研究論文執筆パイプライン

NeurIPS、ICML、ICLR、ACL、AAAI、COLM を対象とした、出版可能なML/AI研究論文を制作するための統合パイプライン。実験設計、実行、監視、分析、論文執筆、査読、修正、投稿の完全な研究ライフサイクルをカバーします。

これは線形パイプラインではなく、反復的ループです。結果は新しい実験を呼び起こします。査読は新しい分析を引き起こします。エージェントはこれらのフィードバックループを処理する必要があります。

<!-- ascii-guard-ignore -->

┌─────────────────────────────────────────────────────────────┐
│                    RESEARCH PAPER PIPELINE                  │
│                                                             │
│  Phase 0: Project Setup ──► Phase 1: Literature Review      │
│       │                          │                          │
│       ▼                          ▼                          │
│  Phase 2: Experiment     Phase 5: Paper Drafting ◄──┐      │
│       Design                     │                   │      │
│       │                          ▼                   │      │
│       ▼                    Phase 6: Self-Review      │      │
│  Phase 3: Execution &           & Revision ──────────┘      │
│       Monitoring                 │                          │
│       │                          ▼                          │
│       ▼                    Phase 7: Submission               │
│  Phase 4: Analysis ─────► (feeds back to Phase 2 or 5)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

<!-- ascii-guard-ignore-end -->

---

このスキルをいつ使うか

以下の場合にこのスキルを使用してください:

• 既存のコードベースやアイデアから新しい研究論文を開始する
• 論文の主張をサポートするための実験を設計・実行する
• 研究論文のセクションを執筆または修正する
• 特定の会議またはワークショップに向けて投稿を準備する
• 査読に対応し、追加の実験または修正を行う
• 論文を会議形式間で変換する
• 非経験的論文を執筆する — 理論、サーベイ、ベンチマーク、またはポジションペーパー（経験的ML以外の論文タイプを参照）
• NLP、HCI、またはアライメント研究用の人間評価を設計する
• 採択後の成果物を準備する — ポスター、トークス、コード公開

基本哲学

1. プロアクティブに対応する。 質問ではなく、完全なドラフトを提供する。科学者は忙しい — 具体的なものを作成し、その後反復を重ねる。
2. 引用を作成しない。 AI生成引用には約40%のエラー率がある。常にプログラム的にフェッチする。検証不可能な引用は [CITATION NEEDED] としてマークする。
3. 論文は物語であり、実験の集合ではない。 すべての論文には1つの明確な貢献が必要で、1文で述べられるべきである。それができなければ、論文はまだ準備完了ではない。
4. 実験は主張に奉仕する。 すべての実験は、それがサポートする主張を明確に述べなければならない。論文のナラティブに接続しない実験は実行しない。
5. 早期にコミット、頻繁にコミット。 完了した実験バッチごと、論文ドラフト更新ごと — 説明的なメッセージでコミットする。Gitログが実験履歴である。

プロアクティビティと協力

デフォルト: プロアクティブに。まずドラフト、ドラフト付きで質問。

信頼度レベル	アクション
高 (明確なリポ、明白な貢献)	完全なドラフトを作成、提供、フィードバックで反復
中 (いくつかの曖昧さ)	フラグ付きドラフトを作成、続行
低 (主要な未知数)	clarify で1-2個のターゲット質問をした上でドラフト作成

セクション	自律的にドラフト?	ドラフトで フラグ
Abstract	はい	"貢献をXとしてフレーム — 必要ならば調整"
Introduction	はい	"問題Yを強調 — 間違っていれば修正"
Methods	はい	"詳細A、B、Cを含める — 不足を追加"
Experiments	はい	"結果1、2、3をハイライト — 必要ならば並べ替え"
Related Work	はい	"論文X、Y、Zを引用 — 見落とした部分を追加"

入力をブロックする場合のみ: ターゲット会議が不明、複数の矛盾するフレーム、結果が不完全に見える、先に確認する明示的なリクエスト。

---

Phase 0: プロジェクト セットアップ

目標: ワークスペースを確立し、既存の作業を理解し、貢献を特定する。

Step 0.1: リポジトリを探索する

# プロジェクト構造を理解する
ls -la
find . -name "*.py" | head -30
find . -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"

以下を探す:

• README.md — プロジェクト概要と主張
• results/, outputs/, experiments/ — 既存の調査結果
• configs/ — 実験設定
• .bib ファイル — 既存の引用
• ドラフト文書またはノート

Step 0.2: ワークスペースを整理する

一貫したワークスペース構造を確立する:

workspace/
  paper/               # LaTeXソース、図、コンパイル済みPDF
  experiments/         # 実験ランナースクリプト
  code/                # コア方法実装
  results/             # 生の実験結果 (自動生成)
  tasks/               # タスク/ベンチマーク定義
  human_eval/          # 人間評価資料 (必要な場合)

Step 0.3: バージョン管理をセットアップする

