雑にいじってから確認させると、だいたい手戻りする。Claude Code でもそこは変わらない。先にセルフレビュー、つまり事前レビューの観点を出させてから変更に入るだけで、あとから「そこじゃない」を潰しやすくなる。
この手は、コード修正だけの話ではない。ファイル整理、不要キャッシュの削除、文書の推敲みたいな作業でも効く。いきなり本体を触らせると、見た目は進んでも肝心の判断基準があいまいなまま走る。結果、差分は増えるのに、欲しかった品質には届かない。かなりもったいない。
やることは単純だ。変更を頼む前に、「何を見て自分で確認するか」を Claude Code に先に書かせる。観点を先に固定しておくと、作業中のブレが減る。人間の側も、あとからレビューしやすい。
たとえば、いきなり「この関数を直して」と投げる代わりに、こう始める。
この変更を始める前に、自己レビューの観点を先に列挙してほしい。
対象は次の通り。
- 変更対象ファイル: src/app.ts
- 目的: エラーハンドリングの改善
- 制約: 既存の挙動を変えすぎない
- 出力: 先にレビュー観点、その後に変更案
観点は、機能、後方互換性、エッジケース、差分の大きさ、テストの5つを最低限含めてほしい。
この一手で大事なのは、「あとで気をつけて」ではなく、「最初に確認項目を言語化させる」ことだ。Claude Code は指示が曖昧でもそれっぽく進められるぶん、観点が空だと、当たり前の抜けが起きる。逆に観点を先に渡すと、変更の理由と検査の順番が揃う。
文書作成でも同じだ。たとえば社内手順書を整えたいなら、こう頼むといい。
この文書を修正する前に、自己レビューの観点を先に出してください。
観点には次を含めてください。
- 用語のぶれ
- 手順の抜け
- 読み手が迷う箇所
- 古い表現や重複
- 変更後に確認すべき箇所
その後で、観点に沿って本文を直してください。
ファイル整理なら、観点はもっと実務寄りになる。
整理作業の前に、自己レビューの観点を先に書いてください。
対象は Downloads フォルダです。
観点には次を入れてください。
- 削除してよい根拠があるか
- 同名ファイルや重複がないか
- 日付や拡張子の判断が雑になっていないか
- 重要そうなものを消していないか
- 変更前に確認すべきフォルダやファイル
観点を出したら、実作業の手順を提案してください。
ここで効くのは、Claude Code に「作業」ではなく「判断」を先にさせる点だ。人間でも、いきなり手を動かすと大事な確認を飛ばす。AI も同じで、先に観点があると、後段の修正がだいぶ締まる。筆者はこれをサボって、長い差分だけ出させたあとに「テスト観点が抜けている」と気づき、手戻りで時間を食ったことがある。差分を眺めて安心するのは、かなり危ない。
ただし、観点の書かせ方にはコツがある。雑に「レビューして」とだけ言うと、抽象論が返ってきやすい。使える観点にしたいなら、対象、目的、制約、見てほしい観点を少しだけ絞る。全部を一度に盛る必要はない。むしろ盛りすぎると、観点が広すぎて、どれも浅くなる。
悪い例はこんな感じだ。
変更前にレビューして
これだと、何を基準に見るのか曖昧すぎる。よくある一般論が返ってきて終わる。使うなら、こうしたほうがいい。
変更前に自己レビューの観点を先に出して。
対象は src/ と docs/ で、目的は不要な挙動変更を避けながらリファクタすること。
観点は次の順で出してほしい。
1. 仕様に影響する箇所
2. 既存テストへの影響
3. 差分が大きくなりすぎる箇所
4. 先に確認すべきファイル
5. 変更後に人間が目視すべき点
この順番指定が地味に効く。Claude Code は、先に重要な観点を出すようにしておくと、あとで読む側も迷いにくい。レビュー観点が先頭に来るだけで、作業の軸が見える。
もうひとつ大事なのは、セルフレビューを「変更の前」と「変更の後」で分けることだ。先に観点を書かせるのは、いわば設計図を作るためだ。そのあと実際に変更して、最後に観点へ照らして再点検させる。ここを一回で済ませると、チェックが甘くなる。
こんな流れにすると使いやすい。
1. 変更前に自己レビューの観点を列挙する
2. その観点に基づいて変更案を作る
3. 変更後に、同じ観点で自己レビューをして、足りない点があれば直す
このやり方は、特に差分が増えやすい作業で効く。たとえば大量のファイル名変更、文書の全面改稿、設定ファイルの整理だ。作業そのものより、「何を変えないか」を先に決める場面で役に立つ。ここを曖昧にすると、いらない差し替えまで混ざる。差分が汚れると、人間の確認コストが一気に上がる。
注意したいのは、自己レビューの観点を万能扱いしないことだ。観点を先に書かせても、事実確認そのものが不要になるわけではない。API の仕様、CLI の挙動、ファイルの中身、削除してよいデータの判断は、結局は人間か実データで見るしかない。Claude Code が書いた観点は、あくまで漏れを減らすための下敷きだ。
それと、観点は長ければいいわけでもない。十個も二十個も並べると、チェックリスト倒れになる。実際に使うなら、3〜7個くらいに絞ったほうが機能することが多い。筆者は最初、網羅しようとして観点を増やしすぎ、読むだけで疲れるメモを量産した。あれは完全に逆効果だった。短く、でも外せないものだけ残すのが正解だ。
少し進めるなら、観点をテンプレ化しておくと楽になる。自分の作業で毎回見る項目が似ているなら、最初から言わせる内容を固定すればいい。
変更前に自己レビューの観点を、次の固定フォーマットで先に書いてください。
- 仕様への影響
- 既存資産への影響
- 例外系
- 差分の大きさ
- 手戻りしやすい点
そのあと、今回の対象にだけ合わせて具体化してください。
こうしておくと、コードでも文書でも、作業前に一度立ち止まる癖がつく。Claude Code をただの実行役にせず、先に考えさせる使い方だ。地味だが、効く。急いでいるときほど、先に観点を書くほうが早い。雑に始めるより、あとで崩れにくいからだ。