Azure ポータルや Microsoft 365 にサインインしようとした瞬間、「AADSTS5000225: このテナントは非アクティブのためブロックされました」と表示されると、業務が一気に止まってしまいます。このエラーはユーザー設定レベルでは解消できない「テナント単位のブロック」であり、放置するとテナント自体が削除されてしまう可能性もあります。この記事では、原因の整理からサポートへの具体的な依頼文、再発防止の運用例まで、実務担当者がそのまま使える形で詳しく解説します。
AADSTS5000225 エラーとは？概要とメッセージの意味
「AADSTS5000225: このテナントは非アクティブのためブロックされました」というエラーは、Microsoft Entra ID（旧 Azure AD）のテナント自体がブロックされている状態を示します。ユーザー アカウントのロックアウトや条件付きアクセスとはレイヤーが異なり、テナントに属するユーザー・アプリケーションがまとめて影響を受けます。
実際のエラー画面では、次のような情報が表示されることが多いです。
| 項目 | 例 |
|---|---|
| エラーコード | AADSTS5000225 |
| メッセージ | This tenant has been blocked due to inactivity. （このテナントは非アクティブのためブロックされました） |
| Trace ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| Correlation ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| Timestamp | 2025-06-23 17:57:10Z など（UTC 時刻） |
この時点で重要なのは、「ユーザーのパスワード変更や多要素認証の設定変更では解消しない種類の問題」であることを正しく認識することです。
なぜ自力解除できないのか ― テナント ブロックの仕組み
AADSTS5000225 はMicrosoft 側のバックエンドでテナントがブロックされている状態を指します。テナントが長期間利用されず、「非アクティブ」と判定された場合、OMS Commerce System などの内部システムによってログインブロックがかかり、その結果としてサインイン時に AADSTS5000225 が返されます。
Microsoft の公開情報やサポート回答では、代表的な目安として次のような流れが案内されています。
| タイミング | 状態 | 概要 |
|---|---|---|
| 請求サイクル終了後 約 200 日以上非アクティブ | 「非アクティブ テナント」としてマーク | サインインやアクティビティが長期間ないテナントを整理対象として検出。 |
| 非アクティブ判定後 | ログイン ブロック開始 (AADSTS5000225) | サインインを試みると「このテナントは非アクティブのためブロックされました」と表示。 |
| ブロックから約 20 日前後 | テナント削除 | 猶予期間を過ぎるとテナントが完全に削除され、復旧不能になると案内されているケースが多い。 |
具体的な日数（約 200 日／20 日）は、Microsoft のテナント ライフサイクル ポリシーに基づくものであり、今後変更される可能性もあります。最新情報は Microsoft Learn の「Tenant lifecycle」および「Tenant inaccessible due to inactivity」に関するドキュメントを必ず確認してください。
重要なのは、このブロック処理はテナントの内部状態に対するシステムフラグであり、ポータル操作や PowerShell、Graph API では解除できないという点です。解除は Microsoft サポートのバックエンド作業に限定されます。
結論：AADSTS5000225 は自力解除不可、Microsoft サポートへの依頼が唯一の解決策
まとめると、AADSTS5000225 が発生した場合のポイントは次の 3 つです。
- 自力解除はできない（ポータルやスクリプトで触れるレイヤーの設定ではない）。
- Microsoft サポートに「テナントのアンブロック」を依頼するのが唯一の解決ルート。
- 猶予期間を過ぎるとテナントが削除され、二度と復旧できない可能性がある。
したがって、「とりあえず様子を見る」「あとで問い合わせる」は非常にリスクが高く、エラーを確認したら即座にサポート チケットを起票することが重要です。
どこに・何を伝えればよいか：アンブロック依頼の全体像
アンブロック依頼は、通常、次のいずれかの窓口から行います。
- Microsoft Entra 管理センター（entra.microsoft.com）の「ヘルプとサポート」
- Microsoft 365 管理センター（admin.microsoft.com）のサポート
- Azure ポータル（portal.azure.com）のサポート
- 契約しているサポート プラン（Premier / Unified / Partner 経由など）の専用窓口
サインイン自体ができない場合は、別の有効なテナントや別環境の管理者アカウントからサポートを起票し、問題のテナント ID を伝える方法が実務的です。また、パートナー企業経由で契約している場合は、まずパートナーの管理者に連絡し、パートナー側からサポート依頼を上げてもらうのがスムーズです。
サポートに依頼する前に集めるべき情報
サポート側が最短で状況を把握できるよう、次の情報をあらかじめ整理しておきます。これはそのままチケットに貼り付ける想定で、最低限そろえておきたい必須情報です。
| カテゴリ | 具体的な情報 | 取得元の例 |
|---|---|---|
| テナント情報 | ・テナント ID（Directory ID / GUID） ・テナント名 ・プライマリ ドメイン（例: contoso.onmicrosoft.com） | Entra 管理センターの「テナント プロパティ」など |
| エラー情報 | ・エラーコード：AADSTS5000225 ・Trace ID ・Correlation ID ・Timestamp（UTC） | エラー画面の「詳細を表示」、またはサインイン ログ |
| 影響範囲 | ・影響ユーザー数／代表ユーザー ・影響を受けているサービス（Teams / Exchange / 自社アプリ 等） ・アクセスしようとしている URL（portal.azure.com など） | 利用者からのヒアリング、既存のサービス設計書 |
| 課金・契約情報 | ・サブスクリプションの種類（例: Microsoft 365 Business, Azure Pay-As-You-Go） ・請求アカウントの状態（有効 / 解約済 / 不明） ・最近の支払い状況（未払いの有無） | 請求管理ポータル、請求担当者への確認 |
| 連絡体制 | ・全体管理者（全テナント管理者）の氏名／メール アドレス ・課金管理者や契約窓口の情報 ・連絡可能な電話番号（任意） | 社内管理台帳、人事システム等 |
この記事冒頭で示したチェックリストを HTML テーブル形式で整理すると次のようになります。
| チェック項目 | 準備状況 | メモ |
|---|---|---|
| テナント ID（GUID）／テナント名 | □ 未 / □ 済 | |
| エラーコード（AADSTS5000225） | □ 未 / □ 済 | Trace ID, Correlation ID, UTC 時刻もセットで控える |
| 影響ユーザー／アプリ／URL | □ 未 / □ 済 | 代表的な利用パターンを簡潔に |
| 課金・サブスクリプション状態 | □ 未 / □ 済 | 有効 / 解約済 / 不明 など |
| 連絡先（全体管理者・課金管理者） | □ 未 / □ 済 | 日中連絡可能な窓口を明記 |
サポート チケットの起票手順（Entra / Azure / Microsoft 365 共通イメージ）
ポータルによって画面構成は異なりますが、概ね次の流れでサポート チケットを起票できます。
- 有効なテナント、またはパートナー テナントの管理者アカウントでポータルにサインインする。
- 画面右上または左下のメニューから「ヘルプ & サポート」を開く。
- 「新しいサポート要求」または「サポート リクエストの作成」を選択する。
- カテゴリに「サインイン / 認証」「ID とアクセス管理」などを選び、問題の説明欄に
- エラーコード：AADSTS5000225
- テナントのアンブロックが必要であること
- すでに収集済みのテナント情報・エラー情報・影響範囲
- 影響度や優先度の項目には、業務影響（例: 全社員が Teams にサインインできない）を具体的に記入する。
- 連絡先情報（メールアドレス、電話番号）を入力し、送信する。
ここで大事なのは、「技術的なトラブルシューティング」ではなく「バックエンドでのテナントアンブロック作業」を依頼するという点を明示することです。サポート担当者の初動を大きく短縮できます。
Trace ID / Correlation ID / UTC 時刻の確認方法
サポートにとって、Trace ID・Correlation ID・UTC 時刻は裏側のログをピンポイントで検索するための鍵です。次のように控えておきましょう。
- サインイン エラー画面に「Details」や「詳細を表示」のリンクがあればクリックし、表示された内容を丸ごとコピーしてメモ帳などに貼り付ける。
- もしまだテナントにサインインできる管理者がいる場合は、Entra 管理センターの「サインイン ログ」から失敗イベントを開き、そこに表示されるエラー詳細、Trace ID、ログイン時刻を取得する。
- 時刻は「UTC」で記載されるため、日本時間（JST）と区別して記載する（例: UTC 2025-06-23 08:00:00 は JST 17:00:00 など）。
ゲストとして招待された別組織のテナントがブロックされている場合
最近は B2B コラボレーションが当たり前になり、他社の Microsoft Entra ID テナントに「ゲストユーザー」として参加しているケースも多くあります。この場合、次のようなシナリオが起きます。
- 自社のテナントには問題なくサインインできる。
- しかし、他社の Teams や SharePoint にアクセスしようとすると AADSTS5000225 が出る。
この状況では、ブロックされているのは他社のテナントであり、自社側からは解除できません。必要な対応は次のとおりです。
- 相手組織の窓口担当者（システム管理者、プロジェクト担当者など）に、発生しているエラー メッセージをそのまま伝える。
- 「テナントが非アクティブ扱いとなりブロックされているため、貴社側の全体管理者から Microsoft サポートへアンブロック依頼を行ってほしい」旨を説明する。
- 可能であれば、スクリーンショットやエラーの詳細情報（Trace ID、Correlation ID、UTC 時刻）も送付する。
サポート依頼に使えるテンプレート（コピペ用）
実際にサポートへ送る際に、そのまま利用できるテンプレートを用意しました。必要に応じて書き換えて使用してください。
件名：AADSTS5000225 によるテナントブロック解除のお願い（バックエンド対応の依頼）
概要：
サインイン時に「AADSTS5000225: このテナントは非アクティブのためブロックされました」が発生し、アクセス不能です。
バックエンドでのアンブロックをご対応ください。
テナント情報：
- テナント ID（Directory ID）：<GUID>
- テナント名／ドメイン：<contoso.onmicrosoft.com / 独自ドメイン>
- サブスクリプション／請求状態：<有効／失効／不明 等>
エラー詳細：
- エラーコード：AADSTS5000225
- Trace ID：<値>
- Correlation ID：<値>
- 発生時刻（UTC）：<YYYY-MM-DD HH:MM:SSZ>
影響範囲：
- 影響ユーザー：<人数や代表ユーザー>
- 影響サービス／アプリ：<Teams / Exchange / 自社アプリ 等>
- ビジネス影響：<高/中/低、具体的な影響>
ご対応希望：
- テナントのアンブロック実施（バックエンド）
- 必要な追加情報があればご連絡ください
メール経由の問い合わせでも、ポータル上のチケットでも、基本的にはこのテンプレートをベースにすれば過不足のない情報を伝えられます。
課金状態・テナント ライフサイクルと AADSTS5000225 の関係
AADSTS5000225 はあくまで「テナントが非アクティブと見なされ、ブロックされている」ことを示すエラーですが、その裏には必ず課金状態やライセンス状態があります。代表的なパターンを整理しておきます。
| 状態 | よくあるシナリオ | リスク | 対応のポイント |
|---|---|---|---|
| 有料サブスクリプション契約中 | 本番環境の Entra ID / Microsoft 365 テナントで、しばらく利用が減っていた。 | 業務停止のインパクトが大きい。誤って非アクティブ扱いになっている場合も。 | 即座にサポートに連絡し、「本番利用中でありアンブロックが必要」と強調する。 |
| 試用版 / PoC 用テナント | PoC 期間中だけ利用し、その後放置。 | 削除されると構成情報が失われ、再現が難しい場合がある。 | 重要な検証結果が残っているなら、早めに復旧依頼。不要なら新規テナントで作り直す判断も。 |
| 既に解約済みのテナント | 会社合併・事業撤退などで不要になったテナント。 | 復旧してもコストがかかるだけの場合もある。 | 本当に復旧が必要か、法的・監査要件などを踏まえたうえで判断する。 |
| 個人の Microsoft アカウントと混同 | 個人用アカウントに送られてきた「Entra ID テナントが非アクティブ」というメール。 | 内容を誤解してフィッシングと思い込んだり、逆に偽メールに誘導されるリスク。 | メールが本物かどうかを慎重に確認し、心配であれば Microsoft 正規サポートに問い合わせる。 |
Microsoft の Q&A などでは、「200 日以上非アクティブなテナントに対してログインブロックを行い、その約 20 日後に削除する」という説明が繰り返し示されています。 ただし、これらはあくまで現在の目安であり、将来的にポリシーが変更される可能性もあります。
よくある質問と誤解しやすいポイント
Q1. 料金を支払えば自動でブロック解除される？
A. いいえ。未払いの解消や新たなサブスクリプション購入は重要ですが、テナントに付いた「ブロック状態」のフラグは自動では元に戻りません。必ず Microsoft サポートに「AADSTS5000225 によるテナントブロック解除」を明示して依頼する必要があります。
Q2. 全体管理者がいなくなってしまった場合は？
全体管理者が退職してしまったり、連絡がつかない場合でも、会社としてテナントを保持しているなら、次のような手順を検討します。
- 人事部門や経理部門に、Microsoft との契約書や請求書の控えが残っていないか確認する。
- ドメインの WHOIS 情報や DNS 管理者の連絡先から、所有企業の情報を証明できる資料を集める。
- それらをもとに Microsoft サポートへ連絡し、「テナント所有者としての確認手続き」を相談する。
Q3. ブロックから 20 日以上経っていると言われたら？
もしサポートから「既にテナントが削除されており、復旧は不可能」と案内された場合は、残念ながら元のテナントを取り戻すことはできません。その場合は、次のステップに切り替える必要があります。
- 新しい Entra ID テナントを作成する。
- 必要なユーザー・グループ・アプリ登録などを再作成する。
- オンプレミスの AD と連携している場合は、Azure AD Connect / Entra Connect の再構成を行う。
このような「作り直し」が発生しないよう、日頃からテナント ライフサイクルおよびアクティビティの管理を徹底しておくことが重要です。
再発防止のための運用設計例
AADSTS5000225 は一度起きるとインパクトが大きいものの、日頃の運用次第でかなりの部分を防ぐことができます。ここでは具体的な運用例をいくつか紹介します。
定期アクティビティの確保
- 少なくとも月に 1 回は、全体管理者が Entra 管理センターにサインインしてテナントの状態を確認する。
- 監視用のサービス アカウントやアプリケーションから、定期的にトークン取得（Client Credentials Flow など）を行い、ログイン アクティビティを残す。
- Azure リソースを使っている場合は、簡易なヘルスチェック ジョブ（Function / Logic Apps 等）を定期実行する。
アラート・通知の活用
- Microsoft から送られてくる「テナント非アクティブ」「購入を完了してください」といったメールを、迷惑メールに入らないようドメイン許可する。
- 重要な通知を受け取るメールボックスは、個人ではなく共有メールボックス（例: [email protected]）にし、担当者が変わっても引き継げるようにする。
- 監視ツール（SIEM や監視 SaaS）と連携して、異常なサインイン失敗や課金関連のアラートを検知できるようにする。
権限と責任の二重化
- 全体管理者（Global Administrator / Entra ID Administrator）を 1 人だけにせず、最低でも 2～3 名を登録しておく。
- 課金管理者（Billing Administrator）も複数名を登録し、片方が退職しても支払いが滞らないようにする。
- テナント情報・請求情報・サポート窓口情報を社内 Wiki や IT 資産管理システムにまとめておき、属人化を防ぐ。
ドキュメント整備と「非常時 Runbook」
万一 AADSTS5000225 が発生しても慌てず対応できるよう、次のような「Runbook（手順書）」を用意しておくと安心です。
- エラー発生時の初動（誰が何を確認するか）
- サポート チケットに添付する情報一覧
- 社内への一次アナウンス テンプレート（「現在、Entra テナントのブロックにより一部サービスが利用できません」など）
- 復旧後の確認項目（サインインテスト、アプリ動作確認、ログの確認）
管理者向けクイック チェックリスト（保存版）
最後に、実務担当者が手元に置いておけるよう、「AADSTS5000225 が発生したときの確認・対応項目」を一覧化しておきます。印刷して机の横に貼っておいてもよいレベルの内容です。
| フェーズ | 確認・実施内容 | 完了 |
|---|---|---|
| 1. 事象確認 | ・エラーコードが AADSTS5000225 であることを確認 ・エラー メッセージ全文をコピーして保存 | □ |
| 2. 情報収集 | ・テナント ID / テナント名 / ドメイン ・Trace ID / Correlation ID / UTC 時刻 ・影響ユーザー数と代表ユーザー ・影響サービス / アプリ / URL ・サブスクリプション / 請求状態 | □ |
| 3. 社内連携 | ・IT 責任者、課金担当者に事象を共有 ・必要に応じて経営層やプロジェクトオーナーへ速報 | □ |
| 4. サポート依頼 | ・Entra / Azure / Microsoft 365 のサポートからチケット起票 ・「テナントのアンブロック（バックエンド対応）」を明記 ・テンプレートを利用して情報を漏れなく送付 | □ |
| 5. 復旧確認 | ・代表ユーザーでのサインインテスト ・主要アプリ（Teams, Exchange, SharePoint 等）の動作確認 ・サインイン ログに異常がないか確認 | □ |
| 6. 再発防止 | ・定期サインインやジョブの設定 ・通知メールの受信設定・共有メールボックス化 ・権限の二重化、Runbook 更新 | □ |
まとめ：AADSTS5000225 発生時に押さえるべき要点
ここまでの内容を、改めて短く整理します。
- AADSTS5000225 は「テナント単位のブロック」を示すエラーであり、ポータル操作やユーザー設定では解除できない。
- 解決策は Microsoft サポートにテナントのアンブロックを依頼することのみであり、その際にはテナント ID、Trace ID、Correlation ID、UTC 時刻、影響範囲、課金状態などをセットで伝える。
- 長期間の非アクティブや請求状態の問題が背景にあることが多く、200 日以上の非アクティブ ＋ 約 20 日の猶予といったポリシーが案内されているが、値は変更される可能性があるため、常に公式ドキュメントを確認する。
- 再発防止には、定期的なサインインやアプリからのトークン取得、通知メールの適切な受信、権限・責任の二重化、Runbook 整備といった日常運用の仕組み化が不可欠。
AADSTS5000225 はインシデントとしては重めですが、ポイントを押さえて落ち着いて対応すれば、テナントを守りつつ業務への影響を最小限に抑えることができます。この記事の内容を、自社の運用設計や手順書にぜひ取り込んでみてください。
コメント