AI論文 2026-09-08

★ ハーネスかモデルか:汚染制御した非公開スイートでエージェント型コーディングのハーネス効果を分離する

コーディングAIの性能差が使用モデルの違いによるものか周辺ツール構成(ハーネス)の違いによるものかを切り分けた検証研究

言語モデルとharness(ツール・プロンプト・制御フロー)の組み合わせについて、ベンダー純正の組み合わせが有利という想定を、汚染管理された256タスクの私設スイートで同一モデルのペア比較により検証したとしている。Opus 4.8ではharness間の平均差-1.25pp(48.8%対50.0%)、GPT-5.5では+1.25pp(55.6%対54.4%)で明確な優位は確認されなかったが、Opusの結果はリポジトリタスクで純正harnessが9.0pp劣り、コンテストタスクで23.7pp優るという相反する内訳の合成だったとしている。壁時計上限で打ち切られた81件中22件は既に正解パッチを生成しており、使用量から再計算するとneutral harnessのコストはOpus 4.8で1.3〜1.6倍、GPT-5.5で1.2倍だったと報告している。

★ ResidualAuth:失効可能な委任下で言語エージェントが保持すべき認可状態とは

ツール利用エージェントの権限委任・失効管理で、どの認可情報を保持すべきかを理論的に分析した研究

ツール使用エージェントの委任・失効可能な権限について、同一の現在権限・同一の到達可能性を持ちながら、同じ直接エッジの失効後に正反対の判断を要する認可履歴の対が存在することを示し、これを区別するのに必要な情報を「残差認可状態」として定式化したとしている。指数関数的に多くの将来区別可能な状態が1つの推移閉包を共有しうることを証明し、4つのオープンウェイトモデルで、固定256トークン要約は16ペア中0-2ペアしか解けず、認証された現在クエリ読み取りは15-16/16解けたと報告している。オンラインメモリ診断では、正確な台帳シリアライゼーションは128ペア全てに適合したが、モデル記述メモリは最大1/128ペアしか解けず、ハードゲートにより8件の無認可効果がゼロになったとしている。

★ 失効しても権威が残る:エージェント記憶システムにおける失効反映の実証研究

エージェントの記憶システムで、無効化(訂正)された情報が検索時に排除されずに使われてしまう問題を測定した研究

長期稼働する言語モデルエージェントが依存する永続的メモリでは、矛盾する事実を無効とマークして保持する「ソフト失効」が使われるが、それが検索時に強制されるかは未検証だったとしている。5つのエージェントメモリシステムに失効したポリシーとその置き換えを与え、9つのシナリオと9つのモデル、6つの防御条件下で、失効した事実が検索で返るか、エージェントがそれに基づき行動するかを測定した結果、失効ラベルが検索層から見える限りどのシステムもデフォルトでは失効を強制せず、失効事実が返され置き換えより優先され、エージェントを安全でない行動に導いたと報告している。これを踏まえ、失効・矛盾するレコードを保留するガードを開発したとしている。

削除は何を破壊するか:エージェント記憶における忘却の復元反実仮想監査

容量制限で記憶から情報を削除した際に生じた誤りが、復元すれば直るのかを検証した研究

固定トークン予算を超えた際にエージェントメモリが履歴を破棄する場合、既存の予算対精度指標は削除による不可逆的損失と回復可能な検索失敗を区別していなかったとしている。質問ごとに正解根拠を読み取り時コンテキストに再挿入して読み手を再実行する「復元反実仮想」により各誤りを回復可能・不可逆・残存に分類し、LongMemEval-Sで4つの削除方針(FIFO・ランダム・冗長性考慮・LLM重要度)を評価。上位k検索・80kトークン予算では、復元で修正された誤りのうち不可逆な割合はFIFO・ランダム・冗長性考慮で0.67-0.73、LLM重要度で0.60、8kトークンでは全方針で1.00に達したと報告している。精度を揃えたペア間では不可逆率に1.2〜6ポイントの分解能で差は検出されなかったとしている。

信頼できない進捗バー:LLMエージェントはタスクの進捗を正しく報告できるか

AIエージェントが作業途中で自己申告する進捗報告の正確さを段階ごとに検証した研究

大規模言語モデルが出すタスク進捗信号をエージェントフレームワークが継続・停止判断に用いるが、モデルがタスクの全段階で進捗を確実に報告できるかは体系的に研究されていなかったとしている。公開ベンチマークτ2-benchと、報告チェックポイントをライフサイクル全体に配置した独自テストベッドStageIFで評価した結果、報告の信頼性はタスクが到達した段階に依存し、試験したほぼ全モデルがある段階では信頼できても別の段階では信頼できなかったと報告している。多くの既存モデルは作業開始後に精度が落ち完了時に回復する一方、最新世代モデルはその中盤の落ち込みは解消するが完了直前でむしろ保守的になる傾向を示したとし、エージェントフレームワークはモデル自身の状態報告のみに基づいてタスクフローを制御すべきでないとしている。

