Azure DatabricksでAIエージェントを社内データ、外部SaaS、ワークフローに接続したい場合、2026年5月時点で確認すべき重要項目が「Model Context Protocol (MCP) on Databricks」です。結論から言うと、MCP on Databricksは「AIエージェントにツールやデータを使わせるための標準インターフェース」を、Unity CatalogとUnity AI Gatewayによる権限管理・認証・監視の枠組みに乗せて扱えるようにする仕組みです。公式情報では、管理対象のMCPサーバー、外部MCPサーバー、カスタムMCPサーバーを用途に応じて使い分ける構成が整理されています。(learn.microsoft.com)
管理者が先に見るべきポイントは、プレビュー機能の有効化、Unity Catalog権限、OAuth認証、IPアクセス制限、AI Gatewayでの監視です。開発者は、どのMCPサーバーURLを使うか、ツール呼び出しに必要なスコープや権限が足りているか、Custom MCPをDatabricks Appsとして展開する場合の命名・認証・再デプロイ手順を確認する必要があります。
Microsoft Azureの「Model Context Protocol (MCP) on Databricks」は何が変わるのか
Model Context Protocol（MCP）は、AIエージェントがツール、リソース、プロンプト、その他のコンテキスト情報に接続するためのオープン標準です。Azure Databricksでは、このMCPサーバーをUnity AI Gatewayの管理対象として扱い、MCPサーバーやLLMエンドポイントに対するアクセス制御、認証、利用状況の可視化を一元的に行う構成になっています。(learn.microsoft.com)
これまでAIエージェントに外部ツールや社内データを使わせる場合、個別API連携、独自認証、権限チェック、監査ログの設計をそれぞれ作り込む必要がありました。MCP on Databricksでは、少なくともDatabricks上のデータや外部MCP連携について、標準化された接続方式とDatabricks側のガバナンスを組み合わせて設計できます。
実務上の変更点は、単に「AIが外部ツールを呼べる」ことではありません。重要なのは、次の3点です。
- AIエージェントから使えるツールやデータが、MCPサーバー単位で整理される
- Unity Catalogの権限や接続情報を使って、誰が何にアクセスできるかを管理できる
- Unity AI GatewayでMCPサーバーを含むAI利用を可視化・監視しやすくなる
つまり、Azure DatabricksでAIエージェントを本格運用する組織にとって、MCPは「便利な拡張機能」ではなく、データアクセスとAIツール利用を標準化するための設計要素になります。
2026年5月時点で押さえるべき機能拡張の流れ
MCP on Databricksは一度に完成した機能というより、2025年以降に段階的に拡張されています。公式リリースノートを時系列で見ると、管理対象MCP、外部MCP、Marketplace、SQL MCP、Managed OAuth、AI Gatewayによる統制へと範囲が広がっています。
| 時期 | 主な変更 | 影響 |
|---|---|---|
| 2025年6月 | Azure DatabricksでMCP for AI agentsがBetaとして追加 | Managed MCPとCustom MCPを使い、AIエージェントからDatabricks上のデータやツールにアクセスする基盤が登場 (learn.microsoft.com) |
| 2025年8月 | External MCP serversがBetaに | 外部ツールをMCP経由でエージェントから利用できる範囲が拡大 (learn.microsoft.com) |
| 2025年10月 | SQL managed MCP serverがBetaに | AIエージェントがUnity Catalogテーブルに対してSQLを実行できる構成が追加 (learn.microsoft.com) |
| 2025年11月 | MarketplaceでMCPサーバー掲載、ワークスペースにMCP Serversタブ追加 | 管理者が利用可能なMCPサーバーを見つけ、管理しやすくなる (learn.microsoft.com) |
| 2026年1月 | Managed MCP serversがPublic Previewに | Databricksリソースや外部APIへのセキュアな接続を、管理対象MCPとして検証しやすくなる (learn.microsoft.com) |
| 2026年3月 | 外部MCPサーバー向けManaged OAuth flowsが追加 | 一部の外部MCPで独自OAuthアプリや資格情報管理の負担を減らせる (learn.microsoft.com) |
| 2026年4月 | AI GatewayがMCPサーバーのアクセス制御、監視、監査に対応 | MCP利用をAIガバナンスの管理対象として扱いやすくなる (learn.microsoft.com) |
ただし、Azure Databricksのリリースは段階的に展開されるため、アカウントやワークスペースによっては初回リリース日から反映まで時間差が出る場合があります。管理者は「公式ページにあるから利用できる」と決めつけず、自社ワークスペースで該当機能が有効かを確認する必要があります。(learn.microsoft.com)
MCP on Databricksで使える3種類のMCPサーバー
Azure Databricksで扱うMCPサーバーは、大きく分けて「Managed」「External」「Custom」の3種類です。どれを選ぶかで、設定作業、権限管理、認証、運用負荷が変わります。
| 種類 | 使いどころ | 主な対象 | 注意点 |
|---|---|---|---|
| Managed MCP servers | Databricks上のデータや機能をすぐにAIエージェントへ接続したい場合 | Vector Search、Genie Spaces、Databricks SQL、Unity Catalog functions | Unity Catalog権限が常に適用される。SQL MCPは読み取りだけでなく書き込み用途にも関わるため権限設計が重要 |
| External MCP servers | GitHub、検索、業務SaaSなど外部サービスを使わせたい場合 | サードパーティMCPサーバー、Marketplace経由のMCP、Custom HTTP接続 | Databricks-managed proxy、Unity Catalog connection、OAuthまたは共有資格情報の設計が必要 |
| Custom MCP servers | 自社独自の業務ロジックや社内ツールをAIエージェントから呼ばせたい場合 | Databricks Appsとしてホストする独自MCPサーバー | HTTP互換トランスポート、Databricks Apps権限、アプリ名、ツール説明の品質が重要 |
Managed MCP serversは、Unity Catalog、Databricks Vector Search、Genie Spaces、Unity Catalog functionsなどにAIエージェントを接続する用途に向いています。公式情報では、Managed MCPサーバーに対してUnity Catalog権限が適用され、ユーザーやエージェントは許可されたデータやツールだけを利用できると説明されています。(learn.microsoft.com)
External MCP serversは、Azure Databricks外でホストされているMCPサーバーをDatabricks-managed proxy経由で使う方式です。インストール後は、エージェントやクライアントが外部サービスを直接扱うのではなく、Databricks側のプロキシURLを通じて利用します。(learn.microsoft.com)
Custom MCP serversは、自社で作ったMCPサーバーや既存のサードパーティMCPサーバーをDatabricks Appsとしてホストする方式です。Databricks Appsの権限でアクセスを制御し、Unity AI Gatewayで他のMCPやLLMエンドポイントと併せて監視できます。(learn.microsoft.com)
Managed MCP serversでできること
Managed MCP serversは、Azure Databricks側で用意されたMCPサーバーを使う方式です。代表的な対象は次の通りです。
| MCPサーバー | 用途 | 実務での使い方 |
|---|---|---|
| Vector Search | 関連ドキュメントやナレッジの検索 | 問い合わせ対応エージェントがFAQ、仕様書、サポートチケットを検索する |
| Genie Space | 構造化データを自然言語で分析 | 売上、請求、利用状況などを会話形式で確認する |
| Databricks SQL | AI生成SQLを実行 | 開発支援ツールやIDEからSQL作成・検証・データパイプライン作成を支援する |
| Unity Catalog functions | 事前定義したSQL関数を実行 | アカウント検索、業務ルール判定、定型集計などをツール化する |
公式情報では、Genie Spaceは読み取り専用で、長時間実行されるクエリでは結果取得のポーリングが必要とされています。また、Databricks SQL MCP serverはAI生成SQLを実行でき、読み書きの用途に関わるため、利用者・サービスプリンシパル・SQL Warehouse・Unity Catalog権限を慎重に設計する必要があります。(learn.microsoft.com)
開発者にとって便利なのは、複数のMCPサーバーを組み合わせてエージェントを作れる点です。例えば、サポート業務向けエージェントなら、Vector Searchで過去チケットやドキュメントを探し、Genie Spaceで請求データを確認し、Unity Catalog functionsで顧客ステータスを判定する、といった構成が考えられます。
External MCP serversを使う前に確認すべきこと
External MCP serversは、外部サービスをAIエージェントから利用したい場合に有効です。ただし、管理者が最初に確認すべき項目が多くあります。
公式情報では、外部MCPサーバーの利用には、Managed MCP Servers previewが有効なワークスペース、Unity Catalogメタストアに対するCREATE CONNECTION権限、MCPサーバー側のStreamable HTTP transport対応が必要とされています。(learn.microsoft.com)
| 確認項目 | 確認する理由 | 見落とした場合の問題 |
|---|---|---|
| プレビュー機能の有効化 | ワークスペースで外部MCPを使えるか確認するため | UIや接続作成項目が表示されない |
CREATE CONNECTION権限 | Unity Catalog connectionを作成するため | 外部MCPサーバーを登録できない |
| Streamable HTTP transport | Databricksが対応する外部MCP方式に合うか確認するため | 外部MCPサーバーを接続できない |
| 認証方式 | 共有資格情報かユーザー別認証かを決めるため | 監査やアクセス制御が曖昧になる |
USE CONNECTION権限 | 利用者やアプリが接続を使えるようにするため | インストール済みでもエージェントから呼び出せない |
外部MCPサーバーをインストールすると、Unity Catalog connectionが作成され、Databricks-managed proxy endpointがプロビジョニングされます。接続先URLはhttps://<workspace-hostname>/api/2.0/mcp/external/{connection_name}の形式です。ほかのユーザーに使わせるには、対象のIDにUSE CONNECTION権限を付与します。(learn.microsoft.com)
認証方式は、共有プリンシパルとユーザー別認証を使い分けます。単一のサービスアカウントで十分な外部サービスなら共有プリンシパル、GitHubリポジトリやカレンダーのようにユーザーごとのアクセス制御や監査が必要なサービスならOAuth U2M Per Userを選ぶのが基本です。(learn.microsoft.com)
Custom MCP serversを展開するときの注意点
Custom MCP serversは、自社独自の業務ツールや既存のMCPサーバーをDatabricks Appsとして動かしたい場合に使います。例えば、社内の承認ワークフローを呼び出す、独自マスタを検索する、運用手順に沿って定型チェックを実行する、といった用途に向いています。
Databricks AppsとしてホストするMCPサーバーは、Streamable HTTP transportなどHTTP互換のトランスポートを実装している必要があります。また、AI PlaygroundでMCPサーバーとして認識させるには、アプリ名をmcp-で始める必要があります。(learn.microsoft.com)
Custom MCPで特に重要なのは、ツールの説明文です。Databricksのテンプレートでは@mcp.tool()デコレーターでツールを定義でき、各ツールにはdocstringが必要です。AIエージェントはdocstringを見て「いつそのツールを呼ぶべきか」を判断するため、説明が曖昧だと誤実行や不適切な呼び出しにつながります。(learn.microsoft.com)
悪い例は次のような説明です。
"""ユーザー情報を取得します。"""これでは、どのユーザーを対象にするのか、取得してよい情報の範囲は何か、どの場面で使うべきかが分かりません。
より実務向きにするなら、次のように書きます。
"""指定された社内ユーザーIDに紐づく部署名と在籍ステータスを取得します。個人連絡先や評価情報は返しません。問い合わせ対応で担当部署を確認する場合にのみ使用します。"""Custom MCPは「作れば終わり」ではありません。再デプロイ、依存関係、Databricks Apps権限、シークレット管理、エラー時のログ確認まで含めて運用設計する必要があります。
クライアント接続ではOAuthを基本に考える
Claude、Cursor、MCP Inspector、Replitなど、MCP対応クライアントからDatabricks MCPに接続する場合は、認証方式の選択が重要です。公式情報では、OAuthはManaged/External MCPとCustom MCPの両方でサポートされ、スコープ付き権限と自動トークン更新により本番利用やチーム利用に適した方式とされています。一方、Personal Access Token（PAT）はManaged/External MCPでは使えますが、Custom MCPではサポートされていません。(learn.microsoft.com)
| 認証方式 | 向いている用途 | 注意点 |
|---|---|---|
| OAuth | 本番利用、チーム利用、長期運用 | リダイレクトURL、スコープ、トークン有効期限、クライアント種別の設計が必要 |
| PAT | 個人開発、短期検証 | Custom MCPでは使えない。漏えい時のリスクを考え、期限と権限を絞る |
| Databricks CLI認証 | ローカルIDEでの開発検証 | 既存のCLI認証を使えるが、本番の自動化とは分けて考える |
OAuthアプリを作成する場合、外部クライアントのリダイレクトURLを正確に設定し、必要なスコープを選びます。公式例ではall-apisだけでなく、GenieやUnity Catalogなどの粒度の細かいスコープを使う例も示されています。実務では、検証時に広いスコープで動かしてから、本番では最小権限に絞る流れが安全です。(learn.microsoft.com)
IPアクセス制限を有効にしているワークスペースでは、クライアントのアウトバウンドIPを許可リストに追加しないと、認証や接続が失敗する可能性があります。特にClaude、ChatGPT apps、社外IDE、CI/CD環境から接続する場合は、ネットワーク管理者と事前に確認しておきましょう。(learn.microsoft.com)
管理者が確認すべき設定チェックリスト
MCP on Databricksを導入する前に、管理者は次の項目を確認してください。
| 項目 | 確認内容 | 判断基準 |
|---|---|---|
| ワークスペースの機能状態 | 対象ワークスペースでMCP関連機能が有効か | UIのAI Gateway > MCPsで確認できるか |
| Unity Catalog | メタストア、カタログ、スキーマ、テーブル、関数の権限 | エージェント用IDに過剰権限を与えていないか |
| Connection権限 | 外部MCP用のCREATE CONNECTION、利用者向けのUSE CONNECTION | 管理者と利用者の権限が分離されているか |
| OAuthアプリ | クライアントID、シークレット、リダイレクトURL、スコープ | 本番用と検証用を分けているか |
| IPアクセス制限 | 外部クライアントやIDEのアウトバウンドIP | 許可リスト漏れで接続失敗しないか |
| 監査と可視化 | Unity AI GatewayでMCP利用を確認できるか | 誰がどのMCPを使ったか追跡できるか |
| 課金 | Databricks Apps、SQL、Vector Search、Serverless computeの利用 | 検証環境でコスト上限や利用範囲を決めているか |
Compute pricingについては、Custom MCP serversはDatabricks Apps pricingの対象で、Managed MCP serverはUnity Catalog functions、Genie Spaces、Databricks SQL、Vector Searchなど利用する機能に応じた課金が関係します。事前に「MCPサーバーそのもの」だけでなく、呼び出し先のコンピュートやインデックスのコストを確認しておく必要があります。(learn.microsoft.com)
開発者が実装前に確認すべきポイント
開発者は、まず「どのMCPサーバーを使うか」を明確にしてください。Databricks上のデータ検索ならVector SearchやUnity Catalog functions、自然言語によるデータ分析ならGenie Space、外部SaaS連携ならExternal MCP、自社独自ツールならCustom MCPが候補になります。
ローカル環境からManaged MCPに接続してエージェントを開発する場合、公式情報ではOAuthでワークスペースに認証し、Python 3.12以上のローカル環境にmcp、databricks-sdk[openai]、mlflow、databricks-agents、databricks-mcpなどの依存関係をインストールする例が示されています。また、接続検証の一部ではServerless computeを有効にする必要があります。(learn.microsoft.com)
デプロイ時は、エージェントがMCPサーバー経由で利用するリソースをログ時に指定する必要があります。例えば、Vector SearchのスキーマやUnity Catalog functionsを使う場合、それらのリソースをエージェントが必要とするリソースとして扱う必要があります。(learn.microsoft.com)
開発時に特に注意すべきポイントは次の通りです。
- MCPサーバーURLを環境ごとに分ける
- 検証用と本番用のOAuthアプリを分ける
- エージェントが呼べるツール数を増やしすぎない
- SQL MCPに書き込み権限を与える場合は、対象テーブルとWarehouseを限定する
- Custom MCPのdocstringには、利用条件、入力、返却値、禁止事項を書く
- 長時間実行されるGenieやSQLの結果取得では、ポーリングやタイムアウトを設計する
移行・展開で失敗しやすいポイント
MCP on Databricksは便利ですが、AIエージェントがデータや外部ツールを実行できる範囲が広がるため、設計を誤るとセキュリティ事故や運用トラブルにつながります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Custom MCPにPATで接続しようとする | Custom MCPはPAT非対応のため接続できない | Custom MCPはOAuth前提で設計する (learn.microsoft.com) |
| 外部MCPがStreamable HTTPに対応していない | Databricks側で外部MCPとして扱えない | 導入前にMCPサーバーのtransport仕様を確認する |
USE CONNECTIONだけ付与して基礎データ権限を確認しない | 接続は見えるがツール実行時に失敗する | 接続権限とUnity Catalog上のデータ権限を両方確認する |
| OAuthリダイレクトURLがクライアント設定と一致しない | 認証フローが完了しない | クライアントの公式設定値を確認してOAuthアプリに登録する |
all-apisを本番でも使い続ける | 必要以上に広い権限を与える | 本番では粒度の細かいスコープへ移行する |
| IPアクセス制限を考慮しない | Claude、Cursor、MCP Inspectorなどから接続できない | クライアントのアウトバウンドIPを許可リストに追加する |
mcp-で始まらないアプリ名にする | AI PlaygroundでMCPサーバーとして認識されない | Custom MCPのDatabricks App名はmcp-で始める (learn.microsoft.com) |
| ツールのdocstringが曖昧 | エージェントが誤った場面でツールを呼ぶ | 使用条件と禁止事項を明記する |
| SQL MCPに広い書き込み権限を与える | 意図しない更新や削除のリスクが高まる | 読み取り中心から始め、書き込みは限定テーブルに絞る |
特に本番環境では、「AIエージェントが人間の代わりに操作する」ことを前提に、ユーザー本人の権限で動かすのか、サービスプリンシパルで動かすのかを明確にする必要があります。ユーザー別の説明責任が必要な業務では、Per-user authenticationを検討すべきです。
導入は小さく始めるのが安全
MCP on Databricksは、最初から全社展開するよりも、対象データと利用者を絞ったパイロットから始めるのが現実的です。
| フェーズ | やること | 成功条件 |
|---|---|---|
| 検討 | AIエージェントに使わせたいデータ・ツールを棚卸しする | 「検索」「分析」「実行」のどれをMCP化するか決まっている |
| 設計 | Managed、External、Customのどれを使うか決める | 既存のUnity Catalog権限と矛盾しない |
| 検証 | 開発用ワークスペースでMCPサーバーを接続する | AI PlaygroundやMCP Inspectorで接続確認できる |
| 権限整理 | OAuth、Connection、Unity Catalog、Apps権限を調整する | 検証ユーザーで必要な操作だけできる |
| パイロット | 1つの業務ユースケースでエージェントを試す | 失敗時のログ、監査、停止手順が確認できる |
| 展開 | 利用部門やツールを段階的に増やす | コスト、権限、監査ログを継続確認できる |
最初のユースケースとしては、書き込みを伴わないナレッジ検索や、読み取り専用の業務データ分析が向いています。いきなりSQL MCPで更新系操作を許可したり、外部SaaSへ投稿・削除できるツールを接続したりするのは避けた方が安全です。
どの企業に向いているか
MCP on Databricksが特に向いているのは、次のような組織です。
- Azure Databricks上に分析基盤やAI基盤をすでに持っている
- Unity Catalogでデータ権限を管理している
- AIエージェントに社内データや外部ツールを使わせたい
- Claude、Cursor、ChatGPT apps、MCP Inspectorなど複数のMCP対応クライアントを検証している
- AI利用の監査、認証、アクセス制御を個別実装ではなく統制された仕組みに寄せたい
一方で、次の状況では慎重に進めるべきです。
- プレビュー機能を本番利用できない社内ルールがある
- 外部MCPサーバーがStreamable HTTPに対応していない
- OAuthアプリ管理やIP許可リスト管理の体制が整っていない
- AIエージェントがどの業務操作を実行してよいか、まだ社内で合意できていない
- Custom MCPの運用担当、ログ監視、障害対応の責任範囲が決まっていない
MCPは「AIに何でも接続できる魔法の仕組み」ではありません。むしろ、AIが使えるツールやデータを明確に定義し、権限と監査の下で利用するための枠組みとして考えるべきです。
次に取るべき行動
Azure DatabricksでModel Context Protocol (MCP) on Databricksを検討するなら、まず管理者と開発者で次の3点を確認してください。
1つ目は、自社ワークスペースでAI Gateway > MCPsを確認し、利用可能なMCPサーバーとプレビュー機能の状態を把握することです。2つ目は、Unity Catalog権限、Connection権限、OAuthスコープ、IPアクセス制限を棚卸しすることです。3つ目は、読み取り専用の小さなユースケースから試し、AIエージェントがどのツールを、どの権限で、どのログの下で使うのかを確認することです。
MCP on Databricksの価値は、AIエージェントの接続先を増やすことだけではありません。Azure Databricks上のデータ、外部ツール、社内ワークフローを、標準化された安全なインターフェースで扱えるようにする点にあります。まずはManaged MCP serversで権限と監査の動きを確認し、その後にExternal MCPやCustom MCPへ広げるのが、リスクを抑えた導入手順です。
コメント