Azureポータル（portal.azure.com）に個人用Microsoftアカウントでサインインすると、エラーコード「AADSTS5000225」が表示されて先に進めないことがあります。多くはアカウント自体の不具合ではなく、過去に紐づいた「古い組織テナント」へ誘導され続けることが原因です。
AADSTS5000225とは（Azureポータルで起きる理由）
AADSTS5000225 は、Microsoftのサインイン基盤（Microsoft Entra ID：旧Azure Active Directory）側で、サインイン先として指定されたテナント（組織ディレクトリ）が無効化・削除状態、または利用できない状態にあるときに出やすいエラーです。
重要なのは、「個人用Microsoftアカウント（MSA）が壊れている」とは限らない点です。GmailやOutlook.comなどの個人メールで作ったMicrosoftアカウントは正常に使えているのに、Azureポータルだけが失敗する場合、問題はアカウントが到達しようとしている“先”（テナント）にあるケースが非常に多いです。
結論：「ログインできない＝資格情報が間違い」ではなく、“入ろうとしている組織（テナント）が死んでいる/使えない”ために弾かれている可能性が高い、という整理になります。
よくある発生パターン：個人アカウントが古いテナントに引きずられる
今回の症状（プライベートブラウズで再登録し、SMS・メール・クレジットカードなどの本人確認が通っても、最後に同じエラーへ戻される）は、次の流れで説明できます。
- 個人用Microsoftアカウント（例：Gmail、Outlook.com）を使って、過去に大学・会社などの組織テナントへ“ゲスト”として招待された
- その組織テナントが、契約終了・統廃合・削除などで無効化/削除状態になった
- ブラウザのセッションや既定のディレクトリ選択の影響で、Azureポータルがサインイン時に毎回その古いテナントへ誘導する
- 結果として、Azureポータルへの入り口でAADSTS5000225が発生し続ける
この状態だと、いくら本人確認が通っても、最後に「無効なテナントへサインイン」しようとして同じエラーに戻されます。つまり本人確認ループではなく、テナント誘導ループです。
まず確認したいポイント（切り分けチェック）
対処に入る前に、状況を“見える化”すると最短で解決に近づきます。特に、エラー画面に表示される情報はあとで管理者へ依頼する際にも役立ちます。
| 確認すること | 見る場所 | 分かること |
|---|---|---|
| エラーコードが AADSTS5000225 か | エラー画面 | 「テナント側の問題」の線が濃い |
| テナント名（例：xxxx.onmicrosoft.com）が出ているか | エラー画面、またはサインイン遷移中の表示 | 引きずられている“古い組織”の特定に使える |
| Correlation ID / Timestamp が表示されるか | エラー画面（詳細情報） | 管理者がサインインログで追跡するための手掛かり |
| 個人用アカウントで Microsoftアカウント自体にサインインできるか | https://account.microsoft.com/ | アカウント自体の凍結・停止などではないことの確認 |
| 同じPCで職場/学校アカウントも併用していないか | ブラウザのプロファイル、保存済みアカウント | “別アカウントのセッション”に引っ張られる事故を防ぐ |
特にテナント名が分かると、次の打ち手（脱退できるか、管理者に依頼できるか、放置して運用で回避するか）が一気に決めやすくなります。
症状から分かる「原因の当たり」を先に把握する
同じ「ログインできない」でも原因は複数あります。以下の表で、自分の状況に近いものを確認してください。
| 症状 | 可能性が高い原因 | 最優先で試す対処 |
|---|---|---|
| AADSTS5000225 が出て、テナント名も表示される | そのテナントが無効化/削除状態、または利用不可 | 古い組織の脱退確認、テナント切替、管理者への依頼 |
| プライベートウィンドウでも同じテナントへ飛ばされる | アカウント側に“組織との紐づき”が残り、解除できない状態 | myaccountで脱退確認 → だめなら運用回避へ |
| 「職場または学校」を選ぶと別画面になるが、個人で入りたい | サインイン種別の選択ミス、または保存済みセッションの混在 | 完全サインアウト、ブラウザプロファイル分離 |
| Azureポータルには入れるが、古いテナントが残って操作できない | ゲストとして残存しているが権限がない | 新しいテナントを既定運用にして“見ない”工夫 |
対処手順：ユーザー側でできること（再現率の高い順）
プライベート（シークレット）ウィンドウで必ずやり直す
まずは切り分けの基本です。通常ウィンドウには、Microsoftのサインイン情報（セッション、トークン、Cookie）が複数残りやすく、意図せず古いテナントへ誘導される原因になります。
- Edgeなら「InPrivate」、Chromeなら「シークレット」を開く
- そのウィンドウで
https://portal.azure.comを開く - サインイン時にアカウント種別を聞かれたら、必ず個人用アカウントを選ぶ
ここで改善するなら、原因はほぼブラウザセッションの汚れです。改善しない場合は、次の“テナント紐づき”の線を濃く見ます。
完全サインアウトで「テナント誘導の癖」を一度切る
「サインアウトしたつもり」でも、Microsoft系はサインイン状態が複数サービスに跨るため、完全に切れていないことがあります。次の順番で“いったん全部ログアウト”を作ると、挙動が変わることがあります。
- 開いているMicrosoft関連タブ（Outlook、OneDrive、Microsoft Learn、Azureなど）をすべて閉じる
- プライベートウィンドウで以下にアクセスしてログアウト状態を作る
https://login.microsoftonline.com/logout.srfhttps://login.live.com/logout.srf
- 同じプライベートウィンドウで
https://portal.azure.comを開き直す
加えて、拡張機能（広告ブロッカーやスクリプト制御）がログイン遷移を壊すこともあるため、心当たりがあれば一時的に無効化して試すのも有効です。
「古い組織（テナント）」から脱退できるか確認する
個人用Microsoftアカウントが過去に組織へ招待されている場合、myaccount 側の組織一覧に痕跡が残っていることがあります。ここから脱退できると、最も“きれい”に解決します。
https://myaccount.microsoft.com/organizationsを開く- 問題の個人用Microsoftアカウントでサインインする
- 大学・会社など心当たりのある組織が表示されていないか確認する
- 表示されていれば「組織を脱退（Leave organization）」相当の操作を試す
脱退できれば、Azureポータル側の誘導先が整理され、AADSTS5000225のループが止まることが期待できます。
脱退できない/エラーになる場合は、次のどれかに該当している可能性が高いです。
- 組織側の設定で、ゲストが自己脱退できない（制限されている）
- テナントが削除・無効化され、ユーザー操作の入口が壊れている
- そもそも“その組織”が職場/学校アカウント前提で、個人アカウントでは完結できない
この場合、ユーザー側で完全に消し切るのは難しくなり、運用で回避するか、管理者へ依頼する判断が現実的です。
Azureポータルで「ディレクトリ + サブスクリプション」を切り替える
Azureポータルに入れたタイミングが一瞬でもあるなら、そこで自分が使えるテナントに固定するのが効果的です。古いテナントが残っていても、日常運用で見ないようにできます。
- Azureポータル右上のアイコン（アカウント）をクリックする
- 「ディレクトリ + サブスクリプション」を開く
- 一覧から、学習用に作った新しいテナントを選択する
- サブスクリプションも正しいもの（学習用/Free Trial等）にチェックする
ここで重要なのは、古いテナントを消すことではなく、日常的に“正しいテナント”で開く状態を作ることです。権限がない古いテナントは、見えていても触れないだけで、学習用途なら実害が小さい場合が多いです。
正しいテナントに固定するコツ（ブックマークとプロファイル分離）
毎回ポータルの入口から入ると、サインインの“最後に使ったテナント”へ戻されることがあります。次の工夫で再発率を下げられます。
- ブラウザのプロファイルを分ける：「Azure用」プロファイルを新規作成し、他の職場/学校アカウントを混ぜない
- プライベートウィンドウをデフォルト運用にする：どうしても混ざる環境なら、Azure操作は常にInPrivate/シークレット
- テナントが含まれるURLをブックマークする：ポータル内で正しいテナントに切り替えたあと、同じ画面をブックマークしてそこから入る
AzureポータルのURLは状況により変わりますが、テナント文脈がURLに含まれることがあります。テナント切替後にブックマークすることで、次回以降も正しいディレクトリで開ける確率が上がります。
それでも無限ループする場合に試す“現場向け”の回避策
「何をしても AADSTS5000225 に戻される」というときは、ポータルの問題というよりサインインの入り口が“古いテナント固定”になっている可能性が高いです。次の回避策は、手間は増えますが成功率が上がります。
| 回避策 | 狙い | 具体例 |
|---|---|---|
| 別ブラウザで試す | Cookie/セッションの完全分離 | Edgeで失敗→Chromeで試す（または逆） |
| OSの別ユーザープロファイルで試す | ブラウザ/資格情報の痕跡をゼロから | Windowsに新規ローカルユーザーを作り、その環境で実施 |
| 拡張機能をすべて無効化 | 認証リダイレクトを壊している要因を排除 | 広告ブロック、プライバシー強化、スクリプト制御をOFF |
| ネットワークを変える | 企業プロキシやフィルタの影響を除外 | 社内Wi-Fi→テザリング/自宅回線で試す |
特に会社PCや学校PCは、SSOやプロキシ設定で“組織テナント優先”になっている場合があります。学習用に個人アカウントでAzureを触るなら、環境分離はかなり効きます。
対処フロー（詰まったときの判断を表で整理）
「次に何をすべきか」を迷いやすいポイントなので、判断を一本道にします。
| やること | 期待する結果 | うまくいかなければ |
|---|---|---|
| プライベートウィンドウでポータルにサインイン | ポータルに入れる／テナント選択まで進む | 完全サインアウトを挟む |
完全サインアウト（logout.srf）→再ログイン | 誘導先が変わる、古いテナント固定が外れる | myaccount の組織脱退確認へ |
myaccountで古い組織を脱退 | 古いテナントとの紐づきが薄れ、エラーが消える | 脱退不可なら管理者依頼 or 運用回避へ |
| ポータルで「ディレクトリ + サブスクリプション」を新テナントに固定 | 学習用リソースが新テナントで扱える | ブックマーク/プロファイル分離で再発防止 |
脱退できない・権限がない場合の現実的な選択肢
ここが一番つらいところですが、結論として自分が管理者ではない古いテナントを、ユーザー操作だけで完全削除・復旧することはできません。できる選択肢は大きく2つです。
選択肢：元の組織（大学/会社）の管理者に依頼する
連絡が可能なら最短です。依頼内容は難しくありません。管理者側で以下のいずれかを実施してもらうと改善する可能性があります。
- 該当テナントが無効化状態なら、復旧可能な範囲で復旧してゲストを削除する
- ゲストユーザー（あなたの個人アカウント）をディレクトリから削除する
- ゲストが自己脱退できるよう設定を変更する（短時間でもよい）
依頼メール（テンプレ）は次のようにすると通りやすいです。
依頼テンプレ（例）
件名：Azure/Entra テナントからのゲスト削除のお願い（個人アカウント） お世話になっております。 過去に貴組織のMicrosoft Entra ID（旧Azure AD）テナントへ、私の個人用Microsoftアカウント（メール：XXXX）をゲストとして招待いただいた履歴があるようで、 現在 Azureポータルにサインインすると AADSTS5000225 で失敗します。 可能であれば、該当ゲストユーザー（メール：XXXX）をテナントから削除、またはゲストが自己脱退できる状態にしていただけないでしょうか。 エラー発生時刻：YYYY/MM/DD HH:MM（JST） Correlation ID：XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX（表示がある場合） 表示されるテナント名：xxxx.onmicrosoft.com（表示がある場合） お手数をおかけしますが、よろしくお願いいたします。
選択肢：新しいテナント（使える方）に寄せて運用で回避する
既に「新しいテナントではポータルに入れて学習用リソースは触れるが、古いテナントが残ったまま」という状態なら、この運用が最も現実的です。
- Azureポータルに入れたら、まず「ディレクトリ + サブスクリプション」で新テナントを選ぶ
- 以後はその状態でブックマークしたURLから入る
- ブラウザプロファイルをAzure専用にし、ログイン混在を防ぐ
- 古いテナントは「見えるけど触れないもの」と割り切り、学習/検証を進める
“古いテナントが一覧に残っている”こと自体は、必ずしもセキュリティ事故ではありません。多くの場合、権限がないため操作はできず、日々の学習に支障が出るのは「切替が面倒」「誤って古い方を選ぶ」点です。ここさえ潰せば、実務的には回ります。
どうしても不安なら「Azure専用の個人アカウント」を作るのも手
学習用途で、かつ将来の混乱を避けたいなら、Azure用に個人Microsoftアカウントを新規作成して切り分けるのはかなり有効です。
- 仕事/学校の招待が来る可能性がある普段のアカウントと分離できる
- ブラウザのオートログインや既定ディレクトリの癖がリセットされる
- Azureの学習環境が“自分専用”になる
注意点として、別アカウントにするとサブスクリプションやリソースは引き継がれません。今の学習環境を残したいなら、先に「どのテナント・どのサブスクリプションで何を作ったか」を整理してから移行するのがおすすめです。
個人用Microsoftアカウントと組織アカウントの違い（混乱ポイントを解消）
今回のようなトラブルは、「アカウントが2種類ある」ことを意識できていないと再発します。
| 種類 | 主な例 | 管理者 | 今回のトラブルとの関係 |
|---|---|---|---|
| 個人用Microsoftアカウント（MSA） | Outlook.com、Gmail等で作るMicrosoftアカウント | 基本は本人 | ゲストとして組織テナントに招待されると“紐づき”が生まれる |
| 職場/学校アカウント（Entra ID） | 会社ドメインのメール、学校の配布アカウント | 組織のIT管理者 | テナントが無効化されると、関連するサインインが不安定になりやすい |
AzureポータルはEntra IDの仕組みでサインインが進むため、個人アカウントであっても「ゲストとして組織にいる」状態だと、組織テナント側の事情を受けやすくなります。これが AADSTS5000225 の“納得感”につながります。
学習用途ならこう運用するとラク（古いテナントが残っていても困らない形）
「古いテナントは消せない。でも学習は進めたい」という場合、次の運用がストレスを減らします。
最初に固定する3点セット
- ポータルに入ったら、最初に「ディレクトリ + サブスクリプション」で新テナント＋正しいサブスクリプションを選ぶ
- その状態のままAzureのホーム（またはリソースグループ一覧）を開き、URLをブックマークする
- 次回からは、そのブックマークから入る（入口の
portal.azure.com直打ちを減らす）
事故を防ぐチェック（毎回30秒）
リソース作成前に、次だけ確認すると“古いテナントで操作してしまった”事故を防げます。
- 画面右上のアカウントメニューで、ディレクトリ名が新テナントになっている
- 「サブスクリプション」が学習用（Free Trialなど）になっている
- リソース作成ウィザードで、サブスクリプション選択が正しい
よくある質問
本人確認（SMSやクレカ）が通るのに、なぜ最後にエラーへ戻るの？
本人確認は「あなたが本人か」を見ていますが、AADSTS5000225は「入ろうとしているテナントが利用可能か」を見ています。本人確認が成功しても、最後の着地先が無効なテナントだと、結局エラーになります。
古いテナントを自分で削除できないのはなぜ？
テナントは組織の資産であり、削除や復旧はテナント管理者の権限が必要です。ゲストとして参加していた、あるいは権限が付与されていない状態では、ユーザー側で“存在自体”を消すことはできません。
古いテナントが残っていると課金やセキュリティ的に危ない？
多くの場合、古いテナントに対してあなたが権限を持っていないなら、勝手に課金されたりリソースが作られたりはしません。危険なのは「操作できると思って誤ったテナントで作業する」「別のアカウントと混在して誤操作する」ことなので、プロファイル分離とテナント固定で事故を防ぐのが現実的です。
サポートに問い合わせるべきラインは？
次のどれかに当てはまるなら、組織管理者またはAzureサポート（契約形態により）へエスカレーションした方が早いです。
myaccount.microsoft.com/organizationsで脱退できない- プライベートウィンドウや別ブラウザでも必ず同じテナントへ誘導される
- 学習ではなく業務でAzureポータルが必須で、放置運用が許されない
まとめ（この問題の“落としどころ”）
- AADSTS5000225は、個人用Microsoftアカウントの不具合というより、紐づいたテナント（組織ディレクトリ）が無効化・削除状態で起きることが多い
- まずはプライベートウィンドウ、完全サインアウトでセッション混在を切る
myaccount.microsoft.com/organizationsから古い組織を脱退できれば最もきれい- 脱退できず権限もないなら、管理者へ依頼するか、新テナントに固定して運用で回避するのが現実的
- 再発防止には、ブラウザプロファイル分離と、正しいテナント状態でのブックマークが効く
コメント