
Azureの所有者とEntraのグローバル管理者は何が違う?権限の範囲を整理する
どうも!オペ部の西村祐二です!
「グローバル管理者なのに、AzureのVMを管理できない」「サブスクリプションの所有者なのに、Entra IDのユーザーを管理できない」。こうした場面では、管理者ロールが対象にしているものを分けて考える必要があります。
AzureロールとMicrosoft Entraロールは、既定では別々の権限体系です。グローバル管理者はEntra ID側、所有者はAzureリソース側のロールで、互いの管理権限が自動的に付くわけではありません。
この記事では、ユーザー管理とVM管理を例に、権限を依頼するときに整理したい対象・ロール・範囲を説明します。2026年10月27日時点のMicrosoft Learnに基づく解説です。実環境でのロール割り当て、操作の許可・拒否、アクセス昇格は実施していません。設定手順やエラー原因全般の調査は扱いません。
所有者とグローバル管理者は、管理する対象が違う
Microsoft Entra IDは、ユーザーやグループ、アプリなどのIDを管理します。一方、Azure RBACは、VMやストレージなどのAzureリソースへのアクセスを管理する仕組みです。リソースグループは、関連するAzureリソースをまとめて管理する単位です。
| 観点 | Microsoft Entraロール | Azureロール(Azure RBAC) |
|---|---|---|
| 管理対象 | Entra IDのユーザー、グループ、アプリなど | AzureのVM、ネットワーク、ストレージなど |
| 代表例 | グローバル管理者、ユーザー管理者 | 所有者、共同作成者、閲覧者 |
| 今回の例で使う場面 | Entra IDのユーザーを作成・管理する | 開発用リソースグループ内のVMを管理する |
| もう一方への権限 | Azureリソースの管理権限は自動付与されない | Entra IDの管理権限は自動付与されない |
同じユーザーに両方のロールが割り当てられることはあります。ただし、その場合も「1つの管理者権限ですべてを操作している」とは捉えず、どのロールがその操作を許可しているかを分けて考えます。
図は自作した概念図で、公式の構成図ではありません。同じユーザーでも、Entra IDの管理とAzureリソースの管理には別のロール割り当てがあります。図は通常の管理対象の違いを示したもので、後述するアクセス昇格は省略しています。

Azureの所有者には「どこの所有者か」がある
Azure RBACのロール割り当ては、「誰に」「どのロールを」「どの範囲で」付与するかの3点で整理できます。この範囲をスコープと呼びます。
通常のスコープ階層は、管理グループ、サブスクリプション、リソースグループ、個々のリソースです。上位で割り当てた権限は下位に継承されます。
たとえば、同じサブスクリプションに開発用のdev-rgと本番用のprod-rgがあるとします。dev-rgの所有者という割り当てだけでは、prod-rgの管理権限は得られません。サブスクリプションの所有者なら、その配下の両方のリソースグループが管理範囲に含まれます。
そのため、「私は所有者です」だけでは管理範囲が伝わりません。「開発用リソースグループの所有者です」のように、対象と一緒に見る必要があります。
権限の依頼は、実行したい操作から考える
管理対象が分かれば、次は必要な操作に合うロールを選びます。以下は、ロールの役割を整理するための例です。
| やりたいこと | 検討する権限 | 範囲を考えるポイント |
|---|---|---|
| Entra IDのユーザーを作成・管理する | Entraのユーザー管理者など | 対象ユーザーの管理に必要な範囲を確認する |
| 開発用リソースグループのリソースを閲覧する | Azureの閲覧者 | 開発用リソースグループを対象にする |
| 開発用リソースグループのリソースを管理する | Azureの共同作成者など | ロール割り当ての管理まで必要かを分ける |
| Azureリソースへのアクセス権を割り当てる | Azureのロールベースのアクセス制御管理者など | 委任する対象範囲や条件を別途検討する |
ユーザー管理者の役割はEntraの組み込みロール、所有者・共同作成者・アクセス管理用ロールの権限はAzureの特権を持つ組み込みロールに記載されています。閲覧者の権限はReaderの定義で確認できます。共同作成者はリソースを管理できますが、Azure RBACのロール割り当てはできません。所有者には、その割り当て権限も含まれます。
たとえば、「開発作業のためにグローバル管理者が必要」と依頼するよりも、次のように操作と範囲が分かるほうが、付与する権限を検討しやすくなります。
開発用サブスクリプションの
dev-rg内で、VMなどのリソースを管理したいです。他のユーザーへのロール割り当ては担当しません。
この要件なら、Azure側のロールをdev-rgの範囲で検討できます。Entra全体を管理するグローバル管理者を付ける話とは分けられます。共同作成者よりも限定したサービス別ロールで足りるかどうかは、実際に担当する操作に合わせた判断になります。
グローバル管理者には、Azure側のアクセスを回復する例外がある
ここまでの「別々の権限体系」という説明には、押さえておきたい例外があります。グローバル管理者によるアクセス昇格です。
公式資料では、Azureのサブスクリプションや管理グループへのアクセスを失った場合などに、グローバル管理者が自分のアクセスを昇格できると説明されています。
このとき付くのは所有者ではなく、ルートスコープ/のユーザーアクセス管理者(User Access Administrator)です。同じEntraテナント内のすべてのサブスクリプションと管理グループで、リソースの閲覧とアクセス権の割り当てが可能になります。
昇格しても、それだけでVMの構成変更権限が付くわけではありません。ただし、Azureロールを割り当てられるため、自分や他のユーザーに所有者などを付与できる強い権限です。
通常の作業で必要な範囲のAzureロールを割り当てることと、テナント全体に及ぶアクセス昇格は区別が必要です。公式資料も、必要な変更が終わったら昇格したアクセスを解除するよう案内しています。
まとめ
Azureの所有者とEntraのグローバル管理者は、同じ管理対象で強さを比べるロールではありません。Entraのユーザー管理なのか、Azureリソースの管理なのかを分けると、必要な権限を整理できます。
権限を依頼するときは、ロール名だけでなく「何を操作したいか」「どの範囲か」を添えるのが良さそうです。グローバル管理者によるアクセス昇格は例外として存在しますが、通常の権限割り当てとは範囲も目的も異なります。
参考リンク:








