Microsoft Entra の「Deploy passkeys with the Microsoft Entra Conditional Access Optimization Agent」は、管理者向けのパスキー導入を手作業で進めるのではなく、対象者の準備状況を分析し、通知・登録・条件付きアクセスによる適用までを段階的に支援する機能です。結論から言うと、すぐに全社へ強制する機能というより、特権管理者を中心に「フィッシング耐性のある認証」へ安全に移行するためのキャンペーン管理機能と考えると理解しやすいです。Microsoft 公式情報では、対象ユーザーやデバイス readiness の確認、猶予期間、Teams 通知、最終的な Conditional Access ポリシー適用までをエージェントが支援する仕組みとして説明されています。(Microsoft Learn)
この記事では、Microsoft Entra 管理者や ID セキュリティ担当者向けに、今回の「Deploy passkeys with the Microsoft Entra Conditional Access Optimization Agent」で何ができるのか、影響範囲、事前設定、移行期限の考え方、導入前に確認すべき注意点を実務目線で整理します。
Microsoft Entra のパスキー導入支援で何が変わるのか
従来、パスキーや FIDO2 セキュリティキーの展開では、管理者が対象ユーザーを選び、デバイス対応状況を確認し、登録手順を案内し、未登録者を追跡し、最後に Conditional Access で認証強度を要求する必要がありました。
今回の更新ポイントは、この一連の作業を Conditional Access Optimization Agent がキャンペーンとしてまとめて扱える点です。エージェントは、対象ユーザーとデバイスの準備状況を評価し、推奨される展開計画を生成し、ユーザーに必要な手順を案内し、準備が整った段階で Conditional Access ポリシーの適用へ進めます。(Microsoft Learn)
特に重要なのは、いきなり強制適用するのではなく、ユーザーを次のような状態に分類して進める設計になっていることです。
| 分類 | 意味 | 管理者が見るべきポイント |
|---|---|---|
| デバイス更新が必要なユーザー | Microsoft Entra に登録済みのデバイスがあるが、パスキー要件を満たしていない | OS 更新、端末管理、古い端末の扱い |
| パスキー登録が必要なユーザー | 対応デバイスはあるが、パスキー未登録 | 登録手順の案内、サポート窓口の準備 |
| 適用準備が整ったユーザー | 対応デバイスがあり、パスキー登録済み | Conditional Access による適用タイミング |
この分類により、管理者は「誰に何を依頼すべきか」を確認しやすくなります。全員に同じ案内を送るのではなく、端末更新が必要な人、登録だけで済む人、すでに適用可能な人を分けて対応できる点が実務上のメリットです。
対象はまず特権管理者。最大200ユーザーのキャンペーンを生成
公式情報では、エージェントはテナントを分析し、対象となる特権管理者を識別したうえで、最大 200 ユーザーを対象にしたキャンペーンを生成するとされています。対象には Global Administrator、Security Administrator、Privileged Role Administrator、Conditional Access Administrator、Exchange Administrator、SharePoint Administrator、Teams Administrator など、複数の管理者ロールが含まれます。(Microsoft Learn)
この仕様から考えると、最初の利用シーンは一般社員全体への一括展開ではなく、侵害時の影響が大きい管理者アカウントの保護強化です。
たとえば、次のような組織では優先度が高くなります。
- グローバル管理者や特権ロール管理者に SMS や音声通話 MFA が残っている
- 管理者アカウントのパスワードレス化を進めたいが、対象者の準備状況が見えない
- Conditional Access の認証強度を使いたいが、いきなり強制して業務停止するのが不安
- 海外拠点を含む管理者に対して、段階的にフィッシング耐性のある認証を展開したい
一方で、キャンペーン対象に自動抽出されたからといって、そのまま展開すべきとは限りません。特に break glass アカウントや緊急アクセス用アカウントは、通常のユーザーキャンペーンに含めない運用が推奨されています。(Microsoft Learn)
利用前に必要な前提条件
この機能を使うには、Microsoft Entra ID P1 以上、Security Compute Units、Authentication methods policy でのパスキー有効化、Security Administrator ロールが必要です。公式情報では、Conditional Access Administrator ロールだけではパスキーキャンペーン管理に十分な権限ではないとされています。(Microsoft Learn)
| 確認項目 | 必要な理由 | 見落としやすい点 |
|---|---|---|
| Microsoft Entra ID P1 以上 | Conditional Access Optimization Agent の利用前提 | パスキー自体の利用条件と混同しない |
| Security Compute Units | Security Copilot 系の処理で使用 | 実行ごとの消費量や上限管理が必要 |
| パスキーの有効化 | Authentication methods policy で対象者が登録できる状態にする | エージェントは対象者がパスキー有効化対象かを現在確認しない |
| Security Administrator ロール | キャンペーン管理に必要 | Conditional Access Administrator だけでは不足 |
| Teams 通知を受け取れる環境 | ユーザーへの案内に利用される | Teams 利用制限や通知ポリシーの影響を受ける可能性がある |
ここで注意したいのは、「パスキーの利用」と「エージェントによるキャンペーン展開」の前提が同じではない点です。Microsoft Entra ID のパスキー自体は FIDO2 ベースの認証方法として提供されますが、Conditional Access Optimization Agent を使った導入支援には Entra ID P1 や Security Compute Units など別の前提があります。Microsoft のパスキー設定手順では、FIDO2 パスキーのプロファイル、対象グループ、デバイスバウンドまたは同期パスキーなどの設定が説明されています。(Microsoft Learn)
キャンペーンは4段階で進む
パスキー導入キャンペーンは、次の4段階で構成されます。(Microsoft Learn)
| 段階 | 内容 | 管理者の判断ポイント |
|---|---|---|
| Target users for passkey campaign | 対象ユーザーを確認・調整する | 管理者ロール、除外対象、緊急アクセス用アカウントを確認 |
| Check device readiness | デバイスがパスキー要件を満たすか確認する | 古い OS、未使用端末、BYOD 端末の扱いを整理 |
| Require passkey registration | 対象者にパスキー登録を求める | 登録手順、問い合わせ対応、猶予期間を設計 |
| Enforce passkey usage | パスキー利用を条件付きアクセスで要求する | report-only で影響確認後、有効化を判断 |
実務では、最初の「対象ユーザー確認」が最も重要です。キャンペーン開始後は、ターゲット、猶予期間、延期設定などのキャンペーン設定を変更できません。開始前に対象者リストを確認し、除外すべきアカウントがないかをチェックする必要があります。(Microsoft Learn)
猶予期間と延期設定は、グローバル展開で特に重要
パスキー導入で失敗しやすいのは、技術設定そのものよりも、ユーザーに与える準備期間の設計です。公式情報では、デバイス更新、パスキー登録、適用前通知から強制適用までの期間に対して、管理者が grace period を調整できるとされています。猶予期間を過ぎても必要な作業を完了していないユーザーは、キャンペーン上で進行が止まり、Exceeded grace period 列で確認できます。(Microsoft Learn)
グローバル企業では、次のように猶予期間を長めに設計するほうが安全です。
| 状況 | 推奨される考え方 |
|---|---|
| 海外拠点を含む | タイムゾーン、休暇、現地サポート時間を考慮する |
| 管理者が少人数 | 業務停止リスクを避けるため、登録確認後に段階適用する |
| 端末更新が必要 | OS 更新や端末交換に時間がかかるため短すぎる猶予は避ける |
| サポート体制が限定的 | 登録開始直後に問い合わせが集中しないよう対象を絞る |
また、延期設定を有効にすると、ユーザーは必要な操作や適用前通知を一定期間延期できます。ただし、公式情報では延期設定のサポート対象が Security Copilot Owner または Security Copilot Contributor ロールを持つユーザーに限られるとされています。全ユーザーに同じ延期体験が提供されると誤解しないようにしてください。(Microsoft Learn)
未使用デバイスの扱いを決めておく
今回の機能では、古い端末や使われていない端末が「デバイス準備未完了」として残り続ける問題を避けるため、inactive devices のフィルターを設定できます。公式情報では、既定で過去1年以内に使用されたデバイスをアクティブとみなし、指定した期間内に使われていないデバイスを評価対象から除外できるとされています。(Microsoft Learn)
これは実務上かなり重要です。たとえば、退役済みのノート PC、検証用端末、古いモバイル端末が Microsoft Entra に残っていると、ユーザーがいつまでも「デバイス更新が必要」な状態に見える可能性があります。
導入前には、次の確認を行うと安全です。
- Microsoft Entra に古い登録デバイスが残っていないか
- Intune 管理対象外の端末をどう扱うか
- 休眠中の管理者アカウントや不要なロール割り当てがないか
- 端末棚卸しとパスキー展開の順序をどうするか
特に大規模テナントでは、パスキー導入の前にデバイス情報を整理しておくと、キャンペーンの精度が上がります。
Conditional Access ポリシーは最初から強制ではなく report-only で作成される
パスキー導入で管理者が最も気にするのは、「突然サインインできなくなるユーザーが出ないか」という点です。
公式情報では、ユーザーが適用対象になった場合、エージェントはフィッシング耐性のある認証を要求する Conditional Access ポリシーを作成します。ただし、このポリシーは少なくとも1人のユーザーが適用前通知の猶予期間を完了した後に作成され、初期状態は report-only です。管理者は影響を確認してから、実際に強制するか判断できます。(Microsoft Learn)
この挙動は重要です。キャンペーンを開始した瞬間に全対象者へ強制適用されるわけではありません。とはいえ、report-only で問題がなさそうだからといって、すぐ本番適用するのは避けるべきです。
本番適用前には、少なくとも次を確認してください。
| 確認項目 | 理由 |
|---|---|
| report-only の結果 | 想定外にブロックされるユーザーやアプリがないか確認する |
| 対象グループ | 管理者以外や緊急アクセス用アカウントが含まれていないか確認する |
| 認証強度 | 要求している認証方法が業務端末・モバイル環境で使えるか確認する |
| 例外設計 | 障害時、端末紛失時、海外出張時の代替手段を用意する |
| ロール管理 | 不要な特権ロールを先に削減する |
Conditional Access は、ユーザーやデバイスなどのシグナルをもとにアクセス制御を行う Microsoft Entra の Zero Trust ポリシーエンジンです。認証強度の要求や管理者向け MFA などに使われるため、パスキー展開でも既存ポリシーとの重複や競合を確認することが重要です。(Microsoft Learn)
ユーザー通知は Teams を前提に考える
キャンペーン実行中、エージェントは24時間ごとに進行状況を評価し、ユーザーの readiness に応じて次の段階へ進めます。デバイス更新が必要なユーザーやパスキー登録が必要なユーザーには、Microsoft Teams 通知とリマインダーが送られます。適用準備が整ったユーザーには、今後の強制適用に関する通知が行われます。(Microsoft Learn)
そのため、Teams 通知を単なる補助機能と考えず、展開計画の一部として扱うべきです。
グローバル展開では、英語だけでなく現地語の補足案内を社内ポータルや FAQ に用意しておくと、問い合わせを減らせます。特に「パスキーとは何か」「スマートフォンを使うのか」「セキュリティキーが必要か」「登録に失敗した場合どうするか」は、管理者以外にも分かる言葉で説明しておく必要があります。
移行期限は公式に固定日が示されているわけではない
今回の公式情報から読み取れる範囲では、Microsoft が全テナントに対して「この日までにパスキーへ移行する」といった固定の移行期限を示しているわけではありません。重要なのは、キャンペーン内で管理者が設定する猶予期間です。
つまり、移行期限は外部から一律に決まるものではなく、自社のキャンペーン設計によって決まります。
たとえば、管理者向けに次のような段階設計が考えられます。
| フェーズ | 目的 | 例 |
|---|---|---|
| 準備 | 対象者と端末を整理する | 特権ロール、緊急アカウント、古い端末を確認 |
| パイロット | 少人数で登録手順を検証する | Security Administrator など数名でテスト |
| 登録促進 | 対象管理者にパスキー登録を依頼する | Teams 通知、FAQ、サポート窓口を用意 |
| report-only 検証 | 強制適用前の影響を確認する | サインインログ、条件付きアクセス結果を確認 |
| 強制適用 | フィッシング耐性のある認証を要求する | 問題がない対象から有効化 |
移行期限を短くしすぎると、端末更新が間に合わない、海外拠点の管理者が登録できない、サポート窓口が逼迫するなどの問題が起きます。逆に長すぎると、特権アカウントが弱い認証方法のまま残ります。管理者アカウントから始め、成功パターンを作ってから範囲を広げるのが現実的です。
既知の制限と注意点
公式情報では、いくつかの制限も明記されています。特に注意すべきなのは、Conditional Access Optimization Agent が、対象ユーザーが Authentication methods policy でパスキーを有効化されているかを現在確認しない点です。キャンペーン開始前に、管理者側でパスキーの対象設定を確認する必要があります。(Microsoft Learn)
| 制限・注意点 | 実務上の影響 | 対応策 |
|---|---|---|
| 対象者のパスキー有効化状態をエージェントが確認しない | 通知しても登録できないユーザーが出る可能性 | Authentication methods policy の対象グループを事前確認 |
| キャンペーン開始後に設定変更できない | 対象者や猶予期間の修正が難しい | 開始前レビューを必須にする |
| CA ポリシーは条件を満たした後に作成される | 最初から Conditional Access 側に見えない場合がある | キャンペーン進行状況を確認する |
| ポリシー管理オプションは作成後に表示される | 設定前に詳細管理できない | report-only 作成後に必ず確認する |
| 延期設定の対象に制限がある | 全対象者に延期を提供できるとは限らない | ロールと利用者体験を確認する |
この制限を理解せずに展開すると、「エージェントが全部やってくれるはず」という誤解が生まれます。実際には、エージェントは導入を自動化・支援しますが、前提設定、対象者の妥当性、例外設計、最終的な強制判断は管理者の責任です。
管理者が導入前に確認すべきチェックリスト
パスキー導入キャンペーンを開始する前に、次の項目を確認しておくと失敗を減らせます。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Entra ID P1 以上を満たしているか |
| Security Copilot 容量 | Security Compute Units の利用状況や上限を確認したか |
| 権限 | Security Administrator ロールで管理できる体制か |
| パスキー設定 | Authentication methods policy で対象者にパスキーが有効か |
| 対象者 | 特権管理者、不要ロール、緊急アクセス用アカウントを確認したか |
| デバイス | OS 要件、未使用端末、Intune 管理状況を確認したか |
| 通知 | Teams 通知に加え、社内 FAQ や問い合わせ先を用意したか |
| 猶予期間 | 端末更新・登録・適用前通知の期間が現実的か |
| report-only 検証 | 強制適用前にサインイン影響を確認する運用があるか |
| 例外対応 | 端末紛失、海外出張、障害時の代替手段を決めたか |
特に、緊急アクセス用アカウントを通常キャンペーンに含めないこと、キャンペーン開始後に設定を変更できないこと、パスキー有効化対象を事前に確認することは必須です。
どのような組織から使うべきか
この機能は、すべての組織がいきなり全社展開に使うというより、まずは特権アカウントの認証強化に向いています。
優先度が高いのは、次のようなケースです。
- グローバル管理者やセキュリティ管理者にパスワード依存が残っている
- フィッシング耐性のある認証を要求したいが、移行状況を把握できていない
- FIDO2 セキュリティキーや Microsoft Authenticator のパスキーを段階導入したい
- Conditional Access の認証強度を本格活用したい
- 管理者への通知、登録状況確認、適用判断を手作業で回すのが難しい
一方で、端末管理が整っていない、Microsoft Teams 通知が使えない、Authentication methods policy の対象設計が曖昧な場合は、先に基盤整理を行うべきです。エージェントを使うことで導入作業は楽になりますが、設計不足まで自動的に解決されるわけではありません。
まとめ：パスキー導入は「自動化」より「安全な段階展開」として捉える
Microsoft Entra の「Deploy passkeys with the Microsoft Entra Conditional Access Optimization Agent」は、パスキーを安全に展開するための実務的な支援機能です。対象ユーザーの準備状況を分析し、デバイス更新、パスキー登録、Teams 通知、猶予期間、Conditional Access による適用までをキャンペーンとして管理できます。
ただし、重要なのは「すべてを自動で任せる」ことではありません。管理者は、ライセンス、SCU、権限、Authentication methods policy、対象ユーザー、緊急アクセス用アカウント、猶予期間、report-only の結果を確認したうえで、本番適用へ進める必要があります。
次に取るべき行動は明確です。まずは特権管理者の棚卸しを行い、パスキーを有効化する対象グループを確認し、少人数の管理者でキャンペーンを試験運用してください。その結果をもとに、猶予期間や通知文面、サポート手順を調整してから、より広い管理者ロールへ展開するのが安全です。
コメント