Model Context Protocol（MCP）

MCPは何のためにあるか

共通の規約がなかった頃は、アシスタントとツールの組み合わせごとに専用の統合が必要でした。二度書き、永遠に保守する作業です。アシスタントが五つ、ツールが二十あれば、個別の接続が百通りになります。MCPはこれを掛け算から足し算に変えます。ツールの作者はサーバーを一つ書き、アプリケーションの作者はクライアントを一つ書けば、どちらの側の何もが相手側の何とでも話せます。Anthropicが2024年末にオープン標準として公開し、以後その枠をはるかに超えて採用されてきました。性質としては製品APIというよりデバイスドライバのインターフェースに近く、価値は「何ができるか」ではなく「形について全員が合意した」ことにあります。

構成はクライアント・サーバーです。モデルを抱えるアプリケーションがクライアントで、公開したい機能はそれぞれサーバーとして動き、提供内容を機械可読な形で記述します。モデルは選択肢を見て選べます。トランスポートには依存せず、同じマシン上のローカルプロセスでも、HTTP経由で到達するものでも構いません。だからこそ同じ統合が、デスクトップのアシスタントでも、サーバー上で動くAIエージェントでも、コーディングツールでも、書き直しなしに動きます。

サーバーが公開するもの

サーバーが提供するものは三種類あり、自分で作るときはこの区別が効いてきます。

• ツール — モデルが呼び出せる操作。メッセージを送る、テーブルを検索する、レコードを作る。結果が伴うのはここで、慎重に扱うべき対象です。
• リソース — クライアントが文脈に取り込めるデータ。ファイル、文書、一行のレコード、ページの中身など。モデルが「する」ことではなく、与えられる読み取り専用の材料です。
• プロンプト — 人が意図して選ぶ、再利用可能でパラメータ化された指示。モデルが自分から手を伸ばすものではありません。

この規約が解決しないこと

接続の標準は配管を取り除きますが、難しい部分はそのまま残ります。実務で最初にぶつかるのは、ツールを持つこと自体が無料ではないという事実です。モデルが呼べる機能はすべてモデルに説明する必要があり、その説明は作業そのものと同じ限られた文脈を占めます。カタログが大きくなるほど、静かに本題と場所を奪い合うのです。AgentCeres — agentceres.com のAIグロースオフィサー — で顧客向けのエージェントを作る中で、まさにここに突き当たりました。利用可能な機能が一定数を超えると、カタログを要約しなければ収まりません。つまり統合を一つ増やすことは、誰も使わなくても何かを消費します。結局のところ技術的な規律とは、エージェントが何に手を届かせるべき*でない*かを決めることでした。

二つ目の欠落は権限です。規約はツールの呼び方を定めますが、このエージェントが、この顧客のために、いま、それをしてよいのかについては何も言いません。表計算を読むツールと、企業のソーシャルアカウントに投稿するツールは、規約から見れば同一で、事業から見ればまったく別物です。その境界は自社の製品側に属します。だから私たちの側では、公開的な結果を伴うものはすべて、機能がどう接続されたかにかかわらず、人が立つ承認ゲートの手前で待ちます。