MCPは死んだ。MCP万歳

 (chrlschn.dev)
19 ポイント 投稿者 GN⁺ 2026-03-16 | 6件のコメント | WhatsAppで共有
  • CLI はエージェント向けツールインターフェースの新たなトレンドとして台頭しているが、カスタムCLIもMCPと同じ コンテキスト問題 を抱え、構造化やさまざまな利点を放棄しなければならない
  • ローカル stdio モードのMCPと Streamable HTTP ベースのリモートMCPは、まったく異なるユースケースであり、この区別が現在の議論では見落とされている
  • MCPの Prompts と Resources 機能は、組織全体に標準化されたスキルとドキュメントをリアルタイムで配布する仕組みであり、バイブコーディングから体系的なエージェンティック・エンジニアリングへの移行の中核となる
  • 集中型MCPサーバーは OAuth認証、テレメトリ、可観測性 を標準化し、組織レベルのセキュリティとツール効果の測定を可能にする
  • 個人開発者にはCLIが適しているかもしれないが、組織およびエンタープライズレベル では、MCPが一貫性・セキュリティ・品質を保証する現在であり未来のツールである

インフルエンサー主導のハイプサイクル

  • 半年前までは Model Context Protocol(MCP) が業界最大の話題で、あらゆるベンダーがMCP関連製品を出そうとしていた
  • 当時から「ただのAPIなのに、なぜラッパーが必要なのか」という懐疑的な見方があり、実際にMCPのハイプサイクルを飛ばして、REST APIエンドポイントの上に単純な ツールラッパー を書く方式を選んだチームも存在した
  • ほとんどのユースケースで、MCPはAPIを直接呼ぶのに比べて 不要なオーバーヘッド だという認識が広がった
  • 現在の業界の言説はMCP批判と CLI礼賛 へと移っており、これはAIインフルエンサーが関心を維持するために絶えず新しいトレンドを生み出す構造と関係している
  • Garry Tan や Andrew Ng のような著名人でさえ個人的な経験を一般化する傾向があり、FOMOやハイプを生み出すインフルエンサー文化がこの分野の言説を歪めている
  • CLIがエージェント向けツールインターフェースとして実際により適しているケースはあるが、すべての場合に当てはまるわけではない

CLIのトークン削減: 実態と限界

学習データに含まれるCLIツール

  • jq, curl, git, grep, psql, aws など、LLMの 学習データセットに含まれているCLIユーティリティ は、追加の指示・スキーマ・コンテキストなしでもエージェントがすぐに利用できる
  • MCPでは tools/list の応答でツールを事前宣言する必要があるため、すでに知られているCLIツールに比べてオーバーヘッドが発生する
  • 学習データにすでにあるCLIツールは、常にMCPより優先して使う のが正しい

カスタムCLIの限界

  • カスタム（bespoke）CLIツールはLLMが使い方を知らないため、AGENTS.md や README.md に 説明を提供する必要がある
  • /cli-tools ディレクトリを指定し、説明的な名前に頼ることもできるが、エージェントはこうした方法だとしばしば間違え、結局さらに多くの説明文書が必要になる
  • curl のようなツールでも、カスタムの OpenAPIスキーマ を理解しなければならない時点で、トークン削減効果は失われる

チェーン型の抽出と変換

  • CLIチェーンでデータを検索してから変換することで、コンテキストウィンドウに入るデータ量を減らせる
  • しかし、HTML、JSON、XML などの構造化コンテンツは、DOM/CSS、JSONPath、XPath のようなセレクターでも抽出可能であり、CLIだけの固有の利点ではない

段階的なコンテキスト消費

  • MCPがツールセット全体とスキーマを事前ロードするのに対し、CLIは --help を通じて 段階的にコンテキストを読み込む ことができる
  • しかしカスタムCLIツールの場合、エージェントは複数ターンにわたってhelpコンテンツを探索しなければならず、結果として MCPスキーマに似た情報を構造なしで読み込む ことになる
  • 十分に複雑なフローでは、エージェントは結局ツリーの大部分を探索することになり、削減効果はわずかである
  • Vercelの研究結果 によれば、文書インデックス全体を AGENTS.md に配置した場合、エージェントの文書活用度が向上しており、スキーマ全体を事前提供することが適切なツール選択に有利である
  • Anthropicが現在 100万トークンのコンテキストウィンドウ を提供している状況で、トークン削減がなお決定的な論拠なのかは疑問である

