Databricks Certified Generative AI Engineer Associate 教科書
第3章 アプリケーション開発(Application Development, 30%)
🎯 この節の学習目標
MCP(Model Context Protocol)は、LLMアプリケーション(エージェント)とツール/データソースを、標準化されたプロトコルでつなぐ仕組みです。Anthropic が公開したオープン標準で、特定のベンダーやフレームワークに依存しません。
MCPがない世界では、エージェントに新しいツールを追加するたびに、そのエージェントのコードにツールごとの接続処理を個別に実装する必要がありました。エージェントがN個、ツールがM個あれば、最悪 N×M 通りの統合コードが必要です。MCPは、この接続部分を共通のプロトコルに標準化します。よく「AI版のUSBのような共通コネクタ」と説明されるのはこのためです。
| 登場人物 | 役割 |
|---|---|
| MCPサーバー | ツールやリソース(データ)を公開する側。「どんなツールがあるか」「どう呼ぶか」をプロトコルに従って提供する |
| MCPクライアント | エージェント側。サーバーに接続してツール一覧を発見(discover)し、必要に応じて呼び出す |
重要なのは、クライアントがサーバーのツール一覧を実行時に発見できることです。エージェントのコードにツールを1つずつハードコードしなくても、サーバーが公開するツール群をまとめて利用できます。
3-9 ではエージェントのコード内でツールを定義しました。MCPは、そのツールの実装をエージェントの実装から切り離します。利点は次の3つです。
📝 試験のポイント
MCPについては、まず「何を標準化するものか」を一言で答えられることが重要です。答えは「LLMアプリケーション(エージェント)とツール/データソースの接続方法」です。モデルの重み形式や学習手順、プロンプトの書式を標準化するものではありません。
Databricks は、プラットフォーム上の主要な機能をマネージドMCPサーバーとして公開しています。自分でサーバーを実装・運用しなくても、Databricks 上の資産をMCP経由でエージェントのツールにできます。
| マネージドMCPサーバー | ツールとして公開されるもの | エージェントができること |
|---|---|---|
| AI Search | AI Search インデックスの検索 | 社内ドキュメントの意味検索(RAGの検索ステージ) |
| Unity Catalog 関数 | UCに登録したSQL/Python関数(3-9) | ガバナンス管理されたビジネスロジックの実行 |
| Genie スペース | Genie による構造化データへの自然言語問い合わせ | 売上・在庫などのテーブルデータへの質問応答 |
これらは Unity Catalog の権限管理の下で動作するため、「誰が(どのエージェントが)どのデータ・関数にアクセスできるか」というガバナンスを保ったままツール統合ができます。さらに、独自のツール群を公開するカスタムMCPサーバーを作る場合は、Databricks Apps 上でホストできます。
3-9 のエージェントのツール群を、MCP経由で供給する構成は次のようになります。
構成例:社内アシスタントエージェント
ユーザーの質問を受けたエージェントは、発見済みのツール一覧から適切なものを選び(function calling)、MCPのプロトコルで呼び出し、結果をもとに回答します。
この構成では、たとえばチケットシステムのAPI仕様が変わっても、修正するのはカスタムMCPサーバーだけで、エージェント本体には手を入れません。また、新しいエージェントを作るときも、既存のMCPサーバー群に接続するだけでツールがそろいます。
MCPは3-9で学んだツール定義・function callingを置き換えるものではなく、供給経路を標準化するものです。ツールに名前・説明・引数スキーマがあること、LLMがツール呼び出しをJSONで出力し実行結果を受け取ること(ReActループ)は変わりません。変わるのは「ツールがどこで定義・実行され、どうやってエージェントに届くか」です。
| 観点 | コード内ツール(3-9) | MCP経由のツール(この節) |
|---|---|---|
| ツールの定義場所 | エージェントのコード内 | MCPサーバー側 |
| ツールの追加・変更 | エージェントのコード修正が必要 | サーバー側の変更のみ。クライアントは発見し直すだけ |
| 複数エージェントでの共有 | コードのコピーや共通ライブラリ化が必要 | 同じサーバーに接続するだけ |
| ツール選択・実行ループ | 共通(function calling / ReActループ。3-9と同じ) | |
試験対策としては、次の2点を確実に押さえてください。
✅ この節のまとめ
問1. MCP(Model Context Protocol)が標準化するものとして最も適切なのはどれか。
正解:B
MCPはエージェントとツール/データソースをつなぐ接続方法(ツール統合)を標準化するオープンプロトコルです。Aのモデル形式、Cのプロンプト文法、Dのインフラ通信はいずれもMCPの対象外です。「モデル」という語が入っていても、モデルの中身ではなくモデルに文脈(ツール・データ)を供給する経路の標準であることに注意してください。
問2. MCPにおけるサーバーとクライアントの役割分担として正しいのはどれか。
正解:B
MCPサーバーはツール・リソースの提供側、MCPクライアントはエージェント側で、ツールの発見(discovery)と呼び出しを行います。Aは役割が逆です。Cのような制約はなく、分離されているからこそ再利用性が生まれます。Dは誤りで、実行時にサーバーからツール一覧を発見できることがMCPの利点です。
問3. Databricks のマネージドMCPサーバーを通じてエージェントのツールとして公開できるものの組み合わせとして、最も適切なのはどれか。
正解:A
Databricks のマネージドMCPサーバーは、AI Search(意味検索)、Unity Catalog 関数(登録済みビジネスロジック)、Genie スペース(構造化データへの自然言語問い合わせ)をエージェントのツールとして公開できます。B・C・Dはいずれもプラットフォームの内部機構や管理情報であり、エージェントのツールとしてMCPで公開する対象ではありません。
問4. 社内チケットシステムのAPIを複数のエージェントから共通のツールとして使えるようにしたい。ツールの実装をエージェントから分離し、Databricks 上でホストする方法として最も適切なのはどれか。
正解:B
独自ツールの共有には、カスタムMCPサーバーとして公開し Databricks Apps でホストする構成が適切です。API仕様の変更もサーバー側の修正だけで済みます。Aは実装の重複でMCPの利点(分離・再利用)を放棄しています。Cはアクセス制御を失う危険な設計です。Dは認証情報の漏えいリスクが重大で、そもそもLLM自身はAPIを直接実行できません(実行はアプリケーション側の役割。3-9)。