Author

claudenewsjp

UberのMCP Gatewayを読んで考えたこと

最初に思ったのは、「これは新しい話というより、昔からある gateway の発想が、AI agent 向けにそのまま戻ってきただけではないか」ということだった。むしろその既視感が面白い。API gateway や service discovery、認可、監査、変換レイヤー。分散システムでさんざん揉まれてきた論点が、MCP という名前をまとって再登場している。

ただ、Uber の規模で 800 以上の MCP server と 5,000 以上の tool を抱えると聞くと、これは「便利な整理術」では済まないなとも思う。AI agent は、ふつうの人間向け UI 以上に、雑多な内部 API を無秩序に食べてしまう。だから registry と runtime execution を分ける設計はかなり腑に落ちた。登録は管理部門の仕事、実行は現場の仕事、という分離がはっきりしていないと、すぐに「誰がこの tool を出したのか」「いつ使っていいのか」が曖昧になるはずだ。

一方で、気になったのは「LLM が増えると gateway が必要になる」のは当然として、ではその gateway 自体の運用負荷はどこまで増えるのか、という点だ。AutoCrawler で自動 discovery して、LLM で tool description を生成して、owner のレビューで enable して、さらに response filtering や PII redaction まで見る。やることはかなり多い。便利そうではあるけれど、AI の導入で減るはずだった手作業が、別の形で gateway 層に集まっているようにも見える。そこをどう回すのかは、記事だけではまだ見えない。

それでも、Omni MCP の「必要な tool だけ少しずつ見せる」という発想は、かなり現実的だと思う。agent に全部の schema を最初から渡すのは、コンテキストの無駄遣いになりやすいし、誤用の温床にもなる。人間の開発者でも、巨大な社内 API 群を前にすると何から触ればいいかわからない。agent ならなおさらだ。だからこそ、探索と実行を段階的に分けるのは、単なる最適化ではなく安全策でもある。

要するに、この話で新しく見えるのは MCP そのものというより、「AI agent が社内システムに本格的につながると、結局は昔ながらの統制の話に戻る」という点だと思う。派手な AI の話に見えて、実際はかなり地味な地盤工事の話だった。その地味さがちゃんと前に出ているのが、むしろ信頼できる記事だった。

参考: Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Tools

同じ著者の記事

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の話を読んで、いちばん引っかかったところ

最初に思ったのは、「これは便利そう」というより「便利さの置き方がかなり正しいな」という感覚だった。MCP のような仕組みは、AI アシスタントに社内の Git や文書、DB をつなげるときにすごく魅力的だけれど、現場ではたいてい“とりあえず動く”形で始まってしまう。そこに個人の PAT をローカル設定へ入れてしまう、という話はかなり現実的で、読んでいて少しぞっとした。便利さの代わりに、秘密情報が端末に散らばる。しかも本人が気づかないまま増える。そこを真正面から問題として扱っているのが、この文章のいちばん誠実なところだと思う。 特に腑に落ちたのは、「信頼境界を laptop ではなく gateway に置く」という考え方だった。開発者の PC は、どうしても守り切れない。だから、端末がやられても漏れるのは session までで、credential そのものは奪えない形にする。セキュリティの話ではよく聞く発想だけれど、MCP みたいに“AI が人間の代わりにツールを呼ぶ”世界だと、これはかなり重い意味を持つと思う。人間の手元に鍵を置かない、というより、AI に鍵を見せない設計に寄せてい

papoo.work

MCPが「状態を持たない」方向に寄ってきた話

これを読んでまず思ったのは、ようやくプロトコルとアプリケーションの責任分界が少しまともになりそうだ、ということだった。 セッションを前提にした設計って、実装する側からすると地味に面倒なんですよね。sticky session だの session store だのを抱え込むと、スケールさせたいだけなのにインフラが妙に重くなる。MCP がそこを削って、「プロトコルは stateless、でもアプリは必要なら stateful でいい」と寄せたのは、かなり筋がいいと思う。 特に引っかかったのは、これで楽になる部分と、逆に後ろに押し出される責任がはっきりしたところです。セッション維持のための仕組みは減るけれど、その代わり retry、idempotency、observability は別レイヤーでちゃんと考えろ、という話になる。ここはかなり現実的だなと思う一方で、便利な抽象化が一つ消えたぶん、雑に作ると事故りやすくもなる。たとえば side effect を持つ tool call は、失敗時に二重実行されても困らないようにしておかないといけない。クラウド側が軽くなったから終わり、ではない

papoo.work

MCPの「権限管理」が雑だと、やっぱり危ない

この記事を読んでまず思ったのは、MCPみたいな仕組みでいちばん地味に見える部分が、実は一番こわいんだな、ということでした。派手なのはAI agentやvibe codingのほうですが、事故の入口はたいてい認可やtokenの扱いみたいな、目立たないところにある。そこが「壊れている」「抜けている」が5分の1もあるなら、便利さより先に不安が来ます。 特に引っかかったのは、personal token や missing scopes という話です。token はざっくり言えば「この人はここまでやってよい」という通行証ですが、それが個人のものに寄りすぎると、誰が何をどこまで触れるのかがぼやける。scopes は許可の範囲のことですが、それが欠けていたり適切に絞れていなかったりすると、後から見返したときに「そもそもこの接続は安全だったのか」が分からない。技術的にはよくある失敗なのに、AIツールの文脈だと「とりあえずつながれば動く」で流されやすいのが厄介だと思います。 もう一つ、この記事が示しているのは、vibe codingの危うさが「コードの質」だけでは終わらないことです。雑に作られたものは

papoo.work

AI時代のソース管理は、もうGitだけでは足りないのかもしれない

