もうMCPサーバは不要なのか？ 代わりになる技術を開発者が提唱：LLM進化で揺らぐ存在価値

MCPはLLMが未成熟な時期に外部サービス接続用として普及したが、AIモデルの高度化で役割が縮小している。あるソフトウェアエンジニアは、多くのMCPサーバを廃し、これを介さない手法を取り入れるべきだと主張した。一体それは何だろうか。

[＠IT]

　「Model Context Protocol」（MCP）は、Anthropicが2024年11月に公開した、AIエージェントを外部サービスやデータ源につなぐプロトコルだ。接続の標準化により、ツールやAPIごとに個別の連携プログラムを書く必要がなくなるため開発コストが削減できる他、一度MCPサーバを作れば、「Claude」や「Cursor」といった異なるAIクライアントで共通して利用できるため相互運用性の向上も図れるといったメリットがある。

　一方で外部システムやローカル環境への強力なアクセス権限を持つため、不正アクセスや脆弱（ぜいじゃく）性対策の管理が不十分だと情報漏えいにつながるリスクがある。また、大規模言語モデル（LLM）が未成熟な時期に外部サービス接続用の技術として普及した背景もあり、ベストプラクティスの蓄積が発展途上であるため、初期・運用コストがかかるというデメリットも指摘されてきた。

　こうしたMCPの“存在価値”について、あるソフトウェアエンジニアが一石を投じた。

　ソフトウェアエンジニアのマハルシ・パテル氏は2026年9月14日（現地時間）、自身のブログでMCPが時代遅れになりつつある理由を考察した記事を公開している。同氏によると、MCPは「AIモデルが今ほど賢くなかった時代に設計された遺物」であり、LLM自体の推論能力やコーディング能力が飛躍的に進化した現在においては以前ほどの価値を感じられなくなっているという。

なぜ「MCP不要論」を提唱？　「エコシステムの肥大化」がもたらした課題

　MCPが登場した2024年末当時、AIエージェント向けワークフローの信頼性は低く、AIモデルの汎用（はんよう）的な推論性能も現在と比べて限定的だった。そのような環境下で、外部サービスとの連携を可能にするMCPは生産性を大きく引き上げ、LLMの普及とともに急速に採用が進んだ。2025年にはAnthropicの主導を離れ、Linux Foundation傘下の「Agentic AI Foundation」に寄託されている。

　しかしMCPの導入が広がるにつれて新たなボトルネックが顕在化した。利用者が多数のMCPサーバを環境に追加した結果、各サーバが提供する複数のツール定義やスキーマがプロンプトを圧迫する「コンテキスト肥大化」を引き起こしたのだ。

　開発現場ではこの問題を回避するため、「Composio」や「MintMCP」「Pipedream」といったプラットフォームを活用し、認証情報の一元管理やAIエージェントに渡すツール定義を最小限に絞り込む検索・実行パターンなどを工夫してきた。

　しかしパテル氏は、こうした対策について「短期的には有効だが、AIモデルの急速な進化を十分に考慮していない」と警鐘を鳴らす。MCPサーバの監視やスキーマ管理、呼び出し精度の担保といった複雑な仕組みが、かえって過剰なシステム構成を生み出しているという。

AIモデルの自律的API呼び出し能力がMCPを代替する

　パテル氏が「MCP不要論」を唱える最大の理由は、主要なAI開発企業が目指してきた通りにLLM自体の実行能力が向上した点にある。現在の先端モデルは、コンピュータで直接コードを実行し、大規模なコードベースを理解して自律的にタスクを遂行できる。

　プログラミング作業のためにスクリプトを記述・実行する訓練を重ねた結果、LLMは未知のAPIであってもドキュメントを読み解いて直接呼び出し、複数のサービスを組み合わせるスクリプトを最小限の人間の介入で構築できるようになった。Cloudflareも、LLMに一連のAPI呼び出しをスクリプトとしてまとめさせ、サンドボックス環境で実行させるアプローチ「Code Mode」を発表している。

　さらに、AIモデルは自ら「--help」コマンドを実行してCLIツールの使い方を探索・把握できるようになった。リモートサービス向けのMCPサーバの多くは、実質的に既存のWeb APIをラップした構造にすぎない。ドキュメント化されたAPIやCLIがある環境であれば、仲介役としてのMCPサーバを介在させる必然性は薄れているという。

HTTP APIとCLIの直接活用へ移行するための標準化アプローチ

　パテル氏は今後の展望として、多くのMCPサーバを廃止し、ターミナルへのアクセス権を持つエージェントが既存のHTTP APIやCLIを直接利用する構成に移行すべきだと提言する。

　課題として、CLIが返すJSONやXMLなどの出力が冗長になり、トークン消費量を増加させる点が挙げられるが、これらはHTTPの標準プロトコルを活用することで解決できるとしている。具体的には、エージェントがアクセスする際の標準的な取り決めとして、以下の2点を提示した。

• 「Accept: text/Markdown」ヘッダによるコンテンツネゴシエーション：ドキュメントサイトなどを中心に、リクエストヘッダとして「Accept: text/Markdown」を解釈するサーバが増加している。HTMLの代わりにレンダリング済みのMarkdownテキストを直接返すことで、トークン消費を抑えつつエージェントが解釈しやすい形式で情報を提供できる
• 「Accept-Language」ヘッダを活用した言語指定：Vercelのエンジニアが提唱し、ECプラットフォームを手掛けるShopifyのドキュメントなどで採用が進んでいる手法。クライアントが希望するプログラミング言語（Pythonなど）をヘッダで明示することで、ドキュメントサーバが汎用的な説明ではなく、該当言語向けのソフトウェア開発キット（SDK）に特化したサンプルコードを優先して返す

　共通プロトコルの標準化がインターネットの発展を支えてきたのと同様に、AIエージェント環境においても、既に成熟しているHTTP APIや標準仕様に回帰することが合理的であるとパテル氏は述べる。「AIエージェントは既に賢く、自らスクリプトを記述し、必要な情報を直接要求できる。MCPの複雑な仕組みに固執するのではなく、HTTP APIとCLIの直接利用へかじを切るべきだ」と同氏は結論付けた。