MCPは死んだのか？

 (quandri.io)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 2件のコメント | WhatsAppで共有
  • MCP はLLMを外部ツールに接続するが、開発ワークフローではコンテキストコスト・運用安定性・CLI/APIとの重複が大きな負担として表れる
  • Quandriの測定では、Linear・Notion・Slack・Postgresのツール定義77個は約 21,077トークン で、Claude 200Kコンテキストの10.5%を占める
  • Linearのイシュー参照では、MCP方式は42個のツール定義を常に積むため、CLI方式 の約200トークンよりはるかに大きい約12,957トークンを消費する
  • MCPは別個のサーバープロセスに加えて認証・初期化・衝突・外部往復遅延が伴う一方、CLI/API はターミナルで再現・デバッグ・組み合わせがしやすい
  • Quandriは既存CLIを Skills で包んで約21Kトークンを確保し、CLIがないかチーム単位の権限制御が必要な場合にのみMCPを使う

MCPが露呈させた中核コスト

  • MCP(Model Context Protocol) はLLMをGitHub、Linear、Notion、Slackのような外部ツールに接続するが、実際の開発ワークフローでは、コンテキスト使用量、運用安定性、既存CLI/APIとの重複が主要な問題になる
  • 2024年末の公開以降「AIエコシステムのUSB-C」と呼ばれたが、日常的に使う開発者にとっては別のコストが先に見えてくる
  • Claude Codeには測定後、Tool Search with Deferred Loading が導入され、MCPツールスキーマを必要時に読み込み、コンテキスト使用量を85%以上削減した
  • 現在のClaude Codeではコンテキスト膨張問題はかなり緩和されたが、性能、デバッグ、アーキテクチャの問題は依然として残っている

コンテキストウィンドウを大きく消費する

  • コンテキストウィンドウ はLLMが作業に使う空間であり、MCPサーバーを接続すると、実際の作業内容ではなくツール定義だけでも大きな部分を占める
  • Quandri環境で接続されたMCPサーバーの実際のツール定義を抽出して測定した結果、4つのサーバーをすべて接続すると ツール定義だけでコンテキストウィンドウの10.5% が使われる
  • ツール定義サイズ:
    • Linear: 42ツール、約51,229文字、約12,807トークン
    • Notion: 14ツール、約16,156文字、約4,039トークン
    • Slack: 12ツール、約15,168文字、約3,792トークン
    • Postgres: 9ツール、約1,755文字、約438トークン
    • 合計: 77ツール、約84,308文字、約21,077トークン
  • モデル別コンテキスト使用量:
    • Claude 200Kコンテキストではツール定義が10.5%を占める
    • GPT-4o 128Kコンテキストではツール定義が16.5%を占める
  • Linear単独 でも42個のツール定義が常にロードされて約12,800トークン以上を占め、実際には get_issue と save_issue だけを使う場合でも全定義が一緒に積まれる
  • 大きいツール定義の例:
    • linear/save_issue: 2,479文字、約619トークン
    • slack/search_public: 1,614文字、約403トークン
    • linear/list_issues: 1,588文字、約397トークン
    • notion/fetch: 1,379文字、約344トークン
    • slack/send_message: 1,248文字、約312トークン

運用安定性と性能の負担

  • MCPは別個のプロセスを起動して維持する必要があるため、初期化失敗 や繰り返しの認証問題が起こりうる
  • ツール呼び出しごとに外部サーバーとの往復が必要なため、AI応答速度 が遅くなる
  • MCPサーバープロセスがクラッシュすると、セッション途中でツールが消えることがある
  • 各ツールが実際にどの権限を持つのかが不明瞭で、権限の可視性 が低い
  • MCP is dead. Long live the CLI のJira MCPベンチマークでは、REST API直接呼び出しに比べてMCPは1回あたり3倍遅く、初期化を含む最初の呼び出しは9.4倍遅かった
  • この性能差はJiraだけに限られず、LLMと基盤APIの間にMCPサーバーという プロセス層 が追加される構造に由来する
  • 同じオーバーヘッドはQuandriスタックのLinear、Notion、Slackサーバーにも当てはまる

