Microsoft Foundry Agent Service の private networking rollout が現場を変える最大の点は、AI エージェントを「社内 API に触れられる本番ワークロード」に引き上げることです。2026年4月20日に公開された Microsoft の公式トラブルシューティングは、オンプレ API へ VPN / ExpressRoute 経由で到達させる際に、VM では成功するのに agent では失敗する典型パターンを整理し、その原因が VPN や DNS そのものではなく、agent runtime を自社 VNet に正しく載せる前提の欠落にあると明確にしました。(TECHCOMMUNITY.MICROSOFT.COM)
結論から言うと、Microsoft Foundry Agent Service で private networking を使うなら、private endpoint を作るだけでは足りません。Standard Setup with private networking、BYO VNet、delegated subnet、Capability Host、依存リソースの private endpoint、DNS、RBAC まで含めて初めて、agent からオンプレや非公開 API に閉域で届きます。ここが分かると、この更新は単なるネットワーク機能追加ではなく、ヘルプデスク、RAG、承認フロー、グローバル展開の進め方そのものを変える更新だと分かります。(Microsoft Learn)
Microsoft Foundry Agent Serviceのprivate networkingで押さえるべき結論
今回の更新で実務的に大きいのは、Microsoft が「VMで通るのに agent で通らない」問題を、Capability Host と VNet injection の観点で公式に説明したことです。公式ブログは、private endpoint はあくまで inbound の仕組みであり、agent の outbound が自社 VNet を通るのは必要条件が満たされたときだけだと整理しています。さらに Capability Host は account / project スコープのサブリソースとして扱われ、構成変更は更新ではなく再作成が前提です。つまり private networking は、あとから GUI で少し足す機能ではなく、最初から IaC と変更管理に乗せるべき構成要素になった、ということです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Foundry Agent Serviceのprivate networkingで最初に決めること
最初に決めるべきは、「何を private にしたいのか」です。Foundry への接続を閉じたいのか、agent から社内 API へ閉域接続したいのか、あるいはユーザー権限を downstream に引き継ぎたいのかで、必要な構成が変わります。(Microsoft Learn)
| 目的 | 選ぶべき設計 | 見落としやすい点 |
|---|---|---|
| Foundry 自体への接続を閉じたい | private endpoint と public network access 制限 | これは主に inbound 制御で、agent の outbound が自社 VNet を通ることとは別 |
| agent から on-prem / private API に閉域接続したい | Standard Setup with private networking + BYO VNet + delegated subnet + Capability Host + BYO Storage / Cosmos / Search | Search / Storage / Cosmos の private endpoint は自動作成されない |
| 利用者権限をそのまま downstream に渡したい | MCP + OAuth OBO を含めた identity 設計 | same-tenant 前提で、Azure AI User role も必要 |
公式ドキュメントを実装目線に直すと、判断はこの3つに集約できます。Foundry 全体の network isolation ドキュメントは inbound private endpoint と outbound VNet injection の両方を扱っていますが、Agent Service の private networking how-to は BYO リソースと閉域実行を強く前提にしています。ここを曖昧にしたまま進めると、ネットワークチームとアプリチームで「private の意味」が食い違います。(Microsoft Learn)
2026年4月時点では、ドキュメント上も experience ごとの差が残っています。Agent Service の private networking how-to は Bicep / Terraform を主軸に案内し、Capability Host 管理も REST API 前提です。一方、Foundry 全体の network isolation how-to には Azure portal からの VNet injection 手順もあります。さらに GA overview では、Hosted Agents、Traces、Workflow Agents は virtual network 前提の本番設計で再確認すべきと明記されています。実装前に「どの portal / どの agent type / どの API surface を使うのか」を揃えておかないと、設計レビューと手順書がすぐズレます。(Microsoft Learn)
特に「まず private networking で作り、あとで Teams や Microsoft 365 に publish する」という計画は要注意です。network isolation の制約一覧では、Publish Agent to Teams / M365 は未対応とされています。社内限定の閉域 agent と、チャネル配布する agent は、同じ rollout 計画に無理に押し込まないほうが安全です。(Microsoft Learn)
Microsoft Foundry Agent Service / private networking が変える具体的な業務フロー
private networking の価値は、portal 内で chat できることではなく、agent が企業ネットワークの中で業務を実行できることにあります。効くのは、public に出せない API を agent に使わせたい場面です。(Microsoft Learn)
ヘルプデスク・ITSM の自動化
たとえばヘルプデスクでは、「利用者Aの端末保証期限を調べ、未更新ならチケットに追記し、必要なら交換申請を起票する」といった流れを 1 回の会話にまとめやすくなります。Microsoft の tool support では、network-isolated 環境でも OpenAPI tool、Azure Functions、Private MCP、A2A は自社 VNet 経由で使えます。つまり社内 CMDB や ITSM API を public 化せずに、agent から安全に呼び出す設計が取りやすくなります。(Microsoft Learn)
このシナリオで変わるのは、開発フローよりも運用フローです。ネットワーク担当は delegated subnet、VPN / ExpressRoute、DNS フォワーディングを用意し、アプリ担当は on-prem API を OpenAPI か MCP で安定した interface に整え、Foundry 側では project capability host と接続先の RBAC をそろえる必要があります。VM から疎通できた時点で終わりではなく、「agent runtime も同じ VNet 経路に載っているか」までが検証対象になります。(TECHCOMMUNITY.MICROSOFT.COM)
現場で最も起きやすい誤診は、DNS や VPN だけを疑い続けることです。今回の公式ブログが示した通り、VM は VNet の中にいても、Capability Host の関連付けが抜けた agent は同じ前提で動きません。「VM成功 = agent成功」ではない、という切り分けに変わったのが今回の更新の実務的な意味です。(TECHCOMMUNITY.MICROSOFT.COM)
private RAG と社内ナレッジ検索
社内ナレッジ検索や規程検索でも、Microsoft Foundry Agent Service の private networking は効きます。Standard Setup では files は Azure Storage、threads は Cosmos DB、vector store は Azure AI Search に入り、これらを自社サブスクリプション内の single-tenant リソースとして保持できます。network-isolated 環境では Azure AI Search tool が private endpoint 経由でサポートされるため、会話履歴・添付ファイル・検索基盤を tenant 内に寄せたい組織に向いています。(Microsoft Learn)
一方で、ここはツール選定を間違えやすい領域でもあります。network-isolated 環境では Azure AI Search tool は使えますが、File Search は未対応です。つまり「閉域 RAG をやりたいから、とりあえず File Search」ではなく、「private endpoint 前提の Azure AI Search tool で設計する」ほうが筋がいいケースが多いです。加えて依存リソース側の private endpoint は自動作成されず、private AI Search を agent tool として使うシナリオでは portal experience の違いも意識する必要があります。(Microsoft Learn)
rollout を組織単位で考えるなら、project を use case 単位の隔離境界として扱う発想も重要です。Foundry の rollout ガイドは、開発・検証・本番の分離、business group ごとの Foundry resource、use case ごとの project を勧めています。private networking は単なる通信設定ではなく、ナレッジの保存場所とアクセス境界を整理する設計テーマになります。(Microsoft Learn)
利用者権限を維持したままの承認・照会フロー
承認フローや照会フローでは、network より identity が主役になる場面も増えます。たとえば購買・人事・財務の agent で、「自分が見られる申請だけを表示し、承認権限があるものだけ承認する」を実現したいなら、shared secret より OAuth identity passthrough を前提に設計するほうが自然です。Foundry の MCP 認証は、key-based、agent identity、project managed identity、OAuth OBO を分けて選べるため、「agent 共有権限で十分か」「利用者権限を downstream に渡すべきか」を設計段階で切り分けられます。(Microsoft Learn)
このパターンでは、初回利用時に consent が必要になり、同じ tool でも user ごとに authorization が発生します。加えて OBO は Foundry project と同じ Entra tenant が前提で、cross-tenant token exchange はサポートされません。グローバル企業で複数 tenant をまたぐなら、private networking だけでなく identity topology も同時に見直す必要があります。(Microsoft Learn)
運用上の失敗ポイントは、network 障害と認証障害を混ぜてしまうことです。MCP や Azure Functions 側で 401 / 403 が出るときは、Audience、issuer、role assignment、OAuth の authorization / token / refresh URL、scope のどれがズレているかを先に確認したほうが早いです。逆に URL 自体に届いていないなら、private subnet、private DNS、Capability Host を見る順番が正解です。(Microsoft Learn)
グローバル展開と landing zone 設計
グローバル企業や複数事業部への rollout では、Microsoft Foundry Agent Service の private networking は「1個の central agent をみんなで使う」発想を弱めます。公式ガイドは、開発・テスト・本番の分離、business group ごとの Foundry resource、project ごとの use case 分離を勧めており、VNet・Storage・Cosmos・Search・Foundry resource は同一 region に揃える前提もあります。region availability は変わり得るため、global rollout ほど「共通基盤を1つに寄せる」より「リージョン別 landing zone を複製する」設計のほうが現実的です。(Microsoft Learn)
このとき platform team の役割は大きくなります。Capability Host は更新不可で REST API 管理が前提、1 scope 1 host の制約もあるため、後から手作業で増改築するより、Bicep / Terraform と policy で landing zone ごとテンプレート化したほうが安定します。さらに Azure Policy では、未承認の connection category を deny したり、有効な Agent capability host を持たない Foundry resource を audit したりできます。(Microsoft Learn)
ツール別に見る、どの通信がどこを通るか
2026年4月時点の公式 guidance を実務向けに整理すると、private networking で迷いやすいのは「何が VNet を通り、何が通らないか」です。(Microsoft Learn)
| パターン | network-isolated 環境での扱い | 主な通信経路 | 向く用途 | 注意点 |
|---|---|---|---|---|
| OpenAPI / Azure Functions / A2A / Private MCP | サポート | 自社 VNet subnet | on-prem API、社内業務 API、内部オーケストレーション | Capability Host、DNS、認証設計が前提 |
| Azure AI Search tool | サポート | private endpoint | 閉域 RAG、社内検索 | Search 側の private endpoint と RBAC が必要 |
| Code Interpreter / Function Calling | サポート | Microsoft backbone | 自社 VNet を使わない計算・関数系処理 | on-prem API 到達の経路にはならない |
| Bing / Websearch / SharePoint Grounding | サポート | public endpoint | 外部情報の補完 | 「全通信を閉域にしたい」要件とは相性が悪い |
| File Search / Logic Apps / Browser Automation / Computer Use / Image Generation | 未対応または開発中 | – | strict private rollout では避ける | 代替パターンを最初から決める |
特に見落とされやすいのが、「supported」と「すべての通信が private」は同じ意味ではない点です。Bing / Websearch / SharePoint Grounding は network-isolated 環境でも使えますが public endpoint 通信です。逆に private MCP や OpenAPI は VNet を通せるので、社内 API 連携の本命になりやすいです。(Microsoft Learn)
トラブルシューティングは「ネットワーク → ID → ツール設定」の順で見る
private networking の障害は、症状だけ見ると似ています。ですが、調べる順番を固定するとかなり早く絞れます。(TECHCOMMUNITY.MICROSOFT.COM)
| 症状 | まず見る場所 | 典型原因 |
|---|---|---|
| VM では成功、agent では timeout / DNS error | Capability Host、subnet 関連付け | agent runtime が VNet injection されていない |
| Azure AI Search で 403 / SearchIndexNotFound | Search RBAC、private endpoint 承認 | Search 権限または接続が不完全 |
| MCP / Functions で 401 / 403 | Audience、issuer、role assignment、OAuth URL / scope | 認証設定のずれ |
nslookup が public IP を返す | private DNS zone、VNet link、DNS forwarder | private endpoint 向け名前解決ができていない |
順番を逆にして、最初から prompt や tool logic を直しに行くと時間を浪費しがちです。今回の公式ブログでも、Capability Host と subnet の確認ができていない段階で DNS や認証を深掘りするのは早すぎる、というメッセージがかなり明確に出ています。(TECHCOMMUNITY.MICROSOFT.COM)
rollout を失敗しにくくする進め方
本番 rollout を急ぐほど、最初の 1 本は狭く始めたほうがうまくいきます。おすすめは、まず read-only の on-prem 参照か private RAG のどちらか 1 つに絞ることです。そのうえで、Standard Setup with private networking、Capability Host、private endpoint、DNS、RBAC を IaC 化し、接続確認は jump VM と agent の両方で実施します。write-back や OBO は、その土台が安定してから広げるほうが失敗しません。(Microsoft Learn)
もう一歩踏み込むなら、production で許可する tool と authentication を先に決めておくべきです。public endpoint を使う tool を production から外す、preview 依存の機能を別環境に分ける、connection category や capability host の有無を policy で監査する、という形にすると、Power users に自走してもらいながらも統制を失いにくくなります。(Microsoft Learn)
Microsoft Foundry Agent Service の private networking rollout は、AI agent を「公開してよい bot」から「企業ネットワークの中で業務を実行する workload」へ変えます。だから評価軸も、prompt の良し悪しだけでなく、VNet、DNS、identity、RBAC、tool support、region plan まで含む platform 設計に変わります。次にやるべきことは、public endpoint を使わない read-only シナリオを 1 本選び、Standard Setup with private networking と Capability Host を IaC 化することです。そこまでできれば、今回の更新は単なるニュースではなく、現場の自動化を一段進める実装基盤になります。(Microsoft Learn)
コメント