Web アプリケーションの動作確認を Cloudflare Kitesurf に任せられるか試してみた
はじめに
Web アプリケーションを変更した後は、フォーム入力、画面遷移、エラー表示などをひとつずつ確認する必要があります。SaaS の画面をカスタマイズした場合や製品手順書を更新する場合には、実際に画面を操作し、各段階のスクリーンショットを撮り直す作業も発生します。
こうした確認をブラウザー操作エージェントへ任せられれば、人が同じ操作を繰り返す負担を減らせます。一方、静的なページを開けても、入力や非同期更新を含む画面を正しく操作し、必要なスクリーンショットまで残せるとは限りません。
そこで、Cloudflare の AI エージェント向けブラウザーである Kitesurf が、動的な画面確認にどこまで使えるかを試しました。 フォーム、非同期 API、画面遷移、埋め込み画面、多段階操作を持つ Next.js サイトを用意し、実際の業務を模した操作で確認しました。
結果として、フォーム入力、非同期 API、多段階操作は完了できました。一方、「戻る」操作と別オリジン iframe では想定外の挙動があり、スクリーンショットの撮影に失敗する試行もありました。
Kitesurf とは
Kitesurf は、Cloudflare Workers 上で動作する、AI エージェント向けのステートレスなブラウザーです。Chromium の全機能を実装するのではなく、ページの表示や操作、HTML の取得、スクリーンショットの撮影など、エージェントが利用する機能を対象としています。公式資料では、ブラウザーが Web 標準に沿って動くかを測る共通テストである Web Platform Tests (WPT) を使い、DOM、HTML、SVG、CORS、XHR、URL などを検証しています。
対象読者
- Web アプリケーションの実装確認へブラウザー操作エージェントを使いたい方
- SaaS の拡張画面や埋め込み画面を自動確認したい方
- 製品手順書に使うスクリーンショットの撮影を自動化したい方
検証環境
- 検証用 Web アプリ: Next.js 16.3.0、React 19.2.8
- Kitesurf が返した Chrome のバージョン: 145.0.0.0
- 比較用ブラウザー: Chrome 150.0.7871.24 (Chrome for Testing)
- Codex とブラウザーをつないだツール: Chrome DevTools MCP 1.6.0
- ブラウザーを操作したエージェント: Codex (使用モデル:
gpt-5.6-sol)
Kitesurf は遠隔の Linux 環境、Chrome for Testing はローカルの Windows 環境で動作しました。このため、速度や描画の見た目は比較していません。
参考資料
検証した動的ページ
静的な HTML の取得だけでは、実装後の画面確認へ使えるか判断できません。検証用 Web アプリには、実際の業務で確認する操作を模した 5 種類のページを用意しました。
フォーム
React の初期化が終わった後、空のまま送信すると入力エラーを表示します。表示名を入力して送信すると、送信後の状態へ表示名を反映します。入力内容の検証と送信後の画面更新を確認するためのページです。
Kitesurf は、未入力時のエラーを確認した後、表示名を入力して送信できました。 入力した値だけでなく、送信後の画面に値が反映されたことも確認できました。
非同期 API
ボタンを押すと API への問い合わせを始め、読み込み中の表示へ切り替わります。成功時には取得したデータ、エラー時には HTTP 503 を表示します。データ取得中、取得完了、エラーという画面の変化を確認するためのページです。
Kitesurf は、読み込み中の表示を待ち、成功時に取得したデータを確認できました。 エラーを発生させた場合には HTTP 503 の表示も確認できました。
画面遷移
Next.js のリンクから詳細画面へ移動し、URL の検索値を画面へ表示します。詳細画面を開いた後は、ブラウザーの戻る操作で一覧画面へ戻ります。ページ全体を読み直さずに画面を切り替える Web アプリで、画面移動とブラウザー履歴を確認するためのページです。
詳細画面への移動はできました。しかし、ブラウザーの「戻る」操作を実行すると、期待した一覧画面ではなく、前に操作した別のページへ戻りました。
埋め込み画面
別の配信元に置いた画面を、ページ内へ別のページを表示する iframe で埋め込み、親画面から Ocean テーマを送ります。埋め込み画面はテーマを反映し、完了したことを親画面へ返します。SaaS のカスタマイズ画面で使われる、別の配信元との画面連携を模したページです。
結果、ページ全体を読み込めず、埋め込み画面へのテーマ反映を確認できませんでした。 Chrome for Testing では同じページを操作できましたが、Kitesurf で読み込めなかった原因は特定できていません。
多段階操作
基本情報、通知設定、確認の順に画面を進め、入力内容を次の段階へ引き継ぎます。操作の途中と完了後にスクリーンショットを撮影し、製品手順書に必要な画面を記録できるか確認するためのページです。
3 段階の入力を進め、通知設定画面と確認画面のスクリーンショットを撮影できました。 一方、別の試行において、確認画面へ到達した後のスクリーンショット撮影が 4 回失敗したケースがありました。
考察
今回の結果から、Kitesurf は人による最終確認を置き換える段階にはないものの、定型的な画面確認を最初に任せる用途には十分使えそうです。まず Kitesurf で広く確認し、問題が見つかった箇所と公開前の重要な確認を、通常の Chrome を使って人が確認する使い方が現実的でしょう。
一方、「戻る」操作では期待と異なる挙動があったため、複数画面をまたぐ試験を Kitesurf だけに任せるには不安が残ります。別の配信元を iframe で埋め込む画面は読み込めなかったため、同じ構成を持つ SaaS の管理画面を任せるのも現時点では難しそうです。スクリーンショットの撮影を任せる場合は、撮影結果の確認と再試行を組み込む必要もありそうです。
まとめ
Kitesurf で、フォーム入力、非同期 API、多段階操作を含む Next.js の動的ページを操作できました。「戻る」操作と別オリジン iframe では Chrome for Testing と異なる挙動があり、スクリーンショットの撮影に失敗する試行もありました。Kitesurf を動作確認に用いる場合は、必要な操作をまずは小さな範囲で試してみるのが適切と思われます。フロントエンドや SaaS 拡張画面の検証へブラウザー操作エージェントを取り入れる際の参考になれば幸いです。
