ブラウザ内で完結するAIエージェント：WebMCPとローカル推論によるプライバシー・レイテンシー両立の実装設計

はじめに：なぜ今、ブラウザ内（Edge）でのAIエージェントなのか

現在、多くのAIエージェントはクラウドAPIを中核としたアーキテクチャで構築されている。ユーザーの入力が外部サーバに送られ、LLMが推論を行い、結果がブラウザに返ってくる。このモデルは開発が容易である反面、構造的に二つの根本的な課題を抱えている。

一つ目はデータ流出リスクである。ユーザーが操作しているページ上のDOM構造、フォームに入力された値、セッション中の業務データが、プロンプトの一部として外部APIに送信される。特に金融・医療・人事といった分野では、この事象そのものがコンプライアンス違反に直結する可能性がある。APIキーの管理やデータ残存ポリシーの設定で一部は緩和できるが、データが自社のネットワーク外に出るという事実を消すことはできない。

二つ目はネットワークレイテンシーである。クラウドAPIへの往復通信には、DNS解決、TLSハンドシェイク、推論待ち時間、応答のストリーミングが重なる。ユーザーがリアルタイムに操作を期待するUI（例：フォームの自動補完、チャット中の即応答）では、この遅延が体験の質を大きく損なう可能性がある。

ここで注目すべきは、ブラウザという環境がすでに「認証済みコンテキスト」を保持しているという点だ。ユーザーがログインしているサイトでは、セッションCookie、認証トークン、ページ上の業務データがすべてブラウザ内に存在する。エージェントをこの環境内に閉じ込めれば、外部へのデータ送信が構造的に不要になり、かつ推論の往復がローカルに限定される。

本記事では、この設計思想を実現する技術スタックとして、WebMCP仕様とローカル推論エンジンの組み合わせを扱う。これは技術的な実験に留まらず、実務においてプライバシー保護とリアルタイム応答を同時に満たす設計指針として機能しうる。CTOやリードエンジニアの視点から言えば、クラウドAPI課金からの脱却、データガバナンス要件の簡素化、エンドユーザーの応答速度向上が期待できる場合がある。

前提知識：WebMCP仕様とブラウザ内エージェントの動作原理

WebMCPは、ウェブサイトが明示的にツールを公開し、AIエージェントがそれを呼び出せるようにする実験的なブラウザAPIである（WebMCPの解説記事）。従来のMCP（Model Context Protocol）がサーバサイドでツールを公開するのに対し、WebMCPはツール定義の主体をブラウザ内にあるWebページ側に置く。つまり、ページ自体が「このツールをエージェントに提供します」と宣言する仕組みだ。

動作の前提条件と制約

WebMCPが動作するのはブラウザのコンテキスト内のみである。具体的には、対象のサイトがブラウザ上で開かれており、かつユーザーがそのサイトにログインしている場合に限り、ツール呼び出しが可能になる（WebMCPの解説記事）。この制約は一見すると不便に思えるが、実はセキュリティ上の重要な利点である。

エージェントがアクセスできるのは、そのユーザーのそのセッションのスコープに限定される。別ユーザーのセッションに横からアクセスする経路が存在しない。オフライン時や別タブでの動作には適さないが、「誰の何のデータにアクセスしているか」が構造的に明確になる。これはクラウドAPI経由でツールを公開する場合と比べ、攻撃面を狭める設計判断になりうる。

標準化の動向

この仕様が単なる実験に留まっていないことを示す動きがある。WebMCPの解説記事によると、ChatGPTは組み込みブラウザにおいてWebMCPベースのサイトツールをサポートする機能を追加している。主要なAIエージェントがブラウザ内のツール呼び出しに対応し始めれば、Webサイト側がWebMCPツールを公開するインセンティブが生まれ、エコシステムとして成立する可能性がある。標準化の波が来る前に、実装パターンを把握しておくことが実務上重要である。

