クライアント確認事項認証・ログインID運用
📁 クライアント確認事項

クライアント確認事項：認証・ログインID運用

⏳ 確認中 起票日: 2026-07-01

1. 背景

新システムのログインまわりについて、要件書には「ログインIDとパスワードで入る」「パスワードを忘れた人はリセットメールで再設定する」といった大枠だけが書かれており、運用に必要な細かい決めごとが残っています。具体的には、リセットメールが届いてから何時間使えるか、ログインIDをそもそも忘れた人はどうやって救済するか、事務局スタッフがログインフォームから入ったときにどこへ飛ばすか、などです。

これらは「Phase1リリース直後の問合せ対応負荷」と「現場運用のしやすさ」に直結するため、リリース前に確定させてください。

2. 現状・課題・影響範囲

2.1 現状

  • パスワードリセット導線は、要件書に「リセットメール送信」とだけ書かれています。
  • 事務局スタッフは普段、WordPressの管理画面（/wp-admin/）にBASIC認証等で直接ログインする想定ですが、もし会員サイトのログインフォームから事務局アカウントで入ってきた場合、どこに着地させるかは未定義です。
  • 「ログインIDを忘れた」場合の救済手段は要件書に記述がありません。

2.2 ご相談したいこと

これらは「私たちが勝手に決めると、現場の運用や問合せ対応に支障が出る可能性がある」内容です。以下のQ1〜Q4でご判断ください。

2.3 この判断が関わる場所

  • 会員サイトのログイン画面（F-AUTH-001）
  • パスワード再設定フロー（F-AUTH-003）
  • ログイン後の遷移先決定（F-AUTH-004）
  • 会員へ送られる「パスワードリセット案内メール」
  • 事務局のお問合せ対応フロー（ID忘れの問合せ）

3. 確認ポイント

Q1 パスワードリセットの再設定リンクは、メール送信後何時間まで有効にしますか？
A
24時間
現場ではこうなります：当日中に再設定する想定。翌日になったら再申請が必要です。
良いところ：万一メールが第三者に渡っても、悪用可能な時間が短く済みます。
気になるところ：受信トレイを翌日確認した会員は、もう一度申請する必要があります。
開発の手間：軽め
B
7日間
現場ではこうなります：1週間以内に対応すれば再申請なしで完了できます。
良いところ：会員の手間が少ないです。週末を挟んでも対応できます。
気になるところ：リンクが7日間有効になるため、メール漏洩時のリスクが高まります。
開発の手間：軽め
C
その他（具体的に）
Q2 ログインIDを忘れた会員の救済はどうしますか？
A
「お問合せフォーム」に誘導する
現場ではこうなります：ログイン画面に「ログインIDを忘れた方はこちら」リンクを置き、お問合せフォーム（ログイン前画面）で受け付け、事務局が手動で本人確認し回答します。
良いところ：成りすまし防止のため、本人確認の余地が残ります。
気になるところ：事務局の対応工数が発生します。
開発の手間：軽め（既存のお問合せ画面を流用）
B
メールアドレスを入力して自動返信
現場ではこうなります：会員が登録メールアドレスを入力すると、そのメール宛にログインIDが自動送信されます。
良いところ：会員の自己解決率が高まり、事務局工数が減ります。
気になるところ：メール乗っ取り時の漏洩リスクがあります。
開発の手間：中くらい
C
その他（具体的に）
Q3 事務局スタッフが会員サイトのログインフォームから入った場合、どこへ飛ばしますか？
A
WordPress管理画面（/wp-admin/）にリダイレクトする
現場ではこうなります：事務局の業務画面はすべてWP管理画面にあるため、ログイン後すぐ管理画面に到達します。
良いところ：事務局の業務動線が短くなります。
気になるところ：特になし
開発の手間：軽め
B
会員サイトの管理者向けトップ画面に飛ばす
現場ではこうなります：会員サイトに着地してから、別途WP管理画面への導線を辿ります。
良いところ：会員向け画面の確認が同時にできます。
気になるところ：事務局の業務動線が遠回りになります。
開発の手間：軽め
Q4 パスワードを何度も間違えた場合、ログインを一時的に止めますか？（2026-07-03 追加）

現在の設計では、2段階認証などの本格的な認証強化は Phase1 の範囲外としています。ただし「パスワードの連続間違いへの最低限の防御」だけは切り分けてご判断ください。何も制限しないと、機械的にパスワードを試し続ける攻撃（総当たり攻撃）に対して無防備になります。一方で、事業所アカウントは複数の職員で共有するため、誰かの入力ミスが続くと他の職員も一時的にログインできなくなる影響があります。

A
同一アカウントで5回連続で間違えたら15分間ログインを止める
現場ではこうなります：5回失敗すると「しばらく時間をおいてお試しください」と表示され、15分後に自動解除されます。事務局の操作は不要です。
良いところ：総当たり攻撃を実用上防げます。ロック解除の問合せ対応も発生しません（時間経過で自動復旧）。
気になるところ：共有アカウントでは、他の職員も最長15分待つことになります。
開発の手間：軽め
B
制限しない（何回でも試せる）
現場ではこうなります：間違え続けてもロックされません。
良いところ：共有アカウントの利用が止まることはありません。
気になるところ：総当たり攻撃への防御がなく、セキュリティ監査で指摘される可能性が高いです。
C
回数・時間を変えて制限する（例：10回で30分）
現場ではこうなります：緩めの制限で運用します。具体値をご指定ください。

4. 私たち（開発側）からのおすすめ

  • Q1=A（24時間）／Q2=A（お問合せ誘導）／Q3=A（WP管理画面リダイレクト）／Q4=A（5回で15分ロック） を推奨します。
  • 根拠は次のとおりです。
    • Q1: 業界標準（24時間）で運用負荷とセキュリティのバランスが取れます。週末を跨いだ場合の再申請は、お問合せフォームで救済可能です。
    • Q2: 「指定事業所番号」型のIDは法人による本人確認が必要なケースが多く、自動返信より事務局の手動対応が安全です。
    • Q3: 事務局の業務画面はWP管理画面に集中しているため、最短動線で着地できます。
    • Q4: パスワードリセットには既に同種の制限（同一宛先1時間1回）があり、ログインだけ無制限にする合理性がありません。時間経過による自動解除なら事務局の解除作業も不要です。