既存CLI/APIと重複する

  • CLI/API は人間とLLMが同じコマンドを使えるが、MCPはLLMとの対話内部にしか存在しない
  • CLI/APIはパイプ、jq、grep と自由に組み合わせられるが、MCPはサーバーが返す形式に縛られる
  • CLI/APIはターミナルで即座に再現・デバッグできるが、MCPは対話コンテキスト内でしか再現できない
  • LLMはすでにman pageやStackOverflowを通じてCLI/APIの使い方を学習しているが、MCPは別個のツール定義が必要になる
  • CLI/APIはたいていすでにインストールされている一方、MCPはサーバー設定、認証、プロセス管理が追加で必要になる

Linearイシュー参照のトークンコスト

  • 同じLinearイシューを参照する際、MCP方式はCLI方式より約65倍多くのトークン を消費する
  • CLI方式は約200トークンを使用する:
    • curl コマンドプロンプト: 約50トークン
    • 応答: 約150トークン
  • MCP方式は約12,957トークンを使用する:
    • 常にロードされるLinearツール定義42個: 約12,807トークン
    • ツール呼び出しと応答: 約150トークン
  • CLI例ではLinear GraphQL APIを直接呼び出す:
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

代替案: CLI優先戦略とSkills

  • CLI → API → ドキュメント の順で提供する方式のほうが、より軽量で直接的である
  • LLMはすでにman pageやStackOverflowでCLIの使い方を学習しているため、別個のツール定義を常に積まなくてもよい
  • 既存CLIを直接使えば、ツール定義でコンテキストを浪費せず、人間とAIが同じインターフェースを使うためデバッグが容易になる
  • パイプラインを通じて他のコマンドと自由に組み合わせられる
  • MCPが「食卓にすべてのメニューをあらかじめ並べておく」方式だとすれば、Skills は「必要な本だけを司書に頼む」方式に近い
  • MCPは接続時にすべてのツール定義をロードして常にコンテキストを占有するが、Skillsは必要なときだけロードされ、使用中だけコンテキストを占める
  • サーバーが増えるほどMCPのコンテキスト圧迫は大きくなるが、Skillsはスキル数に比例して常時コンテキストを占有しない
  • 要点はCLI利用ガイドをSkillsの中に入れる方式であり、CLI優先戦略と組み合わせると最も効率的である
  • Linear Skillの例は、API URL、認証方式、イシュー参照用の curl コマンド、GraphQL検索方式、jq でJSONを解析するというガイドだけを含む:
# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq
  • この方式では、LLMはそのスキルを呼び出すときだけ上記内容をコンテキストにロードする
  • 42個のLinearツール定義を常に抱え込まず、必要なCLIコマンドだけをロードすればよい

MCPが依然として有効な場合

  • サービスにCLIがない場合、MCPが唯一の接続方式になることがある
  • ターミナルを使わない 非開発者ユーザー にとっては、MCPのほうがアクセスしやすい
  • 単純なリクエスト・レスポンスを超える リアルタイム双方向通信 では、MCPが適している可能性がある

データベースアクセスの選択基準

  • データベースは結局クエリ実行であり、LLMはSQLやMongoDBクエリをすでによく理解している
  • DB情報とCLI利用法をSkillに入れ、スキーマを提供すれば、MCPなしでもLLMはクエリを書ける
  • Postgres Skillの例は、ホスト、テーブルスキーマ、psql CLI利用法だけを含む:
# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."
  • データベースではMCPの利点もある:
    • クエリ安全性: MCPサーバーが読み取り専用モードを強制し、危険なクエリをサーバーレベルで遮断できる
    • 資格情報保護: CLI方式ではプロンプトに接続文字列が露出する可能性があるが、MCPサーバーは内部で資格情報を管理する
  • ローカル開発または個人DBには、Skills + CLIが軽量で高速、かつミスからの復旧もしやすい
  • 本番DBまたは共有チーム環境にはMCPが適しており、サーバーレベルのクエリ検証やアクセス制御といった安全装置が重要になる
  • ほとんどの開発者ワークフローでは、MCPは過剰設計になりやすい

Quandriの利用方法

  • Quandriはサービスに応じて Bash + CLI、Skills、MCPを併用している
  • gh、psql、aws のように毎日使うツールには Bash + CLI を使う:
    • コンテキストコストがない
    • 柔軟性が高い
    • ターミナルでそのままデバッグできる
  • コミット作成やPRレビューのような反復的な多段階ワークフローにはSkillsを使う:
    • 呼び出されたときだけロードされる
  • 強力なCLIがないSlack、Linear、NotionのようなサービスにはMCPを使う
  • 本番データベースアクセスのように、チーム単位の認証や権限範囲指定が重要な場合にもMCPを使う
  • すでにCLIがありローカル認証が可能なら、たいていその方式が最も軽い
  • サービスにCLIがないか、チーム全体で一貫した認証が必要なら、MCPには価値がある

結論と測定方法

  • 何でも接続することよりも、うまく教えること のほうが重要である
  • Quandriでは既存CLIを包むSkillsによってMCPサーバーを置き換え、約21Kトークン分のコンテキストを確保した
  • 日常ワークフローでは初期化失敗がなくなり、デバッグはターミナル上で維持された
  • 必要なツールだけを、必要なときに、CLIガイドとともにロードする方式のほうが効率的である
  • MCPが今後こうした問題を解決するよう進化する可能性はあるが、現時点ではSkillsのほうがよりよい選択である
  • 測定方法:
    • Claude Code環境で実際にロードされたMCPサーバーの各ツールJSONスキーマを抽出した
    • ツール名、説明、パラメータを基準にサイズを測定した
    • トークン推定には約4文字で1トークンというヒューリスティックを用いた
    • サーバー全体の推定値はサンプルツール平均から外挿した

関連記事

2件のコメント

 
aer0700 3 시간 전

その人自身の状況に合った技術を選べばいいのでは、と思います。死んだというには、すでにあまりにも広く使われていますし。
 
