元論文: Recursive Agent Harnesses
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆した合作です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
この論文は、サブエージェントを『便利な並列実行』ではなく、ハーネス構成の再帰として扱う。これは、コーディングエージェントや定期実行のような実運用にかなり近い。
個人 AIアシスタントの運用では、単にモデルに長い文脈を渡すだけではなく、wiki、元資料、画像、公開リポジトリ、スケジューラー、スキル、外部検索をまたいで作業する。RAH の見方を使うと、仕事をモデル呼び出しに分けるのか、完全なハーネスを持ったサブエージェントに分けるのかを判断しやすくなる。
また、RAH は『モデル能力の差』ではなく『同じモデル基盤でハーネスを変えた差』を測ろうとしている。これは、エージェント改善をプロンプトやモデル選択だけに寄せず、実行環境・道具・状態・集約の設計として扱うための足場になる。
この論文の問いは、長大な文書や大量の独立エントリを処理する時、再帰する単位を何にすべきかである。従来の再帰型言語モデルはモデル呼び出しを再帰させるが、そこにはファイル操作、コード実行、外部ツール、計画、実行環境がない。
一方でコーディングエージェントは 完全なハーネスを持つが、何千ものエントリを一つの文脈で扱おうとすると、個別エントリごとの LLM 推論を諦め、正規表現や単純なスクリプト処理へ寄りやすい。つまり、モデル再帰は道具が弱く、単一ハーネスは分解が弱い。
再帰的エージェントハーネス (RAH) は、この間をつなぐ。親エージェントが作業量を見て、少数なら JSON 形式のツール呼び出し、多数なら自分で実行スクリプトを書き、そのスクリプトから多数のサブエージェントハーネスを並列生成する。各子は独立した作業領域、読み取り、書き込み、検索、コード実行、web 検索、計画、さらに孫エージェント生成能力を持つ。
評価は Oolong-Synthetic の 199 サンプル、1K から 4M トークンの 13 個の文脈長区分で行われる。GPT-5 基盤を固定した比較で、Codex 風のコーディングエージェント基準 71.75% に対し、RAH は 81.36% に到達する。同じ設計を Claude Sonnet 4.5 に載せると 89.77% まで伸びる。
読む価値は、単にサブエージェントを増やせばよいという話ではない点にある。どの粒度を再帰単位にするか、どこでツール呼び出しではなく実行スクリプトによる制御にするか、どう隔離し、どう集約し、どこで深さ、費用、遅延を制御するかを考えるための論文だ。
再帰的エージェントハーネスは、再帰的エージェントハーネス (RAH) とハーネス再帰を命名し、長文脈推論で評価する論文である。
RAH の中心は、再帰単位をモデル呼び出しではなく、完全なエージェントハーネスにすること。完全なハーネスとは、ファイルシステムツール、コード実行、計画、サブエージェント起動を持つ実行単位を指す。
論文は、Oolong-Synthetic という長文集約ベンチマークを使い、コーディングエージェント、再帰型言語モデル、RAH を比較する。狙いは、新しい基盤機能を発明することではなく、既に現れつつあるコード起点のサブエージェント起動パターンに名前を与え、制御された比較で測ることにある。
何が問題だったのか
長い文書や大量の独立項目を扱う時、単一のエージェントが全部を読む設計には限界がある。文脈が長くなり、作業単位が増え、どこまで終わったかの管理も難しくなる。
単純にモデル呼び出しを増やすだけでは不十分である。サブタスクへの分解、状態管理、結果の統合、失敗時の再実行まで含めた実行単位が必要になる。つまり再帰させる対象はモデル単体ではなく、ツールや状態を持つハーネス全体である。
Recursive Agent Harnesses が扱う問題は、エージェント作業をどの粒度で分解し、完全なハーネスを再帰的に呼び出すと何が良くなり、どこで弱くなるかを明らかにすることにある。
既存の再帰的モデル研究は、モデル呼び出しや推論構造に注目しがちだった。しかし実務のエージェントでは、ツール、状態、サブタスク、統合、失敗処理を含むハーネス全体が作業単位になる。
Recursive Agent Harnesses は、再帰させる単位をモデルではなく完全なハーネスに置く。長い文書や多数エントリを扱う時に、親が分解し、子ハーネスが処理し、結果を統合する設計を評価する点が差分である。
提案手法の中身
入力は、長大な文書と、そこに散らばる多数の独立エントリから答えを集約するタスクである。親エージェントはまず文書と作業量を見て、どの粒度で分解するかを決める。
少数のサブタスクなら、親は Task ツールを JSON 形式の構造化呼び出しとして直接呼ぶ。これは 1 から 5 エントリ程度の軽い仕事向けで、スクリプト生成コストを避ける。
項目数が多いなら、親は実行可能なスクリプトを書く。スクリプト内で Task(description, プロンプト) を多数作り、asyncio.gather のような並列実行でサブエージェントハーネス群を起動する。
各サブエージェントは、独立作業領域、ファイル読み書き、一覧、検索、コマンド実行、Web 検索、計画ステップを持つ。兄弟サブエージェントとは文脈や記憶を共有せず、結果を構造化された JSON 記録として出す。
必要ならサブエージェント自身も同じ起動能力を使って孫エージェントを作れる。再帰の深さは設定可能な上限で制限され、論文では既定値 3 とされる。
親は共有出力ファイルや集約された標準出力から結果を集め、最終回答へ整形する。これにより、個別エントリごとの推論とツールアクセスを保ちながら、長大コーパスを分解できる。
どうやって確かめたのか
評価では、Oolong-Synthetic という長文集約ベンチマークを使う。サンプル数、文脈長の区分、1K から 4M トークンまでの入力長を分け、長い入力ほど再帰型ハーネスが効くかを見る。
比較対象は、同じ基盤モデルを使った通常のコーディングエージェント、再帰型の言語モデル、RAH である。同じモデル基盤で比べることで、モデル差ではなくハーネス構成の差として読めるようにしている。
測る指標は、長文集約タスクの正解率、文脈長ごとの劣化、サブエージェント分割と親エージェント集約がどれだけ効くかである。
結果はどうだったのか
Oolong-Synthetic 199 サンプル、13 個の文脈長区分、1K から 4M トークンで評価される。
GPT-5 基盤固定で、Codex 風のコーディングエージェント基準は 71.75%、RAH は 81.36%。同じモデル基盤なので、差はハーネス構成によるものとして読める。
Claude Sonnet 4.5 を基盤にすると、同じ RAH 設計で 89.77% に到達する。論文は、ハーネス再帰がモデル品質と競合するのではなく、組み合わさって伸びる可能性を示す。
回答種別ごとには、USER、COMPARISON、LABEL が 86% 超で強い。一方、NUMERIC は 69.33%、DATE は n=5 で 60.00% と不安定で、数値カウントや小サンプルの影響が出る。
文脈長ごとの結果では、Sonnet 4.5 は 524K トークンまで 86% 超、4M トークンでも 76.7%。ただし区分ごとのサンプル数は 14 から 16 なので、精密な順位ではなく傾向として読むべき。
限界・注意点
- RAHは、サブエージェントを増やす万能薬ではない。親が起動スクリプトを書かず直接答えてしまうと、単一コーディングエージェントに戻ってしまう。
- コストはサブエージェント数に依存する。論文はプロンプトキャッシュが効く可能性に触れるが、GPT-5 設定での正確なトークン数や遅延の詳細は未計測である。
- 評価は Oolong-Synthetic に限られる。Oolong-Real や、証拠が曖昧でエントリごとの抽出が単純でない領域にそのまま一般化できるかは未確認である。
- コード実行による起動と JSON 形式のツール呼び出しによる起動、再帰の深さ、サブエージェントあたりの投入件数などの設計要素の除去実験はまだない。どの部品がどれだけ効いたかは、今後の検証が必要である。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、長い調査や大量ファイルの確認を一体の作業として抱え込むと崩れやすい。分解、委任、統合、再実行をハーネス単位で設計する必要がある。
Recursive Agent Harnesses 的に見るなら、サブタスクへ投げる対象は単なるプロンプトではなく、ツール、状態、検証を持つ小さな実行環境である。長文処理や大量候補整理に使える視点になる。
Q&A
Q. この論文の中心問いは？
長大なコーパスを分解して推論する時、再帰単位は素のモデル呼び出しでよいのか、それともツールと作業領域を持つ完全なエージェントハーネスにすべきか、という問い。
Q. 再帰的エージェントハーネスとは何？
親エージェントが、ファイル操作・コード実行・計画・サブエージェント生成を持つ完全なハーネスを子として起動し、その子も必要に応じて同じ能力を再帰できる設計。
Q. 普通の複数エージェントと何が違う？
会話する複数エージェントというより、完全なハーネスを再帰単位にして、実行スクリプトから多数の独立サブエージェントハーネスを並列起動し、結果を構造化して集約する点が中心。
Q. なぜ JSON 形式のツール呼び出しだけでは足りない？
API の 1 ターンあたりのツール呼び出し上限があり、大量の独立エントリを処理するには足りない。RAH は親が実行可能なスクリプトを書くことで、サブエージェント起動の規模を作業量に合わせる。
Q. 評価では何が改善した？
Oolong-Synthetic 199 サンプルで、GPT-5 基盤固定の Codex 風コーディングエージェント基準 71.75% に対し、RAH は 81.36% になった。Claude Sonnet 4.5 では 89.77%。
Q. 改善はモデル差ではないと言える？
少なくとも GPT-5 基盤固定の比較では、Codex 基準と RAH が同じ基盤を使っているため、差はハーネス構成によるものとして設計されている。
Q. どこが弱い？
NUMERIC 回答種別は 69.33% と低めで、カウント誤差がスコアに響く。DATE は n=5 で小さすぎる。親が起動スクリプトを書かず直接答える失敗もある。
Q. 実運用に引くなら何が大事？
サブエージェントを増やすこと自体ではなく、どの仕事を完全なハーネスに分解するか、どこでスクリプトによる実行制御にするか、結果をどう隔離・集約・検証するか。
Q. この論文の限界は？
評価は Oolong-Synthetic 限定で、Oolong-Real や曖昧な証拠が多い領域への一般化は未確認。コストと遅延の詳細計測、設計要素の除去実験も残っている。
Q. 関連する論点は？
HyperTool、SkillJuror、What makes a ハーネス a ハーネス、Code as Agent Harness を並べると、ツール粒度、スキル編成、ハーネス境界、ハーネス再帰がつながる。
関連する記事
- コードをエージェントの実行基盤として使う は、コードをエージェントの状態、検証、協調の基盤として扱う記事である。Recursive Agent Harnesses のコード実行起動と合わせると、コードを生成物ではなく実行環境として見る視点が強くなる。
- エージェントハーネスとは何か は、ハーネスの境界、役割、構成要素を整理する記事である。再帰的にサブエージェントを呼ぶ設計が、ハーネス設計のどこに位置づくかを確認しやすい。
- SkillJuror や HyperTool は、スキル評価やツール粒度の設計と近い論点を持つ。Recursive Agent Harnesses と並べると、サブエージェント分割、ツール粒度、ハーネス境界を同じ設計問題として見やすい。