GenAI catch-up 調査ノート 2026-10-13

🤖 Generated by Claude Opus 5.5

• 対象期間: 2026-10-10 〜 2026-10-13 (前回の定期実行 10-10 以降、候補 32 件)。
• 取得できなかった情報源: hn-claude-code (接続のタイムアウト) と hn-mcp (hnrss.org が 502 Bad Gateway を返した) で、どちらも再試行でも取れなかった。
  • 同じクエリを Hacker News の Algolia の検索 API にかけても、期間内に 100 ポイント以上を集めた対象範囲の記事は見つからず、このノートの Hacker News の数値はその API から取った。
• トピック 1 は 2026-10-01 のトピック 5 の続きで、トピック 6 は 2026-10-10 のトピック 9 で見送ったものが戻ってきた。
• トピック 1〜5 は期間より前に公開され、今回の実行で ainews、laiso-newsletter、zenn-trending、hatena-ai-agent を通じて初めてフィードに現れた。

候補と選定

• 選定 (レポートに載せる):
  1. ドキュメント、SDK、価格がそろってパブリックベータになった OpenAI の Decisions API (起点 10-06、期間前の出来事で laiso-newsletter と ainews で初出、影響度 2 / 将来性 2 / 注目度 2)。
  2. Foundry と OpenRouter でパブリックプレビューになった Microsoft-Decision-1 (起点 10-09、期間前の出来事で zenn-trending、laiso-newsletter、ainews で初出、1 / 2 / 2)。
  3. SQLite のソースツリーに移され、3.54.0 のソースに入った vec1 (起点 09-30、期間前の出来事で zenn-trending で初出、1 / 2 / 2)。
  4. developer preview の Strands Box と、EC2 Mac での実測 (起点 10-07、期間前の出来事で zenn-trending で初出、1 / 2 / 2)。
  5. 航空の制度を引いて、AI コーディングエージェントから引き継ぐ力を保つべきだと論じたエッセイ (起点 10-05、期間前の出来事で hatena-ai-agent で初出、1 / 1 / 2)。
  6. 10-10 に見送り、取り上げる記事が増えて戻ってきた Claude Managed Agents の dynamic workflows (起点 10-09、期間前の出来事で ainews で再び現れた、1 / 2 / 1)。 - 1 は 2026-10-01 のトピック 5 の続きで、そのときはエンドポイントもスキーマも価格も公開されていない限定プレビューだったが、10-06 に始まったパブリックベータはどのフィードにも載らなかった。 - 2〜4 は合計 5 で並び、いずれも影響度 1、注目度 2 なので、独立した情報源の数 (9、8、6) で順位を決めた。 - 5 と 6 は合計 4 で並び、影響度はともに 1 なので、注目度で 5 を上にした。 - 6 は 10-10 にリリースノートの外での議論が見つからず 1 / 2 / 0 で見送ったが、今回は The Decoder とそのドイツの姉妹サイト MIXED、XenoSpectrum、実務者の記事が見つかり、既存のメディア 1 社とコミュニティの投稿として数えた。
• 見送り (次回の判断材料):
  7. LLM の能力についての理解の差が広がっているという Karpathy の投稿 (起点 10-11、0 / 1 / 2) — 新しいデータのない論考で、GenAI のエンジニアが作るものを何も変えない。
  8. 解説記事で再び取り上げられた、コーディングエージェントでソース非公開のアプリをリバースエンジニアリングするツール REA (起点 04-14、背景、0 / 1 / 2) — 4 月のツールで最近のリリースも定例のものなので、起点にできる最近の出来事がない。
  9. Vibe Code Bench でのエージェントのチームについての Vals AI の調査 (起点 10-09、1 / 1 / 1) — ベンチマークの持ち主による 1 つの調査で、論じたのはアグリゲーターだけ。
  10. ウェイトリストのすべての Pro と Max のユーザーに開かれた Claude Code Projects (起点 10-09、1 / 1 / 1) — ベータの対象を広げただけで、論じたのはアグリゲーターだけ。
  11. OpenRouter に出た StepFun の Step 5 Preview (起点 10-08、1 / 1 / 1) — オープンウェイトが次の期間の 10-15 に出る予定のプレビュー。
  12. その他の単発項目 — 下記に列挙。
  13. 対象外 (スコープ外) — 下記に列挙。

1. 🎯 OpenAI が Decisions API を全開発者向けのパブリックベータにし、gpt-6-luna の POST /v1/decisions はテキストと画像から確率、選択、ルーブリックのスコアを返し、料金は入力 100 万トークンあたり $0.10 で出力とキャッシュの課金はなく、一般提供は数週間以内の見込み

• 選定 / 影響度 2 / 将来性 2 / 注目度 2 / 起点 10-06、期間前の出来事 / 種別: リリース / 領域: モデル、API・クラウド。
• 候補になったフィード項目:
  • laiso-newsletter 10-12 #22 Jevその後 (無料部分で、Decisions API を Responses API とは別の、画像も受け付ける専用のエンドポイントとして紹介) — はてなブックマーク 1 user (取得時点)
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (決定モデルが製品のカテゴリーになりつつあるという節) — パブリックベータのガイドは 10-06 から Hacker News で 393 ポイント、231 コメントを集めた
• 起点: OpenAI の API の changelog、X の投稿、openai-python v3.26.0 はいずれもパブリックベータの開始を期間の 4 日前の 10-06 としており、当時はどのフィードにも載らず、今回の実行で ainews と laiso-newsletter が初めてフィードに運んだ。

前回からの継続

• 2026-10-01 のトピック 5 は、09-29 の DevDay で発表された限定プレビューと、Every による Jev との最初の比較を扱ったが、その時点ではエンドポイント、スキーマ、モデル ID、上限、料金のどれも公開されていなかった。
• その後 OpenAI は 10-06 に、ガイド、API リファレンス、5 つの言語の SDK、Playground をそろえて API をすべての開発者向けのパブリックベータにした: エンドポイントは POST /v1/decisions、モデルは gpt-6-luna だけで、入力は 100 万トークンあたり $0.10、出力とキャッシュには課金しない。
  • Luna と同じ価格だという Nikunj Handa の発言は、いまでは Luna のキャッシュなしの入力単価についてだけ当てはまる。

収集した情報

[A] OpenAI — Decisions guide (2026-10-06, as fetched on 2026-10-13)

https://developers.openai.com/api/docs/guides/decisions

• API はパブリックベータで、一般提供は今後数週間のうちの見込みとされ、モデルは gpt-6-luna だけで、リクエストは専用の POST /v1/decisions に送る。
• リクエストのフィールドは model、input (テキストの文字列か、input_text と input_image のパーツを持つユーザーメッセージで、すべての質問に共通)、questions の 3 つである。
  • レスポンスの answers 配列は、質問ごとの name をそのまま返す。
• predicate の質問は条件が真である確率 probability を 0〜1 で返し、choice の質問は渡した値の 1 つと、probabilities 配列、それとは別の confidence を返す。
• score の質問は 0 から数えるレベルの番号の確率加重平均を返すので、3 段階の深刻度に 0.1、0.7、0.2 の確率が付けば、2 つのレベルのあいだの 1.1 になる。
• 同じ入力についての独立した質問は 1 つの questions 配列にまとめて種類を混ぜられるが、前の答えに依存する判断には 2 回目のリクエストが要る。
• どの質問も型 refusal で返ることがあり、SDK のサンプルはそれで分岐する。
• 抽出したフィールド、文章での説明、ツール呼び出しは、Responses API の Structured Outputs か function calling に回すよう案内する。
• 画像はインラインの base64 の data URL に限り、ホストされた HTTP(S) の URL と file_id の入力はこのエンドポイントでは使えないとする。
• しきい値はラベル付きの例と、偽陽性と偽陰性のコストから決め、other のような逃げ道の選択肢を加えるよう勧める。
• 入力は 100 万トークンあたり $0.10 で、キャッシュの読み書きと出力トークンには課金しないが、リージョン処理の割増と長いコンテキストの倍率はかかり、gpt-6-luna へのほかのリクエストは通常のモデル料金のままである。
• 対象の顧客向けに Zero Data Retention と HIPAA に対応し、データレジデンシーとリージョン処理は米国と欧州 (EEA とスイス) で使える。
• SDK のサンプルは client.decisions.create(...) を呼び、Python 3.26.0、JavaScript 7.30.0、Go 3.73.0、Ruby 0.101.0、Java 4.78.0 のいずれかが要り、Playground は platform.openai.com/decisions にある。
• ガイドの見出しは型付きの答えを Responses API の約 10 倍の速さで返すとうたうが、ベンチマークは示さない。

[A] OpenAI — API reference: Create a decision (as fetched on 2026-10-13)

https://developers.openai.com/api/reference/resources/decisions/methods/create

• 1 つのリクエストに画像を最大 128 枚、base64 の data URL か公開アクセスできる HTTP(S) の URL で渡せるとしており、ガイドと食い違う。
  • ファイル ID、ほかのロールのメッセージ、関数呼び出し、ファイル、音声、item の参照は拒否され、detail には low、high、auto、original を指定できる。
• choice の質問は 2〜255 個の重複しない選択肢を取り、値は文字列か真偽値で、同じ表記の文字列と真偽値は別の値として扱う。
• 答えは質問した順に返り、拒否された質問は質問の name (または null) だけを持ち、ほかの質問にはそのまま答えが返る。
• レスポンスの usage は input_tokens、cached_tokens、cache_write_tokens、output_tokens、reasoning_tokens を報告し、例では出力トークンが 0 で、任意の safety_identifier (128 文字まで) でエンドユーザーを識別できる。

[A] OpenAI Developers — API changelog, GPT-6 Luna model page and openai-python v3.26.0 (2026-10-06, as fetched on 2026-10-13)

https://developers.openai.com/api/docs/changelog / https://developers.openai.com/api/docs/models/gpt-6-luna / https://github.com/openai/openai-python/releases/tag/v3.26.0

• changelog は gpt-6-luna と v1/decisions のタグを付けた項目でベータの開始を 10 月 6 日とし、同じ日に出た openai-python v3.26.0 は単体の Decisions への対応を加えた。
• 同じ日に OpenAI は API の利用ティアを 5 つから Build、Launch、Grow の 3 つに減らした。
• Luna のページはコンテキストウィンドウを 1,050,000 トークンとし、入力が 272K トークンを超えるプロンプトは入力とキャッシュの単価が 2 倍、リージョン処理は 10% の割増としており、Decisions のガイドがいう倍率はこれらとみられる。
• Responses API での Luna は 100 万トークンあたり入力 $0.10、キャッシュ済み入力 $0.01、キャッシュの書き込み $0.125、出力 $0.50 なので、Decisions はキャッシュなしの入力単価を保ち、出力の課金をなくした形になる。
• Luna のページの 18 行のエンドポイントの表に v1/decisions の行はなく、gpt-6-luna のレート制限は Build の 5,000 RPM、2,000,000 TPM から Grow の 30,000 RPM、180,000,000 TPM までで、Decisions にも当てはまるかは書かれていない。

[A] OpenAI — Connect voice to Decisions (as fetched on 2026-10-13)

https://developers.openai.com/api/docs/guides/decisions-voice

• 対になるこのガイドは、クライアント委任モード (delegation: { type: "client" }) の Live API と Decisions を組み合わせる: アプリが文字起こしとアプリの状態を /v1/decisions に送り、選ばれたアクションを実行し、その結果を session.commentary.append で GPT-Live に伝える。
• choice の質問は reason という選択肢を通じて複雑な依頼を Responses API の推論モデルに回せ、next_slide のようなアクションや、当てはまるものがないときの noop は Decisions に残す。

[A] OpenAI Developers on X — public-beta announcement (2026-10-06)

https://x.com/OpenAIDevs/status/2107573382229188645

• 告知は、判断を Responses API 経由の GPT-6 Luna より最大 10 倍速く返すとうたい、ガイドより比較の対象が狭い。
• スレッドは用途として、モデル、ツール、エージェントへのルーティング、大量のラベル付け、ランキング、スコア付け、画像の分析、視覚的な内容の比較や動画の重要なフレームの発見、ボタンの選択やフォームの操作を挙げる。

[B] Simon Willison — llm-openai-decisions 0.1a0 (2026-10-06)

https://simonwillison.net/2026/Oct/6/llm-openai-decisions/

• Jev 向けの自作プラグイン llm-typesafe にならい、OpenAI の新しいドキュメントから GPT-6 Astra に書かせた、LLM CLI 向けのプラグイン llm-openai-decisions を公開した。
• API の形は概念的に Jev とよく似ており、質問の種類も同じ 3 つで、Luna には画像入力が加わり、どちらも入力にだけ課金するが、単価は OpenAI が 100 万トークンあたり 10 セント、Jev が 4.2 セントだとみる。

[B] MIXED — OpenAI's Decisions API runs on gpt-6-luna alone, and the model's own endpoint table omits it, by Shane S. Ellison (2026-10-07)

https://mixed-news.com/en/openai-decisions-api-beta-gpt-6-luna-endpoint-table/

• 10-06 の 22:40 UTC に Luna のページのエンドポイントの表を数えると、Chat Completions、Responses、Batch が対応、残る 15 行が非対応で、v1/decisions の行はなかった。
• 10 倍という比較にはベンチマークがなく、score はどのレベルにも当たらない値になりうると指摘する。

[B] The New Stack — Decision models are suddenly everywhere; OpenAI's is now public, by Meredith Shubel (2026-10-07)

https://thenewstack.io/openai-decision-models-deployment/

• OpenAI の発表動画では、Decisions がドライブゲームのフレームから車線変更を選び、GPT-Live と組んで Hugging Face の Microduck ロボットにりんごを追わせ、GPT-Live が話すあいだにアニメのキャラクターの表情を選ぶ。
• OpenAI がモデルをホストされた API の奥に置く一方で、Perplexity (pplx-decider、Apache 2.0、Qwen3.8-27B ベース)、Cloudflare (Clef)、AWS (Strands Decider 2B、Qwen3.5-2B ベース) は重みを公開しているとし、開発者がどのモデルを選ぶかは配備の選択肢で決まるとみる。

[B] The New Stack — AWS, Upstage and Ollama agree on a decision-model API; OpenAI hasn't signed on, by Janakiram MSV (2026-10-09)

https://thenewstack.io/decision-models-system-one/

• TypeSafe の System One のスキーマ (noul、choice、score の質問を持つ /v1/systemone) が共通の契約になりつつあり、Upstage の Solar Decide、Ollama 0.35、AWS の Strands Decider、Kev、Open-Jev がネイティブに対応し、OpenRouter と Perplexity は別のパスで変種を出しているとみる。
• TypeSafe はスキーマの戦いで勝ちつつあるがエンドポイントの戦いはまだ決着していないと結論し、OpenAI が独自のスキーマを持てば、このカテゴリーには競合する 2 つの契約が並ぶとする。
  • 10-07 付けの市場の表は、OpenAI の API をまだスキーマ未公開の限定プレビューとしている。

[B] Classmethod (DevelopersIO) — Trying the OpenAI Decisions API with Japanese text and images, by 山本暁斗 (2026-10-08, in Japanese)

https://dev.classmethod.jp/articles/openai-decisions-api-hands-on/

• 入力の種類と質問の種類の組み合わせごとに 100 件、計 900 件のリクエストで、日本語のテキストは含意の predicate が 93/100、3 分類の choice が 84/100、0〜4 の類似度の score が MAE 0.561 だった。
  • 合成画像は 100/100、98/100、MAE 0.104 で、テキスト付きの実写真は 70/100、有効回答 98 件中 66 件、MAE 0.732 だった。
• 通信を含むレイテンシの中央値はテキストで 209〜218 ms、画像ありで 271〜305 ms で、P95 は最大 1,489 ms、最大値は 4,134 ms だった。
• 900 件で入力 302,146 トークン、出力 0 トークンを使い、定価で約 $0.03 だった。
• 2 件が HTTP 200 のまま refusal の答えを返したので、筆者は別のモデルか人に回すフォールバックが要るとする。
• 確信度が高くても人の評価と合うとは限らず、ある画像の説明文は confidence 0.87 で 3.84 と採点されたが、人の評価を換算すると 1.0 だった。
• 比較表は入力 100 万トークンあたりの単価を Decisions が $0.10、Jev が $0.042、Clef-flash が $0.09、Clef が $0.24 とし、Clef は 1 リクエストあたり画像 4 枚まで、Jev は画像を受け付けないと記す。

[B] Classmethod (DevelopersIO) — Finding OCR errors in Japanese document images, and matching document values against Jev and Clef, by けーま (川田 圭真) (2026-10-11 and 2026-10-12, in Japanese)

https://dev.classmethod.jp/articles/openai-decisions-ocr-verification-ja/ / https://dev.classmethod.jp/articles/openai-decisions-cross-match/

• しきい値 0.8 での 107 件の値の突合で、Decisions は exact では Jev と並んだ (106/107) が、semantic では英語の指示で 90、日本語の指示で 91 と Jev の 96 と 97 (いずれも 106 件中) を下回り、Clef (91 から 76 に低下) と違って日本語の指示でも落ちなかった。
• 実行時間の中央値は 264〜270 ms で、Jev の 686〜709 ms、Clef の 468〜499 ms より短かったが、筆者はその時点のサーバーの混み具合による差とみており、費用は Jev の約 2.3 倍、Clef の約 0.6 倍だった。
• predicate に criteria のフィールドがないので、Jev と Clef に渡していた真と偽の条件を instructions の末尾に足す必要があった。
• 日本語の書類 3 枚では、注入した誤り 36 件中 34 件と、Claude Haiku 4.5 が実際に起こした読み間違い 19 件中 10 件を見つけて Clef (32 件と 7 件) と Clef-flash (29 件と 5 件) を上回ったが、正しい値 503 件のうち 16 件を誤りと判定し、Clef の 7 件より多かった。

[C] Zenn (7shi) — Porting from Jev to the OpenAI Decisions API (2026-10-08, in Japanese)

https://zenn.dev/7shi/scraps/38ded435ab8ceb

• Jev 用の LLM-as-a-Judge のスクリプトの移植では、state の辞書を JSON の文字列にし、名前付きの指示文を 1 つの文字列につなぎ、辞書をリストに組み替え、refusal のときに再試行する必要があった。
• 5,200 件の回答の採点は 1 件あたり約 0.25 秒と Jev の 0.22 秒に近く、費用は Jev の約 1.6 倍 (総額 $0.2814) で、スコアは Jev とよく相関し (r = 0.960)、Jev のような 96〜97 点での頭打ちはなかった。
• 同じ gpt-6-luna を Responses API で推論なし、1 語で答えさせると、判定の 91.4% が Decisions と一致したが、所要時間は 101 分 32 秒と Decisions の 21 分 14 秒の約 4.8 倍で、確率も得られなかった。

[B] Latent Space (AINews) — TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (2026-10-10)

https://www.latent.space/p/ainews-typesafejev-at-100m-arr-75b

• 決定モデルが製品のカテゴリーになりつつあるという節にこの API を置き、Jev をだれもが比べる基準点と呼び、3 種類の質問、画像入力、価格、最大 10 倍速いという OpenAI 自身の数字を裏づける。

[B] laiso — #22 After Jev (2026-10-12, in Japanese)

https://blog.lai.so/2026-10-12/

• 無料部分は Decisions API を、Responses API から独立した専用の経路でマルチモーダルにも対応し、時期からみて明らかに Jev への対抗だと説明しており、残りは有料である。
• 要約では「利用できるモデルや構築ツールは増えたが、どの処理に組み込むと有効かは、まだ試行錯誤」とまとめる。

[C] Hacker News — Decisions API is in public beta (from 2026-10-06, 393 points and 231 comments when fetched on 2026-10-13)

https://news.ycombinator.com/item?id=49984025

• 初期の計測は分かれている: Topfi の 600 回未満の呼び出しのスイートでは p50 346 ms、p95 860 ms、費用は Jev の約 3.1 倍で、失敗した呼び出しが 4 件 (Jev と Mercury Decide は 0 件) あった一方、agentdev001 はエンドツーエンドで 160〜175 ms、p95 285 ms だった。
• simonw は OpenAI のエンドポイントの常として /v1/decisions が事実上の標準になると予想し、ほかの参加者は Structured Outputs に比べて何が増えるのか、ゼロショットのキャリブレーションを信用できるのか、Jev の 2 倍を超える価格、企業は既存の OpenAI の契約を選ぶだろうという点を論じる。

[C] OpenAI Developer Community — Decisions API is now available in Public Beta (2026-10-06 to 2026-10-07)

https://community.openai.com/t/decisions-api-is-now-available-in-public-beta/1403877

• jefff は数百問で試し、微妙な判断では Jev のほうが正確で、Luna は自信のある誤答が約 3 倍多く、多段の利用でのターンの中央値は Jev の 0.3 秒に対して 1.6 秒、費用は Jev の 2〜3 倍だったとする。
• platypus の偏ったコインのテストでは、1,000 回の試行で表の割合が predicate では 70%、choice では 98% になり、選択肢の順序でも確率が動いたので、いまは choice を避けるよう勧める。
  • ほかのメンバーは、Decisions には入力のキャッシュがないこと、3 Mbps の回線で画像入力に約 0.8 秒で答えたこと、10-07 時点で Playground のフィールド名が API と合っていなかったことを付け加える。

メモ

