デイリーAIダイジェスト — 2026-08-21

公開

2026年8月21日

English · 日本語

arXiv ハイライト

MemTrapBench: LLMのメモリ利用における認知トラップのベンチマーク

問題設定

メモリ拡張型LLMは一般に、抽出・更新・検索パイプラインが正しい事実を保存・返却できるかどうかで評価されます。しかし、そのパイプラインが完璧であっても、エンドタスクの性能は低下し得ます。意味的に関連性があり、忠実に保存されたメモリであっても、モデルの推論軌跡や現在のクエリに対する信念を偏らせることがあるからです。著者らはこれをメモリトラップとして形式化しています。インタラクション履歴 \mathcal{D}、抽出 E、更新 U、検索 R、そしてメモリ M = R(x, U(E(\mathcal{D}))) が与えられたとき、トラップは以下の条件で発生します。

s(\hat{y}_M) < s(\hat{y}_\varnothing), \quad \hat{y}_M = G(x, M),\ \hat{y}_\varnothing = G(x, \varnothing).

この失敗は検索品質にあるのではなく——検索されたアイテムは話題的に関連している——LLMがそれを条件付けに用いる方法にあります。これは、保存されたコンテンツのリコール・一貫性を主に測定する従来のメモリベンチマーク（LOCOMO、LongMemEvalなど）とは異なる評価軸です。

図1: メモリは常に必要とは限らない。

典型的な例として、階乗パターンを認識することで解けるクエリが挙げられます。検索されたメモリには、セッション前半からの正確で関連性のある算術の計算例が含まれています。それらの例を条件付けに用いることで、モデルは同じ形式の算術操作に固定されてしまい、メモリ自体には誤情報が含まれていないにもかかわらず、階乗を考慮することができなくなります。

タクソノミーと構築

MemTrapBenchはメモリトラップを、それぞれ2つのシナリオを持つ2つのカテゴリに分類します。

  • Reasoning Fixation（推論固着）: 検索された手順・スキーマが問題解決を偏らせる。
    • Task: 特定のツール・操作で解かれた過去の問題が、現在の解空間を制約する。
    • Boundary: 過去のタスク制約が、異なる制約のない現在のタスクに漏れ出す。
  • Belief Distortion（信念歪曲）: 検索されたコンテンツが現在の入力に対するモデルの信念を乱す。
    • Cognitive Bias: 過去のアンカリング、フレーミング、または順序効果。
    • Trauma / Safety: 過去の攻撃的な訂正や拒否が、過度に一般化された慎重さを引き起こす。

図2: MemTrapBench構築の概要。

各アイテムは、履歴 \mathcal{D}、現在のクエリ x、および参照回答のトリプルで構成されます。重要なのは、\mathcal{D} が、現在の正しい回答が検索されたコンテンツの適用可能性を無視または制限することを要求するように構築されている点です。例えば、過去のコンテキストが特定の患者に対する禁忌を指定する一方、現在のクエリは禁忌のない別の患者に関するものである、といった場合です。表2のトラウマのケースは代表的な例です。攻撃的な否定的フィードバック（「あなたが彼を殺すことになる！」）の後、モデルは筋肉内エピネフリンの投与が必要な、関係のない健康な新しいアナフィラキシーショック患者への推奨を拒否しますが、攻撃的なターンがなければ正しく回答します。

図3: MemTrapBenchの代表的な例。

結果

Gemini-3-Flash-PreviewとQwen3-30B-A3B-Instruct-2507において、5つのメモリフレームワークがメモリなしベースラインと比較してベンチマークされています。対象フレームワークはFullText（生の履歴）、LightMem（段階的圧縮）、MemOS（統合異種メモリ）、SimpleMem（構造化意味圧縮 + クエリアウェア検索）、EverMemOS（階層的長期メモリ）です。

4つのシナリオにわたる平均のヘッドライン数値：

  • Gemini-3-Flash-Preview: wo/Mem 85.16。すべてのメモリ戦略がアンダーパフォーム: EverMemOS 71.17、LightMem 70.11、FullText 60.68、MemOS 60.67、SimpleMem 54.69。最良のメモリシステムでも、メモリなしに対して13.99ポイントの差がある。
  • Qwen3-30B-A3B-Instruct-2507: wo/Mem 81.83。最良はFullTextの70.99；LightMem 70.13、EverMemOS 66.47、MemOS 64.88、SimpleMem 62.87。最良手法でも10.84ポイントの差。

シナリオ別では、トラウマ・安全軸が最も破壊的です。Geminiはwo/Memの95.90から、MemOS下では56.15、SimpleMem下では58.05まで低下しており、保存されたメモリに事実誤りがなく、純粋に過去の攻撃的フィードバックによって引き起こされた約40ポイントの崩壊です。Reasoning-Fixation Boundaryは一様に困難で、wo/Memの70.95 / 63.23に対し、どちらのモデルでもどの手法も66を超えません。

2つのモデル間で興味深い逆転が見られます。Geminiでは、構造化・圧縮スキーム（LightMem、EverMemOS）がFullTextを約10ポイント上回っており、圧縮が一部の固着キューを減衰させる可能性を示しています。Qwenでは、FullTextが最良のメモリ戦略であり、圧縮によってメモリのスコープを定めるはずのコンテキストが失われています。これは、トラップの深刻さはメモリ品質そのものではなく、メモリ表現とベースモデルの条件付け挙動の相互作用に依存することを示唆しています。

注目すべきことに、Belief Distortion → Cognitive Biasは、メモリが場合によって有益に働く領域の一つです（Qwen FullText 90.27 対 wo/Mem 87.17）。これはトラップがメモリコンテンツに対して単調ではないことを示しています。

AdaptiveMem

著者らは推論時の緩和策としてAdaptiveMemを提案しており、これはLLMに検索されたメモリを助言的なものとして扱い、条件付けの前にスコープの不一致を確認するよう指示します。アブストラクトでは「MemTrapBenchにおける認知トラップを緩和しつつ、性能を維持または改善する」と報告されていますが、本稿で扱った短縮版セクションでは規模の定量化は行われていません。

限界と未解決問題

  • 使用したモデルは2つのみで、いずれも強力なinstruction-tunedシステムです。小規模モデルやベースモデルが異なるトラッププロファイルを示すかどうかは検証されていません。
  • ベンチマークは構築された履歴に依存しており、実際の運用においてそのようなトラップを誘発する設定がどの程度の頻度で生じるかは不明です。
  • s(\hat{y}_M) < s(\hat{y}_\varnothing) はトラップの存在基準ですが、検索の選択によるトラップと、任意の関連メモリの条件付けに内在するトラップを区別しません。
  • プロンプトによる緩和は脆弱であり、根本的な修正にはおそらく学習時の介入（例：トラップ・非トラップ条件付けに関するcontrastive training）や検索時のスコープ推論が必要です。

この研究が重要な理由

メモリパイプラインは通常、忠実な保存と関連性に向けて最適化されていますが、MemTrapBenchは「完璧な」検索——意味的に話題に沿っており、事実的に正確——であっても、推論をアンカリングしたり過去の制約を過度に一般化したりすることで、下流タスクにおいて10〜40ポイントのコストをもたらし得ることを示しています。これはメモリシステムの評価を再定式化します。目標は検索の忠実性ではなく条件付き有用性であり、現在のアーキテクチャはメモリなしベースラインに対してネットネガティブです。

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

Listening Forward: Next Patch Embedding Prediction Enables Scalable Audio Learners

問題設定

自己教師あり音声事前学習は、ますます複雑なレシピへと収束しつつあります。具体的には、注意深いマスキング比率を持つマスクドスペクトログラムモデリング、EMAティーチャー、マルチビュー拡張、ハード負例マイニングを用いたcontrastive objective、コードブックベースの離散化ステージなどが挙げられます。これらのパイプラインは強力なエンコーダを生成しますが、言語における主流パラダイム（next-token prediction）や、近年の視覚（ARイメージモデルに倣ったnext-embedding prediction）と共通のインターフェースを持ちません。著者らは、狭いながらも重大な問いを提起しています。すなわち、最もシンプルな因果的目標関数——前のパッチから次のパッチembeddingを予測する——は、音声が本質的に時間的順序を持つという性質を踏まえた上で、競争力のある音声表現を学習するのに十分でしょうか？

手法

NAPE（Next-Audio-Patch-Embedding prediction）は、log-melスペクトログラムに対して因果的Transformerを、2つの要素のみで学習します。すなわち、因果的attention maskingとターゲットへのstop-gradientです。マスキング比率も、ティーチャーネットワークも、contrastive termも、離散化も必要ありません。

NAPEフレームワーク：因果的エンコーダがstop-gradientのもとで次のパッチembeddingを予測する。

パイプライン（Figure 1）は以下の通りです。

  1. パッチ化。 波形は16 kHzにリサンプリングされ、F=128のmelビン、25 msウィンドウ、10 msホップを用いてlog-melスペクトログラム x \in \mathbb{R}^{1 \times F \times T_{\text{frames}}} に変換されます。10秒のクリップの場合、1 \times 128 \times 1008 となります。スペクトログラムは重複なしの P \times P = 16 \times 16 パッチにタイル分割され、クリップあたり N = T_F \cdot T_T = 8 \cdot 63 = 504 トークンが得られます。

  2. パッチembedding f。 各パッチは z_i \in \mathbb{R}^d にマッピングされます。デフォルトはConv2dステムであり、著者らはBNを持つより深いconvステム（convstem）や、melをチャンネルとして扱う音声スタイルの時間方向のみのステム（speechstem）についても検討しています。

  3. 因果的エンコーダ h および予測器 g。 因果的self-attention、LayerScale、QK-normを持つpre-norm Transformerが \{z_1,\dots,z_N\} を入力として受け取ります。軽量な予測器 g がエンコーダの位置 i での出力を \hat{z}_{i+1} にマッピングします。

  4. 目標関数。 学習は、予測と（stop-gradientが適用された）次のパッチembeddingとの間の負のコサイン類似度を最小化します。

