デイリーAIダイジェスト — 2026-06-24

公開

2026年6月24日

English · 日本語

arXiv ハイライト

NatureBench: コーディングエージェントはNature系論文の公開SOTAに匹敵できるか？

問題設定

既存のエージェントベンチマークは、既知の結果の再現（PaperBench、CORE-Bench、ReplicationBench）か、Kaggleから取り出したMLエンジニアリング問題の最適化（MLE-bench）のいずれかを評価するものです。しかし、実際の科学論文のSOTAに達するような手法をコーディングエージェントが発明できるかを検証する設定は存在しませんでした。NatureBenchは、査読済みのNature系論文から抽出した90タスクを用い、情報ファイアウォールによってソース手法を隠した状態で公開SOTAアンカーに対してスコアリングすることで、このギャップを埋めます。動機となる問いは明確です。Nature論文のデータとタスクの概要のみを与えられた場合、フロンティアのコーディングエージェントは著者が報告した結果に独立して到達できるのでしょうか？

NatureBenchの概要：6つのタスクドメインとSurpass-SOTAリーダーボード

手法：NatureGymパイプラインとベンチマーク構築

各タスクはタプル T=(A,D,M,S,B)（アルゴリズム A、データセット D、メトリック M、SOTAスコア S、オプショナルのベースライン B）として表現され、3段階のレビューゲート方式で順次整備されます。

  1. 論文フィルタリング：ジャーナルレベルの選定では、(i) 数値的なSOTA主張を伴う具体的なアルゴリズム上の貢献、(ii) 公開されて取得可能なデータ、(iii) scientific-MLのスコープを要件とします。
  2. データセット取得と検証：分割を再導出し、論文報告のメトリックに対してホールドアウトテストセットを検証します。
  3. タスクパッケージ構築：タスク概要、学習データ、隠されたテストセット、自動評価器を含むコンテナ化された環境を構築します。

NatureGymパイプライン：3段階のレビューゲートとソース手法を除外する情報ファイアウォール

設計上の重要な選択は情報ファイアウォールです。エージェントはタスク概要とデータセットを受け取りますが、論文の手法節は受け取りません。したがって成功には、想起や再現ではなく手法の発見が必要となります。各段階ではLLMエージェントがverify–repairループと共に動作し、人間が重大な修正を確認します。

ベンチマークは、多様なモダリティとMLタスクファミリーにわたる6つの科学ドメインをカバーしており（図3参照）、公開リーダーボードの背後にはメンテナー側の再現プロトコルが存在します。

NatureBenchの6つの科学ドメイン、モダリティ、貢献タイプにわたるカバレッジ

スコアリング

性能はエージェントスコアと論文のアンカー S との間のSOTA相対ギャップ g で測定され、Surpass-SOTAは g > 0.1（エージェントがホールドアウトテストセットにおいて公開値を有意に上回ること）として定義されます。元の手法の漏洩を防ぐためにWeb検索は無効化されています。

評価

10種類のフロンティア構成がテストされました。Claude Codeによる7モデル（Opus 4.6/4.7、Kimi K2.6、MiniMax-M2.7、DeepSeek-V4-Pro、GLM-5.1、Qwen 3.7 Max）、Codex CLIによるGPT-5.4/5.5、Gemini CLIによるGemini 3.5 Flashです。各エージェントは90タスクすべてに独立して動作し、900件のログ付き実行結果が得られました。

主な結果

  • 最強の構成でも、g > 0.1 基準のもとでSOTAを上回るのは17.8%のタスクのみです。
  • 900件の実行全体を集計すると、Match-SOTAレートは32.2%です（Surpass-SOTAより緩い基準）。
  • エージェントの手法がソース論文と同じ広いファミリーに属する実行ではSOTAを37.7%のケースでマッチし、ファミリーが異なる場合は29.6%でした。適切な手法タイプを選ぶことには測定可能ながら控えめな利点があります。
  • 手法ファミリーの分布は大きく乖離しています。論文側の手法は構造化表現、統計的モデリング、事前学習/転移に集中している一方、エージェント側の手法は教師あり予測モデリング（実行の41.4%）に収束します。エージェントは科学的タスクを体系的に汎用的な教師ありパイプラインに変換します。
  • 失敗分析によると、SOTAを下回る実行や無効な実行の主な原因は、タスクの誤解ではなく誤った手法選択と不十分な計算予算です。エージェントは概要を正しく読めていますが、慣れ親しんだレシピにデフォルトし、十分に学習しません。

著者らはこれを方法論的変換のレジームとして解釈しています。科学的タスクがきれいな教師あり再定式化を許容する場合にエージェントは成功し、ソース論文の貢献が帰納バイアス、物理情報構造、生成モデリング、またはエージェントが考慮しないドメイン固有表現にある場合は失敗します。6つのドメインは10エージェント全体にわたって一貫した難易度勾配を形成しており、このギャップがエージェント固有のものではなく構造的なものであることを示唆しています。

制限と未解決の問題

  • Web検索ファイアウォールは公平性のために必要ですが、非現実的です。実際の科学者は先行研究を読みます。制御された検索を導入したバージョンでは、「手法の発明」と「手法の検索と適応」を分離できるでしょう。
  • SOTAアンカーは単一論文からの単一の数値であり、Nature系の結果の中には最適値に近いものや非公開データの変種に依存するものがあり、改善余地が制限されることがあります。
  • 「手法ファミリー」の帰属はポストホックに注釈付けされており粗いものです。誤ったファミリーが選ばれた理由（プロンプトのフレーミング？学習データの事前分布？計算ヒューリスティクス？）のより細粒度な功績帰属は未解決のままです。
  • 計算予算は失敗モードとして特定されていますが、制御されていません。エージェントに論文レベルの学習予算が与えられた場合、82.2%の非surpassレートがどの程度縮小するかは不明です。
  • ベンチマークは6ドメインにわたる90タスクをカバーしていますが、例えば理論重視の物理学や湿式実験と連携した生物学のカバレッジは依然として薄いです。

重要性

NatureBenchは、「科学のためのエージェント」という問いを手法を隠した状態で公開SOTAに到達できるかという形式に再フレーミングし、現在のフロンティアにおける答えは17.8%です。主な失敗モード、すなわち異質な科学的問題を教師あり予測に収束させること、は具体的かつ実行可能な診断であり、より大規模な汎用エージェントではなく、手法選択の事前分布、より深い実行予算、および構造化された科学的ツール利用の方向性を示しています。

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

DiffusionBench: Diffusion Transformerの総合的評価について

問題設定

Diffusion transformerの研究は、クラス条件付きImageNet-256をFIDで評価するという単一文化に収束しています。暗黙の前提として、そこでの改善が実際に研究者が関心を持つテキストから画像への生成（T2I）などの領域にも転移するとみなされてきました。著者らはこの前提を実証的に問い直します。核心的な主張は、T2I評価に対するコスト上の反論はもはや成立せず、実際に両タスクで評価すると、ImageNetにおける手法のランキングとT2Iベンチマークにおけるランキングとの間に本質的に正の相関が存在しないというものです。三つのT2Iメトリクスにわたるピアソン相関は-0.377から-0.580の範囲に収まります。

これが成立するとすれば、FIDを数十分の一ポイント改善してきた最近の多くの研究は、せいぜい情報量がなく、最悪の場合は目標タスクと逆相関するプロキシを最適化していることになります。

NanoGenフレームワーク

NanoGenは本ベンチマークを実現可能にする仕組みであり、ImageNetとT2Iをデータローダーとconditioning moduleの二箇所の変更だけで扱える単一のDiTコードベースです。それ以外のすべて（backbone、optimizer、EMA、loss、schedule）は共有されます。

backboneはRAEに従ってencoderとワイド・シャローdecoder に分割したDecoupled DiT（DDT）です。encoderはノイズ付きlatentとconditioning tokenを受け取り、意味表現hを出力します。decoderはhを用いてAdaLNをmodulate（encoderではAdaLNを除去）し、diffusionのターゲットを予測します。すべてのconditioningはin-contextで行われ、timestepとクラス/テキストのtokenがvisual tokenの先頭に追加されるため、タスクの切り替えはconditioning tokenの差し替えに帰着します。

  • ImageNet: 4つのtimestep + 8つのclass token
  • T2I: 4つのtimestep + 256つのtext token（凍結済みtext encoderより）

学習にはAdamWを使用し、\beta_1{=}0.9、\beta_2{=}0.95、2{\times}10^{-4}までの線形warmupの後2{\times}10^{-5}まで減衰、gradient clip 1.0、EMA decay 0.9995です。Timestepはlogitノーマル分布\mathcal{N}(0,1)からサンプリングし、SD3/RAEスタイルの次元依存シフトを適用します。

t_m = \frac{\alpha t_n}{1 + (\alpha-1)t_n}.

NanoGenはRAE（tokenizerとして使用する凍結vision encoder）、VAE latent、ピクセル空間DiT（JiT、PixNerd、PixelGen）、REG、およびMeanFlowをサポートします。現在のフレームワークは21個の学習済みlatent diffusionモデルに加え、ピクセル空間および少ステップのvariantをカバーしています。

重要な点として、この設定ではT2Iの学習コストはImageNetと比べて高くありません。Figure 2は32台のH200による100Kステップの実壁時計時間を示しており、latent空間の手法は二つのタスク間でコストが密集しており、コストの外れ値はT2Iそのものではなくピクセル空間の手法です。

25のDiT手法にわたるImageNetとT2I設定の学習時間比較

ベンチマーク結果

