AI時代のE2E中心テスト戦略とセルフホストCIの実現性

1. 発端

最近、テストをE2Eに寄せていくような流れをXで見かけることが多くなった。そのことについて検討してみた。

また、実行基盤側のアプローチ（セルフホストでCI/CDを組む等）も一つの解決策としてコメントをいただいたため、それも含めて考えてみることにした。

ChatGPTとClaudeと自分の3者で議論したものを、ここに整理する。

そこから、主に次の3つの疑問が発生した。

ローカルPCや自前GitLab Runnerで、実際にどこまで並列実行できるのか。複数人開発になった場合、その「ローカル」とは何を指すのか。
そもそも「ほとんどのテストをE2Eにし、Unit Testを減らす方がAIにとって良い」という前提自体が妥当なのか。
E2Eが数千〜数万ケースに増えた場合、実行時間・料金・1日のデプロイ回数は現実的なのか。

議論を進めた結果、問題は大きく3層に分けて考える必要があると整理できた。

テスト戦略
  ↓
何をどのレイヤーで保証するか

CI/CD設計
  ↓
どのテストを、いつ、どの頻度で実行するか

実行基盤
  ↓
Runner / CPU / RAM / I/O / DB / Network / 並列性 / コスト

今回の議論全体で重要だったのは、この順序を逆にしないことだった。

2. 最初の核心：E2Eで「できる」ことと、E2Eで「やる価値がある」ことは別

E2Eには大きな価値がある。

たとえば、

ユーザーがログインできる
商品を購入できる
管理者のみが承認できる
決済失敗時に注文が確定しない
ユーザー操作全体を通してデータ整合性が保たれる

といったものは、システム全体を通さなければ十分に保証しにくい。

一方で、システムには画面やブラウザとは独立したロジックが大量に存在する。

たとえば、

価格計算
税計算
割引計算
状態遷移
日付計算
バリデーション
権限制御
ドメイン不変条件
境界値
エラー条件
組み合わせ条件

などである。

これらを確認するために毎回、

Browser
 ↓
画面操作
 ↓
HTTP
 ↓
Application
 ↓
Domain
 ↓
DB
 ↓
HTTP Response
 ↓
Frontend
 ↓
画面表示
 ↓
Assert

まで通す必要はない。

したがって、判断軸は、

E2Eで検証可能か

ではなく、

システム全体を通すことでしか得られない追加の保証があるか

である。

3. 価格計算の例で見る「全部E2E」の非効率

たとえば次のような料金計算があるとする。

calculatePrice({
  basePrice,
  memberRank,
  campaign,
  coupon,
  taxRate,
})

条件が、

項目	種類数
会員ランク	5種類
キャンペーン	10種類
クーポン	10種類
税区分	3種類

であれば、単純な組み合わせだけでも、

5 × 10 × 10 × 3 = 1,500パターン

になる。

Unit Testなら、

input → calculatePrice() → expected

だけで検証できる。1,500ケースあっても、実装によっては数秒以下で終わる。

これを全部E2Eにすると、ログイン→商品選択→会員条件設定→キャンペーン適用→クーポン入力→購入確認→表示価格確認、を1,500回行うことになる。

ここで本当に知りたいことが「calculatePrice() のロジックが正しいか」なのであれば、Browser・Frontend・HTTP・DBまで通す価値は小さい。この状態は、UIを被せた高コストなロジックテストになりうる。

4. 「Unit vs E2E」という二択で考えるのも不十分

議論を進める中で、Unit TestとE2Eだけを比較するのも適切ではないことが見えてきた。特に重要なのがIntegration / Component Testである。

レイヤー	主な検証対象	特徴
Unit	計算、状態遷移、不変条件、純粋なビジネスルール	高速・局所的・失敗原因を特定しやすい
Integration / Component	DB、Repository、API、Transaction、Serialization、外部Adapter、Message	境界や結合部分を検証する
E2E	ユーザーから見たシステム全体の振る舞い	広い保証を得られるが実行コストが高い

同じ「価格」という機能でも、検証したい性質によってレイヤーを分けられる。

価格計算そのもの → Unit
Repository / APIを通して正しい価格になる → Integration
ユーザーが画面上で正しい価格を確認し、その価格で購入できる → E2E

