デイリーAIダイジェスト — 2026-11-03

公開

2026年11月3日

English · 日本語

arXiv ハイライト

Wave Forcing: ストリーミング動画生成における光速に向けて

問題

ストリーミング長尺動画 diffusion 生成は、チャンク単位の自己回帰実行がボトルネックとなっています。新たなチャンクはそれぞれ、前のチャンクのデノイジングが完了し、K/V ヒストリキャッシュが更新されるまで待機する必要があり、1ステップ蒸留の極限においても1チャンクあたり2回の直列 forward pass が発生します。Rolling Forcing（RF）はこれらのステージを部分的にオーバーラップさせますが、逆方向依存関係を課します。すなわち、よりノイズの多いチャンクの K/V が「reverse refinement」マスクを介してよりクリーンなチャンクに影響を与えるため、パイプラインが結合され並行性が制限されます。また、ロールアウトが長くなるにつれ品質の低下とカメラドリフトが生じます。本論文は、パイプラインのフィル後に1回の並行 forward ラウンドで1つの出力チャンクが出力される極限（1F1C）を目標としつつ、マルチステップデノイジングの品質を保持することを目指します。

手法

Wave Forcing（WF）は、(i) 因果的 attention マスク、(ii) 3段階の学習レシピ、(iii) K/V の配送を計算とオーバーラップさせるランタイム（WaveRT）の協調設計です。

因果的ウェーブフロント。 Z_i^{(s)} をデノイジングステージ s \in \{0,\dots,S-1\} におけるチャンク i とします。ラウンド k において、セル (i,s) は対角関係 k = i + s, \quad i = k - s に従って Z_i^{(s)} \to Z_i^{(s+1)} を更新します。(k-S, S) における専用のストアステージが、完了したばかりのチャンクの K/V キャッシュを更新します。ラウンド k におけるアクティブ集合は \mathcal{A}_k = \{s : 0 \le s < S,\ 0 \le k - s < N_{\text{chunk}}\} です。WF attention マスクはチャンク順序に対して厳密に因果的です： M_{\text{WF}}(s, j) = \mathbf{1}[j \ge s], \quad s, j \in \mathcal{A}_k, すなわちステージ s のクエリは、同等またはよりクリーンな前段（まず自身、次に j > s）のみに attention します。i' = k - j \le k - s = i のマッピングにより、これはチャンクインデックスにおける下三角マスクとなります。重要なのは、よりノイズの多いチャンクからよりクリーンなチャンクへのエッジが存在しない点です。RF の reverse-refinement エッジが取り除かれることで、ロックステップ実行を強制する依存関係が解消されます。

ステージ s における層ごとのコンテキストは次のように構成されます： \mathcal{C}_{k,s}^{\text{WF},\ell} = A_k^\ell \oplus H_k^\ell \oplus U_k^\ell \oplus \bigoplus_{\substack{j \in \mathcal{A}_k \\ j \ge s}} (K_{k,j}^\ell, V_{k,j}^\ell), 初期チャンクアンカー A、有界なクリーンヒストリ H、ライブストアスロット U、および順序付きデノイジング K/V（まず自身、次によりクリーンなステージ）を連結します。ストアエントリは一度だけ現れ、非アクティブ時は空となり、ラウンド完了後にヒストリへ移動します。

学習。 推論時にモデルは混合ノイズコンテキストを参照します（あるチャンクのクエリステージは、完全にデノイズされたヒストリを含む、厳密によりクリーンなステージの前段に attention する）。そのため、ベースとなる DiT を適応させる必要があります。著者らは3つの連続したステージを提案します：(1) 混合ノイズデノイジングにより、WF コンテキスト分布にモデルを露出させる；(2) モーション教師あり学習により、よりクリーンな条件付けのみで学習した場合に生じる動的度の崩壊を抑制する；(3) 自己生成ヒストリを用いた因果的適応により、ロールアウト時の exposure-bias ギャップを埋める。この適応なしでは、短尺動画の品質と Dynamic Degree の両方が劣化します（Sec. 5.1）。

Wave Runtime。 各デノイジングステージ s とストアは、フルモデルの GPU レプリカを保有します。あるラウンドにおいて、P_{s,\ell} をレイヤー \ell における Q/K/V + RoPE 射影、C_{s,\ell} を attention とリジデュアル MLP とします。依存関係は次の通りです： P_{s,\ell} \to C_{s,\ell}, \quad C_{s,\ell} \to P_{s,\ell+1}\ (\ell < L), \quad P_{j,\ell} \to C_{s,\ell}\ \text{for}\ j > s. ローカルの射影はリモートの K/V を待たずに実行され、attention はよりクリーンなランクの K/V がすべて到着するまでのみ停止します。Wave Parallelism（WP）は、P_{j,\ell} が完了した直後に所有レプリカから K/V を公開し、受信側スロットへ直接書き込んだ後に準備完了シグナルを送ります。これにより、後続の待機がよりクリーンな（処理が速く進む）プロデューサ側の計算の背後に隠蔽されます。初期パイプラインフィルにはやむを得ない1回の待機が発生しますが、後続ラウンドではオーバーラップします。実装には SGLang Diffusion を実行バックエンドとして使用します。

結果

報告された定性的比較では、4および5デノイジングステップの WF が、時間的一貫性と動的モーションにおいて Causal Forcing および Rolling Forcing と同等またはそれを上回ることが示されています。

Causal Forcing、Rolling Forcing、4/5ステップ Wave Forcing の定性的比較。

学習アブレーションにより、3つの適応ステージそれぞれの必要性が確認されています。モーション教師あり学習を除去すると Dynamic Degree が崩壊し、自己生成ヒストリに対する因果的適応を除去すると、長いロールアウトにわたってドリフトアーティファクトが発生します。

4ステップフルモデルにおける学習アブレーション。

1F1C の特性により、S ラウンドのフィル後、スループットは S に依存せず1回の並行 forward pass あたり1チャンクとなります。これが本論文の中心的なシステム上の主張であり、レイテンシのためにGPU（ステージごとに1レプリカ＋ストア）をトレードオフするものです。

制限

WP には固定ステップのスケーリング上限があります。並行性は S+1 レプリカに制限されるため、デノイジングの深さを線形にスケールするとハードウェアも線形にスケールします。著者らは、WP をより細粒度の実行および context parallelism と組み合わせることを今後の課題として挙げています。学習レシピは依然として3段階であり非自明です。モーションと長期安定性を保持しながらこれを簡略化することは未解決の問題です。バランスの取れた DiT/VAE リソース配分のための VAE デコーダ、転送、キュー、バックプレッシャーのエンドツーエンドプロファイリングは将来の課題とされています。また、抜粋された節では標準ベンチマークテーブルが報告されていないため、定量的な FVD/VBench の数値はここでは得られません。

なぜ重要か

Wave Forcing は、ローリングウィンドウストリーミング diffusion における reverse K/V エッジが、マルチステップデノイジングが1チャンクあたり1 forward pass のスループットに到達できない構造的な原因であることを特定し、厳密に因果的なウェーブフロントマスクと対応する学習によってそれを除去します。1F1C の主張が完全なベンチマーク下で成立するならば、固定されたデノイジング深度におけるストリーミング動画 diffusion のスループット上限、すなわちタイトルにある「光速」を具体的に確立することになります。

Source: https://arxiv.org/abs/2611.00859

CrossSWE: コーディングエージェントのクロスリポジトリ共同開発のベンチマーク

問題

既存のエージェント型コーディングベンチマーク（SWE-benchおよびその後継）は、単一リポジトリに限定されたissueの解決を測定するものです。実際のソフトウェア進化では、相互依存する複数のリポジトリにわたる協調的な編集が頻繁に求められます。たとえば、サーバーライブラリのプロトコルを変更すると、その上に構築されたクライアント、プラグイン、またはゲートウェイにも対応する変更が必要になります。単一リポジトリのベンチマークでは、エージェントが(a)関連する対応リポジトリを特定し、(b)インターフェースの一貫性を保ちながらセマンティックな変更を伝播させ、(c)どちらか一方に手を加えなければ失敗するクロスリポジトリのテストを満たせるかどうかを測定することができません。CrossSWEは、単一コードベース内でタスクの長さをスケールアップするのではなく、まさにこの難易度の軸をターゲットとしています。

単一リポジトリのSWEタスクとクロスリポジトリのSWEタスクの比較。

ベンチマークの構築とタスクの定式化

CrossSWEは165のリポジトリ、20の技術ドメイン、13のプログラミング言語にわたる171インスタンスを含んでいます。各インスタンスは以下のタプルで構成されています。

  1. ベースコミット時点での2つ以上のリポジトリと全依存関係がインストールされた事前設定済み環境。
  2. 意図された動作が複数のリポジトリにまたがる、単一の自然言語による問題文。
  3. 新しいクロスリポジトリの動作と既存動作の保持の両方を検証するテストスイート。
  4. 元の協調的な修正を反映したリポジトリ固有のゴールドパッチ。

主要な検証基準は協調の必要性です。著者らは、リポジトリの一部にのみゴールドパッチを適用するとテストスイートが失敗することを確認しており、部分的なリポジトリの解決策では合格できません。これが、CrossSWEを独立したタスクを単純に複数リポジトリにまとめたものと区別する構造的な特性です。

oauth2-proxyとHigressを含むクロスリポジトリ共同開発の実際の例。

代表的なインスタンスでは、oauth2-proxyとHigress APIゲートウェイを組み合わせています。プロキシ側のトークン処理のセマンティクスを変更しても、それを利用するゲートウェイプラグインが同時に更新されなければ観察可能にはなりません。エージェントは依存関係の方向を推論し、両側を一貫して修正しなければなりません。

CrossSWEベンチマーク構築フレームワークの概要。

実験設定

すべてのエージェントは固定のscaffoldを共有しています。mini-SWE-agent v2.4.6は、モデルがマウントされたリポジトリをまたいでファイルを検査・編集し、テストを実行するシェルインタラクションループです。各実行は300インタラクションステップおよびモデルへの支出$10を上限とし、評価された5つのフロンティアモデル（GPT-6.1 Sol、Claude Sonnet 5.5、DeepSeek V4.1 Flash、GLM-5.3 Flash、Qwen3.8-Flash-Next）すべてに対して「high」な推論努力を設定しています。評価指標は完全なテストスイートのもとでのPass@1です。

