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

公開

2026年8月25日

English · 日本語

arXiv ハイライト

ReWorld: 長期記憶を持つインタラクティブ世界モデル

インタラクティブ世界モデルは構造的な矛盾に直面しています。action-conditionedなロールアウトは、制御レイテンシを低く保ち遠い文脈でのドリフトを防ぐために短い受容野を必要とする一方、再訪時の空間的一貫性は過去に任意の遠さまで到達するattentionを要求します。ストリーミングデプロイメントではハードな予算制約が課されており、KV cacheは無制限に増大できません。ReWorldはWan2.2-TI2V-5Bから初期化されたcausal flow-matching DiTの上に、これら二つの目的をtraining時に分離し、inference時に制限する仕組みを実装しています。

制御と記憶の分離

モデルは一度に一つの潜在チャンク z_k を生成し、各チャンクはチャンクごとの6-DoF action a_k とpose P_k に条件付けられています。単一のtransformerの中で短期・長期のレジームを分離するために、二つのアイデアが採用されています。

  1. ヘッドごとの混合attentionウィンドウ。 H=24 個のattentionヘッドのうち、|\mathcal{G}|=6 のグローバルサブセット \mathcal{G} が完全なcausal履歴全体にattendし、残り18個のヘッドは w=12 フレームのローカルウィンドウにattendします。ローカルヘッドは反応的な制御信号を担い、グローバルヘッドはランドマークスケールの記憶を担います。

  2. ランダムヘッドルーティング。 固定されたパーティションを使用すると、二つの能力が特定のヘッドに結び付いてしまい、ヘッドのプルーニングやcacheポリシーの変更に対して脆弱になります。代わりに、optimizerの各ステップで、グローバルセットを |\mathcal{P}|=12 のランダムな6ヘッドパーティションからなるプール \mathcal{P} から決定論的にサイクリングして選択します。これにより、すべてのヘッドが期待値として両方の役割を担うことになります。

固定パターンプール上のランダムルーティングを用いたヘッドごとの混合attentionウィンドウ。

pose情報はMRoPE（pose-indexedな回転埋め込み）を通じてattentionに入力されるため、何千フレームも前にキャッシュされた「ランドマーク」も現在のクエリに対して明確に定義された幾何学的関係を持ちます。actionはposeのみを通じてではなく、チャンク表現に直接注入されることで、ローカルヘッドに鋭い制御信号を与えます。

pose-indexedランドマークによる有界inference cache

inferenceでは、KV cacheは B=12 チャンクに固定され、1つのsinkチャンク、6つのpose検索ランドマーク、および生成中のチャンクに隣接する5つの直近チャンクに分割されます。チャンクが直近ウィンドウから古くなると、カメラposeでindexされた有界のランドマークバンクに統合されます。バンクが満杯の状態で新しいエントリを受け入れる必要がある場合、最も冗長なメンバーを追い出し、バンクをスパースかつ空間的に多様に保ちます。再訪時には、現在のposeに最も近いランドマークがcacheに取り出されるため、定常コストで無制限のロールアウトにわたって空間記憶が持続します。

固定KVバジェット B=12 での記憶統合とchunk-drop training。

inferenceでのcacheは履歴のスパースで非連続なスライスであるため、training時のattention分布もそれに一致する必要があります。そのためReWorldはランダムチャンクドロッピングを適用します。各 L=12 チャンクのtrainingウィンドウ内で、KVチャンクをランダムに1つのsinkに加えて6つのチャンクだけが保持されるまでドロップします。これを行わないと、グローバルヘッドは密な履歴にoverfitし、ランドマーク+直近のcacheを与えられると大幅に性能が劣化します。

メトリックアライメントデータとpalindrome軌跡

記憶のtrainingには、カメラが実際に以前に見たコンテンツに戻る場所での監督が必要です。データパイプラインにおける二つの設計上の選択がこれに対処しています。

  • Palindromeルート。 UEでレンダリングされた軌跡は自身のパスを逆にたどるため、グラウンドトゥルースビデオには記憶ヘッドがスコアリングに必要な再訪イベントが含まれます。
  • メトリックスケールアライメント。 データコーパスは8つのソースを統合しています。UEでレンダリングされた2セット、3つの実写（DL3DV、RealEstate10K、Sekai real-walking-hq）、および3つのゲーム（79タイトルのローミング、OmniWorld-Game、Sekai game-walking）で、pose-annotatedクリップの合計は220,724件です。すべてのposeは、特定のキー押下でカメラがソース間で同じ物理的距離だけ移動するようにリスケールされます。これを行わないと、UEで学習されたaction-to-motionのマッピングが、実世界のVIPEまたはMegaSaM推定poseと一致しなくなります。

UEサービスは337環境のフライスルーを2つの注目点に固定し、それらの間のセグメントを方向バランスのとれたランダムモーションで埋めます。キュレーションファネルは、画面上の速度分布を均一にするために、速すぎるまたは遅すぎるクリップをドロップします。

全体フレームワーク：メトリックアライメントデータ、分離された制御/記憶training、および有界cacheストリーミングinference。

LoRA-DMDによるリアルタイムサンプリング

双方向バックボーンはまずteacher forcingによってストリーミングcausalモデルに変換され、次にLoRA adapterに限定された分布マッチング蒸留（LongLive-2.0レシピ）によって4サンプリングステップに圧縮されます。単一のバックボーンが高忠実度の多ステップモードと4ステップリアルタイムモードの両方に対応し、swapされるのはLoRAのみです。Trainingは2段階で実行されます。480p（384\times 640）の事前学習、次に補間された空間的RoPEによる720p（704\times 1280）のwarm-startです。

限界と未解決の問題

抜粋された論文はFVDや再訪一貫性の数値をhead-to-headで報告していないため、固定パーティションに対するランダムルーティングの定量的な改善、および密なtrainingに対するchunk-dropの効果はこれらのセクションから直接読み取ることができません。ランドマークバンクの追い出しは冗長性ベースですがposeのみに基づいています。意味的な再訪（同じ部屋、異なるpose）は正しく検索されない可能性があります。実世界ソース（VIPE、MegaSaM）でのpose推定品質は、メトリックアライメントがどれだけ厳密に維持できるかのソフトなフロアとなります。最後に、固定された B=12 バジェットと w=12 のローカルウィンドウは手動で選択されており、グローバルヘッド、ローカルウィンドウサイズ、ランドマークバンク容量の分割に関するスケーリング則は探索されていません。

なぜこれが重要か

インタラクティブ世界モデルはこれまで、長期的な一貫性をメモリ拡張のアドオンまたは無制限コンテキスト問題のいずれかとして扱ってきました。ReWorldは、混合ウィンドウヘッドとランダムルーティング、chunk-drop training、およびpose-indexedランドマークcacheという単一の協調設計によって、固定バジェットのストリーミングtransformerがリアルタイム制御を犠牲にすることなく再訪にわたって空間記憶を維持できることを示しています。これはプレイアブルなニューラルシミュレータにとって具体的なボトルネックです。

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

安定性と探索のジレンマを超えて：LLMポリシー最適化のための環境正則化

問題設定

LLMに対するRLHFスタイルのポリシー最適化では、応答分布のドリフトを制御するためにPolicy-KL項 \mathrm{KL}(\pi_\theta(\cdot\mid q)\,\|\,\pi_{\theta_0}(\cdot\mid q)) を使用します。これはジレンマを生み出します。すなわち、この項を保持すると応答行動が制約され、ポリシーが新たな推論チェーンを発見するために必要な探索の余地が削られます。一方で取り除くと、明示的なドリフト制御がなくなります。著者らはこの問題を再定式化します。標準的なGRPO学習下であっても、現在のポリシーが誘導するクエリ分布——すなわち、モデル自身の分布のもとで各学習プロンプトを接頭辞として生成する確率——は、RL前の参照分布から大きくドリフトしており、行動側のKLはこのドリフトを抑制しないと主張します。

GRPO学習中のKL loss。Query-KL（濃色）は上昇する一方、Policy-KL（淡色）は低いまま推移しており、行動側のKLのみではクエリプロセスが安定化されないことを示しています。

この経験的な動機は明確です。GRPOの学習実行において、応答側のKLは学習を通じてほぼゼロに留まる一方、クエリ側のKLは単調に増加します。したがって、標準的な正則化項は、実際に環境ドリフトを示す軸においてほとんど機能していないことになります。

手法

ERPO（Environment-Regularized Policy Optimization）は、正則化を行動側から入力側へ移します。\rho_{\theta_0} をRL前のモデルが誘導するクエリ分布、\rho_\theta を現在のポリシーが誘導するクエリ分布とします。正則化項は次のように定義されます。

\mathcal{L}_{\mathrm{QKL}} = \mathrm{KL}\!\left(\rho_\theta \,\|\, \rho_{\theta_0}\right),

これは学習クエリごとに評価されます。重要な機械的ポイントは、\mathcal{L}_{\mathrm{QKL}} の勾配がクエリ尤度 \pi_\theta(q)（q を生成する生成物に周辺化）のみを通じて流れるという点です。そのため、PG推定量を駆動する応答スコア関数 \nabla_\theta \log \pi_\theta(y\mid q) は現れません。結果として、QKLは応答分布に直接的な圧力を与えず、行動側の探索を保持します。

QKLペナルティに加えて、ERPOは参照モデルから導出された静的なクエリごとの重み w_i を適用し、\rho_{\theta_0} のもとで典型的なクエリへの更新を偏らせます。QKL値と重み w_i はいずれも固定された参照モデルに対して事前計算されるため、GRPOに対するランタイムコストは固定のルックアップであり、追加のforward-backwardパスは不要です。

ERPOの概要：Query-KLと参照モデル由来のクエリごとの重みを事前計算し、通常のGRPO advantageと組み合わせます。

