メタ、8B モデルで Claude Opus 4.5 に匹敵する性能を達成

大規模な顧客レコードをレガシー CRM からクラウドデータベースへ移行するような複雑な企業ワークフローを処理する AI エージェントを想像してください。このエージェントは数時間にわたるタスクを遂行するため、内部のコンテキストウィンドウだけに頼ることはできず、ランタイム層（ハッチネス）に依存します。

このハッチネスはサーバーログなどの実行フィードバックを提供し、動的な API 接続に対するエージェントの正確な理解を維持するのを助けます。また、完了したサブゴールと保留中のサブゴールを管理するための状態追跡機能や制御フロー機構も備えており、データバッチのスキップや重複を防ぎます。データベースが厳格な API レート制限のためにバッチを受け付けないなど予期せぬエラーが発生した場合、ハッチネスは回復のためのツールと指示を提供します。

エージェントにツールの使用方法や使用タイミングを教える主な方法は、人間が開発者としてステップバイステップのルールや指示を書き込むことです。例えば、開発者は「メールを書く前に必ず社内ウィキを検索する」といった指示を与えるかもしれません。しかし、このように厳格なスクリプトに従うだけでは、エージェントに真の自律性は生まれません。行動のコストとベネフィットを自ら判断して重み付けする訓練がされていないからです。

これを解決するため、Meta AI とイリノイ大学アーバナ・シャンペーン校の研究チームは「EvoHarness-RL」というフレームワークを導入しました。これはエージェントのハッチネスに抽象化レイヤーを追加し、環境から得た情報をいつ読み込み、更新し、統合すべきかを基礎モデルに学習させるものです。

長期のタスクにおいて、AI エージェントが環境から得た情報をどのように読み込み、処理するかが成功の鍵となります。エージェントは環境への理解を更新し、完了したサブゴールと未完了のものを追跡し、失敗した行動からの回復を行い、過去の経験から手順を再利用する必要があります。この実行を支えるのが「ハネス」です。

Harness-1 に代表される一連の自己進化型エージェントフレームワークは、過去の軌跡を蓄積し、それらを再利用可能なスキルやワークフロー、コードライブラリといった構造化された手続き記憶として圧縮することで、問題の一部を解決しています。しかし、これらは通常、長期にわたるスキルの選別と、エピソード内のリアルタイムな状態追跡を分離して扱っています。つまり、作業中にエージェントが即時的な環境の現実をどう管理し、アクティブなタスクステップを追跡するかについて、積極的に訓練しているわけではありません。

EvoHarness-RL 論文の共著者である Xuying Ning 氏は VentureBeat の取材に対し、手動で記述されたロジックと硬直したメモリ構造が、エンジニアリングリソースを浪費する主な原因であると指摘しました。

「最適なハネスはモデルによって変化します」と Ning 氏は説明しています。「異なるモデルには、異なるプロンプトやメモリ設計、権限設定、サンドボックス構成が必要になる可能性があります。これらすべてのロジックを手動でコーディングする場合、モデルのアップグレードごとに、再び長いチューニングとデバッグのサイクルを余儀なくされてしまいます。」

さらに、単に経験を蓄積するだけの既存のメモリシステムは、エージェントの推論能力を逆に低下させる可能性があります。Ning氏は「追加型のメモリでは、コンテキストが多ければ多いほど有益だと考えがちですが、必ずしもそうとは限りません」と指摘します。「長いタスクにおいて、メモリには古い結論や失敗した試行、もはや関連性の低い情報が含まれている可能性があるからです」。このため、長期にわたるタスクをこなすエージェントには、過去のミスを繰り返さないよう情報を更新・圧縮・置換できる動的なメモリが必要です。

EvoHarness-RL：信念、進捗、経験を統合したワークスペース

硬直的で手動によるプロンプトの限界を克服するため、研究チームは「EvoHarness-RL」という訓練手法を導入しました。これはエージェントにハネス（支援枠組み）を最適に活用する能力を教えるものです。ハードコードされた指示を盲目的に従うのではなく、雑多な実行データから構造化されたワークスペースを構築し、複雑なワークフローの中でその外部状態をいつ、どのように参照すべきかを自ら判断できるようになります。

