Entra ID SSPR導入ガイド（2026年版）

はじめに：なぜSSPRがヘルプデスクに不可欠なのか

「またパスワードリセットか…」——IT ヘルプデスクで働いたことがある方なら、この溜め息に共感いただけるのではないでしょうか。実際、パスワードリセットの問い合わせは IT サポートコール全体の約20%を占めるといわれています。正直なところ、これはかなりの負担です。

社員がパスワードを忘れるたびに業務が止まり、ヘルプデスクに電話やチケットが殺到する。IT 担当者はもっと戦略的な仕事に集中したいのに、毎日同じリセット作業の繰り返し。この悪循環、どうにかしたいですよね。

そこで登場するのが、Microsoft Entra ID のセルフサービスパスワードリセット（SSPR）です。ユーザー自身が管理者やヘルプデスクの手を借りずにパスワードを変更・リセットできるようになります。本ガイドでは、2026年の最新仕様に基づいた SSPR の導入から運用監視まで、実践的に解説していきます。

SSPRの前提条件とライセンス要件

まずは導入前に確認しておくべきことから。SSPR はライセンスや環境によって利用できる範囲が変わるので、ここをスキップするとあとで困ります。

必要なライセンス

クラウドのみの環境：Microsoft 365 Business、Education、または非営利の有料プランで無料利用可能
ハイブリッド環境（パスワードライトバック）：Microsoft Entra ID P1 以上が必要
Microsoft Entra ID P2：リスクベースの条件付きアクセスとの連携が可能

クラウドオンリーの環境なら追加費用なしで始められるのは嬉しいポイントです。ハイブリッド環境の場合は P1 ライセンスが必要になるので、事前に確認しておきましょう。

必要なロールと権限

SSPR の有効化：認証ポリシー管理者以上
パスワードライトバックの構成：ハイブリッド ID 管理者
条件付きアクセスポリシーの作成：条件付きアクセス管理者

ハイブリッド環境の追加要件

オンプレミス Active Directory と連携する場合は、以下も必要になります。

Microsoft Entra Connect または Microsoft Entra Connect Cloud Sync が構成済み
パスワードハッシュ同期が有効
パスワードライトバック用のファイアウォール設定（送信方向のポート443のみ）

ファイアウォールは送信方向だけでOKなので、受信規則を開ける必要がないのはセキュリティ的にも安心ですね。

SSPR の有効化：ステップバイステップ

では、実際の設定手順に入りましょう。

ステップ1：Microsoft Entra 管理センターでSSPRを有効化

Microsoft Entra 管理センターにサインイン
左メニューから「保護」→「パスワードリセット」をクリック
「セルフサービスパスワードリセットが有効」の設定を選択
- 「なし」：SSPR 無効
- 「選択済み」：特定のグループのみ有効（パイロット展開におすすめ）
- 「すべて」：テナント全体で有効
「保存」をクリック

個人的なおすすめ：いきなり全社展開はリスクが高いです。まず IT 部門や特定の部署をパイロットグループに設定して「選択済み」で動かしてみてください。問題がないことを確認してから全社展開に移行する、というステップが安全です。

ステップ2：認証方法の構成

ユーザーがパスワードをリセットする際に使う認証方法を設定します。ここが SSPR のセキュリティを左右する大事な部分です。

「パスワードリセット」→「認証方法」に移動
「リセットに必要な方法の数」を選択（セキュリティのため「2」を推奨）
利用可能な認証方法を選択：
- Microsoft Authenticator アプリの通知（一番おすすめ）
- Microsoft Authenticator アプリのコード
- メール
- 携帯電話（SMS）
- 会社電話
- セキュリティの質問（管理者アカウントでは使用不可なので注意）

重要：管理者アカウントには自動的に「2ゲートパスワードリセットポリシー」が適用されます。常に2つの認証方法が必要で、セキュリティの質問は使えません。これは変更できない仕様なので、管理者は必ず2つ以上の認証方法を登録しておいてください。

ステップ3：登録の設定

「パスワードリセット」→「登録」に移動
「サインイン時にユーザーに登録を要求する」を「はい」に設定
「ユーザーが認証情報を再確認するまでの日数」を設定（180日が推奨）

