開発者はすべてのE2Eテストを手動で作成すべきか、それとも自律型テストエージェントを使うべきか？
Rui Li
この問いのカギとなる言葉は「すべて」であり、そこに正直な答えがあります。
すべてのE2Eテストを手動で書くことは、実際には誰かが意識的に選んだことではありませんでした。それはデフォルトでした。ソフトウェアの歴史の大半において代替手段が存在せず、カバレッジは誰かが作成した場所にしか存在しなかったからです。自律型テストエージェントの登場は、単に選択肢を追加するだけではありません。「すべて」を意思決定の対象に変えます。そして、ほとんどの開発者にとって正しい答えはどちらの極端でもありません。手動で書く価値のある少数のテストと、それ以外をすべて担うエージェントという境界線です。
その境界線をどこに引くか、そしてその下のデフォルトをなぜ変えるべきかを説明します。
「すべてのテストを手動で」が実際にかかるコスト
手動によるフルカバレッジは厳格さのように聞こえますが、実際には予算であり、その予算には多くのチームが過小評価している3つの費目があります。
オーサリングコストは目に見えます。複数ステップのフローに対する徹底的なE2Eテストは実際のエンジニアリング時間を要し、ある程度の規模のプロダクトには数十のフローが存在します。メンテナンスコストはそれより大きく、永続的に発生します。UIの再編成、コンポーネントの名称変更、APIレスポンスの形式変更のたびに、先週まで正常だったテストが壊れ、誰かがその失敗を調査してプロダクトに問題がないことを確認します。機会コストは結果を左右するものです。テスト2と3に費やした時間は、プロダクトに費やされない時間であり、だからこそ手動で書かれたテストスイートは部分的なカバレッジで頭打ちになり、その後静かに遅れをとり続けるのです。
Claude CodeやCursorを使用する開発者にとって、AIコーディングセッションは実装の詳細を毎週刷新するため、3つのコストがすべて同時に膨らみます。人間のコーディング速度では持続可能だったテストスイートが、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つの問題が発見されます。レッスン完了時に進捗バーは更新されるが、アプリを再起動するまでストリークカウンターが更新されないという問題。これは3週間前に進捗モデルをリファクタリングしたセッションで生じた状態伝播のミスです。そして間隔反復キューが、レビューセッションを途中で中断すると、回答済みのカードは再表示するが未回答のカードは無音でドロップしてしまうという問題。まさにその機能が存在する目的とは正反対の動作です。どちらも振る舞いに関するものであり、ユーザーに直面するものであり、手動カバレッジでは決して到達できない領域にあります。なぜなら、誰もこれらのフローを事前に予測しないからです。
発見事項はClaude Codeのターミナルに届き、修正はその日のうちに行われ、開発者の今後のテスト予算は安定します。4つのテストは手動でメンテナンスします。それらには価値があるからです。そして、エージェントが各セッションの後にその他すべてを再探索します。
まとめ
開発者はすべてのE2Eテストを手動で書くべきでしょうか？いいえ。手動作成が時代遅れだからではなく、「すべて」は戦略ではなかったからです。それは代替手段がなかったということに過ぎません。
今や代替手段があります。永続的な答えはラインを引くことです。ステークスの高さ、フローの安定性、ドキュメントとしての価値がすべて揃った少数のテストは手動で作成し、残りのサーフェス、常にカバーされずにいた部分は、コードが実際に書かれる速度で自律エージェントに任せましょう。
今日、TestSpriteの無料プランで独自のラインを引きましょう。クレジットカード不要です。