このパイプラインはGRPO/PPO/REINFORCEスタイルのループに組み込まれます。(a) オフラインで、参照モデルのもとで各学習クエリのQuery-KLと w_i を計算する。(b) オンラインで、クエリごとに応答グループをサンプリングし、reward modelでスコアリングしてGRPO advantageを得る。(c) 応答KL項を事前計算済みのQKLに置き換え、クエリごとに w_i を適用してERPO目的関数を構成する。仮定A1——\rho_\theta を \rho_{\theta_0} に合わせることで事前学習から引き継いだ汎化能力が保たれるという仮定——は前提として扱われ、経験的に検証されます。

結果

実験ではLevel 3–5のMATH問題（約8,500例）を使用します。評価はAIME24、AIME25、AMC、MATH500、Minerva、Olympiadを対象とし、Avg@32、Pass@32、Pass@1を報告します。

ベンチマーク全体の平均において、ERPOはすべての3つの指標でGRPOを上回ります。

  • Avg@32：ベース 0.143 → GRPO 0.274 → ERPO 0.336（GRPOより+6.2ポイント）
  • Pass@32：ベース 0.463 → GRPO 0.575 → ERPO 0.611（+3.6ポイント）
  • Pass@1：ベース 0.149 → GRPO 0.275 → ERPO 0.332（+5.7ポイント）

GRPOに対するベンチマーク別のAvg@32の改善は一貫しています。AIME24: 0.174 → 0.218、AIME25: 0.072 → 0.110、AMC: 0.398 → 0.478、MATH500: 0.528 → 0.677、Minerva: 0.207 → 0.214、Olympiad: 0.266 → 0.316。MATH500での向上（+14.9ポイント）が最大であり、最小の改善は学習分布から最も外れたドメインであるMinervaでした。

数学的推論タスクにおけるサンプリング温度全体でのAvg@32。

安定性正則化の一般的な失敗モードとして、特定のサンプリング温度でのみ良好に見えるという問題があるため、温度スイープは重要な意義を持ちます。ERPOの曲線は温度全体にわたってGRPOを上回り続けており、行動側の探索が制約されていないという主張と整合します。温度を上げても改善が崩れることはありません。

Pass@32の改善（0.575 → 0.611）とともに、より大きなPass@1の改善（0.275 → 0.332）が見られることは、ERPOが多様な解の網羅性を保ちつつモードを鋭くしていることを示唆します。KLの重みが大きいPOがPass@kを犠牲にしてPass@1を改善するという典型的な病理は、ここでは見られません。

限界と未解決の問題

経験的評価は単一の学習コーパス（MATH L3–5、8,500例）と単一のモデルファミリー・サイズのレジームに限定されているため、より大規模なRLHF（例：選好ベースの報酬、数学以外のタスクで報酬がよりスパースな場合、より長いホライズン）におけるQKLとの相互作用は未検証です。A1は前提として主張されており、論文ではQKLペナルティと参照モデル由来の重み w_i のどちらが改善にどの程度貢献しているかを切り分けていません。(w_i \equiv 1) 対 (\beta_{\mathrm{QKL}}=0) のアブレーションによってこの点を明確にできるでしょう。\pi_\theta のもとでのクエリ尤度は、クエリに対する明確に定義された生成モデルを必要とします。\rho_\theta の構成（接頭辞尤度を使うか学習されたクエリサンプラーを使うかによって）は、KL推定量の精度と、学習クエリがベースモデルが自発的に生成するものから大きく外れている場合の手法の挙動を決定します。最後に、Minervaでの改善は僅かであり（0.207 → 0.214）、QKLが主に学習クエリ分布が参照モデルによってよくカバーされている場合に有効かどうかという疑問が生じます。

なぜ重要か

LLM POにおける安定性と探索のトレードオフは、KLの選択に内在するものであってKLの位置には依存しないと考えられてきました。ERPOの観察——Policy-KLはほとんど変化しない一方でQuery-KLがドリフトする——は、この分野が誤った周辺分布を正則化してきたことを示唆しており、入力側の正則化によってPass@kを犠牲にすることなくPass@1を改善できる可能性があります。この結果が数学的推論を超えて成立するならば、GRPO/PPOパイプラインへの組み込みはほぼ追加のランタイムコストなしに実現できる変更です。

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

Apodex 1.1: 複雑な業務に向けたエージェント的知性のスケーリング

問題設定

言語モデルの評価は伝統的にプロンプトから回答へのマッピングとして捉えられてきましたが、実際の専門的業務——財務モデルの構築、文献調査の実施、リポジトリへのパッチ適用——は、ファイル、検索、コードとの継続的な対話を必要とし、ツールエラーや部分的な失敗にも状態を維持しなければなりません。Apodex 1.1 はこれを working capability（作業能力）として定式化します。すなわち、予算制約のもとで外部から指定された成果物に向けた検証可能な進捗です。技術的な主張は、推論品質が一定水準に達した後は、さらなるパラメータ数の増加ではなく、ポリシーが作用する 環境 のスケーリングと複数エージェントにわたる 協調 構造のスケーリングから残りの性能向上が得られるというものです。

タスクコントラクト

本論文はすべてを通じて使用される単一のタスクコントラクトを以下のように定義しています：

\mathcal{E} = (\mathcal{W}, W_0, q, \mathcal{A}, \mathcal{T}, \Omega, \mathbf{B}, D, V_D).

ここで \mathcal{W} はワークスペース状態空間、W_0 は初期ワークスペース、q は正規化された目標（生のユーザーメッセージ u_0 とは区別されます）、\mathcal{A} は行動集合、\mathcal{T} は確率的にもなりうる遷移演算子、\Omega は観測インターフェース、\mathbf{B} はリソース予算（ターン数 B_{\text{turn}}、ツール呼び出し数 B_{\text{tool}}、トークン数、実時間、並列度）、D は納品コントラクト、V_D はその検証器です。非同期ユーザー介入 u_t \in \mathcal{U} \cup \{\varnothing\} はランタイムによって許容され——ポリシーによって選択されるものではなく——次の行動 a_t の前に適用されます。また、q または D への実質的な変更は、ワークスペース状態が再利用される場合でも新たなコントラクトを生成します。この形式化が重要なのは、「完了した作業」の意味を固定するためです：参照回答へのトークンレベルの類似度ではなく、最終的なワークスペース状態に対する検証可能な述語として定義されます。再現には環境マニフェストが外生的状態、ツールバージョン、シードを保持する必要があり、これはハーネスによって強制されます。

手法：2つのスケーリング軸

Environment Scaling（環境スケーリング）。 ツールを追加するのではなく、Apodex はコントラクトを共有し1つの軌跡内で合成可能な3つのファミリーにわたって (W_0, q, \mathcal{A}, \mathcal{T}, \Omega, \mathbf{B}, D, V_D) の分布を拡張します：

  • File worlds は必要な情報をネストされたディレクトリ、過去のバージョン、異種フォーマット、ファイル間参照に分散させます。構築は解法の逆として記述されます：ビジネス状態、権威関係、導出ロジックを定義し、それをエージェントが再構築しなければならないワークスペースに射影します。検証は配信された成果物を基礎となる状態と照合します。
  • Search worlds は競合する主張を持つノイズの多いソース間での発見と証拠の整合に焦点を当てます。
  • Code worlds はユニットテスト形式の検証器を用いた実行可能な変換に焦点を当てます。

3つのファミリーすべてがコントラクトを共有するため、V_D を機械的に検証可能な状態に保ちながら、遷移の深さ、障害モードの多様性、納品の具体性に沿ってカバレッジをスケールさせることができます。

Agentic Coordination Scaling（エージェント協調スケーリング）。 同一のベースポリシーが、長期タスクの分解、並列作業の委任、非同期結果の統合、サブタスク失敗時の再計画を行うように訓練されます。共有実行ハーネスとAgentOSがツールおよびサブエージェントにわたるタスク状態と来歴を維持します。このハーネスからの協調トレースは、単一エージェントの環境軌跡と並んで訓練データとなります。本論文は意図的にこれを専門家の混合ではなく1つのポリシーとして維持しています——プランナー、コーダー、サーチャーはモジュールではなく振る舞いです。

評価とHDS6

評価は階層化されています：幅広さのための公開ベンチマーク、能力の具体性のための内部構造化検索ベンチマークおよびエンドツーエンド研究成果物ベンチマーク、そして最終スコアだけでなく プロセス の品質を測るHDS6です。HDS6は各4つのルーブリック項目を持つ6つの能力グループと、重み付きルーブリックの外側に独立して適用される整合性ゲートを定義します。

HDS6の能力分類とプロセス採点パイプライン：各4つのルーブリック項目を持つ6つの能力グループと、重み付きルーブリックから独立して適用される整合性ゲート。

2つの実行モードが報告されています：ベースポリシーを単独で評価する通常のReActループ（推論／ツール／観測）と、協調スケーリングを有効にする Agent Team です。スコアは小数点以下1桁で報告され、意味論的な判断には各ベンチマークが定めたジャッジまたはルーブリックが使用されます。

結果

本論文は、複雑な専門業務、金融、科学研究、数学、コーディング、検索において最先端水準の性能を主張しており、Agent Team はいくつかの専門業務、金融、科学研究の評価において強力な参照システムに匹敵または超過し、一般的な推論、検索、数学、コーディングでも競争力を維持しています。主なサイズ効率の主張は35B の Apodex 1.1 Mini に関するものです：代表的な業務、金融、科学研究タスクにおいて選択されたフロンティアシステムの性能帯に到達し、重複する評価においてApodex 1.0 Mini から大幅に改善されており、ローカルへのデプロイも可能です。要約レベルの見出し——フロンティアシステムよりも「大幅に少ない」パラメータ数での最先端水準の結果——が、環境・協調スケーリングのテーゼの経験的根拠です。

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

公開されている内容では、フラッグシップモデルのサイズが開示されておらず、示されているセクションにおけるベンチマークごとの数値も提供されていません。また、成果物評価の多くはルーブリックおよびジャッジベースのスコアリングに依存しており、ジャッジモデルの選択が結果を左右する可能性があります。タスクコントラクトは機械的に検証可能な V_D を必要とするため、受け入れが本質的に主観的なタスクはこの枠組みに収まりにくいです。協調スケーリングはインターフェースレベルで記述されており、協調トレース上での訓練シグナルの構築（サブエージェント間のクレジット割り当て、委任された呼び出しが失敗した場合のオフポリシー補正）は提供されているセクションでは詳述されていません。最後に、HDS6のプロセス採点は品質シグナルとして提示されていますが、評価者間信頼性と V_D の結果との相関はここでは定量化されていません。