• 画像入力: ガイドはインラインの base64 だけを受け付けてホストされた HTTP(S) の URL を拒むとし、API リファレンスは公開アクセスできる HTTP(S) の URL を受け付けるとしており、どちらも 10-13 に取得したもので、MIXED は 10-07 にガイドの規則を伝えた。
• 速さの主張は言い回しが揺れている: X は Responses API 経由の GPT-6 Luna と比べて最大 10 倍、changelog は Responses API の 10 倍、ガイドは約 10 倍とし、どれもベンチマークがない。
  • 第三者の数字は、テキストで中央値約 210 ms、画像ありで 270〜305 ms (クラスメソッド)、1 判定 0.25 秒に対して同じ Luna の Responses API での 1 語の答えが 1.17 秒 (7shi)、HN での p50 346 ms (Topfi) と 160〜175 ms (agentdev001) である。
  • jefff の 1 ターン 1.6 秒は多段の会話での計測で、10-01 のノートは DevDay で OpenAI が示した 150 ms 対 1.6 秒のグラフを記録している。
• Jev との費用: 定価では Jev の 2.4 倍 ($0.10 対 $0.042) だが、実測の倍率は 1.6 倍 (7shi)、2.3 倍 (クラスメソッド)、2〜3 倍 (jefff)、3.1 倍 (Topfi) と幅があり、トークン化と入力の内訳が効いており、クラスメソッドは日本語のテキストでは定価の差ほど高くならないとみた。
  • キャッシュがないので繰り返す長いプロンプトは満額を払い、Responses API での Luna はキャッシュ済み入力が $0.01 だが、出力と推論のトークンに課金される。
• Jev との精度は結果が割れている: 完全一致では並ぶが意味の一致は少ない (クラスメソッド)、Jev のような頭打ちなしによく一致する (7shi)、微妙な判断では劣る (jefff、Topfi)。
  • Microsoft の Decision-1 の投稿はベンチマークの相手に GPT-6 Luna Decisions を挙げ、ほかの決定モデルを上回ると主張するが、本文にモデルごとの数字はない。
• キャリブレーション: OpenAI はキャリブレーションのデータを出しておらず、AINews は 09-30 にこの API がキャリブレーションの学習を加えていないと書き、フォーラムの利用者の簡単なテストでは choice が確率を一方に寄せて順序にも左右され、クラスメソッドは確信度が高いのに人と食い違う例を見ており、ガイドはラベル付きの例からしきい値を決めよと言うだけである。
• スキーマ: OpenAI の契約 (input、questions の配列、predicate) は、Jev、AWS の Strands Decider、Ollama、Microsoft-Decision-1 が従う System One の契約 (state、質問のマップ、noul、criteria) と違うので、乗り換えにはコードの変更が要る (7shi、クラスメソッド)。
  • The New Stack の 10-09 の記事は、ベータの開始から 3 日たっても OpenAI のスキーマを未公開としている。
• まだ示されていないこと: Decisions 自体のレート制限、1 リクエストあたりの質問数や score のレベル数の上限、一般提供の日付、gpt-6-luna 以外のモデル、Azure や Bedrock がこの API を提供するか (フォーラムで質問されたが回答はない)。
• コンテキスト: Luna のページは 1,050,000 トークンとし、フォーラムの常連は標準のティアは 272K で 1M も使えると説明するが、Decisions のガイドには独自の上限の記載がない。
• AINews は複数のベンダーが同じ日に決定モデルを出したと書くが、その号の対象は 10-08〜10-09 で、OpenAI のベータは 10-06 に始まっている。
• 日本語での取り上げ: クラスメソッドの検証記事 3 本、laiso、検索結果でだけ見た Qiita の記事数本 (読んでいない)。
• ここでの事実はどれも WebFetch だけには頼っていない。

実践やアウトプットの提案

• 10-01 に計画したハーネスを、エンドポイントが開いたいま回す: 社内のラベル付きのルーティングか分類のセット 1 つを、/v1/decisions、enum の Structured Output と推論 none の Responses API の Luna、Jev、Microsoft-Decision-1 に通す。
  • 日本から測った p50 と p95 のレイテンシ、精度、ECE 付きの信頼性図、拒否率、1,000 判断あたりの費用を記録する。
• choice のキャリブレーションの懸念をラベル付きのデータで確かめる: 選択肢の順序を入れ替え、choice の確率と選択肢ごとに 1 つずつ立てた predicate を比べてから、どちらを採るか決める。
• 製品写真の破損の判定や、スクリーンショットから次の UI 操作を選ぶような画像のゲートを試作し、detail の設定を比べ、ガイドに反してホストされた HTTPS の画像の URL が通るかを確かめる。
• System One の形 (state、noul、criteria) から /v1/decisions (input、predicate、choices) への薄いアダプターを書き、真と偽の条件を instructions に移して refusal を扱い、チームがプロバイダーを切り替えられるようにする。
• 日本語のテキストと画像の典型的な入力で実測したトークン数から、100 万トークンあたり $0.10 と $0.042 での費用表を作り、キャッシュ割引がないことと 272K トークン超の 2 倍の単価も入れる。
• アウトプット: ハーネスで測ったレイテンシ、費用、拒否の挙動を添えて、Structured Outputs と並べたときの Decisions の使いどころを社内向けに短くまとめる。

2. ⚖️ Microsoft が、Qwen3.5-9B を追加学習したテキスト専用の決定モデル Microsoft-Decision-1 を Foundry と OpenRouter でパブリックプレビューとして公開し、固定の回答候補それぞれの確率を、Jev と同じ入力 100 万トークンあたり $0.042、出力無料で返す

• 選定 / 影響度 1 / 将来性 2 / 注目度 2 / 起点 10-09、期間前の出来事 / 種別: リリース / 領域: モデル、API・クラウド。
• 候補になったフィード項目:
  • zenn-trending 10-12 Microsoft-Decision-1でAI-OCRの品質ゲートを作ってみた — Zenn 6 いいね、はてなブックマーク 0 users (取得時点)
  • laiso-newsletter 10-12 #22 Jevその後 (判断 API を出すようになったベンダーに Microsoft を数える)
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (LLM の判定役と科学的な仮説のふるい分けに向けたモデルと位置づける) — Microsoft の発表は 10-09 から Hacker News で 199 ポイント、66 コメントを集めた
• 起点: Microsoft は期間の前日の 10-09 に Command Line のブログと Tech Community の Foundry のボードでモデルを発表したが、どちらも microsoft-foundry-blog のフィードの対象外で、今回の実行で ainews、zenn-trending、laiso-newsletter が初めてフィードに運んだ。
• 関連: 2026-09-27 のトピック 2 は Jev を、2026-10-06 のトピック 2 は Clef を扱っており、どちらもこのモデルの比較の相手になる決定モデルである。

収集した情報

[A] Microsoft — Introducing Microsoft-Decision-1, our model for fast decision-making, by Achint Srivastava (2026-10-09)

https://commandline.microsoft.com/microsoft-decision-1-model-foundry/

• Microsoft-Decision-1 は Microsoft Foundry と OpenRouter で使えるルーティング、分類、優先順位付け、検証、ワークフローの制御のためのモデルで、料金は入力 100 万トークンあたり $0.042、出力は無料である。
• Microsoft は Qwen3.5-9B を速い 1 回の推論での判断のスコアリング向けに追加学習し、近いうちに MAI (Microsoft AI) や OpenAI のものを含むほかのモデルをベースに作り直すとする。
• 固定した選択肢を与えるとそれぞれについてキャリブレーションされた確率を返し、yes/no、多肢選択、評価尺度の質問のほか、AI の応答やエージェントの行動をルーブリックで採点する用途にも対応する。
• 学習から切り離した約 15 万問、36 のベンチマークでの Microsoft の比較では精度が最も高く、測った中で最速で、P50 では 2 位の H2O-Lightning-4B v1.1 の 2.5 倍、GPT-6 Sol の 35 倍速かった。
• 付録はベンチマークの相手に Quyet-1.0-Large、Surogate Rune 26B-A4B、GPT-6 Luna Decisions、deck-31B、H2O-Lightning-4B、Strands-Decider 2B を挙げ、投稿は JevBench のリーダーボードから上位の公開モデルをいくつか選んだとする。
• 編集者注は、精度とキャリブレーションのベンチマークに Jev を加えるよう投稿を更新したとし、その数字はグラフにしか出ていない。
• 同じリクエストを 8 通りに揺さぶると判断が反転したのは平均 1.3% で、選択肢の説明の言い換え、選択肢の逆順やシャッフルでは反転しなかった。
• 安全性のテストは、有害な内容、ジェイルブレイクの試み、プロンプトインジェクションの 11 のベンチマークにわたる 5,250 件のリクエストで行った。
• 社内のテスト: Xbox Research は 1 万件を超えるフィードバックを、GPT-6 Sol に引けを取らない品質で 14 倍以上速く、200 分の 1 の費用で仕分け、Copilot チームは応答の採点で GPT-5.6 Luna に匹敵し、100 倍速いとみた。
  • Microsoft Discovery では、ルーブリックの採点が LLM による採点より 46 倍一貫して 3 倍速く、適応的な再計画が 4 倍近く速くなった。
• 想定する用途は、エージェントの制御 (続行、停止、再試行、引き継ぎ)、モデルのルーティング、エージェントスキルのルールを読み直さずに当てはめること、AI による判定、コードのスキャン、コンピューター操作での次の UI 操作の選択、ロボティクスである。

[A] Microsoft Tech Community (Microsoft Foundry Blog) — Introducing Microsoft-Decision-1 in Microsoft Foundry for decision and classification workloads (2026-10-09)

https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/introducing-microsoft-decision-1-in-microsoft-foundry-for-decision-and-classific/4562742

• モデルはパブリックプレビューで、今後の版は OpenAI のモデルと Microsoft の MAI のモデルをベースに作り直すとする。
• 料金表は US Datazone と EU Datazone のどちらのデプロイも入力 100 万トークンあたり $0.042 とし、出力は N/A としている。
• Xbox Research の結果を、Command Line の投稿のような GPT-6 Sol との比較ではなく、GPT-5 に匹敵する品質で 80〜100 倍の速さと伝える。
• あいまいなケースでの精度、想定するトラフィックでのレイテンシ、判断 1 件を終えるまでの費用を比べ、キャリブレーションを自分たちのデータで確かめるよう求める。

[A] Microsoft Learn — Deploy and use Microsoft-Decision-1 in Microsoft Foundry (as fetched on 2026-10-13)

https://learn.microsoft.com/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision

• リクエストは state (テキストか JSON) と、名前をキーにした questions のマップを <foundry-resource-endpoint>/providers/microsoft/v1/systemone に送り、model にはモデル名ではなくデプロイ名を入れる。
  • レスポンスの answers オブジェクトは同じ名前を使い、レスポンスにはトークンの使用量と、microsoft-decision-1 のような実際のモデルを示す model のフィールドも入る。
• 質問の種類は noul (確率を返し、任意で true と false の criteria を持つ)、choice (選択肢の criteria のマップを持ち、選んだものとすべての選択肢の確率を返す)、score (低い順の criteria のリストを持ち、確率で重み付けしたレベルの番号を返す) である。
• バージョン 1 は GlobalStandard か、一部のリージョンでは DataZoneStandard として、ポータルか az cognitiveservices account deployment create --model-name "Microsoft-Decision-1" --model-format Microsoft --model-version "1" でデプロイし、呼び出しには Microsoft Entra ID か api-key のヘッダーを使う。
• 制限として、スコアが質問や選択肢の言い回しと順序で動くこと、キャリブレーションがなじみのある種類のタスクで最も強いこと、モデルが説明を返さないことを挙げる。
  • スコアは絶対的なキャリブレーション済みの評点としてではなく、相対的な順位付けやしきい値に使うよう勧める。
• ベストプラクティスには、cannot tell のような判断保留の選択肢、選択肢の順序のランダム化、偽陽性と偽陰性のコストから決めるしきい値、人に関わる重大な判断での人のレビュー、ラベル付きの例と照らして評価する設定の候補をコーディングエージェントに作らせることが並ぶ。
• トラブルシューティングの表は、サポートされないデプロイ名や質問の定義には 422、デプロイのレート制限を超えたときは 429 を返すとするが、上限の値は書いていない。

[A] Microsoft Foundry — Microsoft-Decision-1 model catalog entry (as fetched on 2026-10-13)

https://ai.azure.com/catalog/models/Microsoft-Decision-1

• エントリーは、バージョン 1、ライフサイクルは Preview、Direct from Azure、入力はテキスト、出力は JSON、コンテキストウィンドウは 32,768 トークンと示す。
• 学習データは、Microsoft の Open Data のプロセスを経た公開データセットと、チームが作った合成データである。
• 対象外の用途として、文章の生成、自由回答の質問応答、会話、翻訳、要約、閉じた質問と決まった選択肢のないタスク、与信、雇用、住宅、保険、教育、医療、法律の問題で唯一の判断者になることを挙げ、画像、音声、動画は受け付けない。

[A] Microsoft Tech Community (Educator Developer Blog) — Not Every Decision Needs an LLM: Getting Started with Microsoft-Decision-1 (2026-10-12)

https://techcommunity.microsoft.com/blog/educatordeveloperblog/not-every-decision-needs-an-llm-getting-started-with-microsoft-decision-1/4563468

• Playground で noul と score の質問を 1 つずつ送ったリクエストは入力 86、出力 2 トークンで約 $0.0000036、つまり 1 ドルで 27 万 5,000 回を超える判断になる。
• 1 つのリクエストの質問は並列に評価されるので質問を足しても応答時間はほとんど変わらず、質問のキーはモデルに見せられず、noul の答えには別の確信度のフィールドがない。

[A] OpenRouter — Microsoft: Microsoft-Decision-1 (as fetched on 2026-10-13)

https://openrouter.ai/microsoft/microsoft-decision-1

• OpenRouter は microsoft/microsoft-decision-1 を 2026 年 10 月 9 日のリリースとし、100 万トークンあたり入力 $0.042、出力 $0、コンテキスト 32,768 トークン、プロバイダー 1 社で載せる。
• チャットのエンドポイントではなく OpenRouter の Decisions API で動くので chat completions の SDK では使えず、ページは 3 日間の P50 レイテンシ 0.29 秒、可用性 99.99% を示した。

[B] The New Stack — Microsoft skipped OpenAI's decision model and built its own on Alibaba's Qwen, by Amanda Caswell (2026-10-10)

https://thenewstack.io/microsoft-decision-model-foundry/

• Microsoft は OpenAI が Decisions API を開いた 3 日後に、パートナーのモデルではなく Qwen3.5-9B で作ったモデルを Jev とまったく同じ価格で出したとし、OpenRouter の Kev-4B は $0.042、Perplexity は $0.02、OpenAI は Jev の 2 倍を超える単価だと並べる。
• Microsoft のより大きな狙いは、判断の前後の生成の呼び出しも含めてエージェントのトラフィックを Foundry にとどめることだと読み、GitHub Copilot がこれから行う端末上とクラウドのモデルの選び分けにこのモデルを使うかは Microsoft が明らかにしていないと記す。
• 入力がテキストだけであること、オープンウェイトの発表がないこと、TypeSafe の System One API と完全に互換だとは述べていないことを指摘するが、Foundry のサンプルコードは /systemone のエンドポイントを呼んでいる。
• JevOut のプレプリントを引き、短く自然な追記によって、Jev がはじめ正しく判断した 508 件のうち 312 件が反転し、うち 229 件は誤った答えに 70% 以上を付け、ほかの 3 つの採点システムも 64.9〜73.2% で反転したとするが、Decision-1 は試されていない。

[B] The Register — Microsoft leans on open weight model from Chinese AI lab to challenge Jev, by Thomas Claburn (2026-10-10)

https://www.theregister.com/a/5302473

• Microsoft のグラフの数字として、レイテンシで H2O-Lightning-4B の 2.5 倍、Jev の 2.8 倍速く、36 のベンチマークでの精度は 83.5% で首位、確信度のスコアは 92.2% で Quyet-1.0-Large に次ぐ 2 位、テキスト分類では GPT-6 Sol より 20 倍以上安いと伝える。
• Snowflake のもの、Liquid AI の d1、Surogate Rune、H2O-Lightning-4B を含む 100 を超える決定モデルの中にこの発表を置き、決定モデルもまだ誤りを犯し、敵対的な入力がそれを大きくしうると記す。

[B] ITmedia AI+ — Microsoft also launches Microsoft-Decision-1, a decision-specialised AI model built on Qwen and priced like Jev (2026-10-12, in Japanese)

https://www.itmedia.co.jp/aiplus/article/2610/12/2000002194/

• Microsoft の比較表を説明して、Decision-1 は正答率と応答速度では首位だが、「キャリブレーションでは『Jev』などに次ぐ3位だった」と書く。
• Microsoft が公開後に Jev との正答率とキャリブレーションの比較を加えたことを伝え、コンテキスト長 32,768 トークンでテキストだけを扱うモデルが Foundry と OpenRouter の両方で提供されているとする。

[C] Zenn (Headwaters, takekawa tomoki) — Building a quality gate for AI-OCR with Microsoft-Decision-1 (2026-10-12, in Japanese)

https://zenn.dev/headwaters/articles/6e889f79ee9f2e

• ゲートは Document Intelligence の OCR の Markdown を state として渡し、1 リクエストで 2 つの質問、low_quality という名前の noul と、問題なしの選択肢を含む main_issue という名前の choice を投げ、0.5 以上の文書は GPT-5-mini が項目を抽出する前に人の確認に回す。
• ダミーの請求書 11 枚でゲートは 10 枚を正しく判定し、0.07 と採点されたかすれた FAX だけを見逃し、4 枚を LLM に渡さずに済ませた。
• レイテンシの中央値は Decision-1 が 395 ms、GPT-5-mini が 3,312 ms で、Decision-1 の最初の数件は 700〜1,000 ms、後半は 300 ms 前後だった。
• 専用の SDK がまだないので、筆者は httpx でエンドポイントに直接 POST し、answers.low_quality.noul と answers.main_issue.choice を読み、429 は retry-after だけ待ってから再試行する。

[C] TestingCatalog — Microsoft launches Decision-1 model in Foundry (2026-10-09)

https://www.testingcatalog.com/microsoft-launches-decision-1-model-in-foundry/

• 発表当日の記事は速さの優位を 2 位の Quyet-1.0-Large の 4.5 倍としており、いまの投稿の H2O-Lightning-4B v1.1 の 2.5 倍とは違う。
• Foundry のカタログが一般提供を示しているとし、OpenRouter への対応はこれからだとした。

[B] Latent Space (AINews) — TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (2026-10-10)

https://www.latent.space/p/ainews-typesafejev-at-100m-arr-75b

• Microsoft-Decision-1 を LLM の判定役と科学的な仮説のふるい分けに向けたものと位置づけ、初期に評価した @omarsar0 の、決定モデルはまだ一貫性と複雑な判断に弱いという見方を伝える。

[B] laiso — #22 After Jev (2026-10-12, in Japanese)

https://blog.lai.so/2026-10-12/

• OpenAI、Cloudflare とともに Microsoft を、判断 API を出すようになったベンダーに数え、ベースのモデルも Qwen 系だけでなく Liquid の LFM 系や BERT 系に広がっていると記す。

[C] Hacker News — Microsoft-Decision-1, our model for fast decision-making (from 2026-10-09, 199 points and 66 comments when fetched on 2026-10-13)

https://news.ycombinator.com/item?id=50024913

• Topfi の小さなスイートでは費用は Jev の 0.72 倍で結果は同程度だが、p50 のレイテンシは Jev の 283 ms に対して 369 ms と遅く、彼は試した Jev の対抗モデルの中で商用で出す意味のある最初のものだと評した。
• コメントは Clef や Strands Decider と同じく Qwen をベースにしている点に触れ (別のコメントは 2B から 26B までの Gemma4 ベースの Strands Decider を告知)、価格に競争力があるかで議論になったが Jev と同じだと指摘され、デプロイしたある利用者は Learn のページが出るまで API の形がわからなかったという。

メモ

• 投稿の更新でベンチマークの数字が変わった。
  • 10-09 の TestingCatalog と 10-10 の Business+IT は Quyet-1.0-Large の 4.5 倍とし、いまの投稿、The Register、ITmedia は H2O-Lightning-4B v1.1 の 2.5 倍とするが、編集者注は Jev を加えたことにしか触れていない。
  • キャリブレーションでは、The Register は 92.2% で Quyet-1.0-Large に次ぐ 2 位とし、Jev を加えた更新のあとに書いた ITmedia は Jev ともう 1 つのモデルに次ぐ 3 位としており、投稿の本文には精度とキャリブレーションの数字がない。
• Jev とのレイテンシ: Microsoft のグラフでは Jev の 2.8 倍速い (The Register) が、Topfi の計測では Jev の 283 ms に対して 369 ms で、日本のチームは中央値 395 ms を測り (Zenn)、OpenRouter は P50 0.29 秒を示した。
• 2 つの Microsoft の投稿は Xbox Research について食い違う: GPT-6 Sol に匹敵して 14 倍以上速く費用は 200 分の 1 (Command Line) か、GPT-5 に匹敵して 80〜100 倍の速さ (Tech Community) か。
• 提供の段階: Tech Community の投稿はパブリックプレビュー、カタログは Preview とするのに対し、TestingCatalog はカタログを一般提供と読んだ。
• 提供先: OpenRouter は 10-09 のリリースとし、ITmedia もそこで使えると伝えており (The Register と TestingCatalog は近く対応するとしていた)、モデルは Foundry に限られない。
• Microsoft 自身の文書がキャリブレーションの主張を弱めている: Learn のページはキャリブレーションがなじみのあるタスクで最も強く、言い回しと選択肢の順序でスコアが動き、スコアは絶対的な評点より相対的な順位付けに向くとするが、発表は選択肢を並べ替えても反転しなかったとする。
  • JevOut のような敵対的な入力への頑健性は、このモデルでは試されていない。
