Model Context Protocol（MCP）に関するニュースを追っていた方にとって、最近の MCP バッシングというトレンドは驚くべきことではないでしょう。Perplexity が MCP から撤退するといったニュースや、Cloudflare が MCP サーバー側にコマンドラインインターフェース（CLI）を組み込んだ「Code Mode」をリリースしたといった動きは、技術系インフルエンサーたちが MCP の真の課題——つまり、ツールやツールスキーマのすべてが毎回エージェントの大規模言語モデル（LLM）のコンテキストに注入されることによるコンテキスト肥大化——に気づき始めたことを示しています。

CLI は、MCP のコンテキスト肥大化問題をすべて解決する万能薬として提案されており、インターネット上の一部では「MCP は標準として終わった」と主張する声さえ上がっています。

ツールコンテキストの肥大化という問題の指摘自体は正しいものの、MCP を完全に捨てて CLI に切り替えるという解決策は、逆に過剰反応のように感じられます。

MCP が導入された理由

まず、MCP によるコンテキスト肥大化の問題について簡単に整理しておきましょう。2024 年末に Anthropic が MCP を標準として提案した当時、外部データを LLM に接続するプロセスは断片化していました。

MCP は、JSON-RPC ベースのインタラクション方式を提案することで、この断片化したエコシステムの標準化を目指し、多くの企業から熱狂的に採用されて業界内で急速に支持を集めました。ベンダーやオープンソース開発者は、さまざまな製品を LLM に接続するための MCP サーバーを次々とリリースしていきました。MCP 標準自体も、初期実装における複数の課題を修正しながら、多くの重要なリリースを重ねてきました。

MCP 標準の初期リリースにおける最大の問題の一つは、stdio を使って MCP を実行できる点でした。これにより、ローカルの stdio を介して任意の LLM（またはエージェント）が MCP リソースと通信できるローカルプロセスを素早く立ち上げられる一方、数多くのセキュリティ上の課題をもたらしました。幸いなことに、この設定方法は現在非推奨となっており、後続の MCP リリースではリモート MCP サーバーへの接続方式として、よりシンプルなストリーミング HTTP 方式が標準化されました。ベンダーが公式のリモート MCP サーバーを公開している限り、ローカルの stdio ベースの MCP サーバーを使う必要はありません。

MCP におけるコンテキスト肥大化の問題

現在、MCP サーバーにおける最大の課題（セキュリティを除く）は、MCP サーバーが公開するツールが LLM のコンテキストウィンドウにどのように注入されるか、という点です。MCP 標準が導入され、各ベンダーが MCP サーバーの公開を始めた当初、一般的なアプローチは既存の公開 API を LLM 向けの個別ツールとしてラップすることでした。この変換は通常 1 対 1 で行われ、API エンドポイントやアクションごとに 1 つのツールが割り当てられました。その結果、数十、あるいは数百ものツールを備えた MCP サーバーが生まれました。これがコンテキスト肥大化の問題を引き起こします。MCP 接続が確立されると同時に、それらの数十（あるいは数百）のツールと、そのスキーマの説明・引数の定義が、使用されるかどうかに関わらず LLM のコンテキストに一括で注入されてしまうのです。

こうなると、LLM が実際の作業を行うためのコンテキストの余地がほとんど残りません。この「コンテキスト肥大化」は、トークンの浪費、レイテンシの増加、そして応答精度の低下を招きます。

MCP のコンテキスト肥大化問題への対策がさまざま議論される中、LLM が動的にコードを生成できるようにするアプローチがますます注目を集めるようになりました。ここで、LLM に CLI を使わせて MCP を完全にバイパスするという主張が登場します。提案の骨子は、LLM がサンドボックス環境の CLI にアクセスし、情報源に接続するためのコードを動的に生成するというものです。LLM のトレーニングコーパスにはコマンドラインインターフェースを効果的に使うコード生成の例が豊富に含まれているため、LLM にサンドボックス環境の CLI へのアクセス権を与えるだけで正しいコードを生成させ肥大化した MCP サーバーをバイパスできる——少なくとも CLI 派はそう主張しています。