結果

最強のシステムであるGPT-6.1 Solでも58.48%のPass@1にとどまり、単一リポジトリのDeepSWE v1.1ベンチマークで報告されている75.2%を大きく下回っています。モデル間の順序は以下の通りです。

  • GPT-6.1 Sol: 58.48%
  • DeepSeek V4.1 Flash: 52.63%
  • Claude Sonnet 5.5: 50.29%
  • Qwen3.8-Flash-Next: 45.03%
  • GLM-5.3 Flash: 43.86%

言語設定別に分けると、GPT-6.1 Solは単一言語インスタンスで60.34%を記録しますが、タスクが言語の境界をまたぐ場合（例：Goのゲートウェイ＋Pythonのクライアント）には54.55%に低下します。DeepSeek V4.1 Flashは言語境界をまたいでも52.73%と異例の安定性を示しており、クロス言語のコード理解が全体スコアと必ずしも相関しない独立した能力軸であることを示唆しています。

コスト・効率のプロファイルも示唆に富んでいます。GPT-6.1 Solはインスタンスあたり平均$0.3496、32.9インタラクションステップを使用し、Claude Sonnet 5.5は29.2ステップと同程度です。DeepSeek V4.1 Flash、GLM-5.3 Flash、Qwen3.8-Flash-Nextは平均してそれぞれ152.7、141.7、182.1ステップを使用します。トークンあたりの価格が高いにもかかわらず、クローズドソースモデルははるかに早期に終了するためコスト競争力を保っており、このベンチマークではエージェント的なコストを左右するのはトークンの生の価格ではなく軌跡の効率性であることが示唆されます。

論文では、失敗の44.2%がクロスリポジトリの不整合に起因すると報告されています。エージェントが一方を正しく編集しても、対応する側を共有インターフェースまたはプロトコルに違反した状態のままにしてしまうものです。これが最も多い失敗モードであり、ローカルなコード生成ではなく協調的な変更の伝播が拘束的な制約であることを裏付けています。

限界と未解決の問題

  • 171インスタンスは少数であり、（言語別、ドメイン別の）サブグループ分割は統計的に薄くなっています。
  • 評価されたscaffoldは1つ（mini-SWE-agent）のみです。クロスリポジトリの依存関係グラフを明示的にモデル化したり、複数のリポジトリにわたるretrievalを使用するエージェントアーキテクチャは、状況を大きく変える可能性があります。
  • 300ステップ/$10の上限が長い軌跡を持つモデルを打ち切ってしまうため、Qwen/GLMのギャップがどの程度能力の問題でどの程度予算の問題であるかが明確ではありません。
  • 「協調の必要性」は部分パッチのテストによって検証されていますが、ベンチマークはインスタンスごとに編集が必要なリポジトリの最小数を定量化しておらず、有用な難易度軸となりうるものが欠けています。
  • 165の公開リポジトリに対するトレーニングデータ汚染の分析が報告されておらず、ベースコミットがGitHubから取得されている場合の標準的な懸念事項となっています。

なぜ重要か

単一リポジトリのSWEベンチマークは飽和しつつあり、コーディングエージェントにとっての次の現実的なボトルネック—相互依存するコードベース間での依存関係の推論—こそがCrossSWEが切り出しているものです。最強のモデルがDeepSWE v1.1からCrossSWEへ約17ポイント低下し、失敗の44.2%がクロスリポジトリの不整合に結びついているという事実は、現在のエージェントが主にローカルな編集者として動作しており、グローバルなインターフェースの一貫性を維持するメカニズムを欠いていることを示しています。

Source: https://arxiv.org/abs/2611.01484

FLAMIA: Blackwell上での高速かつ因果的に安全なトレーニングのためのFLAsh MIcroscaling Attention

問題

長いコンテキストにおけるattentionのトレーニングはmatmulのスループットに支配されており、BlackwellはBF16に対してFP8/FP4テンソルコアで大幅な性能向上をもたらします。これらの向上をエンドツーエンドの因果的・パックドドキュメントトレーニングのスピードアップに変換することは容易ではありません。その理由は以下の通りです：(i) 6つの論理的なattentionオペランド（\mathbf{Q},\mathbf{K},\mathbf{V},\mathbf{P},\mathbf{dO},\mathbf{dS}）はそれぞれ異なる縮約軸を持つ2つの積に関与しており、量子化されたコピーの重複またはレイアウト調整が強いられます；(ii) トークン境界をまたぐスケールグループは、共有スケールを通じて将来のトークンの情報を現在のトークンに漏洩させ、因果性を破壊します；(iii) 量子化の方法が異なるforwardとbackwardパスが数値的なドリフトを引き起こし、長いpretrainingの実行中に蓄積されます。FLAMIAは、B200/B300上でMXFP8および混合NVFP4/FP8に対してこれら3つの問題すべてに対処するカーネルファミリーです。

手法

コア設計の決定は、attentionの双対縮約構造に合わせたトークンブロックスケーリングレイアウトです。MXFP8では、1つの2の冪の指数が32個の連続したトークンとオペランドのフルヘッド次元dにわたって共有されます。指数が32\times dブロック内で一定であるため、量子化されたペイロードは転置後も有効なままです：同じコードとスケールが、一方の縮約ではK-major MMAに、もう一方ではMN-major MMAに使用されます。Blackwellでは8ビットMMAが両方の方向を受け付けるため、\mathbf{Q},\mathbf{K},\mathbf{V},\mathbf{dO}の単一のE4M3表現が、再量子化された転置コピーなしにforwardとbackward両方の積に関与できます。\mathbf{dQ}においてキーに沿って縮約され、\mathbf{dK}においてクエリに沿って縮約される\mathbf{dS}は、両方向で共通指数の不変条件が保持されるよう32\times 32の正方ブロックで処理されます。

混合パスでは、\mathbf{Q}と\mathbf{K}はさらにトークンごとに16ヘッド次元要素あたり1つのスケールを持つNVFP4表現を持ちます。この表現は、ヘッド次元縮約を共有するforwardスコア計算\mathbf{S}=\mathbf{Q}\mathbf{K}^\topとbackwardスコア再計算の両方に使用されます。4ビットパスはK-majorレイアウトを必要とするため、NVFMは自然にその制約が満たされる積に限定されます；残り4つの積（\mathbf{PV}、\mathbf{dP}、\mathbf{dV}、\mathbf{dS}を経由した\mathbf{dQ}/\mathbf{dK}）はE4M3のままです。\mathbf{Q}と\mathbf{K}はそれぞれNVFP4とE4M3の両方の表現を持ち、\mathbf{V}と\mathbf{dO}は単一コピーのE4M3のままです。

因果的安全性はブロックレイアウトから導かれます：単一の指数が32\times dトークンブロック全体を支配するため、forwardまたはbackward計算内でスケールがドキュメント境界をまたぐことはなく、ドキュメントローカルスケーリングとワークロード対応スケジューリングにより、再パッキングなしで可変長パックドレイアウトを処理します。forwardとbackwardは縮約軸が許す限り同じ量子化オペランドを使用するため、2つのパス間でgradientと活性化の統計が一貫して保たれます。

量子化はattentionエピローグと融合されており、メモリバウンドな指数削減パスが個別に償却されません。これは重要です。なぜなら、双対縮約を持つ6つのオペランドに対してナイーブな方向別再量子化を行うとコストが支配的になるからです。

結果

表1は、16ヘッドおよびd=128の因果的パックドドキュメントにおける（量子化を含む）combined forward+backward attentionを報告しています。B200上でMXFP8パスは、長い均一形状（4\times 4096および16\times 4096ドキュメント）において1079–1095 TFLOP/sに達し、各ワークロードにおいて評価された最速ベースラインに対して1.10–1.40\timesのスピードアップを実現しています。最大の向上である1.40\timesは、ベースラインスケジューラが多くの短いドキュメントを処理するのが苦手な歪んだ8192+224\times 256ミックスで得られています（FA4 BF16: 6.71 ms vs FLAMIA MXFP8: 1.80 ms）。B300では1.06–1.42\timesの範囲であり、同じ歪んだミックスワークロードが再びトップとなっています（1.67 ms vs FA4 BF16の2.37 ms）。NVFP4はこれらのエンドツーエンドの呼び出しでMXFP8とわずか数パーセントの差に留まっており（例：B200上の4\times 4096で0.92 ms vs 0.89 ms）、トレーニングにおいてはbackwardのE4M3積が支配的であり、4ビットforwardの節約が完全には伝播しないことが示唆されます。

forward専用の数値（表2）は4ビットに対してより有利です：B200上の4\times 4096では、FLAMIA MXFP8 forwardは1616 TFLOP/sで0.17 msであり、cuDNN FP8の0.24 ms、FA4 FP8およびFlashInferバックエンドの0.25–0.27 msと比べて優れています；最速ベースラインに対するスピードアップは64\times 1024で1.42\timesに達します。GQAのログは、いくつかのベースライン（Low Precision FA4、nested-tensor SDPA）がGQAサポートを完全に欠いている場合でも競争力を維持しています。

限界

報告された向上はd=128と16ヘッドを持つパックドドキュメントの因果的ワークロードに依存しており、他のヘッド次元やスパース/スライディングマスクでの挙動は示されていません。混合パスは依然として\mathbf{Q},\mathbf{K}の重複表現（スコア用NVFP4、gradient用E4M3）を必要とするため、メモリの節約は部分的です。いくつかの強力なベースライン（cuDNN MXFP8、FA4 FP8、FlashInfer、HW-FP4 FA4）はサポートされたパックドドキュメントのbackwardパスを持たず、forwardの比較にのみ登場するため、トレーニング呼び出しについてのapples-to-apples比較が困難になっています。エンドツーエンドのLM pretrainingのloss曲線は「一貫した」トレーニング挙動として要約されていますが、抜粋されたセクションでは定量化されていません。

重要性

