exploratory-autoresearch

探索的オートリサーチループ

このループは高速で動作します。標準の ml-autoresearch と同様、実験のたびに診断分析が行われます。異なるのは、各イテレーションでの変更の「種類」がエージェントの直感ではなく、温度スケジューラーによって決まる点です。初期段階では、大きく多様な変更（全面的な書き換え、根本的に異なるアーキテクチャや学習方式）を強制し、その後は適応フェーズに移行して、スイング（新たな大胆なアプローチ）、マージ（登録済みの2つのアプローチを組み合わせる）、活用（最良のアプローチに焦点を絞って調整する）のいずれかを選びます。停滞ガードは、活用が連続して <stagnation_limit> 回実行されると活用を禁止し、スイングまたはマージへの切り替えを強制するため、ループが山登りに行き詰まることはありません。フィードバック信号には、実行ログから読み取った <metric> を使用します。approaches.md レジストリと、各イテレーションの move_type によって、スケジューラーが機能します。

あなたが研究者です。ループの実行中は、許可を求めるために停止しないでください。

使用するタイミング

改良の前に幅広い探索を強制したい、自由度の高い ML キャンペーンで使用します。スケジューラーにより、収束する前に複数の異なる手法群を確実に試せます。また、停滞ガードによって小さな変更を延々と繰り返すことを防ぎます。デフォルトは <swing_budget> = 3、<stagnation_limit> = 3 です。初期探索の幅を広げるには、<swing_budget> を増やしてください。分析を最優先する標準の ml-autoresearch には使用しないでください（強制スイングのスケジューラーを使わず、分析だけを各変更の指針にしたい場合は、そちらを使用してください）。また、単一の学習実行や固定されたスイープ、測定可能なスカラー指標のないタスクにも使用しないでください。

セットアップ

バインディングを対話形式で解決します。 作業ディレクトリに loop.run.yaml が存在する場合は読み込み、値を1行で確認して、ループに進みます。存在しない場合は、Claude Code では（AskUserQuestion ツールが使用可能です。<host> = claude-code と記録します）、プロジェクトから各バインディングの妥当と思われる値を推定し、推奨オプションとして提示します。他のホストでは（<host> = other）、各項目について引用符付きのプレーンテキストのプロンプトで質問します。その後、loop.run.yaml を作成し（形式は examples/run.example.yaml）、他のファイルを作成する前に、すべての値をユーザーに確認します。branches 戦略の場合は、git checkout -b autoresearch/<run_tag> を実行します（タグには今日の日付を使用し、ブランチは未作成である必要があります）。time による制限の場合は、<sandbox_root>/run_with_timeout.sh（timeout $(( <budget> * 60 )) <entrypoint> "$@"）を作成し、これを実行コマンドとして使用します。2 × <budget> 分で強制終了してください。epochs の場合は、<editable_files> 内のファイルでエポック数の上限を変更します。

バインディング	意味	デフォルト	推定方法
<metric> / <metric_direction>	最適化するスカラー値 + minimize/maximize	—	編集可能なファイルと README を調べ、指標名を確認します
<run_cmd> / <entrypoint>	実験を最初から最後まで1回実行するコマンド	—	pyproject.toml / .venv / README
<editable_files>	編集可能なファイル（評価ハーネスは対象外）	—	モデル / 設定 / 学習スクリプト。データ、ログ、環境、ハーネスは除外します
<sandbox_root>	スナップショットと台帳の保存場所	./sandbox	編集可能なファイルの近く
<iter_strategy>	snapshots または branches	snapshots	作業ディレクトリはクリーンな git リポジトリですか？
<gate> / <budget>	time（分）または epochs と、その上限	—	設定にある既存の時間／エポック設定
<swing_budget>	適応モードの前に強制する大胆なスイングの回数	3（3～5）	値が大きいほど初期探索の幅が広がります
<stagnation_limit>	強制的に切り替えるまでの、活用の連続最大回数	3	—

ファイル編集ガード：セットアップ中もループ中も、ファイルに触れる前に必ず <editable_files> に含まれていることを確認してください。それ以外はすべて読み取り専用の正解データです（評価ハーネスが <metric> を定義します）。例外はありません。

サンドボックスを初期化する

レイアウトを作成し、台帳のヘッダーを書き込みます。

<sandbox_root>/
├── loop.run.yaml      ← resolved bindings (written now)
├── results.tsv        ← experiment ledger, header only (written now)
├── approaches.md      ← registry of every distinct approach (header only, written now)
└── iter1/             ← created at loop start

