Skip to content

テンプレート — レビューチェックリスト

いつ使うか

ステージ4 — 検証でエージェントの成果物を人または交差レビューのエージェントが検討するときに使う。コードレビューを「うまく書けているか」中心にだけ見ると、エージェント特有の誤り — 意図とずれた実装、実際には何も検証していないテスト、不必要に防御的なコード — を見落としやすい。このチェックリストはそうした誤りを項目として釘付けにし、レビュアーが毎回同じものを見落とさないようにする。

使い方

レビューするPR/コミット単位で下のチェックリストをコピーし、レビューコメントやレビュー記録文書に貼り付ける。チェックできない項目(根拠が不十分な項目)は通過させず、理由を横に書いて残す。レビュー中に繰り返し引っかかる項目があれば、その項目をプロジェクトのCLAUDE.mdやリントルールへ移し、次サイクルからは自動で引っかかるようにする — チェックリストにだけ残してコンテキスト資産へ移さないと、同じ誤りが繰り返される。

テンプレート

markdown
# レビューチェックリスト: [PR/コミット識別子]

- リスク等級: <!-- 記入ガイド: リスクマトリクス基準の等級を書く。例: High -->
- レビュアー: <!-- 記入ガイド: 実装したエージェント/セッションと異なる人またはエージェントかを明示 -->

## 意図整合性

<!-- 記入ガイド: 成果物が意図文書に書いた目標と実際に一致するか確認する。 -->

- [ ] 実装が意図文書の目標(成功基準)を実際に満たす (例: 「オンボーディング5ステップへ短縮」が実際のステップ数で確認される)
- [ ] 意図文書にない範囲が勝手に追加されていない (例: 依頼していないUI要素、スコープ外のリファクタリング)
- [ ] 意図文書の非目標(捨てたもの)が誤って再び実装されていない

## セキュリティの基本

<!-- 記入ガイド: リスク等級がMedium以上なら必ず確認する。 -->

- [ ] ユーザー入力が検証・エスケープなしにそのままクエリ/コマンド/テンプレートへ入らない
- [ ] 認証/認可のチェックが迂回経路なくすべての入口にかかっている (例: APIルート追加時のミドルウェア抜け漏れの有無)
- [ ] シークレット(APIキー、トークン)がコードやログにハードコードされていない

## テストの実在性

<!-- 記入ガイド: テストが通るという事実ではなく、通る理由を確認する。 -->

- [ ] テストを失敗させてみたとき(ロジックをわざと壊して)実際に失敗する — 常に通る偽のテストではない
- [ ] 境界値と失敗ケース(空入力、最大値、ネットワークエラーなど)がテストに含まれている
- [ ] テストが実装の詳細ではなく意図した動作を検証する (例: 「関数が呼ばれたか」ではなく「結果値が正しいか」)

## コンテキスト反映の可否

<!-- 記入ガイド: 成果物がプロジェクトの既存ルール・規約・用語に従うか確認する。 -->

- [ ] コーディング規約(ネーミング、フォルダ構造)が`CLAUDE.md`/既存のコードベースと一致する
- [ ] すでにあるユーティリティ/ヘルパーを再利用せず、似た機能を新しく作っていない
- [ ] ドメイン用語集に固定された用語を別の意味で使っていない

## スロップの兆候

<!-- 記入ガイド: デモでは問題なく見えるが、保守ステージで負債となるパターンを探す。 -->

- [ ] 重複コードがない (同じロジックが複数箇所にコピペされていない)
- [ ] デッドコードがない (使われない関数、到達不能な分岐、コメントアウトされたコードブロック)
- [ ] 過度な防御コードがない (起こりえないケースまでtry-catch/nullチェックで包み、ロジックを読みにくくしていない)

## 総合判定

- [ ] 上の項目を根拠に、この成果物を信頼して次のステージ(デプロイ)へ渡せる
- 通過しなかった項目と後続対応: <!-- 記入ガイド: コード修正で終えるか、意図文書/コンテキスト資産まで直すか明示 -->