Azure AI Foundryを使っている組織で今回すぐ確認すべきことは、RBACロールの表示名が「Azure AI」系から「Foundry」系に変更された点です。既存のロールIDと中核的な権限は変更されていないため、通常はユーザー権限を作り直す必要はありません。ただし、Azure CLI、Bicep、Terraform、運用手順書、監査レポートなどでロール名を文字列として指定している場合は、失敗や混乱の原因になります。
2026年5月16日に公開・更新されたAzure Updatesでは、「Update: Microsoft Foundry built-in RBAC role naming and enhancements」がLaunched、つまり一般提供済みの更新として案内されています。今回のポイントは機能追加そのものよりも、Azure AI Foundry / Microsoft Foundryの権限管理を、現在のFoundryブランドに合わせて整理する変更だと捉えると分かりやすいです。(Microsoft Azure)
Azure AI FoundryのRBACロール名変更で何が変わるのか
今回の変更では、Microsoft Foundryで使われる組み込みRBACロールの名称が、製品ブランドに合わせて変更されました。Microsoft LearnのRBACドキュメントでも、旧ロール名と新ロール名の対応が明記されており、ロールIDと中核的な権限は変更されていないと説明されています。(Microsoft Learn)
| 旧ロール名 | 新ロール名 | 主な用途 |
|---|---|---|
| Azure AI Account Owner | Foundry Account Owner | Foundryアカウントやプロジェクト、リソース管理を担当する管理者向け |
| Azure AI Owner | Foundry Owner | Foundry環境に対する広い管理権限を持つ所有者向け |
| Azure AI User | Foundry User | プロジェクト内でエージェント作成、推論、開発作業を行う利用者向け |
| Azure AI Project Manager | Foundry Project Manager | プロジェクト管理、開発、Foundry Userの割り当てなどを行うリード開発者・プロジェクト管理者向け |
重要なのは、これは単なる表示名変更では済まない運用上の影響を持つという点です。AzureポータルやFoundryポータル上の表示、社内手順書、権限申請フォーム、IaCテンプレート、CI/CDパイプライン、監査用スクリプトなどに旧名称が残っていると、担当者が同じロールを別物と誤認したり、自動化処理がロール名解決に失敗したりする可能性があります。
一方で、既存の権限割り当てを慌てて削除・再作成する必要は基本的にありません。公式ドキュメントでは、ロールIDと中核的な権限は変わらないとされています。移行作業の中心は、「権限そのものの移行」ではなく「参照名・手順・自動化コードの更新」です。(Microsoft Learn)
変更されるものと変更されないもの
RBACロール名の変更では、見た目の名前だけに注目すると判断を誤りやすくなります。管理者は、何が変わり、何が変わらないのかを切り分けて確認する必要があります。
| 項目 | 変更内容 | 実務上の見方 |
|---|---|---|
| ロール表示名 | Azure AI系の名称からFoundry系の名称に変更 | ポータル、手順書、申請フォーム、教育資料の更新が必要 |
| ロールID | 変更なし | IaCやスクリプトではロールID指定が安全 |
| 中核的な権限 | 変更なし | 既存ユーザーの権限設計を全面的にやり直す更新ではない |
| 一部画面での表示 | 移行中は旧名称が見える可能性あり | ロールIDで同一性を確認する |
| RBACの考え方 | 変更なし | 最小権限、スコープ設計、Entra IDグループ運用は引き続き重要 |
特に注意したいのは、Azureポータルやドキュメント、CLIの出力、監査ログ、サードパーティ製管理ツールで、表示名の反映タイミングがそろわない可能性です。公式ドキュメントでも、ロール名変更のロールアウト中は一部の場所で以前の名前が表示される可能性があるとされています。(Microsoft Learn)
そのため、確認時には「表示名が違うから別ロール」と判断するのではなく、可能な限りロール定義IDで照合してください。
管理者が最初に確認すべき影響範囲
Azure AI FoundryのRBACロール名変更で影響を受けやすいのは、実際の権限よりも、権限を参照・付与・説明している周辺の仕組みです。特に以下の範囲は早めに棚卸ししておくと、問い合わせや運用ミスを減らせます。
| 確認対象 | 影響の例 | 優先度 |
|---|---|---|
| Azureポータル / FoundryポータルのIAM表示 | 旧名称と新名称の混在で担当者が混乱する | 高 |
| Bicep、ARMテンプレート、Terraform | ロール名指定でデプロイが失敗する可能性 | 高 |
| Azure CLI / PowerShellスクリプト | --role に旧ロール名を指定している場合に失敗する可能性 | 高 |
| GitHub Actions / Azure DevOps | 自動デプロイ時のRBAC付与処理が止まる可能性 | 高 |
| 権限申請フォーム | 申請者が旧ロール名を選び続ける | 中 |
| 社内Wiki、運用手順書 | ヘルプデスクや開発者が旧名称で問い合わせる | 中 |
| 監査・棚卸しレポート | 旧名と新名が別ロールのように集計される | 中 |
| PIMや承認フロー | 表示名変更により承認者が判断しづらくなる | 中 |
実務では、まず本番環境に関係するIaC、CI/CD、定期実行スクリプトから確認するのが効率的です。手順書の更新は重要ですが、スクリプト停止のほうが影響は大きくなります。
ロールIDで管理すべき理由
今回の更新で最も実践的な対策は、自動化コードではロール名ではなくロール定義IDを使うことです。Microsoft Learnでも、ロール名変更のロールアウト中の問題を避けるため、コードではロール定義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 |
たとえば、次のような運用は避けたほうが安全です。
az role assignment create \
--assignee <principal-id> \
--role "Azure AI User" \
--scope <scope>ロール名の変更・反映遅延・ローカライズ表示の違いを避けるには、次のようにロール定義IDを使うほうが安定します。
az role assignment create \
--assignee <principal-id> \
--role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
--scope <scope>この考え方は、Azure CLIだけでなく、Bicep、ARMテンプレート、Terraform、GitHub Actions、Azure DevOpsのタスクでも同じです。人が読む資料では新ロール名を使い、機械が実行するコードではロール定義IDを使う、という分担にしておくと、今後の名称変更にも強くなります。
Azure AI Foundryのロールをどう使い分けるべきか
今回の名称変更を機に、ロールの使い分けも見直しておくと効果的です。ロール名が変わっただけでなく、「Owner」「User」「Project Manager」といった名称から受ける印象だけで割り当てると、過剰権限や権限不足が起きやすくなります。
| ロール | 向いている利用者 | 割り当ての考え方 |
|---|---|---|
| Foundry User | 開発者、データサイエンティスト、エージェントを利用・作成するメンバー | プロジェクト単位で付与し、必要以上に広いスコープへ付けない |
| Foundry Project Manager | チームリード、プロジェクト管理者、開発も行う責任者 | プロジェクト作成やFoundry User割り当てが必要な人に付与 |
| Foundry Account Owner | プラットフォーム管理者、AI基盤管理者 | アカウントや共有リソース管理が主目的の人に付与 |
| Foundry Owner | 広い管理・開発権限が必要な少数の管理者 | 最小権限の観点から乱用しない |
MicrosoftのRBACドキュメントでは、Foundryの権限はプロジェクト作成、アカウント作成、プロジェクト内の開発、ロール割り当て、モデル管理、エージェント公開などの観点で整理されています。また、エンタープライズ向けの例として、IT管理者、マネージャー、リード開発者、チームメンバーごとに役割とスコープを分ける考え方も示されています。(Microsoft Learn)
実務では、以下のように整理すると判断しやすくなります。
| シーン | 推奨される考え方 |
|---|---|
| 開発者が既存プロジェクトでエージェントや推論を使う | Foundry Userをプロジェクトスコープで付与 |
| リード開発者がプロジェクト作成やメンバー追加も行う | Foundry Project Managerを検討 |
| 管理者がモデルデプロイやアカウント管理を行う | Foundry Account OwnerまたはFoundry Ownerを検討 |
| 監査・閲覧だけが目的 | Readerなど、より狭いAzure RBACロールで足りるか確認 |
| 全員に広い権限を与えたい | セキュリティ上は避け、グループ単位で最小権限を設計 |
「開発者だからAzure AI Developerを付ければよい」と考えるのは危険です。公式ドキュメントでは、Cognitive Servicesで始まる組み込みロールはAI Servicesリソースへの直接アクセス向けであり、Foundryシナリオには適用されないと説明されています。また、Azure AI Developerロールも、名称に反してFoundryプロジェクトやHosted agents向けのロールとしては不十分な場合があるため、FoundryのプロジェクトアクセスにはFoundry UserまたはFoundry Ownerなどを使うよう案内されています。(Microsoft Learn)
開発者・DevOps担当者が確認すべきポイント
開発者やDevOps担当者は、実際の権限よりも、デプロイ処理の中で旧ロール名を参照していないかを確認してください。特に、開発環境では問題が出なくても、本番用サービスプリンシパルやマネージドIDの権限付与で止まることがあります。
まず、リポジトリ全体で旧名称を検索します。
rg "Azure AI Account Owner|Azure AI Owner|Azure AI User|Azure AI Project Manager"rg が使えない環境では、grepでも構いません。
grep -R "Azure AI User" .見つかった場合は、単純に新名称へ置き換えるだけでなく、可能であればロール定義IDへ置き換えます。特に以下のファイルは優先して確認してください。
| ファイル・場所 | 確認ポイント |
|---|---|
| Bicep / ARMテンプレート | roleDefinitionId を使っているか |
| Terraform | role name参照ではなく、安定したID参照にできるか |
| Azure CLIスクリプト | --role "Azure AI User" のような指定が残っていないか |
| PowerShell | -RoleDefinitionName に旧名称を指定していないか |
| GitHub Actions | 権限付与ステップで旧名称を使っていないか |
| Azure DevOps Pipeline | サービス接続やRBAC付与タスクに旧名称が残っていないか |
また、Foundry Agent Serviceを使う場合は、Azure Resource Managerのコントロールプレーン権限とFoundryのデータプレーン権限を混同しないことが重要です。Microsoft Learnでは、OwnerやContributorは広いARMコントロールプレーン権限を持つ一方で、エージェント作成や操作のようなデータプレーン操作にはFoundry User、Foundry Project Manager、Foundry OwnerなどのFoundry固有ロールが必要だと説明されています。(Microsoft Learn)
つまり、AzureのContributorを付けたのにエージェント操作で失敗する、というケースは今回のロール名変更とは別に起こり得ます。名称変更対応と合わせて、コントロールプレーンとデータプレーンの権限設計も見直してください。
管理者向けの確認手順
今回の更新に対して、管理者は次の順番で確認すると効率的です。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | 現在のロール割り当てを棚卸しする | 旧名称・新名称の混在状況を把握する |
| 2 | IaCとスクリプトを検索する | 自動化処理の失敗を防ぐ |
| 3 | ロール定義IDへの置き換えを検討する | 名称変更に強い運用へ変える |
| 4 | 権限申請フォームと手順書を更新する | 問い合わせと誤申請を減らす |
| 5 | 検証環境でデプロイと権限付与を再実行する | 本番反映前に失敗箇所を見つける |
| 6 | 開発者・ヘルプデスクへ周知する | 旧名称での問い合わせを減らす |
Azure CLIでロール割り当てを確認する場合は、対象のスコープを明確にして実行します。
az role assignment list \
--scope <scope> \
--include-inherited \
--output tableロール定義そのものを確認する場合は、ロール定義IDを使って確認できます。
az role definition show \
--name 53ca6127-db72-4b80-b1b0-d745d6d5456dFoundryポータル側では、AdminページからプロジェクトまたはFoundryリソースのアクセス管理を確認できます。Microsoft Learnでは、FoundryポータルのAdminページ、AzureポータルのAccess Control（IAM）、Azure CLIからロールを管理できると説明されています。(Microsoft Learn)
移行時にやってはいけないこと
ロール名変更への対応では、焦って既存の割り当てを削除・再作成すると、かえって障害を招きます。特に本番環境では、以下の対応は避けてください。
| 避けるべき対応 | 理由 |
|---|---|
| 旧名称のロール割り当てを見つけたら即削除する | 表示名が旧名でも同じロールIDの可能性がある |
| 一時対応として全員にOwnerやContributorを付ける | データプレーン権限不足の解決にならない場合があり、過剰権限にもなる |
| 申請フォームだけ先に更新し、IaCを放置する | 本番デプロイ時にRBAC付与が失敗する可能性がある |
| Azure AI Developerで代替する | FoundryプロジェクトやHosted agentsでは不十分な場合がある |
| ロール名の文字列比較で監査する | 新旧名称の混在で誤検知しやすい |
特に「OwnerやContributorがあれば全部できる」という思い込みは危険です。Foundryでは、ARMコントロールプレーン操作とFoundryデータプレーン操作が分かれており、エージェント作成・推論・操作にはFoundry固有ロールが必要になる場面があります。(Microsoft Learn)
エージェント運用への影響
Azure AI Foundryでエージェントを構築・公開している場合は、RBACロール名変更に加えて、エージェント関連の権限も確認しておくべきです。
Microsoft LearnのHosted agent permissions referenceでは、Foundry Userはエージェント作成、モデル推論、エージェント操作に関係するロールとして説明されています。一方、Foundry Account Ownerはアカウントレベルのリソース管理やデプロイ作成を担いますが、エージェント作成や操作のようなデータプレーン操作はできないと説明されています。(Microsoft Learn)
| 操作 | 確認すべき権限 |
|---|---|
| エージェントを作成する | Foundry User、Foundry Project Manager、Foundry Ownerなどのデータプレーン権限 |
| モデル推論を行う | Foundry User相当の権限 |
| プロジェクトを作成する | Foundry Project Manager、Foundry Account Owner、Foundry Ownerなど |
| モデルをデプロイする | Foundry Account Owner、Foundry Ownerなど |
| TeamsやMicrosoft 365 Copilotへ公開する | Foundry側の権限に加え、Bot Serviceなど別リソースの権限も確認 |
| ACRやLog Analyticsを使う | Foundryロールだけでなく、対象リソース側のロールも確認 |
エージェントを外部リソースと連携させる場合、Storage、Azure AI Search、Key Vault、データベース、Container Registry、Log Analyticsなど、それぞれのリソース側で追加のデータプレーン権限が必要になることがあります。ロール名変更だけを直しても、連携先の権限が不足していればデプロイや実行は失敗します。(Microsoft Learn)
企業環境ではEntra IDグループ単位で見直す
個人ユーザーに直接ロールを付与している環境では、今回のようなロール名変更時に棚卸しが煩雑になります。Microsoft LearnのFoundry展開計画でも、アクセス管理の一貫性を保つためにMicrosoft Entra IDグループを使う考え方が示されています。(Microsoft Learn)
企業環境では、次のようなグループ設計にすると運用しやすくなります。
| グループ例 | 割り当てるロール例 | スコープ例 |
|---|---|---|
grp-foundry-platform-admins | Foundry Account OwnerまたはFoundry Owner | Foundryリソース |
grp-foundry-project-managers | Foundry Project Manager | Foundryリソースまたは対象プロジェクト |
grp-foundry-developers-project-a | Foundry User | プロジェクト |
grp-foundry-readers | Reader | Foundryリソースまたはプロジェクト |
この方式なら、ロール名が変わっても、誰にどの権限を与えているかをグループ単位で追跡できます。個人の異動・退職・プロジェクト参加変更にも対応しやすく、監査にも向いています。
本番展開前のチェックリスト
今回の更新に対応する際は、以下のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認済み |
|---|---|
| 旧ロール名と新ロール名の対応表をチーム内で共有した | |
| IaC、CLI、PowerShell、CI/CDで旧ロール名を検索した | |
| 可能な箇所はロール定義ID指定へ変更した | |
| 権限申請フォームの選択肢を新ロール名に更新した | |
| 社内Wiki、手順書、運用Runbookを更新した | |
| 監査レポートで旧名・新名を同一ロールとして扱えるようにした | |
| AzureポータルとFoundryポータルで主要ユーザーの権限を確認した | |
| 検証環境でプロジェクト作成、モデルデプロイ、エージェント操作を試した | |
| 開発者向けに「Azure AI Developerでは代替できない場合がある」と周知した | |
| PIMや承認フローの表示名変更を確認した |
特に本番影響を避けたい場合は、最初にCI/CDとIaCを確認し、次に申請・監査・手順書を更新する順番がおすすめです。
よくある疑問
既存のRBAC割り当ては作り直す必要があるのか
通常は作り直す必要はありません。公式ドキュメントでは、ロールIDと中核的な権限は変更されていないと説明されています。削除・再作成よりも、まずロール定義IDで同一ロールか確認してください。(Microsoft Learn)
旧ロール名がまだポータルに表示されている場合は問題か
必ずしも問題とは限りません。ロール名変更の反映中は、一部の場所で旧名称が表示される可能性があります。表示名だけで判断せず、ロールIDと実際の権限を確認してください。(Microsoft Learn)
Azure AI UserをFoundry Userに置き換えるだけで十分か
人が読む資料や申請フォームでは、新名称への置き換えで十分な場合があります。ただし、スクリプトやIaCでは新名称に置き換えるだけでなく、ロール定義IDを使うほうが安全です。
AzureのOwnerやContributorがあればFoundryの操作もできるのか
すべての操作ができるとは限りません。OwnerやContributorはARMコントロールプレーンでは広い権限を持ちますが、エージェント作成や操作などのFoundryデータプレーン操作にはFoundry固有ロールが必要になる場合があります。(Microsoft Learn)
Foundry Account Ownerは開発者向けロールなのか
主にアカウントやリソース管理向けのロールです。エージェント作成や推論などのデータプレーン操作を行う開発者には、Foundry UserやFoundry Project Managerなどを検討してください。(Microsoft Learn)
今回の更新で取るべき次のアクション
Azure AI Foundryの「[Launched] Update: Microsoft Foundry built-in RBAC role naming and enhancements」は、既存権限を大きく変える更新というより、RBACロールの名称体系をFoundryブランドへ統一する更新です。とはいえ、運用現場ではロール名を使った自動化、申請、監査、問い合わせ対応が多いため、放置すると小さな混乱が積み重なります。
まずは、以下の3点から着手してください。
- 旧ロール名がIaC、CLI、PowerShell、CI/CDに残っていないか検索する
- 自動化コードでは新ロール名ではなくロール定義IDを使う
- 社内手順書、権限申請フォーム、RBAC設計表を新ロール名に更新する
あわせて、Foundry User、Foundry Project Manager、Foundry Account Owner、Foundry Ownerの使い分けを見直すと、今回の変更対応を単なる名称修正で終わらせず、最小権限に基づいた安全なAzure AI Foundry運用へつなげられます。
コメント