コードを書く速度が上がりました。設計を渡せば実装が出てくるし、リファクタリングも一括で走ります。ところが開発全体のスピードは、期待したほどには上がっていないという感覚を持っている方が多いのではないでしょうか。理由ははっきりしていて、律速が「書く」から「確かめる」へ移ったからです。
この連載では、その「確かめる」側をどう設計するかを扱います。単体・結合・E2E といった従来の枠組みは残りますが、どこに重心を置くかは変わりました。加えて、検証対象そのものが非決定的になる領域（LLM の出力）が業務システムに入ってきています。まずは前提の整理から始めます。
網羅を目指しません。全部にテストを書くべきだ、という主張はしません。書くのは、限られた時間をどこに割り当てるかの判断軸です。テストを増やすこと自体が目的化した現場を何度も見てきたので、そこは繰り返し警告します。
1. 何が変わって、何が変わっていないか
先に変わっていないものを確認します。テストの目的は昔から一つで、変更を安全にすることです。壊れたことに早く気づける状態を作り、直す判断を素早くできるようにする。これは開発手法が何であれ変わりません。 が流行しても廃れても、この目的は動きませんでした。
変わったのはコストの構造です。テストコードを書く手間が明確に下がりました。これまで「書いたほうがいいのは分かっているが時間がない」で見送られていたものが、実際に書ける状態になっています。一方で、書かれたテストが妥当かを判断する手間は下がっていません。ここに非対称が生まれました。
| 工程 | 以前 | 現在 |
|---|---|---|
| テストコードを書く | 重い | 軽くなった |
| 何を検証すべきか決める | 重い | 重いまま |
| テストの妥当性を判断する | 中くらい | 相対的に重くなった |
| テストを実行して待つ | 中くらい | 相対的に重くなった |
| 失敗の原因を特定する | 重い | 重いまま |
この表が連載全体の見取り図になります。軽くなった工程に合わせて、重いままの工程が相対的に目立つようになった。だから実行時間の話（EP.3）とコストの話（EP.10）に章を割きますし、妥当性を判断するという観点が繰り返し出てきます。
2. 量が増えたことで起きる問題
テストが安く書けるようになると、素直に増えます。増えること自体は悪くありません。問題は、増えたテストの質が揃わないことと、増えた量が実行時間に跳ね返ることです。
- が弱いテストが混ざる — 実行はされるが実質何も検証していない。それでも は上がる
- 内部実装に張り付いたテストが増える — を多用した結果、リファクタリングのたびに大量に赤くなる
- 同じことを別の場所で何度も検証する — 重複に気づきにくく、実行時間だけが伸びる
- が紛れ込む — 数本なら我慢できるが、比率が上がると赤が信用されなくなる
最後の項目が最も危険です。赤いのに誰も反応しない状態になると、テスト全体が資産から負債に変わります。EP.11 で一章を使って扱います。
テストが通ることと、検証されていることは別です。 を無確認で更新している、アサーション が「例外が出ないこと」しか見ていない、モック が本物と乖離している ── いずれも緑のまま壊れる構造です。EP.6 で具体的に扱います。
3. 重心をどこに置くか
という古典的な指針があります。速く安定した を土台に多く置き、遅く壊れやすい を頂点に少なく置く。この形は今も有効です。ただし理由の重みが変わりました。以前は「E2E は書くのが大変だから少なく」でしたが、いまは書くのは大変ではなくなった一方で、実行時間と不安定さは変わっていないからです。
つまり、E2E を少なく保つ理由は「書きにくさ」ではなく「維持しにくさ」に一本化されました。ここを取り違えると、書けるようになったからという理由で E2E を増やし、実行に時間がかかり フレーキーテスト が頻発する構成に陥ります。EP.4 で線引きを扱います。
| 層 | 速さ | 壊れやすさ | 本番との近さ | 置き方 |
|---|---|---|---|---|
| 単体テスト | 速い | 低い | 遠い | 土台として多く |
| 中 | 中 | 中 | つなぎ目に絞って | |
| E2Eテスト | 遅い | 高い | 近い | 主要導線だけ |
| 速い | 低い | 近い | デプロイ直後に少数 |
4. 非決定的な対象という新しい問題
従来のテストは、同じ入力なら同じ出力という前提の上に成り立っていました。ところが LLM を組み込んだ機能では、この前提が崩れます。同じプロンプトでも表現が揺れますし、モデルを更新すれば挙動も変わります。完全一致による判定が使えないわけです。
この をどう扱うかが、この連載の後半（EP.7・EP.8）の主題です。結論を先に言うと、「毎回同じか」を捨てて「許容範囲に入っているか」に置き換えることになります。そのために という考え方を持ち込みます。従来のテストとは別の道具立てが要る領域です。
実務上いちばん効くのは、非決定的な部分を狭く閉じ込める設計です。LLM に投げる範囲を最小にし、その前後（入力整形・出力の型チェック・後処理）は従来どおり決定的に保つ。こうすると非決定なテストを書く対象が減り、大半は普通のテストで守れます。
5. 費用対効果で優先順位をつける
全部にテストを書く前提を捨てると、どこから守るかという問いになります。判断材料は 2 つだけで足ります。壊れたときの損害と、壊れる頻度です。
- 1壊れたら金銭・信用に直結する経路 — 決済、権限判定、請求計算。ここは最優先で、遅くても厚く守る
- 2壊れても気づけない経路 — バッチ、非同期処理、集計。人が見ていないので検知の仕組みが要る
- 3頻繁に変更が入る箇所 — 変更のたびに壊れる可能性がある。回帰の網をかける価値が高い
- 4変更が入らず、壊れても気づける箇所 — 後回しでよい。ここに時間を使っても効果が薄い
この順位づけは、AI にテストを書かせる場合こそ重要になります。指示なしに書かせると、書きやすいところ（純粋関数、変換処理）に偏りがちだからです。書きやすさと守るべきさは一致しません。どこを守るかは人間が決め、書く作業を任せるという分担が現実的です。
テストは「正しさの証明」ではなく「変更の安全装置」。証明しようとすると終わらないが、安全装置と考えれば、どこに付けるかを費用で決められる。
6. この連載で扱うこと
以降は、粒度（EP.2）、実行速度（EP.3）、E2E の線引き（EP.4）、回帰の設計（EP.5）、スナップショットの罠（EP.6）と進み、後半で LLM 出力の検証（EP.7・EP.8）、 での自動化（EP.9）、 コストの削減（EP.10）、フレーキーテスト の運用（EP.11）を扱います。最後にアンチパターンをまとめます（EP.12）。
AI を前提にした開発体制そのものについては Claude Code 受託開発記 で扱っています。特に EP.09「レビュー文化」 と EP.04「どこまで任せるか」 は、この連載の前提と重なる部分が多いので、あわせて読んでいただくと理解しやすいはずです。
テストの目的は変わっていないが、コストの構造が変わった。書くのが安くなり、確かめる・待つ・直すが相対的に重くなった。だから連載では実行速度と妥当性の判断、そして非決定的な対象の扱いに紙面を割きます。続編は読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。