Osamu MATSUMOTO

すごい。壊れた複数の同一車種の外装パーツを１つ１つ分解して３DスキャンしてCAD化、CNC加工でプレス金型をつくってAE86などクラシックな名車のボディパーツを量産してる。こういうことを大規模できる事業者、日本には居なそう。 youtube.com/watch?v=cBBZrj…

@ninjinkun お！そうなんだ。

LayerXブースで僕と握手 #tskaigi #tskaigi2026

言語化されててすばらしい。

@ShotaAsanoSnow1 slackも買収したしあるのかもしれんけど。SFDCが高いよね。外資ITがSFDCから切り替えはじめると局面変わりそう。 電話、メール、ビデオ通話、全部SFAに連携したいよね。ってかもうありそうです。

@osm 結局顧客との会話情報が一番大事だから、SFDCがZOOMを買収してくれれば手っ取り早そう

今日外資IT営業にとって大きな一歩を踏み出す事に成功した。ZOOM録画から商談情報を抜き出し、社内SFDCの必要フィールドをClaudeで全て自動アップデート出来て優勝。この仕組みを欲しい人は日本にめちゃくちゃいるはず。

そう思います！セコイアキャピタルの基調講演で、顧客を包み込む体験の１つとして、AIと顧客との間に入って、アフォーダンスのギャップを埋めるアプリケーションが必要と言ってましたね。 youtu.be/LRo33rnv6rQ?si…

テナント別にサイロ化するとmigrationが問題になりそ。 テナント別にローリングでMigrationする仕組みとか、アプリ側でLazyにmigrationかけるとか、そういうデータのケア部分の作り込みが必要になるんじゃないかな。 zenn.dev/emuni/articles…

なんでこんな複雑にしちゃうんだろ？ ElastiCache Cluster Multi-AZは非同期レプリケーションだから障害時に注文情報のロスの可能性あり。その時はsnowflakeのデータと突合させるの？Redisを操作して、漏れているもの発見して入れ直すとか面倒そう。 普通にDBのMutiAZで同期が無難だし運用楽じゃない？

@uents そのプロジェクト独自の規範だったら書く意味ありますよね。プロダクトには、尖らせ方ってのがありますしね。

LLMに内在してるからほとんど要らねて言われちゃった笑 まあハーネス含めてエージェント側に取り込まれて行くんだろうな

最近claude codeがたまに接続エラーしまくることがある。途中でサーバ側からTCP RSTが飛んでくるんだよね。MTUいじったりしたくないが、家のNW構成との相性が悪い。類似Issueが結構ある。MAP-Eによって実効payloadが小さい可能性を疑いIPv6出るようにしたら安定はしてる。 github.com/anthropics/cla…

