AIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界

AIテスト自動化とは｜「テストを書く」と「テストを動かす」は別物

結論から言えば、生成AIが担うのはテストコードの作成と修復であり、テストを実行する仕組みは従来どおりです。ここを混同すると、導入の議論が噛み合いません。

テスト自動化という言葉には、もともと2つの意味が混ざっています。ひとつはテストを人手で実行せず自動で回すこと。もうひとつはテストコード自体を人が書かずに用意すること。PlaywrightやJest、pytestが解決してきたのは前者です。生成AIが新しく持ち込んだのは後者になります。

生成AIが担当する範囲

生成AIがテスト工程で実際に手を動かせるのは、おおむね次の4つです。

• 仕様や実装から、テストケースの観点を洗い出す

• 洗い出した観点を、実行可能なテストコードに変換する

• 失敗しているテストの原因を推定し、修正案を出す

• 既存テストのリファクタリング（重複の整理、命名の統一）

逆に、実行環境の構築、CIへの組み込み、テストデータの準備方針の決定は、依然として人の仕事です。GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説で扱っているような実行基盤の設計は、生成AIに任せても判断の質が上がりません。

「使う」と「信じる」のギャップは大きい

導入前に、業界全体の温度感を押さえておくと期待値を調整しやすくなります。

DORAのState of AI-assisted Software Development（2025年）では、回答者の90%が業務でAIを使っていると答えた一方、AIが生成したコードをほとんど信頼していない層が30%いると報告されています。同レポートは、書く時間が減った分が検証の時間に回る構造を指摘しています。

Stack Overflow Developer Survey 2025のAIセクションはもう少し具体的です。AIツールを使う、または使う予定と答えた層は84%。一方で精度を高く信頼していると答えたのは3.1%にとどまります。66%が「ほぼ正しいが微妙に違う」解答に遭遇したと回答し、45.2%がAI生成コードのデバッグに時間がかかると答えました。いずれも同調査に回答した開発者を母集団とする数字で、開発者全体の分布ではない点には注意してください。

この「ほぼ正しいが微妙に違う」という性質は、テストコードと特に相性が悪くなります。実装コードなら動かせば壊れていることに気づけますが、テストコードは壊れていても緑のまま通るからです。

ミニFAQ

Q. 生成AIを入れればテストエンジニアは不要になりますか。

A. テストコードを書く工数は減りますが、何をテストすべきかを決める工程は残ります。むしろ観点設計とレビューの比重が上がるため、職種としての役割はQAエンジニアとは｜仕事内容・年収・テストエンジニアとの違いをフリーランス視点で解説で整理されている方向に寄っていきます。

Q. どのAIツールを使えばいいですか。

A. テスト生成に限れば、エディタ統合型（Copilot、Cursor）とエージェント型（Claude Code、Cline）で使い分けが変わります。ツールごとの違いはAIコーディングエージェント比較｜Cursor・Claude Code・Clineの選び方にまとめています。

生成AIにテストを書かせる前に決める3つのこと

先に決めておかないと手戻りが出るのは、入力・レイヤー・受け入れ基準の3つです。ここを曖昧にしたまま生成させると、量は増えるのに信頼できないテストの山ができます。

何を入力にするか（実装コードか、仕様か）

実装コードをそのまま渡すのは、最も手軽で最も危険なやり方です。生成AIは渡されたコードの挙動を正とみなすため、実装にバグがあればバグごとテストに固定されます。「今の動きが仕様です」と宣言しているのと変わりません。

安全なのは、仕様・受け入れ条件・バグ票のいずれかを先に渡し、テスト観点を出させてから、コードに変換させる二段構えです。

レガシーコードに後からテストを足すケースでは、実装コードを入力にせざるを得ないことがあります。そのときは「これは現状の挙動を固定する特性テストであり、正しさの保証ではない」とテストファイルのコメントに明記しておくと、後から読む人が誤解しません。

