AIでテストを書く方法：実務5手順と判断軸

AIでテストを書く方法を知りたいなら、まず押さえるべきなのは、何をAIに任せ、何を人が判断するかである。生成AIは、仕様整理、テスト観点の洗い出し、テストコードの下書き、失敗ログの要約までかなり速い。だが、最終的な合否判断まで丸投げすると、テストが増えても安心感は増えない。

対象は、Webサービスやアプリを作る開発者、QA担当、少人数チームで品質管理も兼ねる実務者だ。使う場所は、ChatGPTやClaudeなどの生成AI、そしてPlaywrightやJest、Cypressのようなテストツールである。今すぐ使えるが、万能ではない。そこを先に理解しておくと、AIテストは「派手なデモ」ではなく「現場で効く補助輪」になる。

なお、ここでいうテストは、単にコードが動くかを確かめる作業ではない。仕様のズレや壊れやすい導線を早く見つけるための、品質の見張り台である。AIはその見張り台を高くするのが得意だが、見張る方向まで決めてくれるわけではない。

AIでテストを書く流れの全体像

結論は、AIをテストの代行者ではなく、設計と整理の加速装置として使うのが最も実用的である。まず仕様を読み、次に観点を並べ、最後にテストコードやログ分析へ進む。この順番を崩さないだけで、出力のブレはかなり減る。

AIに向くのは、文章化しやすく、候補を大量に出せる工程だ。たとえば「ログイン時の異常系を洗い出して」「この画面の境界値を列挙して」といった依頼は得意である。一方で、どのケースを先に守るべきかという優先順位は、人間の責任になる。ここを見失うと、テストは増えるが守るべき場所がぼやける。少し残念な“全部入り冷蔵庫”状態だ。

編集部としては、AIで増やすべきなのはテストの本数ではなく、判断の初速だと見る。要件の読み込みに30分、観点出しに10分、コード化に40分かかっていたなら、AIはそのうち前半の詰まりをかなり減らせる。逆に、観点が固まっていないままコードだけ量産すると、きれいなファイルが並ぶだけで、実戦では弱い。

OpenAIの公式ドキュメントでは、モデルにどう指示を与えるかの基本が確認できる。テスト用途でも、入力の粒度が出力の質を左右する点は同じだ。OpenAI Platform Documentationを見ておくと、AIへの依頼文をどう整えるべきかの勘所がつかみやすい。

ユニットテストとE2Eの使い分け

ユニットテストはロジックの守り、E2Eはユーザー導線の守りと考えるとわかりやすい。AIは両方に使えるが、役割は別物である。ユニットテストは速くて壊れにくく、E2Eは画面全体の流れを確認できる。だが、全部をE2Eで覆うのは、金槌しか持っていない人が全てを釘に見えてしまうのに似ている。

AIで最初にやるべきなのは、ユニットテスト向けの観点を広く洗い出すことだ。分岐条件、境界値、例外ケース、空入力、権限不足などを列挙させると抜けが減る。そのうえで、重要導線だけをE2Eに回す。ログイン、決済、検索、フォーム送信のような、ビジネスに直結する箇所を優先するのが現実的である。

ここで見落としがちなのは、「テストが多いこと」と「壊れにくいこと」は別だという点だ。ユニットテストが少なすぎるとロジックの穴が残り、E2Eが多すぎると保守コストが膨らむ。AIはその中間を探るのに向くが、最終的な配分は人が決める必要がある。ちょっと地味だが、品質管理の肝はいつも地味だ。

Playwrightは、ブラウザ操作を自動化する代表的な選択肢だ。公式ドキュメントを読むと、何を自動化し、何を人が確認するのかが整理しやすい。Playwrightの公式入門は、E2Eの基本を押さえる起点として使いやすい。

編集部としては、ユニットテストを土台にしてE2Eを上澄みとして載せる構成が最も安定すると見る。逆に、E2Eを先に増やしすぎると、画面変更のたびに赤ランプが灯り、テストが“アラート係”になってしまう。品質保証なのに毎日ヒヤッとするのは、あまり健康的ではない。

AIに渡すプロンプト設計のコツ

AIテストの出来は、プロンプトで半分決まる。ここでいうプロンプトとは、AIへの指示文のことだ。雑に「テストを書いて」と投げるより、仕様、前提、期待結果、制約、優先順位を分けて伝えたほうが圧倒的に安定する。

たとえば、次のように書くとよい。ポイントは、AIに自由に想像させる範囲と、固定すべき範囲を分けることだ。想像が必要なのは観点の列挙であり、固定すべきなのは仕様の事実である。

• 対象機能: ログイン画面、パスワード再設定、検索フィルタなどを明示する
• 前提条件: 既存ユーザー、新規ユーザー、権限なしなどを示す
• 期待結果: 画面遷移、エラーメッセージ、保存状態を具体化する
• 制約: 実行時間、外部API依存、モックの有無を入れる
• 出力形式: 表形式、箇条書き、テストコードのどれにするかを指定する

