自分が書いていないコードをレビューすることの問題

AIコーディングエージェントは、動作する機能を数分で作り出せます。ボトルネックは移動しました — 制約はもはやコードを書く速さではなく、そのコードが期待通りに動くと誰がどれだけ自信を持って言えるかです。大きな差分を注意深く読むことは、それを生成することよりも時間がかかります。

型チェックとユニットテストは、コードが書かれた通りに動くことを確認します。それらは実際にアプリケーションを開くことがないため、デプロイされたアプリケーションがまだ動いているかどうかを教えてはくれません。そのギャップこそが、AI生成のリグレッションが実際に潜む場所です。

3

検証ループにおけるコマンド数：作成、実行、修正

3つのコマンドで完結するループ

オープンソースのTestSprite CLIをインストールします — 無料、Apache-2.0、Node 20.19+、22.13+、または24+：

npm install -g @testsprite/testsprite-cli
testsprite setup

そしてループです。保証したい振る舞いを記述し、実際のブラウザに対して実行し、終了コードから結果を読み取ります。

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

重要なのはステップ2のバンドルです。失敗したステップ、その前後のステップ、スクリーンショット、DOMスナップショット、テストのソース、根本原因の仮説、そして推奨される修正対象が含まれており、これらはすべて単一のスナップショットIDを共有しています。CLIは異なる2つの実行結果からデータを組み合わせることを拒否するため、エージェントがアプリケーションの異なる2つの状態から組み立てられたコンテキストで推論することは決してありません。

恒久的なスイートが大きなコンテキストウィンドウに勝る理由

合格したテストはすべて蓄積されます。次にエージェントがコードベースに触れるとき、それが現在の会話のどこかに残っているかどうかに関わらず、その要件は引き続きチェックされます。

これが外部検証を支持する構造的な論拠です。コンテキストウィンドウが保持しているのは、エージェントが今まさに考えていることだけです。テストスイートはプロジェクトがこれまで正しく実装してきたすべての要件を保持し、セッションをまたぎ、エージェントをまたぎ、特定のエッジケースがなぜ重要だったのか誰も覚えていない数か月後も、それらを保持し続けます。

まだカバーされていない

testsprite test create — 新しい振る舞いを平易な言葉で記述し、実行します。その要件は恒久的なものになります。

すでにカバーされている

testsprite test rerun — 既存のテストを再実行し、これまで動いていたものが密かに壊れていないか確認します。

何かが失敗した

testsprite test failure get — 1つのバンドル、1つのスナップショット、1つの根本原因の仮説。修正して再実行します。

エージェント自身にこれをやらせるための設定

Webページとコーディングエージェントの間でコマンドを中継する必要はないはずです。1つのセットアップコマンドで、エージェントが実際に消費できる形でこのループを説明するスキルファイルをリポジトリにインストールできます。

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

サポートされているハーネスはclaude、codex、cursor、cline、antigravity、kiro、windsurf、copilotです。インストールは完全にローカルで行われます。その後、エージェントはセッションのたびに指示されることなく、テストの作成・実行・トリアージの方法を理解した状態になります。

環境要因で失敗するコマンドにターンを費やす前に、環境を確認してください。

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

最初に何を検証すべきか

すべてがエンドツーエンドテストに値するわけではありません。AIエージェントの下で急速に変化するコードベースでは、最も価値の高いカバレッジは絞り込まれています。

  1. 収益を生むフロー。サインアップ、チェックアウト、請求。ここでのリグレッションは即座にお金を失わせ、しばしばユニットテストでは見えません。

  2. 認証に関わるすべて。セッション処理、ログイン後のリダイレクト、権限の境界は、一見もっともらしいリファクタリングが最も大きな被害をもたらす場所です。

  3. フォームとバリデーション。記述コストは低いのに、コンポーネントライブラリがアップグレードされたりフィールド名が変更されたりすると不釣り合いに壊れやすい部分です。

  4. 直近に出荷した3つのバグ。修正の後に書かれたリグレッションテストは、どんなスイートにおいても最も投資対効果の高い単一のテストです。

