AI と書くテスト ── 生成とTDDのあいだ── テスト生成の実力、カバレッジの罠、医療ソフトの検証

01そもそもテストは、何のためにあるのか

テスト自動化の話に入る前に、テストの目的を置き直しておきます。ここを曖昧にしたまま「AI で楽をしよう」と進むと、量は増えても意味の薄いテストばかりが積み上がるからです。テストの役割は、大きく二つに分けられます。

一つは、いま書いたコードが意図どおり動くかを確かめる役割。もう一つ、そしてより大切なのは、あとでコードを変えたとき、他が壊れていないと保証する役割です。前者は一度きり、後者は長く効きます。ソフトウェアは作って終わりではなく、直し続けるものです。だからこそテストは、「変更してよい」という許可を与える安全網になります。テストがなければ、人は怖くてコードに手を出せなくなります。

この視点に立つと、良いテストの条件が見えてきます。壊れるべきときに壊れ、壊れるべきでないときには壊れない。つまり、本当のバグは捕まえ、無関係な変更では鳴らない。AI に大量生成させたテストが、この条件を満たしているか ── それが本回を貫く問いです。

02AI にテストを書かせる ── その実力

結論から言えば、AI のテスト生成は実務で役に立ちます。とくに次の場面では、人が手で書くより速く、抜けも減ります。

一方で、限界もはっきりしています。AI はコードが「何をしているか」からテストを起こすため、コードにバグがあれば、そのバグごと「正しい挙動」としてテストに固定してしまいます。これを実装の追認と呼びます。バグのある関数を渡せば、AI はバグを再現するテストを書き、それが「通る」ことで、間違いにお墨付きが付く。テストは仕様に照らして書くべきなのに、AI は目の前のコードに照らして書く。ここが最大の落とし穴です。

03カバレッジの罠 ── 数字が嘘をつくとき

テストの量を測る代表的な指標が、カバレッジです。「カバレッジ 90%」と聞くと、コードの 9 割が守られている気がします。けれど、この数字はしばしば人を欺きます。カバレッジが測るのは「テスト中にそのコード行が実行されたか」だけで、「その挙動が正しいと検証されたか」ではないからです。

極端な例を挙げます。関数を呼ぶだけで、結果を一切確かめない（＝アサーションがない）テストでも、コード行は実行されるのでカバレッジは上がります。AI に「カバレッジを上げて」と頼むと、こうした中身の薄いテストで数字だけ埋めることが起きます。数字は 90% でも、実際には何も守られていない ── そんな状態が生まれます。

04TDD と AI の関係 ── 順序を逆にする意味

実装の追認という落とし穴を避ける、古くからの答えが TDD（＝テスト駆動開発、Test-Driven Development。コードより先にテストを書く進め方）です。ケント・ベックが 2002 年に体系化した方法で、順序はこうです。まず失敗するテストを書き、次にそれを通す最小のコードを書き、最後に整える。この「赤 → 緑 → 整理」を小刻みに回します。

肝心なのは順序です。TDD ではテストが先にあるので、テストは「こう動いてほしい」という仕様を表します。実装はまだ存在しないのだから、追認しようがありません。これは、AI にコードを書かせる時代にこそ効いてきます。人が仕様をテストの形で先に固定し、その枠内で AI にコードを書かせる。すると AI は自由に「盛る」ことができず、テストという柵の内側でしか動けません。

組み合わせ方には、二つの流儀があります。

• 人がテスト、AI が実装 ── 人が仕様をテストで先に書き、それを満たすコードを AI に書かせる。仕様の主導権を人が握れるので、追認を防ぎやすい。医療系など厳しさが要る場面向き。
• AI がテスト、人がレビュー ── 既存コードに後からテストを足すとき、AI にたたき台を出させ、「これは仕様として正しいか」を人が吟味する。速いが、追認の危険が残るので、レビューの厳しさが命綱になる。

どちらにも共通する原則は一つです。「何が正しいか」を決めるのは人であって、AI ではない。AI は速く書きますが、正しさの基準を持ちません。基準を持つのは、仕様を理解した人だけです。

05回帰テスト ── 変えても壊れない、を守る

テストの第二の役割 ── あとで変更しても他が壊れていないという保証 ── を担うのが回帰テスト（＝以前直した不具合が再発していないかを繰り返し確かめるテスト）です。コードを一箇所直したとき、遠く離れた別の場所が巻き込まれて壊れる。これを毎回人手で確かめるのは、現実的ではありません。だから、一度書いたテストを繰り返し自動で回します。