FLAMIAは、量子化を後付けのラッパーとして扱うのではなく、スケールレイアウトをattentionの双対縮約構造に合わせて設計することで、Blackwellの低精度スループットを困難なケース（因果的・パックド・可変長）における実際のトレーニングスピードアップに変換する方法を示しています。因果的安全性とforward/backwardの一貫性を持つ1.10–1.42\timesのエンドツーエンドattentionスピードアップは、本番のトレーニングスタックにおけるMXFP8/NVFP4 attentionカーネルの信頼性の高い設計指針となります。

Source: https://arxiv.org/abs/2611.03344

CoworkOS: 実世界の自動化に向けたエージェント・コーワーカーのスケーリング

問題設定

長期的な生産性作業には、現在のエージェントハーネスにおける二つの関連した弱点が露呈します。(i) 単一のフラットなコンテキストは、数時間の作業にわたって蓄積されるツールのトレース、中間成果物、ユーザーの修正を吸収しきれないこと、(ii) 人間とエージェントは通常チャットのみを介してやり取りする一方で、「作業」そのもの（スライド、CAD、コード、Blenderシーン）はどちらの当事者も共同で閲覧・編集できない不透明なファイルの中に存在すること、です。CoworkOSはこれに対し、タスク戦略（何をするか、何を受け入れるか、誰に委任するか）と実行管理（状態、フィードバック、チェックポイント）を分離し、成果物そのものを人間とエージェントの共同インタラクションの共有サーフェスとすることで対処します。

CoworkOSで生成されたアプリケーション事例の概観

24件のショーケース事例は、フロントエンドウェブサイト、ゲーム、Officeプレゼンテーション、インタラクティブな可視化、CAD、Blenderレンダリングにわたり、特定のツールチェーンではなくハーネス自体を意図的に多様な組み合わせで評価するものです。

ハーネスアーキテクチャ

ランタイムは三層の階層として構成されています。ユーザー向けの目標を担う単一の Main エージェント、委任を仲介する Coordinator Runtime、そしてスコープが限定された割り当てを実行する Subagent です。Mainは唯一の説明責任の主体であり、グローバルなインタラクション履歴を保持し、次式によってアクションを選択します。

a_t^{M} \sim \pi_M(\cdot \mid g, h_t^{M}, \mathcal{F}_t),

ここで g はユーザーの目標、h_t^{M} は保持されたインタラクション履歴、\mathcal{F}_t は新たに利用可能なフィードバック（ツールの結果、ユーザーのガイダンス、Subagentからの返答）です。このデザインはほとんどの責任をMainに集中させており、その理由として三点が挙げられています。タスク全体のコンテキストが一貫して維持されること、コンテキストが大きな独立したブランチをSubagentに分離することでMainのウィンドウを汚染しないこと、そして制御が分散ではなく集中されている方が調整のためのポリシーを学習しやすいことです。

CoworkOSハーネスと共有アクション空間

委任はエビデンス契約として定式化されます。Mainは目標、制約、許可された能力、および期待するエビデンスの形式を指定します。Subagentの中間的な軌跡はMainのコンテキストに入らず、契約上の成果物のみが渡されます。委任は同期的（Mainが返答を待つ）または非同期的（Mainが他の作業を継続し、Coordinatorを介してポーリング・コールバックを処理する）のいずれかです。これが、Mainのコンテキスト予算を超過させることなく長いツールインタラクションチェーンを扱いやすくする仕組みです。

三つの補助サブシステムが継続性を支えています。

  • スケーラブルなアプリケーションエコシステム: 人間とエージェントの両者が同じドキュメント、スライド、CADモデル、Blenderシーンをネイティブに編集できる共有リソースプロトコルであり、リビジョン管理と競合検出を備えています。ループ内の人間の参加は、Mainとの会話、またはMainが調整しなければならない成果物への直接編集を通じて行われます。
  • 階層的ワークスペース: ファイル、意思決定、Jobログはセッションをまたいでエージェント間で存続する永続的なワークスペースツリーに保存されます。
  • 永続的セマンティックメモリ: 重要な意思決定や長期実行Jobのサマリーを蒸留したもので、後のMainインスタンスが完全な履歴を再生することなく作業を再開できるようにします。

評価

CoworkOSは四つの能力クラスターにわたる12のベンチマークで評価されています。

  • Tool Use: SkillsBench、Tau-3 Bench Banking、AutomationBench。
  • Productivity: JobBench、Harvey Legal Agent Bench、GDPVal、OfficeQA Pro、WorkspaceBench-Lite。
  • Search: WideSearch、BrowseComp。
  • ML Coding: MLE-Bench-Lite、MLS-Bench。

10のベンチマークとRSIループにわたる性能概観

概観図はこれら10のベンチマークにわたって、CoworkOSを他の最先端のコワークハーネスと比較しています。論文ではさらに、成果物レベルの評価（提供された成果物の完全性、一貫性、使いやすさ）と、収集された軌跡に対する自動的なポストトレーニングがラウンドをまたいで漸進的な改善をもたらす再帰的自己改善（RSI）ループも報告されています。提供された抜粋にはベンチマークの具体的な数値がテキスト形式では含まれておらず、それらは図のパネルおよび利用可能なセクションに再現されていないSection 4.1/4.3の表に記載されています。

注目すべき設計上の留意点

  • 集中型のMain＋エビデンス契約委任パターンが主要なアーキテクチャ上の主張です。複数のピアが計画を共有するスウォーム型のマルチエージェントシステムと比較して、説明責任とコンテキストを一箇所に集中させ、SubagentをMainからするとステートレスにします——その貢献は内部トレースではなく契約によって定義されます。これによりコンテキストの増大が抑制され、ポリシーが学習可能になります。
  • 共有アプリケーション層は単なるUI上の利便性ではありません。人間がエージェントと同じリソースを編集するため、リビジョン追跡がエージェントのフィードバックストリーム \mathcal{F}_t に人間の修正を再入力する仕組みとなります。人間の介入は別個のモダリティではありません。
  • 非同期委任により、エージェントランタイムはジョブスケジューラに近いものになります。これは個々のSubagentの呼び出しが数分にわたって実行され得るML codingや長期的なsearchにおいて重要です。

限界とオープンクエスチョン

アーキテクチャの説明は詳細ですが、利用可能なテキストでは解決されていない点がいくつかあります。第一に、ポリシー \pi_M は所与のものとして扱われており、適切に委任するための学習方法、Subagentのエビデンスをいつ受け入れるか、いつ再計画するかについてはRSIのセクションに先送りされています。第二に、共有アプリケーション層における競合検出は言及されていますが仕様は示されていません——構造化された成果物（CAD、Blenderシーン）に対するMain、Subagent、人間による同時編集のセマンティックなマージは自明ではありません。第三に、階層は厳密に二階層（MainとSubagent）であり、Subagent自体が委任できるかどうか、また深さをまたいでコンテキスト契約がどのように合成されるかは対処されていません。最後に、競合するハーネスに対するヘッドラインの数値は提供された資料ではグラフィカルにのみ示されているため、抜粋から定量的な差の読み取りはできません。

この研究が重要な理由

長期的なエージェント作業がチャットの書き起こしではなく実際の成果物を生産するものであるならば、ハーネスは成果物、委任契約、永続的メモリを一級市民として——単一のLLM呼び出しの周辺的な足場としてではなく——扱わなければなりません。CoworkOSはこれらの責任を明確に分割した具体的な設計であり、委任のエビデンス契約という視点は、マルチエージェントの本番システムを構築する誰もが再利用できるプリミティブです。

Source: https://arxiv.org/abs/2611.03178

CUA-Master: オープンワールドの再帰的改善によるComputer-useエージェントのスケーリング

問題

Computer-useエージェント（CUAs）——スクリーンショットを入力として受け取り、自然言語タスクを完了するためにマウス・キーボード操作を出力するポリシー——は、軌跡データによってボトルネックが生じています。人間が収集したトレースはコストが高く偏りがあり、純粋に合成されたテンプレート型タスクは行動の多様性に欠けます。また、自己改善ループ（モデルが自身のトレーニングデータを生成する手法）は、生成器が既知の行動しか生成できないため、すぐに飽和してしまいます。CUA-Masterは、この停滞を打破するため、自己生成による教師信号を継続的に取り込まれるオープンワールドコーパスに置き換え、データ構築をエージェントの測定された失敗パターンと結びつけます。

タスクの定式化

著者らは標準的なCUAの定式化を採用しています。タスクは \mathcal{T}=(\mathcal{I},\mathcal{E},\mathcal{V}) として表され、命令 \mathcal{I}、環境 \mathcal{E}、検証器 \mathcal{V} から構成されます。各ステップ s において、ポリシーはアクションバッチをサンプリングします。

\mathbf{a}_s \sim \Pi(\cdot\mid \mathcal{I}, o_s, h_s),\quad \mathbf{a}_s=(a_s^{(1)},\ldots,a_s^{(L_s)}),

これにより、観測 o_s と履歴 h_s に対して、単一アクション（L_s=1）とバッチアクション（L_s>1）の両デコーディングが可能になります。軌跡

\mathcal{X}=\{o_1,\mathbf{a}_1,\ldots,o_S,\mathbf{a}_S,o_{S+1}\}

は終了時に \mathcal{V} によってスコアリングされます。この部分に目新しさはありませんが、バッチアクションの定式化は重要です。後段のシステムがクリック単位の教師信号ではなく、ワークフローの塊全体をマイニングするためです。

手法：入れ子の二重ループ・フライホイール

CUA-Masterは二つの入れ子になったループとして構成されています。

外側ループ（ワールド–データ–モデルのフライホイール）。 各トレーニングイテレーション後、現在のチェックポイントが保留タスクに対してプロファイリングされます。失敗クラスタ（エラーが集中するアプリカテゴリ、インタラクションプリミティブ、GUI/CLIの混合パターン）が、次のコーパス取り込みとタスク合成のラウンドを方向付けます。これにより、通常の静的データセットが弱点に条件付けられたカリキュラムに置き換えられます。重要なのは、新しいデータがモデル自身のロールアウトではなく、外部のオープンワールドソース（後述）から取得される点であり、著者らはこれが純粋な自己プレイの収穫逓減的な挙動を防ぐ理由であると主張しています。

