arbor

Arbor — 仮説ツリーの洗練による自律的最適化

概要

このスキルは、**自律的最適化（AO）**のループを実行します。既存の成果物と測定可能な目標を出発点として、段階ごとに人間が監督しなくても、フィードバック信号に過剰適合することなく、何度も実験と評価を繰り返して改善します。優れた変更を一つ書くことではなく、数十回の試行を体系化し、得られた教訓を消え去らせずに蓄積することがボトルネックとなる場合に適したツールです。

このスキルは、Arbor（Jin et al., 2026）に基づく仮説ツリーの洗練（HTR）を実装します。要点は、研究の状態を会話履歴ではなく、永続的な仮説ツリーに保持することです。各ノードには、仮説、そこから得られた要約済みの知見、それを実現する成果物のバージョンへのポインターが紐づけられます。長期にわたってこのツリーを管理し、探索する場所を決めるコーディネーターを担います。一方、短期間の実行者サブエージェントは、それぞれ隔離された git ワークツリーで仮説を一つずつ検証し、結果を報告します。ホールドアウト・マージゲートは、探索で最適化の対象としていないテスト評価器で改善が確認された場合に限り、変更を受け入れます。これにより、試行錯誤が累積的で監査可能な研究へと変わります。

すべての記録管理（ノードの作成、根拠の記録、知見の伝播、枝刈り、マージゲート、Observe 投影）には、状態管理ツール scripts/tree.py を使用してください。これにより状態の一貫性が保たれ、根拠が何を意味するかの判断に集中できます。

このスキルを使用する場面

評価器のもとで具体的な成果物を反復的に改善するタスクでは、Arbor を使用してください。

• モデルのトレーニング：損失を下げたり、より少ないステップで目標を達成したりするためのオプティマイザー、アーキテクチャ、レシピの変更。
• ハーネス／エージェントのエンジニアリング：エージェントのループ、検索ハーネス、またはツール使用の足場の合格率や精度の向上。
• データ合成：下流のモデルの挙動で評価される生成／フィルタリングパイプラインの改善。
• ベンチマーク最適化：MLE-bench／Kaggle 形式の「提出物を改善する」タスク。
• 出力を自動採点できる場合のプロンプト／システム最適化。

見分けるポイントは、変更可能な成果物、目標、候補を採点する方法があり、多くの実験を実行する見込みがあることです。ユーザーが単一の修正や一度きりの回答だけを求めている場合、これは過剰です。そのまま作業を進めてください。評価器のない自由なアイデア出しを求めている場合は、代わりに hypothesis-generation または scientific-brainstorming を使用してください。

AO のセットアップ — まずここを確定する

実験を始める前に、タスクの組 (M_0, O, E_dev, E_test) を確立してください。ここを正しく設定することは、その後のどの判断よりも重要なので、明示的に確認してください。

• M_0 — 初期素材：改善する成果物（リポジトリ、スクリプト、設定、プロンプトなど）。git 管理下にあり、現在実行できることを確認してください。
• O — 目標：自然言語での目標と、指標の方向（精度を最大化するのか、損失／ステップ数を最小化するのか）。
• E_dev — 開発用評価器：探索中に自由に実行して候補を採点できるコマンドです。高速で、再現性がある必要があります。
• E_test — ホールドアウトテスト用評価器：マージゲートでのみ使用する、別個の評価器です（異なるシード、異なる分割、またはより大規模な実行など）。探索のオラクルとして使用してはいけません。これが重要なポイントです。

ユーザーから明確な開発／テスト分割が示されていない場合は、自分で作成し、そのことを伝えてください。開発／テストの分離は過剰適合を検出する仕組みです。開発用では勝ってもテスト用では勝てない候補は成功ではなく、フィードバック信号を悪用しているという警告です。この分離がなければ、自律的探索は確実に過剰適合します。

実行を初期化します。

