e2e - 自然言語の操作と明示的な検証を組み合わせるE2Eテスト基盤

従来のロケーターとアサーションを使うテストでは、操作手順もコードで明示する。e2eの提示例は、その操作部分をエージェントへ任せ、結果の検証をテストコードに残す構成と読める。これはREADMEの例に基づく編集上の整理であり、従来手法との実測比較ではない。

たとえば「ワークスペースをProプランへ変更する」という目標は、agent.actへ一つの文として渡される。一方、到達後の状態はscreenとexpectを使って記述できる。意図を具体的なUI操作へ変換する記述負担を減らす狙いが見えるが、操作目標を短く書けることと、テストが十分な状態を検証することは別の判断だ。

この分離を踏まえると、e2eの問題設定は、自然言語で表した目標を明示的な合否判定のある反復可能なテストへ接続することにある。どの操作を任せ、どの結果をコードで確認するかが、テスト設計上の主な選択になる。

もう一つの焦点は反復実行だ。同じ操作を毎回モデルに判断させる構成に対し、e2eは検証された操作を次回へ持ち越す仕組みを説明している。作者によれば、アプリが変わるまでは記録した操作をモデル呼び出しなしで再生する。また、エージェントステップを含まないテストにはモデルが不要だという。

編集上は、目標に向けて操作する段階と、確認済みの操作を繰り返す段階をつなぐ設計と捉えられる。これが機能すれば反復時のモデル判断を減らせる可能性がある。ただし、モデル呼び出し削減率、実行時間、成功率、フレーク率の測定値は提示されていない。

したがって、「再生する」という説明から高速化や安定化の程度までは導けない。仕組みの狙いを理解することと、自分のテストで効果を確認することを分けて評価したい。

2026年10月5日のGitHub Trending取得時点では、日次1位、日次1,430スター増、累計4,251スター、180フォークが記録されている。取得したリリース一覧には、10月4日公開の主パッケージe2e@0.17.0もある。これらは直近の注目を示す観測値だ。

技術的に読むべき根拠は、READMEのテスト例、パッケージの役割分担、提示されたリリースノートにある。注目度から再生の正確性やCIでの安定性を推定することはできない。リンク先の公式ドキュメントや実装は今回の資料に含まれておらず、内部の画面認識、操作選択、記録形式は確認できない。

また、主パッケージの0.17.0と、Webエンジンの0.12.0、モバイルエンジンの0.9.2は別のリリースだ。依存変更や修正内容を読む際も、どのパッケージの説明なのかを区別する必要がある。

READMEによれば、e2eパッケージはテストを記述するSDK、実行するランナー、初期化などを行うCLIを提供する。npx e2e initはWebまたはモバイルのエンジンとモデルプロバイダーを尋ね、設定とサンプルテストを書き出す。操作対象への接続と、エージェントに使うモデル接続を選ぶ構成だ。

Web側の@e2e-dev/webはPlaywright経由でChromium、Firefox、WebKitを操作する。モバイル側の@e2e-dev/mobileはagent-device経由でiOSシミュレーターとAndroidエミュレーターを操作する、とREADMEは説明している。同じフレームワークに両方のエンジンが用意されているが、Webとモバイルの機能が同一だと判断できる資料はない。

ここで把握できるのは、テスト記述、実行、対象環境への操作、モデルへの接続という役割の分担までだ。各エンジンが画面をどう認識し、次の操作をどう選ぶかという内部アルゴリズムは、提示資料から補えない。

READMEの例は、testからapp、agent、screenを受け取る。最初にapp.open('/settings/billing')で対象のパスを開き、agent.act('upgrade the workspace to the Pro plan')で操作目標を渡す。続いてagent.assertで請求プレビューに日割り金額が表示されることを自然言語で検証し、expect(screen.getByRole('status')).toContainText('Pro')で対象のテキストを検証する。

この順序から、appは対象を開く入口、agentは自然言語による操作と検証の入口、screenはロケーターによる対象指定の入口として読める。操作と二種類の検証が、一つの非同期テストの中に並ぶ。

ただし、agent.assertの判定手順、モデル依存性、ロケーターによる検証との保証の違いは説明されていない。例に両方が登場することは確認できても、同じ確実性で判定するとは扱えない。重要な結果をどの検証で担保するかは、この不明点を踏まえて決める必要がある。

作者の説明では、後続アサーションで検証されたエージェントステップの操作が記録される。次回はアプリが変わるまで、その操作をモデル呼び出しなしで再生する。操作を実行し、後続の検証で結果を確かめ、その操作を反復実行へ利用する、という流れが設計の中心だ。

ただし、どのアサーションがどの操作を検証したと見なされるのかは不明だ。記録の粒度や保存形式も示されていない。「アプリが変わるまで」という条件についても、何を観測して変更を検出するのか、再生が失敗した場合にどう処理するのかは確認できない。

