E2Eテストとは。AI時代でも変わらない5つの限界と単体テストとの使い分けを整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Kuniwakさんのブログ「若くない何かの悩み」の記事『E2Eテスト大全（あなたの知らない、E2Eテスト周辺の理論）』を紹介します。E2Eテストの定義から実装パターンまでを整理した記事です。

私が保存したブックマークです。読みながら重ねたのは、私の過去記事にある「確かめることと、変えることは、別の承認として分ける」「作った本人は、確かめる側に回らない」という考えでした。AIにコードやテストを書かせる時代の話として、読み直してみました。

読み方の筋は、E2Eテストとは何か、見つかる欠陥、利点、5つの限界、AI時代の頼み方、分類、作り方と時期の順です。Kuniwakさんの主張はKuniwakさんの言葉として整理します。私の読みを書く所は、そう分かる形で書きます。

Kuniwakさんの記事「E2Eテスト大全」の節「E2Eテストの境界と定義」

E2Eテストとは、文字通り「端から端まで（End-to-End）」をつなぐテストを指します。

つまり、利用者が直接触れる入口から、データを保存する層まで全部をつないで、入口の側から操作して結果を確かめるテストです。入口は、画面のあるシステムなら画面になります。

APIサービスなら、公開されているAPIの入口です。

ここが最初の分かれ目です。

どこまで本物をつなぐかにも線があります。Kuniwakさんは、自社で管理しているバックエンドやデータベース、ワーカーは本物を結合すると書いています。

外部の決済代行サービスや外部IDプロバイダのように自組織の外にある物は、テストダブルに差し替えてよいそうです。テストダブルとは、本物の代わりに使う偽物の部品のことです。

画面を操作すれば、それがE2Eになるわけではありません。

Kuniwakさんが挙げるのは、UIカタログの上でスクリーンショットの差分を見るテスト（Visual Regression Testing）や、部品の操作イベントを確かめるテストです。

どちらもUIのテストではあっても、データベースやバックエンドとつながっていないので、E2Eではないと整理されています。逆に、画面を一切触らないE2Eもあります。

公開されているWeb APIやバッチ処理に、APIリクエストを送って保存結果を確かめる形です。

私の読みです。発注先から「E2Eテストはやっています」と言われたら、画面を触っているかどうかではなく、端から端までどこまでつながっているかを聞く。ここが分かれ目かな、と思います。

あなたがAIにテストを書かせる場面でも、この線は使えます。「E2Eで確かめて」と頼む前に、どこまで本物をつなぐのかを一言添えるだけで、返ってきたテストの形を見分けやすくなる、と私は考えます。

画面かどうかは、決め手になりません。

Kuniwakさんは、この定義を特定の言語やツールに寄せずに書いています。道具が変わっても、線の引き方はそのまま持っていける。使いやすい整理だと私は受け取りました。

Kuniwakさんの記事「E2Eテスト大全」の節「E2Eテストで検知可能な欠陥」

活性違反：仕様上、受け付けなければならない操作を実装が拒否する欠陥。

活性違反とは、受け付けなければならない操作を、実装が断ってしまう欠陥のことです。Kuniwakさんは、E2Eテストで見つかる欠陥を、まず大きく二つに分けています。

見る方向は2つあります。

一つ目は正当性違反で、仕様を満たしていない欠陥です。二つ目は妥当性違反で、要求に照らして目的を満たさない欠陥です。前者は、活性違反と安全性違反に分かれます。後者は、性能劣化と低使用性に分かれます。

踏切と自動販売機のたとえが分かりやすいんです。活性違反は、電車が近くにいないのに遮断機が上がらない。十分な金額を入れたのに、在庫のある商品のボタンが点かない。安全性違反は、その逆です。

電車の通過中に遮断機が上がる。金額が足りないのにボタンが有効になって商品が出る。

妥当性違反の例も、元記事にあります。性能劣化は、遮断機が閉まるまでに5分以上かかる、ボタンが点くまで数十秒かかる、という例です。

低使用性は、警報灯が虹色に点滅して危険の切迫度が分からない、商品選びに13桁のJANコードの手入力が要る、という例です。

Kuniwakさんは、この区別を、Boehmの検証（正しく作っているか）と妥当性確認（正しいものを作っているか）の区別に対応させています。文献は[Boehm 1984]です。

AI氣道『WAF Dojoとは。AWS WAFのルールを書く練習ゲームを小さな会社の目線で整理』より

「採点は攻撃のブロック率と誤ブロック率の両方で決まります。」

止めるべき通信を止めた割合と、誤って止めた割合の両方で採点する見方を、私は『WAF Dojoとは。AWS WAFのルールを書く練習ゲームを小さな会社の目線で整理』で書いています。

