第1章 生成AIアプリケーション設計 / 想定学習時間:30〜40分 / 最終確認:2026年8月

1-5. マルチステージ推論パイプライン(Chain)の設計思想

🎯 この節の学習目標

1. チェーンとは何か

チェーン(Chain)とは、生成AIアプリケーションを構成する複数のコンポーネントを連結したパイプラインです。1回のLLM呼び出しで完結しない処理を、部品の直列・分岐の組み合わせとして設計します。主な部品は次のとおりです。

コンポーネント役割
プロンプトテンプレート入力変数を差し込んでプロンプトを組み立てる(1-4)
LLM推論・生成を実行する。ステージごとに異なるモデルでよい(1-2)
リトリーバー(検索)Databricks AI Search(旧 Vector Search) などで外部知識から関連文書を取得する
パーサーLLM出力を構造化データ(JSONなど)に変換・検証する
ツール外部API呼び出し、計算、データベース照会などLLM以外の処理

1-1で行った「要件→タスク分解」の結果を、実行可能な部品の列に落とし込んだものがチェーンです。試験ガイドの目標「望ましい入出力に合わせて適切なチェーンコンポーネントを選ぶ」「マルチステージ推論に必要なツールを定義し順序付ける」は、まさにこの設計作業を指しています。

2. なぜ分割するのか — マルチステージの利点

3. 代表的なチェーンパターン

パターン1 — 前処理 → 検索 → 生成 → 後処理

RAGアプリの基本形です。

  1. 前処理:ユーザー入力の整形、クエリの書き換え(検索に適した形への変換)
  2. 検索:AI Search で関連チャンクを取得
  3. 生成:検索結果をプロンプトテンプレートに差し込み、LLMで回答生成
  4. 後処理:形式検証、引用の付与、不適切出力のフィルタ

パターン2 — 分類によるルーティング(条件分岐)

まず入力を分類し、結果に応じて後段の処理を切り替えるパターンです。例:問い合わせを「技術質問/請求質問/雑談」に分類し、技術質問は技術文書のRAGへ、請求質問は請求システム照会へ、雑談は軽量モデルの直接応答へ振り分ける。段ごとに専用のプロンプト・データソース・モデルを使えるため、単一の巨大プロンプトより品質と効率が上がります。

パターン3 — 逐次要約(長大入力の分割処理)

コンテキストウィンドウに収まらない長文を扱うパターンです。文書をチャンクに分割し、チャンクごとに要約 → 部分要約を統合してさらに要約、と段階的に圧縮します。「検索では拾いきれない文書全体の総括が必要」な場合に、RAGではなくこちらを使います。

💼 例:問い合わせ対応チェーンの全体像

「顧客メールに、社内ナレッジを根拠とした返信案を作る」要件のチェーン設計:

  1. メール本文から質問部分を抽出(LLM・小型)
  2. カテゴリ分類(LLM・小型)→ カテゴリに応じて分岐
  3. 該当カテゴリのナレッジベースを検索(リトリーバー)
  4. 返信案を生成(LLM・大型、引用付きを指示)
  5. 出力の形式検証と禁止表現チェック(パーサー+ガードレール)

順序に注意してください。検索は生成の前(根拠を文脈に入れるため)、検証は生成の後(出力を確かめるため)です。試験ではこの「正しい順序の選択」がそのまま設問になります。

4. マルチステージの欠点と対策

欠点内容対策
レイテンシの積み上げ各ステージの処理時間が合算される各段を小型・高速モデルにする、独立した処理は並列化、不要な段の削減
コストの積み上げLLM呼び出し回数が増えるLLMが不要な段はルールベース処理に置き換える、小型モデルの活用
エラー伝播前段の誤り(誤分類・検索ミス)が後段に波及し、最終出力を壊すステージ間の検証、信頼度が低い場合のフォールバック(人間へのエスカレーション等)
複雑性の増加構成要素が増え、管理・デバッグ対象が増える要件を満たす最小のステージ数にとどめる。トレーシングで可観測性を確保

原則はモデル選定(1-2)と同じで、「要件を満たす最小の構成」です。1回の呼び出しで品質要件を満たせるなら、チェーンにする必要はありません。

