【ITニュース解説】An AI code reviewer that remembers its findings still needs a stop condition

システム開発の現場では、プログラマーが書いたコードが期待通りに動くか、品質が保たれているかを確認するため、他の人がコードをチェックする「コードレビュー」という重要な工程がある。最近では、このコードレビューの一部をAI（人工知能）に任せる動きも活発になっているが、AIがコードレビューを行う際に、人間が気づきにくい特有の課題が明らかになっている。

AIによる自動コードレビューは、一見すると生産的に見えるものの、実際には終わりのないループに陥ってしまうことがある。具体的には、まずAIがコードの中に3つの問題点を見つけたとしよう。その報告を受けて、開発者がそのうちの2つを修正し、関連する部分も変更を加える。ところが、次にAIが再度レビューを行うと、以前指摘した問題が1つまだ残っていることに加え、新たに2つの問題を見つけてしまうのだ。そして、この「AIが指摘→開発者が修正→AIが再び指摘」という繰り返しが延々と続き、最終的には人間が諦めてしまうまで続いてしまうことがある。この問題は、単にAIの性能が完璧でないというだけではなく、このレビューの繰り返しサイクルに「どこで終わるべきか」という明確な終了条件が設定されていないことに根本的な原因がある。

このようなAIコードレビューの特有の課題を解決するため、「レビューランナー」というツールが開発された。このツールは、AIが無限ループに陥る問題を可視化し、その動きに明確な境界線を設けることを目的としている。このレビューランナーは、コードが変更されるたびに自動的にレビューを行うものではなく、開発者が自分のパソコン上で動かすローカルなツールとして機能する。つまり、会社全体で利用するような大きなシステムや、コードの公開を制限するゲートのような役割ではなく、個々の開発者がコードの品質を高めるために活用する補助的な役割を果たす。レビューランナーの主な役割は、AIが見つけた具体的な指摘事項を次のレビューに引き継ぎ、開発者が行った修正がそれらの指摘を正しく解決したかどうかを確認することにある。そして、もしAIによる自動レビューの試行回数に上限が設けられていて、その上限に達してしまった場合でも、無駄にAIの計算資源を使い続けるのではなく、それまでのレビュー過程で得られた情報を人間が判断するための証拠として提供する。

レビューランナーの最も重要な機能の一つは、過去のレビューでAIが見つけた指摘事項を「記憶」することだ。もしAIが前回のレビュー内容を忘れてしまい、毎回ゼロからレビューをやり直すとしたら、同じ問題が何度も指摘されることになり、非常に非効率的だ。だから、レビューランナーは最初のレビューで見つかった問題を記録し、次のレビューの際にその情報を引き継いで活用する。もちろん、もしプログラムの変更内容が大きく変わったり、レビュー対象の範囲が変わったりした場合には、過去の情報をそのまま引き継ぐのではなく、改めて初期状態からレビューをやり直す。しかし、入力されたコードが全く同じであれば、AIに再度計算をさせることなく、前回の結果を再利用することで、計算コストを節約する仕組みになっている。このように過去の情報を記憶することで、AIは「この前指摘したこの問題はちゃんと修正されたかな？」という、より具体的な問いかけを次のレビューで行うことができるようになる。これにより、漠然と「この変更全体をもう一度見てください」とAIに丸投げするのではなく、レビューがより的を絞った有益なものになる。

