E2E・結合テストのシナリオをAIに書かせる——観点の渡し方
単体テストはひととおり書けた。関数ごとの確認は緑に揃っている。 でも、いざ「画面から登録して、決済して、メールが届くまで」を通しで確かめようとすると、どこから書けばいいのか、手が止まる——そんな経験、ありませんか。
部品ごとの確認（単体テスト）と、通しで動かす確認（E2E・結合テスト）は、頭の使い方が別ものです。E2Eは組み合わせの数が一気に増えるので、「全部書く」は現実的ではありません。だからこそAIに洗い出しを手伝ってほしいのですが、「E2Eテストのシナリオを作って」と丸投げすると、たいてい正常系（うまくいく道）ばかりが返ってきます。AIはあなたの業務ルールも、過去に事故った箇所も知らないからです。この記事では、AIに筋の良いシナリオを出してもらうための「観点の渡し方」を、そのままコピーして使える形で整理します。
結論：E2E・結合テストをAIに任せるコツは、「シナリオを作って」ではなく「観点を渡して、その観点ごとにシナリオを出させる」ことです。渡す観点は5つ。①主要な業務フロー（ユーザーが実際にたどる代表的な道を最初に固める）、②異常系・中断（途中で失敗・離脱・タイムアウトしたらどうなるか）、③境界と状態（初回／2回目、在庫0、権限なし、上限ちょうど）、④連携の境目（サービスやDBをまたぐ所で、データが正しく渡り、片方が落ちても壊れないか）、⑤データの後始末（テストが互いに汚さないよう独立して立つか）。進め方は、（1）システムの前提と主要フローをAIに説明する →（2）フローを1本、正常系で固める →（3）その1本に対して観点ごとの派生シナリオを洗わせる →（4）出てきた案を業務知識で取捨選択する。全部を自動で書かせるのではなく、AIが「抜けの候補」を広げ、あなたが「本当に要るもの」を選ぶ。この分担がいちばん速くて、漏れも減ります。
「E2Eは大変」と身構えてしまうのは、たいてい一度に全部を完璧に書こうとするからです。 実際には、代表的な1本を通してから、そこに枝を足していけば十分。今日は、その最初の1本と、枝の広げ方を、AIと一緒に組み立てていきましょう。
まず、単体テストとE2E・結合テストの「見る場所」を分ける
AIに観点を渡す前に、自分の中で「今、どの層を書きたいのか」をはっきりさせておくと、指示がぶれません。ざっくり、こう分けて考えると迷いません。
- 単体テスト：関数やクラス1つが正しく動くか。周りは切り離して確認する。
- 結合テスト：部品と部品のつなぎ目が正しく噛み合うか。たとえば「サービスがDBに正しく書けているか」「APIクライアントが外部の応答を正しく受け取れているか」。
- E2Eテスト：ユーザーの入口から出口までを通しで確認する。画面の操作から始まって、裏で処理が走り、結果が返り、記録が残るまでを1本の道として見る。
大事なのは、E2Eは「単体テストの寄せ集め」ではないということです。部品が一つずつ正しくても、つなぎ目でデータの形がずれていたり、順番が違ったりして、通すと壊れることがある。E2E・結合テストは、その「つなぎ目と通し」でしか見つからない不具合を拾う場所です。だから観点も、単体とは変える必要があります。この違いを一言AIに伝えるだけで、返ってくるシナリオの粒度が変わります。単体側の洗い出しはAIにテストケースを洗い出させるときの観点の与え方も合わせてどうぞ。
AIに渡す「5つの観点」
丸投げで正常系ばかりになるのを防ぐ一番の方法は、観点をこちらから名指しで渡すことです。次の5つを、そのままAIへの指示に貼り付けてください。
① 主要な業務フロー（まず代表の1本） ユーザーが実際にいちばん多くたどる道を、最初の1本に選びます。「未ログインの人が商品を選び、会員登録し、決済し、完了メールを受け取る」のような、端から端までの代表フロー。ここが固まっていないと、枝を足しても土台がぐらつきます。
② 異常系・中断（うまくいかない道） 正常系の裏で、必ず起きる「失敗・中断」を洗います。決済が拒否された、途中でブラウザを閉じた、通信が切れた、二重に送信した、タイムアウトした。E2Eで本当に怖いのは、この中断のときに中途半端な状態が残ること（お金は引かれたのに注文が未確定、など）。ここをAIに名指しで挙げさせます。
③ 境界と状態（初回・上限・権限） 同じ操作でも、状態が違うと結果が変わる所です。初回か2回目か、在庫が1か0か、上限ちょうどか1つ超えたか、権限のあるユーザーかないユーザーか。単体でいう境界値の考え方を、通しの流れに広げます。境界の詰め方は境界値・異常系をAIに考えさせて漏れを減らす手順が近い話です。
④ 連携の境目（またぐ所） サービス間、DB、外部APIなど、部品をまたぐ継ぎ目を狙います。データが正しい形で渡っているか、片方が遅い・落ちているときに全体がどう振る舞うか。結合テストの主戦場です。
⑤ データの後始末（独立して立つか） 各シナリオが、他のシナリオのデータを汚さずに独立して動くか。ここが甘いと、通ったり落ちたりする不安定なテスト（Flaky）になります。詳しくはたまに落ちるテスト（Flaky）の原因をAIに切り分けさせる手順へ。
この5つを渡すだけで、「うまくいく道」一辺倒だったAIの返答が、ぐっと立体的になります。
手順：前提を渡し、1本を固め、観点で枝を広げる
観点がそろったら、順番に進めます。いきなり全シナリオを求めず、土台の1本 → 派生の枝の順で広げるのがコツです。
手順1：システムの前提と主要フローを説明する
AIはあなたのシステムを知りません。まず、登場人物・扱うデータ・使っている外部サービス・代表的なユーザーの流れを短く渡します。ここを省くと、一般論の当たり障りないシナリオしか返りません。
手順2：主要フローを1本、正常系で固める
代表フローを、うまくいく前提で端から端まで書かせます。ステップを番号で並べ、各ステップで「何を操作し、何を確認するか」まで出させると、後で枝を足しやすくなります。
手順3：その1本に、観点ごとの派生シナリオを洗わせる
固めた1本に対して、先ほどの5観点を当てて「ここで中断したら」「この状態だったら」を広げさせます。聞き方の例：
次のE2Eの正常系フローを土台に、テストすべき派生シナリオを洗い出してください。
まだテストコードは書かず、「シナリオの一覧」として出してください。
以下の観点ごとに、それぞれ2〜3個ずつ挙げてください：
① 異常系・中断（決済失敗／通信断／二重送信／タイムアウト／途中離脱）
② 境界と状態（初回か再訪か／在庫0／権限なし／上限ちょうど）
③ 連携の境目（外部APIが遅い・落ちている／DBへの書き込み失敗）
④ データの後始末（このシナリオが他のテストのデータを汚さないか）
各シナリオは「前提 → 操作 → 期待する結果」の3行で書いてください。
特に、途中で失敗したときに『中途半端な状態が残らないか』を必ず含めてください。
--- システムの前提 ---
（登場人物・扱うデータ・外部サービスを貼る）
--- 土台となる正常系フロー ---
（手順2で固めた1本を貼る）手順4：出てきた案を、業務知識で取捨選択する
ここが人の仕事です。AIは「起こりうること」を広く挙げますが、あなたの業務で本当に守るべき所、過去に事故った所は知りません。返ってきた一覧から、優先して自動化する数本を選び、いらないものは落とす。AIが候補を広げ、あなたが要るものを選ぶ——この取捨選択を挟むだけで、量に溺れず、抜けも減ります。
AIのシナリオを、そのまま信じないためのチェック
AIが出したシナリオには、もっともらしいけれど的外れなものや、逆に現場でいちばん怖い所が抜けていることがあります。採用する前に、次を軽く見ておきましょう。
- 正常系に偏っていないか：中断・失敗の道が薄いなら、②異常系をもう一度名指しで頼む。
- 「途中で失敗したとき」が入っているか：E2Eで最も価値が出るのはここ。お金・在庫・予約など、中途半端が許されないものの中断シナリオがあるか。
- 業務ルールを取り違えていないか：AIは一般論で書くので、あなたの仕様と食い違うことがある。数値や条件は自分の仕様で確かめる。
- 他のテストと状態を共有していないか：⑤の後始末が甘いと、通ったり落ちたりする不安定なテストになる。
- 1シナリオが大きすぎないか：欲張って1本に詰め込むと、落ちたとき原因が読めない。1シナリオ＝1つの意図に割る。
生成物をそのまま使わない構えは、テストでも同じです。単体テスト側の確認は生成された単体テストを信用しすぎないための確認ポイントにまとめてあります。
ありがちな落とし穴と、その回避
- いきなり「全シナリオを書いて」と頼む：正常系の羅列が返り、肝心の異常系が薄い。観点を名指しで渡し、1本ずつ広げる。
- 前提を渡さずに聞く：一般論のE2Eしか出ない。登場人物・データ・外部連携を先に短く共有する。
- 正常系だけ自動化して安心する：本番で壊れるのは中断・境界。「途中で失敗したら」を必ず1本入れる。
- 1シナリオに機能を詰め込む：落ちた原因がわからなくなる。意図ごとに分ける。
- データの後始末を後回しにする：不安定なテストになり、赤信号が信用されなくなる。各シナリオが独立して立つように最初から設計する。
- AIの数値・条件を鵜呑みにする：業務ルールはAIの推測ではなく、自分の仕様で裏を取る。
落とし穴の多くは、「E2Eは大変だから一気に片付けたい」という気持ちから、観点を渡す一手間を飛ばす所で生まれます。急がば回れで、5観点を渡してから広げるだけで、後から「あの道が抜けてた」と戻される消耗がぐっと減ります。
明日からやること（小さく始める3つ）
いきなり全画面のE2Eを揃えなくて大丈夫です。まずこの3つから。
- いちばん大事な業務フローを1本だけ選び、正常系で端から端まで書いてみる：土台の1本ができると、枝を足すのが一気に楽になります。
- その1本に「途中で失敗したら」の中断シナリオを1つだけ足す：お金・在庫・予約など、中途半端が許されない所から。ここがE2Eの価値の出所です。
- 派生シナリオの洗い出しはAIに5観点で頼み、要るものだけ自分で選ぶ：広げるのはAI、選ぶのは自分。この分担を一度試してみてください。
この3つだけでも、「E2Eはどこから手をつければ」と感じていた作業が、少しずつ「順番に足していける作業」に変わっていきます。
コピーして使う「E2E・結合テスト シナリオ洗い出しシート」
新しいフローをテストするときに、上から順に埋めてください。全部でなく、わかる所からで十分です。
# E2E・結合テスト シナリオ洗い出しシート
## 0. 前提を書く
- [ ] 登場人物（誰が使う？ 権限は？）
- [ ] 扱うデータ（お金・在庫・個人情報など、壊せないもの）
- [ ] 外部連携（決済・メール・外部API・別サービス）
## 1. 主要フロー（土台の1本）
- [ ] 代表的なユーザーの道を、入口から出口まで番号で
- [ ] 各ステップで「操作」と「確認すること」を書いた
## 2. 派生シナリオ（5観点で広げる）
- [ ] ① 主要フローの別ルート（別の代表ケース）
- [ ] ② 異常系・中断（失敗／離脱／二重送信／タイムアウト）
- [ ] └ 途中で失敗したとき、中途半端な状態が残らないか
- [ ] ③ 境界と状態（初回／再訪・在庫0・権限なし・上限ちょうど）
- [ ] ④ 連携の境目（外部が遅い・落ちている／書き込み失敗）
- [ ] ⑤ データの後始末（他のテストを汚さず独立して立つか）
## 3. 取捨選択する
- [ ] 業務で本当に守るべき道を優先して選んだ
- [ ] 過去に事故った箇所が入っているか確認した
- [ ] 1シナリオ＝1つの意図に割れているか最後に
単体テストは緑なのに、通しで動かす確認の欄が真っ白なまま。 その前で手が止まる気持ち、よくわかります。でも、「部品は確かめた。次は通しで確かめたい」とあなたが思えている時点で、品質を守る目線はもう十分に働いています。一番むずかしいのは、その一歩を踏み出す前の「どこから？」だけです。
一度に全部のシナリオを揃えなくて大丈夫です。今日ひとつ、「大事なフローを1本、正常系で通す」だけ試してみる。そこに「途中で失敗したら」を1本足せば、もうE2Eは始まっています。広げるのはAI、選ぶのはあなた。この分担さえ持てば、身構えていた通しのテストも、順番に足していける作業に変わります。
よければ、こちらも
関連用語
</content> </invoke>