Browserbase Skills徹底解説｜Claude Codeにブラウザ自動化10機能を授けるスキル集

Browserbaseが公開している公式リポジトリ browserbase/skills は、Claude Codeにブラウザ自動化・QAテスト・トレース取得などの10機能を一括で追加できる「スキル集」だ。npx skills add browserbase/skills 一発で導入でき、内部では公式CLI bb とBrowserbase クラウドに繋がる。執筆時点でGitHub Stars 595、skills.shレジストリでも公式扱いとして掲載されている。

この記事ではBrowserbase Skillsの内容と使い方を解説します。Claude Code全体の使い方はClaude Code完全ガイド2026：インストールから本番運用までをご覧ください。

Browserbase Skillsとは：Claude Code × ブラウザ自動化

browserbase/skillsは、Claude Codeに「ブラウザを操作する能力」を後付けするスキル集だ。Browserbase本体は、Anti-Botステルス・CAPTCHA自動解決・住宅プロキシ・サーバレス実行を備えたクラウド型のヘッドレスブラウザ基盤で、PlaywrightやStagehandから接続する形で従来から提供されてきた。今回のリポジトリは、その操作層をClaude Codeから自然言語で叩けるよう、スキルとして整理し直したもの。

「スキル」とは何か、という前提が必要ならClaude Skillsを徹底解説：スキルはフォルダ——Anthropicエンジニアが明かした仕組みと使い方が下地になる。フォルダ構造のSKILL.md＋スクリプトという軽量な拡張機構で、ベンダーがClaude Codeを実用領域に持ち込むのに使われ始めている。Browserbaseのこのリポジトリは、その代表的な早期事例だ。

10スキルの中身：何ができるようになるか

公式READMEに掲載されている全10スキルを、用途別に整理した。

「ブラウザを開く」ものから「ブラウザを開かない」もの（fetch / search）まで含まれているのがポイントで、コストとレイテンシの観点で常にブラウザは過剰という現実に応えている。スクレイピングや単発のJSON取得ならfetchで十分、多段のフォーム入力やJS依存サイトではbrowser、というふうに使い分ける設計だ。

インストール：npx一発か Claude Codeマーケットプレイスから

導入は2通り。汎用エージェント向けとClaude Code限定の2系統がある。

# 1. 任意のコーディングエージェント向け（npx）
npx skills add browserbase/skills

# 2. Claude Code 内のプラグインマーケットプレイス経由
/plugin marketplace add browserbase/skills
/plugin install browse@browserbase

特定の1スキルだけ欲しいなら、skills.shレジストリからピンポイントで入れることもできる。

# browser-traceだけインストール
npx skills add https://github.com/browserbase/skills --skill browser-trace

ローカルでChromeを起動して使う場合は、専用コマンドが用意されている。

# 隔離されたプロファイルで新しいChromeを起動
browse env local

# 既存のChromeセッションをそのまま使う
browse env local --auto-connect

# プロファイルをリセット
rm -rf .chrome-profile

クラウド側に行くなら、bbCLIの初期化が前提になる。

# Browserbase Functionsを初期化
bb functions init

動作モデル：Claude Code → Skill → bb CLI → Browserbase

Browserbase Skillsの全体構成は、次の4層スタックで理解するのが速い。

ポイントは2つある。

1. 同じスキル群がローカルChromeとBrowserbaseクラウドの両方で動く。検証はローカル、本番運用はクラウド、という移行が摩擦なく進む。
2. 永続コンテキストとオブザーバビリティ層が分離されている。Cookie・Storageはbbの永続コンテキストへ、トレース・DOM・スクリーンショットは.o11y/<run-id>/へ集約される。

「自然言語からブラウザ操作」だけなら他にも選択肢があるが、観測・再現性・クラウド実行まで揃ったスタックとして見るとBrowserbase Skillsの位置取りが理解しやすい。

browser-trace：失敗するUIを「事後解析」する

10スキルの中で特にユニークなのがbrowser-traceだ。読み取り専用のCDPクライアントとして既存ブラウザセッションにアタッチし、DevTools イベントの全量をNDJSONで記録、スクリーンショットとDOMスナップショットを並列でポーリングする。

