AI時代のテスト — 変わった実態と、 変わらない問い

大規模言語モデル (LLM) がコード生成に使われるようになり、 テストコードの生成・自動修復・評価にも LLM が応用されるようになった。 GitHub Copilot・Claude (Claude Code 等)・Cursor といったツールは、 実務での採用も進んでいる。 一方で、 この分野の学術研究と実務報告は、 期待と同じくらい多くの限界も明らかにしてきた。 テスト自動化の本質的な難しさは「何が正しい結果かを誰が・どう判断するか」 という oracle 問題 にあり、 これは LLM 登場以前から存在した問題であって、 LLM によって解消されたわけではない。 このシリーズの最終記事として、 誇張を避け、 現時点で知られている実態と限界を整理する。

LLMによるテスト生成の実態

Copilot・Claude・Cursor などのコーディングアシスタントは、 対象の関数やコメント・型情報を文脈として読み取り、 テストケースの骨格・代表的な入力値・アサーションの型を生成できる。 実務上の価値が確認されているのは、 既存パターンに似た定型テストの雛形作成、 開発者が見落としがちな空文字列・null・境界値の想起支援、 そしてテストの存在しないレガシーコードへの「現在の振る舞いを記録するテスト」 の叩き台生成である。

一方で学術的な評価研究では、 生成されたテストがコンパイルエラーを含む、 価値の低い自明なアサーションに留まる、 リポジトリ固有の命名規則やヘルパー関数を踏まえられていない、 といった課題が繰り返し報告されている。 生成精度は、 対象コードに与える文脈情報 (型シグネチャ・既存テストの例・コメント) にどれだけ左右されるかが、 複数の研究で共通して指摘されている。

「自己修復」 という言葉の誇張と実態

自己修復 (self-healing) は、 AI 時代のテスト分野で最もハイプと実態の乖離が大きい語の一つである。 ただし実用化された技術も存在する。 Mabl・Testim・Functionize といった商用の E2E テスト自動化ツールは、 UI 要素を特定する「ロケータ」 が DOM 構造の変更で効かなくなった際、 要素の属性・視覚的な位置・周辺 DOM 構造といった複数のシグナルを機械学習モデルで照合し、 最も一致度の高い代替要素を選び直す auto-healing 機能を提供している。 これは前記事 フレーキーテストとの戦い で扱った E2E テストの構造的な脆さへの、 限定的だが実用化された対処である。

一方、 「テストが失敗した際に AI がテストコードそのものを自律的に書き換えて修正する」 という、 より広い意味での自己修復は研究段階の域を出ていない。 商用ツールが実際に提供しているのは、 主にロケータの自動調整のような限定的な範囲にとどまる。

oracle問題 — AIでも解けない根本問題

oracle 問題 (test oracle problem) とは、 「あるプログラムの出力が正しいかどうかを、 どう判定するか」 という、 テスト自動化における根本的な難問である。 単純な入出力の等値比較で済む場合は問題にならないが、 「正しい出力」 が定義困難な問題 (自然言語生成・画像認識・推薦システム等)、 期待される出力を人手で用意するコストが非現実的な場合、 複数の妥当な出力が存在しうる場合に深刻になる。

LLM はテストの入力候補 (境界値・異常系のパターン) を提案する支援には有効だが、 「何が正しい出力か」 を決める権威 (oracle) を代替するものではない。 LLM に「この出力は正しいか」 と問うこと自体は可能だが、 それは別の LLM 呼び出しに判定を委譲しているだけであり、 判定の正しさを担保する根拠にはならない。 oracle 問題は LLM 登場以前からの中心的な未解決課題であり、 AI 導入で解消されたのではなく、 「判定を誰が・どう行うか」 という問いの形を変えて持ち越されている、 と理解するのが実態に即している。

oracle が定義しやすい領域	oracle が困難な領域
数値計算・ソート・パーサなど、 入出力の等値比較で済む処理	自然言語生成・要約・対話応答
既知の入出力例が豊富にある処理	画像認識・推薦システムなど「正解」が確率的・主観的な処理
期待値を仕様から機械的に導ける処理	複数の妥当な出力がありうる処理 (同じ意味を異なる表現で返すLLMの出力など)

前者は古典的な単体テストがそのまま機能する領域であり、 後者こそが LLM を組み込んだシステム自体の評価 (後述の eval) で常に問題になる領域である。

プロパティ・不変条件のAI推論

前記事群で扱った プロパティベーステスト は、 個別の入出力例ではなく「常に成り立つべき性質」 を検証する手法である。 LLM をこの不変条件の候補抽出に使う試みも研究レベルで存在し、 コードやドキュメントから「この関数は結果が入力より常に大きいはずだ」 といった性質の候補を LLM に提案させ、 人間がそれを precondition/postcondition として採用するかを判断する、 という支援的な使い方が模索されている。 これも「LLM が提案した性質が本当にドメイン上正しいか」 を最終判断するのは人間であり、 oracle 問題を回避しているわけではない。

