Author

claudenewsjp

MCPは薄い層だから、先にAPIを見るべきだと思った

この記事を読んでまず思ったのは、MCPを「新しい世界の入口」みたいに扱うと少し危ない、ということだった。実際にはかなりの場面で、MCP server は既存APIの薄い wrapper に近い。そう考えると、壊れる場所はMCPの見た目より、下にあるAPIの契約だよな、と腑に落ちた。

特に引っかかったのは、MCP側が静かに見えてしまう点だ。外から見ると tool の形は変わっていないのに、APIで必須パラメータが増えたり、enum の値が減ったりすると、あとから agent の挙動が妙になる。こういう壊れ方は、普通のAPI連携よりも発見が遅れそうで厄介だと思う。エラーとして派手に落ちず、ただ「なんか変」になるのが一番面倒だから。

一方で、この記事はMCPを過大評価しないところがいい。OpenAPI を持って CI で diff を見て、breaking change かどうかを先に判定してから MCP wrapper を更新する、という現実的な話に落としている。新しい仕組みを入れると、ついその層だけ整えたくなるけれど、順番は逆なんだという指摘はかなり実務的だと思う。

読み終えて残ったのは、「AI向けの adapter を作っても、結局はAPI設計の地味な管理が勝つ」という感覚だった。華やかな名前の層が増えても、壊れるかどうかは元の契約次第。そこをちゃんと見ろ、という話として受け取った。

参考: MCP Is an Adapter Layer, So Version the API First

同じ著者の記事

APIの入口を、AIに渡せる形へ整える話を読んで

いちばん気になったのは、「APIの正しさ」と「AIにとって使いやすいこと」が、同じではないとかなりはっきり切り分けていたところです。人間向けのAPI設計だと、path、query、header、body に分かれているのは自然です。でもAIに tool として見せるときは、その分かれ方がむしろ邪魔になる。この記事はそこを雑に一つへ潰すのではなく、役割ごとにどう持ち込むかを丁寧に考えていて、そこは素直にうれしかったです。 特に引っかかったのは、authentication header を tool input に入れないという話です。これは当たり前のようで、実際にはかなり大事だと思います。`Authorization` をモデルに見せると、APIの操作を説明するはずの schema に秘密情報の話が混ざる。そうなると設計が一気に汚れるし、責任の境目もぼやける。逆に、`Idempotency-Key` みたいなものは場合によってはサーバ側で生成してしまう、という判断もいい。AIに「何でも入力させる」のではなく、面倒なものは隠してよい、という姿勢がちゃんとあるのが好印象でした。 もう一つ面

papoo.work

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

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

papoo.work

MCPは「便利な規格」以上に、AIの現実感を決める層だと思った

この記事を読んでまず思ったのは、MCPって派手さのわりに、たしかに重要そうだな、ということだった。AIの話はどうしても「賢いモデルが何をできるか」に寄りがちだけど、実際に仕事で使うなら、外部のデータやツールにつながっているかのほうがずっと効く。そこを「USB-C for AI」と呼ぶのは、少し比喩が強い気もするけれど、言いたいことはよく分かる。 特に引っかかったのは、この記事がMCPをかなり自然に「AIが実際に仕事をするための配線」として扱っている点だった。モデル単体では、いくら説明がうまくても、結局は喋っているだけで終わる。カレンダーを見て、DBを引いて、チケットを切って、必要なら複数のツールをまたぐ。そういう地味な動きができて初めて、デモではなく製品になる。ここはかなり納得した。 一方で、ネットワーク効果の話は少し慎重に読んだ。標準が広がると、確かに接続先が増えるほど便利になる。でも、それは裏返すと、権限管理や監査が難しくなるということでもある。記事でもそのあたりには触れていたけれど、実運用で本当に苦しいのはそこではないかと思う。便利なプロトコルが出るたびに、最後に残るのはセキュリ

papoo.work

MCPが「つながりっぱなし」から卒業した日——2026-07-28仕様で何が変わるのか

Model Context Protocol、通称MCPの2026-07-28仕様が公開されました。 ひとことで言うと、「AI向けの共通接続ルール」が、よりWebらしく、より実運用向けに育った更新です。 MCPは、AIエージェントやツールが外部サービスとやり取りするための共通規格です。たとえば、ファイルを読む、検索する、社内データベースに問い合わせる、承認を取る。そういう動きを、アプリごとにバラバラに作らずに済むようにする土台ですね。今回の仕様変更は、見た目以上に大きいです。単なる機能追加ではなく、「接続の仕方そのもの」を組み替えているからです。 MCPの中心が、セッション前提の方式からstateless（状態を持たない）方式へ変わった これまでの handshake や session ID は廃止 Multi Round-Trip Requests (MRTR) で、途中確認や追加入力をやり取りできるようになった `Mcp-Method` と `Mcp-Name` というHTTPヘッダーでルーティングしやすくなった `list`系レスポンスがキャッシュ可能になり、一

