Anthropicが2026年春にベータ提供を開始した「MCP Connector」は、Messages APIにMCPサーバのURLと認証情報を渡すだけで、Anthropic側がクライアント役を肩代わりして実行までを完結させる仕組みだ。これまで必要だった自前MCPクライアントの実装や、Claude Desktopなどフロントエンドの介在を省略できる。本稿ではConnectorの基本動作と、自前クライアントを書き続けてきた立場から見た実利を整理する。
Messages APIに mcp_servers フィールドを追加するだけ
Connectorの使い方は素朴だ。リクエストヘッダに managed-agents-2026-04-01 のベータヘッダを付け、ボディの mcp_servers フィールドにMCPサーバのURLとBearerトークンを記述する。レスポンスにはツール検出・実行のログが含まれて戻ってくる。
これまでMCPサーバを業務で使うには、自分でMCPクライアントを書くか、Claude DesktopなどのMCPホストを介する必要があった。Connectorはこの中間層をAnthropic側に移管した格好で、利用側のアプリケーションは「JSONを組み立ててPOSTする」だけになる。並列実行や状態管理の細かい配線も、利用側コードからは消える。
「裏側で見えないものが増える」と感じるかもしれないが、運用上の取り回しはむしろ軽くなる。MCPの中身に集中する時間が増える、というのが触ってみての率直な印象だ。
自前クライアントを書き続けた半年で溶かした時間
筆者は過去半年で自前のMCPクライアントを2回作っている。1回目はNode製、2回目はGo製。どちらもStreamable HTTPを正しく扱えるようになるまでに、地味に3日ほど溶かした。
具体的にハマる箇所は毎回ほぼ同じだ。SSEのフレーミング、tool_useと結果の対応付け、エラー時のセッション破棄、複数MCPサーバを同時接続する際のスケジューリング。フレームワークがあれば軽くなると思いきや、Streamable HTTP仕様の更新は早く、ライブラリが追従しきれていない時期が交互に訪れる。
Connectorを使えば、これらが全部Anthropic側のサーバ実装に乗っかる。MCPの面白さを試したいだけのフェーズで、低レイヤの配線に時間を持っていかれずに済むのは大きい。
実行性能：GitHub MCPと内製APIの2系統連鎖で1秒台
検証として、GitHub公式のMCPサーバと、社内ツール用に書いた小さな内製MCPサーバの2系統を同時にConnectorに渡し、両方ともStreamable HTTPで公開、認証はBearerに揃えた。
実行自体は速い。GitHubの search_code を呼び、結果から内製APIの lookup_owner を続けて呼ぶような連鎖でも、合計の往復は1秒台で終わる。CLIから直接Claude Codeを叩いていたときと比べて、体感が遜色ない。
地味に助かったのは、エラーレスポンスが「どのMCPサーバで何が失敗したか」明示されて戻ってくる点だ。自前クライアントだと、ツール名から逆引きしてエラーログを追う場面が多かった。Anthropic側で整形されたエラーが返ってくるだけで、デバッグの初動は確実に速くなる。
役割分担としての意味：サーバ側と利用側の境界が綺麗になる
Connectorを使い始めて気付くのは、「MCPサーバを動かすチーム」と「MCPサーバを使うチーム」の境界が明確になることだ。サーバ側は仕様準拠とセキュリティに集中、利用側はAPIを呼ぶだけ。RDBが普及した頃に「ストアドプロシージャを書く人」と「アプリケーション層を書く人」が分かれていった構図と似ている。
業界全体で見ると、MCPサーバは2026年5月時点で2,300本を超え、Claude/Cursor/Windsurf/VS Codeなど200以上の環境で使われている。Connectorはこの裾野の広がりを、クライアント実装の負担を下げる側から支えるレイヤーに位置している。
ベータヘッダが取れて正式版になれば、SaaS各社のMCPサーバ公開はさらに加速するはずだ。利用側がクライアントを書かずに済む構造は、MCPエコシステムの成熟段階を一段引き上げる入口に見える。
