デイリーAIダイジェスト — 2026-06-04
arXiv ハイライト
Cosmos 3: 物理AIのためのオムニモーダル世界モデル
問題設定
現在の物理AIスタックは断片化されています。知覚用のVLM、シミュレーション/ロールアウト用の独立したビデオdiffusionモデル、そして行動生成用の別個のポリシーネットワークが個別に存在しています。各コンポーネントは固有のトークナイザー、学習コーパス、および帰納的バイアスを持っており、言語・視覚・音声・モーターコマンドにわたる統合的な推論が脆弱になります。Cosmos 3が取り組む問いは、単一のバックボーンが、視覚言語理解・条件付きビデオ生成・世界シミュレーション（行動を条件とした次フレーム予測）・世界行動モデル（観測と命令を条件とするポリシー）を、いずれの品質も損なうことなく包括できるかどうかです。オムニモーダル世界モデル――言語・画像・ビデオ・音声・行動を一つのautoregressive/diffusionハイブリッドシステムに統合したもの――が、身体性を持つエージェントにとって適切な因子分解であるというのが本論文の主張です。
手法
Cosmos 3はMixture-of-Transformers（MoT）アーキテクチャを中心に構築されています。モダリティごとのexpertブロックはattentionを共有しつつ、モダリティ固有のFFNと正規化を経由してルーティングします。これにより、テキスト・視覚・音声・行動からのトークンストリームが固有の統計量を保ちつつ、モダリティ間でのattentionを可能にします。具体的には、モダリティラベル m_t \in \{\text{txt, img, vid, aud, act}\} を持つ混合モダリティトークン列 x_{1:T} が与えられたとき、attentionは全トークンにわたって密に行われますが、層 \ell におけるFFNは
h_t^{\ell+1} = h_t^\ell + \text{FFN}_{m_t}^\ell(\text{Attn}^\ell(h^\ell)_t),
となり、計算量は全expertではなくアクティブなexpertの数に応じてスケールします。これにより、統一されたKVキャッシュを維持しつつ、各モダリティが固有のトークン分布に対応するのに十分な容量を確保します。
トークナイズは異種構成です。テキストにはBPEトークナイザーを使用し、画像とビデオフレームは生成タスク用に連続潜在トークナイザー（diffusionデコードと互換）で、理解タスク用には離散トークナイザーでエンコードします。音声はフレームレートでトークナイズされ、行動はDoFごとに離散化されます。このモデルは、予測するポジションと条件付けするポジションをマスクすることで、任意入力・任意出力の構成をサポートしています。これにより、同一チェックポイントをVLM（テキスト出力・画像入力）、テキストから画像/ビデオへのモデル（視覚出力・テキスト入力）、世界シミュレーター（過去のビデオと行動を条件とした次のビデオチャンクの生成）、または世界行動モデル/ポリシー（観測と命令を条件とした行動出力）として機能させることができます。
学習は段階的に進みます。大規模な事前学習フェーズでは、ウェブ規模のテキスト、画像テキスト、ビデオテキスト、音声テキスト、およびロボティクスのtrajectoriesを混合します。目的関数は、離散ストリームに対する次トークンのクロスエントロピーと、連続潜在ストリームに対するdiffusion/flow-matchingのlossを組み合わせています。ノイズスケジュール \sigma_t を持つ連続潜在 z に対するlossは標準的な
\mathcal{L}_{\text{flow}} = \mathbb{E}_{t, z, \epsilon}\big[\| v_\theta(z_t, t, c) - (\epsilon - z) \|^2\big],
であり、テキストと行動のheadは -\log p_\theta(x_t \mid x_{<t}, c) を使用します。事後学習では、精選された命令およびtrajectoryデータに対するsupervised fine-tuningを行い、続いて生成品質のためのpreference optimizationとロボティクスタスクにおけるポリシーheadのRL fine-tuningを実施します。生成されたtrajectoriesとレンダリングされた世界の両方を含む合成データが大量に使用されており、NVIDIAはチェックポイントとともに精選された合成データセットを公開しています。
結果
本論文は、理解と生成にわたって評価された単一のチェックポイントファミリーについて報告しています。Artificial Analysisのサードパーティリーダーボードでは、事後学習済みのCosmos 3が、投稿時点でオープンソースのText-to-Imageとオープンソースのimage-to-videoモデルの中で最高位にランクされました。操作タスクのポリシーベンチマークであるRoboArenaでは、Cosmos 3が最高位のポリシーモデルとしてランクされました。これら三つのランキングを合わせると注目に値します。なぜなら、通常それぞれは専門特化したシステム（例えば、専用のdiffusion画像モデル、専用のビデオモデル、専用のVLAポリシー）によって占められているからです。統一バックボーンが三つすべてで同時に首位を占めることが、本論文の中心的な実証的主張です。技術レポートはさらに、VLMベンチマーク・世界シミュレーションの忠実度（行動を条件とした次フレーム予測）・音声条件付き生成が専門特化したベースラインと競合することを論じていますが、abstractでは個別のベンチマーク数値を列挙していません。
限界と未解決の問い
いくつかの注意点を指摘する価値があります。第一に、「オープンソース最高位」のランキングはタイムスタンプ付きであり、クローズドなフロンティアシステムは比較対象から除外されています。それらとのギャップはabstractでは明示されていません。第二に、MoTはモダリティ間でattentionを共有するため、長期間のビデオと行動シーケンスは通常の二次コストに直面します。abstractだけからでは、推論レイテンシが典型的なロボットの制御周波数でのクローズドループ制御に許容できるかどうかは判断できません。第三に、一つのモデルの中でdiffusionスタイルの連続headとautoregressiveな離散headを混在させることにより、学習目的関数の干渉が生じ、そのスケーリング挙動はよく理解されていません。論文ではおそらくこのアブレーションが行われているでしょうが、トレードオフ曲線は下流ユーザーにとって重要になるでしょう。第四に、RoboArenaは有限のタスクスイートを評価するものであり、分布シフト下での長期的・接触の多い・あるいは巧みな操作タスクへの汎化は、VLAにとって標準的な未解決問題のままです。最後に、OpenMDW-1.1（https://openmdw.ai/license/1-1/）の下でのリリースは寛容ですが、事前学習のデータの来歴――特にビデオについて――は、この規模のモデルに対する通常の未解決の問いです。
なぜこれが重要か
Cosmos 3は、単一のMoTバックボーンがtext-to-image・image-to-video・ロボットポリシー評価のリーダーボードで同時に上位を占められるという具体的な実証例です。これは、物理AIに知覚・シミュレーション・制御の個別モデルが必要だという前提を覆すものです。この統合がスケールにおいても成立するならば、身体性を持つエージェントのためのエンジニアリングの表面積は大幅に縮小されます。
Source: https://arxiv.org/abs/2606.02800
OVO-S-Bench: マルチモーダルLLMにおけるストリーミング空間知性のための階層的benchmark
問題と動機
ロボット、ARヘッドセット、自動運転スタックといったEmbodied agentは、自己中心的な映像を因果的なストリームとして受け取り、現在の視野外に証拠がある可能性のある空間的なクエリに回答しなければなりません。既存の動画QA benchmarkは、クリップ全体を対象としてオフラインで評価する（自由に再スキャン可能）か、空間構造よりもイベント認識に焦点を当てています。どちらの設定も、フレームが到着するにつれてマルチモーダルLLMが環境の持続的かつアロセントリック（環境中心的）な表現を維持するかどうかを検証するものではありません。OVO-S-Benchは、このギャップを対象とした完全に人手でアノテーションされたbenchmark（348本のソース動画から得た1,680問、12名のアノテーターによる複数ラウンドのQAに約804人時間を要したもの）です。各質問にはクエリタイムスタンプ t_q と証拠区間があり、評価時にはモデルは t_q 以前のプレフィックスのみを参照できます。
タクソノミーとプロトコル
質問は、持続性と抽象度の増加を反映した4つのレベルに層別化されています。
- L1 — 瞬時的自己中心的知覚（Instantaneous Egocentric Perception）： t_q 付近のフレームから回答可能。ファミリー：自己中心的メトリクス（距離、スケール、クリアランス、視点高度）、局所的空間関係（包含、遮蔽、支持、可視レイアウト）、動的知覚（カメラ・物体の動き、相対速度）。
- L2 — 時空間コンテキスト追跡（Spatiotemporal Context Tracking）： クエリ対象のエンティティや関係がもはや視野内にない場合で、プレフィックス全体にわたって状態を維持することが求められます。
- L3 — 空間シミュレーションと推論（Spatial Simulation and Reasoning）： 推定されたシーンに対する反事実的または生成的なクエリ（例：別の視点から何が見えるか）。
- L4 — アロセントリックマッピング（Allocentric Mapping）： 複数視点の統合によるグローバルかつ視点非依存のマップの構築（トポロジー、部屋の隣接関係、経路推論）。
ストリーミングプロトコルでは、各動画を t_q でトランケートし、プレフィックスから均一にサンプリングした128フレームを多肢選択問題とともに入力します。ネイティブなストリーミングアーキテクチャは代わりに公表されたレートで取り込まれ、圧縮された状態からクエリされます。これはOVO-BenchおよびOST-Benchの設定を踏襲しています。リーダーボードには3つのコントロールがアンカーとして設定されています：ランダムベースライン、テキストのみのベースライン（質問と選択肢のみが与えられたGPT-5.4）、そしてストリーミングとオフラインの両プロトコル下での人間の評価者です。
主要な結果
このbenchmarkは、7つのファミリーにわたる38のシステムをカバーしています：プロプライエタリMLLM（GPT-5.4、Gemini-3.1-Pro/Flash-Lite、Grok-4.1-Fast）、オープンソースのバックボーン（InternVL-3.5、Qwen2.5/3/3.5-VL、Gemma-4、GLM-4.6V-Flash）、ストリーミング動画MLLM（Flash-VStream、StreamForest、StreamingVLM）、トークン圧縮・メモリ手法（InfiniPot-V、HERMES、FluxMem、StreamingTOM）、空間的にfine-tunedされたMLLM（Spatial-MLLM、Cambrian-S\pmLFP、VST-SFT/RL、SenseNova-SI、Spatial-TTT）、そしてEmbodied foundation model（Cosmos-Reason1、VeBrain、RynnBrain、RoboBrain2.5）です。
主要な数値（全体的な多肢選択の正答率）：
- 人間（オフライン）：92.20；人間（ストリーミング）：86.61。
- 最高スコアのシステム、Gemini-3.1-Pro：59.19 — ストリーミング下の人間に対して27.4ポイントのギャップ。
- GPT-5.4：50.89；Gemini-3.1-Flash-Lite：50.81；Grok-4.1-Fast：43.73。
- テキストのみのGPT-5.4：37.10；ランダム：31.33。
Gemini-3.1-ProのL1→L4の内訳は 61.92 / 64.04 / 55.90 / 54.90 であり、一方で人間（ストリーミング）は 93.21 / 81.03 / 86.43 / 79.19 のスコアを記録しています。最大の絶対的な差は L3（空間シミュレーション） および L4（アロセントリックマッピング） にあります：Gemini-3.1-ProはL3で人間に対して約30ポイント、L4で約24ポイントの差をつけられており、L4.3のサブタスク（画像選択肢を用いたアロセントリック問題）では22.64対人間の71.70という崩壊的なスコアになっています。テキストのみのベースラインはすでにL3で38.85、L4で35.53に達しており、これはL3の質問が言語的ショートカットを許容し、L4の選択肢分布が制約されているためでもあり、各レベルが実際にどの程度視覚を必要とするかの有益な事前情報となっています。
2つの定性的な知見が際立っています。第一に、ストリーミングおよび空間的にfine-tunedされたMLLMは自身のバックボーンを下回るパフォーマンスを示しています：ストリーミングトークン圧縮（InfiniPot-V、HERMES、FluxMem、StreamingTOM）および空間的SFT/RL（Spatial-MLLM、VST-SFT/RL、SenseNova-SI）によって導入された帰納的バイアスは、L3–L4での十分な回復なしに、L1–L2において重要な汎用視覚推論を損なっているように見えます。第二に、著者らは（要旨中では省略されていますが）chain-of-thoughtが空間ストリーミングクエリにおいて限定的または負の効果をもたらすことを報告しており、これは言語的推論が内部マップの代替として機能しないという先行研究の報告と一致しています。
限界と未解決の問題
均一にサンプリングされた128プレフィックスフレームを使用するストリーミングプロトコルは、真のストリーミングアーキテクチャよりも長コンテキスト視覚の強いモデルを有利にします；ストリーミングモデルの性能差のどの程度が方法論的なものかは明らかではありません。L4.3は一部の手法（例：InfiniPot-V）が入力できない画像選択肢を使用しており、クロス比較が不均一になっています。多肢選択形式は、L3シミュレーションにおける診断的分解能を制限しており、自由形式の生成がより豊かな失敗モードを明らかにするでしょう。最終的に、このbenchmarkはメモリの書き込み/読み出しのプリミティブを直接テストするのではなく、エンドタスクの正答率のみを測定しているため、どのメモリ表現（トークンキャッシュ、潜在マップ、明示的シーングラフ）がボトルネックであるかを特定することはできません。
なぜこれが重要か
OVO-S-Benchは、Embodied agentが実際に必要とする能力ギャップ — 因果的な自己中心的ストリームから持続的なアロセントリックマップを構築・クエリする能力 — を明確に切り分けており、フロンティアのプロプライエタリモデルを含む現在のMLLMが人間より約27ポイント低く、アロセントリックマッピングが支配的な失敗モードであることを示しています。最も注目すべきは、ストリーミングおよび空間特化システムがその汎用バックボーンに対して後退していることであり、現在の空間的ポストトレーニングとストリーミング圧縮戦略がこの軸においてネガティブな影響を与えていることを示唆しています。
Source: https://arxiv.org/abs/2606.03890
M^3Eval: 認知科学に基づいたビデオタスクによるマルチモーダルメモリ評価
問題設定
マルチモーダルモデルを対象とした長尺ビデオのベンチマークは、主として知覚と推論を評価するものが大半です。そうしたベンチマークがメモリそのものを独立した能力として問うことは稀であり、具体的には「どのようなコンテンツが符号化されるか」「どの程度忠実に保持されるか」「干渉によってどのように劣化するか」「空間的・時間的な情報源に再結合できるか」といった問いが十分に検討されていません。このようなプローブが欠如していると、「長コンテキストビデオ」に関する主張を反証することが困難になります。すなわち、モデルはフレームレベルの直近性の利用、キャプション生成のショートカット、あるいは単一ストリームの顕著性に頼ることで、一貫したエピソード的表現を保持することなく長尺ビデオQAに合格できてしまいます。
M^3Evalはこの問題に対処するため、認知心理学における4つの標準的なパラダイムを制御されたビデオタスクへと移植しています。それぞれのタスクは、単一の精度スコアではなく特定の失敗モードを名指しするメトリクスで計測されます。
フレームワーク
このベンチマークは空間・時間・記号の軸にわたって構成されています：
- Divided Attention（並行ストリームのもとでの空間的符号化）：意味的に類似した2本のビデオ V_1, V_2 を分割画面で提示し、オプションとして均等間隔で10回の左右スワップを行うことで、コンテンツと位置との結合（binding）をテストします。
- Memory Interference（時間的）：逆行性・順行性干渉をモデル化した、時系列的に類似したディストラクタに対するロバスト性を評価します。
- Interleaved Events（時間的再構成）：インターリーブされたセグメントからイベントの順序を再構成します。
- N-Back（記号的ワーキングメモリ）：長さ N の時間的ギャップをまたいだ同一性マッチングを評価します。
各パラダイムでは、特定の失敗モードに合わせて手作りされたディストラクタを用いた4択問題を採用しており、偶然水準は25%です。エラータイプは集約されたものではなく診断的なものとなっています。
Divided Attention のメカニズム
2つの条件が評価されます。No swapping では、V_1 が左側に固定され V_2 が右側に固定されており、並行入力のもとでモデルが分離された表現を維持できるかどうかを単独で評価します。Swapping では、(V_1,V_2) の空間的割り当てが均等間隔の10タイムスタンプで反転し、「左側のビデオ」を静的なストリームとして扱うのではなく、コンテンツと位置の結合を追跡することがモデルに求められます。
3種類の質問タイプは、それぞれ異なる失敗モードを対象としています：
- Source Identification — ディストラクタが V_2 のコンテンツを V_1 のものとして帰属させます（ソース混同）。
- Order Understanding — ディストラクタが時間的・因果的な順序を並べ替えます。
- Content Retention — ディストラクタがターゲットのあらすじの詳細を歪めます。
この因子分解が方法論的な核心です。ソース混同は結合（binding）を単独で評価し、順序は時間的符号化を、保持は要旨・詳細の想起を単独で評価します。3つのメトリクスにわたって同一の刺激セットが再利用されているため、列間の差異は項目難易度ではなく表現的構造を反映しています。
定量的結果
テスト対象のモデル：Gemini-3.1-Pro-Preview、GPT-5.4、Qwen3-VL-8B-Instruct、Qwen3.5-{4B,9B,27B}、InternVL3.5-8B、およびエージェント型システムであるVideoLucyとM3-Agent。人間の参照値も含まれています。
No swapping において、人間はソース/順序/保持の各指標でそれぞれ 89.58 / 90.00 / 92.16 (%) に達します。最強のモデルであるGemini-3.1-Pro-Previewは 62.50 / 52.50 / 49.02 を記録します。GPT-5.4は 27.08 / 35.00 / 47.06 であり、Source Identificationでは偶然水準にとどまります。Qwen3.5ファミリーはSource Identificationにおいて18.75（4B）から41.67（27B）の範囲であり、27Bでも人間より48ポイント低い結果となっています。オープンソースのエージェントは改善に寄与せず、VideoLucyは 16.67 / 42.50 / 37.25、M3-Agentは 27.08 / 30.00 / 23.53 のスコアです。
Swapping 条件下では、最大の性能低下がSource Identificationに集中しています。Geminiは25.00ポイント低下（62.50 → 37.50）、Qwen3.5-9Bは16.67ポイント低下（35.42 → 18.75）、Qwen3.5-27Bは14.59ポイント低下（41.67 → 27.08）となっています。Order UnderstandingとContent Retentionは実質的に変化がなく、一部のモデルでは若干の改善さえ見られます（例：Gemini Content Retention +7.84、GPT-5.4 Source Identification +8.34、後者はベースライン27.08を考えると偶然水準の変動である可能性が高い）。人間は全3指標にわたって約5〜8ポイントの均一かつはるかに小さな低下を示します。
この解離は示唆的です。スワッピングは、あるストリーム内で何が起きたか、あるいはいつ起きたかを損なうものではなく、どのストリームがそれを所有していたかを損なうものです。これは古典的なソース・モニタリング障害であり、現在のVLMにおいて顕著に現れる一方、人間においては軽微にとどまっています。
Attention レベルの診断
著者らは、シングルスクリーンと分割スクリーンの設定における attention マップを可視化しています。単一ビデオ条件では、attention は問われた領域に集中しますが、分割スクリーン下では、質問が明示的に左のビデオを指定している場合でも、attention は両パネルに拡散します。提案されているメカニズムは並行視覚ストリームをまたぐ attention の混乱です。モデルは自身のトークンを空間的な起源によってゲーティングすることができず、その結果 V_1 と V_2 のトークンが検索に共同で寄与してしまいます。これはデータ面ではなくアーキテクチャ面での修正が必要であることを示唆しており、例えば明示的な位置またはストリームIDの条件付け、クロスストリーム attention のマスキング、あるいは融合前にストリームごとの要約を構築する階層的エンコーダなどが考えられます。
限界と未解決の問題
- このベンチマークは、構築されたディストラクタを用いた4択問題を採用しています。絶対的な精度はディストラクタの調整に敏感であり、各条件あたりの項目数が少ない（人間は1セルあたり40〜51問を評価）ため、単一点の比較にはノイズが生じます。より信頼性の高いシグナルは、パラダイムをまたいだ集約されたパターンです。
- Attention の可視化はソース混乱の仮説を定性的に支持するものの、因果関係を確立するものではありません。そのためには介入実験（強制的な単一ストリームマスキング）が必要です。
- 提供されたセクションではDivided Attentionパラダイムのみが報告されており、「時間的ソース基盤付けが空間的なものより弱い」「N-Backにおける記号的メモリが限定的」というヘッドラインの主張は、全テーブルセットに基づくものです。
- エージェント型パイプライン（VideoLucy、M3-Agent）は複数のセルで基盤となるVLMより低い性能を示しており、現在のメモリ拡張スキャフォールドが結合問題に対処できておらず、情報損失すら引き起こす可能性があることを示唆しています。
なぜこれが重要か
「メモリ」を結合・順序付け・保持・干渉・記号的ギャップブリッジングに分解し、現在のVLMが空間的レイアウトが不安定な場合にソース結合において具体的に15〜25ポイント低下することを示すことで、M^3Evalは長尺ビデオモデルのアーキテクチャ研究に向けた反証可能な目標を提供しています。自動運転、ロボティクス、監視といったマルチストリームアプリケーションは、このベンチマークが現状では欠如していることを示している結合能力にまさに依存しています。
Source: https://arxiv.org/abs/2606.05008
マルチエージェント推論におけるストリーミング通信
マルチエージェントLLMシステムは通常、「生成してから転送する」パターンに従います。エージェント A_i が推論トレース全体を生成し、それを A_{i+1} に送信し、その後初めて A_{i+1} が処理を開始します。エンドツーエンドのレイテンシは \sum_i T_i（T_i は各エージェントの生成時間）としてスケールし、深さ d はレイテンシの乗数として固定されます。StreamMAは、これが不必要かつ逆効果であると主張しています。各推論ステップを生成と同時に下流に streaming することは、計算をパイプライン化するだけでなく、より驚くべきことに、タスクの精度も向上させます。
セットアップとプロトコル
エージェントの推論をステップ列 s_1, s_2, \ldots, s_n とします。本論文では、以下の三つのプロトコルを形式化しています。
- Single：一つのエージェントが単独で回答する。
- Serial（標準的なマルチエージェント）：A_{i+1} が A_i からのチェーン全体 s_{1:n}^{(i)} を受け取って処理する。
- Stream：A_{i+1} が s_k^{(i)} を生成と同時に消費し始め、A_i と並行して実行する。
streaming 下でのレイテンシモデルは、完全なオーバーラップの限界において \sum_i T_i から \max_i T_i へと削減されます。エージェント d 個それぞれがステップ数 n、1ステップあたりの時間を \tau とすると、serial のレイテンシは d \cdot n \tau であるのに対し、stream のレイテンシは (n + d - 1)\tau に近づき、速度向上の上限は
\text{Speedup} \le \frac{dn}{n + d - 1}
となります。これは n \gg d のとき d に近づきます。トークンコストは実質的に変わらず（各エージェントは依然として n ステップを出力します）、serial に対するコスト比は \approx 1 となります。
streaming が精度を向上させる理由
直感に反する主張は、有効性の順序付けです。著者らは、1ステップあたりの正確さが一様でないとモデル化しています。チェーン内の早いステップは後半のステップよりも経験的に信頼性が高く、これは誤りが蓄積し、後半のステップが誤りを含む可能性のあるコンテキストに条件付けられるためです。ステップ k が正しいプレフィックスが与えられたもとで正しい確率を p_k とすると、困難な問題では p_k は k に対して単調減少します。チェーン全体 s_{1:n} に条件付けられた下流エージェントは信頼性の低い末尾を引き継ぎますが、ある k^* < n に対してストリーミングされたプレフィックス s_{1:k^*} に条件付けられたエージェントは、誤った後半ステップに惑わされることを回避できる可能性があります。
streaming プロトコルでは、A_{i+1} は A_i の末尾を待たず、部分的なプレフィックスから推論を開始し、実質的に後半ステップの誤りに対してヘッジします。閉形式の解析により、以下が導かれます。
\Pr[\text{Stream correct}] \ge \Pr[\text{Serial correct}] \ge \Pr[\text{Single correct}]
これは、末尾の誤り確率が無視できない場合に厳密な不等式として成り立ちます。これは、三つのプロトコルにわたってレイテンシ、コスト、精度を同時に分析した初めての研究です。
実験結果
評価は、数学（HMMT 2026 を含む）、科学、コードにまたがる八つのベンチマーク、二つのフロンティアモデル（Claude Opus 4.6 と GPT-5.4）、および三つのトポロジー（Chain、Tree、Graph）にわたって行われています。主要な数値は以下の通りです。
- single/serial の強い方のベースラインに対する平均改善は +7.3 pp。
- Claude Opus 4.6-high による HMMT 2026 での最大改善は +22.4 pp。
- 三つのトポロジーすべてで改善が見られ、この効果が線形チェーン固有のものではないことを示しています。木構造やグラフのアグリゲータも、子エージェントが親に streaming する際に恩恵を受けます。
レイテンシの削減は理論的な速度向上の上限に沿っており、より深いパイプラインでは実時間の利得が深さにほぼ比例する一方で、トークンコストは serial の数パーセント以内に収まっています。
ステップレベルのスケーリング則
副次的な知見として、エージェントあたりの推論ステップ数 n を増やすことで、single エージェントとマルチエージェントの両方のパフォーマンスが一貫して向上しますが、そのスロープは streaming 下でより急峻になります。直感的には、チェーンが長くなることで streaming にオーバーラップの機会が増え、下流エージェントが行動するためのプレフィックスの粒度が細かくなります。一方、serial パイプラインはエージェントあたり n\tau のフルコストを支払うにもかかわらず、品質向上はそれに見合ったものになりません。これは、ステップ数がモデルサイズやエージェント数と並ぶ一級のスケーリング軸であり、streaming がレイテンシの二乗的な増大なしにそのバジェットを実際に活用できるプロトコルであることを示唆しています。
制限と未解決の問題
本分析は、1ステップあたりの信頼性が単調に減少するという仮定に基づいています。これは困難な推論ベンチマークでは成り立ちますが、エージェントが後半に検証や自己修正を行う場合には成り立たない可能性があります。その場合、後半のステップはより信頼性が高く、streaming は下流エージェントに時期尚早な結論を与えることになります。また、このプロトコルは下流エージェントが部分的なプレフィックスを有効に消費できることを前提としており、実際にはインクリメンタルな入力処理のためのトレーニングまたはプロンプトが必要ですが、本論文はプロンプトの感度について詳細なアブレーションを行っていません。同期のオーバーヘッド、A_{i+1} が A_i を追い越す場合のバックプレッシャー、および不均一なステップあたりレイテンシ下での挙動については言及されていますが、網羅的に測定されているわけではありません。最後に、理論的な上限はエージェント間のステップレベルの誤りの独立性を仮定していますが、これは相関した失敗モード（例：共有された学習データのバイアス）に対しては楽観的です。
未解決の問題としては、streaming されたステップをいつコミットするかと修正するかを動的に決定する方法、部分的なプレフィックスに対する投機的実行（speculative decoding に倣って）が速度向上を複合するかどうか、そしてステップレベルのスケーリング則が飽和または反転する領域があるかどうかなどが挙げられます。
この研究の意義
streaming は、マルチエージェントのレイテンシをトークンコストを上げることなく、エージェントの深さに対して O(d) からほぼ O(1) に再定式化します。そして、精度の向上——早い推論ステップが後半のステップよりも信頼性が高いという単純な観察に基づく——は、直交するレイテンシ削減研究が見逃してきたフリーランチです。ステップレベルのスケーリング則が一般化するならば、エージェント型システムにおける推論バジェットの使い方を根本的に見直すことになります。
Source: https://arxiv.org/abs/2606.05158
WebRISE: MLLM生成Webアーティファクトに対する要件誘導状態評価
問題
MLLM生成Webページの既存ベンチマークは、参照レンダリングとのピクセル類似度、特定のDOMノードの存在、または固定軌跡上のスクリプト化されたチェックポイントといった、局所的・静的な証拠によって品質を評価しています。これは「見た目が正しい」ことと「動作が正しい」ことを混同しています。あるページはターゲットと視覚的に一致するログインフォームをレンダリングしながら、送信ボタンが何にも接続されていない場合があります。逆に、異なるレイアウトのページが要求された状態機械を正しく実装している場合もあります。著者らは、生成されたアーティファクトが機能的かどうかを決定するのは、要件によって誘導される状態とユーザーの意図のもとでのそれらの間の遷移であり、これらは実装に依存しない特性でありながら現在の評価には存在しないと主張しています。
手法：Interaction Contract Graph
WebRISEは、各タスクの自然言語要件集合 R_\tau を、観察可能な状態、遷移、およびDOM/視覚的アサーションからなるInteraction Contract Graph（ICG）G_\tau にコンパイルします。同じ G_\tau が5つの入力モダリティ \mathcal{M}=\{\text{Text}, \text{Markdown}, \text{Sketch}, \text{Image}, \text{Video}\} にわたって共有されるため、固定タスク \tau に対してモデル f_\theta は h_{\theta,\tau}^m = f_\theta(x_\tau^m) を自己完結したHTMLアーティファクト（HTML+CSS+JS、バックエンドなし）として生成します。各遷移はタプル
t_j = (s_j^{\text{from}}, s_j^{\text{to}}, g_j, P_j, A_j^{\text{dom}}, A_j^{\text{vis}}),
として表され、g_j はcontract-guidedエージェントに渡される自然言語ゴール、P_j は事前条件集合、A_j^{\text{dom}}, A_j^{\text{vis}} はDOMイベントおよび視覚的事後条件アサーションです。遷移分解は設計上の核心的な工夫であり、証拠をグローバルなDOM差分や単一スクリーンショットではなく、要件に紐付いた状態変化に局在化させます。
評価（Algorithm 1）は、実際のブラウザで H をロードし、キャッシュされた軌跡 \Pi を再生することで s_j^{\text{from}} を復元し、事前スクリーンショットを取得し、P_j を確認した後、予算 K を持つエージェントを g_j の実行に派遣します。安定待機時間 \Delta の後、イベントログ \mathcal{L} を凍結し、DOMオラクルと視覚的オラクルを独立にスコアリングします。遷移が Pass となるのは、ソースが到達可能であり、エージェントがアクションを完了し、かつ両方のオラクルが合意した場合のみです。成功時には \Pi が s_j^{\text{to}} への軌跡で更新され、パスを再導出することなく分岐グラフを扱えます。ベンチマークは8ドメイン、35シナリオにわたる442タスク（生産性ツール23.76%、ソーシャルインタラクション16.97%など）を含み、ユーザーが明示した機能と暗黙のプロダクトレベルの制約を分離する5,495の遷移と5,271の要件チェックを備えています。
結果
14のMLLM（Qwen3.5/3.6ファミリーおよびKimi K2.5/K2.6を含む7つのオープンウェイトモデルと、GPT-5.4/5.5、Claude Opus 4.6/4.7、Gemini-3 Flash/3.1 Pro、Qwen3.6-Plusを含む7つのプロプライエタリモデル）にわたって、最も強力なモデルでも遷移有効性65.6%、要件カバレッジ66.3%にしか達しません。主要な発見は視覚的挙動のギャップです：Qwen3.6-35B-A3BはMarkdownにおいて V=80.8 の視覚的品質を達成しながら、遷移有効性はわずか T=15.5 にとどまります――見た目は完成しているがほとんど動作しないページです。視覚的忠実度は挙動の代理指標にはなりません。
モダリティは重要です。Video仕様が最も強いインタラクション信号をもたらし、Textに対して暗黙的要件カバレッジで+10.6 ppの向上をもたらします。これは、時間的デモンストレーションが意図された状態機械を静的テキストやスクリーンショットよりも直接的にエンコードするという直感と一致しており、特にユーザーが明示しなかったが期待していたアフォーダンス（フォーカス管理、キーボード操作、エラートースト）において顕著です。ただし、暗黙的制約は全モダリティにわたって支配的な失敗モードであり続けています。
著者らはICG定式化の有効性を、欠陥注入によるチェックポイントスタイルの評価と比較して検証しています：ICGベースのスコアリングは注入された状態エラーをチェックポイント評価の2〜16倍の速度で検出します。LLMジャッジと人間の判定の一致度は \kappa = 0.74 です。
限界
ジャッジ層はプロンプト感度とAPIのドリフトに対して依然として脆弱であり、著者らはスコアを絶対的な測定値ではなく順位付けとして読むことを明示的に推奨し、再スコアリングを可能にするためにアサーションごとの判定を公開しています。ICGは単一の貢献者プールによる地域的なプロダクト慣習をエンコードしているため、暗黙的要件集合はロケール中立ではなく、他の市場をターゲットとするアプリケーションにはコントラクトの拡張が必要です。プロトコルはシングルページかつバックエンドなしのアーティファクトを前提としており、マルチページアプリ、永続的状態、ネットワーク依存フローはスコープ外です。最後に、contract-guidedエージェント自体が動作するページ上でゴール g_j の実行に失敗する場合があり、エージェント能力とアーティファクトの正確さが混同されます；予算 K と再生キャッシュ \Pi はこれを緩和しますが排除はしません。
なぜ重要か
WebRISEはWeb生成評価をアーティファクトマッチングからコントラクト適合へと再定義し、現在のMLLMが視覚的には説得力があるが挙動的には不完全なページを生成していることを明らかにします――これは標準的なベンチマークが構造的に見えないギャップです。遷移レベルの分解とチェックポイント評価に対する2〜16倍の欠陥検出改善は、ICGが生成されたUIが実際に動作するかどうかを測定すると主張するあらゆるベンチマークのデフォルト基盤となるべきであることを示唆しています。
Source: https://arxiv.org/abs/2606.03220
AutoLab: フロンティアモデルは長期的な自動研究・エンジニアリングタスクを解けるか？
問題設定
ほとんどのエージェントベンチマークは、単一ターンの回答、または数分程度の短期的な軌跡のみを評価します。しかし現実の研究・エンジニアリングは、提案・実行・計測・改善というサイクルを時間単位で繰り返す反復的なプロセスです。AutoLabはこのギャップを埋めることを目的とし、エージェントに正しいが最適でないベースラインと制限時間を与え、連続的な性能指標を改善させる持続的なクローズドループ最適化を測定します。著者らが実証的に検証する仮説は、長期的な持続性——ベンチマーク・編集・フィードバックの繰り返しサイクル——が成功の予測因子として初回試行の品質を上回るというものです。
ベンチマークの構成
AutoLabは、システム最適化、パズル＆チャレンジ、モデル開発、CUDAカーネル最適化という4つのドメインにわたる36の専門家がキュレーションしたタスクで構成されています。各タスクは（指示、ベースラインコードとエージェントが呼び出せるローカル評価スクリプトを含むコンテナ化された環境、ホールドアウト検証器、隠された参照解、制限時間）のタプルです。参照解はベースラインを非自明なマージンで上回ることが求められており、システム最適化タスクでは通常少なくとも1桁の改善、モデル開発では明確な統計的改善が必要です。
スコアリングはベースライン（s=0）と参照解（s=0.5）を基準とし、0.5を超える値は参照解を上回る性能を示します。桁違いの指標に対しては、著者らはlog-stretch変換を使用します：
s(x) = \mathrm{clip}\!\left(\tfrac{1}{2} \cdot \frac{\log(m_{\mathcal{B}}/m(x))}{\log(m_{\mathcal{B}}/m_{\mathcal{R}})},\ 0,\ 1\right)
最小改善ゲートが設けられており、ベースラインを超えるまではs=0となるため、わずかなノイズに対するクレジットが排除されています。高い方が良い指標には方向を反転させた類似式を使用します。検証はハック耐性を持つ設計となっており、エージェントが開発中に呼び出すローカルスクリプトはホールドアウト検証器とは異なるため、報酬ハッキングした数値は転用できません。
モデルは3回の独立したロールアウトにわたる3つの指標でランク付けされます：Avg@3（典型値）、Best@3（上限値）、およびDominance——トーナメント形式の一対一比較：
\mathrm{Dominance}(m)=\frac{1}{|\mathcal{T}|\cdot(|\mathcal{M}|-1)}\sum_{t\in\mathcal{T}}\sum_{\substack{o\in\mathcal{M}\\ o\neq m}}\!\Bigl(\mathbf{1}[s_{m,t}>s_{o,t}]+\tfrac{1}{2}\mathbf{1}[s_{m,t}=s_{o,t}]\Bigr).
Dominanceは[0,1]の範囲をとり、0.5が平均となります。これはハードウェアの分散や少数の高インパクトなタスクに対してロバストです。
セットアップ
17のモデルが評価されており、プロプライエタリなフラッグシップモデル（claude-opus-4.6、gemini-3.1-pro、gpt-5.4、grok-4-20）と200Bパラメータ以上のオープンウェイトモデル（qwen-3.6-plus、deepseek-v4-pro、glm-5、kimi-k2.6、hunyuan-3-preview、mimo-v2.5-pro、minimax-m2.7）、さらにアブレーション用の旧バリアントが含まれます。ハーネスはHarborにterminusエージェント-2を使用します（セクション4.3にpi-monoと最適化されたmini-swe-agentを用いたパイロット実験が含まれます）。CPUタスクはRyzen 9950X / 64 GBワークステーション上のローカルDockerサンドボックスで実行され、GPUタスクはModal上のH100およびL40Sで実行されます。総計算量：2,544ウォールクロック時間および86億トークン。
結果
claude-opus-4.6はAvg@3およびBest@3の両方において全4タスクカテゴリでトップとなっています。他のプロプライエタリフロンティアモデルとの差はコスト分析によって機械論的に説明されます：gpt-5.4とgrok-4-20は著しく短いエージェント実行時間でクラスタリングされており、試行を早期に終了させています。モデル全体では、Avg@3はエージェントの平均ステップ数および平均ウォールクロック実行時間の両方と正の相関を示しており、生の推論コストとの相関は弱くなっています。いくつかのオープンウェイトモデル（特にdeepseek-v4-flashとmimo-v2.5-pro）は、タスクあたりのUSDコストが大幅に低いにもかかわらず競争力のあるスコアを達成しており、これはベンチマーク性能を駆動するのがトークンあたりの最大能力ではなく長期的なスループットであることを示しています。
定性的な知見として、成功の支配的な予測因子は初回パッチの品質ではなく、エージェントがベンチマーキング・編集・実証的フィードバックの取り込みを繰り返す持続性であることが明らかになりました。早期停止するモデルは——たとえ最初の試みが合理的であっても——改善余地のほとんどを活かせていません。Figure 6の失敗モード分析では、ゼロスコアのロールアウトを4つの相互排他的なクラス（早期終了、ベースラインからの改善なし、破損した修正、インフラ障害）に分類しており、いくつかのプロプライエタリモデルでは早期終了が支配的となっています。
限界と未解決の問題
（1）結果はterminusエージェント-2ハーネスと絡み合っており、セクション4.3のpi-monoおよびmini-swe-agentパイロット実験はハーネスの選択がランキングを変動させる可能性を示唆しています。（2）200B未満のパラメータを持つモデルは除外されているため、能力・コストフロンティアの下端は未測定のままです。（3）ベンチマークはタスクごとに固定されたウォールクロック予算を使用しており、予算に対してスコアがどのようにスケールするか——すなわち、より多くのステップを与えれば弱いモデルが追いつくか、または強いモデルが飽和するか——は特性評価されていません。（4）ハック耐性はホールドアウト検証器に依存していますが、実行時間やスループットのような性能指標については攻撃面（例：事前計算、評価スクリプトの特異性の悪用）が大きく、論文はハック耐性を主張していますが残存するゲーミングを定量化していません。（5）持続性が能力を上回るという主要な結果は、プロプライエタリモデルが早期終了するようにチューニングされているというアーティファクトを部分的に含んでおり、プロンプティングまたはスキャフォールディングだけでclaude-opus-4.6とのギャップを埋められるかどうかは不明です。
この研究の意義
AutoLabは、時間スケールのクローズドループ最適化において、現在のフロンティアモデルにとっての制約要因が生のシングルショット推論能力ではなく反復規律であるという実証的な根拠を示しています——いくつかのプロプライエタリフラッグシップは弱いパッチを生成したからではなく、早期停止したために失敗しています。これは「エージェント能力」の評価を持続的な実証的ループを中心に再定義し、モデルの改善に伴う飽和に耐性を持つ連続的でハック耐性のあるスコアリングスキームを提供します。
Source: https://arxiv.org/abs/2606.05080
Audio Interaction Model
現在のLarge Audio Language Models（LALMs）は、テキスト指示 x と完全な発話 \mathcal{A} を入力とするオフライン関数 y = f(x, \mathcal{A}) として動作しており、信号全体を観測した後に単一の応答を生成します。ストリーミングシステムも存在しますが、それぞれ独立しており、ストリーミングASR、同時通訳、音声チャットはそれぞれ別個のモデルとして存在しています。本論文では、これらのレジームをperceive–decide–respondループのもとに統合したAudio Interaction Modelを形式化し、新たなストリーミングコーパスStreamAudio-2M上でSoundFlowフレームワークを用いて学習させたAudio-Interactionとして具体化します。
問題の定式化
このモデルは音声チャンクを逐次消費し、各ステップでバイナリな介入判断と（条件付きで）応答トークンのストリームを出力します：
(d_t, r_t) = f(a_{\le t},\, d_{<t},\, r_{<t}),
ここで a_t は現在の音声チャンク、d_t \in \{\text{silent}, \text{respond}\} はストリーミング介入判断、r_t は生成された応答トークンです。オフラインレジームとの対比を図2に示します：従来のLALMsは発話終端を待ち、一度だけ応答し、タスクごとに特化していますが、Audio-Interactionはいつ発話するかを継続的に判断します。
この単一の定式化は幅広い能力を包含します：音声翻訳から同時通訳（十分なソースコンテキストが蓄積されたタイミングを判断）、対話からオープンドメイン音声議論、音声理解から音声指示追従、そしてテキストプロンプトを一切用いずに音響的な意味論だけで発動するproactive assistanceです。
SoundFlow training
SoundFlowは音声信号、中間表現、および教師信号を単一の時系列にまとめ、language-modelingの目的関数と応答トリガーの目的関数を同時に学習します（図3）。具体的には、各ストリーミングステップでモデルはトリガーするか否か（d_t）と、トリガーが正しい行動の場合における次の応答トークンの両方について教師信号を受け取ります。報告されている学習は「comprehension-aware」と表現されており、トリガー判断が純粋に音響的なVADスタイルの手がかりではなく蓄積された意味的状態に基づいて行われることを意味しています。これにより、同一のパラメータがproactiveな介入と同時翻訳を単一のlossのもとで扱えるようになります。
デプロイメントでは非同期低レイテンシ推論を使用し、知覚と応答生成を分離することで、長い応答のデコードが後続の音声チャンクの取り込みを停滞させないようにしています。これは安定した常時稼働動作に必要な特性です。
StreamAudio-2M
既存の音声SFTコーパスは本質的に (clip, instruction, response) のトリプレット（Kong et al. 2024; Chu et al. 2024）であり、入力と応答の間に固定された境界を前提としているため、トリガーを学習させることができません。StreamAudio-2Mはストリーミングネイティブに構築されており、各サンプルはインタリーブされたイベントと疎なコンテキスト依存応答キューを持つ3〜15ターンの異種混合インタラクションです。規模は合計302k时間の260万アイテムであり、Audio Agent、Proactive Respond、Voice Chatting、Streaming Audio Understanding、Following Music、Real-time ASR、Streaming Translationの7つの主要カテゴリと28のサブタスクに分類されています。キューの疎さにより、モデルは d_t = \text{silent} を高い事前確率を持つデフォルトとして学習することを強いられ、これは人間の聞き手がほとんどの場合に割り込まないという性質を反映しています。
付随するProactive-Sound-Benchは質的に新しい能力を対象としており、明示的な指示なしに音声の意味論だけに基づいてモデルが適切に介入するかどうかを評価します。これはMMAU、VoiceBenchスタイルのスイート、あるいはLibriSpeechのいずれでも測定できないものです。
評価
Audio-Interactionはオフラインおよびストリーミング能力を網羅する8つのスイートでベンチマークされています：MMAU（Sound/Music/Speech understanding）、VoiceBenchプロトコルに従った音声対話セットAlpacaEval、SD-QA、Llama Questions、Web Questions、ASRのためのLibriSpeech clean/other、S2TTのためのCoVoST2 En\leftrightarrowZh、そしてProactive-Sound-Benchです。選択されたセクションでは実験設定を記述していますが、スコア表は列挙していないため、利用可能な主要な数値的主張はコーパスの規模（260万 / 302k時間 / 28サブタスク）と評価面の広さであり、ストリーミング/trigger目的関数の追加がオフラインタスクの性能を低下させないように明示的に設計されています。
限界と未解決の問題
提供されているセクションでは、バックボーン、音声トークナイザ、チャンクサイズ、trigger-headのアーキテクチャといった再実装の中心的な詳細が示されておらず、オフライン対オンラインのトレードオフも定量化されていません。3つの未解決の問題が自然に生じます：(i) モデルが過剰に割り込んだりキューを見逃したりしないよう d_t はどのように較正されているのか——閾値処理されたlogitなのか、別個の分類器なのか、あるいはLMの語彙における学習済みaction tokenなのか？(ii) 長文生成が新たな顕著な入力（barge-in、応答途中の撤回）と重複する場合、非同期推論はどのようにスケジューリングされるのか？(iii) Proactive-Sound-Benchはイベント検出と指示追従に帰着するのか、それとも真に新しい能力を必要とするのか？同一コーパス上でSoundFlowの joint lossとバニラLMのみの目的関数を比較するアブレーションがなければ、得られた向上をトレーニングフレームワークに帰属させるべきかデータに帰属させるべきかを判断することも困難です。
この研究の意義
音声をストリームとして扱い、モデル自身がいつ発話するかを決定するという定式化は、embodied assistantや常時稼働エージェントにとって正しいアプローチであり、トリガー判断を外部のVADではなく一級の教師付き量として扱うことを強制します。302k時間のストリーミングネイティブコーパスとproactiveベンチマークはより永続的な貢献であり、評価対象としての「online LALM」が何を意味するかを定義しています。
Source: https://arxiv.org/abs/2606.05121
Hacker News Signals
Gemma 4 12B: 統合されたエンコーダーフリーのマルチモーダルモデル
Gemma 4 12B はGoogleの最新オープンウェイトモデルであり、独立したvision encoderを完全に廃止した点が注目されます。CLIP方式のencoderがembeddingを言語モデルに供給するアーキテクチャではなく、テキストを処理するのと同じtransformerスタックで画像トークンを直接処理し、統一されたトークン空間を使用します。このエンコーダーフリーな設計はアーキテクチャの複雑さを低減し、ツータワー型マルチモーダルシステムに共通するencoder-decoderのアライメント問題を排除します。
このモデルは128Kコンテキストウィンドウをサポートし、画像とテキストが混在する入力、1プロンプトあたり複数の画像、および動画フレームを処理できます。12Bパラメータという規模により、量子化を適用することでコンシューマー向けGPUのVRAMに収まります。ウェイトはGemmaライセンス（制限付きで研究・商用利用可）のもとで公開されています。
技術的な観点での注目点は、エンコーダーフリーという選択にあります。Fuyu-8Bのような先行研究は、より小規模でこの主張を展開しました。Gemma 4 12Bは、LLaVA方式のモデルのようなencoderベースの競合がよく最適化されている規模において、このアプローチが通用するかを検証する意義深いテストケースです。トレードオフとして、言語モデルのバックボーンは、畳み込みやViTパッチembeddingのような専用の帰納的バイアスなしに、スケールと学習データの多様性のみに依存して空間的・視覚的表現を学習しなければなりません。細粒度の視覚タスク（OCR、チャート、空間推論）においてこのアプローチが実際に汎化性能で優れるか劣るかは、公開ベンチマークが部分的にしか答えていない未解決の実証的問題です。
HNでの議論は、ライセンス制限（競合するfoundation modelの学習への使用禁止）、LLaVA方式の代替手段と比較した実際の推論コスト、そしてSigLIP encoderを採用していたPaliGemmaシリーズとのアーキテクチャ比較に集中しています。
Source: https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/
Claudeを製品全体でどのように制御するか
Anthropicのエンジニアリング記事では、Claudeがツールコールやエージェントアクションを各製品にわたって実行する際に用いられる隔離とサンドボックスのレイヤーについて説明しています。核心的な問題は、ツールを呼び出したり、Webを閲覧したり、ファイルを書き込んだり、APIを呼び出したりできるLLMが、偶発的・敵対的な誤用に対して大きな攻撃対象領域を生み出すという点です。この記事では4つの制御レイヤーを取り上げています。
第一に、ネットワーク隔離――ツールコール用コンテナはデフォルトで外部への通信が遮断されており、外部ネットワークへのアクセスには明示的な許可リストへの登録が必要です。第二に、capability scoping――各デプロイメントコンテキストには許可されたツールタイプのマニフェストが与えられ、プロンプトで要求された場合であっても、Claudeは宣言されたスコープ外のツールを呼び出すことができません。第三に、prompt injection対策――Webページやユーザーがアップロードした文書からの信頼できないコンテンツは、システムプロンプトレベルの指示から構造的に分離されており、取得されたコンテンツへの命令注入を検出するヒューリスティクスも備えています。第四に、アクション可逆性の優先――システムは不可逆なアクションよりも可逆なアクションを優先するよう設計されており、設定可能なリスク閾値を超える副作用を伴う操作の前には確認のための一時停止を行います。
この記事は、これらが多層防御（defense-in-depth）の措置であり、保証ではないと率直に述べています。特にprompt injectionはモデルレベルでは未解決のままであり、対策は意味論的なものではなく、構造的なもの（コンテンツタグ付け、retrieval sandboxing）に限られています。確認一時停止メカニズムは正確なリスク分類に依存しており、その分類自体がClaudeを通じて行われるため、潜在的な循環性が生じます。
システムの観点から最も技術的に興味深い点は、ツールマニフェストのアーキテクチャです。capability scopingを実行時チェックではなく静的な宣言として扱うことで攻撃対象領域を縮小できますが、連鎖したツールコールによるマニフェストの迂回を防ぐために慎重なAPI設計が求められます。
Source: https://www.anthropic.com/engineering/how-we-contain-claude
Elixir v1.20: 段階的型付け言語へ
Elixir 1.20 では、段階的型システムの最初のプロダクショングレードの層が導入されました。これは複数年にわたる取り組みであり、他の言語で一般的なHindley-MilnerやBidirectionalアプローチではなく、集合論的型（set-theoretic types）を基盤としています。型代数はユニオン型・インターセクション型・否定型をプリミティブとして使用しており、これはElixirのパターンマッチングのセマンティクスやBEAMの動的ディスパッチと自然に対応しています。
設計上の重要な制約として、Elixirは既存のコードに対して型アノテーションを要求することができません。システムはパターンマッチ、ガード、struct定義から型を推論し、その情報を用いて型違反に対してエラーではなく警告を発行します。これは真の意味での段階的型付け（gradual typing）です。型なしのコードは透過的に相互運用でき、型チェッカーは確信を持って主張できるだけの情報がある箇所でのみ動作します。
具体的には、チェッカーは関数呼び出しを通じた型の追跡、case式における網羅性の失敗の検出、不一致なstruct フィールドアクセスのフラグ付けを行います。警告はコンパイル時に出力され、既存のmix compileパイプラインに統合されています。基本的なカバレッジのために新しい構文は不要であり、Dialyzerの@typeおよび@specアノテーションも引き続きサポートされ、新しいシステムにフィードされます。
集合論的基盤が重要なのは、Dialyzerが近似を必要とするような、複数節関数やorガードから自然に生じるユニオン型を適切に扱えるためです。理論的な裏付けはGiuseppe Castagna によるsemantic subtypingの研究であり、José ValimとそのチームによってElixir向けに適応されました。アノテーションサポートを伴う完全な関数レベルの型推論は、今後のリリースで計画されています。
HNのディスカッションは概ね好意的で、DialyzerのSuccess/Painの歴史との比較や、BEAMの動的な性質（ホットコードリロード、メッセージパッシング）が型システムの検証能力に根本的な限界をもたらすかどうかについての議論が見られます。
Source: https://elixir-lang.org/blog/2026/06/03/elixir-v1-20-0-released/
トロント大学の研究者、あらゆるオンラインデバイスを標的にできるAIワームを実証
トロント大学の研究者たちが、LLMを統合したアプリケーションを悪用する自己複製型攻撃を実証しました。脅威モデルは次の通りです：ターゲットシステムが外部コンテンツ（メール、ドキュメント、Webページ）を処理するためにLLMを使用している場合、攻撃者はそのコンテンツに敵対的な命令を埋め込み、LLMにデータを外部へ送出させるとともに、ターゲットが通信する下流のシステムに感染するペイロードを含む新たな出力を生成させます。
その仕組みは、prompt injectionと自己複製の組み合わせです。注入されたペイロードは、応答や転送されるコンテンツに敵対的な命令のコピーを含めるよう、モデルに指示します。メールアシスタントのシナリオでは、感染したメールが届くと、LLMがそれを処理し、ペイロードを含む返信や転送メールを作成し、受信者のメールアシスタントも次々と侵害されていきます。「ワーム」という呼び名は適切であり、従来のコード実行の脆弱性を必要とせず、モデルの通常の出力チャネルを通じて伝播します。
実際の深刻度は、アプリケーションのツール権限に大きく依存します。読み取り専用の要約パイプラインへの影響は低い一方、メール送信・ファイル書き込み・API呼び出しの権限を持つアシスタントへの影響は高くなります。上記のAnthropicの投稿で説明されている封じ込めレイヤー、すなわちネットワーク分離とツールのスコープ制限は被害の範囲を限定しますが、複製ベクタ自体を防ぐことはできません。
この研究は、伝播経路の具体的な分類体系を提示し、GPT-4およびGeminiベースのアプリケーションに対する動作するプロトタイプを実証しています。根本的な防御のギャップは未解決のままです。命令とコンテンツを区別することはモデル自身が確実に解くことのできない意味論的な問題であり、構造的な緩和策（タグ付け、サンドボックス化）は攻撃対象領域を縮小しますが、完全には排除できません。
Source: https://www.utoronto.ca/news/u-t-researchers-demonstrate-ai-worm-could-target-any-online-device
ポータブルなARM64アセンブリの書き方（2023年）
この記事は、実際に存在するポータビリティのギャップを扱っています。System V ABIを用いるLinux/ELF向けのARM64アセンブリは、AppleのABIバリアントを用いるmacOS/Mach-O向けのARM64アセンブリと乖離しており、さらにその両方がWindows ARM64とも異なります。著者は、クロスプラットフォームの低レベルコードで実際に問題となる具体的な非互換性を文書化しています。
取り上げられている主な相違点：(1) スタックアライメント要件 — macOSはすべてのコールサイトで16バイトのスタックアライメントを要求し、Apple Siliconではハードウェアレベルで強制されます。Linuxは実用上よりも寛容です。(2) 呼び出し規約の違い — AppleのABIはx18をプラットフォームレジスタとして予約しており、アプリケーションコードで使用してはなりません。標準のAAPCS64ではx18はソフト予約に留まっています。(3) プロシージャリンケージ — ELFターゲットでは、外部関数呼び出しは通常PLTスタブを経由します。Mach-Oでは、異なるスタブ形式を持つ別セクション内のスタブを使用するパターンが採用されています。(4) ローカルラベルの構文 — gasおよびclang/llvmアセンブラは、ターゲットによってローカルラベルの扱いが異なります。
推奨されるポータビリティ戦略は、プラットフォーム固有の呼び出し規約の詳細を抽象化するためにプリプロセッサマクロを用いた条件付きアセンブリを採用すること、およびx18を一切使用しないことです。記事には、関数のプロローグとエピローグに関する具体的なビフォー・アフターの例が含まれています。
これは、複数のARM64プラットフォームをターゲットにする必要がある手動最適化された暗号処理、SIMDカーネル、またはJITエミッタを書く方にとって実践的に重要な内容です。特にmacOSとLinuxの乖離は、一方のプラットフォームでテストしてもう一方にデプロイする開発者が陥りやすい問題です。この記事は2023年のものですが、根底にあるABIの差異は現在も変わっていません。
Source: https://ariadne.space/2023/04/12/writing-portable-arm-assembly.html
thunderbolt-ibverbs: 家にInfiniBandがある
このHellas AIによるブログ記事は、ThunderboltハードウェアとInfiniBand Verbs（ibverbs）ユーザー空間APIを組み合わせて、小規模なGPUクラスター向けの高帯域・低遅延インターコネクトを構築する方法を解説しています。前提となる考え方は次のとおりです。専用のInfiniBand NICやスイッチは高価ですが、Thunderbolt 4リンクは40 Gbpsの帯域幅を提供し、プロトコルが本質的にPCIe-over-cableであるためPCIeレベルの遅延を実現できます。
技術的なアプローチとしては、thunderbolt-netカーネルドライバーを使ってThunderboltリンクをネットワークインターフェースとして公開し、その上でRoCE（RDMA over Converged Ethernet）を動作させます。元々InfiniBand向けに設計されたibverbs APIはRoCE上でも動作するため、NCCLやその他のRDMA対応集合通信ライブラリを変更なしに利用できます。その結果、GPU間のデータ転送は、コモディティなThunderboltケーブル上のRDMAセマンティクスを介してCPUとカーネルのネットワークスタックをバイパスできるようになります。
計測された数値は、同じリンク上の標準的なTCP/IPと比較して有意な遅延改善を示しており、大きなデータ転送においては帯域幅がThunderboltの理論上の上限に近づいています。主な制限はトポロジーにあります。Thunderboltのデイジーチェーンはサポートできるノード数が限られており、本番のInfiniBand環境で使用されるノンブロッキングのfat-treeトポロジーを提供できません。モデル並列処理やパラメーターサーバーのワークロードを行う2〜8ノードのクラスターにとっては、コスト効率の高い代替手段となります。
この記事には、カーネルモジュール、ibverbs設定、およびNCCLの環境変数に関するセットアップ手順が含まれています。コンシューマー向けハードウェアからデータセンタークラスのインターコネクトセマンティクスを引き出す好例と言えます。
Source: https://blog.hellas.ai/blog/thunderbolt-ibverbs/
Gooey: ZigのためのアクセラレーテッドなUIフレームワーク
GooeyはZigで書かれた初期段階のUIツールキットであり、WebGPU（wgpuネイティブライブラリ経由）を用いてすべてのレンダリングをGPU上で行います。アーキテクチャはretained-modeを採用しており、アプリケーションはウィジェットツリーを構築し、前フレームとの差分を取り、変更された領域に対してドローコールを送信します。HTML、DOM、システムウィジェットツールキットへの依存は一切ありません。
レンダリングパイプラインは、テキストおよびシェイプのレンダリングにsigned-distance field（SDF）技術を使用しており、複数サイズでのラスタライズを行わずに解像度に依存しないレンダリングと滑らかなスケーリングを実現します。グリフはテクスチャアトラス上にSDFとして格納され、フラグメントシェーダーがピクセル中心でSDFを評価してアンチエイリアシングを解析的に適用します。これは一部のゲームエンジンやターミナル（例：Ghostty）が高品質なGPUテキストレンダリングのために採用しているアプローチと同様です。
Zigのcomptime機能はウィジェットシステムに活用されており、ウィジェットの型とそのプロパティをコンパイル時に解決することでランタイムディスパッチのオーバーヘッドを削減しています。レイアウトエンジンはflexboxアルゴリズムの実装であり、CSSでおなじみのものですがWebプラットフォーム固有の複雑さを持ちません。
本プロジェクトはpre-1.0であり、APIのサーフェスは小さいです。現時点での制限としては、アクセシビリティツリーの未対応、IMEサポートの欠如、システムクリップボード統合の未実装が挙げられており、これらはいずれもプラットフォーム固有の難しい問題です。HNのコメントでは、このプロジェクトがclay（Zigで人気のimmediate-modeレイアウトライブラリ）と似たニッチを占めつつも、retained-modeの設計と、レンダリングを呼び出し元に委譲するのではなく直接WebGPUバックエンドを使用する点が異なると指摘されています。
Zigエコシステムの動向を示すデータポイントとして、またシステムUIフレームワークを完全にバイパスするアプリケーション層でのGPUレンダリングへの継続的なトレンドの一例として、興味深い取り組みです。
Source: https://github.com/duanebester/gooey
QBE – コンパイラバックエンド – 1.3
QBEは小規模なコンパイラバックエンド（約15KのCコード）であり、LLVMのコンパイル時コスト・API複雑性・バイナリサイズを避けながらも適切なコード生成品質を必要とする言語実装者向けの、LLVMの代替として設計されています。バージョン1.3では複数のバックエンド改善とバグ修正が加えられています。
QBEはSSA形式の独自IRを定義しており、精神的にはLLVM IRに近いものの、スコープは大幅に小さくなっています。このIRは整数型・浮動小数点型・集成型・フラットメモリモデルをサポートしており、QBEはこのIRからx86-64、ARM64、RISC-Vのアセンブリを生成します。最適化パスはLLVMと比べて限定的であり――基本的なデッドコード除去、コピー伝播、線形スキャンアロケータによるレジスタ割り当て――に留まりますが、GCC -O1の出力から通常20〜30%以内の性能を持つコードを生成するには十分です。
QBEの価値提案は実装のシンプルさにあります。QBEはLLVMにはない形で、読みやすくハックしやすい設計になっています。いくつかの趣味・研究向け言語（CコンパイラであるCprocや、MLファミリーの実験的言語など）での採用実績があります。バージョン1.3のリリースノートでは、ARM64における集成型戻り値の処理改善、RISC-V呼び出し規約実装の修正、およびレジスタアロケータにおける複数の正確性修正について説明されています。
HNのディスカッションでは、QBEが適切な選択かどうかという定番の議論が提起されています――より工業的強度のレジスタアロケータと明示的なWASMサポートを備え、同様のユースケースを対象とするCranelift、あるいは単純にCをIRとして使用するアプローチとの比較です。QBEの回答はシンプルさと監査可能性にあります――バックエンド全体が週末の読書に収まるほどのサイズです。
注目の新規リポジトリ
chiennv2000/orthrus
Orthrusはspeculative decodingを異なる角度から取り組んでいます。別途ドラフトモデルを用意する代わりに、デュアルビュー拡散メカニズムを使って候補トークン列を並列生成し、ベースLLMの単一forward passでそれらを検証します。「デュアルビュー」というフレーミングは、部分的にデコードされたシーケンスについて2つの相補的な表現——自己回帰的なものと拡散ベースのもの——を同時に保持し、それらを調整することで元のモデルのgreedy/samplingデコードと同一の分布を持つ損失のない出力を生成することを意味します。主張されている高速化は、複数のドラフトトークンに渡って検証コストを同時償却することから生じており、精神的にはMedusaやEAGLEに近いですが、ターゲットモデルに対して別途headをfine-tuningする必要がありません。実装はPyTorchベースであり、標準的なHuggingFace互換LLMをターゲットとしているようです。モデルの重みを変更できない実務者（APIに制約されている、あるいは本番環境でcheckpointが固定されている場合）にとって、training-freeなspeculativeメソッドは真に有用です。損失なし保証は、近似的な高速デコードスキームと区別するハード制約です。デプロイ前に実際のacceptance-rateの数式とA100/H100ハードウェア上の実測ベンチマークを精査する価値があります。未解決の問題としては、拡散ビューが長いコンテキストのKV cacheをどのように扱うか、またデュアルステートのオーバーヘッドが短いシーケンスにおける利益を損なわないかどうかが挙げられます。
Source: https://github.com/chiennv2000/orthrus
UditAkhourii/adhd
ADHDは、ClaudeおよびCodex Agent SDK上に構築されたコーディングエージェント向けに、Tree-of-Thought（ToT）推論をコンポーザブルなskillとして実装したものです。コアメカニズムは、「認知フレーム」（例：セキュリティ優先、パフォーマンス優先、シンプルさ優先）ごとに複数の発散的な推論ブランチをファンアウトさせ、設定可能なヒューリスティクスで各ブランチをスコアリングし、スコアが閾値を下回るブランチをプルーニングし、生き残ったパスのみを再帰的に深掘りします。これはオリジナルのToT論文で説明されているBFS/DFSの変形に機械的に近い手法ですが、生のcompletion APIの上に乗せるのではなく、エージェントのtool-callループに直接組み込まれています。プルーニングは明示的かつ早期に行われますが、これは各ノードがエージェントの完全な1ステップを伴うコスト制御において重要です。並列ファンアウトは、解空間が真に多峰性を持つ問題——アーキテクチャの決定、アルゴリズムの選択、異分野横断的な統合——を対象として設計されており、単一パスのコーディングタスクには向いていません。スタンドアロンエージェントではなくskill（SDKのプラグインモデルにおける再利用可能な呼び出し単位）として構築されているため、パイプライン内の他のskillと組み合わせることができます。主な技術的リスクは、スコアリング関数がヒューリスティクスかつドメイン固有である点です。適切なスコアリングがなければ、プルーニングはランダムな打ち切りに退化してしまいます。カスタムフレームセットおよびスコア関数の定義に関するドキュメントが、実際の普及を左右することになるでしょう。
Source: https://github.com/UditAkhourii/adhd
code-yeongyu/lazycodex
LazyCodexは、OpenAI Codexに特化して構築されたagent harnessであり、大規模なマルチファイルのコードベースにおいてCodexがコヒーレンスを失うという失敗モードを対象としています。この問題に対し、三つのサブシステムで対処しています。すなわち、ファイルの役割・依存関係グラフ・過去のタスク結果の構造化サマリーをセッションをまたいで保存する永続的なプロジェクトメモリ、コードを書き始める前にユーザーの意図を順序付きタスクグラフへと分解するプランニングレイヤー、そして各実行ステップ後にテストと静的解析を実行し、失敗時に再プランニングを行う検証ループです。「verified completion」というフレーミングは、コードが生成された時点ではなく、自動チェックが通過した時点でのみagentが成功を報告することを意味します。これはSWE-agentやDevin方式のscaffoldingとアーキテクチャ的に類似していますが、基盤モデルとしてCodexを明示的に対象としています。プロジェクトメモリコンポーネントが最も技術的に特徴的な部分であり、セッションをまたいでコードベースのサマリーを最新の状態に維持することで、有効なcontext windowの要件を削減し、単一のpromptを超えるリポジトリをagentが扱えるようにします。未解決の主な問題として、ファイルが外部から変更された際のメモリの無効化方法、およびタスクグラフのプランナーが循環依存（例えば、テストに影響を与えるリファクタリングがさらなるリファクタリングに影響する場合など）を処理できるかどうかが挙げられます。
Source: https://github.com/code-yeongyu/lazycodex
microsoft/intelligent-terminal
これは、オープンソースの Windows Terminal（C++/WinRT で記述された Microsoft の標準ターミナルエミュレータ）のフォークであり、エージェントレイヤーをシェル UI に直接組み込んだものです。独立したチャットパネルではなく、エージェントの統合はインラインで行われており、コマンド出力の監視、stderr の横取り、修正候補の提示、同一ターミナルセッションのコンテキスト内でのフォローアップコマンドの実行が可能です。既存のシェルアシスタントツール（例：GitHub Copilot CLI、warp.dev）との技術的な相違点は、エージェントがターミナルの内部状態——スクロールバックバッファ、カレントディレクトリ、終了コード——に直接アクセスできる点にあり、スクリーンスクレイピングされたテキストを解析する必要がありません。この緊密な結合により、ターミナルプロセスの外部に位置するツールよりも、より信頼性の高いコンテキスト抽出が実現されます。既存の Windows Terminal レンダリングエンジン（DirectWrite、DXGI）および入力処理の上に構築されているため、エージェントがアイドル状態の際はベースとなるターミナルのパフォーマンスに影響を与えません。この統合は Windows AI Foundry / Azure OpenAI スタックを対象としています。主な制限として、WinRT への依存により構造上 Windows 専用となっており、エージェントのアクションスペースは現在、完全な自律実行ではなくテキストの提案に限定されています。Windows プラットフォーム上での深いターミナルとエージェントの統合に関するリファレンス実装として有用です。
Source: https://github.com/microsoft/intelligent-terminal
atomicstrata/atomicmemory
AtomicMemoryは、AIエージェント向けのポータブルなセマンティックメモリレイヤーを提供するライブラリであり、最初からフレームワーク非依存となるよう設計されています。コアエンジンは、embedding ベースのメモリチャンクの保存・検索を担い、直近重み付け、関連性スコアリング、オプションの忘却曲線をサポートしています。エンジンの上位層には複数のインテグレーションサーフェスが用意されています。すなわち、直接プログラム的に利用するための TypeScript SDK、LangChain や LlamaIndex スタイルのエコシステムを対象としたフレームワークアダプター、MCP 互換エージェントがツールとして利用できる MCP（Model Context Protocol）サーバー、検査やデバッグ用の CLI、そして特定環境への組み込み向けホストプラグインです。ポータビリティに関する主張は実質的なものであり、MCP サーバーと TypeScript SDK の両方を公開することで、同一のメモリストアが Claude Desktop プラグイン、カスタム Node.js エージェント、Python LangChain エージェントに対して、ストレージを重複させることなく機能します。セマンティック検索は、ローカルのベクターインデックス（おそらく HNSW またはフラットコサイン距離を用いた embedding モデル）を利用していると考えられ、クラウドベクター DB への依存なしにセルフホスティングが可能です。調査すべき主要な技術的課題としては、メモリがエージェント・ユーザーごとに名前空間分離されているか、矛盾するメモリが存在する場合の競合解決の仕組み、デフォルトで使用される embedding モデルおよびその差し替え可否などが挙げられます。
Source: https://github.com/atomicstrata/atomicmemory
agentic-in/elephant-agent
Elephant Agentは「Personal-Model First」アーキテクチャを中心に設計されています。このエージェントは、セッションをまたいでステートレスに動作するのではなく、特定のユーザーに関する永続的かつ成長し続けるモデルを維持することを目的としています。「自己進化（self-evolving）」という側面は、基盤となるLLMの明示的な再学習を必要とせず、インタラクション履歴・フィードバック信号・タスクの成果に基づいて、エージェントが内部のユーザーモデルおよび行動ポリシーを更新することを指します。機構的には、構造化された長期メモリストア（「elephant（象）」というメタファー）、暗黙的なシグナルからの選好推論、そして推論時に蓄積されたユーザーモデルを組み込む動的なprompt構築が関与していると考えられます。これはパーソナライズドエージェントやlifelong learningスキャフォールドに関する研究と構造的に関連していますが、ドメイン固有のツールではなく汎用パーソナルアシスタントとして位置づけられています。スター数と説明の野心的な内容との比較からリポジトリは初期段階にあると判断されます。自己進化メカニズムの技術的な深さ、具体的には真に適応的なのか単なる累積的なメモリ検索に過ぎないのか、については直接コードを検査する必要があります。最も興味深いエンジニアリング上の問いは、エージェントが古いユーザー選好と新しいユーザー選好の矛盾をどのように処理するか、そしてユーザーモデルがフラットなメモリログを超えた何らかの解釈可能な構造を持っているかどうかという点です。
Source: https://github.com/agentic-in/elephant-agent
freestylefly/wesight
WeSightは、複数のコーディングエージェント（Claude Code、OpenAI Codex、OpenClaw、Hermes）を単一のUIから実行したい開発者を対象としたデスクトップAIエージェントワークスペースです。各エージェントを個別に設定する手間を省く「ワンクリックセットアップ」が主要な価値提案となっており、環境設定・認証・ルーティングを自動化することで、ユーザーはツール間のコンテキストスイッチングなしに、タスクの種類や好みに応じて異なるエージェントにクエリを振り分けることができます。技術的に興味深いのはカスタムLLMモデルルーティングレイヤーです。これはおそらく、受信タスクを分類して最適なバックエンドに転送するディスパッチャーを実装しており、概念的にはmixture-of-agentsルーティングに近いですが、inference levelではなくオーケストレーションレベルで動作します。デスクトップアプリケーションとして構築されており（クロスプラットフォーム展開という位置付けからElectronまたはTauriと思われます）、オープンソースであるためルーティングロジックの検査やカスタマイズが可能であり、これがクローズドなオーケストレーション製品との差別化点となっています。実用上の懸念点としては、デスクトップアプリにおける複数APIキーの認証情報管理には慎重なセキュリティ設計が必要であること、また境界が曖昧なタスクに対してはルーティングヒューリスティックのチューニングが必要になることが挙げられます。単一プロバイダーのIDE統合にベンダーロックインされることなく、統合されたエージェントワークスペースを求めるチームにとって有用です。
Source: https://github.com/freestylefly/wesight
MyuriKanao/src-hunter-skill
SRC Hunter は、バグバウンティ、SRC（Security Response Center）への報告、クラウドソーシング型ペネトレーションテストに携わるオフェンシブセキュリティ研究者を対象とした、Claude Code skill（Claude エージェント SDK 向けの構造化プロンプト・ツールパッケージ）です。技術的な内容は充実しており、標準的なウェブおよびAPI脆弱性クラスを網羅した19種類の攻撃クラスプレイブック、脆弱性タイプ別に整理された305件の構造化ペイロード、263件のWAFおよびEDRバイパステクニック、2,887件のHackerOne実事例リファレンス、そして88,636件のWooYun（中国の歴史的バグバウンティプラットフォーム）ケースの統計分析が含まれています。後者の2つのコンポーネントが、このツールを汎用的なペイロードリストと差別化する点です。エージェントの攻撃手法選択を過去の事例分布に基づいて根拠付けることで、理論的な網羅性ではなく実証的な成功率によってテクニックの優先順位を付けることが可能になります。機能的には、このskillはClaude Codeのtool-callループに組み込まれます。エージェントはプレイブックを用いてリコナイサンスおよびエクスプロイテーションの推論を構造化し、具体的なインジェクション文字列をペイロードライブラリに問い合わせ、フィルタリングに遭遇した際はバイパステクニックを参照します。法律および倫理上の主な注意点は明確です。このツールは、明示的に認可されたテストおよび研究コンテキストを対象としています。WooYunの統計コーパスは、現在は閉鎖されたプラットフォームにおける中国のウェブセキュリティ脆弱性パターンのスナップショットとして、歴史的に重要な意義を持ちます。ドキュメントは主に中国語で記述されています。