レビューで毎回ゼロから目をこらしていると、だいたいどこかで雑になる。しかも厄介なのは、雑になる場所が毎回少しずつ違うことだ。今回たまたま見たつもりでも、次回は別の抜けが出る。これ、かなりもったいない。
Claude Code は、こういう「見る観点が毎回似ている仕事」に強い。レビュー観点テンプレ、あるいは確認テンプレとして定型を持たせておくと、何を見ればいいかを毎回考え直さなくて済む。結果として、確認が速くなるだけでなく、抜け漏れも減る。
ただし、テンプレを作れば勝手に賢くなるわけではない。雑な観点をそのまま固定すると、雑さまで恒久化する。ここを外すと、むしろ手戻りが増える。筆者は最初、「とりあえず変更点を見て」とだけ投げて、結局あとから「ここも確認して」「いや、権限まわりも見て」と差し戻しを食らった。あれはだいぶだるかった。最初から観点を固定しておけば、こんな往復は減る。
まずやることは単純だ。よく見るポイントを、短い文章で並べる。Claude Code に渡すなら、こういう形でいい。
この作業のレビューでは、次の観点を毎回確認してください。
- 変更の目的と、実際の差分が一致しているか
- 余計なファイルが混ざっていないか
- 既存の命名や配置ルールを壊していないか
- 破壊的な変更、上書き、削除が含まれていないか
- 関連する設定、ドキュメント、テストの更新が抜けていないか
観点ごとに、問題なければ短く「問題なし」、気になる点があれば具体的に指摘してください。
これだけでも、毎回のレビューはかなり楽になる。ポイントは、「何を見るか」を具体語で書くことだ。「ちゃんと確認して」みたいな指示は、ほぼ役に立たない。Claude Code は空気を読む道具ではない。見てほしい場所を言葉にして渡したほうが、出力が安定する。
もう少し実務向けにするなら、観点を用途別に分けるといい。たとえばファイル整理なら、コードの正しさより「消していいものか」「重複していないか」「移動先が妥当か」が大事になる。文書作成なら、「表現の重複」「用語の統一」「誤字よりも論旨の飛び」が効く。開発作業なら、「副作用」「設定ファイルへの影響」「テスト漏れ」が主役だ。全部を一つの大きなテンプレに押し込むと、長くなるだけで読まれない。
実際、テンプレは長すぎると機能しない。人間も Claude Code も、長大なチェックリストを毎回まるごと抱えるのはしんどい。なので、基本は 5〜7 項目くらいに絞るのが扱いやすい。足りない観点は、その案件だけに追加する。全部を常設しない。この割り切りがかなり効く。
たとえば、リポジトリの変更レビュー用に、こんなテンプレを作っておく。
レビュー観点テンプレ
1. 変更の目的と差分が一致しているか
2. 既存の命名、配置、フォーマットから外れていないか
3. 副作用がありそうな箇所はないか
4. 設定、環境変数、権限、パスの変更が混ざっていないか
5. テストや確認手順の更新が必要か
これをそのまま毎回貼るのもいいが、もっと実用的なのは、案件の種類ごとに分けておくやり方だ。たとえば「コード修正用」「ファイル整理用」「文章校正用」の 3 種類にしておく。Claude Code に渡すときも、案件に合うものを一つ選ぶだけで済む。選ぶのは人間の仕事だが、その選択肢が少ないほど速い。
非エンジニアでも、この発想はそのまま使える。たとえば大量の書類を整理するとき、「日付が新しいか」「重複していないか」「送付前の最終版か」「削除してよい一時ファイルか」をテンプレにする。写真整理なら「同じ内容の連写か」「ぼけているか」「保管価値があるか」を見る。Claude Code にフォルダを見せて、こう頼めばいい。
このフォルダ内のファイルを整理するときの確認観点を次の順で使ってください。
- 重複しているファイルを見つける
- 一時ファイルや不要なキャッシュを候補にする
- 重要そうなものと、消してよさそうなものを分ける
- 名前が似ているファイルは、内容の違いも確認する
削除候補は、すぐ消さずに候補として列挙してください。
ここで大事なのは、いきなり削除まで踏み込ませないことだ。レビュー観点テンプレは、判断の順番を固定する道具でもある。最初から結論を急がせると、危ないものまで一緒くたに処理される。特にファイル整理は、見た目が似ているだけで中身が違うことがある。そこを雑にすると痛い目を見る。
注意したいのは、テンプレを「正解の断定」にしないことだ。観点はあくまで確認の順番であって、最終判断そのものではない。たとえば「テストがないからダメ」と機械的に切るのではなく、「この変更ならテスト追加が必要そうだ」と言わせるほうが使える。レビュー観点テンプレは、杓子定規な判定器ではない。見る癖を整えるためのものだ。
筆者が一度やらかしたのは、観点テンプレに「見た目をきれいにする」を雑に入れたことだ。これだけだと、Claude Code は細かい文言の統一からファイル名の微修正まで、やたら広く拾おうとする。結果、レビューが「そこじゃない」方向に膨らんだ。なので、曖昧な言葉はすぐに具体化したほうがいい。見た目なら「表記ゆれ」「改行」「空白」「並び順」まで落とす。ここまで書くと、ようやくテンプレとして機能する。
もう一つ効くのは、テンプレの末尾に「出力形式」まで決めてしまうことだ。毎回の確認結果を、同じ型で返させると読みやすい。
各観点について、次の形式で返してください。
- 観点名
- 判定: 問題なし / 要確認 / 要修正
- 理由: 1〜2文
- 補足: 必要な場合だけ
こうしておくと、後で人間が見返しやすい。レビューは、その場で終わればいい仕事ではない。あとから差分を追うことも多い。だから、出力が毎回バラバラだと地味にきつい。テンプレ化の価値は、確認の速さだけじゃなく、読み返しやすさにもある。
最後に、テンプレは育てるものだと考えたほうがいい。最初から完璧にはならない。むしろ、数回使ってみて「ここは毎回見落とす」「この項目は長すぎる」と削ったり足したりするほうが現実的だ。レビュー観点テンプレ、確認テンプレは、固定資産ではない。使うほど自分の仕事に寄っていく道具だ。
Claude Code に同じ種類の確認を何度もさせるなら、まず観点を言語化する。次に、用途ごとに分ける。最後に、出力の型まで決める。この三つだけで、毎回の確認はかなり速くなる。雑に「見ておいて」で済ませるより、ずっと強い。