夕方の開発オフィスで、ノートPCに並んだたくさんのテスト項目の雰囲気と、手元の工数メモを見比べながら、どこから手をつけるか考えている開発者
テスト・品質約13分

AIにテスト戦略を相談する｜どこを厚く薄くするかの決め方

リリースまで残り2週間。上からは「AIがあるんだから、テストも全部書けるよね」。AIに頼めば、テストコードは確かに数分で何十本も出てきます。でも、出てきたテストを読んで、直して、CIで回して、落ちたら調べて——それをやるのは自分たちで、時間は増えていない。 「結局、どこまでテストすればいいんだろう」と、画面の前で手が止まる。そんな夜、ありませんか。

それは、あなたの手が遅いからではありません。テストに使える時間には、もともと限りがあります。AIで書く速さが上がっても、読む・直す・保守する時間はゼロにはなりません。だからこそ、「全部を同じ厚さで」ではなく「どこを厚く、どこを薄くするか」を決めることが、いちばん効く一手になります。

結論：AIにテスト戦略を相談するときは、①機能ごとに「壊れたら困る度合い」と「変わりやすさ」を人が先に書き出して渡す、②AIに「厚く／ふつう／薄く」の配分案と、それぞれをどの種類のテスト（単体・結合・E2E）で守るかを、理由つきで出させる、③配分は工数の見積もりと突き合わせ、「薄くする所」を言葉にしてチームと合意する、の3手順で進めます。AIに決めさせるのではなく、判断材料を並べさせる。どこを守るかを決めるのは、事業と現場を知っている人です。

「薄くする」と書くと、手を抜くように聞こえるかもしれません。 でも、薄くする所を決めるのは、厚くする所を本当に守るための判断です。

なぜ「AIに全部テストを書かせる」はうまくいかないのか

AIでテストを量産しても、守りたい所が守れていない——そうなりやすい理由は、主に4つあります。

カバレッジの数字が上がっても安心しきれない理由は、AIのテストはカバレッジが高い｜意味のあるテストとの差でも詳しく整理しています。

「壊れたら困る度合い」と「変わりやすさ」で、厚さを決める

高さの違う3つのカードの山を左から並べた図。左は高く積まれた山で「厚く」、中央は中くらいの山で「ふつう」、右は低い山で「薄く」
全部を同じ高さに積むのではなく、壊れたら困る所ほど高く積みます。低い山は「捨てた所」ではなく「ここは軽めでいいと決めた所」です

テストの厚さを決める物差しは、まず2つで十分です。

  1. 壊れたら困る度合い：お金・個人情報・データの消失・法令や契約にかかわるか。壊れたときに、何人に、どれくらい迷惑がかかるか。
  2. 変わりやすさ・壊れやすさ：最近よく変更が入っているか、過去に不具合が出たか、処理が複雑か、外部とのつなぎ目か。

この2つを、機能ごとに「高・中・低」でざっくり付けてみます。たとえばこんな具合です。

機能壊れたら困る度合い変わりやすさ厚さの目安
請求金額の計算高（お金が直接ずれる）中（料金改定のたびに変わる）厚く
会員の退会・データ削除高（戻せない）低厚く（特に異常系）
外部の決済APIとの連携高中（相手側の仕様変更あり）厚く（結合テスト中心）
検索の絞り込み中高（要望が多い）ふつう
管理画面のラベル・並び順低高薄く

ポイントは、「厚く」が多すぎないことです。全部が「厚く」になったら、それは配分していないのと同じ。最初は全体の2〜3割を「厚く」に絞るくらいの感覚で付けると、メリハリが出ます（この割合は目安で、決まりではありません）。

そして、厚さと一緒に「どの種類のテストで守るか」も決めます。

「単体を多めに、E2Eは少なめに」という考え方は、テストピラミッドとしてよく知られています。ただ、Webアプリでは結合テストを厚めにする考え方（テスティングトロフィー）もあり、どの形が正解かはシステムによって変わります。形を先に決めるより、上の表のように機能ごとに「何で守るか」を決めるほうが、現場では迷いにくいです。

AIへの相談の仕方（コピーして使えます）

最初に渡したいのは、コードよりも「どこが大事か」という事情です。次の型で頼んでみてください。

これから作る（または改修する）機能群のテスト戦略を相談したいです。
1つに決め打ちせず、判断材料を並べてください。

## 前提（分かる範囲で）
- システムの概要：（例：会員制の予約サービス。決済あり）
- 言語・フレームワーク・テストツール：（例：TypeScript / Next.js、Vitest、Playwright）
- テストに使える工数：（例：2人で合計5日程度）
- 機能ごとの「壊れたら困る度合い」と「変わりやすさ」（高・中・低）：
  - 請求金額の計算：困る度合い=高 / 変わりやすさ=中
  - （以下、機能ごとに）
- 過去に不具合が出た所：（分かれば）

## お願いしたいこと
1. 機能ごとの「厚く／ふつう／薄く」の配分案（表で）。上の前提のどれを根拠にしたかも書く
2. 各機能を、どの種類のテスト（単体・結合・E2E・目視）で守るか
3. 「厚く」にした機能で、特に押さえるべき観点（境界値・異常系・同時実行など）
4. 「薄く」にした機能で、それでも最低限やっておくこと
5. 配分案が上の工数に収まりそうか、収まらない場合にどこを削る候補にするか