AIが生成したコードのテスト戦略

AI が生成したコード自体をどうテストするかについては、 「人間が書いたコードと本質的な違いはない」 という立場が広く共有されている。 むしろ次の点が実務上重要になる —— 生成されたコードの意図をレビューなしに大量に取り込むと、 その意図をテストだけから逆算する必要が生じテスト設計自体が難しくなること。 実装とテストを同一のプロンプト・同一のモデル呼び出しで生成すると、 実装のバグとテストの誤ったアサーションが相関して生成されやすく、 独立した検証にならない可能性があること。 そして、 AI が実装を提案する場合でも期待される振る舞いを定義する主体は人間である方が、 oracle 問題への対処として健全であること。

AIシステム自体のテスト — eval、 LLM-as-judge、 非決定性

LLM を組み込んだシステム (チャットボット・エージェント・要約や分類のパイプライン) 自体を評価するテストは、 従来の決定的な単体テストとは性質が異なる。 この領域では「テスト」 ではなく eval (評価) という語が使われることが多い。 LLM-as-judge は LLM の出力の良し悪しを、 別の LLM 呼び出しに判定させる手法で、 人手評価のコストを下げられる一方、 判定者側の LLM にもバイアスや不安定性があり、 判定自体の信頼性を検証する必要がある。

LLM の出力は温度 (temperature) を 0 に設定しても完全には決定的にならないことが実測研究で示されている。 推論基盤側のバッチ処理やハードウェア最適化に起因する非決定性が残るためで、 これは「一度のテスト実行で合否を断定できない」 という、 従来のテストの前提を崩す性質である。 実務的な対応策として、 同一プロンプトを複数回 (目安として 3〜10 回程度) 実行して平均・分散を報告する、 完全一致ではなく意味的な等価性 (スキーマ準拠・指示追従・構造の正しさ) を検証する、 モデルバージョン・サンプリングパラメータ・評価者バージョンを記録して再現性を確保する、 といった手法が広まりつつある。 これは前記事の「非決定性」 という概念が、 LLM を含むシステムでは偶発的なバグではなく システムの本質的な性質 として立ち現れることを意味する。

リスク — 幻覚・過信・カバレッジの錯覚・実装追認テスト

LLM によるテスト生成には、 現場で確認されているいくつかの具体的なリスクがある。 存在しない API や間違った型シグネチャ、 コンパイルすら通らないコードを生成してしまう 幻覚的なテスト。 「AI が生成したから正しいはず」 という思い込みがレビューを省略させる 過信。 カバレッジ数値を上げること自体を目的化してテストを大量生成すると、 カバレッジ率は向上してもバグ検出力の伴わないテストが積み上がる カバレッジの錯覚。

そして最も深刻なのが 実装追認テスト (implementation-confirming tests) である。 これは LLM がテストを生成する際、 「あるべき正しい振る舞い」 からではなく「今の実装が実際に返す値」 からアサーションを作ってしまう現象で、 バグを含むコードに対して特に深刻な結果を生む。 GitHub Copilot・CodiumAI CoverAgent・CoverUp という 3 つのテスト生成ツールを評価したある研究では、 最終的なテストスイートの 最大 68.1% が「バグを含む誤った実装ではパスし、 正しい実装では逆に失敗する」 —— つまりバグそのものを “正解” として固定してしまうテストになっていたと報告されている。 カバレッジ数値を上げることを目的にした設計選択が、 バグの検出ではなくバグの追認を生んでしまう典型例として引用される。

人間レビューという不可欠の工程

以上を踏まえると、 現時点で広く受け入れられている現実的な立場は次の通りである。 LLM はテストの雛形生成・入力候補の想起・定型作業の高速化において実務的な価値を持つ。 LLM は「何が正しい振る舞いか」 を決定する権威を代替できない —— これは技術的制約というより、 oracle 問題そのものが本質的に人間のドメイン知識・仕様理解を要求する問題だからである。 生成されたテストは、 通常のプルリクエストのコードと同様に人間によるレビューを経るべきであり、 特に「アサーションが実装の現状をなぞっているだけではないか」 を確認する視点が重要になる。 テストが検証すべきは「仕様通りの振る舞い」 であって「現状のコードの動作」 ではない、 という原則は AI 時代でも変わらない。

実世界の60年、 シリーズの18記事

ソフトウェアテストの実世界での歩みを圧縮すると、 次のようになる。