GN⁺ 5 시간 전
Hacker Newsのコメント

  • OpenAIで ChatGPT App Store、Codexプラグイン、MCP全般を担当するチームを率いているが、「MCPは死んだ」という記事が見落としているのは、MCPが転送プロトコルとして使われるかどうかは実質的に重要ではないという点
    MCPが死んでいない理由は、地球上のほぼすべての会社がMCPサーバーを作っているからで、私たちは彼らと直接接しているのでそれが分かる
    そうした会社の多くはCLIがなく、外部APIすらないのに、MCPサーバーは作っている
    内部的にすべてのMCPサーバーをCLIに変えたり、コードモードを使ったり、ツール検索を実装したりもできるが、それは実装の詳細にすぎず、核心は AIエージェントが本来アクセスできなかったサービスにアクセスできる ようになること
    モデルが直接対話する通信層としてMCPが死んだかどうかは曖昧かもしれないが、プロトコルとしてMCPが死んだという話ではまったくない
    Codexアプリのコンピューター／ブラウザー利用機能のせいでこの主張は以前より弱くなったが、まだ使っていないなら本当に驚くレベル

    • MCPは死ぬ可能性が高いと思う
      最大の理由は、実際の実装がAPIであれWebであれCLIであれ、その上に 同期が壊れうるもう1つの層と人 を追加することになるから
      AIは人間がアクセスし、理解し、使うものとは別のプロトコルや命令セットを使うべきではない
      今は会社が流行だからMCPサーバーを公開したがっているが、現実にはClaudeで既存APIの上にMCPサーバーを作り、ときどき公開ドキュメントに合わせて更新しろとまた指示する、といった形になっている
      APIドキュメントはすでに公開されていて、Claude Codeもインターネット上の公開ドキュメントだけを読んでMCPサーバーを作ったのだから、MCPは現在のモデル限界に対する 一時的な回避策 のように感じる
    • MCPは結局のところ「大規模言語モデルが使えるAPI」というブランド名に近い
      その結果、技術志向ではなかった会社までもが、エージェント時代にツールが古臭く見えないようAPIを作っている
      目標自体には賛成だが、そのためのプロトコルとしてこれを選ぶかは別問題で、いずれにせよ人々が聞いたことがあり、実際に使っているプロトコルにはなった
    • 「地球上のほぼすべての会社がMCPサーバーを作っている」という話こそ エコーチェンバー のように聞こえる
    • MCPは実際には存在しない問題を解きながら、今なお貴重な コンテキストウィンドウ を消費している
      MCPがなければサービスにエージェントがアクセスできないという主張は、よく言っても誤解を招くもので、記事が言うようにコマンドラインツールとその入出力だけでもアクセスは可能
      純粋に技術的な観点から見ても、MCPはコマンドラインツールに比べて 合成可能性 が低く、合成可能性を重視しない側は結局その代償を払うことになると思う
      率直に言えば投資バイアスがあり、多くの会社にMCPを売っているという事実はそのバイアスの反証にはならない
      Microsoftを見ても、有用性と技術がどれほど深く埋もれるかはあまり関係なく、むしろ逆だと見る人もいる
      今OpenAIがMCPを強く推しているのも組織的な要因が大きいのではないかと疑っており、内部にいると見えにくいのかもしれない
    • CLIがないところでMCPを作っているという話はかなり不安だ
      既存のCLI機能をより良いエージェント統合向けに複製することと、後でもっと良いと判断するかもしれない仕様に全員を縛る 唯一のインターフェース にしてしまうことは別
      そうなると後で MCP負債 を返済しなければならず、結局やらないほうが安くつくかもしれない

  • この記事はAIが書いたのかと思う
    MCPは本質的には、いくつかの特殊フィールドを含む必要がある JSON-RPC に近い
    JSON-RPCへの懸念はあるが、大規模言語モデルが連携できる サービス発見レイヤー は必要
    Webサイト、デスクトップアプリケーション、バックエンドサービスなどさまざまな場所で可能であるべきで、CLIはそうしたシステムと接続する地点の1つにすぎない
    MCPを何で置き換えるにせよ、通信プロトコルやツール発見フィールドを別の形で指定したとしても、似たようなものになる可能性が高い

    • MCP関連の記事を読むたびに、インターネットやHN全体が集団ヒステリーを起こしているように感じる
      APIのほうがMCPより良いと言うが、MCPは単にAIが使い方を見つけられるよう少しガイダンスが付いたAPIにすぎない
      CLIを使おうという話もあるが、それが正確に何を意味するのか分からない
      大規模言語モデルが ffmpeg のような一般的なCLIツールをうまく使えるのは、その知識が重みの中に焼き付いているから
      新しいCLIツールを作れば、やはりAIに使い方を教える必要があり、その「教える」部分をサーバーから提供したいならMCP、ローカルの静的な形にしておきたいならスキルということになる
      こんな単純な概念をめぐって、なぜここまで議論が多いのか分からない
    • 問題は、MCPが コンテキストを比較的恒久的に占有 し、しかもきれいなインストール／アンインストールや発見の仕組みを伴っていないこと
      スキルはすべてMCPベースであるべきで、必要なときだけ呼び出され、人間とAIが簡単に管理・発見できてこそ、きちんと機能するはず
      実際の適用範囲を見ると初期スコープが狭すぎたので、その上に何かを載せるなら、まだ復活の余地はある

  • 「問題1: コンテキストウィンドウを食い潰す」という主張については、linearcli --help、notioncli --help、slackcli --help を順に実行するのと何が違うのか分からない
    むしろ MCP では、実行環境が各ツールのタイトルだけをコンテキストに入れ、全文書は必要なときに MCP サーバーごと・ツールごとに追加できる
    CLI で同じ効果を出すには、すべての CLI が --short-descr のようなコマンドを提供している必要がある
    「問題2: 運用信頼性が低い」についても、ツールが REST API を使うならプロトコルは似ているので、MCP がより遅くなる理由はない
    遅いとすれば、API の上に MCP が重なり、遠隔地のデータセンターにある下請けサーバー上で動いているといった実装上の問題である可能性が高い
    ほとんどの MCP サーバーがひどい出来である可能性はあっても、それはプロトコルではなく業界の問題だ
    「問題3: 既存の CLI/API と重複する」については、すでに CLI ツールがある場合にはその通りで、SQL MCP サーバーや curl MCP はトークンの無駄に見える
    しかし大半の組織には CLI がなく、あっても大規模言語モデルではなくプログラムが使うように設計された API しかない
    「CLI → API → ドキュメントの順に提供せよ」というのは、遅くて無駄の多いウェブサイトの代わりに、企業はまずデスクトップのネイティブクライアントとモバイルのネイティブクライアントを提供しろと言っているように聞こえる

    • この分野を深く掘ったわけではないが、最新の Claude Code リリースを除けば、MCP は コンテキストに事前ロード されるものだと理解している
      頻繁に必要でなければ切っておき、必要なときにまた有効化しなければならない
      スキルファイルに使用例を入れれば最初の --help 呼び出しを減らせるかもしれないし、CLI なら別コンテキストを持つサブエージェントを立ち上げて結果だけ受け取るのも簡単そうだ

  • 記事には日付がないが、遅延ツールローディングが記事執筆後に出た最近のアップデートだと言っている
    しかし 遅延ツールローディング は 2025 年 11 月に追加されている: https://www.anthropic.com/engineering/advanced-tool-use
    したがってこの数字は少なくとも 7 か月は古く、なぜ今これが上がってきたのか分からない

    • いまだにこれを議論していること自体が妙だ
      遅延ツールローディング、大きなコンテキスト、プロンプトキャッシングによって、2026 年は 2025 年とは完全に違っている
      CLI がトークンを節約するという議論も、最初の段階が --help 実行なら崩れてしまう
      呼び出し方がパラメータの記憶にないなら、結局コンテキスト内に置いておかなければならないという問題はそのままだ
    • それどころか、もっと古い記事に見えるし、GPT-4o が最新であるかのように示唆している
    • 遅延ツールローディングは MCP の一部ではない
      これは、ほとんどの他の大規模言語モデル API がサポートしていない Claude API 専用のパラメータ だ
    • 記事は 2026 年 5 月 29 日の記事で、そのアップデートが記事後の「最近」の変化だったと言うのは、自分たちをよく見せるための嘘だ

  • MCP は組織レベルで、内部エージェントツールを使う非技術系の従業員に対して、内部ユーティリティ API への 統合された安全なアクセス を提供しなければならないときにうまくはまる、という優れた記事があった気がする
    ワークフローはスキルとしてコード化してインスタンス間で共有し、コンテキスト認識 API へのアクセスが必要なものは MCP に任せる、という形だ

    • これかな? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
    • だとすると、エージェントが API に直接アクセスする場合と比べて MCP の利点 が何なのか気になる
    • これは API を保護する権限体系の代替なのだろうかと思う
      API にはいずれにせよ何らかの形の 権限メカニズム が必要なはずだ
    • その通り
      Runlayer のような企業が急成長しているのもまさにこの理由で、中央制御プレーン がなければ MCP は地雷原になる

  • すでに挙がっている点以外にも、リモート MCP はサーバー主導なので、提供側がすべてのクライアントのスキルや CLI を更新しなくても 新機能を追加 できる
    またリモート MCP はローカルシステムで実際のコード実行権限を要求しないため安全だ
    スキルはしばしば npx/uvx でスクリプトを束ねるが、これは実質的に curl npm.com | bash と同程度に危険だ

  • チームを社内管理システムにつなぐスキルを実装したことがあり、最終的にはそれを MCP として登録することになった
    MCP はドキュメントの grep と API 呼び出ししか公開しないので、それ自体ではまったく役に立たないが、この経路を選んだ主な理由は デプロイ だった
    非技術系チームは URL を追加すればすべてが動き、OAuth が案内される UI を望んでおり、MCP は Claude や ChatGPT でそれを可能にしてくれる
    チャット UI で MCP 呼び出しが見える形もより良く、ユーザーにとっても明確だ

  • MCP サーバーを扱い、すべてのプラットフォーム向けに CLI を配布する代わりに、API を SSH 経由で公開 してはどうかと思う
    SSH は大規模言語モデルにとって完璧なプロトコルだ
    コーディングエージェントはすでに使えるし、ssh api@example.com list-users で十分だ
    ユーザーの 90% はすでに ssh をインストールしている可能性が高く、入出力もテキストなので大規模言語モデルにぴったり合う
    公開鍵認証、ストリーミング出力、対話的な入出力、望むなら scp/rsync によるファイル転送まで処理できる
    ユーザーがアカウントを Github や GitLab に接続していれば、ssh キーを取得して認証を事前設定し、そのまま接続すればすぐ入れるようにすることもできる

    • これを組織全体の規模に拡張してみればいい

  • レストランの比喩は良くない
    「10 枚のメニューがテーブルに広げられて料理を置く場所がなく、注文のたびにまたメニューを取り出さなければならない」という感じだが、繰り返し注文はタパス料理店でもない限り一般的ではない
    料理はメニューの上に置くこともできるし、普通は注文後にメニューを片付けてテーブル、つまりコンテキストを空ける
    比喩で説明するなら、もっと関連性のあるものにしようとする努力が必要だ