そう思っていた時期が俺にもありました...あと何年か経てば、LLMの一部としてセマンティックストレージ（GDMのTitansみたいなやつ）が実用化され、そこにテラバイトのデータを入れてrecall 100%で呼び出せて、かつ今思いついた新単語や製品IDみたいにセマンティクスがないデータも扱える世界がくる...のかも。 しかし現実にはロングコンテキストをフルに使うと重くて遅くて高い上に、Lost-in-the-middleのせいで長さに比例してreasoningの賢さがぐんと低下する。だからSkillsのように、セマンティック索引をエンジニアがこまめにメンテしてコンテキストを最小化するとLLMがぐんと賢く動く。まるでCPUと同じような局所性が重要で、これがコンテキストエンジニアリングが単なるバズワードではない理由。 だから当面はベクトル検索等のセマンティックストレージをLLMの外部に持つ必要がある。では、RAG界隈でベクトル検索がきちんと使えているかというと、全然そんなことはない。そもそもベクトル検索のイノベーションはここ10年くらいかけてじわじわと浸透してきたもので、LLMのイノベーションとはあまり関係がない。今のコンシューマ向けWebサービスのほとんどはベクトル検索と推薦モデルを中心に作られてる。Google等big techの主要サービス、Insta、X、Facebook、Spotify、TikTok、Uber、Amazon、Netflix...これらの今どきのITビジネスの収益を生み出している大黒柱だ。このポストを見ている全員、毎日数10のベクトル検索や推薦モデルを知らずに利用していることに気づいているだろうか？ でもこれらの本物のITとRAG界隈の最大の違いは、多くのRAG事例のような単純な類似検索（cos類似度の距離の近さ）のためにベクトル検索を使っているベンダーはほとんどない点。Xのタイムライン、YouTubeのおすすめ動画、Spotifyのプレイリスト、TikTokでスワイプ後に見せる動画リスト等々...を生成する推薦システム（recsys）を作るためにベクトル検索を使うのが、LLMとは関係なく過去10年のコンシューマ向けサービスで起きている最大のイノベーション。いかにして賢い推薦をするディープラーニングモデル（LLMではない）＝推薦モデルを作れるかという部分で各社はしのぎを削っている。 LLMは推薦の能力は優れているけど、まだコストと遅延が桁違いに大きすぎて、こうした数億人相手の用途には使えない。現時点では世の中のコンシューマービジネスを回しているのはLLMでは全然ないことに気づいて欲しい。そして現在、XやYouTube、Amazon (COSMO) 等の先進的なプロジェクトで、LLM蒸留（LLMに大量の学習データを生成させて小規模なディープラーニングモデルを学習する手法）を使った生成的推薦（generative recommendation）が実用化されはじめている。さらにYouTubeのセマンティックIDやGoogleのDSI等の新しい研究が始まっている。詳しくはこれ参照→ x.com/kazunori_279/s… 一方で、ここ2〜3年の間にネット上で続けられてきたRAG界隈の議論は、こういうレベルに全然達していないまま下火になりつつある。依然としてベクトル検索＝単純なcos類似度による類似検索という前提の議論が主流で、上記のようなアカデミックな推薦モデルやLLM蒸留の話をタイムラインで見かけることは、英語でも日本語でもとても少ない。でも、国内外のコンシューマー大手のデータサイエンティストの人とミーティングしたりすると、やはり彼らは現実的なLLM蒸留を実用化してたり検討している（当然Xにはそういう話はあまり流れない。ビジネスの稼ぎ頭の話だから）。 というわけで、RAG＝ベクトル検索では全くないし、ベクトル検索を使わずとも優れたRAGはいくらでも作れるけど、ここ10年でIR/recsys界隈で起きてきたベクトル検索のイノベーションが背景にあるからこそ、LLMとベクトル検索の組み合わせがとても面白いということを知ってほしい。まずは単純な類似検索をやめてみよう（定期）。

まさに同意見でした。チャレンジャー側にいる。

どのスコープの話なのか経験のない人には伝わらない。部分のことが全部だと伝わっちゃう例をみる。 DDDが必要な業務ソフトウェア、DDDが不要なシステムソフトウェア。データ=~ SoRをもつSaaSと、データを持つがSoRではないSaaS。これらを横断して開発を経験してる人が少ないからなのかなぁ。

私がやってたのはSREとかできる前の世界だが、大型計算機センターの運用チームには当番シフトがくまれてたし、１０年前のSNSの会社でも運用チームがNW・Appそれぞれいて待機当番の手当をもらってたよ。インフラがクラウドになる前だが、当番制度は世の中の普通だったと思う。壊れる頻度が違うからね。

Claude Codeのみで開発されたCコンパイラーCCCのベンチマーク GCCが10秒かかるベンチマークがCCCだと2時間6分もかかる。 harshanu.space/en/tech/ccc-vs…

他にも、人、物、リソース、様々なマッチングのSaaSとかはAIが労働力だとしても、Supply/Demandのデータを突き合わせる場として残るなと思ってる。

mysqlのコミット止まってるデマの時系列 最初はコミット数減少しているという話や開発がオープンではないという批判で、これはMariaDBの元CEOの記事で、この時点では誤情報ではなかったのだが 1/11 optimizedbyotto.com/post/reasons-t… その後devclassというサイトが3ヶ月コミット無しというタイトルで記事化する

10年以上の前の昔話ですが、memcachedといえばmixi大規模障害。私がmixiに入社して1ヶ月後の夏。 qiita.com/bonnu/items/1a…