久しぶりに Azure ポータルへアクセスしたところ、個人用の Microsoft アカウント（@outlook.com / @hotmail.com など）で突然「AADSTS5000225: This tenant has been blocked due to inactivity」と表示されてしまうケースが増えています。本記事では、このエラーの正体とテナントの復旧方法、さらに二度と同じトラブルに遭わないための具体的な運用・予防策まで、体系的に解説します。
Azure ポータルのサインインエラー「AADSTS5000225」とは
まずは、実際に表示されるエラーメッセージを整理しておきます。
Sign in failed.
Error code: AADSTS5000225
Error message: AADSTS5000225: This tenant has been blocked due to inactivity.
日本語にすると、概ね次のような意味になります。
- このテナントは非アクティブ状態のためブロックされています。
- サインインしようとしている「テナント」側に問題があり、アカウント自体が壊れているわけではないことが多いです。
ここで重要なのは、エラーの主体が「アカウント」ではなく「テナント」である点です。Outlook や OneDrive には普通にサインインできるのに、Azure ポータルだけ入れない、という現象はまさにこのパターンです。
そもそも「テナント」とは何か
Azure や Microsoft Entra ID（旧 Azure AD）では、次のようなイメージで理解すると分かりやすくなります。
| 用語 | イメージ | 具体例 |
|---|---|---|
| 個人用 Microsoft アカウント | あなた自身の「ユーザーID」 | [email protected] / [email protected] など |
| テナント（ディレクトリ） | 会社・組織ごとの「入館管理システム」 | example.onmicrosoft.com など |
| Azure サブスクリプション | そのテナントの中で使える「契約・プラン」 | 従量課金、無料試用版、Visual Studio サブスクリプションなど |
個人用アカウントで Azure の無料試用版や学習用サンドボックスを作成すると、裏側で自動的に 専用のテナント（example.onmicrosoft.com のようなもの） が作られます。そして、一定期間まったく使われなくなると、そのテナントが「非アクティブ」と判断され、サインインがブロックされる仕組みです。
テナント ライフサイクルのイメージ
Microsoft の公式ドキュメントや Q&A などから整理すると、AADSTS5000225 が発生するライフサイクルはおおよそ次のような流れになります。
| 状態 | 概要 | サインイン時の挙動 |
|---|---|---|
| アクティブ | 通常利用中。定期的にサインインやリソース利用がある状態。 | Azure ポータルや Azure CLI から問題なくログインできる。 |
| 非アクティブ（ログインブロック） | 長期間サインインや課金アクティビティがないため、自動的にログインがブロックされた状態。 | AADSTS5000225 が返される。管理者が Microsoft サポート経由で再有効化を依頼できる猶予期間。 |
| 削除 | 非アクティブ状態が一定期間続いたため、テナント自体が削除された状態。 | テナントは完全に削除され、復旧不可。新しくテナントを作成するしかない。 |
ドキュメントやコミュニティ回答では、おおむね 200 日以上サインインがないテナントに対してログインブロックがかかり、その後 20 日ほどで完全削除される、という説明が多く見られます。期間はあくまで目安であり、契約種別やキャンペーン、リージョン等によって変わる可能性がありますが、「数か月以上完全放置すると危ない」という感覚を持っておくと安全です。
よくある発生パターン
AADSTS5000225 が出る典型的なパターンは次のとおりです。
- 昔 Azure 無料試用版を有効化したが、その後すっかり忘れてしまい放置していた。
- Microsoft Learn のサンドボックス環境や検証用テナントを使い、そのまま長期間ログインしていない。
- 勤務先や学校のテナントに個人アカウントを接続していたが、退職・卒業後に放置され、テナント側が無効化された。
- 複数テナントを跨いで利用しているうちに、ブラウザーが古いテナントへ自動リダイレクトするようになり、結果としてブロックされたテナントに飛ばされる。
この「どのテナントにサインインしようとしているか」がユーザー視点では非常に分かりにくく、結果として「アカウントが壊れたのでは？」と誤解されることが多いのが、このエラーの厄介なところです。
AADSTS5000225 が出たときの対処フロー全体像
ここからは、実際に AADSTS5000225 が出てしまったときの「おすすめ対処フロー」を整理します。まずは全体像を表で確認してから、各ステップを詳しく見ていきましょう。
| 対応手順 | 内容 |
|---|---|
| ① テナント ID 直指定でサインインを試行 | ブラウザーで portal.azure.com/<テナントIDまたはテナント名> にアクセスし、ブロックが軽度の場合はそのままサインインできることがあります。 |
| ② Microsoft サポートに「テナント復元」を依頼 | Azure サポートページからサインイン不要のチケットを起票し、「Tenant restoration（テナント復元）」を依頼します。 |
| ③ アカウント管理ポータルで状態確認 | 個人用 Microsoft アカウントの管理ページにサインインし、アカウント自体がロックされていないか、セキュリティ警告が出ていないかを確認します。 |
| ④ 復旧後の予防策を実施 | 最低でも 90 日に一度は Azure ポータルにサインインする、管理者アカウントを分離するなど、テナントを「アクティブ」状態に保つための運用ルールを整えます。 |
実際には、①でどうにもならなければ ② が本命です。以下で、各ステップをより具体的に掘り下げます。
テナント ID を指定して Azure ポータルにサインインする
ブラウザーのキャッシュや古いテナントへのリダイレクトを避ける
まず、「本当にブロックされたテナントに飛ばされているのか？」を切り分けるために、次の準備をしてから作業することを強くおすすめします。
- 別のブラウザー（Edge / Chrome / Firefox など）を使ってみる。
- シークレットウィンドウ（InPrivate / シークレットモード）で開く。
- 念のため、一度すべての Microsoft アカウントからサインアウトしてから再試行する。
これだけで、古いテナントへの自動リダイレクトが解除され、新しく作成したテナントに正しくサインインできるようになるケースもあります。
テナント ID / テナント名を指定してサインインする
Azure ポータルでは、URL にテナント ID（GUID）やテナント名（<tenant>.onmicrosoft.com）を指定してサインイン先を明示することができます。
| 指定方法 | 書式 | 例 |
|---|---|---|
| テナント ID（GUID）で指定 | portal.azure.com/<テナントID> | portal.azure.com/11111111-2222-3333-4444-555555555555 |
| テナント名で指定 | portal.azure.com/<テナント名> | portal.azure.com/example.onmicrosoft.com |
ポイントは、「古くてブロックされているテナント」ではなく、「今回使いたいテナント」を URL で明示することです。新しく作成したばかりのテナントがある場合、上記の方法で直接そのテナントにサインインし、ポータルの右上のアカウントメニューから 「既定のディレクトリ」を新しいテナントに変更しておくと、次回以降 portal.azure.com にアクセスした際も新しいテナントが選ばれやすくなります。
なお、ブラウザーに古いセッションが残っていると、せっかく URL で指定してもまた古いテナントに戻されることがあります。その場合は、ブラウザーのキャッシュ・Cookie を削除したうえで再挑戦してみてください。
Microsoft サポートにテナント復元を依頼する
テナントが「非アクティブ」によってブロックされている場合、最終的な復旧手段は Microsoft サポートによるテナント再有効化になります。ここでは、個人用アカウントで Azure を利用しているケースを想定して、問い合わせのポイントを整理します。
問い合わせ前に確認しておくべき情報
サポートに連絡する前に、次の情報を控えておくと対応がかなりスムーズになります。
| 項目 | 内容 | 入手場所 |
|---|---|---|
| テナント ID | 対象テナントの GUID（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 形式） | エラーメッセージに表示される場合があるほか、過去の Azure ポータルのスクリーンショットや Azure CLI の設定、請求書メールなどから分かることもあります。 |
| テナント名 | xxxxx.onmicrosoft.com の形式の名前 | テナント作成時の「ようこそ」メールや、過去のポータル画面から確認できることがあります。 |
| サインインに使ったアカウント | [email protected] などの個人用 Microsoft アカウント | 実際にサインインしようとしているアドレスをそのまま記載します。 |
| エラーコード・メッセージ全文 | AADSTS5000225 を含むエラー全文（英語） | エラーページの「詳細」などからコピーして保存しておきます。 |
| Trace ID / Correlation ID / Timestamp | 内部ログを特定するための ID と時刻 | エラーページの下部に表示されることが多いです。コピーボタンがあればそのまま貼り付け用に保存します。 |
| ビジネスインパクト | テナントが使えないことでどのような影響があるか | 「検証環境のため緊急度は低い」「業務システムが利用できず高い影響がある」など、正直に記載します。 |
特に Trace ID / Correlation ID / Timestamp は、Microsoft 内部のログ検索に利用される重要な情報です。これを添付しておくだけで、調査スピードが大きく変わります。
サポートチケット起票時のポイント
Azure サポートページからサインイン不要で問い合わせを行う際は、次のような点を意識して内容を記載するとよいでしょう。
- サービス：Azure Active Directory / Microsoft Entra ID に相当するカテゴリ
- 問題の種類：Tenant management（テナント管理）
- サブタイプ：Tenant restoration（テナント復元）、もしくはそれに近い選択肢
- 状況説明：
- 個人用アカウント（例：[email protected]）で Azure ポータルにサインインしようとすると AADSTS5000225 が発生する。
- エラーメッセージ全文をそのまま貼り付ける。
- Trace ID / Correlation ID / Timestamp を箇条書きで記載する。
- テナント ID、テナント名が分かっていれば必ず併記する。
- いつ頃から使っておらず、どの程度の重要度の環境か（業務か検証か）を簡潔に書く。
また、同じ内容で複数のサポートチケットを立てないことも重要です。内部的にはケースが統合されたり重複調査が発生したりして、結果的に対応が遅くなる原因にもなります。ひとつのチケットに対して、追記事項があれば返信で情報を補足する、というスタイルが推奨されます。
テナントが復元できる「時間の猶予」
公式な説明やコミュニティ回答では、テナントが「非アクティブ」でログインブロックされてから、再有効化を依頼できる猶予期間はおおよそ 20 日程度とされています。この期間を過ぎると、テナントは「削除」状態に移り、復元できなくなります。
- ブロックから 20 日未満：管理者がサポートに依頼することで、バックエンドからテナントを再アクティブ化できる可能性がある。
- ブロックから 20 日超：テナントが削除済みと判断され、基本的に復元不可。新規テナントを作成し直す必要がある。
このため、AADSTS5000225 を確認したら、「様子見」ではなく早めにサポートケースを起票することが非常に重要です。
個人用 Microsoft アカウント側の状態を確認する
テナント側の問題とは別に、個人用 Microsoft アカウント自体がロックされている・セキュリティ保護状態になっているケースもあります。特に、長期間ログインしていなかったアカウントや、パスワード変更を繰り返した直後などは注意が必要です。
アカウント管理ページで確認すべきポイント
- 最近のサインイン履歴に不審なログインがないか。
- 「アカウントのセキュリティに問題があります」といった警告が表示されていないか。
- 二要素認証（電話番号 / 認証アプリ）が有効な場合、そのデバイスが今も利用可能か。
- メールアドレスの変更や別アドレスへのリンクが途中で止まっていないか。
もしアカウント側に問題がある場合、Azure 以外のサービス（Outlook、OneDrive、Teams など）でもサインインに失敗することが多いため、「Azure だけがおかしいのか」「Microsoft サービス全体で問題が起きているのか」を切り分けることが大切です。
復旧後に必ずやっておきたい再発防止策
無事に Microsoft サポートによってテナントが復元された、あるいは新しくテナントを作り直したタイミングは、運用ルールを見直す絶好のチャンスです。この章では、個人利用・小規模検証環境を想定した現実的な再発防止策を紹介します。
定期サインインで「生存確認」をする
もっともシンプルで効果の高い対策は、定期的に Azure ポータルへサインインすることです。
- 最低でも 90 日おきに 1 回は Azure ポータルにサインインする。
- Outlook や OneDrive を使うタイミングで、一緒に Azure ポータルも開いておく。
- スマホのカレンダーやタスク管理アプリに「Azure テナント健全性チェック」のリマインダーを登録しておく。
実際のブロック・削除までの期間はもっと長いとされていますが、90 日を目安にサインインしておけば、まずブロックされる心配はありません。
「テナント専用」の管理者アカウントを作成する
個人用 Microsoft アカウント 1 つだけで Azure テナントを管理していると、次のようなリスクが発生します。
- パスワードを忘れた／二要素認証デバイスを紛失した → その瞬間テナント全体にアクセスできなくなる。
- アカウントが不正アクセスでロックされた → Azure 側に一切入れなくなる。
可能であれば、テナント内に次のような「専用管理者アカウント」を作成しておくと安心です。
admin@<tenant>.onmicrosoft.com形式のクラウド専用アカウントを作る。- このアカウントに「全体管理者（Global Administrator）」相当のロールを付与する。
- 個人用 Microsoft アカウントとは別のパスワード・認証方法を設定しておく。
こうしておけば、たとえ個人用アカウントに問題が起きても、テナント内部から自己救済できる可能性が高まります。
テナント情報を「資産」として記録しておく
検証用テナントはつい「作りっぱなし」「名前も ID も覚えていない」という状態になりがちですが、テナントも立派な IT 資産です。次のような情報をメモアプリやパスワードマネージャーなどにまとめておきましょう。
| 項目 | 例 |
|---|---|
| テナント名 | example.onmicrosoft.com |
| テナント ID | 11111111-2222-3333-4444-555555555555 |
| 用途 | 個人学習用 / 検証用 / 本番環境 など |
| 管理者アカウント一覧 | [email protected]、[email protected] など |
| 作成日 / 最終利用日 | 例：作成 2024-01-10、最終利用 2024-03-01 |
これだけでも、「このテナントもう 1 年触ってないから削除してしまおう」「半年以上触っていないから、一度サインインしておくか」といった判断がしやすくなります。
不要なテナントは早めに「計画的に」削除する
もう絶対に使わないと分かっているテナントは、Microsoft による自動削除を待たず、自分で明示的に削除するのもひとつの選択肢です。
- 「検証用」「学習用」などで一時的に使っただけのテナント。
- 他のテナントに統合し、役割を終えたテナント。
ただし、削除前には次の点を必ず確認してください。
- 重要なリソース（VM・ストレージ・データベースなど）が残っていないか。
- 課金が発生しているサブスクリプションがぶら下がっていないか。
- 他サービス（Power Platform など）と連携していないか。
自分で削除すれば、「いつ・なぜ削除したか」を把握できるため、後から「あのテナントどこ行った？」とモヤモヤする事態も避けられます。
よくある質問（FAQ）
Q1. 「今日作ったばかりのテナント」なのに AADSTS5000225 が出ます
AADSTS5000225 は本来「長期間使っていないテナント」に対して出るエラーですが、次のようなパターンでは、新しいテナントを作成した直後でも同じエラーに見えることがあります。
- 過去に別のテナントを作っていて、それがすでに非アクティブ状態になっている。
- portal.azure.com にアクセスすると、ブラウザーのクッキーにより自動的に「古いテナント」にリダイレクトされてしまう。
この場合は、新しいテナントの ID / 名前を使って portal.azure.com/<テナントID> にアクセスし、ポータル右上のプロフィールメニューから 「既定のディレクトリ」を新テナントに変更することで解消するケースがあります。
Q2. ブロックされてから 20 日以上経っているようです。復旧できますか？
テナントが「非アクティブ → ブロック → 削除」というライフサイクルをたどり、削除済みになっている場合は原則として復旧できません。サポートに問い合わせても、再有効化ができないという回答になる可能性が高いです。
その場合は、次のような対応が現実的です。
- 新しいテナントを作成し直す。
- 必要な構成（Azure リソース・アプリ登録・ユーザーなど）を再作成する。
- 今後は今回紹介したような定期サインインや管理アカウントの分離などの運用を取り入れる。
Q3. テナントが削除されると、Outlook や OneDrive のデータも消えますか？
個人用 Microsoft アカウント（@outlook.com など）のメインとなるメールボックスや OneDrive は、通常は テナントとは別の仕組みで管理されています。テナント削除によって、これらの個人向けサービスのデータが直ちに消えるわけではありません。
一方で、Azure テナント内に作成していたリソース（VM、ストレージ、Azure SQL、アプリ登録など）は、テナントとともに失われる可能性が高いため、検証環境であっても重要な設定はバックアップしておくことが大切です。
Q4. Microsoft Learn のサンドボックスで AADSTS5000225 が出ました。試験に影響しますか？
Microsoft Learn のサンドボックス環境は、そもそも一時的に利用することを前提としたテナントです。サンドボックス側で AADSTS5000225 が発生しても、通常は認定試験の予約や認定履歴には直接影響しません。
ただし、演習が進められなくなるなどの影響はあるため、必要に応じて Learn サポートやコミュニティに状況を共有し、代替手段（別シナリオの学習・ローカル環境での学習など）を検討するとよいでしょう。
Q5. Azure CLI や PowerShell からも同じエラーが出ています
Azure CLI（az login）や PowerShell でも、バックエンドでは同じ認証基盤（Microsoft Entra ID）が使われています。そのため、テナントがブロックされている場合、次のようなメッセージが表示されることがあります。
Authentication failed.
AADSTS5000225: This tenant has been blocked due to inactivity.
この場合、CLI 側の問題ではなく、テナントの状態そのものが原因です。この記事で紹介した「テナント ID を指定してログインを試す」「Microsoft サポートにテナント復元を依頼する」といった手順で対処する必要があります。
まとめ：AADSTS5000225 をきっかけにテナント管理を見直そう
AADSTS5000225 は、「アカウントが壊れた」というよりは、長期間放置されたテナントに対する安全装置のようなエラーです。とはいえ、一度ブロックされてしまうと、ユーザー側からは何もできないように見えるため、不安になってしまうのも当然です。
本記事で紹介したように、
- テナント ID / テナント名を指定して Azure ポータルにサインインしてみる。
- Trace ID / Correlation ID などを添えて Microsoft サポートに「テナント復元」を依頼する。
- 復旧後は、定期サインインや管理者アカウントの分離など、再発防止の運用ルールを整える。
といった手順を踏めば、多くのケースで状況を正しく把握し、必要であればテナントの復旧や再構築に進むことができます。
もし今、AADSTS5000225 に直面しているなら、まずは落ち着いて、
- どのテナントにサインインしようとしているのかを確認する。
- テナントが本当にブロックされているのか、ブラウザーやアカウントの問題ではないかを切り分ける。
- 必要な情報を整理して、早めに Microsoft サポートへ相談する。
というステップから始めてみてください。これをきっかけに、自分が持っているテナントを棚卸しし、「必要なテナントは定期的に利用する」「不要なテナントは計画的に削除する」というシンプルなルールを取り入れることで、今後のトラブルも大きく減らすことができるはずです。
コメント