テストを書く前に「契約」を書かせる──Googleのバグ実データで検証されたSpec-Driven Test Generation

コーディングエージェントに「このコードのテストを書いて」と指示すると、表面的なハッピーパスは押さえても、境界値やエッジケースを見落とすことがある。この失敗パターンに対して、arXivで2026年8月17日に公開された論文（arXiv:2608.17177）は、Googleの本番バグを使った実証評価で1つの対策を示している。著者はMichele Tufano氏ら10名全員がGoogle所属で、DOI付きでSPLASH 2026併設ワークショップ「SpecOps 2026」（2026年10月4〜9日、米オークランド）に採択されている。

3行まとめ

1. Google所属の研究者10名による論文は、90件のGoogle社内の実バグ修正データ（C++・Java・Python・Go）を使い、同一のGemini 3 Flash・同一のツールセットで、テストをいきなり書かせるベースラインと、事前条件・事後条件・未定義動作を先に文書化させる「Spec-Driven」型を比較した。
2. バグ検出率(detect@k)の差はk=1では+4.2ポイント(統計的に有意でない、p=0.3075)にとどまり、k=5まで独立実行を重ねて初めて+9.8ポイント(p=0.0352、有意)まで開いた。テストの構文的な正しさ(pass@k)自体はほぼ差がなく(k=1で-0.2%)、改善は仕様による推論の質から来ていることを示す設計になっている。
3. Spec-Driven方式はトークン消費が38.0%増える(2億4,390万→3億3,670万)一方、検出できたユニークなバグ数は48件→57件(+9件、+18.8%)に増え、「バグ1件あたりのトークン消費」で見ると16.2%増にとどまったという。

• 提案手法「Spec-Driven Test Generation」は、テストコードをいきなり書かせるのではなく、まずコードの事前条件・事後条件・未定義動作を推論させて明示的に文書化させ、その仕様をテスト生成の「認知的な足場（cognitive scaffold）」として使う
• Googleの本番バグを使った評価で、従来型のテスト生成エージェントと比較して、バグ検出率が9.8ポイント（p=0.0352）、分岐カバレッジが2.5ポイント（p=0.0034）、それぞれ統計的に有意に改善
• LLM-as-a-Judgeによる評価では、仕様駆動型エージェントが生成したテストスイートが、従来型ベースラインの77.8%・人間が書いたテストの56.7%のケースで「優れている」と判定された

問題意識：直接プロンプトの限界

論文のアブストラクトはこう述べている。

When directly prompted to generate tests, these agents can fail to reason about the code and its underlying contracts, thereby missing edge cases and behavioral boundaries that affect test quality.

（直接プロンプトでテスト生成を指示すると、エージェントはコードとその背後にある契約について推論できず、テスト品質に影響するエッジケースや振る舞いの境界を見落とすことがある）

これに対する解決策として提案されているのが、テスト生成の前段に「仕様の言語化」という明示的なステップを挟む設計だ。事前条件・事後条件・未定義動作という3種類の情報を半形式的（semi-formal）に書き出させ、それを土台にテストを組み立てさせる。

仕様アーティファクトの中身:4つ組で定義される「契約」

論文2章はこの「仕様アーティファクト」を、コード単位 $c$ ごとの4つ組 $S_c = \langle D_c, Pre_c, Post_c, Sug_c \rangle$ として形式的に定義している。

• $D_c$：そのコード単位が意図する振る舞いを説明する自然言語の記述
• $Pre_c$：実行前に成立していなければならない状態・制約の集合（事前条件）
• $Post_c$：実行後に保証される状態の集合（事後条件）。入力検証（エラーハンドリング）・成功時の戻り値・データベース書き込みなどの状態変化・想定される状態のバリエーションを含む
• $Sug_c$：$Pre_c$・$Post_c$の各条件を担保するために紐づけられた、テスト案の部分集合

