テストコードの作成にAIを使うときの注意点｜頼み方と作られたテストの確かめ方

テストコードを書く作業は、開発の中でも後回しにされやすい作業です。AIコーディングツールを使うと、関数を指定するだけでテストの下書きが作られるため、テストを増やすきっかけになります。

ただ、AIが作るテストがそのまま役立つとは限りません。実装の動きをなぞっただけのテストや、条件が甘く何も確かめていないテストが混ざることがあります。テストが通っていても、仕様どおりに動いている保証にはならないのです。

この記事では、テストコードの作成にAIを使うときに気をつけたい点と、作られたテストの確認方法を説明します。ツールの機能や料金は変わることがあるため、導入時は各製品の公式情報を確認してください。

AIが作るテストで起きやすいこと

AIにテストを頼むと、多くの場合は対象のコードを読んでテストを作ります。そのため、コードに不具合があっても、その不具合を含んだ動きを正しいものとしてテストに書いてしまうことがあります。

確かめる内容が弱いテストにも注意が必要です。たとえば、関数がエラーなく終わることだけを確かめ、返ってきた値を確認していないテストがあります。このようなテストは、実装が間違っていても通ってしまうでしょう。

テストを通すために、AIが余計な変更をすることもあります。テストが通らないときに、実装を都合よく変えたり、テストの期待値を書き換えたりする場合です。変更の差分を見て、意図しない変更が含まれていないかを確認しましょう。

テストの目的があいまいなまま、数だけが増えることもあります。同じ条件を少しずつ変えただけのテストが並び、肝心のケースが抜けている状態です。量が多いと抜けに気づきにくくなるため、何を確かめるテストなのかを一覧で見られるようにしておくとよいでしょう。

確かめたい仕様を先に伝える

実装をなぞっただけのテストを避けるには、テストで確かめたい仕様を先に伝えます。「この関数のテストを書いて」とだけ頼むと、AIは実装から期待する動きを推測するしかありません。たとえば「金額が負の値ならエラーを返す」「上限を超えた場合は上限の値にそろえる」のように、期待する動きを書いて頼みましょう。そのほうが、目的に合ったテストになりやすいはずです。

仕様が文書にまとまっていれば、その内容を伝えます。はっきりしない部分は、AIに頼む前にチームで確認してください。仕様があいまいなままテストを作ると、あいまいな理解がそのままテストに残ります。

境界のケースも明示しましょう。空の入力・最大値や最小値・日付の切り替わり・想定外の型の値など、不具合が起きやすい条件を挙げてテストに含めるよう頼みます。

可能であれば、実装より先にテストを作る進め方も検討してください。仕様をもとにテストを先に作っておけば、AIが実装の動きに引きずられる心配が減ります。そのあとで実装をAIに頼み、テストが通るかを確かめる流れです。

作られたテストを確認する方法

作られたテストは、テスト名と中身が一致しているかから確認します。テスト名に書かれたことを、本当に確かめているかを読んでください。期待する値が具体的に書かれているか、どの条件で何を確かめているかが読み取れるかを見ます。

テストが失敗すべきときに失敗するかも確かめましょう。実装の一部をわざと間違った内容に変えてみて、テストが失敗するかを見る方法があります。変えても通ってしまうテストは、確かめる力が弱いと考えてよいでしょう。

テストのコード自体の読みやすさも見ておきます。テストは、後から仕様を知るための資料にもなるからです。準備の処理が長すぎる、似たテストが大量に並んでいる、といった場合は整理を頼みましょう。

テストの数より中身を見る

AIを使うと、テストの数は増やしやすくなります。テストの数や、テストで実行されたコードの割合を目標にすると、数を増やすこと自体が目的になりやすい点に注意してください。中身の弱いテストが増えると、実行に時間がかかるうえ、変更のたびに直す手間も増えます。

テストが増えたら、定期的に整理する機会を設けます。同じことを確かめているテストや、意味が分からなくなったテストは、削除や統合を検討しましょう。

整理の際は、テストを消してよいかの判断をAIだけに任せないようにします。そのテストが過去の不具合をきっかけに追加されたものなら、消すと同じ不具合を再び見逃すおそれがあるためです。

外部のサービスや時間に依存するテストにも注意が必要です。AIが作ったテストが、実行のたびに結果が変わる不安定なものになっていないかを確認してください。不安定なテストが増えると、チームがテストの結果を信用しなくなるおそれがあります。

チームで決めておきたいこと

