Azure ポータルにサインインできず「AADSTS5000225: This tenant has been blocked due to inactivity.」と表示される場合、パスワードや MFA の不備ではなく、Microsoft Entra ID テナント（旧 Azure AD テナント）そのものが“非アクティブ扱い”でブロックされている可能性が高いです。原因の見分け方と、復旧の現実的な手順を整理します。
現象を整理：Azure ポータルにサインインできないときのエラー AADSTS5000225
サインイン画面は通常どおり進むのに、最終的に次のようなエラーで止まるのが典型例です。
- Azure ポータルへアクセスし、組織アカウント／個人アカウントでサインインしようとする
- 数秒後にサインイン失敗となり、エラーコードとして AADSTS5000225 が表示される
- メッセージに「This tenant has been blocked due to inactivity（非アクティブのためテナントがブロックされた）」と出る
このエラーは「ユーザーの資格情報が違う」ではなく、「ログイン先のテナントがアクセス不可になっている」ことを示します。つまり、同じアカウントであっても別テナントへ切り替えればサインインできることがあり、逆に言うとそのテナントに入りたい場合はサポート対応が必要になります。
AADSTS5000225 の意味：Microsoft Entra ID テナントが非アクティブでブロック
AADSTS5000225 は、Microsoft のテナント ライフサイクル（未使用テナントの整理）方針により、長期間利用されていないテナントが「非アクティブ」と判断され、サインイン自体がブロックされた状態で発生します。未使用のテナントが残り続けると、意図しないコストや管理負荷につながるため、アクセス不可にすることで不要な支出を抑える目的があります。
| よく混同されるもの | 例 | AADSTS5000225 との関係 |
|---|---|---|
| アカウントの問題 | パスワード誤り、MFA 認証失敗、ロックアウト | 通常は別のエラーになりやすく、テナントが有効ならパスワードリセット等で改善余地があります |
| テナントの問題 | テナントが非アクティブでブロック、削除予定 | 今回の本命。ユーザー側で設定を変えてもサインインできません |
| ディレクトリの選択ミス | 複数の組織に所属しており、意図しない組織へ誘導される | 「ブロックされた別テナント」に誤誘導されているだけなら、組織の切り替え・離脱で回避できる場合があります |
最重要ポイント：20 日以内に動けるかが分岐点
Microsoft の公式ドキュメントでは、テナントが非アクティブ状態に入ってから20 日以内であれば、管理者が再有効化（reactivation）を依頼できると案内されています。一方で、非アクティブ状態が 20 日を超えるとテナントは削除され、復元できないとされています。
つまり、いま AADSTS5000225 が出ているなら「その日から何日経ったか」が極めて重要です。社内で担当者を探している間にも猶予が減るため、テナントを継続利用したい場合は連絡ルートの確保を最優先にしてください。
| 状態 | ユーザーが見える症状 | 取りうる行動 |
|---|---|---|
| 非アクティブ（アクセス不可） | AADSTS5000225 でサインイン不能 | 管理者が Microsoft へ再有効化を依頼できる可能性（20 日以内が目安） |
| 削除済み | サインイン不可、管理画面にも入れない | 原則として復元は期待できないため、新規テナント作成・移行方針の検討 |
最初に切り分ける：本当に“そのテナント”が必要か
実務で意外と多いのが、サインインしたいのは自分の個人アカウント（例：学習用）なのに、過去に所属していた組織アカウントや、ゲストとして参加していた古い組織へ自動的に誘導され、そこで AADSTS5000225 になっているケースです。つまり「アカウントは生きているのに、誘導先テナントが死んでいる」パターンです。
切り分けチェック（すぐできる）
- シークレット／InPrivate で試す（ブラウザのキャッシュ・クッキーの影響を除外）
- 同じアカウントで Microsoft 365 管理センターや他サービスに入れるか確認（入れるなら、アカウント自体は生きている可能性が高い）
- 自分が所属する組織一覧から、問題の組織（古い学校・会社など）を離脱できないか確認
- 別のテナントへ明示的にサインインする（テナント ID を指定して Azure ポータルを開く）
上記で“別テナントには入れる”場合は、復旧の主戦場は「テナントの再有効化」ではなく「正しいテナントにログインするための誘導の修正」になります。逆に、どの手段でも目的のテナントに入れない場合は、次章のサポート依頼が現実的な解になります。
テナントを復活させたい場合：管理者が Microsoft サポートへ依頼する
公式ドキュメントでは、非アクティブでアクセス不可になったテナントを再有効化したい場合、テナント管理者が Microsoft に連絡するよう案内されています。また、サポート対応中に追加の依頼（複数チケット）を出すと処理が分散するため、既存ケースが進行中の間は新規の依頼を控えるよう推奨されています。
「誰が」連絡すべきか
- 組織（会社・学校）：グローバル管理者（もしくはサポート管理者権限を持つ担当者）／情報システム部門が窓口
- 個人で作ったテナント：テナント作成者が管理者になっているケースが多いので、心当たりのあるアカウントで対応
サポートに伝える前に準備する情報
やり取りを最短化するため、次の情報を手元に集めてから連絡するとスムーズです（わからない項目があっても連絡自体は先に進めて構いません）。
| 準備するもの | 例 | 入手のヒント |
|---|---|---|
| テナント ID（GUID） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 過去のメモ、課金・契約時の資料、エンジニアの設定ファイル、Azure CLI の記録など |
| テナントの既定ドメイン | contoso.onmicrosoft.com | 過去メール、アプリ登録のリダイレクト URI、証明書名などに残りやすい |
| 影響を受けるユーザー（メール） | [email protected] | エラーが出るアカウントそのもの |
| エラー詳細 | Trace ID / Correlation ID / Timestamp | エラー画面に表示される文字列をそのまま控える |
| ビジネス影響 | 本番アプリの認証が停止、請求確認が不能 等 | 「なぜ復活が必要か」を短く具体的に |
連絡手段の例
- 電話：Microsoft サポートの「Customer service phone numbers」から国／地域別の番号を確認し、テナント再有効化の依頼として相談します。
- オンライン（可能な場合）：Microsoft Entra 管理センターからサポート リクエストを作成できる場合があります（ただし、ブロックされたテナントに入れない状況では、別のアクセス可能なテナントや契約形態が必要になることがあります）。
日本からの電話窓口は複数掲載されています。番号は変更されることもあるため、必ず最新の一覧で確認してください。
サポートへの依頼文例（コピペ可）
電話でもチケットでも、最初の一言が曖昧だと“アカウントの問題”として扱われやすいので、「テナントが非アクティブでブロック」を明確に入れるのがコツです。
件名：AADSTS5000225 により Azure ポータルへサインインできない（テナント再有効化の依頼）
発生事象：
Azure ポータルのサインインで「AADSTS5000225: This tenant has been blocked due to inactivity.」が表示され、管理者を含めてサインインできません。
依頼内容：
当該 Microsoft Entra ID テナントが非アクティブとしてブロックされているため、再有効化（reactivation）をお願いしたいです。
テナント情報：
・テナント ID：{GUID}
・既定ドメイン：{xxxxx.onmicrosoft.com}
・影響ユーザー：{admin@...}
エラー詳細（表示されている場合）：
・Trace ID：{...}
・Correlation ID：{...}
・Timestamp：{...}
ビジネス影響：
{例：本番アプリの認証が停止している／請求確認が必要 など}
放置する場合に起きること：削除と復元不可のリスク
公式ドキュメントでは、テナントを再有効化しない場合、非アクティブでアクセス不可の状態が 20 日続くとテナントが削除され、復元できないと明記されています。学習用の検証テナントなら「新規で作り直す」という選択も現実的ですが、業務利用やドメイン／アプリ登録が絡む場合は影響が大きくなります。
削除されると、一般的には次のようなディレクトリ データが失われます。
- ユーザー、グループ、ロール割り当て
- アプリ登録（証明書・シークレット含む）
- エンタープライズ アプリ（SaaS 連携）や条件付きアクセスなどの設定
- 監査ログやサインイン ログへのアクセス経路
保持や削除の扱いはサービスや契約条件にも依存します。Microsoft のトラスト センターでは、サービス利用終了時のデータ保持や削除に関する説明がまとめられているため、必要に応じて確認してください。
パターン別：現場で多い“詰まりどころ”と最短ルート
同じ AADSTS5000225 でも、背景によって「いま取るべき行動」が変わります。次の表で自分の状況に近いものを選び、迷いを減らしてください。
| よくある状況 | 見分けポイント | 最短の進め方 |
|---|---|---|
| 会社・学校のテナントが放置されていた | 自分は利用者で、契約や管理権限の心当たりがない | 情報システム部門／契約担当へ連絡し「テナントが非アクティブでブロック、20 日以内にサポートへ再有効化依頼が必要」と共有 |
| 学習用・検証用に作ったテナントを放置していた | 本番業務の影響は小さいが、過去の設定やラボ環境を残したい | まずは再有効化の可否をサポートに確認。期限超過の可能性が高いなら、早めに新規テナント作成へ切り替える |
| 個人アカウントが古い組織に紐づいていて誤誘導される | 別サービスには入れる／別テナントなら動くのに、Azure ポータルだけ失敗 | 組織の離脱や、目的テナントの明示指定で「ブロックされた組織へ行かない」状態を作る |
| アプリや自動処理がブロックされたテナントへ認証し続けている | バックエンドで認証エラーが増え続け、監視アラートが鳴る | テナントが再有効化されるまで、認証リトライを抑制（指数バックオフ／一時停止）。サポートは 1 件に集約 |
アプリ運用者・開発者向けの注意点
ブロックされたテナントに対して、アプリが短い間隔でトークン取得を繰り返すと、ログがノイズで埋まり原因切り分けが難しくなります。Microsoft の案内でも、テナントが再有効化されるまで認証要求の回数を最小化することが推奨されています。
- 短周期のリトライは避け、指数バックオフや上限回数を設定する
- 運用監視では「AADSTS5000225 を検知したら通知＋自動停止」のようにルール化する
- サポート依頼は同一事象で増やさず、ケース番号を社内で共有して一本化する
最後に：結論だけ先に確認したい人向けチェックリスト
- 目的のテナントは本当にそれか？（誤誘導なら回避策がある）
- 継続利用が必要か？（不要なら何もしない、必要なら即エスカレーション）
- 非アクティブ状態に入ってから 20 日以内か？（期限が短い）
- 管理者が誰か特定できたか？（管理者がサポートへ連絡する）
- テナント ID／既定ドメイン／エラー詳細を控えたか？（サポートが調査しやすい）
再発防止：テナントを“非アクティブ”にしない運用のコツ
この手のトラブルは、起きてからの復旧が「サポート依頼（しかも期限付き）」になりがちです。小さな運用で回避できる部分も多いので、次の習慣化をおすすめします。
- テナント ID を資産台帳に残す（社内 Wiki／パスワード管理ツールなど）
- 最低 2 名の管理者を用意し、連絡先メールが失効しないようにする
- 定期的にサインインして、テナントが放置状態にならないようにする（特に検証用）
- 不要なテナントは整理し、逆に必要なテナントは「担当者不在」にならないよう引き継ぎを明確化
- アプリ運用がある場合、テナントが無効化されたときに認証リトライが暴走しないよう、エラー検知とアラートを整備
よくある質問
パスワード変更や MFA の再設定で直りますか？
このエラーはテナント側がブロックされていることを示すため、ユーザーのパスワード変更や MFA 再登録だけで解決する可能性は低いです。まずは「正しいテナントに入ろうとしているか」と「テナント自体が非アクティブか」を切り分けてください。
自分が管理者かわからないのですが？
組織利用であれば情報システム部門や、Azure／Microsoft 365 の契約担当に確認するのが最短です。個人利用であれば、過去にテナント作成や課金登録を行ったアカウントが管理者になっていることが多いです。
サポートに連絡できない（サインインできない）場合は？
テナントに入れない状況でも、電話窓口から相談できることが案内されています。また、別のテナントや別の管理経路からオンラインでサポート リクエストを作成できるケースもあります（サポートの作成方法や“1 件の問題につき 1 件”の考え方は公式の案内が参考になります）。
「誤ってブロックされたテナント」に誘導されているだけなら？
個人アカウントが過去の学校・会社テナントに紐づいていると、ポータルがそちらへ誘導し、結果として AADSTS5000225 を引くことがあります。その場合は、アカウント管理の「組織」ページから古い組織を離脱したり、目的のテナントを明示的に指定してサインインすることで回避できることがあります。
テナントを継続利用する必要があるのか、単に“誘導先が悪い”のかで対応が真逆になります。まずは本記事の切り分け表に沿って状況を整理し、必要なら 20 日の猶予内にサポートへ再有効化を依頼してください。
コメント