2026年6月18日にApps on Azure Blogで公開された「Controlling Tool Access with APIM MCP Gateway」は、Azure API Management（APIM）をMCP Gatewayとして使い、AIエージェントに公開するツールを細かく制御するための実装ガイドです。結論から言うと、GitHub Copilot、Claude、ChatGPTなどのエージェントからMCPサーバーを使わせている組織は、「MCPサーバーを直接公開していないか」「不要なツールまで見えていないか」「tools/listとtools/callの両方を制御しているか」を優先して確認すべきです。今回の分類はNoticeであり、強制移行や廃止告知というより、APIMでMCPツールアクセスを統制する実務パターンの共有と捉えるのが近い内容です。(TECHCOMMUNITY.MICROSOFT.COM)
Controlling Tool Access with APIM MCP Gatewayで何が変わったのか
今回のポイントは、MCPサーバーを「入れたら全部のツールが使える」状態から、APIMを挟んでツール単位で見せる・止める構成にできることです。
MCPサーバーは、AIエージェントが外部データやAPIにアクセスするための標準的な接続口として使われます。ただし、実務では「検索ツールは使わせたいが、課金APIを呼ぶツールは使わせたくない」「本番更新系のツールは特定チームだけにしたい」といった制御が必要になります。
Apps on Azure Blogでは、この課題に対して、APIMをMCPサーバーの前段に置き、JSON-RPCの通信を見ながらポリシーで制御する考え方が示されています。特に重要なのは、MCPのtools/listとtools/callの両方を扱う点です。tools/listだけを隠しても、クライアントが直接tools/callを送れば呼び出せる可能性があるため、非公開にしたいツールは「一覧から消す」と「直接呼び出しをブロックする」をセットで考える必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
影響を受けるAzure利用者
今回のNoticeは、すべてのAzure利用者に即時影響がある内容ではありません。影響が大きいのは、すでにMCPサーバーやAIエージェント連携を業務利用している組織です。
| 対象者 | 確認すべきこと |
|---|---|
| GitHub CopilotやClaudeなどからMCPサーバーを利用している開発チーム | 直接MCPサーバーに接続していないか、APIM経由にできるか |
| Azure API ManagementをAPI Gatewayとして使っている管理者 | MCP Servers機能、ポリシー、認証、レート制限を既存運用に組み込めるか |
| セキュリティ・ガバナンス担当 | ツール単位の利用制御、監査ログ、チーム別の権限制御が設計されているか |
| 課金APIや社内システムをAIエージェントに接続している担当者 | エージェントのループや誤呼び出しで過剰課金・誤操作が起きないか |
| これからMCPを検証するチーム | 最初からAPIMを前段に置く構成で検証するか |
Azure API ManagementのMCPサーバー管理機能は、REST APIをMCPサーバーとして公開する方法と、既存の外部MCPサーバーをAPIM経由で公開する方法を提供しています。Microsoft Learnでは、APIMにより認証、認可、監視、レート制限、IPフィルタリング、キャッシュなどを適用できると説明されています。(Microsoft Learn)
Azure利用者がすぐ確認したい設定
まず見るべきなのは、MCPサーバーの接続経路です。AIエージェントが外部MCPサーバーや社内MCPサーバーへ直接接続している場合、管理者側で呼び出し制御や監査を一元化しにくくなります。
| 確認項目 | 判断基準 | 対応の方向性 |
|---|---|---|
| MCPサーバーの公開経路 | エージェントがMCPサーバーへ直接接続している | APIMを前段に置き、APIM公開URLへ接続先を変更する |
| ツール一覧 | 使わせたくないツールがtools/listに出ている | AllowlistまたはDeny-listで一覧を制御する |
| 直接呼び出し | 非公開ツールをtools/callで呼べる | tools/call側でもブロックする |
| 認証 | APIキーだけ、または認証なしで使える | Entra ID、JWT検証、サブスクリプションキーなどを検討する |
| レート制限 | エージェントの連続呼び出しに上限がない | IP、ユーザー、チーム、サブスクリプション単位で制限する |
| ログ | 誰がどのツールを呼んだか追えない | Application InsightsやAzure Monitorへ記録する |
| コスト管理 | 有料APIを呼ぶツールに上限がない | クォータ、アラート、チーム別集計を設計する |
APIMではMCP Serversセクションから既存MCPサーバーを登録し、APIMがプロキシとして動作する構成を作れます。外部MCPサーバーを公開する場合は、MCPバージョン、認証方式、Streamable HTTPまたはSSEなどのトランスポート条件も確認が必要です。(Microsoft Learn)
ツール制御はAllowlistとDeny-listのどちらを選ぶべきか
Apps on Azure Blogでは、MCPツールアクセス制御の方法として、静的Allowlistと動的Deny-listの2パターンが紹介されています。実務では、セキュリティ重視ならAllowlist、運用負荷を下げたいならDeny-listが候補になります。(TECHCOMMUNITY.MICROSOFT.COM)
| 方式 | 仕組み | 向いているケース | 注意点 |
|---|---|---|---|
| 静的Allowlist | APIMが許可するツール一覧を固定で返し、許可外のtools/callをブロックする | 本番環境、社外MCPサーバー、権限を厳密に管理したい場合 | ツールのスキーマ変更や追加に合わせてポリシー更新が必要 |
| 動的Deny-list | MCPサーバーのtools/list応答から禁止ツールだけを取り除き、該当ツールのtools/callもブロックする | 上流MCPサーバーの変更を自動的に追いたい場合 | 新規ツールが自動的に見える可能性がある。応答本文の書き換えにも注意が必要 |
基本はAllowlistから始めるのが安全です。特に、本番データ、課金API、更新系API、管理系APIに接続するMCPサーバーでは、「明示的に許可したツールだけを見せる」設計にした方が事故を防ぎやすくなります。
Deny-listは、上流MCPサーバーのツール追加を柔軟に取り込みたい場合に便利です。ただし、禁止リストへ入れ忘れた新規ツールが利用者に見える可能性があります。検証環境や信頼できる社内MCPサーバーでは選択肢になりますが、本番利用では監視とレビューをセットにしてください。
tools/listだけでは不十分な理由
MCPでは、エージェントが接続時に利用可能なツール一覧を取得するためにtools/listを呼びます。その後、実際にツールを実行する際にtools/callを送ります。
そのため、たとえばdelete_resourceのような危険なツールを一覧から消しても、別のクライアントが名前を知っていて直接tools/callを投げれば、バックエンドに届く可能性があります。実務では次の2段構えが必要です。
| 制御対象 | 目的 |
|---|---|
tools/list | エージェントに不要なツールを認識させない |
tools/call | 非公開ツールの直接実行を止める |
この考え方は、通常のAPI管理で「ドキュメントに載せない」だけでは不十分で、実際のエンドポイントにも認可が必要なのと同じです。MCPでも、見せない制御と実行させない制御を分けて設計してください。
認証・認可で確認すべきポイント
APIM MCP Gatewayを使うなら、ツール制御だけでなく、誰がMCPサーバーを使えるのかも整理する必要があります。Microsoft Learnでは、MCPサーバーへのインバウンドアクセスと、APIMからバックエンドMCPサーバーへのアウトバウンドアクセスの両方を保護できると説明されています。(Microsoft Learn)
実務では、少なくとも次の観点で確認します。
| 観点 | 確認内容 |
|---|---|
| 利用者認証 | Entra IDのトークン、JWT検証、サブスクリプションキーなどで利用者を識別できるか |
| チーム別制御 | 開発、運用、セキュリティなどのチームごとに利用できるツールを分けられるか |
| バックエンド認証 | APIMから上流MCPサーバーへ渡す認証情報を安全に管理しているか |
| トークン転送 | バックエンドがAuthorizationヘッダーを必要とする場合、APIMポリシーで正しく転送しているか |
| 秘密情報管理 | クライアント設定ファイルにAPIキーやトークンを平文で置いていないか |
特にVS Codeやエージェント設定にサブスクリプションキーを含める場合は、リポジトリへ誤ってコミットしない運用が必要です。チーム共有の.vscode/mcp.jsonに秘密情報を直書きするのではなく、ワークスペース設定や安全な入力方式を使う方が安全です。
監視とログで見るべきポイント
MCPはAIエージェント経由で利用されるため、通常のAPIよりも「誰が意図して呼んだのか」が見えにくくなりがちです。APIMを前段に置く価値は、ツール制御だけでなく、監査と可観測性にもあります。
Microsoft Learnでは、MCPサーバーの監視にAzure MonitorやApplication Insightsを使い、MCPリクエスト、レスポンス、診断情報、相関ID、トレースポリシーを活用することが案内されています。(Microsoft Learn)
運用ログでは、次の情報を追えるようにしておくと障害調査と監査がしやすくなります。
| ログ項目 | 使い道 |
|---|---|
| 利用者IDまたはクライアントID | 誰がツールを使ったかを確認する |
| 呼び出されたツール名 | 危険なツールや高コストツールの利用状況を把握する |
| リクエスト数 | エージェントのループや過剰呼び出しを検知する |
| レスポンスコード | 認可失敗、レート制限、バックエンド障害を切り分ける |
| 相関ID | エージェント、APIM、バックエンド間の追跡に使う |
| サブスクリプションやチーム情報 | 部門別の利用状況やコスト按分に使う |
運用上の注意点
APIM MCP Gatewayを導入する際に、特に失敗しやすいのはレスポンス本文の扱いです。Microsoft Learnでは、MCPサーバーポリシー内でcontext.Response.Bodyにアクセスするとレスポンスバッファリングが発生し、MCPサーバーに必要なストリーミング動作へ干渉する可能性があると注意しています。(Microsoft Learn)
Deny-list方式では、tools/listの応答を書き換えるためにレスポンス本文を読む設計になりやすくなります。tools/listのような非ストリーミング応答では成立する場合がありますが、エージェントホストやMCPサーバーの実装差で問題が出る可能性があります。本番投入前に、少なくとも次の3点を確認してください。
| テスト項目 | 期待する結果 |
|---|---|
tools/listの結果 | 許可したツールだけが表示される |
禁止ツールのtools/call | JSON-RPCエラーなどで確実にブロックされる |
| 許可ツールの実行 | APIM経由でも正常にバックエンドまで到達する |
また、APIMのMCPサーバー機能には制限もあります。Microsoft Learnでは、MCPサーバー管理機能がDeveloper、Basic、Standard、Premium、Basic v2、Standard v2、Premium v2で利用可能である一方、MCPサーバー機能は現時点でworkspacesではサポートされないと説明されています。構成済みのAPIMがworkspaces前提の運用になっている場合は、設計上の前提を確認してください。(Microsoft Learn)
まず実施したい確認チェックリスト
今回のNoticeを受けて、Azure管理者は次の順番で確認すると効率的です。
| 優先度 | 確認内容 | 対応例 |
|---|---|---|
| 高 | MCPサーバーを直接エージェントに公開していないか | APIMのMCP Serverとして登録し、クライアント接続先をAPIM URLに変更する |
| 高 | 不要なツールがエージェントに見えていないか | Allowlistで公開ツールを固定する |
| 高 | 禁止ツールを直接tools/callできないか | APIMポリシーで該当ツール名をブロックする |
| 中 | レート制限・クォータがあるか | IP、サブスクリプション、ユーザー単位で制限する |
| 中 | 認証方式が組織標準に合っているか | Entra ID、JWT検証、サブスクリプションキーを整理する |
| 中 | ログと監査証跡が残るか | Azure Monitor、Application Insights、Log Analytics連携を確認する |
| 低 | ツール追加時のレビュー手順があるか | MCPツールカタログの変更を定期確認する |
特に、本番データにアクセスするツール、課金が発生するAPIを呼ぶツール、書き込み・削除を行うツールは、最初から「使える前提」ではなく「明示的に許可するまで使えない」設計にしておくべきです。
まとめ：MCP利用はAPIMで「見せる前」に制御する
「Controlling Tool Access with APIM MCP Gateway」は、新機能の単なる紹介ではなく、MCPを業務利用する際の実務的なガバナンス設計を示す内容です。Azure利用者がすぐ確認すべきことは、MCPサーバーの前段にAPIMを置けるか、公開するツールをAllowlistで管理できるか、tools/listとtools/callの両方を制御しているかです。
MCPはAIエージェントの活用範囲を広げますが、同時に「AIがどのツールを呼べるのか」という新しい管理ポイントを生みます。まずは利用中のMCPサーバーと公開ツールを棚卸しし、危険度の高いツールからAPIM MCP Gatewayによる認証、レート制限、ログ、ツール単位制御を適用していきましょう。
コメント