デイリーAIダイジェスト — 2026-08-07
arXiv ハイライト
AgentOPSD: Agentic Reinforcement Learningのための再帰的Self-Distillation
問題
検証可能な報酬を用いたAgentic RL（GRPOおよびその派生手法）は、マルチターンの軌跡全体を単一のスカラーadvantageに縮約し、すべてのトークンにブロードキャストします。ALFWorldやマルチホップ検索などの長期的タスクでは、成功はしばしば少数の重要な決定——物体の発見、正しいクエリの発行、検索終了の判断——に依存します。均一なクレジット割り当ては、これらのターンをルーティンなターンと混同させ、学習を遅らせ、entropyを不安定化させます。従来の「特権的self-distillation」手法は、正解や正解軌跡を参照したteacherを用いてより密な監督を生成しますが、teacher–studentのギャップをシーケンシャルな意思決定においてどのターンが重要だったかの証拠としてではなく、局所的なトークン単位の重みとして扱います。AgentOPSDが問うのは、トークン単位のteacher–studentの対数確率ギャップが与えられたとき、それをターンレベルのクレジットに変換するための原則的な方法は何か、ということです。
手法
設定は標準的です。ターン k においてエージェントは履歴 s_k を観測し、a_k = (y_{k,1},\dots,y_{k,L_k}) \sim \pi_\theta(\cdot \mid s_k) をサンプリングします。K ターンのエピソード \boldsymbol{\tau} はバイナリ報酬 R(\boldsymbol{\tau}) を受け取ります。GRPOはグループ正規化されたsequence advantageを
A_{\mathrm{seq}}^{(i)} = \frac{R^{(i)} - \bar{R}}{\widehat{\sigma}_R + \epsilon_0}
として形成し、A_{\mathrm{seq}}^{(i)} をすべてのトークンに割り当てます。
AgentOPSDは、この均一な割り当てを3ステップのターンレベルreshaping（図2参照）で置き換えます。
トークンからターンへの集約。 特権的なteacher \pi_{\mathrm{tea}}（正解軌跡や正答などの追加情報を条件とする）が、トークン単位の対数確率ギャップ \delta_{k,t} = \log \pi_{\mathrm{tea}}(y_{k,t} \mid \cdot) - \log \pi_\theta(y_{k,t} \mid s_k, y_{k,<t}) を提供します。これらはターン内で集約され、スカラーのターンレベル証拠 e_k（\delta_{k,t} の長さ正規化された総和）になります。
対数オッズ空間における再帰的信念更新。 軌跡が成功パス上にあるというベイズ的信念 B_k は対数オッズ形式で維持され、
\ell_k = \ell_{k-1} + \lambda\, e_k,
となります。直近のターンがより大きな重みを持つよう、事前分布に割引率 \gamma が適用されます。更新は対数オッズにおいて加法的であるため、確率スケールでは尤度比の積に相当し、ターン証拠に対する適切な逐次ベイズフィルタとなります。対数オッズで計算することで数値範囲が制約され、単一ターンの影響が e_k に対して線形になります。
- 周辺改訂によるピボットターンの特定。 ターン単位のクレジットは周辺信念変化 \Delta B_k = \sigma(\ell_k) - \sigma(\ell_{k-1})、すなわちターン k において最終的な成功に関する事後分布がどれだけ変化したかです。|\Delta B_k| が大きいターンがピボットターンです。reshapedターンadvantageは A_k^{(i)} = A_{\mathrm{seq}}^{(i)} \cdot w_k^{(i)} であり、w_k^{(i)} は \Delta B_k の正規化された関数です。ターン k 内のすべてのトークンは A_k^{(i)} を継承し、これは上限クリップ \epsilon_{\mathrm{high}} を用いたGRPOのクリッピング比目的関数に直接組み込まれます。critic不要、追加ロールアウト不要、軌跡ごとにteacherのフォワードパスが1回のみです。
結果
Qwen2.5-3Bおよび7Bを用いたALFWorld、WebShop、Search-QAにおいて、AgentOPSDはGRPOおよび従来のself-distillationベースラインを上回ります。図1(a)は、Qwen2.5-7BによるALFWorldの検証成功率がベースラインより速く、かつより高いプラトーに達することを示しています。
ホライゾン頑健性のパネル(b)——サブタスクごとの成功率と測定された平均ターン数に対するOLSの傾き——は、より診断的な結果です。AgentOPSDは負の傾きが大幅に緩やかであり、GRPOや均一ギャップdistillationと比べて、追加の必要ターン数あたりの成功ポイント損失が少ないことを意味します。パネル(c)は、GRPOのようにentropyが崩壊しないことを示しており、クレジットをピボットターンに集中させることでルーティンターンへの監督が弱くなり、探索が保たれるという直感と整合しています。
ハイパーパラメータ感度（図3）は、信念割引率 \gamma、証拠ゲイン \lambda、クリップ \epsilon_{\mathrm{high}} にわたって緩やかです。性能は広い範囲で安定しており、極端な値でも緩やかに劣化します。
限界と未解決の問題
この手法は特権的なteacherを必要とします。Search-QAおよびALFWorldではteacherを正解から構築できますが、自然な特権的視点が存在しないドメインへの一般的なレシピは不明確です。ベイズ信念が明確なセマンティクスを持つのは e_k が対数尤度比として較正されている場合のみですが——生のteacher–student対数確率ギャップをそのように扱うことは、経験的には機能するものの形式的な正当化を欠くヒューリスティックです。信念更新は \ell_{k-1} においてマルコフ的であり、非単調な推論（例えば、後の観測の後にのみピボットとなる決定）を表現できません。最後に、評価は2つのモデルスケールと3つの環境に限定されており、より大きなスケール、より長いホライゾンを持つツール使用ベンチマーク、およびオフポリシーまたは非同期ロールアウトでの挙動は未解決のままです。
なぜ重要か
AgentOPSDは、特権的teacher信号をシーケンシャルなクレジットに変換するための、クリーンかつcritic不要な方法を提供します。その帰納的バイアスは適切であり、ベイズフィルタの周辺改訂が自然にピボットターンを特定します。これはGRPOの学習ループへのドロップイン変更であり、ホライゾン頑健性の結果は、改善をもたらすのが追加の監督だけでなくメカニズム自体であることを示唆しています。
Source: https://arxiv.org/abs/2608.05987
EnvACE: World Rehearsalによる環境ダイナミクスの内在化を用いたAgentic強化学習
問題設定
ツール使用LLMのためのAgentic RLは、環境がボトルネックとなっています。実際の実行可能環境（データベース、API、MCPサーバー）は構築・検証・学習中の安定維持にコストがかかり、合成シミュレータはコストが低い反面、grounding driftやreward hackingの問題があります。どちらのパラダイムもpolicyのスケーリングと環境のスケーリングを結びつけており、いずれの場合も環境応答モデルはpolicyの外部に存在するため、エージェントは自らのアクションが観測をどう形成するかを内在化できません。EnvACEは学習中に外部の応答プロバイダを排除し、環境応答生成器をpolicy自体に組み込むことでこの問題を解決します。
手法
EnvACEは共有policy \pi_\theta に2つの役割を割り当てます。ツール呼び出しを生成するacting役割と、環境を演じるrehearsal役割です。履歴 h_t が与えられたとき、ロールアウトは以下のように交互に進みます。
a_t \sim \pi_\theta(\cdot \mid h_t, \textsc{Act}),\quad \hat{o}_t \sim \pi_\theta(\cdot \mid h_t, a_t, \textsc{Rehearse}),\quad h_{t+1} = h_t \oplus (a_t, \hat{o}_t),
終了まで繰り返されます。したがって、外部シミュレータなしに軌跡が展開されます。ターン t+1 に入力される観測は、a_t を生成したものと同じパラメータから生成されます。タスク成功の報酬は軌跡の終端で付与され、gradientはactトークンとrehearseトークンの両方に流れます。
最適化アルゴリズムはGRPOのrole-wiseな変形版です。actトークンとrehearseトークンでは報酬対長さの統計が大きく異なります。rehearsalは典型的にJSONのような長い観測であるのに対し、actは短いツール呼び出しです。単一のグループbaselineではrehearsal役割が支配的となり、actingのgradientが崩壊してしまいます。EnvACEはプロンプトごとに G 個のサンプリングされた軌跡に対して推定される独立したグループbaseline b^{\textsc{Act}} と b^{\textsc{Rehearse}} を維持し、各役割内でadvantageを計算してからクリップされたsurrogate objectiveを合計します。具体的には、グループリターン \{R_i\}_{i=1}^G に対して、役割 r のトークン上のrole-conditional advantageは以下のようになります。
\hat A_i^{(r)} = \frac{R_i - \mathrm{mean}(\{R_j\})}{\mathrm{std}(\{R_j\})},
これは役割タグが r と一致するトークンにのみ適用され、標準的なPPO clipを使用します。これにより、一方の役割の分散が他方を圧倒することなく、2つの役割が同じタスク報酬に対して共同最適化されます。
テスト時には、policyがprivate rehearsal（内部world modelに対する並列または逐次ロールアウト）を発行し、それらを短い「rehearsalメモリ」に凝縮してから、実際の環境にアクションをコミットします。これは学習済みworld modelに対するinference-time planningであり、MCTSスタイルのlookaheadと類似していますが、完全に自己回帰サンプリングとして実装されています。
重要なのは、world rehearsalはground-truthシミュレータからのdistillationではないという点です。rehearsalされた \hat o_t が実際の環境とトークン単位で一致する必要はありません。最適化されるのは、自身が想像した観測を条件としたpolicyが、最終的に実行されたときに成功するアクションを選択できるかどうかです。これは実質的に、\pi_\theta が自身のロールアウト分布下で一貫性を保つように正則化することになります。
結果
EnvACEは、関数呼び出しとstatefulサービス環境を網羅する4つのベンチマークで評価されています。BFCL-v4、\tau^2-Bench（Retail/Telecom/Airline）、VitaBench（フードデリバリー、店内、旅行、クロスドメイン）、FinMCP-Bench（MCPベースの金融ツール）です。4つすべてにおいて、EnvACEは環境スケーリングベースラインを総合スコアで上回りました。すなわち、より多くの実環境またはシミュレート環境のインタラクションで学習されたエージェントを凌駕しています。
\tau^2-Bench上の制御されたablation（Figure 3）は、world rehearsalが1.7Bと8Bの両パラメータスケールで有効であることを示しており、これらの改善が特定のキャパシティレジームに固有のものではないことを示しています。また、rehearsalを用いてあるタスクファミリーで学習されたpolicyが分布外ベンチマークでも改善を保持するというtransferも報告されており、これはpolicyがシミュレータ特有の挙動を記憶するのではなく、汎用的なアクション-応答構造を内在化したという主張と整合しています。
限界と今後の課題
- Rehearsal fidelityが未計測である。 本手法はタスク成功を最適化しており、実際の環境に対する観測尤度を最適化していません。実際の環境が鋭い分岐（例：認証失敗、競合状態）を持つ場合、内部world modelはデプロイ時にのみ現れる失敗モードを系統的に見落とす可能性があります。
- 軌跡あたりの計算量が増加する。 各ターンでactingとrehearsingの両方にトークンを消費し、さらにテスト時のprivate rehearsalによってinference costが増加します。同じFLOPを追加の実ロールアウトに費やした環境スケーリングとの計算量マッチ比較は提示されていません。
- 役割の不均衡をヒューリスティックに処理している。 Role-wiseなbaselineは主要な症状を解消しますが、actとrehearseのトークン長の不均衡は依然として最適化ダイナミクスに影響を与えます。原則的なper-role KLや長さ正規化されたobjectiveが自然な次のステップとなります。
- 報酬のスパース性。 終端のタスク成功報酬のみを使用する場合、長いact/rehearseの交互シーケンスにまたがるクレジット割り当ては自明ではありません。ablationは、rehearsal自体による改善と、もっともらしい観測を予測する暗黙的な補助objectiveによる改善をどれだけ分離できているかを示していません。
- Self-consistent hallucinationという失敗モード。 policyがあらゆるアクションを成功に見せるrehrsal分布に収束した場合、学習報酬は上昇しても実環境でのパフォーマンスが停滞する可能性があります。報告されたtransfer結果はこれに反論しますが、それを防ぐメカニズムは分析されていません。
重要性
EnvACEはagentic RLを環境をスケールするからpolicyのworld modelをスケールするへと再定式化し、単一のパラメータセットがactor、観測のcritic、そしてシミュレータとして機能することを可能にします。これが一般化するならば、エージェントの能力を実行可能な環境を構築するエンジニアリングコストから切り離すことができます。これはツール使用・コンピュータ使用エージェントの学習における現在の支配的なボトルネックです。
Source: https://arxiv.org/abs/2608.06197
OSReward: クロスプラットフォームなコンピュータ操作 Reward Model の標準化された評価基準の確立
問題設定
コンピュータ操作エージェント（CUA）は、スクリーンショット・アクション・推論のシーケンスからなるトラジェクトリを生成しますが、その成否を検証することは、ベンチマークスコアリング・データキュレーション・RL reward という3つの下流用途において必要不可欠です。人間によるアノテーションはスケールしませんし、手書きの検証器は状態の検査が可能な限られたタスクにしか存在しません。この分野ではデフォルトとして VLM-as-judge が用いられてきましたが、プラットフォームをまたいだ judge の信頼性を厳密に測定した研究はありませんでした。OSReward はその測定基準を提供し、OS-Shepherd はその知見をもとに安価なオープンな reward model として具現化しようとする試みです。
ベンチマークの構築
著者らは、既存ベンチマークのロールアウトを再利用することは実行不可能であると主張しています。それらの実行結果はテストハーネス由来の品質上の交絡因子を引き継いでおり、ラベルも元の検証器のノイズを含んでいるためです。そこで、デスクトップ・モバイル・ウェブにまたがるインフラ上で、端から端まで新鮮なトラジェクトリを独自に収集しました。環境は現実的な状態——ユーザープロファイル、シードされたデータベース、編集対象の実ファイル、ディストラクタコンテンツ——で整備されており、(i) 失敗モードが自明でなく、(ii) 成功には環境の状態変化が必要であり、単なる言語的な完了報告では不十分となるよう設計されています。ウェブタスクはライブサイト上で実行されます。
トラジェクトリは4つのモデルファミリーから選ばれたエージェントにより生成され、3名のアノテーターによるパイプラインで意見の相違にはメタレビューを経てラベル付けが行われ、約800時間の人手作業を経て1019件のゴールドトラジェクトリが得られました。ゴールドセットは3つのビューで公開されています：OSReward（全件）、OSReward-Hard（judge が意見を異にするか判定が拮抗する困難なケースに絞ったもの）、OSReward-Multi（二値的な成功を超えた粒度の細かい効率性・整合性スコアリング）。
Judge のベンチマーキング
27種類の VLM judge が、OpenAI・Anthropic・Gemini・Qwen・Doubao・Kimi・Intern シリーズ（thinking variant および小規模オープンウェイトモデルを含む）を対象に、固定プロトコルのもとで評価されました。主要な発見は、フロンティアのクローズドモデルを含むすべての judge が理想的な judge に及ばず、共通して寛容バイアス（leniency bias）——失敗した実行に対する偽陽性が偽陰性を上回る——を示しているということです。
コスト・精度のフロンティア（図1）は実際的な問題を示しています。すなわち、rejection sampling や RL に十分な強度を持つ judge は、CUA 学習時の呼び出し量では法外なコストがかかる一方、安価な judge は性能が低いか寛容すぎるという問題があります。
判定を左右する要因
分析では judge への入力を系統的に摂動させています。視覚的な摂動は全体的な精度をほとんど変化させません。末尾の5枚のスクリーンショットを最後の3枚に置き換えるか、最初の1枚と最後の2枚に置き換えても、二値精度の変化は0.5ポイント未満です。赤いクリックマーカーを除去しても効果はなく、末尾のスクリーンショット数を1から16まで変化させても、各 judge の変動は単調な傾向を示さず2〜3ポイントの範囲に収まり、per-judge の最適値は N \in [5, 9] にあります。しかし、それぞれの「無害な」視覚的設定は、メイン設定と比べて個々の判定の5〜7%を反転させます。これは評価では平均化されますが、per-トラジェクトリのラベルが個別に消費される reward ラベリングでは平均化されません。judge は集団的な傾向（herding）を示すため、投票ベースの集約ではこのノイズを完全に抑制できず、下流の RL に対するノイズフロアを生じさせます。
補完的な発見（§5.2 で参照）は、判定がピクセルではなく主にテキストストリーム——推論チェーンとアクションログ——に宿るというものです。これは、知識蒸留コーパスにおいて二値判定だけでなく judge の推論を保存することを正当化します。
OS-Shepherd
信頼できる judge は学習スケールで実行するには高コストすぎ、投票では判定を鋭くできないという状況を踏まえ、著者らはアグリーメントフィルタリングによるアンサンブル蒸留によって OS-Shepherd-100K を構築しました。トラジェクトリは、多様で強力な judge が異なるスクリーンショット枚数のもとで独立して同一の判定に達した場合にのみ保持されます。このフィルターは判定済みトラジェクトリの約85%を保持します。ロールアウトは5つのモデルファミリー（Claude、Gemini、GPT、Kimi、Qwen）にわたり、多様なハーネス・アクション空間・ステップ予算のもとで実行され、独立したオープンソースエージェントスタックも含み、OSReward ゴールドセットに対してデコンタミネーションが施されています。重要なことに、保持された各サンプルは judge の推論トレースを含んでおり、OS-Shepherd-100K は推論アノテーション付きの大規模 CUA judge コーパスとして初めてのものとなっています。OSReward-Hard において、OS-Shepherd モデルは推論コストの一部でフロンティア judge の精度に近い性能を達成しています（図1）。
汎化性
同じ judge を3つの既存 CUA ベンチマーク上でそれぞれの手書き検証器と比較した結果、一致率は judge よりもプラットフォームによって大きく変化することが明らかになりました。手書き検証器の代替として約90%の一致率を基準とすると、最良の judge はモバイルでそれに近い値を達成し、ウェブでは約6ポイント内に収まりますが、デスクトップでは大きく届きません。judge 間の順序はベンチマークをまたいで保持されています。デスクトップでの不足分は寛容バイアスを再現しており、偽陽性は検証不可能なドメインや長いトラジェクトリに集中しています。
限界とオープンな問題点
汎化性の研究でグラウンドトゥルースとして使用される手書き検証器はそれ自体が不完全であるため、OSReward 以外のベンチマークでは judge の絶対精度が過小評価されている可能性があります。Judge の集団的傾向（herding）により、アンサンブル投票では寛容性の上限を突破できません。アグリーメントフィルターが有効なのは、判定を解決するのではなく破棄できるからです。単一の judge 呼び出しから得られた reward には、設定ごとの5〜7%の判定反転率によるハードなノイズフロアが存在し、これは長期ホライズン RL においてreward hacking の圧力として現れます。OS-Shepherd の推論条件付き教師あり学習が、オフライン評価器として機能するのではなく、reward として訓練されたポリシーへ転移するかどうかについては、直接的な測定がなされていません。
なぜこれが重要か
CUA の RL および rejection sampling において、今やバインディング制約となっているのはポリシー能力ではなく reward の信頼性です。OSReward はすべての主要な VLM judge の寛容性を数値化し、そのバイアスが自身のデータ外でも持続することを示しています。一方で OS-Shepherd は、アグリーメントフィルタリングと推論アノテーション付き蒸留によって、学習スケールのコストでフロンティア judge の識別能力の大部分を回復できることを実証しています。
Source: https://arxiv.org/abs/2607.28609
WorldClaw: スケールするエージェント型3Dオープンワールド生成
問題
テキストから3Dシーンを生成するシステムは、部屋スケールおよびオブジェクトスケールの出力において急速に進歩してきましたが、探索可能なオープンワールド環境の生成においては、依然として三つの要件を同時に満たすことができていません：(i) グローバルな空間的一貫性——地域、集落、バイオームが配置される一貫した地形の骨格；(ii) 近距離のウォークスルーにも耐えうる豊かなローカルコンテンツ；(iii) BlenderやUnrealのようなエンジンでの下流利用に適した、明示的かつ編集可能なアセットインスタンス。モノリシックな diffusion ベースまたはNeRFベースのジェネレータは、これらの軸のいずれかを犠牲にする傾向があります——連続的ではあるが編集不可能なradiance fieldを生成するか、一貫したワールドフレームを持たないオブジェクト単位のメッシュを生成するかのいずれかです。WorldClawは、ワールド生成をひとつのサンプリングステップではなく、計画された段階的なエージェントワークフローとして扱うことで、この三つの要件を直接的に解決しようとしています。
手法
本システムは、共有された構造化表現上の三つの逐次的な演算子として生成を分解します：
\mathcal{P}=F_{\mathrm{plan}}(q),\quad \mathcal{T}=F_{\mathrm{terrain}}(\mathcal{P}),\quad \mathcal{O}=F_{\mathrm{region}}(\mathcal{P},\mathcal{T}),
最終的なシーンは \mathcal{S}=\operatorname{Compose}(\mathcal{T},\mathcal{O}) となります。ここで \mathcal{P} はJSON形式のシーン仕様（地域、地形パラメータ、アセットカテゴリ、マテリアル、空間関係）、\mathcal{T} は明示的な地域認識地形（高さフィールド＋マテリアル割り当て＋散布された地形アセット）、\mathcal{O} は詳細が要求される地域に配置・テクスチャ付けされたインスタンスレベルのメッシュ集合です。
ステージ1 ——意図分析と計画。 二つのエージェント（意図分析＋シーン計画）が、不完全に指定されたプロンプトを \mathcal{P} へと展開します。これにより、著者らが指摘する二つの失敗モードが解消されます：空間的・幾何学的・外観的属性の欠如、および下流ステージで不整合な解釈をもたらすカテゴリ・スタイルの曖昧な参照です。構造化された仕様はステージ間のセマンティックなコントラクトとして機能します。
ステージ2 ——グローバル地形生成。 \mathcal{P} から、地形エージェントはグランドプレーンを地域に分割するセマンティックレイアウトマップを生成し、次に地域ごとの地形パラメータ（粗さ、標高範囲、バイオームタイプ）とマテリアル割り当てを持つ合成高さフィールドをインスタンス化します。地形関連アセット（岩、植生、水域）は、地域のセマンティクスとローカルな表面条件（傾斜、曲率）の両方に条件付けて散布されます。
ステージ3 ——地域オブジェクト生成と配置。 詳細が要求される各地域に対して、WorldClawは地形に条件付けられた合成画像を生成し、SAM3 / SAM3D / Hunyuan3Dを用いてそれをセグメント化・テクスチャ付きメッシュへと変換し、レンダリングされた構成にインスタンスポーズが一致するよう地形上への配置を復元します。これにより、本システムは編集可能なメッシュインスタンスを生成しながら、2D生成モデルの構成的事前分布を引き継ぐことができます。
レンダリングベースの改良。 独立した改良ループがレンダリングビューを通じてパイプラインを閉じます：
オブジェクト改良エージェントはレポートキューからインスタンスを取り出し、地域コンテキストに対してポーズ、メッシュ品質、スケールを評価し、ターゲットを絞った編集（再メッシュ化、再テクスチャ化、再ポーズ調整）を実行し、再レンダリングによって検証します。地形改良エージェントはオブジェクトが配置された支持面を検査し、浮き上がりや交差貫通を検出し、高さフィールドのローカルな協調変形を適用します——オブジェクト単体を移動させるのではなく \mathcal{T} を更新することで、オブジェクトと地形の接触を一貫したものにします。この協調変形が主要なメカニズム上の詳細です：改良は配置されたインスタンスとその下の支持面の両方に作用するため、接触の修正によってオブジェクトが計画された位置からずれてしまうという一般的なアーティファクトを回避します。
実装と結果
エージェントのバックボーンはClaude Opus 4.8であり、GPT-Image-2（画像生成）、SAM3 / SAM3D（セグメンテーションと変換）、Hunyuan3D（メッシュ＋PBRテクスチャ）に接続されたタスク固有のスキルをオーケストレーションします。PBRテクスチャ解像度は大型オブジェクトで 2048 \times 2048、小型オブジェクトで 1024 \times 1024 です。すべての幾何学的構成、改良、レンダリングはBlender 5.1.1上で4× NVIDIA H20 GPUを使用して実行されます。
実験セクションは定性的なものです。著者らは、異なる様式にわたる七つの完全なワールドを示しています：複数のバイオームにまたがる中世の村、雪に覆われた河川沿いの村、ドラゴンに囲まれた砂漠のキャンプ、日本の町並みの島、火山の悪魔の巣窟、宝石採掘場、ホビット村の山間の谷。それぞれについて、グローバルな軌道ビュー、地域ビュー、ローカルウォークビューとともに、明示的なシーングラフを示すインスタンス、深度、法線レンダリングが提示されています。インスタンスレンダリングは中心的な主張を裏付けています：アセットは暗黙的なフィールドに融合されることなく個別にアドレス可能であり、地形は地域をまたいで単一の一貫した表面を維持しています。
限界とオープンな課題
本論文は定量的なベンチマークを報告していません——FID/CLIPScoreなし、数値スコアを伴うユーザースタディなし、ワールドごとの処理時間やトークンコストの計測もありません。先行テキストからシーンへの変換システムとの比較は存在すると記述されていますが、提供されたセクションには数値の比較が示されていません。いくつかの依存コンポーネントは重い独占的なもの（Claude Opus 4.8、GPT-Image-2、Hunyuan3D）であり、再現性を複雑にするとともに、エージェントループの失敗モードの原因特定を困難にしています：改良ループが収束するのか、それとも反復予算によって上限が設けられているのか、地形協調変形がどの程度の頻度でトリガーされるのか、オブジェクト密度がワールド面積に対してどのようにスケールするのかが明らかではありません。高さフィールドによる地形表現はまた、オーバーハング、洞窟、負の空間幾何学を持つ崖を排除します——これはエージェント設計ではなく表現の構造的な限界です。最後に、地域レベルの構成的事前分布は2D画像生成器に由来しますが、スタイルのずれなしに数十の地域を持つワールドへとスケールするかどうかは示されていません。
重要性
WorldClawは「エージェントとしてのシーンコンパイラ」パターンの具体的なインスタンスです：モノリシックな3Dジェネレータを学習させるのではなく、LLMを使用して構造化された中間表現を計画し、明示的な幾何学的状態に対して特化された2D/3Dファンデーションモデルをディスパッチします。出力は編集可能なメッシュ＋高さフィールドのコンテンツであり、これはゲームエンジンや下流のシミュレータが実際に利用する表現です——ほとんどのコンテンツパイプラインにとって、radiance fieldよりも有用なターゲットです。
Source: https://arxiv.org/abs/2608.05248
GST-Bench: VLMはビデオからグローバルな空間認識を獲得できるか？
問題設定
VLMを対象とした既存の空間推論ベンチマークは、単一画像または少数視点によるVQA、すなわち「Xの左にあるのは何か？」「Yまでの距離は？」「相対的な奥行きは？」「物体の数は？」といった問いが中心です。これらは局所的な空間知覚を測るものであり、モデルが長時間の自己中心的な移動経路をまとまった大域的シーン表現として統合できるかどうかは検証しません。後者の能力こそが、自己位置推定・視野外の物体位置記憶・シーントポロジーに関する推論を求められる身体化エージェントにとって本質的な要件です。
GST-Benchはこのギャップを埋めることを目的としています。具体的には次の問いを立てます。長時間の探索ビデオと、ビデオに登場しない新規クエリ視点が与えられたとき、VLMは (i) 大域的なトップダウン座標系で自己位置を推定し、(ii) 現在の視野に映っていない物体を特定し、(iii) シーン全体のレイアウトについて推論できるか？
ベンチマークの構築
本ベンチマークは、自己位置推定・物体位置推定・シーン構造理解という3つの能力を軸に構成されており、12種類のタスクタイプとして具体化されています。
各問題には最大5種類の視覚入力が組み合わされます。
- 探索ビデオ：空間記憶の唯一の情報源となる、長時間にわたる自己中心的な移動映像；
- 物体アノテーション付きフレーム；
- 探索ビデオには登場しない1枚以上の新規視点画像（フレーム検索ではなく真のグローバル推論を要求するもの）；
- 3段階の抽象度（写真的・意味的・模式的）でレンダリングされたトップダウン画像（モデルは自己中心的な証拠と対応付けなければならない）；
- テキストクエリ。
データはシミュレーション環境で生成されており、グラウンドトゥルースのカメラポーズ・物体配置・トップダウンマップが利用可能です。パイプラインは探索ビデオ・新規視点レンダリング・トップダウンマップ・テンプレートに基づくQAを生成し、自動フィルタリングおよび人手によるベリフィケーションを適用します。
最終的なベンチマークは、合成ビデオ6,790分から生成された人手検証済みの問題で構成されています。新規視点の要件はこのベンチマークの核心的な設計上の選択です。クエリ視点は未見であるため、モデルはフレームマッチングや2次元の視覚的grounding によってタスクを解くことができず、内部的な大域マップを構築しなければなりません。
評価
22種類のVLMをgreedy decodingと公式プロンプトテンプレートを用いてゼロショットで評価しており、対象モデルは以下の通りです。
- プロプライエタリ：Gemini-2.5-Pro、Gemini-3-Pro、GPT-5、GPT-4o、Seed1.8；
- オープンソース：LLaVA-OneVision-1.5 (4B, 8B)、Qwen3-VL (2B/4B/8B/32B)、InternVL3.5 (2B/4B/8B/38B)、NVILA (8B/15B)；
- 身体化 fine-tuning 済み：Cosmos-Reason2 (2B, 8B)、RoboBrain2.5-8B、Robix (7B, 32B)；
- 本論文のGST-Train で fine-tuning した Qwen3-VL-8B。
主要な結果
最大のギャップとして、ゼロショットにおける最強モデルのスコアは42.68であるのに対し、人間のスコアは79.08に達します。このギャップはプロプライエタリなフロンティアモデルおよびより大規模なオープンソースモデルにおいても一貫しており、2Bから38Bへのスケーリングではこの差を埋めることができません。空間推論に特化した身体化 fine-tuning 済みモデル（Cosmos-Reason2、RoboBrain2.5、Robix）も、大域タスクにおいて汎用VLMを体系的に上回るわけではありません。
失敗の原因が空間知覚そのものにあるのか、それとも多数の視点を大域表現に集約するプロセスにあるのかを切り分けるため、著者らはGST-Bench-Localを構築しました。これは同一のタスク定式化と質問テンプレートを使いながら、証拠をローカルウィンドウに限定したものです。モデルはローカル版において大幅に高いスコアを記録しており、ボトルネックが局所的な幾何学的推論ではなく、長時間にわたる観測を大域的に整合したシーン表現へと統合することにあることが示されています。言い換えれば、現在のVLMは「この視点において自分からXはどこにあるか」という問いには比較的うまく対応できますが、数分にわたる移動を通じて持続的なマップを維持することには失敗します。
GST-Train（付随する学習セット）を用いてQwen3-VL-8BをGST-Bench上でfine-tuningすることで性能が向上しており、この能力不足が純粋にアーキテクチャ上の問題ではなく、データ分布の問題でもあることが示唆されています。ただし、論文は人間とのギャップを埋めると主張しているわけではありません。
限界と未解決の問題
- すべてのビデオは合成データです。診断的結論のsim-to-real転移は確立されておらず、実際の自己中心的ビデオにはモーションブラー・露出変動・動的エージェントが加わり、失敗モードが変化する可能性があります。
- 12種類のテンプレートベースのタスクタイプは能力別の明確なスコアを提供しますが、質問の表現が制約されており、モデルがテンプレートに過学習する可能性があります。
- ベンチマークは大域的な統合が失敗することを診断していますが、その原因候補——不十分な時間方向のコンテキスト長・フレーム間の弱い位置エンコーディング・明示的な3D帰納バイアスの欠如・持続的メモリモジュールの不在——を分離して特定してはいません。
- トップダウンマップは3段階の抽象度で画像入力として与えられますが、失敗がトップダウン画像を読むことにあるのか、ビデオから大域表現を構築することにあるのかは部分的にしか切り分けられていません。
- fine-tuning の結果は単一の8Bバックボーンに対して報告されており、GST-Train の教師信号のスケーリング挙動は明らかにされていません。
この研究の意義
GST-Benchは現在のVLMにおける具体的かつ機械論的に明確な欠陥を形式化しています。すなわち、VLMは空間を局所的に知覚することはできますが、自己中心的ビデオを大域的に整合したマップへと統合することができないという欠陥です。これはナビゲーション・操作計画・単一フレームを超えて機能する身体化ポリシーすべてに求められる能力です。42.68対79.08というギャップは、局所/大域のablationと組み合わさることで、時間的メモリおよび3D対応のビデオエンコーダに関する今後の研究に向けた具体的な目標を与えます。
Source: https://arxiv.org/abs/2608.05747
ChronoVision: 潜在状態再構成による時間的推論
問題設定
マルチモーダルLLMは静的な視覚的QAを得意としますが、時間を通じた連続的な視覚変換の追跡——遮蔽を経た物体の永続性、物理的な状態変化、因果関係で結びついたフレームの順序付け——を要するタスクでは性能が急激に低下します。著者らはその根本原因を言語ボトルネックにあると主張しています。すなわち、chain-of-thoughtにサブピクセルレベルや幾何学的な変換を言語化させることで、推論ステップを重ねるごとに曖昧さが蓄積されるのです。「ボールがわずかに左に動いて回転する」といった記述では、次の推論ステップが条件付けすべき実際の視覚状態が一意に定まりません。
ChronoVisionは、多段階の視覚的推論を再定式化し、中間状態を言語トークンではなく潜在視覚空間で表現するとともに、各推論ステップを特定の画像領域に結び付けるattention局所化メカニズムを追加します。
手法
このフレームワークは2段階（SFTの後にRL）で学習される3つの連結コンポーネントから構成されます。
Reconstructive Visual Head (RVH). SFT時には、標準的な自己回帰テキストlossに加え、補助ヘッドが変換後の最終視覚状態の潜在表現を予測します。z^* = E(I_T)をターゲット画像の凍結済み視覚encoder embeddingとし、\hat z = g_\phi(h_L)をMLLMの終端隠れ状態h_Lからヘッドが射影したものとすると、reconstruction lossは
\mathcal{L}_{\text{RVH}} = \lVert \hat z - \text{sg}(z^*) \rVert_2^2,
となり、ターゲットにはstop-gradientを適用します。これにより言語バックボーンは、視覚的な結果を名付けるだけで十分なトークンではなく、視覚的な結果を復元できる表現を維持することを強いられます。
ROI Attention Locating (RAL). 質問またはモデル自身の推論過程から抽出された名詞句であるsemantic span queryを、vision tokenへの空間的なattentionマスクに対応付けます。具体的には、span embedding q_sとvision token特徴量\{v_i\}に対して、RALはa_i = \text{softmax}(q_s^\top W v_i)を計算し、KLタームによるground-truth ROIマスクとの整合性\mathcal{L}_{\text{RAL}} = \text{KL}(a \Vert a^*)でaを監督します。これにより、各中間ステップが推論の根拠として主張する証拠の領域に接地されます。
暗黙的プロセス接地によるRL. 事後学習では複合rewardによるpolicy optimizationを用います：
R = \alpha R_{\text{ans}} + \beta R_{\text{lat}} + \gamma R_{\text{focus}},
ここでR_{\text{ans}} \in \{0,1\}は最終解の正誤、R_{\text{lat}} = \cos(\hat z, z^*)は最終答えが誤りであっても潜在状態の整合性に報酬を与え（dense processシグナル）、R_{\text{focus}}はエントロピーが低く時間的に一貫したRAL attention（すなわちモデルがステップをまたいで分散せずに一貫した物体を注視すること）に報酬を与える教師なし項です。潜在的な軌跡がground-truthの視覚的結果と照合されるため、ステップごとの人間によるアノテーションを必要とせずプロセス監督が実現されます。
SFT全体の目的関数は\mathcal{L} = \mathcal{L}_{\text{LM}} + \lambda_1 \mathcal{L}_{\text{RVH}} + \lambda_2 \mathcal{L}_{\text{RAL}}です。
Vbvr-VQAデータセット. 著者らは動画推論を厳密なフレーム順序付けタスクとして再定式化しています。因果的または物理的なイベントを含む動画のシャッフルされたフレーム集合が与えられ、モデルは正しい時間的順序を出力しなければなりません。これにより、時間的追跡が言語的な事前知識から分離されます——隣接フレームのキャプションはほぼ同一であるため、キャプションによるショートカットでは解けないのです。データセットはin-domainとout-of-domainの分割を持ちます（イベントカテゴリ・ドメインが異なります）。
結果
Vbvr-VQAにおいて、ChronoVisionはin-domain精度74.8%、out-of-domain精度71.6%を達成し、このベンチマークの最先端として報告されています。OODギャップが約3.2ポイントと小さいことは、潜在再構成目的関数が訓練時のイベント分布に対するフレーム順序ヒューリスティックの記憶ではなく、分布外への転移が可能な表現を促進していることを示唆しています。
abstractはablationの前で打ち切られていますが、複合reward構造から3つのコンポーネント（R_{\text{ans}}、R_{\text{lat}}、R_{\text{focus}}）がそれぞれ独立に貢献していることが示唆されます。RVHはメカニズム的に最も新規性の高い部分であり、テキストを超えて連続的な視覚状態がlossに入り込む唯一のチャネルであることから、おそらく最大の寄与因子です。
限界と未解決の問題
本記述からいくつかの問題点が見えてきます。第一に、ターゲット潜在変数z^* = E(I_T)は凍結されたencoderの性能に上限を受けるため、Eがタスクの実際の依存する細粒度の手がかり（姿勢、遮蔽境界）を捨て去っている場合、RVHはそれを復元できません。第二に、順序付けタスクは推論をpermutation出力空間に制限しており、open-endedな視覚的QAよりもreward shapingが容易です——潜在状態アプローチが生成的反事実推論（「もし……だったらそのシーンはどのように見えるか」）に有効かどうかは不明です。第三に、R_{\text{focus}}は教師なしであり、自明に確信度が高いが誤ったattentionに崩壊する可能性があります。focus rewardのハッキングが抑制されていることを論文が示すべきです。第四に、SFT時のROI監督はspanと領域のアライメントを必要とし、キュレートされたデータ以外では大規模に取得するコストが高くなります。最後に、abstractでは強力なクローズドソースベースライン（GPT-4o、Gemini）のVbvr-VQAにおける比較数値が示されておらず、絶対的な位置付けが不明です。
未解決の問題として、RVHによって復元される潜在的な軌跡が解釈可能な中間状態に対応しているか（例：中間層で\hat zをデコードしてもっともらしいフレームが得られるか）という点があります。また、このアプローチが組み合わせ可能かどうか——すなわち長さ>2の推論チェーンに対して複数のRVHターゲットを連鎖させられるか——も未解決です。
なぜ重要か
言語化されたchain-of-thoughtは連続的な視覚的ダイナミクスに対してロスの大きいチャネルであり、コミュニティはこれをテキストトレースのスケーリングによって大部分回避してきました。ChronoVisionは、潜在視覚空間における中間推論の監督を、領域接地されたattentionとプロセスレベルのRL rewardと組み合わせることで、ステップごとの人間ラベルを必要とせずに時間的推論を実質的に改善できることを具体的に示しています。RVHメカニズムが順序付けを超えて予測・反事実タスクへと汎化するなら、それは内部推論が言語を通じた翻訳ではなく真にマルチモーダルなMLLMへの道を示しています。
Source: https://arxiv.org/abs/2608.05631
HarnessOpt-Bench: LLMによるハーネス最適化の評価
問題設定
エージェントの性能は、基盤となるLLMとハーネス（プロンプト、ツールラッパー、メモリ、制御フロー、オーケストレーションコード）の両方に依存します。実務家は現在、重みの fine-tuning よりもハーネスのチューニングに多くの労力を費やすことが一般的になっており、そのチューニング自体をLLMに委ねるケースも増えています。しかし、フロンティアモデルが現実的な制約下でハーネスオプティマイザとしてどの程度機能するかを測定するための標準的なプロトコルはこれまで存在しませんでした。その制約とは、コストのかかる確率的評価、held-out汎化、テストセット情報の漏洩防止などです。HarnessOpt-Benchはこのギャップを埋めるとともに、現在のフロンティアモデルをスキャフォールドライターとして定量的に比較します。
タスクの形式化
候補ハーネス H は実行可能なコードベースであり、実現可能集合 \mathcal{H} に属し、固定されたシード H_0 を持ちます。タスクは不変量 \theta=(\mathcal{M},E,V) を固定します：呼び出し可能なモデルの集合 \mathcal{M}、ケースごとの環境 E(x)、そして検証器 V:\text{trajectory}\to[0,1] です。オプティマイザは H を編集しますが、\theta は変更できません。目標評価バジェット B とフィードバック開示ポリシー \pi_\mathcal{D} が与えられた下で、オプティマイザは候補 H' を逐次コミットし、ケース集合 Q を要求し、フィードバック \pi_\mathcal{D}(\hat s,\varphi) とともに (\hat s,\varphi)\leftarrow F_\theta(H,Q) を受け取り、最終的に H^+\in\mathcal{C} を指名します。サーバーは held-out \mathcal{D}^{\text{test}} 上で H^+ を評価し、シードに対する正規化利得 g を報告します。
このベンチマークを非自明にしているのが強制機構です。信頼された実行サーバーが評価の境界を管理しており、オプティマイザはターゲットハーネスの書き込みと開発トレースおよび集約バリデーションメトリクスの読み取りのみが可能で、テストケースやテストスコアには触れられません。
リソース計測、候補バージョン管理、監査ログは信頼された側に置かれており、これによってテストセットの偶発的汚染と可視バリデーションシグナルへのGoodhart化の両方を防止しています。
実験グリッド
5つのフロンティアモデルを評価します：claude-opus-5、claude-sonnet-5、gpt-5.6-sol、gpt-5.6-terra、kimi-k3。各オプティマイザモデルは2種類のコーディングハーネス上で実行されます：モデル間で共通の opencode スキャフォールド（モデル間で固定）と、モデルファミリー固有のネイティブハーネス（claude-code、codex、kimi-cli）です。これにより10のコアオプティマイザ構成が得られ、4つのターゲットエージェントタスク（OfficeQA、BrowseComp-Plus、Terminal-Bench、GAIA）で実行されます。GAIAでは2つの追加共有ハーネス（goose、mini-swe-agent）が加わり、モデル固定のもとで4レベルのハーネスが得られます。能力ラダー研究として、OfficeQA上でClaudeOpusとGPTの旧リリースをネイティブハーネスで実行します。
主要結果
主要な分解結果として、タスクとハーネスを固定してオプティマイザモデルを変更すると正規化利得は平均0.142変化し、タスクとモデルを固定してコーディングハーネスを変更すると0.079変化します。モデルの選択はハーネスの効果のおよそ 1.8\times です。両者ともタスクごとの解像度バンドを超えていますが、ハーネス効果はわずかに超える程度です。
左パネルは制御された2ハーネス設計における実行ごとの利得を示しており、マーカーの形状がハーネスを示し、縦方向の広がりはスキャフォールドではなくモデルのアイデンティティに支配されています。右パネルは、3つの有能シードタスクにわたるバランスされた共有ハーネスグリッドにおけるLSS-\lambda（分散分解推定量）を示し、同じ順序を定量化しています。
テール部分は明確に分離される一方、中間は分離されません。最強の構成ではシードに対するOfficeQAヘッドルームの約3分の2、BrowseComp-Plusヘッドルームの約半分を回復しますが、最弱の構成はBrowseComp-PlusおよびTerminal-Benchにおいてゼロから未解決、すなわちシードハーネスに対する統計的に検出可能な改善が見られません。中間の構成はラウンド間の分散よりも差が小さいため、著者らは厳密なランキングではなく階層を報告しています。
4レベルのハーネスが利用可能なGAIAでは、単一のハーネスが支配することはありません。
両GPTバリアントはネイティブの codex ハーネス下で大幅な利得を示します——最良の共有代替案と比較して gpt-5.6-sol で +0.179、gpt-5.6-terra で +0.131——一方で、両Claudeモデルおよびkimiはいずれの方向でも解像度バンド1〜2の範囲に収まっています。これは「LLM-as-optimizerにとって最良のコーディングハーネス」がモデル依存であるという直接的な証拠です：単一スキャフォールドを固定した推奨は汎化性能が低いと言えます。
最後に、リリースラダーのアブレーションでは、ClaudeOpusとGPTの連続リリースがOfficeQAにおいて \pm 0.045 の解像度バンドを超える単調な改善を示しており、ハーネス最適化スキルが狭く訓練された能力ではなく一般的な能力に追随するという解釈を支持しています。
制限と未解決の課題
このベンチマークはシングル指名のエンドツーエンドプロトコルを測定しているため、探索・検証・自己停止を1つのスコアに混在させており、これらを分離するには異なるインタラクションポリシー \pi が必要です。使用タスクは4つのみであり、そのうち2つ（BrowseComp-Plus、Terminal-Bench）はシードが十分に強いため、複数のオプティマイザが改善に失敗しており、識別範囲が圧縮されています。信頼された実行サーバーはテスト漏洩を防ぎますが、B が大きい場合のバリデーションパーティションへの過学習は防げません；論文では利得が B とともにどのようにスケールするかは報告されていません。マルチエージェントハーネスや補助訓練のために \mathcal{M} を呼び出すハーネスへの拡張には、不変量 \theta の再定義が必要になります。
なぜ重要か
ハーネス最適化がAI開発のファーストクラスのサブルーティンになりつつある今、どのオプティマイザとスキャフォールドの組み合わせが実際にエージェントを改善するかについて、民間知識ではなく共有された数値的証拠が必要です。HarnessOpt-Benchは、その効果が実在すること（モデルのハーネスに対する効果は 1.8\times）、モデル依存性が非自明であること（ネイティブ codex はGPTを大幅に改善するが、ネイティブスキャフォールドはClaudeやKimiをそれほど改善しない）、そして基盤モデルの能力と相関していることを示しており——これは有界かつ監査可能な形式での再帰的自己改善を追跡するための具体的な基盤となります。
Source: https://arxiv.org/abs/2608.06301
Hacker News Signals
Prime Agent: 自己改善型RLMエージェント
Prime Intellectは、Prime Agentをreinforcement-learning-from-model-feedback（RLMF）ループとして説明しています。このループでは、エージェントが自身の出力を報酬信号として扱うことで、自らのpolicyを改善します。核心となるアイデアはブートストラップ型の自己改善です。エージェントは候補となる解を生成し、それをverifier（自身、あるいはより強力なジャッジ）でスコアリングし、高報酬のtrajectoryに対してfine-tuningを行います。これはRLHF/RLAIFの馴染み深いパターンですが、離散的なトレーニングランではなく継続的に適用される点が異なります。
エンジニアリング面での特徴は、Prime Intellectの分散トレーニングインフラとの統合にあります。オフラインのバッチRLではなく、推論と交互にオンラインのpolicy更新を実行し、エージェントを停止させることなくgradient更新を供給するrolloutバッファを維持しています。これには、self-playレジームにおける既知の失敗モードである分布崩壊（distribution collapse）と報酬ハッキング（reward hacking）を回避するための、慎重なreplay-buffer管理が必要です。
「RLM」（Reinforcement Learning Model）というフレーミングは、報酬信号がモデルによって生成されるエージェントを、人間のラベルやハードコードされたverifierを使用するエージェントから区別するものです。これは重要な区別です。なぜなら、reward modelの精度がボトルネックとなる制約であり、自己参照的なループはreward modelのバイアスを増幅させるためです。ブログ記事では、reward modelの崩壊をどのように緩和するかについて詳述されておらず、これがここでの主要な未解決問題となっています。
実際的な詳細は乏しく、ベンチマーク数値は公開されておらず、reward modelとpolicy modelのアーキテクチャも明示されていません。見えているのはスキャフォールディング（足場）の部分です。ツール使用、マルチステップ計画、そしてrolling evalスコアが閾値を超えて改善するたびにpolicyをチェックポイントするループが実装されています。
これは初期段階の研究です。興味深い研究上の問いは、人間のフィードバックによるチェックポイントを持たない継続的な自己改善が収束するのか、それとも漂流（drift）するのか、という点です。いずれの方向であれ、実証的なエビデンスは非常に価値があるでしょう。
Source: https://www.primeintellect.ai/blog/prime-agent
ASICをリバースエンジニアリングできるか？
Jane Streetの投稿は、実際のASICに対する物理的リバースエンジニアリングの実践的な解説であり、通常はハードウェアセキュリティラボに関連する種類の作業です。このプロセスには、チップのデパッケージング（化学的または機械的なデキャップ）、走査型電子顕微鏡（SEM）または集束イオンビーム（FIB）によるレイヤーの撮像、そしてメタル配線層をトレースしてネットリストを再構築する作業が含まれます。
主な技術的課題は、（1）レイヤー数——現代のプロセスは10層以上のメタル層を持ち、それぞれに個別のデレイヤリングと撮像が必要であること、（2）セルの識別——7 nm以下の標準セルは100 nm未満のフィーチャーサイズであり、光学顕微鏡は使用不能で電子ビーム撮像が必要であること、（3）ネットリストの抽出——2Dレイヤー画像の集合から機能的な回路を再現するには、画像のスティッチング、配線とビアのセグメンテーション、および既知のライブラリに対するセルのマッチングが必要であること、の3点です。最後のステップは、ファブの標準セルライブラリが既知であるか推定可能な場合には実行可能ですが、フルカスタムロジックに対しては困難です。
Jane Streetがこのテーマに関心を持つのはセキュリティ志向によるものです——ASICが実際に何をするのかと、そのベンダーが主張する内容との間のギャップを理解するためです。金融インフラにとって、クリティカルパス上のサードパーティASIC（ネットワークアクセラレーターやハードIPを持つFPGA）は、現実のサプライチェーンリスクです。この投稿は正直に述べており、先進ノードにおける現代のASICの完全なリバースエンジニアリングは高価（商業ラボでは6〜7桁ドル規模）かつ時間がかかるため、日常的な監査としては非現実的であると認めています。
この投稿では部分的なリバースエンジニアリングについても触れています——特定のプロパティ（例えば、隠された無線インターフェースがないこと、予期しないメモリがないこと）を検証するためにフルネットリストを復元する必要はないということです。ターゲットを絞ったFIBクロスセクションは、完全な再構築よりも低コストで限定的な問いに答えられます。
未解決の問題：チップレットと2.5Dパッケージングが標準になるにつれて、ダイ間の配線がインターポーザーの下に埋め込まれるため、リバースエンジニアリングはより困難になっています。
Source: https://blog.janestreet.com/can-you-reverse-engineer-an-asic/
AMDがTaalasを買収し、モデルをシリコンに刻み込むことでinference性能を向上
Taalasはmodel-in-silicon（MiS）inference acceleratorの開発に取り組んでいました。これは、特定のニューラルネットワークの重みをランタイム時にDRAMからロードするのではなく、テープアウト時にハードウェアファブリックに直接エンコードするASICです。このアプローチは柔軟性をレイテンシおよび消費電力と引き換えにするものです。重みがシリコンに固定される（ROMとして、あるいはハードワイヤードな相互接続パターンとして）と、transformer inferenceを支配するメモリ帯域幅のボトルネックを完全に排除できます。
この技術自体は新しいものではなく、ニューロモルフィックコンピューティングやルックアップテーブルベースのinferenceにその起源を持ちますが、特定のニッチ領域において新たに注目を集めています。それは、同一のモデルを年単位で大規模に稼働させる高ボリューム・安定的なモデルデプロイメントです（固定された embedding モデルや特定のASRシステムなどが例として挙げられます）。提案される価値は、特に小バッチまたはシングルトークンの自己回帰デコーディングにおいて、LLM inferenceの支配的な制約がFLOP数ではなくDRAM帯域幅であるという点です。重みがオンダイROMに存在するか構造的にエンコードされているチップは、この問題を根本から回避できます。
困難なエンジニアリング上の問題は、最先端モデルが6〜12ヶ月サイクルで変化するため、固定重みのASICは商業的リスクを伴うという点です。Taalasの解決策は、モデル全体ではなく特定のレイヤーやサブネットワーク（例えば固定された embedding テーブルや固定されたKV-projection head）を対象とし、ハードワイヤードな基盤と揮発性の部分に対応した小規模なプログラマブル部分を組み合わせることであったようです。
AMDの戦略的な動機は、ハイパースケーラーワークロードにおいてGoogle（TPU）、Amazon（Trainium/Inferentia）、Microsoft（Maia）のカスタムinferenceシリコンと競合することにあります。MiS技術をROCm互換のチップレットに統合することで、AMDはまったく別個のISAを必要とせずに、階層的なinferenceシリコンを提供できるようになります。
Taalasのシリコンの買収価格および技術的成熟度は開示されていないため、量産可能なシリコンではなく、設計IPを持つチームのacqui-hireである可能性もあります。
Stateless MCPが再び私の関心を引いた
Simon Willisonの投稿は、Model Context Protocol（MCP）の仕様にstateless HTTPトランスポートモードが追加されたことを受けた、技術的な再評価です。元々のMCPは持続的なSSE接続に依存していたため、実運用上の深刻な問題が生じていました。具体的には、サーバーがセッションごとの状態を維持しなければならない点、水平スケーリングにスティッキーセッションや共有状態ストアが必要な点、そして接続が切れた際にセッションが失われた状態で完全な再接続を強いられる点が挙げられます。
statelessの変形では、各MCPリクエストが自己完結したHTTPリクエスト／レスポンスのサイクルに対応します。ツール呼び出し、リソース読み取り、promptの取得はいずれも、サーバー側のセッション状態に依存するのではなく、完全なコンテキストをインラインで運びます。これにより、既存のインフラ（ロードバランサー、CDN、serverlessプラットフォーム）がすでに正しく扱えるREST／HTTPのセマンティクスとMCPが一致することになります。
トレードオフはペイロードサイズです。statelessなリクエストは、サーバーが事前のやり取りなしに正確に応答できるだけの十分なコンテキストを運ばなければなりません。これは冪等なツール呼び出し（明示的な引数を持つ関数）には問題ありませんが、本質的に蓄積された状態を必要とするツール（例：マルチターンのデータベーストランザクション）には問題となります。仕様では、サーバーがクライアントに返すstate tokenをクライアントが折り返し送信することを許容することでこれに対処しており、状態管理をサーバーではなくクライアントに委ねるアプローチ——署名付きJWTに似た手法——を採用しています。
Willisonが特に関心を持っているのは、stateless HTTPとの相性は良いものの持続的SSEには不向きなserverless関数（Cloudflare Workers、Lambda）へのMCPサーバーのデプロイです。また、stateless MCPによってテストが簡易化される点にも言及しており、テストはJSONボディを持つHTTPリクエスト一つで済み、SSEハーネスが不要になると述べています。
彼が指摘する残る摩擦点はAuthです。現行仕様のOAuthフローはstatelessなコンテキストで正しく実装するには依然として複雑であり、仕様はいくつかのセキュリティ上の判断を実装者に委ねています。
Source: https://simonwillison.net/2026/Jul/31/stateless-mcp/
LLMは対称暗号を破れない
この投稿は、厳密な技術的議論を展開しています。すなわち、現在のLLMは対称暗号プリミティブ（AES、ChaCha20、SHA-2/3）を攻撃するために必要な、持続的かつビット単位で正確な計算を実行できず、またスケールによってその状況が変わりそうにないアーキテクチャ上の理由についても論じています。
中心的な主張は、対称暗号解読は構造的弱点（差分・線形特性、代数的関係）の探索か、総当たり鍵探索のいずれかに帰着するというものです。前者は指数的に広大な空間上での正確な算術を伴う組み合わせ探索を必要としますが、これはtransformerのattentionが全数探索に対して既知の効率的優位性を持たない問題です。後者は 2^{128} スケールでの明らかに並列化可能な整数演算であり、transformerが訓練された用途でも効率的に実行できる処理でもありません。
著者は、LLMが実際に暗号リスクをもたらす領域—ソーシャルエンジニアリング、微妙な脆弱性を含むコード生成、プロンプトを通じたサイドチャネル漏洩—についてはこれと区別しています。これらは現実のリスクであり、すでに観測されています。この投稿は、LLMがプリミティブのレベルで暗号上の脅威になるという誇大な主張に対して反論しています。
差分暗号解読についても、より微妙な指摘があります。暗号解読の文献で訓練されたLLMは既知の攻撃を説明できますが、攻撃を説明することとそれを実行することは別物です。AESに対する差分攻撃を実行するには、差分分布表における衝突を見つける必要があります。これは近似ではなく正確に行わなければならない計算であり、実用的であるためには 2^{50} 回以上の試行が必要です。自己回帰的なトークン生成はこれに適した基盤ではありません。
投稿が十分に扱っていない未解決の問いとして、将来のLLM誘導ソルバー（モデル + SMTソルバー + MILP）がラウンド数を削減した暗号への代数攻撃を加速できるかどうかという問題があります。これはより現実的な脅威領域ですが、それでも運用可能な対称鍵の解読には程遠い状況です。
Source: https://www.bfswa.blog/p/llms-wont-break-symmetric-crypto
Qwen3.8 Max、agentic indexにて総合1位を獲得
Artificial AnalysisのAgentic indexは、単発の質問応答ではなく、複数ステップにわたるツール使用タスクを対象としたbenchmark suiteです。その方法論は重要です。静的なデータセット上での精度を測定するのではなく、agentic benchmarkはモデルがツール呼び出しを連鎖させ、エラーから回復し、複数ターンにわたる計画を必要とするタスクを完了する能力を評価します。評価指標には、タスク完了率、完了までのステップ数、およびコストパータスク（トークン消費量を加味したもの）が含まれます。
Qwen3.8 Maxがこのランキングのトップに達したことは、技術的に注目に値します。なぜなら、このモデルはGPT-4クラスのモデルと比べてパラメータ数がはるかに少なく、推論コストも大幅に低いからです。Artificial Analysisのデータによれば、標準的な能力benchmarkでは競争力はあるものの支配的とは言えない一方で、agentic metricsにおいては大規模な独自モデルをも上回っています。これは、このモデルが広範な知識よりも、複数ステップの推論とツール使用に向けて明示的に最適化またはfine-tuningされたことを示唆しています。
モデルをagentic tasksにおいて強力にする技術的な要因は完全には解明されていませんが、経験的な相関要因としては、構造化された出力フォーマット（JSONツール呼び出し）に対する確実なinstruction following、関数シグネチャにおける低いhallucination率、そして同じ呼び出しを繰り返すのではなく再計画によってツールエラーから回復する能力が挙げられます。検証可能な複数ステップタスクに対するRLで学習されたモデル（DeepSeek-R1のアプローチに類似したもの）は、この評価でより高いスコアを得る傾向があります。
注意点：Artificial AnalysisのAgentic indexは査読済みbenchmarkとして公開されているわけではなく、タスクの分布がQwenの学習データのパターンに有利に働いている可能性があります。ランキングがbenchmark固有のものでないことを確認するには、非公開のタスクスイートでの独立した再現実験が必要です。
Source: https://artificialanalysis.ai/?intelligence=agentic-index
Celld: セルフホスト型分散 Durable Objects
Celldは、CloudflareのDurable Objects（DO）プログラミングモデルをセルフホスト可能な分散ランタイムとして実装したDeno-landプロジェクトです。DOモデルは、ストレージと同じ場所に配置されたシングルスレッドのステートフルアクターを提供します。各オブジェクトインスタンスはキーバリューストアを所有し、リクエストを一度に一つ処理し、グローバルに一意なIDによってアドレス指定が可能です。重要な特性は、調整なしの強整合性です。オブジェクトのストレージへの読み書きはアクター自身によってシリアライズされるため、オブジェクト単位の操作に分散ロックやコンセンサスは不要です。
Celldはこれを、オブジェクトインスタンスをV8 isolate（DenoのIsolateインフラを再利用）として実行し、設定可能なバックエンド（ローカル開発にはSQLite、本番環境には分散KV）に状態を永続化し、オブジェクトIDのconsistent hashingによって適切なノードへリクエストをルーティングすることで実現しています。ノードに障害が発生すると、オブジェクトはマイグレーションされます。コーディネーターが障害を検知し、リクエストを新しいノードへ再ルーティングし、オブジェクトは次のリクエストを処理する前に永続バックエンドから状態を再ハイドレートします。
ここでの分散システムの難問は、フェイルオーバー時のexactly-onceセマンティクスです。Celldのアプローチでは、オブジェクトごとのwrite-ahead logとfencing tokenを組み合わせることで、マイグレーション後に障害ノード上のゾンビインスタンスが古いリクエストを処理するのを防いでいるようです。詳細はドキュメントに明示されておらずソースコード中にあるため、本番環境で利用する前に精読することをお勧めします。
パフォーマンス特性において、CloudflareのホスティングDOとの重要な違いが一点あります。Cloudflareはオブジェクトのストレージをコンピュートと同じ場所に配置することでサブミリ秒のストレージアクセスを実現しています。ネットワーク越しのKVバックエンドを使用するCelldではストレージレイテンシが高くなり、これはリクエストレートに制限のあるアクターにとって影響があります。
これは主に、Cloudflareのベンダーロックインを避けつつDOプログラミングモデルを必要とするチーム、あるいはwranglerを使わずにDOベースのコードをローカルでテストしたいチームにとって有用です。
Source: https://github.com/denoland/celld
Show HN: The Channels SDK – Bring Any Agent to Any Channel
CopilotKitのChannels SDKは、LLMを基盤とするエージェントをメッセージングプラットフォーム（Slack、Microsoft Teams、Discord、および汎用webhook）に接続するための抽象化レイヤーです。このSDKが解決する核心的な技術的問題は、エージェントAPIとプラットフォームAPIの間のインピーダンスミスマッチです。各メッセージングプラットフォームは固有のイベントモデル（SlackのEvents API対TeamsのBot Framework対Discordのgateway）、認証スキーム、およびインタラクティブコンポーネントモデル（Block Kit対Adaptive Cards）を持っています。
このSDKはこれらを単一のエージェント向けインターフェースに正規化します。エージェントは正規化されたスキーマを持つMessageオブジェクトを受け取り、ロジックを実行し、Responseオブジェクトを返します。SDKはプラットフォーム固有のフォーマットへのシリアライズを処理し、OAuthトークンとwebhook検証を管理し、新しいプラットフォームを追加するための薄いアダプターインターフェースを公開します。
興味深いエンジニアリング上のトレードオフは、ステートフルな会話の処理方法にあります。Slackのスレッドとのコンversation IDは自然なグルーピングを提供しますが、SDKはエージェントにプラットフォーム間で一貫したスレッドIDを与えるために会話コンテキストのマッピングを維持しなければなりません。この実装ではこのマッピングを永続化し、ターン間のエージェント側の会話状態を保存するために（プラグイン可能な）key-valueストアを使用しています。
CopilotKitの既存のエージェントインフラストラクチャとの統合により、SDKは標準プロトコルを介してLangGraphやその他のグラフベースのエージェントフレームワークにフックされます。これにより、同一のエージェントグラフをコードを変更することなく複数のチャンネルにデプロイできます。これこそが真の価値です。つまり、エージェントを一度記述し、コード変更ではなくアダプターの設定によって複数のチャンネルにルーティングするということです。
リポジトリから確認できる制限事項として、プラットフォームAPIのレートリミットに対するエラーハンドリングが最小限であること、およびテキストとボタンの抽象化にきれいにマッピングできないプラットフォーム固有のリッチなインタラクション（投票、承認フロー）のビルトインサポートが存在しないことが挙げられます。
注目の新しいリポジトリ
kirodotdev/KiroCrew
セッションをまたいでコンテキストと状態を維持することを目的とした永続的なマルチエージェント開発ワークスペースであり、ほとんどのエージェント型コーディング環境が呼び出しのたびにリセットされるという根本的な問題に対処しています。KiroCrewは、タスク履歴・アーキテクチャ上の意思決定・中間成果物といった構造化されたプロジェクトメモリを保存することで、エージェントがコンテキストを再導出することなく作業を再開できるようにします。自己改善ループにより、システムは過去のタスク結果に基づいて自身の計画ヒューリスティクスを洗練させることができます。アーキテクチャは、オーケストレーター（メモリとタスクルーティングを管理）とエグゼキューターエージェント（コード生成・テスト・レビューを担当）を分離しており、個々のエージェントバックエンドを差し替えることが可能です。主にTypeScriptで構築されており、単一セッションのエージェントが繰り返しコンテキストを失ってリグレッションを引き起こす、長期的なソフトウェアプロジェクトを運用するチームを対象としています。永続化レイヤーはワークスペース状態をローカルストアにシリアライズするため、クラウドへのロックインなしにマシン間で可搬性が確保されます。生のClaude Codeセッションのようなエフェメラルなツールと比較して、KiroCrewは各エージェントが何を行い、その理由は何かについての再現可能な監査証跡を提供しており、これはエージェントが引き起こしたリグレッションのデバッグにおいて重要です。
Source: https://github.com/kirodotdev/KiroCrew
mereyabdenbekuly-ctrl/clodex-ide
エージェント型ソフトウェア開発のためにゼロトラストセキュリティモデルを中心に設計された、ローカルファーストのIDEです。核心となる前提は、自律エージェントが検証可能な実行環境で動作すべきというものであり、ファイル書き込み・シェルコマンド・ネットワーク呼び出しといったすべてのアクションが、実行前後においてログに記録され、ハッシュチェーンによって連結され、監査可能な状態に保たれます。「ゼロトラスト」というフレーミングは、IDEがエージェントの出力を安全なものとみなさないことを意味しており、その代わりにアクションをコミットする前にポリシーマニフェストと照合して検証する層を介在させます。これは、LLMをファイルシステムツールでラップするアプローチとはアーキテクチャ上明確に異なります。Clodex-IDEは検証可能性をファーストクラスのプリミティブとして扱い、外部で再生または監査できる署名付き実行レシートを発行します。ローカルファーストの設計により、エージェントの出力が外部インフラを経由しないため、プロプライエタリなコードベースにおいて重要な意味を持ちます。標準的なコーディングエージェントUI（Cursor、Copilot Workspace）では提供されない監査可能性の保証を必要とする開発者を対象としています。まだ初期段階ではありますが、ポリシーマニフェストとレシート署名のアーキテクチャという観点から技術的に興味深い内容です。
Source: https://github.com/mereyabdenbekuly-ctrl/clodex-ide
mikehasa/agentacct
コーディングエージェント（Claude Code、OpenAI Codex、OpenCode、その他）向けのローカル観測可能性ダッシュボードです。コストの帰属と作業ステップの分解に焦点を当てています。各エージェントセッションは離散的なステップに分解され、それぞれに関連するメタデータが付与されます：実行されたツール呼び出し、読み書きされたファイル、テストの実行回数、実時間、そしてモデルごとのトークン消費量です。ダッシュボードはログインやテレメトリなしに完全にローカルで動作するため、機密要件のあるチームにも適しています。技術的には、agentacctはサポートされているランタイムが生成するエージェントのログストリームまたは構造化出力ファイルにフックし、それらを正規化されたステップスキーマに解析した上で、ローカルのWeb UIを通じてレンダリングします。トークンコストの集計はモデルを認識しており、トークン単価を適用してタスクごとのコスト内訳を生成します。提供する価値は、エージェント自身のUIが隠蔽しているエージェントの動作に対する可視性です。具体的には「このタスクがなぜ$4かかり12分かかったのか」という問いに対して、集計値ではなくトレーサブルなステップごとの内訳で答えます。コストの最適化や暴走したエージェントループのデバッグの両方に役立ちます。
Source: https://github.com/mikehasa/agentacct
deerwork-ai/deer-workflow
ワークフローのトポロジーをTypeScriptで定義し、セマンティックな実行をプラガブルなagent runtimeに委譲する、グラフベースのagentオーケストレーションruntimeです。本設計は、多くのオーケストレーションフレームワークが混同している2つの関心事を分離しています。制御フローグラフ（ノード遷移、分岐条件、リトライロジック、並列性）は型付きTypeScriptに留まるため静的解析が可能であり、一方で「何らかの知的処理を行う」ノードは交換可能なバックエンド——任意のLLM agent、ツール使用システム、または外部API——を呼び出します。これにより、いかなるモデルとも独立してグラフ構造をユニットテストでき、オーケストレーションロジックを配線し直すことなくセマンティックなバックエンドを入れ替えることが可能です。runtimeはノードのライフサイクル、ノード間の状態伝播、およびエラーリカバリを処理します。アーキテクチャ的にはLangGraphに類似していますが、よりTypeScriptネイティブな型システムを重視し、runtime／オーケストレーションの境界を明示的に設けている点が異なります。オープンソースのグラフエンジニアリングという枠組みは、フレームワークベンダーのagent抽象に依存することなくオーケストレーション層を自社管理したいプラットフォームチームを対象としています。
Source: https://github.com/deerwork-ai/deer-workflow
Optim-Agent/optim-plans
ClaudeおよびCodex向けのhuman-in-the-loopプランニングプラグインで、アイデアの発案から実行までの間に、構造化されたレビューおよび承認ステージを挿入するものです。ワークフローは次の通りです：エージェントが自然言語のアイデアを明示的な意思決定ポイントを含むMarkdownプランに変換し、人間がそのプランをレビューして注釈を付け（ステップの承認・却下・修正）、明示的なゲート承認が得られた後にのみ実行が進められます。意思決定の記録はプランとともに監査用に保存されます。「execution gates」はコントローラprimitiveによって強制されます。これらはテスト済みで組み合わせ可能なビルディングブロックであり、記録された人間の承認シグナルなしにエージェントがチェックポイントを通過することを防ぎます。これは、エージェントシステムにおける実際の障害モードに対処するものです。具体的には、沈黙から承認を推論するエージェントや、時間的プレッシャーのもとで確認ステップをスキップするエージェントへの対策です。テスト済みのコントローラprimitiveが技術的に実質的な部分であり、ゲートが設けられたステップ周辺に検証可能な事前・事後条件チェックを提供します。これにより、ゲートの強制をpromptレベルの指示に依存する必要がなくなります。デプロイメントやデータの変更など、不可逆的な操作に対して人間の承認が必要なあらゆるワークフローに有用です。
Source: https://github.com/Optim-Agent/optim-plans
gakonst/nanocodex
OpenAI互換のエージェントパイプラインを構築するためのビルディングブロックを提供するRustライブラリです。PythonSDKのオーバーヘッドが許容できない、パフォーマンスクリティカルまたはリソース制約のあるデプロイメントをターゲットとしています。このcrateは、OpenAIのResponses APIおよびChat Completions APIに対する型付き抽象化、ツール/関数呼び出しの処理、streaming、およびエージェントループのプリミティブを公開しており、完全なPythonオーケストレーションスタックを導入することなくCodexスタイルのエージェントを実行するために必要な最小限のscaffoldingを提供します。Rustで構築することで、メモリ安全性、予測可能なレイテンシ、およびPythonインタープリタをホストできないシステムソフトウェア（CLIツール、デーモン、エッジランタイム）への組み込みへの適性が得られます。「Rustによるfrontier agents」というフレーミングは、既存のギャップを反映しています。PythonはLLMツーリングを支配していますが、システムズコンテキストには適していません。Ethereumツーリングにおけるfoundryおよびalloyで知られるgakonst氏によるこのライブラリは、スクリプト言語のツーリングが支配していた領域に厳格なRustエンジニアリングの規律をもたらすという同じパターンに従っています。まだ初期段階ですが、Pythonなしでエージェント機能を求めるシステムエンジニアにとって実際のニッチを埋めるものです。
Source: https://github.com/gakonst/nanocodex
KlaatAI/klaatcode
オープンソースのターミナルネイティブなAIコーディングエージェントで、タスクの特性に基づいてClaude、GPT-4クラス、Gemini、DeepSeekのモデルを選択するmodel-routingレイヤーを備えています。すべてのリクエストを最も高性能（かつ最もコストの高い）モデルにルーティングするのではなく、タスクの特性に応じて使用するモデルを選択します。このルーティングロジックはサブタスクを分類し――例えば、単純な編集・複雑なマルチファイルリファクタリング・テスト生成などに区別し――各タスクタイプの品質閾値を満たす最もコストの低いモデルに割り当てます。単一モデルのアプローチと比較して10倍のコスト削減が主張されていますが、これはモデルレベルの最適化ではなく、このルーティングによるものです。ターミナルインターフェースは、GUIのコーディングエージェントよりもCLIワークフローを好む開発者を対象としており、Claude Codeレベルの精度をコストをかけずに実現することを目指しています。統一されたインターフェースを通じて複数のバックエンドをサポートすることで、プロバイダーの冗長性も確保され、ローカルホストのモデルへの切り替えも可能です。オープンソースでのリリースにより、ルーティングのヒューリスティックスは独自の多モデルシステムとは異なり、検査・拡張が可能です。主な制限として、ルーティング品質がタスク分類器に大きく依存しており、誤分類が発生すると複雑なタスクが性能不足のモデルにルーティングされる可能性があります。
Source: https://github.com/KlaatAI/klaatcode
OlegSotnikov/sallyport
MCP（Model Context Protocol）エージェントエコシステム向けに特化して設計されたmacOS用クレデンシャルボールトです。エージェントが認証済み操作をリクエストする一方で、基盤となるクレデンシャルそのものは受け取らないというプロキシパターンを実装しています。このボールトはMCP互換のエンドポイントを公開しており、エージェントが操作リクエスト（「このAPIコールを実行せよ」）を送信すると、ボールトが必要なクレデンシャルを解決して操作を実行し、その結果を返します――クレデンシャルの文字列自体は、エージェントのコンテキストにも、いかなるMCPメッセージにも現れることはありません。意図的にエクスポートルートが設けられていないため、エージェントプロセスが侵害された場合でも、保存されたシークレットを外部に持ち出すことはできません。これはアーキテクチャ的に、ハードウェアセキュリティモジュールの「鍵をエクスポートしない」保証をソフトウェアでmacOS上に実装したものと類似しており、セキュアなバッキングストアとしてシステムのKeychainを使用しています。この設計は現実の攻撃対象領域に対処するものです。現状のエージェントワークフローでは、クレデンシャルを（環境変数やシステムプロンプト経由で）モデルのコンテキストウィンドウに直接注入するケースが多く、モデルがコンテキストを開示するよう誘導された場合に容易に抽出可能な状態となっています。Sallyportはクレデンシャルの解決をボールトプロセス内に閉じ込めることで、その攻撃対象領域を完全に排除します。