内側ループ（データのフライホイール）。 二つの連携したステージから構成されます：

  1. オープンワールドシーディング。 実際のワークフローを収集するため、教示動画（チュートリアル、スクリーンキャスト）をマイニングします。視覚的・意味的デュアルパス再構成により、動画を軌跡に変換します。視覚パスはフレーム間でUIの状態遷移を追跡し、意味パスはナレーション・キャプションの意図を抽出します。この二つを対応付けることで、テンプレート型ゴールではなく実際の人間の操作に基づいた (\mathcal{I}, \mathcal{X}) ペアを復元します。

  2. 自己触媒的な伝播。 再構成された軌跡は再利用可能なプリミティブ（アプリ・意味的コンテキストに紐付けられたパラメータ化されたアクションマクロ）に分解されます。これらのプリミティブを制御可能な制約のもとで再組み合わせることで、プログラム的に検証器を構築できる新しいタスクを合成し、検証可能性を保ちながらスケールを実現します。

図5：GUI+CLIハイブリッドCUAの実行における、選択された3つの軌跡のデモンストレーション。

このパイプラインはGUI+CLIのハイブリッド軌跡をサポートしており、これはテンプレート型合成が特に苦手とする領域です。エージェントは、上図に示すように、一つのタスクの中でピクセルに基づくクリック操作とシェルコマンドを切り替えなければなりません。

スナップショット・ロールバックによるリトライ。 実環境での軌跡収集は信頼性が低く（ネットワークの不安定性、非決定論的なUI）、問題が生じます。著者らは、決定境界において環境状態のスナップショットを保存するフィードバック誘導型の仕組みを追加しています。検証器が失敗を検出した場合、ロールアウト全体を破棄するのではなく、最後の有効なスナップショットにロールバックし、修正されたアクションで再試行します。これにより、環境時間あたりの利用可能な軌跡の収率が大幅に向上します。

図7：タスクembeddingのt-SNE。

サンプリングされたタスクのt-SNEは、伝播ステージがシードクラスタを超えたカバレッジを生み出すことを示しており、プリミティブの再組み合わせが自己生成の上限を打破するという主張と一致しています。

結果

CUA-Master-27Bは、汎用オープンモデル（Qwen-3.5/3.6/3.8ファミリー（最大397B-A17B MoE）、Minimax-M3-428B-A23B、Kimi-K2.6-1T-A32B、Kimi-K3-2.8T-A104B）、プロプライエタリな汎用モデル（Seed-2.1-Pro、GPT-5.6、Claude Sonnet/Opus-5）、CUAスペシャリスト（OpenCUA-72B、GUI-Owl-1.5-32B、EvoCUA-1.5-32B、ScaleCUA-9B、Qwen-CUA-397B-A17B、UI-Mate-27B）と比較されています。すべてのベースラインは統一プロトコル（同一のアクションインターフェース、環境、検証器）のもとで再実行されています。

図1：4つのベンチマークにおけるCUA-Master-27Bとベースラインの比較。

27Bパラメータのこのモデルは、一桁大きいスペシャリスト（例：Qwen-CUA-397B-A17B）や兆スケールの汎用モデルと比較されています。図1の4ベンチマーク比較では、CUA-Master-27Bが同クラスのスペシャリストに対して全4軸でリードしており、最大規模のプロプライエタリモデルとも競争力があることが示されています。具体的な数値の内訳は、抽出されたセクションに表形式で示されるのではなく、図に示されています。

限界とオープンクエスチョン

  • 引用された箇所では、外側の弱点条件付きループ、動画に基づくシーディング、スナップショット・ロールバックコレクターのそれぞれがどの程度の寄与をしているかの定量化がされていません。アブレーション研究なしでは、どのコンポーネントが再帰を担っているかが不明確です。
  • 動画から軌跡への再構成は、ナレーション・視覚チャンネルが忠実であることを前提としています。無音のまま誤った再構成はノイズのあるラベルとなり検出しにくく、本論文では再構成の忠実度を報告していません。
  • 伝播されたタスクの検証器の構築は、CUAの合成データにおける通常の弱点です。\mathcal{V} が終端状態しか確認しない場合、縮退したショートカットポリシーが合格してしまう可能性があります。
  • 教示動画コーパスに存在しないアプリへの汎化については言及されておらず、オープンワールドという主張はチュートリアルがカバーする範囲に限られます。
  • 教示動画は評価スイートが検証するのとまさに同種のワークフローを示していることが多いため、ベンチマーク漏洩のリスクは無視できません。

この研究が重要な理由

エージェントの自己改善ループは、モデルが一度も持ったことのない能力をブートストラップできないために飽和します。CUA-Masterの回答——教示動画を外部のスキルソースとして扱い、モデルの弱点が次に何をマイニングするかを駆動する——は、通常の崩壊なしに再帰的なトレーニングを拡張するための具体的なレシピです。そして、27Bのモデルがはるかに大きなスペシャリストと匹敵することは、データパイプラインこそがスケールではなく主要な要因であることの証拠です。

Source: https://arxiv.org/abs/2611.03126

NorthCUA Technical Report: スケールでの経験によるComputer-Use Agentsの高速化

問題設定

画面上のコントロールを特定し、かつ複数ステップからなるソフトウェアワークフローを完了できるcomputer-use agents（CUAs）を訓練するには、個々の意思決定とタスクレベルの成果を結びつける経験が必要です。既存のボトルネックは2つあります：（i）多様なデスクトップおよびウェブ環境にわたって検証可能な成功基準を持つ、多様かつ実行可能なタスクを収集すること、（ii）単純なサンプリングではほとんど完了できない困難なワークフローに対して、長期的な視野を持つ成功軌跡を十分に生成すること。NorthCUAは、経験の生成とポリシーの改善をスケールで閉ループ化するために設計された統合システム——ハーネス、データフライホイール、および3段階の訓練パイプライン——です。

NorthCUAの経験ループ：ハーネスがタスクを実行して軌跡を記録し、Experience Flywheelがインテント・環境・検証器を精製し、段階的な学習とRLがポリシーをハーネスにフィードバックする。

システム

本システムは3つの連携コンポーネントで構成されています。NorthCUA Harnessは全ライフサイクルの実行を提供します：デスクトップおよびウェブ向けのプラットフォーム固有の知覚・行動ツールを備えた、ReActスタイルの共有ランタイム（観測、ポリシー呼び出し、ツール実行、フィードバック）です。セッション・タスク・ステップという3つのネストされたライフタイムが維持されることで、長期的なコンテキスト・ワークスペースの成果物・ライブ環境が、エージェントの終了後もツール使用型の評価器に利用可能な状態に保たれます。Batch Rollout Serviceが隔離された試行を並列化し、同じ観測・行動インターフェースがオンラインRLループでも再利用されます。

Experience Flywheelは2つのレベルで動作します。単一ステップのgroundingでは、スクリーンショットに1つの可視コントロールとその元画像座標がアノテーションされ、クエリは2つのルートで生成されます：（a）アクセシビリティメタデータとスクリーンショット証拠を使用した視覚的・構造的カバレッジによって名称・位置・操作ベースのクエリを生成するルート、（b）視覚的な外観が不十分な場合にアプリ知識から取得するドキュメントに基づいた機能的クエリを生成するルート。エンドツーエンドのタスクでは、インテント・環境・検証器が共同で拡張されます。未解決のタスクは再帰的な自己改善をトリガーし、検証済みのマイルストーンを保持してスキルを再利用可能な形に蒸留することで、後続の試行が最初からではなく部分的な進捗から再開できるようにします。

タスクの範囲：（a）単一ステップのgroundingは元画像内の(x,y)を出力する；（b）成果物・状態の結果チェックを伴う複数ステップのデスクトップ・ウェブインタラクション。

段階的な学習

すべての空間的な値は共通の [0,1000] 表現を使用します：幅 W・高さ H の画像において、ピクセル (x,y) は (1000x/W,\,1000y/H) にマッピングされます。3つの段階は以下の通りです：

  1. Broad GUI mid-training。 ローカリゼーションと広範なソフトウェア使用。報告されているスケール：>100,000軌跡、>4,000,000 GUIステップ、および約40,000のgroundingサンプル。判定器によって選択された軌跡と補助評価器のデモンストレーションが混在して使用されます。
  2. Verified long-horizon SFT。 約3,000軌跡・約310,000 GUIステップ。スクリプトベースの受け入れ判定・依存関係の充足・実行品質によって選択され、完結した依存関係一貫性のあるワークフローへ向けて分布を大幅に絞り込んでいます。
  3. Joint desktop–web agentic RL。 約1,500のデスクトップタスクと約500のウェブタスク。成果のばらつきについて人手でレビューされ、新たな検証器グループによって再スコアリングされます。RLループはハーネスの実行・評価器インターフェースを再利用するため、訓練時のrolloutはプロトコル上、データ収集時のrolloutと同一です。

各段階は前のチェックポイントから初期化されます。付録E（参照はあるが本文中では再現されていない）では、教師あり予測ユニットの定義と、RLのrolloutを訓練サンプルに変換する方法が説明されています。

モデルと評価

このファミリーは3つのサイズにおいてQwen3.5バックボーンを使用しています：Nano（9B dense）、Mini（総計35B / active 3B MoE）、Pro（総計397B / active 17B MoE）。チェックポイントはMid（mid-training後）とSFT（long-horizon SFT後）でタグ付けされており、groundingの結果にはSFTを使用し、デスクトップ・WebArena・WebTestBenchには最終的なRLチェックポイントを使用します。UltrafastはRL前のNanoから初期化された直接行動型の派生モデルで、推論トークンをレイテンシと引き換えにすることを意図しています。

NorthCUA-Proと主要モデルとの6ベンチマークスイートでの比較。

評価スイートは2つの能力軸をカバーしています：

  • Grounding： ScreenSpot-Pro（密度の高い専門的なUI、小さなコントロール）およびOSWorld-G（セマンティクス・レイアウト・精密なターゲティング・対象不在のケース）。
  • Desktop： OSWorld-Verified（アプリケーション・ファイル・クロスアプリワークフロー）およびOSWorld 2.0（長期的な依存ワークフロー、部分点スコアリング）。
  • Web： WebArena-Verified（状態を持つ結果チェック付きユーザータスク）およびWebTestBench（ゴールドチェックリストに対する適合率・再現率・F1による欠陥検出）。

