AIのテスト自動生成｜任せる範囲と人が見る確認項目

AIにテストを自動生成させる動きが、システム開発の現場で広がっています。この記事では、AIが得意なテストと苦手なテスト、AIが作ったテストに起きやすい落とし穴、そして人が確認すべき項目を整理します。新規事業でシステムを作るときに、テストのどこまでをAIに任せ、どこから人が見るのかを判断する材料になれば幸いです。

AIのテスト自動生成で、任せやすいことと任せにくいこと

テストとは、作ったプログラムが意図どおりに動くかを確かめる作業です。AIにテストを書かせるといっても、テストには種類があり、AIとの相性は一様ではありません。まず、種類ごとに任せやすさを整理します。

任せやすいテスト

AIが比較的得意なのは、入力と出力の関係がはっきりしていて、コードを読めば書ける種類のテストです。

• 単体テスト：関数やクラスなど、小さな部品が単独で正しく動くかを確かめるテスト。入力と期待する出力が明確なため、AIが大量に書きやすい領域です。
• 境界値のテスト：「0件」「1件」「上限ぴったり」「上限を1つ超えた場合」といった、境目の値を試すテスト。人が見落としやすい境目の候補を、AIが網羅的に挙げてくれることがあります。
• テストデータの作成：日付、金額、文字列の長さなど、さまざまなパターンのデータを用意する作業。手作業では手間のかかる部分です。
• 回帰テストの追加：不具合を直したあとに、同じ不具合が再発しないかを確かめるテスト。「回帰」とは、直したはずのものが元に戻ってしまうことを指します。
• 画面操作テストの雛形づくり：ブラウザ上で実際に画面を操作する自動テスト（E2Eテストと呼ばれます）の下書きです。

これらに共通するのは、「何が正しいか」がすでにはっきりしている点です。正解が明確な作業ほど、AIは速く、広く書くことができます。

任せきりにしにくいテスト

反対に、次のようなものは、AIだけでは判断材料が足りません。

• 業務ルールの正しさを確かめるテスト：たとえば「キャンセル料は何日前から発生するのか」「会員ランクごとの割引をどう重ねるのか」。この正解は、コードの中ではなく事業の側にあります。
• 使い勝手の確認：画面の迷いやすさ、文言の分かりやすさなどは、実際に触った人の感覚が必要です。
• 本番に近い負荷や運用状況の確認：アクセスが集中したときの挙動や、障害時の復旧手順などです。
• セキュリティの観点：権限のない人が情報を見られないか、といった確認です。この点は、別の記事「AI生成コードのセキュリティ｜確認点と人の役割」でも詳しく触れています。

つまり、「コードから読み取れること」はAIに、「事業や利用者の側にしか答えがないこと」は人に、という分け方が基本になります。

AIが作ったテストに起きやすい4つの落とし穴

AIが書いたテストは、見た目はきれいに整っています。だからこそ、中身の確認が後回しになりがちです。起きやすい落とし穴を4つ挙げます。

1. 実装をなぞるだけのテストになる

AIにコードを渡してテストを書かせると、「今のコードがこう動くから、こう動くはず」というテストが出来上がることがあります。コードの挙動をそのまま期待値に写しているため、コードに間違いがあっても、テストは通ってしまいます。

たとえば、消費税の計算でコードが端数を切り捨てていたとします。本来は事業のルールで切り上げと決まっていたとしても、実装をなぞったテストは切り捨ての結果を「正しい」として保証してしまいます。テストが通っていることと、正しいことは別の話です。

2. 数字上のカバレッジは高いが、確認が浅い

カバレッジとは、テストがプログラムのどれくらいの範囲を実行したかを示す指標です。AIはこの数字を上げるテストを、短時間でたくさん書けます。

ただ、プログラムを「実行した」ことと、「結果を正しく検証した」ことは違います。結果を確かめる記述（アサーションと呼ばれます）が弱いテストは、実行はしても何も確認していないのと変わりません。カバレッジの数字だけで安心すると、この落とし穴に気づきにくくなります。

3. モックが本物の問題を隠す

モックとは、外部の仕組み（決済、メール送信、他社のAPIなど）を、テスト用の偽物に置き換える手法です。テストを速く安定して動かすために、よく使われます。

AIは、テストを通しやすくするためにモックを多用することがあります。その結果、偽物の部分では問題がなくても、本物とつないだとたんに動かない、ということが起きます。外部サービスの実際の応答形式や、エラー時の挙動がモックに正しく反映されているかは、人が確かめたい点です。

4. 仕様の誤解が、コードとテストの両方に入る