AIは曖昧な指示でもそれなりに返してくるが、それは“それなり”である。仕様書が短すぎると、AIは平均点の回答を返し、現場がほしい一点突破の観点は出てこない。見落としがちなのは、AIに与える情報を増やすほど良いのではなく、必要な情報だけを揃えるほうが強い点だ。入力の掃除は地味だが、かなり効く。

Claudeのような生成AIでも考え方は同じである。モデル名が違っても、テストケース生成のコツは大差ない。仕様の抜けを補わせたいのか、コードのひな形を作らせたいのか、失敗ログを整理させたいのかを最初に分けると、出力のブレは減る。

もし既存のテスト方針があるなら、その文書を先に要約させるのも手だ。AIは長い資料を短く圧縮するのが得意で、そこから不足ケースを追加する流れが作りやすい。仕様の原文を貼る前に、まず自分で「何が不足しているか」を一言で言えると、プロンプトは一段よくなる。

同じ発想は、開発支援AIの活用全般にも通じる。コード生成でも、まず小さな単位で試すほうが失敗しにくい。以下の記事で詳しく紹介している。

AIテスト導入で見落としがちな点

いちばん見落としがちなのは、AIより先に運用ルールが壊れることである。機密情報の扱い、レビュー権限、テストデータ、ログ保存のルールが曖昧だと、便利な仕組みはすぐに不安定になる。品質の話なのに、気づけば情報管理の話に寄っていく。現場あるあるだ。

とくに注意したいのは、本番データや個人情報をそのままAIへ貼らないこと、AIの提案は必ず人がレビューすること、そしてE2Eを増やしすぎず重要導線に絞ることだ。ここを守らないと、便利な仕組みがむしろノイズを増やす。テストが守りのはずなのに、運用の火種を増やすのは本末転倒である。

• 本番データや個人情報をそのままAIへ貼らない
• AIの提案は必ず人がレビューする
• E2Eを増やしすぎず、重要導線に絞る
• テスト名を曖昧にしない
• 失敗ログの保存場所と共有範囲を決める

編集部としては、AIテストの価値は「自動化できること」より、判断の準備を速くすることにあると見る。観点の洗い出し、ケースの整列、失敗理由の整理が速くなるだけでも、開発のテンポはかなり変わる。逆に、AIに全部やらせる発想は危うい。そこは料理で言えば、火加減を見ずに鍋を任せるようなものだ。

AIでテストを書くときの比較対象としては、手書きのテスト設計、既存のテストフレームワーク単独運用、AI併用の3つがある。手書きは精度が高いが時間がかかる。フレームワーク単独運用は仕組みが安定しているが、観点の抜けは人に依存する。AI併用は、初速と抜けの発見に強い。現時点での判断軸は、「全部AIにするか」ではなく「どこをAIで速くするか」に置くべきだ。

なお、AIが出したテストケースの中には、理屈は通るが運用には重いものも混ざる。たとえば、毎回外部APIに依存するテストや、画面変更のたびに壊れるシナリオは、見た目は立派でも長持ちしない。テストの強さは、華やかさではなく維持のしやすさで決まる。ここは静かな勝負だ。

この記事のポイント

• AIはテストの代行役ではなく、観点出しと整理を速くする補助役として使うのが現実的である。
• ユニットテストはロジック、E2Eは導線確認に強く、Playwrightはブラウザ自動化の中心になる。
• プロンプトは仕様、前提、期待結果、制約を分けて書くと安定しやすい。
• 失敗ログは要約だけでなく、再現条件と知りたいことをセットで渡すと分析しやすい。
• 導入は1機能から始め、変更に強いテストを少数精鋭で回すのが成功しやすい。

参考情報（主要ソース）

• OpenAI Platform Documentation
• Playwright Official Documentation
• Jest Documentation
• Cypress Documentation
• GitHub Actions Documentation

参考までに、AIでブログ記事を作る流れも、構成整理やファクト確認を先に固めると品質が上がる。テスト設計と似た考え方で動くため、情報の並べ方の参考になる。以下の記事で詳しく紹介している。

失敗ログの読み方と再現手順

失敗ログは、原因を当てる材料というより、再現条件を整える地図である。AIは長いログを短く要約し、似たエラーを分類するのが得意だ。だが、原因の断定は別だ。そこを混同すると、推理ドラマの犯人を早とちりする探偵のようになる。

実務では、ログを貼るだけでなく、最低でも次の3点を添えると精度が上がる。これだけで、AIの返答はかなり実用寄りになる。逆に、ログだけを投げると、エラーメッセージの表面をなぞった要約で終わりやすい。

• 何をしたか: 操作手順、入力値、事前条件
• 何が起きたか: エラー文、失敗したステップ、タイムスタンプ
• 何を知りたいか: 原因候補、再現方法、修正の優先度

ここで重要なのは、AIが返した要約をそのまま採用しないことだ。タイムアウト、セレクタ変更、API遅延、権限エラーなどは見た目が似ていても対処は違う。現時点で注目すべきは、AIの分析力よりも、ログの粒度が足りないと誤判定が起こりやすいことである。入力が粗いと、出力も当然ざっくりになる。