本報告書は、記載された設定のもとすべての6つのベンチマークでオープンソースモデル中のstate-of-the-artを達成したと主張しています。ヘッドラインの棒グラフ（Figure 1）では、各軸においてProがリードしていることが示されています。提供されている抜粋は完全な数値テーブルを再現していないため（メトリクスは小数点1桁で報告）、集計上の主張を超えた具体的なベンチマーク別のスコアはここでは引用しません。

制限事項とオープンクエスチョン

  • 「オープンソース中のSOTA」は著者らの評価設定に限定されています。ハーネスの実装はOSWorldおよびWebArenaスタイルのスコアに実質的な影響を与えるため、共通ハーネスなしでは論文間の比較可能性は低いです。
  • RLタスクプールは小規模（合計約2,000タスク）です。Proレベルの向上がRLに起因するのか、約31万ステップのlong-horizon SFTに起因するのか、あるいは400万ステップ超のmid-trainingに起因するのかは不明です。
  • マイルストーンを保持した再帰的な自己改善は、検証器のreward hackingや試行間のクレジット漏洩のリスクがあります。提供されているセクションでは対策の詳細は述べられていません。
  • 2つのgroundingルート（視覚的・構造的なルートとドキュメントベースのルート）を分離したアブレーション、または未解決タスクに対するスキル蒸留の限界的な価値を定量化した分析は、抜粋には含まれていません。
  • NanoがdenseでありMini・ProがMoEであることは、ファミリー内のスケーリング比較を複雑にします。

重要性

NorthCUAは、実行インフラ・検証器ベースのタスクキュレーション・段階的なSFT→RL訓練を単一のフィードバックループに結合するための具体的なレシピです。そのスケール（>400万GUIステップ、総計397Bまでの3モデルサイズ）はオープンなスタックではほとんど達成されていません。ハーネスとフライホイールが汎化するならば、CUAのスケーリングの主軸は静的なデモンストレーションコーパスから、検証器を備えた実行可能なタスクプールへと移行することになります。

Source: https://arxiv.org/abs/2611.02102

Lost in Recovery: Demystifying Recovery Behavior of Computer-Use Agents via Goal-Oriented Action Replay

マウスやキーボードの操作プリミティブを通じてGUIを操作するcomputer-use agents（CUAs）は、長いホライズンにわたって脆弱です。クリックミス、不意なダイアログ、意図しないファイル書き込みが積み重なって失敗につながります。既存の対策は不十分です。環境のリセットはプロプライエタリなアプリでは実現不可能であり、APIベースのロールバックはwebのDOMにしか存在せず、スナップショットからのaction replayはホライズンに比例してコストが増大します。本論文は、研究が不十分な領域であるモデルベースのリカバリに焦点を当てます。これは、エージェント自身が以前の正常な状態に戻る方法を推論し、タスクを再開しなければならないというものです。本論文の貢献は、リカバリの成功を厳密に定義し、制御されたエラーを注入し、エージェントが軌道に戻れるかを評価するベンチマーク「ReTrace」です。

reflection、rollback、recoveryの各戦略の比較。

リカバリの形式化

CUAタスクはPOMDP \mathcal{M}=(\mathcal{S},\mathcal{A},\mathcal{O},\mathcal{E},\mathcal{T},\Omega) であり、s_t=(h_t,o_t) は隠れ状態 h_t（例：ファイルシステムの状態、隠れウィンドウハンドル）と観測 o_t=\Omega(s_t)（例：スクリーンショット）に分解されます。軌道 \tau=\{(s_t,a_t)\}_{t=0}^T が与えられたとき、リカバリはある回復距離 d に対するマップ f(s_t)=s_{t-d} であり、オラクル \mathcal{R}\in\{0,1\} によって判定されます。

方法論上の重要な決断は、オラクルとしてのピクセル・特徴量マッチングを棄却することです。潜在状態は目に見える変化なしにドリフトし得ます——変更された設定ファイル、古くなったクリップボード、バックグラウンドプロセスなどです。予測状態表現（predictive state representations）から着想を得て、著者らは遷移一貫性リカバリ（transition-consistent recovery）を定義します。2つの状態が等価であるのは、それらが同一のダウンストリームダイナミクスを生成する場合に限ります。具体的には、決定論的 \mathcal{T}_{\mathcal{E}} に対して、

\mathcal{R}_{\mathrm{TC}}=\mathbb{I}\big[\mathcal{T}_{\mathcal{E}}(f(s_t),a_{t-d})=s_{t-d+1}\big],

これをマルチステップのreplayへと再帰的に拡張すると、

\mathcal{R}_{\mathrm{TC}}=\mathbb{I}\big[\mathcal{T}_{\mathcal{E}}(\cdots\mathcal{T}_{\mathcal{E}}(f(s_t),a_{t-d})\cdots,a_{t-1})=s_t\big].

観測チェック \mathcal{R}_{\mathrm{O}}=\mathbb{I}[o=\hat o] を論理積で結合することで、逆の失敗モード（潜在状態のドリフトなしに観測がドリフトする場合）を捉え、\mathcal{R}=\mathcal{R}_{\mathrm{TC}}\wedge\mathcal{R}_{\mathrm{O}} が得られます。

ReTraceパイプライン

ReTrace：on-policyロールアウト、ドリフトを誘発する摂動、回復された状態からのgoal-oriented action replay。

ReTraceは3つのステージから構成されます。(A) On-policyロールアウト：成功した軌道を収集し、各アクション列を N 回replayして決定論性のフィルタリングを行い、\mathcal{T}_{\mathcal{E}} が記録された (s,a) ペア上で関数として振る舞う遷移一貫性データセットを生成します。これはOSWorld上で自明ではありません。GUIアプリにはアニメーションのタイミング、非同期I/O、非決定論的なレイアウトがあるため、N 回replayフィルタこそがオラクルを適切に定義可能にしています。(B) 摂動による軌道ドリフト：ターゲットインデックス t-d を選択し、制御された摂動を注入することで、エージェントが軌道外の誤った s_t に到達するようにします。(C) Goal-oriented action replay：エージェントが回復した状態 f(s_t) から、サフィックス a_{t-d},a_{t-d+1},\dots,a_{T-1} をreplayし、最終状態が s_T と一致するかどうか（等価的に、オラクルがチェーン全体で成立するかどうか）を確認します。

この設計は、タスク成功によってリカバリを評価する循環論法を回避しています——単に「正しく見える」回復済み状態でも、ダウンストリームで失敗する可能性があり、サフィックスのreplayがまさにそれを露わにします。

主要な発見

理想的なリカバリは潜在的な能力を露わにする。 サニティチェックとして、本論文は距離 R においてオラクルが回復した状態からforward policyが再開したときに、5回の独立した継続のうち少なくとも1回成功する確率であるSuccess@5を測定します。OSWorld上でEvoCUA-32Bを実行すると、R が大きくなるにつれてSuccess@5が急激に上昇し、単一ロールアウトの成功率がポリシーの潜在的な能力を大幅に過小評価していることが実証されます。ボトルネックは生成ではなく状態の復元にあります。言い換えれば、より良いリカバリは取り組む価値のあるレバーです。

現在のエージェントのリカバリ性能は低い。 遷移一貫性オラクルの下では、自律的なモデルベースのリカバリは観測のみのメトリクスが示唆するよりも大幅に弱いです。\mathcal{R}_{\mathrm{O}}=1（見た目が正しい）と \mathcal{R}_{\mathrm{TC}}=1（動作が正しい）の間のギャップが中心的な実証的発見です。エージェントは頻繁に可視インターフェースを復元する一方で、replayを脱線させる潜在的な破損を残します。セクション6のエンドツーエンド評価では、同じバックボーンがforward policyとrecovery policyの両方として機能しており、明示的なリカバリ戦略は測定可能ではあるものの限定的な改善をもたらすこと、そして呼び出し頻度ではなくリカバリの品質こそがダウンストリームの成功と相関することが確認されています。

制限と未解決の問題

オラクルは決定論的な \mathcal{T}_{\mathcal{E}} を必要とし、N 回replayフィルタはこれを近似するものの、キュレートされたデータセット外での保証はありません——確率的なアプリ、時間依存のウィジェット、ネットワーク結合された状態は形式主義の外に置かれます。Goal-oriented replayはまた、リカバリ後もサフィックスのアクション列が有効であることを前提としており、意味的には等価でも構文的には異なるパス（例：s_T に到達する別の有効なクリック列）にはペナルティを与えます。本研究はリカバリの挙動をベンチマークしますが、\mathcal{R}_{\mathrm{TC}} を目標とするトレーニング目的関数を提案していません。摂動リセットペアに対するsupervised fine-tuning、あるいは遷移一貫性報酬を用いたRLがギャップを埋めるかどうかは未解決のままです。最後に、「forwardとrecoveryが同じバックボーンを共有する」プロトコルは、非対称なセットアップで分離可能な2つの失敗モードを結合させています。

なぜ重要か

リカバリは確率的な単一ロールアウトエージェントを信頼性の高い長期ホライズンシステムへと変換するコンポーネントであり、本論文はそのための最初の原理的なオラクルを提供します——観測のマッチングでは不十分であり、遷移一貫性が必要です。視覚的なリカバリ成功と動的なリカバリ成功の間の報告されたギャップは、CUAリーダーボードを静かに水増しするような種類のメトリクスのミスマッチであり、ReTraceはそれを解消するための具体的なツールです。

Source: https://arxiv.org/abs/2610.27954

Hacker News Signals

事前学習データ汚染によるエージェント型バックドア

