Databricks Certified Generative AI Engineer Associate 教科書
第3章 アプリケーション開発(Application Development, 30%)
🎯 この節の学習目標
3-9 で学んだとおり、エージェントはLLMがツール定義を読んで「どのツールを使うか」を判断します。この構成は、ツールが増えるほど次の問題に直面します。
| 問題 | 内容 |
|---|---|
| ツール選択精度の低下 | 選択肢が増えるほど、似た説明のツールを取り違えたり、不要なツールを呼んだりする確率が上がる |
| 責務の混在 | 1体のエージェントに「文書検索も、データ集計も、情報抽出も」と役割を詰め込むと、システムプロンプトが肥大化し、どの役割の指示も中途半端になる |
| 改善・評価の難しさ | すべてが1体に混在していると、「データ集計の精度だけ改善したい」ときも全体に手を入れることになり、影響範囲を切り分けにくい |
この解決策が、役割ごとに専門エージェントへ分割し、上位のエージェントが振り分けるマルチエージェント構成です。1体あたりのツールと指示が絞られるため判断が安定し、担当ごとに独立して改善・評価できるようになります。
マルチエージェントの代表的な構成が Supervisorパターンです。統括役の Supervisor Agent がユーザー要求を解釈し、適切な専門エージェントへルーティングして、返ってきた結果を統合して最終回答をまとめます。専門エージェントの典型例は次のとおりです。
図:Supervisorパターン。下層のFoundation Model APIが各エージェントの推論を支え、Unity AI Gateway(ガバナンス)とMLflow 3(トレーシング)が横断的に全体を統制・追跡する
💡 具体例:社内総合アシスタント
ある製造業の企業(架空)が、社員向けの総合アシスタントを1つの窓口で提供するとします。「出張旅費の精算ルールは?」という質問は Knowledge Assistant(規程文書の検索)へ、「今月の部門別経費の合計は?」は Genie Agent(経費テーブルの集計)へ、「この請求書PDFから金額と支払期日を抜き出して」は Information Extraction へ、と Supervisor が振り分けます。ユーザーはどのエージェントが動いたかを意識せず、1つの会話で多様な要求を処理できます。
📝 試験のポイント
「性質の異なる複数の業務(文書QA・データ集計・抽出)を1つの窓口で処理したい」「単一エージェントのツールが増えて精度が落ちた」という問題では、役割別エージェント+Supervisorによるルーティングが正解の軸になります。すべてのツールを1体に持たせ続ける選択肢は、根本原因(選択肢過多)を解消しません。
Databricks では、このSupervisorパターンを Agent Bricks の Multi-Agent Supervisor として公式に提供しています。ポイントは宣言的(declarative)に構成できることです。ルーティングのコードを自分で書く代わりに、次を指定するだけでスーパーバイザー構成が作られます。
なお、Agent Bricks は個別のエージェント構築機能の集まりから発展し、2026年時点では Databricks の AI 機能全体を包括する領域として位置づけられています(1-7参照)。Multi-Agent Supervisor はその中で「複数エージェントの統括」を担う構成要素です。
💡 具体例:宣言的な構成のイメージ
コンソール上で Multi-Agent Supervisor を作成し、(1) 文書QA用の Knowledge Assistant、(2) 売上分析用の Genie スペース、(3) 社内API連携用のカスタムエージェント、の3つを登録します。それぞれに「規程・マニュアルに関する質問を担当」「売上・注文データの集計質問を担当」「在庫システムの照会を担当」という説明文を書けば、ルーティングロジックのコードを書かずにスーパーバイザー構成が完成します。3-9 の「ツールの説明の質が精度を決める」と同じ原理で、この説明文の質がルーティング精度を決めます。
マルチエージェントは強力ですが、増やすほど良いわけではありません。実務・試験の両面で、次の指針を押さえます。
| 指針 | 理由 |
|---|---|
| エージェント数は最小限にする | 担当が増えるほどSupervisorの振り分け精度が下がり、遅延とコストも増える。役割が明確に異なるときだけ分割する |
| 各エージェントの説明文を磨く | 説明文はSupervisorのルーティング判断の材料そのもの。「何を担当し、どんな質問を任せるべきか」を具体的に書く |
| 共有メモリ/会話履歴の受け渡しを設計する | 担当をまたぐ会話では、前の文脈(会話履歴や中間結果)を引き継がないと一貫した回答ができない。何をどこまで共有するかを決めておく |
| エラー時のフォールバックを用意する | 担当エージェントの失敗やタイムアウト時に、別の手段で再試行するか、「わからない」と誠実に返すかをあらかじめ設計する |
また、マルチエージェントは処理が複数のエージェント・ツールにまたがるため、「どこで品質が落ちたのか」を特定する仕組みが単一エージェント以上に重要です。MLflow 3 の Tracing を使うと、Supervisorのルーティング判断、各担当エージェントのツール呼び出し、中間の入出力といった全ステップをトレースとして追跡でき、評価・デバッグの起点になります(詳細は 5-6)。
📝 試験のポイント
「マルチエージェントの応答品質が低下したが、どの担当エージェントに原因があるか分からない」という問題では、MLflow 3 の Tracing で各ステップの入出力を追跡するが正解の軸になります。また、ルーティング精度の改善では、モデル変更より先に各エージェントの説明文の見直しを検討します。
✅ この節のまとめ
問1. 単一エージェントに10種類以上のツールを持たせたところ、ツールの取り違えが増え、応答品質が不安定になった。根本原因に対処する設計変更として最も適切なのはどれか。
正解:B
ツール過多による選択精度の低下には、役割別エージェントへの分割とSupervisorによるルーティングが定石です。1体あたりの選択肢が減り、判断が安定します。Aはプロンプトの肥大化を進めるだけで選択肢過多という根本原因が残ります。Cはばらつきを抑えても誤った選択自体は直りません。Dは外部データ・機能へのアクセスを失い、要件を満たせなくなります。
問2. Supervisorパターンにおける Supervisor Agent の役割として正しいのはどれか。
正解:B
Supervisorの役割は「解釈・ルーティング・統合」です。実際の処理(検索・SQL実行など)は各専門エージェントが担います。Aはツールを1体に集めることになり、分割の利点を失います。CはSupervisorがLLMの判断で柔軟に振り分ける点を見落としています(固定ルールなら通常のチェーンで足ります)。Dはパターンの役割とは無関係です。
問3. 「規程文書へのQA」「売上テーブルの集計」「請求書からの項目抽出」を1つの窓口で提供するため、Databricks 上で複数の担当エージェントを束ねたスーパーバイザー構成を、ルーティングのコードを書かずに構築したい。最も適切な方法はどれか。
正解:A
Multi-Agent Supervisor は、担当エージェントの登録と説明文の記述によって宣言的にスーパーバイザー構成を作れる公式機能で、「コードを書かずに」という要件に合致します。BはGenieが構造化データ専用であり、文書QAや抽出を担えません。Cは実現可能ですが「コードを書かずに」という要件に反し、開発・保守コストも大きくなります。Dは「1つの窓口で」という要件を満たしません。
問4. 運用中のマルチエージェントで応答品質の低下が報告されたが、Supervisorのルーティングと各担当エージェントのどこに原因があるか特定できていない。原因調査の起点として最も適切なのはどれか。
正解:B
複数エージェントにまたがる処理の原因特定には、全ステップを可視化するトレーシングが起点になります。MLflow 3 の Tracing はルーティング判断や各ツール呼び出しの入出力を記録し、どの段階で品質が落ちたかを切り分けられます(5-6参照)。Aは原因不明のまま変更するとかえって切り分けが難しくなります。Cは原因を放置したまま構成を複雑にするだけです。Dは調査ではなく、サービス停止という別の判断です。