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 日経過後 | テナント完全削除 | 不可能 | データ復元不能 | 新規テナントで再構築(データは戻らない) |
いますぐやること(当日中のアクションプラン)
- 期限の確認:最後に正常サインインできた日、ブロックが出始めた日を思い出せる範囲で控え、「ブロック発動から 20 日以内」かどうかを評価します。少しでも不明なら「今日が猶予の起点」と見なして行動を開始してください。
- 情報の採取:エラー画面・認証失敗画面に表示される以下を必ずメモ/スクリーンショット化します。
- Tenant ID(
xxxxxxxx-xxxx-....) - Correlation ID
- Timestamp(UTC)
- エラーコード:
AADSTS5000225
- Tenant ID(
- ポータル外からサポートへ連絡:サインイン不要のチャネルを使います。
- Azure サポート オプションの電話窓口(国・地域の番号一覧)
- Microsoft 365 管理センターの「サポートへ問い合わせ」電話番号
- エンタープライズ契約の場合は担当営業・アカウントチーム
- 推奨チケット分類(口頭で伝える/オペレータ入力用): 分類: 技術 サービス: Azure Active Directory(Microsoft Entra ID) 問題種類: テナント管理 サブカテゴリ: テナントの復元 / ブロック解除
- 依頼時に必ず伝える要点:
- 前述の 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 は「ディレクトリ(テナント)」の凍結です。パスワードやブラウザー設定では直りません。
期限内のサポート依頼が唯一の復旧手段なので、気づいたら即連絡を入れてください。

コメント