第6章 Microsoft Foundry のネットワーク構成を設計する
本章は初稿です。
本章のネットワーク構成と確認手順は公式資料を基にしています。Azure 上の疎通、遮断試験、SDK の実接続は、本教材では未検証です。
6.1 この章で学ぶこと
第5章で接続先と認証・権限を整理しました。次に確認するのは、その接続先へどこから、どの経路で届くかです。認証に成功しても、ネットワーク経路が使えるとは限りません。
本章の到達点は、開発端末から Foundry への通信と、ツールの実行元から接続先への通信を分けて通信台帳へ記録し、接続失敗時にどこを調べるか説明できることです。
私設ネットワークを実際に構築することは、後続の基礎実習の必須条件ではありません。組織が許可した接続方式を使い、既存環境の公開設定を無断で変更しません。受信、送信、DNS の基本を学び、BYO VNet や managed VNet の詳細は自分の環境に必要な場合に当てはめます。
6.2 図で受信と送信を分ける
最初に用語を整理します。VNet は Azure 内で使う仮想ネットワーク、サブネットはその中のアドレス範囲です。Private Endpoint はサービスへ私設経路で接続する入口であり、Foundry 全体を自分のサブネットへ移すものではありません。DNS はホスト名を接続先の IP アドレスへ対応付けます。
「Private Endpoint を作ったので閉域化できた」という判断は不十分です。社内 IT 支援では、利用者の要求が Foundry に届く経路と、エージェントから Search、Storage、チケット API へ届く経路を別々に設計します。公式資料も受信アクセスと送信アクセスを分けています。受信用 Private Endpoint だけを追加し、送信を公開経路のままにする構成もあります。[^network-options]
図6-1 Private Endpoint が受け持つ入口と、別に設計する送信経路。 上段の枠だけがクライアント VNet を表し、Foundry 自体を顧客のサブネットに配置した図ではありません。Foundry 側でツールを実行する場合の論理図として、要求方向のみを示しています。送信経路の箱は単一の Azure 製品を表さず、BYO／managed／公開送信と接続先の対応可否を個別に決める設計箇所です。アプリ側で function calling を実行する場合は、そのアプリを送信元として別の経路を設計します。
まず通信台帳を作り、送信元、宛先 FQDN、実行主体、経路、許可理由、失敗時の扱いを記録します。API をツールとして直接呼ぶ場合と、function calling の要求を自分のアプリで実行する場合では、通信の発生元が異なります。後者ではアプリからチケット API までの経路も自分で設計します。
| 通信 | 設計する境界 | 失敗時の影響 |
|---|---|---|
| 業務アプリから Foundry | 受信制限、Private Endpoint、認証 | 要求を受け付けられない |
| エージェントから Search | 送信経路と Search 側の受信制限 | 根拠を取得できない |
| 状態保存先への通信 | Storage、Cosmos DB などの経路と権限 | 状態の保存や再開ができない |
| 登録実行元から業務 API | 実行方式別の経路と承認検証 | 未登録または結果不明になる |
| CI・運用端末から各資源 | 管理操作とデータ操作の経路 | 配備成功でも試験・調査ができない |
ネットワークの到達性は利用者の文書閲覧権限を代替しません。閉域の Search に到達できても、検索 API で利用者別の認可が必要です。
6.3 DNS と接続元を確認する
受信用 Private Endpoint は作成だけでなく、接続の承認と名前解決まで確認します。公式手順では、クライアントは通常のエンドポイント名を使い、VNet 内ではそれが Private Endpoint のプライベート IP に解決される構成です。独自 DNS を使う場合は、適切な転送やレコード管理が必要になります。IP アドレスをアプリ設定へ直書きして回避しません。[^network-private]
社内端末が VPN や ExpressRoute で Azure に接続していても、オンプレミス DNS が必要な名前を解決できなければ到達できません。VNet との接続、DNS 転送先、Private DNS ゾーンと VNet の関連付け、戻り経路を一組で確認します。Foundry だけでなく、Search、Storage、Cosmos DB など、採用した資源ごとの名前を通信台帳に登録します。
図6-2 名前は通常の FQDN のまま、到達先をプライベート IP にする。 上から時系列で読みます。実線は問い合わせ・接続要求、破線は DNS 応答です。DNS から IP を得る処理と、その IP へ通常のホスト名で TLS／HTTP 接続する処理は別です。Private Link の内部を簡略化した概念図であり、HTTP 応答や DNS の転送段数は省略しています。
CI も独立した接続元です。管理プレーンで資源を作成できたことから、配備後の検索・登録試験まで実行できるとは限りません。必要なら接続済みの専用ランナーを使い、そのランナーの DNS、経路、実行 ID を試験対象に含めます。障害調査用の端末も同じです。運用経路がない状態で公開アクセスを止めると、障害時に公開へ戻す以外の手段を失います。
切替は、私設経路の許可試験、運用経路の確認、公開アクセスの無効化、禁止経路の遮断試験の順で進めます。Private Endpoint の存在だけをもって公開経路が遮断されたとはみなしません。
6.4 接続方式とツールの対応を確認する
6.4.1 公開、BYO、managed を要件で選ぶ
公式の選択肢には、公開送信、顧客管理の BYO VNet、Microsoft 管理の managed VNet があります。BYO は IP 計画、ピアリング、経路を自分たちで管理したい場合、managed はそれらの管理を減らしたい場合の候補です。いずれも、個別のツールや接続先まで無条件に閉域になるという意味ではありません。[^network-options]
| 選択肢 | 適用を考える条件 | 採用前の確認 |
|---|---|---|
| 公開送信＋受信制限 | 送信の公開経路を許容できる | 接続元制限、認証、外部送信先 |
| BYO VNet | 社内網接続や独自の経路制御が必要 | 専用サブネット、DNS、経路、運用担当 |
| Managed VNet | IP 計画の負担軽減や重複回避が必要 | 対象機能、接続承認、必要な私設宛先への対応 |
本教材の基本課題は検索と回答までです。発展付録のチケット登録を社内 API へつなぐ場合には、オンプレミス接続の候補として BYO VNet を評価します。Managed VNet が社内の任意の経路を自動的に継承するとは考えず、接続要件を満たすか確認できなければ採用を保留します。本章では managed 方式の具体的な配備手順までは検証していません。
BYO VNet と BYO データ資源も別の軸です。Standard setup には自分の Storage、Search、Cosmos DB が必要ですが、公式のネットワーク選択表には、プラットフォーム管理のデータ資源と BYO VNet を組み合わせる Basic の経路もあります。「VNet を使うなら必ず Standard」とは一般化できません。[^network-tools]
現行の手順では、BYO の専用サブネットに委任が必要で、Foundry と VNet のリージョン条件や作成時のネットワーク設定にも制約があります。後から送信注入を追加できる前提にせず、新規環境への移行を含めて計画します。[^network-private]
アドレス範囲と本番用サブネットサイズの推奨には、公式の概要・手順と深掘り記事で差があります。CGNAT の採用可否も、対象方式で照合するまでは判断しません。本章では未検証のサブネットサイズ、アドレス割当、API 設定値を構築例として提示せず、同時実行、更新時の余力、共有プロジェクト数を確認項目とします。[^network-options][^network-deep-dive]
6.4.2 送信経路は実行方式とツールごとに確認する
BYO の深掘り資料では、Prompt エージェントのツール通信はデータプロキシを経由し、Hosted エージェント 自身の送信とツール呼び出しにも経路の区別があります。開発端末から疎通しても、実行時の経路を証明したことにはなりません。[^network-deep-dive]
また、Foundry 外のツールを VNet 経由で呼ぶ現在の公式手順では、プロジェクトレベルの有効な capability host が必要とされています。アカウント側だけでは足りず、欠けると名前解決のような接続エラーになる場合があります。新しい capability settings を使う構築経路と、従来の capability host 経路を混ぜず、選択した公式手順の前提を一式で確認してください。[^network-private][^network-tools]
Search、Storage、Cosmos DB を持ち込む場合、それぞれの Private Endpoint、承認、DNS、データ操作権限を確認します。Foundry を作れば依存先の Private Endpoint も自動作成されるとは限りません。Search の検索経路と、文書を取り込む索引更新経路も別です。インデクサーが Private Endpoint を通る構成では、公式資料にある Private 実行環境の要件を確認します。対応しない取り込み方式もあるため、検索だけ成功して空の索引が残る事態を防ぎます。[^network-private]
チケット API が外部 SaaS なら、完全な私設経路を選べないこともあります。許可する宛先と送信データを限定し、承認したチケット本文以外の文書断片を送らない設計にします。認証、監視、イメージ取得などの基盤依存も台帳に含め、必要な通信を一括遮断しません。
閉域化で使えなくなる機能も採用前に確認します。現行のツール一覧では、Web 検索など公開エンドポイントを使う機能、Microsoft バックボーンを使う機能、非対応の機能が区別されています。Code Interpreter は対応していても通信は Microsoft バックボーン経由であり、自分の Private Endpoint を通るとは限りません。private ACR の利用可否にはプロジェクト作成時期の条件があります。現行 Responses API 向けの対応表を classic へ適用せず、workflow の受信対応から送信注入まで対応済みと推定しないことも重要です。[^network-private]
6.5 接続失敗と遮断を区別する
基本課題では、VPN の手順を検索して根拠を取得する経路を確認します。発展付録のチケット登録へ進む場合は、本人の承認後の登録と、登録結果が不明になった場合の照合を追加で試します。いずれも正常系だけでなく、禁止した経路から届かないことを確認します。試験用文書と、発展課題では試験用 API を使い、遮断の影響は検証環境に限定します。以下の登録に関する行は、基本課題の卒業条件ではありません。
| 試験 | 期待する結果 | 取得する証拠 |
|---|---|---|
| 接続済み端末・CI からのアクセス | 正しい宛先へ到達 | DNS 結果、接続結果、要求 ID |
| 許可しない外部接続元 | Foundry の利用を拒否 | 接続元と拒否記録 |
| Search 経路の遮断 | 根拠取得不能として案内 | 検索エラー、タスク状態 |
| 許可しない送信先 | 接続を拒否 | Firewall 等の拒否記録 |
| 登録応答だけが途絶 | 成功と断定せず照合 | 操作 ID、登録先の照会結果 |
調査は、発生元、FQDN、DNS 応答、TCP/TLS、HTTP、認証・認可、業務状態の順に進めます。DNS 失敗や TCP タイムアウトなら、ゾーン、転送、NSG、経路、Firewall を調べます。端末で成功して実行環境だけ失敗する場合は、その実行元からの経路と capability の前提へ戻ります。
403 はネットワーク障害とも権限不足とも即断しません。応答したサービス、要求 ID、ネットワーク制限の診断情報、トークンの対象、呼び出し主体、データ権限を確認します。ネットワーク制限も HTTP の拒否になるため、ロールを広げるだけでは直りません。逆に名前解決の問題に権限変更を重ねても、原因を隠すだけです。
経路が復旧しても、応答を失った登録は再実行前に照合します。利用者には「登録結果を確認中」と伝え、登録 ID が確認できてから完了へ移します。
本章で確認したのは公式資料です。Azure 上の疎通、遮断試験、SDK 実行は未検証であり、上表は実施計画です。GA／preview、リージョン、方式別制約は実装前に再確認します。
6.6 小さな実習：通信台帳を作る
学習用エージェントの通信台帳を作ります。最初は次の二行で構いません。各行に送信元、宛先のホスト名、公開・私設の経路、呼び出し主体、許可理由、失敗時の挙動を書き、通信しない処理はその旨を記録してください。
| 通信 | 記録する内容の手掛かり |
|---|---|
| 開発端末 → Foundry | 第5章で確認した接続先のホスト名、端末からの経路と呼び出し主体 |
| 検索関数の実行元 → 検索先 | 検索 API を呼ぶ場合の実行元と宛先。ローカル資料だけなら「通信なし」と記録する |
第10章の検索関数はローカル資料だけを使い、検索先への通信は発生しません。後でその関数から検索 API を呼ぶなら、送信元は Foundry ではなく、自分のアプリケーションになります。
実環境で確かめる場合は、許可された学習環境だけを対象にし、管理者と試験範囲を合意します。読解だけで進む場合は、どの証拠があれば到達・遮断を判断できるかを台帳へ記入してください。
6.7 確認課題
「端末から接続できた」「認証できた」「実行時に検索できた」は、それぞれ別の確認です。通信台帳と図を参照しながら、次の問いに答えてください。
| 問い | 理解のポイント |
|---|---|
| 受信用 Private Endpoint があれば、検索先への送信も閉じるか | 受信と送信は別に確認する |
| SDK の認証に成功したのにタイムアウトするのはなぜか | 認証とは別に DNS、経路、宛先の到達性を確認する |
| 私設接続だから文書の閲覧認可は不要か | ネットワーク到達性は利用者の閲覧権限を代替しない |
| 端末から検索できれば、サービス実行時も検索できるか | 実行元が違えば DNS、経路、ID も確認し直す |
6.8 まとめ
ネットワークは、受信の入口、実行元からの送信、DNS を分けて考えます。通信台帳で接続元と宛先を対応付け、到達性と認証・権限を別々に確認してください。
閉域化する場合は運用経路も含め、Private Endpoint の数ではなく、必要な経路が通り、禁止した経路が遮断され、失敗後も業務状態を照合できることを完了条件にします。次章では、この接続の前提を確認したうえで、最小のエージェントを作って会話します。
6.9 参考情報
- Networking options for Foundry Agent Service — 受信と送信を分けて構成を選ぶ入口
- How to configure network isolation for Microsoft Foundry — Private Endpoint、DNS、対応機能の確認手順
[^network-options]: Networking options for Foundry Agent Service — Microsoft
[^network-tools]: Network isolation for a toolbox in Microsoft Foundry — Microsoft
[^network-private]: How to configure network isolation for Microsoft Foundry — Microsoft
[^network-deep-dive]: Deep dive into Foundry Agent Service networking — Microsoft