Claude CodeからブラウザのChatGPT Proに質問を投げるChrome拡張ブリッジを作った

開発claude-code-tools

「多分ないと思います」と半ば答えを決めつけながら投げた調べ物が、その日のうちにブラウザのChatGPT Proへ質問を投げ込む橋になって返ってきた。今日のメインはこれ。ほかにも細かい運用ネタをまとめて片付けた一日だった。

  • Claude CodeからブラウザのChatGPT Proに質問を投げるChrome拡張ブリッジを作らせた（本題）
  • 膨らみきったClaude Codeのセッション履歴をUSBへ退避して、ローカルを軽くした
  • 朝イチで昨日の積み残しを計画書と実物の突き合わせで確認し、消化してクローズした
  • 運営サイトの収益化パターンを調べてもらい、非公開記事として保存した

ChatGPT Proへの橋を架ける

発端: Proはブラウザ専用に見える

ChatGPTのプランのうち、いちばん重いリーズニングをするProは、codex CLIのモデル選択には出てこない。CLI側で選べるのはシンキングの強度（最速・標準・高・最高）までで、Proはブラウザの chatgpt.com のUIにしか現れない。だから「codexからProにアクセスする方法はないと思うんですけど、一応調べてほしいです。多分ないと思います」と、ブラウザのスクリーンショットを貼ってClaude Codeに投げた。

返ってきたのは「codexからは無理」という確認だけではなく、「ならブラウザのProに横から質問を投げればいい」という迂回路だった。

作らせたのは「ページ側の操作口」だけ

調査と現状確認を並行で進めさせたあと、組み上がった構成はこうだった。

  • 通信路: すでに接続済みだった Chrome DevTools MCP をそのまま使う。新しくは何も作らない
  • 操作口: chatgpt.com のページ側に window.__gptBridge という固定のAPIを生やす、小さなChrome拡張を新規に作る

最初は「Chrome DevTools自体を作ってくれたのか？」と勘違いして聞いてしまったが、DevTools MCPは既存の道をそのまま使っていて、新規に書かせたのはページ側の窓口だけだった。DevTools経由でページのJSを叩くとき、毎回DOMのセレクタを探り直すと画面変更のたびに壊れる。window.__gptBridge という名前付きの入口を拡張で固定しておけば、Claude Code側は常に同じ関数を呼ぶだけで済む。この拡張は chrome-extension-chatgpt-pro というリポジトリに切り出して、コミットとGitHubへのpushまで済ませた。

経路の全体像はこうなる。

  1. Claude Code が Chrome DevTools MCP 経由でブラウザに命令を送る
  2. chatgpt.com のページ上で、拡張が生やした window.__gptBridge を呼ぶ
  3. ブリッジが質問をChatGPTのUIに流し込み、モデル（Pro含む）が回答を生成する
  4. 回答をブリッジ経由で回収して、Claude Code側に持ち帰る

疎通テスト→Pro本番テストの2段構え

テストの順番に工夫があった。まずシンキング「最速」で疎通テストを通す。Proのクォータは有限なので、「橋が架かっているか」の確認に高いモードを使わない。ブリッジの注入が成功し、最速モードで質問と回答が往復することを確かめてから、Proに切り替えて本番テストを流した。ブラウザのProが返した回答がClaude Code側に戻ってくるところまで確認して、全工程完了。

これで「Proで壁打ちしたい重い問いだけブラウザに投げ、結果を手元のセッションに回収する」という使い方が、手作業のコピペなしで回るようになった。

内部API直叩きと比べてどうだったか

あとから「拡張機能以外に、内部APIを直接叩くようなアプローチはなかったのか」と聞いてみた。答えは、比較したうえで拡張機能方式のほうが良い選択だった、という整理。ログイン済みブラウザの正規UIをそのまま通すので、認証まわりを一切動かさずに済むのがこの方式の利点だと理解した。ブラウザの外に何かを持ち出した瞬間に、認証・セッション管理・仕様変更への追従が全部自分の負債になる。ページに窓口を1枚足すだけの構成は、そのどれも背負わない。

セッション履歴2,601件をUSBへ退避

Claude Codeのセッション履歴がローカルで3.4GBまで膨らんでいた。以前登録しておいた session-backup スキルを起動させて、2026-05-30〜07-05分の2,601件・1.74GBをUSB（Fドライブ）へ退避した。

手順はスキルに固定してある堅牢版で進めさせた。

  • tar.gz圧縮版（0.81GB）と、すぐ開ける展開フォルダの二重でFドライブに置く
  • 件数照合で2,601件の一致を確かめる
  • 照合が通ってから、1ヶ月超の古いセッションをローカルから削除する

結果、ローカルは3.4GBから2.1GBまで軽くなった。消したあとに「照合していなかった」と青ざめるのが最悪のパターンなので、圧縮→展開→照合→削除の順番を崩さないことだけ守らせた。

朝イチの積み残し確認

朝、eurekapu-nuxt4側で「昨日の積み残しが何かあったはず」と、直近3日の計画書（memoディレクトリ）と実際のディスク状態を突き合わせて確認させた。記憶では「もしかしたら終わっているかもしれない」だったが、突き合わせたら未消化が1件残っていた。スキルをコンテンツ（講座）化した件で、スキル側にスクリプトの実体が入っていなかったという昨日の課題の続きだ。

その場で消化まで進めた。スクリプトの所在確認（実装本体がリポジトリに入り、講座の新セクションが実際にその関数を呼んで描画されている状態）、devサーバーでの表示確認（モバイル375px幅でのはみ出しチェックまで）、計画書のチェックボックスとステータス行の更新まで通して、完了扱いにした。本番デプロイだけは保留。静的生成サイトなのでコミットしただけでは本番に1バイトも反映されないが、裏を返せば公開したくなるまで安全に寝かせておける。

運営サイトの収益化パターンを非公開記事に

運営しているサイトの収益化パターン——成果報酬が何への成果として発生するのか——をWeb検索の並列調査で洗い出してもらった。結果は公開記事ではなく、unpublished: true フラグ付きの非公開記事として保存。非公開一覧には載り、公開側のブログ一覧には出ないことをdev環境の描画で確認して締めた。調査メモは自分が読み返せればいいので、この置き場がいちばん収まりがいい。

今日の学び

  • ブラウザ専用に見える機能でも、「通信路（既存のChrome DevTools MCP）」と「ページ側の操作口（Chrome拡張）」を分けて考えると、意外と短い橋で届く
  • テストは安いモードで疎通→高いモードで本番の2段にすると、有限のクォータを溶かさずに済む
  • 「多分ない」と決めつけて投げた調べ物が、経路になって返ってきた。不可能の断定は調べてからでいい
  • 記憶の「終わったかもしれない」は当てにならない。計画書とディスク上の実物を突き合わせて白黒つける