重要なのは、古典的なTest Pyramidの形そのものを守ることではない。Testing TrophyのようにIntegrationを厚くする考え方もある。より一般化すると、

検証したい性質に対して、必要な保証を得られる最も適切なレイヤーを使う

ことが重要である。

5. Integration Testは「隠れた本丸」

今回の議論では、Integration Testの位置づけがかなり重要になった。実際の業務システムでは、純粋な関数内部よりも「境界」で問題が発生することが多い。

たとえば、

Frontend ↔ API
Application ↔ DB
Domain ↔ Persistence
Service ↔ Message Broker
Service ↔ External API

など。具体的には、

ORM Mapping
SQL Constraint
Transaction
Isolation Level
Serialization
API Contract
Repository
Message publish / consume
外部API Adapter
Retry
Timeout

などがある。これらをUnit Testだけで完全に確認するのは難しい。かといって、全部E2Eにする必要もない。適切なIntegration Testを置けば、Unitでは見えない + E2Eほど重くない という位置でかなりの問題を検出できる。

そのため、E2Eが肥大化しているシステムは、本来Integrationで確認すべき責務がE2Eへ漏れている可能性があるという見方もできる。

6. E2Eの実行コスト

仮に、10,000 E2Eケース・1ケース平均10秒だとする。

直列では、100,000秒 ≒ 27.8時間かかる。

20並列できたとして、完全に線形スケールすると仮定しても、27.8時間 ÷ 20 ≒ 83分となる。

実際には、Browser起動・Container起動・DB初期化・Fixture生成・Network・I/O・Retry・Resource contention・Flaky Test・Test Environment起動などがあるので、完全な20倍高速化にはならない。

7. AI時代はCIのフィードバック速度がより重要になる

たとえば、AIによる実装30秒・CI 2時間なら、システム全体の開発速度はほぼCIに支配される。

従来は、人間がコードを書く（数十分〜数時間）・CI（10〜20分）ならCI待ちがそこまで支配的でなかったかもしれない。しかしAIによって実装そのものが高速になると、実装30秒・テスト30分、という状態になる。

つまりAI時代には、テストフィードバック時間の相対的重要性が上がる可能性が高い。

8. E2Eの保守性について

当初は、「E2EはDOMやSelectorに依存して壊れやすい」という話も出た。これは傾向としてはあるが、少し単純化しすぎでもある。

Playwrightなどで getByRole() getByLabel() を使ったり、安定したtest idを設定したりすれば、単純なDOMリファクタにはかなり耐えられる。したがってE2Eの弱点を「UIが変わるたびに壊れる」とだけ捉えるのは正確ではない。

本質は、Browser・UI・Network・Backend・DBなど、多数の構成要素を跨ぐため、変動点と失敗要因が増えることである。

9. 反対側から見ると、Unit Testも変更に弱い

E2E中心派からは、逆方向の反論もできる。Unit Testは、class・function・module・interface・mock・dependency injectionなど、内部実装構造に結合しやすい。

たとえば、PricingService が CouponService・CampaignRepository・TaxCalculator のmockに依存する構造に密着したUnit Test群がある場合、内部を PricingEngine へ統合するだけで大量のテスト修正が必要になる可能性がある。外部仕様は変わっていないのに、内部リファクタでテストが壊れる。

一方、「クーポンを適用すると価格が10%下がる」というブラックボックステストであれば、内部構造を大きく変えても外部仕様が同じなら残る。

つまり、

E2E → 外部構造に結合しやすい
Unit → 内部構造に結合しやすい

という対称的な問題がある。

10. Mockによる「偽の安心」

E2E中心派からの強い反論の一つがMockの問題である。

repository.findUser.mockResolvedValue(user)

というUnit Testは通る。しかし実DBでは、NULL・Constraint・Transaction・Isolation Level・Collation・Timezone・Query semanticsなどが存在する。

Mockが表現しているのは「実際のRepository」ではなく「テストを書いた人が想像したRepository」である。したがって、Unit 10,000件 PASSしかし本番では失敗は起こりうる。

この意味では、実環境に近いものを動かせるなら、Mock中心のUnit Testを減らすべきという主張にも一定の説得力がある。ただし、この問題の多くはIntegration Testによっても解決できる。

11. 「最も局所的なテスト」が常に正しいわけでもない

