https://mcp-b.ai/
https://github.com/MiguelsPizza/WebMCP
目次
はじめに
現代のAIによるブラウザ自動化は、画面を読み取りボタンをクリックするロボットを操作するようなアプローチが主流です。この方法は動作が遅く、UIの僅かな変更で機能しなくなる脆弱性を抱えています。
この課題に対する一つの答えとして、AIとツール間の対話方法を標準化するModel Context Protocol (MCP) が存在します。そして今、その進化形として MCP-B (Model Context Protocol for the Browser) が登場しました。
MCP-Bは、このプロトコルをブラウザの内部に直接埋め込むという革新的なアプローチを取ります。本記事では、MCP-BがどのようにしてウェブサイトをAIにとってネイティブで、安全かつ高性能なツールへと変貌させ、業界が直面していた認証という重大なボトルネックを解消するのかを体系的に解説します。
Part 1: ブラウザにおけるAIの課題
Chapter 1: 「マウス付きOCR」問題
現在のAIブラウザ自動化技術が直面する根本的な課題は、その動作原理にあります。
- 既存の自動化技術は、画面の視覚的解析に依存するため、本質的に低速で不安定です。
多くのソリューションは、まるで「マウスを備えたOCR（光学的文字認識）エンジン」のように機能します。🤖🖱️➡️🐢
- ウェブページのスクリーンショットを撮るか、DOMを解析する。
- LLMに「『カートに追加』ボタンはどこか？」と問い合わせる。
- モデルが座標やセレクタで応答する。
- その情報に基づき、クリックを実行する。
- ページの更新を待ち、再びスクリーンショットを撮って状態を確認する。
このプロセスは、アクションごとにモデルとの複数回の往復通信を必要とし、高レイテンシと高コストを招きます。さらに、UIデザインが少しでも変更されると、システム全体が容易に破綻する可能性があります。これは、構造化されたデータではなく、移ろいやすい視覚表現に依存しているためです。
Chapter 2: MCP標準とその認証の壁
この問題を解決するため、MCPはAI（クライアント）とツール（サーバー）が対話するための標準化された方法を提案しました。しかし、従来のMCP実装にも大きな障壁が存在しました。
- MCPは有望な標準ですが、その認証方法は複雑で、開発者とユーザー双方にとって高い導入障壁となっていました。
従来のMCP実装は、主に2つのアプローチに分かれます。
| アプローチ | 説明 | 課題 |
|---|---|---|
| ローカルMCPサーバー | 開発者のマシン上でプロセスとして実行される。 | APIキーや環境変数の管理が必要。ユーザーごとの設定が煩雑。🔑 |
| リモートMCPサーバー | クラウド上でサービスとして実行される。 | 複雑なOAuth 2.1フローの実装が必須。マルチテナントアプリでのデータ漏洩リスク。🔐 |
これらの認証要件は、特にウェブアプリケーションの文脈でAIを活用しようとする際に、大きな障害となっていました。ウェブサイトが既に持つ洗練された認証メカニズムをAIが利用できず、二重の認証システムを構築・管理する必要があったのです。
Part 2: MCP-B - パラダイムシフトの到来
要約
このパートでは、MCP-Bがどのようにして従来の問題を解決するのか、その革新的なアーキテクチャと基本原則を解説します。MCP-Bは、MCPサーバーをリモートやローカルのプロセスから、ブラウザのタブそのものへと移行させることで、パラダイムシフトを引き起こします。
Chapter 1: 中核概念 - ブラウザ内蔵型MCPサーバー
MCP-Bのブレークスルーは、その名の通り、MCPサーバーをブラウザのウェブページ内で直接実行するというアイデアにあります。
- MCP-Bは、ウェブサイトの既存の認証セッションに「便乗」することで、AIの認証問題を根本的に解決します。
これは、ウェブページのJavaScriptコンテキスト内でnew McpServer(...)を実行することを意味します。このアプローチがもたらす最大の利点は、認証がただ機能することです。ユーザーがウェブサイトにログインしていれば、そのセッション（CookieやJWTなど）をMCPサーバーがそのまま利用できます。
これは、AIに毎回ビジター登録をさせる代わりに、正社員のIDカードを渡すようなものです。AIはユーザーと全く同じ権限で、設定不要で即座にウェブサイトの機能を利用可能になります。🌐✅➡️🚀
Chapter 2: アーキテクチャの深掘り
MCP-Bのエコシステムは、相互に連携する複数のコンポーネントで構成されています。以下の図は、拡張機能内のAIアシスタントがウェブページのツールを呼び出す際の基本的なフローを示しています。
- コアメッセージ: MCP-B拡張機能が中枢として機能し、各タブで実行されるMCPサーバー群からのツールを集約・仲介します。
主要コンポーネント:
- Tab MCP Server: ウェブページ内で動作し、サイト固有の機能をツールとして公開します。
- MCP-B Extension: 中枢神経系のように機能するブラウザ拡張機能。開かれている全タブのツールを集約し、リクエストを適切なタブにルーティングします。
-
Transports (
TabTransport,ExtensionTransport):postMessageやchrome.runtime.messagingといったブラウザAPIを利用し、コンポーネント間の安全な通信を担います。
Chapter 3: 実装の実際
MCP-Bをウェブサイトに導入するプロセスは、驚くほどシンプルです。約50行のコードで、ウェブサイトをAI対応にすることが可能です。
McpServerのインスタンス化、ツールの定義、そしてTabServerTransportへの接続という3ステップで、ウェブサイトはAIから利用可能なツールを提供できます。
以下のは、ウェブサイトにMCPサーバーを実装するための手順を構造化したものです。
この実装の鍵は、fetchが呼び出される際に、特別な認証処理を記述する必要がない点です。ブラウザが自動的にそのドメインのCookieや認証ヘッダーを付与するため、既存のAPIをそのまま、かつ安全にAIへ公開できます。zodによるスキーマ定義は、型安全性を保証し、LLMが正しい形式でツールを呼び出すことを助けます。
Part 3: 高度な応用と未来の可能性
要約
このパートでは、MCP-Bが可能にする、単一サイトの自動化を超えた強力なワークフローや設計パターンを探求します。これらは、MCP-Bが単なるツールではなく、AIとウェブの連携における基盤技術であることを示唆しています。
Chapter 1: クロスサイト・ワークフローの実現
MCP-Bの真価は、複数のウェブサイトにまたがる複雑なタスクをAIが実行できる点にあります。
- MCP-B拡張機能がコンテキストマネージャーとして機能し、異なるドメインのツールをシームレスに連携させることが可能です。
ユースケース例:
ECサイトのカートに入っている商品の価格を、価格比較サイトで調べる。
以下は、このクロスサイト・ワークフローを示しています。
このフローにおいて、shop.example.comとpricewatch.comは、それぞれ自サイトの認証情報を用いてAPIを呼び出します。MCP-B拡張機能は、サイト間のナビゲーションと、LLMの対話コンテキストの維持を担当します。これにより、AIはユーザーの権限内で、複数のサービスを横断した価値あるタスクを実行できます。
Chapter 2: コンテキストエンジニアリング - LLMのためのUI設計
優れたウェブサイトが一度にすべての情報を表示しないように、LLMにもタスクに関連するツールのみを提示することが、その性能を最大化する鍵となります。
- MCP-Bは、ウェブページのUI状態と連動して動的にツールを提示・非表示にすることを可能にし、LLMにとって最適な「作業環境」を設計できます。
これは「コンテキストエンジニアリング」と呼ばれ、LLMに100個の道具箱を渡すのではなく、目の前の作業に必要な数個の道具だけを手渡すアプローチに似ています。
実装パターン (React Hooksの例):
Reactのコンポーネントライフサイクル（useEffect）を利用して、特定のUIが表示されている間だけツールを登録し、非表示になったら登録解除する、といった設計が可能です。
以下は、この動的なツール管理の構造を示しています。
このアプローチは、LLMに提供するコンテキストを最小限かつ最適に保ち、ツールの誤選択を防ぎ、モデルの推論精度を向上させる効果が期待できます。これは、私たちが人間に対して行うUI/UXデザインの原則を、LLMとの対話に応用するものと言えるでしょう。
Chapter 3: セキュリティと信頼モデル
新たな技術にはセキュリティに関する考察が不可欠です。MCP-Bは、ブラウザの堅牢なセキュリティモデルを基盤としています。🛡️
- MCP-Bのセキュリティは、ウェブサイトがユーザーに機能を公開する際の既存の信頼モデルを拡張したものであり、リスクはユーザーの権限範囲内に限定されます。
ウェブサイト開発者にとっての考慮点
- 公開するツールは、ユーザーがボタンやフォームを通じて実行できる操作の範囲内に留めるべきです。
- ツールは、ページが持つ既存の認証コンテキスト内で実行されます。
- ユーザーの状態（例：管理者か否か）に基づいて、公開するツールを制御することが可能です。
ユーザーにとっての考慮点
- ブラウザ拡張機能のインストールは、その開発者への信頼を伴います。
- すべてのツール呼び出しは、原理的に監査可能です。
- どのサイトがどのツールを公開しているかを確認できます。
- 現状の設計では、重要な操作には人間が介在します。
もしウェブサイトが「全ユーザーデータを削除する」ツールを公開すれば、それはMCP-Bのリスクというより、そのウェブサイト自身の設計上の判断です。これは、ページ上に巨大な赤い削除ボタンを設置するのと本質的に変わりません。MCP-Bは、これらの機能をLLMが利用できるようにする「橋渡し」の役割を担います。
おわりに
MCP-Bは、単なるブラウザ自動化ツールではありません。それは、AIがウェブと深く、安全に、そして効率的に統合するための基盤となるプロトコル実装です。
- 速度と信頼性: 画面解析を排し、直接APIを呼び出すことで、ミリ秒単位の実行と高い信頼性を実現します。
- ゼロコンフィグ認証: ブラウザの既存セッションを利用することで、最も厄介なハードルであった認証問題を解消します。
- 高度なワークフロー: サイト横断や動的なコンテキスト提供により、これまでにない複雑なタスクの自動化を可能にします。
AIアシスタントの未来は、複雑なOAuthフローやインフラ管理の中にあるのではなく、私たちが日々利用しているブラウザの中にこそあるのかもしれません。MCP-Bは、その未来を実現するための、具体的で強力な一歩を示しています。
関連リンク:
- Chromeウェブストア: @mcp-b/extension
- GitHubリポジトリ: MiguelsPizza/WebMCP