最初のセットを提案してほしい場合は、探索によって下書きを作成できます。提案はレビュー用にステージングされ、承認するまでディスクには何も書き込まれません。

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

チェックを必須にする

誰かが覚えている時にだけ実行される検証ステップは、検証とは言えません。CIに組み込みましょう。

testsprite ci init github

これはTestSprite/testsprite-action@v1を使った.github/workflows/testsprite.ymlをスキャフォールドします。このアクションは失敗ごとに1つのエラーをPRのチェックタブに注釈として付け、結果テーブルをジョブサマリーに追加し、JUnitレポートをアップロードし — 重要な点として — 部分的な実行をグリーンとして報告するのではなく、ジョブを失敗させます。

これはワークフローが実行を駆動する経路です。TestSpriteはGitHub Appとしてもインストールでき、パイプラインがすでに生成しているデプロイイベントをリッスンして結果をプルリクエストにコメントとして返すこともできます。この場合、ワークフローファイルもリポジトリの変更もまったく必要ありません。

それ以外のCIシステムでは、CLIが必要とするのは環境変数内のAPIキーだけです。

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

分岐判断に使う価値のある終了コード

終了コード意味正しい対応
0すべてのテストが合格マージする
1テストが失敗したtest failure get、修正、test rerun
3認証エラーキーが不足または無効 — 停止し、リトライしない
5検証エラー不正な形式のプランファイル — test lintを実行
7タイムアウトまたは非対応再実行して再接続するか、--timeoutを上げる
11レート制限リトライ可能 — バックオフする
12クレジット不足リトライ不可 — 人による対応が必要
14クライアントが古すぎるCLIをアップグレードする

コード129、130、143は、テストが失敗したのではなく、プロセスがシグナルによって中断されたことを意味します（128にシグナル番号を加えたもの）。実行を「壊れている」と報告する前に、この違いを見分ける価値があります。

よくある質問

これはユニットテストの代替になりますか？

いいえ、そうあるべきでもありません。ユニットテストは最も低コストなチェックであり、エージェントは常時実行すべきです。エンドツーエンド検証は別の問いに答えるものです — デプロイされたアプリケーションが動くかどうか — これはユニットテストが構造的に答えられない問いです。

エージェントはブラウザ自動化コードを書く必要がありますか？

いいえ。テストはアクションとアサーションのステップを持つ平易な言葉のプランファイルです。インストール済みバージョンに固定されたスキーマ正しいひな形を得るにはtestsprite test create --plan-templateを実行してください。

クレジットを消費せずにコマンドを試せますか？

はい。--dry-runは用意されたデータでコードパス全体をオフラインで実行し、test scaffoldとtest lintはネットワークにも認証情報にも一切触れません。

CLIはオープンソースですか？

はい — Apache-2.0で、GitHub上にあり、npmから無料でインストールできます。テストの実行はクラウドで行われ、ワークスペースのクレジットを消費します。

失敗が本物のバグなのか不安定なテストなのかをどう判別しますか？

失敗バンドルには、単なる赤い印ではなく、根本原因の仮説と推奨される修正対象が含まれています。直接その問いに決着をつけたい場合は、testsprite test flakyが自動修復をオフにした状態でテストを複数回再生し、安定性スコアを報告します。

どのコーディングエージェントがサポートされていますか？

Claude Code、Codex、Cursor、Cline、Antigravity、Kiro、Windsurf、Copilotが、testsprite agent install <agent>またはセットアップ時の--agentフラグを通じてサポートされています。

// The verdict

生成は速く、検証は外部で。

AIによるコード生成の速さは、独立した何かがその結果を確認して初めて意味を持ちます。恒久的なテストスイートこそがその独立した存在です — コンテキストウィンドウを超えて生き残り、差分レビューでは見逃すリグレッションを捕まえ、赤い実行結果を謎ではなく具体的な修正対象へと変えます。CLIを1行でインストールし、docs.testsprite.comのリファレンスを読み、GitHub上のオープンソースCLIにスターを付けてください。

無料で始める → 通話予約