5. 実装への接続

本節で学んだのは設計思想です。実装は第3章で扱います。

📝 試験のポイント

試験では「この要件のパイプラインに必要なコンポーネントと順序はどれか」という並べ替え型の設問がよく問われます。鉄則は3つ:(1)検索(retrieval)は生成の前(2)検証・ガードレールは生成の後(または各ステージ間)、(3)分類でルーティングするなら分類は分岐の前。また「単純なタスクに多段チェーンを組む」選択肢は過剰設計として誤答になります。

✅ この節のまとめ

練習問題

問1. 「社内規程に基づいて質問に答え、回答前に機密情報が含まれていないか確認する」チェーンを設計する。コンポーネントの順序として最も適切なのはどれか。

  1. LLM生成 → 規程文書の検索 → 機密情報チェック
  2. 規程文書の検索 → LLM生成 → 機密情報チェック
  3. 機密情報チェック → LLM生成 → 規程文書の検索
  4. LLM生成 → 機密情報チェック → 規程文書の検索
解答と解説を見る

正解:B

検索は生成の前(検索結果を根拠として文脈に入れるため)、出力の検証は生成の後(生成された回答を確かめるため)という2つの鉄則どおりの順序はBだけです。A・Dは生成後に検索しており根拠を文脈に使えません。Cは存在しない出力を先にチェックしようとしており成立しません。

問2. 問い合わせボットで、技術的な質問には技術文書のRAGを、料金の質問には料金データベースの照会を使いたい。この分岐を実現するチェーン設計として最も適切なのはどれか。

  1. すべての問い合わせに対して技術文書と料金DBの両方を常に照会し、結果を全部LLMに渡す
  2. まず問い合わせを分類するステージを置き、分類結果に応じて後段の処理をルーティングする
  3. ユーザーに問い合わせの種類を10項目のフォームで事前入力させる
  4. ランダムにどちらかの処理を選ぶ
解答と解説を見る

正解:B

入力の種類によって後段処理を切り替える要件は、分類→ルーティングのパターンそのものです。Aは毎回両方を照会するため不要なコスト・レイテンシが発生し、無関係な文脈が品質を下げる恐れもあります。Cはユーザー体験を損ない、そもそも分類はLLMが得意とするタスクです。Dは要件を満たしません。

問3. マルチステージチェーンの導入を検討する際の説明として、最も適切なのはどれか。

  1. ステージ数は多いほど品質が上がるため、可能な限り細かく分割すべきである
  2. 分割すると各段の最適化や途中検証が可能になる一方、レイテンシ・コストの積み上げとエラー伝播のリスクがあるため、要件を満たす最小構成にする
  3. チェーンにするとLLMの呼び出し回数が減るため、常に単一呼び出しより低コストである
  4. チェーンでは途中にガードレールを挿入できないため、安全性は単一呼び出しより低い
解答と解説を見る

正解:B

マルチステージの利点(段ごとの最適化・途中検証・デバッグ容易性)と欠点(レイテンシ・コスト積み上げ、エラー伝播)を正しくまとめたのはBです。Aは過剰分割でコスト・複雑性が増すだけです。Cは逆で、呼び出し回数は通常増えます。Dも逆で、途中にガードレールを挿入できるのはチェーンの利点です。

問4. 500ページの年次報告書の「全体を通した総括サマリー」を作りたい。文書はモデルのコンテキストウィンドウに収まらない。最も適切なアプローチはどれか。

  1. AI Searchで上位3チャンクだけを検索し、それを要約する
  2. 文書をチャンクに分割してそれぞれ要約し、部分要約を統合して最終サマリーを作る逐次要約チェーンを使う
  3. 報告書の最初の10ページだけを要約する
  4. ファインチューニングで報告書の内容をモデルに記憶させる
解答と解説を見る

正解:B

「文書全体の総括」が必要な場合は、逐次要約(分割要約→統合)が適切です。Aの検索ベースの手法は特定の質問に関連する部分を拾うのには向きますが、上位数チャンクでは全体の網羅ができません。Cは大部分の情報を捨ててしまいます。Dのファインチューニングは知識の注入に不向きで、1文書の要約のためには過剰かつ不確実です(1-6で詳述)。