\mathcal{L} = \sum_{i=1}^{N-1} \mathcal{D}\!\left(\hat{z}_{i+1},\ \text{sg}(z_{i+1})\right), \quad \mathcal{D}(a,b) = -\frac{a^\top b}{\|a\|\,\|b\|}.

ターゲットは、パッチ i+1 に同じパッチembedding層 f を適用して得られるembeddingです。stop-gradientは、f がすべてのパッチを定数にマッピングするような自明な崩壊を防ぎます。これは、近年のAR視覚研究で用いられているJEPAスタイル／next-embedding定式化の音声版であり、重要な簡略化として、独立したモメンタムティーチャーが不要という点があります——ターゲットエンコーダはsgによって固定された f 自体です。

2Dパッチグリッド上のスキャン順序（time-majorかfrequency-majorかラスタースキャンか）は設計上の選択であり、論文のablationの一つが音声の時間的因果性を最もよく活用する順序を検討しています。time-majorスキャンが自然な選択となります。

データとセットアップ

事前学習はラベルなしのAudioSetを使用します。すなわち、1,964,222のunbalancedクリップ、20,961のbalancedクリップ、加えて18,900クリップの評価分割であり、先行するSSLのセットアップと一致しています。すべての音声はモノラル、16 kHzです。下流タスクの評価には、標準的なAudioSet、ESC-50、音声ベンチマーク（SPC-2、VoxCelebなど）をfine-tuningおよびlinear probingにより使用します。

結果

本論文によれば、NAPEは因果的maskingとstop-gradientのみを使用しながら、複数のスケールにわたってより複雑なSSLベースライン（MAEスタイルのマスクドスペクトログラムモデリング、BEATs、AudioMAE、EAT）に匹敵するか上回る性能を示しています。ablationおよび比較セクションからの主な数値的主張を以下に示します。

  • AudioSet-2Mにおいて、NAPEはAudioSetで事前学習されたモデルの中で最先端のmAPを達成しており、EMAティーチャーを用いたマスク予測よりも厳密にシンプルな目標関数を使用しています。
  • linear probingは強い線形分離性を示しています——学習された特徴はfine-tuningなしに直接利用可能であり、これはマスク再構成エンコーダでは通常見られない性質です。マスク再構成エンコーダの中間特徴は、一般にfull fine-tuningが必要です。
  • スケーリング挙動は単調であり、より大きなエンコーダや長いスケジュールにより継続的にmAPが向上します。これは言語や視覚におけるAR／next-tokenスケーリングの話と整合しています。
  • 畳み込みステムの選択は実質的な影響を持ちます。speechstemバリアントは音声が多い下流タスクに有益であり、一方でデフォルトのConv2dステムは一般的な音声タギングに適しています。

セクション3.6のattentionパターン分析により、因果的headが局所的な時間統合と長距離の調波構造attentionに特化することが示されています。また、学習されたembeddingのt-SNEは、ラベルシグナルなしにクリーンな音響カテゴリ構造を示しています。

限界とオープンな問題

  • 評価はAudioSetスタイルのタギングおよび標準的なSSLベンチマークに集中しており、生成的な下流タスク（音声続き生成、TTS事前学習）における性能は、因果的定式化が本質的に生成的であるにもかかわらず、検討されていません。
  • f へのstop-gradientにより、ターゲット空間は未学習のまま共同学習された浅い射影によって定義されます。分離されたより豊かなターゲット空間（例えば、凍結された事前学習済みトークナイザー）が有効か有害かは解決されていません。
  • 因果的順序は特定の帰納バイアス（time-major）を課します。2D音響構造（周波数方向の倍音）は、frequency-then-timeスキャンにより暗黙的にしか捉えられません。2D因果的スキャンまたは対角スキャンの方が原理的により適切かもしれません。
  • 経験的な下流性能を超えた潜在崩壊の分析は提示されていません。sgのみではSimSiam的なレジームで脆弱になる場合があることが知られています。

なぜ重要か

NAPEは、視覚において現在支配的な「stop-gradientのもとで次のembeddingを予測する」レシピが、現在の音声SSLが依存するマスキング比率チューニング、EMAティーチャー、離散トークナイザーなしに、音声へもクリーンに転用できることを示しています。スケーリングにおいてこれが成立するならば、音声・画像・言語の事前学習を一つの因果予測インターフェースに集約することになります。これにより、マルチモーダル学習が簡素化され、音声エンコーダが自己回帰的生成スタックと直接互換性を持つようになります。

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

EnvHarness: 静的な世界をエージェント学習のために覚醒させる

問題

LLMエージェントの学習パイプラインは、その環境によってボトルネックが生じています。WebShop、SWE-bench、ALFWorldのようなベンチマークは手作業で構築されており、タスク分布、報酬整形、観測空間、検証器はいずれも構築時点で固定されています。これには二つの帰結があります。第一に、環境は現在のポリシーが実際に何を誤っているかを把握できず、失敗モードの重み付けを増やしたり、潜在的なバグを露出させたりすることができません。第二に、ポリシーが改善するにつれて固定タスクプールが飽和し、それ以上のロールアウトから得られるgradient信号が逓減します。環境生成に関する最近の研究（例えば、手続き的タスク合成やLLMによるタスク生成）はこの問題に部分的に対処していますが、各パイプラインはドメイン固有であり、脆弱なLLM判定器による検証か、コストのかかる手書きの検証器のいずれかに依存しています。そして決定的な問題として、生成された環境も一度生成されると再び静的になります。本論文の主張は、環境をゼロから再生成すべきではなく、元の信頼できる検証器をそのまま維持するプログラマブルな適応レイヤーで既存の環境をラップすべきだというものです。

手法

EnvHarnessは、エージェントと環境の間に位置するミドルウェアであり、標準的なreset/step/observeインターフェースを傍受します。これは、観測リライター、行動空間オーグメンター、報酬整形器、タスクサンプラー、前提条件インジェクターといったプラグインコンポーネントの合成であり、各コンポーネントは環境のパブリックAPIに対する純粋な関数です。形式的には、ベース環境が検証器V: \tau \to \{0,1\}を持つ遷移T: \mathcal{S} \times \mathcal{A} \to \mathcal{S}を定義する場合、harness H = (f_o, f_a, f_r, f_\tau)は以下のように再整形されたMDPを生成します。 \tilde{s}_t = f_o(s_t, h_t), \quad \tilde{a}_t = f_a(a_t), \quad \tilde{r}_t = f_r(r_t, s_t, a_t), 一方で、終端検証器は保存されます：\tilde{V}(\tau) = V(\pi_{\text{base}}(\tau))、ここで\pi_{\text{base}}は再整形された軌跡をベース環境の状態・行動空間に射影します。この不変性が重要な設計上の決定であり、再整形されたすべてのロールアウトが元のベンチマークと同じグラウンドトゥルースチェックによってスコアリングされることを意味し、LLM判定器の信頼性問題を回避します。

自動化ループはEnvRiggerです。これは対象ポリシー\pi_\thetaをブラックボックスとして扱い、三つの段階を実行します：(1) 診断 — 現在のharnessでのロールアウトをバッチ収集し、失敗軌跡をクラスタリングし、自然言語による欠陥仮説を生成する（例：「ポリシーがWebShopの在庫制約を無視する」、「ポリシーがネストされたツール呼び出しを要するタスクで失敗する」）；(2) 合成 — コード生成LLMにプロンプトを与え、harness APIに対するPythonプラグインとして表現された、診断された各欠陥を標的とする新しいEnvHarnessコンポーネントを記述させる；(3) 検証 — 候補harnessで新たなロールアウトを実行し、コンポーネントが(a)カナリアセット上で検証器のセマンティクスを保存し、かつ(b)標的とした欠陥における\pi_\thetaの失敗率を閾値以上に増加させる場合にのみ受理する。受理されたコンポーネントは蓄積され、\pi_\thetaが改善するにつれてharnessは徐々により対抗的になります。コンポーネントはコードであるため、検査可能で、合成可能で、ループ内のLLM報酬モデルと比較してロールアウト時のコストが低くなります。

この設計にはいくつか注目すべき特性があります。Vが保存されるため、元のベンチマークに対するオフポリシー評価は引き続き有効です—スコアリングルールに分布シフトはなく、タスク生成分布のみに変化があります。またコンポーネントは加算的であるため、個々のharness要素をアブレーションして性能向上の要因を帰属させることができます。

結果

著者らは四つのドメイン（ウェブナビゲーション、具体化タスク完了、コード・ソフトウェアエンジニアリング、ツール使用）にまたがる五つのベンチマークで評価を行っています。EnvHarnessは元の静的環境および従来のドメイン固有の環境生成パイプラインの両方を上回り、最良の設定では絶対値で最大9.0ポイントの改善を達成しています。改善はドメイン全体にわたって一貫しており、harness抽象化が単一のベンチマーク構造を超えて汎化することを示しています。アブストラクトにはベンチマークごとの数値は記載されていませんが、主要な主張は、単一のドメイン非依存ラッパーが、それぞれに相当なエンジニアリングを要した専用パイプラインに匹敵あるいはそれを凌駕するというものです。

論文のフレーミングから注目すべき二つの副次的観察があります：(i)検証器の保存により、LLM判定器ベースの生成を悩ませる報酬ハッキングの失敗モードが排除される、(ii)EnvRiggerは現在のポリシーに対して診断を行うため、同じベース環境が異なるエージェントに対して異なるharnessを生成する—整形はポリシー条件付きであり、普遍的な難易度カリキュラムではありません。

限界と未解決の問題

