Codexの指摘を30分議論して結局無視した話
Codexにコードレビューを依頼した。
いくつかの指摘が返ってきた。「これは直すべきか？」とClaudeに相談した。
30分議論した結果、出た結論は——
「無視していい」
30分返して。
AIレビューは参考意見であって、福音ではない。プロジェクトの文脈を知っているのは自分だけ。この当たり前のことに気づくのに、30分かかった話をする。
この記事が役立つ方
- AIツールでコードレビューを受けている人
- レビュー指摘を全部直すべきか迷う人
- 「AIが言うなら正しいのでは」と思ってしまう人
- 英語のレビューをそのままClaudeに丸投げしてしまう人
TL;DR
- AIレビューは参考意見であって絶対ではない
- プロジェクトの文脈を知っているのは自分だけ
- 「無視する」も立派な判断
- 英語レビューは理解してから判断する
- 迷ったら「5つの確認プロンプト」を使う
背景: AIレビューツールの得意・苦手
まず、AIレビューツールの特性を整理しておきます。
| ツール | 得意なこと | 苦手なこと |
|---|---|---|
| Codex / OpenAI | 一般的なベストプラクティスの指摘 | プロジェクト固有の事情を考慮した判断 |
| Claude | 文脈を踏まえた議論、設計意図の理解 | 時々自信過剰になる |
| CodeRabbit | PR差分に対する具体的なレビュー | プロジェクト全体の設計把握 |
ポイントは、どのツールも「プロジェクト固有の判断」が苦手ということです。
AIは「一般論としてのベストプラクティス」を知っています。しかし、「このプロジェクトでは、この段階では、このチームでは」という文脈は知りません。
その文脈を知っているのは、開発者である自分だけです。
過剰レビューの実例
実際に「無視していい」と判断した指摘を3つ紹介する。
例1: 過剰な抽象化の提案
Codex: 「この関数は分割すべきです」
言いたいことはわかる。でも、これはMVP開発中のコード。
今この関数を「美しく」分割しても、来週には要件変更で書き直しになるかもしれない。YAGNI（You Ain't Gonna Need It）原則に従って、今必要な分だけ書くのが正解。
過剰な抽象化は、MVP段階では害悪になりうる。
例2: 過剰なエラーハンドリング
Codex: 「エラーハンドリングが不十分です」
確かに本番運用を考えると、もっと細かくエラーを捕捉すべきかもしれない。
でも今はプロトタイプ段階。ユーザーは自分だけ。エラーが起きたらログを見ればいい。
商用化するときに強化すればいい。段階的改善という考え方。
例3: 「ベストプラクティス」の押し付け
Codex: 「このパターンは推奨されません」
一般的には推奨されないかもしれない。でも、このプロジェクトではこれが最適解だった。
AIは「なぜこのパターンを選んだのか」という背景を知らない。だから一般論を言ってくる。それは当然のこと。
英語レビューの落とし穴
Codexは基本的に英語でレビューを返してくる。ここに罠がある。
アンチパターン: コピペ丸投げ
こんなフローに陥っていないだろうか。
Codex: "Consider extracting this logic into a separate utility function
for better reusability and testability."
↓
そのままClaudeにコピペ
「これ直して」
↓
Claudeが修正
↓
何が変わったかよくわからない
↓
またCodexでレビュー
↓
新しい指摘が来る
↓
またコピペ...
↓
無限ループ
これ、あるあるじゃないだろうか。
問題の本質は、開発者が「何を言われているか」を理解していないこと。
理解していないから、必要な修正かどうか判断できない。だから全部丸投げして、全部直そうとする。結果、無限ループにハマる。
対策: 5つの確認プロンプト
英語のレビュー指摘を受けたら、いきなり「直して」と言わない。
まず、レビューしたAIに以下のプロンプトを投げ返す。
このレビュー指摘について確認して:
- 何を言っている？
- この問題は実際に起こる？
- 起こった場合の影響は？
- 現状のコードで本当に問題？
- 修正する場合の工数は？
レビューしたAI自身に確認させることで、指摘の内容と影響を正確に把握できます。
実践例
Codex: "Consider extracting this logic into a separate utility function
for better reusability and testability."
↓ 5つの確認プロンプトをCodexに投げ返す
Codex:
- 何を言っている？
→ このロジックを別のユーティリティ関数に切り出せと言っています
- この問題は実際に起こる？
→ 現時点では問題ありません。将来同じロジックを再利用する場合に
コードの重複が発生する可能性があります
- 起こった場合の影響は？
→ 軽微です。その時点でリファクタリングすれば済みます
- 現状のコードで本当に問題？
→ 動作上の問題はありません。コードの「美しさ」の観点からの提案です
- 修正する場合の工数は？
→ 10〜15分程度です
この回答を見れば、今直す必要があるかどうかを判断できる。
この例なら、「MVP段階では不要。後回し」という判断ができる。
無視すべき指摘の見分け方
判断基準を表にまとめます。
| 従うべき指摘 | 無視していい指摘 |
|---|---|
| セキュリティリスク | 「こうした方がキレイ」系 |
| 明確なバグ | MVP段階での過剰な抽象化 |
| パフォーマンスの問題 | 将来のための「念のため」 |
| 本番で問題になる可能性が高い | 今すぐ必要ない改善 |
迷ったら、以下の3つの質問を自分に投げかけてみてください。
- 今解決すべき問題か？ → NOなら後回し
- ユーザーに影響するか？ → NOなら優先度を下げる
- 直すコストと効果は釣り合うか？ → NOなら無視
30分議論した教訓
あの30分で学んだことをまとめる。
-
AIに相談する前に「本当に迷ってるか」を自問する
- 実は心の中で「直さなくていい」とわかっていた
- それを確認するためだけに30分使った
-
迷ってないなら無視して進む
- 判断に迷うのは、判断基準がないから
- 基準を持っていれば即決できる
-
時間は有限、トークンも有限
- 30分あれば、機能を1つ実装できた
- 無駄な議論に使う時間はない
まとめ
- AIレビューは参考意見。福音ではない
- プロジェクトの文脈を知っているのは自分だけ
- 「無視する」も立派な判断
- 英語レビューは5つの確認プロンプトで理解してから判断
- 30分議論するより「今は無視」が正解のこともある
チェックリスト: AIレビューを受けたら
□ 指摘内容を正確に理解したか？（英語なら翻訳して）
□ セキュリティリスクやバグではないか？
□ 今解決すべき問題か？
□ ユーザーに影響するか？
□ 直すコストと効果は釣り合うか？
□ 「5つの確認プロンプト」で詳細を確認したか？
→ 全部確認した上で「不要」なら、堂々と無視する
関連記事
E2Eテストが通るのに本番で動かない——AIに頼りきりになると、こういう問題も見逃す。
Discussion