背景

毎日、私たちはブラウザで作業しています。情報を検索し、ウェブコンテンツを閲覧し、注文を出し、スプレッドシートを整理し、フォームに入力するなど。

一方で、私たちは数十から数百のブラウザタブを開き、タブの切り替えと管理は不可能な作業になっています。多くの場合、最初からやり直し、目の前のタブに集中する必要があります。

一方で、多くのタスクは反復的で、フォームへの入力、スプレッドシートの整理、CAPTCHAの入力などを何度も実行する必要があります。このプロセスは退屈で非効率的です。

では、AIがやったらどうでしょうか？以前、タブを整理するプラグインを作成し、複雑なタブをグループ化して整理しました。 Tool CallとMCPの発展により、AIエージェントができることがますます増えていることに気づき、このプラグインはすぐに現在のブラウザ拡張機能AIPexになりました。 AIPexは自然言語を使用してブラウザを制御することをサポートし、コンテキストエンジニアリングを最適化した後、タスクを迅速かつ正確に完了できます。

この記事を通じて、以下の質問に答えたいと思います：

1. なぜAIブラウザが将来のトレンドなのか？
2. AIブラウザの実装パスは何か？それぞれの長所と短所は何か？
3. なぜAIPexがAIブラウザ自動化のゲームチェンジャーであると自信を持って言えるのか？

AIブラウザ革命が到来している

ChatGPTの登場以来、多くのチームがAIブラウザの試みを行ってきました。最も早いのはChatGPT for Googleで、 Google検索結果の横にAIの回答を表示でき、瞬時に数百万人のユーザー登録を集めました。その後、SiderとMonicaのリリースにより、Google検索結果を強化できるだけでなく、 ページ上でいつでもAIアシスタントを呼び出せ、動画サイト、chat pdf、画像サイト向けに特別な最適化を行い、AIがコンテンツの生成、修正、分析にいつでも参加できるようになり、ユーザー体験が大幅に向上しました。 今でも私はこのようなプラグインの忠実なユーザーです。Siderだけで、Chromeには600万人のユーザーがおり、AIブラウザプラグインの第1位と言えるでしょう。

その後、Tool UseとMCPの出現と広範な使用により、AIブラウザはクエリ、ダイアログボックス内でのテキストと画像の生成だけでなく、ツールを通じてブラウザの機能を呼び出し、より複雑なタスクを完了できるようになりました。 昨年のBrowser Useがこの概念を提案してから、今年のClaude for Chrome、Comet、ChatGPT Atlasの出現まで、各社がAgentic Browserをリリースし、最大の特徴は自動的にタスクを完了できることです。 QueryからActionへ、ユーザー操作は受動的な閲覧から能動的な自動化へと移行しました。

1. 従来のブラウザの根本的なボトルネック：それは「表示」するだけで、「完了」しない

従来のブラウザの役割は：ウェブページを開く、情報を表示する、人がクリック、コピー、判断、移動するのを待つ。しかし、真の目標は「ウェブページを見る」ことではなく、適切な製品を見つける、 税務申告/チケット予約/フォーム入力、オプションを比較して決定を下す、情報を結果に変換することです。

ブラウザで人が行うことは、実際にはプロセス実行者であり、「読者」ではありません。AIブラウザの核心的なアップグレードは：

2. 現代のウェブのコンテンツ爆発

現実的な問題は：ページがますます複雑になっている（多段階、ポップアップ、CAPTCHA、オプション）、情報密度がますます高くなっている（価格比較、条項、レビュー、ポリシー）、タスクがますますプロセス化されている（申請、登録、比較、提出）。 一方、人間は：クリックが遅い、記憶が限られている、間違いやすい、反復プロセスが苦手。

タスクを自律的に実行するAIブラウザは、本質的に：疲れない、ステップを見逃さない、並列実行できる、継続的にパスを最適化できる。

3. 情報時代の重要なボトルネックは「情報の取得」から「決定の実行」へと移行

過去の問題は：

• 情報が少なすぎる → 検索エンジンが必要

現在の問題は：

• 情報が多すぎる → 決定と実行のコストが高すぎる

例：