アブストラクトには、診断・合成・検証ループの計算コストや、EnvRiggerが合成したコンポーネントが検証段階でどの程度の頻度で棄却されるかは報告されていません—いずれも実用的な採用において重要です。検証器が保存されるという主張は、射影\pi_{\text{base}}が適切に定義されることに依拠していますが、行動のセマンティクスを大幅に変更するharness（例：ベース行動空間に存在しないツールを追加する場合）では、この射影が損失を伴い、不変性の議論が弱まる可能性があります。また、EnvHarnessがオンポリシーRL学習とどのように組み合わさるかも不明確です：ポリシーの更新ごとにharnessがシフトすると、環境が非定常となり、PPO形式のtrust regionと悪い相互作用を生じる可能性があります。最後に、「最大9.0ポイント」という表現は、改善の分布を曖昧なままにしています—この手法が一様に効果的なのか、一部のベンチマークに改善が集中しているのかが不明です。

なぜこれが重要か

EnvHarnessは環境生成を環境適応として再定式化します：新しい世界を構築する代わりに、既存の環境をポリシー条件付きかつ検証器保存型のプラグインでラップします。これは現在のエージェント学習体制において正しい抽象化であり、そこでは信頼できる検証器が希少であり、ポリシーはベンチマークが再構築されるよりも速く進化します。

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

FACET: ターミナルタスク合成におけるソースの意図と実行可能な状態の保持

ターミナルエージェント（コンテナ内で動作するshell/CLI駆動のエージェント）の学習には、実行可能な教師データが必要です。すなわち、指示文は初期化済みの環境、参照ソリューション、そして三者と意味的に一致するベリファイアと対になっていなければなりません。従来の合成パイプラインにおける根本的な失敗パターンは artifact drift です。すなわち、指示文・ソリューション環境・ベリファイアが互いに不整合な前提のもとで独立したLLMの呼び出しから生成されるため、解けないタスク、自明に充足されるタスク、あるいは誤った不変条件を検査するベリファイアで評価されるタスクが生じます。FACETはこの一貫性問題を標的としつつ、タスクが行使しようとするソーススキルの手続き的構造（依存関係・順序・状態遷移）を保持することも目指しています。

問題の定式化

タスクは指示文・環境仕様・参照ソリューション・ベリファイア・ランタイムメタデータにわたるバンドル \mathcal{T}=(\mathcal{I},\mathcal{E},\mathcal{S},\mathcal{V},\mathcal{M}) として定義されます。初期状態 e_0=\operatorname{Init}(\mathcal{E}) とソリューション実行後の状態 e_T=\operatorname{Run}(\mathcal{S},e_0) を与えると、受理条件は次のようになります。

\mathcal{A}(\mathcal{T})=B(\mathcal{E})\land\neg\nu_{\mathcal{V}}(e_0)\land(e_T\neq\bot)\land\nu_{\mathcal{V}}(e_T).

4つの連言項は、従来のパイプラインが混同していた失敗モードに正確に対応しています。(i) 環境が実際にビルドできること、(ii) 初期状態がすでにベリファイアを充足していないこと（そうでなければタスクが自明になる）、(iii) 参照ソリューションがエラーなく実行できること、(iv) ベリファイアがソリューション実行後の状態を受理すること、です。これは厳密な仕様であり、一つのartifactを再生成する合成段階が他の artifact を再検査せずに進めば、受理条件が破られる可能性があります。

パイプライン

FACETは3段階のエージェント型パイプラインであり、コンテナの状態が自然言語記述ではなく共有のグラウンディングとして機能します。

図1: FACETの概要。Stage 1はスキルを収集し、シナリオ–スキルリポジトリを構築する。Stage 2は選択されたスキルを理解し、統合シナリオを探索・復元し、完全な表現へと展開し、整合した参照ソリューションと指示文を構築する。Stage 3は環境を構築・検証してから最終的なタスクartifactを生成し、有界な修復ループを持つ。

Stage 1は関連するソーススキルの集合 X=\{x_1,\ldots,x_m\} からシナリオ–スキルリポジトリを構築します。Stage 2は整合性のある部分集合を選択し、ソースに含まれる目標・依存関係・状態遷移を保持した統合シナリオを復元し、環境が存在する前に整合した指示文とソリューションの 参照 を生成します。Stage 3は環境 \mathcal{E} を実体化し、B(\mathcal{E}) によって検証した後、具体的な初期化後の状態 e_0 に基づいて \mathcal{I}、\mathcal{S}、\mathcal{V} を生成します。有界な修復ループは、受理検査で失敗したartifactだけを修正します。合成全体を再起動するのではなく失敗したコンポーネントのみを再生成するこの仕組みが、連鎖的な再生成によって既に有効なartifactが破壊されることを防ぐ鍵となるメカニズムです。

ここで重要な設計判断は、指示文・ソリューション・ベリファイアがお互いのテキスト仕様ではなく、実行済みの 環境状態を条件としている点です。具体的には、\mathcal{V} は e_T 上の観測可能なファイルシステム・プロセス・ネットワーク述語に対して記述され、\mathcal{S} は実際に最後まで実行することで検証されます。e_0 と e_T が共有のグラウンディングであるため、各artifactがコンテナに対して検査される限り、三者が意味的にドリフトすることはありません。

スキルカバレッジとタスク分布

保持されたスキルコーパスは5つのトップレベルファミリーと34の細粒度カテゴリにわたり、受理述語を通過した6,078件のタスクが9つのタスクファミリーに分布し、ファミリーごとの割合は9.59%から11.99%の範囲に収まっています。ほぼ均一な分布であることは、パイプラインが容易なスキルの組み合わせに集約されていないことを示唆しています。

図3: スキルとタスクの分布。

実験設定とトラジェクトリの統計

ロールアウトは、DeepSeek-V4-Proによって駆動されたTerminus-2が約6Kの検証済みタスクに対して生成します。その中から1.2Kの完全な成功トラジェクトリを選択し、LLaMA-Factoryを用いてQwen3.5-4B/9B/27BのSFTに使用します。トラジェクトリデータはタスク品質に関する情報を含んでいます。成功した教師トラジェクトリは、アシスタントターンの状態間で明確な遷移パターンを持つ構造化されたshell使用を示しています。

図5: 成功した教師トラジェクトリにおける、コマンド頻度と隣接するアシスタントターン状態間の行正規化遷移行列。

遷移行列が非自明かつ非退化であることは、タスクが単一コマンドによる解法ではなく多段階の手続き的実行を必要とすることを示しており、ソーススキルから依存関係と状態遷移を保持するという意図と一致しています。

限界と未解決の問題

この論文の抜粋では、fine-tuningされたQwenモデルのベースラインに対するエンドタスク成功率、および (a) 共有状態グラウンディング vs. (b) 有界修復 vs. (c) スキル–シナリオ復元、それぞれの寄与を切り分けるアブレーションは報告されていません。受理述語 \mathcal{A}(\mathcal{T}) は ある ソリューションと ある ベリファイアが合意することを保証しますが、\mathcal{V} が厳密であることは保証しません。多くの非ソリューション状態を受理する緩いベリファイアは、式(2)を依然として満たしてしまいます。修復ループがLLMにとってパッチしやすいartifactに向けてタスク分布を偏らせるかどうかも未検討です。さらに、教師（DeepSeek-V4-Pro）の成功バーが6Kタスクから1.2KのSFTセットを絞り込んでいるため、下流のモデルは教師がすでに解ける約20%のタスクのみで学習されることになり、より難しいテールは破棄されます。

この研究が重要な理由

実行可能でベリファイアによって採点されるターミナルタスクは、エージェントのRLと評価における自然な基盤ですが、指示文・ソリューション・ベリファイアが相互に不整合であればその価値は失われます。FACETの貢献は実践的なものです。コンテナの初期化後状態を唯一の信頼源とし、artifactを個別に修復することで、合成を明確な受理述語を持つ検証可能な手続きに変換します。これは、手動で作成されたベンチマークを超えてエージェントの学習データをスケールさせるための前提条件です。

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

SWE-bench Science: コーディングエージェントは科学分野のエンジニアリングタスクを解決できるか？

問題設定

標準的なコードエージェントベンチマーク（SWE-bench、SWE-bench Verified、SWE-bench Multilingual）は、人気の汎用リポジトリ（Webフレームワーク、開発者ツール、データサイエンスライブラリ）からサンプリングされており、その難易度はAPI操作、テストの分離、局所的なバグ修正が中心となっています。科学ソフトウェアは異なる種類の失敗パターンを持ちます。すなわち、正確性はドメインのセマンティクス（単位、座標系、保存則、境界条件、数値的安定性）と密接に絡み合っており、構文的にクリーンなパッチが下流の結果をサイレントに無効化してしまう可能性があります。ソフトウェアがますます「科学的計測器そのもの」となっている今日、検出されないリグレッションは公開された結論にまで伝播してしまいます。汎用ベンチマークのaggregate pass@1スコアは、エージェントがドメインの内容について推論できるかどうかを示す指標を何ら提供しません。

SWE-bench Scienceはこのギャップを標的としています。20の科学ドメイン（天体物理学、バイオインフォマティクス、計算化学、気候モデリング、PDEソルバー等）にまたがる98のGitHubプロジェクトから119のリポジトリレベルタスクをキュレーションしており、各タスクには、単なるインターフェースへの適合性ではなく科学的正確性の基準をエンコードした実行可能なテストが付与されています。

タスクの構成

タスクは、科学エンジニアリングの異なるワークフローを反映した3つのパラダイムに分類されています。

  • Issue-driven（課題駆動型）: メンテナーまたはユーザーから報告された欠陥（数値誤差、物理的に誤った結果、誤った境界処理）。標準的なSWE-benchに近い形ですが、正解パッチを正当化するためにドメインの推論が必要です。
  • Expert-exploratory（専門家探索型）: 「バグ」がモデリング上の欠陥である研究スタイルの問題から派生したタスク（例：支配方程式の欠落した項、誤った離散化、テストされた範囲外で破綻する仮定）。エージェントはバグを局所化するのではなく修正を合成しなければなりません。
  • Engineering-integration（エンジニアリング統合型）: 科学コンポーネントを周囲のインフラ（I/Oフォーマット、ソルバー結合、パイプラインステージ）に結びつける複数ファイルにわたる変更。モジュール間の一貫性が問われます。

