Azureで権限を付けたはずなのに、操作できない。よく聞く形はだいたい次のどれかです。

  • テナントのグローバル管理者なのに、Azureポータルにサブスクリプションが1つも出てこない
  • ロールを割り当てた直後に試したら、まだ「権限がありません」と言われる
  • ストレージアカウントの所有者なのに、Blobのコンテナーを開くと「アクセス許可がありません」と出る
  • 共同作成者なのに、ほかの人へロールを割り当てようとすると失敗する
  • 所有者なのに、リソースグループを削除できない

どれも「権限が足りない」ように見えますが、足りないものはそれぞれ違います。この記事は、無料動画「AZ-104試験対策 第1回：Microsoft Entra ID」と、メンバー限定動画「AZ-104試験対策 第2回：RBACとガバナンス」「第3回：Azure Storage」「AZ-900 第8回｜Azureの4階層」を素材に、Azureの権限が効かないときにどこを確かめるかをまとめたものです。公式の説明は2026年10月26日時点のMicrosoft Learnで確認しました。先に結論を書きます。

  1. Entra IDのロールと、Azureのロールは別物。 グローバル管理者でも、既定ではAzureのリソースに触れない
  2. Azureのロールは「どのロールを・誰に・どこ（スコープ）に」の3点で決まる。 権限は上から下へ引き継がれ、下で付けたものは上では効かない
  3. 割り当ててから効くまで、最大10分かかることがある。 サインインし直すと早く反映される
  4. リソースを管理する権限と、中のデータを読む権限は別。 所有者でも、Blobの中身を読むロールは別に要る
  5. 権限があっても止めるものがある。 ロックは所有者にも効く。ロールを人に割り当てられるのは所有者などに限られる

まず、それはEntra IDのロールかAzureのロールか

Microsoft 365やEntra IDを管理している人ほどはまるのが、ここです。無料動画の28分7秒からは、Entra IDでユーザーを作るときにExchange管理者などのロールを割り当てる画面を見せ、続く29分9秒からで、これは「Entra ID（旧Azure AD）の中のロール」であって、AzureはAzureの中に別のロールの仕組みを持っていると説明しています。

公式の「Azure ロール、Microsoft Entra ロール、従来のサブスクリプション管理者ロール」も同じことをはっきり書いています。グローバル管理者はEntra IDとMicrosoft 365にまたがる強い権限を持ちますが、既定では、グローバル管理者はAzureのリソースにアクセスできません。 Azureのロールは「アクセス制御 (IAM)」で割り当てるもので、Entra管理センターの「ロールと管理者」で割り当てるものとは別の一覧です。

Entra IDのロール Azureのロール（Azure RBAC）
例 グローバル管理者、ユーザー管理者、Exchange管理者 所有者、共同作成者、閲覧者、仮想マシン共同作成者
管理するもの ユーザー、グループ、ライセンス、M365のサービス サブスクリプション、リソースグループ、VM、ストレージなど
割り当てる場所 Entra管理センターの「ロールと管理者」 各スコープの「アクセス制御 (IAM)」

グローバル管理者がサブスクリプションを取り戻す方法

サブスクリプションの所有者が退職した、誰が持っているか分からない、というときのために、グローバル管理者には一時的に権限を昇格させる仕組みがあります。公式の「Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる」の手順は次のとおりです。

  1. グローバル管理者としてAzureポータルにサインインする（PIMを使っているなら、先にロールをアクティブにする）
  2. 「Microsoft Entra ID」→「管理」→「プロパティ」を開き、「Azure リソースのアクセス管理」を「はい」にして保存する
  3. サインアウトして、もう一度サインインする

「はい」にすると、ルートスコープ（/）でユーザーアクセス管理者というAzureのロールが付き、そのテナントにつながるすべてのサブスクリプションと管理グループでロールを割り当てられるようになります。この設定は押した本人だけに効きます。自分か担当者にサブスクリプションのロールを割り当てたら、「いいえ」に戻して昇格を外すことを公式は勧めています。

サインインしているディレクトリとアカウントも見る

ロールの割り当て先は、サブスクリプションが信頼しているEntra IDのテナントの中のIDです。無料動画の30分32秒からは、サブスクリプションを別のディレクトリにつなぎ替えると、Azureの中で付けていた権限がまとめて効かなくなる、という話をしています。逆に言えば、ポータルで今見ているディレクトリが、サブスクリプションのあるテナントと違えば、権限があっても何も見えません。

