プロンプトチェイニングとは？AI処理を分割する設計と費用の増え方

開発ベンダーから届いた提案書に「処理を複数ステップに分けたプロンプトチェイニング構成にします」と書かれていて、その意味は何となく分かるものの、稟議書にどう書けばいいか手が止まっている——生成 AI の PoC を本番化しようとしている担当者から、こうした状況はよく生まれます。単発のプロンプトでは出力品質が安定せず、分割すれば改善するという説明自体は理解できる。しかし、その構成に月々いくらかかるのかが読めないままでは、社内を説得できません。

やっかいなのは、プロンプトチェイニングを解説した記事の多くが「分けると精度が上がる」という手法面に集中していて、分けたときに費用がどう変わるのかにほとんど触れていない点です。実装者向けのサンプルコードは見つかるのに、発注する側が知りたい「工程を 4 つに分けたら API 利用料は 4 倍になるのか」という素朴な疑問に答えてくれる情報が見当たらない。結果として、ベンダーの提示する金額を検算できないまま受け入れるか、判断を先送りするかの二択になってしまいます。

ですが、この判断はそれほど難しくありません。プロンプトチェイニングの費用は「呼び出し回数」「入力トークンの再送量」「出力トークンの総量」という 3 つの要因に分解でき、そのそれぞれは提案書に書かれた工程図から概算できるからです。逆に言えば、この 3 要因を押さえておけば「なぜこの工程数なのか」「参照文書を毎回全文渡す設計になっていないか」といった、費用に直結する質問をベンダーに投げられるようになります。

本記事では、プロンプトチェイニングの基本構造と代表的な連結パターンを整理したうえで、費用がどのように増えるのかを計算式と試算例で示します。さらに、費用を抑える設計の勘所、工程を分けすぎないための判断基準、そして発注時に見積書で確認すべき項目までを解説します。読み終えたとき、自社の業務が分割に向いているかを自分で判断し、見積書のランニングコスト欄を概算で検算できる状態を目指します。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

プロンプトチェイニングとは？複数のAI処理を連結する設計手法

プロンプトチェイニング（プロンプトチェーン）とは、ひとつの複雑なタスクを複数のサブタスクに分割し、前の工程で得た AI の出力を次の工程の入力として渡していく設計手法です。Prompt Engineering Guide 日本語版では「タスクを複数のサブタスクに分割することがあります。これらのサブタスクが特定されると、LLM はそれぞれに対してプロンプトを出し、その回答を次のプロンプトの入力として利用します」と説明されています。

イメージとしては工場の生産ラインに近いものです。一人の職人に「材料を渡すので完成品まで全部やってください」と頼むのではなく、切断・加工・組立・検品と工程を切り、各工程の担当者には自分の持ち場だけを任せる。各担当者の仕事が単純になるぶん、品質のばらつきが減り、どの工程で不良が出たのかも特定しやすくなります。社内の稟議が起案・部門確認・法務確認・決裁と回覧されていく流れを思い浮かべてもよいでしょう。

ここで最初に押さえておきたいのが、工程を切るということは AI（LLM）を呼び出す回数がその分だけ増えるという事実です。API の課金はリクエストごとの入力トークン量と出力トークン量に応じて発生するため、工程を増やす設計判断はそのまま費用の設計判断でもあります。この点は本記事の後半で計算式として扱いますが、以降の解説もこの視点を持って読み進めていただくと理解が早くなります。

プロンプトチェーンの基本構造｜分割・受け渡し・逐次実行

プロンプトチェーンは、次の 3 つの要素で構成されます。

1. 分割（サブタスクへの分解）

元のタスクを、独立して定義できる小さな作業単位に切り分けます。「社内規程から該当箇所を探す」「見つけた箇所を平易な言葉に言い換える」「回答文の形式に整える」といった具合です。ここで重要なのは、各工程の入力と出力が明確に定義できることです。工程の切れ目が曖昧だと、次に説明する受け渡しが破綻します。

2. 受け渡し（工程間で渡す情報の固定）

前工程の出力をそのまま次工程に流すのではなく、「何を渡すか」を形式ごと決めておきます。実務では JSON のような構造化されたデータ形式（項目名と値の組を機械が読み取れる形で並べた形式）で受け渡すのが一般的です。自由な文章のまま渡すと、次工程の AI が受け取り方を毎回解釈し直すことになり、出力が不安定になります。