• 最もコスト効率の高いフライト + 荷物規則 + 変更ポリシーを選択

• 20社のサプライヤーにカスタマイズされたメールを送信し、フォローアップ

• 会社のポリシーに従って経費精算/調達プロセスを完了

これらは「検索すれば終わり」ではなく、主に目標の理解、制約の評価、ステップの実行です。

従来のモデルは：

人 → 指揮 → ソフトウェア → フィードバックを待つ → 人が再操作

AIブラウザモデル：

人 → 目標と境界を設定
AI → 自律的な計画 + 実行 + 結果の報告

4. なぜブラウザなのか？

コンピューターは人と情報の媒介として誕生しました。 ブラウザは基本的に90%の仕事と生活システムをカバーし、SaaS、政府サービス、金融、コンテンツプラットフォームに接続できます。 各プロバイダーがAPIを提供するのを待つ必要はなく、「人間インターフェース」層で直接タスクを完了できます。これは現在、私の意見では、 最も現実的で、抵抗が最も少なく、拡張性が最も高いAI自動化の実装パスです。

なぜAIブラウザが必要なのか、一言でまとめると：

AIブラウザの実装原理

AIブラウザの実装の鍵は、ページを効率的に理解する方法にあります。以下のパスがあります：

1. DOM Tree（DOMツリー）——最も直感的で、最も脆弱な方法

• document / HTMLを直接読み取る

• DOMノードをテキストにシリアライズ

• LLMに理解 + アクション生成を任せる

HTML / DOM → serialize → LLM → action

Playwright / PuppeteerもDOMのアプローチです。DOMの処理で多くの汚い作業を行い、比較的クリーンなDOMツリー表現を取得できます。 しかし、このアプローチには以下の問題があります：

❌ DOM ≠ ユーザーが見るインターフェース

❌ divの中にdiv、DOMは意味表現ではないため、意味が失われる

❌ LLMトークンの爆発

2. Visual Tree / OCR（視覚理解派）

ウェブページを「スクリーンショット」として扱い、OCR + Vision Modelを使用して：ボタン、テキスト、入力フィールドを識別し、AIに座標でクリックさせる

Screenshot → Vision Model → UI elements → click(x,y)

現在、OpenAIにはcomputer-use-agent(cua)モデルもあり、スクリーンショットとタスクに基づいてアクションを生成できます。 このアプローチの利点は、より汎用的で、ブラウザのウェブページ表現に依存せず、あらゆるブラウザ、あらゆるオペレーティングシステムの自動化に拡張できることです。 このソリューションは汎用的ですが、コストとレイテンシが高く、現在ChatGPT Atlasでさえcuaを使用して自動化を行いません。

3. Accessibility Tree（アクセシビリティツリー）——AIPexのルート

原理（重要ポイント）

ブラウザ内部には実際に「スクリーンリーダー用の意味ツリー」があります：

• role：button / textbox / link

• name：人間が読める名前

• state：disabled / checked / expanded

• hierarchy：実際のUI構造

DOM → Accessibility Tree → Semantic UI Graph → LLM

なぜAIに最適なのか？

AIブラウザの製品形態

現在、ブラウザ自動化を実装する製品形態は以下の通りです。それぞれ分析します：

1. Agentブラウザ

Agentブラウザは、Comet、ChatGPT Atlasなどの独立したAIブラウザアプリケーションを指します。これらの製品はブラウザを再構築し、AI機能をブラウザカーネルに深く統合します。

利点：

• 深い統合：AI機能がブラウザカーネルと深く統合され、ブラウザの動作をより低レベルで制御できる
• 統一された体験：すべての機能が1つのアプリケーションにあり、より統一された体験
• パフォーマンス最適化：AIシナリオ向けに特別なパフォーマンス最適化が可能

欠点：

• 移行コストが高い：ユーザーは既存のブラウザを放棄し、ブックマーク、拡張機能、パスワードなどのデータを移行する必要がある
• エコシステムの分断：Chrome/Edgeの豊富な拡張機能エコシステムを使用できない
• 学習コスト：ユーザーは新しいブラウザインターフェースと操作習慣に適応する必要がある
• 開発コスト：ゼロからブラウザを構築する必要があり、開発コストが極めて高い

