Azure AD B2C サポート期限2030年5月とConditional Access/Identity Protection(P1/P2)の影響・対策

Azure AD B2Cを運用していると「2030年5月までサポート」と聞いても、Conditional AccessやIdentity Protection（P1/P2）がそのまま使えるのか不安になります。本記事では公式情報を整理し、2026年3月15日のP2終了を踏まえた影響範囲と、今から取るべき実務対応を具体的に解説します。

結論：Azure AD B2Cは2030年5月まで継続サポート、ただしP2（ID Protection）は2026年3月15日で退役

まず結論から整理します。MicrosoftのFAQでは、既存顧客向けにAzure AD B2Cを少なくとも2030年5月までサポートし、SLA・セキュリティ更新・コンプライアンスなどの運用コミットメントは維持される、と明記されています。一方で、Azure AD B2CのPremium P2（Identity Protection/リスクベース制御を含む領域）は2026年3月15日に全顧客向けに廃止されます。つまり、B2Cそのものは当面動き続けても、P2前提のセキュリティ設計（サインインリスク/ユーザーリスクを条件にした制御や、詳細レポートの粒度）を2030年まで温存する前提では設計できません。

アプリへの影響は「P2のリスク機能に依存しているか」で決まる（依存があれば2026年3月15日までに代替設計が必要）
Conditional Accessそのもの（P1相当）は、既存B2Cテナントで継続利用が想定（ただしB2CのCAは“コンシューマーアカウントで使える機能が一部”という制約あり）
P2は退役後にP1へ自動移行される（P2の機能が残る形ではなく、ティアが切り替わる前提で備える）

まず押さえるべき3つの期限（いつ、誰に、何が起きるのか）

日付	何が起きるか	影響を受ける範囲	実務でやること
2025年5月1日	Azure AD B2Cは新規顧客向けに購入不可（新規販売停止）	「これからB2Cを始めたい」新規導入案件。既存顧客は継続利用が前提	新規導入ならMicrosoft Entra External IDを検討。既存は契約形態・課金設定の確認
2026年3月15日	Azure AD B2C Premium P2（ID Protection）が全顧客で退役し、P1へ移行	P2依存のIdentity Protection/リスクベース制御（サインインリスク/ユーザーリスク）	依存機能の棚卸し→代替策（P1化/外部リスク基盤/External ID移行）を設計し、期限前に切り替え
2030年5月（少なくとも）	既存顧客向けAzure AD B2Cのサポート継続期限（最低ライン）	サービス基盤そのもの。SLA/セキュリティ更新/コンプライアンスは維持とされる	中長期ではExternal ID等の後継へ移行する前提でロードマップ化

「2030年5月までサポート」の意味：アプリは基本的に動き続けるが、将来の設計余地は狭くなる

FAQで示されている「少なくとも2030年5月までサポート」は、既存顧客のB2Cテナントが突然止まる/即時移行が必須になる類の話ではない、という安心材料です。加えて、以下の観点が「大きく変わらない」とされています。

プロダクト体験（機能セット）
SLA
セキュリティ更新
コンプライアンス対応

また、既存顧客については、運用中のB2Cテナントで引き続きユーザーフロー作成や、条件付きアクセスの運用が可能です。注意点として、FAQには「新規テナント作成はP1でのみ可能」という趣旨も含まれます。つまり、将来的に「P2前提の新しいテナント/設計に作り直す」という逃げ道は取りづらく、今ある構成を前提に、段階的な移行・代替が現実路線になります。

まず整理したい前提：B2Cテナントには「管理者（業務アカウント）」と「顧客（コンシューマー）」が同居する

Azure AD B2Cテナントは“顧客ID専用”のイメージがありますが、実際には運用するための管理者アカウント（ワーク/ゲスト）も存在します。この2つは機能の適用範囲が異なるため、影響評価は分けて考えるのが安全です。