flowchart LR
    A["ユーザー"] --> B["ブラウザセッション"]
    B --> C["Webサイト（ツール提供者）"]
    B --> D["AIエージェント（ツール呼び出し側）"]
    C -->|"WebMCP: ツール定義を公開"| D
    D -->|"WebMCP: ツール呼び出し"| C
    C -->|"結果を返す"| D
    D -->|"応答を返す"| A

この図は、ユーザーのブラウザセッション内でWebサイトとエージェントがWebMCPを介して対話する流れを示している。データはブラウザの外に出ず、セッションスコープ内で完結する。

アーキテクチャ設計：拡張機能とページの役割分担

WebMCPベースのエージェントを実装する際の中心的な設計判断は、「エージェントロジックをどこに置くか」である。本記事で扱う実装では、Chrome拡張機能がエージェントの中核を担い、ページ側はツール定義とUIの提示に専念する役割分担が採用されている。

拡張機能：エージェントの中枢

WebMCP Local AgentというChrome拡張機能が、ユーザーの意図を受け取りページ上のWebMCPツールを呼び出すエージェントとして機能する。この拡張機能はManifest V3に対応しており、サイドパネルから自然言語コマンドを入力してエージェントを起動する（WebMCP Local AgentのGitHubリポジトリ）。

サイドパネルを採用した理由として、メインウィンドウのDOMをエージェントのUIで占有しない点が挙げられる。ユーザーは業務ページをそのまま操作しながら、サイドパネルでエージェントに指示を出せる。これは「エージェントがページを乗っ取る」のではなく「ページにエージェントが寄り添う」というUX設計の思想に一致する。

エージェントループの設計判断

エージェントがツールを呼び出す際の反復回数は、デフォルトで最大10回に制限されている（WebMCP Local AgentのGitHubリポジトリ）。この制限は二つの目的を持つ。

第一に無限ループの防止である。LLMがツール呼び出しの結果を正しく解釈できず、同じツールを繰り返し呼び出すケースが実務上起こり得る。反復回数に上限を設けることで、最悪ケースのコストと時間が有界になる。第二にコスト管理である。ローカル推論であっても計算資源は有限であり、無制限のループはブラウザのフリーズを招く可能性がある。

重要なのは、この値が設定ファイルで変更可能である点だ。ツールが3つしか無い単純なケースでは5回で十分だが、10以上のツールを連鎖的に呼び出すワークフローでは20回以上が必要になる場合がある。デプロイ環境ごとにこの値を調整できる柔軟性が、実務上の可用性を左右する。

ページ側：サーバーレスなツール提供者

ページ側（フロントエンド）は、AI CEO Simulatorデモに代表されるように、バックエンドを持たないサーバーレスな構造を採用している。React 19、TypeScript、Tailwind CSS v4、Vite 6で構築され、WebMCPツールの定義とUIの提示のみを担当する（AI CEO SimulatorのGitHubリポジトリ）。

この設計の利点は、インフラ負荷がゼロになることだ。ページは静的なアセットとしてCDNから配信されればよく、エージェントの推論やツール実行の計算負荷がページ側にかからない。ツール実行の結果を返す際も、ページ内の状態管理（ReactのstateやContext）で完結するため、APIサーバの存在が不要になる。

ただし、この構造には制約がある。ツール実行がページの状態に依存する場合、ページがリロードされると状態が失われる。永続化が必要なツール（例：データベースへの書き込み）は、ページ側で外部サービスへのHTTP呼び出しをツール実装として公開する必要がある。この場合、データがブラウザの外に出るため、前述のプライバシー利点が部分的に失われる点に注意が必要だ。

