ヘッドウォータース
🧭

Azure APIM の AI Gateway を深掘りする──信頼境界・資格情報終端・Foundry との責務分離

毎熊　星湾
に公開
Azure
AI Gateway
apim
tech

Azure APIM の AI Gateway は「どこに置くか」より「どこで終端するか」が重要

AI Gatewayとは何か──ベンダー中立に整理する概念・ユースケース・Azure/AWSでの実装像 と Azure API Management 完全ガイド: 機能・ユースケース・Azure統合まで を踏まえると、APIM を AI Gateway として使う理由や、JWT / Managed Identity / Credential Manager の基本像が理解可能です。

そのうえで次に詰まりやすいのが、APIM を前段に置いた後、どの境界で認証責務を終端し、どの境界で別の資格情報に切り替えるか です。

本稿はそこだけに焦点を当てます。つまり、AI Gateway の導入判断をもう一度やり直す記事ではなく、導入前提で設計を深掘りする発展編です。扱う論点は次の 4 つです。

  • フロント側の OAuth / JWT をバックエンド認証の代替と誤解しないこと
  • Azure ネイティブ backend では credential termination and reestablishment を第一原則にすること
  • MCP / 外部 API では inbound と outbound を別設計にすること
  • Foundry Agent Service を含むときは APIM と Foundry の責務を分離すること

結論を先に一文で言うと、次のとおりです。

APIM の AI Gateway 設計で本当に重要なのは「入口を 1 枚に寄せること」ではなく、「どの資格情報をどこで終端し、次の境界で誰の権限に張り替えるか」を明確にすることです。

関連記事

必要に応じて、以下の関連記事を参照して、AZURE APIMおよびAI GATEWAYに関する理解を持つことをお勧めいたします。

第一原則: credential termination and reestablishment

このテーマで最も重要なのは、Microsoft の Architecture Center のガイダンス が推奨する credential termination and reestablishment です。

意味はシンプルで、クライアント資格情報を gateway で一度終端し、その先は gateway 自身の権限で backend に接続する、ということです。

[User / Client]
      |
      | user token / client credential
      v
    [APIM]
      |
      | APIM-managed credential
      v
[Model / Tool / External backend]

ここで重要なのは、「通した token をそのまま奥へ流す pass-through が悪である」という単純な話ではないことです。実際には pass-through が必要な場面もあります。ただし、Azure ネイティブ backend では pass-through よりも終端と再認可を基本形にすべき です。理由は明快です。

  • client 側と backend 側の信頼境界を明確に分離できる
  • backend 資格情報をクライアントに持たせずに済む
  • backend への直接迂回を防ぎやすい
  • gateway 側の identity に最小権限を与える構成にしやすい

逆にここを曖昧にすると、「フロント側で OAuth を検証しているからバックエンド側は何もしなくてよいのでは」という誤解に直結します。この誤解は、Authenticate and authorize access to LLM APIs by using Azure API Management でも明確に否定されています。

フロント側の OAuth はバックエンド認証の代替ではない

この一文だけで、本稿の半分くらいは説明できます。

user/client -> APIM の認可と、APIM -> backend の認証は別の責務です。

前段で Entra ID や OAuth 2.0 による認可をしていても、それは「そのユーザーやアプリを APIM に入れてよいか」を判定しているだけです。Azure OpenAI / Foundry / MCP backend が APIM を信頼する理由にはなりません。

この 2 つを混同すると、設計レビューで次のような危険な会話が起きます。

  • 「もう Bearer token はチェックしているから、バックエンドはそのままでいいですよね」
  • 「APIM の前段で Entra 認証をかけているので、Managed Identity はなくても大丈夫ですよね」

どちらも危険です。前者は認可と認証の混同、後者は信頼境界の混同です。便利そうに見えますが、実際には責務が宙に浮くだけです。セキュリティ設計では、宙に浮いた責務はたいてい事故に着地します。

認証責務は 4 つの境界に分かれる

基礎編で扱った話を最小限だけ再掲すると、AI Gateway では認証責務を少なくとも次の 4 つに分けて考えると整理しやすくなります。

[User / Client]
      |
      | ① user/client -> APIM
      v
    [APIM]
      |
      | ② APIM -> Azure OpenAI / Foundry
      | ③ APIM -> external API / MCP backend
      v
[Models / Tools / External backends]
      |
      | ④ agent -> MCP / A2A
      v
[Remote tools / remote agents]
境界 主な責務 第一候補
① user/client → APIM 入口での認可 Entra ID / OAuth 2.0 / JWT 検証
② APIM → Azure OpenAI / Foundry Azure ネイティブ backend 認証 Managed Identity + Azure RBAC
③ APIM → 外部 API / MCP backend backend credential broker named value / Key Vault / Credential Manager / token forward
④ agent → MCP / A2A 誰の権限で実行するか shared auth または OAuth identity passthrough