どのレイヤーを任せるか

レイヤーによって、生成AIの当たり外れは大きく変わります。

純粋関数の単体テストは、入出力が閉じているため任せやすい部類です。逆にE2Eは、画面のどの要素を掴むか、テストデータをどう用意するかという前提条件が外にあり、そこを人が決めないと生成結果が安定しません。

受け入れ基準（人がどこを見るか）

生成されたテストを全行精読していては、時間の節約になりません。かといってノーチェックでマージすると、通るだけのテストが増えます。

筆者が現場で使っているのは、1テストあたり2〜3分で次の4点だけを見る運用です。この4点は後述する典型的な壊れ方に対応しています。

1. そのテストは、実装を壊したときに落ちるか

2. アサーションは結果を見ているか、呼び出した事実を見ているだけか

3. モックを剥がしたとき、何も検証していない状態にならないか

4. 実行順や時刻に依存していないか

単体テストを生成AIで作る手順

単体テストは、プロンプトに観点を明示できるかどうかで結果が変わります。「テストを書いて」だけでは、正常系を3本並べただけの薄いテストが返ってきやすくなります。

プロンプトの型は「対象・観点・制約」

GitHub Copilotの公式ガイドも、スコープの明示とテストシナリオの指定を推奨しています。実務で使いやすいのは、次の3ブロックに分けた指示です。

対象：どの関数・クラスをテストするか。依存の有無。

観点：正常系、境界値、異常系、例外の型、null／空配列、日付をまたぐケースなど、拾ってほしい観点を列挙します。ここを省くと生成AIは正常系に寄ります。

制約：使うテストフレームワークとバージョン、モックライブラリ、命名規約、1テスト1アサーションにするかどうか、日本語のテスト名を使うか。

制約を書かないと、プロジェクトで使っていないライブラリを前提にしたコードが混ざります。既存のテストファイルを隣のタブで開いておくと、フレームワークを推測させやすくなるのは公式ガイドの指摘どおりです。

1回の生成で渡す対象は、目安として200〜300行程度までに抑えると精度が落ちにくくなります。ファイル全体を一度に投げると、観点が薄く広く散る傾向があります。

生成後に必ず直す4つのポイント

生成されたテストで、ほぼ毎回手を入れることになるのは次の箇所です。

• 境界値の根拠：AIはキリのいい数字（0、1、100）を選びがちです。仕様上の実際の境界（たとえば上限が255文字なら254／255／256）に置き換えます

• 例外の型：「エラーが出ること」ではなく、どの例外クラスがどのメッセージで投げられるかまで指定します

• テストデータの意味：「test1」「foo」のような無意味な値を、ドメイン上あり得る値に直します。レビュー時の読みやすさが変わります

• 重複：同じ条件のテストが名前違いで複数生成されることがあります。1本に統合します

pytestやJestのパラメータ化機能を使うと、生成された似たテスト群をまとめやすくなります。それぞれの記法はPytestとは？Pythonテストフレームワークの基本・使い方・フリーランス案件単価への影響を徹底解説やJUnitとは？Javaエンジニアの年収と未来を変える「テスト自動化」で扱っています。

ミニFAQ

Q. 生成されたテストが最初から全部通りました。これは良い状態ですか。

A. 疑ったほうがよいケースです。実装に合わせて書かれたテストは当然通ります。1か所わざと実装を壊して、狙ったテストだけが落ちるかを確認してください。

E2Eテストを生成AIで作る手順

E2Eは、生成したコードがそのまま動く確率が単体テストより低くなります。画面の構造に依存するためです。ここで有効なのは、生成時に実際のブラウザで検証させるアプローチです。

以下ではPlaywrightを代表例として工程を説明しますが、これはPlaywrightに限った話ではありません。CypressやSeleniumを使う場合でも、「計画を立てる・コードに変換する・失敗を直す」という3工程に分ける考え方はそのまま使えます。ツール固有の機能に依存しない部分として読んでください。