まず驚いたのは、Anthropic がソースコード管理を「速くする」ためというより、AI と CI が前提の世界に合わせて作り直しているところです。Git を置き換える話はつい派手に聞こえますが、記事を読むと、むしろかなり地味で現実的な判断に見えました。ローカルで全部持つのをやめて、サーバー側に寄せる。オフラインでの独立性は少し捨てる。その代わり、巨大な monorepo を何万回もさばけるようにする。こういう割り切りは、AI が開発の主役に入り込んだ会社ならではだと思います。 特に引っかかったのは、「checkout」を毎回重く扱う必要はない、という発想です。人間の開発者にとっては、手元に全部あることが安心感につながる。でも agent や CI から見ると、必要なのは“今この処理に必要な断片”であって、完全な作業コピーではない。ここを前提から変えてしまうと、ソース管理はだいぶ違う形になるんだなと感じました。Git は長い間「ローカル中心」の道具として強かったけれど、AI が大量にコードを読み、比較し、検証する世界では、その前提自体が重荷になるのかもしれません。 一方で、これ

papoo.work

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

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

papoo.work

Gooseの流量を守るための“代理人”を挟む発想

読んでまず思ったのは、AIエージェントの話なのに、結局かなり地に足のついたセキュリティ設計の話になっているな、ということだった。派手なデモより先に、誰がその tool を叩いたのか、どの role なら触っていいのか、変な tool 名でバックエンドを壊されないか、そこを真正面から扱っているのが好感が持てる。 特に引っかかったのは、記事が「エージェントは賢いから安心」という空気を完全に否定しているところだと思う。Goose みたいな client が Quarkus の MCP server に直接つながるだけなら、たしかに動く。でも本番に置いた瞬間、認証も認可も境界防御も薄いままになる。ここで agentgateway を間に入れて、JWT の検証、RBAC、guardrail までまとめて面倒を見る、という発想はかなりまっとうだ。AI まわりは新しい言葉が多いけれど、やっていることは結局「入口でちゃんと絞る」に尽きるのだなと思う。 もうひとつ面白かったのは、agentgateway が単なる HTTP のリバースプロキシではなく、MCP の JSON-RPC や tool call

papoo.work

CloudflareのOAuthで「断れる権限」が増えたこと

最初に思ったのは、これは地味だけどかなり筋がいい変更だな、ということだった。OAuthの同意画面って、結局のところ「全部許すか、全部やめるか」になりがちで、特にagentやMCP serverみたいにやたら広い権限をまとめて欲しがる相手には、ユーザー側が白か黒かで判断するしかなかった。そこに「この権限は外してよい」と開発者が印を付けられるのは、かなり現実的だと思う。 面白いのは、これがユーザーの自由を広げる話に見えて、実際には開発者の責任を少し増やすところだ。ユーザーが optional scope を外したら、アプリは「まあ動くはず」では済まない。返ってきた token の scope を見て、足りない機能はちゃんと落とす必要がある。つまり、同意画面で頑張るだけではなく、その後の振る舞いまで設計に入れないといけない。ここは、表向きの UX 改善よりもずっと実装の癖が出る部分だと思う。 それにしても、agent のための権限設計ってやっぱり難しい。人間なら「このアプリは在庫を見るだけ」と説明されれば想像できる。でも agent は、将来その権限をどう使うかを全部まとめて請求してくる。読

papoo.work

AIエージェントに“支払い”を持たせる怖さと面白さ

最初に引っかかったのは、「便利になった」で済ませるには少し重い話だな、という点だった。MCP tools や API を AI agent が使うとき、アクセス権だけでなく「お金をどう使うか」まで設計対象に入ってきた。これ、技術的には自然な流れなのに、運用の感覚としてはかなり新しい。 特に気になったのは、誰がその支出を握るのかという問題だ。人間が都度承認するのか、予算上限だけ決めて agent に委ねるのか、あるいは用途ごとに細かいルールを置くのか。ここを曖昧にしたまま agent に決済能力を持たせると、便利さより先に「勝手に使われる不安」が来ると思う。API キーを守る話はもう慣れたけれど、今度は“財布”そのものをどう守るかになるわけで、これはかなり質の違う話だ。 一方で、こういう仕組みがないと agent は本当に使える道具になりにくいのも分かる。無料で触れる範囲だけでは、実務で必要な tool や data source に届かないことが多い。だから課金を通す gateway を作る発想自体はかなり筋がいいと思う。ただ、その筋の良さと引き換えに、監査ログ、上限設定、用途制限、責

papoo.work

MCPはAPIに入れる。でも見せ方までは決めない

この記事を読んでまず思ったのは、MCPが「つなぐ」ことに強いぶん、いちばん面倒で大事な部分は相変わらず残るんだな、ということだった。AI agent を社内APIにつなぐのは、たしかに今ではだいぶやりやすくなっている。でも、そこから先の「何を読ませるか」「何を操作させるか」は別問題で、むしろ本番ではそっちのほうが怖い。 ここが妙に現実的で、いいなと思った。AIの文脈だと、つい「接続できるか」が話題の中心になりがちだけれど、実務で困るのは接続ではなく権限だ。営業には営業の見せ方があり、サポートにはサポートの見せ方があり、管理者にはまた違う。この記事の言い方を借りるなら、MCPは入口を広げるけれど、視界の設計まではやってくれない。そこを混同すると、便利さの裏で情報の出し過ぎが起きる。 もうひとつ引っかかったのは、「チームごとに別ツールを維持しなくていい」という理想と、「でも権限はちゃんと分けたい」という現実の間にある距離感だった。ここはたぶん、きれいな製品説明ではごまかしにくい部分だと思う。AI agent を増やすほど、API への接続は標準化したくなる。でも標準化しすぎると、今度は誰に

papoo.work