Harness²は、Google Cloud AI Researchと米ノースウェスタン大学による研究フレームワークで、基盤となるモデルには手を加えずに、AIエージェントの仕事ぶりを高めることを目指しています。重みを再学習させる代わりに、モデルを取り巻く指示やルール、補助ファイルを、エージェントが作業しながら自ら編集できるようにする仕組みです。仲裁文書のレビュー課題で試したところ、Gemini 3.5 Flashは1回の自己編集で、55項目の自動チェックのうち合格が20項目から22項目に増え、かかった費用は約$11でした。伸びは小さいものの、研究チームが報告する平均とほぼ一致しており、研究チーム自身の事例研究には、はるかに大きな伸びを示したものもあります。
モデルではなくハーネスに手を入れる理由
より賢いエージェントを目指す取り組みの多くは、モデルそのものに注目してきました。モデルを再学習させるか、新しいデータで重みをファインチューニングするという方法です。Harness²は別の定義から出発します。エージェントとはモデルとハーネスを合わせたものであり、ハーネスとは指示、ファイル、ツール、制約、設定など、モデルの外側にあってその振る舞いを形づくるすべてを指します。
このアプローチでは、モデルの重みは最初から最後まで固定されたままです。エージェントが変更できるのは自分のハーネスだけです。何も再学習しないため、学習コストはかからず、破滅的忘却（新しいことを学ぶとモデルが以前の能力を失ってしまう傾向）の心配もありません。
考え方は、新入社員が上達していく過程に似ています。初日はミスをしてもメモを取り、チェックリストを作ります。すると2日目には、ずっとうまくこなせるようになります。Harness²はエージェントに同じフィードバックの仕組みを与えます。重要なのは、エージェントが正解を一度も見ずに、課題の評価基準に照らして自分の成果を採点する点です。
エージェントが書き換えられる8つのファイル
このフレームワークはモデルを8つのモジュール式ファイルで包んでおり、エージェントが変更できるのはこれらのファイルです。
- システムプロンプト：エージェントが出発点とする基本の指示
- ガードレール：エージェントが常に守るべきルール
- メモリー：以前の作業から引き継ぐメモ
- ツールガイダンス：ツールを正しく呼び出すための指示
- サブエージェント：仕事の一部を引き受ける補助のエージェント
- スキル：特定分野のノウハウをまとめた手順書
- スクリプト：エージェントが直接実行できるコード
- ランタイムプラグイン：タスクの実行中に介入するアドオン
1回の自己改善の進み方
研究チームはこのサイクルを、財務の照合作業を例に説明しています。エージェントが請求書、サービス障害の記録、サブスクリプションのクレジットを照合して1つのワークブックにまとめる作業で、途中では空欄や二重に数えられた行にも対処しなければなりません。各ラウンドは次の5段階で進みます。
- 実行：エージェントが、手を加えていない元のハーネスで課題を一度こなします。
- 提案：2種類の修正案を作ります。1つはどの課題にも役立つはずの一般的な習慣、もう1つはその分野に特有の専門知識を盛り込んだものです。
- 検証：何かを採用する前に、それぞれの修正案を単独で同じ課題に試します。
- 統合：効果が確かめられた修正案だけを最終的なハーネスにまとめ、エージェントが本番の成果物をもう一度作ります。
- 振り返り：エージェントが学んだことを教訓として要約し、永続的なライブラリーファイルに保存します。以後の実行はその教訓を引き継ぎます。
最も重要なのは検証の段階です。研究チームによると、変更ごとにサンドボックスで事前に試さずにハーネスのファイルをやみくもに編集すると、精度が下がり、かえって悪化することが多いといいます。直すべき点を見つけるのは仕事の半分にすぎず、残りの半分は、それぞれの修正が本当に効くかを確かめることだと言えそうです。
▲ ハーネス改善の5段階のサイクル
Gemini 3.5 Flashによる法務レビューのテスト
軽量モデルでどうなるかを確かめるため、テストではGemini 3.5 Flashに、Googleの公式ベンチマーク群から法務の課題を与えました。題材は国際商業会議所（ICC）のもとでの仲裁です。エージェントは手続命令第3号の草案をレビューし、過去の手続命令や戦略メモと比べたうえで、注釈付きのレッドライン（変更案をすべて書き込んだ修正履歴付きの文書）と、主な異議をまとめた書簡を作らなければなりません。
最初の試行で、エージェントは55項目の自動チェックのうち20項目に合格し、スコアは36.4でした。続いて自分の見落としを調べ、ハーネスのファイルを2つ変更しました。1つは新しい分野別の手順書SKILL.mdで、草案を過去の命令と1行ずつ比べ、審理期間と証拠ルールを決まった形で確認するよう指示しています。もう1つは、仕事が仲裁のレビューであればこの手順書を読み込むという条件付きの指示を、systemprompt.mdに加えたことです。
| 項目 | 最初の試行 | ハーネス編集後 |
|---|---|---|
| 合格したチェック | 55項目中20項目 | 55項目中22項目 |
| スコア | 36.4 | 40.0 |
| 実行時間 | 446.4秒（約7分30秒） | 736.9秒（約12分） |
最終的なハーネスの組み立てには45.0秒かかり、編集と再実行のサイクル全体にかかったAPI料金は約$11でした。3.6ポイントの伸びの内訳を見ると、3つの基準が不合格から合格に変わっています。最初の手続命令との相互参照、4.5～5日の審理日程の復元、標準的な費用条項の削除です。一方で、逆方向に動いた基準も1つありました。審理地をチューリッヒとすることに関するチェックは、最初の試行では合格していましたが、2回目では不合格になりました。
▲ 仲裁の手続命令のレビューテスト
論文の結果との比較
Gemini 3.5 Flashの結果は、論文に載った数値と並べると意味がはっきりします。
| 条件 | 改善前 | 1回の改善後 |
|---|---|---|
| 同じ仲裁課題、フロンティアモデルでの最良のケース | 44.4 | 94.5 |
| 論文の法務課題全体の平均 | 79.9 | 81.9 |
| 同じ仲裁課題、Gemini 3.5 Flash | 36.4 | 40.0 |
フロンティアモデルを使った最良のケースは、1回のラウンドでどれだけの成果が出うるかを示していますが、法務課題全体での平均の伸びは2.0ポイントでした。Gemini 3.5 Flashの3.6ポイントの伸びは、この平均的な傾向に近い水準です。通常の1回のラウンドで上がるのは数ポイントで、ハーネスに明らかな欠けがあった課題では時折大きく跳ねる、というのが妥当な見方かもしれません。
編集が大きな成果を生んだ5つの課題
論文では、ハーネスの変更が大きな改善につながった事例も紹介されています。どの事例でもモデルは同じままで、変わったのはエージェントの作業ルールだけでした。
| 課題 | エージェントが変えたもの | スコア |
|---|---|---|
| 映画プロデューサーの予算メモの照合 | 出力するすべての数値を開き直して検証する一般的なガードレール | 43.1から77.8 |
| 売上ワークブックの処理 | 派生する手数料率を加重平均で計算するためのスキルの指示 | 23.6から100.0 |
| オフラインで動く単一ページのWebアプリの作成 | 外部のCDNからのコード取得を禁じ、スクリプト、スタイル、データをインラインに収めるガードレール | 64.0から100.0 |
| リサーチの統合 | 上限に達する前に早めの下書きを強制するランタイムプラグイン | 72.0から100.0 |
| コーディングのベンチマーク | 疑似コード形式のツール呼び出しを禁じる厳格なツールガイダンス | 60.0から100.0 |
CDN（コンテンツ配信ネットワーク）は、スクリプトやフォントなどのファイルをWebページに配信する外部のサービスです。リサーチの課題は、予算とコンテキストの上限（モデルが一度に扱えるテキストの量）に突き当たってタイムアウトを繰り返していたため、エージェントはdeliverable_watchdogと名付けたプラグインを作りました。トークンの上限が近づくと、このプラグインがそれ以上の調査クエリを止め、必ず下書きが書かれるようにします。トークンとは、モデルが処理するテキストの単位です。コーディングの事例では、モデルがツール呼び出しを偽の疑似コード形式で出力していましたが、新しいガイダンスによって、正しいネイティブのツール呼び出しだけを使うようになりました。
試す前に知っておきたい注意点
Harness²はGitHubでharness2リポジトリとして公開されており、約6,000のスターを集めています。ただし、Google Cloud AI Researchとノースウェスタン大学による実験的な学術コードであり、Googleが正式にサポートする企業向け製品ではありません。
セットアップは、開発者向けのツール一式を前提としています。
- Linux
- Python 3.12とパッケージマネージャーのuv
- Node.js 20以降
- テスト実行用のサンドボックスを提供するDocker
- Vertex AIへのアクセス権を持つアカウントでサインインしたGoogle Cloud CLI
この顔ぶれを見ると、技術的な支援のないビジネスユーザーが導入するのは、まだ簡単ではありません。自己編集にはリスクもあります。チューリッヒの審理地のチェックが示したように、ある問題を直す変更が、それまで機能していた部分を壊すことがあります。さらに、サイクルを回すたびに時間とお金がかかります。法務のテストでは2回の実行に合わせて20分近くかかり、課題1つで約$11の費用がかかりました。
エージェントを運用するチームが学べること
Harness²の核心となる教訓は、モデルを固定したままでも、エージェントは周りのファイルを通じて改善を続けられるということです。このアプローチが最も合うのは、エージェントが毎週、予測可能な繰り返しの作業をこなしているチームだと考えられます。ある実行で得た教訓を、次の実行に持ち越せるからです。
フレームワークを導入しなくても、自前のエージェントを運用するチームなら、その原則を今すぐ取り入れられます。
- モデルを乗り換える前に、システムプロンプト、ツールの定義、ガードレールといったハーネスに投資します。
- プロンプトやスキルの変更は1つずつサンドボックスで試し、効果のあるものだけを取り込みます。
- 改善を2つのグループに分けます。出力ファイルの再確認のような一般的な習慣と、仲裁の慣行のような分野の知識です。
- 長時間動くリサーチ用のエージェントには、トークンや時間の予算が尽きる前に大まかな下書きを強制するウォッチドッグを持たせます。
- Webの成果物は、スタイル、スクリプト、データをインラインに収めた自己完結型にし、CDNなしでもオフラインで動くようにします。
- 疑似コード形式のツール呼び出しを禁じ、ネイティブの呼び出し形式を必須とするツールガイダンスを書きます。