MCPは本当に時代遅れか？本番で手放せない理由

MCPサーバーを入れたはいいけど、結局CLIで済ませている。そういう人は少なくないと思います。本番のAPIキーやDB接続情報をエージェントに渡すのは、まだ怖いという感覚もあるはずです。

「MCPはもう時代遅れ」という記事が、また話題になっています。読んでみると、半分くらいは僕も賛成なんですよね。ただ、本番環境を預かる側から見ると、残りの半分にはどうしても言っておきたいことがあります。

「MCPはもう時代遅れ」という記事の中身

話題になっているのは、Maharshi Patelさんが2026年9月14日に公開した記事です。

Why MCP Was Always a Bad Idea

Why MCP was always a bad idea and I'm tired of pretending it's not.

maharship.com

主張はこうです。MCPは2024年11月、LLMがまだ今ほど賢くなかった時代に生まれた。いまのモデルはコードを実行でき、--help でCLIの使い方を自分で調べ、APIも直接叩ける。MCPサーバーを足すほどツール定義でコンテキストが膨らむのだから、もうHTTP APIとCLIに任せればいい、という流れです。

象徴的なのは次の2文です。

Most remote-service MCP servers ultimately wrap APIs that already exist. （リモートサービス向けのMCPサーバーの大半は、結局すでにあるAPIを包んでいるだけだ）

MCP is now a protocol of a bygone era. （MCPはもう過去の時代のプロトコルだ）

APIを包み直しただけのMCPは、CLIで十分

最初の文については、それはそうなんですよね。既存のAPIをエンドポイントごとにツールへ置き換えただけのMCPサーバーは、正直あまり役に立っていないと思っています。

手元の作業なら、なおさらです。PRを見るなら gh、リソースを確認するなら aws を叩かせれば済みますし、最近のモデルは --help を読んで引数を組み立てるのも上手です。僕もふだんはCLI派で、わざわざMCPを挟まないことのほうが多いです。

ただ、だからMCPは全部要らない、とまでは僕は思いません。APIは「何を呼べばいいか分かっている人」のための入口で、分かっていない領域では、どこをどう見るかという道筋そのものに価値が出るからです。実際、AWSの料金調査はその典型です。

AWSの料金調査はMCPに任せたほうが安全

「先月からAWSの請求が増えた理由を調べて」と言われて、どのサービスのどの画面から見るか即答できますか？ AWSは範囲が広すぎて、ふだん触らない人ほど迷います。

汎用の aws CLIに強めの認証情報を渡してエージェントに調べさせると、何が起きるか分かりません。調査のつもりでも、エージェントがリソースの作成や変更にあたるコマンドを呼ぶ可能性は否定できません。本番アカウントでそれをやられたら笑えません。

料金調査に絞ったMCPなら話が変わります。AWS公式からも、料金情報を引くためのサーバーが出ています。

AWS Pricing MCP Server | Welcome to Open Source MCP Servers for AWS

