何が起きたか
中国人民大学とMicrosoft Researchの研究チームが、AIによる自律最適化（Autonomous Optimization, AO）のためのフレームワーク「Arbor」を公開しました。実タスクの評価で、Codex・Claude Codeに対し同じリソース予算で平均2.5倍以上の検証可能な性能向上を記録しています。
具体的には、検索エージェントタスクBrowseCompで保留テスト精度を45.33%から67.67%へ引き上げ（Codexは50%、Claude Codeは53.33%で停滞）。Terminal-Bench 2.0では、Claude Codeが開発75→保留71と劣化したのに対し、Arborは開発72.22→保留77.36と汎化性能を上げています。MLE-Bench LiteでもGPT-5.5を用いて最高スコアを達成しました。
なぜ重要か
Claude CodeやCodexのような汎用コーディングエージェントは、「精度を上げて」と指示するとチャンク分割・プロンプト・検索手法を一度に変えてしまい、何が効いたかを特定できません。さらに記憶は会話履歴に依存するため、数百ターンに及ぶAOタスクではコンテキストを溢れて知見が散逸します。共有作業ツリー上で次々と変更を重ねるため、並行する仮説を独立に検証することもできません。
Arborの仕組み：HTRと隔離worktree
Arborは長期稼働する「Coordinator（主任研究者役）」と短命の「Executor（隔離されたGit worktreeで動く実行役）」に役割を分けます。Coordinatorはコードを直接編集せず、各Executorに一つの仮説だけを渡して実装・評価・デバッグさせます。
中核となる「Hypothesis Tree Refinement（HTR）」は、各ノードに仮説・生成物・事実証拠・蒸留された知見を束ねた木です。RAGならチャンク・検索・プロンプトがそれぞれ別の枝として隔離worktreeで評価され、「検索側の制約分解は+X、幅優先探索は逆効果」といった綺麗な因果特定が可能になります。失敗は「負の制約」として記録され、Executorの報告は親ノードへ逆伝播して汎用的な制約に昇格します。
さらに、保留テスト評価器を用いた「マージゲート」が、開発指標へのリワードハッキングや過学習をブロックします。出力は通常のGitブランチで、既存のコードレビューとCIにそのまま乗せられる点も実務的です。
💼 事業会社視点：これは自社にどう効くか
役員視点：日本企業はどこから試すべきか
Arborが効くのは「評価指標が信頼でき、探索空間が広く、長時間回せる」タスクです。日本の事業会社で現実的なのは、SaaSベンダーが抱える社内RAGや検索パイプラインのチューニング、ECの推薦・ランキング、受託開発会社のMLパイプライン改善でしょう。これらは現状、エンジニアが手作業でA/Bを回し、何が効いたか曖昧なまま納品されているのが実情です。
経営者が今動くべきは三点。第一に「評価器の整備」を最優先投資にすること。ArborはClaude Codeの2.5倍速く改善しますが、上限は評価器の質で決まります。指標がハック可能なら、悪い結果に速く到達するだけです。第二に、Gitとworktreeを多用するためトークン代とディスク・並列計算コストが嵩みます。LLM予算枠とCI基盤の見直しが必須です。第三に、リアルタイム応答や明白な一行修正には使わない判断。受託開発であれば、Arbor的ループを使うフェーズを「精度改善PoC」として切り出し、納品物は通常のGitブランチで監査可能にする契約形態が現実解です。Claude Code単体運用に依存している開発組織は、来期のAI予算の組み立てを見直す時期に来ています。
