Azure AD/Entra ID「AADSTS5000225」でサインイン不可|テナント凍結の原因・20日猶予・復旧手順と再発防止

Azure AD/Microsoft Entra ID で AADSTS5000225: Sign‑in failed が出てサインインできない|テナント凍結の真因と復旧・再発防止の完全ガイド

結論:AADSTS5000225 はユーザーのパスワードやブラウザーの問題ではありません。ディレクトリ(テナント)自体が「非アクティブ+課金停止」状態と判断され、Commerce 系の自動保護によりサインインがブロックされたことを示します。ブロック発動後は猶予 20 日を過ぎるとテナントは完全削除され、復元不能になります。したがって、至急、Azure ポータル外の手段で Microsoft サポートへ連絡し、解除(または復元)を依頼するのが唯一の解決策です。


目次

状況概要(よくある症状)

  • Azure ポータルや業務アプリ(例:NextVoyage)にサインインしようとすると、AADSTS5000225 : Sign‑in failed が表示される。
  • Microsoft の各サイトでログインがループし、最終的にどこにも入れない。
  • サポート チケット作成にもサインインが必要で、手続きに進めない。
  • このままではテナント内の 2 年分の業務データ(例:運航計画、指示履歴、承認ログなど)が失われる恐れがある。

重要:これはユーザー個々の問題ではなく、テナント全体のブロックです。
パスワード再設定、クッキー削除、ブラウザー変更では解消しません。


エラーの意味(原因の核心)

  • AADSTS5000225 は、テナントが 課金サイクル終了後に 200 日以上アクティビティが無いと判定された場合、Commerce システムが自動で「ログイン不可」のブロックを適用した状態を示します。
  • ブロックが発動してから20 日が経過すると、テナントは完全削除され、復元できません。
フェーズ状態サインイン運用への影響取れるアクション
非アクティブ化判定まで課金停止+200 日以上アクティビティなし一部成功する場合あり潜在リスク増大アクティビティの発生・課金再開で回避可能
ブロック発動後(0〜20 日)テナント全体がログイン不可失敗(AADSTS5000225)すべてのクラウド業務が停止サポートへ解除・復元依頼(唯一の手段)
20 日経過後テナント完全削除不可能データ復元不能新規テナントで再構築(データは戻らない)

いますぐやること(当日中のアクションプラン)

  1. 期限の確認:最後に正常サインインできた日、ブロックが出始めた日を思い出せる範囲で控え、「ブロック発動から 20 日以内」かどうかを評価します。少しでも不明なら「今日が猶予の起点」と見なして行動を開始してください。
  2. 情報の採取:エラー画面・認証失敗画面に表示される以下を必ずメモ/スクリーンショット化します。
    • Tenant ID(xxxxxxxx-xxxx-....)
    • Correlation ID
    • Timestamp(UTC)
    • エラーコード:AADSTS5000225
  3. ポータル外からサポートへ連絡:サインイン不要のチャネルを使います。
    • Azure サポート オプションの電話窓口(国・地域の番号一覧)
    • Microsoft 365 管理センターの「サポートへ問い合わせ」電話番号
    • エンタープライズ契約の場合は担当営業・アカウントチーム
    「サインインできないのでチケットが切れない」旨を最初に伝えるとスムーズです。
  4. 推奨チケット分類(口頭で伝える/オペレータ入力用): 分類: 技術 サービス: Azure Active Directory(Microsoft Entra ID) 問題種類: テナント管理 サブカテゴリ: テナントの復元 / ブロック解除
  5. 依頼時に必ず伝える要点:
    • 前述の ID 群(Tenant ID / Correlation ID / Timestamp / エラーコード)
    • テナントが担う業務上の役割(例:船舶運航管理システム NextVoyage の基盤)
    • 復元できない場合の具体的損失(例:運航停止、契約不履行、顧客 SLA 逸脱、財務損失など)
    • ブロック発生日と、今日が猶予 20 日以内である旨

ワンポイント:電話の最初の 60 秒が勝負です。
「テナント全体が Commerce によりブロックされ AADSTS5000225 でログイン不能、猶予 20 日以内。業務停止のため至急解除/復元を希望」と短く要点を伝えましょう。


依頼トークスクリプト(日本語・英語)

日本語

「弊社の Azure AD(Microsoft Entra ID)テナントで AADSTS5000225 が発生し、全ユーザーがサインインできません。
Tenant ID は (読み上げ)、Correlation ID は (読み上げ)、UTC の Timestamp は (読み上げ) です。
これは Commerce によるテナント ブロックと思われ、ブロックから 20 日以内のため、至急の解除または復元をお願いします。
本テナントは NextVoyage による船舶運航に使用しており、業務停止が発生しています。」

