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

公開

2026年8月13日

English · 日本語

arXiv ハイライト

OpenART: オープンエンドな環境進化によるエージェント Red Teaming のスケーリング

問題設定

エージェント安全性ベンチマークの多くは、短期的かつ静的なタスクに対して単一プロンプトをテストするものであり、デプロイされたエージェントにおける主要な障害モード、すなわち変化可能な環境との長期的・状態保持型のインタラクションから生じる累積的リスクを捉えられていません。エージェントが永続的なワークスペース上で数十のツールを協調させる場合、初期の書き込み（おとりレコード、汚染された命令、リダイレクトされた宛先）が後続のステップへ伝播しますが、このような影響は単一ターンのprompt injectionベンチマークでは捕捉できません。OpenARTはこのギャップに取り組むため、評価の単位をプロンプトではなく実行可能シナリオとして定義し、敵対的なユーザーメッセージではなく環境状態の許可された変更を通じてred teamingを行います。

OpenARTの概要：シナリオ、ターゲット固有アダプター、および75のエージェント・モデル構成にわたる制御された環境進化。

手法

OpenARTは評価をシナリオ構築、ターゲットネイティブ投影、制御された環境進化の3段階に分解します。

シナリオはターゲット非依存のコントラクトであり、良性目標 \tau、実行可能な環境仕様、ワークフロー、および決定論的ルール E_q で評価される隠れた安全条件の4要素を固定します。ドメインシード（例：「クラウドプラットフォームの変更調整」）からプランナーが完全なシナリオへ展開し、ユーザーに見えるタスク、初期環境 x_0、評価器が導出されます。ターゲットアダプター \Pi_r は、シナリオのセマンティクスを変えることなく、シナリオをデプロイ済みエージェントのネイティブランタイム（ワークスペースプリミティブ、MCP、ツール、スキル）へ投影します。これにより「何をテストするか」と「ターゲットがどのように表現するか」が分離され、1つのシナリオを異種エージェント間でインスタンス化できます。

3段階アーキテクチャ：シナリオ構築、ターゲットネイティブ投影、フィードバック誘導による環境進化。

red teamingプロトコルは環境状態上の制御されたマルコフ過程です。ラウンド t において、現在の環境 x_t と攻撃者コンテキスト C_t が与えられると、ポリシーが変更 \Delta_t を提案し、それらがフィルタリングされてアダプターを通じてマテリアライズされます：

\Delta_t \sim p(\cdot \mid x_t, C_t), \quad m_t = \Pi_r(\Delta_t)

ターゲットは元のタスクを実行し、軌跡 \xi_t、次の状態 x_{t+1}、評価器フィードバック Y_t を生成します：

(\xi_t, x_{t+1}) \sim K_r(\cdot \mid \tau, x_t, m_t), \quad Y_t = E_q(\tau, \xi_t, x_{t+1})

C_{t+1} = U(C_t, x_t, \Delta_t, m_t, Y_t)

重要なのは、\tau と E_q が進化全体を通じて不変であり、ターゲットに見える状態のみが変化する点です。したがって攻撃成功率の改善は、評価ゴールポストのシフトではなく、より強力な環境摂動を反映しています。インスタンス化されたポリシーである EMHA（Evolutionary Markov Hypergraph Attack）はブラックボックスであり、パラメータの更新を必要としません：許可された状態遷移上のhypergraphを維持し、評価器フィードバックに基づいてマルチベクトル変更（ワークスペースコンテンツ、注入された命令、ケイパビリティメタデータ、保持された実行状態）を協調させます。

厳格な攻撃成功指標は決定論的評価器とGLM-5.2ジャッジの一致を必要とします：

\mathrm{ASR}_{\mathrm{strict}} = \frac{1}{N}\sum_{i=1}^N \mathbf{1}\{D_i = 1 \land L_i = 1\}

不一致はすべて失敗としてカウントされ、保守的な推定値が得られます。

規模と結果

Arenaは50ドメインにわたる10,000件以上の検証済みシナリオで構成されており、SkillNetに倣って収集された50万件以上のツール、MCP、スキルのコーパスから構築されています。決定論的評価器の検証をパスしたバンドルのみが保持されます。シナリオの中央値は97ツール呼び出しを必要とし、タスクは累積的な状態効果が支配的な長期ホライズン領域に位置します。評価は75のエージェント・モデル構成（15のデプロイ済みエージェント × 5の基盤モデル）を対象としています。

正規化後の頻度に応じてワードサイズが変化する、OpenARTの50ドメインのボキャブラリー。

50ドメインのボキャブラリーはエンタープライズ運用、金融、ヘルスケア、インフラワークフローにまたがっており、シナリオが合成的なサンドボックスではなく運用上現実的な設定から取得されていることを示しています。アブストラクトによると、EMHAは進化前のベースラインと比較して75すべての構成においてStrict-ASRを大幅に向上させることが報告されており（提供された抜粋には構成ごとの具体的な数値は記載されていません）、良性タスクを安定して完了するエージェントでさえも環境が敵対的に進化されると脆弱であることが示されています。

制限と未解決の問題

この設計からいくつかの懸念点が生じます。第一に、シナリオをコントラクトとして抽象化するアプローチは、決定論的評価器 E_q が安全条件を忠実にエンコードしていることを前提としており、安全性が本質的に曖昧なシナリオ（例：コンテキスト依存の情報開示）は固定ルールで捉えることが困難であり、GLM-5.2を共同ジャッジとして使用することはそのモデルのバイアスを引き継ぎます。第二に、「許可された状態遷移」がEMHAの行動空間を制限しており、このフレームワークはワークスペースの一部への正規な書き込みアクセスを持つ脅威モデルに対するロバスト性をテストするものであり、共有エージェント設定には現実的ですが、外部のprompt injection表面はカバーしていません。第三に、中央値97ツール呼び出しはコストが高く、10Kシナリオ × 75構成 × 複数の進化ラウンドを実行することは深刻な計算コストを伴いますが、論文（提供された抜粋において）はシナリオごとのコストやジャッジ一致率を定量化していません。第四に、EMHAはブラックボックスかつフィードバック駆動であるため、敵対的に訓練されたエージェントに対する収束挙動が不明確であり、hypergraph構造と更新則 U はここでは詳述されていません。

この研究の意義

プロンプトレベルのred teamingは、モデル化する攻撃面が狭いため、すぐに飽和してしまいます。OpenARTは問題を再定式化します：安全性とは時間の経過とともに実行される環境の性質であり、そのストレステストにはタスクと評価器を固定したまま状態を進化させる必要があります。EMHAスタイルの環境進化が一般化するならば、それはエージェントデプロイメントにおける adversarial training の自然なアナログとなり、10Kシナリオ・75構成という基盤が進捗を測定するための再現可能なベンチマークを提供します。

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

Mechanist: 知性のメカニズムを発見するための科学的計測器としてのAI

問題

メカニスティックな解釈可能性は依然としてボトルネックとなっています。モデルの能力はそれを説明する能力よりも速くスケールしており、既存の自動解釈可能性ツールは、単一のニューロンやSAE featureのラベリングといった狭いタスクに対処するにとどまり、事前学習と推論にまたがる一般的なメカニズム理論を提案・検証するものではありません。同時に、SakanaのシステムやClaude Codeのような「AIサイエンティスト」エージェントは、MLエンジニアリングタスク（学習パイプライン、ベンチマーキング）を対象としており、モデルが内部で何を計算しているかの因果的分析を行うものではありません。

既存のAIサイエンティストとMechanistのスコープの比較

本論文では、モデル自体を科学的対象とするマルチエージェントフレームワークであるMechanistを提案しています。このフレームワークは、内部メカニズムに関する仮説を自律的に提案し、因果的介入を実行し、反復します。

手法

Mechanistは、発見ループを4つの段階的なエージェントに分解しており、それらはオーケストレーターによって調整されます。オーケストレーターは目的を解析し、エージェントを順次ディスパッチし、エージェント間で受け渡されるアーティファクトを検証します。

  1. Hypothesis Agent（仮説エージェント）。 ユーザーの目的が与えられると、意図をドメイン固有のクエリに分解し、2つのグラフから証拠を取得します。(i) 約13,000件の論文からなるキュレーション済みの解釈可能性KG、および (ii) 神経科学、心理学、分子生物学を含む26分野にわたる4,300万件の論文を収録した多分野グラフSciAtlasです。各仮説は、マイルストーンレベルのテストと対になった原子的主張として出力されます。学際的な検索が動機となった例として、信念推論の三者分解（World Knowledge、Personal Belief、Attributed Belief）が挙げられ、これはtheory-of-mind文献から取り入れられたものです。

  2. Experiment Agent（実験エージェント）。 各主張を、データセット分割、対象モデル、解釈可能性手法、コントロール、メトリクス、計算予算を指定した実行可能なスイートに操作化します。probing、因果的介入（activation patching、path patching）、および検証をカバーする32のメカニスティック分析手法のキュレーション済みライブラリを活用します。軽量なサニティチェックパスが完全なデプロイメントへのゲートとして機能します。

  3. Verification Agent（検証エージェント）。 ラベルの来歴、データリーケージ、メトリクスの妥当性、報告された数値からログされた実行結果へのトレーサビリティを監査し、結論のロバスト性を評価します。

  4. Iteration Agent（反復エージェント）。 検証済みの知見をKGにフィードバックし、後続の仮説が成長する内部記録に基づいて条件付けられるようにします。

MechanistとClaude Code、AI-Scientistを比較したフレームワーク概要とベンチマーク

ケーススタディ：クロスモーダルなサブリミナル転移

