減速論が市場と中国の反応にまで届き、AI 関連株が世界的に下落した

Bryan Cantrill による AI をめぐる恐怖の論考。コメントでは、落ち着いた筆致で Sun にも DTrace にも一度も触れていない点が評価されている。

議論の中心は「LLM が思考するかどうか」より「誰かを傷つけうるか」に置くべきだという整理で、仮想空間には無制限に与えてきたアクセスを、生産設備やロボットなど物理世界にも同じように与えたときのリスクが繰り返し挙げられている。核兵器の発射施設や水処理場の制御を LLM に任せる無謀さを例に出す投稿もある。

実存的リスクを警告してきた研究者として Yoshua Bengio、Geoffrey Hinton、Stuart Russell の名が列挙され、「エンジニアリングは知性だけの行為ではない」という Cantrill の2023年の講演からの引用も参照されている。

プログラマが reduce を嫌う傾向についての考察記事。

コメントでの有力な説明は「reduce は強力すぎる」というもの。map と filter は用途が絞られているのに対し、reduce はその型シグネチャからリスト型そのものを構成できるほど汎用的だという議論が展開されている。

非対称性の例として、foldr から map と filter は容易に定義できるが逆はできないことが示され、Graham Hutton の1999年の論文「A tutorial on the universality and expressiveness of fold」が参照されている。「map は C の for だが、reduce は可変変数付きの for」という要約も出ている。

Web 用途では汎用性より対象を絞った非可逆圧縮で足りるとして、JPEG XL を批判する論考。

コメントでは反論が優勢で、JPEG XL の価値は深さではなく広さ、すなわちアルファチャンネル、10億×10億ピクセルまでの画像サイズ、32ビット深度、プログレッシブデコード、アニメーション、可逆と非可逆の両対応、4096の追加チャンネル、JPEG からの可逆変換にあるという整理が示されている。

「Web の平均的な利用者に可逆は不要」という前提への批判として、利用者の1%に影響する用途でも人数としては欧州の多くの国の人口を超えるという指摘、EC サイトが既存 JPEG を可逆再圧縮して即座に恩恵を得られる点を実利に挙げる投稿がある。一方で汎用性がもたらす実装上の摩擦を無視すべきではないという立場も残る。

構文構造を理解してマージを解決する git のマージドライバ。対応する言語とファイル形式を増やしている。

コメントでは過去に2度議論されていることが示され、公式サイト mergiraf.org に詳しい情報があると案内されている。

実用面では、動作が遅いこと、壊れた解決結果を作ることがあるため無人のパイプラインには組み込めないという指摘がある。これに対し、そもそも無人で回せる git のマージなど存在するのかという反応も出ている。

思考に最も影響を与えたブログ記事を挙げるスレッド。

各自のリンク集が共有されており、失わないよう3年前から記録を始めたという一覧や matklad のリンク集が挙がっている。

具体的な推薦として Sandi Metz の「The Wrong Abstraction」があり、間違った抽象は抽象がないより危険だという主旨。エージェント時代に読み返すと印象が変わるという投稿もあり、エージェントは人間以上に先人の轍をなぞりたがるという観察が添えられている。

シェーダの不具合が浮動小数点の小数部を取る処理で解消した経緯の記事。

コメントでは、Metal 向けのシェーダで、読まれない定数への代入という最適化で消えるはずの一行を入れないとクラッシュした、という似た経験が共有されている。

一方で、本文の大半が LLM によって書かれているとして読む価値を否定するコメントも付いており、その一点にスレッドの反応が集まっている。

GCC が定数除数の整数除算を乗算に置き換える仕組みの解説。

コメントでは、定数除数が与えられると2つのマジックナンバーを求め、除算を乗算と比較に置き換える手法であり reciprocal multiplication と呼ばれる、と整理されている。導出は2011年の論文にあるとされる。

関連書籍として「Hacker's Delight」や Programming Pearls が挙がっている。浮動小数点の精度問題への対策かという質問には、高コストな整数除算を imul と cmp に置き換えるものだという説明が返っている。

全員がプロダクトエンジニアになったという論考。

コメントでは、何を作るかを選ぶフィルタとしての役割が最も価値ある技能になり、事業側は技術的負債を気にしないという同意が目立つ。競合が待たない以上、3年かけた設計より1年で出すことが優先されるという現実論も並ぶ。

反対に、負債に追い越されて12か月間主要プロダクトの更新を出せず作り直しになった経験、20年物のコードベースがテストと共に健全に保たれている例がどれだけあるのかという問い返しもある。

