「テストも書いておいて」とAIに頼むと、数十分ぶんの作業が数十秒で返ってきます。実行すれば全部緑。カバレッジも上がっている。なのに、なぜか安心できない。そんなもやもやを感じたことはありませんか。
しかも困ったことに、この違和感は言葉にしにくいものです。レビューで「なんとなく薄い気がします」とは言えません。結果として通してしまい、数か月後に「テストがあったのに気づけなかった」不具合と向き合うことになります。
結論から言います。AI生成テストの多くは、実装ではなくモック(本物の代わりに置くにせ物)を検証しているため、何があっても通ります。この記事では、そうしたテストが生まれる仕組みと、レビューで見分けるための3つの質問、そして明日から使える頼み方を紹介します。読み終わるころには、あの違和感を指摘に変えられるはずです。
AI生成テストが全部通るのは「モックを試している」から
まず正体をはっきりさせます。全部通るテストの多くは、本物の処理を1行も動かしていません。動かしているのは、テストの中で自分が用意したにせ物です。
なぜそうなるのか。テストを書くとき、外部のデータベースや通信をそのまま呼ぶと、遅くて不安定になります。そこで代わりの部品を置くのが、モックという手法です。ここまでは正しい技術です。
問題は置きかえる範囲です。AIは「確実に通るテスト」を作ろうとするため、外部だけでなく、本来は検証したい内部の処理までモックに差しかえてしまうことがあります。こうなると、テストは「にせ物が、自分で決めた通りの値を返すこと」を確かめているだけです。
身近な例で言えば、こういう状態です。車の安全性を確かめるために衝突実験をするはずが、実験室に置いてあるのは車のポスター。ポスターは何回ぶつけても壊れないので、実験は毎回「合格」になります。
Zennで話題になった記事は、この状態を「モック自体をテストしている」と表現し、そのうえでAIが作りがちなテスト群を「絶対成功お利口テストコレクション」と呼んでいました。皮肉のきいた名前ですが、実態をよく言い当てています。
つまり、緑であることは品質の証明ではありません。何を動かしたうえでの緑なのかが、いつも問われます。
もう1つのAI生成テストの罠は「実装の細部を固定してしまう」
AI生成テストには、もう1つ困った癖があります。処理の結果ではなく、内部の作り方そのものを記録してしまうことです。
理由は、AIから見えているものが実装コードだからです。仕様書ではなくコードを渡されれば、そこに書かれた変数名や呼び出し順を「守るべきこと」と解釈します。結果、内部の属性を1つずつ確認する数百行のテストができあがります。
このテストは、動きとしては正しく通ります。ただし、あとから内部を整理しようとした瞬間に、いっせいに赤くなります。動きは何も変えていないのに、です。
たとえるなら、料理のレシピではなく、キッチンの引き出しの中身の並び順をテストしているようなものです。味は同じでも、包丁を別の引き出しに移した日にテストは落ちます。
こうしたテストが増えると、チームは「直すのが怖いコード」を抱えることになります。テストは本来、安心して直すための道具です。それが逆に、直すことをためらわせる重しに変わってしまいます。
AI生成テストを見分ける3つの質問
ではレビューで何を見ればよいのでしょうか。おすすめは、テストコードを読み込む前に、3つの質問を自分に投げることです。この順番なら、数百行あっても数分で判断できます。
- 質問1: このテストが落ちるのは、どんなときか — 答えられないなら、そのテストは何も守っていません
- 質問2: 実装を書きかえたら、通らなくなるか — 動きを変えていないのに落ちるなら、細部を固定しすぎです
- 質問3: 本物の処理は、どこで動いているか — 全部がモックなら、確かめているのはにせ物だけです
とくに質問1が強力です。試しに、実装のどこか1行をわざと壊してからテストを流してみてください。それでも全部緑なら、そのテストは削っても品質は下がりません。
質問2は「リファクタリング耐性」と呼ばれる考え方です。リファクタリングとは、動きを変えずに中身を整理すること。整理しても落ちないテストが、良いテストとされます。
3つとも、専門知識がなくても投げられる質問です。1年目でもレビューに参加できるのは、こういう問いを持っているときです。
数字で見るAI生成テストのコスト
「そこまで気にしなくても」と思うかもしれません。しかし、この手間を省いたぶんは、あとの工程に確実に回ってきます。
まず、AIが作った変更依頼(プルリクエスト)がどれだけ取り込まれているか。開発計測サービスのLinearBが2026年に公開したベンチマークは、42か国4,800チームの810万件の変更依頼を対象に、30日以内に取り込まれた割合を集計しました。結果は人が書いた場合が約84%、AIが作った場合は32.7%で、半分にも届いていません(参考リンク3)。
もう1つが、確認にかかる時間です。同じく開発の計測を手がけるFaros AIの集計では、AIの利用が多いチームで変更依頼がレビューに滞留する時間の中央値が441.5%増(およそ5.4倍)、最初のレビューが始まるまでの時間も156.6%増になっていました(参考リンク4)。なおこれはレビュー工程を測った数字で、テストを書く時間そのものではありません。
2つの数字が示しているのは、作業が消えたのではなく移動したという事実です。書く時間は減り、確かめる時間が増えた。だからこそ、行数や依頼数ではなく「要求からリリースまでの時間」や「手戻りの件数」で測るべきだと言われています。
個人の仕事に置きかえれば、こうなります。テストを10分で用意しても、レビューで3往復すれば、合計時間はむしろ増える。速くなったかどうかは、通るまでを1本の線で見ないとわかりません。
考察: AI生成テストは「説明できるか」で価値が決まる
ここからは筆者の考えです。AI時代に価値が残るのは、テストを書ける人ではなく、そのテストが何を守っているかを説明できる人だと考えています。
理由は単純で、書く作業はすでに機械のほうが速いからです。一方で「この機能で、いちばん壊れたら困るのはどこか」という判断は、仕様と事業をわかっていないと下せません。ここはまだ人の仕事です。
そして説明責任は、あとから追加できません。半年後に不具合が出て「なぜこのケースを試していなかったのか」と聞かれたとき、答えられるのは書いた本人だけです。AIが書きました、では調査は前に進みません。
この構造は、コードそのものにも同じことが言えます。生成物を自分の言葉で説明できるかという論点はAIが書いたコードが理解できない｜原因は読み方より依頼前の準備でも扱いました。テストはその延長線上にあります。
逆に言えば、3つの質問に答えられるだけで、あなたのレビューはチームの中で意味を持ちはじめます。
新人エンジニアが今日から変えられるAIへのテスト依頼
最後に、明日そのまま使える形にまとめます。テストを頼むときの一文を変えるだけです。
- 渡すものを変える: 実装コードだけでなく「この機能で守りたいこと」を3行で添える
- 範囲を指定する: 「外部通信とデータベースだけモックにし、対象の処理は本物を動かして」と書く
- 落ちるケースを求める: 「異常系を3つ含めて。入力が不正なときに落ちることを確認したい」と足す
3つ目が効きます。AIは指示がないと通ることを優先しますが、落ちるべき場面を指定すれば、そこを試すテストを書いてくれます。この「通ればよい」に寄っていく性質そのものについては、AIが「テスト全部通りました」と報告する理由｜報酬ハッキング入門で詳しく説明しています。
使い方の差がチーム内の差になっていく話はAIディバイドとは?生産性3倍の裏でチームが壊れた話もあわせてどうぞ。
まとめ
- AI生成テストが全部通るのは、実装ではなくモックを検証していることが多いから。緑は品質の証明にならない
- レビューでは「落ちるのはどんなときか」「実装を書きかえたら落ちるか」「本物はどこで動くか」の3つを問う
- 依頼の時点で守りたいことと異常系を伝えると、通すためのテストから守るためのテストに変わる
まずは手元のテストを1つ選び、実装をわざと1行壊して流してみてください。それでも緑なら、そこが直しどきです。
コメント