microsoft-foundry

Microsoft Foundry スキル

このスキルは、モデルの検索とデプロイ、AI エージェントの開発ライフサイクル全体、評価ワークフロー、トラブルシューティングなど、Microsoft Foundry リソースを扱う開発者を支援します。

実行前の要件

対応するアクションまたはワークフローを開始する前に、該当する以下の各サブセクションに従ってください。

依存関係の確認とセットアップ

必須： このスキルの読み込み後、最初の手順として、このスキルのルートから以下の依存関係の確認とセットアップのスクリプトを実行し、完了するまで待ってから続行してください。このスクリプトは最初に確認を行い、不足している依存関係のみをインストールします。すでに利用可能な依存関係は再インストールしません。

サブスキル、ワークフロー、またはワークフロー固有のリファレンスを読む前、あるいはそれらに進む前に、必ずこの確認を完了してください。

./scripts/check-and-setup-dependencies.sh     # macOS / Linux
./scripts/check-and-setup-dependencies.ps1    # Windows (pwsh)

以降の手順では、スクリプトの出力に厳密に従ってください。

ワークフローのガイダンス

必須： ワークフロー固有の手順を実行する前に、対応するサブスキルのドキュメントを必ず読んでください。サブスキルのドキュメントを読まずに、そのワークフローのワークフロー固有の MCP ツールを呼び出さないでください。MCP ツールのパラメーターをすでに知っている場合も同様です。スキルのドキュメントには、従う必要のあるワークフローの手順、事前確認、検証ロジックが記載されています。このルールは、スキルがすでに読み込まれている場合でも、異なるワークフローを開始する新しいユーザーメッセージごとに適用されます。

Foundry MCP

必須： Foundry MCP 操作を使用する前に、Azure MCP の foundry ツールを呼び出し、利用可能な Foundry MCP ツールと関連パラメーターを確認してください。これは、MCP ベースのワークフローにおける検出／ヘルプの手順として扱ってください。

azd

必須： azd コマンドを実行する前に、必ず azd-guidance を読み、特に AZURE_DEV_USER_AGENT の設定ルールをはじめ、そこに定義された共通ルールに厳密に従ってください。

サブスキル

このスキルには、特定のワークフロー向けの専門的なサブスキルが含まれています。タスクに該当するサブスキルがある場合は、そのワークフローに厳密に従ってください。