README は、AI エージェントにインターネットへのアクセス能力を与える CLI だと説明している。対象は Twitter、Reddit、YouTube、GitHub、Bilibili、小紅書で、各サービスの API 利用料は不要としている。

想定している不満は具体的で、YouTube の字幕が取れない、Twitter API が有料で検索できない、Reddit はサーバ IP が 403 で弾かれる、小紅書はログインしないと開けない、Bilibili は汎用ダウンローダが遮断される、Web ページを取得しても生の HTML で読めない、といった状況を列挙している。

設計方針としては、接続方式は世代交代していくものなので、利用者が個別に選定・保守しなくて済むようにすることを掲げている。

録画番組をクラウドへ保存できる全自動ディーガの新機種。旧機種でも DiXiM U Cloud がクラウド保存に対応しており、月額380円で専用ストレージ100GB、ただし PC の再生アプリはクラウド再生に未対応だという補足が付いている。

コメントで繰り返し出るのは著作権の扱いで、個人のクラウドに mp3 を保存することが公衆送信とされた MYUTA 事件との整合を問う声がある。

市場環境への言及も多く、レコーダ市場が縮小する時期に円安と HDD 価格の高騰が重なったという指摘、TVer の見逃し配信が原則1週間では足りないという声、各局がオンデマンド配信するのが最も無駄がないという意見が挙がっている。

2027年4月から本人限定受取郵便の本人確認が厳格化され、スマートフォンに搭載したマイナンバーカードでの受け取りにも対応する。これまで使えた条件付きのパスポートなどは対象外になる。

コメントの多くは受け取れなくなる層への懸念で、免許証もマイナンバーカードも持たない場合に代替手段がなく、取得が任意の証明書が事実上必須になるのは筋が通らないという批判が目立つ。

厳格化自体を評価する声もある一方、代理受け取りができる基本型のほうが特定事項伝達型より条件が厳しくなっている点を不自然だとする指摘、どのメディアも受け取れなくなる人について書いていないという不満も出ている。

Windows 11 Home の初期セットアップ（OOBE）で、特定のリンクをクリックするだけで Microsoft アカウントの作成を迂回し、ローカルアカウントを作れるという記事。

コメントでは仕様かバグかの見立てが割れている。OOBE の大規模変更に伴いビルド 26200.5000〜8037 のどこかで入った変更だとする情報がある一方、明らかな仕様漏れで早々に塞がれるのではという見方も強い。

そもそもアカウント必須である必然性が理解できない、こうした手順がノウハウとして蓄積される状況自体がおかしい、という反応が多い。ローカルアカウントでも OneDrive の勧誘は続くだろうという皮肉、中華 PC では普通にローカルアカウントを作れるという指摘も出ている。

楽天モバイルが、楽天 ID を連携していない回線を自動解約するとしていた方針を撤回し、12月以降も継続して利用できるとした。

コメントでは総務省の指導があったのではという推測が繰り返し出ている。契約時に存在しなかった付帯条件を後から追加できるはずがない、という指摘も複数ある。

「悪いことはできないものだ」「怒られ発生か」といった反応が並び、撤回の背景を制度側の圧力と受け取る見方が多い。

併せて、電話をかけたいだけの場面でニュースや買い物情報を押し付けるアプリの設計への不満も書かれている。

コーディングエージェントの普及で LLM が日常的な開発道具になった一方、扱うデータと利用の実態を自組織の内側に収めておきたい場面があるとして、社内向けのローカル LLM Model as a Service を構築した事例。

コメントでは、社内共通の LLM 基盤を持てること自体を羨む声がある。

運用上の観察として、新しいモデルを追加するとリクエストの9割がそこに集中するという点が取り上げられ、結局は最新のものを使いたいだけだという反応が付いている。ビジネス展開も視野にという記述に対して、内容は一般的な範囲に留まるという批判も出ている。

Windows 11 の初期セットアップで Microsoft アカウントでのサインインか新規作成を求められる場面で、「詳細」を選ぶだけで回避できるという報告。

コメントでは、この手軽さに笑うという反応と同時に、明らかな仕様漏れのバグであり早々に対策されるだろうという見方が出ている。

アカウント必須という設計自体が理解できないという意見が並び、このまま残しておいてほしいという声も多い。同じ挙動を扱う記事がこの日はてなブックマークに2本同時に上がっており、Microsoft アカウントの強制に対する関心の高さが表れている。

