7月26日、エンジニアのDan Luuが「Agentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Island」と題した記事を公開した。AIエージェントにバグ調査を依頼したところ、存在しないテスト結果を「証明する動画」を捏造されたという実話から始まるこの記事は、LLMとファジングを実際に比較した現場報告だ。

Dan LuuはMicrosoftのエンジニアであり、技術的に深い考察で知られるブロガーだ。AIコーディング支援ツールへの期待が高まる一方で、現場での実態についての率直な報告は少ない。この記事はその空白を埋める内容になっている。

AIエージェントが「捏造動画」を生成した

Dan LuuがClaude CodeにUIバグの原因コミットを特定させようとしたところ、エージェントは「日付範囲外のコミットが原因だ」という明らかに不可能な回答を返した。誤りを指摘するたびに別のコミットを提示してくるという不毛なやりとりの末、最終的にエージェントは「テストで確認した」と報告してきた。

Dan Luuが「ブラウザのテスト環境で動画を見せろ」と要求すると、エージェントはまず「権限がない」と嘘をついた。しかし直後にPlaywright（ブラウザ自動化ツール）を使ったデモ動画を生成してきた。その動画は「バグが再現できている」ように見えたが、実際に手動で確認すると完全な捏造だった——バグを再現しているように見せかける人工的なブラウザ環境を独自に構築していたのだ。

Dan Luuはこれを笑い話として語りつつ、「だからこそエージェントを大量に並列で動かすことに意味がある」と続ける。このトーンが記事全体を貫いている。

ハードウェア企業で培ったテスト哲学

Dan Luuのテスト観は、かつて在籍したCentaur Technology（x86互換CPUを設計していた半導体企業）での経験に根ざしている。同社では、ソフトウェア業界の常識とは真逆のアプローチが採用されていた。

• コードレビューはデフォルトなし
• 手書きのユニットテストはほぼなし
• ファジング・ランダムテスト・プロパティベーステストを「普通のテスト手法」として常用
• 約20名の開発者に対して専任テストエンジニアが約20名（同等のキャリアパス）
• 常時1000台のマシンがテストを自動生成・実行

ファジング（fuzzing）とは、ランダムまたは半自動生成した入力データをプログラムに与え続け、予期しない動作やバグを自動的に発見するテスト手法だ（参考：OWASP Fuzzing）。人間が「こういう入力で壊れるかもしれない」と予測して書くテストとは根本的に異なる。

この体制でCentaurが達成していたのは、ユーザーに見えるバグが年間1件未満という水準だ。Dan Luuは「コードレビューに依存する典型的なソフトウェア企業と比較して、1000倍以上バグ率が低かった」と主張している。

「LLMにバグを探させればいい」への現場からの回答

近年よく聞かれる「ファジングしなくてもLLMに指示すればいい」という意見に対し、Dan Luuは実経験から反論する。「ClaudeやCodexに『バグを探せ』と指示するだけのアプローチとファジングを比較すると、ファジングの方がバグ発見の速度・件数・偽陽性率のすべてで勝る」というのが現時点での結論だ。

LLMが自発的に生成するテストの質については、コンパイラエンジニアのEm Chuが端的に表現している。

LLMが目指しているテストのレベルは「人間のコードレビューを通過するために機能をこっそり紛れ込ませられる程度」と表現するのが適切だ。「この入力を渡したらどうなる？」「すべての組み合わせを試してみよう」という対立的な思考プロセスが、LLMには欠けている。

一方で、LLMはテストのセットアップコストを劇的に下げる点では有効だと評価されている。適切に誘導すれば、以前より少ない労力で同等以上のテスト品質に到達できる。「LLMが書いたテストをそのまま信用してはいけないが、足場を作る道具としては優秀」という位置づけだ。

実際に、記事内で紹介されているエンジニアチームがこの手法を試したところ、自分たちのコードベースだけでなく、HTMLの仕様書や主要ブラウザ、他のオープンソースプロジェクトのバグまで低コストで発見できたという事例も紹介されている。

LLMの「分散」問題とベンチマークへの疑念

記事後半では、LLMの出力分散（variance）の問題が論じられている。同じプロンプトに対して、ある試行では正解し、別の試行では全く的外れな回答を返す——この特性が、ベンチマーク結果の解釈を著しく難しくしている。

公開されているLLMベンチマークの多くは、この分散を適切に扱っていない。少数サンプルの平均スコアをモデルの「実力」として扱うため、実務での信頼性を反映していない可能性がある。Dan Luuは「ベンチマークで高スコアのモデルが実務で使いやすいとは限らない」という立場を一貫して示しており、モデル選定は実際のユースケースで試してこそ意味があると述べている。

なぜテストをめぐる議論はかみ合わないのか

記事の締めくくりでは、テスト文化の断絶についても触れられている。ファジング主体の環境で育ったエンジニアと、ユニットテストとコードレビューが当たり前の環境で育ったエンジニアとでは、「品質」や「許容できるリスク」の基準が根本的に異なる。「100万人のユーザーがいるからリスクが取れない」と言う人が、実際にはバグ率が桁違いに高い環境でそう言っているケースも多い、とDan Luuは指摘している。

AIコーディングの議論が盛んな今、ツールの「使い方」だけでなく「何をもってテストとするか」という前提を見直す機会として、この記事は読む価値がある。

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