アカウント種別	用途	Conditional Access	Identity Protection
管理者/運用者（ワーク/ゲスト）	Azure portalやEntra管理画面でB2Cを設定・運用	フルサポートされる範囲が広い	ワークフォース側の設計（別テナント）と絡むことが多い
顧客（コンシューマーアカウント）	アプリにサインインする会員/利用者（ローカル/ソーシャル/外部IdP）	サブセット（利用できる条件/制御が限定される）	サブセット（利用できるリスク検出が限定される）。P2退役の影響は主にこちらに出る

そもそもB2CのP1/P2と、Microsoft Entra ID（旧Azure AD）のP1/P2は“同じ名前で別物”になりやすい

現場で混乱が起きやすいポイントです。管理画面やドキュメントには「Microsoft Entra ID P1 / P2」表記が出てきますが、Azure AD B2C側にはAzure AD B2C Premium P1 / P2という“B2C用の課金/機能階層”が存在します。さらに、B2CテナントではConditional AccessやIdentity Protectionを使えますが、ワークフォース（社員）向けEntra IDテナントのフル機能がそのまま使えるわけではなく、B2Cのコンシューマーアカウントでは一部機能のみが提供されます。

観点	B2Cテナント（顧客ID）	ワークフォーステナント（社員ID）
主な対象	一般消費者/会員/市民（ローカルアカウント、ソーシャルID、外部IdP）	社員、社内委託、業務用アカウント
ライセンス/課金のイメージ	B2C Premium P1/P2（機能と課金ティア）	Entra ID P1/P2（ユーザー単位等のライセンス体系）
Conditional Access	利用可能（ただしコンシューマーアカウントは“サブセット”）	フル機能
Identity Protection	利用可能（リスク検出は“サブセット”）。P2退役の影響を強く受ける	フル機能

Conditional Accessへの影響：P1相当の条件付きアクセスは2030年までの継続利用が基本線

Azure AD B2Cでは、ユーザーフローやカスタムポリシーに対してConditional Accessを適用し、位置情報・アプリ・ユーザー/グループなどの条件でアクセス制御できます。FAQのサポート方針から見る限り、既存顧客は2030年5月までの期間、Conditional Accessそのものが突然利用不能になる前提で考える必要はありません。

ただし、B2CにおけるConditional Accessは「コンシューマーアカウントで利用できる条件/コントロールが限定される」という設計上の制約があります。これを理解せずに「Entra ID（社員向け）でできるからB2Cでも同じはず」と考えると、実装・運用で詰まりやすいので注意してください。

Conditional AccessをB2Cに適用するときの制約・注意点（ここが落とし穴になりやすい）

コンシューマーアカウントでは、Conditional Accessの条件やコントロールが一部に限定されます（たとえば“デバイスプラットフォーム”など、B2Cではサポートされない条件が存在します）。
サインインリスク（Sign-in risk）/ユーザーリスク（User risk）を条件にするポリシーはP2が前提です。P2退役後（2026年3月15日以降）は、この軸の設計を維持できません。
ソーシャルID（Google/Facebookなど）を使う場合、Conditional Accessの有効化が別途必要になり、リスク検出も「外部IdPが認証情報を管理する」性質上、制約が出ます。
ユーザーフローでConditional Accessを使うには、ユーザーフロー側のプロパティで「条件付きアクセスの強制」を有効化し、MFA enforcementをConditionalにする設計が一般的です。
運用開始前にReport-onlyで影響範囲を見てから本番適用すると、想定外のロックアウトを避けやすくなります（管理者のブレークグラス除外は必須）。

代表的な条件と必要ティア（P1/P2）の整理

条件（Condition）	必要ティア	用途の例	コメント
Locations（Named Location）	P1 / P2	国外ブロック、社内IPのみ許可	“守りの土台”として最も現実的。例外設計（旅行/VPN）もセットで
User risk	P2	リスクユーザーは追加認証やパスワード変更を要求	P2退役に直結するため、依存している場合は最優先で代替検討
Sign-in risk	P2	リスクの高いサインインはMFA、またはブロック	P2退役に直結。カスタムポリシーで分岐している場合はフェイルセーフも再設計
Device platforms	（B2Cでは非サポート）	OS別に制御	社員向けEntra IDでは定番でも、B2Cでは前提にできない

B2Cで現実的に使われやすいConditional Access設計例