典型的な代表： Comet、ChatGPT Atlas、Dia

2. プラグイン/拡張機能式

プラグイン/拡張機能式は、AIPexなど、既存のブラウザ（Chrome、Edgeなど）に基づいて開発された拡張プログラムを指します。この方法は既存のブラウザの上にAI自動化機能を追加します。

利点：

• ゼロ移行コスト：すべてのブックマーク、拡張機能、パスワード、履歴を保持
• 即座に使用可能：インストール後すぐに使用でき、使用習慣を変更する必要がない
• エコシステム互換性：Chrome/Edgeの豊富な拡張機能エコシステムを引き続き使用できる
• 開発効率が高い：成熟したブラウザAPIに基づき、開発コストが比較的低い
• ユーザー受容度が高い：ユーザーはブラウザの使用習慣を変更する必要がない

欠点：

• API制限：ブラウザ拡張機能APIの能力境界に制限される
• パフォーマンス制約：ブラウザの他の拡張機能や機能と調整する必要があり、パフォーマンスに影響を受ける可能性がある

典型的な代表： AIPex、Claude for Chrome

パス比較

実際の実装の観点から、プラグイン/拡張機能式は現在最も現実的で、抵抗が最も少なく、ユーザー受容度が最も高いパスです。ユーザーは確立されたワークフローと習慣を放棄する必要なく、AI自動化機能を獲得できます。これがAIPexが拡張機能パスを選択した核心的な理由です。

AIPexの優位性

製品の優位性

1. 移行不要

Comet、ChatGPT Atlasなど、完全に新しいブラウザをインストールする必要があるソリューションとは異なり、AIPexはChrome/Edge拡張機能です。

• ゼロ移行コスト：プラグインをインストールするだけで使用できます
• すべてのデータを保持：ブックマーク、拡張機能、パスワード、履歴、Cookieすべてを保持
• 習慣を変更する必要がない：慣れ親しんだブラウザインターフェースと操作方法を引き続き使用
• 即座に使用可能：拡張機能をインストール後すぐに使用でき、新しいインターフェースを学習する必要がない
• エコシステム互換：Chrome/Edgeの豊富な拡張機能エコシステムを引き続き使用できる

"Your browser already works!" —— あなたのブラウザはすでに十分に機能しています。私たちはそれをよりスマートにするだけです。

2. オープンソース & プライバシー保護

AIPex GitHubリポジトリ

読み取り、タスクを実行できるAIエージェントにとって、プライバシーとセキュリティは極めて重要です。 AIPexはMITオープンソースライセンスを採用し、完全に透明で、監査可能で、拡張可能です：

• 完全にオープンソース：コードは完全に公開され、誰でもレビュー、貢献、フォークできます
• プライバシー優先：あなたのデータは決してあなたのマシンを離れません。データを完全にあなたのコンピューター内に保存し、サーバーにアップロードしません
• BYOK（自分のキーを持参）：自分のAPIキーを使用し、データフローを完全に制御

ChatGPT Atlas、Diaなど、有料サブスクリプションが必要で、データをサーバーにアップロードする必要があるソリューションと比較して、AIPexはプライバシーとセキュリティの面で明確な優位性があります。

3. 優れたコンテキストエンジニアリング

AIPexはコンテキストエンジニアリングの面で大量の最適化を行っており、これが効率的かつ正確にタスクを完了できる核心的な技術的優位性です：

アクセシビリティツリー + 検索リコールメカニズム：

• 従来のDOMの代わりに、意味的に豊富なアクセシビリティツリー（Accessibility Tree）を使用
• セマンティック検索を通じて、必要に応じて関連要素をリコールし、ページ全体を渡すのではなく
• コンテキストの長さを大幅に削減し、応答速度と精度を向上

インテリジェントスナップショット重複排除：

• 同じタブの最新のページスナップショットのみを保持
• コンテキストの複雑さをO(n²)からO(n)に削減
• 50回の操作：1,275個のスナップショットから50個のスナップショットに（96%のトークン節約）

Search-based Element Retrieval：

