プロンプトチェイニングとは？段の切り方とゲート設計・採用判断を実装目線で解説【2026年版】

1つのプロンプトに「読んで、抜き出して、判定して、整形して」と全部書き込んだ結果、途中の指示だけが無視される。LLMを組み込んだ実装で最初にぶつかるのがこの壁です。プロンプトチェイニングは、その1回の呼び出しを複数の呼び出しへ分け、前段の出力を次段の入力として渡していく実装パターンに当たります。この記事では、分割で何が戻ってくるのかという構造の話から、段をどこで切るか、段と段の間で何をどう受け渡すか、間にプログラム側の検査をどう挟むかまでが順に扱う範囲です。呼び出し回数が増えることで払う代償と、あえて分けずに1回で済ませる判断基準も最後に示します。技法の総論はプロンプトエンジニアリングとはを先に読むと位置づけが掴めます。

まとめ：チェーンに分ける条件と、1回の呼び出しで済ませる境界

プロンプトチェイニングとは、1つのタスクを固定された複数の段へ分解し、各段をそれぞれ独立したLLM呼び出しとして実行して、前段の出力を次段の入力に渡す実装パターンです。Anthropicが2024年12月に公開した「Building effective agents」は、このパターンを「タスクを一連の段へ分解し、各LLM呼び出しが前段の出力を処理する」ものと定義し、速度を犠牲にする代わりに各呼び出しを単純化して精度を取りにいく手段だと位置づけています。

分割によって戻ってくるものは3つ。1つは精度で、1回あたりの指示が単純になるぶん取りこぼしが減る。2つ目は検査可能性で、段の切れ目に出力が現れるためプログラム側で条件を確かめられる。3つ目は原因の切り分けで、どの段で壊れたかがログから直接読めます。Prompt Engineering Guideが利点として挙げる透明性・制御性・信頼性は、要するにこの3つを指しています。

採用の境界は「分解の形が事前に決まるか」に尽きます。入力を見る前から段の並びを書き下せるなら分ける価値があり、入力ごとに必要な処理が変わるならチェーンではなくルーティングやエージェント側の設計へ移る。逆に、単発で通っている処理を精度以外の理由で分割すると、レイテンシは段数ぶん積み上がり、共通の前提文を毎段送り直すぶんトークンも増えます。分けるかどうかは、失敗率の実測値と応答時間の要件を並べてから決める判断です。

プロンプトチェイニングが単発プロンプトより精度を上げる仕組みと構造

なぜ分けるだけで結果が変わるのか。理由は指示の競合と、出力に至るまでの経路の長さにあります。

1回の呼び出しに指示を詰め込むと出力が崩れる3つの典型的な理由

1つ目は指示同士の競合です。「原文の表現を保つ」と「200字以内に収める」を同時に書けば、どちらを優先するかはモデル側の裁量に落ちる。人間なら質問して確かめる矛盾が、そのまま出力のばらつきになって表れます。

2つ目は出力形式の混線。抽出結果のJSONと、判定理由の自然文と、整形済みの本文を1回で出させると、形式の切り替え地点で構造が壊れやすい。JSONの中に説明文が紛れる、配列が途中で閉じる、といった崩れ方をします。

3つ目が注意の配分で、入力が長いほど中盤に置いた条件が効きにくくなる現象。指示を5つ並べたときに3番目だけ無視される、という報告のされ方をする不具合の多くはこれに当たります。分割は、この3つをまとめて回避する手段です。1回の呼び出しが受け持つ指示を1種類に絞れば、競合も形式の切り替えも起きず、入力も短くなる。

Chain of Thoughtとの違いは呼び出しを分けるかどうかという一点

混同されやすいのがChain of Thought（CoT）との関係です。両者はどちらも「段を踏ませる」点で似ていますが、段が置かれる場所が違います。CoTは1回の呼び出しの内側に推論の段を作らせる書き方で、途中の出力はモデルの応答テキストの一部として現れる。チェイニングは呼び出しそのものを分け、段の境界がアプリケーションのコード上に現れます。

この差は実装上の帰結を生みます。CoTでは中間の推論をプログラム側で検査できません。テキストとして読めても、それが後段の計算に使われた根拠である保証がないためです。一方チェイニングでは、前段の戻り値がそのまま次段の入力になるので、間に検査も加工も差し込めます。「途中結果を証跡として扱いたい」「途中で分岐したい」という要件があるなら、選ぶべきはチェイニング側になります。

