Azureポータルに個人用メール（Microsoft アカウント／MSA）でサインインしようとして「AADSTS5000224: テナントの認証が解除され利用できない」と出た場合、原因は“ブラウザーの不調”よりも「サインイン先テナントのズレ」か「テナント側の停止・ブロック」であることが多いです。最短で切り分ける手順と、復旧に必要な情報整理までまとめます。
AADSTS5000224とは？まず押さえるべきポイント
AADSTSは Microsoft Entra ID（旧 Azure AD）のサインイン基盤（STS）が返すエラーコード群です。重要なのは、PCやブラウザー設定だけで直るケースと、テナント側の状態（停止・ブロック）で“誰も入れない”ケースが混在する点です。
Microsoft Learn のエラーコード一覧では、AADSTS5000224 は 「NotAllowedTenantBlockedTenantFraud」として掲載され、メッセージは「このリソースは利用できない。誤りなら Microsoft サポートへ」旨になっています。つまりこのコードは、単純なパスワード間違いというよりテナント単位でのブロック／利用不可を示す方向に寄っています。
また同ページには「エラーコードやメッセージは変更されうる」「最新情報は https://login.microsoftonline.com/error?code=XXXXX で確認できる」と明記されています。調査のときは、まずこの“公式のエラー辞書”で現行の説明を引くのが近道です。
よくある見え方：Azureポータルで表示されるメッセージ
Azureポータル側では、次のような文言で出ることが多いです。
- 「The tenant you are trying to access has been deauthenticated and is no longer available」
- 「Try signing in using a new or private browser window」
- 「portal.azure.com/[tenant-id] または portal.azure.com/[tenant-domain] でサインインできる」
この“ガイド文”自体が、切り分けの順序を示しています。まずはプライベートウィンドウでCookie影響を排除し、それでもダメならテナントを明示して入口のズレを正します。
原因を最短で絞る：まず試す切り分け（5〜10分）
| やること | 目的 | 判定できること | 次の一手 |
|---|---|---|---|
| プライベート/シークレットで再試行 | Cookie・セッション汚染を排除 | ブラウザー要因かどうか | 改善しないならテナント明示へ |
portal.azure.com/<tenant-id> でアクセス | サインイン先を固定 | “別テナントに迷い込んでいる”可能性 | 目的テナントに入れるか確認 |
portal.azure.com/<tenant-domain>（例：xxx.onmicrosoft.com） | tenant-id不明でも固定 | 同上（入口ズレの修正） | テナントドメインを調べる |
| サインイン時に「職場または学校」側で入る | MSA/組織アカウントの取り違え回避 | アカウント種別の誤り | ゲスト招待/アカウント発行へ |
| 入れた場合はポータル右上でディレクトリ切替 | 複数テナント所属時の誤選択を修正 | “たまたま停止中テナントを掴んでいた” | ブラウザプロファイル分離も検討 |
特に portal.azure.com/<tenant-id or tenant-domain> の指定は、エラーメッセージにも直接案内が出るため効果的です。
「個人用アカウント（MSA）」が絡むとハマりやすい理由
MSA（@outlook.com等）でAzureを触っていた人ほど、次の罠に引っかかります。
- 同じメールっぽく見えても、実は“個人”と“職場/学校”で別物（選択を間違えると、想定外のディレクトリに入る）
- 複数テナントに所属していると、前回のセッション情報で“別テナント”が既定になる
- テナント側が停止・ブロックされると、MSAでも組織アカウントでも入れない（入口を変えても同じエラー）
「先月までは入れたのに突然ダメになった」タイプは、クライアント側変更よりも、テナント側の状態変化（セキュリティ対応・ブロック等）を疑うのが効率的です。実際に Microsoft Q&A でも、AADSTS5000224 は「最近のセキュリティインシデントにより、テナントの認証が一時的に無効化された際に起きる」趣旨で説明され、再有効化にはエンジニアリング側の作業が必要になるケースが示されています。
テナントID／テナントドメインを“ログインできない状態で”調べるコツ
サポートや管理者に連絡する際、テナント識別子があると話が早いです。分からない場合は、次の順で探すと見つかりやすいです。
| 手がかり | 探す場所 | 見つかる可能性が高い情報 |
|---|---|---|
| 過去のメール | Azure/Microsoftからの請求・サブスク通知、招待メール | xxx.onmicrosoft.com、テナント名、サブスクリプション名 |
| 社内の管理者 | 全体管理者（グローバル管理者）／請求管理者 | テナントID、ディレクトリ名、契約情報 |
| 過去の作業メモ | Wiki/手順書/チケット/README | tenantId、サインインURL、環境名 |
| Azure CLIの履歴 | 以前ログインできていたPCのコマンド履歴 | tenantId（過去の出力に残っていることがある） |
ポイントは、「tenant-idが無くても tenant-domain（onmicrosoft.com）で固定できる」ことです。tenant-domain が分かれば、少なくとも入口のズレを正せますし、サポートへの提示材料にもなります。
状況別の対処：あなたのケースはどれ？
パターンA：テナントが停止／ブロックされている（最有力）
プライベートウィンドウでも、テナント明示でも同じ AADSTS5000224 が出続けるなら、この可能性が高いです。Microsoft Learn の説明名に “BlockedTenant…Fraud” が含まれることからも、テナント側がブロック扱いになっている（あるいはその疑いで一時制限）状況が示唆されます。
この場合、現場の端末側でできることは限られ、管理者とMicrosoftサポート（またはMicrosoft側の担当）で再有効化を進めるのが王道です。Microsoft Q&Aでも「認証が一時的に無効化されたので、エンジニアリングチームと連携して再有効化する」流れが案内されています。
実際に、個人アカウントでAzureポータルに入れなくなった事例でも、最終的に「Engineering team has fixed the issue and you will be able to re authenticate」として解消した旨が共有されています。
サポートに渡すべき情報は、エラーページに表示される識別子です（問い合わせ往復を減らせます）。
| 項目 | どこに出る？ | 用途 | 注意点 |
|---|---|---|---|
| Tenant ID / Tenant domain | 分かる範囲で（onmicrosoft.com でも可） | 対象テナント特定 | 不明なら推測せず、分かる手がかりを列挙 |
| Timestamp | エラー画面の末尾 | ログ突合 | 時刻はコピペ推奨 |
| Correlation ID | 同上 | 追跡キー（サポート調査） | 公開の場に貼らない |
| Trace ID | 同上 | 追跡キー（サポート調査） | 公開の場に貼らない |
| 発生範囲 | 自社で整理 | 緊急度・影響把握 | 「誰が」「どの入口で」全滅かを明確に |
補足として、Azure CLI で az login を試しても同様の AADSTS5000224 が返り、エラー文に Trace ID / Correlation ID / Timestamp が含まれる例が報告されています。つまり「ポータルだけ壊れている」のではなく、認証自体が止まっているケースがあり得ます。
パターンB：MSAで“組織テナント”に入ろうとしている（アカウント種別/所属の問題）
組織テナント側で、MSA をそのまま管理者として使う想定になっていない構成は珍しくありません。典型的には以下の対応になります。
- 管理者に 職場または学校アカウント を発行してもらう
- MSA を使いたい場合は、管理者に ゲスト（B2B）として招待してもらい、招待の受諾を完了する
- 受諾後は テナントを明示してサインイン（portal.azure.com/tenant-domain など）
ここで重要なのは、MSAで入れる/入れないは“Azureの機能制限”というより、テナント側の設計・ポリシーで決まる点です。自力でポータル側をいじっても解決しない場合は、所属（メンバー/ゲスト）とアカウント種別の整合を先に取りに行くのが最短です。
パターンC：テナント選択ミス（複数テナント所属・セッション引きずり）
複数ディレクトリに所属していると、ブラウザーの状態によって“前回開いていたテナント”が既定になり、たまたま停止中テナントを掴んで AADSTS5000224 に見舞われることがあります。
- まずはプライベートウィンドウで“素の状態”にする
- 次に
portal.azure.com/<tenant-id>またはportal.azure.com/<tenant-domain>で入口を固定する - 入れたら、右上のアカウントメニューからディレクトリ/テナントを切り替える
普段からの運用としては、ブラウザーのプロファイルを「個人MSA用」「会社テナント用」で分けると、セッション汚染による事故が激減します（Edge/Chromeともにプロファイル分離が有効です）。
パターンD：条件付きアクセスやユーザー無効化（ただし別エラーになりやすい）
条件付きアクセス（CA）やユーザー無効化でもサインインできなくなりますが、よく出るのは MFA要求や準拠デバイス要求など別系統のエラーです。AADSTS5000224 が出ているなら、まずはテナントレベルの停止/ブロックを疑うのが効率的です。
それでも念のため管理者側で見るなら、次の順が実務向きです。
- ユーザーが「サインインをブロック」されていないか
- 条件付きアクセスで「すべてのクラウドアプリ」に対して過剰に制限していないか
- 場所・デバイス・クライアントアプリ制御で想定外に弾いていないか
“管理者が動けない”ときの現実的な打ち手
AADSTS5000224 の厄介なところは、テナントが止まっていると全体管理者ですら管理画面へ入れない状況になり得る点です。その場合、復旧の糸口は「Microsoft側にテナント状態を戻してもらう」方向になります。
- サポート契約があるなら、契約窓口（請求/契約情報に紐づく導線）からエスカレーションする
- 組織で別テナントに管理者権限がある場合、入れるテナントからサポート起票し、影響テナントID/ドメインを提示する
- 公式コミュニティ（Microsoft Q&A等）で、公開してよい範囲に絞って事象を共有し、サポート導線を確保する（ID類は伏せる）
このとき、前述の Trace ID / Correlation ID / Timestamp があると調査が進みやすいです。
復旧後に必ずやる：再発と二次被害を防ぐチェック
テナントが“戻った”直後は、火消しだけで終わらせず、原因と再発防止をセットでやるのが安全です。
| 確認項目 | 具体的に見るもの | 優先度 |
|---|---|---|
| サインインの異常 | 短時間の大量失敗、国外/未知のIP、管理者アカウントへの試行 | 高 |
| 管理者アカウントの棚卸し | 不要な特権付与の削減、役割の最小化、退職者の整理 | 高 |
| MFA/認証方法の見直し | SMS依存の回避、Authenticator/パスキー等の強化 | 中 |
| 条件付きアクセスの安全運用 | 全体ロック級のポリシーは段階適用、除外設計の再点検 | 高 |
| 契約・請求・連絡先 | 技術連絡先の更新、緊急時のエスカレーション手順 | 中 |
再発防止（管理者向け）：ブレークグラス運用は“実装”までがセット
「緊急用アカウント（ブレークグラス）を用意する」は定番ですが、作るだけでは意味がありません。実務で効くポイントを3つに絞ります。
- 2アカウント以上（片方がロックされてももう片方で対応できる）
- 条件付きアクセスの対象外にする（ただし利用時アラートは強めに）
- 保管と運用ルールが明文化されている（誰が、どの条件で、どこに保管し、使ったら何をするか）
また、MSAと組織アカウントを併用している現場では、ブラウザーのプロファイル分離（個人用/業務用）を標準運用にするだけで、「意図しないテナントに入ってエラーに見える」事故が大幅に減ります。
FAQ：現場でよく出る疑問
プライベートウィンドウでもダメ。PCを変えてもダメ。何かできる？
入口や端末を変えても同じ AADSTS5000224 なら、端末側よりテナント側の停止/ブロックが濃厚です。サポートに渡す情報（Tenant ID/Domain、Timestamp、Correlation/Trace ID）を揃え、管理者と連携して復旧ルートに乗せるのが最短です。
Azure CLI / PowerShell なら入れる？
同じ認証基盤を通るため、テナントが止まっている場合は CLI でも同様に失敗します。実際に az login で AADSTS5000224 が返り、Trace/Correlation/Timestamp が出る例があります。
「テナントを明示してサインイン」って具体的にどう書く？
次の形式です（どちらか分かる方でOK）。
https://portal.azure.com/<tenant-id>
https://portal.azure.com/<tenant-domain> （例：contoso.onmicrosoft.com）この導線は、エラーメッセージ内でも案内される定番の切り分け手段です。
個人用アカウント（MSA）でAzureを使っていたのに、突然入れなくなった
「先月までOK→今月から突然NG」は、テナント側の状態変化が絡むことがあります。Microsoft Q&Aでは、AADSTS5000224 について“テナント認証が一時的に無効化された”ケースで、Microsoft側が再有効化対応した事例が共有されています。
現場向け：そのまま使える最短チェックリスト
- プライベート（シークレット）ウィンドウで試した
portal.azure.com/<tenant-id or tenant-domain>を指定して試した- サインイン時のアカウント種別（個人/職場・学校）を意識して選んだ
- サインインできる別テナントがあるなら、右上からディレクトリ切替を確認した
- 改善しない場合、Tenant ID/Domain、Timestamp、Correlation ID、Trace ID を控えた
- 全体管理者（グローバル管理者）に連絡し、サポートへのエスカレーションを依頼した
最後に一言だけ：AADSTS5000224 は「何度ログインしてもダメ」になりやすいエラーです。最初の10分で入口ズレを潰し、それでもダメなら“テナント側”に舵を切る。これが復旧を最短にする動き方です。
コメント