Microsoft Foundry Agent Service でエンタープライズAIエージェントからオンプレミスAPIやプライベートAPIを呼び出す場合、「VNet内のVMからは疎通できるのに、Foundryエージェントからは失敗する」という問題が起きやすくなります。結論から言うと、多くの場合、VPNやExpressRouteそのものではなく、エージェント実行環境がVNet内に配置されていないことが原因です。Microsoftは2026年4月20日付のトラブルシューティング記事で、Foundry Agent Service の private networking では Capability Host を正しく作成・関連付けし、委任済みサブネット、DNS、RBAC、依存リソースをセットで確認する必要があると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
結論：Private Endpointだけでは、FoundryエージェントはVNet内で動かない
Microsoft Foundry Agent Service / private networking で最初に押さえるべきポイントは、Private Endpointを作っただけでは、エージェントのアウトバウンド通信が自社VNet経由になるとは限らないという点です。
Private Endpointは主に「外部から対象リソースへ安全に入るための入口」です。一方、エージェントがオンプレミスAPI、社内API、プライベートDNS名、VPN、ExpressRouteの経路を使って外へ出ていくには、エージェント実行環境がそのネットワーク設計を継承している必要があります。
Microsoftの説明では、Foundry Agent Service がオンプレミスAPIへVPNまたはExpressRoute経由でアクセスするシナリオで、VNet内のVMからはAPIに到達できるのに、FoundryエージェントからはDNS失敗、タイムアウト、HTTP 401/403、想定外のバックエンドURLやプロキシURLがログに出る、といった症状が起きることがあります。(TECHCOMMUNITY.MICROSOFT.COM)
このときの判断基準はシンプルです。
| 確認項目 | 見るべきポイント |
|---|---|
| VMからAPIに疎通できる | VNet、VPN/ExpressRoute、オンプレミスDNSはおおむね正しい可能性が高い |
| エージェントだけ失敗する | エージェント実行環境がVNetのDNS・ルーティングを継承していない可能性が高い |
| Private Endpointは作成済み | それだけではエージェントのアウトバウンド経路は保証されない |
| Capability Host未設定 | まずここを疑うべき |
つまり、ネットワーク担当者が「VMでは通る」と確認しても、AIアーキテクト側で「エージェントが本当にそのサブネットに注入されているか」を確認しなければ、調査は空回りします。
何が壊れるのか：よくある4つの障害パターン
Foundry Agent Service からプライベートAPIに接続できない場合、症状はネットワーク、DNS、認証、ツール設定に分かれて見えます。ただし、根本原因は同じとは限りません。
DNS解決に失敗する
最も典型的なのは、社内APIのFQDNをFoundryエージェントが解決できないケースです。
たとえば、以下のような設計です。
- オンプレミスAPI：
https://api.internal.example.com - VNet DNS：オンプレミスDNSへフォワード
- VPNまたはExpressRoute：Azure VNetと社内ネットワークを接続
- VNet内VM：
nslookupとcurlが成功 - Foundryエージェント：同じFQDNで失敗
この場合、DNSサーバーや条件付きフォワーダーが間違っているとは限りません。VMは確実にVNet内にありますが、エージェント実行環境がCapability HostによってVNetに注入されていなければ、VNet DNS設定、社内DNSフォワード、オンプレミス名前解決パスを継承できません。Microsoftのトラブルシューティング記事でも、この「VMはVNet内だが、エージェントはそうとは限らない」という点が重要な切り分けポイントとして示されています。(TECHCOMMUNITY.MICROSOFT.COM)
タイムアウトする
DNSは引けているように見えるのに接続がタイムアウトする場合は、次のような原因が考えられます。
| 原因候補 | 確認方法 |
|---|---|
| エージェントがVNet経路を使っていない | Capability Hostと対象サブネットの関連付けを確認 |
| サブネットのルートテーブルが想定外 | UDR、NVA、Azure Firewall、ExpressRoute経路を確認 |
| オンプレミス側ファイアウォールで送信元が許可されていない | エージェントサブネットからの送信元IPレンジを許可 |
| Private Endpointや依存サービスへのDNSが壊れている | VNet内VMから各Private Link FQDNを nslookup で確認 |
特にオンプレミス側のACLでは、検証用VMのIPだけを許可していて、エージェント用サブネットのIPレンジを許可していないことがあります。検証VMが通ることと、エージェント実行環境が通ることは同じではありません。
HTTP 401または403が返る
HTTP 401や403が出ると、ネットワーク障害のように見えます。しかし、Microsoftは、サブネット注入とDNSが修正された後に401が出る場合、それはAPIに到達できるようになったことを示す「前進」であり、調査対象はネットワークから認証・認可へ移ると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
この段階で見るべき項目は次の通りです。
| ステータス | 典型的な意味 | 次に見る場所 |
|---|---|---|
| 401 Unauthorized | トークン、APIキー、認証ヘッダーが不正または不足 | Foundry connection、Entra ID、API側の認証設定 |
| 403 Forbidden | 認証は通ったが権限不足、または送信元制限 | RBAC、API側ACL、オンプレミス側ファイアウォール |
| 404 Not Found | プロキシ経由で想定外のURLに到達、またはパス誤り | OpenAPI定義、backend URL、gateway設定 |
| 5xx | API側、プロキシ、ゲートウェイ、依存サービスの問題 | APIログ、APIM、NVA、アプリケーションログ |
401や403を「まだネットワークが壊れている」と決めつけると、調査が長引きます。DNSと経路が通った後は、APIが期待するヘッダー、audience、OAuthフロー、マネージドID、トークン発行元を確認するのが現実的です。
想定外のプロキシURLやバックエンドURLがログに出る
FoundryエージェントがOpenAPI tool、MCP、A2A、API Gateway、API Managementなどを経由してAPIを呼ぶ場合、ログ上のURLが社内APIのFQDNではなく、プロキシやゲートウェイのURLに見えることがあります。
この場合は、次の3層に分けて確認します。
- エージェントからツール定義上のエンドポイントへ到達できるか
- ツール、プロキシ、ゲートウェイが正しいバックエンドへ転送しているか
- バックエンドAPIが正しい認証情報と送信元を受け入れているか
「エージェントからAPIへ直接アクセスしている」と思い込んでいると、実際にはFoundry側の接続、OpenAPI定義、API Management、オンプレミスリバースプロキシのいずれかでURLや認証が変換されている可能性を見落とします。
Microsoftが示す修正方針：Capability Hostを中心に設計を組み直す
Microsoftが強調している修正方針は、Capability Hostを正しく作成・関連付けすることです。Capability Hostは、Foundry Agent Service の機能がどこで実行され、どのストレージ、検索、スレッド保存、モデル接続を使うかを決めるサブリソースです。Microsoft Learnでは、Capability Hostはアカウントスコープとプロジェクトスコープで構成され、会話履歴、ファイルアップロード、ベクトルストアなどの保存・処理先を指定すると説明されています。(Microsoft Learn)
Project Capability HostとAgent Capability Hostの考え方
Microsoftのトラブルシューティング記事では、プライベートネットワーク利用時にCapability Hostが次の役割を持つと説明されています。
| 種類 | 役割 | 向いているケース |
|---|---|---|
| Project Capability Host | プロジェクト全体を顧客管理サブネットに関連付ける | 同一プロジェクト内のエージェントを同じ分離境界で動かす |
| Agent Capability Host | 個別エージェント単位でサブネット配置を明示・上書きする | エージェントごとに異なるネットワーク境界やデータ境界が必要 |
実務では、まずProject Capability Hostを標準にすると運用しやすくなります。プロジェクト内の全エージェントに共通のVNet、DNS、セキュリティ制御を適用できるためです。部門別、機密区分別、リージョン別に分離が必要な場合は、プロジェクトを分けるか、個別エージェントの分離要件を設計段階で整理します。
Capability Hostなしで何が起きるか
Capability Hostが関連付けられていない場合、エージェント実行環境は顧客VNetへ注入されません。その結果、VPN、ExpressRoute、Private Endpoint、オンプレミスDNSが正しく構成されていても、エージェントはその経路を使えません。Microsoftの表現を実務向けに言い換えると、「No Capability Host = No VNet injection = No on-prem connectivity」 です。(TECHCOMMUNITY.MICROSOFT.COM)
この状態で起きる典型的な誤解は次の通りです。
| 誤解 | 実際 |
|---|---|
| Private Endpointを作ったのでエージェントもVNet内にいる | Private Endpointだけではエージェント実行環境の配置は決まらない |
| VMからAPIへ通るのでFoundry側も通るはず | VMとエージェントは同じ実行場所ではない可能性がある |
| DNSは正しいので原因はAPI側 | エージェントがVNet DNSを継承していない可能性がある |
| VPN/ExpressRouteの障害だ | まずエージェントのCapability Host関連付けを確認すべき |
デプロイ前に確認すべき前提条件
Microsoft Foundry Agent Service の private networking は、単に「AIサービスにPrivate Endpointを付ける」だけの構成ではありません。標準セットアップ、顧客所有リソース、委任済みサブネット、Private DNS、RBACが組み合わさります。
Microsoft Learnの private networking ドキュメントでは、Standard Setup with private networking により、パブリックエグレスなし、コンテナ注入、プライベートリソースアクセスを実現する構成が説明されています。また、ネットワークセキュア環境の構成にはプログラムによるデプロイが必要で、Azure portalからのデプロイは現時点でサポートされないと記載されています。(Microsoft Learn)
必要なAzureリソース
Standard agent setupでは、エージェントの状態やデータを自社のAzureリソースに保存します。Microsoft Learnでは、標準セットアップの依存リソースとして、Azure Cosmos DB、Azure Storage、Azure AI Search、Azure Key Vaultなどが挙げられています。(Microsoft Learn)
| リソース | 主な役割 |
|---|---|
| Azure Cosmos DB | スレッド、会話履歴、エージェント定義など |
| Azure Storage | ファイル、添付、成果物 |
| Azure AI Search | ベクトルストア、検索、RAG関連 |
| Azure AI Services / Azure OpenAI | モデル実行 |
| Azure Key Vault | シークレットや接続情報の管理 |
| VNet / Agent Subnet | エージェント実行環境のネットワーク境界 |
| Private DNS Zone | Private Endpointや社内DNS名の解決 |
| VPN / ExpressRoute | オンプレミスAPIへのプライベート接続 |
ここで重要なのは、これらのリソースを「後から足せばよい」と考えないことです。Capability Hostは、必要な接続名や依存リソースを参照します。Microsoft Learnでは、Capability Hostの構成を後から更新することはサポートされず、変更するには削除して再作成する必要があると説明されています。(Microsoft Learn)
サブネットは専用・委任済みにする
Agent Service private networkingでは、エージェント用サブネットを適切に委任する必要があります。Microsoft LearnのFAQでは、Agent Service networking は Azure Container Apps を使用し、VNetにデプロイする場合は Microsoft.App/environments に委任された専用サブネットが必要とされています。(Microsoft Learn)
また、private networking ドキュメントでは、既存VNetとサブネットを持ち込む場合の最小サブネットサイズは /27、推奨は /24 と説明されています。(Microsoft Learn)
実務上は、次のように設計するとトラブルを減らせます。
| 設計項目 | 推奨 |
|---|---|
| Agent Subnet | Foundryリソースごとに専用化 |
| サブネットサイズ | 余裕を持って /24 を検討 |
| サブネット委任 | Microsoft.App/environments |
| Private Endpoint用サブネット | Agent Subnetとは分離 |
| ルートテーブル | オンプレミスAPI、Azure依存リソース、インターネット制御を明示 |
| DNS | Private LinkとオンプレミスDNSの両方を設計 |
サブネットを共有すると、セキュリティ境界、IP枯渇、ルート変更の影響範囲が読みにくくなります。AIエージェントは将来的にツールやAPI呼び出しが増えやすいため、PoC段階でも本番に近いネットワーク境界を意識した方が安全です。
リージョンをそろえる
Microsoft Learnでは、Foundry、Azure Cosmos DB、Storage、Azure AI Search、Managed Identity、Azure OpenAIなど、Foundryワークスペース関連リソースはVNetと同じリージョンに配置する必要があると説明されています。(Microsoft Learn)
グローバル企業では、ここが意外な落とし穴です。たとえば、日本リージョンのVNetから米国リージョンのAI SearchやCosmos DBを参照するような構成は、レイテンシだけでなくサポート要件、データ所在地、Private Endpoint設計の観点でも問題になります。
設計時には、少なくとも以下を同じリージョン単位でまとめてください。
- Foundry account / project
- Agent Subnetを含むVNet
- Azure Storage
- Azure Cosmos DB
- Azure AI Search
- Azure AI Services / Azure OpenAI
- Private Endpoint
- 関連するPrivate DNS設計
トラブルシューティング手順：VM確認で止めず、エージェント配置まで確認する
FoundryエージェントがVPNまたはExpressRoute経由でオンプレミスAPIにアクセスできない場合は、次の順で確認します。
| 順序 | 確認内容 | 失敗時の対応 |
|---|---|---|
| 1 | Capability Hostが作成されているか | Account / Project Capability Hostを作成 |
| 2 | Capability Hostが正しいサブネットを参照しているか | customerSubnetや接続名を確認 |
| 3 | Agent Subnetが委任済みか | Microsoft.App/environments 委任を確認 |
| 4 | 依存リソース接続が作成済みか | Storage、Cosmos DB、AI Search、Azure OpenAI接続を確認 |
| 5 | VNet DNSがオンプレミスDNSへ到達できるか | VMから nslookup、条件付きフォワーダーを確認 |
| 6 | Private EndpointのDNSがプライベートIPを返すか | Private DNS ZoneのリンクとAレコードを確認 |
| 7 | エージェントがAPIを呼ぶ経路が正しいか | OpenAPI定義、Gateway、プロキシURLを確認 |
| 8 | 401/403なら認証・認可を確認 | トークン、RBAC、API ACL、送信元制限を確認 |
この順序で重要なのは、DNSやVPNを深掘りする前に、Capability Hostとサブネット関連付けを確認することです。Microsoftのトラブルシューティング記事でも、Capability Hostと正しいサブネットの関連付けが満たされていない場合、他の調査は時期尚早だと整理されています。(TECHCOMMUNITY.MICROSOFT.COM)
手順：まずCapability Hostの状態を見る
Capability Hostの確認では、次の観点を見ます。
- Account Capability Hostが存在するか
- Project Capability Hostが存在するか
- Project Capability Hostが正しい接続名を参照しているか
- Cosmos DB、Storage、AI Searchの接続がプロジェクトに存在するか
- Capability Hostの状態が
Succeededか - 既存Capability Hostを変更しようとしていないか
Microsoft Learnでは、Capability Hostはアカウントとプロジェクトの両方に構成でき、プロジェクトレベルのCapability Hostでは threadStorageConnections、vectorStoreConnections、storageConnections が標準セットアップの主要プロパティとして示されています。(Microsoft Learn)
変更が必要な場合は注意が必要です。Capability Hostは更新非対応のため、構成変更が必要なら削除・再作成が必要です。既存のエージェントやデータへの影響も事前に確認してください。
手順：DNSを「VMから」だけでなく「サブネット設計」として確認する
DNS確認では、VNet内VMから以下を確認します。
nslookup api.internal.example.com
nslookup <storage-account>.blob.core.windows.net
nslookup <search-service>.search.windows.net
nslookup <cosmos-account>.documents.azure.com
nslookup <foundry-or-openai-endpoint>Private Endpointを使うAzureリソースは、プライベートIPに解決される必要があります。Microsoft Learnでは、Private EndpointのDNS解決に失敗する場合、Private DNS ZoneがVNetにリンクされているか、条件付きフォワーダーがAzure DNS Virtual Serverの 168.63.129.16 を向いているかを確認するよう説明されています。(Microsoft Learn)
ただし、VMからのDNS確認は「DNS設計が正しいか」を見るためのものです。エージェントがそのDNSを使うには、Capability Hostによるサブネット注入が成功している必要があります。
手順：VPN / ExpressRouteの経路を確認する
オンプレミスAPIへの経路では、次を確認します。
| 確認項目 | 例 |
|---|---|
| Azure側ルート | Agent SubnetからオンプレミスCIDRへの経路が存在するか |
| オンプレミス戻り経路 | オンプレミス側からAgent Subnetへの戻り経路があるか |
| ファイアウォール | Agent Subnetの送信元IPレンジが許可されているか |
| DNS | 社内FQDNがオンプレミスDNSで解決されるか |
| TLS | 社内CA証明書、SNI、TLS inspectionの影響がないか |
| プロキシ | 明示プロキシや透過プロキシが認証を要求していないか |
特にExpressRouteでは、VM検証用サブネットとAgent Subnetで経路やファイアウォールルールが異なることがあります。「同じVNetだから同じ経路」とは限りません。
手順：401/403はネットワークではなくIDとして切り分ける
Foundry Agent Service の本番運用では、APIキーよりもMicrosoft Entra IDやManaged Identityを前提に設計するケースが多くなります。Microsoft Learnでは、Microsoft Foundryの認証方式としてMicrosoft Entra IDとAPIキーが説明され、Microsoft Entra IDは条件付きアクセス、Managed Identity、きめ細かなRBACに対応し、本番ワークロードで推奨されています。(Microsoft Learn)
401/403が出た場合は、次を確認します。
| 観点 | 確認内容 |
|---|---|
| トークン | audience、issuer、tenant、スコープがAPI側の期待と一致するか |
| Managed Identity | APIまたは依存リソースに必要なロールが付与されているか |
| Foundry connection | 正しい認証方式、ヘッダー、接続先を使っているか |
| API側ACL | Agent SubnetやGatewayからの送信元を許可しているか |
| プロキシ | Authorizationヘッダーを落としていないか |
| OpenAPI定義 | 認証スキーム、server URL、pathが正しいか |
ネットワークチームとアプリチームが分かれている企業では、「401はネットワークではなく認証」という共通認識を持つだけで、調査時間を大きく短縮できます。
構成ミスを防ぐ設計チェックリスト
Foundry Agent Service / private networking を本番で使う場合、設計レビューでは次のチェックリストを使うと実務的です。
| 分野 | チェック項目 |
|---|---|
| 実行場所 | Capability Hostでエージェント実行環境が正しいサブネットに関連付いているか |
| サブネット | Agent Subnetが専用で、Microsoft.App/environments に委任されているか |
| IP設計 | /27以上、できれば/24など将来拡張を見込んだサイズか |
| DNS | Private Link用DNSとオンプレミスDNSフォワードの両方が設計されているか |
| VPN / ExpressRoute | Agent SubnetからオンプレミスAPIへの往復経路があるか |
| 依存リソース | Storage、Cosmos DB、AI Search、Azure OpenAIが接続済みか |
| RBAC | 作成者、プロジェクトManaged Identity、開発者に必要最小限の権限があるか |
| 認証 | 本番ではEntra ID、Managed Identity、最小権限を優先しているか |
| デプロイ方法 | portal任せではなく、Bicep、Terraform、CLI、REST APIなどで再現可能か |
| 変更管理 | Capability Hostは更新できない前提で再作成手順を用意しているか |
| 監査 | エージェントのツール呼び出し、APIログ、Gatewayログを追跡できるか |
このチェックリストで最も優先度が高いのは、実行場所、サブネット、DNSです。ここが崩れていると、認証、API設計、プロキシ設定をどれだけ調整しても解決しません。
よくある失敗例と回避策
失敗例：Private Endpoint作成で完了だと思ってしまう
Private Endpointは重要ですが、それだけでエージェント実行環境のアウトバウンド経路は決まりません。FoundryエージェントがVNet DNS、ルート、セキュリティ制御を継承するには、Capability Hostとサブネット注入が必要です。
回避策は、設計書に「Private Endpoint」と「Agent Runtime Placement」を別項目として明記することです。
失敗例：検証VMだけで疎通確認を終える
VMで curl が成功しても、Foundryエージェントが同じ経路を通るとは限りません。VM検証は必要ですが、十分条件ではありません。
回避策は、以下のように検証段階を分けることです。
| 検証 | 目的 |
|---|---|
| VNet内VMからAPI疎通 | ネットワークとDNSの基本設計を確認 |
| Capability Host状態確認 | エージェントがVNet設計を継承する前提を確認 |
| エージェントからテストAPI呼び出し | 実際のツール呼び出し経路を確認 |
| 認証付きAPI呼び出し | ID、ヘッダー、権限を確認 |
失敗例：Capability Hostを後から直せると思っている
Capability Hostは構成変更をインプレース更新できません。Microsoft Learnでも、変更には削除と再作成が必要とされています。(Microsoft Learn)
回避策は、PoC段階から本番に近い接続名、リージョン、サブネット、依存リソースを使うことです。仮の構成で作って後から本番仕様に変更する運用は、手戻りが大きくなります。
失敗例：Hosted agentsとネットワーク分離の制約を見落とす
Microsoft Learnでは、Hosted agentsはプレビューであり、ネットワーク分離されたFoundryリソース内でStandard Setupによるネットワーク分離を使って作成することはできないと説明されています。(Microsoft Learn)
回避策は、採用するエージェント形態とネットワーク要件を早い段階で突き合わせることです。特に、フルネットワーク分離、オンプレミスAPI接続、閉域アクセスが必須の案件では、サポートされる構成とデプロイ方法を事前に確認してください。
本番導入での推奨アーキテクチャの考え方
Enterprise AI architects、network engineers、security architectsが共同で設計する場合、責任分界を明確にするとトラブルが減ります。
| 役割 | 主な責任 |
|---|---|
| AIアーキテクト | Foundry project、agent、tools、Capability Host、依存リソース接続 |
| ネットワークエンジニア | VNet、サブネット、VPN、ExpressRoute、UDR、Firewall、DNS |
| セキュリティアーキテクト | RBAC、Managed Identity、API認可、監査、データ境界 |
| アプリ/APIチーム | OpenAPI定義、認証方式、バックエンドURL、APIログ |
実務で有効なのは、「エージェントからAPIへ」の経路を1本の通信フローとして図にすることです。
Foundry Agent
↓
Capability Host
↓
Delegated Agent Subnet
↓
VNet DNS / Private DNS / Corporate DNS
↓
Route Table / Firewall / VPN or ExpressRoute
↓
On-premises API Gateway or Private API
↓
Backend APIこの図に、認証情報の流れも重ねます。
Agent / Tool
↓ Authorization header or Managed Identity
Gateway / API Management / Proxy
↓ Header transformation or token validation
Private API
↓ Application authorization
Backend systemネットワーク経路と認証経路を分けて可視化すると、「DNSは解決しているが401」「APIには届くが送信元ACLで403」「Gatewayまでは届くがバックエンドURLが違う」といった切り分けがしやすくなります。
すぐに取るべき次の行動
Microsoft Foundry Agent Service / private networking でVPNまたはExpressRoute経由のプライベートAPI接続が失敗している場合、最初にやるべきことはVPN機器やオンプレミスDNSの再設定ではありません。まず、Foundryエージェントがどこで実行されているかを確認してください。
次の順で進めるのが最短です。
- Project Capability Hostが存在し、正しいサブネットを参照しているか確認する
- Agent Subnetが専用で、
Microsoft.App/environmentsに委任されているか確認する - VNet内VMからオンプレミスAPIとPrivate Link FQDNのDNS解決を確認する
- エージェントからテスト用の単純なAPIを呼び、経路を確認する
- 401/403が出たら、ネットワークではなく認証・認可として切り分ける
- 変更が必要なCapability Hostは、更新ではなく再作成前提で影響範囲を確認する
この問題の本質は、「社内APIにAIエージェントを安全につなぐ」ことではなく、「AIエージェントの実行場所、DNS、ルーティング、IDを企業ネットワーク設計の一部として扱う」ことです。Foundry Agent Service の private networking は強力ですが、Private Endpoint、VPN、ExpressRoute、DNS、Capability Hostを個別に設定するだけでは不十分です。設計レビューでは、Capability Hostを中心に、エージェント実行環境が本当にVNetの制御下にあるかを最優先で確認してください。
コメント