OpenAI DevDay 2026 の GPT-6.1 Sol と常時稼働エージェント Dots が Hacker News の 1・2 位となり、Techmeme の上位も DevDay とホワイトハウスでの AI 合意の報道で占められる

Wayland 向けのスタッキング型（重ね合わせ型）ウィンドウマネージャー CoW の紹介ページ。Fvwm の長年の主要開発者 Thomas Adam 氏が始めたもので、Fvwm を X から移植するのは現実的でないため、その Wayland 版の後継と位置付けられている。

コメントには river の開発者が参加し、river の上にこうしたものが作られるのを期待していたと歓迎した。作者本人も、X11 の先行きが不透明ななか、Wayland を使わざるを得なくなったときの環境を用意するための趣味の取り組みだと説明している。

X11 を IPC に使って既存の X11 ウィンドウマネージャーのバイナリで Wayland のウィンドウを管理する構想を語る人もいたが、Wayland に対応する機能がない部分で問題が出るうえ、二重バッファリングされない X11 の状態管理ではフレーム単位の正確さを失うという指摘があった。

複数のパターン文字列をテキストの 1 回の走査で同時に見つける Aho-Corasick 法を解説した記事。

コメントでは、Rust の regex クレートが遅延 DFA より有利な場面で aho-corasick クレートを使っていることが紹介された。パターン数が多いファイアウォールやアンチウイルスには Intel の HyperScan を基にした VectorScan のほうがよいという意見に対し、そのクレートは版が 1 つしかなくリポジトリも削除されており、ベンチマークも再現できなかったという反論が出た。

Web コンテンツフィルターで語の重み付けに使っていたという経験談や、Markdown エディタ KeenWrite での R 式の評価への利用、UTF-16 で Rust を上回った Haskell 実装の紹介もあった。

Neovim を使ってきた筆者が Emacs に乗り換えた経験をまとめた記事。Emacs は組み込みのパッケージリポジトリが充実しており、M-x package-install で自動的に導入できる点などを挙げている。

コメントでは、Doom Emacs は大量のパッケージを導入・設定するため、この方法でのパッケージ追加を推奨せずバージョンを固定しているという補足があり、実際にパッケージの不整合で環境が壊れた経験から固定は正しいという意見も出た。

Neovim をすべて削除し、サーバーでは vim-classic、2 台のマシンでは emacs-bedrock と evil-mode を使い始めたという報告や、プラグインなしの Neovim を Neomutt や Offpunk と組み合わせてメールや RSS まで扱っているという人もいた。

OpenShell は、自律型 AI エージェントの群れを安全かつプライベートに動かすためのランタイム。エージェントはファイルの読み書き、パッケージの導入、API 呼び出し、資格情報の利用ができて初めて役立つとしたうえで、データや秘密情報、ネットワークへの無制限のアクセスを与えずにそれらを可能にすることを目的にしている。

各エージェントは隔離されたサンドボックスで動き、カーネルの制御でアクセスできるファイルとシステムコールを制限し、すべてのネットワーク接続をサンドボックスを出る前にポリシーで検査する。エージェントは本物の資格情報を見ず、承認済みの宛先へのリクエストにだけ OpenShell が付与する。

ポリシーの変更は承認前に形式検証にかけ、資格情報を持って新しいホストに接続するといった危険な新規アクセスを検出して人間のレビューに回す。0.1.x では安定したリリース周期と新しい隔離の仕組み、拡張ポイント、API が加わった。

PageIndex は、ベクトル検索の代わりに推論で検索する RAG エンジン。ベクトルベースの RAG は意味の類似度で検索するが、類似していることと関連していることは違い、長く複雑な専門文書では関連があるのに似ていない箇所を取りこぼすという問題意識から作られた。

AlphaGo に着想を得て、ベクトルインデックスの代わりに文書ごとの階層的な木構造インデックスを生成し、LLM がその木を推論しながら探索する 2 段階で検索する。専門家が長い報告書の該当節を開いて読む方法をまねたものとしている。

2026 年 8 月には pip で入る SDK にローカルモードが加わり、自分の LLM キーで索引作成から検索、チャットまで手元で完結できるようになった。テキストベースの PDF 向けの高速な索引生成 PageIndex Flash や、コーパス全体を扱うファイル単位の木構造索引も発表している。

