【ITニュース解説】Code Review Was Never Mostly About Bugs. With Agents, It's How You Learn Your Own Code

今日のソフトウェア開発において、AIエージェントによるコード生成は急速に広まっている。この変化は、ソフトウェアの品質を保ち、知識を共有するための重要な工程である「コードレビュー」のあり方を根本から問い直している。これまでコードレビューは、プログラムの欠陥（バグ）を見つけることが主な目的だと考えられがちだったが、実はその本質は別のところにあったことが、長年の研究によって明らかになっている。

例えば、2013年にMicrosoftで行われた研究では、開発者やマネージャーの多くがコードレビューの最大の理由として欠陥発見を挙げた。しかし、実際にレビューコメントの内容を分析してみると、最も多かったのは「コードの改善」に関する指摘（可読性、一貫性、不要なコードの削除など）であり、次に多かったのは「コードや変更内容の理解を深めるための質問と回答」だった。欠陥の指摘は全体のコメントの約14%に過ぎず、そのほとんども小さな論理的な問題だった。この研究は、「コードと変更の理解がコードレビューの鍵となる側面である」と結論付けている。レビュー担当者はコードを学ぶためにレビューを行い、そのプロセスを通じてコードベース全体への理解を深めていたのだ。

同様に、2018年にGoogleで行われた研究でも、コードレビューの導入目的は「他の開発者が理解できるコードを書かせること」や、「複数の開発者が各コードに精通していることを保証すること」にあったとされている。Googleの開発者たちは、コードレビューに「教育」「開発規範の維持」「品質ゲート」「事故防止」という四つの役割を期待しており、欠陥の発見は歓迎されるが唯一の焦点ではないと述べている。これらの研究結果は、企業の規模やデータは異なっても、「コードレビューがバグを捕らえる一方で、主にその変更を理解する開発者を一人増やす」という同じ結論に達している。

このような「理解を深める」というコードレビューの役割は、AIエージェントがコードを書くようになったことで大きな課題に直面している。従来のコードレビューでは、コードを書いた人間がそのコードを理解していることを前提とし、レビューする人間が二人目の理解者となる。しかし、AIエージェントがコードを生成した場合、そのエージェントの「思考プロセス」はセッションが終われば失われてしまう。プロンプトを入力した人間は一部しか読んでいない可能性があり、結果として、レビュー担当者がその変更内容を「初めて全体を読む人間」となり、そして多くの場合「最後に全体を読む人間」となってしまう。

AIの導入は開発の生産性を向上させる一方で、新たな問題も生み出している。ある調査によると、AIを積極的に利用するチームでは、プルリクエストの統合頻度が98%増加し、平均的なプルリクエストのサイズも154%増大しているという。しかし、レビュー時間は91%しか増えておらず、同じ数のレビュー担当者が、より多くの、より大きな差分を処理しなければならなくなっている。このような状況では、テストがすべてグリーンであれば承認するという「近道」が取られやすくなる。その結果、「理解負債」という問題が深刻化する。「理解負債」とは、システム内に存在するコードの量と、それを人間が真に理解している量の間に生じるギャップのことである。開発者が十分に理解しないまま承認したコードは、暗黙の承認を得たことになり、将来的なトラブルの原因となりかねない。

理解と学習の側面からも、AIに全面的に依存することの危険性が指摘されている。2026年1月に出版されたAnthropicの無作為化試験では、AIの助けなしにコードを書いたグループの方が、AIに完全に作業を任せたグループよりも、新しいPythonライブラリに関する理解度テストで高いスコアを出した。しかし、AIが生成したコードを読み、それについてフォローアップの質問をした参加者たちは、最も高い理解度を示した。これは、AIの出力そのものを鵜呑みにするのではなく、能動的に読み解き、疑問を投げかけるプロセスが理解を深める上で重要であることを示唆している。AIエージェントは人間が読むよりも速くコードを生成するため、未読のコードが積み重なり、それが「理解負債」となっていくのだ。