逆に、単一の答えを出す途中で少し考えさせたいだけならCoTで足ります。呼び出しを分ければレイテンシも費用も段数ぶん増えるため、検査も分岐も要らない場面で分ける理由はありません。1回の呼び出し内部での推論設計、few-shot例示の作り方、推論モデルでの扱いはChain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】に整理してあります。

AIエージェントとの違いは処理の経路を誰が決めるかという一点にある

もう1つの線引きがエージェントとの関係です。前述のAnthropicの整理では、チェイニングを含む一連のワークフローは「あらかじめコードで定められた経路を通る」もの、エージェントは「モデルが自ら処理の進め方とツールの使い方を決める」ものとして区別されています。段の並びを書いたのが人間か、実行時にモデルが決めたか。判定基準はここだけです。

実装コストの差は小さくありません。チェーンは経路が固定なので、テストは段ごとの入出力を並べるだけで書けて、費用の上限も段数×モデル単価で事前に読める。エージェントは経路が実行時に決まるため、終了条件や反復上限を別途設計しないと止まらなくなります。要件が固定の手順で書けるうちは、チェーンに留めておくほうが運用は軽く済む。

ただし、入力によって必要な段が変わる処理を無理にチェーンで書くと、分岐が増えて手に負えなくなります。「問い合わせ内容によって参照先も工程数も変わる」といった要件なら、経路をモデル側に委ねる設計へ移る潮時。その判断材料はエージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】にまとめました。

チェーン設計の手順：段の切り方と段間の受け渡し・ゲートの置き方

設計で決めることは3つだけです。どこで切るか、何を渡すか、間に何を挟むか。順に見ていきます。

段を切る境界は出力の型が変わる箇所に置くという原則と切り方の手順

境界の決め方には目安があります。出力の型が変わるところで切る、という原則です。文章から構造化データへ、構造化データから判定結果へ、判定結果から整形済みの文章へ。この型の遷移点が、そのまま段の切れ目になります。

promptingguide.aiが挙げる文書QAの例がこの形をとっています。第1段では質問に関連する引用を原文から抜き出させ、第2段でその引用と原文を使って最終回答を作る。1段目の出力は引用の配列という構造化データで、2段目の出力は自然文の回答。型が変わるところで切られています。

切りすぎにも注意が要ります。段を増やすほど呼び出し回数が伸びるので、型が変わらない処理を無理に分けても得るものがない。「抜き出す」と「並べ替える」を別段にしても、どちらも構造化データを返すだけなら1段にまとめたほうが速くて安い。実務では、まず型の遷移点だけで切って動かし、失敗の出た段だけをさらに割る順序が扱いやすいところです。

段と段の受け渡しは構造化出力で型を固定して曖昧さを消す手順と検査条件

段の間で渡すものは、自然文ではなく構造化した値にします。前段が「関連する引用は以下の3つです」と前置き付きで返すと、次段のプロンプトに前置きごと混ざり、指示と入力の境界が曖昧になるためです。JSON Schemaを指定できるAPIなら型を宣言し、できない場合でも「配列だけを返す」形式で固定する。

受け渡しの実装で効くのは3点。1つは、前段の出力を次段のプロンプトへ入れる際にタグや見出しで囲い、指示文と視覚的に分けること。2つ目は、前段の出力をそのまま渡さず、必要なフィールドだけ抜いて渡すこと。3つ目は、各段が受け取る入力の最大長を決めておくことです。前段の出力が想定より長く返ってきたとき、次段の入力が膨らんで料金と失敗率が同時に跳ねる事故は、この上限で止められます。

もう1つ、渡す量そのものを減らす設計も効きます。原文全体を毎段送り直すのではなく、1段目で抜いた引用だけを2段目へ渡す。文書QAの例が「抽出済みの引用と原文」を渡しているのは検証のためで、原文が巨大なら引用だけに絞る判断もあり得ます。ここは精度と費用の交換で、実測してから決める箇所です。

段間にゲートを置いて手戻りを局所化する検査の設計と分岐の作り方

チェイニングの実装上の利点が最も出るのが、段と段の間に置く検査です。Anthropicの整理では、この中間検査をゲートと呼び、条件を満たさない出力をそこで止める形で図示されています。挙げられている例は、アウトラインを作らせてから基準を満たすか検査し、通ったものだけを本文執筆の段へ流すという構成。

