Microsoft Entra（旧Azure AD）やAzureへサインインしようとすると、エラーコード「AADSTS5000225」とともに「This tenant has been blocked due to inactivity（非アクティブのためテナントがブロックされた）」と表示され、管理画面に入れない――。本記事では原因の考え方と、復旧へ最短で進めるための実務手順をまとめます。
症状：AADSTS5000225「This tenant has been blocked due to inactivity」で管理画面に入れない
このトラブルは、Microsoft Entra（Microsoft Entra ID / 旧Azure Active Directory）やAzureポータル、Microsoft 365管理系画面など、テナントに紐づくサインインの入口で発生します。サインイン画面の途中で止まり、次のような情報が表示されるのが典型です。
- エラーコード：AADSTS5000225
- メッセージ：This tenant has been blocked due to inactivity（非アクティブのためテナントがブロックされた）
- Correlation ID / Timestamp（後述）
重要なのは、これが「特定ユーザーのパスワード間違い」や「MFA失敗」といった個別アカウント問題ではなく、テナント全体がブロックされている可能性が高い点です。つまり、同じテナント配下のユーザーであれば、管理者でも一般ユーザーでもサインインが通らない（もしくは管理系画面に入れない）ことがあります。
結論：フォーラムや自力では解除できない。Microsoftサポートへ連絡が必要
結論から言うと、コミュニティ（フォーラム）側や一般ユーザーの手元操作で「アンブロック」する手段は基本的にありません。モデレーターや回答者もバックエンド（テナント状態）を直接変更できないため、Microsoftサポートに直接連絡して、テナントのブロック解除を依頼するのが現実解です。
さらに実務上の注意点として、コミュニティ内の案内では、ブロックを放置すると短期間で削除に進み、削除後は復元できない可能性があるとされています。期限や条件は状況により変わり得ますが、「あとで対応」ではなく「今すぐ対応」が安全です。
なぜ起きるのか：テナントの「非アクティブ」判定とブロック
スレッド内で示されている説明では、Microsoft側のテナント運用（テナントのライフサイクル、非アクティブ対策）により、一定期間利用が確認できないテナントは、サインインがブロックされることがあるとされています。
ここでのポイントは、「非アクティブ」の判定が、単純な“人がログインしていない”だけとは限らないことです。例えば次のような条件・状況が重なると、体感的には「作ったばかりなのに非アクティブ扱い」に見えることがあります。
- 作成直後でも、内部的な状態遷移（審査・保留・制限）が残っている
- 検証用に作ったが、実際の運用（サブスクリプション紐づけ、利用、サインイン）が途切れている
- 組織で複数テナントを作成しており、対象テナントに誰も入っていない
- ドメインや請求周りの要件が未完了のまま止まっている（可能性）
ただし、ここは外部から確定診断が難しく、だからこそフォーラム回答が最終的に「サポートに連絡」に集約されがちです。原因特定よりも復旧のための必要情報を揃え、サポートへ正しく投げることが最短ルートになります。
放置が危険な理由：ブロック後、削除へ進む可能性がある
コミュニティでの案内では、ブロックされたテナントは、そのまま放置すると約20日程度で削除され、削除後は復元不可とされています（あくまで案内例であり、条件や期間が変動する可能性はあります）。
実務では、期限が少し違っていたとしても「削除に向かうフローが存在し得る」こと自体が重大です。Azureリソース、Microsoft 365データ、アプリ登録、条件付きアクセス設定、証明書やシークレット、検証で積み上げた構成など、テナントに紐づく資産は多岐にわたります。アクセス不能期間が長引くほど、復旧コストは上がります。
| 段階（目安） | 起きていること | やるべきこと |
|---|---|---|
| ブロック発生直後 | サインイン時にAADSTS5000225が表示され、管理画面に入れない | エラー詳細（Correlation ID / Timestamp 等）を確保し、サポート連絡の準備 |
| ブロック継続中 | 自力での解除は困難。放置すると削除へ進む可能性 | Microsoftサポートへ連絡。ケース番号が出たら一元管理 |
| 一定期間経過後（案内例：およそ20日） | テナント削除に到達する可能性。削除後は復元不可と案内される場合がある | 時間が経つほど危険。早期にサポートと接続して状況確認 |
重要：期間は“目安”として扱いつつ、実務判断は「最短で動く」が正解です。特に業務利用の可能性があるなら、同日中に連絡を開始してください。
最初にやること：エラー画面の情報を漏れなく確保する
サポートへ連絡する際、最初の受け付けや一次切り分けで、エラー詳細を求められることが多いです。慌てて電話すると、聞かれてから取りに戻ることになりがちなので、先に必要情報を控えるのがコツです。
| サポートに渡す項目 | どこで確認できるか | メモのコツ |
|---|---|---|
| Tenant ID | わかっていれば事前資料／管理台帳。表示される場合はエラー画面やサインイン関連情報 | GUID（英数字とハイフン）の形式。コピペが確実 |
| Error Code | エラー画面 | 今回は「AADSTS5000225」をそのまま伝える |
| Correlation ID | エラー画面の詳細欄に表示されることが多い | 1文字でも違うと調査が難しくなるので、スクリーンショット推奨 |
| Timestamp（エラー発生時刻） | エラー画面 | タイムゾーン込みで控える（表示のまま） |
| 業務影響（復旧が必要な理由） | 社内状況 | 「何が止まっているか」「いつまでに必要か」を具体化 |
可能であれば、次も用意しておくと話が早く進みます。
- 対象のユーザーUPN（例：[email protected]）
- 対象テナントの既知ドメイン（例：contoso.onmicrosoft.com）
- 影響範囲（Azureのみ／Microsoft 365も含む／アプリ認証も影響 等）
- いつから発生しているか（初回確認日時）
Microsoftサポートへ連絡する現実的なルート
「サインインできないのに、どうやってサポートに連絡するの？」が最初の壁です。状況により入口が変わるため、実務で使えるルートを整理します。
| 連絡ルート | 前提 | メリット | 注意点 |
|---|---|---|---|
| 電話（グローバルサポート等） | 電話が可能 | サインイン不要で開始できる場合がある。急ぎのときに強い | 国/地域・言語でつながりやすさが変わる。待ち時間が長いことも |
| Azureポータルからのサポートリクエスト | 別アカウント/別テナントでAzureに入れる、または契約情報がある | ケースとして追跡しやすい。証跡を残しやすい | 完全にサインイン不能だと使いにくい。代理で起票する工夫が必要 |
| Microsoft 365管理センター経由 | 別の管理者アカウントが生きている、別テナントで入れる等 | Microsoft 365側の影響もまとめて相談しやすい | テナントブロックの解除自体は結局バックエンド対応が必要になりやすい |
| パートナー/CSP/リセラー経由 | 契約形態によっては利用可能 | 窓口が一本化され、やりとりが速くなることがある | 契約スキームに依存。連絡経路の確認が必要 |
記事のテーマである「フォーラムの案内」に沿うなら、電話窓口への連絡が現実的な第一手です。電話がつながりにくい地域・言語の課題がある場合は、次の工夫が役に立ちます。
- 最初に「英語対応へ転送できるか」を確認する（英語担当のほうが手続きが早い場合がある）
- 案内されている別番号や時間帯を試す（つながりやすさが大きく変わることがある）
- 社内の英語対応者、契約担当、パートナー窓口を巻き込み、一本化して連絡する
サポートに伝える要点：最初の1分で「テナントブロック解除」の話に乗せる
サポートは受付から技術担当へエスカレーションするまでに段階があります。最初の窓口で話が逸れると時間を消耗しやすいので、最初から論点を明確にするのがポイントです。
伝えるべき要点（そのまま読めるテンプレ）
以下を自社情報に置き換えて伝えると、会話がスムーズになりやすいです。
Microsoft Entra / Azure のテナントでサインインができず、エラーコード AADSTS5000225「This tenant has been blocked due to inactivity」が表示されます。フォーラムではサポートでのアンブロック対応が必要と案内されました。テナントのブロック解除可否と、削除に進む可能性があるかも含めて至急確認したいです。
Tenant ID：［ここにTenant ID］
Correlation ID：［ここにCorrelation ID］
Timestamp：［ここにTimestamp］業務影響：［例：Azureポータルに入れず、運用中のリソース/認証基盤に影響。復旧が必要な理由］
特に「AADSTS5000225」「tenant has been blocked due to inactivity」「Tenant ID」の3点が揃うと、一般的なサインイントラブル（パスワードやMFA）ではなく、テナント状態の問題だと理解されやすくなります。
すでに問い合わせ（ケース）が進行中なら、重複依頼を避ける
コミュニティの案内にもある通り、既にケースが動いている場合に、別窓口から重複で問い合わせると、かえって混乱することがあります。もしケース番号（サポートリクエストID）があるなら、社内で次を決めて一元管理してください。
- 窓口担当（サポートと話す人）を1人に寄せる
- ケース番号、やりとり履歴、提出した情報（Tenant ID等）を共有フォルダ/チケットに集約
- 追加連絡が必要な場合も、原則そのケース番号に紐づけて追記する
「テスト/検証用途」なら、新規テナント作成のほうが早い場合がある
スレッド内の提案として、「テスト用途なら作り直したほうが早い」という現実的な判断も出ています。これは、復旧がサポート依存で時間が読めないケースがあるためです。
| 状況 | おすすめ判断 | 理由 | 注意点 |
|---|---|---|---|
| 完全な検証用で、重要データなし | 新規テナント作成 | 最短で環境を再開できる | ドメイン検証やアプリ登録をやり直す必要がある |
| 業務利用/本番利用、またはデータ・設定が積み上がっている | サポートで復旧を最優先 | 失うと影響が大きい資産がある | 復旧までの暫定運用（別テナントでの切り替え等）も検討 |
| 判断がつかない（影響範囲が不明） | 復旧依頼を開始しつつ、並行で代替案を用意 | 時間を無駄にしない | 重複依頼にならないようケース管理を徹底 |
「作り直せばいい」と割り切れるかどうかは、次の観点で決めると迷いにくいです。
- そのテナントで運用中のAzureリソースがあるか
- Microsoft 365（Exchange/SharePoint/Teams等）を使っていたか
- Entra IDでアプリ認証（App registration / Enterprise app）を運用していたか
- カスタムドメイン（独自ドメイン）を既に検証済み/本番使用していたか
問い合わせ前に整理しておくと強い「追加情報」
サポートは「何をどこまでやったか」を見て次の指示を出します。次の情報を持っていると、やりとりが短くなることがあります（必須ではありません）。
- 直近で行った変更（課金設定、ドメイン追加、ユーザー作成、ライセンス付与、アプリ登録、セキュリティ既定値の変更など）
- 最初に発生を確認した日時と、再現する頻度（常に発生／特定のユーザーのみなど）
- エラーが出るURLや画面（Azureポータル、Entra管理センター、Microsoft 365管理センター等）
- 社内の利用目的（検証/開発/本番）と優先度
「作ったばかりなのに非アクティブ扱い」への現実的な向き合い方
実際に「作成直後でも同じ表示になる」という声があり、違和感を覚えるのは自然です。ただ、重要なのはここで原因を断定しようとしすぎないことです。なぜなら、外部からはテナントの内部状態や判定理由を確認できず、復旧操作がサポート側の領域になりやすいからです。
この状況では、次の順番が最も合理的です。
- 期限の有無を意識して、まず即日でサポートに接続する
- 必要情報（Tenant ID / Correlation ID / Timestamp）を提出して、復旧判断に乗せる
- 業務影響があるなら、復旧までの暫定策（別テナント、別認証方式）も並行で検討する
再発防止：非アクティブ扱いで困らないための運用ヒント
非アクティブ判定の詳細条件は公開されないことも多く、また契約形態や状態によって挙動が変わる可能性があります。そのため「これをやれば必ず防げる」と断言はできませんが、実務上は次のような運用が“困りにくさ”につながります。
本番・長期利用のテナントは「定期的に使われている状態」を作る
- 定期的に管理者がサインインして、テナント状態を目視確認する（四半期に1回でも良いのでルーチン化）
- 運用台帳に「最後に確認した日」「担当者」「サブスクリプション/ライセンス状況」を残す
- AzureやMicrosoft 365を使うなら、請求・契約・更新の担当を明確にする
管理者ロスト対策（ブレークグラス）の設計をする
今回のような“テナント側のブロック”は別問題ですが、復旧時に必要な情報を揃えるうえでも、管理設計があると強いです。
- 緊急用管理者アカウント（ブレークグラス）を作り、保管・監査ルールを決める
- 管理者のメール・電話・契約情報が属人化しないよう、組織で管理する
- テナントID、既定ドメイン（onmicrosoft.com）、主要管理者UPNを台帳化する
検証テナントは「使い捨て前提」で設計し、重要資産を置かない
- 検証が終わったら即削除、または明確に「保管する理由」を作る
- 検証テナントに独自ドメインや重要なアプリ登録を持ち込まない（持ち込むなら本番同様の管理）
- 検証用はテンプレート化して作り直せるようにし、復旧に依存しない
よくある質問（FAQ）
AADSTS5000225は、ユーザーを作り直したりパスワードを変えれば直りますか？
このエラーはメッセージ上「tenant（テナント）」がブロックされた状態を示しており、ユーザー単体の対処（パスワード変更、MFA再登録）だけで解消しないケースが多いです。まずはエラー画面の情報を確保し、サポートへ連絡する方針が現実的です。
管理者でも入れない場合、セルフサービスでアンブロックできますか？
コミュニティ案内では、フォーラム側（モデレーター）ではバックエンド操作ができず、解除はサポート対応が必要とされています。まずは電話や契約窓口など、サインイン不要で始められる経路から動くのが安全です。
Tenant IDが分からないときはどうすればいいですか？
理想は台帳化ですが、手元に無い場合は、エラー画面に表示される情報、既知の既定ドメイン（xxxx.onmicrosoft.com）、過去に作った管理者UPN、関連する契約情報（請求メールや注文情報）など、紐づけに使える材料を集めます。サポートに「Tenant ID不明」と正直に伝え、手元の情報で照合してもらう形になります。
「削除される」と言われたら、何が失われますか？
テナントは認証とディレクトリの土台です。削除に至ると、ユーザー、グループ、アプリ登録、ポリシーなどの設定にアクセスできなくなり、AzureやMicrosoft 365等の利用にも影響が及ぶ可能性があります。重要テナントの場合は、削除に到達する前にサポートで状態確認を進めるのが最優先です。
電話がつながらない・言語が不安です。どうしたらいいですか？
つながりやすい時間帯を変える、英語対応への転送を依頼する、契約担当やパートナー（CSP/リセラー）経由で窓口を確保するなど、経路を複線化するのが現実的です。ケース番号が出た後は、重複依頼を避けつつ、そのケースで追いかける方が進みやすくなります。
まとめ：AADSTS5000225は「時間勝負」。情報を揃えてサポートへ
AADSTS5000225「This tenant has been blocked due to inactivity」は、テナント自体がブロックされている可能性が高く、フォーラムや手元操作での解除が難しいトラブルです。コミュニティ案内では、放置が削除につながり復元不能になり得るとされるため、まずはエラー情報（Tenant ID / Correlation ID / Timestamp）を確保し、Microsoftサポートに早急に連絡してください。
検証用途で重要資産が無いなら新規テナント作成も現実的ですが、業務影響がある場合は復旧の一本化・ケース管理を徹底し、最短で復旧判断に乗せることが鍵になります。
コメント