git init  # 既にない場合
git remote add origin <repo-url>
git checkout -b paper-draft  # またはmain

Git規律: 完了した実験バッチごとに説明的なメッセージでコミットします。例:

Add Monte Carlo constrained results (5 runs, Sonnet 4.6, policy memo task)
Add Haiku baseline comparison: autoreason vs refinement baselines at cheap model tier

Step 0.4: 貢献を特定する

何かを書く前に、明確にする:

• 何 (The What): この論文が貢献する唯一のものは何か?
• なぜ (The Why): どのような証拠がそれをサポートするか?
• だから何 (The So What): なぜ読者がそれを気にする必要があるか?

科学者に提案: "私の理解に基づき、主要な貢献は: [1文]です。主要な結果は[Y]を示しています。これが望んでいるフレーミングですか?"

Step 0.5: TODOリストを作成する

todo ツールを使用して構造化されたプロジェクト計画を作成します:

Research Paper TODO:
- [ ] Define one-sentence contribution
- [ ] Literature review (related work + baselines)
- [ ] Design core experiments
- [ ] Run experiments
- [ ] Analyze results
- [ ] Write first draft
- [ ] Self-review (simulate reviewers)
- [ ] Revise based on review
- [ ] Submission prep

プロジェクト全体でこれを更新します。セッション間の永続的な状態として機能します。

Step 0.6: 計算予算を推定する

実験を実行する前に、総コストと時間を推定します:

Compute Budget Checklist:
- [ ] API costs: (モデル価格/トークン) × (実行あたりの推定トークン) × (実行数)
- [ ] GPU時間: (実験あたりの時間) × (実験数) × (シード数)
- [ ] 人間評価コスト: (アノテータ) × (時間) × (時給)
- [ ] 総予算上限と予備費 (再実行用に30-50%を追加)

実験が実行される際の実際の支出を追跡します:

# シンプルなコストトラッカーパターン
import json, os
from datetime import datetime

COST_LOG = "results/cost_log.jsonl"

def log_cost(experiment: str, model: str, input_tokens: int, output_tokens: int, cost_usd: float):
    entry = {
        "timestamp": datetime.now().isoformat(),
        "experiment": experiment,
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "cost_usd": cost_usd,
    }
    with open(COST_LOG, "a") as f:
        f.write(json.dumps(entry) + "\n")

予算が厳しい場合: パイロット実験を実行 (1-2シード、タスクの部分集合) 完全なスイープにコミットする前に。デバッグパイプライン用に安いモデルを使用し、最終実行用にターゲットモデルに切り替えます。

Step 0.7: マルチ著者協調

ほとんどの論文には3-10人の著者がいます。ワークフローを早期に確立します:

ワークフロー	ツール	いつ使うか
Overleaf	ブラウザベース	複数著者が同時に編集、Gitの経験なし
Git + LaTeX	git with .gitignore aux用ファイル	技術的なチーム、ブランチベースのレビューが必要
Overleaf + Git sync	Overleaf プレミアム	両者の長所 — ライブコラボと版履歴

セクション所有権: 各セクションをに1人の主著者を割り当てます。他の人はコメントしますが、直接編集しません。マージ競合とスタイル矛盾を防ぎます。

Author Coordination Checklist:
- [ ] セクション所有権に同意 (誰が何を書くか)
- [ ] 共有ワークスペースをセットアップ (Overleafまたはgitリポ)
- [ ] 表記法の規則を確立 (誰かが書く前に)
- [ ] 内部レビューラウンドをスケジュール (終わりだけではなく)
- [ ] 最終的なフォーマット処理用に1人を指定
- [ ] 図スタイルに同意 (色、フォント、サイズ)

早期に同意すべきLaTeX慣例:

• \method{} マクロ一貫性のあるメソッド命名用
• 引用スタイル: \citet{} vs \citep{} の使用
• 数学表記: ベクトル用の小文字太字、行列用の大文字太字など
• イギリス英語 vs アメリカ英語

---

Phase 1: 文献レビュー

目標: 関連作業を見つけ、ベースラインを特定し、引用を集める。

Step 1.1: シード論文を特定する

コードベースで既に参照されている論文から始めます:

# ターミナルを介して:
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find . -name "*.bib"

Step 1.2: 関連作業を検索する

arxiv スキルをロード 構造化された論文発見用: skill_view("arxiv")。これはarXiv REST APIサーチ、Semantic Scholar引用グラフ、著者プロフィール、BibTeX生成を提供します。

web_search を使用して広範な発見を行い、web_extract を使用して特定の論文を取得します:

# web_searchを介して:
web_search("[main technique] + [application domain] site:arxiv.org")
web_search("[baseline method] comparison ICML NeurIPS 2024")

# web_extractを介して (特定の論文用):
web_extract("https://arxiv.org/abs/2303.17651")

試すべき追加の検索クエリ:

Search queries:
- "[main technique] + [application domain]"
- "[baseline method] comparison"
- "[problem name] state-of-the-art"
- 既存引用の著者名

推奨: Exa MCP をインストール リアルタイムアカデミック検索用:

claude mcp add exa -- npx -y mcp-remote "https://mcp.exa.ai/mcp"

Step 1.2b: 検索を深める (幅優先、その後深度優先)

フラットな検索 (1ラウンドのクエリ) は通常、重要な関連作業を逃します。反復的な幅優先、その後深度優先パターンを使用します (深い研究パイプラインから着想):

反復的な文献検索:

ラウンド1 (幅): 異なる角度をカバーする4-6個の並列クエリ
  - "[method] + [domain]"
  - "[problem name] state-of-the-art 2024 2025"
  - "[baseline method] comparison"
  - "[alternative approach] vs [your approach]"
  → 論文を収集、主要な概念と用語を抽出

ラウンド2 (深度): ラウンド1の学習からフォローアップクエリを生成
  - ラウンド1論文で発見された新しい用語
  - 最も関連性の高いラウンド1の結果によって引用された論文
  - 調査が必要な矛盾する調査結果
  → 論文を収集、残りのギャップを特定

ラウンド3 (ターゲット): 特定のギャップを埋める
  - ラウンド1-2で特定された見落とされたベースライン
  - 並行作業 (過去6ヶ月、同じ問題)
  - 主要な否定的結果または失敗したアプローチ
  → 新しいクエリが既に見ているほとんどの論文を返すときに停止

停止のタイミング: ラウンドがコレクション内の>80%の論文を既に返す場合、検索は飽和しています。通常2-3ラウンドで十分です。サーベイ論文の場合、4-5ラウンドを期待します。

エージェントベースのワークフロー用: delegate_task を介して各ラウンドのクエリを並列に委任します。結果を収集、重複排除、次のラウンドのクエリを結合された学習から生成します。

Step 1.3: すべての引用を確認する

決してメモリからBibTeXを生成しないでください。常にプログラム的にフェッチしてください。

各引用について、必須の5ステップのプロセスに従います:

引用確認 (引用ごとの必須):
1. 検索 → Semantic ScholarまたはExa MCPで特定のキーワードをクエリ
2. 確認 → 論文が2+ソースに存在することを確認 (Semantic Scholar + arXiv/CrossRef)
3. 取得 → DOI コンテント ネゴシエーション経由でBibTeXを取得 (プログラム的、メモリからではなく)
4. 検証 → 引用している主張が実際に論文に現れることを確認
5. 追加 → 検証されたBibTeXをビブリオグラフィに追加
いずれかのステップが失敗 → [CITATION NEEDED] としてマーク、科学者に通知

# DOI経由でBibTeXをフェッチ
import requests

def doi_to_bibtex(doi: str) -> str:
    response = requests.get(
        f"https://doi.org/{doi}",
        headers={"Accept": "application/x-bibtex"}
    )
    response.raise_for_status()
    return response.text

引用を確認できない場合:

\cite{PLACEHOLDER_author2024_verify_this}  % TODO: Verify this citation exists

常に科学者に伝える: "[X]個の引用をプレースホルダーとしてマークしました。検証が必要です。"

詳細なAPI文書と完全な CitationManager クラスについては、references/citation-workflow.md を参照してください。

Step 1.4: 関連作業を整理する

論文ごとではなく、方法論でグループ化します:

良い: "1つの研究ラインはXの仮定を使用します [refs] 一方、我々はYの仮定を使用します..." 悪い: "Smith et al.がXを導入しました。Jones et al.がYを導入しました。我々は両者を組み合わせます。"

---

Phase 2: 実験設計

目標: 論文の主張を直接サポートする実験を設計します。すべての実験は特定の質問に答える必要があります。

Step 2.1: 主張を実験にマップする

明示的なマッピングを作成します:

主張	実験	期待される証拠
"我々の方法がベースラインを上回る"	メイン比較 (Table 1)	勝率、統計的有意性
"効果はより弱いモデルで大きい"	モデルスケーリング研究	単調改善曲線
"収束はスコープ制約が必要"	制約ありなし比較	収束率比較

ルール: 実験が主張にマップしない場合、実行しないでください。

Step 2.2: ベースラインを設計する

強いベースラインは、受け入れられた論文を却下されたものから分ける。査読者は尋ねるでしょう: "Xと比較しましたか?"

標準的なベースラインカテゴリ:

• 素朴なベースライン: 最も単純な可能なアプローチ
• 強いベースライン: 既知の最良の既存メソッド
• アブレーションベースライン: 1つのコンポーネントを除いた自分のメソッド
• 計算一致ベースライン: 同じ計算予算、異なる割り当て

Step 2.3: 評価プロトコルを定義する

何かを実行する前に、指定します:

• メトリクス: 何を測定しているか、方向記号 (高い/低いの方が良い)
• 集計: 実行/タスク間の結果の結合方法
• 統計テスト: 有意性を確立するテスト
• サンプル サイズ: 実行/問題/タスク数

Step 2.4: 実験スクリプトを書く

成功した研究パイプラインからこれらのパターンに従います:

増分保存 — クラッシュ回復のため各ステップ後に結果を保存:

# 各問題/タスク後に保存
result_path = f"results/{task}/{strategy}/result.json"
if os.path.exists(result_path):
    continue  # 既に完了した作業をスキップ
# ... 実験を実行 ...
with open(result_path, 'w') as f:
    json.dump(result, f, indent=2)

アーティファクト保存 — すべての中間出力を保存:

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # 最終結果
      history.json             # 完全な軌跡
      pass_01/                 # 反復ごとのアーティファクト
        version_a.md
        version_b.md
        critic.md

関心の分離 — 生成、評価、可視化を別々に保つ:

run_experiment.py              # コア実験ランナー
run_baselines.py               # ベースライン比較
run_comparison_judge.py        # ブラインド評価
analyze_results.py             # 統計分析
make_charts.py                 # 可視化

references/experiment-patterns.md で完全な設計パターン、クロン監視、エラー回復を参照してください。

Step 2.5: 人間評価を設計する (該当する場合)

多くのNLP、HCI、アライメント論文は、主要または相補的な証拠として人間評価が必要です。自動化された実験を実行する前に、これを設計してください — 人間評価はしばしば長い潜在時間を持っています (IRB承認、アノテータ募集)。

人間評価が必要な場合:

• 自動メトリクスがあなたが気にすることをキャプチャしない (流暢さ、有用性、安全性)
• あなたの貢献は人間対応の品質について (可読性、選好、信頼)
• NLP会場のレビュアー (ACL、EMNLP) は生成タスク用に期待

主要な設計決定:

決定	オプション	ガイダンス
アノテータ タイプ	エキスパート、クラウドワーカー、エンドユーザー	あなたの主張が必要とするものと一致させる
スケール	Likert (1-5)、ペアワイズ比較、ランキング	ペアワイズはLLM出力にはLikertより信頼できる
サンプル サイズ	アノテータあたり、総項目数	冪分析または最小100項目、3+アノテータ
一致メトリック	Cohen's kappa、Krippendorff's alpha、ICC	Krippendorff's alpha >2アノテータ用; 生の一致もレポート
プラットフォーム	Prolific、MTurk、内部チーム	Prolific品質用; MTurk規模用; 内部ドメイン専門知識用

アノテーション ガイドライン チェックリスト:

- [ ] 例 (良い AND 悪い) を含む明確なタスク説明
- [ ] 曖昧な場合の決定基準
- [ ] カテゴリごとに2つ以上の作業例
- [ ] 注意チェック/ゴールド標準項目 (総数の10-15%)
- [ ] 適格タスクまたはスクリーニング ラウンド
- [ ] 推定時間/項目および公正な報酬 (>=ローカル最低賃金)
- [ ] 必要に応じてIRB/倫理レビュー

レポート要件 (査読者が全てをチェック):

• アノテータ数と資格
• 特定のメトリックと値を含む人間アノテータ間の一致
• 報酬の詳細 (金額、推定時給)
• アノテーション インターフェース説明またはスクリーンショット (付録)
• 総アノテーション時間

references/human-evaluation.md で完全なガイド (人間評価データの統計テスト、クラウドソーシング品質管理パターン、IRBガイダンス) を参照してください。

---

Phase 3: 実験実行と監視

目標: 実験を確実に実行し、進行状況を監視し、エラーから回復します。

Step 3.1: 実験を起動する

長時間実行の実験には nohup を使用します:

nohup python run_experiment.py --config config.yaml > logs/experiment_01.log 2>&1 &
echo $!  # PIDを記録

並列実行: 独立した実験を同時に実行しますが、APIレート制限に注意してください。同じAPI上で4つ以上の並列実験を実行すると、各実験が遅くなります。

Step 3.2: 監視をセットアップ (クロン パターン)

長時間実行の実験には、定期的なステータスチェックをセットアップします。クロン プロンプトはこのテンプレートに従う必要があります:

監視プロンプト テンプレート:
1. プロセスがまだ実行中かどうかを確認: ps aux | grep <pattern>
2. ログの最後の30行を読む: tail -30 <logfile>
3. 完了した結果を確認: ls <result_dir>
4. 結果が存在する場合、読んでレポート: cat <result_file>
5. すべて完了したら、コミット: git add -A && git commit -m "<descriptive message>" && git push
6. 構造化形式でレポート (主要メトリクス付きの表)
7. この実験の主要な分析質問に答える

サイレント モード: 最後のチェック以降何も変わっていない場合、ユーザーへの通知を抑制するために [SILENT] で応答します。ニュースがあるときだけレポートします。