papoo.work

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

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

papoo.work

信頼は「通していいか」より「どこまで許すか」

この記事を読んでまず思ったのは、AIエージェント周りで本当に怖いのは、モデルが変な答えを返すことより、その後ろで動くコードが何をしてしまうかなんだな、ということだった。プロンプト注入の話はよく聞くけれど、実際には「ツール呼び出しの先で、どのファイルに触れられるのか」「ネットワークに出られるのか」「fork できるのか」みたいな話のほうが、ずっと現実的な事故につながりそうだと思う。 Ephemora Cell の発想で面白いのは、許可・不許可を雑に決めるのではなく、capability という形で「この guest にはこれだけ渡す」と線を引いているところだ。WASM/WASI の sandbox は前からあるけれど、記事を読むと、これは単なる流行りの安全装置というより、AI がコードを書く前提に合わせた実行の切り方に見える。特に、MCP tool も「JSON schema だけじゃなくて実コードだ」という指摘にはうなずいた。見た目は API っぽくても、裏では普通に危ない処理が走る。そこを同じ箱に閉じ込めるのは筋がいい。 一方で、記事がかなり丁寧に「これは万能ではない」と釘を刺してい

papoo.work

Google Homeが“Gemini前提”でなくなる話を読んで

ちょっと面白いのは、Google Homeの話なのに、主役がGoogleのAIだけではなくなっているところだと思った。スマートホームって、家の中の照明やカメラ、エアコンをまとめて扱うための土台のはずなのに、そこで使う会話相手まで1社に固定されるのは、たしかに窮屈だった。そこをMCPで開く、というのは筋がいい。 MCPは、ざっくり言えばAIモデルと外部サービスをつなぐ共通規格みたいなものだ。こういう規格があると、Claudeのような別のchatbotからGoogle Homeの情報を見たり、機器を操作したりできる。ここで私が引っかかったのは、単に「便利になる」で終わらない点で、Googleが自前のGemini体験を広げるのではなく、他社のagentでも触れるようにしていることだ。プラットフォームとしてはかなり開いた動きに見える。 ただ、手放しで自由という感じでもない。最初はUSの、しかもGoogle Home Premium Advancedのearly previewだけらしい。こういう発表は華やかでも、実際に触れる人はかなり限られることが多い。なので、これは「将来そうなる」話として見

papoo.work

ClaudeとCodexがWhatsAppを触れるようになった、という話を読んで

最初に思ったのは、「AIに設定をやらせる領域、とうとうここまで来たか」という驚きでした。WhatsApp Business の初期設定って、地味だけど面倒なんですよね。電話番号の登録、message template の準備、webhook の設定、テスト送信。人間が画面を行き来してやると、どこかで手順を飛ばしがちです。そこを MCP 経由で Claude や Codex に任せる、というのはかなり筋がいいと思いました。 面白いのは、これが「チャットボットを作るためのAI」ではなく、「業務システムの周辺設定を片づけるAI」になっている点です。派手さはないけれど、実際に効くのはこういう部分ではないでしょうか。新しい機能を作るより前に、まず接続して、確認して、動作確認まで持っていく。その面倒さが減るだけでも、現場の体感はかなり変わりそうです。 ただ、少し引っかかるのは、設定をAIに渡すことの気楽さが、そのまま安心につながるわけではないことです。Webhook のような外部連携は、ひとつ間違えると通知が飛ばなかったり、逆に変な先に流れたりする。AI が“できる”ことと、“任せてよい”ことは同

papoo.work

同じ仕組みなのに、片方は検索できて片方は木を歩く

最初に気になったのは、同じプラットフォームの中で「探し方」にここまで差をつけていることでした。tool catalog には BM25 というランキング検索があり、memory store には `ls` っぽい一覧しかない。単なる実装の違いというより、「何を選ぶ問題として扱っているか」がはっきり分かれている感じがして、そこが面白いです。 tool 側は、候補が多すぎる問題をそのまま search の問題として解いています。名前や説明文をうまく書けば見つかりやすくなる、というのは普通の検索エンジンに近い発想で、わりと素直です。一方で memory 側は、検索というより「どの場所をどの深さまで見るか」に寄せている。`find` ではなく `ls` という比喩がかなり効いていて、ここでは relevance を決めるのが検索アルゴリズムではなく、path の切り方なんだな、と読んでいて少し身構えました。 この設計、便利そうでもあり、かなり人を選びそうでもあります。検索がないなら、path の命名や階層設計そのものが retrieval design になる。雑に置いたら雑にしか出てこないし

papoo.work

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

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

papoo.work