2026年10月9日、Google Cloud AI Researchは北西大学と共同で、arXivに論文「Harness²: Recursive Agent Harnessing for an Open World」を発表し、コードも同日にApache 2.0ライセンスのもとGitHubでオープンソース公開された。論文の核心的な結論は次のとおりだ。モデルの重みを完全に凍結した状態で、モデルを包むスキャフォールド——システムプロンプト、ツール、メモリ、サブエージェントなど8つのコンポーネント——を再帰的に最適化することにより、WorkBuddy-BenchにおけるGLM-5のスコアが64.2から75.7へと単一ステップで11.5ポイント向上した。また、Harvey法律ベンチマーク（LAB）ではGemini 3.5 Flashが11.8ポイント向上し、専門タスクベンチマーク（JobBench）ではGeminiが4.5ポイント（31.5→36.0）向上した。論文公開から約2週間で、コードリポジトリにはおよそ6,600のGitHub Starが集まっている。
これらの数字が本当に衝撃的なのは、絶対的な向上幅にあるのではなく、モデル間比較が明らかにした構造的な事実にある。同一のエグゼキューター「OpenCode」のもとで、自己改善スキャフォールドを使用したGLM-5（75.7点）が、デフォルトスキャフォールドを使用したGemini 3.5 Flash（72.4点）を上回ったのだ。つまり、能力的には相対的に劣る基礎モデルが、より優れた「ラッピング」によってベンチマーク上でより強力な基礎モデルを打ち負かしたことになる。同様の逆転現象は、別のエグゼキューター「Codex」のもとでも確認されている（75.3 vs 74.5）。これは例外的なケースではなく、3つのベンチマーク・4種類のモデル＋スキャフォールド構成にわたって繰り返し確認された系統的な現象だ。
8つのファイル、2層の再帰、重みには手を触れない
Harness²の動作原理を理解するには、まずこのフレームワークが定義する「スキャフォールド」を明確にする必要がある。Harness²はエージェントのスキャフォールドを8つの編集可能なランタイムファイルに分解する。すなわち、システムプロンプト、ガードレール（guardrails）、メモリ、スキルライブラリ、ツールガイダンス、スクリプト、サブエージェント、そしてミドルウェアプラグインである。モデル自体は一切変更されず、すべての最適化はこの8つのファイルに対して行われる。
最適化メカニズムは、入れ子になった2つの再帰層で構成される。第1層はタスクレベルの再帰だ。タスクを実行するたびに、スキャフォールドエディタはまず基本スキャフォールドでタスクを一度実行して参照実行トレースを取得し、次に2種類の候補変更を生成する。一方は領域横断的な汎用エージェントの弱点（計画立案、ツール呼び出し、タスク委任）に対応するもので、もう一方は現在の領域固有の知識とプロセスを含むものだ。両方の候補バージョンは同一のタスク設定のもとでプローブ実行され、変更の効果は「正解との照合」ではなく「行動比較」によって評価される。つまり、変更によって実際にターゲットとした行動が変化したかどうかが検証される。最終的に、シンセサイザーが有効な変更を新しいスキャフォールドに統合する。
この「Propose-Probe-Compose」の3ステップサイクルは、実際の展開における難題を解決している。現実世界のタスクには通常、直接比較できる正解が存在しない。従来の再帰的自己改善スキームは報酬関数や人手によるアノテーションに依存しており、オープンドメインへの展開時にしばしば機能しなくなる。Harness²は真値検証の代わりに行動比較を用いることで、この制約を回避している。
第2層はスキャフォールドレベルの再帰だ。タスク完了後、リフレクターが今回採用された変更と証拠に基づく教訓を永続的な「改善スキャフォールド」ライブラリに書き込む。後続のタスクは依然として同じ基本スキャフォールドから出発するが、提案フェーズではこの蓄積された経験ライブラリを参照するため、改善提案が使用時間とともに収束していく。論文の設計では、スキャフォールドのエディタ自体にはAnthropicのClaude Opus 4.8をOpenCodeフレームワーク上で使用し、評価対象となる凍結されたエグゼキューターにはGemini 3.5 FlashとGLM-5が使用されている。
ツール呼び出しエラー率が36.8%低下——これが企業ユーザーが最も気にする数字だ
学術ベンチマークのスコア差は数字遊びと見なされがちだが、Harness²は重みの更新なしにツール呼び出しエラー率を最大36.8%低下させた。ファイル操作、コード実行、データベースクエリ、API呼び出しなどの実際のタスクをAIエージェントに依存している企業にとって、ツール呼び出しの失敗コストは現実的なものだ。それはタスクの中断、人手による介入、エラーの伝播を意味する。再トレーニング不要のフレームワークがこの種の失敗を3分の1以上削減できるなら、調達担当者の計算は変わってくる。
開発者にとっては、Apache 2.0ライセンスのもとでのオープンソース公開により、この最適化フレームワークを商用製品に合法的に使用できることを意味する。実際の使用においても、モデルの呼び出しロジックを変更する必要はなく、スキャフォールドの8つのコンポーネントをファイルとしてHarness²のエディタに公開するだけで自己改善ループを起動できる。これはLoRAファインチューニングやRLHFよりもインフラへの要件が一桁低い。
大規模モデルへの依存コストを削減したいチームには、より直接的な活用経路がある。コストの低いGLM-5がスキャフォールド最適化を経てGemini 3.5 Flashのデフォルト性能に達するか上回れるなら、アプリケーション層にスキャフォールド最適化を導入することは有効なコスト裁定手段となる。論文のデータは、この経路の実現可能性を2つのエグゼキューターで検証している。
ランキングの比較可能性の問題は、Harness²自体よりも深遠だ
Harness²が産業界に与えるインパクトは、このフレームワーク自体の枠を超えている。現在の大多数の大規模モデルランキング——総合ランキングであれ垂直領域評価であれ——は「モデル＋デフォルトスキャフォールド」の複合スコアを報告している。Harness²のデータは実験的に、同一モデルが異なるスキャフォールド下でのスコア差が11ポイントを超える可能性があること、そして異なるモデルが最適化vs.デフォルトスキャフォールド下でランキングが入れ替わる可能性があることを示している。
これが意味するのは、現在のランキングにおける隣接する順位間の差の少なくとも一部が、モデル能力の差ではなくスキャフォールドエンジニアリングへの投資量の差である可能性だ。評価結果を基にモデル選定の意思決定を行う企業や開発者にとって、これは実質的な情報問題を構成している。ランキングでN位とN+2位のモデルは、基礎モデルの能力の真の差ではなく、「エンジニアリングチームがデフォルトスキャフォールドに投入した工数の違い」の結果に過ぎない可能性がある。
Hacker Newsなどのプラットフォームでこの論文をめぐる議論はこの点に集中している。スキャフォールドが最終結果に与える貢献はどれほど大きいのか、そして現在の評価体系はこの貢献をほとんど標準化された形で測定・開示していない。統一されたスキャフォールド標準のないランキングが公表する数字は、モデルの基礎能力の横断比較というよりも「最高水準のプロンプトエンジニアリングの成果展示」に近い。
歴史的先例から見る：エンジニアリング層の収益はアーキテクチャ層よりも先に過小評価されがちだ
「モデル自体を変更せず、エンジニアリング層によって顕著な成果を得る」という先例が登場したのは、今回が初めてではない。Chain-of-Thought（思考連鎖）プロンプトが体系的に研究される以前、研究コミュニティはプロンプト設計の能力上限について総じて保守的な見方をしていた。ツール呼び出し（Tool Use / Function Calling）も標準化される以前は、各社の実装効果のばらつきが同様に大きかった。これらの歴史を振り返ると、あるパターンが見えてくる。ある能力層がまだ体系化・標準化されていない段階では、その貢献は過小評価されがちだ。しかしそれを定量化した論文が登場すると、業界はこの層が総スコアに実際に貢献する割合が、従来考えていたよりもはるかに大きいことにようやく気づく。
Harness²が成し遂げたのは、「スキャフォールドエンジニアリング」を経験的な作業から、測定可能で再帰的に最適化でき、結果を再現できる方法論の段階へと引き上げることだ。このアクション自体——Harness²というフレームワークの最終的な採用率がどうであれ——は、引用・比較可能な定量的基準を示している。専門タスクにおけるスキャフォールド最適化の単一ステップでの収益は1〜2ポイントの水準ではなく、11ポイントの水準にあるということだ。
不確実性と検証待ちの境界
現在公開されている実験データは3つのベンチマークと4種類のモデル＋スキャフォールド構成の組み合わせから得られたものだ。論文中の評価対象モデルはGLM-5とGemini 3.5 Flashであり、エディタはClaude Opus 4.8だ。この手法がより広範なモデル（例えばパラメータ数がより多いまたは少ないモデル）や、より多くのベンチマーク上での普遍性、そして高並列の本番環境における安定性については、現時点で独立した第三者による再現データは存在しない。
また、再帰的最適化自体の計算コストにも注意が必要だ。タスクレベルの再帰のたびに複数の候補スキャフォールドをプローブ実行する必要があり、独立したエディタモデル（Claude Opus 4.8）が提案と統合を担う。レイテンシが重要な、またはコスト制約のあるアプリケーションシナリオにおいて、この追加オーバーヘッドが正当化されるかどうかは、具体的なタスクの価値密度に依存する。論文には各改善サイクルの推論コストデータが開示されておらず、これは選定時に自ら測定が必要な変数だ。
今後最も起こりやすいこと
以下は上記の分析に基づく展望的判断であり、分析であって事実ではないことを明示する。
短期的には、最も起こりやすい業界への連鎖反応は、主要な評価機関が結果ページにスキャフォールド構成の開示欄を追加せざるを得なくなることだ。FLOPSの透明性が計算量の正規化比較を促進したように、Harness²は「報告時にスキャフォールド設定も同時に開示すべき」という要求を、実践者の直感から注脚可能な学術的コンセンサスへと変えるための引用可能な論文的根拠を提供した。
中期的には、Harness²の独立再現実験がクロスモデルの普遍性を検証すれば、「スキャフォールド最適化」は大規模モデルAPIプロバイダーにとっての標準的な付加価値サービスの方向性となる可能性が高い。既存のFine-tuning APIに似ているが、重みの更新を伴わず、デプロイサイクルが短く、より頻繁な反復が可能だ。
今後6ヶ月以内に注目すべき点は、独立研究チームがMMUL、SWE-Bench、GAIAなどのより汎用的なベンチマークで同様の規模の向上を再現できるかどうか、そして既存のランキング（例えばChatbot Arenaクラスのプロダクト）が提出要件にスキャフォールド開示規範を加え始めるかどうかだ。前者はこの方向性の普遍性の境界を決定し、後者はそれが業界の比較基準を実質的に変えられるかどうかを決定する。
現時点で意思決定が必要な開発者へ。エージェントアプリケーションがすでに安定稼働しているが、ボトルネックがツール呼び出しの安定性とタスク完了率にあるなら、Harness²は次世代の基礎モデルを待たずに、アノテーションデータも必要とせず、今すぐ試せる改善経路を提供している。コードはすでに公開されており、コストはスキャフォールド変体のテストに必要な追加推論費用であり、参入障壁は低い。まず小規模な実験で効果を検証してから、完全な再帰的最適化ループを導入するかどうかを判断することができる。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接