私はWAF Dojoを動かしていません。READMEの説明として読みました。止めるべき通信を止めた割合と、普通の通信を誤って止めた割合の両方で点数が付く。

この採点の見方は、受け付けるべき操作を断っていないかと、受け付けてはいけない操作を受け付けていないかの両方を見る話と、形が似ていると私は読みます。

これは私の読みであって、Kuniwakさんが言っていることではありません。片方だけ見ても足りない、という形が似ているだけです。

片方だけ見ても、足りません。

あなたの現場でも、動いてほしい時に動くかだけでなく、動いてはいけない時に動かないかを見ているか。そこを見直す入口になると思います。

Kuniwakさんの記事「E2Eテスト大全」の節「E2Eテストの利点」

結合バグとは、個々のコンポーネントに対する単体テストがすべて成功しているにもかかわらず、それらを相互接続すると発生する欠陥を指します。

結合バグとは、部品ごとの単体テストがすべて通っているのに、つなぐと出てくる欠陥のことです。Kuniwakさんは、E2Eの利点を三つ挙げています。

部品は全部合格です。

一つ目は、その結合バグを見つけられること。契約による設計（Meyer 1992）の言葉でいうと、前の部品の事後条件と、後ろの部品の事前条件が食い違っている状態です。

例はMyersの三角形問題です。3辺を文字列で受けて、正三角形、二等辺三角形、不等辺三角形のどれかを答えるシステムで、部品は入力を確かめるバリデーションと、種類を判定する分類の二つです。

バリデーションは、3要素が自然数なら通します。分類は、昇順に並んで三角形として成り立つ前提で判定します。

ここに文字列「5, 1, 1」を入れると、バリデーションは正常として通し、分類は5+1>1だけで判定して、二辺が等しいので二等辺三角形と答えます。実際には三角形になりません。

単体テストは合格しているのに、つなぐと欠陥が出るんです。

ただしKuniwakさんは、見つける手段はE2Eだけではないとも書いています。設計の段階で部品どうしの仕様の関係を確かめれば、実装の前に見つかる。

E2Eで見つけるのは、それを実装の後まで持ち越している面がある、という指摘です。

二つ目は高い忠実度。単体テストのテストダブルが本物の挙動をまねきれていないと、テストが通っても、本物とつなぐと失敗します。E2Eは本物同士をつなぐので、この食い違いを減らせます。

三つ目は、内部設計に左右されないこと。依存性注入（DI、部品が使う相手を外から差し込む作り方）が無いコードでは、単体テストを書くこと自体が重い作業です。

E2Eは外から全体を動かすので、中が絡み合っていても書けます。レガシーコードを変える時の保護ネット（Feathers 2004）として重宝されるのは、このためです。

それでも、つなぐと壊れます。

私の読みです。発注先に「テストは通りました」と言われたら、部品ごとの話か、つないだ状態の話かを聞き分けたい。同じ「通った」でも、確かめた範囲がまるで違います。

Kuniwakさんの記事「E2Eテスト大全」の節「カバレッジの組み合わせ爆発」

したがって、結合によって生じるすべての組み合わせをE2Eテストだけで網羅しようとするアプローチは破綻します。

つまり、結合で生じる組み合わせをE2Eだけで全部確かめようとすると、破綻する。Kuniwakさんは、その理由を5つの限界に分けて説明しています。元記事自身が、単純化したモデルだと断っています。

5つとも、構造で説明できます。

一つ目は、実行の重さ。単体テストは1件がミリ秒、E2Eはブラウザの起動やネットワーク通信で1件が数十秒で、4桁から5桁の差があります。

CI（コードを変えるたびに自動でテストを回す仕組み）に許された時間が決まっていれば、E2Eの件数も4桁から5桁少なくなる計算です。並列化では追いつかないそうです。

二つ目は、壊れやすさ。各部品が下にN個の部品をつなぐ木がM層続くと考えます。仕様が1か所変わると、単体テストで直すのは高々K個。E2Eは最悪、全部です。

N=4、M=4、K=4なら、単体は4件、E2Eは最大1,024件で、影響範囲は256倍。ログインに2段階認証を必須にすれば、ログインが要るE2Eが全部壊れます。

三つ目は、原因の探しにくさ。失敗した時の原因の候補は、単体なら1部品、E2Eなら最大256部品で、調べる時間も最大256倍です。

四つ目は、結果の不確実性。個々の失敗率が0.1%で、失敗が互いに独立だと仮定すると、100個が直列につながった時の成功率は約90.5%に下がります。10回に1回は、欠陥と無関係に失敗する計算です。

結果が不安定なテストはFlakyと呼ばれます。Kuniwakさんは、実際には障害に相関があり、独立の仮定は傾向を示すだけだと断っています。

