Microsoft Foundry でオンプレミス API や社内限定サービスへ安全に接続したい管理者が最初に押さえるべき答えは、Private Endpoint だけでは agent の実行経路は私設ネットワークに入りきらないという点です。2026年4月20日に公開された Microsoft Foundry Blog は、Project / Agent Capability Hosts を見落とすと、VPN・ExpressRoute・社内 DNS・Private Link を整えても secure private AI connectivity は完成しないと整理しました。さらに Learn の公式ドキュメントでは、Capability Host はアカウント/プロジェクトのサブリソースとして扱われ、1スコープ1つ、更新不可、現在は REST API ベースで管理する前提が示されています。つまり、発表直後に管理者が確認すべきなのは「設定の有無」だけではなく、展開順序と変更管理の組み方です。 (TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Microsoft Foundry / Agent Capability Hosts をこれから導入する管理者向けに、導入前、設定、周知、展開順序、運用ガードレールまでをそのまま使えるチェックリスト形式で整理します。
2026年4月20日の更新で押さえるべき本質
今回の更新で重要なのは、「Private Endpoint は入口の保護であり、agent の outbound 実行場所を決めるものではない」と Microsoft が明確に言語化したことです。Foundry の network isolation ドキュメントでも、inbound access、Foundry resource からの outbound access、そして Foundry Agent client から依存先へ出る outbound access を分けて説明しています。後者を社内ネットワーク境界の中へ入れるには、VNet injection と Capability Host が実質的な前提になります。 (TECHCOMMUNITY.MICROSOFT.COM)
以下の2つを混同すると、設計もトラブルシュートも外しやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
| 誤解 | 実際 |
|---|---|
| Foundry に Private Endpoint を作れば、agent の通信も自動で VNet に入る | Private Endpoint は主に inbound の保護。agent の outbound を VNet 経由にするには、Capability Host と subnet 側の準備が必要 |
| VM で DNS 解決できるなら、agent も同じ結果になる | Capability Host がないと agent runtime はその VNet/DNS 経路を継承しないことがある |
この前提を外すと、「VM では成功、agent だけ失敗」という典型パターンにそのまま入ります。Microsoft の 4 月 20 日の blog でも、この症状は DNS 設計そのものより agent がどこで実行されているか を誤認しているケースで起きやすいと説明されています。 (TECHCOMMUNITY.MICROSOFT.COM)
まずは影響範囲を判定する
自社がどの構成を選ぶべきか
以下は、管理者が最初に切り分けるべき導入パターンです。Environment setup、Capability hosts、network isolation、managed virtual network の公式ドキュメントをもとに整理しています。 (Microsoft Learn)
| いまの要件 | Capability Hosts の優先度 | 推奨構成 | 見落としやすい点 |
|---|---|---|---|
| Foundry への private inbound だけ必要 | 低 | Private Endpoint と DNS 構成 | inbound と agent outbound を混同しない |
| データ所有権、CMK、自社ストレージ運用が必要 | 高 | Standard Setup | account / project capability host と project connection が必要 |
| agent からオンプレ API や private PaaS を呼びたい | 最重要 | Standard Setup + Private Networking | delegated subnet、private DNS、same region、subnet binding が必要 |
| preview を許容して Microsoft 管理ネットワークも検討したい | 高 | Managed VNet（preview） | カスタム VNet からのアップグレード不可、再デプロイ前提、機能差分の確認が必要 |
Private Network Isolation は Standard Setup で使う前提で整理されており、managed virtual network は 2026年4月時点で preview、無効化不可、custom VNet からの移行パスなしという制約があります。preview を本番標準にするかどうかは、ネットワーク要件だけでなく変更管理と再デプロイ許容度で判断したほうが安全です。 (Microsoft Learn)
用語のズレで迷わないための整理
ここは実務上かなり大事です。2026年4月20日の blog は Project Capability Host と Agent Capability Host という表現で、「どの subnet に agent runtime を入れるか」という実行面の考え方を強調しています。一方、現行 Learn ドキュメントで管理対象として明示されているのは account-level と project-level の Capability Host です。階層は service defaults → account-level → project-level で、より具体的な設定が上位を上書きします。 (TECHCOMMUNITY.MICROSOFT.COM)
管理者向けの運用手順は、account capability host をサービス有効化と既定値の管理対象、project capability host を実際の接続先・保存先・subnet ひも付けの管理対象として組むのが安全です。加えて、現在の docs では Capability Host は 1 スコープ 1 つ、更新不可、REST API 管理です。つまり、本番での変更は「あとで画面で直す」想定ではなく、再作成を前提にした change window として扱うべきです。 (Microsoft Learn)
Microsoft Foundry / Agent Capability Hosts の導入前チェックリスト
設計前に以下が埋まっていなければ、実装に進まないほうが手戻りを減らせます。Rollout guidance、RBAC、networking、baseline architecture をもとにした管理者向けチェックです。 (Microsoft Learn)
| 確認項目 | 何を決めるか | 完了の目安 |
|---|---|---|
| 環境分離 | dev / test / prod の subscription・resource group・Entra グループ分離 | 環境ごとの所有者と承認者が定義済み |
| リージョン | Foundry、VNet、Storage、Cosmos、Search、モデル配置の整合 | 「同一リージョン前提」で設計書に固定済み |
| Resource Provider | 必要 namespace の登録 | 事前登録済みでテンプレート実行時に止まらない |
| RBAC 体制 | Azure AI Account Owner、Role Based Access Control Administrator / Owner、Azure AI User の担当 | 誰がどのスコープで付与するか明文化済み |
| プロジェクト分割ルール | どの access pattern ごとに project を分けるか | 「同じ project に載せてよい agent」の基準がある |
| 認証方針 | Entra ID を標準にするか、API key を例外にするか | 本番は Entra ID、例外時の承認ルールあり |
| Connection 方針 | project-level を基本にするか、account-level を使う例外を定めるか | 共有接続の使用条件が明文化済み |
| Hosted / Preview 判定 | hosted agents、managed VNet preview を使うか | recreate-sensitive な変更として別扱いになっている |
特に重要なのは、同じ project 内の agent は同じ managed identity を共有する点です。異なる権限境界が必要な agent を 1 project に混在させると、最小権限設計が崩れやすくなります。Microsoft の baseline architecture でも、異なる access pattern を持つ agent は project を分けること、connection は project-level を優先し、account-level connection は広すぎる権限になりやすいと警告しています。 (Microsoft Learn)
また、本番の認証方式は Entra ID が基本です。Microsoft は production workload で Entra ID を推奨し、API keys は rapid prototyping 向けと整理しています。Capability Host、networking、connection、agent 実行の担当が分かれるほど、後で監査しやすい Entra ID 前提のほうが運用しやすくなります。 (Microsoft Learn)
設定チェックリスト
先に作るもの、後で作るもの
Capability Host を「最後に足すオプション」と考えると順番を外しやすいので、以下の順で固定しておくと安全です。Standard setup と private networking の公式手順、および Capability Host の概念ページをもとにしています。 (Microsoft Learn)
| 順序 | やること | 完了の目安 | 飛ばすと起きやすいこと |
|---|---|---|---|
| 1 | Azure Storage、Azure Cosmos DB for NoSQL、Azure AI Search を用意する。必要に応じて Key Vault / App Insights も決める | 依存リソースの所有者と配置先が確定 | 後続の host 作成や監査設計が止まる |
| 2 | Foundry account、project、モデル配置を作る | account / project / model が揃う | agent 作成以前の前提が不足する |
| 3 | project connections を作る。Storage、Cosmos、Search、必要なら Azure OpenAI を project へ接続する | connection 名が project 上で確認できる | resource ID だけあっても host から参照できない |
| 4 | project managed identity に必要 RBAC を付与する | IAM 画面で scope と role を確認済み | 403、index 作成失敗、ファイル保存失敗 |
| 5 | account capability host を作る | status が Succeeded | 標準化した既定値や service enablement が曖昧になる |
| 6 | project capability host を作る。Storage / Cosmos / Search の connection 名、必要なら aiServicesConnections、private 構成なら customer subnet 情報を入れる | status が Succeeded | VNet injection が起きない、保存先が意図どおりにならない |
| 7 | private networking を作る。delegated agent subnet、private endpoints、private DNS、PNA 無効化、必要な firewall 設定を揃える | private IP 解決が確認できる | VM は成功、agent だけ失敗する |
| 8 | VNet 内または VPN / ExpressRoute 先から疎通確認し、agent を再デプロイまたは再検証する | target API まで agent で到達確認 | 401 / 403 / timeout の切り分けが曖昧なまま残る |
ここでの落とし穴は 3 つあります。
1つ目は、Capability Host は connection 名を参照するので、ARM resource ID を持っているだけでは不十分なこと。
2つ目は、1 scope 1 host・update 不可・REST 管理であること。subnet や接続名を後から修正する場合は、再作成前提で change window を切る必要があります。
3つ目は、private networking の agent subnet が Microsoft.App/environments に delegated された専用 subnet であることです。推奨サイズは /24、最小は /27、共有不可、RFC1918 の private range が前提です。 (Microsoft Learn)
検証コマンドの最低限
検証は、VNet 内の VM か VPN / ExpressRoute で接続したオンプレ端末 から行います。まずは Foundry endpoint と、依存する private endpoint 側の FQDN が private IP に解決されるかを確認します。 (Microsoft Learn)
nslookup <your-foundry-endpoint-hostname>
nslookup <your-private-service-fqdn>
Test-NetConnection <private-endpoint-ip> -Port 443Foundry の docs では、private endpoint の状態が Approved であること、VNet 内から Foundry endpoint が private IP に解決されること、443/TCP が到達することを最低確認としています。Storage、Search、Cosmos DB、社内 API も、同じネットワーク条件で名前解決と疎通を確認してください。 (Microsoft Learn)
Hosted agents を含む場合の注意
2026年4月の docs を合わせてみると、hosted agents の private networking 周りは要件整理が細かく更新されています。4月22日更新の hosted agents docs では network-isolated Foundry resource へのデプロイが案内される一方、private networking setup docs では network injection は account 作成時に含める必要があり、既存 account への後付けはサポートされないと書かれています。少なくとも本番で hosted agents を含めるなら、「既存 account に後から足す」前提ではなく、新規 account で先に検証するほうが安全です。 (Microsoft Learn)
周知チェックリスト
技術設定だけでなく、誰に何を伝えるかを決めておかないと、発表直後の社内展開は失敗しやすくなります。以下は管理者が先に共有しておきたい内容です。 (TECHCOMMUNITY.MICROSOFT.COM)
| 周知先 | 伝える内容 | 伝えないと起きやすい誤解 |
|---|---|---|
| ネットワーク担当 | Private Endpoint は inbound 側、agent outbound は Capability Host と delegated subnet 側の話 | 「VM で通るから DNS/VPN は問題ないはず」で調査が止まる |
| セキュリティ / GRC | 同じ project の agent は同じ managed identity と connection 境界を共有する。project 分離が最小権限の基本 | 1 project に複数業務を載せて権限境界が崩れる |
| 開発 / agent オーナー | 401 は network 復旧後に出ることがある。これは auth 切り分けに進んだサイン | ネットワーク側の問題だと思い込み続ける |
| 運用 / ヘルプデスク | Capability Host は update 不可、409 は既存 host か同時操作、Pending は PE 承認や DNS を確認 | 誤った切り戻しや場当たり対応が増える |
| 変更承認 / 予算管理 | Standard Setup は customer-owned resources 前提で、Storage / Cosmos / Search の運用コストが増える。managed VNet preview の approved outbound では managed Azure Firewall コストも発生し得る | 「単なる設定追加でコスト影響は小さい」と誤解される |
本番周知では、「Capability Host を追加したら終わり」ではなく、project 分離、connection 境界、identity、再作成前提の変更管理までまとめて伝えると混乱が減ります。Microsoft の標準設計や高可用性ガイドでも、state store を customer-owned resource として運用するなら、権限境界と削除保護を合わせて設計することが推奨されています。 (Microsoft Learn)
展開順序
最も事故が少ないのは、ネットワークの複雑さではなく access pattern の単純さ から pilot を始める順番です。Foundry の rollout guidance は、subscription / resource group、identity groups、region、security requirement を先に決めることを勧めていますし、baseline architecture は production で portal 主導の project 作成を避けるよう警告しています。 (Microsoft Learn)
- まずは 1 project、1 delegated subnet、1 private API の最小構成で pilot を作る
- DNS、private endpoint、managed identity、connection 認証を通す
- 同じ access pattern の workloads だけ横展開する
- 別の接続先や権限境界が必要な agent は、新しい project として分ける
- 検証が通ってから Azure Policy、delete lock、portal 制限を入れて本番へ広げる
この順番なら、「project を分けるべきだった」「subnet を変えたいが host を更新できない」「portal から作った project が intended perimeter を外れた」といった手戻りを本番前に潰しやすくなります。 (Microsoft Learn)
よくある失敗と対処
以下は、実際に管理者が最も踏みやすいポイントです。4月20日の blog と Learn の troubleshooting / networking / standard setup docs をベースに整理しています。 (TECHCOMMUNITY.MICROSOFT.COM)
| 症状 | まず見る場所 | 典型原因 | 次の一手 |
|---|---|---|---|
| VM からは成功、agent だけ失敗 | project capability host、customer subnet、association 状態 | agent runtime が VNet に入っていない | host と subnet binding を確認し、agent を再検証する |
| 401 が出る | connection 認証、header、audience | private path は復旧したが認証が崩れている | token / credential / auth flow を確認する |
| Capability Host 作成で 409、更新で失敗 | 既存 host、同時操作、update 実施有無 | 1 scope 1 host、update 不可 | 既存 host を GET で確認し、必要なら delete/recreate で切り替える |
| Private Endpoint が Pending、または public IP に解決される | PE 承認、private DNS zone link、on-prem DNS forwarder | 承認不足、DNS 未連携 | 承認後に privatelink 解決を再確認する |
| subnet を正しく切ったつもりなのに動かない | subnet delegation、IP range、共有有無 | shared subnet、サイズ不足、誤った IP plan | dedicated subnet、/24 推奨・/27 最小、private range を再確認する |
| private で tool の挙動が想定と違う | tool support matrix、portal / agent type | network isolation 未対応または部分対応 | tool ごとの support matrix を先に確認する |
tool 周りでは、「動くかどうか」と「完全に private かどうか」を分けて考えるのが重要です。例えば、network isolation docs では public endpoint tools は動作しても public internet を使うと説明されていますし、Publish Agent to Teams / M365 は network isolation 非対応、Workflow Agents の outbound virtual network injection は未対応、Blob Storage の File Search も private networking docs で非対応とされています。network fault と機能制約を混同しないことが大切です。 (Microsoft Learn)
補足すると、subnet 設計そのものが原因になることもあります。private networking docs では RFC1918 の private IP range を前提とし、172.17.0.0/16 は Docker bridge networking 用に避けるよう案内しています。VNet だけ正しければよい、とは考えないほうが安全です。 (Microsoft Learn)
本番運用で追加したいガードレール
ここまでを設定できても、運用ガードレールがなければ長期運用で崩れます。Microsoft の Azure Policy、HA/DR、baseline architecture から、管理者が最初に入れておきたいものを絞ると次のとおりです。 (Microsoft Learn)
| ガードレール | 目的 | 実務メモ |
|---|---|---|
| Azure Policy で valid Agent capability host を audit | host 抜けの早期発見 | まず audit、慣れてから prod だけ deny に寄せる |
| Foundry / Cosmos / Search / Storage に delete lock | 誤削除防止 | Foundry account lock は projects、models、connections、agent capability hosts も守れる |
| project は UAMI 優先 | 再作成時の role 再付与を減らす | project / capability host 復旧の手間を減らせる |
| IaC と source control を標準化 | 再現可能な再展開 | agent 定義、connection、prompt、tool 設定を repo に残す |
| production portal access を最小化 | 情報露出と事故を減らす | portal 閲覧だけのつもりでも data plane 事故を避けにくい |
運用面で特に見落としやすいのは 2 点です。1つ目は、Foundry の built-in AI role には data plane を安全に「閲覧だけ」にする read-only 役割がないこと。2つ目は、Foundry account を復旧しても private endpoints は戻らないことです。したがって、本番 runbook には「private endpoint 再作成」「agent 定義と connection の再展開」「delete lock の付け直し」まで明記しておくべきです。 (Microsoft Learn)
最後にやること
要点を一文でまとめると、Microsoft Foundry の secure private AI connectivity は「Private Endpoint を作ったか」ではなく、agent がどこで実行され、どの connection と subnet を Capability Host で束ねたかで決まります。今日やるべきことは 3 つです。影響を受ける project を洗い出す、project 分離ルールと展開順序を決める、IaC で account / project capability host と private networking の検証を先に通す。この順番なら、2026年4月20日の更新を踏まえた展開でも、設定差分、周知項目、運用リスクを一度に揃えやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
コメント