狙い	条件（例）	制御（例）	ポイント
不正アクセスの入り口を減らす	特定国/地域、特定IPレンジ（Named Location）	ブロック	「遮断できる範囲」をまず決める。ビジネス要件で海外アクセスがあるなら例外設計が必要
アカウント乗っ取り耐性を上げる	重要アプリ/重要ユーザー	MFA要求（ステップアップ）	ログイン全体にMFAを掛けるより「高リスク操作時に追加認証」を組み込むとUXが崩れにくい
運用事故を避ける	管理者アカウント	除外（ブレークグラス）	B2C運用でも緊急アクセスアカウントを必ず用意し、Conditional Accessの適用外にする

「Conditional Accessは2030年まで使える？」への現場目線の答え

既存顧客のB2Cは少なくとも2030年5月までサポートされ、SLAやセキュリティ更新も維持される方針のため、P1相当のConditional Accessが“期限内に突然消える”リスクは低いと見てよい
ただし、コンシューマーアカウントで利用できる条件/機能はサブセットなので、過去に「たまたま動いていた」構成を放置せず、どの条件を使っているかを文書化しておく
Conditional Accessをユーザーフローに適用する場合、ユーザーフロー側に「条件付きアクセスを強制する」設定が必要なケースがある。古いユーザーフローを使い続けるより、推奨（Recommended）表記のあるバージョンで再作成して差し替える方が安全

Identity Protectionへの影響：P2（ID Protection）退役により、リスクベース制御の前提が2026年3月で崩れる

Identity Protectionは、サインインのふるまいからリスクを検出し、リスクユーザーやリスク検出（risk detections）として可視化・調査・対処できる仕組みです。Azure AD B2CでもIdentity Protectionは利用できますが、B2Cでは利用できるリスク検出がサブセットである点に注意が必要です。

そして最重要なのが、サインインリスク/ユーザーリスクを条件にしたConditional Accessや、リスク情報を前提にした運用は、P2（ID Protection）に依存することです。P2（ID Protection）は2026年3月15日に退役し、P1へ移行します。したがって、リスク信号に依存している場合は、2026年3月15日以降は同じ形での運用はできない前提で見直すのが安全です。

B2Cでサポートされる代表的なリスク検出（例）

B2Cでは、Entra ID全体のリスク検出のうち一部が提供されます。運用上は「どの検出を根拠に制御しているか」を明確にしておくと、代替設計がしやすくなります。

実務では「いつからいつまでのデータを追えるか」が重要です。B2CのIdentity Protectionでは、リスク検出（Risk detections）レポートが過去のデータを一定期間（例：最大90日）表示できる設計になっていますが、監査やフォレンジックで長期保管が必要なら、早い段階でログのエクスポート/保管先（Azure MonitorやSIEM）を用意しておくと安心です。

リスク検出タイプ	概要	現場での見方
Atypical travel	直近のサインイン傾向と異なる地点からのサインイン	海外出張やVPN利用が多い環境では誤検知もあり得る。例外設計とセットで考える
Anonymous IP address	Torや匿名化VPNなど匿名IPからのサインイン	「ブロック」か「MFA要求」かはサービス性質次第。会員登録直後の悪用検知にも効く
Malware linked IP address	マルウェアに関連付けられたIPからのサインイン	基本的に強いシグナル。高リスクとして扱い、追加認証や一時ブロックを検討
Unfamiliar sign-in properties	最近見られないプロパティ（端末/ネットワーク特性など）でのサインイン	端末変更やブラウザ更新でも出る可能性があるため、運用でのチューニングが重要
Admin confirmed user compromised	管理者がユーザー侵害を確認した状態	検出というより“運用で付与するシグナル”。事故対応や強制リセットの判断材料になる
Password spray	パスワードスプレー攻撃の兆候	アカウントロック/スマートロックアウトと合わせて守りを厚くする
Microsoft Entra threat intelligence	脅威インテリジェンスに基づく既知の攻撃パターン	“理由がわからないが危険”になりやすい。ログ保全と調査手順を先に作っておく