browser-traceが自分でページを操作することはない。Playwright/Stagehand/その他のCDP互換ツールが操作した結果をただ観測する設計で、これが「Flakyテスト」の事後デバッグに効く。

# ローカルChrome（リモートデバッグポート9222）に対してキャプチャ
node scripts/start-capture.mjs 9222 my-run
# 別のターミナルで Playwright/Stagehand を実行...
node scripts/stop-capture.mjs my-run

# 結果をバケット別に分割（network / console / runtime / DOM）
node scripts/bisect-cdp.mjs my-run

Browserbaseリモートセッションに対してならこう。

node scripts/bb-capture.mjs --new my-run
# 自動化を実行...
node scripts/bb-finalize.mjs my-run --release

出力ディレクトリ.o11y/<run-id>/の構造はこうなっている。

.o11y/my-run/
├─ manifest.json        # 実行メタ情報
├─ cdp/
│  ├─ raw.ndjson        # 全DevToolsイベント（firehose）
│  └─ summary.json      # 集約済みスタッツ
├─ screenshots/         # タイムスタンプ付きPNG
├─ dom/                 # タイムスタンプ付きHTMLダンプ
├─ network.jsonl
├─ console.jsonl
└─ runtime.jsonl

「金曜の本番でだけ落ちるテスト」「特定のリクエストパターンでセレクタが切り替わるサイト」のような、再現が難しい不具合をフォレンジック的に解析できる。Claude Codeに「この失敗ランの.o11y/を見て、原因を3つに絞って」と頼めば、エージェントがバケット別ログを横断して仮説を出す、という運用が成立する。

ui-test：gitのdiffから敵対的UIテストを生成する

もう一つ目を引くのがui-testだ。gitのdiffを読んで「変わった部分だけ」をAIに敵対的テストさせる。フルアプリの探索モードもあるが、PRレベルの差分テストに使えるのが効く。

ユーザー: 「直近のコミットでチェックアウトページを変えた。ui-testで回して」

Claude Code: → git diff HEADでチェックアウト関連ファイルを抽出
            → 関連UIをBrowserbase経由でレンダリング
            → クーポン重複適用・住所未入力・カード番号異常値などの境界ケースを生成
            → 全結果を.o11y/にトレース付きで保存
            → 失敗を再現するPlaywrightスニペットを提案

QAエンジニアの「変更点を理解した上で意地悪な入力を投げる」作業を、AIエージェントが部分的に肩代わりする発想だ。adversarial（敵対的）を売りにしているのが正直なところで、開発者の盲点を突く例外系を作るのに向いている。

ブラウザ自動化エージェントとしての先行例だとOpenHands（コーディングエージェント）があるが、Browserbase Skillsは「Claude Codeにスキルとして差し込む」点で導入のハードルが格段に低い。既にClaude Codeを使っているチームなら、/plugin install browse@browserbaseを打つだけで明日からブラウザ自動化が現場に来る。

skills.sh：Open Agent Skills Ecosystemという新興レジストリ

browserbase/skillsの配布元の一つになっているskills.shは、Open Agent Skills Ecosystemを標榜する新興レジストリだ。npm / cargoのような感覚で、エージェント向けスキルをインストール／発見できる。

特定ベンダー（Claude / Cursor / Copilot）に閉じない、エージェント横断の標準配布レイヤーを狙っているのが意図として見える。Anthropic公式のスキル群もここに掲載されており、累計88K+のインストール実績が示されている。同様にスキル配布のレイヤーを整理する流れはAwesome Claude Skills（Composio提供のキュレーション）やgh skill：GitHub CLI公式のAgent Skillsコマンドでも観察でき、2026年は「スキルの流通レイヤー」が一気に整いつつある時期だ。

実例ワークフロー：3つのリアルなユースケース

公式READMEに掲載されている例を、実務寄りの形に展開して見ていく。いずれもClaude Codeに自然言語で指示するだけで動く前提だ。

例1：Hacker Newsのトップ議論を毎朝サマリ