同じメールアドレスで個人用のMicrosoftアカウントと職場のアカウントの両方を持っていると、別のアカウントでサインインしていることにも気づきにくくなります。この2つが別人として扱われる仕組みは同じメールアドレスなのに、アカウントが2つあるで扱っています。

「どこに」割り当てたかで、効く範囲が決まる

メンバー限定の「AZ-104試験対策 第2回」の37分8秒からは、Azureのアクセス制御を「ロール」「ID」「スコープ」の3つと、それを結ぶ「割り当て」で説明しています。スコープは管理グループ、サブスクリプション、リソースグループ、個々のリソースのどこにでも置けます。

このとき効いてくるのが継承の向きです。メンバー限定の「AZ-900 第8回」の19分6秒からは、ポリシーとRBACの設定が管理グループ → サブスクリプション → リソースグループ → リソースの順に上から下へ引き継がれると説明しています。15分20秒からのとおり、権限を付ける基本の単位はサブスクリプションです。

ここから、よくある取り違えが2つ出てきます。

  • リソースグループに付けた権限では、ほかのリソースグループやサブスクリプション全体は見えない。 下で付けたものは上に広がらない
  • サブスクリプションで付けた権限は、中のリソースすべてに効いている。 リソースの画面で外そうとしても、そこで付けたものではない

どこで付いた権限かは画面で分かります。同じ動画の49分19秒からは、IAMの「ロールの割り当て」で、スコープ欄に「このリソース」と出ているものと、「継承済み」として管理グループやサブスクリプションから降りてきたものを見分け、リソースグループ、リソースと降りていっても同じ割り当てが並ぶことを確かめています。動画は試験対策ですが、この画面の読み方は実務でそのまま使えます。

割り当てた直後は、まだ効かないことがある

ロールを付けてすぐに試すと失敗し、少し待つと通る。これは設定の間違いではありません。公式の「Azure RBAC のトラブルシューティング」によると、Azure Resource Managerは性能のために構成をキャッシュしているので、ロールの割り当てや削除が有効になるまで最大10分かかることがあります。 ポータル、Azure PowerShell、Azure CLIなら、サインアウトしてサインインし直すと最新の状態に更新されます。REST APIならアクセストークンを取り直します。

同じページには、もっと長くかかる場合も書かれています。

場面 反映までの目安
通常のロールの割り当て・削除 最大10分。サインインし直しで早まる
管理グループのスコープで、データ操作（DataActions）を含む組み込みロールを割り当てた データへのアクセスが数時間更新されないことがある
マネージドIDをグループに追加し、そのグループにロールを割り当てた 数時間かかることがある（キャッシュが約24時間残る）

マネージドIDそのものの仕組みはマネージドIDを使うと、パスワードを書かなくてよくなるで扱っています。グループ経由で権限を渡すときは、この待ち時間を見込んでおきます。

メンバー限定の「AZ-104試験対策 第3回」の1時間40分58秒からは、まさにこの場面です。ロールを付けた直後に切り替えるとエラーになり、1時間41分27秒からでサインインし直すと通ります。

所有者なのに、Blobの中身が読めない

一番不思議に見えるのがこれです。Azureの操作は、**リソースそのものを作ったり設定したりする操作（コントロールプレーン）**と、**リソースの中のデータを読み書きする操作（データプレーン）**の2層に分かれています。メンバー限定の「AZ-104試験対策 第2回」の42分8秒からは、ロールの定義の中で「操作（Actions）」と「データアクション（DataActions）」が分けて書かれていることを画面で見せ、前者がAzure Resource Manager経由の操作、後者がリソースそのものへの操作だと説明しています。

所有者・共同作成者・閲覧者は、コントロールプレーンのロールです。ストレージアカウントの設定は変えられても、それだけではBlobのデータを読むロールにはなりません。

メンバー限定の「AZ-104試験対策 第3回」は、これを実際に踏んで見せています。1時間37分23秒から、サブスクリプションに権限を持つユーザーで azcopy を使ってアップロードすると、ステータス403の AuthorizationPermissionMismatch で失敗します。コンテナーは作れたのに、です。

ポータルでは中身が見えていた理由が、1時間38分0秒からの説明です。公式の「Azure portal で BLOB データへのアクセスを承認する」のとおり、ポータルはBlobを開くとき、まずアカウントキーを取り出す権限（Microsoft.Storage/storageAccounts/listkeys/action）があるかを確かめ、あればアカウントキーでデータにアクセスします。所有者や共同作成者にはこの権限があるので、自分のEntra IDの権限ではなく、キーで見えていただけでした。動画の1時間38分57秒からで認証方法を「Microsoft Entra ユーザー アカウント」に切り替えると、データを一覧表示するアクセス許可がない、と表示されます。

