😇

Claude in Chromeが便利すぎて不満だったので、自分専用のChrome拡張を作った

に公開2

はじめに

最近、Claude in ChromeというChrome拡張をよく使っている。

ブラウザ上で調べ物をしながらAIに質問したり、記事を要約させたり、ちょっとしたブラウザ操作を頼んだり。大抵のことはこれでできてしまう。正直、ものすごく便利だ。

ただ一つ不満がある。AIモデルがClaudeしか使えない。

Claudeのサブスクは持っているが、コーディングにも使うのでトークンの消費が激しい。Weekly Limitの到達が早い。現在最強のAIモデルだということは承知しているが、正直なところ、ブラウザ作業くらいは安いモデルで済ませたい場面がほとんどだ。

そこでふと思った。

自分専用のChrome拡張を作れば、好きなモデルを使えるのでは?

モチベーション

私は会社からAI用の課金サービスをいくつかもらっている。GitHub Copilot、Gemini、その他もろもろ。でも普段の業務ではほとんどコードを書かないので、正直あまり活用できていなかった。使えるものが手元にあるのに、もったいない。

じゃあ「コードを書くための道具」としてではなく、自分の普段の作業を前に進める道具として使えばいいのでは?

自分にとって本当に欲しかったのは、検索の代行ではなかった。

読んだ内容を整理して、自分の次の判断につなげてくれる道具が欲しかった。

たとえば、参考サイトを見ながらデザイン案を考えるとき。いろいろ見ているうちに「良さそう」は増えるのに、どこが良かったのか、何を自分の案に取り込みたいのか、うまく言語化しきれないことが多い。

やらせたいことは、主にこういうことだ。

  • サイトのHTMLの解析・要約
  • 英語記事やリポジトリの要約
  • 単純なWeb上の繰り返し作業
  • メールなどのメッセージ作成

おそらくこういうツールは他のAIプロバイダーも出していると思う。でも自分専用の、自分好みにカスタマイズしたツールを作りたくなった。

自分の業務が効率化すると思うと、作るのが結構楽しくなってきて、AIと壁打ちしながら1週間ほどで完成した。

SiteSurfとは

SiteSurf

AIと一緒にWebページを操作するChrome拡張機能。サイドパネルからチャットで指示するだけで、ページの読み取り・操作・ナビゲーションを自動化する。

対応しているAIプロバイダーはこんな感じ。

プロバイダー 認証方式
Anthropic (Claude) APIキー
OpenAI (ChatGPT) APIキー / OAuth
Google (Gemini) APIキー
GitHub Copilot OAuth
Kimi (Moonshot AI) APIキー
Ollama なし
ローカルLLM (OpenAI互換) APIキー (任意)

自分が使ってるプロバイダーだけ対応すればいい。これがAI時代のツール作成だ。

技術スタック

主な技術スタックはこんな感じ。

  • React 19 + Mantine v9 — UIコンポーネント
  • Vercel AI SDK v6 — マルチプロバイダー対応の要。ストリーミングもこれ
  • Zustand — 状態管理
  • Chrome Extension APIs — Side Panel, UserScripts, Debugger...
  • TypeScript 6
  • Vite+

私はChrome拡張を作ったことがなかったが、やりたいことを実現しようとするとかなりの知識が必要だった。Service Worker、Content Security Policy、サンドボックスでのコード実行、メッセージパッシング・・・Chrome拡張の世界は思った以上に奥が深い。

とはいえ、一番驚いたのは技術選定そのものではなく、それが1週間で形になってしまったことだった。

正直、作れたことそのものより、そんな速度で作れてしまったことの方が衝撃だった。

できること

画面操作(BrowserJS)

AIが生成したJavaScriptをページ上で実行して、情報の抽出やフォーム入力などを行う。コードはサンドボックス内で安全に実行される。

さらに面白いのが Debuggerモード だ。

通常のJavaScript (element.click()) は isTrusted: false なイベントを生成するため、ReactやGmailなど多くのモダンなWebアプリでは無視されてしまう。SiteSurfではChrome DevTools Protocol(CDP)の Input.dispatchMouseEvent / Input.dispatchKeyEvent を使い、実際のユーザー入力と区別できないイベントを発火できる。

つまり、頑固なサイトでもちゃんと動く。

例: Zennの記事入力

「この下書きをZennの記事フォームに入力して」と指示するだけで、タイトル入力からマークダウン本文の貼り付けまで自動化できる。

