research-paper-writing

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

NeurIPS、ICML、ICLR、ACL、AAAI、COLMを対象とした、投稿可能な品質の機械学習／AI研究論文を作成するためのエンドツーエンドパイプラインです。このスキルでは、実験の設計、実行、モニタリング、分析、論文執筆、査読、改訂、投稿に至る研究ライフサイクル全体を扱います。

これは直線的なパイプラインではありません。反復的なループです。結果を受けて新たな実験を行い、査読を受けて新たな分析を行います。エージェントは、こうしたフィードバックループに対応する必要があります。

┌─────────────────────────────────────────────────────────────┐
│                    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)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

このスキルを使う場面

次のような場合に、このスキルを使用します。

• 既存のコードベースやアイデアをもとに新しい研究論文に着手する
• 論文の主張を裏付けるために実験を設計・実行する
• 研究論文のセクションを執筆・改訂する
• 特定の学会やワークショップへの投稿準備をする
• 追加実験や改訂を行って査読に対応する
• 論文を別の学会のフォーマットに変換する
• 非実証的な論文を執筆する — 理論、サーベイ、ベンチマーク、ポジションペーパーなど（実証的な機械学習以外の論文の種類を参照）
• NLP、HCI、アラインメント研究のための人間による評価を設計する
• 採択後の成果物を準備する — ポスター、講演、コードの公開

基本方針

1. 先回りして行動します。 質問をするのではなく、完成度の高いドラフトを提示します。研究者は多忙です。まず具体的なものを作成して反応を得て、それから反復的に改善します。
2. 引用を捏造しません。 AIが生成した引用の約40％には誤りがあります。必ずプログラムを使って取得します。検証できない引用には[CITATION NEEDED]と記します。
3. 論文はストーリーであり、実験の寄せ集めではありません。 すべての論文には、一文で表現できる明確な貢献が必要です。それができなければ、その論文はまだ完成していません。
4. 実験は主張を裏付けるために行います。 すべての実験について、どの主張を裏付けるのかを明示する必要があります。論文の筋書きにつながらない実験は行いません。
5. 早めに、こまめにコミットします。 実験バッチを完了するたびに、論文のドラフトを更新するたびに、内容がわかるメッセージを添えてコミットします。Git のログが実験履歴になります。

先回りした協働

基本方針：先回りして行動します。まずドラフトを書き、ドラフトとともに質問します。

確信度	対応
高（リポジトリが明確で、貢献内容も明らか）	完全なドラフトを作成して提示し、フィードバックをもとに反復的に改善する
中（多少の曖昧さがある）	不確かな点を明示したドラフトを作成し、作業を続ける
低（大きな不明点がある）	clarifyを使って要点を絞った質問を1〜2件行い、その後ドラフトを作成する

セクション	自律的にドラフトを作成するか	ドラフトに添える注意書き
要約	はい	「貢献をXとして構成しました。必要に応じて修正してください」
序論	はい	「問題Yを重視しました。誤りがあれば修正してください」
手法	はい	「詳細A、B、Cを含めました。不足している点があれば追加してください」
実験	はい	「結果1、2、3を強調しました。必要に応じて順序を変更してください」
関連研究	はい	「論文X、Y、Zを引用しました。見落としがあれば追加してください」

次の場合に限り、入力を得るまで作業を保留します：投稿先が不明確な場合、複数の構成が互いに矛盾する場合、結果が不完全に見える場合、または先にレビューするよう明示的に依頼された場合。

---

フェーズ0：プロジェクトのセットアップ

目標：作業環境を整え、既存の成果を把握し、貢献を特定します。

ステップ0.1：リポジトリを調べる

# Understand project structure
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ファイル — 既存の引用
• ドラフト文書やメモ

ステップ0.2：作業環境を整理する

一貫性のある作業環境の構成を整えます。

workspace/
  paper/               # LaTeX source, figures, compiled PDFs
  experiments/         # Experiment runner scripts
  code/                # Core method implementation
  results/             # Raw experiment results (auto-generated)
  tasks/               # Task/benchmark definitions
  human_eval/          # Human evaluation materials (if needed)

ステップ0.3：バージョン管理を設定する

git init  # if not already
git remote add origin <repo-url>
git checkout -b paper-draft  # or 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: 貢献内容を明確にする

何かを書く前に、次の点を明確にしてください。

• 何を：この論文が貢献することは、ただ一つ何ですか？
• なぜ：どのような証拠がそれを裏付けていますか？
• それがなぜ重要か：読者が関心を持つべき理由は何ですか？

