Reflection AI の 501B オープンウェイトモデル Beam が Hacker News と Techmeme の首位に並び、はてなブックマークと Zenn では mizchi の AI プログラミング手法の記事が首位に入る

Gleam の公式ブログで、Erlang ターゲットのコンパイル時に Erlang のソースコードを生成するのをやめ、Erlang の abstract format を直接出力するようにしたと告知した記事。コメントでの質疑によれば、rebar3 でビルドしたベンチマーク用のプロジェクトでは、Gleam から abstract format への変換のほうが Erlang から abstract format への変換より速かった。

コメントは Gleam の use 式に話題が移り、学習時に最もつまずきやすい点だが、理解すると可読性が大きく上がるという声が Gleam の作者 lpil を含む利用者から出た。use が継続渡しスタイルの API を助長しないかという問いには、公開パッケージを多くレビューしているがそうした例はほとんどなく、過剰に使われがちなのはむしろパイプ演算子だという回答があった。

David Bushell が Deno で動かしていたプロジェクトを Node.js に戻した経緯を書いたブログ記事。コメントによれば、記事では Deno のファイルシステム API や HTTP サーバー機能を、Node の対応する仕組みに置き換える作業を取り上げている。

コメントでは、Bun の TypeScript 対応や標準ライブラリ、性能に惹かれて採用したが、主要な依存である Playwright との問題が重なって Node に移したという報告や、同じく Bun から Node に戻したら驚くほどスムーズだったという声が出た。Bun は Playwright の問題を最近修正したという補足もあった。JavaScript 以外の利用者からランタイム変更の難しさを問う質問があり、ブラウザ外の API はランタイムごとに標準が異なるためだという説明が返された。

P2P 通信ライブラリ Iroh が、ネットワーク全体からコンテンツを持つノードを探す仕組みを紹介したブログ記事。コメントでの引用によれば、BitTorrent の mainline DHT を使い、UDP のアドレスを対応づける小さな索引サービス（udp-addr-index）を追加で用いる。Iroh は QUIC の上で NAT 越えのホールパンチングを実装し、調整には DNS か DHT を使う。

コメントでは、資金が尽きつつあり性能問題も克服できなかった IPFS の次世代版がようやく現れたと期待する声が出た。Iroh 側の関係者は、P2P 接続を確立できない場合の中継サーバーを有料で提供しているが、オープンソースのリレーを自前で運用することもできると補足した。DHT や DNS で Tailscale の調整サーバーを置き換えられるのではと試作しているという報告や、索引サービスが STUN や TURN に近く、送信元アドレスの詐称に悪用されないかを気にする声もあった。

作者がバージョン管理関連のツール Flirt のソースコードを公開したことを告知するブログ記事。コントリビューションにおける LLM 利用の方針も載せており、コードベースの探索や調査、デバッグなど、個人的な用途での LLM の利用は自由だと明記している。

コメントでは、初めてプロジェクトを知る読者向けに概要を書いてほしいという指摘があり、作者が記事に短い説明を追記した。LLM の方針は賢明だという声が出た一方、個人利用は「もちろん」自由という一言だけで LLM 推進派の側だと批判されかねないという指摘があり、作者はこの言い回しを削り、個人利用は方針の対象外だと脚注で説明する方向で考えると応じた。

議論の相手が「Claude says...」と LLM の回答をそのまま根拠として持ち出すことへの不満を書いた個人ブログの記事で、Lobsters では rant と vibecoding のタグが付いた。コメントで引用された部分では、AI がソフトウェアスタックを極度に過剰設計にしている原因だとも述べている。

コメントでは、全体の主張には同意しつつ、ソフトウェアの過剰設計は LLM 以前から利用者の囲い込みや大量のコードを書く動機などの悪いインセンティブで続いてきたという反論が複数出た。8 割方誤りだと思うことを Claude で素早く確かめられるのが利点で、「Claude says」と言う代わりにどうすればよいか分からないという声に対しては、自分で調べて知識を積むという昔からのやり方があるという返答と、それは調べる手間を相手に押し付けているだけだという再反論が続いた。

Rui Ueyama による高速リンカー mold の 3.0.0 のリリースページ。コメントで引用された 2.42.1 のリリースノートでは、mold を C++ から Rust に書き直しており、追加のパッチリリースが必要にならない限り 2.42.1 が最後の C++ 版になると告知していた。

