Password Reset：ログインできない人を、ログインさせずに助ける
パスワードを忘れた人は、ログインできません。当たり前の話ですが、これがサービスデスクにとっては厄介な前提になります。普通の申請フォームは、ログインしないと開けないからです。
ServiceNow の Password Reset は、この矛盾を「ログイン前でも入れる専用の入口」で解きます。そして入口を開けたぶんだけ、本人確認を厳しくする。今回は、その入口と確認の仕組みが実機にどう組まれているかを読みます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
全体の流れは4段
まず道筋を見ておきます。
公開URLで入り、誰なのかを特定し、本人であることを確かめ、保管先のパスワードを書き換える。この4段が Password Reset の骨格です。それぞれに専用のテーブルが用意されています。
処理の定義：pwd_process
pwd_process は「リセット処理1式」を表すテーブルです。実測 5件 ありました。
そのうち有効（active=true）なのは Default Self Service の1件だけです。残る4件は無効でした。Service-Desk 向け、Employee Self-Service 向け、そしてデモ用が2件。
用途ごとに処理を分けられる作りになっています。利用者が自分でやる場合と、サービスデスクが代行する場合では、必要な確認の厳しさが違うからです。
有効な処理を1件開く
Default Self Service を開きます。
上部に赤い警告が出ていました。
This is a High Risk file that might get updated again in later releases.
標準レコードなので、書き換えるとアップグレードで衝突しうる、という注意です。
その下には青い案内もありました。
All the fields related to Password Expiration are hidden. Because the 'Local ServiceNow Instance' doesn't support the listed features.
保管先が ServiceNow 自身のときは、パスワード有効期限まわりの項目が隠れる、という説明です。
保管先しだいで使える機能が変わり、画面の項目まで変わる。この連動が最初の見どころです。
設定値を並べる
Credential store は Local ServiceNow Instance。Identification type は Username Identification。Minimum verifications は 1。Public access はオンで、Public URL は /$pwd_reset.do?sysparm_url=ss_default でした。
url_suffix に ss_default と入っており、それが公開URLの末尾になります。処理ごとに別々の入口URLを持てる仕組みです。サービスデスク用の処理を作れば、そちらには別のURLが割り当てられます。
Display captcha はオン。ログイン不要の入口なので、機械的な総当たりを防ぐ必要があります。Apply to all users もオンで、この処理が全ユーザーに効きます。
Security score という指標
フォームには Process Strength Configuration というセクションがあり、Security score が 82 と表示されていました。緑色のバーで示されます。
この数字は「今の設定がどれくらい堅いか」の目安です。確認の必要数を増やしたり、強い確認方法を選んだりすると上がる仕組みと読めます。算出の中身までは未確認ですが、設定を変えたときに堅さの変化を数字で見られるのは分かりやすい作りです。
Enable security score notification という項目もあり、実測ではオフでした。スコアが下がったときに知らせる仕組みだと読めます。
変更・リセット・ロック解除は別々の機能
フォームには Password change と Password reset のチェックが並んでいました。実測ではどちらもオンです。
変更（change）は「今のパスワードを知っている人が、新しいものに変える」動き。リセット（reset）は「今のパスワードが分からない人に、入れ直させる」動きです。求められる本人確認の厳しさが違うので、別のチェックになっています。
unlock_account という項目もあり、こちらはオフでした。パスワードは合っているが、失敗を重ねてロックされた状態を解除する機能です。扱うかどうかを処理ごとに決められます。
auto_gen_password と display_password もオフでした。システムが自動生成したパスワードを画面に出す運用は取らず、本人に決めさせる設定です。生成したパスワードを画面表示すると、肩越しに見られる危険があります。
チャットボットからも使える
enabled_on_chatbot はオンでした。Virtual Agent の会話からパスワードリセットに入れる、という設定です。
パスワードを忘れた人が最初に触るのは、多くの場合チャットの窓口です。そこから直接リセットへ進めるなら、電話や問い合わせ票を作らずに済みます。公開URLとチャットの両方を入口にしておけば、利用者はどちらからでも辿り着けます。
本人の特定：2つの方法
pwd_identification_type は 2件 でした。
Email Identification … メールアドレスで特定する
Username Identification … ユーザー名で特定する
Default Self Service はユーザー名を使う設定です。ここで入力された値をもとに、対象のユーザーレコードを1件に絞ります。
特定はまだ本人確認ではありません。「あなたが誰を名乗っているか」を聞いた段階です。名乗るだけなら誰でもできるので、次の段階が要ります。
本人確認：種類と部品の2階層
ここが Password Reset の設計で最も面白い部分です。本人確認が2つのテーブルに分かれています。
種類（pwd_verification_type）は8つ
種類には security_level が付いています。実測では Low が3つ、Medium が2つ、High が3つでした。
High に入るのは Email Code、SMS Code、Authenticator App。どれも「本人しか受け取れないところにコードを送る」方式です。Medium は秘密の質問と Soft PIN。Low は Personal Data 系で、ユーザーテーブルに入っている値を答えさせる方式でした。
Personal Data 系だけ auto_enroll が true になっています。自動で登録される、という意味です。メールアドレスはユーザー登録の時点で入っているので、あらためて登録してもらう必要がありません。
いっぽう秘密の質問や Soft PIN は、事前に本人が登録しておかないと使えません。だから auto_enroll が false です。この違いは運用に直結します。事前登録が要る方式を選ぶなら、全員に登録してもらう活動が先に必要になります。
種類は差し替えられる
pwd_verification_type の辞書を見ると、参照フィールドが5本ありました。
enrollment_processor … 登録の処理（→sys_script_include）
is_enrolled … 登録済みかどうかの判定（→sys_script_include）
verification_processor … 確認の処理（→sys_script_include）
enrollment_ui … 登録画面（→sys_ui_macro）
verification_ui … 確認画面（→sys_ui_macro）
処理3つと画面2つ。この5点セットを差し替えれば、独自の確認方式を足せます。社員証番号で確かめる、社内の別システムに問い合わせる。そうした要件に、テーブルを追加せずに対応できる作りです。
部品（pwd_verification）は10個
種類が8つなのに部品は10個あります。差が出るのは Personal Data 系で、同じ種類から3つの部品が作られていました。
Personal Data - Enter Email Address（order 100）
Personal Data - Enter User Name（order 300）
Personal Data - Confirm Email Address（order 400）
同じ「ユーザーテーブルの値で確かめる」方式でも、聞く項目と聞き方が違います。メールアドレスを入力させるのか、ユーザー名を入力させるのか、表示された値を確認させるのか。種類が「やり方」で、部品が「実際の問いかけ」にあたります。
order は 100 から 600 まで振られていました。並び順を決める値で、確認方法を利用者に選ばせる場合の表示順になります。Mock Verification の2件が 500 と 600 で最後に置かれているのは、動作確認用のダミーだと読めます。
何回通せばよいか
Default Self Service の Minimum verifications は 1 でした。1つの確認を通れば先に進めます。
この値を2にすれば、2種類の確認を要求できます。メールのコードと秘密の質問を両方、という組み合わせです。堅くはなりますが、利用者の手間は増えます。Security score とのバランスをどう取るかが設計の勘どころになります。
Allow user to choose from optional verifications はオフでした。利用者に方法を選ばせず、決められた確認だけを使わせる設定です。
秘密の質問は53件用意されている
pwd_question を数えると 53件 ありました。
質問文は question_translated フィールドに入ります。翻訳を前提にしたフィールド名で、多言語環境でも使えるようになっています。
中身を読むと、質問の作りかたの工夫が見えます。「結婚披露宴を行った場所は」「出願したが進学しなかった大学は」「最初の勤務先の会社名は」。どれも答えが後から変わりません。
一方で「子どものころ好きだった場所は」のような質問もあります。記憶の呼び出し方によって答えが揺れる可能性があり、こちらは登録時と回答時で表現がずれやすい種類です。
秘密の質問を使う運用では、53件すべてを見せる必要はありません。答えが変わりにくいものだけを絞って提示するほうが、後から「答えが合わない」という問い合わせを減らせます。
日本語環境では、もうひとつ考えることがあります。標準の53件は英語で、内容も欧米の生活を前提にしています。「9/11をどこで聞いたか」は、日本の利用者には答えにくい質問です。
question_translated というフィールド名が示すとおり、質問は翻訳できます。標準の53件を訳すか、日本の生活に合った質問を自分で足すか。どちらにせよ、そのまま出すと使いにくい部分です。
答えの揺れも見落としがちな点になります。「小学校の名前は」に対して、登録時は「◯◯小学校」、回答時は「◯◯小」。人はこう書き分けます。表記の揺れで弾かれる問い合わせが増えるので、質問文に「正式名称で」と添えておくだけでも効きます。
無効な4件が示す使い分け
有効なのは1件でしたが、無効の4件にも設計の意図が見えます。
Service-Desk Password Reset for Local ServiceNow Instance。サービスデスクの担当者が代行する処理です。目の前の相手が本人だと分かっている場面では、本人確認の要件が変わります。
Employee Self-Service Process for Local ServiceNow Instance。従業員向けの自己解決です。Default Self Service と似ていますが、対象者や確認方法を変えて使い分けられます。
Demo Self-Service Process 1 / 2。デモ用の2件で、動作を見せるためのものと読めます。Mock Verification の部品が2つ用意されていたのと対応します。
処理を複数持てるということは、入口も複数持てるということです。利用者向けの入口とサービスデスク向けの入口を、別のURLで分けられます。誰がどの入口を使うかで、要求する確認の強さを変える。これが pwd_process を複数持てる意味になります。
実行の記録はこのPDIには無かった
pwd_reset_request（リセット依頼）と pwd_reset_activity（活動ログ）は、どちらも 0件 でした。この PDI では実際のリセットが1度も行われていません。
そのため、この記事で読めたのは設定までです。利用者が公開URLを開いてから完了するまでに何が記録されるかは、記録が無いので確認できませんでした。
裏を返すと、設定は最初から一式そろっているということでもあります。処理5件、確認の種類8つ、部品10個、質問53件。何も作らなくても、有効化するだけで動き出せる状態が用意されています。
実務で気をつけるところ
公開URLはログイン不要である
Public access がオンの処理は、ログインしなくても開けます。これは仕組み上そうでなければ困るのですが、同時に「誰でも到達できる入口」でもあります。
captcha をオンにしておくのは最低限の備えです。加えて、確認方法の強さと必要数を決めるのが本命の対策になります。
公開URLは推測しやすい形をしています。ss_default という末尾は、標準のまま使えば誰でも同じです。独自の処理を作るときは、末尾を推測されにくい文字列にしておくと、入口そのものが見つかりにくくなります。ただし、これは補助でしかありません。守りの本体はあくまで本人確認です。
もうひとつ、利用者への案内も対策のひとつです。「パスワードリセットのURLをメールで送ります」という案内が普段から出ていれば、それを装った偽メールに気づきやすくなります。逆に、案内が無い状態で突然リセットURLが届けば、利用者は判断できません。
保管先を変えると画面が変わる
実画面に出ていた青い案内のとおり、Credential store が Local ServiceNow Instance のときはパスワード有効期限の項目が隠れます。外部の資格情報ストアに変えると、隠れていた項目が現れる可能性があります。
「設定項目が見当たらない」と感じたら、まず保管先を確認するのが早道です。
標準レコードは書き換えない
Default Self Service には High Risk の警告が出ていました。標準のまま使うか、必要なら複製して独自の処理を作るのが安全です。処理は複数持てて、それぞれ別のURLを割り当てられます。
事前登録が要る方式は先に配る
auto_enroll が false の確認方式は、利用者が事前に登録していないと使えません。パスワードを忘れてから登録することはできないので、平時に登録を済ませてもらう必要があります。
Enrollment Reminder というタブがフォームにあったのは、この課題への備えと読めます。実測では enrollment_reminder がオフでした。
どこから触るか
/pwd_process_list.do … リセット処理5件
/pwd_process.do?sys_id=... … Default Self Service の設定
/pwd_verification_type_list.do … 本人確認の種類8つ
/pwd_verification_list.do?sysparm_query=ORDERBYorder … 本人確認の部品10個
/pwd_question_list.do … 秘密の質問53件
/pwd_identification_type_list.do … 本人の特定方法2つ
処理のフォームでは Advanced タブと Enrollment Reminder タブも開いてみると、扱える範囲が見えてきます。
まとめ
Password Reset は「ログインできない人のための入口」を作る仕組みでした。
入口は公開URLで、処理ごとに別の末尾が割り当てられます。入った人はまず特定され、次に本人確認を通ります。確認は種類と部品の2階層。種類が方式を持ち、部品が実際の問いかけを持ちます。必要な通過数は処理側で決められる仕組みでした。
実測では処理5件のうち有効が1件、確認の種類が8つ、部品が10個、質問が53件。Security score は82と表示されていました。設定は一式そろっており、有効化と事前登録の運用を整えれば動き出せる状態です。
用語
pwd_process … リセット処理1式の定義。公開URLの末尾や必要な確認数を持つ
pwd_identification_type … 本人を特定する方法。ユーザー名かメールアドレス
pwd_verification_type … 本人確認の種類。処理3つと画面2つを差し替えられる
pwd_verification … 種類から作った実際の問いかけ。order で並ぶ
pwd_question … 秘密の質問。question_translated に本文が入る
pwd_cred_store … パスワードの保管先。実測は Local ServiceNow Instance の1件
Security score … その処理の設定がどれくらい堅いかの目安
自分の環境で確認するときのURL
/pwd_process_list.do?sysparm_query=ORDERBYname（処理5件）
/pwd_process.do?sys_id=...（Default Self Service のフォーム）
/pwd_verification_type_list.do?sysparm_query=ORDERBYsecurity_level（種類8つ）
/pwd_verification_list.do?sysparm_query=ORDERBYorder（部品10個）
/pwd_question_list.do（質問53件）
実測の要点（再掲）
pwd_process 5件（active は Default Self Service の1件のみ）
Default Self Service: Minimum verifications=1 / Security score=82。captcha オン、公開URL は ss_default
pwd_verification_type 8件。Low 3 / Medium 2 / High 3。auto_enroll が true なのは Personal Data 系の2件
pwd_verification 10件。order は 100〜600。Personal Data 系は1種類から3部品
pwd_question 53件。pwd_identification_type 2件。pwd_cred_store 1件
pwd_reset_request と pwd_reset_activity はどちらも0件
検証範囲とおことわり
件数・項目・設定値は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
パスワードリセットそのものは実行していません。設定の読み取りまでです。
Security score = 82 の算出ロジックは未検証です。表示値のみ確認しました。
各確認方式のスクリプトインクルードやUIマクロの中身は読んでいません。
外部の資格情報ストア（Active Directory など）はこの PDI に存在しません。