本論文は、攻撃者が事前学習データの一部を汚染することで、デプロイされたモデルが自律エージェントとして使用される際にのみ発動するバックドアを埋め込む脅威モデルを調査しています。通常のチャットやベンチマーク評価中には発動しない点が特徴です。核心的な洞察は、エージェント型パイプラインがツール使用と多段階の計画ループを導入することで、通常の推論では存在しないトリガー発生面が生まれるという点にあります。攻撃者は、特定の意味論的トリガー（例えば、特定のシステムプロンプトのパターンやタスクの記述）と悪意ある行動シーケンス——データの窃取、任意のシェルコマンドの実行、生成コードへの脆弱性の挿入——を関連付ける汚染ドキュメントを構築します。

機構論的な論拠として、汚染ドキュメントのごく少数の割合（本論文では0.1%〜1%の範囲を検討）であっても事前学習に含まれれば十分とされています。これは、モデルが事実的知識と並行してトリガーと行動の対応関係を学習し、その挙動が RLHF fine-tuning のもとでも安定して維持されるためです。このバックドアが fine-tuning 段階で埋め込まれるものより耐久性が高い理由は、まさに事前学習の表現が事後的に除去しにくいからです。著者らは、直接的に有害な出力を探索する標準的な安全性評価では、バックドアが正しいトリガーを伴うツール呼び出しのコンテキスト内でしか発動しないため検出されないことを実証しています。

検討された防御手法としては、activation クラスタリングと入力摂動が挙げられており、いずれもある程度の有効性は示されているものの、トリガーが語彙的なトークンではなく意味論的なコンテンツ全体に分散している場合には信頼性が低いことが示されています。本論文は、攻撃成功率と防御の再現率の間にあるギャップを解消するには至っていません。

未解決の問題としては、事前学習コーパスをスケールアップした状態でそのようなトリガーを監査する方法、蒸留やモデルのマージによってバックドアが破壊されるかどうか、そしてこの脅威がマルチモーダルエージェントにどのようにスケールするかという点が挙げられます。

Source: https://arxiv.org/abs/2610.37741

AstraはQwenを改善するためにウェイトの読み書きを行う

このブログ記事では、Astraと呼ばれるモデルがQwenモデルのweight tensorを直接操作してその性能を向上させる実験について説明しており、「weight-space programming」として位置付けられています。このセットアップでは、Astraが学習データの生成やgradient descentによるfine-tuningを行う代わりに、特定のパラメータ部分空間に対して標的を絞った編集を生成します。Astraは診断用プロンプトに対するactivationを読み取ることで、どのweightコンポーネントがどの能力に対応するかを特定し、それらのコンポーネントに対して小さな加算的な摂動を書き込むと主張されています。

技術的な基盤はモデル編集に関する研究（ROME、MEMIT）に最も近いですが、より広い範囲に適用されています。MLPレイヤーにおける事実の関連付けにパッチを当てるのではなく、Astraはattention headとFFNブロックにまたがる能力レベルの編集を試みます。ブログでは、AstraがWeightのスライスを読み取り、テストプロンプトに対して推論を実行し、weight空間における修正方向を推定し、deltaを書き戻すというループが説明されています。gradient信号は使用されておらず、「optimizer」はAstraモデル自身の出力です。

これが技術的に興味深いのは、weight編集を手動で設計されたアルゴリズムではなく、学習されたメタスキルとして捉えている点です。この主張が正しければ、Astraはloss landscapeの幾何学を十分に内在化しており、検査だけで有用なgradient stepを近似できることを示唆しています。これは強い主張ですが、ブログはそれを定性的な例と、Qwenの推論タスクにおける小幅な改善を示す小規模なベンチマーク表によってのみ裏付けています。

限界は大きいです。編集は分布外タスクにおいて性能が低下し（weightの干渉）、複数の逐次的な編集にわたってうまく組み合わせることができず、Astraの「読み取り」と「書き込み」の貢献を分離するablationも存在しません。これが小規模な標的を絞った改善を超えて一般化できるかどうかは実証されていません。

Source: https://rikiyat.github.io/blog/weight-space-programming/

AI時代における自我のない数学（Egoless Mathematics）

Terence Taoの投稿は、AIツールが証明のステップを補完し、ケースを網羅的に確認し、補題を提案する能力をますます高めている状況を踏まえ、数学における功績の帰属と共同研究のあり方に構造的な変革をもたらすべきだと主張しています。技術的な核心となる観察は、現在のAIシステムが彼の言う「局所的」推論――特定の代数的操作の妥当性を検証する、有限ケースを網羅する、既知の議論をLeanで形式化する――においては信頼に足る一方で、「大域的」推論――適切な問題分解の特定、鍵となる補題の発見、あるいはアプローチが根本的に行き詰まっていることの認識――においては信頼性に欠けるという点にあります。

この非対称性はワークフローに対して実践的な示唆をもたらします。人間の数学者は大域的構造の設計者として機能しつつ、局所的な検証とギャップの補完をAIに委任すべきであり、これは数十年前に数値計算が算術処理を機械に委ねたことと類比できます。「自我のない（egoless）」という要素は、証明がすべて自分自身の知的産物でなければならないという規範を捨て去ることを指しています――Taoはこの規範が、数学を加速させうるツールの採用を積極的に妨げていると論じています。

彼はCollatz問題やその他の問題でAIアシスタントを使用した自身の経験から具体的な区別を引き出しています。アシスタントは候補となるアプローチを素早く生成し、特定のステップが成立するかどうかを確認するのに有用ですが、どの候補を追求する価値があるかの判断は依然として人間に委ねられます。また、形式化のパイプライン（非形式的なスケッチからLean証明へ）が、最終的な出版ステップとしてではなく継続的な正しさのチェックとして使用できるほど実用的になってきていることも指摘しています。

エンジニアリングに関連する示唆は、人間とAIの協調を局所的推論と大域的推論の境界に沿った分業として捉えるというフレーミングにあります――これはAIが検証を担い、人間がアーキテクチャ的な意思決定を担うあらゆる領域に転用できる原則です。

Source: https://terrytao.wordpress.com/2026/11/02/egoless-mathematics-in-the-ai-era/

OpenAIにおけるGitのスケーリング

OpenAIのエンジニアリングブログでは、GitのモノレポがファイルR数千万、アクティブなエンジニアR数百人規模に成長したときに生じる運用上の問題が述べられています。核心的なボトルネックは、標準的なGit操作 — status、checkout、fetch — が「変更ファイル数」に対してではなく「リポジトリサイズ」に対してO(repository size)となることです。これはindexとオブジェクトストアが選択的な部分ビューを想定した設計になっていないためです。

彼らの緩和策は三つのカテゴリに分類されます。第一に、cone modeを用いたsparse checkoutにより、各エンジニアが実際に必要とするサブツリーだけに作業ツリーを絞り込み、indexのスキャンコストを大幅に削減しています。第二に、partial clone（--filter=blob:none）によってファイルコンテンツのダウンロードをアクセス時まで遅延させ、大きなblobの履歴を持つリポジトリの初回clone時間を数時間から数分に短縮しています。第三に、Scalar互換のバックグラウンドメンテナンススケジュール（commit graphの書き込み、loose objectの再パック、fetchのプリフェッチ）を導入し、インタラクティブなコマンドにペナルティを与えるのではなく、アイドル時間にハウスキーピングコストを分散させています。

また、CIシステムと大規模リポジトリの相互作用についても述べられています。ジョブごとにフルcloneを行うCIランナーはコストの大きな要因であり、パイプラインステージごとに明示的なdepth tuningを施したshallow cloneへ移行しました。CIの実行をまたいでGitオブジェクトストアをキャッシュするには、force-push後に古いオブジェクトを返さないよう、慎重なキャッシュ無効化ロジックが必要でした。

見落としがちな重要な点として、commit graphファイル（事前に計算されたDAGのindex）はgit logやmerge-baseクエリを劇的に高速化しますが、fetchのたびに再ビルドが必要です。彼らはこの再ビルドをフォアグラウンド操作をブロックしないよう、非同期のpost-fetch hookに移動しました。

未解決の問題として以下を挙げています：macOSにおけるファイルシステムの大文字小文字区別の不一致、並列サブモジュール操作時のindexへのロック競合、そしてサブモジュールへの分割なしにディレクトリ単位のアクセス制御をネイティブにサポートするGit機能の欠如です。

Source: https://openai.com/index/scaling-git-at-openai/

AFL++によるファジングテストをより効果的に行うためのヒント

nullprogramブログのこの投稿では、デフォルトの呼び出し方を超えて、コーパスのカバレッジやバグ発見率を実質的に向上させるAFL++の実践的な設定方法を解説しています。技術的に重要なポイントをいくつか紹介します。

Persistent modeは、ほとんどのターゲットにとって最もインパクトの大きな変更です。fuzzターゲットを__AFL_LOOP(10000)でラップすることで、プロセスをイテレーション間で生かし続け、入力ごとのexecオーバーヘッドを回避します。これにより、初期化コストが高いターゲットでは10〜100倍のスループット向上が得られます。トレードオフとして、persistent stateがクリーンなプロセス起動時にのみ現れるバグを見逃す可能性があります。

Sanitizerとの相互作用：ASanを有効にして実行するとスループットが半減しますが、より多くのバグクラスを検出できます。この投稿では、corpusを共有するために-M/-Sのmaster/secondaryモードを使用しながら、ASanありとなしの2つのAFL++インスタンスを並列実行することを推奨しています。secondaryインスタンスはカバレッジを多様化するために、異なるmutation戦略（例：-p fastと-p coe）を使用できます。

シードコーパスの品質は初期カバレッジを左右する最重要要素です。単一の有効な入力から始めた場合と、最小限の多様なコーパス（構造的に異なる5〜10個の有効な入力）から始めた場合とでは、24時間後に測定可能なカバレッジの差が生じることを著者は実証しています。コーパス最小化のためのAFL++のcminツールは、長期キャンペーンの後ではなく前に実行すべきです。

AFL_CUSTOM_MUTATOR_LIBRARYインターフェースを介したカスタムmutatorは、構造化フォーマット（例：バイナリプロトコル）に対して実装コストに見合う価値があります。この投稿では、長さプレフィックスフィールドのmutatorを使うことで、パーサーの最初のバイトで弾かれる入力にバジェットを費やすことを回避できる小さな実例を示しています。

