Microsoft Foundry / Azure OpenAIを本番利用するうえで、最初につまずきやすいのが「誰に、どのスコープで、どのロールを割り当てるべきか」です。結論から言うと、今回のMicrosoft Foundry RBACの更新ポイントは、ユーザー本人だけでなく、プロジェクトのマネージドIDにも最小権限を割り当てること、そしてFoundryリソース単位とFoundryプロジェクト単位を分けて権限設計することです。
特にAzure OpenAIを既に使っている組織では、「OwnerやContributorを付ければ動く」という発想から、Microsoft Entra ID、Azure AI User、Azure AI Project Managerなどを使った最小権限モデルへ移行する必要があります。Microsoftの公式ドキュメントでも、Microsoft FoundryのRBACではスコープ、組み込みロール、エンタープライズ向けの割り当てパターンが整理されています。(Microsoft Learn)
Microsoft Foundry RBACの更新でまず押さえるべき結論
2026年4月時点のMicrosoft Foundry RBACで重要なのは、単に「ロールの種類がある」と理解することではありません。実務では、次の3点を最初に決める必要があります。
| 判断ポイント | 実務での意味 | 推奨される考え方 |
|---|---|---|
| 誰が使うのか | IT管理者、プロダクトオーナー、開発リード、開発者で必要な権限が違う | 人ではなく職務単位でロールを決める |
| どこまで使わせるのか | サブスクリプション、リソースグループ、Foundryリソース、Foundryプロジェクトで影響範囲が変わる | 原則は狭いスコープから割り当てる |
| 何を実行するのか | モデル管理、プロジェクト作成、エージェント構築、微調整などで必要権限が違う | 操作内容ごとにコントロールプレーンとデータプレーンを分ける |
Microsoft FoundryのRBACでは、Foundryリソースが管理・セキュリティ・監視の上位境界になり、FoundryプロジェクトがAPI、ツール、開発者ワークフローを整理するサブスコープになります。つまり、組織全体の管理はFoundryリソースで行い、チームや案件単位の作業はFoundryプロジェクトで制御する設計が基本です。(Microsoft Learn)
最小構成は「ユーザー」と「プロジェクトのマネージドID」の両方にAzure AI User
Microsoft Foundryを新しく使い始める場合、公式ドキュメントでは最小限のロール割り当てとして、Foundryリソースに対してAzure AI Userロールを2つ割り当てる形が示されています。1つは利用者のユーザープリンシパル、もう1つはプロジェクトのマネージドIDです。(Microsoft Learn)
| 割り当て対象 | 割り当てるロール | 割り当て先スコープ | 目的 |
|---|---|---|---|
| ユーザープリンシパル | Azure AI User | Foundryリソース | Foundry機能をユーザーが利用できるようにする |
| プロジェクトのマネージドID | Azure AI User | Foundryリソース | プロジェクトがFoundry機能へアクセスできるようにする |
ここで重要なのは、開発者本人だけに権限を付けても、プロジェクト側のマネージドIDに必要な権限がなければ、接続、エージェント、ツール連携、外部リソース利用の場面でエラーになりやすい点です。AIアプリケーションでは「人がポータルで操作する権限」と「アプリやプロジェクトが裏側で実行する権限」を分けて考える必要があります。
プロジェクトを作成したユーザーがロール割り当て権限を持つ場合、これらの割り当ては自動的に追加される場合があります。ただし、SDKやCLIからデプロイする場合など、自動付与が前提にならないケースもあるため、初回構築後にAzure portalのAccess control（IAM）で確認することが重要です。(Microsoft Learn)
Azure OpenAI運用では「キー認証」よりMicrosoft Entra IDを前提にする
Azure OpenAIを試すだけならAPIキー認証でも動作確認はできます。しかし、Microsoft Foundryを本番運用するなら、Microsoft Entra IDを使った認証とRBACを前提にした方が安全です。
Microsoftの認証・認可ドキュメントでは、FoundryはMicrosoft Entra IDとAPIキーの両方をサポートすると説明されています。一方で、Entra IDは条件付きアクセス、マネージドID、細かなRBACに対応し、APIキーはユーザー単位の追跡や細かなスコープ制御が難しいとされています。(Microsoft Learn)
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| APIキー | 検証、PoC、短期間の isolated test | キーを持つ人やアプリに広い権限が渡りやすい |
| Microsoft Entra ID | 本番、社内システム連携、監査が必要な環境 | 初期設定とRBAC設計が必要 |
| マネージドID | Azure上のアプリ、Functions、Container Apps、VMなどからの接続 | 呼び出し元リソースへのロール割り当てが必要 |
プロダクトオーナー視点では、APIキーは「早く動かす」ための手段であり、Entra IDは「安全に運用し続ける」ための手段です。PoCでAPIキーを使った場合でも、本番化の前にEntra ID認証、マネージドID、RBACへ切り替える計画を必ず入れておくべきです。
コントロールプレーンとデータプレーンを分けて考える
Microsoft Foundry / Azure OpenAIの権限設計で混乱しやすいのが、コントロールプレーンとデータプレーンの違いです。
コントロールプレーンは、リソース作成、プロジェクト作成、ネットワーク設定、接続、モデルデプロイなどの管理操作です。データプレーンは、チャット補完、埋め込み生成、エージェント実行、評価、Content Safety呼び出しなど、実際にAI機能を使う操作です。Microsoftのドキュメントでも、Foundryではこの2つの操作面が分けて説明されています。(Microsoft Learn)
| 操作例 | 分類 | 必要になりやすい権限 |
|---|---|---|
| Foundryリソースを作成する | コントロールプレーン | Owner、Contributor、Azure AI Account Ownerなど |
| Foundryプロジェクトを作成する | コントロールプレーン | Azure AI Project Manager以上が候補 |
| モデルをデプロイする | コントロールプレーン | 管理系ロールが必要 |
| エージェントを構築する | データプレーン | Azure AI Userが基本 |
| 推論APIを呼び出す | データプレーン | Azure AI Userや関連するデータアクション |
| 微調整したモデルをデプロイする | 両方に関係 | データプレーンとコントロールプレーンの両方を確認 |
この分離を理解しないままロールを付けると、「ポータルでは見えるが実行できない」「APIは呼べるがデプロイできない」「開発者にOwnerを付けすぎて監査で指摘される」といった問題が起きます。
組み込みロールの選び方
Microsoft Foundryでは、Azure全体で使われるOwner、Contributor、Readerに加えて、Foundry向けの組み込みロールを使います。主なロールはAzure AI User、Azure AI Project Manager、Azure AI Account Owner、Azure AI Ownerです。Microsoftの公式ドキュメントでは、Foundryリソースでは最小権限の原則に従うため、これらの追加ロールを使うことが示されています。(Microsoft Learn)
| ロール | 主な対象者 | 使いどころ | 注意点 |
|---|---|---|---|
| Azure AI User | 開発者、検証担当、利用者 | プロジェクト内でビルド、テスト、エージェント利用を行う | 管理操作は限定される |
| Azure AI Project Manager | チームリード、開発リード | プロジェクト作成、プロジェクト管理、開発推進 | Azure AI Userの条件付き割り当てが可能 |
| Azure AI Account Owner | IT管理者、AI基盤管理者 | Foundryリソースやアカウント管理 | 高権限のため常時付与は避けたい |
| Azure AI Owner | 小規模チームの責任者、セルフサービス型チーム | 管理と開発をまとめて行う | 権限が広いため大企業では慎重に使う |
| Reader | 監査担当、閲覧のみの関係者 | リソース状態の確認 | 実行や管理はできない |
| Owner | Azure管理者 | ロール割り当て、全体管理 | 最小権限の観点では限定利用が望ましい |
実務では、いきなりAzure AI Ownerを広く配るのではなく、Azure AI Userから始めて、プロジェクト作成やモデル管理が必要な人にAzure AI Project Managerを付ける形が扱いやすいです。IT管理者はAzure AI Account OwnerやAzureのOwnerを必要なスコープに限定し、恒常的な高権限を減らす設計にします。
エージェント公開にはAzure AI Project Manager以上を確認する
Microsoft Foundryでエージェントを扱う場合、開発者がAzure AI Userだけで十分かどうかは操作内容によって変わります。
公式ドキュメントでは、エージェントを公開するにはFoundryリソーススコープでAzure AI Project Managerロールが最小要件として示されています。(Microsoft Learn)
そのため、次のように役割を分けると運用しやすくなります。
| 利用シーン | 推奨ロール設計 |
|---|---|
| 既存プロジェクトでエージェントを試す | 開発者にAzure AI User |
| チーム内でエージェントを作成・検証する | リード開発者にAzure AI Project Manager、メンバーにAzure AI User |
| エージェントを本番公開する | 公開権限を持つ少数メンバーにAzure AI Project Manager以上 |
| 複数部門でエージェントを管理する | 部門別Entraグループにロールを割り当てる |
プロダクトオーナーは、「誰でも公開できる」状態にしないことが重要です。エージェントは外部ツール、検索、ストレージ、業務データと接続する場合があるため、公開権限は開発権限より一段上の承認済みロールとして扱うべきです。
エンタープライズ向けのRBAC設計例
大企業やグローバル組織では、個人単位でロールを直接割り当てるとすぐに管理できなくなります。Microsoft Learnでも、エンタープライズ向けのRBACマッピングとして、IT管理者、マネージャー、チームリード、開発者のようなペルソナごとの割り当て例が示されています。(Microsoft Learn)
実務では、次のような設計が現実的です。
| ペルソナ | 割り当て例 | 目的 |
|---|---|---|
| IT管理者 | サブスクリプションまたはリソースグループでOwner、必要に応じてFoundryリソースでAzure AI Account Owner | ガバナンス、監査、ネットワーク、ロール管理 |
| AI基盤管理者 | FoundryリソースでAzure AI Account Owner | モデル、接続、共有リソースの管理 |
| 開発リード | FoundryリソースでAzure AI Project Manager | プロジェクト作成、チームメンバー招待、開発管理 |
| 開発者 | FoundryプロジェクトでAzure AI User、FoundryリソースでReader | 既存モデルや接続を使った開発 |
| 監査・セキュリティ担当 | 必要範囲でReader、Azure Monitor関連の閲覧権限 | ログ、構成、監査確認 |
この設計のポイントは、「開発者にリソース全体のContributorを付けない」ことです。Azure OpenAIの利用が広がるほど、プロンプト、接続先データ、エージェントの操作範囲が増えます。必要以上の権限を与えると、誤操作だけでなく、意図しないデータアクセスや運用コスト増加にもつながります。
Microsoft Entraグループでロール割り当てを管理する
人数が増える環境では、個々のユーザーに直接ロールを割り当てるのではなく、Microsoft Entraグループを使う方が安全で管理しやすくなります。公式ドキュメントでも、Entraグループを使うことで、個別ユーザーではなくグループに権限を付与し、新しい開発者に必要なロール割り当て数を減らせると説明されています。(Microsoft Learn)
おすすめは、次のようなグループをあらかじめ作ることです。
| Entraグループ例 | 割り当てるロール | 用途 |
|---|---|---|
| grp-foundry-admins | Azure AI Account Owner | Foundry基盤の管理 |
| grp-foundry-project-managers | Azure AI Project Manager | プロジェクト作成・管理 |
| grp-foundry-dev-team-a | Azure AI User | チームAの開発作業 |
| grp-foundry-auditors | Reader | 監査・閲覧 |
| grp-foundry-aiops | Azure Monitor Readerなど | 監視・トレース確認 |
グループ名には、対象サービス、役割、チーム名を含めると棚卸しが楽になります。たとえばgrp-foundry-dev-sales-jpのように命名しておけば、どの部門のどの用途かを権限レビュー時に判断しやすくなります。
ロール割り当ての基本手順
Microsoft Foundryのロール割り当ては、Foundry portal、Azure portalのIAM、Azure CLIから管理できます。公式ドキュメントでは、Foundry portalのAdminページ、Azure portalのAccess Control（IAM）、Azure CLIを使った管理方法が説明されています。(Microsoft Learn)
Azure portalで割り当てる場合
| 手順 | 作業内容 |
|---|---|
| 1 | Azure portalで対象のFoundryリソースまたはFoundryプロジェクトを開く |
| 2 | Access control（IAM）を開く |
| 3 | Add role assignmentを選択する |
| 4 | Azure AI Userなど必要なロールを選ぶ |
| 5 | User、group、service principal、またはManaged identityを選ぶ |
| 6 | 対象ユーザー、Entraグループ、マネージドIDを選択する |
| 7 | Review + assignで確定する |
Azure CLIで割り当てる場合
CLIで割り当てる場合は、対象スコープを間違えないことが重要です。公式ドキュメントでは、az role assignment createを使ってAzure AI Userを割り当てる例が示されています。(Microsoft Learn)
az role assignment create \
--role "Azure AI User" \
--assignee "[email protected]" \
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.CognitiveServices/accounts/<foundry-resource-name>"実運用では、ユーザー個人ではなくEntraグループやマネージドIDを--assigneeに指定するケースが多くなります。CI/CD、Functions、Container Apps、AKSなどから呼び出す場合は、アプリのマネージドIDまたはサービスプリンシパルに必要なロールを付与します。
失敗しやすいポイントと対策
Microsoft Foundry RBACはAzure RBACをベースにしているため、設定自体は慣れれば難しくありません。ただし、Azure OpenAIやAIエージェントの運用では、権限不足と過剰権限の両方が問題になります。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| ユーザーはログインできるが機能を使えない | ユーザープリンシパルに必要なロールがない | Azure AI UserをFoundryリソースまたはプロジェクトに割り当てる |
| エージェントや接続が動かない | プロジェクトのマネージドIDに権限がない | マネージドIDにもAzure AI Userや接続先リソースの権限を付ける |
| 開発者にOwnerを配ってしまう | 最小権限設計がない | Azure AI User、Project Manager、Account Ownerに分ける |
| APIキーが共有されて監査できない | 個人やアプリ単位の認証になっていない | Microsoft Entra IDとマネージドIDへ移行する |
| CLIデプロイ後に権限が足りない | ポータル作成時の自動割り当てを前提にしている | デプロイ後のRBAC確認をIaCまたは運用手順に入れる |
| モデル微調整後のデプロイで詰まる | データプレーンとコントロールプレーンの両方が必要 | Azure AI Owner、またはAzure AI UserとAzure AI Account Ownerの組み合わせを検討する |
特に注意したいのは、Foundry外部で作成したAzure Blob StorageやAzure AI Searchなどを使う場合です。公式ドキュメントでは、外部リソースを利用するには、そのリソース側にもFoundryアカウントのマネージドIDなどへ適切なロールを付与する必要があると説明されています。(Microsoft Learn)
アクセス分離は3段階で考える
Microsoft FoundryのRBACでは、組織の成熟度に合わせてアクセス分離を設計できます。公式ドキュメントでは、アクセス分離の例として、分離なし、部分的な分離、完全な分離という考え方が示されています。(Microsoft Learn)
| 分離レベル | 向いている組織 | 設計例 |
|---|---|---|
| 分離なし | 小規模チーム、PoC中心 | 少数メンバーにAzure AI Ownerを付与 |
| 部分的な分離 | 部門単位で開発する中規模組織 | 管理者にAzure AI Account Owner、開発リードにAzure AI Project Manager |
| 完全な分離 | 大企業、金融、公共、グローバル組織 | 管理者、プロジェクト管理者、開発者、監査担当を明確に分ける |
最初から完全分離を目指すと、PoCのスピードが落ちることがあります。一方で、PoCの設定をそのまま本番に持ち込むと、権限が広すぎる状態が残ります。おすすめは、PoCでは部分的な分離から始め、本番化の前に完全分離へ近づける進め方です。
IT管理者が確認すべきチェックリスト
Microsoft Foundry / Azure OpenAIのRBACを導入・見直しする場合、IT管理者は次の項目を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| APIキーを本番で使い続けていないか | 本番はMicrosoft Entra IDとRBACを基本にする |
| 開発者にOwnerやContributorを広く付けていないか | Azure AI UserやAzure AI Project Managerへ置き換える |
| プロジェクトのマネージドIDに必要権限があるか | Foundryリソース、Storage、AI Searchなど接続先ごとに確認する |
| ロールを個人に直接付けすぎていないか | Entraグループ経由に変更する |
| FoundryリソースとFoundryプロジェクトのスコープを分けているか | 管理はリソース、開発はプロジェクトで分離する |
| エージェント公開権限を制限しているか | Azure AI Project Manager以上を必要な人に限定する |
| 権限レビューの周期が決まっているか | 月次または四半期で棚卸しする |
| IaCやCLIデプロイ後のRBAC確認があるか | 自動付与に依存せず、明示的に検証する |
プロダクトオーナーが押さえるべき判断基準
プロダクトオーナーは、ロール名を細かく覚える必要はありません。ただし、次の判断はできるようにしておくべきです。
まず、AI機能を「誰が作るか」と「誰が公開するか」を分けます。開発者全員に公開権限を渡すのではなく、リード開発者や運用責任者に限定します。
次に、業務データに接続するエージェントでは、接続先の権限も確認します。Foundry側で権限が正しくても、Storage、AI Search、Application Insights、社内API側の権限が広すぎると、データ漏えいや誤操作のリスクが残ります。
最後に、PoC完了時点でRBACを見直します。PoC中はスピード優先で広い権限を使うことがありますが、本番移行前にはAzure AI User、Azure AI Project Manager、Azure AI Account Ownerへ役割を整理し、APIキー共有をやめることが重要です。
まず実施すべき次のアクション
Microsoft Foundry / Azure OpenAIの権限設計を見直すなら、最初にやるべきことはシンプルです。
現在のFoundryリソースとプロジェクトについて、誰にどのロールが付いているかを確認します。そのうえで、開発者にはAzure AI User、開発リードにはAzure AI Project Manager、基盤管理者にはAzure AI Account Ownerを基本として、OwnerやContributorの常時付与を減らしていきます。
あわせて、プロジェクトのマネージドIDにAzure AI Userが付与されているか、外部のStorageやAzure AI Searchに必要な権限があるかを確認してください。Microsoft Foundry RBACの更新ポイントは、新機能の派手さよりも、AIアプリケーションを安全に本番運用するための「権限設計の標準化」にあります。
Azure OpenAIをMicrosoft Foundry上で活用する組織は、次の順番で進めると失敗しにくくなります。
| 順番 | 実施内容 |
|---|---|
| 1 | 現在のロール割り当てを棚卸しする |
| 2 | 個人直接付与をEntraグループ中心に変更する |
| 3 | 開発者、リード、管理者、監査担当のロールを分ける |
| 4 | ユーザーとプロジェクトのマネージドIDに必要な最小権限を付与する |
| 5 | APIキー利用を減らし、Entra IDとマネージドIDへ移行する |
| 6 | PoCから本番移行する前に、過剰権限を削除する |
この流れを運用ルールに落とし込めば、Microsoft Foundry / Azure OpenAIを「動かす」だけでなく、「監査できる」「安全に拡張できる」AI基盤として扱えるようになります。
コメント