コードレビューの主な成果が「理解」であるならば、そのやり方を変える必要がある。まず、AIエージェントがコードを生成したプロセスを「ターン・バイ・ターン」（段階的に）追うことが推奨される。AIはコードを書き、テストを実行し、修正するというサイクルを繰り返すため、git log -p --reverse main..agent/fix-retry のように、AIが変更を加えた順番で差分を見ることで、その思考プロセスをたどることができる。

次に、承認する前にAIエージェントに直接質問を投げかけるべきである。AIがまだセッション中にいる間に、「なぜこのアプローチを選んだのか」「他にどんな選択肢を検討したのか」「もし間違っていたら、何が最初に失敗するか」といった質問をすることで、Anthropicの研究で示されたような「生成されたものを読み、質問する」という効果的な学習パターンをコードレビューに応用できる。

また、AIが生成するプルリクエストのサイズは、人間が理解できる程度に小さく保つことが重要である。Googleのプロセスが小さな変更に焦点を当てているように、人間にとって不慣れなコードであるAI生成コードは、特に小さくすることでレビューの負担を軽減できる。

さらに、プルリクエストに「人間による説明」を含めるべきである。GitHubのプルリクエストテンプレートを活用し、AIが生成したプルリクエストであっても、「変更の概要（2文で）」「このアプローチを選んだ理由（AIに質問し、確認する）」「間違いがあった場合に最初に失敗する箇所」「この変更を他に誰が読んだか」といった項目を人間が記入する。レビュー担当者も、自分の言葉で変更内容を要約できるまで承認しないというルールを設けることで、理解を強制できる。

コードの可読性や一貫性などの低レベルな改善点は、2013年のMicrosoftの研究でも自動化が推奨されていたように、リンターやAIレビューツールに任せるべきだ。これにより、人間はより深い設計上の問題や潜在的な欠陥に集中できる。しかし、これらのツールは「チームメイトの頭の中に理解を生み出す」ことはできない。

コードレビューの評価指標も変えるべきである。「レビューによって発見されたバグの数」は、レビューの真の目的を反映していない。Microsoftのデータが示すように、欠陥発見はレビューの主な成果ではなかった。レビューコメントがゼロのAI生成プルリクエストは、完璧な変更かもしれないし、誰も読んでいない変更かもしれない。その違いをバグ数で判断することはできない。

代わりに、レビューが本来の目的である「理解」に貢献しているかを測るべきである。例えば、週に一度、ランダムに選んだマージ済みのAI生成プルリクエストについて、承認者が差分を開かずに2分間でその内容を説明できるかテストする。何をするコードで、どこが最初に壊れるかを説明できるかを確認し、「はい」「部分的」「いいえ」で評価する。「いいえ」という回答が続くようであれば、そのチームは誰も説明できないコードを蓄積していることになり、テストがグリーンであっても潜在的なリスクを抱えていることになる。また、コードを理解する人間を増やすため、承認者をローテーションさせることも重要である。

著者のプロジェクトであるHermes IDEは、このような新しいレビュー習慣をサポートするために開発されている。Hermes IDEでは、AIエージェントの各作業ターンが保存され、その変更内容を差分として確認できる。また、レビューデスクを通じて、コードの特定の行に対するコメントを、その行を生成したエージェントに直接質問として送ることが可能だ。これにより、AIがどのようにコードを生成したかを深く理解し、疑問点を解消しながらレビューを進めることができる。

AIによるコード生成が常識となりつつある今、チームがコードレビューで何を評価し、何を目標とするかは極めて重要だ。最後に、あなたのチームがAI生成コードをレビューする際に何を基準にしているか、そして直近で承認したコードについて、承認者が今、その差分を開かずに説明できるかを問い直してみてほしい。それは、システム設計の面接で求められるような、書かれていない変更とそのトレードオフを声に出して説明する能力と密接に結びついている。