Osamu MATSUMOTO

最近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…

１月頭からCES出展でラスベガス行ってきました。

@miura1729 機械語になった段階で情報が大量に落ちている感じがします。 例えば複素数で色々計算しているルーチンが機械語になるとバラバラの浮動小数点数を計算しているように見える。それが「複素数」であるかどうかはそこにまつわる全ての計算を追っかけて複素数の計算規則に沿っているか見ないとわからない。

GoogleがText-to-SQLの内部技術を公開。「曖昧な質問の明確化」「関連テーブルの自動抽出」「複数SQL生成して最適を選択」の3手法で精度向上。BigQuery/CloudSQLで既に実装済。自然言語→SQL変換の品質を上げる具体的アプローチが参考になる。 cloud.google.com/blog/ja/produc…

はじめてstarlinkのwifiついている飛行機乗ったんだけど、8.8.8.8のpingが30ms程度。ストレスない。すごいなー。 新幹線もstarlinkになったりしないのかな。でも飛行機のほうが低軌道に近くて有利なのかもなｗ

1972年、田中角栄氏が『日本列島改造論』を発表しました。 人口と産業を地方に分散させ、日本全体を成長させていこうという構想です。当時の日本は人口が増え続け、「これから先も日本は伸びていく」という前提のもとで、水道や道路などの社会インフラが全国で一気に整備されました。 それから約50年。 いま、その延長線上にあった2つの課題がはっきりと見えてきています。 ひとつは、社会インフラの老朽化。多くが耐用年数50年を超え、これから更新のピークを迎えます。 もうひとつは、地方の中小建設業における担い手不足。私の祖父も1970年前後に北九州で建設会社を起業しましたが、当時は需要が大きく、同じように会社を立ち上げた人が多い時代でした。 その二代目世代がいま70歳前後。一方で、2000年代の不況期に若手が十分に入らず、生産年齢人口の減少と重なって、人手不足や技術承継の問題が一気に表面化しています。 高度成長期に整備された社会インフラの更新と、ベテラン人材の退職が同時に起きる構造は、今後、日本だけでなく多くの先進国が必ず直面する未来だと思います。 この課題に向き合うため、私たちは「熟練者の判断基準や勘所」そのものをAIに継承し、いつでも・どこでも・誰でも再現できる形にする現場向けのAI（現場監督エージェント）を開発しています。 ありがたいことに、この取り組みが評価され、年明けにラスベガスで開催される 世界最大級のテクノロジー展｢CES ｣でイノベーションアワードを受賞しました。 今回の受賞は、現場の暗黙知に踏み込むという挑戦に対して、 世界から背中を押してもらえた出来事だと受け止めています。 人口減少の先頭を走る日本だからこそ、日本の建設現場で培われてきた経験と知恵をAIで次世代につなぎ、「現場の未来」を世界に先駆けて示していきたいと思います。 prtimes.jp/main/html/rd/p…

日記を書いたよ。 takagi-hiromitsu.jp/diary/20251216… 知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる - 高木浩光＠自宅の日記（2025年12月16日） 「関係者の皆さんには読んでほしい。方向付けさえすれば自然にここまで言われてしまうという事態の深刻さを受け止めてほしい。」

react2shellの考察、言及全然なかったけどこの記事がめっちゃ良いです、正しいことしか書いてない dev.to/cheetah100/les…

GitHub のシニアエンジニアが語っているポッドキャストからメモ。動画と順番は前後している。 ・スタートアップが「クラウドネイティブ」や「Kubernetesを触りたい」という理由だけで移行すると、コスト増と開発速度低下で死にかけることがある ・人は「かっこいいアーキテクチャ」や「モダン技術のステータス」を追いがちであり、「本当にその問題に必要か」という観点が抜け落ちやすい ・どの規模でどの設計に進化させるべきかという明確な境界値は存在せず、「1000リクエスト/秒だからもう分散システムだ」とは必ずしも言えない ・GitHubのような巨大サービスですら、数百万リクエスト/秒を小さなKubernetesクラスタと数コンテナでさばくことができており、シンプルでも意外といける ・GitHubでは、まず既存アーキテクチャで出せる限界まで使い切ってから、データや需要の伸びを見て「次の段階への書き換え」を判断している ・スタートアップのCTOであれば、いきなり100倍スケールを想定した設計をするのではなく、まずは100〜1000ユーザーを単一VMで捌くくらいのシンプル構成で十分だろう ・スケールアップは過小評価されがちだが、CPU数百コア、TBクラスメモリのVMが普通に買える現代は、これで十分に戦える ・水平分散やシャーディングに飛びつく前に、「まずは限界までマシンを強くする」だけで多くの問題は解決できる ・ソフトウェアは「一度作って終わり」ではなく「進化させ続けるもの」であり、保守と改修というランニングコストが常に発生する資産 ・ビジネス側は一括投資して10年もちそうなシステムを欲しがるが、技術もトレンドも変化が激しい現代では、それは非現実的な期待 ・現実的なやり方は「今の1桁上のオーダーに耐えられる設計をする」「そこに達したらまた次のオーダーのために再投資する」という階段方式 ・キャッシュやNoSQLや分散データストアなどは、「直面している具体的なボトルネック」が見えたときに初めて導入を検討すれば良い ・シンプルな設計や実装はスケールすればするほど価値が高まり、愚直・素直なコードの方が、大規模運用では安全で扱いやすい、という逆説が成立する ・大企業のシステムデザイン面接はスケールの話が多いが、実務経験がなくても理論とパターンを学ぶことで「ゲームとして攻略する」ことが実は可能 ・入社後すぐにゼロから巨大システムを1人で設計することはほぼなく、既存システムに入り、より経験豊富なメンバーからレビューを受けながら成長していくのが普通 ・AIエージェントがコードの9割を書く時代になりつつあり、優れたエンジニアの仕事の重心は実装から、運用・品質・リスク・パフォーマンス・設計判断へ移りつつある ・AIがコードを書くとしても、「何を作るべきか」「どの設計を選ぶべきか」「どのようにテスト・計測・ロールアウトするか」を決めるのは依然として人間の役割 ・プロとしてのソフトウェアエンジニアは、事業への数値的インパクトで評価される ・事業側の意思決定者は技術的な詳細や難しさを完全には理解できないため、エンジニア側に「ビジネスの言葉（売上・コスト・リスク・遅延による損失）」で語れる人が必要 ・そのためには、自分の作るシステムが現場のオペレーションやお金の流れにどう影響するかを、現場に足を運んで観察し学ぶ姿勢が重要 ・これからのエンジニアには、1つの分野を掘るだけでなく、広い分野を高速で学び、短期間で実務レベルに到達できる「学習スピード」と「学習の幅」が求められる ・すべての分野で達人になる必要はなく、「一部の領域で深い専門性を持ちつつ、他の領域もそこそこ分かるT字型のスキル構成」が強みに ・好奇心を鍛え、新しい分野に飛び込むことへの「居心地の悪さ」に慣れ、それを楽しめるようになることが、これからの時代のエンジニアの大きな武器だろう youtube.com/watch?v=LeUUxL…

クラウド側は冗長化すればするほど儲かる。ビジネス案件なんじゃないかと思っちゃうなぁ。 こういう方法が出てくると「もしもに備える」というだけで大量のエンジニアリング工数が必要になるってのに。それは利用者のコストとして見えにくい。 reuters.com/business/retai…