各インスタンスには、リポジトリのスナップショット、自然言語による問題説明、および報告された症状と隣接する科学的不変条件の両方を検査するhidden test suiteが付属しています（報告されたケースにoverFitする表面的なパッチにペナルティを与えるため）。

結果

評価は、最先端モデルと組み合わせた現在のエージェントスタック（Claude Code、OpenHands、Aiderの各バリアント）を対象としています。最良の構成であるClaude Code with Opus-5（最大バジェット）でも、pass@1は50%未満にとどまっています。より弱い構成では大幅に低下し、パラダイム間のギャップも体系的です。Issue-drivenタスクが最も解きやすく、Expert-exploratoryが最も難しく、Engineering-integrationがその中間に位置します。この順序は、暗黙的な科学的文脈の必要量を反映しています。報告された症状の修正は範囲が限定されていますが、探索的なタスクでは意図された物理・数学をエージェントが再構築することが求められます。

著者らは、プロンプトから明示的な科学的文脈を除去するpaired ablation（コードレベルの失敗説明のみを保持）を実施しました。Expert-exploratoryおよびEngineering-integrationではパフォーマンスが顕著に低下しましたが、Issue-drivenではほぼ変化なしという結果が得られました。これは、現在のエージェントはターゲットが明確に指定されている場合にはバグを局所化してパッチを適用できる一方、コードベースのみからドメイン制約を導出することは安定してできないことを示しています。

失敗の分類

失敗したトラジェクトリの手動分析から、4つの繰り返されるメカニズムが明らかになっています。

  1. 科学的知識・抽象化の欠如。 エージェントが単位の慣習、座標変換、または不変条件（例：エネルギー保存、エルミート性）を見落とします。パッチはコンパイルされ報告されたケースをパスしますが、他の場所でテストされている物理法則に違反します。
  2. 誤った探索・表面的な修正。 エージェントが症状に隣接した行に着目し、局所的な修正（クランプ、イプシロン、例外の握り潰し）を適用して、根本的な方程式やアルゴリズムに問題があるかどうかを探索せずに終了します。
  3. 修正範囲の不完全性・統合の欠如。 呼び出し元での変更は正しいが、兄弟のコードパス、別のソルバー、またはシリアライゼーション層が古い動作を保持しています。Engineering-integrationタスクに多く見られます。
  4. 一般化の失敗。 パッチは観測された特定の入力には有効ですが、ドメインによって示唆される自然なパラメータ範囲には適用されません（例：低レイノルズ数では正しく高レイノルズ数では失敗する、2Dでは正しく3Dでは誤り）。隣接したレジームを探索するテストがこれを検出します。

これらのモードは標準的なSWE-benchの失敗（局所化エラー、過剰パッチ）と直交するものではありませんが、カテゴリ1と4は質的に新しいものです。これらはエージェントが根底にある科学のモデルを保持し、見えているテストだけでなく、そのモデルに照らしてパッチを検証することを要求します。

制限事項とオープンな問題

このベンチマークは、科学計算の多様性に対して小規模（119タスク）であり、20のドメイン間でのカバレッジは不均一です。テストスイートは不変条件を探索するように設計されていますが、科学的正確性に対する有限のproxyにとどまっており、原理的にはエージェントがオーバーフィットする可能性があります。パラダイムのラベルはキュレーターによって割り当てられており、Expert-exploratoryとEngineering-integrationの境界は曖昧です。オープンな問題としては、ドメイン文献（論文、教科書）のretrieval augmentationがablationのギャップを縮めるかどうか、シンボリックソルバー、単位チェッカー、またはproperty-based testingによるツール拡張が失敗分布を変えるかどうか、そしてパッチが科学的には正しいが無関係なインターフェースを壊す場合の部分点の採点方法、などがあります。

重要性

リポジトリレベルの科学タスクにおける最強エージェントでさえpass@1が50%未満であること、および明示的なドメインコンテキストへの感度が実証されたことは、特定の能力ギャップを定量化しています。すなわち、現在のコーディングエージェントはコードを修正できますが、そのコードがエンコードしている科学について安定して推論することはできません。これこそがサイレントな失敗が最も重大な領域であり、表面的な修正のみを評価するベンチマークではそれが隠蔽されてしまいます。

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

SkillEvo: マルチターンインタラクションフィードバックによる自己更新型進化 Gradient

問題

エージェントの「Skill」——ベースLLMをタスクに特化させるprompt・知識アーティファクト——は、通常、人手で作成されるか、単一の生成パスで生成されます。近年の自己改善パイプラインは、評価器がSkillの出力をスコアリングし、欠陥を修正ステップにフィードバックすることでループを閉じています。実際には、これらのループはシングルターンのQA評価に依存しており、顕著な非対称性を生じさせます。すなわち、最初の修正ラウンドで単一の対話が露わにできる全てがパッチされ、その後gradient が平坦化します。マルチターン対話をまたいで初めて現れる欠陥（ユーザーの未明示の制約、感情に起因するエスカレーション、ツールのシーケンシング、参照のドリフト）は決して表面化せず、Skill自体がまだ欠陥を持っているにもかかわらず進化が停滞します。これらのシステムのガバナンスも粗雑であり、エンドツーエンドのpass/failゲートは不良な候補を棄却できても、劣化の構造的原因（肥大化、参照の破綻、過度に一般化された事実）を局在化することができません。

SkillEvoの主張は、持続的なSkill進化を制約する真の要因は編集器の能力でもイテレーション回数でもなく、評価が信頼できるgradientを生成し続けるかどうかにある、というものです。本論文は、マルチターンのユーザーシミュレーションを評価エンドポイントからフィードバック生成器へと再定式化し、独立した構造ガバナーと組み合わせます。

手法

U をタスク制約付きUser Agent、S_t をラウンド t におけるSkill、\pi(S_t) を S_t を読み込んだサービスエージェントとします。SkillEvoは以下の閉じたループを実行します。

\text{Scenario Synthesizer}\to\text{UserAgent}\to\text{Verifier}\to\text{Collective Attribution}\to\text{Skill Optimizer}\to\text{Skill Governor}.

  1. Scenario Synthesizer。 実際に人間が対応した各チケットは、intent agenda、behavior facts、emotion trajectory、human reference solution の4つのフィールドに分解され、これらが合わさって1つの評価タスクを定義します。この構造化された抽出により、User Agentの挙動がラウンドをまたいで再現可能かつ制約可能になります。また、シミュレーターがSkillがすでに解決済みのシナリオへとドリフトすることを防ぎます。

  2. User Agent。 U は \pi(S_t) と複数のターンにわたって対話し、軌跡 \tau_t = \operatorname{Interact}(U, \pi(S_t)) を生成します。U はintent/behavior/emotionフィールドに束縛されているため、マルチターンの対話は解決されるか決定的に失敗するまで、同じ潜在的なギャップを繰り返し探索し続けます。

  3. Verifier。 軌跡はhuman reference solutionに対してスコアリングされます：(r_t, f_t) = \operatorname{Verify}(\tau_t)、ここで r_t \in \{\text{Success}, \text{Failure}\} であり、f_t は失敗原因および \tau_t からの支持する根拠スパンを含みます。判定を定義する2つの評価基準があります（Appendix B）。Verifierは厳格な Generator \ne Evaluator 制約の下で動作します——これはフレームワークの唯一のアーキテクチャ上の要件です。

  4. Collective Attribution。 失敗は修復可能性によって a_t \in \{\text{Knowledge Gap},\ \text{Capability Limit},\ \text{Evaluation Noise}\} にトリアージされます。評価loss \mathcal{L}_t に投影されるのは Knowledge Gap の失敗のみです。Capability limitの失敗（いかなるSkill編集でも修正不可能）とEvaluation noise（Verifierの誤検知）は除外されます。これが進化gradientを信頼可能に保つメカニズムです。ノイズや対処不可能なシグナルはアップデートに入り込みません。

  5. Skill Optimizer。 有界アップデート

S_{t+1} = \operatorname{Update}(S_t, \mathcal{L}_t, S_0)

は2つの意味で有界です。evidence boundary は \mathcal{L}_t で明示的に検証されたギャップにのみ編集を制限し、根拠のないコンテンツの導入を禁止します。reference boundary は改訂を本番ベースライン S_0 に固定し、新しいパッチが安定した既存の事実を暗黙のうちに上書きすることを防ぎます。挿入、精緻化、再編成をそれぞれ担う3つの編集器モードがあります（Appendix B）。

  1. Skill Governor。 独立した改訂後レイヤーが構造的劣化——knowledge bloat、reference breakage、factual over-generalization——を検出し、修復推奨を出力します。これらはラウンド t+1 のattributionシグナルと統合されるため、構造的クリーンアップと知識補完は競合する目的としてではなく、並行して行われます。

この2段階ループ（上層のattribution駆動のコンテンツアップデートと、下層のガバナンス駆動の構造アップデート）を、本論文では gradient と direction の分離と呼んでいます。信頼できるフィードバックがgradientを提供し、制御可能なガバナンスがその方向性を制約します。

実験

評価はTencent Cloudの本番テクニカルサポートチケットで行われます。6つのクラウドサービスカテゴリ、9つの本番Skill、98のskill参照ファイルを使用します。データセット内の全チケットは人間のエージェントにエスカレーションされたもので、約40%は即座に、60%は未解決のラウンドの後にエスカレーションされています。そのため、このコーパスは構造的に現在デプロイされているSkillの失敗セットとなっています。チケットはSkillごとに時系列順に並べられ、4等分されます。最初の3分割がシナリオ合成、シミュレーション、attribution、修正を駆動する開発セットを形成し、4番目は純粋に測定用のheld-outセットです。報告される全Task Success Rate（TSR）はheld-outの4分の1から得られます。バージョン選択には開発の4分の1のみを使用するため、評価セットの情報が最適化に漏れることはありません。