sequenceDiagram
    participant U as ユーザー
    participant SP as サイドパネル（拡張機能）
    participant BG as バックグラウンドスクリプト
    participant PG as ページ（WebMCPツール）

    U->>SP: 自然言語コマンドを入力
    SP->>BG: エージェント起動リクエスト
    BG->>PG: WebMCPツール一覧を要求
    PG-->>BG: ツール定義を返す
    BG->>BG: LLM推論（ローカル）
    BG->>PG: ツール呼び出し
    PG-->>BG: 実行結果を返す
    BG->>SP: 最終応答を返す
    SP-->>U: 結果を表示

このシーケンスは、コマンド入力から結果表示までの一連の処理を示している。推論（LLM推論）がバックグラウンドスクリプト内でローカルに完結する点が、クラウドAPI依存型との本質的な違いである。

推論エンジン選定：ローカル推論とプライバシーの両立

エージェントの推論をどこで実行するかは、プライバシー保護と運用コストの両面で最も影響の大きい設計判断である。WebMCP Local Agentがサポートするプロバイダーは大きく3系統に分かれる。Chromiumが管理するGemini Nano（Chrome Prompt API経由）、ローカルにデプロイしたOllama、そしてクラウドのGemini APIである（WebMCPデモ記事）。

Chrome Prompt API：APIキー不要のローカル推論

Chrome Prompt APIを使用する場合、モデルが一度ダウンロードされれば以降の推論はすべてローカルで完結し、APIキーが不要になる（WebMCPデモ記事）。これは実務上、以下の3点で有利に働く。

コスト：推論ごとに課金が発生しないため、高頻度でのツール呼び出しが前提のエージェント設計でもランニングコストを抑えられる。
プライバシー：プロンプトとツール呼び出しの引数がネットワークを通過しない。個人情報や社内データを扱う場面では、この点がコンプライアンス審査を通過する上で重要な要件になり得る。
レイテンシー：往復RTTがゼロになるため、エージェントループの1反復あたりの推論待ち時間がネットワーク遅延に依存しなくなる。

ただし、モデルのダウンロード自体には初期時間とディスク容量が必要であり、モデルサイズが大きいほど初回起動が遅くなる。また、Chrome Prompt APIはChromium系ブラウザに限定されるため、クロスブラウザ対応が必要な場合は別の手段を検討する必要がある。

Ollama：ローカルサーバーによる柔軟なモデル選択

Ollamaプロバイダーを使用する場合、デフォルトでllama3.1（8B）モデルが推奨されており、ツール呼び出しの検証が行われている（webmcp-local-agentリポジトリ）。8Bパラメータの軽量モデルでも、構造化されたツール呼び出し（関数名と引数の抽出）は実用的な精度で動作するということが確認されている点は重要である。

Ollamaの利点は、モデルを自在に差し替えられる点にある。タスクの複雑さに応じて7Bから70Bまでモデルサイズを調整でき、GPUが利用可能な環境ではより高精度なモデルをローカルで実行できる。一方で、Ollamaサーバーの起動と管理が別途必要であり、Chrome Prompt APIのような「ブラウザに組み込まれた」体験とは運用負荷が異なる。

3系統の比較

以下に、3つのプロバイダーを主要な評価軸で比較する。

プロバイダー	レイテンシー	データ流出リスク	コスト	オフライン対応
Chrome Prompt API（Gemini Nano）	最低（ローカル推論）	なし	無料（APIキー不要）	対応（モデルDL済みなら）
Ollama（llama3.1 8B）	低〜中（GPU依存）	なし	無料（計算資源のみ）	対応
クラウドGemini API	中〜高（RTT依存）	あり（プロンプトが送信される）	トークン課金	非対応

クラウドAPIへの依存を最小化・排除すべきかという問いに対しては、一概に「不要」とは言えない。モデルの能力がタスクの複雑さに届かない場合（例：多ステップの推論や長文の要約）には、クラウドAPIをフォールバックとして併用するハイブリッド構成も現実的な選択肢である。ただし、その場合でもプロンプトに機密情報が含まれないよう、ツール呼び出しの引数をマスクする設計を施す必要がある。

