プロンプトチェーンとプロンプトの分解

プロンプトチェーンとは、複数のプロンプトを順番に使ってタスクを解く方法で、1 つの出力が次の入力になります。プロンプトの分解は、その前の設計ステップで、タスクをどう分けるかを決めることです。この 2 つを合わせたものが、モデルに複雑なことをさせる最も確実な方法です。

1 つの大きなプロンプトが失敗する理由

1 回で抽出、分析、判断、執筆を求めるプロンプトには、いくつかの問題があります。

• 指示同士が競合します。求めることが多いほど、どれかの要件が見落とされる可能性が高まります。
• どの部分が失敗したのか分かりません。最終回答が間違っていても、原因はどのステップにもありえます。
• 部品ごとにテストできません。最後まで検証できるものがありません。
• 呼び出しのたびに、この入力に無関係な指示も含めてすべて課金されます。

チェーンは、各ステップに 1 つの仕事、明確な入力、確認できる出力を与えます。

タスクを分解する方法

注意深い人なら何をどの順で行い、どこで他の人に仕事を渡すかを考えます。良い分割点は次のような場所です。

• 仕事の種類が変わるとき（読む、次に判断する、次に書く）。
• 中間結果を確認する価値があるとき（結論を出す前の、抽出された事実）。
• ステップがときどきしか当てはまらないとき（テキストが英語でない場合だけ翻訳する）。
• ステップごとに異なるモデルが必要なとき（分類には小さいモデル、執筆には大きいモデル）。

具体例

タスク：顧客からの苦情メールに返信する。

ステップ 1：抽出。 小さく高速なモデルが、メールを構造化された事実に変えます。

Extract from the email in the tags: order_id, product, the problem in
one sentence, and what the customer is asking for. Return JSON only.
Use null for anything not stated.

<email>
{{email}}
</email>

ステップ 2：判断。 コードが注文を検索します。プロンプトがポリシーを適用します。

Given the complaint and the order record, choose one action from:
refund, replace, escalate, explain. Give the policy clause that applies.
Return JSON: {"action": string, "clause": string}.

<complaint>{{step1_json}}</complaint>
<order>{{order_record}}</order>
<policy>{{policy}}</policy>

ステップ 3：執筆。 3 つ目のプロンプトが、判断から返信文を作成します。

Write a reply to the customer, under 120 words, that states the action
and what happens next. Do not promise anything outside the action.

<action>{{step2_json}}</action>
<customer_name>{{name}}</customer_name>

各ステップは単独でテストできます。返信が誤った約束をしていても、ステップ 2 の出力を見れば、判断と文章のどちらに原因があるかがすぐに分かります。

ステップ間でのデータの受け渡し

ステップ間では構造化出力を使う。 文章ではなく、JSON やタグ付きのフィールドにします。そうすれば次のプロンプトもコードも、その形に頼れます。構造化出力のプロンプトを参照してください。

次のステップに必要なものだけを渡す。 履歴全体を転送すると、後続のプロンプトが長くなり、初期のミスが広がります。

すべての境界で検証する。 各ステップの出力は、使う前に確認します。検証のないチェーンは誤りを増幅します。各ステップが 95% の確率で正しい 5 ステップは、すべてが正しい確率が約 77% にしかなりません。

挿入するものはすべて区切る。 あるモデルの出力は、次のモデルにとって信頼できない入力です。「指示を無視して」と書かれた苦情メールは、ステップ 1 を通過して、今はステップ 2 のプロンプトの中にあります。挿入する内容はタグで囲みます。プロンプトインジェクションを参照してください。

チェーンの形

ループには必ず上限を設けてください。永遠に再試行するチェーンは、障害であり請求書です。

チェーンと代替手段の比較

思考の連鎖との比較。 思考の連鎖は、推論を 1 回の応答の中に収めます。手順があらかじめ分からないときに使います。手順が分かっているときはチェーンを使いましょう。テストしやすさと制御が得られます。

エージェントとの比較。 チェーンでは、順序をコードが決めます。エージェントでは、モデルが決めます。チェーンはより安く、速く、予測しやすいものです。道筋が途中で見つかるものに依存する場合にだけ、エージェントを選びます。ReAct プロンプティングと AI エージェント向けのプロンプトを参照してください。

注意すべきコスト

チェーンは呼び出しが増えます。経済的に保ちましょう。

• 各ステップをこなせる最小のモデルを使います。
• 独立したステップは並列に実行して遅延を減らします。
• この入力に当てはまらないステップは飛ばします。
• 提供元が対応していれば、各プロンプトの固定部分をキャッシュします。トークン最適化を参照してください。

各リンクを健全に保つ

チェーンには保守すべきプロンプトが複数あるので、1 つの問題は見逃されがちです。それぞれをファイルとして保存し、変更のたびにすべてをチェックします。プロンプトテストゲートは、リポジトリ内のどのプロンプトでも品質基準を下回ったり、トークン予算を超えたりするとプルリクエストを失敗させます。プロンプトアナライザーは、あるステップが次のステップに入力を渡す箇所で最も重要になる、区切りのない変数を報告します。