Microsoft Entraの登録キャンペーンは、ユーザーのサインイン時にパスキーまたはMicrosoft Authenticatorの設定を促す機能です。2026年5月31日時点で管理者がまず確認すべき結論は、Microsoft managedのままにしているテナントでは、登録キャンペーンの対象がMicrosoft Authenticator中心からパスキー中心へ変わる可能性があるという点です。
この機能は「認証方法を強制的に切り替える設定」ではなく、MFA完了後により安全な認証方法の登録を促す仕組みです。ただし、対象ユーザー、スヌーズ設定、パスキーのAAGUID制限、条件付きアクセスの設定によって、ユーザーに表示されるプロンプトや展開結果は大きく変わります。Microsoft Entra IDでパスキーやMicrosoft Authenticatorを段階展開する場合は、先に登録キャンペーンの状態と認証方法ポリシーを確認しておきましょう。(Microsoft Learn)
Microsoft Entraの登録キャンペーンとは
Microsoft Entra IDの登録キャンペーンは、ユーザーが通常どおりサインインし、Microsoft Entra多要素認証を完了した後に、指定した認証方法の登録を促す機能です。対象にできる認証方法は、Passkey（FIDO2）とMicrosoft Authenticatorです。
登録キャンペーンでできることは、主に次の3つです。
| できること | 内容 |
|---|---|
| 認証方法の登録を促す | パスキーまたはMicrosoft Authenticatorの登録画面をサインイン中に表示する |
| 対象ユーザーを絞る | ユーザーまたはグループを含める、または除外する |
| スキップ可否を調整する | ユーザーが後回しにできる日数や回数を設定する |
重要なのは、同じテナントでパスキーとMicrosoft Authenticatorの登録キャンペーンを同時に実行できない点です。1つの登録キャンペーンで対象にできる認証方法は1つだけです。(Microsoft Learn)
たとえば、SMSや音声通話を使っているユーザーをMicrosoft Authenticatorへ移行したい場合はAuthenticatorキャンペーンを使います。一方、フィッシング耐性を高めるためにFIDO2パスキーを普及させたい場合は、パスキーを対象にしたキャンペーンを使います。
2026年5月時点の主な変更点
今回のポイントは、登録キャンペーンそのものの存在よりも、Microsoft managed設定の扱いです。Microsoft managedを選ぶと、Microsoft Entra IDがテナントの状態を評価し、推奨されるキャンペーン設定を自動的に適用します。Graph API上では、このMicrosoft managedに相当する状態がdefaultとして扱われます。(Microsoft Learn)
特に確認したい変更点は次のとおりです。
| 項目 | 従来の考え方 | 2026年5月時点で確認すべき点 |
|---|---|---|
| 対象認証方法 | Microsoft Authenticator中心 | 条件を満たすテナントではPasskey（FIDO2）に移る可能性がある |
| スヌーズ日数 | 管理者が調整しやすい | Microsoft managedでは1日に変更され、構成不可になる |
| スヌーズ回数 | 制限ありにできる | Microsoft managedでは無制限スヌーズに変更され、構成不可になる |
| 対象ユーザー | 音声通話またはSMS利用者が中心 | すべてのMFA対応ユーザーへ広がる可能性がある |
| 管理者の選択肢 | Microsoft managedのまま運用 | 要件に合わなければEnabledまたはDisabledへ変更する |
Microsoft managedの登録キャンペーンでは、パスキー（FIDO2）プロファイルが同期型パスキーとデバイスバウンドパスキーの両方を許可している場合、対象認証方法がパスキーへ変わる可能性があります。条件を満たすユーザーがいない場合は、Microsoft Authenticatorのままになります。(Microsoft Learn)
「Microsoft managedのまま」は安全策とは限らない
Microsoft managedは便利ですが、すべての組織にとって最適とは限りません。たとえば、パスキーを有効化していても、ヘルプデスク体制や端末要件の準備ができていない場合、ユーザーに突然パスキー登録の案内が表示されると問い合わせが増えます。
逆に、パスキー展開を進めたい組織では、Microsoft managedを活用することで、対象ユーザーへ自然に登録を促せます。ただし、無制限スヌーズになる点には注意が必要です。ユーザーが毎回スキップできる設定では、登録率が思ったほど上がらないことがあります。
登録を強く進めたい場合は、状態をEnabledにして、スヌーズ回数を制限する運用を検討します。公式ドキュメントでは、Limited number of snoozesを有効にすると、ユーザーは3回までスキップでき、その後は対象認証方法の登録が必要になります。(Microsoft Learn)
影響を受けるテナントとユーザー
今回の登録キャンペーンで特に影響を受けやすいのは、次のようなテナントです。
| 対象 | 影響 |
|---|---|
| 登録キャンペーンをMicrosoft managedで運用しているテナント | 対象認証方法やスヌーズ設定がMicrosoft推奨値へ変わる可能性がある |
| パスキー（FIDO2）を有効化しているテナント | 条件を満たすユーザーにパスキー登録のナッジが表示される可能性がある |
| SMS・音声通話からの移行を進めている組織 | 対象がMFA対応ユーザー全体へ広がる可能性がある |
| Microsoft AuthenticatorをTOTPコード用途だけで使っているユーザー | Authenticatorのプッシュ通知設定を求められる可能性がある |
| サードパーティ認証アプリを使っているユーザー | 対象認証方法が未登録なら、Microsoft Authenticatorまたはパスキーのナッジが表示される可能性がある |
| B2B/ゲストユーザー | ポリシー対象に含まれていればナッジ対象になる |
「すでに認証アプリを使っているから対象外」とは限りません。たとえば、Microsoft AuthenticatorをTOTPコード専用で使っている場合、Authenticatorのプッシュ通知は未設定と判断され、登録キャンペーンの対象になる場合があります。また、サードパーティ認証アプリでMFAしているユーザーも、対象認証方法が未登録であればナッジが表示されます。(Microsoft Learn)
管理者が最初に確認すべき設定
登録キャンペーンを確認する場所は、Microsoft Entra管理センターの次の画面です。
Entra ID > Authentication methods > Registration campaign
少なくともAuthentication Policy Administrator権限を持つ管理者でサインインし、Registration campaignの状態を確認します。管理画面では、Stateとして主に次の選択肢を確認します。(Microsoft Learn)
| State | 向いているケース | 注意点 |
|---|---|---|
| Microsoft managed | Microsoft推奨値に任せたい | 対象認証方法やスヌーズ設定を細かく制御できない |
| Enabled | 管理者が対象方法、スヌーズ、対象範囲を制御したい | 設計を誤ると全社に不要なプロンプトが出る |
| Disabled | 登録キャンペーンを使わない | 別の方法で認証方法の登録促進が必要 |
特に確認すべきなのは、Microsoft managedのままでよいかです。パスキーを有効化しているが登録キャンペーンではパスキーを促したくない場合、状態をEnabledに変更してMicrosoft Authenticatorを対象にするか、登録キャンペーン自体をDisabledにする選択肢があります。(Microsoft Learn)
パスキー展開前に確認すべき前提条件
パスキーを対象にした登録キャンペーンを実行するには、登録キャンペーンだけを有効にしても不十分です。認証方法ポリシー側で、Passkey（FIDO2）が利用できる状態になっている必要があります。
管理者は、少なくとも次の設定を確認してください。
| 確認項目 | 確認内容 |
|---|---|
| Microsoft Entra MFA | 組織でMicrosoft Entra多要素認証が有効か |
| Passkey（FIDO2） | Authentication methods policyで対象ユーザーに有効か |
| Allow self-service setup | パスキー（FIDO2）の構成でセルフサービスセットアップが許可されているか |
| AAGUID制限 | 特定のパスキーだけを許可していないか |
| 条件付きアクセス | Security info登録がブロックされていないか |
公式ドキュメントでは、登録キャンペーン自体にライセンス要件はない一方で、Microsoft Entra多要素認証が有効である必要があるとされています。また、パスキーキャンペーンではPasskey（FIDO2）認証方法とセルフサービスセットアップの有効化が前提です。(Microsoft Learn)
AAGUID制限があるとMicrosoft managedの挙動が変わる
パスキー（FIDO2）ポリシーで特定のAAGUIDを対象にしている場合、Microsoft managedモードでは対象認証方法がパスキーに更新されません。この場合でも、管理者が状態をEnabledに変更し、パスキー対象を手動で構成することは可能です。(Microsoft Learn)
AAGUID制限は、セキュリティキーやAuthenticator内パスキーなど、使わせたい認証器を絞るために有効です。ただし、既存のパスキー利用状況を把握せずにAAGUIDを削除すると、以前登録した方法でサインインできなくなる可能性があります。Microsoft Authenticatorのパスキーでは、Android用とiOS用のAAGUIDが公式に示されています。(Microsoft Learn)
Microsoft Authenticator展開前に確認すべき前提条件
Microsoft Authenticatorを対象にする場合は、単にアプリをインストールさせるだけではなく、プッシュ通知用に設定されているかが重要です。
確認すべき設定は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| Authenticatorアプリの対象ユーザー | Authentication methods policyで対象ユーザーが有効か |
| Authentication mode | AnyまたはPushになっているか |
| Passwordlessのみの設定 | Passwordlessのみの場合、ナッジ対象にならない |
| 既存登録状況 | すでにプッシュ通知用にAuthenticatorを設定済みのユーザーは対象外 |
| TOTPのみのユーザー | プッシュ通知が未設定ならナッジ対象になる |
Authenticatorキャンペーンでは、ユーザーがすでにMicrosoft Authenticatorをプッシュ通知用に設定している場合、基本的に登録を促されません。一方、TOTPコードだけを使っているユーザーは、プッシュ通知の設定を促されることがあります。(Microsoft Learn)
条件付きアクセスがナッジ表示を止めることがある
登録キャンペーンでよくある失敗は、「設定したのにユーザーにプロンプトが表示されない」というものです。この原因の多くは、登録キャンペーンではなく条件付きアクセス側にあります。
Microsoft Entra IDでは、ユーザーが認証方法を設定するよう促される前に、セキュリティ情報登録を制御する条件付きアクセス ポリシーが適用されます。たとえば、セキュリティ情報の更新を社内ネットワークからのみに制限している場合、ユーザーが社外からサインインしてもナッジは表示されません。(Microsoft Learn)
次の条件に該当すると、登録キャンペーンが想定どおり表示されないことがあります。
| 症状 | 主な原因 | 確認ポイント |
|---|---|---|
| 全くプロンプトが出ない | Microsoft Entra MFAを使っていない | 対象ユーザーがEntra MFAで認証しているか |
| 社外では出ない | Register security informationが条件付きアクセスで制限されている | セキュリティ情報登録のCAポリシー |
| アプリ内で出ない | SSOセッション中、または埋め込みビューの制約 | 新規サインインで検証する |
| モバイルで出ない | 登録キャンペーンはモバイルデバイスでは提供されない | PCブラウザーで検証する |
| 利用規約画面の後に出ない | Terms of Use表示中はナッジが表示されない | ToU適用条件を確認する |
| カスタム制御で出ない | 条件付きアクセスのカスタム制御でリダイレクトされる | CAカスタム制御の有無 |
「登録キャンペーンを有効にしたのに出ない」と判断する前に、対象ユーザーで実際にMFAが発生しているか、SSOで既にサインイン済みではないか、Security info登録ページがブロックされていないかを確認しましょう。(Microsoft Learn)
パスキーのナッジはアカウント単位ではなくデバイス・ブラウザー単位
パスキーキャンペーンで特に誤解されやすいのが、ナッジの判定単位です。パスキーのナッジは、ユーザーアカウント全体ではなく、現在使っているデバイスとブラウザーの組み合わせでローカルパスキーがあるかを評価します。(Microsoft Learn)
たとえば、あるユーザーがWindows Hello for Businessを登録済みで、Windows上のChromeからサインインする場合はナッジが抑制されます。しかし同じユーザーがMac上のChromeからサインインすると、そのWindows資格情報はMac環境に適用されないため、パスキー登録を促されることがあります。
代表的な考え方は次のとおりです。
| 利用環境 | ナッジが抑制されやすい代表例 |
|---|---|
| Windows | Windows Hello for Business、Microsoft Entra passkey on Windows、非プラットフォームプロバイダー |
| Mac | iCloudキーチェーン、Mac Platform SSO、非プラットフォームプロバイダー |
| iOS | iCloudキーチェーン、非プラットフォームプロバイダー |
| Android | Google Password Manager、Samsung Pass、非プラットフォームプロバイダー |
| Linux | ユーザーは促されない |
この仕様を理解していないと、「このユーザーは既にパスキーを持っているのになぜ再度促されるのか」という問い合わせにつながります。ヘルプデスク向けFAQには、端末やブラウザーが変わると表示される場合があると明記しておくとよいでしょう。
Graph ExplorerやAPIで確認・展開する場合
管理センターだけでなく、Graph ExplorerやMicrosoft Graph APIでも登録キャンペーンを確認・更新できます。必要な権限は、少なくともAuthentication Policy Administratorロールと、Graph ExplorerでのPolicy.Read.AllおよびPolicy.ReadWrite.AuthenticationMethodの同意です。(Microsoft Learn)
認証方法ポリシーの取得は次のエンドポイントで行います。
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy更新する場合は、registrationEnforcement配下のauthenticationMethodsRegistrationCampaignをPATCHします。
PATCH https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy全ユーザーを対象にパスキー登録を促す場合の考え方は、次のような構成です。
{
"registrationEnforcement": {
"authenticationMethodsRegistrationCampaign": {
"snoozeDurationInDays": 1,
"enforceRegistrationAfterAllowedSnoozes": true,
"state": "enabled",
"excludeTargets": [],
"includeTargets": [
{
"id": "all_users",
"targetType": "group",
"targetedAuthenticationMethod": "fido2"
}
]
}
}
}開発者や運用自動化担当者は、次の点に注意してください。
| 注意点 | 理由 |
|---|---|
| PATCH前に現在値を必ず取得する | 既存の除外グループやスヌーズ設定を誤って上書きしないため |
| 個別ユーザーよりグループで管理する | 認証方法ポリシーでは個別ユーザーターゲットよりグループ管理が推奨されるため |
| 対象グループを増やしすぎない | ポリシーサイズや登録失敗の原因になる可能性があるため |
| 変更内容を構成管理に残す | Microsoft managedからEnabledへ切り替えた理由を後から追跡するため |
Microsoftの認証方法ポリシーでは、多数のグループを含めると登録失敗や保存失敗につながることがあり、認証方法ごとにグループを集約することが推奨されています。ポリシーサイズが20KBを超えると保存できない場合がある点にも注意が必要です。(Microsoft Learn)
既存のMFA/SSPRポリシーからの移行も同時に確認する
登録キャンペーンだけを見ていると、実際の認証方法の登録可否を見誤ることがあります。Microsoft Entra IDでは、Authentication methods policyが現在の推奨管理場所です。一方で、従来のMFA設定やSSPR設定も過去に使われていたため、組織によっては複数ポリシーの影響が残っている場合があります。
Microsoftは、従来のMFAおよびSSPRポリシーでの認証方法管理を非推奨としており、2025年9月30日以降はこれらのレガシーポリシーで認証方法を管理できないと案内しています。認証方法ポリシーへ統合するための移行コントロールを使うことが推奨されています。(Microsoft Learn)
移行状態は、次の観点で確認します。
| 移行状態 | 意味 | 登録キャンペーン展開時の注意 |
|---|---|---|
| Pre-migration | Authentication methods policyは認証のみ、レガシー設定も尊重 | 旧設定の影響で想定外の方法が登録可能な場合がある |
| Migration in Progress | 認証とSSPRでAuthentication methods policyを使用、レガシー設定も尊重 | 移行中のため、対象ユーザーの実挙動をテストする |
| Migration Complete | Authentication methods policyに集約 | 登録キャンペーンの設計と整合しやすい |
展開前には、Authentication methods policy、Registration campaign、条件付きアクセス、SSPR設定を別々に見るのではなく、ユーザーが実際に登録できる認証方法は何かという観点で確認することが重要です。
パスキーとAuthenticator、どちらを対象にすべきか
どちらを対象にするかは、セキュリティレベルだけでなく、端末管理、ユーザー教育、サポート体制で判断します。
| 判断基準 | パスキーを優先 | Microsoft Authenticatorを優先 |
|---|---|---|
| 目的 | フィッシング耐性を高めたい | SMS・音声通話から移行したい |
| 端末環境 | Windows Hello、iCloudキーチェーン、Authenticator内パスキーなどを展開できる | スマートフォンでAuthenticatorアプリを使える |
| サポート体制 | 端末・ブラウザーごとの差異を説明できる | QRコード読み取りやプッシュ承認の案内が中心 |
| 強制力 | 登録キャンペーンに加え、条件付きアクセスの認証強度も検討 | MFA方法の標準化として始めやすい |
| 注意点 | AAGUID、Bluetooth、OSバージョン、ブラウザー差異が影響 | TOTPのみのユーザーにはプッシュ通知設定が別途必要 |
パスキーは強力ですが、登録キャンペーンはあくまで登録を促す機能です。機密性の高いリソースへのアクセス時にパスキーサインインを要求したい場合は、条件付きアクセスのAuthentication strengthsを組み合わせて設計します。Microsoftのパスキー関連ドキュメントでも、まずAuthentication methods policyでパスキー登録とサインインを許可し、その後に条件付きアクセスの認証強度で重要リソースへのパスキーサインインを適用する流れが示されています。(Microsoft Learn)
展開時のおすすめ手順
全社展開では、いきなり全ユーザーへ有効化するよりも、対象範囲を分けて進める方が安全です。
| フェーズ | 実施内容 | 成功基準 |
|---|---|---|
| 現状把握 | 認証方法アクティビティレポートで登録状況を確認 | SMS、音声、TOTP、Authenticator、パスキー利用者を把握 |
| 設計 | 対象認証方法、対象グループ、除外グループを決める | 管理者、役員、ゲスト、例外ユーザーの扱いが決まっている |
| パイロット | IT部門や一部部署でEnabled設定を試す | プロンプト表示、登録完了、スキップ挙動を確認できる |
| ユーザー周知 | 表示される画面、必要な端末、問い合わせ先を案内 | 「怪しい画面ではない」と理解してもらえる |
| 段階展開 | 部署・地域・端末種別ごとに対象を拡大 | ヘルプデスク負荷が許容範囲に収まる |
| 定着確認 | 登録率、サインイン失敗、問い合わせ内容を確認 | レガシー認証方法の削減計画へ進める |
ユーザー向け周知文の例
登録キャンペーンでは、ユーザーがサインイン中に突然「パスキーを設定してください」「Microsoft Authenticatorを設定してください」と表示されます。事前周知がないと、フィッシングと誤認されたり、逆に本物の画面であると無条件に信じてしまったりします。
社内向けには、次のように伝えると実務で使いやすくなります。
今後、Microsoft 365などへのサインイン時に、パスキーまたはMicrosoft Authenticatorの設定を求める画面が表示される場合があります。これは当社のサインインセキュリティ強化の一環です。画面の案内に従って設定してください。不明な場合は、画面を閉じる前に情報システム部へ連絡してください。
パスキーの場合は、端末やブラウザーによって表示が異なることも補足しておくと、問い合わせ削減につながります。
よくある失敗と対策
プロンプトが表示されない
まず、対象ユーザーがMicrosoft Entra MFAを実行しているかを確認します。登録キャンペーンのナッジは、Microsoft Entra多要素認証を使っているユーザーに対して動作します。SSOで既にサインイン済みの場合や、モバイルデバイスからの利用では表示されないことがあります。(Microsoft Learn)
次に、条件付きアクセスでSecurity info登録ページをブロックしていないかを確認します。特に「社内ネットワークからのみセキュリティ情報を更新可能」というポリシーがある場合、社外ユーザーにはナッジが出ません。
ユーザーが何度もスキップして登録しない
Microsoft managedでは、スヌーズ回数が無制限になる場合があります。登録率を上げたい場合は、状態をEnabledにして、Limited number of snoozesを有効にする設計を検討します。
ただし、強制に近い動きにすると、端末要件を満たさないユーザーや休職・出向・共有端末利用者が詰まる可能性があります。除外グループと一時アクセス手段を先に用意してから進めるのが安全です。
パスキー登録でエラーが出る
パスキー登録では、OSバージョン、ブラウザー、Bluetooth、インターネット接続、AAGUID制限、構成証明の設定が影響します。Authenticator内パスキーではAndroid 14以降またはiOS 17以降が要件として示されており、クロスデバイス登録・認証ではBluetoothとインターネット接続も確認が必要です。(Microsoft Learn)
また、構成証明を有効にしている場合、クロスデバイス登録では構成証明付きパスキーを登録できません。AppleやGoogleのサービス状態に依存する場面もあるため、障害時には再試行案内も必要です。(Microsoft Learn)
想定外のユーザーに表示される
includeTargetsとexcludeTargetsを確認します。登録キャンペーンでは、含めるグループと除外するグループの両方に所属しているユーザーは除外されます。例外対象者、ブレークグラスアカウント、検証未完了の端末利用者、ゲストユーザーなどは、必要に応じて除外グループで管理します。(Microsoft Learn)
開発者が確認すべきポイント
アプリ開発者がアプリ側の認証コードを大きく変更する場面は通常多くありません。ただし、Microsoft Entra IDを使ったサインイン体験に登録キャンペーンのナッジが挟まる可能性があるため、検証環境では次の点を確認しておきます。
| 確認項目 | 理由 |
|---|---|
| 埋め込みブラウザービューでの挙動 | 一部アプリ内ブラウザーでは登録キャンペーンがサポートされる |
| SSO済みセッションでの挙動 | 既にSSOでサインイン済みの場合、ナッジが発生しない |
| ToUやCAカスタム制御との組み合わせ | リダイレクトがある場合、ナッジが表示されないことがある |
| テストユーザーの認証方法 | 既に対象認証方法を登録済みだと表示されない |
| モバイルアプリの検証 | モバイルデバイスでは登録キャンペーンが提供されない |
特にQAでは、「プロンプトが出るケース」と「出ないケース」を分けてテストします。出ないことが正しい条件も多いため、単に表示有無だけで合否判定しないことが重要です。(Microsoft Learn)
今すぐ取るべき対応
Microsoft Entraの登録キャンペーンを安全に運用するには、まず現在の状態を確認し、Microsoft managedのままでよいかを判断します。
実務では、次の順番で確認すると抜け漏れを減らせます。
| 優先度 | 対応 |
|---|---|
| 高 | Registration campaignのStateがMicrosoft managed、Enabled、Disabledのどれか確認する |
| 高 | 対象認証方法がMicrosoft AuthenticatorかPasskeyか確認する |
| 高 | Passkey（FIDO2）とAuthenticatorのAuthentication methods policyを確認する |
| 高 | 条件付きアクセスでSecurity info登録がブロックされていないか確認する |
| 中 | AAGUID制限、構成証明、セルフサービスセットアップを確認する |
| 中 | 対象グループと除外グループを整理する |
| 中 | ユーザー向け周知文とヘルプデスクFAQを用意する |
| 低 | Graph APIで設定を取得し、変更履歴を構成管理に残す |
登録キャンペーンは、SMSや音声通話からの脱却、Microsoft Authenticatorの標準化、パスキー展開のきっかけとして有効です。ただし、設定を誤ると「表示されない」「想定外のユーザーに出る」「何度もスキップされる」といった問題が起きます。
まずは小さなパイロットグループで、対象認証方法、スヌーズ、条件付きアクセス、端末・ブラウザー差異を確認しましょう。そのうえで、Microsoft managedに任せるのか、Enabledで明示的に制御するのかを決めるのが、2026年時点のMicrosoft Entra登録キャンペーン運用で最も安全な進め方です。
コメント