experiment-plan

論文主張に基づく実験計画：論文を意識した検証

具体化して精緻化する：$ARGUMENTS

概要

手法が十分に安定し、次の問いが論文を裏付けるために、どの実験をどの順序で実施すべきかになった段階で、このスキルを使用します。ユーザーが一度の依頼で全工程を求めている場合は、/research-refine-pipeline を優先してください。

目標は、膨大なベンチマーク候補のリストを作ることではありません。提案を、次の4点を裏付ける主張 -> 証拠 -> 実施順序のロードマップに落とし込むことです。

1. 手法が、設定した問題を実際に解決している
2. 主たる貢献が実在し、焦点が絞られている
3. 手法が十分に洗練されており、余分な複雑さは不要である
4. フロンティアモデル時代の要素が装飾的ではなく、真に有用である

定数

• OUTPUT_DIR = refine-logs/ — 実験計画の成果物の既定の保存先です。
• MAX_PRIMARY_CLAIMS = 2 — 主たる主張を1つ、補助的な主張を1つとするのが望ましいです。
• MAX_CORE_BLOCKS = 5 — 必須の実験ストーリーは簡潔にまとめてください。
• MAX_BASELINE_FAMILIES = 3 — 弱いベースラインを多数使うより、少数の強力なベースラインを優先してください。
• DEFAULT_SEEDS = 3 — 確率的なばらつきが重要で、計算予算に余裕がある場合は、3つのシードを使用してください。

ワークフロー

フェーズ 0：提案のコンテキストを読み込む

以下の関連ファイルが存在する場合は、まず読み込んでください。

• refine-logs/FINAL_PROPOSAL.md
• refine-logs/REVIEW_SUMMARY.md
• refine-logs/REFINEMENT_REPORT.md

以下を抽出します。

• 問題のアンカー
• 主たる貢献
• 任意の補助的な貢献
• 査読者が懸念する重要な点
• データ／計算資源／スケジュールの制約
• 中心となるフロンティア技術要素がある場合は、その要素

これらのファイルが存在しない場合は、ユーザーのプロンプトから同じ情報を導き出してください。

フェーズ 1：論文の主張を確定する

実験を提案する前に、裏付ける必要のある主張を書き出してください。

次の形式を使用します。

• 主たる主張：メカニズムレベルでの主要な貢献
• 補助的な主張：任意。論文の主なストーリーを直接強化する場合に限ります
• 否定すべき主張：例：「性能向上はパラメーター数の増加だけによる」「性能向上は探索空間の拡大だけによる」「最新の構成要素は単なる飾りである」
• 納得を得るために最低限必要な証拠：各主張について、経験豊富な査読者が信頼に値すると判断するために必要なもの

論文に、相互に切り離せない複数の主張が本当にある場合を除き、MAX_PRIMARY_CLAIMS を超えないでください。

フェーズ 2：実験のストーリーラインを構築する

簡潔な実験ブロックを中心に論文を構成します。既定では以下のブロックを使い、不要なものは削除してください。

1. 主要なアンカー結果 — 手法は実際のボトルネックを解決するか？
2. 新規性の切り分け — 主たる貢献そのものに効果があるか？
3. 単純さ／洗練度の確認 — より大きな構成や細分化された構成を避けられるか？
4. フロンティア技術の必要性の確認 — LLM／VLM／Diffusion／RL 時代の要素が中心にある場合、それは本当に適切な手段か？
5. 失敗分析または定性的な診断 — 手法でなお解決できないことは何か？

各ブロックを次のいずれに含めるか決めてください。

• 本論文 — 中心的な主張を裏付けるために不可欠
• 付録 — 役立つが、なくても論文の主張は成立する
• 削除 — 興味深いものの、論文に割ける予算に見合わない

弱いベースラインを多数並べるより、強力なベースライン群を1つ選んでください。より強力な最新のベースラインがある場合は、数を増やすために項目を追加するのではなく、そちらを使ってください。

フェーズ 3：各実験ブロックの詳細を定める

採用した各ブロックについて、以下をすべて明確にします。

• 検証する主張
• このブロックを設ける理由
• データセット／分割／タスク
• 比較対象システム：最も強力なベースライン、アブレーション、バリアントのみ
• 評価指標：決定的な指標を先に、二次的な指標を後に記載
• 設定の詳細：バックボーン、凍結する部分と学習可能な部分、主要なハイパーパラメーター、学習予算、シード
• 成功基準：どのような結果が説得力のある証拠となるか
• 失敗の解釈：結果が否定的だった場合、何を意味するか
• 表／図の掲載先：論文内のどこにこの結果を掲載するか

特別ルール：

• シンプルさの確認では通常、最終手法を、過剰に作り込んだバリアント、または論文で意図的に採用しない魅力的な追加コンポーネントと比較します。
• 最先端の必要性の確認では通常、選択した最新のプリミティブを、現実的に最も有力な、よりシンプルまたは古い代替手法と比較します。
• 提案が意図的に最先端を目指さない場合は、その旨を明記し、無理に最先端のブロックを設けずに省略します。

フェーズ 4：計画を実行順序に落とし込む