テストの作成にAIを使う場合も、チームでルールを決めておくと品質をそろえやすくなります。どの種類のテストにAIを使ってよいか、作ったテストを誰が確認するか、といった点です。

たとえば、単体テストの下書きはAIに任せて仕様の確認は人が行う、という分担が考えられます。テストのレビューの観点は、コードのレビューと合わせて整理しておくとよいでしょう。AIが書いたコードの確認の進め方は、AIが書いたコードのレビュー手順で説明しています。

テストに使うデータについても、決まりを作っておきましょう。本番のデータを複製してテストに使うと、個人情報などがAIツールに渡るおそれがあります。テスト用には架空のデータを用意し、その作成にAIを使う場合も、実在の情報が混ざっていないかを確認してください。

送料計算の仕様からテストを作る例

架空の通販アプリで、送料を計算する関数のテストを追加するとします。説明用の仕様として、商品代金が5,000円以上なら送料無料、5,000円未満なら送料500円と定めます。商品代金は円単位の非負整数で、負数や整数でない値は受け付けない想定です。実際の料金や販売条件ではありません。

AIに実装を渡す前に、入力と期待する結果を表にします。境界の5,000円と、その前後を含めると、「以上」と「超える」の取り違えを見つけやすくなります。

この例では「0円の注文を受け付けるか」は注文受付側の仕様とし、送料関数は渡された有効値を計算します。機能の境界を決めないと、送料テストの中で注文の可否まで推測してしまいます。分からない条件は未決として扱い、担当者が決めてから期待値にします。

AIへの依頼に変更してよい範囲も含める

依頼文には、「この仕様表に対応するテストを追加する。本体の処理と既存の期待値は変更せず、仕様と実装が合わない場合は報告する」と書けます。使用するテストの仕組みや既存の例も示し、プロジェクトにないライブラリを不用意に増やさないようにします。

作成後は、テスト名だけでなく、期待値をどこから得ているかを読みます。送料の期待値をテスト対象の関数から計算していれば、実装が誤っていても同じ値になる可能性があります。表で決めた結果と直接比較しているかを確認してください。

一つのテストにすべての条件を詰め込むと、失敗時にどの条件が原因か分かりにくくなります。条件ごとに名前を付け、失敗した入力と期待値が表示される形にすると、保守担当者も原因を追いやすくなります。

境界の誤りを検出できるか試す

テストを確認する一つの方法として、隔離した開発用の作業環境で、無料条件を一時的に「5,000円を超える場合」へ変えてみます。この誤った変更なら、5,000円のケースが失敗するはずです。本番環境や共有中の変更には手を加えず、どの差分を一時的に変えたかを把握して行います。

失敗しなかった場合は、該当テストが実行対象に含まれているか、期待値を本当に比較しているか、対象関数を別の処理で置き換えていないかを確認します。単にテスト数を追加しても、この原因が残っていれば確認できる範囲は広がりません。

確認後は、一時的に入れた誤りだけを戻し、テストが通ることと、不要な変更が差分に残っていないことを確かめます。この方法で一つの誤りを検出できても、すべての不具合を防げるわけではありません。今回守りたい条件に対して、テストが働くかを確認するための手順です。

外部処理を置き換えるときは、確認できない範囲を残す

配送サービスから送料を取得する構成なら、単体テストでは接続処理を見本の応答に置き換える方法があります。正常な応答だけでなく、時間切れや不正な応答も用意し、利用者にどの結果を返すかを確かめます。

ただし、置き換えたテストが通っても、実際の配送サービスへ接続できる証拠にはなりません。通信先との形式や認証は、許可された検証環境で別に確認する必要があります。単体テストで確かめたことと、接続先を含めて確かめたことを分けて報告してください。

実行のたびに結果が変わる場合も、失敗を無視する設定へ変える前に原因を調べます。時刻、乱数、処理順、共有データの影響を整理し、必要な条件をテスト側で固定できるかを確認します。安定して同じ条件を再現できれば、不具合による失敗を見分けやすくなります。

まとめ

テストコードの作成にAIを使うと、テストを増やすきっかけになります。確かめたい仕様と境界のケースを先に伝え、作られたテストが失敗すべきときに失敗するかを確認しましょう。テストの数より中身を見て、チームで確認の分担を決めておくことが大切です。

e-Grantsでは、Codex・Claude Code・GitHub Copilotの導入と運用ルールの整備を支援しています。テストを含めた開発の進め方を整えたい場合は、AI開発環境の導入・整備をご覧ください。