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

🤖 Generated by Claude Opus 5.5

• 対象期間: 2026-10-03 〜 2026-10-06 (前回の定期実行 10-03 以降、候補 47 件)。
• 取得できなかった情報源: なし。
• トピック 4 は 2026-10-03 のトピック 1 の続きで、ほかの選定トピックはいずれも新しい。
• トピック 2 と 3 は期間の少し前に Cloudflare の Birthday Week で発表されたもので、今回の実行で初めてフィードに現れた。

候補と選定

• 選定 (レポートに載せる):
  1. EU AI Act に対応する OpenAI のテキストの電子透かし: API でのオプトイン、EU の ChatGPT と Codex のテキスト、承認された研究者向けの検出器 (起点 10-05、影響度 2 / 将来性 2 / 重要度 2)。
  2. Cloudflare の決定モデル Clef と Clef-flash、その強化学習によるファインチューニングの提供 (起点 10-01、期間前の出来事で ainews と zenn-trending で初出、2 / 2 / 2)。
  3. エージェントのサンドボックス向けに作り直された Cloudflare Containers と、同じ日に出た Sandbox SDK 1.0 (起点 09-30、期間前の出来事で ainews と publickey で初出、2 / 2 / 2)。
  4. Claude Code 2.1.289 と 2.1.290 での権限ルールと読み取りのブロックの修正 (起点 10-03、1 / 1 / 2)。
  5. mizchi による自分の AI プログラミングの手法の棚卸し (起点 10-05、1 / 1 / 2)。
  6. アクセンチュア・ジャパンのエンジニアによる kev-4b と laya-ml のレイテンシとリアルタイム制御の検証 (起点 10-05、1 / 1 / 2)。 - 1〜3 は 6 点で同点、いずれも重要度 2 で一次情報があり、独立した情報源の数 (11、8、4) で順位を決めた。 - 1 は選定の時点では 1 / 2 / 2 だったが、調査で発表当日の独立した記事が 6 本見つかり、出力が EU に届く提供者には第 50 条 2 項にもとづく 2026 年 12 月 2 日の期限があるとわかったため、影響度を 2 に上げた。 - 4〜6 は 4 点で同点、いずれも重要度 2 で一次情報があり、独立した情報源の数 (7、7、2) で順位を決めた。
     • 4 と 5 はどの規則でも並ぶため、起点の早い 4 を上にした。
     • 4 は MIXED とクラスメソッドが 2.1.289 を独自に取り上げたものの、ポイントリリースの 2.1.284 と 2.1.285 と同じく影響度 1 のままとした。
• 見送り (次回の判断材料):
  7. ジャンプアカウントの運用下で Claude Code が使う AWS CLI の認証情報を aws-vault で扱う、クラスメソッドの設定 (起点 10-05、1 / 0 / 2) — 既知の credential_process のパターンに、エージェントに固有の発見が 2 つ加わっただけで、より広い議論はない。
  8. 既定でハードな予算上限を設けるべきだとする Simon Willison の主張 (起点 10-03、1 / 1 / 1) — 例に挙げたのは 9 月と 7 月の出来事で、新たに設定できるものはない。
  9. Aleph Alpha の Kolibri と、その設計を解説した実務者の記事 (起点 10-03、1 / 1 / 1) — ドイツ語と英語のモデルで、読者は日本語に使うことも学習を再現することもできない。
  10. コードレビューを 5 つの実践に解体するという t-wada の提案 (起点 10-05、1 / 1 / 1) — インタビューで、新しいデータも再現できる設定もない。
  11. issue からドラフトのプルリクエストまでを 1 時間ごとに回す、ラクスの Claude Code のルーティン (起点 10-05、1 / 1 / 1) — 設計の規則だけで、ルーティンのプロンプト、設定、結果が示されていない。
  12. その他の単発項目 — 下記に列挙。
  13. 対象外 (スコープ外) — 下記に列挙。

1. 💧 OpenAI が EU AI Act のもとでのテキストの電子透かしの進め方を示し、API では世界中で一部のモデルにオプトインの透かしを用意し、EU の ChatGPT と Codex のテキストには今後数週間で見えない透かしを入れ、検出器は承認された研究者だけに開き、短い文章や編集された文章での限界を測定値で示した

• 選定 / 影響度 2 / 将来性 2 / 重要度 2 / 起点 10-05 / 種別: 仕様変更 / 領域: API・クラウド、セキュリティ・安全性。
• 候補になったフィード項目:
  • openai-news 10-06 Our approach to EU text provenance rules
• 関連: 2026-09-29 のトピック 2 は、Claude Sonnet 5.5 に EU AI Act に関わる見えないテキストの透かしが入っているという報道を未確認としていたが、今回読んだ Anthropic のサポートページは、テキストに透かしを入れるモデルに Sonnet 5.5 を挙げている。

収集した情報

[A] OpenAI — Our approach to EU text provenance rules (2026-10-05)

https://openai.com/index/eu-text-provenance/

• Safety のカテゴリの記事で、副題は、今日の技術の限界の範囲で透明性を高めるという趣旨。
• EU AI Act は生成 AI の提供者に、生成したテキストを機械可読な形で識別できるようにすることを求めている、と前提を置く。
• テキストの透かしと検出はまだ初期の技術で限界が大きく、その利点や責任ある使い方についての見方も固まっていないと認める。
• 導入は段階的に進め、テキストの透かしから何がわかり何がわからないかを率直に示すことに重きを置くとする。
• API: 発表の日から、世界中の API 顧客が一部のモデル (select models) でテキストの透かしをオプトインで有効にできる。
  • API では透かしは既定でオフのままとする。
  • 透かしを自社の透明性の義務や、ユーザーに提供する体験にどう組み込むかは、顧客が決められる。
• ChatGPT と Codex: 今後数週間で、EU の対象となる (eligible) ChatGPT と Codex のテキスト出力に見えない透かしを加える。
  • 今後の予定の節では、対象を EU に限った、全プランの eligible な ChatGPT と Codex のユーザーと言い直している。
  • 開始の時点では、テキストの透かしを世界共通の既定にはしない。
  • 地域を限ることで、実際の利用とフィードバックから学ぶ余地を残すとしている。
• クラウド: クラウドパートナーのサービス経由で使われる OpenAI のモデルの出力にも、今後数週間で透かしを使えるよう、パートナーと作業を進めている。
• 検出器: 承認された研究者と専門機関は 2026-10-05 から openai.com/form/content-provenance-api で申し込め、利用はまず、技術の評価と改善に協力できる承認済みの研究者と専門機関に限られる。
  • Code of Practice に沿い、テキストの来歴 (provenance) の評価と改善のため、当初はケースごとに利用を認める。
  • ツールが返すのは OpenAI の透かしを検出したかどうかだけで、ユーザーを特定したり、プロンプトや会話を明かしたりはしない。
  • 透かしの見逃しと誤検出のリスクがあるため、開始の時点では一般に公開しない。
• この制限がかかるのはテキストだけで、画像と音声のためのツール (openai.com/verify と Content Provenance API) は引き続き誰でも使える。
• 仕組み: OpenAI のテキストの透かし技術 textGrain は、モデルの語の選び方に見えない統計的な信号を加える。
  • 検出器はその信号を探し、文章に OpenAI の透かしが含まれるかを判断する。
  • 技術レポートには今後数週間で詳細を追記する予定。
  • 他者が利用し発展させられるよう、技術をオープンソースで公開する計画もある。
• OpenAI の評価では、textGrain は試したほかの手法 (SynthID のテキスト版を含む) と同等かそれ以上の性能だった。
  • ただし、理想的な条件での高い性能が、日常の使い方での確かな検出を保証するわけではないと断っている。
• 長さと分野: 目標の偽陽性率を 1% にしたとき、心理学のような内容では、200 トークンの文章の約 80%、400 トークンの文章の約 95% で透かしを検出できた。
  • 数学のように語の選び方に自由が少ない内容では、検出率は大幅に低かった。
  • グラフには、ELI5 データセット (Hugging Face の rexarski/eli5_category) の数学と心理学の質問への、透かし入りの回答を使っている。
• 編集: 400 トークンの文章で語の 10% を類義語に置き換えると、検出率は約 92% から 66% に下がった。
  • 25% を置き換えると 17% まで下がった。
  • 編集のグラフには、ELI5 の質問への透かし入りの英語の回答を使っている。
• こうした限界も、検出器を当初は、信頼性と責任ある使い方の評価に協力できる承認済みの研究者と専門機関に限った理由の 1 つだとする。
• 品質: 最新のフロンティアモデル Astra の評価に使うベンチマーク全体で、透かしの有無による意味のある性能差は見られなかったとする。
• ベンチマークの表 (Astra、max) の、透かしなしと透かしありの値:
  • Artificial Analysis Intelligence Index は 49.57 と 49.76 ポイント。
  • AutomationBench は 34.09% と 34.86%。
  • DeepSWE v1.1 は 72.80% と 71.68%。
  • Terminal-Bench 4.0 は 53.90% と 56.06%。
  • Terminal-Bench Science 0.1 は 56.90% と 60.00%。
  • BrowseComp は 87.92% と 87.35%。
  • HealthBench Professional は 64.27% と 64.60%。
  • GPQA Diamond は 94.44% と 93.94%。
• 透かしからはわからないこととして、次を挙げる。
  • 人がどれだけ関わったかは測れない。
  • 所有権や責任の所在は示さない。
  • ユーザーは特定しない。
  • 内容が正確かどうかは確かめない。
  • 透かしが検出されなくても、人が書いたことの証明にはならない。
  • 文章が短すぎたり、編集や翻訳を経ていたりして確実に検出できないことがあり、対応していないモデルの出力、透かしの導入前の出力、他社のツールの出力であることもある。
• 来歴の取り組み全体としては、対応する画像の Content Credentials、C2PA への準拠、対応する画像と音声の SynthID、openai.com/verify と Content Provenance API による確認を挙げる。
• 今後も透かしが編集や翻訳にどこまで耐えるかを調べ、AI による支援と AI による執筆をより意味のある形で区別する方法を探るとし、検出器の利用は、結果を責任をもって解釈できると判断した時点で広げるとしている。

[A] OpenAI — textGrain: Entropy-Calibrated Watermarking for Language Model Text, technical report (2026-10-05)

https://cdn.openai.com/pdf/e9508624-d767-41b6-a26d-e34ca798ada6/textgrain-entropy-calibrated-watermarking-for-language-model-text.pdf

• 著者は Xiang Li と Qi Long (University of Pennsylvania)、Garrett Wen と Xiaohong Chen (Yale University)、Arzav Jain、Florent Joly、Mike Lam、Qingquan Song、Weijie Su (OpenAI、連絡先は Su)。
• textGrain の透かしの数学的な詳細を示す文書で、生成と検出の手順、透かしの信号と引き換えに失うサンプリングのエントロピーの予算 (budget) の決め方、保証の前提となる仮定を定める。
• 手法は、Gumbel 確率変数にもとづくコストと Kullback–Leibler (KL) 正則化をもつ最適輸送の問題を通じて、トークンの生成を鍵付きの乱数に結びつける。
• 独立からの KL ダイバージェンスは条件付きエントロピーの減少量に等しく、そのため透かしの強さのパラメーターを情報理論の量として直接解釈できる。
• 計算を速くするため、輸送を語彙のブロックに対して解き、ブロック内のトークンの相対確率を保ったまま最適化の次元を下げる。
• 各位置では、秘密鍵と、直前の最大 L_ctx トークンの窓から導いた擬似乱数を使う。
• 透かしは不偏で、鍵について平均をとれば次トークン予測 (NTP) の分布に戻るが、実際には 1 つの鍵が複数の応答で使い回されることが多いと指摘する。
  • 不偏であるだけでは、その鍵のもとでサンプリングがランダムなままである保証にはならない。
  • Gumbel-max 方式の透かし (Aaronson, 2023) は、文脈と鍵が同じなら常に同じトークンを選ぶため、同じプロンプトからの生成を繰り返すと同一の応答になりうる。
  • 同じプロンプトに対して異なる答えや解をいくつも必要とするアプリケーションでは、これが問題になる。
• エントロピーの予算は、サンプリングのエントロピーの平均的な損失を NTP のエントロピーの割合 β ∈ [0, 1] までに抑えるもので、カップリングは列全体の平均で NTP のエントロピーの少なくとも 1− β を残すが、これは列ごとの下限ではない。
• 生成の 1 ステップ (Algorithm 1) は、鍵付きで語彙を B 個のブロックに分け、温度スケーリングや top-p の切り詰めを経たトークン確率を足してブロックの確率とし、標準化した Gumbel 値のコスト表を予算のもとで m 個の等確率の列に結びつけ、鍵で列を選び、選ばれたブロックの中で元の相対確率に従ってトークンをサンプリングする。
• ソルバーは、対数領域での Sinkhorn の更新と、目標の損失に向けた正則化 λ の調整 (ステップサイズ a = 1/2) を交互に繰り返し、最後に周辺分布の補正で所定の 2 つの周辺分布を回復する。
  • 反復回数の上限や数値の許容誤差のために損失が目標より上にも下にもずれうるので、指定した予算だけでは数値計算の出力を保証できないとする。
  • 位置あたりのコストは、アクティブなサポート A と反復回数 N_it について O(|A| + N_it·B·m) で、複数の分布の求解はバッチにまとめられる。
• 検出に必要なのは生成されたテキストと秘密鍵だけで、生成時に使った予算を知る必要はない。
  • ただし、トークナイザー、ブロックと列の数、文脈の窓の規則、鍵付きの擬似乱数の作り方は生成時と同じでなければならず、一方でカップリングも生成モデルもエントロピーの予算も再構成には要らない。
  • 位置ごとのスコアは Y_t = −log{1 − F_G(Z_t)} で、異なる文脈の窓ごとに最初の出現だけを足した和は透かしのないテキストでは Gamma(n, 1) に従い、和が (1 − α) 分位点を超えたら透かしありと判定する。
  • 固定の鍵を配備し有限精度で計算する以上、経験的な較正の確認が欠かせず、理想化した帰無分布の計算だけでは、どの鍵やアプリケーションでも同じ誤り率になるとは保証できないとする。
• 下書き (draft) のモデルと目標のモデルが秘密鍵を共有すれば textGrain は投機的サンプリングと組み合わせられる (付録 B) が、分布が等価であることだけでは高速化は示せず、検出に下書きのトークンの記録は要らない。
• この構成が生成時に埋め込むのは 1 ビットの来歴の信号で、識別子やメタデータを埋めて出どころの特定に使える多ビットの透かしとは違う。
• レポートに実験はなく、B、m、β、L_ctx の実際の配備値も載っていない。

[A] OpenAI Help Center — Provenance signals in OpenAI-generated content (2026-10-06 取得時点)

https://help.openai.com/en/articles/8912793-provenance-signals-in-openai-generated-content

• 2026-10-06 の 10:13 JST に取得したとき、ページには 10 時間前に更新と表示されていた。
• 来歴のシグナルの表で、テキストの行は textGrain の透かし (EU のみ) となっている。
  • EU では、ChatGPT が生成したテキストに、EU AI Act に従うため、モデルの語の選択に使う乱数への見えない変更が含まれると説明する。
  • 世界中の API 顧客は、プロジェクトか組織の設定から、テキスト出力に透かしを入れられる。
• API の出力は、近く非推奨になる予定のモデル (gpt-image-1、gpt-image-1.5、sora-2 など) を除いて対象になる。
• EU の ChatGPT ユーザーへのテキストの透かしは EU AI Act に従うためで、OpenAI がほかの主要な AI 提供者とともに署名した EU の Code of Practice on Transparency of AI-Generated Content での約束にも沿うとする。
• textGrain は、モデルが文章を書きながら候補の語や語の断片からランダムに選ぶやり方をわずかに調整し、いくらか編集された後でも検出器が探せるパターンを作る。
  • 隠し文字、見えない空白、普通でない句読点は加えない。
  • 透かしは目に見えず、テキストをコピーして貼り付けても隠れたものが入り込むことはない。
• 透かしのシステムは、語の確からしさ (likelihood) を調整した組をいくつも作り、それぞれが秘密鍵に応じて違う選択に傾く。
  • 各組は、平均するとモデルの元の確からしさに一致するよう釣り合わせてある。
  • 鍵がどの組を使うかを決め、モデルはその組からあらためてランダムに選ぶ。
• 透かしは軽い編集やコピーと貼り付けには耐えるよう設計されているが、大幅な言い換えや翻訳で検出できなくなることがある。
• 数学の答えのように事実に忠実で厳密である必要がある回答や、与えた文章の再現を求める依頼では、言い回しを変える余地が少ないため、透かしが検出されないことがある。
• 短い文章は、たいてい確実な検出に足りるだけの長さがない。
  • コードも、次に来うるもっともらしい候補が通常の文章より少ないため、透かしを入れにくい。
  • こうした限界を踏まえ、EU AI Act の Code of Practice on the Transparency of AI-Generated Content は、200 トークン (英語で約 150 語) より短い出力とコード断片 (code snippets) には透かしを求めていないと説明する。
• グラフで EU の公用語 24 言語すべてを評価しており、500 件の合成した英語のプロンプトを残りの 23 言語に翻訳して使っている。
  • 偽陽性率 1% で、検出率が最も高いのはスペイン語 (69.0%)、最も低いのはルーマニア語 (42.2%)。
  • 透かしには調整できる強さのパラメーター (つまみにたとえている) があり、OpenAI は検出率が 60% を下回る言語でこれを上げたが、その改善幅はグラフの棒でしか示されていない。
• 品質: Astra のベンチマークでの差は、評価の実行ごとにふだん見られるノイズの範囲に収まるとする。
  • 以前の ChatGPT での試験でも、透かしの導入で低評価 (thumbs-down) の率やほかのプロダクトの指標は変わらなかったという。
• テキストの透かしがモデルの速度に与える影響はごくわずかだとする。
• Pangram のような分類器を使わない理由は、EU AI Act が生成テキストに信号を埋め込むことを明確に求めているからだと説明する。
• textGrain を作ったのは、透かしの検出しやすさと、同じプロンプトから生成される応答の多様さとの釣り合いを、SynthID や TextSeal より細かく制御するためだとする。
• API での有効化は、プロジェクト単位か組織全体で、テキストの透かしを入れるモデルを選んで行う。
  • 手順は、Allow text watermarking をオンにし、モデルを選んで Save を選ぶ。
  • 組織の既定は Organization settings → Data controls → Text provenance で設定する。
  • プロジェクトごとの上書きは Project Settings → Text provenance で設定する。
  • 対応モデルで有効にすると、OpenAI がテキストの生成中に透かしを加える。
  • 顧客が応答ごとに別のマークを付ける必要はない。
• 対応モデルはこの設定画面にしか示されず、今後数週間ですべてのレガシーモデルに対象を広げるとする。
• 透かしを有効にしても検出器は使えるようにならず、検出器の利用は現在、承認された研究機関と学術機関に限られる。
• テキストの検出器に申し込めるのは、テキストの来歴、検出の信頼性、人が来歴の結果をどう受け取るかを研究する学術・研究機関。
• 現在の研究パートナーは、John Thickstun (Cornell University)、Martin Vechev (ETH Zurich と INSAIT)、Kempelen Institute of Intelligent Technologies (KInIT) の研究者。
• 言い回しを保ったままテキストを再利用すれば、追加の組み込み作業なしに信号は残ると見込まれる。
  • ただし、言い回しが同じでも、とくに短い文章や語の選び方に余地の少ない文章では、透かしを検出できる保証はない。
• 画像、音声、テキストを含むすべての対象の出力に透かしなどの来歴のシグナルが入るよう、すべてのクラウドと配信の提供者と作業を進めているとする。
  • 提供状況は出力の種類やパートナーによって異なりうる。
• 透かしと C2PA のメタデータは、求められうる目に見えるラベル、バナー、その他の告知の代わりにはならず、OpenAI は個別の法的義務について助言できないとする。
• Content Provenance API での確認は現在無料で、利用の上限がある。

[A] OpenAI API docs — Content provenance (2026-10-06 取得時点)

https://developers.openai.com/api/docs/guides/content-provenance

• POST /v1/content_provenance_checks は画像か音声のファイルを 1 つ確認し、完了した結果を同じレスポンスで返す。
• テキストを確認するには利用の申し込みが要る。
  • テキストの確認は現在、AI の研究機関や学術機関を含む承認された組織だけが使える。
• 画像には c2pa と synthid、音声には synthid の結果のエントリがあり、それぞれの outcome は detected か not_detected で、全体としての判定はない。
• 現時点では他社の AI モデルが生成したコンテンツは検出しないため、not_detected は他社のモデルによる生成も否定しない。
• 汎用の AI 検出器ではなく、あらゆる AI システムの生成物を見分けるものでもないとする。
• アップロードできるのは PNG、JPEG、WebP の画像と、MP3、Opus、AAC、FLAC、WAV、PCM の音声で、1 ファイル 50 MiB まで、音声は 60 秒まで、1 リクエストに 1 ファイル。
• SDK の最低バージョンは Python 2.52.0、Go 3.49.0、Ruby 0.75.0。
• エラーは、不正な形式・非対応・ブロック対象のファイルで 400、利用権のない組織で 404、レート制限の超過で 429。
• 責任ある利用の規則には、透かしを解析、除去、回避するために問い合わせを繰り返さないことが含まれる。
  • 影響の大きいワークフローでは、自動の判断に人のレビューを組み合わせるよう求める。

[A] OpenAI — Content Provenance API interest form (2026-10-06 取得時点)

https://openai.com/form/content-provenance-api/

• より高いレート制限やテキストの検出器の利用を希望する組織のための申込フォーム。
• テキストの検出器の利用で対象になるのは、テキストの来歴、検出の信頼性、人が来歴の結果をどう理解するかを研究する学術・研究機関の用途だとする。
• 画像と音声の上限の引き上げについては、日常的な商取引の不正防止やその他の社内業務のワークフローは、おおむね現在のプログラムの対象外だとする。
• 組織名とウェブサイト、任意で OpenAI の組織 ID、OpenAI の Account Director とやり取りしているか、想定する用途 (1000 文字まで)、確認したい形式 (画像、テキスト、音声、その他) を尋ねる。

[A] OpenAI — Supporting Europe's work in ensuring a trustworthy AI ecosystem (2026-06-11)

https://openai.com/index/supporting-eu-trustworthy-ai-ecosystem/

• 欧州委員会の行動規範が公表された翌日の記事で、OpenAI が Code of Practice on Transparency of AI-Generated Content を支持すると表明した。
• OpenAI は 2025 年に、EU の General-Purpose AI Code of Practice に署名した最初の米国企業だったとする。
• 来歴の取り組みの始まりを、DALL-E 3 の画像に C2PA のメタデータを付け始めた 2024 年に置く。
• 行動規範は、実装にあたって実際に機能する手法に根ざし、現在の技術の限界を反映できる柔軟さを保つべきだと述べる。
• 現在の来歴の取り組みとして画像、確認、標準、安全策を挙げ、テキストには触れていない。

[A] OpenAI — API changelog (2026-10-06 取得時点)

https://developers.openai.com/api/docs/changelog

• Oct 5 の日付のエントリは、製品の中で HIPAA の準拠の手続きを進められるようにした 1 件だけで、テキストの透かしや来歴に触れたエントリはない。
• GPT-6 Astra (gpt-6-astra) を最も高性能なモデルと呼び、GPT-6.1 Sol (gpt-6.1-sol) は Sep 29 に GPT-6 Astra より低いコストで出たとしている。

[A] OpenAI — ChatGPT & Codex changelog (2026-10-06 取得時点)

https://learn.chatgpt.com/docs/changelog

• 2026 年 10 月のエントリ (Codex CLI 0.160.0 と 0.160.1) は、透かし、来歴、EU AI Act のいずれにも触れていない。

[A] European Commission (AI Act Service Desk) — Article 50: Transparency obligations for providers and deployers of certain AI systems (2026-07-27 時点の統合版)

https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50

• 第 50 条 2 項: 合成した音声、画像、動画、テキストを生成する AI システム (汎用 AI システムを含む) の提供者は、その出力が機械可読な形式でマークされ、人工的に生成・操作されたものとして検出できるようにしなければならない。
• その解決策は、技術的に可能な範囲で、効果的で、相互運用でき、堅牢で信頼できるものでなければならず、コンテンツの種類ごとの特性と限界、実装のコスト、一般に認められた最新の技術水準を考慮する。
• AI システムが標準的な編集を補助する機能を果たす場合や、導入者 (deployer) が与えた入力データやその意味を実質的に変えない場合は、その範囲でこの義務は適用されない。
• 第 50 条 4 項: 導入者は、公共の利益に関わる事柄を一般に知らせる目的で公開する AI 生成のテキストについて開示しなければならないが、人のレビューや編集上の管理を経て、誰かが編集上の責任を負う場合は除かれる。
• Digital Omnibus on AI で改正された第 50 条 7 項は、欧州委員会が行動規範を評価し、規範が不十分なら共通の規則を定める実施法 (implementing act) を採択できるとする。

[A] European Commission (AI Act Service Desk) — Article 111: AI systems already placed on the market or put into service (2026-07-27 時点の統合版)

https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-111

• Digital Omnibus on AI で新設された 4 項は、合成した音声、画像、動画、テキストを生成する AI システム (汎用 AI システムを含む) のうち、2026 年 8 月 2 日より前に市場に出たものの提供者に、2026 年 12 月 2 日までに第 50 条 2 項に従うための措置をとるよう求める。

[A] European Commission (AI Act Service Desk) — Article 113: Entry into force and application (2026-07-27 時点の統合版)

https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113

• 規則は 2026 年 8 月 2 日から適用され、高リスクの規則の一部にはそれより後の日付がある。

[A] European Commission — Code of Practice on Transparency of AI-generated Content, policy page (2026-07-31 最終更新)

https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content

• 第 50 条の透明性の義務は 2026 年 8 月 2 日から適用される。
• 行動規範への参加は任意でも、AI Act 第 50 条の透明性の要件は法的な義務だと明記する。
• 欧州委員会と AI Board は、この規範が準拠を示すための適切な任意の手段であることを確認した。
• Section 1 は提供者 (マーキングと検出)、Section 2 は導入者 (ディープフェイクと、AI が生成・操作したテキストのラベル付け) を扱う。
• 別の手段で準拠する提供者と導入者は、その措置が適切であることを示さなければならず、市場監視当局が個別に評価する。
• 2026 年 7 月末までに約 190 の組織が署名し、最終版の規範は、2025 年 11 月 5 日の開始の全体会合から進めた起草を経て 2026 年 6 月 10 日に公表された。

[A] European Commission — Code of Practice on Transparency of AI-Generated Content, text (PDF, 2026-06-10 公表)

https://ec.europa.eu/newsroom/dae/redirection/document/129555

• Measure 1.1 は、音声、画像、動画、コンテナに収めたテキストに少なくとも 2 層の機械可読なマーキングを求めるが、自由形式のテキストはメタデータを運べないため、その種のコンテンツには Sub-measure 1.1.2 の 1 層のマーキングで足りるとする。
• Sub-measure 1.1.2 では、署名者は AI が生成・操作したコンテンツに知覚できない透かしでマークを付け、非常に短いテキストだけを例外とする。
  • 200 トークンより長い自由形式のテキストには、非常に長いテキストへの透かしより信頼性が低くなりうるとしても、透かしを適用しなければならない。
  • 自由形式のテキストでの信頼性の低さを補うため、対応する検出の手段の利用を、Sub-measure 2.1.2 に定める検証済みの専門家ユーザーに限ってよいとする。
• モデルの提供者には、川下の提供者の準拠を助けるため、モデルの段階で透かしを実装し、AI システムの推論の過程に透かしを滑らかに組み込めるようにすることを勧める。
• それまでは、非常に短いテキスト (very short text) を 200 トークン未満のテキストと理解するとし、新しい手法が出てくればこの閾値は下がる見込みだとする。
• 自由形式のテキストは、囲む構造、スキーマ、コンテナ形式のない生の文字の並びと定義され、例としてウェブサイトやチャットに表示されるテキストが挙がる。
• Measure 1.2(b) は、導入者などの第三者がメタデータのマーキングを意図的に除去・改ざんすることを、許容利用ポリシー、利用規約、文書で禁じるよう署名者に求める。
• Sub-measure 2.1.1 では、検出の手段は無料で提供し、月間ユーザーが 1,000,000 未満の署名者は非常に大量の利用に料金を課してよいが、当局、メディア、ファクトチェッカー、独立した研究者、市民社会には常に無料かつ無制限で提供する。
• Sub-measure 2.1.2 では、自由形式のテキストの透かしにもとづく検出は信頼性が低いため、署名者はその利用を制限してよいが、検証済みの専門家ユーザーには提供しなければならない。
  • 制限は、より信頼でき堅牢な検出の仕組みが現れるまでの期間に限られる。
• Measure 3.3 は、耐えるべき典型的な処理として、語彙の置き換えやホモグリフ、言い換えや翻訳の往復、印刷とスキャン (と OCR) などを挙げる。

[A] European Commission — Questions & answers: Code of Practice on Transparency of AI-Generated Content (2026-06-10 最終更新)

https://digital-strategy.ec.europa.eu/en/faqs/code-practice-transparency-ai-generated-content

• 2026 年 8 月 2 日から、AI Act 第 50 条 2 項と 4 項の範囲に入る AI システムの提供者と導入者は、AI が生成・操作したコンテンツについての透明性の義務に従わなければならない。
  • その日より前に市場に出た AI システムには例外がある。
  • それらのシステムには、2026 年 12 月 2 日までの移行期間がある。
• 署名者は準拠を確保し示すための簡素化された手段の恩恵を受けられ、今後の執行は規範の遵守の監視に重点を置くとする。
• AI Office は規範を少なくとも 2 年ごとに見直す。

[A] European Commission — Strong backing for the Code of Practice on Transparency of AI-generated Content (2026-10-06 取得時点の署名者一覧)

https://digital-strategy.ec.europa.eu/en/news/strong-backing-code-practice-transparency-ai-generated-content

• Section 1 の例として、Aleph Alpha、Anthropic、Black Forest Labs、Cohere、Google、Meta、Microsoft、Mistral、Open AI (ページの表記のまま)、Synthesia を挙げる。
• 取得時点で、一覧には Section 1 の署名者が 95、Section 2 の署名者が 192 あった。
• 署名者のタスクフォースは 2026 年 9 月に立ち上げる予定とされていた。

[A] European Commission — Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of the AI Act, C(2026) 5054 (2026-07-20)

https://ec.europa.eu/newsroom/dae/redirection/document/131215

• Point 68 は、短い数字・記号・文字の並びの形をとる出力 (単語、画像のキャプション、代替テキスト、UI のラベルやアイコン大の図、データのラベルなど) を第 50 条 2 項の範囲の外に置く。
• 同じく、コンピューターが解釈、コンパイル、実行することを意図した、プログラミング、スクリプト、マークアップ、クエリ、設定の言語で書かれたコンテンツと理解されるソースコードも除く。
  • ソースコードと一体をなす自然言語のコメントや文脈の情報も、これに含まれうる。
  • SDK、SQL、Infrastructure as Code、YAML や JSON の設定、スキーマ、スクリプト、機械可読な仕様、API も除かれる。
• エージェントどうしの通信のように、人の目に触れずに自動で処理される機械どうしの出力は、自然人に知覚されない限り範囲外とする。
• Point 70 は、一方の要素だけを満たしても (たとえば、出力を機械可読な形でマークしても、その検出の手段を用意しなければ) この規定への準拠にはならないとする。
• Point 72 は、提供者が 1 つのマーキング技術に頼っても、複数を組み合わせてもよいとする。
• Point 74 は、提供者が川上のモデル提供者や、解決策を提供する第三者のマーキングに頼ってよいとする。
  • ただし、それに頼っても、第 50 条 2 項への準拠を示す AI システムの提供者の責任は変わらない。
• Point 76 は、標準ができるまで、とくに透かし技術について第 50 条 2 項を実施する初期の段階では、ほかの提供者の解決策と相互運用できる限り、自社の検出の手段か共有の検出の手段を使ってよいとする。
• Point 87 は、公共向けや消費者向けのシステムを除いた狭い企業間 (B2B) の例外を定め、3 つの条件がそろったときだけ適用する。
  • 出力が厳密に技術的な性格のもの (設計図、技術的な指示、確定前の社内文書など) であること。
  • 職務として行動する、あらかじめ決まった限られた数の自然人だけが知覚し処理することを意図していること。
  • 社外への共有を意図しておらず、クラウドの分離やロールベースの制御などの安全策があること。

[A] European Commission — Questions & answers: Transparency obligations under Article 50 of the AI Act (2026-07-24 最終更新)

https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act

• 提供者とは、EU 内に拠点があるか第三国にあるかを問わず、自らの名称や商標で AI システムを EU の市場に出す者を指す。
• EU 外に拠点を置く AI システムの提供者も、その AI システムの出力が EU で使われるなら AI Act の規定の対象になる。
• マーキングの義務の対象外となる出力として、短い並び、機械どうしの出力、閉じた産業用の出力とあわせて、ソースコードを挙げる。
• 限られた猶予期間が想定されているのは、2026 年 8 月 2 日より前に市場に出た AI システムの、AI 生成コンテンツのマーキングと検出の義務 (第 50 条 2 項) だけ。
  • そうしたシステムの提供者は、2026 年 12 月 2 日からその義務に従えばよい。
• 2026 年 8 月 2 日より前に生成されたコンテンツに、さかのぼってラベルを付ける必要はない。
• 執行は主に各国の市場監視当局が担い、同じ事業者がシステムと汎用モデルの両方を提供する場合や、システムが超大規模オンラインプラットフォームや検索エンジンに組み込まれている場合は AI Office が所管する。
• 罰金は最大で 1,500 万ユーロか、前会計年度の全世界の売上高の 3% に達しうる。

[A] Anthropic — How Claude's text watermark works (2026-08-14、2026-09-01 更新)

https://www.anthropic.com/news/claude-text-watermark

• 今後の Claude のモデルは、透かしを含むテキストを生成する。
• Claude のテキストの透かしは、Google DeepMind が 2024 年に Nature の論文で発表した SynthID-Text の手法の一種だとする。
• テキストに何かを加えるわけではなく隠し文字もないうえ、透かしのために余分なトークンは要らず、料金も上がらない。
• 地域ごとに範囲を区切る確かな方法がまだないため、開始の時点から世界中で透かしを適用する。
• 厳密な出力が求められる場面では透かしを入れないため、多くの場合に厳密さが要るコードには、ほかの種類のテキストより透かしが少なくなる。
  • とはいえ、コードの中でも語や用語の選び方に任意性がある箇所、たとえばコード中のコメントには透かしが入りうる。
• 校正では透かしの付く余地がほとんどない一方、Claude による翻訳はすべての語を Claude が選ぶため透かしが入る。
• 検出 API をプライベートプレビューで出す。
  • EU の法律のもとで資格のある組織が対象で、自らの AI Act への準拠のために同じく透かしの確認を義務づけられる企業も使える。
• EU の法律には 2026 年 8 月 2 日より前に出た Anthropic のモデルのための移行期間があり、それらのモデルにも透かしを加える作業を進めているとする。

[A] Anthropic (Claude Help Center) — How Claude marks AI-generated content (2026-10-06 取得時点)

https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content

• Anthropic は、生成 AI のモデルと生成 AI のシステムの両方の提供者として行動規範に署名した。
• 2026 年 8 月 2 日以降に EU で出る Claude のモデルは、出た時点から機械可読なマーキングに対応する。
• マーキングは、対応する Claude のモデルの出力に、Claude Platform (API)、Claude、Claude Code、Claude Cowork、Claude Tag をはじめ、Claude を提供するあらゆる場所で世界中で適用される。
• 透かしはモデルの段階で入るため、どの Claude の製品や画面から出たテキストにも含まれる。
• AWS、Google Cloud、Microsoft Foundry 経由で使う対応モデルの出力にも透かしが入る。
• 表は、3 つのマーク (ファーストパーティのテキスト、クラウドパートナーのテキスト、C2PA のファイル) のすべてを Fable 5.1、Mythos 5.1、Opus 5.5、Opus 5、Sonnet 5.5 に付け、Fable 5、Opus 4.8、Sonnet 5 にも付けたうえで、Amazon Bedrock での展開は October 12 までに完了するという注記を添える。
• Mythos 5、Opus 4.7、4.6、4.5、Sonnet 4.6 と 4.5、Haiku 4.5 には、保存したテキストではチェックマークが 1 つずつしかない。
• 透かしの検出は資格のある組織と義務を負う企業向けのプライベートプレビューで、利用申請のフォームから申し込む。
• 自社の製品に Claude を組み込む場合は、第 50 条が自社の製品とサービスに何を求めるかを独自に判断すべきだとする。

[A] Google DeepMind — SynthID (2026-10-06 取得時点)

https://deepmind.google/models/synthid/

• SynthID を、Gemini のアプリとウェブで生成したテキストの透かしと識別にも広げたとする。
• SynthID はこれらの確率のスコアを調整して透かしを作り、透かしは人の目にはわからず、出力の品質にも影響しないとする。
• Gemini での確認と SynthID Detector のポータルが受け付けるのは画像、動画、音声で、ページにはテキストの確認も、テキストについての API での対応も書かれていない。

[B] TechCrunch — OpenAI will start watermarking ChatGPT's text in the EU, by Aditya Mehta (2026-10-05)

https://techcrunch.com/2026/10/05/openai-will-start-watermarking-chatgpts-text-in-the-eu/

• 世界のどこの開発者でも、OpenAI の API の一部のモデルで発表の日から透かしを有効にでき、既定ではオフだと伝える。
• 透かしは語そのものに入っているので、コピーして貼り付けてもテキストとともに移ると説明する。
• 技術レポートは University of Pennsylvania と Yale の研究者との共著だとする。
  • 何百もの小さな偏りを積み重ねれば、検出器はテキストと鍵だけで AI が生成したコンテンツを見分けられる、と仕組みを説明する。
• 編集で透かしを消せるのかという問いを立て、OpenAI 自身の試験は消せることを示唆していると答える。
• 短い文章、数学の答え、翻訳したテキストは検出しにくいと OpenAI が述べたことも伝える。
• 発表は、Anthropic が Claude の生成するテキストに透かしを入れ、それを世界中で適用すると述べてから 2 か月後だった。
  • Anthropic のその決定には Claude の一部のユーザーが反発し、指示も文脈も判断も自分たちが出しており、Claude は道具にすぎないと主張した。
• OpenAI は以前にもテキストの透かしを作りながら、透かしのない競合にユーザーが移るという懸念もあって公開を見送ったと、The Wall Street Journal が 2024 年に報じていた。
• Anthropic、Google、Meta、Microsoft、OpenAI は、AI 生成コンテンツについての EU の行動規範に従うと約束した企業に含まれる。

[B] The New Stack — OpenAI brings text watermarking to its API — and unlike Anthropic, it's off by default, by Paul Sawers (2026-10-05)

https://thenewstack.io/openai-api-text-watermarking/

• 開発者は API のテキストに透かしを入れるかどうかを選べるようになったが、コードでどこまで機能するかには疑問が残る、と書き出す。
• Anthropic の透かしは API や Claude Code を含め、対応する Claude のモデルに世界中で入り、API の開発者向けの同等のオプトアウトも示されていないため、出力に透かしが入るかを開発者が決める余地は小さい、と対比する。
• OpenAI の顧客はプロジェクトか組織ごと、対応モデルごとに有効にし、有効にした後は個々の API リクエストを変える必要はないと OpenAI が述べていると伝える。
• OpenAI が使えた既存の手法として、SynthID に加えて Meta の TextSeal を挙げる。
• そのうえで、今後の Codex への展開に注目すべきだとする。
  • OpenAI は、Codex の出力のうち何を eligible とするのか、生成されたコードそのものに透かしを入れるのかを、まだ正確に説明していない。
• DeepSWE、AutomationBench、Terminal-Bench での Astra の結果は、textGrain をコーディングの能力を大きく損なわずに有効にできることを示唆するが、できたコードを後でどれだけ確実に透かし入りと判定できるかは何も語らない、と指摘する。
• textGrain をオプトインした API 顧客が、その透かしを検出する手段を自動的に得るわけではないとする。
• The New Stack は、eligible な Codex の出力が何を指すのか、コードに特化した検出率があるのかを OpenAI に問い合わせたとする。
• ページには、TNS の所有者 Insight Partners が OpenAI と Anthropic に投資しているという開示がある。

[B] Gizmodo — OpenAI Is Adding Text Watermarks in the EU Because Regulation Works, by AJ Dellinger (2026-10-05)

https://gizmodo.com/openai-is-adding-text-watermarks-in-the-eu-because-regulation-works-2000821852

• OpenAI が、ChatGPT とコーディングエージェントの Codex を含め、自社の AI モデルが生成するすべてのテキスト出力に透かしを入れると書いたうえで、オプトインと EU での展開を説明する。
• EU での透かしは選べず、自動で入り、オフにする手段もないとする。
• Anthropic と Google DeepMind の透かしは米国のユーザーにも適用される (または適用されていた) が、OpenAI のものはそうではない、と対比する。
• Google が 8 月に、透かしが義務でない国ではユーザーが画像、動画、楽曲から透かしを外せるようにしたことにも触れる。
• Rainey Center の世論調査を引き、10 人に 8 人近くが AI の透かしの義務化を支持し、その割合は民主党支持者で 82%、共和党支持者で 75% だったとする。
• 規制は、きちんと成立させて執行すれば実際に効くのだと結ぶ。

[B] 9to5Mac — OpenAI details new text watermarking system for ChatGPT, Codex, and the API, by Marcus Mendes (2026-10-05)

https://9to5mac.com/2026/10/05/openai-details-new-text-watermarking-system-for-chatgpt-codex-and-the-api/

• OpenAI の方式を Claude の透かしをめぐる論争と並べ、似た手法だが、展開の範囲も対象もずっと限られていると位置づける。
• Claude の鍵は Anthropic のシステムに固有なので、Claude の検出器では、テキストが OpenAI やほかの競合から来たかどうかはわからないと指摘する。
• OpenAI は全体の性能に意味のある差はないとしながら、比較では透かし入りの出力のほうがいくつかのベンチマークでわずかに高かった点を、興味深いと書く。

[B] Mynavi News — OpenAI、テキスト用の電子透かし「textGrain」を導入 ChatGPTとCodexはEUから (2026-10-06)

https://news.mynavi.jp/article/20261006-5082191/

• 10 月 5 日 (現地時間) の発表を EU の AI Act への対応として伝え、ChatGPT と Codex は「今後数週間かけてEU域内のChatGPTおよびCodexユーザーに展開する」、API では「世界のユーザーを対象に、対応モデルで任意に有効化できるようにした」と書く。
• EU 以外については「開始時点でEU以外には標準適用しない」とする。
• OpenAI の数値をそのまま伝え、偽陽性率 1% の評価で心理学などの文章の検出の割合は「200トークンで約80％、400トークンで約95％」、400 トークンの文章では「単語の10％を類義語に置き換えると、検出率は約92％から66％に低下し、25％を置き換えた場合は17％となった」とする。
• 品質については、OpenAI が「最新のフロンティアモデル『Astra』を8種類のベンチマークで評価し、透かしの有無による実質的な性能差は見られなかった」としていると書く。
• 第 50 条の透明性の規則について「関連する透明性義務は2026年8月2日から適用されている」とする。
• 背景として、Google DeepMind が「2024年に『SynthID』をテキストに拡張し」Gemini の文章生成に導入したこと、SynthID が「テキストに加え、画像、音声、動画にも対応している」ことを挙げる。
• Anthropic が 2026 年 8 月に発表した Claude の透かしは「SynthID-Textをベースとし」、「2026年8月2日以降に投入したClaudeモデルを対象とし、それ以前のモデルについても順次対応を進めている」と説明する。

[B] Gizmodo Japan — OpenAIがテキスト透かし技術「textGrain」を発表 なぜか“検出されにくくなる条件”も明かす (かみやまたくみ、2026-10-06)

https://www.gizmodo.jp/article/2610-openai-textgrain-watermark/

• 「『EUでは』というのがポイントで、日本を含むグローバルのChatGPT/Codexには今回は導入されません」と、EU に限った導入であることを強調する。
• 検出器が研究者と専門機関だけに公開されることについて、「怪しい文章をチェックにかけて『やっぱChatGPTだった！』とかはできません」と書く。
• OpenAI の長さのグラフを読み、心理学の文章は「200トークン（ざっくり英単語150個分くらい）」で「80%ほど」、「400トークン（英単語300個分くらい）だと90%ほど」、数学の文章は「40%~60％ほど」とする。
• OpenAI の説明を「数学のように単語選択の柔軟性が低いコンテンツでは、全体的な検出精度は大幅に低下する」と訳して引く。
• 「長さよりも扱う分野のほうが検出率に影響しているんです」と結論づけ、理由を「数学の言葉は非常に厳密で密度も高いですから、単語を選んで透かしを入れられる余地が少ないんでしょうね」と推し量る。
• 編集のグラフからは「単語を置き換える（書き換える）ほど、検出率が下落することが示されています」と読み、OpenAI について「何だか今回は妙に正直」と評する。

[B] Alexander Nemecek, Vipin Chaudhary and Erman Ayday (arXiv) — Watermarks Without Verification: AI Text Watermarking After the EU AI Act (2026-09-09)

https://arxiv.org/abs/2609.09604

• cs.CY の 10 ページのプレプリントで、連絡先は case.edu のアドレス、OpenAI の発表より前に投稿された。
• 透かしへの反対論も擁護論も現時点では検証できず、透かしそのものではなく、この検証できなさこそが実質的なガバナンスの失敗だと論じる。
• 配備済みのシステムを試せる公開のツールがないため、オープンソースの SynthID-Text の実装を MarkLLM のツールキット経由で、指示調整済みの Gemma-2-9B と Llama-3.1-8B の非歪曲 (non-distortionary) の構成で評価した。
  • 文章のセットは自由回答の 500 プロンプト、コードのセットは 2 つのベンチマークの 364 のプログラミング問題で、それぞれ 10 サンプルを生成し、別のシードで透かしなしの 2 本目を対照に置いた。
• 文章では、パープレキシティの変化はどちらのモデルでも −0.3% で、シードを変えた対照は +0.0% と +1.5%、審査役 (judge) の勝率は 0.501 と 0.515 で、文章への透かしの影響はサンプリングのシードを変えた影響を超えないとする。
• コードでは、pass@1 が Gemma で透かしあり 61.8%、透かしなし 61.4% (+0.4 ポイント)、Llama で 60.7% と 63.8% (−3.1 ポイント、95% 区間は −6.0〜−0.3)。
• 偽陽性率 1% での検出は、文章の真陽性率が 200 トークンで 39%、400 トークンで 56%〜59%、文章の AUROC が 0.78 と 0.82 だったのに対し、コードの AUROC は 0.55 と 0.57 で偶然に近いままだった。
  • コードのサンプルの 25%〜31% は、透かしの有無で 1 文字も違わず、Gemma で 200 トークンに達したコードのサンプルは 100 に 1 つもなかった。
• したがって配備する側にはエントロピーの低いところで透かしを切る十分な理由があるが、それをしているか、どの閾値で、出力のどれだけについてかを開示している配備は 1 つもないと指摘する。
• 1 つの固定の鍵のもとでは、同じプロンプトへの繰り返しの応答が本来より似通い、実装はシードを変えてこれを和らげているとする。
• 公開されている検出のインターフェースは、スコアを返さず、透かしあり・なしのような判定に縮めてしまうとする。
• 5 つの要件を提案する: 透かしのオンとオフの出力の対をスコア付きの検出器とともに示すこと、配備した構成の開示、検出器のガバナンスを含む認定された監査、言語とコンテンツの種類ごとに報告する共通の評価プロトコル、相互運用できる検出のインターフェース。

[B] Daring Fireball — Anthropic's 'Watermark' Text Adulteration in Claude Is a Perversion of Writing, by John Gruber (2026-08-16)

https://daringfireball.net/2026/08/anthropics_watermark_text_adulteration_in_claude_is_a_perversion_of_writing

• OpenAI の発表の 7 週間前に、Anthropic の透かしについて書かれた。
• 使う LLM にはどれも、判断の各時点で最良で最も正確な語を選んでほしいと書く。
• ユーザー以外の誰にも読まれない、ユーザーと Claude の私的な会話にまでマーキングがかかることに異を唱える。
• Ben Thompson の有料の Stratechery の要約を紹介し、その中には、提供者はユーザーが透かしを除去しないことを利用規約で義務づけなければならないという点が含まれる。
• 不誠実なユーザーは規範に従わない AI の言い換えツールで検出をかわすだけだと論じ、そうしたマークを 1 ステップで消す手段として James Padolsey の Declaude を挙げる。
• 8 月時点の OpenAI のヘルプ記事の文言について、自分が OpenAI にいたら、頼まれない限り ChatGPT は生成したテキストに透かしを入れないと公に強く打ち出す、と書いた。

[B] TechCrunch — Anthropic says it will watermark text generated by its AI models, by Ivan Mehta (2026-08-11)

https://techcrunch.com/2026/08/11/anthropic-says-it-will-watermark-text-generated-by-its-ai-models/

• Anthropic は更新したサポートページで透かしを認め、8 月 2 日より後に出るすべてのモデルに、コンピューターが生成したテキストとファイルの両方に透かしを入れる技術が自動で入るとし、ファイルには C2PA を使うとした。
• 対象の製品として Claude platform API、Claude、Claude Code、Claude Cowork、Claude Tag を挙げる。
• Substack が 7 月に Pangram と組んで AI 生成コンテンツに印を付けるようにしたこと、Suno が楽曲にマークを付けると述べたことも伝える。

[C] Google AI Developers Forum — Does Gemini API text output carry SynthID watermarking? (2026-08-05〜2026-08-19)

https://discuss.ai.google.dev/t/does-gemini-api-text-output-carry-synthid-watermarking-gemini-2-5-flash-lite-gemini-3-1-flash-lite-eu-ai-act-art-50-2/177241

• gemini-2.5-flash-lite から gemini-3.1-flash-lite に移る EU の開発者が、ガイドライン C(2026) 5054 の point 74 によりモデル提供者のマーキングに頼れるため、API のテキストに透かしが入っているかを尋ねた。
  • 実際の generateContent のレスポンスに来歴のメタデータは見当たらず、Google の確認ツールにもテキストを確かめる経路はなかったとする。
• 2026-08-05 の返信は、API で生成したテキストには SynthID の透かしは入っていないと答えた。
  • テキストへのネイティブな透かしも今のところ予定はないとした。
• 同じアカウントが 2026-08-19 にこれを訂正し、Gemini API で生成したテキストには実は SynthID の透かしが入っていると書いた。
  • Google AI Studio や antigravity で生成したテキストも同じだとした。
• SynthID が API のテキストに最初から入っていたのか、いつからなのかを尋ねた追加の質問には、ページ上で答えがなかった。

[C] OpenAI Developer Community — OpenAI's approach to EU text provenance rules (2026-10-05)

https://community.openai.com/t/openais-approach-to-eu-text-provenance-rules/1403521

• 取得時点で、発表のスレッドへの返信は 2 件だった。
• 1 人は、textGrain の背後にある統計を、2022 年 11 月より前から現在までの LinkedIn の投稿に当てはめてみたいと書いた。
• もう 1 人は詩の形で、自分だけが読み手である私的な ChatGPT の会話の語を EU と OpenAI が変えることに異を唱えた。

メモ

• この政策の項目がスコープの規則を満たす理由は、OpenAI の API で開発するチームに新しい設定と準拠の判断が加わり、EU で Codex と ChatGPT が出力するものが変わること。
  • API には、組織かプロジェクトごと、モデルごとの新しいスイッチ (Data controls → Text provenance) が加わり、既定はオフで、リクエストの変更は要らない。
  • 出力が EU で使われる提供者は、EU 外の事業者でも川上のモデル提供者のマーキングに頼ってよく (ガイドラインの point 74)、システムが 2026 年 8 月 2 日より前に市場に出ていれば 2026 年 12 月 2 日までに準拠しなければならない。
  • コーディングエージェントでは、EU の Codex のテキスト出力に今後数週間で透かしが入る一方、ガイドラインはソースコード (一体をなすコメントを含む) を義務の外に置いている。
  • Claude Code の出力にはすでにモデルの段階で世界中で透かしが入っており、ベンダーと地域によって振る舞いが違う。
  • 結果から何が言えるかは検出の限界で決まり、心理学のような英語では 200 トークンで約 80%、400 トークンで 95% でも、数学ではずっと低く、語の 4 分の 1 を置き換えると 17%、EU の言語では 42.2%〜69.0% になる。
• OpenAI のページどうしで、時期と製品の書き方が食い違う。
  • 投稿は ChatGPT と Codex への EU の透かしを今後数週間でとしているが、ヘルプ記事は EU の ChatGPT のテキストにすでに透かしが含まれるように書き、理由も EU の ChatGPT ユーザー向けとして示して Codex には触れていない。
  • 2026-10-06 の時点で、API の changelog にも ChatGPT & Codex の changelog にもテキストの透かしのエントリはなく、API のオプトインはヘルプ記事にしか書かれていない。
• ChatGPT や Codex のどの出力が eligible なのかは、読んだどのページにも定義がない。
  • The New Stack は、eligible な Codex の出力とコードに特化した検出率を OpenAI に問い合わせたが、記事の公開時点で回答はなかった。
• ヘルプ記事はコード断片 (code snippets) の除外を Code of Practice によるものとしているが、規範の本文が除外するのは 200 トークン未満の非常に短いテキストだけで、ソースコードの除外は欧州委員会のガイドライン (point 68) によるもので、そこではコードと一体をなすコメントも除かれる。
  • Anthropic はコード中のコメントにも透かしが入りうるとしており、point 68 はそれを認めているが求めてはいない。
• 自社の AI モデルが生成するすべてのテキスト出力という Gizmodo の書き方は一次情報を誇張しており、一次情報は ChatGPT と Codex の透かしを EU に、API の透かしをオプトインに限っている。
• 検出の数値は別々のデータセットから出ており、1 本の曲線にはならない。
  • 長さのグラフは心理学の 400 トークンで約 95% だが、編集の試験の出発点は、英語の ELI5 の回答全般での 400 トークンの約 92%。
  • Gizmodo Japan はグラフから 400 トークンで約 90%、数学で 40%〜60% と読んでいるが、OpenAI は本文で数学の数値を示していない。
  • 言語のグラフ (偽陽性率 1% で 42.2%〜69.0%、24 言語、翻訳した合成プロンプト) は文章の長さを示しておらず、80% や 95% の数値とは並べられず、強さを上げた後の改善も棒でしか示されていない。
• textGrain が SynthID のテキスト版と同等以上だったという主張には数値も設定も試験セットも添えられておらず、技術レポートにも実験がない。
  • arXiv の SynthID-Text の数値 (偽陽性率 1% で 200 トークン 39%、400 トークン 56%〜59%) は別のモデル、プロンプト、設定によるもので、textGrain との比較にはならない。
• 品質の表では、8 つのベンチマークのうち 5 つで透かしありが高く (最大は Terminal-Bench Science 0.1 の +3.10 ポイント)、3 つで低い (最大は DeepSWE v1.1 の −1.12 ポイント) が、実行回数も信頼区間も示されておらず、ヘルプ記事はこの差を実行ごとのノイズとしている。
  • Astra, max はおそらく推論の設定を最も高くした gpt-6-astra だが、これは API の changelog からの推測で、投稿には書かれていない。
• 公開されていないものは、配備したパラメーター (ブロック数 B、列数 m、エントロピーの予算 β、文脈の窓 L_ctx)、一部のモデル (select models) の一覧 (設定画面にしか出ない)、オープンソース版の公開日とライセンス、約束された技術レポートの更新。
• API 顧客には検出の空白がある: ガイドラインの point 70 は、検出の手段のないマーキングでは準拠にならないとするが、OpenAI のテキストの検出器は、オプトインした API 顧客にも開かれていない。
  • Anthropic は、プライベートプレビューの検出 API を、自らの AI Act への準拠のために透かしの確認を同じく義務づけられる企業にも提供している。
  • 規範の Sub-measure 2.1.2 は、自由形式のテキストの検出を期間を限って検証済みの専門家ユーザーに制限することを署名者に認めており、OpenAI もこれを根拠にしている。
  • OpenAI のマーキングに頼る API 顧客が、検出できることをどう示すのかは未解決の問い。
• Gruber が紹介した Thompson の要約は、提供者は透かしの除去を規約で禁じなければならないとするが、規範の Measure 1.2(b) が対象にするのはメタデータのマーキングで、OpenAI や Anthropic の規約が透かし入りのテキストの書き換えを禁じているかは確かめていない。
• Google については、DeepMind 自身のページがテキストの透かしを主張するのは Gemini のアプリとウェブだけだが、フォーラムの返信 (C) は Gemini API、AI Studio、Antigravity のテキストへの SynthID の透かしをまず否定し、2026-08-19 に肯定した。
  • 公式の文書は見つからず、返信者が Google の社員かどうかも未確認。
  • Google がユーザーに透かしを外せるようにしたという Gizmodo の記述は画像、動画、楽曲についてのもので、開かなかった検索結果は、これを SynthID を残したまま目に見える透かしだけを切り替える機能だと説明している (未確認)。
• 2026-09-29 のノートは、Claude Sonnet 5.5 に見えない透かしがあるという SiliconANGLE の報道を未確認としていたが、Anthropic のサポートページはいま、Sonnet 5.5 をファーストパーティの画面とクラウドパートナーでのテキストの透かしと C2PA の対象に挙げている。
• Anthropic の表でチェックマークが 1 つの行は、保存したテキストで列の位置が失われており、Mythos 5、Opus 4.7、4.6、4.5、Sonnet 4.6 と 4.5、Haiku 4.5 がどのマークを持つかは今回の実行では確定できない。
• クラウドパートナーについて、OpenAI はパートナーのクラウド上の自社モデルへの透かしを今後数週間でとしているが、今回の検索では Microsoft Foundry や Azure OpenAI でのそれを扱うページは見つからなかった。
• arXiv のプレプリントは OpenAI の発表より前のもので、OpenAI がテキストの透かしを作りながら公開を見送ったとまだ書いており、査読も経ていない。
• Gruber は 8 月の時点で、OpenAI のヘルプ記事の文言を、頼まれたときだけ、あるいは EU だけで透かしを入れるという意味かもしれないと読んでおり、これは OpenAI が発表した分け方に近い。
• The New Stack は、所有者が OpenAI と Anthropic に投資していることを開示している。

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

• テキストの出力が EU の人に届く、OpenAI の API 上の製品ごとに、プロジェクト単位で Allow text watermarking をオンにするかを決め、設定画面が対象として示すモデルを記録し、2026 年 12 月 2 日より前に第 50 条 2 項の記録に判断を残す。
  • その前に、出力がそもそも対象かを確かめる: ソースコード、エージェントどうしの通信、短い文字列、ガイドラインの point 68 と 87 の狭い B2B の場合は対象外。
• 透かしがユーザー向けの文章 (チャットの回答、生成した記事、メール) にだけかかり、社内のパイプラインや構造化出力ではオフのままになるようプロジェクトを分け、設定がプロジェクトに従うことを確かめる。
• 1 つのモデルで、透かしをオンにしたプロジェクトとオフにしたプロジェクトの両方でチームの評価を走らせ、タスクのスコアと、プロンプトごとに n 回サンプリングしたときの重複率を測る (固定の鍵で繰り返しの答えが似通うことがあるため)。
• Codex の展開が EU に届いたら、EU にいる開発者に、Codex のどの出力 (説明、コミットメッセージ、PR の説明、コメント) に透かしが入るかを確かめてもらい、eligible な出力についての OpenAI の回答を追う。
• OpenAI、Anthropic、Google のテキストの透かしを、既定、地域、画面 (API、チャットアプリ、Codex や Claude Code、クラウドパートナー)、コードの扱い、誰が検出できるかで比べる 1 ページの比較表をチーム向けに作る。
• arXiv の著者の構成 (MarkLLM 経由の SynthID-Text を Gemma-2-9B か Llama-3.1-8B で動かす) でオープンなモデルを使い、OpenAI のグラフの形を再現して、文章の長さ、類義語の置き換え、言語 (日本語を含む) に対する検出率を測り、textGrain のオープンソース版が出たらそれも加える。
• 勉強会の題材として、textGrain のレポートの Algorithm 1 (鍵付きの語彙のブロック、エントロピーの予算のもとでの Sinkhorn のカップリング、Gamma(n, 1) の検定) を、SynthID-Text のトーナメントサンプリングと並べて読み解く。
• 学術・研究のパートナーと組むチームは、Content Provenance API のフォームからテキストの検出器の利用を申し込める (フォームは、組織が確認したい形式を尋ねる)。

2. 🎼 Cloudflare が、画像も入力でき型付きの答えを確率とともに返す Apache 2.0 の決定モデル Clef と Clef-flash を Workers AI で公開し、その強化学習によるファインチューニングの提供を、まず同社のフォワードデプロイドエンジニアを通じて始めた

• 選定 / 影響度 2 / 将来性 2 / 重要度 2 / 起点 10-01、期間前の出来事 / 種別: リリース / 領域: モデル、エージェント開発。
• 候補になったフィード項目:
  • zenn-trending 10-04 Cloudflare の判定モデル Clef を Workers AI で触ってみた
  • ainews 10-03 not much happened today (Ollama での Clef)
• 起点: Cloudflare は期間の 2 日前、10-01 の Birthday Week で Clef を発表し、その発表は今回の実行で ainews と zenn-trending を通じて初めてフィードに現れた。
• 関連: 2026-09-27 のトピック 2 は Clef の比較相手である決定モデル Jev を、2026-10-01 のトピック 5 は OpenAI の Decisions API を扱った。
  • Clef は別のベンダーによる別のリリースなので、継続ではなく新しいトピックとした。

収集した情報

[A] Cloudflare — Introducing Clef: our open-source decision models, and new RL fine-tuning platform, by Michelle Chen, Alex Reneau and Kevin Flansburg (2026-10-01)

https://blog.cloudflare.com/clef-decision-models/

• Birthday Week の記事で、タグは Machine Learning、Open Source、Workers AI。
• Jev を、範囲の決まった構造化出力を安く、速く、一貫して出し、判断が要る場面でワークフローに組み込めるモデルを持ち込んだものと位置づける。
• Cloudflare が学習させた 2 つの決定モデル Clef と Clef-flash を、Workers AI でホストして公開した。
• Jev Decision Index で評価すると現時点では Clef が首位だとし、全結果をライブのベンチマークのデモサイト (clef-evals.workers-ai-mle.workers.dev) に載せる。
• より賢く、より速く、Jev の API と完全に互換だとうたう。
• 重みは Hugging Face で Apache 2.0 のライセンスで公開し、手元で動かせる。
• 顧客が Clef をファインチューニングできる新しい強化学習 (RL) の製品も、あわせて披露した。
• 決定モデルは確率付きの型付きの答え (出力) を返し、コードはそれを使ってチケットを振り分けたり、エスカレーションを起こしたり、人に判断を委ねたりできると説明する。
• Cloudflare の Threat Intelligence チームは Browser Run と組み合わせてウェブサイトのドメインの分類に Clef を試しており、たとえばファッションサイトの確率 95%、EC 85%、フィッシング 1% 未満のように返す。
  • Clef はサイトの取得、描画、分類に 2.2 秒かかり、同じワークフローで社内の最速の汎用 LLM の gpt-oss-120b は 4.7 秒かかったうえ、分類を 2 つしか返さなかった。
• 名前は音楽の音部記号 (clef) から取り、CF の文字は Cloudflare を思わせるという。
• 1 つ目の違いとして、ビジョンエンコーダーを持ち、画像を入力して視覚的な内容を分類できる点を挙げ、現在はテキストの分類しかできない Jev と対比する。
• 2 つ目の違いは 64k のコンテキストウィンドウ (Jev は 32k) だとする。
• 抜粋した Decision Index の行 (Clef / Clef-flash / Jev / DiffusionGemma Jev / Kev 9B / Laya の順):
  • BFCL case exact は 98.47 / 98.76 / 95.75 / 96.52 / 94.51 / 38.13。
  • ToolRet nDCG@10 は 69.19 / 66.43 / 65.28 / 61.21 / 64.26 / 12.69。
  • API-Bank accuracy は 91.93 / 93.11 / 88.19 / 83.66 / 56.30 / 11.41。
  • Home appliances case exact は 82.95 / 97.73 / 52.27 / 42.05 / 25.00 / 0.00。
  • When2Call accuracy は 72.37 / 65.58 / 80.97 / 75.44 / 49.62 / 11.94。
  • BANKING77 macro-F1 は 94.20 / 90.93 / 79.74 / 74.28 / 84.83 / 14.29。
  • CLINC150+OOS macro-F1 は 97.43 / 66.77 / 89.27 / 83.49 / 79.03 / 3.19。
  • BRIGHT nDCG@10 は 45.91 / 39.26 / 47.52 / 42.94 / 38.53 / 19.90。
  • Amazon ESCI macro-F1 は 57.48 / 57.39 / 55.21 / 53.37 / 49.22 / 24.40。
  • PhishNChips accuracy は 79.60 / 75.05 / 62.55 / 85.35 / 50.75 / 50.15。
• TypeSafe 自身の評価スイートでは、Clef のモデルが 4 分野のうち 3 分野で Jev を上回ったとする (Clef / Clef-flash / Jev)。
  • 請求書の処理は 64.7 / 57.1 / 61.8。
  • カスタマーサービスは 76.3 / 77 / 76.0。
  • セキュリティインシデントは 62.9 / 61.7 / 61.7。
  • エージェントのトレースのオブザーバビリティは 68.5 / 69.8 / 71.6。
• 実行した 43 の評価ベンチマーク全体で、Clef のモデルはレイテンシでほかの決定モデルを上回ったとし、例外の Laya は非常に速いが、上のベンチマークでは品質と引き換えになっているとする。
  • レイテンシの中央値は Clef 209.3 ms、Clef-flash 38.8 ms、Jev 524.1 ms、DiffusionGemma Jev 84.4 ms、Kev-9B 51.4 ms、Laya 5.8 ms。
  • p95 のレイテンシは Clef 238.6 ms、Clef-flash 122.4 ms、Jev 536.0 ms、DiffusionGemma Jev 211.2 ms、Kev-9B 187.9 ms、Laya 222.5 ms。
• Workers AI ではエッジの GPU で動くためネットワークのレイテンシが小さく、Clef をエージェントのホットパスに置いて、行動を担う Workers AI 上の LLM と組み合わせられるとする。
• REST の呼び出しは、model、state、questions を https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef に POST するもので、質問の型は noul、choice (criteria のマップ)、score (順序付きの criteria のリスト)。
• Clef も Jev と同じく厳密に型付けされた出力を返し、API も完全に互換なので、切り替えはとても簡単だとする。
• Clef はより強力な精度重視のモデル、Clef-Flash はレイテンシが重要な判断に向くモデルと位置づける。
• リクエストとレスポンスを読まず、保存せず、学習に使わないことを保証する (ファインチューニングの製品を使う場合を除く)。
• ファインチューニングは、まずフォワードデプロイドエンジニア (FDE) のチームが実地で組むパートナーとして提供し、後に顧客がモデルを学習させて Cloudflare に再デプロイできるセルフサービスのプラットフォームとして提供する。
• Jev のローンチの週に、Cloudflare は Matt Mastracci の研究と彼の vLLM のプルリクエスト 57250 をもとに、logprobs を公開して決定的な確率を出すよう DiffusionGemma を改造した。
• 現在は Qwen をベースモデルとし、決定モデルの用途に合わせて事後学習している。
• 推論では、Qwen で prefill だけを行い、スキーマで有効な選択肢を並列にスコア付けする。
• 判断のステップは非自己回帰で、トークンを 1 つずつ生成する中間のテキストはない。
• ヘッドは専用の 2 段階のアテンションのルーティングを使い、選択肢ごとの根拠のルーティング、フィールドをまたぐ共同のアテンション、スキーマに縛られたスコア付けを一体にし、選択肢の間で意味の意図を保つための語彙的な事前分布 (lexical prior) も使う。
• Clef では Qwen3.8-27B、Clef-flash では Qwen3.5-9B を凍結し、ルーティングのヘッドと rank-256 の低ランクアダプターを共同で最適化した。
• 事後学習では、有効なスキーマの出力に対するラベル平滑化した交差エントロピーと、確率の較正を詰めるための Brier 損失を組み合わせる。
• 学習データは、フィールドの順序、プロンプト、スキーマの構造を入れ替えた社内の合成データセット。
• Reinforcement Learning for Calibrated Decisions (RLCD) は 2 つ目の最適化の目標で、順序尺度で隣り合う選択肢に部分点を与え、完全に正確なレコードの出力に報酬を与え、分布のずれを防ぐための参照ペナルティを課す。
• 社内でのファインチューニングの対象は、Trust & Safety への申告、Cloudflare Support のトリアージ、Bot の製品でクローラーが良いボットか悪いボットかの判断で、15 年以上のネットワークのデータを使う。
• セルフサービスのプラットフォームでは、データの収集、ファインチューニング、モデルの再デプロイをすべて Cloudflare の上で行えるようにする。
• RL のパイプラインは次の 5 つの要素を組み合わせる。
  • Cloudflare AI Gateway で AI のトラフィックをすべて通し、用途ごとのリクエストのデータセットを自動で作る。
  • Cloudflare Workers AI で、ベースの Clef のモデルに対するロールアウトを生成する。
  • Cloudflare Containers を、エージェントの行動をスコア付けし再生する RL のサンドボックスにする。
  • 新しい Trainer で、ファインチューニングした Clef のモデルの重みを更新する。
  • Cloudflare Workers AI と BYO Model で、ファインチューニングしたモデルを Workers AI に再デプロイする (Replicate の買収以来の Bring Your Own Model (Cog) の取り組みにもとづく)。
• Jev への関心は、速く、小さく、用途を絞った分類器のモデルへの需要を示しており、RL の環境を試し始める領域としてここを選んだと説明する。
• 既存の顧客はフォームからデザインパートナーに応募でき、記事は RL のサービスの価格も日程も示していない。

[A] Cloudflare — Introducing Clef: Cloudflare's first open-source decision models, now on Workers AI (changelog, 2026-10-01)

https://developers.cloudflare.com/changelog/post/2026-10-01-clef-workers-ai/

• @cf/cloudflare/clef と @cf/cloudflare/clef-flash は、Cloudflare Workers AI のチームが学習させた最初のモデル。
• 解析すべき自由形式の出力も、待たされる推論トークンもないとする。
• 43 回のベンチマークの実行全体で、中央値で Clef は Jev の 2.5 倍、Clef-flash は 13 倍速かったとする。
• 10 の判断のベンチマークのうち 7 つで Clef のいずれかのモデルが首位で、Jev やほかのオープンな決定モデルを上回ったとする。
• Clef は 27B で最高精度の判断向け、Clef-flash は 9B でレイテンシが重要なホットパスの判断向けで、どちらもコンテキストウィンドウは 64K トークン。
• Clef は System One API に従うので、既存の Jev の組み込みは、エンドポイントとモデルを変えるだけで Clef に切り替えられる。
• 1 リクエストで最大 64 の質問を 3 つの型で尋ねられる: noul、choice (選んだ選択肢、選択肢ごとの確率、確信度の値)、score (確率で重み付けしたスコアと段階ごとの確率)。
• 用途として、サポートのトリアージ、脅威インテリジェンス、Trust & Safety、エージェントのガードレール、画像の分類を挙げる。
  • エージェントのガードレールでは、エージェントがツールを呼ぶ前に、この行動をとるべきかを数十ミリ秒で確かめられる。
  • 画像の分類では、1 リクエストで最大 4 枚の画像を state とともに渡せる。
• Clef は Workers AI のバインディング (env.AI.run())、/ai/run の REST API、AI Gateway から使える。
• RL によるファインチューニングのサービスは、デザインパートナーとして参加する申し込みから始まる。

[A] Cloudflare — Workers AI model pages for clef and clef-flash, and Workers AI pricing (2026-10-06 取得時点)

https://developers.cloudflare.com/workers-ai/models/clef/ / https://developers.cloudflare.com/workers-ai/models/clef-flash/ / https://developers.cloudflare.com/workers-ai/platform/pricing/

• Clef は、state と型付きの質問のスキーマを判断に変える 27B のマルチモーダルな決定モデルと説明される。
• Clef-flash は、速い 9B のマルチモーダルな決定モデル。
• どちらのページも、モデルは state をテキスト、JSON、画像、動画として読み、すべての質問の許されたすべての選択肢に確率を返すとする。
• どちらもコンテキストウィンドウ 65,536 トークン、Vision: Yes、Cloudflare-hosted のバッジ、タスクのラベル Text Generation を示す。
• 単価は、Clef が入力 100 万トークンあたり $0.24、Clef-flash が $0.09。
• 料金ページは @cf/cloudflare/clef を入力 100 万トークンあたり $0.240 (21818 neurons)、@cf/cloudflare/clef-flash を $0.090 (8182 neurons) とし、出力の価格は載せていない。
• Workers AI の価格は 1,000 Neurons あたり $0.011 で、無料の割り当ては Free と Paid のどちらの Workers プランでも 1 日あたり合計 10,000 Neurons。
• 同じページで、ベースモデルの @cf/qwen/qwen3.8-27b は入力 100 万トークンあたり $0.450、出力 100 万トークンあたり $3.200。
• model は必須で、^\s*(clef|clef-flash)\s*$ に一致しなければならない。
• state は文字列か、レコード、チャットのログ、アプリケーションの状態のような構造化データ (オブジェクトか配列) で、長いテキストの state はモデルのトークンの上限に収まるよう切り詰められる。
• questions は 1〜64 の質問で、id は英字、数字、_、.、- からなる 100 文字以内。
• images は System One API への Clef の拡張で、PNG、JPEG、WebP の画像を最大 4 枚、各 4 MiB・16 メガピクセルまで、デコード後の合計 8 MiB まで、リクエストの本文全体で最大 13 MiB。
  • リモートの URL は受け付けない。
• レスポンスは model、質問の id をキーにした answers、usage を持つ。
• usage のサンプルでは、score の答えは確率で重み付けしたスコア (0 が最も低い段階)。

[A] Cloudflare — Cloudflare/clef and Cloudflare/clef-flash model cards on Hugging Face (2026-10-06 取得時点)

https://huggingface.co/Cloudflare/clef / https://huggingface.co/Cloudflare/clef-flash

• Clef は 1 回の順伝播で、すべての質問の許されたすべての選択肢に確率を返す。
• 自由形式のテキストの生成も、出力の解析もない。
• Clef の API は Jev と SystemOne に完全に互換だとする。
• Clef は Qwen/Qwen3.8-27B から、Clef-Flash は Qwen/Qwen3.5-9B から事後学習しており、後者のモデルツリーの起点は Qwen/Qwen3.5-9B-Base。
• バックボーンはビジョンエンコーダーを含み、標準的な分割された safetensors で保存されている。
• Joint schema head は、バックボーンの最終の隠れ状態を読み、state の根拠を各質問へ振り向け、すべての質問のすべての選択肢をまとめてスコア付けする小さな Transformer のヘッド。
• 出力は、質問ごとに許された選択肢 1 つにつき 1 つのロジットで、質問ごとに softmax をかける。
• ファイルは、バックボーンの分割ファイル、joint_head.safetensors、joint_head_config.json、joint_schema_model.py (レコードのエンコード、バッチ化、モデル、load_release_model、systemone)、トークナイザーとプロセッサーのファイル、Apache-2.0 の LICENSE。
• torch 2.11 と transformers 5.10.2 を使い、H200 1 枚で試験したとする。
• systemone は、Jev / SystemOne の POST /v1/systemone のリクエスト本文を受け取り、同じ形のレスポンス本文を返す。
  • choice の答えは choice、confidence、probabilities を、score の答えは期待値の score、confidence、legend、probabilities を、noul の答えは真である確率を持つ。
  • instructions は省略でき、リクエストに images と videos を加えられる。
• encode_record は max_length (既定は 16,384 トークン) と max_state_tokens を受け付ける。
• 全体の表は Decision Index 0.2.1 のスイートを社内で実行したもので、ベンチマークの 41 行と、レイテンシの中央値と p95 の行からなる。
• ブログの抜粋にない行 (Clef / Clef-flash / Jev):
  • RouterBench は 79.7 / 79.9 / 79.9、SGD/SGD-X は 43.8 / 34.2 / 43.0 (Kev 9B は 64.0)。
  • ANLI は 69.8 / 59.1 / 74.8、ContractNLI は 81.4 / 84.3 / 71.7。
  • MMLU は 90.3 / 91.8 / 91.7、MMLU-Pro は 65.9 / 65.3 / 82.7。
  • GPQA Diamond は 48.0 / 51.0 / 78.3、BBH は 73.7 / 68.9 / 92.9。
  • GSM8K は 80.8 / 67.3 / 79.9、CRUXEval は 86.7 / 86.1 / 73.0、CLadder は 94.0 / 97.7 / 72.6。
  • HoVer は 65.2 / 61.2 / 72.9、VAST は 59.5 / 49.6 / 64.6、NLI4CT は 82.9 / 78.6 / 84.1。
  • RAGTruth の hallucination F1 は 79.4 / 35.6 / 76.5、ForecastBench の Brier (低いほど良い) は 13.9 / 10.6 / 17.4。
  • Habermas Machine は 68.7 / 71.8 / 45.9、MuSR は 83.5 / 86.0 / 66.1、New Yorker は 69.5 / 66.1 / 70.1。
• カードの Laya の値は 2 行でブログとわずかに違い、ToolRet は 12.8 と 12.69、API-Bank は 11.5 と 11.41。
• ワークフローの評価は、Typesafe Evals の 4 つのエンドツーエンドの業務ワークフローでの判断の正確さを、合意にもとづく参照ラベルに対して採点したもの。
  • カードには請求書の処理の Primary action の行が加わり、Clef 86.2、Clef-flash 73.3、Jev 83.1。
• ライセンスは、ベースモデルに合わせた Apache-2.0。
• パラメーター数は Clef が 27B、Clef-Flash が 9B で、BF16。
• 先月のダウンロード数は Clef が 5,416、Clef-Flash が 8,075 で、モデルツリーには量子化版が 18 と 30、ファインチューニング版が 2 と 6 ある。
• どの Inference Provider もこのモデルを配備していないと表示される。

[A] Cloudflare — Decision Model Leaderboard (データの生成は 2026-10-01、2026-10-06 取得時点)

https://clef-evals.workers-ai-mle.workers.dev / https://clef-evals.workers-ai-mle.workers.dev/data/leaderboard.json

• ページは、オープンなモデルとホスト型の決定モデル (型付きの質問を入れると較正済みの確率が出る) を、コミュニティの Decision Index 0.2.1 のスイートで採点したものと説明する。
• Cloudflare 以外の結果、ベンチマークのスイート、採点の式はすべて、multimodalart とコントリビューターが Hugging Face で保守する元の Jev Decision Index から取ったとする。
• Clef と Clef-flash はモデルの作者である Cloudflare が実行したもので、上流のボードでは再現されていない。
• エントリが実行しなかったベンチマークは、答えなかったリクエストを誤りとして数える上流の規則に従って 0 点とする。
• 自己申告のレイテンシは作者自身の配信基盤で測ったもので、上流の基準のハードウェア (NVIDIA RTX PRO 6000 1 枚) ではないため、直接は比べられないとする。
• このページは非公式で、上流のボードとも TypeSafe とも関係がないと明記する。
• 各ベンチマークは k = clip((s − c) / (1 − c)) で偶然の当たりを補正し、Decision Index は 5 分野の加重平均の 100 倍。
• 分野の重みは、知識 25.85%、言語 25.85%、検索と分類 20.02%、ツールと自動化 18.28%、芸術と人の好み 10%。
• データは 2026-09-28 に生成された上流の Decision Index 0.2.1 を写したもので、指数のパネルは 38 のベンチマーク、モデルは 73。
• 指数の上位は次のとおり。
  • Clef は 61.21 (自己申告、38 のうち 36 のベンチマークをカバーし、iSarcasmEval と HLE が欠ける)。
  • Jev は 57.91 (クローズドのホスト型 API、ECE 0.074)。
  • Surogate Rune 26B-A4B v3 は 57.44、Decider chat · Gemma-4-31B は 57.33。
  • Clef-flash は 57.07 (自己申告、こちらも 38 のうち 36 をカバー)。
  • AutoJev-27B は 56.40。
• ほかに、JoshuaSP diffusiongemma (open-jev) が 49.47、Kev 9B が 38.48、Kev 4B が 34.64、Laya が 6.04。
• 分野別の Clef と Jev のスコアは、知識 51.2 / 51.4、言語 61.2 / 62.0、検索 62.5 / 55.4、ツール 81.2 / 75.1、芸術 47.8 / 37.7。
• 較正のグラフは ECE を報告していないモデルを表示しないとして挙げており、データにも Clef と Clef-flash の ECE はない。

[A] multimodalart and contributors — Jev Decision Index 0.2.1 data and methodology (2026-10-06 取得時点)

https://huggingface.co/spaces/multimodalart/jev-decision-index / https://huggingface.co/spaces/multimodalart/jev-decision-index/resolve/main/data/methodology-v0.2.1.json / https://huggingface.co/spaces/multimodalart/jev-decision-index/resolve/main/data/index.json

• 0.2.1 版の日付は 2026-09-28 で、Jev を jev-1.13.0 (Full release v1) として採点している。
• 2026-10-06 に取得した指数のデータに、Clef のエントリはない。
• 再現は NVIDIA RTX PRO 6000 (Blackwell Server Edition、96 GB) 1 枚で、1 回の実行に GPU 1 枚を使い、Jev は TypeSafe のホスト型 API (jev-1.13.0) を HTTPS で呼ぶ。
• Jev のレイテンシは HTTPS とサービス側の並行スケジューリングを含み、モデルの推論だけを切り出したものではない。
• 計算時間の計測は HTTP やネットワークを含まず、Jev の HTTPS のレイテンシと直接は等価でないとする。
• latency-v1 のプロトコルでは、すべての参加者が同じ 750 行を、1 プロセスから 1 件ずつリクエストを送って処理し、Jev には逐次のクライアント 1 つでのネットワーク API のレイテンシを当てる。
• 指数の注記は、すべてのスコアをカバー率で補正しているため、答えなかったリクエストや対応していないリクエストは誤りとして数えること、点推定だけで不確かさの区間はまだないことを述べる。
• RouterBench と SGD はボードには残るが指数には入らない: RouterBench はプロンプトが GPT-4 を最良のルートと明かしてしまい、SGD はビルドの不具合で再実行を待っている。

[A] Ollama — clef model page and the Decision capability documentation (2026-10-06 取得時点)

https://ollama.com/library/clef / https://docs.ollama.com/capabilities/decision

• clef のページは、ダウンロード数 4,529、取得の前日の更新、タグ clef:latest と clef:27b (18GB、入力はテキストと画像) を示す。
• タグの一覧は 256K のコンテキストウィンドウを示す一方、readme の要点は、64K のコンテキストウィンドウで Jev の 32K の 2 倍の state を保持できるとしている。
• Clef には Ollama 0.35.1 以降が要る。
• 決定モデル全般には Ollama v0.35.0 以降が要り、ドキュメントは決定モデルとして Nimble、Tev1、Clef、Clef Flash を挙げる。
• ローカルのリクエストに API キーは要らない。
• Clef は Ollama の /v1/systemone エンドポイントで動き、Clef のプロンプトは Ollama が組み立てる。
• questions は名前付きの質問を 1〜64 受け付ける。
• choice は 2〜26 の選択肢、score は 2〜26 の段階を受け付ける。
• 画像は base64 の PNG、JPEG、WebP で、すべての質問が共有し、リクエストの順に並び、URL や data URL は使えない。
• confidence は 0 から 1 の値で、確率がどれだけ集中しているかを示す。
  • 答えが正しい確率ではないと明記している。
• 2 つの選択肢が同点のときはモデルの選択肢の順に従うので、優先したい選択肢を先に置くよう勧める。
• TypeSafe の Python SDK は、TYPESAFE_BASE_URL=http://localhost:11434 と任意の API キーで Ollama に向けて使える。
• 決定モデルはまだ Ollama の CLI にも Ollama の Python と JavaScript のライブラリにも入っていないとしながら、ページの冒頭には Python と JavaScript の ollama.systemone(...) の例が載っている。
• readme は、Clef が Cloudflare の決定モデルのリーダーボード Decision Index で首位に立ち、そのスイートの大半で Jev を上回るとうたう。
• 例の 1 つは、エージェントのツール呼び出し send_email(...) を、実行前に harm の noul で審査するもの。

[A] ggml-org — New in llama.cpp: Decision Models, by Xuan-Son Nguyen and Victor Mustar (2026-10-02)

https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp

• llama.cpp の server が /v1/systemone エンドポイントで決定モデルに対応した。
• API は TypeSafe の Jev とともに導入された System One の形式に従うので、既存のクライアントはベース URL を変えるだけでよく、実装は PR #29818。
• 対応モデルの表は Clef (ggml-org/Clef-GGUF) を、27B、Qwen3.8-27B ベース、英語、画像あり、Apache 2.0 とし、速度の数値は載せていない。
• 同じ表の速度は NVIDIA RTX PRO 6000 1 枚で 1 つの質問に答えるまでの時間の中央値で、Julia-1 3 ms、Laya 5 ms、Kev-4B 12 ms、lev 36 ms、OpenJev 43 ms。
• 本文は、画像も読めるモデルがある (執筆時点では OpenJev) としている。
• score は低い順に 2〜10 の段階を受け付ける。

[B] Flavio Copes — A deep dive into Clef, Cloudflare's decision model (2026-10-01)

https://flaviocopes.com/clef/

• 記事の例はすべて自分の Cloudflare のアカウントで両方のモデルを使って実行し、載せた出力は実際のものだとする。
• Clef を 2 週間で 3 つ目の決定モデルとし、09-15 の Jev、09-29 に限定プレビューで出た OpenAI の Decisions API、その 2 日後の Clef を挙げる。
• Choice は定義した 2〜255 の選択肢から 1 つを選び、Score はデータを 2〜10 段階の順序尺度に置く。
• 何も生成しないので、答えに定義していない選択肢が入ることはなく、直すべき JSON もない。
• RLCD は、TypeSafe が Jev の背後の手法に使っているのと同じ名前だと指摘する。
• 価格は 10-01 時点の Workers AI の料金ページから取り、受け取ったレスポンスはすべて "output_tokens": 0 だったとする。
• まず Clef-flash から始め、ラベル付きの例で Flash の誤りが示された質問だけを Clef に移すよう勧める。
• 手で作るトークンには Workers AI - Read と Workers AI - Edit の両方が要る。
• REST API は答えを Cloudflare の外側の封筒 (success、errors、messages) で包むので、Jev の形の部分は result の下にあり、model はバージョン番号なしで clef-flash と返る。
• 同じサポートチケットで、両モデルとも確信度 0.91 で bug_report を選んだが、深刻度は Clef で 1.38 (確信度 0.22)、Clef-flash で 1.11 (0.43)、has_repro_steps は 0.04 と 0.54 だった。
• Workers AI のバインディングは封筒なしで Jev の形のオブジェクトを返すが、10-01 時点では wrangler types が生成する型がまだ Clef のモデルを知らなかった。
• Jev からの切り替えでは、https://api.typesafe.ai/v1/systemone に代わる新しい URL、Cloudflare の API トークン、clef か clef-flash の model、REST での result の下の答えが変わる。
  • jev-latest を残したままだと、リクエストはエラーコード 5006 で失敗する。
  • TypeSafe の JavaScript SDK は独自の fetch アダプターを挟めば動き続けるが、systemOne() 以外は動かない。
• 画像は Jev にない機能で、最大 4 枚の PNG、JPEG、WebP を base64 で送り、リモートの URL は受け付けない。
• 元の PNG (1.3 MB と 575 KB) は、このモデルのコンテキストウィンドウの上限 (65536) を超えたというエラーで失敗し、Workers AI はターミナルのスクリーンショットを、base64 の文字列長を 4 で割った 425,610 トークンと見積もっていた。
  • 1024 px、品質 80% の JPEG (140 KB と 48 KB) に縮めると課金は 1,048 と 1,272 トークンになり、画像は 1 枚あたり約 190 KB 未満に抑えるよう勧める。
• テキストのリクエストは 1 秒をかなり下回って返ったが、10 月 1 日に送った画像のリクエストは、両モデルとも 13〜30 秒かかった。
• スクリーンショットの確認では、アドレスバーの URL に Clef は 0.67 で気づき、Flash は 0.21 で見逃した。
• Hugging Face のモデルカードは動画のフレームにも触れているが、Workers AI の API が文書化しているのは画像だけ。
• Cloudflare のリーダーボードは Clef を 61.2 で 1 位、Jev を 57.9 で 2 位、Clef-flash を 57.1 とし、Jev と Clef-flash の間には Google のオープンな Gemma 4 にもとづくコミュニティのモデルが 2 つ入る。
• 全体の表は、ブログの 10 行より勝ち負けが入り混じっているとする。
  • Jev は GPQA Diamond (78.3 に対し Clef は 48.0)、MMLU-Pro (82.7 対 65.9)、BBH (92.9 対 73.7) でなお勝っている。
  • TypeSafe のワークフローの評価では、Clef が 3 つで 0.3〜2.9 ポイント差で勝ち、4 つ目は Jev が勝つ。
• リーダーボードの注記を、Jev の中央値 524 ms は Cloudflare の研究環境からインターネット越しに TypeSafe のホスト型 API を往復した時間だという意味に読む。
• TypeSafe は、米国西海岸から測ってほとんどの呼び出しで約 100 ミリ秒としている。
• TypeSafe は Jev の公開ベンチマークの結果を出さないことを選んだので、これらの数値はすべてコミュニティと Cloudflare によるものだと指摘する。
• イタリアから REST API で、395 トークンのチケットを 10 回続けて呼ぶ計測を 3 回繰り返した結果は次のとおり。
  • Clef-flash の中央値は 191〜205 ms で、最も遅い呼び出しは 676 ms。
  • Clef の中央値は 524〜726 ms で、単発では最大 3 秒。
• 1 日 10,000 の無料の Neurons は、Clef で約 458,000 トークン、Clef-flash で 120 万トークンにあたる。
• したがって Clef は Jev より安くはなく、入力トークンあたり Clef は約 5.7 倍、Clef-flash は約 2.1 倍のコストだとする。
  • 約 400 トークンのチケット 100,000 件なら、Jev で $1.68、Clef-flash で $3.60、Clef で $9.60。
• ダウンロードした重みを transformers と PyTorch で H200 上で動かすのは研究用の構成で、1 コマンドで入るものではないとする。
• 比較表では、Jev は利用できるが 9 月 22 日から新規登録を止めており、Clef は Workers AI で利用でき、Decisions API は限定プレビューで API も価格も公開されていない。
• 価格が効く大きなバッチ処理、推論の重い質問、人が待つリクエストでの画像の質問、普通の if で正しく決まることには、Clef を使わないとする。

[B] Latent Space (AINews) — [AINews] not much happened today (2026-10-03)

https://www.latent.space/p/ainews-not-much-happened-today-cee

• 10/1〜10/2 を扱う号で、AI Twitter Recap に Decision models and open weights という項目がある。
• llama.cpp がローカルで Jev 風の決定モデルの推論を行う /v1/systemone エンドポイントを加え、llama serve -hf ggml-org/Kev-4B-GGUF で始められるとする。
• Perplexity は、pplx-decider-v1-27b が 11 のベンチマークの平均で 85.7% となり、Jev を上回ると主張している。
• Clef の決定モデルが Ollama で使えるようになった。
• 懐疑的な見方として、@mervenoyann は決定モデルをゼロショット分類器の看板の掛け替えだと呼ぶ。
• 較正についての投稿は、Jev 風の較正を価値関数や Q 関数の予測に結びつける。
• r/LocalLLaMA のスレッド Clef: Open Weights decision model by Cloudflare (Activity: 619) はおおむね好意的で、Clef がローカルのモデルのエコシステムの空白を埋めると見るコメントが多かった。
  • 技術的な懸念として、量子化、とくに Q8 より下で Clef の品質が保てるかが挙がった。
  • あるコメントは評価セットが弱すぎると批判し、弱いオープンな Jev 系のベースラインではなく jevbench の上位のモデルと比べるべきだと論じた。
• r/LocalLLaMA のスレッド New in llama.cpp: Decision Models (Activity: 574) では、懐疑派がこの分野には堀 (moat) がないと論じ、実際に何に役立つのかわからないという声もあった。

[B] GIGAZINE — CloudflareがJevっぽい意思決定モデル「Clef」を公開、画像入力に対応しベンチマークではJev超えだがJev作者はベンチマークそのものに懐疑的 (2026-10-05)

https://gigazine.net/news/20261005-clef-cloudflare-decision-model/

• 「2026年9月15日にJevが登場した後、同様の機能を持った意思決定モデルが続々と登場しています」とし、決定モデルは「適切な用途で使えばLLMより圧倒的に高速かつ低コストでタスクを処理できます」と書く。
• Clef の特徴を「Jevはテキストの入力にのみ対応していますが、Clefは画像の入力にも対応しているのが特徴です」と説明する。
• 横軸に出力にかかる時間、縦軸に Decision Index 0.2.1 のスコアをとった Cloudflare のグラフを載せ、「ClefがJevと比べて高速かつ高スコアであることが分かります」とする。
• 脅威インテリジェンスの例を「ファッションサイトである可能性が95％」「オンラインストアである可能性が85％」「詐欺サイトである可能性が1％未満」と紹介し、gpt-oss-120b では 4.7 秒かかる分類を Clef は 2.2 秒で終えるとする。
• 「すでにOllamaがClefシリーズの実行をサポートしています」とし、ollama pull clef (27B) と ollama pull clef-flash (9B) を示す Ollama の 2026-10-03 の投稿を埋め込む。
• Jev の開発者 Diogo Almeida (記事の表記はディオゴ・アルメイダ氏) が、Jev を上回るモデルが次々に出るなかでベンチマークの有効性に疑問を呈していると伝える。
  • 2026-10-04 の投稿 (記事では日本時間の 10 月 5 日) を「ベンチマークテストのために最適化されたモデルと、真の信頼性を重視するモデルの間には決定的な違いがあり、その違いはベンチマークスコアには現れません」と訳し、続く括弧書きを「(LLMでこの現象を学んできました……)」と訳す。
  • 2026-10-01 の投稿 (記事では 10 月 2 日) は、企業はベンチマークを求めていない、速い企業はすでに社内の用途でベンチマークを済ませている、という TypeSafe の GTM の担当者の言葉を引くもので、記事はこれを「Jevの市場進出戦略担当者はすでにフォーチュン500企業の4分の1で導入を進めている」と紹介する。

[B] PC Watch (Impress) — テキストを生成しない爆速AI「意思決定モデル」が続々 Clefなど3本まとめ (劉 尭、2026-10-02)

https://pc.watch.impress.co.jp/docs/news/2145211.html

• 決定モデルを「テキストを1トークンも生成せず、分類やルーティングといった判断だけを高速に返す」ものとし、このジャンルは「Typesafe AIの『Jev』が火付け役となった」とする。
• 速く、出力の解析も要らないことから、「エージェントの分岐処理やガードレール、チケットの振り分けなどに向くとされる」と書く。
• 「Clefは『Qwen3.8-27B』、Clef-flashは『Qwen3.5-9B』をポストトレーニングしたモデルで、いずれも画像入力にも対応し、コンテキストウィンドウは64k」とする。
• Cloudflare が自社の評価で Decision Index の首位だとしていることを伝え、「BANKING77やCLINC150+OOSなどではJevを上回った一方、GPQA DiamondやMMLU-ProなどではJevが上回っている」と書く。
• レイテンシの中央値は「Clefが209.3ms、Clef-flashが38.8msと、Jevの524.1msより高速だった」とする。
• 同じまとめで、DiffusionGemma を Jev のような決定モデルとして動かす Matt Mastracci の構造化生成のモードが vLLM にマージされ、「DGX Spark 1台で、32並列時に毎秒54リクエスト(約162判断)を処理できた」と伝える。
• Liquid AI が決定モデル d1 を API で提供しており、質問は noul、choice、score の 3 タイプで、コンソールで API キーを取得すれば「『d1:free』モデルとして試用できる」とも伝える。

[B] gihyo.jp — Cloudflare、オープンソースのマルチモーダル意思決定モデル「Clef」と「Clef-flash」をリリース (2026-10-02)

https://gihyo.jp/article/2026/10/cloudflare-clef-decision-model

• Cloudflare が 2026 年 10 月 1 日に、Qwen をベースに自社で学習させた 2 つの意思決定モデルを、Apache 2.0 のライセンスで Hugging Face にオープンソースとして公開したと伝える。
• Typesafe AI の Jev と同様の意思決定モデルで、「確率を含む型付き回答を返し、意思決定が必要な際にワークフローに組み込むことができる」とし、「AIエージェントがどのように行動すべきかを判断するのに役立つ」と説明する。
• 「ClefはQwen3.8-27Bをベースとした27Bパラメータのマルチモーダルモデル」、Clef-Flash は「Qwen3.5-9Bをベースにトレーニングを施した軽量モデル」で、いずれもテキスト、JSON、画像、動画を読み、「1回の順伝播（フォワードパス）で選択できるオプションのすべての確率を返す」とする。
• 同社のベンチマークのサイトによれば「ClefはJev Decision IndexでJevが記録したスコアを総合で上回る性能をマークした」と伝える。
• 脅威インテリジェンスのワークフローでは「汎用LLMであるgpt-oss-120bと同じワークフローでのサイトの取得、レンダリング、分類が半分の時間で終了し、gpt-ossより詳細な分類結果が得られた」と紹介する。

[B] MarkTechPost — Cloudflare Releases Clef and Clef-flash: Open-Weight Decision Models That Return Typed Probabilities Instead of Text, by Asif Razzaq (2026-10-01)

https://www.marktechpost.com/2026/10/01/cloudflare-releases-clef-and-clef-flash/

• 配備できるかという問いを立て、両モデルが Workers AI で動き、重みも Hugging Face にあってセルフホストできるので、できると答える。
• Workers AI では 1 リクエストに最大 64 の質問と最大 4 枚の画像を載せられるとする。
• ほかの分野では Jev が明確にリードしているとし、GPQA Diamond、MMLU-Pro、BBH を挙げる。
• 数値はすべてベンダーの報告で、独立した再現はまだないと断る。
• 比較表では、Jev のサイズとバックボーンを非公開、コンテキストを 32K (Cloudflare による) とし、Kev-9B を Qwen3.5-9B-Base 上の 9B + 45.4M LoRA、コンテキストを 65,536 (検証済みは 8,192) とする。
• セルフホストについては、モデルカードが BF16 の重みを H200 1 枚で試験したとしていると伝える。

[C] Zenn (akari1106) — Cloudflare の判定モデル Clef を Workers AI で触ってみた (2026-10-04、10-05 更新)

https://zenn.dev/akari1106/articles/b6d3180cc50dfe

• 前提として「実験はすべて 2026年10月4日に Workers AI 上で行いました」とし、問い合わせ文と画像はすべて架空のもの。
  • 件数は「1つの実験あたりの件数は5件前後です」とし、「結果は傾向の確認であり、精度の評価ではありません」と断る。
• 仕組みを、ベースモデルが「入力全体を1回だけ読み込みます（prefill）」、その上の「小さな head が、各選択肢のスコアを並列で計算します」とまとめ、ベースモデルの重みは凍結されていて「学習で更新したのは、head と LoRA だけです」と書く。
• 質問の形式は 3 種類で、noul は yes の確率を返し、choice は 2〜255 個の選択肢から 1 つを選んで選択肢ごとの確率と confidence を返し、score は 2〜10 段階で評価して確率で重み付けした期待値を返す。
• API トークンは、Cloudflare のダッシュボードで「テンプレート『Workers AI』を選んで作成します」とする。
• サンプルのレスポンスでは、is_complaint が noul 0.9266、topic が returns で 0.9956 (confidence 0.9869)、入力 262 トークン、出力 0 トークンだった。
• 「Workers AI では、質問ごとの instructions が必須です」と書き、Hugging Face の model card では省略できると書かれていると指摘する。
• 出力トークン数は「レスポンスを確認した32回のリクエストですべて0でした」とし、料金表にも入力トークンあたりの金額しか書かれていないとする。
• 日本語の試験では、問い合わせ文 5 件を、英語と英語、日本語の問い合わせ文と英語の質問、日本語と日本語の 3 条件で配送、返品、請求の担当に振り分け、「Clef と Clef-flash の30回すべてで、想定どおりの担当が選ばれました」とする。
  • 「入力トークン数は165〜183で、言語による差はほとんどありませんでした」と書く。
• わざと迷うように作った「返品した商品の返金がまだ口座に入っていない」という問い合わせでは、billing の確率が Clef-flash で英語 0.777、日本語 0.917〜0.949、Clef で 0.908 と 0.967〜0.975 だった。
  • 英語と日本語の文は筆者が別々に書いたもので、「差の原因が文の書き方なのか、モデルの性質なのかは切り分けていません」と断る。
• criteria の選択肢の順番を 4 通りに変えても、確率は「4回とも小数点以下4桁まで同じ値でした」(billing 0.7772、returns 0.2066、shipping 0.0162) とし、時間を空けて同じ入力を送っても同じ確率が返った。
  • 公開されている推論コードは、選択肢を option id の文字列順に並べ替えてからモデルに渡している。
• other の選択肢がないと、範囲外の問い合わせ (実店舗の営業時間、求人への応募、コーヒーの淹れ方) もどれかの担当に振られ、たとえば Clef-flash では returns 0.454、billing 0.595 だった。
  • other を加えると 3 件とも 0.961〜0.997 で other に分類され、範囲内の問い合わせの判定はほとんど変わらなかった。
  • other がない場合、範囲外の問い合わせの confidence は 0.02〜0.16 まで下がり、範囲内の問い合わせは 0.89 以上だった。
• 用件が複数ある問い合わせでは、「choice は確率の合計が1になるため、用件が2つあると確率が2つの担当に割れました」とし、担当ごとの noul はそれぞれを独立に判定できた。
  • 用件が 3 つの問い合わせでは、Clef-flash が配送の用件を見落とし (0.181)、Clef は同じ用件を 0.935 で判定した。
• 画像の試験は 512×512 ピクセルの PNG のマグカップのイラスト 6 枚 (入力はどれも 456 トークン) で、違う色は手ぶれ風の加工があっても両モデルが判定できた (0.972〜0.989)。
  • 小さなひびや欠けは Clef-flash がきれいな画像でも見落とし (注文どおり 0.873)、Clef も手ぶれ風の画像では破損 0.486、注文どおり 0.460 とほぼ半々になった。
• 日本からの 15 回の往復時間の中央値は「Clef-flash が166ミリ秒、Clef が406ミリ秒でした」とし、差の約 240 ミリ秒は「公式の中央値の差（約170ミリ秒）に近い値でした」とする。
  • 単発の往復は、Clef-flash で 125〜688 ms、Clef で 240〜815 ms。
• Hugging Face で公開されている推論コード (joint_schema_model.py) を読み、モデルへの入力は「system prompt、画像、state、質問と選択肢の順に並ぶ」ことを確かめた。
  • 「入力が上限を超えると、state の末尾が削られます」とし、質問と選択肢は削られず、「質問と選択肢だけで上限を超える場合はエラーになります」と書く。
  • 選択肢は {"description":"...","option_id":"returns"} という JSON の文字列としてモデルに渡るので、id は意味のある英単語にするほうが安全だと考えられるとする (id を変えた試験はしていない)。
  • オブジェクトの state は json.dumps(sort_keys=True, ensure_ascii=False) で文字列にされるので、キーはアルファベット順に並べ替えられ、日本語はエスケープされずにそのまま入力される。
  • system prompt に「すべての項目を合わせて判断する（Decide every field jointly）」とあり、1 回のリクエストの質問どうしの判定が影響し合う可能性があるとする。
• model card と Workers AI の違いとして、instructions は省略可と質問ごとに必須、画像の渡し方は PIL 画像と base64 のみ (URL 不可)、動画は対応と項目なし、入力長の上限は max_length の既定値 16,384 と 65,536 トークンを並べる。
  • URL でモデルを指定していても、リクエストの本文に "model": "clef-flash" が要る。
• 画像は { "content_type": "image/png", "base64": "..." } の形か data:image/png;base64,... の形で渡し、SVG は受け付けられない。
• 確率は小数点以下 4 桁に丸められて返り、confidence の計算方法は公開されておらず、確率が均等に近いほど低くなるが「最大の確率とは別の値です」と書く。
• 結論として「Clef を使う場合、モデルの精度と同じくらい、利用者側の設計が結果を左右します」とし、Jev を試したときにも同じ印象を持ったと書く (範囲外の入力への other か confidence のしきい値、用件ごとの noul、長い会話ログでの state の並べ方)。
• 実験スクリプトは Claude Code に書いてもらったとし、「Clef は発表されたばかりで、AI の学習データには仕様が含まれていません」として、「コードを書く前に、Workers AI の入力スキーマ（schema-input.json）を読む必要があります」と勧める。

[C] X — Replies to Georgi Gerganov's announcement of decision models in llama.cpp (2026-10-02)

https://x.com/ggerganov/status/2106029758350032937

• Georgi Gerganov は、最新の llama のビルドで /v1/systemone エンドポイントが使えるようになり、Jev 風の推論をローカルで効率よく、プライベートに行えると告知した。
• Armin Ronacher は、代わりに分類器 (classifiers) と呼べないのかと返信した。

メモ

• Cloudflare の首位という主張は、自社の実行にもとづいている。
  • リーダーボード自体が、Clef と Clef-flash は上流のボードで再現されていないとしており、10-06 に取得した上流の Decision Index 0.2.1 のデータに Clef のエントリはなかった。
• ベンチマークの数が、Cloudflare のページどうしでそろわない。
  • ブログと changelog は 43 のベンチマークとし、Flavio Copes は 43 のベンチマークとレイテンシと読み、カードの表はベンチマーク 41 行とレイテンシ 2 行で、上流のスイートは 43 のベンチマークと、38 のベンチマークからなる指数のパネルを挙げる。
  • Clef は指数の 38 のうち 36 をカバーし、欠けた iSarcasmEval と HLE はボードの規則で 0 点になるため、指数を上げる方向ではなく下げる方向に働く。
• 今回の実行でカードの 41 行を数えると、Clef は 26 行、Clef-flash は 24 行で Jev を上回り、少なくとも一方が上回るのは 29 行、Jev が両方を上回るのは 11 行 (GPQA Diamond、MMLU-Pro、BBH、When2Call、HoVer、ANLI を含む) で、RouterBench では Clef-flash が 79.9 で Jev と並ぶ。
  • リーダーボードの分野別のスコアでは、Clef のリードは検索、ツール、芸術から来ており、知識 (51.2 対 51.4) と言語 (61.2 対 62.0) では Jev にわずかに及ばない。
• レイテンシの倍率 (Jev の 2.5 倍と 13 倍の速さ) は、別々の測り方を比べている。
  • 上流では、Jev の 524.1 ms は HTTPS とサービス側の並行スケジューリングを含む HTTPS の API のレイテンシで、オープンなモデルの値は RTX PRO 6000 1 枚での計算時間、Clef の値は Cloudflare 自身の基盤で測ったもので、リーダーボード自身がこれを直接は比べられないとしている。
  • Flavio Copes は Jev の往復を Cloudflare の研究環境からのものとしているが、上流の手法は、ボードが逐次のクライアント 1 つで測ったとしている。
  • エンドツーエンドで測ると、Clef-flash の中央値はイタリアから 191〜205 ms (Flavio Copes)、日本から 166 ms (Zenn)、Clef は 524〜726 ms と 406 ms で、表の 38.8 ms と 209.3 ms を大きく上回る。
  • TypeSafe は米国西海岸からほとんどの Jev の呼び出しで約 100 ms としている (Flavio Copes 経由) が、今回の実行ではこの数値を確かめていない。
• 較正はうたわれているが、第三者が測っていない。
  • Cloudflare は Brier 損失と RLCD で学習させているが、リーダーボードには Clef と Clef-flash の ECE がなく、Jev の ECE は 0.074。
  • Ollama の clef のページは confidence を答えが正しい確率ではないとし、Zenn の筆者はその計算式が公開されていないと指摘する。
• TypeSafe のワークフローの評価での 4 つのうち 3 つの勝ちは、0.3〜2.9 ポイントの差 (Flavio Copes)。
  • Kev 1.0 のリリースノート (https://github.com/jaredpalmer/kev/releases/tag/kev-1.0) は、TypeSafe の公開の評価を、正解が 2 つのクローズドなモデルから作られ問題数も少なすぎるとして、Kev 自身のモデル選びから外した。
• Clef はトークンあたりでは Jev より安くない: 入力 100 万トークンあたり $0.24 と $0.09 で、Jev の $0.042 の約 5.7 倍と 2.1 倍 (Flavio Copes)。
• インターフェースの細部は提供経路によって違う。
  • instructions は Hugging Face のコードでは省略できるが、Workers AI では必須。
  • 動画にはモデルのページ、カード、gihyo.jp、MarkTechPost が触れているが、Workers AI の API が文書化しているのは画像だけ。
  • カードのコードは max_length の既定が 16,384 トークンだが、Workers AI は 65,536 トークンで提供する。
  • Workers AI では選択肢が 2〜255、段階が 2〜10 (Flavio Copes、Zenn) だが、Ollama では 2〜26。
  • Ollama のタグの一覧は 256K のコンテキストウィンドウを示すが、readme は 64K としている。
  • llama.cpp は Clef を英語のみとしているが、Zenn の試験では 5 件の問い合わせで日本語の振り分けが英語と同じくらい正確だった。
  • llama.cpp の本文は画像を読めるのは OpenJev だけとしながら、表では Clef に画像ありの印を付けている。
• Clef はすべての質問をまとめてスコア付けする (カードは全質問の全選択肢を共同でスコア付けするとし、Zenn によれば system prompt に Decide every field jointly とある) のに対し、Kev のカード (https://huggingface.co/jaredpalmer/kev-4b) は質問どうしが影響し合えないとしており、Clef のリクエストで質問を足したり減らしたりすると、ほかの答えが動く可能性がある。
• ここでのオープンソースは Apache 2.0 のオープンウェイトのことで、社内の合成の学習データと学習のコードは公開されていない。
  • この点を指摘した Hacker News のコメントは、検索結果の要約でしか見ていない (未確認)。
• Jev のコンテキストの 32k は Cloudflare による数値で、MarkTechPost も Cloudflare によると注記しており、今回の実行では確かめていない。
• 懐疑的な見方として、ベンチマークに最適化したモデル (benchmaxxed models) についての Jev の作者の発言 (GIGAZINE)、@mervenoyann によるゼロショット分類器の看板の掛け替えという見方 (AINews)、jevbench の上位と比べるべきだという r/LocalLLaMA の声と Q8 未満での量子化への懸念 (AINews)、分類器と呼べばよいという Armin Ronacher の返信 (X) がある。
• RL のサービスには、ブログと既存の顧客向けのデザインパートナーのフォームのほかに価格も日程も文書もなく、その Trainer は新しく作られたもの。
• Zenn の検証は 1 つの実験あたり約 5 件で、写真ではなくイラストを使っているので、示しているのは精度ではなく傾向。
• 画像のリクエストはローンチ当日に 13〜30 秒かかった (Flavio Copes) が、10-01 以降に改善したかは確かめていない。

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

• 既存の System One のクライアント (TypeSafe の SDK や Vercel AI SDK) を fetch アダプター経由で Workers AI の Clef-flash に向け、ラベル付きの日本語のチケット 30〜50 件を流して、正解率、confidence の分布、東京からの p50 と p95 のレイテンシ、1,000 判断あたりのコストを、Jev や Kev と比べて記録する。
• 同じ質問をまとめて送る場合と 1 つずつ送る場合を比べて、Clef の共同のスコア付けがそれぞれの答えをどれだけ動かすかを測り、質問ごとに独立して答える Kev と比べる。
• 範囲外の入力で明示的な other の選択肢と confidence のしきい値を比べ、用件が複数あるメッセージで担当ごとの noul と 1 つの choice を比べる。
• Clef の確率をしきい値に使う前に、自分のラベル付きデータで信頼性図 (reliability diagram) を描いて ECE を計算する (Clef の較正を報告した第三者はまだいないため)。
• 同じ項目で ollama pull clef-flash (Ollama 0.35.1 以降) か llama.cpp の ggml-org/Clef-GGUF を動かし、量子化したローカルの答えが Workers AI からどれだけずれるかを確かめる。
• 約 190 KB 未満に縮めた画像で、スクリーンショットのゲート (秘密情報、URL、違う商品) を試して時間を測る (ローンチ当日は画像のリクエストが遅かったため)。
• AI Gateway ですでにトラフィックを記録しているなら、デザインパートナーに応募する前に、記録された判断と人による修正が RL のファインチューニングのサービスの種になるかを見積もる。
• Jev、Clef、Kev、Laya、OpenAI の Decisions API を、インターフェース、言語、画像、価格、日本から測ったレイテンシ、較正の根拠で比べる 1 ページの比較表をチーム向けにまとめる。

3. 📦 Cloudflare が Containers をエージェントのサンドボックス向けに作り直し、サンドボックスごとのイメージとインスタンスタイプを Durable Object のコードから実行時に選べるようにし、ファイルシステムのスナップショットをベータで加え、起動時間の中央値が約 4 秒から 648 ms に縮んだベンチマークを示した

• 選定 / 影響度 2 / 将来性 2 / 重要度 2 / 起点 09-30、期間前の出来事 / 種別: リリース / 領域: エージェント開発、セキュリティ・安全性。
• 候補になったフィード項目:
  • publickey 10-06 Cloudflare ContainersがAIエージェント向けに刷新。起動が6倍速、ファイルシステムのスナップショット機能など
  • ainews 10-03 not much happened today (作り直しに合わせて同じ日に出た Sandbox SDK 1.0)
• 起点: Cloudflare は期間の 3 日前、09-30 の Birthday Week でこの作り直しを発表し、今回の実行で ainews と publickey を通じて初めてフィードに現れた。
• 関連: 2026-09-29 のトピック 3 は、別のベンダーによるコーディングエージェント向けのサンドボックス、Docker Cloud Sandboxes を扱った。

収集した情報

[A] Cloudflare Blog — Cloudflare Containers, rebuilt to scale agent sandboxes, by Thomas Gauvin, Rushil Mehra, Gabi Villalonga Simón and Thomas Lefebvre (2026-09-30)

https://blog.cloudflare.com/faster-agent-sandboxes/

• 2026 年 9 月 30 日に Birthday Week のタグで公開された。
• 冒頭で、Cloudflare Containers をよりプログラムしやすく、エージェントのワークロードに最適化したものにすると宣言する。
• 課題として、エージェントはサンドボックスを前もってデプロイしない点を挙げる。
  • エージェントはタスクごとにその場でサンドボックスを作り、すぐに使えること、一時停止と再開ができることを期待する。
• 変更は 3 つで、コードが実行時にサンドボックスごとのイメージとインスタンスタイプを選べるようになり、Containers の起動が 6 倍速くなり、ファイルシステムのスナップショットがパブリックベータで使えるようになった。
• 仕組みとしては、新しいスケジューリングポリシーが各サンドボックスの制御をアプリケーションのコードに移し、作り直したランタイムが Container の起動までの経路を短くする。
• ComputeSDK の独立したベンチマークで起動時間の中央値が 4 秒強から 648 ミリ秒に縮み、自社の予備的なバーストテストでは数十万の Container を数秒で作れたとする。
• すべての Container は専用の Durable Object を持ち、これは Container のすぐ隣で動く永続的でプログラムできるコントローラーとして、ライフサイクルや外向きの通信などを管理する。
  • 機能をネイティブの ctx.container API に移して、Durable Object が間にラッパークラスを挟まずに Container を制御できるようにし、同じモデルを Sandbox SDK 1.0 にも持ち込んだ。
• これまでの Cloudflare Containers は、アプリケーションのデプロイを単位に組み立てられていた。
  • イメージと計算資源はデプロイ時に決まってアプリケーション全体に展開され、設定と展開の単位はアプリケーションだった。
• エージェントのワークスペースは、エージェントが作業している最中にその場で作られ、イメージ、資源、ツール、最初のファイルシステムはタスクで決まる。
  • 数分だけ存在することも、リクエストの合間に眠ることも、数日後に復元されることもある。
• 利用者と連携先として、Base44 (アプリを作るワークスペース)、Kilo Code (クラウドエージェントのセッション)、Cursor Cloud Agents、Devin Outposts、OpenAI Agents API、Claude Managed Agents を挙げる。
• ワークロードの要件として、コーディングエージェントにはリポジトリ、パッケージマネージャー、コンパイラー、テストランナー、開発サーバーが要り、評価には既知の状態から始まるサンドボックスが要り、強化学習のシステムは大量の環境を作って採点しリセットする必要があり、長いタスクではエージェントが作ったファイルを残す必要があるとする。
• その答えが durable_object のスケジューリングポリシーで、コードが実行時にサンドボックスごとのイメージと計算資源を選べ、Containers の起動が 6 倍以上速くなり、ファイルシステムのスナップショットでワークスペースを保存して復元できる。
• Base44 の Software Engineer, App Infrastructure の Dolev Epshtein は、Containers がアプリごとに隔離された開発環境を与え、そこで AI がコマンドを実行し、依存関係を入れ、変更をライブのプレビューで形にできると語る。
• Kilo Code の共同創業者で Anaconda の VP Engineering, AI Workspaces の Emilie Schario は、クラウドエージェントのセッションごとに、正しいリポジトリ、ツール、ユーザーの設定を備えた専用のワークスペースと環境が要ると語る。
• 以前は、イメージとインスタンスタイプの組み合わせごとに別の Containers のアプリケーションと Durable Object の名前空間があり、wrangler deploy で前もって用意していた。
  • 小さな Node.js のサンドボックスと大きな Python のビルド用のサンドボックスを使うには、アプリケーションが 2 つ、名前空間が 2 つ、各タスクを正しい側へ送る Worker のルーティングの処理が要った。
• wrangler.jsonc でのオプトインの設定は、"class_name": "AgentSandbox"、"scheduling_policy": "durable_object"、images のマップ (node と python、それぞれ { "dockerfile": ... }) を持つ containers のエントリと、SANDBOX という名前の Durable Object のバインディング。
• 宣言した各イメージは this.ctx.container.images.<name> で参照できる。
  • 例では workspace.toolchain に応じて images.python か images.node を、ビルドなら "standard-2"、それ以外なら "standard-1" を選び、this.ctx.container.start({ image, instance, enableInternet: true }) を呼ぶ。
• 以前は別のアプリケーションと別の wrangler deploy が要ったことが、いまは if 文 1 つで済むとする。
• インフラが、環境そのものに至るまでリクエスト時に動くコードになる、というのが今回の更新全体の考え方だとする。
• 以前の展開では猶予期間、割合での分割、API の呼び出しを使い、エージェントがタスクの途中かどうかにかかわらず、どのインスタンスをいつ置き換えるかをプラットフォームが決めていた。
• 新しいポリシーでは展開の設定そのものがなく、Container はコードが止めるまで起動時のイメージのまま動き、次の起動ではコードが選んだイメージを使う。
  • 例では this.ctx.storage から pinned-image を読み、なければ isCanary(this.ctx.id) のときに images.nodeV2、それ以外は images.node を使う。
• 展開のパターンとして、Durable Object の ID のハッシュで新しいサンドボックスの 5% に新しいツールチェーンをカナリアで当てること、作業中のプロジェクトを今のイメージに固定すること、次のセッションやスナップショットの後のような区切りでワークスペースを移すこと、今後の起動が選ぶイメージを変えて元に戻すこと (設定のプッシュもドレインの待ちもない) を挙げる。
• 以前の起動の経路では、グローバルなコントロールプレーンがアプリケーションの設定を解決し、容量を探し、配置を調整しており、エージェントの最初のコマンドの手前にデプロイの仕組みが挟まっていた。
• 新しい起動の経路では、要求は Durable Object から始まり、インフラはまず同じマシンで容量を探し、必要なら同じロケーションの中で範囲を広げる。
  • Container のイメージやスナップショットをすでにローカルのストレージに持つホストを優先し、ダウンロードを待たずに起動できるようにする。
• ランタイムは、新しい仮想マシンをゼロから起動する代わりに、まだ割り当てていない準備済みの仮想マシンを復元する。
  • ネットワークとファイルシステムの準備を再利用し、繰り返す操作をまとめ、最初のコマンドに要らないサービスを待たなくなった。
• ComputeSDK の Burst TTI Benchmark は、100 のサンドボックスを同時に起動し、クライアントから見た操作可能になるまでの時間 (time-to-interactive) を測る。
• 表は以前のスケジューリングの経路と新しいスケジューリングポリシーを比べ、中央値が 4.049 秒と 648 ミリ秒 (6.2 倍速い)、95 パーセンタイルが 5.839 秒と 910 ミリ秒 (6.4 倍)、99 パーセンタイルが 6.717 秒と 1129 ミリ秒 (5.9 倍)。
• 予備的なバーストテストでは、1 つのアカウントが 6 つのロケーションで 100,000 の Container を 5.387 秒で起動した。
• 新しいシステムイメージ cloudflare/debian-trixie は、実行時に環境を整えるエージェント向けのすぐ使えるイメージで、Debian Trixie Slim と Node.js 24.20.0 LTS を含む。
  • 例では instance: "standard-2"、enableInternet: true、entrypoint: ["/bin/sleep", "infinity"] で起動する。
• これを使えば、エージェントは Dockerfile を作ったりイメージをビルドして Cloudflare に push したりせずに Linux のサンドボックスを起動し、exec() でリポジトリのクローン、パッケージの導入、タスクに合わせた環境の設定ができる。
• このイメージは Cloudflare が管理しているので、リクエストが来る前に対象の Containers のホストへ配って準備しておけるとする。
• スナップショットとして、Containers にネイティブのファイルシステムのスナップショットをパブリックベータで加える。
  • 保存は this.ctx.container.snapshotContainer({ name: "project-ready" }) と this.ctx.storage.put("workspace-snapshot", snapshot)、復元は start({ containerSnapshot: snapshot, instance: "standard-2", enableInternet: true })。
• パターン 1 は、1 つのワークスペースを多くのセッションにまたがって続けるもので、リポジトリ、導入済みの依存関係、ビルドのキャッシュ、設定、編集を、環境を作り直さずに使える。
• パターン 2 として、スナップショットは不変で再利用できるので、複数の Container が同じ準備済みの環境からそれぞれ起動し、そこから別々に変更を加えられる。
• 評価の例では、1 つのスナップショットから隔離された環境を多数起動して、システムプロンプト、スキル、モデル、エージェントのバージョンを比べ、準備の時間を減らし、環境のずれが結果に影響するのを防ぐ。
• 組み合わせた流れは、cloudflare/debian-trixie から始め、exec() で準備し、スナップショットを保存して、以後のサンドボックスはそこから起動するというもの。
  • 作業が止まれば計算を止め、新しい Container が最新のスナップショットから起動して続きから再開できる。
• 根拠として、エージェントのシステムには、状態を保ち、認証情報を持ち、サンドボックスのライフサイクルを制御する、Container の外のプログラムできて状態を持つ環境が要るとし、Anthropic の脳と手を切り離す (decoupling the brain from the hands) パターンを引く。
• 配置の選択肢は、エージェントを Durable Object で動かして Container をワークスペースにするか、エージェントを Container で動かして Durable Object から監督するかで、軽量な隔離実行には Dynamic Workers がある。
• exec() は Workers のランタイムで直接動き、外向きのリクエストの横取り、実行時のイメージとインスタンスの選択、ファイルシステムのスナップショットはすべて ctx.container にあって、Durable Object のストレージ、アラーム、WebSocket、RPC と組み合わせられる。
• パターンの 1 つは、エージェントのループを Durable Object で回し、シェル、コンパイラー、開発サーバーが要るときだけ Container を起こし、待つ間は計算を止めて、アイドルの Linux の計算に料金を払わないというもの。
• セキュリティのパターンでは、Durable Object がユーザーの許可したことを覚えておき、Container の Outbound Request Handler を更新して、新しく与えた認証情報を差し込み、新しいポリシーを適用し、追加の活動を記録するもので、Cloudflare OS の Gatekeeper パターンに似ているとする。
• 評価と RL のパターンでは、コーディネーターがベースのワークスペースのスナップショットをとり、それぞれ専用の Durable Object と Container を持つ N 個の試行に分岐させる。
  • 各 Durable Object は Container がクラッシュしても結果を残し、コーディネーターは試行を採点して最良のもののスナップショットをとり、そこからまた分岐させる。
• 経緯として、Containers の提供開始時にはあえて Durable Object を Container クラスの背後に隠していたと明かす。
  • ランタイムにコマンドの実行、外向きのリクエストの横取り、スナップショットのどれもなかったため、Sandbox SDK がそれらをユーザー空間で作っていた。
• 協力したほぼすべてのチームが、汎用のライフサイクルとは少しずつ違うもの (独自のスリープの方針、独自の認証情報の扱い、評価の実行の独自の追跡) を必要としていたとする。
• 新しい機能はネイティブの API だけで提供する。
  • ポリシー、速い起動、実行時のイメージとインスタンスの選択、スナップショットは ctx.container からしか使えない。
• Container クラスとレガシーの Sandbox クラスは 2026 年 12 月 31 日まで保守する。
  • その日以降も既存のデプロイは動き続けるが、クラスは更新されなくなる。
  • ctx.container への移行を勧める。
• Sandbox SDK 1.0 はベースクラスではなく、ユーティリティの集まりだとする。
  • そのヘルパーは、ctx.container と並べて、自分の Durable Object のクラスの中で使う。
• より高いレベルの環境としては、Dynamic Workers と Containers を同期したファイルシステムで組み合わせる @cloudflare/computer がある。
• 移行は、たいてい extends Container を extends DurableObject に変え、this.ctx.container を直接呼ぶことだとする。
• 提供状況として、新しい durable_object のスケジューリングポリシーは、パブリックベータで今日から誰でも試せる。
  • リンク先は、ポリシーのドキュメント、スナップショットのガイド、cloudflare/containers-demos の完全なサンドボックスの例、Cursor Cloud Agents、Devin Outposts、OpenAI Agents API との連携のチュートリアル。

[A] Cloudflare Changelog — New scheduling policy for Containers to configure image and instance from Durable Objects (2026-09-30)

https://developers.cloudflare.com/changelog/post/2026-09-30-durable-object-scheduling-policy/

• Containers が durable_object のスケジューリングポリシーにパブリックベータで対応した。
• このポリシーでは、アプリケーションで一元管理する 1 つの設定ではなく、Durable Object が実行時に Container のイメージとインスタンスのサイズを選ぶ。
• Wrangler が各イメージを準備し、その不変の参照を ctx.container.images で公開する。
• このポリシーは新しいマネージドイメージ cloudflare/debian-trixie (Debian Trixie slim 上の Node.js 24.20.0) に対応し、名前付きのイメージを設定せずに直接起動できる。
• Durable Object が管理する Container のインスタンスはそれぞれ独立したライフサイクルを持ち、アプリケーション全体のイメージの展開には加わらない。

[A] Cloudflare Changelog — Snapshot and restore Container filesystem (2026-09-30)

https://developers.cloudflare.com/changelog/post/2026-09-30-snapshots/

• Containers が、ある時点のファイルシステムの状態を保存して復元するスナップショットの API に、パブリックベータで対応した。
• 復元の場面として、Container のスリープ、再起動、別の Durable Object への引き渡しの後を挙げる。
• 例では名前なしで snapshotContainer({}) を呼び、ハンドルを Durable Object のストレージに保存し、start({ containerSnapshot, enableInternet: false }) に渡す。
• スナップショットは durable_object のポリシーのアプリケーションでしか使えず、不変なので、復元後のファイルシステムの変更を残すには新しいスナップショットを作る。

[A] Cloudflare Changelog — Sandbox SDK 1.0: control every sandbox from your own Durable Object (2026-09-30)

https://developers.cloudflare.com/changelog/post/2026-09-30-sandbox-sdk-1-0/

• Sandbox SDK 1.0 が使えるようになった。
  • 自分の Durable Object のクラスが、this.ctx.container の Durable Object Container API を通じて、各サンドボックスの Container を直接制御する。
• 1.0 では、クラスが起動ごとにイメージとインスタンスのサイズを選び (デプロイしても動いているサンドボックスは再起動しない)、サンドボックスのファイルをスナップショットとして保存し (パブリックベータ)、各サンドボックスをいつ止めるかを決められる。
• ストリーミングの入出力、シグナル、端末付きでコマンドを実行し、独自のホスト名と認証でポートからプレビューを配信し、ホスト名ごとに外向きのリクエストを扱える (認証情報とバインディングは Worker に留まる)。
• 呼び出し側に使わせるメソッドだけを公開し、サンドボックスでコマンドを実行するモデルのツールを持つエージェントを、同じ Durable Object で動かせる。
• 例の MySandbox は this.container.images.sandbox を instance: "lite" と enableInternet: false で起動し、Files で /tmp/task.sh を書き、exec(["sh", "/tmp/task.sh"]) を実行する。
• @cloudflare/sandbox は、Files (ファイルをストリームで出し入れする)、S3Mount (R2 のような S3 互換のバケットをマウントし、Worker が各ストレージのリクエストに署名するので認証情報はサンドボックスに入らない)、DirectoryBackup (ディレクトリを R2 に保存し、新しいイメージのものを含むどのサンドボックスにも復元する) を加える。
• 0.x のアプリケーションは動き続け、@cloudflare/sandbox 0.x は npm に残り、0.x は 2026-12-31 までバグとセキュリティの修正を受ける。
• 既存のクラスを新しいポリシーに移すデプロイは一方向なので、ガイドではまずリハーサルの方法を示す。

[A] Cloudflare Docs — Durable Object Container API (2026-09-30)

https://developers.cloudflare.com/containers/api/durable-object-container/

• API は、コンテナのバインディングを持つ任意の Durable Object のクラスの中の this.ctx.container で、コンテナのプロセスは Linux の VM の中でイメージを動かす。
• images (durable_object のポリシーのみ) は Wrangler の images の欄からの読み取り専用のマップで、Wrangler が名前付きの各イメージをビルドまたは解決し、ダイジェストで固定した参照を同じキーで公開する。
• running はコンテナが動いていれば true だが、リクエストを受け付ける準備ができたことまでは確かめない。
• start() はコンテナを起動する。
  • コンテナがリクエストを受け付けられるようになる前に戻る。
  • 起動の失敗を含む後のエラーは monitor() で表に出て、コンテナがすでに動いていれば start() は例外を投げる。
• start() のオプションは env、entrypoint、enableInternet (オプションを渡すときは必須)、image、instance、containerSnapshot、labels。
• image はマネージドの cloudflare/debian-trixie か ctx.container.images の値をとり、containerSnapshot を渡さない限り必須で、両者は同時に指定できない。
• instance は "lite"、"standard-1"、"standard-2"、"standard-3"、"standard-4" か、vcpu、memoryMib、diskMb を持つ独自のオブジェクトをとり、既定は "lite"。
• labels は最大 10 個のラベル (名前は 1〜16 バイト、値は 64 バイトまで) で、inspect() が返す。
• start() に渡した環境変数は、PATH を除いて exec() で起動したプロセスには届かない。
• exec(cmd, options) はシェルを介さず実行ファイルを直接起動するので、Bash は ["bash", "-lc", "<COMMAND>"]、POSIX シェルは ["sh", "-c", "<COMMAND>"] として呼ぶ。
• exec() のオプションは stdin (ReadableStream か "pipe")、stdout と stderr ("pipe"、"ignore"、"combined")、cwd、env、user (uid:gid)、signal (SIGKILL を送る AbortSignal)、pty (true なら 80 列 24 行)。
• output() はすべての出力を Durable Object のメモリに保持し、それがメモリの上限に数えられるので、大きな出力はストリームで扱う。
• exec() に組み込みのタイムアウトはない。
• プロセスを起動したリクエストを取り消しても、プロセスは止まらない。
  • クライアントが再試行すると、同じコマンドの 2 つ目が動く。
• snapshotContainer() は、動いているコンテナの書き込み可能なルートファイルシステムの、ある時点のスナップショットを作る。
  • メモリ、動いているプロセス、別にマウントしたファイルシステムは含まない。
  • スナップショットから起動したコンテナは、エントリーポイントをもう一度実行する。
• 返る ContainerSnapshot は id、バイト単位の size、任意の name を持つ不透明なハンドルで、スナップショットのデータそのものは Worker に返らない。
• コンテナのスナップショットは不変。
  • スナップショットのハンドルには暗黙の 30 日の有効期限があり、復元するたびに延びる。
• setInactivityTimeout(durationMs) は、Durable Object が非アクティブになった後もコンテナを動かし続ける時間を、0 より大きく最大 6 時間 (21600000) の範囲で設定する。
  • デプロイの後などで再起動した Durable Object は、この設定のない状態で始まる。
• getTcpPort(port) は、コンテナのポートへの HTTP リクエストや TCP 接続のための Fetcher を返す。
• 待機中の monitor() の呼び出しは、コンテナが終了するまでか最大 15 分のどちらか早いほうまで、退避 (eviction) を防ぐ。
• interceptOutboundHttp() は、ホスト名、ホスト名のグロブ、IP、IP:port、CIDR の範囲に一致する外向きの HTTP を Fetcher に通し、横取りはコンテナが止まるまで続く。
• enableInternet: false では公開のリゾルバーが DNS に答えず、名前解決できるのは横取りしたホスト名だけか、interceptAllOutboundHttp() や * の対象を使った後ならすべてのホスト名。
• 横取りの上限はコンテナあたり 128 エントリで、3 つの横取りのメソッドが共有し、ホスト名 1 つで 2 エントリ (IPv4 と IPv6) を使うので、ホスト名なら最大 64、IP や CIDR なら 128。
• コンテナが動いている間は、横取りを外せない。
• interceptAllOutboundHttp() が対象にするのはポート 80 だけで、enableInternet: true で起動したコンテナでは、どの横取りにも当たらない接続はそのままインターネットに出る。
• interceptOutboundHttps() は既定でポート 443 を横取りし、コンテナは /etc/cloudflare/certs/cloudflare-containers-ca.crt の CA 証明書を信頼しなければならない。

[A] Cloudflare Docs — Scheduling Policies (2026-09-30)

https://developers.cloudflare.com/containers/configuration/scheduling-policy/

• default はイメージとインスタンスのサイズを Wrangler の設定に書き、展開はアプリケーション全体で、インスタンスが同じイメージとサイズを使うサービス向け。
• durable_object (ベータ) はイメージとサイズを ctx.container.start() を呼ぶ Durable Object のコードで選び、サンドボックスやエージェントの環境など、インスタンスごとの設定が要るワークロード向け。
• 1 つの Wrangler の設定に、両方のポリシーのアプリケーションを含められる。
• スケジューリングポリシーは変更できない。
  • アプリケーションを削除するとその Container のインスタンスも消えるので、ポリシーの切り替えは、動いているすべてのインスタンスを置き換えることになる。
• containers[].images の下の各キーが ctx.container.images のプロパティになり、dockerfile (任意で build_context と build_vars) か、registry.cloudflare.com/<ACCOUNT_ID>/<REPOSITORY>@sha256:<DIGEST> の形のダイジェストで固定した image を指定する。
• Docker Hub、Amazon ECR、Google Artifact Registry を直接参照することはできない。
• 1 つの設定に最大 100 の名前付きのイメージを含められる。
  • イメージの名前は 1〜128 文字。
• イメージのマップは Worker のバージョンとともにアップロードされる。
  • マップを更新しても、動いている Container のインスタンスは再起動も置き換えもされない。
  • 段階的なデプロイの間は、デプロイが終わるまで Durable Object ごとに違うイメージで起動しうる。
• ランタイムは basic も、レガシーの dev と standard の別名も受け付けない。
• 独自のサイズは、ランタイムではキャメルケース (memoryMib、diskMb)、Wrangler の instance_type のオブジェクトではスネークケースで書き、後者は default のポリシーにだけ適用される。
• スナップショットは、作ったときのイメージに結びつく。
  • イメージを更新したら、そのイメージで動く Container から新しいスナップショットを作る。
• durable_object のポリシーは max_instances に対応しない。
  • 動いているインスタンスは、アカウントの上限に数えられる。
• durable_object のポリシーは ssh と authorized_keys の欄に対応する。
• 例は "compatibility_date": "2026-09-29" と、exports の下に宣言した SQLite を使う Durable Object を使う。

[A] Cloudflare Docs — Limits and Instance Types (2026-09-30)

https://developers.cloudflare.com/containers/platform/limits/

• lite は 1/16 vCPU、256 MiB、ディスク 2 GB、basic は 1/4 vCPU、1 GiB、4 GB、standard-1 は 1/2 vCPU、4 GiB、8 GB。
• standard-2 は 1 vCPU、6 GiB、12 GB、standard-3 は 2 vCPU、8 GiB、16 GB、standard-4 は 4 vCPU、12 GiB、20 GB。
• 独自のインスタンスタイプは 1〜4 vCPU、メモリは最大 12 GiB、ディスクは最大 20 GB で、vCPU あたり最低 3 GiB のメモリが要る。
• アカウントの上限は、同時に使うメモリ 6 TiB、同時の vCPU 1,500、同時のディスク 30 TB、イメージのサイズはインスタンスのディスクまで、イメージの保存の合計はアカウントあたり 50 GB。
• スナップショットの上限は最大 20 GB で、保持は作成か最新の復元から 30 日。
• より大きなインスタンスやより高いアカウントの上限は、アカウントチーム、サポートチケット、フォームから申し込む。

[A] Cloudflare Docs — Containers Pricing (2026-10-05)

https://developers.cloudflare.com/containers/pricing/

• Containers は動いている間 10ms ごとに課金され、月額 $5 の Workers Paid プランに含まれる利用分があり、Free プランはない。
• メモリは月 25 GiB 時間まで含まれ、超過分は GiB 秒あたり $0.0000025。
• CPU は月 375 vCPU 分まで含まれ、超過分は vCPU 秒あたり $0.000020。
• ディスクは月 200 GB 時間まで含まれ、超過分は GB 秒あたり $0.00000007。
• メモリとディスクの利用量は選んだインスタンスタイプで割り当てた量にもとづき、CPU は実際に使った分だけで数える。
• 課金はコンテナにリクエストが送られるか起動したときに始まり、コンテナのインスタンスがスリープした後に止まる。
• 外向きの転送量は、北米と欧州が GB あたり $0.025 (1 TB まで含まれる)、オセアニア、韓国、台湾が $0.05 (500 GB まで含まれる)、その他が $0.04 (500 GB まで含まれる)。
• Workers と Durable Objects の利用は別に課金され、ログは Workers Logs の料金になる。
• ページにスナップショットの料金は載っていない。

[A] Cloudflare Docs — Image Management (2026-09-30)

https://developers.cloudflare.com/containers/guides/image-management/

• cloudflare/debian-trixie は durable_object のポリシーでだけ使え、元はダイジェストで固定した node:24.20.0-trixie-slim (Debian Trixie slim 上の Node.js 24.20.0)。
• cloudflare/debian-trixie は Cloudflare が管理する識別子で、Docker Hub にある Cloudflare の公開イメージではない。
• 更新したイメージのマップをデプロイしても、動いている Container は再起動しない。
  • durable_object のポリシーでは、アプリケーションが制御するこの再起動でイメージの変更を展開する。
• 動いている Container をすぐ更新するには、inspect() のイメージと設定したイメージを比べ、違えば destroy() する。
  • 起動中の Container と、スナップショットから復元した Container では、inspect() のイメージは空になる。
• ほかのレジストリのイメージは Cloudflare のマネージドレジストリに push してダイジェストで参照する必要があり、CI では wrangler containers build --push か wrangler containers push を使える。

[A] Cloudflare Docs — Use snapshots (2026-09-30)

https://developers.cloudflare.com/containers/guides/snapshots/

• snapshotContainer() で、コンテナのファイルシステム全体をとる。
• 返るスナップショットのハンドルは、ただのデータのオブジェクト。
  • 保存しておき、後で別の Durable Object からでも復元できる。
• スナップショットを復元した後にファイルを変えたら、その変更を残すには新しいスナップショットを作る。
• 保持は復元のたびに延びる暗黙の 30 日の有効期限で、独自の有効期限はまだ設定できない。

[A] Cloudflare Docs — Migrate to the Durable Object scheduling policy (2026-09-30)

https://developers.cloudflare.com/containers/guides/migrate-to-durable-object-scheduling-policy/

• 既存の Container のアプリケーションのスケジューリングポリシーは変えられない。
  • 置き換えのアプリケーションは、新しい Durable Object のクラスと名前空間を使わなければならない。
• Container クラスは durable_object のポリシーに対応しない。
  • 置き換えのクラスは Durable Object Container API を使い、ポートの準備の確認、リクエストのプロキシ、スリープのタイムアウトのようなヘルパーを作り直す。
• Docker Hub、Amazon ECR、Google Artifact Registry のイメージは、まず Cloudflare のマネージドレジストリに push する。
• 対応関係は、instance_type が起動オプションの instance になり、max_instances は非対応で、アプリケーション全体の展開は各 Container を止めて起動するアプリケーションのコードになる。
• 配置の制約、展開の設定、wrangler_ssh、trusted_user_ca_keys は、置き換えのアプリケーションでは使えない。
• サイズの置き換えは、dev が lite、standard が standard-1、basic が lite か standard-1 で、独自のインスタンスタイプには最低 1 vCPU が要るためだとする。
• Container クラスは、enableInternet = false を設定しない限り、外向きのインターネットへのアクセスを許す。
• 置き換えの名前空間の Durable Object は、古い名前空間のストレージにアクセスできない。
  • Durable Object の状態を移す必要があるなら、置き換えの名前空間に振り向ける前に、サンドボックスごとにアプリケーション固有の移し替えを終えておく。
• バインディングは論理的な Container ごとに選ぶ (割合での展開の間に両方のバインディングで同じ名前を扱うと、Container が 2 つ動いて状態が食い違いうるため)。
• ロールバックは古いバインディングに振り向け直すことで、切り替えの後の書き込みは置き換えの名前空間に残る。

[A] Cloudflare Docs — Migrate from the Container class to the Durable Object Container API (2026-09-29)

https://developers.cloudflare.com/containers/guides/migrate-to-durable-object-container-api/

• Durable Object を置き換えずに、実装を移せる。
  • TypeScript のベースクラスを変えても、Durable Object の新しいマイグレーションは要らない。
• start() は ctx.container.start() に、stop() は signal() か destroy() になる。
• defaultPort、containerFetch()、自動の fetch() のルーティングは、getTcpPort(port).fetch() と、自前のルーティングと準備の確認になる。
• sleepAfter は setInactivityTimeout() に、ライフサイクルのフックと schedule() はアプリケーションのコード、monitor()、Durable Object のアラームになる。
• 確かめるべき試験として、起動、同時のリクエスト、準備の確認、アイドル時の停止、アラームの配信、ストレージの継続、コンテナの再起動後の回復を挙げる。

[A] Cloudflare Docs — Containers API, choose an API (2026-09-29)

https://developers.cloudflare.com/containers/api/

• 新しいアプリケーションには Durable Object Container API を勧める。
• Container クラスは、既存のアプリケーションのために引き続き文書化されている。
• クラスは startAndWaitForPorts()、waitForPort()、onStart()、onStop()、onError()、onActivityExpired()、sleepAfter、schedule() を提供する。
  • 直接の API では、getTcpPort() による準備の確認、同時の start() の調整、ライフサイクルのフックはアプリケーションのコードになる。
• 直接の API は、レイテンシに敏感なワークロードや、ストレージの使用量を小さくしたいアプリケーションにも向くとする。

[A] Cloudflare Docs — Sandboxes on Cloudflare (2026-09-30)

https://developers.cloudflare.com/sandbox/

• Workers Paid プランで使える。
• Cloudflare は、どちらも Worker から使う 2 つのサンドボックス環境、Containers と Dynamic Workers を提供する。
• 各インスタンスは専用のカーネルとネットワークを持つ microVM で、ほかのワークロードと共有しない。
• サンドボックスのコンテナは、パブリックベータの Durable Object のスケジューリングポリシーを使う。
• Dynamic Workers は、信頼できない JavaScript、Python、WebAssembly を実行時に作る Worker として動かし、globalOutbound: null で外向きのリクエストを遮断する。
• コーディングエージェントのガイドにリンクし、Claude Code、Codex、Devin のようなコーディングエージェントを、1 つのタスク専用のサンドボックスで動かす方法を示す。
• 以前の /sandbox/1-0-preview/ の URL は、このページに転送される (2026-10-06 に取得)。

[A] Cloudflare Docs — Sandbox lifetime (2026-09-30)

https://developers.cloudflare.com/sandbox/concepts/lifetime/

• Linux のサンドボックスは、名前、Durable Object、Containers のインスタンスの 3 つからなる。
  • インスタンスは、何かが動かし続けている間だけ動く。
• Durable Object が非アクティブになった後、インスタンスは setInactivityTimeout() の値 (最大 6 時間) だけ動き続け、タイムアウトがなければ間もなく止まる。
• インスタンスの中で動くコードは、活動に数えられない。
  • リクエストが来なければ、ビルド、テストスイート、エージェントのタスクがまだ中で動いていても、非アクティブのタイムアウトが切れた時点でインスタンスは止まる。
  • タイムアウトより頻繁に動くアラームがあればインスタンスは動き続け、バックグラウンドのプロセスのガイドは 1 分ごとのアラームを使う。
• インスタンスが止まるのは、タイムアウトが切れたとき (すべてのプロセスが SIGTERM を受ける)、Worker が destroy() を呼んだとき (プロセスが後始末する時間はない)、メインのプロセスが終了したとき。
• cloudflare/debian-trixie の既定のコマンドはすぐ終了するので、サンドボックスの例はこのイメージを sleep infinity をエントリーポイントにして起動するか、Web サーバーをメインのプロセスとして動かす。
• デプロイはすべての Durable Object を再起動するが、動いているインスタンスはファイルとプロセスごと残り、サンドボックスを置き換える展開はない。
• 新しいインスタンスは同じプロセス ID を使い回すので、ファイルに保存したプロセス ID が、復元の後には別のプロセスのものになっていることがある。
• /run のファイルはメモリ上にあり、スナップショットには保存されない。
• Cloudflare がスナップショットを自動で復元することはない。
• コーディングエージェントの例では、リポジトリ、依存関係、編集はスナップショットから戻るが、開発サーバーは戻らない。
• マウントした R2 のバケットのファイルはどのインスタンスより長く残り、マウントしたディレクトリはスナップショットに含まれない。
• インスタンスが止まっても、Cloudflare は Durable Object を起こさない。

[A] Cloudflare Docs — Sandbox security (2026-09-30)

https://developers.cloudflare.com/sandbox/concepts/security/

• 隔離は、コードが自分のサンドボックスの中で何をするかまでは制限しない。
• 配備したサンドボックスでは、すべてのプロセスが root と同じ Linux の capabilities を持つので、ファイルのパーミッションは制約にならず、root に戻ることもできる。
• したがって、サンドボックスが信頼の最小単位になる。
• 例として、クローンの URL に入れたトークンは .git/config に残り、テストの依存パッケージがそれを読める。
  • 認証情報はサンドボックスの外に置くほうが安全。
  • Worker の外向きのハンドラーが、リクエストがサンドボックスを出た後に、HTTPS のリクエストにだけ認証情報を加える。
• スナップショットは .git/config のトークンを含めてそうしたファイルを保存し、復元すると元に戻る。
• 名前やスナップショットを別の人に使い回すと、前のユーザーのファイルがその人に渡る。
• Container は既定で enableInternet: false で起動するので、インターネットに届かない。
• ハンドラーが見るのは、ポート 80 の HTTP とポート 443 の HTTPS。
  • インターネットへのアクセスをオンにすると、ほかのポートへの接続はそのまま外に出る。
• プレビューは別のホスト名で配信し、サンドボックスのページがアプリケーションの Cookie や API を使えないようにすべきだとする。

[A] Cloudflare Docs — Migrate from Sandbox SDK 0.x (2026-09-30)

https://developers.cloudflare.com/sandbox/sdk/migrate/

• 1.0 への移行では、Sandbox クラスを自分で書く Durable Object のクラスに置き換え、パブリックベータの durable_object のポリシーを使う。
• 1.0 のサンドボックスは起動が速い。
  • 準備済みのイメージでは、start() から最初のコマンドまでの時間の中央値は 600 ms 未満で、0.x では約 4 s だった。
• Sandbox SDK 0.x は 2026-12-31 までバグとセキュリティの修正を受け、新機能は入らない。
• ページは 1.0 を 0.x の最後のリリースの 0.12 と比べており、それより前の利用者はまず @cloudflare/sandbox 0.12.10 と docker.io/cloudflare/sandbox:0.12.10 のイメージに上げる。
• 切り替えは一方向で、1 回のデプロイですべてのサンドボックスを移すか、1.0 のクラスを 0.x のクラスと並べてサンドボックスを 1 つずつ移すかのどちらかを、ステージングの Worker でリハーサルしてから行う。
• grep -rhow のコマンドで、src で使っている 0.x の API の名前を数える。
  • 0.12 の codex-app-server のテンプレートでは、getSandbox が 6、proxyToSandbox が 2、sleepAfter が 2、interceptHttps が 2 などと出る。
• コマンド、ファイル、バケットのマウントの呼び出しは書き換えが要り、バックグラウンドのプロセス、プレビューの URL、トンネル、端末、外向きのルール、バックアップ、コードインタープリターはコードの追加が要る。
• FROM docker:dind-rootless で作ったイメージは、サンドボックスの中で Docker を動かすためにイメージの変更が要る。
• 移るまでは @cloudflare/sandbox を 0.12.10 に固定し、2026-06-09 に非推奨になった 0.x の機能 (HTTP と WebSocket のトランスポート、exposePort()、既定のセッション、別立てのストリーミングのメソッド) を避ける。

[A] Cloudflare Docs — Changes in Sandbox SDK 1.0 (2026-09-30)

https://developers.cloudflare.com/sandbox/sdk/migrate/changes-in-1-0/

• 0.x ではパッケージの Sandbox クラスが Durable Object で、各呼び出しをコンテナの中のサーバーに送っていた。
  • 1.0 では、0.x の SDK のサーバーがしていたことを this.ctx.container が行う。
• アプリケーションに依存する判断 (サンドボックスをどれだけ動かすか、何に届くか、呼び出しが失敗したらどうするか) はアプリケーションのコードに残る。
• start() が enableInternet: true を渡さない限り、コンテナはインターネットにアクセスできない。
• 引数として渡したテキストから 2 つ目のコマンドが起動することはない。
  • cwd と env を呼び出しから次の呼び出しへ引き継ぐセッションはない。
• デプロイは、動いているコンテナを置き換えない。
• 0.x のイメージには Python、Git、curl、wget、jq、unzip、ps が入っている。
  • これらのページが使う cloudflare/debian-trixie と node:24-trixie-slim には、そのどれも入っていない。
• パッケージは Durable Object のストレージに何も書かない。
• パッケージは再試行もせず、時間の制限も設けない。
  • 長いコマンドは GNU coreutils の timeout で制限する。

[A] Cloudflare Docs — @cloudflare/sandbox reference (2026-09-30)

https://developers.cloudflare.com/sandbox/reference/

• パッケージはコンテナを起動も停止も監視もしない。
• 要件の 1 つは、イメージに /usr/local/bin/sandbox-shim が入っていることで、パッケージのバージョンと同じタグの cloudflare/sandbox のイメージからコピーする。
  • このヘルパーは静的にリンクした linux/amd64 のバイナリ。
• もう 1 つの要件は、Worker に nodejs_compat のフラグがあり、メソッドを呼ぶときにコンテナが動いていること。
• Dockerfile の例は、FROM node:24-trixie-slim、COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim、RUN mkdir /workspace、CMD ["sleep", "infinity"]。
• Wrangler の例は、"compatibility_date": "2026-10-05"、nodejs_compat、workspace という名前のイメージ 1 つを持つ durable_object のポリシー、start() の後とコンストラクターで設定する 10 分の非アクティブのタイムアウトを使う。
• クラスは Files API、S3Mount API、DirectoryBackup API。

[A] Cloudflare (GitHub) — cloudflare/sandbox-sdk repository README (2026-09-24)

https://github.com/cloudflare/sandbox-sdk

• サンドボックスは、Durable Object と、それが起動する Container からなる。
• Files はファイルをストリームで出し入れして ENOENT のような Linux のエラーを報告し、S3Mount は Worker で各ストレージのリクエストに署名するので認証情報がサンドボックスに入らず、DirectoryBackup は新しいイメージのものを含むどの Container にもディレクトリを復元する。
• テンプレートは npm create cloudflare@latest -- my-sandbox --template=cloudflare/sandbox-sdk/examples/minimal で、URL の名前ごとに専用のサンドボックスを与える。
• 1.0 では自分の Durable Object が Container を起動し、このパッケージが提供するのはファイル操作とバケットのマウントだけ。
• 0.x のソースは v0 のブランチにある。
• リポジトリには crates/sandbox-tools (sandbox-shim)、images/sandbox-tools (cloudflare/sandbox のイメージ) と、目的ごとの例 (チェックポイントとバックアップのワークスペース、外向きのルール、コーディングエージェント、devin、openai/agents-api など) がある。
• 2026-10-06 の時点で、スターは 1.1k、フォークは 116。
• タグは @cloudflare/sandbox@1.0.0-rc.0、-rc.1、-rc.2、@cloudflare/sandbox@1.0.0 (2026-09-30T01:42:20Z) と続くが、GitHub の Releases の一覧は 0.12.10 (2026-09-23) で止まっている。

[A] npm — @cloudflare/sandbox package metadata (2026-10-06 取得時点)

https://registry.npmjs.org/@cloudflare/sandbox

• 1.0.0 は 2026-09-30T01:44:26Z に公開され、その前に 1.0.0-rc.0 (2026-09-26)、rc.1 (2026-09-28)、rc.2 (2026-09-29) が出ていた。
• 0.x の最後のリリースの 0.12.10 は、2026-09-23T10:36:01Z に公開された。
• 2026-10-06 の dist-tags は、latest が 1.0.0、rc が 1.0.0-rc.2、next が 0.13.0-next.776.1。
• 1.0.0 の説明は、Cloudflare のサンドボックスのための構造化されたワークスペースのファイル操作という趣旨で、依存は zod 4.5.4 と aws4fetch 1.0.20。

[A] Cloudflare (GitHub) — containers-demos/sandbox README (2026-10-05)

https://github.com/cloudflare/containers-demos/tree/main/sandbox

• 最小限のサンドボックスの HTTP API を公開する Cloudflare Worker。
  • コンテナの start() API を使い、Worker のコードの中でコンテナのイメージと設定をプログラムから指定する。
• 前提は、Node.js と pnpm、デプロイ時に builder のイメージをビルドするための Docker、Durable Objects と Containers が有効なアカウント。
• 認証は SANDBOX_API_KEY の Bearer トークンで、openssl rand -hex 32 で作り、wrangler secret put で保存する。
• ルートは、POST /v1/sandbox でサンドボックスを作り、POST /v1/sandbox/:id/exec で引数の配列を実行し、DELETE /v1/sandbox/:id で破棄する (HTTP 204)。
• 作成の本文は vcpu、memoryMib、diskMb をまとめて受け取り、image (builder は Node.js 24 とよく使うビルドツールを加える) も受け取る。
  • サイズを指定しなければ、コンテナは standard-1 のインスタンスタイプを使う。
  • image を指定しなければ、cloudflare/debian-trixie を使う。
  • コンテナはインターネットに届く。
• exec は argv、cwd、timeout_ms (既定は 30,000、最大 900,000) を受け取り、base64 の stdout と stderr、最後の exit のイベントを server-sent events で流す。
• このディレクトリの最新のコミットは、サンドボックスの作成時にサイズとイメージを受け付けるようにした 2026-09-28 のものと、RPC の呼び出し元からの起動オプションを検証するようにした 2026-10-05 のもの。

[A] Cloudflare Blog — Everything we launched during Birthday Week 2026 (2026-10-05)

https://blog.cloudflare.com/birthday-week-2026-wrap-up/

• Containers の記事は、Wednesday, September 30 - Powering the agent economy の見出しの下に並ぶ。
• その要約は、Containers の起動が速くなり、イメージとインスタンスを柔軟に選べ、新しいスケジューリングの制御と、エージェントの永続的なワークスペースのためのファイルシステムのスナップショットが加わったというもの。
• まとめには、Sandbox SDK 1.0 の独立した項目はない。

[A] Cloudflare Blog — Agents have their own computers with Sandboxes GA (2026-04-13、背景)

https://blog.cloudflare.com/sandbox-ga/

• 30 日より前の背景として、Sandboxes と Cloudflare Containers がどちらも一般提供になったと発表した記事。
• スナップショットは今後数週間で展開するとしていた。
  • スナップショットは、コンテナのディスクの状態全体、OS の設定、導入済みの依存関係、変更したファイル、データファイルなどを保存すると説明していた。
• 当時の API は Sandbox クラスにあり、スリープ時のスナップショットに persistAcrossSessions = {type: "disk"}、分岐に baseInstance.snapshot() と start({ snapshot: snapshotId }) を使っていた。
• スナップショットはアカウント内の R2 に保存し、耐久性と場所からの独立を得るとしていた。
• 将来のリリースでは動いているメモリの状態もとり、動いているプロセスを止めたところから正確に再開できるようにするとしていた。
• 暫定のバックアップと復元のメソッドでは、サンドボックスを起動して axios をクローンし、npm install するまでに 30 秒かかった。
  • バックアップからの復元は 2 秒だった。

[A] ComputeSDK — Burst TTI results, results/burst_tti (2026-03-13〜2026-10-02)

https://github.com/computesdk/benchmarks/tree/master/results/burst_tti

• GitHub API で、実行ごとに 1 つずつコミットされた JSON のファイルとして読んだ。
• ブログの以前のスケジューリングの経路の行は、2026-07-13 (01:13:16Z) の実行と一致する: 中央値 4,049.26 ms、p95 5,839.19 ms、p99 6,716.69 ms、成功率 100%、総合スコア 51.03、20 のプロバイダーのうち 18 位。
• ブログの新しいスケジューリングポリシーの行は、2026-09-25 (16:26:45Z) の実行と一致する: 中央値 647.84 ms、p95 910.11 ms、p99 1,129.21 ms、成功率 100%、総合スコア 92.14、30 のプロバイダーのうち 12 位。
  • 同じ実行では、100 のサンドボックスすべての経過時間 (wall clock) が 3,874.18 ms、最初のサンドボックスの準備完了までが 460.21 ms だった。
• 次の 2026-10-02 (13:16:13Z) の実行は、中央値 536.29 ms、p95 727.39 ms、p99 780.17 ms、経過時間 1,874.80 ms、最初の準備完了 393.25 ms、総合スコア 93.79、30 のうち 9 位。
• 2026-10-02 のほかのプロバイダーの中央値は、Daytona 332.50 ms、Vercel 475.06 ms、Cloud Run 514.77 ms、E2B 1,275.82 ms、Modal 1,568.94 ms、CodeSandbox 7,531.54 ms で、最速の isorun は 72.77 ms。
• 2026-09-25 のほかのプロバイダーの中央値は、Daytona 341.39 ms、Vercel 452.89 ms、Cloud Run 492.87 ms、Blaxel 556.55 ms、Modal 907.55 ms、E2B 1,237.69 ms。
• 2026-07-13 の中央値は、Vercel 446.73 ms、Daytona 451.21 ms、Cloud Run 489.28 ms、E2B 496.18 ms、Modal 627.79 ms。
• Cloudflare のそれ以前の履歴では、2026-03-18 から 2026-06-25 までの完全に成功した 96 回の実行の中央値が 1,640〜4,426 ms で、真ん中の値は 2,026 ms。
• 2026-06-26 から 07-05 までの 10 回の実行では Cloudflare のサンドボックスが 1 つも成功せず、07-06 の実行の成功率は 30%。
• 2026-07-07 から 09-18 までの完全に成功した 17 回の実行では、09-10 の 917.46 ms を除いて中央値が 3,534〜5,702 ms、真ん中の値は 4,648 ms で、09-04 の実行は成功率 95%、中央値 5,177 ms だった。
• 実行は 2026-07-13 まではほぼ毎日、07-17 からはほぼ毎週。
• 各実行は 100 のサンドボックスを 120,000 ms のタイムアウトで起動し、10-02 のファイルには Linux x64 上の Node v24.21.0 が記録されている。

[A] ComputeSDK — Benchmark Methodology (2026-08-11)

https://github.com/computesdk/benchmarks/blob/master/METHODOLOGY.md

• TTI は、サンドボックスの作成のリクエストを出してから最初のコマンドの実行に成功するまでの経過時間と定義される。
• プロバイダーの API までのネットワークの往復、キューでの待ち、インフラの割り当て、OS とランタイムの起動、エージェントの初期化、準備完了のポーリング、最初のコマンドを含む。
  • 後片付け、その後のコマンド、ファイルシステムの操作、サンドボックスの中のネットワークの速さは含まない。
• 各回は compute.sandbox.create() と sandbox.runCommand('node -v') を計り、後片付けは計らない。
• バーストモードでは、すべてのサンドボックスを同時に作り、起動の間に待ちを入れない。
  • 100 のサンドボックスをそれぞれ 120 秒のタイムアウトで動かし、経過時間、最初の準備完了までの時間、成功率も報告する。
• バーストが重要な理由として、AI エージェントやオーケストレーションのツールは多くのサンドボックスを一度に立ち上げることが多いと説明する。
• 実行環境は Namespace のランナー上の GitHub Actions (Ubuntu、Node.js 24.x) で、プロバイダーはランダムな順に 1 つずつ実行する。
• プロバイダー固有のリージョンからは実行せず、予約したネットワークの容量も使わず、失敗したリクエストを再試行しない。
• 総合スコアは時間のスコアに成功率を掛けたもので、各指標を 100 × (1 − 値 / 10,000 ms) で採点し、中央値 0.60、p95 0.25、p99 0.15 で重み付けし、成功した回の上下 5% を除いてから計算する。

[A] ComputeSDK — @computesdk/cloudflare changelog (2026-10-05)

https://github.com/computesdk/computesdk/blob/main/packages/cloudflare/CHANGELOG.md

• 2.0.0 (npm での公開は 2026-09-24T19:48Z) は、リモートと直接の Cloudflare のサンドボックスに、Cloudflare のサンドボックスのデモの Worker を使うようにした。
  • 直接モードは Worker の Durable Object の RPC API を呼び、サンドボックスの ID にネイティブの Durable Object の ID を使い、ファイルシステムの操作を exec で行うようになった。
• 2.1.0 (2026-10-05 に公開) は、sandbox.create() から vcpu、memoryMib、diskMb、image をデモの Worker に渡し、新しいサンドボックスのサイズとイメージを選べるようにした。
• プロバイダーのソースは、デモの Worker のルートである /v1/sandbox と /v1/sandbox/<id>/exec を呼んでいる (2026-10-06 の GitHub のコード検索)。

[A] ComputeSDK — Pull request #470, fix: use SANDBOX_API_KEY for Cloudflare benchmarks (2026-09-25)

https://github.com/computesdk/benchmarks/pull/470

• kisernl が 2026-09-25T01:41:07Z に開いて 01:44:33Z にマージしたもので、09-25 の実行の約 15 時間前だった。
• Cloudflare のプロバイダーの設定を CLOUDFLARE_SANDBOX_SECRET から、sandboxApiKey として渡す SANDBOX_API_KEY に切り替え、プロバイダーの一覧、環境変数のテンプレート、TTI、capabilities、DAX のワークフローを変えた。
• プロバイダーの認証情報が要るため、実際の Cloudflare のベンチマークは (PR の段階では) 走らせていないとする。

[B] Publickey — Cloudflare ContainersがAIエージェント向けに刷新 起動が6倍速、ファイルシステムのスナップショット機能など (2026-10-06)

https://www.publickey1.jp/blog/26/cloudflare_containersai6.html

• Cloudflare Containers を「同社のエッジロケーションでコンテナ型仮想マシンを実行可能にする」サービスと紹介し、それを AI エージェント向けに刷新したと伝える。
• 2026 年 9 月 30 日の Cloudflare の X の投稿を埋め込んでおり、その投稿は、起動が 6 倍速くなり、エージェントが実行時にサンドボックスごとのイメージとインスタンスタイプを選べ、ファイルシステムのスナップショットにパブリックベータで対応し、そのすべてを Durable Object から制御できると告げている。
• 背景を「これまでのCloudflare Containersは人間のソフトウェア開発者によって構成され、デプロイされ、アプリケーションが実行されることを想定していました」と説明する。
  • 続けて「多数のAIエージェントが自身の開発環境やテスト環境、実行環境などとしてコンテナ型仮想化を利用するようになったことで、大量のコンテナ型仮想マシンの需要が発生するようになったのです」と書く。
• 変更の 1 つ目は新しいスケジューリング方式による起動の高速化で、「同社によると、起動時間のこれまでの中央値が4.049秒だったものを、今回の刷新で648ミリ秒に改善したとのこと」とする。
• 2 つ目は「コンテナ実行時にコンテナイメージとインスタンスサイズをコードで指定できるようになった」こと。
• 3 つ目は「Debian Trixie SlimとNode.js 24 LTSを含むベースイメージ」で、「Dockerfileを作成しなくとも即座にAIエージェント用のサンドボックス環境としてCloudflare Containersを起動できるようになった」とする。
• 4 つ目は「ある時点のコンテナ内ファイルシステムの状態を保存し、後で同じ状態に復元できるスナップショット機能」で、「特定の開発環境などをすぐに用意できるようになる（現在ベータ版）」とする。
• 「Cloudflareは同社のアプリケーションプラットフォームを急速にAIエージェント向けに最適化していると言ってよさそうです」と結ぶ。
• ComputeSDK、durable_object のポリシーの名前、Sandbox SDK 1.0、2026 年末の保守の期限には触れていない。

[B] Latent Space — [AINews] not much happened today (2026-10-03)

https://www.latent.space/p/ainews-not-much-happened-today-cee

• 2026 年 10/1〜10/2 の AI ニュースを扱う号。
• Platform updates の項で、Sandbox SDK 1.0 によって Durable Object がサンドボックスのコンテナを直接制御できるようになったと伝え、@CFchangelog の投稿を引いており、その投稿の ID から日時は 2026-10-02 10:00 UTC とわかる。
• 同じ項目で、Cloudflare がリクエストの Traces も出したと付け加える。

[B] The New Stack — AWS, Google Cloud, Microsoft Azure, and Cloudflare now all offer agent sandboxes; none built them the same way, by Janakiram MSV (2026-07-24、背景)

https://thenewstack.io/cloud-agent-code-sandboxes/

• このリリースより前に書かれた背景で、4 つの主要なクラウド (AWS、Google Cloud、Microsoft Azure、Cloudflare) がいずれも隔離したコード実行をネイティブの基本機能として提供しているが、隔離の仕組みとライフサイクルのモデルは大きく違うとする。
• AWS Lambda MicroVMs は Firecracker 上でセッションごとに専用の VM を使い、最大 8 時間の実行と、メモリ、ディスク、動いているプロセスを保つ一時停止と再開を備える。
  • Lambda MicroVMs は 5 つのリージョンの Graviton で動き、上限は 8 時間。
• Google は GKE Agent Sandbox に gVisor を使い、Cloud Run のサンドボックスは親のインスタンスの CPU とメモリを追加料金なしで借りる。
  • Google は、1 つの Cloud Run のサービスが 1,000 のサンドボックスを平均 500 ミリ秒ずつで起動、実行、停止したデモを報告した。
• Azure Container Apps の dynamic sessions は 2024 年から Hyper-V の境界で動いており、Copilot だけでもこのセッションを 1 日に 400,000 以上使うとする。
• Cloudflare は Containers の上に Sandboxes を作り、各サンドボックスを専用の VM で隔離し、Workers と Durable Objects から制御する。
• 隔離は封じ込めの境界であってガバナンスの層ではなく、認証情報とネットワークの到達範囲は設定上の判断として残ると指摘する。

[C] GitHub — rocketflare-dev/rocketflare-launch issue #18, Later: Sandbox SDK 1.0 migration and per-app container snapshots (2026-10-05)

https://github.com/rocketflare-dev/rocketflare-launch/issues/18

• cliftonc が Oct 5, 2026 に、スターが 1 つのリポジトリで開いた。
• @cloudflare/sandbox のレガシーの Sandbox ベースクラスは、2026-12-31 まで保守のみになると書く。
• スナップショットはルートファイルシステムをとり、1 つのスナップショットでそのクラスのどの Container も起動でき、コールドスタートは約 650 ms、保持は 30 日だとまとめる。
• そのため、バックアップにもとづく事前ビルドの自然な後継になると見る。
• 予定の範囲は、SessionSandbox とそのポートを SDK 1.0 に移し、バックアップにもとづく事前ビルドを durable_object のポリシーでのアプリごとの Container のスナップショットに置き換え、スナップショットの ID がなければベースのイメージに戻るというもの。
• 1.0 を @next のプレビューと呼んでいるが、npm の latest のタグは 2026-09-30 から 1.0.0 を指している。

メモ

• Sandbox SDK 1.0 は同じ日に出た付随のリリースで、別の発表ではない。
  • 独自の changelog のエントリ (2026-09-30) と npm のリリース (1.0.0、01:44 UTC) があり、ブログの記事は 1 つの節で扱い、Birthday Week のまとめは Containers の記事だけを挙げる。
  • AINews はリリースの 2 日後、2026-10-02 の @CFchangelog の投稿からこれを拾った。
  • 高速化、実行時のイメージの選択、スナップショットは Containers のプラットフォーム (ctx.container) の機能で、1.0 のパッケージに残るのは Files、S3Mount、DirectoryBackup だけ。
• 6 倍という数値は、約 11 週間離れた ComputeSDK の 1 回ずつの実行 (2026-07-13 と 2026-09-25) を比べたもの。
  • 07-07 から 09-18 までの完全に成功した 17 回の実行での Cloudflare の中央値は 3,534〜5,702 ms (真ん中の値 4,648 ms) なので、選ばれた基準は低めの側にあり、典型的な値に対する倍率は約 7 倍になる (このノートでの計算)。
  • 2026-03-18 から 06-25 までの同じスイートの真ん中の値は 2,026 ms で、2026 年春と比べると倍率は約 3 倍になり、6 月下旬の失敗した実行の後に 4〜5 s へ跳ねた理由は、コミットされたファイルからはわからない。
  • 2026-09-10 の実行 (917.46 ms) は 5,177 ms と 5,702 ms の実行に挟まれており、読んだ資料にその説明はない。
• 新しい経路の数値は、Cloudflare 自身のサンドボックスのデモの Worker に向けた ComputeSDK の Cloudflare のプロバイダーによるもの (09-24 の @computesdk/cloudflare 2.0.0 と 09-25 の PR #470)。
  • 10-05 のプロバイダー 2.1.0 まではサイズもイメージも渡していなかったので、09-25 と 10-02 の実行はおそらくデモの既定値、つまり standard-1 と事前に配置された cloudflare/debian-trixie を使った (プロバイダーの changelog とデモの README からの推測)。
  • 独自の Dockerfile のイメージやスナップショットからの復元は、この事前配置のイメージより起動が遅いかもしれず、読んだ資料にそのどちらを測ったものもない (イメージの準備が残りの待ち時間の大きな部分になっていくというブログ自身の注記からの推測)。
  • ベンチマークの CLOUDFLARE_SANDBOX_URL の背後の Worker を誰がデプロイし、運用しているかは書かれていない。
• 起動時間の数値は 3 つ出回っている: 648 ms (ブログ、同時 100 サンドボックスでネットワークの往復を含むクライアント側の TTI)、準備済みのイメージで start() から最初のコマンドまで 600 ms 未満 (Sandbox SDK の移行ガイド)、536 ms (ComputeSDK の 10-02 の実行)。
• ComputeSDK は README (https://github.com/computesdk/benchmarks) で自らのベンチマークをプロバイダー中立とし、スポンサーは結果に影響できないとしている。
  • GitHub API で読んだ SPONSORSHIP.md は、現在のスポンサーとして Archil と Latitude (Tier 1)、Tigris (Tier 2) を挙げ、Cloudflare は載っていない (https://github.com/computesdk/benchmarks/blob/master/SPONSORSHIP.md)。
• 順位は ComputeSDK の総合スコアによるもので、ほかのプロバイダーも毎週の実行の間で動く (E2B の中央値は 07-13 に 496 ms、09-25 に 1,238 ms) ため、1 回の実行は順位づけの根拠として薄い。
• ブログの冒頭はバーストテストで数十万の Container を数秒で作ったとするが、本文が報告するのは、6 つのロケーションで 100,000 の Container を 5.387 秒で起動した予備的な試験 1 回だけ。
  • 既定のアカウントの上限 (同時の vCPU 1,500、メモリ 6 TiB、ディスク 30 TB) のもとでは、1 つのアカウントで同時に動かせる lite のインスタンスはディスクで決まって約 15,000 (30 TB / 2 GB) なので、この試験は上限を引き上げて行われた (このノートでの計算)。
• Publickey は 4.049 秒から 648 ミリ秒への数値を Cloudflare によるものとし、ComputeSDK の名前を出していないが、Cloudflare の記事はこれを ComputeSDK の独立したベンチマークと呼んでいる。
• 提供状況が食い違う: durable_object のポリシーとスナップショットはパブリックベータ、Sandbox SDK 1.0 はそのベータのポリシーを必要とする安定版のリリースで、Container クラスと 0.x の Sandbox クラスの更新は 2026-12-31 まで。
  • ポリシーがいつベータを抜けるかは、読んだ資料に書かれていない。
• 既存のアプリケーションの移行は一方向で、その場ではできない: ポリシーは変更できず、置き換えには新しい Durable Object のクラスと名前空間が要り、Durable Object のストレージは引き継がれず、Container クラスは新しいポリシーに対応しない。
  • default のポリシーのまま Container クラスから ctx.container に切り替えることはその場でできるが、durable_object 専用のスナップショット、実行時のイメージの選択、速い経路は得られない。
• インターネットへのアクセスの既定が違う: Container クラスは enableInternet = false にしない限り外へのアクセスを許すが、直接の API はオプションを渡すとき enableInternet を必須とし、Sandbox security のページは Container がオフで起動するとしている。
• マネージドイメージは最小限で、cloudflare/debian-trixie には Git、Python、curl、wget、jq、unzip、ps がないため、ブログのように exec() でリポジトリをクローンするにはまずパッケージの導入が要り、それにはインターネットへのアクセスか横取りしたミラーが要る (推測)。
  • 既定のコマンドはすぐ終了するので、ブログの例のように sleep infinity のようなエントリーポイントで起動する必要がある。
• 出荷されたスナップショットは 4 月の GA の記事と違い、書き込み可能なルートファイルシステムだけをとり (メモリ、プロセス、マウントは含まない)、Sandbox クラスではなく ctx.container にあり、4 月に予告した動いているメモリの状態の保存はまだ出ていない。
  • スナップショットのデータがどこに保存され、課金されるのかは、現在のドキュメントに書かれていない。
  • 4 月の記事はスナップショットをアカウント内の R2 に保存するとしていたが、10-05 の料金ページにスナップショットの料金はない。
• 計画に織り込むべきスナップショットの制約は、最大 20 GB、復元でしか延びない 30 日の有効期限 (独自の有効期限はまだ設定できない)、作ったときのイメージへの結びつき、.git/config のトークンのようにファイルシステムに残った秘密情報も保存されること。
• インスタンスの中で動くコードは活動に数えられないので、アラームで Durable Object をアクティブに保たない限り、長いビルドやエージェントのタスクは非アクティブのタイムアウト (最大 6 時間) が切れた時点で止まる。
• The New Stack (07-24) と比べると、AWS Lambda MicroVMs の一時停止と再開はメモリ、ディスク、動いているプロセスを保つが、Cloudflare のファイルシステムのスナップショットはそうではない。
• 公開されている超過料金で計算すると、動いている standard-1 はメモリで 1 時間あたり約 $0.036、ディスクで $0.002 かかり、CPU を常にフルに使えば 1 時間あたり最大 $0.036 が加わり、lite は CPU を除いて 1 時間あたり約 $0.003 (このノートでの計算)。
• ComputeSDK の pricing.json は Cloudflare のストレージをまだ揮発性で永続ストレージなしと説明し、成功 9/100、コールドスタート 2,000 ms という古いベンチマークの記載も並んでいるので、第三者の比較表はスナップショットに追いついていない (https://github.com/computesdk/benchmarks/blob/master/pricing.json、GitHub API で読んだ)。
• コミュニティの反応は薄く、Hacker News への投稿 (item 49909470、2026-09-30) は、2026-10-06 に HN Algolia API で確かめたとき 4 ポイントでコメントはなかった。
  • ほかの検索結果の多くはアグリゲーターによる書き直しで、2026-10-06 までにこのリリースを扱った定評のある英語の分析は見つからず、InfoQ と The New Stack はそれ以前の Cloudflare のサンドボックスの節目を扱っていた (検索結果)。
• 2026-10-06 の時点で記事の日本語訳はなく (/ja-jp/faster-agent-sandboxes/ の URL は 404 を返した)、日本語の視点は Publickey になる。
• 未確認 (検索結果のみ): 以前の Sandbox SDK 1.0 preview のドキュメントのページは、@next タグ上の、プロセスのハンドル 1 つ、PTY の端末、オプトインのコードインタープリターを持つより薄い SDK を説明していた。
  • その URL はいまサンドボックスの概要に転送され、出荷された 1.0 はコマンドの実行をパッケージから完全に外した。
• WebFetch だけで確認したもの: ComputeSDK のプロバイダーのページ https://www.computesdk.com/benchmarks/sandboxes/burst-tti/cloudflare は 10-02 の実行 (536 ms、727 ms、780 ms、成功率 100%) を示していたが、上の数値はすべてコミットされた JSON から取った。
• 読んだ資料には images のマップや scheduling_policy に要る Wrangler の最低バージョンが書かれておらず、例は互換日付 2026-09-29 と 2026-10-05 を使っている。

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

• 起動時間の主張を自分のアカウントで再現する: cloudflare/containers-demos/sandbox をデプロイし、ComputeSDK の pnpm run bench:burst -- --provider cloudflare をそこに向けて、既定の cloudflare/debian-trixie と独自の Dockerfile のイメージで 1 回ずつ走らせ、648 ms のどれだけが事前配置のイメージによるものかを見る。
• 現実的なコーディングエージェントのワークスペースで時間を測る: cloudflare/debian-trixie で exec() を使って中規模のリポジトリをクローンして依存関係を入れ、snapshotContainer() で保存し、復元から最初のコマンドまでの時間を新規の準備と比べる (4 月のバックアップの経路では新規で 30 秒、復元で 2 秒だった)。
• 評価の分岐のパターンを小さく作る: コーディネーターの Durable Object がベースのワークスペースのスナップショットをとり、そこからシステムプロンプトやモデルを変えた 5〜10 の試行を起動し、Container がクラッシュしても各結果を Durable Object のストレージに記録する。
• 認証情報のパターンを試す: enableInternet: false でサンドボックスを起動し、interceptOutboundHttps() でパッケージレジストリと github.com だけを通し、GitHub のトークンを Worker で加え、悪意のあるテスト用の依存パッケージを使って、.git/config、環境変数、スナップショットのどれにもトークンが残らないことを確かめる。
• @cloudflare/sandbox 0.x か Container クラスを使うチームでは、ガイドの grep -rhow による棚卸しをいま走らせ、Durable Object の状態の移し方を含めて、2026-12-31 より前に新しい名前空間への一方向の移行を計画する。
• 一時停止と再開がプラットフォームごとに何を意味するかを、チーム向けの比較メモにまとめる: Cloudflare のファイルシステムだけのスナップショット (20 GB、30 日の有効期限) と、メモリを保つ AWS Lambda MicroVMs の一時停止を、起動時間、セッションの上限、時間あたりの価格とともに並べる。

4. 🔒 Claude Code 2.1.289 と 2.1.290 が、サンドボックスの自動許可のもとでの環境変数の接頭辞から、読み取りの途中で差し替えられたシンボリックリンク、フックが書き換えた入力、組織のガードを上書きするユーザーの mod まで、deny と ask のルールや作業ディレクトリ外の読み取りのブロックを素通りできた一連の穴をふさいだ

• 選定 / 影響度 1 / 将来性 1 / 重要度 2 / 起点 10-03 / 種別: 仕様変更 / 領域: コーディングエージェント、セキュリティ・安全性。
• 候補になったフィード項目:
  • claude-code-changelog 10-04 2.1.289
  • claude-code-changelog 10-06 2.1.290
  • classmethod-claude-code 10-05 Claude Code v2.1.289 の主要アップデート - sandbox auto-allow 時の Bash deny ルール修正と agent.spawn の teammate 対応
  • classmethod-claude-code 10-03 Claude Code の blockReadsOutsideWorkingDirectories で作業ディレクトリ外の読み取りを拒否してみた

前回からの継続

• 2026-10-03 のトピック 1 は、ユーザーの mod が deny ルールや管理設定を上書きしないようにする組み込みのガード (sec-default@builtin) とともに Claude Mods を加えた 2.1.287 と、2.1.288 での後続の修正を扱った。
• その後、2.1.289 と 2.1.290 は、ユーザーが入れた mod やプラグインが組織の統制をすり抜けた 4 つのケース (複合コマンドの入れ子部分への deny や ask のルール、組織が管理する MCP サーバーのサインイン用ツールの説明文、組織のプラグインの読み込みの解除、ガードによる確認の省略) をふさぎ、2.1.290 は tool.check のフックに ceiling と agentId を、turn.step の結果に serverToolUses を、claude plugin validate にゲートのフックが .catch を持つかの一覧を加えた。

収集した情報

[A] Anthropic — Claude Code changelog, 2.1.289 (2026-10-03)

https://code.claude.com/docs/en/changelog#2-1-289

• ドキュメントのページは GitHub の CHANGELOG.md から生成されたもので、このエントリを October 3, 2026 の下に載せる。
• エントリは 27 項目で、Added 1、Fixed 23、Improved 2、Reverted 1。
• サンドボックスの自動許可: サンドボックスがコマンドを自動で許可しているとき、値が展開される環境変数の接頭辞 (たとえば TZ="$HOME" rm -rf build) の後ろのコマンドを、Bash の deny と ask のルールが見逃していた問題を直した。
• サンドボックスの自動許可: コマンドの前に単独の変数代入があると、サンドボックスの自動許可のもとで Bash の deny や ask のルールが飛ばされていた問題を直した。
• 管理対象のマシンの mod: 管理対象のマシンで、複合シェルコマンドの入れ子部分への deny や ask のルールが、ユーザーが入れた mod の承認より優先されていなかった問題を直した。
• 組織の MCP サーバー: ユーザーが入れたプラグインが、組織が管理する MCP サーバーのサインイン用ツールの説明文を書き換えられた問題を直した。
• Read の deny ルール: シンボリックリンク経由で @ メンションしたファイルや、IDE で変更・選択したファイルに Read の deny ルールが適用されていなかった問題を直した。
• mod: teammate 向けの agent.spawn、プラグインのフックのイベントをまたいで共通の agent id、$.agent.list() の idle と waiting の状態を加えた。
• mod: アップグレード後の最初のセッションで、インストール済みの mod が読み込まれなかった問題を直した。
• [VSCode] サインアウトを増やしたかもしれない、2.1.288 での claude auth status の変更を取り消した。
• 閉じていない <script> タグを多く含む短いコードブロックや、深く入れ子になった ${ の置換で端末がフリーズする問題と、閉じていない <script> タグを多く含む短いコードブロックがあると、公開した artifact のページが閲覧者のブラウザのタブをフリーズさせたりクラッシュさせたりする問題を直した。
• 残りの 17 項目は、プラグインと mod の描画、読み込み、検証の修正や改善。
  • 例として、端末が知らない枠線のスタイルの Box をプラグインが描くと起動時にフリーズや強制終了が起きた問題、プラグインの画面のハンドラーが非同期に例外を投げるとセッションが終わった問題を直し、描画中に失敗した mod の Client はそれだけが失敗して ui.fault を出すようにした。

[A] Anthropic — Claude Code changelog, 2.1.290 (2026-10-05)

https://code.claude.com/docs/en/changelog#2-1-290

• ドキュメントのページはこのエントリを October 5, 2026 の下に載せる。
• エントリは 190 項目で、Added 15、Fixed 131、Improved 19、Changed 25。
  • 接頭辞は [VSCode] が 11、[Claude Tag] が 9、[Cloud sessions] が 4、[Code Review] が 2、[Remote Control] が 1。
• 権限ルール: declare、typeset、export、readonly の接頭辞として設定した変数から名前が来るコマンドやパスを、deny や ask のルールが見逃していた問題を直した。
• 権限ルール: PreToolUse のフックが入力を書き換えた後のツール呼び出しに、一部の権限ルールと安全チェックが適用されていなかった問題を直した。
• Bash のチェック: シェルがまだワイルドカードとして展開する引数を持つ一部の読み取り専用コマンド (rg や git grep など) を自動で承認していた問題を直し、承認を求めるようにした。
• Bash のチェック: zsh と bash で変数名の読み方が違う特定のコマンドを自動で承認していた問題を直し、承認を求めるようにした。
• Bash のチェック: 読み取り専用コマンドの一部のオプションの値に含まれるワイルドカードに、Read の deny ルールや作業ディレクトリ外の読み取りのブロックを適用していなかった問題を直した。
• Bash のチェック: pyright を読み取り専用のコマンドとして扱うのをやめ、実行前に許可を求めるようにした。
• Bash のチェック: より多くの形の ps コマンドが、確認なしで実行される代わりに承認を求めるようにした。
• サンドボックスの自動許可: サンドボックス化された Monitor ツールのコマンドが、サンドボックスの自動許可のもとで許可の確認を飛ばしていた問題を直し、権限ルールに従わせた。
• サンドボックスの除外: git clone のオプションの短い形が、sandbox.excludedCommands の git * のような git のパターンによるサンドボックスの除外を保ってしまう問題を直し、長い形と同じに扱うようにした。
• Linux のサンドボックス: .claude/settings.json や .claude/settings.local.json がないとき、Linux のサンドボックス化された Bash のコマンドが ConfigChange のフックを動かし、コマンドの途中で設定を読み直していた問題を直した。
• サンドボックスの確認: heredoc を別のコマンドにパイプするサンドボックス化されたコマンド (cat <<EOF | python3) が、実行のたびに承認を求めていた問題を直した。
• 読み取りのブロック: 作業ディレクトリの外へのシンボリックリンクになっているプロジェクトの CLAUDE.md、ルール、AGENTS.md が、permissions.blockReadsOutsideWorkingDirectories や Read の deny ルールのもとでも読み込まれていた問題を直した。
• 読み取りのブロック: 読み取りのブロックや --restricted のもとでの @ メンションが、読み取りの途中で変えられたリンクを通じて、作業ディレクトリの外のファイルを読めた問題を直した。
• 途中で差し替えられたリンク: macOS と Windows で、画像の読み取りが、途中で差し替えられたリンクを通じて承認された範囲の外のファイルを返しえた問題を直した。
• Read の deny ルール: プロンプトに貼り付けたりドラッグしたりした画像のパスや、@ メンションしたフォルダーに並ぶファイル名に、Read の deny ルールが適用されていなかった問題を直した。
• 設定ファイル: シンボリックリンクの設定ファイルが指す先のファイルの編集が、設定ファイルについての許可の確認なしに実行されていた問題を直した。
• 封じ込め: macOS と Linux で、バックスラッシュを含むパスに対する plansDirectory の設定のプロジェクトルートのチェックを直した。
• 大規模な読み取りルール: 遅いファイルシステム (とくに WSL 上の Windows のドライブ) で管理設定が多くのパスの読み取りを拒否していると、VS Code の拡張のような SDK のホストのもとで 2.1.285 以降に起動が遅くなったり失敗したりした問題を直した。
• 大規模な読み取りルール: ~/**/.env のようなサンドボックスの読み取りルールが大きなフォルダーを覆うと、Linux と WSL で、最初のリクエストの前と /sandbox の Config タブでフリーズした問題を直した。
• mod と組織: ユーザーが入れた mod が組織のガードに確認を飛ばさせることができたケースを直し、そうした mod は読み込みを解除されるようにした。
• mod と組織: ユーザーが入れた mod が組織のプラグインの読み込みを解除させることができたケースを直し、解除されるのはその mod の側になった。
• 組織の MCP サーバー: 組織が提供する MCP サーバーが、サインインや再接続の後に (ヘッドレスや SDK のセッションで遅れて届く結果からも) 自分のものとして並び直されていた問題を直した。
• 組織の MCP のルール: .mcp.json、プラグイン、エージェントで宣言した一部の MCP のエントリに、disableClaudeAiConnectors と allowedMcpServers の URL のルールが適用されていなかった問題を直した。
• コネクターのポリシー: サーバーから送られた ask のポリシーを持つ、読み取り専用でないコネクターのツールを、plan mode が auto mode の分類器に承認させていた問題を直した。
• URL のルール: xn-- のホストのラベルの中にワイルドカードを持つ URL の allow と deny のパターンが、プロセスごとに違う一致の仕方をしていた問題を直した。
• auto mode: auto mode の拒否が、ツール全体で分類器を飛ばす権限ルールや、Claude Code が無視する権限ルールを提案していた問題を直した。
• 管理設定: 管理設定のファイルが、管理設定のフォルダーの外のファイルへのリンクになっているときの警告を加えた。
• 管理設定: 管理設定が、ユーザーの設定したサンドボックスの allowRead のパスや許可したドメインを無視しているときの、/status と doctor の警告を加えた。
• リポジトリの設定: プロジェクトの設定ファイルで Claude in Chrome をオンにできないようにし、--chrome、/chrome、ユーザー設定を使うよう求めた。
• リポジトリの設定: リポジトリの .claude/settings.json や .claude/settings.local.json では CLAUDE_CODE_DISABLE_ATTACHMENTS を設定できないようにした (シェル、ユーザー、管理の設定ではまだ設定できる)。
• ネットワークの設定: セッションの最初の機能フラグのリクエストが、プロジェクトの設定にあるプロキシや API のエンドポイントを無視していた問題を直した。
• 制限付きのセッション: --restricted (と CLAUDE_CODE_RESTRICTED=1) のセッションが、セッション間のメッセージングのソケットを開いていた問題を直した。
• バイパスのモード: バイパスの権限についての免責事項を受け入れていないのに、バックグラウンドのワーカーが再起動のときに --allow-dangerously-skip-permissions に従っていた問題を直した。
• plan mode: 端末で --continue や --resume <session-id> でセッションを再開したとき、plan mode が戻らなかった問題を直した。
• 許可の中継: --channels の許可の中継で、セッション内で繰り返された返信の ID が別の確認を承認してしまう問題を直し、無視するようにした。
• 許可の確認: 改行を含むファイル名が、ファイルツールのエラーや許可の確認で正しく表示されなかった問題を直した。
• 許可の確認: [VSCode] 開いているダイアログの裏に届いた許可の確認がキーボードのフォーカスを奪い、ダイアログで押したキーがそれに答えてしまう問題を直した。
• スキルとコマンド: タブと改行以外の生の制御文字を含む ! のシェルコマンドを、スキルとカスタムコマンドが拒むようにし、その位置を示すメッセージを出すようにした。
• 端末の出力: claude daemon run と claude daemon logs で、バックグラウンドのデーモンのログが端末の制御文字を画面にそのまま通していた問題を直し、\uXXXX のエスケープで表示するようにした。
• クラウドのセッション: クラウドのセッションの組み込みの gh api が、GH_HOST や GH_REPO に github.com 以外のホストが設定されていると拒むようにし (--hostname か完全な URL を使う)、ほかのホストへのリクエストを stderr に記すようにした。
• アップロード: unset や unspecified という名前の git のフィルタードライバーの下のファイルについて、/ultrareview がコミットしていない変更をフィルターを通さずにアップロードしていた問題を直し、アップロードを止めてドライバーの名前を変えるよう求めるようにした。
• ゲートウェイの通信: マシンの管理設定がゲートウェイのログインを強制していないとき、バックグラウンドのコマンド、エージェントのビュー、デーモンのワーカーが、Claude apps gateway の背後から Anthropic にテレメトリと機能フラグのリクエストを送っていた問題を直した。
• ゲートウェイのサインイン: Claude apps gateway のサインインの承認ページに Deny のボタンを加え、待っているサインインを終わらせて、待機中の端末が数秒で止まるようにした。
• サインイン: macOS で、キーチェーンが新しいログインを拒み、消せない古いログインを残したのに、/login が成功を報告していた問題を直した。
• 通信: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で、起動時の接続のウォームアップも省くようにした。
• 堅牢性: HTTP の MCP サーバーが非常に大きなレスポンスを送ると、メモリの使用量が際限なく増えた問題を直した。
• 堅牢性: MCP サーバーのツールの一覧に結合文字の非常に長い並びがあると、処理が止まった問題を直した。
• 堅牢性: セルフホストのランナーで、細工された非常に長いセッションのエラー出力の行が、ランナーを数秒間フリーズさせた問題を直した。
• 堅牢性: 秘密情報のスキャンや許可の確認が長いトークン風のテキストに出会うとフリーズした問題と、秘密情報のマスクが非常に長い切れ目のないテキストに出会うと数秒フリーズした問題を直した。
• Managed Agents の例: claude-api スキルの Managed Agents の例を、エージェントが必要としない限り Web のツールを切り、auto の権限ポリシーを使うように変えた。
• Claude Tag: アクセスバンドルでカスタムの接続を作るときに任意の Path prefixes の欄を加え、その allow ルールがホスト全体ではなくそのパスだけを対象にできるようにした。
• mod のフック: mod の tool.check のフックが読む質問と判定に、組織がツールに求める承認を示す ceiling を加えた。
• mod のフック: プラグインのフックの tool.check のイベントに agentId を加え、フックがサブエージェントの許可のチェックとメインのセッションのそれを見分けられるようにした。
• mod のフック: mod の turn.step のフックの結果に、API 自身が実行したツール呼び出し (advisor) を、それぞれの id、名前、入力、開始と終了とともに示す serverToolUses を加えた。
• mod のフック: claude plugin validate に、mod がゲートの箇所に登録した各フックを、.catch を持つかどうかとともに一覧する機能を加えた (--json では gatingHooks)。
• mod のフック: .catch を持つプラグインのフックが、プロンプトやツール呼び出しでフックのワーカーを占有し続けたときに、読み込みを解除されて .catch も飛ばされた問題を直した。
• mod のフック: next(e) を呼んだ後でプロンプトを落とす mod の prompt.submit のフックが黙って無視されていた問題を直し、名前を挙げて失敗として報告するようにした。
• mod のフック: 子プロセスが動いた後で別の mod が拒否したとき、mod の $.process.spawn が返す拒否の内容を変え、呼び出しは実行されたがプラグインがその結果を差し止めたと伝えるようにした。
• mod のフック: プラグインのフックで、長いテキストを拒否したり黙って捨てたりする代わりに、切り詰めてログに残すようにした。
• mod のフック: プラグインのフックの型定義に ThemeKey と Color の型を加え、mod の描画で指定できるテーマの色をエディターが一覧できるようにした。
• ゲートウェイでの mod: ゲートウェイ経由 (ANTHROPIC_BASE_URL と ANTHROPIC_AUTH_TOKEN) で Claude を使い、Anthropic のアカウントを持たない人で mod がオフのままだった問題を直した。
• エージェントの識別: プロセス内の teammate の、Agent の結果での agent_id をそのエージェント ID に変え (name@team のアドレスは teammate_id に残る)、そのサブエージェントやフォークからは TeammateIdle のフックが発火しないようにした。
• データの消失: stash を選んだとき、同じ名前の追跡対象のファイルを置き換えていたフォルダーの中のファイルを、claude --teleport と /teleport が消していた問題を直し、stash を断ってその理由を示すようにした。
• データの消失: Windows で git stash create が失敗すると、/ultrareview がコミットしていない変更を警告なしに捨てていた問題を直した。
• バックグラウンドのセッション: claude attach <name> と claude logs <name> を加え、ID の代わりにセッション名の一部を使えるようにした。
• Managed Agents: ページが説明する Managed Agents のパターンを ant apply のファイルとして組み立てる /claude-api managed-agents-onboard <url> を加えた。
• Managed Agents: deep-researcher のような Console のクイックスタートのテンプレートを ant CLI で作る /claude-api managed-agents-onboard <quickstart-name> を加えた。
• WebSearch: 対話セッションの WebSearch の予算を、200 回で打ち切る方式から時間とともに補充される方式 (1 時間に 100 回、CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR で速さを設定し、0 で無効) に変えた。
• WebFetch: WebFetch が 100,000 文字を超えたページのテキストを黙って捨てていた問題を直し、読み残した量を伝えて、続きを読むための offset を受け取るようにした。
• コードレビュー: medium の effort の /code-review が、Opus 5.5 や Sonnet 5.5 を含むレビュー用の設定が調整されていないモデルでも、後片付けと CLAUDE.md の規約についての指摘を報告するようにした。
• 予定されたタスク: 予定された起床 (/loop) を待つバックグラウンドのセッションを、更新やメモリ不足のときにも動かしたままにするようにした (再起動や終了で起床が黙って失われうるため)。
• 予定されたタスク: 会話が圧縮された後に再開すると、予定されたタスク (間隔付きの /loop、リマインダー) が黙って戻らなかった問題を直した (このバージョン以降の圧縮が対象)。
• エージェントのビュー: claude agents から忙しいバックグラウンドのセッションに送った /model、/effort、/rename が、ターンの終わりを待たずに確認なしですぐ適用されるようにした。
• サブエージェント: 実行中にメッセージを受け取った後、再開したサブエージェントと teammate が以前の思考とプロンプトのキャッシュを失っていた問題を直した。
• コンテンツフィルター: Claude がまだ思考している間に API の出力のコンテンツフィルターが応答を止めると、ターンがすぐ終わっていた問題を直し、エラーを示す前に 1 回再試行するようにした。
• ヘッドレスの実行: 構造化出力がすでに届いた後で接続が切れると、ヘッドレスの --json-schema の実行が、success の結果なのに is_error: true で 0 以外の終了コードを返していた問題を直した。
• Claude in Chrome: browser_batch の呼び出しがタイムアウトと報告されるまでの時間を、60 秒から 90 秒に延ばした。
• ゲートウェイ: Claude apps gateway が対応する PostgreSQL の最低バージョンを 14 から 11 に下げた。
• Claude Tag: Slack に fast mode を加え、!fast で Claude をメンションするとスレッドを fast mode に切り替え (必要なら Opus に移す)、!fast off で戻せるようにした。
• Claude Tag: チャンネルの指示の上限をバイトではなく 8,192 文字にして、英語以外のテキストにも同じだけの余地があるようにした。

[A] GitHub — anthropics/claude-code releases v2.1.289 and v2.1.290 (2026-10-03 と 2026-10-05)

https://github.com/anthropics/claude-code/releases

• v2.1.289 のリリースは 2026-10-03T23:07:17Z (日本時間 10 月 4 日 08:07)、v2.1.290 は 2026-10-05T23:33:17Z (日本時間 10 月 6 日 08:33) に公開された。
• リリースの本文は、What's changed の下に、ドキュメントのページと同じ 27 項目と 190 項目を載せる。
• リポジトリの CHANGELOG.md は、それらを ## 2.1.290 と ## 2.1.289 の下に載せる。
• 2 つのエントリがリンクする唯一の issue、anthropics/claude-code#98135 (/chrome の Reconnect でブラウザのツールが登録されない) は、リリースと同時に 2026-10-05T23:32:58Z に閉じられた。

[A] npm — @anthropic-ai/claude-code package metadata (2026-10-06 取得時点)

https://registry.npmjs.org/@anthropic-ai/claude-code

• レジストリは、2.1.289 の公開を 2026-10-03T20:12:02Z (日本時間 10 月 4 日 05:12)、2.1.290 を 2026-10-05T18:12:44Z (日本時間 10 月 6 日 03:12) と記録している。
• dist-tags は、stable が 2.1.285、latest が 2.1.290、next が 2.1.290 だった。
• 2.1.285 は 2026-09-29T17:32:09Z に公開されたので、stable のタグは latest より 5 リリース遅れている。

[A] GitHub — anthropics/claude-code security advisory GHSA-5j29-h97v-84ch, Arbitrary File Write via Write-Time Symlink Following (TOCTOU) in Claude Code (2026-10-05)

https://github.com/anthropics/claude-code/security/advisories/GHSA-5j29-h97v-84ch

• 2026-10-05T12:45:33Z に公開され、深刻度は high、CVE-2026-103435、CVSS v4 のスコアは 7.7。
• 弱点は CWE-22 (パストラバーサル)、CWE-61 (シンボリックリンクの追従)、CWE-367 (チェックと使用の時間差による競合)。
• 影響を受けるのは < 2.1.129 で、修正版は 2.1.129。
• Claude Code は、許可のチェックの時点では対象のファイルのパスがプロジェクトの作業ディレクトリの中にあることを確かめていたが、書き込みの時点でその確認を繰り返さずにパスを解決し直していた。
• ワークスペースに書き込める攻撃者は、プロジェクトのファイルをシンボリックリンクにアトミックに置き換えて、Claude Code にプロジェクトのサンドボックスの外の任意のファイルへ書き込ませることができた。
• 悪用には、書き込みの操作との競合に勝つことと、共有されたワークスペースへの書き込み権限が必要だった。
• 標準の自動更新を使うユーザーには、この修正がすでに届いているとする。
• 謝辞として hackerone.com/c_h4ck_0 を挙げる。
• 2026-10-03 から 2026-10-06 の間に公開されたこのリポジトリの唯一のアドバイザリで、2.1.289 や 2.1.290 を挙げるアドバイザリはない (2026-10-06 取得時点)。

[A] GitHub — anthropics/claude-code commit history of mods/sec-default (2026-10-06 取得時点)

https://github.com/anthropics/claude-code/commits/main/mods/sec-default

• 組み込みのガードの公開のソースが最後に変わったのは 2026-09-29 で、2 つのリリースより前。
• 最後の 3 つのコミットは、システムプロンプトの節がユーザーの層の後も続くようにしたもの (#97241)、設定の deny ルールが本人の入れたプラグインからの allow や ask より優先されるようにしたもの (#98080)、管理設定のオプション allowManagedModsOnly で本人の入れた mod を読み込ませないようにしたもの (#98083)。

[A] Claude Code Docs — Configure permissions (2026-10-06 取得時点)

https://code.claude.com/docs/en/permissions

• deny と ask のルールは、サブシェル、コマンド置換、for ループのような制御構文の本体に入れ子になったコマンドを含め、どれかのサブコマンドが一致すれば適用される。
• Claude Code は既知の安全な環境変数の先頭の代入を取り除くので、Bash(npm test *) は NODE_ENV=test npm test に一致するが、それ以外の変数の代入を越えて allow ルールが一致することはない。
• deny や ask のルールはどの先頭の代入も越えて一致するので、deny の Bash(rm *) は FOO=bar rm -rf tmp/ にも一致する。
• Bash のルールが覆うのは Claude がふだん生成する呼び出しで、プログラムを囲むセキュリティの境界ではないとする。
• ページの表によれば、Bash(curl *) は /usr/bin/curl https://example.com や sh -c 'curl https://example.com' を止めず、Bash(rm *) は /bin/rm -rf build/ や bash -c 'rm -rf build/' を止めず、Bash(git push *) は git -C . push origin main を止めない。
• コマンドのテキストに依存しないファイルシステムとネットワークの強制には、サンドボックスを使うよう勧める。
• Read と Edit の deny ルールは、組み込みのファイルツール、Bash の中で Claude Code が認識するファイルのコマンド (cat、head、tail、sed、tee)、リダイレクトの対象に適用される。
  • そのファイルを含むディレクトリから実行した grep -r pattern . や、自分でファイルを開く Python や Node のスクリプトのように間接的にファイルを読み書きする任意のサブプロセスには適用されない。
• Claude は、Read のルールを Grep と Glob、@file のメンション、接続した IDE が共有する選択範囲と開いているファイルの文脈にも、ベストエフォートで適用しようとする。
• シンボリックリンク越しでは、deny ルールは要求されたパスか解決先のファイルのどちらかが一致すれば適用され、allow ルールは両方が一致したときだけ適用される。
• ツールが承認されたファイルを開くときには、そのパスが許可のチェックで承認された場所にまだ解決されることを確かめる。
• 組み込みの読み取り専用コマンドの集合 (ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd、読み取り専用の git) は、どのモードでも確認なしで動き、設定では変えられない。
• .claude/settings.local.json は、git で追跡されているときや .claude がシンボリックリンクのとき、リポジトリが供給したものとして扱われる。

[A] Claude Code Docs — Configure the sandboxed Bash tool (2026-10-06 取得時点)

https://code.claude.com/docs/en/sandboxing

• 自動許可のモードでは、コマンドがサンドボックスの中で動くとき、Claude Code は確認なしで自動的にそれを承認する。
• 自動許可のモードでも、明示的な deny ルールは常に守られるとする。
• 重要なパスを対象にした rm や rmdir のコマンドは、それでも通常の許可の流れを通る。
• Bash(git push *) のような内容を指定した ask ルールは、サンドボックス化されたコマンドでも確認を強いるが、素の Bash の ask ルールは、plan mode の外ではサンドボックス化されたコマンドについて飛ばされる。
• 自動許可は権限モードとは独立に働くので、サンドボックスの境界の中でファイルを変える Bash のコマンドは、ファイル編集のツールなら確認が出る Manual モードでも実行される。

[A] Claude Code Docs — All settings (2026-10-06 取得時点)

https://code.claude.com/docs/en/settings-reference

• permissions.blockReadsOutsideWorkingDirectories は、bypassPermissions を含むすべての権限モードで Claude のファイルツールに作業ディレクトリの外の読み取りを拒ませ、Read、Grep、Glob、LSP の呼び出しを拒否するもので、v2.1.257 以降が要る。
• どのファイルでも設定でき、リポジトリはこのブロックを自分のためにオンにはできるが、ユーザーのブロックを外すことはできない。
• --add-dir、/add-dir、ユーザーか管理の設定の additionalDirectories で加えたディレクトリは、ブロックの上では作業ディレクトリとして数える。
  • .claude/settings.json だけで加えたものは数えず、.claude/settings.local.json のものも、git がそのファイルを未追跡と報告しない限り数えない。
• git リポジトリでないディレクトリや、git がそのファイルを追跡しているときは、Claude Code は .claude/settings.local.json をリポジトリの設定として扱うので、読めるままにしたいディレクトリはユーザー設定に書くよう勧める。
• サンドボックスがオンのとき、このブロックはサンドボックス化されたコマンドから、ホームディレクトリと /Users、/home、/root、/Volumes、/mnt、/media、/run/media、/srv の読み取りを取り上げ、そのうえで作業ディレクトリ、worktree、セッションの一時ディレクトリ、コマンドが必要とする ~/.claude の一部を開き直す。
• ブロックが効いている間は、リポジトリの設定の allowRead と allowWrite のエントリは数えない。
• ディレクトリを 2 回以上移動したりサブシェルを動かしたりするような、シェルのパーサーが追えない Bash のコマンドは、サンドボックスがブロックを強制していない限り、auto mode や bypassPermissions のモードでも確認を求める。
• どのファイルでも設定できる plansDirectory は、パスをプロジェクトのルートからの相対で解決し、その外に解決されるときは既定のままにし、既定は ~/.claude/plans。
• sandbox.autoAllowBashIfSandboxed の既定は true で、どのファイルでも設定でき、deny ルールと Bash(git push *) のような内容を指定した ask ルールは効いたままにする。
• autoUpdatesChannel の "stable" は、通常約 1 週間前のもので大きな後退のあるリリースを飛ばしたバージョンに従い、未設定なら "latest"。
• Homebrew での導入はこのキーを無視し、claude-code の cask は stable を、claude-code@latest は latest を追う。
• 管理設定専用のキー requiredMinimumVersion (v2.1.163 以降が要る) は、動いているバージョンが組織の許すものより古いと、起動時に Claude Code を終了させる。

[A] Claude Code Docs — Choose a permission mode (2026-10-06 取得時点)

https://code.claude.com/docs/en/permission-modes

• どのモードも自動では承認しない操作の 1 つとして、読み取りのブロックがオンの間は、認識されたファイルを読む Bash のコマンドが auto mode や bypassPermissions のモードでも確認を求め、サンドボックスの外での実行に承認が要るサンドボックス外の再試行も同様だとする。
• コマンドがサンドボックスの中で動き、サンドボックスがブロックを強制しているときは、この確認はかからない。
• ブロックがオフなら、auto mode で作業ディレクトリの外への最初の Read、Grep、Glob の呼び出しは、-p の実行とバックグラウンドのセッションを除いて、許可するかを尋ねる。
  • そこで選択肢 No, and block reads outside the working directories from now on を選ぶと、ユーザー設定でブロックが true になる。
• ページの構成の表は、Manual モードと自動許可のモードのサンドボックスの組み合わせを、分類器なしで確認を減らす構成とし、deny ルールは引き続き適用されると注記する。

[A] Claude Code Docs — Hooks reference (2026-10-06 取得時点)

https://code.claude.com/docs/en/hooks

• PreToolUse のフックの updatedInput はツールの入力を置き換え、Claude Code は権限ルールと Bash のコマンドの自動バックグラウンド化の可否を、Claude が送った入力ではなく、フックが返した入力に対して評価する。
• permissionDecision については、フックが何を返しても deny と ask のルールは評価されるとする。

[A] Claude Code Docs — Manage mods for your organization (2026-10-06 取得時点)

https://code.claude.com/docs/en/plugins/mods/admin

• 組み込みのガード sec-default@builtin は、マシンに管理設定があるか、ユーザーが Team か Enterprise のプランでサインインしているとき、ユーザーが入れたすべての mod より先に読み込まれる。
  • API キーで認証するユーザーや、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry 経由のユーザーは、管理設定のあるマシンでだけガードを得る。
• ユーザーの mod は、管理フックが受け取るものや決めること、システムプロンプト、管理された CLAUDE.md などの管理された指示、mod が設定として読むもの、管理された MCP サーバーのツールと説明文を変えられない。
• ガードが読み込まれる環境では、どの設定ファイルにルールがあっても、deny ルールが拒む呼び出しをユーザーの mod が承認することはできない。
• ツール呼び出しを承認するユーザーの mod は、ask ルールなら確認が出る呼び出しや、管理設定の外の PreToolUse のフックがブロックした呼び出しを承認できる。
• auto mode では、mod が承認した呼び出しは分類器のチェックなしで動く。
• Read(.env) を拒否していても、mod は $.fs.read でそのファイルを読めるし、それを読むプログラムを起動することもできる。
• ガードは安全側に倒れる (fail closed) 設計で、管理設定を読めなければユーザーのすべての mod を拒み、ユーザーの mod が承認した呼び出しについて deny ルールを確かめられなければ、その呼び出しを拒む。
• allowModsToOverrideDenyRules を使うと、deny ルールが拒む呼び出しをユーザーの mod が承認できる。

[A] Claude Code Docs — Mods reference (2026-10-06 取得時点)

https://code.claude.com/docs/en/plugins/mods/reference

• リファレンスが対象とするのは v2.1.289 時点の Claude Code の CLI と Desktop アプリで、ceiling の欄も、tool.check の agentId も、serverToolUses も、gatingHooks も載っていない。
• tool.check は tool.call と PreToolUse のフックの後に発火し、next(e) はルール、権限モード、それらのフックが至った判断に解決され、フックは allow、ask、deny のいずれかの { decision } を返す。
• agent.spawn はサブエージェントかエージェントチームの teammate が起動する直前に発火し、teammate なら e.isTeammate が true になり、フックはモデルを選んだり { deny: reason } を返したりできる。
• ui.fault には Claude Code v2.1.289 以降が要る。
• .catch のハンドラーの実行時間の上限は 1 秒。

[A] Claude Code Docs — React to events with a mod (2026-10-06 取得時点)

https://code.claude.com/docs/en/plugins/mods/events

• .catch のハンドラーのないフックが、next を呼ぶ前に例外を投げたり、タイムアウトしたり、違う形を返したりすると、そのフックは飛ばされ、次のハンドラーが代わりに動く。
• 呼び出しをブロックするフックを安全側に倒すには、代わりに答える .catch のエラーハンドラーを加えるよう求める。
• ハンドラーがなければ、Claude Code は guard を飛ばしてコマンドを実行してしまうと説明する。

[A] Claude Code Docs — CLI reference (2026-10-06 取得時点)

https://code.claude.com/docs/en/cli-reference

• claude attach <id|name> はバックグラウンドのセッションにつなぎ、claude logs <id|name> はその最近の出力を表示し、動いているセッションの名前の一部を渡すには Claude Code v2.1.290 以降が要る。
• --restricted (v2.1.248 以降) は、評価のハーネスが共有のマシンで claude を動かすときのためのもので、コマンドを実行するツールと WebFetch を外し、ファイルツールを作業ディレクトリに閉じ込め、管理設定と --settings だけを読み込み、bypassPermissions を拒む。

[A] Claude Code Docs — Tools reference (2026-10-06 取得時点)

https://code.claude.com/docs/en/tools-reference

• ページにはまだ、1 つのセッションで WebSearch を呼べるのは最大 200 回 (メインの会話とそのサブエージェントを通して数え、上限は CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION で設定、v2.1.212 以降) と書かれている。
• WebFetch についてもまだ、大きなページは処理の前に決まった文字数で切り詰めると書かれている。

[A] Claude Code Docs — Environment variables (2026-10-06 取得時点)

https://code.claude.com/docs/en/env-vars

• CLAUDE_CODE_DISABLE_ATTACHMENTS を 1 にすると添付の処理が無効になり、@ のファイルのメンションはファイルの内容に展開されずにプレーンテキストとして送られる。
• ページに CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR は載っていない。
• .claude/settings.json の env の変数は、ソース管理にチェックインされ、プロジェクトで作業する全員に適用される。

[A] Claude Code Docs — Connect Claude Code to tools via MCP (2026-10-06 取得時点)

https://code.claude.com/docs/en/mcp

• 組織は claude.ai のコネクターにツールごとの制御を設定でき、Claude Code は起動時にそれを読んでローカルで強制する。
• ask に設定されたツールは、acceptEdits、auto、bypassPermissions のモードでも、呼び出しのたびに Your organization requires approval for this tool という理由で確認を求める。
  • allow ルールもこの確認を飛ばせず、dontAsk のモードでは代わりに呼び出しを拒否する。
• blocked に設定されたツールは、Claude に見える前に取り除かれる。

[B] MIXED — Claude Code 2.1.289 closes a second route past its rm guard, and stable is four builds behind, by Shane S. Ellison (2026-10-05)

https://mixed-news.com/en/claude-code-2-1-289-second-route-past-rm-guard-stable-four-builds-behind/

• Claude Code 2.1.289 は 10 月 3 日 20:12 UTC に npm に届き、削除のコマンドが、それを止めるはずの許可のチェックをすり抜ける 2 つ目の経路をふさいだと書く。
• stable のチャンネルから入れる人には、その修正が届いていないと指摘する。
• 10 月 4 日 23:58 UTC の時点で、dist-tags は stable を 2.1.285 に向け、latest と next はどちらも 4 リリース先の 2.1.289 にあったとする。
• Anthropic はサンドボックスの 2 つの修正のどちらも脆弱性とは呼んでいないとする。
  • CVE も深刻度の評価もなく、Anthropic 自身のリポジトリの changelog にも、この経路が誰かに対して使われたことを示すものはないとする。
• Bash の 2 つの修正はどちらもサンドボックスの自動許可のもとでだけ当てはまり、サンドボックスの関わらない既定の導入はどちらも対象にしていないとする。
• deny や ask のルールは行の先頭にあると想定したコマンドに一致し、その前に環境変数の代入があると、シェルに先に読むものを与えてしまうと仕組みを説明する。
• この修正を、bash -c のラッパーで危険な rm が通り抜けた 2.1.288 と結びつけ、管理対象のマシンでの入れ子の複合コマンドの修正を 3 つ目のシェルの修正と数える。
• MCP の修正については、説明文は飾りではなく指示だとし、Anthropic はユーザーの入れたプラグインがその文章を変えられたとだけ述べ、実際に変えたプラグインがあったかは述べていないと指摘する。
• リリースの 27 の修正のうち 5 つが権限かサンドボックスの作業だとする。
• 2.1.285 から 2.1.289 までの npm の公開時刻 (9 月 29 日 17:32 UTC から 10 月 3 日 20:12 UTC) を並べ、Anthropic はビルドを昇格させる予定を公開していないので、その差はレジストリでしか見えないとする。
• それは欠陥ではなくリリースチャンネルについての選択であり、保守的な stable のタグこそがそれを持つ普通の理由だと付け加える。

[B] Classmethod (DevelopersIO) — Claude Code v2.1.289 の主要アップデート - sandbox auto-allow 時の Bash deny ルール修正と agent.spawn の teammate 対応 (石川覚、2026-10-05)

https://dev.classmethod.jp/articles/20261005-cc-updates-v2-1-289/

• v2.1.289 を「2026-10-03 公開」とし、「27 件の変更が入りました」として、「内訳は新機能 1 件、セキュリティ修正 5 件、不具合修正 19 件、改善 2 件です」と数える。
• 「不具合修正 19 件のうち 15 件は mods とプラグインに関するもので、セキュリティ修正 5 件はいずれも権限ルールまたは組織管理の設定に関わります」とする。
• Mods reference を引き、agent.spawn は「subagent または teammate が起動する直前に発火するイベント」で、「hook からモデルを指定したり、起動を拒否したりできます」と説明し、teammate の場合は e.isTeammate が true になるとする。
• sandbox のページの「auto-allow モードでも明示的な deny ルールは常に適用される」という説明を挙げ、自動許可の 2 件の修正を「この説明どおりに動いていなかったケースの修正です」と位置づける。
• 「sandbox の auto-allow を有効にしたうえで deny ルールで特定のコマンドを止めている方は、早めにアップデートしておくのがよいと考えます」と勧める。
  • 管理対象のマシンの 2 件については、「managed settings を配備しつつユーザーの mod を許可している組織の管理者は、この 2 件が修正された点を把握しておくとよいと感じます」とする。
• シンボリックリンクの修正は「.env などを Read の deny ルールで保護していて、シンボリックリンクや IDE 連携を多用している方に関係する修正」だとする。
• 検証の準備として、.claude/ ディレクトリや git リポジトリを含まない新しいディレクトリ ~/cc-handson-sandbox-deny を作り、"deny": ["Bash(touch *)"] と "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true, "failIfUnavailable": true } を持つ settings.json を置く。
  • failIfUnavailable は「sandbox を起動できない場合にサンドボックスなしでコマンドが実行されるのを防ぐ設定」だと説明する。
• 検証のコマンドは claude -p --max-turns 1 --output-format json --setting-sources project --settings ./settings.json で、プロンプトは Run exactly this Bash command: TZ="$HOME" touch denied.txt。
  • --setting-sources project で、ユーザー設定 (~/.claude/settings.json) を読み込まないようにしている。
• 対照として、同じ sandbox の内容で permissions を除いた settings-control.json を作り、TZ="$HOME" touch allowed.txt を実行させた。
• deny ルールありでは permission_denials に、TZ=\"$HOME\" touch denied.txt のコマンドを持つ Bash のエントリが 1 つ記録され、denied.txt は作られなかった。
• 対照では permission_denials が [] で、allowed.txt が作られた。
• どちらも subtype が error_max_turns、terminal_reason が max_turns で終わり、筆者はその理由を「--max-turns 1 の上限に達して終了したため」とする。
• 結論として「環境変数プレフィックスを付けたコマンドでも deny ルールで止まることを、対照実験とあわせて確認できました」と書き、「auto-allow による実行と deny ルールによる制限を両立しやすくなったと感じます」とする。

[B] Classmethod (DevelopersIO) — Claude Code の blockReadsOutsideWorkingDirectories で作業ディレクトリ外の読み取りを拒否してみた (佐藤雅樹、2026-10-03)

https://dev.classmethod.jp/articles/claude-code-block-reads-outside-working-directories/

• この設定は v2.1.257 (2026-09-01) で加わったもので、「作業ディレクトリ外のファイル読み取りを、権限モードによらず拒否する設定です」と説明する。
• 「記事執筆時点の最新バージョンのClaude Code 2.1.287で検証しました」とし、権限モードは auto で試した。
• Read ツールは、未設定なら読め、true なら「読めない（承認の余地なし）」だった。
• sandbox 無効の Bash は、未設定なら読め、true なら Reads outside the working directories are blocked (permissions.blockReadsOutsideWorkingDirectories) で始まる確認プロンプトが出て、Yes を選ぶと cat が実行された。
• sandbox 有効で allowUnsandboxedCommands: false の Bash は、未設定なら読め (「sandbox は書き込みを作業ディレクトリ配下などに絞りますが、既定では読み取りを制限しません」)、true なら確認プロンプトなしに Operation not permitted で OS が拒否した。
• Read ツールは「権限モード auto , plan , manual , accept edits どれで試しても同じく拒否されました」とし、bypassPermissions は筆者の環境では検証できなかった。
• ブロックのもとで、~/.claude/CLAUDE.md は読めたが、~/.claude/settings.json は拒否された。
• /add-dir の確認画面の選択肢は Yes, for this session、Yes, and remember this directory、No の 3 つで、2 つ目は local 設定の .claude/settings.local.json に additionalDirectories を保存する。
• 作業ディレクトリ外のディレクトリを Read ツールと sandbox 有効の Bash の両方に開いたのは、/add-dir と user 設定の additionalDirectories で、user 設定の sandbox.filesystem.allowRead は sandbox 有効の Bash だけに開いた。
• 何も開かなかったのは、local 設定の additionalDirectories と local 設定の sandbox.filesystem.allowRead。
• local 設定の additionalDirectories は、git が settings.local.json を ignored と判定している間は反映されず、筆者がファイルを未追跡 (??) にした後も、Read ツールには反映されなかった。
  • 筆者は「ドキュメントの記載では untracked なら作業ディレクトリとして扱われますが、手元では local 設定の additionalDirectories は反映されませんでした」と書く。
• local 設定の sandbox.filesystem.allowRead は、ignored でも untracked でも、絶対パスで書いても Operation not permitted で拒否され、project 設定の allowRead も拒否された。
  • 筆者は「今回の検証では、local 設定が反映されなかった理由をドキュメントから説明できていません」とする。
• 結論は「Read ツールの読み取りを止めるだけなら、true にするだけで済みました」「Bash も止めたい場合は sandbox の併用が必要です」で、読ませたいディレクトリは「今回の検証で確実に反映された user 設定に書く形が良さそうです」とする。

[C] GitHub — anthropics/claude-code issue #92582, permissions.blockReadsOutsideWorkingDirectories ignores additionalDirectories from project and local settings (2026-09-07)

https://github.com/anthropics/claude-code/issues/92582

• 2026-09-07 に macOS の Claude Code 2.1.263 について開かれ、bug、has repro、area:permissions のラベルが付き、2026-10-06 の時点でまだ開いている。
• ユーザー設定の additionalDirectories に A と B、プロジェクト設定の additionalDirectories に C と D を置くと、セッションのヘッダーには 4 つすべてが並んだが、Read、Grep、Glob は C と D の下のファイルを拒否した。
• サンドボックスの読み取りの許可リストには作業ディレクトリ、A、B しかなく、C の下での cat は Operation not permitted で失敗したが、/add-dir C は効いた。
• 報告者は、プロジェクトのファイルが git で追跡されている場合も、未追跡の .claude/settings.local.json の場合も同じだったとする。
• 影響として、/add-dir には対話セッションが要るため、読み取りの柵 (read fence) が有効な間は、無人の定期実行のセッションがプロジェクトで宣言した追加のディレクトリをまったく使えないと述べる。
• 2026-10-05 のコメントは、Windows 11 の CLI 2.1.278 と VS Code の拡張 2.1.289 でも同じだったと報告する。

[C] GitHub — anthropics/claude-code issue #31558, Claude can bypass "no nesting" rule and/or deny permissions via env variable prefix (2026-03-06、背景)

https://github.com/anthropics/claude-code/issues/31558

• macOS の 2.1.70 について報告され、ラベルは bug、has repro、area:security、area:permissions。
• 再現の手順は、deny でコマンドをブロックし、環境変数の接頭辞で回避できると Claude に伝えて、禁止した操作ができてしまうのを確かめるというもの。
• ボットが重複の可能性のある 3 件 (#23924、#18613、#16180) を挙げ、issue は同じ日に閉じられた。

[C] GitHub — astrosteveo/claude-plugins issue #97, Use what Claude Code 2.1.290 added for plugins (2026-10-06)

https://github.com/astrosteveo/claude-plugins/issues/97

• プラグインの作者のエピックで、2026-10-05 に 2.1.290 の changelog を見直した結果として 2026-10-06T00:19:11Z に開かれ、作者のプラグインが使える 4 つの変更を挙げる。
• 提案の順は、例外を投げたフックにはもう代替がないとして各ゲートのフックに .catch を付けること、tool.check のフックで ceiling を尊重すること、エピックを閉じるガードで agentId を使うこと、テーマの色の型を使うこと。
• エピックは、すべての子 issue を終えて閉じられた。

[C] Arrange Act Assert — Claude Code sandbox: close the gaps before you auto-allow (2026-06-30、背景)

https://arrangeactassert.com/posts/claude-code-sandbox-close-the-gaps-before-you-auto-allow/

• サンドボックスは境界であって、信頼を与えるボタンではないとする。
• サンドボックスは既定で書き込みをよく制限するが、読み取りは同じようには制限しないとする。
• Read(./.env) のような permissions のルールは Claude 自身の Read ツールを止めるが、postinstall のスクリプトの中のサンドボックス化された cat .env には何もしない。
  • Bash を止めるのは filesystem.denyRead のエントリだけで、それはコマンドが何であれ OS が強制するからだとする。
• 日々の開発向けの設定は、autoAllowBashIfSandboxed をオンにしたまま、allowRead: ["."] とともに ~/、./.env、./.env.*、./secrets の読み取りを拒否し、Bash(git push *)、Bash(npm publish *)、Bash(pnpm publish *) を ask ルールに残す。
• だから、確認に疲れたという理由で自動許可をオンにしてはいけないと結ぶ。

メモ

• 日付について、changelog のページは 2.1.289 を 10 月 3 日、2.1.290 を 10 月 5 日としているが、npm での公開は日本時間の 10 月 4 日 05:12 と 10 月 6 日 03:12 で、フィード項目が 10-04 と 10-06 を示すのはこのため。
• 2.1.289 と 2.1.290 のどの修正にも CVE やアドバイザリはなく、MIXED は Anthropic がサンドボックスの修正を脆弱性と呼んでいないと指摘する。
  • 期間中に公開された唯一のアドバイザリ GHSA-5j29-h97v-84ch は、読み取りの途中でのリンクの修正と同じ系統の、書き込み時のシンボリックリンクの競合だが、2.1.129 で直っており、背景にあたる。
• stable の dist-tag は 2026-10-06 にもまだ 2.1.285 を指していたので、stable のチャンネル (Homebrew の claude-code の cask が追うもの) に従うマシンには、これらの修正がどれも入っていない。
  • 2.1.289 以降がいつ stable に届くかは告知されていない。
• 数え方が違う: 2.1.289 のエントリは Fixed 23、Added 1、Improved 2、Reverted 1 で、クラスメソッドはセキュリティ修正 5 件を含む 27 件の変更と数え、MIXED はリリースの 27 の修正のうち 5 つと書く。
• MIXED は 2.1.289 を、2.1.288 の bash -c の修正に続く、rm のガードをすり抜ける 2 つ目の経路の修正と位置づける。
  • しかし 2.1.289 の項目はサンドボックスの自動許可のもとでユーザーが設定した deny と ask のルールについてのもので、rm -rf build は例にすぎず、2.1.288 の項目は危険な rm (/ やホームディレクトリが対象のものなど) を止める組み込みの安全策についてのものだった。
• セキュリティの項目の多くは、ドキュメントがすでに約束していた振る舞いを取り戻すもの: 自動許可でも常に守られる deny ルール、どの先頭の代入も越えて一致する deny と ask のルール、PreToolUse のフックの updatedInput に対して評価される権限ルール、ガードが読み込まれる環境でユーザーの mod より優先される deny ルール。
  • 同じ権限のページは、Bash のルールはプログラムを囲むセキュリティの境界ではないとし、強制にはサンドボックスを勧めているので、これらの修正は OS の層を置き換えるものではなく、テキストの一致の層の隙間を狭めるもの。
• 未解決の問い: 2.1.289 の項目は、管理対象のマシンでは入れ子の deny や ask のルールがユーザーの入れた mod の承認より優先されるべきだとするが、mod の管理のページ (10-06 取得時点) は、ユーザーの mod が ask ルールなら確認が出る呼び出しを承認できるとしている。
• クラスメソッドの deny ルールの検証は 2.1.289 で対照とともに行っただけで、2.1.288 でコマンドが通ることは示していないので、修正前の振る舞いは changelog に拠っている。
• クラスメソッドの読み取りのブロックの検証は両方のリリースより前の 2.1.287 で行われたので、シンボリックリンクと読み取りの途中での修正は対象外。
  • 未追跡の .claude/settings.local.json がディレクトリを加えなかったという結果は設定のリファレンスと食い違い、どちらのリリースも触れていない未解決の issue #92582 と一致する。
  • sandbox.filesystem.allowRead について、ドキュメントはブロックのもとでリポジトリの設定のエントリは数えないとするが、未追跡の local のファイルをリポジトリの設定として数えるかどうかは書いていない。
• ドキュメントはリリースに追いついていない: Mods reference は v2.1.289 時点のもので ceiling、tool.check の agentId、serverToolUses、gatingHooks がなく、Tools と Environment variables のページはまだ 200 回の WebSearch の上限を説明し、CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR を載せていない。
  • changelog が変えたのは対話セッションの予算だけなので、CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION が非対話のセッションをまだ制限するのかは書かれていない。
• ceiling の意味は文書化されていない。
  • 最も近い文書化された組織の統制は claude.ai のコネクターのツールごとの ask や blocked の設定で、2.1.287 は __proto__ という名前の MCP ツールでの組織のツールごとの権限の上限 (organization per-tool permission ceilings) を直していた (両者の関係は未確認)。
• changelog は Claude in Chrome と CLAUDE_CODE_DISABLE_ATTACHMENTS をリポジトリの制御から外した理由を示しておらず、ドキュメントはこの変数を @ のメンションをプレーンテキストで送るものとしか定義していない。
• 2.1.289 と 2.1.290 でのガードの修正は、最後のコミットが 2026-09-29 の公開の mods/sec-default のソースからは読み取れない。
• プラグインの作者の、例外を投げたフックにはもう代替がないという書き方は、ドキュメントと違う。
  • next の前に失敗したフックは飛ばされて次のハンドラーが動くので、.catch のないガードは安全側ではなく素通りの側に倒れる (fail open)。
• このノートは、2.1.290 の 190 項目のうち 56 項目をセキュリティに関わるもの (権限ルールと Bash のチェック、読み取りのブロックとリンク、サンドボックス、組織とリポジトリの設定、mod のガード、細工した入力への堅牢化)、6 項目を境界的なもの (読み取りルールの性能、データの消失、エージェントの識別) と数えたが、この分類はこのノートによるもので Anthropic によるものではない。
  • 2.1.289 では、クラスメソッドの数え方と同じく、27 項目のうち 5 項目がセキュリティの修正。
• ここに WebFetch や検索結果だけに拠る事実はない。

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

• サンドボックスの自動許可を deny ルールとともに使っているマシン、読み取りのブロックを使っているマシン、ユーザーの mod を許す管理設定のマシンが 2.1.290 以降になっていることを確かめる。
  • 組織は管理設定のキー requiredMinimumVersion で下限を強制でき、stable のチャンネルの遅れを受け入れるかどうかを決められる。
• クラスメソッドの claude -p --max-turns 1 --output-format json --setting-sources project --settings の仕組みを回帰テストにする: コマンドの形 (TZ="$HOME" のような展開される接頭辞、コマンドの前の単独の代入、declare と export の接頭辞、bash -c のラッパー) とサンドボックスの自動許可のオンとオフを掛け合わせ、2.1.285 と 2.1.290 で permission_denials を読む。
  • stable のチャンネルがまだどの形を通すかがわかり、アップグレードのたびに後退を捕まえられる。
• クラスメソッドの読み取りのブロックの表を、2.1.290 で直ったケース (外へのシンボリックリンクになったプロジェクトの CLAUDE.md や AGENTS.md、リンク越しの @ メンションや画像のパス、@ メンションしたフォルダーのファイルの一覧) と issue #92582 の未追跡の settings.local.json のケースを加えて 2.1.290 で取り直し、管理設定がユーザーの allowRead のパスを無視するときの新しい /status の警告も確かめる。
• mod を書くチームは claude plugin validate --json を走らせて gatingHooks で .catch のないガードを探し、リファレンスに載った時点で tool.check のガードが ceiling と agentId を読むようにする。
• 2.1.290 がもう従わない設定 (プロジェクトの設定で Claude in Chrome をオンにするもの、.claude/settings.json の CLAUDE_CODE_DISABLE_ATTACHMENTS) と、sandbox.excludedCommands の git のパターンがないか、リポジトリを監査する。
• アウトプットとして、どの層が何を止めるか (ドキュメント自身が挙げる見逃す形の一覧を含む Bash のルールのテキストの一致、読み取りのブロック、サンドボックスの denyRead と allowRead) を、2.1.289 と 2.1.290 の修正と、確実にディレクトリを開いたのはユーザー設定だけだったというクラスメソッドの結果を例に、短いチーム向けの文書にまとめる。

5. 🔁 mizchi が自分の AI プログラミングの手法を棚卸しし、メモリ使用量、lint の警告数、ミューテーションテストの Kill 率のような数値の指標に向けて /goal でループを回すこと、読む時間のないコードを理解するための解説スキル、テストオラクルとしての形式手法 (TLA+、Z3、Alloy) をまとめた

• 選定 / 影響度 1 / 将来性 1 / 重要度 2 / 起点 10-05 / 種別: 検証・実践 / 領域: コーディングエージェント、評価・運用。
• 候補になったフィード項目:
  • hatena-ai-agent 10-05 俺のAIプログラミング手法(2026/10/05)
  • zenn-trending 10-05 同じ記事
  • hatena-llm 10-05 同じ記事

収集した情報

[A] mizchi (Zenn) — 俺のAIプログラミング手法(2026/10/05) (2026-10-05)

https://zenn.dev/mizchi/articles/ai-coding-loop-formal

• Zenn API によれば、2026-10-05 の 13:59 JST に公開され、同じ日の 15:38 JST に最後に更新されており、Zenn のトピックは AI、testing、Claude Code、formalmethods。
• 2026-10-06 の 10:17 JST の時点で、Zenn でのいいねは 379、ブックマークは 155、コメントはなかった。
• 筆者は「棚卸し的な記事です」と書き、最後を「またすぐ変わると思います」で結ぶ。
• 人間の役割の 1 つ目は「モデルの性能を評価する」ことで、「無茶振りしてどこまで出来るか観察」し、「何ができて、何ができなかったことがドメイン知識になる」とする。
• 2 つ目は「ループを構築する」ことで、「自動化して得られた時間で、評価指標を改善する」とする。
• 3 つ目は「評価指標を作る」ことで、「どの数値を改善すべきか、トレードオフは何を優先すべきか」を決める。
• 4 つ目は「ループのイテレーションを評価する」ことで、説明の文は「AI の行動ログを観察して、評価指標を正しく終えているか、」と途中で切れている。
• 5 つ目は「テストとCIをチューニングする(その優先度を与える)」ことで、「評価指標が増えると、そのためのCIが長くなる」ため、「何を優先して、何をやらないかを明確にする」とする。
• 考える順番は「これはAIに任せられる仕事か」から始まり、任せられない場合は「そのブロッカーは何か」を問う。
• 次に「この仕事の完了の定義・評価指標は何か」を考え、「数値化できるものならAIで自動化できる」とする。
• それから「AIに指示して、一度やらせてみる」とし、「まずやらせて、どういう振る舞いをするかを観察する」。
• できたときは「このワークフローは自動化できるか？」を問い、「人間がつきっきりではなく、判断基準自体を作れるか」を考える。
• できなかったときは理由を問い、「コンテキストの不足なら、その指示や守るべきテストを追加」「権限の不足なら、それを与えられるか検討」「性能の不足(半年寝て待つ)」と分ける。
• 「プロンプトは高速に陳腐化する」とし、「あなたは優秀なプログラマです」や「問題に取り組む前に、ゆっくり深呼吸してください」(記事は、これで数学の性能が 7 ポイント改善していたとする) を挙げて、「これらはもう古い」と書く。
• 「グローバルプロンプトは、選択肢が複数あるときの判断基準を書く」とし、例として「node は 24+ を使う」「既存のプロジェクトの設計は尊重しつつ、新規には npm ではなく、pnpm を使う」「nix を使う/使わない」「Rust は stable の 1.99 を使う」「gh stack を使う」を挙げる。
• そのうえで「基本的には Agents.md のグローバルプロンプトは 書かない」とする (AGENTS.md のことを記事は Agents.md と表記する)。
• 「最新モデル知識に組み込まれてる知識は、半年ほど古い」とする。
• 「skill は(おそらく)重点的に学習されているので、いらなくなる速度が速い」とする。
• 「世界知識はモデルに埋め込まれてる情報で、コンテキストウィンドウに与えた情報は、それより優先される」とする。
• 「モデルにとって既知の情報が多くなるようにプロンプトを与えると(=よく知られたOSSで構築すると)、結果的に高効率で動く」とする。
• /compact は「現在のコンテキストから、重要な情報だけ残して圧縮する」もので、「正しく判断基準が与えられていないと、間違ってる側に倒れるので注意」とする。
• 既存のリポジトリでは、最初に「現状の構成を読み取って解説して」と頼み、「速習しつつ、自分の理解とズレてないか確認」し、それに mizchi/explainer を使う。
• 「一般的ではないこだわりや制約は Agents.md に書く」とする。
• 原始的な Ralph Loop は while :; do claude -p "..."; done の形の「ただの無限ループ」で、プロンプトは「Git 履歴を見て次にやることを探して」。
• /goal (例は /goal Issues を全部潰して) については、「claude session hook で、セッションが終了するたびに 『Issues を全部潰して』 が再送される」と説明し、「goal を満たすまでエージェントは自律的にループする」とする。
• 実験的な手法として dspy の RLM を挙げ、「ある程度ワークフローが決まってるものに対して、巨大コンテキストをインタプリターで実行されるコード断片に分解する」とする。
• マルチエージェントも実験的な手法とし、「現在、決定的な解がない」「難しいなら無理して使わなくていい」と書いて arXiv 2512.08296 を挙げる。
• マルチエージェントのプロンプトは「今あるタスクから、干渉が少ないものをレーンに分割して、レーンごとにサブエージェントを分割して」。
• 探索的な改善では「エージェントを信用してある程度丸投げする」とし、「現状でもかなり賢いので、これでもだいぶ網羅できる」とする。
• その依頼の例は「現在の実装と最新の研究を比較して、参考になるものを列挙して」「SRE視点でテレメトリを計装して」「テストを壊さない範囲でリファクタリングをして」「データベースに対するN+1を見つけて潰して」「セキュリティ視点で攻撃側としてチェックリストを作り、localhostに閉じてペネトレーションして」。
• 「視点が大事」とし、誰にとって何の数値が大事かが改善の仕方の理由になるとして、「自身がないときは、Docker や適切なサンドボックスで実行する」(原文ママ) と書く。
• 見つかったものは「一旦見つかったものは Umbrella Issue でまとめて」と頼み、これで GitHub の 1 つの Issue にまとまるので、/goal にそれを渡せば上から順にやってくれるだろうとする。
• 「自分が専門の範囲は精査して、自分が専門でない範囲はレビューを投げる」とし、そのために作ったスキルとして、メンテナーの人格や好き嫌いを調べてそれに追従する maintainer-persona を挙げる。
• /goal と一緒に使う評価指標として、まずパフォーマンスベンチマークを挙げるが、「CI では安定しないので、RSS やFuel など決定的な指標優先したい」とする。
• メモリ使用率の RSS は hyperfine、perf、valgrind で測る (記事の表記は valglind)。
• 「厳しいルールの lint warning 数」として、循環複雑度 (moznion/cccc) とコード重複率 (mizchi/similarity) を挙げる。
• 「Mutation Test の Kill 率」を挙げる。
• 「VRT の一致率」を挙げる。
• 「具体的な数値に落とせるものが望ましい」とし、「主観的な判断が必要だと、ユーザーが都度呼び出される」とする。
• 結果を理解するために「せめて振る舞いを把握したい」とし、E2E のケース名、テストコード、関数シグネチャを挙げ、「具体のコードを読むととてもじゃないが間に合わない」と書く。
• 「スキルを使って、AIに概念的に解説させる」として DreambigOu/ELI5 と mizchi/explainer を挙げ、「これらでAIから自分にコードを説明させる」とする。
• プロンプトの例に「mizchi/explainer で作った説明画像を gh --attach で添付してPRを作って」があり、このフラグについての gihyo.jp の記事にリンクしている。
• 実験的な取り組みとして「OpenAI はAIがトリアージして、ある程度マージを自動化しているらしい」とし、安全なコードは AI がそのままマージし、危険なコード (たとえば DB スキーマの変更や terraform の変更) は人間にエスカレートするとする。
• 「TODO: 今自分でもこれをやるレビューツール作ってる」と書く。
• 形式手法は、実装しようとしている仕様がそもそも合っているかを「強い型(依存型、時相論理)で検査する」もので、「実現できない、存在がしようがないものを作ろうとしていないか」「最適化に使うアルゴリズムが正しいか」を見るとする。
• 「自然言語がそのまま形式仕様に落とせるわけではない」とし、「その性質を記述するイメージになる」とする。
• 「経験的に、マイクロサービス、マルチスレッドのキャッシュ制御はほぼ確実に漏れがある」とし、「TLA+ か Quint を使うように指示する」。
• 「述語論理で書ける制約は Z3 を使う」とし、「困ったら Z3 か TLA+ を使っておくとよい」とする。
• 「Lean はアルゴリズム自体の開発に使う」とし、ユーザーの権限まわりには Alloy を使うとする。
• 形式仕様のプロンプトの例は「今あるコードを形式化できる部分を形式化して、それをテストオラクルに、実装がそれに従ってるか確認して」「モデル検査で反例が出たら、それを実際のテストケースに落として」「何を検査したか、ドメインの言葉を使わずに例え話で説明して」。
• 使っている仕様化のスキルは、mizchi/skills の formal-methods-reconciler。

[A] Anthropic — Keep Claude working toward a goal, Claude Code docs (2026-10-06 取得時点)

https://code.claude.com/docs/en/goal

• /goal コマンドは完了条件を設定し、Claude はステップごとにプロンプトを受けなくてもその条件に向けて作業を続ける。
• 各ターンの後にモデルが条件を満たしたかを確かめ、まだだと判断すれば、Claude は制御を返さずに次のターンを始める。
• ゴールは、条件が満たされたとき、モデルが不可能と判断したとき、ユーザーが直す必要のあるエラーでターンが失敗したときに消える。
• ドキュメントが挙げる検証できる最終状態の例は、すべての呼び出し箇所がコンパイルされテストが通るまでモジュールを移行すること、各モジュールがサイズの予算を下回るまで大きなファイルを分割すること、ラベル付きの issue のバックログをキューが空になるまで片づけること。
• /goal はセッションに限ったプロンプトベースの Stop フックのラッパーで、各ターンの後に条件とそこまでの会話を設定された小さく速いモデルに送り、そのモデルが未達、達成、不可能のいずれかを短い理由とともに返す。
• 評価役は自分でコマンドを実行したりファイルを読んだりしないので、条件は Claude 自身の出力で示せるものとして書くよう求める。
• 持ちこたえる条件には、1 つの測れる最終状態、npm test が 0 で終わるといった明示的な確認、ほかのテストファイルを変えないといった大事な制約がそろっている。
• 条件は最大 4,000 文字で、or stop after 20 turns のような節で実行を区切れる。
• 1 つのセッションで有効にできるゴールは 1 つで、/goal だけを打つと、条件、経過時間、評価したターン数、トークンの消費、評価役の最新の理由が表示され、/goal clear で消せる。
• 時間の間隔で次のターンを始める /loop や、範囲内のすべてのセッションに効く設定の Stop フック (スクリプトかプロンプト) と違い、/goal は各ターンの後に条件を確かめる別の評価役を加えるので、完了を判断するのは作業をしているモデルではなく新しいモデルだとする。
• ゴールは権限モードを変えないので、無人でゴールのターンを回すには auto mode で /goal を動かすよう勧める。
• claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" は 1 回の呼び出しでループを完了まで回し、--output-format stream-json --verbose で実行中の各メッセージを表示できる。
• Claude が進展のないまま評価役に答え続ける (何ターンも続けてツールを使わない) と、Claude Code はゴールを残したままループを止め、制御を返す。
• ゴールを消す失敗は 4 つで、Claude Code が自分で認証情報を管理しているときの認証の失敗、クレジットの残高切れ、自動圧縮でも解消できないコンテキストのあふれ、モデルが使えないこと。
• ほかのエラーではゴールは残り、v2.1.269 からは、対話セッションは一時的な失敗を再試行し (自動の再試行 3 回の後に一時停止)、レートや利用の上限では一時停止する。
• 動いているサブエージェントやバックグラウンドのシェルがあると評価は先送りされ、30 分後、1 時間後、その後は 2 時間ごとに様子を確かめ (check-in)、プロンプトの間のアイドル時の確認はゴールあたり最大 3 回 (check-in には v2.1.234 以降が要る)。
• CLAUDE_CODE_GOAL_CHECKIN_MINUTES で最初の間隔を変えられ、0 にすると check-in と自動の再試行を切る。
• 評価役は小さく速いモデルで動き、ANTHROPIC_DEFAULT_HAIKU_MODEL で変えられ、そのトークンはメインのターンの消費と比べてふつうは無視できるほどだとする。
• /goal はフックについてのワークスペースの信頼の規則に従い、disableAllHooks が true のときや allowManagedHooksOnly が設定されているときは使えない。

[A] Anthropic — Claude Code changelog, the /goal entries (2026-05-11〜2026-09-17)

https://code.claude.com/docs/en/changelog

• 2026-05-11 に、完了条件を設定すると Claude がそれを満たすまでターンをまたいで作業を続ける /goal コマンドを加えた。
  • 対話、-p、Remote Control で動く。
  • 経過時間、ターン数、トークンをオーバーレイのパネルでライブに表示する。
• 2026-05-12 と 05-15 に、disableAllHooks や allowManagedHooksOnly のもとで /goal が黙って止まる問題と、バックグラウンドのシェルや委任したサブエージェントがまだ動いている間に評価役が発火する問題を直した。
• 2026-08-17 に、回復できないエラーでターンが落ちたときにゴールが通知とともに自ら消えるようにし、ゴールを 30 分以上待たせるバックグラウンドのタスクについて Claude が様子を確かめるようにした。
• 2026-08-19〜08-25 に、アイドルのセッションが 30 分後に様子を確かめ、1 時間、その後は 2 時間ごとに間隔を広げ、次のメッセージまでゴールあたり最大 3 回の確認を始めるようにし、claude --resume の選択画面が有効なゴールを戻すようにした。
• 2026-09-11 に、API のエラー、ネットワークの切断、トークンの上限の後に /goal の実行が黙って止まっていた問題を直し、ゴールはバックオフ付きで再試行するか、利用の上限が戻るまでを含めて一時停止してその理由を示すようにした。
• 2026-09-17 に、圧縮したセッションを再開すると有効な /goal が失われる問題と、有効な /goal のようなフック駆動のセッションが圧縮されずに Prompt is too long で終わる問題を直した。

[A] GitHub, mizchi/skills — formal-methods-reconciler: SKILL.md and references/tool-selection.md (2026-10-06 取得時点)

https://github.com/mizchi/skills/tree/main/formal-methods-reconciler

• ソフトウェアの仕様、文書、テスト、設定、コード、ログ、インシデントを形式手法で突き合わせるときに使うスキルで、Z3、Alloy、TLA+、P、Dafny、MoonBit prove、Lean、Rocq、Why3、Verus、CBMC、Tamarin、ProVerif から選ぶ。
• 基本の立場は、LLM が候補のモデルを提案して直し、判断はソルバー、モデル検査器、検証器、証明支援系が下し、最終結果は人が判断できるようドメインの言葉に訳し戻すというもの。
• ステップ 1 は正しさの拠り所を選ぶ: 信頼できる仕様、文書、ADR、API の契約があれば期待される契約とし、なければコード、テスト、設定、ログを事実上の振る舞いとして扱い自動的に正しいとはみなさず、両者が食い違えば一人で決めずにドメインへの質問を作る。
• ステップ 2 は、ツールを選ぶ前に主張 (許される、禁じられる、いずれ起きる、決して起きない、等価、到達できる、到達できない、不変条件を保つ) を取り出し、空、欠落、エラー、タイムアウト、再試行、クラッシュのときの振る舞いを明示する。
• ステップ 3 は、問いを純粋な述語、関係、状態遷移、メッセージのプロトコル、逐次のコードの契約、全称の定理、セキュリティのプロトコルに分類する。
• ステップ 4 は最小のツールを選ぶ段階で、速い設定のバグ探しに Lean や Rocq を使わない、時間的なインターリーブに Z3 を使わない、単純な述語の一貫性に TLA+ を使わない、とする。
• ステップ 5 は I/O、フレームワーク、データベース、UI のない最小のモデルを作り、強すぎるモデルを捕まえる肯定的な健全性のケースと、チェックが効いていることを示すための壊した変種を用意する。
• ステップ 6 は検証器の出力を修正のオラクルとして使い、ドメインの判断が変わったのでない限り、緑にするためだけに性質を弱めることは決してしない。
• ステップ 7 は、モデルの反例はモデルについての主張で、まだコードについての主張ではないとする。
  • エージェントは証拠 (witness) を強制する実装のテスト (同じ入力、同じ関係のインスタンス、バリアやクラッシュの注入や止めた時計で駆動するインターリーブ) を書き、同じように失敗するテストを回帰の防御にする。
  • 実装がどちらの向きに食い違っても、まずモデルのバグとして扱い、分離レベル、ロックの意味、再試行の方針、提供者の保証のような前提を見直す。
• モデルが小さく信頼できるなら、テストオラクルとして残し、モデルの証拠やモデル検査器のトレースを実装のテストケースとして再生するか、実装を実行可能なモデルと突き合わせる。
• ステップ 8 と 9 は、結果をドメインの言葉 (誰が何をできるか、どの順序が受け入れられるか、どの設定が死んでいるか、どのクラッシュの並びがデータを失うか) に訳し、判断を文書、CI のチェック、ドメインの責任者への質問として固定する。
• LLM が担うのは主張の抽出、ツールの選択、最初の形式化、反例の説明、修正の提案、言い回しで、正しさの拠り所でも、証明の最終的な判定者でもない。
• 出力の約束は、通るか落ちるかのコマンドを持つ形式的なチェック、訳した証拠、回帰の防御の候補、再現する実装のテスト、台帳のエントリのいずれかで、作る価値のある形式モデルがなければ、その理由を述べてより安いチェックを提案する。
• ツールの対応は、純粋な述語 (バリデーター、機能フラグ、設定、適格性) に Z3、関係 (RBAC、テナントの分離、所有) に Alloy、状態遷移 (再試行、クラッシュ、キュー、outbox、活性、すべてのインターリーブ) に TLA+、メッセージのプロトコルに P、逐次のコードの契約に Dafny、全称の定理に Lean 4、セキュリティのプロトコルに Tamarin か ProVerif。
• 使い分けとして、入力の述語は Z3、実体と関係の世界は Alloy、構造の穴は Alloy、順序や再試行やクラッシュがバグを生むなら TLA+ とする。
• モデル化の前に、到達できてはならない悪い状態は何か、ドメインの責任者を納得させる証拠は何か、CI でこのチェックを走らせるコマンドは何か、といった問いを自分に投げる。
• README はこのスキルが Codex を助けるとし、フォルダーには agents/openai.yaml、evals/、4 つの参照資料があり、apm install mizchi/skills/formal-methods-reconciler か npx skills add mizchi/skills --skill formal-methods-reconciler で入れる。
• 兄弟のスキル formal-methods-drift-guard は、仕様、コード、モデルのずれを確かめて既存のモデルを保守する。

[A] GitHub, mizchi/skills — maintainer-persona: README and SKILL.md (2026-10-06 取得時点)

https://github.com/mizchi/skills/tree/main/maintainer-persona

• 自分が持ち主でないリポジトリに、メンテナーがトリアージできる issue や PR を書くためのスキル。
• 投稿の形は、発見の性質ではなく、対象のリポジトリの性質で決まるとする。
• ある大きな OSS のプロジェクトで、そこで PR がマージされたことのない作者による 44 の PR のうち、13 がマージされ、9 がメンテナーに、22 が自動のチェックに閉じられており、結果を決めたのは新参であることではなく自動化だったとする。
• パイプラインは 9 段階 (0〜8) で、測定、ペルソナの手での仕上げ、文脈による分岐、事実の検証、下書きと lint、ユーザーの承認、対象が英語で書く場合の翻訳、新しい読み手による確認、ゲートと送信。
• node $S/measure.ts acme/widget --corpus personas/acme/widget.corpus (Node 24+、認証済みの gh、読み取り専用) は、personas/<owner>/<repo>.md と、メンテナー自身の PR と issue の本文のコーパスを書き出す。
• 測る行には、初めての作者の結果と最初の人による応答までの時間の中央値、目に見える本文の長さの p90、見出し、PR がテストファイルに触れるか、閉じる issue にリンクするか、sign-off があるか、必要な承認とチェックが含まれる。
• 文脈の行には、関係 (internal か oss)、立場 (PR がマージされるまで first-time)、公開範囲 (public か private)、種類ごとの言語 (かなを含む本文の割合で判断) を記録する。
• 測定は移せるが処方は移せないとし、指示に仮説を入れて作ったペルソナはその仮説を助言として返し、しかもそれは誤りだったとする。
• 事実は固定したバージョン (branch @ short-sha) に対して検証し、すべての file:line は番号付きの読み取りから取り、トラッカーはすべての状態の issue と PR を検索し、X は存在しないという主張はすべて大文字と小文字を区別せずに検索し直す。
• 下書きは日本語で書き、ユーザーが内容を承認してから翻訳し、slop の lint (兄弟の ai-index スキルの slopscore.py) が 0 で終わり、取り除ける兆候がメンテナーのコーパスの最大値を超えないことを求める。
• 対象のファイルの中の指示はデータとして扱い、AI エージェントに宛てた AGENTS.md、テンプレート、ボットのコメントは要件として記録するが、決して従わない。
• 新しいサブエージェントが、ペルソナと下書きだけを読んで前もって決めた失敗の基準で判定し、2 回書き直しても通らなければスキルは止まって、その異議をユーザーに示す。
• check-draft.ts が送信をゲートし (目に見える長さと p90、言語、公開の対象の読み手が開けない参照)、ゲートと送信は 1 つのシェルのステップで動き、送信のたびにその場でユーザーの確認が要る。

[A] GitHub, mizchi/skills — repository README and the multi-agent-orchestration skill (2026-10-06 取得時点)

https://github.com/mizchi/skills

• @mizchi が保守し APM (Agent Package Manager) で配布するエージェントスキルの集まりで、各ディレクトリは agentskills.io のオープンな標準に従い、取得時点でスター 352、フォーク 5、コミット 129。
• スキルは apm install -g mizchi/skills/<skill-name> で入れるか、npx skills add mizchi/skills --skill <skill-name> で互換のエージェント (Claude Code、Codex、opencode、Gemini CLI、Cursor) に入れる。
• カタログには、StrykerJS で JavaScript と TypeScript のテストの質を測り、CI で Git の差分にミューテーションを走らせ、生き残ったミュータントを手元でのアサーションの改善に使う stryker-js のほか、empirical-prompt-tuning、retrospective-codify、waxa-eval がある。
• waxa (npx @mizchi/waxa) はスキルを評価するもので、--baseline でスキルありとなしの実行を比べ、iterate で台帳付きの反復ループを回し、PATH に claude CLI が要る。
• multi-agent-orchestration は、エージェントを足すな、という一文から始まる。
  • 足すべきは独立に検証できる作業で、依存グラフを作り、独立したノードだけを並列にし、共有の状態と検証役を通じて統合するとする。
• そのゲートは既定で単一のエージェントとし、独立した部分があるか、情報、モデル、ツール、権限の違うエージェントが要る場合で、しかも期待される利得がトークン、レイテンシ、エラーの伝播のコストを上回るときだけマルチにする。
• Google の 260 構成の比較として、分解できる金融の推論で単一のエージェントに対し +80.8%、逐次の計画で −70% を引き、中央の検証役がなければエラーが伝播するとする。
• 各コーディングのタスクは契約 (writeScope、budget、successCriteria、outputSchema を持つ AgentTask) で、書き込みの集合が重ならないノードだけを並列に動かし、共有の幹に書くのは統合役だけで、検証役は別の文脈で動く。
• 単一のエージェント、静的な DAG、動的な DAG を固定のトークン予算のもとで比べるよう求め、論文の数値は著者の報告で、その比較の代わりにはならないとする。

[A] GitHub, mizchi/explainer — README (2026-10-06 取得時点)

https://github.com/mizchi/explainer

• AI から人に概念を説明するためのスキルとツールの集まり。
• Geoffrey Litt を引き、コーディングエージェントはいまや人が理解できるより速く書くとし、このリポジトリは、1 人の読み手のために、その読み手がまだ知らないことだけを、主張と図をツールで確かめて書くためのものだとする。
• 1 つの Claude Code のプラグイン explainer に、explainer (1 人の読み手向けの速習講座)、explainer-book (章立ての講座)、first-reader (書き直さずに、どこで読み手が脱落するかを報告する模擬の読み手)、d2-diagram、d2-slides の 5 つのスキルがある。
• 導入は /plugin marketplace add mizchi/explainer と /plugin install explainer@explainer、または npx skills add mizchi/explainer --skill '*' -a claude-code、または apm install mizchi/explainer --target claude。
• パイプラインは、ペルソナ → 問い → 実物 (動かせる例、モデル) → 文と図 → 検証 → HTML と進む。
• ペルソナのファイルは、読み手がすでに知っていることと理解があやふやなところを持ち、何を省くかを決める。
• 検証では、引用した出力をすべて checks.json から再実行し、Mermaid、D2、SVG、HTML の図を事実のシートと照らして重なり、はみ出し、矢印の読みやすさを確かめ (figure-check.mjs)、ページに vlmkit check integrity と check a11y contrast を走らせる。
• ELI5 (DreambigOu) が読み手を型 (年齢、職業) として扱うのに対し、explainer は実在の 1 人を読み手とし、書いたものをツールで確かめるとする。
• 例は、公開情報から作ったペルソナにもとづく mizchi 向けの形式手法の速習講座で、ペルソナから彼がすでに約 10 の検証器をエージェント経由で動かしているとわかったため、文書はツールの使い方ではなく、チェッカーの緑の結果が何を保証したかの判断を扱っている。
• Node 24+ と npm i -D @mizchi/vlmkit marked playwright mermaid が要り、D2 の図には d2 CLI、TLC と Apalache には Java 17+ (npm run setup:tla) が要る。
• 評価は claude plugin eval . --trust-plugin --allow-tools Bash Write Edit Agent -j 4 で、各ケースをプラグインありとなしで走らせる。
• 2026-09-25〜27 の実行での Δ は、crash-course +0.43、crash-course-known-heavy +0.25、crash-course-persona-implicit +0.12、crash-course-persona-build が回によって +0.13〜+0.40、pr-reader-first +0.50、book +0.28 で、対照のケースでは差がなかった。
• 実行できなかったコードを報告してしまうことは、スキルありで 6 回中 6 回、なしで 6 回中 1 回起きており、評価のサンドボックスでシェルが動かなかったため、コードの実行を見る採点は無効にしてある。
• ライセンスは MIT (同梱の first-reader は Shubhamsaboo/awesome-llm-apps の Apache-2.0 のまま) で、取得時点でスター 394、フォーク 7、コミット 84。

[A] GitHub, mizchi/similarity — README (2026-10-06 取得時点)

https://github.com/mizchi/similarity

• Rust で書いた高性能なコードの類似検出のツール群で、重複した関数や似たコードのパターンを見つける。
• similarity-ts は Production Ready、similarity-py と similarity-rs はベータで、Elixir、汎用 (Go、Java、C/C++、C#、Ruby)、Markdown、CSS のツールは実験的。
• コードを AST に解析し (TypeScript と JavaScript は oxc-parser、Python と Rust は tree-sitter)、組を TSED (Tree Structure Edit Distance) とサイズのペナルティで採点して 0〜1 に正規化する。
• cargo install similarity-ts で入れて similarity-ts . で走らせ、オプションには --threshold (既定 0.85)、--min-lines、--cross-file、--print がある。
• 結果は VSCode でクリックでき、優先度 (行数 × 類似度) の順に並ぶ。
• README は、AI に similarity-ts . を走らせて重複を見つけ、リファクタリングを計画させるプロンプトを示し、連携として pre-commit のフックと CI を挙げる。
• MIT で、取得時点でスター 828、フォーク 22、コミット 272。

[A] GitHub, moznion/cccc — README (2026-10-06 取得時点)

https://github.com/moznion/cccc

• Cognitive Complexity (SonarSource / G. Ann Campbell) と Cyclomatic Complexity (McCabe) を測る速い CLI (単一の cccc バイナリ) で、Rust で書かれている。
• 拡張子でファイルを 19 の言語と Racket のフロントエンドに振り分け、TypeScript と JavaScript (oxc)、Rust (syn)、Go、PHP、Ruby、Python、Kotlin、Java、C、C++、Swift、Dart、Scala、Zig などに対応する。
• --max-cognitive N と --max-cyclomatic N は、どれかの関数が N を超えると 0 以外で終わるので、cccc --max-cognitive 15 src/ が CI のゲートになる。
• --top-cognitive N はファイルをまたいで関数を順位づけし、出力は既定で 1 行の JSON で、その summary は平均の代わりに合計、最大、中央値、p90、p95 を報告する。
• しきい値は cccc.toml に書け、たとえば max-cognitive = 15 と max-cyclomatic = 10。
• 結果のキャッシュにより、2 回目以降の実行は約 3 倍 (TS/JS) から 17 倍 (C のような tree-sitter の言語) 速く、CI では 1.6〜9.6 倍速くなり、moznion/cccc-action で GitHub Actions に組み込める。
• GitHub Releases か cargo install cccc-cli (crates.io のビルドには Kotlin がない) で入れ、取得時点でスター 86、フォーク 11、コミット 274。

[A] GitHub, DreambigOu/ELI5 — README (2026-10-06 取得時点)

https://github.com/dreambigou/eli5

• 子ども、マネージャー、エンジニア、親など、誰にでも何でも説明する Claude Code のスキル。
• プロンプトから読み手 (5 歳から 40 歳以上、学年、職種、関係) を見分け、語彙、たとえ、口調、深さ、枠組みを合わせる。
• skills/eli5 を ~/.claude/skills/eli5 にコピーして入れ、ELI5 this や explain this to my manager のように頼む。
• 評価のスクリプトは各プロンプトをスキルありとなしで走らせ、出力をアサーションに照らして Claude で採点し、スキルありで 10/12 (83.3%)、なしで 5/12 (41.6%) が通った。
• 最も改善したのは読み手に合わせた枠組みで、とくにマネージャーのような技術者でない読み手で、ベースラインの 0% からスキルありで 50% になったとする。
• MIT で、取得時点でスター 1.7k、フォーク 93、コミット 10。

[A] DSPy — dspy.RLM, API docs (2026-10-06 取得時点)

https://dspy.ai/current/api/modules/RLM/

• RLM (Recursive Language Model) は、サンドボックス化した Python の REPL を通じて、LLM が大きなコンテキストをプログラムで探索できるようにする DSPy のモジュール。
• Recursive Language Models (Zhang, Kraska, Khattab, 2025) を実装し、変数の空間 (REPL に保存した情報) とトークンの空間 (LLM が実際に処理するもの) を分けることで、コンテキストの劣化 (context rot) に対処する。
• ループでは、LLM がコンテキストについてのメタデータ (型、長さ、プレビュー) を見て、それを探る Python を書き、サンドボックスの出力を読み、断片の分析にサブの LLM を呼ぶ llm_query(prompt) を使い、SUBMIT(output) で終える。
• dspy.RLM("context, query -> answer") は max_iters (既定 20)、max_llm_calls (50)、max_output_chars (10,000)、tools、sub_lm を受け取り、ドキュメントは sub_lm に安いモデルを使うよう勧める。
• 既定の PythonInterpreter は Deno と Pyodide の上でローカルの WASM サンドボックスを動かし (pip install "dspy[deno]")、LocalInterpreter はセキュリティのためのサンドボックスではないとする。
• 結果にはステップごとの推論、コード、出力からなる trajectory が含まれ、RLM は実験的と位置づけられている。

[A] arXiv — Kim et al., Towards a Science of Scaling Agent Systems (2512.08296, v1 2025-12-09, v3 2026-04-08、背景)

https://arxiv.org/abs/2512.08296

• 260 の構成での統制された評価で、6 つのエージェントのベンチマーク、5 つのアーキテクチャ (Single-Agent と、Independent、Centralized、Decentralized、Hybrid のマルチエージェント)、3 つの LLM ファミリーを、ツール、プロンプト、計算量をそろえて比べた。
• 予測モデルは、6 つのベンチマーク全体で交差検証の R^2=0.373 (タスクに根ざした能力の指標を使うと 0.413) に達する。
• 主な結果は、単一のエージェントのベースラインがある性能を超えると協調の利得は逓減すること、ツールの多いタスクはマルチエージェントのオーバーヘッドを負うらしいこと、中央での検証のないアーキテクチャは中央で協調するものよりエラーを伝播させやすいこと。
• 単一のエージェントと比べた変化は、分解できる金融の推論での +80.8% から、逐次の計画での −70.0% まで幅がある。
• この枠組みは、取り置いた構成の 87% で最も性能のよいアーキテクチャを言い当てる。

[A] GitHub Changelog — GitHub CLI: Media in issues, pull requests, and comments (2026-09-01、背景)

https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/

• GitHub CLI に、ローカルの画像や動画をアップロードして issue、プルリクエスト、コメントの本文にインラインで参照させる、繰り返し指定できる --attach フラグが加わった。
• gh issue create、edit、comment と gh pr create、edit、comment で使え、gh v2.99.0 が要る。
• 本文ですでに参照しているローカルのパス (たとえば ![alt](./login.png)) はその場で書き換えられ、添付したが参照していないものは末尾に足される。
• 対応形式は PNG、JPEG、GIF、WebP、SVG、MP4、MOV、WebM で、上限は画像と GIF が 10 MB、動画が 10 MB (Free) か 100 MB (有料プラン)。
• アップロードにはリポジトリへの書き込み権限が要り、GitHub Enterprise Server はこのリリースでは対象外。
• コーディングエージェントもこれを使えるので、結果を言葉で説明する代わりに見せられるとする。

[B] gihyo.jp — GitHub CLIに--attachフラグ、コマンドラインからIssueやPull Requestへ画像・動画を添付可能に (2026-09-02、背景)

https://gihyo.jp/article/2026/09/github-cli-attach-flag

• mizchi が gh --attach のためにリンクした記事で、GitHub の changelog と同じコマンド、形式、上限、v2.99.0 の要件を伝える。
• そのうえで「1回のコマンドで複数回指定でき、最大50ファイルを添付できる」と付け加える。
• --body-file を併用すると Markdown が参照するローカルパスの位置に画像が表示され、末尾に足す画像の代替テキストはパスの末尾に # とテキストを続けて指定できるが、「動画には代替テキストを指定できない」とする。

[A] Geoffrey Huntley — Ralph Wiggum as a "software engineer" (2025-07-14、背景)

https://ghuntley.com/ralph/

• Ralph は技法だとする。
  • 最も純粋な形の Ralph は Bash のループで、while :; do cat PROMPT.md | claude-code ; done。
• 1 回のループで Ralph に頼むのは 1 つのことだけ、と念を押す。
• プロンプトは毎回のループで同じ計画 (@fix_plan.md) と仕様を読み込み、主のコンテキストウィンドウはサブエージェントのスケジューラーとして働き、ビルドとテストに使えるサブエージェントは 1 つだけとする。
• セキュリティのスキャナーや静的解析器のように、不正なコード生成をはじく背圧 (back pressure) として何でもつなげられるが、車輪は速く回らなければならないとする。
• マルチエージェントについては、現段階では要らないとし、それ自体が非決定的なマイクロサービスのようなもので、ひどい混乱になると書く。

[B] Geoffrey Huntley — software doesn't need to be readable anymore. it needs to be explainable (2026-10-02)

https://ghuntley.com/readable/

• AI:Engineer World Fair で収録した、AI21 Labs とのポッドキャスト YAAP の書き起こし。
• ソフトウェアは人が読めなくてもよく、人に説明できなければならないとする。
• コードは人が理解できるよう読みやすくあるべきだと、まだ多くの人が声高に言っているが、もはやそれが目標だとは思わないと書く。
• 実演では、わざと難読化した Haskell の関数も、息子や娘に説明するように、ただし参照として Python で説明してほしいと LLM に頼むと理解できるようになった。
• 成果物は人がいきなり読むために最適化されている必要はなく、モデルが求めに応じて人に説明できるものであればよいとする。
• 型は検証の一形態で、コンパイラーのエラーが背圧になり、LLM が毎回のループでそれを拾って自動で直すとし、そのおかげで安いモデルも使えるとする。
• 言語はいまや交換可能で、ループを回せばある言語から別の言語へ移植でき、最終結果を検証しやすければ移植は簡単だと論じる。
• 2 年間手でコードを書いておらず、推論なしか低の設定の GPT 6.1 sol と、GLM や Kimi を組み合わせて使っているとする。

[B] Martin Fowler — Fragments: October 4 (2026-10-04)

https://martinfowler.com/fragments/2026-10-04.html

• コードを読むことが開発者の未来に残るかという問いに関して、コードは人が理解できるよう読みやすくあるべきだとまだ多くの人が声高に言っているが、それが目標だとはもう思わない、という Huntley の言葉を引く。
• Huntley の例は LLM に Haskell の関数を Python に訳して説明させるもので、Fowler はこれを、コードの役割は残るが、LLM が読み手に示すのと同じ形でコードを保持する必要はないことを示すものと読み、projectional editing の背後の考え方に結びつける。
• Sam Ruby を経由して、約 60,000 トークンの Rails のアプリケーションを C にコンパイルすると約 4,000,000 トークンに膨らむ例を挙げ、人が読まなくても高水準の記法を残す理由とする。
• 私たちは生成されたコードの受け身のレビュー役になるべきではなく、コードは理解のモデルでもある、という Unmesh Joshi の言葉を引く。
• Sam Ruby の後の投稿から、私たち全員のテーマとして、今週目の前にあるタスクで情報はどこから来て、何が結果を確かめるのか、という問いを取り上げる。

[B] Geoffrey Litt — Understanding is the new bottleneck (2026-07-02、背景)

https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck

• 2026 年 7 月の AI Engineer のカンファレンスでの講演の文章版で、mizchi/explainer の README が引いている。
• あえて異論のありそうな意見として、エージェントが書いたコードを理解することはやはり大事だと書く。
• エージェントは自分の作業を検証するのがどんどんうまくなるので、理解は検証のためだけでなく参加するために要ると論じ、これを認知的負債に結びつける。
• 彼の /explain-diff スキルは、コードの解説を HTML、Markdown、Notion のページとして書き、まず背景を教え、細部の前に直感を置き、変更を文章で語る literate diff としてたどる。
• 各解説は 5 問のクイズで終わり、クイズに合格できるまで他人にコードを送らず、他人のコードをレビューするときも同じにしていると書く。
• クイズは速度の調整器だとする。
• ほかの技法として、Prolog のインタープリターのためのステップ実行のデバッガーや、サイトを段階的に移植するためのコマンドセンターのようなマイクロワールドと、チームでともに理解を作る共有の場を挙げる。

[B] ACM SIGOPS blog — Can LLMs model real-world systems in TLA+?, by the Specula team (2026-05-08、背景)

https://sigops.org/2026/can-llms-model-real-world-systems-in-tla

• Etcd の Raft の実装について Claude に TLA+ の仕様を頼むと、構文のチェックと TLC は通ったが、それは Etcd ではなく Raft の論文の付録の仕様だった。
• SysMoBench は、ソースコード、トレースを集めるハーネス、不変条件のテンプレートとともに 11 のシステムを LLM に与え、生成した仕様を構文、実行時 (TLC)、適合 (実際の実行に対するトレースの検証)、不変条件の 4 段階で採点する。
• 上位の LLM は、構文ではほぼ満点なのに対し、適合で平均約 46%、不変条件で平均約 41% にとどまり、実行時のスコアは 30%〜92%、不変条件のスコアは 16%〜81% (Gemini 3.1) に広がる。
• 教科書的なモデル化による失敗の型は 2 つで、仕様がシステムの入らない状態に到達するもの (Claude Sonnet は ZooKeeper の送信者ごとの票のマップを集合の和としてモデル化した) と、システムが必ず入る状態を見落とすもの (コードの 2 つのステップを 1 つの原子的なガードにまとめた)。
• Claude Sonnet 4.6 は、RedisRaft と CURP で全体の 25% しかとれないとする。
• チームは、Claude Code や Codex のような最前線のコーディングエージェントはすでに実システムの TLA+ のモデル化に強い力を持つとし、自分たちのエージェント Specula は現在の SysMoBench のタスクで適合と不変条件の満点に達するとする。

[A] arXiv — Cheng et al., Specula: Scaling formal specifications for autonomous model checking of system code (2607.25333, v1 2026-07-28、背景)

https://arxiv.org/abs/2607.25333

• Specula は、大きく複雑なシステムのコードに高品質な形式仕様をボタン 1 つで生成し、その仕様を使ってきわめて効果的なモデル検査とバグ探しを行うエージェントのシステムだとする。
• LLM ベースのコーディングエージェントが、不変条件と、適切な抽象度での実装のモデルを含む TLA+ の仕様を書く。
• エージェントのコードの理解を深める自己進化のループで、報酬ハッキングと幻覚に対処する。
• 48 のオープンソースのシステムのプロジェクトで、既存の手法では見つけにくい深いバグを多く含む 249 のバグを見つけ、いくつかの企業で使われているとする。

[B] laiso — 説明スキルの比較：ELI5、Archify、Explainer (2026-10-05)

https://blog.lai.so/eli5-archify-explainer-skills/

• 「特徴の異なる3つのスキルを紹介し、実際にAgent Skillsの仕組みの説明を生成して比べてみます」とする。
• 取り上げる ELI5 は「Anthropicのコミュニティプラグイン用リポジトリ」にあるもので、「大きな絵と少ない言葉を使ったHTMLで、対象を視覚的に説明するスキル」であり、その「スキルは短く、題材について何も知らない人を想定しています」とする。
• AI に仕事を任せるほどソースコードを読む機会が減る一方、生成される文章は「冗長で、専門的な語彙や会話のコンテキスト汚染がある、前提知識に頼ったものになりがち」で、「それを人間が読解するコストもばかにならない」ため、こうした説明系のスキルは「その負担を減らすためにも受け入れられている」と見る。
• 保存したページは導入部だけで、比較そのものは有料会員向け。

[A] Anthropic — claude-plugins-community, the eli5 plugin manifest (2026-10-06 取得時点)

https://github.com/anthropics/claude-plugins-community/tree/main/eli5

• plugin.json は、どんな話題でも 5 歳児に説明するように、大きな図と少ない言葉のとても簡単な HTML の絵の解説を作るものと説明する。
  • 使い方は /eli5 <topic>。
• 作者は Thariq Shihipar (バージョン 1.0.0、MIT) で、mizchi がリンクした DreambigOu/ELI5 とは別のスキル。

[C] Hatena Bookmark — Comments on the article (2026-10-05〜2026-10-06)

https://b.hatena.ne.jp/entry/s/zenn.dev/mizchi/articles/ai-coding-loop-formal

• 2026-10-06 の 10:13 JST までに 425 ユーザーがブックマークし、22 件のコメントがあり、カテゴリはテクノロジー。
• masterq は「/goal知らなかった」とし、「都度判断しないと方針にブレが起きそうで怖い」「このトークン貧乏な思考がそもそももう古いのかもしれない」と書いて、「マルチエージェントが実験的な扱いになっているのが興味深い」とする。
• pochi-taro00 は「/goalは一つだけしか判定できないし その判定エージェントも嘘つく事があるんよね」と書く。
• kiririmode は「AIに仕事を任せられる主要因は『AIが自力で評価・再試行できる閉ループ』に変換できるか」とし、「人間の主要な仕事は実装ではなく、閉ループを成立させる評価関数・制約・優先順位・エスカレーション条件を設計すること」とする。
• mkusaka (AI 要約のタグ付き) は「人間の役割定義と評価指標（RSS/Fuel、hyperfine等）を用い/goal・/compactで改善する手法を整理」とまとめる。
• netanetia は「当時AIが出力するコードをクリーン保つため四苦八苦していたノウハウはごみのようになった」「今はとにかく動いてりゃそれでいい」「負債は将来賢い奴（モデル）が解決するだろう」と書く。
• hdampty7 は「今に最適化すると無駄になる、そういう時代」「とにかく動く製品を作り続ける」としつつ、「ただ、おどろくような単純なバグもある」「ソースコードを読まずにそれをどうやって見つけ出すか、それが課題」と書く。
• mayumayu_nimolove は「もうエンジニアは技術では無く必要とされるものの作り方，見つけ方に移るべき」と書き、「あ、それだとエンジニアじゃないや」と続ける。
• pmint は批判的で、「まず『ループ構築はAIに任せられる仕事か』を考えましょう」「Anthropicを頂点としたMLMに刷り込まれてる」「この手の知識をいくら集めてもAI情報商材屋に取り込まれるだけ」と書く。
• sd-craft は「ハーネスハーネス言ってたのももう終わったしな」、chiba1008 は「しょーもないのばっか上がってくるなあ…」と書く。
• igrep、kabochatori、shoh8 は締めの「またすぐ変わると思います」を取り上げ、nguyen-oi は「形式手法まで組み込んで自律ループ回してて流石だな」と評し、onesplat は「clineに全部賭けた人だ」と書く。
• mizchi 自身も「書いた」と添えてブックマークしており、残りのコメントは あとで読む の類、お礼、猫のキャラクターのアカウントのもの。

メモ

• 記事とドキュメントで /goal の説明が違う: 記事はセッションが終わるたびにセッションのフックが指示を送り直すとするが、ドキュメントはセッションに限ったプロンプトベースの Stop フックで、小さく速いモデルが各ターンの後に会話だけから条件を判断し、コマンドの実行もファイルの読み取りもしないとする。
  • したがって指標のループでは、Claude が測った数値 (Kill 率、警告数、RSS) を毎ターンやり取りの中に出力する必要があり、条件には測り方を書き、ターン数か時間の上限を付けるべきことになる。
• pochi-taro00 の不満はドキュメントと合う: 1 つのセッションで有効なゴールは 1 つなので、複数の指標は最大 4,000 文字の 1 つの条件を共有することになり、評価役は Claude が示したものを確かめずに判断する。
  • 誤って報告された数値が評価役を通ってしまうかどうかは試していない。
• 記事の主張のうち出典のないものは、深呼吸のプロンプトでの数学の 7 ポイントの改善、OpenAI の AI によるトリアージ付きのマージ (記事自身の言い方で伝聞)、スキルが重点的に学習されているという点 (筆者自身が推測と断っている)。
• 記事は Fuel を定義していない。
  • WebAssembly のランタイムの fuel のような、決定的な命令の予算を指すのかもしれないが、未確認。
• 記事はグローバルプロンプトに選択肢の判断基準を書くとしつつ、AGENTS.md のグローバルプロンプトは基本的に書かないとも言う。
  • 合わせて読むと、グローバルプロンプトはそうした基準に限り、プロジェクト固有の制約はリポジトリの AGENTS.md に置くと読める (解釈)。
• ELI5 と呼ばれるスキルは 2 つある: 記事と explainer の README がリンクするのは DreambigOu/ELI5 (読み手に合わせた文章) で、laiso が比べているのは Thariq Shihipar による Anthropic のコミュニティプラグイン (HTML の絵の解説)。
• SIGOPS の測定は、既存のコードを形式化してテストオラクルに使うという記事のプロンプトへの注意になる: LLM が書いた TLA+ の仕様はしばしばコードではなく教科書のプロトコルをモデル化し、適合は平均約 46% にとどまる。
  • 各証拠を実装で再現し、食い違いをまずモデルのバグとして扱う formal-methods-reconciler のステップ 7 がその安全策で、記事自身のプロンプトは適合の確認に触れていない。
• formal-methods-reconciler の README はこのスキルが Codex を助けるとし、フォルダーに agents/openai.yaml があるが、スキルは Claude Code も入れられる agentskills.io の形式で、その evals/ は読んでいない。
• コードを読むことについての見方は分かれる: Huntley はコードは読めるより説明できることが必要だとし、Litt と、Fowler が引く Joshi は、受け身のレビュー役ではなく参加するために人が理解することを求め、mizchi は E2E のケース名、テスト、シグネチャを読み、残りはスキルに説明させる。
• マルチエージェントへの慎重さは、記事、Huntley の 2025 年の Ralph の投稿、arXiv 2512.08296 に共通し、mizchi の multi-agent-orchestration スキルはその数値を著者の報告として繰り返している。
  • スキルは論文を Google のものとしているが、arXiv の要旨のページにそうは書かれていない。
• mizchi/explainer 単体は 09-30 にフィード (hatena-llm) に現れ、2026-10-01 のノートでその他の単発項目に載った。
• 1 回の Web 検索では記事についての独立した記事は見つからず、その広がりは 1 日以内に はてな の 425 ユーザーと Zenn の 379 のいいねに表れている。
• WebFetch だけに拠る事実は、gihyo.jp の日付 (2026-09-02、ページのヘッダーから読んだ) と、laiso の投稿の残りが有料会員向けであること。

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

• 使い捨てのリポジトリで、決定的な数値 1 つ (たとえば cccc --max-cognitive 15 src/ が 0 で終わること、similarity-ts が報告する組が決めた数を下回ること) に向けて /goal を回し、条件で Claude に毎ターン数値を出力させて or stop after 20 turns で終える。
  • /goal の状態からターン数とトークンを記録し、エージェントが指標をごまかしたか (ファイルを除外した、しきい値を上げた) も記録する。
• 小さな TypeScript のモジュールに StrykerJS (mizchi/skills の stryker-js スキル) を加え、Stryker の設定と既存のアサーションの変更を禁じたうえでミューテーションテストの Kill 率を /goal の指標にし、エージェントがテストを強くするのか、測り方を弱めるのかを見る。
• 既知のバグ 1 つ (TLA+ でのキャッシュの競合か、Alloy での権限の穴) に formal-methods-reconciler を当て、反例が実装のテストとして再現するか、モデルが SIGOPS の言う教科書的な失敗の型を示すかを確かめる。
• 同じ PR を mizchi/explainer と Litt の /explain-diff で説明させ、explainer の図を gh pr create --attach (gh v2.99.0 以降) で添付し、どちらがレビュー役に変更についての 5 問のクイズを通させるかを比べる。
• /goal の条件に使える指標を CI での決定性の順 (RSS と Fuel 対 実時間のベンチマーク、警告数、重複率、Kill 率、VRT の一致率) に並べ、それぞれを出力するコマンドを添えた 1 ページのカタログを書く。

6. 🎮 アクセンチュア・ジャパンのエンジニアが Jev 互換の決定モデル kev-4b と laya-ml を Mac と Vertex AI で測り、1 回の判断に 15 ms から 252 ms かかることを示したうえで、リアルタイムのアクションゲームの最初の穴を 600 回の試行でどちらも越えられなかったと報告した

• 選定 / 影響度 1 / 将来性 1 / 重要度 2 / 起点 10-05 / 種別: 検証・実践 / 領域: モデル、評価・運用。
• 候補になったフィード項目:
  • zenn-trending 10-05 人生オワタ2を600回、Jev互換AIは穴を越えられず
• 関連: 2026-09-27 のトピック 2 は Jev を、2026-09-29 のトピック 8 は日本語で Laya を Jev と比べた検証を扱った。
  • 今回は、別の筆者によるレイテンシとリアルタイム制御の別の測定にあたる。

収集した情報

[A] Accenture Japan (有志) on Zenn — 人生オワタ2を600回、Jev互換AIは穴を越えられず (Shinya Koike、2026-10-05)

https://zenn.dev/acntechjp/articles/zenn-system1-owata2-realtime

• 「本記事は個人の検証であり、所属組織の見解ではありません」とし、測定コードと生データは GitHub (ccie26302/zenn-code の owata2-system1-realtime フォルダー) に置いている。
• 前作「文章を書かないJevをGoogle Cloudで作れるか」の続きで、公開されている Jev 互換のモデルを動かして測る第 1 部、そのモデルに死にゲーを遊ばせる第 2 部、Jev でマリオを遊ばせる参考デモの入力の作りに寄せる第 3 部からなる。
• 選択肢ごとの確率だけを返す Jev の種類のモデルを、記事は「System-1 モデル」と呼ぶ。
  • Jev 自身の Doom のデモは「画像ではなく構造化された状態を渡していると明記しています」とし、コミュニティ製のテトリスやスネークも盤面を JSON で渡す作り (たとえば jev-arcade) だとする。
• 「Jev 本体は API キーがないので使っていません」とし、比べたのは同じ /v1/systemone の形で呼べる公開モデル 2 つ。
  • kev-4b は Qwen3.5-4B-Base を凍結し、LoRA と選択肢を採点するヘッドを付けた判定モデルで、モデルカード上は英語のみ、Mac では MLX で動かす。
  • laya-ml (laya-multilingual) は mmBERT-base (約 3 億パラメーター) のエンコーダーで多言語、Mac では公式の PyTorch 実装を GPU (MPS) で動かす。
• 検証の環境は M4 Max / 128GB / macOS 26 で、Python のパッケージ管理に uv を使う。
• kev-4b は公式リポジトリのコミット 0fe8fc9 から、uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009 で動かす。
• laya-ml は PyPI の laya 0.3.23 を使い、laya.load("convaiinnovations/laya", subfolder="multilingual", device="mps") で読み込んで /v1/systemone で laya.decide() を呼ぶ、40 行ほどのローカルのサーバーの背後で動かす。
  • 付属の laya-serve はコマンドライン引数を取らず (--help を付けてもそのまま起動した)、既定で 0.0.0.0:8000、「つまり LAN 全体に公開されます」とし、モデルとデバイスは LAYA_MODELS と LAYA_DEVICE で指定する作りだとする。
• 崖の端で 3 択を聞く動作確認では、どちらのモデルも walk right (右へ歩く) を 1 位にし、トゲへまっすぐ歩いていく答えになった: kev-4b は 0.754 (131.8 ms)、laya-ml は 0.483 (サーバー側で 29.1 ms)。
• レイテンシのベンチマークは、開発中の日本語の試走でモデルに渡した重複のない状態の文章 1,249 件と日本語の 11 択を使い、暖機 20 回の後に 300 回を keep-alive で直列に送り、手元で測った往復時間とサーバーが返す内訳を CSV に残す。
• 結果 (p50 / p90 / p99 と、p50 の間に 60fps のゲームが進むコマ数) は次のとおり。
  • Mac の laya-ml (PyTorch、MPS) は 14.6 / 15.0 / 16.0 ms、0.9 コマ。
  • Mac の laya-ml (PyTorch、CPU) は 53.7 / 57.5 / 59.4 ms、3.2 コマ。
  • Mac の画面を読む処理 (撮影と判定) は 55.3 / 65.2 / 78.0 ms、3.3 コマ。
  • Mac の kev-4b (MLX) は 200 / 208 / 214 ms、12.0 コマ。
  • Vertex AI 米国 L4 の kev-4b (カスタム推論) は 252 / 334 / 417 ms、15.1 コマ。
  • Vertex AI 東京の Gemini 2.5 Flash (思考なし) は 440 / 520 / 615 ms、26.4 コマ。
  • Vertex AI global の Gemini 3.8 Flash (思考 LOW、N=100) は 3,685 / 19,068 / 61,887 ms、221 コマ。
• kev-4b は自分でコンテナにし (cloud/Dockerfile、cloud/cloudbuild.yaml で Artifact Registry にビルド)、Vertex AI のカスタム推論 (g2-standard-8 + NVIDIA L4、専用エンドポイント) に置いており、「デプロイには33分かかりました」とする。
• 米国 L4 の p50 の往復 252 ms は、コンテナ内の処理 88.5 ms (うち GPU の推論 84.4 ms、PyTorch・bf16) と、ネットワークと Google の入口の 160 ms (最小 141 ms) に分かれる。
  • TCP の接続は 9 ms で近くの Google の入口につながり、そこから米国までの道のりが約 160 ms。
  • 「L4 の推論(84ms)は Mac の MLX(200ms)より速いのですが、実行系も違うので単純な性能比ではありません」と断る。
• 東京へのデプロイは 2 回ともクォータの 429 CustomModelServingL4GPUsPerProjectPerRegion で失敗し、このプロジェクトの東京の L4 推論の枠は Cloud Quotas で見ると 1 で「公式の既定値の表とは違う値です」とし、原因は確かめていない。
  • 同じ日の朝には、同じマシン構成で東京へ 2 回デプロイできていた。
  • 筆者は、朝の撤去で endpoint が消えきる前に課金を外したことが枠を握ったままにした可能性を挙げるが、確かめていない。
  • asia-northeast1-aiplatform.googleapis.com へのネットワークの時間は、p50 で DNS 3.8 ms、TCP 7.37 ms、TLS 13.68 ms、TTFB 40.49 ms。
  • 東京なら「おおむね100ms 台前半と見込んでいます」とし、そうなら Mac の MLX より速く返るが、これは測っていない。
• g2-standard-8 (L4 1 枚込み) は us-central1 の定価で 1 時間あたり約 0.98 ドルで、専用エンドポイントは呼ばなくても動いている間は課金されるので、1 台を常時置くと月に約 720 ドル (730 時間) になる。
• 計測の後、60 秒放置してから 1 回呼ぶのを 10 回繰り返すと、1 回目は 634 ms、2 回目以降は 335〜463 ms だった (短い 3 択の入力)。
• Vertex AI での落とし穴として、次の 3 つを挙げる。
  • 「カスタムコンテナのヘルス経路は、kev.serve に存在する /v1/models にする」とし、存在しない /health にすると「デプロイが取り消せないまま課金が続いた」。
  • 「python:slim ベースのコンテナでは GPU ドライバのライブラリが見えず、kev-4b が黙って CPU で起動した」とし、LD_LIBRARY_PATH=/usr/local/nvidia/lib64:/usr/local/nvidia/lib などを渡して、起動ログの on cuda を確かめるよう勧める。
  • 撤去の直後に課金を外したら endpoint が 1 つ残って見え、削除がまだ途中だったので、一覧が 0 になってから課金を外した。
• 「Vertex AI は、現在の公式ドキュメントでは Gemini Enterprise Agent Platform という名前で案内されています」と注記する。
• Gemini は前作と同じ方式 (enum の制約と logprobs) で呼び、東京の Gemini 2.5 Flash は p50 440 ms で、東京までの接続が 7 ms ほどなので「ほとんどはサーバ側の処理です」とする。
  • Gemini 3.8 Flash は思考を LOW より下げられず、p50 3.7 秒、p90 19 秒で、100 回中 16 回が 10 秒を超えた。
  • 前作の実測では logprobs も返さなかったので、ゲームには使っていない。
  • 提供場所は global と米国・欧州のマルチリージョンだけで、asia-northeast1 では 404 になり、Gemini 2.5 Flash は提供終了が告知されている。
• 画面を見て状況を文章にする目は、AI を使わないルールだけの画像処理。
  • 自機は 4 種類のお手本との重なり (Dice 係数) を FFT で画面全体について一度に計算して探し、カメラは前のコマとの横ずれを位相相関で求め、足場とトゲはお手本の形で探し、地面は自機の足元の高さで地面の線を数える。
  • お手本はゲームの絵なのでリポジトリには入れず、自分で撮った画面から作るスクリプトを置いている。
  • 出力は You: x=176, y=302. The ground under you ends 4px to the right, with spikes beyond it. A floating platform is at x=282-337, y=245, moving left. のような文章。
• 300 回の計測で目は p50 55 ms (p90 65 ms) かかり、半分以上は Chromium のスクリーンショット (32 ms) で、「laya-ml の判断(15ms)より、目のほうが4倍近く遅いことになります」とする。
  • p50 の内訳は、画像の読み込み 1.5 ms、自機 12.0 ms、カメラ 2.3 ms、足場 3.1 ms、地面 0.1 ms、トゲ 3.3 ms。
• 1 名が目視でラベルを付けた 186 コマでの目の精度は、生存 95/95 を「あり」、自機なし 69/69 と死亡演出 22/22 を「なし」と判定し、閾値 0.43 は同じラベルを見て決めた。
  • 試走中の録画 6,556 コマでは、6,542 コマでトゲの列を 1 本見つけ、14 コマで見逃し、その 14 コマはすべて左の樹海側でトゲが画面の外だった。
  • 足場の位置と向き、地面の切れ目までの距離、カメラ追跡の精度は、正解ラベルでは確かめていない。
• 題材は、作者キング氏が Ruffle (Flash を今のブラウザで動かすエミュレーター) で再公開している『人生オワタの大冒険2』で、FAQ に「配信や実況してもいいですか？」に「いいよ！」とあるので、記事はプレイ動画も載せている。
• 挑むのは 1 面の最初の画面だけで、崖の端は x≈185、穴の上を幅 55px の足場が 1 コマ約 2px で行き来し、向こう岸の地面は x≈393 から始まる。
• リアルタイムの条件として、ゲームの時計を Playwright の fake clock で止め、1 コマ (1/60 秒) ずつ進める。
  • 画面を撮った瞬間からモデルの答えが返るまでに実際にかかった時間 (目とモデル) を計り、そのコマ数だけ手を離した状態でゲームを進めてから行動を実行する。
  • これで laya-ml なら約 6 コマ、kev-4b なら約 17 コマの遅れが乗り、目の時間と録画が加わるため第 1 部の値より長い。
• 「どのキーをいつ押すかはハーネスに書いていません」とし、穴の越え方のスクリプトは一度試して撤回したが、記憶には「足場の上に立てたら大きく加点する」(+100) という、この穴に合わせた点数の付け方が入っている。
• 最初の 6 択では、kev-4b、laya-ml、Gemini 2.5 Flash に各 100 回遊ばせて、足場に乗れた回は全部で 0 回だった。
  • Gemini 2.5 Flash は判断の遅れが p50 31 コマ、最大 575 コマ (約 9.6 秒) で、100 回で 85 回死んだ。
• 操作の効果を測り直すと、Z を押したコマ数が 1、2、4、8、12、16 以上のとき、ジャンプの高さは 24、34、53、106、129、131px だった。
  • 空中で右を 20 コマ押すと +52px、40 コマで +112px 動き、X で弾を撃ち、S で決めポーズを取る (S は公式の操作説明になく、一時停止ではない)。
• 11 択は、右へ歩く、左へ歩く、何もしない、その場・右・左へのジャンプ (Z 16 コマ)、その場・右・左への小ジャンプ (Z 2 コマ)、攻撃、ポーズ。
• この 11 択で穴は越えられ、崖の手前で待つコマ数 (0〜120、4 コマ刻み) と跳んだ直後に空中で右を押す回数 (0〜3 回) の 124 通りを遅れなしで試すと、31 通りで足場に乗れた。
• モデルだけ (英語、各 30 回) では、kev-4b は 30 回死に、27 回跳んで崖を離れ、足場には一度も乗れず、最高 x は 227 で、laya-ml は一度も死なず、一度も跳ばず、最高 x は 99 だった。
  • kev-4b は判断の 73% が small hop to the right (右へ小ジャンプ) で、届かない低い跳び方で穴へ落ち続けた。
  • laya-ml は 2,400 手すべてが attack で、スタート地点で弾を撃ち続けて時間切れになった。
• 崖際で止めた 16 の場面 (足場の位置 4 通り × 動く向き 2 通り × 崖までの距離 2 通り、独立した観測ではない) で、状態の文章だけを変えて確率を比べた。
  • 日本語では、laya-ml は「左へ動いている」と書いた場面の 8/8 で左系の行動を 1 位にし、「右へ動いている」では 0/8 だったが、「x が減る/増える向きに動いている」と言い換えるとどちらも 0/8 になり、kev-4b はどの書き方でも 0/8 だった。
  • 筆者は、laya-ml は向きの意味より「左」という語に反応している可能性が高いと見るが、言い換えは 1 組だけで、x の書き方が通じていないだけという説明も否定できないとする。
  • 押すキーは同じまま、ジャンプ系 6 つの呼び方を変えると、右へ大ジャンプのモデル確率は laya-ml で 0.036 から 0.133 (3.7 倍)、kev-4b で 0.093 から 0.222 (2.4 倍) に上がり、並び順だけを変えると 0.034 と 0.157 だった。
  • 英語では、kev-4b は jump to the right を 16 場面中 8〜13 場面で 1 位にし、確率は平均 0.21〜0.28 だった (日本語では 0.19〜0.23 で、32 場面中 26 場面で右へ歩くが 1 位)。
  • 英語の laya-ml はどの書き方でも 16 場面すべてで attack を 1 位にし、筆者はこれを「ゲームの状況を読んだ結果というより、英語の11択の文面そのものへの偏り」と見る。
• 記憶はモデルの外に置き、4 つの版を経た。
  • 禁止だけ (死んだら、最後に地面にいたときの行動をその場所で禁止) では臆病になり、崖際で左右を行き来して時間切れが続いた。
  • 良い記憶 (8 手先までの x の伸びで前へ進めた行動を優先し、足場に立てたら +100、まだ試していない行動にボーナス、モデルの確率は探索の順番に使い、死んだら禁止もする) では崖を越えるようになったが、死の責任がかなり前の無関係な判断に付き、正解の右へジャンプまで禁止された。
  • 禁止なしは、危険を潜り抜けないと進めないゲームで危険な行動を禁止すると何もできなくなるため、禁止をやめた版。
  • 最終比較で使った軽い罰は、禁止はせず、死ぬ直前の 3 手の点を 50、25、12.5 下げる。
• カメラ追跡が一度外れたとき、世界座標が x=-4 → 186 → 425 と飛び、試走は穴を越えたと判定されたが、録画では左の樹海で死んでいた。
  • 記憶は「樹海へ跳ぶと大きく進める」と学び、5 回続けて樹海へ向かったため、判断の間に 100px 以上飛んだら打ち切る見張りを入れた。
• 「トゲの先は自機の足元より138px 下」と伝えると、崖際 (x 150〜186、接地) の判断は、右へジャンプの 36% (50 回中 18 回) から、何もしない 53% (233 回中 123 回) と攻撃 33% (77 回) に偏った (1 本ずつの比較)。
• トゲを読む版の目では、足場に乗った直後にその場でジャンプを選び、跳んでいる間に足場が横へ動いて、そのまま穴に落ちる回があった。
• 選択肢の呼び方を変えた試走は足場に 31 回乗ったが、同じ設定で回し直すと 2 回で、そのため最終比較はモデルごとに 3 本にした。
• 開発中の試走 (日本語、各 1 本) の結果を、回数 / 跳んで崖を離れた / 足場に乗った / 向こう岸 / 最高 x / 遅れ p50 / 1 位をそのまま実行の順に並べる。
  • laya-ml、禁止だけの記憶は 100 / 0 / — / 0 / 129 / 4 コマ / 対象外。
  • laya-ml、良い記憶の 1 回目は 100 / 0 / — / 0 / 186 / 4 / 76%。
  • laya-ml、良い記憶の調整後は 100 / 33 / — / 0 / 256 / 4 / 24%。
  • 同上・録画ありは 100 / 29 / 1 / 0 / 252 / 5 / 24%。
  • laya-ml、呼び方を変更は 100 / 72 / 31 / 0 / 381 / 5 / 46%。
  • 同上の回し直しは 100 / 64 / 2 / 0 / 360 / 6 / 33%。
  • laya-ml、禁止なしは 100 / 75 / 4 / 0 / 345 / 6 / 44%。
  • laya-ml、禁止なし＋トゲの目は 100 / 54 / 3 / 0 / 238 / 6 / 36%。
  • laya-ml、軽い罰は 100 / 67 / 20 / 1 / 397 / 6 / 30%。
  • laya-ml、モデルだけ (トゲの目あり) は 30 / 0 / — / 0 / 125 / 6 / 100%。
  • kev-4b、モデルだけ (ゴール明示) は 30 / 0 / — / 0 / 198 / 17 / 100%。
  • kev-4b、軽い罰 (ゴール明示) は 100 / 82 / 4 / 0 / 282 / 17 / 51%。
  • laya-ml、軽い罰 (ゴール明示) は 100 / 88 / 47 / 0 / 354 / 6 / 35%。
• 言葉の定義として、跳んで崖を離れたは崖の端より右で地面より高い位置にいた手がある回、足場に乗ったは録画の全コマで足場の上に 10 コマ以上続けて立っていた回、1 位をそのまま実行は 11 の選択肢がすべて残っている手のうち、記憶がモデルの 1 位を差し替えなかった手の割合。
  • kev-4b は英語のみのモデルなので、日本語の開発中の結果はその不利を含む。
• 11 択にしてから集計した 1,820 回のうち、向こう岸に着いたのは開発中の軽い罰の 1 回だけで、着地した直後に上から下りてきたトゲの板 (2 つ目の罠) に当たった。
• 最終比較は、条件と判定の規則を固め、結果を見る前に手元の git にコミットしてから回した (事前登録)。
  • 文章は両モデルとも英語 (kev-4b が英語のみのため) で、記憶は軽い罰、選択肢は 11 択、大ジャンプの呼び方は jump to the right。
  • 目的の文は Goal: reach the right edge of the screen and go on to the next stage. で、目は向こう岸の地面の位置も書く。
  • 各モデル 100 回 × 3 本と、記憶なし (モデルだけ) の対照を各 30 回とし、遅れは実測のまま、試走中は全コマを録画した。
  • 実行は POLICY=systemone ACTSET=v3 MEMORY=gain ALPHA=0.5 GAMMA=1.0 STATKEY=coarse GAIN=net NOBAN=1 SOFTPEN=50 STATE_V=4 GOAL_X=640 REC=1 REC_ALL=1 EP=100 STEPS=80 LANG_=en を設定して node run_play.mjs を走らせる。
• 最終比較 (各 100 回、1 本目 / 2 本目 / 3 本目) の結果は次のとおり。
  • kev-4b は、死亡 100 / 98 / 100、足場に乗った 1 / 3 / 14、向こう岸 0、遅れ p50 17 / 16 / 17 コマ、1 位をそのまま実行 60% / 52% / 64%。
  • laya-ml は、死亡 64 / 67 / 80、足場に乗った 23 / 0 / 0、向こう岸 0、遅れ p50 6 コマ、1 位をそのまま実行 57% / 62% / 43%。
  • 崖の外へ出たのは kev-4b が 98 / 96 / 99、laya-ml が 47 / 26 / 64 で、跳んで崖を離れたのは kev-4b が 94 / 90 / 88、laya-ml が 42 / 10 / 57。
  • 見失いは kev-4b が 0、laya-ml が 8 / 5 / 6 で、最高 x は kev-4b が 264 / 336 / 366、laya-ml が 312 / 229 / 238。
• 「向こう岸に着いた回は600回で0回でした」とし、足場に乗れた回は 3 本の範囲が重なるので、事前に決めた規則ではどちらが上とも言えないとする。
  • 足場の上に 20 コマ以上で数えると kev-4b が 1・3・13 回、laya-ml が 10・0・0 回で、結論は変わらない。
  • 崖の外へ出た回と死亡は範囲が重ならず、どちらも kev-4b のほうが多い。
  • 「3本対3本では、完全に分かれても順位の検定で p=0.10 にしかならず、もともと強い結論は出せない規模です」とする。
• 「kev-4b はとにかく右へ行きます」とし、100 回でほぼ 100 回死に、そのうち 96〜99 回は穴の中で、跳び方は小ジャンプが最も多い (全判断の 40〜47%)。
• laya-ml は全判断の 42〜61% が attack で、時間切れは 10〜21 回だけ、死んだ回の多くは穴の中 (25〜61 回) か、スタート地点の側 (19〜42 回、看板「←樹海」の付近で撃っていて爆発した回など) だった。
• 目は自機を 2 回続けて見失うと死亡と判定し、S の決めポーズでは自機の形が変わるため、laya-ml で死亡と数えた回のうち 7・8・4 回は、録画ではポーズを決めて生きていた (kev-4b は 0 回) ので、表の死亡は録画で数え直した値になっている。
  • この誤判定は記憶にも死んだとして入ってポーズに罰が付いており、「目の誤りが学習を汚す例です」とする。
• 記憶ありの条件でモデルの 1 位がそのまま実行されたのは 43〜64% の手で、「成績はモデルとハーネスの合作で、モデルの力とは切り分けられません」とする。
  • kev-4b の記憶ありは 300 回中 18 回足場に乗り、モデルだけは 30 回中 0 回だったが、記憶ありでも最初の 30 回では足場はほぼ出ないので、この対照だけでは差を言えない。
• kev-4b は崖の端から jump to the right を 3 本で 199 回選び、そこから 7 手以内に足場に乗れたのは 6 回 (3%) だった (判断の瞬間で数えた値)。
  • 事前に決めていた判断時の足場の位置ごとに分けると、足場の左端が 32〜63px 先でこちらへ動いているときは 181 回跳んで 0 回、64〜95px 先で向こうへ動いているときは 7 回跳んで 4 回、その他は 11 回跳んで 2 回乗れた。
  • kev-4b の遅れ (16〜17 コマ、目の約 60 ms とモデルの約 200 ms、録画の負荷) の間に、足場は 2,829 区間で測った中央値の 1 コマ約 2.0px で 32〜34px 動くので、目が見た位置は足場の幅 (55px) の 6 割ほど古くなる。
  • 筆者は「遅れが跳ぶ瞬間の選び方を狂わせている可能性はありますが、このデータでは確かめられていません」とする。
• 足場の先の罠は判断の一巡より速く、穴の底のトゲの床は約 12〜14 コマで足場より高くせり上がるのに、判断の一巡 (遅れと行動を押し続けるコマ数) は laya-ml で 13〜23 コマ、kev-4b で 23〜34 コマかかる。
  • 一巡の大部分を占める行動を押し続けるコマ数は、ハーネスの作りで決めたもので、モデルの性質ではないとする。
• 第 3 部の出発点は kanta13jp1 さんの Zenn の記事で、その記事はマリオ 1-1 を ROM なしで再現した自作ゲームに、画像ではなく内部状態を渡して、Jev 本体 (jev-1.13.0) を含む複数のモデルを試している。
  • ゲームを止めずに 60Hz で進める試験で、補助ありでは 4 系統すべてがクリアし、モデル単体ではどれもクリアできていない。
• 参考デモ fhshaik/typesafe-mario は、エミュレーターのメモリから JSON の状態 (自機の速度、ジャンプの段階、敵の予測位置、接触までのコマ数、計測した反応の遅れ) を作り、タイミングの計算を jump_must_start_this_decision までコードで行う。
  • 指示文と選択肢の説明にルールを書き、8 フレームごとに 3 つの質問 (次の操作、跳ぶべきか、危険度) を聞き、「ハーネスが操作を上書きする仕組みはない(README に明記)」。
• マリオの記事のハーネスは、ゲームの状態を複製した先読み探索と実行直前の安全確認を足しており、クラウドの Jev では 210 回の判断のうちモデルの案がそのまま採用されたのは 17 回で、187 回を探索が差し替えていた。
• 参考デモにはライセンスの記載がないので、筆者はコードを使わず、設計だけを人生オワタ2の最初の画面に合わせて書き直し、録画から 4 つの障害を見つけた。
  • 穴では、足場 (幅 55px) の左端が x 198〜320 を 1 コマ 2px で往復し、足場が覆うのは x 198〜375。
  • せり上がるトゲの床は、足場の上で x≥279 に来ると 1 コマで作動し、約 12 コマで足場より高くなり、足場に触れるだけでは作動しない。
  • 下りてくる板は、自機が x≥395 に入ると 9 コマ後に現れ、約 30 コマで x 423〜527 に下りて止まり、当たらずに待てるのは x 388〜399 の幅 11px だけで、下りた後は上に乗れる。
  • 画面の右端を越えると次の区画へスクロールし、床一面のトゲと浮いた足場 3 つが続く (ハーネスは未対応)。
• 跳び方は実測の軌跡から式にし、Z を押している間は最大 12 コマ、1 コマ 6.7px で上がり、減速は押したままなら 0.3、離すと 0.5、落下は 0.38、横は空中で 1 コマ 3px、地上で 2.73px で、頂点の高さ 131px と 95px に一致した。
  • 実際に押した操作の列どおりに 30 コマ先まで計算すると、接地面の一致はルールだけの試走で 92% (802 回中 734 回)、kev-4b の試走で 71% (1,291 回中 915 回) だった。
  • x の誤差の p90 は 7.6px と 8.2px で板の安全地帯 (11px) とほぼ同じ大きさで、高さの誤差の p90 は 20px と 107px で、kev-4b の試走は空中で跳び直す操作が多かった。
• 選択肢は、何もしない、右へ歩く、右へジャンプ、その場でジャンプ、左へ歩く、左へジャンプの 6 つで、それぞれに着地の予測が付く。
  • 状態には、自機の位置・速度・接地・ジャンプの段階、足場の位置と速度、2 つの罠の状態と作動の条件のほか、参考デモの期限にあたる「跳べる時間が今回で終わる」という事実も入れた。
  • 探索のおすすめは、8 コマごとに選ぶ操作の列を最大 7 段まで物理の式で試し、死なず、トゲの床を作動させず、いちばん先へ進める列の最初の一手で、マリオの記事の補助と違ってモデルの答えは差し替えない。
  • 予測と探索は全条件の 8,208 判断で p90 18 ms、最大 52 ms かかり、判断の遅れに含めた。
• 予測の不具合 (経過コマ数を 11 以下に丸めていて、減速中でも上昇が最大に戻っていた) を直すと、開発中のルールの試走で 5 コマ先の高さの誤差の p90 が 17px から 7px に減った。
  • ほかにも、速さを 3 コマの平均でならし、カメラ追跡では動く大きな物を隠して計算し、画面の右端で半分はみ出した自機を見失う問題を直した。
• 参考デモ方式の入力では kev-4b が遅くなり、試走中の判断の中央値は Mac で 1,216 ms だった。
  • 試走の状態 12 件 (状態の JSON は中央値で約 2,150 文字) では、参考デモ方式 (長い指示文・選択肢の説明・質問 3 つ) が 1,681 ms、長い指示文と説明で質問 1 つが 917 ms、短い指示・説明なし・質問 1 つが 552 ms だった。
  • 作り直した版 (状態は短い文章 1 つ) は、試走中の中央値で 99 ms。
• 最初の結果は、モデルではなくハーネスの入力のせいで壊れていた。
  • laya-ml について筆者は「選択肢の説明を48トークンで切り、質問と選択肢を合わせて192トークン、全体を512トークンで切り捨てる作りです(ライブラリの実装)」とし、説明の後ろに書いた予測が届いていなかったとする。
  • kev-4b は入力の長さは問題なかった (モデルカード上、学習時の状態は最大 7,552 トークン) が、右の岸へ渡るという目的の文と右へ進む結果を優先せよという指示に引っ張られた可能性が高いと見ており、複数の点を同時に変えたので切り分けはしていない。
• ゲームと関係のない単純な問題で、kev-4b は「DEATH: 右へ歩く」「SAFE: 何もしない」「DEATH: 右へジャンプ」から SAFE を確率 0.82 で選び、SAFE を先頭の別の選択肢に付け替えても 0.61 で選んだが、laya-ml はどちらでも 3 つ目 (DEATH) を選んだ。
• 作り直した入力では、状態を短い文章 1 つ (各選択肢は、判断の遅れまで考えたシミュレーターで SAFE か DEATH か判定済み) にして目的の文を外し、選択肢の先頭に SAFE / DEATH と探索のおすすめ (RECOMMENDED) を書いた。
  • 指示は「SAFE を選べ」「DEATH は選ぶな」「SAFE の中では RECOMMENDED を優先せよ」。
  • 試走で出た場面 47 件で、kev-4b は 47 件すべて (選択肢を逆順にしても 47 件) で SAFE を選び、laya-ml は 4 件、逆順で 15 件だった。
• 各 20 回の結果を、足場に乗った / 向こう岸 / 画面の右端 / 最高 x / 判断の遅れの中央値の順に並べる。
  • ルールだけ (モデルなし、探索のおすすめに従う) は 14 / 5 / 1 / 615 / 5 コマ。
  • kev-4b の参考デモ方式 (長い JSON＋ルール＋質問 3 つ) は 14 / 0 / 0 / 313 / 80 コマ。
  • kev-4b の選択肢に判定を付けた最初の版は 0 / 0 / 0 / 211 / 20 コマ。
  • laya-ml の選択肢に判定を付けた最初の版は 0 / 0 / 0 / 268 / 7 コマ。
  • kev-4b の選択肢に判定を付けた作り直した版は 6 / 0 / 0 / 309 / 11.5 コマ。
  • laya-ml の選択肢に判定を付けた作り直した版は 0 / 0 / 0 / 235 / 7 コマ。
• 参考デモ方式の kev-4b は 40 回の判断すべてで右へジャンプを選び、1 回のゲームで判断できたのは平均 2 回で、着地した x=313 は罠の作動位置 (x 279 以上) を越えていて、次の判断が間に合わなかった。
  • 20 回はほぼ 2 通り (足場で 14 回、穴で 6 回) の繰り返しだった。
• 作り直した版の kev-4b は、SAFE の選択肢があった 1,329 回すべてで SAFE を選び (残り 27 回は 6 つすべてが DEATH)、最も多いのはその場でジャンプ (876 回、うち 691 回は空中で横に動かず Z を押し続けるもの) だった。
• 作り直した版の laya-ml は、SAFE の選択肢があった 122 回のうち SAFE を選んだのは 18 回で、筆者は「この使い方には向いていません」とする。
• ルールとの比較は、はじめ公平でなかった: 選択肢の判定は着地まで押し続ける前提、探索は 8 コマごとに操作を変える前提で計算しているため、おすすめの 59% (1,329 回中 785 回) に DEATH の判定が付いていた。
  • 崖の手前の地面の 308 場面のうち 298 場面で右へジャンプが DEATH になり、DEATH を選ぶなと指示された kev-4b はほとんど右へ跳べず、一方でルールだけの版は判定を見ずに、DEATH の付いたおすすめに 179 回従って前へ進んでいた。
• kev-4b と同じ判定とおすすめを使う対照を、回数 / 足場に乗った / 向こう岸 / 画面の右端 / 最高 x / 判断の遅れの中央値の順に並べる。
  • kev-4b は 20 / 6 / 0 / 0 / 309 / 11.5 コマ。
  • SAFE を選択肢の並び順で選ぶルール (先頭は何もしない) は 14 / 0 / 0 / 0 / 163 / 6 コマで、14 回すべてが崖際で時間切れになった (30 分の実行上限で 14 回で止まった)。
  • SAFE を右へ進む操作から順に選ぶルールは 20 / 19 / 12 / 6 / 616 / 5 コマ。
  • 指示に「おすすめが SAFE でなければ右へ進む SAFE を優先(ゴールは右)」を足した kev-4b は 20 / 6 / 0 / 0 / 510 / 14 コマ。
  • 右から順に選ぶルールに kev-4b の応答時間 (144 ms) ぶんの遅れを足したものは 20 / 9 / 0 / 0 / 288 / 14 コマ。
• おすすめが SAFE だったとき、右優先のルールは作りどおり 732 回すべてで従い、kev-4b は 544 回中 304 回従った。
• 目的を足した kev-4b は、右へジャンプが判断の 13% から 22% に増え、時間切れが 4 回から 0 回に減ったが、20 回すべてで死に、SAFE の選択肢があった 413 判断はすべて SAFE を選んだ。
  • x=510 まで進んだ 1 回は、罠の作動位置で足場に降りた後に高く跳び、向こう岸の上空で、着地する前に下りてきた板に当たった。
• 筆者ははじめ kev-4b の失敗を選び方の問題と見ていたが、データは逆を示した。
  • kev-4b が崖の手前でその場でジャンプを選んだ 93 場面では、右へジャンプも右へ歩くも DEATH で、右へ進む SAFE はそもそもなく、同じ場面なら右優先のルールも 79 場面で同じ選択をした。
  • 空中で、右へ進んで足場か向こう岸に降りられる SAFE があった 59 判断では、kev-4b は 59 判断すべてでそれを選んでいた。
• 差は遅れで説明できる: ルールの遅れを kev-4b に合わせる (14 コマ) と、足場 19 回・向こう岸 12 回から 9 回・0 回に落ち、kev-4b の 6 回・0 回に近づいた。
  • 崖の手前の地面で右へ進む SAFE があった場面は、遅れ 5 コマのルールで 61 場面中 44 場面、144 ms を足すと 232 場面中 23 場面だった。
  • 空中で右へ進んで降りられる SAFE があった判断も 41% から 13% (kev-4b は 17%) に減り、このルールでもその場でジャンプが判断の半分を超えた。
  • 判断ごとに見ると、kev-4b の選択がルールと一致したのは 467 判断中 300 判断 (64%) で、SAFE のおすすめに従ったのは kev-4b が 193 回中 79 回、ルールはすべてだったが、遅れをそろえると成績の差 (足場 9/20 対 6/20) は偶然の範囲に入る。
  • 「この遅れでは右優先のルールでも渡れないので、どちらの選び方が良いかを見分ける力はこの対照にはありません」とする。
• 第 3 部の結論は、物理の計算、着地の予測、探索をコードが行い、入力を整えれば kev-4b は SAFE / DEATH の判定を読めたが、モデルに残った仕事 (SAFE の中からどれを選ぶか) で「右を優先する」の 1 行に勝る点は見えなかった、というもの。
  • その 1 行のルールはモデルの応答時間ぶん (144 ms) 遅らせるだけで向こう岸 12/20 が 0/20 になり、「モデルを挟むと、この遅れが必ず乗ります」とする。
  • 「事実とルールを渡そうとするほど入力が長くなり、そのぶん判断は古い画面に基づくことになります」とする。
  • 「System-1 モデルが要らないところまで System-1 モデルにやらせるのはやめよう、というのがこの第3部の結論です」と書く。
• 右優先のルールでも画面の右端に届いたのは 20 回中 6 回で、8 回は足場に乗った後に死に (1 回はせり上がったトゲの床、7 回は穴で、うち 5 回は足場の上で何もしないまま落ち、そのうち 3 回は足場に残ると予測していた)、6 回は時間切れ (4 回は板が下りて 6 つすべてが DEATH になったもの、2 回は板の手前の安全地帯で何もしないのおすすめに従い続けたもの) だった。
• クライアントの案件に当てはめる際は、System-1 モデルを提案する前に判断を 3 つに振り分けるよう勧める。
  • コードで計算できる (物理・タイミング・規則) もの、たとえば着地の予測、罠の作動条件、探索はコードに任せる。
  • 速さが要り規則で書き切れないものは System-1 モデルの候補だが、「今回の題材では切り出せなかった」。
  • 遅くてよく曖昧なもの、たとえば録画を見て死因を調べることは LLM や人に任せる。
• 「前作では、問い合わせの判定のような業務の分岐で、速い方式は4〜8割しか当たりませんでした」とし、今作は速さが必須の実時間の制御で、速いモデルの判断がそのまま成果にならなかったとする。
  • 現在の見立ては「System-1 モデルの速さが効くのは、規則で書き切れない曖昧さがあり、数十〜数百 ms の遅れが許され、間違えたときの損が小さい判断です」。
• PoC の合格条件として、次の 5 つを挙げる。
  • モデルを抜いた対照を、入力・制約・目的・遅れをそろえて置き、誰が決めたかを判断ごとに記録して、モデル単体の評価と仕組み全体の成績を分けて報告する。
  • 同じ設定で 3 回以上回す (足場に乗れた回が、回し直しで 31 回から 2 回に、最終比較の 3 本で 0〜23 回に揺れたため)。
  • 入力の上限と切り捨ての位置を試験する (laya-ml の 48、192、512 トークンでの切り捨てで、渡したはずの判定が届かなかったため)。
  • 文言や言語を変えたら回帰試験する (説明の文言だけで laya-ml の確率が 3.7 倍動き、英語では attack ばかり選んだため)。
  • 遅れの予算を対象の事象の速さと比べ、モデルより先に画面の取り込み (今回 55 ms) を測る (罠は 12〜14 コマでせり上がり、判断の一巡は 13〜34 コマだったため)。
• 「置き場所は、モデルの大きさと距離の掛け算です」とし、laya-ml 級の小さなモデルは画面のそばで動かすのが一番速く、kev-4b 級 (4B) は近いリージョンの GPU なら Mac より速く返る見込みだとする (東京は未計測)。
  • Azure でも、Azure Machine Learning のマネージド オンライン エンドポイントで同じく、GPU の枠とリージョンの近さが効くと付け加える。
• 筆者が結論を左右するとして挙げる限界は次のとおり。
  • 遊ばせたのは 1 面の最初の穴だけで、評価用にとっておいた 2 面以降には一度も進まず、計画にあった手書きのルールやランダムとの比較はやめた。
  • 最終比較は開発中の結果を見てから条件を固めた探索的な検証で、事前登録も手元の git へのコミットだけ。
  • ランダムな事前確率に同じ記憶を付けた対照がないので、モデルの確率が探索を助けたのか邪魔したのかは分けられていない。
  • 各モデル 3 本では強い結論は出ず、足場に乗れた回は 100 回の時点でもまだ増えていて、「0/600は『100回で』という条件付きの結果です」。
  • 第 3 部は各条件 20 回 (並び順で選ぶルールは 14 回) で、ハーネスは最初の画面専用、判定と探索の前提は食い違ったままで、加えた対照はどれも初稿への外部レビューの後に足したもの。
  • 遅れをそろえたルールは 144 ms を一律に足しただけで kev-4b のばらつきまでは再現せず (遅れの p10/p90 は kev-4b が 13/15 コマ、ルールが 14/15 コマ)、目的なしの kev-4b (遅れ 11.5 コマ) に合わせたルールは回しておらず、6 つすべてが DEATH のときにおすすめを選ぶ規則はルールにだけある。
• そのほかの限界として、次を挙げる。
  • 記憶の設定と 11 択は laya-ml の日本語の試走を見て決め、英語にそろえることは laya-ml の英語での挙動を試す前に決めた。
  • モデルだけの対照 2 本は、事前登録の 640 ではなく既定の 420 の GOAL_X で回っていたが、最高到達が 227 と 99 なので結果には影響しない。
  • 1 回の上限が判断 80 回なので、モデルによってゲームの時間と記憶の経験量が違い、1 本あたりの判断数は kev-4b が 827〜959 回、laya-ml が 1,696〜2,702 回。
  • 目の正解ラベルは 1 面・1 名の目視で、閾値も同じラベルで決め、ポーズ姿のコマは入っていないとみられ、足場に乗ったの判定は確かめていない足場の検出に頼っている。
  • 録画すると目は 46 ms から 60〜67 ms に、laya-ml は 22〜26 ms から 27〜30 ms に遅くなるので、速さの比較には第 1 部のベンチ (入力は日本語の文章) の数字を使うよう求める。
  • kev-4b のクラウドは米国だけ、Gemini 3.8 Flash は global だけで、Mac は M4 Max の 1 台、回線は 1 本、計測は 1 日。
• 記事中の数字は、試走のログ、ベンチの CSV、録画から集計スクリプト (第 1 部・第 2 部は report.py、第 3 部は bench/demo_summary.py) で出し直せ、手順は REPRODUCE.md にある。
• 最後に「補助を足して成功したら、モデルを抜いた対照で確かめる」ことを、いちばん持ち帰ってほしいこととして挙げる。

[A] ccie26302/zenn-code — owata2-system1-realtime: README, PREREGISTRATION.md, REPRODUCE.md and data/REPORT.md (2026-10-06 取得時点)

https://github.com/ccie26302/zenn-code/tree/main/owata2-system1-realtime / https://github.com/ccie26302/zenn-code/blob/main/owata2-system1-realtime/PREREGISTRATION.md / https://github.com/ccie26302/zenn-code/blob/main/owata2-system1-realtime/REPRODUCE.md

• リポジトリは MIT ライセンスで、筆者の Zenn の記事で使った測定コードと生データと説明され、最後の push は 2026-10-05。
• ゲームは作者の公式ページをそのまま開いて遊び、SWF、ゲーム画面、録画、お手本は含めず、ハーネスは広告・計測のリクエストを遮断しており、REPRODUCE.md はその理由を「作者の広告に無効な表示を積まないためです」とする。
• 事前登録のコミットは 2026-10-02 20:29:55 (条件の固定) と 20:40:02 (全本英語への変更) で、最終比較の最初の録画コマのファイル時刻は 20:40:34 だが、「コミットは手元の git なので、第三者が時刻を確かめられる形ではありません」とする。
• 事前登録は外部レビュー 3 本を受けたもので、主な指摘は次のとおり。
  • kev-4b のモデルカードは Languages: English なのに、日本語の文で使っていた。
  • 主比較が 1 本ずつだった。
  • モデルだけの対照の文がそろっていなかった。
  • 状態の文に「(止まって動いている)」の誤りがあった。
  • kev が足場に乗れない理由を遅れと書いたのは言い過ぎで、2 つのモデルは別の手順に収束していた。
  • kanta13jp1 さんの記事の紹介に誤りがあり、先方の補助ありのクリアは止めない条件で、Jev 本体 (jev-1.13.0) を使っていた。
• 計画では最初 laya-ml を日本語、kev-4b を英語にしていたが、モデルの差と言語の差が混ざるため、試走の前に全本を英語にそろえ、順番は A1, B1, C(kev), C(laya), A2, B2, A3, B3 とした。
• 事前登録は、遅れが足場の成否に効くかを仮説として扱い、同じ経路に絞った成功率と、判断時の足場の位置ごとの内訳で確かめるとしている。
• 記録された逸脱は、モデルだけの対照が GOAL_X 420 で回っていたことと、3 つの指標 (跳んで崖を離れた、録画の全コマで数えた足場に乗った、録画で確かめた死亡) を事後に足したこと。
• 要件は Apple Silicon の Mac、zsh、Node.js 24、Python 3.13、uv、ffmpeg で、zsh harness/chain_final.sh で最終比較全体が 10 時間前後で回る。
• リポジトリには表に使った 21 本分の試走のログ (data/play/<TAG>/episodes.jsonl) が入っているが、録画は入っておらず、録画すると目が約 15 ms 遅くなる。
• data/REPORT.md は最終比較の本ごとのモデルのレイテンシの p50 を加えており、kev-4b は 215、203、216 ms、laya-ml はどの本も 29 ms、目は 65〜66 ms。
  • モデルだけの対照では、kev-4b が 197 ms、laya-ml が 27 ms。
• 録画から数えた 25 回ごとの足場に乗った回は、laya-ml の 1 本目で 0、0、8、15、kev-4b の 3 本目で 0、3、5、6。
• 唯一の向こう岸は、開発中の試走 rt11_layaml_softpen_rec のエピソード 62。
• kev-4b の崖の端からの右へのジャンプを足場の位置のキーで分けると、1l が 181 回中 0、1r が 6 回中 0、1s が 1 回中 0、2l が 1 回中 0、2r が 7 回中 4、3r が 2 回中 1、4r が 1 回中 1。

[A] Jared Palmer — Introducing Kev (2026-10-01)

https://jaredpalmer.com/blog/introducing-kev

• Kev 1.0 は、0.8B から 27B パラメーターまでの 4 つのオープンソースの決定モデルのファミリー。
• そのインターフェースを、自分で動かしファインチューニングできる重みで使いたかったと動機を書く。
• Kev は同じ API を使うので、TypeSafe の SDK で作ったアプリケーションは、エンドポイントとモデル名を変えるだけで切り替えられる。
• Kev-4B は手元での利用とファインチューニングの出発点という位置づけで、L40S か 32 GB の Mac で動き、毎秒 51 リクエスト、100 万リクエストあたりの GPU の推定費用 $10.54、モデルの時間 42 ms。
• 32 GB の M5 では、短いテキストについての 5 つの質問に 721 ms、テキストがキャッシュされていれば 136 ms で答える。
• 文書は 1 回だけ処理され、各質問はほかの質問を見ずに、そのキャッシュした計算を使う。
• ファインチューニングから外した 14 の公開データセットで、偶然補正した指数は Kev-4B が 38.0、Kev-27B が 52.3。
• Kev-4B の較正誤差は、全体をまとめて 0.029、データセットごとの平均で 0.098。
• 誤り 5% を狙うしきい値で、Kev-4B は 31% を受け入れ、誤りは 3.5% だった。
• Kev-4B の開発中、ラベル付きの消費者の苦情 5,219 件で 1 回学習させると、取り置いた苦情での正解率が 80% から 90% に上がった。
• Kev-4B の小さなファインチューニングは GPU 時間で約 $1 で、kev-finetune と kev-deploy のスキル (後者は Modal にデプロイし、コールドスタートは約 35 秒) は Claude Code、Codex、Devin などのコーディングエージェントで使える。
• 答えの順序でも確率がわずかにずれうるとする。
• 小さい Kev は、約 7,500 トークンまでの文書で学習した。
• Jev の出力は使っていないとする。

[A] jaredpalmer/kev — Kev 1.0 release notes and the Kev-4B model card (2026-10-01、カードは 2026-10-06 取得時点)

https://github.com/jaredpalmer/kev/releases/tag/kev-1.0 / https://huggingface.co/jaredpalmer/kev-4b

• リポジトリは、Qwen3.5/3.8 の上に作り、自分で学習させて動かせる Jev 風の決定モデルのファミリーで、Apache-2.0、2026-09-17 に作られ、取得時点でスター 8,514、フォーク 561。
• 記事で使ったコミット 0fe8fc9 は 2026-09-29 のもので、Kev 1.0 のタグの 2 日前。
• Kev 1.0 は Kev のファミリー全体の最初のバージョン付きのリリースで、新たに学習させたものは含まない。
• 1.0 の Kev-4B はリビジョン 139fdd94 で、Qwen3.5-4B-Base 上の LoRA アダプターとヘッド、温度 2.41、検証済みのコンテキストは 8,192 トークンで、09-24 のファミリーのリリースと同じチェックポイント。
• カードは Kev-4B を、Qwen3.5-4B-Base 上の LoRA アダプターとポインターのヘッドで、24 GB の GPU 1 枚か 32 GB の Apple Silicon の Mac に収まる大きさだと説明する。
• アダプターは LoRA の rank 16、α 32 で、アテンション、MLP、DeltaNet の射影にかかる (33.8M パラメーター)。
• カードは Languages: English とし、英語以外の言語を対象外とする。
• 最大 65,536 トークンの状態を受け付けるが、学習時の状態は最大 7,552 トークンだった。
• choice は 1〜255 の名前付きの選択肢、score は 1〜255 の順序付きの段階を受け付ける。
• 各質問は共有の状態から続く独立した行として答えるので、質問どうしは影響し合えず、状態は 1 回だけ計算してキャッシュする。
• 配信時のモデルの時間 (CUDA、bf16、20 回の中央値、新しい状態 / 繰り返しの状態) は次のとおり。
  • L40S では、短い状態の 6 問で 41.5 / 27.7 ms、2,200 トークンの状態の 5 問で 145.2 / 43.0 ms、64 クライアントで毎秒 51.4 リクエスト。
  • H100 では、それぞれ 18.1 / 12.9 ms、89.4 / 22.5 ms、毎秒 100.8 リクエスト。
• 32 GB の M5 の MLX では、8,192 トークンの状態は新規で 6.6 s、キャッシュありで 354 ms かかり、MLX の経路は短い状態の 60 問で fp32 の評価の経路との差が 0.018 以内。
• Kev-4B と Jev の主な数値は、breadth-v1 の指数 38.0 対 54.0、transfer-v4 の開発セットの正解率 0.817 対 0.857、MMLU-Pro 0.565 対 0.840。
• 取り置いたデータセットでは、breadth-v1 の指数で Jev に 16 ポイント及ばない。
• 1 つの温度では確信度の順序を変えられないため、ドメイン外で誤り 5% 以下のカバー率は開発セットで 0.620 にとどまり、Jev の 0.70 に及ばない。
• Kev 1.0 は黙った切り詰めをやめ、以前のサーバーは上限より長い状態を知らせずに切っていたが、いまは 65,536 トークンを超える状態を 422 で拒む。
• 評価の監査で、TypeSafe の公開の評価 (2 つのクローズドなモデルから作った正解、少なすぎる問題数) を、モデル選びに適さないとして外した。
• uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b@v1.0 --port 8009 (CUDA か Apple Silicon の MLX) で動かし、TypeSafe の SDK は変更なしで動くとする。
• カードの先月のダウンロード数は 17,339。

[A] Convai Innovations — Laya model card on Hugging Face (2026-10-06 取得時点)

https://huggingface.co/convaiinnovations/laya

• Laya は、多言語で非自己回帰の System 1 の決定モデルで、100 以上の言語で 1 回の順伝播 (約 33 ms) で較正済みの確率を返し、RLCD で学習したとする。
• チェックポイントは、laya (ModernBERT-large、421M、512 トークン、英語)、laya-multilingual (mmBERT-base、322M、1024 (最大 8k)、約 2.2 倍速い)、laya-typed-decisions (421M、1,024 トークン)。
• laya (英語) の既定のコンテキストは 512 (head_max_len = 192、状態に約 320 トークン)。
• laya-multilingual と laya-typed-decisions の既定のコンテキストは 1,024 (head_max_len = 256、状態に約 768 トークン) で、mmBERT-base のエンコーダーは RoPE で最大 8,192 に対応する。
• 選択肢は head_max_len の予算を共有するので、77 の選択肢ではラベル 1 つに 3〜4 トークンしか使えず (Banking77 は 0.425、Jev は 0.870)、head_max_len は 512 まで上げられる。
• laya-multilingual は長い文書を切る 1,024 トークンの上限付きで配布され、4,000 トークンの入力は Apple の GPU で約 1.7 s かかる。
• T4 では、1 問が 39.5 ms (英語) と 32.8 ms (多言語)、10 問のバッチが 158.6 ms と 72.3 ms。
• ベースのチェックポイントは typed-decisions のゼロショットでほぼ偶然の水準で、0.362 (多言語は 0.352) に対し、ランダムは 0.318、多数派クラスのベースラインは 0.461 だとする。
• Laya は特化させるための速い土台であって、ゼロショットの判断エンジンではないとする。
• カードの先月のダウンロード数は 11,733。
• 多言語のチェックポイントの設定 (multilingual/rl_agent_config.json) は、jhu-clsp/mmBERT-base に max_len 1024、head_max_len 256 を設定している。
• laya 0.3.23 のコードは各選択肢の説明を 48 トークンに制限し (max_length=48)、設定にないときは max_len 512 と head_max_len 192 に戻る (https://github.com/NandhaKishorM/laya/blob/v0.3.23/laya/common.py、https://github.com/NandhaKishorM/laya/blob/v0.3.23/laya/agent.py)。

[A] ggml-org — New in llama.cpp: Decision Models, by Xuan-Son Nguyen and Victor Mustar (2026-10-02)

https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp

• llama.cpp の server が /v1/systemone エンドポイントで決定モデルに対応し、TypeSafe の Jev とともに導入された System One の形式に従う。
• 速度は NVIDIA RTX PRO 6000 1 枚で 1 問に答える時間の中央値で、Laya (421M、英語) が 5 ms、Kev-4B (4B、Qwen3.5-4B-Base、英語) が 12 ms。
• クイックスタートは llama serve -hf ggml-org/Kev-4B-GGUF。

[A] Google Cloud — Gemini Enterprise Agent Platform pricing (2026-10-06 取得時点)

https://cloud.google.com/vertex-ai/pricing

• G2 シリーズで g2-standard-8 を 1 時間あたり $0.98181 とし、表示は Iowa (us-central1) で、リージョンの中に Tokyo (asia-northeast1) もある。
• 予測をしなくても、エンドポイントにデプロイした各モデルに料金がかかるとする。

[B] DevelopersIO (Classmethod) — 判断特化型AI Jev互換のOSSモデル「Kev」を M4 Mac の MLX で動かし、4B の判定精度を試してみた (suzuki.ryo、2026-09-27、背景)

https://dev.classmethod.jp/articles/kev-oss-jev-compatible-mlx-mac/

• 環境は Mac mini (M4 Pro、メモリ 24GB)、macOS 27.0、uv 0.12.19、Python 3.13.15、mlx 0.32.2 / mlx-lm 0.31.3 で、kev-4b の release_date は 2026-09-24。
• 起動ログは serving jaredpalmer/kev-4b (...) on mps via mlx (bfloat16)。
• 同じ日本語のサポートチケットのリクエスト (担当部署、エスカレーション、怒りの度合い) での初回と 2 回目の応答時間は次のとおり。
  • Kev-0.8B は 205.7 ms と 45.0 ms で、footprint は 2.1G (peak 3.1G)。
  • Kev-4B は 1200.9 ms と 262.1 ms で、8.6G (15.6G)。
  • Kev-9B は 30244.8 ms と 483.0 ms で、17.4G (30.6G) で、peak は Mac の 24GB を超えた。
• AI-DLC の 11 の scope と none の 12 択で、明確な依頼 100 回での誤りは 0.8B が 23 (77%)、4B が 0 (100%)、9B が 1 (99%)、紛らわしい依頼 40 回では 20 (50%)、10 (75%)、12 (70%)。
• 依頼文だけを日本語にし (criteria と instructions は英語のまま)、「依頼文を日本語にしても 4B の誤り件数は英語と同じで、回答品質が大きく劣化することもありませんでした」とする。
• 「4B の応答時間は、M1 / Docker / CPU では 26〜93 秒でした」とする。

[C] Zenn (kanta13jp1) — Jevでマリオを操作できる？51msの紹介デモと日本からの実測・本番実装 (2026-09-20、09-22 更新、背景)

https://zenn.dev/kanta13jp1/articles/jev-realtime-use-cases-deep-dive

• X で 130 万回以上表示された Faadil Shaik 氏のデモでは Jev が初代スーパーマリオブラザーズを遊び、記事は「画面に表示された51msが、状態取得から入力適用までの全時間なのか、通信を含むのかは区別が必要です」と注意する。
• 日本の Windows の Edge から認証付きの中継で jev-1.13.0 を呼んだ試験 (2026-09-21 の 1 回) では、中央値でブラウザ往復 976.8 ms、中継サーバーから Jev への HTTP 往復 480.3 ms、状態取得から操作適用まで 972.4 ms だった。
  • 成功 5 件の回答はすべて right で、約 958 ms の待機の後に届いた回答もあり、「次の回答を待つ間の4フレームで衝突しています」とする。
• GitHub Actions の CPU でゲームを 60Hz のまま止めずに進めた試験 (各条件 1 回) では、4 系統すべてが探索の補助ありで約 21 秒で 1-1 をクリアし、モデル単体ではどれもクリアできなかった。
  • クラウド Jev＋探索は 21.18 秒でクリアし (モデル案の採用 17、探索による変更 187、応答なしで探索 6)、単体では x=306 でミスした。
  • LocalJev＋Qwen0.5B は 21.42 秒 (8 / 104 / 99) で、単体では 60 秒後も x=32 だった。
  • Jev 由来の LightGBM は 21.22 秒 (138 / 68 / 0) で、単体では x=295 でミスした。
  • Laya 英語 421M は 21.22 秒 (72 / 47 / 20) で、単体では x=314 でミスした。
• 探索単体でも 21.05 秒でクリアしているので、「この結果からモデルがクリアに不可欠だったとは言えません」とする。
• Laya の 5 応答のうち 4 応答は「状態入力が残り316トークンの枠で切り詰められています」とし、Laya の HTTP 往復の中央値は CPU で約 3.32 秒だった。

[A] Accenture Japan (有志) on Zenn — 文章を書かないJevをGoogle Cloudで作れるか (Shinya Koike、2026-09-23、背景)

https://zenn.dev/acntechjp/articles/zenn-jev-on-google-cloud

• 「判定と確率だけを返すAI『Jev』と同じものを Google Cloud で3方式作り、8,453試行で測った」とし、「確率を校正しても、人手なしで捌ける割合はほとんど増えなかった」とする。
• 「0.3〜0.7秒で返る速い方式は4〜8割しか当たらない」とし、「正確なのは思考ありの Gemini 3.8 Flash だけで、中央値3秒、コストは Jev 公称の約87倍」とする。
• 「判断の分かれる言い回しが5%混ざるだけで、人手なしで捌ける割合は76%→4%と崩れた（事後の分析）」とする。

メモ

• 1 人の実務者による測定で独立した再現はないが、コードと生のログ (21 本、MIT) は公開されており、録画、ゲームの素材、目のお手本は公開されていないので、お手本は自分の画面から作り直す必要がある。
• 記事の laya-ml の切り詰めの数値 (説明ごとに 48 トークン、質問と選択肢で 192、全体で 512) は英語のチェックポイントの既定値とライブラリのフォールバックに一致するが、Laya のカードと多言語のチェックポイントの設定は全体 1,024、質問と選択肢 256 としている。
  • 説明ごとの 48 トークンの上限は laya 0.3.23 のコードにあるが、筆者の実行でどちらの全体の予算が効いていたかは今回確かめていない。
  • kanta13jp1 さんのマリオの記事も Laya の切り詰め (残り 316 トークンの枠) に当たっており、どちらの予算であれ、選択肢の文が多いと laya-ml の上限はすぐ効く。
• kev-4b のレイテンシは構成に大きく左右され、数値は直接は比べられない。
  • M4 Max の MLX で日本語の 11 択の 1 問なら p50 200 ms (この記事) で、最終比較の実行では 203〜216 ms。
  • M4 Pro の MLX で 3 問の 2 回目の呼び出しなら 262.1 ms (DevelopersIO)。
  • M5 で 5 問なら新規 721 ms、キャッシュありで 136 ms (Jared Palmer)。
  • Vertex AI の L4 の PyTorch bf16 で GPU の推論 84.4 ms (この記事)、L40S で 6 問 41.5 ms (モデルカード)、Decision Index の RTX PRO 6000 で中央値 52.1 ms (https://huggingface.co/spaces/multimodalart/jev-decision-index)、llama.cpp の GGUF 版なら RTX PRO 6000 で 1 問 12 ms。
• ルールの遅れをそろえるのに使った 144 ms は、短い作り直した入力でゴールありの条件での kev-4b の応答時間の中央値で、11 択のベンチの 200 ms より低く、筆者は一律の遅れが kev-4b のばらつきを再現しないと注記している。
• kev-4b はカード上英語のみなので、日本語の開発中の試走では不利を負っていた。
  • DevelopersIO は、英語の criteria の 12 択のタスクで日本語の依頼が Kev-4B の誤りを増やさなかったとしており、ゲームの外での対照的なデータ点になる。
• ここで試した laya-ml (多言語、322M) は、Decision Index の Laya (指数 6.04、https://clef-evals.workers-ai-mle.workers.dev/data/leaderboard.json) や llama.cpp の Laya とは別物で、後者は英語の 421M のチェックポイント。
• kev-4b に使ったコミット (0fe8fc9、09-29) は Kev 1.0 (10-01) より前だが、リリースノートは Kev-4B の重みが 09-24 のリリースと同じだとしており、1.0 のサーバーの変更は 65,536 トークンを超える状態に関するもので、このゲームの入力よりはるかに大きい。
• 否定的な結果は、ゲーム専用のハーネスと報酬のもとで画面の入力から 1 つの穴をリアルタイムに制御した、1 本 100 回の範囲でのものであり、筆者の前作と DevelopersIO が測った業務の振り分けでの決定モデルの正確さについてはほとんど何も言わない。
• 遅れで負けが説明できるという結論は、外部レビューの後に足した対照、各条件 20 回、一律の遅れに拠っており、筆者自身がこの対照ではどちらの選び方が良いかを見分けられないとしている。
• kanta13jp1 さんのマリオの記事は、補助ありのクリアが探索によるもの (クラウド Jev の案の採用は 210 判断中 17) で、どのモデルも単体では失敗したことを独立に見つけており、この記事の第 3 部と一致する。
• 筆者の東京の見込み (100 ms 台前半) は計測しておらず、東京のクォータのエラーの原因も確かめていない。
• g2-standard-8 の 1 時間あたり約 0.98 ドルは、取得時点の料金ページの $0.98181 と一致し、月 720 ドルは常時稼働の 1 台を 730 時間とした値で、ほかの料金は含まない。
• Jev 本体は試していないので、同じハーネスで Jev がどうなるかはこの結果からはわからず、kanta13jp1 さんの日本のブラウザからの 1 回の試験は、中央値で中継から Jev まで 480.3 ms、エンドツーエンドで 976.8 ms だった。

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

• ccie26302/zenn-code を clone し、自分の Mac で kev-4b (MLX) と laya-ml (MPS) に bench/latency.py を走らせ、llama.cpp の /v1/systemone と ggml-org/Kev-4B-GGUF も加えて、200 ms のうちどれだけがランタイムによるものかを見る。
• UI の自動化、テストの自動化、監視での System-1 の PoC の前に、筆者の 5 つの合格条件 (入力・制約・目的・遅れをそろえたモデル抜きの対照、3 回以上の実行、切り詰めの試験、文言や言語を変えた後の回帰試験、取り込みを含めて事象の速さと比べた遅れの予算) を採り入れる。
• チームのエージェントのワークフローの 1 つで、判断をコード、System-1 の候補、LLM か人に振り分け、コードで計算できるものを除いた後に決定モデルが何を節約するかを見積もる。
• 長い選択肢の説明の末尾と状態の末尾に目印の語を置いて laya-multilingual の予算を探り、入れたバージョンで 512/192 と 1,024/256 のどちらが効くかを確かめる。
• 判断ごとに、最終的な選択をしたのがモデル、記憶、ルールのどれかを記録し、モデルの分担を仕組み全体の成功率と分けて報告する。
• 決定モデルを Vertex AI で動かす必要があるなら、まず asia-northeast1 の L4 推論のクォータを確かめ、ヘルス経路に /v1/models を使い、起動ログで on cuda を確かめ、常時稼働の g2-standard-8 1 台あたり月約 720 ドルを見込む。
• 補助付きのエージェントを評価するパターンとして、遅れをそろえた対照についての短い社内メモを書き、この記事の 12/20 から 0/20 への結果を例にする。

7. 🔑 クラスメソッドが、aws-vault を credential_process の背後に置き、1Password を MFA デバイスとしてだけ使うことで、ジャンプアカウントの運用下で平文のキーなしに Claude Code から AWS CLI を使えるようにした

• 見送り / 影響度 1 / 将来性 0 / 重要度 2 / 起点 10-05 / 種別: 検証・実践 / 領域: コーディングエージェント、セキュリティ・安全性。
• 候補になったフィード項目:
  • classmethod-claude-code 10-05 ジャンプアカウント運用下でAWS CLI（+ AIエージェント）の認証情報を安全に扱う
• 見送りの理由: 既知のパターンの上に組んだ再現できる設定で、エージェントに固有の発見は、1Password CLI のプラグインが aws をシェル関数でラップする方式は Claude Code が呼ぶ aws には届かないことと、aws login がジャンプアカウントの認証情報を平文でキャッシュすることの 2 つだけで、検索でもより広い議論は見つからなかった。

8. 💸 Simon Willison が、コーディングエージェントが有料のサービスを立ち上げるようになった今、従量課金のサービスには既定でハードな予算上限が要ると論じ、AWS の新しい支出上限と Google Cloud の支出キャップを例に挙げた

• 見送り / 影響度 1 / 将来性 1 / 重要度 1 / 起点 10-03 / 種別: 論考 / 領域: 評価・運用。
• 候補になったフィード項目:
  • simon-willison 10-04 We're going to need default hard budget caps on pretty much everything
• 見送りの理由: 新しい統制ではなく既定の在り方についての主張で、例の 2 つは 09-16 に発表されてまだ限られた顧客にしか届いていない新規アカウントのプロジェクト向けの AWS の月次の支出上限と、7 月からの Google Cloud の Spend Caps であり、検索ではコーディングエージェントの予算の統制についての記事がほかにも見つかったが、新たに設定できるものはなかった。

9. 🐦 Aleph Alpha がアクティブパラメーター 3.46B のドイツ語と英語のオープンウェイトの MoE モデル Kolibri を公開し、その設計を解説した実務者の記事が Hacker News で 420 ポイントを集めた

• 見送り / 影響度 1 / 将来性 1 / 重要度 1 / 起点 10-03 / 種別: リリース / 領域: モデル。
• 候補になったフィード項目:
  • hn-llm 10-03 Aleph Alpha Kolibri: How the sovereign German LLM works
• 見送りの理由: 設計の考え方 (筆者の数えで法律のドイツ語を o200k_base より 15% 少ないトークンで表せたトークナイザー、1,048,576 トークンまで検証したスライディングウィンドウのアテンション、わからないと答えるための学習) はよく説明されているが、読者はこのモデルを日本語に使うことも、その学習を再現することもできない。

10. 🔨 t-wada が、生成されるコードに人間の確認が追いつかないとして、上流の仕様レビューから継続的な理解の形成まで、コードレビューを 5 つの実践に解体することを提案した

• 見送り / 影響度 1 / 将来性 1 / 重要度 1 / 起点 10-05 / 種別: 論考 / 領域: コーディングエージェント。
• 候補になったフィード項目:
  • hatena-llm 10-05 AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え
• 見送りの理由: レビューの役割を、上流の仕様レビュー、テスト駆動開発、型システムと制約によるガードレール、ビジネスの影響度に基づくリスクマッピング、継続的な理解の形成に分け、認知の負債に注意を促すインタビューで、新しいデータも再現できる設定もない。

11. ⏰ ラクスが、ラベル付きの issue を 1 件選び、複数のリポジトリを横断して文脈を集めて実装し、AI のレビュー付きのドラフトのプルリクエストを開く Claude Code のルーティンを 1 時間ごとに動かしている

• 見送り / 影響度 1 / 将来性 1 / 重要度 1 / 起点 10-05 / 種別: 検証・実践 / 領域: コーディングエージェント。
• 候補になったフィード項目:
  • hatena-claude-code 10-05 Claude Codeのルーティンを利用した開発フローの自動化 - RAKUS Developers Blog
• 見送りの理由: ルーティンは設計の規則 (担当者とラベルによる機械的に確かめられる選定、1 回の実行で 1 件、ほかのリポジトリへの索引になるリポジトリ) で説明されているが、プロンプト、設定、結果は示されていない。

12. 📎 その他の単発項目

• 見送り / 1 件ずつ採点し、影響度 0〜1、将来性 0〜1、重要度 0〜1。
• hn-claude-code 10-04 Anthropic の Getting the most out of Opus 5.5 in Claude and Claude Code は、ローンチ当日 (09-22) に公開されて 2026-09-27 のトピック 1 を補う手引きで、Hacker News で 239 ポイント、159 コメントを集めた。
  • 完了の姿を言葉にすること、慎重に考えるよう求める行を消すこと、止まって尋ねるべきときの規則を CLAUDE.md に書くこと、タスクの一覧を TASKS.md のようなファイルに置くこと、避けるべき設計のパターンを並べることを勧める。
• classmethod-claude-code 10-03 2026-10-03 のトピック 1 で扱ったリリース v2.1.288 の /code-review --max-findings の検証と、Orca で多数の Claude Code のセッションを整理する DevelopersIO 2026 Osaka の登壇。
• zenn-trending 10-05 3 つの Claude Mods を試し、入れる前に mod を点検する手順を示す記事 (2026-10-03 のトピック 1 の続報)、GraphRAG をゼロから説明する記事、AI が作業をするときに人はまだ何かを判断しているのかを問うエッセイ。
• laiso-newsletter 10-05 Anthropic のコミュニティプラグインの ELI5 (08-21 に紹介)、Archify、Explainer の 3 つの説明スキルの比較で、大半は会員限定であり、導入部はトピック 5 で引いた。
• hatena-llm 10-03 voluntas の 10 月上旬の LLM の使い方で、全員向けに DeepSeek V4.1 Flash と GLM 5.3 Flash を使う月 $500 の Ollama Cloud の Team プランに、Cursor と Codex を加えたもの。
• hn-llm 10-03 2 ビットのルーティングされたエキスパートで DeepSeek V4 Flash を 96〜128 GB のマシンで動かす antirez の C の推論エンジン DwarfStar 4 (ds4) で、ローカルのサーバーとコーディングエージェントが付き、5 月から公開されており、投稿は新しいサイトを示していた (362 ポイント)。
• aws-whats-new 10-05 推論、指示への追従、ツール呼び出しの改善を数値なしでうたう音声対音声のモデル Amazon Nova 2.5 Sonic で、価格は Nova 2 Sonic と同じ、東京を含む 4 つのリージョンで使え、あわせて Strands Bidi Agents が一般提供になった。
• aws-ml-blog-bedrock 10-06 Bedrock Managed Knowledge Base での AgenticRetrieveStream による LangChain とのエージェント的な検索をトレースとコストで Retrieve と比べたもの (既存の機能のチュートリアル)、Strands のサプライチェーンの例での AgentCore Evaluations によるマルチエージェントの評価、Z.ai が先に出した GLM 5.3 の Bedrock での提供と Strix によるセキュリティテストの手順、AWS GovCloud (US) での Claude Opus 5.5 と Sonnet 5.5 と Claude Code。
• kiro-changelog 10-05 Kiro Workflows (2026-10-01 のトピック 17) へのパッチにあたる IDE 1.2.37 で、macOS と Linux でのローカルの状態へのアクセスの厳格化、中断をまたいで完了した作業を残すこと、effort の制御と組み合わせたモデルの検索を含む。
• gcp-agent-platform-release-notes 10-05 CodeMender v0.12.0 で、.github/ や .config/ のようなフォルダーも走査する --include-hidden と、より大きなファイルへの対応。
• publickey 10-05 State of Devs 2026 で、回答者の 49% がコードの 75% 以上を AI に書かせ、9% はまったく書かせていない。
• martin-fowler 10-05 エージェントがコードを書くときにコードは読みやすくあるべきかについての断章で、Geoffrey Huntley、Sam Ruby、Unmesh Joshi を引く (意見、トピック 5 で引用)。
• ainews 10-03 静かな日の号で、ローカルの決定モデルのための llama.cpp の /v1/systemone エンドポイントと GGUF 版の Kev-4B、pplx-decider-v1-27b が Jev を上回るという Perplexity の主張、DeepSeek Harness のデスクトップ版、T3 Code のオーケストレーターの書き直しを扱い、Clef と Sandbox SDK の項目はトピック 2 と 3 で引いた。

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

• openai-news 10-05 ChatGPT の新しいビジュアル広告の形式と計測のツール (広告)。
• aws-whats-new 10-06 CI/CD のパイプラインで使う AWS Continuum for Penetration Testing のパブリックプレビュー (2026-10-03 と同じく、クラウドの運用のための AI セキュリティのサービス)。
• publickey 10-05 Supabase による Turso の買収 (買収)。
• hatena-llm 10-03 プロダクトマネージャーの仕事を AI が担うことについての投稿、10-05 Adobe 風の 7 つのアプリケーションをオープンソースの Rust で作り直した Crafting Apps (デザインのソフトウェア)、10-05 学習データとしての有償の人の文章についてのスレッド。
• zenn-trending データエンジニアリングの副業、JSON の実装どうしの違い、Azure 上の Dify のログのために nginx を OpenResty に置き換える話、Remix 3、Pod がないときの Traefik のメンテナンスページ、EC2 のキャパシティ予約。