Databricks Certified Generative AI Engineer Associate 教科書
第1章 生成AIアプリケーション設計(Design Applications, 14%)
🎯 この節の学習目標
エージェント(Agent)とは、LLMが推論しながらツール(検索、API、関数、コード実行など)を自ら選択・呼び出して目標を達成するアーキテクチャです。1-5で学んだチェーンとの本質的な違いは、処理の流れを誰が決めるかにあります。
| 観点 | 固定チェーン | エージェント |
|---|---|---|
| 処理の流れ | 開発者が設計時に固定(分岐もあらかじめ定義) | LLMが実行時に動的に計画・分岐 |
| ステップ数 | 設計時に決まっている | 目標達成まで可変(観察→判断→行動を繰り返す) |
| 予測可能性・デバッグ | 高い(毎回同じ経路) | 低め(実行のたびに経路が変わりうる) |
| コスト・レイテンシ | 見積もりやすい | 変動しやすい(試行回数に依存) |
| 向くタスク | 手順が事前に定義できる定型処理 | 手順が入力によって変わる、動的なツール選択・多段の意思決定が必要な処理 |
エージェントの基本ループは「目標の理解 → 次の行動の推論 → ツールの呼び出し → 結果の観察 → (達成まで繰り返し) → 最終回答」です。どのツールを、どの順番で、何回使うかを実行時にLLM自身が決める点が、固定チェーンにない能力です。
エージェントを支える基礎技術がツール呼び出し(function calling)です。仕組みは次のとおりです。
重要なのは、LLM自身はツールを実行しないという点です。LLMは「どう呼ぶか」の判断と要求の生成だけを行い、実行はアプリ側の責務です。また、LLMがツールを正しく選べるかどうかはツールの説明文の品質に大きく依存します。ツール定義は「LLMに読ませるドキュメント」として、用途・使いどころが明確に伝わるよう書きます。
💼 例:経費精算アシスタントのツール定義
search_expense_policy(query) — 経費規程から関連ルールを検索する。規程の確認が必要なときに使う。get_expense_history(employee_id, month) — 指定従業員の月次経費履歴を取得する。calculate(expression) — 数値計算を正確に行う。合計・按分の計算に使う。「先月の出張経費が規程の上限を超えていないか確認して」という依頼に対し、エージェントは「履歴取得 → 規程検索 → 計算 → 判定を回答」という手順を自分で組み立てて実行します。この手順は開発者が固定したものではなく、依頼内容が変わればツールの組み合わせも変わります。
Databricks は、エージェントを宣言的に(=実装コードを一から書くのではなく、達成したいタスクとデータを指定する形で)構築できる仕組みとして Agent Bricks を提供してきました。2026年時点の Agent Bricks は、この宣言型構築機能にとどまらず、Databricks の AI ケイパビリティ全体を包括する領域へと拡張されています。構成要素は次のとおりです。
| 構成要素 | 役割 |
|---|---|
| Agent(本体) | 推論しながらツールを選択・呼び出す主体。MLflow の ResponsesAgent インターフェースで実装・記録するのが現行の標準 |
| Tools | エージェントが呼び出す道具。Unity Catalog 関数(UC関数)として登録するものと、コードで定義するカスタムツールがある |
| AI Search | 非構造化文書のベクトル検索基盤。RAG・文書QAにおける検索ツールとして機能する |
| Genie Agent | 構造化データ(テーブル)への自然言語問い合わせを担当するエージェント。「先月の地域別売上は?」のような質問をクエリに変換して回答する |
| MCP(Model Context Protocol) | ツール統合の標準プロトコル。マネージドMCPサーバーを通じて AI Search や Genie、UC関数などを共通の作法でエージェントに接続できる |
| Supervisor Agent | 複数のエージェントを統括し、要求内容に応じて適切なエージェントへタスクを振り分けるマルチエージェントの統括役 |
そのうえで、Agent Bricks にはユースケース別のテンプレートが用意されており、達成したいタスクとデータを指定するだけで、上記の構成要素を組み合わせたエージェントを構築できます。
| ユースケース | 内容 | 典型シナリオ |
|---|---|---|
| Information Extraction | 非構造化文書から構造化データを抽出する | 契約書・請求書・報告書の項目抽出をスキーマ指定で自動化 |
| Knowledge Assistant | 社内文書に基づく質問応答アシスタント | 社内ナレッジQAボット(RAGベース)を迅速に構築。検索基盤には AI Search を利用 |
| Multi-Agent Supervisor | 複数エージェントを統括し、適切なエージェントへタスクを振り分ける | 文書QA担当(Knowledge Assistant)とデータ分析担当(Genie Agent)を束ねた統合アシスタント。Supervisor Agent の実現形 |
設計上のポイントは、これらが1-1〜1-6で学んだ要素(タスク分解、RAG、構造化抽出、ルーティング)のマネージドな実現形だということです。たとえば Knowledge Assistant はRAGパターンを AI Search の上に実現したもの、Multi-Agent Supervisor は「分類によるルーティング」(1-5)をエージェント間に拡張したものと整理できます。要件がこれらの定型ユースケースに合致するなら、独自実装より宣言的な構築の方が開発・運用コストを抑えられます。
構成要素どうしの関係を、エージェント型アプリケーションの現行の標準的な構成として1枚の図にまとめます。
図:エージェント型アプリケーションの現行標準アーキテクチャ
この構成全体を横断して支えるのが、MLflow 3(トレーシングと評価:エージェント実行の各ステップを記録し、品質を測定する)と Unity AI Gateway(ランタイムガバナンス:ポリシー・ガードレール・利用量の統制)です。エージェント本体だけでなく、ホスティング(Databricks Apps)・観測(MLflow 3)・統制(Unity AI Gateway)までを一体で設計するのが現行の考え方です。
エージェントは強力ですが、実行経路が動的である分、コスト・レイテンシの予測が難しく、デバッグ・評価も複雑になります。設計判断の原則はこれまでと同じで、「要件を満たす最小の構成」です。
📝 試験のポイント
「マルチステージ推論に必要なツールを定義し順序付ける」という試験ガイドの目標に関連して、固定的な手順ならチェーン、動的なツール選択・分岐ならエージェントという対応付けが問われます。また、function calling では「ツール名・説明・引数スキーマをLLMに渡し、LLMは呼び出しの判断と引数生成を行う(実行はしない)」という役割分担を正確に覚えてください。「LLMがAPIを直接実行する」という選択肢は誤答です。
本節はエージェントの設計概念と全体像までを扱いました。実装・運用の詳細は第3章・第4章で学びます。
また、エージェントの評価・トレーシング(意図した通りにツールを選べているか)は第5章、ツールに与える権限の統制やランタイムガバナンスは第6章のテーマにつながります。
✅ この節のまとめ
問1. 固定チェーンではなくエージェント型アーキテクチャを選ぶべき状況として、最も適切なのはどれか。
正解:B
ツールの選択・組み合わせ・順序が入力によって動的に変わる要件はエージェントの適用場面です。A・C・Dはいずれも手順が事前に固定できる定型処理であり、固定チェーン(または単一呼び出し)の方が予測可能でコスト・品質管理も容易です。
問2. ツール呼び出し(function calling)の仕組みに関する説明として正しいのはどれか。
正解:B
function calling の役割分担を正しく述べています。Aは誤りで、LLMは呼び出し要求を生成するだけで実行はしません。Cは誤りで、説明文の品質はLLMのツール選択精度を大きく左右します。Dは誤りで、ツール呼び出しに対応したモデルであれば追加のファインチューニングは不要です。
問3. 経営企画部門から「売上テーブルに対して『先月の地域別売上を教えて』のように自然言語で問い合わせたい」という要望があった。Agent Bricks の構成要素として最も適合するのはどれか。
正解:C
Genie Agent は構造化データ(テーブル)への自然言語問い合わせを担当する構成要素です。Aは非構造化文書からの構造化抽出、Bは社内文書(非構造化データ)に基づくQAであり、対象データの種類が異なります。Dは複数エージェントの統括役で、単一の要件しかない本問では過剰です。
問4. 「社内文書のQA」と「業績データの自然言語分析」の両方に1つの窓口で応えるアシスタントを作りたい。それぞれの機能は個別のエージェントとして構築済みである。最も適切な構成はどれか。
正解:B
構築済みの複数エージェントを統括し、要求に応じて振り分けるのは Supervisor Agent(テンプレートとしては Multi-Agent Supervisor)の典型ユースケースです(1-5のルーティングパターンのエージェント版)。Aは既存資産を捨てたうえ、性質の異なるタスクの同居で品質が下がります。Cは無関係な回答が混ざりコストも倍増します。Dは「1つの窓口で」という要件を満たしません。
問5. MLflow の ResponsesAgent インターフェースで実装したエージェントを、社内ユーザー向けのWebアプリケーションとして提供したい。エージェントアプリのホスティング先として、現行の Databricks で推奨される構成はどれか。
正解:B
現行の標準アーキテクチャでは、エージェントアプリのホスティング先として Databricks Apps が推奨されます。プラットフォーム内でホスティングすることで、Unity Catalog の権限管理や Unity AI Gateway による統制、MLflow 3 によるトレーシングと一体で運用できます。Aは可用性・ガバナンスの面で本番提供に不適切です。Cはエージェントを介さず検索基盤を直接公開する構成で、要件を満たしません。Dは対話型アプリではなくバッチ処理の仕組みです。