AIのテストコード書き方入門｜安全に作るための5つのステップ

AIにテストコードを書かせても大丈夫なの？
安全なテストコードの書き方を今すぐ知りたい！

「テストコードは大事だとわかっているけど、書く時間がなかなか取れない」、そう感じている方も多いと思います。

実は、AIにテストコードを書かせる作業は、正しい手順と注意点さえ押さえれば、入門者でも十分に安全に進められます。

この記事では、AIでテストコードを書く5つのステップと、私が実際につまずいた落とし穴を、そのまま共有します。

AIでテストコードを書くとは？入門者が知っておきたい基本

AIにテストコードを書かせるというのは、単に「テストを自動生成してもらう」ことではありません。

ここでは、以下の内容について詳しく解説します。

テストコードがなぜ必要なのか

テストコードとは、書いたコードが期待通りに動くかどうかを自動で確認するためのコードです。

手で毎回動作確認をしていると、修正のたびに同じ手順を繰り返すことになり、時間がどんどん奪われます。

テストコードがあれば、コマンド一つで全体の動作を数秒〜数十秒で確認できます。

修正によって別の箇所が壊れていないかを機械的に検知できるという点が、テストコード最大の価値です。

「バグを未然に防ぐ」というより、「バグにすぐ気づける状態を作る」と捉えると、必要性が実感しやすいと思います。

特にチーム開発では、自分以外の誰かが書いたコードを修正する機会が多く、その人が仕様を完全に把握していないことも珍しくありません。

そんなときでも、テストコードさえ整っていれば、修正後にコマンドを実行するだけで壊れた箇所を教えてくれます。

AIにテストを書かせる基本的な流れと向き不向き

AIにテストコードを書かせる基本の流れは、仕様を伝える、AIに生成させる、人がレビューする、の3工程です。

この3工程さえ守れば、AIに任せる部分と人が判断する部分の境界がはっきりします。

すべての工程をAI任せにしてしまうと、後述する落とし穴にそのままハマってしまうので注意してください。

向いているのは、入力と出力の関係がはっきりしたユニットテストです。

逆に、画面をまたいだE2Eテストや、業務ドメイン特有の判断が絡む統合テストは、AI単独では設計が難しい領域です。

生成AIコードの読み方にも書きましたが、AIが出したコードをそのまま読まずに使うと、あとで痛い目を見ます。

テストコードも同じで、AIが何を保証しようとしているコードなのかを、まず自分の頭で理解することが出発点になります。

AIにテストコードを書かせる5つのステップ

ここから、実際にAIでテストコードを書くときの手順を5つのステップに分けて説明します。

【ステップ1】仕様と使用例を明確にする

最初にやるべきことは、AIに丸投げすることではなく、何を保証したいコードなのかを自分の言葉で書き出すことです。

関数の入力と出力、想定している正常系、そして起きてほしくない異常系を、箇条書きで整理します。

仕様書をAIで作成する方法で紹介した手順と同じ考え方で、まず仕様を言語化しておくと、この後のステップが驚くほどスムーズになります。

ここを省略してAIに「テストを書いて」とだけ頼むと、AIは表面的な動作しか保証しないテストを返してくることが多いです。

手間に感じるかもしれませんが、この言語化こそが、あとで自分がテストコードを読み返すときの説明書にもなります。

【ステップ2】テストの観点を洗い出す

仕様が固まったら、次はその仕様のどこをテストで確認するのか、観点を洗い出します。

境界値、空文字、最大値・最小値など、開発者が見落としがちなケースをここでリストアップしておきます。

この段階で観点を紙やメモに書き出しておくと、AIに依頼するときの指示が具体的になります。

逆に観点を洗い出さずにAIへ丸投げすると、AIは典型的なケースしか思いつかず、実務で問題になる境界値を見落とします。

観点の洗い出しは地味な作業ですが、ここでの精度がそのままテストコード全体の網羅性に直結します。

【ステップ3】AIにプロンプトでテストケースを出力させる

観点が揃ったら、いよいよAIにプロンプトを投げてテストケースを出力してもらいます。

ポイントは、対象の関数、仕様、洗い出した観点をワンセットで渡すことです。

下記は、Claude Codeに渡すプロンプトの一例です。

以下の関数に対するJestのユニットテストを書いてください。

関数: validateEmail(email: string): boolean
仕様:
- 「@」を含み、ドメイン部分にドットがある文字列はtrueを返す
- 空文字・null・undefinedはfalseを返す
- 「@」が2つ以上ある文字列はfalseを返す

テストしてほしい観点:
- 正常な形式のメールアドレス
- 空文字とnullのケース
- 「@」が複数あるケース
- 前後に空白が入っているケース

このように仕様と観点を明示すると、AIは「何を確認すればよいか」を推測せずに済むので、精度の高いテストコードを返してくれます。

【ステップ4】生成されたコードをレビューする

AIが出力したテストコードは、そのまま実行する前に必ず人の目でレビューします。

AIによるコードレビューの方法でも触れましたが、レビューの視点はテストコードでも基本的に同じです。

特に確認したいのは、アサーション（期待値の検証部分）が本当に意味のある値を比較しているかどうかです。

「実行はできるが何も検証していないテスト」が紛れ込んでいないかを、この段階で必ずチェックしてください。

レビューにかける時間は、コード生成にかかった時間より短くて構いませんが、ゼロにはしないでください。

ステップ1で書いた仕様と、AIが生成したテストの内容を見比べる作業も、このタイミングで済ませておきます。

ここで手を抜くと、次のステップで実行してから初めて問題に気づくことになり、かえって時間がかかります。

【ステップ5】実行して結果を確認し仕上げる

レビューが終わったら、実際にテストを実行してみます。

