Azure API Managementの今回の更新で押さえるべき結論は、MCPツールやA2A APIの入出力にも、Azure AI Content Safetyを使ったコンテンツ安全性制御を一貫して適用できるようになったことです。これにより、AIエージェント、MCPベースのツール、Agent-to-Agent通信を個別実装のフィルターで守るのではなく、Azure API Managementを共通のAIゲートウェイとして使い、同じポリシーで安全性・監査・運用をそろえやすくなります。
2026年6月3日に公開または更新されたAzure Updatesでは、「Azure API Management now supports content safety controls for MCP and A2A APIs」が一般提供として案内されています。特に、Copilot連携、社内エージェント、MCPサーバー、A2A APIを本番環境に展開し始めている組織では、単なる新機能ではなく、AIガバナンスの設計を見直すきっかけになります。(Microsoft Azure)
Microsoft AzureのAI/Copilot更新で何が変わるのか
今回の変更は、Azure API Managementのllm-content-safetyポリシーが、従来のLLMトラフィックに加えて、MCPとA2Aの通信にも適用できるようになった点が中心です。MicrosoftのBuild 2026関連情報では、MCPのツール呼び出し引数、MCPの応答テキスト、A2Aペイロードも対象になると説明されています。さらに、アウトバウンドポリシーとしての設定や、長いメッセージを検査するためのwindow-size、window-overlap-sizeも示されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 観点 | これまで起きやすかった課題 | 今回の更新でできること |
|---|---|---|
| MCPツールの安全性 | ツールごとに独自フィルターを実装し、判定基準がばらつく | API Management側でMCPツール呼び出しや応答に安全性ポリシーを適用しやすくなる |
| A2A APIの統制 | エージェント間通信が通常のAPI管理の外側に置かれやすい | JSON-RPCベースのA2A APIをAPI Managementで管理し、ポリシーや監視を適用できる |
| コンプライアンス | LLM、ツール、エージェントで監査ログやブロック基準が分断する | 入口と出口のポリシーをAzure API Managementに集約できる |
| 運用 | アプリごとに改修が必要で、変更時の影響範囲が見えにくい | グローバル、製品、API単位など、API Managementのスコープで段階的に適用できる |
| 長文・ストリーミング | 応答の一部だけを検査する、または検査を諦める実装になりやすい | ウィンドウサイズや重複幅を考慮して、長い応答の検査設計をしやすくなる |
重要なのは、「AIモデルのプロンプトだけを検査する機能」ではなくなってきたことです。MCPツールが社内データベースを検索したり、A2A APIで別のエージェントに処理を委譲したりする場合、危険な入力や出力はLLMの前後だけで発生するとは限りません。Azure API ManagementをAIゲートウェイとして置くことで、モデル、ツール、エージェント間通信をまとめて制御する設計が現実的になります。
Azure API Managementで扱う「MCP」と「A2A API」の位置づけ
MCPは、AIエージェントやLLMが外部ツール、API、データソースにアクセスするための仕組みです。Azure API Managementでは、既存のMCPサーバーを安全に公開し、認証、認可、監視、スケーリングを集中管理する用途が想定されています。Microsoft Learnでも、MCPサーバーをGitHub Copilot、ChatGPT、ClaudeなどのAIエージェントやLLM向けに安全に公開・管理するシナリオが説明されています。(Microsoft Learn)
A2A APIは、AIエージェント同士がやり取りするためのAPIです。Azure API ManagementのA2Aサポートでは、Agent2Agentプロトコル仕様に対応したAIエージェントAPIを、REST、SOAP、GraphQL、MCPツール、AIモデルAPIなどと並べて管理できます。A2A APIをインポートすると、JSON-RPCランタイム操作の仲介、ポリシーによるガバナンス、Application Insightsを使った観測性の強化が可能になります。(Microsoft Learn)
実務上は、次のような使い分けで考えると分かりやすくなります。
| 種類 | 主な役割 | 例 |
|---|---|---|
| LLM API | モデルにプロンプトを送り、回答を得る | Azure OpenAI、Microsoft Foundry上のモデル |
| MCPサーバー | エージェントが使うツールや外部データへの接続口 | 社内検索、チケット作成、在庫照会、ワークフロー実行 |
| A2A API | エージェント同士の依頼・応答・連携 | 営業支援エージェントが見積エージェントへ処理を依頼する |
| Azure API Management | これらの通信を制御・監視するゲートウェイ | 認証、レート制限、Content Safety、ログ、ルーティング |
今回の更新が管理者に与える影響
Azure API Managementのゲートウェイは、APIリクエストをバックエンドへ中継し、ポリシーを適用し、テレメトリを収集する役割を持ちます。具体的には、APIキーやJWTなどの検証、利用制限、リクエスト・レスポンス変換、ログ・メトリック・トレースの出力などを担います。(Microsoft Learn)
今回の更新により、管理者は従来の「APIを公開するためのゲートウェイ」としてだけでなく、「AIエージェントの行動を統制する実行時の境界」としてAzure API Managementを設計する必要があります。
特に影響が大きいのは、次のような環境です。
| 対象環境 | 影響 | 優先して確認すべきこと |
|---|---|---|
| 社内CopilotやAIエージェントにMCPツールを接続している | ツール呼び出しの引数や応答も安全性チェックの対象にできる | どのMCPツールが外部入力や機密データを扱うか |
| 複数のAIエージェントをA2A APIで連携させている | エージェント間通信をAPI管理の対象にできる | JSON-RPCベースか、Agent Cardが適切に構成されているか |
| LLM APIと業務APIを別々に管理している | 安全性・認証・監視のポリシーを統一しやすくなる | 既存のAPIMポリシーとAI向けポリシーの重複 |
| アプリごとに独自のNGワード・安全性チェックを実装している | 共通ポリシーへ段階的に移行できる | 既存フィルターとの二重ブロック、誤検知、ログ設計 |
| 本番でストリーミング応答を使っている | 違反検出時のレスポンス挙動が通常の403と異なる場合がある | クライアント側の表示、再試行、監視ルール |
AIエージェントが業務システムを操作するようになると、「モデルが安全か」だけでは不十分です。どのツールを呼べるのか、どんな引数を渡せるのか、別のエージェントに何を依頼できるのか、応答に不適切な内容が含まれていないかまで確認する必要があります。
llm-content-safetyポリシーでできること
llm-content-safetyポリシーは、LLMのリクエストやレスポンスをAzure AI Content Safetyに送信し、安全性チェックを実施するポリシーです。Microsoft Learnでは、このポリシーがAPI Managementで管理されるMCPツールやA2A Agent APIのリクエスト・レスポンスにも適用できると説明されています。Azure AI Content Safetyが悪意ある内容を検出した場合、API Managementはリクエストまたはレスポンスをブロックし、403エラーを返します。(Microsoft Learn)
主に次の用途で使います。
- 有害コンテンツやヘイト、暴力、自傷、性的内容などを含むリクエストやレスポンスをブロックする
- 組織独自のブロックリストを使い、特定の語句や表現を送受信させない
- プロンプト攻撃に該当する可能性のある入力を検出する
- MCPツールやA2A APIにも、LLM APIと同じ安全性基準を適用する
ただし、これは万能なDLP機能ではありません。個人情報、機密情報、営業秘密の持ち出し対策まで完全に置き換えるものではなく、認可、データ分類、監査ログ、Microsoft Purviewなどのデータ保護施策と組み合わせて設計するべきです。
管理者が確認すべき前提条件
llm-content-safetyを使うには、Azure AI Content Safetyリソースと、API Managementからそのサービスへ接続するためのバックエンド設定が必要です。Microsoft Learnでは、API ManagementのマネージドIDにAzure AI Content Safety側でCognitive Services Userロールを付与すること、バックエンドURLをhttps://<content-safety-service-name>.cognitiveservices.azure.com形式にすること、認証資格情報をマネージドIDで構成することが前提として示されています。 (Microsoft Learn)
確認項目を実務向けに整理すると、次の通りです。
| 確認項目 | 見るべきポイント | 失敗しやすいポイント |
|---|---|---|
| Azure AI Content Safetyリソース | 利用するサブスクリプション、リージョン、権限 | 開発環境と本番環境で別リソースにせず、検証結果が混ざる |
| API ManagementのマネージドID | システム割り当てIDまたはユーザー割り当てIDの利用方針 | IDは有効だが、Content Safety側のRBACが不足している |
| APIMバックエンド | Content Safety APIへ向けるバックエンドID | llm-content-safetyのbackend-idと実際のバックエンド名が不一致 |
| 認証方式 | マネージドIDでContent Safetyへ認証 | APIキーをアプリやポリシーに埋め込んで運用してしまう |
| ネットワーク | APIMからContent Safetyへ到達できるか | 閉域・Private Link・ファイアウォール構成で疎通を確認していない |
| 権限分離 | ポリシー編集者、セキュリティ管理者、開発者の役割 | すべての開発者が本番ポリシーを変更できる状態にする |
最初にやるべきことは、いきなりポリシーを書くことではありません。まず、どのAPI Managementインスタンスで、どのMCPサーバー、A2A API、LLM APIを扱っているかを棚卸ししてください。特にPoCから本番へ昇格したエージェントは、管理者が把握していないMCPツールを持っていることがあります。
ポリシー適用スコープの考え方
llm-content-safetyポリシーは、グローバル、ワークスペース、製品、APIなどのスコープで使えます。Microsoft Learnのポリシーリファレンスでも、利用できるポリシーセクションとしてinboundとoutbound、スコープとしてglobal、workspace、product、APIが示されています。(Microsoft Learn)
おすすめは、次の順に段階展開することです。
| 段階 | 適用範囲 | 目的 |
|---|---|---|
| 検証 | 開発用APIまたはテスト用MCPサーバー | 403の発生条件、誤検知、レイテンシを確認する |
| 小規模展開 | 特定の製品または低リスクAPI | 実ユーザーに近い通信で運用影響を測る |
| 本番展開 | 重要度の高いMCP/A2A/LLM API | 安全性基準を本番運用に組み込む |
| 標準化 | グローバルまたは共通ポリシーフラグメント | チーム間で安全性ルールを統一する |
注意したいのは、グローバルスコープにいきなり強い制限を入れないことです。A2A APIのドキュメントでは、グローバルスコープのポリシーがA2A Agent APIスコープのポリシーより先に評価されると説明されています。つまり、全体ポリシーでブロックされた通信は、個別API側で後から救済できない設計になりやすいということです。(Microsoft Learn)
inboundとoutboundのどちらで検査するべきか
安全性チェックは、リクエストを見るのか、レスポンスを見るのかで配置が変わります。
| 配置 | 主な対象 | 使う場面 |
|---|---|---|
inbound | ユーザー入力、MCPツール呼び出し引数、A2Aリクエスト | 危険な依頼をバックエンドやエージェントへ渡す前に止めたい |
outbound | LLM応答、MCPツール応答、A2Aレスポンス | 利用者へ返す内容に不適切な表現が含まれないか確認したい |
inboundのenforce-on-completions | チャット補完の応答検査 | LLM APIのリクエストと応答をまとめて検査したい |
ポリシーリファレンスでは、リクエストを検査する場合はinbound、レスポンスを検査する場合はoutboundに構成すると説明されています。また、enforce-on-completionsはinboundに設定した場合にチャット補完の応答検査にも使われ、outboundでは無視されます。(Microsoft Learn)
MCPやA2Aの運用では、リクエスト側だけでなくレスポンス側も重要です。たとえば、ユーザーの依頼自体は問題なくても、MCPツールが取得したデータや別エージェントからの応答に不適切な内容が含まれる可能性があります。外部に返す前の出口対策として、outboundの設計も検討してください。
カテゴリ、しきい値、ブロックリストの決め方
llm-content-safetyでは、Hate、SelfHarm、Sexual、Violenceのカテゴリを指定できます。しきい値は0から7の範囲で指定し、値が小さいほど厳しく、大きいほど許容範囲が広くなります。Microsoft Learnの例では、HateとViolenceをしきい値4でブロックする例が示されています。(Microsoft Learn)
実務では、すべてのAPIに同じしきい値を入れるより、用途別に分けた方が安全です。
| API・ツールの用途 | 設定方針の例 | 注意点 |
|---|---|---|
| 一般社員向け社内Copilot | 厳しめのしきい値から検証し、誤検知を調整 | 業務用語が誤って有害表現に見えるケースを確認する |
| カスタマーサポート | ユーザー入力に強めの検査、応答にも検査 | クレーム文や障害報告を過度にブロックしないようにする |
| 医療・メンタルヘルス関連 | 自傷カテゴリの扱いを慎重に設計 | 必要な支援情報まで遮断しないよう専門部署と確認する |
| ゲーム・映像・ニュース系 | 暴力カテゴリの誤検知に注意 | 作品名、報道、レビュー文脈をテストする |
| 社内管理ツール操作系MCP | プロンプト攻撃対策を優先 | 危険な命令をツール呼び出し前に止める |
ブロックリストは、組織として必ず止めたい語句や表現を追加する補助的な仕組みとして有効です。ただし、表記ゆれ、言い換え、別言語化まですべて拾えるわけではありません。ブロックリストだけで機密情報漏えい対策を完結させるのではなく、アクセス制御やデータ分類と組み合わせる必要があります。
最小構成のポリシー例
以下は、inboundでリクエストを検査する構成イメージです。実際の本番環境では、backend-id、カテゴリ、しきい値、スコープ、outboundでの応答検査を自社のリスク基準に合わせて調整してください。
<policies>
<inbound>
<base />
<llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
<categories output-type="EightSeverityLevels">
<category name="Hate" threshold="4" />
<category name="SelfHarm" threshold="4" />
<category name="Sexual" threshold="4" />
<category name="Violence" threshold="4" />
</categories>
</llm-content-safety>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>この例をそのまま全APIへ適用するのは避けてください。業務領域によっては、暴力、医療、自傷、性的表現が文脈上必要な場合があります。まずはテスト環境で、正常系、危険入力、長文入力、ストリーミング応答、A2A応答を使って、ブロック率と誤検知を確認することが重要です。
MCPとA2Aで特に注意したい制限
A2A APIについては、Azure API Managementが対応するのはJSON-RPCベースのA2A Agent APIです。Microsoft Learnの制限事項では、JSON-RPCベースのA2A Agent APIのみがサポートされ、送信レスポンス本文のデシリアライズはサポートされないと説明されています。(Microsoft Learn)
また、ゲートウェイやサービス階層によって使える機能が異なります。API Managementのゲートウェイ比較では、A2A agentはClassicとV2ではサポートされる一方、Consumption、self-hosted、workspaceでは非対応として示されています。MCPサーバーについても、pass-through MCP serverやREST APIのMCP server公開はClassic、V2、self-hostedでサポートされ、Consumptionやworkspaceでは制約があります。(Microsoft Learn)
| 確認ポイント | なぜ重要か |
|---|---|
| A2A APIがJSON-RPCベースか | 対応外の通信形式では、想定通りにAPI Managementで管理できない |
| Agent CardのURLとRuntime URL | クライアントがAPIM経由ではなくバックエンドへ直接接続すると統制を回避される |
| APIMのサービス階層 | A2A、MCP、ポリシー、監視機能の利用可否が階層で変わる |
| self-hosted gateway利用有無 | AI向け機能やA2Aの扱いがマネージドゲートウェイと異なる場合がある |
| workspace利用有無 | MCPやA2Aの管理対象がワークスペースで期待通り動くか確認が必要 |
| ストリーミング応答 | 違反検出時に通常のHTTP 403と異なる見え方になる場合がある |
特に、既存のAPI Managementをそのまま使えばすべてのAI機能が動くと考えるのは危険です。本番展開前に、利用中のサービス階層、ゲートウェイ種別、リージョン、ネットワーク構成、Azure AI Content Safetyへの到達性を確認してください。
ストリーミング応答と長文レスポンスの注意点
ストリーミング応答では、違反が検出されたときに通常のREST APIのような403が返らない場合があります。Microsoft Learnでは、ストリーミング応答ではイベントをスライディングウィンドウでバッファし、コンテンツ安全性違反が検出されると、それ以降のイベント転送を停止すると説明されています。(Microsoft Learn)
これは、チャットUIやエージェントUIの設計に影響します。たとえば、途中まで文章が表示された後で急に応答が止まる可能性があります。その場合、ユーザーには「安全性ポリシーにより応答を停止しました」のような分かりやすいメッセージを表示する必要があります。
また、window-sizeやwindow-overlap-sizeを調整すると、長文検査の精度とContent Safety呼び出し回数のバランスが変わります。重複幅を大きくすると文脈をまたいだ検出には有利になる可能性がありますが、検査対象が増えるため、レイテンシやコストにも影響します。実運用では、代表的な長文応答を使って負荷試験を行ってください。
導入手順：本番展開までの進め方
今回の更新を安全に活用するには、次の順番で進めるのが現実的です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | MCPサーバー、A2A API、LLM APIを棚卸しする | API一覧、所有チーム、利用者、データ種別 |
| 2 | 安全性ポリシーの基準を決める | カテゴリ、しきい値、ブロックリスト、例外条件 |
| 3 | Azure AI Content SafetyとAPIMバックエンドを構成する | Content Safetyリソース、RBAC、backend-id |
| 4 | テスト用APIにllm-content-safetyを適用する | 検証用ポリシー、テストケース |
| 5 | 正常系・異常系・長文・ストリーミングを検証する | 403発生条件、レイテンシ、誤検知一覧 |
| 6 | 一部の製品またはAPIへ段階展開する | カナリア展開、監視ダッシュボード |
| 7 | 標準ポリシーとして横展開する | 共通ポリシーフラグメント、運用手順書 |
| 8 | 定期レビューする | ブロック率、誤検知、例外申請、ポリシー変更履歴 |
テストケースは、単に「危険な単語を入れる」だけでは不十分です。MCPツールやA2A APIでは、命令の意図が複数ステップに分かれることがあります。たとえば、最初のエージェントには無害に見える依頼でも、別エージェントへ渡すと権限の高い操作になる場合があります。
検証時は、次のようなケースを含めると実運用に近づきます。
- 通常の業務質問
- 社内データ検索を伴うMCPツール呼び出し
- 書き込み系MCPツールの呼び出し
- A2A APIで別エージェントへ処理を依頼するケース
- プロンプトインジェクションを含む入力
- 長文の添付内容や議事録要約
- ストリーミング応答
- 誤検知が起きやすい業務用語、製品名、略語
既存の独自フィルターから移行するときの注意点
すでにアプリ側でNGワードチェックや独自のプロンプト防御を実装している場合、Azure API Management側のContent Safetyを追加すると、二重にブロックされる可能性があります。移行時は、どちらが最終的な判定者なのかを決めておくべきです。
| よくある失敗 | 起きる問題 | 対策 |
|---|---|---|
| アプリ側とAPIM側で別々のしきい値を使う | どこでブロックされたのか分からない | ブロック理由、ステータスコード、ログ項目を統一する |
| いきなりグローバルポリシーへ適用する | 無関係なAPIまで停止する | API単位または製品単位で段階展開する |
| 403をクライアントが通常エラーとして再試行する | 同じ危険リクエストを繰り返す | 403時は自動再試行せず、ユーザーに入力修正を促す |
| プロンプトや応答を過剰にログ出力する | 機密情報や個人情報がログに残る | ログ対象、保持期間、マスキング方針を決める |
| 誤検知レビューの運用がない | 現場が回避策を作り始める | 例外申請、レビュー担当、変更履歴を整備する |
| MCPツールの直アクセスを残す | APIMの安全性ポリシーを迂回される | クライアントはAPIM経由のURLだけを使うよう制御する |
移行で大切なのは、「止めること」よりも「止めた理由を説明できること」です。セキュリティ部門、開発チーム、業務部門が同じログを見て、どのカテゴリで、どのしきい値により、どの通信がブロックされたのかを確認できる状態にしてください。
開発者が実装で気をつけること
開発者側では、API Managementでコンテンツ安全性制御が入ることを前提に、クライアントとバックエンドの挙動を見直す必要があります。
まず、403を単なる認証エラーとして扱わないことです。Content Safetyによるブロックも403になるため、UIでは「権限がありません」だけでなく、「安全性ポリシーにより処理できませんでした」のようなメッセージを出し分ける設計が望ましいです。
次に、A2AやMCPのリクエストID、ユーザーID、エージェントIDをトレースできるようにします。A2A APIでは、Application Insightsを有効にした場合、OpenTelemetry GenAI semantic conventionに沿ったA2A固有属性が追加されると説明されています。(Microsoft Learn)
最後に、ポリシーで止められた通信をバックエンドで再送しないことです。クライアントやエージェントランタイムが自動再試行する設計だと、同じ危険な依頼を何度も送信し、ログやコストを増やす原因になります。
監視・ログ・コストで見るべき指標
Azure API ManagementのAI gatewayでは、トークン使用量、ログ、Application Insights、Azure Monitorなどを使ってAI APIの利用状況を把握できます。Microsoft Learnでは、プロンプトと補完のログ、Application Insightsでの消費者別トークンメトリック、組み込み監視ダッシュボード、カスタムディメンションによるメトリック出力などが説明されています。(Microsoft Learn)
Content SafetyをMCPやA2Aに広げる場合、次の指標を見てください。
| 指標 | 見る理由 |
|---|---|
| 403件数 | ブロックが急増していないか、誤検知が多くないかを確認する |
| API別ブロック率 | 特定のMCPツールやA2A APIに問題が集中していないかを見る |
| レイテンシ | Content Safety呼び出しによる応答遅延を確認する |
| Content Safety呼び出し回数 | コストやスループットへの影響を把握する |
| ストリーミング停止件数 | 途中停止がユーザー体験を悪化させていないかを見る |
| 例外申請件数 | ポリシーが現場の業務に合っているかを判断する |
| エージェントID別の傾向 | 特定エージェントの設計やプロンプトに問題がないかを見つける |
ログを有効にする場合は、プロンプトや応答本文をそのまま保存するかどうかを慎重に決めてください。安全性向上のためのログが、別の機密情報リスクを生むことがあります。特に、MCPツールが顧客情報、契約情報、障害情報、ソースコードを扱う場合、ログの保存範囲と保持期間は必ずセキュリティ・法務・コンプライアンス担当と確認しましょう。
この更新を活用すべき組織
今回の一般提供は、次のような組織に特に有効です。
| 組織・チーム | 活用メリット |
|---|---|
| 社内AI基盤チーム | LLM、MCP、A2Aをまたいだ安全性ポリシーを標準化できる |
| APIプラットフォームチーム | 既存のAPI Management運用をAIエージェント領域に拡張できる |
| セキュリティ部門 | ツール実行やエージェント間通信を監査対象にしやすくなる |
| 業務アプリ開発チーム | 個別の安全性チェック実装を減らし、共通基盤に寄せられる |
| Copilot拡張を進めるチーム | MCPツールの公開時に、アクセス制御とContent Safetyをまとめて設計できる |
一方で、まだMCPやA2Aを使っていない組織では、すぐに既存システムへ影響が出るとは限りません。ただし、今後Copilot拡張、社内エージェント、AIワークフローを導入する予定があるなら、早い段階でAzure API ManagementをAIゲートウェイとして設計に入れておく価値があります。
まず何をすべきか
今回のAzure API Management更新で最初にやるべきことは、機能を有効化することではなく、AI通信経路の棚卸しです。どのアプリがLLM APIを呼び、どのエージェントがMCPツールを使い、どこでA2A APIが発生するのかを確認してください。
そのうえで、開発環境にAzure AI Content SafetyリソースとAPIMバックエンドを用意し、llm-content-safetyポリシーをAPI単位で試します。正常な業務入力、危険入力、長文応答、ストリーミング、A2A連携をテストし、403の扱い、誤検知、レイテンシ、ログを確認します。
MCPやA2Aを本番利用する組織では、今後「エージェントが何を言ったか」だけでなく、「エージェントがどのツールをどの引数で呼び、別エージェントに何を依頼したか」まで管理対象になります。Azure API ManagementのContent Safety対応は、その統制をアプリごとの個別実装ではなく、共通のAPI管理基盤で実現するための重要な一歩です。
コメント