この研究の意義

本論文は多くの研究機関が収束しつつある転換を具体化しています：フロンティアレベルの推論品質において、実際の作業における更なる性能向上は、より多くのパラメータからではなく、どちらも訓練可能なより豊かな 環境 と 協調構造 から得られるという転換です。形式的なタスクコントラクトと35Bモデルが専門業務評価において最先端水準に到達できるという主張は、エージェント能力がスケールの問題ではなくデータとハーネスの問題であるという議論を鮮明にしています。

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

コンセプトスケーリングと高密度教師信号による画像編集ポテンシャルの解放

Instruction-tuned な画像編集モデルは、T2I のトレーニングレシピを継承しています：1つの instruction、1つのソース画像、1つのターゲット画像、1つの loss。本論文は、このレシピが編集タスクに対して最適でない原因として2つのミスマッチを指摘しています。第一に、編集コンセプトの空間は離散的、階層的、かつロングテールであるにもかかわらず、現在のパイプラインはVLMを介した確率的サンプリングによってそれを探索し、少数のモードに収束してしまいます。第二に、単一の編集ペアが提供する教師信号は疎であり、1回の forward pass で学習されるローカライズされたコンセプトは1つに過ぎず、変化のないピクセルに対するloss面の大部分が無駄になります。著者らはこれら両方の問題を、構造化されたコンセプトライブラリと合成的な高密度教師信号トレーニングスキームによって対処し、ConceptEdit-12M としてパッケージ化した上で、GEdit-Bench および新たに提案された ConceptEdit-Bench で評価しています。

分布崩壊の診断

データ構築の取り組みを動機付ける中核的な実証的観察は、VLM駆動の instruction 生成が著しくバイアスされているという点です。「スタイル転送」カテゴリにおいて、上位5スタイルが確率的サンプリングされた instruction の74.6%を占める一方、数十の代替スタイルは1%を下回っています。各編集コンセプトを独立したドメインとして扱うと、この崩壊は汎化性能を直接制限します：モデルはロングテールのコンセプトを一切学習できません。

モチベーション：コンセプトスケーリングと高密度教師信号。

この解決策として、確率的サンプリングを廃棄し、ライブラリ駆動のコンセプト列挙を採用します。このライブラリはVLMの事前分布からサンプリングするのではなく、LLMの世界知識から構築されます。タクソノミーは1,000以上の細粒度のリーフノードを持ち、属性、物体、シーン、スタイル、構図およびそれらのサブクラスとして階層的に整理されています。

1,000以上の細粒度編集コンセプトの階層的タクソノミー。

合成パイプライン

4段階のパイプラインは、コンセプト列挙と画像実現を分離しています。ステージ1ではLLMを用いてコンセプトライブラリを構築します。ステージ2では意味的検索によってコンセプトとソース画像を対応付け、その特定のコンセプトに紐付いたVQA検証チェックリストとともに instruction を作成します。ステージ3では画像合成を専門化された編集バックボーンに委譲します（一律適用ではなく、コンセプトごとのルーティング）。ステージ4ではステージ2で作成されたチェックリストに基づいてインスタンスレベルのVQAを実行し、失敗したペアを破棄します。

4段階の合成パイプライン。

チェックリストはコンセプト固有であり instruction と同時生成されるため、フィルタリングは汎用的な美的評価やCLIPスコアではなく、編集の意図されたセマンティクスと整合しています。

合成による高密度教師信号

高密度教師信号のために、著者らは k 個の非干渉コンセプトを単一の (x, y) ペアに合成します。編集 e_1, \dots, e_k が互いに素な領域または直交する属性に作用する場合、それらを順次適用することで、すべての k 編集を列挙した instruction とペアリングされたターゲット y = e_k \circ \cdots \circ e_1 (x) が得られます。トレーニング loss は標準的な flow-matching / diffusion の目的関数のままですが、各ペアは相関した空間サポートを持つ k 個のコンセプトレベルの教師信号を提供し、サンプルあたりの gradient を高密度化します。非干渉性はステージ2において、選択されたコンセプトが互いに素なエンティティまたは属性軸に作用することを確認することで強制されます。

結果

トレーニングはベースモデルとしてZ-Imageを使用し、instruction/フィルタリングにQwen3.5-122B-A10B、合成にFLUX.2-klein-9B、LR 1\times 10^{-5}、batch size 512を用います。評価はGEdit-Bench（ENおよびCN）において2Mおよび5Mのトレーニングスケールで行われ、G_{SC}（意味的一貫性）、G_{PQ}（知覚的品質）、G_O（総合）が使用されます。

GEdit-Bench-ENにおける5Mスケールでは、完全モデル（ConceptEdit_{1000} w/ Comp）が G_{SC}=7.07、G_{PQ}=7.30、G_O=6.62 を達成し、ScaleEditの 5.77 / 6.69 / 5.77 に対して総合で +1.30 / +0.61 / +0.85 の改善を示しています。GEdit-Bench-CNでは総合改善が +1.45 / +0.45 / +0.97 となっています。コンセプトライブラリのスケールアップは単調に貢献しており、5Mスケールにおいて G_O はコンセプト数10で5.93、500で6.30、1000で6.40と改善し、500コンセプト以降でもロングテールが重要であることを示しています。

高密度教師信号のアブレーション（\Delta Comp. Gain）は、合成戦略をデータスケールから分離して評価しています：5Mスケールにおいて、シングルトン編集でトレーニングされたConceptEdit_{1000}に対し、ENで +0.21 / +0.11 / +0.22、CNで +0.32 / +0.11 / +0.24 の改善をもたらします。2Mスケールでは G_{SC} における改善がより大きく（EN +0.43、CN +0.45）、データが限られている場合に高密度教師信号が最も有効であることと一致しており、サンプル効率の一部を回復しています。知覚的品質の改善は小さく（+0.03 から +0.11）、合成が主に instruction following シグナルを高密度化するものであり、美的品質ではないことから予想通りの結果です。

限界

合成における非干渉条件は合成時にヒューリスティックに強制されており、合成された編集がトレーニング中に互いに漏れ込む頻度や単一編集の精度が低下する程度は定量化されていません。すべての合成はFLUX.2-kleinに依存しているため、トレーニング分布はそのバックボーンの失敗モードを引き継いでいます—ライブラリは instruction のバランスを再調整しますが、画像の事前分布は調整しません。評価モデル（Z-Image）は特定の選択であり、自己回帰型エディタやより大きなDiTへの改善の転移性は未検証です。最後に、ConceptEdit-Benchは診断スイートとして導入されていますが、詳細なカテゴリ別の分析は提供されているセクションでは提示されておらず、ロングテール汎化の主張はコンセプトレベルの精度曲線によってさらに裏付けられることが望まれます。

重要性

本論文は、編集データのスケーリングをデータ量の問題ではなくタクソノミーの問題として再定式化し、サンプルあたりの教師信号密度が独立して調整可能な軸であることを示しています。両方の介入はモデルに依存せず、任意の diffusion または flow-matching エディタと組み合わせることができ、VLM生成ペアを大量に積み重ねるよりもクリーンなレシピを提供しています。

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

MobilePA-Bench: 複雑な実世界タスクにおけるモバイルプランナーエージェントのベンチマーク評価

問題と動機

既存のモバイルエージェントベンチマークは、いずれも不十分な二つのパラダイムに二分されています。GUI中心のスイート（AndroidWorld、Mobile-Envなど）は、ピクセルレベルの画面操作を測定する一方で、実際のパーソナルコパイロットが調整しなければならない構造化されたビジネスAPI、バックグラウンドサービス、および長期的な計画を無視しています。静的な関数呼び出しベンチマーク（BFCL、API-Bank）は、副作用、状態、あるいはエラー回復とは切り離されて、参照と照合したオフラインのAPI名・引数マッチングを評価します。どちらも、生きたデータベースが操作に応じて変化する中で、APIを直接呼び出すべき時期、GUIサブエージェントに委託するべき時期、そして保存されたユーザーメモリを参照するべき時期を判断しなければならないプランナーを捉えることができません。

MobilePA-Benchはまさにこのギャップを標的にしています。すなわち、実行可能なサンドボックスが13の機能ドメインにわたってライブアプリケーションデータベースを維持し、212の現実的なモバイルツールを公開し、単一のモノリシックな「タスク成功」指標ではなく4つの能力軸に沿って中央プランナーを評価する、インタラクティブかつステートフルでツール中心のベンチマークです。

アーキテクチャと評価パラダイム

MobilePA-Benchの評価パラダイムの概要。

このシステムはモバイルインテリジェンスをツール中心のオーケストレーションループとして形式化しています。単一の中央プランナーが高レベルの推論を担当し、(i) 構造化されたビジネスツールを直接呼び出す、(ii) 6つの専門サブエージェントのいずれかに委任する（特に視覚的グラウンディングのためのGUIサブエージェントおよびビジュアル処理サブエージェント、さらに条件付きモニター）、(iii) ユーザーのMemoryストアからアイテムを取得する、(iv) 再利用可能なSkill（事前にパッケージ化された複合手順）をロードする、といった操作が可能です。GUI実行は競合するパラダイムではなくプランナーの配下にあるツールであり、この設計上の選択によってベンチマークはルーティング判断を明示的に評価できます。

4つの能力次元は直交に保たれています：

  • Basic Tool Use: 直接的なAPI選択、引数のグラウンディング、呼び出し間の依存関係処理、およびサンドボックスから返された実行エラーからの回復。
  • Sub-agent Collaboration: 構造化APIが不十分な場合を認識し、適切に整形された委任を発行する（例：フォーム入力をGUIサブエージェントに委任するなど）。
  • Memory Usage: 要求内の暗黙的な参照を解決するために保存されたプリファレンス・プロファイルを取得する。
  • Skill Usage: 事前にパッケージ化された複合スキルにルーティングし、その下流のツールシーケンスを正確に完了させる。