JavaScriptプロジェクトであれば、Jestを使って次のようにコマンドを実行します。

npx jest validateEmail.test.js

失敗したテストがあれば、AIが仕様を誤解しているのか、実装側にバグがあるのかを切り分けます。

この切り分け作業こそ人間にしかできない判断で、AIに丸投げできない工程だと私は考えています。

ここまで終えて初めて、AIに書かせたテストコードをチームの資産として扱えるようになります。

AIが書くテストコードで注意すべき3つの落とし穴

手順通りに進めても、AIが書くテストコードには共通した落とし穴が3つあります。

落とし穴1：トートロジー（何もテストしていないテスト）

トートロジーとは、実装のロジックをそのままコピーしただけで、実質的に何も検証していないテストのことです。

例えば、関数の中身をそのままテストコードにも書き写し、同じ計算結果同士を比較しているケースがこれにあたります。

一見すると緑色のテスト結果が並ぶので安心してしまいますが、実装にバグがあってもテストは通り続けます。

私も最初はこれに気づかず、AIが出したテストを疑わずに採用してしまったことがあります。

後からバグ報告を受けて調べ直したときに、そのテストが一度も本当の意味で失敗していなかったと気づき、背筋が冷えました。

落とし穴2：過剰なモックでバグを見逃す

モックとは、外部サービスやデータベースなど、本物の依存先の代わりに使う「偽物」の部品です。

AIはテストを組み立てやすくするために、依存関係を片っ端からモックに置き換えてしまう傾向があります。

モックだらけのテストは高速に動きますが、本物のAPIやデータベースとのつなぎ目で起きる不具合には気づけません。

すべてをモックに置き換えるのではなく、依存先の一部だけは実物に近い形で確認するテストを残しておくと安心です。

特に決済や認証など、失敗が業務に直結する処理ほど、モックだけに頼らない確認を意識してください。

落とし穴3：カバレッジの数字だけを追いかけてしまう

カバレッジとは、テストコードがどれだけの割合のコードを実行したかを示す数値です。

AIに「カバレッジ100%にして」と頼むと、実行はするが検証はしていないテストを量産して数字だけ達成することがあります。

カバレッジは「実行された割合」であって「正しく検証された割合」ではないという点を、忘れないようにしてください。

数字を追うより、仕様の抜け漏れがないかを見る方が、結果的に品質につながります。

私の場合、カバレッジの数値はあくまで目安として見て、ステップ1で書き出した仕様と照らし合わせることを優先しています。

数字が低いこと自体は問題ではなく、なぜそこが実行されていないのかを説明できる状態にしておくことの方が大切です。

AIでテストコードを書いてみた結果、気づいたこと

ここからは、実際に私が自分のプロジェクトでAIにテストコードを書かせてみた一次体験を共有します。

ここでは、以下の内容について詳しく解説します。

Claude CodeとJestで試した内容

今回は、日々の開発で使っているClaude Codeに、フォームのバリデーション関数のテストを書かせてみました。

先ほど紹介した5つのステップの通り、仕様と観点をまとめてから依頼したところ、想定より短い時間でテストコードの雛形ができあがりました。

Claude Codeはターミナル上でファイルを読み書きできるので、既存のテストファイルの書き方に合わせて新しいテストを生成してくれる点が助かりました。

なお、Claude Codeを継続的に使うには、最低限Proプランへの加入が必要になる点は押さえておいてください。

APIキーでの従量課金も利用できますが、使いすぎで想定外の請求が来るリスクがあるため、入門段階ではおすすめしません。

出てきたコードのよかった点と直した点

よかった点は、境界値や空文字のケースなど、自分では書き漏らしがちなケースをきちんと拾ってくれたことです。

一方で、直した点もいくつかありました。

最初に出てきたテストの一部は、まさに落とし穴1で紹介したトートロジーに近く、期待値が実装をコピーしただけの状態でした。

また、外部APIを呼び出す処理をすべてモックに置き換えていたため、実際のレスポンス形式が変わった場合の検知ができない状態になっていました。

この経験を通じて、AIはテストの「量」を増やすのが得意で、「質」を保証するのは最後まで人の役割だと実感しました。

AIのテストコードの書き方に関するよくある質問

Q：無料のAIツールでもテストコードは書けますか？

A：無料枠のあるチャット型AIでも、簡単な関数のテストコードなら十分に書けます。

ただし、プロジェクト全体のファイルを読みながら書いてもらいたい場合は、Claude Codeのような開発環境と連携できるツールの方が効率的です。

Q：どのプログラミング言語から始めるのがおすすめですか？

A：この記事で紹介したJavaScriptとJestの組み合わせは、情報量が多く、入門者にも扱いやすい選択肢です。

すでにPythonで開発している場合は、同じ考え方をunittestやpytestに置き換えるだけで応用できます。

Q：既存のプロジェクトにAIでテストを導入する場合、何から始めればいいですか？

A：いきなり全体にテストを追加しようとせず、バグが出やすい重要な関数を1つだけ選ぶところから始めてください。

小さく成功体験を積んでから対象を広げる方が、途中で挫折しにくいです。

まとめ

AIにテストコードを書かせる作業は、仕様を明確にし、観点を洗い出し、プロンプトで依頼し、レビューし、実行するという5つのステップを踏めば、入門者でも安全に進められます。

一方で、トートロジーや過剰なモック、カバレッジ至上主義といった落とし穴は、知らずにいると誰でもハマります。

私自身、AIが出したテストをそのまま信じそうになった経験があるからこそ、レビューの一手間だけは省略しないようにしています。

今書いているコードの中に、AIにテストを任せてみたい関数はありませんか。

まずは1つの関数からで構わないので、今日紹介した手順で試してみてください。