Azure AI FoundryでAIアプリ開発を始める場合、まず確認すべき公式手順が「Quickstart: Set up Microsoft Foundry resources」です。結論から言うと、このクイックスタートは、Microsoft Foundryプロジェクトの作成、モデルのデプロイ、チームメンバーへのアクセス付与までを一通り行うための最短ルートです。管理者はRBACロール名の変更、ロール割り当てのスコープ、CLIやポータルでの作成手順を確認し、開発者はプロジェクトエンドポイントとデプロイ名を正しく受け取れる状態にすることが重要です。(Microsoft Learn)
今回のポイントは、単に「Azure AI Foundryでモデルを作る手順」ではありません。Microsoft Foundryとしてのリソース構成、旧Azure AI系ロール名からFoundry系ロール名への移行、チーム利用時の最小権限設計、モデルデプロイ後に開発へ渡す接続情報までが整理されています。社内でAzure AI Foundryを試験導入する担当者、既存のAzure AIリソース運用を見直す管理者、AIアプリやエージェント開発を始める開発者は、最初にこの変更点を押さえておくべきです。
Azure AI Foundryの公式クイックスタートで何が示されたのか
「Quickstart: Set up Microsoft Foundry resources」は、Microsoft Foundryプロジェクトを作成し、モデルをデプロイし、必要に応じてチームメンバーにアクセス権を付与する手順をまとめた公式クイックスタートです。公式ページ上の最終更新日は2026年5月15日と表示されていますが、日本時間や配信文脈では2026年5月16日の更新情報として扱われる場合があります。(Microsoft Learn)
このクイックスタートで実施する作業は、大きく分けると次の4つです。
| 作業 | 内容 | 主な対象者 |
|---|---|---|
| Foundryプロジェクトの作成 | リソースグループ、Foundryリソース、プロジェクトを用意する | 管理者、リード開発者 |
| モデルのデプロイ | 例としてgpt-4.1-miniをデプロイする | 開発者、MLOps担当 |
| 接続情報の取得 | プロジェクトエンドポイントとデプロイ名を確認する | 開発者 |
| チームへのアクセス付与 | Foundry UserなどのRBACロールを割り当てる | Azure管理者、プロジェクト管理者 |
特に重要なのは、Azure AI Foundryをチームで使う場合、単にモデルをデプロイするだけでは不十分だという点です。誰がプロジェクトを作成できるのか、誰がモデルを利用できるのか、誰がロールを割り当てられるのかを事前に決めておかないと、開発開始後に権限不足や過剰権限の問題が起きやすくなります。
管理者が最初に確認すべき変更点
今回の公式情報で最も注意したいのは、Foundry RBACロール名の変更です。Microsoftの説明では、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と中核的な権限は変わらないとされています。(Microsoft Learn)
ただし、ロール名の変更が反映される途中では、ポータル、CLI、社内手順書、IaCテンプレート、監査ログなどで旧名称と新名称が混在する可能性があります。管理者は「名称が変わっただけ」と軽く扱わず、運用上は次の確認を行うべきです。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 社内手順書 | 旧Azure AIロール名の記載が残っていないか | 新任担当者が誤ったロールを選ぶ |
| IaC・自動化スクリプト | ロール名指定ではなくロール定義IDを使っているか | ロール名解決に失敗する可能性 |
| Azure PortalのIAM | 実際の割り当て先とスコープが正しいか | 過剰権限または権限不足 |
| 監査・棚卸し | 旧名称と新名称を同一ロールとして扱えるか | 権限レビューの抜け漏れ |
| 開発者向け案内 | 必要なプロジェクト名、エンドポイント、デプロイ名が共有されているか | SDKやアプリ接続時に失敗する |
公式クイックスタートでは、ロール名変更の移行中に問題を避けるため、コードやスクリプトではロール名ではなくロール定義ID、つまりGUIDを使うことが推奨されています。(Microsoft Learn)
影響範囲は「新規作成」だけでなく既存運用にも及ぶ
このクイックスタートは新規にMicrosoft Foundryリソースを作る手順ですが、影響は新規作成だけに限られません。既にAzure AI Foundryや関連リソースを使っている組織でも、RBACロール名、アクセス管理、開発者への接続情報の渡し方を見直す必要があります。
特に影響を受けやすいのは、次のような環境です。
| 環境・運用 | 影響を受ける理由 | 確認すべきこと |
|---|---|---|
| Azure CLIで環境を作成している | コマンドやスクリプト内でロール名を使っている可能性がある | GUID指定に変更できるか |
| 複数チームでFoundryを使う | プロジェクト単位の権限管理が必要になる | セキュリティグループで割り当てるか |
| 開発者にOwner権限を広く付与している | 最小権限から外れやすい | Foundry UserやProject Managerへ分離する |
| エージェント開発を行う | 基本セットアップと高度なセットアップで必要リソースが異なる | BYOリソースやネットワーク要件を確認する |
| APIキーで検証している | 本番利用では監査性や粒度の面で課題がある | Microsoft Entra ID認証へ移行できるか |
Azure AI Foundryは、単一の開発者が試すだけなら比較的簡単に始められます。しかし、チーム運用や本番環境を前提にすると、リソース、プロジェクト、モデル、認証、ロール、ネットワーク、監査を分けて設計する必要があります。
クイックスタートの基本手順
公式クイックスタートでは、Azure CLIまたはFoundryポータルを使ってプロジェクトを作成できます。CLIを使う場合は、Azure CLI 2.67.0以降が前提として示されています。(Microsoft Learn)
Azure CLIで作成する場合の流れ
CLIで進める場合、流れは次のようになります。
| 手順 | 実施内容 | 注意点 |
|---|---|---|
| Azureへサインイン | az loginで認証する | 対象テナントとサブスクリプションを間違えない |
| リソースグループ作成 | 例ではeastusに作成 | 利用予定モデルの提供リージョンを確認する |
| Foundryリソース作成 | --kind AIServices、--sku s0などを指定 | プロジェクト管理を有効化する |
| カスタムサブドメイン設定 | グローバルで一意の名前を指定 | 既に使われている名前は指定できない |
| プロジェクト作成 | Foundryリソース配下にプロジェクトを作成 | プロジェクト名の命名規則を決めておく |
| 作成結果の確認 | project showでリソースIDなどを確認 | ロール割り当て時にスコープとして使う |
公式手順では、Foundryリソース作成時に--allow-project-managementフラグを使います。このフラグは、そのリソース内でプロジェクト作成を有効にするための指定です。(Microsoft Learn)
実務では、検証用と本番用でリソースグループを分けることをおすすめします。たとえば、検証用はrg-foundry-dev、本番用はrg-foundry-prodのように分けておくと、コスト確認、アクセス管理、削除時の事故防止がしやすくなります。
Foundryポータルで作成する場合の流れ
Foundryポータルで作成する場合は、Microsoft Foundryにサインインし、New Foundryトグルが有効になっていることを確認したうえで、プロジェクト作成画面からプロジェクト名、リソースグループ、場所を指定します。(Microsoft Learn)
ポータル作成は初心者に向いていますが、チームや本番展開では「誰がどの設定で作成したのか」が見えにくくなることがあります。そのため、検証はポータル、本番や再現性が必要な環境はCLI、Bicep、Terraformなどで管理する方が安全です。
モデルデプロイで確認すべきポイント
公式クイックスタートでは、例としてgpt-4.1-miniをデプロイします。CLI例では、モデル名にgpt-4.1-mini、モデルバージョンに2025-04-14、モデル形式にOpenAI、SKU名にStandardを指定しています。(Microsoft Learn)
ここで注意したいのは、例にあるモデルが常に全リージョン、全サブスクリプション、全テナントで同じ条件で利用できるとは限らないことです。実際の展開前には、利用リージョン、クォータ、社内の利用ポリシー、コスト上限を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| モデル名 | 開発用途、コスト、応答速度、品質要件に合っているか |
| モデルバージョン | アプリ側で想定している挙動と一致するか |
| リージョン | チームの所在地だけでなく、モデル提供状況とデータ要件に合っているか |
| SKU・容量 | 検証用途と本番用途で分けているか |
| デプロイ名 | アプリ設定、環境変数、チーム共有資料で同じ名前を使っているか |
開発者に渡す情報として特に重要なのは、プロジェクトエンドポイントとデプロイ名です。公式クイックスタートでも、管理者はプロジェクトエンドポイントとデプロイ名をチームに共有する必要があると説明されています。(Microsoft Learn)
RBACロールの見直しが重要な理由
Azure AI Foundryの運用では、RBACを「とりあえずOwnerにしておく」と後で問題になります。Ownerは強力な権限を持つため、開発者に広く付与すると、意図しないリソース変更、ロール割り当て、コスト増加につながる可能性があります。
Microsoft Foundryでは、FoundryリソースとFoundryプロジェクトという2つのスコープを意識して権限を設計します。Foundryリソースは管理、セキュリティ、監視の境界であり、Foundryプロジェクトは作業単位や開発者ワークフローのアクセス制御に使われるサブスコープです。(Microsoft Learn)
代表的なロールの使い分けは次のとおりです。
| ロール | 主な用途 | 向いている人 |
|---|---|---|
| Foundry User | プロジェクト内でモデルや機能を使って開発・テストする | 一般開発者、検証担当 |
| Foundry Project Manager | プロジェクト管理や一部のロール付与を行う | チームリード、リード開発者 |
| Foundry Account Owner | Foundryリソースやプロジェクトを管理する | 管理者、プラットフォーム担当 |
| Foundry Owner | 管理と開発の両方を広く行う | 小規模チームの責任者、強い権限が必要な担当者 |
実務では、一般開発者にはFoundry Userを基本とし、チームリードには必要に応じてFoundry Project Managerを付与するのが扱いやすい構成です。管理者と開発者の役割を分けたい場合は、Foundry Account OwnerやFoundry Project Managerを使って、プロジェクト作成・モデル管理・アプリ開発の権限を分離します。
ロール名ではなくGUIDを使うべき場面
公式ドキュメントでは、ロール名変更の展開中に問題を避けるため、コードではロール定義IDを使うことが推奨されています。代表的なロール定義IDは次のとおりです。(Microsoft Learn)
| ロール | ロール定義ID |
|---|---|
| Foundry User | 53ca6127-db72-4b80-b1b0-d745d6d5456d |
| Foundry Owner | c883944f-8b7b-4483-af10-35834be79c4a |
| Foundry Account Owner | e47c6f54-e4a2-4754-9501-8e0985b135e1 |
| Foundry Project Manager | eadc314b-1a2d-4efa-be10-5d325db5065e |
特に次のような場面では、ロール名ではなくGUID指定を優先してください。
- Azure CLIでロール割り当てを自動化している
- TerraformやBicepでFoundry環境を展開している
- CI/CDパイプラインでサービスプリンシパルに権限を付与している
- 複数テナントや複数サブスクリプションで同じ手順を使っている
- 旧Azure AIロール名が混在している環境を移行している
たとえば、チームメンバーにFoundry Userを付与する場合は、プロジェクトのリソースIDを取得し、そのスコープに対してロール定義IDを指定します。個人ユーザーだけでなく、Microsoft Entraセキュリティグループに割り当てる運用も有効です。
チーム利用ではMicrosoft Entraセキュリティグループを使う
小規模な検証なら個別ユーザーにロールを付与しても問題ありません。しかし、開発者が増えると、個別付与はすぐに管理しづらくなります。公式クイックスタートでも、複数ユーザーを追加する場合は個別メールアドレスではなくMicrosoft Entraセキュリティグループの利用が示されています。(Microsoft Learn)
おすすめの運用は、役割ごとにグループを分ける方法です。
| グループ例 | 割り当てるロール | 用途 |
|---|---|---|
grp-foundry-dev-users | Foundry User | 開発者がモデルやプロジェクトを使う |
grp-foundry-project-managers | Foundry Project Manager | チームリードがプロジェクトを管理する |
grp-foundry-admins | Foundry Account Ownerまたは必要な管理者権限 | プラットフォーム管理者が環境を管理する |
grp-foundry-readers | Readerなど | 監査、確認、運用閲覧用 |
この設計にしておくと、新しい開発者が参加したときはEntraグループに追加するだけで済みます。退職、異動、プロジェクト終了時の権限削除もシンプルになります。
認証方式は本番前に見直す
Azure AI Foundryでは、Microsoft Entra IDとAPIキーによる認証が利用できます。ただし、Microsoftは本番ワークロードではMicrosoft Entra IDを使い、条件付きアクセス、マネージドID、最小権限RBACを有効にすることを推奨しています。APIキーは簡単に使える一方で、ユーザー単位の追跡や細かな権限制御が難しいと説明されています。(Microsoft Learn)
判断基準は次のとおりです。
| 用途 | 推奨される認証 | 理由 |
|---|---|---|
| 個人検証、短期PoC | APIキーでも可 | 設定が簡単で始めやすい |
| チーム開発 | Microsoft Entra ID | ユーザーやグループ単位で管理しやすい |
| 本番アプリ | Microsoft Entra ID、マネージドID | シークレット管理を減らし、監査性を高められる |
| CI/CD | サービスプリンシパルまたはマネージドID | 自動化に適し、権限を限定しやすい |
| エージェント利用 | Microsoft Entra ID | Foundryの一部機能ではEntra IDが必要になる |
APIキーでPoCを始めた場合でも、本番化の前にはEntra ID認証へ移行する計画を立ててください。特に、キーをソースコード、.env、CIログ、チケット本文に貼り付ける運用は避けるべきです。
エージェント開発ではクイックスタートだけで終わらせない
今回のクイックスタートは、基本的なリソース作成とモデルデプロイに焦点を当てています。公式ページでも、独自リソースを使う高度なシナリオでは、エージェント開発向けの環境セットアップを参照するよう案内されています。(Microsoft Learn)
Foundry Agent Serviceの環境セットアップでは、Basic Setup、Standard Setup、Standard Setup with Bring Your Own Virtual Networkといった構成が示されています。Standard SetupではAzure Storage、Azure AI Search、Azure Cosmos DBなどのBYOリソースを使い、顧客データを自社Azureリソースに保存する構成が説明されています。(Microsoft Learn)
つまり、次のような要件がある場合は、クイックスタートの基本構成だけで設計を完了しない方が安全です。
| 要件 | 検討すべき構成 |
|---|---|
| 会話履歴やファイルを自社管理したい | Standard Setup |
| ネットワーク分離を強めたい | Standard Setup with BYO Virtual Network |
| 顧客管理キーを使いたい | Standard Setup系 |
| 本番の監査・セキュリティ要件がある | Entra ID、RBAC、監視、BYOリソースを含めて設計 |
| エージェントを複数チームで運用したい | プロジェクト分離とEntraグループ管理 |
PoCではBasic Setupで素早く試し、本番化の判断前にStandard Setupへ移行するかどうかを検討する流れが現実的です。
移行・展開時に失敗しやすいポイント
Azure AI Foundryの環境構築では、コマンドをそのまま実行しても、組織のポリシーや権限、リージョン、モデル可用性によって失敗することがあります。以下の点は、展開前に確認しておきましょう。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| プロジェクトを作成できない | 必要なロールが不足している | Foundry OwnerやAccount Ownerなど、作成に必要な権限を確認する |
| ロール割り当てに失敗する | Ownerまたはロール割り当て権限がない | 管理者に依頼するか、適切なスコープで権限を付与する |
| モデルをデプロイできない | リージョンやクォータの制約 | モデル提供状況、クォータ、リージョンを事前確認する |
| 開発者がプロジェクトを開けない | ロールのスコープが違う | Foundryリソースとプロジェクトのどちらに割り当てたか確認する |
| アプリから接続できない | エンドポイントまたはデプロイ名が誤っている | 管理者が正式な接続情報を共有する |
| Entra ID認証で失敗する | カスタムサブドメインやRBAC設定が不足 | トークン認証の前提条件を確認する |
| 旧ロール名でスクリプトが動かない | ロール名変更の影響 | ロール定義IDを使う |
特に見落としやすいのが、ロール割り当てのスコープです。サブスクリプション、リソースグループ、Foundryリソース、Foundryプロジェクトのどこに付与したかで、実際にできる操作が変わります。開発者が「アクセス権はあるはずなのに使えない」と言う場合、まずスコープとテナントを確認してください。
管理者向けチェックリスト
Azure AI Foundryの展開前に、管理者は次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| サブスクリプション | 検証用・本番用のサブスクリプションが分かれているか |
| リソースグループ | 削除やコスト管理がしやすい単位で作成しているか |
| リージョン | 利用予定モデル、データ要件、社内ポリシーに合っているか |
| RBAC | Foundry User、Project Manager、Account Ownerなどを役割別に設計しているか |
| ロールID | 自動化ではロール名ではなくGUIDを使っているか |
| Entraグループ | 個別ユーザーではなくセキュリティグループで管理できるか |
| 認証方式 | PoCと本番でAPIキー、Entra ID、マネージドIDの使い分けを決めているか |
| 監査 | 誰がモデルをデプロイし、誰が使えるか確認できるか |
| コスト | モデルデプロイ、Standard Setupの追加リソース、検証環境の削除方針を決めているか |
開発者向けチェックリスト
開発者は、管理者から次の情報を受け取ってから実装を始めると、接続エラーや権限エラーを減らせます。
| 必要な情報 | なぜ必要か |
|---|---|
| プロジェクト名 | FoundryポータルやSDKで対象を確認するため |
| プロジェクトエンドポイント | アプリケーションから接続するため |
| デプロイ名 | モデル呼び出し時に指定するため |
| 使用可能なモデル | 品質、コスト、レイテンシの前提を合わせるため |
| 認証方式 | APIキーかEntra IDかで実装が変わるため |
| 自分に付与されたロール | できる操作とできない操作を把握するため |
| 利用環境 | dev、stg、prodで接続先を分けるため |
開発者側では、設定値をコードに直書きせず、環境変数やシークレット管理サービスを使うのが基本です。複数環境を扱う場合は、AZURE_FOUNDRY_ENDPOINT、AZURE_FOUNDRY_DEPLOYMENTのように名前を統一しておくと、チーム内でトラブルシューティングしやすくなります。
本番展開前に決めておきたい運用ルール
Azure AI Foundryを本番で使う場合、環境構築後の運用ルールまで決めておく必要があります。特にAIアプリは、モデル、プロンプト、データ、権限、コストが継続的に変化するため、初期設定だけで終わらせると運用品質が落ちます。
決めておきたいルールは次のとおりです。
| 運用ルール | 具体例 |
|---|---|
| 命名規則 | foundry-{system}-{env}-{region}のように統一する |
| 権限レビュー | 月次または四半期ごとにFoundryロールを棚卸しする |
| モデル変更手順 | モデルバージョン変更時は検証環境でテストしてから本番反映する |
| コスト監視 | サブスクリプション、リソースグループ、モデル単位で利用状況を確認する |
| キー管理 | APIキーを使う場合はローテーション周期を決める |
| ログ・監査 | 誰がデプロイ、変更、アクセスしたか追えるようにする |
| 削除ルール | PoC終了後にリソースグループ単位で削除できる構成にする |
特にPoC環境では、モデルデプロイや関連リソースを放置しがちです。公式クイックスタートでも、不要になったプロジェクトはリソースグループを削除して関連リソースを消す手順が示されています。(Microsoft Learn)
今回の更新を受けて次に取るべき行動
Azure AI Foundryの「Quickstart: Set up Microsoft Foundry resources」は、これからMicrosoft Foundryプロジェクトを作ってモデルを使い始めるための実践的な入口です。ただし、管理者や開発者が見るべきポイントは、手順そのものよりも、RBACロール名の変更、GUIDによるロール指定、プロジェクト単位のアクセス管理、Entra ID認証、チームへの接続情報共有にあります。
まずは検証環境でクイックスタートを一度実行し、プロジェクト作成、モデルデプロイ、Foundry Userの割り当て、開発者による接続確認までを小さく試してください。そのうえで、本番展開前にロール設計、Entraグループ、認証方式、ネットワーク、BYOリソースの必要性を見直すのが安全です。
特に既存のAzure AI関連手順を持っている組織は、旧ロール名が残っていないか、CLIやIaCでロール名指定をしていないか、開発者に過剰なOwner権限を付与していないかを優先的に確認しましょう。ここを整理しておけば、Azure AI Foundryの導入は単なる検証環境づくりではなく、チームで継続運用できるAI開発基盤へつなげやすくなります。
コメント