Microsoft Foundry、cross-リージョン モデル connectivity の設計パターン

Microsoft は 2026年6月19日、Microsoft Foundry Blog で cross-リージョン モデル connectivity の設計パターンを解説しました。Foundry ではモデルや Foundry エージェント サービス の提供リージョンがプロジェクトで承認されたリージョンと一致しない場合があり、別リージョンの Foundry リソース や モデル deployment にどう接続するかが設計課題になります。

要点

• 別リージョンの Foundry リソース へ直接接続する方法は、最も構成要素が少ない選択肢です。
• Azure API Management を モデル connection の前段に置くと、routing、ポリシー、オブザーバビリティ、network isolation を顧客側で制御しやすくなります。
• エージェント surface の前段に APIM を置くパターンでは、ingress の ガバナンス と telemetry は得られますが、Foundry が caller トークン を直接検証する必要がある点は残ります。
• VNet-secured APIM variant では、APIM ingress と backend Foundry account の private エンドポイント を組み合わせ、caller から APIM、backend まで Azure backbone 上に寄せる構成が説明されています。

今回のブログ記事で語られていること

この記事の出発点は、Microsoft Foundry のモデル提供がリージョン依存であることです。プロジェクトで承認されたリージョンに、必要なモデルや Foundry エージェント サービス のサポートが無い場合、別リージョンにある Foundry リソース や モデル deployment へ接続する必要が出ます。Microsoft はその選択肢として、別 Foundry リソース への direct connection、Azure API Management を使った モデル connection、エージェント surface の前段に APIM を置く構成を比較しています。

Direct connection は、別リージョンの Foundry リソース にあるモデルへ最小構成で到達する方法です。記事では、追加 ゲートウェイ tier が不要で、最も overhead が小さい一方、platform-owned ポリシー、routing、throttling、オブザーバビリティ を全 モデル call に適用する余地は小さいと整理されています。単一チームや検証環境では扱いやすい反面、複数チームが共有する企業基盤では、中央制御の不足が問題になる可能性があります。

Azure API Management モデル connection は、backend Foundry リソース の前に顧客管理の ゲートウェイ surface を置く設計です。APIM は authentication の正規化、ポリシー 適用、backend routing、telemetry、throttling などを担えます。記事では、VNet-secured variant として、プロジェクト VNet の private エンドポイント、privatelink.azure-api.net の private DNS、backend Foundry account の private エンドポイント を組み合わせ、public hostname を経由しない request path を説明しています。モデル呼び出しを platform team が管理したい場合に向いた選択肢です。

エージェント surface の前段に APIM を置くパターンは、エージェント エンドポイント への inbound traffic に対する ガバナンス や オブザーバビリティ を強めるものです。ただし、Foundry が caller トークン を直接見る必要があるため、APIM が エージェント surface の identity を完全に置き換えるわけではありません。記事では、MCP On-Behalf-Of、顧客-data ツール authorization、per-ユーザー audit trails のために、Foundry が caller を認識する必要があると説明されています。したがって、この構成は auth layer ではなく、ガバナンス / オブザーバビリティ layer として読むのが自然です。

今回のブログ記事が関係する人

Microsoft Foundry を複数リージョンで使うプラットフォームチーム、ネットワーク担当、エージェント基盤担当に関係します。モデルの提供リージョンとプロジェクトの承認リージョンがずれる環境では、直接接続と APIM 経由の責任分界を理解しておきたい内容です。

実務で確認したいポイント

どのパターンを選ぶかは、モデル呼び出しの所有者が誰かで変わります。個別チームが少数のモデルへ接続するなら direct connection が簡単です。一方、platform team が複数 backend、複数プロジェクト、複数リージョンを管理し、routing、throttling、logging、Content 安全性 や プロンプト Shields のような ポリシー を中央で適用したいなら、APIM を検討する理由があります。

また、記事では chat completions surface と Responses API の routing 差分にも触れています。deployment name が URL に入る chat completions では APIM の parameterized route が使いやすい一方、Responses API は モデル name が JSON payload に入るため、body inspection か Foundry の dynamic モデル connection を検討する必要があります。API surface ごとに同じ設計が通用するとは限りません。

結局、今回のブログ記事をどう読むべきか

この Foundry 記事は、別リージョンのモデルを使うための単純な接続手順ではなく、enterprise deployment pattern の比較として読むのが自然です。モデルの可用性、リージョン制約、network isolation、identity、オブザーバビリティ、Content 安全性、エージェント ツール authorization をまとめて設計する必要があります。Foundry を複数リージョンで運用するチームは、direct connection で始めるか、APIM を ゲートウェイ として置くかを、運用責任と統制要件から決めることになります。