Azure ポータルで検証中に個人 Microsoft アカウント（MSA）を Entra ID テナントへ追加したら、表示が #EXT# になり「個人アカウントは使えない」と出てサインインできない…。さらに MFA の桁数まで合わず詰む原因と復旧手順を、管理者がいる場合／いない場合で整理します。
起きている現象を「症状」と「状態」に分解する
このトラブルは、単に「サインインできない」だけではなく、複数の要素が同時に発生していることが多いです。まずは症状を分解して、何が起きているかを言語化すると復旧が早くなります。
よくある症状
- Azure ポータル（portal.azure.com）でアプリ検証中に、個人 Microsoft アカウントをテナントへ追加・招待した
- いつの間にか「別テナント扱い」「権限がないテナントに紐づいた」ような挙動になる
- ユーザー表示が
#EXT#を含む形式になり、外部ユーザー（ゲスト）っぽい見え方に変わる - myaccount.microsoft.com に行くと「ここでは個人アカウントは使えない」と表示されて進めない
- MFA を求められるが、画面が要求するコードが「6 桁」、手元に出るコードが「8 桁」などで一致せずサインイン不能
このとき裏で起きている“状態”
- 個人 Microsoft アカウント（MSA）そのものが壊れたのではなく、「特定テナントにゲストとして招待された“外部ユーザー表現”」になっている
- アクセスしている入口（URL）が「個人用」ではなく「組織用」になっていて、弾かれている
- MFA は“同じ認証アプリ”でも、登録種別（個人／職場学校）や方式（プッシュ／OTP）で桁数や流れが異なり、噛み合わなくなる
| 見えていること | ありがちな原因 | 最優先でやること |
|---|---|---|
| 「個人アカウントは使えない」 | 組織アカウント向けの入口に行っている | 個人用の入口へ切り替える（後述） |
#EXT# になった | テナントにゲスト（外部ユーザー）として存在している | テナント側でゲストの状態と招待のやり直しを確認 |
| MFA の桁数が合わない | 見ているコードが別方式／別アカウントのコード | 管理者に「MFA 再登録」を要求してもらい再設定 |
| 誰も管理者で入れない | テナント ロックアウト（管理者不在） | サポート経由の復旧ルートへ |
最初にやるべき切り分け：アクセス先 URL が違う
「個人 Microsoft アカウントなのに、個人が使えないと言われる」ケースの第一原因は、入口サイトの選択ミスです。ここを直すだけで、表示がガラッと変わることがあります。
| サイト（入口） | 主に対象 | よくある表示 | 使いどころ |
|---|---|---|---|
| account.microsoft.com | 個人 Microsoft アカウント（MSA） | 個人のセキュリティ設定、購入履歴など | MSA の設定・保護状態確認 |
| myaccount.microsoft.com | 職場/学校アカウント（組織アカウント、Entra ID） | 「個人アカウントは使えない」になることがある | 組織アカウントの情報確認 |
| mysignins.microsoft.com/security-info | 職場/学校アカウント（ゲストを含む） | 「セキュリティ情報」登録画面 | MFA 再設定（復旧後に重要） |
チェック手順（最短ルート）
- ブラウザーで一度サインアウトする（Microsoft 365、Azure、GitHub、Teams など Microsoft 系に複数ログインしている場合は特に注意）
- 可能なら「プライベート（InPrivate）/シークレット」ウィンドウを開く
- 個人アカウントの状態確認は account.microsoft.com にアクセスする
- myaccount.microsoft.com で弾かれても、即「アカウントが壊れた」とは判断しない（入口が違うだけの可能性が高い）
この時点で、個人アカウント（MSA）側のセキュリティ情報や復旧用メールなどが正常に見えるなら、MSA 自体の致命的な破損ではなく、テナント側（Entra ID 側）の“外部ユーザーとしての状態”が問題になっている可能性が濃厚です。
#EXT# は異常ではない：外部ユーザー（ゲスト）として招待された表示
#EXT# は、Entra ID テナントに外部ユーザー（B2B ゲスト）として追加されたときに表示されやすい形式です。特に個人 Microsoft アカウント（MSA）を「テナントに招待」した場合、テナント内部の表示名（UPN 風の文字列）が次のように変換されます。
元のメールアドレス_ドメイン#EXT#@テナント名.onmicrosoft.com
重要なのは、これは「あなたの個人アカウントが組織アカウントに変わった」わけではないという点です。あくまで「そのテナントの中で、外部ユーザーとして表現されている」だけです。
| 項目 | 意味 | 困りがちな点 | 基本方針 |
|---|---|---|---|
#EXT# 表示 | ゲスト（外部ユーザー）として存在 | 自分のアカウントが“別物”に見えて混乱 | テナント側でゲストとして整合を取る |
| サインイン画面が組織寄り | テナント（組織）前提のフロー | 個人用 URL では弾かれる／逆もある | 入口 URL を使い分ける |
| MFA が噛み合わない | 別方式／別登録情報を参照 | 6 桁を求められるのに 8 桁しかない等 | 管理者に再登録を要求してもらいリセット |
「ここでは個人アカウントは使えない」が出る典型パターン
表示メッセージそのものは強い言い方ですが、原因は大きく 2 つに分かれます。
パターンA：そもそも入口が“組織用”
myaccount.microsoft.com は、職場/学校アカウント（Entra ID の組織アカウント）向けの入口です。ここで個人アカウント（MSA）を入れようとすると、弾かれることがあります。
パターンB：テナント側のポリシーで“個人の利用”が許可されていないように見える
Entra ID テナントでは、条件付きアクセス（Conditional Access）やセキュリティ既定値など、MFA を含むサインイン条件が設定されます。ゲストであっても、特定のアプリや Azure 管理ポータルにアクセスする際に強制され、しかも手元の MFA 状態が古い／別方式だと「詰み」になりやすいです。
ここで大事なのは、MSA 側で何とかしようとしても解けない問題があることです。なぜなら、詰んでいるのは「テナント側で要求される認証」と「あなたが今提示できる認証」が噛み合っていない状態だからです。
MFA の 6 桁と 8 桁が合わない：何がズレているのか
「6 桁を入れろと言われるのに、アプリには 8 桁しか出ない」などの不一致は、次のどれかが起きている可能性が高いです。
| 画面が求めているもの | 手元にあるもの | 起きがちな状況 | 解決の方向性 |
|---|---|---|---|
| 6 桁のワンタイムパスコード（OTP） | 8 桁のコード | Authenticator アプリで「別の種類のアカウント」用コードを見ている | テナント側で MFA を再登録し、正しい登録に揃える |
| プッシュ通知の承認（番号合わせ/タップ承認） | 時間で変わるコード | 本来はプッシュ方式だが、端末変更や再インストールで通知が届かない | 再登録（もしくは一時的に別手段を追加） |
| SMS/音声の確認 | 認証アプリのコード | 条件付きアクセスで方法が固定されている／以前の方法が消えた | 管理者が認証方法を見直し、再登録を促す |
「同じメールアドレス」でも、Authenticator 内で別物になっていることがある
Microsoft Authenticator には、ざっくり言うと次のような登録のされ方があります。
- 個人 Microsoft アカウント（MSA）としての登録
- 職場/学校アカウント（Entra ID）としての登録（ゲストであっても、テナント側の要求でこちらを使う局面がある）
同じメールアドレスに見えても、テナント側が求めているのが「組織の認証フロー」で、手元で見ているのが「個人のコード」だと、桁数や方式が噛み合わず前に進めません。
ここが分岐点：管理者がテナントに入れるかどうか
復旧の難易度は、これで決まります。まずはテナント内に「別の管理者」が存在するか、存在するならその人がサインイン可能かを確認してください（あなた自身が今サインイン不能でも、他の管理者が入れれば復旧できます）。
| 状況 | 復旧難易度 | 取るべき手段 |
|---|---|---|
| 別の管理者（認証管理者以上／グローバル管理者）が入れる | 低〜中 | 管理者に MFA 再登録要求 → 必要なら招待し直し |
| 自分しかグローバル管理者がいない、誰も入れない | 高 | テナント ロックアウトとしてサポート復旧ルート |
別の管理者がいる場合：最も確実な復旧手順（王道）
このパターンが最短・最確実です。ポイントは「あなたの端末で頑張る」のではなく、テナント側の認証状態を管理者が正してあげることです。
管理者がやること（Entra 管理センター）
- 管理者が Microsoft Entra 管理センター にサインインする
- 対象テナントを選択し、ユーザー（Users）から対象ユーザーを検索する
- 検索のコツ：
#EXT#を含む表示名、元のメールアドレス、表示名（Display name）など複数で試す - 「ゲスト ユーザー」と表示されていることが多い
- 検索のコツ：
- 対象ユーザーの詳細で、認証方法（Authentication methods） を開く
- 「MFA の再登録を要求（Require re-register MFA）」 を実行する
- 可能なら追加で、対象ユーザーのサインイン セッションの無効化（Revoke sessions）も実行する（古いトークンを捨てて再認証させる）
これで次回サインイン時に、ユーザーは MFA を再設定し直せるようになります。MFA の桁数不一致は、この「再登録」で解消することが非常に多いです。
それでもダメな場合：招待（Invite）をやり直す
#EXT# が付いたゲストユーザーは、招待の履歴や“受諾状態”が中途半端になっていると、ログインが変な方向へ誘導されることがあります。その場合は、次のどちらかを検討します（運用や影響範囲で選びます）。
| 手段 | やること | 向いている状況 | 注意点 |
|---|---|---|---|
| 同一ユーザーの招待を再送（可能なら） | 招待メールを再送し、受諾をやり直す | まだ削除したくない／権限付与が複雑 | UI や設定によって再送の見え方が違う |
| ゲストを削除 → 外部ユーザーとして再招待 | 古いゲストを削除し、新しく Invite External User | とにかく早く正常化したい | 割り当て済みの権限・グループが消える可能性があるため、事前に控える |
特に「テスト用に追加しただけ」で、複雑な権限付与がないなら、削除→再招待が最短になることが多いです。
今回の着地点として多い解決パターン
- テナント内に別のグローバル管理者ユーザーが存在し、そのアカウントでテナントへアクセスできた
- 対象の個人 Microsoft アカウントを外部ユーザーとして再招待（Invite External User）し直した
- 復旧後、Azure サインイン用のMFA を再設定して解消した
この流れは「詰み」状態に見えても、管理者がテナント側の認証を整えるだけであっさり直ることがある、代表例です。
自分しかグローバル管理者がいない場合：テナント ロックアウトの考え方
もし「自分が唯一のグローバル管理者」かつ「自分が MFA で詰んで入れない」状態なら、これは実質的に テナント ロックアウトです。こうなると、公開情報だけで本人確認や権限回復を完結させることはできません。
このケースで重要なのは、遠回りでも次の方針を取ることです。
- ブラウザーや端末を変えても根本解決はしない（認証要求がテナント側にあるため）
- 復旧はMicrosoft のサポートルートに乗せる必要がある
- サポートをスムーズにするため、事前に情報を整理する
サポートに回す前に整理しておくとよい情報
| 情報 | 例 | なぜ必要か |
|---|---|---|
| テナント名／初期ドメイン | xxxxx.onmicrosoft.com | 対象テナントの特定 |
| テナント ID（分かれば） | GUID 形式 | サポート側の確認が早い |
| 影響範囲 | Azure ポータルに誰も入れない等 | 緊急度の判断 |
| 最後にサインインできた日時（目安） | ○月○日ごろ | 変更点・原因推定 |
サポートの入口は契約形態や組織の状況で変わりますが、少なくとも「テナント ロックアウト」「管理者がサインインできない」「MFA が不整合」といったキーワードで状況を明確化して伝えることが、解決までの往復を減らします。
復旧できたら必ずやる：MFA 再設定を“正しい場所”で完了させる
管理者が「MFA 再登録を要求」してくれた後は、ユーザー側で再設定を完了させないと、同じ詰みが再発します。復旧直後は焦っているため、ここで手順を取りこぼしがちです。
ユーザー側のおすすめ手順
- プライベート（InPrivate）で mysignins.microsoft.com/security-info を開く
- サインイン画面で、意図したアカウントを選ぶ（同じメールが並ぶ場合は「職場/学校」側を選ぶケースが多い）
- Microsoft Authenticator を使う場合、端末側で「職場/学校アカウント」として追加する（既に似た表示が複数あるなら、どれがどれか整理する）
- 可能なら第二の手段も登録する（例：電話、別端末、FIDO2 セキュリティキーなど）
- 設定後、Azure ポータルに入り直して動作確認する
個人 Microsoft アカウント（MSA）側の設定（account.microsoft.com）と、テナント側のセキュリティ情報（mysignins.microsoft.com/security-info）は、見た目が似ていても役割が違います。今回のような #EXT# 混線では、「どこで何を設定しているか」を意識するほど復旧が安定します。
再発防止：個人 Microsoft アカウントをテナントに招待するときの運用ポイント
今回の問題は「レアな事故」ではなく、アプリ検証や Azure ポータルの検証で誰でも踏みやすい地雷です。再発防止は、難しい技術より“運用の設計”が効きます。
ブラウザーを分ける（これだけで事故が激減）
- Edge/Chrome のプロファイルを「個人用」「検証テナント用」で分ける
- Azure ポータルは別プロファイルで開く（同一プロファイルに複数アカウントを混在させない）
- 検証時だけ InPrivate を使う運用も有効
テスト用アカウントを用意する
- 普段使いの MSA をそのまま招待しない（事故時の影響が大きい）
- 検証専用の MSA／検証専用の組織アカウントを用意して、用途を分離する
管理者は必ず複数人（またはブレークグラス）
「自分しかグローバル管理者がいない」は、MFA が絡んだ瞬間に一気に高リスクになります。最低限、次のどちらかを満たすと安全性が跳ね上がります。
- グローバル管理者を2 名以上用意する
- 緊急用（ブレークグラス）アカウントを用意し、厳重に保管する
セキュリティ強化のつもりで MFA を固めた結果、管理者自身が締め出されるのは本末転倒です。運用の現場では「攻撃を防ぐ」だけでなく「復旧できる」ことも同じくらい重要です。
よくある質問
個人 Microsoft アカウント（MSA）は元に戻せますか？
多くの場合、MSA 自体が変質したわけではありません。#EXT# はテナント側での“外部ユーザー表現”なので、テナント側の状態（招待・MFA）を整えれば通常は問題なく使えます。個人側の確認は account.microsoft.com が基準です。
#EXT# のユーザーを削除するとどうなりますか？
そのテナント内のゲストユーザー（オブジェクト）が削除されます。テナント内で付与していた権限やグループ所属は消える可能性があるため、削除前に「何を割り当てていたか」を控えてから実行するのが安全です。単なる検証用途なら削除→再招待が早いこともあります。
MFA の「6 桁」と「8 桁」はどちらが正しいのですか？
“正しさ”ではなく“求められている方式”が違います。サインイン画面が求める入力形式に合わせる必要がありますが、今回のように噛み合わない場合は、テナント側で「MFA 再登録」を要求してもらい、正しい方式で登録を作り直すのが現実的です。
管理者に頼めない（いない）場合、ユーザー側だけで解決できますか？
管理者が誰もサインインできない状態は、テナント ロックアウトとして扱われ、本人確認を伴う復旧が必要になります。ユーザー側のブラウザー操作だけで解ける範囲を超えていることが多いため、サポートルートでの復旧を前提に動くのが確実です。
「個人アカウントは使えない」が出たら、すべて個人アカウントが原因ですか？
いいえ。入口 URL が組織向けのことがよくあります。個人の設定確認は account.microsoft.com、テナント側のセキュリティ情報は mysignins.microsoft.com/security-info が基準、という使い分けをまず行ってください。
まとめ：現実的な復旧順序は「URL → テナント側 MFA → 招待し直し → ロックアウトはサポート」
個人 Microsoft アカウントを Entra ID テナントへ追加したことで、#EXT# 表示や「個人アカウントは使えない」といった混線が起きるのは、仕組みとして十分に起こり得ます。まずは入口 URL の切り分けを行い、それでも詰んでいる場合はテナント側で MFA を再登録できる状態に戻すのが王道です。別の管理者が入れるなら復旧は一気に現実的になりますし、もし管理者不在ならテナント ロックアウトとしてサポート復旧ルートに切り替えるのが最短になります。
コメント