OpenChrome - Chromeブラウザ向けの並列自動化MCPサーバー
(github.com/shaun0927)Playwrightは、何らかの形でクローリングをしたり、
本番環境でE2Eテストを行いたいときに、
ブラウザ上でクリックなどのアクションを操作してくれる便利なWeb自動化ツールです。
2020年にリリースされましたが、
今でも大半の開発者が使っているツールです。
ですが、1セッション立ち上げるだけでもRAM消費が2GBを超え、重くて遅く、壊れやすいです。
AI時代にはこのツールにも革新が必要で、
特に並列作業でも安定して動くブラウザ自動化ツールが必要です。
私たちはもう手動でQAをしたり、サイト内をうろついたりしたくありません。
OpenChromeは、この問題を解決したいという意志から始まったプロジェクトです。
並列で高速かつ賢くブラウザの並列自動化を実現するMCPサーバーです。
個人的な作業でも、最近もっともよく使っているツールです。
Chromeブラウザのログインを利用し、
複数アカウントを使う場合は、作業時に使用するアカウント名を指示していただければ大丈夫です。
基本的には、ログイン済みのChromeブラウザを基準に動作します。
20個以上のブラウザで並列作業が可能で、RAM使用量を約300MBまで削減しました。Chromeにログインした状態で作業するため、事実上Bot検知を全面的に無力化します。Openclawとの連携も可能です。
使用例は以下のとおりです。
"Twitterの著名人20人の最新投稿をocでクロールして。"
(claude code基準のベンチマークで3分30秒所要 - ほとんどはLLMの推論時間です)
実際、playwrightの慢性的な問題は、無駄な動きをする「LLM徘徊」です。
ログインのような作業を指示しても、長いあいだサイト内を探り回りながらあれこれ試し、
結局30分以上かかって失敗したという通知が来ることがあります。
Openchromeは、これを推測方式ではなくGuided方式で解決します。
Chromeにすぐログインし、リンクを渡せばすぐそのリンクにアクセスします。
スクリーンショットは最小限だけ撮り、ボタンなどの位置を素早く把握します。
作業中に問題が起きても、記憶をたどって同じミスを繰り返しません。
MCPサーバーなので、既存のPlaywrightの代わりにあらゆる環境ですぐ使えます。
MAC-claude code開発やWindows、Linuxなど他のOSはもちろん、
codex cli、cursorなどでも動作します。
インストール :
npx openchrome-mcp setup
非常に複雑で容量消費の大きい大規模プロダクションでの安定性については追加検証が必要ですが、
フィードバックや提案があればGitHub Issuesに投稿していただければすぐ反映します。
ありがとうございます。
13件のコメント
既存のE2Eソリューションを使わずに、AIが直接テストコードを管理して実行するようになるのでしょうか？
従来のplaywrightは定型的な方法論でWebサイトにアクセスするため、トークン消費が大きかったとすれば、
openchromeはLLMフレンドリーにアクセスし、LLMがWebサイトの動作制御に素早く直接関与できるようにする、というコンセプトとして捉えるとよさそうです。e2eソリューションを直接実行できます。
たとえばGoogleログインが必要な本番環境で、管理者アカウントでログインした状態のままQA作業をさせることができます。スクロールしたり、エッジケースを自動でクリックさせたりなど、想像できるたいていの作業はすべて可能です。playwrightに自律的に間の抜けた作業をさせっぱなしにするのではなく、LLMが即座に関与して動作を制御する方式だからです.
トークン使用量だけを見れば、定型化された方法は E2E テストケースを LLM の介入なしで回すことなので、むしろ少なくなるのではありませんか?
テスト方法論を見ると、TC のほかに QA が自律的にテストすることも含まれていますが、
その部分について効率が良いと判断すればよいのでしょうか?
具体的にご質問いただいたので、もう少し技術的にお答えすると、
従来の Playwright MCP は、以下の3段階の抽象化で動作します:
LLM → MCP サーバー → Playwright Node.js サーバー → CDP/Juggler → ブラウザ
一方、OpenChrome は以下の1段階の抽象化で動作します:
LLM → MCP サーバー → CDP → ブラウザ
抽象化レイヤーが少ないほど高速で制御も精密になり、
Playwright が汎用ツールであるのに対し、OpenChrome は特化型のツールを使っています。
数学の問題でたとえるなら、20行の解法プロセスを4行に圧縮したような感覚だと考えていただければよいです。
Playwright はアクセシビリティツリーというテキストベースの方式でフィードバックを受け取るため、
（理論上は優れていますが、ほとんどのサイトで破綻する理由でもあります）
文脈把握がかなり制限されます。
したがって、アクセシビリティがうまく実装されたサイト（Google などの有名ドメイン）では依然として Playwright は有用ですが、
大半のサイトや本番環境では OpenChrome のほうが圧倒的に優れています。
また、「ツール設計の密度」と「LLM がミスする機会を減らすこと」が、結局は実運用での性能を左右するため、
理論上の性能ではなく real-world task で測定するのが適切だと考えています。
ありがとうございます。本文を十分に読めていませんでした。
本番環境を対象としていたという点を見落としていました。
私もぜひ使ってみます。
的外れな質問にも丁寧にお答えいただき、ありがとうございます〜
いいえ、良いご質問をありがとうございます。私も説明しながら、自分の中で整理できました。
確かに速くて良いですね。
でも、アラートが出ると止まってしまいますね。
この内容は早急に改善します。
Chrome DevTools MCP との比較も気になりますね！
使ってみたときは、chrome devtools mcp よりもむしろ Playwright のほうが良かった記憶がありますが、今後ベンチマークも追加してみます。
chrome devtools mcp は large context の警告が出ないのに、性能はほぼ同じように感じたので、自分はこれを使っていました！ ベンチマーク結果が楽しみですね :D
おお、トークン使用量も減るんですか？ありがとうございます！！
無駄打ちが減るぶん、トークン消費も減ると考えればよいです