#インフラ

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

大規模言語モデルの性能は、モデルの中身だけでは決まらない。実際には、学習したモデルをどう動かすか、つまり推論基盤の出来が応答速度やコスト、安定性を左右する。今回の元記事は、GLMを手がけるチームが、その推論インフラを自分たちで組み上げていった経緯をたどる内容だ。単なる技術自慢ではなく、なぜ外部の完成品に乗るだけでは足りなかったのか、そして自前化がどこまで効くのかを考える材料になる。 元記事が中心に描いているのは、GLMのチームがモデル開発だけでなく、そのモデルをユーザーに返すための推論インフラまで自分たちで作った、という話だ。推論インフラとは、学習済みモデルに入力を与え、応答を生成し、同時に多数のリクエストをさばくための仕組みを指す。ここが弱いと、モデルが賢くても返答は遅くなり、コストもかさむ。 記事では、最初から万能な仕組みがあったわけではなく、まず既存のやり方で運用を始めたことが示される。ただ、モデルが大きくなり、利用が増えるにつれて、一般的な推論環境では限界が見えてきた。GPUの使い方がうまくいかない、レイテンシが読みにくい、ピーク時にスケールさせるのが難しい、といった問題が積み

PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。 Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。 PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード

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