デイリーAIダイジェスト — 2026-07-15

公開

2026年7月15日

English · 日本語

arXiv ハイライト

Read It Back: Pretrained MLLMs Are Zero-Shot Reward Models for Text-to-Image Generation

問題設定

text-to-imageのRL向けreward modelingには、通常、preference data（ImageReward/HPSのようなスカラーreward headを学習するため）か、脆弱なpromptingパイプライン（MLLM-as-judge scoring、あるいはVQA分解によるアトミックなyes/no質問）のどちらかが必要です。スカラースコアリングはjudgeのキャリブレーションに敏感であり、離散化ノイズを生じさせます。VQA分解は二段階パイプラインをもたらし、その品質は質問生成と回答集約に依存します。どちらのアプローチも、生成目的から意味的に遠い水準に位置しています。

SpectraRewardは、MLLMが事前学習時に用いたものと同じlikelihood目的関数を再利用するtraining-freeなrewardを提案します。すなわち、生成された画像が与えられたとき、MLLMは元のpromptをどれだけうまくtoken-by-tokenで予測できるか、というものです。

手法

G_\thetaをprompt x=(x_1,\dots,x_T)に対してy \sim G_\theta(\cdot \mid x)を生成するT2I policyとし、\mathcal{M}をfreezeされた事前学習済みMLLMとします。SpectraRewardはyをvisual contextとして入力し、xに対して単一のteacher-forced forward passを実行します：

R_{\mathcal{M}}(x,y) = \frac{1}{T-1}\sum_{t=1}^{T-1} \log p_{\mathcal{M}}(x_{t+1} \mid x_{\leq t}, y).

これは画像条件付きprompt log-likelihoodの平均であり、scoringのためのpromptも、chain-of-thoughtも、分解も必要ありません。per-token log-likelihoodは、著者らが「semantic spectrum」と呼ぶペア(x,y)の分布を形成します。これはpromptのどの部分が実際に画像に根拠付けられているかを示す、prompt tokenにわたる分布です。

MLLMベースのreward関数の比較：スカラースコアリング、VQA分解、SpectraReward、Self-SpectraReward。

この設計には二つの帰結があります。第一に、MLLM事前学習の目的関数（image tokenに条件付けられたnext-token prediction）を直接活用することで、モデルが学習された方法とjudgeとして問い合わせられる方法との間のdistribution shiftを回避します。第二に、rewardはtoken単位の総和であるため、visual contentに対するrewardのgradientは意味的に重要なtokenに集中します。Figure 3はこれを具体的に示しています：物体の「three」を「two」に置き換えると「Two」tokenのlog-likelihoodが急激に低下し、ギターを椅子に置き換えると「guitar」のlog-likelihoodが低下します。つまり、誤りはcaption全体に広がるのではなく、不一致なtokenに局在化されます。

Token-level semantic sensitivity：属性および同一性の誤りが、それらが矛盾する特定のtokenのlog-likelihoodを低下させる様子。

Self-SpectraReward。 policyが理解と生成の両ブランチを持つ統一マルチモーダルモデル（例：BAGEL）である場合、同一モデルの理解ブランチが\mathcal{M}として機能できます。これにより外部reward modelが不要になり、さらに重要なことに、rewardのsemantic representationをpolicy自身のそれと整合させます。つまりgeneratorは、自身の理解ブランチがエンコードするalignmentそのものに対して最適化されます。結果として、preference labelも、外部reward MLLMも、外部knowledge distillationも必要としない、クローズドループな自己改善セットアップが実現します。

実験設定

policyはBAGEL（AR-Diffusion統一マルチモーダルモデル）です。RLアルゴリズムはAWM（三つのRLアルゴリズムのablationを経て選択）です。SpectraRewardはデフォルトでQwen3-VL-30B-A3Bをfreeze済みscorerとして使用し、Self-SpectraRewardはBAGELの理解ブランチを使用します。

学習条件：512×512で16 diffusion sampling steps、gradient計算のために最初の10 denoising stepsから6 stochasticステップをサンプリング、32 promptsのバッチ、group size G=16、CFG scale 4、timestep shift 3、lr 1e-4、32×A100、380 total steps、AlphaGRPO20kのpromptを使用。

概要：SpectraRewardのsemantic spectrum、RL学習曲線、MLLMバックボーンのsweep。

評価は、2つのdiffusionモデル、3つのRLアルゴリズム、4つのファミリー（4B〜235Bパラメータ）から9つのreward MLLMバックボーン、5つのOOD T2I benchmarkにわたります。このsweepは、rewardの有用性が特定のバックボーンの産物なのか、それとも事前学習済みMLLMの一般的な性質なのかを検証するよう設計されています。

結果

本論文の主要な知見は、キャリブレーションも、prompt engineeringも、reward-modelのfine-tuningも行わずにprompt log-likelihoodをそのまま用いることで、テストした9つのMLLMバックボーン（4Bから235B）と両diffusion policyにわたって使用可能でOODに対してロバストなrewardが得られるという点です。Self-SpectraRewardは外部MLLMrewardを用いた場合と同等かそれ以上の性能を示しており、policyの理解ブランチが十分（かつより良く整合した）criticであることを示しています。Token-levelのsensitivityプロット（Figure 3）は、rewardが粗い画像-テスト類似度の水準ではなく、特定の属性および同一性の誤りのレベルで識別的であることを確認しています。

限界とオープンな課題

  • このrewardはMLLM自身のgroundingに縛られています。MLLMが体系的に誤認識する物体、属性、関係はrewardのブラインドスポットになります。稀な組み合わせや細粒度のカテゴリが自然な失敗モードです。
  • prompt tokenにわたる平均化は機能語とcontent wordを等しく重み付けします。semantic spectrumはおそらく再重み付け（例：TF-IDFやcontent-tokenマスクによる）が可能ですが、本論文では一様平均を使用しています。
  • 特定のMLLMのgroundingバイアスに対するreward hackingは排除されていません。クローズドループのSelf-SpectraRewardセットアップは原理的に特に脆弱であり、generatorが自身の理解ブランチの特異性を利用できる可能性があります。
  • prompt長Tはrewardの分散に影響し、prompt間の比較可能性にも影響する可能性があります。T-1による正規化は有効ですが、この問題を完全には解決しません。
  • promptに対するteacher-forced forward passはVQA分解と比べて安価ですが、30B〜235BのrewardスケールではRLステップコストを依然として支配します。

なぜこれが重要か

MLLMの事前学習likelihoodをrewardとして再利用することは、既存のvision-language能力をimage生成のためのRL signalに変換する最も直接的な方法であり、T2I RLを制約してきたpreference dataのボトルネックを解消します。統一モデルが理解ブランチを通じて自身の生成物を批評するSelf-SpectraRewardの変種は、外部の監督なしに統一マルチモーダルアーキテクチャのためのクリーンな自己改善ループを指し示しています。

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

深層強化学習の評価・設計パラダイムに関する原則的分析

問題設定

サンプル効率の高い深層RLに関する多くの研究（DrQ、OTR、DER、CURL、SimPLE、EfficientZero）は、新手法を200Mフレーム領域における最先端アルゴリズム、特にRainbowおよびその分布的価値コンポーネント（C51、IQN、QR-DQN）と比較してベンチマークを行っています。暗黙の仮定は単調性です：アルゴリズム A が漸近的に B を支配するならば、100Kフレーム領域でも A を打ち破るべき適切なベースラインであるべきだというものです。本論文は、この仮定が誤りであることを理論的・実験的の両面から主張し、その結果生じた比較が、低データ領域において実際にどのアルゴリズム的アイデアが有効であるかについて誤った結論を生み出してきたと論じます。

理論的議論

理論的核心は、\mathcal{Q}_t(\theta_t)(s,a) = \phi_t(s,a)^\top \theta_t を用いた有限ホライズンMDP \langle S, A, \mathcal{P}, \mathcal{R}, \mathcal{H}\rangle に対する線形関数近似の設定で展開されます。Zanette et al. (2020) に基づき、達成可能なregretは

\textsc{Regret}(\mathcal{K}) = \tilde{O}\!\left(\sum_{t=1}^{\mathcal{H}} d_t \sqrt{\mathcal{K}} + \sum_{t=1}^{\mathcal{H}} d_t \sqrt{\mathcal{I}\mathcal{K}}\right),