レイヤー分離派は「必要な保証を得られる最も局所的なテストを選ぶ」と考える。しかしE2E中心派から見ると、局所的であること自体を重視しすぎではないかという反論がある。

システム障害は、Aは正しい・Bも正しい・Cも正しい・しかしA + B + Cは動かない、という形で起こる。

たとえば、Frontend OK・API OK・Domain OK・Repository OK、しかしFrontend→API→Domain→RepositoryはNG、というケース。

したがって、結合された状態そのものを検証することには独自の価値がある。

12. 「E2E 10,000件」という想定そのものへの反論

これまでの計算では、Unit 10,000件 → E2E 10,000件のように置き換える想定をしていた。しかし、強いE2E中心派は必ずしもそう主張しない。むしろ、Unit 10,000件 → E2E 300件にする可能性がある。

考え方としては、細かい組み合わせをすべてテストするのではなく、本当に重要な振る舞いだけ確認するというもの。たとえば、代表値・境界値・重要な組み合わせ・過去に壊れた条件・ビジネス上重要なフローだけをE2Eとして持つ。

この場合、Unit Testで網羅していたケース数そのものが本当に必要だったのかという品質戦略の議論になる。

13. テストケース数が多いこと自体は品質ではない

AIが大量のUnit Testを生成できるようになると、「10,000 Test PASS」という数字自体の価値はむしろ下がる可能性がある。

AIが実装を読んで、その実装と同じ前提のTestを生成すれば、間違った実装 + その間違いを正しいとするTestが大量にできる可能性もある。

したがって、テスト数・Coverage・PASS件数を品質そのものとみなすのは危険である。この観点では、人間が定義した外部仕様に近いAcceptance Testの価値はAI時代にむしろ高まる。

14. AI AgentとE2Eの相性

AI Agentにとって、実装→アプリ起動→操作→結果観測→修正、というループは非常に自然である。さらにAIなら、Screenshot・Console log・Network log・Server log・DB state・Traceなどをまとめて解析できる。

従来、E2E Failure→人間が30分デバッグ、だったものが、E2E Failure→AIが自動解析→修正、になる可能性がある。

このため、E2EはAI AgentのAcceptance Test / 完了条件としてかなり強い。

15. ただし「AIのAcceptance Test」と「回帰テスト戦略」は別

ここは今回の議論で特に重要だった。

「AIにとってE2Eが扱いやすい」ことと、「システム全体の回帰テストをE2E中心にすべき」ことは同じではない。

たとえばAIへ「商品にクーポンを適用でき、その価格で注文できること」をE2Eで完了条件として与える。AIはその内部で、Unit・Integration・E2Eを適切に作ってもよい。

つまり、E2Eを最上位の仕様・検収条件として重視することと、詳細ロジックの検証までE2Eへ移すことは分離できる。

16. AIが下げられるコストと、下げにくいコスト

AIが大きく下げられる可能性があるのは、Test作成・Test修正・Fixture生成・UI変更への追従・Failure解析・Test Case生成・リファクタ時のTest修正などの人的コスト。

一方で、AIでも直接消えにくいのは、CPU時間・RAM・Disk I/O・Network・Browser起動・DB初期化・Container起動・Test Environment・Resource contention・Runner・フィードバック待ち時間など。

つまり、AIによって「書く・直す」コストは大きく下がるが「動かす」物理コストは残るという違いがある。

17. AI時代は逆にテストレイヤー分けがしやすくなる

従来は、Unit Testを1,000件書くこと自体が人間には大きな負担だった。AIが、Unit 1,000件・Integration 300件・E2E 50件を生成・保守できるなら、テストを適切に分ける人的コストが下がる。

一方、実行時の差は残る。Unit 1,000件は数秒〜数十秒、E2E 1,000件は数十分〜数時間。

したがって、AIによってテスト作成コストが下がるほど、実行レイヤーを適切に選ぶ重要性が上がるという逆説も成り立つ。

18. 一方で、AIはE2Eの弱点も削る

E2E中心派からは逆に、AIならE2Eの作成・保守・失敗解析も安くなるという主張ができる。

従来E2Eが敬遠された大きな理由は、書くのが大変・壊れたとき直すのが大変・flaky原因調査が大変・Traceを見るのが大変といった人件費だった。そこがAIで大幅に下がるなら、少し多くCPUを使っても、外部仕様に近いテストを増やした方が合理的というケースもありうる。