ハネスの各コンポーネント管理を簡素化するため、EvoHarness-RLはエージェントの支援システムを単一の統合インターフェースに集約しました。このインターフェースは「信念・進捗・経験（BPE）」と呼ばれ、エージェントが外部に求めるニーズを3つの機能領域に分類します。

信念：現在の環境を正確に把握する。

進捗：完了したサブゴールと未着手のサブゴールを管理する。

経験：タスク間で過去の知識を再利用する。

AI は複雑なドメイン固有の API を使用するのではなく、このクリーンなダッシュボードに対して 4 つのコンパクトなメタアクション（track, commit, recall, note）を通じて相互作用します。具体的には、ライブ環境を追跡するコマンドを発行し、ワークフローの更新をコミットし、行動に移す前に過去の戦略を思い出し、新たに発見した洞察を将来の実行に備えてノートとして記録します。

これらの状態は、高付加価値な企業向け業界と直接対応しています。「ソフトウェアエンジニアリングにおいて、Belief はエージェントがリポジトリに対して現在持っている理解を表します」と寧氏は説明し、エージェントがコンポーネント間の相互作用やワークスペースの変更をどのように監視するかを詳述しました。また、「Progress はすでに完了した作業、まだ着手すべきタスク、そして他のステップに依存する手順を追跡します」とも述べました。

一方、Experience は失敗に対するユーザーフィードバックなどの教訓を捉え、将来の行動を導く役割を果たします。

寧氏によると、この考え方は金融業界にも同様に適用されます。コンプライアンス監査の際には、Belief が適用されるルールと利用可能な証拠を記述し、Progress は完了したチェック項目と未解決の例外を追跡します。Experience は、エージェントが繰り返しの不整合に気づいたり、問題のエスカレーションが必要なタイミングを判断したりするのを助けます。

「これら 3 つの状態を組み合わせることで、エージェントが作業を見失ったり、同じ失敗したアプローチを繰り返したりすることを防ぎます」と寧氏は述べています。

外部ワークスペースの管理におけるメカニクスと戦略をエージェントに習得させるため、研究チームは 2 つ段階からなるトレーニング手法を設計しました。最初の段階である教師ありハルネス微調整では、ベースモデルが雑多なインタラクションログから有用な事実を抽出し、BPE フレームワークに構造化する方法を学習します。

しかし、メモリの照会やトラッカーの更新には時間と計算リソース（トークン）が必要となるため、エージェントは各ステップでツールを盲目的にチェックすることはできません。これを解決するため、2 段階目では「コスト意識型」強化学習を用いて効率性を教えます。このフェーズでは、外部状態へのアクセスが予算コストに見合うかどうかを判断する能力を訓練します。この 2 ステップのプロセスにより、ツールの使用は硬直したハードコードされたプロンプトから、学習されたランタイム挙動へと変貌します。

EvoHarness-RL の実働検証

EvoHarness-RL を検証するため、研究チームは ALFWorld ベンチマークを用いてシステムを評価しました。これは多段階タスクを含むテキストベースの環境で、シーケンシャルな論理と状態追跡能力を試すものです。

ベースモデルには Qwen3-8B を採用して訓練を行いました。チームは、訓練済みの 8B モデルを、Claude Opus 4.5、GPT-4.1、GPT-5 という 3 つの最先端大規模モデルと、ReAct、ExpeL、ReasoningBank のように静的なツールを持つ凍結されたエージェントフレームワーク、さらに標準的な GRPO、SkillOS、SkillRL といった高度な学習可能手法と比較対照しました。

その結果、小規模でコスト効率の高いモデルの性能が大幅に向上しました。EvoHarness-RL を適用した Qwen3-8B モデルは平均成功率 96.9% を達成し、ベースラインとなる ReAct 版と比較して 49.0 ポイントもの改善が見られました。

さらに、学習済みのモデルは SkillRL（89.9%）や SkillOS（80.2%）といった高度なトレーニング可能なフレームワークをも上回りました。特に企業開発者が計算コストの最適化を求めている場合、この 8B モデルは Claude Opus 4.5 のような高価なクローズドモデルの性能限界にほぼ匹敵する結果を出しました。Claude Opus 4.5 は初期状態で 96.4% のスコアを記録しています。

