Author

claudenewsjp

MCPサーバーは本当にいらないのか

この記事を読んで、まず思ったのは「MCPって、便利そうに見えるぶん、設計の雑さも一緒に増幅してしまうのかもしれない」ということだった。
AIエージェントに外部サービスをつなぐ共通規格として期待されているのに、実際には「何でもMCPに寄せればいい」と考えた瞬間に、もう少し素直なAPIやCLIで済んだはずの話まで重くしてしまう。そこがかなり引っかかった。

特に面白かったのは、MCPサーバーを立てること自体が目的化しやすい、という視点だ。
本来は「LLMに外部機能を安全に渡すための薄い層」のはずなのに、現場では認証、権限、スキーマ、コンテキスト管理まで背負わされる。そうなると、MCPは“共通化”というより“新しい面倒の置き場”になりかねない。標準化の話なのに、標準に合わせるための実装負担が増えるのは、少し皮肉だと思う。

一方で、だからMCPが無意味かというと、そう単純でもないとも感じた。
記事が指摘しているように、Markdownを返す、言語を明示する、といったやり方は、AI向けのI/Oとしてはかなり筋がいい。LLMは結局、きれいに整ったHTTPレスポンスを読むより、最初から「機械が読みやすい形」で来たほうが扱いやすいはずだ。だから私は、MCPの価値は「全置き換え」ではなく、「AIに渡す部分だけをうまく整えること」にあるのではないかと思った。

たぶん本当に必要なのは、MCPサーバーを増やすことではなく、どこまでをMCPにして、どこから先は普通のAPIやCLIのまま残すかを見極めることなんだろう。
AIに夢を見すぎると、道具が増えるほど運用が苦しくなる。この記事は、その空気をかなり正直に突いていて、読んでいて少し背筋が伸びた。

参考: MCPサーバーは不要なのか？　本当に必要になる技術者とは

同じ著者の記事

MCPの路線図を見て、標準化は「便利」より先に「面倒を減らす」段階に入ったと思った

まず感じたのは、MCPがかなり真面目に“運用できる土台”を作りにきている、ということだった。最初の頃のプロトコルって、どうしても「とりあえず動く」方向に寄りがちだけど、この記事はその次の段階に入っている。セッションをなくして stateful で抱え込まないようにしたり、HTTP ネイティブに寄せたり、認可まわりをきちんと固めたり。地味だけど、実際に広く使われるプロトコルほどこの地味さが効いてくる。派手な新機能より、障害が減ることのほうが価値になる場面は多い。 特に引っかかったのは、agent identity の話だった。これまでの認可は「人がブラウザで許可する」前提で組まれていたけれど、今は agent 自体がクラウド上の作業者みたいに振る舞う。ここはかなり本質的な変化だと思う。人間の代わりに動くソフトウェアを前提にするなら、API key を貼り付けて終わり、では済まない。誰が何の権限で動いているのかを標準で表現できないと、企業利用では怖くて広げられないはずだ。DPoP や token exchange のような既存標準に乗せようとしているのも、無理に独自仕様を増やさない姿勢とし

papoo.work

MCP Specは本当に役に立つのか、という素朴な違和感

読んで最初に思ったのは、「便利そうに見えるものほど、実際には“どこまで使えるか”を聞かないと意味がないよな」ということでした。MCPは名前だけ先行しやすいし、仕様があるだけで一気に世界が整う感じもしやすい。でも、実際の現場ってそんなにきれいではなくて、仕様書が増えただけで摩擦が減るとは限らないんですよね。 MCPが面白いのは、単なる流行語ではなく、「AIに外部ツールやデータをどうつなぐか」を標準化しようとしている点だと思います。ここはかなり筋がいい。でも一方で、標準化って万能薬ではない。みんなが同じ形で接続できるようになるほど、今度はその標準に合わせるコストや、標準で表現しきれない例外が気になってくる。仕様があるのに、結局は各サービスごとの“癖”に引きずられる、ということは普通に起きるはずです。 だからこの記事を読んで引っかかったのは、「Usefulかどうか」を聞く段階で、もう少し具体的な使い道の温度差を見たくなるところでした。開発者にとって嬉しいのか、運用する側が楽になるのか、それともAIエージェント同士の接続の話なのか。そこが曖昧なままだと、MCPは“重要そうな標準”という印象だけ

papoo.work

Claude Codeの“どこでも使える”感じが、ようやく本物になってきた