サブスキル	使用する場面	リファレンス
deploy	ホステッドエージェントを Foundry にデプロイし、デプロイをスモークテストし、プロンプトエージェントを作成または更新し、エージェントのバージョンや複数環境へのデプロイを管理します。	deploy
cicd	Foundry エージェントの CI/CD デプロイパイプラインを設定します。	cicd
invoke	エージェントにメッセージを送信し、単一ターンまたは複数ターンの会話を行います	invoke
routine	ルーチンを使って Foundry エージェントをスケジュール実行またはイベントトリガーで実行します。azd を使った CRUD、有効化／無効化、手動ディスパッチ、過去の実行の表示や、azure.yaml でのルーチンの定義に対応します。	routine
invocations-ws	invocations_ws 双方向 WebSocket プロトコルに対応したホステッドエージェント（音声エージェント、リアルタイムストリーム、帯域外メディアトランスポート向けシグナリング）を構築、デプロイし、接続します。	invocations-ws
observe	エージェントの品質を評価し、バッチ評価を実行し、失敗を分析し、プロンプトを最適化し、エージェントの指示を改善し、バージョンを比較し、CI/CD モニタリングを設定し、継続的な本番環境評価を有効にします	observe
insights	既存のモニターから生成済みのエージェントに関する分析情報、根拠、推奨事項を取得します。読み取り専用の取得であり、新たな分析の実行ではありません	insights
trace	トレースをクエリし、レイテンシや失敗を分析し、App Insights の customEvents を通じて評価結果を特定の応答に関連付けます	trace
troubleshoot	ホステッドエージェントのログを表示し、テレメトリをクエリして、失敗を診断します	troubleshoot
validate	ユーザーがこの検証サブスキルの使用、または Microsoft Foundry のホステッドエージェントコードのベストプラクティスに照らした検証を明示的に依頼した場合にのみ使用します。自発的に呼び出したり、別のワークフローに追加したりしないでください。	validate
create (quick start)	ホステッド Foundry エージェントを一からエンドツーエンドで新規作成します。スキャフォールドの作成、Foundry プロジェクトのプロビジョニングまたは既存プロジェクトの使用、デプロイ、スモークテストを行います。既存コードに関する作業には使用しないでください。クイックスタートで対応できない作業には create を使用します。	create/quick-start-hosted.md
create	標準的なエンドツーエンドのハッピーパス（クイックスタート）が適さない場合に使用します。Foundry エージェントの新規作成、既存エージェントのコード更新や開発の継続、スキャフォールド作成時の接続の設定、高度なセットアップや A2A（Agent2Agent）の使用、またはクイックスタート実行の失敗からの復旧に対応します。	create
create managed harness	Foundry 管理の GitHub Copilot ハーネスを明示的に使用する Prompt Agent の作成または開発の継続に使用します。通常の Prompt Agent MCP ワークフローではなく、azd と azure.yaml を使用します。	create-managed-harness
agent-optimizer	既存の Python ホステッドエージェントコードを最適化に対応させ、eval.yaml を設定し、Agent Optimizer ジョブを実行し、候補をローカルに適用して、レビュー後に azd でデプロイします。	agent-optimizer
eval-datasets	本番環境のトレースから評価データセットを作成し、データセットのバージョンと分割を管理し、評価メトリクスの経時変化を追跡し、リグレッションを検出し、トレースからデプロイまでの完全なリネージを維持します。次の用途に使用します：トレースからのデータセット作成、データセットのバージョン管理、評価の経時的な傾向分析、リグレッション検出、データセット比較、評価リネージ。	eval-datasets
project/create	エージェントやモデルをホストするための Microsoft Foundry プロジェクトを新規作成します。Foundry の利用開始時や、新しいインフラストラクチャのセットアップ時に使用します。	project/create/create-foundry-project.md
resource/create	Azure CLI を使用して Azure AI Services マルチサービスリソース（Foundry リソース）を作成します。AI Services リソースをきめ細かく制御して手動でプロビジョニングする場合に使用します。	resource/create/create-foundry-resource.md
private-network	Foundry のネットワーク分離に関する質問への回答、および VNet 分離（BYO VNet、Managed VNet、ハイブリッド）を使用した Foundry のデプロイに使用します。アーキテクチャの概念、テンプレートの選択、デプロイ、デプロイ後の検証を扱います。	resource/private-network/private-network.md
models/deploy-model	インテリジェントなルーティングを使用した、統合モデルデプロイに対応します。クイックプリセットデプロイ、完全カスタマイズしたデプロイ（バージョン／SKU／容量／RAI）、リージョン間の容量確認を処理します。次のサブスキルにルーティングします：preset（クイックデプロイ）、customize（完全な制御）、capacity（利用可能な容量の確認）。	models/deploy-model/SKILL.md
quota	Microsoft Foundry リソースのクォータと容量を管理します。クォータ使用量の確認、クォータ不足によるデプロイ失敗のトラブルシューティング、クォータ増加の申請、容量計画に使用します。	quota/quota.md
rbac	Microsoft Foundry リソースの RBAC 権限、ロール割り当て、マネージド ID、サービスプリンシパルを管理します。アクセス制御、権限の監査、CI/CD のセットアップに使用します。	rbac/rbac.md
finetuning	Microsoft Foundry でモデルをファインチューニングします。SFT 蒸留、DPO 選好最適化、採点器とツール呼び出しを使用する RFT に対応します。データセットの準備、採点器の調整、トレーニング、チェックポイントの選択、デプロイ、評価を行います。次の用途に使用します：ファインチューニング、SFT、DPO、RFT、トレーニングデータ、採点器、蒸留、ファインチューニング済みモデル、大容量ファイルのアップロード。	finetuning/SKILL.md
azd-guidance	Foundry エージェントの管理に関する、共通の azd 知識とガイダンスを提供します。azd に関連するワークフローでは、まずこちらをお読みください。	azd-guidance

