【ITニュース解説】Don't Let Claude Review Claude's Code. Models That Think Alike Make the Same Mistakes

AIがコードを生成する能力は日々進化し、今ではAIが書いたコードを別のAIがレビューするという場面も増えてきた。しかし、この記事は、AIによるコードレビューに潜む重要な落とし穴について警告している。それは、「もしコードを書いたAIと、それをレビューするAIが同じ種類のモデルだった場合、同じような間違いを見逃してしまう可能性がある」というものだ。システムエンジニアを目指す上で、AIツールを効果的に活用するためには、この指摘の核心を理解することが不可欠だ。

まず、記事は「Don't Let Claude Review Claude's Code. Models That Think Alike Make the Same Mistakes（ClaudeにClaudeのコードをレビューさせるな。同じ考え方をするモデルは同じ間違いをする）」というタイトルが示すように、この問題の根源に触れる。ある研究では、QwenというAIモデルが、同じQwenファミリーの別のモデルが生成した回答を、Llamaという異なる種類のAIモデルの回答よりも「正しい」と評価する傾向があることを示している。これは、たとえLlamaの方が客観的に見て正答率が高かったとしてもだ。この傾向は、「AIの評価者（ジャッジ）は、自分とより似たモデルに好意的な評価を下しやすい」という発見を裏付けている。つまり、AIが人間のように「好み」や「偏見」を持つ可能性があるということだ。

この現象をより詳しく分析するために、「CAPA（Chance Adjusted Probabilistic Agreement）」という新しい指標が導入されている。これは、二つのAIモデルが、偶然の一致を除いて、どれだけ同じ種類の間違いを犯すかを測定するものだ。もし二つのモデルが異なる種類の誤りを犯した場合、それは「不一致」と見なされる。このCAPAという指標を使って分析すると、AIは自分と似たモデルに有利な評価を与えがちであること、さらに驚くべきことに、AIモデルの能力が向上するにつれて、異なるベンダーのモデル同士でさえ、その間違いのパターンがより類似してくる傾向があるという。これは、「モデルの能力が上がるにつれて、その間違いもより類似してきており、相関した失敗のリスクを示唆している」と述べられている。

これらの研究結果は、AIによるコードレビューにどのような影響をもたらすのだろうか。もしコードを書いたAIと、そのコードをレビューするAIが同じような思考パターンや「盲点」を持っていたとしたら、レビュアーのAIは、コードの書き手が犯した論理的なバグや設計上の欠陥を、正しいコードであると誤って判断してしまう可能性がある。これは、二人の人間が同じ種類の眼鏡をかけて、同じものを見落としてしまうような状況だ。

他の研究もこの見解を補強している。例えば、GPT-4やLlama 2といったAIモデルが、自分自身が生成したテキストを他のテキストと区別できること、そして自身の生成したテキストをより高く評価する傾向があることが示された論文がある。また、AIが自分の書いたコードを自分で修正する「自己修復」に関する研究では、その効果は限定的だった。人間がAIのコードに対してフィードバックを与えた場合、修正が成功する割合が大幅に向上したのだ。これは、AIが自分のコードのどこに問題があるのかを正確に認識するのが難しいということを示唆している。つまり、コードを書くAIと、それをレビューするAIが同じファミリーのモデルである場合、同じ訓練データや学習方法から生じる共通の「癖」や「理解不足」、あるいは「スタイル」の好みが、間違った理由での「合意」を生み出しやすくなる。コードを書いたAIが「このリストは決して空にならない」という前提でプログラムを組んだ場合、同じ前提を持つレビューAIは、その前提を疑う理由を見つけられないのだ。

では、この問題に対する効果的な対策は何だろうか。記事が推奨するのは、「異なるベンダーのAIエージェントを組み合わせ、最終的には人間が確認する」というアプローチだ。具体的な手順は次のようになる。 まず、一つのAIエージェント、例えばClaude Codeに、特定の機能のコードを書かせる。このコードは、専用のブランチで管理する。 次に、異なるベンダーのAIエージェント、例えばCodexに、その書かれたコードのレビューを依頼する。Codexには、コードを直接編集せず、変更点に対する「発見事項」だけを報告するように指示する。 そして最も重要なのが、人間であるあなたが、Codexが報告したレビュー結果と、実際のコードの変更点（diff）を読み、どの指摘をコードの書き手であるClaude Codeに戻すかを判断することだ。

このようなクロスベンダーでのレビューを実践するには、Codexの/reviewコマンドのようなツールが役立つ。例えば、レビュー対象のコードをgit diff main...hermes/add-refund-endpointのように指定し、「ファイルを編集するな。バグをファイル名と行番号で、最も深刻なものからリストアップし、それぞれのバグを再現する入力例を挙げろ。スタイルのコメントはスキップしろ」といった具体的な指示を与えることができる。ここでmain...hermes/add-refund-endpointのように三点リーダーを使うことで、現在のブランチがmainから分岐した時点からの変更点だけをレビュー対象とすることができる。

最終的に人間がレビューするステップは、決して省略してはならない。AIモデルの能力が向上するにつれて、異なるベンダーのモデル間でも間違いのパターンが似てくる傾向があるため、単に異なるAIを組み合わせただけでは、十分な多様性が得られない可能性もあるからだ。AIレビューアが指摘した箇所は、人間がコードを詳しく見るべき「注目すべき点」のリストとして扱い、決してレビューアの言葉を鵜呑みにしてはいけない。あなたは依然として、コードそのものを読む必要があるのだ。

もちろん、すべてのレビューに異なるベンダーのAIを使う必要があるわけではない。例えば、ファイルが途中で編集されたままになっている、テストが実行されていない、あるいは「TODO」コメントが残ったままになっているといった、コードの書き手がどのような前提を持っていたかに関わらず発生する単純なミスは、同じAIによるレビューでも検出可能だ。これらは、リンターや型チェッカーのような既存のツールでも、ある程度自動的に検出できる。しかし、論理的なバグ、境界条件の扱い、エラー処理、並行処理といった、システムがどのように振る舞うべきかという「設計思想」や「信念」に関わる複雑な問題では、異なる視点を持つレビューアが不可欠となる。同じAIが書いたコードを同じAIがレビューした場合、まさにこのような「共有された間違い」が見過ごされやすいのだ。

AIはシステム開発において強力なツールであり、多くの段階で大きな助けとなる。しかし、その限界と特性を深く理解し、特にクリティカルな部分では、異なる視点（異なるAIエージェント）を組み合わせ、最終的には人間の判断を介入させることが、高品質なシステムを構築し、潜在的なリスクを低減するために不可欠だ。AIを効果的に使うには、AIを過信せず、その能力を賢く利用する姿勢が求められる。