はじめに

最近は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と人のレビューをうまく組み合わせつつ、

必要な観点を、必要なタイミングで、できるだけ小さい範囲でレビューする

形に改善していきたいと思っています。