MCPは Model Context Protocol の略で、LLM（大規模言語モデル）が外部ツールにつながるための仕組みです。
たとえば GitHub、Linear、Notion、Slack みたいなサービスを、AIが操作できるようにするイメージですね。
元記事では、MCPは「AI界のUSB-C」みたいに言われてきたけれど、実際に毎日使う開発者の目線では、ちょっと話が違うと言っています。
ここ、かなり面白いです。理想としては“なんでもつながる万能規格”なんですが、現場では「便利そうだけど、重いし壊れるし、既存のやり方で足りるのでは？」となりがち。こういうギャップ、技術あるあるです。
元記事の一番強い主張はこれです。
MCPは、LLMのコンテキストウィンドウを圧迫する。
ざっくり言うと、AIが一度に覚えておける作業机の広さです。
机の上に資料を置きすぎると、肝心の仕事をするスペースがなくなりますよね。
MCPは、その机の上にツールの説明書（tool definitions）をたくさん並べる感じです。
Quandriが自分たちの環境で測ったところ、4つのMCP serverを接続しただけで、**コンテキストの10.5%**がツール定義で埋まったそうです。
GPT-4o の 128K context なら 16.5% までいきます。
特に Linear は重く、42個の tool definitionsで 約12,807 tokens。
しかも、実際に毎回使うのが get_issue と save_issue だけでも、全部ロードされるのがつらいところです。
率直に言うと、これはかなりもったいないです。
AIに「仕事して」と頼んでいるのに、最初に分厚いマニュアルを全部机に広げるようなもの。そりゃ集中力も削られます。
次の問題は、運用が不安定なことです。
元記事が挙げている問題はこんな感じです。
要するに、AIとAPIのあいだにもう1枚レイヤーを挟む分、壊れやすくなるという話です。
元記事では、Jira MCP のベンチマークで、REST APIを直接叩くより 1回あたり3倍遅い、初回は 9.4倍遅い という報告も紹介されています。
ここは感覚的にも納得しやすいです。
“標準化された便利レイヤー”って、うまくいくと美しいんですが、だいたいどこかで「そのレイヤー、ほんとに必要？」問題が出ます。MCPもその例に見える、というのがこの記事の空気です。
記事の主張でかなり筋がいいと思ったのがここです。
多くのケースで、MCPは既存のCLIやAPIと役割が重なるんです。
比較するとこんな感じです。
CLI/API
pipe、jq、grep などと組み合わせやすいMCP
個人的には、ここがこの記事のいちばん現実的な指摘だと思います。
新しい仕組みが出るたびに「AI対応しました」と言いたくなるのはわかるんですが、本当に欲しいのは“AI専用の箱”ではなく、ちゃんと使える道具なんですよね。
記事では、Linearのissueを1件調べるのにかかるtoken数を比較しています。
つまり、約65倍違うということです。
これはさすがにインパクトがあります。
しかもMCP側では、実際の呼び出しより前に、42個分の tool definitions を常時抱えるコストが乗ります。
「ちょっと調べてほしいだけなのに、分厚いカタログを毎回持ち歩く」みたいな話で、無駄がかなり大きいです。
この記事の本題は、単なるMCP批判ではなく、じゃあどうするのかです。
Quandriが提案するのは大きく2つ。
まず CLI を使い、必要なら API、さらに docs を見る、という順番です。
理由はシンプルで、LLMはCLIの使い方をすでにかなり知っているからです。
メリットはこうです。
これはかなり強いです。
「AIのために新しい世界を作る」のではなく、既にある世界をそのまま使う。この発想は地味だけど強い。私はかなり好きです。
Skills は、ざっくり言えば 必要なときだけ読み込まれる作業メモです。
MCPが「最初に全部のメニューをテーブルに広げる」方式なら、Skills は「必要な本だけ図書館から借りる」方式。
記事では、Skills の利点をこう整理しています。
特に大事なのは、Skillsの中にCLIの使い方を書くことです。
たとえば Linear の skill に、API endpoint、認証方法、curl コマンド、jq での整形方法などをまとめておく。
するとAIは、必要になった瞬間だけその手順を参照できます。
これ、地味にすごく合理的です。
MCPが“全部常駐”なのに対して、Skillsは“必要な分だけオンデマンド”。
この差は、実運用ではかなり効いてくるはずです。
元記事は、そこまで極端ではありません。
MCPがまだ有効な場面もあると認めています。
たとえば：
つまり、「MCPは死んだ」というタイトルはかなり煽り気味で、実際には用途限定で生きている、というのが正確です。
このタイトル、かなり挑発的ですが、内容を読むと完全否定ではなく、むしろ「使い分けようよ」という話なんですよね。
ここも興味深い部分です。
DBは結局、SQLを投げるか、クエリを実行するかの世界です。
元記事では、ローカル開発や個人DBなら Skills + CLI で十分だとしています。
schema を渡しておけば、LLMはSQLを書けるし、psql で実行すればいいからです。
ただし、DBにはMCPの強みもあります。
なので元記事は、DBについてはかなりバランスよく考えています。
ここは「MCPはダメ」ではなく、ガードレールが必要な場面ではMCPの価値があるという、かなり筋の通った整理だと思います。
Quandriでは、3つの方法を使い分けているそうです。
gh, psql, aws など、日常的に使うツールこの考え方はかなり現実的です。
ひとつの技術で全部解決しようとしない。これがいちばん健全なんですよね。
ツールは思想で選ぶと失敗しやすくて、運用コスト・安全性・デバッグしやすさで選ぶのが大事だと思います。
個人的には、この記事は「MCPは終わり」と断言したいというより、**“AI連携の最適解は、必ずしも新しいプロトコルではない”**と釘を刺しているように見えました。
特に印象的だったのは、
という3点です。
これは流行りものへの冷静なツッコミとしてかなり鋭いです。
一方で、MCPにはMCPの価値もあります。
だからこそ「死んだ」と言い切るのは少し大げさで、実態としては**“万能ではない。使いどころを選ぶべき”**が正しいでしょう。
この温度感がいちばん大事だと思います。
この記事の結論をかなり雑に一言でいうと、
「AI連携は、なんでもMCPにすればいいわけじゃない。CLIやSkillsのほうが軽くて強い場面は多い」です。
そして、MCPが向くのは主にこんな場面です。
逆に、日常的な開発ワークフローでは、CLI + Skills のほうが速くて軽くて壊れにくい。
これがQuandriの記事の核心だと感じました。