Microsoftは2026年7月17日、Tech Communityブログで「From AI Adoption to AI Governance」と題する記事を公開し、Azure API Management（APIM）をMicrosoft Foundry（旧Azure AI Foundry）の前段に配置してAIモデル利用を一元的に統制する構成を解説した。社内でAI活用が広がるほど「誰が」「どのモデルを」「どれだけ」使っているかが見えなくなる、という課題に対する具体的な処方箋である。

APIMを「AIゲートウェイ」として使う発想

これまで多くの現場では、開発者やチームがMicrosoft Foundryのモデルエンドポイントに直接APIキーで接続していた。この状態が広がると、利用状況の可視化ができない、チームごとのコスト配分ができない、キーが漏洩しても検知できない、といった統制不能な状況に陥る。

APIMをFoundryの手前にリバースプロキシとして挟むことで、次のようなポリシーを一箇所に集約できる。

  • トークン単位でのレート制限・クォータ管理（従来のリクエスト数制限では不十分なLLM特有の課金構造に対応）
  • 複数モデルデプロイやリージョン間でのロードバランシング
  • セマンティックキャッシュによる重複リクエストのコスト削減
  • Application Insightsへの一元的なログ集約とトークン消費の可視化
  • Microsoft Entra IDのマネージドID・アプリ登録を軸にした認証統合（APIキーの個別配布からの脱却）

記事ではあわせて、こうしたGenAIゲートウェイポリシーの利用にはAPIMのv2ティア（Standard v2 / Premium v2）が前提になる点、およびApp Service上でエージェントをホストする構成に関する仕様変更にも触れており、既存構成からの移行を検討する際の注意点として押さえておきたい。

実務への影響

日本のエンタープライズでも、部門ごとにFoundryやAzure OpenAIのエンドポイントを個別契約し、気づけばAPIキーが乱立している、というケースは珍しくない。この状態では月次のAI利用コストが読めず、セキュリティ部門もどの部署が何を呼んでいるか把握できない。

明日から着手できる対策は、まずAPIMをAI利用の唯一の入口として位置づけ、アプリケーション側からFoundryへの直接呼び出しを禁止することだ。APIMとFoundry間の認証はAPIキーではなくマネージドIDに統一し、サブスクリプションキーとEntra IDのアプリ登録を紐付ければ、チーム単位のコスト按分や監査ログの追跡が一気に楽になる。IT管理者はこの構成を「AI版の踏み台サーバー」として説明すると社内の理解を得やすいだろう。

筆者の見解

AzureとMicrosoft Entra IDの基盤としての信頼性は揺るがない、というのが筆者の一貫した立場だ。今回の構成はまさにその強みを体現している。APIMとEntra IDでAIモデルへのアクセスを統制するというのは、結局のところ「人間ではなくサービスプリンシパルやマネージドIDといった非人間アイデンティティ(NHI)をどう管理するか」という話であり、これはゼロトラストの延長線上にある本質的な課題だ。常時発行されたAPIキーがそこら中に転がっている状態こそが最大のリスクであり、APIMを唯一の入口にする発想は正しい方向だと思う。

Microsoft Foundry経由であれば、Azureという基盤を手放すことなく、そのときどきで最良のAIモデルを選んで動かせる。最先端モデルの開発競争でMicrosoftが常に先頭を走っているとは言えないが、多数のエージェントを安全に運用できるプラットフォームを提供する競争では十分に勝負できる力を持っている。今回のようなガバナンス機能の地道な積み上げこそが、その強みを実際の現場価値に変えていく道だろう。正面から勝負できるはずのプラットフォームなので、この路線を継続してほしい。

出典: この記事は From AI Adoption to AI Governance - Using APIM as the Gateway for Azure AI Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。