💡 ヒント： オンボーディングの流れ全体を実行するには、project/create（パブリック）または private-network（VNet 分離）→ models/deploy-model → エージェントのワークフロー（create → deploy → invoke）を使用します。

💡 ファインチューニング： モデルのカスタマイズにはすべて finetuning を使用します。SFT 蒸留、DPO による選好最適化、採点器を使用した RFT に対応しています。クイックスタート、採点器のキャリブレーション、学習曲線の分析も含まれています。

💡 モデルのデプロイ： あらゆるデプロイシナリオで models/deploy-model を使用します。クイックプリセットデプロイ、完全に制御可能なカスタムデプロイ、リージョン間の容量確認をインテリジェントに振り分けます。

💡 プロンプトの最適化： 「プロンプトを最適化して」や「エージェントの指示を改善して」といったリクエストには、observe を読み込み、評価駆動型のワークフローを通じて prompt_optimize MCP ツールを使用します。

インフラストラクチャのライフサイクル

ユーザーの意図に合ったインフラストラクチャのワークフローを選択します。

ユーザーの意図	ワークフロー
「Foundry を作成」／「Foundry をセットアップ」（意図が曖昧）	AskUserQuestion を使用して、（a）AI Services リソースのみ、（b）パブリックアクセスのプロジェクト、（c）ネットワーク分離されたプロジェクトのいずれかを確認します。振り分け先：（a）→ resource/create、（b）→ project/create、（c）→ private-network
VNet 分離で Foundry をセットアップ	private-network
Foundry プロジェクトを作成（パブリック）	project/create
Foundry リソースのみを作成	resource/create

エージェント開発ライフサイクル

ユーザーの意図に合ったエージェントのワークフローを選択してください。実行する前に、各サブスキルを順番に読んでください。

ユーザーの意図	ワークフロー（順番に読む）
明示的に依頼された Managed Harness Agent / GitHub Copilot harness agent を作成または開発する	依存関係の確認とセットアップ → azd-guidance → create-managed-harness → deploy → invoke
新しいホステッドエージェントを最初から最後まで作成する（スキャフォールド作成＋デプロイ＋テスト）	依存関係の確認とセットアップ → azd-guidance → quick-start-hosted（エンドツーエンドで完結）
標準のクイックスタート以外の作業（既存コード、移行、再ホスト、デプロイのカスタマイズ、スキャフォールド作成時の接続、A2A（Agent2Agent）、復旧）	依存関係の確認とセットアップ → azd-guidance → create → deploy → invoke
既存の Python ホステッドエージェントを最適化する	依存関係の確認とセットアップ → azd-guidance → agent-optimizer → スキャフォールド作成／レビュー → eval.yaml → 最適化 → 候補を適用 → デプロイ → 呼び出し
エージェントをデプロイする（コードはすでに存在する）	依存関係の確認とセットアップ → azd-guidance → デプロイ（eval-suite のセットアップを含む） → 呼び出し → 観察（評価／最適化）
コード変更後にエージェントを更新／再デプロイする	依存関係の確認とセットアップ → azd-guidance → デプロイ（eval-suite のセットアップを含む） → 呼び出し → 観察（評価／最適化）
ホステッドエージェント用の CI/CD デプロイパイプラインをセットアップする	依存関係の確認とセットアップ → azd-guidance → cicd
エージェントを呼び出す／テストする／チャットする	依存関係の確認とセットアップ → azd-guidance → invoke
エージェントをスケジュール／イベントでトリガーする、または routine の CRUD／有効化／無効化／ディスパッチを行う	依存関係の確認とセットアップ → azd-guidance → routine
エージェントのプロンプトまたは指示を最適化／改善する	observe（ステップ 4：最適化）
エージェントを評価して最適化する（全体のループ）	observe
継続的な評価モニタリングを有効にする	observe（ステップ 6：CI/CD とモニタリング）
エージェントのインサイトを取得する／生成された問題と推奨事項を一覧表示する	依存関係の確認とセットアップ → insights（証拠を展開した全ページ。読み取り専用）
エージェントの問題をトラブルシューティングする	依存関係の確認とセットアップ → azd-guidance → invoke → troubleshoot
破損したエージェントを修正する（トラブルシューティング＋再デプロイ）	依存関係の確認とセットアップ → azd-guidance → invoke → troubleshoot → 修正を適用 → deploy → invoke