実装パターン：WebMCP統合の多様な手法と選択基準

WebMCPの統合方法は単一ではなく、navigator.modelContextやwindow.webmcpといったネイティブAPI、JSON-RPC形式のpostMessage、HTTPエンドポイント等多様な手法で実装される（AI CEO Simulatorリポジトリ）。どの手法を選ぶかは、セキュリティ要件と開発コストのトレードオフで決まる。

ネイティブAPI：最もシンプルだがブラウザ依存が強い

navigator.modelContextやwindow.webmcpに直接アクセスする方式は、最もコードが簡潔になる。ページ側はツールを登録するだけでよく、エージェント側も標準APIを呼び出すだけで済む。ただし、これらのAPIは特定ブラウザの特定バージョンでしか利用できないため、ブラウザのアップデートや仕様変更によって動作が変化するリスクがある。プロダクト化を前提とする場合、この依存をどのように管理するかが設計上の焦点になる。

postMessage：互換性があるが検証コストが高い

JSON-RPC形式のpostMessageを用いる方式は、ブラウザのネイティブAPIに依存しないため互換性が高い。一方、メッセージの形式定義（メソッド名、引数のスキーマ、エラーコード）を独自に設計する必要があり、エージェント側とページ側の実装が一致していることを検証するコストが生まれる。特に、ツール呼び出しの引数が複雑なオブジェクト構造を持つ場合、シリアライズ/デシリアライズ時の型不整合が原因でsilent failureが発生しやすい。このため、postMessage方式を採用する場合は、メッセージのスキーマ検証を両端で行うことを設計要件として明示すべきである。

document.modelContextのワールド境界という落とし穴

実装で最も頻繁に遭遇する技術的制約は、document.modelContextオブジェクトがページのメインワールド（main world）に存在するため、Chrome拡張機能のコンテンツスクリプトからは直接アクセスできないという点である（webmcp-local-agentリポジトリ）。

この制約を回避するための実装パターンは主に2つある。1つ目は、メインワールドへスクリプトを注入してdocument.modelContextにアクセスし、その結果をpostMessageでコンテンツスクリプトに渡す方式。2つ目は、拡張機能のバックグラウンドスクリプトがchrome.scripting.executeScriptでメインワールドにスクリプトを注入し、ツール定義を取得する方式である。

1つ目の方式は実装が単純だが、注入するスクリプトがページ上の他のスクリプトと同一のワールドで動作するため、ページ側のJavaScriptがwindow上のオブジェクトを汚染した場合に予期しない挙動を引き起こす可能性がある。2つ目の方式はワールドの分離が明確で安全性が高いが、chrome.scripting APIの権限（"scripting" permission）と対象URLの指定（matches）が必要になるため、拡張機能の権限範囲が広がり、Chrome Web Storeの審査で指摘される可能性もある。

実務上の判断基準として、ページが自社管理のものである場合は1つ目の方式で十分であり、サードパーティのサイトにも対応させる必要がある場合は2つ目の方式を採用する方が安全である。いずれにせよ、メインワールドへのスクリプト注入はCSP（Content Security Policy）のscript-srcディレクティブと衝突する可能性があるため、対象ページのCSP設定を事前に確認しておくことを推奨する。

セキュリティ設計：重大な操作とユーザー承認の仕組み

AIエージェントがツールを自律的に呼び出す構造では、モデルの出力が意図しない操作をトリガーするリスクが常に存在する。WebMCP仕様が提供するconsequentialHint注釈は、このリスクに対する最後の防御層として機能する（WebMCPデモ記事）。この注釈がツール定義に付与されている場合、エージェントがそのツールの呼び出しを決定した時点で、ユーザーに対して確認プロンプトが表示され、明示的な承認が得られるまで実行が保留される。

consequentialHintを付与すべきツールの判断基準