であり、regretはステップごとの特徴次元数 d_t に依存します。これは価値表現の本質的な容量の代理指標です。平均ではなく収益の分布というより豊かな対象をパラメータ化するアルゴリズムは d_t を増加させ、その豊かな表現が最終的には有益であるとしても、低 \mathcal{K} 領域においてはより多くのregretを払うことになります。

第4節では、この議論を行動ランキングに関する命題に精緻化しています。命題4.1は、2つの行動が \mathbb{E}[\mathcal{Z}(s,a)] = \mathbb{E}[\mathcal{Z}(s,\hat a)] + \epsilon を満たす場合、d_{TV}(\mathcal{Y}, \mathcal{Z}(s,a)) \le \epsilon かつ \mathbb{E}[\mathcal{Y}] \le \mathbb{E}[\mathcal{Z}(s,\hat a)] を満たす \mathcal{Y} が存在することを示しています。すなわち、学習された収益分布における \epsilon の全変動誤差でgreedy順序を逆転させるのに十分です。標準的な離散分布推定と組み合わせると、サイズ k の固定サポートを持つC51は \Theta(k/\epsilon^2) サンプルを必要とします。命題4.2はこれを未知サポートの推定器（QR-DQN、\mathcal{Z}(s,a) = \frac{1}{\mathcal{N}} \sum_{i=1}^{\mathcal{N}} \delta_{\theta_i(s,a)} をモデル化するIQN）に拡張し、厳密に大きなサンプル複雑度を示しています。要点は、分布的手法を漸近的に魅力的にする特徴（学習されたサポート、分位点の柔軟性）こそが、データが少ない場合に性能を悪化させるということです。なぜなら、policy improvementのボトルネックは \mathcal{Z} の裾を当てはめることではなく、行動ランキングを正しく得ることにあるからです。

実験結果

実験は、低データ領域の100Kインタラクションと高データ領域の200Mフレームの両方でALE上で実施され、プレーンなベースラインとしてdueling DQN（Wang et al., 2016）、高容量の分布的手法としてC51、QR-DQN、IQNを使用しています。

ALEにおけるスケーリング則：データ領域ごとのベースラインの挙動と各領域でのregret。

図1はスケーリング則の中心的な図です：高データ領域でのランキングは低データ領域には引き継がれず、分布的手法とduelingの間のregretギャップは2つの領域間で逆転しています。図3のゲームごとの学習曲線は、100Kインタラクションにおいて、Alien、Amidar、Asterix、BankHeist、ChopperCommand、Hero、CrazyClimber、JamesBond、Kangaroo、MsPacman、FrostBite、Qbert、RoadRunner、Seaquest、UpNDownにわたってこれを裏付けています。

dueling、C51、IQN、QR-DQNのゲームごとの100K学習曲線。

図2に示された集計された人間正規化統計量（中央値、平均、20パーセンタイル）は、100KではduelingがC51/IQN/QR-DQNを支配し、200Mでは順序が逆転することを示しています。

100K（上）および高データ領域（下）における人間正規化中央値、平均、20パーセンタイル。

最も注目すべき数値は：2016年のプレーンなdueling アーキテクチャが、100KにおけるDrQ^{\text{NeurIPS}} を人間正規化スコアで15%上回り、DrQ^{\text{ICLR}} との差が11%以内に収まっているという事実です。これは、duelingがサンプル効率のよいRL文献の比較対象に一切含まれていなかったにもかかわらずです。DrQ自体がdueling のバックボーンを分布的headなしで使用していることを踏まえると、「サンプル効率的な」手法の系列から報告されている利益の多くは、分布的Rainbow スタイルのベース上に提案メカニズム（augmentation、モデルベースのrollout、contrastive auxiliary）を追加することによるものではなく、容量を削減することに起因していることが示唆されます。

原則的な評価フレームワーク

第5節では5つのルールを成文化しています：(i) ランキングはデータ領域をまたいで非単調である；(ii) 単調性の仮定のもとで構築されたベンチマークは偏りがある；(iii) 核となる低容量アルゴリズム（例：dueling DQN）が比較対象に含まれなければならない；(iv) 領域をまたいだ挙動を予測するため、本質的容量と d_t を報告すべきである；(v) 単調性の仮定を引き継いでデータセットを構築すると、オフラインRLベンチマークに同じ偏りが持ち込まれる。

限界と未解決問題

理論は線形関数近似と非定常方策のもとで展開されており、regret boundの d_t の解釈を深層ネットワークに拡張することは証明によるものではなく類推によるものです。実験の範囲はDQNファミリーのエージェントによるALEに限定されており、同じ非単調性がactor-criticファミリー（PPO、SAC）や連続制御ベンチマークにも成立するかどうかはここでは検証されていません。また、分析はDrQ/DER/EfficientZeroの報告された利益がRainbowではなくduelingを再ベースラインとした場合にどの程度残存するかを定量化しておらず、特定のDrQ設定に対してギャップが縮小または逆転するということのみを示しています。

本研究の重要性

2016年のベースラインが「サンプル効率的なRL」として数百件の引用を積み重ねてきた手法を上回るとすれば、フィールドの評価プロトコルこそが、アルゴリズムではなく、報告された進歩の主要な源泉であるということになります。本論文は、メカニズム（分布的容量が行動ランキングのサンプル複雑度を悪化させる）と具体的な改善策（低容量のコアベースラインを含め、複数の領域にわたって報告する）の両方を提示しており、ALE-100Kや類似した低データスイートでベンチマークを行う研究者にとって直ちに実行可能なものです。

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

Know Before Fix: QA-Driven Repository Knowledge Acquisition for Software Issue Resolution

問題設定

リポジトリレベルの issue 解決を目的とした LLM ベースのコーディングエージェント（例：SWE-bench）が失敗する主な原因は、推論能力の限界ではなく、リポジトリ内部の知識の欠如にあります。具体的には、モジュール間の依存関係、暗黙的な API 契約、データフローのセマンティクス、外部プロトコル制約などが挙げられます。著者らが引用した実証的な調査によれば、知識不足による軌跡は成功した軌跡に比べて約 4\times のトークンと 2\times のステップを消費します。既存の「修正前」手法（LocAgent、CoSIL、LingmaAgent、SWE-Debate）は修正主導型であり、issue のキーワードに基づいて疑わしいファイルや構造的なサマリーを提示しますが、エージェントが何を知らないかを明示的に特定することはありません。本論文では、これは誤った抽象化であると主張しており、エージェントには浅い局所化パスではなく診断パスが必要であると述べています。

動機付けとなるオラクル実験

著者らは、Mini-SWE-Agent + DeepSeek-V3.2 が失敗する SWE-bench Lite の 116 インスタンスに対してオラクルプローブを実行します。オラクル Questioner（issue と golden test patch を条件とする）が 1 つの質問を生成し、オラクル Answerer（golden ファイルのみが与えられる）がそれに回答し、QA ペアをエージェントに注入します。その結果、以前は失敗していた 116 インスタンスのうち 26 件が成功に転じました。これは使用する質問が 1 件かつ gold ファイルによるグラウンディングのみであるため下限値ですが、修正前の知識をターゲットを絞って与えることが不足しているものであり、より多くの局所化ではないことを示しています。

5 人の CS 大学院生による 116 件のオラクル質問の手動分析により、Questioner のテンプレートとなる 4 カテゴリの分類法が得られました。

  • Mechanism & Behavior（70.7%）：内部の制御・データフロー
  • Design & Usage（18.1%）：API 契約、規約
  • Locating & Structure（7.8%）：コードの所在
  • Ecosystem & Standards（3.4%）：外部ライブラリ・プロトコルの挙動

手法

ACQUIRE は、2 段階にわたる 3 つの専門化されたエージェントによって、知識獲得とパッチ適用を切り離します。

ACQUIRE の概要

issue \mathcal{I} と環境 \mathcal{E} が与えられた場合：

  1. Questioner は \mathcal{I} を N 個のターゲットを絞った質問 \{q_i\} に分解します。この際、4 カテゴリのテンプレートを活用することで、質問が冗長にならず互いに補完し合うようにします。
  2. Answerer — N 個の独立したインスタンスが並列に動作し、それぞれがリポジトリを自律的に探索（オラクルのファイルセットなし）して、証拠に基づいた a_i を生成します。これにより \mathcal{K} = \{(q_i, a_i)\}_{i=1}^N が得られます。
  3. Resolver は (\mathcal{I}, \mathcal{K}) を条件としてパッチを生成します。