この点は、E2E中心派のかなり強い主張である。

19. AIエージェント自体の料金はどう見るべきか

ここは、E2E中心派とレイヤー分離派で「まったく同じ」とまでは言い切れない。ただし、CI計算資源ほど単純な差ではない。

AIエージェント料金は概ね、入力トークン・出力トークン・推論時間・Tool Call回数・Browser操作回数・Test実行結果の読み取り量・ログ/Trace/Screenshot解析量・修正→再実行ループの回数、に影響される。

レイヤー分離派：Unit Testならコード変更→Unit Test実行→失敗メッセージ→修正、で済む。テストが高速なので、AI Agentも短いループを多数回回しやすい。一方、Unit/Integration/E2Eという複数レイヤーを理解し、どこにTestを書くか・Mockは必要か・Integrationにするかを判断する推論コストは増える可能性がある。

E2E中心派：AIにとっては、アプリ操作→結果を見る→直す、という単純なフィードバックモデルにできる。その意味では設計判断の推論負荷は減る可能性がある。ただし、Failure時にはScreenshot・Trace・Console・Network・Backend Log・DB stateなど大量の情報をAIへ入力する可能性がある。さらに、E2E 30秒→AI解析→修正→E2E 30秒、というループを何度も回せば、Agentの実行時間とTool利用も増える。

したがって、E2E中心だからAI Agent料金は必ず高いとも、Unit中心だからAI Agent料金は必ず安いとも言えない。

20. AI Agent料金で重要なのは「テスト種類」より「試行回数」

Agent料金については、最終的には、1回あたりのAgent処理量 × 修正ループ回数の影響が大きい。

ケースA：Unit Failure→原因が明確→1回で修正、なら非常に安い
ケースB：E2E Failure→Trace解析→原因候補A→修正→再実行→まだ失敗→原因候補B→修正、ならAgent料金も増える
ケースC：Unit TestがMockだらけ→複数箇所を修正→Testも大量修正→再設計、となれば、Unit中心でもAI利用量は増える

したがってAI Agent料金の本質的な決定要因は、テストレイヤーそのものというより、AIが正解に到達するまでに必要な観測・推論・修正の総量である。

21. AI Agent料金とCI料金は分けて考える

ここはかなり重要。AI Agent料金とCI Runner料金は別のコストである。

E2E中心化すると、Runner側では、Browser・DB・Backend・Container・Networkなどの実行コストが増えやすい。一方Agent側は、E2Eの方が外部仕様から判断しやすい・Failure解析情報は増える・実行待ちによってAgent Sessionが長くなる可能性がある、という両方向の影響がある。

そのため、

Total Cost
= AI Agent Cost
+ CI Compute Cost
+ Developer Cost
+ Infra Operation Cost

として考えるべきである。

22. AI Agent料金は両陣営の決定打にはなりにくい

現時点の議論では、AI Agent料金そのものは、E2E中心派が決定的に不利、あるいは、レイヤー分離派が決定的に不利、というほどの差にはなりにくい。なぜなら、両方ともAIを使うからである。

違いは主に、

E2E中心 → 実行結果・Trace・画面観測が多い
レイヤー分離 → Test設計・レイヤー判断・複数Test修正が多い

という形で現れる。最終的には、どちらの方式がAI Agentに少ない試行回数で正解へ到達させられるかの方が重要になる。

23. Selective Testingが重要になる可能性

大量のE2Eを持っていたとしても、毎回全部実行する必要はない。AIが変更差分と依存関係を理解できるなら、変更→影響範囲分析→必要なE2Eだけ選択、ということが可能になる。

たとえば価格ロジックの変更なら、Pricing・Cart・Checkout・Payment関連だけを実行する。CSS変更なら、対象画面・Visual Regressionだけ。

すると、E2E 10,000件存在していても、1変更あたり50件実行なら現実的になる可能性がある。

24. Selective Testingにも新しいリスクがある

ただし、実行しなかったテストに実は影響があった、という可能性が生まれる。

つまり、

Full Test → 高コストだが影響分析ミスがない
Selective Test → 高速だがTest Selectionの正しさに依存

