Azure AI Foundryでエージェント、評価、ファイル管理、モデル検証を始める前に最初に確認すべきことは、「プロジェクトを作る方法」だけではありません。どのFoundryリソース配下に作るのか、誰にどのRBACロールを付与するのか、既存のAzure Policyやコストタグに合う作成方法を選ぶのかが重要です。
結論として、個人検証や小規模PoCならFoundryポータルから作成して問題ありません。一方、本番環境や複数チームでAzure AI Foundryを使う場合は、Azure CLI、Bicep、Azure portalを使い、リソースグループ、リージョン、権限、ネットワーク、タグを標準化してから作成するべきです。Microsoft Learnの「Create a project – Microsoft Foundry」は、Foundryプロジェクトを作成し、エージェントや評価、ファイルを扱う前に環境の準備状況を確認するための公式手順として整理されています。なお、該当ページの最終更新表示は2026年5月15日であり、日本時間では2026年5月16日前後に確認される更新情報として扱われる場合があります。(Microsoft Learn)
Create a project – Microsoft Foundryで押さえるべき結論
Azure AI Foundryの現在の公式ドキュメントでは、サービス名やポータル表記として「Microsoft Foundry」が使われています。公式の概念整理では、以前のAzure AI Studio／Azure AI FoundryはMicrosoft Foundryへ、Hub＋Azure OpenAI＋Azure AI Servicesという構成は、単一のFoundryリソースと配下のプロジェクトというリソースモデルへ整理されています。(Microsoft Learn)
実務上のポイントは、Foundryプロジェクトを「単なる作業フォルダー」と見なさないことです。プロジェクトは、エージェント、評価、ファイル、データセット、トレースなどを扱う作業単位であり、Foundryリソース配下のAzure子リソースとして権限管理や運用管理の対象になります。複数チームで使う場合は、プロジェクトごとにアクセス制御を分けつつ、親のFoundryリソース側でネットワーク、デプロイ、接続済みツールなどを共有する設計が可能です。(Microsoft Learn)
| 対象者 | 影響範囲 | 最初に確認すべきこと |
|---|---|---|
| 管理者・情シス | RBAC、Azure Policy、リソースグループ、コスト管理 | Foundry OwnerやOwnerなど、作成・ロール割り当てに必要な権限を持っているか |
| 開発者 | プロジェクトエンドポイント、SDK、認証方式 | New Foundryが有効か、Microsoft Entra ID認証で接続できるか |
| DevOps・基盤担当 | Azure CLI、Bicep、命名規則、リージョン | AIServicesリソース、--allow-project-management、カスタムドメインを標準化しているか |
| 移行担当 | classicポータル、旧SDK、旧ロール名 | FoundryプロジェクトとclassicのHubベースプロジェクトを混同していないか |
何が変わるのか：作成手順よりも「設計単位」の見直しが重要
今回の公式情報で重要なのは、ボタンを押してプロジェクトを作る手順そのものよりも、Azure AI Foundryの利用単位が「Foundryリソース」と「プロジェクト」の組み合わせで整理されている点です。
Foundryポータルで新規プロジェクトを作成すると、プロジェクトはFoundryリソース上に作成されます。ポータルでは必要に応じてFoundryリソースも自動作成されますが、組織で独自の命名規則、セキュリティ制御、コストタグ、Azure Policyを使っている場合は、ポータルの簡易作成だけで済ませず、Azure portalやテンプレートによる作成を検討する必要があります。(Microsoft Learn)
特に本番環境では、次のような変更・確認ポイントが実務に影響します。
| 確認ポイント | 実務上の意味 | 推奨対応 |
|---|---|---|
| New Foundryの利用 | 手順は新しいFoundryポータルを前提にしている | ポータル右上やバナーの切り替えでNew Foundryが有効か確認する |
| Foundryリソース配下のプロジェクト | プロジェクト単位で作業を整理し、親リソースの設定を共有する | チーム、環境、機密度ごとにプロジェクト分割を決める |
| RBACロール名の変更 | 旧Azure AI系ロール名が残る画面やスクリプトが混在する可能性がある | スクリプトではロール名ではなくロール定義IDの利用を検討する |
| 複数プロジェクト対応 | 同じFoundryリソース上に複数プロジェクトを追加できる | 共有デプロイや接続を使う範囲を事前に決める |
| デフォルトプロジェクト | 一部機能はデフォルトプロジェクトでの扱いが強い | デフォルトプロジェクトを安易に削除しない |
プロジェクト作成前に決めるべき設定
Azure AI Foundryのプロジェクト作成では、画面の入力項目よりも、事前設計のほうが重要です。特に、あとから変更しにくい項目や、組織ポリシーに関わる項目は作成前に決めておきます。
リソースグループとリージョン
検証用であれば、新しいリソースグループを作成して、その中にFoundryリソースとプロジェクトをまとめると管理しやすくなります。公式手順でも、最初に試す場合はプロジェクト用の新しいリソースグループを作ると、関連リソースをまとめて管理しやすいとされています。(Microsoft Learn)
本番環境では、リージョン選定も重要です。利用したいモデル、社内のデータ所在地ルール、ネットワーク制約、監査要件を確認してからリージョンを決めます。サンプルではEast USが使われていますが、日本企業の本番運用では、社内ルールや利用可能な機能を確認したうえで適切なリージョンを選ぶべきです。
命名規則とカスタムドメイン
Azure CLIでFoundryリソースを作成する場合、--allow-project-managementでプロジェクト作成を有効にし、さらにカスタムサブドメインを設定します。カスタムドメイン名はグローバルで一意である必要があるため、単純な名前では取得済みになりやすい点に注意してください。(Microsoft Learn)
実務では、次のような命名規則にすると運用しやすくなります。
| 用途 | 命名例 | 判断基準 |
|---|---|---|
| 検証環境 | fdry-dev-app01 | 個人名ではなく用途で分かる名前にする |
| ステージング | fdry-stg-salesai | 本番に近い権限・接続で検証できるようにする |
| 本番 | fdry-prd-corpai | コスト管理、監査、ネットワーク制御と合わせる |
| プロジェクト名 | agent-eval-sales | チーム名、機能名、評価対象が分かるようにする |
認証方式
プロジェクトのホーム画面では、プロジェクトエンドポイントとAPIキーを確認できます。ただし、Microsoft Entra ID認証を使う場合、APIキーは不要です。キー管理の負担を減らし、監査性を高めたい場合は、アプリケーションや開発者の認証方式をEntra ID中心に設計するのが現実的です。(Microsoft Learn)
Foundryポータルでプロジェクトを作成する手順
個人検証や初期PoCでは、Foundryポータルから作成するのが最も簡単です。手順は次の流れです。
- Microsoft Foundryポータルにサインインする。
- New Foundryの切り替えが有効になっていることを確認する。
- 画面左上の現在のプロジェクト名を選択する。
- 「Create new project」を選ぶ。
- プロジェクト名を入力し、「Create project」を選択する。
- 詳細設定を使う場合は、既存のリソースグループまたは新しいリソースグループ、リージョンを選択する。
- 作成完了後、プロジェクトエンドポイント、権限、利用できるモデルやツールを確認する。
ポータル作成の利点は、SDKやCLIの準備なしで始められることです。一方で、Azure Policy、タグ、ネットワーク分離、顧客管理キー、厳密な命名規則が必要な組織では、ポータルのデフォルト設定だけでは統制が不十分になる場合があります。そうした環境では、Azure portalやBicepによるテンプレート化を優先しましょう。(Microsoft Learn)
Azure CLIで作成する場合の実務手順
複数環境へ同じ構成を展開したい場合や、手順をチームで再現したい場合はAzure CLIが向いています。公式手順では、リソースグループ作成、Foundryリソース作成、カスタムドメイン設定、プロジェクト作成、作成確認という流れが示されています。(Microsoft Learn)
az login
az account set --subscription "{subscription-name}"
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
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この例ではeastusを使っていますが、実運用では自社の利用リージョンに置き換えてください。CLI化する場合は、サブスクリプションID、リソースグループ名、Foundryリソース名、プロジェクト名、リージョンを変数化し、開発・検証・本番で同じスクリプトを使い回せる形にしておくと運用ミスを減らせます。
Python SDKで作成する場合の注意点
Python SDKでプロジェクト作成を自動化する場合は、azure-identityとazure-mgmt-cognitiveservicesを利用します。公式手順では、azure-mgmt-cognitiveservicesは13.7以上を確認する流れが示されており、管理クライアントではapi_version="2025-04-01-preview"が使われています。複数テナントを扱う環境では、DefaultAzureCredentialに対象のMicrosoft Entra IDテナントを指定することも検討します。(Microsoft Learn)
開発者がつまずきやすいのは、認証が通っているつもりでも、別テナントや別サブスクリプションに向いているケースです。作成前にaz account showやSDK側の簡易認証テストで、対象サブスクリプションとテナントが正しいか確認してください。
また、Python SDKはプロジェクト作成には使えますが、チームメンバーへのロール割り当て操作はサポートされていないと公式手順に記載されています。アクセス権の付与はFoundryポータル、Azure portal、Azure CLIで行う運用に分けましょう。(Microsoft Learn)
Bicepで展開するべきケース
本番環境、監査対象システム、複数部署への横展開では、BicepによるInfrastructure as Code化が有効です。公式のBicepクイックスタートでは、Foundryリソースとプロジェクトをテンプレートでまとめてデプロイでき、既存のFoundryリソース設定をBicepとしてエクスポートして再利用する方法も案内されています。(Microsoft Learn)
Bicepを使うべき代表的なケースは次のとおりです。
| ケース | Bicepを使う理由 |
|---|---|
| 本番・検証・開発を同じ構成で作りたい | 環境差分をパラメーターで管理できる |
| ネットワーク分離や顧客管理キーが必要 | セキュリティ設定をテンプレートに含められる |
| Azure Policyやタグを強制したい | 組織標準の設定漏れを防ぎやすい |
| 既存構成を複製したい | Azure portalからエクスポートしたBicepを出発点にできる |
ただし、エクスポートしたBicepにはサブスクリプションID、リソースグループ名、リソースIDなどの固定値が含まれる場合があります。再利用前にパラメーター化し、不要な参照や外部リソースへの依存を取り除く必要があります。公式情報でも、エクスポート結果に不足や警告が出る可能性があるため、出力内容を確認して必要なプロパティを補うことが推奨されています。(Microsoft Learn)
管理者が確認すべきRBAC設定
Azure AI Foundryのプロジェクト作成で最もトラブルになりやすいのがRBACです。自分用に作成する場合は、Foundryリソースを作成できるロールが必要です。チーム用に作成する場合は、プロジェクト作成だけでなく、ユーザーやMicrosoft Entraセキュリティグループへロールを割り当てられる権限も必要になります。(Microsoft Learn)
公式情報では、Foundry関連のRBACロール名が最近変更されたことが明記されています。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerという名称でした。ロールIDと中核的な権限は変わらないため、スクリプトではロール名よりロール定義IDを使うと、名称変更の反映中でもトラブルを避けやすくなります。(Microsoft Learn)
| 現在のロール名 | 旧ロール名 | 主な用途 | ロール定義ID |
|---|---|---|---|
| Foundry User | Azure AI User | 開発者がプロジェクトを使ってAIアプリを構築・検証する最小権限 | 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 |
チームメンバーには、原則としてFoundry Userを付与します。複数人に付与する場合は、個別メールアドレスではなくMicrosoft Entraセキュリティグループを使うと、入退社や異動時の運用が楽になります。アクセスできない場合は、ロール割り当てが完了しているか、メールアドレスやグループIDが正しいか、ユーザーが同じMicrosoft Entraテナントに属しているかを確認します。(Microsoft Learn)
複数プロジェクトとデフォルトプロジェクトの注意点
同じFoundryリソース上に複数のFoundryプロジェクトを作成すると、チームごとに作業領域を分けながら、親リソース側のセキュリティ、デプロイ、接続済みツールなどを共有できます。これは、開発者にはセルフサービスの検証環境を与えつつ、管理者は制御済みのAzure環境を維持したい場合に有効です。(Microsoft Learn)
ただし、すべての機能が追加プロジェクトで同じように使えるわけではありません。公式情報では、最初の「default」プロジェクトのほうが強力であると説明されています。
| 機能 | デフォルトプロジェクト | 追加プロジェクト | 運用上の注意 |
|---|---|---|---|
| Model inference | 対応 | 対応 | 通常の推論用途はどちらでも使える |
| Playgrounds | 対応 | 対応 | 検証用途では追加プロジェクトでも利用しやすい |
| Agents | 対応 | 対応 | チーム別エージェント開発に使える |
| Evaluations / Tracing / Datasets / Indexes | 対応 | 対応 | 評価・監視単位をプロジェクトで分けやすい |
| OpenAI SDK and API | 対応 | Responses、Files、Conversationsに対応 | 追加プロジェクトでは対応範囲を確認する |
| OpenAI Batch、Fine-tuning、Stored completions | 対応 | 非対応 | 使う予定がある場合はデフォルトプロジェクトを意識する |
| Speech fine-tuning | 対応 | 非対応 | 音声系の調整を行う場合は特に注意する |
デフォルトプロジェクトを削除すると、次に作成されたプロジェクトがデフォルトになります。機能差や運用ルールが変わる可能性があるため、削除は検証環境でも慎重に扱うべきです。(Microsoft Learn)
classic環境から移行する場合の確認ポイント
Foundry classicポータルやHubベースのプロジェクトを使っている組織では、「新しいプロジェクト作成手順」と「既存環境の移行」を分けて考える必要があります。公式の移行情報では、classicのAzure OpenAI＋Hub構成が、現在は単一のFoundryリソースと子プロジェクトという構成に整理されていること、エンドポイント管理も単一のプロジェクトエンドポイントとOpenAI v1エンドポイントへ簡素化されていることが示されています。(Microsoft Learn)
移行時は、次の順番で棚卸しすると失敗しにくくなります。
- classicポータルで使っているHub、プロジェクト、Azure OpenAIリソースを一覧化する。
- 利用しているSDK、API、エンドポイント、認証方式を確認する。
- 新しいFoundryプロジェクトへ移す対象と、しばらくclassicに残す対象を分ける。
- Foundryポータル、SDK、CLIの手順が新しい環境向けか確認する。
- ロール名、ロールID、ユーザーグループ、サービスプリンシパルを更新する。
- 開発環境でプロジェクト作成、モデル呼び出し、エージェント作成、評価実行を試す。
特にSDKは注意が必要です。公式の移行情報では、SDKバージョンとポータル体験が一致していないとエラーの原因になると警告されています。classic向けのサンプルコードをそのまま新しいFoundryプロジェクトへ流用しないようにしてください。(Microsoft Learn)
よくある失敗と対処法
| 失敗しやすいポイント | 起きる症状 | 対処 |
|---|---|---|
| New Foundryが無効 | 手順どおりの画面が見つからない | FoundryポータルでNew Foundryの切り替えを確認する |
| サブスクリプション違い | CLIで作成先が想定と違う | az account setで対象サブスクリプションを明示する |
--allow-project-managementを忘れる | Foundryリソース配下にプロジェクトを作成できない | リソース作成時にプロジェクト管理を有効化する |
| カスタムドメイン名が重複 | リソース更新や作成に失敗する | 組織名、環境名、用途を含めた一意な名前にする |
| ロール名変更を考慮していない | スクリプトのロール割り当てが失敗する | Foundryロールの定義IDを使う |
| 個人へ直接権限付与している | 異動・退職時に権限管理が煩雑になる | Microsoft Entraセキュリティグループへ付与する |
| 追加プロジェクトで機能差を見落とす | Fine-tuningやBatchが期待どおり使えない | デフォルトプロジェクトと追加プロジェクトの対応機能を確認する |
| 削除を軽く扱う | プロジェクトを復旧できない | 削除前に不要なプロジェクトか、関連資産がないか確認する |
プロジェクト削除は復旧できないため、検証環境でも注意が必要です。不要になったプロジェクトやリソースを削除する前に、デプロイ、評価結果、接続設定、関連するストレージや検索リソースの扱いを確認しておきましょう。(Microsoft Learn)
管理者・開発者向けチェックリスト
プロジェクト作成前後に、次の項目を確認してください。
| タイミング | 確認項目 |
|---|---|
| 作成前 | 利用目的がPoC、本番、チーム展開、移行のどれかを決める |
| 作成前 | リソースグループ、リージョン、命名規則、コストタグを決める |
| 作成前 | Azure Policy、ネットワーク分離、顧客管理キーの要否を確認する |
| 作成前 | 作成者がFoundryリソース作成とロール割り当てに必要な権限を持っているか確認する |
| 作成時 | Foundryポータル、Azure CLI、Python SDK、Bicepのどれで作るかを決める |
| 作成後 | プロジェクトエンドポイントを取得し、Entra ID認証またはAPIキー利用方針を決める |
| 作成後 | チームメンバーまたはセキュリティグループにFoundry Userを付与する |
| 作成後 | モデル推論、エージェント作成、評価、トレースなど必要機能を実際に試す |
| 展開前 | CLIやBicepのロール指定をロール名ではなく定義IDにできるか確認する |
| 展開前 | classic環境や旧SDKのサンプルが混在していないか確認する |
次に取るべき行動
Azure AI Foundryで「Create a project – Microsoft Foundry」の手順を使う場合、まずは利用目的を分けて判断しましょう。個人検証ならFoundryポータルでプロジェクトを作成し、エンドポイントと権限を確認します。チーム開発なら、Microsoft Entraセキュリティグループを用意し、Foundry Userを最小権限として付与します。本番展開なら、Azure CLIやBicepでリソース作成を標準化し、ネットワーク、タグ、RBAC、リージョンを組織ルールに合わせて管理します。
特に移行中の組織では、「Azure AI Foundry」「Microsoft Foundry」「Foundry classic」「Hubベースプロジェクト」という言葉が混在しやすくなります。作成手順を実行する前に、現在使っているポータル、SDK、ロール、エンドポイントが新しいFoundryプロジェクト向けかを確認してください。ここを整理してからプロジェクトを作れば、後続のエージェント開発、評価、ファイル管理、モデル展開を安全に進められます。
コメント