並列化は実時間コストの観点で重要です。N 個の Answerer による探索は完全に並列化可能であり、LingmaAgent における MCTS トラバーサルや SWE-Debate における逐次的なデバッとは対照的です。

結果

2 種類のバックボーンを用いた SWE-bench Verified（500 インスタンス）における結果：

  • Mini-SWE-Agent ベースラインに対する Pass@1 の向上：GPT-5-mini で +3.8、DeepSeek-V3.2 で +4.4。ACQUIRE は両バックボーンにおいて最も高い性能を示す修正前手法です。
  • クロスモデルの頑健性：局所化のみのベースライン（LocAgent、CoSIL）は DeepSeek-V3.2 では改善しますが、GPT-5-mini では性能が低下します。これは、浅いポインタがセマンティクスの再構築をバックボーンに依存しているためです。ACQUIRE は両者で改善します。
  • よりリッチな文脈を持つベースラインとのコスト・時間比較：LingmaAgent と SWE-Debate は Pass@1 を改善しますが、エンドツーエンドの時間が 1.4〜5 \times、コストが 2〜14 \times かかります。ACQUIRE の修正前段階はこれらと比較して 2.5〜11 \times 高速かつ 5〜26 \times 安価でありながら、Pass@1 でも上回ります。
  • 素の Mini-SWE-Agent に対する絶対的なオーバーヘッド：GPT-5-mini / DeepSeek-V3.2 それぞれで、インスタンスあたり約 115 秒 / 約 227 秒および $0.030 / $0.018 の追加コスト。具体的には、GPT-5-mini はインスタンスあたり 187 秒 / $0.024 から 302 秒 / $0.054 へと増加します。

挙動および知識品質の分析

QA 注入あり・なしの 44 件の Fail → Pass インスタンスにおける軌跡のステージ構成

44 件の Fail\toPass インスタンスにおいて、QA 知識を注入すると軌跡の構成が変化します。盲目的な局所化や試行錯誤的な編集に費やす時間が減少し、再現と検証により多くの時間が割り当てられます。これは、エージェントが修正中にリポジトリの情報を再発見する必要がなくなったという主張と一致しています。

QA の信頼性に関する人手による監査では、「軽微な逸脱を伴うものの支持される」ペア（n=132）のうち、不完全さの内訳は次のとおりです：局所的な参照・詳細の不正確さ（67.9%）— 説明は正しいが行の範囲や関数の帰属がずれている；証拠範囲の逸脱（24.6%）— Answerer が取得可能な証拠を超えて意図やエコシステムの挙動について推測している；実装境界の過度な一般化（7.5%）— メカニズムは正しいが、分岐やエッジケースの処理が誤っている。注目すべきは、主要な失敗モードが誤った結論ではなく、根拠のない精度の高さであることです。

QA ペア数を変化させた場合の Pass@1 とインスタンスあたりの平均コスト

Pass@1 は N の増加とともに上昇した後、頭打ちになります。一方でコストはほぼ線形に増加します。これは、カテゴリ分類法が適度な N でカバレッジを飽和させ、追加の質問は大部分が冗長になることを示唆しています。

限界と今後の課題

  • 言語の適用範囲：プロンプトと分類法は Python 向けに特化しており、API 契約に関する質問が支配的な静的型付け言語では分類法の比率（70.7% が Mechanism & Behavior）が変わる可能性があります。
  • 分類法の出所：4 カテゴリは SWE-bench Lite の 116 件のオラクル質問から導出されています。ベンチマーク外でどこまで一般化できるか、また Ecosystem & Standards カテゴリ（3.4%）が SWE-bench の issue の外部接触面が狭いためにアンダーサンプリングされているかどうかは不明です。
  • Answerer の幻覚リスク：軽微な逸脱の 24.6% が証拠範囲の逸脱であり、回答を取得済みのコードスパンに結び付ける明示的なグラウンディング制約は存在しません。
  • Resolver の能力との相互作用：得られた改善は Resolver として Mini-SWE-Agent を使用した場合のものです。より強力な修正エージェント（例：ツールコールを備えた SWE-agent）が依然として外部 QA から恩恵を受けるか、あるいは獲得ステップを内包してしまうかについては評価されていません。
  • テスト駆動のリーク risk：Pass@1 による SWE-bench Verified の評価はテストへの過適合の影響を受けやすく、著者らはこれを指摘していますが、隠しテストによる評価は行っていません。

なぜ重要か

ACQUIRE は、修正前のリポジトリ探索を「バグのあるファイルを見つける」から「issue だけではエージェントが答えられない診断的な質問に答える」へと再定義し、小規模でカテゴリ誘導型の QA レイヤーが、より高コストなトラバーサル・デバッテベースラインをはるかに安価に上回ることを示しています。この分類法が言語やリポジトリをまたいで一般化できるならば、既存のほとんどのエージェント型 SWE パイプラインに対して安価かつドロップイン可能な改善手法となります。

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

自律的かつ監査可能な医用画像モデル開発に向けて

問題設定

経験的フィードバックに基づいて計画・コーディング・デバッグ・反復を行う自律型ML engineering（MLE）エージェントは、表形式データや汎用ビジョンタスクにおいてKaggleスタイルの競争力あるsubmissionを生み出し始めています。しかし医用画像は、そうしたシステムが前提とする仮定を破壊します。各モダリティ（CTボリューム、MRA、病理組織タイル、パノラマX線、顕微鏡画像）はそれぞれ異なる前処理・サンプリング・augmentationを要求し、検証プロトコルは妥協できません（患者レベルの分割、Dice計算のためのリサンプリング済みスペーシング、病変ごとのFROC対画像ごとのAUC）。さらに、成果物は単なる数値ではなくモデルパッケージ、すなわちコード・重み・チャレンジ固有フォーマットの予測結果・監査可能な来歴が求められます。ローカルメトリクスに過学習したり、暗黙のうちに分割を変更したりする汎用MLE エージェントは、見かけ上は良好な結果を示すものの、受理不可能なものとなります。

AMIDはこのギャップを標的としています。すなわち、受理されるすべての成果物がデータ・メトリクス・分割・submissionフォーマットのコントラクトチェックを通過しなければならない、自律的なモデル開発です。

手法

AMIDはパイプラインを2つのメカニズムに分解します：Data-Conditioned Method PlanningとVerification-Guided Two-Stage Optimizationです。

AMIDのdata-conditioned planningとverification-guided optimizationの概要

タスクと成果物のコントラクト。 入力は最小限であり、データセット（2D/3D画像、タイル、マスク、ラベル、品質スコアなど）とタスク定義（ターゲット、メトリクス、submissionプロトコル）です。要求される出力は完全なパッケージ、すなわち学習・推論コード、チェックポイント、予測ファイル、検証スコア、submission成果物、および監査証跡です。形式的には、\mathcal{C} = (\mathcal{D}, m, \sigma, \pi)をコントラクト（データ、メトリクス、分割、プロトコル）と表記するとき、AMIDはメソッド開発手続き\phiを探索します。ここで\phiは、経験的スコアm(\phi(\mathcal{D}); \sigma)が高く、かつ\phiが生成したすべての成果物がコントラクト適合チェックを通過するという両条件を満たします。

Data-Conditioned Method Planning。 エージェントが粗いタスクレベルの空間で自由にアイデアを生成するのではなく、AMIDはまずデータをプロファイリング（モダリティ、ボクセルスペーシング、クラス不均衡、タイルサイズ、アノテーション種別）し、タスクのエビデンスを実行可能なmethod laneの集合に変換します。これらは、実行可能な医用画像リソース（nnU-Netスタイルのsegmentation、検出フレームワーク、病理用MILなど）に基づいた、並列かつ自己完結型のパイプラインです。各laneはエンドツーエンドで実行するのに十分な具体性を持ち、追加の計画を必要としません。これにより、曖昧な「良いモデルを試す」という指示が、独立した軌跡のポートフォリオへと変換されます。