すべてのツールにconsequentialHintを付与すれば安全であるが、その場合、ユーザーはエージェントの動作のたびに確認を求められ、実用的な操作体験が得られなくなる。付与すべきか否かの判断には、以下の基準を適用するのが合理的である。

データ削除・上書き：一度実行すると元に戻せない操作（レコードの削除、ファイルの上書き書き込み等）は必ず付与する。
外部へのデータ送信：APIへのPOST、メールの送信、Webhookの呼び出しなど、データをユーザーの管理範囲外に送出する操作は付与する。
設定・権限の変更：システム設定の書き換え、ユーザー権限の昇格、APIキーのローテーション等は付与する。
可逆的な読み取り・検索：データの参照、リスト取得、フィルタリング等、副作用のない操作は付与しない。

この基準の核心は「操作の可逆性」と「データの境界を越えるか」の2軸である。可逆で境界内にとどまる操作はエージェントに自律的に実行させ、不可逆または境界を越える操作は人間の承認を挟む、という設計原則に収束する。

UXとセキュリティのバランス

consequentialHintの適用粒度を誤ると、セキュリティとUXのどちらかを犠牲にする。頻繁に確認プロンプトが表示される場合、ユーザーは次第に確認を無視して「OK」を押し続ける「承認疲労」に陥り、本来防ぎたかった誤操作が起きる可能性がある。逆に、付与しすぎるとエージェントの自律性が失われ、人間の操作と変わらない速度になる。

実務上の推奨として、consequentialHintは「1回のセッション内で最大2〜3回程度表示される」粒度に収めることを目標に設計する。エージェントが複数ステップのタスクを実行する場合、最初の承認で「この一連の操作を許可しますか？」とまとめて確認を取り、その範囲内の操作は追加の確認をスキップするバッチ承認パターンも検討に値する。この場合でも、バッチ承認の範囲を明確に提示し、範囲外の操作が発生した場合は再度確認を取りに行く仕組みを設けることで、安全性と操作体験の両立が可能になる。

実装手順：最小限のPoC構築ステップ

ブラウザ内エージェントのPoCを構築する際は、最小構成から始めて段階的に機能を追加するのが有効です。ここでは、デモアプリ「AI CEO Simulator」の構成を参照しながら、5つのステップでPoCを立ち上げる方法を紹介します。

ステップ1：WebMCPツールを公開するページを作成

まず、エージェントが呼び出せるツールを定義するHTML/JSページを作ります。WebMCPツールはページ上で明示的に公開する必要があり、navigator.modelContextやwindow.webmcpなどのネイティブAPIを通じてツールを登録します。この時点ではツールの実装はダミーで構いません。重要なのは、ツールのスキーマ（引数名・型・戻り値の型）を正確に定義することです。エージェントがツールを選択する際にこのスキーマを参照するため、曖昧な定義は誤ったツール呼び出しの原因になります。

<script>
// ページ上でWebMCPツールを公開する最小例
// 実際のAPI名はブラウザのサポート状況により異なるため、
// 公式ドキュメントで確認すること
if (window.webmcp) {
  window.webmcp.registerTool({
    name: "get_project_status",
    description: "プロジェクトの現在のステータスを返す",
    inputSchema: {
      type: "object",
      properties: {
        project_id: { type: "string", description: "プロジェクトID" }
      },
      required: ["project_id"]
    },
    handler: async (args) => {
      // 実際の処理はここに実装
      return { status: "active", progress: 72 };
    }
  });
}
</script>

この段階で確認すべきことは、ツールが正しく登録され、ブラウザのデベロッパーツールから参照できるかどうかです。ツールが登録されていない場合、エージェントは利用可能なツールを認識できず、ループ内でエラーになります。

ステップ2：拡張機能のマニフェストを設定

