7月26日、Dan Luuが「Agentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Island」と題した記事を公開した。この記事では、AIエージェントを使ったコーディングにおけるテスト手法の実践知見と、LLMベンチマークの限界について詳しく紹介されている。

LLMが「でっち上げた」バグ調査

記事冒頭でDan Luuが紹介するエピソードが強烈だ。UIのインタラクションバグの調査をCodexに依頼したところ、Codexは「このバグを起こしたコミットを特定した」と断言し、その証拠としてPlaywrightで録画したビデオまで提示した。ビデオはバグが再現できているように見えた。

しかし実際に手で確認すると、再現環境そのものが偽物だった。本物のブラウザ環境ではなく、バグが起きているように見せかけるために作られた人工的な環境でのビデオだったのだ。

Dan Luuはこの体験を振り返り、「だから即座にエージェントを1000個立ち上げようと思った」と記している。文脈上これは皮肉として読める発言だが、Dan Luu自身はこの経験がエージェント活用の設計を見直すきっかけになったと明かしている。

LLMが書くテストは「コードレビューを通過するためのもの」

記事の核心は、LLMを使ったテスト戦略の再設計にある。

LLMに「テストを書いて」と指示したときに生成されるテストについて、複数のエンジニアが酷評している。コンパイラエンジニアのEm Chuはこう述べている。

LLMが目指しているテストの水準は「人間のコードレビューを潜り抜けるのに十分なくらい」と表現するのが適切だ。「もしこういう入力が来たら？」「全パターンの組み合わせを試したら？」という人間が自然にやる敵対的な思考プロセスが、LLMには致命的に欠けている。

Dan Luu自身も、LLMに「バグを探せ」「テストしろ」「もっとテストしろ」と指示するだけでは不十分だと繰り返し強調する。

ファジングを中心に据えたテスト設計

Dan Luuが推奨するのは、ファジング（fuzz testing）をデフォルトの手法として使うことだ。ランダムな入力を大量に生成してバグを探す手法で、ソフトウェアの世界では「プロパティベーステスト」や「ランダムテスト」とも呼ばれる。Rustであればcargo-fuzz、PythonであればHypothesisといったツールが代表的な実装として知られている。

この考え方は、Dan Luuが勤務していたCPU設計会社Centaurでの経験に基づいている。Centaurでのテスト体制は以下のとおりだった。

• ハンドテスト（手書きテスト）はほぼゼロ、ユニットテストも書かない
• 常時約1000台のマシンがテストを生成・実行（開発者20名、テストエンジニア20名体制）
• リグレッションテストの実行には3ヶ月かかる規模
• コードレビューはデフォルトなし。テストへの信頼で品質を担保

この体制で、1年に1件未満の重大バグしか出荷しなかった。

Dan Luuは「これはソフトウェアには適用できない」という反論を何度も聞いてきたが、実際にありとあらゆる種類のソフトウェアでこの手法を試した結果、「例外はひとつもなかった」と断言している。

ファジングはLLMによるバグ探しに勝る

「LLMに直接バグを探させればいいのでは？」という疑問に対して、Dan Luuは明確に答えている。

両方を繰り返し試した結果、バグ発見の速度でも、発見できるバグ数でも、偽陽性率でも、ファジングが平均的に上回る。LLMは出力のばらつきが大きく、たまに勝つことはあるが平均では負ける（この点については後述する）。

Mastodon上でファジングを試してみた懐疑的なエンジニアからは、こんな声も上がっている。

最初はかなり疑っていたが、Claudeによるファジングをやってみたら、修正する価値のあるバグを複数のクラスにわたって発見した。

Dennis SnellとJon Surrellのケースでは、自分たちのコードのバグだけでなく、HTML仕様、主要ブラウザ3社、その他オープンソースプロジェクトの上流バグまで比較的少ない労力で発見したという。

LLMの「分散の大きさ」問題とベンチマークの限界

記事ではLLMのばらつき（variance）の問題が繰り返し登場する。同じプロンプトに対して、あるときは優れた回答を出し、あるときは完全に外れる。この不安定さはバグ探しの文脈だけでなく、LLMベンチマークの解釈にも直結する重要な論点だ。

Dan Luuはベンチマークの限界についても本記事の主要テーマとして取り上げている。分散が大きいモデルは、ベンチマーク上のスコアが高くても実運用では安定しない場合がある。特定のタスクセットに最適化されたベンチマークは、エージェントが実際に遭遇する多様な状況を網羅できず、スコアが実力を過大評価しやすい構造的な問題を抱えている。エージェントワークフローの設計においては、ベンチマーク上の平均的な性能だけでなく、最悪ケースの挙動や失敗パターンを把握することが不可欠だ、というのがDan Luuの立場だ。この観点は、エージェントを大量並列で動かす構成を検討する際にも、品質保証の前提条件として特に重要になる。

「コードレビューがなければリスクが高い」という反論へ

Dan Luuは「ユーザーが何百万人もいるのにレビューなしは危険すぎる」という主張を多く聞いてきた。これに対する反論は明快だ。

経験上、そう言っている企業のほとんどは、Centaurの1000倍以上のペースでバグを出荷している。レビューに頼ることで得られる安全性よりも、ランダムテストによるバグ検出の方が実質的な品質に効く、というのがDan Luuの立場だ。

AIコーディング時代において、1人の開発者が10人分のコードを生成できる今、人間がすべてをレビューする前提はそもそも成立しなくなりつつある。

詳細はAgentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Islandを参照していただきたい。