代表例：Playwrightの3エージェント構成

Playwright公式のTest Agentsドキュメントでは、役割の異なる3つのエージェントが定義されています。この分け方は、生成AIでE2Eを作るときの工程設計としてそのまま参考になります。

重要なのは、Generatorがセレクタとアサーションを実際に動かしながら検証する点です。静的にコードを生成するだけの使い方と比べ、最初から動かない率が下がります。本記事の執筆時点で公式ドキュメントが挙げている前提はVS Code 1.105以上ですが、動作要件は更新されるため、導入前に公式ページで確認してください。エージェント定義はPlaywrightの更新ごとに再生成すべきとされています。

Healerを使うときの歯止め

自動修復は便利な反面、使い方を間違えると品質を下げます。落ちているテストを通す方向に寄せると、本来検出すべきリグレッションを握りつぶすことがあるためです。

歯止めとして決めておきたいのは次の3つです。

• 再実行は2〜3回で打ち切る。それ以上通らないものは人が見る

• アサーションの削除・緩和を含む修正は自動採用しない

• 修復の差分は必ずコミットを分け、レビューで見分けられるようにする

ロケータについては、生成AIは画面上の文言を掴みに行きがちです。文言はリリースのたびに変わります。data-testid属性のような、表示テキストから独立した識別子を先にアプリ側へ用意しておくと、生成されるテストの寿命が伸びます。この下準備は生成AIの導入前にやっておく価値があります。

Selenium資産が残っている現場では、移行判断が別途必要になります。Seleniumとは｜ブラウザ自動化・スクレイピングの基本と案件への影響を解説も参考にしてください。

AI生成テストの落とし穴と限界

ここが本記事の中心です。AI生成テスト特有の壊れ方には型があり、知っていれば数分のレビューで見抜けます。

壊れ方は4パターンに分類できる

トートロジーテスト。 実装をそのまま写しただけのテストです。実装が「価格×1.1」なら、テスト側でも同じ計算式を期待値として書いてしまう。実装を変えれば期待値も変わるため、どんな変更をしても落ちません。

見分け方は単純で、期待値がリテラル（110という具体的な数字）になっているかを見ます。期待値に計算式が入っていたら疑ってください。

アサーションが薄い。 呼び出しが例外を投げずに終わったことだけを確認し、返り値を見ていないテストです。nullが返っても通ります。「エラーにならないこと」だけを確かめているテストは、テストというより実行確認です。

過剰モック。 依存をすべてモック化した結果、テスト対象の実処理がほとんど通らなくなっている状態です。モックの設定を書き写す形でアサーションが組まれるため、「モックを呼んだことをモックで確認する」構図になります。

対策は、モックの対象を外部I/O（HTTP、DB、ファイル、時刻）に限定するルールを先に決め、プロンプトの制約ブロックに書いておくことです。

フレーキー（実行のたびに結果が変わる）。 現在時刻、ランダム値、実行順への依存が代表例です。生成AIは現在時刻の取得をそのまま使ったテストを書くことがあり、月末や年またぎで落ちます。

E2Eでは、待機処理を固定の秒数スリープで書いてしまうパターンが目立ちます。要素の出現を待つ仕組みに置き換えてください。

これら4つを1枚のチェックリストにまとめたのが、次の表です。

生成AIが苦手な領域と、人が書くべきテスト

結論として、判断基準が仕様書の外にあるテストは、生成AIに任せても精度が出ません。以下は人が主導する前提で考えたほうが安全です。

• 非機能要件のテスト：性能・負荷の目標値そのものが事業判断です。閾値を決められない相手に書かせても意味がありません

• セキュリティテスト：攻撃観点は「こう使われたら困る」という想定に依存します。網羅性をAIの知識に委ねるのは危険です

• マルチテナントの分離検証：他社データが見えないことの確認は、仕様の外にある前提知識が必要です

