デイリーAIダイジェスト — 2026-08-28
arXiv ハイライト
PAWBench: 確率的に整合した世界モデリングにはどこまで到達しているか？
問題
ビデオ生成モデルはますます世界モデルとして位置づけられるようになっていますが、標準的な評価では単一のロールアウトを視覚的妥当性に基づいて採点しています。コイン投げ、サイコロの目、ボールがコーナーで跳ね返るといった任意の確率的過程において、常に同じ終端状態を生成する世界モデルは誤りであり、この誤りは単一サンプルのメトリクスでは検出できません。本論文はこの失敗モードを確率的整合性の欠如として形式化しています。すなわち、初期観測 x とアクション a が与えられたとき、モデルの条件付き分布 P_M(\tau \mid x,a) は、未来にわたる真の分布とサポートおよび質量の両面で一致しなければなりません。
手法
PAWBench はモデル M を評価するにあたり、固定された (x,a) ペアのもとで K=50 個の i.i.d. ロールアウトを生成し、各ロールアウトを離散集合 \mathcal{Y} 上の終端結果にマッピングして、\mathcal{Y} 上の経験分布 \hat p_M を構成します。ソース画像とアクションプロンプトの両方を固定することで、ロールアウトの分散がモデルの誘導分布に起因するものとなります。
50 のシナリオは 2 つのトラックに分割されます（図 2）：
- PAW-Calibration（25 シナリオ）：投げ、回転、ルーティング、描画シナリオで、\mathcal{Y} 上の参照分布 q が解析的に指定されています（対称なサイコロには一様分布、重み付きスピナーには指定分布など）。総変動距離 \mathrm{TVD}(\hat p_M, q) でスコアリングします。
- PAW-Coverage（25 シナリオ）：衝突、安定性、エージェント間の相互作用、素材の遷移。有効な結果は列挙可能ですが厳密な確率は不明であり、K 回のロールアウトで \mathcal{Y} の要素のうち少なくとも 1 回出現した割合でスコアリングします。
2 つのトラックを分離することが設計上の核心的な選択です。calibration は誤配分された質量を測定し（すべてのサイコロの目は妥当に見えるが、4 が 80% の頻度で出る）、coverage は欠損モードを測定します（サイコロで 5 や 6 が一度も出ない）。単一のスカラー値ではこれらを区別できません。
結果はルーブリックベースの VLM judge である PAWEval によって抽出され、各ロールアウトを読み取ってスキーマ内のラベル（例：Head / Tail）を出力します。シーンは結果読み取りゲートである Scene Pass Rate（SPR）をパスするのは、50 ロールアウトのうち少なくとも 20 回が読み取り可能なラベルを生成した場合のみです。SPR 統計量は、解析不能な動画を生成することでモデルが高スコアを得ることを防ぎます。
結果
HappyHorse、Veo 3.1 Fast、Kling 3 Std.、Seedance 2、Wan 2.2/2.7、LTX-2.3/2.5、Cosmos 3 Super I2V、LingBot-Video-MoE、MiniMax H3 の計 11 のシステムがデフォルトの推論設定のもとで評価されています。
参照確率に一貫して一致しつつ有効なサポートをカバーするシステムは存在しません。表 3（ベース行）から読み取ると：
- Wan2.2：Calibration TVD \times 100 = 26.3（SPR 64%）；Coverage 63.4%（SPR 92%）。
- Cosmos 3 Super I2V：TVD 20.5（SPR 80%）；Coverage 55.2%。
- MiniMax H3：TVD 24.2（SPR 68%）；Coverage 48.7%。
- LTX-2.5：TVD 30.2（SPR 60%）；Coverage 57.4%。
calibration シナリオにおいて、結果集合上の一様乱数 baseline は一様参照分布に対して \mathrm{TVD}\times 100 = 0 を与えますが、モデルは 20〜40 の値にとどまっており、質量を 1〜2 個の未来に強く集中させていることを意味します。50〜65% の範囲の coverage は、50 回のロールアウトで定性的に異なる有効な結果の 3 分の 1 から半分が一度も出現しないことを示しています。
介入：prompt、noise、weights
本論文では整合性を改善するための 3 つのレバーを検討しています。prompt 側では、5 つの VLM が \mathcal{Y} 上の分布サンプラーとして（動画なしで）直接クエリされています（表 2）。GLM-5V Turbo は calibration で TVD 34.8、coverage 39.9% を達成し、GPT-5.5 は 42.3 / 34.3 となっています。VLM 自体が物理的結果に対して誤ったキャリブレーションを持っているため、それらをステアリングコントローラとして使用することには上限があります。
表 3 はこれを具体的に示しています。GPT-5.5 を各ロールアウトごとに目標結果を指定する PE controller として接続すると、結果はまちまちです。Wan2.2 の calibration TVD は 26.3 から 27.1 へ（悪化）、Cosmos は 20.5 から 31.6 へ、MiniMax H3 は 24.2 から 38.9 へ悪化します。Coverage は場合によって改善されますが（Cosmos 55.2 → 64.9）、コントローラはベースモデルが本来生成できない分布構造を修正することはできません。
Oracle PE 条件（真の参照分布をコントローラに与える）は、情報的な上限を示します。Wan2.2 は TVD 15.3、coverage 76.2% に低下し、Cosmos は 12.8 / 87.3%、MiniMax H3 は 10.8 / 82.9% となります。つまり、どのような混合をサンプリングすべきかを正確に伝えられた場合、生成モデルは残留 TVD ギャップの概ね半分を埋めることができますが、oracle guided prompting でさえ 10〜20 TVD ポイントの差と不完全な coverage が残ります。これにより、残余の誤差がコントローラ側ではなく生成側に起因すること、すなわちモデルが要求された未来を忠実に実現できないことが分離されます。
限界
終端結果ラベルは軌跡情報を圧縮するため、正しい最終状態に到達しても動力学的に不可能なプロセスを経たモデルも高スコアを得ます。結果読み取りゲートは読み取り不能なロールアウトが多いシーンを除外するため、SPR と TVD/Coverage は合わせて読む必要があります。PAW-Coverage には参照確率がないため、すべての結果を 1 回ずつ出力しても質量のキャリブレーションが著しく悪いモデルも coverage で満点を得ます。|\mathcal{Y}| > 6 の結果集合に対しては K=50 は小さく、裾の coverage 推定に影響します。
なぜ重要か
ビデオ生成モデルが計画や反事実推論のための世界モデルとして機能するためには、未来の周辺分布を一致させることは望ましい特性ではなく前提条件です。PAWBench は、現在のシステム（独自モデルおよびオープンモデル）がこのテストに 20〜40 TVD ポイントの差で失敗し、有効なモードの 35〜50% を見逃しており、推論時の prompt ステアリングは oracle supervision 下でもギャップを解消できないことを初めて制御された形で測定して示しています。
Source: https://arxiv.org/abs/2608.27345
TTPO: Test-Time Policy Optimization
問題設定
数学的推論のためのpost-trainingパイプライン（検証可能な報酬を用いたRLやon-policy self-distillation）は正解ラベルを必要とするため、テスト時に利用することができません。ラベルなしの代替として自然に思いつくのは、K個のサンプリングされた軌跡に対する多数決による疑似ラベルですが、これは脆弱です。多数決の答えが誤っている場合、その投票結果に同意するすべての軌跡が正のteacher signalとして扱われ、モデルはトークンごとに誤ったターゲットへと誘導されてしまいます。難しい競技数学ベンチマーク（AIME、HMMT、BRUMO）では疑似ラベルの精度が低く、このような失敗が稀ではなく頻繁に発生するため、ナイーブなTTTループはモデルを劣化させてしまいます。
TTOは経験的な非対称性に基づいています。すなわち、正例集合（\hat{a}と一致するrollout）の信頼性は投票自体の信頼性と同程度に過ぎませんが、負例集合（\hat{a}と一致しないrollout）はほぼ常に本当に誤っています。\hat{a}が誤っている場合でも、一致しないrolloutの大部分は何か別の誤った答えを選択しています。
図の左パネルはこれを定量化しています。AIME 2026に対するQwen3-1.7BのTTT中、一致しないrolloutが誤りである割合は疑似ラベルの誤り率を大幅に上回っています。これにより、負例を強く信頼し、正例を弱く信頼する非対称な目的関数の使用が正当化されます。
手法
ラベルなしのテスト問題 x それぞれについて、K 個の軌跡 \{y_k\} \sim \pi_\theta(\cdot\mid x) をサンプリングし、a_k = \operatorname{Extract}(y_k) を抽出し、数学的同値性によってクラスタリングを行い、最大クラスタの答えを合意数 c を持つ \hat{a} とします。以下のように分割します。
\mathcal{P} = \{k : a_k \equiv \hat{a}\}, \qquad \mathcal{N} = \{k : a_k \not\equiv \hat{a}\}.
TTOは2つのブランチに対して異なるlossを適用します。
正例ブランチ — token weightingを用いたOPSD。 \mathcal{P} の軌跡は、凍結されたteacher（\pi_\theta のスナップショット）から \pi_\theta へのトークンごとのforward KLを通じた疑似teacherとして利用されます。
\mathcal{L}_{\text{OPSD}} = \sum_{k\in\mathcal{P}} \sum_{t} w_{k,t}\, \mathrm{KL}\!\left(\pi_{\text{teacher}}(\cdot\mid y_{k,<t},x)\,\|\,\pi_\theta(\cdot\mid y_{k,<t},x)\right).
token weight w_{k,t} は、studentがすでに確信を持っておりteacherと一致している位置、すなわち「収束済み」のトークンを低く重み付けします。これにより、疑似ラベルが誤っている場合でも、lossは主に依然として不確かなトークンにのみ作用し、誤った軌跡のすべての位置を強化することを避けられます。これにより、誤った \hat{a} による悪影響が制限されます。
負例ブランチ — token maskingを用いたグループRL。 \mathcal{N} の軌跡は、K 個のrolloutのバッチ内で計算されたグループ相対的なadvantageを用いたGRPOスタイルのペナルティを受けます。重要な点として、負のgradientは異常なトークン、すなわち \pi_\theta が自信を持って誤っていたポジション（コンセンサスから乖離した推論経路上のトークンに高い確率を割り当てていた位置）に対してのみマスクされます。誤った軌跡上の確信度が低いトークンはペナルティを受けません。これらは学習された誤りではなく探索的な不確実性を表しているからです。
両者を組み合わせることで、全体的なテスト時の更新は以下のようになります。
\mathcal{L}_{\text{TTPO}} = \mathcal{L}_{\text{OPSD}}^{\mathcal{P}} + \lambda \, \mathcal{L}_{\text{GRPO}}^{\mathcal{N}},
ここで \lambda はdistillationとrejectionのバランスを調整します。ノイズの多い \hat{a} のもとで安定性をもたらす2つの特性があります。(i) 正例ブランチのtoken weightingにより、誤った投票結果との一致は不確かなトークンにのみわずかな影響を与えます。(ii) 負例ブランチは「誤った答えの集合」が \hat{a} の正誤にかかわらず確実に誤っているため、十分な根拠を持ちます。学習が進むにつれて、多数決はより鋭くなり（モデルが少数の候補に確率を集中させる）、自己教師あり信号が強まります。これは外部ラベルを必要としないポジティブなフィードバックループです。
実験設定と結果
実験では、すべての線形層に対してLoRA（r=64、\alpha=128）を適用したQwen3-1.7B / 4B / 8Bを使用しています。2つの設定が評価されています。
- OpenThoughts設定: ラベル付きデータで学習されたモデル。TTOはラベルを無視し、ラベル教師あり OPSDと比較されます。
- TTT設定: （ラベルなしの）テストセット上で直接学習が行われます。
主要な主張は、TTOがいかなるラベルも使用せずに、5つの競技レベルのベンチマークにわたってラベル教師あり OPSDと同等の性能を達成するというものです。図の最右パネルは、AIME 2026、HMMT 2026、BRUMO 2025で平均化されたQwen3-1.7Bの結果を示しています。TTOはラベル付き OPSDの上限との差を縮め、多数決のみのベースラインを大幅に上回っています。後者は、動機づけの部分と一致して、疑似ラベルが不良な場合にはベースモデルを下回る可能性があります。
限界と未解決の問題
- 非対称性の議論は、多数派が反集中的なdistractorの集合となることに依存しています。特定の誤った答えが系統的に魅力的に見える問題（adversarial distractor、よくある算術ミスなど）では、負例ブランチが正しいが少数派のrolloutにペナルティを与える可能性があります。
- 本手法はテスト問題ごとに K 個のrolloutとgradient updateを必要とするため、推論時のwall-clock costは標準的なデコーディングよりも大幅に高くなります。論文では、self-consistencyのために単純に K を増加させた場合との計算量を合わせた比較は報告されていません。
- すべての結果はLoRAを用いたQwen3による数学ベンチマークのものです。コード、複数ステップのツール利用、または自由生成に対して同じ非対称性が成立するかは未検証です。
- token weightingのスキーム（収束済み正例の重みを下げ、確信度の低い負例をマスクする）はヒューリスティックであり、疑似ラベルのノイズモデルからの原理的な導出は欠如しています。
意義
TTOは教師なしpost-trainingの標準的な失敗モード、すなわち疑似ラベルノイズを、「誤ったrolloutは確実に誤っている」という特性を活用することで設計原理へと転換します。これは「正しいrolloutは疑似的にしか正しくない」場合でも成立します。これにより、難しい数学ベンチマークにおいてラベル教師ありdistillationと競合するラベルフリーな目的関数が得られ、コンセンサスが信頼できない一方で不一致が情報量を持つ場合にテスト時RL/OPSDハイブリッドが有効であることを示唆しています。
Source: https://arxiv.org/abs/2608.27448
Self-OPD: 教師なしでFlow Matchingモデルに対するOn-Policy Distillation
問題設定
On-policy distillation（OPD）は、flow matching（FM）生成器をタスク報酬に整合させるための有力な手法として確立されています。この手法では、専門化された教師がステップごとの密な速度ターゲットを提供し、学生がそれに対して回帰を行います。しかし、この方法はコストが高く——目的ごとに1つの教師が必要——さらに、学生のon-policy分布が教師の学習分布からずれていく際に誤差が累積するという問題があります。一方、軌道レベルのRL手法（Flow-GRPO、GRPO-Guard、DiffusionNFT）は教師を必要としませんが、長いODEロールアウトを通じてスパースな終端報酬信号のみを逆伝播します。
Self-OPDは、学生自身がOPDで通常教師から得るステップごとの監督を生成できるかどうかを問います。これにより、密なステップごとのターゲットを維持しつつ、教師への依存を排除することを目指します。
手法
設定は標準的なrectified flowに基づきます：確率パス x_t=(1-t)x_0+t\epsilon、速度場 v_\theta は \mathcal{L}_{\mathrm{FM}}=\mathbb{E}[\|v_\theta(x_t,t)-(\epsilon-x_0)\|^2] によって学習され、離散スケジュール \{t_j\} に沿って t{=}1 から t{\approx}0 へと逆方向に積分されます。局所的な探索を可能にするため、ODEステップをEuler–Maruyama SDEステップに変換します：
x_{t_{j+1}} = x_{t_{j+1},\theta} + \sigma_{t_j}\sqrt{|\Delta t_j|}\,z_j,\quad \sigma_{t_j}=\eta\sqrt{t_j/(1-t_j)},
実験では \eta=0.7 を使用しています。スコア恒等式 \nabla_{x_t}\log p_t(x_t)\approx -\bigl(x_t+(1-t)v_\theta\bigr)/t はドリフトを速度場に結びつけるため、x空間における摂動は速度ターゲットに対する明確に定義された摂動に対応します。
各学習タイムステップにおいて、学生は決定論的な次状態を K{=}8 個の確率的なSDEの候補に分岐させ、各分岐をODEロールアウトで最終画像まで完成させます。各ロールアウトはスコアリングされて r_k が得られ、決定論的（ノイズなし）ロールアウトによって自己参照ベースライン r^{\mathrm{ref}} が得られます。正規化されたアドバンテージ
A_k = \frac{r_k - r^{\mathrm{ref}}}{\mathrm{std}(\{r_k\})+\varepsilon}
は分岐をポジティブ（A_k>0、速度 v_+）とネガティブ（A_k<0、速度 v_-）に分類します。
lossは、分岐タイムステップにおける速度場に対する全分岐のpull–pushです：
- Pull項：v_\theta をアドバンテージで重み付けされたポジティブ速度に向けてMSEで引き寄せる。
- Push項：ネガティブ速度からの反発。ただし、方向を考慮した係数 d_k によって変調され、push方向がpull方向に反する場合はゲートされます。加えて、確率的摂動の大きさをタイムステップ間で比較可能に保つSDE分散正規化が施されます。
具体的には、更新は符号付き重み付き回帰 v_\theta \leftarrow v_\theta - \nabla_\theta \sum_k w_k\|v_\theta - v_k\|^2 のような形をとります。ここで w_k は A_k の符号、分散正規化、およびゲート d_k を含みます。監督は軌道の収益ではなく速度自体に対して行われるため、勾配は教師ベースのOPDと同様に密でステップごとに得られますが、「教師速度」は学生自身の分岐速度の報酬重み付き混合に置き換えられます。
学習にはSD3.5-Mediumを512×512で使用し、transformer上でLoRAを適用、AdamWで学習率 3\times 10^{-4}、1回の最適化ステップあたり2つの学習タイムステップを使用します。
結果
Flow-GRPOおよびGRPO-Guardとの単一報酬・教師なし比較（表1）：Self-OPDはGenEval strictで0.9536を達成し、GRPO-Guardの0.9155およびFlow-GRPOの0.9005を上回ります（ベースラインは0.5222）。OCRでは、Self-OPDは0.9745対0.9348 / 0.9253。PickScoreでは24.47対23.98 / 23.57。HPSv2では0.4099対0.3453 / 0.3396。改善は4つすべての報酬モデルで一貫しており、OCRおよびHPSv2の向上が最大の相対的な差を示しています。
単一報酬RLファインチューニングから知られるトレードオフは依然として存在します：OCRを最適化するとGenEvalが0.4186まで低下し、PickScoreのHPSv2が0.2719まで低下します。すなわち、報酬ごとの専門家モデルは目的に過学習します。Self-OPDが最も注目すべきなのは混合報酬の設定（表2）です：単一の教師なしモデルがGenEval strictで0.9521、OCRで0.9597、PickScoreで23.87、HPSv2で0.3214を達成し、GenEvalとOCRでは教師ベースのFlow-OPD（0.8594 / 0.9392 / 23.43 / 0.3042）およびDiffusionOPD（0.9150 / 0.9464 / 22.72 / 0.2676）を上回り、選好指標ではそれらに匹敵または超え、また教師なしのDiffusionNFTベースライン（0.8888 / 0.9229 / 23.67 / 0.3206）をほぼすべての軸で上回っています。
限界と未解決の問題
- ステップあたりのコスト：K{=}8 個の分岐それぞれにスコアリングのための完全なODEロールアウトが必要なため、1回の更新あたりの実効計算量が高くなります。論文ではFlow-GRPO / DiffusionNFTとの実時間比較は報告されていません。
- 自己参照ベースラインは、K 個の分岐すべてが r^{\mathrm{ref}} に近い場合に崩壊する可能性があります。分散正規化はこれを緩和しますが、信号が少ないタイムステップの問題を完全には解決しません。
- 方向を考慮したゲート d_k はヒューリスティックであり、原理的な導出（例：速度空間上のtrust-region）は存在しません。
- 報酬ハッキングは単一報酬の実行で観察されます（OCRはGenEvalとのトレードオフが生じます）。混合報酬の結果は手動で融合したスコアラーに依存しています。
- 評価は1つのバックボーン（SD3.5-Medium）上でLoRAを使用した512×512での結果であり、より高解像度やビデオFMモデルへのスケーリング挙動は未検証です。
重要性
Self-OPDは実用的なギャップを解消します：目的ごとの教師を学習することなく、教師ベースのOPDと同等の密でステップごとの監督品質を実現し、さらに単一の混合報酬モデルにおいて教師ベースのOPDと軌道レベルRLの両方を上回ります。K 個の分岐ロールアウトの計算オーバーヘッドを償却できれば、これはflow matching生成器の報酬fine-tuningにおける自然なデフォルト手法となり得ます。
Source: https://arxiv.org/abs/2608.26872
GameWAM: ビデオゲームのためのWorld Action Model
問題設定
インタラクティブなゲームモデルには、大きな隔たりを挟んで二つのファミリーが存在します。行動クローニングエージェント（VPTスタイル）は観測と指示からネイティブアクションへのマッピングを行いますが、明示的な順方向モデルを持たないため、視覚的な未来について推論することができません。一方、インタラクティブなworld model（Genie、GameNGen、およびその後継）は与えられたアクションを条件として次フレームを合成しますが、方策を生成せず、外部のコントローラーによって駆動される必要があります。World-Action Model（WAM）はこの二つの目的を統合することを目指していますが、既存のWAM研究はロボティクスや短い時間軸の操作タスクを主な対象としてきました。ビデオゲームには独自の困難があります。急激な視覚的変化を伴う一人称視点、数分間にわたる持続的なワールド状態、連続的なマウスデルタと離散的なキーイベントを混合したヘテロジニアスなネイティブコントロール、さらにフリールックのゲームプレイとモーダルGUI画面（インベントリ、クラフトテーブル）の間のモード切り替えなどが挙げられます。GameWAMは、このネイティブな閉ループ環境向けに構築された最初のWAMとして提示されています。
手法
GameWAMはロールアウトをworld-actionブロック B_j = (\mathcal{V}_j, \mathcal{A}_j) に分解します。ここで \mathcal{V}_j はビデオのlatentであり、\mathcal{A}_j = [\mathcal{A}_j^{\text{cont}}; \mathcal{A}_j^{\text{disc}}] はネイティブのキーボード・マウスベクトルです。サイクル c のブロック k における条件付けコンテキストは
\Gamma_{c,k} = (C_{c,k}, \ell, H_c, s_{c,k}),
であり、サイクル内のクリーンな観測 C_{c,k}、指示 \ell、持続的なクロスサイクル視覚履歴 H_c、およびオプションの固有感覚情報 s_{c,k} から構成されます。R ブロックのプランにわたって、モデルはブロック因果的に分解されます：
p_\theta(B_{k:k+R-1}\mid\Gamma_{c,k}) = \prod_{r=0}^{R-1} p_\theta(B_{k+r}\mid\Gamma_{c,k}, B_{k:k+r-1}).
両モダリティはflow matchingで学習されます。m\in\{v,a\} に対して、補間とターゲットは
X_{\sigma_m}^m = (1-\sigma_m)X_0^m + \sigma_m \epsilon^m,\quad U^m = \epsilon^m - X_0^m,
であり、並列なVideo-DiTとAction-DiTブランチがノイズの乗ったモダリティとコンテキストから (\widehat{U}_\theta^v, \widehat{U}_\theta^a) を予測します。推論時にはガウスサンプルから出発して \sigma=1 から 0 へとODEが積分されます。
重要な設計上の選択は、Fast-WAMスタイルのモダリティ分離型 attention maskです。対象ブロック j に対して、両ブランチは同一のクリーンな視覚プレフィックス \mathcal{P}_{c,j} = H_c \cup C_{c,j} を参照しますが、それぞれのノイズの乗った変数は互いに attention しません：
\operatorname{Vis}(\mathcal{A}_j) = \mathcal{P}_{c,j} \cup \mathcal{A}_j,\qquad \operatorname{Vis}(\mathcal{V}_j) = \mathcal{P}_{c,j} \cup \mathcal{V}_j.
Video DiTは \mathcal{P}_{c,j} を両ブランチが共有するレイヤーごとのK/Vにエンコードするため、ビデオの教師信号がアクションのデノイジングに使用されるコンテキストを形作ります。一方、オンラインでのアクションのみのロールアウトでは将来のビデオをデノイジングする必要がありません。ブロック内でのビデオ・アクションの結合 attention との ablation が §D.2 で議論されています。
ヘテロジニアスなネイティブコントロールを扱うために、GameWAMはタイムステップごとのルーターを追加します。ロジット \rho_\tau がゲームプレイモードかGUIモードかを決定し、ネイティブアクションベクトル全体に対する予測flow fieldは
\widehat{U}_\tau^a = (1-\hat{r}_\tau)\widehat{U}_\tau^{\text{game}} + \hat{r}_\tau \widehat{U}_\tau^{\text{gui}},\quad \hat{r}_\tau = [\sigma(\rho_\tau) > 1/2]
となります。連続座標と離散座標はflow生成中は一つのネイティブベクトルに保持され、離散チャンネルはサンプリング後にのみ二値決定に閾値処理されます。連続アクションの正規化（マウスデルタ）はモードごとに適用されます。
長い時間軸のインタラクションのために、ブロックサイクル制御は R ブロック先まで予測しますが、再計画前に短いプレフィックスのみをコミットします。階層的メモリは一時的なサイクルローカルK/Vキャッシュと持続的なクロスサイクル視覚履歴 H_c を組み合わせることで、バイオーム、インベントリの内容、ミッションの進捗といった長距離の状態が、軌跡全体に対してattentionを再計算することなくサイクル境界を越えて保持されます。
データ
世界とアクションの共同学習には、モードラベルを付与した整合された (o_t, a_t) ストリームが必要です。Minecraftでは著者らが共通のインタラクションタイムラインで標準化した三つのストリームを組み合わせています：(i) 広範な自然な網羅性と長い時間的コンテキストのための通常のVPTトラジェクトリ、(ii) MineStudioスタイルのインタラクションイベントを状態遷移から抽出したEvent-Anchored VPTデータセット（指示に整合したイベント中心のクリップを生成）、(iii) インターフェースの網羅のためのスクリプト化されたMineStudio GUIトラジェクトリ。イベントアンカーストリーム内のクリップサンプリングはイベントアンカー近傍で密に、遠くでは疎になっており、これはアノテーションされたイベントの直前・直後と比較して、移動や偶発的なカメラ動作が弱い教師信号しか持たないという考えに基づいています。
結果
評価には二つの閉ループベンチマークが使用されます：ネイティブコントロール下での長い時間軸のタスク成功率と実行された環境アクションを計測するMinecraft Universe（MCU）と、平均エピソード報酬によって高速な視覚的ダイナミクスを評価する四マップのViZDoomスイートです。本論文は公開されているベースラインとそれぞれの報告プロトコルの下で比較を行っています。提供されたセクションでは数値テーブルの各エントリは列挙されておらず、タスクごとの具体的な成功率と報酬の数値は公開論文の実験セクションと付録に報告されています。
限界と未解決の問題
いくつかの点を指摘しておく価値があります。モダリティ分離型maskはノイズの乗ったアクショントークンがノイズの乗ったビデオへ attention することを意図的に遮断し、またその逆も同様です。そのため生成の「共同」性は共有されたクリーンなプレフィックスK/Vを通じてのみ媒介されており、ビデオブランチが補助的なlossを超えてどれほど方策の質を実際に向上させるかは、§D.2 ablationが対処しようとしている経験的な問題です。ルーターはハードな二値スイッチであるため、モード予測の失敗はそのタイムステップにおけるモード固有のアクションベクトル全体を破棄します。イベント中心の密なサンプリングは、実際のプレイを支配する移動セグメントからの分布シフトのリスクを生じさせます。最後に、評価はMinecraftとViZDoomに限定されており、根本的に異なるコントロール体系（ツインスティック、リズム、ストラテジー）を持つゲームへの転移は未検証です。
なぜ重要か
GameWAMはネイティブで、ヘテロジニアスで、長い時間軸のインタラクションの下でのWAMの具体的な実装例であり、ブロック因果的な分離型attentionを用いたflow-matching DiTがGUIとゲームプレイの複合制御における順方向モデルと方策の両方として機能できることを示しています。公開された重みとデータが妥当であることが確認されれば、インタラクティブな環境においてビデオの未来予測がアクション選択を真に助けるかどうかを研究するための再利用可能な基盤を提供するものとなります。
Source: https://arxiv.org/abs/2608.26200
PILOT in the Loop: 長期エージェントのためのライブ自己改善
問題設定
長期エージェントの実行（数時間に及ぶシェルセッションやリポジトリレベルの修復）では、通常エピソード終了後にのみ経験が収集されます。すなわち、軌跡サマリがオフラインfine-tuning、検索メモリの更新、またはプロンプトの調整に利用されます。これに伴い、2つの失敗モードが生じます。第一に、一度行き詰まった計画に収束してしまうと、実行中の処理を修正することができません——自己批判を求められたReActワーカーは、実行と評価を同一コンテキストで混在させてしまい、軌跡が長くなるほど自己批判が劣化します。第二に、実行途中に得られた知見（例えば、20回のツール呼び出しを無駄にしたパッケージマネージャの挙動など）が、並行して実行されている兄弟タスクや、数分後に生成されるワーカーには反映されません。著者らは、自己改善はライブであるべきだと主張しています。すなわち、軌跡から得られるエビデンスが、現在実行中のワーカーを誘導しながら、同時に永続的なハーネスをその場で変化させるべきだということです。
手法
PILOTは、supervisorとworkerのハーネスです。モデルのパラメータ \theta は固定されたままで、進化するのはスキルライブラリ \mathcal{K} とメモリ \mathcal{M} からなるハーネス H = (\mathcal{K}, \mathcal{M}) です。環境 \mathcal{E} 上のタスク \tau に対して、supervisorはワーカー W_j \leftarrow \textsc{Spawn}(\theta, \tau_j, H) を（場合によっては並行して）生成します。各ワーカーは独立したコンテキストで実行され、軌跡 \xi_j を出力します。supervisorは必要に応じてのみ \xi_j の断片を参照し、冗長なツール出力ではなくゴール状態、直近のイベント、および繰り返し発生する失敗パターンに自身のコンテキストを集中させます。
この構造上で、2つの連結ループが動作します：
- ライブステアリング：supervisorは実行中のワーカーを中途で方向転換させたり中断したりすることができます。これは構造的に、subagent委譲（親が最終出力のみを観察する）とも、単一エージェントの自己修正（同一コンテキストが両方の役割を担う）とも異なります。
- ライブ自己進化：supervisorは \xi_j から手順や失敗パターンを抽出し、\mathcal{K} および \mathcal{M} の新規または改訂されたエントリとして反映させます。重要なのは、これらの更新が検証器の結果が得られる前に行われる点です——候補スキルはライブ軌跡と環境フィードバックから生成されるものであり、合否に条件付けられた事後サマリではありません。ハーネスの変異後に生成されたワーカーは、更新された H を読み込みます。
実験では、supervisorとworkerの両方に同一の固定バックボーンが用いられており、役割間の能力差ではなくオーケストレーションによる利得が分離されています。
結果
3つのベンチマーク、2つのバックボーン（GLM-5.1、Kimi-K2.6）、4〜5つのハーネスベースライン（Pi、OpenCode、Terminus-2、Hermes、Mini-SWE-Agent）で評価しています。
Terminal-Bench 2.0（89タスク）。 PILOTはGLM-5.1で71.9%、Kimi-K2.6で71.3%を達成し、平均71.6%となりました——次点のPiは66.3%です。Hardタスクに限ると、PILOTは両バックボーンで55.0%を記録し、Piの50.0%／48.3%を上回りました。対応するハーネスに対して最大9.8パーセントポイントの改善が報告されています。
SWE-bench Multilingual／Pro。 Multilingualでは、PILOTの平均は72.7%（Piの72.9%とほぼ同等）。難易度の高いSWE-bench Proでは、PILOTの平均は59.9%に対しPiは55.5%であり、Kimi-K2.6の強力な結果65.1%（Pi: 59.1%）が牽引しています。6つの設定のうち5つでPILOTが1位となっています。
Terminal-Bench 2.0での反復的自己進化。 H_i を実行をまたいで持続させ、タスクごとに環境をリセットする反復スイープを実行した結果：
- GLM-5.1は第14反復でピーク、Kimi-K2.6は第13反復でピーク。
- 反復0に対する追加通過分は、Hardタスクに集中：GLM-5.1はEasy/Medium/Hardで (+2, +6, +8)、Kimi-K2.6は (+1, +7, +12) の改善。
- スキルライブラリは62→83（GLM-5.1）、50→81（Kimi-K2.6）に増加。
- 評価対象タスク1件あたりの平均出力トークン数は、5反復窓でGLM-5.1が28.5K→16.3K（42.9%削減）、Kimi-K2.6が41.9K→22.1K（47.4%削減）。
- 出力トークン100万件あたりの成功評価数：ピーク時の改善は反復0比でGLM-5.1が110.3%、Kimi-K2.6が134.0%。
Hardタスク——バックボーンが新たに再構築できない特定の回復手順を必要とするタスク——に改善が集中していることは、\mathcal{K} が些末な情報を記憶しているのではなく、真に再利用可能な構造を捉えていることを示す最も明確な証拠です。
限界と今後の課題
- supervisorとworkerは同一の固定バックボーンを共有しており、より弱いsupervisorでも有効にステアリングできるか（あるいはより強いsupervisorが支配的になるか）はテストされていません。これは、supervisorの呼び出しがPILOTの単一エージェントハーネスに対する限界コストであり、安価なsupervisorの展開が実用的なシナリオであるため重要です。
- スキル／メモリの更新は検証器のシグナルなしで行われますが、反復的なTerminal-Bench 2.0のプロトコルは、H の蓄積に使用したタスク分布と同じ分布で評価しています。\mathcal{K} のベンチマーク間転移（例えば、Terminal-Bench由来のスキルをSWE-bench Proに適用する場合）は報告されていません。
- ワンショット設定と自己改善設定において、ライブステアリングとライブ自己進化を個別に分離したアブレーションが提供されている節には示されておらず、9.8 ppのヘッドライン数値は両機構を合算したものです。
- スキルライブラリは13〜14反復にわたって単調増加しており、スキルの劣化、矛盾の処理、あるいは約80スキルを超えた際の検索スケーラビリティの分析は存在しません。
- 兄弟ワーカーが実行中に H をライブで変異させることは一貫性の問題（実行中のワーカーはどの H_i を参照するか？）を生じさせますが、引用されている節ではこれに対処していません。
重要性
PILOTは、エージェントの自己改善を事後的な学習／メモリ更新から、コントロールプレーンの問題へと再定式化します。すなわち、独立したsupervisorが実行中にアクティブな軌跡と永続的なハーネスの両方を編集します。精度の同時改善を伴いながら42〜47%のトークン削減が実現されていることは、長期タスクにおいてモデルの弱点に見えていたものの多くが、実際にはハーネスの健忘症——同じ発見が毎回の実行で再導出されること——であることを示唆しています。
Source: https://arxiv.org/abs/2608.26530
Zero-WAM: 人間の動画からのIn-Context World-Action Modelingによるオープンエンドタスク汎化
問題設定
ゼロショットのクロスタスクマニピュレーションは、訓練時に登場しなかったタスクをデプロイ時にパラメータ更新なしで実行するようポリシーに求めます。言語指示はマニピュレーションを十分に特定できません：「赤いブロックを棚に置いて」という指示は、把持のアフォーダンス、アプローチ方向、サブゴールの分解について曖昧さを残し、言語条件付きポリシーは訓練分布からタスクから軌跡へのショートカットを記憶しがちです。Zero-WAMは、マニピュレーションの自然なタスク仕様は同じタスクの人間によるビデオデモンストレーションであると提案し、クロスタスク汎化をin-context learning（ICL）問題として定式化します：人間がタスク T を実行するビデオプロンプトが与えられたとき、タスク T に対するロボットの将来のビデオ・アクションチャンクを予測するというものです。
中心的な障壁はデータです。数千のタスクにわたる人間とロボットのペアとなったデモンストレーションは大規模には存在せず、公開ロボットデータに対する素朴な言語条件付き事前学習は少数のタスクに対する繰り返しの遠隔操作をオーバーサンプリングしてしまいます。
手法
HumanGenデータパイプライン。 著者らは5つの公開ロボットデータセット（AgiBot、InternData-A1、Open-X-Embodiment、RoboCOIN、RoboMIND）を（アクション、オブジェクト）ペアによって定義されるタスクへと再分割し、タスクあたりの軌跡数を上限付きにすることで、タスクバランスVA事前学習の1エポックあたり約6,000タスクおよび~400K軌跡を得ます。さらに、タスクサンプリングされたロボット動画からマッチした人間動画を合成し、8.6Kタスクにわたる74.2Kの人間-ロボットICLペアを生成します。これはPre-train ICL（外部/社内）、Simulation ICL、Real-world ICLに分割されます。
因果的ビデオ・アクションモデル。 LingBot-VAに従い、各軌跡はアラインされたビデオとアクションチャンクとともに \tau=\{(\mathbf{x}^i,\mathbf{a}^i)\}_{i=1}^N としてチャンク化されます。ステップ i においてモデルは以下を因数分解します：
p_\theta(\mathbf{x}^{i+1},\mathbf{a}^{i+1}\mid\mathbf{x}^{\le i},\mathbf{a}^{\le i},c) = p_\theta^{\mathrm{vid}}(\mathbf{x}^{i+1}\mid\cdot)\, p_\theta^{\mathrm{act}}(\mathbf{a}^{i+1}\mid\mathbf{x}^{i+1},\cdot),
ここで p_\theta^{\mathrm{act}} は予測された次のビデオチャンクからアクションをデコードするinverse-dynamicsヘッドとして機能します。ビデオ予測にはflow matchingを使用します：クリーンなチャンク \mathbf{x}_0、ノイズ \bm\epsilon、および t\in[0,1] に対して、
\mathbf{x}_t=(1-t)\mathbf{x}_0+t\bm\epsilon,\quad \mathbf{v}_t^\star=\bm\epsilon-\mathbf{x}_0,\quad \mathcal{L}_{\mathrm{fm}}=\mathbb{E}\big[\|\mathbf{v}_\theta(\mathbf{x}_t,t,c)-\mathbf{v}_t^\star\|_2^2\big].
条件はタスク多様VAデータでは c=\ell（言語）、HumanGen ICLデータでは c=\{\mathbf{h},\ell\} であり、ここで \mathbf{h} は人間動画を表します。
アーキテクチャ。 Zero-WAMはWan-2.2-TI2V-5Bから初期化され、隠れ次元 d_v=d_a=3072、30層、RoPEを持つ2ストリームのMixture-of-Transformersへと再構成されています。ICLの人間動画とロボット動画のトークンを分離するために、高さ軸のRoPEオフセット \Delta_H=32 を使用します。動画（人間およびロボット）はWan-2.2 VAEを通過し、言語にはT5を使用します。
In-context Future Prediction（IFP）。 ICLのための重要な学習目標：次のチャンクのみを予測するのではなく、モデルは時間ストライド s=2、重み (w_1,\dots,w_4)=(0.5,0.25,0.15,0.15) で K=4 個の将来のロボットチャンクを予測します。近い将来の予測は最近の軌跡プレフィックスだけで解決できる（既知タスクに対するショートカット）ため、より遠い地平線の予測を強制することにより、モデルは人間動画プロンプトからタスクの進行情報を引き出す必要が生じます。これが事前学習中に学習されるタスクアイデンティティのショートカットを抑制するメカニズムです。
学習スケジュール。 タスク多様VAとHumanGenは1:5で混合されます。言語dropoutはICLサンプルにおいてWan-2.2のデフォルト0.1から0.4に引き上げられ、ICLの人間動画latentは確率0.1でドロップされ、非ICLの言語dropoutは0.1です。事前学習中のチャンクサイズは一様に1〜4であり、推論時のチャンクサイズは2です。学習率 10^{-4}、weight decay 0.01のAdamW、15,360 GPU時間で学習します。Token-packingにより、GPU毎のシーケンスを160Kトークン以内に収めます。
推論。 2つのモード：言語のみ（video CFG=5、人間プロンプトなし）またはICL（人間動画プロンプト、言語無効化、ICL CFG=5、action CFG=1.0）。
結果
RoboTwin 2.0における7つの未見タスク（未見オブジェクト、関節オブジェクト、バイマニュアル、ロングホライズンマニピュレーションを網羅）において、Zero-WAMは平均成功率47.0%を達成し、最強のビデオ・アクションベースラインに対して絶対値で+29.5 ppを上回ります（ベースラインが17.5%であることを示唆）。
実世界評価では、人間動画プロンプトが、訓練時には存在しない複数オブジェクトシーン、ロングホライズンシーケンス、および細粒度の挿入構成への汎化を推進します。
限界と未解決の問題
- 論文の主要な改善は合成人間動画生成器に依存しており、その生成器の忠実度とバイアスがICL品質の上限を決定する可能性が高く、テスト時に「合成人間動画プロンプト」対「実際の人間動画プロンプト」を分離するアブレーションは論文要旨では報告されていません。
- 絶対成功率47.0%は未見タスクで過半数の失敗が残ることを示しており、ロングホライズンおよび細粒度マニピュレーションの失敗モードはここでは分解されていません。
- IFPの重みとストライド（K=4,s=2）は手動調整されています。このスケジュールなしにショートカット抑制の議論が成立するか、あるいはより長い地平線でどのようにスケールするかは未解決です。
- ICLモードで言語を無効化した2モード推論（言語のみ vs. ICL）は、モデルが2つの条件付けチャネルを完全に統合していないことを示唆しており、複合的なプロンプト（言語+ビデオ）はこの抜粋では評価されていません。
- 計算コスト（5Bベースからの15,360 GPU時間）は独立した再現を高コストにし、事前学習データセット外の身体への汎化はここでは未検証です。
なぜ重要なのか
Zero-WAMは、タスクバランスのとれたVA事前学習、自動生成された人間動画プロンプト、およびタスクアイデンティティのショートカットを構造的に罰する将来チャンク予測lossという具体的なレシピによって、マニピュレーションに対するICLを実用化します。未見タスクでの+29.5 ppの差がより厳密なアブレーションのもとで維持されるならば、タスク仕様そのものがボトルネックであってモデルの容量ではないような状況において、ビデオプロンプティングが言語条件付きの汎用ポリシーに代わる実行可能な選択肢となります。
Source: https://arxiv.org/abs/2608.26103
LLMの推論に向けたEvolution Strategiesの理解：GRPOより広い推論カバレッジ
Evolution Strategies（ES）は、LLMの推論における post-training としての、メモリ効率の高いpolicy-gradient手法の代替として再注目されています。ESはsamplerを通じたbackpropを必要とせず、摂動パラメータに対するforward評価のみを用います。本論文は、ESがGRPOと実際に何を異なる最適化しているのか、そしてその定性的な優位性（または欠点）が原理的なものか偶発的なものかを問います。著者らは分析を3つの問いを軸に整理しています：(1) ESはGRPOのentropy collapseを回避しPass@Kを維持できるか？(2) 大きなパラメータのドリフトはcatastrophic forgettingを意味するか？(3) どのhyperparameterと推定量がESをスケーラブルにするか？
Pass@Kのメカニズムとしての集団多様性
中心的な理論的主張は、ESのパラメータノイズが制御された量のpolicy空間の多様性を誘起し、それがより高いPass@Kに転換されるというものです。s_\theta(y\mid x)=\nabla_\theta\log\pi_\theta(y\mid x)とプロンプト条件付きFisher情報量を
\mathcal{I}_x(\theta)=\mathbb{E}_{Y\sim\pi_\theta(\cdot\mid x)}[s_\theta s_\theta^\top]
と定義します。局所的な摂動\delta=\sigma\epsilonはD_{\mathrm{KL}}(\pi_{\theta+\delta}^x\|\pi_\theta^x)=\tfrac{1}{2}\delta^\top\mathcal{I}_x(\theta)\delta+o(\|\delta\|^2)を生じさせます。Lemma 1は、N個のメンバーからなるES集団の集団平均Jensen–Shannonスプレッドを以下のように定量化します：
\mathbb{E}_{\epsilon_{1:N}}[\mathrm{JS}^{\mathrm{pol}}_N(x)] = \frac{\sigma^2}{2}\Big(1-\frac{1}{N}\Big)\operatorname{tr}\mathcal{I}_x(\theta) + O(\sigma^4).
メカニズムは明示的です：摂動スケール\sigmaと集団サイズNが集団全体のJS多様性を制御し、論文は（標準的なサポート・滑らかさ条件のもとで形式化されて）、検証器v(x,y)がこの多様性を正解事象\mathcal{C}(x)に射影するとき、異種の\pi_iをまたいでサンプリングすることで少なくとも1メンバーが正解を出す確率（Pass@Kの量）が高まると論じます。ESの更新における報酬重み付けはさらに、組み合わせたcenterをp_\pi(x)が高いメンバー寄りにバイアスさせるため、多様性の優位性は集約後にも消失せず生き残ることができます。
実験的に（Panel (a)）、GRPOは既知のentropy collapseを示します：Pass@1は改善しますが、大きなKでのPass@Kは低下します。ESはPass@1を改善しつつ、GRPOよりも高いPass@Kを達成します。著者らはさらに、GRPOのPass@1の精鋭化とESのカバレッジ向上を重ねるために、逐次的なGRPO→ESスケジュールを提案します。
大きなドリフト、スパースな機能的更新
RQ2はESに関する標準的な懸念に取り組みます：パラメータの移動がgradient手法に比べて巨大であり、catastrophic forgettingを示唆するというものです。相対的なL_2ドリフトD_{\mathrm{rel}}(\theta,\theta_0)=\|\theta-\theta_0\|_2/\|\theta_0\|_2（Table 4）を測定すると、Full ESはQwen2.5-1.5B/7B、Llama-3.2-3B、DeepSeek-R1-Distill-Qwen-1.5Bにわたって、GRPOより40.7〜44.1倍遠くに移動します（例：Qwen2.5-1.5Bで0.0475\to 1.933、Llama-3.2-3Bで0.0954\to 4.185）。
しかし、更新の大きさの分布は小さな変化に向けて著しく歪んでいます。閾値\tau=2.0\times 10^{-3}において、3つのinstructモデルでは非ゼロ更新の97.57%〜98.11%が(0,\tau]に収まります；DeepSeek-R1-Distill-Qwen-1.5Bのみスパース性が低くなります（87.29%）。これはHoyらによるESの分解、すなわち報酬に整合した進捗とフラットな方向に沿った高次元ランダムウォークへの分解と一致します：ドリフトの大部分は拡散であり、報酬に関連する変化は大きな大きさを持つ更新のスパースなサブセットに集中します。Panel (b)は、大きさによる閾値処理（より大きな更新のみを保持する）がターゲットタスクの性能と、重要なことにheld-outのMaj@32を保持することを示しており、catastrophic forgettingがESの本質的な性質ではなく拡散成分の性質であることを示しています。
推定量とスケーリングのノブ
RQ3は実際に重要な選択肢を特定します。集団内でのZ-score報酬正規化は、訓練全体を通じて正規化なしを上回ります（Panel (c), item (1)）；これは理論的な描像と一致します。ESは摂動方向に対する重みとして報酬を使用するため、正規化されていない報酬はタスクの難易度とともにドリフトするからです。GSM8KにおけるPopulation-sizeのスケーリング（Table 6）は収穫逓減点を示します：Qwen2.5-1.5Bおよび3Bでは、N=32はすべての測定された更新においてN=64の参照と0.01以内に収まります（例：1.5Bの更新300において：0.8449 vs. 0.8438；3B：0.9004 vs. 0.9031）。0.5Bモデルでは、より大きなNが依然として効果的です（更新300においてN=8で0.4421 vs. N=64で0.5287）。これは、正解に到達するために必要な多様性がベースモデルの能力低下とともに増大することを示唆しており、Lemma 1の\operatorname{tr}\mathcal{I}_x(\theta)とNの相互作用と整合しています。
制限と未解決の問い
Pass@Kの分析は局所的（\sigma\to 0）であり、実現された集団を条件とします；報酬重み付けのもとでの集団JS多様性からES更新後のcenterへの転換は条件のもとで特徴付けられていますが、実際の\sigmaとNに対してはタイトに有界ではありません。スパース性の結果は記述的なものです：論文はまだ、報酬に整合した進捗を損なわずに拡散更新を抑制する訓練時の手続きを提示していません（大きさによる閾値処理はpost-hocです）。最後に、GRPO→ESは強みを組み合わせることが示されていますが、GRPOのentropy収縮とESの多様性注入の相互作用は分析されていません。
なぜこれが重要か
下流の検証器やbest-of-Nパイプラインが消費するものがPass@Kカバレッジであるならば、GRPOスタイルのentropy collapseは積極的に有害であり、ESはカバレッジを保持するためのFisher情報制御された原理的な方法を提供します。機能的スパース性の知見はまた、ESの「巨大なパラメータドリフト」を負債から、ほとんどの更新が枝刈り可能であるというシグナルに再解釈し、これはより安価なデプロイメント（sparse delta）や、Pass@1にはGRPOを、推論の幅にはESを使用するhybridパイプラインを指向します。
Source: https://arxiv.org/abs/2608.27351
Hacker News Signals
Terminal-Bench-Science: 科学研究ワークフローにおけるAIエージェントの評価
Terminal-Bench-Scienceは、ターミナル環境内で実行されるエンドツーエンドの科学研究タスクを対象としたAIエージェント評価のためのbenchmarkです。狭義の質問応答や孤立したコード生成をテストする既存のbenchmarkの多くとは異なり、本benchmarkは研究のフルループ――文献検索、データ取得、実験設計、コード実行、結果解釈――を一連の流れとして連鎖させており、すべてがbashアクセス可能な環境でPython、wget、git、標準的な科学ライブラリなどの実際のツールを用いて実施されます。
各タスクはエージェントに与えられる目標仕様（例：「提供されたデータセットを使ってこの論文のFigure 3を再現せよ」）として構成され、検証可能な出力――正確な数値結果、テストスイートの合否、または成果物の存在確認――に基づいてスコアリングされます。本benchmarkが対象とする領域には、バイオインフォマティクス、計算化学、物理シミュレーションが含まれます。タスクは可能な限り自動採点され、部分点を必要とする一部のタスクについては人手によるレビューが行われます。
設計思想として、ターミナルアクセスは実際の科学的作業における最小限のインターフェースであるという考えがあります――エージェントはシェルコマンドを連鎖させ、ファイルシステムの状態を管理し、パッケージをインストールし、ランタイムエラーをデバッグしなければならず、これによりサンドボックス化されたコード実行benchmarkでは見えない失敗モードが明らかになります。リーダーボードの結果は能力の大きなばらつきを示しており、トップクラスのフロンティアモデルがタスクの約30〜40%を完全にこなす一方、小規模なモデルは複数ステップにわたる依存関係チェーンやエラー回復で行き詰まります。
注目すべき設計上の決定の一つは、上流データソースがわずかに不正形であったり依存関係にバージョンの競合が生じたりする「ノイジー環境」タスクの導入であり、ロバスト性と自己デバッグ能力をテストします。これはクリーンな環境のbenchmarkよりも実際の研究ワークフローに近いと言えます。
未解決の主要な問題としては、ドメイン専門家によるレビューなしに科学的正確性を大規模にスコアリングすることがまだ解決されておらず、現在のbenchmarkではほとんどのタスクにおいて科学的妥当性を判断するのではなく数値の完全一致を要求することでこの問題を回避しています。また、カバレッジは計算集約型の科学に偏っており、ウェットラボの計画タスクは含まれていません。
Source: https://www.terminal-bench-science.ai/announcement
Show HN: Claudeの出力を支える語彙（load-bearing vocabulary）
このプロジェクトは、大規模なプロンプトコーパスにわたって活性化パターンと出力分布を調査することで、Claudeの語彙の中でその出力に対して不釣り合いなほど大きな影響力を持つトークンをリバースエンジニアリングするものです。核心的なアイデアは、モデルの挙動を誘導する際にすべてのトークンが等しいわけではないということです。一見構造的に平凡に見えるトークンの中には、存在するかしないかによってモデルの補完分布を劇的に変化させるピボットとして機能するものがあります。
この手法は、特定のトークンをマスクまたは置換した際のKLダイバージェンスや出力エントロピーの変化を計測することで、トークンごとの重要度スコアに類似したものを算出することに関与しているようです。結果として得られる「load-bearing vocabulary」のリストが際立っているのは、明らかに意味的な内容語ではなく、句読点、空白のパターン、XMLライクなデリミタ（Claudeは構造化されたプロンプトで大量に学習されています）、および特定の命令動詞に偏っている点です。
実際的な観点から、これはプロンプトエンジニアリングと敵対的プロンプティング研究に関連します。少数のトークンが出力の誘導を支配しているなら、プロンプト最適化（例：AutoDAN、GCGスタイルの攻撃、あるいは良性のsoft-prompt探索）は語彙全体を均一に探索するのではなく、それらのトークンにバジェットを集中させるべきです。また、Claudeの指示追従動作が特定の語彙的な位置において構造的に脆弱であることも示唆しています。
プロジェクトページの可視化は、語彙ランク全体にわたるトークンの重要度をマッピングしており、重いテール分布を示しています——少数のトークンが不均衡な影響を持っており、これは構造化されたプロンプトテンプレートに対するRLHF fine-tuningから予想されるものと一致しています。重要度スコアのトークン選択がAnthropicの既知の学習プロンプト形式（XMLタグ、<thinking>、Human:、Assistant: デリミタ）と相関しているため、この分析はClaude特有のものです。
限界：手法はやや不透明であり、重要度スコアがlogit attribution、attention weightの集約、あるいは行動的プロービングのいずれから導出されているのかは必ずしも明確ではありません。再現にはモデルの重みではなく大規模なモデル出力へのアクセスが必要であるため、これはブラックボックスのリバースエンジニアリングです。
Source: https://louisabraham.github.io/load-bearing/
Asahi Linux 進捗レポート: Linux 7.2
Asahi Linux プロジェクトは、Apple Silicon（M シリーズ ARM SoC）を対象とした Linux 7.2 にマージされるアップストリーム統合作業について報告しています。主なトピックは、DCP（Display Coprocessor）ドライバの継続的な成熟、PCIe 電源管理の改善、および M3 クラスのハードウェアに影響する NVMe コントローラの修正です。
Apple のファームウェア管理型コプロセッサを通じてディスプレイ出力を処理する DCP ドライバは、HDMI/DisplayPort のホットプラグ処理およびカラー管理の改善を受けました。Apple GPU ドライバ（AGX）は、ダウンストリームの Asahi Mesa フォークとのギャップを埋める OpenGL 適合性修正を含め、アップストリームへの段階的な安定化を継続しています。Rust で書かれた Apple SoC の pinctrl ドライバはさらに洗練されており、これは実際のハードウェアを管理するメインラインカーネルにおけるプロダクション Rust コードの、より具体的な事例の一つです。
PCIe 電源管理は M2/M3 Mac の初期カーネルにおいて重大なリグレッションの原因となっていましたが、7.2 では NVMe のレイテンシスパイクや断続的なコントローラリセットを引き起こしていた ASPM（Active State Power Management）の動作に対処するパッチが含まれています。thunderbolt/USB4 スタックも Apple の実装に固有の修正を受けました。
レポートによると、SMC（System Management Controller）ドライバが新たなセンサーサポートを獲得し、ユーザースペースツールにおける温度およびバッテリーレポートの精度が向上しました。Apple 固有の cpufreq ドライバによる CPU 周波数スケーリングは、効率コアでのエネルギー効率向上のために調整されています。
エンジニアリング観点から最も興味深い進行中の作業は、DCP のリバースエンジニアリングパイプラインです。Apple のディスプレイファームウェアはクローズドソースであるため、ドライバはプロトコルトレースとファームウェアステートマシンに関する推論に基づいて構築されています。このプロジェクトは、他の Apple 周辺機器ドライバも依存する RTKit（Apple の組み込み RTOS）抽象化レイヤーを並行して管理しています。このドライバクラスに対するアップストリームへの受け入れ速度は向上しており、カーネルメンテナがそのアーキテクチャに対して現在は十分な信頼を持っていることを示唆しています。
Source: https://asahilinux.org/2026/08/progress-report-7-2/
Z.aiがOx AlphaをGLMシリーズの新モデルとして確認し、重みの公開を発表
Z.ai（旧Zhipu AI）は、Ox AlphaがGLM-4やChatGLMと同じファミリーであるGLM（General Language Model）アーキテクチャの系譜を引き継ぐモデルであることを正式に確認しました。重みが公開されるという確認こそが実質的なニュースであり、研究者がDeepSeekクラスの性能と競合すると報告されているモデルを検査・fine-tuningできることを意味します。
GLMアーキテクチャは、その事前学習の目的関数において標準的なGPT系transformerとは異なります。純粋な左から右への言語モデリングではなく、自己回帰的な空欄補充（autoregressive blank infilling）を用いており、マスクされたトークンのスパンを生成対象として扱いつつ、それ以外の部分では双方向のコンテキストを条件として使用します。これが元来のGLMの革新でした。その後のGLM-4系モデルは通常のdecoder-onlyアーキテクチャに近づいていますが、事前学習手法の一部は踏襲しています。
Ox Alphaは大規模モデル（正確なパラメータ数は未確認）であり、強化された長コンテキスト能力と改善されたinstruction followingを備えて学習されたと報告されています。Bloombergの記事によれば、中国語およびコードタスクにおいてDeepSeek-V3やGPT-4oクラスのモデルと内部でベンチマーク比較が行われ、競争力のある結果を示したとされています。
重みの公開はいくつかの点で重要な意味を持ちます。GLMシリーズのモデルはこれまで商用利用を認める寛容なライセンスを採用しており、中国のエンタープライズ環境で広く普及してきました。フロンティア水準の能力を持つオープンな重みの公開は、そのパターンを継続するとともに、2025〜2026年前半のオープンモデル議論を席巻したDeepSeekの重み公開に対する具体的な代替選択肢となります。
未解決の問題：正確なアーキテクチャの詳細（MoE対dense、コンテキストウィンドウ、tokenizer の変更など）はまだ公開されていません。DeepSeekとの比較に用いられたベンチマーク手法は未検証です。公開のタイムラインも明示されていません。
Gemini-3.5-Transcribe
Gemini-3.5-Transcribeは、Googleが提供する専用の音声テキスト変換モデルであり、高精度な転写パイプラインにおけるWhisperクラスのモデルの代替として位置づけられています。汎用的なGeminiマルチモーダルモデルとの主な差別化点は、このモデルがオーディオを多数のモダリティの一つとして扱うのではなく、転写のスループットと精度に特化して最適化されている点です。
技術的には、このモデルは長時間オーディオをネイティブに処理します（投稿では、Whisperの30秒ウィンドウイングに起因するチャンク化アーティファクトという既知の問題点を生じさせることなく、数時間にわたる転写が可能であると述べられています）。100以上の言語をサポートし、自動言語検出機能を備えています。話者ダイアライゼーションも、別途後処理ステップを必要とせず、統合された形で提供されています。
アーキテクチャの詳細は公開されていませんが、その説明からは、audio encoderがGeminiの事前学習データから恩恵を受け、decoderが話者メタデータを含む大規模な転写コーパスでfine-tuningされた、encoder-decoder構造が示唆されます。単語および文レベルでのタイムスタンプ生成もサポートされており、これは字幕生成や下流のアライメントタスクにとって重要です。
引用されている精度ベンチマークでは、多言語テストセットにおいてWhisper Large-v3を上回る改善が示されており、特に低リソース言語やアクセントのある発話において優れた性能を発揮します。また、固有表現が多いドメイン（医療、法律）においては、Word Error Rate (WER)が相対的に15〜25%低減されています。ストリーミングユースケースに対するレイテンシは競争力があるとされていますが、リアルタイムファクターに関する具体的な情報は乏しい状況です。
APIの料金体系はオーディオの分数単位の課金であり、オフライン処理向けのバッチモードも提供されています。主な実用上の制限は、これがクローズドAPIである点です。モデルの重みは公開されていないため、ユーザーはセルフホスト、プライベートデータでのfine-tuning、または機密性の高い転写ドメインにおける動作の監査を行うことができません。データレジデンシー要件を持つエンタープライズユースケースにとっては、これは解決困難な障壁となります。
Source: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe/
Gemini Omni 1.1 Flash
Gemini Omni 1.1 Flash は、テキスト・画像・音声・動画の入出力を単一の統合アーキテクチャで処理するマルチモーダルモデルであり、レイテンシを重視した本番環境へのデプロイを主な対象としています。「Flash」という名称は、最大性能よりも高スループットな推論サービングを目的とした蒸留・最適化バリアントに対するGoogleの命名規則を踏襲しています。
オリジナルのGemini Omni Flashからの1.1アップデートは、3つの領域に焦点を当てています。すなわち、マルチモーダルコンテキストが交互に出現する場面での instruction following の改善、音声出力品質の向上（モデルは別個のTTSシステムを経由せず直接音声を生成できます）、そして動画フレームにわたるより長い有効コンテキストによる動画理解の拡充です。ネイティブ音声出力はアーキテクチャ上興味深い点であり、トークンの語彙または出力ヘッドにテキストに加えて音声トークンが含まれることを示唆しており、GPT-4oの報告されているアーキテクチャで採用されているアプローチと類似しています。
開発者にとっての主要な機能は、リアルタイム音声会話（モデルがターンテイキングと割り込みを処理します）、画像を条件とした対話、そして動画の要約です。公表されているレイテンシの数値によると、最初の音声トークンが生成されるまでの時間は数百ミリ秒の低い領域にあり、自然な音声インタラクションに必要な範囲内に収まっています。
HNのディスカッションでは、前バージョンとのAPI挙動の違いに焦点が当てられており、特定の構造化出力タスクにおけるリグレッションや、拒否応答の挙動の変化を指摘するコメントが複数見られます。これらは本番パイプラインにおけるモデルアップデートで生じがちな摩擦点であり、1.1の fine-tuning が instruction following の分布を必ずしも純粋な加算的な形ではない方法で変化させたことを示唆しています。
コンテキストウィンドウは100万トークンであり、Gemini 1.5/2.0系と一致しています。価格はモダリティによって入出力トークンのコストが差別化された階層構造に従います。このモデルはオープンウェイトではなく、アーキテクチャはGoogleの公開技術レポートを超えて開示されていません。
Source: https://blog.google/innovation-and-ai/technology/developers-tools/build-with-gemini-omni-1-1-flash/
Show HN: LatticeDB – SQLiteのようなグラフデータベース
LatticeDBはGoで書かれた組み込み型グラフデータベースで、SQLiteと同じデプロイメントニッチ——単一ファイル、ゼロコンフィギュレーション、サーバープロセス不要——を標的としていますが、リレーショナルSQLの代わりにプロパティグラフデータモデルとグラフクエリインターフェースを採用しています。
ストレージ層はメモリマップドファイルをバックエンドとするカスタムB-tree実装を使用しています。頂点（Vertex）と辺（Edge）は任意のキー・バリュープロパティを持つ型付きエンティティとして格納されます。クエリインターフェースは、完全なCypherやGremlinの実装ではなく、パス表現言語のように見受けられ、プロパティに対する述語フィルターを伴う隣接構造上のパターンマッチングをサポートしています。
組み込み方式を採用するアーキテクチャ上の判断は、SQLiteと同じトレードオフによって動機付けられています。すなわち、シリアライゼーションのオーバーヘッドの排除、CLIツールやモバイルアプリへのデプロイの簡略化、そしてネットワークレイテンシなしでトランザクションアクセスを可能にすることです。現在の実装ではクラッシュ安全性のためにWAL（Write-Ahead Log）を使用しており、単一ライター・複数リーダーレベルでのACIDトランザクションをサポートしています。
このスケールのグラフデータベースは、リレーショナル組み込みストアが直面しないある構造的な課題に直面しています。グラフトラバーサルのアクセスパターンは非常に不規則でポインタチェイニングが多く、B-treeの局所性に対して不利に働くという問題です。LatticeDBはこの問題に対して、各頂点の隣接リストを頂点レコード内にソート済み配列として格納することで対処しています。これにより次数1の近傍探索は単一ページ読み取りで済みますが、密なトラバーサルは専用の隣接リスト形式（例：CSR）よりもコストが高くなります。
READMEに記載されている現在の制限事項：全文インデックスなし、分散モードなし（設計上の判断）、クエリプランナーは初歩的（コストベースの最適化なし）、そしてクエリ言語はいかなる標準（Cypher、GQL）とも互換性がありません。最後の点は採用における重大な障壁であり、Neo4jや類似製品からの移行パスが存在しません。このプロジェクトは初期段階にあり、HNのコメントにはCypher互換性やPythonバインディングに関するいくつかの機能要望が寄せられています。
Source: https://github.com/jeffhajewski/latticedb
Value Classesにはまだコンパイラの協調が必要
この記事では、システム言語におけるvalue type（ヒープ間接参照なしにスタックに割り当てられるstruct）の根強いパフォーマンス問題を検討しています。具体的には、コンパイラが関数呼び出し境界をまたぐ際や非自明な制御フローを通じてvalue classインスタンスをレジスタに保持できず、意図したパフォーマンス上の利点を損なう余分なスタックspillを強制してしまう問題です。
著者はC++と明示的なvalue classセマンティクスを持つ言語で具体的なベンチマークを示しながらこの問題を実証しています。核心的な問題は、struct引数の受け渡しに関するABIがアーキテクチャ固有であり、しばしば悲観的であることにあります。System V AMD64 ABIは16バイトまでのstructを2つの整数レジスタで渡しますが、しきい値をわずかに超えるstructはポインタ渡しとなり、この呼び出し規約がインライン化の判断と悪い形で干渉します。コンパイラがvalue class引数を含む関数をインライン化しないと判断した場合、スタック上にその値を実体化してポインタを渡すため、value semanticsによる利点が消えてしまいます。
記事にはアセンブリの詳細な確認が含まれており、2フィールドのstruct（16バイト）がレジスタ割り当てに成功する一方で、3フィールドのバリアント（24バイト）がスタックspillパスを引き起こす具体的なケースを示しています。また、LLVMのbyvalとinreg属性の相互作用、およびstruct受け渡し規約の誤ったアノテーションがパフォーマンス問題とは別に正確性の問題を引き起こす方法についても解説しています。
提案されている対策は以下の通りです：(1) ABIが許可する場合に明示的な[[gnu::regparm]]または同等のアノテーションを使用する、(2) ABIの制約を回避するクロス翻訳単位インライン化を可能にするwhole-program optimization / LTOに依存する、(3) structがレジスタのしきい値を超える場合にstd::spanや薄いポインタラッパーを使用する、(4) value semanticsが理論上の利点をもたらすと仮定する前に呼び出しサイトのアセンブリをプロファイリングする。
より広い視点での要点は、ゼロコストなvalue semanticsに対する言語レベルの抽象化が、保証されておらず暗黙のうちに劣化する特定のコンパイラ動作に依存しているということです。これは、たまたまインライン化されるベンチマークのマイクロテストから直感を得ているシステムプログラマにとって重要な指摘です。
Source: https://johan-sjolen.github.io/post/compiler-sympathy/compiler-sympathy/
注目の新しいリポジトリ
deeplethe/utopia
自らをオープンソースの「エンタープライズ向けワールドモデル」と称するUtopiaは、狭義のタスク特化型モデルと汎用的なビジネス環境シミュレーションとの間のギャップを埋めることを目指しています。中心となるアイデアは、エンティティ・関係・時間的ダイナミクスをエンコードした、構造化されかつ更新可能なワールドステートを維持し、LLMバックボーンが純粋なインコンテキスト表現に頼るのではなく、そのステートに対してクエリと更新を行えるようにするというものです。このアーキテクチャはステート管理と推論を分離しており、ニューロシンボリックやmodel-based RLの設計に構造的に類似していますが、エンタープライズ知識グラフへの適用を想定している点が異なります。マルチステップ計画、組織データに対するカusal reasoning、およびエージェントセッションをまたいだ永続的なメモリのサポートを意図しています。サプライチェーン計画・CRMワークフロー・財務予測など、長期的に一貫した挙動が求められるエンタープライズエージェントを構築する実務家にとって、ワールドモデル基盤は生のretrieval手法よりも扱いやすいアプローチです。リポジトリはまだ初期段階であり、「エンタープライズ」という表現は将来的な展望を示すものですが、ワールドステートとLLMを構造的に分離するという設計判断は技術的に注目すべき点です。複数のエージェントが共有ワールドステートに同時に書き込む際のステート一貫性と競合解決をどのように扱うか、今後の動向を注視する価値があります。
Source: https://github.com/deeplethe/utopia
Spielewoy/autoprompt-skill
Autopromptは、コーディングエージェント向けのdrop-inスキルとして設計されたprompt engineeringレイヤーであり、エージェント型コーディングベンチマークにおけるタスク失敗率を45%削減すると主張しています。そのメカニズムは動的なprompt構築です。静的なシステムプロンプトではなく、このスキルは現在のタスクコンテキスト（ファイルの種類、エラートレース、直前のツール呼び出しの出力など）を検査し、構造化されたライブラリからpromptフラグメントを選択・組み立てます。これは学習済みのsoft promptよりも、retrieval-augmented promptingに近いアプローチです。45%の失敗率削減という数値は、エージェント型コーディングタスクに対して内部的にベンチマークされたものであり（正確なeval harnessの詳細は重要であり、精査が必要です）、コーディングエージェントの失敗の多くがコンテキストの不十分な指定に起因していることを踏まえれば、この方向性の結果は妥当と言えます。スキルインターフェースは既存のエージェントフレームワークと組み合わせられるよう設計されており、リポジトリにはスキルがprompt組み立て段階に介入するtool-callingループ向けの統合パターンが示されています。実用的な価値として、promptのロジックをエージェントコードから外部化することで、テストやバージョン管理が可能になります。制限事項として、有効性はフラグメントライブラリの品質に大きく依存しており、ドメイン固有のキュレーションが必要です。
Source: https://github.com/Spielewoy/autoprompt-skill
Kylin010/tcpfit
tcpfitは、固定されたテキストブックの値を適用するのではなく、マシンごとのパラメータを実測によって導出するTCPチューニングツールです。TCPチューニングの標準的なアプローチ――rmem/wmem、tcp_congestion_control、バッファサイズを汎用的なガイドラインから設定すること――は、実際のネットワーク状態を無視しています。tcpfitは対象インターフェース上の帯域幅遅延積（BDP）を計測し、レートリミッターの変曲点（スループット対バッファサイズ曲線における「膝」の部分）を探索することで、マシン固有のソケットバッファの推奨値を導出します。BDPの計測は単純で、\text{BDP} = \text{bandwidth} \times \text{RTT}ですが、変曲点の検出には負荷をかけた状態でsendバッファサイズを反復的に変化させる必要があり、本ツールはその作業を自動化します。出力は、経験則ではなく実際の計測値から導出されたsysctlの推奨設定セットです。これは、異種混在環境――クラウドVM、1G/10G/100G混在ホスト、トラフィックシェーパー配下のホスト――において特に価値があります。そのような環境では、単一のチューニングテンプレートは性能が低下しがちです。本ツールはシステムスクリプティングスタイルで書かれており、sysctlの書き込みにはroot権限が必要です。制限事項：プロービング自体が無視できないトラフィックを生成するため、負荷のかかったプロダクション環境のインターフェース上では実行しないでください。
Source: https://github.com/Kylin010/tcpfit
calmrocks/ai-engineer-notebooks
実用的なAIエンジニアリングスタックを網羅した、体系的なカリキュラム構成のColabノートブック集です。フレームワーク非依存で、無料のGroq APIティアで実行可能です。技術的な範囲は広いながらも一貫性があり、モデルAPIの統合、構造化出力（JSONスキーマの強制、関数シグネチャ）、tool calling、retrieval-augmented generation（チャンキング、embedding、reranking）、そして後付けではなく第一級の関心事としての評価（evaluation）をカバーしています。エージェントのセクションでは、tool-callingループをゼロから構築する手順を扱っており、フレームワークの魔法を避けているからこそ有益です。また、ガードレール、プロンプトインジェクション、MCP（model context protocol）の統合についても取り上げています。fine-tuningの解説では、フルfine-tuningとLoRAを区別しており、これは教育的観点から正しい分離です。「evaluationを軸とする」という設計思想がこのカリキュラム最大の強みです。評価インフラが早い段階で導入され、最後に付け足されるのではなく全体を通して活用されています。フレームワーク非依存という制約により、上位レベルのライブラリが抽象化している内容を明示的に理解することが求められます。ライブラリAPIを呼ぶだけでなく、スタック全体について論理的に考える必要がある、応用AI職へ転向するエンジニアに適しています。Groqへの依存により、実験コストをゼロに抑えられます。
Source: https://github.com/calmrocks/ai-engineer-notebooks
genspark-ai/genoffice
GenOfficeは、AIエージェントを内蔵したクロスプラットフォーム（macOS、Windows、Linux）のオープンソースオフィススイートであり、.docx、.xlsx、.pptx、PDF、Markdownの各フォーマットを対象としています。LibreOfficeやOnlyOfficeとの技術的な差別化ポイントは、AI機能がアドオンプラグインではなく編集モデルのファーストクラスとして組み込まれている点にあります。エージェント層は単にテキストを追記するだけでなく、ドキュメント構造（テーブル、チャート、スライドレイアウト）を解釈・変更することができます。このスイートはOpen XMLフォーマットをネイティブに解析・出力しており、互換性の観点から適切な選択です。AIの統合アーキテクチャは、「このテーブルを棒グラフに変換して」「このセクションを要約して」といった命令に従うために、ドキュメントのコンテキストをLLMへルーティングする仕組みになっており、エージェントは生テキストを操作するのではなく、ドキュメントオブジェクトモデルへの構造的なアクセス権を持っています。リリース直後に3,800以上のスターを獲得していることから、プロプライエタリなAI強化オフィスツールに対するオープンな代替手段への需要は明らかです。未解決の主要課題としては、オフライン・ローカルモデルのサポート、複雑な.xlsxの数式処理の精度、そしてエージェントがドキュメント全体のセマンティクスへの書き戻しアクセスを持つのか、それともテキスト領域のみに限られるのかという点が挙げられます。
Source: https://github.com/genspark-ai/genoffice
ShawnPana/phone-harness
phone-harnessは、AndroidおよびiOSデバイス向けのエージェント制御ハーネスを提供し、スマートフォンのUIをLLMベースのエージェント向けのaction/observation spaceとして公開します。このアーキテクチャは、ADB（Android Debug Bridge）とiOS instrumentsをラップし、スクリーンショットのキャプチャ、タッチ/スワイプアクションの実行、およびUIヒエラルキーの抽出（アクセシビリティツリー経由）を提供します。エージェントはピクセル空間のobservationまたは構造化されたXMLアクセシビリティダンプを受け取り、タップ座標、スワイプベクトル、テキスト入力などのアクションを出力し、ハーネスがそれをデバイスコマンドに変換します。これはGUIエージェントの標準的なアプローチ（AppAgentやMobileAgentに類似）ですが、phone-harnessはモノリシックなパイプラインではなく、組み合わせ可能なスキル/ツールとして設計されており、既存のエージェントフレームワークへの統合が容易です。2,000件以上のスター数は、エージェント機能としてのスマートフォン自動化への真摯な関心を反映しています。実用的なユースケースとしては、モバイルテストの自動化、個人的な自動化タスク、およびGUIエージェントの研究が挙げられます。制限事項としては、座標空間のアクションはデバイスの解像度によって動作が不安定になること、アクセシビリティツリーの品質はアプリによって異なること、iOSでは開発者モードを有効にしたMacへの接続が必要なためデプロイ可能性が制限されることが挙げられます。
Source: https://github.com/ShawnPana/phone-harness
cristicretu/diri
diriは、並列コーディングエージェントのためのネイティブmacOSオーケストレーターです。複数のLLMコーディングエージェント（Claude Code、OpenAI Codex、Cursor、Gemini）を同一コードベース上で同時に実行すると、ファイルの変更が競合するという具体的な問題を解決します。解決策はgit worktreesです。各エージェントセッションは同一リポジトリからブランチされた独立したworktree上で動作するため、干渉を防ぐことができます。diriはworktreeのライフサイクル——作成、エージェントの割り当て、監視、マージ——をネイティブmacOS UIを通じて管理します。また、リモートホストへのディスパッチもサポートしており、エージェントを別のマシン上で実行しながら、diriが統合されたコントロールプレーンを提供できます。技術的な価値はオーケストレーション層にあります。具体的には、特定エージェントへのタスクルーティング、セッション状態のトラッキング、そして並列エージェントブランチ間の競合を表面化するマージ・差分ワークフローです。コーディングエージェントがシングルセッションのツールからマルチエージェントの並列処理へと移行する中で、これはまだ十分に探求されていない運用上の問題です。ネイティブmacOSアプリ（Swift/SwiftUIと推定）として構築されているため、ポータビリティは制限されますが、OSとの緊密な統合が実現されています。リモートホストのサポートは、クラウドGPUインスタンスや高性能ワークステーション上でエージェントを実行しながら、ラップトップをコントロールサーフェスとして使用する開発者を想定した設計であることを示唆しています。
Source: https://github.com/cristicretu/diri
tt-a1i/simplify-codebase
simplify-codebaseは、コードベースにおける偶発的な複雑性——デッドコード、冗長な抽象化、意図的な設計を経ずに積み重なった過度に複雑な間接参照——に対処するツールです。そのアプローチは挙動等価性検証であり、提案された単純化が観測可能な挙動を変化させないことを証明してから適用を試みます。技術的な核心は、静的解析による候補の特定（到達不能なコードパス、未使用のパラメータ、インライン化可能な一度しか呼ばれない関数）と、削除の安全性を検証するための軽量形式検証またはテストスイートカバレッジチェックとの組み合わせにあります。これはコンパイラのデッドコード除去に隣接しますが、より高い意味的レベルで動作し、バイトコードだけでなく設計レベルの複雑性を対象とします。「証明」という表現は最も強力かつ最も議論を呼ぶ主張です。任意のコードに対する完全な挙動等価性の証明は決定不能であるため、実装は必然的に有界検証（テストカバレッジ、有界深さのシンボリック実行、またはプロパティベースのチェック）に依存しています。実際的な価値は本物であり——コードベースはチームが手動でリファクタリングするよりも速く複雑性を蓄積します——しかし、安全性が重要なリファクタリングに依存する前に、実装において「証明」が実際に何を意味するかをユーザーが確認することを推奨します。