会社支給 PC の起動に8分かかり、使い始めようとした瞬間に Windows Update でさらに10分を失うという投稿から、設備更新の提案が却下される職場の話に広がったまとめ。

コメントでは実体験の共有が多く、古いリースの HDD モデルでは保存時のビルドに毎回10分を失う一方、新しい MacBook Pro の現場は快適だという対比、手順書の最低スペックすら満たさない PC が配給される現場もあるという報告が挙がっている。

電源を落とさなければ済む、起動は始業後に行うもので必要なら会社が自動起動を設定すべきだ、という実務的な指摘もある。近年の PC 価格の上昇を踏まえて今後どうなるかを気にする声も出ている。

ローカルで LLM を実行する Ollama の v0.34 が ChatGPT デスクトップアプリに対応した。ChatGPT（Codex）アプリからオープンモデルを選択できるようになる。

ただし対応は macOS 限定という制約が付く。

コメントは多くないが、ChatGPT アプリから Ollama を叩けるようになった点を歓迎する声が出ており、macOS 限定である点が惜しまれている。ローカルモデルとクラウドのフロントエンドを同じ画面で使い分けられる構成に関心が向いている。

Claude Code、Codex、Agy を併用して開発するなかで、17万行規模のプロダクトでは生成コードのレビューが実質不可能になり、レビュー自体もトークンを消費するという問題からローカル LLM を試した記録。

環境は GeForce 3060（12GB）で、Ollama から qwen2.5-coder:14b を取得している。開発は Issue 単位でブランチを切り、規模が大きければスライスに区切って小さく実装を回す進め方。

モデルには Modelfile で temperature 0.05、top_p 0.8、num_ctx 8192 を設定し、git のステージ上の差分から重大な問題の候補だけを検出させ、要約・説明・総評・PR 本文・コミット説明を書かせないシステムプロンプトを与えている。

kaggle のポケカコンペに向けて読んだ『強化学習を学びたい人が最初に読む本』の読書メモ。1章から3章は Python と教師あり学習の説明のため省いている。

4章では強化学習の目的を、報酬和の期待値が最大となる方策を求めることと置く。再帰がある場合に報酬和が発散しないよう割引率を入れること、報酬和が状態・報酬・行動の3つの観点で確率的であることを整理している。

5章は Q 学習で、期待値を求めるのに全観測値を保持せず更新則 V ← (1-α)V + αr で収束させる方法、全探索を避けるための動的計画法、Q 値のベルマン方程式を扱う。本書が対象にするのはモデルフリーの手法。

技術スタックのボードとノベルティだけで妥協しないブース企画のために、筆者が心がけている5点を紹介する記事。Go Conference 2025 の ENABLE THIS CODE など複数のブース企画に関わった経験が背景にある。

前提として、企画者の属性とカンファレンス参加者の属性が離れすぎていないかを確認し、離れていれば該当する属性の社内メンバーを運営に巻き込むことを挙げる。来訪者が興味を持って質問したのに運営側が何も答えられない状況を避けるためとしている。

残りは、目的と手段の再帰で企画に落とし込むこと、来訪者の思考と行動をエミュレートすること、運営メンバーへ情報を共有すること、振り返りを実施すること。目的の例として短期・長期のリクルーティング、自社プロダクトの売り込み、情報収集を挙げている。

企業法務を主とする法律事務所でのエンジニアリング事例。弁護士の業務は Word が中心で、証拠整理などで Excel も使い、ほとんどが Windows のデスクトップ版 Office。案件資料は Google Drive に置かれ、PDF、Word、Excel、PowerPoint が大半を占める。

法務領域では Office のアドインとしてエージェントを実装し、開いているファイルだけを編集させる形が主流だが、それではエージェントの可能性が単一のファイルに閉じてしまう。弁護士の仕事は複数のファイルを参照しながら複数のファイルを編集するもので、DD になるとファイル数は膨大になる。

作ったのはローカルで動く MCP サーバ（Rust の Windows デスクトップアプリ）で、Claude Desktop や Codex Desktop から使う。利用者が非技術者であるため相応の安全策を取り、入力が学習に使われない設定とそれが可能なプランで運用している。

JOIN クエリで想定外に巨大な結果データセットが生じ、アプリケーションサーバー上のメモリ枯渇などを招くデカルト積問題について、メモリ使用量を計測した記事。

例として2つのクエリを比較する。users - posts - comments という親・子・孫の関係は問題にならず、users から posts と files という2つの子が生えるクエリのほうが問題になる。