最も印象的な行動的知見は、対立する選好やクロスモーダルな設定へのサブリミナル学習の拡張です。先行研究では、フクロウを好むGPT-4.1教師からの中立的な数列でfine-tuningされたGPT-4.1学生がフクロウの選好を継承することが示されていました。Mechanistは2つの拡張を提案し、検証しています。

  • フィルタリングされたデータによるSafety転移。 安全でない教師からの応答を、安全と分類されたコンテンツのみを保持するようにフィルタリングし、Qwen3.5-9B学生のfine-tuningに使用します。この学生は、フィルタリングされた安全なデータのみで学習したにもかかわらず、マルチモーダルな実験室安全プロンプトに対して安全でない回答を生成します。
  • クロスモーダルな選好転移。 バナナを好む教師を用いてリンゴの画像を生成し、これらのリンゴ画像でfine-tuningされたQwen-Image学生が、好きな果物を聞かれるとバナナの画像を生成します。

Mechanistによって発見されたクロスモーダルおよび対立選好のサブリミナル転移

いずれの効果も N=3 の学習実行と95% t-CIで定量化されており、通常の教師の出力と特性を持つ教師の出力でそれぞれ学習した学生間に統計的に明確な分離が見られます。これは真に安全性に関わる結果です。モダリティを跨ぐフィルターは潜在的な特性の伝達を無効化しません。

信念メカニズムと介入

認知科学から取り込んだ信念分類法を用いて、Mechanistはモデルが世界知識をどのようにエンコードし、個人的な信念を形成し、他者に信念を帰属させるかを記述するメカニズム理論を導出し、事前学習チェックポイントにわたるこれらの表現の出現を追跡します。その理論は次に、下流タスクの性能を向上させるステアリング介入へと変換され、さらに科学的foundation modelの設定（Evo2-7B）においては、ユーザーが指定した特性に向けてDNA配列生成をバイアスするactivationレベルのステアへと変換されます。

定量的評価

Mechanistは、9つの研究分野にわたる16件の再現論文を対象に、Claude CodeおよびSakana AI-Scientistと比較してベンチマークされており、4つの次元（データ使用、実験設計、実験実行、結果分析）について、3名の人間の専門家とLLMジャッジとしてのClaude Opus 5およびGPT-5.6-solによって評価されています（ジャッジあたり48のシステム-論文ユニット）。結果は以下の通りです。

  • Mechanistはすべてのジャッジのもとで最も高い平均信頼性を達成しており、ジャッジペアのSpearmanの順位相関は一貫した順序付けを示しています。
  • 仮説の品質（最近傍の10件の関連研究に対する新規性、インパクト、検証可能性でスコアリング）は、両ベースラインよりも高くなっています。

評価方法論自体も注目に値します。3名の人間と2つのLLMジャッジにわたるペアスコアリング、ブートストラップCI（4,000リサンプル）、ジャッジ間のランク相関チェックが含まれています。

限界と未解決の問題

  • 論文の中心的なメトリクス — 再現の信頼性に関するLLMまたは人間による判断 — はグラウンドトゥルースのメカニズムテストではなく、ジャッジ間の合意は共通の盲点を排除しません。
  • メカニズムライブラリ（32手法）は帰納的バイアスを固定します。ライブラリに存在しない手法でのみ検証可能な仮説は体系的に十分に探索されません。
  • サブリミナル転移の知見は重要ですが、特定のモデルファミリー（GPT-4.1、Qwen3.5-9B、Qwen-Image）で実証されており、特性リーケージのスケーリング則は未解明のままです。
  • 「信念メカニズム理論」は操作的なものであり、その構成概念がプロービングされたタスクを超えて汎化するか、あるいはプロービング基底のアーティファクトを反映しているかは検証されていません。
  • エージェントループのコスト、実時間、および失敗モードは抜粋では詳述されていません。

なぜこれが重要か

自律エージェントがフロンティアモデルに関する因果メカニズムの主張 — フィルタリングされたデータを通じたクロスモーダルな特性リーケージのような安全性に関わるものを含む — を提案、検証、証明できるならば、メカニスティックな解釈可能性はボトルネックではなくスケーラブルなパイプラインとなります。問題は、この分野の評価基準が追いつく必要があるということです。再現に関してLLMによって判断される信頼性は、メカニズム理論自体の対抗的な反証の代替にはなりません。

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

ToolHazard: LLMベースエージェントのセキュリティ評価とアライメントのための敵対的環境のスケーリング

問題

間接プロンプトインジェクションは、ツール使用型LLMエージェントにとって現在最も支配的な攻撃対象領域となっています。エージェントの観測に後から流れ込む任意の環境状態（メール本文、DBレコード、ツール出力など）に書き込める攻撃者は、ユーザクエリやシステムプロンプトに触れることなく、エージェントの意思決定ループを乗っ取ることができます。既存のベンチマーク（InjecAgent、AgentDojo、およびその派生物）は、固定されたインジェクションスロットを持つ手作業で構築された環境に依存しており、ツール応答のシミュレーションに確率的なLLMを使用することが多いです。これにより、ドメインのカバレッジが制限され、非決定論的な評価が生まれ、インジェクションが実際にどこでいつ成功するかを研究することが困難になります。ToolHazardの貢献は、手作業による環境エンジニアリングのボトルネックを取り除き、プログラム的な成功チェックを備えた実行可能かつステートフルな環境を生成する合成パイプラインです。

手法

脅威モデルは標準的なものです：エンティティ/状態 \mathcal{E}、遷移規則 \mathcal{R}、ツールAPI \mathcal{T} を持つ環境 e=\langle\mathcal{E},\mathcal{R},\mathcal{T}\rangle を想定します。良性クエリ q が与えられると、エージェントは \tau=(q,a_1,o_1,\ldots,a_T,o_T)\sim\mathcal{A}(q,e) をサンプリングします。攻撃は e'=\operatorname{Inject}(e,\ell,\delta) としてモデル化されます。ここで \ell は攻撃者が書き込み可能で観測に伝播する状態であり、成功は注入された \delta が最終環境スナップショット上で検証可能な意図しないツールアクションを引き起こすこととして定義されます。

ToolHazardフレームワークの概要

三つのモジュールが協調して動作します。Environment Simulator はToolACEおよびAPI-Bankからシードクエリを取り込み、段階的なプロンプト駆動型プランニングを実行してブループリント

\mathcal{B}=f_{\text{ops}}\big(f_{\text{state}}(f_{\text{env}}(\mathcal{D}))\big),

を生成します。ここで f_{\text{env}} はドメイン（例：銀行、カレンダー、CRM）を推論し、f_{\text{state}} はエンティティスキーマと遷移制約を導出し、f_{\text{ops}} は実行可能なクエリ/ミューテーション操作を列挙します。ブループリントはその後、実行可能なPythonツールコードにコンパイルされ、自動品質インスペクタに通されます。Attacker Agent はコンパイルされた環境を探索して、タスク実行中に実際に到達可能な（読まれないフィールドへのインジェクションとは対照的に）実行可能なインジェクションポイント \ell を特定し、6種類のラッパーのもとでペイロードをインスタンス化します：basic-combined、important-template、multi-turn、decision-hijacking、reasoning-criteria、tool-selectionです。User Simulator は状態に基づいた長いホライゾンのタスクを生成し、その成功と攻撃の結果は最終環境スナップショット上で実行される生成されたチェック関数によって検証されます。チェック関数はGPT-4.1-miniによって一度合成された後、決定論的に実行されます。評価ループにLLMジャッジは存在しません。

ベンチマーク構築とカバレッジ

パイプラインは最初に191の有効な環境を生成し、140の訓練候補と51のテスト候補に分割されます。タスクの軌跡上で実際に到達可能なインジェクションポイントを含む環境にフィルタリングすると、ToolHazard-Align（アライメントデータ生成）用に60環境、ToolHazard-Bench用に28の独立した環境が残ります。

ToolHazard-Benchの統計

ToolHazard-Benchは512のツールと87の状態に基づくタスクを含み、平均実行ホライゾンは15.56ステップです。これは単一または少数ステップのツールシーケンスを重視する従来のインジェクションベンチマークのほとんどよりも大幅に長いものです。ドメインの幅広さはシードデータセットから継承されています（環境のワードクラウドは金融、スケジューリング、ヘルスケア、Eコマース、生産性関連の用語が支配的です）。

合成された環境サマリーのワードクラウド

結果

7つのエージェントがReActループで評価されています：GPT-5、GPT-4.1、Gemini-3.1-pro-preview、Gemini-2.5-pro、DeepSeek-V3.2、Qwen3-8B/4Bです。論文の主要な実験的主張は以下の通りです：

  • すべての対象エージェントは6種類の環境側攻撃戦略において実質的な脆弱性を示しており、攻撃スイート全体にわたってロバストなモデルは存在しません。
  • インジェクションのタイミングは強く影響します。攻撃戦略をtool-selectionに固定した場合、最も早く到達可能な状態（top-1）でインジェクションすることで、top-2やランダム配置よりも一貫して高いASRが得られます。早期ステップの観測はエージェントの計画を再形成する可能性がはるかに高く、おそらくエージェントの初期のReActの思考が軌跡にコミットしてしまうため、後から矛盾する内容が現れても容易に覆せないためと考えられます。
  • ToolHazard-Alignデータによるfine-tuningは、良性タスク完了率（BR）を維持しながら、ToolHazard-BenchおよびOut-of-distributionなAgentDojoベンチマークの両方でASRを低減させます。これは合成されたアライメントデータがToolHazard独自の攻撃テンプレートに過学習するのではなく、汎化することを示しています。

BRとASRは環境スナップショット上での実行チェック関数によって計算されるため、LLMで採点するエージェントベンチマークに蔓延するジャッジの分散やプロンプト感度の問題を回避できます。

制限と未解決の問題

カバレッジはシードデータセットによって制限されます：ToolACE / API-Bankのドメイン分布外の環境は合成されません。環境生成、タスク生成、チェック関数合成のすべてにGPT-4.1-miniを使用しているため、そのモデルの系統的なバイアス（例えば、特定の競合状態や認可パターンの過少表現）がベンチマークに伝播します。Appendix Fでの人手による検証が主な対策です。脅威モデルはブラウザ/ウェブページレベルのインジェクションを明示的に除外していますが、これは現実世界では最も高インパクトなチャネルと言えます。6種類のペイロードラッパーは有用な分類法ですが網羅的ではなく、アライメント訓練済みエージェントに対する適応的な攻撃は研究されていません。最後に、「攻撃成功」は最終スナップショット上でのチェック関数の発火によって定義されているため、終端条件を変えずに中間状態を損傷する部分的なハイジャックを見逃す可能性があります。