3. 逐次実行（順番に呼び出す）

工程 1 の結果が出てから工程 2 を呼び出す、という順次処理になります。並行して同時に走らせられる工程もありますが、前工程の出力に依存する工程は必ず待つことになります。これが後述する応答時間の増加につながります。

単一プロンプトで一度に指示する方法との違い

単一プロンプトは、ひとつの指示文の中に「参照してよい文書」「守るべきルール」「出力形式」「例外時の扱い」をすべて詰め込み、1 回の呼び出しで完成品を得ようとするアプローチです。手軽ですが、指示が長くなるほど AI が一部の条件を見落としやすくなり、出力の形式も安定しづらくなります。

両者の違いを整理すると次のようになります。

「プロンプトを分割すると精度が上がる」と言われる根拠は、この表の上から 4 行にあります。一方で下から 3 行が、そのまま費用と運用要件への影響になります。判断は、この上下をひとつの天秤に載せて行うことになります。

AIエージェント・AIオーケストレーションとの違い

プロンプトチェイニングと混同されやすい概念に、AI エージェントと AI オーケストレーションがあります。ここを整理しておくと、ベンダー提案書に出てくる用語を正しく読み分けられます。

プロンプトチェイニング（ワークフロー型） は、人が手順をあらかじめ固定する方式です。工程 1 → 工程 2 → 工程 3 という道筋は設計時に決まっており、AI は各工程の中身を担当するだけです。Anthropic の技術記事Building Effective Agentsでは、プロンプトチェイニングを「タスクを一連のステップに分解し、各 LLM 呼び出しが前の呼び出しの出力を処理する」ワークフローと定義し、「タスクが固定されたサブタスクに簡潔に分解できる場合」に適していると述べています。

AI エージェント は、AI 自身が手順を決める方式です。同記事は、ワークフローが「あらかじめ定義されたコードパス」で LLM とツールを制御するのに対し、エージェントは「LLM が自らのプロセスとツール利用を動的に方向づける」システムだと区別しています。柔軟性は高いものの、手順が実行ごとに変わるため呼び出し回数を事前に見積もりにくく、費用の上限が読みづらいという特性があります。

AI オーケストレーション は、さらに一段上のレイヤーで、社内の複数の AI 活用施策やシステム連携を組織全体でどう束ねるかという話です。ひとつの処理フローの内部設計を指す本記事のテーマとは、扱う粒度が異なります。複数の AI 処理を組織全体でどう統合していくかについてはAIオーケストレーションとはをご覧ください。

見積もりの観点で重要なのは、ワークフロー型（プロンプトチェイニング）は呼び出し回数が設計時に確定するのに対し、エージェント型は確定しないという点です。提案書がどちらの方式かによって、費用の予測可能性が大きく変わります。

プロンプトチェイニングで精度が上がる仕組みと代表的な連結パターン

「プロンプトを分割すると精度が上がる」という説明は、それだけでは費用増を正当化する材料になりません。なぜ上がるのかを言語化しておくと、自社の業務にその理屈が当てはまるのかを判断できるようになります。理由は大きく 3 つです。

1 工程あたりの指示が単純化される：AI に一度に課す判断の数が減るため、条件の見落としが起きにくくなります。前掲の Anthropic の記事も、プロンプトチェイニングの狙いを「各 LLM 呼び出しをより簡単なタスクにすることで、レイテンシと引き換えに高い精度を得る」ことだと明示しています。裏を返せば、もともと単純なタスクを分割しても精度の伸びしろは小さいということです。

工程ごとに出力形式を固定できる：「この工程の出力は項目 A・B・C を持つ構造化データ」と決めておけば、想定外の形式で返ってきたことを機械的に検知できます。単一プロンプトでは出力が最終成果物ひとつしかないため、こうした途中でのチェックができません。

中間結果を人が検証できる：Prompt Engineering Guide も、この手法の利点として「モデルの応答に関する問題を簡単にデバッグし、改善が必要な各段階のパフォーマンスを分析して改善することが可能」になる点を挙げています。運用開始後に品質が落ちたとき、どの工程が原因かを特定できることは、長期運用のコストに直結します。