というトレードオフになる。そのため現実には、PR→Selective、Merge→Core、Nightly→Full Regression、のような構造になりやすい。

25. CI実行頻度とテスト種類は別問題

仮にテスト資産の多くがE2Eだとしても、PR→関連E2E、Merge→Core E2E、Nightly→Full E2E、Release→Full Regression、とすれば、毎回全部を実行する必要はない。

したがって、E2E中心戦略と毎回全E2Eを実行するは同義ではない。

26. GitLab ServerとGitLab Runnerは別

セルフホストGitLabの議論では、この区別が重要だった。

GitLab Server ≠ GitLab Runner

GitLab Serverは、Repository・Pipeline管理・Job scheduling・API・PostgreSQL・Redisなどを担当する。実際に、npm test・pytest・Playwright・Docker buildなどを実行するのはRunnerである。

E2Eを大量実行した際、計算資源の壁になりやすいのはRunner側。

27. ローカルPC1台に置いた場合の構造

開発PC
├─ GitLab
├─ PostgreSQL
├─ Redis
├─ Docker
└─ Runner
    ├─ Job 1
    ├─ Job 2
    ├─ Job 3
    └─ ...

何並列できるかはGitLabというソフトウェアではなく、CPU・RAM・Disk I/O・DB・Networkによって決まる。

概念的には、

最大並列数 = min(CPU上限, RAM上限, Disk I/O上限, DB上限, Network上限)

と考えられる。

28. 1 Jobあたりのリソース試算

以下は説明用の仮定であり、実測値ではない。

リソース	仮の使用量
Browser	1GB
Application / API	0.5GB
DB	1GB
Redis / その他	0.5GB
合計	約3GB

64GB RAMなら単純計算では、64 ÷ 3 ≒ 21 Jobとなる。

ただし実際には、OS・GitLab・Runner・Docker・filesystem cache・CPU・DB I/O・Disk I/Oなどにも余裕が必要。仮に1 JobがCPUを2〜4コア程度消費するなら、32 core環境ではCPU側から8〜16並列程度で厳しくなる可能性もある。

したがって、64GBだから20並列できる、とは単純には言えない。

29. Runnerは技術的にはスケールアウトできる

GitLab Runnerは、GitLab → Runner 1/2/3/4… のように増やせる。つまり、1台→10台→100台と増やすことは可能。

したがって、セルフホストGitLabはスケールできないわけではない。正確には、スケールさせるための計算資源と運用基盤を自分で用意する必要があるということ。

30. 「自前Runner = 必ずKubernetes」ではない

100並列したいからといって、Kubernetesが必須なわけではない。たとえば、固定VM群・Bare Metal・Auto Scaling VM・Kubernetes・Cloud Runnerなど複数の方法がある。

動的に需要変動へ追従したいなら、Kubernetes・VM Autoscaling・Cloud Autoscalerなどが候補になる。

重要なのは、スケールさせるほど、単なる「GitLabをPCに入れる」という話から離れていくこと。

31. 自前Runnerを増やすとCI基盤運用になる

Runnerが増えれば、Server調達・OS管理・Runner更新・Docker管理・Storage・Cache・Monitoring・Backup・Network・Security Patch・障害対応・Capacity Planningなどが必要になる。

つまり、「GitLabをローカルに置く」という話から、CIプラットフォームを運営するという話に変わる。

32. ただし「自前Runnerは大変すぎる」と決めつけるのも違う

反対側からすると、GitLab.com + 数台〜数十台のRunner VM程度なら、必ずしも専任SREやKubernetesが必要なわけではない。Terraformなどで、VM作成→Runner登録→Image適用、を自動化できる。

固定負荷が多いなら、オンプレや専用RunnerがクラウドCIより安くなるケースもある。したがって、自前化は必ず損、という話でもない。

33. 専用の高性能マシン1台という選択肢

普通の開発者PCではなく、多数コアCPU・256GB RAM・高速NVMeなどを積んだCI専用ワークステーションを用意する方法もある。小規模〜中規模チームなら、それだけでかなりの並列数を処理できる可能性がある。数年運用するなら、クラウドRunnerよりTCOが低くなる場合もある。

つまり、ローカルPC1台だから非現実的、ではなく、どの程度の専用ハードウェアを想定するかで話は変わる。

34. クラウドCIの料金は「CPU時間」だけではない