この研究が重要な理由

ToolHazardは、敵対的環境の構築を特注のエンジニアリング作業から、決定論的かつプログラム的な評価を伴うコンピュート・スケーラブルな合成パイプラインへと変換します。インジェクションのタイミングがペイロードの文言よりも支配的であるという知見――最も早く到達可能なスロットが最高のASRをもたらす――は、防御策に直接的な示唆を与えます：早期ステップの入力検証とプランロッキングは、後段の出力フィルタよりもレバレッジが高い可能性があります。

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

視覚的ツール使用の幻想：画像を用いた思考に対する因果的監査

問題設定

「画像を用いた思考」パラダイムは、マルチモーダルLLMが推論中に視覚的操作——典型的にはcrop-and-zoom——を呼び出すことを可能にします。これは、画像領域に能動的に再注目することで細粒度の知覚が向上するという前提に基づいています。実際には、こうしたエージェント的パイプラインは直接推論と同程度の性能にとどまるか、それ以下となることが多く、さらにはるかに多くのトークンを消費します。また、無関係な領域を繰り返しクロップするといった病理的な挙動や、ベースモデルが正しく回答できる質問に失敗するといった現象も見られます。本論文は「ツール使用は有効か？」という問いよりも鋭い問いを立てます。すなわち、返ってきた視覚的証拠が回答を因果的に駆動しているのか、それともツール呼び出しは単なる構文的な骨組みに過ぎず、言語の事前分布がそれを利用しているだけなのか、という問いです。

因果的定式化

著者たちは視覚的ツール使用のトラジェクトリを構造的因果グラフとして形式化します。ステップ i において、ポリシー \pi がアクション

T_i \sim \pi(\cdot \mid I, Q, T_{<i}, O_{<i})

をサンプリングし、視覚エンジン E_{\text{tool}} が観測 O_i（クロップされたサブ画像）を生成します。そして n ステップ後にモデルが Y \mid (I, Q, T_{1:n}, O_{1:n}) を出力します。このグラフは Y へ至る2つのパスを分離します。すなわち、観測を介したパス T \to O \to Y（真の知覚的寄与）と、アクションによって誘発されるショートカット T \to Y です。後者は、ピクセルを一切参照しなくても、ツール呼び出しを発するだけで言語コンテキスト（chain-of-thought、領域名、座標など）が変化することを反映しています。

著者たちはこのグラフを3つの介入レベルで監査します：

  • ポリシーレベル：ツール使用全体と直接推論を比較し、T \to O \to Y サブグラフ全体のオン・オフを切り替えます。
  • トラジェクトリレベル：ロールアウト中に各実観測 O_i を破損した \tilde O_i に置き換えます。ポリシーが破損したフィードバックを受け取るため、新しいアクション列 \tilde T_{1:\tilde n} に分岐する可能性があり、閉ループ効果を捉えます。
  • ステップレベル：固定されたプレフィックス (T_{<i}, O_{<i}) のもとで、O_i のみを反事実的に置き換え、その限界的な寄与を分離します。

3レベルの因果介入。

ステップレベルの推定量である Visual Evidence Gain（\mathrm{VEG}_i）は、プレフィックスと下流の生成制御を固定した上で、観測 O_i のみに起因する正解確率の変化を測定します。これが鍵となる量です。T\to Y ショートカットが非ゼロである場合、ポリシーレベルの比較が過大評価されますが、\mathrm{VEG}_i は構成上それを無効化します。

監査の知見

6つのMLLMと5つの細粒度知覚ベンチマークにわたって、観測を介したパスはほぼ不活性であることが示されました。著者たちはこの病理を2つの失敗モードを持つポリシーの誤校正として整理します：

モード1 — 見ずに呼ぶ（Calling Without Looking: CWL）。 ツールは呼び出されるが、O_i は回答分布を動かさない。2つのサブケースがあります：

  • 飽和した事前分布：呼び出し前の正解確率 g_{i-1} がすでに \tau_{\text{sat}} = 0.95 を超えている状態でポリシーが呼び出しを行うため、\mathrm{VEG}_i は機械的にほぼゼロに制限されます。これはQwen3-VL-8Bで支配的に見られます。
  • 構造的に不活性な呼び出し：トラジェクトリ上のいかなる呼び出しもショートカットを超えた証拠を持たないため、ツール系列全体が T \to Y のみを介して寄与します。DeepEyesがこの典型例です。

V^* における g_{i-1} 対 \mathrm{VEG}_i の散布図は飽和パターンを明示しています。多数の呼び出しが \tau_{\text{sat}}=0.95 の線より右側に \mathrm{VEG}_i \approx 0 で集中しており、正解トラジェクトリ（C）は g_{i-1} が低く証拠が実際に機能する左上象限付近に集積しています。

V^* における呼び出し前確率 g_{i-1} 対 \mathrm{VEG}_i の呼び出しごとの散布図。

モード2 — 計画なしに見る（Looking Without Planning）。 相補的な失敗：観測は証拠を持っているが、ポリシーが十分性に達した後も呼び出しを続けるか、利用可能な信号を抽出する前に終了してしまう。この場合 T \to O \to Y は非ゼロですが、停止・確定のルールが証拠の蓄積と無相関です。

まとめると、ツール使用は「構文的な儀式」として振る舞います。すなわち、クロップアクションを発するという行為は、返ってきたピクセルが観測パスを通じて Y を変化させるよりも、トークン列（ひいてはショートカットを通じた Y）を変化させることの方がより確実に起きます。これにより、高いトークンコストにもかかわらず限界的または負の利得が生じるという実証的な謎が、訓練データのアーティファクトを持ち出すことなく説明されます。

限界と未解決問題

本フレームワークは現在crop-and-zoomに対して実体化されています。\mathrm{VEG} をより豊かな視覚的操作（描画、セグメンテーション、OCR、外部検索）に拡張するには、O_i を置き換えるために使用する反事実的観測分布の定義に注意が必要です。また、ステップレベルの推定量は \tilde O_i の破損方法の選択にも依存します。異なる破損方法は効果を異なる範囲で制限し、論文の飽和閾値 \tau_{\text{sat}}=0.95 はベースモデルの校正に診断を結びつけるヒューリスティックです。最終的に、この監査は記述的なものです。誤校正を明確に特定しますが、\mathrm{VEG}_i を高めるような訓練目標——たとえば、最終回答の正しさではなく反事実的な証拠利得に結びついたRL報酬で、CWLと計画なしに見る挙動の両方を直接ペナルティ化するもの——はまだ提示されていません。

なぜこれが重要か

「エージェント的」な視覚的ツール使用によるベンチマーク上の利得は、真の知覚的再注目とツールトークンの発行によって誘発される言語側ショートカットという、全く異なる2つのメカニズムを混同しています。Visual Evidence Gainは、いかなる画像を用いた思考システムに対しても監査可能な、原則的なステップごとの因果分解を提供し、訓練ターゲットを「モデルはツールを呼び出して正しく回答したか？」から「返ってきたピクセルは回答を動かしたか？」へと再定式化します。

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

Spark-to-Paper: 研究論文生成をコンポーザブルなスキルとしてエンドツーエンドで実現する

問題設定

研究アイデアから投稿可能な原稿までのパイプラインを自動化することは、単なるテキスト生成の問題ではありません。検証可能な引用を伴う文献検索、実験設計と実行、測定された証拠に基づくクレームの修正、編集可能なベクター形式での図版生成、そして長い時間軸にわたって執筆されるセクション間の一貫性確保が必要です。既存の「AIサイエンティスト」システムは、これらを一般的にモノリシックなエージェントに処方されたグラフとしてまとめており、すべてのサブタスクを同一のインタラクションパターンに押し込み、パイプラインのロジックを特定のオーケストレーションプラットフォームに密結合させています。Spark-to-Paperは、このパイプラインを汎用コーディングアシスタント（参照実装ではClaude Code）内で実行される13個のコンポーザブルなスキルとして再定義し、専用のエージェントランタイムを排除しています。

手法

スキルとは、研究タスクが何を達成すべきか、その制約、利用可能なツール、必要な出力アーティファクトを宣言的に記述した単位であり、内部の推論軌跡は含みません。コーディングアシスタントは共有プロジェクトファイルを読み込み、スキルの完了方法を決定し、新しいアーティファクトを書き戻します。したがって、スキルの実行は同じ宣言的インターフェースを使いながら、短時間で完了するもの（例：論点の再構成）から広範なもの（一貫性チェック失敗後の引用追加）まで対応できます。軽量な ts-paper オーケストレーターがスキルをStage 0（入力ルーティング）、Stage 1〜7（論文生成のコア）、条件付きStage 8（実験実行と原稿の整合）にシーケンスとして配列します。

Spark-to-Paper実行の概要

コアの設計原則は、モデルの判断と決定論的な操作を厳密に分離することです。LLMはコンテキスト依存の判断——論点の整理、文献の関連性、証拠がクレームを支持するか否か——を担い、決定論的スクリプトは検証可能な操作を担当します：テンプレート構造の検証、引用のクロスリファレンス、LaTeXのコンパイル、測定済みメトリクスからのプロット生成、ファイルの整合性確認です。各ステージは決定論的なゲートを通過した後にのみ進行します。

プレレジストレーションとしての実験計画。 Spark-to-Paperは実験の計画と報告を分離します。計画段階では、データセット、ベースライン、メトリクス、ablation、結果テーブルのスキーマが固定され、数値セルは実行まで空のままです。実験ステージでは、原稿のクレームを必要な証拠にマッピングし、汎用的な実験テンプレートを拡張するのではなく、ギャップを埋めるための最小限の実行セットのみを実行します。各数値結果は、原稿に採用される前に、データセット、モデル設定、シード、メトリクス、ソース出力ファイルにトレース可能でなければなりません。