小規模モデルの強化だけでなく、実験からは BPE フレームワークがすべてのモデルサイズにおいて普遍的な恩恵をもたらすことも示されました。これは広範な強化学習フェーズを経なくても同様です。研究者たちは、凍結された初期状態の最先端モデルに BPE プロンプトタイムハネスを適用したところ、実行性能が著しく向上しました。GPT-4.1 の成功率は 22.1 ポイント、GPT-5 では 25.7 ポイント改善しています。

結果だけでなく、研究者たちは EvoHarness-RL のトレーニングを通じて LLM が獲得する動的な挙動を示す現象も記録しました。強化学習フェーズ中、エージェントが時間をかけて知識を内部化していく過程で行動様式の変化を観察し、これを「ハネス・アニーリング」と名付けました。

学習初期には、AI はほぼすべてのステップで「経験」および「進捗」トラッカーへの問い合わせに依存していました。しかし、定型タスクを習得するにつれて、外部ツールへの依存を積極的に減らし、成功したパターンを直接パラメータ内に埋め込むようになりました。実際の企業環境では、これはレイテンシの低下と計算コストの削減に直結します。ツール使用量を調整することで、AI はすでに習得済みの標準ワークフローのためにデータベースを照会する無駄なトークンや時間を浪費しなくなります。

同時に、エージェントは「ハネスの進化」も示しました。これは、その場の状況の複雑さに基づいて戦略を動的に適応させるものです。シンプルで慣れ親しんだタスクではツールを迂回しますが、未知の環境や予期せぬ障害に直面した瞬間、積極的に「信念」および「経験」モジュールの使用を拡大します。例えば、AI エージェントが標準的なデータベースレコードを移行する際は高速で処理を進めます。しかし、奇妙なレガシー API エンドポイントや複雑な検証エラーに出会うと、処理速度を落とし、ライブサーバーログを確認し、過去のチケットを検索して安全にエッジケースを解決します。推測で誤った回答（ハルシネーション）をするのではなくです。

EvoHarness-RL を既存システムへ統合する

これらの大きな進歩にもかかわらず、新しいフレームワークの導入は、企業のエンジニアリングチームにとって摩擦を生むことがあります。しかし、EvoHarness-RL は環境アダプターを活用しており、組織が既存のツールに特化した内部実装を維持しつつ、学習可能な層のみを共有することが可能です。

「BPE を既存のオーケストレーションシステムに統合する大きな可能性があると私は考えています」と寧氏は述べています。「必ずしもチームが現在のツールやエージェント・フレームワークを置き換える必要はありません。BPE は、エージェントが現在何を信じているか、どこまで進捗したか、そして何を学んだかを継続的に整理する、追加のステート管理レイヤーとして機能します。」

推論コストを懸念する企業向けビルダーにとって、このフレームワークは統合に伴う隠れたエンジニアリングコストに対処します。統合には高度な推論能力が求められるため、チームは予算を最適化するためにハイブリッドで非同期のアーキテクチャを採用できます。

「一つの現実的な妥協案として、最先端モデルを使用して高品質な統合データを生成し、その後、一般的なステート管理を担当させるために、高性能なオープンウェイトモデルを微調整する方法があります」と寧氏は説明します。さらに、「統合は非同期で実行できるため、必ずしもエージェントの主要な実行ループを遅らせる必要はありません。」

チームはまた、学習可能な BPE ハーネスが必要となる場合と、それがやりすぎになる場合を慎重に評価する必要があります。

「短期かつ安定したタスクであれば、ReAct や標準的な RAG でも十分対応できる」と寧氏は語る。「BPE が真価を発揮するのは、エージェントが数時間から数日、あるいは数週間にわたって作業を継続するケースだ」。

こうした複雑なシナリオでは、エージェントは迷走しないよう意思決定の要点を圧縮して理解しておく必要がある。そのために「経験（Experience）」を活用し、過去の失敗や人間のフィードバックから反復的に改善していく仕組みが求められる。

最終的にこのアプローチは、AI オーケストレーションエンジニアにとって大きな転換点を示している。「ワークフロー工学を完全に置き換えるものではない」と寧氏は説明する。「むしろ、エージェントの振る舞いを直接スクリプトで記述する手法から、より優れた行動を学習できるシステムを構築する方向へ移行していくのだ」