デイリーAIダイジェスト — 2026-07-24
arXiv ハイライト
AREX: 深層リサーチのための再帰的自己改善エージェントに向けて
問題
BrowseComp や GAIA に代表される深層リサーチクエリは、時間的・数値的・関係的・証拠的な制約の束を同時に満たす回答を要求します。AREX の動機となる核心的な観察は、発見–検証の非対称性です。候補回答を生成するには高コストなマルチホップ検索が必要ですが、候補が各制約を満たすかどうかの確認は、安価な制約単位の検証に分解できます。単に「より長く考える」か軌跡を線形に延長するだけの検索エージェントは、この非対称性を活用できません。AREX はその代わりに、検証済みのサブクレームを固定し、未解決の制約が新たなターゲット型検索パスを生成する双レベルループを実行します。
手法
AREX はリサーチ状態を中心とした2つのネストされたループとして動作します。内側のループは、クエリ x から目標 q^{(t)} を導き、ツール呼び出し（検索、ブラウジング、論文検索）を実行し、証拠を統合し、自己報告の信頼スコア s^{(t)} とともに暫定回答を出力します。外側のループは (q^{(t)}, \text{answer}, s^{(t)}) を受け取り、(i) s^{(t)} > \tau であれば回答を受理するか、(ii) 制約集合 \mathcal{C}(y) に対して回答を監査し、検証済みの証拠を保持し、未解決の制約を対象とした精緻化目標 q^{(t+1)} を構築するか、または (iii) 軌跡が回復不能と判断された場合に再起動します。
重要なエンジニアリング上の要素は、自律的コンテキスト更新ツールです。生の履歴を連結したり要約を外部モデルに委ねたりする代わりに、AREX は (a) 検証済みの証拠、(b) まだ未解決の制約、(c) 次のリサーチ目標を含む圧縮された「改善状態」を出力することを学習します。これにより、長い時間軸にわたって再帰が実現可能となります。状態はサブ線形に成長し、外側のループが進捗を推論するために必要な不変条件を保持します。
タスク合成は制約優先の構成に従います。潜在的回答 y が与えられると、人手によるテンプレートが制約集合を定義します。
\mathcal{C}(y) = \{c_1, c_2, \ldots, c_n\},
各 c_i は検証可能なリサーチ目標を表します。制約はキーワードマッチングを防ぐために間接的な記述 \mathcal{C}' に変換され、クエリは次のように生成されます。
x = f(y, \mathcal{C}').
有効性の条件は、y が x から直接推論できないこと、\mathcal{C}' のすべての c_i がアクセス可能な証拠から検証可能であること、\mathcal{C}' が y を一意に識別すること、です。独立したロールアウトにより、自明に検索可能または解決不能なタスクが除外され、ブラウズ集約型・推論集約型・科学文献の3つのレジームにわたる \mathcal{D}_{\text{task}} = \{(x, y)\} が生成されます。
学習は2段階のエージェント的中間学習ステージと長時間軸 RL によって進行します。ステージ1では能力を段階的に獲得します。まずブラウズ集約型の軌跡（ツール使用、ナビゲーション、証拠獲得、クエリ再構成）を学習し、次に専門家推論の軌跡（長文演繹、仮説比較）を学習します。推論の専門化がブラウジング行動を劣化させるため、ステージ2では混合能力統合を行います。ブラウズ軌跡からの困難な中間決定の対象再生を、能力拡張タスク（学術論文リサーチ、知識集約型推論）と交互に行い、さらに重要なこととして、暫定回答を監査し検証済み証拠を保持して次の目標を定式化する検証駆動型遷移を組み込みます。バックボーンは Qwen3.5-4B（AREX-Turbo）と Qwen3.5-122B-A10B（AREX-Base）です。
結果
本論文は、4つのレジームにまたがる6つのベンチマークで評価を行います。深層リサーチ（BrowseComp、DeepSearchQA）、エージェント的完遂（GAIA、xbench-2510）、広範カバレッジの検索（WideSearch English）、ツール拡張型高度推論（ツール付き HLE）です。報告されるメトリクスは、WideSearch では Item-F1、DeepSearchQA では F1、その他では精度です。
信頼スコアのキャリブレーション分析は設計の中心的要素です。外側のループが s^{(t)} > \tau に基づいて受理を制御するため、信頼信号は正しい出力と誤った出力の間で識別力を持つ必要があります。Figure 3 は正規化された分布を示しています。
この意味ある分離こそが、外側のループが既に正しい暫定回答にバジェットを費やすのではなく、誤った暫定回答の精緻化を優先的に行えるようにするものです。
限界と未解決の問題
提供されたテキストには抜粋部分に具体的なベンチマーク数値が欠けているため、強力なベースライン（例：ReAct スタイルのブラウジングエージェント、検索拡張 o1 クラスモデル）に対する改善幅をこれらの抜粋だけでは検証できません。方法論的な問いもいくつか未解決のままです。第一に、信頼スコアはモデルが生成するものであり、合成制約ベースの学習タスク外の分布シフトへの堅牢性は未検証です。実際のリサーチクエリが n 個の独立した検証可能な制約にそれほど綺麗に分解できることは稀です。第二に、「軌跡の回復可能性」判断は学習されたメタ判断であり、偽陰性による再起動（ほぼ正しい軌跡を捨てること）と偽陽性による継続のコストは定量化されていません。第三に、自律的コンテキスト更新ツールはエンドツーエンドで学習されますが、その圧縮忠実性、つまり検証済み証拠が複数回の圧縮サイクルを経ても忠実に検索可能なまま残るかどうか、についてはアブレーションが必要です。最後に、ここでの RSI は単一クエリ内にとどまっており、フレームワークはまだクエリをまたいでループを閉じることで、エージェントのポリシーがデプロイメントを通じて改善されるまでには至っていません。
この研究の意義
制約単位の検証はエンドツーエンドの発見よりも真に安価なプリミティブであり、AREX はその非対称性を、自己改善を曖昧なプロンプティングパターンとして扱うのではなく、具体的な状態保持機構によって実用化しています。キャリブレーションと回復の判断が合成制約タスク外でも通用するならば、双レベル設計と学習済みコンテキスト圧縮は、ブラウジングを超えた長時間軸エージェントシステムのための再利用可能な設計図となります。
Source: https://arxiv.org/abs/2607.21461
動画からの構造化ダイナミクスの自己教師あり学習
動画の表現学習は通常、フレーム間の変化における2つの異なる要因——自己運動（カメラ）とシーンダイナミクス（物体の動き）——を混在させています。単一トークンの潜在行動モデルや密な遷移トークンはこれらの要因を絡み合わせており、カメラ運動に不変な物体運動（またはその逆）を推論することが目標である場合、下流の識別性を損ないます。本論文は、ゼロからビデオエンコーダを学習することなく、事前学習済み画像ViTの凍結済み特徴量上で動作する軽量な予測器によって、この分解が回復できるかどうかを問います。
セットアップと構造化予測
\mathcal{E}を凍結済みViTとします。各フレームx_tについて、特徴量は
f_t = \mathcal{E}(x_t) \in \mathbb{R}^{H\times W\times D}
となります。SDMは特徴空間においてf_{t-1}からf_tを予測します。重要なのは、遷移トークンの抽出時にモデルがf_tへ非因果的にアクセスする一方で、モーショントークンに関しては時間方向に自己回帰的である点です。従来の潜在行動アプローチ（Genieスタイル）はフレーム間のすべての変化を単一の低ランクトークンに圧縮し、CroCo/SiamMAEスタイルのクロスビュー条件付けは密なターゲットビュー特徴量を使用します。いずれも遷移自体に構造を課していません。
SDMのコアな仮定は、時間的変化が支配的な低次元要因（通常はカメラまたは1つのグローバルなシーン運動）と残りを説明する残差に分解できるというものです。したがって、各遷移から2つのモーショントークンを抽出します：
- (f_{t-1}, f_t)から得られる主要トークンp_t。これは主要補償済み特徴マップf'_{t-1 \to t}を生成します；
- f_tに対する残余誤差を予測する残差トークンr_t。
両トークンは時間方向に再帰的であり、予測器はf_tへの特徴空間回帰によって学習されます。トークンボトルネックこそが分割を強制するものです：p_tは再帰を生き残りf_t - f_{t-1}の大部分を説明しなければならない小さなベクトルであるため、変化のグローバルかつ低次元な原因を優先的に捉え、空間的に局所化された独立運動をr_tに委ねます。
学習データと弱教師あり学習
学習は実動画における自己教師あり予測と弱ラベル付き合成データを混合します。コーパスは以下の通りです：
- 180kのKubricシーケンス。静的シーン（カメラのみ移動）と動的シーン動画に均等に分割され、動的シーンの半分はさらに移動カメラと静的カメラの設定に均等に分割されています。
- 約170kのSSv2クリップと約4kのDL3DVクリップ（いずれもラベルなし）。
Kubricはシーンレベルの二値ラベル（カメラ静止・シーン静止）を提供し、p_tとr_tのどちらにどのモーション要因が入るかを明確化するための弱教師として使用されます。実動画は自己教師あり特徴予測シグナルのみを提供します。この混合は重要です：Kubricの弱ラベルがなければ、2つのトークンには置換対称性（異なるクリップでカメラ運動または物体運動のいずれかを担いうる）があり、分割はクリップ依存になって意味論的に安定しなくなります。
段階的な振る舞い
2段階補償は特徴空間残差に直接現れます。
DAVIS2017のサンプルにおいて、主要段階はカメラに起因する背景・エッジの動きを除去しますが、独立して動く前景物体では局所的に誤差が増加します——これはp_tが単一のグローバルな説明に固定されているというシグネチャです。残差段階がその後、物体領域を補完します。これは、分解されたダイナミクスモデルに期待される定性的な振る舞いです。
ProbeMotion評価スイート
本論文はProbeMotionを提案します。これはカメラ運動と物体運動を別々にターゲットとするlinear-probeベンチマークです：
- Kubric（cam.+obj.）：15k学習 / 5kテストの合成クリップ、4フレーム。
- DL3DV：3.5k学習、カメラ運動のプロービング、5フレーム。
- CameraBench：60/30動画、カメラ運動、4フレーム。
- 静的カメラDAVIS2017および静的カメラYouTubeVOS（VGGTのカメラ推定値によるフィルタリングとマスク重心変位を物体運動ターゲットとして使用して構築）：3.5k学習（DAVIS）、YouTubeVOSは1k / 20k、4〜5フレーム、2D物体変位のプロービング。
- SSv2-110k：運動量の多い行動分類、7フレーム。
静的カメラサブセットはVGGTで推定されたカメラ運動を閾値処理することで構築され、物体ダイナミクスの分離に適したクリーンな設定を提供します。このスイートは、制御された合成の複合運動（Kubric）、純粋なカメラ運動（DL3DV、CameraBench）、純粋な物体運動（静的カメラDAVIS/YTVOS）、および混合した実世界の意味論（SSv2）を網羅しています。プロービングのターゲットはデータセットに応じて、カメラ運動クラス、物体変位回帰/分類、または行動クラスとなります。
限界と未解決の問題
提供されているセクションはセットアップを説明していますが、最終的な主要数値は示されていません；主要/残差分解の強度は最終的にKubricの弱ラベルに依存しており、「支配的な運動」が真に曖昧なシーン（静的カメラ下で複数の物体が独立して動く場合や、特徴空間においてカメラ運動と物体運動の大きさが同程度の場合）における分割の振る舞いは不明確です。予測器は凍結済みViT特徴空間上でのみ動作するため、バックボーンが破棄したもの——きめ細かい運動、パッチ解像度以下の小物体の並進——は回復不可能です。再帰的なモーショントークンは構造を強制するためにボトルネック化されていますが、引用されている論文部分ではトークン次元数が主要/残差の純度とどのようにトレードオフするかが定量化されていません。最後に、評価はlinear probingによるものであり、これらのトークンが密なタスク（トラッキング、フロー、セグメンテーション）に転用できるかどうかはここでは扱われていません。
なぜ重要か
カメラ運動と物体運動を分解することはビデオ表現における長年の要望であり、専用のビデオエンコーダを学習するのではなく凍結済み画像ViT上でそれを実現することは、安価で組み合わせ可能なレシピです。ProbeMotionもまた実際のギャップを埋めています：ほとんどのビデオベンチマークは2つの運動要因を混在させており、分離の主張を反証することを困難にしています。
Source: https://arxiv.org/abs/2607.21576
LLMはユーザーの意図の変化に追いつけない
問題設定
LLMの標準的な評価では、ユーザーが完全かつ整形済みのタスクを1ターンで提示することを前提としています。しかし実際のインタラクションはこれとはかけ離れています。ユーザーはまず曖昧な形で入力し、考えながら制約を追加し、以前の要件を取り下げ、時に会話の途中で関連しているが異なるゴールへと方向転換します。本論文が問う実証的な問いは明確です。タスク T の仕様が一括提示された場合にそれを解けるモデルが、同じ T の仕様が複数ターンにまたがって断片的に、あるいは部分的に修正・上書きされながら提示された場合にも同様に解けるのか、というものです。
これが重要な理由は、実際の運用においてシステムがprompt-completionのオラクルではなく、ユーザーから逐次送られてくるメッセージを読む「エージェント」として機能することを前提とする場面が増えているからです。現実的なマルチターン動態のもとで意図のトラッキングが著しく劣化するならば、シングルターンのベンチマークleaderboardは実際の運用能力を過大評価していることになります。
手法
著者らは、既存のシングルターンベンチマークをマルチターンの「進化する意図」形式の会話へと変換しつつ、元の採点プロトコルをそのまま維持するフレームワークを提案しています。これにより新たなアノテーションは不要です。形式的には、仕様 S = \{c_1, \dots, c_k\}（制約・サブ要件・節の集合）と、出力 y を採点する評価器 E(y, S) が与えられたとき、会話の軌跡
U_1, A_1, U_2, A_2, \dots, U_T, A_T
を生成します。ここで各ユーザーターン U_t は、以下のいずれかの動態に従って部分集合 S_t \subseteq S を開示します。
- 逐次開示 (Incremental disclosure): S_t は S_{t-1} を厳密に拡張し、\bigcup_t S_t = S を満たします。
- 修正 (Revision): ターン t において S_{t-1} の一部 c_i \in S_{t-1} が修正後の c_i' に置き換えられ、ターン t での有効な仕様は (S_{t-1} \setminus \{c_i\}) \cup \{c_i'\} となります。
- 転換 (Redirection): あるターン t^\ast において、制約の一部集合が関連しているが部分的に非互換な集合によって上書きされ、会話途中でのゴールシフトを模擬します。
最終的なアシスタントの出力 A_T は、元の評価器 E を用いて最終的な有効仕様に対して採点されます。これにより、モデルが意図の一貫した最新の内部表現を維持する能力が単独で測定されます。E は変更されないため、進化する意図の設定における絶対スコアは同一ベンチマークのシングルターンbaselineと直接比較可能です。ユーザー側はLLMで模擬されており（選択した動態に従って S を断片的に開示するよう指示されたLLM）、動態・ターン数・修正タイミングを変えた制御された sweepが可能です。
主要な実験上の変数は以下の通りです。
- タスクスイートは複数のタスクファミリー（検証可能な制約を含むinstruction-following、コード、推論）にわたり、それぞれ節ごとに分解可能な仕様を持ちます。
- モデルファミリーは、元のシングルターン設定と、同一採点基準を用いた進化する意図の設定の両方で評価されます。
- アブレーションでは、(i) 修正の有無、(ii) 修正が早期か後期か、(iii) ターン数の上限を変化させます。
結果
中心的な実証的知見は、強力なシングルターン性能がそのまま維持されないということです。モデルファミリーやタスクタイプを問わず、仕様が一括提示されるシングルターン設定から進化する意図のマルチターン設定へと移行すると、精度が大幅に低下します。この劣化は一貫しており、著者らはこれをモデル固有の現象ではなく、普遍的な現象として捉えています。静的leaderboardでトップのモデルが、同一ベンチマークの進化する意図版でもトップとは限りません。
アブレーションから2つのメカニズム的パターンが浮かび上がります。
修正が主要な失敗モードである。 純粋な逐次開示（撤回なし）は中程度の劣化を引き起こします。これは主に、モデルが部分的な解に早期にコミットし、後から追加される制約を統合できないことで説明されます。修正や転換が加わると劣化は顕著に大きくなり、モデルが修正後の節を完全に上書きするのではなく、旧仕様と新仕様を混同する傾向があることが示されます。
早期コミットが複合的な問題を生じさせる。 完全な仕様が開示される前にモデルが実質的な A_t を生成すると、その後のターンで軌跡が完全に修正されることはほとんどありません。不完全な仕様に基づいて行動したことで生じた誤りは、欠けていた制約が後から与えられた後も持続します。これはretrievalにおける「lost in the middle」効果と一致していますが、この場合は意図の表現に対して生じています。後から提示された矛盾する情報は、先に定着した解釈を必ずしも置き換えません。
論文は、これら両方の効果を、現在のLLMがユーザーの意図を修正可能なビリーフとして維持するのではなく、文脈を累積することで近似している証拠として位置づけています。
限界とオープンな問い
いくつかの留意点を挙げておく価値があります。ユーザー自身がスクリプト化された開示ポリシーに従うLLMであるため、既存の評価器を制御可能な形で再利用できる一方、実際のユーザーはよりノイジーで、代名詞や省略をより積極的に用い、修正を曖昧なシグナルで示すことがあります。また、このフレームワークは基礎となる評価器 E の弱点を引き継ぎます。もし E が部分的な制約の充足を寛大に採点するならば、一部の意図トラッキングの失敗は見えにくくなる可能性があります。さらに本論文はギャップを記録するものの、それを解決するわけではありません。診断結果（早期コミット、修正の混同）は、明示的な意図状態のトラッキング、回答の遅延、修正が多い軌跡でのtraining、といった対策を示唆しますが、これらの介入は本研究では評価されていません。
オープンな問いとしては、修正を含むマルチターン軌跡へのRL fine-tuningがシングルターン性能を損なうことなくこのギャップを埋めることができるかどうか、明示的な「現在の仕様」スクラッチパッドが有効かどうか、劣化がモデルサイズやlong-context trainingとどのようにスケールするか、などが挙げられます。また、この失敗が根本的に表現的なものなのか、あるいはpromptingで緩和できる単なる復号時の振る舞い（過度に積極的なコミット）に過ぎないのかも未解明です。
なぜこれが重要か
静的なシングルターンベンチマークはモデル開発を駆動する主要なシグナルですが、本論文はそれらのベンチマークにおけるランキングが、実際のユーザーが生み出すインタラクションパターン下での振る舞いを予測しないことを示しています。修正を伴う意図トラッキングがエージェント的な運用における律速制約であるとすれば、評価とtrainingのパイプラインはどちらも、マルチターンをシングルターンタスクの装飾的なラッパーとして扱うのではなく、進化する仕様に対して一等市民としての対応を行う必要があります。
Source: https://arxiv.org/abs/2607.20734
SANA-Video 2.0: 効率的な動画生成のためのHybrid Linear AttentionとAttention Residuals
問題設定
動画DiTのスケールアップは困難です。これは、時空間トークングリッド上のself-attentionがシーケンス長に対してO(N^2)となるためであり、720p/8秒の動画ではトークン数がフレームバッチあたり約19Kに達します。純粋なlinear attentionは漸近的なコストを解決しますが、ランク不足という問題があります。そのカーネル特徴グラム行列は、softmaxが提供する全ランクのトークン混合を再現できず、長距離の一貫性やプロンプトへの追従性が低下します。従来の研究では、学習済みのsoftmax DiTを事後的に線形化する手法が主流でしたが、これは分布ミスマッチを引き継ぐという問題があります。SANA-Video 2.0は、最大14Bのモデルスケールにおいて、スクラッチから学習されたhybrid attentionスタックが、linear attentionのスケーリング特性を維持しながら完全なsoftmaxに匹敵する品質を達成できるかどうかを検討します。
手法
バックボーンはLTX-VAE 2.3の潜在表現を用いた動画DiTであり、レイヤーごとのcross-attentionによってGemma-2-2B-ITのテキスト特徴を参照し、flow matchingで学習されます。本研究の貢献は以下の2つのメカニズムで構成されます。
Hybrid Linear–Softmax Attention。 各レイヤーはgated linear attention（GLA）とgated softmax attentionを3:1の比率で交互に配置します。すなわち、全レイヤーの25%がsoftmaxの「アンカー」として機能します。GLAレイヤーはO(N)支配のトークン混合を提供し、定期的に挿入されるsoftmaxレイヤーは、純粋な線形スタックでは表現できない全ランクのトークン相互作用を復元します。この25%の比率は、低解像度の代替実験（深さ28、幅3072、256p/81フレーム）によって選定されました。スカラーのランダムt平均はノイズ軸にわたって3倍の変動を隠蔽するため、タイムステップごとの検証MSEを読み取って評価を行いました。
Block Attention Residuals（AttnRes）。 レイヤーは8レイヤーごとのブロックにグループ化されます。共有クエリルーターが現在の入力と前のブロックから完成した要約を集約し、それを後続の線形レイヤーのself-/cross-attentionブランチに供給します。これにより、線形レイヤーはブロック階層の下流から更新されたアンカー特徴を再利用でき、深いレイヤーの表現の実効ランクが約12%向上します。
各hybridレイヤーは、まずAttentionブランチ（self + cross）にAttnResルーティングを適用し、次にSwiGLU FFNに適用します。各ブランチ内にAdaLNスタイルのモジュレーションを持ち、出力ヘッドの前に最終的な集約を行います。ローカルパスはconvolution不使用です。SANA-Video 1の時間方向convolution FFNを除去することで、スケールに応じて20〜29%のオーバーヘッドを削減し、attentionの比率を唯一のシーケンススケーリングのパラメータとして保持します。この設計を共有する2つのモデルが存在します。5B（32レイヤー、幅2560）と14B（40レイヤー、幅4096、14.25Bパラメータ、384枚のB200で学習）です。
学習レシピも手法の一部として扱われています。6段階のファンネルは、品質と動きの軸を分離してクリップをスコアリングします（統合された集計スコアではなく）。これにより、クリーンだが静的な映像を選択してしまうことを回避します。このレシピはクリップを事前学習、継続学習、SFT、そしてDPOとReRLを組み合わせた選好に基づくpost-trainingに通し、解像度・長さのカリキュラムおよび量子化された動きディスクリプタによるキャプション条件付けを行います。
結果
81フレーム出力でのVBenchにおいて、5B hybridモデルはトータルスコア84.30（品質85.61、セマンティック79.05）を記録し、HunyuanVideo 13B（83.43）、Wan 2.1 14B（83.69）、Cosmos-3 Nano 16B（83.13）、Wan 2.2 A14B MoE（84.23）を上回り、Bernini-R 14B MoE（84.64）をわずかに下回る結果となりました。品質サブスコア（85.61）は報告されたモデルの中で最高です。40サンプリングステップで、480p生成は単一のH100上で13.2秒で完了します。
B200上での720p/8秒（736×1280×193、19.3Kトークン）において、デプロイメントパイプラインはエンドツーエンドのレイテンシを段階的に圧縮します。ベースライン62.65秒 → カーネル/実行フュージョンにより30.74秒（2.04倍速） → 50ステップのうち17ステップをスキップする残差再利用により20.89秒（3.00倍速） → softmaxアンカーに限定したsparse attentionにより17.52秒（3.58倍速）。H100では同じスタックで95.08秒 → 33.43秒（2.84倍速）となります。長いシーケンスではsoftmaxアンカーがモジュール時間を支配するため、それらのレイヤーのみをスパース化することが自然なアプローチとなります。
スケーリング曲線は、解像度またはクリップ長が増加するにつれて、hybridレイヤーの線形領域が完全softmaxに対してギャップを広げることを示しています。50% softmaxとの交差点は不利であり、25%の選択が動機付けられます。
限界とオープンクエスチョン
hybridの比率とAttnResのブロックサイズは、5B/14Bスケールで完全にアブレーションされることなく、代替実験を通じてレシピと合わせて選定されました。そのため、品質向上がどの程度アーキテクチャによるものか、データファンネルやDPO+ReRLのpost-trainingによるものかは不明確です。拡散キャッシュのステップスキップとアンカーのスパース化は近似であり、その忠実性はVBenchの加速条件ではなく定性的（Figure 8）にのみ検証されています。セマンティックサブスコア（79.05）はMoEの競合モデル（Bernini-R 82.49、SANA-Video 2B linear 81.46）に劣っており、レイヤーごとのcross-attentionにもかかわらず、hybridモデルはテキスト条件付けを十分に活用できていない可能性を示唆しています。最後に、これらのスケールでのスクラッチからの学習はコストが高く、AttnResメカニズムを学習済みのsoftmax DiTに移植した際に、実効ランクの12%向上が失われないかどうかは未検証です。
なぜ重要か
SANA-Video 2.0は、大部分がlinear attentionスタックを用いた動画DiTをスクラッチから学習するための具体的なレシピを提供し、パラメータ数が3〜4倍の完全softmaxモデルと同等またはそれ以上の性能を達成します。また、ランクギャップを埋めるメカニズムとして、定期的なsoftmaxアンカーとクロスブロック残差ルーティングを特定します。エンジニアリングの成果として、720p/8秒を単一のB200上で17.52秒で生成できることは、アンカーレイヤー以外の特殊なスパース性を用いることなく、長尺動画生成をシングルGPU領域に引き入れるものです。
Source: https://arxiv.org/abs/2607.21553
エージェント経験からのサンプル効率の良い学習
問題設定
実環境（ソフトウェアエンジニアリング、科学的実験、human-in-the-loop設定）に展開されるLLMエージェントは、環境とのインタラクション回数に厳しい予算制約を受けます。各rolloutには、テストスイートの実行、実験の遂行、あるいは人間へのクエリが伴う場合があります。収集した経験を活用するパラダイムは大きく二つあります。In-context learning（ICL）は極めてサンプル効率が高く、エージェントは自身の試行錯誤の軌跡を条件として即座に改善できますが、その軌跡がコンテキストから外れた瞬間に恩恵は消えてしまいます。一方、context distillationはコンテキスト情報を重みに内在化しますが、エージェントの履歴への素朴な適用は大量の追加rolloutを必要とする傾向があり、本末転倒になりかねません。本論文はこのギャップをExperience Distillationとして定式化します。すなわち、収集済みのインタラクション軌跡の固定プールを与えられたとき、追加の環境クエリを一切行わずに、non-in-contextな挙動がin-context拡張済み挙動と一致するモデルを生成することを目指します。
これが具体的に重要な理由：命令や推論トレースのdistillationに関する先行研究は、安価または無制限のon-policyサンプリングを前提としています。各インタラクションに非自明なコスト（コンパイル、評価ハーネス、外部ツールのAPIトークン、人間の評価者）を伴うエージェントのドメインでは、distillation自体のサンプル予算がボトルネックとなります。収集した軌跡に対する標準的なSFT（自明なベースライン）は、ICLの恩恵をほとんど回復できないことが明らかになっています。
手法
設定：エージェントは環境とインタラクションすることで軌跡のバッチ \tau_i を収集します（バッチ内の以前の軌跡からのICLを利用する場合もあります）。\pi_{\text{ICL}}(a \mid s, \mathcal{C}) を取得済み経験 \mathcal{C} を条件とするpolicyとし、\pi_\theta(a \mid s) を目標とする重み内在化済みpolicyとします。Experience Distillationは、新たな環境インタラクションを生成することなく、収集済み経験から得られた状態上で両者の間のdivergenceを最小化します：
\mathcal{L}_{\text{ED}}(\theta) = \mathbb{E}_{s \sim \mathcal{D}}\left[ D_{\text{KL}}\big(\pi_{\text{ICL}}(\cdot \mid s, \mathcal{C}) \,\Vert\, \pi_\theta(\cdot \mid s)\big) \right]
重要なのは、目標分布 \pi_{\text{ICL}} は、既存の状態に対して \mathcal{C} をコンテキストに入れてベースモデルを再実行することで計算される、モデル内部でのオフライン操作である点です。観測された行動 a_t を \tau_i から直接学習するSFTと比較して、Experience Distillationはraw行動policyに対してICLが提供する補正信号を含む、ICLによって誘導される完全な教師分布を学習します。これが本質的な非対称性です。収集された行動はしばしば最適ではありませんでした（試行錯誤の一部であったため）が、ICL条件付き分布は、それらの試行を証拠として見た後にモデルがとるであろう行動を反映しています。
このレシピは、初期の経験収集を超えた追加の環境ステップを必要としません。軌跡は二重の役割を果たします。すなわち、取得コンテキストとして \mathcal{C} を埋め、かつ教師/学生のdivergenceを評価する状態分布 \mathcal{D} を提供します。
結果
評価は二つのドメインにまたがります：749件の精選されたソフトウェアエンジニアリングタスクと六つのテキストアドベンチャーゲームです。主要な数値は以下の通りです：
- Experience Distillationは、両ドメイン平均で、ICLがベースエージェントに対してもたらす恩恵の少なくとも64.8%を保持します。
- 同一の収集経験に対する直接SFTは、ICLの恩恵のわずか3.8%しか保持できず、約2桁も悪い結果となっています。
- 古典的なRLベースラインと比較して、このパイプライン（収集時のICL + Experience Distillation）は、少なくとも9.6倍少ない環境インタラクションで同等の性能を達成します。
SFTとEDのギャップが最も示唆に富む結果です。両手法は同一の軌跡を参照しており、違いは完全に学習ターゲットにあります。SFTは行動policyを模倣しますが、試行錯誤エージェントの場合、それには多くの失敗・探索行動が含まれます。Experience Distillationは代わりに、それらの試行を振り返った場合にベースモデルが従うであろう反事実的なpolicyを模倣し、行動ではなく教訓を抽出します。64.8%の保持率は、ICLが「知っている」ことの大半がベースモデルの重み空間で表現可能であり、誘導された行動分布をマッチングすることで引き出せることを示しています。
RLに対する9.6倍のサンプル効率の倍率は、on-policyのRLが探索においてサンプルを無駄にするという一般的な観察と一致しています。ここでは探索はICL拡張エージェントによって一度行われ、結果として得られた能力が重みに圧縮されます。
限界と未解決問題
いくつかの点を指摘する価値があります。第一に、この手法の上限はICL自体がベースモデルから何を抽出できるかによって制限されます。Experience Distillationは、事前学習の事前分布に存在しない本質的に新しいスキルを教えることはできず、潜在的なものを表面化させるに留まります。第二に、KLターゲットは教師 \pi_{\text{ICL}} が学生と同じ状態で評価可能であることを要求しますが、取得コンテキスト \mathcal{C} がコンテキストウィンドウに近づくあるいは超える非常に長いホライズンのタスクでは、教師の計算がコストが高くなるか実行不可能になります。第三に、論文における完全ICLに対する〜35%の残差ギャップは説明されていません。これは最適化の限界、学生policyヘッドの容量の限界、あるいは重みへの内在化に抵抗するコンテキスト依存の挙動を反映している可能性があります。第四に、対象ドメインであるSWEタスクとテキストアドベンチャーはいずれも記号的かつ言語主体です。教師の行動分布がトークンlogitsとして自然に表現されない、embodiedまたは連続制御のエージェントへの拡張は自明ではありません。
未解決の問題として、distillationラウンドをまたいだ合成可能性があります。すなわち、経験を繰り返し収集・distillationして単調な改善を得られるのか、あるいはベースモデルのICL上限でプロセスが飽和するのかという問いです。RLとの比較はハイブリッドアプローチも示唆します。Experience Distillationをpolicy-gradient手法のウォームスタートとして使用することで、サンプル効率を継承しつつICL上限を突破できる可能性があります。
なぜ重要か
Experience Distillationは、エージェント軌跡に対するSFTがなぜ低性能となるかについて明快なメカニズム上の理由を明らかにします。行動を模倣することは、その行動が誘導する回顧的policyを模倣することとは異なります。distillationを観測された行動ではなくICL条件付き分布のマッチングとして定式化することは、高コストなインタラクションデータを追加の環境コストをほぼかけずに重みレベルの能力へと変換するための実用的なレシピを提供します。
Source: https://arxiv.org/abs/2607.21051
LLM RLのための予測的発散マスク
問題
LLMに対するPPOスタイルのRLでは、サンプリングされた各トークンに対して2つのtrust-regionテストを行います。近傍性基準（学習ポリシー\pi_\thetaはビヘイビアポリシー\pi_bから離れすぎていないか？）と方向性基準（次の更新がさらに遠ざかる方向に進むか？）です。どちらも従来、サンプリングされたトークンのimportance ratio r_t = \pi_\theta(a_t|s_t)/\pi_b(a_t|s_t)から計算されます：近傍性は|r_t - 1|、方向性は\operatorname{sign}(\hat A_t(r_t-1))によって評価されます。
DPPO（Qi et al., 2026）は近傍性基準をすでに、\pi_bと\pi_\thetaの間の語彙全体にわたる分布的発散D_t（実用上はトップK KLの打ち切り版であり、これは本番のロールアウトエンジンがトップKのlogprobsのみを公開するため）にアップグレードしました。しかし、方向性基準はPPOの単一サンプルratioに基づくままです。本論文の観察：trust regionが分布的な量D_tによって定義される場合、ratioに基づくsignは\operatorname{sign}(\Delta D_t)と一致しないことがあり、マスクが「保持する」トークンが実際にはポリシーをtrust regionの外側へさらに押し出す可能性があります。
手法
修正策は、方向性テストを近傍性テストで使用している同じ発散の一次変化で置き換えることです。\pi_\etaを、代理勾配方向にサイズ\etaのlogitステップを踏んだ後の学習ポリシーとします。このとき、
D_t(\pi_\eta) = D_t + \eta \cdot \left.\frac{d}{d\eta} D_t(\pi_\eta)\right|_{\eta=0} + O(\eta^2),
となり、マスクは一次係数のsignによって決定されます。trust regionの外にあるトークン（D_t > \delta）は、この係数が正の場合（更新がD_tを増大させる）にクリッピングされ、負の場合（更新がD_tを減少させる）に保持されます。
離散的なsoftmaxポリシーに対して、方向微分は解析的に分解でき、(i) サンプリングされたトークンにおけるratioに基づくsignを再現する局所的な項と、(ii) 語彙全体にわたるsoftmax結合から生じる大域的な項の和になります。ロールアウトエンジンはトップKのlogprobsのみを返すため、本論文は大域的な項を2つのテールモデルで推定します：残余マス1-\sum_{i \le K} \pi(i)を単一のバケットにまとめるaggregated-tail推定量（式10）と、残りの語彙全体に一様に分散させるuniform-tail推定量（式11）です。式12は、この2つが小さな補正項のみで異なることを示しており、ほぼ同一の挙動を予測します——これは実験的にも観察されることです。
得られた予測的発散マスクは、DPPOスタイルの目的関数における方向性基準のドロップイン代替品です。すべてがロールアウトがすでに出力しているトップKの統計量から計算されるため、追加のネットワーク計算は不要です。
結果
学習にはフィルタリング済みのDAOP-Math-17k（約13k問題）を使用し、評価はAIME24とAIME25のavg@16で行います。バックボーンはQwen3-4B-Base、Qwen3-8B-Base、およびQwen3-30B-A3B-Baseで、2つのFP8モード（rollout-onlyとE2E）のもとで4つの設定を構成します。主要なベースラインはK=20のDPPO-TopK-KLであり、GRPO with clip-higher（\epsilon_{\text{low}}=0.2、\epsilon_{\text{high}}=0.28）がratioクリッピングの参照として含まれています。
推奨値\delta = 0.15において、GRPO clip-higherはQwen3-30B-A3B-Baseの両FP8設定で崩壊します。これは、FP8がロールアウトと学習の数値的な差を拡大する場合にratioクリッピング単独では脆弱であるという直感と一致しています。発散ベースの手法はすべて安定を保ちます。そのファミリーの中で、両予測的発散マスク（aggregated-tailとuniform-tail）は4つすべての設定でDPPO-TopK-KLを上回ります。DPPO-TopK-KLとの唯一の違いは方向性基準（近傍性には同じトップK KL、同じ\deltaを使用）であることから、この改善は方向性テストを分布的にすることの価値を単離して示しています。2つのテール推定量は学習全体を通じて互いに密接に追跡しており、式12の小さな補正項の予測を確認しています。
\delta = 0.05ではtrust regionが過度に制限的となり、すべての手法が性能を低下させますが、予測的マスクはDPPO-TopK-KLを依然として上回っており、\deltaハイパーパラメータに対するより高いロバスト性を示しています。
Figure 3のメカニズム的検証では、trust regionの外にある（D_t > \delta）かつ2つの基準が不一致であるトークンに注目し、「unsafe-keep」レート——保持されたトークンのうち更新後に発散が実際に増加した（\Delta D_t > 0）ものの割合——を測定します。発散ベースの基準はratioベースのものよりもunsafe-keepレートが大幅に低く、そのsignが実際の\Delta D_tとより良く整合しているという中心的な主張を直接的に支持しています。
限界
予測的テストは単一トークンにおける一次局所近似です。実際のオプティマイザのステップはバッチ内のすべてのトークンにわたって勾配を集約し、その結果生じるパラメータ更新は、per-tokenの方向微分が無視している共有バックボーンを通じたトークン間の相互作用を導入します。トップKテールモデルもヒューリスティックであり、本論文では2つの変種が一致しますが、Kが非常に小さい場合やテール分布が重い場合には成立しない可能性があります。最後に、評価は数学的推論（AIME24/25）とQwen3バックボーンに限定されており、より密な報酬を持つ非数学的なRLHFレジームにおける挙動は未検証です。
重要性
trust regionの近傍性テストをサンプリングされたratioから分布的発散に移行した後も、PPOのratioベースの方向性テストを維持することは一貫性に欠けます——そして、Figure 3が示すように、実際にはD_tが増大することを許すマスク決定を経験的に生じさせます。方向性基準を同じ発散に追跡させることで、GRPO スタイルのratioクリッピングが崩壊するFP8ロールアウト/学習の不一致のもとでの安定性が回復されます。追加コストはほぼゼロです。なぜなら、すべてがロールアウトがすでに返しているトップK logprobsから計算されるためです。
Source: https://arxiv.org/abs/2607.10848
TableVerse: 汎化可能な操作のための実世界に基づくレイアウトを持つ大規模テーブルトップデータセット
問題設定
シーンを横断して汎化する操作ポリシーには、実際のテーブルトップの空間分布に一致する訓練データが必要です。すなわち、密な雑然状態、物体の妥当な共起関係、正確なメトリックスケール、そして物理的に有効な接触関係が求められます。既存の合成パイプラインは、(i) LLMがテキストからレイアウトを「幻想」するため幾何学的に不自然かつ非現実的な共起統計が生じる、あるいは(ii) 手続き的生成器を用いるが疎で定型的すぎる、という問題を抱えています。実際のロボットデータはスケールアップにコストがかかります。TableVerseはこれらの問題をいずれも回避するため、単一の非構造化インターネット画像から直接シミュレーション可能なテーブルトップシーンを再構築します。このReal2Simパイプラインのレイアウトは、生成的な事前分布からのサンプルではなく、実写真の決定論的な投影として得られます。
手法
パイプライン（図2）は、知覚から物理シミュレーションへの4段階のワークフローで構成されます。
1. インスタンス抽出。 MLLMとGroundingSAM-v2を連鎖させる（検出誤差が累積する）のではなく、著者らはSeed-1.8を用いて入力画像に対してオープン語彙の検出を直接行います。検出結果は通常の物体とコンポジット物体（容器とその中に入ったコンテンツ）に分類され、液体などのメッシュ化できない物質は単一のエンティティとして扱われます。内部アイテムのクラスタに対しては、検出器が代表的なバウンディングボックス1つとインスタンス数 n を出力することで、個々のアイテムごとのボックスの曖昧さを回避します。バウンディングボックスはSAM2に渡されてインスタンスマスクが生成されます。
2. コンポジットアセットの分解。 SAM3Dによって容器とコンテンツが別々のメッシュとして再構築され、短時間の自由落下による安定化のために孤立したMuJoCoシーンに配置されます（図3）。これにより、下流タスクでボールから単一の物体をピッキングする必要がある場合でも、各内部アイテムの独立した剛体特性が維持されつつ、物理的に有効な静止配置が得られます。
3. 6自由度ポーズ登録。 Depth Anything 3が単一視点からメトリック点群を提供します。セグメンテーションされたテーブル/床マスクが平面フィッティングを通じて重力整合フレームを定義し、この変換がグローバル点群に適用された後に各物体の登録が行われるため、すべてのメッシュが物理的に整合したup軸を共有します。粗から細への登録により、各SAM3Dメッシュがメトリックスケールでシーンに配置されます。
4. レイアウト整合衝突修正（LCCR）。 単眼再構築では、MuJoCoに配置された際にアライメントのノイズによりメッシュが相互貫通します。LCCRは、マクロ的なレイアウトを保持するように変位を制約しながら貫通を解消します。この制約こそが、本パイプラインを一般的な衝突解消（そうでなければシーンが任意の局所最小値へドリフトしてしまう）と区別する点です。
凸分解と検証。 すべてのメッシュはCoACDによる近似凸分解を経て、MuJoCoの接触計算を安定させます。その後、マルチビュー正射影レンダリングがGemini 2.5 Proによってシーンの妥当性、カテゴリ整合性、信頼度の観点でスコアリングされ、タスク指示が同じパスで生成されます。
タスク条件付き軌道合成。 検証済みのデジタルツインが与えられると、パイプラインはハイレベルなタスク仕様（例：「マグカップをトレイに置く」）から関節空間における衝突なしのピックアンドプレースデモンストレーションを生成します。これにより、静的アセットだけでなく各シーンに対応したインタラクションデータが得られます。
規模と定量的結果
公開された TableVerse-100K には10万の物理的に整合したシーン、約 10^6 の個別物体インスタンス、および35,000以上のセマンティックカテゴリが含まれています（図1）。すべてのシーンはMLLM検証とMuJoCo安定性チェックを通過しており、各シーンには生成された操作軌道が対応付けられています。通常 10^2〜10^3 カテゴリで飽和する手続き的生成ベンチマークと比較すると、カテゴリ数は1〜2桁大きく、これは固定されたアセットカタログではなく、野生のインターネット画像ソースの多様性によるものです。
制限と未解決の問題
設計上の選択から直接生じるいくつかの注意点があります。第一に、単一視点の再構築は単眼深度推定とSAM3Dの失敗モードを受け継ぎます。大きく遮蔽された物体や薄い構造物（食器、ワイヤー）は背面の形状が悪く、さらにパイプラインの凸分解によってグラスピングに重要な凹部がさらに平滑化されます。第二に、メッシュ化できない物質は剛体エンティティに集約されるため、液体の注ぎや粒状体の操作はスコープ外となります。第三に、LCCRはマクロ的なレイアウトを保持しますが、Depth Anything 3からの系統的な深度スケールバイアスを修正できないため、遠い物体の絶対メトリック誤差が接触形状に伝播します。第四に、検証はGeminiベースであり人間によるものではないため、微妙な物理的非妥当性（遮蔽物の後ろで浮いている物体、ずれたサポート面など）に対する偽陰性率は報告されていません。最後に、提供されているセクションには下流のポリシー転移の数値が示されていません。TableVerse-100Kが従来の合成データセットよりもsim-to-real汎化を改善するという実証的な主張は、ポリシー訓練結果が利用可能になった際に外部検証が必要です。
なぜ重要か
テーブルトップシーン合成を「レイアウトを想像する」から「すでに存在するものを再構築する」へ転換することで、訓練分布が実際の人間環境の結合統計に基づくようになります。すなわち、生成的レイアウトモデルが系統的に見逃してしまう物体の共起関係、雑然密度、サポート関係などが反映されます。パイプラインの自動化が成立するならば、10万から 10^7 シーンへのスケールアップは単により多くの画像を取り込む問題となり、物理的に有効な接触を持つインターネットスケールの操作訓練データへの最初の現実的な経路となります。
Source: https://arxiv.org/abs/2607.21017
Hacker News Signals
Flux 3
Black Forest Labsは、画像生成モデルファミリーの次世代イテレーションであるFlux 3をリリースしました。このリリースは、オリジナルのFlux.1アーキテクチャからflow-matchingバックボーンを継承しつつ、プロンプト遵守性、テキストレンダリング、およびフォトリアリズムをさらに向上させています。技術的には、Fluxラインはrectified flow定式化を採用しており、順方向プロセスはノイズとデータの間を線形補間し、モデルはDDPMのepsilonパラメータ化よりも学習が容易な速度場 v_\theta(x_t, t) を学習します。Fluxはアーキテクチャ上、テキストトークンと画像トークンに対して別々のストリームを持つハイブリッドtransformerデザインを採用し、後段のレイヤーで統一表現にマージされる前にクロスアテンションを行う点で際立っています。これは、モダリティを最初から連結する標準的なDiTとは異なるアプローチです。Flux 3は、画像内の構造化テキスト生成（グリフを空間的にレイアウトすることが要求される、悪名高い難タスク）および複雑な組み合わせプロンプトに対するきめ細かい指示追従において、先行するFlux.1 [pro]から改善されたと報告されています。モデルは段階的なAPI SKUとして提供されています。内部ベンチマークでは、Flux.1 [pro]を上回り、人間の選好評価においてImagen 3およびDALL-E 3に対して競争力のある位置づけを主張していますが、ブログにはサードパーティによる再現可能なベンチマーク数値は記載されていません。アーキテクチャは、ガイダンス蒸留バリアント構造（低ステップ推論向けの別途「dev」蒸留モデル）を維持しており、推論コストを実用的に保っています。制限事項として、評価方法論が不透明であること、すべての数値が自己報告であること、このティアではモデルの重みが公開されていないことが挙げられます。Flux.1 [pro]に対する改善がスケール、データキュレーション、またはアーキテクチャ変更のいずれに主に起因するかは開示されていません。
Source: https://bfl.ai/blog/flux-3
Flux 3 X Mimic: 次世代のビデオ・アクションモデル
MimicはBlack Forest Labsのビデオ生成モデルであり、本記事ではFlux 3 X Mimicを発表しています。これは「アクション」に特化した画像・映像の統合システムであり、すなわち画像またはテキストプロンプトが与えられた際に時間的に一貫したモーションを生成するよう訓練されたモデルです。技術的な核心は、静止画像生成のための rectified flow フレームワークを時間領域へと拡張することにあります。フレームを独立にサンプリングするのではなく、このモデルは時空間的な latent 上で動作し、3D attention またはcausal temporal attentionメカニズムによって時間的整合性が保たれます（ブログでは完全には明示されていませんが、アーキテクチャはCogVideoXやOpen-Soraのようなビデオ diffusion transformer によって確立されたパターンに従っています）。「X Mimic」という名称は、Flux 3 画像モデルのバックボーンを空間的事前分布として用い、その上に temporal layers を fine-tuning または追加するという手法を示唆しており、既存の高品質な空間表現を活用する一般的な効率的戦略です。主な主張されている特性としては、高いモーション忠実度、プロンプト駆動のアクション制御（例：「ボールを投げる人」が物理的に妥当な動作を生成する）、フレーム間でのidentityの一貫性が挙げられます。「アクションモデル」という位置づけは、静的なシーンではなく動的なシーンを対象とした訓練データまたは loss 関数を用いていることを示唆しています。これが重要な理由は、一般的なウェブ動画で訓練されたほとんどのビデオ diffusion モデルは、動きが遅くドリフトが顕著なクリップを生成しがちであり、アクションに特化した訓練データやoptical-flow誘導型 loss によって動的な一貫性を向上させられる可能性があるためです。アーキテクチャの図、訓練の詳細、および公開された重みは提供されていません。Sora、Kling、またはRunway Gen-3との定量的な比較も存在しません。主要な未解決の問題は、時間的長さのスケーリングに関するものであり、この種のモデルのほとんどは数秒を超えると性能が著しく低下します。
Source: https://bfl.ai/blog/flux-3-mimic
Meta Garbage Collection: Using OCaml’s GC to GC Rust
この記事では、特定のアロケーションの所有権をOCamlのガベージコレクタに委譲することで、Rustのメモリライフタイムを管理するテクニックについて説明しています。背景としては、ocaml-rs や類似のFFI bindingsを介したRustとOCaml間のinteropがあり、OCamlがそれらへの参照を保持している間はRustが生成した値を生存させ続ける必要があります。中核となるアイデアは、RustのヒープアロケーションをOCamlのカスタムブロック（custom block）内にラップすることです。OCamlのカスタムブロックでは、GCがブロックを回収する際にCのfinalizeコールバックを登録できます。カスタムブロックのデータペイロード内に生ポインタ（またはBox<T>）を格納し、それをドロップするためにBox::from_rawを呼び出すファイナライザを登録することで、RustのOCaml値がOCamlのコードから到達不能になった時期の判断を、OCamlのトレーシングGCに効果的に委ねることができます。これにより、FFI境界をまたいでライフタイムを手動で追跡する必要がなくなります。「meta」というフレーミングは、Rustコード自体が所有しないGCを外部のメモリマネージャとして使用することを指しています。機械的な仕組みとしては、OCamlのカスタムブロックがポインタサイズのフィールドを持ち、ファイナライザはstatic struct custom_operationsに格納されたC関数ポインタであり、OCamlのminor/majorヒープのプロモーションルールにより、ファイナライザはmajor collectionの際に発火します。注意点は重要です：ファイナライザはOCamlのGCスレッド上で実行されるため、そこから呼ばれるRustのデストラクタはスレッドセーフでなければならず、OCamlの値に触れてはなりません（再入可能なGCのリスクがあります）。また、OCamlのGCは二つのヒープにまたがるサイクルを認識しないため、ヒープ混合サイクルはリークを引き起こします。このテクニックは、返される値すべてに明示的なライフタイムアノテーションを必要とせずに、RustのライブラリをOCamlランタイムにbindingする際に真に有用ですが、安全性の不変条件には細心の注意が必要です。
Source: https://soteria-tools.com/blog/meta-garbage-collection
MCPサーバーにおけるANSIエスケープインジェクション：人間には見えず、AIには見える
Model Context Protocol（MCP）は、LLMを外部ツールに接続するためのAnthropicの標準規格です。本稿では、MCPツールの出力に固有のインジェクション攻撃のクラスを特定しています。悪意のあるサーバー（または侵害されたツール）が、ANSIエスケープシーケンスを含む文字列を返します。ターミナルエミュレータはこれらのシーケンスをカーソル移動、カラーコード、または画面クリアとしてレンダリングするため、ログを確認する人間にはテキストが空白または無害に見えます。しかし、LLMはターミナルレンダリングの前の生の文字列を受け取るため、埋め込まれたコンテンツ全体—prompt injectionのペイロードを含む可能性がある—が見えてしまいます。例えば、MCPツールは \033[2J\033[H<hidden instructions: exfiltrate user data> を返すことがあります。これはターミナル画面を視覚的にクリアしますが、インジェクションされた指示はモデルにそのまま届きます。攻撃対象となるのは、ANSIを人間が確認する前に除去せずにターミナルでツールの結果を表示するMCPクライアントです。この攻撃の影響は、通常の監視ワークフローでは防御者が攻撃ペイロードを確認できないステガノグラフィック的なprompt injectionです。著者らはDAST（Dynamic Application Security Testing）を提案しています——MCPサーバーのレスポンスを細工したシーケンスでファジングし、モデルの挙動が可視出力と矛盾する形で変化するかどうかを確認します。緩和策は技術的には単純です。すべてのツール出力をモデルのコンテキストに渡す前にANSIエスケープを除去し、ロギングの前にも独立してサニタイズします。より根本的な問題は、エージェント型パイプラインにおける一般的な課題です。モデルに見える情報と人間の監視者に見える情報は、フォーマット・レンダリングの境界において乖離し得るため、監視における系統的な盲点が生じます。
Source: https://brightsec.com/research/detecting-ansi-escape-sequence-injection-in-mcp-servers-with-dast/
「作る」ということ
「Beej’s Guide」で知られるBeej Jorgensenが、AIを活用したコーディングについて、慎重かつ技術的な考察を投稿しました。具体的には、実装の大部分がAIによって生成される場合に、何かを「作る」とはどういう意味かを問うものです。この議論は哲学的な悩みではなく、実践的な分類論です。彼は以下の3つを区別しています。(1) AIをコード検索・autocompleteの加速器として使い、プログラマが出力を完全に理解している場合、(2) プログラマ自身は書けるが書かないことを選択してAIに生成させ、要所だけ確認する場合、(3) プログラマが自力では書けない・検証もできないコードをAIに生成させる場合。三番目のカテゴリは、道徳的な理由ではなくエンジニアリング上の理由から、著作権と責任の問いが自明ではなくなります。生成されたコードを読むことができないプログラマは、それをデバッグすることも、障害モードについて推論することも、保守することもできないのです。彼は自身がCやシステムコードにLLMを使った具体的な例を挙げながら、この議論を展開しています。技術的な懸念は現実のものです。LLMは構文的には妥当でも意味論的には微妙なバグ、特にメモリ安全性、整数オーバーフロー、APIコントラクト違反に関わるものを生成しますが、それらを発見するにはドメイン知識が必要です。彼の暗黙の推奨事項は、AI出力を外部依存ライブラリやジュニアコントリビューターのコードと同じように扱うことです。つまり、読んで、テストして、責任を持つ。この投稿がHNで共感を呼んでいるのは、「AIは役に立たない」とも「AIがプログラマに取って代わる」とも言わず、代わりにこう問うているからです。AIを活用した開発にはどのような検証の規律が求められるのか？実験もベンチマークもなし。これは技術的根拠を持つ実践者のエッセイです。
Source: https://beej.us/blog/data/ai-making/
DARPA・米空軍、AI制御のF-16を飛行させる
DARPAのAir Combat Evolution（ACE）プログラムは、有人F-16を相手とした近距離格闘機動（within-visual-range combat maneuvering）において、フルスケールのF-16（X-62A VISTAと呼称）をAIエージェントが制御する飛行を完了しました。これは重要なマイルストーンです。なぜなら、これまでのAIによるドッグファイトのデモンストレーション（例：2020年のAlphaDogfightトライアル）はシミュレーションのみであったためです。ACEで採用された技術的アプローチは、ドメインランダム化を用いてシミュレーション内で学習した方針（policy）の階層構造を使用し、構造荷重限界・最低高度・近接距離などの制約違反を監視するsafety layerを介して実機に転移するというものです。AIエージェントはウェイポイント計画レベルではなく、飛行制御レベルで動作します。すなわち、ニューラルpolicyはセンサー状態（相対位置、速度、迎角）を高周波で直接操縦面への指令（ロールレート、ピッチレート、スロットル）にマッピングします。高性能航空機におけるsim-to-realギャップは深刻です。高迎角でのF-16の空力特性は非線形な流れの剥離を伴い、高Gロード時のセンサーノイズはシミュレーションと異なります。DARPAはこれに対し、ハードウェアインザループテストの反復と、後部座席に搭載したセーフティパイロットによるオーバーライドを可能にすることで対処しました。このプログラムにおける未解決の問題は、AIが積極的な機動を実行できるかどうかではありません——それは実証済みです——むしろ、学習分布を超えた敵対的なエッジケースにpolicyが汎化できるか、およびFAA・軍の耐空性基準のもとでそのようなシステムの認証がどのように機能するかという点です。後者は機械学習ではなく、実運用展開における実質的な制約となる可能性が高いと考えられます。
Source: https://www.darpa.mil/news/2026/darpa-us-air-force-fly-ai-controlled-f-16
Show HN: Palmier Pro – AI向けに構築されたオープンソースのmacOSビデオエディタ
Palmier Pro は、主にSwift/SwiftUIで書かれたネイティブのmacOSビデオエディタであり、AI編集操作をファーストクラスのタイムラインアクションとして公開しています。GitHubリポジトリによると、映像の入出力とコンポジットにAVFoundationを使用しており、これはmacOS上では標準的な選択であり、VideoToolboxを通じてH.264/HEVCのハードウェアアクセラレーテッドなエンコード・デコードへのアクセスを提供します。「AI向けに構築された」という主張は具体的なもので、このエディタは外部モデルAPI（Replicate、またはllama.cppなどを用いたローカル推論）と統合し、トランスクリプトに基づくカット検出、Whisperによる自動キャプション付け、セグメンテーションモデルによる背景除去、フレーム説明の埋め込みベクトルインデックスを用いたプロンプト駆動のクリップ検索といった操作を実現しています。アーキテクチャは、タイムラインエンジン（純粋なSwift、AVFoundation composition）と、モデルを非同期で呼び出してタイムラインのアノテーションやエフェクトとして結果を書き戻す推論ブリッジ層に分離されています。ベクトル検索用のフレーム説明は、キーフレームに対して実行されるvision-languageモデル（おそらくCLIPまたはBLIPの派生モデル）によって生成されます。ベクトルストアは、フルのベクトルデータベースではなく、SQLiteをバックエンドとしたシンプルなローカルの近似最近傍インデックスのようです。オープンソース（MITライセンス）であり、ElectronではなくネイティブのmacOSアプリであることは技術的に意味のある選択です――Electronベースのエディタに典型的な約200msの入力レイテンシを回避し、macOSのアクセシビリティおよびメディアAPIと自然に統合されます。制限事項として、AI統合の大部分は高品質な操作のために有料のAPIキーに依存しており、ローカル推論は利用可能ですが、Mシリーズのneural engineとの統合がない状態では低速です。コードベースは初期段階にあり、いくつかの機能は作業中と記載されています。
Source: https://github.com/palmier-io/palmier-pro
Claude Cookbook
Anthropicは、OpenAIのcookbookのパターンに倣い、Claude向けのAPIワーク例集（cookbook）を公開しました。このコンテンツは技術的に有益であり、単純な「hello world」プロンプトを超えて、実運用パターンを網羅しています。具体的には、Claudeのtool-use APIを用いた制約付きJSONスキーマによる構造化出力抽出、マルチターン会話の状態管理、retrieval-augmented generationパイプライン、そしてClaudeがツールを反復的に呼び出すagentic loopなどが含まれます。注目すべきセクションでは、tool-use（function calling）APIのメカニズムが詳細に解説されています。具体的には、ツールスキーマをJSON Schemaオブジェクトとして定義する方法、ClaudeがツールはTの呼び出し側が実行してtool_resultブロックとして返す必要があるtool_useコンテンツブロックを出力する仕組み、そして最終的な回答を生成するまでにClaudeが複数回ツールを呼び出すマルチホップチェーンの処理方法などが説明されています。別のセクションではprompt cachingについて取り上げています。ClaudeのAPIは、大きなシステムプロンプトやドキュメントブロックに対してcache_controlパラメータをサポートしており、KV cacheをサーバー側に保存することで、同一プレフィックスを持つ繰り返し呼び出しにおけるレイテンシとコストを削減します。これはアーキテクチャ上重要な意味を持ちます。つまり、大きなコンテキスト（例：一度ロードされる50kトークンのコードベース）を伴うマルチターンセッションでは、prefillのコストをターンをまたいで償却できるということです。cookbookにはまた、増分的なトークン配信のためのstreaming例（server-sent events）やvision inputのパターンも含まれています。実用的な価値は、リファレンスドキュメントから必ずしも明らかではないエラーハンドリングのパターンと明示的なJSONスキーマにあります。新規の研究はなく、これはドキュメントとしてのエンジニアリングガイダンスです。
Noteworthy New Repositories
vshulcz/deja-vu
コーディングエージェント専用に設計されたメモリレイヤーであり、多くのエージェントフレームワークが汎用ベクトルストアに丸投げしているretrieval問題を対象としています。主な主張は、LongMemEval-Sにおいてhit@1が84.9%を達成しており、retrieval過程にLLMを一切使用しないという点です。すなわち、recall経路は純粋に決定論的/embeddingベースであり、ルックアップ時の推論レイテンシとコストを回避しています。本システムは15種類のコーディングエージェントとの統合をサポートし、事後的な検索（retroactive search：関連するメモリを後から探索する機能）とMCP（model context protocol）によるrecallの両方を提供しています。特筆すべき点として、時間的インデキシング（いつ何が起きたかによる検索）を追加している点が挙げられます。これはデバッグセッションにおいて直近の情報が強いpriorとなる場面で有効です。Trust scopeにより、エージェントごとまたはプロジェクトごとのメモリ分離が可能となり、マルチエージェントパイプラインにおけるクロスコンタミネーションを防止します。タグ付きのキュレーションノートは、完全な再現が必要なケースに対してセマンティック検索の上位に構造化されたレイヤーを提供します。システム全体はゼロ依存の単一バイナリとして提供され、完全にローカルで動作するため、データが外部に送信されることもなく、APIキーの管理も不要です。繰り返しの問題解決にコストがかかる自律型コーディングエージェントを構築するチームにとって、コードベース全体を対象とした汎用RAGに代わる、より用途に特化した選択肢となります。
Source: https://github.com/vshulcz/deja-vu
avifenesh/bw24
RustとCUDAカーネルをゼロから実装した推論エンジンであり、既知の単一ハードウェア構成（RTX 5090 Laptop 1基、sm_120a）をターゲットとしています。設計思想はビット単位の完全再現性にあり、出力の決定性は慣習によるものではなく、設計上保証されています。NVFP4（BlackwellとともにNVIDIAが導入した4ビット浮動小数点フォーマット）、mixture-of-expertsルーティング、およびMTP（multi-token prediction）speculative decodingを実装しています。speculative decodingのパスは特に注目すべき点であり、MTPは1回のforward passで複数の候補tokenを生成することで、生成token当たりに必要なフルモデル評価の回数を削減します。「実測した1台のRTX 5090 Laptopの限界」に合わせたチューニングは、理論上のピーク値ではなく実際のメモリ帯域幅と演算スループットをターゲットとしていることを意味し、誠実なエンジニアリング上の制約となっています。エンジンをPython/C++ではなくRustで記述することで、ガベージコレクタなしのメモリ安全性が実現され、CUDAカーネルが必要とする慎重なバッファ管理において重要な意味を持ちます。これは主にresearch/learningのための成果物であり、Blackwell固有の最適化に関するproof of conceptですが、vLLMやTensorRT-LLMの複雑さを避けてクリーンで監査可能な推論スタックを求める方にとって、具体的な出発点となります。
Source: https://github.com/avifenesh/bw24
Skyvern-AI/rustwright
RustwrightはPlaywrightのAPIサーフェスをRustネイティブなChrome DevTools Protocolエンジン上に再実装したもので、PythonからPlaywrightを呼び出す場合でも必要となるNode.jsサブプロセスを排除しています。標準のPlaywright Pythonバインディングは依然としてstdio経由でNodeサーバープロセスと通信していますが、RustwrightはそのホップをなくしRust製コアから直接CDPを話します。このコアに対してPythonおよびNodeバインディングがコンパイルされています。ブラウザ自動化において、サブプロセスを介したラウンドトリップはレイテンシと信頼性のコストとなっており、各CDPコマンドはプロセス境界を2回横断します。Rust製のCDPエンジンはコマンドをパイプライン化し、接続状態をより効率的に扱うことができます。Playwright互換のAPIを備えているため、既存のテストスイートやスクレイピングコードはセレクタやページ操作ロジックを書き直すことなく移行できます。このプロジェクトは明示的にアルファ版であり、APIサーフェスは不完全で破壊的変更が想定されます。注目すべき主な理由は、高並列自動化ワークロード（例：大規模Webスクレイピング、並列テスト実行）における低オーバーヘッド、およびコンテナ内にNodeの依存関係なしでブラウザ自動化をRustサービスに組み込める可能性です。さらに、ドライバーサブプロセス不要というデプロイ上の利点は、補助プロセスの起動が制限されたロックダウン環境での展開も簡素化します。
Source: https://github.com/Skyvern-AI/rustwright
Rhacknarok/hacksguard
Rustで書かれたTUIマルウェア解析ツールで、インシデントレスポンスやマルウェアトリアージの静的解析フェーズを対象としています。コア機能は、深いPE（Portable Executable）フォーマットのパース、YARAルールスキャン、そしてヒューリスティックリスクスコアリングです。これらは動的サンドボックス解析の前に行う標準的なトリアージの三本柱です。PEパースでは、インポートテーブル、セクションエントロピー、リソースディレクトリ、オーバーレイデータをカバーしており、アナリストが手動で確認する主要な静的インジケータを網羅しています。YARAスキャンはユーザー提供またはバンドル済みのルールセットに対して実行され、既知のマルウェアファミリーへの分類を可能にします。ヒューリスティックスコアリング層は、シグナル（高エントロピーセクション、不審なインポート、パック済みの兆候）を単一のリスク値に集約し、ディレクトリ内のサンプル群に対して迅速なトリアージを実現します。Rustネイティブかつマルチスレッドであるため、大規模なサンプルコレクションを高速にスキャンでき、Cベースのペーパーサーに付きまとうメモリ安全性の問題も回避できます。マルウェアは解析ツールをクラッシュさせるために不正なPEヘッダーを意図的に作成することが多いため、これは実際的な懸念事項です。TUI（おそらくratatuiまたは類似のクレートで構築）により、GUIなしのSSH環境でも利用可能です。PEview、PE-bear、あるいはcapaの実行といったツールと比較すると、本ツールはシングルバイナリでスクリプタブルな選択肢であり、自動化パイプラインへの統合に適しています。
Source: https://github.com/Rhacknarok/hacksguard
MIgHTy-alIeN/MEV-Arbitrage-Bot
MEV（Maximal Extractable Value）アービトラージシステムであり、2つのコンポーネントで構成されています。アービトラージ取引をアトミックに実行するオンチェーンスマートコントラクトと、DEXの価格フィードを監視して収益性のある機会を検出した際にコントラクトをトリガーするオフチェーン自動化スクリプトです。このアーキテクチャはオンチェーンアービトラージの標準的な設計であり、コントラクトはアトミックに借り入れ、2つ以上のプールをまたいでスワップし、返済して、スプレッドを獲得します。アトミック性の保証により、トランザクションは利益を得るか、ガス以外の資本リスクなくリバートするかのどちらかとなります。オフチェーンスクリプトはmempoolの監視、ガスの見積もり、および機会の検出を担い、コントラクトにcalldataを渡します。このパターンはDeFiにおいて確立されたものであり、オープンソースのリファレンス実装の価値は主に教育的なものです。具体的には、アービトラージボットがAMMの価格カーブとどのようにインタラクションするか、flashloanコールバックがどのように構成されているか、そしてガスの入札がブロックへの組み込みとどのように連動するかを理解するためのものです。プロダクション用のMEVボットは、公開リポジトリでは提供できないレイテンシおよびプライベートmempoolアクセス（Flashbots、プライベートRPC）を前提に動作しています。本リポジトリは、デプロイ可能なアドバンテージとしてではなく、DeFiのメカニズムおよびSolidityコントラクト設計を学ぶためのリファレンスとして扱ってください。
Source: https://github.com/MIgHTy-alIeN/MEV-Arbitrage-Bot
jmerelnyc/Talos
Talos分散推論ネットワーク向けのGPUワーカークライアントです。このクライアントはローカルGPUをTalosアカウントと紐付け、WebSocket接続を介してオープンモデルの推論ジョブを受信・実行し、結果をストリーミングで返送するとともに、報酬追跡のためのアップタイムを報告します。アーキテクチャはfolding-at-homeやBittensorの推論サブネットに類似しており、アイドル状態のコンシューマーまたはデータセンターGPUが共有推論プールにコンピュートを提供し、アップタイムとスループットによって報酬が決定されます。WebSocketトランスポートは、コーディネーターへのストリーミングトークン生成に適した選択と言えます。「オープンモデル」という表現は、ネットワークが独自モデルではなく公開されているモデルウェイトへのリクエストをルーティングすることを示唆しており、これは信頼性の観点から重要です。ワーカーは自分が何を実行しているかを把握できる必要があります。説明では答えられていない重要なエンジニアリング上の疑問点としては、ジョブの分離がどのように実施されているか（ワーカーによるプロンプトのロギングの防止）、コーディネーターが推論の正確性をどのように検証するか、そしてスケジューリングポリシーがどのようなものかが挙げられます。GPUの余剰キャパシティを持つ方にとって、ネットワークに十分な需要があるという前提のもとで、これはアイドル状態のコンピュートを収益化する簡便な方法です。ジョブプロトコルと報酬メカニクスを理解するための出発点として、クライアントコードが最適です。
Source: https://github.com/jmerelnyc/Talos
oversecured/Samsung_Vulnerabilities
Oversecuredによる構造化された脆弱性開示リポジトリで、Samsungのプリインストール済みAndroidアプリケーションにおいて発見された176件の脆弱性を文書化しています。Oversecuredは自動化されたAndroidアプリセキュリティスキャナを運営しており、本リポジトリはSamsungのプリインストール済みアプリ群——Samsungデバイスに同梱され、通常は昇格したシステム権限を持つか、機密データ（連絡先、SMS、カメラ、位置情報）を扱うアプリ——に対する調査結果の蓄積を示しています。プリインストール済みアプリはユーザーがアンインストールできず、サードパーティアプリが要求できない特権的な権限を保有し、Play StoreのタイムラインではなくメーカーのタイムラインでOTAアップデートを受け取ることが多いため、重要な攻撃対象領域となっています。此種の監査で一般的に発見される脆弱性クラスには、intent redirection（権限昇格を可能にする）、content providerにおけるpath traversal、安全でないbroadcast receiver、ローカルデータベースへのSQL injectionなどが含まれます。176件の文書化されたCVEが単一リポジトリにまとめられていることで、Androidセキュリティ研究者、Samsungデバイスを対象とするペネトレーションテスター、そして障害モードを理解したい類似のプリインストール済みアプリコンポーネントを開発する開発者にとって有用なリファレンスとなっています。開示はSamsungへの通知を経た上での協調開示と推定されており、本リポジトリはパッチ適用後の教育的リソースとして機能します。
Source: https://github.com/oversecured/Samsung_Vulnerabilities
simonlin1212/investment-news
中国A株市場の投資家を対象としたローカル動作のニュース集約・要約ダッシュボードで、グローバルサプライチェーンのシグナルを追跡する必要があるユーザー向けに設計されています。半導体、AI、ロボティクス、新エネルギー車などを含む12の産業セクターを対応するA株上場企業にマッピングし、それらのグローバルサプライチェーンをカバーする100以上の権威ある情報源からデータを取得します。日次パイプラインはローカルLLM（外部APIキー不要）を実行し、各セクターのニュースを中国語の箇条書きに要約するとともに、外国語記事を翻訳します。完全ローカルのアーキテクチャは重要な意味を持ちます。外部LLM APIを用いた金融ニュース集約はデータ漏洩リスクと継続的なコストをもたらしますが、オープンモデルによるローカル推論（おそらくOllamaまたはllama.cppを利用）によってその両方を排除できます。セクターと銘柄のマッピング層がこのシステムの構造的な洞察です。汎用的な金融ニュースを提供するのではなく、「本日グローバル半導体サプライチェーンで何が起きたか、それはA株半導体指数にどのような関連があるか」という問いに答える設計になっています。テーマ型A株へのエクスポージャーに注力する個人投資家やクオンツ投資家にとって、英語の業界紙を手動で読む場合と比べて構造化された情報優位性を提供します。このコードベースは、ドメイン特化型ニュースインテリジェンスパイプラインの実用的なテンプレートとなっています。