「サインイン時に登録を要求」は必ずオンにしましょう。これをオフにすると、いざパスワードを忘れたときに「認証方法を登録してなかった…」というユーザーが続出します（経験談です）。

【2026年必須】認証方法ポリシーへの移行

ここは特に重要なセクションです。2025年9月30日をもって、レガシ MFA および SSPR ポリシーでの認証方法管理は廃止されました。つまり2026年現在、新しい統合認証方法ポリシーの使用が必須です。

まだ移行していない場合は、最優先で対応してください。

移行が必要な理由

レガシポリシーだと認証方法がテナント全体に一律適用され、グループ単位での細かい制御ができない
SMS やボイスコールなど安全性の低い方法がすべてのユーザーに強制されてしまう
移行しないと、ユーザーが承認された認証方法を持たなくなりテナント全体のロックアウトが発生するリスクがある

最後の項目が一番怖いですね。テナント全体のロックアウトなんて、想像するだけで冷や汗ものです。

移行手順

Microsoft Entra 管理センターで「認証方法」→「ポリシー」に移動
移行ウィザードを使って、現在のレガシ MFA/SSPR 設定を自動チェック
各認証方法を新しいポリシーで有効化し、対象グループを設定
移行完了後、レガシポリシーの認証方法を無効化

注意点：セキュリティの質問は、認証方法ポリシーではまだ管理できません。引き続きレガシ SSPR 設定で管理する必要があります。ちょっと不便ですが、現時点ではこの制約を受け入れるしかなさそうです。

移行状況の確認（PowerShell）

# Microsoft Graph PowerShell モジュールに接続
Connect-MgGraph -Scopes "Policy.Read.All"

# 認証方法ポリシーの移行状態を確認
$policy = Get-MgPolicyAuthenticationMethodPolicy
$policy.PolicyMigrationState

# 結果の解釈：
# "preMigration" = 移行前（レガシポリシーのみ使用中）
# "migrationInProgress" = 移行中（両方のポリシーが有効）
# "migrationComplete" = 移行完了（新しいポリシーのみ使用中）

まずはこのコマンドで自社の移行状態を確認してみてください。"migrationComplete" が表示されれば安心です。

ハイブリッド環境：パスワードライトバックの構成

オンプレミス AD と Microsoft Entra ID を同期しているハイブリッド環境では、クラウドでリセットされたパスワードをオンプレミスに書き戻すパスワードライトバックが欠かせません。これがないと、クラウドでパスワードを変更してもオンプレミス側は古いまま…という混乱が起きてしまいます。

Microsoft Entra Connect での設定

Microsoft Entra Connect サーバーで構成ウィザードを起動
「オプション機能」で「パスワードライトバック」にチェック
ウィザードを完了して設定を適用

手順自体はシンプルですね。

Microsoft Entra Connect Cloud Sync での設定

Cloud Sync を使っている場合は、PowerShell から有効化できます。

# Cloud Sync サーバーでパスワードライトバックを有効化
Set-AADCloudSyncPasswordWritebackConfiguration -Enable $true

# 必要な権限の設定（エンタープライズ管理者で実行）
Set-AADCloudSyncPermissions -PermissionType PasswordReset

Microsoft Entra 管理センターでの有効化

「パスワードリセット」→「オンプレミスの統合」に移動
「同期されたユーザーのパスワードの書き戻しを有効にする」にチェック
必要に応じて「パスワードをリセットせずにアカウントのロック解除をユーザーに許可する」にチェック
「保存」をクリック

3番目のロック解除オプションは、パスワードは覚えているけどアカウントがロックされた…というケースに便利です。ヘルプデスクへの問い合わせをさらに減らせるので、有効にしておくことをおすすめします。

ライトバック設定時の注意点

ファイアウォールの受信規則は不要（Azure Service Bus リレーを使用し、送信ポート443のみ）
オンプレミスのパスワードポリシーで最小パスワード年齢を0に設定するのがベスト
AD DS アカウントの継承が無効になっていると、特定のユーザーでライトバックが失敗することがある
権限の反映には最大1時間以上かかる場合がある（焦らず待ちましょう）

