Microsoft Foundry / Agent Capability Hosts の rollout で現場がまず変わるのは、AI エージェントの接続設計が「エージェントを作ってから考える設定」ではなく、「プロジェクトを作る前に決める基盤設計」になることです。2026年4月20日の公式ブログは、オンプレミス API や閉域 API へ secure private AI connectivity を実現するうえで、Project / Agent Capability Hosts が見落とされやすい前提条件だと明示しました。Capability Host が無いと、たとえ同じ VNet 上の VM から API に到達できても、Foundry エージェントの実行基盤はその VNet に入らず、DNS・ルーティング・セキュリティ制御を継承できません。 (TECHCOMMUNITY.MICROSOFT.COM)
しかも2026年4月時点では、旧 Azure AI Foundry / Azure AI Studio は Microsoft Foundry に整理され、新ポータルはコアシナリオで GA に入っています。ただし、すべての機能が同じ完成度ではなく、ネットワーク分離や一部のツールには制限が残ります。つまり「Foundry が GA だから全部そのまま本番化できる」と考えると、設計の後戻りが起きやすい状態です。 (Microsoft Learn)
この記事では、Microsoft Foundry / Agent Capability Hosts の最新動向を前提に、Power users、admins、solution owners が実務でどこを見直すべきかを、オンプレ API 接続、private MCP、部門横断エージェント連携といった具体的な利用シナリオ中心に整理します。結論を先に言えば、閉域での AI エージェント運用を本気でやるなら、Capability Host は「オプション設定」ではなく、RBAC、接続、サブネット、DNS、復旧設計まで含めた最初の設計単位として扱うべきです。 (Microsoft Learn)
2026年4月時点で押さえるべき前提
Microsoft Foundry では、Foundry リソースが上位のガバナンス境界で、プロジェクトはその中のユースケース単位の作業コンテナです。Learn の現行ドキュメントでは、Capability Host は account と project の両スコープに存在し、特に project capability host は「そのプロジェクトの設定そのもの」として、どの Storage、Search、Cosmos DB、必要に応じて Azure OpenAI 接続を使うかを決める役割を持ちます。 (Microsoft Learn)
一方で、4月20日の公式ブログは field guidance として、project レベルに加えて agent レベルの Capability Host も説明しています。実務上は、まず account / project capability host を標準セットアップの前提として理解し、エージェントごとに異なる分離境界が必要な場合に agent capability host を使う、という読み方をすると混乱しません。 (Microsoft Learn)
もう1つ重要なのは、Capability Host を作らない場合の既定動作です。作成しなければ Agent Service は thread storage、file storage、vector search に Microsoft 管理リソースを使います。逆に、顧客管理の Azure Storage、Azure AI Search、Azure Cosmos DB に状態を置きたいなら、account と project の両スコープで Capability Host を前提にした standard agent setup に入る、という理解が必要です。 (Microsoft Learn)
Microsoft Foundry / Agent Capability Hosts の rollout でワークフローがどう変わるか
private AI の設計開始点が「プロンプト」から「プロジェクト設計」に移る
standard agent setup は、agent state を顧客管理・単一テナントの Azure リソースに置く方式です。ファイルは Azure Storage、ベクターストアは Azure AI Search、メッセージや会話履歴、agent metadata は Azure Cosmos DB に保存されます。つまり、閉域な Agent を作る時点で、プロンプト以前に「どのデータをどこに保持するか」を設計しなければいけません。 (Microsoft Learn)
さらに VNet injection は、BYO の Storage / Search / Cosmos DB を選び、かつ Foundry の public access を disabled にしたときにだけ有効になります。subnet は Microsoft.App/environments への委任が必要で、サイズも /27 以上が必要です。しかも Azure AI Search、Azure Storage、Azure Cosmos DB の private endpoint は Foundry 作成時に自動生成されません。ここを見落とすと、ネットワークは作ったつもりでも、Agent が実際には閉域経路を使えません。 (Microsoft Learn)
「VM で通るのに agent で通らない」が典型障害になる
4月20日の公式ブログが強調しているのは、Capability Host がなければ agent runtime は VNet に注入されない、という点です。VM が corporate DNS を使って API 名を解決できても、Agent 側は同じ DNS 設定を継承していないため、名前解決やルーティングが失敗します。ここで多くのチームが VPN や ExpressRoute を疑いますが、実際には実行場所の前提がずれているケースが多い、というのが今回の重要なメッセージです。 (TECHCOMMUNITY.MICROSOFT.COM)
開発者だけでは完結せず、RBAC と ID 設計が必須になる
Foundry の認証モデルも、ワークフローを変えます。現行の認証ドキュメントでは、Agents service は API key ではなく Microsoft Entra ID を使う前提で、least privilege、managed identity、きめ細かい RBAC は Entra ID 側で実現する設計です。API key は全権限型で粒度が粗く、Agent Service には適しません。 (Microsoft Learn)
最低限でも、ユーザー本人とプロジェクトの managed identity に Azure AI User を付与する考え方が必要です。さらに agent 公開には Azure AI Project Manager が最低ロールになり、standard setup では project managed identity に Cosmos DB Operator、Storage Account Contributor、Search Index Data Contributor、Search Service Contributor、Storage Blob Data Contributor、Storage Blob Data Owner など、複数のロール割り当てが必要になります。PoC の時点から、開発者・管理者・ネットワーク担当の分業を前提にした方が早いです。 (Microsoft Learn)
Capability Host は「後からちょっと変える設定」ではない
Capability Host は account ごと、project ごとに1つだけが有効で、設定のインプレース更新はできません。変更が必要なら削除して作り直す運用です。しかも現行ドキュメントでは、Capability Host の管理は REST API 前提で、SDK での管理はまだ提供されていません。つまり、運用フローは「Portal で微修正」ではなく、「IaC とスクリプトで再構成」が基本になります。 (Microsoft Learn)
プロジェクト分割だけではネットワーク分離にならない
ここは見落としやすいですが、private endpoint は project レベルではなく account レベルで定義されます。そのため、同じ Foundry account 配下の複数 project は、同じ private endpoint とネットワーク露出を共有します。さらに rollout ガイドでは、必要な API が project スコープに対応しない場合、Foundry resource 自体を分けることが推奨されています。部門ごと、データドメインごと、ネットワーク露出ごとに境界を切りたいなら、「project を増やす」より「Foundry resource を分ける」発想の方が安全です。 (Microsoft Learn)
standard agent setup を選ぶと、復旧責任も自分たちに戻ってくる
high availability / DR の観点でも変化は大きいです。Microsoft は control plane と capability host platform を運用しますが、standard agent deployment mode で使う Azure Cosmos DB、Azure AI Search、Azure Storage の耐久性は顧客側の責任になります。しかも DR ガイドでは、多くのワークロードで single Foundry project が recovery unit だとされ、Agent Service 自体に built-in な自動 failover や point-in-time restore はありません。閉域・高統制を取る代わりに、復旧設計まで自分たちで持つ必要があります。 (Microsoft Learn)
具体的な利用シナリオで見るワークフローの変化
社内承認 API を OpenAPI ツールで呼ぶケース
たとえば「稟議番号を受け取り、オンプレミスの承認 API から現在ステータスを返す」エージェントを考えます。従来の感覚だと、VM から API に疎通できれば、あとは OpenAPI 定義を登録すれば終わりです。しかし Foundry rollout 後の実務は、そう単純ではありません。Agent がどの subnet で実行されるか、どの DNS を使うか、どの project connection を参照するかまで先に決める必要があります。 (TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の順序が安全です。
- Foundry を standard agent setup + BYO VNet で作り、public access を disabled にします。agent 用 subnet は
Microsoft.App/environmentsに委任し、/27 以上を確保します。Azure AI Search、Azure Storage、Azure Cosmos DB の private endpoint は別途作成します。 (Microsoft Learn) - project に Storage、AI Search、Cosmos DB、必要なら Azure OpenAI の connection を作り、account capability host と project capability host を設定します。project capability host が、その project の state store と model 接続の基準になります。 (Microsoft Learn)
- まずは同じ subnet 上の VM から DNS と通信を確認し、その後に agent 実行で検証します。agent 側が 401 を返す段階まで来たら、ネットワーク経路は通っている可能性が高く、次は token、header、audience、認可フローを疑うべきです。 (TECHCOMMUNITY.MICROSOFT.COM)
- 開発者の操作経路も忘れずに決めます。private endpoint 前提の Foundry では、project レベル機能に触るために jump box、peered VNet、ExpressRoute、site-to-site VPN などが必要になります。 (Microsoft Learn)
このシナリオで実際に増えるのは、agent authoring の手数ではなく、事前の変更申請です。ネットワーク、ID、アプリ担当が同じチケットで動けるようにしておかないと、PoC でも詰まります。
private MCP で社内共通ツールを横展開するケース
Power users や platform team にとって、次に効いてくるのが private MCP です。MCP は「複数の agent が共通で使う社内ツール」を配るのに向いており、tool catalog の説明でも、MCP は他チームが管理する共有ツールに適した方式とされています。 (Microsoft Learn)
ただし private MCP には前提があります。現行ドキュメントでは、private MCP は standard agent setup + private networking が必要で、VNet 内に dedicated MCP subnet を用意し、Azure Container Apps の internal-only ingress でホストする構成が tested path です。認証情報はハードコードせず、project connection に持たせます。Function Apps や App Service でも動く可能性はありますが、private MCP のホストとしては内部検証済みではありません。 (Microsoft Learn)
さらに、toolbox は複数ツールを1つの MCP endpoint として束ねて再利用できる preview 機能です。ここを使うと、platform team が「ERP 参照」「在庫確認」「価格照会」を1つの toolbox として提供し、各業務 team は toolbox endpoint を繋ぐだけ、という役割分担に変えられます。Capability Host rollout の価値は、単に private に繋がることではなく、社内ツール提供の責務を agent ごとの個別実装から共通基盤へ寄せられることにあります。 (Microsoft Learn)
購買・法務・経理を分業させるマルチエージェント承認フロー
もう1つ分かりやすいのが、部門ごとの専門 agent をつないで承認フローを回すケースです。A2A は現時点で preview ですが、network-isolated 環境でも VNet 経由で使えるカスタムツールとして整理されています。たとえば購買 agent が見積比較を行い、法務 agent が契約条項を確認し、最後に経理 agent が支払条件を評価する、という分業は現実的です。 (Microsoft Learn)
ただし、この種のフローは project の切り方が重要です。DR ガイドでは多くのワークロードで single Foundry project が recovery unit とされ、architecture ガイドでは private endpoint は account レベルで共有されると説明されています。つまり、購買と法務で障害影響範囲を分けたい、あるいはネットワーク露出を分けたいなら、project を2つ作るだけでは足りません。Foundry resource 自体を分け、A2A や API でつなぐ設計の方が運用に耐えます。 (Microsoft Learn)
Teams 配布や Web 検索も使いたいケース
ここは rollout で誤解されやすいポイントです。network isolation ガイドでは、Publish Agent to Teams/M365 は未対応、Traces は private Application Insights では未対応、Workflow Agents は outbound の virtual network injection が未対応と整理されています。GA になったからといって、閉域構成でそのまま全部使えるわけではありません。 (Microsoft Learn)
ツールの通信経路も一様ではありません。
- MCP、OpenAPI、Azure Functions、A2A は VNet 側の経路を使う前提です。 (Microsoft Learn)
- Azure AI Search や Fabric Data Agent は private endpoint 前提で設計できます。 (Microsoft Learn)
- Code Interpreter と Function Calling は Microsoft backbone network を通る扱いです。 (Microsoft Learn)
- Bing、Websearch、SharePoint Grounding は network-isolated 環境でも動きますが、通信は public endpoint を使います。厳密に「全通信を private network に閉じたい」組織では、その時点で要件不適合になりえます。 (Microsoft Learn)
さらに architecture ガイドでは、Web Search のような built-in tool は agent egress subnet を経由しない内部メカニズムを取る場合があると明記されています。つまり、Azure Firewall の allow list を作っただけで「すべての built-in tool の外向き通信を観測・制御できる」とは限りません。閉域要件が強いなら、public tool を禁止する policy と、実トラフィックの検証をセットで持つべきです。 (Microsoft Learn)
導入前に決めるべき順番
最初の rollout で失敗しにくい順番は、次の6つです。
- まず Foundry resource の境界を決めます。部門、データドメイン、親リソース権限、ネットワーク露出が違うなら resource を分けます。 (Microsoft Learn)
- 次に project の境界を決めます。project はユースケース単位、かつ多くのワークロードでは recovery unit です。 (Microsoft Learn)
- その後で Basic か Standard かを決めます。データ主権、private MCP、閉域接続、復旧手順まで欲しいなら Standard、速度優先の試作なら Basic が向きます。 (Microsoft Learn)
- ネットワーク方針を決めます。public、private endpoint、hybrid のどれかだけでなく、ツールごとの通信経路まで決めます。 (Microsoft Learn)
- RBAC と managed identity を先に揃えます。agent を作ってから権限不足を直すより、project managed identity のロールを最初に入れた方が早いです。 (Microsoft Learn)
- 最後に Capability Host の作成・変更・復旧を IaC とスクリプトに落とします。更新は再作成前提なので、手動運用だと本番で苦しくなります。 (Microsoft Learn)
失敗しやすいポイント
- 「VM から通るから agent も通る」と判断すること。Capability Host が無いと、agent runtime は VNet に入っていない可能性があります。 (TECHCOMMUNITY.MICROSOFT.COM)
- Basic agent setup のまま、あとから virtual network injection だけ足そうとすること。VNet injection は BYO の Storage / Search / Cosmos DB と public access disabled が前提です。 (Microsoft Learn)
- Search、Storage、Cosmos DB の private endpoint が自動で生えると思い込むこと。ここは別作業です。 (Microsoft Learn)
- project を分ければネットワークも分かれると思うこと。private endpoint は account レベルなので、必要なら resource を分けます。 (Microsoft Learn)
- API key やハードコードした secret で agent や MCP 認証を済ませようとすること。Agents service は Entra ID 前提で、MCP 認証情報も project connection に寄せるのが基本です。 (Microsoft Learn)
- Standard を選んだのに、バックアップや復旧は Microsoft が面倒を見ると思うこと。耐久性は自分たちの設計責任です。 (Microsoft Learn)
- Cosmos DB の容量設計を軽く見ること。標準セットアップのドキュメントでも、RU/s 不足は capability host provisioning failure の原因として明記されています。 (Microsoft Learn)
まとめ
Microsoft Foundry / Agent Capability Hosts の rollout が現場にもたらす本質的な変化は、AI エージェント開発が「モデルとプロンプト中心」から「プロジェクト、ID、ネットワーク、復旧まで含めた基盤中心」へ移ることです。Capability Host は、その変化を象徴する control point です。ここを後回しにすると、DNS も VPN も API 定義も合っているのに agent だけ失敗する、という一番厄介な状態に入ります。 (TECHCOMMUNITY.MICROSOFT.COM)
次にやるべきことはシンプルです。まず1つのユースケースを選び、Foundry resource 境界、project 境界、connections、subnet、DNS、RBAC、許可するツール通信の経路を1枚の設計メモにまとめてください。その設計が固まってから agent を作る順番に変えるだけで、Microsoft Foundry の rollout は「つながらない PoC」ではなく「本番を見据えたワークフロー改善」になります。 (Microsoft Learn)
コメント