Step 3.3: エラーを処理する

一般的なエラーモードと回復:

エラー	検出	回復
APIレート制限/クレジット枯渇	ログの402/429エラー	待機、その後再実行 (スクリプトは完了した作業をスキップ)
プロセス クラッシュ	PID がなく、結果が不完全	最後のチェックポイントから再実行
ハード問題でのタイムアウト	プロセスが詰まり、ログの進行がない	強制終了してスキップ、結果に注記
間違ったモデルID	モデル名を参照するエラー	IDを修正して再実行

キー: スクリプトは常に既存の結果をチェックし、完了した作業をスキップする必要があります。これは再実行を安全で効率的にします。

Step 3.4: 完了した結果をコミット

各実験バッチの完了後:

git add -A
git commit -m "Add <experiment name>: <key finding in 1 line>"
git push

Step 3.5: 実験ジャーナルを保持する

Gitコミットは何が起こったかを追跡していますが、探索ツリー (学習したことに基づいて次に試すことについての決定) ではなく。構造化された実験ジャーナルを保持します:

// experiment_journal.jsonl — 試みごとに1つのエントリを追加
{
  "id": "exp_003",
  "parent": "exp_001",
  "timestamp": "2025-05-10T14:30:00Z",
  "hypothesis": "スコープ制約を追加することで、exp_001の収束失敗を修正します",
  "plan": "max_tokens=2000および固定構造テンプレートでautoreasonを再実行",
  "config": {"model": "haiku", "strategy": "autoreason", "max_tokens": 2000},
  "status": "completed",
  "result_path": "results/exp_003/",
  "key_metrics": {"win_rate": 0.85, "convergence_rounds": 3},
  "analysis": "スコープ制約が収束を修正しました。勝率は0.42から0.85に跳ね上がりました。",
  "next_steps": ["Sonnetで同じ制約を試す", "構造テンプレートなしでテスト"],
  "figures": ["figures/exp003_convergence.pdf"]
}

なぜジャーナルが、Gitだけではなく? Gitはファイルの変更を追跡します。ジャーナルは推論を追跡します: Xを試したのはなぜ、何を学んだか、それが次の実験に何を意味するか。論文を書くとき、このツリーはメソッドセクション ("我々はXを観察しました、これはYを動機づけました") と正直なエラーレポートに貴重です。

最適なパスを選択: ジャーナルが分岐ツリー (exp_001 → exp_002a、exp_002b、exp_003) を示す場合、論文の主張をサポートする最適なパスを特定します。アブレーション行き止まりまたは否定的結果として付録で死端ブランチを文書化します。

実験ごとにコードをスナップショット: 各実行後に実験スクリプトをコピー:

cp experiment.py results/exp_003/experiment_snapshot.py

これは後続のコード変更後でも正確な再現を可能にします。

---

Phase 4: 結果分析

目標: 調査結果を抽出し、統計を計算し、物語を特定します。

Step 4.1: 結果を集計する

以下を行う分析スクリプトを書く:

1. バッチからすべての結果ファイルをロード
2. タスク単位と集計メトリクスを計算
3. サマリー表を生成

# 標準的な分析パターン
import json, os
from pathlib import Path

results = {}
for result_file in Path("results/").rglob("result.json"):
    data = json.loads(result_file.read_text())
    strategy = result_file.parent.name
    task = result_file.parent.parent.name
    results.setdefault(strategy, {})[task] = data

# 集計メトリクスを計算
for strategy, tasks in results.items():
    scores = [t["score"] for t in tasks.values()]
    print(f"{strategy}: mean={np.mean(scores):.1f}, std={np.std(scores):.1f}")

Step 4.2: 統計的有意性

常に計算:

• エラーバー: 標準偏差または標準誤差、どちらかを指定
• 信頼区間: 主要な結果に対する95% CI
• ペアワイズテスト: 2つのメソッドを比較するためのMcNemarテスト
• 効果サイズ: Cohen's d または h 実用的な有意性用

McNemar テスト、ブートストラップ CI、Cohen's h の完全な実装については、references/experiment-patterns.md を参照してください。

Step 4.3: 物語を特定する

分析後、明確に答える:

1. 主な調査結果は何か? 1文で述べてください。
2. 何があなたを驚かせたか? 予期しない結果はしばしば最良の論文を作ります。
3. 何が失敗したか? 失敗した実験は最も有益な場合があります。エラーの正直なレポートは論文を強化します。
4. どのようなフォローアップ実験が必要か? 結果は多くの場合、新しい質問を提起します。

否定的または帰無結果の処理

仮説が間違っていたり、結果が結論的でない場合、3つのオプションがあります:

状況	アクション	会場の適合性
仮説が間違っていますがなぜが有益	理由の分析を中心に論文をフレーム	NeurIPS、ICML (分析が厳密な場合)
メソッドはベースラインを上回らないが何かを明かす	寄稿を理解/分析として再フレーム	ICLR (理解を価値とする)、ワークショップペーパー
人気のある主張に対するクリーンな否定的結果	書き上げて — フィールドが知る必要があります	NeurIPS データセット & ベンチマーク、TMLR、ワークショップ
結果が結論的でなく、明確な物語がない	ピボット — 異なる実験を実行または再フレーム	準備ができていない論文を強制しないでください

否定的結果論文を書く方法:

• コミュニティが信じていることと、なぜテストすることが重要かで始める
• あなたの厳密な方法論を説明 (査読者はより厳しく精査します)
• 帰無結果を統計的証拠を含めて明確に提示
• 期待された結果が出現しなかった理由を分析
• フィールドへの影響について議論

否定的結果を明示的に歓迎する会場: NeurIPS (Datasets & Benchmarks トラック)、TMLR、ML再現性チャレンジ、主要な会議のワークショップ。いくつかのワークショップは特に否定的結果を呼びかけています。

Step 4.4: 図と表を作成する

図:

• すべてのプロットにベクターグラフィックス (PDF) を使用: plt.savefig('fig.pdf')
• 色盲対応パレット (Okabe-Ito または Paul Tol)
• 自己完結型キャプション — 読者はメインテキストなしで理解すべき
• 図の内にはタイトルなし — キャプションがこの機能を提供

表:

• booktabs LaTeXパッケージを使用
• メトリクスあたりの最高値を太字に
• 方向記号を含める (高い/低いの方が良い)
• 一貫した小数精度

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
Method & Accuracy $\uparrow$ & Latency $\downarrow$ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf{Ours} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

Step 4.5: 決定: さらに実験を行うか、執筆するか?

状況	アクション
コア主張がサポート、結果が有意	Phase 5に移動 (執筆)
結果が結論的でない、さらなるデータが必要	Phase 2に戻る (設計)
予期しない調査結果が新しい方向を示唆	Phase 2に戻る (設計)
査読者が尋ねるでしょう1つのアブレーションがない	それを実行してから Phase 5
すべての実験が終了したがいくつか失敗	エラーを注記、Phase 5に移動

Step 4.6: 実験ログを書く (執筆へのブリッジ)

結果ファイルから物語を導き出すために再導出する必要性を、執筆エージェントが生じないように、移行する前に構造化された実験ログを作成します。これは結果と散文の間の最も重要な結合組織です。

experiment_log.md を作成 次の構造で:

# Experiment Log

## Contribution (one sentence)
[論文の主な主張]

## 実行した実験

### Experiment 1: [Name]
- **テストされた主張**: [この論文のどの主張をサポートするか]
- **セットアップ**: [モデル、データセット、構成、実行数]
- **主要な結果**: [番号付きの1文]
- **結果ファイル**: results/exp1/final_info.json
- **生成された図**: figures/exp1_comparison.pdf
- **驚くべき調査結果**: [予期しなかったこと]

### Experiment 2: [Name]
...

## 図
| ファイル名 | 説明 | どのセクションに属するか |
|----------|------|----------|
| figures/main_comparison.pdf | ベンチマークXのすべてのメソッドを比較する棒グラフ | 結果、Figure 2 |
| figures/ablation.pdf | コンポーネントA、B、Cを削除するアブレーション | 結果、Figure 3 |
...

## 失敗した実験 (正直さのため文書化)
- [何が試行されたか、なぜ失敗したか、それが私たちに何を教えるか]

## オープンな質問
- [論文が対処すべき結果が提起したこと]

これが重要な理由: ドラフト時に、エージェント (または委任されたサブエージェント) が experiment_log.md をLaTeXテンプレートと一緒にロードでき、実際の結果に基づいた最初のドラフトを作成できます。このブリッジがなければ、執筆エージェントは生のJSON/CSVファイルを解析して物語を推論する必要があります — これは幻覚化または誤ったレポート番号の一般的なソースです。

Git 規律: 記述するログを説明する結果と一緒にコミットします。

---

反復的な改善: 戦略選択

このパイプライン内のすべての出力 — 論文ドラフト、実験スクリプト、分析 — を反復的に改善できます。Autoreason研究は、各改善戦略がいつ機能し、いつ失敗するかについて経験的証拠を提供します。このセクションを使用して正しいアプローチを選択します。

クイック決定表

あなたの状況	戦略	なぜ
中層モデル + 制約されたタスク	Autoreason	スイート スポット。生成評価ギャップが最も広い。ベースラインは積極的に弱いモデル出力を破壊します。
中層モデル + オープン タスク	Autoreason + スコープ制約が追加	固定事実、構造、または成果物を追加して改善スペースを束縛します。
フロンティア モデル + 制約されたタスク	Autoreason	境界でも制約されたタスク3つのうち2つを獲得します。
フロンティア モデル + オープン タスク	批評と修正 または シングル パス	Autoreason最後に来ます。モデル自己評価十分なら。
具体的な技術タスク (システム設計)	批評と修正	直接の検出修正ループはより効率的です。
テンプレート埋め込みタスク (1つの正しい構造)	シングル パス または 保守的	最小限の決定スペース。反復は値を追加しません。
テスト ケース付きコード	Autoreason (code variant)	修正する前になぜ失敗したかの構造化分析。回復率62% vs 43%。
非常に弱いモデル (Llama 8Bクラス)	シングル パス	モデルは多様な候補に対して弱すぎます。生成品質に投資します。