MCP サーバーの課題と提案されている CLI ソリューションの概要を押さえたところで、次は CLI を使う際の課題を見ていきましょう。

MCP の代替手段としての CLI 利用における課題

エンタープライズ分野で重要な 4 つの観点から検討していきます。

保守性

サンドボックス環境の CLI を使いたいユーザー一人ひとりが、開発中に CLI をダウンロードして正しく設定しなければならないのは、それだけでハードルになります。これを、LLM やエージェント用途のために各自で CLI バージョンを設定する企業内の数百人・数千人の開発者に拡大して考えると、事態は一気に複雑化し、維持管理が困難になります。誰がサンドボックスや CLI 内のエージェントに対する適切な権限セットを管理するのでしょうか？全員が脆弱性のないバージョンを実行していることを、企業はどう保証するのでしょうか？専任の運用チームがなければ、容易な作業ではありません。

一方、リモート MCP サーバーを利用すれば、全員が同じ URL に接続するだけです。ダウンロードも設定も不要で、ソフトウェアコンポーネントの配布サプライチェーンを管理するような複雑な運用フローも必要ありません。

セキュリティ

冒頭で触れた Perplexity の MCP 撤退ですが、Perplexity の検索エンジンが扱うのは主に公開情報です。エンタープライズ環境はまったく異なります。セキュリティとポリシーベースのアクセス制御は、エンタープライズ環境における大きな懸念事項です。エージェントが CLI 経由で接続しようとするあらゆる情報源について、自然と湧く疑問があります。接続に必要な認証情報はどこに存在するのでしょうか？各ユーザーが管理しなければならない環境変数の中にあるのでしょうか？CLI が API キーを管理し、OAuth 3-Legged スキームをトリガーするのでしょうか？これはすぐに混乱を招きます。

• 同意画面が少々わかりにくいかもしれません。認証の対象は CLI なのか、それともエージェントなのか？

• トークンが返ってきた後、適切に処理されない限り、ユーザーはトークンを正しく保存するための追加操作が必要になる可能性があります。

• 正しく保存されたとしても、認証されたのはユーザー自身であり、ユーザーに代わって動作するエージェントではないことを忘れてはなりません。

• この最後の点は重大です。システムが把握しているのはユーザーの ID だけであり、そのコンテキストにある実際のエージェントの情報は含まれていません。

一方、リモート MCP では、認証フローをトリガーすると、ユーザーを適切に認証してその情報を保存し、必要なバックエンドに伝達する——その責任はすべて MCP サーバーが担います。

ガバナンスと可観測性

CLI を API アクセスの手段として使うユーザーやエージェントは、ガバナンスの観点から大きな問題があります。API ごとのアクセス制御をどのレベルで適用すればよいのでしょうか？ID が CLI 経由でしか渡されない場合、管理者は API インターフェースにどうガバナンスを組み込めばよいのでしょうか？そのようなシナリオでのログ記録やトレースがいかに難しいか、想像してみてください。一方、MCP やツールを使えば、すべてのツール呼び出しがログに記録されトレースされ、それらの情報を一元的に集約してセキュリティチームやガバナンスチームが分析できます。ガバナンスモデルもシンプルで、ポリシーの適用をツール単位で行えます。

使いやすさ

IT やソフトウェア開発のバックグラウンドを持たないエンドユーザーにとって、CLI は敷居が高くなりがちです。現場部門のユーザーは CLI を敬遠しがちで、開発者にとっても CLI の操作・管理体験は改善の余地が大きいのが現状です。

エンタープライズ向けソリューション

では仮に、CLI を使いながらもエンタープライズ環境の問題点をすべて解決するシステムを作ろうとしたら、どうなるでしょうか？

1. カスタムハーネスを使って保守性の問題を解決する

