8月3日、Wealthfrontが「Experiments with AI Code Review — Engineering Blog」と題した記事を公開した。この記事では、懐疑的な出発点から始まったAIコードレビューの実験が、数年をかけて実運用レベルの仕組みへと進化した経緯について詳しく紹介されている。

「1レビューに$20払う」という発想

多くのAIコードレビューツールが「1回$0.25・2〜3分」を目標にしていた時代、Wealthfrontは逆張りの設計思想を掲げた。良いレビューは価格がつけられないほど価値がある——だから1レビューあたり$20払っても構わないし、15分以上待っても構わない、という考え方だ。

この発想の出発点は偶然のひと言だった。あるポストモーテムの場で、エンジニアがバグが含まれたブランチのdiffをGPT-3.5に貼り付け、「バグをレビューしてほしい」と頼んだ。リファクタリング中に生じたSQLフィルタの漏れ——自動テストも人間のコードレビューも素通りしていたそのバグを、LLMは即座に発見した。

これがきっかけとなり、Wealthfrontは複数年にわたるAIコードレビューの内製化実験を開始した。

失敗した最初のアプローチ

最初の構成は「ドキュメント収集」方式だった。安価なモデルにコードベースをクロールさせ、関連ファイルの一覧を作成。その後、高性能モデルが一発でdiffとドキュメントをレビューするというものだった。

これは機能しなかった。「関連ドキュメントを探せ」という指示はあまりに曖昧で、モデルはすべてを関連ありと判断し、際限なくファイルを掘り続けた。Wealthfrontのコードベースは20を超えるリポジトリ（同社によれば実際は350以上）、2000万行超という規模であり、構造なき探索は破綻する。

最初のリリース：構造化した多段エージェント

試行錯誤の末、最初に実運用に投入したシステムは以下の構成だった：

1. Gemini 2.5 Proがトップレベルのレビュアーとしてpropose_research_questionsツールを呼び出す
2. 研究エージェント（Gemini 2.5 Flash）が各質問に答えるべくループ探索。読んだファイルに1〜9の「関連スコア」を付け、上位ソースを集約
3. 上位ソースをGemini 2.5 Proが評価し、追加調査が必要なら再帰的にpropose_research_questionsを呼び出す（最大3回×3問）
4. 最終的にトップレベルエージェントがレビューコメントを出力

この仕組みは動いた。エージェントがコードベースを横断的に調べることで、一見無関係なコードとの相関から非自明なバグを複数発見した。

しかし1年後、限界が見えてきた：

• バグの多くは「偶然」関係ないコードを見ているときに発見されていた
• レビューコストが変更の複雑さと相関しておらず、コストが乱数的だった
• 「問題を探せ」と言われたモデルは、なくても問題を作り出す。コメントのS/N比が悪かった
• ツールが増殖しすぎており（Jira検索、正規表現検索など）、コンテキストを圧迫していた

現行システム：「対審式レビュー（Antagonistic Review）」

現在のシステムの核心は、原告・被告・裁判官という役割分担だ。

1. Opus 4（裁判官）がdiffを読み、潜在的な問題を見つけるとpropose_possible_problemsを呼び出す
2. 問題ごとに2つのサブエージェントが起動する：
   • GPT-5（原告）：OpenAIの最上位モデル。問題が実在する証拠を探すよう指示される。ただしnull結果も許容し、ハルシネーションを抑制
   • Gemini 3.0 Flash（被告）：Googleの軽量高速モデル。問題でない証拠を探すよう指示され、コストを抑制する役割も担う
3. 両エージェントが一次ソースとともに証拠を提出
4. Opus 4が証拠を公平に評価し、最終判断を下してレビューを続行

この設計によって「問題を探せと言われたから問題を見つけた」という歪みが大幅に減少した。

信頼性を高めた3つの実装上の工夫

1. 「フリーフォーム→指示→構造化」の順序

長いエージェントループの後、Opus 4は構造化ツールの呼び出しが破綻しがちだった（ファイル名のハルシネーション、JSONの閉じ方を忘れて数千トークン迷走するなど）。対策として：

1. まずフリーフォームのテキストファイルとしてレビューを書かせる
2. str_replace_based_edit_toolで自由に編集させる
3. その後、JSON形式でツールを呼び出す指示を追記
4. 最後にツール呼び出しを必須化

2. Unix哲学とツールの簡素化

コード、PRの内容、Sentryのエラー、Jiraチケットなど——かつてはデータ取得ツールが多数存在していた（いわゆるMCPサーバー的な構成）。現在はこれらをすべて廃止し、「AIリーディングルーム」と呼ぶサンドボックス環境に一本化した。全データを単一ファイルシステム上の大容量SSDに配置し、公開するのはread_fileツールのみ。シェルコマンドは自由に使わせる。

現代のモデルはUnix標準ツールを使ったデータ取得をRLでトレーニングされているため、この設計が合理的に機能する。

3. 方向づけられたリサーチ

エージェントが自発的に考えない問いを補うため、レビュー開始時に3つのサブエージェントを先行起動する：

• プロジェクト背景エージェント：変更が大きなプロジェクトの文脈でどう位置付けられるかを調査
• 既存データエージェント：DBへのクエリを通じて、コードが本番でどう振る舞うかを調査（エッジケースの漏れなど）
• チェックリストエージェント：エンジニアが書いた約80項目の品質チェックリストに照らして違反を探す

実測パフォーマンス

エンジニアに各コメントを1〜5段階で評価させた（1：有害、5：バグを防いだ）。

初期リリースでは評価がほぼ正規分布で中央値は3。対審式レビューに移行後、分布は「階段状」に変化した——4と5の絶対数が微増しつつ、1と2が激減した。なお初期リリースと現行システムのコメント総数の比較については元記事では明示されていないが、「ほとんどのPRがコメントゼロか1件のみ」という記述から、無用なコメント数そのものが大幅に絞り込まれていることがうかがえる。

• 平均レビュー時間：10分
• 平均コスト：$4

当初目標の「$20以内・15分以内」を大幅に下回る水準だ。

AI導入後も人間レビューは残す

Wealthfrontの現在のフローでは、エンジニアがセルフレビュー後に「Ready for Review」をクリックするとIris AIレビューが起動し、その後にピアレビューが追加される。ピアレビューはマージのブロッカーだが、AIレビューはノンブロッキングだ。

人間のニットピッキング（細部への指摘、いわゆる「揚げ足取り」的なスタイルコメント）はAIに任せる時代になりつつある、という認識はある。しかし「人間レビューをボトルネックとして排除する」という方向には今のところ向かっていない。

詳細はExperiments with AI Code Review — Engineering Blogを参照していただきたい。