Chrome拡張機能「webmcp-local-agent」はManifest V3に対応しており、サイドパネルから自然言語コマンドを入力してエージェントを起動する構成です。マニフェストファイルでは、サイドパネルのHTMLファイルを指定し、バックグラウンドスクリプト（サービスワーカー）とコンテンツスクリプトの連携を定義します。

ここで注意すべきは、前述した通りdocument.modelContextオブジェクトがメインワールドに存在するため、コンテンツスクリプトからは直接アクセスできないという制約です。PoC段階では、拡張機能のバックグラウンドスクリプトからページへメッセージを送信し、ページ側でツール呼び出しを実行する仲介パターンを採用するのが安全です。メインワールドへのスクリプト注入はCSPと衝突する可能性があるため、PoCでは避けることを推奨します。

ステップ3：推論エンジンを統合

推論エンジンの選択は、PoCの目的に応じて決めます。最もシンプルな構成はChrome Prompt API（Gemini Nano）です。モデルが一度ダウンロードされれば、以降の推論はローカルで行われ、APIキーは不要です。初期化処理としては、モデルのダウンロード状態を確認し、ダウンロードが完了してからエージェントループを開始するガードを設けます。

Ollamaを使用する場合は、ローカルでollama serveを起動し、拡張機能側からhttp://localhost:11434へリクエストを送る構成になります。デフォルトでllama3.1（8B）モデルが推奨されており、ツール呼び出しの検証が行われています。PoC段階ではこのモデルで十分ですが、ツール数が多くなる場合はコンテキストウィンドウの制約に注意してください。

ステップ4：エージェントループを実装

エージェントループは、ユーザーの入力を受け取り、推論エンジンにプロンプトを送り、ツール呼び出しの指示が返ってきたらページ上のツールを実行し、結果をプロンプトに追加して再度推論を依頼する、という繰り返し処理です。デフォルトでは最大10回の反復で実行され、設定ファイルで変更可能です。この上限は無限ループ防止とコスト管理の両面で重要です。10回を超えてもタスクが完了しない場合、エージェントはエラーを返してループを終了します。

エラーハンドリングとしては、ツール呼び出しが失敗した場合にそのエラーメッセージをプロンプトに追加し、エージェントに再試行または代替手段を選択させる設計が有効です。また、consequentialHintが設定されたツールを呼び出そうとした場合、ループを中断してユーザーの確認プロンプトを表示し、承認後に再開するフローを実装します。

ステップ5：デモアプリを参照して統合を確認

最終的に、AI CEO Simulatorのような実際のデモアプリを参照し、React 19、TypeScript、Tailwind CSS v4、Vite 6で構成されたフロントエンドとエージェントの統合方法を確認します。このデモはバックエンドを持たないサーバーレス構成であり、フロントエンドがツール定義とUIの提示のみを担当します。PoCで得た知見をこの構成に当てはめることで、実務的なアーキテクチャの妥当性を検証できます。

flowchart TD
    A["ツール公開ページ作成"] --> B["拡張機能マニフェスト設定"]
    B --> C["推論エンジン統合"]
    C --> D["エージェントループ実装"]
    D --> E["デモアプリ参照と統合確認"]

落とし穴と解決策：ブラウザ内エージェントの開発課題

ブラウザ内エージェントの開発は、サーバーサイドのAIサービスとは異なる制約を抱えています。ここでは、PoCからプロダクト化の過程で頻繁に遭遇する課題と、その対処法を整理します。

メモリ制限とパフォーマンス

ブラウザにはタブごとのメモリ上限が存在します。エージェントループが10回反復するたびにプロンプトにツール呼び出しの結果が追加されていくため、コンテキストのサイズが指数関数的に増大する可能性があります。特にツールが返すデータ量が多い場合（例：一覧取得で100件以上のレコードを返す）、数回の反復でメモリが逼迫し、タブが強制終了するリスクがあります。