results.tsv のヘッダー（タブ区切り。move_type ∈ {swing, merge, exploit}）：

iter	<metric>	status	move_type	analysis_summary	description

approaches.md のヘッダー：# Approach Registry と、マージステップで相補的なアプローチを見つけて組み合わせるためにこのファイルを参照する、という1行の注記。

ループ（中断されるまで無限に繰り返す）

反復1は常に未変更のベースラインです（スイングとして数えません）。移動の選択と変更計画はスキップしますが、必須の分析は実行してください。反復2がこれを基にする最初の実証的な基準点です。<editable_files> 内のすべてが変更対象です（アーキテクチャ、オプティマイザー、ハイパーパラメーター、データパイプライン、損失、初期化、評価）。特にスイングでは、全面的な書き換えを推奨します。制約は、コードが実行でき、<budget> 以内に完了することだけです。エポック効率も目的の一部です。同じスコアに、より少ない実効ステップ数で到達する変更は、実質的な改善です。シンプルさの基準：ほかの条件が同じなら、シンプルなほうが優れています。ハック的なコードを20行追加する0.001の改善には価値がありませんが、コードを削除して得られる0.001の改善（または同等の指標）は keep です。

スケジューラーは、反復をまたいで2つのカウンターをメモリに保持します。swings_taken（ベースラインを除いたスイング反復の合計）と**consecutive_exploit**（直近のスイング／マージ以降の exploit 数。スイングまたはマージを行うと0にリセット）。

各反復でこのチェックリストをコピーし、項目にチェックを付けてください。

• 1. 状態を確認する。 ブランチ方式：git log --oneline -5。スナップショット方式：iter<N>/ が存在しないことを確認します。反復 N-1 の分析概要と2つのカウンターを読みます。
• 2. move_type を選ぶ（反復1：スキップ — ベースライン）。以下のスケジューラーを適用し、ファイルに触れる前に移動を記録します。
• 3. 仮説を立てる（反復1：スキップ）。移動の内容とその理由（ルールまたは分析を引用）を述べ、実施することと、変更する <editable_files> を明記します。3つの移動を参照してください。
• 4. スナップショットを作成／コミットしてから、変更を適用する。 スナップショット方式：iter<N>/{code_snapshot,analysis,results}/ を作成し、すべての <editable_files> を code_snapshot/ にコピーしてから、loop.run.yaml を iter<N>/ にコピーし、その後に変更を適用します。ブランチ方式：変更を適用してから、git commit -am "<move_type>: <desc>" を実行します。
• 5. 実験を実行する。すべてをリダイレクトします（tee は絶対に使わないでください）。 <entrypoint> > <sandbox_root>/iter<N>/<run_log> 2>&1（または時間制限がある場合は run_with_timeout.sh）。 時間を超過した場合は停止し、クラッシュとして扱います。
• 6. 指標を読む：grep '^<metric>:' <sandbox_root>/iter<N>/<run_log>。空の場合は、 tail -n 50 <run_log> を実行してトレースを読み、簡単な修正を1回試します（タイプミス／インポート）。根本的に壊れている場合は crash を記録して続行します。
• 7. 結果を分析する — 必須。実際の成果物ファイルを作成します。分析を参照してください。
• 8. approaches.md を更新する（スイングおよびマージの移動のみ）。レジストリを参照してください。
• 9. results.tsv に記録する（未追跡 — 絶対にコミットしない）。台帳を参照してください。
• 10. 維持または元に戻す（変更はこの反復で実行済み）。<metric_direction> に従って改善した場合は keep とし、現在のベストを更新します。同等／悪化／クラッシュの場合は discard／crash とします。ブランチ方式では git reset --hard HEAD~1 を実行し、スナップショット方式では iter<N>/code_snapshot/ から <editable_files> を復元します。discard を記録する前に、シンプルさの基準を適用します。クラッシュ／OOM の場合は、意図を保つ最小限の変更で修正します（OOM → 実効バッチサイズを維持したまま、バッチサイズを小さくして勾配累積を行う）。実験内容は絶対に変更しないでください。
• 11. カウンターを更新する（以下を参照）して、ステップ1に戻ります。

スケジューラー（ステップ 2 — これがループのアイデンティティです）

ルールに厳密に、順番どおり従ってください。これらは提案ではなく、必ず守る制約です：