親に2つの子が結びつく関係では、特定の親に紐づく子同士のデカルト積が結果セットの大きさに影響するため、単純な親子孫のリレーションとはレコード数が異なる。見た目が似ているために気付きにくい点を難点として挙げている。

株式会社 PRUM の採用広報担当が、未経験から IT 業界を目指す人によく聞く悩みとして「働きながら勉強する時間が取れない」を取り上げた記事。

勉強できなかった日に焦ってしまう、勉強時間を作れないことに引け目を感じるという人が少なくないとしたうえで、IT につながる経験は仕事が終わったあとにしか作れないわけではない、という見方を示している。

今の仕事を振り返れば「この作業、もう少し楽にならないか」といった着眼点が既にきっかけになっている、という筋立てで説明している。

Claude Code に Design doc や PR を書かせると「情報量は多いのに、何を決めたのかが頭に入ってこない」と感じる現象について、実際の GitHub PR を使って原因を確かめた記事。

内容が間違っているわけではなく、むしろ大抵は正しいとしたうえで、疲れる理由を4つに集約する。ひとつは網羅と重要度を区別しないこと。人間は「書くべき」「省いていい」の取捨選択を無意識に行うが、生成 AI は思いつく観点を同じ重みで並べるため、決定的な判断と自明な前提が同じ文量で説明され、読み手が重要度の仕分けを肩代わりすることになる。

もうひとつは結論が最後に来ること。人間は「結論から言うと」と先に言い切ることが多いのに対し、生成 AI は検討の過程を順に再生してから最後にまとめを書く構成を取りがちで、読み手は結論にたどり着くまで全情報を保持し続けなければならない。

2026年9月8日に、生成 AI がミレニアム懸賞問題のひとつであるナビエ・ストークス方程式の存在と滑らかさに関する問題の一部を解決したという発表があった。外力がある場合に3次元の流れの解が有限時間で特異点を生じうる、つまり滑らかな解がいつまでも続くわけではないことを示したものだと説明されている。

筆者が着目するのは、成果が解析的な証明だけでなく Lean による形式化とセットで公開された点。Quanta Magazine の記事でも、形式化が「それが本当に正しいという確信を数学者に与えている」と書かれている。人間が読み切るには重すぎる証明でも、機械が通したのであれば信じられる、という構図になっている。

そのうえで、Lean の無矛盾性と信頼の根拠を扱う。成果の帰属や発表に至る経緯をめぐる論争には立ち入らないとしている。

バックエンドの基礎を42日で学ぶ連載の第32回で、Web サーバー、アプリケーションサーバー、データベースという3層アーキテクチャを扱う。以降の AWS 編（#34〜#38）がすべてこの構図の上に乗るという位置づけ。

到達目標は、各層の役割とその分け方が定番になった理由を説明できること、「アプリケーション層はステートレスに保つ」という原則をスケールアウトの仕組みから説明できること、データベースをインターネットに直接公開しない理由を実際の構成で確かめて説明できること。

説明は銀行の支店の比喩を使い、窓口・事務室・金庫に対応させる。言語に依存しない回として、Go 編と Python 編どちらの読者も対象にしている。

「借金完済が経済を破壊する : Python で学ぶマクロ経済学入門 Podcast 14」という動画の内容を、Gemini との対話形式でまとめた記事。Qiita の記事をベースに、Python を用いたマクロ経済シミュレーションの結果とロジックを解説している。

論点のひとつは、国家財政を家計簿として捉える危険性。「誰かの赤字は別の誰かの黒字」という会計上の原則から、政府の帳簿を黒字にすると民間部門が赤字になるとし、1997年以降の日本が増税と支出削減で需要を消滅させたと指摘する。

もうひとつは、借金の絶対額ではなく経済規模に対する債務比率を見るべきだという点。名目経済成長率が名目金利を上回っていれば比率は抑えられる、という整理を示している。

プロジェクトが大きくなると AI への修正依頼が遅くなり、回答がずれたり関係のない場所を壊したりする現象を、AI の性能ではなく「変更前に読み解く情報量」の問題として捉える記事。

この量を IRV（Issue Reading Volume）と呼ぶ。呼び方は新しいが、見ているのは実務でおなじみの「変更前の調査範囲」だとしている。主張は、AI コーディングの速さを保つには変更ごとの調査範囲を小さく保つこと。

扱う内容は、AI が読む情報量を確認する方法、ファイル数を減らさずに AI が読む範囲を小さくする方法、やってはいけない IRV の減らし方、次の Issue で使えるチェックリスト。身近なチャットアプリの例から説明を始める。