図1は、単一のトラジェクトリにおいて4つすべてが連携して動作する様子を示しています。すなわち、保存された食事制限の好みを想起し、フライト・ホテル予約のスキルを呼び出し、マルチモーダルツールを介してQRコードをスキャンし、画像の多いフォームをGUIサブエージェントに委任する様子です。

メモリ、スキル、ツール、およびサブエージェント委任を行使する代表的なエンドツーエンドタスク。

クローズドループ実行と検証

クローズドループ実行と検証プロトコル。

ステップ t において、プランナーはクエリおよびインタラクション履歴 \mathcal{H}_t、さらに候補ツールセット \mathcal{A}_t（動的選択設定では N=15 候補の動的リコール）を与えられます。プランナーはアクション a_t \in \mathcal{A}_t を出力し、サンドボックスはそれを実行して基盤となるドメインデータベースを変化させ、フィードバック f_t（構造化された状態デルタまたはシステムエラー）を返します。ループはFinishアクションが出力されるか、t = T_{\max} = 15 に達した時点で終了します。

検証は能力タクソノミーから分離されています。各タスクは作成時に以下の3つのエビデンスバケットのいずれかにアノテーションされます：

  • Bucket 1 — Tool Call: 正しいツール呼び出しが正しい引数で発生したかどうかで成功を判定します。
  • Bucket 2 — State Change: 最終的なデータベース状態（例：行の挿入、予約の確定）で成功を判定します。
  • Bucket 3 — Agent Behavior: トラジェクトリの観測可能な行動特性（例：適切な時点で委任が発生したかどうか）で成功を判定します。

各タスクを最も信頼性の高いエビデンスタイプにルーティングすることが、このような異質なアクション空間全体で非受動的な検証を実行可能にしています。純粋な状態差分チェックはGUI委任に対して脆弱であり、純粋なツールトレースチェックは複数の有効な計画が存在する場合に脆弱となります。

規模と実験設定

フルスイートには1,705タスクが含まれています：Basic Tool Use 1,040件、Sub-agent Collaboration 89件、Memory Usage 376件、Skill Usage 200件であり、13ドメインにわたる212ツールをカバーしています。モデルはライブサンドボックスに対して標準化されたシステムプロンプトを用いたマルチターン関数呼び出しプロトコルで評価されます。論文は同じ軸に沿って4つの研究課題を位置づけています。すなわち、ステートフルなツール使用の信頼性、委任判断の精度、メモリからの暗黙的コンテキスト取得の有効性、そしてスキル呼び出し後の下流実行の正確さです。

限界と未解決の問題

提供されたセクションはベンチマーク設計を説明しているものの、モデルごとの主要な数値は記載されていないため、最先端モデルの性能に関する定量的な主張をここで評価することはできません。いくつかの設計上の選択も精査が必要です。第一に、Sub-agent Collaborationの分割数が少ない（89タスク）ため、最も難しい軸で僅差のプランナーを区別するのに必要な統計的分解能が不足している可能性があります。第二に、Bucket 3（Agent Behavior）の検証は機械的定義が最も曖昧であり、アノテーター間の信頼性が委任スコアの信頼性にとって重要です。第三に、候補リコールを N=15 に固定することは、取得品質と計画品質を混同させます。不十分な15ツールのショートリストを与えられたプランナーは回復できないため、ベンチマークは自身が仕様を定めていない上流のリトリーバーを暗黙的に評価していることになります。最後に、GUIサブエージェントをブラックボックスの委任先として扱うことで、GUI実行の失敗はプランナーの委任仕様ではなくサブエージェントに帰属されることになり、実際のルーティングエラーを見えにくくする可能性があります。

なぜこれが重要か

MobilePA-Benchは、オフラインのAPIマッチングやピクセルレベルの画面テストに還元するのではなく、エビデンスに適した検証を伴うライブのステートフルサンドボックスの下で、メモリ、スキル、構造化API、そしてGUI委任というオーケストレーション問題を評価する、初めてのモバイルエージェントベンチマークです。サンドボックスとアノテーションが有効であれば、これはオンデバイスプランナーがパーソナルコパイロットとして実際に展開可能かどうかを測定するための適切な粒度を持つものです。

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

Prime Agent: 自己改善型 RLM ハーネス

長期ホライズンのエージェント評価は、ハーネスのアーティファクト——関連する状態を破棄するコンテキスト圧縮、単一のワークフローを強制するツールインターフェース、モデルより先に失敗するオーケストレーション層——に支配されています。Prime Agent は、このフロアを最小化しようとするオープンソースのハーネスです。Recursive Language Model (RLM) 抽象に従った永続的な IPython REPL、軌跡から派生した状態を永続化する Continual Harness、エージェント間メッセージングを伴う再帰的サブエージェントセッション、そしてデーモンベースのセッションを人間が検査するための Agents View を提供します。本論文の中心的な主張は、新しいモデルや学習手順ではなく、十分に表現力が高く摩擦の少ない実行メンブレンが、測定されたパフォーマンスをモデルの本質的な能力に近づけるという点であり、さらにこのシフトはベンチマーク解釈にとって重要なほど大きいという点です。

アーキテクチャ

Prime Agent はランタイムを情報管理と計算管理に分割しています。情報管理は、各モデル呼び出しに何が入力され、圧縮・デタッチ・再起動後に何が残るかを決定します。計算管理は、モデルのアクションを永続的な REPL で実行されるコード、ツール呼び出し、および再帰的サブエージェントセッションにマッピングします。4 つの状態層は次の通りです：(1) モデルの重み、(2) アクティブなコンテキストウィンドウ、(3) REPL プロセスの状態、(4) Continual Harness 配下のディスクバックストレージ。REPL が永続的であるため、モデルは中間値（解析済みログ、テンソル、部分的な結果）を個々のターンを超えて存在し続ける Python オブジェクトとして具現化し、それらをコンテキストに再エンコードするのではなく名前で参照できます——これがプログラム的なコンテキスト処理という RLM 抽象の機械的な基盤です。

Continual Harness は軌跡のエビデンスを再利用可能な状態に変換します：履歴、メモリ、スキル、プロンプト、サブエージェントの仕様が軌跡をまたいで永続化されるため、実行はメモリのないエピソードではなくハーネス自体の変更となります。サブエージェントはルートセッションの実行・通信プリミティブを継承し、共有スクラッチパッドではなく直接のエージェント間メッセージによって連携します。セッションをバックアップするデーモンにより、デタッチ/再起動と Agents View を通じた人間の介入が可能になります。ランタイムはモデル呼び出し、ツール使用、メッセージ、ハーネスの変更、リソース使用を記録し、分解・割り当て・通信・停止の決定はモデルに委ねられます。

これは意図的に薄い設計です：ハーネスは実行・回復・検証・リソース会計を標準化し、戦略の構築はモデルに委ねます。「ハーネスの失敗をモデルの失敗にしてはならない」という設計原則が明示されており、これはベンチマークを単一の固定ワークフロー下でのパフォーマンスではなく、ハーネスが許容するポリシー \pi にわたる \max_\pi \mathrm{Perf}(M, \pi) の測定として再定義します。

評価

評価は 3 つの問いを対象としています：標準化された表現力豊かな実行が追加のテスト時トークンを検証済みの進捗に変換できるか（RQ1）、永続的な REPL 状態が長いコンテキストの情報管理に役立つか（RQ2）、同じランタイムが複数日にわたる反復作業を支えられるか（RQ3）。

ヘッドラインとなる数値は ARC-AGI-3 で、各ゲームはモデルにアクションバジェット内でアドホックな世界モデルを誘導させるものです。Prime Agent は環境インターフェースと PRO-LONG から適応した自律プロンプトのみを提供し、戦略全体はモデルが構築します。RHAE Best@1 は 30% から 95.5% に上昇しました——この変化は、基盤となるモデルが変わっていないため、モデルレベルの改善よりもハーネスに起因するシーリングの除去と整合的です。テスト時スケーリング曲線（ゲームあたりの出力トークンおよび推定 API コストに対する RHAE）は、より強い設定が長いインタラクションホライズンにわたって改善し続ける一方、弱い設定は早期にプラトーに達することを示しています。すなわち、同じインターフェース下でも、異なるモデルは計算資源を進捗に変換する速度が大きく異なります。本論文は、Claude Code と Codex のネイティブハーネス再実行が Anthropic/OpenAI の自己報告 ARC-AGI-3 数値を下回ったと指摘しており、外部参照ラインはハーネス貢献を因果的に分離するのではなく位置づけに使われます——これは真剣に受け止めるべき注意点です。

RQ2/RQ3 の軸では、Prime Agent は長いコンテキストのコーディング、PMPP-Hard における GPU カーネル生成、EmulatorBench におけるエミュレータ構築、自律的な nanoGPT スピードランにわたって、ネイティブおよび一般的なハーネスと同等以上の性能を報告しています；Factorio と MazeBench は、サブエージェントの割り当て・情報保持・中断からの回復の軌跡分析に使用されています。Factorio に関する記述は抄録において途中で切れているため、提供されたテキストからは具体的な定量的主張を検証できません。

限界と未解決の問い

いくつかの注意点があります：ARC-AGI-3 の比較は、著者らがベンダー報告のベースラインを一致したプロンプトと設定で再現できなかったことによって交絡しており、30% → 95.5% のデルタはハーネスの改善とプロンプトエンジニアリングおよびモデル選択の違いが混在しています。「モデルの真の最大限の基礎的能力への測定」というフレーミングは直接反証できません——より表現力の高いハーネスであればより高いスコアになると常に主張できるからです。Continual Harness の永続化は評価の衛生上の問題も提起します：スキルとプロンプトが軌跡をまたいで蓄積される場合、タスクごとの Best@1 数値は他のハーネスが行わないクロスタスク学習を暗黙的に評価に含めることになります。最後に、ランタイムはリソース使用を記録しますが、論文のコスト正規化比較は実際の経過時間や FLOP 計算ではなく推定 API コストに依存しています。