以下では、実務でよく使われる連結パターンを 3 つの型として紹介します。自社の業務がどの型に当てはまるかを考えながら読んでみてください。

逐次型｜抽出→整形→生成という最も基本の連結パターン

前の工程の出力を、そのまま次の工程に一直線に渡していく最も基本的な形です。

入力 → [工程1: 必要な情報を抽出] → [工程2: 構造化・整形] → [工程3: 文章を生成] → 出力

社内文書から該当箇所を抜き出し、それを要点の一覧に整え、最後に回答文として仕上げる、といった流れが典型です。Prompt Engineering Guide が例示している「文書から関連する引用を抽出し、その引用を根拠に回答を組み立てる」2 段構成も、この型に当たります。

この型の利点は、参照する情報量を工程が進むにつれて絞り込めることです。工程 1 で大きな文書から必要な箇所だけを抽出しておけば、工程 2 以降に渡すデータ量が小さくなり、後述する費用面でも有利に働きます。

分岐型｜入力を分類してから処理を振り分ける

最初の工程で入力の種類を判定し、その結果に応じて後続の処理を切り替える形です。

入力 → [工程1: 種別を分類] ─┬→ [経費精算用の処理]
                            ├→ [人事制度用の処理]
                            └→ [システム障害用の処理]

問い合わせ内容によって参照すべき規程も回答の書き方も異なる、という業務に向いています。前掲の Anthropic の記事でも、入力を分類して専門化された後続タスクへ振り分ける「ルーティング」がワークフローの型のひとつとして挙げられています。関心事を分離することで、それぞれに特化した指示文を用意できるのが利点です。

費用の観点では、分岐型は実行される工程数が入力によって変わる点が重要です。すべての分岐先を毎回通るわけではないため、平均的な工程数で試算する必要があります。

検証型｜生成→レビュー→修正で品質を担保する

いったん生成した結果を、別の工程でチェックし、問題があれば修正させる形です。

入力 → [工程1: 生成] → [工程2: 基準に照らして検証] → [工程3: 指摘に基づき修正] → 出力

顧客に出す文面、社外公開する文章、正確性が求められる要約など、誤りが許されない業務で使われます。検証工程で「問題なし」と判定されれば修正工程を飛ばす設計にすれば、実行される工程数を抑えられます。

ただし、この型は呼び出し回数が最も増えやすい型でもあります。「念のため検証を入れる」という判断は、そのまま費用の上乗せになるため、検証が本当に必要な業務かどうかは慎重に見極める必要があります。

プロンプトチェイニングのメリットとデメリット

ここまでの内容を、メリットとデメリットの形で整理します。ベンダー提案を評価する際は、右列のデメリットが自社の要件と衝突しないかを確認してください。

注目したいのは、メリットとデメリットが同じ原因から生まれていることです。「工程を分ける」という一つの判断が、精度の向上と費用・時間の増加を同時に引き起こします。したがって「分けるか分けないか」ではなく「どこまで分けるか」が実務上の論点になります。

業務での適用例｜問い合わせ回答・議事録からのタスク抽出・定型レポート

プロンプトチェイニングの例として、中堅企業でよく検討される 3 つの業務を挙げます。

社内問い合わせへの一次回答（逐次型） 「質問の意図を分類する → 関連する規程・マニュアルの該当箇所を抽出する → 回答文を生成する → 社内向けの表現規則に照らして整える」という 4 工程構成が典型です。単一プロンプトでは「規程に書かれていないことを答えてしまう」現象が起きやすいのに対し、抽出工程を分けることで根拠のない回答を減らせます。

議事録からのタスク抽出（逐次型 + 検証型） 「発言録から決定事項と依頼事項を抽出する → 担当者と期限を紐づける → 抜け漏れがないか検証する」という構成です。抽出結果を構造化データで受け渡すことで、そのままタスク管理ツールに登録できる形にできます。

定型レポートの作成（分岐型 + 検証型） 「対象データの種別を判定する → 種別ごとの分析観点で要約する → レポート形式に整形する → 数値の整合性を検証する」という構成です。数値を扱うため検証工程の価値が高く、費用増を正当化しやすい部類に入ります。

いずれのケースでも、工程数は 3〜4 が目安になっています。この妥当性については、のちほど工程数の判断基準として改めて扱います。

