これらの手順の背後にあるネットワーク アーキテクチャ、サブネットのサイズ設定、および IP 割り当てモデルの背景については、 Foundry Agent Service ネットワークの詳細を参照してください。
この記事では、2 つの方法について説明します。
ポータルまたはテンプレート パスを使用して、ネットワークで保護された Foundry 環境を Bicep または Terraform でプロビジョニングします。
Azure Developer CLI パスを使用して、azdホステッド エージェント プロジェクトの依存関係をプライベート エンドポイントの背後に配置します。 セレクターを使用してメソッドを選択します。
Foundry Agent Service は、 プライベート ネットワーク環境を備えた Standard セットアップを 提供します。 このセットアップにより、ネットワーク インフラストラクチャを完全に制御しながら、データへの安全なアクセスを可能にする分離されたネットワーク環境が作成されます。
既定では、プライベート ネットワークを使用した標準セットアップでは、次の処理が保証されます。
- パブリック エグレスなし: 基盤インフラストラクチャは、信頼されたサービス バイパスを必要とせずに、エージェントとツールに適切な認証とセキュリティを提供します。
- サブネット統合: 仮想ネットワークから委任されたサブネットを提供します。 プラットフォームはエージェント コンピューティングをこのサブネットに接続し、同じ仮想ネットワーク内のAzure リソースとのローカル通信を可能にします。
- プライベート リソース アクセス: リソースがプライベートとしてマークされ、インターネットから検出できない場合でも、プラットフォーム ネットワークは必要な資格情報と承認が行われているときにアクセスできます。
既存の仮想ネットワークがない場合は、プライベート ネットワーク フローを使用した Standard セットアップで必要なネットワーク インフラストラクチャをプロビジョニングできます。
前提 条件
Azure サブスクリプション - 無料で作成。
アカウントとプロジェクトを作成する個人が、サブスクリプション スコープで Foundry アカウント所有者 ロールを持っていることを確認します。
重要
Foundry RBAC ロールの名前が最近変更されました。 Foundry User, Foundry Owner, Foundry Account Owner、および Foundry Project Manager は、以前は、AZURE AI ユーザー、Azure AI 所有者、Azure AI アカウント所有者、および AZURE AI Project Manager という名前でした。 名前の変更がロールアウトされている間、以前の名前が表示される場合があります。ロール ID とコア アクセス許可は、名前の変更によって変更されません。
このセットアップを作成するユーザーには、必要なリソース (Azure Cosmos DB、Azure AI 検索、Azure Storage) にロールを割り当てるアクセス許可も必要です。
- 必要な組み込みロールは 、ロール ベースのアクセス管理者です。
- または、サブスクリプション レベルで 所有者 ロールを持つことも、この要件を満たします。
- 必要な主なアクセス許可は次のとおりです:
Microsoft.Authorization/roleAssignments/write
エージェント環境が構成されたら、Agent Playground または SDK を使用してエージェントを作成または編集する各チーム メンバーに、プロジェクトの組み込みの Foundry ユーザーRBAC ロール が割り当てられていることを確認します。
- 必要なアクセス許可の最小セットは、agents/*/read、agents/*/action、agents/*/delete です。
プロバイダーを登録します。 次のプロバイダーを登録する必要があります。
Microsoft.KeyVaultMicrosoft.CognitiveServicesMicrosoft.StorageMicrosoft.MachineLearningServicesMicrosoft.SearchMicrosoft.NetworkMicrosoft.AppMicrosoft.ContainerService- Bing検索ツールを使用するには:
Microsoft.Bing
az provider register --namespace 'Microsoft.KeyVault' az provider register --namespace 'Microsoft.CognitiveServices' az provider register --namespace 'Microsoft.Storage' az provider register --namespace 'Microsoft.MachineLearningServices' az provider register --namespace 'Microsoft.Search' az provider register --namespace 'Microsoft.Network' az provider register --namespace 'Microsoft.App' az provider register --namespace 'Microsoft.ContainerService' # only to use Grounding with Bing Search tool az provider register --namespace 'Microsoft.Bing'
重要
Standard のセットアップでは、すべてのエージェント データが Azure テナントに留まるよう、Bring Your Own (BYO) リソースを使用する必要があります
BYO リソースには、Azure Storage、Azure AI 検索、およびAzure Cosmos DBが含まれます。
Foundry Agent Service によって処理されるすべてのデータは、これらのリソースに自動的に保存され、コンプライアンス要件とエンタープライズ セキュリティ標準を満たすのに役立ちます。
ネットワークで保護された環境を構成する
このセットアップは、Azure ポータルで作成することも、Bicepまたは Terraform を使用してデプロイすることもできます。
大まかに言えば、デプロイには次の手順が含まれます。
- Foundry リソースのターゲット Azure リージョンを選択します。
- 独自の VNet とサブネットを使用するか、自動プロビジョニングされたネットワークを使用するかを決定します。
- 独自の VNet を持ち込む場合は、VNet とサブネット リソース ID を収集します。
- Azure ポータルでセットアップを作成するか、Bicepまたは Terraform を使用してデプロイします。
- デプロイを確認します (デプロイ の確認を参照してください)。
セットアップでは、次のリソースがプロビジョニングされます (持ち込む場合を除く)。
- Foundry アカウントと Foundry プロジェクト。
- gpt-4o モデルのデプロイ。
- ファイル、スレッド、ベクター データを格納するためのAzure Storage、Azure Cosmos DB、およびAzure AI 検索。
- これらのリソースはプロジェクトに接続されます。
- ストレージ アカウントと Cognitive Account (Foundry) のMicrosoftマネージド暗号化キーが既定で使用されます。
次のタブを使用して、優先する展開方法を選択します。
- Azure ポータルで、Foundry を検索し、 リソースの作成を選択します。
- [基本] タブを構成したら、[ストレージ] タブを選択し、[エージェント サービス] で [リソースの選択] を選択します。
- ストレージ アカウント、Azure AI 検索 リソース、Azure Cosmos DB リソースを選択または作成します。 仮想ネットワークの挿入を使用している場合、エンドツーエンドの仮想ネットワーク全体の隔離を実現するStandard Agentを作成するには、独自のストレージ、Azure AI 検索、およびAzure Cosmos DBリソースを用意する必要があります。
- [ ストレージ ] タブを構成した後、[ ネットワーク ] タブを選択し、パブリック アクセスの [無効] オプションを選択します。
- [ プライベート エンドポイント ] セクションで、[ + プライベート エンドポイントの追加] を選択します。
- フォームを使用してプライベート エンドポイントを作成する場合は、次のことを確認してください。
- [基本] から、仮想ネットワークと同じリージョンを選択します。
- Virtual Network フォームから、接続先のvirtual networkとサブネットを選択します。
メモ
ポータル UI では、プライベート エンドポイントを作成するターゲットに "アカウント" というラベルを付ける必要があります。 メッセージが表示されたら、Foundry リソースを選択します。
- 受信プライベート エンドポイントを設定すると、 仮想ネットワークの挿入を設定するための新しいドロップダウンが表示されます。 最初のドロップダウンで仮想ネットワークを選択し、サブネットを選択します。そのサブネットはMicrosoft.App/environmentsに委任されており、サブネットサイズは/27以上である必要があります。 この委任とサブネットのサイズは、注入に必要です。
- フォームを続行してプロジェクトを作成します。 [ 確認と作成 ] タブに移動したら、設定を確認し、[ 作成 ] を選択してプロジェクトを作成します。
- 「デプロイの確認」のチェックに進みます。
メモ
Foundry リソースをデプロイするときに、Azure AI 検索、Azure Storage、Azure Cosmos DBへのプライベート エンドポイントは自動作成されません。 Azure ポータルのリソース ページで、これらのリソースへのプライベート エンドポイントを個別に作成してください。
デプロイを確認する
デプロイが完了したら、すべてのリソースが正しく構成されていることを確認します。
-
Confirm サブネット委任: Azure ポータルで、VNet >Subnets に移動し、エージェント サブネットに
Microsoft.App/environmentsへの委任が表示されていることを確認します。 - パブリック ネットワーク アクセスの確認: 各リソース (Foundry、Azure AI 検索、Azure Storage、Azure Cosmos DB) を開き、Public ネットワーク アクセスが Disabled に設定されていることを確認します。
-
プライベート エンドポイントの DNS 解決を検証する: VNet に接続されているマシンから、
nslookupに記載されている各エンドポイントに対してを実行します。 - エージェントの接続をテストする: VNet 内から Foundry プロジェクトにアクセスし ( セキュリティで保護されたエージェントへのアクセスを参照)、エージェントを作成して実行できることを確認します。
- ロールの割り当てを構成する: 次のコマンドを実行して、必要なロールを割り当てます。 1 つ目はユーザー割り当てマネージド ID に対してマネージド ID オペレーターを付与し、2 つ目はテナント間アクセス用にリモート VNet のネットワーク共同作成者を付与します。
az role assignment create \
--assignee <your-principal-id> \
--role "Managed Identity Operator" \
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<id>"
az role assignment create \
--assignee <service-principal-object-id-in-remote-tenant> \
--role "Network Contributor" \
--scope "/subscriptions/<remote-subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>"
制限
-
VNET とサブネットの IP アドレスの制限:
- エージェント サービスの委任されたサブネットには、有効なRFC1918プライベート IPv4 範囲 (
10.0.0.0/8、172.16-31.0.0/12、またはプライベート クラス A、クラス B、およびクラス C の IP 範囲とも呼ばれる192.168.0.0/16) 内の IP 範囲が必要です。 - プライベート クラス A の IP アドレス範囲 (
10.0.0.0/8) は、特定のリージョンでのみサポートされます。 クラス A の範囲をサポートするリージョンの一覧については、「 サポートされているリージョン」を参照してください。 クラス B (172.16.x.x) または C (192.168.x.x) の範囲を使用して、エージェント サービスを他のリージョンにデプロイします。 -
44.x.x.xや CGNAT アドレス範囲などのパブリック IP 範囲100.64.0.0-100.127.255.255は、エージェント サービスの委任されたサブネットではサポートされていません。 - VNET のアドレス空間が、Azure環境内の既存のネットワークまたは予約済み IP 範囲 (
169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、192.0.2.0/24、0.0.0.0/8、127.0.0.0/8、100.100.0.0/17、100.100.192.0/19、100.100.224.0/19、100.64.0.0/11など) と重複していないことを確認します。 この要件には、VNET に含まれるすべてのアドレス空間が含まれ、複数ある場合は、ピアリングされた VNET のアドレス空間も含まれます。
- エージェント サービスの委任されたサブネットには、有効なRFC1918プライベート IPv4 範囲 (
- エージェント サブネットの排他性: エージェント サブネットを複数の Foundry リソースで共有することはできません。 各 Foundry リソースでは、専用エージェント サブネットを使用する必要があります。
-
Agent サブネット サイズ:
Microsoft.App/environmentsへのサブネットの委任により、委任されたエージェント サブネットの推奨サイズは /24 (256 アドレス) です。 サブネットのサイズ設定の詳細については、Azure Container Apps に関するページを参照してください。 -
エージェント サブネットのエグレス ファイアウォール許可リスト: Azure Firewall をプライベートネットワークで保護された標準エージェントと統合する場合、『Azure Firewall との統合』記事の「マネージド ID」に記載されている完全修飾ドメイン名 (FQDN) を許可リストに追加するか、サービス タグ AzureActiveDirectory を追加します。
- 自己署名証明書を追加できる TLS 検査がファイアウォールで行われることがないことを確認します。 障害発生時に、ファイアウォールに着陸するトラフィックがあるかどうか、およびブロックされているトラフィックを調べます。
- ソース コード エージェントのデプロイの場合は、「 プライベート仮想ネットワークのファイアウォール要件」に記載されているデプロイ エンドポイントも許可します。
- Foundry リソースは、仮想ネットワーク (VNet) と同じリージョンにデプロイする必要があります。 Azure Cosmos DB、Azure AI 検索、Azure Storageなどの他のAzure リソースは、さまざまなリージョンにデプロイできます。 リージョン間デプロイのコストへの影響を考慮してください。
-
リージョンの可用性:
- モデル デプロイでサポートされているリージョンについては、「Azure OpenAI モデル リージョンのサポートを参照してください。
- Azure Blob Storage: ファイル検索ツールでのAzure Blob Storageファイルの使用はサポートされていません。
-
コード インタープリター ファイルの制限: プライベート ネットワーク (BYO) 構成では、コード インタープリターは、ファイルのアップロードやダウンロードを伴わないシナリオでのみ機能します。 このセットアップでは、ストレージ アカウントからファイルを取得できません。 コード インタープリターでファイルを使用する必要がある場合は、SDK を使用して、必要なファイルを使用してコンテナーを明示的に作成し、
container_idをコード インタープリターに渡す必要があります。 この回避策は、SDK を介してのみ使用できます。Foundry ポータル UI ではサポートされていません。 - Bing検索によるグラウンディング: サポートされているリージョンは、西ヨーロッパ、カナダ東部、スイス北部、スペイン中部、アラブ首長国連邦北部、韓国中部、ポーランド中部、東南アジア、米国西部、米国西部 2、米国西部 3、米国東部、米国東部 2、米国中部、インド南部、東日本、英国南部、フランス中部、ノルウェー東部、オーストラリア東部、カナダ中部、スウェーデン中部、南アフリカ北部、イタリア北部、ブラジル南部です。
- ネットワーク挿入の削除: Foundry リソースと Standard Agent をセキュリティで保護されたネットワーク セットアップで削除する場合は、Foundry リソースと仮想ネットワークを最後に削除します。 仮想ネットワークを削除する前に、Foundry リソースを削除して 消去 します。
- ホストされるエージェントの仮想ネットワークの挿入: ホストされたエージェントの場合、Foundry アカウントを初めて作成するときに、仮想ネットワーク構成 (ネットワークインジェクション) を含める必要があります。 作成後に既存の Foundry アカウントにネットワークインジェクションを追加することは、ホストされているエージェントではサポートされていません。
- プライベート ネットワークの背後にあるホステッド エージェント コンテナー レジストリ: ホストされるエージェントの場合、プライベート ネットワーク (パブリック ネットワーク アクセスが無効なプライベート エンドポイント) の背後にあるAzure Container Registry (ACR) のサポートは、Foundry プロジェクトが作成されたタイミングによって異なります。 2026 年 6 月 25 日以降に作成されたプロジェクトでは、プライベート ACR がサポートされます。 その日付より前に作成されたプロジェクトでは、プラットフォームがイメージをプルできるように、ACR にパブリック エンドポイント経由で到達できる必要があります。 既存のプロジェクトは影響を受けず、引き続きパブリック ネットワーク アクセスを使用します。
アーキテクチャ図
プロビジョニングされたネットワーク リソースを確認する
プライベート ネットワークで Standard Setup を使用すると、次のリソースが自動的にプロビジョニングされます。ただし、独自のリソースを持ち込む場合を除き、次のリソースが自動的にプロビジョニングされます。
ネットワーク インフラストラクチャ
- 仮想ネットワーク (192.168.0.0/16)
- エージェント サブネット (192.168.0.0/24): エージェントクライアントをホストします
- プライベート エンドポイント サブネット (192.168.1.0/24): プライベート エンドポイントをホストします
仮想ネットワークの機能
仮想ネットワークは、リソースに対して API 呼び出しを行うことができるエンドポイントを制御します。 Azure サービスは、定義されたネットワーク外のデバイスからの API 呼び出しを自動的に拒否します。
ネットワーク ルール
すべてのアカウントとそれに対応するプロジェクトは既定で パブリック ネットワーク アクセス無効 フラグで保護され、プライベート エンドポイント経由のアクセスを許可するための明示的な構成が必要です。 これらの規則は、REST や WebSocket を含むすべてのプロトコルに適用されます。
DNS ゾーン構成の概要
| Private Link リソースの種類 | サブ リソース | プライベート DNS ゾーン名 | パブリック DNS ゾーン フォワーダー |
|---|---|---|---|
| ファウンドリ | アカウント | privatelink.cognitiveservices.azure.comprivatelink.openai.azure.comprivatelink.services.ai.azure.com |
cognitiveservices.azure.comopenai.azure.comservices.ai.azure.com |
| Azure AI 検索 | 検索サービス | privatelink.search.windows.net |
search.windows.net |
| Azure Cosmos DB | Sql | privatelink.documents.azure.com |
documents.azure.com |
| Azure ストレージ | BLOB | privatelink.blob.core.windows.net |
blob.core.windows.net |
DNS サーバーで Azure DNS Virtual Server への条件付きフォワーダーを作成するには、上記の表に記載されているゾーンの一覧を使用します。 Azure DNS仮想サーバーの IP アドレスは 168.63.129.16 です。
セキュリティで保護されたエージェントにアクセスする
デプロイが完了したら、次のいずれかの方法を使用して、仮想ネットワークの背後にある Foundry プロジェクトにアクセスできます。
-
Azure VPN Gateway: オンプレミス ネットワークをプライベート接続経由で仮想ネットワークに接続します。 接続はパブリック インターネット経由で行われます。 使用できる VPN ゲートウェイには、次の 2 種類があります。
- ポイント対サイト: 各クライアント コンピューターは、VPN クライアントを使用して仮想ネットワークに接続します。
- サイト間: VPN デバイスは、仮想ネットワークをオンプレミス ネットワークに接続します。
- ExpressRoute: プライベート接続を介して、オンプレミスネットワークをクラウドに接続します。 接続は、接続プロバイダーを使用して行われます。
- Azure Bastion: このシナリオでは、仮想ネットワーク内にAzure仮想マシン (ジャンプ ボックスとも呼ばれます) を作成します。 その後、Azure Bastionを使用して VM に接続します。 Bastion を使用すると、ローカル Web ブラウザーから RDP または SSH セッションを使用して VM に接続できます。 その後、ジャンプ ボックスを開発環境として使用します。 仮想ネットワーク内であるため、ワークスペースに直接アクセスできます。
FAQ
仮想ネットワーク全体にどのアドレス範囲を使用する必要がありますか?
仮想ネットワーク アドレス範囲には、委任されたエージェント サブネットとプライベート エンドポイント サブネットの両方に十分なアドレス空間を残す任意のプライベート IP 範囲を指定できます。
ピアリングされた仮想ネットワークを使用するか、別の仮想ネットワークにリソースを配置できますか。
ピアリングされた仮想ネットワークはサポートされていますが、データ転送コストが増加する可能性があります。
複数の Foundry リソースで同じ仮想ネットワークとサブネットを再利用できますか?
はい。同じ VNET ですが、同じサブネットではありません。 複数の Foundry リソースで同じ仮想ネットワークを再利用できます。 ただし、各 Foundry リソースには、専用のエージェント ランタイム サブネットが必要です。 エージェント サブネットを複数の Foundry リソース間で共有することはできません。
仮想ネットワークは Foundry リソースと同じリソース グループに存在する必要がありますか?
いいえ。 仮想ネットワークと Foundry リソースは同じリソース グループ内に存在する必要はありませんが、同じリージョンに存在する必要があります。
トラブルシューティング ガイド
Azure ポータル、Bicep、Terraform のどちらを使用したかに関係なく、Standard エージェントのデプロイ中またはデプロイ後のエラーを解決するには、このガイドを参照してください。
デプロイ エラー
"CreateCapabilityHostRequestDto is invalid: Agents CapabilityHost supports a single, non empty value for vectorStoreConnections property."
"Agents CapabilityHost supports a single, non empty value for storageConnections property."
"Agents CapabilityHost supports a single, non empty value for threadStorageConnections property."
解決策: すべての Bring Your Own (BYO) リソースへのすべての接続を提供するには、すべての BYO リソースへの接続が必要です。 3 つのリソースがすべて提供されていないと、Foundry でセキュリティで保護された標準エージェントを作成することはできません。
"Provided subnet must be of the proper address space. Please provide a subnet which has address space in the range of 172 or 192."
解決策: 委任されたエージェント サブネットに適切な IP 範囲を使用していません。 有効なプライベート IP アドレス空間を使用していることを確認します。 有効なRFC1918範囲には、 10.0.0.0/8、 172.16-31.0.0/12、および 192.168.0.0/16が含まれます。 詳細については、上記の 制限事項を 参照してください。
"Subscripton is not registered with the required resource providers, please register with the resource providers Microsoft.App and Microsoft.ContainerService."
解決策: 正しいリソースの登録が見つかりません。 必要なリソースがテナントに登録されていることを確認します。
"Failed to create Aml RP virtual workspace due to System.Exception: Failed async operation." または "The resource operation completed with terminal provisioning state 'Failed'. Capability host operation failed."
解決策: これはキャッチオール エラーです。 セットアップを調査するためのサポート チケット要求を作成します。 機能ホストのエラーを調べます。
"Subnet requires any of the following delegation(s) [Microsoft.App/environments] to reference service association link /subscriptions/11111-aaaaa-2222-bbbb-333333333/resourceGroups/agentRANGEChange/providers/Microsoft.Network/virtualNetworks/my-agent-vnet/subnets/agent-subnet/serviceAssociationLinks/legionservicelink."
Solution: このエラーは、Azureでセキュリティで保護された標準テンプレートのセットアップを削除しようとして、すべてのリソースを正しく削除しなかった場合に表示されます。 1 つの解決策は、Azure ポータルで Foundry リソース ページに移動し、 削除されたリソースの管理を選択することです。 そこから、エージェントがこの仮想ネットワークに関連付けられたリソースを消去します。 もう 1 つのオプションは、セキュリティで保護された標準テンプレートで deleteCaphost.sh スクリプトを実行することです。
"Timeout of 60000ms exceeded" error when loading the Agent pages in the Foundry project
Solution: Foundry プロジェクトには、エージェントを作成するためのAzure Cosmos DBとの通信に関する問題があります。 Azure Cosmos DB (プライベート エンドポイントと DNS) への接続を確認します。
プライベート エンドポイントの DNS 解決が失敗する
解決策: プライベート エンドポイントを介してリソースに到達できない場合は、各プライベート DNS ゾーンが仮想ネットワークにリンクされていることを確認します。 条件付きフォワーダーが Azure DNS 仮想サーバーの IP アドレス 168.63.129.16 を指していることを確認します。 VNet に接続されているマシンから、 nslookup <resource-fqdn> 実行し、各名前がプライベート IP アドレスに解決されることを確認します。
次の手順
これで、ネットワークで保護されたアカウントとプロジェクトが正常に構成されました。 クイック スタートを使用して、最初のエージェントを作成します。
ネットワーク分離の構成とオプションの詳細については、「 ネットワーク分離の構成」を参照してください。
多くのエンタープライズ環境では、Foundry、コンテナー レジストリ、および Application Insights や Storage などの依存サービスにプライベート ネットワークからのみ到達できる必要があります。 このセクションでは、仮想ネットワーク (VNet) 内 azd プライベート エンドポイントの背後にある依存関係を持つホストされたエージェントをプロビジョニングしてデプロイする方法について説明します。
VNet 統合を実現するには、スキャフォールディングされたinfra/ Bicep テンプレートをカスタマイズし、VNet 内から (または VNet にアクセスして) azdを実行します。
前提 条件
- 初期化されたホステッド エージェント プロジェクト。 作成するには、「Azure Developer CLI を使用してホストされるエージェント プロジェクトを初期化する」を参照してください。
- Azure Developer CLI Foundry 拡張機能がインストールされています。
- 仮想ネットワーク (新規または既存) と、プライベート エンドポイントとプライベート DNS ゾーンを作成するためのアクセス許可。
- スキャフォールディングされた Bicep に関する知識。 Azure Developer CLI を使用したホステッド エージェント インフラストラクチャに関するページを参照してください。
azd デプロイにおける VNet 保護の意味
ホストされるエージェント プロジェクトは、いくつかのAzure リソースをプロビジョニングします。 それぞれのパブリック ネットワーク アクセスを無効にし、VNet にプライベート エンドポイントを配置できます。
| Resource | VNet で保護できますか? | プライベート モードの意味 |
|---|---|---|
| AI サービス アカウント | はい | Foundry アカウントは、データ プレーン呼び出しと ARM 呼び出しの両方について、プライベート エンドポイント経由でのみ到達可能です。 |
| 鋳造プロジェクト | はい(アカウントを使用) | アカウントのネットワーク体制を継承します。 |
| Azure Container Registry | はい |
publicNetworkAccess: Disabled。 プライベート エンドポイントを介してビルド、プッシュ、プルが行われます。 |
| Application Insights | はい(Azure Monitor Private Link スコープを使用) | テレメトリの取り込みは、プライベート リンク スコープを経由して行われます。 |
| Azure Storage | はい | BLOB、ファイル、およびキュー サービスは、プライベート エンドポイントの背後に配置されます。 |
| エージェントのエンドポイント自体 | いいえ、このプレビューでは | デプロイされたエージェント エンドポイントの URL は、パブリックにアドレス指定可能なままです。 各ユーザーのセッションは、ID によって分離されます。 「ユーザーごとにホストされるエージェント セッションを分離する」を参照してください。 |
エージェント エンドポイント自体をプライベートにする必要がある場合、これは現在、この拡張機能の範囲外のプラットフォーム側の機能です。
拡張機能の機能と実行しない機能
| 能力 | 地位 |
|---|---|
| VNet 統合を有効にする CLI フラグ | サポートされていません。 既定では、 --vnet フラグまたは --private-endpoint フラグは付属しません。 |
| 既存のプライベート ACR の再利用 |
AZURE_CONTAINER_REGISTRY_RESOURCE_IDとAZURE_CONTAINER_REGISTRY_ENDPOINTでサポートされます。
プライベート Azure Container Registryを使用したホステッド エージェントのデプロイに関するページを参照してください。 |
| 既存の Foundry アカウントの再利用 |
AZURE_AI_ACCOUNT_NAMEとUSE_EXISTING_AI_PROJECT=trueでサポートされます。 |
infra/ のカスタム Bicep モジュール |
完全にサポートされています。
infra/ ディレクトリは、ご自身が所有する標準の azd Bicep ディレクトリです。 |
azd ai agent doctor VNet の内部から |
動作します。 リモート チェックでは、Foundry データ プレーン エンドポイントの DNS 解決が必要です。 それらをスキップするには、--local-onlyを使用します。 |
| VNet 内のセルフホステッド GitHub ランナーまたは Azure DevOps エージェント | 推奨されるパターン。 CI は、ネットワーク内からプロビジョニングとデプロイを行います。 |
トポロジを決定する
ほとんどの VNet で保護されたデプロイは、次のいずれかの形に分類されます。 Bicep を編集する前に、1 つ選択してください。
- Greenfield、新しい VNet 内にすべてを配置。
azd ai agent init実行し、スキャフォールディングされたinfra/にプライベート エンドポイント モジュールを追加します。 VNet とリソースの両方を 1 つのBicep実行からプロビジョニングします。 - Brownfield、既存の VNet に接続します。 グリーンフィールドアプローチと同じですが、既存の VNet を作成するのではなく、パラメーターを使用して参照します。 これは、別のチームがネットワークを所有している場合に便利です。
- 既存のすべてのリソースを再利用します。 プラットフォーム チームが、プライベート エンドポイントで Foundry アカウント、ACR、Application Insights を事前プロビジョニングしました。 エージェント定義のみを取り込み、環境変数を既存のリソースにポイントします。
main.bicepは、不足しているものだけを作成します。
トポロジ 2 とトポロジ 3 は、規制対象企業で最も一般的です。 トポロジ 1 は自己完結型パイロットに適合します。
スキャフォールディングされた Bicep のカスタマイズ
infra/によって生成される azd ai agent init ディレクトリは、標準のazd Bicepです。 その所有権はお客様にあり、変更はデプロイ後も保持されます。 既定のテンプレートではパブリック リソースが作成されるため、プライベート エンドポイントを追加するためにリソースを置き換えるか拡張します。
VNet とサブネットのパラメーターを追加する
infra/main.bicep にパラメーターを追加し、infra/main.parameters.json でそれらをバインドします:
// infra/main.bicep (excerpt)
@description('Resource ID of the existing virtual network. If empty, a new VNet is created.')
param vnetResourceId string = ''
@description('Name of the subnet hosting private endpoints.')
param privateEndpointSubnetName string = 'snet-pe'
@description('Disable public network access on data-plane resources.')
param disablePublicNetworkAccess bool = true
// infra/main.parameters.json (excerpt)
{
"vnetResourceId": { "value": "${AZURE_VNET_RESOURCE_ID=}" },
"privateEndpointSubnetName": { "value": "${AZURE_PE_SUBNET_NAME=snet-pe}" },
"disablePublicNetworkAccess": { "value": "${DISABLE_PUBLIC_NETWORK=true}" }
}
azd provisionする前に環境変数を設定します。
azd env set AZURE_VNET_RESOURCE_ID \
/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>
azd env set AZURE_PE_SUBNET_NAME snet-pe
azd env set DISABLE_PUBLIC_NETWORK true
各リソースをロックダウンする
テンプレートが作成するすべてのリソースについて、 publicNetworkAccess: 'Disabled' 設定し、プライベート エンドポイント モジュールを追加します。 次のパターンは例示です。 リソースの種類と DNS ゾーンを環境に合わせて調整します。
// infra/core/ai/account.bicep (excerpt)
resource aiAccount 'Microsoft.CognitiveServices/accounts@2024-10-01' = {
// ...existing properties...
properties: {
// ...existing properties...
publicNetworkAccess: disablePublicNetworkAccess ? 'Disabled' : 'Enabled'
networkAcls: {
defaultAction: disablePublicNetworkAccess ? 'Deny' : 'Allow'
}
}
}
アカウントを VNet に接続するプライベート エンドポイント モジュールを追加します。
module aiAccountPrivateEndpoint '../network/private-endpoint.bicep' = if (disablePublicNetworkAccess) {
name: 'pe-ai-account'
params: {
name: 'pe-${aiAccount.name}'
location: location
subnetId: '${vnetResourceId}/subnets/${privateEndpointSubnetName}'
privateLinkServiceId: aiAccount.id
groupId: 'account'
privateDnsZoneId: privateDnsZones.cognitiveServices
}
}
プライベートにするリソースに対して、このパターンを繰り返します。
- AI サービス アカウント: グループ ID
account。 DNS ゾーンには、データ プレーンに応じて、privatelink.cognitiveservices.azure.com、privatelink.openai.azure.com、およびprivatelink.services.ai.azure.comが含まれます。 - コンテナー レジストリ: グループ ID
registry。 DNS ゾーンprivatelink.azurecr.io。 リージョンごとにデータ エンドポイントを追加します。 - Application Insights: Azure Monitor Private Link スコープを使用します。 DNS ゾーンには、
privatelink.monitor.azure.com、privatelink.ods.opinsights.azure.com、privatelink.oms.opinsights.azure.com、privatelink.agentsvc.azure-automation.netが含まれます。 - ストレージ アカウント: 必要に応じて、グループ ID
blob、file、queue、およびtable。privatelink.blob.core.windows.netなど、サービスごとの DNS ゾーン。
エージェント拡張機能が基にして生成する azd-ai-starter-basic リポジトリは、既定で何が作成されるのかを知るための参考になります。 これらのモジュールを置き換えるのではなく、拡張します。
リソースをプロビジョニングする
azd provision
プロビジョニング後、リストに対するすべての依存関係は、そのプライベート エンドポイント経由でのみ到達できます。 パブリック DNS 解決では引き続きパブリック ホスト名が返されますが、プライベート DNS ゾーンは VNet 内でそれをオーバーライドします。
VNet 内から azd up を実行する
パブリック ネットワーク アクセスを無効にした後、パブリック インターネット ワークステーションから azd up または azd deploy を実行することはできません。 ARM コントロール プレーンに到達できますが、Foundry および ACR プッシュへのデータ プレーン呼び出しは、 403 エラーまたは接続拒否エラーで失敗します。 次のいずれかのパターンを使用します。
セルフホステッド GitHub Actions ランナー
ランナー VM または AKS でホストされるランナーを、同じ VNet のサブネットにプロビジョニングします。
runs-on: [self-hosted, agent-vnet]を使用して、ワークフローをそのランナーに向けます。 各 azd ai ステップではその後、プライベート DNS 名が正しく名前解決され、プライベート エンドポイント経由で処理されます。
jobs:
deploy:
runs-on: [self-hosted, agent-vnet]
steps:
- uses: actions/checkout@v4
- uses: Azure/setup-azd@v2
- run: azd ext install microsoft.foundry
- run: azd auth login --client-id ${{ secrets.AZURE_CLIENT_ID }} \
--federated-credential-provider github \
--tenant-id ${{ secrets.AZURE_TENANT_ID }}
- run: azd up --no-prompt
Azure DevOps のセルフホステッド エージェント
Azure DevOpsに同じパターンを使用します。 VNet サブネットにエージェントをインストールし、 pool: name: agent-vnet ディレクティブを使用してターゲットに設定します。
azd CLI と Foundry 拡張機能は変更されずに実行されます。
1 回限りの実行の Bastion またはジャンプ ホスト
手動インシデント対応やサイクル外デプロイなどのアドホック実行の場合は、Azure Bastion経由で VNet 内のジャンプ ホストに接続し、そこにazdと拡張機能をインストールして、そのホストからazdを実行します。 ジャンプ ホストを最小限に抑えておく。 長期的な答えは CI です。
プライベート Foundry エンドポイントに対してローカルに開発する
ローカル開発 (azd ai agent run と azd ai agent invoke) は、ループバックを介してローカル エージェント プロセスと、 invoke中のツール、モデル、セッションの Foundry データ プレーンと通信します。 Foundry エンドポイントが VNet 専用の場合は、開発用コンピューターからのネットワーク到達可能性が必要です。 オプションは次のとおりです。
- VNet の DNS スコープに入れるポイント対サイト VPN または常時接続 VPN。
- VNet 内の開発用 VM への Azure Bastion 接続 その VM で
azd ai agent runを実行し、Bastion トンネルを介してインスペクターのポート 8088 と 8087 を転送します。 - プライベート エンドポイントをホストするスポークへの ExpressRoute またはハブ VNet パスを持つ企業ネットワーク内のワークステーション。
FOUNDRY_PROJECT_ENDPOINTの解像度は変更されません。 値は、アクティブな azd 環境またはグローバル構成から引き続き取得されます。重要なのは、DNS がエンドポイントをパブリック IP ではなくプライベート IP に解決することです。
プライベート ACR と組み合わせる
Foundry エンドポイントと ACR の両方が同じ VNet 内のプライベート エンドポイント上にある場合は、次の操作を行います。
- VNet 内から
azd upを実行します。 - 既存のプライベート ACR を指す
AZURE_CONTAINER_REGISTRY_ENDPOINTとAZURE_CONTAINER_REGISTRY_RESOURCE_IDを設定すると、Bicepは新しいパブリック ACR の作成をスキップします。 - エージェント ID に、レジストリに対する AcrPull ロールが割り当てられていることを確認してください。
azd deployは、エージェント ID の作成後に自動的にこれを処理します。
レジストリ固有の詳細については、「プライベート Azure Container Registryを使用してホストされるエージェントをデプロイする」を参照してください。
ネットワークの問題を診断する
-
azd ai agent doctorは、Foundry データ プレーンに対してネットワーク到達可能性チェックを実行します。 VNet 内部からは、チェックは正常に通ります。 外から見ると、明らかに失敗している。--local-onlyを使用して、ネットワーク以外の問題をデバッグするときにリモート チェックをスキップします。 -
azd ai agent invoke --output raw "ping"は完全な HTTP 応答をダンプします。 ここでの接続拒否またはホストなしのエラーは、DNS またはルーティングの問題であり、認証の問題ではありません。 - ACR プッシュエラーの場合、原因がネットワークの問題ではなくロールが不足している場合、CLI は貼り付け対応の
az role assignment createコマンドを出力します。
既知の制限
- ファースト クラスの CLI フラグはありません。 すべての VNet 接続構成は、Bicep の手動カスタマイズに加え、ランナーの配置、DNS、RBAC に関する運用上の厳格な管理が必要です。
- エージェント エンドポイントは、このプレビューではパブリックなままです。 パブリック エンドポイントでのテナントの分離は、ネットワーク プライバシーではなく、 ユーザーごとにセッションを分離することによって行われます。
- リージョンの制約が適用されます。 ホストされるエージェントは、一連の固定リージョンで使用できます。 VNet、ACR、Foundry アカウントはすべて、これらのリージョンのいずれかに住んでいるか、ピアリングされている必要があります。 Foundry リソースとその仮想ネットワークの間の同じリージョンの要件については、 プライベート ネットワークのリージョンのサポートに関するページを参照してください。
azd ai agent doctorを実行して検証します。 - DNS は最も一般的な障害モードです。 問題が RBAC であると想定する前に、ランナーまたは開発 VM からの
nslookup <endpoint>など、プライベート DNS 解決をエンドツーエンドで確認します。