デイリーAIダイジェスト — 2026-07-02
arXiv ハイライト
PerceptionRubrics: マルチモーダル評価を人間の知覚に合わせた較正
問題
標準的なマルチモーダルキャプション・知覚ベンチマークは飽和状態に達しています。リーダーボードのスコアは、実際の使用場面では大きく異なる振る舞いをするモデル間で圧縮されてしまっています。著者らはこの原因を、既存のメトリクスが持つ二つの失敗モードに求めています。第一に、全体的な意味マッチング（CIDEr、BLEU、キャプション全体に対するLLM-as-judge）は、流暢なグローバルな要約を報酬とし、欠落した細部や幻覚的な細部を許容してしまいます。第二に、サブ基準の線形平均化により、モデルは多数の容易な項目を正答することで重大な事実誤りを補償できてしまいます。具体的な例として、DOCCIにおいて複数のフロンティアモデルが、人間の嗜好Eloレーティングでは明確に異なるにもかかわらず、ほぼ同一のスコアを受け取っています。
手法
PerceptionRubricsは、参照ベースの類似度ではなく、インスタンス固有のルーブリックに対するアトミック監査として評価を再定式化します。パイプラインは三つのコンポーネントから構成されます。
Circular Peer-Reviewによるゴールデンキャプション。 情報量の多い1,038枚の画像（混雑したシーン、密な文書、チャート、UI画面、その他のカテゴリ。図3参照）それぞれについて、複数のMLLMが長い説明文を生成し、その後お互いの出力をCircular Consensusループで批評・検証し合います。生き残った記述がゴールデンキャプションを構成し、その長さは意図的に大きく設定されています。平均770.42語、中央値569語で、3,400語を超える右歪みの裾を持ちます。長いキャプションは、何百もの個別に検証可能な視覚的事実を含む画像のルーブリックを固定するために必要です。
デュアルストリームルーブリック蒸留。 各ゴールデンキャプションはアトミックな命題に分解され、互いに素な二つのプールに分割されます。
- Must-Right：有能な観察者なら見逃さないような本質的な事実（主要被写体の同定、文書の見出しテキスト、顕著な物体の数）。ここでの失敗は基本的な知覚の破綻を示します。
- Easy-Wrong：強いモデルと凡庸なモデルを区別するような細粒度でエラーが生じやすい詳細（遮蔽された物体の属性、小さなテキスト、多数のエンティティ間の空間関係）。
ベンチマークには合計10,718のアトミックルーブリックが含まれています。Must-Rightが4,053件、Easy-Wrongが6,665件で、1画像あたり平均10.33件のルーブリックです。
ゲートスコアリング。 線形平均ではなく、スコアはMust-Rightに対して連言的、Easy-Wrongに対して加法的です。i番目のMust-Rightルーブリックの充足をM_i \in \{0,1\}、Easy-WrongをE_j \in \{0,1\}と表します。画像ごとのスコアは
S \;=\; \mathbb{1}\!\left[\textstyle\sum_i M_i \geq \tau_M\right] \cdot \left(\alpha \cdot \frac{\sum_i M_i}{|M|} + (1-\alpha) \cdot \frac{\sum_j E_j}{|E|}\right),
ここで指示関数は鋭い二値ペナルティを実装しています。閾値\tau_Mを超える本質的事実を見逃したモデルは、どれほど多くの細部を列挙していても、クレジットがゼロになります。これは、主要被写体を誤って捉えながら多くの周辺的属性を列挙するというモデルの失敗モードを直接ターゲットにしています。
ルーブリックの検証自体は、モデルの候補キャプションとアトミックな命題だけが与えられたLLMジャッジによって行われます。各ルーブリックはYes/Noのアトミックな主張であるため、全体的なキャプションスコアリングよりもジャッジの分散がはるかに低くなっています。
結果
三つの知見が挙げられています。
信頼性のギャップ。 ルーブリックごとの集計精度（線形平均）はフロンティアモデル全体で高い値を示しますが、Gatedスコアは急激に低下します。モデルは個々の検査の多くに合格しているにもかかわらず、特定の画像において連言的なMust-Rightの制約に定常的に失敗しています。これは、飽和したベンチマークが隠している脆弱性を定量化するものです。
オープン・クローズドの層別化。 推論ベンチマークではオープンソースモデルがギャップを縮めたという最近の主張にもかかわらず、PerceptionRubricsは密な知覚タスクにおいて、最良のオープンソースモデルとプロプライエタリなフロンティアモデルとの間に持続的な約8%の差を明らかにしています。ギャップが残っているのは推論ではなく、知覚においてです。
人間との整合性。 GPT-5.4、Qwen3-VL-235B、GPT-4o、Kimi-K2.6、MiMo-V2.5のVision Arena EloスコアとPerceptionRubricsを比較したところ、Pearson r = 0.916、Spearman \rho = 1.000（この5モデルのスライスにおける完全な順位一致）が達成されました。DOCCIとDetailCapsはほぼ退化したランキングを生成し、相関も大幅に低くなっています。整合性を促進するのはルーブリック分解だけでなく、ゲーティングメカニズムであるように思われます。ゲーティングを線形平均で置き換えると、アブレーション実験において順位相関が測定可能な程度に低下しています。
制限と未解決の問題
このベンチマークは画像数が少なく（1,038件）、評価はアトミックな命題に対するLLMジャッジに依存しており、信頼性の問題をキャプションレベルの判断からアトミックな検証へとシフトさせています。これはコストが低い一方で、特にOCR依存のEasy-Wrongアイテムにおけるバイアスを完全には排除できていません。Circular Peer-ReviewパイプラインはMLLMを用いてMLLMのためのグラウンドトゥルースを構築するため、生成モデル間で共有される系統的な盲点（例：特定のスクリプト、チャートの種類）が検証されないままルーブリックに伝播する可能性があります。5モデルの人間整合性スライスはSpearman数値を1.000まで高めており、より大きなモデルセットにおける順位の安定性は報告されていません。最後に、ゲートスコアリングにおける閾値\tau_Mと重み\alphaは設計上の選択であり、その感度は本論文の抜粋において完全には特徴付けられていません。
重要性
マルチモーダルキャプションベンチマークの飽和は、主にスコアリングの人工的産物でした。線形平均化により、モデルは本質的な事実を周辺的な冗長性と引き換えにすることができていたのです。アトミックルーブリックに対するゲート連言スコアリングは、フロンティアモデル間の識別能力を回復し、人間の嗜好と整合し（テスト済みスライスにおいてSpearman 1.000）、推論ベンチマークが見逃しているオープン対クローズドの8%の知覚ギャップを明らかにする、シンプルで機械的にクリーンな解決策です。
Source: https://arxiv.org/abs/2606.28322
非対称相互変分学習によるマルチモーダル連続推論
問題設定
マルチモーダル LLM は通常、推論を離散トークン（言語空間における chain-of-thought）として外部化します。知覚を重視するタスクでは、この離散化は情報の損失を招きます。細粒度の空間情報や属性情報は、利用される前にテキスト語彙に射影されてしまうためです。連続潜在推論 — 学習された潜在ベクトル \mathbf{Z} = [\mathbf{z}_1,\ldots,\mathbf{z}_k] \in \mathbb{R}^{k \times d} を自己回帰ストリームに挿入する手法 — はこのボトルネックを回避しますが、それらの潜在変数が何を表すべきかについての教師信号がありません。変分推論は自然な解決手段です。\mathbf{Z} を未観測変数として扱い、次式を最大化します。
\log p_\theta(\mathbf{y}\mid\mathbf{x}) = \log \int p_\theta(\mathbf{y}\mid \mathbf{x},\mathbf{Z})\, p_\theta(\mathbf{Z}\mid\mathbf{x})\, d\mathbf{Z}.
問題は、訓練と推論の間の非対称性にあります。訓練時に使用される事後分布 q_\phi(\mathbf{Z}\mid\mathbf{x},\mathbf{y}) はターゲット \mathbf{y} を参照できますが、推論時に使用される事前分布 p_\theta(\mathbf{Z}\mid\mathbf{x}) はそれができません。標準的な ELBO のもとでは、
\log p_\theta(\mathbf{y}\mid\mathbf{x}) \geq \mathbb{E}_{q_\phi}\!\left[\log p_\theta(\mathbf{y}\mid\mathbf{x},\mathbf{Z})\right] - D_{\mathrm{KL}}\!\left(q_\phi(\mathbf{Z}\mid\mathbf{x},\mathbf{y})\,\|\,p_\theta(\mathbf{Z}\mid\mathbf{x})\right),
順方向の KL は事前分布を、答えに条件付けされたショートカットを取った事後分布へと引き寄せます。著者らはこれを答え漏洩（answer leakage）と呼んでいます。q_\phi は \mathbf{y} をほぼそのまま \mathbf{Z} に符号化でき、事前分布はその内容を \mathbf{x} のみから幻覚（hallucinate）するよう訓練されてしまいます。
手法
AMVL は ELBO の構造を維持しつつ、事後分布を事前分布へと正則化する逆方向の KL を追加することで、双方向のキャリブレーション目的関数を生成します。具体的には、このフレームワークは両方の分布を LLM 自体からパラメータ化します。k 個の潜在スロットを自己回帰系列に挿入し、それらの位置における隠れ状態が、ガウス事前分布（\mathbf{x} のみに条件付け）とガウス事後分布（\mathbf{x} と \mathbf{y} に条件付け）をパラメータ化します。
訓練は3つの項を組み合わせます。再構成尤度 \mathbb{E}_{q_\phi}[\log p_\theta(\mathbf{y}\mid\mathbf{x},\mathbf{Z})]、標準的な順方向 KL D_{\mathrm{KL}}(q_\phi \| p_\theta)、および逆方向 KL D_{\mathrm{KL}}(p_\theta \| q_\phi) です。2つの KL は補完的な幾何学的役割を担います。順方向は mode-seeking であり、事前分布を事後分布のモードへと収束させます。一方、逆方向は mass-covering であり、事後分布が事前分布の確率質量が存在する領域全体をカバーするよう促します。双峰分布の例において、順方向 KL のみでは近似分布が1つのモードに崩壊しますが、逆方向の項によって推論時の事前分布が実際に到達できる領域へのサポートが回復されます。
漏洩に対するメカニズムは明快です。q_\phi が p_\theta(\mathbf{Z}\mid\mathbf{x}) がアクセスできない答え依存の領域に崩壊すると、事前分布が事後分布の確率質量のない場所に確率質量を置くため D_{\mathrm{KL}}(p_\theta \| q_\phi) が発散します。したがって、逆方向 KL を最小化することは、著者らが事前分布汚染（prior contamination）として定式化した「推論と非互換な」事後分布の配置にペナルティを与えることになります。
実装は Qwen2.5-VL-7B-Instruct 上で行われ、次元 d=512 の k=8 個の潜在トークンを使用しています。Vision encoder は凍結され、LM バックボーンと変分ヘッドは Visual-CoT、ReFocus、CogCoM、Zebra-CoT の混合データセット上で共同訓練されます。推論時には事前分布のみが使用されるため、計算オーバーヘッドはクエリごとに k 個の追加潜在位置分となります。
結果
高解像度知覚タスク（V*、HRBench4K、HRBench8K）において、AMVL-7B は全体で 84.29 / 72.12 / 68.50（平均 74.97）を達成しており、Qwen2.5-VL-7B の 76.44 / 68.00 / 63.75（平均 69.40）と比較して、ベースモデルに対する絶対的な改善幅は +5.57 です。最強の連続潜在 baseline である Monet（平均 74.08）および離散推論 baseline である DeepEyes（73.21）と PixelReasoner（73.09）を上回っています。特に V* ではベースモデルに対して +7.85、Monet に対して +1.04 の改善があり、HRBench8K FSP（細粒度単一インスタンス知覚）では +9.25 の改善が見られます。
視覚中心の BLINK ではより大きな効果が得られています。AMVL-7B はベースモデルの 56.08 に対して平均 66.91（+10.83）を達成し、次点の PixelReasoner（62.70）および Mull-Tokens（62.30）を約4ポイント上回っています。タスクレベルの改善は抽象的・知覚的カテゴリに強く集中しています。IQ Test +12.67、Jigsaw +32.00、Multi-view Reasoning +14.29、Visual Similarity +5.93 となっています。Spatial Relation は変化なし（88.81）であり、これは言語空間での CoT が適切でない場面において潜在推論が最も効果的であることを示唆しています。
トークンレベルの関連性マップは、学習された潜在変数が汎用的なレジスタトークンとして機能するのではなく、タスクに関連する画像領域にアテンションを向けていることを示しています。
制限と未解決の問題
評価は単一の 7B バックボーンに限定されており、事後分布がショートカットに依存しにくくなるより大規模なモデルにおいて逆方向 KL の補正が依然として必要であるか、あるいは十分であるかは検証されていません。潜在バジェットは小さく固定されており（k=8）、k に関するスケーリングの挙動や、適応的な潜在トークン数がより長いホライズンの推論に有効かどうかは未解決です。逆方向 KL が答え漏洩を特異的に無効化するという主張は「事前分布汚染」の定式化に依拠していますが、直接的な因果プローブ（例えば、逆方向の項あり・なしの条件下での事後分布における相互情報量 I(\mathbf{Z}; \mathbf{y} \mid \mathbf{x}) の測定）による検証が望まれます。潜在変数 LM において脆弱であることが知られている KL スケジューリングの詳細は付録に委ねられています。最後に、合成推論トレース上での BC-Z スタイルの teacher forcing のような単純な非変分 baseline との比較は示されていません。
重要性
連続潜在推論は、知覚を重視するマルチモーダルタスクにおける言語トークンボトルネックを回避する有望なアプローチですが、不安定な訓練という問題に悩まされてきました。失敗モードを事後分布のショートカット使用として捉え、mass-covering な逆方向 KL によってそれを修正するというアプローチは、離散 CoT が頭打ちになる抽象的視覚 benchmark において二桁の改善をもたらす、理論的に根拠のある明快な介入手法です。
Source: https://arxiv.org/abs/2607.00461
ASPIRE: ロボティクスのためのエージェント的スキル発見
ASPIRE（Agentic Skill Programming through Iterative Robot Exploration）は、code-as-policyパラダイムのもとでロボット制御プログラムを自律的に作成・デバッグ・改善し、検証済みの修正を成長し続けるスキルライブラリに蒸留する継続学習システムです。現在のLLM駆動ロボットプログラミングパイプラインのほとんどはone-shotであるという前提に立っています。エージェントがコードを生成し、それが失敗すると、人間が介入するか、エージェントが不透明なシーンレベルのフィードバックに対してリトライするかのいずれかです。ASPIREはそれぞれの失敗を、プリミティブ単位のマルチモーダルな証拠を伴う構造化されたデバッグ問題として扱い、成功した修復をファーストクラスで転用可能な知識として取り扱います。
システムアーキテクチャ
ASPIREはコーディネーター・アクターループとして構成されています（図1）。中央コーディネーターは共有スキルライブラリを所有し、アクターコーディングエージェント（シミュレーションではClaude Opus 4.6・1Mトークンウィンドウ、実機ロボットではCodex GPT-5.5）を個々のタスクに割り当てます。アクターは生のトラジェクトリやチャット履歴を共有しません。蒸留されたスキルのみがライブラリに昇格されます。各アクターのコンテキストは狭く保たれており、タスク仕様・現在のプログラム・失敗したプリミティブ付近の構造化された実行トレースのみが含まれます。
ループを閉じる3つのコンポーネントがあります。
ロボット実行エンジン。 プリミティブ呼び出し（知覚・ジオメトリ・モーション計画・制御）ごとに、エンジンはAPI・入力・出力・リターンステータス、および関連するマルチモーダルアーティファクト（呼び出し直前・直後のRGBキーフレーム・オーバーレイ・グラスプ候補・物体姿勢・プランナー出力）を記録します。エージェントは完全な動画を受け取らず、失敗に関与したコールチェーンに紐付けられた証拠スコープのトレースを受け取ります。これは意図的な設計上の選択です。証拠が少なすぎると失敗したプリミティブが隠れ、生の動画が多すぎると因果連鎖から注意がそれます。
スキルライブラリ。 検証済みの修復—人間が記述したプリミティブではなく—が再利用可能なin-contextスキルとしてコンパイルされます。生成されるカテゴリには、局在化の曖昧性解消・モーションプリミティブ構築・ナビゲーションリカバリー・物体レベルの把持・シーン理解・デバッグワークフローが含まれます。
進化的探索。 単一トラジェクトリの改善に依存するのではなく、コーディネーターはタスクをまたいで多様な候補プログラム \pi_0, \ldots, \pi_k をサンプリングし、純粋なローカル修復ループでは見逃してしまう代替戦略の探索を可能にします。
トレースガイデッドデバッグの具体例
図2は、BEHAVIOR-1Kのナビゲーション・ラジオピックアップタスクにおけるメカニズムを示しています。エゴビューのキーフレームは、ロボットがラジオを局在化しながらも繰り返しアプローチに失敗する様子を示しています。プリミティブトレースは、繰り返す PLANNING_ERROR のリターンに失敗を帰属させています。ナビゲーション候補ゴールがテーブルの衝突回避バッファの内側に落ちているためです。アクターはパッチを合成します。到達可能な側からラジオを再知覚するマルチアングルアプローチルーティンです。修復はクローズドループで検証され、「Multi-Angle Approach」スキルとしてライブラリに昇格されます。
重要なのは、このスキルが将来のクラッター付きナビゲーションタスクにおいてin-contextで利用可能になり、後述のように、実機ハードウェア上の異なるエンボディメントにおいても同様であるということです。
実験設定と結果
コーディングエージェント・環境・APIサーフェスは、全てのシミュレーション実験にわたって固定されています。ASPIREはhold-inシードレンジでスキルを学習・収集し、held-outシードに対してタスクごとに1つの生成プログラムを評価します。主要な比較ベースラインであるCaP-Agent0は、1つの次元においてASPIREの評価プロトコルよりも有利です。テスト時の推論とリトライを用いてシードごとに新鮮なプログラムを再生成します。ASPIREはタスクごとに1つのプログラムにコミットします。
- LIBERO-Pro（摂動下での10タスク×50 held-outシード）：摂動下でのマニピュレーションにおいて、従来手法に対して最大77%の改善。シード51–65で学習し、シード1–50で評価。
- Robosuite（タスクごとに100のheld-outトライアル、2Aバイマニュアルを含む）：バイマニュアルハンドオーバーにおいて最大72%の改善。シード101–125で学習し、1–100で評価。
- BEHAVIOR-1K 2つの家庭タスクにおける長期ホライズンモバイルマニピュレーション：最大32%の改善、ナビゲーションとタスク成功が個別に報告。シード26–35で学習し、インクリメンタルブロック実行でシード1–25で評価。
ASPIREのいくつかの結果は、これらのベンチマークにおいて人間の専門家が作成したプログラムを上回ると報告されています。
クロスエンボディメント転送
実機ロボットの研究（§3.6）は、スキルが単なるタスク単位の過学習ではないことの最も直接的な証拠です。ASPIREはFrankaベースのシミュレーションで学習した3つのスキル（ソーダ缶ピックアップ・ボウルのプレートへの配置・引き出しのプッシュ/プル）を選択し、異なるエンボディメントとAPIを持つバイマニュアルYAMマニピュレーションステーション上のCodex GPT-5.5コーディングエージェントへのin-contextガイダンスとして注入します。評価指標のペアはtokens-to-first-successとheld-out実機ロボット成功率であり、シミュレーションで発見されたスキルの有無で比較されます。エンジンは実機ロボット上でもマルチモーダルトレースを公開し、エージェントがタスク固有の人間入力なしに自律的にデバッグできるようにしています。結果の方向性は転送の主張を支持していますが、3つのスキルというサンプルは控えめです。
制限事項と未解決の問題
- 評価にはフロンティアのクローズドモデル（Claude Opus 4.6、GPT-5.5）と1Mトークンコンテキストが使用されており、オープンループデバッグの計算量とレイテンシのエンベロープは相当なものですが、本抜粋では特徴付けられていません。
- タスクごと1プログラムの評価はエレガントですが、多くのタスクにわたるライブラリの成長は、示されたセクションでは分析されていない検索と干渉の問題を提起します。
- スキルはin-contextテキスト/コードとして保存されており、ライブラリがコンテキスト予算を超えた場合のスケーリング挙動や、APIやエンボディメントが変化した際のスキルの非推奨化についての議論はありません。
- 実機への転送は3つのキュレートされたスキルで実証されており、任意のシミュレーションで発見されたスキルが転送するのか、あるいはフィルタリングされたサブセットのみが転送するのかは不明です。
- トレース帰属ヒューリスティック（呼び出しごとにどのキーフレームとオーバーレイを公開するか）の失敗モードは定量化されていません。
なぜこれが重要なのか
ASPIREは、エージェント的ロボットプログラミングが実行スタックをブラックボックスではなくデバッグ可能な環境として扱い、手作業で記述されたプリミティブの代わりに検証済み修復の永続的なライブラリを用いるべきであるというアイデアのクリーンな具現化です。報告されたマージン（LIBERO-Proで最大77%、Robosuiteバイマニュアルで72%、BEHAVIOR-1Kで32%）とシミュレーションから実機へのスキル転送は、構造化されたマルチモーダルトレースと積み重なるスキルストアが、code-as-policyと持続的なロボット能力の間に欠けていた足場である可能性を示唆しています。
Source: https://arxiv.org/abs/2607.00272
状態予測分離仮説
自己回帰Transformerにおいて、各隠れ状態 h_i^{(l)} は構造的に異なる2つの目的を果たします。すなわち、x_{i+1} のlogitを生成すること、および将来の全ポジション j>i がKV cacheから参照するkeys/valuesを出力することです。著者らはこれを形式化するために、長さ T のシーケンスに対する全体のgradientを予測項と状態準備項に分解しています。
\nabla_{\theta}\mathcal{L} = \sum_{i=1}^{T-1}\Big[\underbrace{\tfrac{1}{T-1}\nabla_{\theta_i}\ell_i}_{\text{Prediction}} + \underbrace{\tfrac{1}{T-1}\sum_{j=i+1}^{T-1}\nabla_{\theta_i}\ell_j}_{\text{State}}\Big].
両項は同じ h_i^{(l)} を経由するため、単一のactivationが「今何を出力するか」と「将来のトークンが私から何を必要とするか」を同時にエンコードするよう最適化されます。この仮説は、この混在が最適ではなく、2つのgradient成分を別々の表現に経路分岐させるアーキテクチャ的設計により言語モデリングが改善されるというものです。
2ストリームアーキテクチャ
State-Prediction Separation（SPS）Transformerは、各入力の後に学習済みの <predict> トークン \rho_i を挿入します。
x \rightarrow (x_1,\rho_1,x_2,\rho_2,\ldots,x_T,\rho_T),
ここで x_i と \rho_i はposition encodingを共有します。lossは \rho_i スロットにのみ適用されます（式4）。重要な点として、attention maskが非対称な持続性を強制します。
\mathcal{A}_{\mathrm{SPS}}(i,q) = \{x_k : k \leq i\} \cup \begin{cases}\{\rho_k : i-w \leq k < i\} & q = x_i \\ \{\rho_k : i-w \leq k \leq i\} & q = \rho_i\end{cases}.
入力エントリは永続的なKV cacheに存在し、任意の距離を超えて状態を保持します。一方、<predict> エントリはサイズ w（デフォルト w=64）のスライディングウィンドウの後に退去されるため、遠い将来のトークンへの状態準備に寄与することができません。\rho_i におけるlossのgradientは h_{\rho_i} を通じて予測パラメータに伝播し、状態準備のgradient \sum_{j>i}\nabla \ell_j は永続的なKV読み取りを介して入力ストリーム h_{x_i} に流れます。これにより2つの役割が機械的に分離されます。
メカニズムを特定するAblation
2つのベースラインにより明白な交絡因子を排除しています。2x Memory は両ストリームを永続的に保持します。このモデルは余分な計算リソースを得ますが、役割が再び混在し、KV cacheが2倍になります。Delayed State は予測と状態の両方を <predict> スロットに配置し、入力に対してスライディングウィンドウを使用します。これは余分な計算ステップを保持しますが、分離は維持しません。Reverse SPS バリアントは経路付けを入れ替え（<predict> を通じた状態、入力を通じた予測）、分離の方向が重要かどうかを検証します。
結果
GPT-2スタイルの5つのスケール（53Mから1.678Bパラメータ、4096トークンコンテキスト）全体において、SPSは全スケールでFineWeb-Edu検証NLLの最低値を達成し、Standardとのギャップは単調に拡大しています。すなわち、XSで -0.042、Sで -0.048、Mで -0.058、Lで -0.067、XLで -0.068 となっています。
同一トークン数での比較ではSPSが常に優位であり、GPU時間の比較においても、挿入されたシーケンスによってコンテキスト長が実質的に2倍になるにもかかわらず、Standardを上回っています。Standardのpre-decayバジェットを18Bから36Bトークンに倍増させてもXLのギャップは埋まらず、SPSがStandardの品質をおよそ半分のデータで達成し、そのスケールとともにその比率が拡大することを示唆しています。
分布外コーパスのNLLはスケール全体で 0.09〜0.11 低下し、XLでの最大低下は -0.149 となっています。Zero-shotタスク精度（5ベンチマーク平均）はXSで +2.5、Sで +2.3、Mで +2.9、Lで +2.5、XLで +3.1 向上しています。
重要なことに、Delayed StateはSPSのNLL改善の約半分を回復しますが、一貫してSPS自体には及びません（例：XLでは -0.048 対 -0.068）。これは余分な計算ステップ単独が主因ではないことを示しています。2x MemoryはNLLでDelayed Stateと同等ですが、デコード時のピークメモリコストが 1.75\times〜1.81\times 増加し、XLではスループットが最大 0.64\times 低下するという代償を払います。SPSはStandardに近いスループット（XLで 0.94\times）とメモリ（1.01\times）を維持しています。
ウィンドウのスイープがメカニズムを確認しています。品質は小さいが非ゼロの w で最良となり、Reverse SPS（<predict> を通じた状態経路付け、入力を通じた予測）はすべての w において厳密に劣っています。
この非対称性、すなわち永続的な入力と一時的な予測、が機能しているのであり、単に2つのストリームが存在するだけでは不十分です。
限界と未解決の問題
学習時のattentionパターンにより各シーケンスが実質的に長さ 2T となるため、トークンあたりの学習FLOPはStandardよりも高くなります。論文はGPU時間の同等性を報告していますが、FLOP一致での比較曲線は示していません。スライディングウィンドウ w は新たなハイパーパラメータであり、最適値がスケールや4096を超えるコンテキスト長とともにどのように変化するかは論文では検討されていません。SPSの内部でStandardと比較して予測gradientと状態gradientが実際により非整合であることを示すgradientレベルの測定はなく、「gradientの根本的な相違」という主張はablationパターンからの推論に大きく依存しています。最後に、全実験はFineWeb-Eduにおけるdecoder-onlyの事前学習のみであり、長コンテキストのfine-tuning、RLHF、または検索設定での動作は未検証です。
なぜこれが重要か
この結果は、通常あらゆるTransformerのforward passにおいて見えない形で絡み合っている2つの機能を特定・分離するという、明確なアーキテクチャ的介入です。FLOP一致での比較および長コンテキストにおいて 2〜3 ポイントのdownstream改善と \sim 2\times のデータ効率が維持されるならば、これは既存の事前学習レシピと競合するのではなく、組み合わさる種類の変更です。
Source: https://arxiv.org/abs/2607.01218
反復的メタリフレクションによる自律的科学的発見
問題
LLMを基盤とした自律的発見パイプラインは、通常以下の2つの制約のいずれかの下で動作します：(i) ペアワイズ因果エッジ（PC、NOTEARS、GPT-4 BFS）のような制限された仮説空間を探索するか、(ii) 完全な研究課題またはシード仮説を必要とする（AI Scientist、HeurekaBench、ExperiGen）かのいずれかです。いずれの設定も、生のデータセットを渡されて「ここに何がある？」と問われた研究者のオープンエンドな状況を反映していません。さらなるギャップとして、反復的な提案ループは発見を蓄積するものの、その蓄積について推論して構造的なギャップ、交絡因子、または冗長なカバレッジを特定することがほとんどありません。
DiscoPERは \mathcal{P}=\emptyset、\mathcal{H}_{\text{code}}^{\text{open}} のレジーム（事前目標なし、任意の実行可能コードとして表現可能な仮説）を対象とし、事前クレームをデータとして扱う明示的なメタリフレクションステップを追加しています。
手法
著者らは先行研究を、クレーム集合 \mathcal{C}_t とガイダンス要約 \mathcal{G}_t に関する汎用ループのインスタンスとして形式化しています。データ \mathcal{X}（オプションでマルチモーダル）が与えられると、システムは以下を反復します：
h_t^{(1)},\ldots,h_t^{(K)} \sim \textsc{Propose}(\mathcal{X},\mathcal{P},\mathcal{G}_{t-1},\mathcal{C}_{t-1}) b_t^{(k)}, e_t^{(k)} = \textsc{Evaluate}(h_t^{(k)}, \mathcal{X}) \mathcal{C}_t = \mathcal{C}_{t-1} \cup \{h_t^{(k)} : b_t^{(k)}=\text{supported}\} \mathcal{G}_t = \textsc{Reflect}(\mathcal{C}_t, \hat{\mathcal{C}}_t) \quad \text{every } \tau \text{ iterations}
各仮説 h は \mathcal{X} を受け取り、統計的エビデンス e とともに b\in\{\text{supported},\text{rejected}\} を返すプログラムです。採択基準は厳格です：効果量 |\delta|\geq 0.2、訓練分割と保留された検証分割の両方で p\leq 0.05、さらに過学習ガード |\delta_{\text{val}}|\geq 0.6\cdot|\delta_{\text{train}}| が課されます。この双方向分割テストが、LLMが捏造した「パターン」を \mathcal{C}_t から排除します。
3つのモジュールを図2に示します。Proposeは自然言語のクレームとコードを出力し、Evaluateはテストコードを生成します（また、iNaturalistの観察データに対するマルチモーダルな仮説を実現するため、画像から視覚的属性を抽出するために同一のベースLLMに紐付けられたVLMを呼び出すことがあります）。Reflectは5イテレーションごとに実行され、カバレッジ、交絡因子、および未探索の方向をまとめた \mathcal{G}_t を生成します。
ExperiGen（短期記憶を使用）やHeurekaBench（リフレクションなし、完全な事前情報あり）との際立った相違点は、\mathcal{G}_t が単なる進行中のスクラッチパッドではなく、\mathcal{C}_t \cup \hat{\mathcal{C}}_t を経験的データとして分析することで導出された二階オブジェクトであるという点です。
結果
エッジ回復メトリクス（SHD、edge-F1）は媒介・交絡構造をスコアリングできず、QAベンチマークは目標をリークするため、iNaturalistの観察データから2つの新しいベンチマークが導入されています：
- iNatDisco-800：800件の観察データ、8種、査読済みの生態学的パターン9件をground truthとして使用。
- iNatDisco-50K：50,000件の観察データ、9,776種、12件のパターン。
iNatDisco-800において、Claude Sonnet 4.6、100イテレーション、5イテレーションごとにリフレクションを実施した結果：
| 手法 | \mathcal{H} | 事前情報 | Recall | Support rate |
|---|---|---|---|---|
| LLM+PC | edge | なし | 0/9 | – |
| LLM+NOTEARS | edge | なし | 0/9 | – |
| GPT-4 BFS | edge | 完全 | 1/9 | – |
| HeurekaBench | code (guided) | 部分的 | 3/9 | 62.2 ± 6% |
| ExperiGen | code (guided) | 部分的 | 3/9 | 56.6 ± 5% |
| DiscoPER w/o Reflect | code (open) | なし | 7/9 | 70.0 ± 2% |
| DiscoPER | code (open) | なし | 8/9 | — |
2点が際立っています。第一に、エッジ仮説からオープンコード仮説への移行は、それだけでおよそ4/9のrecall向上に値します。ground truthのパターン（例：オオカバマダラの観察における季節的な緯度変化）がペアワイズの条件付き独立関係ではないため、因果グラフ手法はここではほぼ失敗します（0〜1/9）。第二に、Reflectは事前情報ゼロで動作しながらアブレーションに対して+1/9のrecallを追加し、部分的なタスク記述を受け取る手法を上回っています。
iNatDisco-50Kにおけるスケーリング挙動（図3）は示唆に富んでいます：(a) データ量が増えるとrecallと支持されたクレーム数の両方が単調に増加し、(b) イテレーション数が増えるとrecallは増加するが、support rateは低下します。後者は、容易で効果量の大きいパターンを早期に消費し、|\delta|\geq 0.2 の保留閾値を満たさない投機的なクレームへと移行するシステムの典型的なシグネチャです。これは、採択フィルタがLLMの出力を単に追認するのではなく、実質的な機能を果たしているエビデンスです。
限界と未解決の問題
- Ground truthは少数の精選された文献パターンのセット（9件と12件）であり、8/9のrecallは低カーディナリティの参照集合に対するものです。真のパターンのより広い空間に対する偽陰性は測定されていません。
- 統計的採択は偽の効果を排除しますが、因果性を裁定するわけではありません。仮説コード自体が同定戦略を実装していない限り、支持されたクレームは関連性に基づくものです。オープンループに対する明示的な多重検定補正（ExperiGenのBonferroniとの対比）は報告されていません。
- Reflectの品質はベースLLMが \mathcal{C}_t を内省する能力に依存しており、小規模モデル（DeepSeek V4 Pro等）での性能低下は報告されていますが、Proposeの失敗とReflectの失敗モードへの分解は行われていません。
- 画像属性のためのループ内VLMは推論LLMと重みを共有しており、仮説生成と視覚的特徴の評価との間で相関したエラーが生じるリスクがあります。
なぜ重要か
先行する自律的発見システムを単一の (\mathcal{H}, \textsc{Propose}, \textsc{Evaluate}, \textsc{Reflect}, \mathcal{P}) タプルの制約として捉えるフレームワークは、どこに影響力があるかを明確にします：\mathcal{H} を実行可能コードに開放することと二階リフレクションの追加は、それぞれ測定可能かつ加算的な利得をもたらし、両者を組み合わせることで部分的な事前情報を与えられたシステムを上回ります。イテレーションに伴うsupport rateの低下は、オープンエンドエージェントに対する原理的な停止シグナルを与えます。
Source: https://arxiv.org/abs/2607.01131
Graph-NativeなReinforcement Learningが概念的再結合によってトレーサブルな科学的仮説生成を可能にする
問題
オープンエンドな科学的仮説生成（材料設計・力学）に適用されたLLMは、流暢な文章を生成しますが、その中間的な推論が欠如しているか、事後的であるか、あるいは最終的な回答と整合していません。提案されたメカニズム（例えば、生体模倣複合材料における階層的な靭性化経路）が中間的な因果的主張から実際に導かれるかどうかを検証する必要があるPhDレベルのユーザーにとって、このトレーサビリティの欠如が本質的な制約となっています。著者らが標的とする具体的な失敗モードは、検査・分解・問題横断的な再利用が不可能な推論です。
手法
Graph-PRefLexORは1.7B、3B、8Bパラメータのモデルファミリーであり、それぞれQwen3-1.7B、Llama-3.2-3B-Instruct、Qwen3-8Bから初期化されています。コアとなる設計は、<think>領域を5つのセンチネルで区切られたフェーズに分解することを強制します。
<brainstorm>— 発散的な候補メカニズムと失敗モード。<graph>— エンティティ（配列、構造、処理、特性……）と型付き因果関係への抽象化。<graph_json>— 厳密な機械可読な有向グラフ（例:{"source":"Sequence","relation":"encodes","target":"Structure"}）で、固定された関係語彙から導出されます。<patterns>— 高次モチーフの抽出：因果連鎖（\text{sequence} \to \text{structure} \to \text{properties} \to \text{failure}）、スケール橋渡しエッジ、フィードバックループ。<synthesis>— マルチスケールメカニズムを予測される結果に結びつけるテスト可能な仮説への統合。
学習は2段階で行われます。Stage 1はORPOによるもので、選好ペアを使用します。選択された回答は、強力な教師（GPT-5.1）が「グラフベースの潜在構造を使って推論する」というシステムプロンプトのもとで生成した完全なgraph-nativeなトレースであり、棄却された回答はGPT-5-nanoによる意図的に浅い1〜3文の回答です。行動上のギャップは意図的に大きく設定されており、選好の順序付けが1エポック以内に飽和するようにされています――これがスキーマを定着させる「コールドスタート」です。graph_jsonがパース不可能だったり回答が空のレコードは破棄されるため、すべての学習例には有効なパース済みグラフが含まれています。
Stage 2はGraph-GRPOです。使用されるのはプロンプトとゴールド回答のみで、選択/棄却ペアは使用されません。ポリシーは自身のトレースをサンプリングし、同じgraph_jsonオブジェクトに基づく複合報酬を受け取ります。この報酬は回答の正確さとグラフの質（構造的妥当性、ノード/エッジの型付け、抽出されたパターンとの整合性）の両方を評価します。GRPOのグループ相対的アドバンテージ推定器はこのような設定に適しています。なぜなら、価値クリティックが不要であり、サンプルされたグループ内で報酬を正規化するためです。これは報酬がフォーマット、構造、意味論的な項の不均質な和である場合に重要です。
学習コーパスはfineweb-edu（一般教育的Webテキスト）とbio-silk-mech-mix-80K（生物・機械材料に焦点を当てたもの）を混合しており、グラフスキーマは汎用的なスキャフォールドではなくドメイン語彙に基づいています。特筆すべきは、3Bバックボーン（Llama-3.2-3B-Instruct）にはネイティブな思考モードがないため、graph-nativeなフォーマットをゼロから獲得する必要があるという点です。著者らは、学習ダイナミクスを支配するのはスケールではなくこのバックボーンの違いであると指摘しています。
結果
評価には、材料科学および力学分野の公開文献から導出された100問のオープンエンドな問題が使用されており、分野横断的な結びつけ、因果マッピング、仮説生成を検証します。Claude Opus-4.7が判定器として使用され（GPTベースのデータセット生成器とは意図的に異なるファミリーから選択し、ファミリーバイアスを低減）、Reasoning Quality、Intellectual Depth、Reasoning Traceability、および総合的なOverall Scoreを0〜10で採点します。
3つのスケールすべてにわたって、Graph-PRefLexORは総合スコアでベースモデルに対して40〜65%の向上を達成しており、最も大きな差分はReasoning Traceability――手法が対処するよう設計された軸――で見られます。生成されたトレースのembedding解析によれば、対応するベースラインと比較して意味的多様性が約2〜3倍大きいことが示されており、<brainstorm>フェーズがRL後に狭いモードに収束しておらず、グラフ条件付き生成が定型的な連鎖を繰り返すのではなく、より広範な概念的再結合を促進していることが示されています。意味的バックトラッキングおよび層ごとの隠れ状態解析（論文内に報告）はさらに、グラフ構造が表面上のトークンとして単に出力されるのではなく、内部的に表現されていることを示しています。
限界とオープンクエスチョン
- 判定器は単一のLLM（Claude Opus-4.7）です。絶対的なスコアレベルは人間の専門家による評価と比較できず、LLM判定器によって採点される「トレーサビリティ」は真の因果的妥当性よりもフォーマット準拠を報酬するかもしれません。
- 関係語彙は事前定義されており、オープン語彙のエッジや発見された関係は評価されていません。
- 教師蒸留トレースに対するORPOの1エポックのみの学習により、モデルは特定のグラフスタイルの強力な模倣者となります――利得のどれだけがGRPOによるものでORPOコールドスタートによるものかは、学習ダイナミクスの議論を超えて完全には分離されていません。
- ベンチマークは100件のオープンエンドな問題であり、トレーサブルな推論が数値的に正確な下流予測を生成するかどうかを確認するための閉じた形式の検証可能な回答セット（例：特性予測）は存在しません。
- 生物/機械材料混合データ以外への汎化は未検証であり、3Bバックボーンの比較は思考機能を持たないベースラインとの比較であるため、traceabilityの差分が過大評価されています。
なぜこれが重要か
chain-of-thoughtの中にパース可能なグラフを強制することで、「推論」は不透明な散文的成果物から、監査・差分比較・再結合が可能なオブジェクトへと変換されます――これはLLMを回答生成器としてではなく、科学的発見ループのコンポーネントとして利用するための前提条件です。1.7Bモデルがオープンなコールドスタートとグラフ条件付きGRPOによってこの領域に誘導できるという結果は、スケールではなくフォーマットが主な役割を果たしていることを示唆しています。
Source: https://arxiv.org/abs/2607.00924
TurboServe: ストリーミング動画生成を効率的かつ経済的に提供する
問題
ストリーミング動画生成は、オフライン（ワンショット）動画生成およびLLMサービングの両方とは異なる、新しいサービングワークロードです。ユーザーは長期間のセッションを開設し、動画をチャンク単位で生成します。このとき、アクティブ期間とアイドル期間が交互に現れ、サーバーはセッション全体の生存期間にわたってセッションごとの状態（temporal features、KV cache、latent buffer、control embedding）を維持しながら、厳格なデッドライン内で各新規チャンクを配信しなければなりません。
Shengshu Technologyの本番トレースに見られる2つのワークロード特性が、汎用サービングスタックを機能不全に陥らせます。
- セッション持続時間の不均一性。 セッションの生存期間は数桁にわたるため、初期配置の判断は、短いセッションが終了し長いセッションが継続するにつれて最適ではなくなります。
- 時間的需要の不均一性。 同時にアクティブなセッション数は数分単位で急激に変動します。
論文の動機として示されているように、この結果として、(a) GPU間でセッションのアクティベーションが偏ることで最も負荷の高いGPUがチャンクあたりの最悪ケースのレイテンシを決定づけ、(b) 需要の低い期間には固定の割り当てが十分に活用されず、(c) 需要の高い期間にはSLO違反が発生します。
手法
TurboServeは、サービングをイベント駆動のオンラインスケジューリング問題として定式化し、セッション配置 \phi_i(t) とクラスターサイズ M(t) \in \{0,\dots,M_{\max}\} という2つの連動した制御を行います。各イベント t（到着、離脱、アクティブ/アイドル遷移）において、各セッション s_i \in \mathcal{S}(t) はGPU g_j \in \mathcal{G}(t) へのマッピング（実行）、\emptyset へのマッピング（サスペンド、状態をホストにオフロード）、または終了のいずれかが割り当てられます。各GPUはチャンクあたりのレイテンシ予算を守るために最大 K の同時セッションをホストします。結合された目的関数は、重み \lambda(t) を用いて最悪ケースのチャンクあたりレイテンシ \mathcal{L}(t) とプロビジョニングコスト \mathcal{C}(t) のトレードオフを取ります。
ランタイム基盤（TurboServe_base）。 各GPUはコアレスチャンクループを実行します。すなわち、次のチャンクが準備できたセッションを収集し、バッチにまとめ、モデルを一度呼び出し、セッションごとの状態を書き戻します。状態は(i) 共有モデルレプリカ、(ii) セッションごとの独立した状態領域（descriptor、prompt/control embedding、temporal/KV state、チャンク履歴、latent buffer）、(iii) 所有権テーブルに分割されます。セッションはセッションごとの領域のみをホストメモリにコピーすることでサスペンドできます。再計算ベースのrematerialization（LLM KV-cache管理で一般的）は、動画生成がメモリ帯域幅バウンドではなくコンピュートバウンドであるため採用されません。
配置コントローラー。 マイグレーションを考慮したコントローラーがセッションを再分散し、最悪ケースのチャンクあたりレイテンシを引き起こす正規化GPU負荷の最大値 \rho_{\max}(t) を低減します。マイグレーションはセッションごとの状態領域のみをGPU間でRDMA/NIXL one-sided readを介して転送し、CPUを経由しません。一貫性はチャンク境界で保証されます。具体的には、(i) ソースが現在のチャンクを完了して状態を凍結し、(ii) ターゲットがバッファを取得・検証し、(iii) 所有権がアトミックに切り替わります。これにより転送を継続に必要なもののみに限定し、チャンクの重複実行を防ぎます。
オートスケーリングコントローラー。 負荷駆動のループが観測された負荷と利用率を目標値 \hat{\rho}(t) と比較し、目標バジェット M_{\mathrm{tar}}(t) を計算してGPUをプロビジョニングまたは解放します。セッションはマイグレーション可能であるため、スケールインは長期滞在セッションによってブロックされません。それらは残存するGPUに退避されてからシャットダウンされます。
セッションマネージャー。 実行/サスペンド/終了の遷移を追跡し、サスペンドされた状態をホストメモリに永続化することで、セッション生存期間をGPU常駐から切り離します。
結果
評価にはLongLiveスタイルのストリーミング動画モデル（LongLive-1.3Bおよびより大きなバリアント）を使用し、Shengshuのクラスター（Cluster 1: 16台のH20 GPU、Cluster 2: 64台のB300 GPU）上で実施します。8台のGPUによるNVLinkアイランドは956 GB/s、ノード間は50 GB/s RDMA InfiniBandです。6本の本番トレースを再生して評価します。ベースラインはTurboServe_base（ラウンドロビン＋FCFS）、TurboServe_base+LAG（利用率による最小負荷GPU）、およびTurboServe_base+MAG（メモリ利用率が最小のGPU）です。
論文はペアによる比較を報告しています。コストを固定した場合の最悪ケースのチャンクあたりレイテンシと、レイテンシを固定した場合のコストです。コストを固定した場合、TurboServeはモデル、トレース、両クラスターにわたって全3つのベースラインに対して最悪ケースのチャンクあたりレイテンシを低減します。レイテンシを固定した場合にはGPU運用コストを削減します。アブレーション実験により2つのメカニズムを個別に評価した結果、オートスケーリングを除去すると主に低需要期においてコストが膨らみ、マイグレーションを除去するとアクティベーションが偏る期間において最悪ケースのレイテンシが主に膨らむことが示されました。
（トレースごとの正確な数値は論文のFigure 7に含まれており、抽出されたテキストには含まれません。定性的な順序は、両軸においてTurboServe < MAG ≈ LAG < baseです。）
限界と未解決の問題
- 論文の貢献はスケジューラーとランタイムであり、生成モデル自体を修正しないため、固定バッチサイズにおけるチャンクあたりの計算レイテンシは変わりません。改善はすべて配置、マイグレーション、弾力性から生じます。
- GPU当たりの最大同時セッション数 K は、チャンクあたりレイテンシSLOから導出される上限として扱われており、適応的な K や異種モデルの共同配置については検討されていません。
- マイグレーションはチャンク境界においてのみ実行されます。チャンクが非常に長い場合や高コストな状態（大規模なtemporal cache）を持つモデルでは、凍結・転送・インストールのウィンドウが支配的になる可能性があり、論文ではマイグレーションオーバーヘッドの分布やテールレイテンシへの影響は報告されていません。
- オートスケーリングコントローラーは観測された負荷に反応します。既知のバースト的パターン（例：日周トレース）に対する予測的スケーリングは評価されていません。
- 再計算はコンピュートバウンドという理由で却下されていますが、ハイブリッドな手法（latentをオフロードし、安価なconditioningを再計算する）は最大規模のモデルにとって依然として魅力的な可能性があります。
この研究の意義
ストリーミング・セッション指向の生成動画は、vLLMスタイルのLLMサービングともバッチ拡散パイプラインとも異なるワークロードクラスです。永続的な状態、アクティブ/アイドルサイクリング、チャンクごとのハードなデッドラインを組み合わせています。TurboServeはスケジューリング問題を明確に定式化し、セッションごとの領域メモリレイアウトとRDMA転送の上に構築された、マイグレーションを考慮した配置と負荷駆動のオートスケーリングの組み合わせが、本番ストリーミングワークロードと汎用サービングヒューリスティクスとのギャップを埋めるのに十分であることを示しています。
Source: https://arxiv.org/abs/2606.19271
Hacker News Signals
Senior SWE-Bench: エージェントをシニアエンジニアとして評価するオープンソース benchmark
SWE-Bench はエージェントが GitHub の issue をクローズできるかどうかをテストしますが、そのタスクは自己完結した明確に仕様定義されたバグ修正に偏りがちです。Senior SWE-Bench は、シニアエンジニアが実際に行う作業を反映したタスクを構築することでハードルを引き上げています。具体的には、複数ファイルにわたるリファクタリング、API 設計の意思決定、下流の互換性制約を持つ機能追加、そして曖昧な仕様の解決といったタスクです。この benchmark はオープンソースであり、Snorkel のデータキュレーション基盤の上に構築されています。
技術的には、各タスクにはルーブリックが紐付けられており、「テストスイートが通るか」だけでなく、構造的な基準も捉えています。具体的には、変更が既存の抽象化を尊重しているか、不必要な結合を導入していないか、コミットメッセージが diff と整合しているか、といった観点です。これにより、評価がユニットテストの合否判定よりもコードレビューに近づきます。テストをパスすることは必要条件ではありますが、プロダクション品質のコードには到底十分ではないため、この違いは重要な意味を持ちます。
ここでより困難なエンジニアリング上の課題は、人手アノテーションがボトルネックにならないようにしながら、大規模なルーブリックを構築することです。Snorkel のアプローチでは、プログラマティックラベリングを使ってルーブリックのコンポーネントをブートストラップし、その後、人手のレビュアーによって検証を行います。この benchmark は、意図的に不完全なコンテキストを持つタスクにおけるエージェントの挙動も追跡します。これは、関連する背景情報が省略されている実際のチケットにより近いアナログです。
現在のフロンティアモデルは、Senior SWE-Bench において元の SWE-Bench よりも大幅に低いスコアを記録しており、後者がシグナルとしてある程度飽和しつつあることを示唆しています。この benchmark はオープンソースであるため、コミュニティはタスク構築を監査したり、現在の Python ウェブフレームワーク中心のコーパスを超えたドメインを追加したりすることができます。
未解決の問題としては、ルーブリックの妥当性（ルーブリックへの準拠がシニアエンジニアの判断と実際に相関するか？）、現在の Python 中心のコーパスを超えた言語およびフレームワークのカバレッジ、そしてプログラマティックラベリングが「シニア」品質の定義に関して系統的な盲点を生じさせないか、といった点が挙げられます。
Source: https://senior-swe-bench.snorkel.ai/
難読化：暗号理論の最終ボスを構築する（パート I）
Vitalik によるこの解説は、識別不可能難読化（iO）を取り上げています。iO は、効率的に実現可能であれば、他のほぼすべての暗号構成を包含し得る暗号プリミティブです。「最終ボス」というフレーミングは的を射ています。iO を用いると、機能的に等価な任意の2つの回路に対して、難読化されたコード自体が与えられても計算上識別不可能な難読化バージョンを生成することができます。
この記事では、定義の階層構造を丁寧に説明しています。すなわち、仮想ブラックボックス（VBB）難読化——理想的ではありますが一般回路に対しては証明可能な意味で実現不可能——と、等価なプログラム間の識別不可能性という保証に要件を弱めた iO との比較です。iO に一方向性関数を加えることで、公開鍵暗号、完全準同型暗号、関数型暗号、そして証人暗号が、いずれも特殊ケースとして構成できます。これにより、iO は複雑性理論的に厳密な意味での「完全な」プリミティブとなっています。
現在の候補構成は多線形マップまたは格子ベースの仮定（例：Lin-Matt 構成、その後の Jain-Lin-Sahai による研究）に依拠しています。これらはまだ実用的ではありません。多項式オーバーヘッドが大きく、トイプログラムでさえギガバイト単位の難読化回路を生成するほどであり、多線形マップ候補の基盤となる安全性仮定は繰り返し攻撃を受けてきました。格子ベースの iO 候補は仮定の頑健性という観点ではより優れていますが、実用化にはほど遠い状況です。
パート I は、構成の内部詳細よりも定義の全体像と動機付けに焦点を当てています。記述は技術的に正確であり、現時点での実現可能性を過大評価することはありません。ブロックチェーン応用（難読化プログラムとしてのスマートコントラクト、トラステッドセットアップ不要のトラストレスエスクロー）との関連についても言及されていますが、過度に強調はされていません。
応用暗号やゼロ知識システムを扱う方にとって、iO がプリミティブの階層においてどのような位置づけにあるかを理解することは、実装しない場合でも真に有用な背景知識となります。
Source: https://vitalik.eth.limo/general/2026/06/29/obfuscation1.html
非対称量子化：97%のストレージ削減でほぼ無損失な検索を実現
核心となる観察は、検索においてクエリと文書が非対称な役割を担うという点です。文書はインデックス作成時に格納され、何百万回も検索対象となります。一方、クエリは実行時に生成され、一度しか使用されません。この非対称性により、文書 embedding を積極的に量子化する一方で、推論時はクエリ embedding をフル精度（float32 または bfloat16）のまま維持することが正当化されます。
本手法では、文書ベクトルを1次元あたり1ビット（バイナリ量子化）または2ビットに量子化した上で、精度損失を非対称的に補償します。クエリ側はフル精度を保持し、類似度計算が調整されます。内積類似度においては、バイナリ文書ベクトル b \in \{-1,+1\}^d とフル精度クエリ q \in \mathbb{R}^d の相互作用は \text{sim}(q, b) = q^\top b で表され、閾値処理後に popcount ベースの内積として計算されます。重要な洞察は、検索品質が主に両側を量子化した場合に劣化するという点であり、片側をフル精度に保つことで損失の大部分を回復できます。
Mixedbread の報告によると、1ビット文書量子化とフル精度クエリを組み合わせた場合、BEIR 上の NDCG@10 は float32 ベースラインと比較して絶対値で約1〜2ポイントの低下にとどまる一方、ストレージは32倍削減されます（float32 から1ビットへ）。主張されている97%削減は、量子化と次元削減を組み合わせた結果です。また、内積推定値の期待二乗誤差を最小化するよう量子化ベクトルを再スケーリングするキャリブレーションステップについても説明されており、これは次元ごとに適用される標準的なスカラー量子化理論に基づいています。
制限事項として、本アプローチは embedding モデル固有のものであること（キャリブレーション統計は代表的なコーパス上で計算される）、得られる利益がコーパスの分布に依存すること、そして意味的内容が疎な極めて短い文書は積極的な量子化によって長い文書よりも多くの情報を失うことが挙げられます。非対称的なフレームワーク自体は新しいものではなく（Faiss は長年にわたり非対称距離計算をサポートしています）、しかし現代の dense retriever に慎重に適用し、標準ベンチマーク上の数値を報告している点は有用です。
Source: https://www.mixedbread.com/blog/asymmetric-quant
ゼロ知識証明技術をオープン化して年齢確認におけるプライバシーを促進する
Googleは、Periodic Unlinkable Disclosure（PUD）プロトコルの実装をオープンソース化しました。このプロトコルはゼロ知識証明を用いて、ユーザーが生年月日やリンク可能な識別子を一切開示することなく、年齢閾値（例：「私は18歳以上です」）を証明できるようにするものです。暗号理論的なコアは署名ベースのZKPです。クレデンシャル発行者が年齢属性に署名し、ユーザーはその属性値や署名自体を明かすことなく、当該属性へのコミットメントに対する有効な署名の知識を証明します。
本スキームはBBS+署名（またはその変種）を使用しており、メッセージのベクトルに対する署名の知識のZK proofsを効率的にサポートします。「Periodic Unlinkable」という特性は、ある時間ウィンドウ内において、同一クレデンシャルの連続的な提示が互いにリンク不可能なproofsを生成することを意味します。発行者と共謀したとしても、verifierは二つの提示を相関付けることができません。これは、固定されたnullifierではなく、各proofを新鮮なランダム性と時間エポックに紐付けることで実現されます。
このオープンソース化が重要な理由は、年齢確認が複数の法域で法的に義務化されつつあり、現在主流のアプローチ（書類のアップロード、クレジットカード確認）が機密性の高い個人識別情報（PII）の保存または送信を伴うからです。暗号理論的に健全であり、第三者による監査が可能なZKPアプローチは、プロプライエタリなブラックボックス型ソリューションと比較して実質的な改善と言えます。
技術的に注意すべき点としては、脅威モデルが依然として信頼されたクレデンシャル発行者（政府または文書認証機関）を必要とすること、ZKPはプレゼンテーション層を保護するのみであり発行プロセスは対象外であること、デバイス binding とrevocationは未解決のエンジニアリング課題として残っていることが挙げられます。このライブラリはGoで実装されており、Android Identity Credential APIとの統合を想定して設計されています。
SQLiteデータベースファイルを破損させる方法
これはSQLite公式ドキュメントによる破損の原因となるベクターの解説であり、見た目以上に有用です。SQLiteがI/Oスタックに対して持つ前提条件を正確に列挙しており、それらの前提が破られた際に、エラーではなく無音のデータ破損が生じる箇所を明示しています。
主なカテゴリは以下のとおりです。(1) 不完全な書き込み — SQLiteは、電源喪失後にセクターへの書き込みが完全に完了するかまったく行われないかのいずれかであることを要求します。永続メディアへのフラッシュ前に成功を報告するファイルシステムやストレージコントローラーはこれに違反します。(2) 書き込み順序の乱れ — WAL（write-ahead log）プロトコルは、メインデータベースが変更される前にジャーナルが永続化されていることを前提としています。OSが書き込みを並べ替えると、アトミック性が失われます。(3) ファイルロックの失敗 — ネットワークファイルシステム（NFS、SMB）では、アドバイザリロックが信頼できないか、あるいは無音で無視されることがあり、複数のライターが競合を検出しないままファイルを破損させる可能性があります。(4) 部分的なセクター書き込み — 512バイトのアトミック書き込み粒度を持つドライブ上での4096バイトページへのtorn writeにより、ページが半分だけ書き込まれた状態になる可能性があります。(5) ファイルシステムのバグ — ext3における特定の既知のバグ（fsynが必ずしもディレクトリエントリの永続性を保証しない問題など）やその他のバグがバージョン番号とともに挙げられています。
このドキュメントはAPIの誤用についても言及しており、同一接続に対して複数スレッドからシリアライズなしにsqlite3_execを呼び出すケースや、プリペアドステートメントが生存中にデータベースをクローズするケースが取り上げられています。
システムエンジニアにとってこれが価値を持つのは、各破損モードがストレージスタック上の特定の不変条件に対応付けられているためです。これにより、自身のデプロイ環境（クラウドブロックストレージ、コンテナ化されたoverlayfs、ネットワークマウントされたボリュームなど）がSQLiteのドキュメントに記載された要件を満たしているかどうかを監査できます。一般的な構成のいくつかに対する答えは「必ずしも満たしていない」というものです。
Source: https://www.sqlite.org/howtocorrupt.html
Kubernetes 1.36 における kubelet メモリリークの修正
この記事は、Kubernetes 1.36 で導入された kubelet の実際の本番環境におけるメモリリークを、pprof によるヒーププロファイリングで発見した経緯を記録したものです。リークは podResourcesServer コンポーネントに存在し、このコンポーネントはデバイスプラグインがポッドごとのリソース割り当て（GPU、FPGA など）を照会するために使用する PodResources gRPC API を提供しています。
根本原因: ContainerDevices オブジェクトのキャッシュが gRPC 呼び出しのたびに蓄積されるにもかかわらず、一切削除されない仕組みになっていました。キャッシュキーにはポッド UID とコンテナ名が含まれており、削除イベント発火時に起動する退避パス（ポッド削除をトリガーとする）には、削除イベントが発火した後にキャッシュエントリが蓄積されてしまうというレースコンディションがありました。CI/CD ランナー、バッチジョブ、スポットインスタンスノードなど、ポッドの入れ替わりが激しいクラスターでは、完了した各ポッドが孤立したキャッシュエントリを残すため、際限なく増加し続けるという問題が生じていました。
修正方法は、イベントの順序に依存するのではなく、kubelet の既存のポッドライフサイクルリコンサイラー上で実行するファイナライザースタイルのクリーンアップを追加することでした。ヒーッププロファイルでは、メタデータではなく ContainerDevices 構造体そのものが支配的なアロケーションとして示されており、これによりログやメトリクスサブシステムではなくキャッシュへと調査の方向が絞られました。
デバッグの方法論も注目に値します。著者は kubectl exec を使用して kubelet の pprof エンドポイント（デフォルトでは localhost:10248 で公開）にアクセスし、一定の時間ウィンドウ内でヒープスナップショットを比較した上で、go tool pprof の list コマンドを使ってソース内のアロケーションサイトと照合しました。これは標準的な Go のメモリデバッグ手法ですが、ウォークスルーが具体的である点が特徴です。
この修正はアップストリームにマージされました。GPU ワークロードやポッドの入れ替わりが激しい 1.36 を実行しているクラスターは、複数日にわたるウィンドウで kubelet の RSS 増加を canary として確認することを推奨します。
Source: https://heyoncall.com/blog/fixing-kubernetes-kubelet-memory-leak
完全なClickHouse OLAPエンジンをWebAssemblyにコンパイル
chDBはClickHouseの組み込み可能バージョンで、プロセス内で動作します。このデプロイメントでは、サーバーバックエンドなしにブラウザ上で動作するよう、chDBを完全にWebAssemblyにコンパイルしています。ClickHouseのクエリ実行パイプライン全体——カラム型ストレージエンジン、ベクトル化された式評価、MergeTreeインデックス、集約関数——がWASMを通じてクライアントサイドで実行されます。
エンジニアリング上の制約は重大です。ClickHouseのコアはC++で書かれており、文字列操作、ハッシュ集約、圧縮のためにSIMDインtrinsic（SSE4.2、AVX2）を多用しています。WASMのSIMDサポートは128ビットのみ（fixed-width SIMDプロポーザル経由）であるため、SIMDパスは無効化されるか書き直されます。ビルドはEmscriptenで-msimd128フラグを使用しますが、AVX2パスを直接使用することはできません。メモリはWASMのリニアメモリモデルに制限されており（memory64プロポーザルがまだ普遍的に利用可能でないため、現在はほとんどのブラウザで最大4 GB）、クエリのワーキングセットが制約されます。
データの読み込みは、ブラウザのローカルファイルシステムからFile System Access APIを介してParquetまたはCSVファイルをWASMメモリに転送することで処理され、ClickHouseがそこでパースとクエリを行います。デモでは、データがブラウザの外に一切出ることなくローカルファイルに対してインタラクティブなSQLを実行できることを示しており、これがプライバシーを重視する分析においての魅力的なユースケースです。
圧縮後のバイナリサイズは約30〜40 MBで、大きいとはいえ初回読み込み時の一度限りとして許容範囲内です。デモデータセットでのクエリレイテンシは、ネットワークのラウンドトリップがないため、小〜中規模のデータにおいてサーバーサイドのClickHouseと競争力があります。
現時点での制限事項：セッションをまたいだ永続ストレージなし（IndexedDBとの統合は未実装）、メモリ上限によりマルチギガバイトのデータセットは非現実的、そしてスレッディングモデルがSharedArrayBufferを使用するため、すべてのホスティング環境が提供するわけではない特定のCOOP/COEPのHTTPヘッダーが必要です。
Source: https://wasm.chdb.io/
Asahi Linux 7.1 進捗レポート
Asahi Linux 7.1 レポートは、今サイクルで実装または成熟した Apple Silicon 機能をサポートするために必要なカーネルドライバの作業を取り上げており、M4 シリーズチップ（M4、M4 Pro、M4 Max、M4 Ultra）に焦点を当てています。
最も技術的に密度の高いセクションでは、AGX GPU ドライバ（Apple の GPU 向け DRM ドライバ、drm/asahi）について説明しています。Apple は M4 においてファームウェアインターフェースを変更し、コマンドサブミッションパスの更新が必要となりました。具体的には、compute コマンド構造に新しいフィールドが追加され、vertex/fragment パイプラインのスケジューリングセマンティクスが変更されました。このドライバは Rust で記述されており、レポートでは DRM 向けの Rust-for-Linux 抽象化に新しいサブミッションモデルをサポートするための追加が必要だったと述べています。
ディスプレイコントローラの作業（DCPext）も注目に値します。M4 Pro および Max は独立したディスプレイコントローラダイを持ち、M1〜M3 で使用されていた内部ファブリックではなく PCIe 経由で AP と通信します。これにより、DCP（Display Controller Processor）ドライバに新しいトランスポート層が必要となりました。DCP は Apple 独自のファームウェアを実行するコプロセッサであり、Linux ドライバは RTKit IPC プロトコルをリバースエンジニアリングしてこれを制御します。
M4 Ultra（2 つの M4 Max ダイをタイリングしたもの）での CPU 周波数スケーリングは、2 つのダイが独立した周波数で動作できるため、ダイごとの P-state 管理が必要でした。既存の cpufreq ドライバはチップごとに単一の周波数ドメインを前提としていました。
ニューラルエンジンおよびメディアエンコード／デコードブロックは未サポートのままです。これらには追加のファームウェアリバースエンジニアリングが必要です。レポート内のステータステーブルは、ハードウェア機能とドライバステータスを正確に対応付けたマトリックスであり、文章による要約よりも有益な情報を提供しています。
注目の新規リポジトリ
john-rocky/coreai-model-zoo
AppleのCore AIスタック（iOS/macOS 26以降）をターゲットとした、コミュニティメンテナンス型のmodel zooおよびナレッジベースです。本プロジェクトは、Qwen3.5およびGemma 4向けのエンドツーエンド変換パイプラインを提供しており、GPU・Apple Neural Engine（ANE）の両方に対してiPhone 17 Proハードウェア上での動作が検証されています。モデルの重みにとどまらず、このリポジトリは実践者がはまりがちな変換上の落とし穴も文書化しています。具体的には、quantizationのエッジケース、Core MLにおけるオペレータカバレッジのギャップ、活性化関数のリマッピングなどが挙げられます。また、ネイティブで加速されないオペレーション向けにカスタムのMetal Performance Shadersカーネルも含まれています。Swiftランナーは最小限のinferenceハーネスを提供しており、コントリビューターはXcodeプロジェクトをゼロから構築することなく、デバイス上で直接ベンチマークを実行できます。
「ナレッジベース」コンポーネントはおそらくより高い価値を持つ成果物です。どのモデルファミリーがcoremltools → ANEパイプラインを許容可能な精度劣化で乗り越えられるか、またどれがCPU/GPUへのフォールバックを必要とするかが体系的にまとめられています。Appleの内部ツールにアクセスできない環境でAppleシリコン上のオンデバイスinferenceを実装しようとしている方にとって、公式ドキュメントがほとんど空白のままにしているドキュメントの空白を実質的に埋めるものです。本番アプリをデプロイする実践者にとっても、エッジinferenceのベンチマークを行う研究者にとっても有益なリソースです。
Source: https://github.com/john-rocky/coreai-model-zoo
raiyanyahya/recall
Recallは、Claude Codeにおけるステートレスセッション問題を解決します。新しいターミナルセッションを起動するたびにプロジェクトのコンテキストがすべて失われ、毎回説明をやり直す必要が生じるという問題です。Recallはそのコンテキストを構造化されたプレーンテキストファイルとしてローカルに永続化します。クラウドも、外部サービスも、リモートのメモリストアへのトークンのやり取りも不要です。実装は完全にオフラインで動作し、状態はディスク上にClaude Codeがセッション開始時にcontext windowを通じて読み込める形式で保存されます。アーキテクチャ的には、ベクトルストアベースのメモリシステムよりもシンプルです。embedding、検索ランキング、近似最近傍インデックスはいずれも存在しません。そのトレードオフとして、Recallはプロジェクトの複雑さに対して線形にスケールし、準線形にはなりません。そのため、非常に大規模なプロジェクトでは最終的にcontext windowの制限に達する可能性があります。この手法の価値は、インフラが不要なセットアップにあります。一度インストールするだけで、既存のClaude Codeワークフローに永続的なメモリ機能を追加できます。後述するbrain.mdと比較すると、Recallは意思決定や制約の記録よりもセッションレベルの継続性を主な目的としているように見えますが、その境界は曖昧です。サイドカーサービスを運用せずに永続性を求めるソロ開発者に適しています。
Source: https://github.com/raiyanyahya/recall
gykim80/perfectpixel-studio
テキストプロンプトからゲームに即使用可能なキャラクタースプライトシートを生成するデスクトップアプリケーションです。2D RPGやストラテジーゲームで一般的な、8方向・複数アクション形式を対象としています。スタックはWails（Goバックエンド + Reactフロントエンドを単一のネイティブバイナリにコンパイル）を採用しており、クロスプラットフォーム開発ツールでよく見られるElectronのメモリオーバーヘッドを回避しています。生成パイプラインは単一のプロンプトを受け取り、方向角（N、NE、E、SE、S、SW、W、NW）に渡って100以上のアクションカテゴリ（idle、walk、attack、deathなど）のスプライットバリアントを生成し、全マトリックスにわたって視覚的な一貫性を維持します。これだけ多くのフレームにわたる一貫性の確保は技術的に困難な部分であり、単純なフレームごとの生成ではキャラクターのアイデンティティが一貫しない結果になります。リポジトリの公開ドキュメントには一貫性確保のメカニズムに関する実装の詳細が記載されていないため、ControlNet スタイルのconditioning、参照画像のinpainting、あるいはカスタムfine-tunedモデルのいずれを使用しているかは、リポジトリのみからは判断できません。出力はUnity、Godot、またはRPGMakerにインポート可能な標準スプライトシートレイアウトを対象としています。ピクセルアーティストを持たないインディー開発者にとって、このツールは実際のプロダクション上のボトルネックを解消するものです。
Source: https://github.com/gykim80/perfectpixel-studio
mindmuxai/brain.md
brain.md は、コーディングエージェント向けのファイルベースかつバージョン管理に親和性の高いメモリレイヤーです。基本的な考え方は、プロジェクトごとに brain.md という単一のMarkdownファイルを用意し、Claude CodeやOpenAI Codexといったエージェントがセッションをまたいで尊重すべき永続的な決定事項・アーキテクチャ上の制約・要件を蓄積していくというものです。CLIはゼロ依存（npmパッケージツリーもPython virtualenvも不要）で動作し、構造化されたMarkdownセクションへの読み書きによって機能します。主要な設計上の洞察は、Markdownはすでにあらゆる主要コーディングエージェントのcontext windowに収まる形式であるため、検索レイヤーが不要という点です。エージェントはファイルを直接読み込みます。これは生のセッションログ（recall）よりも意味的に豊かです。なぜなら、キュレーションされており人間が編集可能であるため、開発者は「何が決定されたか」だけでなく「なぜその決定がなされたか」を注記できるからです。制限としては、手動キュレーションのオーバーヘッドがあり、エージェントや人間が明示的に書き込まない限りファイルは自動更新されません。ベクターストアのメモリシステムと比較するとセマンティック検索がないため、セッションのたびにファイル全体がcontextに入ることになり、決定事項の履歴が非常に大きくなるケースには適しません。制約セットが限定的かつ安定しているプロジェクトに最も向いています。
Source: https://github.com/mindmuxai/brain.md
sums001/Windows-Copilot-API
このリポジトリはWindows Copilotクライアントのプロトコルをリバースエンジニアリングし、OpenAI互換のREST APIとして公開することで、APIキーや課金アカウントなしにGPT-4およびGPT-5モデルへアクセスできるようにするものです。インターフェースはOpenAIの /v1/chat/completions スキーマを模倣しているため、既存のOpenAI SDK統合はベースURLを変更するだけで利用可能です。実装はWindows Copilotデスクトップクライアントからインターセプトしたセッショントークンに依存しており、認証済みのWindowsセッションが必要であり、クライアント側のプロトコル変更やサーバー側のボット検知に対して構造的に脆弱です。実際のレート制限はこのプロキシではなくMicrosoftのバックエンドによって適用されるため、レート制限に関するドキュメントは存在しません。法的立場は曖昧であり、有料サービスを無償で利用するという点で、他の「フリーティア抽出」プロキシと同じカテゴリに位置づけられます。技術的に興味深い成果物はプロトコルのリバースエンジニアリング作業そのものであり、リクエスト署名、セッショントークンのライフサイクル、レスポンスストリーミングフォーマットが含まれます。APIサーフェスを調査したい研究者やOpenAIへの直接アクセスができない地域の開発者にとっては機能的なインターフェースを提供しますが、本番環境での利用は推奨できません。
Source: https://github.com/sums001/Windows-Copilot-API
lidge-jun/opencodex
OpenCodexは、OpenAI Codex CLI/App/SDKと任意のLLMバックエンドの間に位置するプロバイダープロキシであり、任意のOpenAI互換エンドポイントがCodexツールを提供できるようにリクエストを変換します。実用上の動機として、Codex CLIがOpenAIのエンドポイントおよびモデルファミリーに関する前提をハードコードしているという点が挙げられます。opencodexはそれらの前提をルーティングレイヤーの背後に抽象化します。サポートされているバックエンドには、Ollamaを介したローカルモデル、Anthropic Claude、およびその他のOpenAI互換APIが含まれます。このプロキシはリクエスト・レスポンスのスキーマ正規化を処理しており、プロバイダーをまたいだtool-callのフォーマットの差異も含まれます。これは、単純なベースURL置換の多くが失敗するポイントです。Codexのエージェント的なファイル編集やシェル実行機能を利用したいが、データ保管場所やコストの観点からセルフホスト型モデルを経由する必要があるチームにとって、これは直接的な解決策となります。アーキテクチャはSDKラッパーではなく軽量なHTTPプロキシであるため、言語に依存しません。つまり、PythonのSDK、NodeのSDK、生のHTTPのいずれを使用するかにかかわらず、あらゆるCodexクライアントが動作します。Codexのプロトコルが急速に進化していることを考えると、メンテナンスリスクは高い状態です。
Source: https://github.com/lidge-jun/opencodex
aresyn/codex-control-plane-mcp
Codex Desktopのタスクは本質的にエフェメラルです。ウィンドウを閉じればタスクの状態も失われます。このリポジトリは、Model Context Protocol（MCP）を介してCodex Desktop上に永続的なコントロールプレーンを実装し、長時間実行されるエージェントタスクがセッション中断後も存続し、外部から監視・再開できるようにします。MCPサーバーは、タスクのライフサイクル操作（作成・一時停止・再開・検査・キャンセル）をMCP tool callとして公開しており、MCP互換クライアント（Claude Desktop、カスタムエージェントなど）から呼び出せます。永続性は、プロセス内メモリに依存するのではなく、Codex Desktopとのインタラクションの間にタスク状態をディスクに保存することで実現しています。コントロールプレーンパターンは分散システムの標準的な設計手法であり、それをシングルノードのデスクトップエージェント環境に適用したものです。タスクの定義と状態を実行環境から分離することで、実行エンジンがクラッシュして再起動しても作業を失わずに済みます。これは、Codexが大量のファイル操作を行う必要があり、開発者がアプリケーションをフォアグラウンドに保ち続けられない数時間に及ぶコーディングタスクに対して実用的に役立ちます。MCPインターフェースはチェーニングも可能にします。オーケストレーションエージェントがCodexのサブタスクを生成し、その完了をプログラム的に待機できます。
Source: https://github.com/aresyn/codex-control-plane-mcp
agentteamhq/agentteam-email
AgentTeam-emailは、人間のユーザーではなくAIエージェントのために設計されたオープンソースのメールインフラを提供します。標準的なメールライブラリは、インタラクティブな認証フロー、人間が読めるエラーハンドリング、低メッセージ量を前提としていますが、これらはいずれもエージェントの使用パターンとは一致しません。本プロジェクトはその逆を目指しています：プログラマティックな認証、構造化されたエラーサーフェス、高スループットの送受信、そしてエージェントパイプラインに直接フィードするwebhook駆動のインバウンド処理です。アーキテクチャは、SMTP/IMAPをエージェントフレンドリーなAPIレイヤーでラップし、メールボックスのポーリングループ、構造化された添付ファイルのパース、返信チェーンのスレッディングなどのプリミティブを追加しており、エージェントが独自のパースロジックを必要とせずに利用できます。インバウンドメールをエージェントのトリガーとして活用するパターンは十分に活用されていません：ほとんどのエージェントフレームワークはツールコールとREST webhookに注目していますが、メールはエンタープライズワークフローにおける主要なインテグレーションサーフェスであり続けています。オープンソースとして提供されている点は、マネージドトランザクションメールサービス（SendGrid、Postmark）との差別化要因となっており、オペレーターにルーティング、ストレージ、エージェントインテグレーションレイヤーに対する完全な制御を提供します。承認フロー、通知ハンドリング、顧客コミュニケーションの自動化など、メール駆動のビジネスプロセスに参加するエージェントを構築するすべての方に関連します。