---
generated_at: 2026-01-29 16:45:00
metrics:
  claims_total: 22
  claims_with_evidence: 22
  claims_without_evidence: 0
confidence_derived: 1.00
---

# 根拠レポート：4-パスワードリカバリ

## 本レポートについて

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

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

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

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

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

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**1.00**
  - 根拠あり：22 / 22、根拠なし：0
- 優先レビュー（高）
  1. なし - 全ての主張に根拠あり

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

- E-01: `src/Storefront/Controller/AuthController.php` - recoverAccountForm(), generateAccountRecovery()（222-277行目）
- E-02: `src/Core/Checkout/Customer/SalesChannel/SendPasswordRecoveryMailRoute.php` - 全体（1-257行目）
- E-03: `docs/code-to-docs/機能一覧/機能一覧.csv` - No.4の定義
- E-04: `docs/code-to-docs/画面機能マッピング/画面機能マッピング.csv` - 画面No.14のマッピング

## 3) Claims と根拠の対応（レビューの主戦場）

| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | AuthController::recoverAccountFormがGETリクエストを受け取る | E-01 (222-226行目: Route属性でGETメソッド指定) | ○ |
| C-02 | AuthController::generateAccountRecoveryがPOSTリクエストを受け取る | E-01 (242-246行目: Route属性でPOSTメソッド指定) | ○ |
| C-03 | emailデータをDataBagとして取得 | E-01 (249-251行目: $data->get('email') as DataBag) | ○ |
| C-04 | storefrontUrlを設定 | E-01 (254行目: mailData->set('storefrontUrl')) | ○ |
| C-05 | sendPasswordRecoveryMailRouteを呼び出し | E-01 (256-260行目: $this->sendPasswordRecoveryMailRoute->sendRecoveryMail) | ○ |
| C-06 | CustomerNotFoundExceptionでも成功メッセージ | E-01 (263-264行目: catch CustomerNotFoundException -> addFlash SUCCESS) | ○ |
| C-07 | RateLimitExceededExceptionで待ち時間表示 | E-01 (267-268行目: catch RateLimitExceededException) | ○ |
| C-08 | Email形式のバリデーション | E-02 (127-131行目: validation->add('email', new Email())) | ○ |
| C-09 | storefrontUrl検証（ドメイン一覧でChoice） | E-02 (135行目: new Choice(choices: getDomainUrls)) | ○ |
| C-10 | レート制限チェック（RESET_PASSWORD） | E-02 (77-79行目: rateLimiter->ensureAccepted(RateLimiter::RESET_PASSWORD)) | ○ |
| C-11 | 顧客検索時にactive=1でフィルタ | E-02 (209行目: EqualsFilter('customer.active', 1)) | ○ |
| C-12 | 顧客検索時にguest=0でフィルタ | E-02 (211行目: EqualsFilter('customer.guest', 0)) | ○ |
| C-13 | boundSalesChannelIdでOR条件フィルタ | E-02 (212-215行目: MultiFilter::CONNECTION_OR) | ○ |
| C-14 | 既存リカバリレコードの検索と削除 | E-02 (95-98行目: existingRecovery検索->deleteRecoveryForCustomer) | ○ |
| C-15 | 32文字のランダムハッシュ生成 | E-02 (102行目: Random::getAlphanumericString(32)) | ○ |
| C-16 | customer_recoveryテーブルにINSERT | E-02 (105行目: customerRecoveryRepository->create) | ○ |
| C-17 | PasswordRecoveryUrlEventを発行 | E-02 (248-249行目: dispatch PasswordRecoveryUrlEvent) | ○ |
| C-18 | CustomerAccountRecoverRequestEventを発行 | E-02 (116-118行目: dispatch CustomerAccountRecoverRequestEvent) | ○ |
| C-19 | デフォルトURLテンプレートは/account/recover/password?hash= | E-02 (245行目: urlTemplate デフォルト値) | ○ |
| C-20 | Store-APIのルートパスは/store-api/account/recovery-password | E-02 (70行目: Route path定義) | ○ |
| C-21 | 機能名は「パスワードリカバリ」でAuthController::recoverAccountFormを使用 | E-03 (5行目: No.4の定義) | ○ |
| C-22 | 画面No.14がパスワードリカバリページ | E-04 (37行目: 画面No.14, 機能No.4のマッピング) | ○ |

## 4) 不足情報（Unknown / Missing）

- なし - 全ての主張がソースコードまたはCSVファイルで確認可能

## 5) リスクフラグ（レビュー観点）

- 0: 低リスク - 全ての主張がソースコードから直接確認可能であり、推測に基づく記述はない

## 6) レビュアーチェックリスト（最小）

- [ ] AuthController.phpのリカバリ関連メソッドが記載と一致しているか確認
- [ ] SendPasswordRecoveryMailRoute.phpのバリデーションロジックが正しく記載されているか確認
- [ ] CustomerAccountRecoverRequestEventの発行タイミングが正しいか確認
- [ ] レート制限のキー（RESET_PASSWORD）が正しいか確認