コメントでは、Rust への書き直しの経緯が興味深いという声が出た。リンク先に LLM の話はないのになぜ vibecoding タグが付いているのかを問う書き込みに対しては、最近のコミットメッセージに LLM らしい文面が目立ち、リポジトリの貢献者で Claude が 2 番目に多いという指摘が返された。

Philip Zucker が、項の等価性を管理するデータ構造 e-graph を、等価だけでなく「一方が他方を精緻化する」という順序関係まで扱えるように拡張する考え方を論じたブログ記事。コンパイラの最適化や形式手法の文脈で使われる e-graph の拡張を扱っている。

コメントでは、多面体コンパイル（polyhedral compilation）で抱えていた問題を解くデータ構造になるかもしれないという声があり、ループネストを多面体として幾何的に比べていた従来の考え方を精緻化の関係で置き換えられるかもしれないと述べた。SSI や union-find との統一につながるかという問いに対しては、筆者が SSI はむしろ versioned e-graph や colored e-graph に近いと答え、関連する論文を挙げた。

Rust の async で、Future を実行するスケジューラー（ランタイム）がプログラムのどこに存在し、どう参照されるのかを掘り下げたブログ記事。Tokio がランタイムを「隠れた引数」のように受け渡している設計を問題として挙げている。

コメントでは、非同期ランタイムを利用者から見えなくしようとする試みは理解を助けるより妨げるという同意の声があった。一方で、スレッドなしでも動く健全な非同期実装なら、Rust ではグローバルまたはスレッドローカルな状態を持つのは避けられず、Tokio に固有の問題ではないという反論も出た。ページを開くと Firefox が落ちるという報告には、再現しないという返答が続いた。

自分で所有できるセルフホスト型のジムと体重のトラッカー。週の計画を立て、ガイド付きでワークアウトを進め、セットごとの記録と体重を残せる。スマートフォンで使え、複数のデバイス間で同期し、自前のパスキーログインの背後で動く。

リポジトリの説明によれば、スーパーセット、ウォームアップ、有酸素運動の記録に対応し、どの筋肉が鍛えられているか、疲労しているか、鍛えられずに落ちているかを表示する。FitNotes、Strong、Hevy からのデータ取り込みにも対応する。ライセンスは AGPL-3.0 で、GitHub と GitLab の両方でテストとパイプラインを回している。

PS5 の実行ファイルを Linux と Windows 向けに自動で移植するツール。実行ファイルを対象システムのネイティブ形式に変換するリリンカーと、動的リンクに使うシステム prx ライブラリの実装を含み、エミュレーションや別のランタイムプロセスは使わない。

README によれば、2D プラットフォーマーの Dreaming Sarah が GTX 1050 Ti と i5-7500 3.4GHz の環境で安定して 60fps で動く。シェーダーリコンパイラーは SPIR-V を生成し、未対応や想定外の状態では std::runtime_error を投げて終了する。SDL 経由のゲームコントローラーに対応し、キーボードとマウスの割り当ては anyps5-input.ini で設定する。相互運用性、研究、保存、互換性を目的とするという免責事項も記載している。

mizchi による AI プログラミング手法の棚卸し。人間の役割を、無茶振りでモデルの性能を観察し、評価指標を作り、自動化のループを構築し、得られた時間で評価指標を改善することと定義する。任せる前に AI に任せられる仕事か、完了の定義と評価指標は何かを考え、失敗したら原因がコンテキスト、権限、性能のどれの不足かを切り分けるとしている。

プロンプトは高速に陳腐化するとし、「あなたは優秀なプログラマです」のような指示は古くなったと述べる。グローバルプロンプトには node 24 以上、新規は pnpm、Rust は stable の 1.99 といった選択肢が複数あるときの判断基準だけを書き、一般的でないこだわりは Agents.md に書くという。

ループの例として、Git 履歴を見て次の作業を探す Ralph Loop、セッション終了ごとに指示を再送する /goal、実験的な dspy の RLM やマルチエージェントを挙げ、SRE やセキュリティの視点を与える探索的改善の指示例も並べる。

「AI 時代はタスクを AI にやらせ、人間は判断に集中する」という言説への違和感を 2 点挙げる記事。対象を理解しないまま妥当な判断ができるのかという点と、その判断すら AI への丸投げに近づいているのではという点で、専門外のタスクでは理解しないまま AI の推奨を選ぶことになると述べる。