さらに$Pre_c$・$Post_c$内の各条件には、既存のユニットテストスイートと突き合わせて「Tested（既存テストで検証済み）」か「Untested（未検証で、$Sug_c$に対応するテスト案が生成される）」のいずれかの検証状態が割り当てられる仕組みになっている。論文はこの半形式的な自然言語仕様を、Daikonのような動的invariantマイニング（実行トレースを機械的に定式化するため、バグの挙動までそのまま「仕様」化してしまうリスクがある）と対比し、LLMエージェントはdocstring・コメント・既存テスト・呼び出し元のAPI利用パターンを横断的に参照することで、実装そのものではなく「開発者の意図」を推論しようとする点が異なる、と位置づけている。

評価方法:90件の実バグ、同一モデル・同一ツールセットで比較

評価に使われたのは、Googleの内部Issue Tracking Systemから厳選された90件の過去のバグ修正（バグ入り版と修正版のペア）で、些細な構文修正・マルチメディア処理・個人情報が絡むものは除外し、本番コード1ファイル・対応するテストファイル・任意のBUILD設定ファイルのみを変更するバグに限定したという。対象言語はC++・Java・Python・Goの複数言語にまたがる。比較対象のベースラインエージェントと仕様駆動型エージェントは、いずれも同じGemini 3 Flash・同じツールセット（view_file・list_dir・write_to_file・run_command・grep_search・find_by_name・run_test）・同じ推論パラメータ（temperature 1.0・TopP 1.0・TopK 50）で動かされており、違いは「仕様を先に書かせるかどうか」という1点だけに絞られている。

まず「テストが構文的に正しくコンパイル・パスするか」を見るpass@k（Table 1）では、両エージェントにほぼ差がなかった。

論文はこの「ほぼ差がない」という結果を、後述するバグ検出率の改善が、コード生成の巧拙ではなく仕様による推論の質そのものに起因することを裏付ける材料として位置づけている。

本題のバグ検出率detect@k（Table 2、95%信頼区間・McNemar検定のp値付き）は次の通り。

要旨で強調されている「+9.8ポイント」という数字はk=5時点のものであり、k=1では+4.2ポイントで統計的に有意な差ではない。論文は「独立試行の回数が増えるほど差が広がる」ことを、仕様駆動型のフレームワークが追加の実行予算を、多様な経路の探索と巧妙なバグの発見に効果的に振り向けている証拠だと解釈している。McNemar検定はk=1・k=2では非有意（p>0.05）、k=3で限界的（p=0.0574）、k=4・k=5でp=0.0352の有意差に達したとしている。

Table 2の95%信頼区間が両エージェントとも比較的広いことについて、論文はデータセット内のバグ難易度のばらつきが原因だと説明している。バグごとの検出率は一様ではなく、ほぼ全試行で検出される（難易度が低い）か、ほぼ全試行で検出されない（難易度が高い）かに二極化する傾向があり、ベースラインでは90件中59件（65.6%）がこの「検出率0%か100%」の両極端に該当する。Spec-Driven方式ではこの二極化がやや緩和され、90件中52件（57.8%）に減少しており、これは一部のバグが「完全に未検出（0%）」から「20〜80%の確率で検出される」中間領域へ移動したことを意味すると論文は述べている。

k=5時点で両エージェントが検出したバグの重なりも分析されている。両方が検出できた共通のバグは45件、Spec-Driven方式のみが検出できたバグは12件、逆にベースラインのみが検出できたバグは3件だった（45+12=57件、45+3=48件で、それぞれの合計検出数と一致する）。

加えて、LLM-as-a-Judge（Gemini 3.1 Pro、テスト生成に使ったモデルとは別のモデルで判定）による定性評価では、生成されたテストスイートの質を人間が書いたテストとも比較している。仕様駆動型のテストスイートは、従来型ベースラインとの比較で77.8%、人間が書いたテストとの比較で56.7%のケースで「優れている」と判定され、ベストプラクティスの順守・可読性・エッジケースカバレッジの面でも改善が見られたとされている。

コスト:トークン消費は38%増、バグ1件あたりでは16.2%増

明示的な仕様を書かせる分、当然コストは上がる。論文のTable 4（全5回の実行を合算したトークン消費）は次の通り。