Entra IDの権限でBlobを読むには、公式によると次の2つが要ります。

  • データ用のロール: ストレージ BLOB データ閲覧者、ストレージ BLOB データ共同作成者、ストレージ BLOB データ所有者のどれか（またはそれに当たるカスタムロール）
  • ストレージアカウントを見られるロール: 少なくともストレージアカウント以上のスコープで、閲覧者（またはそれ以上の管理用のロール）

動画の1時間39分50秒からは、IAMで所有者を持っていることを確かめたうえで、ストレージ BLOB データ所有者を追加しています。同じ公式ページは、ストレージアカウントに読み取り専用のロックがかかっているとアカウントキーを取り出せないので、Entraの資格情報でアクセスする必要がある、とも書いています。所有者だから見える、という状態に頼っていると、ロックやキーの扱いが変わった日に急に見えなくなります。

共同作成者なのに、ほかの人にロールを割り当てられない

同じ「AZ-104試験対策 第2回」の43分34秒からは、よく使う3つのロールの違いを説明しています。

ロール できること
所有者 すべて。ほかの人へのロールの割り当ても含む
共同作成者 リソースの管理はすべてできる。ただしロールの割り当てはできない
閲覧者 すべてのリソースを表示できる。変更はできない

共同作成者で割り当てようとすると、Microsoft.Authorization/roleAssignments/write を実行する権限が無い、というエラーになります。公式の「Azure RBAC のトラブルシューティング」の対処は、そのスコープでこの権限を持つロールの人にサインインしてもらうことです。所有者のほか、先ほどのユーザーアクセス管理者もこの権限を持ちます。リソースを作る人と、権限を配る人を分けておける、ということでもあります。

割り当ての画面そのものは、動画の47分10秒からで見られます。ロールを選び、メンバーとしてユーザー・グループ・サービスプリンシパル・マネージドIDのどれかを選び、スコープを確かめて割り当てる流れです。

所有者なのに、削除できない

権限が足りないのではなく、止められていることもあります。リソースのロックです。公式の「インフラストラクチャを保護するためにAzure リソースをロックする」によると、ロックはすべてのユーザーのアクセス許可より優先されます。 「削除」のロックなら読み取りと変更はできても削除できず、「読み取り専用」なら変更も削除もできません。親のスコープに付けたロックは中のリソースすべてに継承されます。

メンバー限定の「AZ-104試験対策 第2回」の50分2秒からは、公開中のWebサイトを入れたリソースグループに削除のロックを付け、51分28秒からで削除を実行して、ロックされているため削除できない、と失敗するところを見せています。続けて、子のリソースからは親で付いたロックを編集できず、付けたスコープに移動して外す必要があることも確かめています。

ロックを付けたり外したりできるのも、所有者やユーザーアクセス管理者などに限られます。消せないときはIAMより先に、そのリソースと親のリソースグループ・サブスクリプションの「ロック」を見ます。

まとめ

症状 原因 確かめる・直すこと
グローバル管理者なのにサブスクリプションが見えない Entra IDのロールで、Azureのロールが無い サブスクリプションの所有者に割り当ててもらう。いなければ「Azure リソースのアクセス管理」で昇格し、済んだら戻す
何も見えない・別のテナントの画面になっている サインインしているアカウントやディレクトリが違う ポータル右上のアカウントとディレクトリを確かめる
一部のリソースグループしか見えない リソースグループのスコープで割り当てている IAMのスコープ欄で、どこで付いた権限かを見る
割り当てた直後だけ失敗する Azure Resource Managerのキャッシュ 最大10分待つ。サインインし直す。管理グループ・マネージドIDのグループ経由は数時間見込む
所有者なのにBlobのデータが読めない、azcopy が403 管理用のロールで、データ用のロールが無い ストレージ BLOB データ閲覧者などを割り当てる
共同作成者なのにロールを割り当てられない 共同作成者には割り当ての権限が無い 所有者かユーザーアクセス管理者に頼む
所有者なのに削除・変更できない ロックがかかっている リソースと親スコープのロックを見る

Azureの権限が効かないとき、「もっと強いロールを付ければいい」と考えると、所有者を配りすぎる方向に進みます。足りないのは強さではなく、種類（EntraかAzureか、管理かデータか）と場所（スコープ）と時間のどれかであることがほとんどです。この3つを順に見れば、必要な権限だけを付けて解決できます。