【実録】月3億DLの『MCP』を自作してぶつかった壁と、Anthropic公式が示す5つの『最適解』

MCP SDKのダウンロード数が月3億回を超えた。年初から3倍。

Anthropicの公式ブログにさらりと書かれていた数字だけど、自分でMCPサーバーを実装した身として、これの意味することを考えてみたら、けっこう面白かった。

「プロトコルが普及する」というのは、つまり「みんながそのルールに従って作り始める」ということで、それが月3億回のダウンロードという形で現れている。

AIエージェントが本番環境で動くようになったのは、MCPのおかげだと思っている。その理由が、公式ブログを読んでやっと言語化できた。

AIと外部システムを繋ぐ、3つの方法

まず背景から。AIエージェントが外部のシステム（Google DriveやGitHub、データベースなど）と連携するには、方法が3つある。

Anthropicのブログ「Building Agents That Reach Production Systems with MCP」では、これをきれいに整理していた。

直接APIを叩くのが一番シンプル。でも、サービスが増えるたびに実装も増える。10のツールに繋ぎたければ10通りの実装を書く必要がある。「M×N問題」と呼ばれているやつで、エージェントとツールの組み合わせが爆発する。

CLI経由は軽量で速い。でも、ファイルシステムやシェルが前提なので、クラウドのコンテナ環境や本番サービスには繋ぎにくい。

MCPを使うのが、今の標準的な答えになりつつある。プロトコルを共通化することで、一度MCPサーバーを作れば、MCPクライアントがあるAIなら何にでも繋げる。書く量は増えるけど、スケールする。

自分で作って初めてわかった、MCPの難しさ

自分がMCPサーバーを作り始めたのは半年ほど前。「Claude Codeから内部ツールに通知を送りたい」という、わりと単純な動機だった。

最初に詰まったのは、認証だった。

直接APIなら、APIキーをどこかに置いておけばいい。でもMCPサーバーをリモートで動かす場合、OAuthの認証フローを実装する必要がある。ドキュメントを読みながら3日かけてやっと動かしたとき、「これ、毎回やるの？」と正直思った。

ツール定義の設計でも悩んだ。「APIのエンドポイントを1:1でツールにする」のか、「『メッセージを送る』という意図でツールをまとめる」のか。最初はAPIを1:1でツール化していたら、エージェントが混乱して使い分けられなかった。設計をやり直すことになった。

エラーハンドリングも地味に手間がかかった。MCPサーバーが落ちたとき、エージェントがどう振る舞うかを設計しないといけない。

「なんでこんなに面倒なんだろう」と思いながら実装していた。その感覚の正体が、最近の公式ブログを読んで全部繋がった。

Anthropic公式が示す「良いMCPサーバー」5つの設計

ブログには5つの設計パターンが書かれている。自分が悩んでいたことへの、ほぼ完全な答えだった。

1. リモートサーバーを作る

ローカルで動かすのではなく、リモートサーバーとして公開することで、Web・モバイル・クラウドのどこからでも使えるようになる。「本番で動く」とはそういうことで、ローカル限定のMCPサーバーは本番では使えない。

2. ツールはAPIと1:1にしない

「APIのエンドポイントをそのままツール化しない」と明記されていた。ユーザーの意図でグループ化する。「メッセージを送る」「チャンネルを検索する」という粒度にする。これは自分が失敗して気づいたことと完全に一致していた。

3. 数百のオペレーションが必要なら「コード生成」を使う

これは目から鱗だった。ツールの数が増えすぎる場合、エージェントにコードを生成させて実行させる設計にする。APIをラップしたSDKをサンドボックスで実行するイメージで、ツールの爆発を防げる。

4. Rich semanticsでUIを返す

MCPは単なるデータのやりとりだけでなく、インタラクティブなUIを返せる（MCP Apps）。フォームや確認ダイアログをエージェントとユーザーの間に挟める。「エージェントが勝手に何かを実行してしまう」問題への対策として、これは実際に役立ちそうだと思った。

5. 標準化されたOAuth（CIMD）を使う

自分がAPIキーで済ませたあの認証まわりへの答えが、ここにあった。CIMD（Client ID Metadata Documents）という仕組みで、OAuth認証を標準化する。実装コストが大幅に下がるらしい。次に作るときはこれを最初から組み込む。

コンテキストコストを抑える2つのクライアントパターン

ツールの数が増えると、エージェントが全ツールの定義を読み込むだけでトークンを大量に消費する。ブログではクライアント側のパターンも2つ紹介していた。

Tool search（ツール検索）は、必要なときだけツール定義をロードする方法。トークン使用量を85%以上削減できるとのこと。エージェントが「今何が必要か」を判断してからツールを取得する設計で、精度も落ちないという。

Programmatic tool calling（プログラム的ツール呼び出し）は、エージェントのレスポンスをサンドボックスで処理してから結果を返す方法。複雑なワークフローでトークンを37%削減できる。

どちらも「ツールが多くなってもスケールする」ための工夫で、本番運用を意識した設計だと思った。ツールを増やすほど逆にコストが下がっていくというのが面白い。

MCPが「インフラ」になりつつある

ブログの末尾近くに書かれていたのが、MCPがすでにClaude Code・Claude Managed Agents・Claude Coworkのインフラとして使われているという事実だった。

「毎日何百万人もがMCPを使っている」という表現で書かれていた。

つまりMCPは「今後検討する技術」ではなく、「すでにAnthropicのプロダクトが依存している技術」になっている。

自分がMCPサーバーを作り始めたのは「Claude Codeに繋ぎたいから」だった。その判断は間違ってなかったと確認できた気がした。

MCPサーバーを作るなら、今がちょうどいいタイミングだと思っている。プロトコルが固まり、公式の設計ガイドラインが出て、月3億回のダウンロードという土台がある。

次に作るときは、CIMDのOAuth認証と、ツールのintentベース設計を最初から組み込むつもり。参考になれば嬉しいです。

#takibiラボ #takibiラボ_AI #MCP #ClaudeCode #AIエージェント