MCP Toolkit for Azure Cosmos DBのGAは、Azure Cosmos DB上の業務データをAIエージェントやCopilotから扱いやすくするための更新です。既存のAzure Cosmos DBが自動的にAIへ公開されるわけではありませんが、Microsoft FoundryやVS Code/GitHub CopilotなどのMCP対応クライアントから、Cosmos DBのデータ検索・スキーマ確認・ベクトル検索などを標準的な形で呼び出せるようになります。
特に確認すべきポイントは、「どのCosmos DBアカウントをAIに見せるか」「誰がMCPサーバーを呼び出せるか」「読み取り可能なデータ範囲が広すぎないか」の3つです。開発者にとってはAI/Copilot連携の実装が進めやすくなる一方、管理者にとっては認証、RBAC、ネットワーク、監査ログ、RU消費の管理がより重要になります。Microsoftの発表では、MCP Toolkit for Azure Cosmos DBはMCP対応のAIクライアントやエージェントフレームワークにCosmos DBデータを公開するための仕組みとして説明されています。(Microsoft for Developers)
Azure Cosmos DBのAI/Copilot更新で何が変わるのか
今回の更新の中心は、Azure Cosmos DBをAIエージェントの外部データソースとして接続しやすくする「MCP Toolkit for Azure Cosmos DB」が一般提供されたことです。MCPはModel Context Protocolの略で、AIエージェントが外部システムやデータソースとやり取りするための標準的な接続方式として使われます。
これまでAIアプリや社内CopilotからCosmos DBを参照させるには、独自API、検索API、認証処理、権限制御、データ取得ロジックを個別に作る必要がありました。MCP Toolkitを使うと、Cosmos DB向けのMCPサーバーを用意し、AIエージェント側から標準化されたツールとして呼び出せます。
実務上の変化を整理すると、次のようになります。
| 観点 | これまで起きやすかった課題 | MCP Toolkit for Azure Cosmos DBで変わる点 |
|---|---|---|
| AI連携 | アプリごとにCosmos DB接続ロジックを実装していた | MCP対応クライアントから共通のツールとして呼び出せる |
| データ検索 | キーワード検索、ベクトル検索、スキーマ確認を個別実装していた | 代表的な検索・参照ツールが用意される |
| 認証 | APIキーや独自認証を混在させがちだった | Microsoft Entra ID、Managed Identity、RBACを前提に構成しやすい |
| 展開 | 本番向けホスティング設計を別途考える必要があった | Azure Container Appsへの展開例が用意される |
| 運用 | AIからのアクセス範囲が曖昧になりやすい | MCPサーバー単位で権限・ログ・接続先を管理しやすい |
GAとは、Azure Updates上の区分では本番利用を前提に利用できる状態を指します。ただし「GAだから設定不要で安全」という意味ではありません。Cosmos DBのデータをAIエージェントに触らせる以上、既存のアプリケーション連携よりもデータ露出範囲を慎重に設計する必要があります。(マイクロソフト Azure)
MCP Toolkit for Azure Cosmos DBでできること
MCP Toolkit for Azure Cosmos DBは、AIエージェントが自然言語の指示をもとにCosmos DBへ問い合わせるためのMCPサーバーです。GitHubの公式リポジトリでは、Azure Entra ID認証、ドキュメント操作、ベクトル検索、ハイブリッド検索、スキーマ検出を備えるツールキットとして説明されています。(aka.ms)
代表的なMCPツールは次のとおりです。
| ツール | 主な用途 | 活用例 |
|---|---|---|
list_databases | Cosmos DBアカウント内のデータベース一覧を取得 | エージェントに利用可能なデータソースを確認させる |
list_collections | 指定データベース内のコンテナー一覧を取得 | 顧客、商品、問い合わせ履歴などのコンテナーを把握する |
get_approximate_schema | サンプル文書から上位プロパティを推定 | 開発者がスキーマを把握してクエリ設計する |
get_recent_documents | 最近のドキュメントを取得 | 最新の注文、問い合わせ、イベントを確認する |
find_document_by_id | IDでドキュメントを検索 | 顧客IDや注文IDを指定して詳細を取得する |
text_search | 指定プロパティに対するテキスト検索 | 「nameにAzureを含む商品」を探す |
vector_search | 埋め込みを使ったベクトル検索 | 意味的に近いFAQ、商品、ナレッジを探す |
hybrid_search | ベクトル検索と全文検索を組み合わせる | キーワード一致と意味検索を併用して精度を上げる |
公開されているツール一覧を見る限り、AI/Copilotへ公開する基本機能は参照・検索系が中心です。業務システムの更新処理までAIに任せるというより、まずは「安全に業務データを探す」「根拠データを取り出す」「開発時にデータ構造を確認する」用途から検討するのが現実的です。hybrid_searchについては、対象コンテナーにベクトルインデックスと全文インデックスの両方が必要とされています。(aka.ms)
影響を受ける利用者と受けない利用者
この更新は、すべてのAzure Cosmos DB利用者に即座に影響するものではありません。既存のWebアプリ、API、バッチ処理がCosmos DBを使っているだけなら、MCP ToolkitのGAによってアプリの挙動が変わることは基本的にありません。
影響が大きいのは、次のようなチームです。
| 対象 | 影響 |
|---|---|
| AIアプリ開発者 | Cosmos DBをRAG、エージェント、社内Copilotのデータソースとして使いやすくなる |
| Azure管理者 | Entra ID、Managed Identity、RBAC、Container Apps、監査ログの設計が必要になる |
| セキュリティ担当者 | AIエージェントが読めるデータ範囲、利用者、認証方式の確認が必要になる |
| データ管理者 | 個人情報、機密情報、社外秘データをAIに渡してよいか判断する必要がある |
| DevOps担当者 | MCPサーバーのCI/CD、バージョン更新、障害時の切り戻しを考える必要がある |
逆に、Cosmos DBを通常のアプリケーションバックエンドとしてのみ利用しており、AIエージェントやCopilotから接続する予定がない場合は、すぐに移行作業が発生する更新ではありません。ただし、今後社内AIや開発支援エージェントから業務データを参照する計画があるなら、早い段階でデータ境界と権限設計を決めておく価値があります。
管理者が最初に確認すべき設定
MCP Toolkit for Azure Cosmos DBを本番環境に近い場所で使う場合、最初に見るべきなのは機能ではなく「アクセス範囲」です。公式リポジトリでは、権限を付与した後のMCPサーバーは、関連付けられたCosmos DBアカウント内のすべてのデータベースとコンテナーに読み取りアクセスを持つ点が強調されています。認証に成功したエージェントやアプリケーションは読み取り操作を実行できるため、信頼できる利用者とアプリケーションだけにアクセスを限定する必要があります。(aka.ms)
確認項目は次の順番で進めると安全です。
| 確認項目 | 判断基準 | 失敗しやすいポイント |
|---|---|---|
| 接続先のCosmos DBアカウント | AIに見せてもよいデータだけを含むか | 本番の全データをそのまま接続してしまう |
| Entra IDアプリ登録 | 専用アプリとして識別・監査できるか | 既存アプリ登録を使い回して責任範囲が曖昧になる |
| ロール割り当て | Mcp.Tool.Executorを必要なユーザーやサービスだけに付与しているか | 検証用に広く付与したまま本番化する |
| Managed Identity | Cosmos DBや埋め込みサービスへの権限が最小限か | 便利だからと広い権限を与える |
| ネットワーク公開 | Container Appsの入口を社内要件に合わせて制限できているか | テスト時の公開設定を残す |
| ログと監査 | 誰が、いつ、どのツールを呼んだか追跡できるか | AI経由のアクセスが通常アプリのログに埋もれる |
| RUとコスト | 検索・スキーマ推定・最近文書取得の負荷を見積もっているか | エージェントが繰り返し広範囲検索してRUを消費する |
特に避けたいのは、「Copilotに便利そうだから」という理由で本番Cosmos DBアカウントを丸ごと接続することです。まずは検証用アカウント、匿名化済みデータ、参照専用のコンテナー、またはAI公開用に分離したデータセットから始めるのが安全です。
開発者が確認すべき実装・展開上の注意点
開発者は、MCP Toolkitを単なるライブラリではなく「AIから呼ばれるデータアクセス用サービス」として扱う必要があります。公式リポジトリでは、Azure Container Apps、Azure Container Registry、Managed Identity、RBAC割り当てを含む展開構成が示されています。ローカル開発にはDocker Composeや.NET開発環境も利用できます。(aka.ms)
前提条件を満たしているか確認する
主な前提は、Azureサブスクリプション、Azure Cosmos DBアカウント、埋め込みサービス、Azure CLI、PowerShell 7以上、Docker Desktop、.NET 9.0 SDK、Gitです。Azure Developer CLIはazd upで展開する場合に使います。ベクトル検索やハイブリッド検索を使う場合は、Azure AI Services、Microsoft Foundry、OpenAI APIなどの埋め込みサービスも必要です。(aka.ms)
導入前に、少なくとも次の情報をそろえておきます。
| 必要な情報 | 用途 |
|---|---|
| Cosmos DBエンドポイント | MCPサーバーが接続するデータベースを指定する |
| 対象データベース名・コンテナー名 | エージェントの指示やツールパラメーターで使う |
| 埋め込みモデル名 | ベクトル検索・ハイブリッド検索で使う |
| EntraアプリのクライアントID | MCPクライアントの認証対象として使う |
| Container App URL | VS CodeやFoundryなどのMCPクライアントに設定する |
| ロール割り当て対象 | 利用者、開発者、エージェント実行環境を決める |
AIエージェントへの指示は具体的に書く
MCP Toolkitを接続しただけでは、エージェントが安全で正確な問い合わせをしてくれるとは限りません。Microsoft Foundryの設定例でも、データベース名やコンテナー名をパラメーターとして指定し、利用可能なMCPツールを使うようにエージェントへ指示する流れが示されています。(aka.ms)
実務では、次のように指示を制限すると事故を減らせます。
あなたは社内FAQ検索用のアシスタントです。
指定されたfaqデータベースとpublic-knowledgeコンテナーのみを使用してください。
個人情報を含む可能性があるフィールドは回答に含めないでください。
検索結果に根拠がない場合は、推測せず「該当データが見つかりません」と回答してください。曖昧な指示のまま接続すると、エージェントが必要以上に広いデータを検索したり、利用者に見せるべきでないフィールドを回答に含めたりする可能性があります。MCP側の権限制御だけでなく、エージェント側のプロンプト、対象コンテナー、返却フィールドの制御を組み合わせることが重要です。
VS CodeやCopilot連携ではトークン更新に注意する
VS CodeのMCPクライアントから使う場合は、Container AppのMCPエンドポイントURLとBearerトークンを設定します。公式手順では、Azure CLIでEntraアプリ向けのアクセストークンを取得し、settings.jsonにAuthorizationヘッダーとして指定する例が示されています。JWTトークンは通常期限切れになるため、検証時に401エラーが出た場合は、まずトークンの有効期限とaudience設定を確認します。(aka.ms)
本番利用では、個人の手動トークンに依存した運用は避けるべきです。エージェント実行基盤、CI/CD、開発端末のどこから呼ぶのかを分け、認証方式とトークン更新手順を文書化しておきましょう。
プレビュー版や検証環境から移行する場合の確認点
すでにMCP Toolkitを検証していた場合は、単に「GAになったからそのまま本番化」ではなく、バージョン、エンドポイント、依存関係、ロール設定を確認します。
GitHubのChangelogでは、2026年5月29日の1.1.2でhybrid_searchが追加され、text_search、vector_search、hybrid_searchの既定件数が10になったこと、Cosmos DB SDKや認証関連ライブラリなどの依存関係が更新されたことが示されています。また、1.1.0では複数の埋め込みプロバイダー対応やトークン取得、Foundry接続スクリプト、ロール割り当てスクリプトの修正も含まれています。(GitHub)
移行時は、次の順番で確認すると安全です。
| 手順 | 確認内容 |
|---|---|
| バージョン確認 | 利用中のタグ、Changelog、リリースノートを確認する |
| エンドポイント確認 | MCPクライアントが/mcpなど現在の推奨エンドポイントを参照しているか確認する |
| ロール確認 | 既存のEntraアプリ、Service Principal、Mcp.Tool.Executorの割り当てを棚卸しする |
| 検索確認 | text_search、vector_search、hybrid_searchで期待した件数・スコア・RU消費になるか確認する |
| インデックス確認 | ハイブリッド検索に必要なベクトルインデックスと全文インデックスを用意する |
| ログ確認 | 401、403、Cosmos DBクエリエラー、埋め込みAPIエラーを追跡できるか確認する |
| 切り戻し確認 | 旧コンテナー、旧Container App、旧イメージへ戻せる手順を残す |
特に注意したいのは、検証時に作ったEntraアプリやロール割り当てが残っているケースです。検証用ユーザー、退職者、外部委託先、古いサービスプリンシパルに権限が残っていないかを本番化前に必ず確認してください。
セキュリティ設計で押さえるべき考え方
MCP Toolkit for Azure Cosmos DBのセキュリティは、Microsoft Entra ID、JWT Bearer Token、audience検証、Managed Identity、RBACを組み合わせる構成です。アーキテクチャ上は、クライアントがMCP Toolkit APIへBearer Token付きでアクセスし、APIがトークンとロールを検証したうえで、Managed Identityを使ってCosmos DBや埋め込みサービスにアクセスします。(GitHub)
ただし、技術的に安全な認証方式を使っていても、データ設計を誤るとリスクは残ります。次の3つを分けて考えると判断しやすくなります。
誰が呼べるか
利用者本人、開発者、社内Copilot、Foundry上のエージェント、外部MCPクライアントのどれが呼び出すのかを明確にします。人間のユーザーだけでなく、エージェント実行環境や自動化プロセスも「利用者」として扱うべきです。
何を読めるか
MCPサーバーが接続するCosmos DBアカウント、データベース、コンテナーを絞ります。可能であれば、AI公開用のコンテナーを分け、不要なフィールドを含めない形に整えます。個人情報、契約情報、未公開の財務情報、障害対応履歴などは、AIに渡す前に明確な基準を作る必要があります。
どこまで答えてよいか
データにアクセスできることと、利用者へ回答してよいことは別です。たとえば、社内問い合わせエージェントが顧客テーブルを検索できても、すべての顧客情報をそのまま表示してよいとは限りません。エージェントの指示、レスポンス整形、マスキング、ログ監査を組み合わせて制御しましょう。
よくある失敗と回避策
MCP Toolkitの導入で失敗しやすいのは、機能検証の勢いで運用設計を後回しにすることです。特にAI連携では、少人数の検証では問題が見えにくく、本番展開後に「誰でも広いデータを検索できる」「RU消費が急に増えた」「監査ログから原因を追えない」といった課題が表面化しやすくなります。
| 失敗例 | 起きること | 回避策 |
|---|---|---|
| 本番DBを丸ごと接続する | エージェントが想定外のデータを検索できる | AI公開用アカウント、コンテナー、ビュー相当のデータセットを分離する |
| 権限を広く付与する | 検証ユーザーや不要なアプリが残る | ロール割り当てを棚卸しし、期限付き運用にする |
| インデックスを準備しない | 検索が遅い、RU消費が高い、検索結果が不安定になる | text/vector/hybridごとに必要なインデックスを設計する |
| プロンプトだけで制御する | 機密データが回答に出る可能性が残る | データ分離、権限、返却フィールド制限を併用する |
| ログを取らない | 問題発生時に誰が何を検索したか分からない | Container Apps、アプリログ、Cosmos DBメトリックを確認できる状態にする |
| コストを見積もらない | エージェントの反復検索でRUや埋め込みAPI利用が増える | 検証時に代表シナリオのRU、レイテンシ、API利用量を測る |
「AIだから例外的に自由に読ませる」のではなく、「AIも通常の業務アプリと同じか、それ以上に厳しく管理する」という前提で設計することが重要です。
どのような用途から始めるべきか
最初のユースケースは、書き込みや高リスクな判断を伴わないものが向いています。たとえば、以下のような用途です。
| 用途 | 向いている理由 |
|---|---|
| 社内FAQ検索 | 公開範囲を限定しやすく、検索品質を検証しやすい |
| 商品・カタログ検索 | ベクトル検索やハイブリッド検索の効果を確認しやすい |
| 開発者向けスキーマ確認 | get_approximate_schemaでデータ構造を把握しやすい |
| 問い合わせ履歴の要約前検索 | 最近のドキュメント取得やテキスト検索を活用しやすい |
| RAGアプリのデータ取得 | Cosmos DBを運用データと検索データの接点として使いやすい |
一方で、次の用途は慎重に進めるべきです。
| 慎重にすべき用途 | 理由 |
|---|---|
| 個人情報を含む顧客DBの直接検索 | 回答への混入や権限逸脱のリスクが高い |
| 請求・契約・人事データの検索 | 閲覧権限の管理が複雑になりやすい |
| 障害対応ログやセキュリティログの検索 | 機密情報や攻撃情報を含む可能性がある |
| 業務データの更新・削除 | 誤操作時の影響が大きく、監査と承認が必要 |
まずは低リスクな参照系ユースケースで、認証、ログ、RU消費、回答品質を確認します。その後、対象データや利用部門を段階的に広げるのが安全です。
導入前チェックリスト
本番展開を検討する前に、次の項目を確認してください。
| チェック | 内容 |
|---|---|
| データ分類 | AIに見せてよいデータ、見せてはいけないデータを分けた |
| 接続先分離 | 本番全体ではなく、用途に合ったCosmos DBアカウントまたはコンテナーを選んだ |
| 認証設計 | Entra IDアプリ、audience、Bearer Token、ロール割り当てを確認した |
| 権限設計 | Managed IdentityとRBACを最小権限にした |
| 検索設計 | text/vector/hybridごとのインデックスと検索対象フィールドを決めた |
| エージェント指示 | 利用するデータベース、コンテナー、禁止事項をプロンプトに明記した |
| 運用監視 | ログ、メトリック、エラー、RU消費を確認できる |
| コスト確認 | 代表的な質問パターンでRUと埋め込みAPI利用量を測った |
| 移行手順 | 既存検証環境からの更新手順と切り戻し手順を用意した |
| 利用者教育 | AIが返す回答を鵜呑みにせず、根拠データを確認するルールを共有した |
MCP Toolkit for Azure Cosmos DBは、Azure Cosmos DBをAIエージェントやCopilotの実用的なデータソースにするうえで有力な選択肢です。ただし、価値が出るかどうかは「接続できるか」ではなく、「安全な範囲で、必要なデータだけを、適切な利用者に公開できるか」で決まります。
次に取るべき行動は明確です。まずAIに公開したいユースケースを1つ選び、対象データを分離し、MCPサーバーの検証環境を作ります。そのうえで、Entra IDのロール、Managed Identity、検索インデックス、ログ、RU消費を確認し、小さく本番に近い形で試すのが最も安全な進め方です。
コメント