PowerShellによるSSPR運用監視

SSPR を展開したら終わり…ではありません。登録状況と利用状況を定期的にモニタリングして、ちゃんと使われているか、問題が起きていないかをチェックすることが大切です。

SSPR 登録状況レポートの取得

# Microsoft Graph PowerShell に接続
Connect-MgGraph -Scopes "AuditLog.Read.All", "UserAuthenticationMethod.Read.All"

# 全ユーザーの SSPR 登録状態を取得
$report = Get-MgBetaReportAuthenticationMethodUserRegistrationDetail -All

# SSPR 未登録ユーザーの一覧を出力
$unregistered = $report | Where-Object { $_.IsSsprRegistered -eq $false -and $_.IsSsprEnabled -eq $true }
$unregistered | Select-Object UserPrincipalName, UserDisplayName, DefaultMfaMethod |
  Export-Csv -Path "SSPR_Unregistered_Users.csv" -NoTypeInformation -Encoding UTF8

Write-Host "SSPR有効だが未登録のユーザー数: $($unregistered.Count)"

未登録ユーザーがいたら、個別に声をかけるか登録を促すメールを送りましょう。登録率が低いままだと、SSPR を導入した意味が薄れてしまいます。

SSPR アクティビティログの監視

# 過去30日間の SSPR イベントを取得
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
$filter = "activityDateTime ge $startDate and category eq 'UserManagement' and activityDisplayName eq 'Self-service password reset flow activity progress'"

$events = Get-MgAuditLogDirectoryAudit -Filter $filter -All

# 成功・失敗の集計
$summary = $events | Group-Object -Property Result
$summary | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count) 件"
}

# 失敗イベントの詳細を CSV に出力
$events | Where-Object { $_.Result -eq "failure" } |
  Select-Object ActivityDateTime, InitiatedBy, TargetResources, ResultReason |
  Export-Csv -Path "SSPR_Failed_Events.csv" -NoTypeInformation -Encoding UTF8

失敗イベントが急増している場合は、認証方法の設定や条件付きアクセスポリシーに問題がある可能性があります。早めに原因を調査しましょう。

Azure Automation で自動化する

毎回手動でスクリプトを実行するのは正直面倒ですよね。Azure Automation Runbook を使えば、週次や月次で SSPR の利用状況レポートを自動生成し、ヘルプデスクマネージャーにメール送信するワークフローを組めます。一度セットアップしてしまえばあとは放っておけるので、ぜひ検討してみてください。

条件付きアクセスとSSPRの連携

SSPR を導入しただけで満足せず、条件付きアクセスと組み合わせるとセキュリティと利便性のバランスをさらに高められます。

推奨される条件付きアクセスポリシー

MFA 登録ポリシー：信頼済みの場所またはデバイスからのみ MFA 登録を許可
SSPR 利用時の追加検証：リスクの高いサインインが検出された場合は追加の認証を要求
パスワードレス認証への段階的移行：FIDO2 キーや Microsoft Authenticator のパスワードレスサインインを推進

最終的にはパスワードレスに移行するのが理想です。SSPR はあくまで過渡期のソリューションと考え、並行してパスワードレス認証の導入も進めていくのが良いでしょう。

2026年3月の重要な変更

今まさにタイムリーな話ですが、2026年3月に条件付きアクセスの「承認済みクライアントアプリ」許可が廃止されます。該当するポリシーをお使いの場合は、「アプリ保護ポリシーを要求する」への移行が必要です。

また、以前は除外されていた低い特権スコープにも条件付きアクセスが適用されるようになります。一部のユーザーに新しい認証チャレンジが発生する可能性があるので、事前にテストしておくことをおすすめします。

SSPR トラブルシューティング：よくある問題と解決策

SSPR の導入・運用で遭遇しがちなトラブルをまとめました。問題が起きたときに焦らないよう、事前に目を通しておくと安心です。

問題1：「この機能は使用できません」と表示される

原因：SSPR が有効なグループにユーザーが含まれていないケースがほとんどです。

