「実装しました。テストも書きました。すべて緑です、問題ありません」。AIエージェントがそう報告してくる場面に、もう慣れてしまった人は多いはずだ。コードを書くのもAI、テストを書くのもAI、テスト結果を評価して「大丈夫です」と言うのもAI。人間がやることは、それを見て「じゃあマージします」とボタンを押すことだけ、という状況が実際に生まれつつある。
こうなると自然に湧く疑問がある。これから単体テストの書き方やTDD（テスト駆動開発。実装より先にテストを書き、そのテストが通ることを目標にコードを育てていく手法）を、わざわざ自分の手で学ぶ意味はあるのか。どうせAIが書けるなら、その時間を別の勉強に回したほうが得なのではないか、という問いだ。
素直に考えれば、答えは「学ぶ必要は薄れた」になりそうだ。人間がタイプする手が要らないなら、手の動かし方を練習する意味も薄い。実際、テストコードの書き方――アサーションの構文、モックの作り方、フレームワークの使い方――は、AIに任せて確実に速くなる領域だ。ここで人間が写経のような練習をする時間対効果は、以前より確実に下がった。
ところが、実際に価値が上がっているのはむしろ逆の部分だ。テストの「書き方」ではなく、テストの「決め方」――何をテストし、何をテストしないか、どのケースを守るべきかの優先順位を判断する、いわゆるテスト設計の力の方が、相対的に重みを増している。ここがAIにとって一番苦手な領域だからだ。
AIは「頼まれたこと」しかテストしない
AIにテストを書かせると、たいてい高いカバレッジがすぐ出る。正常系、代表的な異常系、ついでに境界値もいくつか。見た目には十分立派なテストが並ぶ。だが、その中身をよく見ると、AIが得意なのは「渡されたコードから読み取れる仕様に沿ってテストを組み立てること」であって、「そもそも渡された仕様や実装のどこが危ういかを疑うこと」ではないと気づく。
たとえば、割引計算のコードがあるとする。AIは「割引率0%」「割引率100%」「割引率が負の場合にエラーになるか」といった、コードの分岐から機械的に導ける境界は丁寧に押さえてくる。一方で、「この割引はクーポンと在庫連動キャンペーンが同時に発生したとき、二重適用されないか」というような、コードのどこにも明示的に書かれていない、業務の暗黙の前提から生まれるリスクには気づきにくい。そこは仕様書にも書かれていないことが多く、書いた人間自身も「言われてみれば怪しい」と初めて気づくような領域だからだ。
つまりAIは「頼まれた範囲を漏れなくやる」ことには強いが、「そもそも何を頼むべきか」を決める部分は苦手にしている。テストを書く手はAIに委譲できても、テストで何を守るべきかという判断は、依然として人間の側に残る。むしろAIが生成物の量を増やすほど、その中から「本当に効いている検証」と「体裁だけのテスト」を見分ける必要は増える。
カバレッジという緑の罠
この構造は、カバレッジという数字の性質を考えるとわかりやすい。カバレッジは「コードのどれだけの行が実行されたか」を測るものであって、「その実行結果が正しいことをどれだけ確かめたか」を測るものではない。getterやsetterのような当たり前の処理を丁寧になぞるテストを大量に書けば、カバレッジ自体はあっさり9割を超える。だが、それは「危ないところを守れている」ことをまったく保証しない。
AIは、この「見た目のカバレッジを埋めるテスト」を大量生産することに関しては非常に得意だ。だからこそ危うい。AIが自信満々に緑のチェックマークを並べてくるとき、そのチェックが「本当に守るべき境界を守っているか」を見抜けるのは、その業務やシステムのリスクの所在を理解している人間だけになる。テスト設計を学んでいない人がAIの「問題ありません」をそのまま信じるのと、テスト設計を知っている人が同じ報告を見て「このケースは触れていないのでは」と一言差し込めるのとでは、システムの安全性がまったく違ってくる。
TDDが本来教えてくれるのも、実はテストコードの書き方そのものより、この「先に境界を決める」思考の型だ。実装より先にテストを書くという順番を守ると、いやでも「この関数は何を保証すべきか」「どこまでが仕様で、どこからが未定義か」を先に言語化する癖がつく。この思考の型さえ身についていれば、実際にキーボードを叩くのがAIであっても構わない。逆に、この型を持たないままAIにテストを丸投げすると、AIが作った検証の網の粗さに気づく手段を自分だけが持たない、という状態に陥る。
これから何に時間を使うべきか
なので、学習時間の配分としては、テストフレームワークの細かい書き方を写経する時間は減らしていい。そこはAIとの分業で置き換わっていく領域だ。その代わりに時間を割くべきは、境界値分析や同値分割（入力を「同じ結果になるはずのグループ」に仕分けて、各グループの代表値だけを確認する考え方）といったテスト設計の基礎、そして「このコードの、どこが一番壊れると困るか」というリスクの優先順位づけを、自分の頭で考える練習だ。具体的には、他人が書いたテスト一覧を見て「抜けているケースはどれか」を指摘する練習や、仕様書の曖昧な部分を洗い出す練習は、AI時代でも――というより、AI時代だからこそ――効いてくる。
AIが並べてくる緑のチェックマークは、あくまで「頼まれた範囲を漏れなく通過した」という印にすぎない。そこにどのケースを守るべきかの優先順位が正しく反映されているか、危険な暗黙の前提が抜け落ちていないかは、チェックマークの色では分からない。その抜け落ちに、コードを読んだ瞬間に見当をつけられるかどうか――それがテスト設計を学んだ人と学んでいない人の差になる。テストを書く手はAIに譲っていい。ただ、何を守るべきかを決める頭までは、今のところ誰も肩代わりしてくれない。
これから技術書を選ぶときも、テストの書き方が載った入門書だけでなく、テスト設計や品質保証の考え方そのものを扱った一冊を1冊混ぜておくと、AI時代の学習投資として無駄になりにくい。
tasklogでは、開発者が実際に引用しているテスト設計・品質保証まわりの技術書を確認できる。