AI のセーフガードの解釈が広がり、筋が悪いと AI が判断した指示に従うのを渋ったり、許可なく別案を実行したりする場面があるとし、超賢い AI と対等に議論して納得して動いてもらうために専門性を高める必要があると論じる。

判断だけをする働き方に完全に移ると知識やスキルが落ち、判断そのものが劣化するとして、抽象的に考える力と具体的な内容を理解する力は両輪だと述べ、意図的に自分の能力向上に時間を使うことを挙げている。

RAG、ナレッジグラフ、オントロジー、GraphRAG と次々に出てくる用語を時系列で整理し、最終的に Microsoft が公開している OSS の GraphRAG（記事中では MS GraphRAG）の仕組みを理解することを目指す解説記事。GraphRAG には一般的な Graph と RAG を組み合わせた手法と MS GraphRAG という 2 つの意味があり、後者にしかない仕組みもあるため区別するとしている。

前半ではまず LLM 単体での対話を取り上げ、事前学習していない新しい情報に答えられず、数値計算も苦手で、fine-tuning は追加学習のコストがかかると課題を整理する。そのうえで社内規定の質問を例に、プロンプトをもとに文書を検索して結果をプロンプトに埋め込む RAG の流れを説明し、情報が更新されてもモデルを更新しなくてよく、非公開の社内情報にも答えられる点を利点に挙げる。

Claude Code で UI を生成すると、修正指示が「もっと見やすく」のような感覚的な表現になりがちだという課題から、書籍『オブジェクト指向UIデザイン ──使いやすいソフトウェアの原理』（上野学、藤井幸多著、技術評論社、2020 年）の考え方を Agent Skill にまとめ、Skill の有無で生成される UI を比較した記事。題材は社内文書を検索して答える RAG システムの管理画面。

UI を「タスク（動詞）」ではなく「オブジェクト（名詞）」を起点に設計するオブジェクト指向 UI の考え方を紹介し、本書の 1〜3 章から 4 つの原則に整理した。名詞から動詞へ、オブジェクトが見えて直接触れる、一覧と詳細のビューを対応づける、モードレスにする、の 4 つで、それぞれに AI の出力を評価する判断観点を添え、生成された画面をレビューする評価軸にもなるとしている。

Kubernetes 上の Traefik でメンテナンス画面を出す既存の仕組みを、DB のメジャーバージョンアップなどでアプリの Pod を 0 台に落とす場面でも使えるようにした事例。既存の仕組みでは、社外 IP に IP 許可リストが返す 403 を errors middleware が拾ってメンテナンス画面に差し替え、statusRewrites で 503 に書き換える。

ON/OFF は GitHub Actions の workflow_dispatch で values.yaml を書き換え、ArgoCD が同期する。Pod を 0 台にするとルートごと消えて 404 になる懸念を調べると、providers.kubernetesCRD.allowEmptyServices が true ならルートが残って 503 が返ると分かった。Traefik 本体の既定値は false だが公式 Helm chart では true で、筆者の環境もすでに true だった。

プロジェクトマネジメントの業務を振り返り、大事だと感じた 3 点を AI を使わずに書いた記事。1 点目は、大きな問題は急に起きるのではなく小さな問題が育って表面化したものなので、言いにくいことでも見過ごされそうな問題を積極的に拾い、何も問題が起きない状態にむしろ居心地の悪さを感じるくらいがよいという考え。

2 点目は、プロジェクトを構成要素が影響し合うシステムとみなし、必要な情報を適切なタイミングで渡すなど、自分が何をするかより、どこに入るとプロジェクト全体が流れるかを考えること。そのためには時間軸と空間軸の意識、自分の余裕、プロジェクトをよく見ていることが必要だとする。3 点目は、線表は共有や進捗管理だけでなく、叶えられている状態を具体的に想像し、逆算して今やることを考えるためにも有効だという点。

Claude Code や Codex などの AI エージェントに API キーを使う作業を頼むとき鍵をどう渡せばよいかを、Claude Code、Codex、Gemini CLI、GitHub Copilot、Cursor の 5 つの道具の公式文書から調べた記事。利用者の操作で分けると渡し方は 6 つあり、鍵の文字列が AI の目に触れる所にあるほど漏れる道が増え、最も安全なのは鍵の文字列そのものを AI に渡さない OAuth だとしている。

