AIブラウザエージェントに必要な「ハーネス」とは何か

2026年時点で、Computer Useやブラウザエージェントの主要な発信は、かなり収束しています。OpenAIは、モデルがスクリーンショットを見てアクションを返し、ハーネスが実行して次のスクリーンショットを返すループとしてComputer Useを説明しています。

GoogleのGemini Computer Useは、モデルが提案した操作に対してsafety_decisionを返し、人間確認が必要な場合は実行前に止める形をAPIの一部にしています。

AnthropicのComputer Useも、サンドボックス、allowlist、人間確認、画面内のprompt injectionを明示的なリスクとして扱っています。Microsoft Research系のMagentic-UIやWeb agentの介入研究も、人間の関与を「最後に確認する人」ではなく、co-planning、action guard、long-term memory、介入タイミングの設計として扱っています。

つまり、「責任を外側で持つ」はもう当たり前です。ここから先で考えるべきなのは、責任をどう分解するかです。許可された観測、許可された操作、止める条件、記録すべき証跡、次回に残す知識を、実行ループの中で更新できる形にする必要があります。

Browserbaseの記事が面白いのは、raw CDPか抽象化か、という道具選びの話に留めていないところです。Security、cache、identity、credential broker、skill、filesystemという分解は、「ブラウザを動かす」ではなく「ブラウザ経由の委任を運用する」ための分解です。

ただし、この分解を読むにはBrowserbase自体の位置づけを先に見たほうがよい。Browserbaseは単に「クラウドでChromeを起動するサービス」ではなく、ブラウザエージェントがWebに出るときの実行面を束ねようとしているからです。

Browserbaseの話を薄く扱うと、この記事は「Browserbaseの記事を読んで、自分のBrowser QAに当てはめました」で終わってしまいます。それでは少し弱い。

公式ドキュメントでは、Browserbaseは「Webを人間のように閲覧し操作するエージェントを作り、デプロイするためのプラットフォーム」と説明されています。中身は、クラウドブラウザだけではありません。

Browser API、Search API、Fetch API、Functions、Model Gateway、Agent Identity、Stagehand、observabilityが同じ面に置かれています。つまり、Webを読む、開く、ログイン状態を持つ、操作する、記録する、モデルへ渡す、再実行する、という工程を1つの実行面として扱おうとしている。

ここで重要なのは、Browserbaseが「ブラウザをAPI化する会社」だと言い切るだけでは足りないことです。API化だけならCDPやPlaywrightですでにあります。Browserbaseが足しているのは、AIにブラウザを任せたときに必ず出てくる、状態、身元、証跡、記憶、デプロイの面です。

だからBrowserbaseの記事の「Security、cache、identity、credential broker、skill、filesystem」という6層は、単なる概念整理ではありません。彼らのプラットフォームが実際に持っている論点から出てきた分類です。

セッションを作る。必要ならSearchやFetchで先に読む。Contextでログイン状態を再利用する。Identityで正当な自動化として到達する。Observabilityで実行をあとから見返す。StagehandやBrowse.shで操作知識をSkillへ戻す。この流れは、そのまま「委任を運用する」ための構成になります。

この記事では、この分解をBrowser QAに引き寄せて読みます。ブラウザQAは、単なる画面確認の自動化ではありません。どの範囲ならAIに任せてよいかを、実行結果から更新していく委任契約の台帳になります。

ブラウザを動かすための道具は、すでにあります。Chrome DevTools ProtocolはChromiumやChromeを検査、操作、デバッグするためのプロトコルです。

PlaywrightやPuppeteerは、ブラウザ操作の高水準APIを提供しています。Stagehandのように、AIによる操作と決定論的なコードを組み合わせる道具もあります。

でも、CDPやPlaywrightが与えるのは「ブラウザを動かす能力」です。何を信用するか。何を隠すか。何を記録するか。失敗をどう再利用するか。そうした運用上の方針は、別に決める必要があります。

ローカルで1回だけ試すなら、モデルにブラウザ操作を渡しても動きます。画面を見て、クリックして、フォームを埋めて、結果を返す。デモとしては成立します。

本番で人間の代わりに動かすなら、すぐ別の問題になります。

この問いに答える層が、ブラウザエージェントにおけるハーネスです。ブラウザ操作APIの上に置く、線引き、記録、再利用の仕組みです。

実行ボタンを作るのではなく、押してよい状態を作る。ブラウザ版ハーネスの仕事は、かなり雑に言えばそこにあります。

自分たちのBrowser QAも、最初はPlaywright MCPを操作するSkillから始めました。その後、Claude Agent SDK + TypeScript workflowに載せ替えました。

今はBrowserbaseベースのBrowser Eval Harnessに寄せています。

雑に言うと、同じ問題を3回ぐらい作り直しています。

ここまで来ると、Browser QAは画面確認の自動化ではありません。

Browser QAは、AIに任せてよい範囲と確認条件を、ブラウザ上で確かめ、記録し、再利用する仕組みである。

この考え方は、以前のハーネスエンジニアリング登壇で話した内容にも近いです。