Claude に「敵対的レビュー」をさせて、指摘がどれくらい当たっていたかを数えた
- Claude Code
- コードレビュー
- 個人開発
個人開発では、コードを見てくれる人がいません。そこで Claude Code に「このコードの壊れるところを探して」と頼むレビューを、よく使っています。褒めずに粗を探させるので、ここでは 敵対的レビュー と呼んでいます。
ただ、AI のレビュー指摘はそのまま信じられません。それっぽいけれど外れている指摘が混ざるからです。そこで、指摘をもう一度確かめる「再検証」までをセットにしてきました。
その記録が、各リポジトリの git 履歴と PROGRESS.md（進捗メモ）に残っていました。指摘がどれくらい当たっていたのかを数えてみます。
環境：Windows 10 / Claude Code（Opus・Sonnet）／2026年7月〜10月の個人開発リポジトリ
レビューの頼み方
やり方はだいたい次の形です。
- 観点を分けて、サブエージェントに並行で頼む。たとえば Windows アプリでは「キーボードフック周り」「音声処理」「フォルダ構成・読みやすさ」の3つに分けました
- 「壊れる可能性」に絞らせる。良いところの説明は要らない、と伝えます
- 出てきた指摘を、別の Claude に再検証させる。「先のレビューの結論を鵜呑みにせず、該当するコードを実際に読んで確かめて」と頼みます
- 再検証の結果を
PROGRESS.mdに残す。外れた指摘も消さずに、「検証：〜」と訂正を書き足します
3 の再検証が、この記事の材料です。
数えてみた
git 履歴をレビュー・指摘・偽陽性などの言葉で探すと、8リポジトリで40件ほどのコミットが見つかりました。そのうち、指摘を再検証して、結果を数として残していたもの は次の5回です。
| レビュー | 指摘 | 完全に外れ | 重さや範囲が言いすぎ | 判断が要る |
|---|---|---|---|---|
| Web アプリ全体（Node.js） | 18件 | 0件 | 4件 | — |
| Windows アプリ（C#、3観点並行） | 約13件 | 1件 | 2件 | — |
| 画像生成サービス（コードレビュー） | 11件 | 2件 | — | — |
| 画像生成サービス（全体監査） | 38件 | 1件 | 4件 | 3件 |
| Windows アプリ（/code-review と /simplify の計5回） | — | 1件 | 1件 | — |
まとめると、完全な外れは各回0〜2件で、思っていたより少なめでした。多かったのは、指摘そのものは事実だけれど「重さ」「影響範囲」を言いすぎているものです。
完全に外れていた指摘
- 「〜という注意コメントを足すべき」：そのコメントはすでにファイルに書いてありました
- 「ワーカーへの同時アクセスで競合する」：本番は同時実行数1・インスタンス1台に絞ってあり、競合は起こりません
- 「ワーカーに認証なしでアクセスできる」：IAM で呼び出し元を絞っていて、認証なしは 403 になることを確かめました
- 「モデルのライセンス表記が古い」：表記はすでに直っていました
- 5つのレビューが一致して勧めた書き換え：その書き換えに使うメソッドが、ライブラリに存在しませんでした。ビルドが通らないので却下です
最後の例は印象に残っています。5回のレビューが全員同じことを言っても、正しいとは限りません。同じ思い込みを5回繰り返しただけでした。
言いすぎていた指摘
- 「境界値のチェックが全くない」→ 実際は1か所だけ漏れていた：Q 値やゲインはすでに範囲を制限していて、漏れていたのは EQ の周波数の上限だけでした。「優先度A」から「この3行を直すだけ」に縮みました
- 「例外処理がないのでフックチェーンが壊れる」→ 壊れる経路はない：コールバックの先頭で次のフックを必ず呼んでいました。ログを足す程度の「優先度B」に下げました
- 「色のテーブル（256色）の変換を直すべき」→ 1回しか動かない：静的な初期化なので、変換は型の初期化時に1回だけでした。対応不要としました
- 「依存パッケージに high の脆弱性が4件」→ 件数は正しいが、悪用の条件が揃わない：ReDoS はルートにパラメータがあるときだけ成立し、このアプリにはありませんでした
- 「不要なファイルがコンテナイメージに入る」→ 一部だけ：ビルドは git のチェックアウトから行うので、未追跡のファイルは入りません。入るのはテストや docs だけで、「イメージが少し太る」程度でした
- 「JWT の検証でアルゴリズムを指定していない」→ 実害なし：使っているライブラリは、対称鍵だと HS 系しか受け付けません。「低・堅牢化」に下げました
- 行番号の誤り：重複の指摘自体は正しく、場所がずれていました
「判断が要る」に変わった指摘
全体監査では、3件が「バグ」から「要ユーザー判断」に書き換わりました。たとえば「出題で2軸の差のペアがほとんど出ない」という指摘は、実は「差の大きいペアから試す」という意図した設計の結果でした。直すかどうかはコードの正しさではなく、方針の問題です。
AI は、意図した設計と不具合の区別がつきません。ここは人が決めるしかありません。
外れ方の型
外れた指摘を並べると、型がありました。
- 「〜がない」という指摘が、実はある。一番多い外れ方です。メソッド名や設計から「たぶんない」と推測して、実際のコードを読んでいません
- 本番の設定を知らない。同時実行数、IAM、ビルドの仕組みなど、コードの外にある条件で実害が消えるパターンです
- 重さを最大に見積もる。悪用の条件や発生頻度を考えずに「高」を付けます
- 存在しない API を勧める。ビルドすればすぐに分かります
Windows アプリのレビューでは、再検証のあとに Claude がこう書き残していました。
「境界値／例外処理が無い」という指摘は、対策コードの有無を実際に grep・通読して確認してから採用すること（メソッド名や設計思想からの類推だけで「無い」と断定しない）
これは、そのまま次のレビューの指示に使えます。
再検証の頼み方
数えてみて、再検証で効いていたのは次のことでした。
- 別の Claude に頼む。レビューした本人に確かめさせると、自分の結論を守りがちです。新しいサブエージェントに「先の指摘を鵜呑みにしないで」と渡します
- 再現させる。「スクリプトで実測する」「
npm auditをもう一度回す」「Playwright で画面を操作して起きるか見る」のように、手を動かして確かめさせます。全体監査では、2件を Playwright で再現できたと追記していました - 「ない」と言われたら grep させる。上の型の1つ目を潰せます
- 本番の設定も渡す。デプロイの設定ファイルや IAM の状態を読める状態にしておくと、型の2つ目が減ります
- 外れた指摘も記録に残す。消さずに「検証：一部偽陽性。理由〜」と書き足しておくと、次に同じ指摘が出たときにすぐ判断できます
敵対的レビューはコード以外にも使える
コードだけでなく、方針にも使っています。
Web アプリで「楽譜表示を外部ライブラリから自作に置き換えるか」を調べたとき、調査のあとに「そもそも置き換える価値があるのか、あえて反対側から考えて」と頼みました。返ってきたのは、こんな指摘です。
- 利用者から見て、今の表示に不具合報告はない。置き換えても見える改善はほぼない
- 楽譜表示を誰が見ているかのデータがない。作る前に計測するべき
- 大譜表にすると高さが増え、スマホで画面が縦に長くなる
結局、自作することにしたのですが、「高さは今より増やさない」という条件はこのレビューから来ています。反対意見を先に聞いておくと、進める場合でも条件がはっきりします（自作の話は別の記事に書きました）。
まとめ
- 5回分の再検証の記録では、完全に外れた指摘は各回0〜2件だった
- 多かったのは「事実だが重さを言いすぎ」の指摘。優先度Aが「3行直すだけ」に縮んだ例もある
- 外れ方の型は「ないと言うが実はある」「本番の設定を知らない」「重さを最大に見積もる」「存在しない API」
- 何回レビューしても、同じ思い込みは繰り返される。5つ一致した提案がビルドできなかった
- 再検証は別の Claude に、grep・再現・本番設定つきで頼み、外れた指摘も記録に残す
参考文献
この記事をシェア