Openship は、CI/CD を内蔵したオープンソースのセルフホスト型デプロイ基盤。リポジトリを指定すると、アプリのビルド、デプロイ、ルーティング、TLS 終端までを行い、デスクトップアプリ、Web ダッシュボード、CLI のいずれからも操作できる。

最初に決めるのは制御プレーンの動かし方で、1 人で運用するならデスクトップアプリ、チームで使う場合や push によるデプロイ、自前サーバーでのアプリのホストが必要なら openship up によるセルフホストのサーバー、何も運用したくなければ管理型の Openship Cloud を選ぶ。

デスクトップアプリは起動している間だけ手元のマシンで制御プレーンを動かし、SSH で接続したサーバーを操作するため、常時稼働のサーバーや公開された窓口を残さない。macOS（Apple シリコン・Intel）、Windows、Linux 向けに配布している。

AI がコードを書くようになり E2E とユニットテストのどちらを厚くすべきかという議論が増えたが、テストの種類ごとに検出できる不具合は違い、その役割は AI が来ても変わらないとして使い分けを整理した記事。

型・lint、ユニットテスト、PBT、integration テスト、E2E テスト、探索的テストについて、値の取り違え、境界値を含む計算の誤り、DB・永続化の誤り、画面をまたぐ結合の誤り、仕様の漏れなど不具合の種類ごとの検出力を表にまとめている。どの自動テストも書かれたことしか検証しないため、想定外の不具合は探索的テストで探すしかないとする。

AI に実装させテストが通るまで修正させる進め方では、1 回の反復の待ち時間と反復回数が生産性を左右する。速く失敗の原因まで示せる型検査、lint、ユニットテスト、PBT を反復の中のフィードバックに使い、遅い integration と E2E は結合や実環境の確認に集中させる方が活きるとしている。

Cloudflare が公開した次世代の統合 CLI cf（現在 v1.0.0-beta）への移行記録。従来の wrangler.json や wrangler.toml から、TypeScript ベースの設定ファイル cloudflare.config.ts への移行が推奨されており、公式の cf migrate コマンドもあるが、実行するだけではそのまま本番で動かないとしている。

移行の利点として、設定の型チェックと補完、cloudflare.config.ts から env の型を逆算する cf workers types、DNS や R2、D1 などを同じコマンド体系で扱える統合 CLI、Vite や React Router との連携、AI エージェントとの親和性の 5 点を挙げる。

React Router v8 と Vite による Workers のフルスタック構成と、キューやバッチの Worker を含むマルチ Worker 構成を例に、cf migrate から本番デプロイまでの手順と、遭遇したエラーと対処を整理している。

2011 年から会社の指定で Git を使ってきた筆者が、2026 年に初めて自分の意思で VCS を選び、Jujutsu に移行した経緯と理由を書いた記事。Claude Code などの AI コーディングエージェントでコードを書く速度が上がり、Git の add と commit の手間や、理解が浅いまま commit したコードを後から直す rebase の失敗が日常的な負担になっていたという。

Jujutsu は設計思想もコマンド体系も Git と大きく異なり最初は使いこなせなかったが、インデックスが存在しない手軽さと、どの操作も undo で戻せる安心感から 1 か月ほどで扱えるようになり、現在はすべてのリポジトリと原稿執筆を Jujutsu で管理している。

戻れない理由の 1 つ目として、作業ディレクトリの状態がそのまま commit になるため、保存のタイミングを考えなくてよく、stash に相当する退避が不要で、作業中のコードを失う危険がほぼないことを挙げている。

データサイエンス実務向けの AGENTS.md と Skills を公開した前回の記事の続編。今回は決まった手法を実行するときの分析診断を標準化するもので、MCMC なら CmdStanPy を使って収束診断をする、因子分析ならバイプロットを見る、回帰分析なら診断図を出すといった「手法×ツール×可視化・診断」のセットを事前に定義し、毎回の指示やレビューでの確認漏れを減らすことを狙う。

