---
generated_at: 2026-02-24 20:55:00
metrics:
  claims_total: 24
  claims_with_evidence: 23
  claims_without_evidence: 1
confidence_derived: 0.96
---

# 根拠レポート：2-パスワードリセット画面

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.96**
  - 根拠あり：23 / 24、根拠なし：1
- 優先レビュー（高）
  1. **データベーステーブル構造（password_reset_token）**：バックエンド側の実装確認が必要

## 2) 参照した情報（Evidence一覧）

- E-01: `packages/admin/dashboard/src/routes/reset-password/reset-password.tsx`
- E-02: `packages/admin/dashboard/src/routes/reset-password/index.ts`
- E-03: `packages/admin/dashboard/src/hooks/api/auth.tsx`
- E-04: `docs/code-to-docs/画面一覧/画面一覧.csv`
- E-05: `docs/code-to-docs/画面機能マッピング/画面機能マッピング.csv`
- E-06: `docs/code-to-docs/画面一覧/画面遷移図.md`

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | 画面URLは `/reset-password` である | E-01 (164-170行目: Link to="/login") | ○ |
| C-02 | tokenパラメータの有無で2つのモードが切り替わる | E-01 (242行目, 270-272行目) | ○ |
| C-03 | ResetPasswordInstructionsSchemaでメールバリデーション | E-01 (18-20行目) | ○ |
| C-04 | ResetPasswordSchemaでパスワード一致チェック | E-01 (22-35行目: superRefine) | ○ |
| C-05 | ResetPasswordTokenSchemaでトークン検証 | E-01 (37-43行目) | ○ |
| C-06 | useResetPasswordForEmailPassフックでリセット要求 | E-01 (251行目), E-03 (41-54行目) | ○ |
| C-07 | sdk.auth.resetPasswordでAPIを呼び出す | E-03 (45-47行目) | ○ |
| C-08 | useUpdateProviderForEmailPassフックでパスワード更新 | E-01 (117行目), E-03 (63-75行目) | ○ |
| C-09 | sdk.auth.updateProviderでAPIを呼び出す | E-03 (68-69行目) | ○ |
| C-10 | decodeTokenでJWTトークンをデコード | E-01 (102-104行目: decodeToken) | ○ |
| C-11 | 無効なトークン時はInvalidResetTokenを表示 | E-01 (141-143行目, 57-95行目) | ○ |
| C-12 | 成功時にAlertコンポーネントで通知 | E-01 (202-210行目, 310-318行目) | ○ |
| C-13 | エラー時にtoast.errorで通知 | E-01 (134-135行目, 263-264行目) | ○ |
| C-14 | ログイン画面へのリンクがある | E-01 (220-230行目, 326-335行目) | ○ |
| C-15 | LogoBoxコンポーネントを使用 | E-01 (64行目, 148行目, 277行目) | ○ |
| C-16 | useFormフックを使用している | E-01 (109-115行目, 244-249行目) | ○ |
| C-17 | zodResolverでバリデーション | E-01 (110行目, 245行目) | ○ |
| C-18 | 成功後はボタンが非表示になる | E-01 (212-216行目: !showAlert && Button) | ○ |
| C-19 | 画面カテゴリは「認証」である | E-04 (3行目: カテゴリ=認証) | ○ |
| C-20 | 関連機能No.59 認証ID管理が主機能 | E-05 (5行目: 画面No=2, 機能No=59) | ○ |
| C-21 | 関連機能No.77 通知送信が補助機能 | E-05 (6行目: 画面No=2, 機能No=77) | ○ |
| C-22 | ログイン画面からの遷移がある | E-06 (認証フロー: Login --> ResetPassword) | ○ |
| C-23 | リセット完了後ログイン画面へ遷移 | E-06 (認証フロー: ResetPassword --> Login) | ○ |
| C-24 | password_reset_tokenテーブルでトークン管理 | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- パスワードリセットトークンの保存方法とテーブル構造
  - 候補：`packages/modules/auth/src/` / バックエンドスキーマ定義 / 認証モジュールのドキュメント

## 5) リスクフラグ（レビュー観点）
- 0（低リスク）：フロントエンド側の処理はソースコードから確認済み
- 1（中リスク）：バックエンド側のトークン管理方法の確認が必要

## 6) レビュアーチェックリスト（最小）
- [ ] パスワードの最小文字数要件が適切か確認（現在は1文字以上）
- [ ] トークンの有効期限設定が業務要件を満たしているか確認
- [ ] パスワードリセットメールの送信処理を確認
- [ ] i18nキーの翻訳が適切に設定されているか確認
- [ ] superRefineのエラーメッセージが正しく表示されるか確認