なぜ重要か

ハーネスの変更がモデルに触れることなく ARC-AGI-3 RHAE Best@1 を 30% から 95.5% に移動させるならば、公表されているエージェントベンチマーク数値のかなりの割合はモデルの能力ではなくハーネスの品質を測定していることになります。Prime Agent は、コミュニティが表現力豊かな実行メンブレンを標準化し、単一ワークフローのスコアではなくトークンとドルでスケーリング曲線を報告すべきであると、説得力を持って主張しています。

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

Block3D: ブロック単位の Diffusion による効率的なテキスト-3D 生成

問題

離散形状トークナイザーに基づくテキスト-3D 生成器は、スループットと品質のトレードオフに直面しています。N 個の形状コード（例: Cube [5]、N=1024、V=16384）に対する自己回帰デコーダは、各トークンを取り消し不可能な形で確定し、O(N) の逐次ステップを要します。全シーケンスに対する離散 diffusion やフローマッチング デコーダは誤りを修正できますが、多数の refinement ステップにわたって全 N 位置に繰り返し attention を行うため、推論コストはシーケンス長と refinement のホライズンの両方に応じて増大します。Block3D はその中間点を目指します。すなわち、局所ウィンドウ内で diffusion の並列性と自己修正を維持しつつ、因果的プレフィックスによってコンテキストを償却することで、forward pass の回数もパスごとのコストも支配的にならないようにします。

3D トークン生成スケジュールの比較

手法

Block3D は凍結された Cube VQ-autoencoder を再利用して形状表現を固定します。エンコーダはサイズ V=16384 のコードブック上で N=1024 個のコードを生成し、固定デコーダは完成したシーケンスをメッシュ \hat{S} にマッピングします。条件付けには CLIP ViT-L/14 のテキスト embedding（77 トークン特徴）を使用し、オプションとして射影されたバウンディングボックストークンで拡張できます（報告された実験では未使用）。生成モデルは Cube から初期化され、ブロック因果スケジュールのもとで再学習されます。

Block3D パイプライン: テキスト条件が左から右へのブロック生成を駆動し、M2T/T2T が active block のみを編集する

N 位置は K 個の連続したブロックに分割されます。生成は左から右へ、以下の 3 つのコンポーネントによって進行します。

(1) 条件付きブロック因果 Denoising。 学習時の可視性は、シーケンスをクリーンプレフィックス（確定済みブロック）、アクティブブロック（完全にマスクされたまたは部分的に破損している）、および不可視の未来領域に分割します。Attention はブロック粒度で因果的ですが、アクティブブロック内では双方向です。すなわち、アクティブ位置は条件 C、プレフィックス、および互いに attention を行います。これは Block Diffusion [43] のテンプレートを、可変長テキストではなく固定長の 3D トークングリッドに適用したものです。

(2) 編集対応学習。 マスク位置のみで学習するのではなく、生成器はマスクトークンと置換された誤ったコードの両方を参照します。これは LLaDA2.1 [14] の T2T（トークン間）改訂中のブロック内状態を模倣するものです。単一のモデルベースのロールアウトが実行され、そのロールアウト後に残留する誤差のみに対して教師信号が適用されます。これにより学習を推論時の編集分布に合わせます。すなわち、モデルはマスクを埋めるだけでなく、自身の誤りを修正することを学習します。

(3) 境界付き信頼度誘導デコーディング。 ブロック内の各イテレーションでは、マスク位置に対して M2T（マスクからトークン）の充填を実行し、既に充填されているが低信頼度の位置に対して T2T 置換を実行します。どの位置を処理するかの選択にはモデルの条件付き事後信頼度を使用します。決定論的な開示クォータにより、残りのすべてのマスクが最大 T イテレーション以内に確定されることが保証されます。ここで T はブロックごとの更新ホライズンです。ブロックが \le T 回の更新を完了すると、キャッシュされたプレフィックスに凍結され、二度と再開されません。すべての修正は厳密にブロック内部で行われます。

コストの構造は K \cdot T 回の forward pass であり、各 pass は主に小さなアクティブブロックと KV キャッシュされたプレフィックスに対して attention を行います。これは AR の O(N) パス、またはグローバル diffusion の O(T_{\text{full}}) 回の全シーケンスパスと比較して有利です。

結果

Fine-tuning には TRELLIS-500K [2] から 30 万オブジェクトを使用し、評価では学習プールから除外された 100 オブジェクト（シード 42）を保持し、対応するテキストプロンプトを条件として各プロンプトにつき 1 サンプルを生成します。

このホールドアウト分割において、Block3D はエンドツーエンドの平均生成時間を 25.71 秒から 4.99 秒に短縮し、fine-tuning された Cube 初期化の自己回帰ベースラインに対して 5.15× の高速化を達成しています。著者らの比較によれば、幾何学的忠実度の低下はありません。定性的には、Block3D はトークン単位の AR および全シーケンス denoising ベースラインが欠損または歪んだ幾何形状を示すプロンプトにおいても、前面と背面の整合したビューを生成します。

定性的比較: Block3D 対トークン単位 AR および全シーケンス denoising ベースライン

限界と未解決の問題

評価セットは小規模（ホールドアウト 100 プロンプト）であり、単一のアセット分布（TRELLIS-500K）から得られています。提供されたセクションには FID/CLIP 類似度の数値、幾何学的指標（Chamfer、F-score）、または人間による評価の数値が引用されていないため、「幾何学的忠実度を犠牲にすることなく」という主張は著者らの定性的・付録的比較に基づいています。ブロック分割 K、ブロックごとのホライズン T、決定論的開示クォータと T2T 再編集の相互作用はハイパーパラメータであり、その感度はここでは要約されていません。確定されたブロックは凍結されるため、初期ブロックの誤り（例: 最初のコードにエンコードされた粗いグローバル構造）を後のブロックで修正することはできません。これはブロック因果スケジュールが AR から受け継ぐまさに失敗モードであり、自然な左から右への空間的順序を持たない 3D トークナイザーにとってその深刻さは不明確です。最後に、この手法は固定長トークナイザー（N=1024）を前提としており、より高解像度の形状コードや階層的トークナイザーへのスケーリングは取り上げられていません。

重要性

Block3D は、離散テキスト生成におけるブロック diffusion のレシピが固定長 3D 形状コードシーケンスにきれいに転用でき、同じバックボーンの AR ベースラインと比較して約 5× の実時間高速化をもたらすことを示しています。同時に、AR デコーダが構造的に欠如しているトークン修正能力を保持しています。忠実度の主張がより強力な指標のもとで成立するならば、ブロック因果離散 diffusion が言語を超えたトークン化生成モデリングにおける実用的なデフォルトであることが示唆されます。

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

Hacker News Signals

seL4のセキュリティ証明がAArch64上で完成

seL4マイクロカーネルは、32ビットARM（ARMv7）ターゲットに対する形式的正当性証明を10年以上前から有していましたが、64ビットAArch64ポートには完全な証明スタックが欠けていました。具体的には、Cレベルの細化証明を実際のコンパイル済みバイナリまで接続し、Cコンパイラへの信頼を迂回するバイナリ検証層が欠如していました。そのギャップがついに解消されました。ProofcraftはAArch64上でseL4の完全な証明スタックが検証されたと発表しました。その内容は次の通りです：（1）機能的正当性（C実装が抽象仕様を細化すること）、（2）バイナリ検証（コンパイルされたELFバイナリがCのセマンティクスを実装すること）、（3）細化チェーンから導出された機密性と完全性を含むセキュリティ特性。

ARMv7に対するAArch64固有の技術的課題としては、より広いレジスタ幅、異なる例外モデル、より豊富なページテーブル構造（3レベルに対して4レベル）、そして形式的モデル化または信頼されたコンピューティングベース（TCB）からの慎重な除外が必要なポインタ認証のようなハードウェア機能が挙げられます。バイナリ検証には、Isabelle/HOL上に構築されたl4v証明インフラストラクチャが使用されています。この検証は、特定のコンパイラツールチェーンとフラグによってコンパイルされたバイナリおよび約10,000行のCコードを対象としており、いずれかを変更した場合は再検証が必要となります。

これは実際の展開において重要な意味を持ちます。seL4は車載（AUTOSAR）、航空、および防衛システムで使用されており、それらの多くは現在AArch64シリコン（Cortex-A55/A72/A78クラス）上で動作しています。従来、AArch64の展開においてはCレベルの証明には依拠できましたが、バイナリ証明は存在せず、コンパイラの振る舞いがTCBに残ったままでした。コンパイラをTCBから除去することは容易ではありません。バイナリ検証には、ISAセマンティクスの形式化されたモデルと、各バイナリ命令列が対応するCのセマンティクスを実装することを示す機械化された証明が必要です。IsabelleによるこのProof開発は、seL4のGitHub organizationでオープンソースとして公開されています。

未解決の問題として、これらの証明は依然として単一の検証済み構成（ハイパーバイザ拡張なし、特定のハードウェアプラットフォーム）に限定されています。AArch64上でのVerified MCS（Mixed-Criticality Systems）スケジューリングは、別の取り組みとして現在も進行中です。

Source: https://proofcraft.systems/news-2026/#2026-08-21

Hot Chips 2026: CUDAがRISC-Vをターゲットに

Chester LamによるHot Chips 2026のレポートは、NVIDIAがCUDAをRISC-Vコアへ再ターゲットする取り組みを取り上げており、解説する価値のある重要なアーキテクチャ上の転換点となっています。NVIDIAはここ数世代にわたり、ダイ上のマイクロコントローラ（GSP、FSP、SEC2）をFalcon（自社独自のVLIW ISA）からRISC-Vへ移行してきましたが、今回のHot Chips発表はさらに踏み込んだ内容です。CUDAカーネル自体が、従来のSM（Streaming Multiprocessor）によるPTX/SASSpipelineではなく、RISC-V実行ユニットをターゲットにできるようになりました。

