プロンプトチェイニング:1つのプロンプトでは不十分な場合

プロジェクト全体を1つのプロンプトに詰め込もうとしたことがある方なら—要件 → ソリューション → 計画 → リスク → 最終ドキュメント—その結果がどうなるかはすでにご存知でしょう:

• ステップをスキップする
• 制約を忘れる
• 簡単に検証できない「確信に満ちた」答えを出す
• 何か問題が起きた瞬間、どこでミスが発生したのかわからなくなる

プロンプトチェイニングはその解決策です。組み立てラインの各ステーションとして各プロンプトを配置するワークフローを構築するようなものです:1つのステップが入り、1つのステップが出て、その出力が次のステーションの入力になります。

つまり:LLMに「すべてを一度に」やらせるのではなく、一度に1つずつ、確実にやらせるのです。

1) プロンプトチェイニングとは?

プロンプトチェイニングは以下の実践です:

1. 大きなタスクを小さなサブタスクに分解する
2. 各サブタスクに専用のプロンプトを設計する
3. あるステップから次のステップへ構造化された出力を渡す
4. チェーンが逸脱しないように検証+修正ステップを追加する

基本的には「マイクロサービスの考え方」をLLMの推論に適用したものです。

シングルプロンプト vs プロンプトチェイニング(わかりやすく)

| 側面 | シングルプロンプト | プロンプトチェイニング | |----|----|----| | 複雑性 | シンプルな1回限りのタスクに適している | マルチステップの実際のワークフロー向けに構築 | | ロジック | モデルがプロセスを推測する | あなたがプロセスを定義する | | 制御 | 制御が難しい | すべてのステップが制御可能 | | デバッグ | 「どこで問題が起きた?」 | 問題のステップを特定できる | | コンテキスト制限 | オーバーフローしやすい | データを段階的に供給 |

2) なぜ機能するのか(本当の理由)

LLMは複数の目標を同時に処理するのが得意ではありません。

「要件を分析し、機能を提案し、工数を見積もり、優先順位をつけ、計画を書く」と依頼すると—マルチオブジェクティブな最適化問題を設定したことになります。モデルは通常1つの目標では適切に処理しますが、残りの目標では静かに期待を下回ります。

プロンプトチェイニングは認知負荷を軽減します:1ステップ → 1出力 → 1成功基準。

3) コアメカニズム:入力 → 処理 → 出力(繰り返し)

その本質において、プロンプトチェイニングはループです:

• 入力: 前のステップの出力 + 新しいデータ
• 処理: ルール + フォーマット制約を持つ次のプロンプト
• 出力: 次のステップのための構造化された結果

視覚化できるシンプルなチェーンは以下の通りです:

flowchart LR A[生のユーザーフィードバック] --> B[プロンプト1:課題点を抽出] B --> C[プロンプト2:機能を提案] C --> D[プロンプト3:優先順位付け & 工数見積もり] D --> E[プロンプト4:イテレーション計画を作成]

4) 良いチェーンを構築するための4つの必須事項

4.1 サブタスクは独立かつ接続されている必要がある

• 独立: 各ステップは1つの作業を行う(重複なし)
• 接続: 各ステップは前の出力に依存する(「浮いた」ステップなし)

悪い例:「課題点を抽出し、機能を設計する」 良い例:ステップ1で課題点を抽出;ステップ2でそれに基づいて機能を設計する。

4.2 中間出力は構造化されている必要がある

自由テキストは脆弱です。次のプロンプトがそれを誤読したり、再解釈したり、無視したりする可能性があります。

JSON、テーブル、または固定キーを持つ箇条書きリストのような構造化フォーマットを使用してください。

例(実際に解析できるJSON):

{  "pain_points": [   {"category": "performance", "description": "チェックアウトに8秒以上かかる", "mentions": 31},   {"category": "ux", "description": "返金ボタンが見つけにくい", "mentions": 18},   {"category": "reliability", "description": "エラーなしで支払いが失敗する", "mentions": 12} ] }

4.3 各プロンプトは明示的にコンテキストを「継承」する必要がある