Verification-Guided Two-Stage Optimization。 オプティマイザはlane上でexplore-then-exploitループを実行し、レビュアーエージェントが各遷移においてコントラクトチェックを強制します。

レビュアーによる成果物チェックを伴う2段階のexplore/exploit

ステージ1（探索）では、多様なlaneが共有の検証ハーネスのもとで並列実行されます。検証ハーネスは以下を検査します：(i) 検証プロトコルが\sigmaに一致しているか（例：患者レベルのfold、同一スライドのタイル間でリークがないか）、(ii) メトリクス計算の方向が正しくチャレンジ実装と一致しているか、(iii) 予測成果物がevaluatorの期待するフォーマットとバイト互換性があるか。検証に失敗したlaneはローカルスコアによらず棄却されます。ステージ2（活用）では、昇格した候補がハイパーパラメータ精緻化・ensembling・後処理のための追加計算リソースを受け取りますが、レビュアーは引き続きすべての受理成果物を\mathcal{C}に照らしてゲーティングします。最終的に受理されるパッケージは、検証済みスコアが支配的であり、かつその来歴（コード、シード、分割、メトリクス実装）が完全に復元可能な最初の候補です。

この構造は汎用MLE エージェントと決定的に異なります。検証は事後フィルタではなくループ内制約として機能し、軌跡を枝刈りするため、許容集合の外に最適解があるlaneに計算資源が浪費されません。

結果

AMIDはReX-MLEで評価されます。これはパノラマX線、CT、MRI、CTA、MRA、病理組織、超音波、顕微鏡画像にわたるsegmentation・検出・分類・画像品質評価・画像強調の20タスクから成る医用画像チャレンジデータセットです。各タスクは単一のRTX A6000（48 GB）上で24時間の実時間予算のもとで実行され、コーディングバックエンドとしてGPT-5.5（Codex）を使用します。

各元コンペティションの人間リファレンスに正規化したチャレンジごとのAMIDの性能

20タスク全体にわたり、AMIDは評価された汎用MLE システムを上回り、いくつかのタスクでは元コンペティションの人間リファレンス（図3の破線パリティライン）に近づくか一致します。棒グラフの個別表示は、このパターンが少数の簡単なモダリティに牽引されていないことを示しています。異なるモダリティのsegmentationおよび分類タスクでパリティが達成される一方、一部の検出および画像強調タスクは人間リファレンスを下回ります。これは、それらのタスクでlaneの多様性と後処理（バックボーン選択ではなく）がリーダーボード性能を左右する傾向があることと一致しています。

著者らは、これらのスコアは成果物コントラクトが満たされた場合にのみカウントされること、すなわちチャレンジ主催者が受理するsubmissionに相当するものであり、内部検証の数値ではないことを強調しています。

限界とオープンな課題

  • 図3のパリティ比較は「厳密に一致したリーダーボードターゲットではなく、おおよそのスケール」として記述されています。元のコンペティションはプライベートテストセットと、1台のA6000での24時間をはるかに超える複数チームの計算を使用しているため、人間への追随に関する絶対的な主張は慎重に読む必要があります。
  • 結果はGPT-5.5 / Codexについて報告されており、バックエンド性能および基盤となる医用画像リソースライブラリのカバレッジに対する感度は、示されているセクションでは定量化されていません。
  • 検証チェックは、レビュアーが微妙なコントラクト違反（例：同一スライドのタイル間での患者レベルのリーク）を検出する能力に依存しており、検証における偽陰性は「受理済み」成果物に混入する可能性があります。
  • Data-Conditioned Method PlanningとVerification-Guided Optimizationの各寄与を報告された改善から分離するアブレーションは、本稿では示されていません。

この研究の重要性

医用画像における自律MLE は、出力が受理可能な場合、すなわち正しい分割・正しいメトリクス・正しいsubmissionフォーマット・検査可能な来歴を備えている場合にのみ有用です。AMIDは検証を報告上の懸念ではなく第一級の最適化制約として扱い、控えめな単一GPU 24時間予算のもとで、エージェントが20の異質なタスクにわたって人間のコンペティション性能に近いパッケージを生成できることを示しています。これにより焦点は「エージェントはMLEを実行できるか」から「エージェントは監査のもとでMLEを実行できるか」へとシフトします。後者こそが臨床展開において重要なバージョンです。

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

Blind-Spots-Bench: マルチモーダルモデルの盲点を評価する

問題設定

フロンティアの言語モデルおよびマルチモーダルモデルは、多くの標準的な benchmark（MMLU、GPQA、MATH）で飽和状態に達している一方で、人間にとってはほぼ自明なタスク——文字列中の文字を数える、解剖学的に誤った数の動物を描く、高頻度の事前分布に反するリクエストを処理する——では依然として失敗し続けています。こうした失敗は、能力指向の benchmark では取り上げられていません。なぜなら、そのような benchmark はスケールや事前学習の事前分布が有利に働くタスクを過剰にサンプリングしているからです。著者らは、これらの残存する「盲点」の測定不足が能力に関する過大評価につながると主張し、それらを表面化することを目的とした小規模かつ高品質にキュレーションされた benchmark である blind-spots-bench を提案します。

構築

問題の素材は、大学院の AI コースの受講生から収集されました。各受講生は、人間には簡単だが2025年10月頃に利用可能なフロンティアモデルが失敗するような問題を5件提出するよう求められました。最初の約287件のプールは、重複・曖昧さ・過度な難易度について篩にかけられ、最終的に235件のキュレーション済みサンプルが Hugging Face 上で公開されています。

各サンプルには、(i) 期待される回答、(ii) 正答の明示的な必要条件、(iii) 既知の失敗モード、を含む構造化された参照解答が付与されています。失敗モードは2つのソースから収集されています：収集時の受講生とモデルのやり取りで実際に観察されたエラー、および各問題につき少なくとも3名のアノテータによって提案された追加エラーです。この構造こそが自動検証を実行可能にする要因です——生の問いに対してファジーな文字列マッチングや LLM-as-judge に依存するのではなく、採点器は「必ず満たすべき」条件節を明示的に与えられ、それに照らして検証します。

サンプルには質問フォーマットラベル（テキストのみ、画像生成、または multi-to-text）とタスク taxonomy が付与されています。Figure 3 はフォーマットおよび細粒度のタスクカテゴリにわたる分布を示しており、3つの主要クラスタに分類されています。

blind-spots-bench の質問フォーマットとタスクカテゴリにわたる構成の内訳。

代表的なサンプル——「5本脚の犬を描け」という典型例や文字操作のプロンプトを含む——は Figure 2 にアノテーションスキーマとともに示されています。

テキストのみ・画像生成・multi-to-text にわたる代表的なアノテーション済みサンプル。

約15問は複数のサブタスクを含んでおり、それらは taxonomy の統計においてサブタスクごとに1件としてカウントされています。

評価パイプライン

評価は Inspect AI 上に構築された2段階の solver–grader 設計に従っています。solver はプロンプト戦略と本質的な能力を混同しないよう、chain-of-thought や in-context example を用いずにゼロショットでプロンプトされます。grader は問い、solver の応答、および構造化された参照解答を受け取り、正答／誤答の二値判定を出力します。gemini-3-flash が grader として使用されており、コード実行ツールが与えられています。これは重要な設計判断です。なぜなら多くの盲点タスクは厳しい制約付き検証（部分文字列のカウント、生成された文字列が特定の型の文字をちょうど n 個持つことの確認など）に帰着するため、LLM のみによる採点者自身が評価対象の盲点と同じものに陥りやすいからです。タスクは客観的に正しい答えを持つよう設計されているため、採点は二値方式です。

結果

テキストのみのサブセットにおいて、クローズドソースのフロンティアモデルはオープンウェイトモデルを大きく上回っています。著者らは、同程度のランクのクローズドとオープンのシステム間で約10%の精度ギャップを強調しています——これは、同じモデルのペアが互いに誤差範囲内に収まっている Artificial Analysis Intelligence Index スコアでは 見えない ギャップです。Figure 1（左）は blind-spots-bench の精度を Intelligence Index に対してプロットしており、この乖離を直接示しています：汎用 benchmark のスコアがほぼ同一のモデルが、この benchmark では約10ポイントの差をつけており、集約指標が能力の一軸を捉え損ねていることを示しています。

