カバレッジ 80% の本体は数字ではなく「下げさせないこと」だった — AI に何度も減点を提案された話

はじめに

テストカバレッジのしきい値を、全パッケージ共通の下限 80% で敷いている。四つの指標（文・行・関数・分岐）すべてにこの数字を当てて、下回ったら CI が落ちる。

設定自体は数行で済む。実際に難しいのは設定ではなく、割れたときに下げないことだった。そして自分の場合、その「下げませんか」を持ちかけてくるのは、同僚でもレビュアーでもなく、コードを書いている AI だった。

「テストが通らないので、しきい値を下げましょう」

開発の主体を AI に移してから、実装は AI が進める。当然、テストも AI が書く。そして CI が赤くなる。カバレッジがしきい値を割ったからだ。

このとき AI がしばしば提案してくるのが、しきい値そのものを下げるという案だ。「このパッケージは性質上テストしづらいので 70% に」「一時的にこの指標だけ緩めては」。技術的には筋が通って見えるし、その場は確かに緑になる。

自分はこれを何度も断ってきた。理由は単純で、一度でも下げたら、そこが新しい基準になるからだ。

下げる提案はいつも「今回だけ」の顔をしてやってくる。でも、しきい値が下がった状態は次の実装のスタート地点になる。次に同じ状況が来たとき、前回下げた前例が根拠として効いてしまう。例外を一つ作ると、その後は例外の交渉が仕事になる。

数字そのものに深い根拠があるわけではない。80% でなければならない理由は特にない。重要なのは、その数字が動かないと全員が知っていることの方だ。

ここで効いているのは「全部を同じ数字に固定すること」ではなく、動かす方向を片側だけに限ることだった。実際、パッケージによっては下限より高い値を置いている（十分書けている部分を 90 や 100 に引き上げている）。上げるのは自由にやっていい。禁じているのは下限を割る方向へ動かすことだけだ。

この非対称が肝で、上げる分にはいくら個別事情を持ち込んでも構わないが、下げる方向には個別事情を持ち込ませない。細かく設定できる仕組みは、放っておくと「ここは事情が違う」という交渉の入口になる。下限を共通に固定しているのは、その交渉を成立させないためであって、すべてのパッケージに同じ品質を要求しているからではない。

下げる代わりに、どこを見るか

とはいえ「絶対に下げない」だけでは、ただの精神論になる。実際には、割れたときに見るべき場所がだいたい決まっている。

割れる指標はたいてい分岐だ。文も行も関数も 80% を超えているのに、分岐だけが足りない。原因はほぼ例外系で、正常な経路しか通っていない。フォールバック側、エラーを投げる側、条件の裏側が一度も実行されていない。

これは実のところ、しきい値が本来やってほしい仕事をしている状態だ。分岐が足りないという警告は、「異常系のテストが無い」と言い換えられる。ここで数字を下げると、消えるのは警告だけで、異常系が無いという事実は残る。下げるという行為は、問題ではなく計測器を消している。

だから対処は決まっていて、テストを足す。それが本当に割に合わないなら、下げるのではなく分母の設計を見直す方に手を入れる。

分母をどう引くか＝テスト戦略の宣言

カバレッジは割合なので、どのファイルを分母に入れるかでしきい値の厳しさが決まる。ここは数字より重要な設計判断だと思っている。

自分の場合、Web アプリのいくつかは分母をロジック層だけに絞っている。画面の側はユニットテストのしきい値に含めず、E2E で担保する、という二段構えだ。（すべての Web アプリでそう割り切れているわけではなく、画面まで分母に含んだままのものも残っている。）

正直に書くと、この線引きを決めた当時は「UI はユニットテストでは扱えない」と思い込んでいた面もある。今にして思えばそれは正確ではない。ただ、結果としての方針——画面は実際に動かして通しで確かめ、しきい値の圧力はロジックに集中させる——自体は、今でも正しかったと思っている。ユニットのしきい値であらゆる画面を 80% まで詰めるのは、費用対効果が悪い。

もう一つの分母調整は、実行コードでないものを外すこと。型定義や、再エクスポートしかしていない取りまとめ用のファイルは、テストのしようがないのに分母を押し下げる。実装は十分に書けているのに全体が数 % 下がって落ちる、という不可解な失敗はたいていこれが原因だ。

ただし除外は「実行コードでないもの」に限る。テストが面倒なファイルを除外リストに足し始めると、しきい値は数字だけ立派な見かけ倒しになる。これも結局、しきい値を下げるのと同じことをしている。

おわりに

やってみて分かったのは、カバレッジのしきい値というのは技術的な設定というより、交渉を発生させないための装置だということだ。数字が何％かより、それが動かないことの方が効く。

そして AI と組んで開発するようになって、基準を緩める圧力が内側から、しかも善意で、技術的に妥当な顔をして来るようになった。AI は目の前の CI を通す方向に最適化する。しきい値を下げるのは、その意味では完全に合理的な提案だ。ただ、何を守るために基準を置いたのかを覚えているのは人間の側でしかない。

自動化が進むほど、人間の仕事は手を動かすことから線を引いて、そこを動かさないことに寄っていく。カバレッジのしきい値は、その最小の練習台みたいなものだった。