モデルが「あなたの意図を覚えている」と仮定しないでください。次のプロンプトで、前の出力を明示的に参照してください:

4.4 失敗パス(検証 + 修復)を組み込む

すべてのチェーンには「品質ゲート」が必要です:

• 検証:「出力にすべての必要なキーが含まれているか?数値は一貫しているか?」
• 修復:「欠落している場合、欠落している部分のみを再生成する」
• ガードレール:「最大2回再試行;それ以外の場合はベストエフォート + エラーを返す」

5) あらゆる場所で使用する3つのアーキテクチャ

5.1 リニアチェイニング:固定ステップ、分岐なし

使用する場合: ワークフローが予測可能な場合。

例:UK月次収益レポート(リニア)

英国のeコマースショップからCSVエクスポートがあり、以下が必要だとしましょう:

• クリーニング
• インサイト
• 経営陣向けレポート

ステップ1 — データクリーニングプロンプト(クリーンなテーブルまたはJSONを出力)

SYSTEM: あなたはデータアナリストです。指示に正確に従ってください。 USER: 以下のデータセットをクリーニングしてください。 ​ ルール: 1) revenue_gbpまたはunits_soldがnullの行を削除する。 2) revenue_gbpの外れ値にフラグを立てる:カテゴリ平均の3倍以上 または 0.1倍未満。削除はしない。 3) month_over_month_pctを追加:(今月 - 先月) / 先月 * 100。 4) JSON配列のみで出力。各項目には以下が必要:   date, category, revenue_gbp, units_sold, region_uk, outlier_flag, month_over_month_pct ​ データセット: <データをここに貼り付け>

ステップ2 — インサイトプロンプト(箇条書きのインサイトを出力)

SYSTEM: あなたは英国のリーダーシップ向けに執筆するシニアアナリストです。 USER: 以下のクリーンなJSONを使用してインサイトを作成してください: ​ 1) カテゴリ:revenue_gbp上位3つ、month_over_month_pct上位3つ。貢献率%を含める。 2) 地域:収益上位2地域、最大の減少(>10%)。 3) トレンド:全体的なトレンド(上昇/下降/変動)。収益vs販売数の関係を説明。 ​ 出力フォーマット: - カテゴリインサイト:2-3箇条書き - 地域インサイト:2-3箇条書き - トレンドインサイト:2-3箇条書き ​ クリーンなJSON: <ステップ1の出力を貼り付け>

ステップ3 — レポート作成プロンプト(最終ドキュメントを出力)

SYSTEM: あなたは簡潔な内部レポートを作成します。 USER: 以下のインサイトを「月次収益ブリーフ」(800-1,000語)に変換してください。 ​ 構造: 1) エグゼクティブサマリー(1つの短い段落) 2) 主要インサイト(カテゴリ / 地域 / トレンド) 3) 推奨事項(2-3の実行可能項目) 4) クロージング(1つの短い段落) ​ GBP(£)フォーマットと英国スペリングを使用。 インサイト: <ステップ2の出力を貼り付け>

リニアチェーンは最良の意味で退屈です:予測可能で、自動化可能で、テストが容易です。

5.2 ブランチングチェイニング:分類に基づいてパスを選択

使用する場合: 次のステップが決定(タイプ、重大度、意図)に依存する場合。

例:顧客メッセージトリアージ(ブランチング)

ステップ1でメッセージを分類します:

SYSTEM: あなたは顧客メッセージを分類します。ラベルのみを出力してください。 USER: このメッセージを以下のいずれかに分類してください: - complaint - suggestion - question ​ 出力フォーマット: label: <3つのうちの1つ> ​ メッセージ: 「注文に課金されましたが届かず、メールにも誰も返信しませんでした。これはひどいです。」

次に分岐します:

• complaintの場合 → インシデント対応計画を生成
• suggestionの場合 → 実現可能性 + ロードマップスロッティングを作成
• questionの場合 → 直接サポート回答を生成

クレーム処理ハンドラー(例):