Table 2は80エポック、$615Mパラメータ、CFGを[0.0, 0.9]$で各手法ごとに最適選択した場合のImageNet-256の結果を報告しています。具体的な数値をいくつか挙げます。

  • RAE encoderの中では、DINOv3-BがFID 1.74（IS 244.2）、SpatialPE-LがFID 1.86（IS 247.1）、SigLIP2-BはFID 2.61と明らかに劣ります。
  • VAEの中では、FLUX.2-VAEがFID 1.37（IS 272.7）で最良であり、FLUX.2-VAE + REGは1.44（IS 294.1）です。SD-VAE-EMAは2.43、FLUX.1-VAEは3.55、Qwen-Image-VAEは3.01です。
  • End-to-end REPA-E variantは分散を圧縮します：E2E-SD3.5-VAE 1.62、E2E-VA-VAE 1.65、E2E-Qwen-Image-VAE 1.55。
  • ピクセル空間の手法は一様に劣ります：JiT 4.08、PixNerd 4.17、PixelGen 3.97。
  • MeanFlow NFE=1はFID 6.60、NFE=2は5.40です。

Tableでは5つのbackbone（Inception、ConvNeXt、DINOv2、MAE、SigLIP）に対するFDrとMINDも報告されており、「FID」が単一の量でないことがすでに示されています。例えば、DINOv2-BはInception-FID 1.22ですがDINOv2-FID 3.26であり、SD-VAE-EMAはその逆のパターン（1.38 vs 7.71）を示します。手法のランキングは、どのencoderで評価するかに依存します。

非相関の結果

これらと同じ手法をT2I学習後にGenEval、DPG-Bench、GenAIBenchで評価したとき、核心的な知見が明らかになります。Figure 1はRAEおよびVAEの手法にわたって、ImageNet FIDと各T2Iメトリクスをプロットしています。

RAEおよびVAE手法にわたるImageNet FIDとT2Iメトリクス（GenEval、DPG-Bench、GenAIBench）のピアソン相関

ピアソン相関は[-0.580, -0.377]の範囲に収まります。T2Iメトリクスは高い方が良く、FIDは低い方が良いため、正の転移があれば負の相関が得られるはずですが、その大きさは控えめであり、スライスによって符号が一定でないため、著者らは「強い相関はない」というより慎重な主張をしています。具体的には、ImageNetで最良のVAE（FLUX.2-VAE）がGenEvalでも最良というわけではなく、ImageNetでは平凡に見えるtokenizerのいくつかがプロンプト忠実度のメトリクスで大幅に順位を上げます。

100K〜200Kステップ（batch 1024）後の256×256でのT2I定性サンプルはFigure 3に示されており、Table 3で報告された定量的な順序と一致しています。

NanoGen latent空間手法による256×256でのテキストから画像への定性サンプル

制限と未解決の問い

本研究は256×256、$$615Mパラメータ、80〜200Kステップの学習スパンで行われています。T2Iを損なういくつかのtokenizerの病理（例：テキストのレンダリング品質の低さ、弱い構成的構造）がモデル容量と相互作用する可能性があるため、スケールアップするとImageNet–T2Iの相関が強まる可能性は排除できません。T2Iメトリクス自体（GenEval、DPG、GenAIBench）も不完全であり、部分的に冗長です。また、CFGはImageNetで手法ごとに調整されており、たまたまその領域でCFGフレンドリーな手法を有利にする可能性があります。同じCFGスイープがT2Iに対して同等に公平かどうかは不明です。さらに著者らは、どの手法レベルの特性がT2I品質を予測するかの特定には至っておらず、負の結果の方が正の結果よりも明確です。

重要性

ImageNet FIDがT2Iの挙動とせいぜい弱い相関しか持たず、場合によっては逆相関しているとすれば、ImageNetのみでベンチマークされてきた最近のほとんどのDiT手法（tokenizer、アーキテクチャ、regularizer）は、デプロイメントタスクを追跡しないプロキシの上に立っていることになります。NanoGenの貢献は代替手法を十分安価にすることでT2I評価を省略する言い訳をなくした点にあり、DiffusionBenchの21モデルにわたるスイープは、単一ベンチマークの均衡から脱却する必要性を示すこれまでで最も強力な実証的根拠です。

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

Qwen-AgentWorld: 汎用エージェントのための言語ワールドモデル

問題設定

ワールドモデル p(s_{t+1}\mid s_{\le t}, a_{\le t}) は、履歴と行動が与えられたときに環境のダイナミクスを予測します。LLMベースのエージェントにとって、「環境」はシェル、ブラウザ、MCPツール呼び出し、Android UI、コード実行といった異種インターフェースにまたがるため、使い物になる言語ワールドモデル（LWM）はこれらすべてにわたる観測をシミュレートし、それに対して訓練されたポリシーが実システムへ転移できるだけの十分な忠実度を持たなければなりません。既存のシミュレータはドメイン固有であるか、あるいは忠実度が低いかのどちらかです。Qwen-AgentWorldは、7つのドメイン（MCP、Search、Terminal、SWE、Android、Web、OS）をカバーする単一の自己回帰型LWMを目指しており、汎用チャットモデルの副タスクとしてではなく、環境モデリングを主目的として明示的に訓練されます。

Qwen-AgentWorldの統合LWMとしての概要および2つのデプロイモード。

手法

2つのMoEチェックポイントが公開されています：35B-A3Bと397B-A17Bです（アクティブパラメータの命名規則はQwen MoEの慣例に従います）。いずれも「CPT injects, SFT activates, RL sharpens」というスローガンのもとでエンドツーエンドに訓練されます。

3段階の訓練パイプライン。

ステージ1 — CPT。 非思考型の環境軌跡と、拡充された「専門コーパス」（manページ、APIドキュメント、シェルのセマンティクス）を用いた継続事前訓練。軌跡は(i)専用インフラ——コンテナ化されたサンドボックス、MCPサーバー、永続シェルセッション、GUIの状態がアクセシビリティツリーとビュー階層としてシリアライズされたAndroid/ブラウザ/デスクトップVM——、(ii)マルチエージェントのノイズ除去/セグメント化/アライメント/スコアリングパイプラインでフィルタリングされた公開トレース（ターミナル記録、ツール呼び出しログ、リポジトリ実行トレース）、(iii)環境軌跡形式に再フォーマットされた社内SFT軌跡から収集されます。総計：10M件以上の軌跡。CPT、SFT、RLのプールは厳密に分離されています。

ステージ2 — SFT。 次状態予測を明示的なchain-of-thoughtパターンとして活性化します：o_{t+1}を出力する前に、モデルは行動が状態に与える影響を推論する思考トレースを生成します。Table 2によれば、SFTプールは7ドメインにわたる7,094件の軌跡を持ち（Webが最多、次いでTerminal、Android）、RLプールの軌跡の平均長さは13.4ターンにわたる19,443トークンと——これらは真に長いコンテキストの訓練サンプルです（Terminalは平均34,125トークン、MCPは62,702トークン）。

ステージ3 — RL。 ルールベースのチェック（形式適合性、決定論的フィールドの完全一致）とAgentWorldBenchが使用する5つの次元に沿ってスコアリングするルーブリックベースのLLM判定を組み合わせたハイブリッド報酬によるオンポリシーRL。RLはデータのアーティファクトを増幅するため、このステージにデータエンジニアリングの大半の労力が費やされます。

ベンチマークと主要結果

AgentWorldBenchは、9つの確立されたエージェントベンチマーク上でフロンティアエージェント5つの軌跡を収集し、予測された各観測を実際の環境のground-truth観測とペアにして、format / factuality / state consistency / domain conventions / overallの5次元でスコアリングします。重要なのは、訓練データとベンチのクエリがデータソースレベルで分割されており、これは暗記ではなくOOD汎化の評価であることです。

5次元ルーブリックの平均において、Qwen-AgentWorld-397B-A17Bが総合首位のモデルであり、テキストベースのドメイン（Terminal、MCP、SWE、Search）では明確な差をつけ、GUIドメイン（Android、Web、OS）では競争力ある性能を示しています。

応用

本論文ではLWMを2つのデプロイモード（DecoupleとUnify）を通じて検証しています：

  1. エージェントRLのための環境シミュレータとして（“Sim RL”）。 Claw Agentのアンカー軌跡の少数サンプルを用いて、Qwen-AgentWorld-397B-A17Bは4,000件のOpenClawスタイルの環境を——完全にOODな——合成します。これは具体的な状態を変化させながらワークフロー構造を保持し、ユーザーインテントを言い換え・合成することで実現されます。このシミュレータでポリシーを訓練すると、ドメイン固有の適応なしにClaw-Evalで+4.3、QwenClawBenchで+7.1を達成します。制御可能な摂動（実世界ではめったに露出しない敵対的状態を意図的に注入）を加えると、MCPMarkは制御なしのSim RLに対して+12.3、WideSearchは+16.3向上します。最も印象的なのは、LWMに対するSim RLがライブ検索エンジンに対するRLを上回ること——50.3% vs 45.6%——です。完全に架空でありながら自己整合性のある世界でも、実際の検索に転移するポリシーが生まれ、さらにシミュレートされた知識からエージェントへのファクトリークを構造的に防ぎます。アブレーションにより、初期状態の詳細度がSim RLの改善における律速条件であることが特定されています。

  2. エージェントの基盤モデルとして（Unify）。 LWM訓練の目的関数それ自体が、同じバックボーンをその後ポリシーとしてSFT/RLする際の下流エージェントの性能上限を引き上げます。

推論分析