ウェブページコンテンツを処理する際、AIPexは埋め込みベースのRAG技術を使用していません。コードと比較して、ウェブページは常に変化しており、静的な埋め込みはウェブページを分析するシナリオに適応するのが困難です。 Claude CodeおよびClineのアプローチと一致して、AIPexはウェブページを埋め込み保存せず、最適化された検索を使用して、大規模モデルに必要な要素を判断させます。 ページコンテンツ全体を大規模モデルに渡すのではなく、埋め込みベースのRAG技術でもありません。

これらの技術革新により、AIPexは高い精度を維持しながら、計算コストと応答時間を大幅に削減できます。

4. Skillsサポート

AIPexは**Claude Agent Skills**とシームレスに統合し、ブラウザ自動化に無限の可能性を開きます：

• スキルのインポート：コミュニティが作成した数千の事前構築されたスキルにアクセスし、自動化機能を拡張
• スキルのエクスポート：成功したAIPexワークフローを再利用可能なスキルとしてエクスポート
• スキルの組み合わせ：複数のスキルを混合してマッチングし、複雑な自動化ワークフローを作成
• エコシステムの協力：Claudeエコシステムの集合知識から利益を得る

これは、AIPexを使用できるだけでなく、Claude Agent Skillsエコシステム全体を活用できることを意味し、タスクを再利用可能、共有可能、より迅速かつ効率的にします。

5. インテリジェントな介入

AIPexは、タスクが確認を必要とする場合に、インテリジェントにユーザーに確認を促します。これにより、支払い、確認提出などの重要な機密操作のセキュリティが保証されます。

6. ターゲットを絞ったユーザーシナリオ

AIPexはウェブページとユーザーのアクションを理解できるため、ユーザーガイドドキュメントの作成（「Vercelでドメインを作成する方法は？」）などの特定のシナリオに対して、ターゲットを絞った最適化を行っています。

以前、システムのユーザードキュメントを作成したい場合、以下が必要でした：

• ユーザーの視点に戻り、ドキュメントに技術用語が出現しないことを保証

• 各ステップを手動で記録し、各ステップの説明ドキュメントを作成

• 各ステップを手動でスクリーンショットし、重要な注釈を追加

• 各ステップのドキュメントを整理してフォーマットし、最終的にドキュメントを形成

しかし、今では、AIPexのユーザーガイド機能を開き、操作を記録するだけで、AIPexが自動的にユーザーガイドドキュメントを生成します。

この効率向上は革命的です。人間として、フォーマット、ユーザーの視点、技術用語に注意を払う必要がなくなり、これらはすべてAIPexが準備してくれます。 最終的な成果物にのみ注意を払い、いつでも更新できます。 「ユーザーガイドの作成」のような細分化されたシナリオは他にも多くあり、エンドツーエンドテスト、製品デモの記録など、AIPexはこれらの細分化されたシナリオにより良いソリューションを提供できます。ご期待ください。

AIPexはどのように誕生したか

最初、私はブラウザ内のraycastのようなものを作りたかっただけです。どこからでも呼び出せ、タブの切り替え（ArcブラウザのCommand + Tショートカットに似て、タブを選択して切り替え）、タブページの整理（40以上のタブを処理する必要があり、手動での整理は非常に面倒）、どこからでもAIアシスタントを呼び出す（メールを送信、ツイート、質問するかどうかに関わらず）を支援します。そこで、AIPexの最初のバージョンを開発しました。 このバージョンは、私が遭遇したマルチタブの問題を最適化でき、一部のページでAIに質問できましたが、まだ十分にクールではないと感じました。

昨年のこの時、AnthropicはComputer Use Operatorの概念を提案しました。 その後、Browser UseもAIブラウザ自動化の概念を提案しました。 技術の発展により、主にtool useとmcpの発展により、いくつかのchromeのmcpが出現しました。例えば、mcp-chrome、playwright-mcp、browserMCP、devtools-mcpプロジェクトです。 私はcursorで試しましたが、最大の問題は、それらがすべてヘッドレスブラウザを使用しているため、ユーザーのログイン状態を再利用できず、介入なしで私が小红书に投稿することさえできませんでした。 実際、このmcp client、serversの分離にもコンテキストの浪費の問題があり、cursorはターゲットを絞ったコンテキスト最適化を行うことができませんでした。