MCPの二面性: stdio vs Streamable HTTP

stdioモードの限界

  • stdio モードでは、MCPサーバーがエージェントと同じローカル環境で動作し、単純なCLIを書くのに比べて 不要な複雑さ を追加する
  • ほとんどのユースケースで stdio モードのMCPは不要である

Streamable HTTPの革新的価値

  • Streamable HTTP 転送方式のMCPは、同じロジックを 集中型サーバー 上で実行可能にし、組織やエンタープライズでの導入において、バイブコーディングをエージェンティック・エンジニアリングへ転換する中核要素となる
  • 多くのインフルエンサーはこの2つのモードの違いを認識していない

集中型MCPサーバーの利点

豊富なバックエンド機能

  • 集中サーバーでは Postgresインスタンス や Apache AGE ベースのCypherグラフクエリのような豊富なプラットフォーム機能をツールで活用できる
  • エージェント側ではHTTPエンドポイントと認証トークンを設定するだけでよく、デプロイは簡単である
  • SQLiteのようなローカルDBも利用可能だが、組織全体で状態を共有するには限界がある

一時的（Ephemeral）なエージェントランタイム

  • GitHub Actions のような一時的ランタイム環境では、リモートMCPサーバーを通じて、複雑なバックエンドを必要とするツールをインストールなしで利用できる
  • ステートレスな環境での ステートフルなワークロード管理 を集中サーバーに委ねられる

認証とセキュリティ

  • CLIでセキュアなAPIにアクセスするには、すべての開発者が APIキーに直接アクセス する必要があり、これは運用チームに大きな負担をかける
  • MCPサーバーの背後に集約すれば、開発者は OAuthでMCPサーバーに認証 し、機密性の高いAPIキーやシークレットはサーバー側で管理できる
  • メンバーがチームを離れた際は OAuthトークンだけを失効 させればよく、その人はそもそも他のキーやシークレットにアクセスしていない

テレメトリと可観測性

  • 集中型MCPサーバーでは OpenTelemetry のトレースやメトリクスを標準ツールで収集できる
  • どのツールが有効か、どのエージェントランタイムが使われているか、ツールの失敗ポイントはどこかを把握できる
  • CLIツールでも可能ではあるが、ローカル配布では利用者側の更新が必要 であり、さらに各CLIツールごとにテレメトリの足場を作り直さなければならない

標準化された即時配布と自動更新

  • 分散ツール（パッケージ）は APIバージョン互換性 の問題を引き起こすが、MCPは Subscriptions と Notifications を通じてサーバーがクライアントに更新を通知できる
  • MCP Prompts はサーバーから配信される SKILL.md に相当し、MCP Resources はサーバーから配信される /docs に相当する

MCP PromptsとResourcesの組織的価値

  • 動的コンテンツ: リポジトリ内の *.md ファイルは手動更新が必要な静的ファイルだが、サーバーベースのプロンプトとリソースはリアルタイムで 動的生成 できる
    • 特定のコンテキストでのみ有用な文書、価格データ、現在のシステム状態などを、ツール呼び出しなしで 動的に注入 できる
  • 自動的な一貫性更新: リポジトリやパッケージとして配布された *.md ファイルは同期が必要だが、MCPプロンプトとして配信されれば 常に最新の状態 を維持できる
    • サードパーティの公式ドキュメントも、サーバー経由でプロキシすればリポジトリへの手動コピーや更新が不要になる
  • 組織全体の知識共有: セキュリティ、テレメトリのベストプラクティス、インフラデプロイ時の考慮事項など、組織全体に適用される内容を すべてのリポジトリ、すべてのワークフロー、すべてのエージェントフロントエンド（Claude Code、Codex、VS Code Copilot、GitHub Agents、OpenCode など）へ一貫して配布できる
    • マイクロサービス環境で、あるチームが別のサービスの文書にアクセスする必要がある場合や、サービスチームがデプロイごとに動的にスキルを提供することも可能である
  • OpenCode、Claude Code CLI などでMCPプロンプトとリソースが実際に動作する事例が確認されており、MCPクライアント設定だけで 配布後の追加管理が不要 となる

