共同作成者ロールが付与されているのにBlob操作で認証エラーが発生してしまう件について
Azure の認証とアクセス制御は、意外とハマりがちなポイントが多いです。
特に AzureDefaultCredential を使って Azure Blob Storage にアクセスしようとすると、
「権限がない」というエラーに出くわすことがあります。
その理由は、RBAC（ロールベースアクセス制御） の設定にあります。
この記事では、なぜエラーが発生するのか、どうすれば解決できるのかを解説します。
ところで、こちらの記事の内容が非常にわかりやすかったです。
https://zenn.dev/microsoft/articles/932f815d3cd7de
AzureDefaultCredential とは？
上記でも書いてますが、ざっくりと説明します。
AzureDefaultCredential は、Azure SDK の認証クラスで、
いくつかの認証方法を自動的に試してくれる便利な仕組みです。
例えば、以下のような順番で認証を試みます：
1. 環境変数の資格情報（ローカルで設定されているもの）
2. マネージド ID（Azure VM や Azure Functions など）
3. Azure CLI のログイン情報（開発環境で便利）
4. Visual Studio や Azure PowerShell の認証情報
つまり、「どれか使える認証があれば自動的に選んでくれる」というわけです。
では、なぜ Azure Blob Storage へのアクセスでエラーになるのでしょうか？
Contributor（共同作成者）ロールでは Blob のデータ操作ができない？
Azure Storage の RBAC 設定には、さまざまなロールが存在します。
その中で 「共同作成者（Contributor）」ロール は、
ストレージアカウントの管理操作はできるけれど、データ操作はできない という制約があります。
具体的には：
| ロール名 | できること | できないこと |
|---|---|---|
| Contributor（共同作成者） | ストレージアカウントの管理（設定変更、ポリシー管理など） | Blob のデータ操作（アップロード、ダウンロード、削除） |
| Storage Blob Data Reader | Blob の読み取り | 書き込み、削除 |
| Storage Blob Data Contributor | 読み取り・書き込み・削除 | なし |
| Storage Blob Data Owner | すべて（アクセス管理も可能） | なし |
つまり、Contributor ロールだけでは Blob のデータ操作ができない ため、
AzureDefaultCredential を使ってアクセスしようとしても、権限エラーが発生するわけです。
エラーが発生するケース（Python コード例）
例えば、以下の Python コードでエラーが出ます：
from azure.identity import AzureDefaultCredential
from azure.storage.blob import BlobServiceClient
credential = AzureDefaultCredential()
blob_service_client = BlobServiceClient(account_url="https://<your-storage-account>.blob.core.windows.net", credential=credential)
container_client = blob_service_client.get_container_client("my-container")
blobs = container_client.list_blobs() # ここで権限エラー発生
この場合、Contributor ロールしか持っていないと、
list_blobs() の時点で 権限不足エラー になります。
解決策：適切な RBAC ロールを付与する
この問題を解決するには、適切な RBAC ロール をストレージアカウントに設定すればOKです。
Blob データ操作に必要なロール
• Storage Blob Data Reader → 読み取り専用（ダウンロード可）
• Storage Blob Data Contributor → 読み書き・削除が可能
• Storage Blob Data Owner → すべての権限（アクセス管理もできる）
もし、データの読み書き・削除をしたい場合は、Storage Blob Data Contributor を付与すれば解決します。
PortalとかStorage Explorer ではアクセスできる理由
「でも、PortalとかAzure Storage Explorer では普通にアクセスできるんだけど？」
と思うかもしれません。
これは、PortalやStorage Explorer が Azure Entra ID 以外の認証方法 もサポートしているためです。
具体的には、ストレージアカウントのアクセスキーを使って認証している からです。
実は、Contributor（共同作成者）ロールには、アクセスキーの取得権限があります。
そのため、Storage Explorer では Entra ID 認証が失敗しても、アクセスキーを使ってストレージにアクセスできる のです。
Storage Explorer の認証方法
1. Azure Entra ID（RBAC）認証
• これが失敗すると、RBAC のロール設定の問題
2. アクセスキー認証
• ストレージアカウントの「アクセスキー」を使ってフルアクセス可能
3. SAS トークン認証
• 特定のアクセス権限と有効期限を設定したトークンを使用
Storage Explorer の動作パターン
• Entra ID 認証が成功 → AzureDefaultCredential と同じ動作
• Entra ID 認証が失敗 → アクセスキー or SAS トークン認証に切り替える
そのため、Contributor（共同作成者）ロールだけを持っている状態では、
AzureDefaultCredential を使う Python コードでは権限不足エラーが出る 一方で、
Storage Explorer ではアクセスキー認証が使われるため、問題なくアクセスできる というわけです。
まとめ
✅ AzureDefaultCredential は Entra ID（旧 Azure AD）を使うため、RBAC の設定が重要
✅ AzureDefaultCredential を使う場合は、Contributor（共同作成者）ロールでは Blob データ操作はできない。
✅ AzureDefaultCredential を使う場合は、Storage Blob Data Contributor など適切なロールがContributor（共同作成者）ロールがあっても必要。
✅ Storage Explorer もPortalと同じように アクセスキーで認証している。
✅ Python（他の言語でも） でAzureDefaultCredential を使って Blob Storage にアクセスするには、RBAC を適切に設定する。