Azure AI Foundryで権限エラーや「どのロールを付ければよいのか分からない」という悩みが出ている場合、まず確認すべきなのはRBACの割り当て範囲です。公式情報「Role-based access control for Microsoft Foundry」では、Microsoft Foundryの権限管理を「Foundry resource」と「Foundry project」の2階層で考え、ユーザー本人だけでなくプロジェクトのマネージドIDにも適切なロールを付与することが重要だと整理されています。Microsoft Learn上の該当ページは最終更新日が2026年5月15日と表示されており、日本時間では2026年5月16日時点の確認対象として扱うのが自然です。(Microsoft Learn)
今回のポイントは、単なるロール名の変更ではありません。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerという名称への整理、Microsoft Entra ID認証を前提にした最小権限設計、Azure AI DeveloperやCognitive Services系ロールの誤用回避、そしてCLIやIaCでロール名ではなくロール定義IDを使うべき点が実務上の重要ポイントです。(Microsoft Learn)
Azure AI FoundryのRBACでまず押さえるべき結論
Azure AI FoundryのRBAC対応で最初にやるべきことは、既存の権限を「誰に」「どのスコープで」「何の目的で」付けているかを棚卸しすることです。特に、Azureポータルやスクリプトで旧名称のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerを参照している環境では、新名称への移行状況を確認する必要があります。ただし、公式情報ではロールIDと中核となる権限は変更されないと説明されています。(Microsoft Learn)
実務では、次の4点を優先して確認してください。
| 確認項目 | 確認する理由 | 対応の目安 |
|---|---|---|
| Foundryロールの名称変更 | 画面やスクリプトで旧名称と新名称が混在する可能性がある | 自動化ではロール名ではなくロール定義IDを使う |
| Foundry resourceとFoundry projectのスコープ | 権限を付ける場所を間違えると開発・運用操作が失敗する | 管理者はresource、開発者はproject中心で設計する |
| ユーザー本人とプロジェクトのマネージドID | 人の権限だけでは、プロジェクト側の処理が外部リソースへアクセスできない場合がある | Foundry Userを必要な主体に付与する |
| Azure AI DeveloperやCognitive Services系ロール | 名前が似ていてもFoundryプロジェクト向けではない場合がある | Foundry project accessにはFoundry UserまたはFoundry Ownerを使う |
特に注意したいのは、APIキー認証です。Microsoft FoundryのRBACロールはMicrosoft Entra IDで認証した場合に適用され、キー認証ではキー自体が広いアクセスを与えるため、きめ細かいロール制御には向きません。運用環境では、条件付きアクセス、監査、マネージドID、最小権限を活用できるMicrosoft Entra ID認証を前提に設計するのが安全です。(Microsoft Learn)
影響を受ける対象者
今回のRBAC整理は、Azure AI Foundryを使うすべてのユーザーに関係しますが、影響の出方は立場によって異なります。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Azure管理者、IAM管理者 | ロール割り当て、グループ管理、監査設計に影響する | 旧ロール名の利用、OwnerやContributorの過剰付与、グループ割り当ての有無 |
| AI基盤管理者 | Foundry resource単位の管理権限、モデル管理、接続管理に影響する | Foundry Account OwnerとFoundry Ownerの使い分け |
| プロジェクト責任者、リード開発者 | プロジェクト作成、メンバー追加、エージェント公開に影響する | Foundry Project Managerが必要な範囲 |
| アプリ開発者 | エージェント作成、推論、評価、ファインチューニングに影響する | Foundry Userがprojectスコープに付いているか |
| DevOps、SRE | CLI、IaC、CI/CDのロール割り当てに影響する | ロール名ではなくロール定義IDを使っているか |
| セキュリティ担当者 | キー認証、監査、最小権限、権限分離に影響する | Microsoft Entra ID認証へ寄せられているか |
管理者が最初に見るべきなのは、開発者にAzureのOwnerやContributorを広く付けていないかです。これらはAzureリソース管理では強力ですが、Foundryのデータプレーン操作まで意図通りにカバーするとは限りません。Hosted agentの公式リファレンスでも、ARMのcontrol plane権限とFoundryのdata plane権限は分けて考える必要があると説明されています。(Microsoft Learn)
Microsoft FoundryのRBACで理解すべき基本概念
Azure AI FoundryのRBACは、従来のAzure RBACと同じく「ID」「ロール」「スコープ」の組み合わせで考えます。ここでつまずきやすいのは、FoundryにはFoundry resourceとFoundry projectという2つの重要なスコープがある点です。
Foundry resourceとFoundry projectの違い
Foundry resourceは、Microsoft Foundry環境の上位スコープです。管理、セキュリティ、監視の境界として使われます。
Foundry projectは、その配下にある作業単位です。API、ツール、開発ワークフロー、エージェント構築などの実作業はproject単位で整理されます。公式情報でも、この2つのスコープを意識してロールを割り当てることが説明されています。(Microsoft Learn)
| スコープ | 主な用途 | 代表的な割り当て例 |
|---|---|---|
| Foundry resource | アカウント管理、プロジェクト管理、モデル管理、監視境界 | 管理者にFoundry Account Owner、責任者にFoundry Project Manager |
| Foundry project | 開発、推論、エージェント作成、評価、チーム単位のアクセス制御 | 開発者にFoundry User |
実務では、全員にresourceスコープで強い権限を付けるよりも、管理者はresource、開発者はprojectという形で切り分ける方が事故を防ぎやすくなります。
control planeとdata planeを分けて考える
Azure AI Foundryでは、権限をcontrol planeとdata planeに分けて考える必要があります。control planeはリソース作成、プロジェクト作成、ネットワーク、暗号化、接続、ロール割り当てなどの管理操作です。data planeは、モデル推論、エージェント操作、評価、ファインチューニングなど、実際にAI機能を使う操作です。(Microsoft Learn)
この違いを理解していないと、「AzureのContributorを付けたのにエージェントを操作できない」「管理者なのにプロジェクト内の実行操作ができない」といった権限エラーが起きます。
Foundryの組み込みロールの使い分け
Azure AI Foundryでは、Foundry向けの組み込みロールを使って最小権限を設計します。特に重要なのは、Foundry User、Foundry Project Manager、Foundry Account Owner、Foundry Ownerの4つです。
| ロール | 主な用途 | 向いている対象者 | 注意点 |
|---|---|---|---|
| Foundry User | Foundry projectでの開発、データアクション、基本的な利用 | 一般開発者、チームメンバー、プロジェクトのマネージドID | 最小権限の起点として使う |
| Foundry Project Manager | プロジェクト管理、開発、Foundry Userの条件付き割り当て | リード開発者、プロジェクト責任者 | エージェント公開には最低限このロールが必要とされる場面がある |
| Foundry Account Owner | プロジェクトやリソースの管理、条件付きロール割り当て | AI基盤管理者、部門管理者 | 管理権限は強いが、すべてのdata plane操作の代替とは考えない |
| Foundry Owner | 管理、開発、モデル管理、エージェント公開を含む広い権限 | 小規模チームの技術責任者、検証環境の管理者 | 権限が強いため本番では付与対象を絞る |
| Azure Owner | Azureサブスクリプションやリソースグループ全体の権限管理 | Azure管理者 | Foundryの日常開発ロールとして乱用しない |
| Azure Contributor | Azureリソース作成・更新 | インフラ担当、デプロイ担当 | Foundry projectのdata plane権限とは別に考える |
公式情報では、Cognitive Servicesで始まる組み込みロールはAI Servicesリソースへ直接アクセスする用途であり、Foundryシナリオには適用しないよう注意されています。また、Azure AI Developerという名前のロールも、Foundry projectやFoundry hosted agent向けではなく、Azure Machine LearningワークスペースやFoundry hubs向けの範囲だと説明されています。(Microsoft Learn)
名前だけで判断すると、Azure AI Developerを開発者向けに付けたくなります。しかし、Foundry projectでエージェントを作る、モデル推論を実行する、プロジェクト内の機能を使うといった操作では、Foundry UserやFoundry OwnerなどFoundry向けロールを確認するべきです。
最小権限で始めるためのロール割り当て
新規にAzure AI Foundryを使い始める場合、公式情報ではユーザープリンシパルとプロジェクトのマネージドIDの双方にFoundry Userを割り当てる考え方が示されています。プロジェクト作成者にロール割り当て権限がある場合は、自動的に割り当てられるケースがありますが、SDKやCLIからデプロイする場合は同じように自動付与されない点に注意が必要です。(Microsoft Learn)
最小構成の考え方
| 付与対象 | 推奨ロール | 主な目的 |
|---|---|---|
| 開発者本人 | Foundry User | Foundry projectでの開発、推論、エージェント操作 |
| プロジェクトのマネージドID | Foundry User | プロジェクトがFoundry機能や関連リソースを利用するため |
| プロジェクト責任者 | Foundry Project Manager | プロジェクト管理、メンバー追加、エージェント公開 |
| AI基盤管理者 | Foundry Account Owner | アカウント、プロジェクト、共有接続、モデル管理 |
| 全体管理者 | Azure OwnerまたはUser Access Administrator | ロール割り当て、権限管理 |
開発者が「画面には入れるが、エージェント作成や推論で失敗する」場合、本人の権限だけでなく、プロジェクトのマネージドIDに必要なロールが付いているかを確認してください。人間のユーザーとプロジェクト側のIDは別物です。
CLIやIaCではロール定義IDを使う
Foundry RBACロールは名称変更の展開中に旧名称と新名称が混在する可能性があります。そのため、スクリプトやIaCではロール名よりもロール定義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 | e47c6f54-e4a2-4754-9501-8e0985b135e1 |
| Foundry Project Manager | Azure AI Project Manager | eadc314b-1a2d-4efa-be10-5d325db5065e |
Azure CLIで割り当てる場合は、次のようにロール定義IDを指定します。実際のスコープは、Foundry resource、Foundry project、リソースグループなど、運用設計に合わせて置き換えてください。
az role assignment create \
--role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
--assignee "<user-or-managed-identity-object-id>" \
--scope "<target-scope>"メールアドレスを使って割り当てることもできますが、CI/CDや自動化ではオブジェクトIDを使う方が、名称変更や表示名変更の影響を受けにくくなります。
変更点として特に重要なロール名の整理
今回の公式情報で実務上もっとも目立つ変更は、Foundry RBACロールの名称変更です。旧名称はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerでしたが、新名称ではFoundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerに整理されています。ロールIDと中核権限は変わらないため、既存の割り当てが別物に置き換わるわけではありません。(Microsoft Learn)
ただし、管理画面、ログ、ドキュメント、CLI出力、IaCテンプレート、社内手順書では、しばらく旧名称と新名称が混在する可能性があります。管理者は「旧ロールを削除して新ロールを付け直す」と判断する前に、ロール定義IDが同じかを確認してください。
実務で起きやすい混乱
| 起きやすい混乱 | 原因 | 対処 |
|---|---|---|
| Azure AI UserとFoundry Userが別ロールに見える | 名称変更の展開中で表示が混在している | ロール定義IDを確認する |
| IaCがロール名指定で失敗する | ロール名の解決が環境や時期で揺れる | GUIDで指定する |
| 社内手順書とAzureポータルの表示が違う | 旧名称で作成されたドキュメントが残っている | 新旧対応表を手順書に追記する |
| 監査で重複付与に見える | 旧名称と新名称を別物として扱っている | IDベースで棚卸しする |
ロール名の変更は、権限設計そのものを変えるというより、Foundryとしてのサービス体系に合わせて名称を整理する動きです。とはいえ、自動化や監査の現場では小さな表記差が障害につながるため、運用手順の更新は早めに行うべきです。
Azure AI DeveloperやCognitive Servicesロールを使ってはいけない場面
Azure AI Foundryの権限設計でよくある失敗が、「AI」「Cognitive Services」「Developer」という名前だけを見てロールを選ぶことです。
公式情報では、Cognitive Servicesで始まるロールはAI Servicesリソースに直接アクセスするためのもので、Foundryシナリオには適用しないよう説明されています。また、Azure AI DeveloperロールはAzure Machine LearningワークスペースやFoundry hubs向けであり、Foundry projectsやFoundry hosted agents向けではありません。(Microsoft Learn)
| 付けたくなりやすいロール | 誤解 | 実務上の判断 |
|---|---|---|
| Azure AI Developer | Foundryの開発者ならこれでよいと思いがち | Foundry projectやHosted agentでは不足する可能性が高い |
| Cognitive Services OpenAI User | OpenAI系の推論に使えそうに見える | Foundry project accessとは分けて考える |
| Contributor | Azureリソースを作れるのでFoundry内も使えると思いがち | control plane中心。data plane権限を別途確認する |
| Owner | 何でもできると思いがち | 権限付与には強いが、日常開発者に広く付けるべきではない |
開発者に必要なのは、名前がそれらしいロールではなく、実際に利用するFoundry projectに対するdata plane権限です。エージェント作成、推論、評価、トレース、ファインチューニングなどを行う場合は、Foundry User、Foundry Project Manager、Foundry Ownerのどれが必要かを操作内容ごとに確認してください。
企業利用でのRBAC設計パターン
Azure AI Foundryを組織で使う場合は、アクセス分離のレベルを先に決めるとロール設計がぶれにくくなります。公式情報では、アクセス分離の考え方として「分離しない」「部分的に分離する」「完全に分離する」という例が示されています。(Microsoft Learn)
小規模検証ではFoundry Owner中心でもよいが本番では注意
小規模な検証チームでは、全員にFoundry Ownerを付けると立ち上げは早くなります。プロジェクト作成、開発、モデル管理、エージェント公開まで少人数で進める場合には効率的です。
ただし、この設計は本番運用や部門横断の環境には向きません。削除、変更、公開、接続管理などの権限が広くなり、監査や責任分界が曖昧になります。PoCが終わったら、必ずロールを見直してください。
部分分離では管理者と開発責任者を分ける
部分的にアクセスを分離する場合は、AI基盤管理者にFoundry Account Owner、プロジェクト責任者やリード開発者にFoundry Project Managerを割り当てる構成が現実的です。
この構成では、管理者が環境や接続、モデル、共有設定を管理し、プロジェクト責任者がチームの開発を進めます。管理者が日常的にプロジェクト内の開発操作をする必要がない組織では、権限の過剰付与を避けやすくなります。
本番環境では完全分離を基本にする
本番環境や機密データを扱うプロジェクトでは、管理者、プロジェクト責任者、開発者を明確に分ける設計が安全です。
| 役割 | 推奨される割り当て例 | 意図 |
|---|---|---|
| 管理者 | Foundry Account Ownerをresourceスコープに付与 | アカウント、プロジェクト、接続、モデル管理を担う |
| プロジェクト責任者 | Foundry Project Managerをresourceスコープに付与 | プロジェクト作成、メンバー管理、開発推進を担う |
| 開発者 | Readerをresourceスコープ、Foundry Userをprojectスコープに付与 | 必要なプロジェクトだけで開発できるようにする |
この形にすると、開発者が不要なプロジェクトや共有リソースへアクセスするリスクを下げられます。社内のMicrosoft Entra IDセキュリティグループと組み合わせれば、異動や参画・離任時の運用も簡単になります。
管理者が確認すべき設定チェックリスト
Azure AI FoundryのRBACを見直すときは、単にロールを付け直すのではなく、現在の状態を確認してから変更してください。
| チェック項目 | 確認方法 | 問題がある場合の対応 |
|---|---|---|
| 旧ロール名が残っていないか | Azure portalのAccess control、Azure CLI、IaCテンプレートを確認 | 新名称とロール定義IDの対応表を作る |
| ロール名指定の自動化がないか | Bicep、Terraform、CLI、PowerShell、社内スクリプトを確認 | ロール定義ID指定へ変更する |
| OwnerやContributorが広すぎないか | サブスクリプション、リソースグループ、resourceスコープを確認 | Foundry専用ロールへ置き換える |
| 個人単位で大量に割り当てていないか | IAMのメンバー一覧を確認 | Microsoft Entra IDセキュリティグループで管理する |
| APIキー運用に依存していないか | アプリ設定、Key Vault、環境変数を確認 | Microsoft Entra ID認証とマネージドIDへ移行する |
| プロジェクトのマネージドIDに権限があるか | プロジェクトIDのIAMを確認 | Foundry Userなど必要ロールを付与する |
| 接続先リソースの権限が足りているか | Storage、Azure AI Search、Application Insightsなどを確認 | 対象リソース側にも必要なロールを付与する |
公式情報では、Foundry外で作成されたBlob Storageを使う場合はFoundry account resourceのマネージドIDにStorage Blob Data Readerを付与する例や、Azure AI Searchを使う場合はSearch側のロール割り当てを確認する例が示されています。つまり、Foundry本体のRBACだけを直しても、接続先リソースの権限が不足していれば処理は失敗します。(Microsoft Learn)
開発者が確認すべき権限エラーの原因
開発者がAzure AI Foundryで権限エラーに遭遇した場合は、エラー文だけを見てロールを増やすのではなく、操作の種類を切り分けてください。
画面には入れるがエージェントを作成できない
この場合、resourceスコープのReaderやContributorは付いていても、projectスコープのFoundry Userが不足している可能性があります。Hosted agentの公式情報では、data plane操作にはFoundry User、Foundry Project Manager、Foundry OwnerなどのFoundryロールが必要になると説明されています。(Microsoft Learn)
確認する項目は次の通りです。
| 確認項目 | 見る場所 |
|---|---|
| 自分のユーザーにFoundry Userがあるか | 対象Foundry projectのAccess control |
| プロジェクトのマネージドIDに必要ロールがあるか | Foundry projectまたは関連リソースのIAM |
| Azure AI Developerだけで済ませていないか | 自分に付いているロール一覧 |
| APIキーではなくEntra IDで認証しているか | SDK、アプリ設定、環境変数 |
モデルのデプロイやファインチューニングで失敗する
ファインチューニングやデプロイでは、data planeとcontrol planeの両方が関係します。公式情報では、Foundryでモデルをファインチューニングするにはdata planeとcontrol planeの両方の権限が必要で、組み込みロールではFoundry Owner、またはFoundry UserとFoundry Account Ownerの組み合わせが選択肢として説明されています。(Microsoft Learn)
「推論はできるがデプロイできない」「評価は動くがモデル公開で止まる」という場合は、data planeだけでなくcontrol plane側の権限も確認してください。
ポータルでは動くがCLIやSDKでは失敗する
ポータルUIからFoundry resourceをデプロイした場合、ロール割り当て権限があるユーザーにはFoundry Userが自動的に付与されることがあります。一方、SDKやCLIからデプロイする場合、この自動付与は適用されないと公式情報に記載されています。(Microsoft Learn)
そのため、CI/CDで作った環境だけ権限エラーが出る場合は、デプロイ後に必要なロール割り当てを明示的に実行しているかを確認してください。
移行と展開の実務手順
既存環境を安全に移行する場合は、いきなり全ロールを変更するのではなく、棚卸し、対応表作成、テスト、段階展開の順で進めます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状棚卸し | サブスクリプション、リソースグループ、Foundry resource、Foundry projectのIAMを確認 | projectスコープの権限を見落とす |
| 新旧ロール対応表の作成 | Azure AI Userなど旧名称とFoundry Userなど新名称を対応付ける | 表示名だけで別ロールと誤認する |
| 自動化の修正 | CLI、Bicep、Terraform、社内スクリプトをロール定義ID指定へ変更 | ロール名指定のまま残す |
| グループ設計 | Microsoft Entra IDセキュリティグループ単位で割り当てる | 個人付与が増えて監査が難しくなる |
| 最小権限テスト | 一般開発者、リード開発者、管理者の操作を検証 | 管理者アカウントだけでテストしてしまう |
| 段階展開 | 検証環境、本番の一部、全体の順で反映 | 一括変更でプロジェクトが停止する |
| 監査と手順書更新 | ロール名、ID、付与基準、申請フローを文書化 | 旧名称の手順書が残る |
移行時に重要なのは、ロールを「強くすれば解決」と考えないことです。権限エラーが出たときにFoundry OwnerやAzure Ownerを付けると一時的には解消しやすいですが、後で誰が何をできるのか分からなくなります。まず操作内容を分け、必要な最小ロールを特定してください。
よくある失敗と対処法
Azure AI Developerを付けたのにHosted agentを使えない
Azure AI Developerは名前から開発者向けに見えますが、Hosted agentの公式リファレンスでは、Foundry project resourcesを使うHosted agentシナリオには不十分だと説明されています。(Microsoft Learn)
対処法は、対象projectにFoundry User、必要に応じてFoundry Project ManagerやFoundry Ownerを割り当てることです。
Contributorを付けたのに推論やエージェント操作ができない
ContributorはAzureリソース管理に強いロールですが、Foundryのdata plane操作とは別に考える必要があります。エージェント作成、推論、評価などはFoundry向けロールのdataActionsが関係します。(Microsoft Learn)
対処法は、操作がcontrol planeなのかdata planeなのかを切り分け、projectスコープのFoundry Userなどを確認することです。
APIキーを使っているのにRBACで制御できると思っている
RBACによる細かな制御はMicrosoft Entra ID認証を前提に考えるべきです。キー認証は検証には便利ですが、キーを持つ主体に広いアクセスを与えるため、ユーザー単位の監査や条件付きアクセスとの相性がよくありません。(Microsoft Learn)
対処法は、本番アプリケーションではマネージドIDやサービスプリンシパルを使い、必要なFoundryロールを明示的に割り当てることです。
接続先リソースの権限を忘れている
Foundry projectからBlob Storage、Azure AI Search、Application Insightsなどを使う場合、Foundry側のロールだけでは足りないことがあります。接続先リソース側にも、マネージドIDやグループへの権限付与が必要です。(Microsoft Learn)
対処法は、エラーが出たリソースを特定し、FoundryのマネージドIDが対象リソースで必要なロールを持っているか確認することです。
本番展開前に決めておくべき運用ルール
Azure AI FoundryのRBACは、導入時に一度設定して終わりではありません。プロジェクト追加、メンバー変更、モデル追加、接続先リソース追加、CI/CD更新のたびに見直しが必要です。
本番展開前には、少なくとも次のルールを決めておくと運用が安定します。
| ルール | 推奨内容 |
|---|---|
| 権限申請の単位 | 個人ではなくMicrosoft Entra IDグループを基本にする |
| 開発者の標準ロール | projectスコープのFoundry Userを基本にする |
| プロジェクト責任者の標準ロール | Foundry Project Managerを基本にする |
| 管理者の標準ロール | Foundry Account Ownerを基本にし、Foundry Ownerは限定する |
| 自動化で使うロール指定 | ロール名ではなくロール定義IDを使う |
| 認証方式 | 本番はMicrosoft Entra ID、検証でもキーの扱いを明確にする |
| 定期監査 | Owner、Contributor、Foundry Ownerの過剰付与を重点的に確認する |
特にFoundry Ownerは便利ですが、強い権限を持つロールです。小規模な検証では有効でも、本番では「誰でも作れる、消せる、公開できる」状態になりやすいため、利用目的と期限を決めて付与してください。
まとめ：Azure AI FoundryのRBACは「名称変更」より「権限設計の見直し」が重要
Azure AI Foundryの「Role-based access control for Microsoft Foundry」で押さえるべき本質は、ロール名の変更そのものではなく、Foundry resourceとFoundry projectを分けて最小権限を設計することです。
まずは、既存のAzure AI系ロールがFoundryロールへどう対応するかを確認し、自動化ではロール定義IDを使うように修正してください。そのうえで、開発者にはFoundry User、プロジェクト責任者にはFoundry Project Manager、管理者にはFoundry Account Ownerを基本に割り当て、Foundry OwnerやAzure Ownerは必要最小限に絞るのが安全です。
次に取るべき行動は、現在のIAM設定の棚卸しです。サブスクリプション、リソースグループ、Foundry resource、Foundry projectの4か所を確認し、旧ロール名、過剰なOwner・Contributor、APIキー依存、マネージドIDの権限不足を洗い出してください。ここまで整理できれば、Azure AI Foundryの権限エラーを減らしながら、チーム単位で安全にAI開発を進められます。
コメント