• 業務ドメイン固有の異常系：金融の営業日計算、医療の投薬ルールなど、ドメイン知識が判断を左右する領域

• UIの見た目・使い勝手：崩れの許容範囲は人の判断です

LLMを組み込んだプロダクションのテストは、さらに別の話になります。出力が確率的で固定の期待値を置けないためです。この領域はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説で扱っています。

AI生成テストの質をどう検証するか

テストが増えたことと、品質が上がったことは別です。ここを測る方法を持っておくと、案件でも説明できるようになります。

カバレッジの数字は目安にしかならない

AIにテストを大量生成させると、カバレッジは簡単に上がります。行を通るだけならアサーションがなくても数字は伸びるからです。80%を超えたという報告だけでは、品質の根拠になりません。

カバレッジは「テストされていない箇所を見つける」用途では有効です。「テストされている箇所が十分か」を判断する用途には向きません。

ミューテーションテストで「気づけるか」を測る

より実態に近いのが、ミューテーションテストです。要するに、実装に小さなバグを人工的に混ぜ込み、既存のテストがそれに気づけるかを確かめる方法です。演算子の反転や条件の除去といった書き換えを機械的に加え、テストが落ちるかを見ます。検出できなければ、そのテストは意味を持っていません。

JavaScript／TypeScript、C#、ScalaではStryker Mutator、Javaではpitestが代表的な選択肢です。実行コストは通常のテストより重くなるため、毎回のプッシュではなく週1回や夜間バッチで回す運用が現実的です。

AI生成テストは「通るが検出しない」テストが混ざりやすいため、この検証と特に相性が良い組み合わせになります。

レビュー観点チェックリスト

生成テストをマージする前に確認する項目を、実務で使っている順に並べます。

• 実装を1か所壊したとき、狙ったテストが落ちるか

• 期待値がリテラルで書かれているか

• モックの対象が外部I/Oに限定されているか

• 時刻・乱数が固定値として注入されているか

• テスト名から、何を保証しているかが読み取れるか

• 同じ条件のテストが重複していないか

• テストデータがドメイン上あり得る値になっているか

• 失敗時のメッセージで原因が特定できるか

ケース別の進め方

レガシーコードに保護網を張る

仕様書がなく、コードだけが残っている状況です。この場合は現状の挙動を固定する特性テストから入ります。生成AIとの相性は良く、短時間で広い範囲を覆えます。

ただし前述のとおり、これは「正しさ」ではなく「現状」を固定するものです。リファクタリング前の安全網としては機能しますが、バグの検出は期待できません。テストファイルの冒頭に、その旨と作成日を書き残しておいてください。

新規開発でテストを並走させる

仕様が文書化されているため、仕様を入力にしたテスト生成が使えます。実装より先にテスト観点を出させ、観点をレビューしてからコードを書く進め方が取りやすくなります。

観点の洗い出しは、生成AIが比較的得意な工程です。人が思いつかない異常系が出てくることもあります。採用するかどうかは人が決め、不要な観点は削ります。

CIで落ちているテストを直す

既存テストが落ちたとき、原因の切り分けに生成AIを使うケースです。失敗ログ、対象コードの差分、テストコードの3点を渡すと、当たりをつけやすくなります。

ここで気をつけたいのは、修正の方向です。実装のバグでテストが落ちているのに、テスト側を通るように直してしまうと、検出したはずの不具合を消してしまいます。「実装とテストのどちらが間違っているか」を先に判断してから修正に入ってください。

案件でこのスキルはどう見られるか

まず短答として、テスト自動化の経験は単体で単価を押し上げる要素というより、開発案件の中で評価が加点される性質のスキルです。公開されている案件情報を見る限り、「テスト自動化担当」として切り出された募集より、開発ポジションの要件欄にPlaywrightやpytestが並ぶ形のほうが目立ちます。