ここで本稿が重視するのは、①の実装詳細よりも ②〜④でどの権限主体を選ぶか です。①の JWT / subscription key / claim validation の話は、既存記事 Azure API Management における認証と認可 のほうが詳しいので、ここでは繰り返しません。

ただし 1 点だけ再確認しておくと、subscription key は依然として有用です。利用者識別・メータリング・契約単位の切り分けには向いています。しかし、ユーザー本人性やロールベース認可の主担当にするには弱い。そこはやはり JWT / OAuth の役割です。

Azure ネイティブ backend は Managed Identity を標準解に寄せる

Authenticate and authorize access to LLM APIs by using Azure API Management が示すとおり、Azure OpenAI および Foundry の model deployment に対しては、Managed Identity + Azure RBAC が第一候補です。

構成自体は既存記事で説明済みなので、ここでは設計原則だけを強調します。

  • APIM に system-assigned または user-assigned managed identity を付与する
  • backend 側にはその identity に対する最小権限だけを付与する
  • APIM が backend token を取得し、Authorization: Bearer を組み立てる

この構成の本質は、「シークレットレスだから嬉しい」だけではありません。backend が信頼する主体を user ではなく APIM に固定できる ことにあります。

それによって、次の設計が可能になります。

  • user / client の認可判断は APIM 入口で行う
  • backend 側は APIM の managed identity だけを信頼する
  • client が backend の資格情報や endpoint 事情を知らなくてもよくなる

pass-through を選ぶ前に確認すべきこと

Azure ネイティブ backend に対して pass-through を選びたくなるのは、典型的には「ユーザー単位の権限を最後まで残したい」ときです。しかし、その前に次の問いを確認すべきです。

  1. backend は本当に user context を必要としているか
  2. gateway を経由しない bypass 経路は存在しないか
  3. user context を残したいのは認可判断のためか、監査のためか

監査のためだけなら、APIM から user claim を header として転送しつつ、backend 認証は Managed Identity にするほうが安全です。user context が必要なのか、user credential が必要なのかは別問題 です。ここは意外と混ざります。

外部 API / MCP では inbound と outbound を分離する

Azure OpenAI / Foundry の外に出ると、Managed Identity 一択では解けません。外部 LLM、OpenAI 互換 API、SaaS、remote MCP backend では、APIM は credential broker として振る舞います。

代表的な選択肢は次のとおりです。

  • API key / bearer token を named value に保持する
  • secret を Key Vault reference に逃がす
  • OAuth 2.0 対応 backend には Credential Manager を使う
  • 必要に応じて inbound token を backend に forward する

ここで重要なのは、「外部 backend だから仕方なく secret を持つ」のではなく、誰の権限で backend を呼ぶのかを先に決める ことです。

MCP は client 側認証と backend 側認証を分けて考える

Secure access to MCP servers in API Management が分かりやすいのですが、MCP では inbound と outbound を分離して考える必要があります。

  • inbound: MCP client → APIM
    • subscription key
    • Entra ID / JWT 検証
  • outbound: APIM → MCP server backend
    • Credential Manager による OAuth token 付与
    • shared credential の注入
    • 必要なら Authorization header の forward

たとえば次の 2 パターンは似て見えて、責務がまったく違います。

パターン A: client は user token、backend は shared credential

  • client は Entra JWT で APIM に入る
  • APIM はその JWT を検証する
  • backend には Credential Manager から別の shared token を注入する

このとき APIM は 入口の認可 と backend credential broker の 2 役を担っています。MCP client にとっての認証と、MCP backend にとっての認証は別物です。

パターン B: client token を backend に forward する

  • client は Entra JWT で APIM に入る
  • APIM は必要に応じて JWT を検証し、その Authorization header を backend に渡す
  • backend は user context のまま認可判断する

こちらは identity passthrough に近い構成です。成立はしますが、backend に直接アクセスできる bypass 経路が残っていると一気に危険 になります。gateway 経由時だけポリシーが効いて、直アクセス時は効かない、という最悪のパターンです。

設計レビューで先に決めるべき問い

外部 API / MCP backend の設計では、実装詳細に入る前に次の問いに答えておくと迷いにくくなります。

  • 全ユーザーが同じ権限で backend を呼べるのか
  • user ごとの権限を backend に残す必要があるのか
  • APIM に secret を持たせることを許容できるのか
  • token forward を採用したとき bypass を封じられるのか

Azure ネイティブ backend では「Managed Identity に寄せる」が標準解ですが、外部 backend では shared auth と individual auth の見極め が先に来ます。