English

“Our Azure AD (Microsoft Entra ID) tenant is blocked with AADSTS5000225 and no one can sign in.
Tenant ID: (spell out), Correlation ID: (spell out), Timestamp (UTC): (read).
This seems to be a Commerce-triggered tenant block. We are within the 20-day window. Please expedite unblock or restore.
The tenant runs our NextVoyage fleet operation system and the business is halted.”


「やってはいけない」対処と、正しい思考法

誤った対処なぜダメか正しい行動
ユーザー パスワードのリセット問題はテナントのブロックであり、個別アカウントではないサポートへブロック解除・復元を直請求
ブラウザーのキャッシュ/クッキー削除認証フロー以前でブロックされるため効果なしCorrelation ID・Timestamp の採取を優先
新規テナントを作成して逃げる既存データ・ID・設定が失われ、復旧コストが激増まずは既存テナントの解除・復元を全力で交渉

復旧依頼の品質を高めるコツ(通りやすい説明の型)

  • ビジネス影響の具体化:「◯◯船の出航が止まっている」「◯◯社との SLA 違反見込み」など、時間単位の損失を示す。
  • 猶予 20 日の明示:いま何日目かをはっきり伝える。わからない時は「本日が 20 日以内である可能性が高い」と補足。
  • 準備資料の即時送付:Tenant ID、Correlation ID、Timestamp をメールや口頭で正確に共有。
  • 連絡先の一本化:担当者を 1 名に集約し、エスカレーションの窓口をはっきりさせる。

詳細手順(チェックリスト付き)

手順内容完了
期限の確認20 日以内であることを確認。不明でも即日依頼を開始。□
必要情報の控えTenant ID / Correlation ID / Timestamp(UTC)/ AADSTS5000225□
ポータル外で連絡電話窓口・契約担当に直接連絡。「サインイン不可のためチケットが切れない」旨を冒頭で説明。□
分類の提示技術 > Azure Active Directory > テナント管理 > テナントの復元 / ブロック解除□
業務影響の説明NextVoyage などミッションクリティカルな用途、損失を定量化□

再発防止:90 日に 1 回以上の「生存信号」を自動化する

本事象は「完全に使っていないテナント」と誤推定されることで起きます。以下のいずれか、または複数を自動化し、少なくとも 90 日に 1 回はアクティビティを発生させましょう。

推奨アクティビティの例

  • 管理者アカウントで Azure ポータルへ定期サインイン(自動化が難しい場合は月次の運用点検をルーチン化)
  • Microsoft Graph API で軽量な読み取り(例:GET /organization や GET /users?$top=1)を実行
  • 監査ログの取得スクリプトを月1回回す(「読み取り」でもアクティビティになります)
  • 有効な支払い方法・Azure サブスクリプションをテナントに関連付け、商用利用の実態を明確化

PowerShell(Microsoft Graph)サンプル

# 事前に Microsoft.Graph モジュールを導入
# Install-Module Microsoft.Graph -Scope CurrentUser

# 必要最小限の読み取りスコープで接続

Connect-MgGraph -Scopes "Organization.Read.All","User.Read.All"

# 軽量な呼び出しでアクティビティを発生させる

Get-MgOrganization | Out-Null
Get-MgUser -Top 1 | Out-Null

# ログ出力(監査用)

$timestamp = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
"KeepAlive ping at $timestamp" | Out-File -FilePath "C:\Logs\TenantKeepAlive.log" -Append 

上記を Windows タスク スケジューラや Azure Automation(Runbook)で 30~60 日間隔に設定しておけば、「非アクティブ誤判定」リスクを大幅に低減できます。

補足:Azure AD Premium P1 以上がある場合、テナント非アクティブの兆候を把握するためのアラートや運用レポートを有効化し、運用チームのメール/Teams チャネルに通知しましょう。


類似エラーとの違い(切り分け早見表)

エラーコード主因の対象典型的な原因一次対処
AADSTS5000225テナント非アクティブ+課金停止 → Commerce による自動ブロックサポートでブロック解除/復元を依頼
AADSTS50020ユーザー(外部組織)ユーザーが該当テナントに存在しない招待やアカウント確認、テナント切替
AADSTS50126ユーザー認証資格情報の不一致(パスワード等)パスワード/資格情報の見直し
AADSTS50076条件付きアクセス/MFA追加認証が必要MFA 完了、ポリシー確認

よくある質問(FAQ)

Q. テナント ブロック中にできることはありますか?

A. サインインが原則できないため、利用者側でできる有効な技術処置はありません。やるべきは「情報の採取(Tenant ID など)」と「ポータル外からのサポート連絡」です。