「risky users report」と「details」の違い：レポートの粒度が“運用コスト”に直結する

Identity Protectionは「レポートでの可視化」と「それを使った制御」に分解して考えると整理が早いです。Microsoft Learnの記載では、B2CではP1でも一定のレポート閲覧やダウンロード、Graph APIでの取得が可能で、P2では“details”の粒度が上がる構造になっています。

観点	一覧（report）	詳細（report details）	実務への影響
Risky users	リスク状態（At risk/Remediated/Dismissed）や対象ユーザーを俯瞰する	個別ユーザーの検出履歴、調査・対応（リスクの却下/侵害確認など）	詳細が取れないと「なぜ止めたか/なぜ追加認証が出たか」の説明が難しくなり、CS/SOCの負荷が上がりやすい
Risk detections	検出タイプ、同時発生したリスク、サインイン地点などを俯瞰する	個別の検出イベントに深掘りして調査する	誤検知の切り分けや攻撃再現の難易度が変わる。ログ保全と相関分析の設計が重要

自動リスク修復（automatic remediation）とは何か：B2Cでは「評価→追加認証→リスク解消」の流れ

リスクベースのConditional Access（サインインリスク/ユーザーリスク）を使う場合、B2C側では大まかにEvaluation（評価）とRemediation（修復）の2段階で動きます。評価で「このサインインはリスクが高い」と判断されたら、ユーザーにMFAを要求したり、アクセスをブロックしたりします。評価の精度を保つためには、ローカル/ソーシャルを問わず、すべてのサインインでEvaluation（評価）を実行する設計が推奨されます。MFAを完了すると、B2CはIdentity Protection側へ「この脅威はこの方法で修復された」ことを通知し、リスク状態を更新します。修復はMFA以外にも、管理者/ユーザーによるパスワードリセットなどで行われます。

カスタムポリシー（IEF）でConditional Accessを組み込んでいる場合、技術的には「Evaluationの後にRemediationのテクニカルプロファイルを呼ぶ」ことが重要になります。評価だけ行って修復に進まないと、リスク状態が“At risk”のまま残る動きになりやすいため、設計・テストの観点として覚えておくと事故を減らせます。

&lt;TechnicalProfile Id="ConditionalAccessRemediation"&gt;
  &lt;DisplayName&gt;Conditional Access Remediation&lt;/DisplayName&gt;
  &lt;Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine" /&gt;
  &lt;Metadata&gt;
    &lt;Item Key="OperationType"&gt;Remediation&lt;/Item&gt;
  &lt;/Metadata&gt;
&lt;/TechnicalProfile&gt;

アプリケーションへの影響を見誤らないための「依存関係マップ」

「B2Cが2030年まで動く」と「いまのセキュリティ設計が2030年まで同じ形で維持できる」は別です。影響評価は、アプリがどの信号（リスク、場所、MFAなど）に依存しているかを整理すると一気に進みます。

依存している機能	よくある実装例	2026年3月15日以降	影響の出方	現実的な対策
場所/アプリ/ユーザー・グループ条件のConditional Access	国外IPはブロック、特定アプリはMFA要求、管理者は除外	基本的に継続利用の想定	大きな変更なし。ただしB2CのCAはサブセットのため、使っている条件を要確認	ポリシーの棚卸しと、例外（Named Location、ブレークグラス）の見直し
サインインリスク/ユーザーリスクを条件にしたポリシー	「Sign-in riskが高い場合はMFA」などのテンプレート活用	成立しない前提で再設計が必要	“想定していた自動判定”が消える。セキュリティ強度が下がるか、運用で補う必要	P1条件へ置き換え、外部の不正検知/ボット対策、行動分析、SIEM相関で補完
Identity Protectionの詳細（details）を前提にした運用	CSやSOCが詳細画面で原因を追い、ユーザーに説明する	詳細粒度が確保できなくなる可能性が高い	調査コスト増、誤検知判定が難化。監査対応の説明材料が不足する	監査ログ/サインインログの長期保管、アプリ側イベントログの整備、調査手順の標準化
カスタムポリシー（IEF）でConditional Access技術プロファイルを利用	Evaluation/RemediationでMFAに分岐	“リスク信号”が得られない前提が必要	フロー自体は動くが、分岐条件が常にFalse/Unknownになり、守りが薄くなる恐れ	「信号が取れない場合のフェイルセーフ」（追加認証/制限）を設計し直す