左：blind-spots-bench の精度と Artificial Analysis Intelligence Index の関係。右：サブタスクごとの VLM 性能。

Figure 1 の右パネルは、マルチモーダル側では単一の VLM がサブタスク全体で支配的な性能を示してはおらず、異なるモデルが互いに重ならないサブセットで失敗していること、また一部のカテゴリは評価された4つの VLM すべてにとって一様に困難であることを示しています。これは、盲点がスケールの単調関数ではなく、特定の学習分布のアーティファクト（例：5本脚の犬を描いた画像の確率がほぼゼロであること、またはトークンレベルではなく文字レベルの操作を要求するテキスト）を反映しているという解釈と整合しています。

限界と未解決の問題

この benchmark は小規模（235件）であり、2025年末時点で利用可能なモデルに対して対抗的に構築されているため、将来のモデルリリースにおける有効期間は不明であり、対抗的な構築はデータセットが公開されると Goodharting のリスクを孕んでいます。問題が受講生によって作成されているため、盲点タイプにわたるサンプリング分布は統計的に制御されておらず、taxonomy は事後的なものです。採点の信頼性も懸念事項です：コード実行があっても gemini-3-flash 自体がフロンティアモデルであり、同様の失敗モードの影響を受けやすいです；論文はアノテータの合意に対する grader の人手一致率を報告していません。最後に、プロンプティングが CoT なしの厳密なゼロショットであるため、結果は「できない」と「意図的な推論なしにはできない」を混同しており、これらは質的に異なる失敗モードです。

なぜ重要か

本論文は、複合的な知能指標が——特にトークン化、文字レベルの操作、および低頻度視覚的合成に関連する失敗モードにおいて——表面上は同等とされるモデル間の約10ポイントの能力ギャップを隠し得るという具体的な証拠を提供しています。盲点的な挙動が標準 benchmark と直交しているならば、デプロイリスクを忠実に描写するために、評価スイートには明示的な対抗的または long-tail の軸が必要です。

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

Hacker News Signals

コーディングエージェントの事前推論

本論文は、インタラクティブなエージェントワークフローにおけるレイテンシ問題に対処するため、実行開始前にコーディングエージェントの推論トレースを事前計算する手法を提案しています。標準的なchain-of-thoughtエージェントは推論コストを逐次的に発生させます――推論し、行動し、観察し、また推論するという流れで、各ステップにおいてレイテンシが積み重なります。核心的なアイデアは、思考フェーズと行動フェーズを切り離すことです。タスク仕様が与えられると、エージェントは想定されるツール呼び出し、中間状態、および分岐条件をあらかじめ見越した構造化プラン（「事前計算」トレース）を生成し、再計算を最小限に抑えながらそのプランに従って実行します。

本手法では、より長いオンラインロールアウトから蒸留することで、このプリフェッチされた推論トレースを生成するモデルを訓練します。学習シグナルは、オンザフライの再推論を必要とせずに正しい最終実行につながるトレースに対して報酬を与えます。これは精神的にはspeculative decodingに類似しています――必要になると予想されるものを事前に計算する――ものの、トークンレベルではなくタスクプランニングレベルに適用されています。

メカニズム的には、このアプローチは二段階パイプラインを導入します。planning model \pi_{\text{plan}} が潜在的なプログラムスケッチを生成し、execution model \pi_{\text{exec}} がそのスケッチを条件としてツール呼び出しを出力します。スケッチは類似タスク間でキャッシュして再利用することが可能です。SWE-benchおよびHumanEvalの派生タスクにおける実験では、多段階タスクにおいて精度劣化を最小限に抑えつつ、実時間で1.5〜2.5倍の高速化が示されました。

この手法の限界は、実行が予測された状態から乖離した場合に事前計算トレースが陳腐化する点にあります――エージェントはオンライン推論へのフォールバックを余儀なくされますが、本論文ではこれを信頼度ゲートによる再プラニングトリガーで対処しています。プランの品質は環境の予測可能性にも依存しており、敵対的または高度にステートフルな環境ではキャッシュの前提が崩れます。

未解決の問題として、副作用を伴うツール呼び出しとの組み合わせにおいて、再プランニングコストが非対称になる場合にどう対処するかという点が挙げられます。

なぜ重要か

レイテンシは実用上のエージェント利便性を制約する支配的要因です。プランニングと実行を分離することで、基盤となるモデルアーキテクチャに依存しないクリーンなキャッシュプリミティブが実現されます。

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

Linuxにおける入力レイテンシの計測：X11 vs. Wayland、VRR、そしてDXVK

本記事は、高速カメラとArduinoベースのカスタム製クリック-ピクセル間レイテンシ計測治具を用いて、Linuxデスクトップスタック上のエンドツーエンド入力レイテンシを慎重に実証的に調査したものです。手法の重要性として、合成ベンチマークではなく、物理スイッチの作動から光子放出までのフルパイプラインを実際に捉えている点が挙げられます。

主な知見：WaylandコンポジタはKDE PlasmaのKWin、GNOMEのMutterともに、unredirectedなX11パスと比較してコンポジタ由来のフレーム分のレイテンシを追加しますが、xdg-outputと直接スキャンアウトを併用した場合にその差は大幅に縮まります。Variable Refresh Rate（VRR/FreeSync/G-Sync Compatible）は非決定性を引き起こします——コンポジタが次のAdaptive Syncウィンドウを待ってフレームを保留する際、平均レイテンシが改善されるにもかかわらず、最悪ケースのレイテンシは固定リフレッシュレートの最悪ケースを上回る可能性があります。著者はKWin上のVRRにおいて、これを約2〜4msの追加分散項として計測しています。

DXVK（Vulkanバックエンドを持つD3D変換レイヤー）は、テスト対象ゲームにおいてネイティブVulkanパスと比較してメジアン値で約1〜2msのオーバーヘッドを追加しており、これは変換レイヤー内部のコマンドバッファ管理に起因します。本記事では、フレームサブミッションレイテンシとpresentレイテンシを区別しており、SDL2とSDL3のバックエンドがWaylandのpresentキューとのやり取りにおいて異なる挙動を示すことを指摘しています。

計測セットアップでは、VK_LAYER_MESA_overlayを介してログ記録されたフレームタイムスタンプを、240fpsのカメラフレームとクロス相関させています。著者はグレー-トゥ-グレー遷移を使用し、別途計測したパネル応答時間を差し引くことで、ディスプレイ応答時間を明示的に考慮しています。

手法上の注意点：本治具はクリックからゲームロジック受付までではなく、クリックから最初の光子までを計測するため、入力処理レイテンシとレンダリングパイプラインレイテンシを混同しています。著者はこの点を認識しつつも、ユーザーが知覚する体験を正しく反映していると主張しています。

実践的な結論：Linux上での競技ゲーミングにおいて、固定リフレッシュレートを用いたunredirectedなX11は最悪ケースのレイテンシで依然として優位に立ちます。Waylandは平均値では競争力がありますが、テールレイテンシでは及びません。

なぜこれが重要か

Linuxにおける入力レイテンシの計測は、これまで逸話的な情報に頼りがちでした。本研究は再現可能な手法を確立し、各スタックレイヤーのコストを数値で定量化しています。

Source: https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/

TS-2026-009: Tailscale SSHにおける安全でない引数処理がrootアクセスを許可

本セキュリティ情報は、Tailscale SSHにおける権限昇格の脆弱性を開示するものです。SSHサーバーのコマンド実行パスにおける不適切な引数のサニタイズにより、特定のACL構成下でTailscale SSHへのアクセス権を持つユーザーが対象マシン上でrootを取得できる状態にありました。

技術的な根本原因として、TailscaleのSSH実装はForceCommandおよびsubsystemディレクティブを内部で処理しています。脆弱なコードパスでは、ユーザーが制御する引数が十分なサニタイズなしに下位のシェルまたはプロセス起動プログラムへ渡されており、引数インジェクションが可能な状態でした。Tailscale SSHのACLが非rootユーザーとしてのログインを許可しているものの、デーモン自体がrootとして動作している標準的なデプロイメント環境において、細工されたSSHコマンドによって意図された実行コンテキストから脱出し、デーモンレベルの権限でコードを実行できました。

