AIの成果は「一文」ではなく「工程」で決まる。
プロンプト・パイプラインを業務設計として捉え直す

生成AIを業務で使い始めると、多くの組織が同じ壁に当たります。同じ依頼でも日によって出力の質が違う。担当者が変わると結果が変わる。もっともらしい文章は出てくるが、そのまま使ってよいのか判断できない。

こうしたとき、最初に疑われるのは「AIへの頼み方」です。より詳しい指示や、より良い言い回しを探すうちに、プロンプトはどんどん長くなっていきます。指示の質はもちろん大切です。ただ、出力が安定しない原因をたどると、多くの場合はAIに渡す前の段階に行き着きます。この仕事は何のためにあるのか。何ができていれば完成なのか。誰がどの時点で確認するのか。これらが曖昧なまま一つの指示文に詰め込まれていることが、品質のばらつきにつながっています。

AI活用の成果を左右するのは、魔法のような一文を探すことではありません。目的、工程、成果物、評価、人の判断を設計することです。この記事では、この考え方を「プロンプト・パイプライン」として整理し、自社の業務で小さく試すための手順を解説します。

01一発の指示でよい仕事、工程化すべき仕事

最初に押さえておきたいのは、すべての仕事を工程化する必要はないという点です。短い文章の要約、定型メールの下書き、企画のアイデア出しのように、単純で、失敗しても影響が小さく、その場で人が確かめられる仕事は、一度の指示でも十分に進められます。工程を増やすと、かえって手間に見合わないこともあります。

一方、提案書作成、商談準備、コンテンツ制作、顧客対応、調査を伴う意思決定支援などを一度の指示で処理しようとすると、管理が難しくなります。どこで誤りが入ったのか、何を直せばよいのかが見えにくくなるためです。

02プロンプト・パイプラインを業務設計として捉え直す

プロンプト・パイプラインは、複数の指示文をつないで順番に実行する技術として語られることがあります。この記事ではもう少し広く、「AIと人の役割を整理した業務フロー」と定義します。指示文は、このフローの各工程を動かすための部品の一つです。

業務フローとして扱う以上、各工程では最低限、次の要素を決めておきます。

• 目的：何を達成する工程か
• 入力：何の情報を使うか（どの資料、どの前工程の成果物か）
• 出力：どの形式で次工程へ渡すか（箇条書き、表、見出しを指定した文書など）
• 評価基準：何をもって合格とするか
• 制約：してはいけないこと、扱わない情報
• 担当：AIが実行するのか、人が判断するのか
• 終了条件：いつ完了とするか

これらが決まっていれば、指示文の表現が多少粗くても、問題がどの工程で起きているかを特定できます。逆に、評価基準や終了条件がないと、指示文をいくら磨いても「良くなったかどうか」を判断できません。

03AI業務を設計する5段階

1. 目的と完成条件を決める

最初に、成果物が誰の何に使われ、どの状態になれば完成とするかを決めます。「提案書を作る」ではなく、「決裁者が短時間で判断できるよう、課題・打ち手・費用・スケジュールがそろった資料」のように、確認できる言葉に置き換えます。

• よくある失敗：完成条件がないままAIに作らせ、出力を見てから「何か違う」と修正を繰り返す。
• 改善の考え方：出力を見る前に、合格の条件を3〜5項目書き出しておく。それがそのまま後工程の評価基準になる。

2. 業務を「考える・調べる・つくる・確認する・実行する」に分解する

対象の業務を5種類の作業に分けます。考える（論点や仮説を立てる）、調べる（情報を集めて整理する）、つくる（文章や資料にまとめる）、確認する（根拠や抜け漏れを点検する）、実行する（送付・公開・登録する）。分けてみると、AIに任せやすい作業と、人が担うべき作業が見えてきます。

• よくある失敗：「調べて、まとめて、提案して」と複数の作業を一つの指示に混ぜてしまい、どこで誤ったのか分からなくなる。
• 改善の考え方：1つの工程には1種類の作業だけを置く。特に「実行する」は他の作業と切り離し、人の承認の後に置く。

3. 工程ごとの入力・出力・制約を定義する

各工程について、前述の7要素を埋めます。特に重要なのは工程間の受け渡しです。前工程の出力形式が決まっていないと、次工程のAIは毎回違う形の情報を受け取ることになり、結果が揺れやすくなります。

