Chrome DevTools MCP に最近触れていて、衝撃を受けています。
Chrome DevTools MCP は、Claude Code などの MCP クライアントから Chrome DevTools Protocol(CDP) を通してブラウザを操作する仕組みです。ざっくり言えば、「AI に、普段使っている Chrome をそのまま操作させるためのインタフェース」です。従来の Selenium や Puppeteer のように大量の操作コードを書くのではなく、「このボタンを押して」「CSV をダウンロードして」と自然言語で指示できるのが特徴です。
過去にクローラー本を書いてきた人間として言うと、人類が「プログラムにやってほしかったこと」がかなり自然に実現できる時代になった、という感覚があります。HTML 要素を 1 つずつ調べてセレクタを書く、という作業を延々やらなくて済みます。10 年前、Ruby でクローラー/スクレイピングをやっていて、多少長く見てきました。著者名義で最初に出した商業誌も、AWS の本ではありません。実はクローラー本で、『Rubyによるクローラー開発技法』(2014 年)を書きました。当時は対象サイトの DOM 構造を眺めて CSS セレクタを当て、ログインの POST を再現し、Cookie を保持し、レンダリング時間を sleep で待つ、という地味な作業の繰り返しでした。
その後 Selenium、Puppeteer、Playwright と進化してきましたが、本質は変わっていません。「ログイン状態の Chrome を、人間に代わって動かしたい」という要件には、毎回それなりの工数がかかっていました。
それが Chrome DevTools MCP で根本から変わりました。具体例と運用の知見を、その間にあった「もう一段階」も含めて整理しておきたいと思います。
プログラミングと MCP の間にあった SaaS スクレイピング
「コードを書かずに、ブラウザで対象ページを指定すればスクレイピングできる」という SaaS が 2010 年代に複数登場しました。代表例が KimonoLabs(2014 年創業、Y Combinator 出身)です。Chrome 拡張で対象サイトの欲しい要素をクリックすると、API として叩けるエンドポイントを発行してくれる、という建付けでした。当時はかなり盛り上がって、自分も試した記憶があります。
KimonoLabs は 2016 年に Palantir に買収されてサービス終了しました。同時期に並走していた代表的なサービスを並べると、「決定版が出なかった」という構造が見えやすくなります。
- import.io(2012 年〜): 現存。今は「AI-Native Web Data Extraction Platform」を名乗る企業向け路線
- ParseHub: 現存。Visual point-and-click 系、月 189〜599 ドルのサブスク
- Apify(2015 年〜): 現存、Prague 拠点、開発者向けマーケットプレイス路線
- Scrapinghub(2010 年〜): 2021 年に Zyte に改名、エンタープライズ寄りに軸足を移した
他にも Octoparse、Mozenda、80legs などが並走していましたが、上の 4 社で大筋の流れは見えます。存続している会社は多いです。ですが、誰もが知るスクレイピングサービスの決定版は出ていません。大きく 3 パターンに収束しました。一つはエンタープライズ向け契約に逃げる路線(Zyte、import.io)。一つは Visual builder のニッチで小さく続ける路線(ParseHub)。もう一つは開発者向け基盤に振り切る路線(Apify)です。
決定版が出なかった理由は構造的です。スクレイピング SaaS は対象サイト側から見ると、利用規約違反になりうる領域です(robots.txt の解釈、レート制限、認証越え)。サービス提供者がスケールするほど対象サイトとの摩擦が増えます。法務・倫理面の不確実性が事業継続のリスクになります。結果として「コードレスで誰でもスクレイピング」というマス向けの展開は実現しませんでした。
ここに Chrome DevTools MCP が出てきた、という時系列で見ると意味が違って見えてきます。
Chrome DevTools MCP がやってくれること
公式は chrome-devtools-mcp です。Claude Code などの MCP クライアントから「Chrome の DevTools プロトコル」越しにブラウザを操作するサーバで、Puppeteer をバックエンドにしています。
何が革命的かというと、次のような点です。
- DOM スナップショット(aria/role 付き)が取れる。Claude が「メニューの『売上CSV』をクリック」を文字情報として理解できる
- セレクタを書かなくていい。「『発行する』ボタンを押して」で通る
- ログイン状態は Chrome プロファイルに委ねる。MCP 側はパスワード管理ロジックを一切持たない
- ダウンロードリンクを押した後、保存先を固定してファイル出現を待たせられる
- Headless / Headed を切り替えられる(CAPTCHA や追加確認が出たときに人間が確認しやすいので headed が扱いやすい)
書き方が変わります。Selenium ならコードだったところが、Claude へのプロンプト(スラッシュコマンド)になります。それでだいたい動きます。
そして KimonoLabs のような SaaS スクレイピングと違って、Chrome MCP はユーザの手元の Chrome を動かすだけです。中央集権型サービスが対象サイトとの摩擦を抱える構造ではありません。各ユーザが自分のブラウザで自分のアカウントの管理画面を操作するだけなので、サービス提供者がスケールしてバンされる、という事態は起きにくいです。第二幕の SaaS スクレイピングが解決できなかった事業継続性の問題を、構造的に回避しています。
実用例: BOOTH と Kindle ダイレクトパブリッシングの売上を自動取得する
私のリポジトリには `/fetch-booth` と `/fetch-kdp` という Claude Code のスラッシュコマンドを置いています。やっていることは次のような流れです。
`/fetch-booth` の場合:
- `https://manage.booth.pm/orders` に遷移
- 注文一覧のスナップショットを取る
- 既存 CSV の mtime と最新注文日時を比較(鮮度チェック)
- 必要なら売上 CSV 発行画面に遷移して、期間指定 → 「発行する」をクリック → ダウンロード待ち
- ダウンロードフォルダに落ちた CSV を `analytics/raw/booth/` に配置
`/fetch-kdp` の場合:
- KDP のログイン状態を確認(2 段階認証を要求されたら中断してユーザに依頼)
- レポート画面で Orders と KENP Read を順に発行 → ダウンロード
- xlsx をパースして JSONL(共通スキーマ)に変換
これを Selenium で書いていたら、要素セレクタを当てて、ログインの維持を確認して、ダウンロードイベントの待機を自前で書いて、というコードが数百行はかかります。さらに UI 改修があるたびに直す必要があります。
Chrome MCP では、コマンド定義が Markdown で 70〜80 行程度です( `/fetch-booth` が 79 行、`/fetch-kdp` が 71 行)。Claude が毎回スナップショットを取って判断するので、UI が少し変わっても通ります。根本的な構造変更があれば指示文を直しますが、その粒度は Selenium のセレクタ修正よりはるかに楽です。再実装の保守コストが激減します。
ポイントは、CSV 発行枠に「BOOTH は 30/日」のような制限があるところです。鮮度チェックを入れて無駄打ちしないという判断を、Claude にスナップショットを読ませて任せられます。これは Selenium 自前実装でも書けますが、Claude の判断委譲のほうが運用が楽です。
認証は Chrome 側に委ねる。ただしセッションは強い権限であることを留意する
セキュリティ観点で気になるのは「Claude にパスワードや 2FA コードを渡したくない」という点です。Chrome MCP では、少なくとも Claude にパスワードや 2FA コードを入力させずに運用できます。ただし、ログイン済み Cookie / セッションを使って操作するため、認証リスクが消えるわけではありません。
ログインは事前に手動でプロファイルを作るときに 1 回だけ実施します。以降は Chrome プロファイルに保存された Cookie やセッションがそのまま使われます。Claude にパスワードを入力させる必要はありません。
ただし注意点として、MCP クライアント側はブラウザの内容を inspect/modify できる立場にあります。公式 README でも、ログイン済み画面の DOM や Cookie・localStorage に保存されたトークン類は MCP 経由で読み取りうることが明記されています。だからこそ「専用プロファイルを切る」「読み取り中心の運用に限定する」「他サービスのログインを混ぜない」という運用ルールが効いてきます。パスワードを直接渡さない、というのはあくまで一段目の防御です。
2FA や OTP、CAPTCHA が要求されたら、Claude は中断してユーザに依頼する設計にしておきます。`/fetch-booth` と `/fetch-kdp` はこの方針です。課金確定アクション(決済実行や広告出稿など)はやらせません。読み取り中心の運用で十分元が取れます。
「パスワードを AI に直接渡さない」運用にし、専用プロファイルでアクセス範囲を絞れば、リスクは局所化できます。ただし、Cookie / セッションは MCP クライアント側から読み取りうる状態なので、サイト側が再認証を要求しない操作については、実質的にパスワードを渡しているのに近い権限委譲になります。リスクを理解した上で、何を許すかは利用者側でしっかり考える必要があります。
ちょっとした詰まりどころ: MCP 専用 Chrome プロファイルを用意する
完全にスムーズというわけではありません。運用上のコツとしては、MCP 専用の Chrome プロファイルを用意するのがおすすめです。普段使いの Chrome と同じプロファイルで MCP を動かそうとすると、Cookie の暗号化や同時起動の扱いで混乱しやすく、ログインが消えたように見えるトラブルにつながります。専用プロファイルを切っておけば、ログイン状態の保持も判断もシンプルになります。
具体的には、Chrome MCP の専用プロファイルは `--use-mock-keychain` フラグ付きで起動されます(Puppeteer の既定)。手で同じプロファイルから Chrome を立ち上げるときも、同じフラグを付けないと Cookie の暗号化キーが食い違って、ログインが消えたように見えてしまいます。
なお、このフラグは利便性のためのものですが、OS のキーチェーン保護とは別の鍵管理になるため、ローカルマシン上の攻撃面は増える可能性があります。専用プロファイルに他サービスを混ぜない理由もここにあります。
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --user-data-dir="$HOME/.chrome-mcp-profile" \ --use-mock-keychain
このフラグ付き起動でしかアクセスしない、というのが運用ルールです。詰まりどころというより、最初に決めてしまえば困らない範囲です。
これから試したいこと
`/fetch-booth` と `/fetch-kdp` の次に、同じ仕組みで広げたい用途がいくつかあります。
- OGP 監査(各 URL の OGP 画像と meta タグを一括チェック)
- UTM の e2e テスト(BOOTH 商品ページから GA4 へ送られる内容の検証)
- BOOTH 商品ページの棚卸し(価格・在庫・カバー画像の整合性)
- ブログ記事の Web Vitals 計測(Lighthouse 連携)
すべて「ログイン後画面とブラウザの状態を読みたい」用途で、Selenium で書いたら結構な工数ですが、Chrome MCP なら数十行のコマンド定義で済む見込みです。優先順位は ROI 順で、OGP 監査からと考えています。
まとめ
Chrome DevTools MCP は凄いです。人類が「プログラムにやってほしかったこと」がかなり自然に実現できる時代になっている、というのが正直な感想です。
10 年前にクローラー本を書いた身として、要素セレクタを当ててログインを維持して、というあの労力が「Claude にスナップショットを渡して指示」で済むようになったのは衝撃でした。途中の SaaS スクレイピングは事業構造の問題で決定版が出ませんでしたが、Chrome MCP はユーザの手元の Chrome を動かすだけなので、その問題を構造的に回避しています。
上手く使えば、恩恵はかなり大きいと思います。読み取り中心の管理画面操作なら、まず試してみる価値があります。「パスワードを AI に直接渡さない」運用にし、専用プロファイルでアクセス範囲を絞れば、リスクは局所化できます。ただし、Cookie / セッションは MCP クライアント側から読み取りうる状態なので、サイト側が再認証を要求しない操作については、実質的にパスワードを渡しているのに近い権限委譲になります。
最近は、Claudeを中心にAIの使い方についても、いろいろ考えています。よければ、気軽にTwitter(@dkfj）をフォローしてください。
