Claude Cowork を社内AXに使っている私の実践ログです。社内固有名・個人名は伏せています。
「PR出す前に、もう一回 diff 全部読みなおすか…」
その儀式、私は本気で嫌いだった。30分かけて読み直して、結局見つかるのは命名のブレと console.log の消し忘れ。たまに大きい指摘が出るけど、ほとんどは細かい。退屈。なのに飛ばすと、必ずレビュアーから「ここインデント揃ってないですよ」が飛んでくる。詰む。
で、3週間前に Claude Code に丸投げしてみた。結論、私はもうセルフレビューを「人がやる仕事」だと思っていない。
どう組んだか(構成は3行で済む)
私の運用はシンプルで、.claude/commands/selfreview.md に手順書を置いて、PR ブランチで /selfreview を叩くだけ。中で Claude Code が git diff origin/main...HEAD を読んで、私が指定した観点でチェックして、Markdown で吐く。
レビュワー宛のコメントは私が貼る。Claude には「私が見落としそうなところ」を全部洗い出してもらって、最後に私が取捨選択する。意思決定は私、しらみつぶしは Claude、という分担。これが効く。
私がやめた5つの作業
実際に手放したやつを正直に並べる。順序は「やめてラクになった度」。
1. console.log / dbg!() / TODO コメントの探し漁り
これ、地味に効く。grep でも拾えるけど、// TODO: あとで直す みたいな意味付きを文脈ごと拾えるのは Claude が圧倒的。
2. 命名ブレの一覧化
同じ概念で userId と user_id が混在してるやつ。レビュー中に気付くと毎回イラッとしていた。今は事前に「変数名のスタイル違反を全部出して」と言うだけ。
3. 自分の diff の「なぜここ触った?」セルフ問答
これが一番大きい。Claude に「この変更、本当に必要だった?消せる行ある?」と聞かせるのが、自分でやるより容赦ない。自分相手だと甘くなる。Claude は容赦ない。
4. テスト網羅性のざっくり確認
追加した関数に対してテストがあるか、エッジケース漏れがないか。「テスト書き忘れリスト」をMarkdownで出させてる。
5. PR 説明文の下書き
diff を読んでビジネス上の意味を1段落書かせる。これ、レビュアーが感謝してくれた。
コピペで使えるテンプレ(/selfreview の中身)
私が今使っているやつを、ほぼそのまま貼る。.claude/commands/selfreview.md:
あなたは私の PR セルフレビュー担当です。私は怠惰なので、私が見落としやすいところを容赦なく指摘してください。
## やってほしいこと
以下の観点で `git diff origin/main...HEAD` を読み、Markdown で結果を返してください。
1. **デバッグ残骸**: console.log / print / dbg! / TODOコメント / コメントアウトされたコード
2. **命名ブレ**: 同一概念に複数の命名スタイル(camelCase と snake_case の混在等)
3. **不要な変更**: 機能に関係ない whitespace / import 順 / フォーマッタが勝手に直した行
4. **テスト漏れ**: 追加/変更された関数で、テストが追加されていないもの
5. **PR説明文ドラフト**: 1段落でビジネス上の変更意図、1段落で技術的な変更概要
## ルール
- 「ここはレビュアーが嫌いそう」という直感も歓迎
- 確信が無い指摘には [推測] とラベルを付ける
- 「問題なし」と判断したカテゴリは「✅ 問題なし」と1行で済ませる
これ貼って /selfreview するだけ。3分で結果が返る。私の30分が3分になった。
私の判断(賛否あると思う)
「セルフレビューを人がやる時代は終わった」と私は思っている。
これは強めに言いたい。AI レビューを「補助」扱いしている人を見るけど、私はもう逆だと思う。**人間がやるのは「指摘の取捨選択」と「修正の意思決定」**だけでいい。スキャンと網羅は機械の仕事。
理由はシンプルで、人間のセルフレビューは「自分のコードを甘く見る」というバグを構造的に抱えている。書いた本人がレビューしても、見つかるものは限られる。Claude にやらせると、自分が想定してなかった角度から指摘が飛んでくる。これが効く。
ただし——Claude の指摘を全部採用するのは絶対にやめたほうがいい。たまに「いや、それは意図してそうしてるんだよ」というやつが混じる。最終取捨選択は必ず人間。ここは譲らない。
ハマったところ(7個)
3週間で詰まったところを正直に書く。
-
最初、diff が大きすぎて Claude が途中で力尽きた
500行超える PR で「重要な指摘を5個まで」と制限したら、本当に重要なのが落ちた。今は「カテゴリ別に全件、優先度ラベル付き」に変更。長くなるが、読む側で絞れる。 -
origin/mainが古いと差分がバグる
git fetch origin mainを/selfreview内で先に走らせるよう手順書に追記した。これ最初気付かなくて、「なんで関係ない行まで指摘されてんの?」と30分溶かした。 -
「whitespace の指摘ばかり返ってくる問題」
フォーマッタの差分を拾いすぎる。.gitattributesで生成物をlinguist-generated=trueにしても効かなくて、結局プロンプトに「フォーマッタ起因の差分は除外」と明記した。 -
「テスト漏れ」の判定が甘い
private 関数まで全部テスト要求してきた時期があった。「public API のみ対象、内部実装は対象外」を追記したら落ち着いた。 -
日本語と英語が混ざる
コメントは日本語、見出しは英語、みたいな混在になる時があって、レビュアーから「結局なに?」と言われた。「全文日本語」と明記。 -
PR 説明文ドラフトを丸ごと貼ったらレビュアーに見抜かれた
一文一文が綺麗すぎた。今は Claude のドラフトを下敷きに、私の言葉に書き直してから貼る。これ大事。 -
「✅ 問題なし」と書かれていても、たまに問題ある
信用しすぎない。私は最低でも「デバッグ残骸」と「不要な変更」の2項目だけは自分の目で diff を眺めるようにしている。完全自動化はしない。
まとめ
- 私はセルフレビューの30分を、
/selfreviewの3分に置き換えた - スキャンは Claude、取捨選択は私、という分担にした
-
.claude/commands/selfreview.mdをコピペすれば今日から動く - AI レビューを「補助」ではなく「主担当」に格上げするのが私の立場
- ただし最終判断は絶対に人間、ここは譲らない
3週間運用して、レビュー差し戻し回数が体感で半分以下。何より、私が PR を出す前の心理的なハードルがガクッと下がった。これが一番うれしい。
みなさんはセルフレビュー、どう運用していますか? 「うちはこういうテンプレ使ってる」とか「いや、AI に任せるのは怖い」とか、コメントで教えてください。特に「Claude の指摘を全部採用しないルール」を運用している方の知見、聞きたいです。
Claude Cowork を社内AXの相棒として毎日使っているエンジニアの実践ログです。
シリーズ: Claude Cowork で社内AXを回す