ハクソク

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

MCPは死んだ；MCP万歳

46日前原文(chrlschn.dev)

概要

  • CLIとMCPの業界トレンド比較
  • 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を使ってさまざまなことをするから。ただ、ポイントは新しいプロトコルを作る必要があるのかってことだよね？
└
なんでこれが正しい道だと思うの？見た目の問題は解決してないよね。もし外国のAPIと通信するのが課題なら、明らかな解決策は進化的に発見できるCLIやAPI仕様だよ。普通、開発者が使うツールだし。MCPが必要なのは、初期のエージェント設計が任意のCLIを実行できなかったから。コマンドを実行できるようになったら、MCPは意味がなくなるよ。自動的な解決策が欲しいのは明らかだけど、それは「すべてのAPIの形を捉える標準プロトコルがない」ってことじゃなくて、「bashを実行できないエージェントのためにCLIがすることをシミュレートする良い方法が必要」ってことなんだ。
└
つまり、CLIツールも「再利用可能なコミュニケーションの抽象化」ってことだよね？
└
MCPって要するに「このバイブコードプロトコルを使って、JSON-RPCでカスタムAPIを定義する」ってことだよね。既存のプロトコルを使うのと比べて、特に標準的でも再利用可能でもアプリケーションに依存しないってわけじゃない。
MCPはいいけど、特にリモートMCPは、認証を自動で処理してくれるホスティングサービスにアクセスするための最も低い摩擦の方法だね。ただ、MCPはコンテキストの膨張があって、CLI + スキルと比べるとあまり良くない。CLIを使えば、毎回ツールコール全体を展開しなくても、フィルターやパイプ（通常のUnix bash）ができるし、複雑な入力をエスケープしにくい場合でもheredocが使える。CLIは、—help出力から簡単にスキルを生成したり、エージェント特有の指示を追加したりできる。つまり、エージェントにツールの使い方や存在するツール、レイジーロードの情報を教えるためのすべての指示を与えられるってこと。これで、すべてのツールを最初からコンテキストウィンドウに詰め込むことなく、必要な情報を提供できる（そう、Claudeのツール検索が部分的にこれを解決してるのは知ってる）。CLIはMCPのように常駐プロセスを実行する必要はないけど、必要なら実行できるよ。
└
CLIを_インストール_する必要があるけど、MCPなら設定するだけでいいんだよね！
今見ているAI周りの最高のツールの多くは、確定的なゲートを追加して、確率的なAIエージェントがそれを使っているんだ。だから、私はhttpよりもMCPを使ってる。エージェントが問題解決のために知性や創造性を使うのは嬉しいけど、いくつかの操作に関しては、普通のソフトウェア機能のように確実に動作するゲートが欲しいんだ。NanoClawは、エージェントがWhatsAppメッセージを見る前に確定的なフィルタリングを使うことで自分を売り込んでるし、APIキーをプロキシしてエージェントがそれを見ないようにしてる。これは、AIと作業する際にもっと自信を持てるようにするための似たような確定的なゲートなんだ。
└
これ、めっちゃ共感する。今のところ、最高のAIツールってエージェントを自由にするんじゃなくて、制約をかけることに関するものが多いよね。MCPは、AIが決めることとシステムが確定的に実行することの間にクリーンな境界を提供してくれる。俺はMCPサーバーをClaude Codeと一緒に使ってるけど、一番の利点はまさに君が言った通りで、AIがクリエイティブな問題解決を担当する一方で、実際のアクションは予測可能で監査可能な経路を通ることなんだ。
└
エージェントが侵害された場合でも境界を保つ必要があるよね。キーをプロキシするのは正しい直感だと思う。俺たちもアクションレイヤーで同じアプローチを取ったんだ：タスクにスコープを持った暗号的な令状、委任を意識したもの、実行前にMCPツールの境界で検証されるやつ。オープンソースのコアだよ。 https://github.com/tenuo-ai/tenuo
└
俺も似たようなパターンを辿ってる。俺の自律エージェントSmithは、MCPを接続するサービスメッシュを持ってて、そこにポリシーを定義するための一つの場所（OPAは永遠に）とモニタリングを提供してる。サービスゲートウェイは自分の資格情報を持ってる。このパターンは安全で、管理が簡単で、ツールカタログからCLIをプログラム的に生成できるんだ。モデルを理解したいなら、ここを見てみて。 https://github.com/sibyllinesoft/smith-gateway
どのAI統合も、ちゃんと設計されてない（トークンスロップの場合は設計すらされてない）感じがする。クリエイターたちは、まるで「あなたは絶対正しい、$TOOLはあなたの問題を解決する素晴らしいソリューションだ！」っていうのを吐き出すのに、$LLMOFTHEWEEKと同じくらいの考えを注いでるみたい。基本的なコマンドのヘルプテキストすら、真剣に標準化されてない（-hはホスト名を設定するのか、それともヘルプテキストを表示するのか？それとも-Hなのか？--helpは存在するのか？）。マニュアルページを書くのは、今や失われた技術のように思える。みんな$WEBSITE/docsを指さすけど、そこには予想通りLLMのスロップドキュメントが含まれてる。結局「AIの現代的標準」→「AIの標準」→「標準ですらない」→「過去のもの」っていう同じループを見続けることになる。すべてが根本的に間違ってるから。LLMは文脈的に純粋にテキストで、ネットワークプロトコルは本質的にもっと複雑だから。LLMは/api/v1/pingエンドポイントを過剰にスペックすることになるけど、ICMP pingはビット内でそれを実現できる。テキストベースのエンジニアリングは見えるけど（技術に疎い人でも解釈しやすいという意味で）、常にコアの上に抽象を形成することになる。$LLMモデルのエンコーディングが変わった瞬間に、揺らいだピラミッドが崩れ落ちることになるよ。
メンテナンスの負担が、誰も話さない本当のMCPキラーだよ。エージェントがGitHubを必要とする？そしたら、すでに良いドキュメントがあるAPIをラップしたnpmパッケージに依存することになる。俺はgh cliとcurlを使うだけで、APIが変更されたらエージェントは更新されたドキュメントを読んで適応する。MCPだと、ミドルマンがラッパーを更新するのを待つことになる。tptacekが言った通り、エージェントがbashを実行するようになったら、MCPはオーバーヘッドになる。セキュリティの議論も変だよ、認証なしで出荷されて、今はセキュリティが主な利点だって主張してる。chrootジャイルとスコープ付きトークンが数十年前にこれを解決してる。MCPが勝つのは、ターミナルを開かない非技術的ユーザーのためのOAuthフローだけ。開発ツールに関しては？もっと良いCLIを書けばいいだけだよ。
資格情報プロキシパターン（エージェントはキーを見ず、ゲートウェイがそれを所有する）は、人間が主役でエージェントがその代理として行動する時にはうまく機能する。でも、エージェントが主役になる必要がある時には壁にぶつかる。人間のアカウントからエージェントの名義で送信されたメールは、エージェント自身のアドレスから送信されたメールとは異なる法的および評判上の問題になる。エージェントが間違いを犯したり、行動を取ったり、関係を結んだりした場合、誰の名前がそれに載るの？今のところ、その答えはほぼ常に「人間の名前」になってるから、エージェントは実体として責任を持てないことになる。MCPが解決していない深い問題は、認証がユーザーのために作られたものであって、エージェントのためではないってこと。OAuthはエージェントに委任されたアクセスを与える。でも、委任はアイデンティティじゃない。委任されたGmailアクセスを持つエージェントは、代理として行動している。一方、自分のメールアドレスと電話番号を持つエージェントは、一級の参加者として行動している。ウェブをブラウジングしたりカレンダーを読むようなことには代理モデルが必要だけど、アウトリーチやコミットメント、帰属が重要なものには明確なアイデンティティが必要だ。これらの二つのケースには異なるインフラが必要なんだ。
俺は今でもMCPは完全に不要だと思ってるし、最初からそう思ってた。記事ではCLIがMCPより優れてる点を指摘してるけど、2つのポイントで足りてないんだよね。1つ目は、MCPなしでインターフェースを文書化すること。これは、CLIやAPI（他の統合も含む）の指示を含められるスキルを使うことで一番うまく解決できる。エージェントは必要な詳細だけを読み込むから、特定のケースに合わせてドキュメントをカスタマイズしやすいし、ツールのサブセットを使ったスキルを構築するのも簡単。2つ目は、リモートMCPに帰属する中央集権の利点について。従来の中央集権型プロキシでも同じ利点を得られるよ。MCPは本質的にそれらの利点を与えてくれるわけじゃない。CLI経由でAWS SSOを使えば、すぐに俺のアカウントにすべての権限が紐づくし、中央管理の利点も得られるし、観測可能性の利点もある。俺の考えでは、スキルを使って何をすべきかを文書化し、ターゲットを絞ったプログレッシブディスclosureの利点を享受し、サービスとの実際のやり取りにはCLIやREST APIを使うべきだと思う。
俺は数ヶ月間MCPを使って、デスクトップ自動化のためのアダプターを作ってる（ブラウザ、CLIツール、Officeアプリ）。プロトコル自体はしっかりしてるし、JSON-RPCのトランスポートとツール/リソースの抽象化もうまく機能してる。ただ、使えるアダプターのエコシステムが欠けてるんだ。ほとんどの開発者は、カスタム統合コードを書くことなくAIを既存のツールに接続したいと思ってる。これが今の本当のギャップだと思う。「MCPは死んだ」というフレームは早すぎると思う。むしろ「MCPはより良いツールとアダプターが必要」って感じで、これは解決可能な問題だよ。
最後に、これを数ヶ月言ってきたけど、一般的に大きな反発を受けてる。欠けてるのは中央MCPゲートウェイの役割とコードモードの2つだけ。これらが最適に使われる方法は100%わからないけど、90%のユースケースでは未来はこんな感じになると思う。簡単なケース、例えばcatやls、rg、grepみたいな一般的なコマンドをパイプするためのbashからjsへのコンパイラを誰かが作る必要があるんじゃないかな。そうすれば、すべてのRLやトレーニングデータを使えて、そっちに逸れるオーバーヘッドを節約できる。ローカルツールがほとんど残らなくなったら、エージェントサーバーをopencode serveみたいにスケールアップして、ウェブサーバーのようにエージェントを提供できるようになると思う。