はじめに

E2Eテストは、ユーザー体験を直接確認できる強力な手段です。
しかし「E2Eさえ回しておけば品質は担保できる」という考えは危険です。

さらに近年は「AIが進歩すればE2Eの修正や生成も自動化できるから大丈夫」という意見も耳にします。
この記事では、E2E偏重が招く課題とAIへの過剰な期待（AI幻想）を整理し、最後にユニット／インテグレーション＋AIの実務的な活用例を提示します。

E2E偏重が招く課題

大規模化するとパイプラインが数十分〜数時間に膨張し、リリース速度を阻害します。
フィードバックが遅れることで、開発者が変更の影響をすぐに把握できず、小さな修正でも手戻りコストが大きくなります。

UIや環境依存でflaky（気まぐれに落ちるテスト）が発生します。
失敗の原因がアプリ側かテスト側かの切り分けに時間を浪費し、チームの信頼性と生産性を下げます。

UI変更に敏感で、ボタン名やクラス名が変わるだけで多数のテストが壊れます。
その結果、「テストを直す作業」がプロジェクト全体のボトルネックになりやすいです。

本来ユニットやインテグレーションで検知すべき不具合までE2Eに押し込んでしまうと、テスト戦略が曖昧になります。
失敗しても原因が多岐に渡るため、責任の所在が不明確になり属人化が進みます。

「E2Eが通っている＝品質が担保されている」と誤解しやすい点も危険です。
実際には境界条件や例外系が網羅されていなくても、緑色の結果画面を見て安心してしまい、重大な欠陥を見逃すリスクがあります。

「AIが自動でテストを書き直してくれる」
「AIが仕様変更を検知して修正してくれる」

これらは魅力的に聞こえますが、現実的には幻想に近いものです。

AIに依存すると、むしろE2E偏重を加速させる危険があります。

E2E偏重の危険性は、AIが進歩しても普遍です。
幻想に頼るのではなく、戦略的にテストレイヤーを組み合わせることが重要です。