プロンプトチェイニングが費用に与える影響｜呼び出し回数とトークンの増え方

ここからが本記事の中心です。工程を分けると費用がどのように増えるのかを、要因ごとに分解して見ていきます。結論を先に述べると、呼び出し回数が 4 倍になっても費用が 4 倍になるとは限らず、設計次第で 2 倍台にも 4 倍近くにもなります。この幅を生む要因を理解することが、見積もりを検算する鍵になります。

費用が増える3つの要因｜呼び出し回数・入力の再送・出力トークン単価

LLM API の料金は、原則として「入力トークン量 × 入力単価 + 出力トークン量 × 出力単価」で決まります。トークンという単位そのものや、料金がどう積算されるかの基本はLLMのトークンとはで詳しく解説していますので、単位の理解に不安がある場合は先に目を通してください。この前提のうえで、チェイニングによって費用が押し上げられる要因は 3 つあります。

要因 1: 呼び出し回数そのものが工程数分だけ増える

最も分かりやすい要因です。4 工程に分ければ、1 件の処理につき 4 回の API リクエストが発生します。ただし後述するとおり、各リクエストで扱うトークン量は単発処理より小さくなるのが普通なので、費用が単純に 4 倍になるわけではありません。

要因 2: 各工程で共通の指示文や参照データを送り直すため、入力トークンが累積する

見落とされやすいのがこの要因です。各工程は独立した API リクエストなので、その工程が必要とする指示文・前工程の出力・場合によっては参照文書を、毎回改めて送る必要があります。前の会話を AI が覚えているわけではありません。

特に危険なのが、参照文書の全文をすべての工程に渡してしまう設計です。3,000 トークンの規程文書を 4 工程すべてに渡せば、それだけで 12,000 トークンの入力が発生します。本来は工程 1 で必要箇所を抽出し、以降は抽出結果（数百トークン）だけを渡せば済むはずのものです。この差が、費用が 2 倍台に収まるか 4 倍近くまで膨らむかの分かれ目になります。

要因 3: 出力トークンは入力より単価が高いモデルが多く、中間出力が積み上がると効く

多くの LLM API では、出力トークンの単価が入力トークンの数倍に設定されています。チェイニングでは各工程が中間結果を出力するため、最終成果物として読者の目に触れない中間出力にも課金が発生します。工程を増やすと、この中間出力の総量が積み上がっていきます。

まとめると、費用の増え方は次の式で捉えられます。

チェーン全体の費用（1 件あたり）
 = Σ（各工程の入力トークン × 入力単価）
 + Σ（各工程の出力トークン × 出力単価）

呼び出し回数は「Σ（合計）の項数」に、入力の再送は「各工程の入力トークン」に、中間出力は「各工程の出力トークン」に、それぞれ効いてきます。

概算の計算式と試算例｜単発処理と4工程チェーンの月次比較

具体的な数字を当てはめてみます。以下の単価はモデルによって大きく異なるため、あくまで考え方を示すための仮置きの数値として扱ってください。モデル別の実単価と詳細な試算手順はLLM API料金の計算方法で解説しています。

前提（仮置き）

• 業務: 社内問い合わせへの一次回答
• 月間処理件数: 3,000 件
• 入力単価: 100 万トークンあたり 3 ドル
• 出力単価: 100 万トークンあたり 15 ドル
• 為替: 1 ドル = 150 円

パターン A: 単発プロンプト（1 回の呼び出し）

1 件あたりの費用 = 4,000 × 3 ÷ 1,000,000 + 800 × 15 ÷ 1,000,000 = 0.012 + 0.012 = 0.024 ドル

パターン B: 4 工程チェーン（抽出結果だけを後続に渡す設計）

1 件あたりの費用 = 8,200 × 3 ÷ 1,000,000 + 2,300 × 15 ÷ 1,000,000 = 0.0246 + 0.0345 = 0.0591 ドル

パターン C: 4 工程チェーン（参照文書を全工程に渡してしまう設計）

1 件あたりの費用 = 17,200 × 3 ÷ 1,000,000 + 2,300 × 15 ÷ 1,000,000 = 0.0516 + 0.0345 = 0.0861 ドル

月次での比較（3,000 件）

この試算から読み取れることは 3 つあります。