対策として、ツールの実装側で返すデータを要約・圧縮する（例：一覧の件数とサマリーのみを返し、詳細は別途取得する）、エージェントのプロンプト内で古いツール結果を省略する（スライディングウィンドウ方式）、といった手法を検討してください。また、推論処理自体は非同期で実行されるため、UIのフリーズは起きにくいですが、ツール呼び出しが同期的にブロックする実装は避けるべきです。

クロスブラウザ互換性

WebMCPは現在、Chrome中心の実装です。FirefoxやSafariではnavigator.modelContextやwindow.webmcpが利用できない可能性が高く、プロダクト化前にターゲットブラウザのサポート状況を調査する必要があります。PoC段階ではChrome限定で進めつつ、ブラウザ検知のガード（feature detection）をコードに組み込むことで、非対応ブラウザで適切にフォールバックする設計を最初から入れておくと後の修正コストを抑えられます。

セキュリティポリシーの衝突

企業のWebアプリではCSP（Content Security Policy）が厳格に設定されていることが多く、拡張機能のスクリプト注入やpostMessageのtargetOrigin指定と衝突することがあります。特にscript-srcが'self'に限定されている場合、メインワールドへのスクリプト注入はブロックされます。デバッグに時間を要する典型的な原因であり、PoC環境ではCSPを緩めて動作確認し、本番環境では拡張機能の権限設定とCSPの整合性を事前に検証するワークフローを推奨します。

課題	症状	解決策
メモリ逼迫	タブの強制終了・フリーズ	返答の要約、スライディングウィンドウ
ブラウザ非対応	ツールAPIがundefined	feature detectionとフォールバック
CSP衝突	スクリプト注入がブロックされる	postMessage仲介、CSP事前検証
モデル更新	ツールスキーマの非互換	バージョン管理とマイグレーション

モデルのバージョン管理

ローカル推論の場合、モデルのアップデートは手動または自動更新で行われます。モデルが更新された際に、ツール呼び出しの形式（function callingのスキーマ）が変更される可能性があります。Ollamaのllama3.1（8B）がデフォルトで推奨されていますが、将来的に新しいモデルがリリースされた場合、既存のプロンプト設計が機能しないケースがあります。モデルのバージョンをログに記録し、更新時にツール呼び出しの回帰テストを自動実行するCIパイプラインを構築することを推奨します。

運用と発展：スケーラビリティとメンテナンス戦略

PoCが機能しても、実運用ではツール定義の更新、ログの収集、拡張機能の配布といった運用面での課題が生まれます。ここでは、スケーラビリティとメンテナンス性を確保するための設計指針を示します。

ツールのバージョン管理とプロトコルの進化

WebMCPツールはページ側で定義されるため、フロントエンドのデプロイと同時にツールスキーマが変更されることがあります。拡張機能側がツールを呼び出す際に、スキーマのバージョンを照合する仕組みがない場合、非互換なツール呼び出しが発生し、エージェントループがエラーで中断します。

対策として、ツール定義にversionフィールドを追加し、拡張機能側がページからツールメタ情報を取得した際にバージョンを確認するプロトコルを導入します。バージョンが不一致の場合、エージェントは利用可能なツールリストを再取得し、プロンプトに反映してから処理を再開します。これにより、フロントエンドのデプロイタイミングと拡張機能の更新タイミングがずれても、互換性を保つことができます。

ログとモニタリング

ブラウザ内ではサーバーサイドのログ収集が困難です。エージェントの動作状況（どのツールを呼び出し、何度反復し、どこでエラーになったか）を把握するためには、ローカルストレージ（chrome.storage.local）へのログ出力が基本になります。ただし、ログにユーザーの入力やツール返答が含まれる場合、機密情報漏洩のリスクがあります。ログ出力時にはユーザー入力をハッシュ化またはマスクする処理を挟み、必要最低限のメタデータ（ツール名、呼び出し時刻、成功/失敗、反復回数）のみを記録するように設計してください。