P2利用中の組織が見落としやすい「費用と切り替えタイミング」

Microsoftの開発者向け更新情報では、P2利用中の顧客は2026年3月15日まではP2/ID Protectionを継続利用でき、課金も継続し、期限到来でP1へ移行すると示されています。これは「ギリギリまでP2を使って移行準備を進める」ことも、「早めにP1へ切り替えて差分を前倒しで潰す」ことも、どちらも可能だということです。

選択肢	メリット	デメリット	向いているケース
期限までP2を維持	移行までの間、リスクベース制御を最大限使える	切替が集中し、直前に炎上しやすい	複数アプリ/複数組織で調整が必要で、猶予を最大化したい
早期にP1へ切替	“P2がなくなった世界”を早めに固定化して、運用を安定させやすい	セキュリティ差分を早期に失う。代替策が先に必要	リスクベース制御の依存が軽く、P1＋外部対策で早期に回せる

今すぐやるべき棚卸し：2026年3月15日までに“やり切る”ためのチェックリスト

期限が明確な以上、対応は「いつか」ではなく「順番」を決めて進めるのが安全です。以下は現場で抜けやすいポイントを含めたチェックリストです。

チェック項目	確認場所/方法（例）	優先度	補足
対象B2Cテナントの課金ティア（P1/P2）	Azure portalのB2C設定、課金/サブスクリプション紐付け	最優先	P2が有効なテナントは2026年3月15日に前提が崩れる
Conditional Accessポリシーの一覧と適用対象アプリ	Azure portal > Azure AD B2C > Security > Conditional Access	最優先	「どのアプリがどのポリシーに守られているか」を可視化する
ポリシー条件に「Sign-in risk / User risk」を使っていないか	各ポリシーの条件（Conditions）を確認	最優先	該当する場合はP2依存。代替案が必要
ユーザーフローがConditional Access対応（Recommended）か	User flowsのプロパティでConditional Access設定を確認	高	古いユーザーフローを使い続けると、将来的な差分が出やすい
リスクレポート/サインインログの保管期間要件	監査要件、社内規程、規制（例：金融/医療）	高	ログ保持が短い前提で、Azure Monitor/SIEMへエクスポートする設計が必要
CS/不正対策/SOCの運用フロー（誰が何を判断するか）	運用手順書、アラートルール、対応SLA	中	P2の詳細がなくなると、人の判断が増える可能性がある

2026年3月15日以降の代替策：3つの現実解

P2が担っていた「自動でリスクを判定し、必要に応じて追加認証/遮断する」役割をどう埋めるかがポイントです。代替策は大きく3系統に分かれます。

P1のConditional Accessに寄せて“シンプルに守る”（最短で現実的）

Named Location（国/地域、IPレンジ）で「そもそも来てほしくない場所」をブロック
重要なアプリ/操作にだけステップアップMFAを要求（ログイン全体に強制しない）
異常検知はB2C外（WAF/アプリログ/監視）で行い、B2Cは“止める/追加認証する”に集中させる

外部の不正検知・ボット対策・本人確認を組み合わせる（P2の穴埋めとして強力）

MicrosoftはAzure AD B2C向けに、本人確認（KYC）、不正/ボット対策、WAFなどの連携パートナーを公開しています。P2の終了後は、こうした外部シグナルを取り込み、登録（サインアップ）やログイン、重要操作のタイミングで「追加検証」を挟む設計が有効です。

カテゴリ	代表的な用途	例（パートナー/サービス）	入れどころ
Fraud protection / Bot対策	ボットによる大量登録、アカウント乗っ取り、クレデンシャルスタッフィング対策	Arkose Labs、BioCatch、Microsoft Dynamics 365 Fraud Protection など	サインアップ、ログイン、パスワードリセット
Web Application Firewall（WAF）	OWASP Top10や不正トラフィックの遮断、レート制限	Azure WAF、Cloudflare、Akamai WAF など	認証ページ/認証APIの手前（リバースプロキシ層）
Identity verification / Proofing	なりすまし登録防止、本人確認、年齢確認	Jumio、Onfido、LexisNexis、Experian など	初回登録、属性変更（氏名/住所/電話番号）