abstractと手法のセクションでは、結果を定性的に説明しています——持続的なgradient、ラウンドをまたいで減衰しない進化、ガバナーによって保たれる構造的整合性——しかし提供された抜粋には数値的なTSRテーブルは含まれていません（それらはSection 4.1以降の本文にあります）。データセット自体はユーザーのプライバシーおよび商業上の機密性の制約からリリースできないと再現性に関する記述で明示されていますが、マルチターンのログとhuman reference solutionが存在するところであればどこでも手法はデータセット非依存です。

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

2つの限界が直接述べられています。第一に、チケットソースは独自のものでリリース不可であるため、外部検証はreference solutionを持つマルチターンの相談の代替コーパスで行う必要があります。第二に、モデルに関する唯一の厳格な要件はGenerator \ne Evaluatorであり、異なるファミリーの任意の2つのモデルで十分なはずですが、そのペアリングに対する感度は論文では特性評価されていません。このフレームワークが提起するオープンクエスチョンとして、Capability Limit が支配的なときに3方向attributionがどのように振る舞うか（システムが失敗しているにもかかわらずgradientがゼロに縮退する）、Skill Governorが構造修復と知識挿入が競合する編集を生成したときどのように調停するか、そして S_0 への有界アップデートのアンカーが最終的に到達可能なSkill品質を制約なしの書き直しで達成できるものより下に上限付けしてしまうかどうかが挙げられます。

なぜ重要か

ほとんどの自己改善型エージェントパイプラインは、シングルターン評価が最初のパッチ後に自身のシグナルを使い果たすため、密かにプラトーに達します。SkillEvoは実際のボトルネック——進化gradientの信頼性——を特定し、イテレーションや編集器の規模を拡大するのではなく、マルチターンのシミュレートされたフィードバックと修復可能性に基づくattributionでそれに対処します。このフレーミングは、アーティファクトがLLM由来の批評に対して進化させられる任意の閉ループシステムに一般化できる可能性が高いです。

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

Repo0: 設計駆動のゼロ-to-オール・コード生成

問題

リポジトリレベルのコード生成ベンチマークは、通常、エージェントにあらかじめ定義されたアーキテクチャ（ファイルレイアウト、モジュール境界、多くの場合は関数シグネチャ）を与えます（Commit0、NL2Repo-Bench）。より難しい「ゼロ-to-オール」設定では、自然言語の要件からプロジェクト全体を合成する必要があり、エージェントは機能とアーキテクチャを同時に推論しなければなりません。RPGのような既存のグラフベースのプランナーは、設計をコーディング前に一度だけ生成する成果物として扱いますが、実装が進むにつれて凝集度・結合度の問題が明らかになると、静的な設計図は責任の重複、依存関係の絡み合い、未実現の要件を蓄積しがちです。

図1：従来の手法がグラフを固定された計画成果物として扱うのに対し、Repo0は生成中にリポジトリアーキテクチャを継続的に進化させます。

Repo0はゼロ-to-オール生成を継続的な構造進化問題として再定式化します。すなわち、アーキテクチャはモジュール性メトリクスのもとで収束するまで洗練される可変状態であり、その後にテスト駆動のコード生成が進むというものです。

手法

ステップ t における永続的なアーキテクチャ状態は、Dual-DAGとアライメントの組として表されます。

S_t = (G_t^R, G_t^C, \mathcal{A}_t)

  • G_t^R = (V_t^R, E_t^R)：要件レベルのDAG。ノードは（サブ）要件、辺 (u,v) は機能的共同利用を表します。つまり、一貫したI/Oと動作のために、二つの要件を合わせて推論する必要があることを意味します。辺は明示的に実装上の依存関係を表すものではありません。
  • G_t^C = (V_t^C, E_t^C)：コンポーネントレベルのDAG。ノードは有界な実装単位（モジュール、アダプタ、パーサ、サービス層）、辺は継承・再利用・包含関係をエンコードします。
  • \mathcal{A}_t \subseteq V_t^R \times V_t^C：多対多のトレーサビリティ関係。(q,c)\in\mathcal{A}_t は、コンポーネント c が要件 q の一部を実現することを意味します。

要件の共同利用と実装上の依存関係を分離することが、モデリングの核心的な選択です。これにより、機能的な協調のための辺が具体的なコードレベルの依存関係と混同されることを防ぎます。これは単一グラフのプランナーが境界を曖昧にしがちな点です。

図2：継続的な意思決定駆動の構造進化フレームワークの概要。

パイプラインは三つのフェーズで動作します。まず、自然言語プロンプトを要件ノードに分解し、初期コンポーネント集合を設定してそれらを整合させることで、初期状態 S_0 が構築されます。

図3：初期アーキテクチャ状態の構築の例示。

次に、構造進化がモジュール性メトリクス（コンポーネントDAG上の凝集度・結合度の代理指標）を用いて G_t^C を反復処理し、構造的なアクションを提案します。具体的には、凝集度の低いコンポーネントの分割、冗長なコンポーネントのマージ、あるいはグラフのトポロジーを変えずに責任の記述とインターフェースの前提を書き直す境界保持型の改訂です。LLMはその後、選択されたアクションを実体化し、コンポーネント、アライメントエントリ \mathcal{A}_t、インターフェースを書き直します。モジュール性メトリクスが改善しなくなるまで（構造的収束）、反復が続きます。第三フェーズでは、固定されたアーキテクチャがTDDスタイルのコード生成を駆動します。テストは要件ノードから合成され、コードは依存関係の順にコンポーネントごとに生成され、検証の失敗は固定アーキテクチャ内での局所的な修復をトリガーします（境界保持型の改訂が必要な場合を除き、さらなる構造的変更は行いません）。

モジュール性メトリクスがLLMが書き換えにコミットする前に候補となるアクションをフィルタリングするため、本フレームワークは「どの構造的な操作を行うか」（メトリクス駆動）と「それをどう実体化するか」（LLM駆動）を切り離すことができます。

結果

評価はGPT-5 miniとDeepSeek V3.2をバックボーンとして、6つのRepoCraftリポジトリで行われています。ベースライン：mini-SWE-agent、Paper2Code、RPG（最も強力なリポジトリ計画ベースライン）。

GPT-5 miniのもとで、Repo0は3つの主要リポジトリすべてで最高のFunctionality Coverageを達成しています：requestsで100.00%、statsmodelsで80.68%、djangoで80.50%。RPGに対するPass Rateの改善は大幅で、requestsで+19.47、statsmodelsで+7.61、djangoで+27.03です。Voting Rateは全6設定（2バックボーン×3リポジトリ）で最高です。DeepSeek V3.2でも同様の順序が見られ、評価対象の全リポジトリでcoverageが最高となっています。

コスト面では、DeepSeek V3.2において、Repo0の生成コストはrequests / statsmodels / djangoでそれぞれ$11.95 / $28.19 / $27.24、総コストは$21.28 / $41.12 / $100.06（djangoでは評価が$72.82と支配的）です。RPGと比較すると、Repo0はrequests（生成コスト−$9.32）とstatsmodels（−$35.59）では安価ですが、djangoではわずかに高価（生成コスト+$8.83）です。GPT-5 miniのもとでは、Repo0の生成コストは全リポジトリで低くなっています。論文では、凝集度が高く結合度が低いことでコンポーネント間の競合が減り、繰り返しの修復がトリガーされにくくなるため、TDD修復の反復回数が減少してコスト削減につながると説明しています。

補足的なベースラインの弱点も示唆的です。mini-SWE-agentはスケールが大きくなるとリポジトリ全体の一貫性を失います（大きなリポジトリではPass Rateが崩壊）。Paper2Codeは高いFunctionality Noveltyを生成しますが、それが正確性に結びつきません。これは、もっともらしいが整合していないコンポーネントを生成するプランナーに一致した結果です。

限界と今後の課題

  • 構造的な更新は最終的にバックボーンLLMのアーキテクチャ推論に依存します。モジュール性メトリクスは分割・マージの候補を選択するだけであり、LLMが境界を書き直すため、モデルが弱い場合は不整合な改訂を提案する可能性があります。反復ループと改訂アクションによって部分的に緩和されますが、必要な進化ラウンド数の上界は特定されていません。
  • 評価はRepoCraftの6つのPythonリポジトリに限定されています。コンポーネントDAG上で定義されたモジュール性メトリクスが、異なるモジュール性の慣習を持つ言語エコシステム（GoマイクロサービスやRustのcrate、JSバンドラなど）に転用できるかは検証されていません。
  • 論文ではDual-DAG分離そのもの（すなわち G^R と G^C を統合した場合）のablationが報告されていないため、機能的共同利用と実装上の依存関係を分離することの限界価値は、示された抜粋から直接測定されたものではなく推論されたものです。
  • 構造的収束はモジュール性メトリクスによって宣言されますが、使用される特定の凝集度・結合度の代理指標の定義とその感度についてはここでは詳述されていません。

なぜ重要か

ゼロ-to-オールのリポジトリ生成は、関数レベルおよびリポジトリ補完のベンチマークが隠しているボトルネックを露わにします。すなわち、アーキテクチャ設計はコーディングへの一度限りの前置きではなく、証拠が蓄積されるにつれて改訂されなければならない状態であるということです。Repo0の数値、特にdjangoにおける+27ポイントのPass Rate向上は、メトリクスガイドによる構造的書き換えが、一枚岩的な計画や制約のないマルチエージェントのロールプレイよりも、長期的なSWEエージェントにとってより扱いやすいプリミティブであることを示唆しています。

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

Hacker News Signals

DiffusionGemma テクニカルレポート

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