メニューは実行の事前情報である:オンラインエージェントのための状態経路型ツールメニュー

大量のツール群から、タスク実行に必要な順序を考慮して少数のツール候補を提示する選択手法

数千のツールを含むライブラリからエージェントに実行前に提示される短く順序付けられたツール部分集合を「ツールメニュー」と定義し、既存の構築法はリクエストとの関連度でランク付けするため目立たない生成元ツールを見落とすことがあるとしている。観測可能な状態から目的の結果への実行前経路「状態パス」を学習するState-Path Tool Menuを提案し、ToolBenchでこのメニューはオンライン成功率を0.737から0.898に引き上げ、検索・再ランキング・生成・ルーティングの各ベースラインをエージェントを変更せずに上回ったとしている。同メニューは32ツールで公式リスト128ツールより完全な連鎖を多くカバーし、成功率の向上は実行モデルの能力が異なっても持続したとしている。

CIVI:行政情報における検索エージェントの失敗を診断するフレームワーク

LLM検索エージェントが行政・公共サービス情報を調べる際の誤りの原因を分類・診断する評価手法

公共部門で展開される大規模言語モデルは誤った案内が不可逆的な害を招きうるとして、市民情報における検索エージェントの失敗を診断する枠組みCIVIを導入したとしている。ベンチマークは国・州・地方の複数管轄の政府文脈と国連基準に基づく機能カテゴリをカバーし、10の検索エージェントを評価した結果、注意深い人間のベースラインに一致するものは無かったと報告している。CIVIは精度に加え検索呼び出し率、検索なしでの選択的正答率、政府情報源の引用頻度を測定し、失敗を4つの排他的モードに分解する手法ARISEを導入、観測された失敗の72.1%はモデルのパラメトリック知識の欠如ではなく検索に起因するものと分類されたとしている。

APIベンチマークのスコアはチャットボットのインターフェースに確実には反映されない

API経由の性能評価とチャットアプリ経由の実際の挙動にずれがあることを、ChatGPT等で検証した研究

APIで測定したモデル性能が実際に展開されたシステムの挙動を忠実に反映するという前提を、ChatGPT・Claude・Geminiの7システムと9つのベンチマークで監査したとしている。API評価はインターフェース評価より平均して精度で3.4ポイント、再テスト一致率で2.1ポイント高く、系統的な差があったと報告している。ChatGPTでは、APIとインターフェースのアクセス方式間の性能差が、APIのみで比較したGPT 5.3とGPT 5.4の差を上回ったとし、アクセス経路の切り替えがモデル世代を1つ下げるのと同程度の性能低下をもたらしうるとしている。システムプロンプトやサンプリングパラメータ、推論設定を変えても、挙動は一部変化するのみでギャップは確実には解消されなかったとしている。

Code-to-Harness:自己対戦からブラックボックス最適化器を蒸留する

AIが試行錯誤で書いたコードから数値最適化の戦略を短いテキスト指示として抽出し他モデルに転用する研究

エージェントが実行を通じて数値探索戦略を学習し、それをテキストとして転用できるかを、既存の言語モデル単体では強力な古典的最適化手法に及ばない低予算ブラックボックス最適化で検証したとしている。開発中にエージェントは最適化プログラムを繰り返し記述・評価し、得られたプログラムと練習記録を197語のharness Aに蒸留、評価前に固定した。Harness AはN=30の独立研究でGemini Flashのregretを48%削減し(p<.001)、未見の3つのBBOBランドスケープ全てでregretを低下させ、Claude Sonnetにも転用してregretを43%・49%削減した(p≦.005)としている。独立した再現実験では別プログラムのHarness Bが同程度の性能を示し、同じ枠組みは非公開のYouTube報酬調整ベンチマークでも最小のregretを達成したとしている。

コーディング中の独り言:コメントは何がコード生成に役立つのか

LLMがコード生成時に書くコメントが、実際の性能向上にどう寄与するかを分析した研究

大規模言語モデルがコード生成中に出す自然言語コメントは後続コード生成のコンテキストの一部となるが、コメントのどの性質が性能に影響するかは不明だったとしている。LiveCodeBenchでの観察分析ではコメントの頻度や大まかな意図はpass@1を確実には予測しなかったとし、強いモデルが書いたコメントを弱い受け手モデルに事前挿入して表面形式と解法内容を分離した結果、テストに通った解法由来のコメントは受け手のpass@1を平均17.2%引き上げた一方、失敗した解法のコメントには確実な効果がなく、別問題向けのコメントはpass@1を20.8%低下させたと報告している。多様なモデル・プロンプトの下でほとんどの受け手モデルは外部コメントの効果を再現できず、最良でも24%しか回復しなかったとしている。