難しい点として、どのセットを採用するかの取捨選択と、スキルが増えすぎることによるコンテキストの肥大化と取り違えを挙げ、AI が気を利かせずにやらなかったことや人間のチェックで見つかったミスをもとに選んだという。

対策として、統計的推論などの第 2 ルーターを挟むルーティングの 2 段化（progressive disclosure）で手法別のスキルを設計し、新しいセッションで分析を頼んだときにスキルが発火するかも検証している。

トランザクションの中に処理を書く順番について、簡単な指針を紹介する記事。EC サイトの注文確定処理で、注文確定メールを送った後に在庫の引き当てで失敗してロールバックすると、確定していない注文の確定メールが利用者に残ってしまう例を挙げる。

Jim Gray の 1981 年の論文「The Transaction Concept: Virtues and Limitations」に基づき、処理を取り消しも再実行も要らない非保護（一時ファイルへの書き込みや読み取り）、ロールバックで戻せる保護（通常の DB 操作）、実行したら取り消せない実（メール送信や現金の払い出し）の 3 つに分類する。

解決策は実アクションを最後に実行することで、例ではステータス更新と在庫の引き当ての後にメールを送る順に書き換えている。実アクションが複数ある場合など、それでも困るときはトランザクショナルアウトボックスパターンを検討するよう勧めている。

サンフランシスコで開かれた OpenAI DevDay 2026 の発表を現地からまとめた記事で、加筆中としている。公式の Recap ページに載った発表は 25 項目で、キーノートでは Sam Altman CEO が dots、ChatGPT Space、GPT-6.1 Sol、Ultrafast、Decisions API などを紹介した。

主な発表として、GPT-6 Astra に近い性能を低コストで使える GPT-6.1 Sol、高速にトークンを生成する Ultrafast、Codex のクラウド環境と CLI、コードレビュー機能の強化、Computer Use に対応した Agents API、Sign in with ChatGPT、月額 500 ドルの Pro 500 を挙げる。

dots は GPT-6 Astra を使い、専用のクラウド上のコンピューターで与えた目標に向けて 24 時間動くエージェントで、4,000 を超えるアプリにプラグインで接続できる。対象は Pro と Business Premium で、dots 単体ではレートリミットを消費しない。

コミュニティ JISSEN が開いた「具体と抽象」をテーマにしたイベントの参加レポート。AI とエンジニアについての話のほか、運営メンバーが求めている本を 3 つの質問で推理するワークと、来店客が減ったカフェのオーナーへのヒアリングから原因の仮説と改善策を考えるワークが行われた。

筆者は、AI 時代のエンジニアの価値として、コードの良し悪しを判断するための基礎力と、誰の何をなぜどうやって解決し、いつ最大の価値を出せるかを考える力を挙げている。日本の学びは板書してまとめてから問題を解くが、アメリカはまず行動し、失敗から気づいて原理を学ぶ逆の順序だという対比も紹介している。

感想として、「なぜ」を 5 回ほど深掘りすると本質に近づくと感じたこと、エンジニアの価値は上流の判断や問題提起の力に移っていくと考えたことを書いている。

ブログの画像を差し替えても X に貼ると古い画像のまま、あるいはカードが灰色の枠になる問題への対処を書いた記事。冒頭で、著者のみのるん氏に代わって Claude Code が書いたと断っている。

X のクローラーはリンク先の OGP からカードを作ってキャッシュし、同じ URL では使い回すため、サイト側を変えても古い画像が出続ける。X にログインした状態で公式の Card Validator に URL を入れて Preview card を押すと、キャッシュを無視して読み直され、数分でカードが入れ替わる。画面に出る告知は 2022 年 8 月のプレビュー機能廃止のもので、キャッシュの取り直しは今も動くとしている。

URL に ?v=1 を付ける定番の方法は、カードと画像のキャッシュが別のため画像が古いまま残ることがあり、正規 URL を宣言する connpass のページではカード自体も変わらなかった。自分のサイトなら画像側の URL を変えてから Card Validator を使うのが確実だとしている。

モバイルアプリのリリース前の手動テストで、Google スプレッドシートで管理していたテストケースが荒れた問題を、ケース管理をコードに移して解消した記事。PR ごとに実装者がばらばらにケースを追加していたため、同じ確認の重複、新旧ケースの期待値の矛盾、どの PR で増えたか追えないといった問題が起きていた。