129件の思考トレース（Terminal/MCP/Search/SWEそれぞれ32〜33ターン）の手動分析では、1,347件の「Wait!」自己修正割り込みが見つかり、1ターンあたり平均10.4回、あるSWEターンでは最大56回に達しています。TerminalとMCPが最も高い頻度（16.9と12.7）を示しており、より重い状態追跡の負荷と一致しています。自己修正は、事実的（APIレスポンス形式の修正など）、認識論的（文脈内では計算不可能なことを認識すること——例えばnp.random.seed(42)の出力を捏造することを拒否し、正しい形式のみを出力する）、および視点取得的（Searchにおける回答リークを防ぐためにエージェントが知っている事実と環境が明かした事実を分離する）に分類されます。これにより観測予測は、単一パスの生成から制約充足探索の一形態へと変換されます。

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

  • AgentWorldBenchのスコアは部分的にルーブリックLLMジャッジに依存しており、付録のルールベースによる裏付けは主要な評価ではなく補足として報告されています。
  • GUIドメインはテキストドメインに比べて劣っており、テキスト化（アクセシビリティツリー、ビュー階層）が実際のGUIエージェントが現在活用しているピクセルレベルの情報を失っていることと一致しています。
  • Sim RLは初期状態の仕様がボトルネックとなっており、状態の完全性が下流転移とどのようにスケールするかを論文は定量化していません。
  • 397B-A17B vs. 35B-A3Bのギャップは忠実度がまだパラメータ数に依存していることを示唆しており、RLループ内で397Bのシミュレータを使用するコストは実質的であり、実環境の壁時計時間と比較したベンチマークは行われていません。
  • 汎化はOpenClawと検索でテストされており、構造的に異なるドメイン（物理ロボティクスやマルチエージェント経済など）は未解決のままです。

なぜ重要か

7つのインタラクティブなドメインにわたって、検索においてライブエンジンRLを上回る（50.3 vs 45.6）ほど忠実な言語ワールドモデルは、LLM内のシミュレータがトイタスクだけでなくスケールでのエージェント訓練において実環境を代替できるという最初の具体的な証拠です。もし律速条件がダイナミクスモデリングではなく状態の完全性であるならば、エージェントRLの今後の方向性は、より多くの実ロールアウトを収集することから、より豊かな初期状態分布を設計することへとシフトすることになります。

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

MobileForge: アノテーション不要のモバイルGUIエージェント適応のための階層的フィードバック誘導ポリシー最適化

問題設定

MLLMベースのモバイルGUIエージェントは特定のターゲットアプリに適応させる必要がありますが、アプリの数は膨大で頻繁に更新されるため、人手によるタスク記述、デモンストレーション、スカラー報酬ラベルで網羅することは現実的ではありません。既存のアノテーション不要のGUI学習パイプラインは手動監督を削減しますが、二つの構造的欠陥を抱えています：(i) ターゲットアプリの探索、カリキュラムマイニング、ロールアウト実行、評価を統合する統一基盤が存在しない；(ii) ポリシー最適化が疎で粗い報酬のもとで孤立したロールアウト上で実行されるため、弱いフィードバックをステップレベルの有用な gradient signal に変換することが困難である、という点です。MobileForgeはこの両方の問題に対処するために、同一の軌跡データを共有するインタラクション／評価環境とポリシー最適化アルゴリズムを構築しています。

動機：既存のアノテーション不要パイプラインとMobileForgeの統一基盤の比較。

設定と記法

エージェントは逐次的なGUI制御の下で動作します。試行 k、ステップ t における状態は

s_k^{(t)} = (x, I_k^{(t)}, \mathcal{H}_k^{(t)}, \eta_{<k}),

と定義されます。ここで x は生成されたタスク、I_k^{(t)} はスクリーンショット、\mathcal{H}_k^{(t)} はインタラクション履歴、\eta_{<k} は同一タスクに対する以前の試行からの修正ヒントです。ポリシーは構造化されたアクション a_k^{(t)} = (\alpha_k^{(t)}, \psi_k^{(t)}) \sim \pi_\theta(\cdot \mid s_k^{(t)}) を出力します。ここでアクションタイプは \alpha \in \{\text{tap, swipe, type, wait, terminate, answer, navigate}\}、引数 \psi は座標、テキスト、方向、ステータスです。一回のロールアウトは \tau_k = (s_k^{(1)}, a_k^{(1)}, \dots, s_k^{(T_k)}, a_k^{(T_k)}) です。重要な点として、環境は密なスカラー報酬を提供せず、報酬 R は評価器ラベル z, \ell から事後的に構築されます。

手法

MobileForgeは二つの連携したコンポーネントから構成されています：MobileGym（基盤）とHiFPO（最適化器）です。全体のループは

\begin{aligned} \mathcal{Z} &\leftarrow \operatorname{Explore}(\mathcal{E}), \quad \mathcal{T} \leftarrow \operatorname{Curriculum}(\mathcal{Z}),\\ \{\tau_k\}_{k=1}^K &\leftarrow \operatorname{Rollout}(\pi_\theta, x, \eta_{<k}),\quad \mathcal{F}_k \leftarrow \operatorname{Critic}(x, \tau_k),\\ \mathcal{D} &\leftarrow \operatorname{HiFPO}(\mathcal{T}, \tau, \mathcal{F}), \quad \theta' \leftarrow \operatorname{GRPO}(\theta, \mathcal{D}). \end{aligned}

と表されます。

MobileForge適応ループ：探索 → カリキュラム → ロールアウト → critic → HiFPO → GRPO。

MobileGym はターゲットアプリにおける到達可能なGUI状態 \mathcal{Z} を探索し、MobileGym-Curriculumを通じて実行可能かつ軌跡に根拠を持つタスク \mathcal{T} をマイニングし、ロールアウトを実行します。そしてMobileGym-Criticを通じて階層的フィードバック \mathcal{F}_k を生成します：軌跡レベルの合否結果 z、有益なアクションと有害なアクションを識別するステップレベルのプロセスラベル \ell、および同一タスクの次の試行に引き継がれる自然言語の修正ヒント \eta です。

MobileGym基盤：探索、カリキュラムマイニング、および階層的criticが結果ラベル、ステップラベル、修正ヒントを生成する。

HiFPO このフィードバックをポリシー gradient に変換します。以前の試行からのヒント \eta_{<k} はロールアウト中に状態に組み込まれるため、ポリシーはヒント条件付きの回復を学習します。階層的criticは (a) タスクのフィルタリング（例えば、解けないタスクや試行をまたいで自明に解けるタスク——これは標準的なGRPO advantageの退化ケース——を破棄する）と (b) 保持された軌跡内のステップ選択に使用されます。ステップレベルラベル \ell と結果ラベル z は、同一 x に対する試行グループ上のステップレベルGRPOアップデートを駆動する数値報酬 R に変換されます。ヒントが条件付けのコンテキストの一部であるため、このアップデートは論文が「hint-contextualized step-level GRPO」と呼ぶものです：advantageはタスクを共有しながらヒントコンテキストが異なる場合があるグループ内で計算され、コンテキストを所与としたアクション選択に対するクレジットを分離します。階層的フィードバックによるフィルタリングは、ほとんどのグループがゼロ advantageに収束してしまう疎報酬GUIロールアウト上での純粋なGRPOの既知の弱点に対処するものです。

結果

主要な結果として、Qwen3-VL-8Bを出発点とし、自動生成されたアノテーション不要の適応データのみを用いて、MobileForgeはAndroidWorld（116タスク）においてPass@3 67.2%を達成しており、クローズドデータのGUI特化モデルであるGUI-Owl-1.5-8B baseに近い性能を示しています。これはin-domainプロトコルによるもので、MobileForgeがAndroidWorldアプリのエコシステム自体を探索、カリキュラムマイニング、HiFPOロールアウトに利用しています。評価ではPass@1/2/3が報告されており、汎用8B VLMからGUIスペシャリスト並みの性能への向上が主要な主張となっています。

さらに論文では、MobileWorld GUI-only（117タスク）を分布外テストとして評価しています。ここでは適応にMobileWorldのタスク、ロールアウト、フィードバックを一切使用しておらず、適応がカリキュラムマイニングに使用したアプリを超えて汎化するかどうかを検証しています。

限界と未解決の課題

  • 報告されている主要指標はPass@3であり、成功とみなされるまでに最大2回の失敗試行を許容します；絶対的なPass@1がより信頼性を示す指標であり、abstractではその値が示されていません。
  • MobileGym-Criticの品質がすべての下流処理の上限となります。論文では（引用箇所において）ステップレベルラベルに対するcriticの適合率・再現率を特性評価しておらず、これはHiFPO報酬のノイズフロアを直接制御するものです。
  • Hint-contextualized GRPOは二つの改善点——より良い状態条件付け（推論時の \eta_{<k}）とステップレベルの報酬整形——を混在させています。それぞれを分離したablationによって、向上の要因を明確にする必要があります。
  • 探索駆動のカリキュラムマイニングは容易に到達可能な状態に偏るため、認証や稀な状態の奥にある長期的タスクはサンプリング不足になる可能性があります。
  • UIの頻繁な変更があるアプリへの汎化（動機となる問題）には、単一のベンチマークスナップショットではなく縦断的評価が必要です。

なぜ重要か

アノテーション不要のパイプラインがクローズドデータのGUIスペシャリストに匹敵できるなら、モバイルエージェント展開の主要なコスト——アプリごとの人手によるタスク作成とデモンストレーション収集——は大幅に削減され、適応はデータセットではなくランタイムの特性となります。技術的な鍵は、弱い言語形式のcriticフィードバックをステップレベルのGRPO signalに変換することであり、これはLLMジャッジがプロセスレベルのヒントを生成できる疎報酬のエージェント的設定全般に広く応用可能です。

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

MemGUI-Agent: プロアクティブなコンテキスト管理を備えたエンドツーエンドの長期ホライズン型モバイルGUIエージェント

問題設定

