E2EテストはすべてデベロッパーがHand codeすべきか、それとも自律型テストエージェントを使うべきか？
Rui Li
その質問におけるキーワードは「すべて」であり、正直な答えもそこにあります。
すべてのE2EテストをE2Eテストを手動で書くことは、誰かが意識的に選んだ選択肢ではありませんでした。それはデフォルトでした。ソフトウェアの歴史のほとんどにおいて、代替手段が存在しなかったからです。カバレッジは、誰かが書いた箇所にしか存在しませんでした。自律テストエージェントの登場は、単に選択肢を増やすものではありません。それは「すべて」を意思決定の対象に変えます。そして、ほとんどの開発者にとって正しい決断は、どちらかの極端ではありません。一本の線引きです。手動で書く価値のある少数のテストと、それ以外のすべてを担うエージェントという線引きです。
その線引きの方法と、その背後にあるデフォルトを転換すべき理由を解説します。
「すべてのテストを手動で書く」ことの本当のコスト
手動による完全なカバレッジは、一見すると厳格さの証のように見えます。しかし実際にはそれはコストの問題であり、ほとんどのチームが過小評価している3つの費目があります。
作成コストは目に見えます。複数ステップのフローを網羅するE2Eテストには相応のエンジニアリング工数がかかり、ある程度の規模のプロダクトには数十ものフローが存在します。メンテナンスコストはさらに大きく、永続的に発生します。UIの再編成、コンポーネントのリネーム、APIレスポンスの変更のたびに、先週まで正しかったテストが壊れ、調査した結果プロダクト自体には問題がなかったと判明するケースが繰り返されます。そして結果を左右するのが機会コストです。テストの作成・メンテナンスに費やす時間は、プロダクト開発に使えない時間です。これが、手動で書いたテストスイートが部分的なカバレッジで頭打ちになり、やがて静かに取り残されていく理由です。
Claude CodeやCursorを使用している開発者にとって、この3つのコストはいずれも同時に膨らみます。AIによるコーディングセッションは実装の詳細を毎週のように変えるからです。人間のコーディング速度では維持できていたテストスイートが、AIのコーディング速度ではトレッドミルのようになってしまいます。
自律エージェントが変えるもの
自律テストエージェントは、テストの作成プロセスを最適化するのではなく、作成という工程そのものを不要にします。
TestSpriteの探索エージェントは、動作中のアプリケーションを訪問し、実際のユーザーのようにナビゲートします。プロダクトを使いながらフローを発見し、現実的な入力値でフォームを入力し、複数ステップのジャーニーを通じてセッション状態を維持します。テストシナリオは探索の「出力」であり、誰かが事前に書く「入力」ではありません。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
メンテナンスの性質も変わります。カバレッジが構造ではなく振る舞いに紐付けられているため、名前が変わっても機能しているコンポーネントは何も壊しません。また、実際に障害を引き起こすドリフトはAuto-Heal Rerunが対処し、振る舞いが維持されている場合は自動適応し、プロダクトレベルの問題がある場合はそれを検出して報告します。Backend Testing 2.0は同じアプローチをAPIに拡張し、アサーションを行う前に実際のレスポンスを観察することで、推測ではなくAPIの実際の動作を記述するアサーションを生成します。
ワークフローのコストはほぼゼロです。CursorまたはClaude Code内から一度指示を出すだけで、結果が同じウィンドウに返ってきて、検出された問題は同じセッション内でコーディングエージェントが修正できる形式にフォーマットされています。
それでも手動で書く価値があるテスト
この線引きが存在するのは、少数のテストが確かに手動作成への投資に値するからです。クラフトへの情緒的なこだわりではなく、その基準を明確にしておく価値があります。
テストが手動作成に値するのは、次の3つすべてが成立する場合です。ステークスが十分に高く、正確で決定論的なアサーションが重要であること。フローが十分に安定しており、メンテナンスが稀であること。そして、そのテストが誰かに必要なドキュメントとして機能すること、つまりシステムが何をしなければならないかを示す実行可能な仕様であることです。
正確な請求金額を伴う決済フローはこの基準を満たします。厳密なフォーマットを要する法令遵守のエクスポートも満たします。コア認証シーケンスも多くの場合そうです。これらは通常、数百本のスイートではなく、ほんの一握りのフローです。それらを手動作成の精度で維持することは、かけた時間に十分見合います。
3つの基準のいずれか一つでも満たさないものは、つまりプロダクトのほとんどは、線の反対側に属します。
デフォルトの転換：エージェントをベースラインに、手動作成を例外に
従来のメンタルモデルは、手動作成のカバレッジを基盤とし、必要に応じてツールで補完するというものでした。現在のソフトウェア開発の実態に即したモデルはその逆です。エージェントの探索がデフォルトで全体をカバーするベースラインとなり、手動作成のテストは、精度が価値を生む箇所に置かれる意図的な例外です。
この逆転が重要なのは、2つのモデルの間にあるギャップに何が潜んでいるかによります。実際にユーザーに届く障害は、誰かが手動で書こうと選んだフローにあることはほとんどありません。それらは継ぎ目にあります。昨日のセッションで追加されたまだテストのない機能、共有状態の変更によって壊れたdiffから2画面離れたフロー、誰のメンタルモデルにも含まれていなかったエッジケース。探索によるベースラインは、これらを事前に予測することに依存しないため、こうした問題を捉えることができます。
旧来のデフォルトでは、これらのギャップは恒久的なものでした。閉じるには、誰も時間を割けないテストを書く必要があったからです。新しいデフォルトでは、初日からカバーされており、手動作成のコストは、常にその意義があった少数のテストへと絞り込まれます。
シナリオ：実際のプロダクトで線を引く
あるソロ開発者が、Claude Codeで構築した語学学習アプリを運営しています。レッスン、間隔反復レビュー、ストリーク追跡、プレミアムサブスクリプションを備えています。これまでのカバレッジ：サブスクリプション購入周りに手動で書いた4本のテスト。金銭が絡むため慎重に作成されました。それ以外は時間がなかったため何もありません。
彼らはTestSpriteを接続し、その線引きをそのまま維持しました。4本のサブスクリプションテストは手動作成・精密・メンテナンスに値する状態で残します。エージェントが初回実行からそれ以外の全体をカバーします。
その初回実行で、誰も手動テストを書こうとは思わなかった2つの問題が発見されました。1つ目は、レッスンを完了すると進捗バーは更新されるものの、アプリを再起動するまでストリークカウンターが更新されないという問題で、3週間前に進捗モデルを見直したセッションで生じた状態伝播のミスでした。2つ目は、間隔反復キューにおいて、レビューセッションを途中で中断すると、すでに回答済みのカードは再表示されるものの、未回答のカードが無言で消えてしまうという問題で、この機能が存在する目的と真逆の挙動でした。どちらも振る舞いに関わる問題であり、ユーザーに影響するものです。そして、誰もこのフローを事前に予測しないため、手動作成のカバレッジでは絶対に到達できない領域に正確に存在していました。
検出結果はClaude Codeのターミナルに届き、修正は同日中に完了しました。そして開発者の今後のテストコストは安定しています。手動でメンテナンスする4本のテストはその価値があるから続ける。そして、エージェントがすべてのセッション後にそれ以外のすべてを再探索します。
まとめ
開発者はすべてのE2EテストをE2Eテストを手動で書くべきでしょうか？いいえ。手動作成が時代遅れだからではなく、「すべて」は最初からストラテジーではなかったからです。それは代替手段がなかったことの表れでした。
今、代替手段があります。永続的な答えは線引きです。高いステークス、安定したフロー、ドキュメントとしての価値がすべて重なる少数のテストは手動で書き、プロダクトの残りの部分、常にカバーされないままだった部分は、コードが実際に書かれるスピードで自律エージェントに任せる。それが答えです。
今日、TestSpriteの無料プランで自分だけの線引きを始めましょう。クレジットカード不要です。