ケースの定義はリポジトリ内の YAML に置いて PR でレビューし CI で検証し、テストの実施と結果の記入はスプレッドシートで行う形に分けた。スプレッドシートにはマージ済みの YAML から生成した xlsx を取り込む。id は変えず再利用しない、input には操作を 1 つだけ書く、expected には観察できる結果を書くといった記述ルールも定めている。

CI の検証はエラーと警告の 2 段階で、未知のキーや必須項目の漏れ、ID の重複、表記ゆれを正規化したうえで実質同一のケース、前提条件と操作の矛盾をエラーにし、文字列の類似度が高いケースを警告として出す。

Object.prototype に then を生やすと、Promise ではない {} を await しただけでその then が呼ばれることを示し、原因となる仕様を解説した記事。await は引数が Promise かではなく then メソッドを持つ thenable かどうかで解決を判断しており、これは Promise が標準化される前の各ブラウザの独自実装との互換性を保つためだという。

この then インジェクションを正面から使ったのが CVE-2025-55182（React2Shell）で、想定外のオブジェクトを解決させることがサーバー側での任意コード実行の足がかりになった。ほかに CVE-2024-43357、CVE-2024-9680、CVE-2021-21206 もこの仕様に起因するとしている。

対策として TC39 の提案「Curtailing the power of "Thenables" (SafeResolve)」を紹介している。現在 Stage 2.7 のテスト段階だが、Promise だけを解決する形ではなく then の出どころを確認する複雑な解決策で、また抜け道が見つかりそうだと筆者は評している。

受託開発案件でバッチの監視とテストを担当した筆者が、バッチが実行されたかだけでなく、正常に動き続けているか、時間内に終了したか、異常から復旧できたかまで確認する必要があると学んだ経験を、初心者向けにまとめた記事。

バッチ処理はユーザー操作ではなく時刻や条件で実行され、途中で止まってもすぐには気づかれにくいため、実行中と終了後の状態の監視が重要になるとして、Web API との違いを表で整理している。

この案件では CloudWatch Logs へのログ出力、Laravel Cache を使った heartbeat、監視 API、外形監視を組み合わせた。開始時に action:start、正常終了時に action:end を BATCH_ID 付きで出力し、毎時 00 分に動くバッチで予定時刻から 5 分を過ぎても action:start がなければ異常と判定する監視 API のコード例を示している。

API 設計で Google の AIP やスタイルガイドを参考にしている筆者が、Google JSON Style Guide の「空や NULL のプロパティは JSON から削除することを検討する」という規約を採用したときに、PATCH による部分更新で生じる課題を扱った記事。未入力の値をプロパティごと省くと、「空にしたい」と「何もしない」の区別が問題になる。

前提として、Google のスタイルガイドは理由やトレードオフが明記されていることと、知名度が高く導入コストが低いことを採用理由に挙げる。ただしあくまでガイドラインで、Go なら Effective Go や gofmt を優先し、Google のガイドは補足として扱っている。

本題では、意味上の強い理由がない限り任意項目や空・NULL の値はプロパティごと省くことを検討するという Empty/Null Property Values の原文を引いたうえで、この課題に対して採用してきた 2 つのアプローチを紹介している。

Oracle の SELECT AI で、生成された SQL に期待と違うテーブルが使われる問題を扱う連載の 1 回目。受注、請求、入金などのテーブルがあると「売上」がどれを指すのかは人間同士でも確認が要り、LLM に全テーブルを見せると選択肢がさらに増えると説明する。

モデルやプロンプトを変える前に SELECT AI に見せるオブジェクトの範囲を見直すべきだとして、AI プロファイルを業務目的ごとに分け、object_list に必要なテーブルとビューだけを指定し、enforce_object_list で指定外の利用を抑止する方法を示す。SHOWPROMPT と SHOWSQL で渡された内容と生成 SQL を確認し、固定した質問セットで絞り込み前後を比較することも勧めている。

想定環境は 2026 年 9 月時点の Autonomous AI Database Serverless 26ai と OCI Generative AI で、object_list_mode=automated はすべての環境で使えるわけではないと注意している。