これはSSH実装において広く知られているバグの一種です。OpenSSHも過去にAuthorizedKeysCommandの引数処理において類似の問題を抱えていました。本件の新規性は、Tailscale SSHがホストのSSHデーモンを完全に置き換えるため、攻撃対象領域がシステムのSSH設定ではなくACLで制御されたTailscaleレイヤーになる点にあります。攻撃者に必要なのは、(1) tailnet上の有効なTailscaleアイデンティティ、および(2) ACLポリシーにおける何らかのSSHアクセス許可の2点であり、必ずしもrootアクセスである必要はありません。

修正内容は、プロセスを起動する前に引数インジェクションの経路を除去し、コマンドのパースロジックを厳格化するものです。公開されているセキュリティ情報のリンクには影響を受けるバージョンの記載はありませんが、パッチが適用されたリリースへの即時アップデートが推奨されています。

Tailscale SSHをバスチョンホストの代替として使用しているデプロイメントや、CI/CDパイプラインにおける自動アクセスに使用しているデプロイメントでは深刻度が高く、そのような環境では非特権のマシンアイデンティティが一般的である可能性があります。

なぜこれが重要か

Tailscale SSHはゼロ設定のバスチョンホスト代替として利用が拡大しています。このコンテキストにおける引数インジェクションを介した権限昇格は、tailnet全体にわたるラテラルムーブメントへの影響をもたらします。

Source: https://tailscale.com/security-bulletins

Linux on the Sega 32X: ハードウェアの同期プリミティブなど不要？

Sega 32Xには23 MHzで動作するHitachi SH-2 CPUが2基搭載されており、共有フレームバッファを持ちながら、キャッシュコヒーレンシプロトコルもハードウェアのアトミック操作もありません。著者はこのプラットフォームにLinux 6.xを移植しており、この記事は、設計上の前提が生まれる以前のハードウェア上で現代のOSを動かしたときに何が壊れるかを正直に記録したエンジニアリングログです。

SH-2にはLL/SC（load-linked/store-conditional）やCMPXCHGに相当する命令がありません。Linuxのロックプリミティブ — spinlock、mutex、RCU — は、最低限test-and-setまたはcompare-and-swapを前提としています。著者はこれを回避するため、SH-2のTAS（test-and-set）命令を活用しています。この命令は1バイトに対する不可分なread-modify-writeを提供しており、その上に最小限のspinlockを構築しています。ただし問題があります：32X上でのTASはキャッシュを通らないパスで共有SDRAMにアクセスするため、競合のないspinlockの「fast path」でさえ十分に低速です。

デュアルSH-2構成では、カスタムのSMPブリングアップパスが必要です。マスターSH-2がLinuxをブートストラップし、スレーブはIPI機構が存在しないため共有メモリ領域をポーリングすることで起動されます。メモリバリアはSYNCO相当のシーケンスによるフルパイプラインフラッシュとして実装されています。

フレームバッファドライバは特に興味深い点があります：32X VDPとGenesis VDPはハードウェアの優先度オーバーレイによって同じ出力を共有しており、どちらのCPUのタイミングでも決定論的に防ぐことができないティアリングアーティファクトを避けるため、垂直ブランク同期を慎重に行う必要があります。

著者はシェルの起動に成功しています。メモリは4MB（32X上の2MB SDRAMと64KBの内部メモリ）です。カーネル自体がかろうじて収まる程度であり、ユーザー空間は削ぎ落としたBusyBoxです。起動時間は数分かかります。

なぜこれが重要か

これは、OSの抽象化がハードウェアに対して実際に何を要求するかを示すクリーンなケーススタディであり、最小限の失敗事例に取り組むことで明快に理解できるようになっています。

Source: https://cakehonolulu.github.io/linux-on-32x/

C++26 Reflectionによる洗練されたType Erasure

C++26の静的reflection（P2996）は、コンパイラが型のメタデータを定数式で使用可能なstd::meta::info値として公開できる機能を提供します。この記事では、その機能を活用して、マクロや手動のvtable構築を一切使わず、reflectionのみによってゼロボイラープレートのtype erasure（std::any、std::function、および仮想ディスパッチの背後にあるパターン）を実装する方法を解説しています。

従来の手書きアプローチでは、消去したい各インターフェースに対してconcept、modelの構造体、vtableの構造体、ストレージ管理をそれぞれ記述する必要があります。reflectionを用いると、著者はconceptのメンバ関数をイテレートすることによってコンパイル時にvtableのレイアウトを生成します。

consteval auto make_vtable_type(std::meta::info iface) {
    // 関数メンバをreflectし、関数ポインタのフィールドを生成する
    std::vector<std::meta::info> members;
    for (auto fn : members_of(iface, is_function))
        members.push_back(make_fn_ptr_member(fn));
    return define_aggregate(synthesize_name(iface), members);
}

次に著者は、インスタンス化時に具体的な型をreflectすることでmodelのfill_vtable特殊化を合成し、各vtableスロットを対応するメンバ関数に結びつけます。これにより、手書きのものと同じABIを持ちながら、インターフェース宣言のみから完全に導出された、完全にtype-erasedなラッパーが生成されます。

パフォーマンスに関しては、生成されたコードは最適化後に手書きのvtableパスと同一であるとされており、手動のtype erasureとの比較でゼロオーバーヘッドであることがGodboltの出力によって検証されています。エルゴノミクス上の利点も実質的なもので、インターフェースにメソッドを追加すると自動的に伝播されます。

制限事項：P2996は2026年半ば時点でまだいかなる製品版コンパイラにも搭載されておらず、デモは実験的なClangフォークを使用しています。関数合成のためのreflection APIはまだ変更中であるため、define_aggregateの正確な記法は標準化前に変更される可能性があります。

この意義

これは、C++26 reflectionがシリアライゼーションだけでなく、根本的なOOPパターンに対しても、大規模なコード生成ツールの代替となるほどの表現力を持つことを示すものです。

Source: https://ryanjk5.github.io/posts/rjk-duck/

Show HN: RLでモデルをRL訓練するエージェントをRL訓練した（約$1,300）

このプロジェクトは、メタRLエージェントを訓練するものであり、そのエージェントの行動空間は下流のRL訓練実行の設定——ハイパーパラメータ、報酬シェーピング係数、カリキュラムパラメータ——であり、報酬信号は下流モデルの最終性能です。これは、RLの訓練パイプラインに特化して適用された自動機械学習（AutoML）であり、最初のループの外側に第2のRLループを設けることで実装されています。

外側のエージェントはPPOで訓練される小さなpolicyネットワークです。その状態には現在の下流訓練メトリクス（エピソードリターンの曲線、gradient norm、参照policyからのKL divergence）が含まれ、行動は内側ループの設定に対する連続的な調整です。内側のループは固定されたベンチマークスイート上でタスク解決エージェントを訓練します。外側エージェントの報酬は、固定された計算予算後における内側エージェントの評価スコアです。

$1,300というコストは、クラウドコンピューティングにおけるGPU時間を反映しています。著者はA100を使用しており、外側の訓練全体の実行には約40時間かかると報告しています。内側のループは並列化されており——複数の内側訓練ジョブが同時に実行され、外側エージェントに外側ステップごとのtransitionのバッチを提供します。

報告された結果によると、メタ訓練された設定スケジュールは、ベンチマークタスクにおける最終評価スコアでhand-tunedなベースラインを8〜15%上回り、発見されたスケジュールは解釈可能な構造を示しています：エージェントは著者が予期していなかったカリキュラム的なパターンでKLペナルティ係数をアニールすることを学習しています。

制限事項は重大です：meta-policyは訓練されたベンチマークスイートに過学習しており、新しいタスクへの転移性能は低いです。また、外側ループは信頼性の高いgradient signalを得るために十分な内側の計算量を必要とし、コストがかかります。

なぜこれが重要なのか

RLパイプラインのメタ最適化は明確に定式化された問題でありながら、安価で再現可能な公開実装が不足していました。本研究は、具体的なコストを指標としたベースラインを提供します。

Source: https://github.com/Danau5tin/ai-trains-ai

Guardian Angels: 生産性とセキュリティのためのLLMパーソナライゼーション

Gwernの投稿は、LLMベースの個人エージェントに関する特定のアーキテクチャを提唱しています。このエージェントは、ユーザーの全情報履歴にアクセスできる持続的・縦断的に認識するアシスタントとして機能し、セキュリティモデルを後付けではなく中心的なエンジニアリング課題として位置付けています。

