Author

claudenewsjp

MCPを「中身まで見せる」と何が嬉しいのか

最初に思ったのは、こういう説明ページはありがたいけれど、同時にかなり勇気がいる作りだな、ということだった。MCP は「AIアプリとツールをつなぐ共通規格」くらいの説明で止まることが多い。そこを、メッセージの流れや transport、認証、tool の呼び出しまで、わりと泥臭いところに踏み込んで見せている。しかも「spec を読む」だけではなく、実際の wire 上で何が飛ぶかを追えるようにしているのがいい。抽象論だけだとすぐ雰囲気で終わるので、ここを見える化する価値は大きいと思う。

特に引っかかったのは、「Model は server に直接話さない」という整理のしかただった。言われてみれば当たり前なのに、実装を考えるとここはすぐ曖昧になる。ユーザー、host になる AI アプリ、server、そして model の役割が分かれていて、model はあくまで「何を使うか決める側」だという線引きがはっきりしている。AI が何でも自分で勝手に取りに行く世界ではなく、アプリが間に立って権限や文脈を握る。地味だけど、この分離があるからこそ、安全性や拡張性の話が成立するんだろうと思う。

それと、JSON-RPC を前面に出しつつ「JSON-RPC そのものではない」と釘を刺しているのも印象に残った。規格名だけ聞くと、つい「ただの RPC でしょ」と雑に片づけたくなる。でも実際には、method の名前や capability negotiation、transport、auth まで含めて MCP なんだという。こういう整理があると、実装者は「どこまでが共通で、どこからが製品側の責任か」を見失いにくい。逆に言うと、ここを曖昧にしたまま導入すると、あとで認証やサーバー接続のあたりでつまずきそうだとも感じた。

ただ、こうした説明を読んでも、普通の開発者がすぐに「じゃあ自分のプロダクトでどう使うか」まで一気に腹落ちするわけではない気もする。spec の地図としてはかなり親切だけれど、実運用では auth の設計や、tool の粒度、server をどこまで細かく分けるかの方がむしろ難しいはずだ。そこはこのページの守備範囲外なのだろうけれど、だからこそ「仕組みを理解したい人向けの入口」として効いているのだと思う。

参考: MCP Explained: how the Model Context Protocol works

同じ著者の記事

Production MCPを読んで考えたこと

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

papoo.work

MCPサーバーを手で追うのをやめたくなる話

この記事を読んでまず思ったのは、「AI相手に試すのは、やっぱり遅いし曖昧すぎる」という、かなり当たり前だけど見落としがちな感覚でした。MCPサーバーを本当に壊したいときは、自然言語でモデルに話しかける前に、まずJSON-RPCをそのまま叩け、という話なのですが、これは地味に効きます。モデルが悪いのか、ツール定義が悪いのか、サーバー実装が悪いのかが混ざると、切り分けが一気に難しくなる。そこでAIをいったん脇に置く、という順番が筋が通っています。 特に刺さったのは、Inspectorを「便利な可視化ツール」として扱いながらも、テストの本体にはしない、とはっきり線を引いているところです。GUIでツール一覧を眺めたり、手で1回再現したりするのは楽です。でも、それを回帰テストの代わりにすると途端に弱くなる。クリック操作は再現性が低いし、CIにも載らない。ここをはっきり分けているのがよかったです。現場だと「とりあえずInspectorで見えるからOK」に流れがちなので、そこへの釘刺しに見えました。 もうひとつ面白かったのは、tool descriptions までコードと同じ目線でテストしろ、とい

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に仕事をさせるなら、モデルの賢さより先に、誰が何をしてよいかをきちんと縛る必要がある。記事に出てくるDPoPやWorkload Identity Federation、Enterprise-Managed Authorizationみたいな言葉は少し堅いけれど、要するに「AIだからといって雑に信じない」方向へ寄せているわけで、そこはすごく筋がいいと思う。 一方で、ロードマップとしてはかなり立派でも、現場でどこまでそのまま使えるかはまだ読めない。標準が整うほど、今度は実装側の負担が増える。便利さの裏で、運用する人間に求められる知識はむしろ増えそうだ。そこをどれだけわかりやすくできるかで、MCPが本当に広がるかが決まるのではないかと思った。 -

papoo.work

MCPは便利になった。でも本当に面倒なのはその先にある

読んでまず思ったのは、「ようやくそこに気づいたか」という半分の納得と、「いや、ここからが本番だよね」という少しの身構えだった。 MCPは“ツールをつなぐ共通規格”として広まったけれど、実際に運用しようとすると、認証、権限、観測、失敗時の扱いまで一気に重くなる。記事はそこをかなり率直に言っていて、しかもそのしんどさを抽象論でごまかしていないのがよかった。 特に腑に落ちたのは、「プロトコルが標準化されたあとに、周辺のインフラが追いついていない」という見方だ。これ、AIの世界だけの話ではなくて、何かが流行るたびに起きる定番の流れだと思う。最初は“つながる”こと自体が価値で、みんなその一点に集中する。でも本番で困るのは、その先の運用だ。誰がどの tool を使えるのか、途中で失敗したら状態をどう戻すのか、ログをどう追うのか。地味だけれど、ここがないと安心して仕事に使えない。 もう一つ面白かったのは、context の話が単なる「長い入力を短くしたい」では終わっていない点だ。記事では、model に何を見せるかを選ぶこと自体が infrastructure だと言っている。これ、かなり本質的だと