DiffusionGemmaは、マスク拡散言語モデリングのパラダイムをGemmaアーキテクチャファミリーに適用し、テキスト生成ベンチマークにおいて自己回帰ベースラインと競合する離散拡散LMを実現します。中心となるメカニズムはマスク拡散です。学習時には、トークンが確率 t \in [0,1] で独立に [MASK] トークンへと破損され、モデルはクロスエントロピー目的関数によってすべてのマスク位置を同時に予測するように学習されます。推論時には、完全にマスクされたシーケンスから生成を開始し、T ステップにわたって反復的にデノイズを行います。これにより、自己回帰デコードには不可能な並列性が実現されます。

テクニカルレポートでは、いくつかのアーキテクチャ上の設計判断が詳述されています。スクラッチから学習するのではなく、事前学習済みのGemmaチェックポイントから初期化する手法が採用されており、因果的 attention マスクを双方向 attention に変換する手順が用いられています。これは、拡散LMがマスクされたトークンをデノイズするために左右両方のコンテキストに attend する必要があるためです。因果マスクを単純に除去して、マスク拡散目的関数で fine-tuning するだけで事前学習済みの重みを適応させるのに十分であることが示されており、これによりスクラッチからの学習と比べて計算コストが大幅に削減されます。

標準的なベンチマーク（HellaSwag、ARC、MMLU、テキスト生成パープレキシティ）において、2Bおよび9Bパラメータスケールで学習されたDiffusionGemmaモデルは、同等のパラメータ数を持つ自己回帰型Gemmaに近い性能を示すものの、一様には一致しません。ただし、スケールが大きくなるにつれてそのギャップは縮小します。固定されたデノイズステップ数のもとでの生成品質は、制約なしのデコードと比較して低下しますが、これは離散拡散における標準的なトレードオフです。サンプリング品質は、スループットを犠牲にすることでデノイズステップ数を増やすほど向上します。

テキストに対する最適なノイズスケジュール、可変長生成の扱い（拡散は本質的に固定長シーケンスで動作します）、そしてレイテンシが重要な設定において双方向 attention の利点がステップ数コストを上回るかどうかについては、未解決の問題が残っています。本研究は、大規模な事前学習済み自己回帰モデルを完全な再学習なしに拡散目的関数に適応させられることを実証した点で重要であり、スケールでの離散拡散の研究に対する参入障壁を低下させるものです。

中間トークンを推論・思考トレースとして擬人化することを止めよ（2025年）

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

本論文は、方法論的に鋭い主張を展開しています。すなわち、chain-of-thoughtや「思考」モデルが生成する中間トークン列を、モデルの内部推論プロセスの忠実な表現として解釈すべきではなく、そのような解釈は科学的・工学的に誤った結論をもたらすという主張です。

中心的な技術的主張は、中間トークンと最終回答の正確性との関係が、推論トレースの物語が示唆するような因果的なものではないというものです。著者らは以下の証拠を提示しています。（1）scratchpadトークンが大幅に破損されたり無関係な内容に置き換えられたりしても、最終回答の品質が比例して低下しないことから、トークンが実際の計算経路を符号化していないことが示唆される。（2）モデルは、「推論」が実際には前の層によって既に暗黙的に決定された回答と整合するように事後的に生成された合理化であっても、構文的に整合した推論トレースを生成する。（3）トレースが中間ステップを「正しく」記述しているかどうかを判定するfidelityメトリクスは、機構的な対応関係ではなく表面的なもっともらしさを測定しているに過ぎない。

interpretabilityの観点から見ると、これは重要な問題です。複数の研究の流れが、chain-of-thoughtトレースをモデル内部のプロキシとして利用しているからです。例えば、トレースの長さや内容を「モデルがどれだけ考えているか」のプロキシとして使用するといった手法がそれに当たります。もしトレースが、真の計算中間体ではなく、人間が書いた解答の学習分布によって形成された装飾的な出力に過ぎないとすれば、こうしたプロキシは無効です。

RLVRとprocess reward modelへの実践的な含意は重大です。process reward modelが中間トークンを推論ステップとしてスコアリングするよう学習されており、かつそれらのトークンが解答の正確性と因果的に連結していないとすれば、reward signalの仕様が誤っていることになります。本論文は中間トークンが完全に無用であると主張しているわけではなく、後続トークンの生成を通じてresidual streamに影響を与えることは認めています。しかし、機構的な解釈には機構的な証拠が必要であり、表面的なもっともらしさでは不十分であると主張しています。

本論文の限界は、議論が部分的に否定的なものであり、中間トークンが計算的に何をしているのかを十分に特徴付けていない点です。それは依然として、mechanistic interpretabilityにおける未解決の問いとして残されています。

DFlash 2: 並列ドラフトの継続

Source: https://inco.ai/blog/dflash2

DFlash 2は、複数ドラフト並列シナリオにおけるスループットを目標とした最適化済みのspeculative decodingカーネルであり、バッチスケールでのspeculative decodingのボトルネックがドラフト受理ロジックではなく、複数の同時ドラフトシーケンスにまたがるattention計算にあるという観察に基づいて構築されています。

標準的なspeculative decodingは、小さなモデルで k 個のドラフトトークンを実行し、ツリー構造のattentionマスク上での単一のforward passによってターゲットモデルで検証します。この検証passは、フラットなシーケンスではなくトークンツリーに対してattentionを行うため、分岐構造を効率的に処理するカスタムattentionカーネルが必要となります。DFlash 2の貢献は、完全な O(n^2) のattention行列をマテリアライズすることなくツリー構造のflash attentionを実行するfused CUDAカーネルであり、分岐マスクの計算をSRAM内に保持してグローバルメモリのラウンドトリップを回避します。

核心的なアルゴリズム上の洞察は、ツリー構造のattentionが共有プレフィックス計算を伴う独立したパスレベルのattentionに分解できるという点です。共通プレフィックス上のトークンは一度だけattentionが計算され、分岐した各ブランチはプレフィックスKVキャッシュを再利用し、同一のカーネル起動内でブランチローカルのattentionを並列に計算します。これにより、ドラフトブランチごとに個別のカーネル呼び出しが発生するオーバーヘッドを回避でき、小さいバッチサイズでは演算コストよりもそのオーバーヘッドの方が支配的となります。

ベンチマークでは、H100ハードウェア上でドラフト幅4〜16トークンにおける検証ステップのレイテンシに意味のある改善が報告されており、典型的なspeculative decodingの構成において、素朴なtree-attentionの実装と比較して1.3〜1.8倍の範囲でスループットが向上しています。この改善は、ツリー構造がより不規則になる大きなドラフト幅においてより顕著です。

未解決のエンジニアリング上の問題は、これがcontinuous batchingとどのように相互作用するかという点です。バッチ内の異なるシーケンスはドラフト長やツリー形状が異なるため、スケジューリングのオーバーヘッドを追加する動的なカーネル構成が必要となります。このブログでは、これはパディング戦略によって処理されると述べられていますが、その結果として一部の非効率性が再び生じます。

悪意のあるRustクレート「Arrayref」がビルド時ペイロードを実行

Source: https://safedep.io/arrayref-proc-macro1-rust-build-time-malware

これは、Rustのbuild.rsメカニズムおよびprocedural macroを悪用してビルド時に任意のコードを実行する悪意のあるクレートを介した、Rustエコシステムを標的としたサプライチェーン攻撃です。

技術的な攻撃ベクターはシンプルながらも効果的です。Rustのビルドシステムでは、クレートにbuild.rsスクリプトを同梱することができ、このスクリプトはコンパイル中に開発者またはCIマシン上で実行されます――コンパイル済み成果物に対する人間によるレビューよりも前に実行される点が重要です。攻撃者はarrayrefという名前のクレート（正規のarrayrefクレートのtyposquattingまたはnamesquatting）を公開し、難読化されたペイロードを含むbuild.rsを組み込みました。このペイロードはリモートバイナリをフェッチして実行するため、当該依存関係を含む状態でcargo buildを実行したあらゆるマシン上で任意コード実行が可能となります。

二次的な攻撃ベクターはprocedural macroでした。RustにおけるProc macroはチューリング完全なプログラムであり、コンパイル時にコンパイラプロセス内部でホストのファイルシステムおよびネットワークへの完全なアクセス権を持った状態で実行されます。この悪意のあるクレートはproc macroを使用して、コンパイル中に環境変数（AWS_SECRET_ACCESS_KEYやGITHUB_TOKENなど、機密情報を含むことが多い）を外部に送出していました。

これはRustのビルドモデルが持つ根本的な性質を浮き彫りにしています。すなわち、cargo buildは信頼されていない依存関係に対して安全な操作ではないということです。コードを実行前に検査できるインタープリタ型言語とは異なり、cargo buildはビルドパイプラインの一級要素としてホスト上でRustコードを実行します。--no-default-featuresフラグやcargo-sandboxのようなサンドボックスツールはこのリスクをある程度軽減しますが、いずれもデフォルトの動作ではありません。

Safedepの分析によれば、このクレートはcrates.io上に相当期間にわたって公開されていたことが判明しました。検出のきっかけは、build.rsの内容を静的解析してネットワーク呼び出しにフラグを立てたことです。この事例は、CIパイプラインにおけるクレート監査ツール（cargo-audit、cargo-vet）の必要性、およびbuild.rsにおけるアウトバウンドネットワークsyscallに対するcrates.ioの自動スキャンの強化という課題を改めて示しています。

Apple Silicon 上で Linux MicroVM スタックを再構築した話

Source: https://encore.dev/blog/firecracker-apple-silicon

本記事では、Apple Silicon Mac 上で Firecracker microVM を動作させるためのエンジニアリング作業を詳述しています。Firecracker は x86/ARM Linux 上の KVM を前提として設計されており、Apple Silicon 上の macOS は異なるハイパーバイザーインターフェースを公開しているため、これは容易な問題ではありません。

