agent-browser + wterm + opencodeとは｜Claude CodeでAIがAIを見守る3点入れ子構造とPlaywright MCPの違い

agent-browserとwtermって結局なに？

まずagent-browserから。

Vercel Labsが公開したブラウザ操作CLIで、
Claude CodeやCursorなどのAIエージェントから呼び出す前提で設計されている。

開発の中心はChris Tate氏（@ctatedev）。

2026年1月11日の元ポストはこう書かれています。

Weekend project: agent-browser. Browser automation CLI for agents → Zero config → Fast Rust CLI → Headed or Headless → Up to 93% less context than Playwright MCP → Compatible with Codex, Claude Code, Gemini, Cursor, Copilot, opencode, and any agent that supports Bash

— Chris Tate（元ポスト、1.7Kいいね・95返信）

ポストから1ヶ月で週次ダウンロードが500,000を突破。本人発表の数字です。

これ、相当な速度。

私が気になったのは、
単なるCLIツールではなくAIエージェント専用に設計されている点。

一方のwtermは「web terminal」の略で、
ブラウザ上で動くターミナルエミュレータ。

Chris Tate氏が紹介ポストで挙げた特徴はこれ。

A terminal emulator for the web → DOM rendering — not canvas → Select text, copy/paste, ⌘+F, a11y → Dirty-row tracking, 24-bit color, themes → WebSocket transport with reconnection → Zig core compiled to ~12 KB WASM → just-bash, local, SSH

CanvasではなくDOMでレンダリングしている点がポイント。
テキスト選択やコピペ、
⌘+F検索、
アクセシビリティが標準で使えます。

Zigで書かれたコアをコンパイルして約12KBのWASMにしているのも異常な軽さ。

Playwright MCPと何がそんなに違うの？

agent-browser推しの一次ソースが強調するのはコンテキスト効率。

ただし数字の扱いには注意が必要で、
「最大93%削減」という留保付きの表現が正確です。

公式サイトにはこう明示されている。

snapshot出力: 約200〜400トークン／フルDOM表現: 約3,000〜5,000トークン（出典: agent-browser.dev）

実測検証もいくつか出ています。

paddo.dev（2026年1月）の6操作ベンチマークでは、
Playwright MCPが約31,000文字（約7,800トークン）に対して、
agent-browserは約5,500文字（約1,400トークン）で約5.7倍差。

一方で真逆の実測もあります。

morphllm.com（2026年3月8日）は20ステップの複雑ワークフローでPlaywright MCPのほうが2.0〜3.2倍効率的だったと報告。

Playwright MCP should remain the default for complex CRUD and coding agent workflows.（出典: morphllm.com）

ここが面白いところ。

高橋清二氏（株式会社ベースマキナCEO）のnoteでは、
93%削減は-i（対話要素のみ）-c（空構造削除）-d（深さ制限）というフィルタフラグの組み合わせで初めて達成されると指摘されている。

93%削減は常に達成できるわけではない。
視覚的レイアウト判断には補助的な画像分析が必要なケースもある。
（出典: Seiji Takahashi note 2026年1月14日）

では両者の立ち位置を表にまとめます。

個人的には「agent-browserが全面的に勝ち」という整理ではなく「用途で選ぶべきもの」という読みのほうがフェアだと思っています。

実際、webfuse.com（2026年4月10日）はこう書いています。

Playwright remains the strongest default for most engineering teams.（出典: webfuse.com）

どんな3点セット構成で話題になっているの？

ここが本記事で一番書きたかったところ。

Chris Tate氏が示唆している構図は、
agent-browser単体ではなく3点セット入れ子構造です。

図にするとこう。

構図の要点は3つ。

• Claude Codeが外側で全体を見張る
• wtermで描画されたターミナルの中でopencodeが別のAIとして動く
• agent-browserで外部ブラウザの操作結果を両方のAIに見せる

つまりAIがAIを見守る構造。

opencodeはSST（Serverless Stack）チーム製のターミナルエージェントCLI。
GitHubスター146,000（2026年4月19日時点）、
75以上のモデルプロバイダに対応しています。

Claude、
OpenAI、
Gemini、
Bedrock、
Groq、
Mistral、
Ollamaまで一本で叩ける柔軟さが評価されている印象。

ただしChris Tate氏のデモで示された具体的な操作画面は、
一次URLで詳細が確認できた範囲に限界があります。
agent-browserの公式「対応エージェント」リストにopencodeが含まれている事実と、
wterm紹介ポストで「just-bash, local, SSH」が明示されている事実を組み合わせると、
技術的には成立する構成という粒度の整理が妥当です。