クラウドCI料金は、CPUを借りる料金だけではない。同時に、Runnerの調達・可用性・スケール・アップデート・障害対応を自分たちで持たなくてよい料金でもある。

つまり自前化すると、クラウド利用料 → 設備費・電気代・保守・人件費・障害対応・Capacity Planning、へ変換される。

35. ただしクラウド費用より人件費の方が高い場合も多い

E2E中心派からの重要な反論。例えば、エンジニア10人・総人件費1,000万円/月・CI 20万円/月だとする。CIが倍になって40万円になっても、全体から見れば小さい。

もしE2E中心化によって、Mock設計が減る・Unit Test保守が減る・AI Agentが自律化しやすい・人間の確認工数が減る、などにより開発効率が数%上がるなら、CI費用増加は十分回収できる可能性がある。

したがって、CPUが高いからE2Eを減らす、だけでは経済合理性を判断できない。見るべきは、Total Cost of Ownershipである。

36. ただし「料金」と「待ち時間」は別

計算資源に金をかければ、並列数を増やせる。しかし逐次依存やEnvironment起動などにより、最低でも20分かかる部分があるなら、お金だけでは完全に消せない。

特にAI Agentが高速になるほど、実装30秒・Test 20分、という待ち時間が支配的になる。

したがって、CI料金が払えることと、フィードバック速度が十分であることは別問題。

37. E2Eの並列化には計算資源だけでは足りない

たとえば100 Jobが共有DBへアクセスすると、Job 1が user@example.com を作成、Job 37も同じメールで作成 → UNIQUE constraint violation、のような競合が起こる。

つまり、Runnerを100台用意しただけでは100並列できない。必要なのは、計算資源 + テスト独立性 + データ独立性 + 環境独立性である。

38. DB分離の選択肢

DB per Job：Job1→DB1、Job2→DB2、Job3→DB3。独立性は高い。ただし大量並列ではリソースが増える。

Shared DB + logical isolation：tenant_id・namespace・unique test dataで論理分離する。資源は軽いが、テスト設計が複雑になる。

Modern ephemeral approach：schema per worker・template clone・copy-on-write・snapshot・database branch・transaction snapshotなどを使えば、独立環境の作成コストをかなり下げられる場合もある。

したがって、100並列なら100個の重いDB Serverが必要、とは限らない。

39. E2EのFlakinessについて

E2Eは依存要素が多いため、構造的に不安定要因は増える。ただし、flakyになる原因がすべてE2Eそのものにあるわけではない。

たとえば、sleep(5000)・外部本番API依存・Shared state・不安定なFixture・Timezone依存・時刻依存など、テスト設計の問題も大きい。Playwrightのauto-waitなどを活用し、環境を制御できればかなり安定させられる。

したがって、E2Eだからflaky、という単純な議論は避けるべき。

40. 両陣営の強み

E2E中心派が強い論点

ユーザー価値を直接保証できる
内部実装変更に強い
Executable Specificationとして使える
AI AgentのAcceptance Testに向いている
Mockによる現実との乖離を避けられる
AIによって作成・修正・Failure解析コストが下がる
Selective Testingによって実行量を減らせる可能性がある

レイヤー分離派が強い論点

大量のロジックケースを高速に検証できる
境界値・組み合わせテストの経済性が高い
Failureを局所化しやすい
CIフィードバックが速い
少ない計算資源で回せる
大量並列やEnvironment分離を必要としにくい
Integration Testを使えばMock問題もかなり減らせる

41. 「保証の意味」と「保証の経済性」

今回の議論をかなり短く圧縮すると、次のように整理できる。

E2E中心派は「何を保証すべきか」という問いに強い。 ユーザーが実際に使えることを直接保証するから。

レイヤー分離派は「その保証をどう安く・速く得るか」という問いに強い。 同じ性質をより局所的に検証できるなら、その方が高速だから。

両方とも重要である。

42. 両者を統合したテスト戦略

最終的には、次の構造がかなり自然である。

                 外部仕様
                    │
                    ▼
           Acceptance E2E
        少数・重要・仕様に近い
                    │
         ┌──────────┴──────────┐
         ▼                     ▼
Integration / Component       Unit
実際の境界・連携              詳細ロジック
         │                     │
         └──────────┬──────────┘
                    ▼
                   実装

