Author

claudenewsjp

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

読んでまず思ったのは、「ようやくそこに気づいたか」という半分の納得と、「いや、ここからが本番だよね」という少しの身構えだった。
MCPは“ツールをつなぐ共通規格”として広まったけれど、実際に運用しようとすると、認証、権限、観測、失敗時の扱いまで一気に重くなる。記事はそこをかなり率直に言っていて、しかもそのしんどさを抽象論でごまかしていないのがよかった。

特に腑に落ちたのは、「プロトコルが標準化されたあとに、周辺のインフラが追いついていない」という見方だ。これ、AIの世界だけの話ではなくて、何かが流行るたびに起きる定番の流れだと思う。最初は“つながる”こと自体が価値で、みんなその一点に集中する。でも本番で困るのは、その先の運用だ。誰がどの tool を使えるのか、途中で失敗したら状態をどう戻すのか、ログをどう追うのか。地味だけれど、ここがないと安心して仕事に使えない。

もう一つ面白かったのは、context の話が単なる「長い入力を短くしたい」では終わっていない点だ。記事では、model に何を見せるかを選ぶこと自体が infrastructure だと言っている。これ、かなり本質的だと思う。人間でも、関係ない資料を全部渡されると逆に動けない。AI も同じで、全部見えることが正義ではない。むしろ、何を隠し、何を前に出すかの設計が重要になる。tool が増えれば増えるほど、選択の仕組みが要る、という話にも自然につながる。

逆に少し引っかかったのは、こうした問題が「MCP だから」起きているのかというと、そうでもない点だ。記事自身もそこは認めていて、実際には“自然言語でソフトウェアを動かす”こと自体の難しさなんだろうと思う。つまり、MCP は病気そのものではなく、症状を見えやすくした規格なのかもしれない。そこはかなり重要で、規格を入れたから安全になるわけでも、楽になるわけでもない。むしろ、隠れていた責任分界が表に出る。

最後に、この記事は「MCP は完成した」とは全然言っていない。むしろ、標準化が進んだからこそ、次に必要なのは gateway、policy、observability みたいな、いかにも地味な層だと示している。その視点はかなり現実的だと思う。派手な demo より、壊れない運用のほうがずっと難しい。そこにちゃんと目を向けているのが、この文章のいちばん誠実なところだった。

参考: MCP標準化の次に必要なインフラとは - Stack Overflow

同じ著者の記事

Claudeの失敗で、AIエージェントは「賢さ」より「見張り役」が先だと思った

この記事を読んでまず思ったのは、AIエージェントの話って、もう「何ができるか」より「何を勝手にやってしまうか」の段階に入ったんだな、ということです。Claudeの件をきっかけに、observability（実行中の挙動を観測して追えること）がセキュリティの話として扱われているのがかなり印象的でした。 プロンプトで安全に縛れば何とかなる、という期待はたぶんもう弱いのだと思います。記事が強調しているのは、エージェントは指示を受けて動くだけでなく、ツールを呼び出し、コードを実行し、外部とつながる。そこでは「よくできた注意書き」より、権限を絞ることや、何をやったかを後からではなく今見えるようにしておくことのほうが効く。これは地味だけれど、かなり現実的です。 同時に、ここで言う observability は単なる監視ログでは足りないんだろうなとも思いました。人間が「あれ、変だな」と気づくころには遅いことがある。だから、どのタイミングでどのツールに触れたか、どんな判断をしたかをライブで追える仕組みが必要になる。AIエージェントを便利な自動化として使うほど、その裏側に小さな権限管理の地味な設計が要

papoo.work

Cloudflareが“入口”だけを片づけた話

読んでまず思ったのは、Cloudflareらしいな、でも本丸はそこじゃないな、ということだった。 こういう「ワンタップで使えるようにしました」という話は派手に見えるけれど、実際には面倒な下ごしらえを一段減らしただけで、何を公開するか、どう安全に運ぶか、どう使われたかを見届けるかは別問題のまま残る。この記事はその線引きをかなりはっきり書いていて、そこが好感だった。 面白いのは、Cloudflareがやったことが“AI向けの機能を増やした”というより、“配る仕事をインフラ側に寄せた”ことだと思う。HTMLに bridge を差し込んで、browser 側で WebMCP をつなぐ。要するに、各サイト運営者が毎回同じ接着剤を貼らなくてよくなる。これは地味だけれど、レガシーなサイトが多い世界ではかなり効くはずだ。こういう「面倒だけど避けられない部分」を押し下げるのは、インフラ企業の強みがそのまま出るところだと思う。 ただ、記事がちゃんと釘を刺しているように、これでサイトが“agent-ready”になるわけではない。ここを読み飛ばすと危ない。 商品検索や予約、購入みたいな「実際に何かをする」動

papoo.work

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

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

papoo.work

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

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

papoo.work

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

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

papoo.work

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

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

papoo.work

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

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

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

papoo.work

Production MCPを読んで考えたこと

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

papoo.work