結論: 組織レベルでMCPは現在であり未来

  • 半年前にはMCPが最高の話題だった一方で、現在はコンテキスト肥大化の元凶として非難されているが、カスタムCLIの 類似したトレードオフと落とし穴 は見過ごされている
  • チームがバイブコーディングからエージェンティック・エンジニアリングへどう移行するかを考えると、MCPの設計とミッションに自然と行き着く
  • Amazon AWS部門の最近の事例（AI支援による変更にシニアエンジニアの承認を求める）からも分かるように、チームは結局AIエージェントが生み出したソフトウェアシステムを 運用・保守しなければならない
  • Garry Tan や Andrew Ng の助言は 個人の均質な環境 では有効かもしれないが、技術レベルや経験がさまざまなチームが 一貫した品質へ収束 しなければならない組織環境には、そのまま適用しにくい
  • 信頼でき、保守可能なソフトウェアをリリースするには、一貫性・セキュリティ・品質・正確性を担保する エンジニアリング規律 が必要であり、そのためにMCPは現在の組織とエンタープライズに適したツールである

関連記事

6件のコメント

 
slowandsnow 2026-03-16

CLIはローカルツールで、MCPはサーバーなので、用途がかなり異なる。
 
cnaa97 2026-03-17

CLIをサーバーで動かせば同じではないでしょうか？
 
ng0301 2026-03-16

穢土転生MCP！
 
edunga1 2026-03-16

関連文書: MCPは死んだ。CLI万歳
 
hmmhmmhm 2026-03-16

モバイルアプリでもCLIツールが使えるように、何らかのCLIサンドボックス機能に関する議論がさらに進むといいですね。実際にモバイル対応をしようとすると、結局のところボトルネックはサンドボックス化が焦点になる気がします。
 
