Google と Microsoft の最新論文 2 本を共有：エージェントのための「Harness（枠組み）」の自動進化

LLM エージェントが急速に進化する現在、エージェントのために適切なHarness（制約・馬具）をいかに設計するかが重要な課題となっています。本稿では、メモリシステムとアクション制約という 2 つの次元から、自動化された Harness 進化手法を提案する最新の論文 2 本をご紹介します。

Microsoft発のM⋆：タスクごとに専用メモリを持つHarness 構造の実現に焦点
Google発のAutoHarness：不正なアクションを防ぐためのコードレベルの制約を自動生成することに注力

正直なところ、この 2 本の論文を読んだ最初の感想は「AI 研究の潮流は確実に変わった。もはや『自己進化型エージェント』の時代だ」というものでした。

この分野を深く理解したい方のために、自己進化スキル、エージェントシステム、ワールドモデル、コンテキスト、Harness などの最先端論文とコードをまとめた資料を共有します。

以下のQR コードをスキャンし、「120Agent」と返信すると、論文セットとプロジェクトコードが無料で入手可能です。

1. M⋆：すべてのタスクに専用メモリ Harness を

1.1 核心的な課題：固定メモリ構造の限界

現在の LLM エージェントのメモリシステムは、往々にして「ワンサイズ・フィッツ・オール」の設計を採用しています。対話エージェントにおけるセマンティック検索から、コードエージェント向けのスキルシステム、あるいは専門分野向けの構造化データベースに至るまで同様です。しかし問題があります。ある分野向けに最適化されたメモリ設計は、他の分野には適用できないのです。

Figure 1: 異なるタスクで進化した多様なメモリ構造の模式図。Legal、Conversation、Embodied AI、Healthcare の 4 分野それぞれが独自のメモリ Harness 構造を持つことを示す

図 1 に示すように、対話タスク（LoCoMo）では人物関係を追跡するためのエンティティ関係グラフが必要であり、法務照会（PRBench）には判例を保存するリレーショナルデータベースが必要です。一方、具身 AI（ALFWorld）には軌跡のルックアップテーブルが必要です。これらの構造はあまりにも異なり、単一の汎用ソリューションで解決することはできません。

1.2 手法：プログラム可能な実行による進化

M⋆は、メモリ Harness をPython メモリプログラムとして表現します。これには以下の 3 つの中核コンポーネントが含まれます。

Schema（スキーマ）：保存および検索するデータの形式を定義（Python dataclass を使用）
Logic（ロジック）：バックグラウンド操作を定義（書き込み/読み取りロジック。ベクトルデータベース、SQL、または LLM を呼び可能）
Instruction（指示）：エージェントがメモリとどのように対話するかを定義するプロンプト定数

Figure 2: M⋆システムの概要。Seed Memory Program から Program Pool へ、そして Evaluate、Reflect & Mutate、Quality Checks を経る反復プロセスを示す

本システムは再帰的コード進化（Reflective Code Evolution）を採用しています。

検証ループサンプリング：静的検証セットとローテーション検証セットを使用して現在のプログラムを評価
コーディングエージェントによる反復：実行軌跡と失敗事例に基づき、LLM が根本原因を分析してコードパッチを生成
制約チェックと自動修復：コンパイルチェック、スモークテスト、実行時制約（例：戻り値は 3000 文字以内など）

同時に、集団ベースの探索戦略（Population-based Search）を採用し、探索（Exploration）と活用（Exploitation）のバランスを調整。Softmax 温度サンプリングによって高スコアのプログラムを選択し、変異させます。

1.3 実験結果

4 つの全く異なるベンチマーク（LoCoMo 対話、ALFWorld 具身、HealthBench 医療、PRBench 法律・金融）において、M⋆は 8 つの設定中 7 つで最高性能を記録しました。

Table 1: 主要実験結果の比較（一部データ）。M⋆は多くのタスクで固定メモリベースラインを大幅に上回る

Figure 3: 進化の軌跡を示すグラフ。複数のベンチマークにおいて、検証スコアが反復ごとにどう変化するかを示し、「初期の構造エラー修正→中期の大幅改善→後期の微調整」という 3 段階パターンを描く

