Browser Code: AIにuserscriptを育てさせる仕組み

Browser Code: AIにuserscriptを育てさせる仕組み cover image

既存のWebサイトに対して「ここだけもう少し使いやすくしたい」「自分のワークフローに合わせて表示や挙動を変えたい」と思うことはありませんか？

「AI がブラウザを操作する」ツールは、Playwright や Puppeteer で既に実現されています。でもBrowser Code が狙っているのは、そこではありません。

「AIが操作する」のではなく、「AIが常駐するuserscriptを育てて、サイトを自分仕様に作り替え続ける」。それがBrowser Codeの本質です。

ブラウザ自動化（操作の再生）ではなく、userscriptの動的生成（改造の永続化）です。この違いを理解すると、どこで使えて、どこで使えないかが見えてきます。

Browser Codeとは何か（ブラウザ自動化ではない）

Browser Codeは、ブラウザ拡張として動作し、ページのDOM （Document Object Model）を「仮想ファイルシステム」として扱います。Claude にuserscriptをJavaScriptで生成させ、それをchrome.userScripts API （Tampermonkey のようなuserscript常駐実行の仕組み）で永続化・自動実行するツールです。

仮想ファイルシステムの構造

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
/{domain}/{url-path}/
├── page.html           # Live DOM（読み書き可能）
├── console.log         # コンソール出力（読み取り専用）
├── screenshot.png      # スクリーンショット（オンデマンド）
├── plan.md             # AIの計画（Plan/Executeモード用）
├── scripts/
│   ├── my-script.js    # 保存したuserscript
│   └── _auto_edits.js  # DOM編集から生成されたスクリプト
└── styles/
    └── custom.css      # カスタムCSS

ブラウザ自動化との違い

観点	ブラウザ自動化（Playwright等）	Browser Code
目的	操作の再生・テスト	サイトの常駐改造
実行タイミング	明示的に起動	ページロード時に自動実行
永続性	スクリプトファイルとして保存	userscriptとして拡張に保存
CSP 制約	外部から操作するため回避可能	userScripts APIでCSP回避
対象	任意のサイト	自分が使うサイト

つまり、Browser Codeは「毎回同じ操作を自動化する」のではなく、「サイトの見た目・挙動を永続的に変える」ツールです。

永続化の仕組み（何が残るか）

Browser Codeの「永続化」は2つの層に分かれます。

残るもの: userscript本体