MLLMベースのモバイルGUIエージェントは、短期ホライズンのタスク（アプリを開く、ボタンをタップする、クエリを入力するなど）については十分な性能を発揮しますが、複数のアプリにまたがり中間的な情報を保持し続ける必要がある長期ホライズンのワークフローでは性能が著しく低下します。例えば、確認メールからフライト番号をコピーし、カレンダーアプリに切り替えてペーストし、その後メッセージアプリに戻って概要を転送する、といったタスクがその典型例です。著者らは、主要な失敗モードは知覚的なものではなく構造的なものであると主張します。すなわち、ReActスタイルのプロンプティングでは、各ステップごとに (thought, action, observation) のログがホライズン長に比例して蓄積されていきます。これにより2つの問題が生じます。第一は「プロンプト爆発」：ステップ30に達するころには、画面ごとのUIスナップショットと推論トレースがコンテキストウィンドウを飽和させてしまいます。第二は「希釈」：アプリをまたいで重要な情報（OTP、価格、受信者アドレスなど）が中間画面の無数の無関係な要素の中に埋没し、コンテキスト上のattentionがそれらを確実に検索できなくなります。

現実的なモバイルアシスタントタスク（予約、複数ステップの購入、アプリ間の情報転送など）の大半が長期ホライズン型であり、ベースMLLMが単一ステップのgroundingにおいて改善されるにつれて、短期タスクと長期タスクのベンチマーク差は広がりつつあることから、この問題は重要な意義を持ちます。

手法: Context-as-Action (ConAct)

中心的な抽象化は、コンテキスト管理をUIアクションを発行する同一ポリシーが発行するファーストクラスのアクションクラスとして扱うことです。具体的には、各ステップでポリシー \pi_\theta がUIアクション a^{\text{ui}}_t（タップ、スワイプ、入力、アプリ切り替え）か、構造化メモリ状態 M_t を変化させるコンテキストアクション a^{\text{ctx}}_t のいずれかをサンプリングします。メモリは3つの明示的なフィールドに分割されます。

  • 折り畳まれたアクション履歴 H_t：明示的なfold操作によって冗長または無関係な過去ステップが要約エントリに圧縮された、過去アクションの圧縮トレースです。
  • 折り畳まれたUI状態 S_t：ポリシーが保持すると判断した要素（例えば確認番号を含むメール本文）のみを保持した、顕著なUI観測の圧縮記録であり、生のアクセシビリティツリーは含みません。
  • 直近ステップ記録 R_t：次の意思決定のためのローカルなコンテキストを提供する、最新の (action, observation) ペアそのもののスライディングウィンドウです。

ステップ t でモデルに与えられる完全なコンテキストは、現在の画面を o_t として連結 C_t = [H_t; S_t; R_t; o_t] となります。ポリシーは以下のように因数分解されます：

p(a_t \mid C_t) = \pi_\theta(a^{\text{ui}}_t \cup a^{\text{ctx}}_t \mid C_t),

コンテキストアクションには fold_history(span, summary)、extract_ui_fact(field, value)、evict(field) といった操作が含まれます。これらの操作は同一の自己回帰的なheadから発行されるため、別途メモリコントローラや検索モジュールは不要であり、ポリシーはタスク実行とコンテキスト管理を交互に行うことができます。例えば、アプリを切り替える前に確認メールを閲覧した直後に extract_ui_fact("flight_no", "AA231") を発行するといったことが可能です。

ReActとの主要な対比は、ConActのコンテキスト更新が受動的な蓄積ではなく、プロアクティブかつ学習済みである点にあります。すなわちポリシーは、グローバルなタスクを条件として、何を記憶し、何を要約し、何を廃棄するかを自律的に決定します。

データと学習

ConActを学習可能にするために、著者らは完全なConActアノテーションを付与した2,956件の軌跡からなるデータセット MemGUI-3K を構築しました。すなわち、すべての軌跡にUIアクションだけでなく、適切に管理されたコンテキストを生成するためのfold/extract/evictアクションも付与されています。アノテーションにより各ステップで正解メモリ状態 M_t が得られるため、教師あり学習はUIアクションとコンテキストアクションを交互に含む系列に対する標準的なnext-token predictionに帰着されます：

\mathcal{L}_{\text{SFT}} = -\sum_t \log \pi_\theta(a_t \mid C_t).

これは注目すべき設計上の選択です。ホライズン依存の報酬を伴うRLに依存するのではなく、プロアクティブなメモリ管理をアノテーションされたコンテキスト管理決定の模倣として定式化しています。このデータセットは、コンテキストサイズ、事実保持率、eviction品質をエンドタスクの成功とは独立して測定できるオフライン分析材料としても機能します。

MemGUI-3Kで8Bサイズのが MMLLMバックボーンを学習することで、MemGUI-8B-SFT が得られます。

結果

アブストラクトによると、MemGUI-8B-SFTはMobile-Agent型の長期ホライズンベンチマークにおいてオープンデータ使用の8Bモデルの中で最高性能を達成しています。8B SOTAの主張と2,956件という軌跡数以外の具体的な数値は提供されたアブストラクトでは省略されています。同一スケールのReActベースラインとの比較という枠組みから、コンテキスト希釈が最も深刻な長期ホライズンタスクで大きな性能向上が集中しており、メモリ圧力が低い短期タスクでは同等か小幅な改善にとどまることが示唆されます。

限界と未解決問題

この設計からいくつかの問題点が見受けられます。(1) ConActの品質はアノテーション品質に依存します。どのUI情報を抽出すべきかの判断は本質的に主観的であり、教師あり模倣学習はタスク条件付きの必要性を学習するのではなく、アノテータのヒューリスティクスに過適合する可能性があります。(2) 3フィールドのメモリは手動設計であり、(H, S, R) が適切な分割であるか、よりフラットな学習済みスロットメモリと比較してどうかについてはアブストラクトでアブレーション実験が行われていません。(3) RLファインチューニング段階が存在しないため、ポリシーは誤ったeviction決定の下流コストを学習できません。ステップ5で誤って廃棄された事実がステップ25での失敗として初めて顕在化するという問題があります。(4) 8Bのみの結果では、より大きなコンテキストウィンドウがプロンプト爆発問題を部分的に吸収できる70B以上のスケールでConActが限界的な改善をもたらすかどうかが未解決のままです。(5) 学習済みのアクションレベルのメモリ制御の貢献を単独で評価するために、単純な要約ベースライン（定期的なLLMベースのコンテキスト圧縮）との計算量および推論レイテンシの比較が必要です。

意義

長期ホライズン型GUIエージェントの性能は知覚よりもワーキングメモリ管理によってボトルネックされており、ConActはその明快な再定式化です。すなわち、メモリ操作をアクションとして発行し、模倣学習で習得することで、検索モジュールを後付けする必要がなくなります。8B SOTAという結果が独立した長期ホライズンベンチマークでも再現されるならば、モバイルUI以外のエージェント的ドメインにおいても、コンテキストのキュレーションをポリシーのアクション空間の一部として扱うことの重要性を示す根拠となります。

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

OpenThoughts-Agent: エージェント型モデルのためのデータレシピ

問題設定

エージェント型LMの学習データに関するオープンな研究（SWE-Smith、SERA、Nemotron-Terminal）は、単一のベンチマークに対して最適化されており、コーディングエージェントおよびターミナルエージェントにわたって汎化するSFTコーパスをどのように構築するかは依然として不明確です。OT-Agentは、体系的なアブレーション駆動型のレシピを試みます。すなわち、どのタスクソース、命令の書き換え、軌跡フィルタ、およびスケーリング戦略が実際に転移するかを明らかにします。成果物は100K件の（タスク、軌跡）ペアからなるSFTデータセットと、7つのエージェント型ベンチマークで評価されたQwen3-32B fine-tuneであり、平均44.8%を記録し、Nemotron-Terminal-32Bの40.9%を上回っています。

パイプラインとアブレーション方法論

SFTパイプラインは6段階、すなわちタスクソーシング、命令の書き換え、軌跡生成、軌跡フィルタリング／スコアリング、アップサンプリング、およびミキシングから構成されており、各段階はホールドアウトされた3つのベンチマーク（SWE-Bench Verified-100、OT-TBLite、Terminal-Bench 2.0）に対して独立にアブレーションされます。

6段階のSFTデータパイプライン

異種ベンチマークスケールにわたる候補戦略をランク付けするために、著者らはベンチマーク b における戦略 s のper-benchmark z-scoreを次のように計算します。

z_{s,b} = \frac{a_{s,b} - \mu_b}{\sigma_b}

その後、b にわたって平均を取ります。アブレーションは10K件のサンプルで実行され（コスト効率が高く、有意なシグナルを持つ）、軌跡はGLM-4.7-AWQがDaytonaサンドボックス内のterminus-2ハーネスにおいて教師として軌跡を生成します。100件以上の制御済み実行が最終レシピに反映されています。

選択されたソースの組み合わせは「Top-4」、すなわちswe-smith、stackexchange-superuser、stackexchange-tezos、およびissue-tasksです。フィルタリングは \geq 5 ターンの軌跡のみを保持します。これは非自明なエージェント挙動の強いシグナルとしてアブレーションを経て選定されたヒューリスティックです。gpt-5-nanoからの応答長シグナルは、ハードなtop-k カットではなくソフトなアップサンプリングの重みとして使用されるため、すべてのユニークなタスクは少なくとも1つのロールアウトを受け取ります。

スケーリング：レシピが実際に破綻する箇所

タスクあたりのロールアウト数を増やすことで単純にスケーリングする方法（Method 1）は、31.6Kから100Kの間で停滞します（SWE-Bench Verified-100で+3pp、Terminal-Bench 2.0で−2pp、標準誤差の範囲内）。これは、ボトルネックがロールアウト数ではなくタスク記述の多様性にあることを示しています。

合成によるオーグメンテーションはスケールし続けるが、ロールアウトのアップサンプリングは停滞する

生のソースを追加する方法（Method 4）もこの問題を解決しません。Top-8はTop-4に対して混在した向上をもたらし（SWE-Bench Verified-100が49.00対45.33、Terminal-Bench 2.0が22.85対21.72）、Top-16はすべての指標で回帰します（40.33 / 33.14 / 20.60）。残る手段は合成タスクオーグメンテーション（Method 3）です。Tezosサブセット（ユニークタスク数はわずか997件、表層形式は約902種類）をセクション3.3の命令書き換え戦略を用いて書き換えることで、新たな根本問題を導入することなく21K件以上の表層形式に拡張します。その後、\geq 5 ターンフィルタを4つのすべてのソースに均一に適用します。