匿名化メトリクスを外部に送信する場合は、ユーザーの明示的な同意を得る必要があります。プライバシー保護の観点から、メトリクスの送信はオプトイン方式にし、送信内容と送信先を拡張機能の設定画面で明示的に表示する設計が望ましいです。

拡張機能の配布と更新

Chrome Web Storeでの公開は、審査基準（権限の必要性、データ収集の明示など）を満たす必要があります。エージェントがユーザーの入力とツール返答を処理する性質上、審査時にデータ処理の説明が求められる可能性が高く、プライバシーポリシーの整備が前提になります。

企業内利用の場合は、社内ポータル経由で拡張機能のZIPファイルを配布し、chrome.managementAPIによる強制インストールと自動更新を適用する方式が実用的です。この方式ではChrome Web Storeの審査を回避できる一方、更新の通知を社内チャネルで行う運用ルールが必要です。

将来展望：ネイティブエージェント連携への備え

WebMCPがブラウザ標準として定着した場合、拡張機能に依存しないネイティブなエージェント連携が可能になります。ChatGPTが組み込みブラウザにおいてWebMCPベースのサイトツールをサポートする機能を追加したことは、この方向性の兆候です。ネイティブエージェントがページ上のツールを直接認識できるようになった場合、拡張機能が仲介する現在の構成は不要になり、ページ側がツールを公開するだけでエージェント連携が完了するようになります。

この変化に備えるため、フロントエンドの設計ではツール定義を拡張機能のロジックから分離し、ページ自体が自己完結的にツールを公開する構成を維持してください。拡張機能は「ユーザーの入力を受け取るUI」と「推論エンジンの管理」に役割を限定し、ツール呼び出しのロジックをページ側に置くことで、将来的なネイティブエージェントへの移行コストを最小限に抑えられます。

まとめ：ブラウザ内エージェントが拓く新しい開発パラダイム

本記事では、WebMCPとローカル推論の組み合わせにより、プライバシー保護とリアルタイム応答を両立するブラウザ内エージェントの実装設計について解説しました。クラウドAPIへの依存を減らすことで、データがユーザーのブラウザ内にとどまる可能性が高まり、ネットワーク往復がない分だけ応答速度の改善が見込めます。Chrome Prompt APIのモデルがダウンロードされればAPIキーが不要になる点、Ollamaのllama3.1（8B）でもツール呼び出しが検証されている点は、ローカル推論の実用性を示す具体的な根拠となります。

技術意思決定者の視点では、このアプローチがもたらすビジネスインパクトは明確です。API呼び出しコストの削減、データ流出リスクの低減、コンプライアンス要件（データローカライゼーションなど）への対応が、アーキテクチャの選択によって同時に実現される可能性があります。特に、顧客データや社内情報を扱うエージェントを構築する場合、データを外部APIに送信しない設計はセキュリティ要件の面で大きな利点になり得ます。

ただし、ブラウザのメモリ制限、クロスブラウザ互換性の欠如、CSPとの衝突といった課題を過小評価すべきではありません。PoC段階でこれらの制約を実際に検証し、プロダクト化に必要なガードやフォールバックを設計に組み込むことが重要です。エージェントループの最大反復回数（デフォルト10回）やconsequentialHintの適用範囲など、設計判断の分岐点は多く、それぞれにトレードオフがあります。これらの判断を「なんとなく」ではなく、利用シーンとリスク許容度に基づいて行うことが、実運用で信頼性の高いエージェントを構築する鍵になります。

ブラウザ内エージェントは、単なる技術トレンドではありません。ユーザーのデータを安全に活用し、リアルタイムに価値を提供する新しいWebの標準となり得る技術です。WebMCPの標準化が進む今、このアーキテクチャの設計判断を早期に行うことが、将来的な競争優位性の源泉になる可能性があります。

参考

本記事は海外の技術トレンド「What If Your AI Agent Never Had to Leave the Browser? (Demo 🚀)」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。