長期間 Azure にアクセスしていなかった管理者が、突然「AADSTS5000225」エラーでサインインを拒否される――これは珍しくありません。本稿では、発生条件の整理、200日/220日の境界で何が変わるのか、復旧の可否判断、実務で使える依頼テンプレートや予防の自動化までを、現場目線で徹底的にまとめます。
状況の全体像と結論（まず知っておくべきこと）
「AADSTS5000225」は、Azure AD（現 Microsoft Entra ID）のテナントが長期未使用として扱われた場合に、ポータル サインインがブロックされて起きる代表的なエラーのひとつです。実務上の判断は、最終サインインからの経過日数でほぼ決まります。以下の早見表を最初に確認してください。
早見表：最終サインインからの経過日数で決まる対応
| 期間 | テナントの状態 | 取るべき対応 |
|---|---|---|
| 最終サインインから200日以内 | アクティブ | 通常どおりサインイン可能。対応不要。 |
| 200日経過後 〜 220日未満 | 「非アクティブ」扱い。AADSTS5000225 によりサインインがブロック | Microsoft サポートへ「テナント再アクティブ化」を依頼。 ブロックから20日以内（= 最終サインインから220日以内）であれば復旧可能。 |
| 最終サインインから220日以上 | テナントが完全削除済み | 復旧不可。 新しい Azure テナントを作成し、サブスクリプションやリソースを再構築。 |
この判断軸に沿って、復旧手順と再発防止まで一気通貫で解説します。
AADSTS5000225 の意味と発生しやすいパターン
このエラーは、ユーザー名やパスワードの誤り、MFA の未完了、リダイレクト URI の不一致などとは別系統です。主にテナントの状態が要因で起き、長期間の未使用により「非アクティブ」へ移行したテナントで発生します。とくに以下の状況で表面化しがちです。
- 検証用や一時的な PoC で作成したテナントを放置していた。
- グローバル管理者が一人だけで、担当者の異動・退職により誰もサインインしていない。
- Azure は使っていないが、Microsoft 365 のみ利用していた（またはその逆）ため、片方のポータルに長期間アクセスしていない。
- サブスクリプションを解約後、テナント自体を維持する運用に切り替えたが、保守的な定期サインインをしていなかった。
まずやるべき初動と可用性チェック
復旧可能かどうかは「今が 200〜220 日の間か」を特定することです。ただしポータル サインインが塞がれているため、以下のいずれかで確認します。
- 別の全体管理者（存在する場合）から Entra 管理センターへサインインし、対象の管理者アカウントの「最終サインイン日時」を確認する。
- 社内の運用記録（アクセス記録、ジョブ実行ログ、監査レポート、請求書の通知受信記録）から、最後に誰かがポータルもしくは API でアクセスした日を推定する。
- アカウントのメールボックス（Exchange Online）にサインインできる場合、セキュリティ通知やサインイン通知の受信日時を手がかりにする。
200〜220 日の復旧猶予ウィンドウに入っている可能性が少しでもあるなら、余計な切り分けを続けず、次の章の手順で直ちにサポートへ再アクティブ化を依頼するのが最短です。
復旧できる期間内（200〜220日未満）の実務手順
どこから依頼するか
- Azure ポータルの「ヘルプ + サポート」から サポート リクエスト を作成。
- Microsoft 365 管理センターが利用可能なら、同様にサポートへ「テナント再アクティブ化」を依頼。
依頼時に準備する情報（チェックリスト）
| 項目 | 内容 | 備考 |
|---|---|---|
| テナント ID（ディレクトリ ID） | GUID（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx） | 過去のスクリーンショットや IaC パラメータに残っている場合あり |
| 初期ドメイン名 | xxxxx.onmicrosoft.com | 社内 wiki や運用台帳を確認 |
| カスタム ドメイン | contoso.com 等 | DNS を管理している場合は確認容易 |
| 最終サインイン推定日 | YYYY/MM/DD | 200〜220 日内である根拠を簡潔に記載 |
| 契約/請求情報 | サブスクリプション ID、課金アカウント、過去の請求書番号など | 本人/組織確認に有効 |
| 連絡先 | 氏名、所属、電話番号、連絡用メール | SMS 認証が発生する可能性に備える |
依頼テンプレート（そのまま使えます）
件名：テナント再アクティブ化の依頼（AADSTS5000225）
お世話になっております。弊社 Azure テナントに長期間サインインしていなかったため、
「AADSTS5000225」エラーでポータルにアクセスできない状況です。
以下の通り、最終サインインから 220 日未満と判断しており、再アクティブ化をお願いしたくご連絡しました。
・テナント名（初期ドメイン）：
・テナント ID（ディレクトリ ID）：
・カスタム ドメイン：
・最終サインイン推定日：（根拠：<運用記録/ログ>）
・主なサブスクリプション/契約情報：<サブスクリプション ID / 契約番号>
・連絡先：<氏名 / 部署 / 電話 / 連絡用メール>
本人確認・組織確認のために追加情報が必要であればお知らせください。
何卒よろしくお願いいたします。 サポート対応後の確認ポイント
- 再アクティブ化完了の連絡を受けたら、ポータルにサインインし、Azure と Microsoft 365 の双方でアクセスできるか確認。
- 全体管理者の数、緊急アクセス（ブレークグラス）アカウント、MFA 設定、条件付きアクセス ポリシーを再点検。
- 監査ログの保存期間を見直し、以降の章の予防策をすぐに適用。
220日以上経過していた場合：復旧不可時の再構築ガイド
テナントが完全削除されている場合は、以下の手順で最短で業務を再開します。
新規テナントの作成
- Azure ポータルで「テナントの作成」を開始。
- 組織名、初期ドメイン名、国/地域を入力して作成。
- 必要な Azure サブスクリプションを紐付け。
ドメインの取り込み（再バインド）
- カスタム ドメイン（例：contoso.com）を新テナントへ追加し、DNS（TXT レコード）で所有確認。
- 旧テナント側に同ドメインが残留していないか要注意（完全削除後であれば追加可能）。
ID・アクセス制御の初期設計
- 全体管理者を最低 2 名以上、緊急アクセス アカウントを 1〜2 つ作成し、MFA を適切に構成。
- 条件付きアクセスのベースライン（国/地域・デバイス準拠・リスクベース）を用意。
リソースの再デプロイ
- Infrastructure as Code（Bicep/Terraform/ARM）を活用し、既存テンプレートがあれば流用して迅速に復旧。
- バックアップからのリストアや、アプリ側のシークレット・証明書の再発行を忘れずに。
業務影響を最小化する判断マトリクス
| 対象 | 影響 | 推奨アクション |
|---|---|---|
| Azure リソース | 旧テナントに紐付くものは原則利用不可 | 新サブスクリプションで再構築（IaC 推奨） |
| アプリ登録（App Registration） | クライアントID/シークレットの再発行が必要 | 新テナントでアプリを再登録、リダイレクトURI再設定 |
| ユーザー/グループ | すべて再作成 | CSV等で一括作成、ロール付与を自動化 |
| カスタム ドメイン | DNS 構成を移行 | TXT 検証 → MX/SRV/CNAME を順次切替 |
よくある誤解の整理（テナント／サブスクリプション／アカウント）
- テナント＝組織のディレクトリ（ID プラットフォーム）。
- サブスクリプション＝課金の入れ物。1 テナントに複数ぶら下がる。
- アカウント＝ユーザーの資格情報。テナント内でロールを持つ。
サインイン ブロックは多くの場合「ユーザーの問題」ではなく「テナントの状態」が原因です。ユーザーのパスワード変更や端末再起動では解決しません。
トラブルシューティング：別要因の切り分け
次のようなメッセージや状況なら、未使用によるブロック以外の要因が混在している可能性があります。
- 「パスワードが違います」→ 資格情報の誤り。
- 「追加の認証が必要です（MFA）」→ MFA デバイスの紛失や登録不備。
- 「リダイレクトURIが一致しない」→ アプリ設定の誤り。
ただし 200〜220 日の可能性があるなら、まずサポート依頼を先行させるのが鉄則です。切り分けに時間をかけるほど復旧期限が縮みます。
予防策（再発防止の標準運用）
未使用ブロックは定期的なサインインと見える化で確実に回避できます。以下を最低ラインとして導入してください。
- 半年に一度以上の定期サインイン（全体管理者・緊急アクセス）
- アクティビティ監視：最終サインイン日時のレポート化とリマインダー
- 管理者の冗長化：全体管理者を 2 名以上、緊急アクセス アカウントを用意
- 運用台帳：テナント ID、初期・カスタムドメイン、請求先、連絡先を最新化
PowerShell（Microsoft Graph）での簡易監視例
以下は「最終サインインが 150 日以上前」の全体管理者を抽出し、CSV に出力する例です。必要に応じてスケジュール実行し、メール通知に接続してください。
# Microsoft Graph PowerShell SDK が必要
# Install-Module Microsoft.Graph -Scope AllUsers
Connect-MgGraph -Scopes "Directory.Read.All","AuditLog.Read.All","RoleManagement.Read.Directory"
Select-MgProfile -Name "v1.0"
# 全体管理者（Global Administrator / Company Administrator）のメンバー取得
$gaRole = Get-MgDirectoryRole -Filter "displayName eq 'Company Administrator'"
if (-not $gaRole) {
Write-Error "全体管理者ロールが見つかりません。"
exit 1
}
$gaMembers = Get-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id -All
$thresholdDays = 150
$limitDate = (Get-Date).AddDays(-$thresholdDays)
$result = @()
foreach ($m in $gaMembers) {
# メンバーのユーザー情報とサインイン アクティビティを取得
$u = Get-MgUser -UserId $m.Id -Property "id,displayName,mail,userPrincipalName,signInActivity"
$last = $null
if ($u.AdditionalProperties.ContainsKey("signInActivity")) {
$last = [DateTime]$u.AdditionalProperties.signInActivity.lastSignInDateTime
}
$result += [pscustomobject]@{
DisplayName = $u.DisplayName
UPN = $u.UserPrincipalName
Mail = $u.Mail
LastSignIn = $last
DaysSinceSignIn = if ($last) { (New-TimeSpan -Start $last -End (Get-Date)).Days } else { $null }
OverThreshold = if ($last) { $last -lt $limitDate } else { $true } # サインイン履歴が無ければ要注意
}
}
# 150 日超のアカウントを出力
$alert = $result | Where-Object { $_.OverThreshold -eq $true }
$alert | Export-Csv -NoTypeInformation -Encoding UTF8 -Path ".\stale-admins.csv"
Write-Host "監視完了。stale-admins.csv を確認してください。" ポイント：
signInActivityの取得には適切な権限（例：Directory.Read.All 等）が必要です。- 緊急アクセス アカウントは MFA を適用しない代わりに、厳格な監査と金庫（パスワード保管）管理を徹底します。
- 150 日のしきい値は一例です。180 日や 90 日ごとのアラートなど、組織のリスク許容度に合わせて調整しましょう。
運用ドキュメントの雛形（そのまま社内共有できます）
「長期未使用テナント」早期検知の運用
| 項目 | 頻度 | 責任 | アウトプット |
|---|---|---|---|
| 全体管理者の最終サインイン監視 | 週次 | IT 管理チーム | ダッシュボード/CSV、150 日超のアラート |
| 緊急アクセス アカウント点検 | 月次 | セキュリティ チーム | 保管庫の開封テスト記録、MFA 例外レビュー |
| テナント情報台帳の更新 | 四半期 | サービスオーナー | テナント ID/ドメイン/請求先/担当者の最新化 |
| サインイン実施（健康診断） | 半年 | 全体管理者 | Azure/M365 ポータルへの実サインイン証跡 |
ケーススタディ：200〜220日の「復旧猶予」を使い切らない動き
実例ベースの時間軸を示します。あくまで参考ですが、現場での段取り感覚を掴めます。
| 経過 | やること | 注意点 |
|---|---|---|
| Day 0（エラー検知） | 220 日未満の可能性を確認し、サポート依頼を起票 | 切り分けより先に依頼。証跡は後追いで良い |
| Day 1〜2 | 本人/組織確認の追加情報に即応 | 請求書番号やドメイン所有の証明を準備 |
| Day 3 | 再アクティブ化後の全体点検 | 管理者/MFA/CA/監査を一気に是正 |
| Day 4〜7 | 予防の自動化（監視・通知・定期サインイン計画） | スクリプトのサービス化、運用台帳の整備 |
FAQ（現場でよく受ける質問）
Q. 旧テナントにぶら下がっていた Azure サブスクリプションは救えますか？
テナントが完全削除の場合は原則不可です。新テナントにて新規サブスクリプションを用意し、リソースは IaC などで再展開します。
Q. カスタムドメインは再利用できますか？
旧テナントから切り離されていれば新テナントに追加可能です。DNS 側の TXT 検証と各種レコード切り替えを計画的に行ってください。
Q. AADSTS5000225 と MFA エラーの見分け方は？
MFA 要求は追加認証のプロンプトが出るのに対し、5000225 は最初からサインイン自体がブロックされ、異なるメッセージとなります。
Q. ゲストユーザー（B2B）だけが使っていたテナントでもブロックされますか？
未使用であれば同様に対象になり得ます。ゲスト主体のテナントでも定期サインイン（もしくは監視）を行いましょう。
Q. 条件付きアクセスでブロックされている可能性は？
その場合は別のエラーやポリシー違反メッセージになることが多いです。200〜220 日のタイムラインに該当するなら、まずは再アクティブ化の依頼を優先してください。
チェックリスト（今すぐやること）
- 最終サインイン推定日を確定し、200〜220 日内かを判断。
- 該当すれば即座にサポートへ再アクティブ化を依頼（テンプレ利用）。
- 復旧後は全体管理者の冗長化と緊急アクセス アカウントの整備。
- 最終サインイン監視の自動化（週次/日次）とリマインダーを実装。
- 半年に一度の「健康診断サインイン」を運用規程として明文化。
まとめ
「AADSTS5000225」はユーザーの入力ミスではなく、テナントのライフサイクル管理に起因するエラーです。鍵は200日/220日という時間軸。200〜220日の猶予に居るならサポート依頼で復旧、220日を超えていれば速やかに新テナントを構築――この二択を明確にし、復旧後は定期サインインと可視化で再発を封じる。この記事の手順とテンプレート、監視スクリプトをそのまま取り入れれば、突然のサインイン不能に振り回されることはなくなります。ビジネス継続性は、小さな定期運用の積み重ねで確保できます。
付録：ユーザー教育用の短縮解説（社内共有向け）
「最後にサインインしてから 200 日を超えるとテナントは非アクティブ化、さらに 220 日を越えると完全削除。200〜220 日の間にサポートへ再アクティブ化を頼めば復旧できる。半年に一度、全体管理者が実サインインするだけでこの事故は防げる。」――この一文を社内周知に使ってください。
コメント