IF   iter == 1                                  → baseline   (run unmodified; no move)
ELIF swings_taken < <swing_budget>              → swing      (forced exploration)
ELIF consecutive_exploit >= <stagnation_limit>  → swing OR merge  (forced pivot — exploit BANNED)
ELSE                                            → agent chooses: swing / merge / exploit

自由に選べる ELSE 分岐では、イテレーション N-1 の分析に基づいて決めます。

• swing：現在の系統に根本的な上限がある場合。たとえば、上位の結果すべてに同じ失敗パターンが見られる場合です。
• merge：approaches.md の複数のエントリーに、それぞれ異なる重複しない強みがある場合（異なる軸を変えた親を優先します。互いに干渉せず、相乗的に組み合わさります）。
• exploit：新しいアーキテクチャを必要とせず、現在の最良の結果に分析から明らかな改善の余地がある場合です。

カウンターの更新（ステップ 11）

if move_type in {swing, merge}:  swings_taken += 1 (swing only); consecutive_exploit = 0
elif move_type == exploit:       consecutive_exploit += 1

3つの変更（ステップ 3）

• Swing — これまでのすべての Swing と根本的に異なるものにします（微調整ではなく、差分を見れば現在の最良の結果と明らかに異なるものであるべきです）。多くの人は反射的にアーキテクチャを Swing しますが、それは避けてください。次の軸も同等に有効で、まだ十分に探究されていません。アーキテクチャの系統（情報の流れ方、深さと幅、スキップ接続、ローカルとグローバル）；初期化（大きさに基づく方式、構造を保つ方式、入力統計に基づく方式、スパース方式 — 初期の動態が異なります）；データパイプライン（順序付け、サンプリング、決定性、ビュー空間の網羅性 — 拡張の種類だけではありません）；コンポーネントごとの学習率の分離（初期層／後期層、正規化層、バイアス、ヘッドには、それぞれ最適なステップ幅があります）；評価（単一パス、マルチビュー、チェックポイントの平均化、キャリブレーション）；目的関数（損失の形状、ターゲットの鋭さ、補助信号／一貫性信号）。真の Swing では、まだ試していない方法でこれらの軸のいずれかを探究します。
• Merge — approaches.md から複数のエントリーを選び、それぞれから何を取り入れるかを明記します。その結果は、どちらの親とも異なる新しいアプローチである必要があります。異なる軸の要素を優先してください。
• Exploit — 特定の分析結果に基づき、現在の最良の結果に狙いを定めて集中的に変更します。一度に変更するのは1つか2つにします。軸を分離してください（新しいオプティマイザーと新しい学習率は別々のイテレーションでテストし、どちらが結果をもたらしたかを特定できるようにします）。アーキテクチャを変更してはいけません。

分析（ステップ 7 — 必須。実際の成果物を生成します）

分析は、次の変更につなげる軸となります。この結果が生じた理由への理解を深めるのに最も役立つ分析を実行してください。分析スクリプトはすべて iter<N>/analysis/ に置き、出力（プロット、CSV、テキスト）はすべて標準出力をリダイレクトして iter<N>/results/ に保存します。結果が存在するまでは先に進まないでください。ファイルを書き出していない分析は、実施されていないのと同じです。分析の観点は、適切なものを選んでください。勾配のノルム／流れ、活性化統計／飽和、埋め込み（PCA／CKA／崩壊）、誤りと混同行列の分析、損失の推移と改善の余地（打ち切り時点でも改善が続いていましたか？）、重み／パラメーターの統計、データのプロファイリング（多くの場合、最も成果が得られます）、計算のプロファイリング。

簡潔な分析サマリーを3〜8項目で記述します。調べた内容、最も重要な発見、そして次の変更への示唆（swing／merge／exploit のどれが適切か）を含めてください。

アブレーションの規律（複数の軸に変更を加えた keep の後）：どの変更が改善をもたらしたかは、まだ分かりません。その点を明記し、次にアブレーション目的の exploit を検討してください。1つずつコンポーネントを元に戻します。アブレーションなしで複数軸の変更を基に構築するのは、未知のものを土台にすることです。

将来に備えた計測。 分析後に、「何を記録しておきたかっただろう？」と考えてください。結果を生成したスクリプトが <editable_files> にある場合は、今のうちに追加してください（最良エポックのチェックポイント、層ごとの勾配ノルム、クラスごとの精度など）。ログが充実すれば、今後の分析すべての質が向上します。計測の追加だけでも独立したイテレーションとして有効です（move_type=exploit として記録します）。

レジストリ（ステップ 8 — approaches.md、swing と merge のみ）