ログと相関分析で“検知→対応”を強化する（運用品質で補う）

B2Cのリスク信号が弱まるなら、ログ設計を強くするのが王道です。B2Cのサインインログ/監査ログは保持期間が短いため、監査や調査要件がある場合はAzure MonitorやSIEM（例：Microsoft Sentinel）へエクスポートし、次のような相関を作ると実務が回りやすくなります。

短時間に多数の失敗ログイン（IP・ユーザーID・UserAgentで集計）
登録直後のアクセス集中、同一端末指紋からの多重アカウント作成
パスワードリセットの連続試行、同一メールドメインの異常増加

Microsoft Entra External IDへの移行：2030年を待たずに“計画的に終わらせる”のが安全

Microsoftは後継の外部IDプラットフォームとしてMicrosoft Entra External IDを提示しています。FAQでは、B2Cの既存顧客向けに少なくとも2030年5月までサポートするとしつつ、今後の移行計画の情報提供が予定されています。特にカスタムポリシー（IEF）に大きく投資している場合でも、移行パスを提供する方針が示されています。

移行は「いきなり全ユーザーを移す」より、アプリ単位・機能単位で段階的に進めるのが現実的です。

フェーズ	ゴール	やること	成果物
評価	External IDで要件が満たせるか判断	認証方式（OIDC/SAML）、ソーシャルID、MFA、カスタムUI、監査要件の確認	ギャップ一覧、移行方針
設計	“B2Cでやっていたこと”を再現する道筋を作る	ユーザージャーニー、属性、トークン設計、SSO、運用（CS/不正対策）の再設計	基本設計、テスト計画
並行稼働	リスクを抑えて移行する	新規ユーザーのみ新基盤へ、既存はB2C維持、段階的に比率を上げる	切替手順、ロールバック手順
移行完了	B2C依存を最小化	全アプリ切替、不要ポリシー削除、監査証跡の最終保管	運用手順書、最終報告

よくある質問（運用でつまずきやすいポイント）

既存顧客なら、2030年5月まで何もしなくても大丈夫？

「認証が動く」という意味ではすぐに困らない可能性が高い一方、P2（ID Protection）に依存するリスクベース制御を使っている場合は2026年3月15日までに必ず設計変更が必要です。特に“何か起きたときにP2の詳細画面で調査する”運用をしていると、セキュリティとCSの両面で影響が出ます。

新しいB2Cテナントやユーザーフローは作れる？

既存顧客は引き続き作成できます。ただし、新規テナントはP1でのみ作成可能で、P2を前提とした新設計にはできません。将来を見据えるなら「新規アプリはExternal IDで開始し、既存アプリはB2Cを延命しつつ順次移行」という二段構えが取りやすいです。

P2終了後、サインインが“壊れる”のか、“守りが薄くなる”のか？

多くのケースでは、サインイン自体が突然失敗するよりも、リスク信号が得られずに想定していた分岐が効かなくなる（結果として守りが薄くなる）パターンが現実的です。カスタムポリシーでリスククレームの有無を前提にしている場合は、フェイルセーフ（信号が取れない場合は追加認証）を設計し直すのが安全です。

まとめ：2030年までの“安心”と、2026年までの“宿題”を切り分ける

既存顧客のAzure AD B2Cは、少なくとも2030年5月までサポート継続。SLA/セキュリティ更新/コンプライアンスも維持される方針
Azure AD B2C Premium P2（ID Protection）は2026年3月15日に退役しP1へ移行。P2依存のリスクベースConditional Accessや詳細運用は、そこで前提が崩れる
いまやるべきは「P2依存の棚卸し」→「P1に寄せる/外部シグナルで補う/External IDへ移行」のいずれかに決めて計画化すること

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。