ここは歯切れよく書きたいところですが、誇張は避けます。

日本語解説が薄い領域なのは確か。
shinyaa31氏のzenn記事（2026年4月11日）はClaude CodeとagentBrowser単体の連携を丁寧に実演していますが、
3点入れ子構造を日本語で図解した記事は現時点でほぼ見当たりません。

私の見方では、ここが今後1〜2ヶ月で日本語技術ブログの主戦場になるエリア。

料金と環境はどれくらい必要？

3ツールとも本体は無料。

内訳を表に整理します。

運用費で効いてくるのはAIのAPIトークン代だけ、と公式は案内しています。

agent-browserの公式changelogによれば、
v0.20.0以降はNode.js依存を完全除去してネイティブバイナリ化。
コールドスタートが1002ms→617ms、
デーモンメモリが143MB→8MB、
インストールサイズが710MB→7MBと激減しています。

この数字はさすがに強い。

18倍減、99倍減の桁が並ぶとインパクトがあります。

v0.26.0ではdoctorコマンド（環境診断・自動修復）と安定タブID（t1, t2）が追加されました。

opencodeについては運用上の注意点がひとつあります。
sst/opencodeはAnthropicから2026年1月9日に法的要求を受け、
Consumer OAuthトークン経由のClaude利用はブロック済み。
APIキー直打ち運用は継続可能、
とアナウンスされています。

Claude ProやMaxプランのアカウント連携で使おうとしている場合は、
API契約が別途必要です。

どんな場面で効きそうか？

個人開発者・副業エンジニア目線で整理します。

Playwright MCPを既に使っている層から見ると、
agent-browserの旨みはトークン代の削減と起動の速さ。
ここが効くユースケースを挙げます。

ケース1: 朝イチの管理画面チェック自動化

WordPressやShopifyの管理画面をClaude Codeに見張らせるタスク。

毎朝1回スナップショットを取ってレポート化する運用なら、
snapshot 200〜400トークン×複数ページでも消費量は軽め。

Playwright MCPでフルDOMを毎回読ませると、
APIコストが厚くなる構造です。

ケース2: 副業サービスの回帰テスト

ランディングページのフォーム送信、決済フローの見た目確認、レスポンスの取得。

agent-browserのbatchコマンドで複数操作をJSONパイプで流せるので、
shinyaa31氏のzenn記事で示されている通り、
Claude Codeが自動でコマンドを組み立てて実行する流れになります。

ケース3: AIエージェントのデモ環境

wterm + opencodeで「ブラウザ上でAIが動くデモ」を作るパターン。

Zigコア12KBのおかげでCDN配信も軽く、
静的ファイル配信不要（WASMはbase64でJSバンドルにインライン化）。

個人の技術ブログや副業サービスのランディングページにデモを埋め込むなら、
この軽さは武器になります。

ケース4: 複雑ワークフローは従来通り

morphllm.comの実測で示された「20ステップ以上のCRUD処理」ではPlaywright MCPのほうが効率的なので、
こちらは従来通り。

agent-browserに全移行ではなく、
用途で使い分けるスタンスが今のところ無難です。

安全設定で気をつける点はある？

ここは引用しておきたい箇所。

hirokaji氏のnote（2026年4月6日）がこう指摘しています。

agent-browserはブラウザ自動化ツールではない。
本質は「LLMが限られたコンテキストウィンドウでWeb UIを読むための中間表現レイヤー」。
安全制御（ドメイン許可リスト、
アクション確認）はデフォルトオフで要明示設定。
単体では計画・管理・長期記憶機能がなく、
タスク全体のオーケストレーションには不向き。
（出典: hirokaji note）

この指摘は重要。

ドメイン許可リストとアクション確認ポリシーがデフォルトでオフなので、
本番環境で寝かせ運用するならconfigで明示設定が必要です。

セッションCookieやlocalStorageはAES-256-GCMで暗号化されますが、
それは保存時の話。
操作範囲を絞る設定は別に必要です。

Hacker Newsのコメントでも現実的な懸念が挙がっています。

freezing doesn't pause servers. Real SPAs with optimistic UI updates still create confusion when DOM says 'saved' but network requests haven't finished.（出典: Hacker News agent-browser-protocolスレッド）

DOMが「保存済み」と言っていてもネットワークリクエストが終わっていない、
というSPA特有の罠。