エージェント：.foundry ワークスペース標準

各エージェントのソースフォルダーでは、Foundry 固有のキャッシュとオーバーレイ状態を .foundry/ に保持できます。

<agent-root>/
  .foundry/
    agent-metadata.yaml
    agent-metadata.prod.yaml
    suites/
    datasets/
    evaluators/
    results/

• azd プロジェクトでは、azure.yaml と azd env get-values からデプロイコンテキスト（プロジェクトエンドポイント、エージェント名／バージョン、ACR、App Insights）を導出します。azd から取得できる値をメタデータに重複して記載しないでください。
• agent-metadata.yaml は、azd 以外の値、リモート Foundry スイートへの参照、ローカルキャッシュパス、結果の概要、明示的なオーバーライドを記述するための、ローカル／開発用オーバーレイとして推奨されます。agent-metadata.prod.yaml などの任意のサイドカーファイルには、複数の環境を1つのファイルに混在させず、単一の本番環境または CI 対象のオーバーレイを格納できます。
• suites/、datasets/、evaluators/ はローカルキャッシュフォルダーです。最新の状態であれば再利用し、更新または上書きする前に確認してください。
• 正規のスキーマとワークフロールールについては、Agent Metadata Contract を参照してください。

エージェント：セットアップの参照資料

• Standard Agent Setup — データ所在地を管理する必要がある本番ワークロード向けの高度なセットアップです（Foundry 機能ホストを介して、独自の Cosmos DB／Storage／AI Search を使用）。デフォルトの azd ai agent フローでは Basic Agent Setup が使用され、capabilityHosts/agents はプロビジョニングされません。そのため、これがないことをバグとして指摘しないでください。デフォルトのプロビジョニング後の状態については、foundry-agent/create/create-hosted.md の「Expected env-var fingerprint」セクションを参照してください。

エージェント：共通のプロジェクトコンテキスト解決

エージェントスキルでは、まだ把握していない構成値が必要な場合に限りこの手順を実行します。エージェントのルート、環境、プロジェクトエンドポイント、エージェント名などの値を、ユーザーのメッセージまたは同じセッション内の以前のスキルですでに把握している場合は、その値の解決を省略してください。

ステップ 1：エージェントのルートと azd コンテキストを特定する

まず、ワークスペースに host: azure.ai.agent を使用するサービスを含む azure.yaml があるか確認します。

• azd エージェントサービスが1つ -> kind と harness からそのサービスを分類し、そのサービスの project フォルダーまたは azure.yaml があるディレクトリをエージェントのルートとして使用します。
• azd エージェントサービスが複数 -> ユーザーに対象のサービス／フォルダーを選択してもらいます。
• azd エージェントサービスがない -> ワークスペース内で、agent-metadata.yaml または agent-metadata.<env>.yaml を含む .foundry/ フォルダーを検索します。
  • 一致が1件 -> そのエージェントルートを使用します。
  • 一致が複数 -> ユーザーに対象のエージェントフォルダーを選択してもらいます。
  • 一致なし -> insights の場合は、ローカルファイルを初期化せず、不足しているリモート入力のみを確認します。作成／デプロイのワークフローでは、セットアップ時に新しい .foundry/ フォルダーを作成します。それ以外のワークフローでは処理を停止し、初期化するエージェントのソースフォルダーをユーザーに確認します。

