Azure AD B2C Premium P2 の販売終了がアナウンスされ、現行テナントの将来や切替手順に不安を抱く担当者は多いはずです。本記事では「いつ何がどう変わるのか」「P1 へ移行したら何が使えなくなるのか」「実務として何を、いつまでにやれば良いのか」を、現場でそのまま使える粒度で体系的に整理します。プロジェクト計画、社内説明、影響評価にそのまま転用できるように、実践的な表・チェックリストも豊富に掲載します。
目次
Azure AD B2C P2 販売終了で何が起きるのか（結論の先出し）
販売終了日：2026年3月15日
- 既存テナントは存続：P2 の販売終了後も既存の B2C テナントは引き続き稼働し、SLA とセキュリティ更新は少なくとも 2030年5月までは継続されます。
- ライセンスは P1 へ移行必須：2026年3月15日以降、P2 を保持し続けることはできません。P1 ライセンスへ変更が必要ですが、テナントやユーザー、アプリ登録を作り直す必要はありません。
- 切替方法はシンプル：移行手続きは主にバックエンドで行われます。Microsoft の営業窓口（アカウント担当）へ依頼すればよく、原則としてポータルでの再構成は不要です。
- サービス停止は想定されない：ローカル／ゲスト アカウント、サインインフローはそのまま動作し、切替による計画停止は不要と見込まれます。
- 失われる機能：P2 専用の サインイン リスク ポリシー／ユーザー リスク検知／リスクベース条件付きアクセス は利用できなくなります。
スケジュールと移行計画（実務者向けタイムライン）
販売終了日とサポート継続時期に合わせ、計画・準備・検証・本番切替の各フェーズを逆算します。次の標準テンプレートをベースに、社内のガバナンスに沿って微調整してください。
| フェーズ | 推奨時期 | 主なタスク | 成果物 |
|---|---|---|---|
| 方針決定 | 〜2025年Q1 | 適用対象のテナントとアプリを棚卸／P2 機能の利用実態を洗い出し／リスク代替案の選定 | 影響評価レポート、代替アーキテクチャ案 |
| 設計 | 2025年Q2〜Q3 | P1 への切替方式を確定／MFA・サインインフローの再検証／API コネクタや外部リスクエンジン連携の要件化 | 基本設計書、試験計画、移行計画 |
| 検証 | 2025年Q3〜Q4 | ステージングでの回帰試験／パフォーマンス・可用性確認／運用監視の再設定 | 試験記録、Go/No-Go 判定 |
| 移行申請 | 2026年1月〜2月 | Microsoft 営業窓口へ P1 への切替を依頼／社内 Change 管理の起案 | 切替依頼書、承認記録 |
| 本番切替 | 2026年3月15日 前後 | 監視強化・利用者向け告知（必要な場合）／切替実施の立会い | 切替完了報告、影響なし確認 |
| 運用・最適化 | 〜2030年5月 | セキュリティ更新・運用監視の継続／代替リスク対策の効果測定 | 月次レポート、改善サイクル |
影響の全体像（何が変わり、何が変わらないか）
| 領域 | P2 販売終了後の状態 | 影響 | 対応方針 |
|---|---|---|---|
| テナント | 継続利用可能 | なし | 従来どおりの運用を継続 |
| ユーザー（ローカル／ゲスト） | アカウント・属性・クレームは維持 | なし（再登録不要） | プロファイル・同意・本人確認フローは従来どおり |
| アプリ登録 | アプリID／リダイレクトURI／シークレットは維持 | なし | 発行者・メタデータは変更なし |
| ユーザーフロー／カスタムポリシー | P1 でも継続利用可能 | なし | XML ポリシー・Ief プロファイルの変更不要 |
| MFA | 引き続き利用可能（P1 で提供） | なし | サインイン時のステップアップはそのまま |
| リスク検知・リスクベース制御 | P2 専用機能は停止 | あり | 後述の代替策を適用（Entra ID 側や外部リスク連携） |
| 課金・契約 | P1 契約へ切替 | あり（契約・支払ライン） | 営業窓口で手続き。技術構成変更は原則不要 |
失われる P2 専用機能と代替アプローチ
P2 固有の高度なリスク機能が利用できなくなるため、セキュリティ要件に応じて次の代替策を準備します。
| 失われる P2 機能 | P1 での状態 | 推奨の代替策 | 実務ポイント |
|---|---|---|---|
| サインイン リスク ポリシー | 不可 | Entra ID 側の Identity Protection（ワークフォース／B2B での利用）、または B2C カスタムポリシーから外部リスクエンジンを呼び出す | API コネクタ／REST 技術プロファイルでリスクスコアを取得し、スコアに応じて MFA 強制・ブロックを分岐 |
| ユーザー リスク検知 | 不可 | 利用者行動分析（UEBA）や不正検知 SaaS を連携 | 匿名化された端末指紋や過去イベントをキーにリスク蓄積、属性にリスクフラグを付与 |
| リスクベース条件付きアクセス | 不可 | 地理・ASN・デバイス健全性など静的条件の活用、または外部シグナルによるダイナミック制御 | Bot・クレデンシャルスタッフィング対策として CAPTCHA／レート制限を強化 |
代替アーキテクチャ例（B2C カスタムポリシー活用）
- サインイン前半で REST 技術プロファイル を呼び出し、IP、ユーザー、デバイス、過去失敗回数などを送信。
- 外部リスクエンジンから
riskScore（0〜100）とriskReasonsを受け取り、クレームに格納。 - オーケストレーション ステップで
riskScore >= 70の場合は MFA を強制、>= 90の場合は ブロック。 - 監査用にクレームをアプリへ渡さず、Log Analytics にのみ出力。
この方式なら P1 でも「事実上のリスクベース認証」を実装できます。運用での誤検知率・通過率を可視化し、しきい値は段階的にチューニングしてください。
P1 で引き続き使える主要機能
- 多要素認証（MFA）：SMS／音声電話／認証アプリなどの二段階認証。
- 外部 ID 連携：OpenID Connect／OAuth2.0／SAML による Google、Apple、Facebook、LINE などの ID 連携。
- ユーザーフローとカスタムポリシー：サインイン／サインアップ、パスワードリセット、プロフィール編集、カスタム属性、ブランド／UI カスタマイズ。
- 開発者機能：JWT クレーム、Graph API／管理 API、SDK、テナントごとのキー管理、トークンライフタイム制御等。
- 運用・監視：監査ログ、サインインログ、アラート、可用性監視、SLA。
切替方法の詳細（バックエンド手続きと現場チェック）
切替は Microsoft 側のバックエンド処理で行われます。原則としてポータルでの再設定は不要ですが、次の確認をしておくと安心です。
事前確認（推奨）
- 対象テナント・サブスクリプション・課金アカウントの整合。
- ユーザーフロー／カスタムポリシーのバックアップ（XML のエクスポート）。
- アプリ登録（アプリID、URI、機密情報）の棚卸と有効期限の見直し。
- 外部 ID プロバイダー（OIDC/SAML）のメタデータ有効期限の確認。
- 監視（ログ収集・アラート）とダッシュボードの再点検。
当日の運用
- 計画停止は不要。ただし監視を臨時強化し、主要フローの合否を 5〜10 分間隔で追跡。
- 重要アプリについては、開発者・コールセンター待機体制をとると安心。
事後確認
- サインイン成功率・MFA 成功率・平均応答時間のトレンドを比較。
- 障害・苦情の有無。問い合わせ件数・失敗理由（MFA、IDP、ネットワーク）。
- 想定どおり P2 機能が停止し、代替ロジックが動いていること。
影響が出やすいユースケースと回避策
| ユースケース | 懸念 | 回避策 |
|---|---|---|
| 高リスク国・ASN からの攻撃的トラフィック | リスクベース制御喪失により通過率が上がる | 地理・ASN ブロック、WAF の Bot 対策、レート制限、カスタムポリシーでの CAPTCHA 追加 |
| 合成不正（購入直前のみアカウント乗っ取り） | 都度の検知が弱くなる | 取引直前の ステップアップ MFA を導入（トランザクション署名） |
| パスワードスプレー／クレデンシャルスタッフィング | ログイン試行が急増 | IP レピュテーション照会＋遅延挿入／アカウントロックしきい値の見直し |
| ゲスト連携（B2B/企業間）と B2C の混在 | ポリシーが分かれて管理が複雑 | Entra ID 側の条件付きアクセスと役割分担を明確化、B2C は顧客向けに専念 |
監視・運用の再設計ポイント
- メトリクスの基準値を更新：P2 → P1 切替直後の 1〜2 週間はベースラインが揺れます。成功率、MFA 失敗率、平均処理時間の“新常態”を採取。
- 失敗理由の分類：MFA／外部 IDP／ネットワーク／ユーザー操作ミスの 4 区分に自動ラベル付けし、週次でトップ要因を是正。
- 不正兆候の早期検知：一定時間内の同一デバイス・同一 ASN・同一メールドメインでの試行数アラートを整備。
- ログの保持と相関：サインインログ、アプリログ、WAF／CDN ログを相関させ、KPI ダッシュボードを統合。
テスト計画テンプレート（そのまま使える）
| テスト項目 | 観点 | 期待結果 | 備考 |
|---|---|---|---|
| ローカルアカウントでのサインイン | 通常／ロック後／パスワードリセット | 従来と同じ UX と成否判定 | 成功率・平均時間を計測 |
| 外部 ID 連携（Google/Apple 等） | 初回同意／再同意／リンク解除 | 属性マッピングとクレームが維持 | メタデータ期限・証明書ローテーション |
| MFA ステップアップ | 通常時／高額取引時 | MFA が適切なトリガで要求される | 通知の可用性・遅延も確認 |
| リスク代替ロジック | 高リスク IP／AS／端末 | しきい値に応じて拒否／MFA 強制 | 誤検知率を 1% 未満に調整 |
| スループットとレイテンシ | ピーク時 | SLA 内で安定 | CDN・キャッシュ併用の検討 |
コストと契約の観点
- P1 への統一で予算が読みやすくなる：P2 専用機能廃止により、機能差による複雑な料金整理が不要になります。
- 外部サービス連携コスト：リスク代替のための不正検知 SaaS／UEBA／IP レピュテーションの費用を見積もり、ログ転送量・API 呼び出し回数も忘れずに試算。
- サポート契約：切替期間中は重要アプリのサポート優先度を一段上げることを検討。
セキュリティ設計のベストプラクティス（P1 での堅牢化）
- 段階的 MFA：常時 MFA ではなく、リスク代替ロジックやトランザクションの重要度に応じてステップアップ。
- 秘密情報の有効期限管理：アプリシークレット／証明書のローテーションを自動化し、期限 30 日前のアラートを必須化。
- 登録系フローの耐攻撃性：サインアップ時にメール検証・電話番号検証・ボット対策を多層化。
- 最小権限の徹底：管理者ロールは作業時に一時付与、終了後に剥奪（PIM 的運用）。
- 監査ログの完全性：すべての重要フローで相関 ID を出力し、外部 SIEM で改ざん検知。
よくある質問（FAQ）
Q. テナントやユーザーを作り直す必要はありますか？
A. ありません。テナントは存続し、ユーザーやアプリ登録も継続利用できます。
Q. 切替でサービス停止は発生しますか？
A. 想定されていません。監視を強化し、重要フローの疎通確認を行えば十分です。
Q. 何が使えなくなるのですか？
A. P2 専用の「サインイン リスク ポリシー／ユーザー リスク検知／リスクベース条件付きアクセス」が利用できなくなります。MFA や外部 ID 連携、カスタムポリシー等の主要機能は P1 でも維持されます。
Q. 代替策は？
A. Entra ID 側の機能活用（特に B2B 連携や社内利用での CA／Identity Protection）や、B2C のカスタムポリシーから外部リスクエンジンを呼び出す方式が実務的です。
Q. いつまでに何をすれば良いですか？
A. 2025 年内に影響評価、2026 年 1〜2 月に切替依頼、3 月 15 日前後に本番切替、以後は 2030 年 5 月まで運用最適化を継続するのが目安です。
社内外コミュニケーションに使える雛形
経営層向けエグゼクティブサマリー（メール例）
件名：Azure AD B2C P2 販売終了に伴う当社対応方針（P1 へ移行）
本文：
・2026/03/15 に B2C P2 の販売が終了、当社テナントは存続（SLA/セキュリティ更新は少なくとも 2030/05 まで）
・P2 専用のリスク機能は停止、P1 へ移行（Microsoft 側バックエンド手続き）
・サービス停止は見込まず、主要機能（MFA/外部 ID/カスタムポリシー）は継続
・代替策：外部リスク連携＋ステップアップ MFA を段階適用
・スケジュール：2025 年内に検証完了、2026/01-02 で切替申請、3/15 前後に本番切替
ご承認お願いいたします。
開発・運用チーム向けチェックリスト
- カスタムポリシー XML のバックアップを最新化
- 主要アプリのシークレット／証明書有効期限を棚卸
- 外部 IDP のメタデータ更新計画を確認
- ログとアラートの基準値を更新・ドキュメント化
- 高リスク時のステップアップ MFA とブロック条件を合意
現場で役立つ「P2 → P1」差分サマリー表
| カテゴリ | P2 | P1（切替後） | 実務メモ |
|---|---|---|---|
| テナント継続 | ◯ | ◯ | 移行に伴う再構築は不要 |
| ユーザー/アプリ再登録 | 不要 | 不要 | 影響なし。疎通試験のみ実施 |
| MFA | ◯ | ◯ | ステップアップ制御でセキュリティ維持 |
| 外部 ID 連携 | ◯ | ◯ | IDP メタデータの期限に注意 |
| リスク検知 | ◯ | — | 外部リスク連携や運用で補完 |
| 条件付きアクセス（リスクベース） | ◯ | — | ワークフォース/B2B は Entra ID 側で実装 |
移行を安全にやり切るための「7 つの実践則」
- 機能利用実態を「データ」で把握：過去 90 日のサインインログから、MFA 要求率・外部 ID 利用率・失敗要因を可視化。
- しきい値は“保守的”に開始：代替リスクスコアの初期値は厳しめに、誤検知の苦情が増えたら段階的に緩和。
- ステージングで負荷を再現：実利用のピーク特性（時刻・地域・端末）を模擬し、90 パーセンタイルの遅延を測定。
- 監視は「サマリ＋深掘り」を両立：役員向け KPI と、運用向けドリルダウンを 1 つのダッシュボードで。
- 秘密情報は「期限前 30 日」で自動更新：人手運用をなくし、更新失敗時は即ロールバック。
- インシデント演習：認証障害・外部 IDP 障害を想定し、フェイルセーフと顧客告知テンプレを準備。
- 監査証跡の一元化：利用規約・同意・本人確認の証跡をテナント外のストレージに二重保管。
まとめ：P2 の終焉は「設計の見直し」の好機
P2 の販売終了は大きなニュースですが、テナントや主要機能は継続し、サービス停止も想定されません。むしろ、リスク対策をアーキテクチャとして明文化し、段階的 MFA と外部シグナル連携にアップデートする好機です。2025 年中に影響評価と検証を完了し、2026 年 1〜2 月に手続きを済ませることで、3 月 15 日の販売終了を平穏に迎えられます。以後は 2030 年 5 月までの運用で、継続的改善とセキュリティ成熟度の引き上げに注力しましょう。
付録：移行作業チェックリスト（コピー＆利用可）
| カテゴリ | チェック項目 | 責任者 | 期限 | 状態 |
|---|---|---|---|---|
| アセスメント | P2 機能の利用有無を棚卸（リスク系） | セキュリティ担当 | 2025-03-31 | 未/進/完 |
| 設計 | 外部リスク連携の方式決定（API/しきい値） | アーキテクト | 2025-06-30 | 未/進/完 |
| 開発 | カスタムポリシーに REST 技術プロファイル追加 | 開発チーム | 2025-08-31 | 未/進/完 |
| 検証 | 回帰・負荷・障害訓練の完了 | QA | 2025-10-31 | 未/進/完 |
| 運用 | 監視ダッシュボードとアラートの更新 | 運用チーム | 2025-11-30 | 未/進/完 |
| 手続き | Microsoft 営業窓口へ P1 切替依頼 | 購買/契約 | 2026-02-15 | 未/進/完 |
| 本番 | 切替当日の監視強化と疎通確認 | SRE | 2026-03-15 | 未/進/完 |
コメント