ゲートに置く検査は、まずプログラムで書ける条件から埋めます。件数が想定範囲か、必須フィールドが揃っているか、引用が原文に実在する文字列か。文字列の実在確認は、生成された引用が原文に含まれるかを単純比較するだけで書けて、事実の捏造をかなりの割合で弾けます。LLMに検査させるのは、機械では書けない条件が残ったときだけにする。

検査に落ちたときの動きは3通りから選びます。前段だけをやり直す、既定値を入れて次段へ進む、処理全体を止めて人へ返す。チェーンにしておく価値はここで出ます。単発の呼び出しなら全部を作り直すしかないところを、落ちた段だけの再試行で済ませられる。再試行の上限回数は段ごとに決めておき、無限に回らないようにします。

実装で詰まるレイテンシ・トークン費用・前段の誤りの伝播への対処

分割は無料ではありません。払う代償は3種類あり、いずれも設計で削れます。

呼び出し回数ぶん積み上がる応答時間をどこまで許容するかの見積り

最も直接的な代償が応答時間です。1回3秒の呼び出しを4段に分ければ、単純計算で12秒。Anthropicの整理も、このパターンを「速度を犠牲にして精度を取る」ものとしてはっきり位置づけています。対話型のUIに載せるなら、この積み上がりは要件と正面からぶつかります。

削り方は3つ。1つは、依存していない段を並列に走らせること。「要約する」と「タグを付ける」が互いの出力を必要としないなら、直列に並べる理由はありません。2つ目は、型の遷移が起きていない段を統合して段数そのものを減らすこと。3つ目は、段ごとにモデルを使い分けることです。抽出や分類のような単純な段は小型モデルで足りることが多く、そこだけ差し替えるだけでも体感は変わります。

それでも要件に届かない場合は、UIの側で受ける手が残っています。段の完了ごとに途中経過を返す、先に速い段の結果だけ表示する、といった設計です。全段の完了を待たせない作りにできるなら、総所要時間の絶対値はある程度まで許容範囲に収まります。

トークン消費が増える理由とキャッシュとモデル使い分けで削る手順

2つ目の代償が費用です。増える理由は呼び出し回数だけではありません。段ごとに共通の前提（役割定義、用語集、原文）を送り直すため、入力トークンが重複して積み上がる構造になっています。4段のチェーンで同じ前提文を毎回送れば、その前提のぶんは4倍かかる計算です。

削り方の1つ目は、前提を共有する段でプロンプトの先頭を揃え、キャッシュを効かせること。共通部分を先頭に固定し、段ごとに変わる指示を後ろに置く並びにすると、前方一致で再利用が効きます。仕組みと対応状況はプロンプトキャッシングの仕組みとコスト削減の実装で確認してください。

2つ目は、そもそも渡す量を減らすこと。段ごとに本当に要るフィールドだけを渡す設計にすれば、重複自体が小さくなる。3つ目が段別のモデル使い分けで、判定や整形のような段を小型モデルへ寄せると、単価差がそのまま総額に効いてきます。どの段が費用を食っているかは、段ごとの入出力トークンを記録しないと見えません。まず計測から入るのが順序です。

前段の誤りが後段で増幅する失敗と段ごとのトレースで切り分ける方法

3つ目が失敗の伝播です。1段目が誤った抽出をしても、2段目はそれを与えられた事実として扱い、もっともらしい結論まで組み立ててしまう。単発の呼び出しなら「答えが変」で済むところが、チェーンでは「どこかの段が静かに間違えた結果、最終出力だけが変」という形で表面化します。

切り分けの前提になるのが段ごとの記録です。各段の入力・出力・所要時間・トークン数を紐づけて残し、最終出力から遡れる状態にしておく。この計装が無いままチェーンを長くすると、再現に時間を取られて改善が止まります。トレースと評価の実装はLLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】を参照してください。

評価も段ごとに持ちます。最終出力だけを採点していると、1段目の抽出漏れと3段目の整形崩れが同じ低スコアに丸められてしまう。段ごとに小さなテストデータを用意し、その段の入力に対する期待出力で採点する形にすれば、改修の効果が段単位で読めます。段が独立して呼べる構造になっているからこそ取れる方法で、これはCoTには無い利点です。

プロンプトチェイニングを採用する条件と、あえて分けない場面の判断

ここまでを踏まえて、採否を条件で言い切ります。

採用してよい3つの条件と、実測から段数を決めるまでの進め方の判断軸