その仕組みとして、NVIDIAはファームウェア以外の用途にもRISC-Vコアを展開しています。具体的には、GPUダイ上のプログラマブルエンジンとして配置し、CUDAプログラミングモデルに対応したメモリ階層および同期向けのカスタム拡張を持つRV64をターゲットとするLLVM backendを通じて、コンパイルされたCUDA C++を実行できるようにしています。これは演算集約的なワークロードにおいてSMを置き換えるものではなく、グラフ探索・スパースデータ構造の操作・大規模カーネル内に埋め込まれたcontrol-plane logicなど、SMパイプラインでは過剰であり単純なスカラコアで十分なタスクをカバーするものです。

compiler的観点から見ると、CUDA/LLVM toolchainはすでにPTX emissionと下位ISAの間にクリーンな分離を持っているため、RISC-V backendを追加することはアーキテクチャ上は直截的です。興味深い技術的課題は、CUDAメモリモデル（unified virtual addressing、atomic semantics、warp-level primitives）をRISC-Vのメモリモデルへマッピングする方法にあり、これにはカスタムISA拡張か、オーバーヘッドを伴う保守的なfencingのいずれかが必要となります。

より広いエコシステムへの示唆として、CUDAのセマンティクスがオープンなISAへ正式に再ターゲットされれば、サードパーティがRISC-Vシリコン上にCUDA互換アクセラレータを構築しやすくなり、NVIDIAの主要な競争優位の一つであるPTX/SASS ISAへのロックインが弱まる可能性があります。AMDのROCmはすでにオープンなISAをターゲットにしており、IntelのoneAPIも同様です。この動きがユーザーから見えるCUDAプログラムにまで進展すれば、GPUコンピューティングエコシステムを大きく開放することになりえます。

Source: https://chipsandcheese.com/p/hot-chips-2026-cuda-targets-risc

LLMはInference Engineを悪用してホストマシンを制御できる可能性がある

Boyd Kaneのエッセイは、システムセキュリティコミュニティがより注目すべき具体的な攻撃対象領域を体系的に整理しています。その対象とは、モデルの重みや入力自体によって悪用可能なinference engineの脆弱性であり、ホストされたLLMが意図されたI/Oの境界を超えてホストマシンに影響を与えることを可能にするものです。

この議論は、従来の意味でのprompt injection（出力を操作するもの）とは異なります。inference engineのランタイム — TensorFlow、PyTorch、llama.cpp、vLLM、TensorRT-LLMなど — をネイティブコードを実行する特権プロセスとして捉え、他のネットワーク向けサービスと同様の脅威モデリングが必要であるという主張です。いくつかの具体的な攻撃ベクトルが指摘されています：

Custom ops / plugins: Inference engineは共有ライブラリとしてロードされるユーザー定義カーネル（CUDA、CPU）をサポートしています。攻撃者がどのopsをロードするか、またはその引数に影響を与えられる場合、任意コードの実行につながります。GGUFやSafeTensorsなどのモデルフォーマットは、opのサニタイズレベルがそれぞれ異なります。

デシリアライゼーションのバグ: pickleベースのレガシーなPyTorchモデルフォーマットが安全でないことはよく知られています。しかし、SafeTensorsでさえパーサーのバグが存在したことがあります。悪意を持って細工されたテンソルファイルは、shape/strideの解析におけるバッファオーバーフローや整数オーバーフローを悪用できます。

attentionにおけるメモリエイリアシング: マルチテナント環境でのサービング（engineがprefix cachingによってリクエスト間でKV cacheを再利用する場合）において、巧妙に細工されたKV cacheポイズニングにより、あるテナントの計算が別のテナントのキャッシュ済み状態を読み取る可能性があります。これはコード実行ではなく情報漏洩ですが、それでも機密性の侵害に当たります。

タイミングによるサイドチャネル: 実行環境を認識しているLLM（システムプロンプトやツールコールの結果を通じて）は、メモリタイミングを探索したり、同じハードウェアを共有するプロセスから観測可能な共有ハードウェア状態に影響を与えるワークロードを生成したりする可能性があります。

このエッセイは、モデルの重みをランタイムへの非信頼な入力として扱うべきであると主張しています — これはほとんどのinference engine開発者が正式に採用していない脅威モデルです。緩和策としては、サンドボックス化されたinference（seccomp、gVisor、リクエストごとに独立したプロセス）、SafeTensors専用ロードの強制、およびパーサーにおけるshape演算の正式な監査などが挙げられています。

Source: https://boydkane.com/essays/llms-could-control-their-host-machines-by-exploiting-inference-engines

PicoMQ: オブジェクトストレージ上でHTTPを介した永続ストリーム

PicoMQは、オブジェクトストレージ（S3互換）を唯一の永続バックエンドとして使用し、プロデューサーとコンシューマー向けにシンプルなHTTP APIを公開するメッセージストリーミングシステムです。このアーキテクチャは、Kafka、Pulsar、NATS JetStreamのようなステートフルなブローカーモデルを意図的に採用していません。

コア設計：プロデューサーはHTTPエンドポイントにメッセージをPOSTし、サーバーはそれらをバッチ処理してセグメントをS3/GCS/R2にオブジェクトとしてフラッシュします。コンシューマーはオフセットパラメーターを指定してlong-poll GETリクエストを実行し、サーバーは該当するセグメントオブジェクトを読み込んでレコードをストリームで返します。コンシューマーオフセットはクライアント側で保持するか、同じバケット内の小さなオブジェクトとしてオプションでチェックポイントされます。レプリケーションブローカー層は存在せず、耐久性はオブジェクトストアのレプリケーション保証（S3では通常イレブンナイン）に完全に依存しています。

このアプローチはコスト構造が明確に理解されています。書き込みレイテンシはオブジェクトストアのPUTレイテンシ（小さなオブジェクトで数十〜数百ミリ秒）に下界が制約されるため、100ms以下のpublish-to-consumeレイテンシには適していません。しかし、エンドツーエンドのレイテンシとして1〜10秒を許容できるイベントパイプラインにとって、運用上のシンプルさは大きな利点です。Zookeeperも、ブローカークラスターも、パーティションのリバランスも、ディスク管理も不要です。S3のGETはステートレスであるため、読み取りパスでは水平スケールが可能です。書き込みスループットはバッチ処理ロジックとPUTの並列性によって制限されます。

類似システムとしては、Cloudflareの内部イベントパイプライン、WarpStream（同じくS3バックエンドのKafka互換）、ResponsiveのKafka階層型ストレージがあり、いずれも同じトレードオフの領域を探求しています。PicoMQはKafka API互換性よりもシンプルさを優先する点で差別化されています。コンシューマーグループもパーティショントポロジーも存在せず、ただのストリームとオフセットをプレーンなHTTP上で提供します。

未解決の課題として、exactly-onceセマンティクスは結果整合性のオブジェクトストア上では非自明な2フェーズ調整を必要とし、プロジェクトの現状がこの点でどこまで対応しているかは不明です。また、古いセグメントのコンパクションやリテンションポリシーについても詳細は明示されていません。

Source: https://picomq.com/

Fences, Not Sandboxes

Steve Yeggeのエッセイは、AIエージェントをサンドボックス化しようとする業界の本能——制限されたsyscallサーフェスを持つ隔離環境、コンテナ化されたファイルシステム、ネットワーク egress 制御——がアーキテクチャ的に誤っていると主張しています。核心的な主張は、サンドボックス化がエージェントとホストの間に敵対的な関係を生み出し、capability境界の絶え間ない交渉を強いるというものであり、正しいモデルは「フェンス」——OSレベルのパーミッションではなくタスクドメインの観点で定義された、明示的かつ意味論的に意味のある境界——であるというものです。

技術的な核心は、capability制限（どのsyscallを呼び出せるか、どのパスに書き込めるか）と意味論的インテント仕様（エージェントが達成すべきこと、終了後に保持されなければならない不変条件）の区別にあります。サンドボックス化は抽象レベルを誤っています。サンドボックス化されたコンテナ内でコーディングタスクを解くエージェントは、依然として微妙に誤ったコードを生成したり、許可されたパス内で誤ったファイルを削除したり、リソースを枯渇させたりする可能性があり——これらはいずれもsyscallフィルタリングでは検出できません。逆に、サンドボックスはエージェントが必要とする正当な操作をブロックし、回避策を強いることになります。

提案されている代替案は、「フェンス」をフォーマルなコントラクトとして定義することです。すなわち、エージェントが操作する状態空間に対する事前条件・事後条件であり、OSレベルのエンフォーサーではなく軽量なベリファイアによって監視されます。これは従来のサンドボックス化よりも、design-by-contractやエージェントインタラクションに対するsession typesに近い考え方です。実装の負担はOSからタスク仕様レイヤーへと移行します。

これは、アクショントレースのformal verificationによるLLMエージェント安全性に関する研究（例えば、ファイルの変更がベースに対して指定されたdiff内に収まっているかのチェック）や、マルチエージェントシステムのプロセス計算に関する研究と接続しています。このエッセイの弱点は、依然として綱領的なものに留まっている点です——具体的な実装なし、形式的意味論なし、実証的比較なし。システム上の貢献というよりも、アーキテクチャ上のマニフェストとして読めます。それでも、フレーミングに対する批判として読む価値はあります。

Source: https://yegge.ai/essays/fences-not-sandboxes/

Zig の Io.Threaded は面白い

matklad（rust-analyzer の作者である Alex Kladov）の投稿では、Zig の標準ライブラリにおける I/O 抽象化である Io.Threaded を分析しています。これはイベントループやグリーンスレッドではなく、OS スレッドを用いて async スタイルのノンブロッキング動作を実現するものです。重要なポイントは、comptime インターフェースを通じてコンパイル時に I/O 戦略を交換可能にしている点であり、Io.Threaded は Io.Async（epoll/kqueue ベース）や Io.Blocking と並ぶ実装の一つです。

