browser-to-api — サイトを CDP トレースから OpenAPI 化する Browserbase スキル
> TL;DR (EN): browser-to-api is a Browserbase agent skill that turns any website into a documented API. It does not crawl or capture traffic itself — it post-processes a browser-trace capture offline: it pairs Chrome DevTools Protocol (CDP) request/response events, templatises observed URLs, infers JSON schemas from samples, and emits an OpenAPI 3.1 spec plus a coverage report and a ready-to-use client. Pair it with the browser-trace skill (capture) → browser-to-api (synthesise). It is how Codex one-shotted a fully documented OpenTable API client from a single prompt.
きっかけは @derekmeegan(Browserbase のエンジニア)の 2026-05-14 の投稿。「/browser-to-api で任意のサイトを API に変える。Codex が単一プロンプトで OpenTable の API クライアントを一発生成する様子」を見せ、711K views を集めていた。中身を一次情報で整理しておく。
何をするものか
未公開・非公式の Web API を、ブラウザ操作の記録から逆算して OpenAPI 仕様に起こす agent skill。Browserbase の公式スキル集 browserbase/skills の一つで、Claude Code / Codex / Cursor などのコーディングエージェントから呼び出せる。
重要な前提:このスキル自体はトラフィックを取得しない。 あくまで browser-trace が取った CDP ネットワークログに対するオフラインの後処理。だから「実行 = 副作用なし・決定的」で安全に回せる。
パイプライン(2スキル構成)
browser-trace(捕捉)— ブラウザ自動化中に DevTools プロトコルのトレース(CDP firehose、スクリーンショット、DOM ダンプ)を丸ごと記録する。出力は.o11y/<run>/cdp/network/{requests,responses}.jsonl。browser-to-api(合成)— 上記 jsonl を読み、- CDP の request / response イベントをペアリング
- 観測した URL をテンプレート化(
/users/123→/users/{id}のように動的部分を変数化) - サンプルから JSON スキーマを推論
- OpenAPI 3.1 ドキュメント+人間可読の coverage report を出力
生成物
.o11y/<run>/api-spec/index.html— ドキュメントopenapi.yaml— OpenAPI 3.1 仕様本体client.mjs— そのまま叩けるクライアントモジュール
使いどころ
- サードパーティ/ドキュメントのない Web API に対し、正式な OpenAPI スペックが欲しい
- 既存のブラウザ自動化の記録から、エンドポイントとスキーマを抽出したい
- 仕様を公開していないサイト相手に、クライアント/SDK を起こしたい
インストール・呼び出し
npx skills add browserbase/skills
Claude Code なら /plugin でマーケットプレイスを追加 → browse プラグインを入れ、自然言語で依頼する。エージェント文脈では /browser-to-api のようにスキルを直接呼ぶ。
周辺・類似(位置づけの整理)
- AndrewWalsh/openapi-devtools — 任意のアプリ/サイトの API スペックを生成するブラウザ拡張。手動・ローカル版の発想が近い先行事例。
- Browserbase Stagehand — OpenAPI スペック/SDK 生成の機能を持つ。Browserbase 内の関連系譜。
- browse.sh — Browserbase が公開する「browser skills のカタログ」。
browser-to-apiはこのエコシステムの一部。 - 自分の既存ノート Browser Automation MCP 2026 はブラウザ自動化の「操作」側。
browser-to-apiは「記録 → 仕様化」側で、レイヤーが違う。
所感
「サイトを API 化する」という発想自体は openapi-devtools 等で既出だが、エージェントのスキルとして決定的・オフラインで合成まで完結させ、browser-trace と分業させた設計が筋がいい。捕捉(副作用あり)と合成(副作用なし)を分けることで、後処理を何度でも安全に回せる。GEO/スクレイピングの文脈でも、対象サイトの API 構造を素早く把握する偵察ツールとして効く。
参考・引用元
- browser-to-api — browserbase/skills (skills.sh) — サイト(Browserbase 公式スキルカタログ)
- browserbase/skills (GitHub) — リポジトリ(Browserbase 公式)
- Skills — Browserbase Documentation — ドキュメント(Browserbase)
- @derekmeegan の投稿(2026-05-14) — ポスト(Derek Meegan / Browserbase)。本ノートの発端
- AndrewWalsh/openapi-devtools (GitHub) — リポジトリ(類似の先行事例)
- browse.sh, a catalog of browser skills | Browserbase — ブログ(Browserbase)