エージェントのルートを選択したら、ローカルの .foundry キャッシュの確認、ソースの確認、評価者の提案、データセットの提案、プロンプト最適化のコンテキストは、すべてそのフォルダー内だけで扱います。ユーザーが明示的にルートを切り替えない限り、隣接するエージェントフォルダーをスキャンしないでください。

ステップ 2：環境とデプロイコンテキストの解決

azure.yaml が存在する場合は、まず azd 環境を解決します。

1. ユーザーが明示的に指定した環境
2. azd env get-values の AZURE_ENV_NAME
3. .azure/config.json の azd デフォルト環境
4. セッション中にすでに選択された環境

プロジェクトまたはデプロイの値がまだ判明していない場合は、選択した環境に対して azd env get-values を実行します。デプロイコンテキストには azd の値を優先して使用します。

azd 変数	解決される値
AZURE_AI_PROJECT_ENDPOINT または AZURE_AIPROJECT_ENDPOINT	プロジェクトのエンドポイント
AGENT_<SERVICE>_NAME	選択した azd サービスのエージェント名
AGENT_<SERVICE>_VERSION	選択した azd サービスのエージェントバージョン
AZURE_CONTAINER_REGISTRY_NAME または AZURE_CONTAINER_REGISTRY_ENDPOINT	ACR レジストリ名／イメージ URL のプレフィックス
APPLICATIONINSIGHTS_CONNECTION_STRING	トレースのワークフローに使用する App Insights 接続文字列
AZURE_SUBSCRIPTION_ID、AZURE_RESOURCE_GROUP、AZURE_AI_ACCOUNT_NAME、AZURE_AI_PROJECT_NAME	Azure リソースの検索と Playground のリンク

azd がこれらの値を提供する場合は、それを信頼できる唯一の情報源として使用し、メタデータを書き込む際に .foundry/agent-metadata*.yaml へコピーしないでください。

ステップ 3：メタデータのオーバーレイを選択し、環境を解決

選択したエージェントルート内で、次の順にメタデータファイルを選択します。

1. ユーザーまたはワークフローが明示的に指定したメタデータのファイル名またはパス
2. 環境が明示的に判明しており、.foundry/agent-metadata.<env>.yaml が存在する場合は、そのファイル
3. .foundry/agent-metadata.yaml
4. 複数のメタデータファイルが残り、上記のルールで選択できない場合は、ユーザーに選択を求めます

選択したメタデータファイルを読み取り、残りの環境選択を次の順に解決します。

1. ユーザーが明示的に指定した環境
2. 選択したメタデータファイルに環境が 1 つだけ定義されている場合は、その環境
3. セッション中にすでに選択された環境
4. メタデータの defaultEnvironment

選択したメタデータファイルに複数の環境が残り、上記のルールで選択できない場合は、ユーザーに選択を求めます。すべてのワークフローの要約で、選択したエージェントルート、メタデータファイル、環境、およびコンテキストが azd とメタデータのどちらに由来するかを明示してください。

選択した環境のメタデータに、evaluationSuites[] ではなく古い testSuites[] がある場合は、このセッションでは testSuites[] を情報源として扱い、続行する前に各エントリをメモリ内で evaluationSuites[] の形式に正規化します。メタデータがさらに古く、レガシーの testCases[] のみがある場合は、そのリストも同じ方法で正規化します。データセットと評価器のフィールドは保持し、既存の tags はそのまま残します。また、tags.tier が存在しない場合に限り、レガシーの priority を tags.tier に割り当てます。P0 -> smoke、P1 -> regression、P2 -> coverage。

ステップ 4：eval.yaml のローカル評価の意図を解決

選択したエージェントルートに eval.yaml が存在する場合は、新しいスイートを生成する前に解析します。