主な発見点は以下の通りです。

構造の多様性：タスクごとに全く異なるメモリ構造が進化（図 4 の t-SNE 可視化を参照）。例えば、ALFWorld の最適プログラムはシンプルなリスト＋LLM 要約を使用しますが、LoCoMo は SQL と ChromaDB を組み合わせたハイブリッド設計を採用します。
タスク特異性：クロスタスク移行実験により、タスク A で進化したメモリプログラムをタスク B に適用すると、汎用ベースラインすら下回る結果になることが判明。メモリ構造はタスクと協調して最適化される必要があることが証明されました。

Figure 4: プログラム埋め込み空間の可視化。色は異なるベンチマークを表し、各タスクが異なる構造クラスタ（LLM-Centric、Semantic Search、Hybrid Retrieval など）に収束することを示す

2. AutoHarness：コード Harness の自動生成による不正アクションの防止

2.1 核心的な課題：LLM における「不正アクション」のジレンマ

LLM はコード生成や数学的推論において卓越した能力を発揮しますが、厳密に定義された環境（チェスなどのゲームなど）では、しばしば不正なアクション（Illegal Moves）を提案してしまいます。最近のカグル GameArena チェス大会では、Gemini-2.5-Flash の失敗原因の 78% が不正な手に起因していました。

従来の解決策では、ゲームごとに手作業で制約コード（harness）を作成する必要があり、多大な労力を要する上にエラーも発生しやすかったのです。AutoHarness は、これらのコード制約を LLM に自動生成・最適化させることを提案します。

2.2 手法：ツリー探索とトンプソンサンプリングによるコード合成

Harness 生成をプログラム探索問題としてモデル化。探索（異なる論理構造の試行）と活用（部分的に有効な Harness の改善）のバランスを、トンプソンサンプリングで誘導されるツリー探索によって調整します。

Figure 1: Code-as-harness 学習フレームワーク。ツリー構造のノード（コード変種）がトンプソンサンプリングで選択され、評価器からのフィードバックを経て Refiner が新コードを生成する様子を示す

3 種類の Harness モードをサポートします。

harness-as-action-filter：有効なアクション候補セットを生成し、LLM が排序・選択
harness-as-action-verifier（主要実験）：LLM がアクション生成→コードが正当性を検証→不正なら再試行
harness-as-policy：戦略全体を Python コードで完全実装。テスト時はLLM 呼び出しが不要

主要なメカニズムは以下の通りです。

フィードバック駆動：環境がアクションの正当性と報酬シグナルを返す
反復最適化：エラー事例と軌跡に基づき、LLM がコードパッチ（V4A 形式）を生成
コンパイル - 修正ループ：構文エラーや実行時制約違反を自動処理

2.3 実験結果

TextArena において145 種類のゲーム（自由記述の対話系を除く）で包括的なテストを実施しました。

訓練効率：平均 14.5 回のツリー探索反復で 100% の合法アクション率に到達。32 ゲーム中 19 ゲームが 10 回以内の反復で収束しました。

Figure 2: 代表的な 6 ゲームにおけるヒューリスティック値（合法アクション率）の合成反復回数に伴う変化曲線

対戦パフォーマンス（2P ゲーム）：

Gemini-2.5-Flash + Harness vs Gemini-2.5-Pro：勝率 9/16（全体勝率 56.3% vs 38.2%）
専用 Harness を備えた小規模モデルが、より大規模なモデルを打ち負かしうることを証明

Figure 3: 16 種類の 2P ゲームにおける Gemini-2.5-Pro 戦の勝率/引き分け/敗率の棒グラフ（緑が勝ち、赤が負け）

1 プレイヤーゲーム（1P）：平均報酬 0.745 を記録。Gemini-2.5-Pro（0.707）や GPT-5.2（0.635）を上回りました。

極限モード：Harness-as-Policy：モデルに戦略全体（検証器のみではなく）のコード生成を許可した場合、16 種類の 1P ゲームで平均報酬 0.870を達成。GPT-5.2-High（0.844）を凌駕し、かつテスト時のコストはほぼゼロ（LLM 呼び出し不要）という結果でした。