辞書インジェクション（-x）は活用が少ない機能です。テキストベースのプロトコルでは、キーワード辞書を使用することで、特定のバイト文字列をチェックする分岐条件に対するtime-to-coverageを短縮できます。

Source: https://nullprogram.com/blog/2025/02/05/

Trigger.dev における顧客環境変数の漏洩

Trigger.devのインシデントレポートは、顧客の環境変数——APIキー、データベース認証情報、シークレットなどを頻繁に含む——が不正アクセスによって漏洩した事象を報告しています。根本原因は、シークレット管理レイヤーにおけるアクセス制御パスの設定ミスです。具体的には、タスク実行のために環境変数のペイロードを取得するAPIエンドポイントが、プロジェクトごとの認証トークンを要求せず、有効な（ただしプロジェクトスコープを持たない）プラットフォーム認証情報のみで到達可能な状態になっていました。

漏洩期間と影響を受けた顧客数は投稿内で開示されています。攻撃者はこのエンドポイントを利用してプロジェクトIDを列挙し、それに関連する環境変数セットを取得しました。アクセスパターンは量的に異常でしたが、当該エンドポイントが通常運用でも正当な実行パスであったため、即座には検知されませんでした。

同社の対処策として、設定ミスのあったエンドポイントにプロジェクトスコープの認可チェックを強制するパッチを適用し、漏洩したシークレットをすべてローテーション（顧客への通知を含む）し、シークレット関連エンドポイントへの監査ログを遡及的に拡充しました。また、認証情報ごとのシークレット取得量に対する自動異常検知の追加も進めています。

この事象が示す構造的な問題は、開発者向けプラットフォームに見られる典型的なパターンです。すなわち、高スループットかつ低レイテンシを求められる実行インフラのエンドポイントは、リクエストごとの認証オーバーヘッドを最小化する圧力を生み出し、粗粒度の認可につながりやすいという点です。タスク実行コンテキストにおける環境変数の取得は、シークレットの価値が高く、かつアクセスパターン（実行時フェッチ）が運用上の正常動作と区別しにくいため、特に狙われやすいターゲットとなります。

この投稿はタイムラインを含み、公開インシデントレポートとしては適度に詳細ですが、設定ミスの具体的な認可ロジックについては開示されていません。

Source: https://trigger.dev/blog/security-incident-nov-2026

中国初の先端AI輸出規制：商務部公告第48号

Cloud Security Allianceのリサーチノートは、中国商務部公告第48号を分析しています。同公告は、先端AIシステムおよびその構成要素を対象とした輸出規制メカニズムを新たに導入するものです。これは構造的に新しい試みです。AIに関する従来の中国の輸出規制は、2021〜2022年のアルゴリズム規制および深度合成規制のもとで特定のアルゴリズムカテゴリ（レコメンデーションシステム、ディープフェイクなど）を対象としていましたが、第48号は先端モデルの能力および関連インフラをカテゴリとして対象とする初めての規制です。

技術的な適用範囲は、計算量閾値（学習FLOPsで測定）を超えるモデルの重み、先端モデルの学習データ、そして「主要な実現技術（key enabling technologies）」を対象としています。この最後の用語は意図的に広く定義されており、リサーチノートはRLHFパイプライン、評価インフラ、fine-tuningツールチェーンを含む可能性が高いと解釈しています。同規制は、外国法人への移転に対して輸出ライセンスを要求し、米国BISのライセンスと構造的に類似したエンドユーザー確認要件を設けています。

リサーチノートはいくつかの実施上の曖昧さを指摘しています。「先端」の定義となるFLOPs閾値は、公告文中に数値として明記されておらず、これは米国大統領令14110における定義上の課題と同様ですが、その解決は後続の規制指針に委ねられています。また、オープンウェイトモデルの扱いも不明確であり、重みを公開することがライセンスを要する「輸出」に該当するかどうかは未解決のままです。

地政学的なメカニズムとして、この動きは米国・同盟国と中国の双方が先端AIに対する輸出規制の枠組みを持つ対称的な管理体制を生み出します。これにより、相互的なライセンス圧力が生じ、国際的な研究協力が複雑化します。重みベースの資産（容易に複製可能）に対する現実的な執行上の課題については触れられていません。

Source: https://labs.cloudsecurityalliance.org/research/csa-research-note-china-ai-export-controls-announcement-48-2/

Launch HN: Momentic (YC W24) – アプリを実際に操作してバグを検出するエージェント

Momenticは、AIを活用したエンドツーエンドのテストツールです。DOMセレクタの事前定義スクリプトを実行するのではなく、エージェントがユーザーと同様の方法でウェブアプリケーションを操作します。このアプローチの核心にある技術的な賭けは、セレクタベースのテストフレームワーク（Selenium、Playwrightスクリプト）がUIのリファクタリングに対して脆弱であるという点です。それらはintent（意図）ではなく、実装の詳細（CSSクラス、要素ID）をエンコードしているためです。Momenticのエージェントは代わりに、ユーザーフローの自然言語による説明を受け取り、ライブアプリケーションをナビゲートしてそれを検証します。

基盤となるアーキテクチャには、レンダリングされたUIをエージェントが推論できる構造化された表現に変換するvision-language modelまたはアクセシビリティツリーパーサーが含まれており、さらに述べられたゴールに基づいて次に操作する要素を決定するプランニングコンポーネントと組み合わされています。エージェントのループは、現在の状態を観察し、アクション（クリック、タイプ、スクロール、アサート）を選択し、実行し、ゴールが達成されるか失敗条件が検出されるまで繰り返すというものです。

純粋にLLMプロンプトによるテストと比較した場合の主張される優位点は、エージェントが各ステップで実際のレンダリング状態を観察するため、明示的な待機や同期コードなしに動的コンテンツ（モーダル、非同期ロード、状態依存UI）を処理できるという点です。失敗検出は、アプリケーションが予期しない状態に入ったことをエージェントが認識することに依存しており、これはハードなセレクタマッチよりもソフトなアサーションです。

このアプローチにおける既知の難問は、エージェントの意思決定レイヤーでのflakiness（不安定さ）です。LLMベースのアクション選択は非決定論的であるため、テストの再実行が異なるパスをたどり、一貫性のない結果を生じる可能性があります。MomenticのHNスレッドでの議論は主にこの問題、そしてシステムがCI統合に向けて安定したpass/failシグナルを生成するかどうかに集中しています。実際のコードベースでのPlaywrightやCypressとの詳細なベンチマーク比較はローンチ時には提示されていません。

Source: https://momentic.ai/

注目の新しいリポジトリ

jwuthri-cloud/Tracely-ai

Tracely-aiは、LLMのeval benchmarkと実際の本番AIエージェントで発生する障害との間のギャップを埋めることを目的としています。コアとなるワークフローは、エージェントにトレース収集を組み込んでから本番環境へデプロイし、実際のトレースに対してグレーディングパイプラインを実行して、正確性・ツール呼び出しの一貫性・障害モードをスコアリングするというものです。cluster-failuresという機能は、embedding類似度によってトレースをグループ化し、単発の異常ではなく系統的なエラーを浮き彫りにします。特筆すべき点として、失敗したトレースを再現可能なリグレッションテストとして固定化できます。これは決定論的な入出力スナップショットであり、テストスイートにコミットされてCIに組み込まれます。PRチェックでは固定化されたすべてのリグレッションを再実行し、いずれかのスコアが閾値を下回った場合はマージをブロックします。

セルフホスティングにより、トレースがインフラ外に出ることはなく、PIIや独自のツールスキーマを扱うエージェントにとって重要な特性となっています。アーキテクチャはprompt-nativeではなくtrace-nativeです。つまり、評価はデプロイメントループの第一級市民であり、独立したオフラインプロセスではありません。これはLangSmithやBraintrustといったフレームワークとは本質的に異なります。リグレッションの固定化とブロックの仕組みが継続的なラチェット機構を生み出し、以前に通過していた動作を気づかぬうちに退行させることができなくなります。単一のツール呼び出しの失敗が連鎖するマルチステップエージェントを運用するチームにとって、この種の構造的なリグレッション防止は、手書きのゴールデンスイートを維持するよりもはるかに現実的なアプローチです。

Source: https://github.com/jwuthri-cloud/Tracely-ai

N1nEmAn/sapper-v2

Sapper-v2は、コマンダー・ワーカー階層として構成された自律的なペネトレーションテストフレームワークです。計画担当のLLMがコマンダーとして機能し、攻撃目標をサブタスクに分解して、各フェーズ（偵察、脆弱性列挙、エクスプロイト、ラテラルムーブメント）を担当するワーカーエージェントの群れに割り振ります。状態は階層化されたファクト・インテントグラフで管理されます。ファクトは観測されたシステムの特性（開放ポート、サービスバナー、CVEマッチング）であり、インテントは有効な攻撃仮説です。コマンダーはワーカーからの報告を受け取るたびにグラフを更新し、セッションを再起動することなくリアクティブな再計画を実現します。

ベンチマーク結果は注目に値します。第3回テンセントインテリジェント攻防コンテスト（634チーム参加、8時間の無人稼働ウィンドウ）において、本システムは約10億トークン合計を使用したにもかかわらず、45億トークンを使用したチームを上回りました。これは、グラフ構造化された計画が冗長なツール呼び出しや幻覚的な攻撃パスを削減していることを示唆しています。説明中に言及されている「女媧テスト」—創造・言語・歴史のプリミティブをエージェントに与え、文明の出現をシミュレートする—は、プロダクション機能というより、内部的なアライメントまたは能力境界の探索として読み取れます。

セキュリティ研究の観点から見ると、階層化グラフが興味深い技術的貢献です。既存の自律ペネトレーションテストツールの多く（AutoAttacker、PentestGPT）はフラットな会話履歴を使用しており、長時間のセッションでは性能が劣化します。構造化されたファクトの分離により、8時間全体のウィンドウを通じてコンテキストの忠実性が維持されます。

Source: https://github.com/N1nEmAn/sapper-v2

guregodevo/memdoor

