AIにテストを書かせると毎回同じ場所が抜ける理由と対策

AIにテストを書かせると「速い」というのは正常系だけの話だ。GitHub CopilotやClaude Codeにテストコードを書かせると、たしかに関数が期待どおりに動く場合のテストは数分で出てくる。だが何度か使ってみると、同じパターンで抜けることに気づく。境界値、異常系、非同期処理、副作用の検証が毎回のように落ちている。これは実装コードを読むAIの動き方から来ている。AIは与えられたコードから「最もありそうな使われ方」を推測してテストを組み立てるため、失敗するパスや予期しない状況への対応は後回しになりやすいのだ。 ここが「AIの鬼」的に見ると面白い点だ。テストコードの生成はAI時代の「品質保証のプロセスが根本的に変わった」ことを示している。従来は人間がテストケースを考えて、コードで書く。つまり「考える人」と「実装する人」が同じか、少なくとも密に連携していた。ところがAIはこれを逆にする。「正常系を自動抽出する」という機械的な部分は高速化するが、「何が起きる可能性があるか」という想像力の部分は人間にしか難しい。つまりAIは業務を「加速」したのではなく、「作業の分類」そのものを変えてしまったということだ。中小製造業では、一人の工程エンジニアが見積もりから検査まで一人で回していることも多い。その現場にAIが入ると、業務はより「細分化」される。結果として「何のためにテストするのか」という根本が見落とされやすくなる危険がある。 実務に活かすなら、プロンプトで「観点を具体的に番号付きで指示する」ことが実は一番速い。「異常系も書いて」と抽象的に頼むのではなく「0件、1件、上限件数、null、undefined、型違い」と列挙する。すると生成されるテストの本数は増えるが、中身が薄くなるテストも混ざってくる。ここが肝だ。カバレッジ数値を目標にしてはいけない。AIが出したテストをレビューするときは、アサーション（何を確認しているのか）の中身を必ず一行ずつ読む。見た目は完璧なテストでも、実は「呼ばれたか」という表面的な確認だけで、「何回呼ばれたか」「どんな引数で呼ばれたか」という副作用までは検証していないケースがほとんどだ。そこを補う手間を見込んでおかないと、テストが多いだけのコードになってしまう。