科学者に次のように提案します。「私の理解では、主な貢献は次のとおりです。[一文]。主な結果は[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: (model price per token) × (estimated tokens per run) × (number of runs)
- [ ] GPU hours: (time per experiment) × (number of experiments) × (number of seeds)
- [ ] Human evaluation costs: (annotators) × (hours) × (hourly rate)
- [ ] Total budget ceiling and contingency (add 30-50% for reruns)

実験の実行に伴い、実際の支出を記録します。

# Simple cost tracker pattern
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	補助ファイル用の .gitignore を設定した git	技術系チーム、ブランチベースのレビューが必要な場合
Overleaf + Git sync	Overleaf premium	両方の利点を活用 — バージョン履歴を備えたリアルタイム共同編集

セクションの担当：各セクションの主担当者を1人割り当てます。他の著者はコメントしますが、直接編集はしません。これにより、マージの競合やスタイルの不統一を防げます。

Author Coordination Checklist:
- [ ] Agree on section ownership (who writes what)
- [ ] Set up shared workspace (Overleaf or git repo)
- [ ] Establish notation conventions (before anyone writes)
- [ ] Schedule internal review rounds (not just at the end)
- [ ] Designate one person for final formatting pass
- [ ] Agree on figure style (colors, fonts, sizes) before creating figures

早い段階で合意しておく LaTeX の規約：

• メソッド名を統一するための \method{} マクロ
• 引用スタイル：\citet{} と \citep{} の使い分け
• 数式の表記：ベクトルには小文字の太字、行列には大文字の太字を使うなど
• イギリス英語とアメリカ英語のどちらを使うか

---

Phase 1: 文献レビュー

目標：関連研究を見つけ、ベースラインを特定し、引用文献を集めます。

Step 1.1: 起点となる論文を特定する

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

# Via terminal:
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 を使います。

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

# Via web_extract (for specific papers):
web_extract("https://arxiv.org/abs/2303.17651")

追加で試す検索クエリ：

Search queries:
- "[main technique] + [application domain]"
- "[baseline method] comparison"
- "[problem name] state-of-the-art"
- Author names from existing citations

推奨：リアルタイムの学術検索には Exa MCP をインストールします。

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

Step 1.2b: 検索を深める（まず幅広く、次に深く）

一度だけの検索では、重要な関連研究を見落としがちです。ディープリサーチのパイプラインを参考に、反復的な幅広く調べてから深掘りするパターンを使います。

Iterative Literature Search:

Round 1 (Breadth): 4-6 parallel queries covering different angles
  - "[method] + [domain]"
  - "[problem name] state-of-the-art 2024 2025"
  - "[baseline method] comparison"
  - "[alternative approach] vs [your approach]"
  → Collect papers, extract key concepts and terminology

Round 2 (Depth): Generate follow-up queries from Round 1 learnings
  - New terminology discovered in Round 1 papers
  - Papers cited by the most relevant Round 1 results
  - Contradictory findings that need investigation
  → Collect papers, identify remaining gaps

Round 3 (Targeted): Fill specific gaps
  - Missing baselines identified in Rounds 1-2
  - Concurrent work (last 6 months, same problem)
  - Key negative results or failed approaches
  → Stop when new queries return mostly papers you've already seen

検索を終えるタイミング：あるラウンドで、返された論文の80％超がすでに収集済みの場合、検索は飽和しています。通常は2～3ラウンドで十分です。サーベイ論文の場合は、4～5ラウンドを想定してください。

エージェントベースのワークフローの場合：各ラウンドのクエリを delegate_task で並行して委任します。結果を集めて重複を除去し、統合した知見から次のラウンドのクエリを生成します。

Step 1.3: すべての引用を検証する

BibTeX を記憶から生成してはいけません。必ずプログラムで取得してください。

各引用について、必須の5段階の手順に従います。

Citation Verification (MANDATORY per citation):
1. SEARCH → Query Semantic Scholar or Exa MCP with specific keywords
2. VERIFY → Confirm paper exists in 2+ sources (Semantic Scholar + arXiv/CrossRef)
3. RETRIEVE → Get BibTeX via DOI content negotiation (programmatically, not from memory)
4. VALIDATE → Confirm the claim you're citing actually appears in the paper
5. ADD → Add verified BibTeX to bibliography
If ANY step fails → mark as [CITATION NEEDED], inform scientist

# Fetch BibTeX via DOI
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: 関連研究を整理する

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

良い例：「ある研究の流れではXの仮定を用いています[引用]が、私たちはYの仮定を用います。その理由は……」 悪い例：「SmithらはXを提案しました。JonesらはYを提案しました。私たちは両方を組み合わせます。」

---

Phase 2: 実験設計

目標：論文の主張を直接裏付ける実験を設計します。すべての実験で、具体的な問いに答える必要があります。

ステップ 2.1: 主張を実験にマッピングする

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

主張	実験	期待される証拠
「私たちの手法はベースラインを上回る」	主要な比較 (表 1)	勝率、統計的有意性
「効果は弱いモデルほど大きい」	モデルスケーリング研究	単調な改善曲線
「収束にはスコープ制約が必要」	制約あり vs 制約なし	収束率の比較

ルール: 実験が主張にマッピングされないなら、実行しないでください。

ステップ 2.2: ベースラインを設計する

強力なベースラインは、採択される論文と却下される論文を分けるものです。査読者はこう尋ねます: 「彼らは X と比較したのか?」

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

• ナイーブベースライン: 可能な限り最も単純なアプローチ
• 強力なベースライン: 既知の最良の既存手法
• アブレーションベースライン: あなたの手法から 1 つのコンポーネントを除いたもの
• 計算量を揃えたベースライン: 同じ計算予算、異なる配分

ステップ 2.3: 評価プロトコルを定義する

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

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

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

成功した研究パイプラインから、これらのパターンに従ってください:

インクリメンタル保存 — クラッシュからの復旧のために各ステップ後に結果を保存します:

# Save after each problem/task
result_path = f"results/{task}/{strategy}/result.json"
if os.path.exists(result_path):
    continue  # Skip already-completed work
# ... run experiment ...
with open(result_path, 'w') as f:
    json.dump(result, f, indent=2)

成果物の保存 — すべての中間出力を保存します:

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # Final result
      history.json             # Full trajectory
      pass_01/                 # Per-iteration artifacts
        version_a.md
        version_b.md
        critic.md

関心の分離 — 生成、評価、可視化を分離しておきます:

run_experiment.py              # Core experiment runner
run_baselines.py               # Baseline comparison
run_comparison_judge.py        # Blind evaluation
analyze_results.py             # Statistical analysis
make_charts.py                 # Visualization

完全な設計パターン、cron モニタリング、エラー復旧については references/experiment-patterns.md を参照してください。

ステップ 2.5: 人手評価を設計する (該当する場合)

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

人手評価が必要になる場合:

• 自動メトリクスが、あなたが重視するもの (流暢さ、有用性、安全性) を捉えていない
• あなたの貢献が、人間に向けた品質 (読みやすさ、好み、信頼) に関するものである
• NLP 系の会議 (ACL、EMNLP) の査読者が、生成タスクにおいてそれを期待している

主要な設計上の決定:

決定	選択肢	ガイダンス
アノテーターの種類	専門家、クラウドワーカー、エンドユーザー	あなたの主張が要求するものに合わせる
尺度	リッカート (1-5)、一対比較、ランキング	LLM の出力にはリッカートよりも一対比較の方が信頼性が高い
サンプルサイズ	アノテーターごと、および総項目数	検出力分析、または最低 100 項目、3 人以上のアノテーター
一致度の指標	Cohen's kappa、Krippendorff's alpha、ICC	3 人以上のアノテーターには Krippendorff's alpha、生の一致率も報告する
プラットフォーム	Prolific、MTurk、社内チーム	品質には Prolific、規模には MTurk、ドメイン専門知識には社内

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

- [ ] Clear task description with examples (good AND bad)
- [ ] Decision criteria for ambiguous cases
- [ ] At least 2 worked examples per category
- [ ] Attention checks / gold standard items (10-15% of total)
- [ ] Qualification task or screening round
- [ ] Estimated time per item and fair compensation (>= local minimum wage)
- [ ] IRB/ethics review if required by your institution

報告要件 (査読者はこれらすべてを確認します):

• アノテーターの人数とその資格
• 具体的な指標と値を伴うアノテーター間一致度
• 報酬の詳細 (金額、推定時給)
• アノテーションインターフェースの説明またはスクリーンショット (付録)
• 総アノテーション時間

人手評価データの統計的検定、クラウドソーシングの品質管理パターン、IRB のガイダンスを含む完全なガイドについては references/human-evaluation.md を参照してください。

---

フェーズ 3: 実験の実行とモニタリング

目標: 実験を確実に実行し、進捗を監視し、失敗から復旧する。

ステップ 3.1: 実験を起動する

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

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

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

Step 3.2: モニタリングを設定する（Cron パターン）

長時間実行する実験では、定期的なステータス確認を設定します。Cron プロンプトは次のテンプレートに従います。

Monitor Prompt Template:
1. Check if process is still running: ps aux | grep <pattern>
2. Read last 30 lines of log: tail -30 <logfile>
3. Check for completed results: ls <result_dir>
4. If results exist, read and report: cat <result_file>
5. If all done, commit: git add -A && git commit -m "<descriptive message>" && git push
6. Report in structured format (tables with key metrics)
7. Answer the key analytical question for this experiment

サイレントモード：前回の確認から何も変わっていない場合は、ユーザーへの通知を抑制するために [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 — append one entry per experiment attempt
{
  "id": "exp_003",
  "parent": "exp_001",
  "timestamp": "2025-05-10T14:30:00Z",
  "hypothesis": "Adding scope constraints will fix convergence failure from exp_001",
  "plan": "Re-run autoreason with max_tokens=2000 and fixed structure template",
  "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": "Scope constraints fixed convergence. Win rate jumped from 0.42 to 0.85.",
  "next_steps": ["Try same constraints on Sonnet", "Test without structure template"],
  "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

これにより、その後コードを変更しても、実験を正確に再現できます。

---

フェーズ 4：結果の分析

目標：知見を抽出し、統計量を算出して、ストーリーを見極めます。

Step 4.1: 結果を集計する

次の処理を行う分析スクリプトを作成します。

1. バッチ内のすべての結果ファイルを読み込む
2. タスクごとの指標と集計指標を算出する
3. サマリーテーブルを生成する

# Standard analysis pattern
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

# Compute aggregate metrics
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 の d または h

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

Step 4.3: ストーリーを見極める

分析後、次の問いに明確に答えます。

1. 主な知見は何ですか？ 1 文で述べます。
2. 何が意外でしたか？ 予想外の結果が、最良の論文につながることはよくあります。
3. 何が失敗しましたか？ 失敗した実験が最も有益な場合があります。失敗を誠実に報告することで、論文の信頼性が高まります。
4. どのような追試が必要ですか？ 結果から新たな疑問が生じることはよくあります。

ネガティブまたは有意差なしの結果の扱い

仮説が間違っていた、または結果が結論を出せないものであった場合、3つの選択肢があります。

状況	対応	適した投稿先
仮説は間違っていたが、なぜが有益	なぜの分析を中心に論文を構成する	NeurIPS、ICML（分析が厳密であれば）
手法がベースラインを上回らないが、何か新しいことを明らかにした	貢献を理解/分析として再構成する	ICLR（理解を重視）、ワークショップ論文
一般的な主張に対するクリーンなネガティブ結果	論文にまとめる — 分野はそれを知る必要がある	NeurIPS Datasets & Benchmarks、TMLR、ワークショップ
結果が結論を出せず、明確なストーリーがない	方向転換する — 別の実験を行うか再構成する	存在しない論文を無理に書かない

ネガティブ結果の論文の書き方:

• コミュニティが信じていることと、それを検証することがなぜ重要かを最初に述べる
• 厳密な方法論を説明する（隙のないものでなければならない — 査読者はより厳しく精査します）
• 統計的根拠とともに有意差なしの結果を明確に提示する
• 期待された結果がなぜ実現しなかったのかを分析する
• 分野への影響について議論する

ネガティブ結果を明示的に歓迎する投稿先: NeurIPS（Datasets & Benchmarksトラック）、TMLR、ML Reproducibility Challenge、主要会議のワークショップ。一部のワークショップはネガティブ結果を特に募集しています。

ステップ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}

ステップ4.5: 判断: さらに実験するか、書くか？

状況	対応
中核的な主張が裏付けられ、結果が有意	フェーズ5（執筆）に進む
結果が結論を出せず、さらにデータが必要	フェーズ2（設計）に戻る
予想外の発見が新しい方向性を示唆	フェーズ2（設計）に戻る
査読者が求めるアブレーションが1つ欠けている	それを実行してからフェーズ5へ
すべての実験は完了したが、一部が失敗した	失敗を記録し、フェーズ5に進む

ステップ4.6: 実験ログの作成（執筆への橋渡し）

論文執筆に移る前に、結果を文章につなぐ構造化された実験ログを作成します。これは実験と執筆の間をつなぐ最も重要な結節点です — これがなければ、執筆エージェントは生の結果ファイルからストーリーを再構築しなければなりません。

以下の構造で experiment_log.md を作成します:

# Experiment Log

## Contribution (one sentence)
[The paper's main claim]

## Experiments Run

### Experiment 1: [Name]
- **Claim tested**: [Which paper claim this supports]
- **Setup**: [Model, dataset, config, number of runs]
- **Key result**: [One sentence with the number]
- **Result files**: results/exp1/final_info.json
- **Figures generated**: figures/exp1_comparison.pdf
- **Surprising findings**: [Anything unexpected]

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

## Figures
| Filename | Description | Which section it belongs in |
|----------|-------------|---------------------------|
| figures/main_comparison.pdf | Bar chart comparing all methods on benchmark X | Results, Figure 2 |
| figures/ablation.pdf | Ablation removing components A, B, C | Results, Figure 3 |
...

## Failed Experiments (document for honesty)
- [What was tried, why it failed, what it tells us]

## Open Questions
- [Anything the results raised that the paper should address]

これが重要な理由: 下書きを作成する際、エージェント（または委任されたサブエージェント）は experiment_log.md をLaTeXテンプレートとともに読み込み、実際の結果に基づいた初稿を作成できます。この橋渡しがなければ、執筆エージェントは生のJSON/CSVファイルを解析してストーリーを推測しなければなりません — これはハルシネーションや誤報告の数値の一般的な原因です。

Gitの規律: このログを、それが記述する結果と一緒にコミットしてください。

---

反復的な改善: 戦略の選択

このパイプラインにおけるあらゆる成果物 — 論文の下書き、実験スクリプト、分析 — は反復的に改善できます。autoreasonの研究は、各改善戦略がいつ機能し、いつ失敗するかについての実証的な証拠を提供しています。このセクションを使用して、適切なアプローチを選択してください。

クイック判断表

状況	戦略	理由
中位モデル＋制約のあるタスク	Autoreason	最適な組み合わせです。生成能力と評価能力の差が最も大きくなります。ベースラインは弱いモデルの出力を積極的に損ないます。
中位モデル＋オープンなタスク	制約を加えた Autoreason	固定された事実、構成、または成果物を加え、改善の余地を限定します。
最先端モデル＋制約のあるタスク	Autoreason	最先端モデルでも、制約のあるタスクの3分の2で優れた結果を出します。
最先端モデル＋制約のないタスク	Critique-and-revise または single pass	Autoreasonは最も低い結果になります。モデルは十分に自己評価できます。
具体的な技術タスク（システム設計）	Critique-and-revise	問題を直接見つけて修正するループのほうが効率的です。
テンプレート記入タスク（正解の構成が1つ）	Single pass または conservative	判断の余地が最小限です。反復しても価値は増えません。
テストケース付きのコード	Autoreason（コード版）	修正前に、失敗した理由を構造的に分析します。復旧率は62％で、43％を上回ります。
非常に弱いモデル（Llama 8Bクラス）	Single pass	多様な候補を生成するにはモデルの能力が不足しています。生成品質の向上に注力してください。

生成能力と評価能力の差

核心的な洞察：Autoreasonの価値は、モデルの生成能力と自己評価能力の差に左右されます。

Model Tier        │ Generation │ Self-Eval │ Gap    │ Autoreason Value
──────────────────┼────────────┼───────────┼────────┼─────────────────
Weak (Llama 8B)   │ Poor       │ Poor      │ Small  │ None — can't generate diverse candidates
Mid (Haiku 3.5)   │ Decent     │ Poor      │ LARGE  │ MAXIMUM — 42/42 perfect Borda
Mid (Gemini Flash)│ Decent     │ Moderate  │ Large  │ High — wins 2/3
Strong (Sonnet 4) │ Good       │ Decent    │ Medium │ Moderate — wins 3/5
Frontier (S4.6)   │ Excellent  │ Good      │ Small  │ Only with constraints

この差は一時的なものではなく、構造的なものです。コストが下がれば、今日の最先端モデルは明日の中位モデルになります。最適な領域は移り変わりますが、なくなることはありません。

Autoreasonのループ（概要）

各パスでは、独立した新しいエージェントから3つの候補が生成されます。

1. Critic → 現行のAの問題点を見つけます（修正はしません）
2. Author B → 批評に基づいてAを改訂します
3. Synthesizer → AとBを統合します（ラベルはランダム化）
4. Judge Panel → 3つのブラインドCoT審査員が、ボルダ得点方式でA、B、ABを順位付けします
5. 収束 → Aが連続k=2回のパスで勝利したら完了です

主なパラメーター：

• k=2で収束（k=1は早すぎ、k=3はコストがかかりすぎ、品質向上なし）
• 常にCoT審査員を使用（収束が3倍速くなります）
• Authorの温度は0.8、Judgeの温度は0.3
• 保守的なタイブレーク：同点の場合は現行案が勝利します
• 各役割には、共有コンテキストを持たない新しいエージェントを使用します

論文原稿への適用

Autoreasonで論文自体を改訂する場合：

• 批評者に正解データを提供する：実際の実験データ、結果のJSON、統計出力を提供します。これがないと、モデルは存在しないアブレーション研究や偽の信頼区間を捏造することがあります。
• 最低3人の審査員を稼働させる：審査員のパーサーが壊れていると、単にノイズが増えるのではなく、均衡そのものが成立しなくなります。
• 改訂範囲を制約する：「論文を改善する」ではなく、「これらの具体的な弱点に対処する」と指定します。

失敗モード

失敗	検出方法	対処法
収束しない（Aが一度も勝たない）	20回以上のパスでAの勝率が15％未満	タスクに範囲の制約を追加します
統合による逸脱	語数が際限なく増加する	構成と成果物を制約します
シングルパスより品質が低下	ベースラインのスコアが反復後の出力を上回る	シングルパスに切り替えます。モデルの能力が不足している可能性があります
過学習（コード）	公開テストの合格率は高いが、非公開テストの合格率が低い	テストのフィードバックだけでなく、構造的な分析を使用します
審査員の不具合	パースエラーにより審査パネルが3人を下回る	続行する前にパーサーを修正します

完全なプロンプト、ボルダ得点の詳細、モデル選定ガイド、範囲の制約を設計するパターン、計算予算の参考情報については、references/autoreason-methodology.md を参照してください。

---

フェーズ5：論文の草稿作成

論文の草稿作成手順一式（セクションごとの順序、LaTeXのひな形、図表の規約、要旨と序論の公式、関連研究における位置付け）は、 references/phase5-paper-drafting.md に記載されています。このフェーズに進んだら、read_file を使って読み込んでください。 文章レベルのスタイル規則については、references/writing-guide.md も併せて参照してください。

フェーズ6：セルフレビューと改訂

目標：投稿前に査読プロセスをシミュレーションします。弱点を早期に見つけます。

Step 6.1: レビューをシミュレートする（アンサンブルパターン）

複数の視点からレビューを生成します。自動化された研究パイプライン（特に SakanaAI の AI-Scientist）から得られた重要な知見は、メタレビュアーと組み合わせたアンサンブルレビューは、単一回のレビューよりもはるかに偏りの少ないフィードバックを生み出すということです。

Step 1: N 件の独立したレビューを生成する（N=3-5）

異なるモデルまたは温度設定を使用します。各レビュアーは論文のみを見て、他のレビューは見ません。否定的なバイアスをデフォルトにします — LLM が評価において肯定的に偏ることは、十分に文書化されています。

You are an expert reviewer for [VENUE]. You are critical and thorough.
If a paper has weaknesses or you are unsure about a claim, flag it clearly
and reflect that in your scores. Do not give the benefit of the doubt.

Review this paper according to the official reviewer guidelines. Evaluate:

1. Soundness (are claims well-supported? are baselines fair and strong?)
2. Clarity (is the paper well-written? could an expert reproduce it?)
3. Significance (does this matter to the community?)
4. Originality (new insights, not just incremental combination?)

Provide your review as structured JSON:
{
  "summary": "2-3 sentence summary",
  "strengths": ["strength 1", "strength 2", ...],
  "weaknesses": ["weakness 1 (most critical)", "weakness 2", ...],
  "questions": ["question for authors 1", ...],
  "missing_references": ["paper that should be cited", ...],
  "soundness": 1-4,
  "presentation": 1-4,
  "contribution": 1-4,
  "overall": 1-10,
  "confidence": 1-5
}

Step 2: メタレビュー（エリアチェアによる集約）

N 件すべてのレビューをメタレビュアーに渡します。

You are an Area Chair at [VENUE]. You have received [N] independent reviews
of a paper. Your job is to:

1. Identify consensus strengths and weaknesses across reviewers
2. Resolve disagreements by examining the paper directly
3. Produce a meta-review that represents the aggregate judgment
4. Use AVERAGED numerical scores across all reviews

Be conservative: if reviewers disagree on whether a weakness is serious,
treat it as serious until the authors address it.

Reviews:
[review_1]
[review_2]
...

Step 3: リフレクションループ（任意、2-3 ラウンド）

メタレビューを見た後、各レビュアーはレビューを修正できます。早期終了のセンチネルを使用します。レビュアーが「I am done」（変更なし）と回答した場合は、反復を終了します。

レビュー用モデルの選択：レビューは、たとえより安価なモデルで論文を執筆した場合でも、利用可能な最も強力なモデルで行うのが最適です。レビュアーモデルは執筆モデルとは独立して選ぶ必要があります。

少数例によるキャリブレーション：利用可能であれば、投稿先の会場から実際に公開されたレビューを 1-2 件、例として含めます。これによりスコアのキャリブレーションが大幅に向上します。レビューの例については、references/reviewer-guidelines.md を参照してください。

Step 6.1b: ビジュアルレビューパス（VLM）

テキストのみのレビューでは、図の品質、レイアウトの問題、視覚的な一貫性といった問題を見落とします。視覚対応モデルを利用できる場合は、コンパイル済み PDF に対して別途ビジュアルレビューを実施します。

You are reviewing the visual presentation of this research paper PDF.
Check for:
1. Figure quality: Are plots readable? Labels legible? Colors distinguishable?
2. Figure-caption alignment: Does each caption accurately describe its figure?
3. Layout issues: Orphaned section headers, awkward page breaks, figures far from their references
4. Table formatting: Aligned columns, consistent decimal precision, bold for best results
5. Visual consistency: Same color scheme across all figures, consistent font sizes
6. Grayscale readability: Would the figures be understandable if printed in B&W?

For each issue, specify the page number and exact location.

これにより、テキストベースのレビューでは検出できない問題を見つけられます。たとえば、軸ラベルが読めないプロット、初めて参照される箇所から 3 ページ離れて配置された図、Figure 2 と Figure 5 で異なるカラーパレット、あるいは明らかに段組みの幅を超えている表などです。

Step 6.1c: 主張の検証パス

シミュレーションレビューの後、別途検証パスを実施します。これにより、レビュアーが見落とす可能性のある事実誤認を検出できます。

Claim Verification Protocol:
1. Extract every factual claim from the paper (numbers, comparisons, trends)
2. For each claim, trace it to the specific experiment/result that supports it
3. Verify the number in the paper matches the actual result file
4. Flag any claim without a traceable source as [VERIFY]

エージェントベースのワークフローでは、論文のテキストと生の結果ファイルのみを受け取る新しいサブエージェントに検証を委任します。新しいコンテキストにすることで確証バイアスを防ぎ、検証者が結果について本来どうあるべきだったかを「記憶」しないようにします。

Step 6.2: フィードバックの優先順位付け

レビューを集めた後、分類します。

優先度	対応
重大（技術的な欠陥、ベースラインの欠落）	必ず修正します。新たな実験が必要な場合は、フェーズ 2 に戻ります
高（明瞭さの問題、アブレーションの欠落）	今回の改訂で修正します
中（軽微な執筆上の問題、追加の実験）	時間があれば修正します
低（スタイルの好み、関連性の低い提案）	今後の作業に向けて記録します

Step 6.3: 改訂サイクル

重大または優先度の高い問題ごとに、次の手順を実施します。

1. 影響を受ける具体的なセクションを特定します
2. 修正案を作成します
3. 修正によって他の主張が損なわれないことを確認します
4. 論文を更新します
5. レビュアーの懸念に対応できているか再確認します

Step 6.4: 反論文の執筆

実際のレビューに回答する場合（投稿後）、反論文の執筆は改訂とは異なるスキルです。

形式：各レビュアーの懸念に対し、一つずつ回答します。

> R1-W1: "The paper lacks comparison with Method X."

We thank the reviewer for this suggestion. We have added a comparison with 
Method X in Table 3 (revised). Our method outperforms X by 3.2pp on [metric] 
(p<0.05). We note that X requires 2x our compute budget.

ルール：

• すべての懸念に対応します — 一つでも飛ばすとレビュアーに気づかれます
• 最も強い回答から始めます
• 簡潔かつ直接的に書きます — レビュアーは多数の反論文に目を通します
• 反論期間中に実験を行った場合は、新しい結果を含めます
• 弱い批判であっても、決して防御的になったり、軽視したりしません
• 変更箇所を示す PDF を生成するには latexdiff を使用します（「Professional LaTeX Tooling」セクションを参照）
• 一般的な称賛ではなく、具体的で実行可能なフィードバックに対してレビュアーに感謝します

避けるべきこと：根拠を示さずに「謹んで異議を唱えます」と述べること。説明なしに「対象範囲外です」と述べること。強みのみに回答して、弱点を無視すること。

Step 6.5: 論文の変更履歴の記録

重要なマイルストーンごとにスナップショットを保存します。

paper/
  paper.tex                    # Current working version
  paper_v1_first_draft.tex     # First complete draft
  paper_v2_post_review.tex     # After simulated review
  paper_v3_pre_submission.tex  # Final before submission
  paper_v4_camera_ready.tex    # Post-acceptance final

---

Phase 7: 投稿準備

目標：最終確認、フォーマット調整、投稿を行います。

ステップ 7.1：学会チェックリスト

各会場には必須のチェックリストがあります。慎重に記入してください。未記入の項目があると、デスクリジェクトにつながる可能性があります。

references/checklists.md を参照してください。

• NeurIPS の 16 項目の論文チェックリスト
• ICML の広範な影響と再現性
• ICLR の LLM 開示ポリシー
• ACL の必須の制限事項セクション
• 投稿前の共通チェックリスト

ステップ 7.2：匿名化チェックリスト

ダブルブラインド査読では、査読者に論文の執筆者が知られないようにする必要があります。以下の項目をすべて確認してください。

Anonymization Checklist:
- [ ] No author names or affiliations anywhere in the PDF
- [ ] No acknowledgments section (add after acceptance)
- [ ] Self-citations written in third person: "Smith et al. [1] showed..." not "We previously showed [1]..."
- [ ] No GitHub/GitLab URLs pointing to your personal repos
- [ ] Use Anonymous GitHub (https://anonymous.4open.science/) for code links
- [ ] No institutional logos or identifiers in figures
- [ ] No file metadata containing author names (check PDF properties)
- [ ] No "our previous work" or "in our earlier paper" phrasing
- [ ] Dataset names don't reveal institution (rename if needed)
- [ ] Supplementary materials don't contain identifying information

よくある間違い：補足コードに Git のコミットメッセージが表示されている、機関のツールで作成した図に透かしが入っている、以前の草稿の謝辞が残っている、匿名化期間の前に arXiv のプレプリントを公開している。

ステップ 7.3：フォーマットの確認

Pre-Submission Format Check:
- [ ] Page limit respected (excluding references and appendix)
- [ ] All figures are vector (PDF) or high-res raster (600 DPI PNG)
- [ ] All figures readable in grayscale
- [ ] All tables use booktabs
- [ ] References compile correctly (no "?" in citations)
- [ ] No overfull hboxes in critical areas
- [ ] Appendix clearly labeled and separated
- [ ] Required sections present (limitations, broader impact, etc.)

ステップ 7.4：コンパイル前の検証

pdflatex を実行する前に、これらの自動チェックを実行してください。ここでエラーを見つけるほうが、コンパイラの出力をデバッグするよりも早く解決できます。

# 1. Lint with chktex (catches common LaTeX mistakes)
# Suppress noisy warnings: -n2 (sentence end), -n24 (parens), -n13 (intersentence), -n1 (command terminated)
chktex main.tex -q -n2 -n24 -n13 -n1

# 2. Verify all citations exist in .bib
# Extract \cite{...} from .tex, check each against .bib
python3 -c "
import re
tex = open('main.tex').read()
bib = open('references.bib').read()
cites = set(re.findall(r'\\\\cite[tp]?{([^}]+)}', tex))
for cite_group in cites:
    for cite in cite_group.split(','):
        cite = cite.strip()
        if cite and cite not in bib:
            print(f'WARNING: \\\\cite{{{cite}}} not found in references.bib')
"

# 3. Verify all referenced figures exist on disk
python3 -c "
import re, os
tex = open('main.tex').read()
figs = re.findall(r'\\\\includegraphics(?:\[.*?\])?{([^}]+)}', tex)
for fig in figs:
    if not os.path.exists(fig):
        print(f'WARNING: Figure file not found: {fig}')
"

# 4. Check for duplicate \label definitions
python3 -c "
import re
from collections import Counter
tex = open('main.tex').read()
labels = re.findall(r'\\\\label{([^}]+)}', tex)
dupes = {k: v for k, v in Counter(labels).items() if v > 1}
for label, count in dupes.items():
    print(f'WARNING: Duplicate label: {label} (appears {count} times)')
"

先に進む前に、警告をすべて修正してください。エージェントベースのワークフローでは、chktex の出力をエージェントに渡し、最小限の修正を行うよう指示してください。

ステップ 7.5：最終コンパイル

# Clean build
rm -f *.aux *.bbl *.blg *.log *.out *.pdf
latexmk -pdf main.tex

# Or manual (triple pdflatex + bibtex for cross-references)
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex

# Verify output exists and has content
ls -la main.pdf

コンパイルに失敗した場合：.log ファイルを調べ、最初のエラーを特定します。よくある修正方法は次のとおりです。

• "Undefined control sequence" → パッケージが不足しているか、コマンド名に誤字があります
• "Missing $ inserted" → 数式モードの外で数式記号を使っています
• "File not found" → 図のパスが間違っているか、.sty ファイルが不足しています
• "Citation undefined" → .bib エントリが不足しているか、bibtex が実行されていません

ステップ 7.6：学会固有の要件

会場	特別な要件
NeurIPS	付録に論文チェックリストを記載し、採択された場合は一般向けの要約を提出
ICML	広範な影響に関する声明（結論の後に記載し、ページ数の上限には含まれません）
ICLR	LLM の開示が必須で、相互査読の合意が必要
ACL	制限事項セクションが必須で、Responsible NLP チェックリストが必要
AAAI	厳格なスタイルファイルを使用し、変更は一切不可
COLM	言語モデルコミュニティに向けて貢献を位置付ける

ステップ 7.7：学会への再投稿とフォーマット変換

投稿先を変更する際は、テンプレート間で LaTeX のプリアンブルをコピーしないでください。

# 1. Start fresh with target template
cp -r templates/icml2026/ new_submission/

# 2. Copy ONLY content sections (not preamble)
#    - Abstract text, section content, figures, tables, bib entries

# 3. Adjust for page limits
# 4. Add venue-specific required sections
# 5. Update references

変更元 → 変更先	ページ数の変更	主な調整
NeurIPS → ICML	9 → 8	1 ページ削減し、広範な影響を追加
ICML → ICLR	8 → 9	実験を拡充し、LLM の開示を追加
NeurIPS → ACL	9 → 8	NLP の慣例に合わせて構成を変更し、制限事項を追加
ICLR → AAAI	9 → 7	大幅に削減し、厳格にスタイルに準拠
任意 → COLM	変動 → 9	言語モデルを中心とした内容に再構成

ページ数を削減する場合：証明を付録に移し、関連研究を簡潔にし、表を統合し、サブ図を使います。 ページ数を増やす場合：アブレーションを追加し、制限事項を詳しくし、追加のベースラインを含め、定性的な例を追加します。

不採択後：査読者の懸念に新しいバージョンで対応しますが、「変更点」のセクションを追加したり、以前の投稿に言及したりしないでください（ブラインド査読のため）。

ステップ 7.8：カメラレディ原稿の準備（採択後）

採択後、カメラレディ版を準備します。

Camera-Ready Checklist:
- [ ] De-anonymize: add author names, affiliations, email addresses
- [ ] Add Acknowledgments section (funding, compute grants, helpful reviewers)
- [ ] Add public code/data URL (real GitHub, not anonymous)
- [ ] Address any mandatory revisions from meta-reviewer
- [ ] Switch template to camera-ready mode (if applicable — e.g., AAAI \anon → \camera)
- [ ] Add copyright notice if required by venue
- [ ] Update any "anonymous" placeholders in text
- [ ] Verify final PDF compiles cleanly
- [ ] Check page limit for camera-ready (sometimes differs from submission)
- [ ] Upload supplementary materials (code, data, appendix) to venue portal

ステップ 7.9：arXiv とプレプリントの方針

ML では arXiv への投稿が一般的ですが、タイミングと匿名性について重要な考慮事項があります。

タイミングの判断基準：

状況	推奨事項
ダブルブラインド方式の会議に投稿する場合（NeurIPS、ICML、ACL）	投稿締切の後に arXiv に投稿し、前には投稿しないでください。先に投稿すると、匿名性に関するポリシーに技術的に違反する可能性があります。ただし、適用の厳しさは会議によって異なります。
ICLR に投稿する場合	ICLR では、投稿前の arXiv への投稿が明示的に認められています。ただし、投稿原稿自体には著者名を記載しないでください。
論文がすでに arXiv にあり、新しい会議に投稿する場合	ほとんどの会議で問題ありません。査読期間中に、査読コメントへの言及を含む変更を arXiv のバージョンに反映しないでください。
ワークショップの論文	ワークショップは通常ダブルブラインド方式ではないため、いつ arXiv に投稿しても問題ありません。
優先権を確立したい場合	先取される懸念がある場合は、すぐに投稿してください。ただし、匿名性とのトレードオフを受け入れてください。

arXiv のカテゴリ選択（ML／AI 論文）：

カテゴリ	コード	主な対象
機械学習	cs.LG	一般的な ML 手法
計算と言語	cs.CL	NLP、言語モデル
人工知能	cs.AI	推論、計画、エージェント
コンピュータビジョン	cs.CV	ビジョンモデル
情報検索	cs.IR	検索、レコメンデーション

**主カテゴリに加え、関連カテゴリを1～2件追加してください。**カテゴリを増やすと見つけられやすくなりますが、本当に関連するカテゴリのみを追加してください。

バージョン管理の方針：

• v1：初回投稿（会議への投稿内容と一致）
• v2：採択後、カメラレディ版の修正を反映したもの（アブストラクトに「[Venue] で採択」と追加）
• 査読期間中に、査読者のフィードバックへの対応が明らかな変更を加えた v2 を投稿しないでください

# Check if your paper's title is already taken on arXiv
# (before choosing a title)
pip install arxiv
python -c "
import arxiv
results = list(arxiv.Search(query='ti:\"Your Exact Title\"', max_results=5).results())
print(f'Found {len(results)} matches')
for r in results: print(f'  {r.title} ({r.published.year})')
"

ステップ 7.10：研究コードのパッケージ化

整理され、実行可能なコードを公開すると、引用数と査読者の信頼が大幅に高まります。カメラレディ版の投稿とあわせてコードをパッケージ化してください。

リポジトリの構成：

your-method/
  README.md              # Setup, usage, reproduction instructions
  requirements.txt       # Or environment.yml for conda
  setup.py               # For pip-installable packages
  LICENSE                # MIT or Apache 2.0 recommended for research
  configs/               # Experiment configurations
  src/                   # Core method implementation
  scripts/               # Training, evaluation, analysis scripts
    train.py
    evaluate.py
    reproduce_table1.sh  # One script per main result
  data/                  # Small data or download scripts
    download_data.sh
  results/               # Expected outputs for verification

研究コード用 README テンプレート：

# [Paper Title]

Official implementation of "[Paper Title]" (Venue Year).

## Setup
[Exact commands to set up environment]

## Reproduction
To reproduce Table 1: `bash scripts/reproduce_table1.sh`
To reproduce Figure 2: `python scripts/make_figure2.py`

## Citation
[BibTeX entry]

公開前のチェックリスト：

- [ ] Code runs from a clean clone (test on fresh machine or Docker)
- [ ] All dependencies pinned to specific versions
- [ ] No hardcoded absolute paths
- [ ] No API keys, credentials, or personal data in repo
- [ ] README covers setup, reproduction, and citation
- [ ] LICENSE file present (MIT or Apache 2.0 for max reuse)
- [ ] Results are reproducible within expected variance
- [ ] .gitignore excludes data files, checkpoints, logs

投稿用の匿名コード（採択前）：

# Use Anonymous GitHub for double-blind review
# https://anonymous.4open.science/
# Upload your repo → get an anonymous URL → put in paper

---

フェーズ 8：採択後の成果物

目標：発表資料の作成とコミュニティへの参加を通じて、採択された論文のインパクトを最大化します。

ステップ 8.1：会議ポスター

ほとんどの会議ではポスターセッションが必要です。ポスターのデザイン原則は次のとおりです。

要素	ガイドライン
サイズ	会場の要件を確認してください（通常、24"x36" または A0 縦向き／横向き）
内容	タイトル、著者、1文での貢献、手法の図、主要な結果2～3件、結論
構成	左上から右下への流れ（Z パターン）、または列形式
テキスト	タイトルは3m、本文は1m離れた位置から読める大きさにします。段落は使わず、箇条書きのみを使用してください。
図	論文の図を高解像度で再利用します。重要な結果は拡大してください。

ツール：LaTeX（beamerposter パッケージ）、PowerPoint／Keynote、Figma、Canva。

制作：会議の2週間以上前に発注してください。布製ポスターは持ち運びに便利です。現在は多くの会議で、バーチャル／デジタルポスターにも対応しています。

ステップ 8.2：会議での講演／スポットライト発表

口頭発表またはスポットライト発表に選ばれた場合：

発表の種類	所要時間	内容
スポットライト	5分	問題、アプローチ、重要な結果を1つ。5分ちょうどになるように練習してください。
口頭発表	15～20分	全体の流れ：問題、アプローチ、主要な結果、アブレーション、制約事項。
ワークショップでの発表	10～15分	ワークショップの参加者に合わせて調整してください。背景説明を増やす必要がある場合があります。

スライドのデザインルール：

• 1枚のスライドにつき、アイデアは1つにします
• テキストを最小限にします。詳細は口頭で説明し、スライドに詰め込まないでください
• 重要な図をアニメーション化し、段階的に理解できるようにします
• 最後に「要点」のスライドを入れます（貢献を1文で示す）
• 想定される質問に備えた予備スライドを用意します

ステップ 8.3：ブログ記事／ソーシャルメディア

読みやすい要約は、インパクトを大きく高めます。

• Twitter/X のスレッド：5～8 件の投稿にします。手法ではなく、結果から始めます。図 1 と主要な結果を示す図を含めます。
• ブログ記事：800～1500 語にします。査読者ではなく、ML の実務者に向けて書きます。形式的な説明は省き、直感的な理解と実践的な意味合いを重視します。
• プロジェクトページ：要旨、図、デモ、コードへのリンク、BibTeX を含む HTML ページを作成します。GitHub Pages を使います。

タイミング：論文が会議録または arXiv のカメラレディ版に掲載されてから 1～2 日以内に投稿します。

---

ワークショップ論文とショートペーパー

ワークショップ論文やショートペーパー（ACL のショートペーパー、Findings 論文など）は、同じパイプラインに従いますが、制約や期待値が異なります。

ワークショップ論文

項目	ワークショップ	メインカンファレンス
ページ数の上限	4～6 ページ（通常）	7～9 ページ
査読基準	完全性に対する基準は比較的低い	完全かつ綿密であることが必須
査読プロセス	通常はシングルブラインドまたは簡易査読	ダブルブラインド、厳格
評価される内容	興味深いアイデア、予備的な結果、立場を示す論考	強力なベースラインを備えた、完全な実証的ストーリー
arXiv	いつでも投稿可能	タイミングが重要（arXiv 戦略を参照）
貢献の基準	新しい方向性、興味深い否定的結果、進行中の研究	強力な証拠に裏付けられた重要な進展

ワークショップを投稿先に選ぶケース：

• 完成版の論文にする前に、フィードバックを得たい初期段階のアイデア
• 8 ページ以上を割くほどではない否定的な結果
• 時宜を得たトピックに関する立場を示す論考や意見
• 再現研究または再現性に関する報告

ACL ショートペーパーと Findings

ACL の投稿先には、明確に異なる投稿種別があります。

種別	ページ数	期待される内容
ロングペーパー	8	完全な研究、強力なベースライン、アブレーション
ショートペーパー	4	焦点を絞った貢献：証拠を伴う、明確な論点を 1 つ
Findings	8	メインカンファレンスの採択にわずかに届かなかった、堅実な研究

ショートペーパーの戦略：主張を 1 つだけ選び、それを十分な証拠で裏付けます。ロングペーパーを 4 ページに圧縮しようとせず、より焦点を絞った別の論文を書きます。

---

実証的 ML 以外の論文種別

上記のメインパイプラインは、実証的な ML 論文を対象としています。それ以外の論文種別には、異なる構成と証拠基準が必要です。各種別の詳しい指針については、references/paper-types.md を参照してください。

理論論文

構成：序論 → 予備知識（定義、表記法）→ 主な結果（定理）→ 証明の概略 → 考察 → 完全な証明（付録）

実証論文との主な違い：

• 貢献は定理、境界、または不可能性の結果であり、実験数値ではありません。
• 方法のセクションは「予備知識」と「主な結果」に置き換わります。
• 証明が証拠となり、実験ではありません（ただし、理論の実証的検証は歓迎されます）。
• 本文に証明の概略を記載し、付録に完全な証明を載せるのが一般的です。
• 実験セクションは任意ですが、理論的な予測を検証する場合は論文を強化できます。

証明を書く際の原則：

• すべての仮定を明示したうえで、定理を形式的に述べます。
• 形式的な証明の前に、直感的な説明を加えます（「重要な洞察は……です」）。
• 証明の概略では、主なアイデアを 0.5～1 ページで伝えます。
• \begin{proof}...\end{proof} 環境を使います。
• 仮定に番号を付け、定理内で参照します。「仮定 1～3 のもとで、……」

サーベイ／チュートリアル論文

構成：序論 → 分類体系／構成 → 詳細な解説 → 未解決問題 → 結論

主な特徴：

• 貢献は、未解決問題の整理、統合、特定であり、新しい手法ではありません。
• 対象範囲内を網羅している必要があります（査読者は参考文献の欠落を確認します）。
• 明確な分類体系または構成の枠組みが必要です。
• 個々の論文では示されていない研究間のつながりに価値があります。
• 有力な投稿先：TMLR（サーベイ枠）、JMLR、Foundations and Trends in ML、ACM Computing Surveys

ベンチマーク論文

構成：序論 → タスクの定義 → データセットの構築 → ベースライン評価 → 分析 → 想定される用途と制限事項

主な違い：

• 貢献はベンチマークそのものです。実際に存在する評価上の空白を埋める必要があります
• データセットの文書化は任意ではなく必須です（データシート、ステップ 5.11 を参照）
• ベンチマークが難しいことを実証する必要があります（ベースラインでは性能が頭打ちにならないこと）
• ベンチマークが主張する対象を測定していること（構成概念妥当性）を実証する必要があります
• 最適な投稿先：NeurIPS Datasets & Benchmarks トラック、ACL（リソース論文）、LREC-COLING

ポジションペーパー

構成：序論 → 背景 → 主張／論点 → 裏付けとなる証拠 → 反論 → 含意

主な違い：

• 貢献は結果ではなく、論点です
• 反論に真剣に向き合う必要があります
• 証拠には、実証的分析、理論的分析、論理的分析を用いることができます
• 最適な投稿先：ICML（ポジショントラック）、ワークショップ、TMLR

---

Hermes エージェントとの連携

このスキルは Hermes エージェント向けに設計されています。研究の全ライフサイクルにわたり、Hermes のツール、委任、スケジューリング、メモリを活用します。

関連スキル

特定のフェーズでは、このスキルと他の Hermes スキルを組み合わせてください。

スキル	使用するタイミング	読み込み方法
arxiv	フェーズ 1（文献レビュー）：arXiv の検索、BibTeX の生成、Semantic Scholar による関連論文の検索	skill_view("arxiv")
subagent-driven-development	フェーズ 5（執筆）：2 段階のレビュー（仕様への準拠確認、その後に品質確認）を伴う並行セクション執筆	skill_view("subagent-driven-development")
plan	フェーズ 0（セットアップ）：実行前の構造化された計画の作成。.hermes/plans/ に書き込みます	skill_view("plan")
qmd	フェーズ 1（文献）：ハイブリッド BM25+ベクトル検索によるローカルナレッジベース（ノート、トランスクリプト、ドキュメント）の検索	インストール：skill_manage("install", "qmd")
diagramming	フェーズ 4～5：Excalidraw ベースの図やアーキテクチャ図の作成	skill_view("diagramming")
data-science	フェーズ 4（分析）：インタラクティブな分析と可視化のための Jupyter ライブカーネル	skill_view("data-science")

このスキルは ml-paper-writing に取って代わります。ml-paper-writing のすべての内容に加え、実験・分析の全パイプラインと autoreason の手法を含みます。

Hermes ツールリファレンス

ツール	このパイプラインでの用途
terminal	LaTeX のコンパイル（latexmk -pdf）、git 操作、実験の起動（nohup python run.py &）、プロセス確認
process	バックグラウンド実験の管理: process("start", ...)、process("poll", pid)、process("log", pid)、process("kill", pid)
execute_code	引用検証、統計分析、データ集計のために Python を実行します。RPC 経由でツールにアクセスできます。
read_file / write_file / patch	論文の編集、実験スクリプト、結果ファイル。大きな .tex ファイルへのピンポイント編集には patch を使用します。
web_search	文献の発見: web_search("transformer attention mechanism 2024")
web_extract	論文の内容の取得、引用の検証: web_extract("https://arxiv.org/abs/2303.17651")
delegate_task	セクションの並列ドラフト作成 — 各セクションごとに独立したサブエージェントを生成します。引用の並行検証にも使用します。
todo	セッションをまたぐ主要な状態トラッカー。フェーズが切り替わるたびに更新します。
memory	セッションをまたいで重要な決定を永続化します: 貢献の位置づけ、投稿先の選択、査読者からのフィードバック。
cronjob	実験の監視、締め切りのカウントダウン、arXiv の自動チェックをスケジュールします。
clarify	行き詰まったときにユーザーへ的を絞った質問をします（投稿先の選択、貢献の位置づけ）。
cron の deliver:	実験が完了したときやドラフトができたときに、ユーザーがチャットにいなくても通知します — チェックを cron ジョブとしてスケジュールし、メッセージングの deliver: ターゲットを指定します（エージェントには send_message ツールがなくなりました。送信の配信は cron/hermes send が処理します）。

ツールの使用パターン

実験の監視（最も一般的）:

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '<descriptive message>' && git push")
→ (final response auto-delivers "Experiment complete: <summary>"; for unattended runs, schedule via cron with a deliver: target)

セクションの並列ドラフト作成（委任を使用）:

delegate_task("Draft the Methods section based on these experiment scripts and configs. 
  Include: pseudocode, all hyperparameters, architectural details sufficient for 
  reproduction. Write in LaTeX using the neurips2025 template conventions.")

delegate_task("Draft the Related Work section. Use web_search and web_extract to 
  find papers. Verify every citation via Semantic Scholar. Group by methodology.")

delegate_task("Draft the Experiments section. Read all result files in results/. 
  State which claim each experiment supports. Include error bars and significance.")

各委任は共有コンテキストを持たない新しいサブエージェントとして実行されます — 必要な情報はすべてプロンプトに含めてください。出力を収集して統合します。

引用の検証（execute_code を使用）:

# In execute_code:
from semanticscholar import SemanticScholar
import requests

sch = SemanticScholar()
results = sch.search_paper("attention mechanism transformers", limit=5)
for paper in results:
    doi = paper.externalIds.get('DOI', 'N/A')
    if doi != 'N/A':
        bibtex = requests.get(f"https://doi.org/{doi}", 
                              headers={"Accept": "application/x-bibtex"}).text
        print(bibtex)

memory と todo による状態管理

memory ツール — 重要な決定を永続化します（上限: MEMORY.md で約 2200 文字）:

memory("add", "Paper: autoreason. Venue: NeurIPS 2025 (9 pages). 
  Contribution: structured refinement works when generation-evaluation gap is wide.
  Key results: Haiku 42/42, Sonnet 3/5, S4.6 constrained 2/3.
  Status: Phase 5 — drafting Methods section.")

主要な決定やフェーズの切り替えの後に memory を更新します。これはセッションをまたいで永続化されます。

todo ツール — 細かい進捗を追跡します:

todo("add", "Design constrained task experiments for Sonnet 4.6")
todo("add", "Run Haiku baseline comparison")
todo("add", "Draft Methods section")
todo("update", id=3, status="in_progress")
todo("update", id=1, status="completed")

セッション開始時のプロトコル:

1. todo("list")                           # Check current task list
2. memory("read")                         # Recall key decisions
3. terminal("git log --oneline -10")      # Check recent commits
4. terminal("ps aux | grep python")       # Check running experiments
5. terminal("ls results/ | tail -20")     # Check for new results
6. Report status to user, ask for direction

cronjob による Cron 監視

cronjob ツールを使用して、定期的な実験チェックをスケジュールします:

cronjob("create", {
  "schedule": "*/30 * * * *",  # Every 30 minutes
  "prompt": "Check experiment status:
    1. ps aux | grep run_experiment
    2. tail -30 logs/experiment_haiku.log
    3. ls results/haiku_baselines/
    4. If complete: read results, compute Borda scores, 
       git add -A && git commit -m 'Add Haiku results' && git push
    5. Report: table of results, key finding, next step
    6. If nothing changed: respond with [SILENT]"
})

[SILENT] プロトコル: 前回のチェックから何も変化がない場合は、正確に [SILENT] と応答します。これにより、ユーザーへの通知配信が抑制されます。知る価値のある本当の変化がある場合にのみ報告します。

締め切りの追跡:

cronjob("create", {
  "schedule": "0 9 * * *",  # Daily at 9am
  "prompt": "NeurIPS 2025 deadline: May 22. Today is {date}. 
    Days remaining: {compute}. 
    Check todo list — are we on track? 
    If <7 days: warn user about remaining tasks."
})

コミュニケーションパターン

ユーザーに通知すべきとき（直接の/最終応答、または無人実行の場合は cron の deliver: ターゲット経由）:

• 実験バッチが完了したとき（結果の表を添えて）
• 判断を要する予期しない発見や失敗
• ドラフトのセクションがレビュー可能になったとき
• 未完了のタスクを抱えたまま締め切りが近づいているとき

通知すべきでないとき:

• 実験がまだ実行中で、新しい結果がない → [SILENT]
• 変化のない定例の監視 → [SILENT]
• 注目を必要としない中間ステップ

レポート形式 — 常に構造化データを含めます:

## Experiment: <name>
Status: Complete / Running / Failed

| Task | Method A | Method B | Method C |
|------|---------|---------|---------|
| Task 1 | 85.2 | 82.1 | **89.4** |

Key finding: <one sentence>
Next step: <what happens next>

人間の入力が必要な判断ポイント

本当に行き詰まったときは、clarify を使って的を絞った質問をします:

判断	いつ尋ねるか
対象の投稿先	論文を書き始める前（ページ制限や位置づけに影響します）
貢献の位置づけ	複数の有効な位置づけが存在するとき
実験の優先順位	TODO リストの実験が時間的にこなせる数を超えているとき
投稿の準備状況	最終投稿の前

尋ねてはいけないこと（主体的に行動し、選択し、それを明示します）:

• 語句の選択、セクションの順序
• どの具体的な結果を強調するか
• 引用の完全性（見つけたものでドラフトを作成し、不足を記録します）

---

査読者の評価基準

査読者が何を重視するかを理解すると、取り組むべき点を絞りやすくなります。

基準	確認される内容
品質	技術的な妥当性、十分な裏付けのある主張、公正なベースライン
明確さ	明快な文章、専門家が再現できること、一貫した表記
重要性	コミュニティへの影響、理解の前進
独創性	新たな知見（新しい手法は必須ではありません）

スコア（NeurIPS 6 段階評価）：

• 6：強い採択 — 画期的で、欠点がありません
• 5：採択 — 技術的に堅実で、影響力が大きい
• 4：採択寄りのボーダーライン — 堅実ですが、評価が限定的です
• 3：不採択寄りのボーダーライン — 弱点が長所を上回ります
• 2：不採択 — 技術的な欠陥があります
• 1：強い不採択 — 既知の結果、または倫理上の問題があります

詳細なガイドライン、よくある懸念、反論戦略については、references/reviewer-guidelines.md を参照してください。

---

よくある問題と解決策

問題	解決策
要旨が一般的すぎる	どの ML 論文にも当てはまる冒頭文なら削除します。独自の貢献から始めます。
序論が 1.5 ページを超える	背景を関連研究に移します。貢献の箇条書きを前半に配置します。
実験で主張が明示されていない	各実験の前に「この実験では、［具体的な主張］かどうかを検証します……」と加えます。
査読者に論文が読みにくいと思われる	道しるべとなる表現を加え、用語を統一し、図のキャプションだけで内容が分かるようにします。
統計的有意性が不足している	誤差範囲、実行回数、統計検定、信頼区間を加えます。
実験の範囲が広がりすぎている	すべての実験を具体的な主張に対応させます。対応しない実験は削除します。
論文が不採択となり、再投稿が必要	フェーズ 7 の「学会への再投稿」を参照してください。査読への言及を避けつつ、懸念に対応します。
より広範な影響についての記述がない	ステップ 5.10 を参照してください。多くの投稿先で必須です。「悪影響はありません」という主張は、ほとんどの場合、説得力がありません。
人手による評価が不十分だと批判される	ステップ 2.5 と references/human-evaluation.md を参照してください。一致度指標、アノテーターの詳細、報酬を報告します。
査読者が再現性に疑問を持つ	コードを公開し（ステップ 7.9）、すべてのハイパーパラメーターを記載し、シード値と計算環境の詳細を含めます。
理論論文に直感的な説明がない	形式的な証明の前に、平易な説明を添えた証明の概略を加えます。references/paper-types.md を参照してください。
結果が否定的／帰無的	否定的な結果への対処については、フェーズ 4.3 を参照してください。ワークショップ、TMLR、または分析としての再構成を検討してください。

---

参考資料

ドキュメント	内容
references/writing-guide.md	Gopen & Swan の 7 原則、Perez の簡潔なヒント、Lipton の語句選び、Steinhardt の精密さ、図のデザイン
references/citation-workflow.md	引用 API、Python コード、CitationManager クラス、BibTeX の管理
references/checklists.md	NeurIPS の 16 項目、ICML、ICLR、ACL の要件、投稿前の包括的チェックリスト
references/reviewer-guidelines.md	評価基準、スコア、よくある懸念、反論テンプレート
references/sources.md	執筆ガイド、学会のガイドライン、API の全参考文献
references/experiment-patterns.md	実験設計のパターン、評価プロトコル、モニタリング、エラー復旧
references/autoreason-methodology.md	Autoreason ループ、戦略の選択、モデルガイド、プロンプト、スコープの制約、Borda スコアリング
references/human-evaluation.md	人手評価の設計、アノテーションガイドライン、一致度指標、クラウドソーシングの品質管理、IRB のガイダンス
references/paper-types.md	理論論文（証明の執筆、定理の構成）、サーベイ論文、ベンチマーク論文、ポジションペーパー

LaTeX テンプレート

templates/ にあるテンプレート：NeurIPS 2025、ICML 2026、ICLR 2026、ACL、AAAI 2026、COLM 2025。

コンパイル手順については、templates/README.md をご覧ください。

主な外部ソース

執筆の考え方：

• Neel Nanda：ML 論文の書き方
• Sebastian Farquhar：ML 論文の書き方
• Gopen & Swan：科学論文の書き方の科学
• Lipton：科学論文執筆のヒューリスティクス
• Perez：論文執筆を簡単にするヒント

API： Semantic Scholar | CrossRef | arXiv

投稿先： NeurIPS | ICML | ICLR | ACL