これにより、スケーリングの継続が可能になります。100Kにおいて、32BのSFTモデル（OpenThoughts-Agent-v2）はTerminal-Bench 2.0で26.2%、OT-TBLiteで41.3%、SWE-Bench Verified-100で55.7%に達し、31.6Kチェックポイントからの単調な向上として、SWE-Bench Verified-100で+7.7pp、Terminal-Bench 2.0で+5.0ppを記録します。

7つのベンチマークにわたるOT-Agentの最終結果

総合的な見出しとしては、OT-Agent-v2でfine-tuningされたQwen3-32BはNemotron-Terminal-32B（40.9%）に対して+3.9pp上回る44.8%を7つのエージェント型ベンチマークの平均で達成し、OT-Agentはすべての制御された学習セットサイズにおいて代替のオープンデータセットを凌駕しています。

強化学習への拡張

RL研究はコストの関係から8Bの規模に限定されています。学習は、検証結果からのバイナリ報酬（すべてのテストに対してexpect PASS: PASS、expect FAIL: FAIL）を用いたasync RLOOを使用します。コールドスタートはOT-Agent-ColdSFT-8Bであり、thinking付きのGLM-4.7-AWQによって生成されたSWE-Smithトレースから蒸留されています。主要な実行では24×A100 80GBを使用し、バッチサイズ64、実時間で約46時間を要します。セットアップはSWE-Smith / R2EGymと並行しており、dockerizable なリポジトリ、失敗するテストを持つ欠陥のあるコミット、自然言語の問題記述を使用します。RLのアブレーションはSFTのものと精神的に対応しており（データソースの感度）、RLをSFTレシピの代替ではなく後続ステップとして位置付けています。

制限事項と未解決の問題

  • アブレーションは10Kで実施され、3つのベンチマークで評価されます。z-scoreによるランク付けは、戦略間の分散が人為的に圧縮された段階を過大評価する可能性があります。
  • 多様性のボトルネックは選択されたソースに起因するアーティファクトである可能性が高く、論文ではオーグメンテーションが大規模スケールで真に新しいタスクコーパスを取り込むことに勝ることを示していません。
  • 合成オーグメンテーションは997件のTezos問題を再利用しており、オーグメンテーション密度が高まり表層形式の書き換えが新たな推論パターンを伝えなくなるにつれて、効果が飽和する可能性があります。
  • 教師（GLM-4.7-AWQ）は強力ですが特定の分布を持ちます。利得のどの程度がレシピによるものであり、どの程度が教師の品質によるものかは切り離されていません。
  • RLはバイナリ報酬を用いた8Bのみで研究されており、32Bへの転移および密な報酬の設計は未解決です。
  • 7つのベンチマークの平均はper-benchmarkのトレードオフを隠しています（例：Terminal-Bench 2.0はMethod-1スケーリング中に実際に回帰しました）。

なぜこれが重要か

オープンなエージェント型のpost-trainingは、単一ベンチマークのレシピと非制御のスケーリングに支配されてきました。OT-Agentは規律あるアブレーションを通じて、タスク記述の多様性こそが拘束制約であり、ロールアウト数でも生のソース数でもないことを実証しています。また、合成的な命令書き換えが停滞を打破するのに十分であることも示しています。完全に公開されたパイプラインは、将来のエージェント型SFTおよびRLデータ研究が比較対象とできる具体的で再現可能なベースラインをコミュニティに提供します。

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

FLAT: Feedforward Latent Triangle Splatting for Geometrically Accurate Scene Generation

問題設定

video diffusion priorに基づくfeedforwardな単一画像→3Dパイプラインは、通常latentを3D Gaussian splatsにデコードします。Gaussianはレンダリング品質に優れていますが、明確なサーフェスを持たないため、シミュレータ、メッシュ抽出器、あるいは方向付きジオメトリを前提とするグラフィクスパイプラインへの入力としては不向きです。自然な代替案として、フラットな三角形のようなサーフェス整合プリミティブが挙げられますが、最適化が困難であることが知られています。三角形の向きに関するgradientは不安定であり、ラスタライゼーションの重みはエッジから外れると消失しがちで、3つの頂点のうち2つがほとんど信号を受け取らないという問題があります。FLATが問うのは、凍結されたvideo diffusion modelのlatentを単一のforward passで直接triangle splatsにデコードし、サーフェスとの整合性と高忠実度の新規視点合成の両立を実現できるかどうかです。

FLATはvideo diffusion latentからsoft三角形を回帰します。

手法

パイプライン（図2）は単一のRGB画像 \mathbf{I}_0 と目標軌跡 \{\mathbf{P}_t\}_{t=1}^T（ただし \mathbf{P}_t=(\mathbf{K}_t,\mathbf{R}_t,\mathbf{t}_t)）を入力として受け取ります。単眼深度から軌跡に沿ってレンダリングされた点群ベースのcontrol videoが、カメラembeddingとともに凍結されたUni3C video diffusion modelを条件付けます。デノイズされたlatent \mathbf{z}\in\mathbb{R}^{F'\times C'\times H'\times W'} はカメラlatentと融合され、ワールド座標系におけるピクセル単位の三角形パラメータを出力する訓練可能なscene decoderに渡されます。

パイプライン：control video＋camera embeddingが凍結されたvideo diffusion modelを条件付け、decoderがデノイズされたlatentとカメラlatentを融合してtriangle splatsを生成します。

三角形回帰を扱いやすくするための設計上の工夫が2つあります。

Ray中心の回転パラメータ化。 各三角形に対して自由な SO(3) 回転を予測する場合（いずれかの軸における微小な角度誤差が、三角形平面と可視サーフェスとの間に大きなずれを生じさせる）の代わりに、FLATは各三角形をピクセルレイに固定します。decoderはカメラレイに沿った深度 d、平面内回転、および頂点位置をそのレイ点を通る平面上に定義する接線方向オフセットを予測します。これにより三角形は初期化時にカメラを向くように制約され、レイ周りの残差方向のみを学習すれば済みます。この方法はdecoderが探索すべき回転多様体を縮小し、頂点がレンダリングフットプリントの外に飛び出してしまう初期学習段階におけるgradient flowを大幅に改善します。

積ウィンドウ関数。 標準的な三角形ラスタライザは、各エッジの符号付き距離のsigmoid（三角形外部で急激に減衰し、遠い側の頂点からgradientを奪う）、またはmax-edge距離（最も近いエッジの2頂点にのみgradientを流す）のいずれかを使用します。FLATは代わりにエッジごとのソフト指示関数の積を使用します。模式的には

w(\mathbf{p}) = \prod_{e=1}^{3} \sigma\!\left(-\,s_e\, d_e(\mathbf{p})/\tau\right),

ここで d_e はエッジ e への符号付き距離です。積の形式は三角形境界を超えて非ゼロの影響を拡張しつつ、各サンプルが全3頂点にgradientを伝達することを保証します（図3）。これは各因子がそのエッジを定義する2頂点に依存しているためです。この工夫こそが、triangle splattingを病的な回帰ターゲットから安定したfeedforward予測問題へと転換する鍵となっています。

ウィンドウ関数：sigmoidエッジ、max-edge、および提案手法の積。FLATは三角形境界を超えて影響を拡張し、全3頂点にgradientを流します。

学習データと監督信号

モデルはまず25,000枚のS3OD画像とUni3Cが合成したvideoに加え、再生成されたRealEstate10KおよびDL3DVシーケンスを用いて事前学習されます（これにより、decoderはground-truthのvideo latentではなくdiffusion modelの実際のlatent分布を学習します）。その後、実際のRealEstate10K/DL3DVビデオでfine-tuningされます。すべてのシーンはMapAnythingの深度・カメラ予測によってメートルスケールに揃えられ、NormalCrafterによる疑似GTの法線がサーフェスの向きを監督します。Lyra、Bolt3D、Wonderlandのプロトコルに倣い、評価は単一画像からのfeedforwardな新規視点合成を対象とします。

結果

本論文の中心的な主張——図4で支持されている——は、triangle splatsがGaussianベースラインよりも大幅にクリーンなジオメトリを提供しつつ、レンダリング忠実度を維持するというものです。著者らが比較するGaussion表現は視覚品質のためにチューニングされており、体積的に厚くサーフェスが曖昧な再構成を生み出しますが、FLATの三角形はサーフェスに整合し、同等のPSNRを保ちながら、よりシャープな深度マップと法線マップを実現します。（Lyra/Bolt3D/Wonderlandに倣った評価プロトコルでは具体的なPSNR/SSIM/LPIPS/深度誤差の表が参照されていますが、現時点で入手可能な抜粋では最終的な数値は列挙されていません。定性的な主張は、レンダリング品質を維持しつつより精細で正確なジオメトリを実現するというものです。）

限界と未解決問題

  • このシステムは凍結されたUni3C video diffusion modelに依存しており、品質はUni3Cのカメラ条件付けへの追従性によって上限が決まります。著者らは困難な軌跡ではこれが失敗することを明示的に指摘しており（生成されたビデオでのMapAnythingによるポーズ再推定が必要）。
  • 三角形はlatentピクセル1つにつき1つデコードされるため、非常に細い形状や高周波なジオメトリは依然としてアンダーサンプリングされる可能性があり、この表現はwatertightなメッシュを生成しません。
  • 監督信号はNormalCrafterによる疑似GT法線とMapAnythingによるメートリック深度に依存しており、いずれかの系統的誤差がサーフェス予測に伝播します。
  • 積ウィンドウ関数がラスタライザの深度ソートにおける重複する三角形とどのように相互作用するか、また、ソフトな境界が遠背景に対する前景物体のシルエットのにじみを引き起こすかどうかは不明です。