呼び出し回数が 4 倍でも費用は 4 倍にならない：パターン B は呼び出しが 4 回に増えていますが、費用は約 2.5 倍にとどまっています。各工程が扱う情報量が単発処理より小さいためです。「工程数 = 費用倍率」という直感は、過大な見積もりになりがちです。

同じ工程数でも設計次第で 1.5 倍近い差が出る：パターン B と C の違いは、工程間で何を渡すかだけです。この差が月間で約 1 万 2,000 円、年間で約 15 万円の差になります。提案書の工程図を見るときは、工程数だけでなく各工程に何が入力されるかを確認してください。

絶対額としては数万円規模に収まることが多い：月 3,000 件の処理で数万円という水準は、担当者 1 名の作業時間削減効果と比べれば十分に正当化できる範囲です。ただしこれは処理件数の前提に強く依存します。件数が 10 倍になれば費用も 10 倍になるため、後述する「想定処理件数の前提確認」が重要になります。

レイテンシ（応答時間）への影響と業務要件との折り合い

費用と同じ構造で増えるのが応答時間（レイテンシ）です。工程は前の結果を待って実行されるため、待ち時間が積み上がります。Anthropic の記事も、プロンプトチェイニングを「レイテンシと引き換えに精度を得る」手法と位置づけています。

1 工程あたりの応答時間が 2〜5 秒だとすると、4 工程では 8〜20 秒程度になります。この差が許容できるかは、業務の性質によって判断が分かれます。

ここで実務的に有効なのが、リアルタイム性が必要な業務では非同期処理に切り替えられないかを検討することです。「質問を送信すると数十秒後に回答が通知される」形にできれば、応答時間の制約が外れ、精度重視の工程構成を選べるようになります。この設計変更は要件定義の段階でしか行えないため、提案を受けた早い段階で議論しておく価値があります。

費用を抑えるプロンプトチェイニングの設計ポイント

費用が増えることが分かったうえで、設計段階で圧縮できる余地を 4 つ紹介します。いずれも「何をするか」「どのくらい効くか」「発注時にどう確認するか」の 3 点で整理します。ここで扱う内容は、そのままベンダーへの質問リストとしても使えます。

工程ごとにモデルを使い分ける

何をするか：すべての工程を最高性能のモデルで処理する必要はありません。「質問の意図を 5 種類に分類する」「出力形式を整える」といった単純な工程は軽量・低価格のモデルで十分処理でき、判断が難しい生成工程だけを高性能モデルに任せる、という使い分けができます。

どのくらい効くか：主要な LLM プロバイダでは、軽量モデルと高性能モデルの単価差が 10 倍以上になることも珍しくありません。4 工程のうち 2 工程を軽量モデルに置き換えられれば、全体の費用を 3〜5 割程度圧縮できる可能性があります（効果はモデル構成と工程ごとのトークン配分によって変動します）。

発注時の確認方法：「各工程でどのモデルを使う想定ですか。分類や整形の工程も高性能モデルを使う設計になっていませんか」と尋ねてください。全工程が同一モデルになっている提案は、見直しの余地があるサインです。

プロンプトキャッシュを効かせる｜固定の指示文・参照文書を先頭に置く

何をするか：プロンプトキャッシュは、リクエストの先頭部分が前回と同一であれば、その部分の処理結果を再利用して入力トークンの課金を割り引く仕組みです。効かせるには、毎回変わらない内容（システム指示・共通ルール・参照文書）をプロンプトの先頭に置き、リクエストごとに変わる内容（ユーザーの質問・前工程の出力）を後ろに置くという配置が必要になります。

OpenAI のプロンプトキャッシュのドキュメントは「安定した開発者向け指示と共有の参照資料を先頭に置き、変化するコンテンツはブレークポイントより後に置く」ことを推奨しており、キャッシュの再利用には「レンダリングされたプレフィックス全体の一致が必要」と説明しています。Claude のプロンプトキャッシュのドキュメントも同様に、静的なコンテンツを先頭に配置し、変動するコンテンツをキャッシュ区切りより後ろに置くことを推奨しています。

