MCPはAPI経済を飲み込む

Model Context Protocolは、RESTがSOAPにしたことをAPI統合に対して行っている。手で書かれた統合レイヤーを、エージェントが自分で発見し利用できるものに置き換えている。

ほとんどのシニアエンジニアはMCPサーバーを初めて見ると、JSON-RPCのラッパーだと切り捨てる。実際そうだ。2005年のHTTP上のRESTも同じだった。

MCPが実際に答えている問いは、RESTが20年間うまく答えられなかった問いと同じだ。あるソフトウェアは、まだ見たことのない別のソフトウェアに自らの機能をどう公開するのか？RESTの答えは「ドキュメントを読んでクライアントを書け」だった。その答えは読み手が人間の開発者である場合にしか成立しない。

REST APIはクライアントコードを書く人間のために作られた。エンドポイント、ドキュメント、正しい順序で正しいパラメータを渡す手書きのfetchコール。すべての統合がオーダーメイドだ。

これは消費者が人間の開発者である限りうまく機能する。消費者がLLMになると壊れる。LLMはSwaggerファイルを読んで12個のエンドポイントのうち3つを連鎖させる、ということをしない。入力として機能の記述が必要だ。ツール名、何をするか、入力スキーマ、出力スキーマ、副作用。

MCPはまさにその形を与える。`tools/list`呼び出しは、モデルが推論時に推論できるJSONスキーマと共にすべての機能を返す。SDKなし、コード生成なし、オンボーディングチケットなし。

MCPを変革的にしているのは、個別の機能ではない。実行時の構成だ。

すべてのサービスがMCPツールとして自らを公開すると、エージェントは推論時にそれらを発見し連鎖できる。サポートエージェントがCRMから読み、課金サービスに問い合わせ、Slackメッセージを書き、チケットを起こす——30秒前に知ったばかりのツールを使って。ハードコードされた統合なし。プロバイダー固有のミドルウェアなし。

これはエージェントに適用されたUnix哲学だ。小さく焦点を絞ったツールが組み合わさる。作曲家はもはやシェルスクリプトではない。どのツールをどの順序で組み合わせるかを推論できるモデルだ。

エージェントを任意のツールに接続することを自明に簡単にすると、悪意のあるツールへの接続も自明に簡単になる。ツールポイズニング——説明が一つの動作を約束し、実装が別のことをする——はMCP時代のSQLインジェクションだ。

今日MCPサーバーを出荷しているほとんどのチームはこのことを考えていない。動くようにすることに集中している。ウェブの歴史におけるすべての主要なセキュリティ危機は同じように始まった。

MCP経済で勝つチームは、最も速く出荷するチームではない。痛い目に遭う前にツールの来歴、出力のサニタイゼーション、サンドボックスを解いたチームだ。

他のソフトウェアが消費するソフトウェアを構築しているなら、もうMCPインターフェースを出荷しているべきだ。経済がそれを強いる。

REST統合は開発者に数日かかる。MCPツールは数分だ。統合が100倍安くなると、同じ統合が100倍手に入るのではない——以前は構築する価値がなかった統合のカテゴリ全体が手に入る。StripeはすでにMCPサーバーを出荷している。Linearも。Supabaseも。

すべてのSaaSはいずれMCPツールを公開する。すべての内部サービスはMCPインターフェースを持つ。唯一の本当の問いは、競合より先に出荷するかだ。