悩み：納品前の動作確認、毎回手作業でポチポチするのに限界を感じている
Web制作の仕事をしていて、納品直前の「一通り触ってみる」動作確認が地味にしんどい。フォーム送信、会員登録、カート追加からの決済画面遷移……同じ操作をブラウザで何度もポチポチ繰り返し、修正が入るたびにまた最初からやり直す。件数が増えるほど「今日ちゃんと全部確認したっけ」という不安がつきまとう。
2026年に入ってから、AIがブラウザを実際に操作しながらE2E（エンドツーエンド）テストのコードを自動生成してくれるという話をよく見かけるようになった。ChatGPTやClaudeにMCP経由でブラウザを操作させ、その操作履歴からPlaywrightのテストコードを書かせる、という使い方だ。手作業の動作確認をどこまで肩代わりしてもらえるのか、実際の案件サイト（保守契約中のもの）で試してみた。
結論を先に言うと、AIに「このページで会員登録から購入完了までの操作を再現するPlaywrightテストを書いて」と頼むと、ボタンのクリックやフォーム入力といった基本操作のテストコードはものの数分で書き上がった。ただし、「このクライアントは在庫切れ表示を特別扱いしている」「このフォームだけ確認画面が2段階ある」といった、そのサイト固有の業務フロー上の分岐は、こちらが指示しない限りAIは気づいてくれなかった。
TOI
テストは「グリーン」になったのに、後で見たら在庫切れの商品がふつうにカートに入っていた……
なぜChatGPT×PlaywrightでのE2Eテスト自動生成を試したか
Playwrightは、ブラウザを自動操作してWebサイトの動作を検証できるオープンソースのテストツールだ。従来は「どのボタンを、どんな順番でクリックするか」というテストコードを人間が書く必要があったが、2026年に入ってからはChatGPTやClaudeにブラウザ操作の指示を出すと、その操作をなぞったPlaywrightのコードをAIが自動で書いてくれる使い方が広まっている。
自分で全ページ分のテストコードを書くのは非現実的だが、「AIに操作を伝えるだけでテストコードが手に入る」なら、納品前の動作確認をかなり効率化できるのではと考えた。非エンジニアの同僚でも、コードは書けなくても「こういう操作を確認したい」という日本語の指示くらいは出せる、という点にも期待した。
実際にやってみた
やった手順
- 保守契約中のECサイト（テスト環境）を対象に、「トップページ→商品ページ→カート追加→会員登録→購入完了画面」までの一連の操作をChatGPTに日本語で説明
- 「この操作を再現するPlaywrightのテストコードを書いて」と依頼
- 生成されたコードをローカル環境で実行し、実際に想定通りの画面遷移になるか確認
- エラーが出た箇所や、想定と違う挙動になった箇所をAIに伝えて修正させる
AIが速かったこと
日本語で操作手順を伝えるだけで、動くテストコードがすぐに出てきた点は素直に驚いた。
- 「商品ページの『カートに入れる』ボタンを押す」だけの指示から、該当ボタンのセレクタを推測してクリック処理のコードを生成
- フォーム入力（氏名・メールアドレス・パスワード）を一気にコード化し、入力後の「次へ」ボタン遷移まで含めて再現
- テスト実行時にエラーが出ても、エラーメッセージを貼り付けるだけで「このセレクタが変わっている可能性がある」と原因を推測して修正案を出してくれる
- 一度書いたテストコードを土台に、「同じ流れをスマホ表示でも確認して」と頼むと、画面幅を変えたテストにすぐ書き換えてくれる
基本的な画面遷移・フォーム送信のテストコードを一から書く時間は、ほぼゼロになったと言っていい。これまで「動作確認したいけどテストコードを書く時間まではない」と諦めていた工程に、初めて自動化の足がかりができた感覚があった。
AIに任せきれなかったこと
一方で、実際にテストを走らせてから気づいた抜け漏れがいくつかあった。
- 在庫切れの商品ページでは「カートに入れる」ボタンの代わりに「入荷通知を受け取る」ボタンが表示される仕様だったが、AIが書いたテストはボタンの有無を確認せず、常に通常のカート追加フローとして進めてしまっていた
- このクライアントのサイトだけ、確認画面が「入力内容確認」と「配送方法確認」の2段階に分かれているが、AIは一般的な1段階の確認画面を前提にコードを書いていた
- クーポンコード入力欄など、このサイト固有のオプション項目はAIの生成コードには含まれておらず、こちらが個別に「この項目もテストして」と指示しない限り漏れ続けた
AIは「一般的なECサイトの購入フロー」を前提にコードを組み立てているため、そのクライアントのサイトだけに存在する分岐や特殊な仕様は、こちらが業務フローを把握したうえで具体的に指示しない限りテストの対象から漏れる。「テストがグリーンになった＝サイトが正しく動いている」と鵜呑みにするのは危険だと痛感した。
TOI
結局「このサイトの仕様、どこが特殊だっけ」を思い出す作業は自分でやるしかなかった
結局どこまで任せていいか：案件の性質別に整理する
やってみて分かったのは、E2Eテストの自動生成そのものより「対象サイトの仕様をどれだけAIに伝えられるか」で任せられる範囲が大きく変わるということだった。
汎用的な構成のコーポレートサイト・ランディングページの場合
お問い合わせフォームの送信、リンク切れの有無といった標準的な確認項目であれば、AIが生成したテストコードをほぼそのまま使ってよい。特殊な業務フローがないぶん、抜け漏れのリスクも小さい。
ECサイトや会員機能付きサイトなど、業務フローが複雑な場合
先に自分で「このサイト特有の分岐」を洗い出してリスト化し、その一つひとつをAIに個別のテストケースとして指示する必要がある。ここを省くと、在庫切れや2段階確認のような仕様がテストから抜け落ちる。
保守契約中で継続的に回帰テストを回したい場合
一度書いたテストコードを資産として蓄積し、修正が入るたびにAIに差分だけ調整させる運用が向いている。ゼロから毎回書き直すのではなく、既存コードをベースに「この画面だけ変わったので直して」と頼む方が、抜け漏れも減らしやすい。
まとめ
- ChatGPTに日本語で操作手順を伝えるだけで、動くPlaywrightのE2Eテストコードがすぐ手に入るようになり、基本的な画面遷移・フォーム送信のテスト作成はほぼ自動化できる
- ただしAIは「一般的なサイトの標準フロー」を前提にコードを書くため、在庫切れ表示や2段階確認画面のような、そのクライアント特有の分岐は指示しない限りテストから漏れる
- 「テストがグリーン」を鵜呑みにせず、対象サイト固有の仕様を自分で洗い出したうえでAIに具体的に指示するひと手間が欠かせない
- 次のアクションとしては、案件開始時に「このサイトだけの特殊な業務フロー」をリスト化しておき、AIにテストコードを書かせる際は毎回そのリストを一緒に渡すようにすると、抜け漏れをかなり減らせる
コメント