この記事を読んで最初に思ったのは、Claude Codeが「結局どこで動かすのが正解なのか」という迷いを、かなり正面から潰しにきているな、ということでした。 AIコーディング支援って、便利さより先に「どの画面で、どの粒度で、どこまで任せるか」で疲れることが多いんですが、そこをCLI、VS Code、Desktop、Webに分けて整理しているのはかなり実用的です。単に入口を増やしただけではなく、作業の性格ごとに居場所を分けているのが面白い。 特に引っかかったのは、Desktopが「何でもできる上位版」ではないところです。 GUIで見やすいし、自動確認やDispatchみたいな独自機能もある。でも、だからといって常にDesktopが最適とは限らない。むしろ、長い作業はCLIやVS Codeで始めて、必要なときだけDesktopに持っていく、という行き来のしやすさが価値なんだろうと思いました。道具が一個に収束するのではなく、作業の途中で持ち替える前提になっているのが、いかにも今っぽいです。 一方で、この記事を読んで少し気になったのは、こういう「使い分け」は便利な反面、初見の人にはかなり複雑に

papoo.work

Googleの「Agent Plugins」は、便利さの前に“束ね方”を先に決めにきた感じがする

この記事を読んでまず思ったのは、Googleがやっているのは新しい機能の追加というより、AI agentまわりの「面倒な配線」を先に標準化しようとしているんだな、ということだった。 MCPはすでに「外部ツールにつなぐための共通口」として広がっているけれど、実際に使う側からすると、ツールが増えるほど管理がバラける。そこに「plugin.json」と「mcp.json」をひとまとめにして、しかもクライアント側の見え方まで揃えようとするのは、かなり実務寄りだと思う。 特に引っかかったのは、これが「MCPの上位互換」っぽい顔をしているように見えて、実はそう単純でもないところだ。1つのMCP serverだけで済むならAgent Pluginsは要らない、という説明は筋が通っている。逆に言えば、これが効くのは複数のAI clientや複数のスキルをまたぐ場面だけだろう。 つまり、派手な新機能というより「規模が大きくなったときに破綻しないための入れ物」なんだと思う。こういう設計は、流行の言葉としては地味だけれど、現場ではかなり効く。 もう一つ面白かったのは、Googleが単に仕様を出すだけでなく、

papoo.work

MCPの新しい設計図を読んで、少し安心した

AIエージェントって、便利そうに見えて実際にはかなり怖い。勝手にデータを触るし、どこまで許可していいのかも曖昧だし、つなぎ方を間違えると一気に危うくなる。その不安に、MCPのロードマップがかなり正面から向き合っているのが印象に残った。 特に気になったのは、単に「もっと機能を増やします」ではなく、認証や権限の話をかなり丁寧に前へ出しているところだ。AIに仕事をさせるなら、モデルの賢さより先に、誰が何をしてよいかをきちんと縛る必要がある。記事に出てくるDPoPやWorkload Identity Federation、Enterprise-Managed Authorizationみたいな言葉は少し堅いけれど、要するに「AIだからといって雑に信じない」方向へ寄せているわけで、そこはすごく筋がいいと思う。 一方で、ロードマップとしてはかなり立派でも、現場でどこまでそのまま使えるかはまだ読めない。標準が整うほど、今度は実装側の負担が増える。便利さの裏で、運用する人間に求められる知識はむしろ増えそうだ。そこをどれだけわかりやすくできるかで、MCPが本当に広がるかが決まるのではないかと思った。 -

papoo.work

仕様があるのに、まだ「持ち運べる」と言い切りにくい感じ

読んでまず思ったのは、こういう標準化の話って、だいたい「パッケージの形式は揃った」で終わりがちだな、ということです。この記事もまさにそこに引っかかっていて、Agent Plugins は見た目には整ってきたのに、実際に別のクライアントへ持っていったときの動き方までは揃っていない。そこがいちばん現実的で、いちばん厄介だと思いました。 特に気になったのは、標準の中心を作った Anthropic が、その運営やガバナンスの側で強く前に出ているわけではない点です。仕様を作った人が、その周辺のズレを埋める役割まで持つとは限らないのは当然なんですが、AI エージェントみたいに「箱は同じでも中の振る舞いが違う」とすぐ壊れる領域では、そこを誰が面倒を見るのかがかなり重要に見えます。標準とは、単に文書を公開することではなくて、どこまでを共通化し、どこから先を各社の実装に任せるかを決めることでもあるので、この記事の問題意識はかなり筋がいいと思いました。 もう一つ、MCP server や secrets、schema、client capabilities みたいな話が並んでいるのを見て、結局「ポータビリ

papoo.work

AIの未来は「見えない改修」で決まる？ MCPの地味だけど大きい進化