2. 認証情報を安全に保存し、ユーザーを混乱させることなく OAuth 認証フローを管理する

3. ガバナンスを組み込んだシステムを構築し、オブザーバビリティの基盤を整える

4. エンタープライズ向けに使いやすい CLI インターフェースを構築する

おめでとうございます——あなたはいま、大量の特注システムエンジニアリングの負担を抱えながら、MCP を別の形で再発明したのです！

CLI は、初期の探索段階でスピードが最優先の単発実験プロジェクトには有効な選択肢です。しかしプロジェクトが探索から製品化へと移行すると、MCP サーバーの活用はほぼ不可避になります。では、MCP コンテキスト肥大化問題に対するほかの解決策はあるのでしょうか？あります！

現在、コンテキスト肥大化を解消するための複数のアプローチが検討されています。ここではそのうちいくつかを紹介します。

ツール検索ツール

MCP のコンテキスト肥大化を軽減するアプローチの一つが、ツール検索ツールです。このアプローチの基本は、LLM が最初に知っているのはツール検索ツールの MCP のみで、必要なツールが生じた時点でそれを使って段階的に読み込むというものです。操作に必要なツールだけを読み込んで不要なものは破棄するため、初期のコンテキスト肥大化を大幅に削減できます。Anthropic は最近のブログ記事「Claude Developer Platform における高度なツール使用の導入」でこのアプローチを詳しく解説しています。

ユニバーサルツール

もう一つのアプローチは、基盤となるソースが何であれ同じインターフェースを持ち、LLM が必要な情報を動的に探索できるメタツール（ユニバーサルツール）を用意することです。これが CData 製品の採用するアプローチです。

これにより、LLM のコンテキストを肥大化させることなく、文脈に関連する情報を動的に見つけ出せます。実際の動作を詳しく知りたい方は、CData Connect AI をご覧ください。Connect AI の MCP は、CLI ベースアプローチの利点である簡単なセットアップと迅速なオンボーディングを実現しつつ、セキュリティや保守性に関わる課題をすべて回避しています。

エージェントスキルについて

エージェントスキルは、Markdown 形式のテキストファイルで、処理中のタスクに応じて LLM が読み込みます。オプションでスクリプトやコードスニペットへの参照を含めることもできます。LLM によって文脈に応じて読み込まれる、自然言語によるドメイン固有の指示と考えるとわかりやすいでしょう。当初は Anthropic が導入しましたが、現在はコミュニティでの採用が急速に進んでおり、OpenAI や Google など各社もエージェントスキルをサポートしています。スキルの重要なポイントは、コンテキストへの追加が最小限でありながら、動作を柔軟に変更できる点です。MCP の直接的な代替ではありませんが、スキルと MCP を組み合わせることでコンテキスト肥大化問題を解消できます。スキルはコンテキスト内で最小限のリンクを提供し、スキルが読み込まれると LLM は MCP へのナビゲーション方法を把握します。

Connect AI で確信を持って構築していきましょう

本記事では、エージェントへの情報アクセスを提供する際に、CLI ベースのインターフェースと MCP ベースのインターフェースがどのように異なるかを見てきました。CLI はエージェント型エコシステムにおいて確かに役割を持っています。迅速な PoC や、エンタープライズ上の懸念がそれほど重要でない単一開発者主導のユースケースには適した選択肢です。特に、コマンドラインの双方向性が初期探索の高速な反復に役立つ場面では有効です。しかし、開発者以外のユーザーが主体のエンタープライズシナリオが中心となり、安全かつガバナンスの効いたアクセスの追跡が求められる場合は、MCP サーバー、あるいはエージェントスキルと MCP サーバーの組み合わせが最適な選択です。

どちらのルートを選んでも、Connect AI は企業が AI を安心して導入するために必要な安全な接続基盤を提供します。まずは 14 日間の無償トライアルでお試しください。

※本記事は CData US ブログ「MCP vs CLI: What Works for Enterprise AI Agents」の翻訳です。