Memdoorは、構造化されたコンテキスト管理によって小規模モデルが実際のコーディングタスクにおいてフロンティアモデルを上回ることができるという主張を中心に構築された、コーディングワークフロー用のハーネスです。核心となるアイデアは、無関係なトークンによって劣化する単一の長いコンテキストウィンドウに依存するのではなく、エージェントが各ステップで読み書きを行う、永続的かつ階層的に整理されたメモリストアです。このハーネスは、各プロンプトに注入するメモリセグメント（ファイルの要約、関数シグネチャ、過去のdiff、エラーログ）を管理し、実効コンテキストを簡潔かつタスクに関連したものに保ちます。

これは十分に記録された現象と結びついています。すなわち、長く雑然としたコンテキストにおけるフロンティアモデルはlost-in-the-middleによる性能劣化を示す一方、クリーンで的を絞ったコンテキスト上の小規模モデルはその差の多くを縮めることができます。Memdoorは、コンテキストのキュレーションをプロンプティングの技法としてではなく、エンジニアリングの問題として扱うことでこれを実践します。このワークフローハーネスはツールのオーケストレーション（ファイルの読み込み、テストの実行、linterの出力）も担い、構造化された結果をメモリストアにフィードバックすることで、クローズドループを形成します。

推論コストやレイテンシに制約のある実践者にとって、これは直接的に有用です。ローカルで動作する量子化済みの7Bまたは14Bモデルを厳格なコンテキスト管理のもとで用いることで、リポジトリ規模のタスクにおいてGPT-4クラスの推論と競合する性能を、トークンあたりのコストのほんの一部で実現できる可能性があります。

Source: https://github.com/guregodevo/memdoor

xingjian-bai/opal

OPAL（Online Parameter Adaptation Loop、と思われる）は、コーディングエージェントを用いてoptimizerのハイパーパラメータ——場合によってはoptimizer自体のロジック——をモデルの学習中にリアルタイムで書き換えるリアクティブなoptimizerです。概念的な枠組みはコード生成としてのメタ最適化であり、別途HPOスイープを走らせたり固定スケジュールでlearning rateを調整したりするのではなく、監視エージェントが学習メトリクス（loss曲線、gradient norm、重み更新の大きさ）を観察し、実行時に適用されるoptimizerのコードパッチを生成します。

これは技術的にはlearned optimizer（例：VeLO、L2O）に近い位置づけですが、メカニズムが異なります。学習済みのメタネットワークが更新則を生成するのではなく、汎用LLMがPython/PyTorchのコードを生成し、それがコンパイルされて学習ループにホットスワップされます。新たな学習ランを必要とせず、変更が現在のランの後続ステップから即座に反映されるため、リアクティブループは従来のHPOよりもはるかに高速に閉じます。

主な未解決の課題としては、安定性の保証（不正なコードパッチがランを破壊する可能性）、学習ステップ時間に対するLLM推論のレイテンシ（高速なGPUステップにおいて問題となる）、およびスカラーメトリクスのみから得られるシグナルだけでエージェントが有益な判断を下せるかどうか、などが挙げられます。それでも、手動監視が現実的でない長い学習ランにおいては、保守的なリアクティブ調整——learning rateウォームアップの延長、gradient clippingの閾値チューニング——だけでも無駄な計算リソースを防ぐことができる可能性があります。

Source: https://github.com/xingjian-bai/opal

yjid/kensaku

Kensakuは、3つの検索モダリティを組み合わせたローカルファーストのファイルランチャー兼検索エンジンです。具体的には、完全一致・ファジーによるファイル名およびテキスト検索、スクリーンショットやスキャンPDFからのOCRベースのコンテンツ抽出、そして文書内容に対するセマンティックベクトル検索の3つを統合しています。すべての処理はデバイス上で実行され、クラウドへの依存は一切ありません。MCP（Model Context Protocol）インターフェースにより、検索インデックスをローカルのLLMエージェントに公開することができ、エージェントはファイルを手動で受け渡しすることなく、ツールコールとしてファイルシステムをセマンティックにクエリできます。

OCRパイプラインによって、スクリーンショットが第一級の検索可能なドキュメントとして扱われます。これは、コードスニペット、ターミナル出力、参考資料のスクリーンショットを保存するワークフローを持つユーザーにとって実用的です。セマンティック検索レイヤーは、おそらくローカルで動作するembeddingモデルを使用しており（リポジトリで使用モデルとインデックスバックエンドの詳細を確認できます）、正確なファイル名を覚えていなくても「attention-sinkの緩和に関するドキュメントを探す」といったクエリが可能になります。

Kensakuは明確なニッチを占めています。SpotlightやEverythingが完全一致検索に対するものと同様に、ローカルファイル検索に対する存在といえますが、視覚的コンテンツの抽出とセマンティック検索という付加価値を持ちます。MCP統合はエージェント的ワークフローにおける差別化要因であり、ローカルファイルシステムをデータを外部APIに公開することなく、MCP互換のエージェントからアクセス可能な構造化されたクエリ可能なナレッジベースへと変換します。

Source: https://github.com/yjid/kensaku

miuuyy/Octopus-SI-OS

Octopus-SI-OSは、エージェント型オペレーティングシステムとして自らを位置付けています。すなわち、OSレベルの抽象化——スケジューリング、メモリ分離、プロセス間通信——をLLMベースのエージェントに適用することで、エージェントの実行を管理するランタイムです。このアーキテクチャは、カーネル/ユーザ空間の分割に類比して、ハーネス層（リソース管理、エージェントのライフサイクル管理、メッセージルーティング）とエージェントロジック層を分離しています。エージェントはプロセスとして扱われ、リソースの可用性やタスクの優先度に基づいて、ハーネスによってスポーン・サスペンド・レジューム・ターミネートされます。

OSのメタファーは単なる見た目上のものではありません。プロセス分離の概念をエージェントに適用することは、現実の問題に対処するものです。フラットなマルチエージェントシステムでは、誤動作するエージェント一つが共有状態を破壊したり、コンテキストバジェットをすべて消費してしまう恐れがあります。Octopus-SI-OSは、境界を構造的に強制することを目指しています。「自己進化（self-evolving）」という主張は、ハーネス自身がカーネルを書き換えるというよりも、タスクの要求に応じてハーネスが実行時に新しいエージェントタイプをスポーンしたり、エージェントの設定を変更したりする能力を指していると考えられます。

説明文にある「超知性への道（path toward superintelligence）」というフレーミングは、技術的な主張としてではなく、アーキテクチャ上の展望として読むべきです。具体的なエンジニアリング上の価値は、エージェントのオーケストレーションにOSの抽象化アプローチを採用している点にあり、これはアドホックなマルチエージェントフレームワークよりも厳密です。この抽象化が敵対的なワークロードや高度な並列ワークロードのもとで成立するかどうかは、未解決の実証的問題です。

Source: https://github.com/miuuyy/Octopus-SI-OS

pullboard-dev/pullboard

Pullboardは、ガバナンスが整備された自律的な開発システムです。ワークフローはspec駆動で設計されており、プロダクトビジョンとフィーチャー仕様を宣言すると、エージェントがspecをタスクに分解して実装し、PRを提出します。その後、独立した検証エージェントがテストを実行し、マージが許可される前に受け入れ基準との照合を行います。パイプラインにおけるヒューマンゲートはspec承認の段階、すなわち「何を作るか」「どの水準で作るか」の判断に置かれており、実行と検証はエージェントが担います。

アーキテクチャ上の核心は役割の分離にあります。ビルダーエージェントは自己検証を行わず、検証エージェントは独立して動作するため、エージェントが自身の誤った出力を合理化するリスクを低減しています。これは人間のチームにおけるコードレビューの分離原則を模倣したものです。「設定するルール」のメカニズムは、おそらく宣言的なポリシー層（コーディング規約、依存関係の制約、セキュリティルールなど）に対応しており、検証エージェントがこれらを「ソフトな提案」ではなく「ハードゲート」として適用します。

DevinスタイルのシステムやSWE-agentと比較すると、Pullboardが重視するのは純粋なタスク完遂能力よりもガバナンス構造です。実行を委譲しつつも、何をリリースするかについての説明責任を保持したいチームを対象として設計されています。実際上の制約として、specの品質が出力の品質を決定するという点が挙げられます。曖昧または仕様不足の要件からは、自動検証をパスしてしまう「もっともらしいが誤った」実装が生成されます。したがって、人間の判断によるチェックポイントは形式的なものではなく、システム全体を支える本質的な役割を担っています。

Source: https://github.com/pullboard-dev/pullboard

Tejashmakwana/motionmaxxing

Motionmaxxingはエージェントスキル — 既存のエージェントフレームワーク内で使用可能なコンポーザブルなツール — であり、AIが生成した動画にモーションデザインの後処理を適用します。このツールが対象とする問題は、現在のtext-to-video出力に特有の平坦さです。すなわち、コンテンツとしては正確であっても、プロフェッショナルなモーショングラフィックスを特徴づける躍動感のある洗練さ（イージングカーブ、アンティシペーションフレーム、オーバーシュート、レイヤードタイミング、タイポグラフィアニメーションの階層構造）が欠如しているという問題です。

このエージェントスキルは、生成された動画クリップの要素のモーションパスとタイミングを解析し、パラメトリックなモーションデザインルールを適用してタイミングの調整と動きのスムージングを行うパイプラインをラップしています。このルールは、squash-and-stretch、follow-through、staged timingといったアニメーションの原則に基づいていると考えられます。出力は、After Effectsや類似のツールでモーションデザイナーが制作するものにより近いものになるはずです。

技術的な観点では、これは生成的な問題というよりも後処理とコンポジティングの問題です。ベースとなる動画はすでに生成済みであり、このスキルは抽出されたモーショントラジェクトリ、レイヤーマスク、またはoptical flowフィールドに対して動作し、タイミングの調整と拡張を行います。「エージェントスキル」というフレーミングは、スタンドアロンでの使用ではなく、より広範な動画制作エージェントからツールとして呼び出されることを意図していることを意味します。主な未解決の問題は、手動でのクリップごとのチューニングなしに、パラメトリックなルール適用が多様な生成コンテンツにわたってどれだけうまく汎化できるかという点です。

Source: https://github.com/Tejashmakwana/motionmaxxing