Azure ポータルに突然サインインできなくなり、「The tenant you are trying to access has been deauthenticated and is no longer available…（AADSTS5000224）」と表示されて戸惑っていませんか。本記事では、このエラーの意味と原因、今すぐ試せる回避策からテナント再有効化の依頼方法まで、実務でそのまま使える手順を詳しく解説します。
Azure ポータルのサインイン エラー「AADSTS5000224」とは？
Azure ポータルや Microsoft Entra ID（旧 Azure AD） 関連の画面にサインインしようとした際、次のようなメッセージとともに失敗することがあります。
Error code: AADSTS5000224The tenant you are trying to access has been deauthenticated and is no longer available.We are sorry, this resource is not available. If you are seeing this message by mistake, please contact Microsoft support.など
このエラーが示しているポイントはシンプルで、
「今アクセスしようとしているテナント（ディレクトリ）が、何らかの理由で“無効化（deauthenticated）”されており、通常の方法ではサインインを受け付けられない状態」
ということです。テナントが無効化される理由としては、以下のようなものが挙げられます。
- セキュリティ インシデントや不正利用の疑いによる一時的な認証停止
- 長期の未利用やライセンス・サブスクリプションの問題に伴うブロック
- テナントの削除・統合に向けたオペレーションの一環（削除待ち状態など）
さらに厄介なのは、「自分が本当に使いたいテナント」ではなく、「既定のサインイン先になっている別テナント」が無効化されているケースです。この場合、Azure ポータルの URL やキャッシュの影響で、毎回その無効化テナントに向かってしまい、ポータルに入れない状況になります。
| 現象 | 代表的なメッセージ | 想定される原因 |
|---|---|---|
| Azure ポータルにサインインできない | AADSTS5000224: The tenant you are trying to access has been deauthenticated... | サインイン先テナントが無効化されている／既定ディレクトリが無効化テナント |
| entra.microsoft.com / Azure CLI でも失敗 | interaction_required: AADSTS5000224: We are sorry, this resource is not available... など | 同じ無効化テナントに対する認証が、複数のクライアントで失敗している |
| 個人アカウントでのみ発生 | 同様の AADSTS5000224 エラー | 個人アカウントが「ゲスト」として参加しているテナントが無効化され、そこに既定でアクセスしている |
まず試すべき回避策：テナントを URL で明示指定してサインイン
「無効化されたテナント」に誤って飛ばされているだけであれば、アクセスしたいテナントを URL で明示指定することで、問題を回避できる場合があります。Microsoft の Q&A でも、次のような URL 形式でのサインインが案内されています。
https://portal.azure.com/<tenant-id>https://portal.azure.com/<tenant-domain>
例：contoso.onmicrosoft.com、contoso.com
ステップバイステップ：URL 指定サインイン手順
- ブラウザーで シークレット / プライベート ウィンドウ を開きます。
（Edge の InPrivate、Chrome のシークレット ウィンドウなど） - アドレスバーに、次のいずれかを直接入力します。
https://portal.azure.com/<tenant-id>https://portal.azure.com/<tenant-domain>
- サインイン画面が表示されたら、問題が起きているアカウント（個人アカウント／職場アカウント）でサインインします。
- 正常にポータルに入れた場合、そのテナントが今後の作業で使うべき「正しいテナント」です。
同じ考え方は、Azure ポータル以外のエンドポイントにも応用できます。
- Entra 管理センター（新しい管理ポータル）
https://entra.microsoft.com/<tenant-id>https://entra.microsoft.com/<tenant-domain>
- Resource Graph Explorer やその他の Azure サービス ポータルでも、多くはクエリパラメーターや URL でテナント指定が可能
ここまででサインインできるようになった場合、テナント自体は生きていて、単に誤った既定テナントに飛ばされていただけと判断できます。この先は「ディレクトリの切り替え」やブックマークの整理で、誤テナントへの遷移を防止していくフェーズです。
| URL 形式 | 用途 | 備考 |
|---|---|---|
https://portal.azure.com/ | 既定テナントへサインイン | 無効化テナントが既定になっていると AADSTS5000224 になりやすい |
https://portal.azure.com/<tenant-id> | テナント ID を指定してサインイン | 確実に狙ったテナントに接続したい場合に有効 |
https://portal.azure.com/<tenant-domain> | テナント ドメイン（xxx.onmicrosoft.com 等）を指定 | テナント ID が分からない場合でも利用しやすい |
テナント ID / ドメインが分からない場合
「そもそも自分のテナント ID が分からない」というケースもよくあります。その場合、次のような方法で確認できます。
- すでに他の管理者が分かっているなら、その人に テナント ID またはドメイン を確認してもらう
- 同じ組織の別アカウントで Azure ポータルに入れる場合は、
「Microsoft Entra ID > 概要」からテナント情報を確認する - Microsoft から届いた課金・契約関連のメールに、テナント名やドメインが記載されている場合もある
個人利用であっても、学生向けサブスクリプションや無償評価版などを何度か作成していると、複数テナントが自分のアカウントに紐づいている可能性があります。そのうちのどれかが無効化されていると、既定サインイン先がそちらを向いてしまい、AADSTS5000224 に繋がることがあります。
ブラウザーとアカウント周りの切り分けチェックリスト
URL 指定でのサインインと合わせて、まずは以下の「すぐできる切り分け」を順番に試しておきましょう。これだけで問題が解消することも多く、Microsoft サポートにエスカレーションする際の情報整理にも役立ちます。
- シークレット / プライベート ウィンドウで再試行
ブラウザーに古い認証情報やクッキーが残っていると、無効化テナントに自動でリダイレクトされることがあります。必ず InPrivate / シークレット ウィンドウで確認します。 - 別ブラウザー / 別プロファイルで再試行
Edge と Chrome で結果が異なることもあります。ブラウザー プロファイルごとにキャッシュや既定テナントが違うため、「片方だけエラー」というパターンも珍しくありません。 - Azure ポータル右上のアイコン >「ディレクトリの切り替え」
もしポータルには入れるが一部のリソースでエラーが出る場合は、「ディレクトリの切り替え」で利用したいテナントを明示的に選び直します。 - 複数テナントに所属している場合は URL でテナントを明示
Microsoft アカウントや職場アカウントが複数テナントのメンバー／ゲストになっていると、誤ったテナントに行きがちです。portal.azure.com/<tenant-id>で狙い撃ちしましょう。 - それでもダメな場合は「テナント無効化」を前提に調査
ここまで試しても AADSTS5000224 のままなら、テナント自体が無効化されている前提で、Microsoft への再有効化依頼の準備に進みます。
それでも入れない場合：テナント無効化（deauthenticated）の可能性
URL 指定やブラウザーの切り分けを行っても状況が変わらない場合、対象テナント自体が無効化状態である可能性が高くなります。Microsoft は、利用頻度の低いテナントや問題のあるテナントを「ブロック」「アクセス不可（inaccessible）」状態にする仕組みを持っており、その結果として AADSTS5000224 が返されることがあります。
テナントが無効化される代表的なパターン
| パターン | 主なトリガー | 関連しやすいエラー |
|---|---|---|
| セキュリティ インシデント対応 | 不正アクセス疑い・利用規約違反等 | AADSTS5000224（テナント無効化）、その他セキュリティ関連エラー |
| 長期未利用・ライセンス問題 | 長期間ログイン無し、支払い情報の問題など | AADSTS5000224 / AADSTS5000225（ブロック・非アクティブ）など |
| 意図的な停止・削除準備 | 管理者がテナントを削除・統合する際の中間状態 | AADSTS5000224、テナント未検出系エラー（削除完了後） |
特に昨今は、長期間利用されていないテナントを自動的にブロックするライフサイクル ポリシーの適用が進んでおり、「久しぶりに触ろうとしたらいきなり AADSTS5000224 / 5000225」というケースが増えています。
この段階に来たら、ユーザー側だけで完結する解決策は基本的にありません。テナント所有者（Global Administrator）か、Microsoft サポートなどの裏側オペレーションが必須となります。
Microsoft へのテナント再有効化依頼：準備しておきたい情報
テナントの再有効化を依頼する場合、事前に情報を整理しておくと対応がスムーズになります。Microsoft Q&A やサポート案内でも、概ね次のような情報が求められます。
最低限まとめておきたい情報
- 対象テナントの識別情報
- テナント ID（GUID）
- または
xxx.onmicrosoft.comドメイン
- 全体管理者（Global Administrator）の情報
- 管理者の UPN（
[email protected]など） - 管理者本人が問い合わせを行うのが理想
- 管理者の UPN（
- 問い合わせ担当者が Microsoft 社員かどうか（該当する場合）
- Microsoft 社員であれば Work ID（
[email protected]）
- Microsoft 社員であれば Work ID（
- テナントの作成経緯・用途
- 本番 / 開発 / 検証 / 学習用 などの区分
- 教育機関向け・スタートアップ向け・無償評価版などの種別
- 再有効化しない場合の業務影響
- 利用中のサービス（VM、ADB2C、Power Platform、Entra ID など）
- 影響を受けるユーザー数・システム数
コンタクト チャネルの例
環境や契約により利用できる窓口は変わりますが、一般的には次のような方法が考えられます。
- 別テナントの管理者として Azure ポータルに入れる場合
- 「ヘルプ + サポート」からテクニカル サポート チケットを起票
- Microsoft 365 テナントを持っている場合
- Microsoft 365 管理センターのサポートから問い合わせ
- いずれのポータルにも入れない場合
- 一般公開されているサポート窓口（電話 / Web フォーム）から問い合わせ
- 購入したリセラー / パートナー経由でエスカレーションしてもらう
いずれにしても、「テナント無効化に伴う AADSTS5000224 発生」「対象テナント ID はこれ」「再有効化したい理由と影響範囲」を明確に伝えることが重要です。
個人アカウント（Microsoft アカウント）特有の落とし穴
今回のように「個人アカウントで Azure ポータルにサインインしようとしたら AADSTS5000224」という問い合わせは、Microsoft Q&A でも頻繁に投稿されています。
多くの場合、背景には次のような構図があります。
- 個人の Microsoft アカウント（Outlook.com / Hotmail など）が
- 過去にどこかの組織テナントに ゲスト ユーザー として招待されている
- そのテナントが現在は「無効化」「ブロック」「削除予定」などの状態になっている
- それにも関わらず、Azure ポータルがその無効化テナントを既定サインイン先として扱う
この場合、個人アカウント自体に問題はありません。「既定で向かっているテナントが悪いだけ」なので、URL で明示的に別テナントを指定するか、余計なテナント所属を整理することで解消できる可能性があります。
個人アカウントで確認しておきたいポイント
- 過去に
- 学校や前職の組織
- オンライン講座やコミュニティ
- 検証用に作った自分の別テナント
- もし別のテナント（例：現在の勤務先）に問題なくサインインできる場合は、
portal.azure.com/<別テナントのドメイン>- または
entra.microsoft.com/<別テナントのドメイン>
- 「アカウントの組織アクセス管理」画面から、不要な組織へのアクセス権を解除する（可能な範囲で）。
こうした整理を行ってもなお AADSTS5000224 が続く場合は、その個人アカウントに紐づくいずれかのテナントが無効化されており、Azure 側で既定選択の影響を受けている可能性が高いため、前述の手順で Microsoft に調査・再有効化を依頼する必要があります。
実務で使える対応フロー（まとめ）
ここまでの内容を、実務で利用しやすいフローに整理すると次のようになります。
- プライベート ウィンドウで URL 直アクセス
https://portal.azure.com/<tenant-id>またはhttps://portal.azure.com/<tenant-domain>に直接アクセスし、目的テナントを狙い撃ちしてサインインします。 - 別ブラウザー / 別プロファイルでの再試行
Edge / Chrome / Firefox など、ブラウザーを変えて同じ URL にアクセスし、キャッシュや拡張機能の影響を切り離します。 - ディレクトリの切り替えでテナントを確認
もしどこかのテナントには入れる場合、その中で「ディレクトリの切り替え」を使い、問題のテナントが一覧に出るか、ステータスがどうなっているかを確認します。 - URL も切り替えも効かない場合は「テナント無効化」を前提にする
ここまで試しても AADSTS5000224 のままなら、テナントが無効化されている前提で Microsoft への再有効化依頼に進みます。 - テナント情報と業務影響を整理し、サポートへエスカレーション
テナント ID / ドメイン、管理者 UPN、用途、本番 / 試験区分、利用中サービス、影響範囲をまとめた上で、利用可能なサポート チャネルから問い合わせます。 - 再有効化後は「既定サインイン先」と「不要テナント」を棚卸し
二度と同じことが起きないよう、よく使うテナントの URL をブックマークしたり、不要なテナント招待を解除したりして、サインイン経路をシンプルに整えます。
| 現在の状況 | 推奨アクション | 期待される結果 |
|---|---|---|
| URL 直指定でサインイン成功 | ブックマーク登録 / ディレクトリ切り替えの習慣化 | 今後は誤テナントに飛ばされず Azure ポータルを利用可能 |
| どのブラウザーでも AADSTS5000224 | テナント無効化と判断し、情報を整理してサポートへ | テナント再有効化の可否・方針が Microsoft から提示される |
| 個人アカウントでのみ発生 | ゲスト参加テナントの整理、URL 指定で別テナントにサインイン | 問題のあるテナントを回避しつつ、他テナントでの作業を継続可能 |
よくある質問（FAQ）
AADSTS5000224 と AADSTS5000225 の違いは？
AADSTS5000224 は、アクセスしようとしているテナントが「deauthenticated（無効化）」状態にあることを示すエラーとして報告されています。一方、AADSTS5000225 は 「このテナントは非アクティブ状態（blocked / inactive）である」ことを示すケースが多く、長期未利用などのライフサイクル ポリシーに関連することが多いとされています。
実務上はどちらも「テナント側の状態問題」であることに変わりはないため、Microsoft サポートへテナント状態の確認・再有効化可否を問い合わせるという対応になります。
テナントが完全に削除されていた場合はどうなりますか？
テナントがすでに完全削除されている場合、AADSTS90002（Tenant not found）など別のエラーとなることが多く、AADSTS5000224 からエラーが変化するケースもあります。
この状態から元のテナントを復元することは基本的にできないため、
- 新規テナントで環境を再構築する
- 必要に応じてバックアップや他システム上のデータから復元する
といった対処が必要です。テナント削除までには「soft-delete」「非アクティブ」などの中間状態が存在するため、できるだけ早期に状況を把握し、再有効化の余地がある段階で動くことが重要です。
Azure CLI や PowerShell、Visual Studio でも同じエラーが出ます
Azure ポータルだけでなく、
az login（Azure CLI）- PowerShell（
Connect-AzAccount等） - Visual Studio / VS Code のサインイン
などでも、同じテナントに対する認証であれば AADSTS5000224 が返されることがあります。
この場合も本質は同じで、サインイン操作が無効化テナントに向かっているか、テナント自体がブロックされていることが原因です。CLI や PowerShell の場合は、次のような追加確認も有効です。
az account listやGet-AzContextなどで現在のテナントを確認する- パラメーターで
--tenant <tenant-id>を指定して、意図したテナントに明示的にログインする - 資格情報キャッシュをクリアしてから再ログインする
再有効化を依頼すべきか、新規テナントを作るべきかの判断基準は？
ざっくりとした目安としては、次のように考えると整理しやすくなります。
| 状況 | 再有効化を優先 | 新規テナントを優先 |
|---|---|---|
| 本番サービスが稼働している | ◎（まずは再有効化依頼） | △（最終手段として検討） |
| 検証用・学習用の一時テナント | △（重要度次第） | ◎（作り直した方が早い場合も多い） |
| 組織リーガル的にデータ保持が必須 | ◎（ログ・監査・証跡の観点で再有効化が望ましい） | △ |
| データはすでに別環境へ移行済み | △ | ◎（新環境への一本化を検討） |
重要なのは、「このテナントにある“はず”のもの」を具体的に洗い出すことです。仮想マシン、ストレージ、アプリ登録、B2C テナント、Power Platform の環境など、どれか一つでも重要なものがあれば、再有効化の価値は高くなります。
おわりに：URL でテナントを明示し、状態を早めに確認する
AADSTS5000224 は、一見すると「よく分からない英語メッセージ」ですが、意味するところは 「そのテナントは今は普通の方法では使えない状態です」 というシンプルなものです。
この記事で紹介したように、
- URL でテナントを明示指定することで誤った既定テナントを回避する
- ブラウザーやアカウントの切り分けで、問題がテナント側かクライアント側かを見極める
- テナント無効化が疑われる場合は、情報を整理して Microsoft に再有効化を依頼する
という流れを押さえておけば、原因特定から解決までをスムーズに進めることができます。日常運用では、「よく使うテナントの URL をブックマーク」「不要テナントの棚卸し」を行い、再び同じエラーに悩まされないようにしておきましょう。
コメント