世界を動かす技術を、日本語で。

MCPは死んだ;MCP万歳

2026年3月15日原文(chrlschn.dev)

概要

  • CLIMCP の業界トレンド比較
  • CLI利用によるトークン節約 の実際と誤解
  • MCPの本質的価値 と企業利用での重要性
  • インフルエンサーの影響 による議論の偏り
  • CLIとMCPの適材適所 の見極めが必要

CLIとMCPの業界トレンドと誤解

  • 現在、 CLI利用 がSNSや業界で流行
  • 数ヶ月前は Model Context Protocol (MCP) が話題
  • CLI利用によるトークン節約 が注目されるも、実際には MCPと同じ文脈問題 が発生
  • MCPのローカル(stdio)とサーバー(HTTP) の違いが議論で混同されがち
  • MCPツールだけでなく、MCPプロンプトやリソース も組織的なエンジニアリング推進に重要

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

  • 半年前は MCP関連製品 が溢れ、各社が導入を競う
  • APIを直接呼び出せる のに、なぜラッパーが必要か疑問視
  • インフルエンサーや有名人 が流行を煽り、FOMOを生む構造
  • 現在は MCP批判とCLI礼賛 が主流
  • CLIが最適な場合もある が、全てに当てはまる訳ではない

CLI vs MCPの本質的議論

  • CLI利用によるトークン節約 は存在するが、過度な期待は禁物
    • モデルの学習データに含まれるCLI(例: jq, curl, git) は追加説明不要
    • カスタムCLI の場合は、詳細な説明やドキュメントが必要
    • OpenAPIスキーマ の理解が必要な場合、結局コンテキスト消費は増加
  • チェーン実行や抽出変換 でのCLI活用は可能だが、CLI特有ではなく標準ライブラリでも実現可能
  • CLIはプログレッシブなコンテキスト消費 が可能
    • ただし、複雑なCLIの場合は結局全体を辿ることになり、節約効果は限定的
    • 全スキーマを最初に提示 した方がエージェントの精度向上
  • CLIとMCPの併用も選択肢
  • コンテキストウィンドウの拡大 (例: Anthropicの1M context)で、議論の焦点が変化

MCPの組織的価値とサーバー型運用

  • MCPの本質的価値 は組織・エンタープライズ用途で発揮
  • ローカルMCP(stdio) はCLIで十分な場合が多い
  • サーバーMCP(HTTPストリーミング) は中央集約型で大きなメリット
    • PostgresやApache AGE連携 など、リッチな基盤機能の提供が容易
    • エージェントがHTTPエンドポイントにアクセス するだけで組織横断利用が可能
    • ローカルDBでは共有や拡張性に限界
  • GitHub等のエージェント環境 でも、MCPサーバーなら複雑なバックエンドを簡易利用可能

まとめと今後の視点

  • CLIとMCPは相互補完的 で、使い分けが重要
  • インフルエンサー主導の議論 に流されず、実用性と組織要件で選択
  • MCPは今後も企業・組織レベルで重要な基盤
  • 現状のハイプサイクル は一過性、半年後には新たなトレンドが登場する可能性

Hackerたちの意見

MCPが出たとき、これは過剰設計のクソだと思って、全然時間をかけなかった。今でもその決断を後悔してないよ。同じことがLangChainにも言える。経験豊富な開発者とそうでない人の大きな違いは、何かがクソに見えたら、たいていクソだってこと。流行ってるからって、無理に何かを真似するのはやめよう。

例えば、企業のドキュメントコーパスに接続されたrag llmチャットAPIがあるとする。MCPエンドポイントを公開しないの?ほとんどのVSCodeやオープンソースのノードは、認証を正しくやれば無料でそれを手に入れるよ(mcp.json設定に小さなJSONスニペットを追加するだけ)。

今作業しているコードはすべてMCPインターフェースを持っていて、LLMがデバッグしやすくなってる。最近ではUIと同じくらい重要だと思う。これでどれだけ時間が節約できたか、信じられないよ。少しだけ時間を投資してみる価値はあるかも。たとえ貧弱なプロトコルでも、役立つ機能を提供できるからね。

LangChainは過剰設計じゃないよ。全然設計されてない、純粋なカオスだ。

何かがクズに見えるなら、それはたぶんクズだよ。 そうだね、技術的にはそうだけど、ここでは「クルフト」のことを言いたかったんじゃない?

LangChainが何なのか、まだよくわからないんだけど。

MCPのどの部分がオーバーエンジニアリングだと思う?これは、私や他の多くの人がMCPを最初に探求したときの意見とは真逆だよ。すごく_明らかに_シンプルだから、最初に注目を集めたんだよね。

じゃあ、代わりにどんなことに時間を投資してるの?

スニフテストは役に立つけど、知恵とは言えないよね。これらのスタックのほとんどは、リポジトリに包まれたチャンバラみたいなもので、早めに見切りをつけるのが正解なことが多い。でも、時々、汚いツールが一つの厄介な統合問題を解決するのがうまくて、クリーンな選択肢よりも残っちゃうことがあるんだよね。失敗のパターンは、味を宗教化すること。初日から粗雑なものに触れなければ、後でつまらないインフラになるような変なものを見逃しちゃうことになるよ。

MCPはAIアプリ間の通信のための固定仕様/プロトコル(HTTP CRUDアプリの上に構築されている)。AIアプリと相互運用したいなら、これが絶対に正しい方法だよ。長い間、ソフトウェアエンジニアたちは、異なるアプリケーションをつなぐ唯一の方法は「統合」(他のアプリの特注APIにアプリを密結合させること)だと考え込まされていたみたいだ。誰かがプロトコルの本来の目的を思い出してくれて本当に嬉しい。再利用可能な通信の抽象化で、アプリケーションに依存しないものなんだ。MCPの目的は、HTTPやFTP、SMTP、IMAPのような共通の通信言語になること。AIはさまざまなことに使われるけど、特定の考慮が必要な特定の種類のものと通信したいと思うから、これは絶対に必要だよ。まだ読んでないなら、仕様を読んでみてね:https://modelcontextprotocol.io/specification/2025-11-25

AIがAIなら、どうしてHTTPやFTPとどうやってやり取りするかを理解するためにプロトコルが必要なの?MCPはその統合をすぐに立ち上げるための方法だけど、根本的な技術が期待されていた能力にまだ達していないからだよ。だからみんなMCPをバンドエイド的な修正だと思ってるんだ。

これは絶対に必要だよ、AIを使ってさまざまなことをするから。ただ、ポイントは新しいプロトコルを作る必要があるのかってことだよね?

Hacker Newsで議論の続きを見る