独立したエンドツーエンドテストで AI 生成コードをテストする方法
Claude Code、Cursor、Copilot、Codex が生成したコードをテストする方法: エージェント自身のテストがバグを見逃す理由と、独立したエンドツーエンドテストがそれを捉える方法。
読了 10 分更新日: 2026年11月6日執筆: Ait Nohaila (事業開発担当)
AI が生成したコードをテストするには、動いているアプリケーションを外側からテストします: 人が所有する重要なワークフローのエンドツーエンドテストを持ち、エージェントが開くすべてのプルリクエストで実行し、失敗がマージをブロックするようにします。
AI が生成したコードをテストするとはどういうことか
Definition
AI が生成したコードをテストするとは、AI コーディングエージェントが変更した後もアプリケーションがユーザーの必要とすることをまだ行えると証明することです。誰がその行を書いたかはユーザーには関係ありません。重要なのは、サインインがまだ動くか、合計がまだ正しいか、ボタンがまだそこにあるかです。
コーディングエージェントは今や、行を補完するよりずっと多くのことをします。Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Devin は、タスクを受け取り、多くのファイルを変更し、コマンドを実行し、プルリクエストを開けます。さらに進んでバイブコーディングを実践するチームもあります: 欲しいものを説明し、返ってきたものを受け入れ、コードはほとんど読みません。
タスク
人が書く
エージェントがコードを変更する
多くのファイルを数分で
エージェント自身のテストは合格
エージェントと同じ理解を共有している
独立したエンドツーエンドテスト
ユーザーが見るものはまだ正しいか?
人がマージする
緑の実行、レビュー済みの変更
エージェント自身のテストでは足りない理由
最初に思いつくのは、エージェントにテストも書かせることです。ぜひそうしてください: ユニットテストは本当の間違いを捕まえますし、エージェントはそれを素早く書きます。しかし、コードを書いたエージェントが書くテストは、そのエージェントのタスクの理解を共有しています。エージェントが要件を読み違えていれば、コードとテストは互いに一致し、どちらも間違っています。
タスクには、100 ドルを超える注文は 10% 割引と書かれています。エージェントは 100 ドルちょうどから割引を適用します。そしてちょうど 100 ドルの注文に割引を期待するユニットテストを書きます。テストは合格し、カバレッジは良さそうに見え、ルールは間違っています。チームより先に顧客がそれを見つけます。
コードレベルのテストには、要件の読み違え以外にも盲点があります。
| 盲点 | 見逃すもの |
|---|---|
| モック | データベース、ネットワーク、ブラウザーを代役に置き換えたテストは、それらが一緒に壊れる所を決して見ません。 |
| 画面 | ユニットテストは、新しいスタイルに隠されたボタン、途中で切れたラベル、ウィンドウの後ろに開くダイアログを決して見ません。 |
| 動機 | 失敗しているビルドを緑にするよう求められたエージェントは、コードではなくテストを変えるかもしれません。 |
| 影響範囲 | 1 つの関数を直すエージェントが、他の 3 つの画面が頼っているヘルパーまで書き換えるかもしれません。 |
レビュアーが読むもの
12 個のファイルが変更
合計$49.00
自己修復型のエンドツーエンドテストで解決するのか?
エンドツーエンドテストは昔からの答えです。エンドツーエンドテストは、ユーザーがするように実際のアプリケーションをインターフェイスから操作し、何が起こるかを検証します。ほとんどのチームは Playwright、Cypress、Selenium でそれをコードとして書きます: 要素ごとにセレクターを、クリックごとに 1 行のコードを書きます。
エージェントはそのコードを上手に書き、ツールも今ではそれを助けます。
| ツール | そのツール自身のドキュメントによる説明 |
|---|---|
| Playwright test agents | Playwright にはテストエージェントが付属しています: プランナー、ジェネレーター、そして失敗するテストを再生してページを調べ、合格するまでテストを修正するか、機能が壊れていると判断したときはスキップ扱いにするヒーラーです。 |
| Cypress cy.prompt | Cypress の cy.prompt は、平易な英語で書かれた手順を Cypress のコマンドに変え、セレクターやテキストが実行の間に変わると手順を修復します。 |
| Playwright MCP | Playwright MCP を使うと、エージェントはページのアクセシビリティスナップショットを通してブラウザーを操作できます。 |
壊れたエンドツーエンドテストのほとんどはバグではなくセレクターの名前の変更なので、修復は役に立ちます。リスクは 1 つのエージェントがすべてを行うときに現れます: 機能を書き、テストを書き、テストが失敗すればそれを修復します。それぞれの修復は単独では妥当です。しかし合わさると、テストをユーザーが必要とするものから、コードがたまたま行うものへと動かしてしまいます。
修復 1
単独では妥当
修復 2
単独では妥当
修復 3
単独では妥当
エンドツーエンドテストツール自体を比較するには、比較調査を参照してください。
AI が生成したコードをエンドツーエンドでテストするには
6 つの習慣が、エンドツーエンドテストを、エージェントが言い逃れできないガードレールに変えます。どれも特定のツールを必要としません。
- 1
決して壊れてはならない導線を書き出す
ユーザーにとって欠かせない 5 から 10 のワークフローを挙げます: サインアップ、サインイン、検索、カートへの追加、支払い、レポートのエクスポートなど。それぞれを、新しいテスターに説明するように、期待する結果付きで書きます。その一覧が仕様であり、エージェントではなく自分のものです。
- 2
エージェントがコードを書く前にテストを作る
新しい導線なら、まずデザインか手順からそのエンドツーエンドテストを作ります。そうすればエージェントは、自分で選んでいない目標に向かって作業します。機能が動くまでテストは失敗します: エージェントに適用したテスト駆動開発です。
- 3
ユーザーが見るものをチェックする
画面を検証します: ユーザーが読む言葉、要素の見た目、物の配置です。内部 ID、クラス名、コードだけが知っている状態のチェックは避けてください: まさにそれらこそエージェントが自由に変えるものだからです。画面に固定されたテストは、その下のコードの書き換えを生き延びます。
- 4
テストをエージェントの手の届かない所に置く
テストはコードの隣に保管しますが、テストへのすべての変更には人のレビューを必須にします。GitHub では、テストフォルダーの CODEOWNERS エントリと、マージ前のコードオーナーの承認の必須化が、まさにそれを実現します。エージェントはテストを実行し、変更を提案してかまいません。その変更を単独でマージすることは決してありません。
- 5
すべてのプルリクエストで実行する
エージェントが開くすべてのプルリクエストで、実際のアプリケーションが表示されるマシン上でエンドツーエンドのリグレッションテストを実行し、失敗がマージをブロックするようにします。警告するだけの結果は、すぐに無視されるようになります。固定した画面サイズから既知の開始状態まで、実行を毎回合格させるものはテストを実行するにあります。
- 6
失敗をエージェントにも自分にも読めるようにする
失敗したテストは、何が、どこで失敗し、画面が期待とどう違うかを画像付きで伝えるべきです。エージェントはそれを使って修正を提案します。自分はそれを使って、変更がバグなのか意図したものなのかを判断します。
すること
- ユーザーが頼る導線をエンドツーエンドでテストする
- 期待する結果をユーザーの言葉で書く
- エージェントにテストを実行させ、結果を読ませる
- テストが期待する内容へのすべての変更をレビューする
避けること
- コードを書いたエージェントだけがそのテストを書くこと
- クラス名、ID、内部状態のチェック
- 何が変わったかを読まずに修復済みのテストを受け入れること
- マージをブロックしない赤のエンドツーエンド実行
人間が関わり続ける場所
| 決定 | 決める人 |
|---|---|
| アプリケーションが何をするべきか | 人: 導線とその期待する結果 |
| コードがそれをどう実現するか | エージェント、人がレビュー |
| テストの実行と結果の確認 | エージェントとパイプライン、すべてのプルリクエストで |
| テストが期待する内容の変更 | 人、差分を見てから |
| マージ | 人、緑のエンドツーエンド実行を目の前にして |
AI コードレビューツールは 2 行目を助けます: 差分を読み、危険なコードを指摘します。それでも見ているのはコードであって、動いているアプリケーションではありません。エンドツーエンドの実行は、製品そのものを見る唯一のチェックです。
GUI Test Studio による AI コーディングエージェントのためのエンドツーエンドテスト
GUI Test Studio は、この役割分担のために作られました。人がテストを記録または説明し、エージェントがそれを実行して判定を読み、パイプラインがすべてのビルドで実行し、テストが期待する内容の変更は人を待ちます。
コードに依存しないテスト
実際のアプリケーションをクリックと入力で操作しながら、GUI Test Runner-Recorder でワークフローを一度記録するか、Claude、ChatGPT、または自分のコンピューター上のローカル AI モデル (当社が提供するものかお持ちのもの) にプロンプトで説明します。どちらにしても、テストは画面をチェックします。ビジュアルアサーションは要素の画像を比較し、テキストアサーションはその言葉を読み、レイアウトアサーションは要素の配置を検証します。
- 書くべきセレクターも、エージェントが書き換えるテストコードもありません。GTS Engine + AI は、各要素をアプリケーションがそれについて伝えること、つまりアクセシビリティ情報から見つけ、何も伝えないときは見た目から見つけます。クラス名の変更やコンポーネントの書き直しでテストが壊れることはありません。アシスタントがテストを作成するときは、追加するすべてのアサーションがその場で試され、今の画面で合格できないものは拒否されます。
エージェントが実行して判定を読む
GUI Test Studio には MCP コネクターが付属しているので、コードを書くアシスタントがテストを実行することもできます。Claude Code、Claude Desktop、Codex 付きの ChatGPT、VS Code の Copilot Chat にはワンクリックで接続でき、MCP コネクターを受け付ける他のどのアシスタントでも使えます。
| エージェントの依頼 | 起こること |
|---|---|
| run_test | テストはコンピューターの画面上で実行されます。エージェントは PASSED か、どのステップがなぜ失敗したかを受け取ります。 |
| describe_test | エージェントはテストの内容を受け取ります: 番号付きの順番どおりのステップと、シナリオです。 |
| edit_test | エージェントは、アサーションの時間を延ばす、期待するテキストを変えるといった変更を提案します。まず変更内容を見せ、確認するまで何も書き込みません。 |
Run the Checkout test and tell me what failed.gtr-cli ですべてのプルリクエストで
- gtr-cli は同じテストをパイプラインから Windows のビルドマシン上で実行し、パイプラインが期待する形で答えます。終了コードがビルドを失敗させ、JUnit ファイルがテストタブを埋め、JSON ファイルはスクリプトやエージェント向けに用意され、Markdown の要約はプルリクエストにそのまま使えます。gtr-cli からの実行がテストファイルを変更することは決してありません。
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--json results\run.json --summary results\summary.md --artifacts results\artifacts ^
--jira on-failure--jira on-failure を付けると、不合格のテストは再現手順と期待画像・実際の画像の付いた Jira の課題になり、同じ失敗が再び見つかると重複を作る代わりにコメントが追加されます。同じコマンドは GitHub Actions、GitLab、Azure DevOps、Jenkins、TeamCity で使えます: パイプラインでテストを実行すると、TeamCity の設定手順についてはすべてのビルドでエンドツーエンドテストを実行するを参照してください。
もう一度の確認と、人の最終判断
- すべての実行は、アサーションごとに要素が見つかったか、記録と一致するかを伝える信頼度レポートで終わります。アサーションがピクセルの違いで不合格になったとき、AI スマート分析がもう一度確認できます: 無害な描画のノイズは無視しつつ、変わった言葉、消えたバッジ、灰色になったボタンのような本当のリグレッションは捕まえます。オンにすると、その回答がそのアサーションの最終判定になり、何が変わったかをわかりやすい言葉で伝えます。自分の OpenAI または Anthropic のキーでクラウド上で、または自分のコンピューター上のローカル AI モデルで動きます: 当社が提供するものか、お持ちのものです。
アプリケーションを意図的に変更したときは、人がレポートで新しい見た目を採用して保存すれば、テストはそれ以降それを期待します。レポートの読み方は信頼度レポートを読むにあります。
このガイドはテストの実践面です。プロンプトからエージェントが直す Jira のバグまで、AI エージェントによる開発のサイクル全体については、AI エージェントとの開発 (ADLC)をお読みください。
要点
- 1AI が生成したコードは外側から、ユーザーがアプリケーションを使うようにテストします。
- 2エージェント自身のテストは、エージェントと同じ盲点を持ちます: タスクを読み違えていれば、コードとテストは一致し、どちらも間違っています。
- 3重要な導線の独立したエンドツーエンドテストを、人が所有して持ち、失敗がマージをブロックするようにします。
- 4エージェントは、テストが要素を見つける方法を変えてもかまいません。テストが何を期待するかを変えるのは、人だけです。
- 5失敗を画像付きで読みやすくし、エージェントが修正を提案し、人が決めるようにします。
よくある質問
AI が書いたコードはどうテストしますか?
ユーザーがアプリケーションを使うように、外側からテストします。人が所有する重要なワークフローのエンドツーエンドテストを持ち、エージェントが開くすべてのプルリクエストで実行し、失敗がマージをブロックするようにします。エージェントが書くユニットテストは役に立ちますが、エージェントのタスクの理解を共有しています。
AI が生成したコードは、テストの仕方を変えるべきですか?
アサーションは同じですが、規律がより厳しくなります。重要な導線の同じエンドツーエンドテストが当てはまりますが、それらはコードを書いたエージェントから独立していて、リリース前ではなくすべてのプルリクエストで実行され、人の承認があったときだけ変更されなければなりません。コードはより速く届くので、安全網は誰も待たずに動かなければなりません。
AI コーディングエージェントは自分のテストを書くべきですか?
ユニットテストについてはそうです: 素早く書けて、本当の間違いを捕まえます。しかし、コードを書いたエージェントが書くテストは同じ盲点を持つので、重要な導線のエンドツーエンドテストは独立させ、人が所有してレビューしてください。
自己修復型のテストは AI が生成したコードに対して安全ですか?
テストが要素を見つける方法だけを変える修復は、時間を節約し、安全です。テストが期待する内容を変えたり、アサーションをスキップしたりする修復は、製品についての決定です: 人がレビューするべきで、さもないとテストはコードが行うことの方へ流されていきます。
バイブコーディングで作ったアプリはどうテストしますか?
サインアップ、サインイン、支払いのような、ユーザーにとって欠かせない導線から始めます。それぞれについて画面が表示するものをチェックするエンドツーエンドテストを作り、AI が変更するたびに、何かをリリースする前に実行します。
AI が生成したコードに対して、エンドツーエンドテストはどのくらいの頻度で実行すべきですか?
エージェントが開くすべてのプルリクエストと、すべてのビルドでです。エージェントは 1 時間に何件もプルリクエストを開けるので、一晩に 1 回実行するスイートでは、1 日分の変更が確かめられないまま通ってしまいます。重要な導線は毎回実行できる速さに保ち、スイート全体は毎晩実行してください。
コーディングエージェントは GUI Test Studio のテストを実行できますか?
はい。Claude Code、Claude Desktop、Codex 付きの ChatGPT、VS Code の Copilot Chat は、GUI Test Studio のコネクターにワンクリックで接続でき、MCP コネクターを受け付ける他のどのアシスタントでも使えます。パイプラインでは、gtr-cli がアシスタントなしで同じテストを実行します。
Claude、Cursor、GitHub Copilot、OpenAI Codex、ChatGPT、Devin、Playwright、Cypress、Selenium、Jira、TeamCity は、それぞれの所有者の商標です。
テスト対象のアプリでご覧になりますか? チームとの 30 分の無料相談を予約してください。