実行後、各クレームは supported、partially-supported、unsupported、contradicted、needs-confirmation に分類され、保持・弱化・削除・限界セクションへの移動、または追加実験のトリガーが行われます。null結果および否定的結果は保存されます。2つの動作モードが決定論的ゲートによって強制されます：Proposal Mode（未観測の結果は未指定のままにしなければならない）とData-Aware Mode（すべての定量的クレームはデータソースに解決されなければならない）。このゲートは、数値テーブルが幻覚されるという一般的な失敗を防ぎます。

Self-Refutation Loopの上限。 自己批判が元の研究目標を再帰的に無効化し得るため、実験-批判-修正のサイクルは7回に上限が設けられています。収束に失敗した軌跡は原稿ではなく失敗レポートを生成します。これは、決定論的ゲートを通過した意味的決定に異議を唱えるSelf-ReviewスキルおよびAdversarial Reviewスキルによって補完されます。

役割を意識した図版生成。 図版は機能に応じて2つのパスで処理されます。

役割を意識した編集可能な図版生成

実験結果の図版は、測定済みメトリクスファイルからプロットプログラムを通じてネイティブベクターPDFとして直接生成され、定量的な図版がログに根拠を持つようにします。手法図および説明図は、画像生成モデルを使用してラスター形式のビジュアルターゲットを生成し、それを編集可能なテキスト、シェープ、コネクターを使用したHTMLとして再構成します。システムはHTMLを繰り返しレンダリングしてラスターと比較し、差異が許容範囲になるまでレイアウト、ジオメトリ、テキスト配置を調整し、その後PDFにエクスポートします。再構成が信頼できない場合、パイプラインは壊れたベクター図版を出力するのではなくラスターにフォールバックします。この結果、手法図版のすべてのテキストおよびジオメトリ要素は編集可能かつベクターベースのまま維持されます。

評価

評価は6つの次元にわたります——5つはアーティファクトの品質、1つは生成コスト——外部から選定された8つのトピックに対する制御された実行（うち3つはシングルパスベースラインとの対比比較のために共有）、既存システムの公開済み出力の遡及的分析、およびケーススタディを用いています。「オプティマイザーで評価する」という病理を避けるため、引用の有効性はパイプライン内の引用ゲートではなく、外部書誌サービスに対して事後的に検証されます。評価プロトコル（トピックリストおよび基準を含む）は、生成前に外部タイムスタンプとともに登録されています。既存システムとのコスト比較は、それらのシステム自身の論文で報告された値のみを使用し、入手不可能な数値は補完するのではなくそのように明記されています。

掲載されているケーススタディは、1つの短いプロポーザルから生成された2本のデモ論文を示しており、不一致なクレームにフラグが立てられています。論文は、修正ステージが測定された証拠を通じて修正した具体的な誤った期待を強調しています。

2つの異なるドメインのデモ論文に関するケーススタディ

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

クレームレベルの証拠診断（supported/contradicted等）は依然としてLLMによって実行され、構造化レポートに記録されるだけです——これが最大の残存する信頼境界です。7サイクルの実験上限はヒューリスティックであり、正当な研究軌跡がより多くのイテレーションを必要とする場合を排除するものではなく、失敗レポートという結果はhuman-in-the-loopによる回復と比較されていません。手法図版のHTML再構成パスは「少数の修正ラウンドで成功する」と示されているのみで、定量的な再構成忠実度の数値やフォールバック率の統計は提供されていません。評価はトピック間の不確実性を伴う8つのトピックで結果を報告していますが、abstractの具体的な数値クレーム（品質マージン、コスト）はここで提供されているセクションには現れていません。

重要性

興味深い貢献はモデリングではなくアーキテクチャにあります：モデルの判断を決定論的ゲートから分離し、実験実行前に証拠スキーマをプレレジストレーションすれば、ファイルI/Oとツール使用を備えた汎用コーディングアシスタントが長期的な研究自動化の十分な基盤となることを示しています。その分解——共有アーティファクトに対する宣言的スキル、検証可能な特性に対するハードゲート、意味的ドリフトに対する有界自己批判——は、幻覚された数値出力が主要な失敗モードである他の長期的なLLMパイプラインに対して再利用可能なテンプレートです。

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

テスト時のAI4AI：ハーネスによる強から弱へのケイパビリティ転移

問題設定

蒸留は、弱いモデルのパラメータを更新する（teacher forcing、on-policy蒸留、RLAIF）ことによって、強いモデルから弱いモデルへケイパビリティを転移します。本論文は、同様の転移がターゲットモデルへの勾配更新を一切行わず、完全に推論時に実現可能かどうかを問います。設定は以下の通りです：強い「ビルダー」モデルが、固定された弱い「ターゲット」モデルをラップする推論時ハーネス（プロンプト、ルーター、決定論的コード、フォーマット強制器、検証器）を記述します。問いかけは、ケイパビリティのギャップのどれほどが実際にはスキャフォールディングのギャップであるか、という点です。

手法

M_{\text{build}} を強いビルダー、M_{\text{tar}} を固定された弱いターゲットとします。各ベンチマーク \mathcal{D}^{(j)} に対して、著者たちは5%の検証スライス \mathcal{V}^{(j)} を切り出し、残りの \mathcal{T}^{(j)} を隠蔽します。ビルダーはエージェント型コーディングプラットフォーム（Cursor、Claude Code、またはGPT Codex）内に配置され、初期ワークスペースは \mathcal{W}_0 = \{\mathcal{R}, \mathcal{C}_{\text{demo}}, \mathcal{V}\}、すなわちルールファイル、M_{\text{tar}} の呼び出し方のデモ、および正解付き検証セットとなります。

Strong-to-Weakスキャフォールディング評価フレームワークの概要。

イテレーション k におけるビルダーのループ：

  1. スキャフォールド S_k \leftarrow M_{\text{build}}(\mathcal{W}_k) を提案・改訂する。
  2. 検証セット上で実行する：\hat{Y}^{\mathcal{V}}_k \leftarrow S_k(M_{\text{tar}}, \mathcal{V})、精度 a_k。
  3. エラーセット \mathcal{E}_k = \{(x, y, \hat{y}) \in \mathcal{V} : \hat{y} \neq y\} を収集する。
  4. ワークスペースを更新する：\mathcal{W}_{k+1} = \mathcal{W}_k \cup \{S_k, a_k, \mathcal{E}_k\}。

ビルダーが提出を行うと、最終スキャフォールド \hat{S} は実行可能なエントリーポイント f_{\hat{S}}(x; M_{\text{tar}}) としてエクスポートされ、隠蔽された \mathcal{T} 上で評価されます。重要な点として、スキャフォールドのアーキテクチャは制約されておらず、プロンプトテンプレート、ベンチマークルーター、決定論的な前処理・後処理、シンボリックソルバー、フォーマット強制器、アンサンブルがすべて許容されます。

ベンチマーク：4つのTheory-of-Mindデータセットを合計3900件に集約したもの — BigToM（1200件、二値の信念・目標・行動）、Hi-ToM（1200件、欺瞞を含む深さ0〜4の入れ子再帰）、MMToM-QA（600件、ベイズ的な目標・信念推論）、MuMA-Tom（900件、3択マルチエージェント）。主要指標：4つのベンチマークにわたる重みなしマクロ平均精度。ターゲット：GPT-5.4-mini（メイン）およびGemini-3.5-flash（対照）。ビルダーはOpus-4.7（4つの推論努力レベル）、Sonnet-4.6、GPT-5.5、GPT-5.4-mini、Codex-5.3、Gemini-3.1-Pro、Gemini-3.5-flash、Grok-0.1にわたり、各プラットフォームにつき3回複製されます — 合計72回の実行。

GPT-5.4-miniにおける参照点：バニラの直接呼び出しが 0.488、人手設計のUserHarnessが 0.939、バニラのGPT-5.4（一段階上）が 0.619。

結果

スキャフォールドを施した57回すべてのGPT-5.4-mini実行にわたって、平均マクロ精度は 0.763（バニラ比 +0.275）であり、100%の実行がno-scaffoldのベースラインを上回りました。最良の単一スキャフォールド（GPT Codex内でGPT-5.5ビルダーを使用）は 0.912 に達し、相対的な向上は86.7%となり、人手によるUserHarnessの 0.939 との差をほぼ埋め、バニラのGPT-5.4（0.619）を余裕で超えました。

GPT-5.4-miniにおけるビルダーランキング：

ビルダー BigToM Hi-ToM MMToM MuMA 平均
GPT-5.5 1.000 0.803 0.842 0.857 0.875
Opus-4.7 (x-high) 0.970 0.791 0.788 0.876 0.856
Gemini-3.5-flash 0.986 0.712 0.778 0.777 0.813
Sonnet-4.6 0.977 0.712 0.742 0.810 0.810
Opus-4.7 (high/med/low) — — — — 0.807 / 0.793 / 0.711
Gemini-3.1-Pro 0.910 0.732 0.618 0.593 0.713
GPT-5.4-mini（自己） 0.981 0.649 0.619 0.474 0.681
Codex-5.3 0.983 0.625 0.563 0.528 0.675
Grok-0.1 0.613 0.592 0.537 0.511 0.563

