Google Harness2、エージェントの自己改善をオープンソース化 ただし検証がなお試金石
Googleは、モデルそのものではなくエージェントを取り巻くソフトウェアを変更することで最大11.5ポイントの改善が得られたと報告した後、Google Harness2をオープンソース化した。この違いが、中心的な緊張関係を生んでいる。このフレームワークでは、エージェントがプロンプト、ツール、メモリ、その他の運用指示を改訂できる一方、既知の正解がないまま、それらの改訂を評価しなければならない。
著者らがHarness²と呼ぶこのプロジェクトは、Google Cloud AI ResearchおよびNorthwestern Universityに所属する研究者によるものだ。コードは2026年10月9日の研究論文とともに公開され、Apache 2.0ライセンスを採用している。このリリースにより、研究手法は開発者が調査、実行、改変できるソフトウェアとなった。
このプロジェクトは、AIエージェントに関する馴染み深い前提にも疑問を投げかける。より良い結果には、常に新しい、あるいはより大規模なモデルが必要とは限らない。言語モデルを行動するシステムへと変えるソフトウェアと指示、すなわちハーネスを変えることで実現できる場合がある。
この主張は、固定されたエージェントフレームワークに圧力をかける。OpenCode、Codex、Claude Codeなどのシステムは、モデルをプロンプト、ツール、メモリ、オーケストレーションと組み合わせている。Google Harness2は、こうした周辺コンポーネントがデプロイ後も固定されたままであるべきかを問う。
その答えは、ベンチマークの順位を超えて重要だ。自己編集するハーネスは、未知の法務、オフィス、ウェブ、コーディング業務に適応できる。一方で、誤った前提を維持したり、より弱い改訂を選んだり、回答に到達するまでに大幅に多くの計算資源を費やしたりする可能性もある。
Google Harness2は凍結されたモデルを取り巻くソフトウェアを変更する
このリリースは、再帰的な改善をモデル学習から、エージェントランタイムの編集可能な8つの部分へと移す。
AIエージェントは、プロンプトに回答する言語モデルだけではない。指示、利用可能なツール、保存されたコンテキスト、委任ルール、各アクションを制御するソフトウェアにも依存する。これらのコンポーネント全体が、エージェントハーネスを構成する。
Google Harness2は、システムプロンプト、ガードレール、メモリ、ツールガイダンス、サブエージェント、スキル、スクリプト、ミドルウェアプラグインという8つのコンポーネントを改訂対象として公開している。各コンポーネントはランタイムにマウントされるファイルとして表現される。基盤となるモデルの重みは凍結されたままだ。
この分離は重要である。モデルの学習やファインチューニングには、専用インフラ、準備済みデータ、別個のデプロイプロセスが必要になる。プロンプト、スキル、ツール指示の編集は、エージェントがタスクに取り組んでいる最中にも行える。
オープンソースリポジトリは、この手法をLinux向けPythonプロジェクトとしてパッケージ化している。Python 3.12、並列・逐次のリファインメント、OpenCodeおよびCodexエグゼキューターとの統合をサポートする。付属のデモは決定論的なエディターとローカルPython実行を使用するため、開発者はモデル認証情報なしでワークフローを確認できる。
モデルを用いた評価には、より多くのインフラが必要となる。リポジトリには、Node.js、Google Cloud認証、Vertex AI経由のモデルアクセス、ベンチマーク固有の依存関係が指定されている。WorkBuddy-BenchにはDockerが必要であり、法務ベンチマークには文書処理ユーティリティが必要だ。
このセットアップは、現時点でのプロジェクトの対象ユーザーを示している。これは、管理された評価を実行する準備があるチーム向けの研究ソフトウェアであり、あらゆるエージェントを自動的にアップグレードする消費者向け機能ではない。リリースは実験のための仕組みを提供するが、採用者には依然としてタスク、実行環境、評価者、運用上の制限が必要となる。
フレームワークは、各受信タスクを共通のベースハーネスから開始する。直前のタスク固有設定を次の割り当てにそのまま引き継ぐわけではない。代わりに、現在のハーネスを一時的にリファインし、再利用可能な教訓を別の改善ライブラリに記録する。
この判断は、適応システムにおける一般的な失敗に対処する。契約分析に役立つ指示が、スプレッドシートのタスクには害となる可能性がある。成功した編集をすべて直接蓄積すれば、ハーネスはますます特化し、理解や推論が難しくなる。
Harness²は代わりに、編集がなぜ役立ったのかに関する証拠を保持しようとする。将来のタスクは、過去の実行設定全体を継承せずに、その経験を活用できる。
したがって、このプロジェクトは2つの形態のソフトウェアを表す。1つのハーネスが作業を実行し、別のハーネスがその作業を行うシステムを改善する。この第2層があるため、著者らはこの手法を通常のプロンプト最適化ではなく、再帰的エージェントハーネシングと説明している。
すでにエージェント指示を手作業で管理している開発者にとって、このリリースは馴染みのあるワークフローを形式化するものだ。チームは失敗を調査し、指示を改訂し、タスクを再実行し、有用な手法を保存する。Google Harness2は、そのループの大部分をエージェントに委ね、結果として生じた変更を構造化された成果物として記録する。
Google Harness2が正解なしでエージェントをリファインする方法
その中核メカニズムは、完全な検証器に正しい出力を特定させるのではなく、条件を揃えた振る舞いを比較する。
フレームワークは、主要なタスクレベルのプロセスをPropose-Probe-Composeと呼ぶ。まず提案者が元の実行を分析し、対象を絞ったハーネス編集を提案する。プローブがそれらの候補で同一タスクを再実行する。次にコンポーザーが、得られた軌跡の差異によって裏付けられた変更を組み合わせる。
軌跡とは、モデル応答、ツール呼び出し、観測、生成ファイルの記録された一連の流れである。最終回答だけよりも多くの証拠をシステムに提供する。エディターは、ある改訂が不足している入力を発見したか、適切なツールを呼び出したか、提出前に文書を検証したかを確認できる。
システムは提案を2つの範囲に分ける。不変エディターは、書き込み後に出力を確認するといった一般的な実行行動に注力する。ドメインエディターは、タスク固有の知識、形式、手順に注力する。
この分離により、すべての問題に同じ汎用的な修正が適用される可能性を減らす。また、両方が有益な行動変化を生み出した場合、コンポーザーは広く役立つプロセスルールと専門的なガイダンスを組み合わせられる。
重要なのは、オンラインプロセスがベンチマークの解答キーを受け取らない点だ。研究論文は、ハーネス設計後にタスクが到着するオープンワールド環境を説明している。実行時に利用可能な信頼できるグラウンドトゥルース検証器がない場合もある。
システムは、ある候補を正しいと断定する代わりに、対比を探す。たとえば、ベースエージェントが複数のソースファイルを見落とすとする。ある改訂はすべての入力を一覧化し、別の改訂はスプレッドシート照合のガイダンスを加える。それぞれの軌跡は、それらの介入がエージェントのプロセスを変えたかどうかを示す。
コンポーザーはその証拠を用いて別のハーネスを構築し、タスクを再び実行する。このアプローチは判断をなくすものではない。出力を既知の答えと比較することから、実行間で観測可能な振る舞いを比較することへと判断を移す。
開発者は、追加のテスト時コンピュートを2つの方法で使える。並列再帰では複数の候補改訂を同時に探索し、その試行から得られた証拠を合成する。逐次再帰では、前の各改訂の後に別のリファインメントを適用する。
変数kは、その探索予算を制御する。値を大きくすると、システムが編集を発見してテストする機会は増えるが、そのたびにモデル呼び出し、ツール使用、実行時間が追加される。
タスク完了後、第2の再帰レベルが継続的改善ハーネスを更新する。リフレクターは、採用されたハーネスと、介入、証拠、結果を説明する経験ファイルを保存する。後続の提案は、そのライブラリを参照できる。
この設計により、経験は完成したプロンプトよりも移植しやすくなる。保存された教訓には、文書生成タスクでは最終ファイルを再度開き、必要なセクションを確認すると有益である、といった内容を記録できる。正確な文書が異なる場合でも、そのプロセスは複数のドメインに適用できる。
この区別は、フレームワークを日常的なナレッジワークにも結び付ける。エージェントは、意思決定メモを作成する前に、会議メモ、スプレッドシート、ポリシー、プロジェクト文書を組み合わせる必要があるかもしれない。難しいのは、多くの場合、流暢な文章を生成することではなく、複数のソースにまたがって主張をたどることだ。
チームはすでに、検索可能なナレッジベースを構築することで、その負担を軽減できる。Harness²はこの考え方を実行ポリシーへと拡張する。エージェントは、特定のタスクに対して、その資料を収集、確認、利用する方法を改訂できる。
ただし、このメカニズムは依然として実験段階にある。行動上の対比は証拠であり、真実ではない。2つの候補が同じ誤った前提を共有することもあり、洗練された軌跡が不適切な成果物につながることもある。
ベンチマークでの改善は固定エージェントハーネスに圧力をかける
報告された結果は、特に出発点となるシステムが弱い場合、ハーネス設計がモデルの交換と同程度に性能を変え得ることを示している。
研究者らはHarness²を3つの専門ベンチマークで評価した。WorkBuddy-Benchはコーディング、ウェブ、オフィスタスクを対象とする。JobBenchは専門業務をテストし、Harvey’s Legal Agent Benchmarkは法務タスクの性能を測定する。
テストでは、2つのモデルと2つの開始ハーネスを組み合わせた4通りを扱った。モデルはGemini 3.5 FlashとGLM-5、初期実行ハーネスはOpenCodeとCodexだった。主要実験ではClaude Opus 4.8がデフォルトエディターを務めた。
著者らによれば、単一のリファインメントステップにより、テストしたすべてのモデルとハーネスの組み合わせが、3つのベンチマークすべてで改善した。報告された最大の改善幅は、WorkBuddy-Benchで11.5ポイント、JobBenchで4.5ポイント、法務ベンチマークの部分合格率で11.8パーセントポイントに達した。
WorkBuddy-Benchで最大の変化が見られたのは、OpenCode上のGLM-5だった。平均スコアは1ステップ後に64.2から75.7へ上昇した。OpenCode上のGemini 3.5 Flashは72.4から77.5へ上昇した。
これらの数値は実務的な推論を支持する。ハーネスは、生のモデル能力だけでは解決できない実行上の振る舞いを修正することで、モデル間の差の一部を縮められる可能性がある。
結果は構成によって異なった。Codex上のGLM-5はJobBenchでわずか1.2ポイントの改善にとどまり、23.6から24.8へ移行した。同じベンチマークで、OpenCode上のGeminiは4.5ポイント改善した。
この変動は、最も大きな見出し数値よりも重要である。この手法は、すべてのモデル、ハーネス、タスクに一様な改善をもたらしたわけではない。その価値は、開始時のシステムとドメインに依存した。
研究者らは再帰予算も増やした。OpenCode上のGeminiでは、1回のリファインメントステップからk=5の並列再帰へ移行することで、WorkBuddy-Benchの性能がさらに向上した。コーディングは80.8、ウェブは81.7、オフィスは83.4に達した。
論文によれば、選択されたWorkBuddy-Benchのドメインでは、予算を1から5へ増やすにつれ、並列・逐次の両方のスコアが上昇した。競合手法は、これらのテストでより小さい、あるいは一貫性の低い変化を示した。
探索量の増加だけがすべての説明ではない。アブレーション研究では、改善ライブラリを除去するとWorkBuddy-Benchの平均性能は3.1ポイント低下した。範囲別のエディター役割を取り除くと2.9ポイント、合成を省略すると1.6ポイントの損失となった。
JobBenchでも同様の傾向が見られた。ライブラリを除去するとスコアは1.8ポイント低下し、汎用エディターでは3.7ポイント失われ、合成を省略すると1.9ポイント低下した。これらの結果は、保持された経験、専門化された提案、証拠に基づく組み合わせが、それぞれ寄与したことを示している。
JobBenchのケーススタディは、その仕組みをよく示している。ベースエージェントはソースファイル間の情報を突き合わせられず、最終出力を再度開いて検証することもしなかった。スコアは43.1だった。
提案された介入の一つでは、すべての入力の棚卸しと明示的なソース追跡が求められた。別の介入では、スケジュール、会場、人員、予算の整合性確認に関するドメインガイダンスを追加した。コンポーザーはこれらの介入で導入された4つの編集をすべて保持し、再実行のスコアは77.8となった。
この例は、失敗が手続き上のものだったため、エージェントハーネス改善の必要性をより強く裏付けている。モデルに基本的な言語能力やファイルへのアクセスが欠けていたわけではない。信頼できる運用方法が欠けていたのだ。
固定ハーネスでも、ドメインごとにパフォーマンスは異なった。論文の比較では、固定システムのうちClaude Codeはコードとオフィスタスクで、CodexはWebタスクで首位だった。変更されていないハーネスで、すべての領域をリードするものはなかった。
より大きな再帰予算を設定したOpenCodeを起点として、Harness²は最も強力な固定代替案を、コードで4.6ポイント、Webで5.8ポイント、オフィスで4.9ポイント上回った。著者らは、この適応的な結果が追加のテスト時コンピュートを使用したことを明示している。
したがって競争圧力が向けられているのは、特定の製品ではなく固定ハーネスというアプローチである。ベンダーはモデルを改善できるが、周囲の指示やツールが適応できなければ、ユーザーは依然として一貫しない結果を受け取る可能性がある。
自己改善型エージェントハーネスには依然として独立した検証が必要
Harness²はエージェントのプロセスを改善できるが、その証拠自体が、再帰的な編集がときに劣った挙動を選択したり、誤った前提を広めたりすることを示している。
ベンチマーク結果はプロジェクト著者によるものであり、独立したデプロイメント全体での本番信頼性はまだ確立されていない。論文は3回の実行にわたる平均値を報告しており、これはばらつきの測定には役立つが、外部による再現検証の代わりにはならない。
この手法は、最終出力を提供する前に追加のコンピュートを消費する。各提案、プローブ、構成、再実行は、トークンと実行時間を消費する。容量が利用可能なら並列処理で経過時間を短縮できるが、根本的なリソースコストはなくならない。
論文は、評価対象の構成をJobBenchとWorkBuddy-Benchにおける実証的なコンピュート・パフォーマンスのフロンティアに位置付けている。この結果は、測定された改善がテストされた代替案と比べて有利だったことを意味する。再帰がすべての本番ワークロードで経済的であることを意味するわけではない。
低価値のタスクでは、複数回のモデル実行を正当化できない場合がある。法的メモや運用上の意思決定ではより多くの検証が正当化されるかもしれないが、これらの領域ではベンチマークランナー以上に厳格な制御も求められる。
最も重要な警告は、著者ら自身の失敗分析にある。彼らは9件の性能低下を調査し、候補選択の失敗、共有された誤った前提、評価または実行の不確実性に分類した。
あるコーディング例では、フレームワークはスコア95の代替案ではなく、スコア55の出力を選択した。法務タスクでは、より限定的な改訂により網羅性が低下し、スコアは54から26へ下がった。
別の失敗は、候補間で共有された誤った前提から始まった。これらのエラーは2〜11ポイントの損失をもたらした。提案されたすべての編集が同じ誤った前提を受け入れている場合、その挙動を比較しても元の誤りは明らかにならない。
論文はまた、欠落した判定結果や通常の実行間のばらつきを、原因帰属上の問題として挙げている。変化したスコアは、編集、確率的実行、または評価ノイズを反映している可能性がある。プローブを増やせば役立つが、コストも増加する。
リポジトリの活動からは、実装上のリスクも明らかになっている。公開されているキャッシュ識別の問題では、タスク識別子が同一のままタスク指示やソースファイルが変更された場合、再開された実験が以前の出力を再利用する可能性が報告されている。
この問題の報告者は、モデル呼び出しなしでこの挙動を再現し、保存された実行識別情報の一部に入力コンテンツが含まれていないと指摘した。この報告は公開済みベンチマークスコアへの影響を定量化しておらず、確認時点ではメンテナーによる解決策も添付されていなかった。
それでも、この問題はより広範な運用上の課題を示している。再帰的システムには、タスク、ソース資料、ハーネス改訂、キャッシュ出力、評価設定について信頼できる来歴管理が必要である。そうでなければ、見かけ上の改善が古い証拠を反映している可能性がある。
セキュリティも別の懸念を生む。編集可能な8つのコンポーネントには、ガードレール、スクリプト、プラグイン、ツール指示が含まれる。これらのファイルは、エージェントが何にアクセスし、どのアクションを実行するかに影響を与え得る。
自律的なエディターに、アクセス制御を弱めること、未審査のスクリプトを実行すること、機密性の高いタスク詳細を永続化することへの無制限の権限を与えるべきではない。本番利用には、コンポーネント単位の権限、不変のセキュリティ境界、監査ログ、ロールバックが必要である。
永続的な経験にも同様の注意が必要だ。ある顧客、部門、法的案件から得た有用な教訓が、別の案件で取得された際に機密情報を露出させる可能性がある。したがって改善ライブラリには、意味的関連性だけでなく、データ分離と保持ポリシーが必要になる。
チームは、パフォーマンス最適化と安全性検証も区別すべきである。ベンチマークスコアは、その評価器の下でのタスク完了を報いる。プライバシー、権限管理、事実正確性、悪意ある入力への耐性を自動的に測定するものではない。
Google Harness2自体が、この区別が重要である理由を示している。そのコンポーザーは、挙動としては説得力があるものの、客観的には劣る候補を選好する場合がある。正解データの不在はフレームワークが対処する問題だが、フレームワークが取り除けない限界でもある。
現実的な本番設計では、システムが低リスクのガイダンスを変更できる一方で、コアポリシーを保護するべきである。プロンプトの文言やワークフローのチェックリストは編集可能でもよい。認証情報のルール、ネットワーク境界、承認ゲート、破壊的アクションの制限は、エージェントの権限外に置くべきである。
タスクをまたいで永続化される変更の提案には、人間によるレビューも引き続き有用である。このフレームワークは、編集が採用された理由を説明する証拠を作成できる。運用担当者は、その記録を用いて変更を承認、却下、または制限してから共有ライブラリに登録できる。
再帰的エージェントハーネシングがエージェントエンジニアリングのロードマップを変える
次の検証点は、組織がコンピュート、性能低下、永続メモリを管理しながら、この改善を再現できるかどうかである。
最初に注視すべきシグナルは、独立したベンチマーク再現である。リポジトリはコード、構成、プロンプト、評価コマンドを公開しており、外部チームに実用的な出発点を提供している。再現実験では、最終スコアと総モデル使用量の両方を報告すべきである。
異なるプロバイダーにまたがる再現の成功は、中心的な主張を強化する。それは、適応的ハーネシングがテスト対象のモデル、エディター、Google Cloud環境に強く依存していないことを示すだろう。
改善を再現できなければ、一般性に対する根拠は弱まる。研究者は、その差がモデルの挙動、ベンチマークのバージョン、実行環境、評価設定のどこに由来するのかを特定する必要がある。
2つ目のシグナルは、孤立したベンチマーク実行ではなく、実際のタスクストリームにおけるパフォーマンスである。ハーネシングレベルの再帰は、以前のタスクから得た教訓が後の提案を導くため、累積的な価値を約束する。
論文は、このような転移に関する初期的な証拠を示している。JobBench上で構築された経験ライブラリは、WorkBuddy-Benchにおける1ステップ改良を、コードで0.6ポイント、Webで0.5ポイント、オフィスで2.9ポイント改善した。
これらの改善は最も強いタスクレベルの結果より小さく、ある分析では後続タスクの経験が遡及的に使用された。実運用のデプロイメントでは、将来の情報を取り込むことなく、有用な教訓が時系列順に蓄積することを示すべきである。
運用担当者は、平均パフォーマンスと並行して性能低下率を測定すべきだ。また、介入頻度、レイテンシー、モデル消費量、人間のレビューを通過する永続的編集の割合も追跡すべきである。
3つ目のシグナルは、より強力な検証・ガバナンス層である。著者らは、共有された前提に異議を唱えるプローブ、編集とばらつきを分離するための繰り返し実行、網羅性と精度のバランスを取るより良い選択手法を推奨している。
リポジトリの修正も別の指標となり得る。コンテンツを考慮したキャッシュ識別子、固定されたベンチマーク改訂、信頼できる無効化により、実験は再現しやすくなる。編集可能なコンポーネントに明確なセキュリティ境界を設ければ、デプロイメントも安全になる。
より広範な研究分野では、ハーネス適応の代替形式も検証されるだろう。Meta-Harnessはデプロイ前に構成を探索する。ReasoningBankはハーネスを固定したまま有用な推論経験を取得する。Harness Scalingは個別タスク向けにハーネスを改訂する。
Harness²は、オンラインのタスク適応と永続的な改善メカニズムを組み合わせている。この組み合わせが最大の特徴だが、リスクも集中させる。悪いタスクレベルの改訂は一つの結果に影響するが、保持された悪い教訓は後続タスクに影響を及ぼし得る。
開発者にとって実践的なメッセージは、すべてのエージェントが直ちに自己書き換えを始めるべきだということではない。プロンプト、メモリ、ツール、オーケストレーションを接続されたシステムとして評価すべきだということである。
チームは、範囲を限定した実験から始められる。代表的なタスクを選び、不変のベースハーネスを保持し、サンドボックス内でのみ改訂を許可し、出力品質を総コンピュートと比較できる。すべての永続的変更は、追跡可能かつ可逆的であるべきだ。
ナレッジワーカーが関心を持つべきなのは、ハーネスの品質が目に見えるエージェントの挙動を形作るためである。ツール指示が弱い、メモリがノイジー、またはワークフローに検証が欠けている場合、モデルは信頼できないように見えることがある。反対に、より良い手順はモデルを変更せずに結果を改善できる。
オープンリリースにより、これらの仮説は検証可能になる。エージェントが失敗を診断し、運用指示を改訂し、経験を保持する方法を研究するための共通実装を、研究者に提供する。
Google Harness2は最終的に、自己改善をめぐる議論を抽象的なモデル知能から、検査可能なソフトウェア成果物へと移す。チームはファイルをレビューし、改訂を追跡し、実行を測定できるため、これは有益な転換である。
ただし、最も難しい問いは解決しない。正解データが存在しない場合、改善者を誰が検証するのか。フレームワークは盲目的な編集を構造化された行動証拠に置き換えるが、証拠が誤解を招くことは依然としてある。
今後数か月は、独立した再現、実運用でのクロスタスク結果、編集可能なコンポーネントをめぐるより厳格な制御に注目すべきである。これらのシグナルが、再帰的エージェントハーネシングが信頼できるエンジニアリング層となるのか、それとも有望な研究ワークフローにとどまるのかを決める。
現在AIエージェントを評価しているチームにとって、直ちに取るべき行動は明確である。モデルとそのハーネスを別々にテストし、すべての変更を記録し、自動化された改訂を保持する前に明確な証拠を求めることだ。Google Harness2はその実験のための具体的なフレームワークを提供する一方、報告された失敗は、監督がなお重要である理由を示している。