https://youtu.be/DRqwCQoYK6s

ちなみに、この操作がスムーズにできているのは、後述する Skills のおかげだ。ZennのフォームのDOM構造やセレクタをあらかじめSkillとして登録しておくことで、AIが毎回ページ構造を手探りする必要がなくなっている。

データ作成(Artifacts)

AIが生成したコードの実行結果を、HTML / CSV / JSON / 画像などのファイルとしてその場で保存・プレビューできる仕組み。

AI生成のHTMLをプレビューするのは一見簡単そうに見えるが、Chrome拡張のCSP (Content Security Policy) が <script> タグの実行を阻むので、実は一筋縄ではいかない。SiteSurfでは拡張自体のサンドボックスページをiframeで読み込むことで、安全にスクリプト実行可能なプレビュー環境を実現している。

例: サイトを参考にデザイン作成

参考サイトを読ませて「この方向性でUIモックを作って」と指示すると、HTMLプレビューがその場で表示される。

https://youtu.be/kOAh41EPxkc

例: ゲーム作成

「シューティングゲームを作って」と言えば、サンドボックス内で即プレイ可能なゲームが出てくる。

https://youtu.be/X7lKo5QhKTc

知識の蓄積(Skills)

最近GoogleがChromeに Skills in Chrome という機能を追加するらしいが、発想はあれに近い。それをよりブラウザ操作に特化させた形だ。

Skillはサイトごとのデータ抽出ルール。URLパターンやDOMセレクタでマッチングし、該当サイトを開いたときに自動的に使えるようになる。マッチングにはホスト名(40点)、パスパターン(30点)、DOM要素の存在(30点)の信頼度スコアリングを使っている。

面白いのは、AIに試行錯誤させた結果をAI自身にSkill化させられること。

例: Amazonの価格抽出

最初はAIに手探りでAmazonの価格抽出を試みさせる。セレクタが変わったり、ページ構造が微妙に違ったりして、何度か失敗する。でも最終的にうまくいったら「これをSkillにして」と言うだけでいい。

AIが自分で試行錯誤した結果を、再利用可能なSkillとして保存してくれる。次からは一発で正確に抽出できる。再現性が劇的に上がる。

Skillの定義はMarkdownファイルなので、人間が読んで直すのも簡単だ。

https://youtu.be/zHDEOSgBIaI

https://youtu.be/_A7c2J5t3I8

使い方の流れ

機能を個別に並べるより、実際の使い方を一つの流れで見た方がわかりやすいと思う。
普段はこんな流れで使っている。

  1. 参考サイトを開く
  2. 「このページのUIの特徴を整理して」と聞く
  3. 別の参考サイトに移って「さっきのページと比べて差分をまとめて」と聞く
  4. 「この2つを踏まえて、今回のアプリに合う方向性を3案出して」とまとめさせる
  5. 必要ならそのままページ上の情報抽出やブラウザ操作をさせる

単なるページ要約ではなく、読んだ内容を比較して、自分の次の案にまでつなげられるところが一番気に入っている。

その他の工夫

プロバイダーごとのコンテキスト圧縮

長い会話を続けるとトークンが膨らんでいくが、SiteSurfではプロバイダーごとに異なる閾値を設定している。

プロバイダー 圧縮閾値
Anthropic 150,000 トークン
OpenAI / Copilot 90,000 トークン
Google (Gemini) 700,000 トークン
ローカルLLM 5,000 トークン

クラウドプロバイダーでは圧縮にもAPI呼び出し(= 課金)が発生するため、自動圧縮はせず確認ダイアログを表示する。ローカルLLMだけはサイレントに自動圧縮。こういう地味な気配りが、マルチプロバイダー対応の面白さでもある。

圧縮後も、UIに表示される会話履歴は一切削除されない。ユーザーは常にフルの会話を見ることができ、APIに送るメッセージだけが圧縮される。

プロンプトインジェクション検知

Webページの内容をAIに読ませるということは、悪意あるページがAIの指示を乗っ取ろうとするリスクがある。「ignore previous instructions」のような定番のプロンプトインジェクションパターンをツール出力からリアルタイムでスキャンし、検出したら信頼度レベル付きで警告を表示する仕組みを入れている。

AIのシステムプロンプト側でも17種類の信頼できないデータソース(ページタイトル、DOM内テキスト、Cookie、URLパラメータなど)を明示して防御しているが、それとは別にパイプラインレベルでも検知する二重防御の構成にしている。