python scripts/tree.py init \
  --objective "Improve BrowseComp answer accuracy on the search harness" \
  --dev-eval "python eval.py --split dev --n 50" \
  --test-eval "python eval.py --split test --n 300" \
  --material "." --metric-direction max --branching 3 --max-depth 2 --budget 12

--branching は、親ごとに提案する兄弟仮説の数です。--max-depth 2 は、方向性を深さ 1 に、具体的な介入を深さ 2 に保ちます（論文の既定値）。--budget は、コーディネーターのサイクル数です。まずは少なめ（10～20 サイクル）から始めてください。構造化された探索は総当たりより効果的で、進展が続いていれば後から延長できます。

コーディネーターループ

6 つのステップを繰り返すサイクルを実行します。これが HTR の中核です。場当たり的な編集に置き換えないでください。予算を追跡するため、各サイクルで python scripts/tree.py cycle を 1 回実行します。

1. 観察する

すべてのサイクルを、会話の記憶ではなくツリーを改めて確認することから始めます。

python scripts/tree.py observe

ここでは、目的、全体的な洞察、アクティブなフロンティア（選択可能な仮説）、根拠とともに実行されたノード、枝刈りされた教訓（否定的な制約）、現在の最良の成果物が表示されます。ツリーを信頼できる情報源として扱うことで、コンテキストの圧縮によって詳細が失われた後も、長い実行のあいだ一貫性を保てます。

2. 仮説を立てる

有望な親ノードを選び、その下にいくつかの子仮説を提案します。ツリーの根拠を踏まえてください。これが Arbor とランダム探索の違いです。

• 検証済みの洞察は、そこから組み立てられる前提です。
• 枝刈りされたノードは、避けるべき行き止まりです。
• 「半分正しい」結果は、方向性を諦める理由ではなく、より精緻な仮説の出発点です。

各仮説は、あいまいな意図ではなく、成果物を変更すると指標がどう変化するかについて、反証可能な主張にしてください。深さ 1 のノードは広い方向性（「検索ハーネスが、すでに取得した正解を取りこぼしている」）、深さ 2 のノードは具体的で実行可能な介入（「独立したロールアウトを K=5 回実行し、多数決ではなく根拠資料一式を使って集約する」）です。

python scripts/tree.py add-node --parent n0 --hypothesis "Verification, not retrieval, is the bottleneck: candidates are found but discarded"
python scripts/tree.py add-node --parent n4 --hypothesis "Decompose the question into atomic constraints and verify each independently"

3. 選択する

次に実行する保留中のリーフを選びます。選択はスコアの最大化だけで決めるものではありません。事前の根拠が強い仮説、その兄弟ノードで明らかになった曖昧さを解消できる仮説、または失敗によって重要な前提が明らかになる仮説を選びます。フィードバックが遅れる状況でのフロンティア制御では、有望さだけでなく、有益な情報が得られる実験が重視されます。

4. 実行を依頼する

選択した仮説はそれぞれ、分離されたワークツリー内の実行サブエージェントとして実行します（isolation: "worktree" を指定して Agent ツールを使うか、実行担当に git worktree add で作成させます）。分離は重要です。並行実験が互いの変更や現在の最良の成果物を上書きせず、探索的な変更をマージゲートに合格するまで隔離しておくためです。

独立している兄弟ノードは並行して実行を依頼します（1 つのメッセージ内で複数の Agent 呼び出しを行います）。同じ方向性の中で得られる比較根拠があってこそ、その後の枝刈りや抽象化が可能になります。

各実行担当には、簡潔で仮説に厳密に結び付いた指示を与えます。完全なテンプレートについては references/executor-brief.md を参照してください。HTR を機能させる契約上の要点は、指標が伸び悩んでも、実行担当が仮説を変更してはならないことです。自分のコードを修正して再実行することはできますが、h_n は固定です。そうしないと、返されたスコアが割り当てられたノードに関する根拠ではなくなり、ツリーの意味が崩れます。実行担当が返すものは、次の 4 つに限られます。