ルール：
- 前提から判断できない点は、推測で埋めずに「要確認」として、何を確かめれば決められるかを書く
- 「全部厚く」にはしない。厚くするのは全体の2〜3割程度を目安にし、それを超える場合は理由を書く

答えが出てきたら、人が見るのは3か所です。

  1. 配分の根拠：AIが「厚く」にした理由が、渡した前提（困る度合い・変わりやすさ）に基づいているか。「一般的に重要だから」だけなら、割り引いて受け取ります。
  2. 「薄く」にした所の最低限：薄くする所ほど、「それでも何をやるか」が書かれているかを見ます。ここが空欄だと、ただの抜けになります。
  3. 「要確認」の項目：チームで決めていなかったこと（「この画面、実は営業が毎日使っている」など）が浮かび上がる、いちばん価値のある出力です。

「厚く」にした所の具体的なテストケースを洗い出すときは、AIにテストケースを洗い出させる｜観点の与え方や境界値・異常系をAIに考えさせて漏れを減らす手順の型がそのまま使えます。

配分は、工数と突き合わせて合意する

配分案ができたら、最後に工数と突き合わせます。AIに出させた案は、だいたい理想寄りです。

上の配分案について、テストの作成と見直しにかかる工数を、
機能ごとにざっくり見積もってください（AIで下書きを作り、人がレビュー・修正する前提）。

- 作成：下書き生成＋人のレビュー・修正の時間
- 運用：CIでの実行時間の増え方、仕様変更時に直す手間の大きさ（大・中・小）
- 合計が「前提の工数」を超える場合は、削る候補を「削ったときに残るリスク」とセットで3つ挙げる

ここで大事なのは、AIで書く時間だけでなく、人が読んで直す時間も見積もりに入れることです。AIの下書きをそのまま信用できない理由は、AIが書いた単体テストを信用しすぎない｜確認ポイントにまとめています。見積もりの織り込み方は、「AIで早くなるよね」と言われた見積もり｜工数の織り込み方も参考にしてください。

そして、決めた配分はチームや上司と短く合意しておきます。とくに「薄くした所」は、言葉にして残すのがおすすめです。

こう書いておけば、後で何か起きても「テストしていなかった」ではなく、「ここは軽めにすると決めていた。次はこう見直す」と話せます。決めたことは、責める材料ではなく、次の判断の材料になります。

配分を決めておくと、何が変わるか

ありがちな落とし穴と、その回避

明日からやること（小さく始める3つ）

  1. 今いちばん触っている機能を5つ書き出して、「壊れたら困る度合い」を高・中・低で付けてみる：まずは自分の感覚で大丈夫です。
  2. その5つに「変わりやすさ」も付けて、上の相談の型でAIに配分案を出してもらう：まだテストは書かず、表と「要確認」だけ眺めます。
  3. 「薄くする所」を1つだけ決めて、理由を2行で書く：それをチームに見せるところから、配分の合意は始まります。

コピーして使う「テスト戦略 配分チェックリスト」

# テスト戦略 配分チェックリスト

## 1. AIに渡す前に
- [ ] テストに使える工数（人数×日数）を書いた
- [ ] 機能ごとに「壊れたら困る度合い」を高・中・低で付けた
- [ ] 機能ごとに「変わりやすさ・壊れやすさ」を高・中・低で付けた
- [ ] 過去に不具合が出た所を分かる範囲で書いた
- [ ] 使っている言語・フレームワーク・テストツールを書いた

## 2. 配分案を見るとき
- [ ] 「厚く」が全体の2〜3割程度に収まっているか（超えるなら理由があるか）
- [ ] 「厚く」の根拠が、渡した前提に基づいているか
- [ ] 機能ごとに、どの種類のテスト（単体・結合・E2E・目視）で守るかが決まっているか
- [ ] E2Eは大事な流れ数本に絞られているか
- [ ] 「薄く」にした所にも、最低限やることが書かれているか
- [ ] 「要確認」の項目を、チームで決めることとして拾った

## 3. 決めるとき
- [ ] 作成だけでなく、人のレビュー・修正時間も工数に入れた
- [ ] 工数を超える場合、削る候補と残るリスクをセットで並べた
- [ ] 「薄くした所」とその理由を、短く言葉にして残した
- [ ] チームや上司と配分を合意した

## 4. 運用しながら
- [ ] 障害が出た所・変更が増えた所の厚さを見直す時期を決めた

最後に

テストは、多ければ多いほど安心——そう思いたくなります。でも、時間が限られた現場で本当に効くのは、「ここだけは守る」と決めて、そこに力を集めることです。 薄くする所を決めるのは、手を抜くことではありません。大事な所を本当に守るための、ちゃんとした判断です。

明るいオフィスで、ホワイトボードの前に並んで立ち、配分を決め終えてほっとした表情で話している2人の開発者

一度に全部の配分を決めなくて大丈夫です。今日は、いちばん触っている機能を5つ書き出して、「壊れたら困る度合い」を付けるところから。どこが大事かを知っているのはあなたで、配分案を並べるのはAI。その分担で、限られた時間はちゃんと守りたい所に届くようになります。

よければ、こちらも

関連用語