• API の契約: リクエストは System One の形 (state、質問のマップ、noul、choice、score、criteria) に従うが、Microsoft 独自のパスで Azure の認証を使い、model にデプロイ名を入れ、OpenRouter は自前の Decisions API で提供する。
  • Microsoft は OpenAI のモデルをベースに作り直す計画だが、OpenAI の /v1/decisions のスキーマとは違い、TypeSafe の SDK との互換もうたっていない。
• リージョン: 料金表は米国と EU のデータゾーンしか挙げず、Learn のページは GlobalStandard がどのリージョンでもリクエストを処理しうるのでレイテンシが高くなったりばらついたりすると警告しており、日本のチームには効いてくる。
• MAI と OpenAI のモデルへの作り直しは、一方の投稿では近いうち、もう一方では今後の版とされ、日付も答えがどう変わるかも示されていないので、デプロイはバージョン 1 に固定しておくのがよい。
• 出力トークン: 教育者向けの投稿のリクエストは無料の出力トークンを 2 つ使ったが、OpenAI の Decisions API は 0 と報告する。
• 未確認: HN のコメントは、昨年買収したスタートアップ Pi Labs の IP がモデルの開発に役立ったとし、Learn のページの例のデプロイ名 pi-decision-1 もそれに合うが、Microsoft の情報源はどれも裏づけていない。
• 未確認: @omarsar0 の評価は AINews の要約でしか知らず、X の投稿は開いていない。
• WebFetch だけに頼るもの: Business+IT の 10-10 の記事 (https://www.sbbit.jp/article/cont1/187397、保存できなかった) で、見える部分は Quyet-1.0-Large の 4.5 倍という数字を示し、分析は会員限定である。
• Tech Community の 2 つの投稿はクライアント側で描画されるので、本文は全文を載せたブログの RSS フィードから読んだ。
• 日本での注目: ITmedia AI+ と Business+IT が発表を伝え、Zenn の検証記事は取得時点で 6 いいねだった。

実践やアウトプットの提案

• ラベル付きのルーティングか分類のセット 1 つを、Foundry (GlobalStandard) と OpenRouter の Decision-1、Jev、OpenAI の /v1/decisions に通し、日本から測った p50 と p95 のレイテンシ、精度、キャリブレーション (ECE 付きの信頼性図)、1,000 判断あたりの費用を記録する。
  • Jev の 2.8 倍速いという Microsoft のグラフを、Topfi の 369 ms と 283 ms に照らして確かめられる。
• 既存の Jev (System One) のクライアントを api-key とデプロイ名で Foundry のパスに向け、契約を持ち運べるとみなす前に、何が壊れるか (認証、レスポンスのフィールド、上限) を洗い出す。
• 各リクエストを選択肢のシャッフル、逆順、説明の言い換えで再実行して 1.3% の反転という主張を確かめ、ユーザーの文章を読むゲートには JevOut 風の誤誘導の文脈をいくつか加える。
• Zenn の OCR のゲートをラベル付きの社内のスキャン文書で再現し、読めない文書が LLM に届かないようにしきい値を調整し、Decision-1 はテキストしか受け付けないので、ページの画像を直接読む OpenAI の Decisions API とも比べる。
• Azure だけで完結する環境でのツール呼び出しのゲートには、データゾーンで Entra ID 認証のガードとして Decision-1 を試し、プレビューであることと予定された作り直しを設計の記録に残す。
• アウトプット: Jev、OpenAI Decisions、Microsoft-Decision-1、Clef、Strands Decider を、API の契約、モダリティ、コンテキストウィンドウ、価格、データの所在、日本から測ったレイテンシで並べた比較表。

3. 🗃️ SQLite の開発チームが、IVF のインデックス、PQ か OPQ の量子化、インデックス内でのメタデータの絞り込みを依存のない 1 つの C ファイルに収めた自前の近似最近傍のベクトル検索拡張 vec1 を SQLite のソースツリーに移し、バージョン 0.8 が 3.54.0 のソースに、amalgamation の外で別にビルドするローダブル拡張として入った

• 選定 / 影響度 1 / 将来性 2 / 注目度 2 / 起点 09-30、期間前の出来事 / 種別: リリース / 領域: エージェント開発。
• 候補になったフィード項目:
  • zenn-trending 10-11 SQLite 本体にベクトル検索拡張 vec1 がやってきた — Zenn 109 いいね、はてなブックマーク 236 users (取得時点)
• 起点: vec1 は 09-30 にブランチで SQLite のソースツリーに取り込まれ、10-01 に trunk にマージされ、10-09 の version-3.54.0 のタグには 0.8 として入っているが、この移動を告げる発表はなく、今回の実行では 10-11 の mattn の記事が初めてフィードに運んだ。
• 対象範囲とした理由: SQLite の開発者自身によるベクトルインデックスは、sqlite-vec のようなサードパーティの拡張なしに、ローカル、組み込み、端末上の RAG でどのストアを検索に使えるかを変える。

収集した情報

[A] SQLite — Vec1 Vector Extension (2026-10-01)

https://sqlite.org/vec1.html

• vec1 は SQLite の仮想テーブルのインターフェースで近似最近傍 (ANN) の検索を提供し、距離はユークリッド (L2) とコサインで、外部依存のないポータブルな C で書かれ、x86 では AVX2、ARM では NEON を使う。
• インデックスは OPQ (optimized product quantization) を使う IVFADC (inverted file with asymmetric distance computation) で、拡張全体が vec1.c の 1 ファイルに収まる。
• このページはいまでは SQLite の本体のドキュメントの中にあり、最終更新は後述の trunk へのチェックインと同じ分の 2026-10-01 11:21:38Z で、現在のリリースをバージョン 0.8 とし、SQLite のソースツリーの ext/vec1/vec1.c にリンクしている。
• 完全な SQLite のソースツリーの最上位で ./configure && make vec1.so (macOS では vec1.dylib)、Windows では nmake /F Makefile.msc vec1.dll でビルドでき、どちらも実行時に CPU に合わせて AVX2 かスカラーのコードを選ぶ 1 つのバイナリになる。
  • cc -g -O3 -DNDEBUG -mavx2 -mfma vec1.c -shared -fPIC -o vec1.so のように手でビルドすると、AVX2 のバイナリは AVX2 のない x86-64 の CPU では動かず、ext/vec1/Makefile の vec1multi.so のターゲットが複数の x86-64 のレベルに対応する。
• ロードマップは日付なしで、テストと最適化の追加、IVFADC に代わるグラフベースのインデックス (HNSW か DiskANN か、その変種かと疑問形で挙げる)、速い SELECT count(*)、wasm での SIMD、float32 に加えて int8、int32、float16 の要素、パーティションキー、浮動小数点のバイト順が違うプラットフォームのデータベース、距離としての内積、マルチスレッドのクエリを挙げる。

[A] SQLite — Vec1 User Manual and Vec1 Reference Guide (2026-10-01)

https://sqlite.org/vec1doc.html / https://sqlite.org/vec1ref.html

• CREATE VIRTUAL TABLE t USING vec1(vector, meta1, ...) は 1 つのベクトル列と 0〜255 個の型のないメタデータ列を宣言し、クエリはテーブルを表値関数として SELECT rowid FROM t(:v, '{K:10}') のように使い、隠し列 distance を持つ。
• ベクトルはマシンのバイト順の 32 ビット IEEE 浮動小数点数の BLOB で、有限の値だけを受け付け、vec1_from_json() と vec1_to_json() が JSON の配列と変換し、次元は最初の挿入かモデルで決まる。
• モードは 3 つあり、インデックスなし (既定で、1 行に 1 ベクトル)、flat (ベクトルを大きな BLOB に詰め、全件探索が 2 倍以上速い)、学習済みのモデルが要る ANN である。
  • マニュアルは、厳密な結果が要るとき、約 5,000 ベクトル未満のとき、学習データがないか用意しにくいときは厳密 (NN) モードを勧める。
• ANN のモデルは学習用のセットに対する集約関数 vec1_train(vector, '{nbucket:1024, quantizer:"opq", codesize:32, distance:"cos"}') が返す BLOB で、INSERT INTO t(cmd, arg) VALUES('rebuild', :model) がそれを入れてインデックスを作り直し、これはデータに応じていつでも何度でも行える。
  • 学習と再構築は vec1_config('nthread', N) で複数のスレッドを使い、あるホストで学習したモデルは浮動小数点のバイト順が同じ別のホストでも使える。
• 推奨の設定: nbucket は想定行数の平方根程度 (1,000,000 ベクトルなら 1,000)、quantizer はニューラルネットワークの埋め込みには "opq"、SIFT のような人手で設計した記述子には "pq" とし、"bq" (二値で、既定ではランダム化した Walsh-Hadamard 変換が付く) は学習時間を最小にしたいときだけ使う。
  • codesize は OPQ なら 32 バイト (再現率が低すぎれば 48 か 64)、PQ と BQ なら次元数の 1/8〜1/16 で、学習用のサンプルは 100 × nbucket ベクトル程度でたいてい足りる。
• nprobe はクエリが走査するバケットの割合で、1.0 未満なら割合、1.0 以上ならバケットの数を表し、クエリごとか接続ごとに vec1_config('nprobe', ...) で設定でき、既定は 0.05 である。
• ANN の距離は圧縮したコードの上で計算され、vec1 は自動では再ランキングしないので、マニュアルは約 100 件の候補を取り出し、LIMIT 10 の前に vec1_l2_distance() か vec1_cos_distance() で SQL の中で並べ直すよう求める。
  • マニュアルは、vec1 の ANN のクエリでは再ランキングがたいてい欠かせないと念を押している。
• 絞り込みの仕組みは 2 つある: streaming:1 は SQLite が求める限り K を超えておおむね距離の昇順で行を返し続け (結合したテーブルにあるメタデータ向け)、メタデータ列への <、>、=、>=、<=、IS、IS NULL、IS NOT NULL の制約は、上位 K 件を集める前に ANN の探索の中で適用される。
• WHERE in_stock AND price < 20000 の in_stock のような比較演算子のない項は取り出したあとに適用されて黙って K 件より少なくなるので、マニュアルは in_stock = 1 と書き、結合、集約、ORDER BY がなく WHERE のすべての項が探索の中で適用されるクエリなら、見える LIMIT が K の代わりになる。
• 上限: K は 0〜33,554,432 (2^25)、nbucket は 2〜65,536 (0 で転置ファイルを無効化)、codesize は 0〜256 バイト (目安) で、vec1_l2_distance() はユークリッド距離の 2 乗を返し、vec1_cos_distance() は正規化していない入力でも 0.0〜2.0 を返す。

[A] SQLite — Vec1 Tests on Publicly Available Data (2026-10-01)

https://sqlite.org/vec1bench.html

• 4 つの公開データセット (sift 128 次元、imagenet-clip 512 次元、コサインの landmark-dino 768 次元、agnews-mxbai 1024 次元) の学習と構築は AMD 5950X の Linux ワークステーションで 16 スレッドを使って行い、スループットはシングルスレッドで測っており、どの実行もバージョン 0.7 と記されている。
• RAG のコーパスに最も近い、769,382 件のテキスト埋め込みからなる agnews-mxbai-1024-euclidean は {nbucket:1024, quantizer:"opq", codesize:32, residual:0} で、10 万件のサンプルでの学習に 25.9 秒、構築に 4.75 秒かかった。
• このデータで上位 10 件だけを求めると nprobe 16〜64 で recall@10 は 0.618〜0.626 にとどまるが、K=100 で取って再ランキングすると 0.930 (nprobe 16、毎秒 2,251 クエリ) から 0.961 (nprobe 64、毎秒 1,290) になり、nprobe 64 で K=300 なら毎秒 883 で 0.983 に届く。
• これらの実行の nprobe は 1,024 バケットのうち 16〜64 という絶対数 (1.6〜6.25%) で、既定の 0.05 なら約 51 を走査する。

[A] SQLite source tree — check-ins 3a0876d973 and 92709f54d4, main.mk, later ext/vec1 commits and release 3.54.0 (2026-09-30 to 2026-10-10)

https://sqlite.org/src/info/3a0876d973868be7 / https://sqlite.org/src/info/92709f54d4 / https://github.com/sqlite/sqlite/commit/e32fbe0c230c60b77e42672d17520030ff85446f / https://sqlite.org/releaselog/3_54_0.html

• Dan Kennedy は 2026-09-30 14:49 UTC に vec1 のソースを vec1 ブランチの ext/vec1/ に取り込み (チェックイン 3a0876d973)、同じ日にそこで MSVC と Windows のテストの問題を直し、2026-10-01 11:21 UTC に 92709f54d4 として trunk にマージした。
• 取り込みは 65 ファイル (うち 57 が新規) を変えて 21,637 行を加えており、その内訳は 12,938 行の vec1.c、6,756 行の 50 のテストファイル、VIBE のデータセット向けの vec1bench.tcl や vec1bench_vibe2db.py といったベンチマークのツールである。
  • 取り込んだ時点の vec1.c は、まだ VEC1_VERSION "0.7" を定義していた。
• main.mk はこのターゲットを、amalgamation にもどの配布パッケージにも含まれず、明示的に make vec1.so を実行したときだけビルドされるものと説明する。
  • configure がコンパイラは -mavx2 -mfma を受け付けると判断すると、vec1.c はスカラーと AVX2 の 2 回コンパイルされて実行時に選ぶ 1 つの拡張になり、既定の最適化は -O3 である。
• その後の ext/vec1 へのコミットは、10-06 に vec1_info() が返す文字列を "0.8" に上げ、10-07 には、ユーザーが渡した引数から組み立てた SQL 文を準備して実行することがあるため vec1_train() を SQLITE_DIRECTONLY にした。
  • あわせて、xSavepoint の無限再帰 (10-06)、壊れたメタデータの配列の扱い (10-09)、削除を失敗させうる丸め誤差 (10-10) を直した。
• 2026-10-09 の version-3.54.0 のタグには、VEC1_VERSION "0.8" の ext/vec1/vec1.c が 2026-02-04 付けの SQLite のパブリックドメインの宣言とともに入っているが、3.54.0 のリリースノートは vec1 に触れていない。

[A] SQLite — the standalone vec1 repository's page and timeline (as fetched on 2026-10-13)

https://sqlite.org/vec1/doc/trunk/doc/vec1.md / https://sqlite.org/vec1/timeline?n=200&a=2026-08-01&y=ci

• https://sqlite.org/vec1 がいまも返すページは現在のリリースをバージョン 0.7 とし、このリポジトリの最後のチェックインは取り込みの前日の 2026-09-29 である。
• そのロードマップは、1.0 のリリースまでに要る機能はもうないとしつつ、テストが不十分だという注意を 1 つだけ付けている。
  • 1.0 以降の案として、学習を要さずに IVFADC の利点を保つインデックスも挙げ、RaBitQ か TurboQuant での量子化を候補にしているが、新しいページにはもう書かれていない。
• 08-05〜08-27 の 37 のチェックインは、08-04 (1 件)、08-05 (8 件)、08-19 (28 件) に出たバグ報告に応えて、クラッシュ、インデックスの破損、行を落としたり重複させたりするストリーミングのクエリ、入力の検証を直している。
  • 例として、挿入したベクトルがどのセントロイドからも極端に遠いときのクラッシュ、32 ビットの整数のオーバーフローによる壊れたレコードでのクラッシュ、vec1_from_json(NULL) のクラッシュ、インデックスかメタデータの BLOB が SQLITE_LIMIT_LENGTH を超えたときの黙ったインデックスの破損がある。
• 9 月のチェックインはおもに AVX2 と NEON での高速化で、転置したコードブックや、学習、再構築、内積のための複数のアキュムレーターなどがある。

[A] SQLite User Forum — "Vec1 version 0.7.", by Dan Kennedy, with a reply by Richard Hipp (2026-07-07, background)

https://sqlite.org/forum/info/a09b103d9d41ed25a357a42aa22ca32a93d4a5fb9b10eb40ab3e14cde508e8f1?t=c

• Dan Kennedy は 0.7 を、まだ 1.0 ではないがもうプレビューでもないと位置づけ、学習の要らない RaBitQ の量子化器を加えたが、学習した PQ や OPQ には及ばないと述べた。
• 学習できる静的なデータセットや、学習に使える代表的なサンプルがあるデータなら、vec1 はたいていの ANN のベクトル検索の実装とおおむね競える水準にあると主張した。
• 次の重点は学習のまったく要らないモードで、書き込みが遅くなる代わりに、オンラインで書き込めてインデックスがつねに検索できるようにするとした。
• 08-02 に Richard Hipp は、後述のメモリ安全性の報告に応えて Vec1 Forum の匿名アクセスと自己登録を有効にし、vec1 の問題はそこに報告するよう求めた。

[A] APSW — Change History and SQLite extra, by Roger Binns (as fetched on 2026-10-13)

https://rogerbinns.github.io/apsw/changes.html / https://rogerbinns.github.io/apsw/extra.html

• 3.52.0.0 以降、Python の SQLite のラッパー APSW の PyPI のフルビルドは SQLite の追加の拡張を同梱しており、その中に実験的で開発中と記された vec1 があり、apsw.sqlite_extra.load(db, "vec1") でコンパイラなしに読み込める。
• extras のページはリファレンスにない vec1_to_json_f、vec1_to_json_i、テーブル vec1cat を挙げ、vec1.c は vec1cat を database、name、model、qprofile の列を持つカタログとして定義している。

[A] ncruces/go-sqlite3 — Release v0.34.0 and later release notes (2026-04-23 to 2026-09-23)

https://github.com/ncruces/go-sqlite3/releases/tag/v0.34.0 / https://github.com/ncruces/go-sqlite3

• SQLite を Wasm 向けにビルドして wasm2go で Go に変換する cgo なしのこの Go のドライバーは、v0.34.0 (2026-04-23) から vec1 をパッケージ github.com/ncruces/go-sqlite3/ext/vec1 として提供し、接続ごとに vec1.Register(conn) で有効にする。
• v0.34.4 (06-04) で Vec1 0.6 に、v0.35.2 (07-06) で 0.7 に上げ、最新の v0.35.6 (09-23) は 0.8 より前のものである。

[A] Alex Garcia — sqlite-vec README, vec0 documentation and releases v0.1.7 to v0.1.10-alpha.4 (2026-03-17 to 2026-05-18)

https://github.com/asg017/sqlite-vec / https://alexgarcia.xyz/sqlite-vec/features/vec0.html / https://github.com/asg017/sqlite-vec/releases/tag/v0.1.10-alpha.1

• sqlite-vec は float、int8、二値のベクトルを vec0 の仮想テーブルに格納して MATCH と k = ... で検索し、純粋な C で書かれ、WASM でブラウザでも動く。
• vec0 は最大 16 の厳密に型付けしたメタデータ列 (=、!=、>、>=、<、<=) で絞り込み、最大 4 つのパーティションキーの列でシャーディングし (キーの値ごとに数百のベクトルがある場合だけ勧められる)、インデックスしない + の補助列を結合なしで返す。
• v0.1.7 (2026-03-17) は Mozilla の支援で長い休止からプロジェクトを再開し、古い Go と ncruces のバインディングの一部は休止したとした。
  • ANN のインデックス (rescore、実験的で有効になっていない IVF、DiskANN) は、最後の安定版である同じ日の v0.1.9 のあと、2026-03-31 からの v0.1.10 のアルファでようやく入り、最新のアルファ v0.1.10-alpha.4 (2026-05-18) がリポジトリへの最後の push でもある。

[C] Zenn (mattn) — vec1, a vector search extension, arrives in SQLite itself (2026-10-11, in Japanese)

https://zenn.dev/mattn/articles/6e9996319ac099

• Go のドライバー go-sqlite3 のメンテナーの mattn は、ソースツリーから ./configure と make sqlite3 vec1.so で vec1 をビルドし、SELECT vec1_info(); は version 0.8 (AVX2, multi-threaded) を返した。
• いちばんの利点は普通の SQL として使え、結果を元のテーブルと結合したり WHERE で絞り込んだりできることだとし、返る L2 の距離は 2 乗だと指摘する。
• Go からは sql.Register("sqlite3_vec1", &sqlite3.SQLiteDriver{Extensions: []string{"/path/to/vec1"}}) で自分のドライバーに読み込む。
• デモの yomivec は言語モデルを使わずに日本語の単語を音の近さで引く: IPAdic の約 22 万語を、ローマ字にした音のキーの 2〜3 文字の断片をハッシュした 256 次元のベクトルにし、学習も量子化もない flat のインデックスでコサインで検索し、取り込みは約 2 秒で終わる。
  • バナーナでバナナが、coffee でコーヒーと珈琲が引けるが、音では意味を区別できないので、実用では埋め込みのベクトルと組み合わせることになるとする。
• vec1 が 1.0 前で amalgamation に含まれず、テストが不十分とされていることから「実運用に投入するのはもう少し様子を見た方が良さそうです」と書き、公式のベクトル検索が入れば、スマートフォン、ブラウザ、デスクトップのアプリが外部のサービスや専用のデータベースなしに意味の近い文書を探せるようになると期待する。

[C] SQLite User Forum — replies to "Vec1 version 0.7." by Lee Butterman and Nuno Cruces (2026-08-02 to 2026-10-12)

https://sqlite.org/forum/info/a09b103d9d41ed25a357a42aa22ca32a93d4a5fb9b10eb40ab3e14cde508e8f1?t=c

• 08-02 に Lee Butterman は、コーディングエージェントを使った red-green の TDD で多数のメモリ安全性のバグが見つかり、そのうち半ダースを超えるものは SQL から直接たどれると報告し、どこに報告すべきかを尋ねた。
• 10-11 に、自分の Go のドライバー向けに vec1 をシングルスレッドの Wasm にコンパイルしている Nuno Cruces は、3.54.0 の一部として 0.8 が本体のリポジトリに入ったことを歓迎して告知を求め、この版はパッチを当てないと VEC1_THREADS=0 でコンパイルできない (vec1KMeansInitOne の不完全な構造体) と報告した。
• また、SIMDe で NEON のコードを Wasm の SIMD128 に変換すると、vec1 が Wasm の組み込み関数を持つまでのあいだ明らかに速くなるとし、10-12 にそのラッパー (#define VEC1_HAVE_NEON 1、#define VEC1_SIMD_WIDTH 4、clang -msimd128) を投稿した。

[C] SQLite User Forum — vec1-related feedback, by punkish, with replies by Roger Binns and Dan Kennedy (2026-03-19, background)

https://sqlite.org/forum/info/3b73af13a1c4b36929f5413246faa68e2d0968cb8f64db229e14558ded9c9bed

• 110 万本の論文からの約 340 万の 1 KB のチャンクを 768 次元の nomic-embed-text のベクトルにした RAG の作り手は、コンパイルが要るので vec1 を試せず、sqlite-vec のフォークはメンテナーが警告したとおり約 10 万ベクトルを超えると動かなくなったと報告し、FTS5 での事前の絞り込み、約 500 本の論文へのコサイン、上位 8 件をローカルの LLM に送る構成に戻して数百ミリ秒で答えている。
• 彼は FTS5 と同じくらい一級の扱いのベクトル検索を望み、Roger Binns は APSW の wheel にある vec1 のバイナリを紹介しつつ、オンラインのサービスか 0.5 GB ほどのモデルでベクトルを作ることこそが本当の障害で、FTS5 を使う場合と比べて Lite とは言いにくいと論じた。

[C] Hatena Bookmark — comments on mattn's article (2026-10-11 to 2026-10-12, in Japanese)

https://b.hatena.ne.jp/entry/s/zenn.dev/mattn/articles/6e9996319ac099

• 10-13 に読んだ時点で 236 users、21 コメントで、自己完結のローカルの RAG や簡易な RAG に役立つと期待する声がいくつかあり、SQLite でローカルの RAG を作っている利用者は試してみるとし、別の利用者は文脈的な距離を見ているわけではなく、ネイティブのベクトル型より遅いだろうから小規模な RAG 向けだとみる。
• ほかに、pgvector のような次元数の制限はないが、ベクトルはただの BLOB なので halfvec のような 16 ビットの型もないこと、日本語の埋め込みには multilingual-e5 のような多言語モデルがよいこと、すでにベクトル検索を持つ DuckDB に SQLite が追従したのかという疑問が挙がる。

[C] Hacker News — Vec1: Native vector search (ANN) in SQLite (2026-10-10)

https://news.ycombinator.com/item?id=50030011

• 5 ポイントで、動画へのリンクのコメントが 1 つだけで、以前のドキュメントの投稿 (04-23 に 5 ポイント、04-24 に 3) や 0.7 の投稿 (07-07 に 3) もそれ以上は伸びておらず、2024 年の sqlite-vec のリポジトリの投稿の 314 ポイントとは対照的である。

メモ

• 2 つのドキュメントのサイトでバージョンが食い違う。
  • sqlite.org/vec1.html (10-01) は、10-06 まで 0.7 を名乗っていたコードを 0.8 とし、sqlite.org/vec1 とそのベンチマークのページはいまも 0.7 とする。
  • 新しいロードマップは、1.0 までに要る機能はもうないという旧版の一文を削り、テストの充実を最初に置き、1.0 の日付を示さない。
  • 移動に告知はなく、3.54.0 のリリースノートは何も触れず、Nuno Cruces が 10-11 に告知を求めた。
• 3.54.0 に入ったといってもソースツリーの話である: 3.54.0 のタグは 0.8 の ext/vec1/ を含むが、main.mk は amalgamation とすべての配布パッケージから外している。
  • したがって、システム、プラットフォーム、言語に同梱された SQLite を使うアプリケーションには、別にビルドした vec1.so と、拡張の読み込みを許す SQLite が要るが、どのプラットフォームが許すかは確かめていない。
  • 見つかったビルド済みの入手経路は APSW の PyPI の wheel (Python) と ncruces/go-sqlite3 (Go、0.7) で、APSW 3.54.0.0 (10-12) が 0.8 を同梱しているかは確かめていない。
• ローカルの RAG で効いてくる sqlite-vec との違い:
  • インデックス: vec1 には文書化された ANN の経路 (PQ、OPQ、二値のコードによる IVF) と厳密な flat の探索があり、sqlite-vec の安定版には ANN がなく、rescore、IVF、DiskANN のインデックスは 05-18 以降リリースのないアルファにある。
  • 絞り込み: どちらもメタデータの制約を探索の中で適用し (vec1 は != なしで型のない列を 255 まで、sqlite-vec は型付きの列を 16 まで)、vec1 には結合したテーブル向けのストリーミングがあり、パーティションキー (sqlite-vec のドキュメントの例ではユーザーごとにシャーディング) は sqlite-vec にしかなく、vec1 はロードマップに載せている。
  • 要素の型: vec1 は float32 だけを格納してインデックスの中で圧縮し、sqlite-vec は int8 と二値のベクトルも格納する。
  • 距離: vec1 は L2 とコサインだけで内積がないが、情報源の主張ではなく推論として言えば、正規化した埋め込みならコサインは内積と同じ順位になるので、この差が効くのはおもに正規化していない埋め込みである。
  • ブラウザ: sqlite-vec はいま WASM で動き、vec1 も Nuno Cruces のようにシングルスレッドで Wasm にコンパイルできるが、Wasm の SIMD はまだなく、彼の SIMDe の経路はつなぎである。
• 増え続ける RAG のコーパスでは学習がおもな運用のコストになる: ANN のモデルには代表的なサンプル (100 × nbucket ベクトル程度) が要り、データの分布がずれたら学習し直して rebuild する必要がある。
  • Dan Kennedy は 7 月に学習の要らないオンラインのモードを次の重点としたが、10-01 のロードマップはグラフベースのインデックスしか挙げず、それで学習が要らなくなるのかは書いていない。
  • 0.7 の投稿の RaBitQ の量子化器はドキュメントにその名前では出てこず、載っているのはランダム化した Walsh-Hadamard 変換付きの二値の量子化 "bq" だけなので、"bq" がその量子化器かは確かめられていない。
• 再現率は再ランキングしだいである: agnews では、圧縮した距離での上位 10 件に本当の上位 10 件の約 62% しか入らないので、検索側は約 100 件の候補を取って SQL の中で並べ直す必要があり、マニュアルはそれを利用者に任せている。
• フットプリントは文書化されていない: ベクトルあたりのディスクやメモリを示す情報源はなく、情報源の主張ではなく推論として言えば、再ランキングは格納した vector の列を読むので、テーブルはコードと並べて元のベクトルも持っているとみられる。
• 頑健性: 8 月の記録はテストが不十分だという以前の注意を裏づけ、壊れたメタデータの配列や丸め誤差の修正は 10 月にも続いた。
  • 8 月の報告を誰が出したかは vec1 のフォーラムにログインしないと見えないので、Lee Butterman がエージェントで見つけたバグと結びつける根拠は時期の一致だけである。
  • SQL からたどれるメモリ安全性のバグが半ダースを超えるという数は Lee Butterman の主張で、裏づける情報源はない。
  • SQLite の関数フラグによれば、SQLITE_DIRECTONLY は関数を最上位の SQL からだけ実行できるようにしてビュー、トリガー、スキーマからは実行させないので、関数を呼ぶようにスキーマを書き換えたデータベースファイルへの守りになる。
• mattn はファイルのヘッダーから開発の始まりを 1 月ごろとみているが、ヘッダーの日付は 2026-02-04 で、Dan Kennedy の vec1 についての最初のフォーラムの投稿は 2026-02-26 である。
• 規模の目安として、agnews の実行はデスクトップの CPU の 1 スレッドで、1024 次元の 77 万ベクトルに対し再ランキング込みで毎秒約 1,300〜2,250 クエリ、再現率 0.93〜0.96 を出しており、3 月のフォーラムの利用者が sqlite-vec のフォークが動かなくなったという 10 万ベクトルを大きく超える。
• Simon Willison (サイト内検索で vec1 は何も出ない) や Alex Garcia の記事は見つからず、英語圏の議論は SQLite のフォーラムと、5 ポイント以下の Hacker News の投稿に限られる。
  • 注目度を支えているのは日本の場で、10-13 時点ではてなブックマーク 236 users、Zenn 111 いいねだった。
• ここでの事実はどれも WebFetch だけに頼っておらず、vec1 のフォーラム https://sqlite.org/vec1/forum はログインが要るので読んでいない。

実践やアウトプットの提案

• コンパイルなしに (pip install apsw のあと apsw.sqlite_extra.load(db, "vec1")) vec1 を読み込むか、3.54.0 のソースから vec1.so をビルドし、チームの RAG のチャンクをいつもの埋め込みモデル (日本語なら multilingual-e5 など) で flat のテーブルと ANN のテーブル (nbucket は √N 程度、quantizer:"opq"、codesize:32) に入れる。
  • flat のテーブルを正解として、SQL での再ランキング付きで K を 10、50、100、nprobe を 0.02、0.05、0.1 にしたときの recall@10 と、開発者のノート PC でのレイテンシを測り、agnews の数字 (K=100 で 0.93〜0.96) が日本語のテキストでも成り立つかを見る。
• 同じコーパスを 1 万、10 万、100 万チャンクで sqlite-vec v0.1.9 と vec1 に通し、レイテンシ、ファイルサイズ、学習と再構築の時間を記録して、対象の端末で厳密な探索では足りなくなる境目を探す。
• マルチテナントの RAG の使い方で絞り込みを試す: 探索の中で tenant_id = ? と制約する tenant_id のメタデータ列、黙って K を減らす WHERE flag AND ... の落とし穴、文書のテーブルとの JOIN を伴う streaming:1 である。
• 1 つの SQLite のファイルで、FTS5 の BM25 と vec1 の候補を 1 つの SQL 文の中で reciprocal rank fusion によって合わせるハイブリッド検索を作り、チームの評価用の質問でベクトルだけの検索と比べる。
• 学習のあとに新しい文書を挿入して再現率の推移を追い、増え続けるコーパスでどのくらいの頻度で vec1_train() と rebuild が要るかを決める。
• Go のサービスや端末上のビルドには ncruces/go-sqlite3 の ext/vec1 (cgo なし、vec1 0.7) を試し、Wasm の SIMD がないことでスループットがどれだけ落ちるかを測る。
• アウトプット: ローカルの RAG のための SQLite のベクトル検索を 1 ページで比べ (vec1 0.8 と、sqlite-vec 0.1.9 とその 0.1.10 のアルファ)、インデックスの種類、絞り込み、要素の型、距離、配布の経路、成熟度を、チームで測った再現率とレイテンシとともに並べる。

4. 🛡️ AWS が、エージェントの過去の操作に応じて判断できる Dogwood のポリシーを備えた Apple シリコンの Mac 向けのオープンソースのエージェント用サンドボックス Strands Box を developer preview で公開し、EC2 Mac での実測では、ポリシーが起動を許したホストのプログラムが、ポリシーで禁じたファイルを読めた

• 選定 / 影響度 1 / 将来性 2 / 注目度 2 / 起点 10-07、期間前の出来事 / 種別: リリース / 領域: セキュリティ・安全性、コーディングエージェント。
• 候補になったフィード項目:
  • zenn-trending 10-11 Strands BoxをEC2 Macで実測 — Dogwoodポリシーが効く経路を仕分け — Zenn 1 いいね、はてなブックマーク 0 users (取得時点)
• 起点: AWS は期間の 3 日前の 10-07 に、どのフィードも追っていない Open Source Blog で developer preview を発表し、今回の実行では Zenn の検証記事が初めてフィードに運んだ。
• 関連: 2026-10-10 のトピック 1 は MXC を、2026-09-29 のトピック 3 は Docker Cloud Sandboxes を扱っており、どちらも比べる相手になる封じ込めの仕組みである。

収集した情報

[A] AWS Open Source Blog — Introducing Strands Box: AI agent sandboxes powered by Dogwood, by Fernando Dingler (2026-10-07)

https://aws.amazon.com/blogs/opensource/introducing-strands-box-ai-agent-sandboxes-powered-by-dogwood/

• Strands Box は、OS レベルの封じ込め (macOS では Seatbelt) と Dogwood のポリシーを組み合わせた Apache 2.0 のサンドボックスとして developer preview に入り、操作ごとの人のレビューなしに動くコーディングアシスタントなどのエージェントを対象にする。
• 埋め込んだ Dogwood Local Engine が、求められた操作をポリシーとエージェントの記録された履歴に照らして判断し、許可か拒否をエージェントの外で強制する。
• 封じ込めはエージェントがホストとネットワークで届く範囲を決め、その境界の中の操作はポリシーが 4 つの強制点で決める: すべての外向きの通信を中継する egress のゲートウェイ、Strands Shell、Python 向けの Pydantic の Monty、MCP のブローカーである。
  • 2 つのインタープリターとブローカーはサンドボックスの外の Box 自身のプロセスで動き、エージェントからはローカルのソケット越しの普通の bash、python3、MCP のコマンドに見え、AWS はこれをトラステッドコンピューティングベースを広げるトレードオフだとする。
• すべての強制点が 1 つのイベントの履歴と 1 つの語彙を共有するので、どちらのインタープリターでの読み取りも fs:read、curl からでも Python からでもリクエストは http:request になり、どのツールで読んだかにかかわらず、顧客データを読んだあとの外向きの HTTP を 1 つのルールで止められる。
  • Strands Shell は rm -rf build/ をファイルごとの fs:delete の判断に展開するので、fs:delete への forbid は何かが消える前にそれを止め、普通の編集は通る。
• ハーネスの組み込みのファイルツールが開くプロジェクトのディレクトリのように box.toml で直接許可したパスは封じ込めだけで縛られてポリシーの履歴に入らず、AWS はポリシーでより多くを覆いたいとして、macOS 27 で加わる Endpoint Security の機能をぜひ採り入れたいとする。
• ローカルでの利用にコンテナや microVM を使わなかったのは、プロビジョニングしてローカルのファイルやツールにつなぐゲストの環境が増えるからで、ハーネスの許可のプロンプトに頼らなかったのは、それがエージェントのプロセスの中で動き、触れるファイルやホストではなくツールの呼び出しを判断するからだとする。
  • 同じ box.toml と policy.dw が、箱の中でどのハーネスを動かしても当てはまる。
• ゲートウェイはポリシーが許したリクエストにだけ認証情報を付けてエージェントのプレースホルダーを秘密の値に差し替え、Bearer トークン、カスタムヘッダー、HTTP Basic、クエリパラメータ、AWS SigV4 に対応する。
  • secret.inject = "always" はプレースホルダーなしでトークンを注入し、認証情報を割り当てただけではどの宛先も開かない。
• ルールはエージェントを固定のプリンシパルとする Cedar の構文で書き、Box::Action::"shell:spawn" や Box::Action::"http:request" のような操作に当てはめ、context.input からホスト、ポート、メソッド、パス、プログラムのパスを読む。
  • AWS はエージェントスキル authoring-box-policy も出しており、ほとんどの利用者はポリシーを LLM に書かせるとみている。
• 時間の条件の例は、::response のイベントのうち output.status: 200 のものを formerly within 10m と count for (t: Timepoint) で数えて Slack の POST /api/chat.postMessage を 10 分に 3 回までにするので拒否は数に入らず、::request に結びつければ試行を数えることになる。
  • 拒否された投稿は policy denied this operation とルールの @id と @description を伴う HTTP 403 を受け取るので、エージェントは再試行せずに待てる。
• 今後の予定は、ほかの OS、入っているハーネスを検出して基本のポリシー付きの box.toml を作る CLI、Strands Harness SDK、LangChain、Claude Agent SDK で作ったエージェントを Box と一緒に Amazon Bedrock AgentCore、ECS、Kubernetes 向けにパッケージすること、Dogwood の活性 (liveness) のルールである。

[A] Strands Agents — Strands Box: The Big Picture, by Marc Brooker (2026-10-07)

https://strandsagents.com/blog/strands-box-the-big-picture/

• Brooker は Box を、AgentCore Runtime (セッションごとの Firecracker の microVM)、AgentCore Policy (Cedar)、Dogwood、Dogwood Local Engine に続くものと位置づけ、Box のポリシーは AgentCore Policy と同じ基盤の技術だとする。
• Box はカーネルのサンドボックスをポリシーの適用に使うのではなく、すべてのやり取りを唯一の出口であるユーザー空間のポリシー層に流し込むために使い、それによってシステム、プロトコル、言語を理解したルールを書けるとする。
  • microVM のデバイスの境界から見えるのはおもに TLS の暗号文とディスクのオフセットで、システムコールのフィルタリングはファイルと接続は見えても TLS の中は見えず、gVisor のようなエミュレーションも MCP のレベルの意味には届かないと論じる。
• 例として、git push を、直近 15 分以内に npm test が成功してその後に git add がない場合にだけ許し、AWS の MCP サーバーへの tools/call を 1 時間に 60 回までにする。
  • こうしたポリシーは読み書きが難しいと認めて今後数か月の大きな投資先とし、最先端のコーディングエージェントはすでに Dogwood をうまく読み書きするとも言う。
• Box はより多くのコード、つまり Rust で書いてファジングしたインタープリターやプロトコルのインターセプターを信頼することになると認め、コードが増えればバグの機会も増え、この領域のバグはポリシーの迂回を意味しうると書く。
  • マルチテナントのクラウドでの利用には、セッションごとの専用の microVM と Box を組み合わせることを勧め、最も簡単なのは AgentCore Runtime の中で、EC2、Lambda、Fargate でもよいとする。

[A] strands-agents/box — README, security model, policy guide, limitations and the v0.1.0 release (2026-10-07)

https://github.com/strands-agents/box / https://github.com/strands-agents/box/blob/v0.1.0/docs/user/security.md / https://github.com/strands-agents/box/blob/v0.1.0/docs/design/limitations.md

• 2026-10-02 に Apache 2.0 で作られた Rust のリポジトリは 10-13 時点でスター 371、フォーク 18 で、v0.1.0 (10-07 17:24 UTC 公開) は box-v0.1.0-aarch64-apple-darwin.tar.gz だけを出し、download.sh がそれを SHA256SUMS.txt と照合する。
  • リポジトリの説明は、Linux への対応を予定しているとする。
• 入門の手順には、macOS 15 以降の Apple シリコンの Mac、Homebrew の Node.js 22.21 以降、us-west-2 の Amazon Bedrock での Claude Opus 5 が要る。
• security.md は 2 つの層に分ける: box.toml はワークロード自身のプロセスが開けるものを決めて最初のプロセスより前から OS が強制し、ポリシーの判断はなく判定ログにも何も残らず、policy.dw は箱の信頼されたプロセスを通るリクエストを 1 件ずつ判断する。
  • [tool.<name>] のプログラムや、shell:spawn の permit で認められたホストのプログラムについては、ポリシーが決めるのは起動するかどうかだけで、そのファイル操作や子プロセスは判断しない。
• Box は箱のディレクトリへのリクエストと、読み込んだ box.toml と policy.dw の読み取りや変更をつねに拒否するが、ゲートウェイに組み込みの遮断がないので、クラウドのメタデータの保護は各ポリシーが持つべき 2 つの forbid ルール metadata_hosts と metadata_addresses だけである。
  • リポジトリの例のポリシーは両方を持つが入門のポリシーにはなく、security.md は運用者に加えるよう求める。
• 文書化された制限には、パスの条件のない fs:read の permit は ~/.aws と ~/.ssh に届くこと、重なる permit は警告なしに読み込まれること、::response の予算は処理中のリクエストで使いすぎうる一方、::request の予算は正確だが拒否された試行でも減ることがある。
  • count_within のような時間のマクロを呼ぶルールは、呼び出しより前の文字列がコメントでも変わると数を失うが、インラインの when temporal 句なら数は保たれる。
  • 判定ログはルールとパスを記録するが操作は記録しないので、同じファイルへの cat と ls が同じに見える。
• 拒否は policy denied this operation on '<path>' [policy: <id>]: <description> という文面で、呼び出し元ごとに届き方が違い、拒否されたシェルのコマンドは終了ステータス 126、Python では PermissionError、リクエストには HTTP 403、MCP の呼び出しには JSON-RPC のエラー -32001 が返る。
• 語彙は fs:read、fs:write、fs:delete、fs:move、予約済みの fs:other、net:connect、http:request、shell:exec、shell:spawn、mcp:call の 10 の操作と、見つけた MCP のツールごとに作られる操作からなり、外向きの呼び出しには net:connect と http:request の両方の permit が要る。
  • ファイルシステムのレスポンスは output.result に completed、descriptor_issued、indeterminate のいずれかを持ち、policy クレートの README は、許可した呼び出しのあとでバイトが動くので descriptor_issued をあえて区別しており、完了した書き込みを数えるルールはそれを除くべきだとする。
• 判断は <box_dir>/private/telemetry/records.jsonl に OTLP の JSON で書かれ、署名もチェーンもなく、出力先が失敗すると記録は知らせなしに失われる。
• limitations.md は、Box はリソースの制限、テナント間の分離、カーネルの脆弱性への防御、リモートの MCP サーバーや自身の信頼されたプロセスの欠陥の封じ込め、改ざんできない監査証跡のいずれも提供しないとする。
• ポリシーガイドの書き込み予算の例 (1 時間に completed の内容の書き込みを最大 20 回) は tee の書き込みが write_budget で拒否される出力を載せており、その文面は 10-13 時点の main でも変わっていない。

[A] strands-agents/box — Claude Code and Codex CLI tutorials, and the getting-started guide (2026-10-07, at tag v0.1.0)

https://github.com/strands-agents/box/blob/v0.1.0/docs/user/tutorials/claude-code.md / https://github.com/strands-agents/box/blob/v0.1.0/docs/user/tutorials/codex-cli.md / https://strandsagents.com/docs/user-guide/box/getting-started/

• v0.1.0 には Claude Code、Codex CLI、Pi、Strands CLI、Strands Agents SDK のエージェントの例が付き、操作の語彙とコンテキストのフィールドは 1.0.0 までに変わりうると警告する。
• Claude Code の例は 2.1.292 を --dangerously-skip-permissions 付きで Bedrock (CLAUDE_CODE_USE_BEDROCK=1、ANTHROPIC_MODEL=global.anthropic.claude-opus-5) で動かし、プロジェクトには list の許可しか与えないので、Read、Write、Edit は EPERM で失敗し、ファイルはすべて Bash ツールから箱のシェルを通る。
  • チュートリアルの実行では、Claude Code が自分で cat と printf に切り替え、no_env と no_deletes の拒否をそのまま引用した。
  • Box は Claude Code の OpenTelemetry のスパン、ログ、メトリクスを同じ記録ファイルに中継し、CLAUDE_CODE_PROPAGATE_TRACEPARENT=1 で各判断をそれを引き起こしたツールのスパンに結びつける。
• Codex CLI 0.160.1 の例には、Codex 自身のサンドボックスのヘルパーが箱の中では起動できないので sandbox_mode = "danger-full-access" と approval_policy = "never" が要り、apply_patch は Codex 自身のプロセスから書き込んで Operation not permitted になるので、シェルで編集するよう指示する AGENTS.md も要る。
  • https://bedrock-mantle.us-west-2.api.aws/openai/v1 を通じて Bedrock の openai.gpt-5.6-terra を動かす。
• Strands CLI のガイドは、AWS SDK の呼び出しがゲートウェイを通るように Node のプリロードファイルを読み込み、SDK の HTTP/2 での Bedrock の呼び出しはプロキシの設定を無視するので HTTP/1.1 を強制する。
  • 箱のシェルには cat、printf、ls のほか約 30 の組み込みコマンドがあり、それ以外のプログラムはポリシーが許す必要のある shell:spawn になる。

[A] AWS Open Source Blog — Introducing the Dogwood Local Engine: temporal governance for agent actions (2026-09-30)

https://aws.amazon.com/blogs/opensource/introducing-the-dogwood-local-engine-temporal-governance-for-agent-actions/

• Box が埋め込むエンジンは Apache 2.0 の Rust のライブラリで、並行するイベントを順序づけ、クラッシュしても履歴が残るように各イベントを redb のログに書いて定期的にスナップショットを取り、分離は強制層に任せるので、強制層はエージェントをエンジンの状態から遠ざけておく必要がある。
• セッションの途中でポリシーを変えると、変更後に記録されたイベントだけで判断されるので、変更前に満たした前提条件はもう一度満たす必要がある。
• 1 時間に 360 イベントを処理するサーバー級のホスト 1 台で、24 時間の窓は 12 時間のセッションのあとで 1 判断 6 ms に達して 15 分の窓の 300 倍のコストになり、細かい操作のスキーマは粗いものより約 5 倍速く評価された。

[A] AWS Open Source Blog — Introducing Dogwood: runtime verification for AI agents (2026-08-06), with the Dogwood Guide

https://aws.amazon.com/blogs/opensource/introducing-dogwood-runtime-verification-for-ai-agents/ / https://dogwood-policy.github.io/dogwood/

• Dogwood (Apache 2.0) は Cedar を拡張したもので、構文として正しい Cedar のポリシーはそのまま Dogwood としても正しく、Metric First-Order Temporal Logic (MFOTL) に由来する when temporal { … } 句を、formerly、previous、since、exists、tp、count、sum などの演算子とともに加える。
• AWS は同時に AgentCore Policy に Dogwood の対応を加えたが、時間の条件は Cedar の自動推論による解析の外にあり、イベントのログとともにコストが増えうる状態の追跡が要ると注意する。
• ガイドの dogwood CLI (validate、replay、lower、check-parse) は、Rust のコードを書かずにポリシーを検査したり、トレースのファイルの上で再生したりできる。

[C] Zenn (kashiwabaray) — Measuring Strands Box on EC2 Mac: sorting out which paths the Dogwood policy covers, by Yutaka Kashiwabara (2026-10-11, in Japanese)

https://zenn.dev/kashiwabaray/articles/fc2d097da71f30

• 筆者は v0.1.0 (strands-box 0.1.0、ドキュメントはタグ 81d241f) を us-east-1b の EC2 mac2.metal (Apple M1、macOS 26.7) で、Bedrock は us-west-2 にして動かし、Box が Strands Shell に差し替える zsh -c を呼ぶ probe で決まったコマンドを流し、プロジェクトは list の許可だけにした。
  • 各ケースは 1 回ずつで、mac2.metal は 1 時間 $0.65、最低 24 時間 ($15.60) の課金で、us-west-2 は 4 つの AZ すべてで InsufficientHostCapacity を返した。
• エージェント自身の open('README.md') は Seatbelt から PermissionError: [Errno 1] Operation not permitted を受けて判定ログには何も残らず、Strands Shell の cat .env (終了コード 1) と Monty の open('.env') は同じ no_env ルールで拒否された。
  • shell:exec の記録は cat ~/.aws/credentials を cat <redacted> と伏せたが、続く fs:read の deny の記録はパスをそのまま残した。
• shell:spawn で /usr/bin/awk を許し、[tool.awk] でプロジェクトの read を与えると、awk 1 .env は no_env の forbid があるのにダミーの DB_PASSWORD を表示し、.env への fs:read は記録されず、止められたのは [tool.awk.filesystem] に deny を書いたときだけだった (awk: can't open file .env、終了コード 2)。
• エージェントのプロセスには Bedrock のキーの代わりに strands_box_5f で始まる 76 文字のプレースホルダーが見え、Strands Shell での echo $AWS_BEARER_TOKEN_BEDROCK は空文字列を表示した。
• Strands Shell の組み込みの curl はポリシーにかかわらず 169.254.169.254 に届かず何も記録しなかったが、ゲートウェイを通るホストの /usr/bin/curl は、全許可のポリシーから 2 つのメタデータの forbid を外すと、インスタンス ID と IMDSv2 のトークンを取得した (HttpTokens=optional、インスタンスプロファイルなし)。
  • ルールで拒否されたときも、ホストの curl は終了コード 0 で 403 の本文を表示したので、終了コードで判断するスクリプトには --fail か --fail-with-body が要る。
• secret.txt への fs:read::response から 10 分以内の example.com への http:request を禁じるルールでは、接続は通り、リクエストが curl: http:request gate: policy denied this operation on 'example.com:443/' [policy: no_send_after_secret] で拒否された。
• fs:write::response のうち結果が completed のものを数えるポリシーガイドの書き込み予算は、Strands Shell の >> や tee -a の書き込みを 1 度も数えず (5 回とも許可)、それは v0.1.0 がこれらを descriptor_issued として記録するからで、Monty の書き込みは completed として数えられ 4 回目から拒否された。
  • 結果の条件を外すとシェルの書き込みも 4 回目から拒否され、::request で数えると 3 回目から拒否されて、通ったのは上限の 3 回より 1 回少なかった。
  • 数えた回数は再起動と policy.dw へのコメントの追記を越えて残り、10 分の窓が過ぎるとリセットされ、<box_dir>/private/dogwood.redb に保存される。
  • 書き込みを試す中で、Strands Shell は zsh と違って echo 1 >> notes/log.txt を、ファイル記述子 1 のリダイレクトである echo 1>>notes/log.txt と解釈することも見つけた。
• Strands Shell 経由の true 20 回は中央値 11.4 ms (9.5〜58.0 ms で、最大は初回) で、ホストの /bin/zsh の 2.7 ms (2.5〜4.1 ms) より 1 コマンドあたり約 9 ms 多く、box run 全体は 0.5〜1.4 秒だった。
• Strands Agents SDK のエージェント (1.59.0、global.anthropic.claude-opus-5) は拒否のたびにルールと説明を引用して止まったが、筆者はそれを、引用して止まるよう指示する例の system prompt の影響でもあり、ポリシーだけによるものではないとする。
• 筆者は、Box はエージェントの作業を Strands Shell と Monty に集約できる用途ほど効果が大きいとし、「ホストのプログラムを多く許可する用途では、ポリシーより [tool.<name>] の設計が安全性を左右します」と結ぶ。

[B] The Register — AWS launches open-source AI agent sandbox to prevent YOLO mode disasters, by Brandon Vigliarolo (2026-10-07)

https://www.theregister.com/a/5301687

• Marc Brooker は The Register へのメールで、Box は設定したポリシーを決定的に強制し、エージェントが言いくるめてルールをかわすことはできないが、どのアクセスを与え、どこで人のレビューが要るかを決めるのは開発者のままだと述べた。
• AWS は Linux への対応を開発中、Windows のクライアントを検討中とし、どちらも提供日は示さなかった。

[B] InfoWorld — AWS takes aim at runaway AI agent behavior with Strands Box, by Prasanth Aby Thomas (2026-10-08), republished by CSO Online the same day

https://www.infoworld.com/article/4232439/aws-takes-aim-at-runaway-ai-agent-behavior-with-strands-box.html / https://www.csoonline.com/article/4232446/aws-takes-aim-at-runaway-ai-agent-behavior-with-strands-box-2.html

• 記事はこの設計を、専用の VM の代わりに OS の分離を使い、その代価としてポリシーの強制のために信頼すべきコードが大きくなるものと位置づける。
• Pareekh Jain (Pareekh Consulting) は、Box は新しくない技術で現実の穴を埋めるもので、利点はエージェントのフレームワークをまたいだ一貫した強制だとし、処理のオーバーヘッドと、新しい部品がそれ自体の欠陥を持ちうることに注意を促す。
  • 許された権限の中でエージェントが下す有害な判断をすべて防げるわけではないので、IAM、監視、人による監督は引き続き必要だとも言う。
• Tulika Sheel (Kadence International) は、まずいポリシーは正当な作業を止めたり穴を残したりしうるとし、企業は広く採り入れる前に本番での信頼できる挙動の証拠を求めるだろうとみる。
• AWS はこの媒体に、macOS 以外のプラットフォームや AgentCore、ECS、Kubernetes へのデプロイの時期を示さなかった。

[B] AWS Builder Center — Strands Box on AWS Lambda MicroVMs: a kernel per agent, a policy per command, and a fleet to run them with microvm-ctl, by Vivek Raja P S (2026-10-07)

https://builder.aws.com/content/3KNzMek3U1WL6S49viNEhHeFZmC/strands-box-on-aws-lambda-microvms-a-kernel-per-agent-a-policy-per-command-and-a-fleet-to-run-them-with-microvm-ctl

• AWS AI Hero の筆者は、名前空間とシステムコールのフィルターを使うバックエンドが ARM64 だけで動く aarch64 Linux 向けに Box をソースからビルドして Lambda MicroVMs で動かしたが、Box が新しい /proc をマウントできるように additionalOsCapabilities: ["ALL"] が要った。
  • 既定の Docker のコンテナは unshare(CLONE_NEWUSER) を拒み、Box は seccomp=unconfined と systempaths=unconfined を付けたときだけ動いた。
• us-east-1 で、5 回のツール呼び出しと 26 の判断を含む箱はウォームの 1 GB の VM の中で 83 ms かかり、VM 1 台 (2 vCPU) は 4 つの箱を並行させて毎秒約 22.7 箱が上限で、8 台の VM にわたる 64 の箱は 64 とも正しく動き、no_env と no_deletes の判定も macOS と同じだった。
• Linux では list の許可を表せず (代わりに勧められる read ではエージェントが判断なしに .env を開ける)、コンパイル済みの wheel を含む venv は exec の下に置く必要があり、aws:// はプロファイルの静的なキーでしか署名しないので、IAM ロールを持つワークロードはタスクごとに Bedrock のベアラーキーを発行して env:// の経路で渡す。
• 彼の役割分担は、ノート PC の 1 つのエージェントには Box だけ、クラウドのエージェントにはユーザーかセッションごとの microVM の中に Box を置くというもので、エージェントが何を壊せるかは VM が、何をしてよいかは Box が決める。

[C] strands-agents/box issues — #10, #18, #33, #36, #38, #39 and #49 (2026-10-07 to 2026-10-11)

https://github.com/strands-agents/box/issues

• リリースのワークフローは aarch64 と x86_64 の Linux の tarball もビルドするが macOS のものしか公開せず、メンテナーは Linux は macOS より開発が遅れているので出していないと述べ (#18)、10-09 には 5 つのエピックからなる Linux の計画が起票された (#10)。
  • Ubuntu 22.04 でのビルドは GLIBC_2.35 を求めるので、glibc 2.34 を載せる Amazon Linux 2023 では起動しない (#49)。
• AgentCore のコンテナの Linux ARM64 で Box の中の Claude Code を動かすチームは、仲介された Shell にはエージェントのプロセスが受け取る env:// のプレースホルダーがないと報告し (#39)、Fernando Dingler は 10-11 に Box が渡すべきものだと答えた。
• Seatbelt と seccomp の拒否を記録してほしいという要望 (#33) に Dingler は、一部のシステムコール、まずファイルシステムの呼び出しをポリシーエンジンに通す計画だと答え、利用者が操作の語彙を広げられる Policy Packs も提案している (#38)。
• ソケットのエイリアスは、仲介するシェルや Python のコマンドのたびに RLIMIT_NOFILE までのすべての記述子を閉じており、Linux x86_64 で上限 65,536 では 12.6 ms、1,073,741,816 では 208.97 秒かかるが、close_range の 1 回の呼び出しなら 602 ns で済む (#36)。

[C] Hacker News — three Strands Box submissions (2026-10-07 to 2026-10-08)

https://news.ycombinator.com/item?id=49997144 / https://news.ycombinator.com/item?id=50006827 / https://news.ycombinator.com/item?id=50007576

• 10-13 の Hacker News の検索 API によれば、Brooker の記事を投稿した 2 件は 7 ポイントと 5 ポイント、リポジトリを投稿した 1 件は 4 ポイントで、どれにもコメントはなかった。

メモ

• CSO Online の記事は InfoWorld の記事の転載なので 1 本と数え、独立した取り上げは既存のメディアの The Register と InfoWorld に実務者による builder.aws.com を加えたもので、10-13 の検索では Zenn の検証のほかに日本のメディアの記事は見つからなかった。
• 書き込み予算: policy.md の例は tee の書き込みを拒否する出力を示すが、ルールは結果が completed のものしか数えず、Strands Shell の書き込みは descriptor_issued として記録され (policy クレートは完了した書き込みからそれをあえて除く)、Zenn の検証ではシェルの書き込みが 5 回とも許可されており、10-13 までにこれを報告した issue はない。
  • policy.md の ::request の変種は比較が >= 20 のままなので 19 回しか通さないだろうという Zenn のさらなる指摘は、上限 3 での結果からの推測で、試されていない。
  • Brooker の 1 時間に 60 回という MCP の例も ::request と >= 60 の同じ形なので 59 回しか通さないかもしれず、これも試されていない。
• AWS の認証情報: ブログのオンコールの例ではゲートウェイがホストの oncall プロファイルの一時的なセッションの認証情報で署名するが、v0.1.0 の egress と認証情報のドキュメントは、aws:// の経路はプロファイルの静的なアクセスキーで署名し credential_process のプロファイルを拒むとしており、builder.aws.com も同じ制限に当たったが、セッショントークンを持つプロファイルが使えるかは文書にない。
• ブログのポリシーの断片は http:request しか許していないが、actions.md は外向きの呼び出しごとに net:connect と http:request の両方の permit を求めるので、断片だけを写すと文書の規則どおり接続の段階で拒否されるはずで (試されていない)、ブログは動く構成として入門のガイドを案内している。
• シェルの中のプレースホルダー: Zenn が Strands Shell で見た空の変数は #39 と一致し、メンテナーは Box が渡すべきものと認めたので、v0.1.0 では env:// の変数からトークンを送るシェルのコマンドは何も送らないが、secret.inject = "always" の経路ならプレースホルダーは要らないはずである (ブログからの推論で、試されていない)。
• メタデータ: ブログのオンコールのポリシーは名前を挙げたホストしか許さないので IMDS は既定の拒否で拒まれたままで、Zenn が測った到達には 2 つのメタデータのルールのない広い宛先の permit が要り、入門のポリシーにはそのような permit はない。
• コーディングエージェント: チュートリアルでは、Claude Code の Read、Write、Edit と Codex の apply_patch は、判断もログもない box.toml の許可でプロジェクトに届くか、切り離されて編集がシェルを通るかのどちらかで、シェルだけでの編集が実際のコーディングのタスクにどう響くかを測った情報源はなく、メンテナーはこの差を埋める手段としてシステムコールの仲介 (#33) と macOS 27 の Endpoint Security を挙げる。
• オーバーヘッドの数字はそれぞれ別のものを測っている: Zenn の macOS の M1 での 1 コマンドあたり約 9 ms、builder.aws.com の Linux の microVM での 5 回の呼び出しを含む箱 1 つあたり 83 ms、#36 の Linux で上限 65,536 のときの 1 コマンドあたり 12.6 ms の記述子を閉じるループで、そのループが macOS の数字の一部を説明するかは試されていない。
• builder.aws.com の数字は、メンテナーがあえてリリースしていないソースからのビルドによるもので、実現できることを示しても、サポートされた構成ではなく、筆者は自分が貢献する Strands のプロジェクトに box を挙げているので完全に独立した記事ではなく、ページの日付は 10-07、数字の日付は 10-08 である。
• 以前のトピックとの比較: MXC (2026-10-10 のトピック 1) も macOS ではエージェントを Seatbelt で封じ込めるが、その Seatbelt のバックエンドは外向きの通信を全部許すか全部止めるかしか選べず、ホスト名のルールは呼び出し側が管理するプロキシに任せるのに対し、Box はホスト、メソッド、パスを履歴とともに判断するゲートウェイを備える一方で、統制が及ぶのはシェル、Python、ゲートウェイ、MCP のブローカーを通るものだけである。
• Docker Cloud Sandboxes (2026-09-29 のトピック 3) はエージェントごとに microVM を与え、プロキシを通じてリクエストごとに秘密を注入しており、Box のゲートウェイと同じプレースホルダーとプロキシの形をとり、Brooker はそうした VM の境界を補完とみて、マルチテナントのクラウドでは Box をセッションごとの microVM で包むよう勧める。
• 10-13 の反応: Zenn の検証は 1 いいね、はてなブックマーク 0 users で、AWS の投稿ははてなブックマーク 1 user だった。
• この節の事実はどれも WebFetch だけに頼っていない。

実践やアウトプットの提案

• macOS 15 以降の Apple シリコンの Mac と Bedrock のアクセスがあれば、v0.1.0 の examples/claude-code の箱を小さな実際のリポジトリで半日動かし、Claude Code がファイルツールからシェルに切り替える頻度と、printf や sed による複数行の編集が持ちこたえるかを数える。
• チームのポリシーを左右する Zenn の 3 つの確認を、records.jsonl で permit が deny に変わる点を読みながら繰り返す: shell:spawn で許したホストのプログラムが禁じたファイルを開くこと、input.operation: Box::FsReadOperation::"read_content" で絞った読んだら送らないルール (Zenn は試していない)、descriptor_issued を数える書き込み予算である。
• git push のゲートや MCP の呼び出しの予算のような時間のルールを、箱に入れる前に dogwood CLI で記録したトレースの上で再生し、並行するツール呼び出しのもとでの ::request と ::response の数え方を比べる (どの情報源も測っていない)。
• 手元に Mac がなければ EC2 の mac2.metal は 24 時間の最低割り当てで少なくとも $15.60 かかるが、Zenn はホストを確保する前に box.toml、ポリシー、probe をすべて用意して約 1 時間 10 分で終えた。
• 使っているコーディングエージェントについて、統制がそれぞれどこにあるか (エージェントの中のハーネスの許可ルール、エージェントの外でシェル、Python、ゲートウェイ、MCP を見る Box のポリシー、MXC のような OS の封じ込め、Docker のような microVM のサンドボックス) と、それぞれが何を記録するかを 1 ページのチームのメモにまとめられる。
• write_budget の例の tee の出力を上流に報告すれば、10-13 時点でこれを扱う issue はないので、小さいが役に立つ貢献になる。

5. ✈️ あるエンジニアが、FAA の SAFO 13002 と 17007、EASA の安全情報から根拠に基づく訓練 (EBT) まで航空の自動化をめぐる制度をたどり、AI コーディングエージェントと働くエンジニアが保つべきは AI なしで書く力ではなく AI から引き継ぐ力であり、ノルマではなくリスクの高い差分を手で読み、自分たちの障害を演習にすべきだと論じた

• 選定 / 影響度 1 / 将来性 1 / 注目度 2 / 起点 10-05、期間前の出来事 / 種別: 論考 / 領域: コーディングエージェント。
• 候補になったフィード項目:
  • hatena-ai-agent 10-11 オートパイロットは外せる人間を前提にしている — AI時代のエンジニア技能維持を航空業界に学ぶ — はてなブックマーク 159 users、Zenn 80 いいね (取得時点)
• 起点: エッセイは期間の 5 日前の 10-05 に Zenn で公開され、はてなブックマークが 100 users 以上の記事を載せるこのフィードには 10-11 に現れた。

収集した情報

[A] shimitaro (Zenn) — Autopilot assumes a human who can disengage it: what aviation teaches about keeping engineering skills in the AI era (2026-10-05, in Japanese)

https://zenn.dev/shimitaro/articles/eb45d8d63c7bd1

• Zenn の API によれば 2026-10-05 17:06 JST に、Zenn のトピック AI、AWS、SRE を付けた idea の記事として公開され、筆者の Zenn での唯一の記事である。
  • 2026-10-13 10:23 JST に 80 いいね、20 ブックマーク、コメント 0 で、10:47 JST の筆者の記事一覧では 82 いいねだった。
  • 演習をチームの日常に組み込む具体的なやり方は別の記事で扱うと予告して終わるが、その時点ではまだ公開されていなかった。
• きっかけ: あるエージェントが実装し、別のエージェントがレビューとテストを書き、筆者が差分の要所を眺めてマージする流れの中で、AI のレビューが問題なしとした下に読んでいない CDK の差分が並び、承認しようとして手が止まった。
• 抽象化のレイヤーが上がること (アセンブリから C、Java や Python、フレームワークへ) は受け入れたうえで違いを 1 つだけ挙げ、コンパイラは決定的でフレームワークのバグは共有されるが、エージェントの出力は毎回変わり、もっともらしく自信ありげに間違う、つまりたまに静かに間違える下のレイヤーだとする。
• 主張は、航空の規制当局が保たせているのは自動化なしで飛ぶ力ではなく自動化から引き継ぐ力であり、エンジニアも AI なしで書く力ではなく AI から引き継ぐ力を保つべきだというもので、見出しには「目的は AI なしで書けることではなく、AI から引き継げること」と掲げる。
• 論拠として、FAA SAFO 13002 (2013-01-04)、FAA の最終規則 78 FR 67800 (2013-11-12)、飛行経路管理システムについての PARC/CAST の報告書 (2013)、CAST SE-30 (2008)、SAFO 17007 (2017-05-04)、FAA AC 120-123 (2022-11-21)、EASA SIB 2013-05R1、そして ICAO Doc 9995、EASA NPA 2018-07、Opinion 08/2019 の根拠に基づく訓練 (EBT) を挙げる。
• Mermaid の図は、航空のループ (自動操縦を使う、監視する、異常を認識する、解除する、引き継ぐ、回復する) を AI 開発のループ (AI に実装させる、出力を監視する、誤った実装や判断を認識する、AI から人に切り替える、コードを読んで原因を探す、直して回復する) に対応させる。
  • 表は、自動操縦をコーディングエージェントに、飛行計画を要件と設計に、モードアウェアネスを AI が何をしているかの理解に、シミュレーター (FSTD) を障害解析とレビューの演習に、EBT を本番障害からポストモーテム、演習の教材への流れに対応させる。
• 提案する演習: Terraform や CDK に仕込んだ危険な設定を見つける、"Action": "*" や不要な "Resource": "*" のような IAM の過剰な権限を洗い出す、ALB が 502 を返す原因をアクセスログとターゲットの設定から特定する、AI が問題ないとしたコードから問題を拾う、データベースの削除につながる IaC の変更をレビューで止める、AI が書いたテストをすり抜ける障害を想定する、AI が提案した誤った修正を検証する。
• 例題: 本番と検証で共有するスタックの定義で、AI が承認した rds.DatabaseInstance への 2 行の差分が、removalPolicy を cdk.RemovalPolicy.RETAIN から DESTROY に、deletionProtection を true から false に変える。
  • 想定解答は本番向けにはこれを止めるというもので、removalPolicy は CloudFormation の DeletionPolicy と UpdateReplacePolicy の両方を決めるので、スタックの削除でも、どんな置き換え (新しいインスタンスを作ってから古いものを消す) でも本番のデータベースが消え、それを止める削除保護も残っていない。
• 日常の作業では、1 日に決まった行数を読むような一律のルールを、ノルマを避けよという SAFO 17007 の助言になぞらえて退け、AI のレビューを通ったあとでもリスクの高い差分 (IAM ポリシーの変更、データを消しうる IaC、ネットワークの構成) だけは意図して手で読むことを勧める。
• EBT からはループを借りる: 本番の障害のもとになったコードや設定を匿名化し、小さな再現環境に作り直してチームで定期的に演習し、合否を付けると課題は易しく報告は控えめになりがちなので合否は付けない。
  • AI が提案した誤った修正、AI のレビューが見逃した差分、AI が書いたテストをすり抜けた障害のような AI の時代の素材は、automation surprise の訓練教材になる。
• 認める限界: ソフトウェアの障害の多くはロールバックでき、訓練を義務づける規制はなく、1 人のエンジニアが複数のエージェントやリポジトリを見ることがあり、手動の操縦は身体技能に頼るがコードを読んで原因を特定するのは認知的な作業である。
  • そのうえで、ソフトウェアでの AI の誤りはコックピットのような警報のない、ほぼすべて静かなものなので、異常の認識が最も難しい段階であり、演習は AI が問題ないとするものから問題を見つけることを中心にすべきだと論じる。
• エージェントが操縦を担う PF (pilot flying) になれば人は監視役の PM (pilot monitoring) に回るが、航空の PM は PF として飛べる訓練を受けているので、実装の技能をゼロにしてよいわけではないとする。

[A] FAA — SAFO 17007, Manual Flight Operations Proficiency (2017-05-04, background)

https://www.faa.gov/sites/faa.gov/files/other_visit/aviation_industry/airline_operators/airline_safety/SAFO17007.pdf

• Air Carrier Training Aviation Rulemaking Committee の Flight Path Management Workgroup の勧告に基づき、手動飛行の習熟を育てて保つ訓練と運航の方針を航空会社に求める。
• カリキュラムは手動飛行がほかの技術的な操縦技能の土台だという考え方に沿うべきだとしつつ、手動飛行には身体技能以上のものが含まれると認める。
  • 基礎知識の一覧は身体と認知の両面にわたり、自動化のレベルを変えるたびの計器の表示の変化まで含む。
• 訓練のシナリオには、機体の装備に応じて承認されたフライトディレクター、自動操縦、オートスロットルのすべての組み合わせ (FD オン、AP オフ、AT オンや、3 つともオフなど 5 つを例示) と、PF と PM の両方の作業負荷の管理を含める。
• 運航では機長が、天候、地形、時間帯、乗員の経験、交通の密度、機体の状態のような脅威を量ってその都度判断する。
  • 方針は、夜間には手で飛ばないといった一律のルールや、科学的な根拠のない手動飛行のノルマ (例は月に少なくとも 10 時間) を避けるべきだとする。

[A] FAA — SAFO 13002, Manual Flight Operations (2013-01-04, background)

https://www.faa.gov/sites/faa.gov/files/other_visit/aviation_industry/airline_operators/airline_safety/SAFO13002.pdf

• きっかけは、通常の運航、インシデント、事故にわたる運航データの分析で、手動操縦の誤りが増えていたことである。
• 自動飛行システムを使い続けても手動の技能は強化されず、望ましくない状態から素早く回復する能力が落ちうるので、運航者は運航と訓練の両方で手動飛行を重視すべきだとする。
• 手動の練習は作業負荷の低い状況と非 RVSM の空域に置き、自動化は作業負荷の高い状況と自動操縦を要する手順に充てる。

[A] EASA — Safety Information Bulletin 2013-05R1, Manual Flight Training and Operations (2025-06-23, background)

https://ad.easa.europa.eu/blob/EASA_SIB_2013_05_R1.pdf/SIB_2013-05R1_1

• 2025 年 6 月 23 日に出た改訂版で、2013 年 4 月 23 日の SIB 2013-05 を改める情報提供だけの文書であり、自動化は安全に大きく寄与したが、使い続けても手動の操縦技能は保てないというエッセイの読みを裏づける。
• FAA の AC は通常の運航で広く手動で飛ぶ可能性を示唆するが、EASA は CAT 運航で手動の操縦技能を訓練し発揮できる条件を慎重に評価して定めるべきだと考えるとし、エッセイが引く FAA と EASA の対比を裏づける。
• 欧州の運航者の方針は、離着陸以外は全面的に自動化するものから、決めた高度より下ではできるだけ自動化を外すものまで幅があり、EASA は運航者に SMS と FDM で逸脱を監視し、EBT に沿ってそのデータに合わせて訓練を調整するよう求める。

[A] FAA — Advisory Circular 120-123, Flightpath Management (2022-11-21, background)

https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_120-123.pdf

• Part 121 と 135 の運航者と Part 142 の訓練センター向けの飛行経路管理の指針で、手動の運航、自動システムの管理、パイロットによる監視、エネルギーの管理を扱う。
• 各パイロットは機体を手動で飛ばせる力を十分に持つ責任があり、操縦していないパイロットはつねに介入できる用意をしておくべきだとしており、エッセイの PF と PM の論点を FAA 自身の言葉で述べている。
• SAFO 17007 の運航の指針を引き継ぎ、手動飛行のノルマは検証された科学的な根拠がある場合にだけ認めるとする。

[A] Casner, Geven, Recker and Schooler (Human Factors) — The Retention of Manual Flying Skills in the Automated Cockpit (December 2014, background)

https://gwern.net/doc/technology/2014-casner.pdf

• SAFO 17007 が関連する指針に挙げる NASA Ames 主導の研究 (DOI 10.1177/0018720814535628) で、16 人の航空会社のパイロットが Boeing 747-400 のシミュレーターで、自動化のレベルを変えながら通常と非通常のシナリオを飛んだ。
• 計器の走査と手動の操縦は、めったに練習しなくてもおおむね保たれていたが、地図表示なしでの位置の把握、次の航法の手順の判断、計器の故障の認識のような手動飛行の認知的な作業では、より頻繁で大きな問題が出た。
  • 高度計の故障では、75% のパイロットが割り当てられた高度から 300 フィート以上ずれるまでそれに従い、ほかの高度計と方位計を相互確認したのは 69% と 63% だけだった。
• 自動飛行のもとでは作業に関係のない考えに費やした時間が 20.0% で、手動の操縦では 11.7%、生データと手動の操縦では 6.9% であり、考えがよくそれたパイロットほど航法の誤りが多かった (r = .56、ばらつきの約 30%)。
  • 著者らは、認知的な技能を保てるかは、パイロットが自動化の監督にどれだけ積極的に関わり続けるかにかかっているかもしれないと結論する。

[A] Anthropic — How AI assistance impacts the formation of coding skills, by Judy Hanwen Shen and Alex Tamkin (2026-01-29, background)

https://www.anthropic.com/research/AI-assistance-coding-skills

• ランダム化比較試験で、おもに若手の 52 人のエンジニア (1 年以上毎週 Python を使い、Trio ライブラリは初めて) が、オンラインのコーディング環境のサイドバーの AI アシスタントの有無に分かれて 2 つの機能を作った。
  • 続くクイズの平均は AI のグループが 50%、手で書いたグループが 67% (Cohen's d = 0.738、p = 0.01) で、差はデバッグの問題で最も大きく、AI のグループは約 2 分早く終えたがその差は有意ではなかった。
• 低得点者 (40% 未満) はコードを任せきりにする (n = 4)、しだいに依存を深める (n = 4)、AI にデバッグさせる (n = 4) パターンで、高得点者 (65% 以上) はコードを生成したあとに追加で質問する (n = 2)、コードと一緒に説明を求める (n = 3)、概念の質問だけをする (n = 7) パターンだったが、著者らはこの関係を因果とは呼ばない。
• 脚注は、この設定は Claude Code のようなエージェント型の製品とは違い、著者らはそちらの技能の形成への影響はより顕著だろうと予想するとし、クイズは作業の数分後だったので長期の定着は測っていない。
• マネージャーには、エンジニアが学び続けられる意図的な設計を求め、Claude Code の Learning と Explanatory の出力スタイルや ChatGPT の Study Mode のような学習モードを挙げており、論文は arXiv 2601.20245 である。

[A] FAA (Federal Register) — Qualification, Service, and Use of Crewmembers and Aircraft Dispatchers, final rule, 78 FR 67800 (2013-11-12, background)

https://www.govinfo.gov/content/pkg/FR-2013-11-12/html/2013-26845.htm

• エッセイを裏づける: Public Law 111-216 を受けて、Part 121 の訓練に手動操縦の課目 (低速飛行、信頼できる対気速度の喪失、手動で操縦する出発と到着) と、失速、異常姿勢、バウンドした着陸からの回復を、パイロットによる監視の訓練とともに加え、2014 年 3 月 12 日に発効させた。

[A] PARC/CAST Flight Deck Automation Working Group — Operational Use of Flight Path Management Systems, final report (2013-09-08, background)

https://www.faa.gov/sites/faa.gov/files/aircraft/air_cert/design_approvals/human_factors/OUFPMS_Report.pdf

• 自動化を好む方針は手動の操縦技能を侵食し、自動化への過度な依存を招きうるというエッセイの言い回しと、2 つの勧告、つまり手動飛行の機会を定めた明確な飛行経路管理の方針 (勧告 9) と、監視、相互確認、PF と PM の作業配分を重んじる手順 (勧告 8) を裏づける。
• その Finding 4 は、パイロットがときに自動システムに頼りすぎて介入をためらうことがあり、自動飛行のモードの混乱による誤りが続いているとも加える。

[A] CAST — Safety Enhancement 30, Mode Awareness and Energy State Management Aspects of Flight Deck Automation, Revision 5 (August 2008, background)

https://www.cast-safety.org/pdf/cast_automation_aug08.pdf

• エッセイを裏づける: CAST は SE-30 のチームに作業をモードの混乱とモードアウェアネスに絞るよう指示し、報告書は自動化が航空会社の安全に大きく寄与したと認めるところから始まる。

[A] EASA — Opinion 08/2019, update of ORO.FC: evidence-based training (2019-12-18, background)

https://www.easa.europa.eu/en/document-library/opinions/opinion-082019-b

• エッセイの EBT の説明を裏づける: この考え方は学習を最大にして形式的な審査を最小にするよう設計されており、予期しない状況を認識して対処できる乗員を目指す。

[A] AWS Documentation — Troubleshoot your Application Load Balancers (as fetched on 2026-10-13)

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

• エッセイが挙げる 502 の原因を裏づける: 接続時のターゲットからの TCP RST、リクエストの処理中にターゲットが RST か FIN で接続を閉じたこと (ターゲットの keep-alive がロードバランサーのアイドルタイムアウトより短くないかを確かめる)、不正な形式の応答や無効なヘッダーである。

[A] AWS CDK API Reference — enum RemovalPolicy (as fetched on 2026-10-13)

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.RemovalPolicy.html

• 削除ポリシーは、リソースがテンプレートから外されたとき、変更で置き換えられたとき、スタックとともに削除されたときに適用され、DESTROY はリソースを物理的に破棄するので、エッセイの例を裏づけたうえで、エッセイが挙げていないテンプレートから外す場合を加える。

[B] InfoQ — Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17%, by Steef-Jan Wiggers (2026-02-23, background)

https://www.infoq.com/news/2026/02/ai-coding-skill-formation/

• Jošt、Taneski、Karakatič (マリボル大学、Applied Sciences) の 2024 年の研究を加える: 10 週間にわたり React を学ぶ 32 人の学部生で、コードの生成とデバッグに LLM を使うほど最終成績が低いという有意な負の相関があり、説明に使うことには有意な負の影響はなかった。
• この研究が示すのは自分にとって新しいことを学ぶのに AI の利用がどう響くかであって、AI がプログラマー全般にどう影響するかではない、という Tom Smykowski の反論を引く。

[B] @IT (ITmedia) — Skills may decline depending on how AI coding is used: Anthropic analyses three usage patterns (2026-03-04, in Japanese, background)

https://atmarkit.itmedia.co.jp/ait/articles/2603/04/news072.html

• 同じ試験を同じ数字 (52 人のエンジニア、50% 対 67%、有意でない約 2 分の短縮、差が最大なのはデバッグ) で伝える日本語の記事で、残りは登録会員向けである。

[B] Scientific American (from Nature) — Is AI ruining our skills? Early results are in—and they're not good, by Mariana Lenharo (2026-07-05, first published in Nature on 2026-06-18)

https://www.scientificamerican.com/article/is-ai-ruining-our-skills-early-results-are-in-and-theyre-not-good/

• ポーランドで、それぞれ 2,000 件以上の大腸内視鏡検査を経験した内視鏡医の腺腫の発見率は、AI のツールが入る前の 3 か月は 28.4% だったが、導入後の 3 か月に AI なしで行った検査では 22.4% だった (The Lancet Gastroenterology and Hepatology)。
  • 共著者の Yuichi Mori は、いまのところ技能の低下に対する確立した解決策はないと述べる。
• Tapani Rinta-Kahila の 2018 年の研究では、AI ではない自動化された会計システムを 10 年以上使った会計士は、それを取り上げられるといくつかの定型業務のやり方を忘れていた。
• Kevin Crowston (シラキュース大学) は Anthropic の結果を成績と学習の乖離と読み、人は AI から技能を借りて成果を出し、自分では技能を育てていないとする。

[B] Uwe Friedrichsen — AI and the ironies of automation, Part 1 (2025-11-21, background)

https://www.ufried.com/blog/ironies_of_ai_1/

• Lisanne Bainbridge の 1983 年の論文 Ironies of Automation をエージェント型の AI に当てはめ、監視役に回された専門家は技能と記憶を失い、後の世代はいまの監督者が頼っている技能を持たないことになるとする。
• ビジランスの研究 (Mackworth、1950) を引き、ほとんど何も起きない対象に 30 分程度を超えて有効な注意を保てる人はいないので、人はエージェントのまれな誤りを確実には捉えられず、警報やログを足しても解決しないと論じる。

[B] Uwe Friedrichsen — AI and the ironies of automation, Part 2 (2025-12-12, background)

https://www.ufried.com/blog/ironies_of_ai_2/

• 50 行や 100 行を超え、ときに数百行に及ぶエージェントの計画は揺るぎない確信とともに書かれてまれな誤りを覆い隠すので、それを見つける責任を負う人にとっておそらく最悪の UI と UX だとする。
• 訓練については、未知の故障は模擬できないので訓練は特定の対応ではなく一般的な戦略を教えなければならないという Bainbridge の指摘と、手動の介入がめったに要らない最も成功した自動システムこそ、人の運用者の訓練に最大の投資を要するかもしれないという彼女の最後の皮肉を伝える。

[B] InfoQ — Survey Finds AI-Generated Code Increases Debugging and Failure Rates and Creates a Comprehension Gap, by Sergio De Simone (2026-10-07)

https://www.infoq.com/news/2026/10/survey-complex-codebases-agents/

• AI による根本原因分析を売る Undo のために Coleman Parkes が行った調査では、おもに C と C++ のミッションクリティカルなソフトウェアを率いる 300 人のシニアのエンジニアリングリーダーが週に 16.9 時間をデバッグに、9.8 時間をコードを書くことに使い、生成したコードの 35% がチームが十分に理解しないまま本番に届いていた。
• 過去 6 か月に 93% が、ハルシネーションによる誤った根本原因の診断を少なくとも 1 回経験し (18% は月に数回)、79% はリリースのサイクルが以前より速くなっていないと答えた。

[C] Hatena Bookmark — Comments on the article (2026-10-11 to 2026-10-12, in Japanese)

https://b.hatena.ne.jp/entry/s/zenn.dev/shimitaro/articles/eb45d8d63c7bd1

• 2026-10-13 10:23 JST 時点で 159 users、36 コメント、カテゴリーはテクノロジーで、最初の公開ブックマークは公開の 6 日後の 2026-10-11 10:59 JST であり、注目コメントの多くはアナロジーに異を唱える。
  • caynan は航空の引き継ぎは運用時の話で、壊れたアプリを人手のサービスに切り替えはしないとし、rryu は手動の操縦に当たるのは仕様を見てゼロからコードを書くことだろうとし、nakex1 はパイロットは変わらない物理法則に戻れるが、コーダーが AI から引き継ぐものは量も質も違うとし、knok はより近いのは LLM のプロバイダーの障害時にエージェントなしで実装することだとし、kakei-akihiko、zentarou、kshtn はアナロジーに無理があるとみる。
• 反対側では、schoollife は定期的な訓練の時間を取るための上との議論にパイロットのアナロジーを使いたいとし、tmatsuu はトラブルシューティングの力を保とうと書き、TakamoriTarou は航空を引くなら設計保証 (DO-178/254、A-SPICE) のほうがふさわしいとしたうえで、本文について「この文章自体も結構ハルシネーションってる」と書く。

メモ

• エッセイの航空の引用は確かめられた: SAFO 13002、SAFO 17007、78 FR 67800 の規則、PARC/CAST の報告書、CAST SE-30、AC 120-123、EASA SIB 2013-05R1、EASA Opinion 08/2019 はエッセイのいうとおりのことを書いており、これらについては TakamoriTarou のハルシネーションの指摘は当たらないが、ICAO Doc 9995 と EASA NPA 2018-07 は開いていない。
  • 小さな不正確さが 2 つある: SAFO 17007 が勧めるのはあらゆる組み合わせではなく機体の装備に応じて承認された FD、AP、AT の組み合わせであり、エッセイは SIB 2013-05R1 の日付を示していないが、AC 120-123 に触れているのはその 2025 年の改訂版である。
• エッセイの身体技能と認知技能についての留保は、類似を控えめに述べすぎている: SAFO 17007 は手動飛行を身体と認知の両面のものと位置づけ、それが引く NASA の研究は身体技能が保たれて認知技能が落ちることを見つけており、異常の認識が最も難しい段階だというエッセイ自身の主張を支える。
• 基準は航空と逆向きである: SAFO 13002 と EASA は手動の練習を作業負荷の低い状況に置き、作業負荷の高い局面には自動化を残すが、エッセイは最もリスクの高い差分で人を手動の読解に戻す。
  • 借りているのはノルマではなく判断に任せるという考え方で、リスクの高い差分を手で読むことは手動飛行の練習より PM の相互確認に近いが、エッセイはこの 2 つを区別していない。
• エッセイの主張を試した計測はない: コーディングの研究は新しい技能を身につける学習者を測ったもの (Anthropic はおもに若手の 52 人で作業の数分後のクイズ、マリボル大学は 32 人の学部生) で、身についた技能の衰えやエージェントから引き継ぐ力を測ったものではなく、エッセイも演習を試した結果を報告していない。
  • Anthropic は Claude Code のようなエージェント型のツールではより強い影響を予想するが、測ってはいない。
• Friedrichsen が伝える Bainbridge は、過去の障害から作る演習に疑問を投げる: 未知の故障は模擬できないので、自分たちの障害をなぞる練習は特定の対応を鍛えるが、彼女は訓練は一般的な戦略についてのものであるべきだと論じており、エッセイの演習の一覧は両方を混ぜたままこの点に触れていない。
• ビジランスの研究 (Friedrichsen の Part 1) と NASA のマインドワンダリングの結果は、めったに失敗しないエージェントを人の PM が見張り続けられるかを問うが、手動の注意をリスクの高い差分に絞るというエッセイの答えは、どちらの情報源でも評価されていない。
• InfoQ の調査は根本原因分析のツールのベンダーが依頼したもので、回答者はおもに C と C++ のミッションクリティカルなコードベースを率いており、数字は自己申告である。
• エッセイは特定のエージェントやツールの名前を挙げず、演習はすべて AWS (CDK、CloudFormation、IAM、ALB) を使う。
• 情報源: Casner らの論文は出版社のページが 403 を返したので gwern.net の写しで読み、CACM のニュース記事 The AI Deskilling Paradox も 403 を返したので引用していない。
  • ここでの事実はどれも WebFetch や検索結果だけに頼っていない。

実践やアウトプットの提案

• エッセイの CDK の例題を 30 分のチームの演習として行う: AI のレビューが承認した removalPolicy と deletionProtection の 2 行の差分を見せてマージしてよいかと理由を問えば、レビュアーの考えがスタックの削除だけでなく置き換えやテンプレートからの削除まで及ぶかがわかる。
• 最近のポストモーテムを 1 つ選んで匿名化し、小さな再現環境に作り直し、エージェントの利用は認めつつ結論はすべてログか設定で裏づけるという条件でペアに原因を探らせると、採点しなくてもチームがどの証拠をまだ自分で見つけられるかがわかる。
• ノルマの代わりにリスクに応じた手動の読解をレビューのルールに書く: AI のレビューのあとでも人が 1 行ずつ読む差分の種類 (IAM ポリシー、状態を持つリソースを削除したり置き換えたりする IaC、ネットワークの構成) を挙げ、CODEOWNERS かパスに応じた必須のレビュアーで強制し、毎週の発生件数を数える。
• 自動化に驚かされた事例 (誤った修正、レビューの見逃し、AI が書いたテストをすり抜けた障害) を演習の素材として記録し、同僚が AI の承認済みの差分に種類を告げずに欠陥を仕込む抜き打ちの演習を加えて、決まった答えのリハーサルではなく Bainbridge のいう一般的な戦略を試す。
• 新しいライブラリを学ぶ若手については、Anthropic の研究の関わり方のパターン (概念の質問や説明を求める使い方と、任せきりの使い方) を比べ、その記事が挙げる Learning と Explanatory の出力スタイルを試し、あとで短いクイズで理解を確かめる。
• アウトプット: 航空の文書をチームの実践に対応させた 1 ページのチームのメモに、メモの節の 3 つの留保 (手動飛行の認知の側面、逆向きのリスクの基準、未知の故障) を添える。

6. 🧩 Claude Managed Agents に dynamic workflows がパブリックベータで入り、セッションのエージェントが書いたプログラムが Anthropic のサーバー上で 1 回の実行あたり最大 1,000 のエージェントを同時に 64 まで段階的に動かし、Anthropic はトークンの消費が多くなりうるので範囲を絞ったタスクから始めるよう勧めた

• 選定 / 影響度 1 / 将来性 2 / 注目度 1 / 起点 10-09、期間前の出来事 / 種別: リリース / 領域: エージェント開発、API・クラウド。
• 候補になったフィード項目:
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (@ClaudeDevs を伝え、リードのエージェントが段階的な計画を書いて 1 回の実行あたり最大 1,000 のエージェントに展開し、multiagent_20261001 で有効にでき、トークンの消費が多くなりうるので範囲を絞ったタスクから始めるよう勧めるとする)
• 起点: リリースノートはベータの開始を 10-09 とし、前回の実行は claude-platform-release-notes から載せて 1 / 2 / 0 で見送ったが、今回の実行で ainews が再び運んだ。

前回からの継続

• 2026-10-10 のトピック 9 は、検索でもリリースノートの外での議論が見つからなかったので、リリースノートの項目だけでこのリリースを 1 / 2 / 0 で見送った。
• その後、取り上げる記事が現れた: AINews (10-10) がコストの注意を含む Anthropic の X の投稿を伝え、The Decoder (10-09) と MIXED (10-11) が英語で、XenoSpectrum (10-10) が日本語で書き、実務者もブログで扱った。
  • その項目以降に新しくわかったのは、ドキュメントの上限 (同時に 64 スレッド、1 回の実行で 1,000 エージェント、24 時間の有効期間、セッションあたり 10 の開いた実行)、課金 (トークンと、実行中のセッション時間 1 時間あたり $0.08 のほかに独自の価格はない)、仕込んだ 70 個のバグのうちワークフローは 66 個、単一のエージェントは 14〜27 個を見つけたという Anthropic の主張である。

収集した情報

[A] Anthropic — Claude Platform release notes, entry of October 9, 2026 (2026-10-09)

https://platform.claude.com/docs/en/release-notes/overview

• Claude Managed Agents のエージェントが dynamic workflows を使えるようになり、既存の managed-agents-2026-04-01 のベータヘッダーのもとでベータとして提供される。
• 数百の文書のレビューのような多くの部分からなる作業では、エージェントがワークフロー、つまり多数のエージェントを段階的に動かして結果をまとめるプログラムを書き、サーバーがそれを workflow run としてバックグラウンドで実行する。
• エージェントの multiagent フィールドを {"type": "multiagent_20261001", "workflows": {"type": "enabled"}} にして有効にし、いつ実行を始めるかはシステムプロンプトで伝えて誘導し、進み具合はセッションのイベントストリームの workflow_run.* のイベントで追う。
• 以前の項目から系譜がたどれる: マルチエージェントのオーケストレーション (サブエージェント) は 2026-05-06 に同じヘッダーのもとでパブリックベータになり、2026-05-29 に Claude Platform on AWS に届き、セッション向けの advisor のモデルは 2026-08-07 に入り、Claude Code の Workflows は 2026-05-28 にリサーチプレビューとして載った。
  • Managed Agents の dynamic workflows に触れた以前の項目はないので、この機能はいきなりベータで出た。

[A] Claude Platform Docs — Multiagent orchestration (as fetched on 2026-10-13)

https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration

• 型 multiagent_20261001 は 3 つの設定、つまり既定で有効の subagents と workflows、既定で無効の advisor をまとめる。
• サブエージェントではエージェントがターンごとに委任し、持続するスレッドに追加の指示を送れて、深さは 1 段、子のスレッドは同時に最大 25 であり、ワークフローでは Claude が自分では直接関わらずにエージェントを動かすプログラムを書くので、主スレッドはユーザーとの対話と実行の確認のために空いたままになる。
• ドキュメントは、複数のエージェントが要るたいていの作業、つまり多くの部分からなる作業、並列の作業、早く終わらせたい長い作業 (監査、移行、深い調査、照合など) にワークフローを勧める。
• 実行を始める API の呼び出しはなく、user.message からいつ始めるかを決めるのはエージェントで、それを誘導できるのはメッセージかシステムプロンプトだけである。
  • 許可のポリシーは実行の中のエージェントが呼ぶツールに適用され、実行を始めることには適用されない。
• 実行の中のエージェントは、ワークフローが定義するインラインのエージェント (ワークフローが書くシステムプロンプトとセッションのエージェントのモデルを使う) か、workflows.predefined_agents に挙げた定義済みのエージェント (最大 20 で、subagents.predefined_agents とは別の一覧) である。
  • 実行の一部のエージェントを別のモデルで動かすには、それをエージェントとして作ってそこに挙げる必要がある。
• 挙げたエージェントは作成か更新の時点で解決したバージョンに固定され、自身は multiagent を設定できず、リードのエージェントと同じ inference_geo をすべてが固定するか、どれも固定しないかのどちらかでなければならず、{"type": "self"} はエージェント自身の複製を挙げる。
• インラインのエージェントはセッションのエージェントの MCP サーバーとツールを受け継ぎ、vault の認証情報はすべてのスレッドに適用されるので、実行のアクセスを絞るには workflows の下で inline_agents を {"type": "disabled"} にして、より狭いエージェントを挙げる。
• すべてのエージェントがセッションのサンドボックス、ファイル、vault の認証情報を共有し、それぞれはコンテキストを分けたセッションのスレッドで働く。
• サンプルのシステムプロンプトは契約書のレビュー役に、数件を超える契約書のレビューを頼まれたら実行を始め、1〜2 件なら自分でレビューするよう指示し、追記の案として分け方 (契約書ごとに 1 エージェント、その後で全件を見直す 2 つ目のエージェント)、失敗の扱い (読めなかった契約書を対象外として挙げる)、1 時間の時間制限を示す。
• ツール名の接頭辞 ant__ はいまでは予約されており、ant__… という名前のカスタムツールを持つエージェントは、ワークフローを有効にするのと同じ更新でツールの名前を変えるまで、更新も新しいセッションもすべて 400 のエラーで失敗する。
• 古い coordinator 型 (サブエージェントと advisor だけ) から移ると multiagent のブロック全体が置き換わるので、workflows と subagents.inline_agents を省くと両方が有効になり、サブエージェントの一覧を省くと空になる。
• セッションは作成時に設定を写し取り、{"type": "disabled"} でワークフローが止まり、既定が有効なので null を送ると有効に戻る。

[A] Claude Platform Docs — Workflow runs (as fetched on 2026-10-13)

https://platform.claude.com/docs/en/managed-agents/workflow-runs

• 実行は、実行、任意の名前付きのフェーズ、エージェントのスレッドの 3 層からなり、プログラムはその中でエージェントを展開し、あるエージェントの結果を別のエージェントに渡し、レビューが通るか回数が尽きるまで手順を繰り返し、失敗したエージェントを処理するか上に伝える。
  • 結果はセッションのエージェントではなくプログラムに届き、セッションのエージェントは実行が終わったときに、実行が何をしたかを読むターンを得る。
• 上限: 1 回の実行で同時に働くスレッドは 64 (API が保証する値ではない)、実行の全期間で起動するエージェントは 1,000 で、超えると実行は thread_limit_error で終わり、有効期間は既定で 24 時間 (エージェントが短くできる)、セッションあたりの開いた実行は既定で 10 (アイドルのものを含む) である。
  • 失敗したエージェントを新しいスレッドで再試行すると 1,000 スレッドを超えることがあり、サーバーには列挙されていないほかの上限もあり、1 つのセッションが全期間で始められる実行の数に制限はない。
• セッションのストリームのイベントは、workflow_run.created (wrun_… の ID、名前、説明、宣言した phases を持ち、どれもモデルが書いた文字列)、workflow_run.status_running、workflow_run.status_idle、workflow_run.phase_started と workflow_run.phase_ended、result を持つ workflow_run.status_ended、workflow_run.error である。
  • 実行のイベントは webhook を起動せず、実行を一覧するエンドポイントもないので、クライアントは再接続したあと、types のフィルターで過去のイベントを一覧して実行の状態を組み立て直す。
• 結果が completed でもワークフローが終わったという意味でしかなく、スレッドでの作業が失敗したりスレッドを作れなかったりしても completed で終わることがあり、エラーの結果は timeout_error、program_error、thread_limit_error、unknown_error である。
• 実行は入れ子にならず、実行を始められるのは主スレッドのエージェントだけで、実行のスレッドは子スレッド 25 の上限の対象外だが、エージェントはそれらに追加の指示を送れず、サーバーは実行の終わりまでに各スレッドをアーカイブする。
• ワークフローのコード、実行を始めて管理するツールの呼び出し、各スレッドがプログラムに返すものは見えず、ヒントとして、実行が終わってセッションがアイドルになってから、別の実行を始めずにワークフローを一字一句そのまま表示するようエージェントに頼むよう勧める。
• 実行を終わらせるクライアントのイベントはない: user.interrupt はエージェントのターンを止めるが実行は一時停止するか続くので、止めるには実行を止めるよう頼む user.message を送る必要があり、実行が開いているあいだにセッションをアーカイブや削除したり、その agent を更新したりすると、workflow_run_open の 400 が返ることがある。
• 実行が動いているあいだは、どのスレッドも働いていなくてもセッションは running のままで、作業が終わったと言えるのは、見えたすべての実行に workflow_run.status_ended が届き、そのあと end_turn の session.status_idle が届いたときである。
• 実行そのものに価格はなく、そのエージェントのトークンは各モデルの単価で課金されてセッションの予算に数えられ、1 つの実行の使用量はその workflow_run_id を持つスレッドの usage の合計である。
• 予算に達すると開いた実行はすべて一時停止し、働いているスレッドごとに 1 リクエストまで予算を超えうるが、一時停止中も実行の有効期間は減り続けるので、一時停止したまま放置した実行は timeout_error で終わることがある。
• 実行のモデルへのリクエストはほかのトラフィックとともに組織の Messages API のレート制限に数えられ、同じ作業に複数のスレッドが作られることがあるので、ドキュメントは 2 回呼ばれても安全なツールを求める。
• 例は 300 の契約書のうち支配権変更の条項を持つものを問い、フェーズ Read the contracts と Reconcile the findings を持つ実行が、41 件にあるという答えで終わる様子を示す (計測ではなく例示)。

[A] Claude Platform Docs — Session budgets and the Claude Managed Agents section of Pricing (as fetched on 2026-10-13)

https://platform.claude.com/docs/en/managed-agents/budgets / https://platform.claude.com/docs/en/about-claude/pricing#claude-managed-agents-pricing

• Managed Agents はトークンを各モデルの単価で、プロンプトキャッシュの倍率、1,000 回の Web 検索あたり $10、inference_geo が "us" のときの 1.1 倍とともに課金し、加えてセッションの実行時間を 1 時間あたり $0.08 で、セッションが running のあいだだけミリ秒単位で計る。
  • Batch API の割引は適用されず、Managed Agents はパートナーが運営するクラウドのプラットフォームでは使えない。
• 予算 {"type": "limit", "max_list_cost": {"amount": "<US cents>", "currency": "USD"}} はセッションの作成時にだけ設定でき、交渉した価格ではなく公開の定価でモデルのリクエストのあいだに強制され、マルチエージェントのセッションのすべてのスレッドが共有し、スレッドごとの上限はない。
• セッション単位の active_seconds は並行するスレッドの重なった活動を 1 回と数えるので、並列のスレッドで実行時間の課金が膨らむことはなく、スレッドごとの list_cost は実行時間を含まない。
• エージェント、どちらかの定義済みの一覧のエージェント、advisor のいずれかが公開の定価のないモデルを使うと、予算付きのセッションの作成は 400 のエラーで失敗する。

[A] Claude (@ClaudeDevs) on X — launch thread on dynamic workflows in Claude Managed Agents (2026-10-09)

https://x.com/ClaudeDevs/status/2108591328732856655

• 最初の投稿は、パブリックベータを最も野心的な作業のための新しい種類のマルチエージェントのオーケストレーションとして示し、リードのエージェントが多数のエージェントにまたがって段階的に動く計画を書き、最後に結果をまとめるとする。
• 2 つ目の投稿は社内のテストを報告する: 116k 行のコードベースに 70 個のバグを仕込むと、単一のエージェントは 3 回の実行で 14、15、27 個を見つけ、ワークフローは 3 回とも 66 個を見つけた。
  • モデル、effort のレベル、使ったトークン、誤検知の数は書いていない。
• 3 つ目の投稿は、multiagent_20261001 を設定して Claude にワークフローの実行を頼めば、Claude が計画を書き、1 回の実行で最大 1,000 のエージェントを動かすとする。
• 4 つ目の投稿は、dynamic workflows は強力だがトークンを大量に使いうるので、範囲を絞ったタスクから始めるよう勧める。
  • そこから段階的にタスクの複雑さを上げるよう助言し、Claude Code の /claude-api managed-agents-onboard bug-hunter と、platform.claude.com/agent-quickstart のテンプレートを案内する。

[A] Anthropic — Introducing dynamic workflows in Claude Code (2026-05-28, since updated) and the Claude Code docs page Orchestrate subagents at scale with dynamic workflows (as fetched on 2026-10-13)

https://claude.com/blog/introducing-dynamic-workflows-in-claude-code / https://code.claude.com/docs/en/workflows

• 30 日より前の背景: Claude Code の dynamic workflows は 2026-05-28 に出ており、投稿はいまでは冒頭に dynamic workflows が一般提供になったという更新の注記を置き、ドキュメントはすべての有料プラン、Anthropic API、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry で使えるとする。
• そこではワークフローはローカルの実行環境が動かす JavaScript のスクリプト (agent()、pipeline()、parallel()) で、~/.claude/projects/ の下のファイルに書かれ、読む、差分を見る、編集する、再実行する、.claude/workflows/ にコマンドとして保存することができ、最初に起動するワークフローは確認を求める。
• 上限も違い、同時に動くエージェントは既定で 16 (CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS で 1〜256)、parallel() か pipeline() の 1 回の呼び出しあたり 4,096 項目、1 回の実行あたりのエージェントは同じ 1,000 である。
• 費用は実行中に示され、/workflows は各エージェントのトークンの使用量を表示し、25 を超えるエージェントか見込みで 150 万トークンを超えると助言としての Large workflow の警告が出て、発表の投稿も範囲を絞ったタスクから始めるよう同じ助言をしていた。

[A] Anthropic — When to use multi-agent systems (and when not to) (2026-01-23) and How we built our multi-agent research system (2025-06-13)

https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them / https://www.anthropic.com/engineering/multi-agent-research-system

• オーケストレーションのドキュメントからリンクされたコストの背景: Anthropic のテストでは、マルチエージェントの実装は同等のタスクで単一のエージェントの 3〜10 倍のトークンを使うのが普通で (2026 年)、2025 年の調査システムはマルチエージェントのシステムをチャットの約 15 倍のトークンとした。
• 2025 年の投稿は、文脈の共有が要る領域やエージェント間の依存の多い領域は向かず、たいていのコーディングのタスクは調査より並列化しにくいとも加える。

[B] AINews (Latent Space) — [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch (2026-10-10)

https://www.latent.space/p/ainews-typesafejev-at-100m-arr-75b

• Multi-Agent Orchestration and Coding Tools の節の先頭でこのリリースを扱うが、@ClaudeDevs の投稿から取っただけで何も加えておらず、Vals AI のエージェントのチームについての調査を同じ節に置く。

[B] The Decoder — Anthropic's Claude can now orchestrate up to 1,000 AI agents in parallel through dynamic workflows, by Matthias Bastian (2026-10-09)

https://the-decoder.com/anthropics-claude-can-now-orchestrate-up-to-1000-ai-agents-in-parallel-through-dynamic-workflows/

• 見出しと本文は 1 回の実行で最大 1,000 のエージェントが並列に動くとしており、ドキュメントと食い違う。
• 費用対効果には議論の余地があるとし、Anthropic のバグのテストを、OpenAI のシニアエンジニアがエージェントの群れをトークンの大きな無駄と呼んだという同誌の以前の報道と並べ、タスクの種類をまたいだ効果はまだわからないとする。

[B] MIXED — Claude now writes its own programs to run up to 1,000 agents, and starts them itself, by Shane S. Ellison (2026-10-11)

https://mixed-news.com/en/claude-managed-agents-dynamic-workflows-1000-agents-permission-policies/

• 視点は統制で、流れの中に開発者に起動の承認を求める場面はなく、使えるのはメッセージかシステムプロンプトでの説得だけで、許可のポリシーは群れのツールは統制しても群れを立ち上げることは統制しないとする。
• 予算はおおよそのブレーキで、行き過ぎの幅を抑えているのは Anthropic が公表する数字ではなく、働く 64 のスレッドだと読む。

[B] Vals AI on X — Do agent teams pay off? (2026-10-09)

https://x.com/ValsAI/status/2108608719420600709

• dynamic workflows ではなくエージェントのチーム一般のテストで、Vibe Code Bench では GPT-6 Sol と Claude Opus 5.5 のチームは単一のエージェントの 1.8〜5.1 倍の費用がかかり、有意に改善したのは 4 つの比較のうち 1 つ (medium の effort の Sol で 7.3 ポイント) だけだった。
• Sol の単一のエージェントを medium から max の effort に上げると 11.4 ポイント伸び、max の effort にチームを重ねても 1.4 (有意でない) しか加わらず、Opus のチームは max の effort で最大 2.3 倍の時間がかかった。

[C] XenoSpectrum — Claude assigns work to up to 1,000 AIs as a cloud version of workflows enters public beta, by Y Kobayashi (2026-10-10, in Japanese)

https://xenospectrum.com/claude-managed-agents-dynamic-workflows/

• 2 つの機能を区別し、05-28 の Claude Code の機能は名前が同じでも実行環境と上限が違うとし、1,000 は累計の上限で同時は 64 スレッドなので「1,000体のエージェントが一斉に動くわけではなく、処理速度が単純に1,000倍になるという意味でもない」と書く。
• バグのテストを発見率に直し (単一のエージェントは 20.0〜38.6%、ワークフローは 3 回とも 94.3%)、毎回同じ 66 個だったのか、トークンの予算をそろえたのか、誤検知、修正、費用、時間、ほかのコードベースでの成果など、数字からは分からないことを挙げる。
• ファイルを共有しても複数のエージェントが同じファイルを書き換えたときの競合は防げないので、コードの変更ではエージェントごとに担当するファイルと範囲を明確に分ける必要があると注意する。
• 最初の試行では対象を絞り、同じ資料と評価基準で単一のエージェントと比べ、調査できた範囲、正確さ、見落とし、未処理の件数、費用を記録するよう勧める。
  • 英語版は https://xenospectrum.com/en/claude-managed-agents-dynamic-workflows/ にある。

[C] Vanja Petreski — Dynamic Workflows Move to the Server (2026-10-09)

https://vanja.io/managed-agents-dynamic-workflows/

• 視点は誰が操縦桿を握るかで、Claude Code ではスクリプトが自分のマシンで動いて開く、編集する、再実行することができるのに対し、Managed Agents はそれを、予算を付けて観測し、頼んで止めるサーバー側のワークロードにするとする。
• 動いている実行があるとセッションは running のままなので、その状態で 24 時間たつとトークンとは別にセッションあたり $1.92 かかり、64 スレッドでは予算の超過が実行あたり 64 リクエストに達することがあり、開いた実行が複数あればさらに増える。
• 製品の停止ボタンが user.interrupt を送るだけならバックグラウンドの作業は続くので、エージェントにメッセージを送って workflow_run.status_ended を待つべきだとする。
• 経験則として、独立した作業の単位と、その結果をまとめる規則の両方を言えるときだけ実行を始め、そうでなければまず単一のエージェントでタスクを試すとする。

[C] Licence (note) — New feature: dynamic workflows in Claude Managed Agents, set up in one field (2026-10-10, in Japanese)

https://note.com/licence/n/na9c68f21f310

• リリースノートだけから書いた手順で、ベータヘッダーと multiagent フィールドを扱う httpx のコードと、実行を始める条件 (数十件以上、事前に数えられる、互いに独立、1 つの成果物にまとめる) と始めない条件の両方を書いた日本語のシステムプロンプトの断片を載せる。
• ヘッダー managed-agents-2026-04-01 と型 multiagent_20261001 の取り違えを警告するが、「既存エージェントを持っている場合、変更点は multiagent の1フィールド追加だけです」と書いており、ドキュメントにある予約された接頭辞 ant__ と coordinator からの移行の規則を見落としている。

[C] ひまなねこのひまつぶし (Hatena Blog) — Dynamic workflows added to Claude's Managed Agents: what they automate, the beta setup and caveats (2026-10-10, in Japanese)

https://himanekoblog.hatenablog.com/entry/2026/10/10/093034

• ドキュメントの上限には触れずにリリースノートの事実を裏づけ、これは Claude のチャットの機能ではなく Claude Platform の開発者向けの機能だと強調し、社内のデータを入れる前に架空の議事録 10 件から始めるとする。

[C] ToolNavs — Dynamic workflows in Claude Managed Agents enter public beta, orchestrating up to 1,000 agents in one run (2026-10-10, in Japanese)

https://toolnavs.com/ja/article/2446-claude-managed-agents-dong-tai-gong-zuo-liu-jin-ru-gong-kai-ce-shi-dan-ci-zui-du

• 「Claude Managed Agentsのマルチエージェント編成は、これまで研究プレビューへの個別申請が必要だった」と主張するが、リリースノート (2026-05-06 から標準のヘッダーのもとでパブリックベータ) と食い違う。

[C] TILNOTE — Dynamic workflows in Claude Managed Agents: 1,000-way parallel orchestration beyond a single model's limits (2026-10-10, in Korean)

https://tilnote.io/pages/6aca0e771e0f9a6cd00dc818

• 2 つの製品を混同して、Managed Agents の機能に Claude Code の発表時の条件 (Claude Code のプラン、Bedrock、Vertex AI、Foundry でのリサーチプレビュー、ultracode) を当てはめ、ここでは確かめていないが、Managed Agents は Zero Data Retention と HIPAA BAA の対象外だと主張する。

[C] X — replies to the @ClaudeDevs launch thread (2026-10-09)

https://x.com/ClaudeDevs/status/2108591334449684643

• ある利用者 (@truffle) は、ワークフローは claude -p の呼び出しを並べたスクリプトよりトークンの効率がずっと悪かったので避けているとして変わったのかを尋ね、別の利用者は 1 つのタスクに 1,000 のエージェントを使うことが個人にも手の届くものになったと書き、いくつかの返信は週ごとの上限のリセットを求めるが、それはこの API の機能ではなくサブスクリプションの話である。

メモ

• 同時実行数が誤って伝えられている: The Decoder の見出しは 1,000 のエージェントが並列に動くとするが、ドキュメントは 1 回の実行で同時に働くスレッドを 64 (保証なし)、実行の全期間のエージェントを 1,000 とする。
  • XenoSpectrum と vanja.io はこの区別を正しく書いており、1 回の実行あたり最大 1,000 のエージェントという AINews の表現も正確である。
• 2 つの製品が同じ名前で、取り上げる記事が混同している。
  • 更新された発表の投稿によれば Claude Code の dynamic workflows はいまでは一般提供だが、05-28 のプラットフォームのリリースノートは、発表時の状態であるリサーチプレビューとして載せている。
  • Claude Code は読めるローカルのスクリプトを動かし、既定で同時 16 のエージェントで、初回に確認を求めるのに対し、Managed Agents はプログラムを Anthropic のサーバーで動かし、同時 64 スレッドを許し、コードを見せず、エージェントが承認なしに実行を始められる。
  • TILNOTE は Claude Code の発表時の条件を Managed Agents のものとしている。
• それ以前の限定の段階は記録にない: リリースノートに Managed Agents の dynamic workflows のリサーチプレビューはなく、マルチエージェントのオーケストレーションは 05-06 からパブリックベータなので、申請制のプレビューだったという ToolNavs の主張には裏づけがなく、すべての利用者に開いたという言い方も、対象を広げたのではなく新しく出た変更を誇張している。
• 70 個中 66 個という結果は X の投稿での Anthropic 自身の主張で、詳しい解説の記事、モデル、effort のレベル、トークンの予算、誤検知率は示されておらず、独立した再現も見つからなかった。
  • Anthropic 自身の指針はマルチエージェントのトークンの使用を単一のエージェントの 3〜10 倍とし、Vals AI のエージェントのチームの調査は 1.8〜5.1 倍の費用で 4 つの比較のうち有意な改善は 1 つだったが、こちらは dynamic workflows を試したものではない。
• multiagent_20261001 ではワークフローは既定で有効で、workflows を省いた coordinator からの移行でもそうなり、実行を始めることは許可のポリシーで止められないので、いったん有効にすればおもなブレーキはシステムプロンプトと、セッションの作成時に設定する予算になり、MIXED と vanja.io はどちらもこの点を強調する。
• 未解決の問い: Claude Platform on AWS で dynamic workflows が使えるか (マルチエージェントのオーケストレーションは 05-29 から使えるが、10-09 の項目は触れていない)、どのモデルが実行を率いられるか、列挙されていないサーバーの上限は何か、64 スレッドという数字がベータのあいだに変わるか。
• 較正のための反応の数字: X の最初の投稿は取得時点で 977.1K 回の表示と 427 の返信、バグのテストの投稿は 82.6K 回の表示だったが、これらは注目度に数えず、オーケストレーションのドキュメントの Hacker News への投稿 (10-10) は 2 ポイントでコメントなし、日本語の投稿は取得時点ではてなブックマーク 0 users だった。
• The Decoder と MIXED は同じ発行元 Deep Content GmbH の別の媒体なので、2 つの独立した記事としての重みは弱まる。
• WebFetch だけに頼るもの: 実行が終わったあとにワークフローを一字一句表示するようエージェントに頼むというドキュメントのヒント (ページのキャッシュはその注記を落とした) で、vanja.io の保存したページが同じ文言で引いている。
• 読んでいないもの: FourWeekMBA (403)、検索で見つかったアグリゲーターの投稿 (cellcog.ai、AlphaSignal、byteiota、explainx.ai、muddaser.com) は開いておらず、platform.claude.com/agent-quickstart はサインインのページしか示さないので、投稿がいうテンプレートと /claude-api managed-agents-onboard bug-hunter は確かめていない。

実践やアウトプットの提案

• バグのテストを小さく再現する: 1 万〜2 万行のリポジトリに既知のバグを 10〜20 個仕込み、予算付きのセッションで単一のエージェントとワークフローをそれぞれ 3 回動かし、見つけたバグ、見逃したバグ、誤検知、トークン、list_cost、実行時間を記録する。
  • Anthropic が報告する差がチームのコードでも成り立つか、成り立つならどのくらいのコストの倍率でかを確かめられる。
• ドキュメントのサンプルをもとに最小の実行トラッカーを作る: workflow_run.* のイベントを追い、すべての実行が終わって end_turn のアイドルが続いてから作業を完了とみなし、再接続のあとは types のフィルターでイベントを一覧して状態を組み立て直し、スレッドの usage から実行ごとの費用を計算する。
  • 失敗する文書 1 つ、2 回呼ばれるツール 1 つ、割り込み 1 回、メッセージでの停止 1 回、予算による一時停止 1 回を試し、アプリケーションが実際に何を観測できるかを見る。
• どのエージェントでも有効にする前に、workflows を明示的に設定し (展開を望まないところ、とくに coordinator から移したエージェントでは無効にする)、始める条件と始めない条件の両方をシステムプロンプトに書き、Haiku 5.5 で動く定義済みのエージェントのような安いものを workflows.predefined_agents に挙げ、MCP のアクセスを絞るべきところでは inline_agents を止め、セッションは予算付きで作る。
• ルートハンドラーにまたがる認証チェックの漏れの調査のような同じ監査を、Claude Code のワークフローと Managed Agents の実行の両方で行い、スクリプトの見え方、同時実行数、承認、トークンの使用、経過時間を比べて、どの作業を開発者のマシンに置き、どれをサーバー側のジョブにするかを決める。
• アウトプット: サブエージェント、Managed Agents のワークフロー、Claude Code のワークフロー、自作の claude -p の呼び出しのスクリプトを、上限、課金、統制の点、実行を誰が止められるかで並べた 1 ページのチーム向けの判断表。

7. 🧭 Andrej Karpathy が、LLM の能力についての理解の差が漏斗のように広がっていると論じ、LLM をほとんど使ったことのない約 60 億人から、数学とコードにフロンティアモデルを使う約 2,000 万人の専門家、ラボの中でフロンティアのシステムに触れられる約 5,000 人までを並べた

• 見送り / 影響度 0 / 将来性 1 / 注目度 2 / 起点 10-11 / 種別: 論考 / 領域: モデル。
• 候補になったフィード項目:
  • hn-llm 10-12 The gap in shared understanding of LLM capability is widening — Hacker News で 680 ポイント、990 コメント (取得時点)
• 見送りの理由: 新しいデータのない概算による投稿で、漏斗を、人が持ち込む問題の大きさ、検証可能な報酬での強化学習が残す能力のでこぼこ (jaggedness)、アクセスの差で説明しており、GenAI のエンジニアが作るものを何も変えない。

8. 🔍 TechnoEdge の解説記事が、コーディングエージェントに MCP か CLI でソースコード非公開のアプリを解析させて似た機能を作り直させる、4 月公開の MIT ライセンスのツール REA (Reverse Engineer Anything、GitHub のスター約 15 万 8,000) を改めて取り上げた

• 見送り / 影響度 0 / 将来性 1 / 注目度 2 / 起点 04-14、背景 / 種別: リリース / 領域: コーディングエージェント、セキュリティ・安全性。
• 候補になったフィード項目:
  • hatena-llm 10-12 なんでもリバースエンジニアリング。ソースコード非公開のアプリをAIに解析させ、類似機能を作らせるオープンソースツール「REA」（生成AIクローズアップ） — はてなブックマーク 377 users (取得時点)
• 見送りの理由: リポジトリは 2026-04-14 に作られ、最近のリリースは定例のもの (10-08 の 6.0.0 は MCP のファイルシステムの入力にホストの絶対パスを求めるようになり、6.4.0 は 10-11) なので直近 30 日に起点にできるものがなく、解説記事も独自の検証を加えていない。

9. 👥 Vals AI が GPT-6 Sol と Claude Opus 5.5 を Vibe Code Bench で単体と、リードと最大 5 つのサブエージェントからなるチームとで走らせ、チームは費用が 1.8〜5.1 倍かかり、有意にスコアが上がったのは medium の effort の Sol のチームの 7.3 ポイントだけだった

• 見送り / 影響度 1 / 将来性 1 / 注目度 1 / 起点 10-09 / 種別: 研究・評価 / 領域: コーディングエージェント、評価・運用。
• 候補になったフィード項目:
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch — Vals AI の X の投稿を伝え、Opus のリードは max の effort で 1 アプリあたり約 6.8 のサブエージェントを順に波のように送り出し、サブエージェントのツール呼び出しは約 1,140 回に及んだが、有意な改善はなかったとする
• 見送りの理由: Vals AI のケーススタディは、50 のフルスタックの Web アプリからなる 1 つのベンチマークを構成ごとの対応のある t 検定で扱ったもので、論じたのは AINews と検索で見つかった二次的な要約 1 本だけであり、最高の 93.2% を出した Opus 5.5 の max の effort のチームは 1 アプリあたり $122 と 174.1 分かかり、単一のエージェントは 89.8% で $23.77、74.7 分だった。

10. 🧵 開発の目標を、それぞれのブランチで並行して動く Claude Code のセッションに分けるベータ Claude Code Projects が、ウェイトリストに登録したすべての Pro と Max のユーザーに開放された

• 見送り / 影響度 1 / 将来性 1 / 注目度 1 / 起点 10-09 / 種別: リリース / 領域: コーディングエージェント。
• 候補になったフィード項目:
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch — @ClaudeDevs を伝え、ウェイトリストの Pro と Max のユーザーを全員受け入れ、各プロジェクトはタスクを並行するスレッドとして動かすとし、ある利用者の投稿はセッションをローカルでも動かせるようになったとする
• 見送りの理由: 09-17 に発表したベータの対象を広げたもので、いまも GitHub のリポジトリを持つ Pro と Max に限られ、各スレッドは使用量の上限に対して完全な Claude Code のセッションとして数えられ、論じたのはアグリゲーターだけであり、10-10 にドキュメントを読んだ記事はローカルのスレッドをまだ予定としていて、AINews が伝える投稿と食い違う。

11. 🪜 StepFun が、総パラメータ 600B、アクティブ 27B の MoE モデルで 100 万トークンのコンテキストと画像入力を備えた Step 5 Preview を、10 月 15 日予定のオープンウェイトに先立って OpenRouter に出した

• 見送り / 影響度 1 / 将来性 1 / 注目度 1 / 起点 10-08 / 種別: リリース / 領域: モデル。
• 候補になったフィード項目:
  • ainews 10-10 [AINews] TypeSafe/Jev at >$100M ARR, $7.5B valuation 3 weeks after launch — Hermes Index で GPT-6 Luna と並ぶ 33.89、Nous Portal で 1 週間無料、最大出力は 64K トークンに訂正とし、OpenRouter の掲載は 10-08 に Hacker News で 147 ポイント、38 コメントを集めた
• 見送りの理由: スコアがアグリゲーターの指数 1 つと利用のランキングしかないプレビューで、重みはまだ出ておらず、10-15 の公開は次の実行の期間に入る。

12. 📎 その他の単発項目

• 見送り / 1 件ずつ採点し、影響度 0〜1、将来性 0〜1、注目度 0〜2。
• aws-whats-new 10-13 Amazon Bedrock AgentCore の短期メモリの従量課金: イベントあたりの定額をやめ、取り込みは 1 GB あたり $1.00、取得は 1 GB あたり $0.20、保存は 1 GB・月あたり $0.10 とし、課金されるイベントのサイズは最小 12 KB、最大 64 KB で、長期メモリの料金は変わらない (1 / 1 / 0)。
• aws-ml-blog-bedrock 10-13 シンガポール、ジャカルタ、タイ、マレーシア、台北からのグローバルなクロスリージョン推論で使う Bedrock の GPT-6 Sol、Luna、Astra で、Converse と OpenAI 互換の API、IAM と SCP の権限、クォータの見積もりを扱う (0 / 0 / 0、送信元のリージョンが増えただけ)。
• github-changelog-copilot 10-11 Copilot for JetBrains: エンタープライズが管理する既定のモデル、Copilot と Claude の MCP サーバーの自動起動を止める設定、診断に対する Fix のアクション、JetBrains IDE 2025.1 のサポート終了 (1 / 0 / 0)。
• classmethod-claude-code 10-10 Claude Code v2.1.296: サブエージェント向けの autoCompactWindow と Read の allow_large のオプションを Opus 5.5 で試し、オプションなしの Read は 3,001 行のうち 732 行を返した (1 / 1 / 0、2026-10-10 のトピック 6 の続報)、10-12 AWS MCP Server を通じて複数の AWS アカウントを読む Claude Code (1 / 0 / 0)。
• zenn-trending 10-10 uhyo による Haiku 5.5 の React の習熟度のベンチマーク: effort high で 83.82 と、13 の仕様のうち 10 で Sonnet 5.5 high (81.08) を上回り、max では 85.56 で、26 の条件の中で 12 位と 10 位 (1 / 0 / 0、2026-10-08 のトピック 1 の続報、14 いいね)。
• zenn-trending 10-12 Claude Desktop と Bedrock 上の Claude Code の利用者ごとのコストのダッシュボード: CUR 2.0 の Data Exports の呼び出し元 ID (IAM プリンシパル) のオプション line_item_iam_principal、Athena、Amazon Quick で作った AWS のソリューションアーキテクトによるもの (1 / 1 / 0、2 いいね)、Transformers.js で処理を追い 1,000 枚の MS-COCO の画像で測った CLIP の画像埋め込み (0 / 0 / 0)。
• hatena-llm 10-10 TTS に日本語を正しく読ませることについての松尾研究所の記事の前編で、ピッチアクセントから G2P のフロントエンドまでを扱う (0 / 1 / 2、はてなブックマーク 103 users、09-28 公開、LLM のアプリケーションではなく音声のフロントエンド)、10-11 自己改善するソフトウェアは避けられないという Boris Tane の主張で、エージェントが本番のシグナルを読み、人が仲介役 (meat proxies) として挟まることなく修正を出すとする (0 / 1 / 1、はてなブックマーク 43 users)、10-12 voluntas が CLI のハーネスを OpenCode v2 から Pi に移した記事で、DeepSeek V4.1 Flash の上で @ollama/pi-web-search だけを使い、作業の 99% は DeepSeek Harness のフォークで行う (0 / 0 / 2、はてなブックマーク 163 users)。
• ainews 10-10 の号はほかに、トピック 1、2、6 と見送ったトピック 9〜11 のほか、音声、動画、画像、テキストを扱う Cloudflare の clef-omni と Jev より安くなった clef-flash、Vercel AI Gateway の Liquid d1、vLLM Semantic Router の Decision 2.0、Jev を判定役に使う LangSmith、Qwen3.5-4B を 8 GB の VRAM で決定モデルにする Unsloth のノートブック、サブスクリプションの外の使用クレジットに課金される Opus 5.5 の fast mode、Pro のユーザーに次のメッセージを提案する Codex、管理された Devin を木のように生む Devin、2,000 を超えるエージェントが Rust で書き直した Prime Intellect のエージェント、Upstage Solar Mini 4 (35B、アクティブ 3B)、新しい OCR のベンチマークを挙げる (いずれも高くても 1 / 1 / 1)。

13. 🚫 対象外 (スコープ外)

• ainews 10-10 の見出し: Jev の公開から 3 週間で年間経常収益 $100M 超、評価額 $7.5B とする TypeSafe の Series AI という名の資金調達 (資金調達のニュースで、この調達は Hacker News で 443 ポイント)、ほかに画像の生成と編集 (Qwen-Image-2.1-Turbo、30 回の編集を重ねるテスト)、音声のモデル、学習と推論のシステム (vLLM と SGLang の Vera Rubin での結果、TRL v1.15、Datology、Tinker の値下げ)。
• zenn-trending 10-10 Claude Motion は Claude がコードとして書いて MP4 に書き出すアニメーションの解説で、10-08 から Claude Dashboards とともに Team と Enterprise 向けのベータ (エンドユーザーの生産性の話で、46 いいね、はてなブックマーク 19 users)。
• hatena-llm 10-12 確率的なオウム (stochastic parrot) という比喩とそのよくある誤読についての GIGAZINE の記事 (AI 一般の言説、はてなブックマーク 65 users)。
• classmethod-claude-code 10-12 Claude Code に書かせた入門書でビジネス開発を学ぶエンジニアの記事 (エンジニアリングの作業ではない)。
• simon-willison 10-13 Python 3.15 と Python 3.10 のサポート終了、publickey 10-13 BTCONJP 2026 (イベントの告知)、aws-whats-new 10-13 アフターコンタクトワークのガイドを自動で埋める Amazon Connect、gcp-vertex-ai-release-notes 10-11 と 10-12 Agent Platform Workbench v2 のパッケージの更新。
• zenn-trending SHA のピン留めの先の GitHub Actions、1 年間の Mozc の変更、Mac 上の Besu のネットワーク、リザバーコンピューティングによる異常検知、C++ の文字列の扱い。