テストコードをAIに書かせる｜品質が上がるケースと危ないケース

結論から言うと、AIにテストコードを書かせると「テストがない」状態は脱せますが、「正しいテスト」が増えるかどうかは別の話です。

私はバックエンドエンジニアとして日常的にコードを書いています。AIを使ったテスト生成は、確かに手が速くなる場面があります。ただし最初に痛い目を見た経験があるので、その話から始めます。

結論

AIを使ったテスト生成が得意な場面

AIによるテスト生成が効果を発揮しやすいのは、次のような場面です。

既存コードの網羅的なテスト起こし

すでに動いている関数やメソッドに対して、テストがまったく書かれていない状態を解消するのに使えます。入力と期待する出力を整理させて、テストケースの骨格を出させると、自分で一から書くより速く一覧が出てきます。

境界値・異常系の洗い出し

正常系のテストを書いた後、「他に確認すべき境界値や異常系を列挙してください」とAIに依頼すると、自分が見落としていた入力パターンが出てくることがあります。空文字、null、マイナス値、最大値ちょうど、最大値+1、型が違う場合——こういったパターンの網羅は、AIを使うと出しやすい部分です。

ボイラープレートの削減

テストの書き方は決まった形が多く、同じ構造を何度も書くことになります。最初の1〜2件を人が書いてパターンを示し、残りをAIに出させる使い方は時間の節約になります。

最大の罠：実装のバグをテストに転写する

ここが最も気をつける必要がある部分です。

AIはコードを渡されると、そのコードの動作をそのまま「正しい振る舞い」として解釈してテストを書きます。実装にバグがある場合、バグも含めた動作をテストします。

具体的に起きたことを書きます。

この問題を防ぐ方法は、仕様からテストを書かせることです。

実装ではなく仕様や要件を渡して「この仕様を満たすテストケースを書いてください」という依頼にすると、AIは実装を知らない状態でテストを設計します。この使い方なら、実装とテストが独立した目線で書かれるため、実装のバグを検出できる可能性が上がります。

依頼の例：
「以下の仕様を満たす関数に対するユニットテストを書いてください。
 仕様：inputとして整数の配列を受け取り、偶数だけ返す。
 空配列の場合は空配列を返す。inputがnullの場合は例外を投げる。
 コードは渡しません。仕様からテストを設計してください。」

カバレッジを稼ぐだけのテストが増える問題

AIにテストを量産させると、コードカバレッジの数字は上がります。しかしカバレッジが高い＝テストの品質が高い、ではありません。

AIが生成しがちな「カバレッジを稼ぐだけのテスト」の特徴はこれです。

• 関数を呼んで「例外が出なければOK」としかテストしない
• 戻り値の型だけ確認して中身は確認しない
• エラー系のテストがない
• 副作用（DBへの書き込み、外部API呼び出し）を無視している

こういったテストは、コードを書き換えても通過し続けるため、リグレッションを検出する意味を持ちません。

防ぐには、AIへの依頼を具体的にすることと、出てきたテストを人がレビューすることです。特に以下を確認します。

• 各テストが何を検証しているか、テスト名から読み取れるか
• 異常系・境界値のテストが含まれているか
• 期待値が具体的な値で書かれているか

「AIに書かせる」と「AIと一緒に書く」は違う

テスト生成でのAIの使い方は、大きく2パターンあります。

「書かせる」：AIに出させてそのまま使う
素早くテストの数を増やせますが、質の担保が難しく、上述の罠にはまりやすいです。

「一緒に書く」：AIと対話しながら設計する
「この関数でテストすべきケースを列挙して」「その中で最も見落としやすい異常系はどれ？」「その境界値のテストを書いて」のように、設計の対話相手として使う方法です。生成スピードは落ちますが、品質が安定しやすいです。

私は後者の使い方をメインにしています。AIに全部まかせると、自分がテストを理解していない状態でCIが通る、という気持ちの悪い状況になるためです。

エンジニアとしてのキャリアとの向き合い方

AIツールの普及でテスト設計の自動化が進むほど、「どのテストが本質的なバグを検出できるか」を設計できるエンジニアの価値は上がります。ツールに生成を任せながら、自分はテスト設計そのものへの理解を深めるほうに時間を使うのが長い目で見て正解だと思います。

AIを使って実装の速度を上げながら、より高単価な案件や責任範囲の広いポジションを狙うなら、技術力の根拠となる部分は自分でしっかり持っておく必要があります。フリーランス案件や転職を視野に入れているエンジニアには、スキルセットの整理と案件探しを同時に進める方法もあります。

私の使い方

テストコードへのAIの活用は、「骨格を出させる→人がレビューして修正する」のサイクルが現実的です。

使い分けの原則は次の通りです。

• 既存コードに対してテストを一から書く場面では、AIに骨格を出させて時間を節約する
• テストの期待値に不安がある場合は、実装を見せずに仕様だけ渡す
• カバレッジの数字より「このテストは実際にバグを検出できるか」を確認する
• 出てきたテストは必ずレビューする。通過するかどうかだけで判断しない

AIは「テストを書く速度」は上げてくれます。「テストの質」は、使い方しだいです。