APIM と Foundry の責務を混同しない

agent を含む構成になると、APIM の話だけでは足りません。Foundry の MCP 認証、A2A 認証、Agent identity concepts を合わせて読むと、責務分離が見えてきます。

ざっくり分けるとこうです。

  • APIM: 入口統制、JWT 検証、header 代理、credential broker、監査、公開面の整備
  • Foundry Agent Service: shared auth / individual auth の選択、agent identity のライフサイクル管理、誰の権限で tool / remote agent を呼ぶかの決定

この境界を曖昧にすると、「APIM で認証しているのだから agent 側もそのまま安全だろう」と考えがちです。しかし、実際に問題になるのは agent が誰として実行されるか です。

shared auth と individual auth の違い

Foundry 側の整理では、MCP / A2A の認証パターンは大きく 2 つです。

shared authentication

全ユーザーが同一の権限で動作してよい場合です。

  • key-based authentication
  • agent identity
  • project managed identity

適用しやすい例は、社内共通ナレッジ検索、共通 Cosmos DB コンテナー参照、全員が同じ権限で使う社内ツールです。

individual authentication

ユーザーごとに権限を保持する必要がある場合です。

  • OAuth identity passthrough

典型例は GitHub、Outlook / Calendar / Teams / SharePoint、個人ごとに見える情報が異なる SaaS です。

ここで重要なのは、「認証方式を選ぶ」のではなく、操作主体を選ぶ という視点です。MCP / A2A で問われるのは「認証できるか」ではなく、「その操作を誰の権限で実行するべきか」です。

publish 後に agent identity が変わる問題

Agent identity concepts in Microsoft Foundry で特に見落としやすいのがここです。

実務では次のような事故になります。

  1. 開発中は project 共有 identity に role assignment を付与
  2. MCP / A2A / data source への接続が正常に動く
  3. agent を publish
  4. distinct identity に切り替わる
  5. 以前の role assignment が効かなくなる
  6. 本番でだけ tool 呼び出しが失敗する

これはかなり嫌なタイプの障害です。なぜなら「開発では動いていた」のに「publish 後だけ壊れる」からです。したがって、agent をデプロイするパイプラインでは publish 後 identity を前提に RBAC を再確認する工程 を最初から入れておくべきです。

実務で刺さる落とし穴

最後に、重複説明ではなく「設計時に見落としやすいが、後で効いてくる論点」だけをまとめます。

1. APIM multi-region は完全な一元管理ではない

multi-region で replicate されるのは gateway です。management plane / developer portal は primary region にあります。また、rate-limit* や llm-token-limit のようなカウンターは regional gateway ごとに独立 して計算されます。

このため、設計者が「全世界で共通の 1 つの quota」と思っていても、実際には各 region で別々に積み上がることがあります。中央集権っぽく見えるのに、カウンターは意外と地方自治です。

2. unified gateway は global single point of regional failure になり得る

Architecture Center が指摘するとおり、single-region の unified gateway は global single point of regional failure になり得ます。

  • cross-region backend 呼び出しで latency が増える
  • egress cost が増える
  • 入口が 1 地域に集中して、その地域障害が全体停止につながる

「統一感があるから正しい」とは限らない、という好例です。見た目の美しさと故障半径はしばしば反比例します。

3. trusted service connectivity の前提はもう古い

Trusted service connectivity retirement により、APIM gateway から Storage / Key Vault / Service Bus / Event Hubs / Container Registry への trusted connectivity 依存は 2026 年 3 月 15 日に退役しました。

ここは「MI を使っているから閉域を考えなくてよい」と誤解しやすいので注意が必要です。

4. MCP は capability ごとに対応状況が違う

APIM の MCP 対応は「MCP なら全部いける」という意味ではありません。公開方式によって扱える capability が変わります。

つまり、prompts 前提の設計をすると、APIM の MCP 管理面にそのままは乗りません。

5. A2A はまだ preview 前提で見るべき

Import an A2A agent API は将来性のある機能ですが、現時点では次の制約があります。

  • preview
  • v2 tiers のみ
  • JSON-RPC ベースのみ
  • outgoing response body の deserialization 未対応

方向性としては重要です。ただし「A2A ももう APIM で本番成熟済み」と見なすのは早い。PoC の温度感と production の温度感は分けたほうが安全です。

設計レビューで確認したいこと

最後に、本稿の内容をレビュー観点に落とすと次のチェックリストになります。