なぜ重要か

FLATは、明示的なサーフェス整合triangle primitivesをvideo diffusion latentから1回のforward passで直接回帰できることを初めて実証したものです。ジオメトリ品質がGaussianのfeedforward decoderに対して定量的にも維持されるならば、シーンごとの最適化やpost-hocなメッシュ化を必要とせず、生成的なvideo priorから標準的なグラフィクス・シミュレーションパイプラインで使用可能なアセットへの道筋を提供します——ニューラルシーン生成と下流の3Dツールの間にある重要なギャップを埋めることになります。

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

Hacker News Signals

Qwen-AgentWorld: 汎用エージェントのための言語世界モデル

Qwen-AgentWorldは、エージェントの方策学習のためのシミュレータとして機能する言語世界モデル（LWM）の学習を提案しています。核心となるアイデアは、実際の環境とインタラクションする代わりに、エージェントが行動と状態の履歴を与えられた次の観測と報酬を予測する言語モデル、すなわちテキストベースの遷移関数 P(o_{t+1}, r_t \mid s_t, a_t) に問い合わせるというものです。本論文は、これを環境へのアクセスなしにオフラインまたは低コストなエージェント学習を可能にする手段として位置づけています。

アーキテクチャは、世界モデル（環境ダイナミクスを予測）とそれに対して学習される方策モデルを組み合わせた構成です。両者ともQwegのベースモデル上に構築されています。世界モデルは、多様な環境から得られたトラジェクトリでfine-tuningされ、タスク間での汎化を実現します。主要な貢献として主張されているのは、世界モデルを単なる評価器としてではなく学習シグナルとして活用する点であり、方策はLWM内のロールアウトを通じて更新されます。これはDynaスタイルのモデルベースRLに類似していますが、完全にトークン空間上で動作します。

評価はツール使用およびウェブナビゲーションのベンチマークにわたっています。このアプローチはAgentBenchスタイルのタスクで改善を示しているものの、LWMが生成するロールアウトが実際の環境をどの程度忠実に表現しているかが主要な未解決問題として残っています。シミュレートされた遷移ダイナミクスと実際の遷移ダイナミクスとの間の分布シフトは、マルチステップのロールアウトにわたって累積する可能性があります。

限界としては、長期ホライゾンのタスクにおけるハルシネーションによる遷移、世界モデル学習に対するトラジェクトリデータ品質への依存、そして単純により多くの実環境データを収集する場合と比較したスケーリング挙動の不明確さが挙げられます。

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

Show HN: Neural Particle Automata

Neural Particle Automata（NPA）は、連続空間における自己組織化システムであり、各パーティクルは近傍情報に対してローカルに適用された学習済みニューラルネットワークを用いて、自身の位置と内部状態を更新します。固定グリッド上で動作するセルオートマトンや、グリッド上の畳み込みカーネルを使用するLeniaとは異なり、NPAは非構造化点群（unstructured point clouds）上で動作するため、不規則な空間配置に対してより柔軟に対応できます。

各パーティクルは状態ベクトルを保持しています。各タイムステップにおいて、共有MLPがある半径内の近傍パーティクルの相対位置と状態を読み取り、速度と状態の更新量を出力します。したがってこの力学系は、入力として相対位置を用いることで構成上の平行移動同変性（translation-equivariance）を持ち、同一のネットワークが全パーティクルを支配します。学習は、微分可能シミュレーションと集約パターン統計量に基づく loss を用いて、安定パターン・群れ行動・自己複製といった創発的挙動をターゲットとして行われます。

デモでは、ランダムな初期状態からパーティクルが安定した構造へと自己組織化する様子が示されており、ネットワークはシミュレーションステップを通じた backpropagation によりend-to-endで学習されています。これは精神的にNeural Cellular Automata（Mordvintsev et al.）に近いアプローチですが、グリッドの制約を取り除いた点が異なります。計算コストは近傍クエリに依存してスケールし、空間ハッシングやk-dツリーによって高速化できますが、パーティクル数が多くなると計算が高価になります。

興味深い未解決問題としては、発見されたルールがスケールをまたいで汎化するかどうか、多くのシミュレーションステップを通じた gradient flow が安定しているかどうか（パーティクル相互作用を通じた勾配の爆発・消失問題）、そして学習されたルールが解釈可能かどうか、などが挙げられます。

Source: https://selforg-npa.github.io/

Mistral OCR 4

Mistral OCR 4は、古典的なOCRパイプラインではなく、マルチモーダルなドキュメントパーサーとして位置づけられたドキュメント理解モデルです。発表では構造化出力の忠実性が強調されており、テーブル、数式、コードブロック、および画像が埋め込まれた混合レイアウトのドキュメントが、生のテキストシーケンスではなくレイアウトを考慮したフォーマットで抽出されます。

技術的には、ドキュメントコーパスで大規模にfine-tuningされたvision-language modelであり、構造的なセマンティクスを保持したMarkdownを出力します。Mistralは標準的なOCRベンチマークにおける最先端性能を主張し、具体的な機能として、ネストしたテーブルの抽出、LaTeX形式の数式出力、多段組みの学術論文レイアウトへの対応を挙げています。これらはいずれも、汎用目的のVLMが性能低下しやすい領域です。

APIはMarkdownに加えて構造化JSONを返し、ページレベルのメタデータ、バウンディングボックス情報、要素タイプごとの信頼度シグナルへのアクセスを後続の解析パイプラインに提供します。これは、チャンキング戦略がトークンウィンドウではなくドキュメント構造に従うべきRAGパイプラインにとって重要な意味を持ちます。

料金はページ単位で、無料枠も用意されています。主な競合文脈はAWS Textract、Azure Document Intelligence、Google Document AI、およびSuryaやMarkerといった特化型モデルに対するものです。Mistralの差別化要因はLaTeX数式復元の品質と、同社のより広いモデルエコシステムとの統合です。

対応していない制限事項として、手書きテキストへの性能、大規模な非ラテン文字スクリプト、および劣化したスキャン画像が挙げられます。オープンウェイトは公開されていないため、監査性やfine-tuningは利用できません。技術レポートが公開されていないため、OCR 4が以前のバージョンと比較してどのような学習データやアーキテクチャ上の変更に基づいているかを評価することが困難です。

Source: https://mistral.ai/news/ocr-4/

Claude Codeの「Extended Thinking」出力に含まれるテキストは本物ではない

この投稿は特定の技術的主張を展開しています：Claude Codeのextended thinking表示に現れる「thinking」トークンは、モデルの内部的なchain-of-thoughtを忠実に描写したものではなく、最終的な回答の因果的上流に位置するのではなく、表示目的で別途あるいは事後的に生成されている可能性があるというものです。

この主張は行動実験に基づいています：表示されているthinkingテキストを変更しても最終出力に影響がないこと、thinkingの内容が最終回答の推論経路と矛盾する記述を含むことがあること、そして表示トークンが実際に応答前に処理されていると仮定した場合に期待されるレイテンシプロファイルと実測値が一致しないこと、などが挙げられます。モデルの内部にはアクセスできないため、これらは間接的な検証手段に過ぎません。

この問題には特定の技術的重要性があります：extended thinkingは透明性のメカニズム――モデルの推論を監査し誤りを検出する手段――として宣伝されています。もし表示される推論が機構的なものではなく装飾的なものであるならば、エージェント的なコード生成ステップのデバッグや検証にそれを用いることは不健全です。この問題はchain-of-thoughtの「faithfulness」に関する一般的な研究文献（Turpin et al., 2023）とは異なります。同研究は、CoTが出力に影響を与える場合でも潜在的な計算を正確に反映しているかどうかを問いましたが、本投稿の主張はより強力です――そのテキストは計算と全く結びついていない可能性があるというものです。

Anthropicはこの具体的なアーキテクチャについて公式に肯定も否定もしていません。「extended thinking」モデルについて公開されている情報によれば、thinkingトークンは応答の前に自己回帰的に生成されてコンテキスト内に含まれるとされており、そのため投稿の行動的証拠は精査に値します。これらの実験は示唆的ではあるものの、APIレベルのテストにおける交絡因子を考慮すると、決定的とは言えません。

Source: https://patrickmccanna.net/the-text-in-claude-codes-extended-thinking-output-is-not-authentic/

AIのアフォーダビリティ危機

David Rosenthalの投稿は、製品批評ではなくインフラ経済学の議論です。核心的な主張は次の通りです：現在のAIコンピュートスタックは、ユースケースや組織の長尾に対して構造的に費用を賄えない状態にあり、業界は補助金を受けたAPIの価格設定やハイパースケーラーのクロスサブシディゼーションによってこの事実を覆い隠しているというものです。

技術的な内容は、トークンあたりのコスト計算を中心に展開されます。Rosenthalは、H100/H200クラスターの設備投資コスト、バッチング非効率・KV cacheの圧迫・I/Oボトルネックにより理論的最大値を大きく下回る実際の稼働率を精査した上で、現在の市場レートを大幅に上回る持続可能なトークン単価の推定値を導き出しています。暗示される結論は、現在の価格設定がコストを下回っており、それはユーザー獲得のための補助金競争か、将来のハードウェアコスト曲線が経済性を正当化するという想定のいずれかを反映しているというものです。

彼はこれをinference scalingのレジームとも結びつけています。より長いcontext、より長いchain-of-thought、そしてエージェント的なマルチステップワークロードは、クエリあたりのコストを非線形に増大させます。1回の拡張推論クエリが、数百件の標準的な補完に相当するコンピュートを消費することもあります。エンタープライズまたはコンソーマースケールでは、これは現在のアプリケーションアーキテクチャを正当化するユニットエコノミクスを破壊します。

