Prompt Chaining（プロンプト連鎖）

タスクを固定の直列ステップに分解し、各LLM呼出が前段の出力を処理するパイプラインを構成する。段と段の間にプログラマティックな検証ゲートを挟むことで、プロセスの逸脱を早期に検出する。

別名

呼称	出典
Sequential Orchestration（順次オーケストレーション）	Microsoft「AI Agent Orchestration Patterns」
Pipeline / Linear Delegation	同上（Azure記載の別称）

問題

1回のプロンプトに複数の責務を詰め込むと、各責務へのモデルの注意が分散し、個々のサブタスクの精度が落ちる。「アウトラインを作り、基準を満たすか確認し、本文を書け」という指示は、3つの仕事のどれに対しても中途半端な出力を生みやすい。

さらに深刻なのは、単一呼出では中間結果を検証する機会がないことである。序盤の誤り——ずれたアウトライン、誤った前提——は誰にも検査されないまま後続の処理に取り込まれ、最終出力まで静かに伝播する。壊れた出力を見ても、どの工程が原因かを特定できない。

コンテキスト

適用する:

タスクを固定のサブタスクに明確かつクリーンに分解できる場合
レイテンシと引き換えに精度を上げたい場合——各LLM呼出をより簡単なタスクにすることが本パターンの主目的
draft→review→polish 型の、段階的洗練が品質を上げるワークフロー

適用しない（不要な）ケース:

サブタスクが embarrassingly parallel で、直列化する理由がない場合（→ Parallelization）
実行経路が動的で、後戻りや反復が必要な場合（→ ReAct、Evaluator-Optimizer）
段数が少なく、単一のLLM呼出で十分にこなせる場合。ワークフロー自体が不要なら作らない

解決

各段を単一責務に専門化したLLM呼出とし、前段の出力だけを入力として受け取るパイプラインを事前定義する。段間のゲートは決定論的コード（スキーマ検証・形式検証・ルールチェック）で実装し、不合格なら早期に停止するか、失敗理由を添えて前段へ差し戻す。次にどの段へ進むかはコードが決め、モデルには委ねない。

Anthropic の例では、文書のアウトライン作成 → アウトラインが基準を満たすかのチェック（ゲート） → アウトラインに基づく本文執筆、という連鎖を挙げる。Azure の例は契約書生成の4段パイプラインで、テンプレート選定 → 条項カスタマイズ → 規制コンプライアンス確認 → リスク評価と、各段が前段の完全な出力を処理する。

python

stages = [
    Stage(prompt=outline_prompt, gate=check_outline_criteria),  # 基準チェック
    Stage(prompt=draft_prompt,   gate=check_schema),            # 形式検証
    Stage(prompt=polish_prompt,  gate=check_style_rules),       # ルールチェック
]

def run_chain(task, max_retries=2):
    data = task
    for stage in stages:                      # 経路は事前定義。コードが進行を決める
        for _ in range(max_retries + 1):
            candidate = llm(stage.prompt, input=data)
            ok, reason = stage.gate(candidate)  # ゲートは決定論的コード
            if ok:
                data = candidate
                break
            data = attach_feedback(data, reason)  # 失敗理由を添えて同段を再試行
        else:
            return fail(stage, reason)        # リトライ上限で早期停止・失敗報告
    return data

実装の要点:

各段は単一責務に絞る。 1つの段に複数の仕事をさせるなら、そもそも分解した意味がない。段のプロンプトは前段の出力形式を前提に書けるため、単体でテストできる
ゲートは決定論的コードで書く。 スキーマ検証・必須項目チェック・正規表現で判定できる基準に限定する。自然言語でしか表せない基準を判定したくなったら、それは Evaluator-Optimizer の領域である
不合格時の挙動を設計する。 差し戻しの回数上限と、上限到達時の扱い（早期停止・失敗報告）を決める。検証だけあって差し戻しがないゲートは、単に「途中で止まるパイプライン」になる

トレードオフ

✅ 各LLM呼出がより簡単なタスクになり、段単位の精度が上がる。障害時もどの段が原因かを特定でき、デバッグとテストが段単位で完結する
✅ 中間ゲートが逸脱をその場で検出し、序盤の誤りが最終出力まで伝播するのを遮断する
⚠️ 直列化のぶんレイテンシが増える。これは精度と引き換えに意図的に支払うコストであり、許容できないならこのパターンは選ばない
⚠️ 序盤の段が低品質な出力を出しうるのに差し戻し設計がないと、蓄積誤差がそのまま下流に流れる。後続の段を守る手段がないタスクには適用しない

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
Pipes and Filters	Azure 自身が対応を明言。「決定論的にコーディングされたフィルタによるデータ変換の連鎖」から「非決定論的なLLM呼出による文脈的洗練の連鎖」へ。フィルタが確率的な処理に置き換わったため、段間にプログラマティックな評価ゲートを挟むことが必須になった

出典・参考

Anthropic — Building Effective Agents（Prompt chaining ワークフローの原典。ゲートによる中間チェックの推奨）
Microsoft — AI Agent Orchestration Patterns（Sequential orchestration。契約書生成パイプラインの例）
Azure Architecture Center — Pipes and Filters pattern（系譜元のクラウドパターン）

Prompt Chaining（プロンプト連鎖） ​

別名 ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

クラウドパターンとの対応 ​

関連パターン ​

出典・参考 ​

Prompt Chaining（プロンプト連鎖）

別名

問題

コンテキスト

解決

トレードオフ

クラウドパターンとの対応

関連パターン

出典・参考