AI-Papers
- 仮説・実験結果・証拠・知見を1本のツリーで累積管理する「仮説ツリー精練（HTR）」を提案し、6つの実研究タスク全てでCodexやClaude Codeを上回った
- 長期存続するCoordinatorと短命なExecutorを分離した設計により、Claude Code比で平均2.5倍以上の改善率を達成した
- MLE-Bench LiteではGPT-5.5バックボーン使用時にメダル獲得率86.36%を記録し、コードはオープンソースとして公開済み
研究の背景
AI研究の自動化は、仮説立案から実験実行、結果の解釈まで一連のプロセスをAIエージェントに委ねる試みです。しかし既存の単一エージェント型アプローチには根本的な制約がありました。1回の試行で得た知見を次の試行へ引き継ぐ仕組みがなく、長期的な探索が事実上不可能だったのです。
Claude CodeやCodexのような汎用コーディングエージェントは、与えられたタスクを単発で実行することは得意ですが、複数の実験を通じて累積的に学習しながら研究を進めることはできません。過去の失敗から得た洞察が次の仮説に反映されないため、同じような試行錯誤が繰り返されがちです。
中国人民大学NLPIR Labが発表したArborは、この問題を「仮説ツリー」という木構造のデータ管理で解決します。仮説・実験の成果物・証拠・洞察を時系列でツリーに累積することで、AIエージェントが長期にわたって体系的な研究を進められるよう設計されています。
Arborフレームワークの構造
Arborは役割の異なる2種類のエージェントで構成されます。Coordinator（調整役）は研究セッション全体を通じて存在し続け、仮説ツリーの管理と戦略的な意思決定を担います。一方、Executor（実行役）は1つの仮説に対して起動され、実装と検証を終えると消滅する短命な存在です。
Coordinatorは、次の6段階のサイクルを回して仮説ツリーを更新します。
- Observe: 現在の探索フロンティアを把握する
- Ideate: 親ノードから複数の子仮説を生成する
- Select: 次に実行する候補を戦略的に選択する
- Dispatch: 選んだ候補をExecutorに割り当てる
- Backpropagate: 実験結果を受け取り、親ノードまで洞察を伝播させる
- Decide: 候補を採用するか否かを判定する
このサイクルを繰り返すことで、個々の実験で得られた知見がツリー全体に蓄積されていきます。
ツリーの各ノードは3つの要素から成ります。「仮説（h）」は検証可能な改善案、「洞察（ι）」は子ノードの実験結果から親レベルに抽象化された再利用可能な知見、「メタデータ（μ）」はスコアやgitブランチ参照などの管理情報です。内部ノードは抽象的な研究方向と蓄積された教訓を保持し、葉ノードが実際に実行可能な候補を表します。
開発用評価器（探索に使用）と保持テスト評価器（採用判定に使用）を厳密に分けている点も、Arborの設計の要になっています。開発フィードバックが探索を導く一方、最終的な採用判定はテストセットのスコアに基づくため、開発セットへの過学習的な最適化を防げます。
実験結果と性能比較
Arborは「自律最適化（AO）タスクスイート」と呼ぶ6つの実研究タスクで評価されました。モデル訓練（オプティマイザ設計、アーキテクチャ設計）、ハーネス工学（Terminal-Bench 2.0、BrowseComp）、データ合成（Search-Agent Data、Math-Reasoning）の3領域にまたがる実践的な構成です。
比較対象はCodex（GPT-5.5バックボーン）とClaude Code（Claude Opus 4.6バックボーン）の2つの単一エージェント型ベースラインで、Arborは6タスク全てで最高スコアを記録しました。代表的な2タスクの数値は次の表の通りです。
項目 | Arbor | Codex | Claude Code |
|---|---|---|---|
Math-Reasoning Data Synthesis の改善幅 | +19.79ポイント | +5.21ポイント | +7.29ポイント |
BrowseComp の保持テスト精度 | 67.67% | 50.00% | 53.33% |
改善幅でも保持テスト精度でも、Arborは単一エージェント型のベースラインを明確に上回りました。
さらにKaggle競技に準拠したMLE-Bench Liteでの評価では、GPT-5.5バックボーン使用時にArborがメダル獲得率86.36%を達成しました。バックボーンモデルを替えた追加実験からは、Arborの枠組み自体がモデルを問わず機能することも確認されています。
一方で、Arborを実際に導入する際にはいくつかの制約を考慮する必要があります。Coordinatorは仮説ツリー全体をコンテキストとして保持するため、ツリーが肥大化するにつれてコンテキストウィンドウの上限に達する可能性があります。
また各タスクには開発用の評価関数が別途必要であり、評価指標が明確でないタスクや複数の目的を同時に最適化したいケースには現状そのまま適用できません。現在の設計はスカラー値のメトリクスを前提としており、多目的最適化への対応は今後の課題として挙げられています。
まとめと今後の展望
Arborが示した核心は、AI研究エージェントの能力が「単発の実行力」よりも「累積的な学習構造」に依存するという点です。仮説ツリー精練という仕組みを加えるだけで、同じバックボーンモデルを使っても性能が大幅に向上しました。Sakana AIがAIでAIを開発する専門チームを設立したように、AI研究自動化への関心は急速に高まっており、Arborはその実用的な実装例として位置づけられます。
今後の課題としてまず挙げられるのが、実験時間スケールの拡張です。現在の評価は48時間のウォールクロック制限下で行われており、週単位・月単位での継続的な自律実験には対応していません。長期運用を実現するには、Coordinatorのコンテキスト管理戦略の刷新や、仮説ツリーの圧縮・要約機構の開発が必要になるでしょう。
ドメインの汎化性向上も次の焦点です。現在の評価は機械学習タスクに集中しており、物理・化学・生命科学など評価関数の設計が難しい領域への適用には追加の工夫が求められます。また仮説ツリーにおける洞察は現在自然言語で表現されていますが、形式的な知識表現へ移行すれば、知見の再利用精度がさらに高まる可能性があります。
論文は「進行中プロジェクトの生きた技術報告書」として位置づけられており、今後も継続的に更新される予定です。コードはGitHubで公開済みであり、研究コミュニティが実際のタスクでフレームワークを試しながら改善を積み上げていける基盤が整っています。
論文情報: "Toward Generalist Autonomous Research via Hypothesis-Tree Refinement"（Jiajie Jin et al., 2026） arXiv:2606.11926, CC BY-SA 4.0
本記事の図（図1〜図3）とサムネイルは上記論文より引用しています（縮小・形式変換あり）。