より広いシステム的な指摘として、ハードウェアの調達サイクル（発注から導入まで18〜24ヶ月）、電力インフラの整備（数年単位）、および冷却能力は、需要に対して弾力的に反応しないハードな制約であるという点が挙げられます。コスト曲線が経済性を救うほど速く低下するという想定は、タイムラインが不確かなアーキテクチャ上のブレークスルー（例：準二次的なattention、より効率的なtraining）に依存しています。

Chinchillaスケーリングの文献やHoffmann et al.のコスト最適training分析と併せて読む価値があります。

Source: https://blog.dshr.org/2026/06/ais-affordability-crisis.html

Usbliter8: A12/A13 SecureROM エクスプロイト

Usbliter8 は、Apple の A12 および A13 SoC を対象とした SecureROM（BootROM）エクスプロイトです。checkm8（A5〜A11）の系譜に連なるものであり、iPhone XS から iPhone 11 シリーズを含む新しいデバイスへの、ソフトウェア更新では修正不可能なハードウェアレベルのアクセスを拡張することを目的としています。

技術的なメカニズムとしては、SecureROM 内の USB スタックに存在する脆弱性を悪用します。具体的には、DFU（Device Firmware Update）モードが USB コントロール転送を処理する方法に問題があります。BootROM の USB 実装は最小限のものであり、メイン OS の USB スタックが備えるすべての保護機能を持っているわけではありません。このエクスプロイトは、慎重にタイミングを調整した USB トランザクションによって引き起こされるメモリ破壊状態を利用し、セキュアブートチェーンがブートローダーを検証する前に、SecureROM コンテキストで任意のコードを実行できるようにするものと考えられます。

BootROM エクスプロイトが重要視される理由は、SecureROM がマスク ROM であるためです。すなわち、ソフトウェア更新によってパッチを当てることができません。脆弱な SoC を搭載したデバイスは、そのハードウェアが存在する限りエクスプロイト可能な状態にとどまります。これは、checkm8 が長期にわたって有効であり続けた理由と同じ特性です。このエクスプロイトにより、ジェイルブレイク、Secure Enclave Processor（SEP）インターフェースの研究、そしてフォレンジックアクセスが可能となります。最後の点については、法的・政府機関向けツールへの影響（例：Cellebrite や GrayKey による BootROM レベルのアクセス活用）があります。

A12 は、checkm8 が対象としていた範囲と比較してリスクをわずかに高めます。A12 では第二世代の Secure Enclave と pointer authentication codes（PAC）が導入されているためです。usbliter8 が BootROM コンテキストにおいて PAC の制約を回避しているのか、あるいは単に PAC がアクティブになる前の段階で動作しているのかは、技術的に重要な点ですが、投稿時点の公開された記述では詳細が完全には明らかにされていません。

Source: https://ps.tc/pages/blog-usbliter8.html

採用におけるアルゴリズム的モノカルチャー

Stanford HAI の記事では、AIを用いた採用スクリーニングツールにおける人種的バイアスを検証した研究を取り上げています。技術的な核心は、単一システムのバイアスではなく、複数システム間における誤りの相関——モノカルチャー問題——にあります。

複数の雇用主が独立して同一または類似のembeddingベースの履歴書スクリーニングシステムを採用する場合（市場はHireVue、Pymetricsおよびその他わずかなベンダーが支配していることが多い）、あるシステムで不採用となった候補者は、系統的に多くのシステムでも不採用となります。これは、共有されている基盤モデルのアーキテクチャと学習データが相関した偽陰性を生み出すためです。競争的な労働市場において、モデルが学習した分布の外に位置する候補者——歴史的なデータを考えると、人種、出身教育機関の名声、および名前のパターンと相関している——は、単一の偏った門番ではなく、同一の門番を何重にも相手にすることになります。

形式的な構造として、p_i をスクリーニングシステム i による不採用確率とします。共有モデル M を持つ独立したスクリーニングシステム群の下では、すべての i に対して p_i = f(M, x) となるため、不採用は独立ではなく完全に相関します。候補者は、個々に異なるバイアスを持つ人間の審査官の場合のように、複数の雇用主に渡ってリスクを分散させることができません。

この研究では監査手法を使用しています。資格を揃えつつ人種と相関した名前シグナルだけを変えた合成履歴書を、特定のツールを使用していることが判明している雇用主群に送付し、返答率の格差を記録しています。

残された技術的な問いは、adversarial debiasing、多様なモデルのエコシステム、または規制上の開示要件がこのモノカルチャーを解体できるかどうかという点です。モノカルチャーという枠組みは、共有された依存関係による相関した障害モードに関する、より広範なシステム信頼性の議論とも結びついています。

Source: https://hai.stanford.edu/news/ai-hiring-tools-can-yield-racial-bias-and-systemic-rejection

Show HN: Recall – Claude Code向けローカルプロジェクトメモリ

Recallは、Claude Codeセッションのための永続的なプロジェクトローカルメモリストアを維持するCLIツールです。このツールが解決する問題は、Claude Codeのコンテキストウィンドウがセッション間でリセットされ、蓄積されたプロジェクト固有の知識（ファイル構造の設計根拠、アーキテクチャ上の決定事項、繰り返し現れるパターン、既知のバグ）が失われてしまうことです。

実装では、プロジェクトルートの .recall/ ディレクトリにプレーンテキストまたはMarkdownファイルとしてノートを保存します。CLIインターフェースにより、開発者はメモリエントリの書き込み、タグ付け、および取得が可能で、セッション開始時にClaude Codeのsystem promptまたはCLAUDE.mdに注入されます。embedding ベースの検索は使用しておらず、設定されたストラテジーと合計トークンバジェットに応じて、キーワードフィルタリングまたはフルコンテキスト注入が行われます。

ベクターデータベースではなくフラットファイルを使用する設計上の選択は意図的なものです。これにより、ツールの監査可能性が保たれ、gitへのコミット（チーム共有メモリ）が可能になり、ローカルのembeddingモデルやベクターストアを実行する際の依存関係のオーバーヘッドを回避できます。トレードオフとして、コンテキストバジェットが制約となる数百エントリ以上には検索がスムーズにスケールしません。

興味深いエンジニアリング上の選択として、このツールはAnthropicが永続的なコンテキストを注入する標準的な方法として文書化しているClaude CodeのCLAUDE.md規約にフックします。これにより、RecallはCLIをモンキーパッチするのではなく、サポートされたインターフェースの上に層を重ねる形となり、Claude Codeのアップデートに対してより堅牢になっています。

制限事項として、会話履歴からのメモリの自動抽出はなく（エントリは手動で書き込む）、重複排除もなく、またメモリが増大するにつれてフルコンテキスト注入ストラテジーは大規模プロジェクトで劣化します。リポジトリは初期段階にあり、テストカバレッジは限定的です。チームでの利用においては、現在の設計では対処されていない .recall/ ファイルのマージコンフリクトが実際の懸念事項となります。

Source: https://github.com/raiyanyahya/recall

注目の新規リポジトリ

portbuster1337/ArachneC2

IPFSやlibp2pベースのブロックチェーンノードの基盤となっているピアツーピアネットワークスタックであるlibp2pの上に構築された、分散型のコマンド＆コントロールフレームワークです。エージェントのトラフィックを中央のチームサーバー（従来のC2アーキテクチャにおける単一障害点かつ明白なネットワークIOC）経由でルーティングするのではなく、ArachneC2はインプラントの通信をlibp2p DHTオーバーレイを通じてルーティングします。各ノードがメッシュに参加するため、ブロックあるいはテイクダウンの対象となる固定のC2 IPが存在しません。このフレームワークはlibp2pの多重化ストリームとnoiseプロトコルハンドシェイクをトランスポートセキュリティに活用しており、独自の暗号実装を行うことなく、オペレーターに暗号化・認証済みのチャネルを提供します。分散型のトポロジーはアトリビューションも困難にします。トラフィックは既知のドメインやIPへのビーコン通信ではなく、一般的なp2pアプリケーションのノイズに類似して見えるためです。オペレーターの観点からは、インフラのテイクダウンに対する耐性と、ネットワーク層での検知の困難化を意味します。トレードオフとして運用上の複雑さが生じます。DHTベースのインプラントメッシュの管理は、シンプルなHTTPチームサーバーと比較してデバッグが難しく、またp2pトラフィックにおけるタイミングサイドチャネルはディフェンダーにとって現在も活発な研究領域です。検知耐性のあるインフラを研究するレッドチーム、および中央C2指標が存在しない状況でも機能する振る舞い検知の構築を行うブルーチームの双方にとって関連性の高い内容です。

Source: https://github.com/portbuster1337/ArachneC2

jestasecurity/thumper

Thumperは、Shai-Hulud npmワームを検知するために特別に設計されたcanary-tokenシステムです。このワームはファイルシステムをスキャンして認証情報ファイル（.npmrc、.env、AWS設定ファイルなど）を探し出し、発見した秘密情報を外部に送信します。防御策はシンプルです。構文的には有効ながら失効済みまたは監視下にある認証情報を、ワームが探索することがわかっているパスに正確に配置し、その認証情報への読み取りや使用が発生した瞬間にアラートが発火するよう仕込みます。Thumperはこれらのデコイファイルの生成と配置を自動化し、認証情報へのアクセスが発生した瞬間に発火する監視フックと連携します。また、SaaS依存なしに完全オフラインで動作します。技術的アプローチはクラシックなtripwireであり、斬新な点はShai-Huldの既知のスキャンパターンに合わせてチューニングされた脅威特化型の配置ロジックです。ワームはファイルを実行するのではなく読み取ることで動作するため、ファイルシステムレベルの監査フック（Linux上のinotify、macOS上のFSEvents）によりサブ秒単位の検知レイテンシが実現されます。無償のオープンソースビルドであるため、ディフェンダーはどのような認証情報が配置されているかを正確に監査し、有効なものが一切含まれていないことを検証できます。信頼できないまたはサードパーティのパッケージを実行しているnode.js環境（ほとんどの本番スタックが該当します）に有用です。主な制限として、このシステムは特定のワームの既知の動作に対してリアクティブであり、既知のデコイパスをスキップするような亜種には回避される可能性があります。