ここでも AI は役に立ちますが、注意が要ります。バグを見つけて直したら、そのバグを再現するテストを一つ追加するのが回帰テストの王道です。AI にコードだけ直させると、往々にしてこの「再発防止のテスト追加」を飛ばします。直しはしても、二度と起きないための柵を立てない。結果、同じバグが形を変えて何度も戻ってきます。

もう一つの落とし穴が、壊れやすいテスト（＝flaky test、実行するたびに結果が変わる不安定なテスト）です。AI が生成したテストには、時刻や実行順序に左右されて、たまに失敗するものが紛れ込みます。壊れやすいテストが増えると、人は「また誤報だ」と警告を無視しはじめ、やがて本物のバグの警告まで見落とします。鳴りすぎる警報は、鳴らない警報より危うい。回帰テストは、量より、鳴るべきときだけ鳴る信頼性のほうが大切です。

06医療ソフトの検証 ── IEC 62304 という土台

ここまでは一般論でした。けれど、製薬・医療の現場でソフトウェアを扱うなら、テストは「良い習慣」ではなく規制上の義務になります。その中心にあるのが IEC 62304（＝医療機器ソフトウェアのライフサイクルを定めた国際規格。Medical device software — Software life cycle processes）です。医療機器に組み込まれるソフト、あるいはそれ自体が医療機器となるソフト（＝SaMD）について、開発と検証の枠組みを定めています。

この規格の芯にある考え方は、ソフトが壊れたとき患者にどれだけ害が及ぶかで、求める厳しさを変える点です。安全区分は三段階に分かれます。

ここで、AI 生成テストとの関係が問われます。IEC 62304 が求めるのは、テストが「ある」ことではありません。要求仕様の一つひとつが、対応するテストで確かめられ、その対応関係をたどれること（＝トレーサビリティ）です。AI が大量のテストを吐いても、それがどの要求に紐づくかを示せなければ、規制上は評価の対象になりません。数の多さは、証拠になりません。

07運用 ── テストを回し続ける仕組み

テストは一度書いて終わりではなく、変更のたびに自動で回してこそ意味を持ちます。この「自動で回す」仕組みが CI（＝継続的インテグレーション、Continuous Integration。コードを変えるたびに自動でテストを走らせる仕組み）です。AI がコードを速く生み出す時代には、この自動の関所がいっそう重みを増します。人が目で追いつけない速さで変更が来るからです。

運用で守るべき原則を、いくつか挙げます。

• テストが赤なら、先に進めない ── 失敗したテストを放置したまま機能を足さない。壊れた土台の上に積むと、原因の切り分けが指数的に難しくなる。
• 壊れやすいテストは、見つけ次第つぶす ── 誤報を放置すると、警報全体の信頼が失われる。不安定なテストは直すか、隔離する。
• AI 生成テストも、人のレビューを通す ── 生成されたから正しい、ではない。とくに医療系では、レビューの記録そのものが規制上の証拠になる。

大事なのは、CI という自動化を、人の判断を省くためではなく、人の判断を最も重い所に集めるために使うという発想です。単純な「壊れていないか」の確認は機械に任せ、「この仕様は本当に正しいか」という難しい問いに人が向き合う。この分担が、テストを速度に飲み込ませずに回す鍵になります。

08本サイトの他の章との接続

本回は、次の章と読み合わせると理解が深まります。

• AI Programming 第 5 回 ── リファクタリング ── テストという安全網があって初めて、AI 支援のコード改善は安全に行える。本回はその前提を固める回。
• 資材審査シリーズ ── 生成物を人がレビューして通す/止めるという構造は、コードのレビューと資材審査で通じ合う。
• 日々是好日 ── 「動いた」で満足せず、正しさを問い続ける姿勢を、人と人の営みとして描くエッセイ群。

AI は、テストを速く・大量に書けるようにしました。これは機会です。けれど、テストの多さは品質の高さと同じではありません。AI は目の前のコードからテストを起こすため、バグごと「正しい」と固定してしまう ── 実装の追認という落とし穴があります。カバレッジという数字も、実行されたことは示しても、正しいことは示しません。数字を目標にした瞬間、人も AI も中身のない行埋めに走ります。

だからこそ、順序を握り直します。人が仕様をテストの形で先に固定し、その柵の内側で AI にコードを書かせる ── TDD の発想が、量産時代にこそ効きます。医療ソフトなら、IEC 62304 が求めるのはテストの数ではなく、要求とテストの対応をたどれ、記録として説明できることです。「動いた」は検証ではない。正しさの基準を持つのは人であって、AI ではありません。速く書ける力は、人が正しさに集中する時間を生むためにこそ使う。次回は、この安全網の上で、AI 支援のリファクタリングをどう安全に進めるかに入ります。