要件が曖昧なままAIにコードとテストの両方を書かせると、同じ誤解が両方に入り込みます。両者が一致しているため、テストは通り、誤りが表に出ません。これは「同じ作り手が、作ったものを自分で確かめる」ときに起きる、人間の開発でも知られた問題です。

この問題を防ぐには、要件を先に人が言葉にしておくことが欠かせません。要件の整理については「AI要件定義で変わること｜AIが整理し人が決める範囲」、抜け漏れを防ぐ進め方については「要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方」もあわせてご覧ください。

人が見るべき確認項目

ここからは、AIが生成したテストを前にしたとき、人が確かめたい項目を順に整理します。専門的なコードの読解がすべてできなくても、次の問いに答えられるかどうかで、確認の質は大きく変わります。

確認1：テストの根拠が、要件や受け入れ条件にひもづいているか

テスト一つひとつが、「どの要件を確かめているのか」に説明がつくかを見ます。受け入れ条件（「こうなっていれば完成とみなす」という基準）を先に書いておき、それぞれに対応するテストがあるかを一覧にすると、抜けが見つかります。

逆に、どの要件にもひもづかないテストが大量にある場合は、コードの挙動をなぞっているだけの可能性があります。

確認2：期待値が、事業のルールと合っているか

期待値とは、「この入力なら、結果はこうなるはず」という正解の値です。金額計算、料金の区分、日付の扱い、ステータスの遷移など、事業に固有のルールが絡む部分は、期待値を人が読んで確かめます。

AIが書いた期待値の数字を、電卓や表計算ソフトで検算するだけでも、意味のある確認になります。ここは、事業を理解している人にしかできない役割です。

確認3：わざとコードを壊して、テストが失敗するか

テストの質を確かめる実践的な方法が、コードを意図的に少し変えてみることです。たとえば「以上」を「より大きい」に書き換える、計算式の符号を逆にする、といった変更です。このとき、テストが失敗すれば、そのテストはちゃんと役目を果たしています。変更しても通ってしまうなら、そのテストは何も守っていません。

この考え方を自動化した手法は、ミューテーションテストと呼ばれます。ツールを使えば広い範囲を機械的に調べられますし、使わなくても、重要な箇所だけ手で試すことはできます。

確認4：異常な入力、境目、権限が考えられているか

AIは、うまくいく経路（正常系）のテストを手厚く書く傾向があります。人が補いたいのは、うまくいかない経路です。

• 空欄、極端に長い文字列、想定外の形式のデータが入ったとき
• 通信が途中で切れたとき、外部サービスが応答しないとき
• 同じ操作が二重に実行されたとき（ボタンの連打など）
• 権限のない利用者が、他人のデータを見たり変更したりしようとしたとき

全部をテストする必要はありません。事業にとって損害の大きいものから優先して、テストがあるかを見ます。

確認5：テストデータと環境が、実際の利用に近いか

テストに使うデータが、「山田太郎」「テスト株式会社」のような整いすぎた値ばかりだと、現実の入力で起きる問題を拾えません。全角と半角の混在、旧字体、長い住所、空白の混入など、実際の利用で起きがちなパターンが含まれているかを確かめます。

あわせて、テストを動かす環境が本番とどれくらい近いかも確認します。本番と違う設定でだけ通っているテストは、安心の根拠になりません。

確認6：不安定なテストや、実行に時間がかかりすぎるテストがないか

実行するたびに結果が変わるテストは、「フレーキーなテスト」と呼ばれます。日付や乱数、実行順序に依存して起きることが多く、AIが書いたテストにも含まれることがあります。

こうしたテストが混ざると、「たまに落ちるが、いつものことだろう」と見過ごす習慣がつき、本当の不具合を見逃す原因になります。また、全体の実行に時間がかかりすぎると、開発のたびに回されなくなります。テストが日常的に回り続ける状態を保てているかも、見る価値のある点です。

確認項目のまとめ表

確認項目	見るポイント	主に判断する人
要件とのひもづけ	各テストがどの受け入れ条件を確かめているか	事業側・発注側
期待値の正しさ	金額・日付・状態遷移などが事業ルールと合うか	事業側・発注側
テストの強さ	コードを壊したときにテストが失敗するか	開発側
異常系・権限	うまくいかない場合や権限外の操作が考えられているか	双方
データと環境	実際の利用に近い値・設定で試しているか	双方
安定性・実行時間	結果がぶれない、日常的に回せる速さか	開発側

「誰が判断するか」を最初から分けておくと、確認が特定の人に偏らずに済みます。AIが関わる開発全体で、人がどこを確認するのかについては「AI開発でも品質には人の確認が必要な理由」でも整理しています。

テストを書かせる前に決めておきたい役割分担

