1. AIレビューは強い。それでもコードベースは腐る
最近のコードレビューAIは、もう lint の延長ではありません。少なくとも私の感覚では、実装上の局所的な correctness に関しては、すでに人間のレビューより鋭い場面があります。race condition や deadlock のように、静的解析のルールに単純には落ちない問題でも、コードの因果関係を追いながら「どう壊れるか」をかなり具体的に指摘してきます。
私は Codex のマルチエージェントモードを使って、worker が実装し、reviewer がセルフレビューするワークフローでアプリを作る実験をしました。結果はかなり面白かったです。レビューは実際に役に立ちました。バグを事前に見つけたり、設計との不整合を見つけたり、危ない変更を止めたりするには十分に有効でした。
ただ、それでもコードベース全体の品質は時間とともに落ちていきました。
ファイルは肥大化し、ディレクトリは散らかり、コピーされて削除されない重複コードが増え、後方互換性を維持するためのビジネスロジックは複雑化していきます。
テストも増えるのですが、その多くは回帰防止の資産というより、その場のバグに絆創膏を貼るようなパッチワーク的なものになりやすいです。
結果として、機能追加あたりの修正コードは増え続け、生産性は落ちていきました。
ここでの問いは単純です。なぜレビューが効いているのに、コードベースは腐るのか。
2. Codexのレビューは何を最適化しているのか
この問いを考えるには、まずコードレビューAIがそもそもどう設計されているかを見る必要があります。
Codex CLIのレビュー用のシステムプロンプト review_prompt.md には以下のように書かれています。(2026/03/22時点)
1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.
2. The bug is discrete and actionable (i.e. not a general issue with the codebase or a combination of multiple issues).
3. Fixing the bug does not demand a level of rigor that is not present in the rest of the codebase (e.g. one doesn't need very detailed comments and input validation in a repository of one-off scripts in personal projects)
4. The bug was introduced in the commit (pre-existing bugs should not be flagged).
5. The author of the original PR would likely fix the issue if they were made aware of it.
6. The bug does not rely on unstated assumptions about the codebase or author's intent.
7. It is not enough to speculate that a change may disrupt another part of the codebase, to be considered a bug, one must identify the other parts of the code that are provably affected.
8. The bug is clearly not just an intentional change by the original author.
日本語訳
1. コードの正確性、パフォーマンス、セキュリティ、または保守性に意味のある影響を与える。
2. バグが離散的かつ対処可能である（コードベース全体に関わる一般的な問題や、複数の問題の組み合わせではない）。
3. バグの修正が、コードベースの他の部分に存在しない水準の厳密さを要求しない（例：個人プロジェクトの使い捨てスクリプト集で、詳細なコメントや入力バリデーションを要求しない）。
4. バグがそのコミットで導入されたものである（既存のバグは指摘しない）。
5. 元のPR作者が問題を知っていれば、修正する可能性が高い。
6. バグがコードベースや作者の意図に関する不明示の仮定に依存していない。
7. 変更がコードベースの別の部分を壊す可能性があるという推測だけでは不十分であり、バグとして扱うには、影響を受けることが証明できるコードの他の部分を特定しなければならない。
8. バグが元の作者による意図的な変更でないことが明らかである。
ここからわかるのは、AIによるコードレビューは主にバグを見つけるためのものであり、そのバグは「今回の変更で導入された、離散的で、修正可能で、影響をコード上で具体的に示せる問題」であることが求められている、ということです。さらに、レビューは「コードについて自由に意見を述べる相手」として設計されているのではなく、むしろ差分から修正価値の高い不具合を抽出する装置として設計されている、ということもわかります。
3. セルフレビュー開発で実際に起きたこと
この設計が実運用でどう見えるかは、自分の実験ではかなりはっきり出ました。worker が機能を実装し、reviewer が差分をレビューし、その指摘を受けて修正します。
局所的な品質はたしかに上がります。危険な変更は減りますし、設計と実装のズレも早めに露出します。
とくに、複数箇所にまたがる挙動の破綻や、条件分岐の端でだけ起きるような不具合候補を拾う精度は高かったです。
でも、コードベース全体を見ると別のことが起きます。個々の変更は安全になっても、全体の構造は少しずつ濁っていきます。
ファイルが大きくなっても、その場ではレビューを通ります。責務が曖昧なモジュールが増えても、そのコミット単体では合理的に見えます。互換レイヤが一枚増えても、その時点では既存挙動を壊さないので正しいです。
テストが一つ追加されても、それ自体は「改善」に見えます。
つまり問題は、レビューが失敗していることではありません。レビューが成功しているのに、その成功の積み重ねが長期的な劣化を止めないことにあります。
4. なぜ安全な変更の積み重ねがコードを腐らせるのか
ここで重要なのは、AIが何に対して報酬を受け取っているように振る舞うかです。差分単位のレビューでは、短期的な安全性と既存挙動の維持が非常に強い成功条件になります。テストを壊さないこと、既存 API を壊さないこと、今の利用者に影響を出さないこと。その条件に忠実であるほど、破壊的な再構成よりも、ラッパー追加・条件分岐追加・互換レイヤ追加のような増築的な修正が選ばれやすくなります。
これは AI が臆病だからではありません。むしろ局所的な成功条件に忠実だからそうなります。破壊的変更は短期的なリスクが高いですし、レビューも通しにくいです。対してパッチワーク的な修正は、そのコミットだけ見れば筋が通っています。だから AI は後方互換性を維持しながら既存構造を延命する方向に流れやすいです。
しかしコードベースは、悪い変更だけで腐るわけではありません。壊さないことを優先しすぎることでも腐ります。 各コミットは妥当でも、その累積として重複、分岐、互換レイヤ、例外処理、補助テストが堆積し、全体の変更容易性が下がっていきます。ここに、個々のレビューでは見えにくい大きな論点があります。
5. 品質ゲートは有効だが万能ではない
もちろん、この問題に対しては対策も打てます。
コミットを小さくすればレビューはしやすくなりますし、lizard のようなツールで NLOC や CCN に品質ゲートを置けば、明らかな肥大化をある程度は防げます。少なくとも「巨大関数が何本も生え続ける」みたいな劣化には効きます。
ただ、固定のルールセットで抑えられるのは、ルールとして表現できた劣化だけです。
ファイル長に制限をかければ、今度は責務の薄いファイルが乱立するかもしれません。CCN を抑えれば、分岐は減っても重複コードが増えるかもしれません。
巨大ファイルは減っても、ディレクトリ直下のソースコード数が増え、探索コストが上がるかもしれません。
テスト本数は増えても、テスト体系そのものはむしろ見えにくくなるかもしれません。
問題を見つけるたびにルールを追加することはできます。でもそれは本質的にはイタチごっこです。ルールは腐敗をなくすのではなく、腐敗の形を変えます。 定量監視は必要ですが、それ自体が品質観ではありません。
6. 人間に残る責務、AIに委ねる責務、共同で持つ責務
コードを長期的に保守するためには、現状のコードレビューAIだけでは不十分です。人間はまだまだコードを読む必要があります。ただし、これまでのようにバグや修正漏れを見つけるために読む部分はAIにかなり委ねられます。人間は、コードの意味と構造の変化を判断するために読む部分を残すことになります。
AIに委ねるべき責務
- 差分単位の不具合検出
- 回帰リスクと影響範囲の洗い出し
- テスト観点の提案
この三つは、差分ベースで評価しやすく、根拠をコード上に落とし込みやすいです。AIは広く、速く、しかもかなり深く見られます。とくに「どう壊れるか」を具体化できる問題では強いです。
人間に残すべき責務
- 設計方針の最終判断
- 破壊的変更の可否判断
- 長期的な構造品質の監督
ここで必要なのは、コードそのものよりも、時間軸と文脈です。互換性をまだ守るべきか。今は増築で耐えるべきか、それとも壊して組み直すべきか。どこまで壊してよいかを決める力は、人間側に残ります。
共同で持つべき責務
- リファクタリング候補の特定
- セキュリティなど高リスク箇所の重点レビュー
- テスト体系の見直し
この領域は、AIだけでも人間だけでも精度が落ちます。
AIは候補を広く洗い出せます。セキュリティのような高リスク箇所も、危ない場所を列挙するところまではかなり任せられます。
でも、そのリスクをどう評価するか、いま触るべきか、どこまで壊してよいか、どのテストを資産として残すかは人間が判断しないといけません。AIが危険箇所を見つけ、人間がそれをどう扱うかを決めます。この分業がたぶんいちばん現実的です。
言い換えると、AIは壊さずに直すのが得意で、人間は壊して作り直す境界を決められます。ここが、今後も人がコードを読む理由になります。
この役割分担が整理できると、問われるべき問いも変わります。AIがレビューできるかどうかではなく、レビューという仕事をどう分解し、どの責務をAIに委ね、どの責務を人間に残すか。コードレビューAIが強くなるほど、人間の役割は「全部読む人」ではなく、変更の意味と、構造劣化の方向を判断する人へ寄っていきます。局所的な不具合検出や回帰リスクの洗い出しはAIへかなり委ねられる一方で、どこを壊してよいか、何を捨て、何を作り直すべきかを判断する役割は人間に残り続けます。
7. まとめ
この記事では、AIコードレビューが強力である一方で、コードベースの長期的な品質を保つためにはまだ人がコードを読む必要がある理由を考察しました。
- AIによるコードレビューは差分単位の不具合検出や回帰リスクの洗い出しなど、局所的な問題に対して非常に有効です。
- 一方で、コードベース全体の品質や、「そもそも解くべき問題が違う」ような破壊的な指摘はAIレビューでは見つけにくいです。
- そのため、バグを見つける役割はAIに任せつつ、コードの意味と構造の変化を判断する役割は人間に残す、という分業が現実的です。