採用してよいのは次の3条件が揃うときです。第1に、入力を見る前から段の並びを書き下せること。処理の順番が入力内容に依存しないなら、経路を固定する形が素直に当てはまります。第2に、途中結果に対してプログラムで書ける検査が存在すること。件数・形式・原文との一致など、機械判定できる条件が1つでもあれば、ゲートを置く価値が出ます。第3に、応答時間の要件が段数ぶんの積み上がりを飲めること。バッチ処理や非同期の生成なら、まず問題になりません。

進め方は、いきなり多段にしないことに尽きます。まず単発で作って失敗の型を集め、「抽出は合っているのに整形で崩れる」といった切れ目が見えた時点で、そこだけを2段に割る。段数は設計で決めるのではなく、失敗の分布から決まるものだと考えたほうが手戻りが少なくて済みます。

受託開発の現場では、この段の切り方と検査条件の置き方が最終的な品質を左右します。業務側の判定基準をどこまで機械で書けるかは業務の理解量に依存する部分で、外部の手を借りるなら実装だけでなく業務要件の分解から入れる体制が要る。当社の生成AI開発・AI受託開発では、この処理分割とゲート設計を含めた形でLLM組み込みの実装を請け負っています。

分割せず1回の呼び出しで済ませるべき3つのケースとその理由と判断基準

分けないほうがよい場面もはっきりしています。1つ目は、処理が単一の型変換で終わるとき。翻訳、要約、分類のように入力から出力への写像が1つしかない処理は、途中に検査すべき中間物が存在しません。分けても呼び出しが増えるだけです。

2つ目は、入力によって必要な工程が変わるとき。固定の経路に押し込むと分岐が増え続け、保守できる形に収まらなくなります。この場合はルーティングを前段に置いて経路ごとに別チェーンへ振り分けるか、経路の決定自体をモデルへ委ねる設計に切り替える。

3つ目は、応答時間が最優先の対話用途で、単発でも失敗率が要件を満たしているとき。実測で足りているものを精度向上の名目で分割するのは、確かめられていない改善のために確実な遅延を買う取引になります。分割の判断はいつも、失敗率という数字が先にあってから下すもの。数字が無いなら、まず単発で計測するところから始めます。

よくある質問

プロンプトチェイニングとマルチステップ推論は同じものですか？

指す範囲が違います。マルチステップ推論は「複数の段を経て答えに至る」という現象や課題の性質を指す言葉で、1回の呼び出しの中で起きる場合も含みます。プロンプトチェイニングは、その段を呼び出しの分割として実装する具体的な手段のこと。多段の推論が必要な課題に対する実装方法の1つが、チェイニングだと捉えると整理できます。

LangChainやLangGraphのようなフレームワークは必要ですか？

2段や3段の直列なら、SDKを順に呼ぶだけのコードで足ります。導入を検討する目安は、分岐・再試行・並列・途中状態の永続化が絡み始めたとき。LangGraphは1.2系（2026年8月時点）で、段をノードとして宣言し状態を持ち回す形の実装を提供しています。まず素のコードで書き、経路の管理が本題になった時点で寄せる順序が扱いやすいところです。

段を分けるとハルシネーションは減りますか？

分けること自体では減りません。減るのは、段の間に検査を置いた場合です。たとえば引用抽出の段の直後に「その文字列が原文に存在するか」の照合を挟めば、原文に無い引用はそこで落ちます。効いているのは分割ではなく検査のほうで、チェーンは検査を差し込める場所を作る手段だと考えてください。

何段まで分けるのが現実的ですか？

段数の上限値そのものより、1段あたりの所要時間×段数が応答要件に収まるかで決まります。実務で直列に並べるのは3段から5段程度までが扱いやすく、それ以上になると経路の管理と失敗時の再開が本題になってきます。段が増えてきたら、統合できる段が無いか、並列に回せる段が無いかを先に見直すほうが効果的です。

前段の出力が空だったとき、後段はどう扱うべきですか？

空を正常な結果として扱うか異常として扱うかを、段ごとに決めておきます。「該当する引用が無い」は正常な結果で、その場合の後段は「情報が見つからなかった」と答えるのが正しい動作。一方でフォーマット違反による空は異常なので、再試行か停止に倒します。ゲートでこの2つを区別できる形にしておくと、後段のプロンプトが単純に保てます。

関連記事

• Chain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】：1回の呼び出し内部で推論の段を踏ませる設計
• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】：経路をモデル側が決める設計への移行判断
• LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】：段ごとのトレースと評価の実装
• プロンプトキャッシングの仕組みとコスト削減の実装：共通前提の重複送信を削る手段
• プロンプトエンジニアリングとは：技法全体の中での位置づけ