Azure ポータルにサインインしようとしたら「AADSTS16000: User account … from identity provider ‘live.com’ does not exist in tenant …」が出て、テナントに入れない。外部ユーザー（#EXT#）を内部ユーザーへ変換した直後に起こりやすい落とし穴です。原因の仕組み、最短での復旧手順、サポートにつなぐ代替ルート、再発防止の実務ポイントをまとめます。
Azure テナントに入れないときに最初に確認すること
まずは「本当にテナントへ入れないのか」「ブラウザのセッション／別アカウントに引っ張られているだけなのか」を切り分けます。Azure ポータルは一度サインインすると、同じブラウザ内で別アカウントの情報が残っていることがあり、想定外のテナントに誘導されるケースが多いです。
- Edge / Chrome の プライベート（InPrivate / シークレット）で portal.azure.com を開き直す
- 一度「別のアカウントを使用する」を選び、意図したアカウントで入り直す
- それでもだめなら、キャッシュ・Cookie を削除して再試行する
上記は「アカウント自体が壊れている」ケースでも意味があり、後述する “正しいサインイン ID に切り替える”手順が確実に効く状態を作れます。
エラー AADSTS16000 の意味（結論：そのテナントにそのユーザーがいない）
今回のメッセージの核は、次の部分です。
AADSTS16000: User account 'xxx' from identity provider 'live.com'
does not exist in tenant 'yyy' and cannot access the application ...AADSTS16000 は Microsoft Entra の STS が返す認証エラーで、要点は「指定されたテナントに、その ID プロバイダー（例：live.com）のユーザーが存在しないのでトークンを発行できない」です。エラーメッセージ上でも「外部ユーザーとして追加してから、別の Microsoft Entra ユーザーでサインインし直す」趣旨が明記されています。
ここで重要なのが identity provider ‘live.com’ の部分です。これは多くの場合、個人用 Microsoft アカウント（MSA：Outlook.com / Hotmail / 旧 Live ID など）でサインインしていることを示します。つまり、あなたは “組織の Entra テナントに存在するアカウント” ではなく、“個人アカウントとしてのあなた” で入ろうとしている可能性が高い、ということです。
なぜ「外部ユーザー→内部ユーザー変換」でロックアウトしやすいのか
このトラブルは、次の条件が揃うと発生しやすくなります。
- Azure テナントを 個人用 Microsoft アカウント（MSA）で作成していた
- Entra ID 上では、そのアカウントが 外部ユーザー（B2B）として扱われていた
- しかもテナント内に 管理者がその 1 ユーザーしかいない
- そのユーザーを「外部ユーザー」から「内部ユーザー」へ変換した
Microsoft Entra の B2B（外部コラボレーション）では、外部ユーザーはテナント内に “ユーザーオブジェクト” は作られますが、サインイン自体は外部の ID プロバイダー（Microsoft アカウント、google.com など）で行われます。外部ユーザーの UPN は、メールアドレスをベースにした文字列＋#EXT#＋tenantname.onmicrosoft.com という形式になるのが一般的です。
| 用語 | よくある見え方 | ポイント |
|---|---|---|
| 個人用 Microsoft アカウント（MSA） | [email protected] / [email protected]（Microsoft アカウントとして登録） | 認証元が live.com になりやすい |
| 外部ユーザー（B2B ゲスト／外部メンバー） | UPN が user_domain.com#EXT#@tenant.onmicrosoft.com のような形 | サインインは外部 ID で行う（テナントがパスワードを管理しないことが多い） |
| 内部ユーザー（メンバー） | [email protected] / [email protected] | 認証は “そのテナントで” 行う（パスワードや MFA をそのテナントで持つ） |
そして「外部ユーザーを内部ユーザーに変換」すると、認証の前提が変わります。Microsoft のドキュメントでも、外部→内部変換では UPN とパスワードを指定して、ユーザーがそのテナントで認証できる状態にすることが説明されています。つまり、変換後は “外部 ID（MSA など）で入るユーザー” ではなく “そのテナントのローカル（内部）で入るユーザー” に切り替わります。
このとき、本人が従来どおり 元の MSA（[email protected] など）で Azure ポータルに入ろうとすると、STS から見ると「そのテナントに live.com のユーザーは存在しない」扱いになり、AADSTS16000 が出ます。ここがロックアウトの正体です。
変換前後で何が変わったのか（外部ユーザー→内部ユーザー）
「外部ユーザー→内部ユーザー変換」は、見た目以上に “ログインの前提” を切り替えます。混乱しやすいポイントを表にまとめます。
| 項目 | 変換前（外部ユーザー） | 変換後（内部ユーザー） | 影響 |
|---|---|---|---|
| 認証元 | 外部 ID（例：Microsoft account / google.com） | テナントのローカル認証（Microsoft Entra ID） | 今までの「いつものアカウント」で入れなくなる |
| サインイン ID（UPN） | #EXT# を含む形になりやすい | @tenant.onmicrosoft.com / 独自ドメインなど | ポータルに入るときに “入力するID” が変わる |
| パスワード | 外部側で管理（テナントでは持たないことが多い） | 変換時に指定／生成（テナント側で管理） | 「変換後のパスワード」が必要 |
| MFA | 外部側の MFA か、そもそも未登録 | 変換後アカウントで MFA 登録が求められる可能性 | 初回サインインで追加手順が出る |
特に「テナント内にユーザーが 1 人しかいない」状態で変換すると、正しい UPN／パスワードを控えていないだけで詰みます。変換を操作した本人でも、外部ユーザーの感覚で「いつもの MSA で入ればいい」と思い込むと、今回のような AADSTS16000 に繋がります。
最短で復旧する手順（実際に効くルート）
結論から言うと、復旧の本筋はシンプルです。“今テナントに存在している内部ユーザーの UPN でサインインし直す”。これで Azure ポータルへのアクセスが戻る可能性が高いです。
サインイン前の準備（ブラウザの罠を排除）
- Edge なら InPrivate、Chrome ならシークレットで portal.azure.com を開く
- 表示されるアカウント候補があっても、必要なら「別のアカウントを使用する」を選択
- 過去のセッションが残っていそうなら、通常モードのブラウザでは Cookie/キャッシュを削除してから再試行
サインインに使う ID を切り替える
サインイン画面で、これまで使っていた [email protected]（個人用 Microsoft アカウント）ではなく、変換後に作られた（または指定した）内部ユーザーの UPNでサインインします。例：
- 変換前に使っていた（MSA）：[email protected]
- 変換後に存在する（内部ユーザー）：[email protected]
「内部ユーザーの UPN がわからない」場合は、変換作業の途中で指定した値が必ずどこかに残っているはずです（画面の控え、運用メモ、パスワード管理ツール、チケットなど）。テナントに入れない状態だと確認手段が極端に減るので、ここは “記録を探す” が最短になります。
パスワードでサインイン（必要ならリセット）
内部ユーザーに紐づくパスワードでサインインします。変換時に「自動生成パスワード」を選んだなら、そのパスワードを参照して入力します。パスワードが不明な場合、テナント側の設定によっては「パスワードを忘れた場合」から自己リセットが可能です（ただし、自己パスワードリセットの可否はテナントの構成に依存します）。
MFA（多要素認証）の登録を完了する
初回サインイン時に MFA 登録が求められることがあります。ここで “後でやる” を選べない構成のテナントもあるため、スマホの Authenticator アプリや電話番号など、すぐ登録できる手段を用意しておくと復旧が早いです。
サインイン後にやるべきこと（再発防止も兼ねる）
- 元の個人用 Microsoft アカウントを B2B 外部ユーザーとして招待し直す（必要な場合）
- グローバル管理者などの管理ロールを 複数アカウントに割り当てる
- 緊急用（ブレークグラス）アカウントを用意し、資格情報を安全に保管する
サインインできても「サブスクリプションが見えない」場合の追加チェック
サインインが通っても、No subscriptions found（サブスクリプションが見つからない）や、何も表示されない状態になることがあります。これは “テナントは合っているが権限がない／ディレクトリが違う” パターンです。Microsoft のトラブルシュートでも、ディレクトリ選択ミスや権限不足で同様の症状が出ることが説明されています。
- 右上のアイコンから ディレクトリの切り替え（Switch directory）を確認する
- 「ディレクトリ + サブスクリプション」フィルターで、目的のディレクトリが選択されているか確認する
- サブスクリプションに対する RBAC（Owner/Contributor 等）が付与されているか確認する
なお、サポート リクエストの作成には権限要件があります。サブスクリプションに紐づくサポートの場合、基本的に Owner / Contributor / Support Request Contributor などの権限が必要で、サブスクリプションを指定しない（例：Entra のみの問い合わせ）場合でも “Admin 権限” が必要とされています。
「テナントに入れないのでサポート リクエストも出せない」時の現実的な対応手段
ここが一番つらいポイントです。Azure ポータルの「サポート + トラブルシューティング」はログイン前提なので、そもそも入れないと詰みやすい。そこで、実務的には “ルートを複線化” します。
別管理者アカウントで入って復旧する（最優先）
もしテナント内に別の管理者（グローバル管理者、ユーザー管理者、課金管理者など）が存在するなら、そのアカウントでサインインし、あなたのアカウントを回復させるのが最短です。今回のケースは「唯一のユーザー」だったため難しいのですが、今後は必ず複数管理者を用意してください。
課金・サブスクリプション系の窓口からつなぐ
Azure のサポートは、課金・サブスクリプション管理（Billing / Subscription management）については全顧客向けに用意され、技術サポートはサポートプランが必要、という整理がされています。テナントロックアウトは “技術” と “アカウント/サブスク” の境界に跨るため、入口としては課金・サブスク系の窓口から相談したほうが話が進みやすいことが多いです。
契約形態が CSP の場合は、まず販売パートナーへ
Azure を CSP（Cloud Solution Provider）経由で購入している場合、一次窓口は Microsoft ではなく販売パートナーになることがあります。サポート プランの有無や契約形態によって “どこが受付できるか” が変わるので、請求書や契約情報を見て購入ルートを確認してください。
コミュニティ（Microsoft Q&A）で状況整理をしておく
緊急度が高いほど、問い合わせ時に “何をいつやったか” を短時間で説明できるかが勝負になります。Microsoft Q&A などで状況を文章化しておくと、後でサポートに出すときにそのまま流用でき、抜け漏れが減ります（機密情報は伏せる）。
手段別の使い分け早見表
| 状況 | 最短の手段 | 準備しておく情報 |
|---|---|---|
| 内部ユーザーの UPN とパスワードがわかる | その UPN で Azure ポータルにサインイン | UPN、パスワード、MFA 登録手段 |
| UPN はわかるがパスワードが不明 | 自己リセット（可能なら）／別管理者にリセット依頼 | 回復用メール/電話、別管理者の有無 |
| 管理者が他にいない・入れない | 課金/サブスク窓口、購入ルート（CSP/EA）経由でエスカレーション | テナント名、テナントID、サブスクID、請求情報、ドメイン所有の証跡 |
再発防止：唯一の管理者を作らない（ブレークグラスの考え方）
今回の事故の本質は「外部→内部変換」そのものより、“唯一の管理者アカウントに依存していた”ことです。対策はシンプルで、次の 3 点を徹底するとロックアウト事故が激減します。
- 管理者アカウントを複数用意：最低でも 2 つ（できれば 3 つ）
- 管理者の種類を分ける：日常運用用／緊急用（ブレークグラス）
- サインイン手段も分散：MFA のデバイスや回復手段を別々に
ブレークグラスは “使わないために作る” アカウントです。普段はログインしない前提で、資格情報を金庫やパスワードマネージャーに保管し、緊急時だけ使えるようにしておくのが王道です。
外部ユーザーを内部ユーザーに変換する前にやるべき安全手順
今後同じ操作をする人のために、実務で事故りにくい手順を残します。
- 変換対象とは別に、内部の管理者アカウントを新規作成してサインインできることを確認
- 管理者ロールを複数アカウントに割り当て、少なくとも 1 つは “変換の影響を受けない” 形で残す
- 変換作業では、新しい UPN とパスワードを確実に記録（自動生成なら保存場所を明確化）
- 変換後、新しい UPN でサインインできることを確認してから、元の外部アカウントの扱いを決める
- 必要なら元の MSA を B2B 招待し直し、役割付与は段階的に行う
Microsoft のドキュメントでも、外部ユーザー変換はテストアカウントで検証することが推奨されています。特に本番テナントで “唯一の管理者” をいじるのはリスクが高いので、必ず事前に回避策を用意してから実施してください。
よくある質問
内部ユーザーに変換したのに、元の MSA（[email protected]）で入れません。壊れましたか？
壊れたというより、サインインしようとしている “人格” が違います。変換後は内部ユーザー（テナントのローカル認証）の UPN で入る必要があります。元の MSA を使いたい場合は、改めて B2B 外部ユーザーとして招待し直す、という方針が現実的です。
#EXT# を消してスッキリさせたいのですが？
#EXT# は B2B 外部ユーザーの UPN が “外部ユーザー由来” であることを表す目印の一つです。見た目が気になっても、いきなり UPN だけを変えようとすると認証やアプリ連携に影響が出ることがあります。外部ユーザーの扱いを変えたい場合は、まず “外部で認証するユーザーなのか／内部で認証させたいのか” を整理し、必要なら公式の変換手順に沿って進めるのが安全です。
サポートに連絡するとき、何を伝えると話が早い？
ロックアウト系は、本人確認やテナント特定のための情報が重要です。最低限、次を準備しておくとスムーズです。
- テナント名（xxx.onmicrosoft.com）と可能ならテナント ID
- サブスクリプション ID（請求書やメールから辿れることが多い）
- 課金情報（請求先、支払い方法の末尾など）
- 操作の時系列（いつ外部→内部に変換したか、どの画面で何を変更したか）
コメント