N個のツールをM個のモデルにつなぐには、従来N×M個の適応実装が必要でした。MCPはツール側とモデル側を分離し、それぞれが一度プロトコルを実装すれば相互接続できるようにします。本稿ではその設計上のトレードオフ、ブラウザ環境とページ操作の抽象化、そして現時点で未解決の課題を説明します。
Agentが実際に作業を行うと、最終的にはブラウザに行き着くことが多くなります。ログイン、投稿、データ取得、フォーム入力などです。技術的に難しいのはクリックできるかどうかではなく、ブラウザをAgentに渡すときの接続コストです。
N×Mの適応地獄
市場にN個のツールとM個のモデルがあるとします。ツール提供側は各モデル向けに接続コードを書く必要があり、モデル側も各ツール向けの適応レイヤーを用意しなければなりません。双方が別々に保守するため、実装総数はN×Mになります。
問題は掛け算になることです。ツールが1つ増えても作業が1つ増えるだけではなく、そのツールをすべてのモデルにつなぐ必要があります。逆にモデルのバージョンが変わると、すでに接続済みのツールも再検証が必要になる場合があります。どれほど優れた機能でも、特定モデル向けの適応がなければ利用できず、ツールは流通の途中で止まってしまいます。
初期には、それぞれが独自実装するしかありませんでした。同じ処理でも、環境一覧の取得、ブラウザの起動、ページの読み取りを呼び出し元ごとに書き直す必要があり、ロジックもそろいません。待機処理をクライアント側に置く実装もあれば、サーバー側に置く実装もありました。
プロトコルが両側を分離する
MCP（Model Context Protocol）は2024年末に公開されました。ツールの検出と呼び出しを標準形式で定義し、何を公開するか、パラメータをどう記述するか、どのような構造を返すかをプロトコルに組み込みます。
構成は、AgentがMCP Clientに接続し、Clientがプロトコルに従って複数のMCP Serverへ接続し、その背後に実際の機能がある形になります。実装量はN×MからN+Mへ減ります。モデル側はクライアントを一度、ツール側はサーバーを一度実装すればよくなります。
役割は3つだけです。Hostはモデルを実行するアプリケーションで、クライアントを起動します。Clientはプロトコルクライアントの実装で、通常はServerごとに1つ対応します。Serverはツール提供者が実装し、機能を標準化されたツールとして公開します。
通信方式は現在2種類です。ローカル方式は標準入出力を使い、クライアントとサーバーが同じマシン上にあります。経路が短く設定も少ないため、自動化でよく使われます。リモート方式はHTTPまたはWebSocketを使い、分散配置に向きますが、認証とネットワーク境界を別途慎重に設計する必要があります。
ブラウザでは3つの層が公開される
ブラウザ環境をプロトコルにつなぐと、公開される機能はおおむね3層に分かれます。
最上位は環境です。アカウント内の環境一覧を取得し、設定に基づいて新規作成し、指定環境を起動し、ネットワーク出口を割り当て、使い終わったら停止します。以前は各社のAPIに分散していた操作が、今ではモデルが検出して呼び出せるツールになります。起動後には通常、ポートやWebSocketアドレスなどのデバッグエンドポイントが返され、それをSeleniumやPuppeteerなどのドライバーへ渡せます。
中間はページです。アドレスを開き、DOMまたはアクセシビリティツリーを読み、タブを切り替え、スクリーンショットを取得します。
最下位は操作です。クリック、入力、スクロール、条件が成立するまでの待機、ポップアップ処理などです。
重要な変化は操作数ではありません。環境が、自分で書かなければならないコードから、Agentが自ら選んで使えるリソースに変わることです。目標だけを明確にすれば、新しい環境を作るか既存環境を再利用するか、どの順番で呼び出すかをAgentが決められます。複数環境を並行利用すると特に明確で、スケジューリングはスクリプトにハードコードするのではなく、プロンプトに記述できます。
現時点でまだ解決されていないこと
プロトコルが解決するのは接続であり、正しさではありません。見落とされやすい点がいくつかあります。
ツール記述の品質が呼び出し結果を左右します。パラメータが間違っていたり、誤ったツールを選んだりしても、プロトコルは助けてくれません。ツール数が増えると記述自体がコンテキストを圧迫するため、数と粒度のバランスも必要です。粒度が粗すぎると1つのツールが何をできるかモデルに伝わりにくく、細かすぎると先にコンテキストが埋まります。
権限と監査もまだ初期段階です。かなりのServerがローカル単一マシン構成で、起動時から大きな権限を持ち、細かな認可や呼び出し記録が不足しています。リモート方式では、誰が接続でき、何を見られるのかをまず決める必要があります。
ページの不安定さも消えません。要素が見つからない、読み込み順序が安定しない、ログイン状態が期限切れになる、CAPTCHAが出るといった問題には、引き続き待機、再試行、フォールバック処理が必要です。プロトコルが統一するのは入口だけです。
エコシステムの成熟度にもばらつきがあります。Serverごとに対応リソース種別、返却構造、エラーコードが完全には一致しません。複数Serverを組み合わせて1つのタスクを実行する場合、オーケストレーションロジックは依然として自分で書くことが多くなります。プロトコル自体も進化中なので、バージョン間の挙動差に注意が必要です。
もう1つ明確にすべき境界があります。プロトコルが扱うのはモデルがツールをどう呼び出すかであり、タスクそのものが適法・適切かどうかではありません。データ取得に許可があるか、アカウントの利用目的が正当か、プラットフォーム規則に反していないかは、それぞれ独立した判断であり、接続が滑らかかどうかとは別問題です。
複数環境を使う場面では、環境同士が分離されているか、ネットワーク出口・タイムゾーン・言語が一体として設定されているかの方が、接続方法より結果に大きく影響することがあります。PurpleMarkは環境分離の層で、AIツールから呼び出せる環境作成、起動、ネットワーク設定のインターフェースを提供し、同一クライアントから調整できます。
本稿は技術原理の説明のみを目的としています。関連するプロトコルとツールは、法令やルールを守って使用してください。