どのくらい効くか：両ドキュメントによれば、キャッシュから読み出される入力トークンは通常の入力単価の 0.1 倍程度、一方でキャッシュへの書き込みは 1.25 倍程度の単価が適用されます。つまり同じ先頭部分を 2 回以上再利用できる場面では有利に働きます。ただしキャッシュが有効になる最小トークン数がモデルごとに定められており（1,024 トークン程度が一つの目安）、短い指示文だけでは効果が出ません。

発注時の確認方法：「共通の指示文や参照文書はプロンプトの先頭に固定配置し、プロンプトキャッシュが効く設計になっていますか」と確認してください。参照文書が毎回異なる業務ではキャッシュが効かないため、「効かない前提での試算になっているか」も併せて確認すると精度が上がります。

工程間で渡すデータを構造化して入力トークンを削る

何をするか：前掲の試算でパターン B と C の差を生んだ要因がこれです。工程間で受け渡すデータを、文書の全文ではなく「必要な項目だけを抜き出した構造化データ」にします。3,000 トークンの規程全文を渡す代わりに、抽出された該当条文 3 件（合計 400 トークン程度）を項目名付きで渡す、という形です。

どのくらい効くか：試算のとおり、参照文書を後続工程に渡すかどうかで月間費用に 1.5 倍近い差が生まれました。トークン削減の効果が最も大きく、かつ設計段階で確実にコントロールできる項目です。加えて、渡すデータを絞ることで後続工程の AI が余計な情報に引きずられなくなり、精度面でもプラスに働きます。

発注時の確認方法：提案書の工程図に「各工程への入力」が明記されているかを見てください。明記されていない場合は「工程 3 と工程 4 には、参照文書の全文が渡りますか、それとも抽出結果だけが渡りますか」と具体的に質問します。

早期終了・条件分岐で不要な工程を実行しない

何をするか：すべての入力に対して全工程を通す必要はありません。「工程 2 の検証で問題がなければ修正工程を実行しない」「対象外の問い合わせと判定されたら以降の工程に進まない」といった早期終了の条件を設けます。

どのくらい効くか：効果は入力データの分布に依存します。たとえば検証工程で 8 割が「問題なし」と判定される業務であれば、修正工程の実行回数は 2 割で済み、その工程分の費用は約 8 割削減されます。分岐型のチェーンでは、実行される平均工程数が設計上の最大工程数より小さくなるのが普通です。

発注時の確認方法：「見積もりの試算は、全件が全工程を通る前提ですか、それとも早期終了を織り込んだ平均値ですか」と確認してください。全件が全工程を通る前提であれば、それは安全側に振った見積もりということになり、実績はそれより下回る可能性があります。逆に平均値で見積もられている場合は、その前提となる比率の根拠を確認する必要があります。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

分割しすぎを防ぐ判断基準｜どこまで工程を分けるべきか

ここまで読むと「分けるほど良さそうだ」という印象を持たれるかもしれませんが、しかし実態はそうではありません。分割には初期開発工数・運用費用・応答時間という明確なコストがあり、分ける効果がそれを上回らない業務では単一プロンプトのほうが合理的です。

分けるべきケースと分けないほうがよいケース

自社の業務がどちらに当てはまるかを、以下の対比表で確認してください。

左列に多く当てはまるほど分割の価値が高く、右列に多く当てはまるほど単一プロンプトで十分ということになります。判断に迷う場合は、「この工程を分けることで、具体的にどの失敗パターンが防げるのか」を一言で説明できるかを基準にしてみてください。説明できない工程は、おそらく不要です。

工程数の決め方｜小さく始めて計測しながら増やす

工程数は最初から確定させるものではなく、運用しながら調整していくものです。実務的には次の進め方が現実的です。

第 1 段階: 2〜3 工程で始める まずは効果が明確な分割だけを行います。多くの業務では「必要な情報を絞り込む工程」と「成果物を生成する工程」の 2 分割だけで、単一プロンプトからの改善幅の大半が得られます。

第 2 段階: 失敗事例を分類する 運用データを見て、出力が期待どおりでなかったケースを分類します。「参照すべき箇所を取り違えた」「形式が守られなかった」「事実にない内容が混じった」など、原因のパターンごとに件数を数えます。

第 3 段階: 最も件数の多い失敗に対応する工程だけを追加する 分類結果のうち最も多い失敗パターンに対して、それを防ぐ工程を 1 つ追加します。追加後に同じ指標を測り、想定どおり減ったかを確認します。減っていなければ、その工程は費用と時間を消費しているだけなので撤去します。