いくつかのパターンが一貫して確認されました：

  • ビルダーがプラットフォームを支配する。 ビルダーによる順序付けはCursor/Claude Code/GPT Codexにわたって安定しており、セル内の平均標準偏差は 0.036 と、平均向上量より一桁小さい。
  • 推論努力はビルダー内で重要。 Opus-4.7では推論努力とスキャフォールド品質のSpearman相関が \rho = 0.77 であり、low（0.711）からx-high（0.856）まで単調増加する。
  • 検証効率が高い。 検証評価回数の中央値は5回であり、検証とテストの平均ギャップは 0.021；プローブ数と精度の相関は r = 0.17 のみで、5%スライスへの過学習は見られず、より多くのプロービングによる利益もない。
  • メカニズムは認知的オフロードであり、推論時の思考量の増加ではない。 スキャフォールドの精度は、ターゲットモデルではなく決定論的なコード・ルールによって回答される項目の割合と強い相関（r = 0.72）を示す。向上は、ベンチマークごとのルーティング、構造化された述語の抽出、極性ロジックの適用、回答フォーマットの強制、貪欲デコーディングから生まれており、ターゲットにより深く考えさせたり多くサンプリングさせたりすることによるものではない。
  • 自己スキャフォールディングは弱い。 GPT-5.4-miniが自己スキャフォールディングしても 0.681 にしか達しない；正しい決定論的ソルバーを記述するにはそれを実行するよりも強い推論が必要であるため、ターゲットが固定されていてもビルダーのケイパビリティは重要である。
  • 余白が重要。 Gemini-3.5-flash（バニラ 0.761）では、UserHarnessでも 0.941 にしか向上しない；より強いターゲットをスキャフォールディングする場合、修正すべき点が少なく、正しい挙動を乱すことすらある。

残留エラーは、欺瞞を含む深い再帰的信念追跡（Hi-ToMの高次）とMMToMにおけるベイズ的目標推論に集中しており、これらはまさに明示的な決定手続きへの還元に抵抗する部分です。上位スキャフォールドでもベースラインエラーの約83%を修復しています。

限界と未解決の問い

本研究は、信念述語・観測トレース・部屋グラフのようにシンボリック抽出に特に適した構造を持つToMベンチマークに限定されています。+0.275 の向上が、決定論的オフロードが利用できないドメイン（未解決の数学的証明、未知APIのコード修復、長期的なエージェント作業）にどれほど一般化できるかは不明です。ビルダーが正解付きの \mathcal{V} に直接アクセスできるため、これは純粋な転移よりもfew-shotプログラム帰納に近く、5%のスライスは小さいながらも無視できない大きさです。人手設計のハーネスとのほぼ同等性（0.912 対 0.939）は、天井の存在を示唆しています：自動ハーネシングは人間がエンコードしたものを回復しますが、それを超えません。最後に、このフレームワークは「ターゲットのケイパビリティ」と「コントローラーへのターゲットの従順性」を混同しています — フォーマット遵守が脆弱な強いターゲットは、より従順な弱いターゲットよりもスキャフォールディングが難しい場合があります。

なぜ重要か

もしテスト時ハーネシングが重みの更新なしに構造化タスクにおける強いモデルとのギャップの大部分を回復できるとするならば、小規模モデルのベンチマークリーダーボードは実質的にハーネスを施していない下限を測定していることになり、デプロイメントにおける本質的な問いは、タスクの能力のどれほどが安価なターゲットが実行できるスキャフォールドに「コンパイル可能」かということになります。これは、ケイパビリティの引き出しを、強いビルダーによる一回限りの推論への支出として捉え直し、その後の弱いターゲットによるすべての推論に償却するものとして再定式化します。

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

Self-Geometry: GT-Free and Plug-and-Play Test-Time Adaptation for Geometrically Consistent 3D Vision Foundation Models

問題

VGGT、\pi^3、Depth Anything 3 (DA3) のような feed-forward の3D Vision Foundation Models (VFMs) は、1回の forward pass でカメラポーズ、深度、pointmap を回帰します。これらのモデルは、明示的なマルチビュー幾何学的制約（bundle adjustment は事前学習スケールでは計算コストが高すぎる）なしに、各出力をGTアノテーションに対して独立して回帰することで学習されます。その結果、予測された（ポーズ、深度、pointmap）の三つ組は、物理的に整合したシーンに対して成立しなければならない再投影/エピポーラ関係を満たすことが保証されません。Free-Geometry のような従来の test-time adaptation (TTA) アプローチは、モデルから得られる量（pointmap、features）間の暗黙的な自己整合性に依存しており、ベースとなる VFM がすでに不正確な場合には無視できる程度の修正しかもたらしません。

DA3-BaseとFree-GeometryおよびSelf-GeometryのHiRoomシーンにおける比較。

手法

Self-Geometry は暗黙的なシグナルを明示的なマルチビュー制約に置き換え、LightGlue からの2Dピクセル対応を疑似GTとして使用します。パイプラインは、Geometric Disentanglement Optimization (GDO)、Frame Angular-Neighbor (FAN) ビューサンプリング、および Lightweight LoRA-based TTA の3つのコンポーネントから構成されます。

Self-Geometryパイプラインの概要。

2つの主要な loss。 ターゲットビュー i とソースビュー j 間の対応ペア (\tilde{\mathbf{x}}_i, \tilde{\mathbf{x}}_j) に対して：

  • MVC loss (\mathcal{L}_{\mathrm{mvc}}) は点対点の再投影残差です：予測深度 \mathbf{D}_j とポーズを用いて \tilde{\mathbf{x}}_j を逆投影し、ビュー i に再投影して、\tilde{\mathbf{x}}_i との距離をペナルティとします。これはポーズと深度を同時に監督しますが、古典的なポーズ・深度の曖昧性（異なる（ポーズ、深度）のペアが同じ再投影をもたらす）に悩まされます。
  • EC loss (\mathcal{L}_{\mathrm{ec}}) は、エピポーラ線 \boldsymbol{\ell}_i = \mathbf{F}_{i \leftarrow j} \tilde{\mathbf{x}}_j（ただし \mathbf{F}_{i \leftarrow j} = \mathbf{K}_i^{-\top}[\mathbf{t}_{i\leftarrow j}]_\times \mathbf{R}_{i\leftarrow j}\mathbf{K}_j^{-1}）に対するSampson距離を用いた、深度に依存しない点対線の残差です。これはカメラポーズのみを監督し、\mathcal{L}_{\mathrm{mvc}} における曖昧性を解消します。

Gradient Disentanglement (GD)。 両方の loss は共有のポーズパラメータに作用し、それらの gradient は ETH3D における TTA イテレーションの42.4%で衝突（鈍角）します。GD は \nabla\mathcal{L}_{\mathrm{mvc}} に対して \nabla\mathcal{L}_{\mathrm{ec}} から衝突するコンポーネントを射影除去します（「ec-disentangled」方向は経験的に選択されます）。アブレーションにより方向性が重要であることが確認されており、\nabla\mathcal{L}_{\mathrm{ec}} のみの disentanglement では AUC@3 = 0.27、geometry F1 (w/o p.) = 0.60 が得られ、\nabla\mathcal{L}_{\mathrm{mvc}} の disentanglement（0.25 / 0.52）や双方向の disentanglement（0.26 / 0.59）を上回ります。

疑似対応のフィルタリング。 生のLightGlueマッチは精度0.39です。\mathcal{L}_{\mathrm{ec}} 次いで \mathcal{L}_{\mathrm{mvc}} 残差による2段階フィルタリングにより精度が0.63（再現率0.88）に向上し、下流の AUC@30 は0.37（生）から0.83へと跳ね上がります。

FAN と Lightweight TTA。 ビューは SO(3) 測地距離によってサンプリングされ、監督はスケール不変となります。LoRA adapter（rank 64、\alpha=64、すべての attention ブロックの QKV に挿入；\pi^3 ではエンコーダのみ）のみが更新されます。補助正則化項 \mathcal{L}_{\mathrm{pc}}（光度測定、\alpha=0.85 の SSIM+L1）、\mathcal{L}_{\mathrm{eds}}（エッジを考慮した深度スムーズネス）、および \mathcal{L}_{\mathrm{bdc}}（信頼度上位50%のピクセルに対するベースライン深度アンカー）が深度のドリフトを防ぎます。すべての再投影残差は \delta = 1.345 \cdot 1.4826 \cdot \mathrm{median}(|r|) でHuberロバスト化されます。最適化は cosine スケジュールで lr 5\times 10^{-5} の AdamW を用いて50イテレーション実行されます。

結果

6つの VFMs（VGGT、\pi^3、DA3-G/L/B/S）と4つのベンチマーク（7Scenes、ETH3D、ScanNet++、HiRoom）にわたって：

  • VGGTポーズ： 平均 AUC@3 は0.38 → 0.39（+3.3%）に上昇し、ETH3D では顕著な +37.3%（0.20 → 0.27）を達成。Free-Geometry は平均でわずか +2.1% に留まります。TCO は VGGT を悪化させます（平均 -15.2%）。
  • \pi^3： 平均 AUC@3 は0.45 → 0.48（+8.3%）、AUC@30 は0.90 → 0.92。TCO は \pi^3 を崩壊させ（平均 AUC@3 -91.5%）、従来の TTA の脆弱性を示しています。
  • DA3-Giant（すでに強力）：平均 AUC@3 は0.60 → 0.61（+1.5%）；より難しいHiRoomサブセットでは +3.5%。Free-Geometry はこのよく較正されたモデルでわずかに優れています（+2.4%）。
  • 弱い方の DA3-B では、Self-Geometry は ETH3D AUC@3 を +9.8% 改善します。

VGGT、π³、DA3-Giantにわたる定性的な深度と幾何誤差マップ。

シーンごとの adaptation は、ETH3D の DA3-Giant を用いた最大40入力ビューで、単一の RTX PRO 6000 上で2分未満で完了します。

限界

監督の品質は外部マッチャーによって制限されます：繰り返しテクスチャ、テクスチャのない壁、およびオーバーラップが少ないワイドベースラインペアは loss を枯渇させます。DA3-Giant（ベースラインがすでにほぼ飽和している）では、Self-Geometry が Free-Geometry を下回ることがあります（例：ScanNet++ AUC@3 -1.0% vs. +0.2%）。これは明示的な制約がすでに整合した予測をわずかに乱す可能性があることを示唆しています。レイテンシ（〜2分/シーン）はリアルタイム用途を排除します。また、本手法は \mathbf{F} を計算するために内部パラメータが復元可能であるか、VFM がそれらを同時に予測することを前提としています。

