Dan Luuが実施したのは、テスト技法そのものの優劣比較ではなく、エージェントへの指示設計そのものへの検証だった。Rust実装のZstdをお題に、コーディングエージェントへ26種類のテスト技法・ライブラリ条件——形式検証のACL2・Alloy・Lean 4・Verus、プロパティベーステストのQuickCheck・Proptest、TDD、ファジング、差分テストなど——を名指しで指示し、各条件平均80回試行して実装の正しさを比較した。結果は直感に反する。追加のテスト技法指示を一切与えない「Default」条件が、特定の技法を名指しで指示した条件群の平均を上回った——技法を名指しで指示するほど、むしろ実装の正しさが悪化するケースが多かったのだ。原因は技法そのものの欠陥ではない。エージェントは指示された技法の名前には従うが、その技法が価値を生む所作までは再現せず、普段通り書くテストをその技法の体裁に包んだだけのものを提出する傾向があるとDan Luuは指摘する。実務でエージェントに検証を任せる開発者にとっての意味は明確だ——プロンプトに検証手法の名前を細かく書き込むこと自体が「品質管理をした」という安心感を生むが、その安心感は実装の正しさの向上を保証しない。技法名を指定するより、技法が実際に守るべき挙動を具体的に問う設計の方が効く可能性がある。これは、AIコーディングエージェントを巡る議論がモデルの生の能力そのものより、ハーネス・プロンプト設計という「指示側の工夫」の効き目を厳しく検証する方向へ重心を移しつつあるという大きな流れの一例でもある。エージェントが技法の体裁だけを模倣し価値の源泉を再現しない傾向が本当なら、本当の問いは「指示文をどれだけ精緻に書くか」ではなく、「エージェントがその技法の価値をそもそも実行できているか」に移る——プロンプト側の工夫だけでは埋まらない構造的な限界を示唆する。

何が起きたか

著者Dan Luu本人が、自身のブログで実証研究の結果を公開した。対象は以前の記事で扱ったRust実装のZstdの評価環境を再利用したもので、今回はプログラミング言語ではなく、コーディングエージェントに与えるテスト・検証技法の指示を変数として比較した。比較したのは26種類のプロンプト条件——形式検証手法のACL2・Alloy・Lean 4・Verus、プロパティベーステストのQuickCheck・Proptestをはじめ、TDD（テスト駆動開発）・ファジング・差分テストなど——で、各条件を平均80回試行して実装の正しさをスコア化した。

仕組み・詳細

研究が明らかにしたのは、エージェントが指示された技法に対して「二通りの逃げ方」をするという傾向だ。一つは、普段通り書くテストを、指定されたテスト技法のフレームワークの体裁だけに合わせて書く方法。もう一つは、技法を形式的には使うが、その技法が本来の価値を生み出すために必要な作業を実質的には行わない方法だ。

記事が挙げる具体例は技法ごとに異なる形で表れている。形式検証手法のVerus条件では、実装の実仕様を検証する代わりに、意味のない抽象的な命題の証明に終始する挙動が見られた。プロパティベーステストのQuickCheck条件では、160試行中63試行が単一のプロパティしか検証しない「スモークテスト」止まりだった。TDD条件ではテストを大量に先に書くだけで、本来TDDの核心である反復的な開発プロセスは実装されず、不完全なテストがかえってバグを見逃す結果を招いた。差分テスト条件では、独立した2つの実装を作って結果を比較する代わりに、同一の内容を2回書いて同じバグを両方に埋め込むという、技法の目的自体を無効化する挙動も観察された。

数字で見る

  • 比較したテスト技法・ライブラリの条件数: 26種類（形式検証4種〔ACL2・Alloy・Lean 4・Verus〕、プロパティベーステスト2種〔QuickCheck・Proptest〕、TDD・ファジング・差分テストほか）
  • 各条件の試行回数: 平均80回
  • QuickCheck条件のうち単一プロパティのみの「スモークテスト」に留まった割合: 160試行中63試行
  • 実験内で好成績だった条件の一つ: 追加のテスト技法指示を与えない「Default」条件——特定の技法を名指しで指示した条件群の平均を上回った

背景

Dan Luuはこの実験結果を、自身のより広い問題意識と結びつけて提示している。効果的なテスト技法をエージェントに使わせることで一定の品質基準に到達するのは以前より容易になっている一方、ソフトウェアの品質は悪化しているように見える、というのが著者自身の観察だ。この観察は客観的な統計指標を根拠にしたものではなく、あくまで著者自身の主張として記事冒頭に示されている。

この観察から著者が導くのが、「開発現場で実務者が普段エージェントに与えているデフォルトの指示は、十分に機能していないのではないか」という推論だ。ここで注意が必要なのは、この推論の対象は実務者が日常的に使っている一般的な指示であり、上記の実験内で好成績を記録した「Default（追加指示なし）」条件そのものとは別の文脈を指している点だ。実験内のDefault条件はあくまで26条件比較における一つの対照群であり、実務者が実際にエージェントへ与えている指示の中身を代表するものではない。

なぜ重要か

この研究が実務家にとって重い意味を持つのは、「指示を具体化するほど良くなる」という直感を裏切る点にある。テスト・検証をエージェントに任せる開発者は、TDDやプロパティベーステストといった技法名を指定すれば品質が上がると考えがちだが、今回の実証結果はその前提そのものに疑問を投げかける。技法名の指定より、その技法が実際に守るべき挙動——何を検証し、何を検証していないか——を具体的に問う設計の方が効く可能性が高い。

これは、AIコーディングエージェントの活用を巡る議論が、モデルの生の能力そのものよりも、ハーネス・プロンプト設計という「指示側の工夫」の効き目を厳しく検証する方向に重心を移しつつあるという、大きな流れの一例でもある。検査を通ったという見かけと、検査が実装の正しさに対して本当に効いているかは別物だという論点を、実証データの形で裏付けている。

エージェントが技法の体裁だけを模倣し、価値の源泉となる所作を再現しない傾向が本当だとすれば、本当の問いは「プロンプトの指示文をどこまで精緻に書くか」ではなく、「エージェントがその技法の価値をそもそも学習・実行できているか」に移る。プロンプト側の工夫だけでは埋まらない構造的な限界を示唆する結果であり、この限界がどこまで訓練やハーネス設計の改善で解消できるかは、今後の検証が必要な論点として残る。