• agent.name -> 対象エージェントの候補。使用前に、選択した azd／メタデータのエージェントと一致することを確認します。
• dataset.local_uri -> ローカルのシードデータセット候補。レガシーの dataset_file はメモリ内で正規化できます。
• dataset.name / dataset.version -> 登録済みデータセット候補。
• validation_dataset -> 任意の検証データセット候補。
• evaluators[] -> Foundry 評価器名の候補。リモート評価器として扱う前に、evaluator_catalog_get で確認します。
• name -> ローカル評価／スイートの候補。suiteName として保存する前に、リモートで確認します。
• options.eval_model、options.optimization_model、options.max_candidates、options.optimization_config.model_search_space、options.pass_threshold、max_samples、trace_days、generation_instruction -> セットアップのデフォルト値。

eval.yaml はローカル評価の意図として扱い、Foundry スイートが存在する証拠とはみなしません。同期されたスイート／データセット／評価器の参照は、リモートでの検索または登録が成功した後にのみ .foundry に保存します。

Step 5: 共通設定を解決する

次の順序でソースを適用します。

1. 明示的なユーザー入力と、セッションですでに選択されている値
2. デプロイコンテキスト用の azd 環境値
3. .foundry/agent-metadata*.yaml のオーバーレイ値とリモートスイート／キャッシュ参照
4. azure.yaml と eval.yaml のローカルソース設定
5. まだ不足している情報についてのユーザーへの確認

azd とメタデータの両方に同じ値があり、それぞれ異なる場合は、どちらのソースを優先するか確認するために処理を中断します。一致する場合は azd の値を使用し、今後メタデータを書き込む際に重複して書き込まないようにします。

有効な値	優先するソース	使用箇所
プロジェクトエンドポイント	azd env	デプロイ、呼び出し、監視、トレース、トラブルシューティング
エージェント名／バージョン	azd エージェント変数、次に azure.yaml	呼び出し、監視、トレース、トラブルシューティング
ACR	azd env	デプロイ
評価スイートとキャッシュパス	.foundry/agent-metadata*.yaml	監視、eval-datasets
ローカルのシードデータセット／評価器の意図	eval.yaml	監視、eval-datasets

Step 6: メタデータオーバーレイを書き込む（作成／デプロイ／監視のみ）

メタデータを書き込む際（デプロイ、自動セットアップ、データセットの更新、またはトレースからデータセットへの更新）は、選択したメタデータファイルに、他の情報から導出できないオーバーレイ／キャッシュ状態のみを保存します。

• 将来の解決に役立つ場合は、azd バインディング（azd.environmentName、azd.service）
• リモートのスイート／データセット／評価器参照とローカルキャッシュパスを含む evaluationSuites[]
• lastEval、結果ファイル、比較の概要、または azd 以外による明示的なオーバーライド

azd がデプロイ値をすでに提供している場合は、azd が管理するデプロイ値をメタデータにコピーしないでください。選択したファイルが単一環境向けの優先ファイルの場合は、その環境ブロックのみを書き換えます。選択したファイルがレガシーの複数環境ファイルの場合は、選択した環境ブロックのみを書き換えます。兄弟メタデータファイル間で環境を自動的にコピーまたはマージしないでください。選択した環境で古い testSuites[] またはレガシーの testCases[] を使用している場合は、evaluationSuites[] に書き換え、書き換えたエントリから移行済みの priority フィールドを削除します。

Step 7: 不足している値を収集する

ユーザーメッセージ、セッションコンテキスト、メタデータ、または azd のブートストラップから解決できなかった値に限り、ask_user または askQuestions ツールを使用します。スキルで必要になることが多い値は次のとおりです。

• エージェントルート — 対象となる azd サービスプロジェクトフォルダー、または .foundry/agent-metadata*.yaml を含むフォルダー
• メタデータファイル — ローカル／開発用の agent-metadata.yaml、または agent-metadata.prod.yaml などの明示的なサイドカーファイル
• 環境 — azd 環境、dev、prod、またはメタデータの別の環境キー
• プロジェクトエンドポイント — Microsoft Foundry プロジェクトのエンドポイント URL
• エージェント名 — 対象エージェントの名前

