📝 論文: "Continual Harness: Online Adaptation for Self-Improving Foundation Agents"(Karten et al., 2026, arXiv:2605.09998)
📌 まとめ
- コーディングハーネス(Claude Code, OpenHands 等)のような「ツール+メモリ+計画」の足場は、身体化エージェントの長期・部分観測環境にはまだ存在しなかった
- Continual Harness は、環境リセットなしで、エージェントが自分自身のプロンプト・サブエージェント・スキル・メモリを CRUD 操作でオンライン更新する自己改善フレームワーク
- ポケモン Red/Emerald で検証し、ゼロ知識から手作りエキスパートハーネスとの性能差の大部分を埋め、さらにオープンソースモデルとの共学習で継続的な進歩を実証
1. 🔍 背景:「ハーネス」とは何か?
1.1 コーディングハーネスの台頭
近年、基盤モデル(Foundation Model)をツール・メモリ・計画機能でラップする「ハーネス(harness)」が急速に普及しています。
| ハーネスの例 | 機能 |
|---|---|
| Claude Code | コード生成・ファイル操作・タスク計画をツールとして統合 |
| OpenHands | マルチツール・メモリ管理・計画ループ |
| Codex CLI | コマンドライン環境でのコード生成・実行 |
これらはソフトウェア開発タスクにおいて大きな成果を上げています。
1.2 身体化エージェントにはハーネスがなかった
しかし、以下のような身体化(Embodied)エージェントの課題には、同等のハーネスが存在しませんでした:
- 🕹️ 長期的な意思決定(数千〜数万ステップ)
- 👁️ 部分観測性(環境全体が見えない)
- 🔄 非決定的な状態遷移(戦闘結果のランダム性等)
💡 この論文の核心的問い: コーディングハーネスと同じように、身体化エージェントのための「自己改善型ハーネス」を作れないか?
2. 🏗️ 3段階の貢献
本論文は以下の3つの段階的貢献を提示しています:
段階1(GPP) → 人間がハーネスを反復改善(Human-in-the-Loop)
段階2(Continual Harness) → エージェントが自動でハーネスを改善(Human-out-of-the-Loop)
段階3(Co-Learning) → モデル重みとハーネスを同時にオンライン学習
2.1 🎮 段階1:Gemini Plays Pokémon(GPP)— 人間が介在するハーネス改善
GPP(Gemini Plays Pokémon) プロジェクトでは、人間がハーネスを反復的に改善しながら、GeminiベースのAIが初めて複数のポケモンRPGをクリアしました。
| ゲーム | 達成時期 | 特記事項 |
|---|---|---|
| ポケモン Blue | 2025年5月 | AIによる初のポケモンRPGクリア |
| ポケモン Yellow Legacy | 2025年8月 | ハードモード、全バトル無敗 |
| ポケモン Crystal | 2025年11月 | 完全クリア |
🌟 創発的な自己改善行動
注目すべきは、明示的に指示していないのに、モデルが自発的に以下の行動を示した点です:
- ツールの非効率性を再利用可能なプリミティブにラップ(例:移動ルーチンの自動生成)
- 名前付きの多段階戦略を自発的に開発(例:「ジム攻略3フェーズ戦略」)
- 明示的な問題表現を自ら記述(自分の状態を構造化して把握)
これらの「人間+AIの共同改善」で観測された行動パターンが、段階2の自動化の着想源になります。
2.2 🤖 段階2:Continual Harness — 完全自動のハーネス改善
Continual Harness は、段階1で観測された改善パターンを完全に自動化します。
核心コンセプト
「最小限の環境インタフェースだけから出発し、
エージェントが行動とハーネス改善を交互に繰り返す。
環境リセットは一切不要。」
既存手法との根本的な違い
| 特徴 | 従来のプロンプト最適化 | Continual Harness |
|---|---|---|
| 環境リセット | エピソードごとにリセット必要 | ❌ リセット不要(reset-free) |
| 更新タイミング | エピソード間(バッチ) | 🔄 エピソード中(オンライン) |
| 更新対象 | プロンプトのみ | プロンプト+サブエージェント+スキル+メモリ |
| 事前知識 | ドメイン知識が必要 | ❌ 不要(ゼロ知識から開始) |
| 長期情報 | リセットで失われる | ✅ 蓄積・活用される |
2.3 🧠 段階3:Model-Harness Co-Learning — モデルとハーネスの共学習
オープンソースモデル(Gemma-4, 31B dense)を使い、ハーネスの改善とモデル重みの更新を同時にオンラインで実行します。
- DAgger + Process Reward Model(PRM) によるオンライン学習
- フロンティアモデル(Gemini-3.1-pro)が教師として軌跡データをリラベル
- 環境リセットなしでトレーニングイテレーション間もゲーム状態を持続
3. 🏛️ アーキテクチャ:2重ループシステム
Continual Harness のアーキテクチャは2つのネストされたループで構成されます。
3.1 全体構造
┌──────────────────────────────────────────────────┐
│ 外側ループ(Refiner) │
│ F ステップごとに軌跡ウィンドウを分析し │
│ ハーネスの4コンポーネントに CRUD 編集を実行 │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ 内側ループ(Agent Action) │ │
│ │ 現在のハーネスで環境を観察 → 行動選択 │ │
│ │ → 行動実行 → 次の観察 → ... │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
3.2 4つのハーネスコンポーネント
ハーネス $\mathcal{H}$ は以下の4つのタプルとして形式化されます:
$$\mathcal{H} = (p,;\mathcal{G},;\mathcal{K},;\mathcal{M})$$
| コンポーネント | 記号 | 役割 | CRUD操作例 |
|---|---|---|---|
| システムプロンプト | $p$ | エージェントへの指示・戦略ガイダンス | 失敗パターンに基づくリライト |
| サブエージェント | $\mathcal{G}$ | 特定サブタスク専用モジュール | バトル用サブエージェントの作成・修正・削除 |
| スキル | $\mathcal{K}$ | 再利用可能なルーチン(ヒューリスティクス+実行可能コード) | ナビゲーションスキルの作成・修正 |
| メモリ | $\mathcal{M}$ | 軌跡全体にわたる永続的な知識 | 情報の追加・更新・古い情報の降格 |
3.3 Refiner の動作
- ウォームアップ後、F ステップごとに Refiner が起動
- 直近の軌跡ウィンドウを分析
- 以下の失敗シグネチャを検出:
- 🔁 ナビゲーションループ(同じ場所を行き来)
- ❌ ツールコールエラー
- ⏸️ 目標の停滞
- 🔍 探索の不足
- 検出した問題に対して、4つのコンポーネントに構造化された CRUD 編集を発行
-
4パスの逐次更新:
- Pass 1: システムプロンプト $p$ を失敗パターンに対してリライト
- Pass 2: サブエージェント $\mathcal{G}$ の CRUD(反復パターンの抽出、エラー修正、未使用の削除)
- Pass 3: スキル $\mathcal{K}$ の CRUD(成功シーケンスのコード化、例外修正)
- Pass 4: メモリ $\mathcal{M}$ の CRUD(ギャップの補填、古い情報の更新、通過済み領域の降格)
💡 重要: Refiner はエージェントと同じ基盤モデルを使用し、同じメタツール API で編集を行います。
4. 📊 実験結果
4.1 実験設定
- 環境: ポケモン Red、ポケモン Emerald
- モデル: Gemini 3 Pro / Flash / Flash-Lite
-
ベースライン:
- $H_\text{min}$(ミニマリスト):
press_buttons+process_memoryのみ - $H_\text{expert}$(エキスパート):手作りの A* 経路探索、タイプ相性表、ダメージ計算機、目標システム、名前付きサブエージェント等を完備
- $H_\text{min}$(ミニマリスト):
-
Continual Harness バリアント:
- from-scratch:事前知識なし、改善有効
- bootstrap frozen:前回の改善済みハーネスを読み込み、改善無効
- bootstrap updating:前回のハーネスを読み込み、改善も有効
4.2 能力依存スケーリング(核心的知見)
| モデル | 結果 | 解釈 |
|---|---|---|
| Gemini 3 Pro | ✅ ミニマリストベースラインに対してパレート優位 | 十分な能力 → 改善が蓄積 |
| Gemini 3 Flash | ⚠️ 高分散;限定的な改善 | 中程度の能力 → 改善効果は不安定 |
| Gemini 3 Flash-Lite | ❌ 全バリアントでベースライン以下 | 能力下限未達 → 改善が機能しない |
⚠️ 能力下限(Capability Floor)が存在する: モデルの基礎能力が一定の閾値に達していなければ、ハーネスの自己改善はブートストラップできない。
4.3 ナビゲーションスキルの改善
24時間にわたるランで、ナビゲーションスキルのコストが改善されました:
初期状態:ダイクストラ・オラクル比で約 50% のペナルティ
改善後 :ダイクストラ・オラクル比で一桁のペナルティ
- リセット不要の修復サイクルにより、エピソード内で持続的に改善
- CH 条件下ではスキルの呼び出し頻度も大幅に増加
4.4 オープンソース共学習の結果
| 条件 | マイルストーン進行 |
|---|---|
| SFT のみ | ❌ 進行なし |
| オフライン GRPO のみ | ❌ 進行なし |
| DAgger + PRM(完全 CH ループ) | ✅ ゲーム開始・中盤の両方から持続的進行 |
Gemma-4(31B dense) を使用。SFT やオフライン RL 単体では不十分であり、オンライン CH ループとの組み合わせで初めて進歩が実現。
5. 🔑 主要な知見
5.1 改善はボトルネックに集中する
更新操作はすべてのコンポーネントに均一に分散するのではなく、ナビゲーションやバトルなどのボトルネックコンポーネントに集中します。
→ 創発的な専門化(Emergent Specialization) が発生。
5.2 ハーネスは「転移可能な単位」
- 成功したランのハーネスを別のランに継承すると、後続ランが加速
- 継承したサブエージェントを放棄すると退行が発生
- → ハーネスが「知識の運搬容器」として機能
5.3 コンテキスト・ホライゾンの限界
- ツール生成は主にボトルネック遭遇の初期(50〜200ステップ) に集中
- 500ターン以上の停滞では、エージェントは改善を停止し実行パターンに戻る
5.4 リセット不要の回復
- 同一の失敗モードが再発した際に診断・修復が可能
- エピソード前半の改善シグナルが後半に蓄積される
6. 🚨 制限事項
| 制限事項 | 詳細 |
|---|---|
| 能力下限 | 基礎能力が低いモデルでは改善が機能しない |
| 収束の未確認 | オープンソースモデルの転移実験では、収束ポイントが未確立 |
| リセットありとの直接比較なし | バッチ蓄積(リセットあり)との直接 head-to-head 比較は未実施 |
| 評価環境 | ポケモンRPGに限定。他ドメイン(ロボティクス等)への汎化は未検証 |
7. 💻 実装・再現方法
7.1 リポジトリ
公式実装:sethkarten/continual-harness(MIT License)
7.2 セットアップ
# リポジトリのクローン
git clone https://github.com/sethkarten/continual-harness
cd continual-harness
# 環境構築(uv 推奨)
curl -LsSf https://astral.sh/uv/install.sh | sh
uv sync
source .venv/bin/activate
7.3 Continual Harness の実行
# ゼロ知識から開始(from-scratch)
python run.py \
--game red \
--scaffold continualharness \
--enable-prompt-optimization \
--optimization-window-length 50 \
--backend gemini --model-name gemini-3-pro-preview \
--port 8000 --agent-auto
# 前回のランのハーネスをブートストラップ(bootstrap updating)
python run.py \
--game emerald \
--scaffold continualharness \
--enable-prompt-optimization \
--bootstrap-from run_data/<prior_run_id>/end_state/game_state/bootstrap \
--backend gemini --model-name gemini-3-pro-preview \
--port 8000 --agent-auto
7.4 ブートストラップバリアント
| バリアント | コマンドフラグ |
|---|---|
| from-scratch |
--enable-prompt-optimization(--bootstrap-from なし) |
| bootstrap frozen |
--bootstrap-from <path>(--enable-prompt-optimization なし) |
| bootstrap updating |
--bootstrap-from <path> + --enable-prompt-optimization
|
8. 🤔 考察:なぜこの研究が重要なのか
8.1 「静的ベンチマーク」から「動的ハーネス」へ
従来のAIエージェント評価は静的なベンチマークが中心でした。しかし現実世界では環境は常に変化します。Continual Harness は、評価ハーネスそのものをエージェントの認知アーキテクチャの一部として扱う、パラダイムシフトを提示しています。
8.2 RL(強化学習)へのアンチテーゼ
従来の RL は「何百万回もの試行錯誤」を前提としていました。Continual Harness は、LLM のゼロショット推論能力を活かしつつ、ハーネスが教師・ガードレールとして機能するアプローチを提案しています。試行回数を桁違いに削減できる可能性があります。
8.3 エンタープライズ「エージェントワークフロー」への応用
長期間にわたって自律動作するエンタープライズエージェントでは、失敗コストが高く、環境リセットが現実的ではない場面が多くあります。Continual Harness の「リセット不要・オンライン自己改善」パラダイムは、まさにこうした現実的なデプロイ制約に対応します。
9. 📚 関連研究
| 論文 | 関連性 |
|---|---|
| The PokeAgent Challenge (Karten et al., 2026) | ポケモンゲームを使ったエージェントベンチマーク |
| EvoTest (2025) | テスト時学習による自己改善 |
| Hyperagents (2026) | 次世代エージェントアーキテクチャ |
| Meta-Harness (2026) | ハーネスのエンドツーエンド最適化 |
| Agentic Harness Engineering (2026) | 観測駆動型のコーディングエージェントハーネス進化 |
10. 📖 論文情報
| 項目 | 内容 |
|---|---|
| タイトル | Continual Harness: Online Adaptation for Self-Improving Foundation Agents |
| 著者 | Seth Karten*, Joel Zhang*, Tersoo Upaa Jr, Ruirong Feng, Wenzhe Li, Chengshuai Shi, Chi Jin, Kiran Vodrahalli |
| 公開日 | 2026年5月11日 |
| arXiv | 2605.09998 |
| GitHub | sethkarten/continual-harness |
| プロジェクトページ | sethkarten.ai/continual-harness |
🙏 おわりに
Continual Harness は、「AIエージェントが自分自身の動作環境(ハーネス)をリアルタイムで改善し続ける」というビジョンを、ポケモンRPGという複雑な長期意思決定タスクで実証した画期的な研究です。
特に以下の点が印象的です:
- 🔄 リセット不要:現実世界のデプロイ制約に直結
- 🧱 CRUD ベースの構造化された改善:ハーネスの各コンポーネントが独立して更新可能
- 📈 能力依存スケーリング:モデル能力と改善効果の関係が明確
- 🤝 モデルとハーネスの共学習:推論時の改善と学習時の改善を統合
今後、ロボティクスやエンタープライズエージェントなど、リセットが困難な現実環境への応用が期待されます。