五つ目は、組み合わせ爆発。分岐N通りの部品Aと、M通りの部品Bを直列につなぐと、網羅に必要な件数は単体ならN+M、E2EならN×Mです。N=4、M=4なら8件と16件。

悪口ではなく、性質の話です。

私の読みです。E2Eは遅い、壊れる、不安定という声は、悪口ではなく、構造で説明できる性質なんですよね。「E2Eが不安定でやめた」と聞いたら、5つのどこに当たったのかを聞く。

あなたが話を整理する手がかりになると思います。

Kuniwakさんの記事「E2Eテスト大全」の節「AI時代における制約の不変性」

しかし実行時間の物理的な遅延、ネットワーク越しの確率的失敗、組み合わせ爆発という数理的性質はテストコードの作成者が人間からAIに代わっても解消されません。

つまり、テストを書く速さがAIで上がっても、実行の遅さ、確率的な失敗、組み合わせ爆発は消えません。

Kuniwakさんは、AIにE2Eの実行と自動修正を回させると、1回ごとに数十秒から数分の待ちが出ると書いています。

任せる所と決める所を分けます。

元記事の例は、ECサイトの決済に、通常とプレミアムのチェックアウトを足す場面です。指示Aは、E2Eで決済が通ることを確かめて、と頼む形。

AIはブラウザを動かして確認を繰り返し、待機時間やセレクタ（画面の部品を指定する書き方）のずれで、修正ループが長引きます。

指示Bは、通常とプレミアムの判定と割引計算を別々のクラスに分けて設計し、分岐は単体テストで網羅し、E2Eには「プレミアム会員で入ると、プレミアムの経路が選ばれる」代表1本だけ足す形です。

確認がミリ秒の単体テストに寄るので、AIの試行錯誤は短く済みます。

自動修正（Self-Healing）にも触れていて、セレクタの修復のように期待結果の核心を書き換えない範囲なら実害は少ない、とあります。それを超えると実装の追認でしかなく、むしろ有害だと書いています。

ここからは私の読みです。AIに任せてよいのは、守りたい操作の洗い出しと、テストの下書き、実行結果の整理。人が決めるのは、何を期待結果とするかと、それを変える承認です。

テストと自動修正まで一緒に任せると、確かめることと変えることが一体になり、期待結果が実装に合わせて書き換わる恐れがあるからです。

AI氣道『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』より

「確かめることと、変えることは、別の承認として分けておきます。」

確かめることと変えることを別の承認として分ける考えを、私は『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』で書いています。

2026年10月28日、Tailscaleの公式ブログに、SSHとServeの不具合を直した1.104.4の発表が載りました。その日のうちに、AIに頼んで自分のMacを確かめています。

設定は一つも変えていません。確かめられたのはMac 1台だけで、ほかの9台は「未確認」と書いて残しました。変えるのは、確認が終わってから、別の承認を取って決める。その順番です。

線は、ここに引けそうです。

私の読みでは、Kuniwakさんの言う「実装の追認」は、この分け方に重なって見えます。確かめる役と直す役を分け、期待結果を動かす時だけ人が承認する。AIにテストを頼む線は、そこに引くのがよさそうです。

Kuniwakさんの記事「E2Eテスト大全」の節「目的と状況に応じたテスト手法の選択」

最も堅牢な組み合わせは、状態遷移モデルに基づくグラフベーステストと高価値シナリオを固定した例ベーステストの併用です。

つまり、いちばん堅いのは、状態遷移モデルから探索するグラフベースと、大事なシナリオを固定した例ベースの併用だ、とKuniwakさんは言います。まず、元記事の分類を順に見ます。

手法は5つあります。

操作を機械的な規則で選ぶルールベースは三つです。例ベースは、決めた操作の順番（イベント列）を実行して、期待結果を確かめます。主に活性違反を見ます。

グラフベースは、Kuniwakさんが整理した手法です。

状態遷移モデル（状態と操作の移り変わりを描いた図）をもとに、実行した操作の列が仕様に含まれるか、実装が断る操作が仕様の範囲内かを確かめながら、断られない操作を選んで進みます。

広げるには実行時間を増やします。

モンキーベースも筆者の整理で、画面上の操作できる要素を自動で抜き出し、操作し続けます。仕様モデルは持たず、クラッシュや未処理例外、HTTP 500のような一般的な欠陥と、性能劣化が見えます。

人やAIの判断で選ぶ非ルールベースは二つ。ペルソナベースは、想定ユーザーの状況からゴールを推測して試し、使いやすさを見ます。

エラー推測ベースは、特殊文字の入力や戻るボタンの連打など、過去に不具合が多かった所を狙います。

推奨は冒頭の併用です。状態遷移モデルは、開発の初めにAIエージェントへの厳密な仕様にも流用できます。

