久しぶりに Azure ポータルを開いたら「This tenant has been blocked due to inactivity」と表示され、サインインが一切できない…。新しいテナントを作っても同じエラーになり、テナント ID も分からず完全に詰んだ――そんな状況から抜け出すための、具体的で実践的な対処方法と再発防止策をまとめます。
Azure テナントが「非アクティブのためブロック」と表示される典型パターン
まずは、今回のようなトラブルが発生する代表的なパターンを整理しておきます。
- 「一定期日までにサインインして購入しないとブロックされる」という内容の通知メールを受信していた。
- 期日前に一度はサインインしたつもりだが、それでも「This tenant has been blocked due to inactivity」と表示されるようになった。
- 同じメールアドレスで新規テナントを作成したところ、作成は成功するが、その後のサインイン時に同じエラーメッセージが出る。
- 「テナント ID を URL に指定してログインすれば良い」という情報は見つけたものの、そもそもテナント ID が分からない。
表にすると、次のような状況になっていることが多いです。
| 発生している事象 | 裏側で起きていそうなこと |
|---|---|
| 通知どおりサインインしたがブロックされた | 「サインインしたつもりのテナント」と「通知対象テナント」が別物だった可能性 |
| 新規テナントを作っても同じエラー | ホーム レルム検出（HRD）により、古いブロック済みテナントに誘導されている |
| テナント ID が分からずお手上げ | 初期ドメインや過去メール、エラー詳細を確認していない・情報が残っていない |
ここから見えてくる一番のポイントは、「Azure ポータルに入るときに、どのテナントにサインインしているのかを明示できていない」という点です。
最重要ポイント：テナントを URL で明示指定してサインインする
この問題を突破するうえで最も効果的なのは、対象テナントを URL で直接指定してサインインすることです。
テナント指定で Azure ポータルにサインインする
ブラウザで次の URL にアクセスし、<テナントID> を自分の組織のテナント ID に置き換えます。
https://portal.azure.com/<テナントID>
Microsoft Entra 管理センター（旧 Azure AD ポータル）を使う場合は、クエリパラメーターでテナント ID を指定します。
https://entra.microsoft.com/?tenant=<テナントID>
このように「テナント指定 URL」からアクセスすると、そのテナントに対して直接サインイン処理が行われるため、ホーム レルム検出による「誤ったテナントへの誘導」を避けやすくなります。
逆に、いつもの癖で
https://portal.azure.com
のような「汎用入口」にアクセスすると、以下のようなことが起こります。
- 古いブロック済みテナントが優先的に選ばれ、そこにサインインしようとしてエラーになる。
- 新規に作ったテナントではなく、職場テナントや個人用の別テナントに自動的に切り替えられる。
- 見かけ上「同じエラーが繰り返し出ている」ように見えるが、実際には別テナントにサインインしに行っている。
このため、一度でも「This tenant has been blocked due to inactivity」が出たら、テナント指定 URL を使ってログイン動作を切り分けるのがおすすめです。
テナント指定 URL を使うときのコツ
- プライベート ウィンドウ（InPrivate / シークレット モード）で開く
既存のクッキーやセッションにより、思わぬテナントへリダイレクトされるのを防ぎます。 - 一度すべての Microsoft アカウントからサインアウトする
ポータル右上のアイコンからサインアウトし、https://login.microsoftonline.comでもサインアウトしてから改めて指定 URL を開くと、切り分けがやりやすくなります。 - メールアドレスは同じでも「アカウントの所属テナント」は別
同じ UPN（メールアドレス形式）でも、テナントが違えば別アカウント扱いになります。URL でどのテナントかを指定することで、どの「自分」にサインインするのかが明確になります。
そもそも「Azure テナント」とは何かをおさらい
ここで一度、用語を整理しておきます。特に「アカウント」「テナント」「サブスクリプション」がごちゃごちゃになると、トラブルシューティングが難しくなります。
| 用語 | ざっくりした意味 | 今回の問題との関係 |
|---|---|---|
| アカウント（ユーザー） | サインインに使う ID（例：[email protected]） | 同じメールアドレスでも、所属テナントが複数存在することがある |
| テナント / ディレクトリ | Microsoft Entra ID（旧 Azure AD）の「組織」単位 | 「非アクティブのためブロック」されるのはこの単位 |
| サブスクリプション | Azure リソース利用の契約（従量課金やサポート プランなど） | 通知メールで「購入しないとブロックされる」と書かれる主な対象 |
今回のエラーは「ユーザー」でも「サブスクリプション」でもなく、テナント（ディレクトリ）単位でブロックされたことを表しています。
テナント ID が分からないときの調べ方
テナント指定 URL を使うには、<テナントID>（GUID）を把握する必要があります。ここでは、サインインできない状態でも試せる調査方法を優先して紹介します。
1. 初期ドメイン名やカスタム ドメイン名から調べる
もし、次のような情報が分かっている場合はチャンスです。
- 初期ドメイン：
<組織名>.onmicrosoft.com - カスタムドメイン：例）
example.co.jp、contoso.comなど
ブラウザで次の URL にアクセスします（<ドメイン> の部分を、初期ドメインまたはカスタム ドメインに置き換えます）。
https://login.microsoftonline.com/<ドメイン>/v2.0/.well-known/openid-configuration
JSON 形式の情報が表示され、その中の issuer という項目に注目します。
"issuer": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0"
この URL の中に含まれている xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx が、目的のテナント ID（GUID）です。この値をコピーして、先ほどのテナント指定 URL に差し込めば OK です。
2. 過去の招待メール・請求メールを漁る
次のようなメールに、テナントを特定できるヒントが含まれていることがあります。
- Azure への招待メール（B2B 招待）
- 評価版やサブスクリプション開始時の案内メール
- 請求書・支払い関連のメール
これらのメールの中に、
xxx.onmicrosoft.com形式の初期ドメイン- 「ディレクトリ ID」「テナント ID」といった表記
- Azure ポータルや Entra 管理センターへの URL（クエリの
tenant=パラメーター）
が記載されている場合があります。特に、URL の中の tenant=xxxxxxxx-.... や、URL パスに含まれている GUID（32文字＋ハイフン）は、ほぼテナント ID と見てよいです。
3. 組織の管理者・課金担当に聞く
自組織で Azure / Microsoft 365 を運用している場合は、
- Microsoft Entra ID / Azure AD の全体管理者（Global Administrator）
- 課金管理者 / 請求担当者
がテナント ID を把握していることが多いです。特に、複数テナントを使い分けている企業では、管理者がテナント情報を一覧で管理しているケースもあります。自分だけで悩むより、「該当テナントのテナント ID を教えてください」と率直に問い合わせるのが近道です。
4. サインイン エラー画面の「詳細を表示」を確認する
エラー画面に「詳細を表示（Show details）」や「詳細情報」リンクがある場合、クリックすると
- テナント名
- テナント ドメイン
- 要求 ID（Request ID）
- サインインしようとしている URL
などが表示されることがあります。ここにテナント ID が直接記載されていない場合でも、URL パラメーターの中に tenant= や GUID 形式の ID が含まれていないかチェックしてみましょう。
テナント ID 調査手段の比較
| 方法 | サインイン不要か | 必要な前提 | メリット / デメリット |
|---|---|---|---|
| openid-configuration から取得 | 不要 | ドメイン名（初期 or カスタム） | 正確なテナント ID が得られる / ドメインが分からないと使えない |
| 過去メールを確認 | 不要 | メールの保管 | 他の契約情報も併せて確認できる / メールが残っていない場合は不可 |
| 管理者に問い合わせ | 不要 | 組織に管理者がいる | 確実だが、回答まで時間がかかる場合がある |
| エラー詳細を確認 | 不要 | エラー画面が表示できる | 情報が出ていれば手っ取り早い / 何も出ないケースもある |
サインインできた後に必ずやっておきたい設定
テナント指定 URL のおかげで無事サインインできたとしても、何も設定を変えずに放置すると、同じトラブルが再発しがちです。ここでは、再発防止のために最低限行っておきたい設定を整理します。
1. 既定のディレクトリ（デフォルト テナント）を切り替える
Azure ポータル右上のプロフィール アイコンから、次のように操作します。
- 右上のユーザーアイコンをクリック
- 「ディレクトリの切り替え」を選択
- 日常的に使うテナントを選び、そのテナントを「既定のディレクトリ」として設定
こうしておくことで、
https://portal.azure.comのような汎用入口を開いたとき、誤ったテナントに誘導されにくくなる- 複数テナントを行き来する場合でも、基準となるテナントが明確になる
2. 「テナント指定 URL」を必ずブックマークする
今回のトラブルシューティングで使った、テナント指定 URL をブラウザにブックマークしておきましょう。
- Azure ポータル：
https://portal.azure.com/<テナントID> - Entra 管理センター：
https://entra.microsoft.com/?tenant=<テナントID>
ブラウザに複数アカウントのセッションが溜まっているほど、「どのテナントで開かれたのか」が分かりづらくなります。ブックマークから直接アクセスする習慣を付けておくと、トラブル発生率が大きく下がります。
3. サブスクリプションとライセンスの状態を確認する
通知メールに「購入しないと無効化される」「有効期限までにサインインが必要」といった文言があった場合、
- Azure サブスクリプション（従量課金 / 評価版 など）
- Microsoft 365 / Office 365 ライセンス
- 各種試用版（トライアル）の残期間
といった要素が絡んでいる可能性があります。サインイン後は必ず、
- 必要なサブスクリプションが有効化されているか
- 不要なテナント・サブスクリプションが残っていないか
を確認し、整理しておきましょう。
なぜ「同じメールアドレスで新規テナントを作っても」同じエラーになるのか
今回のケースで混乱しやすいポイントがここです。「新しいテナントを作ったのだから、古いブロック済みテナントとは関係ないはず」と考えがちですが、実はそう単純ではありません。
ホーム レルム検出（HRD）の罠
Microsoft のサインイン基盤は、ユーザー名（メールアドレス）を入力した時点で、その文字列から「どのテナントに属するか」を推測する仕組み（ホーム レルム検出）を持っています。具体的には、
- 過去にそのメールアドレスでサインインしたテナント
- B2B 招待で紐づいているテナント
- キャッシュされたテナント情報
などから、どのテナントにサインインさせるかを自動で判定します。このとき、
- 古くに作った評価用テナントがブロックされている
- その後、同じメールアドレスで新しいテナントを作成した
という状況だと、HRD が「先に作られた古いテナント」を優先してしまい、結果的に常にブロック済みテナントへサインインしようとしてしまう、という現象が起きえます。
これを避けるために有効なのが、ここまで解説してきたテナント指定 URLなのです。
複数テナント運用時の実践的な工夫
複数の Azure テナントを使い分けるエンジニア・管理者の場合、次のような工夫をしている人が多いです。
- テナントごとに異なるメールアドレス（エイリアス）を使う
- ブラウザのプロファイル（Edge プロファイルなど）をテナントごとに分ける
- プロファイルごとに「テナント指定 URL」をブックマークバーに登録する
- 「個人用」「検証用」「本番用」でテナントを明確に分離する
個人や小規模チームであっても、「本番で使うテナント」と「試しに作ってみたテナント」を混在させないよう意識するだけで、後々のトラブルをかなり防げます。
再発防止のためのチェックリスト
ここまでの内容を踏まえ、「同じ罠に二度ハマらない」ためのチェックポイントをまとめます。
| 項目 | チェック内容 |
|---|---|
| テナント情報の記録 | テナント名 / テナント ID / 初期ドメイン / 目的（本番・検証など）を一覧で管理しているか |
| 既定ディレクトリの設定 | 日常的に使うテナントを「既定のディレクトリ」に設定しているか |
| ブックマーク | Azure ポータル / Entra 管理センターの「テナント指定 URL」をブックマークしているか |
| メールアドレスの使い分け | 複数テナントに同じメールアドレスを使い回していないか |
| 定期サインイン | 長期間放置しないよう、定期的にサインインする運用になっているか |
| サブスクリプション管理 | 不要な試用テナント・評価用サブスクリプションを放置していないか |
どうしても復旧できない場合：Microsoft サポートに相談する
テナント指定 URL を試してもなお、
- サインイン画面すら開けない
- テナント ID をどうしても特定できない
- 組織として重要なテナントであり、自力での復旧が不安
といった状況であれば、Microsoft サポートに相談するのが安全です。
問い合わせの前に整理しておくと良い情報
- 問題の概要（いつから / どの URL で / どのようなエラー メッセージが表示されるか）
- 通知メールが残っていれば、その内容（件名・送信元・本文の要点）
- 分かっている範囲でのテナント情報（テナント名、初期ドメイン、カスタムドメインなど）
- エラー画面のスクリーンショット（Request ID や日時が含まれていると尚良い）
サポート側から見ても、テナントを特定できなければ対応が難しくなります。可能な限りの手がかりを整理したうえで問い合わせましょう。
よくある質問と補足情報
Q. 「非アクティブのためブロック」はユーザー個人が悪い？
必ずしも「サインインをサボったから悪い」という話ではありません。よくあるパターンとして、
- 検証目的で一時的に作ったテナントをそのまま放置していた
- 組織としてテナントを整理した結果、あるテナントは廃止方針だったが、通知だけ残ってしまった
- テナント管理者が退職して、引き継ぎが不十分だった
などの「運用上の問題」が背景にあることも多いです。今後のために、テナントの棚卸しと情報共有を見直す良い機会と捉えるとよいでしょう。
Q. 一度ブロックされたテナントは必ずしも復旧できない？
テナントの種類や状態によっては、完全には復旧できないケースもありえます。例えば、
- 長期間完全に放置され、削除プロセスが進んでいる
- 試用版テナントとして運用され、有効期限を大きく過ぎている
といった場合です。「何としても元のテナントを復活させる」ことにこだわるより、新しいテナントで構成をやり直すことも選択肢として考えておくと、精神的にも楽になります。
Q. 通知メールには「購入しないとブロック」とあったが、購入するだけで良かった？
通知内容によっては、「サブスクリプションの購入」だけでなく、
- 管理者による明示的なアクション（同意・設定変更など）
- 一定期間内のサインイン実績
が求められる場合もあります。また、実際に購入しても、その操作が別テナントに対して行われていたということも起こりえます。いずれにせよ、
- どのテナントで購入したか
- 通知メールの「このテナント」という表現が指しているのはどのテナントか
を意識して確認することが大切です。
まとめ：テナントを「見える化」して Azure ログインの迷子を防ごう
Azure テナントが「This tenant has been blocked due to inactivity」と表示されサインインできない問題は、
- テナントを URL で直接指定してサインインする
- テナント ID を地道に洗い出す
- サインインできたら、既定ディレクトリやブックマークを整える
といったステップを踏むことで、かなりの割合で解消できます。特に、複数テナントが同じメールアドレスで混在している環境では、
- 「どのテナントで何をしているのか」を常に意識すること
- テナント情報をきちんとドキュメント化・共有しておくこと
が、トラブルを未然に防ぐ最大のポイントです。
今まさにエラーで困っている場合は、まずは落ち着いて、
- テナント ID の手がかりを探す
- テナント指定 URL からサインインを試す
- 復旧できたら、二度と迷子にならないよう環境を整える
という順番で進めてみてください。どうしても難しいと感じたら、早めに Microsoft サポートや組織内の管理者に相談することも、立派な「正しい解決策」です。
コメント