はじめに
最近はClaude Codeを使って実装を行なっています。
AIに実装してもらい、自分で確認したうえでPRを作成し、上司や他のメンバーからレビューを受ける、という流れで開発しています。
レビューでは、自分では気付かなかった案件固有のルールや、過去の実装との整合性について指摘をもらうことがあります。
そこで、
「PRを出す前に、過去に指摘された内容を自分でも確認できるようにしたい」
と考えました。
今回はClaude CodeのSkillを使い、案件ごとのレビュー観点を読み込んでレビューし、実際のPRコメントを追加しながら観点を育てる仕組みを作ってみました。
やりたかったこと
やりたかったことはシンプルです。
AIで実装
↓
自分でレビュー
↓
PR作成
↓
上司・メンバーからレビュー
↓
新しい指摘をレビュー観点へ追加
↓
次回のレビューで利用
一度受けた指摘を、そのPRだけで終わらせず、次回以降の実装でも確認できるようにします。
レビュー観点を案件ごとに管理する
自分の環境では、work 配下に複数の案件があります。
~/work/
├── project-a/
├── project-b/
└── project-c/
案件ごとに設計やルールが異なるため、レビュー観点も案件単位で分けています。
~/work/.claude/review-checklists/
├── project-a.md
├── project-b.md
├── project-c.md
└── _template.md
一方で、レビューの基本的な進め方は案件が変わっても共通にしたいため、Skill自体は共通化しています。
~/.claude/
└── skills/
└── review/
└── SKILL.md
これにより、リポジトリが変わっても同じ流れでレビューしつつ、案件固有の観点だけを切り替えられます。
/review Skillを作る
作成したSkillでは、大きく2つの使い方をしています。
レビューする
案件内で、
/review
を実行すると、
- 現在の案件を判定する
- 案件用のレビュー観点を読み込む
- 変更内容を確認する
- 観点に沿ってレビューする
という流れで確認します。
特定のファイルだけ確認したい場合は、
/review src/example.ts
のように指定できます。
PRコメントからレビュー観点を追加する
PRで新しい指摘を受けた場合は、その内容をレビュー観点へ追加します。
現在はClaude CodeからPRコメントを取得し、内容を確認したうえで、
/review 「このPRコメントの内容を今後のレビュー観点に追加して」
のように更新しています。
このとき、PRコメントをそのまま保存するのではなく、別の実装でも使える形に一般化します。
例えば、
エッジケースが不足しているので追加して下さい。
という指摘を受けた場合は、
- 正常系だけでなく、空文字・null・異常値などのエッジケースが具体的にテストできているか、またテストケースが網羅されているかを確認する。
のような観点として追加します。
既存の観点と同じ内容であれば新しく追加せず、必要に応じて既存項目を具体化します。
レビュー観点だけに依存しない
案件ごとのMarkdownに記載した観点は利用しますが、それだけを確認するようにはしていません。
イメージとしては、
案件固有のルール
+
過去のPRレビュー
+
Claude Codeによる通常のコードレビュー
の3つを組み合わせて確認します。
過去に指摘された内容だけを確認していると、新しいバグや別の問題を見落とす可能性があります。
そのため、観点ファイルはあくまで追加のチェック材料として使い、一般的なコードレビューも一緒に行うようにしています。
コミット前のチェックに組み込む
/review をPR作成前にだけ実行するのではなく、現在はコミット前の確認にも組み込んでいます。
もともとコミット前には、
型チェック
↓
lint
↓
テスト
↓
コミット
といった確認を行っていました。
そこにレビューを追加し、
型チェック
↓
lint
↓
テスト
↓
/review
↓
必要に応じて修正
↓
コミット
という流れにしています。
これによって、PR作成直前にまとめて問題を見つけるのではなく、実装途中の小さい単位で確認できるようになりました。
実際に運用して分かったこと
最初は、1つのブランチの実装が終わったタイミングでまとめて /review を実行していました。
ただ、変更量が多くなると、
- レビューに時間がかかる
- 読み込むコード量が増える
- トークン消費も大きくなる
という問題がありました。
そこで現在は、ブランチ単位ではなく、コミットごとにレビューする方法を試しています。
一度に確認する変更量を小さくすることで、レビュー対象を絞りやすくなりました。
一方で、コミット単位にしても毎回レビューを実行すると、それなりに時間やトークンを消費します。
そのため、単純にレビューの実行単位を小さくするだけでなく、読み込ませるレビュー観点自体も見直す必要があると感じています。
今後の課題
PRレビューを追加していくと、案件ごとのMarkdownに記載するレビュー観点も少しずつ増えていきます。
観点が増えるほど確認できる内容は増えますが、
観点ファイルを読み込む
↓
変更差分を読み込む
↓
各観点と照らし合わせる
ための処理も増えていきます。
今後は、単純に観点を追加し続けるのではなく、
- 重複している観点をまとめる
- 長い説明を短くする
- 優先度の低い観点を整理する
- フロントエンド、バックエンド、DBなどで観点を分ける
- 変更内容に応じて必要な観点だけ参照する
といった工夫も必要だと考えています。
特に、
レビュー精度を上げることと、時間・トークン消費を抑えることのバランス
は、今後実際に使いながら調整していきたい部分です。
まとめ
今回はClaude CodeのSkillを使って、過去のPRレビューを次回以降のレビューに生かす仕組みを作りました。
現在の流れをまとめると、
Claude Codeで実装
↓
型チェック・lint・テスト
↓
/review
↓
必要に応じて修正
↓
コミット
↓
PR作成・レビュー
↓
新しい指摘をレビュー観点へ追加
↓
次回のレビューに反映
という形です。
人から受けたレビューを、その場限りの指摘として終わらせず、
次に自分が確認するためのレビュー観点として再利用する
ことを目的にしています。
実際に使ってみると、レビュー対象や観点が増えるほど時間やトークンも消費するため、単純に観点を増やせばよいわけではないことも分かりました。
また、Claude Codeで事前に確認できることが増えても、案件固有の背景や設計意図など、人の判断が必要な部分は残ります。
今後はMarkdownの内容や参照方法を見直しながら、AIと人のレビューをうまく組み合わせつつ、
必要な観点を、必要なタイミングで、できるだけ小さい範囲でレビューする
形に改善していきたいと思っています。