Microsoft Foundry Agent Service、ホスト型AIエージェントの外部通信先を制限するネットワーク制御機能をプレビュー公開

要点

• Microsoftは「Foundry Agent Service」において、ホスト型AIエージェントのアウトバウンド通信先を制限・監査できるネットワークエグレス制御の仕組みを公開した。
• 送信先ルールをエージェントのコード内から切り離し、アカウントレベルの責任あるAI（RAI）ポリシーとして独立して管理できる。
• 接続先をFQDN単位で明示的に許可し、未承認の宛先への接続をデフォルトで拒否する構成が可能となっている。
• Python SDKを通じてエージェントに適用可能で、現在は開発および評価を目的としたプレビュー段階で提供されている。

概要

Microsoftは2026年9月24日、同社の公式ブログ「Microsoft Foundry Blog」にて、ホスト型AIエージェント（クラウド上で実行される自律型AIプログラム）の外部通信先を制御する機能「Network egress controls」の技術解説を公開した。AIエージェントが意図しない外部サーバーへリクエストを送信するリスクを防ぐため、プラットフォーム層で明示的な通信境界を設定できるようにする仕組みだという。本機能は現在、開発および評価を目的としたプレビュー段階に位置づけられており、一般提供（GA）やSLA（サービス品質保証）の対象外であることが明記されている。

アプリケーションコードから分離された通信境界の設計

従来のAIエージェント開発では、エージェントに付与するツール一覧や個別のHTTPラッパー内で通信先を制限する手法が用いられてきた。しかし元記事では、請求書処理エージェントが財務APIとベンダーAPIを利用する例を挙げ、処理対象の文書に未知のアップロードリンクが含まれる場合や、導入したライブラリが想定外の通信を行うリスクを指摘している。特定のHTTPラッパー内のみにルールを設けても、そのラッパーを経由しない通信は防げないため、「どのツールを与えたか」だけでなく「プロセス自体がどこへリクエストを送信できるか」を制御する必要があるという。

今回の仕組みでは、通信先の判定をエージェントのアプリケーションコードから切り離し、ホスト型エージェントの実行基盤側で定義する。これにより、アプリケーションがビジネスロジックや認証を保持したまま、外部送信（エグレス：ネットワーク内部から外部へのアウトバウンド通信）ポリシーを個別にレビューおよび管理できるようになると説明している。

ポリシー定義の構造とAzure CLIによる登録

ネットワークエグレス制御のルールは、Azure Resource Manager（ARM：Azureのリソース管理基盤）のRAI（Responsible AI：責任あるAI）ポリシーリソースとしてJSON形式で定義される。

元記事で示された構成例では、コンテンツセーフティ設定（properties.mode）を Blocking とする一方、エグレス設定（properties.egressPolicy.mode）に通信ログを記録する Audit モードを指定している。未承認の通信は defaultAction の Deny によってデフォルトで遮断され、rules 配列内に許可する接続先をFQDN（完全修飾ドメイン名：ホスト名とドメイン名を完全に指定した表記）で記述する。広範なワイルドカードではなく完全一致でホスト名を指定することが推奨されている。

定義したJSONファイルは、Azure CLIの az rest コマンドを用いてARM API（APIバージョン 2026-05-15-preview）へ送信し、アカウントレベルで登録する。ルールは先頭から順に評価され、最初に一致した条件のアクションが適用される仕組みだという。なお、Foundryプラットフォームの動作に必要なシステム通信は個別に許可されており、デフォルト拒否の設定によってプラットフォーム全体の全接続が遮断されるわけではないと説明されている。

Python SDKによる適用と検証手順

作成されたエグレスポリシーは、Python SDKを用いてホスト型エージェントに関連付けられる。元記事によると、適用環境には azure-ai-projects（バージョン2.2.0以上）および azure-identity が必要となる。

エージェントへの紐付けにはSDKの RaiConfig クラスを使用し、ポリシーの完全なARMリソースIDを指定して実行する。対象エージェントは、Responsesプロトコルを実装したコンテナであることが前提とされる。

運用前の確認手順として、Azure CLIのGETリクエストで登録内容を照合した上で、許可された通信と意図的に遮断される通信の双方をテストすることが推奨されている。また、既存の混在ポリシーを直接変更せず、検証用の新規リソースを作成してテストを行うよう注意を促している。公式GitHubリポジトリ（foundry-samples）では、本機能のサンプルコード（18-egress-control）が提供されている。