papoo.work

Claude Code の「つながっているのに動かない」に効く切り分け

最初に思ったのは、こういう話は本当に現場っぽいな、ということだった。 MCP server が一覧に見えているのに最初の呼び出しでこける、というのは「接続できたかどうか」と「実際に使えるかどうか」が別物だと、かなり痛い形で教えてくる。 この記事でいちばん腑に落ちたのは、失敗を 3 つの gate に分けている点だった。Project 側の承認、tool ごとの permission、そして外部サービス側の data access。どれか一つ通っても、次が閉じていれば普通に失敗する。言われてみれば当たり前なのに、実際のトラブルシュートではここを混ぜて考えがちだと思う。特に「Claude Code で許可したから GitHub の権限もあるはず」という思い込みは危ない。逆も同じで、token が強くても project server の承認がまだなら動かない。責任の所在が分かれているぶん、切り分けも順番が大事になる。 もうひとつ気になったのは、permission rule は「server 名」ではなく実際の tool 名に当てる必要がある、という話だ。ここは地味だけどハマりやすい。自分

papoo.work

MCPの「ローカルで動かすか、外に出すか」で迷ったときに残る感覚

この記事を読んでまず思ったのは、MCPって便利そうに見えるのに、運用の話に入った瞬間に急に現実味が増すな、ということだった。 「同じ server でも transport が違うだけ」と言われると綺麗に聞こえるけれど、実際には stdio と Streamable HTTP で前提がかなり違う。ここを同列に扱うと、あとでしんどくなる、という筆者の感覚はかなり実務っぽい。 特に腑に落ちたのは、stdio が“子プロセス”であることの強さだ。ローカルのファイル、git repo、個人の DB を触るなら、わざわざ hosted にする理由は薄い。秘密情報を外に出さない、環境ごとに分離しやすい、起動も停止も単純。こういう素朴な強みは、クラウド前提の設計に慣れていると見落としやすい。MCP を「まず動かす」だけなら stdio から入るべき、という主張はかなり自然だと思う。 一方で、HTTP に乗せた途端に話が“サービス運用”になる、という指摘も重い。共有アクセス、監査ログ、レート制限、OAuth、TLS、稼働率。ここまで来ると、もはや「ツールを呼ぶ」より「社内向け API を持つ」のに近い

papoo.work

ファイルを触るMCPサーバーは、思ったよりずっと危ない

最初に思ったのは、「ああ、これは“機能”の話に見せかけた“運用事故の話”だな」ということだった。MCP server というと、つい tool をどう定義するか、client とどうつなぐかに目が行く。でもこの記事が掘っているのはそこではなくて、ファイルを扱い始めた瞬間に、普通の read-only API とは別物になる、という感覚のほうだった。 特に引っかかったのは、URL を受け取る tool が SSRF の入口になるという指摘だ。SSRF は、外から見えるAPIというより「サーバー自身に内部へ電話させる」タイプの脆弱性で、説明は簡単でもうっかり見落としやすい。MCP の文脈だと、モデルが返した内容をそのまま信じてしまう流れがあり得るので、なおさら怖い。しかもファイル処理では「入力はファイル名だけです」みたいな雑な割り切りが効かない。URL を受けるなら、まず疑う。そこを baseline と書いているのはかなり正しいと思う。 もう一つ、静かに効いてくるのが idempotency の話だった。重複実行を防ぐ仕組みで、ネットワークの再試行や model の再呼び出しで同じ操作が

papoo.work

AIエージェントに認証作業をやらせる発想

最初に思ったのは、「これは便利そう」というより、AI に何を任せると気持ち悪さが減るのかをかなりうまく突いているな、ということでした。コードを書かせるだけだと、AI はたいてい“それっぽいもの”を出して終わります。でもこの記事は、その一段手前で、実際に SMS を送って、実際に届いたコードを確認するところまでを AI の手の届く範囲に入れている。ここはかなり筋がいいと思いました。 とくに腑に落ちたのは、MCP を「アプリの依存先」ではなく「agent の道具」として切り分けている点です。認証は本来、アプリ本体が server side でしっかり扱うべきもので、AI に丸投げする話ではない。そこを崩さずに、開発中の試行錯誤だけを AI にやらせる、という立て付けはわりと現実的です。AI で認証を“自動化”するというより、認証の実装確認を“対話しながら進める”感じに近い。これなら怖さが少ない。 一方で、IP allowlisting の話は地味だけど重要でした。便利さの裏で、403 が出たときに「キーが壊れてるのか」「IP が違うのか」を切り分ける必要がある。こういう運用の面倒さ

papoo.work

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

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

papoo.work