生産性に関する議論は馴染み深いものです。すなわち、メール・カレンダー・ドキュメント・コミュニケーション履歴にアクセスできるモデルは、文脈設定のオーバーヘッドを大幅に削減しながら、スケジューリング・要約・下書き作成を処理できます。この投稿で興味深いのはセキュリティの枠組みです。Gwernは、guardian angelを有用にする持続的アクセスこそが同時に高価値な攻撃対象となると主張し、能力分割型アーキテクチャを提案しています。すなわち、履歴データへの読み取り専用アクセスと書き込み／アクション能力は、ユーザーの明示的な確認を必要とする暗号化認証ステップによって分離され、アクションごとのnonceに紐付けられます。

脅威モデルはプロンプトインジェクションに特に対処しています。これは、ユーザーのコーパス内の敵対的なドキュメントがエージェントのアクション空間を乗っ取ろうとするものです。提案された対策は、サンドボックス化された「reader」モデルを用いることです。このモデルが信頼できない入力を処理し、構造化されたサマリーのみを「actor」モデルに渡します。actorモデルは生の外部コンテンツを直接参照しません。これはLLM推論パイプラインにtaint-trackingのアプローチを適用したものです。

この投稿ではパーソナライゼーション学習に関する問題も議論されています。具体的には、個人データに対するfine-tuning、long-contextによる検索、LoRAアダプターの比較です。Gwernはプライバシーと更新容易性の観点からRetrieval-Augmentedアプローチを支持し、fine-tuningは個人データをweightに埋め込んでしまうため監査や取り消しが困難であると指摘しています。

この文章は考察的なものであり、実装や実験結果は含まれていません。論文ではなく、設計文書および議論です。

なぜこれが重要か

持続的な個人エージェントのセキュリティアーキテクチャは、文献上いまだ十分に仕様化されていません。プロンプトインジェクションに対するtaint-trackingの枠組みは、具体的かつ実装可能な提案です。

Source: https://gwern.net/guardian-angel

LFortranとEnzymeによる微分可能Fortran

LFortranはLLVMバックエンドとクリーンなASR（Abstract Semantic Representation）IRを備えたモダンなFortranコンパイラです。EnzymeはLLVM IRレベルで自動微分を行うLLVM passであり、ソースレベルの変換ではなくLLVMビットコードを通じて微分を実行します。この記事では、EnzymeをLFortranのコンパイルパイプラインに統合し、ソースを一切変更することなくFortranコードの前向きモードおよび逆向きモードのADを実現するプロセスを解説しています。

この統合が機能する理由は、LFortranがEnzymeを直接消費できるLLVM IRを出力するためです。Enzyme passはLLVM intrinsic、メモリ操作、制御フローを通じて微分を行い、primalと同じLLVMバックエンド最適化でコンパイルされるgradientコードを生成します。ユーザーはFortranソース内の関数ポインタに対して__enzyme_autodiffを呼び出すだけで、残りの処理はLFortranとEnzymeが担います。

記事で解説されているエンジニアリング上の課題は、LFortranのIRローワリングが微分可能なコードを出力するようにすることです。具体的には、Enzymeが微分できない不透明なメモリ操作を回避することが求められます。FortranにおけるArray操作はディスクリプタベースのメモリアクセスにマップされるため、LFortranがこれらを不透明なランタイムライブラリ呼び出しではなく、型付きLLVM IRによる明示的なload/storeシーケンスにローワリングするよう保証する必要がありました。

ベンチマーク結果によれば、生成されたgradientコードは典型的な数値カーネル（ステンシル、行列演算）においてprimalの1.5〜3倍以内の性能を達成しており、標準的なソース間変換Fortran ADツールであるTapenadeと競合する水準であり、primalとgradientのペアを結合して最適化するEnzymeの能力により、場合によってはより高速です。

制限事項：メモリバウンドなadjoint計算に対するEnzymeのチェックポインティング戦略がFortranのArray semanticsに対してまだチューニングされていないため、逆向きモードのadjointのメモリ使用量が大きくなる可能性があります。

この研究が重要な理由

FortranによるLarge-scale科学シミュレーションコードは、気候・流体力学における微分可能物理シミュレーションの主要なボトルネックとなっています。LFortran + Enzymeは、レガシーコードを書き直すことなく微分する道筋を提供します。

Source: https://docs.pasteurlabs.ai/projects/tesseract-core/latest/blog/2026-07-09-enzyme-lfortran-autodiff.html

注目の新しいリポジトリ

can1357/pon

Python 3.14向けのAhead-of-TimeおよびJITコンパイラで、全てRustで書かれており、Craneliftコード生成バックエンドを通じてネイティブマシンコードをターゲットにしています。CへのトランスパイルやCPythonバイトコードのラッピングではなく、ponは独自のメモリマネージャ「Green Tea GC」を持つネイティブランタイムを構築しており、CPythonの参照カウントと循環GCのハイブリッド方式と比較してポーズタイムを削減するよう設計されています。パースはruffのパーサークレートが担当しており、lexer/parserをゼロから再実装することなく、メンテナンスが行き届いた仕様に忠実なASTフロントエンドを実現しています。正確性に関するアプローチは異例なほど厳格で、CPythonに対するバイト単位の差分テストにより、ASTやIRレベルではなく出力レベルでのセマンティクスの乖離を検出します。LLVMではなくCraneliftを選択したのは意図的な判断であり、コンパイル時間の短縮、よりクリーンなRustネイティブAPI、C++ FFIサーフェスの排除といったメリットがある一方、ピーク最適化の品質はやや劣ります。このプロジェクトはPython 3.14言語の全体をターゲットとしているため、動的ディスパッチ、クロージャ、ジェネレータ、および最近のCPythonバージョンで導入されたGIL削除に関わる変更を処理する必要があります。組み込みスクリプティング、サーバーレスのコールドスタート削減、またはCPythonのインタープリタオーバーヘッドがボトルネックとなる場面での有力な選択肢です。まだ初期段階ではありますが、テスト手法とバックエンドの選定はエンジニアリング上の規律を示しています。

Source: https://github.com/can1357/pon

pocket-stack/pocketjs

DOMを持たない環境向けに構築されたJSXベースのUIランタイムです。組み込みシステム、ターミナルUI、ゲームオーバーレイ、そしてフルブラウザスタックのオーバーヘッドが許容できないその他のネイティブサーフェスをターゲットとしています。このフレームワークが掲げる主要な制約は、8 MBのメモリ内で60 FPSのアニメーションバジェットを実現することです。ハードウェアレンダリングはHTML/CSSレイアウトエンジンを一切介さず、代わりにレンダラーがGPUまたはフレームバッファAPIと直接通信します。フレームワークの表面は意図的に親しみやすい設計となっており、Vue VaporのコンパイルモデルとSolidのfine-grained reactivityをサポートしています。これにより、コンポーネントの記述は既存のWebツールに近い形を保ちながら、実行パスからvirtual DOMのオーバーヘッドが排除されています。Tailwind互換のデザインシステムも含まれており、おそらくCSSとして解釈されるのではなく、静的なトークンテーブルにコンパイルされる形で実装されていると考えられます。アーキテクチャはコンポーネントモデル（宣言的なJSXツリー、reactive signals）とプラットフォームバックエンド（実際のピクセル描画レイヤー）を分離しており、これがサーフェス間の移植性を実現しています。ElectronやWebViewの導入が許容されず、かつ独自ウィジェットツールキットをゼロから構築するコストも避けたい場合——IoTディスプレイ、キオスクソフトウェア、プロセス内エージェントダッシュボードなど——制約のあるネイティブ環境でUIを提供するすべての人に関連する技術です。

Source: https://github.com/pocket-stack/pocketjs

databufflabs/databuff

