Enterprise-Grade MCP on Databricks: A Practical Walkthroughの翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
AIツールに関する領域における最新のバズワードであるMCPについて興味を持っているのであれば、すでにそれがAnthropicによって開発され、2024年後半にオープンソース化されたことを知っているでしょう。「AIエージェントのUSB-C」と説明されているのを見かけたり、いくつかのエージェントアプリケーションを構築したりしながらも、依然としてMCPがストーリーをどのように変革するのかを不思議に思っているかもしれません。この記事では、MCPのレイヤーを掘り下げ、提供するコアに到達します。特にDatabricksの利用者であるあなたにとって何を意味するのかを説明します。
MCPとは？
Model Context Protocol (MCP)は、大規模言語モデルに対するコンテキストを提供するプロトコルを定義します。 データベース、API、システムのようなツールとAIエージェントの間での一貫性があり信頼できるやり取りを支援するオープン標準です。
以下の一般的なMCPのアーキテクチャからスタートしましょう。後のセクションでは、Databricksバージョンをウォークスルーします。
右側には、データベースやSaaSアプリケーションから提供されるであろうデータ資産を見ることができます。これらは、MCPサーバーに接続されたツールを通じてアクセスされます。MCPサーバーは、あなたが定義したロジックを実行するコンピュートレイヤーとして動作します。
図の左側には、MCPにリクエストを送信するエージェントであるMCPクライアントがあります。例えば、エージェントが「やあ、MCPサーバー、ベクトルサーチインデックスを用いて類似した取引を取ってきてくれない？」とお願いすると、サーバーは結果を伴うレスポンスを返却します。これらは、構造化されたリクエストとレスポンスを通じてコミュニケーションします。MCPのプロトコルは、一貫性があり標準化された方法で、リクエストとレスポンスを解釈、整形することを保証します。
なぜ、MCPが必要なのか？
MCPが必要な大きな理由が2つあります。
はじめに、これは一般的な問題に対応します: ツールの利用は扱いにくく一貫性がありません。この課題は、LLM開発者とアプリケーションエンジニアの両方に影響を与えます。Anthropicは内部でこの障害に直面し、これを解決するために、最終的にはMCPになる標準化された中間レイヤーを作成しました。
次に、業界はすべてのユースケース、トークン消費の半分以上がループでツールを繰り返し呼び出すエージェントからもたらされる未来に向かっています。一貫性の改善につながるツールの定義方法、呼び出し方法を標準化することで、効率性の改善につながり、最終的にはビジネス価値を向上させます。
ツールを呼び出す一貫性のないエージェント (ソース)
例えば、MCPがない場合、異なるチームが同じ天気APIを呼び出しますが、あるものはJSONオブジェクト、べつのものは平文、さらにべつのものはpandasデータフレームのように完全に異なるフォーマットで結果を返すというケースがあり得ます。この一貫性の欠如は、さまざまなフォーマット、異なるプログラミング言語にさえも対応しなくてはならない、お使いのLLMに大きな負荷を与えることになります。小規模なモデルは苦戦、場合によっては整合性のない結果を返却する場合があり、ツールの標準化において多大な苦痛を伴うことになります。
課題はこれだけではありません。LangGraphのような別のプラットフォームにおいては、すべてのコードに目を通すか、個別のドキュメントを管理することなしに、利用可能なすべてのツールの一覧や説明を取得する簡単な方法は存在しません。ガバナンスは複雑性のレイヤーを追加します。逆に、Databricksの利用者はこれらの問題を完全に回避します。ツールはネイティブにUnity Catalogにインテグレーションされ、サービスプリンシパルによって一貫性持って管理されます。
これら全ては、MCPのような標準なしにはツール管理は大変で非効率なものになりうるのかを示しています。開発を遅延させ、エラーが増加し、本番運用を長期化させます。
なぜ、Databricks上のMCPなのか？
MCPは強力なコミュニティのモメンタムを持つオープンで一貫性のあるプロトコルを提供しますが、エンタープライズにおけるユースケースは多くの場合、堅牢なガバナンス、セキュアなアクセス、大規模な運用の効率性のような追加のレイヤーを必要とします。
ここで、Databricksが活躍します。信頼できるインフラストラクチャのサポートによって、AIエージェントにすべての種類のツールを提供するために、Databricksの利用者はMCPを活用することができ、エンタープライズレベルの機能でその能力を許可します。DatabricksでホストされるMCPサーバー(とクライアント)は以下を提供します:
- Unity Catalogによるエンタープライズレベルのガバナンスによって、ツールがセキュアかつコンプアインスに沿って利用されることを確実にするための、きめ細かいアクセスコントロール、監査記録、サービスプリンシパルに基づく認証を実現します。
- 企業のデータとのシームレスな連携は、Deltaテーブルにある構造化データ、非構造化データ、ベクトル検索インデックス、外部システムからのテレメトリーであっても、エージェントはプラットフォームを離れることなしに適切な文脈に簡単にアクセスすることができます。
- Mosaic AI Gateway、MLflow evaluation、MLflow tracingを通じたビルトインの観測可能性は、デバッグと評価のためのツールの使用法、モデルの挙動、エージェントのワークフローに対する完全な可視性を開発者に提供します。
- ツールのロジックを効率的に実行するために、Databricks Appsを通じた軽量なサーバレスコンピュートによる柔軟でスケーラブルなインフラストラクチャによって、企業はリソースを過度に配備することなしに、エージェントとツールのインタラクションをスケールさせることができます。
MCPによって解放されるDatabricks利用者のユースケースは？
DatabricksにMCPをインテグレーションすることで、さまざまなエンタープライズレベルのAIユースケースを解放します:
- Deltaテーブル、外部API、レガシーシステムにアクセスするカスタムツールをラッピングするために軽量コンピュートを用いて、Databricks Apps上でMCPサーバーを構築、管理することで、最小限のオーバーヘッドであなたのロジックをスケールさせます。
- Mosaic AI GatewayやMLflow Tracingを通じた完全なる観測可能性とともに、Unity Catalog、Genieスペース、Vector Search Indexを公開することで、MCPを通じてツールに接続される企業レベルのエージェントを開発します。
- 外部MCPサーバーを呼び出すエージェントをDatabricksでホストすることで、統合され、セキュアなインタフェースを通じて、Salesforceや他のプラットフォーム外のサービスのようなシステムとのシームレスなインテグレーションを実現します。
DatabricksでMCPを活用した例は？
はい！以下のアーキテクチャ例では、Databricks上にデプロイされた品質コントロールAIエージェントがどのようにメンテナンスの質問に回答し、システムに対するアクションを実施するのかを示しています。
ユースケース例とDatabricks上のMCP
インタラクションは以下のステップに従います:
- ステップ1: ユーザーのクエリー: 「やあ、QCエージェント、マシン#1234の状態は？知っておくべき欠陥があるなら、メンテナンスチケットをオープンしてください。」
- ステップ2: ドキュメントの収集: エージェントは、Databricksでホストされるデータソースから適切なドキュメントを取得するために、MCPサーバー #1: InfoHubに問い合わせます。
- ステップ3: メトリクスの取得: 外部のMySQLデータベースからリアルタイムのマシンデータを取得するために、MCPサーバー #2: TeremetryServerに問い合わせます。
- ステップ4: 異常の分析と確認: エージェントがLLMを用いてドキュメントとセンサーメトリクスを処理します。正常より3σ以上の振動の読み取り値を検知して、欠陥の可能性のフラグを立てます。
- ステップ5: 通知、チケットのオープン: フォローアップを開始するために、エージェントはアラートを送信し、JIRAチケットを作成するために、DatabricksにホストされているMCP Server #3: SlakcMCPにコンタクトします。
- ステップ6: ユーザーにレスポンス: 「マシン#1234で振動レベルの上昇を確認したので、JIRAに優先度高のチケットをオープンしました。また、#maintenance-alertsにアラートをポストしました。詳細が知りたければ教えてください！」
DatabricksにおけるMCPのアーキテクチャはどのようなものか？
DatabricksでMCPを使いたいと思った時に、どのコンポーネントがDatabricksで実行され、どれが実行されないのかを不思議に思うかもしれません。このアーキテクチャはどれだけ柔軟なのでしょうか？以下の例では、3つのMCPサーバーとやり取りを行うDatabricks上にデプロイされたAIエージェント(MCPクライアント)を示しています。以下のプロットでは、同じ例を用いており、それぞれのコンポーネントがどのように動作し、このアーキテクチャを他のユースケースにどのように拡張できるのかを説明しています。
ガバナンス、スケーラビリティ、拡張可能性を持つDatabricks上のMCP
左側では、MCPクライアントはDatabricksにデプロイされたエージェントです。streamableHTTP MCPプロトコルを通じて、Databricks上にホストされているMCPサーバーを呼び出す他の場所で実行されているエージェントでも構いません。(IDEからなど)ローカルのMCPクライアントの場合には、代わりにstdio+SSEプロトコルとなります。
中央では、3つすべてのMCPサーバーがDatabricks Appsを用いてDatabricks上にホストされています。これらは、上時間実行されるプロセスをサポートし、既存のワークフローとシームレスに連携する軽量なコンピュート環境です。これによって、一貫性のあるガバナンスを用いて、カスタムのMCPロジックをホスティングする理想定期な環境となります。ツールは、@mcp.tool()や@app.call_tools()のような関数を用いてこれらのサーバーに登録されます。これは、LangGraphを用いる際の@toolと似ています。
右側では、ツールがデータアセットに問い合わせを行います。これらは、(Deltaテーブルやベクトルインデックスのように)Databricks内、MySQLのような外部のデータベース、SlackのようなSaaSプラットフォームに存在し得ます。この分離されたデザインによって、お使いのインフラストラクチャやツールに合わせて組み合わせつつも、エージェントのロジックを集中管理することが可能となります。
Databricksで構築した際に、MCPが開放するビジネス価値は？
DatabricksでMCPを実行することで、組織はガバナンス、スケーラビリティ、拡張可能性に対する戦略的な価値を解放し、セキュアで効率的、将来に対応できるAIシステムの構築が容易になります:
- 下流のチームや外部のパートナーにMCPサーバーを公開することで、内部ツールのリーチとインパクトを増加します。これによって、コラボレーションを促進しつつも、集中管理のガバナンスとコントロールを維持します。
- エージェントがツールとどのようにやり取りするのかを標準化することで、内部の開発を加速し、スクリプトのカスタム開発を最小限にし、チームはクイックかつ一貫性を持ってソリューションを構築できるようになります。
- MCPを通じてレガシーシステムにアクセスできるようにすることで、レガシーシステムを延命し、直近の近代化を必要とすることなしに、価値を提供し続けることができます。
Databricksによって、MCPのパワーはエンタープライズレベルになります。Unity Catalogはセキュアで管理されたアクセスを確実にしつつも、柔軟なインフラストラクチャによってツールロジックのシームレスなスケーリングを実現します。MLflowやMosaic AI GatewayのようなAIとMLとのネイティブなインテグレーションによって、観測可能性とライフサイクル管理をさらにシンプルにします。エージェントを構築しようが、レガシーシステムをラッピングしようが、チームにツールを公開しようが、DatabricksはMCPを現実世界の本番運用環境において実践的になるように、コントロール、スケーラビリティ、オープン性を提供します。DatabricksのMCP APIのドキュメントやコードの手順をこちらでチェックしてみてください！