調査・比較

AIエージェントの実ブラウザ操作をCIに組み込む方法

POINT

  • Cloudflareの「Kitesurf」とRob Pruzan氏の「terminal-browser」が、AIエージェントが実ブラウザを操作する基盤として2026年に相次いで登場した
  • 録画起点の受け入れテストと違い、隔離・権限制御・証跡を備えた実行基盤として設計されており、CIへの組み込みを前提にできる
  • 読み終えると、Codex・Claude Codeでの実装フェーズにUI回帰テストを自動で挟み込む際の技術選定基準がわかる

なぜ今、AIエージェントのブラウザ操作をCIに通す必要があるのか

CodexやClaude Codeで実装したUIを、人間がクリックして確認する作業は減らない。エージェントに実装だけでなく検証まで任せたいと考えるのは自然な流れだ。だが実ブラウザをエージェントに渡すのは、ローカルの信頼できるページを開くのとはわけが違う。

エージェントが訪れるページは外部由来のスクリプトやコンテンツを含む。読み込んだHTMLがそのままエージェントへの入力になる以上、悪意あるページからの情報漏えいや権限昇格のリスクを無視できない。CIパイプラインに組み込むなら、隔離・権限制御・実行証跡の三つが最低条件になる。

「隔離」と「ターミナル内表示」、二つのアプローチの仕組み

Cloudflareが発表したKitesurfは、Workers上のV8 isolateで完全に動くエージェント専用ブラウザだ。Rust製のヘッドレスエンジン「obscura」をベースに、wasm-bindgenでWebAssemblyへ直接コンパイルしている。ネットワークへ直接アクセスできるコンポーネントはSandboxOutbound workerに限定し、Dynamic WorkersでCORS適用、Cookie分離、ポリシー違反時の403応答までを一括管理するIntroducing Kitesurf。すべてのページ読み込みを信頼できない入力として扱い、各セッションを初期状態から始める設計は、CI上で毎回クリーンな検証を回したい用途に合う。処理に失敗してもセッションを落とさず、空白フレームとして扱う点も落ちにくいCI向きの割り切りだ。

一方のterminal-browserは方向性が違う。開発者のRob Pruzan氏が2026年7月30日にXで公開したもので、ChromiumをElectronのオフスクリーンレンダリングで描画し、Kitty graphics protocolでターミナルにそのまま表示する。2026年7月31日時点の最新はv0.3.2。マウス・キーボード入力はChromiumへ渡り、ターミナルから拾えない入力はSwift製のバックグラウンドアプリがOSレベルで補う。agent-browser互換の`terminal-browser action`は、スナップショット取得・クリック・フォーム入力・JS実行に対応し、SSH越しでもポート転送なしで同じセッション内に描画結果を送れる。ただしApple Silicon Mac限定でWindows非対応、Linuxはロードマップ止まりだ。

Kitesurf と terminal-browser の設計比較
比較項目 Kitesurf Cloudflare(クラウド分離型) terminal-browser Rob Pruzan氏(ローカル描画型) 実行環境 Cloudflare Workers • V8 isolate 上で分離実行 • WASMへ直接コンパイル ローカルMacのターミナル • Electron Offscreenレンダリング • Swift製アプリでOS入力を補完 隔離・通信 SandboxOutbound worker • Dynamic Workersでアクセス制御 • セッション単位で初期状態を保持 Kitty graphics protocol • ターミナルへ直接描画表示 • SSH越しでもポート転送不要 制御プロトコル CDP 対応 • Puppeteer / Playwright 互換 • 既存自動化ツールと直結可能 agent-browser 互換 • action コマンド操作 • クリック・JS実行・SS取得に対応 対応環境 クラウド (OS非依存) • Web標準・どこからでも利用可能 ※ Browser Runベータ期間中は無料 Apple Silicon Macのみ • Windows非対応 ※ Linuxはロードマップ段階 Kitesurf クラウド分離型 terminal-browser ローカル描画型 ■ 実行環境 Cloudflare Workers • V8 isolateで分離 • WASMへ直接実行 • クラウド上で動作 Mac ターミナル • Electron描画 • Swiftアプリで補助 • ローカル上で動作 ■ 隔離・通信 SandboxOutbound • Dynamic Workers • セッション制御 • 毎回初期化で安全 Kitty protocol • 画面直接描画 • SSH対応 • ポート転送不要 ■ 制御プロトコル CDP 対応 • Puppeteer 互換 • Playwright 互換 • 既存ツール連携 agent-browser • action コマンド • クリック/フォーム入力 • JS実行・SS取得 ■ 対応環境 クラウド (OS非依存) • どこからでも実行 ※ ベータ期間中は 無料提供 Apple Silicon Mac • Win非対応 ※ Linuxはロード マップ段階
クラウド上での安全な実行に特化したKitesurfと、ローカル端末内の表示に特化したterminal-browserの機能比較。

実例に見る、ゲームQAからUI回帰テストへの応用

実プロダクトでの先行例は既にある。スクウェア・エニックスの荒牧岳志氏は2026年7月30日、「Google Cloud Next Tokyo '26」の基調講演で、GoogleのGeminiによるゲーム自動プレイを披露した。GeminiはGemini Enterprise Agent Platform上で動作し、ゲーム画面の状況を認識してコントローラーを自動操作する仕組みだスクエニ、ゲームの品質テストをGeminiで自動化。この取り組みは経済産業省のコンテンツ産業向け支援にも採択されている。

AIがゲーム内の地図を開いて場所を確認し、キャラクターを操作する自動プレイ画面には、思考過程とタスクリストが表示された。

ゲームQAとWeb UIの回帰テストは対象が違うだけで、発想は同じだ。エージェントが画面を見て操作し、判断根拠を証跡として残す。KitesurfのCDP対応をPlaywrightのCI実行に差し込めば、隔離環境でのスクリーンショット比較とアクセス制御が同時に手に入る。terminal-browserなら、ローカルMac上でエージェントに実際の操作ログとスナップショットを取らせ、SSH越しにレビューする運用が組みやすい。

導入すべきチーム、まだ早いチーム

CodexやClaude Codeで実装まで自動化していて、次はUI変更の検証もエージェントに預けたいチームには向いている。Kitesurfのベータ期間中は無料提供が続いており、CI上に毎回実ブラウザを立てるコストとセキュリティ懸念を同時に下げられる。terminal-browserは、Mac上でローカルにエージェントの操作を目視確認しながら開発したい個人〜小規模チームに向く。

逆に、Windows前提の開発環境や社内の複雑な認証基盤を通す必要がある場合は、現状の対応範囲では手が届かない。terminal-browserはApple Silicon Mac限定で、Windows非対応、Linuxはロードマップ段階に留まる。CIがまだ整っていないチームは、隔離基盤より先に基本のテスト自動化を固めるほうが優先度は高い。

まとめ

AIエージェントに実ブラウザを渡す時代は始まったばかりだが、隔離・権限制御・証跡という三条件を満たす基盤は既に手が届く。KitesurfのCDP互換性、terminal-browserのローカル運用のしやすさ、どちらを選ぶかは対象環境と信頼境界の設計次第で決まる。まずは自分のCIパイプラインに、どちらが安全に組み込めるか試すところから始めるといい。