生成評価ギャップ

コア インサイト: Autoreason の値は、モデルの生成機能と自己評価機能のギャップに依存します。

Model Tier        │ Generation │ Self-Eval │ Gap    │ Autoreason Value
──────────────────┼────────────┼───────────┼────────┼─────────────────
Weak (Llama 8B)   │ Poor       │ Poor      │ Small  │ None — 多様な候補を生成できない
Mid (Haiku 3.5)   │ Decent     │ Poor      │ LARGE  │ MAXIMUM — 42/42完璧なBorda
Mid (Gemini Flash)│ Decent     │ Moderate  │ Large  │ High — 3つのうち2つを獲得
Strong (Sonnet 4) │ Good       │ Decent    │ Medium │ Moderate — 5つのうち3つを獲得
Frontier (S4.6)   │ Excellent  │ Good      │ Small  │ 制約付きの場合のみ

このギャップは一時的ではなく、構造的です。コストが低下するにつれて、今日の境界は明日の中層になります。スイート スポットは移動しますが、決して消えません。

Autoreason ループ (サマリー)

各パスは新しい分離されたエージェントから3つの候補を生成:

1. 批評家 → 現職A の問題を見つける (修正なし)
2. 著者B → 批評に基づいてAを修正
3. シンセサイザー → A と B をマージ (ランダム化ラベル)
4. 判定パネル → 3つの盲目CoT判定Bordaを介してA、B、ABをランク
5. 収束 → A がk=2連続パスを獲得 → 完了

主要パラメータ:

• k=2収束 (k=1早期、k=3費用がかかりすぎて品質向上なし)
• CoT判定常に (3倍高速な収束)
• 温度0.8著者、0.3判定
• 保守的なネクタイ切り: 現職がネクタイを獲得
• すべてのロールは共有コンテキストなしの新しいエージェント

論文ドラフトに適用する

autoreason 経由で論文自体を洗練される場合:

• グラウンドトゥルースを批評家に提供: 実際の実験データ、結果JSON、統計出力。これがなければ、モデルは製造されたアブレーション研究と偽の信頼区間を幻覚化します。
• 最小3つの作業判定を使用: 壊れた判定パーサーはノイズを追加しません — それは平衡を全体的に防ぎます。
• タスクのスコープを制限: "これらの特定の弱点に対応する" ではなく "論文を改善"。

エラー モード

エラー	検出	修正
収束なし (A は20+パスで決して獲得)	A <15%で獲得	タスクにスコープ制約を追加
シンテーシス ドリフト	ワード カウント無限に増加	構造と成果物を制限
シングル パスに劣化	ベースラインが反復出力より高いスコア	シングル パスに切り替え; モデルは弱すぎる
オーバーフィッティング (コード)	高いパブリック テスト パス、低いプライベート テスト パス	テスト フィードバックだけでなく構造化分析を使用
壊れた判定	パーサー エラーがパネルを3未満に削減	継続する前にパーサーを修正

完全なプロンプト、Borda スコアリング詳細、モデル選択ガイド、スコープ制約設計パターン、計算予算参照については、references/autoreason-methodology.md を参照してください。

---

Phase 5: 論文執筆

目標: 完全で出版可能な論文を執筆します。

大規模プロジェクトのコンテキスト管理

50以上の実験ファイル、複数の結果ディレクトリ、広範な文献メモを含む論文プロジェクトは、容易にエージェントのコンテキスト ウィンドウを超える場合があります。これを積極的に管理:

ドラフト タスクあたりコンテキストにロードするもの:

ドラフト タスク	コンテキストにロード	ロードしないでください
Introduction を作成	experiment_log.md、貢献ステートメント、5-10最も関連のあるペーパー要約	生の結果JSON、完全な実験スクリプト、すべての文献メモ
Methods を作成	実験設定、疑似コード、アーキテクチャ説明	生ログ、他の実験からの結果
結果を作成	experiment_log.md、結果要約表、図リスト	完全な分析スクリプト、中間データ
関連作業を作成	整理された引用メモ (Step 1.4出力)、.ibファイル	実験ファイル、生PDF
修正パス	完全な論文ドラフト、特定の査読者懸念	その他すべて

原則:

• experiment_log.md はプライマリ コンテキスト ブリッジ — 生データファイル (Step 4.6を参照) をロードせずにすべての必要なものを要約します。
• 1つのセクションのコンテキストを一度にロード 委任時。Methods をドラフトするサブエージェントは文献レビュー メモを必要としません。
• 生ファイルを含めずに要約します。 200行の結果JSONについては、10行のサマリー表をロードします。50ページの関連論文については、5文の要約+関連性についての2行のメモをロードします。
• 非常に大規模なプロジェクト用: 事前圧縮されたサマリーを使用して context/ ディレクトリを作成:

  context/
    contribution.md          # 1文
    experiment_summary.md    # 主要な結果表 (experiment_log.md から)
    literature_map.md        # 整理された引用メモ
    figure_inventory.md      # 説明付きの図のリスト
  

ナラティブ原則

最も重要な洞察: あなたの論文は実験の集まりではなく、証拠によってサポートされている1つの明確な貢献を持つストーリーです。

成功したすべてのML論文はNeel Nandaが「ナラティブ」と呼ぶ、短く、厳密で、証拠ベースの技術的ストーリーに焦点を当てています。

3つの柱 (Introduction 終了時に結晶清なら必須):

柱	説明	テスト
何 (The What)	1-3特定の新規主張	1文で述べることができますか?
なぜ (The Why)	厳密な経験的証拠	実験はあなたの仮説を代替から区別していますか?
だから何 (The So What)	読者が気にするべき理由	これは認識された社会問題に接続しますか?

1文で貢献を述べることができない場合、論文はまだありません。

このガイダンスの背後にあるソース

このスキルは、トップ会場で広く出版している研究者からの執筆哲学を統合します。執筆哲学層は元々Orchestra Researchによって ml-paper-writing スキルとしてコンパイルされました。

ソース	主要な寄稿	リンク
Neel Nanda (Google DeepMind)	ナラティブ原則、何/なぜ/だから何フレームワーク	ML論文を書く方法
Sebastian Farquhar (DeepMind)	5文要約公式	ML論文を書く方法
Gopen & Swan	読者期待の7原則	科学的執筆の科学
Zachary Lipton	単語選択、ヘッジの排除	科学的執筆のヒューリスティック
Jacob Steinhardt (UC Berkeley)	精密さ、一貫した用語	執筆ヒント
Ethan Perez (Anthropic)	マイクロレベルの明確性のヒント	簡単な論文執筆ヒント
Andrej Karpathy	単一貢献フォーカス	様々な講義

これらのいずれかの深い掘り下げ:

• references/writing-guide.md — 例を含む完全な説明
• references/sources.md — 完全な参考文献

時間配分

約同等の時間を各項目に費やします:

1. 要約
2. Introduction
3. 図
4. その他すべて

なぜ? ほとんどの査読者はメソッドに到達する前に判断を形成します。読者は論文に遭遇: タイトル → 要約 → Introduction → 図 → 多分その他。

執筆ワークフロー

論文執筆チェックリスト:
- [ ] Step 1: 1文の貢献を定義
- [ ] Step 2: Figure 1をドラフト (コア考え、または最も説得力のある結果)
- [ ] Step 3: 要約をドラフト (5文公式)
- [ ] Step 4: Introduction をドラフト (最大1-1.5ページ)
- [ ] Step 5: Methods をドラフト
- [ ] Step 6: 実験と結果をドラフト
- [ ] Step 7: 関連作業をドラフト
- [ ] Step 8: 結論と議論をドラフト
- [ ] Step 9: 制限をドラフト (すべての会場で必須)
- [ ] Step 10: 付録を計画 (証明、追加実験、詳細)
- [ ] Step 11: 完全な論文チェックリスト
- [ ] Step 12: 最終レビュー

2パス改善パターン

AIエージェントで草案を作成する場合、2パスアプローチを使用します (SakanaAIのAI-Scientist パイプラインで実証済み):

パス1 — セクションごとの執筆+即座的な改善: 各セクションについて、完全なドラフトを書いて、その後即座に改善します。これはセクションが新しいときにローカル問題 (clarity、flow、completeness) をキャッチします。

パス2 — 完全な論文コンテキストでのグローバル改善: すべてのセクションがドラフトされた後、完全な論文の認識を持って各セクションを再訪します。これはセクション間の問題をキャッチ: 冗長性、矛盾した用語、ナラティブ流、1つのセクションが別のセクションが配信しないものを約束するギャップ。

2パス目改善プロンプト (セクションごと):
"完全な論文のコンテキストの [SECTION] をレビューしてください。
- 論文の残りと適合していますか? 他のセクションとの冗長性はありますか?
- 用語はIntroductionとMethodsと一貫していますか?
- メッセージを弱めずに何かを削除できますか?
- ナラティブフローは前のセクションから引き出され、次のセクションに入りますか?
最小限で、ターゲット化された編集を行います。最初からやり直さないでください。"

LaTeX エラー チェックリスト

すべての改善プロンプトにこのチェックリストを追加してください。これらはL