重要性

これは、3D VFMs のための TTA が、出力空間の自己整合性よりも、安価な外部対応によって監督された明示的なマルチビュー制約（再投影＋エピポーラ）から大幅に恩恵を受けることを示すクリーンなデモンストレーションです。再投影残差とエピポーラ残差間の gradient 衝突の分析は、ポーズと深度を再投影 loss に対して同時に最適化するあらゆるパイプラインにとって再利用可能な教訓です。

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

Hacker News Signals

16年前のWALリセットSQLiteバグの追跡

Source: https://tailscale.com/blog/sqlite-wal-reset-bug

Tailscaleのエンジニアたちは、稀に発生するデータベース破損の問題を、SQLiteのWAL（Write-Ahead Log）モードとWALヘッダーのリセット方法との間にある微妙な相互作用に突き止めました。このバグはSQLiteに約16年間存在しており、別のリーダーが共有ロックを保持しているものの、まだWAL indexを読み込んでいない状態でWALファイルがトランケートまたはリセットされたときに表面化します。

メカニズム上の問題：SQLiteのWALモードは、リーダーとライターを協調させるために共有メモリ領域（WAL-index、通常は .shm ファイル）を使用します。完全なチェックポイントの後にWALがリセットされると、ライターはWAL-indexのヘッダーフィールドをゼロクリアしてから再書き込みします。リーダーがゼロクリアと再書き込みの間——TOCTOUウィンドウ——でindexヘッダーのスナップショットを取得した場合、部分的に不整合なヘッダーを観測する可能性があります。具体的には、mxFrame フィールド（最大有効フレーム数）とソルト値が引き裂かれた状態で読み込まれる可能性があり、リーダーがコミット済みフレームを見逃したり、同じファイルオフセットを共有する前のWALジェネレーションのフレームを適用しようとしたりする原因になります。

再現には、マルチプロセスによるSQLiteアクセス（単一ハンドルによるマルチスレッドではなく）、WALモードの有効化、そして狭い書き込みウィンドウに当たる正確なスケジューリングが必要でした。Tailscaleのワークロード——複数のGoプロセスが協調状態のためにSQLiteデータベースを共有している——により、1操作あたりの確率は非常に低いにもかかわらず、本番環境においてこの競合状態が大規模に到達可能となっていました。

修正は、WAL-indexヘッダーが十分なメモリバリアを伴って書き込まれること、およびリーダーが読み取りロックを取得した後にヘッダーのソルトを再検証することを保証するものです。SQLiteの既存の「ヘッダーを2回読んで比較する」ロジックがこれを処理するはずでしたが——しかしバリアが欠如していたため、コンパイラまたはCPUが読み取りを並べ替え、両方の「読み取り」が同じキャッシュされた値を参照できてしまいました。

これは、ロックフリーの共有メモリプロトコルがx86上においても明示的なメモリ順序セマンティクスを必要とする理由、そしてSQLiteの信頼性に関する評判があっても、エッジケースなアクセスパターンにおける十年規模の潜在的な並行性バグを排除できない理由を示す優れたケーススタディです。

Jolt: Chez Schemeで実装されたClojureコンパイラ

Source: https://jolt-lang.github.io

Joltは、Chez Schemeの上に構築されたClojure（またはClojure互換方言）向けのahead-of-timeコンパイラです。核心的なアイデアは、Chez Schemeの成熟したネイティブコードコンパイラをバックエンドとして活用し、ClojureのセマンティクスをJVMではなくSchemeのオブジェクトモデルに変換するというものです。

技術的な背景として、JVM上のClojureはJVMの起動レイテンシ、GCポーズの特性、およびシステムレベルの作業におけるinteropの煩雑さを受け継いでいます。Chez Schemeは世代別GC、第一級継続、小規模なランタイムを備えた高度に最適化されたネイティブコンパイラを提供しており、より高速な起動を実現するClojureの基盤として有望な選択肢となっています。

コンパイラパイプラインは、Clojureの永続データ構造（PersistentVector、HAMTによるPersistentHashMap）と並行処理プリミティブ（atom、ref）をScheme表現に変換します。Clojureのマクロシステムは、マクロエキスパンダー自体をChez Scheme上で実行することでブートストラップされます。つまり、コンパイルモデルは「Clojureソースを読み込み、Scheme上でマクロを展開し、Scheme ASTを生成し、Chezのcompile-programを呼び出す」という流れになります。Schemeライブラリとのinteropは直接的ですが、Javaとのinteropは設計上存在しません。