AIに再現手順を作らせるときは、1回で完璧を狙わないほうがよい。まず「失敗した画面にたどり着くまでの手順」を作り、次に「失敗直前の入力値」を足し、最後に「本当に失敗するか」を人が確認する。再現手順は短ければよいのではなく、誰が読んでも同じ失敗にたどり着けることが大事だ。

GitHub ActionsのようなCI/CD（継続的インテグレーション/継続的デリバリー）基盤でテストを回しているなら、どのジョブで落ちたか、どのブランチで再現したかまで整えておくと分析が速い。GitHub Actions Documentationを見て、実行単位とログの残し方を確認しておくと、AIの要約も扱いやすくなる。

Jestのようなユニットテストフレームワークも、失敗時の出力を読む習慣と相性がよい。Jest Documentationでは基本的な書き方を確認できる。AIにテストを書かせるとしても、失敗したときに人が読める形にしておくことが、結局いちばんの近道だ。

導入手順の現実解

最初から全テストをAI化する必要はない。むしろ、1機能だけで小さく始めたほうが成功しやすい。変更の多い画面、問い合わせが多い導線、バグが繰り返し出る処理など、痛みが見えやすい場所を1つ選ぶのがよい。

流れは次の5段階が扱いやすい。ここで大切なのは、各段階を独立した作業に見せないことだ。要件整理が甘ければケース設計がぶれ、ケース設計が甘ければコード化で迷い、最後はログ分析が雑になる。工程は一直線ではなく、行ったり来たりする。

• 1. 仕様を整理する
• 2. AIに観点を出させる
• 3. 優先度の高いケースを3〜5本に絞る
• 4. PlaywrightやJestでコード化する
• 5. 失敗ログをAIで要約し、修正と再実行を回す

この流れで大事なのは、網羅性より変更耐性である。100本のうち10本が壊れやすいテストより、10本のうち10本がちゃんと守ってくれるテストのほうが、現場では頼りになる。導入直後は派手さより、静かに効くことを優先したい。

導入時のチェックポイントも決めておくとよい。たとえば、実行時間が長すぎないか、CIで安定して通るか、レビューのたびに手戻りが増えないか、テスト名だけで意図が伝わるか、である。テストは作って終わりではなく、回して守れるかが本番だ。

同じ発想は、開発支援AIの活用全般にも通じる。コード生成でも、まず小さな単位で試すほうが失敗しにくい。以下の記事で詳しく紹介している。

AIテスト導入で見落としがちな点

いちばん見落としがちなのは、AIより先に運用ルールが壊れることである。機密情報の扱い、レビュー権限、テストデータ、ログ保存のルールが曖昧だと、便利な仕組みはすぐに不安定になる。品質の話なのに、気づけば情報管理の話に寄っていく。現場あるあるだ。

とくに注意したいのは、本番データや個人情報をそのままAIへ貼らないこと、AIの提案は必ず人がレビューすること、そしてE2Eを増やしすぎず重要導線に絞ることだ。ここを守らないと、便利な仕組みがむしろノイズを増やす。テストが守りのはずなのに、運用の火種を増やすのは本末転倒である。

• 本番データや個人情報をそのままAIへ貼らない
• AIの提案は必ず人がレビューする
• E2Eを増やしすぎず、重要導線に絞る
• テスト名を曖昧にしない
• 失敗ログの保存場所と共有範囲を決める

編集部としては、AIテストの価値は「自動化できること」より、判断の準備を速くすることにあると見る。観点の洗い出し、ケースの整列、失敗理由の整理が速くなるだけでも、開発のテンポはかなり変わる。逆に、AIに全部やらせる発想は危うい。そこは料理で言えば、火加減を見ずに鍋を任せるようなものだ。

AIでテストを書くときの比較対象としては、手書きのテスト設計、既存のテストフレームワーク単独運用、AI併用の3つがある。手書きは精度が高いが時間がかかる。フレームワーク単独運用は仕組みが安定しているが、観点の抜けは人に依存する。AI併用は、初速と抜けの発見に強い。現時点での判断軸は、「全部AIにするか」ではなく「どこをAIで速くするか」に置くべきだ。

なお、AIが出したテストケースの中には、理屈は通るが運用には重いものも混ざる。たとえば、毎回外部APIに依存するテストや、画面変更のたびに壊れるシナリオは、見た目は立派でも長持ちしない。テストの強さは、華やかさではなく維持のしやすさで決まる。ここは静かな勝負だ。

この記事のポイント

• AIはテストの代行役ではなく、観点出しと整理を速くする補助役として使うのが現実的である。
• ユニットテストはロジック、E2Eは導線確認に強く、Playwrightはブラウザ自動化の中心になる。
• プロンプトは仕様、前提、期待結果、制約を分けて書くと安定しやすい。
• 失敗ログは要約だけでなく、再現条件と知りたいことをセットで渡すと分析しやすい。
• 導入は1機能から始め、変更に強いテストを少数精鋭で回すのが成功しやすい。

参考情報（主要ソース）

• OpenAI Platform Documentation
• Playwright Official Documentation
• Jest Documentation
• Cypress Documentation
• GitHub Actions Documentation