この進め方の要点は、工程の追加を仮説検証として扱うことです。提案書に最初から 6 工程・7 工程が並んでいる場合は、「各工程がどの失敗を防ぐためのものか」「段階的に導入して効果を測る進め方は取れないか」を確認する価値があります。初期構成を絞り込めれば、開発費・運用費の両方を抑えられます。

エラー伝播を防ぐ中間検証の置き方

工程を分けると、前の工程の誤りが後続に連鎖するリスクが生まれます。工程 1 で誤った箇所を抽出してしまえば、以降の工程がどれだけ丁寧でも、誤った前提のうえで整った回答が出来上がってしまいます。むしろ「もっともらしく整っている」ぶん、誤りに気づきにくくなる面もあります。

これを防ぐ実務的な手立ては 3 つあります。

出力形式の機械的な検証：各工程の出力が、あらかじめ決めた構造（必要な項目がすべて存在するか、値の型は正しいかなど）を満たしているかをプログラムでチェックします。AI を追加で呼び出す必要がないため、費用はかかりません。最も費用対効果の高い対策です。

再試行と打ち切りの取り決め：形式検証に失敗した場合に同じ工程を再実行する回数の上限（たとえば 2 回まで）を決めておきます。上限に達したら処理を打ち切り、人に引き継ぐ設計にします。この上限がないと、失敗が続いたときに呼び出し回数が想定外に膨らみ、費用が跳ね上がる原因になります。

根拠の受け渡し：生成工程には結論だけでなく、その根拠となった抽出結果も併せて渡し、最終出力に根拠を添えさせます。人が最終確認する運用であれば、根拠が示されていることで誤りの発見が格段に容易になります。

発注時には「各工程の出力検証はどう行いますか」「再試行の上限は設けられていますか」の 2 点を確認してください。特に後者は、費用の上限管理に直結する項目です。

発注時に確認すべきプロンプトチェイニングの見積もり項目

最後に、AI 開発の運用コストを含む見積書・提案書を受け取ったときに確認すべき項目を整理します。ここまでの内容を、そのままチェックリストに落とし込んだものです。各項目に「なぜ聞くのか」を添えているので、社内説明の材料としても使えます。

初期開発費とAI利用料（変動費）が分けて書かれているか

確認すること：見積書のなかで、一度きりの開発費用（設計・実装・テスト）と、稼働後に毎月発生する AI 利用料が、別の行として分離されているか。

なぜ聞くのか：この 2 つは性質がまったく異なります。初期開発費は固定額として予算化できますが、AI 利用料は処理件数に比例して変動します。合算された「初期費用一式」という記載になっていると、稼働 2 年目以降にいくらかかるのかが読めません。稟議では通常、初年度費用と次年度以降のランニング費用を分けて示す必要があります。

あわせて確認したい点：AI 利用料の請求形態（ベンダー経由の立て替えか、自社が API プロバイダと直接契約するか）も確認してください。自社直契約であれば利用実績を自分で確認でき、透明性が高まります。

想定処理件数・トークン量・使用モデルの前提が明記されているか

確認すること：「月額 AI 利用料 ○ 万円」という金額に対して、その根拠となる (1) 月間の想定処理件数、(2) 1 件あたりの平均入力・出力トークン量、(3) 各工程で使用するモデル名、の 3 つが記載されているか。

なぜ聞くのか：この 3 つが揃って初めて、金額を検算できます。逆に言えば、どれか一つでも欠けていると、提示額が妥当かどうかを外部から判断する手段がありません。前掲の試算で示したとおり、同じ工程数でも設計次第で費用は 1.5 倍近く変わります。前提が明記されていない見積もりは、良し悪しではなく検証不能であることが問題です。

あわせて確認したい点：想定処理件数の根拠も尋ねてください。PoC の実績値なのか、現行業務の件数からの推計なのか、単なる仮置きなのかで、見積もりの信頼度が変わります。実績値がない場合は、稼働後 3 か月の実績を見て前提を見直す取り決めを入れておくと安全です。

費用上限と利用量の監視をどう取り決めるか