エントリーを追加してください。axes changed フィールドを使って、merge のステップで相補的な親を見つけます（アーキテクチャだけを変更した2つより、異なる軸を変更した2つのほうが適しています）。

## Approach <N>: <short name>
- **move_type**: swing | merge
- **iter**: <N>
- **<metric>**: <value>  (status: keep | discard | crash)
- **axes changed**: architecture | initialization | data pipeline | optimizer | lr schedule | evaluation | objective | other
- **key ideas**: <what makes this approach distinct>
- **strengths** / **weaknesses** (from analysis): <what worked / what the analysis says is missing>
- **ablated?**: yes (which components isolated, what was found) / no
- **parents** (merge only): Approach X + Approach Y — axes taken from each

台帳

<sandbox_root>/results.tsv はタブ区切りとし、自由記述にカンマを使用しないでください。ステータスは {keep, discard, crash} のいずれかです。クラッシュ時のメトリクスには 0.000000 を使用してください。branches では、反復番号の代わりに最初の列へ7文字のコミットを記載します。

iter	<metric>	status	move_type	analysis_summary	description
1	0.6320	keep	swing	baseline; grad norms clean, no pathologies	baseline
2	0.5910	discard	swing	ResNet blocks; gradient flow good but overfit on 5 epochs	ResNet-style residual blocks
3	0.6890	keep	swing	MLP-Mixer; feature mixing effective, less overfit	MLP-Mixer token+channel mix
4	0.7120	keep	merge	Mixer channel-mix + ResNet skips; best of both	merge: Mixer + ResNet skips
5	0.7250	keep	exploit	train/val gap small; warmup helped stability	add 2-epoch LR warmup
6	0.7240	discard	exploit	no gain from dropout; val acc unchanged	add dropout 0.1
7	0.6800	discard	swing	forced pivot after stagnation guard; ViT too data-hungry	ViT patch-16 from scratch

approaches.md のレジストリには、スイング／マージごとに1つのエントリを記録し、上記の形式に従ってください。例：

# Approach Registry
The merge step consults this file to find complementary approaches to combine.

## Approach 3: MLP-Mixer
- **move_type**: swing
- **iter**: 3
- **val_acc**: 0.6890  (status: keep)
- **axes changed**: architecture
- **key ideas**: token mixing + channel mixing, no convolutions
- **strengths**: less overfit than ResNet, fast per-epoch
- **weaknesses**: spatial locality not exploited; edges/textures underused
- **ablated?**: no

要約時には、最後の反復とは限らない、最良の反復を報告してください。results.tsv や approaches.md はコミットせず、未追跡のままにしてください。

制約

• <editable_files> 内のファイルのみを編集してください。編集のたびに、必ず事前に確認してください。それ以外のすべては読み取り専用の正解データであり、評価ハーネスが <metric> を定義します。
• 反復ごとに変更は1つとし、メトリクスの変化を1つの変更に帰属できるようにしてください。
• スケジューラのルールは厳守すべき制約であり、提案ではありません。 consecutive_exploit >= <stagnation_limit> の場合は、必ずスイングまたはマージを選択してください。分析結果にかかわらず、エクスプロイトは選択できません。このガードにより、際限ない山登りを防ぎます。
• 反復ごとに分析を必ず実施し、iter<N>/results/ に実際のファイルを作成してください。分析の裏付けがない変更は、ループを盲目的な反復に変え、次の判断に必要な情報を枯渇させます。
• スイングは、それ以前のすべてのスイングと根本的に異なるものでなければなりません。マージでは、各親から何を取り込むのかを明記してください。そうでなければ、レジストリも幅広さを保証する仕組みも意味をなしません。
• プロジェクトにないパッケージをインストールしたり、依存関係を追加したりしないでください。補助スクリプトは標準ライブラリのみを使用してください。
• 学習の出力は必ず <run_log> にリダイレクトし、tee は使用しないでください。サンドボックスは自己完結しており、../ による脱出は禁止です。

停止

このループは人間が中断するまで永久に実行されます。「続けてもよいですか？」や「ここで止めるのがよいですか？」と尋ねるために、一時停止しないでください。人間は不在の場合があり、無期限の自律的な作業を期待しています。動作する結果は次の反復の始まりであり、終わりではありません。アイデアが尽きた場合は、対象範囲内のファイルを読み直して見落とした観点を探し、分析をさらに掘り下げてください（勾配／活性化／埋め込み／エラーからは常に何かが見つかります）。approaches.md にある過去の惜しかった案を組み合わせるか、より大胆なスイングを試してください。