この節の記述は、2026年9月時点で首都圏を中心とする主要フリーランスエージェント数社の公開案件ページを対象に、テスト自動化・QA関連の募集を確認した範囲での観測です。週3〜5日稼働の準委任案件を中心に見ており、確認できたのは数十件規模にとどまります。統計調査ではないため、傾向をつかむ材料として読んでください。非公開案件は個別条件で内容が大きく変わるため、ここには含めていません。

その範囲では、生成AIを使ったテスト作成そのものを要件に掲げる募集は限定的でした。一方で、AIツールの利用を前提とした開発案件は公開案件でも見られ、その中でテスト品質を担保できることが差別化になります。

スキルシートへの書き方

「生成AIを使ってテストを書けます」という書き方では、評価につながりません。何をどう改善したかを数値で示すほうが伝わります。

• どのレイヤーのテストを、どのくらいの規模で整備したか（例：単体テスト400ケース、E2E 60シナリオ）

• 導入前後で何が変わったか（リグレッション検出のタイミング、リリース前の手動確認工数）

• 品質の検証をどう行ったか（ミューテーションスコア、意図的な実装破壊での検出確認）

書き方の型はQAエンジニアのスキルシートの書き方｜品質実績の数値化と職種別テンプレが参考になります。品質保証寄りのポジションで動く場合の単価感はQAエンジニアのフリーランス単価相場｜案件動向と単価アップの条件にまとめています。

自分の経歴だとどのくらいの単価帯を狙えるのかを確かめたい方は、無料のフリーランスエンジニア単価診断で目安を確認できます。テスト関連の募集を実際に見たい場合は、テストエンジニアの案件一覧から探せます。

案件に入る前の導入チェックリスト

生成AIをテスト工程に組み込む前に、次の項目を確認しておくと立ち上がりが早くなります。

1. テスト方針（何をどのレイヤーで担保するか）が文書になっているか

2. コードを外部AIサービスに送信してよいか、契約上の確認が済んでいるか

3. data-testidなど、表示テキストに依存しない識別子が用意されているか

4. 生成テストのレビュー基準がチームで共有されているか

5. 時刻・乱数を固定値に差し替える仕組みがあるか

6. CIでテストが落ちたときの一次対応者が決まっているか

7. AI生成であることがコミットやPRから判別できるか

2番目は特に、フリーランスとして客先の案件に入る場合の必須確認事項です。ソースコードの外部送信を禁じている現場は珍しくありません。契約上の扱いはGitHub Copilotの使い方｜エンジニアの開発効率と案件単価への影響を解説でも触れています。

まとめ

生成AIはテストコードを書く工数を確実に減らしますが、何をテストすべきかを決める工程と、生成物を検証する工程は人に残ります。増えたテストが品質につながるかは、レビュー基準を先に決められるかで決まります。

• 実装コードをそのまま渡すと、バグごとテストに固定される。仕様・観点を先に言語化する

• 単体テストは任せやすく、E2Eはロケータ設計とテストデータの前提を人が用意してから広げる

• 生成テストの壊れ方はトートロジー・薄いアサーション・過剰モック・フレーキーの4型。レビューはここから見る

• 実装を1か所壊して狙ったテストが落ちるかを確認する。これが最も速い検証方法

• カバレッジは不足箇所の発見に使い、十分性はミューテーションテストで測る

• 客先の案件では、コードの外部送信可否を契約面で先に確認する

次の一歩としては、既存プロジェクトのテストを1ファイル選び、実装をわざと1か所壊してみてください。落ちないテストが混ざっていれば、そこが生成AIを入れる前に整えるべき場所です。

参照した一次情報は以下のとおりです。

• DORA State of AI-assisted Software Development（2025年）

• Stack Overflow Developer Survey 2025 AIセクション

• Playwright公式ドキュメント Test Agents

• GitHub Copilot公式ガイド Write tests

• Stryker Mutator公式サイト