標準的なOpenTelemetryシグナル（トレース、メトリクス、サービス依存グラフ）の上にマルチエージェントLLMシステムを重ね合わせたオブザーバビリティプラットフォームです。人間のオペレーターがダッシュボードをクエリする代わりに、複数のエージェントが協調して異なるシグナルタイプにまたがる異常を相関付けます。例えば、トレース上のレイテンシスパイクをインフラメトリクスおよびサービストポロジグラフと照合し、生のアラートではなく因果チェーンを生成します。「AI-native」というフレーミングは、既存のAPMストアにNLPを後付けするのではなく、LLMが読みやすいサマリーと構造化された検索を最初から想定した設計でインジェストパイプラインが構築されていることを意味します。実装面では、ほぼ確実にOTELコレクターをインジェスト用にラップし、構造化されたスパン・メトリクスデータをembeddingまたは検索レイヤーに投入し、根本原因の仮説生成に特化したエージェントへクエリをルーティングしていると考えられます。実用上の価値は、オンコールエンジニアの認知負荷を軽減する点にあります。Jaeger、Prometheus、サービスマップを手動で相関付ける代わりに、統合された説明を得ることができます。未解決の課題としては、因果関係の主張におけるハルシネーションの発生率や、学習データに含まれていない新規障害モードへの対応方法が挙げられます。

Source: https://github.com/databufflabs/databuff

eli-labz/Cognitive-Core-Skills

LLM、SLM、エージェント、およびワールドモデルに期待される認知プリミティブを、ドメイン非依存の形式で列挙しようとする、構造化されたタクソノミーおよびスキーマライブラリです。知覚・記憶・推論・計画・行動・検証・学習・ガバナンスという8つのトップレベルカテゴリが、それぞれ機械可読スキーマを持つ159個の個別スキルカードに分解されています。特定のベンチマークスイートやアプリケーションドメインに縛られない、能力ベンチマーキングのための共通語彙を提供することを意図しています。CIインテグレーションによりスキーマはコミット時に自動検証され、既存の評価をタクソノミーにマッピングするベンチマークも含まれています。提供する価値は標準化にあります。エージェント評価ハーネスを構築するチームは、場当たり的な能力マトリクスを再発明することが多いですが、このライブラリは再利用可能なオントロジーを提供します。ただし、制約も少なくありません。認知のタクソノミーは本質的に異論の余地があり、ベンチマークのパフォーマンスを離散的なスキルカードにマッピングすることは主観的な判断を伴います。コミュニティが標準として採用するかどうかは、ツール類への普及に依存しています。それでも、能力監査やレッドチーミングチェックリストの出発点として、機械可読スキーマを備えた159カードの分解は、散文形式のタクソノミーよりも実用的です。

Source: https://github.com/eli-labz/Cognitive-Core-Skills

William-Lu-stack/Flawless

Kubernetesクラスタおよびクラウドインフラを対象としたエージェント型SREプラットフォームであり、単なるアラート通知ではなく自動化された運用として位置づけられています。「AgenticOps」というフレーミングは、受動的なモニタリングを超えていることを示唆しています。すなわち、エージェントがクラスタの状態を観察し、障害を診断し、人間の承認を待たずに（または設定可能な承認ゲートを介して）podの再起動、スケーリングの調整、設定のロールバックといった修復アクションを実行できます。技術的な基盤は、おそらくKubernetes APIウォッチャー、クラウドプロバイダーAPI、そして半構造化された運用データ（podログ、イベントストリーム、リソースメトリクス）を対象とした推論を行うLLMバックボーンの組み合わせと考えられます。ここでの難しいエンジニアリング上の問題は、信頼性とブラストラジウス（影響範囲）です。本番環境でkubectlの書き込みアクセス権を持つ自律エージェントは、アクション空間の慎重なサンドボックス化とロールバック保証を必要とします。Flawlessがこれらに具体的に対処しているかどうかは説明からは明らかではありませんが、デプロイ前に問うべき正しい問いです。専任のSREヘッドカウントを持たない小規模チームが自動化されたファーストレスポンダー能力を必要とする場合に有用です。またKubernetesネイティブなスコープにより、修復プリミティブとして既存のHelm/Operatorエコシステムを活用できます。

Source: https://github.com/William-Lu-stack/Flawless

deer-flow/llm-space

反復的なエージェント開発のためのローカルファーストなデスクトップアプリケーションで、LLMを基盤とするエージェントのビルド・デバッグ・評価という内側のループに特化しています。クラウドベースのエージェントIDEとの核心的な差別化点は、障害トレースをdeterministicに再現（リプレイ）できる機能にあります。具体的には、ライブバックエンドに対してエージェントを再実行することなく、すべてのツール呼び出し・プロンプト・モデルの応答をステップ実行できます。これは、エージェントの挙動がnon-deterministicであり、障害の発生頻度は低いものの再現コストが高い場面で重要となるインフラです。評価レイヤーはリプレイシステムと並置されており、パフォーマンス指標は別途の評価パイプラインを必要とせず、キャプチャされた実行結果に基づいて算出されます。「ローカルファースト」とは、状態がリモートデータベースではなく検査可能なフォーマットでディスク上に保存されることを意味し、独自データのプライバシー保護やオフライン開発において重要です。ターゲットユーザーは、ReActループ・ツール使用チェーン・プランニングエージェントなど、マルチステップエージェントをプロトタイピングしている人物で、printデバッグ以上の手段を必要としながらも、フルのMLOpsプラットフォームまでは必要としない層です。ステップレベルの検査・障害リプレイ・統合された評価を一つのローカルツールに組み合わせることで、現在のエージェント開発ツールチェーンに存在する真のギャップを埋めています。

Source: https://github.com/deer-flow/llm-space

michaelshimeles/boring-computers

オンデマンドでFirecracker microVMを起動し、AIエージェントにその制御を渡すサンドボックス化されたコンピュートプロビジョニングレイヤーです。各VMにはブラウザとターミナルが標準プロトコル経由でアクセス可能な状態で付属しており、コンテナレベルのnamespaceではなくmicroVMの粒度で真のプロセス分離を実現したフルインタラクティブなLinux環境をエージェントに提供します。「boring（退屈な）」というフレーミングは意図的なもので、FirecrackerはAWS LambdaやFargateで使用されているものと同じハイパーバイザーであり、100ms未満のブート時間と最小限の攻撃対象領域を理由に採用されています。コーディングエージェントとブラウザ操作エージェントはVM内部で動作するため、エージェントサンドボックスからの脱出にはハイパーバイザーからの脱出が必要となります。実用的なユースケースはcomputer-useエージェント――コードの実行、Webブラウジング、ファイル操作を必要とするモデル――であり、ホストマシンへの直接アクセスをエージェントに与えることが許容できない場合を対象としています。アーキテクチャはエージェントオーケストレーションレイヤーをVMライフサイクル管理から切り離しているため、異なるエージェントフレームワークを差し替えて接続することができます。主な未解決の問題としては、ネットワーク外部通信ポリシー（各VMにどの程度のインターネットアクセスを許可するか）、VM分あたりのコスト、そしてセッション状態が呼び出しをまたいで保持されるのか、それとも一時的なものかという点が挙げられます。

Source: https://github.com/michaelshimeles/boring-computers

Rhacknarok/hacksguard

Rustで実装されたターミナルUIを備えた静的マルウェア解析ツールで、PE（Portable Executable）バイナリを対象としています。3つのコアとなる解析レイヤーは、深いPE構造のパース（セクションヘッダ、インポート／エクスポートテーブル、リソースディレクトリ、オーバーレイ検出）、パース済みバイナリへのYARAルールスキャン、そして各種インジケータをリスクスコアに集約するヒューリスティックスコアリングエンジンです。Rustによる実装は、不正な形式のバイナリをパースする際にメモリ安全性を提供します。これは、不正なPEヘッダが解析ツールをクラッシュさせたり誤誘導したりするための一般的な手法であることを考えると、重要な特性です。マルチスレッディングは、バッチでサンプルを処理する際のスキャンを並列化するために使用されています。TUIにより、GUIへの依存なしにSSHセッションや自動化パイプラインでの利用が可能です。YARAとの統合により、既存のコミュニティルールセット（例：YARA-rules GitHubオーガナイゼーションのもの）を直接インポートできます。pestudioやcapaといったツールと比較した場合、このツールの価値はRustによる安全性の保証、スクリプト向けのCLI／TUIインターフェース、およびヒューリスティックレイヤーのオープンソースとしての拡張性にあります。制限事項としては、静的解析のみであること（動的実行なし、サンドボックス統合なし）、およびPEのみのスコープ（ELFやMach-Oのサポートは記載されていません）が挙げられます。

Source: https://github.com/Rhacknarok/hacksguard