Gmailアドレスで作成したAzureサブスクリプションで、Key Vaultにロール割り当てをしようとしたらMissingSubscriptionで失敗し、さらに「ゲスト」から「メンバー」へ変更した結果サインインできなくなった――この2つは、実は“テナント（ディレクトリ）とアカウント種別のズレ”が引き金になって連鎖的に起きがちです。この記事では、まずAzure環境へのアクセスを取り戻す手順から、Azure CLIでのコンテキスト固定、Key VaultのRBAC/アクセス ポリシー確認、適切なロール選定までを具体的に整理します。
今回の症状を整理する（何が起きているか）
状況をまとめると、次の2系統の問題が同時に発生しています。
| 困りごと | 表面上の症状 | よくある根本原因 | 最初に見るべきポイント |
|---|---|---|---|
| Azureに入れない | サインインできない／サブスクが見えない | MSA（個人Microsoftアカウント）とEntra ID（旧Azure AD）のユーザー種別・所属テナントが噛み合っていない | 「個人アカウント」でログインしているか、正しいディレクトリに切り替えているか |
| Key Vaultのロール割り当てができない | MissingSubscription エラー | Azure CLIが別テナント／別サブスクリプションを見ている、またはスコープ・権限・プロバイダー登録が不整合 | az account show のtenantIdとid（subscriptionId）が意図どおりか |
大前提：Gmailで作ったAzureは「個人のMicrosoftアカウント（MSA）」になりやすい
GmailアドレスでAzureを始めると、Microsoft側ではそのメールが個人のMicrosoftアカウント（MSA）として扱われることが多いです。ここがポイントで、Azureの「ディレクトリ（テナント）」と「サブスクリプション」の関係が、職場/学校アカウント（Entra IDのメンバー）とは挙動が異なります。
- MSA（個人アカウント）：Outlook.comだけでなく、Gmailなどでも作成できる。Azureポータルのサインイン画面では「個人アカウント」を選ぶ必要があることがある。
- Microsoft Entra ID（旧Azure AD）テナント：組織ディレクトリ。ここに“メンバー”として存在するユーザーは「組織アカウント（職場または学校）」としてログインする。
- ゲスト（外部ユーザー）：MSAや他テナントのユーザーが、特定テナントに招待されて入ってくる形。Gmail由来のアカウントはこの形になりやすい。
今回の「外部アカウント（ゲスト）→内部アカウント（メンバー）」変更は、テナントの設定やアカウントの実体（MSA）と噛み合わないと、サインイン経路が崩れてロックアウトに見える状態を起こしやすくなります。まずは、ロール割り当て以前に、管理できる入口（ログイン）を取り戻すのが最優先です。
最優先：サブスクリプションへのアクセスを取り戻す（ログイン復旧の実務手順）
サインイン方法を「個人のMicrosoftアカウント」に寄せて試す
ポータルに入れないと、テナント切替も権限確認もできません。まず、サインイン画面で次の点を意識します。
- メールアドレス（Gmail）を入力した後、アカウント選択が出たら「個人アカウント」側の導線を選ぶ
- 「職場または学校アカウント」で入ろうとしていないか確認する
- ブラウザのプロファイルを分ける（別プロファイル/シークレットウィンドウで試す）
サインインできたら必ず「ディレクトリ（テナント）」を切り替える
「ログインできたのにサブスクリプションが見えない」ケースは、別ディレクトリを見ていることが非常に多いです。Azureポータルの右上アカウントメニューから「ディレクトリ + サブスクリプション」を開き、サブスクリプションが属しているディレクトリへ切り替えます。
| よくある状態 | 画面の見え方 | 対処 |
|---|---|---|
| 別ディレクトリを参照 | サブスクが0件、リソースが何もない | 「ディレクトリ + サブスクリプション」で正しいディレクトリへ切替 |
| ゲストとして入っている | ユーザー種別にGuest/外部が混在 | ゲストのままでも運用可能。無理にメンバー化しない方が安全なことが多い |
| 権限が欠けている | サブスクは見えるがIAM操作ができない | OwnerまたはUser Access Administratorを付与してもらう（自分がOwnerのはずならログイン経路の見直しが先） |
どうしてもログインできない場合にやること（現実的な順番）
「ゲスト→メンバー」変更後にサインインできない場合、原因が“資格情報の問題”なのか“ディレクトリとサインイン経路の問題”なのかが混ざります。実務では次の順で切り分けるのが速いです。
- アカウント回復フロー（パスワード再設定、本人確認）を試す
- ブラウザを変える／端末を変える／シークレットで試す（キャッシュ・セッション要因を排除）
- Azure CLIで
az loginして、少なくともトークン取得とテナント情報の確認ができるか試す - それでも詰む場合は、Azureサポートに「サブスクリプション所有者だがログイン不能」として復旧を依頼（サブスクリプションと本人性を示す情報を揃える）
なお、サポートに伝えるときは次を短くまとめると通りやすいです。
- Gmailで作成したAzureサブスクリプション（MSA起点）であること
- テナント側でユーザー種別を変更したこと（ゲスト→メンバー）
- その後、サインインできずサブスクリプションOwnerであっても管理できないこと
- サブスクリプションID、テナントID、作成日時、課金情報（可能な範囲で）
復旧できたら最初にやる「再発防止の基盤作り」
同じ事故を繰り返さないために、復旧直後にやるべきことを“運用の型”として固定します。
| やること | 狙い | 具体例 |
|---|---|---|
| テナント専用の管理者ユーザーを作る | MSA依存を減らし、テナント内の正規ルートを確保 | admin@<tenant>.onmicrosoft.com のクラウドユーザー |
| 管理者に強い権限を付与 | RBACや設定変更が詰まらないようにする | （テナント）全体管理者、（サブスク）OwnerまたはUser Access Administrator |
| MSA（Gmail）は“バックアップ経路”として残す | 入口の冗長化 | ゲストのままOwnerを保持（テナントポリシー次第） |
| MFAと復旧手段の整備 | ロックアウト耐性を上げる | 認証アプリ、予備メール、複数管理者 |
MissingSubscriptionの正体：Azure CLIが「別の世界」を見ている
MissingSubscriptionは、単純に「サブスクリプションIDが間違っている」だけでなく、CLIが参照しているテナント/サブスクリプションがズレているときに出やすいエラーです。特にMSA/ゲストが絡むと、ログインできているように見えても、CLI側の既定コンテキストが別テナントに寄っていることがあります。
実務でよくある原因は次のとおりです。
- CLIが別テナントでログインしている（
tenantIdが違う） - CLIの既定サブスクリプションが違う（
az account setしていない） - スコープ（Key VaultのID）が不完全（フルリソースIDになっていない）
- 割り当てを実行する権限が不足（Owner/User Access Administratorではない）
- リソースプロバイダー未登録（まれに
Microsoft.Authorizationなど） - ゲストへの割り当て制限（テナント設定で外部ユーザーの管理が厳しい）
Azure CLIで「テナント」と「サブスクリプション」を固定する（最重要）
ロール割り当て作業は、まずCLIのコンテキストを固定してから実行します。MSA/ゲスト混在環境では、ここを曖昧にすると高確率でハマります。
基本の固定手順（テンプレ）
# いったんログアウト（複数アカウントの残骸を消す意図）
az logout
# 対象テナントを明示してログイン
az login --tenant
# サブスクリプション一覧で「見えているか」を確認
az account list -o table
# 使うサブスクリプションを明示的に選択
az account set --subscription
# 最終確認（ここがズレていると全て崩れる）
az account show --query "{subscription:id, tenant:tenantId, user:user.name}" -o jsonよく使う確認コマンド早見表
| 目的 | コマンド | 見どころ |
|---|---|---|
| 現在のコンテキスト確認 | az account show | tenantId と id（subscriptionId）が意図どおりか |
| 利用可能なサブスク一覧 | az account list -o table | 目的のサブスクが一覧に出るか（出ないなら権限かテナントが違う） |
| テナントを切り替えてログイン | az login --tenant <tenant-id> | MSA/ゲストが絡むと必須級 |
| サブスクを明示 | az account set --subscription <subscription-id> | 以降の操作の“世界”が決まる |
スコープの落とし穴：Key VaultのIDは「フル リソースID」で指定する
--scopeにはKey VaultのフルリソースID（ARM ID）を指定する必要があります。文字列を手打ちするとミスしやすいので、CLIから取得して変数に入れるのが安全です。
# Key VaultのリソースIDを安全に取得
KV_ID=$(az keyvault show -n <keyvault-name> -g <resource-group> --query id -o tsv)
# 取得できているか確認
echo "$KV_ID"フルリソースIDは次の形式です。
/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/<key-vault-name>もし$KV_IDがこの形式になっていない場合、そもそも別サブスクリプションを見ているか、Key Vaultが別の場所に作られている可能性があります。先にaz account showへ戻ってコンテキストを確認してください。
付与先（assignee）の落とし穴：ゲストはObject IDが想像と違う
ロール割り当ての付与先指定は、運用上のハマりどころです。特にGmail起点のユーザーはテナント内でゲスト扱いになりやすく、同じメールでもテナント上のObject IDが別物になりがちです。
おすすめは「まずメールで試す」→ダメならObject IDを確定
状況によっては--assignee-object-idよりも、メールで--assignee指定した方が、CLIが正しく解決できることがあります。
# メールで指定（解決できるならこれが一番楽）
az role assignment create \
--role "Key Vault Administrator" \
--assignee "[email protected]" \
--scope "$KV_ID"解決できない場合は、Object IDを“そのテナント上のユーザー”として確実に取得します。ゲストはUPNが特殊になることがあるため、メール検索やフィルタ検索が有効です。
# サインイン中ユーザー（自分）ならこれが手っ取り早い
USER_ID=$(az ad signed-in-user show --query id -o tsv)
# 確認
echo "$USER_ID"もし「自分ではなく別ユーザーに付与したい」「ゲストのObject IDを取りたい」という場合は、テナントのディレクトリ上で該当ユーザーがどう登録されているか（Guest/Member、UPN表記）を確認し、CLI検索条件を合わせます。
付与先指定の使い分け表
| 指定方法 | 例 | 向いている場面 | 注意点 |
|---|---|---|---|
| メールで指定 | --assignee [email protected] | 単純に自分（または既知のユーザー）へ付与したい | テナント上で解決できないと失敗（ゲストの表記ゆれに注意） |
| Object IDで指定 | --assignee-object-id <guid> | 確実に“そのテナントのそのユーザー”に割り当てたい | 取得元のテナントがズレると別人に付与しうる |
| サービスプリンシパル | --assignee <appId> | 自動化（CI/CD、GitHub Actions等） | 人のアカウントで運用しない設計にすると事故が減る |
ロール割り当てに必要な権限：OwnerかUser Access Administratorが要る
Key Vaultスコープにロールを割り当てるには、割り当てを実行する主体にロール割り当てを書き込める権限が必要です。一般に次のどちらかが必要になります。
- 所有者（Owner）
- ユーザー アクセス管理者（User Access Administrator）
「自分はサブスクリプションOwnerのはずなのに割り当てできない」場合、よくあるのは次のどちらかです。
- 実はCLI/ポータルで見ているテナント・サブスクが違う
- Ownerが付いているのは“別のアカウント（別のユーザー実体）”で、今ログインしているのは別物
まずは自分の割り当て状況を確認します。
# 自分に付与されているロールをサブスク範囲で確認（例）
az role assignment list \
--assignee $(az ad signed-in-user show --query id -o tsv) \
--scope /subscriptions/<subscription-id> \
-o tableプロバイダー登録：Microsoft.Authorizationが未登録だと詰むことがある
頻度は高くありませんが、サブスクリプション側でリソースプロバイダーの登録が未完了だと、RBAC操作で予期しないエラーになることがあります。念のため、Microsoft.Authorizationの状態を確認します。
az provider show --namespace Microsoft.Authorization --query "registrationState" -o tsv
# NotRegisteredなら登録
az provider register --namespace Microsoft.Authorization同様にKey VaultならMicrosoft.KeyVaultも確認しておくと安心です。
az provider show --namespace Microsoft.KeyVault --query "registrationState" -o tsv
az provider register --namespace Microsoft.KeyVaultKey Vaultは「RBACモード」か「アクセス ポリシー モード」かで手順が分かれる
Key Vaultのアクセス制御には大きく2種類あります。
- RBAC（Azureロールベース）：
az role assignmentで制御する - アクセス ポリシー（従来方式）：Key Vaultのアクセスポリシーで制御する
ここを取り違えると、「ロール割り当てはできたのにシークレットが触れない」「逆にロール割り当てを頑張っても意味がない」状態になります。まずは現在のモードを確認します。
az keyvault show -n <keyvault-name> -g <resource-group> \
--query "properties.enableRbacAuthorization" -o tsv| モード | 確認値 | 設定の基本 | ハマりポイント |
|---|---|---|---|
| RBACモード | true | IAM（ロール割り当て）でデータ操作権限も管理 | 付与するロールを間違えると「Vault管理はできるがシークレット操作できない」などが起きる |
| アクセス ポリシー | false | Key Vaultの「アクセスポリシー」でシークレット/キー/証明書の権限を付与 | ロール割り当てをいくら作ってもデータプレーンの許可にならないことがある |
今回のエラーはロール割り当て作成時点で落ちているため、まずはRBAC操作（管理プレーン）を通すのが先ですが、復旧後はKey Vaultのモード確認も必ずセットで行ってください。
目的別：Key Vaultでよく使うロールの選び方（最小権限が基本）
Key Vaultは「Vault自体の管理（ネットワーク、設定）」と「中のデータ操作（シークレット読み書き）」が分離して考えられます。必要以上に強いロールを付けると事故の半径が増えるので、目的に合わせて選びます。
| やりたいこと | 推奨ロール | できること（ざっくり） | 向いている利用者 |
|---|---|---|---|
| シークレットの作成・更新・削除・一覧（運用担当） | Key Vault Secrets Officer | シークレットの管理操作が中心 | アプリ運用、SRE、運用自動化 |
| シークレットの読み取り（参照だけ） | Key Vault Secrets User | 読み取り主体 | アプリ実行環境、参照のみのユーザー |
| Vaultの設定・アクセス制御も含めた管理 | Key Vault Administrator | Vault全体の管理（強い） | 基盤管理者（必要最小人数に限定推奨） |
| 参照（管理情報） | Reader | リソース閲覧 | 監査、参照のみ |
「シークレットを書き込むだけ」が目的なら、まずはKey Vault Secrets Officerで足りるケースが多いです。Vault全体の管理が必要なときだけKey Vault Administratorを使うのが安全です。
MissingSubscriptionを潰す“実務向け”修正版コマンド例
ここまでのポイントを踏まえ、最小限の“事故りにくい”流れを例としてまとめます。変数名はそのまま流用できるようにしています。
# 事前に埋める
TENANT_ID="<tenant-id>"
SUBSCRIPTION_ID="<subscription-id>"
RG_NAME="<resource-group>"
KV_NAME="<keyvault-name>"
ASSIGNEE_EMAIL="[email protected]" # まずはメールで試す
# コンテキスト固定（ここが最重要）
az logout
az login --tenant "$TENANT_ID"
az account set --subscription "$SUBSCRIPTION_ID"
az account show --query "{subscription:id, tenant:tenantId, user:user.name}" -o json
# Key VaultのフルID取得（手打ちしない）
KV_ID=$(az keyvault show -n "$KV_NAME" -g "$RG_NAME" --query id -o tsv)
echo "$KV_ID"
# Key VaultがRBACモードか確認（trueならRBACでデータアクセスも管理）
az keyvault show -n "$KV_NAME" -g "$RG_NAME" --query "properties.enableRbacAuthorization" -o tsv
# まずは目的に合わせて最小権限ロールを付与（例：シークレット運用）
az role assignment create \
--role "Key Vault Secrets Officer" \
--assignee "$ASSIGNEE_EMAIL" \
--scope "$KV_ID"もしメール指定で解決できない場合は、自分（サインインユーザー）のObject IDで試して「CLIの世界でユーザー解決できるか」を先に確定します。
USER_ID=$(az ad signed-in-user show --query id -o tsv)
az role assignment create \
--role "Key Vault Secrets Officer" \
--assignee-object-id "$USER_ID" \
--assignee-principal-type User \
--scope "$KV_ID"それでもMissingSubscriptionが出る場合は、ほぼ確実に次のどれかです。
az account showのtenantIdやsubscriptionが意図と違う- 目的のサブスクリプションが
az account listに出ていない（権限がない／別アカウント実体） - スコープ
$KV_IDが期待するサブスクリプション配下になっていない
「ゲストにロールを付けられない」パターン：テナントの外部ユーザー設定を疑う
Gmail起点のユーザーはゲスト扱いになりやすいため、テナントのセキュリティ設定次第では、ゲストへの管理系ロール付与が制限される場合があります。現場では次の方針が安定します。
- ゲストに強いロールを付ける前に、テナント内のクラウドユーザー（メンバー）を管理用に作る
- どうしてもゲストに付与したい場合は、外部コラボレーション設定やゲスト権限の制限ポリシーを確認する
特に「運用を継続する意思がある環境」なら、管理者はテナント内ユーザーに寄せた方が、将来的な認証トラブルや権限事故を大幅に減らせます。
再発防止の設計：個人MSAで作ったAzureを“壊れにくく”運用する
今回のような事故は、「入口が1つ」「入口がMSA」「テナント内の管理者がいない」が重なると起きやすいです。おすすめの最小構成は次のとおりです。
| 役割 | 推奨アカウント | 付与ロール（例） | 狙い |
|---|---|---|---|
| 基盤管理（ブレークグラス） | テナント内クラウドユーザー（メンバー） | 全体管理者 + サブスクOwner | 最悪のときに必ず入れる入口 |
| 日常管理 | テナント内クラウドユーザー（メンバー） | Owner または User Access Administrator | RBAC操作の安定 |
| 個人MSA（Gmail） | ゲスト（必要なら） | 必要最小限（できれば強権限は避ける） | バックアップ経路（ただし依存しない） |
| 自動化（CI/CD） | サービスプリンシパル/マネージドID | Key Vault Secrets User/Officer等 | 人のログイン問題から切り離す |
さらに安全側に倒すなら、Key Vaultの運用は「人が手で触る」より、マネージドIDに必要最小権限を付けてアプリからアクセスへ寄せるのが堅いです。人のアカウント（MSA/ゲスト）に依存するほど、認証・ディレクトリ切替・ポリシー変更で詰みやすくなります。
よくある質問（詰まりやすい所だけ）
サブスクリプションが“存在しない”ように見えるのはなぜ？
多くの場合、別ディレクトリを見ているか、別アカウント実体でログインしているのが原因です。ポータルでは「ディレクトリ + サブスクリプション」を必ず確認し、CLIではaz account showでtenantIdとsubscriptionを確定させてください。
ゲストをメンバーに変えれば解決する？
短期的に解決することもありますが、MSA起点だと逆に壊れることがあります。運用としては、テナント内のメンバー（クラウドユーザー）を管理用に新規作成し、そこに管理権限を寄せる方が安全です。
Key Vault Administratorを付ければ何でもできる？
強いロールではありますが、Key Vaultがアクセス ポリシー方式の場合、データアクセスの許可は別経路になることがあります。必ずenableRbacAuthorizationを確認し、モードに合った権限付与を行ってください。
まとめ：解く順番を間違えない
- 最初にやるべきはAzure環境に入れる状態を取り戻すこと（個人MSAでのサインイン、ディレクトリ切替）
MissingSubscriptionは、ほとんどがCLIのテナント/サブスクのズレで起きる。az login --tenantとaz account setで固定する--scopeはKey VaultのフルリソースIDを使い、手打ちを避ける- 付与先はまず
--assignee（メール）で試し、ダメならテナント上のObject IDを確定する - 再発防止には、MSA依存を減らし、テナント内の管理者ユーザー（メンバー）を作って運用の入口を冗長化する
コメント