そこで、ブラウザで直接使用でき、ユーザーのログイン状態を再利用し、自然言語でブラウザの動作を制御し、ブラウザ向けにターゲットを絞ったコンテキスト最適化を実行できるchrome拡張機能を作りたいと考えました。 これ以前、私は実際にはMCPが何であるか、tool useが何であるか、Agent Loopが何であるかを理解していませんでした。cursorの先生と1週間格闘した後、AIPexの最初のバージョンができました。80以上のブラウザツールをカバーしています。 当時、AIpexコードをオープンソース化し、最初のデモビデオ「Googleを使用してMCPを研究するのを手伝って」を記録しました。AIPexはGoogleを開き、MCPを入力し、検索をクリックし、さらにサブリンクをクリックして研究し、最終的にMCPに関するレポートを生成しました。

私はこのデモをリーダー、同僚、友人と共有しました。彼らは皆非常に興味を持ち、ここで何が行われたかを理解したいと思いました。最初、私はAIPexを余暇に作ったおもちゃとして扱いました。Glaceは最初に貢献した友人です。 AIPexに対して、彼は無限の熱意とアイデアを持っており、ユーザードキュメントの作成、インターフェースのエンドツーエンドテストなど、仕事で遭遇した実際の問題をAIPexの能力で解決したいと考えています。 私は彼と製品形態と要件についてコミュニケーションを取りました。共通点は、私も彼もtypescriptの純粋な初心者でしたが、cursorの先生のコードレベルを信じていたことです。 Glaceの高いエネルギーは私にさらに影響を与え、AIPexが面白く、価値があることを知らせ、AIPexをさらに最適化するよう促しました。

AIPexについて知る同僚や友人が増えるにつれ、より多くの要件と修正提案を受け取りました。より深刻なのは、最初のバージョンのUIが比較的醜く、ほぼネイティブコンポーネントとサードパーティコンポーネントを混在させていたことです。 これにより、UIスタイルが美しくなく、統一されておらず、いくつかのバグが存在しました。Kenは、国慶節に完全にai elementsを使用してAIPexのUIを再構築しました。このコード変更量は当時の1/2を占めていました。 最終的な効果は非常に驚くべきもので、現在のAIPex UIができました。その後、Claude Agent Skillsが出現すると、Kenは1週間以内にSkillを1:1で複製し、AIPexに統合しました。 Skillはprompt + スクリプトを使用して、今回の成功した実行プロセスを記録でき、次回使用時に、AIPexはSkillに基づいてより一貫性があり、より迅速に動作できます。

現在、k8s/golang/supabase/tidb contributor卡神も私たちに参加しました。市場のgemini-cli、openai-agents-sdk、spring-aiなどの主流のAIエージェント 実装方法を研究した後、オープンソースリポジトリを再構築しました。AIPexのオープンソースコードはより理解しやすく、より標準化され、より保守しやすくなりました。卡神はオープンソースコミュニティの運営を引き続き支援します。

私たちは依然として4人の小さなチームです。私とGlaceは主に製品を担当し、Kenはシニアフロントエンドで、AIPexのようなリッチフロントエンドモデルのエージェントにとって極めて重要です。 卡神はシニアのオープンソース貢献者で、プロジェクトのオープンソースルートとコミュニティ運営にとって非常に重要です。 現在、私たちはすべて余暇にAIPexに貢献しています。 製品面では、製品デモの記録、エンドツーエンドテスト、UI比較など、より適切な垂直シナリオを引き続き開発することを目標としており、各垂直シナリオは異なる人々の問題を解決します。 マーケティング面では、あまり資金を投入していません。SEOの最適化を試みています。 SEOについては、実際には1年間研究しており、AIナビゲーションサイトを作成して一定の成果を得ましたが、AIPexではまだ良い効果が得られていません。 現在の目標は、安定した相当なMRRを獲得することです。協力の意向がある場合は、https://www.claudechrome.com/zh/contact でお問い合わせください。