出力トークンの増加率（+59.1%）が入力トークンの増加率（+36.2%）より大きいのは、仕様駆動型エージェントが(1)行動の背後にある仕様そのものをMarkdownで出力する必要があり、(2)仕様に導かれてより網羅的で大きなテストスイートを合成するためだと論文は説明している。「バグ1件検出あたりのトークン数」で見ると、総トークンの増加率(38.0%)よりも小さい16.2%増にとどまっており、論文はこれを「コストの増加分に対して、それを上回るバグ検出数の増加が伴っている」ことの根拠として示している。

分岐カバレッジは伸びたが、行カバレッジは伸びていない

論文のTable 3（95%信頼区間・Wilcoxon符号順位検定付き、修正後のコードに対して生成テストを実行した際の平均カバレッジ）は、次の通り。

行カバレッジはむしろ0.4ポイントわずかに下がっているが、分岐カバレッジは2.5ポイント有意に上がっている。論文はこれを、仕様駆動型のフレームワークが単に実行行数を稼ぐのではなく、より複雑な制御フロー構造（分岐）を系統的にカバーする方向にエージェントを導いている証拠だと解釈している。

質的評価:83件のテストスイートをLLM-as-a-Judgeが比較

RQ2の質的評価では、Spec-Driven方式が生成に成功した83件のテストスイートを対象に、ベースラインが生成したテストスイート・人間の開発者が書いた既存テストスイートのそれぞれと、LLM-as-a-Judge（Gemini 3.1 Pro）で比較している。判定者は5回の独立評価にわたって90%以上の自己一致率、5.6%以下という低い引き分け率を示し、内部信頼性は高かったとされる。

• ベースライン比較：Spec-Driven方式のテストスイートは、粒度の細かい振る舞いの分離、イディオマティックなフレームワークの使い方（リフレクションや過剰なモック使用を避ける）、契約に沿った命名規則（Method_State_Outcome形式など）で一貫して高く評価された。特にエッジケースカバレッジでは83.3%のケースで優れていると判定され、境界値・欠落したオプション引数・エラーパスを体系的に検証していた一方、ベースラインはこれらをほぼ見落としていたという。
• 人間が書いたテストとの比較：Spec-Driven方式は、より狭く精度の高いアサーションを生成し、ローカルなファクトリヘルパーによって定型コードを削減し、契約が定める否定的なエラーパスを体系的に検証していた点、また人間のテストに時折見られる非決定的な待機処理より頑健な並行処理構文（absl::Notificationなど）を好んだ点が強みとされた。一方で、複雑なアルゴリズム的シナリオ（複雑な状態遷移やタイムゾーンなど）に対する網羅的なテスト設計は人間の開発者の方が優れており、また人間は公開APIのカプセル化を厳格に守っていたのに対し、Spec-Driven方式のエージェントは時折リフレクションを使ったハック（invokePrivateMethodなど）でカプセル化を回避することがあったと、弱点も明記されている。

仕様そのものの精度:ContractCoverageとバグ検出の相関

RQ3では、生成された仕様がどれだけ正確に「違反された契約」を捉えられているかを、論文が新たに定義した指標ContractCoverage@kで評価している（450回の試行＝5回×90件バグを対象）。

さらに「契約が正しく文書化されたか」と「バグを検出できたか」の2×2分割表をFisherの正確検定で分析したところ、統計的に有意な中程度の相関が見られた（p=3.62×10⁻¹⁴、ファイ係数0.35）。契約が正しく文書化された場合はバグ検出率54.9%（275回中151回）だったのに対し、文書化に失敗した場合は19.4%（175回中34回）まで落ち込んでいる。契約カバレッジがないのに検出できた残り34回は、構造的なカバレッジ目標や単純なクラッシュ検知（未処理例外の確認など）が偶然バグを引き当てたケースだと論文は分析している。

バグを検出できなかった試行のうち、仕様自体が違反された契約を捉えられていなかった「仕様生成の失敗」141件は、LLM判定によって5パターンに分類されている。

