新しく作成・有効化したはずのMicrosoft Entra ID（旧Azure AD）テナントにサインインしようとして「AADSTS5000225」が出る場合、実際は“テナントが非アクティブ扱いでブロックされた”か、“別テナントに入ってしまっている”ことが原因になりがちです。原因の見極めから最短の回避策、復旧依頼の要点までまとめます。
AADSTS5000225とは何か（テナントが「非アクティブ」でログインが遮断される）
AADSTS5000225 は、Microsoft Entra ID（Azure AD）のサインイン時に表示されるエラーコードの一つで、対象テナントが非アクティブ扱いとなり、テナント自体へのアクセスがブロックされている状態で発生します。単なるパスワード誤りやMFA失敗ではなく、ディレクトリ（テナント）側の状態が原因なので、同じテナントに属するユーザーは基本的に全員ログインできません。
Microsoftは「利用されていないテナントがコストを生み続ける」ことを抑える目的で、一定条件に該当するテナントを“inaccessible due to inactivity（非アクティブのためアクセス不可）”として扱い、該当テナントへの認証リクエストを抑制します。エラーメッセージに「This tenant has been blocked due to inactivity」と表示されるのが典型です。
| 項目 | 内容（要点） |
|---|---|
| 発生条件の考え方 | 長期間利用がないなどの理由で、テナントが非アクティブ扱いになりログインがブロックされる |
| 影響範囲 | ユーザー単位ではなくテナント単位（同テナントに属するサインインが広く失敗する） |
| 猶予 | 管理者が再アクティブ化（復旧）を依頼できる猶予がある |
| 放置した場合 | 一定期間を過ぎるとテナントが削除され、復旧できなくなる |
公式ドキュメントでは、テナントが非アクティブ状態に入ってから20日以内であれば管理者が再アクティブ化を依頼でき、20日を超えるとテナントは削除され復旧不可と説明されています。まずは「いつからブロックされているか」を把握することが最優先です。
「作ったばかりなのに」起きる理由：新規テナントではなく“別テナント”に当たっていることが多い
質問でよくあるのが「新しく有効化したばかり（数日〜10日程度）なのにAADSTS5000225になった」というケースです。実務的には、次のどちらかに当てはまることが少なくありません。
- 過去に同じメールアドレス／同じ表示名で作った古いテナントが残っており、ブラウザのセッションや既定ディレクトリ設定でそこに入ってしまっている
- Microsoftアカウント（個人）と組織アカウント（Entra ID）が混在し、意図しないテナント・意図しないアカウントで認証が進んでいる
Azureポータルは直近で利用したディレクトリ（テナント）を“既定”として扱うことがあり、テナントが複数ある人ほど「思っていたテナントと違う場所に入る」事故が起きます。さらに、ポータルにはディレクトリ（テナント）を切り替える機能があり、これが混乱の原因にもなります（逆に言えば、正しく切り替えられれば解決に近づきます）。
最初にやるべき切り分けチェック（原因を“テナントのブロック”と“取り違え”に分ける）
次の表に沿って確認すると、遠回りせず原因にたどり着けます。特に「新規テナントのはずなのに…」という場合は、取り違えチェックが最重要です。
| チェック観点 | 確認方法（例） | 分かること |
|---|---|---|
| ブラウザの影響 | シークレット/プライベートウィンドウで再サインイン | キャッシュ・Cookie・既存セッションの影響を除外できる |
| アカウントの種類 | 同じメールで「個人Microsoftアカウント」と「職場/学校アカウント」が存在しないか確認 | 認証が意図しないアカウントに流れていないか判断できる |
| テナントの特定 | テナントID（GUID）または contoso.onmicrosoft.com を用意 | “どのテナントに入ろうとしているか”を固定できる |
| ポータル上のディレクトリ確認 | ログインできた場合は「Directories + subscriptions」で現在のディレクトリを確認 | いま見ているテナントが正しいか確定できる |
上記のうち、「テナントID/ドメインで特定する」ができると、次に紹介する“テナントID指定ログイン”が使えるようになり、解決率が一気に上がります。
解決の近道：テナントID（またはドメイン）をURLで指定してAzureポータルに入る
今回の事例で最終的に効いたのが、AzureポータルへアクセスするときにテナントID（またはテナントドメイン）をURLに含めて「このテナントに入る」と明示する方法です。通常の portal.azure.com だと、ブラウザの状態や既定のディレクトリに引っ張られ、意図しないテナントに入ってしまうことがあります。
手順（Azureポータル）
- いったんAzureポータルからサインアウトし、可能ならシークレット/プライベートウィンドウを開きます。
- 次の形式でURLを開きます（テナントIDはGUIDでも、
contoso.onmicrosoft.comのようなドメインでも指定できるケースがあります）。
https://portal.azure.com/<テナントIDまたはテナントドメイン>例：
https://portal.azure.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
https://portal.azure.com/contoso.onmicrosoft.com- 表示されたサインイン画面で、対象テナントに属するユーザー（UPN）でログインします。
- ログイン後、右上のアカウントメニューや「Directories + subscriptions」で現在のディレクトリが想定どおりか確認します。
この方法は、Microsoft Q&Aなどでも「特定テナントに入るためにポータルURLにテナント名を付ける」として紹介されています。テナント取り違えが原因の場合、ここで一発で解消することがあります。
うまくいく時／うまくいかない時の見分け方
| 結果 | 読み取り | 次のアクション |
|---|---|---|
| ログインできた | 取り違え（別テナントに当たっていた）可能性が高い | ブックマーク化し、起動時の既定ディレクトリも見直す |
| 同じAADSTS5000225が出る | そのテナント自体が非アクティブ扱いでブロックされている可能性が高い | 20日以内なら復旧依頼、過ぎていれば再作成を検討 |
テナントID（GUID）やドメイン名の調べ方
テナントIDが分からないと「テナントID指定ログイン」ができません。すでにどこかからサインインできる状態なら、最も確実なのはAzureポータルやMicrosoft Entra管理センターで確認する方法です。
Azureポータルで確認できる場合
Microsoftのドキュメントでは、AzureポータルでMicrosoft Entra IDを開き、正しいディレクトリに切り替えたうえでテナントIDを確認する手順が案内されています。
- ポータルにサインイン
- 必要ならディレクトリを切り替える（Directories + subscriptions）
- Microsoft Entra ID（旧 Azure Active Directory）を開き、概要（Overview）で「Tenant ID」を確認
ログインできない場合に現実的な入手ルート
- 別の管理者に確認：同テナントの管理者がいるなら、その人からTenant ID/ドメインを共有してもらう
- 招待メールや設定資料を確認：B2B招待・プロジェクト資料・検証メモに
onmicrosoft.comドメインが残っていることが多い - 課金・契約情報から確認：Azureサブスクリプションがある場合は、契約/請求の紐づきからテナントを特定できる場合がある
本当に“非アクティブによるブロック”なら：20日以内に復旧依頼を出す
テナント取り違えを潰してもAADSTS5000225が継続する場合、テナントが「inaccessible due to inactivity」と判断されている可能性が高いです。公式ドキュメントでは、管理者は非アクティブ状態に入ってから20日以内に再アクティブ化を依頼できるとされています。
復旧依頼の前に準備しておく情報
サポートに伝える情報が揃っているほど、無駄な往復が減ります。最低限、次の項目はメモしておきましょう。
| 項目 | 例 | 理由 |
|---|---|---|
| テナントID（GUID）またはテナントドメイン | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / contoso.onmicrosoft.com | 「どのテナントを復旧するか」を一意に特定するため |
| 影響を受けているユーザーのUPN | [email protected] | 権限・所属・影響範囲の確認に使われる |
| 発生日時・タイムゾーン | 2025/12/19 10:30 JST など | サインインログやサポート側の追跡に必要 |
| エラー画面の情報 | Request ID / Correlation ID / Timestamp | バックエンドでの調査の手がかりになる |
| 業務影響（ビジネスインパクト） | 検証が止まる、本番導入が遅延する等 | 優先度判断に直結する |
どこに連絡すればいいか（現実的な選択肢）
- グローバルサポートの電話窓口：公式ドキュメントでも、テナント管理者はMicrosoftへ連絡する手段として「global support phone numbers」が案内されています。
- Microsoft Entraのサポート導線：Microsoft Entraの「Find help and get support」では、コミュニティでの相談やサポートリクエストの作成手段がまとめられています。
- Azureポータルからサポートリクエスト：契約/サブスクリプションがある場合、Azureポータルからサポートリクエストを作成できます（権限が必要）。
電話が自動音声でWeb誘導になる場合でも、落ち着いて「テナントが非アクティブ扱いでブロック（AADSTS5000225）」であること、ブロックから20日以内である（またはその確認が必要）であること、そして上記のテナント特定情報を伝えるのがポイントです。
よく言及される「200日」や「課金サイクル」について（目安として理解する）
現場の相談やコミュニティでは、AADSTS5000225が起きる背景として「課金サイクル終了後に長期間（目安200日程度）利用がないテナントが整理対象になり、OMS（コマース/課金システム）側でログインブロックが入る」といった説明がされることがあります。これは公式ドキュメントの本文で明記されている数字ではありませんが、複数の事例回答で同様の説明が見られます。
重要なのは、正確な日数よりも「ブロックされたら20日で削除されうる」という運用ルールの方です。ここだけは公式ドキュメントでも明確なので、迷ったら“急いで復旧依頼”が正解になります。
20日を過ぎてしまった場合：復旧は難しいため、再作成と移行を前提に動く
公式ドキュメント上、非アクティブ状態が20日を超えて続くとテナントは削除され、復旧できないとされています。もし「いつからブロックされているか」が不明で、すでに時間が経っていそうなら、復旧依頼と並行して新規テナント作成・再構築の準備も進めるのが現実的です。
再作成時は、次の点でつまずきがちです。
- onmicrosoft.comの名前が取れない：過去のテナントが残っていると、同じプレフィックスが使えないことがあります
- カスタムドメインの再追加に条件がある：古いテナント側にドメインが残っていると、新テナントへ追加できません
- 検証手順書・アプリ登録・証明書などの“テナント依存資産”を洗い出しておかないと、復旧後も同じ混乱が再発します
再発防止の運用Tips（複数テナント管理者ほど効く）
AADSTS5000225そのものは“非アクティブテナントの整理”に関係するため、日常の運用で完全にゼロにはできません。ただし、「取り違え」や「迷子」を減らすだけでも、トラブル対応の時間は大幅に短縮できます。
よく使うテナントはブックマークを“テナント指定URL”で持つ
ポータルのトップ（portal.azure.com）をブックマークしていると、既定ディレクトリに引っ張られます。運用上は、テナントごとに次の形式でブックマークしておくのがおすすめです。
https://portal.azure.com/<テナントIDまたはテナントドメイン>Azureポータルの「Directories + subscriptions」を使いこなす
Azureポータルには、現在のディレクトリ（Azure tenant）を確認し、別ディレクトリへ切り替えるための「Directories + subscriptions」画面があります。そこでは、現在のディレクトリや、起動時に使う既定ディレクトリ（Startup directory）も設定できます。
- 頻繁に使うディレクトリは「お気に入り（スター）」を付ける
- 作業テナントを切り替えたら、最初に「Current directory」を目視確認する
- 学習・検証用のテナントは、起動時の既定ディレクトリにしない（誤ログイン防止）
“使わないテナント”を放置しない（最低限の棚卸し）
個人検証や研修で作ったテナントは、数年後に「どれが本命のテナントか分からない」状態になりがちです。棚卸しの観点では、次の2点だけでも効きます。
- テナント一覧（名前・Tenant ID・用途・管理者）をスプレッドシートで管理し、プロジェクトが終わったら「不要」判定にする
- 不要テナントは、カスタムドメインやアプリ登録を残したまま放置しない（次の移行を阻害する）
よくある質問
電話しても自動音声でWebに誘導されます。詰みですか？
詰みではありません。テナントが非アクティブ扱いでブロックされている場合、公式ドキュメントでも「管理者がMicrosoftに連絡して再アクティブ化を依頼できる」旨が示されています。電話が難しい場合は、Microsoft Entraのサポート導線や、Azureポータルからのサポートリクエスト作成が現実的な代替手段になります。
テスト用テナントなら復旧より作り直しが早い？
はい。検証・学習目的で、本番データやカスタムドメインの依存が薄いなら、新規テナントを作り直した方が早いケースが多いです。一方で、カスタムドメイン・アプリ登録・課金サブスクリプションが絡む場合は、復旧依頼の優先度が上がります。
まとめ（やることを順番に整理）
- AADSTS5000225は、テナントが非アクティブ扱いとなりサインインが遮断されるときに出るエラー
- まずは「本当にそのテナントに入っているか」を疑い、テナントID/ドメイン指定でAzureポータルに直接入るのが最短ルート
- それでも同じなら、テナント自体のブロックが濃厚。20日以内に復旧依頼できる可能性がある
- 20日を超えると削除・復旧不可なので、復旧依頼と並行して再作成の準備も進める
コメント