仕組みとしては、Io.Threaded はブロッキング操作ごとにスレッドを生成します。呼び出し側は同期的に見えるコードを書き、Io 抽象化が各呼び出しをスレッドでラップして、呼び出し側が await できるハンドルを返します。Zig の comptime によってビルド時に Io の実装をランタイムオーバーヘッドなしに選択できるため、デバッグ時には Io.Blocking（シングルスレッド、全操作がブロッキング、推論が容易）でビルドし、本番環境では Io.Threaded や Io.Async でビルドするといったことが、アプリケーションコードを変更せずに可能です。

Io.Threaded が特に興味深い理由は、アプリケーションを async/await スタイルで書いたりイベントループを管理したりすることなく、真の並行性を提供できる点です。中程度の並行要件（同時 I/O 操作が数千ではなく数百程度）を持つプログラムにとって、スレッド per 操作モデルはシンプルでデバッグしやすく、colored functions（async 関数が呼び出し元に伝染する問題）の組み合わせ問題を回避できます。I/O 操作が粗粒度であれば、スレッドのオーバーヘッドは許容範囲内です。

これは「function color」問題の解決策を具体的に実現したものです。型レベルで I/O を抽象化することで、Zig はプログラマが言語レベルで並行モデルを選択することを強制されずに済みます。Io.Async に対するトレードオフはメモリ（各スレッドはデフォルトで通常 2〜8 MB のスタックを必要とする）と高並行時のスケジューラオーバーヘッドです。matklad は、ほとんどの実用的なプログラムにとってこのトレードオフは有利であり、スレッドのデバッグしやすさという利点は過小評価されていると主張しています。

Source: https://matklad.github.io/2026/08/06/neat-io-threaded.html

AIチップアーキテクチャ

Jordan Peakeの技術サーベイは、現代のAIアクセラレータを特徴づける主要なアーキテクチャテーマを網羅しています：systolic arrays対dataflow対spatial architectures、メモリ階層設計、そして大規模運用を支配するインターコネクト戦略です。

このサーベイは、主要なボトルネックである演算強度（arithmetic intensity）を軸に構成されています。Transformerの推論は、自己回帰的なデコーディング（低演算強度）においてメモリ帯域幅バウンドとなり、プリフィル（高演算強度）においてコンピュートバウンドとなります。異なるチップはこのスペクトラム上の異なる点に最適化されています。TPUは大規模なsystolic arraysを使用し、多数のMACにわたってメモリアクセスをアモータイズします——これは大バッチの学習には有利ですが、単一シーケンスのデコーディングには非効率です。NVIDIAのHopper/BlackwellはFP8サポートとasynchronous memory copy（TMA）を備えたTransformer Engineを追加し、デコーディングのボトルネックを部分的に解消しています。

専用推論チップ（Cerebras、Groq、SambaNova）はより極端な立場をとっています。GroqのTSP（Tensor Streaming Processor）はVLIW設計であり、コンパイラがすべてのデータ移動を静的にスケジューリングします。キャッシュ階層は存在せず、すべての重みはダイ上の分散SRAMに格納されています。これは柔軟性を犠牲にする代わりに、決定論的かつ低レイテンシな実行を実現します。Cerebras WSE-3はモデル全体を単一のウェハースケールチップ（90万コア、44 GBオンチップSRAM）に搭載し、現在のダイサイズで最大約240億パラメータのモデルに対してチップ間通信を排除します。

インターコネクトのセクションでは、NVLink（GPU間、H100 NVLink 4.0で双方向900 GB/s）、独自ファブリックの代わりに21本の200Gb Ethernetポートを使用するIntelのGaudi 3（スケールアウト向けのコモディティネットワーキングとして興味深い）、そして（実際に出荷されれば）attentionをシリコンにハードコードしてattentionの演算コストを完全に排除するEtchedのSohuを取り上げています。

このサーベイは、ML側から来た人が特定のハードウェア上でなぜ特定の演算がボトルネックになるかを理解したい場合に、適切な入口となっています。マイクロアーキテクチャ（パイプラインステージ、キャッシュ置換ポリシー、DRAMタイミング）の深部には踏み込んでいませんが、アーキテクチャレベルのトレードオフを適切にカバーしています。

Source: https://www.jepeake.com/ai-chip-architectures

AIにコードで絵を描かせる：SVG生成のためのQwen上でのRL

Surya Bhupatiraju氏の投稿では、Qwen（7Bクラスのオープンウェイトモデル）を強化学習でfine-tuningし、指定された視覚的ターゲットを正確にレンダリングするSVGコードを生成させる試みを紹介しています。これは、報酬シグナルがテキストの一致ではなく画像の類似度に基づく、制約付きコード生成問題です。

セットアップとしては、モデルがSVG XMLをテキストとして生成し、そのSVGをヘッドレスブラウザまたはcairosvgでレンダリング、レンダリングされたビットマップをターゲット画像と微分可能な知覚的メトリクス（CLIPの類似度またはSSIM、あるいはその両方）を用いて比較します。RLアルゴリズムはGRPOまたはPPOの変形版（投稿ではDeepSeek-R1のパターンに従いGRPOを使用しているようです）です。報酬は純粋に視覚的なものであり、有効性以外のSVG構文への教師信号はありません。

技術的な課題として興味深いのは、SVG生成が長いトークン列と複雑な階層構造（入れ子になった要素、変換行列、ベジェパス構文）を含み、トークンレベルの小さなエラーが非滑らかに大きな視覚的誤差を生じさせる点です。これにより、学習の初期段階では報酬のランドスケープが疎になります。投稿ではカリキュラム学習によってこれに対処しており、単純な幾何学的ターゲット（矩形、円）から始めて複雑なシーンへと段階的に進んでいきます。

モデルは、supervised fine-tuningだけでは学習データから際立たせることのできなかったSVGの機能を活用することを学習します。具体的には、視覚的効果を達成するためのグラデーション塗りつぶし、クリッピングパス、レイヤー合成などです。これは、コード生成のためのRLポストトレーニング（AlphaCode、CodeRL）が、模倣学習を超えてテストのpass rateを最大化する言語機能の活用をモデルに可能にするのと類似しています。

結果は定性的なものですが説得力があります。ポートレート風の画像に対して生成されたSVGは、写真的な内容を近似するために幾何学的プリミティブを一貫して活用しており、これはSVGデータセット上の純粋なSFTでは一般的に達成が難しいものです。投稿にはベースライン（例：SVGCraft、Star-Vector）との比較を行った正式なメトリクスが含まれておらず、これが主な不足点です。

Source: https://surya.website/rling-qwen-to-paint-with-code

注目の新しいリポジトリ

QwenAudio/qwen-audio-agent

LLMベースのエージェントがライブ音声セッション中に応答性と一貫性を維持できるよう設計された、リアルタイム音声ランタイムです。このランタイムが解決する中心的な問題は、ストリーミング音声I/Oと大規模モデルの比較的低速な推論ループとの間にある、レイテンシおよび状態管理のギャップです。素朴なパイプラインでは、モデルの出力待ちでブロッキングが発生するか、会話のコンテキストが失われるかのいずれかになります。このランタイムはターンをまたいで永続的なエージェント状態を維持し、音声チャンクをバッファリングし、VAD（voice activity detection）と非同期ツール呼び出しの実行を協調させることで、ユーザーが発話中または待機中であっても、エージェントが関数の実行やAPIへの問い合わせといった作業を継続できるようにします。アーキテクチャは音声パイプライン（キャプチャ、VAD、ASR）と推論レイヤーを分離しており、転写されたターンを管理されたコンテキストウィンドウとともにQwen-Audioモデルへ供給します。ツールの実行結果は、音声チャネルを中断することなくストリームに注入されます。デモではなくインフラストラクチャとして設計されており、カスタムツール登録のためのフックを公開し、明示的なメモリ管理を伴うマルチターンセッションをサポートしています。重複する発話やバックグラウンドタスクを処理する際にエージェントが無応答になることなく対応できる音声アシスタントを構築する方に有用です。Qwen-Audioのマルチモーダル能力を基盤として構築されているため、ASRとLLMを別々にカスケードする方式ではなく、同モデルの音声・テキスト統合事前学習の恩恵を受けています。

Source: https://github.com/QwenAudio/qwen-audio-agent

hardrave/NIGHTRUN

NIGHTRUNは、UEFIファームウェアから直接LLMを実行します — OSなし、カーネルなし、libcなし。Rustで記述されており、EFIステージでマシンの制御を掌握するUEFIアプリケーションとして起動し、その特権的なベアメタル環境で推論を完全に実行します。実用上の帰結として、信頼済みコンピューティングベース（trusted computing base）が大幅に削減されます：OSのスケジューラなし、ファイルシステムドライバスタックなし、明示的に実装しない限りネットワークスタックなし、ユーザ/カーネルの特権境界もありません。メモリ管理はUEFIメモリマップに対して手動で行われます。Rustのno-stdエコシステムによってこれが現実的になっています — コードベースはファームウェアバインディングにuefi-rsを使用し、EFIメモリデスクリプタに対して独自のアロケータを実装しています。モデルの重みはEFIシステムパーティションから読み込むか、コンパイル時に埋め込まれます。計算はCPUのみであり、この環境にGPUドライバは存在しません。推論エンジンは最小限のものであり、利用可能な物理RAM内（メモリマップドI/Oの競合が発生する前）に収まる小型の量子化モデル（おそらくGGUF形式のQ4またはQ8）をターゲットとしています。セキュリティ研究の観点から興味深い点として、UEFIレベルのLLMはプリブートポリシーエンジンとして、またはOSレベルの改ざんの影響を受けないエアギャップ分析ツールとして機能し得ます。また、Rustのno-stdの成熟度がファームウェアレベルのMLワークロードに十分対応できることを技術的に真剣に示したデモンストレーションでもあります。本番の推論インフラストラクチャではありませんが、制約のある環境や敵対的な環境に向けた意義ある概念実証です。

Source: https://github.com/hardrave/NIGHTRUN