一方、契約は正しくカバーされていたのにバグを検出できなかった「テスト生成の失敗」110件（コンパイル失敗など14件は除く）も、5パターンに分類されている。

AIコーディング利用者にとっての含意

この論文が扱っているのは学術的な理論ではなく、Google社内の実バグという実務データだ。テスト生成エージェントを使う際に「まず仕様（契約）を書かせてからテストを書かせる」という2段階のプロンプト設計は、既存のコーディングエージェント（Claude Code・Codex・Copilotなど）を使う個人開発者でも、プロンプトの工夫として今すぐ試せる考え方ではある。ただし論文の実験環境はGoogle社内の独自エージェント基盤上のものであり、市販のコーディングアシスタントで同じ改善幅が再現される保証は論文には書かれていない。

限界:単一組織・単一モデル・履歴バグという評価環境

論文6章「Threats to Validity」は、この結果の適用範囲を3つの観点から自己申告している。

• 構成概念妥当性（Construct Validity）：質的評価とContractCoverageの算出にLLM-as-a-Judge（Gemini 3.1 Pro）を用いている以上、分類ノイズ・冗長性バイアス・自己選好バイアスのリスクは避けられない。論文は対策として、(1) テスト生成に使ったモデルより大きく高性能なGemini 3.1 Proを判定に使うことで自己選好バイアスを抑え、(2) 判定を5回独立実行して多数決を取る、という2つの緩和策を取ったとしている。
• 内的妥当性（Internal Validity）：過去のバグを評価に使う手法にはデータ汚染（LLMが事前学習でそのバグ修正パターンを学習済みである可能性）のリスクが伴う。ただし論文は、ベースラインとSpec-Driven方式が全く同じ基盤モデル（Gemini 3 Flash）を使っている以上、観測された性能差はデータ汚染ではなく仕様による推論力の向上に起因すると主張している。また評価対象は「過去に実際に起きたバグの再検出」であり、本番環境で「まだ知られていない新規バグ」を見つけられるかどうかは、この論文の範囲外だとも明記している。
• 外的妥当性（External Validity）：対象言語はC++・Java・Python・Goと多言語にまたがるが、90件全てがGoogleの単一モノレポから採られており、Google固有のエンジニアリング標準・スタイルガイドの影響を受けている。そのため異なる企業やOSSのコードベースで同じ検出率・カバレッジが再現される保証はない。評価対象も「単一の本番コードファイルを変更するバグ修正」に絞られており、複数ファイルにまたがる複雑な修正は評価対象外になっている。

本記事はarXivのHTML全文（Abstract・2〜6章）とPDF版（camera-ready）をcurlで取得し、3章のPhase I仕様抽出・Human-in-the-Loop仕様キュレーション・Phase IIオラクル駆動テスト生成の各手順の詳細な記述、および「Illustrative Example」節の具体的なコード例までは、本文中で引用した数値・分類・定義以上には読み込んでいない。ACM DOI（10.1145/3842652.3843195）は本記事執筆時点（2026年8月31日）でACM Digital Library側に未登録（404）で、正式な会議論文集としての公開は2026年10月のSpecOps 2026開催後になる見込みだ。なお同ワークショップの公式ページによれば、SPLASH/ISSTA 2026本体の会期は2026年10月4日（日）〜9日（金）・米カリフォルニア州オークランドだが、SpecOps 2026自体は「10月6日に、ISSTAと併設でOakland Marriott City Centre ホテルにて開催」と公式ページに単日で明記されている。90件という評価対象の規模、Google社内という限定された環境での結果であることも踏まえ、市販のコーディングアシスタント（Claude Code・Codex・Copilotなど）や異なるモデルでどこまで再現するかは、この論文の範囲では判断できない。自分の手元で同じ2段階プロンプトを既存のコーディングエージェントに試して効果を検証する作業も、本記事の範囲外とした。

関連記事: AIコーディングアシスタント比較 / Claude Codeとは / AIエージェントとは

感想・指摘はコメント欄へ。