AIが書いたテストコードの、どこまでを人間が疑うべきなのか

AIに実装を書かせ、ついでにそのテストコードも書かせる。もう誰もが日常的にやっていることだ。ここまで来ると、素直にこう思う人は多いはずだ。「実装もテストも生成できるなら、人間がテストの書き方を学ぶ必要は、これからどんどん薄れていくのではないか」。assert文の書き方やモックの作法を覚えることに時間を使うのは、もう割に合わないのではないか、という不安である。

直感としては筋が通っている。だが実際に起きていることは、その予想と逆向きだった。tasklogが集計している技術記事の言及数を直近53日間で見ると、PlaywrightやVitestといったテスト関連ツールへの言及は、PythonやTypeScriptのような主流言語よりもはるかに速く伸びていた。実装そのものの話題は緩やかにしか増えていないのに、テストの話題だけが加速している。「AIがテストを書いてくれるのだから、人間の関心は薄れるはずだ」という予想に対して、現場の言及量は正反対の反応を見せていたことになる。

この逆転は、何を意味しているのだろうか。

AIが書けるのは「動くコード」、書けないのは「正しさの定義」

AIにテストコードを書かせると、たしかに文法的に正しく、実行してパスするコードが出てくる。関数を渡せば、それに対応するassert文やモックの雛形はいくらでも生成できる。ここだけを見れば「もうテストの書き方を覚える必要はない」という結論に飛びつきたくなる。

ただし、テストコードが本当に仕事をするのは「書けたとき」ではなく「何を正しいとみなすかが、業務的に妥当だったとき」だ。たとえば「ユーザーが退会したら、関連データは即座に消すべきか、一定期間は復旧可能にしておくべきか」。これはコードの書き方の問題ではなく、そのプロダクトが何を正しさとして採用するかという仕様判断であり、法務の要件やビジネス上の約束事、過去に起きた障害の経緯まで知っている人間でなければ決められない。AIは「このテストはこういう入力に対してこういう出力を期待する」という形式は完璧に埋められるが、「その期待値そのものが、このプロダクトにとって妥当かどうか」は、文脈を知らなければそもそも判断する材料がない。

テストの世界では、この「何を正しさの基準とするか」を決める問題を、昔から厄介な論点として扱ってきた。正解をどう定義するかが自明でないケースのほうが、実務では圧倒的に多いからだ。AIが埋めてくれるのは、その基準が一度決まった後の「実行可能な形への変換」部分であって、基準そのものを発明する部分ではない。

消えるのは暗記、残るのは「どこを疑うか」を見抜く力

ここから見えてくるのは、ひとつの非対称な構造だ。テストの書き方――構文、フレームワークの使い方、モックの組み方――という「手順の知識」は、AIに丸投げしてもほぼ困らなくなった。覚えることに時間を使う価値は、たしかに下がっている。

一方で、価値が上がっているのは「どこを検証すべきかを見極める力」のほうだ。AIは与えられた仕様に対して忠実にテストを書くが、仕様に書かれていない境界、たとえば同時に同じ操作が来たらどうなるか、入力が極端に大きかったり空だったりしたらどうなるか、外部サービスが一瞬だけ失敗したらどうなるか、といった「誰も明文化していないがシステムが壊れやすい場所」を自発的に疑って探しにいくことは、まだ得意ではない。これを見抜くには、実装がどう動いているかへの理解と、過去にどこで障害が起きやすかったかという経験的な直感の両方が要る。

つまりAI時代のテスト学習は、「assertの書き方を覚える」から「このシステムはどこで嘘をつきやすいかを疑う習慣をつける」へと、学ぶべき中心が移動している。冒頭で見た、テストツールへの関心が主流言語より速く伸びているという逆転は、この移動がすでに起きている気配として読むのが自然だろう。同じ操作がほぼ同時に重なったときの競合、極端に大きい・あるいは空の入力、外部サービスが一瞬だけ失敗して戻ってくる瞬間――こうした「誰も仕様書には書かなかったが、現場では繰り返し起きる」場所を疑いにいく習慣こそが、AIがどれだけ速く実装とテストを書けるようになっても、最後まで人間の側に残り続ける仕事だ。

どこに学習の時間を割くか

だとすれば、これからテストを学ぶ人が時間を割くべき場所も見えてくる。テストフレームワークの文法を一通り覚えることは依然として無駄ではない――自分で一度書いてみなければ、AIが出してきたテストコードが「何を検証していて、何を検証していないか」を読み解けないからだ。しかしそこで時間を使い切らず、むしろ「このテストはどの入力まで想定しているか」「ここで触れられていない状況は何か」を自分の言葉で言い切る練習に、意識して時間を残したほうがいい。AIが生成したテストコード一式を読んで、抜けている観点を一つでも指摘できるかどうかは、実際にそのコードベースで手を動かした人にしか持ち得ない判断材料だ。

テストの書き方そのものに触れるなら、Playwrightの学習リソースやVitestの学習リソースから始めて、自分の手で一本のテストを書き切ってみるのがいい。AIが生成したテストをそのまま信じるのではなく、まず自分で書く経験を一度は通しておくことが、後からAI製のテストを疑えるようになる最短ルートだからだ。

tasklogでは、こうしたテストツールや主流言語の言及の伸びを、/learn配下の各技術ページで実測のまま確認できるようにしている。何を学ぶか迷ったときの裏付けとして、自分の目で数字を見てみてほしい。