確認すること：(1) 想定件数を超えた場合の費用負担がどうなるか、(2) API 側で利用上限（月間の予算上限）を設定できるか、(3) 利用量を日次・週次で確認できる仕組みが構築に含まれているか。

なぜ聞くのか：従量課金で最も避けたいのは、想定を超えた利用が誰にも気づかれないまま月末を迎えることです。プログラムの不具合で同じ処理が繰り返し実行される、想定外の大量データが投入される、といった事態は起こり得ます。主要な API プロバイダは月間の利用上限設定や利用量の確認画面を提供しているため、それを使う運用が構築に含まれているかを確認してください。

あわせて確認したい点：異常な利用量を検知したときの通知先と対応手順（誰が気づき、誰が止めるのか）まで決まっているかを確認します。前述した工程の再試行上限も、この文脈で有効な安全装置です。

モデル変更・工程追加が発生したときの扱い

確認すること：(1) 使用モデルを別のモデルに切り替える場合の作業範囲と費用、(2) 稼働後に工程を追加・削除する場合の費用、(3) 特定のプロバイダの機能に強く依存した実装になっていないか。

なぜ聞くのか：LLM の分野はモデルの更新が速く、数か月単位で性能・価格の前提が変わります。稼働後に「より安いモデルに切り替えたい」「精度が足りないので工程を 1 つ足したい」という要望は高い確率で発生します。そのときの手続きと費用が決まっていないと、都度の追加見積もりに時間を取られ、機動的な改善ができません。

あわせて確認したい点：工程ごとの指示文（プロンプト）を、プログラムの改修なしに更新できる形にしておけるかも尋ねる価値があります。指示文の調整を自社側で行えれば、細かな改善のたびにベンダー作業が発生することを避けられます。

まとめ｜プロンプトチェイニングは「分ける効果」と「費用」を同じ天秤で判断する

プロンプトチェイニングは、タスクを複数のサブタスクに分割し、前工程の出力を次工程の入力として渡していく設計手法です。工程ごとに指示が単純になるため出力が安定し、中間結果を検証できるようになる一方で、LLM の呼び出し回数と入力トークンの再送が増え、応答時間も積み上がります。メリットとデメリットが同じ原因から生じているため、判断は「分けるかどうか」ではなく「どこまで分けるか」になります。

費用については、呼び出し回数が 4 倍でも費用が 4 倍になるとは限らないこと、そして同じ工程数でも工程間で渡すデータの設計次第で 1.5 倍近い差が生まれることが、本記事の試算から確認できました。工程数だけを見て高い・安いを判断するのではなく、各工程に何が入力されるのかまで踏み込んで確認することが、見積もりを読み解く勘所になります。

明日から実行できることとして、次の 3 ステップをおすすめします。

1. 自社の業務がどの連結パターンに当たるかを当てはめる：逐次型・分岐型・検証型のどれか、そして「分けるべきケースと分けないほうがよいケース」の対比表で左右どちらに多く当てはまるかを確認します。
2. 工程数を仮置きして概算する：想定処理件数と 1 件あたりのトークン量を仮置きし、月次費用を自分で計算してみます。桁が合っていれば、提示された金額の妥当性はおおよそ判断できます。
3. 見積書の 4 項目を確認する：初期開発費と AI 利用料の分離、前提（件数・トークン量・モデル）の明記、費用上限と監視、変更時の扱い。この 4 つが揃っていれば、その見積もりは検証可能です。

ベンダーの提案をそのまま受け入れるのでも、根拠なく疑うのでもなく、自分の側に判断軸を持ったうえで対話することが、AI 活用を継続的な投資として成立させる出発点になります。工程数と費用の関係を理解しておけば、稼働後に「もっと安くできないか」を議論する際にも、同じ物差しを使い続けることができます。

関連情報

生成 AI の業務適用を検討する際の進め方や、費用・体制の考え方をまとめた資料をお役立ち資料で公開しています。社内での検討材料としてご利用ください。

プロンプトチェイニングを含む AI 活用の要件整理や、受け取った提案・見積もりの妥当性の確認をご検討中の方は、お問い合わせフォームからご相談ください。要件が固まる前の段階からご相談いただけます。

費用の計算方法をさらに詳しく知りたい方は、あわせて以下の記事もご覧ください。

• LLMのトークンとは
• LLM API料金の計算方法
• AIオーケストレーションとは

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。