• dev_score — 開発用評価器の結果（選択に使用します）。
• result — 起きたことの事実に基づく要約。
• insight — 再利用可能な教訓として抽出された内容（その結果が仮説をなぜ支持、弱化、または限定するのか）。
• branch_ref — 成果物を含む Git ブランチ、コミット、またはワークツリーのパス。

実行を依頼する前に、ノードを running に設定します（tree.py set-status --node n5 --status running）。こうすることで、観察時の表示が正確に保たれます。

5. 逆伝播

実行者から結果が返されたら、その報告をノードに記録し、教訓を上位へ抽象化します：

python scripts/tree.py set-evidence --node n5 --dev-score 70.0 \
  --result "K=5 dossier aggregation recovers answers in minority rollouts" \
  --insight "Correct answers often appear in a minority of rollouts; aggregation beats majority vote" \
  --branch-ref "wt/n5"

python scripts/tree.py propagate --node n5 \
  --insight "Candidate coverage, not verification, limits this direction" --to-root

このステップによって、ツリーは単なるログ以上のものになります。葉ノードレベルの観察（「データインターフェースの不一致」）は、方向性レベルの制約となり、一般化できる場合は、今後のアイデア創出を形作るグローバルな事前知識になります。インサイトの伝播は、HTRの成果向上を最も大きく支える要素です。論文のMLE-Bench Liteアブレーションでは、インサイトのフィードバックがないツリーは、ツリーを使わないフラットな実験キューよりも低いスコアでした（全システムの81.8%に対し、メダル獲得率は54.5%対63.6%）。階層構造だけでは不十分で、重要なのは意味的なメモリです。そのため、抽象化には十分に考えを巡らせてください。葉ノードのインサイトをそのまま上位にコピーするだけではいけません。

6. 判断

新しい証拠に基づき、方向性の探索を続けるか、仮説が否定されたサブツリーを剪定するか、候補のマージを試みるかを判断します。

• 剪定 — 行き止まりになった枝を、理由を記録したうえで剪定します。その理由は否定的な制約となります：

  python scripts/tree.py prune --node n7 --reason "search-augmented judge overfits dev questions; no test transfer"
  

• マージゲート — 候補を新たな最良案に昇格させるのは、E_testを改善する場合に限ります。リークを避けるため、開発用ワークツリーではなく、新しいワークツリーでテスト評価を実行し、次に：

  python scripts/tree.py merge --node n5 --test-score 67.67 --branch-ref "wt/n5"
  

  ゲートで却下された場合も、有益な情報です。開発用データで高スコア、テストデータで低スコアの候補は、汎用性のある改善ではなく、方向性が開発用シグナルを利用している可能性を示す証拠です。その教訓を記録し、黙って昇格させることは避けてください。

予算を使い切る、フロンティアを探索し尽くす、または進展が明らかに停滞するまで繰り返します。

実行の完了

停止する際は、次の内容をまとめた短いレポートを作成します（references/report-template.mdを参照）。

• 最終的な最良の成果物、そのテストスコア、およびM_0からの差分。
• 試した内容の監査証跡となるツリー（python scripts/tree.py status）。
• 主な仮説の変化 — 実行を通じてタスクへの理解がどのように深まったか（初期ノードでは幅広いメカニズムを検証し、後期ノードではその限界を見いだし、祖先ノードのインサイトがそれらを最終設計の根拠となる制約にまとめていきます）。
• マージされた候補と探索された候補の違い — 開発用データでは改善するノードは多くても、テストゲートを通過するノードははるかに少ないため、開発用データでの成果を誇張せず、その差を正直に報告します。

M_bestは、名前付きブランチ上の実際に実行可能な成果物として必ず残し、ユーザーにチェックアウト方法を伝えてください。

これを機能させる原則（機械的なルールではありません）

これらは論文の分析から得られた原則です。機械的に従うことよりも、その理由を理解することが重要です。