中心的な技術的障壁は、Apple Silicon Mac が KVM ではなく macOS Hypervisor framework（Hypervisor.framework）を使用している点です。Firecracker の VMM は、vCPU 管理・メモリマッピング・割り込み配送のために KVM の ioctl と密接に結合しています。チームはこの KVM バックエンドを Hypervisor.framework 上に構築したものに置き換えました。この framework は類似しているものの異なる API を公開しており、特に Apple の framework にはカーネル内 irqchip エミュレーションのような一部の KVM 機能が欠けているため、ユーザー空間での割り込みコントローラーエミュレーションが必要になりました。

第二の問題はアーキテクチャです。Apple Silicon は AArch64 ですが、ARM 上の Firecracker は Linux 上の AWS Graviton でほぼ専ら検証されていました。GIC（Generic Interrupt Controller）のエミュレーションパスは KVM/Linux と macOS で異なり、Linux ゲストカーネルが CPU ホットプラグやシャットダウンに使用する PSCI（Power State Coordination Interface）呼び出しについても VMM 内での再実装が必要でした。

メモリハンドリングも異なります。Linux 上では、Firecracker は memfd と mmap を KVM_SET_USER_MEMORY_REGION と組み合わせて使用します。macOS での相当物は hv_vm_map ですが、これはアラインメント要件が異なり、Firecracker がスナップショット・リストアに使用するダーティページ追跡機能のすべてをサポートしているわけではありません。

その結果、M シリーズハードウェア上で Firecracker と互換性のある microVM 環境が動作するようになり、サーバーレスワークロードに Firecracker を魅力的なものとしている高速ブート時間（125ms 以下）とメモリ分離が実現されています。主な残存制限は、スナップショット・リストアの忠実性と、ハードウェアアクセラレーションによるネステッド仮想化の欠如であり、これを必要とするワークロードに制約をもたらしています。

Taffy: 柔軟で高性能なクロスプラットフォームUIレイアウトライブラリ

Source: https://github.com/DioxusLabs/taffy

Taffyは、主にFlexboxとCSS Gridというレイアウトアルゴリズムをブラウザ以外のUIフレームワークで利用するために実装したRustライブラリです。Dioxus、Bevy UI、およびフルブラウザエンジンを導入せずに標準準拠のレイアウトを必要とする他のいくつかのRust GUIプロジェクトのレイアウトエンジンとして採用されています。

コアとなる設計はツリーベースのレイアウトソルバーです。ユーザーはスタイルプロパティ（寸法、flexパラメータ、グリッドトラック定義）を持つノードツリーを構築し、Taffyは2パスアルゴリズムによって最終的なピクセル位置とサイズを計算します。具体的には、サイズ制約をツリー下方に伝播するmeasureパスと、ボトムアップで位置を解決するlayoutパスです。これはブラウザがレイアウトを実装する方法を意図的に踏襲しており、CSSスペックへの準拠を実現しています。

CSS Gridのサポートは容易ではありません。グリッドトラックのサイズ決定には反復的な制約解決アルゴリズムが必要であり（CSSスペックでは空きスペース分配のための多段階最大化手続きとして定義されています）、Taffyはfr単位の解決、minmax()トラック定義、および自動配置を含むフルトラックサイジングアルゴリズムを実装しています。Flexboxも同様にスペックに完全準拠しており、主軸・交差軸のサイジング手続き、flex-grow/shrink係数の分配、そしてベースライン揃えも含まれています。

パフォーマンスも重視されており、アリーナアロケータ（slotmapベースのノードストレージ）を使用することでアロケーションのオーバーヘッドとキャッシュ非効率なポインタ追跡を最小化しています。レイアウトはインクリメンタルな意味合いを持ち、入力（使用可能なスペース、スタイル）が変化していない場合は変更されていないサブツリーをスキップできます。ただし、無効化の粒度はノードレベルです。リポジトリ内のベンチマークによれば、Taffyはモダンなハードウェア上で1000ノードのツリーのレイアウトを低マイクロ秒台で完了することが示されています。

このライブラリは意図的にヘッドレスとして設計されており、ジオメトリのみを出力し、レンダリング、入力、ウィンドウ管理の機能は持ちません。これにより、任意のRust GUIツールキットにドロップインのレイアウトエンジンとして適用できます。主な制限は、CSSレイアウトのサブセットを実装するにとどまる点であり、位置指定レイアウト（absolute/fixed）とテキストレイアウトは部分的な実装であるか、ユーザーへ委譲されています。

Git at Any Scale

Source: <https://cursor.com/blog/git-at-any scale>

Cursorのエンジニアリングブログでは、大規模なGitリポジトリ（具体的には数千万ファイルを含むリポジトリや長い履歴を持つリポジトリ）を運用する際に直面したパフォーマンス問題と、それらに対処するために用いた技術的アプローチについて詳述されています。

大規模運用における主なボトルネックは git status およびインデックス操作です。Gitのインデックスは、追跡対象の全ファイルをフラットなソート済みリストとして .git/index にシリアライズしたものです。ステータスの確認には全ファイルに対してstatを呼び出しインデックスエントリと照合する必要があり、大規模なワーキングツリーではキャッシュの局所性が低い O(n) のファイルシステム操作となります。標準的な緩和策は fsmonitor フック（またはGit 2.36以降の組み込み core.fsmonitor）であり、OSのファイル監視API（macOSのFSEvents、LinuxのiNotify）を利用して変更されたパスのリストを提供することで、ステータス確認をツリー全体ではなく報告されたパスのみに限定します。

リポジトリ履歴については、長い履歴を持つファイルに対する git log や git blame はコミットDAGをウォークする必要があり、その計算量は履歴の深さに依存するため、数百万コミットになると非常にコストがかかります。コミットグラフファイル（.git/objects/info/commit-graph）は生成番号と到達可能性ビットマップを事前計算することで、祖先クエリの計算量を O(\text{DAG walk}) から、よくあるケースでは O(1) またはほぼ定数時間へと高速化します。CursorのブログではコミットグラフのメンテナンスをGC戦略に組み込むことの重要性が強調されています。

Partial cloneとsparse checkoutは、ワーキングツリー自体が問題となるケースに対処します。Sparse checkoutは宣言されたパスの集合にワーキングツリーを限定し、partial cloneはオブジェクトへのアクセスが生じるまでダウンロードを遅延させます。これは --filter=blob:none または --filter=tree:0 を使用することで、クローン時に大きなバイナリblobや深いサブツリーのフェッチを避けるものです。

このブログではpack-fileの最適化についても述べられています。多数のルーズオブジェクトを持つリポジトリのクローンは、ルーズオブジェクトの参照にファイルシステムのトラバーサルが必要なため、fetchのパフォーマンスが低下します。定期的に git repack -a -d --write-bitmap-index を実行することでオブジェクトを統合し、fetch時のpack negotiationを高速化する到達可能性ビットマップを書き出すことができます。

Linux 7.2

Source: https://www.igalia.com/2026/08/19/Linux-72-Released.html

Linux 7.2 は、いくつかの注目すべきサブシステム変更を含むメインラインカーネルリリースです。Igalia のまとめは、彼らが直接貢献した領域、特にグラフィクスとウェブプラットフォームインフラに偏っていますが、リリース全体は広範囲にわたります。

DRM/GPU サブシステムでは、Rust ベースの DRM 抽象化に関する継続的な作業が行われています。カーネルへの Rust 統合は 6.1 以降、ドライバコードへと段階的に拡張されており、7.2 では DRM プリミティブ — GEM バッファオブジェクト、スケジューラ統合、フェンス同期 — に対するより完全な Rust binding が追加され、C のグルーコードなしに Rust で完全なシンプル GPU ドライバを書くことが現実的になりました。これは、歴史的にドライバ品質が低かった組み込みや新規 GPU アーキテクチャにとって重要な意味を持ちます。

スケジューラには、6.6 で CFS を置き換えた EEVDF (Earliest Eligible Virtual Deadline First) ポリシーに対する改善が施されています。7.2 では latency-nice サポートが洗練され、インタラクティブ/バッチ混合ワークロード下での動作が改善されており、CFS から EEVDF への移行後に顕在化したデスクトップおよびゲーミングワークロードにおけるリグレッション報告に対応しています。

ネットワーキングでは、ジャンボフレームや GRO (Generic Receive Offload) との相互作用に関連するマルチバッファパケット処理のための XDP (eXpress Data Path) 改善が含まれており、また io_uring の継続的な作業として新しい操作タイプの追加と fixed-file パスにおけるオペレーションあたりのオーバーヘッド削減が行われています。

ファイルシステム面では、bcachefs が改善された fsck カバレッジとジャーナルリプレイの信頼性向上により成熟を続けています。ext4 と XFS は、現在の開発サイクルの段階において機能追加ではなく目的を絞った修正を受けています。

メモリ管理では、zswap 圧縮スワップキャッシュへの改善が行われており、より良いアカウンティングと、zswap プールが逼迫した際のレイテンシスパイクを低減する新しいライトバック機構が含まれています。6.1 でメインラインに取り込まれた MGLRU (Multi-Generational LRU) は、大規模デプロイメントからの本番フィードバックに基づいてさらなるチューニングが施されています。

注目の新規リポジトリ

FareedKhan-dev/kimi-k3-in-c

2.78兆パラメータのKimi K3 MoEモデルに対する推論を、単一CPUのRAM 8.24 GB上で動作させる、完全自己完結型のC99実装です。核心となる工夫は積極的な量子化です。重みは低ビット幅で格納されており、各フォワードパスの実行時には有効なエキスパートのパラメータのみがワーキングメモリに存在すれば足ります。また、スパースなMoEルーティングにより、トークンあたりの実効計算量はGPUなしでも扱える範囲に収まります。ランタイム全体はBLAS依存なし、Pythonなし、フレームワークスタックなしのポータブルなC99で構成されており、必要なのはコンパイラとウェイトファイルだけです。これはllama.cppと同じ思想的系譜に属しますが、より大規模なMoEアーキテクチャをターゲットとし、メモリ予算を暗黙的ではなく明示的に扱っている点が異なります。実用的には、エアギャップ環境へのデプロイ、組み込みサーバー、あるいはフレームワークのオーバーヘッドとGPUの利用可能性が厳しい制約となるあらゆる状況において有益です。BLASを使用しないため、ベクトル化は手書きで実装するか、コンパイラの自動ベクトル化機構に委ねることになりますが、スループットをスケールさせる必要がある場合には検討に値するトレードオフです。それでも、正確性の検証、教育目的での利用、あるいは制約されたハードウェア上でのプロトタイピングにおいて、フロンティア規模のMoEに対する単一ファイルの推論パスを持つことは、意義のあるエンジニアリングの成果物といえます。