ユーザー: 「Hacker Newsのトップ5記事のコメントを取得して、議論の論点を3つに要約。
         結果を docs/hn-digest/$(date +%Y-%m-%d).md に保存して」

Claude Code: → fetchスキルでHN APIから上位記事一覧
            → browserスキルで各記事ページとコメントスレッドを取得
            → コメントを論点別に分類（賛成・懸念・補足）
            → Markdownで整形して保存

fetchとbrowserをスキル間で連携させ、最終的にローカルのファイル書き込みまでClaudeが完了させる。Cron + GitHub Actionsで毎朝実行する仕掛けに乗せれば、「社内Slackに毎朝HNダイジェストが流れる」運用にすぐ繋がる。

例2：認証必須サイトの定期スクレイピング

# 1) ローカルChromeでログインを済ませた状態にする
browse env local --auto-connect

# 2) Cookie をBrowserbase永続コンテキストへ同期
# （Claude Code内で：「cookie-syncで現在のChromeセッションをコピーして」）

# 3) 以後はBrowserbaseクラウドから認証済み状態でアクセス可能

cookie-syncの役割は、「人間が手動でログインした状態」をクラウドに引き上げること。MFA・CAPTCHAで詰まりがちなログインフローを毎回自動化せずに、1回だけ人間が突破した状態を保存して以降は使い回す、という設計だ。

例3：PR時のUIリグレッションテスト

# GitHub Actions の例（概念）
on: pull_request
jobs:
  ui-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Browserbase UI Test
        run: |
          npx skills add browserbase/skills
          # Claude Code経由でui-testを実行
          claude "ui-testでこのPRの差分をテストして、結果をレポートに"
        env:
          BROWSERBASE_API_KEY: $

PRトリガでui-testを回し、変更箇所だけ敵対的なシナリオをぶつける。人間QAの一次フィルタを置き換える位置づけで、本格的なE2Eスイートと役割分担しながら使う形になる。

セキュリティと監査：Trust Hub・Socket・Snyk

skills.shに掲載されているスキルの中には、Trust Hub・Socket・Snykによる監査結果がバッジで表示されているものがある。browserbase/skillsもそのうちの1つで、Officialラベルと監査済みステータスが付与されている。

「スキルが任意コードを実行する性質」を考えると、これらの監査体制は重要だ。ローカルにインストールしたスキルはClaude Codeのプロセス権限で動くため、実質的にホストOS上の任意の操作が可能になる。skills.shの監査レイヤーは、このインストール時の信頼判定を補助する役割を果たす。

なお、サプライチェーン全体の防御戦略についてはサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストで別途整理しており、Skillsエコシステムも同じ視座で扱うべき領域だ。

実務での使い分け：fetch / search / browser を選ぶ基準

10スキルあるが、日常タスクで使うのはせいぜい3〜4種類になるはず。実務での選択指針を整理する。

「ブラウザを開かないで済むなら開かない」を原則に、fetch → search → browserの順で検討するのが運用コスト的に最もきれいに収まる。

SKILL.mdの中身：スキルが「ただのフォルダ」である意味

Browserbase Skillsの各スキルは、本質的には SKILL.md + 実行スクリプト が入ったフォルダだ。Claude Codeが起動時にこれを読み、自然言語のリクエストを内部スクリプトに翻訳する。browser-traceのSKILL.mdを概念的に見るとこういう構造になる。

---
name: browser-trace
description: |
  Capture a full DevTools-protocol trace alongside any browser
  automation, then bisect the stream into per-page searchable buckets.