./scripts/*.js や ./styles/*.css は拡張のストレージ（browser.storage.local）に保存されます
保存時に chrome.userScripts.register() で登録され、次回以降も同じURL（またはパターン）で自動実行されます
動的ルートマッチング（/products/[id] 等）にも対応しており、パラメータは window.__routeParams で取得できます

残らないもの: DOM状態そのもの

ページをリロードすると、DOMは元に戻ります
しかし保存済みuserscriptが再実行されるため、「結果として同じ見た目/挙動を再現」します

この設計により、「一度設定したら、そのサイトでは常に自分仕様の画面が表示される」状態を作れます。

向くユースケースの条件

Browser Codeの設計から逆算すると、以下の条件を満たすサイトで特に有効です。

1. 改善要望が通らないサイト

なぜ向くか: 公式が対応する理由がない、開発リソースが回らない

具体例:

社内システム（Salesforce/kintone/Redmine等の管理画面）
業務ツール（ERP、ワークフローシステム）
官公庁サイト（e-Gov、e-Tax）
学術DB（J-STAGE、CiNii、PubMed）

これらのサイトは「ユーザ数が少ない」「予算がない」「仕様変更が難しい」といった理由で、UI改善が永遠に来ません。

2. 日本向け対応が薄い海外SaaS

なぜ向くか: ローカライズが雑、日本向け機能がない、サポートに要望しても通らない

具体例:

Figma/Notion/Linearの日本語表示崩れ修正
Stripe/Shopifyの管理画面に日本向け表示追加（税率、インボイス番号）
GitHub/GitLabのissueテンプレを日本語デフォルト化

海外サービスは「日本だけ不便」な箇所が多く、公式対応を待つより自力で直した方が早いケースがあります。

3. 自分だけのワークフロー

なぜ向くか: 公式が対応する理由がない、個人のワークフロー特化

具体例:

Aサイトの情報をBサイトのフォームに転記（求人→スプレッドシート、論文→Notion）
複数タブの情報を1画面に集約表示
特定キーワードの出現を監視してSlack/Discord通知

こうした「自分だけの組み合わせ」は、公式連携が存在しないため、userscriptで埋めるしかありません。

4. 廃止予定/メンテ終了サービス

なぜ向くか: 公式は改善しない、でも使い続けたい

具体例:

Google系サービスの旧UIを維持（カレンダー、Gmail）
終了予告されたサービスからのデータエクスポート自動化
API廃止後のスクレイピング代替

公式が「見捨てた」機能を自力で維持する場合、userscriptは現実的な選択肢です。

向かないユースケース（メジャーサイトの限界）

一方で、Browser Codeが向かない条件も明確です。

メジャーなサイトは大体ユーザの要求を叶えている

Amazon、楽天、YouTube、Twitter（X）などのメジャーサイトは、以下の理由でuserscriptの出番が少ないです。

公式が既に対応済み: ユーザ要望の多い機能は公式が実装する
頻繁な仕様変更: DOM構造が変わるたびにuserscriptが壊れる
既存の拡張が充実: 広告ブロック、ダークモード等は専用拡張がある

例えば「YouTubeの広告を消す」は、uBlock Originで済みます。「Twitterのタイムラインをフィルタする」は、公式のミュート機能で十分です。

具体的な変更を書かない理由

本記事では「社内システムの入力フォームを最適化」「官公庁サイトのバリデーション強化」といった具体的なサイト名や変更内容を書いていません。理由は2つです。

サイト仕様の変更リスク: 具体的なDOM構造やクラス名を書くと、サイト更新で即座に陳腐化します
汎用性の欠如: 特定サイト向けのコードは、読者の環境で再現できません

代わりに「どういう条件のサイトで使えるか」という判断基準を提示しました。

Plan/Executeワークフローの意味

Browser Codeは、AIの暴走を防ぐため「Plan/Execute」の2段階ワークフローを採用しています。

Planモード（デフォルト）

AIはページを探索し、plan.md に変更案を書きます
DOM変更やスクリプト書き込みはできません
ユーザが計画を確認してから、Executeモードに切り替えます

Executeモード

ユーザ承認後、AIは計画を実行します
ファイル書き込み、DOM編集、スクリプト実行が可能になります

この設計により、「AIが勝手にサイトを壊す」リスクを減らしています。

インストールと初期設定（Chrome/Firefox）

Browser Codeは現状ブラウザ拡張として使います。ざっくり言うと「ビルドして、拡張として読み込む」です。

ビルド

ビルドには Bun を使います。

1
2
3
4
5
6
7
8
bun install

# Development
bun run dev           # Chrome
bun run dev:firefox   # Firefox

# Production
bun run build         # Both browsers

Chromeに読み込む

chrome://extensions を開きます
Developer mode（デベロッパーモード）を有効にします
Load unpacked で .output/chrome-mv3/ を選びます
拡張のDetailsから User scripts 権限を有効にします（CSP回避に必要）

※ Chromeのバージョンによっては「Allow User Scripts」トグル側に寄っていくため、うまく動かない場合は chrome.userScripts が有効かを先に疑うのが良いです。

Firefoxに読み込む

about:debugging#/runtime/this-firefox を開きます
Load Temporary Add-on で .output/firefox-mv2/ 配下の任意のファイルを選びます

Firefoxは File System Access API がないので、ローカルとの同期はエクスポート（WebExtensions downloads API ）前提になります。

導入前に、Releases 、Commits 、Issues を軽く眺めておくと安心です。

2026-01-29時点ではReleasesがなく、最終pushは2026-01-25（UTC）でした。個人的には、当面は「実験的なツール」として扱い、使うならコミットハッシュ固定で追いかけるのが安全だと思います。

技術的な制約と回避策

Browser Codeを使う上で、以下の制約に注意が必要です。

CSP（Content Security Policy）の壁

一部のサイト（LinkedIn等）は厳格なCSPを設定しており、通常のJavaScript注入では動作しません。

回避策: Chrome 120+の userScripts API を使用することで、CSPを回避できます。ただし、拡張の設定で「User scripts」権限を有効化する必要があります。

Trusted Types の制約

一部のサイトは Trusted Types（危険な文字列を innerHTML 等に流し込むのを制限する仕組み）を有効にしており、DOM操作が失敗することがあります。

回避策: createElement や appendChild などのDOM APIを使用します。

Firefoxの同期制限

Firefoxには File System Access API がないため、ローカルファイルとの双方向同期ができません。

回避策: エクスポート専用（Downloads API経由）で運用します。

まとめ: Browser Codeが向く境界線

Browser Codeは「ブラウザ自動化」ではなく「userscriptの動的生成」ツールです。向くのは以下の条件を満たすサイトです。

条件	例
改善要望が通らない	社内システム、ニッチ専門サイト
開発リソースが回らない	官公庁、学術DB、業界ポータル
日本向け対応が薄い	海外SaaS
自分だけのワークフロー	サイト間連携、個人自動化
公式が改善する気がない	廃止予定、レガシー

逆に、メジャーサイトでは「公式が既に対応済み」「既存拡張で十分」なケースが多く、出番は限定的です。

興味のある方は、まず「自分が毎日使う、でも微妙に不便なサイト」を思い浮かべてみてください。そこにBrowser Codeの出番があるかもしれません。

Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新

Browser Code: AIにuserscriptを育てさせる仕組み

Browser Codeとは何か（ブラウザ自動化ではない）

仮想ファイルシステムの構造

ブラウザ自動化との違い

永続化の仕組み（何が残るか）

残るもの: userscript本体

残らないもの: DOM状態そのもの

向くユースケースの条件

1. 改善要望が通らないサイト

2. 日本向け対応が薄い海外SaaS

3. 自分だけのワークフロー

4. 廃止予定/メンテ終了サービス

向かないユースケース（メジャーサイトの限界）

メジャーなサイトは大体ユーザの要求を叶えている

具体的な変更を書かない理由

Plan/Executeワークフローの意味

Planモード（デフォルト）

Executeモード

インストールと初期設定（Chrome/Firefox）

ビルド

Chromeに読み込む

Firefoxに読み込む

技術的な制約と回避策

CSP（Content Security Policy）の壁

Trusted Types の制約

Firefoxの同期制限

まとめ: Browser Codeが向く境界線

参考リンク