解決策：Microsoft Entra 管理センターで SSPR の対象グループにユーザーを追加するか、「すべて」に設定を変更しましょう。意外とこの単純な見落としが多いんです。

問題2：パスワードライトバックが失敗する

原因：ファイアウォール設定、Entra Connect の接続問題、または AD DS アカウントの権限不足など、複数の要因が考えられます。

解決策：

Entra Connect サーバーから Azure Service Bus（*.servicebus.windows.net:443）への送信接続を確認
Entra Connect 構成ウィザードでパスワードライトバックを一度無効にし、再度有効化してみる
対象ユーザーの AD アカウントで権限の継承が有効であることを確認

2番目の「無効にして再有効化」は地味ですが、けっこう効きます。

問題3：MFA 登録のプロンプトが頻繁に表示される

原因：条件付きアクセスのサインイン頻度設定が短すぎることが多いです。

解決策：条件付きアクセスポリシーでサインイン頻度の期間を延長し、ブラウザーセッションを永続に設定しましょう。ユーザーから「何度もログインを求められる」というクレームが来たら、まずここを疑ってください。

問題4：認証方法ポリシー移行後にサインインできない

原因：レガシポリシーで有効だった認証方法が、新しいポリシーで有効化されていない。

解決策：Microsoft Entra 管理センターの「認証方法」→「ポリシー」で、必要な認証方法がすべて有効化されているか確認してください。移行は段階的に行い、完全に確認できるまでレガシポリシーを無効化しないのが鉄則です。

SSPR 展開チェックリスト

最後に、導入の漏れがないかこのチェックリストで確認しましょう。

☐ ライセンス要件の確認（クラウドのみ or ハイブリッド）
☐ パイロットグループの選定と SSPR の有効化
☐ 認証方法の構成（2つの方法を推奨）
☐ 認証方法ポリシーへの移行完了
☐ パスワードライトバックの構成（ハイブリッド環境のみ）
☐ Microsoft Entra Password Protection の展開
☐ 条件付きアクセスポリシーの構成
☐ ユーザーへの登録案内と教育
☐ PowerShell 監視スクリプトの設定
☐ 全社展開とモニタリング開始

特に「ユーザーへの登録案内と教育」は見落としがちですが、ここを怠ると登録率が上がらず、結局ヘルプデスクの負担が減らないという本末転倒な結果になりかねません。周知メールやトレーニングセッションなど、しっかり計画に組み込んでおきましょう。

よくある質問（FAQ）

Q1：SSPRを導入すると、ヘルプデスクのパスワードリセット対応はどのくらい減りますか？

パスワードリセット関連の問い合わせは IT サポートコール全体の約20%を占めるといわれています。SSPR の導入とユーザー登録率の向上により、多くの組織で50〜80%の削減効果が報告されています。もちろん組織の規模やユーザーの IT リテラシーにもよりますが、かなりのインパクトが期待できます。

Q2：SSPRの利用にはどのライセンスが必要ですか？

クラウドのみの環境なら Microsoft 365 Business 以上の有料プランで追加費用なしで使えます。オンプレミス AD へのパスワードライトバックが必要な場合は、Microsoft Entra ID P1 以上のライセンスが必要です。

Q3：オンプレミスの Active Directory 環境でもSSPRは使えますか？

はい、使えます。パスワードライトバックを構成すれば、クラウドでリセットされたパスワードがオンプレミスの AD にリアルタイムで書き戻されます。Microsoft Entra Connect または Entra Connect Cloud Sync が必要です。

Q4：認証方法ポリシーの移行は必須ですか？

はい、必須です。2025年9月30日にレガシポリシーは廃止されました。まだ移行が完了していない場合は、Microsoft Entra 管理センターの移行ウィザードを使って早急に対応してください。放置するとテナント全体でサインインに問題が発生するリスクがあります。

Q5：管理者アカウントのパスワードリセットポリシーは一般ユーザーと異なりますか？

はい、異なります。管理者には自動的に「2ゲートパスワードリセットポリシー」が適用され、2つの認証方法が必須です。セキュリティの質問は使えません。このポリシーは変更不可なので、管理者は必ず2つ以上の認証方法を登録しておく必要があります。