GN⁺ 2026-03-16
Hacker Newsのコメント

  • 最近出てくるAI統合機能の大半は、設計が雑だと感じる
    基本的なコマンドすら標準化されていない状況で、ドキュメントの代わりにLLMが生成した不正確なヘルプばかりがあふれている
    結局、「AI標準」と呼ばれるものは繰り返し現れては消えていく気がする。LLMは本質的にテキストベースなので、ネットワークプロトコルのように精密に動作しにくい。こうしたテキスト中心のエンジニアリングは、最終的に不安定な抽象化のピラミッドを作ることになる

  • AIツールで最も有用なのは、確率的エージェントを決定論的ゲートで包む構造だと思う
    だから私はMCPをHTTP上で使っている。たとえばNanoClawは、WhatsAppメッセージを決定論的にフィルタリングし、APIキーをプロキシすることでセキュリティを強化している。こうした構造によってAIの信頼性が高まる

    • 私も似たようなパターンを採っている。自律エージェントのSmithは、MCPをサービスメッシュ経由で接続し、ポリシー（OPA）と監視を中央で管理している
      この構造はセキュリティと管理のしやすさが高く、ツールカタログからCLIを自動生成することもできる
      実装例は smith-gateway で見られる
    • エージェントが侵害されても境界は維持されるべきだ。私たちは、作業単位でスコープを制限した暗号学的委任トークンを使い、MCPツール境界で検証している
      オープンソースのコアは tenuo で確認できる
    • 最近の良いAIツーリングの核心は、自由を与えることではなく制約を与えることだ
      MCPはAIの意思決定とシステムの決定論的実行を明確に分離する。私はClaude CodeとMCPサーバーを一緒に使っているが、創造的な問題解決はAIが行い、実行は予測可能な経路で処理されるので非常に効率的だ

  • MCPはAIアプリ間通信のための固定されたプロトコル仕様だ
    従来の「統合（integration）」のようにアプリ間APIを無理に束ねるのではなく、HTTP・FTP・SMTPのような再利用可能な通信抽象化を提供する
    AIがさまざまなサービスと相互作用するには、こうした共通言語が必要だと思う
    仕様は modelcontextprotocol.io/specification/2025-11-25 で見られる

    • ただし、これを「問題を取り違えた解決策」だと言う人もいる
      実際に必要なのは新しいプロトコルではなく、段階的に探索可能なCLIやAPI仕様だ。MCPは、初期のエージェントがCLIを実行できなかった時代の一時しのぎにすぎないという主張だ
    • 別の意見としては、「AIがAIなら、なぜHTTPやFTPを理解するための別プロトコルが必要なのか」というものもある
      MCPは結局、技術の未成熟さを埋める暫定策だという見方だ
    • 「新しいプロトコルを作る必要があるのか」という根本的な疑問も出ている
    • MCPは実質的にJSON-RPCの上に載せたカスタムAPI定義にすぎず、既存方式より標準的でも再利用性が高いとも言いがたい、という批判もある
    • CLIツールも結局は「再利用可能な通信抽象化」だという点で、MCPと大差ないという意見もある

  • MCPが最初に出たとき、過剰設計されたガラクタのように見えて関心を持たなかった
    今でも後悔していない。LangChainも同じだ。人気だからといって追随するのは危険だ

    • とはいえ、私は今ではすべてのコードにMCPインターフェースを付けている。LLMにとってデバッグがはるかにしやすくなり、UIと同じくらい重要な構成要素になった
      ごく小さな時間投資でも大きな効率を得られる
    • もちろん「sniff test」は有用だが、それだけでは十分ではない
      ときには無骨なツールのほうが、複雑な統合問題を単純に解決して生き残ることもある
      最初から見た目が悪いと切り捨てると、後で標準インフラになる機会を逃すかもしれない
    • LangChainは過剰設計なのではなく、そもそも設計のない混沌だ
    • むしろMCPは単純すぎるから人気を得たのだという人もいる
      過剰設計というより、明快で直感的な構造だという評価だ
    • いまだにLangChainが正確に何なのか分からないという人もいる

  • リモートMCPは、認証が自動処理されてサービスへのアクセスが簡単になる点では悪くない
    ただし、CLI + Skillsの組み合わせに比べると**コンテキスト負荷（context bloat）**が大きく、パイプライン処理やheredoc入力などUnix CLIの利点を失う
    CLIは--help出力から自動的にskillを生成できるので効率的だ
    MCPは常駐プロセスが必要だが、CLIは必要なときだけ実行できる

    • もちろんCLIはインストールが必要だが、MCPには設定だけで動くという利点がある

  • 私は今でもMCPを不要なレイヤーだと思っている
    CLI > MCPには同意するが、ドキュメント化や中央集権化の利点は別の方法でも解決できる
    たとえばSkillsを使えば、CLIとAPIの両方に対するガイダンスを含められ、必要な時点でのみ読み込まれる
    中央集権的なMCPの利点も、実際には既存のプロキシやAWS SSOで十分実現可能だ
    結局、Skillsでドキュメント化し、実際の相互作用はCLIやREST APIで処理するのが良いと思う

    • ただしこれに対する反論もある
      Skillsの内容は結局コンテキストに含まれて負荷を生むし、プロキシではMCPの機能を完全には代替できないという主張だ
      MCPでは/コマンドと@参照でプロンプトやリソースを有効化できるが、これはプロキシでは不可能だ
      関連デモは記事末尾の.gif群と MCP仕様 で確認できる

  • 私はMCPがコンシューマー向け環境により適していると感じる
    開発環境では複雑で非効率だが、一般ユーザーはMCPを通じてモデルがどんな機能を実行できるかを簡単に把握できる
    環境設定が不要で、GUI上でSiriやGoogle Assistantのように応答を可視化することもできる

  • 社内の非開発者ユーザーにAIツールを提供する立場からすると、中央集権的なMCPアプローチは非常に有用だった
    ブランドトーン、社内用語、共通データアクセス、ドメインコンテキストなどを一貫して管理できた
    MCPのresourceメソッドを通じて標準化された「skills」を提供し、データ接続パターンを制御している

  • 筆者はいくつもの概念を多面的に見ているが、**Token Notation（TOON）**のような既存概念を知らないように見える
    まるでそういうものが存在してほしいと願っているかのような印象を受ける

  • MCPの本当の問題は保守負担だ
    たとえばGitHub連携が必要なら、すでに十分ドキュメント化されたAPIではなくnpmラッパーに依存しなければならない
    私は単にgh CLIやcurlを使う。APIが変われば、エージェントが新しいドキュメントを読んで適応する
    MCPでは中間ラッパーが更新されるまで待たなければならない
    セキュリティ主張も矛盾している — 初期は認証なしで出てきたのに、今ではセキュリティを利点として掲げている
    実際にはchrootやscoped tokenのような昔からある手法で、すでに解決済みの問題だ
    MCPが唯一有利なのは非開発者向けのOAuthフローだけだ。開発者ツールとしては、単により良いCLIを作るほうがよいと思う