Microsoft Entra External ID への顧客ID基盤の移行で、最もユーザー体験を損ないやすいのが「全ユーザーにパスワードリセットを求める」設計です。2026年4月16日時点で注目したい更新は、Microsoft Entra External ID の Just-in-Time password migration（JITパスワード移行） が一般提供として扱われ、ユーザーの初回サインイン時に既存パスワードを検証しながら段階的に移行できるようになった点です。Microsoft の2026年3月更新では、External ID の新リリースとして JIT Password Migration が掲載されています。(TECHCOMMUNITY.MICROSOFT.COM)
結論から言うと、JITパスワード移行は「既存ユーザーに新しい認証基盤を意識させず、移行リスクを分散する」ための仕組みです。顧客IDアーキテクトや開発者にとっては、Azure AD B2C や独自CIAM、レガシIdPから Microsoft Entra External ID へ移行する際の摩擦を下げる現実的な選択肢になります。
Microsoft Entra External ID のJITパスワード移行とは
Microsoft Entra External ID は、コンシューマーやビジネス顧客向けアプリに、セルフサービス登録、パーソナライズされたサインイン、顧客アカウント管理などのCIAM機能を追加するための Microsoft Entra の外部ID基盤です。外部テナントでは、顧客アカウント、アプリ登録、ユーザーフロー、サインイン方法、カスタム認証拡張機能などを管理できます。(Microsoft Learn)
JITパスワード移行は、ユーザーが初めて Microsoft Entra External ID 経由でサインインしたタイミングで、レガシIdPに対してパスワードを検証し、成功したユーザーのパスワードを External ID 側に移す方式です。ユーザーから見ると、これまで使っていたメールアドレスやユーザー名、パスワードでログインするだけです。裏側では、External ID がカスタム認証拡張機能を呼び出し、レガシIdPで認証できたユーザーから順に移行済みとして扱います。(Microsoft Learn)
重要なのは、JITパスワード移行が「毎回レガシIdPでパスワード検証する仕組み」ではないことです。レガシIdPが使われるのは基本的に初回移行時です。移行後のサインインは Microsoft Entra External ID で直接認証されます。(Microsoft Learn)
なぜJITパスワード移行は移行プロジェクトの摩擦を減らすのか
顧客向けID基盤の刷新では、技術的な移行よりも「ユーザー行動を変えさせること」が大きなリスクになります。強制パスワードリセットを一斉に実施すると、ログイン離脱、問い合わせ増加、復旧フローの混雑、キャンペーン施策への悪影響が起こりやすくなります。
JITパスワード移行は、この摩擦を次のように下げます。
| 課題 | 従来起こりがちな問題 | JITパスワード移行での改善点 |
|---|---|---|
| パスワード移行 | 既存パスワードをエクスポートできず、全員にリセットを求める | 初回サインイン時にレガシIdPで検証し、成功したユーザーから移行 |
| ユーザー体験 | 新しい認証画面やパスワード変更で離脱が増える | ユーザーは既存資格情報でログインできる |
| カットオーバー | 一括切り替えの失敗時に影響範囲が大きい | アクティブユーザーから段階的に移行できる |
| 運用負荷 | ヘルプデスク、再送メール、リセット失敗対応が集中する | 移行対象をサインイン実績に沿って分散できる |
| 移行計画 | 「いつ全員を移せるか」が見えにくい | 移行済みフラグやログで進捗を追跡しやすい |
特にグローバルサービスでは、タイムゾーン、言語、メール到達率、地域ごとのサポート体制がばらつきます。JIT方式なら、すべてのユーザーに同じ日に行動を求める必要がありません。Customer identity modernization の文脈では、これは単なるUX改善ではなく、カットオーバーリスクを下げる設計パターンです。
JITパスワード移行の基本フロー
JITパスワード移行は「ユーザーを事前に作る」「初回サインイン時にレガシIdPで検証する」「成功したら External ID に移す」という順序で進みます。Microsoft の移行ガイドでも、JITを使う場合でもユーザーアカウントの一括移行は必要であり、External ID にユーザーが存在していることが前提とされています。(Microsoft Learn)
| ステップ | 実施内容 | 実務上の確認ポイント |
|---|---|---|
| 事前評価 | 既存CIAM、Azure AD B2C、独自IdPのサインイン方式を棚卸し | ローカルアカウント、ソーシャルログイン、MFA、カスタム属性を分けて整理 |
| ユーザー事前作成 | External ID 側にユーザーアカウントを作成 | メール、ユーザー名、外部ID、顧客IDなどの照合キーを決める |
| 移行フラグ設定 | 移行対象ユーザーに toBeMigrated: true のような拡張プロパティを設定 | 移行済みユーザーを判定できるようにする |
| カスタム認証拡張機能 | OnPasswordSubmit で顧客管理のHTTPSエンドポイントを呼び出す | 通常は Azure Functions などで検証ロジックを実装 |
| 初回サインイン | ユーザーが既存パスワードでサインイン | External ID が暗号化されたパスワード情報を拡張機能へ渡す |
| レガシ検証 | 関数がレガシIdPに資格情報を問い合わせる | 成功、失敗、ロック、弱いパスワードを明確に分岐 |
| 移行完了 | 成功時に External ID がパスワードを保存し、移行フラグを更新 | 以後のサインインは External ID で直接処理 |
| 残存対応 | 長期間サインインしないユーザーを別途処理 | 最終期限、強制リセット、アカウント無効化方針を決める |
この流れで特に重要なのは、JIT移行の開始時点でアプリケーションが External ID のエンドポイントへ移っている点です。ユーザーがサインインすると、External ID が OnPasswordSubmit カスタム認証拡張機能を使ってレガシIdPに対する検証を行い、移行後のサインインは External ID に対して直接行われます。(Microsoft Learn)
JIT方式が向いているケース、向かないケース
JITパスワード移行は便利ですが、すべての移行に最適とは限りません。判断基準は「既存パスワードを維持する必要があるか」「レガシIdPを安全に検証APIとして使えるか」「共存期間を管理できるか」です。
| 判断項目 | JIT方式が向いている | 別方式を検討したい |
|---|---|---|
| ユーザー体験 | パスワードリセットによる離脱を避けたい | セキュリティ方針として全員にパスワード更新を求めたい |
| 既存パスワード | 平文パスワードを取得できない、または取得したくない | 実行時または保存時に安全にパスワードを扱える |
| レガシIdP | ユーザー名とパスワードをAPIで検証できる | 検証APIがない、可用性が低い、レート制御が不十分 |
| アプリ移行 | アプリを External ID エンドポイントへ切り替えられる | しばらく旧IdPエンドポイントで認証を続ける必要がある |
| 運用体制 | 移行進捗、失敗率、残存ユーザーを監視できる | 共存状態を長期放置する可能性が高い |
| ユーザー構成 | ローカルアカウントの比率が高い | ソーシャルログイン、パスワードレス、OTP中心 |
たとえば、ECサイトや会員ポータルのように、パスワードリセットが売上や継続率に直結するサービスではJIT方式の効果が出やすくなります。一方、金融・公共・高リスク領域で「移行を機に全ユーザーへ再同意やパスワード更新を求める」設計が必要な場合は、JITだけにこだわるべきではありません。
実装で押さえるべき主要コンポーネント
JITパスワード移行の実装では、Microsoft Entra External ID だけで完結するわけではありません。レガシIdPとの接続、Azure Functions などの検証エンドポイント、証明書、Key Vault、アプリ登録、Microsoft Graph API の設定が関係します。
OnPasswordSubmit カスタム認証拡張機能
JIT移行の中心になるのが OnPasswordSubmit カスタム認証拡張機能です。Microsoft Graph のリソース説明では、これはサインイン中に顧客提供のAPIエンドポイントを呼び出し、レガシシステムに対してパスワードを検証するための拡張機能とされています。検証に成功すると、そのユーザーの資格情報が Microsoft Entra ID に保持され、ユーザー単位の移行が完了します。(Microsoft Learn)
開発者視点では、ここで作るべきものは「認証画面」ではなく「検証アダプター」です。External ID から渡される認証コンテキストを受け取り、レガシIdPに問い合わせ、結果を決められたアクションで返します。
Azure Functions などの顧客管理HTTPSエンドポイント
Microsoft のドキュメントでは、OnPasswordSubmit 用に設定するエンドポイントは、通常 Azure Functions として実装される顧客管理のHTTPSエンドポイントである必要があります。このURLは Microsoft Graph、Microsoft Entra サービスエンドポイント、レガシIdPの対話型サインインURLを指してはいけません。検証ロジックを実装した Function App の関数エンドポイントを指す必要があります。(Microsoft Learn)
実務では、次のように責務を分けると設計しやすくなります。
| コンポーネント | 役割 | 注意点 |
|---|---|---|
| Microsoft Entra External ID | サインインフロー、ユーザー管理、移行後の認証 | ユーザー事前作成と移行フラグが必要 |
| カスタム認証拡張機能 | パスワード送信時に外部ロジックを呼び出す | タイムアウト、再試行、エラー時動作を設計 |
| Azure Functions | レガシIdPへの検証処理を実装 | 平文パスワードをログ出力しない |
| Azure Key Vault | 復号用の秘密キーや証明書を保護 | マネージドID、RBAC、ローテーションを設計 |
| レガシIdP | 初回移行時の資格情報検証 | 可用性、レート制限、ロックアウト仕様を確認 |
| 監視基盤 | 成功率、失敗率、未移行ユーザーを可視化 | 移行完了判定と残存ユーザー対応に使う |
暗号化とKey Vault
External ID は、パスワードを平文で外部エンドポイントへ送るのではなく、公開キーを使ってパスワード情報を暗号化し、Azure Functions 側で秘密キーを使って復号します。Microsoft Learn では、公開キーを External ID のアプリ登録に設定し、秘密キーは Key Vault に残したまま Azure Function がマネージドIDでアクセスする構成が説明されています。(Microsoft Learn)
ここで避けるべき失敗は、検証処理のデバッグログにユーザーの入力パスワードを残すことです。移行プロジェクトでは一時的なログ強化を行いがちですが、パスワード、復号後ペイロード、認証ヘッダー、Key Vault から取得した秘密情報は出力対象から除外してください。
応答アクションを正しく設計する
カスタム認証拡張機能は、単に「成功」「失敗」を返すだけではありません。Microsoft のドキュメントでは、代表的な応答アクションとして MigratePassword、UpdatePassword、Retry、Block が示されています。(Microsoft Learn)
| 応答アクション | 使う場面 | ユーザー体験への影響 |
|---|---|---|
MigratePassword | レガシIdPで検証に成功し、移行できる | 認証が継続し、移行後はExternal IDで直接サインイン |
UpdatePassword | パスワードは正しいが、弱い、期限切れなどで更新が必要 | パスワードリセットまたは更新フローへ誘導 |
Retry | パスワードが誤っている | ユーザーに再入力を促す |
Block | アカウントロック、不正リスク、レガシ側でブロック対象 | サインインを止め、必要に応じてメッセージを表示 |
実装でありがちな失敗は、レガシIdPの全エラーを Retry に寄せてしまうことです。パスワード誤り、アカウントロック、MFA未完了、退会済み、本人確認待ち、システム障害は意味が違います。最低でも次の分類を用意してください。
- ユーザー入力ミス:
Retry - パスワードは正しいがポリシー未達:
UpdatePassword - アカウント状態により認証不可:
Block - 一時的なバックエンド障害: セキュリティ要件に応じてフェイルクローズを基本に検討
特にグローバルサービスでは、地域ごとにレガシIdPの応答仕様が異なることがあります。移行前にエラーコード一覧を収集し、External ID に返すアクションへマッピングしておくと、リリース後の問い合わせ分析が容易になります。
移行方式の比較：JIT、強制リセット、事前投入
JITパスワード移行を採用するかどうかは、他の移行方式と比較して決めるべきです。代表的には、強制パスワードリセット、事前パスワード投入、JIT移行の3つがあります。
| 方式 | 概要 | メリット | デメリット |
|---|---|---|---|
| 強制パスワードリセット | 移行後、ユーザーに新しいパスワードを設定させる | 実装が比較的単純。セキュリティポリシーを刷新しやすい | 離脱、問い合わせ、メール不達が増えやすい |
| 事前パスワード投入 | パスワードにアクセスできる場合にExternal IDへ事前設定 | 初回ログインがスムーズ | パスワードを扱える条件が限られ、セキュリティ・法務確認が重い |
| JITパスワード移行 | 初回サインイン時にレガシIdPで検証して移行 | ユーザーの行動変更が少なく、段階移行しやすい | レガシIdPとの共存、監視、残存ユーザー対応が必要 |
Microsoft Learn でも、レガシシステムで保存時または実行時にユーザーパスワードへアクセスできる場合は事前投入も可能とされています。一方でJIT方式は、既存パスワードをエクスポートできない、またはしたくない場面で特に有効です。(Microsoft Learn)
プロジェクト計画で見るべきKPI
JITパスワード移行は「入れたら終わり」の機能ではありません。むしろ、移行期間中の可視化が成否を分けます。顧客IDアーキテクトは、次のKPIを移行計画に組み込んでください。
| KPI | 目的 | 見るべきタイミング |
|---|---|---|
| 移行済みユーザー率 | 全体の進捗を把握 | 日次、週次 |
| 初回サインイン成功率 | JITフローの品質を確認 | リリース直後は時間単位 |
Retry 発生率 | 入力ミス、照合不整合、レガシ連携問題を検知 | キャンペーンや地域別に分析 |
UpdatePassword 発生率 | 外部IDのパスワード要件とのギャップを把握 | 本番前のパイロットで重点確認 |
Block 発生率 | ロック済み、退会済み、不正リスクを把握 | セキュリティチームと共有 |
| Azure Functions のレイテンシ | サインイン体験への影響を確認 | ピーク時間帯を重点監視 |
| レガシIdP APIエラー率 | 共存期間中の安定性を確認 | カットオーバー前後 |
| 未移行ユーザー数 | 最終対応対象を把握 | 移行終了期限に向けて管理 |
「30日でアクティブユーザーの大半を移行し、60日で残存ユーザーへ個別施策、90日でレガシIdP停止判断」のように、あらかじめ期間を区切ることが重要です。Microsoft の移行ガイドでも、JITでは Azure AD B2C と External ID の共存期間が発生し、サインインしないユーザーは移行されないため、強制リセットや最終バルク移行、明確なカットオーバー期限を計画すべきだとされています。(Microsoft Learn)
セキュリティ設計で失敗しやすいポイント
JITパスワード移行は、パスワードを扱う移行処理です。ユーザー体験を優先するあまり、検証APIやログ、権限管理が甘くなると、移行期間そのものが攻撃面になります。
レガシIdPへのブルートフォース対策を忘れない
JIT移行中は、External ID から呼び出される検証エンドポイントがレガシIdPへの入口になります。攻撃者が大量のパスワード試行を行える構造にしないよう、IP、ユーザー、アプリ、地域などの単位で試行回数を制御してください。Microsoft の移行ドキュメントでも、REST API をブルートフォース攻撃から保護し、サインイン試行が一定のしきい値を超えたらリクエスト処理を止めることが推奨されています。(Microsoft Learn)
共存期間を長引かせない
JIT方式は段階移行に向いていますが、永続的な二重運用には向きません。共存期間が長くなるほど、プロファイル更新、パスワード変更、新規登録、退会処理、同意状態の同期が難しくなります。
実務では、次のように共存期間のルールを決めておきます。
| 項目 | 決める内容 |
|---|---|
| 新規登録 | External ID 側に一本化する日 |
| パスワード変更 | 旧IdPとExternal IDのどちらを正とするか |
| プロファイル更新 | メールアドレス、電話番号、同意情報の同期方法 |
| 退会・停止 | 両システムで無効化漏れが起きない設計 |
| 期限 | レガシIdPの停止判断日、残存ユーザー対応日 |
弱いパスワードの扱いを事前にテストする
レガシIdPでは有効だったパスワードが、External ID のパスワード複雑性要件を満たさない場合があります。Microsoft Learn では、Native Auth フローで、レガシIdP上は正しいが External ID の複雑性基準では弱いパスワードの場合、SSPRへリダイレクトされずエラーが返る既知の問題が説明されています。(Microsoft Learn)
この問題を本番で初めて見つけると、ユーザーには「正しいパスワードなのにログインできない」ように見えます。パイロット段階で、古いパスワードポリシーのサンプルを使い、UpdatePassword への誘導やメッセージ設計を確認してください。
開発者向けの実装チェックリスト
JITパスワード移行を実装する開発者は、機能を作る前に「本当に安全にレガシ検証できるか」を確認する必要があります。
| チェック項目 | 確認内容 |
|---|---|
| ユーザー照合キー | メール、UPN、顧客番号、旧IdPのユーザーIDのどれで照合するか |
| レガシ検証API | パスワード検証のAPIがあり、応答コードが安定しているか |
| エラー分類 | 誤パスワード、ロック、退会、期限切れ、障害を区別できるか |
| HTTPSエンドポイント | Function App など顧客管理の安全なエンドポイントになっているか |
| Key Vault | 秘密キー、証明書、アクセス権限、ローテーションを管理できるか |
| ログ | パスワード、トークン、復号済みペイロードを記録しない設計か |
| レート制御 | ユーザー単位、IP単位、アプリ単位で試行制限できるか |
| 監視 | 成功、失敗、レイテンシ、例外を相関ID付きで追えるか |
| リリース戦略 | 小規模コホート、地域、アプリ単位で段階展開できるか |
| ロールバック | External ID側、アプリ側、レガシIdP側で戻し方を決めているか |
アプリ登録まわりでは、カスタム認証拡張機能用のアプリケーションを作成し、External ID と Azure Functions 間の呼び出しを認証できるようにします。また、認証イベントからHTTPリクエストを受け取るために CustomAuthenticationExtension.Receive.Payload アプリケーション権限が必要です。(Microsoft Learn)
アーキテクト向けの判断基準
顧客IDアーキテクトは、JITパスワード移行を「機能」ではなく「移行リスクを分散するための設計」として評価する必要があります。次の問いに答えられるなら、採用判断がしやすくなります。
- パスワードリセットを強制した場合、ログイン離脱と問い合わせはどの程度増えるか
- アクティブユーザーの何％が30日、60日、90日以内にサインインするか
- サインインしないユーザーをいつ、どの方法で移行完了扱いにするか
- レガシIdPを何日間、安全に検証基盤として維持できるか
- プロファイル更新や退会処理の二重管理をどう防ぐか
- 移行失敗時にビジネス側へ説明できるKPIを持っているか
- グローバル展開時に地域別の認証要件、法務要件、サポート体制を反映できるか
特に大規模サービスでは、全ユーザーを同じ方式で扱う必要はありません。アクティブユーザーはJIT、長期休眠ユーザーは期限後に強制リセット、高リスクユーザーは追加確認というように、ユーザーセグメントごとに移行パスを分けると現実的です。
Azure AD B2C移行との関係
Azure AD B2C から Microsoft Entra External ID への移行を検討している組織にとって、JITパスワード移行は重要な選択肢です。Microsoft Learn では、2025年5月1日以降、Azure AD B2C は新規顧客向けに購入できなくなり、Microsoft Entra External ID が次世代CIAMソリューションとして説明されています。(Microsoft Learn)
既存の Azure AD B2C 利用企業では、カスタムポリシー、REST API連携、ユーザーフロー、ソーシャルIdP、カスタム属性、トークンクレームなどを棚卸ししたうえで、External ID での代替実装を検討する必要があります。JITパスワード移行は、その中でも「ローカルアカウントのパスワードをどう扱うか」という最もユーザー影響が大きい論点に対する解決策です。
ただし、B2Cの全機能がExternal IDにそのまま移せるわけではありません。移行計画では、認証フロー、MFA、ソーシャルフェデレーション、カスタムビジネスロジック、トークン仕様を個別に検証してください。
JITパスワード移行を成功させる進め方
JITパスワード移行を採用するなら、いきなり本番全体へ適用するのではなく、次の順序で進めるのが安全です。
| フェーズ | やること | 成功条件 |
|---|---|---|
| 調査 | 既存IdP、ユーザー属性、ログイン頻度、パスワードポリシーを棚卸し | 移行対象と除外対象が明確 |
| PoC | Azure Functions、Key Vault、OnPasswordSubmit連携を検証 | 主要な応答アクションを再現できる |
| パイロット | 社内ユーザー、テスト顧客、一部地域で試す | 初回ログイン成功率と失敗理由を説明できる |
| 段階展開 | アプリ、地域、ユーザーセグメント単位で拡大 | ヘルプデスク負荷が許容範囲 |
| 残存対応 | 未サインインユーザーへ通知、リセット、無効化を実施 | レガシIdP停止対象が確定 |
| カットオーバー | External ID を主系として運用 | レガシ検証経路を閉じられる |
最後に確認すべきことはシンプルです。既存ユーザーにパスワードリセットを強いることが事業上のリスクなら、JITパスワード移行は検討価値があります。ただし、成功にはユーザー事前移行、レガシIdPの安全な検証API、監視、期限付きの共存計画が欠かせません。
まずは既存ユーザーのサインイン頻度、ローカルアカウント比率、パスワードポリシー差分、レガシIdPの検証API可用性を棚卸ししてください。そのうえで、少数ユーザーのPoCから MigratePassword、UpdatePassword、Retry、Block の動作を確認すれば、Microsoft Entra External ID への顧客IDモダナイゼーションを、ユーザー体験を壊さずに進めやすくなります。
コメント