ある日突然、Microsoft Entra ID（旧 Azure AD）のサインインが AADSTS5000225: This tenant has been blocked due to inactivity で止まり、しかも「20日前後でテナントが完全削除」と表示される――。ユーザーは毎日ログインしているのに「非アクティブ扱い」になるこの現象は、実は課金・ライセンスの有無がトリガーです。本稿では、原因の本質、復旧の実務的プレイブック、再発防止の運用設計までを一気通貫で解説します。
問題の全体像：AADSTS5000225 の正体
AADSTS5000225 は「テナントが非アクティブのためブロックされた」ことを示すエラーです。重要なのは、この「非アクティブ」が ユーザーのログイン有無ではなく、課金・ライセンスの状態で判定される点です。したがって、毎日ユーザーがログインしていても、課金システム（OMS Commerce）からは非アクティブと見なされる場合があります。
典型的なシナリオは次のとおりです。
- 長期にわたり 有効なサブスクリプションやライセンス SKU が一切存在しない（例：無償試用終了、すべての SKU を解約）。
- その状態が継続すると、課金システムがテナントを「非アクティブ」と判定し、認証がブロックされる。
- ブロック後、おおむね 20日（最大30日）でテナントは自動的に物理削除され、復旧不能になる。
ポイント： サインイン活動ではなく「課金・商用関係の有無（0状態が続く）」がブロック判定のカギ。ログイン状況は救済条件になりません。
「非アクティブ」の実体：200日以上ライセンス／サブスク 0 継続
ブロックの主因は、200日以上にわたり テナントに紐づくライセンスまたはサブスクリプションが一切存在しないことです。ここでいう「一切存在しない」は、次のいずれにも当てはまらない状態を指します。
- Microsoft 365（E1/E3/E5 など）の有償 SKU が 1 つ以上有効
- Entra ID（P1/P2 など）の有償 SKU が 1 つ以上有効
- その他、課金システムがアクティブと認識するサブスクリプションが有効
この「0状態」が 200日以上続くと、課金側のルールで「非アクティブ」→ 認証ブロック→ 自動削除の順で進行します。
削除までのタイムライン（目安）
| フェーズ | 経過日数の目安 | システム状態 |
|---|---|---|
| ライセンス／サブスク 0 期間 | 〜200日 | 表面上は利用できることが多いが、内部では非アクティブ候補としてカウントが進む |
| ブロック発動 | ≒200日経過時点 | サインインで AADSTS5000225。管理ポータルにも入れない場合あり |
| 猶予期間 | 約20日（最大30日） | Microsoft サポート経由の解除依頼で復旧できる可能性あり |
| 自動削除 | ブロック後 20〜30日 | テナントが物理削除。復旧不能 |
初動プレイブック：すぐに取るべき行動
時間との勝負です。以下を上から順に実施してください。
- 事象の確定：実際に AADSTS5000225 が出ているか、複数アカウント（全体管理者、ユーザー）で再現確認。
- テナント情報の収集：
- テナント ID（GUID）
- 初期ドメイン（
<tenant>.onmicrosoft.com） - 影響を受ける代表ユーザー／管理者の UPN
- ビジネス影響（システムが止まる、認証できない SaaS がある等）
- 発生日と最終正常日時
- サポート経路の確保：Azure ポータルの ヘルプ + サポート から「サポート リクエストの作成」。テナントに入れない場合は、別テナント（個人の Microsoft アカウントでも可）でサインインしてチケットを作成し、影響を受けるテナント ID を明記します。
- 分類のコツ：技術カテゴリよりも 「課金／サブスクリプション」 を選ぶと、有人対応に到達しやすく、課金システム起因のブロックに話が通しやすい。
- エスカレーション要求：ブロック解除はプロダクト グループ（PG）の操作が必要です。PG へのエスカレーションを明確に依頼し、猶予期間内であることを伝えます。
実務上の要点： チケット冒頭に「AADSTS5000225」「非アクティブ誤判定の疑い」「ブロック解除希望」「テナント削除期限が迫っている」――の 4点を太字で記載すると、一次対応からの伝達が速くなります。
復旧条件と必要情報
ブロックから削除までの猶予内（概ね 20〜30日）で、次の情報を添えてサポートに依頼します。適切にエスカレーションされれば、PG 側でブロック解除が可能です。
- テナント ID または初期ドメイン（
.onmicrosoft.com） - 影響ユーザー／管理者の UPN
- ビジネス影響（停止しているサービス名、規模、期限）
- 「ライセンス／サブスクが 0 の期間が長期化していた可能性」や「支払い方法の変更／失敗の有無」など、状況説明
サポート チケットの作り方（補足）
- Azure ポータル経路：ヘルプ + サポート → サポート リクエストの作成 → 概要に AADSTS5000225 と記載、影響レベルは業務停止に応じて選択。
- 入れない場合：別テナントでサインインし、影響テナント ID を明記。必ず「課金／サブスクリプション」系の分類にも触れる。
- 電話連絡：自動音声でポータルに誘導される場合でも、課金・支払いカテゴリを選ぶと有人につながりやすい。チケット番号の即時発行を依頼。
復旧後に必ずやる確認（チェックリスト）
| 確認項目 | 内容 | 完了基準 |
|---|---|---|
| 管理者サインイン | 全体管理者で Entra 管理センターに入れるか | ポータル表示・基本設定の閲覧が可能 |
| ユーザー認証 | 代表ユーザーで主要アプリにサインイン | エラーなしでトークン取得・利用可能 |
| サインインログ | AADSTS5000225 の発生が収束しているか | 直近 24〜48 時間で 0 または顕著に減少 |
| ライセンス在庫 | 最低 1 SKU 以上の有効化を確認 | 有効 SKU > 0、支払い方法が正常 |
| 課金プロファイル | 請求失敗・期限切れの有無 | 未払い・期限切れがない状態 |
再発防止：設計・運用・自動化の三段構え
基本施策（設計）
| 施策 | 内容 | 効果 |
|---|---|---|
| 最低 1 ライセンス保持 | Microsoft 365 E1/E3 や Entra ID P1 など、有償 SKU を 1 つは維持 | 課金システム上の「アクティブ」維持 |
| 請求プロファイル定期点検 | 毎月「請求書と支払い > 製品とサービス」で有効サブスク／請求失敗を確認 | 非アクティブ誤判定の未然防止 |
| テナント健全性アラート | Entra サインインログで AADSTS5000225 を検知し通知 | ブロック発動の即時検知 |
| 検証環境の方針 | 検証テナントは期限付きで「使い捨て」。実運用と混在させない | 不要テナントの自動削除を前提にリスク最小化 |
運用ベストプラクティス
- オーナーシップの明確化： テナント所有者（Billing Admin）と技術責任者（Global Admin）を分離し二重化。
- 支払い手段の二系統化： メインのクレジットカードに加え、予備の支払い手段を登録。
- 解約手順のガバナンス： すべての SKU の解約は CAB（変更管理）必須。承認なしに「全ゼロ」にならない運用を定義。
- 棚卸しと証跡： 四半期ごとに SKU 在庫・消費数・請求書を棚卸しし、監査ログと一緒に保存。
自動化（PowerShell / Graph）
少なくとも 1つの SKU が存在することを定期的に検査し、0 ならアラート／自動調達の検討を行います。
# Microsoft Graph PowerShell（例）
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes Organization.Read.All,Directory.Read.All
# サブスク（SKU）の存在確認
Get-MgSubscribedSku | Select SkuId,SkuPartNumber,ConsumedUnits,PrepaidUnits
# 0状態判定のサンプル
$skus = Get-MgSubscribedSku
if ($skus.Count -eq 0) {
Write-Output "警告: 有効なサブスクリプションが見つかりません。"
# ここで通知（メール/Teams/ServiceNow など）を実装
} else {
Write-Output "OK: SKU が存在します。"
} 組織規模によっては、在庫閾値（例：消費数が上限の 90% を超過）での警告も有効です。
監視（KQL 例：Entra サインインログ）
// AADSTS5000225 を検出するKQL（サインインログ）
SigninLogs
| where ResultType == 5000225 or ResultDescription has "AADSTS5000225"
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by AppDisplayName, ResourceTenantId
| order by LastSeen desc
このクエリをアラートルール化し、発生時は SRE / 情シス当番へ通知します。
「ユーザーは毎日ログインしているのに」― よくある誤解と FAQ
- Q. なぜログインしているのに非アクティブ扱い？
A. 判定は「課金・ライセンスの有無」です。ログイン活動は評価対象外です。 - Q. 無償プランでも助かる？
A. 「課金システムがアクティブと認識する SKU / サブスク」が 1つでもあればリスクが大幅に減ります。解釈は契約体系に依存するため、最低 1つの有償 SKU を保持するのが確実です。 - Q. ブロック解除は自分でできる？
A. できません。PG による解除が必要で、Microsoft サポート経由のエスカレーションが前提です。 - Q. 猶予は何日？
A. 実務上の目安は 20日程度、最大で 30日と案内されるケースがあります。期限を過ぎると物理削除で復旧不能になります。 - Q. 復旧したらやることは？
A. 管理者とユーザーのサインイン確認、SKU の存在・支払い状態の確認、アラート整備、再発防止の運用見直しを即時に行います。
実際の対応結果（ケーススタディ）
- 必要情報（テナント ID、影響ユーザー、ビジネス影響）を添えてチケットを提出。
- 課金カテゴリで一次対応に到達し、PG へエスカレーション。
- PG による 認証ブロック解除が完了。
- 管理者の再ログインが確認され、サインインログの AADSTS5000225 も収束。
- 以後は 最低 1 ライセンス保持と請求プロファイルの月次点検、アラートの常時監視に移行。
運用テンプレート：緊急連絡・ヒアリング票（社内用）
| 項目 | 質問 | 記入例 |
|---|---|---|
| 事象 | AADSTS5000225 の画面文言／発生時刻は？ | 本日 09:12、テナント全体で再現 |
| 影響 | 止まっているサービスは？ | 社内ポータル、Teams、SharePoint |
| ビジネス | 期限・イベント・損失見込みは？ | 午後の客先デモ実施不可 |
| 契約 | 直近の支払い変更・解約の有無は？ | 先週 E1 を全解約、支払い方法変更 |
| リカバリー | 優先復旧対象（アプリ）は？ | メール、SAML/SSO 提供の業務アプリ |
よくあるつまずき：サポート起票のコツ
- 別テナントで起票：影響テナントに入れなくても、別テナントや個人アカウントで起票して問題ありません。対象テナント ID を明記。
- 切り分けの言語化：「ユーザーは毎日ログインしていたが、課金 0 状態が続いていた可能性が高い」と明記。
- 期限の可視化：ブロック後 20〜30日の削除期限をチケットの表紙に記載し、優先度を上げる。
アーキテクチャ観点：ID とコマースは別系統
Entra ID（ID 基盤）と OMS Commerce（課金基盤）は独立したシステムです。
ID 側の利用（ログインやトークン発行）が活発でも、コマース側が「商用関係なし」と判断すればブロックが走る設計になっています。ここを理解しておくことが、運用議論の出発点になります。
チェックリスト：これで再発しない
| 領域 | 対策 | 定着方法 |
|---|---|---|
| 契約 | 最低 1 SKU 維持、支払い手段二系統 | 四半期レビューと CAB 承認 |
| 監視 | AADSTS5000225 検知アラート、SKU 在庫監視 | NOC/SRE の当番運用に組み込み |
| ガバナンス | 解約・支払い変更は変更管理必須 | 標準手順書（SOP）化 |
| 人 | Billing Admin と Global Admin の二重化 | 権限の棚卸しを四半期ごとに実施 |
まとめ（要点）
- AADSTS5000225 は「ログイン活動」ではなく「課金・ライセンス 0」が引き金。
- ブロック後は 約20日（最大30日）で自動削除。急いでサポートにエスカレーション。
- 復旧には PG 解除が必要。テナント ID・影響範囲・ビジネス影響を整えて依頼。
- 最低 1 SKU を維持し、請求プロファイルを定期点検すれば、この種の自動ブロックはほぼ回避可能。
付録：運用スクリプト断片集
SKU 在庫のしきい値監視（例）
# 例：SKU 消費率が 90% 超で警告
$skus = Get-MgSubscribedSku
foreach ($sku in $skus) {
$limit = $sku.PrepaidUnits.Enabled
$used = $sku.ConsumedUnits
if ($limit -gt 0) {
$rate = [math]::Round(($used / $limit) * 100, 1)
if ($rate -ge 90) {
Write-Output "警告: $($sku.SkuPartNumber) が $rate% です。追加購入をご検討ください。"
}
}
}
サインイン失敗の急増検知（KQL）
// 過去 60 分の 5000225 比率
let Window = 60m;
let Base = 24h;
let recent = SigninLogs
| where TimeGenerated >= ago(Window)
| summarize r = countif(ResultType == 5000225) * 1.0 / count() ;
let baseline = SigninLogs
| where TimeGenerated between (ago(Base) .. ago(Window))
| summarize b = countif(ResultType == 5000225) * 1.0 / count();
union (datatable(metric:string, val:real) [ "recent", toreal(recent.r) ]),
(datatable(metric:string, val:real) [ "baseline", toreal(baseline.b) ])
ケースの結論
今回の事象は、200日以上のライセンス／サブスク 0 状態が引き金となり、課金システムが非アクティブ判定→ 認証ブロック（AADSTS5000225）→ 自動削除予告、という流れで顕在化しました。猶予期間内に Microsoft サポートへ必要情報を添えてエスカレーションし、PG によるブロック解除で復旧しています。今後は 最低 1 ライセンスの恒常維持、請求プロファイルの月次点検、サインイン失敗の監視・自動通報により、同種インシデントの再発を回避できます。
クイックリファレンス
| テーマ | 要点 | 現場メモ |
|---|---|---|
| 原因 | 200日以上、ライセンス／サブスクが 0 | ログイン有無は関係なし |
| 猶予 | ブロック後 20〜30日で自動削除 | チケットは即日起票 |
| 復旧 | PG によるブロック解除 | テナント ID と影響を用意 |
| 防止 | 最低 1 SKU 維持、請求点検 | 解約は CAB 承認制 |
参考運用：社内通達のひな形
【重要】Entra ID テナント運用ルール改訂
- 最低 1SKU の恒常維持（E1/E3/P1 など）
- 請求プロファイルは毎月点検。支払い手段を二系統化
- 解約・支払い変更は変更管理（CAB）必須
- AADSTS5000225 検知アラートを常時監視に追加
- 棚卸し（SKU/請求書/監査ログ）は四半期ごとに保存
最後に
「ユーザーが使っているのに止まるのはおかしい」――そう感じるのは自然ですが、ID とコマースは別世界で動いています。技術運用（ログイン）と契約運用（ライセンス・支払い）の両輪を回してこそ、ID 基盤は止まりません。本稿のプレイブックとテンプレートをあなたの組織の SOP に落とし込み、AADSTS5000225 を二度と起こさない運用に仕上げてください。
回答・解決策（要点の再掲）
ブロックの主因
- 200日以上ライセンス／サブスクが一切存在しない状態が続くと、課金システムが非アクティブ判定 → AADSTS5000225。
- ブロック発動から 約20日後（最大30日）に自動削除。
復旧条件
- 猶予内なら Microsoft サポート経由で PG に解除依頼が可能。
- 必要情報：テナント ID or 初期ドメイン、影響ユーザー、ビジネス影響とリスク。
サポート チケットの開き方（補足）
- Azure ポータル → ヘルプ + サポート → サポート リクエストの作成。
- 入れない場合は 別テナントで起票して「影響テナント ID」を明記。
- 電話は「課金／サブスクリプション」を選び有人へ。
再発防止策
| 施策 | 内容 | 効果 |
|---|---|---|
| 最低 1 ライセンス保持 | M365 E1/E3、Entra ID P1 等の有償 SKU を 1 本以上維持 | 課金上「アクティブ」扱いとなりブロック対象外 |
| Azure 定期請求プロファイル確認 | 「請求書と支払い > 製品とサービス」で有効サブスクと請求失敗を月次点検 | 非アクティブ誤判定の抑止 |
| テナント健全性アラート | サインインエラー AADSTS5000225 をアラート化 | ブロック即時検知 |
| テスト用は使い捨て | 検証テナントは期限付きで運用し、必要に応じて新規作成 | 不要テナントの自動削除を前提とした安全運用 |
今回の対応結果
- 必要情報を提供し、PG による 認証ブロック解除が完了。
- 管理者は再ログインを確認済み。
- 今後は 継続的なアクティブ状態の維持（最低 1 ライセンス）と代替環境検討へ。
結論
ブロック判定はユーザーのログイン有無ではなく、課金／ライセンスの有無です。発生時は 20〜30日の猶予内に Microsoft サポートへ速やかにエスカレーションし、解除後は 最低 1 ライセンスの維持と監視・ガバナンスを仕組み化しましょう。
コメント