設計レビューチェックリスト
  • user/client -> APIM の認可と APIM -> backend の認証を別責務として扱っているか
  • Azure ネイティブ backend では Managed Identity + RBAC を第一候補にしているか
  • user context が必要なのか、user credential そのものが必要なのかを区別しているか
  • 外部 API / MCP backend で inbound と outbound を分離して設計しているか
  • token forward を使う場合、backend への bypass 経路を閉じられているか
  • MCP / A2A では shared auth と individual auth のどちらを選ぶべきかを明示しているか
  • Foundry agent を publish した後の identity 変化と RBAC 再付与を運用に組み込んでいるか
  • multi-region 配置で regional counter の独立性を理解しているか
  • trusted service connectivity 退役後の network line-of-sight を満たしているか
  • MCP / A2A の対応 capability と preview 制約を前提に設計しているか

このチェックリストにきれいに答えられない場合、問題は「APIM の機能不足」ではなく、たいてい 責務の分け方が曖昧 なところにあります。

実例

ここまでの話を、社内チーム向けの複合ナレッジ検索 / 分析ユースケースに落とすと、責務分離の意味が見えやすくなります。

ユースケース概要

  • 社員が社内ポータルから「今回の障害に似た過去事例、関連設計書、運用手順をまとめて、影響範囲と初動案を出してほしい」と質問する
  • agent は複数の知識源をまたいで検索・要約し、最後に回答案を返す
  • ただし、共通知識と本人権限でだけ見える情報は分けて扱う

全体像

この図で見たいポイントは 3 つだけです。

  • APIM は user token を入口で検証するが、その token を Azure ネイティブ backend への信頼証明としては使わない
  • Foundry Agent Service へは、APIM が Managed Identity でつなぐ
  • Agent は接続先に応じて、Azure 内の MCP と Azure 外の MCP を呼び分けつつ、shared auth と individual auth を使い分ける

重要なのは、「Azure 内か外か」と「shared か individual か」は別軸 だということです。実際、Entra の認証情報や権限情報を使ってユーザーごとに文書参照権限を分けたいなら、Azure 内の文書基盤や Entra 連携された社内 backend のほうが設計しやすい 場面は多いです。

どこで終端し、どこで張り替えるか

ここでの役割分担を、実務向けに一行で言い切るとこうなります。

主役 何を担うか
APIM 入口認可と Azure ネイティブ backend への再認可
Agent どの情報源を使うか、および shared / individual の切り分け
MCP 各情報源への接続面の提供

何を shared にして、何を individual にするか

  • Azure 内 MCP + shared auth に寄せるもの
    • 全員が同じ権限で参照してよい設計書
    • 共通 runbook
    • 共通知識ベース
  • Azure 内 MCP + individual auth に寄せるもの
    • Entra のユーザー属性やグループで閲覧可否が変わる部門別ドキュメント
    • ユーザーごとの ACL を反映した文書検索
    • 社内の文書 API や検索基盤で、本人権限に応じて結果が変わるもの
  • Azure 外 MCP に寄せるもの
    • GitHub や Jira などの外部 SaaS
    • shared auth で十分な外部ツール
    • individual auth が必要な外部ツール

つまり、「Azure 内だから shared」「Azure 外だから individual」で決めるのではありません。配置場所ではなく、誰の権限で見るべき情報か で切るのが基本です。

アンチパターン

  • 悪い例 1: user token を APIM から agent、さらに MCP backend まで一気通貫で流す
    • bypass を閉じにくい
    • どの境界で誰を信頼しているのかが曖昧になる
  • 悪い例 2: 逆に全部を shared credential でまとめる
    • 個人ごとの差分が消える
    • 監査で「誰の権限で見えたのか」がぼやける

この実例で言いたいことはシンプルです。APIM は入口認可と backend への再認可、agent は操作主体の選択、MCP は接続先の整理 に集中させると、責務が混ざりにくくなります。

まとめ

APIM の AI Gateway を設計するとき、論点は「何を前段に置けるか」ではありません。もっと重要なのは、どの資格情報をどこで終端し、次の境界で誰の権限に張り替えるか です。

特に重要なのは次の 3 点です。

  1. フロント側 OAuth はバックエンド認証の代替ではない
  2. Azure ネイティブ backend では termination and reestablishment を標準形にする
  3. MCP / A2A を含むときは APIM と Foundry の責務を分離する

この視点で見ると、APIM は単なる「LLM の前段プロキシ」ではなく、AI 基盤における trust boundary の配置面 として理解できます。便利機能の多さではなく、責務の置き方で評価すべき理由はここにあります。

参考リンク

最重要

MCP / A2A / Agent identity

運用上の注意

ヘッドウォータース
ヘッドウォータース

株式会社ヘッドウォータースのテックブログです。 AIエージェント、生成AI、Azure、GitHub Copilot、IoT、XR系などData&AIとApp modernizeに関して幅広く投稿します！

Discussion