ただ、グラフベースは巡回なので、「会員登録して、カートに入れ、クーポンを使って購入する」大事な流れを、限られた時間で通す保証がありません。そこは例ベースで固定します。

状態遷移モデルを作る余裕が無く、過去の障害の記録があるなら、エラー推測と大事なシナリオ。仕様モデルも記録も無い新規のシステムなら、モンキーベースと大事なシナリオで、既成のツールを使えます。

使いやすさも見たいなら、ペルソナベースを足します。

LLMを使った自律エージェントにペルソナを与える方法は、人によるユーザビリティテストの前段階のふるいに使える、とも書かれています。

選ぶ手がかりは、手元にあるものです。

私の読みです。あなたの現場に合う道は、過去の障害の記録があるか、仕様の図があるかで選べそうです。ここは元記事の整理をそのまま並べた所です。

Kuniwakさんの記事「E2Eテスト大全」の節「結合後のアプローチ」

しかし、テストコードが「本来あるべき仕様」ではなく「現に動いてしまっている実装の挙動」を無批判に追認してしまう危険性が高くなります。

つまり、動いている実装に合わせて書くと、本来あるべき仕様ではなく、現にある挙動を正解にしてしまう恐れがあります。Kuniwakさんが結合後のアプローチで指摘する点です。先に、壊れにくい書き方を見ます。

作る時期にも、一長一短があります。

ReusableOperatorパターンは、Kuniwakさんが整理したパターンです。セレクタの指定や文字入力、クリックといった低レベルの操作と、高レベルなイベントを分けます。

イベント名で操作を引く辞書にしておけば、画面が変わっても直すのは辞書の1か所です。

画面やUI部品の単位でまとめたものが、PageObjectパターンです。ContextStreamパターンは、画面遷移を、画面と文脈を受け取って次の画面と文脈を返す関数として組みます。

ログインの前にマイページは開けない、という前後関係を、実行前の型の検査で弾けます。

Record & Playbackは、人やAIの操作の記録を再生します。作り始めは速いものの、画面の構造やタイミングの変化に弱い。

テストケース連鎖は、Aが成功した時だけAの終わりの状態を引き継いでBを始め、時間を減らします。Aの影響でBの結果が変わる恐れがあるので、データの分離が前提です。

作る時期は二つです。実装の前に作ると、要求仕様から開発でき、通ったシナリオの本数がそのまま進捗の目安になります。実装の都合で書き直す手間は出ます。仕様が固い基幹業務に向きます。

実装の後に作ると、動いている画面やAPIに書くので手戻りが少なく、作業は進みます。欠点が冒頭の追認で、結合が終わる終盤まで全体を確かめられない点もあります。

探索的な新規開発や、既存システムの回帰の防止に向きます。

AI氣道『AIエージェントの役割・権限・記憶は、全部を一度に作らず、動くのを確かめてから次を足す。英語の動画2本から』より

「作った本人は、確かめる側に回らない。ここは私も同じです。」

作った本人は確かめる側に回らないという考えを、私は『AIエージェントの役割・権限・記憶は、全部を一度に作らず、動くのを確かめてから次を足す。英語の動画2本から』で書いています。

動画2本を整理したその回では、作者ではない検証役を新しい文脈で動かす設計を紹介しました。

Claude Codeのセミナーの発話記録に残る私の発言を言い換えると、AIはやった後に、本当はできていないのに、できましたと言うことがある、だから本当にできているかを別のAI、サブエージェントに確認させてほしい、という趣旨です。

作った時の思い込みで読むと、抜けた所もできた所に見える。そう書きました。

確かめる役は、別にします。

私の読みです。Kuniwakさんの「結合後は追認しやすい」は、AIが書いた実装をAIが書いたテストで確かめる時にも、起きうる話だと考えます。

Kuniwakさんの記事は、E2Eテストを、利用者の入口から保存先まで本物をつないで確かめるテストと整理していました。画面を触るかどうかでは決まらず、結合バグを見つけられる強みがあります。

数字は、元記事のモデルのものです。

同時に、遅い、壊れやすい、原因が探しにくい、不安定、組み合わせが爆発する、の5つの限界があります。数字は元記事の単純化したモデルのもので、書く人がAIに替わっても変わらない、というのがKuniwakさんの見立てです。

私の読みでは、私の読みでは、AIにテストを頼む線は、任せてよい所と人が決める所の間に引けます。洗い出し、下書き、結果の整理はAIに。期待結果と、それを変える承認は人が持つ。確かめる役と直す役も分けて頼みたい、と考えます。

選ぶのは、あなたの現場です。

次の一歩は、どちらか一つで十分です。発注先やAIに「テストは通りました」と言われたら、誰が期待結果を決めたかを一つ聞く。AIにテストを頼む時は、確かめる役と直す役を分けて頼む。あなたの現場で、先に試せそうな方を選んでください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！