Source: https://github.com/jestasecurity/thumper

PentesterFlow/agent

ターミナル上で完全に動作するエージェント型の攻撃的セキュリティアシスタントであり、CLIから離れることなくLLMによる支援を受けながら列挙と攻撃を行いたいペネトレーションテスターを対象としています。エージェントループは、推論モデルをツール層に接続します。このツール層は標準的なペンテストユーティリティ（nmap、gobuster、sqlmap、curlなど）をラップし、偵察・脆弱性特定・攻撃ステップを繰り返し実行しながら、ツール呼び出しの結果をコンテキストにフィードバックします。アーキテクチャは標準的なReActスタイルのループ（観察→推論→行動→繰り返し）に従っています。汎用的なコード実行エージェントとの差別化点は、ドメイン固有のprompt engineering、ペンテストに適したラッパーを備えたキュレーション済みのツールレジストリ、および汎用的なシェル出力ではなくセキュリティツールのフォーマットに合わせた出力パースにあります。すべてがターミナル上でローカルに動作するため、クラウドベースのセキュリティコパイロットで懸念されるデータ漏洩の問題を回避できます。これはNDA締結下でクライアントのインフラに対して作業する場合に重要です。エージェントはカスタムツール定義をサポートしているため、社内ツールや独自スキャナへの拡張も容易です。未解決の課題としては、コンテキストウィンドウを超えてしまう長大な列挙出力の信頼性ある処理と、fine-tuningなしで推論モデルが特殊なまたはCTF固有の攻撃パスにどこまで汎化できるかという点が挙げられます。

Source: https://github.com/PentesterFlow/agent

fancyboi999/ai-engineering-from-scratch-zh

AIエージェントエンジニアになるための構造化された中国語カリキュラムで、503の個別レッスンをカバーする20の段階的なステージに整理されています。このコンテンツは英語のAIエンジニアリング教材を完全に翻訳したものに、コンパニオンウェブサイトとアニメーション解説動画を補足したものです。技術的には、カリキュラムはフルスタックを網羅しており、LLMの基礎概念、prompt engineering、RAGパイプライン、ツール使用とfunction calling、マルチエージェントオーケストレーションフレームワーク（LangChain、LlamaIndex、AutoGen）、評価、およびデプロイメントパターンを含みます。20段階の進行は、事前のML研究の背景を前提とせずに、開発者をMLの基礎から本番環境のエージェントシステムまで導くよう設計されています。中国語話者の実践者にとっての価値は、主に英語で書かれているAPIドキュメント、フレームワークのソースコード、および研究論文に取り組む際の翻訳オーバーヘッドを排除できる点にあります——これは学習を遅らせる現実的な摩擦点です。アニメーション動画コンポーネントは、視覚的な説明によって直感を再構築することで、生の翻訳テキストの教育的品質が悪名高く低いという問題に対処しています。503レッスンという規模は野心的であり、主なリスクは各トピックの深さを犠牲にしたカバレッジの広さです。また、エージェントフレームワークが急速に進化する中で、カリキュラムは継続的なメンテナンスを必要とするでしょう。

Source: https://github.com/fancyboi999/ai-engineering-from-scratch-zh

raiyanyahya/recall

RecallはClaude Code（Anthropicのコーディングエージェント）におけるコンテキストの健忘症を、永続的なオフラインメモリ層を提供することで解決します。各セッションでClaude Codeはプロジェクトに関する知識をゼロから始めるため、開発者はアーキテクチャ、規約、過去の意思決定を再説明するためにトークンを無駄にしてしまいます。Recallはプロジェクトスコープのメモリ——下した決定、ファイル構造、従うべきパターン、避けるべき事項——をローカルに保持し、新しいセッションのコンテキストに関連するサブセットを自動的に注入します。実装は完全オフラインで動作します。外部メモリサービスへのAPI呼び出しはなく、データがマシン外に出ることもありません。技術的なメカニズムはプロジェクトをキーとした構造化ドキュメントストアであり、セッション開始前に現在のタスクコンテキストに基づいて関連するメモリフラグメントを選択する検索ロジックを持ちます。意味的にはこれは自身のエンジニアリングノートに対するRAGシステムですが、汎用的なドキュメントQAではなくClaude Codeのワークフロー専用に構築されています。オフライン制約は、プロジェクトコンテキストをクラウドメモリサービスに送信することが選択肢にならない独自コードベースにとって重要です。制限事項として、検索品質はメモリがどれだけ適切にチャンク分割・インデックス化されているかに依存すること、コンテキストに注入された古いまたは矛盾するメモリはエージェントを助けるどころか誤誘導する可能性があること、そして現在このシステムはエージェント非依存ではなくClaude Code専用であることが挙げられます。

Source: https://github.com/raiyanyahya/recall

gykim80/perfectpixel-studio

テキストプロンプトから2Dアニメーションスプライトシートを生成するデスクトップアプリケーションです。多方向キャラクタースプライトを必要とするゲーム開発者やアーティストをターゲットとしています。このパイプラインは単一のテキスト説明を受け取り、8方向の向きと100種類以上の個別アクションアニメーション（idle、walk、run、attack のバリアントなど）を含むスプライトシートを生成します。これは手作業で制作するには膨大な労力を要する組み合わせ的な出力です。技術スタックはWails（Webフロントエンドを持つネイティブバイナリにコンパイルされたGoバックエンド）とUIのためのReactで構成されており、Electronのメモリオーバーヘッドなしにネイティブデスクトップのパフォーマンスを実現しています。AIの生成バックエンドは、方向やフレームを跨いだキャラクターの同一性を維持するために、画像生成モデルとスプライトシートのレイアウトおよび一貫性強制ステップをチェーンしていると推測されますが、詳細なモデルの仕様はリポジトリの説明には開示されていません。8方向という制約はトップダウンおよびアイソメトリックゲームの要件に直接対応しています。インディー開発者にとっての価値は明確で、スプライトシートの生成は2Dゲーム開発における最大のアートボトルネックの一つです。未解決の課題としては、アニメーションフレーム間の時間的一貫性（キャラクターの外見のドリフトを回避すること）、非人型キャラクターへの対応、そして手動クリーンアップなしに本番使用に耐えるだけの出力解像度とスタイルの制御性が確保されているかどうか、などが挙げられます。

Source: https://github.com/gykim80/perfectpixel-studio

agentic-in/inferoa

「tokenmaxxing」エージェント型推論ループ向けのハーネスです。tokenmaxxingとは、長時間稼働するLLMエージェントループにおいて、トークン予算あたりに引き出せる有用な作業量を最大化する手法です。このフレームワークが取り組む核心的な問題は、ナイーブなエージェントループがトークン効率に優れないという点です。すなわち、冗長なコンテキスト、構造化が不十分なtool-callの出力、および無制限な生成が、タスク完了率を改善しないまま予算を浪費してしまいます。Inferoaは推論ネイティブなフレームワークとして位置づけられており、トークン予算管理はデフォルトのチェーンロジックの後付けではなく、ループエンジニアリング層における第一級の関心事として扱われます。技術的な内容には、ループオーケストレーションのプリミティブ、コンテキスト圧縮フック、およびエージェントの各ステップでトークンがどこで消費されているかをプロファイリングするためのツール群が含まれます。「tokenmaxxing」というフレーミングは理論的というより実践的なものです。大規模運用では、エージェント呼び出しあたりのトークンを20〜30%削減することが、コストとレイテンシの直接的な改善につながります。このフレームワークは、デフォルトのチェーンロジックが生成するものをそのまま受け入れるのではなく、各ステップでプロンプト予算をプログラム的に制御したいと考えるエージェントパイプライン構築エンジニアを対象として設計されています。リポジトリは初期段階にあり、主要な未解決の問題は、その抽象化が異なる基盤モデルやツールエコシステム間でクリーンに汎化するかどうか、あるいは特定のプロバイダーのトークン化と価格体系に暗黙的に依存しているかどうかという点です。

Source: https://github.com/agentic-in/inferoa

aresyn/codex-control-plane-mcp

Model Context Protocol（MCP）を介して公開される、Codex Desktopタスク向けの耐久性のあるコントロールプレーンです。解決しようとしている問題は、Codex Desktopのタスクがエフェメラルかつステートレスであるという点です。すなわち、長時間実行中のコーディングタスクがネットワーク切断・デスクトップのスリープ・プロセスの強制終了などにより中断された場合、進捗状況が失われ、タスクを最初からやり直さなければなりません。このMCPサーバーは永続化レイヤーを追加し、タスクの状態をチェックポイントとして保存することで、中断されたタスクを最初から再起動するのではなく再開できるようにします。MCPインターフェースを採用しているため、コントロールプレーンはカスタム統合作業なしにMCP対応のクライアントと統合できます。

技術的には、耐久性はタスクの状態（現在のステップ・tool-callの履歴・中間出力）を各チェックポイントで永続ストレージにシリアライズし、再接続時に最後のチェックポイントからリプレイすることで実装されています。これはTemporalのような耐久性実行フレームワークがワークフローの再開を処理する方法と類似しており、それをCodex Desktopのエージェントループに特化して適用したものです。数時間に及ぶリファクタリングやコード生成タスクを実行する開発者にとって、信頼性の向上は大きな意味を持ちます。

注目すべき制限事項として、チェックポイントの忠実度はMCPサーバーがエージェントの状態をどれだけ完全に捕捉できるかに依存する点が挙げられます。もし基盤となるCodexプロセスがMCPインターフェースを通じて公開されていない状態を保持している場合、それらのコンポーネントはチェックポイントの対象にならず、真の意味での再開可能性は部分的なものにとどまります。

Source: https://github.com/aresyn/codex-control-plane-mcp