• ツリーがメモリであり、会話はそうではありません。 長期にわたる実行では、コンテキストが圧縮されます。判断の根拠を、情報が失われやすい要約ではなく、永続的な証拠に置くため、各サイクルで改めて観察してください。
• サンプリングを増やすのではなく、構造化して探索します。 Arborの成果向上は、トークンの消費量ではなく、競合する仮説を維持し、兄弟ノードを比較し、教訓を引き継ぐといった、予算の構成方法から生まれます。やみくもに枝分かれさせず、各実験はツリーにすでに蓄積された知見を踏まえて行ってください。
• 開発用データで方向を定め、テストデータで採否を決めます。 開発用データからのフィードバックを探索の指針として自由に活用しますが、テストで確認されていない開発用データでの成果を最終成果物に反映してはいけません。開発用データとテストデータの不一致そのものも、読み取る価値のあるシグナルです。
• 実行者は仮説に拘束されます。 ローカルなエンジニアリング上の柔軟性（編集、デバッグ、再実行）は問題ありませんが、より良い数値を追って仮説を密かに変更してはいけません。そうすると、証拠の意味が損なわれます。
• 失敗はノイズではなく制約です。 仮説が否定されたことで、解決策が避けるべきことが明らかになります。理由を残して剪定した枝は、剪定して忘れた枝よりも価値があります。

参考ファイル

• references/htr-methodology.md — HTR、ノード構造、6つのステップ、および論文から得られた実証的な知見（アブレーション、転移、コスト）について詳しく説明しています。設計上の選択の根拠を知りたい場合にお読みください。
• references/executor-brief.md — 各実行担当サブエージェントに渡すブリーフのテンプレートです。
• references/report-template.md — 最終レポートの構成です。
• references/arbor-upstream.md — RUC-NLPIR/Arbor のスタンドアロン arbor CLI を使って、ネイティブにオーケストレーションする代わりにインストールして実行する方法と、それぞれを選ぶべき状況について説明しています。

エージェントの運用手順

1. 環境を確認します。 目的、評価指標、予算（時間、計算資源、費用）、停止条件を確認します。
2. 入力を明確にします。 データまたはユーザーから、形式、識別子、パラメーターを確認します。結果に影響する値を推測せず、質問してください。
3. まず小規模に実行します。 1回分を最初から最後まで実行し、規模を拡大する前にログを確認します。
4. 上記の手順と参考資料を使用して、タスク全体を実行します。
5. 結果を検証します。 保留データで評価し、各反復、仮説、結果の監査証跡を残します。
6. 報告します。 実行した内容（バージョン、コマンド、パラメーター）、確認した事項、未確定の事項を明記します。

発生した場合	対応
反復で不自然に大きな改善が見られる	結果を受け入れる前に、データ漏洩や評価のバグがないか確認します。
これらの手順に記載された関数、フラグ、エンドポイントがインストール済みバージョンにない	インストール済みバージョンのドキュメント（help()、--help、公式ドキュメント）を確認して対応し、ユーザーに伝えます。APIを捏造してはいけません。
必須の入力、識別子、パラメーターが曖昧である	ユーザーに質問するか、実行前に仮定を明示します。

誠実性に関するルール

• 結果、パラメーター、識別子、引用、統計値を捏造してはいけません。実行または検証できない場合は、その旨を明確に伝えます。
• 否定的な結果も記録し、好ましい実行結果だけを選んだり報告したりしてはいけません。
• ここに記載されたバージョン固有の詳細は古くなっている可能性があるものとして扱い、インストール済みバージョンの公式ドキュメントで確認します。
• 費用が発生する操作、共有GPUやクラウドクォータを消費する操作、個人データや患者データを扱う操作、取り消せない操作を行う前に、必ず確認を求めます。

関連スキル

• research-skill-creator：論文執筆、ラボのプロトコル、分析パイプライン、ドメインデータベースなど、研究ワークフロー向けのエージェントスキルを作成、改善、テストします…
• statistical-analysis：研究データの統計分析をガイドします。検定の選択、仮定の確認、効果量、検出力分析、ベイズ的代替手法など…
• nextflow：Nextflow のデータパイプラインと nf-core ワークフローを、最初から最後まで構築、実行、デバッグします。