allowed_tools:
  - Bash(node scripts/*.mjs)
  - Read(.o11y/**)
  - Write(.o11y/**)
keywords: [trace, debug, cdp, devtools, ndjson]
---

# browser-trace

## When to use this skill
- A browser automation is failing intermittently and you need to see
  network/console/DOM state at the moment of failure.
- You want to share a reproducible trace with a teammate or with Claude
  for joint analysis.

## Inputs
- Local Chrome at debugger port (default 9222)
- Browserbase remote session id (when using `bb-capture.mjs`)

## Output
- `.o11y/<run-id>/` directory with:
  - `manifest.json` — run metadata
  - `cdp/raw.ndjson` — full event stream
  - `screenshots/`, `dom/` — periodic samples

## Usage
1. Start capture with `node scripts/start-capture.mjs <port> <run-id>`
2. Run automation in another terminal/agent
3. Stop with `node scripts/stop-capture.mjs <run-id>`
4. Bisect with `node scripts/bisect-cdp.mjs <run-id>`

このシンプルさが、スキル文化の出発点だ。マニフェストでもなくPyPIでもなく、ただのフォルダにMarkdownとスクリプトを並べる——という設計だからこそ、誰でもフォークして自社版を作れる。SKILL.mdの構造についてはAnthropic公式の解説を読み解いたClaude Skillsを徹底解説：スキルはフォルダが下地になる。

CDPトレースの中身：NDJSONを読み解く

browser-traceが吐くraw.ndjsonは、文字通りDevToolsプロトコルの全イベントをJSON Lines形式で記録したものだ。Chromeの開発者ツールで見えている情報すべてがテキストとして残る、と理解すればいい。具体的にどんな行が並ぶかと言うと、

{"ts":1714370512.123,"method":"Network.requestWillBeSent","params":{"requestId":"39B","url":"https://example.com/api/login","method":"POST","headers":{"Content-Type":"application/json"},"postData":"{\"user\":\"alice\"}"}}
{"ts":1714370512.456,"method":"Network.responseReceived","params":{"requestId":"39B","response":{"status":401,"headers":{"WWW-Authenticate":"Bearer realm=app"}}}}
{"ts":1714370512.789,"method":"Runtime.consoleAPICalled","params":{"type":"error","args":[{"type":"string","value":"Login failed: 401"}]}}
{"ts":1714370513.012,"method":"DOM.documentUpdated"}
{"ts":1714370513.345,"method":"Page.frameNavigated","params":{"frame":{"url":"https://example.com/login?error=auth"}}}

このイベント列を bisect-cdp.mjs がバケット別ファイルに分割する。network.jsonl / console.jsonl / runtime.jsonl / dom.jsonl に切り分けられるので、Claudeに「console.jsonlのERRORレベルを時系列で並べて」と指示するだけで、エラー再現の時系列が手元に揃う。

# Claude Codeに直接投げる例
claude "browser-traceで取った.o11y/run-0429のconsole.jsonlからerrorレベルを抽出し、
        各エラーの直前1秒のnetworkリクエストと相関させてMarkdownレポートに"

「ログを集めて → AIに渡して → 仮説を並べさせて → 再現スニペットまで作る」という、SREでいうfailing-test-debug-loopが、ターミナル内で完結する。

Browserbase料金とコスト試算

クラウド側の料金感覚は導入判断で重要なので、執筆時点（2026年4月）の公開情報ベースで概算する。プランの正確な料金は公式サイトで確認してほしいが、運用設計の見通しを立てる目安にはなる。

具体的な試算を「PR時のui-testを毎日30回回す」でやると、

• 1テスト= ブラウザセッション3分（起動・操作・トレース）
• 30テスト/日 × 30日 = 900テスト
• 合計 ≈ 2,700分/月
• Hobbyプラン枠で十分収まる範囲

「Hacker News digest を毎朝スクレイピング」程度なら、毎日5分 × 30日 = 150分/月で、Free枠で完結する場合もある。最初は ローカルChrome + 月数十ドル枠で運用し、必要に応じて Scale 帯へ移るのが王道だ。

競合比較：Apify / Bright Data / ScrapingBee / Crawlee

ブラウザ自動化基盤の選択肢は、Browserbase以外にも複数ある。実務での選択肢を比較する。

「Claude Codeで自然言語からブラウザ自動化」という用途では、Browserbase Skillsが現時点で最も統合度が高い。Apifyは「スキルとしてActorを呼ぶ」変換層を自分で作れば近いことができるが、エコシステムとして整っているのはBrowserbaseだ。逆にコストを最小化したいならCrawleeを自前のサーバで動かすのが選択肢になる。

スクレイピングの法的論点：robots.txt と利用規約

便利すぎる道具は責任とセットになる。Browserbase Skillsで実務に使う前に、最低限おさえておきたい論点。

特に「Anti-Bot回避」は、技術的には Browserbase の機能で容易にできるが、回避自体が違法とされるケース（米国・CFAA関連訴訟など）がある。自社が所有・契約しているサイト、公共データ、規約上明確に許可されているサイトにスコープを絞るのが安全だ。

日本語サイトでの動作実績：CAPTCHA・MFA・Mojibakeとの戦い

日本語サイトで Browserbase Skills を使うと、英語サイトとは違う論点が出る。

「日本の銀行サイトにログインして残高を取得」のようなフローは技術的に可能だが、規約・法的リスクが大きいので、本番で動かすのは推奨しない。一方、「自社のWebサービスに対する E2Eテスト」「社内ポータルの定期チェック」「公開されている政府オープンデータの取得」のようなケースでは、日本語サイトでも安定して動かしやすい。

まとめ：Claude Codeに「現場のブラウザ業務」を持たせる

Browserbase Skillsは、概念としては地味だが効くタイプのリリースだ。

• 既存のClaude Codeユーザー → /plugin install browse@browserbaseでブラウザ業務がチャットの中に来る。
• QA/SRE視点 → browser-traceとui-testは本番の不具合解析・PR時テストに直接効く。
• エコシステム視点 → skills.shを介してマルチエージェント（Cursor / Copilot / Codex 等）にも持っていける。

クラウドサイドのbb料金が発生するスキル（browser、functions、browser-traceのリモート版）と、ローカルで完結するスキルが混在しているので、最初はローカルChromeで試して効果を見極めてからクラウドに行くのが王道だ。Browserbaseは無料枠も用意しており、PoCに対して敷居は低い。

1年後の予想：Browser Skills が引き起こす3つの変化

事実の整理から離れて、Browserbase SkillsとAgent Skills文化が今後1年で引き起こす変化を独自視点で3つ置く。

予想1：「ブラウザ自動化」がエンジニアの職能から外れる

これまで「Playwrightのスクリプトを書ける」「セレクタを長く保てる」がQAエンジニアの専門性だった。Skillsの登場で、自然言語の指示だけでブラウザ自動化が動く領域が広がり、職能の境界が引き直される。逆にQAエンジニアはAIエージェントを設計・運用する側に回ることが評価軸になりそうだ。

予想2：「監査済みスキル」がOSS版App Storeになる

skills.shに並ぶTrust Hub・Socket・Snyk監査スタンプは、「誰が書いたか不明なスクリプトを動かす不安」を解消する仕掛けだ。1年後にはこれが監査スキル数 vs 全スキル数で品質を競う段階になり、OSSの中央レジストリ＋第三者監査が業界標準のディストリビューション形態になる可能性が高い。

予想3：「ブラウザはAIが操作する第一の道具」になる

過去20年「APIで取れないものはWebスクレイピング」という発想だった。Skillsの広がりで、「APIがある場合でもブラウザで操作する」逆転が起こる。AIエージェントにとって、APIスキーマを学ぶよりブラウザを操作するほうが学習コストが低いためだ。1年後にはAPI設計の優先度が下がり、UI設計が「AIが操作しやすいか」も評価軸に加わる、というシナリオがあり得る。

FAQ

Q. Claude Code以外のエージェントでも使えますか？

A. はい。skills.shレジストリ経由で npx skills add browserbase/skills を実行すれば、Cursor、GitHub Copilot、Gemini CLI、OpenAI Codex 等20+のエージェントに対応します。Claude Code向けには専用に /plugin marketplace add browserbase/skills ルートも用意されています。

Q. Browserbaseのクラウド契約は必須ですか？

A. 必須ではありません。browser、fetch、search、browser-traceはローカルChromeでも動作します。functions、cookie-sync、bb-usage等はBrowserbaseクラウドが前提です。料金体系はBrowserbase側のドキュメントを確認してください（執筆時点で無料枠があります）。

Q. PlaywrightやStagehandを既に使っています。乗り換えるべきですか？

A. 乗り換えではなく併用が現実的です。browser-traceはPlaywright/Stagehandの上に観測層を載せる位置づけで、既存のテストコードを残したままトレースだけ取れます。ui-testは新規にPlaywrightスニペットを生成するので、既存資産との接続は段階的に進められます。

Q. ui-testはどこまで「敵対的」ですか？

A. 公式の文言は “AI-powered adversarial UI testing” で、gitのdiff部分にフォーカスし、境界値・異常入力・順序入れ替えなどのケースを自動生成すると説明されています。完全な侵入テストではなく、プロダクトQAの自動化が想定されています。Burp Suite等の代替ではない点に注意してください。

Q. browser-traceが取得した.o11y/は機密情報を含みますか？

A. 含みます。 ネットワークペイロード、Cookie、認証ヘッダー、DOM内のユーザーデータなどがNDJSONに記録されるため、.o11y/をそのままGit管理しないでください。.gitignoreに追加し、共有が必要な場合はPII（個人情報）をマスクしてから扱うのが安全です。

Q. 既にBrowserbaseのMCPサーバを別途使っています。重複しますか？

A. Browserbase MCP は「MCP経由でブラウザ操作APIを公開する」もので、browserbase/skillsは「Claude Codeのスキルとしてラップする」ものです。両方ローンチされた経緯から、用途が分かれています——MCPは他LLM横断のサーバ、スキルはClaude Code向けのワークフロー集。今のところ併存可能です。

Q. サンドボックス内で実行されますか？任意コード実行のリスクは？

A. スキル自体はClaude Codeのプロセス権限で動作します。Browserbase Skillsの場合、scripts/配下のNodeスクリプトを実行するため、ローカル環境でファイルアクセス・ネットワークアクセスが可能な状態になります。Claude Codeのallowed_tools設定で実行可能なBashコマンドを絞り込むか、Sandboxモードを有効化して動かすのが安全です。Claude Codeのサンドボックス機能の詳細は公式ドキュメントを確認してください。

Q. スキルのアップデートはどう管理しますか？

A. npx skills add browserbase/skills を実行すると最新版が取得されます。バージョン固定したい場合は、特定のコミットハッシュを指定してインストールできます（npx skills add browserbase/skills#<commit>）。本番環境では特定のリリースタグを固定しておくのが運用上安全です。

Q. 自社向けのカスタムスキルも同じ形式で書けますか？

A. はい。SKILL.md+ スクリプトのフォルダを作って npx skills add <自社GitHub URL> でインストールできます。社内の独自業務（在庫システムへの自動アクセス、社内Wikiの更新等）をスキル化すれば、Claude Codeの能力をそのまま自社業務に適用できます。社内専用スキルはプライベートリポジトリで配布するのが現実的です。

Q. 並列実行で何セッションまで使えますか？

A. ローカルChromeの場合はマシンリソース次第（一般的なノートPCで4〜8セッション程度）。Browserbaseクラウドはプランごとに同時セッション数の上限があり、HobbyやStartupプランは数〜数十並列、Enterpriseはカスタム交渉です。browser-traceの併用は1セッション当たりのストレージとCPU使用量を増やす点に注意してください。

Q. WindowsでもBrowserbase Skillsは動きますか？

A. Claude CodeがWindows対応していれば動作します。ローカルChromeを使うスキル（browser、cookie-sync）はWSL2上で動かすのが安定します。クラウド側スキル（functions、bb-usage）はOSに依存しないため、Windowsからも問題なく利用できます。

Q. ロギングと監視はどう設計すべきですか？

A. クラウド側はbb-usageスキルで利用量を可視化できます。ローカル側は .o11y/<run-id>/ 配下のNDJSON・スクリーンショット・DOMダンプが事実上のログ集積点になります。本番運用では、.o11y/をS3等のオブジェクトストレージに定期アップロードし、保管期間（30〜90日）を決めて運用するのが定石です。Datadog/New Relic等のAPMにも、CDPトレースのnetwork.jsonlを取り込めばAPIコール失敗の事後解析が桁違いに楽になります。

参照ソース

• browserbase/skills — GitHub
• browser-trace skill on skills.sh
• skills.sh — Open Agent Skills Ecosystem
• Browserbase 公式サイト