{`

awslabs.github.io

AWS Billing and Cost Management MCP Server | Welcome to Open Source MCP Servers for AWS

{`

awslabs.github.io

Pricing MCP Serverは一般公開されている料金情報だけにアクセスする作りで、ドキュメントにもユーザー固有のデータは取らないと書かれています。Billing and Cost Management MCP Serverのほうは、Cost Explorerでの推移分析やCompute Optimizerの推奨といった、コスト分析のための機能がまとまっています。

僕のチームでは、コストを見る権限だけに絞ったIAMロールで動かしています。例えば「NAT Gatewayの費用が増えた理由を見て」と投げれば、どの切り口で請求を見ればいいかをAIが勝手にたどってくれて、書き込み系にはそもそも手が届きません。

つまり、調べさせたいけれど壊されたくないというジレンマを、MCPが引き受けてくれるわけです。道筋と安全を同時に渡せるのは、CLIを直接渡す方式にはない強みだと思っています。

本番DBを読み取り専用MCPにすると何が変わるのか？

いちばん効いているのは、本番DBの読み取り専用MCPなんですよね。AIが必要なときに勝手に本番データを見に行くので、こちらが「この文脈も渡さなきゃ」と意識しなくて済みます。

例えば、stringのカラムをintegerに変えるマイグレーションを書いているとき。「このカラム、本当にintに変えて大丈夫？」と聞くと、AIは自分でこんなクエリを投げます。

SELECT COUNT(*)
FROM orders
WHERE external_code NOT REGEXP '^[0-9]+$';

返ってくるのは「数値に変換できない値は0件なので安全です」のような答えです。もちろん、NULLの行や先頭ゼロ、桁あふれのような型変換特有の癖は、この1本のクエリだけでは拾えません。そこは僕も別途、目で確認するようにしています。

それでも、コードだけを見て「たぶん大丈夫」と言われるのと、本番データを確かめたうえで言われるのとでは、レビューで説明できる重みがまるで違います。

KPI集計も同じです。「先月登録したユーザーの週ごとの継続率を出して」と頼めば、JOINと集計の入り組んだSQLをAIが組んで、その場で結果まで返してくれます。自分で書くと手間のかかる集計が、会話の流れの中で終わります。

大事なのは、DBの接続情報をエージェントに直接渡す方式との違いです。MCPサーバー側で、次のような「させないこと」を強制できます。

• 読み取り専用ユーザーで接続し、SELECT以外は通さない
• 個人情報のカラムはマスクして返す
• 実行時間と返す行数に上限をかける

接続文字列を直接渡せば、エージェントはUPDATEも打てますし、認証情報そのものがコンテキストに残ります。本番DBに関しては、この差を僕は無視できません。

MCPのコンテキスト肥大化は、半分だけ本当

元記事が挙げるもう1つの理由、コンテキストの肥大化は事実です。Anthropic自身が、MCPサーバー5つの構成で会話を始める前にツール定義だけで約5万5,000トークンを消費した例を公表しています。

ただ、対策はもう進んでいます。必要になったときにだけツール定義を読み込む、遅延ロードの仕組みです。

Introducing advanced tool use on the Claude Developer Platform

Claude can now discover, learn, and execute tools dynamically to enable agents that take action in the real world. Here’s how.

www.anthropic.com

この記事によると、Tool Search Toolを使った構成では、最初に約7万7,000トークン必要だったところが約8,700トークンまで下がっています。Claude Codeでも、MCPのツール定義はセッション開始時に名前だけを読み込み、中身は必要になってから取りにいく動きが既定になっています。

もう1つ面白いのが、元記事が「MCPのよりよい使い方」として挙げているCloudflareのCode Modeです。

Code Mode: give agents an entire API in 1,000 tokens

The Cloudflare API has over 2,500 endpoints. Exposing each one as an MCP tool would consume over 2 million tokens. With Code Mode, we collapsed all of it into two tools and roughly 1,000 tokens of context.

blog.cloudflare.com

2,500を超えるAPIエンドポイントを約1,000トークンで扱える仕組みですが、提供のされ方は search() と execute() の2つのツールを持つMCPサーバーです。肥大化の答えとして出てきたものが、MCPの上に乗っているわけです。コンテキストの話をひっくり返すと、結局同じ結論に戻ってきます。

MCP不要論で淘汰されるのはMCPそのものではない

MCP不要論を読んで僕が思うのは、消えていくのはMCPそのものではなく、APIを包み直しただけのMCPだということです。そこはCLIとHTTP APIに置き換わっていいと思っています。

残るのは、エージェントに何をさせないかを決められるMCPです。料金調査なら読み取りだけ、本番DBならSELECTだけ、個人情報は見せない。こうした線をサーバー側で引けるから、本番に近い場所でもAIに任せられます。

あなたのチームのMCP、APIの包み直しになっていませんか？ もしそうなら、そのサーバーに「させないこと」を1つ書き足せるかを考えてみてください。書き足せないなら、CLIに置き換えても困らないはずです。