私ならここを読んだ時点で、
本番投入前にテスト環境で最低1週間は挙動を眺める運用にします。

よくある疑問

Q. agent-browserはPlaywrightの完全上位互換ですか？

いいえ。
webfuse.comやmorphllm.comの比較記事では、
20ステップ以上の複雑なCRUDワークフローではPlaywright MCPのほうが効率的という実測が示されています。
agent-browserは日常的なブラウザ操作と、
トークン効率が効く中短尺のタスク向け。
ytyng.comも「日常用途はagent-browser、
複雑操作はPlaywright CLIで補完」と整理しています。

Q. 93%削減というのは誰の数字ですか？

agent-browser開発者のChris Tate氏本人による2026年1月11日のXポスト「Up to 93% less context than Playwright MCP」が一次ソースです。
「Up to」（最大）という留保付き。
paddo.devの6操作実測では約5.7倍差、
morphllm.comの20ステップ実測ではPlaywright MCPのほうが優位という結果もあるため、
ページ複雑度に依存する数字です。

Q. Claude Codeと連携させるのにMCPサーバーは必要ですか？

不要です。
agent-browserはCLIツールでBashから呼び出す設計なので、
Claude Codeに限らずCursor、
GitHub Copilot、
Codex、
Gemini、
opencodeなど「Bashを叩けるエージェント全部」が対象。
MCP未対応のエージェントでも動きます。

Q. wtermとagent-browserはセットで使う必要がありますか？

いいえ、
独立したツールです。
wtermはブラウザ上のターミナル描画ライブラリで、
agent-browserは外部ブラウザの操作CLI。
Chris Tate氏のXポストでは両者とjust-bashを組み合わせたデモが示唆されていますが、
単体運用も可能です。

Q. 料金はどれくらいかかりますか？

agent-browser、
wterm、
opencodeの3ツールは本体無料（Apache-2.0またはMIT）。
実運用でかかるのはAIのAPIトークン代だけです。
Claude APIを使うならAnthropicの従量課金、
OpenAIやGeminiを使うなら各社の料金体系が適用されます。

Q. opencodeとAnthropicの関係で注意点は？

sst/opencodeは2026年1月9日にAnthropicから法的要求を受け、
Consumer OAuthトークン経由のClaude利用はブロックされました。
APIキー直打ちなら継続利用可能です。
Claude Pro/Maxのサブスクを流用する運用は不可なので、
API契約が必要です。

まとめ

ここまで整理した論点を3つに絞ります。

• agent-browser＋wterm＋opencodeは「AIがAIを見守る」3点入れ子構造を成立させる新興OSS。Chris Tate氏の元ポスト1.7Kいいね・週500,000DL到達・GitHubスター29,800が示す通り勢いは本物
• 「最大93%コンテキスト削減」はケース依存。単純ページでは5.7倍差の実測もあるが、複雑CRUDではPlaywright MCPに軍配。用途で使い分けるのが今のところ妥当
• 安全設定はデフォルトオフ。本番運用するならドメイン許可リストとアクション確認ポリシーを明示設定すること

個人開発者にとって「毎朝の管理画面チェック」「副業サービスの画面回帰テスト」「ブログやLPへのAIデモ埋め込み」はフィットしやすい領域。

ここは抑えておきたい組み合わせ。

日本語での3点入れ子構造解説はまだ薄いので、
英語圏のChris Tate氏の発信と日本語エンジニア記事を引き続きウォッチしていく予定です。

参考リンク

• agent-browser 公式サイト
• agent-browser changelog（v0.20.0以降のRust化パフォーマンス数値）
• vercel-labs/agent-browser（GitHub）
• wterm 公式サイト
• vercel-labs/wterm（GitHub）
• vercel-labs/just-bash（GitHub）
• opencode 公式サイト
• sst/opencode（GitHub）
• Chris Tate氏 agent-browser元ポスト（2026年1月11日）
• Chris Tate氏 wterm紹介ポスト
• Chris Tate氏 500,000週次DL達成ポスト
• paddo.dev コンテキスト効率実測（2026年1月）
• morphllm.com agent-browser vs Playwright MCP比較（2026年3月）
• ytyng.com 3ツール比較記事
• webfuse.com Puppeteer/Playwright/agent-browser比較（2026年4月）
• Seiji Takahashi（高橋清二）note（2026年1月14日）
• hirokaji note「agent-browserはブラウザ自動化ツールではない」（2026年4月6日）
• shinyaa31 zenn（2026年4月11日）
• Hacker News agent-browser-protocolスレッド

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。