💡 ヒント： ユーザーがエージェントのパス、環境、プロジェクトエンドポイント、またはエージェント名をすでに指定している場合は、その値を直接抽出してください。再度尋ねないでください。

エージェント：エージェントの種類

エージェントのワークフローでは、次の3つの開発パスを区別します。

種類	Kind	説明
プロンプト	"prompt"	モデルデプロイを基盤とする LLM ベースのエージェント
ホステッド	"hosted"	カスタムコードを実行するコンテナベースのエージェント
マネージドハーネスエージェント	harness.type: "github_copilot_preview" を指定した "prompt"	Foundry 管理の GitHub Copilot ハーネスで実行されるプロンプトエージェント。このスキルでは開発とデプロイに azd を使用します

host だけでなく、定義に基づいて azure.yaml のサービスを分類します。

• kind: hosted -> ホステッド。
• kind: prompt と harness.type: github_copilot_preview の組み合わせ -> マネージドハーネスエージェント。
• kind: prompt で、そのハーネスが指定されていない場合 -> 通常のプロンプトエージェント。

プロジェクトコンテキストから種類を解決できない場合に限り、agent_get を使用します。既存のエージェントをプロンプト、ホステッド、マネージドハーネスエージェント間で変換しないでください。代わりに新しいエージェントを作成します。

ツールの使用規則

• ユーザーから情報を収集する場合は、ask_user または askQuestions ツールを使用します
• 時間のかかるサブタスクや独立したサブタスク（環境変数のスキャン、ステータスのポーリング、Dockerfile の生成など）を委任する場合は、task または runSubagent ツールを使用します
• Hosted Agents と Managed Harness Agents には azd を、通常の Prompt Agents には Foundry MCP を優先して使用します
• CLI コマンドの構文を埋め込む代わりに、Microsoft の公式ドキュメント URL を参照します

Azure の認証

• Azure 認証のベストプラクティス

その他のリソース

• Foundry Hosted Agents
• Foundry Agent Runtime Components

ネットワーク分離エラー

Foundry プロジェクトまたはその親 Foundry アカウントに対するすべての呼び出しに適用されます。Foundry MCP ツール、azd、az CLI、curl、REST、SDK が対象です。

エラーが Public access is disabled／PublicNetworkAccessDisabled／プライベートエンドポイントからの 403 Forbidden／接続タイムアウト／プロジェクトのエンドポイント FQDN がパブリック IP に解決される場合、通常は親 Foundry アカウントで publicNetworkAccess=Disabled または Enabled from selected IP addresses が設定されており、現在のシェルがその VNet の外部にあることを意味します。

エラーの内容が不明確な場合に限り、管理プレーンの呼び出しで Foundry アカウントを確認します（リーダーアクセスがあればどこからでも実行できます）。

az cognitiveservices account show \
  --name <account> --resource-group <rg> \
  --query "properties.{publicNetworkAccess:publicNetworkAccess, networkAcls:networkAcls, privateEndpointConnections:privateEndpointConnections[].properties.privateLinkServiceConnectionState.status}"

publicNetworkAccess: "Disabled"、または networkAcls.ipRules／virtualNetworkRules が空でない状態での "Enabled" は、ネットワーク分離が設定されていることを示します。publicNetworkAccess: "Enabled" で networkAcls が空の場合、失敗の原因は呼び出し元側のネットワークの問題です（たとえば、プライベートエンドポイントを使用する VNet 内から FQDN をパブリック IP に解決する Private DNS など）。アカウント設定の問題ではありません。

ネットワーク分離が原因である場合、サポートされている接続方法については、Foundry へのセキュアな接続方法の選択を参照してください。

ℹ️ Foundry MCP ツールは、VNet 内からでも VNet で分離されたプロジェクトに到達できません。