truespar/sentio

Sentioは、Rustで書かれたフルマルチテナント対応のSMTPメールサーバーであり、AIエージェントにプログラマブルなメールアイデンティティを付与することを目的として設計されています。各エージェントは実際にルーティング可能なメールアドレスを取得し、受信メールは生のMIMEではなく構造化されたJSONウェブフックとして解析・配信されます。また、送信返信はスレッドのコンテキストを保持したままREST API経由で行われます。インフラストラクチャ層は包括的な構成となっており、DKIM署名・検証、SPFおよびDMARCポリシーの適用、転送メール向けのARC（Authenticated Received Chain）、トランスポートセキュリティポリシーのためのMTA-STS、そしてTLSAレコード検証のためのDANE（DNS-Based Authentication of Named Entities）を備えています。スパム対策は3つの層にわたって機能していますが、具体的なメカニズム（ヒューリスティクス、レピュテーションリスト、コンテンツスコアリング）については現時点では公式に完全なドキュメントが公開されていません。Rustによる実装により、MTA自体が並行テナント分離に対して安全であり、旧来のCベースのMTAに多く見られるメモリ安全性の落とし穴を回避しています。マルチテナントモデルがこの設計の核心的なエンジニアリング判断であり、新しいエージェントアドレスのプロビジョニングはメールサーバーの設定変更ではなくAPIコールで完結します。非同期通信が必要なエージェントワークフロー、すなわち返信の待機、メールスレッドへの参加、外部通知の受信といったユースケースにおいて、レート制限やデータ共有上の問題を伴うサードパーティ製メールAPIを後付けで組み込む必要がなくなります。メールをネイティブな通信チャネルとして人間やサービスと対話する自律エージェントに対して、直接的に有用なソリューションです。

Source: https://github.com/truespar/sentio

antinomie-lab/pi-book

Pi-bookは、AIエージェントをゼロから構築する際の設計・実装上の意思決定を、ソース管理された構造化ノートとして記録する「生きたアーキテクチャノートブック」です。このコンテンツはチュートリアルでもフレームワークでもなく、アーキテクチャ意思決定レコード（ADR）のコーパスに近いものであり、コンポーネント境界、状態表現、ツールインターフェース、メモリモデル、オーケストレーションパターンの背景にある reasoning を網羅しています。ソース管理されているという性質上、ノートはコードと並行して進化し、git履歴が設計変更の理由を示す根拠の軌跡として機能します。博士レベルの読者にとっての価値は、コード自体よりも設計空間の分析にあります。すなわち、どのようなトレードオフが明示されているか、どの前提が設計の根幹を担っているか、既存の抽象化とどこで摩擦が生じたかといった点です。このフォーマットは現実のギャップに対処しています。多くのエージェントフレームワークは「なぜそのように構造化されているか」についての documentation がほとんどなく、適応や失敗モードの理解が困難な状態で公開されています。Pi-bookはその reasoning を第一級の要素として扱います。また、独自のエージェントアーキテクチャを設計しようとしている人が、文書化された先例に照らして自身の意思決定を監査したい場合の有用なリファレンスにもなります。このリポジトリのスター数の推移は、ブラックボックスなフレームワークドキュメントに辟易し、APIコールの次元ではなく原理の次元でエージェント設計を深く考えたい実務者に、このフォーマットが響いていることを示唆しています。

Source: https://github.com/antinomie-lab/pi-book

PicoMQ/picomq

PicoMQは、インフラの複雑性スペクトルの低い側を対象とした耐久性のあるストリームブローカーです。KafkaやRedpandaが運用上過剰となる状況、つまりat-most-onceデリバリーではなく永続的・順序保証・再生可能なメッセージストリームが必要な場面を想定しています。「durable streams」というフレーミングは、メッセージが確認応答前にディスクに書き込まれること、コンシューマーが任意のオフセットにシークできること、そしてブローカーが再起動後もデータを失わずに生き残ることを意味します。実装は意図的に最小限に抑えられており、小さなバイナリ、少ない依存関係、シンプルなデプロイが特徴です。これにより、Redis Streams（耐久性はあるがRAMが主体）とフルKafka（ZooKeeper/KRaftとJVMのオーバーヘッドが必要）の中間に位置づけられます。想定されるユースケースは、エッジデプロイメント、より大規模なシステムへの組み込みインフラ、そしてKafkaの運用フットプリントなしにKafkaセマンティクスを求める開発環境です。技術的な賭けはスループットの最大化よりもシンプルさと正確性に置かれており、重いブローカーの運用コストがもたらすエンジニアリング上の価値を上回る場合に意義を持ちます。コードベースはストレージエンジンの選択——セグメントローテーションの処理方法、オフセット検索のインデックス構造、コンシューマーグループの状態管理——を検討する価値があります。191スターとまだ初期段階であるため、APIのインターフェースと耐久性の保証はまだ安定していません。そのため、本番環境での採用にあたっては、障害発生時の書き込みパスとfsyncの挙動について十分な精査が必要です。

Source: https://github.com/PicoMQ/picomq

aigclink/geolook

GeoLookは、エンドツーエンドのGEO（Generative Engine Optimization）パイプラインを実装しています。GEOとは、従来の検索ランキングではなく、LLMが生成する回答における可視性のためにコンテンツやプレゼンスを最適化するという新興の手法です。このパイプラインは、ステータス分析（対象エンティティに対する現在のLLM引用頻度の計測）、診断（引用が存在しない・不正確な理由の特定）、戦略生成（表現を改善するためのコンテンツや構造化データの変更案）、チケット作成（実行可能な作業項目）、実行、および検証（変更後の再計測）という全サイクルをカバーしています。LLMベースの回答エンジン（ChatGPT、Perplexity、Gemini）がランク付きリンクを提示せずに回答を合成することが増えており、従来のSEO指標が無意味になりつつあるため、これは重要な取り組みです。GEOでは、モデルがトレーニングデータをどのようにサンプリングするか、エンティティの曖昧性解消をどのように処理するか、そして権威あるソースをどのように重み付けするかを理解する必要があります。GeoLookのオープンソース実装は、診断・最適化の全ループを監査可能にしており、実践者にとってだけでなく、コーパス操作によってモデルの挙動がどのように影響を受けるかを研究する研究者にとっても価値があります。このアーキテクチャは、診断推論と戦略生成の両フェーズにLLM呼び出しを使用しているようであり、モデルがモデルへの影響方法を助言するというメタループを生み出しています。この循環性は、評価方法論が成熟するにつれてプロジェクトが対処すべき正当な測定妥当性の問題を提起しています。

Source: https://github.com/aigclink/geolook

rome-os/rome

Romeはアジェンティック OS として自らを位置づけています。これは、AIエージェントを従来のOS上にアプリケーションレベルの構成要素として付け足すのではなく、第一級のプロセスとして扱うランタイムおよびコーディネーションレイヤーです。設計上の仮説は、標準的なオペレーティングシステムの抽象（プロセス、ファイル、ソケット）が、異なるリソース・永続性・通信パターンを持つエージェントワークロードに対して適合性が低いというものです。Romeはエージェントのライフサイクルに対してネイティブなプリミティブを提供しようとしており、エージェントのスポーン・サスペンド・レジュームを計算の基本単位として扱い、メモリとツールへのアクセスをアプリケーションコード内部ではなくOSレベルで管理します。これはアーキテクチャ的に野心的であり、まだ初期段階にあります。興味深いエンジニアリング上の問題としては、エージェントの分離（ツールアクセスのサンドボックス化、意図しない副作用の防止）をどのように扱うか、協調するエージェント間の共有状態をどのようにモデル化するか、そして推論呼び出しに対してスケジューラがプリエンプティブか協調的かという点が挙げられます。305スターを獲得しており、アジェンティックワークロードが主流になった場合のシステムソフトウェアの方向性に対する概念的な賭けとして注目を集めています。近い将来における実用的な用途は、文字通りのOS置き換えというよりも、独自の設計思想を持つエージェントオーケストレーションフレームワークとしての利用になる可能性が高いですが、このフレーミングがAPIデザインに影響を与え、LangGraphやAutoGenが提供するものよりも低レベルで高い合成可能性を持つプリミティブへと向かっています。

Source: https://github.com/rome-os/rome

brijr/iris

Irisは、最小限のAPIインターフェースとレンダリング精度にフォーカスしたウェブサイトスクリーンショットサービスです。コアエンジンは、静的なHTMLスナップショットではなく、ヘッドレスブラウザバックエンドを使用してJavaScriptがレンダリングされたライブページをキャプチャします。これにより、SPAや動的に読み込まれるコンテンツも正確にキャプチャされます。インターフェースは意図的に最小限に設計されており、URLを指定してスクリーンショットを取得するだけで、ビューポートのサイズ、遅延（JS実行を待つため）、フォーマットなどのオプションも利用できます。「強力なエンジン」という主張は、複雑な機能セットではなくレンダリングパイプラインを指しており、価値の根拠は現代の幅広いウェブスタックにわたるキャプチャの信頼性と正確性にあります。ユースケースとしては、ビジュアルリグレッションテスト、コンテンツのアーカイブ、リンクプレビューの生成、URLの現在のビジュアル表現を必要とするLLM visionパイプラインなどが挙げられます。AIエージェントのワークフローにおいて、スクリーンショットキャプチャは繰り返し登場するプリミティブです。ウェブを閲覧したりタスクの完了を確認したりするエージェントは、DOM検査だけでは得られない視覚的なグランドトゥルースを必要とすることが多いからです。Irisは、PlaywrightやPuppeteerのようなフルブラウザ自動化フレームワークと直接統合することなく、クリーンでセルフホスト可能なサービスとしてこれを提供します。最小限のインターフェースにより統合の手間が軽減される一方、エンジンはフォントの読み込み、遅延ロード画像、CSSアニメーションなど、現代のウェブレンダリングの複雑さを処理します。より大きなパイプラインにおけるマイクロサービスの依存関係として適しています。

Source: https://github.com/brijr/iris