デモ用の Microsoft アカウントで、昨日までは普通に Power BI や Azure ポータルに入れていたのに、突然サインインできなくなる――CDX テナントを使った検証やデモでは、実はよくあるトラブルです。この記事では「CDX テナントの有効期限切れ」と「条件付きアクセス（CA）によるセキュリティ情報登録のブロック」という、実務で特に多い2つの原因と復旧・再発防止のポイントを体系的に整理します。
デモ用 Microsoft アカウントで Power BI / Azure にサインインできないときの全体像
CDX などのデモ用テナントを使っていると、次のような症状で Power BI や Azure ポータルにサインインできなくなることがあります。
- Power BI サービス（
https://app.powerbi.com）でサインインすると「組織アカウントでサインインできません」「アクセス権がありません」などのメッセージが出る - Azure ポータル（
https://portal.azure.com）でサインインしようとしても、ポータルが開かずループしたり、ブロックされたと表示される - サインインログを確認すると「条件付きアクセスによりブロック」「追加のセキュリティ情報の登録が必要」などと記録されている
このような場合、多くは次のどちらか、もしくは両方が絡んでいます。
| 主な原因 | 概要 | 典型的な症状 |
|---|---|---|
| CDX テナントの有効期限切れ | デモ／評価用テナントに設定されている有効期限を過ぎており、テナント自体が失効している状態 | Azure ポータルや Power BI を含め、ほぼすべてのサービスにサインインできない |
| 条件付きアクセス（CA）による セキュリティ情報登録のブロック | 「セキュリティ情報の登録」を特定 IP などに強く制限しており、初回 MFA 登録が完了できない | サインインの途中で MFA 登録画面から進めない、登録画面にすら到達しない |
実際の現場でも、失効した CDX テナントをクリーンアップして新規テナントを作成し、同時に条件付きアクセスの設計を見直すことで、Azure ポータルと Power BI のログイン問題が解消された事例が複数報告されています。
CDX デモテナントの有効期限切れが原因の場合
CDX テナントとは何か
CDX テナントは、Microsoft のデモ／検証向けに提供されるテナントです。営業デモ、PoC、検証環境などで非常に便利ですが、ほとんどの場合、あらかじめ有効期限が設定されています。有効期限を過ぎると、次のような状態になります。
- テナントが「失効」状態となり、管理ポータルにアクセスできない
- Azure ポータルや Power BI、Teams などのサービスにもサインインできなくなる
- ユーザーやアプリ登録情報はテナントに残っていても、事実上復旧できない
つまり、一度失効した CDX / 評価テナントは、元に戻すのではなく、基本的には「諦めて新しいテナントを作る」ことが前提になります。
CDX テナントの有効期限に関する確認ポイント
| 確認箇所 | 具体的なチェック内容 | 補足 |
|---|---|---|
| CDX ポータルや発行元情報 | 発行時のメール、CDX 管理ポータルなどに有効期限が記載されていないか確認する | パートナー向けの CDX では「○日間有効」と明記されていることが多い |
| サインインのエラーメッセージ | すべてのユーザーで一斉にサインイン不能になっているかを確認する | 個別ユーザーのみなら CA やライセンスの問題の可能性が高い |
| 管理者アカウントの状況 | グローバル管理者アカウントでも Azure ポータルに入れないか確認する | 管理者ですら入れない場合、テナント自体の失効が濃厚 |
期限切れテナントから新テナントへの移行の考え方
CDX テナントが期限切れの場合、現実的な復旧プランは次のようになります。
- 新しいデモ／検証用テナントを作成（CDX 再発行や別の評価テナント）
- 新テナントでグローバル管理者アカウントを準備
- 必要なユーザー、グループ、ロールを再作成
- 必要な Microsoft 365 / Power BI / Azure ライセンスを再割り当て
- Azure 上のリソース（仮想マシン、ストレージ、App Service など）を新環境に再構築
- アプリ登録（サービス プリンシパル、エンタープライズアプリ）を再設定
- Power BI ワークスペースやデータセット、ゲートウェイ接続を新テナントで再構成
- 可能ならデモ用データやレポートをエクスポート／インポートして再利用
Power BI 側で必要になる再構成作業
Power BI については、テナントが変わると「ワークスペース」と「ユーザーID」がすべて別物になります。そのため、次のような観点で作業を洗い出しておくとスムーズです。
| 対象 | 新テナントでの対応 | 注意点 |
|---|---|---|
| ワークスペース | 旧テナントと同じ名前・構成でワークスペースを作成 | アクセス権（メンバー／閲覧者など）の再設定を忘れない |
| レポート・ダッシュボード | 可能なら PBIX をローカルに保存しておき、新テナントのワークスペースに再公開 | 埋め込みパラメータや URL がテナント固有の場合は作り直し |
| データセット | データソースへの接続情報を再設定し、スケジュール更新を構成 | オンプレミス データゲートウェイとの紐づけを再設定する必要がある |
| サービス アカウント / SPN | Azure AD（Microsoft Entra ID）にサービス プリンシパルを再登録し、Power BI API へのアクセス権を付与 | クライアントID／シークレットが変わるため、外部アプリの設定変更が必須 |
CDX テナントはそもそも「作って壊す」ことを前提とした環境です。デモ環境であっても、設定や構成をあらかじめドキュメント化しておくと、新テナントへの再構築が格段に楽になります。
条件付きアクセスで「セキュリティ情報の登録」がブロックされている場合
条件付きアクセスとセキュリティ情報登録の関係
Microsoft Entra ID（旧 Azure AD）の条件付きアクセス（CA）では、ユーザーアクションとして「セキュリティ情報の登録」を制御できます。ここを厳しく絞り込みすぎると、次のような事態が起こります。
- MFA を必須にする CA ポリシーを適用
- しかし「セキュリティ情報（MFA の認証方法）の登録」を特定の IP アドレスからのみ許可
- ユーザーが別のネットワークから初回サインインしようとする
- セキュリティ情報の登録画面に進めず、結果としてサインインが完了しない
つまり、「MFA 必須」なのに「MFA の登録ができない」状態になり、実質的にログインを封じてしまいます。
症状から見た CA 関連トラブルの見分け方
| 症状 | サインインログの例 | 想定される原因 |
|---|---|---|
| サインイン直後にブロックされる | 条件付きアクセスによりブロック | ユーザー／グループが CA ポリシーの対象となっており、IP や端末条件を満たしていない |
| MFA 登録画面が表示されない、ループする | 追加の認証が必要です／セキュリティ情報の登録が必要です | 「セキュリティ情報の登録」を制御する CA ポリシーの対象から外れている、もしくは許可 IP のみになっている |
| 管理者だけはサインインできる | 一部のユーザーのみブロック | 対象ユーザー／グループやロールの範囲が偏っている |
実務でよくある CA 設定の落とし穴
デモ環境・本番環境を問わず、次のような CA 設定がトラブルの原因になりがちです。
- 「セキュリティ情報の登録」アクションを、社内固定 IP のみ許可
在宅勤務や外出先から初回サインインすると、MFA 登録が完了できず、そのままブロックされる。 - レポート専用モードを使わず、いきなり本番適用
影響範囲を確認しないまま適用し、想定外のユーザーやアプリが大量にブロックされる。 - ブレークグラスアカウントまで CA の対象に含める
いざトラブルが発生したとき、ポリシーを変更できるアカウントが一つも残らない状況になる。
安全に CA を一時緩和して登録を完了させる手順例
条件付きアクセスが原因で Power BI や Azure ポータルに入れない場合、次のような手順で一時的にポリシーを緩和し、セキュリティ情報の登録を完了させます。
- 管理者が、CA で許可されているネットワーク（例：社内固定 IP、VPN）からサインイン
- 問題のユーザーを特定し、対象となっている CA ポリシーを確認
- 該当ポリシーを一時的に次のいずれかに変更
- 対象ユーザーから一時的に除外する
- 「セキュリティ情報の登録」アクションに対する制限を緩める（許可 IP を追加する等）
- ポリシーを「レポート専用」モードに切り替え、しばらく様子を見る
- ユーザーにサインインしてもらい、MFA などのセキュリティ情報を登録
- 登録完了後、CA ポリシーを元の設定（または改善した設定）に戻す
ポイントは、登録が終わるまで一時的に緩めることであって、恒久的にセキュリティを弱くすることではありません。登録完了後は、必ずポリシーを元に戻すか、より安全な設計に見直しましょう。
実務で使える切り分けフロー
実際に Power BI / Azure へサインインできないユーザーから「ログインできない」とだけ連絡が来た場合、以下のようなフローで原因を切り分けるとスムーズです。
ステップ 1：テナントの種別と状況を確認
- 利用しているテナントが CDX / 評価テナントかどうかを確認
- CDX 発行時のメールや管理者のメモから、有効期限をチェック
- グローバル管理者アカウントでも Azure ポータルに入れないかを確認
ここで「テナント全体がダメそう」「CDX の有効期限を過ぎている」と分かれば、テナント失効が原因と判断しやすくなります。
ステップ 2：サインインログで失敗理由を確認
テナントが生きていると判断できた場合は、Microsoft Entra 管理センターからサインインログを確認します。
- 対象ユーザーのサインインログを絞り込み
- 失敗したサインインイベントを選択
- 「ステータス」「結果の詳細」「条件付きアクセス」の項目を確認
ここで「条件付きアクセスによりブロック」となっている場合は、ほぼ確実に CA の設定が影響しています。「追加のセキュリティ情報の登録が必要」などが表示されている場合も、セキュリティ情報登録まわりの CA を疑います。
ステップ 3：影響範囲を確認する
CA が原因と分かったら、いきなりポリシーを削除するのではなく、次の観点で影響範囲を確認します。
- 対象ユーザー／グループ／ロールはどこまで含まれているか
- 対象となるアプリ（クラウドアプリ）がどこまで含まれているか（Office 365 全体、Power BI のみ、Azure 管理ポータルのみ 等）
- どのネットワークや端末条件が設定されているか（Trusted Location、デバイス準拠、ハイブリッド参加 等）
この情報を踏まえたうえで、一時的な緩和策を考えます。
管理ポータルに入れない場合の最後の砦：ブレークグラスアカウント
ブレークグラスアカウントとは
ブレークグラスアカウントは、条件付きアクセスによるロックアウトなど緊急時のために用意しておく、すべての CA ポリシーから除外された管理者アカウントです。通常は使用せず、「ガラスを割るような非常時にのみ使用する」ことからこの名前が付いています。
ブレークグラスアカウントが適切に用意されていれば、一般ユーザーや通常の管理者アカウントがすべて CA でロックアウトされてしまっても、次のような対応が可能です。
- ブレークグラスアカウントでサインイン
- 問題の CA ポリシーを一時停止、もしくは影響範囲を縮小
- 状況を確認しながら、他の管理者アカウントの復旧や設定の見直しを行う
ブレークグラスアカウント運用のポイント
| 項目 | 推奨される運用 |
|---|---|
| アカウント数 | 少なくとも 2 つ以上用意し、片方に問題が起きてももう一方が使えるようにする |
| CA ポリシー | すべての条件付きアクセス ポリシーから除外し、ロックアウトの影響を受けないようにする |
| パスワード | 非常に強力なパスワードを設定し、金庫など厳重に管理された場所に保管する |
| 監査 | サインインログやアラートで、利用があった場合に確実に気づける仕組みを用意する |
| 定期確認 | 半年に一度など、定期的に実際にサインインできるか確認する |
CDX を含むデモ環境であっても、Power BI や Azure の検証結果が重要なビジネス判断に使われるケースは少なくありません。ブレークグラスアカウントの有無で、トラブル時の復旧スピードは大きく変わります。
再発防止：CDX テナントと CA を安全に運用するコツ
CDX / 評価テナントの有効期限管理
- テナント発行時に、有効期限をカレンダー（Outlook 予定表など）に登録しておく
- 有効期限の 1〜2 週間前にリマインダーを設定し、延長手続きや新テナントの準備を開始
- 大事なデモ用レポートやスクリプトは、個人の OneDrive や SharePoint など別の場所にバックアップ
「気づいたらテナントが消えていた」という状況を避けるためにも、テナントを資産として管理する意識が重要です。
条件付きアクセスの段階的な適用
CA を適用する際は、本番テナントであってもデモテナントであっても、次のようなステップを踏むことを強くおすすめします。
- まずは小さなテストグループ（IT 部門など）にのみ適用
- しばらく運用し、サインインログやユーザーからのフィードバックで問題がないか確認
- 「レポート専用」モードを活用し、実際にブロックされると想定されるユーザー／アプリを可視化
- 問題がないことを確認してから、対象範囲を段階的に広げて本番適用
特に「セキュリティ情報の登録」を制御する CA は、初回サインインのユーザー全員に影響し得るため、慎重な設計が求められます。
ユーザー向けの案内と初回登録の導線づくり
MFA やセキュリティ情報の登録を行う際、ユーザーへの案内が不十分だと、サポート窓口への問い合わせが急増します。次のようなドキュメントや手順をあらかじめ用意しておくと、トラブルを大きく減らせます。
- 「初回サインイン時の手順書」：スクリーンショット付きで、MFA 登録手順を分かりやすく説明
- 「どのネットワークから登録すべきか」：Named Location（信頼済み場所）を設定し、登録用の安全なネットワークを明示
- 「よくある質問（FAQ）」：スマートフォン紛失時の対応、認証アプリの再登録手順など
チェックリスト：すぐ試せる確認項目
最後に、Power BI / Azure にデモ用アカウントでサインインできない場合に、最初に確認しておきたいポイントをチェックリストとしてまとめます。
| チェック項目 | 確認内容 |
|---|---|
| テナント種別 | 利用中のテナントが CDX / 評価テナントか、通常の本番テナントかを確認する |
| CDX 有効期限 | CDX 発行時の情報やメールで、有効期限を確認し、期限切れになっていないかを見る |
| サインインログ | 対象ユーザーのサインインログを確認し、「条件付きアクセスによるブロック」や「セキュリティ情報の登録が必要」などの記録がないか確認 |
| セキュリティ情報の登録状況 | 問題のユーザーがすでに MFA などのセキュリティ情報を登録済みかどうかを確認する |
| CA ポリシー対象範囲 | 該当ユーザーやグループ、ロールが CA ポリシーの対象になっていないか、除外設定が適切かを確認する |
| 許可 IP / 信頼済み場所 | 「セキュリティ情報の登録」が許可されている IP やネットワークが、実際の利用状況に合っているかを確認する |
| ブレークグラスアカウント | CA から除外されたブレークグラスアカウントが 2 つ以上用意されており、実際にサインインできることを定期的に確認しているか |
以上のチェックを踏まえ、状況に応じて次の方針を取るのが、最短での復旧につながります。
- テナントが期限切れなら：新しいテナントを作成し、ユーザーやアプリ、Power BI 環境を再構成する
- 条件付きアクセスが原因なら：セキュリティ情報の登録が完了するまで一時的に CA を緩和し、登録完了後に再度強化する
デモ用（CDX）テナントは、その性質上「壊れてもリカバリできる」ように設計しておくことが重要です。テナントの有効期限管理、条件付きアクセスの慎重な設計、ブレークグラスアカウントの準備という 3 つのポイントを押さえておけば、Power BI や Azure ポータルのログイン障害が発生しても、落ち着いて復旧対応に移ることができるでしょう。
コメント