Source: https://github.com/FareedKhan-dev/kimi-k3-in-c

Leonxlnx/unlazy

LLMエージェントの既知の失敗モード（怠惰、思考不足、早期タスク終了）を対象としたprompt engineeringおよびエージェントscaffoldingライブラリです。中心的な構成要素はDepth Tree法です：タスクをN層の深さで再帰的に分解し、各リーフノードには葉の数で割り当てたbudgetではなく、元のトップレベルタスクの実際の実行時間またはトークンbudgetをそのまま割り当てます。実効的な処理量はしたがってO(B \cdot L)（Bはベースbudget、Lは葉の数）でスケールし、一定のままにはなりません。設計の根拠として、モデルの怠惰性および思考不足に関する2025〜2026年の文献が引用されており、現在のRLHF訓練済みモデルが短い出力に対して暗黙的に報酬を受けていることを認めています。このライブラリはscaffoldingレイヤーでdepth-tree分解を強制するラッパーを提供し、モデル自身の計画立案傾向を回避します。これは、一貫してショートカットを行うモデルに単一の複雑なタスクを渡すagenticパイプラインに特に有用です——scaffoldingが、モデルが本来選択するであろう行動とは独立して、徹底性に向けた構造的な圧力をかけます。制限事項：トークンコストが乗算的に増加するため、コスト制御なしには実用的でなく、また葉ごとに完全なbudgetを割り当てることが常に品質を向上させるという仮定は、厳密にablationされていません。

Source: https://github.com/Leonxlnx/unlazy

alikon-art/DeterminFlow

AIワークフローを信頼性の高いサービスとして構築・運用するための、本番環境向けランタイムです。ノートブック形式のエージェントチェーンでは通常欠如している運用上の特性、すなわち入力バリデーション、構造化されたエラーリカバリー、再現可能な実行トレース、そして一度限りのスクリプトではなく永続的なサービスとしてのデプロイメントに重点を置いています。アーキテクチャはワークフローの定義と実行を分離しており、ワークフローを宣言的に構成したうえで、リトライ・部分的障害・状態チェックポイントを処理するマネージドエグゼキューターを通じて実行することができます。プロジェクト名はその設計哲学を示しています。すなわち、決定論的な制御フローをファーストクラスの制約として位置づけ、AIコンポーネントをオーケストレーターではなく失敗しうるサブルーティンとして扱うというものです。これはLangChain流のチェーン合成よりも、ワークフローエンジン（Temporal、Prefect）に精神的に近い立場です。その違いは、障害のセマンティクスが例外として伝播するのではなく、明示的に定義されている点にあります。エージェント的なプロトタイプを開発環境で動作させることに成功し、重量級のオーケストレーションプラットフォームへの再設計を伴わずに本番環境への移行ルートを必要としているチームに適しています。プロジェクトは初期段階にあり、その出自を反映してドキュメントは英語・中国語のバイリンガルで提供されています。

Source: https://github.com/alikon-art/DeterminFlow

i3T4AN/KADATH

エージェント設計を集団ベースの最適化問題として扱う、進化的マルチエージェントランタイムです。本システムは自律エージェントの集団を維持し、再現可能なエポックにわたってユーザーが指定した目標に対してそれらを評価し、選択と突然変異を適用して改良された変種を生成し、収束条件が満たされるまでこの処理を繰り返します。エポックの再現性制約が技術的に興味深い点であり、これは適応度評価が世代間で意味のある比較を行えるほど決定論的である必要があることを意味し、環境の確率性とLLMのtemperatureを慎重に扱うことが求められます。このアプローチは、手作業で設計されたエージェントのプロンプトやツール設定が脆弱であるという観察に動機づけられており、エージェント設計空間を自動探索することで、目標に対してより汎化しやすい設定を発見できるとされています。これは概念的に自動プロンプト最適化（例：DSPy、TextGrad）と関連していますが、個々のプロンプトコンポーネントではなくエージェント全体のレベルに適用される点が異なります。未解決の問題としては、報酬がスパースまたは遅延するタスクにおける適応度ランドスケープの構造、および突然変異演算子がプロンプト空間において意味論的に有意であるかどうかが挙げられます。

Source: https://github.com/i3T4AN/KADATH

yc-software/qm

複数のAIエージェントが共有タスクに協調して取り組むマルチプレイヤーエージェントハーネスであり、14kのスターを獲得していることからコミュニティでの急速な支持が伺えます。中心となる抽象化は、複数のエージェントが状態を読み取り、アクションを実行し、互いの出力を観察できる共有ワークスペースであり、単一エージェントによるツール利用を、専門化と並列処理が第一級の関心事となる協調プロセスへと変換します。「マルチプレイヤー」という枠組みは、逐次的なchain-of-agentsパターンとの差別化を図るものであり、エージェントはバトンを渡し合うのではなく並行して動作できます。実用的なユースケースとしては、ライターエージェントとクリティックエージェントによるコードレビューパイプライン、プランナーがドメイン固有のサブエージェントに委譲するリサーチタスク、あるいは独立した並列作業の後に統合ステップを設けることが逐次実行よりも効率的なあらゆるワークフローが挙げられます。「ハーネス」という枠組みは、このプロジェクトがエージェントの振る舞いを規定するのではなく、インフラ（メッセージルーティング、状態管理、エージェントライフサイクル）を提供することを示唆しており、汎用ツールとして適切な抽象化レベルと言えます。説明文を超えたドキュメントが乏しい点が、現時点での評価における主な障壁となっています。

Source: https://github.com/yc-software/qm

fuxicodex/Fuxi

LLMプロバイダー間でコストを意識した明示的なルーティング機能を備えた、ターミナルネイティブのAIコーディングエージェントです。このエージェントはシェル上で直接動作し、ファイルの読み書き、コマンドの実行、ツールの呼び出しを行います。インタラクションループ全体がIDE拡張やWeb UIではなくターミナル上で完結します。コストを意識したルーティングコンポーネントが技術的な差別化要素であり、すべてのクエリを単一のモデルにルーティングするのではなく、タスクの複雑さをプロファイリングし、フロンティアモデルの推論を必要としないタスクには安価なモデルへルーティングします。これにより、単純な編集における品質を損なうことなく、運用コストを削減できます。これは、重みレベルではなくプロバイダーレベルでのmixture-of-expertsルーティングの一形態といえます。自己完結型の設計（LLM APIコール以外の外部サービス依存なし）により、ブラウザベースのエージェントが実用的でないCI環境やリモートサーバーワークフローにも適しています。比較対象としてはAiderやClaude Codeが挙げられますが、Fuxiの差別化点は単一モデルの最適化ではなく、明示的なマルチプロバイダーのコストルーティングにあります。

Source: https://github.com/fuxicodex/Fuxi

bojieli/queqiao

パケットロスが主要なパフォーマンス問題となる劣化した長距離リンクを対象とした、セルフホスト型のWAN最適化プロキシです。トランスポート層はTLSを使用したQUICを採用し、UDPがブロックされている環境向けにTCPをフォールバックとして、またイングレスインターフェースにはSOCKS5を使用することで既存のアプリケーションを変更なしに利用できます。コアとなるアーキテクチャ上の設計判断は、パケットロスを輻輳シグナルではなくイレージャーイベントとして扱う点にあります。標準的なTCPはロスを輻輳ウィンドウを縮小するきっかけと解釈しますが、真にロスの多いリンク（衛星通信、物理的な障害を抱える大陸間光ファイバー）においては、実際のネットワーク容量に不釣り合いな壊滅的なスループット低下を引き起こします。queqiaoは輻輳チャネルではなくイレージャーチャネル向けに調整されたforward error correctionや再送戦略を使用することで、TCPがスロットリングしてしまうようなリンク上でも帯域幅を回復します。認証はトランスポート層に組み込まれており、公開されたプロキシエンドポイントには必須の機能です。セルフホスト型の構成により、オペレーターが両エンドポイントを制御できるようになっており、これは企業のWAN高速化や個人の地域間トンネリングにおける標準的な構成です。

Source: https://github.com/bojieli/queqiao

vercel-labs/marketing-team-eve-template

Eve agent frameworkをベースに構築され、Vercelインフラへのデプロイを想定した、マルチエージェントマーケティングチームのリファレンステンプレートです。本システムは、コピー生成・キャンペーン計画・アセットレビューなどのタスクをそれぞれ担う特化型エージェント群を協調的に展開し、モノリシックなアシスタントではなくチームとして機能させます。技術的な核心はエージェント協調レイヤーにあります。すなわち、タスクの分解と割り当て方法、あるエージェントの出力が別のエージェントのコンテキストへどのように供給されるか、そして個々の関数呼び出しがステートレスなサーバーレスデプロイメントモデルにおいてチーム全体の状態をリクエストをまたいでどのように永続化するか、といった点です。Vercelネイティブな設計により、このテンプレートはエージェントの状態を外部（おそらくKVまたはエッジストレージ経由）で管理する方法と、サーバーレスの実行時間制限内でマルチステップのエージェントワークフローを構造化する方法を示しています。これらはいずれも自明ではないエンジニアリング上の課題です。テンプレートとして汎用的というよりは規範的な設計となっていますが、サーバーレスコンテキストにおけるステートフルなマルチエージェント協調のパターンは他のドメインにも転用可能です。

Source: https://github.com/vercel-labs/marketing-team-eve-template