Claudeに本物のブラウザがINした?話題の「dev-browser」の正体と、SNS自動化勢が知るべき”BAN耐性”の話

「ClaudeにブラウザがINした」が話題

2026年4月7日、海外の開発者 Suryansh Tiwari氏(@Suryanshti777) による1本のXポストが、AI自動化界隈を騒がせている。

「Holy shit… someone just gave Claude a real browser. Not screenshots. Not brittle selectors. Not slow MCP loops. Real Playwright code — inside a sandbox.」
(訳: マジかよ、誰かがClaudeに本物のブラウザを持たせやがった。スクショじゃない、壊れやすいセレクタじゃない、遅いMCPループじゃない。サンドボックス内で動く本物のPlaywrightコードだ)

これを日本語圏で広めたのが、AI自動化系インフルエンサーのそらさん(@sora19ai)だ。「エージェントの手が生えた感じだ」という一言が、技術的な核心を見事に捉えている。

正体は「dev-browser」というClaude Code Skill

調べてみると、紹介されているツールの正体は SawyerHood氏 がGitHubで公開している dev-browser だ。Claude Code向けのスキル/CLIツールとして配布されている。

従来のブラウザ自動化と何が違うのか、ポイントは3つに整理できる。

① AIが「Playwrightコードそのもの」を書く

これまでの主流は「MCPサーバ越しに、定義済みのツール(クリックする・テキスト取る等)をAIに呼ばせる」方式だった。dev-browserはこの中間層を取っ払い、AIが直接Playwrightのスクリプトを書いてサンドボックス内で実行する。

例えるなら、これまでが「指差し会話帳でレストランの店員と会話する」だったとすれば、dev-browserは「AIが現地語をそのまま喋る」感覚に近い。AIにとっては表現の自由度が一気に上がる。

② QuickJS WASMサンドボックスで安全

「AIにPlaywright書かせるなんて怖すぎる」という直感は正しい。dev-browserはこの懸念に対し、QuickJSというJavaScriptランタイムをWASMサンドボックスで動かすという解で答えている。Node.jsではない。

これにより、AIが書いたコードはファイルシステムにアクセスできず、ホストOS上でコマンドも実行できない。ブラウザ操作という強力な権限を与えつつ、危険な範囲は物理的に切り離されている。

③ 「ヘッドレス起動」と「既存Chrome接続」の2モード

これがSYNCON読者にとって最も重要なポイントだ。dev-browserには起動モードが2種類ある。

• --headless: 新規にヘッドレスChromiumを立ち上げる(従来型の自動化)
• --connect: すでに開いている自分のChromeに接続する(chrome://inspect/#remote-debuggingでリモートデバッグを有効化する必要あり)

後者の--connectモードは、ログイン済み・拡張機能入り・Cookie永続化済みの「自分の本物Chrome」をAIに操らせる、という発想だ。

ベンチマークが派手

作者が公開しているベンチマーク値は確かに目を引く。

比較対象として、Playwright MCP・Chrome拡張・各種browser skillsより「速くて安い」と作者は主張している。実測条件の詳細は確認の余地があるが、少なくとも「重い」「遅い」と言われがちなMCPブラウザ操作に対する一つのアンサーであることは間違いない。

SYNCONの視点:派手さの裏にある「使い分け」

ここからが本題だ。「Claudeにブラウザが生えた」という華やかな見出しに乗って、すべてのブラウザ自動化を dev-browser に置き換えるべきかというと、答えは 「やる仕事による」 である。

SaaS操作なら最有力候補

Google Sheets、Notion、Slack、GitHub、社内ダッシュボード——こうした「業務系SaaS」の自動化用途では dev-browser は極めて有望だ。bot検出が緩く、APIで足りない細かい操作(複雑なフォーム入力、複数ステップのワークフロー)を、AIに任せられるようになる。MCPの「重さ」に悩んでいた人ほど刺さるだろう。

SNS運用、特にXでは話が変わる

一方で、X(旧Twitter)、Instagram、ThreadsといったSNSプラットフォームの自動操作には、別の論点がある。これらのプラットフォームは2023年以降、bot検出を異常に強化しており、検出シグナルは複数レイヤーに及ぶ。

• ブラウザフィンガープリント: Playwrightデフォルトの--headlessモードはChromiumベースで、navigator.webdriver等の痕跡が残る
• IPレピュテーション: クラウド実行時のデータセンターIPは即フラグが立つ
• Cookie/セッションの非永続性: 毎回新規ログインは即アウト
• TLSフィンガープリント: 本物のChrome.appとChromiumには微妙な差がある

つまり、--headlessモードでX運用を回そうとすると、数日でshadowbanや凍結のリスクが跳ね上がる。

「--connectモード+本物Chrome」が現実解

では dev-browser はSNS用途で全くダメかというと、そうではない。--connectモードを使い、「自宅IP+本物のChrome.app+ログイン済みプロファイル」に接続する形であれば、外部から見れば「ちょっと操作の速い人間」でしかない。これならXからの検出シグナルは大幅に下がる。

逆に言えば、SNS自動化を考えるなら「物理マシン+住宅IP+永続プロファイル」という”重い構成”こそが本命であり、dev-browserは「その上で走らせる便利な操縦桿」として位置付けるのが正しい。サンドボックスやクラウド実行の魅力に引きずられて、足元の生存条件を見失ってはいけない。

大人の結論:「AIに手が生えた」を冷静に受け取る

そらさんが言う「エージェントの手が生えた」という比喩は、技術トレンドの本質を捉えている。AIが「画面を見る」段階から「画面を操作する」段階へ移行している、という認識は正しい。

しかし、その「手」が動かす対象が業務SaaSなのか、SNSなのかで、戦略はまったく変わる。前者なら dev-browser のような新世代ツールに即乗っていい。後者なら、目立たない既存運用を慎重にアップデートしていく忍耐が要る。

「速くて安い」より「続けられる」が、最終的には強い。これはメディア運営でもAI活用でも、ずっと変わらない真理だ。

ソース

• GitHub: SawyerHood/dev-browser
• Suryansh Tiwari氏 元ポスト: @Suryanshti777
• そらさん 紹介ポスト: @sora19ai