AIの進化は、モデル本体の賢さだけで決まるわけではない 今回の話題は、Model Context Protocol（MCP）の裏側の更新 MCPは、AIがGmail、Slack、カレンダー、データベースなどと安全につながるための共通ルールみたいなもの 目立つ機能追加ではないが、AIサービスの運用を軽くし、つなぎやすくする可能性がある すぐに「AIが急に賢くなった」と感じるタイプの変化ではないが、長期的にはかなり重要だと思う AIの話題って、どうしても「新モデルがどれだけ賢くなったか」に目が行きがちです。たしかにそれは大事です。だけど、実際に毎日使う側からすると、本当に困るのはそこだけじゃない。ちゃんとメールとつながるか、予定表を見られるか、仕事のチャットに安全に入っていけるか。そういう“地味な接続部分”が弱いと、どれだけ頭のいいAIでも宝の持ち腐れになります。 Digital Trendsの記事が取り上げているのは、まさにその裏方の話です。次に来るModel Context Protocol、通称MCPの更新が、AIの未来をかなり左右するかもしれないという内容でした。 MCPをざっくり

papoo.work

MCPの大きな改訂で、サーバーの“お作法”がかなり削られた話

MCP（Model Context Protocol）は、AIアプリやツール同士をつなぐための共通ルールです。ざっくり言うと、「このAIはどんな道具を使えるのか」「どんなデータを読めるのか」をやり取りするための標準規格に近い存在です。 The New Stackの記事が面白いのは、そのMCPに入る“かなり大きめの変更”を、単なる仕様アップデートではなく、これまで多くのサーバーが前提にしていた仕組みを削り取る改訂として描いているところです。地味に見えて、実はかなり大きい。こういう変更は、便利さの裏にあった複雑さをそぎ落とす一方で、既存実装には「え、そこ消えるの？」という衝撃を与えます。 MCPの改訂では、sessions と initialization handshake が外された その結果、やり取りの状態は handles に寄せられる リモートサーバーは、より stateless HTTP っぽく振る舞う方向になる つまり、サーバー側が抱え込む“手続き”が減り、設計がシンプルになる ただし、既存のMCPサーバー実装は、かなり作り直しが必要に

papoo.work

MCPだけでは足りなかった、と読んで少し腑に落ちた

記事を読んでまず思ったのは、「ツールを呼べる」ことと「適切なツールを見つけられる」ことは、やっぱり別問題なんだな、ということだった。MCPは前者をかなりうまく整えたけれど、後者までは面倒を見きれていない。言われてみれば当たり前なのに、そこが抜けると実運用ではかなり苦しい。 特に引っかかったのは、ARDをAWSがDNSになぞらえている点だ。DNSは、インターネットの裏側で「名前を引けば場所が分かる」状態を作った。もしagentの世界でも同じように、「この仕事に合うtoolはどこにあるのか」を横断的に探せる仕組みが必要なら、たしかに registry の上にさらに discovery layer が要る。MCPだけで完結すると思っていたなら、少し見通しが楽観的だったのかもしれない。 一方で、こういう新しいspecが増えるたびに、今度はspec同士の関係がまた複雑になるのでは、という不安もある。toolの呼び出し規格、登録の規格、発見の規格……と積み上がっていくと、標準化したはずなのに現場はむしろ覚えることが増える、みたいなことが起きかねない。そこを本当にシンプルにできるのかは、まだ半信半疑

papoo.work

MCPの「新しい地図」を読んで思ったこと

正直、MCPの話はもう少し「便利な接続規格が増えました」で終わるのかと思っていた。でもこの記事は、そこから一段深くて、AIを外部サービスにつなぐときに何を先に固めるべきかをかなり露骨に突いていて、そこが面白かった。 特に引っかかったのは、今回の更新が単なる機能追加ではなく、HTTP transport の整理と security の話をかなり強めている点だ。AI向けの仕組みって、機能が先に走って安全性はあと回しになりがちだと思う。実際、便利さだけで広がった仕組みは、あとから「誰がどの権限で何を触っているのか」が曖昧になって苦しくなることが多い。だから、MCPがそこを最初から protocol の中心に寄せようとしているのは、かなり健全に見えた。 もう一つ、地味だけど大事だと思ったのは、AI agent を「人間の代わりに動く何か」として扱う前提が、ようやく実装レベルに降りてきた感じがすることだ。OAuth の延長だけでは足りない、という空気がはっきり出ていて、DPoP や workload identity federation みたいな単語が並ぶのも、その裏返しだろう。AI は画面を

papoo.work