SYSTEM: あなたはカスタマーオペレーションマネージャーです。 USER: 以下のメッセージに対するクレーム処理計画を作成してください。 ​ 含める内容: 1) 問題の記述 2) アクション:1時間以内、24時間以内、48時間以内 3) 補償提案(英国eコマースとして妥当) 3つのセクションに分けて箇条書きで出力。 ​ メッセージ: <メッセージを貼り付け>

ブランチングチェーンは、すべての入力を同じ問題として扱うことを止める方法です。

5.3 ループングチェイニング:停止条件に達するまで繰り返し

使用する場合: 多くの類似項目を処理する必要がある場合、または出力を反復的に改善する場合。

例:製品リストを一括生成(ループング)

ステップ1でリストを項目ブロックに分割します:

SYSTEM: あなたは製品データをフォーマットします。 USER: 以下の製品リストを個別のブロックに分割してください。 ​ 出力フォーマット(各項目について繰り返し): [ITEM N] name: key_features: target_customer: price_gbp: ​ 製品リスト: <リストを貼り付け>

ステップ2で各ブロックをループ処理します:

SYSTEM: あなたは高いコンバージョンを生む製品コピーを書きます。 USER: 以下の製品のeコマース説明を書いてください。 ​ 必要条件: - フック見出し ≤ 12語 - 3つの機能箇条書き(それぞれ ≤ 18語) - 1文:誰に最適か - 1文:なぜ良い価値か(£を使用) - 合計150-200語、英国英語 ​ 製品: <ITEM Nを貼り付け>

ループングチェーンにはハードストップルールが必要です:

• 正確にN項目を処理する、または
• 単語数が長すぎる場合は最大2回再試行、または
• 検証が通過したら停止

そうしないと、世界で最も高価な無限ループを作成することになります。

6) 実用的な「自爆しない」チェックリスト

問題:中間フォーマットが乱雑 → 次のプロンプトが失敗

修正: フォーマットを譲れないものにする。

次のような行を追加:

• 「JSONのみを出力してください。」
• 「従えない場合は出力:ERROR:FORMAT。」

問題:モデルが以前の詳細を忘れる

修正: 毎回「契約」を明示的に再表明する。

• 「前の出力のpain_points配列を使用してください。」
• 「追加のカテゴリを作り出さないでください。」

問題:ループが収束しない

修正: 測定可能な制約 + 最大再試行を定義する。

• 「単語数 ≤ 200」
• 「最大再試行:2」
• 「それでも失敗する場合は、ベストエフォート + エラーリストを返す」

問題:分岐選択が間違っている

修正: 分類ルールを改善 + 2回目のチェックを追加。

例:

• クレームにはネガティブな感情と具体的な問題が含まれている必要があります。
• 不確実な場合、出力ラベル:question(clarificationが必要)。

7) チェイニングを楽にするツール

プロンプトを手動でチェーン化できます(コピー/ペーストで機能します)が、数ステップを超えるとツールが役立ちます。

• n8n / Make:API呼び出しのチェーン化、出力の保存、アラートのトリガーのためのローコードワークフローツール。
• LangChain / LangGraph:メモリ、分岐、再試行、ツール呼び出し、状態管理を備えたチェーンを構築。
• Redis / Postgres:中間結果を永続化して、再開、監査、重複呼び出しの回避が可能。
• Notion / Google Docs:初期段階の「人間をループに含む」チェイニングに驚くほど効果的。

8) これをレベルアップする方法

プロンプトチェイニングは、以下と組み合わせるとさらに強力になります:

• RAG:チェーンの途中で検索ステップを追加(例:「応答を作成する前にポリシードキュメントを取得」)
• 人間の承認ゲート:リスクの高いアクション(価格変更、顧客への返金、コンプライアンス回答)の前に承認
• マルチモーダルステップ:テキスト → 画像ブリーフ → 図の生成 → 最終ドキュメント

最終的な見解

プロンプトチェイニングは「より多くのプロンプト」ではありません。それはワークフロー設計です。

プロンプトを契約、検証、失敗パスを持つステップとして扱い始めると、LLMは混沌としたテキストジェネレーターのように振る舞うのをやめ、信頼できるチームメイトのように—一度に1つのステーションずつ—行動し始めます。

1回限りのデモを超えて何かを構築している場合は、チェーン化してください。

\