Azure AI Foundryの「Create a Foundry resource – Foundry Tools」で押さえるべき結論は、Foundry resourceが生成AIモデル、エージェント、モデルデプロイ、評価、プロジェクトを管理する中核リソースとして扱われるという点です。従来の「Foundry Tools」という呼び方はFoundry resourceへ整理され、管理者はRBAC、ネットワーク、課金、監視、プロジェクト作成権限をリソース単位で見直す必要があります。新規構築では kind に AIServices を指定し、プロジェクト作成、モデルデプロイ、チーム権限付与までを一連のセットアップとして確認するのが実務上のポイントです。(Microsoft Learn)
この記事では、2026年5月16日時点で確認すべきAzure AI Foundry関連の公式情報をもとに、「何が変わるのか」「誰に影響するのか」「管理者・開発者がどの設定を確認すべきか」を実務目線で整理します。特に、旧ロール名が残る環境、CLIやIaCでの自動展開、Private Endpointを使う企業環境では、作成手順だけでなく権限・ネットワーク・命名・リージョンの設計まで確認してから展開してください。
Azure AI FoundryのCreate a Foundry resourceで何が変わるのか
「Create a Foundry resource – Foundry Tools」は、単にAzureポータルでリソースを1つ作る手順ではありません。Foundry resourceを、AIアプリケーション開発の入口となるAzureリソースとして定義し、その下でプロジェクト、モデルデプロイ、エージェント、評価、接続などを扱う構成に整理しています。
特に重要なのは、次の5点です。
| 確認項目 | 変更・整理されたポイント | 実務への影響 |
|---|---|---|
| リソースの位置づけ | Foundry resourceは生成AIモデルやエージェントを構築・デプロイ・管理する主要なAzureリソース | Azure AI Foundry環境の管理単位を、プロジェクト単位だけでなくFoundry resource単位で考える必要がある |
| 名称 | Foundry resourceは、以前の「Foundry Tools」の次バージョンおよび名称変更として説明されている | ドキュメント、画面、スクリプト、社内手順書で新旧名称が混在しやすい |
| API kind | AzureポータルではFoundry > Foundry配下に表示され、API kindは AIServices | CLI、PowerShell、Bicepでリソース種別を誤ると想定したFoundry resourceにならない |
| プロジェクト管理 | Foundry resourceの下に複数のプロジェクトを作成して作業を整理する | チーム、業務ドメイン、PoC、本番などの分け方を事前に設計する必要がある |
| 権限管理 | Foundry系RBACロールの名称が変更され、旧称が一部に残る可能性がある | ロール名ではなくロール定義IDを使うと、自動化や移行時の失敗を避けやすい |
Foundry resourceは、アクセス制御、ネットワーク、課金、監視などのスコープを定義するAzureリソースです。複数のユースケースをまとめ、同じ業務領域やデータ領域を扱う開発チームで共有する前提が示されています。(Microsoft Learn)
Foundry resourceは「旧Foundry Toolsのリソース名変更」だけではない
今回のポイントを「名前が変わっただけ」と捉えると、設定漏れが起きやすくなります。Foundry resourceは、エージェント、モデルデプロイ、評価などをホストするアプリケーション環境として扱われます。つまり、作成後すぐにモデルを呼び出すだけでなく、プロジェクト作成、モデルデプロイ、チームメンバーのアクセス権付与まで含めて運用設計する必要があります。(Microsoft Learn)
たとえば、社内の生成AI基盤を作る場合は、次のように分けて考えると失敗しにくくなります。
| 設計対象 | 具体例 | 判断基準 |
|---|---|---|
| Foundry resource | foundry-sales-prod、foundry-rd-dev | 課金、監視、ネットワーク、権限境界をどこで分けるか |
| Project | 営業FAQ、契約書レビュー、社内ナレッジ検索 | チームやアプリケーション単位でアクセス制御したいか |
| Model deployment | gpt-4.1-mini などのデプロイ名 | アプリ側が参照する名前なので、環境ごとに命名ルールを統一する |
| RBAC | Foundry User、Foundry Ownerなど | 最小権限で開発・管理できるか |
| Network | Public access、Selected networks、Private Endpoint | 企業データや閉域要件を満たす必要があるか |
PoCでは1つのFoundry resourceに複数プロジェクトをまとめても問題ないことがあります。一方、本番運用では、データ分類、コスト配賦、監査ログ、ネットワーク制限の単位に合わせてFoundry resourceを分けた方が管理しやすくなります。
新規作成で確認すべき基本設定
Foundry resourceの作成では、Azureポータル、Azure CLI、PowerShell、Bicepを使えます。基本的な確認項目は、サブスクリプション、リソースグループ、リージョン、リソース名、SKU、API kindです。
特にCLIで作成する場合は、--kind AIServices を指定する点が重要です。公式手順でも、Foundry Toolsには複数のリソース種類があるため、Foundry resourceを作成する場合は AIServices を使うよう明示されています。(Microsoft Learn)
az group create \
--name my-foundry-rg \
--location eastus
az cognitiveservices account create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--kind AIServices \
--sku s0 \
--location eastus \
--allow-project-management--allow-project-management は、このリソース内でプロジェクト作成を可能にするためのフラグです。CLIでプロジェクト作成まで自動化する場合、Foundry resourceの作成だけで終わらせず、カスタムサブドメイン、プロジェクト作成、プロジェクト確認まで含めて手順化してください。(Microsoft Learn)
az cognitiveservices account update \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--custom-domain my-foundry-resource
az cognitiveservices account project create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--project-name my-foundry-project \
--location eastus
az cognitiveservices account project show \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--project-name my-foundry-projectカスタムサブドメインはグローバルで一意である必要があります。社名や部署名だけの短い名前は取得済みになりやすいため、環境名、リージョン、用途を含めた命名規則を先に決めておくと展開時の手戻りを減らせます。
管理者が最初に確認すべき権限とRBAC
Foundry resourceを作成するには、サブスクリプションまたはリソースグループに対して、Owner、Contributor、または Microsoft.CognitiveServices/accounts/write を含むカスタムロールが必要です。作成できない場合は、Microsoft.CognitiveServicesのリソースプロバイダー登録や /register/action 権限が不足している可能性があります。(Microsoft Learn)
ただし、作成権限と開発権限は分けて考える必要があります。チームメンバーにAIアプリケーションの構築・テストをさせる場合は、最小権限としてFoundry Userロールを割り当てる構成が基本です。公式RBAC情報では、キー認証はロール制限を受けずフルアクセスになり得るため、より細かな制御にはMicrosoft Entra ID認証が推奨されています。(Microsoft Learn)
RBACロール名の変更に注意する
FoundryのRBACロールは名称変更が進んでおり、旧称が一部の画面やドキュメントに残る可能性があります。公式情報では、ロールIDと基本的な権限は変更されていないため、自動化スクリプトではロール名ではなくGUIDを使うのが安全です。(Microsoft Learn)
| 新しいロール名 | 以前の名称 | 主な用途 | ロール定義ID |
|---|---|---|---|
| Foundry User | Azure AI User | プロジェクトでの開発・テストに必要な最小権限 | 53ca6127-db72-4b80-b1b0-d745d6d5456d |
| Foundry Owner | Azure AI Owner | プロジェクトとリソースの管理、開発、公開まで広く扱う高権限ロール | c883944f-8b7b-4483-af10-35834be79c4a |
| Foundry Account Owner | Azure AI Account Owner | Foundryアカウントやプロジェクト管理、他ユーザーへの一部ロール付与 | e47c6f54-e4a2-4754-9501-8e0985b135e1 |
| Foundry Project Manager | Azure AI Project Manager | プロジェクト管理と開発、Foundry Userロールの条件付き割り当て | eadc314b-1a2d-4efa-be10-5d325db5065e |
個別ユーザーに直接ロールを付けるより、Microsoft Entraセキュリティグループに割り当てる方が運用は安定します。人事異動やプロジェクト参加者の変更があっても、Azure側のロール割り当てを毎回変更せずに済むためです。
PROJECT_ID=$(az cognitiveservices account project show \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--project-name my-foundry-project \
--query id -o tsv)
az role assignment create \
--role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
--assignee-object-id "<security-group-object-id>" \
--assignee-principal-type Group \
--scope $PROJECT_ID開発者が確認すべき接続情報とモデルデプロイ
開発者がすぐ作業できる状態にするには、Foundry resourceを作るだけでは不十分です。プロジェクト、モデルデプロイ、プロジェクトエンドポイント、デプロイ名、RBACの割り当てまで揃っている必要があります。
公式クイックスタートでは、モデルをデプロイした後に provisioningState が Succeeded になっていることを確認し、プロジェクトエンドポイントとデプロイ名をチームに共有する流れが示されています。アプリケーションから接続する際は、このエンドポイントとデプロイ名を環境変数やシークレット管理に保存し、コードに直書きしないようにしてください。(Microsoft Learn)
az cognitiveservices account deployment create \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--deployment-name gpt-4.1-mini \
--model-name gpt-4.1-mini \
--model-version "2025-04-14" \
--model-format OpenAI \
--sku-capacity 10 \
--sku-name Standard
az cognitiveservices account deployment show \
--name my-foundry-resource \
--resource-group my-foundry-rg \
--deployment-name gpt-4.1-miniモデル名やバージョンはリージョンや時期によって利用可否が変わる可能性があります。公式手順のサンプルをそのまま本番テンプレートに固定するのではなく、利用するリージョンで選択可能なモデル、SKU、クォータを確認してから展開してください。
リージョンとクォータは早めに確認する
Foundry resourceでは、リージョン選択が待機時間や利用できる機能に影響します。公式ドキュメントでも、一部のFoundry Toolsはリージョンによって可用性が異なる可能性があると説明されています。(Microsoft Learn)
実務では、次の観点でリージョンを決めると判断しやすくなります。
| 判断軸 | 確認すること | 失敗しやすい例 |
|---|---|---|
| 利用モデル | 使いたいモデルがそのリージョンでデプロイ可能か | PoCで使ったモデルが本番リージョンでは選べない |
| データ所在地 | 社内規程や顧客契約で利用可能なリージョンか | 海外リージョンを選んでコンプライアンス確認が後回しになる |
| レイテンシ | 利用者や接続先システムに近いか | アプリは日本利用なのに遠いリージョンへ固定する |
| ネットワーク | Private EndpointやVNet設計と整合するか | 既存VNetと異なるリージョンでPrivate Endpoint設計が複雑になる |
| クォータ | 必要なスループットやデプロイ数を満たせるか | デモ直前にクォータ不足でモデルを増やせない |
クォータは、CLIで az cognitiveservices account list-usage を使って確認できます。PoCから本番へ移す前に、利用量、モデルデプロイ数、想定トークン量、同時アクセス数を見積もっておきましょう。(Microsoft Learn)
ネットワーク分離を使う場合の注意点
企業利用では、Public accessのまま使えるケースよりも、Private Endpoint、Selected networks、VNet、VPN、ExpressRouteなどを組み合わせるケースが多くなります。Foundryのネットワーク分離では、主に次の3つを考える必要があります。
| 領域 | 内容 | 確認ポイント |
|---|---|---|
| Inbound | 利用者や開発環境からFoundry resourceへ接続する経路 | Public network accessを無効化するか、選択したIPだけ許可するか |
| Outbound | FoundryからAzure Storage、Azure AI Search、Cosmos DBなどへアクセスする経路 | Private LinkやVNet injectionが必要か |
| Agent client | エージェントが外部ツールやデータソースへ接続する経路 | ツールごとのPrivate対応、Public endpoint利用可否を確認する |
Private Endpointを使う場合、DNS解決が正しく構成されているかが重要です。仮想ネットワーク内からFoundryのエンドポイントを解決したときに、Private EndpointのプライベートIPへ向く必要があります。DNSが誤っていると、権限設定が正しくても接続できない、またはPublic endpointへ解決されるといった問題が起きます。(Microsoft Learn)
また、Agent Serviceでエンドツーエンドのネットワーク分離を行う場合、Storage、Azure AI Search、Azure Cosmos DBなどのBYOリソースが必要になる場面があります。仮想ネットワーク注入を使う構成では、Public network accessを無効化し、必要なPrivate Endpointを個別に作成する必要があります。(Microsoft Learn)
特に注意したいのは、アウトバウンドネットワーク設定です。公式情報では、既存のFoundryデプロイに後からアウトバウンドの仮想ネットワーク注入を追加することはできず、追加するには再デプロイが必要とされています。閉域要件がある本番環境では、PoC後に「やはりPrivateにする」と判断すると作り直しになる可能性があります。(Microsoft Learn)
BicepやIaCで展開する場合の確認ポイント
本番環境や複数環境へ展開する場合は、Azureポータルで手作業するより、BicepなどのIaCで構成を管理した方が再現性が高くなります。公式ドキュメントでは、Bicepテンプレートを使ってFoundry resourceとプロジェクトを展開でき、既存リソースからBicepをエクスポートする方法も示されています。(Microsoft Learn)
ただし、エクスポートしたBicepをそのまま本番テンプレートに使うのは避けてください。エクスポート結果には、サブスクリプションID、リソースグループ名、リソースIDなどの固定値が含まれることがあります。さらに、一部のリソースタイプでは完全にエクスポートされず、警告が出る場合もあります。(Microsoft Learn)
IaC化する際は、少なくとも次の項目をパラメーター化しましょう。
| パラメーター化すべき項目 | 理由 |
|---|---|
| Foundry resource名 | dev、stg、prodで重複を避けるため |
| リージョン | モデル可用性、データ所在地、ネットワーク設計に合わせるため |
| SKU | PoCと本番で必要な容量や課金条件が異なるため |
| プロジェクト名 | チームや業務単位で管理しやすくするため |
| RBAC割り当て先 | 個人ではなくEntraグループへ切り替えやすくするため |
| Public network access | 環境ごとにPublic、Selected networks、Privateを切り替えるため |
| Private Endpoint関連 | VNet、Subnet、Private DNS Zoneを環境別に管理するため |
| タグ | コスト配賦、所有部署、環境区分、監査に使うため |
IaCのゴールは「作れること」ではなく、「同じ設定を安全に再現できること」です。特にFoundry resourceは、モデル、エージェント、プロジェクト、接続、ネットワーク、権限が絡むため、作成後の手作業が多いほど本番差分が増えます。
既存環境・移行時に確認すべきこと
既存のAzure AI Foundry、Azure AI Services、Foundry Tools関連の運用がある場合は、いきなり新しい手順に置き換えるのではなく、まず棚卸しを行ってください。今回の公式情報は、既存リソースを即時停止する内容ではありませんが、名称、RBAC、API kind、プロジェクト管理、ネットワーク設計の見直しが必要になる可能性があります。
確認すべき項目は次のとおりです。
| 確認対象 | 見るべきポイント | 対応例 |
|---|---|---|
| 既存リソース | AIServices として作成されているか、用途が分かる名前か | 不明なリソースはタグと所有者を追加する |
| スクリプト | ロール名やリソース名を旧称で固定していないか | FoundryロールはGUID指定へ変更する |
| RBAC | 個人ユーザーへ直接割り当てていないか | Entraセキュリティグループへ置き換える |
| プロジェクト | 業務、環境、データ境界が混在していないか | 本番用、検証用、部門別に分ける |
| ネットワーク | Public accessのまま本番利用していないか | Private EndpointやSelected networksを検討する |
| 接続情報 | エンドポイントやデプロイ名をコードに直書きしていないか | Key Vaultや環境変数に移す |
| ドキュメント | Azure AI Userなど旧称が残っていないか | 新旧名称の対応表を追記する |
RBACロールについては、日本語UIや翻訳ドキュメントの一部で旧称が残る可能性があります。英語版の最新情報では、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerへの名称変更と、ロールID・基本権限は変更されていないことが示されています。運用手順書では「旧称が表示される場合がある」と明記しておくと、問い合わせを減らせます。(Microsoft Learn)
よくある失敗と対処法
Foundry resourceの作成・展開で起きやすいトラブルは、手順ミスよりも「前提設計の不足」が原因になることが多いです。
| よくある失敗 | 主な原因 | 対処法 |
|---|---|---|
| Foundry resourceを作成できない | 権限不足、リソースプロバイダー未登録 | Ownerまたは管理者に登録を依頼し、Microsoft.CognitiveServices/accounts/write 権限を確認する |
| CLIで作ったがプロジェクトを作れない | --allow-project-management を付けていない、または手順が不足 | Foundry resource作成、カスタムサブドメイン、プロジェクト作成を一連のCLIで確認する |
| ロール割り当てスクリプトが失敗する | 旧ロール名・新ロール名の混在 | ロール名ではなくロール定義IDを使う |
| チームメンバーがプロジェクトを開けない | スコープ違い、テナント違い、グループID誤り | プロジェクトスコープのRBAC、Entraテナント、セキュリティグループのメンバーを確認する |
| モデルを呼び出せない | デプロイ未完了、デプロイ名の誤り、リージョン差異 | provisioningState、デプロイ名、モデル可用性を確認する |
| Private Endpoint環境で接続できない | DNSがPublic endpointへ解決されている | VNet内から nslookup を実行し、Private IPへ解決されるか確認する |
| ネットワーク分離を後から入れられない | アウトバウンドVNet injectionを既存環境へ追加できない | 本番前に閉域要件を確定し、必要なら再デプロイ計画を立てる |
| リソース削除で他の環境も消える | リソースグループ単位で削除した | PoC専用リソースグループを使い、本番共有リソースと分ける |
不要になった検証環境は、課金を避けるために削除が必要です。ただし、リソースグループを削除すると、その中の関連リソースも削除されます。PoCでは専用リソースグループを作り、本番や共有リソースと混在させない構成にしておくと安全です。(Microsoft Learn)
管理者・開発者別のチェックリスト
最後に、実際にAzure AI FoundryのFoundry resourceを作成・展開する前に確認すべき項目を、役割別に整理します。
管理者向けチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| サブスクリプション | 利用可能なAzureサブスクリプションか |
| リソースプロバイダー | Microsoft.CognitiveServicesが登録済みか |
| 作成権限 | Owner、Contributor、または必要なカスタムロールがあるか |
| リージョン | モデル、ツール、ネットワーク、データ所在地の要件に合うか |
| 命名規則 | Foundry resource、Project、Deploymentの命名が環境別に整理されているか |
| タグ | 部署、用途、環境、コストセンター、所有者を付与しているか |
| RBAC | Foundry UserなどをEntraグループで割り当てているか |
| ネットワーク | Public access、Selected networks、Private Endpointの方針を決めているか |
| IaC | BicepやCLIで再現可能な展開手順になっているか |
| 監査・削除 | 不要リソースの削除手順と影響範囲を把握しているか |
開発者向けチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| プロジェクトアクセス | 自分または所属グループにFoundry User相当の権限があるか |
| プロジェクトエンドポイント | アプリから接続するエンドポイントを取得しているか |
| デプロイ名 | モデル名ではなく、実際のデプロイ名を参照しているか |
| 認証方式 | Microsoft Entra ID認証を使える構成か |
| 環境変数 | エンドポイント、デプロイ名、テナント情報をコードに直書きしていないか |
| リージョン差分 | dev、stg、prodでモデル可用性が同じか |
| ネットワーク | 開発端末やCI/CD環境からPrivate Endpointへ到達できるか |
| エラー確認 | 403はRBAC、タイムアウトはDNSやネットワークの可能性があると切り分けられるか |
まず何から始めるべきか
これからAzure AI FoundryでFoundry resourceを作成するなら、最初にやるべきことは「リソース作成」ではなく、管理単位の設計です。誰が管理するのか、どのチームが開発するのか、Public accessでよいのか、どのリージョンを使うのか、どのモデルをデプロイするのかを決めてから作成してください。
最小構成で試すなら、専用リソースグループを作成し、kind AIServices でFoundry resourceを作成し、プロジェクト、モデルデプロイ、Foundry Userの割り当て、プロジェクトエンドポイントの共有までを一度通します。本番展開に進む場合は、RBACをEntraセキュリティグループへ寄せ、BicepやCLIで再現可能にし、ネットワーク分離の要否を先に確定させることが重要です。
「Create a Foundry resource – Foundry Tools」は、単なるクイックスタートではなく、Azure AI Foundryの運用境界をどこに置くかを考えるための出発点です。既存環境がある場合は、旧名称、ロール名、スクリプト、ネットワーク、リソースグループ構成を棚卸しし、新規環境ではFoundry resourceを中心に、プロジェクト、権限、モデル、接続、監視を一体で設計しましょう。
コメント