対話文に貼った場合は、鍵が AI の会社のサーバーに送られ（Cursor は Privacy Mode を切るとプロンプトを保存し、学習に使うことがある）、手元の会話記録に残り（Claude Code と Codex は会話を手元に保存し、Claude Code は暗号化しない文字のまま）、Copilot CLI では GitHub のアカウントに同期されると図で示している。

社内 SaaS にアプリ内アンケート機能を追加した際、要件のすり合わせ開始から PR 3 本のマージまでを 2 日で終えた事例。速さの理由は AI の実装力ではなく要件定義の順序で、Claude Code でモックを先に作って画面で要件を決めたと述べる。文章の合意は誤解を隠し、これまでモックを先に作らなかったのは高くついたからだが、AI で数十分で作れるようになって順序が逆転したとしている。

5 つのステップのうち、最初に決めるのは回答形式の種類と非エンジニア向けの編集画面の有無という、後から変えるとテーブル設計からやり直しになる 2 点だけで、番号付きで yes / no で答えられる形で聞く。モックはプロダクトのデザイントークンと既存画面のコードを AI に読ませて実物と同じ色と部品で作り、全画面を 1 ページに縦に並べるとしている。

Gemini との対話形式で進む連載「システム設計視点の行動経済学」の第 36 回。冒頭で、2027 年 4 月 1 日に本格施行予定の育成就労制度を題材にした第 35 回を、システム設計、行動経済学、財源幻想からの脱却、国家レジリエンスの 4 つの視点で復習している。

第 35 回では、政策を一度決めたら変えない完成品ではなく、現実社会に投入して運用データを観測しながら継続的にデバッグし、Version 1.1、1.2 と更新していくコードとみなす考え方を示した。具体策として、事前審査、社会的コストの内部化、多重観測とデータの白書化、施行延期を可能にする安全装置という 4 層の設計を挙げ、行動経済学の視点では個人を責めず、局所的に合理的な行動が全体の自滅を招く合成の誤謬のインセンティブ構造を診断するとしている。

セキュリティ業界に入って 1 年の筆者が、2026 年 9 月下旬以降に大手企業などで不正アクセスや情報漏えいのニュースが一気に増えたと感じたことから、その背景と基本対策をまとめた記事。AI の普及だけが理由ではないとしている。

ランサムウェアはデータの暗号化だけでなく、バックアップの破壊、盗んだデータの公開をちらつかせる二重恐喝、業務停止そのものを狙う形に変わったと説明する。攻撃者は偵察、初期アクセスブローカー、横展開、情報窃取、RaaS 運営元、交渉役に分業したビジネスになっており、そこに AI が加わって自然な日本語のフィッシングメール、攻撃ツールの作成、侵入後のログ分析や脆弱性探しが高速化したとする。手薄な関連会社や委託先を踏み台に大企業を狙うサプライチェーン攻撃にも触れている。

2026 年 10 月 1 日にリリースされた Rust 1.99.0 について、派手な新文法はないものの、FFI、raw pointer、メモリ所有権、unsafe、ファイルシステム、Cargo に関わる人向けの変更を拾った記事。低レイヤーの道具が増え、unsafe の安全条件がより細かく言語化されたと述べる。

"C" と "C-unwind" ABI の可変長引数関数を Rust 側で定義できるようになり、C との間の中継コードを省ける場合があるが、安全になるわけではないと注意する。Vec::into_parts / from_parts、Box::into_non_null / from_non_null が stable になり、*mut T ではなく NonNull で低レベルな所有権の受け渡しを書けるようになったが、from_parts などは依然 unsafe で、allocation、alignment、length、capacity は呼び出し側が保証する必要があるとしている。

Oracle の SELECT AI で対象表を絞り込んでも、更新日時で期間を絞る、単価の合計を受注金額とする、存在しない文字列 'CONFIRMED' に変換する、似た名前の列同士を JOIN するといった SQL が生成される問題を扱う連載の第 2 回。原因は、テーブル名とカラム名だけでは LLM にとって業務上の意味が足りないことだとする。

対策として、テーブル・カラムコメント、Oracle AI Database 26ai のアノテーション、主キー・外部キーなどの制約でメタデータを補強し、AI プロファイルの comments、annotations、constraints を有効にする。コード値や単位、日付の役割、同義語を具体的に書き、SHOWPROMPT と SHOWSQL でメタデータが使われているかを確かめ、同じ質問セットで変更前後の SQL を比べるとしている。情報の重複や不要な情報は、かえって精度を下げうるとも述べる。