年代	ひとことで
〜1970年代	手動確認・デバッグの延長。 まだ「テスト」 は独立した工程ではなかった
1990年代半ば	SUnit がフィクスチャ・テストランナーという xUnit 系の原型パターンを確立
1997-2002年	JUnit の普及と TDD の体系化により、 テストが「設計を導く行為」 になる
2000年代後半	BDD・Cucumber・xUnit Test Patterns でテストの語彙と手法が結晶化
2010年代前半	JS/フロントエンド向けフレームワーク (Jasmine → Jest) が爆発的に普及
2010年代後半	Selenium 一強から Cypress・Puppeteer へ、 E2E ツールの世代交代が進む
2020年代	Playwright によるマルチブラウザ統一と、 LLM によるテスト生成の浸透

系譜を振り返る — 18の記事を貫いた問い

このシリーズは、 上の年表を 18 の記事に分けて辿ってきた。

記事	ひとことで
1. 前史	手動確認の時代、 Dijkstra の警句、 V&V という古典的区別
2. xUnitの誕生	SUnit/JUnit がフィクスチャ・テストランナーを発明
3. xUnitの普及	xUnit系のパターンが各言語のエコシステムへ広がる
4. TDD	Red-Green-Refactor、 テストが設計を導く
5. BDD	「振る舞い」 の言葉で、 テストの心理的ハードルを下げる
6. モックとテストダブル	実体を差し替えて依存を切り離す技法の体系化
7. プロパティベーステスト	個別の例ではなく「常に成り立つ性質」 を検証する
8. E2Eの世代交代	Selenium から Cypress・Playwright へ
9. JavaScriptテスト	フロントエンドテストの爆発的普及
10. 言語別エコシステム	各言語コミュニティごとのテスト文化の違い
11. テストの形	テストピラミッドなど、 配分の理論
12. 単体テスト設計と契約	良い単体テストの条件、 契約による設計
13. カバレッジとミューテーション	「十分にテストした」 をどう測るか、 測ることの限界
14. フレーキーテスト	非決定性という、 テストの信頼性を蝕む問題
15. 形式手法	テストで届かない領域を、 数学的証明で補う試み
16. 品質は誰の仕事か	テストが特定の職能から、 チーム全員の関心事へ
17. 大規模開発のテスト	数百万件規模のテストを支える実行基盤と設計
18. AI時代のテスト (この記事)	生成・実行の道具が変わっても、 検証という営みの根本問題は変わらない

テストは何を保証できるか — 道具は変わっても問いは変わらない

このシリーズの第 1 記事 テストの前史 で見た通り、 Edsger Dijkstra は 1969 年の NATO ソフトウェア工学会議での発表を経て、 1970 年の論文「Notes on Structured Programming」 (EWD249) でこう書いた。

“Program testing can be used to show the presence of bugs, but never to show their absence!”

プログラムテストはバグの存在を示すのには使えるが、 バグの不在を示すことは決してできない。 Glenford Myers が 1979 年に定義した「テストとはプログラムを壊すための破壊的プロセスである」 という視点も、 Barry Boehm の V&V ── 「正しく作れているか (検証)」 と「正しいものを作っているか (妥当性確認)」 の区別も、 半世紀以上前から変わらず現役の視座であり続けている。

LLM はテストを書く速度を上げ、 見落としがちな入力を思い出させ、 レガシーコードへの最初の一歩を軽くした。 だが LLM は、 Dijkstra が突いた限界を消してはいない —— むしろ実装追認テストという形で、 「テストが緑であること」 と「バグがないこと」 の距離を、 これまで以上に鋭く可視化した。 SUnit から JUnit、 TDD から BDD、 モックからプロパティベーステスト、 Selenium から Playwright、 そして数百万件のテストを支えるモノレポの基盤に至るまで、 道具と語彙は 60 年かけて何度も入れ替わった。 その間ずっと問われ続けてきたのは、 ただ一つ —— テストで何を保証できるのか、 という問いである。

道具が人間から AI に代わっても、 この問いに答える責任だけは、 依然として人間の側にある。

読者へ

このシリーズを通読した読者には、 次のような一次資料に直接あたることを勧めたい。 Kent Beck 『Test-Driven Development: By Example』 (2002)、 Michael Feathers 『Working Effectively with Legacy Code』 (2004)、 Gerard Meszaros 『xUnit Test Patterns: Refactoring Test Code』 (2007)、 Steve Freeman と Nat Pryce 『Growing Object-Oriented Software, Guided by Tests』 (2009)。 そして Google のエンジニアリング文化を扱った『Software Engineering at Google』 は、 本記事で扱った hermetic tests やテストサイズ分類の一次資料でもある。 いずれも半世紀に満たないこの分野で、 すでに「古典」 と呼べる位置を占めている。

ソフトウェアテストの系譜シリーズは、 ここに完結する。 Dijkstra の警句から始まり、 AI がテストを書く時代まで —— 「動くかどうかを確かめる」 という素朴な行為の奥に、 これほど豊かな問いの歴史があったことを、 この 18 記事が伝えられていれば幸いである。