Microsoft Entra ID（旧Azure AD）テナントが長期間使われていないと、突然「AADSTS5000225: This tenant has been blocked due to inactivity」でサインインできなくなることがあります。届いたメールが本物かを確認しつつ、復旧できる期限と具体的な対応手順、新規テナント作成が必要なケースまでを整理します。
最初に押さえる結論：いま何が起きていて、何から着手すべきか
「Microsoft Entra ID テナントが非アクティブ扱いになりブロックされた」というメールを受け取り、メール内の購入ボタンからサインインしようとしても AADSTS5000225 が出る場合、状況は大きく2つに分かれます。
| 状況 | 起きていること | 現実的な打ち手 |
|---|---|---|
| ブロックから日が浅い（猶予が残っている） | テナントは「停止・保留」の状態。サインインが制限されるが、復旧ルートが残っている可能性がある。 | ポータルに直接アクセスして通知を確認し、購入・課金情報の更新を試す。難しければ Microsoft サポートへ。 |
| ブロックから時間が経過している（猶予を過ぎている） | テナントが削除済み（または削除プロセスが完了）となり、一般的に元に戻せない。 | 新しい Entra ID テナントを作成し、ユーザーや設定を作り直す。必要ならドメイン再利用の相談をサポートへ。 |
また、こうしたメールはフィッシングに悪用されやすいため、メール内リンクを踏む前に正当性確認を行うのが安全です。本文では、確認ポイントと対応手順を「すぐ試せる順」に並べています。
Microsoft Entra ID テナントとは何か：混乱しやすい用語を整理
復旧の判断を誤りやすいポイントが「テナント」「サブスクリプション」「アカウント」の関係です。メールに「購入」「課金」などが出てくるのは、テナント（IDの箱）とサブスクリプション（請求の契約）がセットで運用されているからです。
| 用語 | 一言でいうと | このトラブルとの関係 |
|---|---|---|
| Microsoft Entra ID テナント（旧 Azure AD テナント） | 組織のID・認証の入れ物（ユーザー、グループ、アプリ登録、条件付きアクセス等が入る） | 非アクティブ扱いになると「サインイン自体」がブロックされることがある。 |
| Azure サブスクリプション | 課金の契約（リソースの作成・課金の単位） | 有効なサブスクリプションがなく長期間利用がないと、整理対象になるケースがある。 |
| Microsoft アカウント（個人）/ 仕事または学校アカウント（組織） | サインインに使うID | 同じメールアドレスでもアカウント種別や所属テナントが異なると、サインイン先がズレてハマりやすい。 |
特に「2023年ごろに Azure アカウントを作って放置していた」というケースでは、無料枠や試用、検証用のままテナントだけが残り、一定期間後に整理対象になることがあります。
メールの正当性確認：フィッシング対策として必ず行うチェック
まずは「そのメールが本当に Microsoft から来たものか」を確認します。仮に内容が正しくても、リンク先が偽物なら資格情報（ID/パスワード、MFA）を盗まれるリスクがあります。
| 確認ポイント | チェック方法 | 安全側の判断 |
|---|---|---|
| 差出人ドメイン | 表示名ではなくメールアドレスのドメインを見る（例：@microsoft.com など） | 不自然なドメイン、似せ字（micros0ft 等）があれば要注意。 |
| リンク先URL | ボタンやリンクにマウスオーバーして表示されるURLを確認 | 不安ならクリックせず、公式ポータルへ手入力でアクセスする。 |
| 要求内容の不自然さ | 「今すぐ支払い」「口座情報を再入力」など煽りが強いか | 焦らせる文言が強いほど疑う。操作は公式ポータルから行う。 |
| 添付ファイル | 添付の有無、拡張子（.html, .zip, .iso など） | 基本は開かない。Microsoft の案内はポータル通知で確認できることが多い。 |
不安な場合は、メール内リンクは使わず、ブラウザで次の公式サイトに直接アクセスして状況を確認してください。
サインイン後、「ディレクトリの切り替え（別のテナントへ切り替え）」ができる場合もあるので、意図したテナントに入れているかも併せて確認します。
エラー AADSTS5000225 の意味：なぜサインインが拒否されるのか
AADSTS5000225: This tenant has been blocked due to inactivity は、文字どおり「非アクティブなためテナントがブロックされた」状態を示すサインインエラーです。よくある誤解は「パスワードが違う」「MFAが壊れた」と思い込むことですが、このエラーはアカウント側ではなくテナント側の状態で弾かれている点が重要です。
今回のメール文面（例：200日以上非アクティブ、2025年8月1日までに購入手続きなど）から読み取れるのは、Microsoft が「使われていないテナント」を整理する運用の中で、課金や利用がないテナントを段階的に停止・削除するという流れです。
よくあるタイムライン（目安）
メールや画面の案内に「200日」「20日」といった期限が出ている場合は、その期限が最優先です。一般的な目安としては次のように段階が進みます。
| 段階 | 目安 | 状態 | ユーザーに起きること |
|---|---|---|---|
| 非アクティブ判定 | 課金サイクル終了後に長期間利用がない（例：200日以上） | 整理対象としてマークされる | 予告メールが届く、ポータルで注意表示が出ることがある |
| ブロック（サインイン制限） | 一定期間経過後 | テナントがブロック | AADSTS5000225 が出てサインインできない／操作できない |
| 削除（復旧困難） | ブロック後の猶予を過ぎる（例：20日） | テナント削除が完了 | 基本的に元に戻せない。再作成が必要になることが多い |
ここで重要なのは、「ブロックされた＝即削除」ではない点です。猶予が残っている間は、手続きやサポート対応で復旧できる可能性があります。一方で、猶予を過ぎると復旧が極めて難しくなるため、判断は早いほど有利です。
ブロックから猶予が残っている場合：復旧のために試すべき手順
「まだ猶予が残っていそう」「ブロックされたばかりかもしれない」という場合は、次の順で進めるのが現実的です。ポイントは、メールの購入ボタンに頼らず、公式ポータルで状況を確認することです。
手順：ポータルへ直接アクセスして、通知・バナーを確認する
- ブラウザのシークレット/プライベートウィンドウで、Microsoft Entra 管理センターへアクセスします。
- 該当の管理者アカウントでサインインを試みます（可能ならグローバル管理者）。
- サインイン画面やエラー画面に表示されるテナント名やテナントID、エラーコードを控えます。
- サインインできた場合は、画面上部の通知（バナー）や「状態」「請求関連」のメッセージを確認し、案内に沿って購入・更新を実施します。
サインインできない場合でも、エラー画面にCorrelation ID（相関ID）やタイムスタンプが表示されることがあります。これはサポートに問い合わせる際の重要情報なので、スクリーンショットかメモで保存しておきます（外部に共有しない範囲で）。
手順：購入・課金情報の更新（できる範囲で）
メールに「購入が必要」「2025年8月1日までに手続き」とある場合、対象は Azure サブスクリプションや関連サービスの更新であることが多いです。ポータルで操作できる場合は次を確認します。
| 確認・操作 | 目的 | 見る場所の例 |
|---|---|---|
| 有効なサブスクリプションがあるか | 課金契約が失効していないか確認 | Azure ポータル > 「サブスクリプション」 |
| 支払い方法の登録・更新 | カード期限切れ等で更新できないケースを潰す | Azure ポータル > 「コスト管理 + 請求」 |
| 連絡先メールの確認 | 重要通知が届く先を最新化 | 請求プロファイル、アカウントセンター等 |
なお、テナントがブロック状態だとポータル内の操作自体が進まないことがあります。その場合は無理に試行錯誤せず、次の「サポートへの連絡」で情報をそろえる方が早いケースが多いです。
うまくいかないときの切り分け（ありがちな落とし穴）
- ディレクトリが違う：同じアカウントでも、サインイン後に「別のディレクトリ」に入ってしまうことがあります。ディレクトリ切り替えで目的のテナントを選び直してください。
- 複数アカウントの混在：個人の Microsoft アカウントと会社のアカウントを同じブラウザで使っていると、意図しない方でサインインしてエラーになります。シークレットウィンドウを使うと切り分けが容易です。
- キャッシュ/クッキー：古いセッションが残っていると、ディレクトリ切り替えがうまくいかないことがあります。一度サインアウトし、クッキーを削除して再試行します。
Microsoft サポートに連絡する際のチェックリスト（復旧を依頼する情報）
ブロック解除や復旧は、状況によってはサポート側の操作が必要になります。問い合わせ時に情報が不足すると往復が増えがちなので、次の項目を最初から用意しておくとスムーズです。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| テナントID またはテナントの初期ドメイン | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / xxxx.onmicrosoft.com | 対象テナントの特定に必須 |
| 影響ユーザーの UPN | [email protected] | 誰がサインインできないかを明確化 |
| エラーコード | AADSTS5000225 | 原因の分類と調査の起点 |
| Correlation ID | エラー画面に表示されるID | ログ追跡に使われることが多い |
| 失敗時刻（タイムスタンプ） | 2025-xx-xx 12:34 (UTC など) | ログの検索範囲を絞れる |
| ビジネス影響 | 「このテナントで運用しているアプリが停止する」等 | 優先度判断や復旧の必要性が伝わる |
問い合わせ文は、長文よりも「事実＋期限＋依頼」を短くまとめるのが通りやすいです。例として、次のように書くと状況が伝わりやすくなります。
件名：Entra ID テナントが非アクティブでブロック（AADSTS5000225）されサインイン不可
・テナントID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・影響ユーザー：[email protected]（グローバル管理者）
・エラー：AADSTS5000225: This tenant has been blocked due to inactivity
・Correlation ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・発生時刻：2025-xx-xx xx:xx（UTC/ローカル）
・状況：メールで「200日以上非アクティブ」「2025年8月1日までに購入手続き」と案内。購入ボタンからはサインインできず。
・依頼：テナントの復旧（または復旧可否の確認）と、継続利用のために必要な手続きの案内をお願いしたい。猶予を過ぎている場合：復旧が難しいときに取るべき対応
ブロック後の猶予を過ぎている場合、テナントが削除済みと見なされ、一般的には復旧できないことが多いです。このとき重要なのは、「復旧に固執して時間を失う」よりも、「新しいテナントで再構築する」方が早く、確実なケースが多いという点です。
復旧が難しいときに影響する範囲
テナントが削除されると、次のような要素は基本的に新規作成が必要になります。
- ユーザー、グループ、ロール割り当て
- アプリ登録（App registrations）、エンタープライズアプリ、証明書/シークレット
- 条件付きアクセス、MFAのポリシー、セキュリティ設定
- 外部ID連携、ゲストユーザー設定
- （紐づくものがあれば）Azure サブスクリプションや課金関連の構成
一方で、「過去の Azure リソースが残っているか」はケースバイケースです。検証用でリソースを作っていなければ影響は小さいことが多いですが、もし本番運用していたなら早急にサポートへ連絡し、現状（削除済みか、復旧余地があるか）の確認を優先してください。
「復旧」と「新規テナント作成」の判断早見表
| 観点 | 復旧を狙う | 新規テナント作成 |
|---|---|---|
| 猶予期間 | 残っている可能性がある | 猶予を過ぎている/不明だが急ぐ |
| 本番データの有無 | 本番ID/アプリがあり影響が大きい | 検証用で再作成しても痛手が少ない |
| 再構成コスト | 低い（設定が少ない）なら復旧トライ | 高いが復旧が見込めないなら割り切る |
| 時間 | サポート往復が発生する可能性 | 手順どおり進めれば自力で前に進める |
新しい Microsoft Entra ID テナントを作成してやり直す手順（再構成の実務）
復旧が難しい場合は、新しいテナントを作成し、必要な構成を作り直します。ここでは「再発防止」まで含めた実務の流れをまとめます。
テナント作成時のポイント
- 管理者アカウントを複数用意：少なくとも2名（または2つ以上）のグローバル管理者を作り、片方が使えなくなっても詰まらない構成にします。
- ブレークグラス（緊急用）を用意：MFA障害時に備えた緊急用アカウントを1つ作り、保管・運用ルールを決めます。
- 連絡先・請求情報を最初に整える：「メールが届かず放置」にならないよう、通知先メールボックスを運用に組み込みます。
再構成の流れ（おすすめ順）
- テナント（ディレクトリ）を作成：Entra 管理センターや Azure ポータルから新しいディレクトリを作成します。テナント名と初期ドメイン（onmicrosoft.com）を決めます。
- 管理者と基本ユーザー/グループを作成：運用担当者、サービス用アカウント、グループ設計（管理・利用者）を作ります。
- セキュリティの最低限を先に適用：MFA、条件付きアクセス、パスワードポリシー、サインインログ確認など、最小限の守りを作ってからアプリを入れます。
- 必要なアプリ登録を作成：Graph API や独自アプリの登録、リダイレクトURI、証明書/シークレットの管理方針を整理します。
- Azure サブスクリプションを紐づけ：Azure を使うなら、支払い方法・請求先・コスト管理を設定し、アラート（予算）も作成します。
ドメイン（例：contoso.com）を再利用したい場合の注意
以前のテナントでカスタムドメインを使っていた場合、新テナントで同じドメインを追加できるかは、旧テナントの状態に依存します。旧テナント側でドメインが「解放」されていないと、新テナントへ追加できません。
- もし旧テナントへまだアクセスできるなら、旧テナントからドメインを削除してから新テナントに追加します。
- 旧テナントが削除済みでドメインが残留している疑いがある場合は、サポートに「ドメイン再利用（ドメイン解放）」の相談が必要になることがあります。
今後同じ事態を防ぐ：非アクティブ扱いを避ける運用のコツ
「放置していたら消えていた」は、検証用テナントでは起きがちです。逆に本番テナントで起きると影響が大きいため、運用として“放置できない仕組み”を作ることが重要です。
| やること | 推奨頻度 | 目的 |
|---|---|---|
| 管理者が定期的にサインインして通知を確認 | 月1回〜四半期に1回 | ブロック前の予告を見逃さない |
| 請求情報・支払い方法の棚卸し | 四半期に1回 | 期限切れや連絡先変更を早期に検知 |
| 通知メールの受信箱を監視（共有メールボックス等） | 常時 | 個人依存を減らし、見逃しを防ぐ |
| 検証テナントの一覧化と廃止手順の整備 | 半期に1回 | 不要テナントを放置しない |
| テナントの役割を明確化（本番/検証/個人） | 随時 | 「どれが本番かわからない」を防ぐ |
特に小規模環境では「個人の無料アカウントで作ったテナントが、そのまま業務の基盤になっていた」ということが起きます。将来的に運用を安定させるなら、運用主体（会社/チーム）を明確にし、管理者の冗長化と通知経路の整備をセットで行うのがおすすめです。
よくある質問
メールの「購入」ボタンを押してもサインインできません。どうすればいい？
まずはメール内リンクを使わず、Azure ポータルまたは Entra 管理センターへ直接アクセスしてください。メールのボタンは便利ですが、サインイン先のディレクトリがズレたり、フィッシングに悪用されたりするリスクもあります。公式ポータルで同じ案内（バナー/通知）が出ていないか確認するのが安全です。
200日・20日という期限は固定ですか？
期限は通知内容や契約状態によって異なる場合があります。画面やメールに具体的な期限が書かれているなら、それが最優先です。この記事の数値は「メールに書かれがちな目安」として捉え、実際の期限は必ず案内に従ってください。
テナントIDがわかりません。どこで確認できますか？
サインインできる場合は、Entra 管理センターの「概要（Overview）」で「テナントID」を確認できます。サインインできない場合でも、エラー画面にテナント名やIDの手がかりが出ることがあります。サポート問い合わせ用に、エラー画面の情報（テナント名、ドメイン名、Correlation ID、時刻）を控えておくと役立ちます。
検証用で何も作っていないなら放置してもいい？
不要なテナントなら大きな実害は出にくいですが、将来「どのテナントが本番かわからない」原因になります。検証用は用途を終えたら削除し、残すなら管理者の定期ログインや通知受信の仕組みだけでも整えると安心です。
まとめ
- AADSTS5000225 は「テナントが非アクティブでブロックされ、サインインが拒否されている」状態を示すことが多い。
- まずはメールの正当性確認。不安ならリンクを踏まず、Azure ポータル/Entra 管理センターへ直接アクセスして状況を確認する。
- 猶予が残っているなら、購入・課金情報の更新やサポート連絡で復旧できる可能性がある。
- 猶予を過ぎている場合は、新しい Entra ID テナントを作成して再構成するのが現実的。再発防止として運用（定期ログイン、請求情報、通知監視）も整える。
コメント