ユーザーが最初に何をすべきか分かるよう、現実的な実行順序を作成します。

次のマイルストーン構成を使用します。

1. 健全性確認段階 — データパイプライン、評価指標の正確性、簡単な過学習テストまたはおもちゃのデータ分割
2. ベースライン段階 — 最も強力なベースラインを再現
3. 主手法段階 — 最終手法を主要な設定で実行
4. 判断段階 — 新規性、シンプルさ、最先端の必要性を検証する決定的なアブレーションを実行
5. 仕上げ段階 — 頑健性、定性的な図、付録用の追加実験

各マイルストーンについて、以下を見積もります。

• 計算コスト
• 予想所要時間
• 継続／中止の判断基準
• リスクと軽減策

必須の実験とあると望ましい実験を分けてください。

フェーズ 5：成果物を作成する

ステップ 5.1：refine-logs/EXPERIMENT_PLAN.md を作成する

次の構成を使用します。

# Experiment Plan

**Problem**: [problem]
**Method Thesis**: [one-sentence thesis]
**Date**: [today]

## Claim Map
| Claim | Why It Matters | Minimum Convincing Evidence | Linked Blocks |
|-------|-----------------|-----------------------------|---------------|
| C1    | ...             | ...                         | B1, B2        |

## Paper Storyline
- Main paper must prove:
- Appendix can support:
- Experiments intentionally cut:

## Experiment Blocks

### Block 1: [Name]
- Claim tested:
- Why this block exists:
- Dataset / split / task:
- Compared systems:
- Metrics:
- Setup details:
- Success criterion:
- Failure interpretation:
- Table / figure target:
- Priority: MUST-RUN / NICE-TO-HAVE

### Block 2: [Name]
...

## Run Order and Milestones
| Milestone | Goal | Runs | Decision Gate | Cost | Risk |
|-----------|------|------|---------------|------|------|
| M0        | ...  | ...  | ...           | ...  | ...  |

## Compute and Data Budget
- Total estimated GPU-hours:
- Data preparation needs:
- Human evaluation needs:
- Biggest bottleneck:

## Risks and Mitigations
- [Risk]:
- [Mitigation]:

## Final Checklist
- [ ] Main paper tables are covered
- [ ] Novelty is isolated
- [ ] Simplicity is defended
- [ ] Frontier contribution is justified or explicitly not claimed
- [ ] Nice-to-have runs are separated from must-run runs

ステップ 5.2：refine-logs/EXPERIMENT_TRACKER.md を作成する

次の構成を使用します。

# Experiment Tracker

| Run ID | Milestone | Purpose | System / Variant | Split | Metrics | Priority | Status | Notes |
|--------|-----------|---------|------------------|-------|---------|----------|--------|-------|
| R001   | M0        | sanity  | ...              | ...   | ...     | MUST     | TODO   | ...   |

トラッカーは簡潔で、実行に役立つ内容にします。

ステップ 5.3：ユーザーに簡潔な要約を提示する

Experiment plan ready.

Must-run blocks:
- [Block 1]
- [Block 2]

Highest-risk assumption:
- [risk]

First three runs to launch:
1. [run]
2. [run]
3. [run]

Plan file: refine-logs/EXPERIMENT_PLAN.md
Tracker file: refine-logs/EXPERIMENT_TRACKER.md

出力プロトコル

すべての出力ファイルに、以下の共通プロトコルを適用してください。

• 出力バージョニングプロトコル — タイムスタンプ付きファイルを先に書き、その後、固定名のファイルにコピーする
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録する
• 出力言語プロトコル — プロジェクトの言語設定に従う

重要なルール

• 大きなファイルの取り扱い：ファイルサイズが原因で Write ツールが失敗した場合は、直ちに Bash（cat << 'EOF' > file）を使い、分割して書き込むよう再試行してください。ユーザーに許可を求めず、何も伝えずに実行してください。

• すべての実験で主張を裏付ける必要があります。 査読者の見方を変えない実験は削除してください。

• 論文のストーリーは簡潔に保ってください。 まずメインの表を設計し、それを裏付けるアブレーションだけを追加してください。

• シンプルさを明示的に裏付けてください。 複雑さが懸念される場合は、削除実験、またはより強力だが肥大化したバリアントとの比較を含めてください。

• 最先端の選択を明示的に裏付けてください。 最新のプリミティブが中核をなす場合は、最も強力なシンプルな代替手法より優れている理由を示してください。

• 長いベースライン一覧より、強力なベースラインを優先してください。 水増しした一覧より、短く信頼できる比較対象セットのほうが適切です。

• 必須の実験と、あると望ましい実験を分けてください。 付録向けのアイデアによって、論文の核となる証拠の提示を遅らせないでください。

• 提案の制約を再利用してください。 非現実的な予算やデータに関する前提を作り出さないでください。

• 結果を捏造しないでください。 証拠を計画するのであって、証拠があると主張してはいけません。

他のスキルとの組み合わせ

/research-refine-pipeline -> one-shot method + experiment planning
/research-refine   -> method and claim refinement
/experiment-plan   -> detailed experiment roadmap
/run-experiment    -> execute the runs
/auto-review-loop  -> react to results and iterate on the paper