つまり、E2Eを最上位の仕様・Acceptanceとして重視する一方で、詳細な組み合わせや内部ロジックまで全部E2Eにはしないという形。

43. AI時代に変わること

AI時代には、E2Eの重要性が上がる可能性がある。理由は、AI Agentにゴールを与えやすい・仕様として理解しやすい・Failure解析をAIができる・Test作成/修正をAIへ任せられる、から。

しかし一方で、CPU・RAM・I/O・Browser・DB・Network・実行時間は残る。

したがって、「AI時代だから全部E2E」という結論ではなく、「AI時代だからこそE2Eを仕様・Acceptanceとしてより重視しつつ、詳細検証は最適なレイヤーへ分散させる」方が自然に見える。

44. 今後の設計判断で使える4つの問い

最終的に、テスト戦略を考えるときは次の順番で考えると整理しやすい。

何を保証したいのか？
その保証を得るために、どこまでシステムを通す必要があるのか？
そのテストをいつ、どの頻度で実行する必要があるのか？
その実行時間・計算資源・コストをCI基盤で許容できるか？

この順番が重要。悪い順序は、

AIにはE2Eが向いている
↓
全部E2Eにする
↓
遅い
↓
Runnerを増やす
↓
さらに重いCI基盤を作る

である。本来は、

必要な保証
↓
適切なテストレイヤー
↓
実行頻度
↓
必要なCI基盤

の順で設計する。

45. 最終的な結論

今回の議論を通して、最初の違和感はかなり具体化された。

「ほとんどをE2Eにすれば良い」という主張は、AI Agentとの相性やブラックボックステストの変更耐性という点では十分理解できる。一方で、それだけを理由に、Unitをほぼ捨てる・Integrationも薄くする・大量の詳細検証をE2Eへ寄せる、合理性までは導けない。

E2Eには、外部仕様に近い・実際の利用状態に近い・AI Agentが検証しやすい、という大きな価値がある。しかし同時に、実行時間・計算資源・環境分離・DB分離・並列性・Failure局所化・フィードバック速度、という物理的・構造的コストがある。

AIは前者の価値を高め、後者の一部を緩和できる。しかし後者そのものを消すわけではない。

したがって、現時点で最も筋が通る整理は、

E2EをAI AgentのAcceptance TestやExecutable Specificationとして重視する。一方で、ビジネスロジックの高密度な検証はUnit、DB・API・Message・Repositoryなどの境界はIntegration、システム全体を通さなければ得られない保証だけをE2Eへ配置する。そのうえでSelective Testingや段階的CI実行を利用し、必要なフィードバック速度を維持する。

というものになる。

そしてセルフホストGitLabについても、「GitLabを置けばE2E中心戦略の問題が解決する」わけではない。正確には、GitLab Runnerの計算資源を自分たちで管理する方式へ切り替えられるだけである。

それが有利かどうかは、負荷の安定性・必要並列数・チーム規模・CI料金・AI Agent料金・人件費・運用体制・必要なフィードバック時間、によって変わる。

最終的には、単にCIコストだけではなく、

Total Cost
= AI Agent Cost
+ CI Compute Cost
+ Developer Cost
+ Infra Operation Cost

で見る必要がある。

AI Agent料金については、E2E中心・レイヤー分離のどちらか一方が必ず高くなるわけではない。E2E中心ではTrace・Screenshot・ログ解析や実行待ちが増えやすい一方、AIが外部仕様から判断しやすく、少ない推論で修正できる可能性がある。レイヤー分離ではUnitやIntegrationが高速なため修正ループは短い一方、どのレイヤーにテストを置くか、Mockや境界をどう設計するかという判断が増える可能性がある。

したがってAI Agent料金で重要なのは、テストレイヤーそのものより、AIが正しい実装へ到達するまでに必要な観測・推論・修正の総量と考えるのが自然である。

最終的に今回の議論を一文で表すなら、

AI時代にはE2Eの価値は高まるが、E2Eの実行コストまで消えるわけではない。AI Agent料金も含めて、必要な保証をどのテストレイヤーで最も少ない総コストと待ち時間で得られるかを考え、その結果に合わせてCI基盤を設計することが重要である。

作成日: 2026-09-24 23:10

更新日: 2026-09-24 23:10