ブラウザ自動化MCPを自作した話 — 制作日誌 #2

前回 はこのブログ自体の制作話を書いた。今回は、その制作の中で自作することになったブラウザ自動化 MCP サーバーの話。

MCP（Model Context Protocol）は Anthropic が公式に出している「AI に外部ツールを使わせる」ための共通プロトコル。

ブラウザ自動化については、最近 Anthropic が Claude Chrome 拡張 を出していて、これは普段使いの Chrome に直接インストールして使う。ログイン済みの状態をそのまま引き継いで操作してくれる、よく出来た製品だ。

ただ、自分の用途には合わなかった。なぜなのか、どう自作したのかを書く。

公式 Chrome 拡張がフィットしなかった理由

1. 動かせる場所が「claude.ai のチャット UI 内」に限定される

公式 Chrome 拡張は、claude.ai のチャットインターフェイスから呼び出すツール。とても便利だが、

• Claude Code CLI からは呼び出せない
• ローカルで走らせている別のスクリプト・cron ジョブ・自作エージェントからも呼び出せない
• 「AI に PC 全体を操作してもらう」ような統合的なフローに組み込めない

自分が作りたかったのは「朝のルーチンを Claude Code に丸投げする」「夜に走る自動化ジョブの一部としてブラウザ操作を含める」みたいな、バックエンド側からブラウザを動かす用途。Chrome 拡張だと、人間がチャットに入力するという「フロント側からの起動」しかない。

2. ローカルファイルとの行き来が薄い

業務自動化の現場では、**「ブラウザで何か入力 → ファイルを取り出す → ローカルで加工 → 別のブラウザに入れる」**みたいな鎖がよく出てくる。これを Chrome 拡張で完結させるのは厳しい。AI 側の「ファイルシステムを触る MCP」と「ブラウザを触る Chrome 拡張」のレイヤーが分断しているからだ。

ローカル側に閉じた MCP として両方を出した方が、AI が一連の流れとして扱える。

3. Microsoft の Playwright MCP は別物として使い分けたい

ブラウザ自動化 MCP では Microsoft 提供の Playwright MCP が事実上のスタンダードで、これも良くできている。実際このブログでも別用途で使っている。

ただ Playwright は基本的に毎回フレッシュな Chromium インスタンスを起動する前提のツール。これはこれで「テスト目的」「クロール目的」には正しいのだけど、

• 普段使いのアカウントセッションが使えない
• 拡張機能（パスワードマネージャ、検索補助、業務系ツール）が使えない
• 結果として、ログイン状態でしか操作できないサービスを触れない

要するに、用途で分かれる。

使い分けの整理

• Playwright MCP: ログイン不要なクロール、定型サイトのテスト自動化
• 自作 MCP: 普段ログインしているアカウントセッションを使いたい用途
• 公式 Chrome 拡張: claude.ai 内で手早くブラウザ作業を頼みたいとき

k-chrome の設計 — 既存プロファイルをそのまま使う

設計は最小限。普段使っている Chrome を --remote-debugging-port 付きで起動するだけ。

chrome.exe --remote-debugging-port=9222 \
  --user-data-dir="C:\path\to\my-real-profile"

これで、自分の普段のブラウザが Chrome DevTools Protocol（CDP）経由で操作可能になる。MCP サーバーから localhost:9222 の WebSocket に接続して、Page.navigate Runtime.evaluate Input.dispatchMouseEvent を必要なだけ叩く。

このアプローチの何が良いかと言うと、

• 普段使っているアカウントセッションがそのまま使える（Google、各種 SaaS、業務ツール、何でも）
• 2要素認証は事前に1回だけ済ませておけば、それ以降は不要（セッションが残るため）
• 拡張機能も生きている

特殊なことはしていない。ただ、AI から「自分のブラウザ」を触れる窓口を1個開けただけ。

提供している MCP ツール

k-chrome として AI 側に公開しているのは、最小限のセット:

• navigate — URL に移動
• get_content — テキスト or HTML 取得
• evaluate — 任意の JavaScript を実行して結果を返す
• click — セレクタ or 座標でクリック
• type_text / fill_form — 入力
• scroll / press_key — 補助操作
• screenshot — スクリーンショット
• set_file_input — <input type="file"> にローカルファイルを投入
• list_tabs / new_tab / close_tab — タブ管理

「人間が普段使ってる操作の最小公倍数」をそのまま並べただけ。

特に効くのは evaluate。AI が DOM を観察したあと「この button.btn-primary をクリック」みたいに具体的なセレクタを生成してくれるので、座標クリックよりも安定して動く。ボタン位置が変わっても壊れにくい。

詰まりどころと回避策

1ヶ月運用して見えてきたコツ。

1. 同じ操作が2回続いたら Playwright 化する

ブラウザ自動化 MCP は便利だが、毎回 AI に DOM を観察させて操作させるのはトークンを食う。同じサイトで同じ手順を週次・日次で繰り返すなら、Playwright スクリプトに落とすのが正解。

その判断のために、CLAUDE.md には「繰り返す k-chrome 操作は Playwright 化（明示依頼なしでも提案）」とルールを書いてある。これにより AI 側から「これは Playwright に落としませんか？」と提案してくれる。

2. DOM 観察はトークン重い

get_content で HTML 丸ごと取ると数千トークンを消費する。大事なのは、「最初に1回観察 → セレクタを取得 → 以後は evaluate だけで完結させる」運用に倒すこと。

3. セッションの寿命

普段使いのブラウザでも、サービスによってはセッションが数日〜数週間で切れる。切れたら AI 操作の途中で「ログイン画面に飛ばされる」事態になる。これに備えて、各タスクの先頭に「現在ログイン状態か確認」のステップを入れておくと事故が減る。

学んだこと

このプロジェクトで掴んだ大事な感覚は、**「公式と自作は競合しない」**ということ。

• 公式 Chrome 拡張は claude.ai でサッと使いたいときに最強
• Playwright MCP は テスト・クロール・ヘッドレス用途に最強
• 自作 k-chrome は 既存セッションを Claude Code から扱いたい用途に必要

3つ全部入れて、用途に応じてどれを呼ぶか AI に選ばせている。

つまり公式の制約は妥協ではなく設計判断で、自分の用途と噛み合わないだけ。自作 MCP の意義は「公式が想定していない用途を埋める」ことにある。

次回予告

次回は 「Gmail 周りの自作 MCP の話」。公式や third-party 連携でも Gmail は扱えるが、「ローカルで完結させたい」「OAuth トークンを自分で握りたい」という個人開発者の要望を、自作でどう解決したか。

まとめ

• 公式 Claude Chrome 拡張は良くできているが、claude.ai の中でしか動かせない
• バックエンドや Claude Code CLI から触りたいなら、別の MCP が要る
• Playwright MCP は テスト・クロール用途 に向く
• 自作 k-chrome は 既存ログイン済みプロファイルを CDP 経由で使う仕組み
• 公式と自作は競合せず、用途で使い分けが正解

第3回 → Gmail 周りの自作 MCP | 第1回 ブログ立ち上げ記