レビューランナーでは、AIによる自動レビューの試行回数に上限を設ける。例えば、この記事では「3回」という回数が例として挙げられているが、これはあくまでも現実的な安全策として選ばれたものであり、どんなコードにもこの回数が最適だという魔法の数字ではない。この回数制限の目的は、AIが際限なくレビューを繰り返し、小さな問題が無限に続くプロセスになってしまうのを防ぐことにある。上限に達したからといって、すぐにそのコードが危険な状態にあるというわけではないし、逆に上限に達しなかったからといって、そのコードが完全に安全だという保証もない。この制限は、AIによる自動レビューが、これ以上計算資源を使ってレビューを続けるよりも、これまでの結果をまとめて人間に引き継ぎ、最終的な判断を求めるべき時期に達したことを意味する。上限に達した場合、レビューランナーは「人間の判断に委ねます」という明確な結果を返す。この結果には、最初のレビューで見つかった問題点、最新のレビュー結果、そしてコードがどのように変化したのかを示すための具体的な証拠が含まれる。しかし、レビューランナーが勝手にコードを「承認」したり、他のコードと「結合」したり、勝手に変更を「公開」したりすることはない。最終的な判断はあくまで人間が行うという点が重要だ。

AIによるコードレビューにおいて、試行回数の制限だけでは解決できない難しい問題が一つある。それは「スコープ」、つまり「このプログラムの変更が本来何を目的としているのか」という範囲の定義だ。例えば、AIがコードの問題点を見つけたとしても、それが現在の変更の目的とは全く関係のない部分の問題だった場合、それを指摘し続けるのは効率的ではない。レビューアは、そのコード変更が具体的にどのような範囲の作業を意図しているのか、その定義を知る必要がある。筆者は、このスコープを定義するために、恒久的な文書を毎回作成したり、すべてのプログラム変更について人間が承認するステップを設けたりすることは避けたいと考えている。そこで現在試みているのは、より効率的な方法だ。具体的には、プログラマーが変更内容を説明する文章、関連する課題管理システムのチケット、実際のコードの差分、そしてテストコードなどから、暫定的なスコープをAIが自動的に推測する。そして、AIが見つけた指摘事項は、そのスコープに合致する関連性を示す証拠を必ず提示することを求める。もし、AIが指摘した問題が、その証拠を伴っていなかったり、スコープとの関連性が不明確だったりする場合には、レビューを「詳細が不足している」とマークし、AIが勝手にレビューの範囲を広げないようにする。このようにして、曖昧な指示や不適切に定義された作業に対しては、先述の試行回数制限が最終的な安全弁として機能するようにするのだ。ただし、このスコープの問題はまだ完全に解決されたわけではない。もしAI自身がスコープを定義し、その定義に基づいて自分のレビュー結果を判断すると、本来防ぎたかったはずのレビュー範囲の無制限な拡大を、AI自身が合理化してしまう可能性もある。どの程度の独立した証拠があれば、AIの指摘が意味のあるものとしてレビューのループに留まるべきか、という設計上の課題は今も続いている。

このレビューランナーは、先ほども述べたように独立した機能であり、レビュー対象のコードが保存されているリポジトリとは別の、信頼されたローカル環境で動かすことができる。具体的には、環境変数に利用するAIモデルの名前を設定し、専用のスクリプトを実行するだけで簡単に利用できる。例えば、特定のプログラム変更に対して「自動的にレビューを実行する」コマンドや、「現在のレビューの状況を確認する」コマンドがある。レビューランナーには、デフォルトで1800秒（30分）という実行時間の制限が設けられている。もし、この時間制限を超えたり、途中で処理が中断されたり、停止の指示が出されたりした場合でも、その時点で得られた結果は失われることなく保存される仕組みになっている。また、ステータスを確認するだけの目的であれば、AIに新たな計算をさせることなく、これまでの結果をすぐに読み出すことが可能だ。

最終的に重要なのは、単に「3回」という数字そのものではない。AIによるコードレビューのプロセスに責任を持たせること、それが最も重要な点だ。具体的には、AIがレビューを繰り返すたびに、以前見つけた問題点全てを解決するか、あるいは新しい、意味のある証拠を提示するか、そうでなければ停止して、なぜこれ以上判断できないのかを明確に人間に伝えるべきだという考え方が根底にある。このツールは、プログラマーがより効率的に、より高品質なコードを生み出すための強力な味方となるだろう。