この不足は再生を評価するうえで重要になる。後続の検証が十分な状態を確認しているか、認証状態や動的データが変わった実行でも同じ操作を使えるかは、導入先で確認すべき論点だ。提示資料だけでは、不十分な検証が記録へ与える影響や、再探索の挙動まで説明できない。

実行環境の接続も別パッケージに分かれる。READMEによれば、@e2e-dev/kernelはKernelのホスト型ブラウザーをWebエンジンへ、@e2e-dev/easはEAS Simulatorsのホスト型iOS・Android環境をモバイルエンジンへ接続する。@e2e-dev/githubはテスト結果をPRコメントへ投稿する。操作対象の実行環境と結果の出力先を、テスト基盤に組み合わせる構成だ。

モデル接続については、既存サブスクリプション、APIキー、ローカルモデルを利用できると作者は説明する。0.17.0のリリースノートでは、copilot()が初回にモデル一覧のsupported_endpointsを読み、Chat CompletionsとResponses APIを選択する。Responses API側には@ai-sdk/openaiを使うという。

また、@e2e-dev/decisionは範囲を限定した意味的な操作とアサーション向けのdecision-model executorを提供するとされる。ただし内部アルゴリズムは不明で、このパッケージの説明だけから操作選択の方式や精度を推定できない。接続先が列挙されていることと、内部のデータフローが明らかであることは区別して読む必要がある。

適用先として読み取りやすいのは、操作目標を自然言語で表しつつ、重要な結果をロケーターとアサーションで明示したいE2Eテストだ。操作部分だけをエージェントへ任せる構成は提示例と一致する。検証済み操作の再生を試験導入し、反復時のモデル利用を減らせるか調べたいチームにも検討余地がある。ただし効果は導入仮説の段階にある。

Playwrightとの関係は補完的だ。e2eのWebエンジンはPlaywrightを操作基盤として使い、その上へ自然言語の操作と検証済み操作の再生を組み合わせる。既存テストとの比較では、ブラウザー操作基盤よりも、操作手順を誰が決め、結果をどう検証するかに注目すると違いを捉えやすい。

READMEにはVite、Next.js、Expo、SwiftUIの独立したサンプルがある。ただしサンプルの存在だけで各構成の運用品質は判断できない。PRコメントへの結果集約にはGitHubレポーターを使えるが、具体的なCI設定は提示資料に含まれていない。

READMEは1.0に向けた開発中であり、APIと設定がマイナーリリース間でも変わり得ると明記する。長期運用で互換性維持を必須とする場合には、この状態が導入上の制約になる。

Webエンジン0.12.0ではplaywright-coreを厳密なバージョンで固定し、ブラウザー導入手順も変更している。CIではエンジン側のインストールコマンドを使う。アプリが@playwright/testも利用する場合は別のコピーを保持し、バージョンが一致するときだけブラウザーキャッシュを共有する、とリリースノートは説明する。Playwrightを基盤にする関係でも、依存管理とブラウザー導入は確認が必要だ。

モバイル0.9.2には、Androidでインストール済みパッケージ名を取得できない場合の処理改善と、iOSで近傍コントロールを覆われていると誤判定する問題の修正が記載されている。修正後の再現結果はなく、ホストOS別の対応範囲やWebとの機能差も確定できない。対象環境の列挙だけで運用可能範囲を決めるのは早い。

CLIは匿名利用データを送信する。作者は、そのデータにテスト内容、アプリ内容、認証情報を含めないと説明している。無効化にはnpx e2e telemetry disable、またはE2E_TELEMETRY_DISABLED=1を使える。

この説明の対象はCLIテレメトリーであり、モデルプロバイダーへ送られる情報の保証に広げることはできない。画面、DOM、機密情報のうち何がモデルへ送信されるかは、今回の資料では判断できない。操作記録の保存先や秘匿方法も不明だ。

ローカルモデルやホスト型の実行環境が選択肢としてあることだけでも、情報の扱いは確定しない。機密情報を含むアプリで評価する場合、モデルへの送信範囲、操作記録の保持、実行環境へのアクセス条件は別々の確認事項になる。提供される接続先の柔軟さと、情報管理の仕様が明らかであることを混同しない判断が必要だ。

提示資料には、速度、成功率、フレーク率、モデル呼び出し削減率の測定値や比較条件がない。再生の説明から、モデル判断を繰り返す回数が減る狙いは読み取れるが、総実行時間や運用費用がどれだけ変わるかは分からない。

導入評価では、認証状態、動的データ、外部サービスを含む自分たちの実行条件で、操作と検証が再現できるかを確かめたい。再生の無効化条件、失敗時の挙動、自然言語アサーションの判定も確認対象になる。これらは既知の欠陥として断定する話ではなく、資料から適合を判断できない範囲だ。

互換性、再生の監査可能性、実測フレーク率を必須とする本番CIには、現時点の説明だけでは導入根拠が足りない。一方、重要な結果を明示的に検証できるテストで限定的に試し、記述負担と反復実行への影響を調べる用途なら、設計上の仮説を具体的に評価しやすい。