主な未解決問題としては、Schemeの SRFI-9 またはカスタムvtable構造にマッピングされるClojureのdeftype/defrecordプロトコルディスパッチ、Schemeのdelay/`forceやカスタムサンクに自然に変換される遅延シーケンス、そしてChezのライブラリシステムの上に別個のモジュール解決レイヤーを必要とする名前空間システムなどが挙げられます。

このプロジェクトはまだ初期段階であり、Clojureのコア機能がすべて実装されているわけではありませんが、アプローチとしては技術的に健全です。Chez Schemeのレジスタアロケータとインライナーは高く評価されており、先行事例（例えば、RacketがChezSchemeを自身のコンパイラのバックエンドとして採用した件）もこの基盤の妥当性を裏付けています。言語実装に関心のある方にとって、このコードベースはゼロから書くのではなく、高品質な既存コンパイラをポータブルなバックエンドとして活用する好例です。

大規模言語モデルにおける内省的気づきの創発

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

本論文は、LLMが著者らの言う「内省的気づき（introspective awareness）」——大まかに言えば、モデルが自身の内部状態や処理について正確な信念を持つ能力——を示すかどうかを検証します。この枠組みは心の哲学の用語に影響を受けていますが、実証的な主張はより扱いやすいものになっています。

方法論としては、不確実性・知識の欠如・推論ステップに関する自己報告を引き出すよう設計されたプロンプトを構築し、それらの報告をグラウンドトゥルースとなる行動的シグナルと照合しています（例：モデルが一貫して誤答する問いに対して自信を示すかどうか）。著者らは複数のLLMを対象に、事実想起・多段階推論・反事実的タスクにわたってテストを行っています。

定量的な結果によれば、大規模なモデルほど自己報告のキャリブレーションが優れており——表明された不確実性が実際のエラー率とより強く相関する——ものの、この相関は絶対値として依然として弱いです。上位モデルでさえ、表面的な馴染みのある領域では系統的な過信を示します。本論文はこれが「創発的（emergent）」であると主張しており、その根拠として、小規模モデルでは自己報告のキャリブレーションがほぼゼロに近いのに対し、大規模モデルでは統計的に有意ではあるものの控えめな正の相関が見られることを挙げています。

解釈上の主張——これが真の内省を構成するというもの——は哲学的に過剰な意味を帯びており、論文の枠組みは測定結果が示すものをやや誇張しています。実際に測定されているのは、言語化された確信のbehavioralなキャリブレーションであり、内部状態へのアクセスではありません。モデルは自身の重みやactivationへの特権的なアクセスを持っておらず、他のあらゆることと同じメカニズムを用いて自己についてのトークンを予測しているにすぎません。それが「内省」を構成するかどうかは、その用語をどう定義するかに完全に依存しており、本論文はその問いに決着をつけていません。

より具体的に有用な点として、自己報告された確信が下流のエラー検出に対して弱いながらも非自明な予測シグナルであるという知見があり、これはモデル自身の不確実性推定をルーティングや棄権シグナルとして活用するLLMパイプラインの構築に実践的な示唆を与えます。

AIボットを詐称した大規模な脆弱性スキャンが実施されている（ClaudeBot等を模倣）

Source: https://knownagents.com/insights

本レポートは、既知のAIクローラー識別子（ClaudeBot、GPTBot、anthropic-aiなど）に合致するUser-Agent文字列を提示しながら、正規のWebクローラーではなく脆弱性スキャナーに特有の挙動を示すHTTPトラフィックのパターンを記録したものです。具体的には、CVE固有の既知パス（例：/wp-admin/、/.env、/actuator/health）へのアクセス、非公開APIエンドポイントへの探索、そしてインジェクションテストに関連するペイロードの送信が確認されています。

技術的なメカニズムは単純です。特定のUser-Agent文字列が宣言された送信元に対応することを強制する仕組みは存在しません。正規のAIクローラーは、コンテンツのインデックス化を望むサイト管理者によって一般的に通過を許可されています。これらの文字列を詐称することで、スキャナーは既知のクローラーをホワイトリスト登録している単純なボット検出ルールを回避できる可能性が高まります。

悪意のあるトラフィックを区別するいくつかの指標があります。IPレンジがAnthropicやOpenAIインフラの公開ASNブロックと重複していないこと、リクエストパターンがリンクを辿るのではなく順次パスを列挙していること、そしてTLSフィンガープリント（JA3/JA4）が正規のブラウザベースまたはcurlベースのクローラーが生成するものと異なっており、カスタムツールの使用が示唆されることです。

緩和策は限られています。公開されているクローラーIPレンジに基づくIPホワイトリスト登録が最も堅牢な防御策ですが、最新のリストを維持し続ける必要があります。JA3/JA4フィンガープリントフィルタリングも有効ですが、手間をかければ回避可能です。より根本的な問題は、「既知のAIクローラーを許可する」という業界慣習が悪用可能なトラスト・シグナルを生み出している点にあります。

これは慣習の悪用という典型的な攻撃手法です。新たな技術は一切必要とせず、User-Agent詐称はHTTPと同じくらい古い手法ですが、AIクローラーのホワイトリスト登録が広く適用されるルールとして定着したことで、新たな効果的な回避ベクターが生まれています。サーバー管理者にとっての運用セキュリティ上の示唆は次の通りです。User-Agentのホワイトリスト登録を、機密性の高いパスに対する実際のアクセス制御と混同してはなりません。

RustのAPIを使った浮動小数点演算の高速化

Source: https://pythonspeed.com/articles/faster-float-math-rust/

本記事では、Rustにおける f32::midpoint および関連する数値的に健全な浮動小数点ユーティリティの安定化、そしてより実質的な内容として、std::intrinsics::fadd_fast ファミリーと、unsafe を使わずにIEEE緩和セマンティクスをオプトインできる新しい安全なラッパー（明示的丸めモードを伴う f32::add）について解説しています。

核心的な問題は、Rustはデフォルトで（-ffast-math なしの -O2 のCと同様に）厳密なIEEE 754セマンティクスを保持するという点です。これにより、コンパイラは (a + b) + c を a + (b + c) に再結合したり、a * b + c をFMAに縮約したり、x - x == 0 を仮定したりすることができません。これらの制約は、SIMDレーンがリダクションの順序を変えてしまうため、多くのループにおける自動ベクトル化を妨げます。

新しいAPIとして、f32::midpoint(a, b) は恒等式 a + (b - a) / 2 を用いてオーバーフローなしに (a + b) / 2 を計算し、素朴な中点計算のオーバーフローバグを回避します。パフォーマンスの観点でより影響が大きいのは、f32::mul_add（融合積和演算、x86 AVXでは単一の VFMADD 命令にマッピング）の明示的な利用可能性と、ブランケットな unsafe ブロックなしに特定の演算を再結合安全として注釈付けできる、演算ごとの「fast」フラグの継続的な安定化です。

記事中のベンチマーク結果では、コンパイラが緩和された結合律でベクトル化できる場合、float配列に対するリダクションループのスループットが2〜4倍改善されることが示されており、これはスカラーだったループに対して256ビットAVX2 SIMD（1レーンあたり8つのfloat）から期待される結果と一致しています。

制限として、Rustのアプローチは単一フラグであるGCC/Clangの -ffast-math よりも依然として粒度が細かい点があります。数値カーネル全体が緩和されたセマンティクスを必要とする場合、演算ごとの注釈はスケールしません。#[allow(clippy::float_arithmetic)] エコシステムや fast-floats のようなクレートが回避策として使われてきましたが、モジュールレベルまたは関数レベルの緩和セマンティクス属性は、stable Rustにはまだ存在しません。

Qwen3.8-2.4T

Source: https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B

Qwen3.8-2.4Tは、AlibabaのQwen3リリースにおける最大のモデルです。総パラメータ数2.4兆、1回のforward passあたりのアクティブパラメータ数950億（“A95B”の由来）というMixture-of-Expertsアーキテクチャを採用しています。このモデルはexpert FFN層に対する標準的なtop-k tokenルーティングを使用しており、各transformer blockには共有attention headとルーティングされるFFNが含まれ、トークンごとにexpertの一部のみが活性化されます。

2.4T/95Bという比率は、k=1の場合に1層あたり約25個のexpertを持つか、あるいは同様のsparse構成を意味しており、MoEがトークンあたりの計算量を増やさずに総パラメータ数（すなわち記憶容量と知識のカバレッジ）を高速にスケールさせることを可能にするというスケーリング則の動機と整合しています。学習計算量はアクティブパラメータ数に支配されており、総パラメータ数ではないため、推論時に95BアクティブというのはFLOPs-per-tokenの観点からdenseな約95Bモデルにほぼ相当します。

公式に発表されているbenchmark結果は、コーディング（HumanEval、LiveCodeBench）、数学（AIME、MATH-500）、instruction followingにわたって優れており、リリース時点でいくつかのbenchmarkにおいてGPT-4oおよびClaude Sonnetと競合または上回ると報告されています。本モデルは「thinking」モード（budget tokenを用いた拡張chain-of-thought）と標準モードの両方をサポートし、system promptによって切り替えられます。

実際のデプロイは容易ではありません。bf16での2.4TパラメータはGPUメモリを約4.8 TB必要とし、マルチノードのtensor parallelismまたは積極的な量子化（INT4では約1.2 TBに削減されるが、それでも大規模なクラスターが必要）を必要とします。Hugging Faceのモデルカードには、フル精度版と量子化版の両方が提供されていると記載されています。ほとんどの実務者にとって、より小さなQwen3バリアント（30B-A3B、235B-A22B）が現実的な運用上の選択肢であり、2.4Tは能力の上限を示すbenchmarkとして存在しています。

GoはAI支援ソフトウェアエンジニアリングに理想的な言語である

Source: https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/

GoogleのGoチームは、GoのデザインプロパティがLLMベースのコード生成・編集に対して特に扱いやすいと主張しています。この記事は利害関係者によるものですが、技術的な議論には実質的な内容が含まれています。

中心的な主張はいくつかの特性に基づいています。まず、Goの文法は小さく規則的（25個のキーワード、演算子オーバーロードなし、暗黙の型変換なし）であり、LLMが構文的・意味的に有効な生成を行うためにモデル化しなければならない領域を縮小しています。次に、gofmtが単一の正規フォーマットを強制することで、training dataおよび生成出力におけるスタイルのばらつきを排除しており、モデルはプログラム構造ごとに一つの表現のみを見ることになります。第三に、Goの型システムは明示的ではあるものの、RustやHaskellほど複雑ではないため、型正確な生成の達成と検証が容易です。第四に、標準ライブラリとimportグラフは明示的かつ自己完結的であり、ファイル外のコンテキストを必要とするヘッダファイルやビルドシステムの複雑さがありません。

より興味深い技術的な点はリファクタリングに関するものです。Goのツールチェーンは明確に定義されたASTと型情報API（go/ast、go/types、golang.org/x/tools/go/analysis）を公開しており、LLMが生成したコードを修正・検証する決定論的な後処理パスを記述することが容易になっています。構文的に有効なGoのLLM出力は、即座にパース・型チェック・静的解析を密なループで行うことができ、複雑なビルドシステムを持つ言語では構築が難しい生成-検証パイプラインを実現します。

この議論の限界として、LLMはすでに不規則な構文にもかかわらずPythonやTypeScriptで高い性能を発揮しており、生成品質の要因としては言語の規則性よりもtraining dataの量が支配的であることが示唆されています。Go固有のツーリングの利点は実在しますが、主にツール支援のワークフローに関連するものであり、素の生成品質には直結しません。この投稿はGo擁護の側面も持ちますが、エージェンティックなコーディングループにおけるツールチェーンの内省可能性に関する根本的な指摘は技術的に妥当です。

Launch HN: Discovered Materials (YC P26) – AI agents to discover new materials

Source: https://discoveredmaterials.com/research/

Discovered Materialsは、自律型AIエージェントを計算材料探索に応用しており、仮説生成からDFT（密度汎関数理論）計算、構造予測、合成実現可能性評価に至るパイプライン全体を対象としています。

技術的なワークフローは、確立された計算材料科学のスタックに従っています。まず構造生成（ランダムサーチ、進化的アルゴリズム、または結晶構造空間上の生成モデルなどの手法を使用）を行い、続いてVASPやQuantum ESPRESSOなどのコードを用いたDFT緩和によって基底状態のエネルギーを求め、競合相の凸包に対して安定性を評価します。エージェント層はこれらの計算コストの高いステップを統括し、優先すべき候補構造を決定し、結果を解釈して次の実験を提案します。これは材料分野に適用された標準的な active learning ループです。

MLコンポーネントとしては、高コストなDFT計算の前に安価な事前スクリーニングを行うためのグラフニューラルネットワーク原子間ポテンシャル（例：MACE、CHGNetなど）、および構造提案のための生成モデル（DiffCSPやCDVAEのような結晶構造上のdiffusion）が含まれていると考えられます。HNのコメントではベンチマークターゲットについて質問があり、チームはバッテリー電解質と触媒を初期ドメインとして挙げています。これらはイオン伝導率や吸着エネルギーといった明確に定義された計算上の適合度指標を持つ、高付加価値なターゲットです。

主な技術的課題は、計算予測と実験的合成の間のギャップです。凸包上でのDFT安定性は合成可能性を保証するものではなく、エージェントは合成経路、前駆体の入手可能性、および現実的な条件下での熱力学的到達可能性について推論する必要があります。このループを閉じるには、実験的フィードバック（コストが高い）または実験データベースを用いて学習した合成実現可能性モデル（依然として未解決の研究課題）のいずれかが必要です。

より広い競合空間（Google DeepMindのGNoME、MicrosoftのMatterGen、同様のスタックを使用する学術研究グループ）は競争が激しいため、差別化はおそらく新規MLアーキテクチャではなく、ワークフローエンジニアリングとドメイン特化型fine-tuningによるものになるでしょう。

Noteworthy New Repositories

drumih/turbo-fieldfare

Apple Silicon上でGemma 4 26B-A4Bを約2 GBのRAMで動作させるプロジェクトです。重要な洞察は、Gemma 4の26B-A4Bバリアントが、forward passごとに4BパラメータのみがアクティブになるMixture-of-Expertsモデルであるという点です。turbo-fieldfareはこのスパース性を利用し、非アクティブなexpertの重みをメモリ上に展開しないようにしています。ランタイムはMetalを通じてMシリーズのunified memoryをターゲットとしており、アクティブなexpertシャードのみを常駐メモリに保持し、非アクティブなものはディスクからストリーミングするかページアウトした状態に保ちます。PyTorchもHugging Faceスタックも使用せず、推論パスはフレームワークのオーバーヘッドを排除した軽量なC/Metal実装です。ワークステーション用GPUや大容量RAMなしに高性能なMoEをローカルで動かしたい実践者にとって、これは実際の空白を埋めるものです。既存のローカル推論ツールの多くは、スパース性に関わらず完全なパラメータテンソルを読み込んでしまいます。本プロジェクトは初期段階ですが、アーキテクチャの選択（MoE + 積極的なexpertオフローディング）は技術的に合理的であり、RAMの数値がなぜこれほど低いかを直接説明しています。コンシューマ向けハードウェア上でスパースモデルの推論を構築する方々にとって、参考実装として有用です。

Source: https://github.com/drumih/turbo-fieldfare

FareedKhan-dev/kimi-k3-in-c

Kimi K3（名目上は2.78兆パラメータのMoEモデル）をスクラッチから実装したC99推論エンジンであり、単一のCPU上で約8 GBのRAMで動作します。このアプローチは精神的にllama.c/llama2.cを踏襲しており、BLAS・LAPACK・CUDA・フレームワークへのリンクは一切なく、ポータブルなCコードに手書きの行列カーネルと積極的な量子化（おそらくINT4/INT8の重みパッキング）を組み合わせることで、アクティブパラメータのワーキングセットを圧縮しています。このスケールのMoEでは、メモリ常駐のフットプリントはパラメータ総数ではなくトークンごとのアクティブなエキスパート数によって支配されるため、非アクティブなエキスパートをメモリマップしてオンデマンドでページングすれば、8 GBという数字は十分に妥当です。このプロジェクトの価値は教育的・移植性指向にあります。単一ファイルまたは最小構成のC99アプローチは、Cコンパイラさえあれば任意のPOSIXシステムでコンパイル可能です。組み込みやエアギャップ環境での推論パイプラインを構築する実務者や、すべての演算を監査したい研究者にとって、抽象化レイヤーが存在しない点は大きな利点となります。また、ベンダーライブラリを一切使わずに純粋なCPUバウンドのハードウェア上でMoEのスパース性をどこまで活用できるかを検証するストレステストとしても機能します。

Source: https://github.com/FareedKhan-dev/kimi-k3-in-c

i3T4AN/KADATH

KADATHは、エージェントの改善を集団ベースの最適化ループとして定式化する、進化的マルチエージェントランタイムです。各エポックでは、自律エージェントの集団がインスタンス化され、指定されたゴールに紐づけられた適応度関数に対して評価された後、選択・突然変異・交叉演算子が適用されることで次世代が生成されます。エポックはシード付き状態によって再現可能であり、進化的実行間のアブレーションや比較を可能にします。このアーキテクチャは、エージェントの基盤（ツール使用・環境インタラクション）と進化的コントローラー（選択圧・遺伝的演算子）を分離しており、コアループがモデル非依存であることを意味します。これは、標準的なRLHFやprompt最適化よりも、エージェント行動に適用されたニューロ進化・quality-diversity探索に近いアプローチです。関連する先行研究としては、OpenAIのPOET、AutoML-Zero、および各種LLMベースの自己改善ループが挙げられますが、KADATHのエポック再現性への明示的な注力は、研究用途における実践的な差別化要因となっています。未解決の問題としては、適応度関数の指定方法、突然変異演算子がprompt・重み・ツール設定のいずれに作用するか、そしてエージェントのロールアウトがコスト高の場合のスケーラビリティなどが挙げられます。

Source: https://github.com/i3T4AN/KADATH

Paritok-official/paritok-4b-v1

エージェント型コーディングセッション向けに特化して設計された、コンテキスト圧縮ゲートウェイです。中核となるメカニズムは、4Bパラメータのコードネイティブモデルであり、エージェントの会話履歴をより高密度な表現に書き直すことで、意味的に重要なコンテンツを破棄することなくトークン数を削減します。報告されている圧縮率は、ターン1で25%から始まり、長いセッションやコンテキストが飽和したセッションでは85%以上にまで累積するとされており、コンテキストウィンドウあたりの有効ターン数が3倍に増加すると主張されています。本システムは透過的なプロキシとして動作し、エージェントはBASE_URLをドロップイン置換する形で通信するため、Claude Code、Cursor、Codex、OpenHandsはコードを変更する必要がありません。技術的には、要約（損失あり・タスク非依存）とロスレスなトークン化トリックの中間に位置しており、コードおよびツール呼び出しのトレース上で専用に学習されているため、汎用の要約器が脱落させてしまう識別子名、関数シグネチャ、エラーメッセージを保持します。4Bというモデルサイズにより、推論レイテンシがターンレイテンシ全体を支配しない程度に低く抑えられています。主な未解決の問いは、忠実度と圧縮率のトレードオフです。すなわち、後半のターンにおける積極的な圧縮が、下流のエージェントにとって重要なコンテキストの喪失を引き起こす頻度はどの程度か、またそれをどのように測定するか、という点です。

Source: https://github.com/Paritok-official/paritok-4b-v1

alikon-art/DeterminFlow

AIパイプライン向けのプロダクション指向ワークフローランタイムであり、軽量なチェーンライブラリ（LangChain、シンプルな非同期キューなど）と重量級のオーケストレーションプラットフォーム（Airflow、Prefectなど）の中間に位置づけられます。「determin」というネーミングは決定論的な実行セマンティクスを強調しており、ワークフローは型付き入出力を持つ明示的なDAGとして定義され、ランタイムは各ノードの動作が検証された後にのみ実行を進めることを保証します。リカバリは第一級のプリミティブとして扱われており、ノードは障害モードを宣言し、ランタイムはパイプライン全体を最初からやり直すことなく、チェックポイント・リトライ・迂回処理を行うことができます。これは、LLMの呼び出しコストが高く、部分的な障害からの回復によって大幅なコスト削減が見込める長時間稼働のエージェント型ワークフローにとって重要です。本ランタイムは、埋め込みライブラリとしてではなくサービスとして（HTTPまたはgRPCインターフェース経由で）デプロイすることを想定しており、ワークフロー定義のバージョン管理と独立した監視が求められるマルチチーム環境に適しています。LangGraphや類似ツールとの主な差別化要因としては、実行前の明示的なバリデーションパス、組み込みのリカバリポリシー、およびサービスファーストのデプロイモデルが挙げられます。実際の信頼性保証を評価するには、チェックポイントストアと障害検知の実装を詳しく調べる必要があります。

Source: https://github.com/alikon-art/DeterminFlow

dinosn/fastjson-jsontype-rce-lab

fastjsonのデシリアライゼーションRCEチェーンを学習・防御するための自己完結型Dockerラボ環境であり、2つの異なる脆弱性クラスをカバーしています。1つ目は、@JSONTypeリソースプローブガジェット（CVE-2026-16723として追跡）を介したfastjson 1.x（バージョン1.2.66〜1.2.83）を対象としています。2つ目は、fastjson2 2.0.57のバイパスを実証するもので、ポリモーフィック型アノテーション（@JSONType(seeAlso)およびJacksonの@JsonSubTypes）を悪用してポリモーフィズム解決パスを通じてクラスロードを密輸することで、autoTypeが明示的に無効化されていても攻撃者が制御する@typeがloadClassに到達できることを示します。ペイロードはマーカーのみ（実際の武器化されたシェルコードなし）であるため、防御ツールの開発に安全に使用できます。また、このリポジトリには脆弱なパターンを検出するスキャナーも同梱されています。safeModeおよびJDK17の制御が緩和策として文書化されており、JDK17における特定のリフレクションアクセスパスの削除が一般的なJNDI/classloaderガジェットを無効化するため、特に有用です。fastjson 1.xから2.xへアップグレードする際にautoType無効化のデフォルト設定で十分と仮定していた場合も含め、信頼されていないJSONを消費するJavaサービスを監査するセキュリティエンジニアにとって価値があります。

Source: https://github.com/dinosn/fastjson-jsontype-rce-lab

yc-software/qm

YCombinatorが構築・運用する、人間とAIエージェント間の作業を協調させるためのマルチプレイヤーエージェントハーネスです。技術的な基盤は共有タスク／状態環境であり、複数のエージェント（および人間のオペレーター）に作業項目を割り当て、互いの進捗を観察し、ハンドオフやエスカレーションを行うことができます。ここで言う「マルチプレイヤー」とは、ターンベースのシングルユーザーチャットではなく、並行かつ永続的なセッションを意味しており、チャットボットよりも協調的なOSプロセスモデルに近い設計です。このハーネスはエージェントのライフサイクル管理（スポーン・監視・終了）、タスクルーティング（どのエージェントがどのサブタスクを担当するか）、および結果の集約を管理します。エンジニアリングチームにとっては、単一のコーディングタスクが並列化可能なサブタスクに分解され、異なる専門エージェント（または人間のレビュアー）が同時に処理できるようなシナリオに適しています。YCというプロベナンスから、実際のスタートアップのワークフローで実戦的に検証されていることが示唆されます。状態同期メカニズム、エージェント間通信プロトコル、および障害処理に関する技術的詳細は、これをインフラとして評価する上での重要な未知事項です。https://qm.ycombinator.com からアクセス可能です。

Source: https://github.com/yc-software/qm

fuxicodex/Fuxi

コスト認識型LLMルーティングに重点を置いた、ターミナルネイティブなAIコーディングエージェントです。FuxiはCLIプロセスとして動作し、ファイルの編集、シェルコマンドの実行、ツールの直接呼び出しをターミナル環境内で行えるエージェントループを提供します。IDEプラグインもブラウザUIも不要です。特徴的な機能はコスト認識型ルーティングです。エージェントはモデルのコストテーブルを管理し、推定タスク複雑度とユーザー定義のコスト予算に基づいて、設定済みのLLMプロバイダー間で動的に選択を行います（例：単純な編集は安価なモデルへ、複雑なリファクタリングはより高性能なモデルへルーティング）。これは、単一のプロバイダーをハードコードしたり、手動でのモデル選択を必要とするツールとはアーキテクチャ上明確に異なります。自己完結型であるため、エージェントの状態はすべてターミナルセッション内に保持され、LLM API自体以外の外部サービスへの依存がありません。これは、エアギャップ環境やセキュリティに敏感な環境において重要です。高速な起動と最小限のフットプリントにより、シェルスクリプトやCIパイプラインとの組み合わせも容易です。AiderやClaude Code CLIと比較した場合の主な差別化要因は、マルチプロバイダーのコストルーターです。ルーティング判断におけるタスク複雑度の推定方法については、実装の詳細を詳しく検討する価値があります。

Source: https://github.com/fuxicodex/Fuxi