個人で作るからこその自由

今回あらためて感じたのは、個人で作るアプリは最初から全部入りである必要がないということだ。

本来なら、もっと多くの設定や機能に対応した方が汎用的なのかもしれない。でも自分用のアプリなら、自分がよく使うものだけに対応していれば十分だ。デザインも、自分が使いやすいもの、自分が好きなものに寄せていい。

既製品を選ぶのではなく、道具の側を自分に曲げられる。

この感覚はかなり新鮮だった。

国民総開発者時代を実感した

以前、AIに自分が欲しいアプリを作らせるという話を書いた。既存のSaaSやありもののアプリに自分の仕事を合わせるのではなく、自分が欲しい道具を自分で作れる時代が来ている、と。

https://zenn.dev/sonicmoov/articles/b2ec3f6a8ade39

今回はその延長で、実際に作ってみた話だ。

欲しいものを欲しい人が、自分で作れてしまう。しかも、それが以前よりずっと速い。

これは単なる個人開発の話ではなくて、仕事やシステムの作られ方そのものに広がっていく変化だと思う。社内で必要になるちょっとしたツールやワークフローも、いずれは「要件を言語化できる人」がAIと一緒に作るようになっていくはずだ。従来のように、必ずしも専門の開発者や外部委託を通さなくても、まず形にするところまで進められる。そういう方向に社会全体が寄っていく感じがある。

このとき、細野晴臣が語っていた話を思い出す。

技術の進化で音楽制作のあり方そのものが変わっていった。かつてはレコーディングエンジニアにしかできなかったことを、ミュージシャン自身が担うようになる。機材が小型化し、個人のスタジオで完結できるようになり、そうやって職能の境界が揺れていった。

もちろん、それをそのままAI時代に当てはめられるわけではない。でも、技術が制作の敷居を下げ、作る側の範囲を広げることで、既存の役割が少しずつ曖昧になっていく——その感覚は、今の状況とも重なって見える。

それでも少し苦い

自分はこの変化を、基本的には前向きに見ている。

欲しい道具を欲しい人が自分で作れるのは、やっぱりいいことだと思う。既製品に合わせるより、自分の仕事や癖に合わせて道具を作れる方が健全だ。

ただ、その一方で、この変化の中で自分のような中途半端なエンジニア人材は必要なくなっていくのかもしれない、とも感じる。

深い専門性で勝負できるわけでもない。かといって、完全に非エンジニアでもない。
その中間にいる自分のような人間の価値は、こういう時代になるほど曖昧になっていく。

いい時代になったと思う。でもその「いい時代」は、自分がこれまで拠り所にしてきた仕事の輪郭も少しずつ薄くしていく。

だからこれは希望の話であると同時に、少し苦い話でもある。

おわりに

今回、自分用のChrome拡張を実際に1週間で作ってみて、思っていた以上に時代が変わっていることを実感した。

欲しいものを、自分で作れる。しかも、かなり速く。

この変化はたぶんもう止まらないし、個人開発だけではなく、仕事の現場や社内システムの作られ方にも広がっていくと思う。

国民総開発者時代は、もう始まっているのかもしれない。


SiteSurfはGitHubで公開しています。興味がある方はぜひ触ってみてください。

株式会社ソニックムーブ

Discussion

y02y02

製作されるときにcometやatlasなど既存のAIブラウザと比べて意識されたことは何かあるのでしょうか

takemo101takemo101

コメントありがとうございます。
CometやAtlasなどは特別に意識していませんでした。
むしろ意識していたのは OpenCode や Claude Code のようなコーディングエージェントです。

コーディングエージェントの面白さは「開発環境(ファイル、ターミナル、Gitなど)という文脈にAIが入り込んで自律的に作業を進める」点にあります。これと同じことをブラウザ環境でやりたかった。ブラウザにおける「文脈」はDOMであり、ページ遷移であり、ユーザーの操作履歴です。これらにAIがアクセスして、読み取り→判断→操作のループを回す。そのためにChrome DevTools Protocolを使った入力イベントの生成や、サイトごとの操作知識を蓄積するSkillの仕組みを作りました。

既存のAIブラウザと被る機能はあるかもしれませんが、出発点が「AIブラウザを作りたい」ではなく「自分のブラウザ作業をコーディングエージェントみたいに効率化したい」だった感じです。