Q. 猶予 20 日を過ぎたら絶対に復元できませんか?

A. 本事象では完全削除後の復元は不可と理解してください。データ保全を最優先し、20 日以内にサポートへ到達することが極めて重要です。

Q. 一時的に別のテナントで運用を再開しても良いですか?

A. 緊急避難としてはありえますが、ID・アプリ登録・権限モデル・監査の分断を招きます。可能な限り既存テナントの解除・復元を先に試みてください。やむを得ない場合は、後日の統合計画(ID 移行/ドメイン移管/アプリ再登録)を併せて策定しましょう。

Q. そもそもなぜ 200 日・20 日という閾値があるのですか?

A. 長期間まったく使われていないテナントや課金停止テナントを自動整理し、セキュリティと運用効率を保つための仕組みです。誤判定を避けるため、定期的な「生存信号(アクティビティ)」の送信が運用ベストプラクティスです。


インシデント後の恒久対策(テンプレート付き)

1. 運用プロセスに「アクティビティ点検日」を組み込む

  • 毎月第 1 営業日に「ポータル サインイン+Graph API の軽量呼び出し」を実施
  • 結果を運用ノートに記録(実施者・時刻・成功/失敗・所感)

2. 自動化ジョブの二重化

  • 本番系(Azure Automation)とオンプレ系(タスク スケジューラ)で冗長化
  • 双方の実行ログを Teams の運用チャネルへ通知

3. 支払い・サブスクリプション健全性のモニタリング

  • 有効な支払い方法が登録されているかを四半期ごとに監査
  • サブスクリプションの有効期限アラートを運用カレンダーに登録

4. アラート

  • Premium P1 以上:非アクティブ警告やサインインログの閾値監視を有効化
  • 「過去 60~90 日で管理者サインインなし」を検出する簡易スクリプトを運用

現場で役立つメモ(実務 Tips)

  • スクリーンショットは UTC を見える形で:エラー画面右下の時刻やブラウザーの開発者ツールで UTC を確実に記録。
  • Correlation ID は間違えやすい:英数字の O/0、l/1、B/8 を読み上げ確認。
  • 「最初の連絡」を最速で:猶予カウントは待ってくれません。たとえ 1% でも復元の可能性があるうちに動く。
  • 関係者の合意形成:情報システム・運用・事業部・経営のチャットに「状況・影響・次アクション」を 1 枚で共有。

まとめ

AADSTS5000225 は「ユーザー」ではなくテナントが凍結されたことを示すシグナルです。
(1)20 日以内の迅速なサポート依頼、(2)必要情報の即時提示、(3)90 日ごとのアクティビティ自動化を徹底することで、データ消失の臨界点を回避し、再発を防げます。
もし本稿を読んでいる今がその「20 日以内」かもしれません。まずは電話でサポートへ到達し、解除/復元の判断テーブルに自社テナントを載せるところから始めましょう。


参考:この記事の要点を 30 秒で復習

  • 症状:どの Microsoft サイトでもサインインがループし AADSTS5000225
  • 原因:課金停止+200 日無活動 → Commerce によるテナント ブロック
  • 猶予:ブロック後 20 日で完全削除(復元不可)
  • 解決策:ポータル外からサポートへ 解除/復元 依頼(唯一の道)
  • 再発防止:90 日ごとにポータル サインイン or Graph 読み取り、支払い方法・サブスク健全化、アラート設定

付録:問い合わせ用ひな型(メール/メモ)

件名: テナント ブロック解除/復元のお願い(AADSTS5000225)

お世話になっております。弊社テナントで AADSTS5000225 によりサインイン不能となっております。
以下、確認済みの情報です。

* Tenant ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
* Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
* Timestamp (UTC): 2025-10-01T03:12:45Z
* 事象開始: 2025-09-30 頃(ブロック発動から 20 日以内)
* 影響: 業務アプリ(NextVoyage)に全社でログイン不可、運航停止の恐れ

Commerce によるテナント ブロックと推測しており、猶予内のため至急の解除/復元をご支援ください。
必要な追加情報があれば即時提出いたします。 

付録:運用点検の「見える化」テンプレート

実施日(UTC)実施者ポータル サインインGraph 呼び出し支払い/サブスク確認所感/課題
  成功 / 失敗成功 / 失敗OK / 要対応 

構造化データ(FAQ リッチリザルト用)


最重要メッセージ

AADSTS5000225 は「ディレクトリ(テナント)」の凍結です。パスワードやブラウザー設定では直りません。
期限内のサポート依頼が唯一の復旧手段
なので、気づいたら即連絡を入れてください。


この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次