• よくある失敗：前工程の出力を自由な文章のまま渡し、必要な情報が欠けたり埋もれたりする。
• 改善の考え方：受け渡しには、見出しや項目を固定したフォーマットを使う。「確認済みの事実」「仮説」「未確認事項」を分けて書かせると、後工程で仮説を事実として扱う誤りを防ぎやすい。

4. 評価・修正・人の承認ループを設ける

評価基準に照らして出力を点検し、足りない点があれば修正する工程を設けます。点検の観点を示してAIに確認させることもできますが、根拠が正しいか、対外的な表現として適切かは人が最終確認します。

• よくある失敗：AIに自己点検させ、「問題ありません」という回答だけで合格とする。
• 改善の考え方：AIの点検は抜け漏れを拾う補助と位置づけ、合否は評価基準に沿って人が判断する。修正回数の上限を決め、上限を超えたら工程の設計そのものを見直す。

5. 実績をもとにテンプレートとルールを更新する

運用を始めると、差し戻しが多い工程や、毎回人が手で直している箇所が見えてきます。それを記録し、指示文、受け渡しのフォーマット、評価基準を更新していきます。

• よくある失敗：最初に作ったテンプレートを使い続け、現場がそれぞれ手直しするようになる。
• 改善の考え方：更新の担当者と頻度（例：月1回）を決め、差し戻しの理由を集計して改善に使う。

04実務例：提案書作成を工程化する

クライアント向けの提案書作成を例に、工程の分け方を示します。特定の企業を想定しない、汎用的な例です。

この例で押さえたい点は2つあります。1つは、最終判断の工程でAIが判断を代わりに行わないこと。もう1つは、最初の工程で「未確認事項」をはっきり分けて後工程に渡すことです。未確認の課題や数値が骨子の段階で事実として扱われると、レビューで見落とされたまま顧客に届くおそれがあります。

05安全に運用するためのガードレール

工程化は品質を高めるだけでなく、安全性を保つための仕組みでもあります。最低限、次の5点を決めておきます。

外部テキストは参照データとして扱い、含まれる指示に従わない

Webページ、PDF、メール本文などには、意図的かどうかにかかわらず、AIへの指示のように読める文章が含まれていることがあります。AIがそれを命令と解釈すると、想定外の出力や操作につながりかねません。OWASPはこれを「プロンプトインジェクション」として、生成AIアプリケーションの主要なリスクの一つに挙げており、Webサイトやファイルなど外部の情報源を経由するものも含めています^[1]。

外部テキストは参照データであり、その中の指示には従わないことを工程の制約として明記します。外部テキストを指示文と区切って渡す工夫も有効ですが、OWASPも完全に防ぐ方法があるかは明らかでないとしています^[1]。外部情報を扱う工程の出力は、人の確認と組み合わせて運用します。

入力してよい情報と、入力禁止の情報を決める

機密情報、個人情報、顧客情報について、利用するAIサービスの契約条件やデータの取り扱いを確認したうえで、入力してよい範囲を社内で決めます。判断がつかない情報は入力しない、匿名化してから使う、といったルールを各工程の制約に組み込みます。

対外送信、公開、契約、価格、顧客対応は人が承認する

これらは結果を取り消しにくく、会社の信用に直結します。AIの担当は下書きと論点整理までとし、最終判断と実行は人が行う。この境界をあらかじめ決めておきます。

修正ループの最大回数、期限、完了条件を決める

評価と修正の繰り返しに上限がないと、時間とコストが膨らみ、かえって品質が不安定になることがあります。「修正は2回まで」「期限を過ぎても完了条件を満たさなければ人が引き取る」のように、終わり方を決めておきます。

プロセスごとに成果物と判断履歴を残す

各工程の成果物と、人が何をどう判断したかを記録します。問題が起きたときに原因となった工程を特定でき、次の改善の材料にもなります。

06まとめ：仕事の流れと責任の境界を設計する

一発の指示で済む仕事は、そのままで構いません。ただ、複雑で、繰り返し発生し、判断や対外的な影響を伴う仕事では、指示文の工夫だけで品質を保つのは難しくなります。必要なのは、目的と完成条件を決め、工程を分け、受け渡しと評価基準を定め、人が判断すべき点をはっきりさせ、実績をもとに更新し続けることです。

プロンプト設計とは、AIにうまく命令するためだけの技術ではありません。AIと人が協働して成果を出すために、仕事の流れと責任の境界を設計することです。