確認項目を並べると、一つの共通点が見えてきます。AIが作ったテストを後から直すより、テストを書かせる前に、人が決めておくほうが効果的な事柄が多いということです。

受け入れ条件は、人が先に言葉にする

「何ができれば完成なのか」を、日本語の短い文章で先に書いておきます。たとえば「注文後24時間以内なら、利用者はキャンセルでき、返金処理が開始される」といった具合です。この文章を材料にAIにテストを書かせれば、コードをなぞるテストではなく、要件に沿ったテストになりやすくなります。

テストの観点は、AIに出させて、人が足し引きする

AIに「この機能で確かめるべき観点を挙げて」と頼むと、人が思いつかない観点を出してくれることがあります。そのうえで、事業にとって重要でないものを外し、事業固有の観点を足す。この「AIが広げて、人が絞る」流れは、テストの設計に向いた分担です。

結果の確認は、レビューとセットにする

テストを書いたAIとは別の仕組みや人が、テストの中身をレビュー（点検）する形にすると、同じ誤解が両方に入り込む問題を減らせます。AIによるコードレビューの機能も広がっており、Claude Codeのレビューが一般提供になり、深さを選べるようになった話題も最近ありました。ただ、こうした機能を使っても、最終的に「これでよい」と判断する役割は人に残ります。

AIが書いたコードを安全と動作の両面から測るベンチマーク（比較のための評価基準）を扱ったLSCBenchの記事も参考になります。動くことと安全であることの両立は、AIにとってもまだ難しい課題として語られており、テストでも両面を見る必要があります。

新規事業では、テストの深さを段階で変える

ここまで読むと、「すべてを丁寧に確認するのは大変だ」と感じるかもしれません。新規事業では、すべてのテストを最初から同じ深さで行う必要はありません。事業の段階に応じて、テストにかける力の配分を変えるのが現実的です。

プロトタイプの段階

事業の仮説を確かめる段階では、「動くかどうか」「利用者が使いたいと思うか」を知ることが主目的です。この段階では、中心になる流れが正しく動くかを重点的に確かめ、細かな異常系や性能は後回しにする判断もあり得ます。プロトタイプでの確かめ方は、「プロトタイプのユーザーテスト｜新規事業での確かめ方と質問」で扱っています。

ただし、後回しにしたものは「何を後回しにしたか」を残しておくことが大切です。あとから本開発に進むとき、確認していない部分が見えなくなると、思わぬ不具合の原因になります。

本開発・運用の段階

実際の利用者やお金、個人情報を扱い始める段階では、テストの深さを上げます。特に、決済、権限、個人情報、外部サービスとの連携は、事業への影響が大きいため、人が期待値と異常系を丁寧に確認する価値があります。

保守を見据えたテストの残し方

テストは、納品時に一度確かめて終わりではなく、機能を追加するたびに「以前の機能が壊れていないか」を確かめる土台にもなります。AIが書いたコードを後から引き継いで直すときに、テストがあるかどうかで作業のしやすさは変わります。この観点は「AI生成コードの保守は可能か｜引き継ぎと改修の確認点」にまとめています。

また、検証の指標を先に決める考え方は、テストにも通じます。何を確かめれば「次に進んでよい」と言えるのかを先に決めておく点は、MVP検証の指標を先に決める方法と同じ発想です。

まとめ

AIによるテストの自動生成は、単体テスト、境界値、テストデータの作成のように、正解がはっきりしている作業で力を発揮します。一方で、実装をなぞるだけのテスト、確認の浅いカバレッジ、モックによる問題の隠れ、仕様の誤解の二重化といった落とし穴もあります。

人が見るべき点は、次の6つに整理できます。

• テストが要件や受け入れ条件にひもづいているか
• 期待値が事業のルールと合っているか
• コードをわざと壊したときにテストが失敗するか
• 異常な入力、境目、権限が考えられているか
• テストデータと環境が実際の利用に近いか
• 不安定なテストや遅すぎるテストがないか

AIにテストを書かせる前に、受け入れ条件を人が言葉にしておくこと。そして事業の段階に応じて、確認の深さを調整すること。この2点が、AIの速さを活かしながら品質を保つための土台になります。AI駆動開発全体の役割分担については、「AI駆動開発とは｜AIと人の役割分担と発注側の要点」もご参照ください。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく受託開発サービスです。開発にはAIを活用した独自の開発基盤「LAF」を使い、要件定義、設計、実装、テスト、レビューをそれぞれ担う専門のAIが開発を進めます。そのうえで、人は「何を作るかを決めること」と「品質の最終判断」を担います。サービスの詳細はJustFitのサービス紹介をご覧ください。