トップAI会議向けML論文執筆ガイド

NeurIPS、ICML、ICLR、ACL、AAAI、COLMを対象とした出版品質のペーパー執筆に関する専門家レベルのガイダンスです。このスキルは、トップ研究者（Nanda、Farquhar、Karpathy、Lipton、Steinhardt）の執筆哲学と実用的なツール（LaTeXテンプレート、引用検証API、会議チェックリスト）を組み合わせています。

システムズ分野の会議（OSDI、NSDI、ASPLOS、SOSP）の場合は、systems-paper-writingスキルを使用してください。このスキルは段落レベルの構造ブループリント、執筆パターン、会議固有のチェックリスト、およびシステムズ会議向けのLaTeXテンプレートを提供します。

コア哲学：協調的な執筆

論文執筆は協調的ですが、Claudeは草稿の提供において積極的である必要があります。

通常のワークフローは、コード、結果、実験成果物を含む研究リポジトリから始まります。Claudeの役割は以下の通りです：

1. プロジェクトを理解する - リポジトリ、結果、既存ドキュメントを調査する
2. 完全な初稿を提供する - 貢献内容について確信が持てる場合
3. 文献を検索する - ウェブ検索とAPIを使用して関連引用を検索する
4. フィードバックサイクルを通じて改善する - 科学者からの入力に基づいて
5. 明確化を求める - 主要な決定について真に不確実な場合のみ

重要な原則：積極的に行動してください。リポジトリと結果が明確であれば、完全な草稿を提供してください。各セクションのフィードバック待ちでブロックしないでください。科学者は忙しいです。具体的なものを作成して反応を待ち、その応答に基づいて反復してください。

---

⚠️ 重要：引用を絶対に捏造してはいけません

これはAI支援での学術的執筆における最も重要なルールです。

問題点

AI生成の引用には約40%のエラー率があります。捏造された参考文献（存在しないペーパー、著者名の誤り、年号の間違い、偽造DOI）は学術的不正の深刻な形態であり、デスク・リジェクションまたは取り下げをもたらす可能性があります。

ルール

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

アクション	✅ 正しい	❌ 間違い
引用を追加する	Search API → 検証 → BibTeXをフェッチ	メモリからBibTeXを作成する
ペーパーが不確実な場合	[CITATION NEEDED]とマークする	参考文献を推測する
正確なペーパーが見つからない	注記：「プレースホルダー - 検証必須」	似た名前のペーパーを発明する

引用を検証できない場合

引用をプログラム的に検証できない場合、以下を行う必要があります：

% 明示的なプレースホルダー - 人による検証が必要
\cite{PLACEHOLDER_author2024_verify_this}  % TODO: この引用が存在することを確認

科学者に常に伝えてください：「検証が必要な[X]個の引用をプレースホルダーとしてマークしました。これらのペーパーが存在することを確認できませんでした。」

推奨：論文検索用にExa MCPをインストール

最適な論文検索体験のために、リアルタイム学術検索を提供するExa MCPをインストールしてください：

Claude Code:

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

Cursor / VS Code（MCPの設定に追加）:

{
  "mcpServers": {
    "exa": {
      "type": "http",
      "url": "https://mcp.exa.ai/mcp"
    }
  }
}

Exa MCPで以下のような検索が可能になります：

• 「2023年以降に出版された言語モデルのRLHFに関する論文を探す」
• 「VaswaniによるTransformerアーキテクチャペーパーを検索」
• 「解釈可能性のためのスパースオートエンコーダに関する最近の研究」

その後、Semantic Scholar APIで結果を検証し、DOI経由でBibTeXをフェッチします。

---

ワークフロー0：研究リポジトリから開始する場合

論文執筆を開始する際は、プロジェクトを理解することから始めてください：

プロジェクト理解：
- [ ] ステップ1：リポジトリ構造を探索する
- [ ] ステップ2：README、既存ドキュメント、主要な結果を読む
- [ ] ステップ3：科学者と主要な貢献を特定する
- [ ] ステップ4：コードベースで既に引用されているペーパーを見つける
- [ ] ステップ5：追加の関連文献を検索する
- [ ] ステップ6：論文構造のアウトラインを一緒に作成する
- [ ] ステップ7：フィードバックを含めながらセクションを反復的に作成する

ステップ1：リポジトリを探索する

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

以下を探してください：

• README.md - プロジェクト概要と主張
• results/、outputs/、experiments/ - 主要な発見
• configs/ - 実験設定
• 既存の.bibファイルまたは引用参照
• ドラフトドキュメントまたはメモ

ステップ2：既存の引用を特定する

コードベースで既に参照されているペーパーを確認してください：

# 既存の引用を見つける
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find . -name "*.bib"

これらは関連作業の高シグナル開始点です。科学者はすでにそれらの関連性を認めています。

ステップ3：貢献を明確にする

執筆を開始する前に、科学者と明示的に確認してください：

「リポジトリの理解に基づいて、主要な貢献は[X]のようです。 主要な結果は[Y]を示しています。これがペーパーのフレーミングとして 望ましいですか、それとも異なる側面を強調すべきですか？」

決して人間に相談せずに物語を仮定しないでください。

ステップ4：追加の文献を検索する

ウェブ検索を使用して関連ペーパーを見つけます：

試す検索クエリ：
- 「[主要手法] + [応用領域]」
- 「[ベースライン手法]との比較」
- 「[問題名]最先端」
- 既存の引用の著者名

その後、引用ワークフロー（以下を参照）を使用して検証し、BibTeXを取得します。

ステップ5：最初の草稿を提供する

各セクションの許可を求めるのではなく、積極的に完全な草稿を提供してください。

リポジトリが明確な結果を提供し、貢献が明らかな場合：

1. 最初から最後まで完全な最初の草稿を執筆する
2. フィードバック用に完全な草稿を提示する
3. 科学者の応答に基づいて反復する

貢献のフレーミングや主要な主張について真に不確実な場合：

1. 確信を持って草稿できるものを草稿する
2. 具体的な不確実な点を明記する：「[X]を主要な貢献として枠付けしました。[Y]を代わりに強調することを望む場合は知らせてください」
3. ブロックするのではなく、草稿を継続する

草稿に含める質問（事前ではなく）:

• 「[X]を主要な貢献として強調しましたが、必要に応じて調整してください」
• 「結果A、B、Cを強調しましたが、他がより重要な場合は知らせてください」
• 「関連作業セクションに[ペーパー]が含まれています。見落とした他のペーパーがあれば追加してください」

---

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

このスキルを使用してください：

• 研究リポジトリから開始してペーパーを執筆する場合
• 特定のセクションを作成または修正する場合
• 関連作業の引用を見つけて検証する場合
• 会議提出用に書式設定する場合
• 別の会議に再提出する場合（書式変換）
• 科学者フィードバックで草稿を反復する場合

常に覚えておいてください：最初の草稿は議論の開始点であり、最終出力ではありません。

---

積極性と協調性のバランス

デフォルト：積極的に行動してください。草稿を提供してから反復してください。

信頼度	アクション
高 （明確なリポジトリ、明らかな貢献）	完全な草稿を執筆し、提供してからフィードバックで反復
中 （いくつかの曖昧さ）	不確実性をマークした草稿を執筆し、続行
低 （主要な不明な点）	1～2の的を絞った質問を尋ね、その後に草稿

事前ではなく、草稿と一緒に尋ねてください：

セクション	自律的に草稿	草稿と一緒にフラグを立てる
要約	はい	「貢献を[X]として枠付けしました。必要に応じて調整してください」
導入	はい	「問題[Y]を強調しました。間違っている場合は修正してください」
方法	はい	「詳細A、B、Cを含めました。不足しているものを追加してください」
実験	はい	「結果1、2、3をハイライトしました。必要に応じて順序を変えてください」
関連作業	はい	「論文X、Y、Zを引用しました。見落とした論文があれば追加してください」

入力をブロックするのは以下の場合のみ：

• 目標となる会議が不明確な場合（ページ数制限、フレーミングに影響）
• 複数の矛盾したフレーミングが同等に妥当である場合
• 結果が不完全または矛盾しているように見える場合
• 継続する前にレビューするための明示的な要求

以下についてはブロックしないでください：

• 単語選択の決定
• セクションの順序
• どの特定の結果を表示するか（選択を行い、フラグを立てる）
• 引用の完全性（見つけたもので草稿し、ギャップを注記する）

---

ナラティブ原則

最も重要な唯一の洞察：あなたのペーパーは実験の集合ではなく、証拠によって支援された1つの明確な貢献を備えた物語です。

成功したML論文のすべては、Neel Nandaが「ナラティブ」と呼ぶものを中心としています：短く、厳密で、証拠に基づいた技術的な物語であり、読者が関心を持つ結論です。

3本の柱（導入の終了までに明確である必要があります）:

柱	説明	例
「何」	1～3の凝集テーマ内の具体的な新規主張	「条件Zの下でXが結果Yを達成することを証明しました」
「なぜ」	主張を支持する厳密な実験的証拠	強力なベースライン、仮説を区別する実験
「だから何」	読者がなぜ関心を持つべきか	認識されたコミュニティの問題への接続

貢献を1つの文で述べることができない場合、あなたはまだペーパーを持っていません。

---

ペーパー構造ワークフロー

ワークフロー1：完全なペーパーの執筆（反復的）

このチェックリストをコピーして進捗を追跡してください。各ステップには草稿→フィードバック→改訂が含まれます：

論文執筆の進捗：
- [ ] ステップ1：1文の貢献を定義する（科学者と）
- [ ] ステップ2：図1を草稿→フィードバックを得る→改訂
- [ ] ステップ3：要約を草稿→フィードバックを得る→改訂
- [ ] ステップ4：導入を草稿→フィードバックを得る→改訂
- [ ] ステップ5：方法を草稿→フィードバックを得る→改訂
- [ ] ステップ6：実験を草稿→フィードバックを得る→改訂
- [ ] ステップ7：関連作業を草稿→フィードバックを得る→改訂
- [ ] ステップ8：制限事項を草稿→フィードバックを得る→改訂
- [ ] ステップ9：完全なペーパーチェックリスト（必須）
- [ ] ステップ10：最終レビューサイクルと提出

ステップ1：1文の貢献を定義する

このステップは科学者からの明示的な確認が必要です。

何かを執筆する前に、明確にして検証してください：

• あなたのペーパーが貢献する単一のものは何ですか？
• あなたの仕事の前に何が明らかでなかったか、または存在しなかったか？

「貢献を次のように枠付けすることを提案します：『[1文]』。これがあなたが 主要な結論と見なしているものを捉えていますか？強調を調整する必要がありますか？」

ステップ2：図1を草稿する

図1は特別な注意に値します。多くの読者は直接それにスキップします。

• コアアイデア、アプローチ、または最も説得力のある結果を伝える
• ベクターグラフィックス（プロット用のPDF/EPS）を使用
• スタンドアロンで理解できるキャプションを書く
• 白黒での可読性を確認する（男性の8%は色覚異常）

ステップ3：要約を執筆する（5文式）

Sebastian Farquhar（DeepMind）による：

1. 達成したことについて述べる：「私たちは...を導入します」、「...を証明します」、「...を実証します」
2. これが難しく重要な理由
3. どのように行うか（専門家用語を含めて発見可能性向上）
4. どのような証拠があるか
5. あなたの最も驚くべき数字/結果

削除する一般的な開口部、例えば「大規模言語モデルは驚くべき成功を達成しました...」

**ステップ4：導入を執筆する（最大1～1.5ページ）

含める必要があります：

• 2～4項目の貢献リスト（2列形式では各最大1～2行）
• 明確な問題ステートメント
• 簡潔なアプローチ概要
• 方法は最大ページ2～3で開始する必要があります

ステップ5：方法セクション

再実装を可能にする：

• 概念概要または疑似コード
• リストされたすべてのハイパーパラメータ
• 再現に十分なアーキテクチャ詳細
• 最終設計決定を提示する（アブレーションは実験に）

ステップ6：実験セクション

各実験について、明示的に述べる：

• どの主張をサポートするか
• 主要貢献との関連付け
• 実験設定（詳細は付録）
• 観察すべきこと：「青い線は[X]を示し、[Y]を実証します」

要件：

• エラーバーと方法論（標準偏差 vs 標準誤差）
• ハイパーパラメータ検索範囲
• コンピュート基盤（GPUタイプ、合計時間）
• シード設定方法

ステップ7：関連作業

方法論的に編成する（論文ごとではなく）：

良い例： 「1つの研究ラインはFloogledoodleの仮定[参考]を使用しますが、私たちはDoobersnoddleの仮定を使用します。なぜなら...」

悪い例： 「Snap et al.は[X]を導入し、Crackle et al.は[Y]を導入しました。」

気前よく引用してください。レビュアーは関連ペーパーの著者である可能性があります。

ステップ8：制限事項セクション（必須）

すべての主要会議がこれを要件としています。逆説的に、正直さは役に立ちます：

• レビュアーは正直な制限事項の認識を罰しないよう指示されています
• 批判を事前に特定して弱点を認識する
• 制限事項がコア主張を損なわない理由を説明する

ステップ9：ペーパーチェックリスト

NeurIPS、ICML、ILCRはすべてペーパーチェックリストを要件としています。references/checklists.mdを参照してください。

---

トップMLカンファレンス向けの執筆哲学

このセクションは、トップMLに発表している研究者の最も重要な執筆原則を蒸留します。 これらはオプションのスタイル提案ではなく、受け入れられたペーパーと却下されたペーパーを区別するものです。

「ペーパーは短く、厳密で、証拠に基づいた技術的な物語であり、読者が関心を持つ結論です。」 — Neel Nanda

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

このスキルは、トップベニューで広く発表している研究者の執筆哲学を統合します：

ソース	主要な貢献	リンク
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 - 完全な参考文献

時間配分（Neel Nandaから）

以下の各項目に大体同じ時間を費やしてください：

1. 要約
2. 導入
3. 図
4. その他すべてを合わせたもの

理由は何ですか？ ほとんどのレビュアーは方法に到達する前に判断を下します。読者はペーパーに次のように遭遇します：タイトル→要約→導入→図→もしかしたら残り。

執筆スタイルガイドライン

文レベルの明確さ（Gopen & Swanの7原則）

これらの原則は、読者が実際に散文をどのように処理するかに基づいています。それらに違反すると、読者はコンテンツではなく構造に認知努力を費やすことになります。

原則	ルール	例
主語と動詞の近接	主語と動詞を近く保つ	❌ 「...で訓練されたモデルは...を達成します」 → ✅ 「モデルは...を達成します...で訓練後」
ストレスポジション	文末に強調を配置	❌ 「注意を使用すると精度が15%向上します」 → ✅ 「注意を使用すると、精度が**15%**向上します」
トピックポジション	文脈を最初に、新情報を後に	✅ 「これらの制約が与えられた場合、私たちは提案します...」
古い前に新しい	馴染みのある情報→未知の情報	後ろにリンクしてから新しい情報を導入
1ユニット、1機能	各段落は1つのポイントを作成	複数ポイント段落を分割
動詞の中のアクション	動詞を使用し、名詞化しない	❌ 「分析を実行しました」 → ✅ 「分析しました」
コンテキスト前に新規	ステージを設定して表示	方程式を説明してから表示

詳細な7原則と詳細な例： references/writing-guide.mdを参照してください

マイクロレベルのヒント（Ethan Perez）

これらの小さな変更は有意に明確な散文に蓄積されます：

• 代名詞を最小化する：❌ 「これは...を示します」 → ✅ 「この結果は...を示します」
• 動詞を早期に配置する：動詞を文の開始近くに配置
• アポストロフィを展開する：❌ 「[X]の[Y]」 → ✅ 「[X]の[Y]」（不格好な場合）
• フィラーワードを削除する：「実際に」、「少し」、「非常に」、「本当に」、「基本的に」、「かなり」、「本質的に」

詳細なマイクロヒントと例： references/writing-guide.mdを参照してください

単語選択（Zachary Lipton）

• 具体的である：❌ 「パフォーマンス」 → ✅ 「精度」または「レイテンシ」（意図を明確にする）
• ヘッジを除去する：真に不確実な場合を除き、「かもしれない」と「できる」を削除
• 段階的な語彙を避ける：❌ 「組み合わせる」、「変更する」、「拡大する」 → ✅ 「開発する」、「提案する」、「導入する」
• インテンシファイアを削除する：❌ 「非常に厳密な近似を提供します」 → ✅ 「厳密な近似を提供します」

簡潔さより精度（Jacob Steinhardt）

• 一貫した用語：同じコンセプトに異なる用語を使用するとconfusionが生じます。1つを選択して固定してください。
• 仮説を形式的に述べる：定理の前に、すべての仮定を明示的にリストする
• 直感+厳密さ：形式的な証明と一緒に直感的な説明を提供

レビュアーが実際に読むもの

レビュアーの行動を理解するとフォーカスを優先順位付けするのに役立ちます：

ペーパーセクション	レビュアーが読む%	含義
要約	100%	完璧である必要があります
導入	90%+（スキム）	貢献を前面に
図	方法の前に検査	図1は重要
方法	興味がある場合のみ	鉛を埋めないでください
付録	稀に	補足詳細のみ

結論：要約と導入がレビュアーをフックしなければ、彼らは素晴らしい方法セクションを読まないかもしれません。

---

会議要件クイックリファレンス

ML/AI会議

会議	ページ制限	カメラレディの追加	主要要件
NeurIPS 2025	9ページ	+0	必須チェックリスト、受け入れ時の一般向けまとめ
ICML 2026	8ページ	+1	より広い影響ステートメント必須
ICLR 2026	9ページ	+1	LLM開示必須、相互レビュー
ACL 2025	8ページ（長）	varies	制限事項セクション必須
AAAI 2026	7ページ	+1	厳格なスタイルファイル準拠
COLM 2025	9ページ	+1	言語モデルに焦点

システムズ会議（OSDI、NSDI、ASPLOS、SOSP）: systems-paper-writingスキルでページ制限、テンプレート、締め切り、提出規則を参照してください。

普遍的な要件：

• ダブルブラインドレビュー（提出を匿名化）
• 参考文献はページ制限にカウントされない
• 付録は無制限だがレビュアーは読む必要はない
• すべての会議にはLaTeXが必須

LaTeXテンプレート： すべての会議テンプレートについてはtemplates/ディレクトリを参照してください。

---

LaTeXテンプレートを正しく使用する

ワークフロー4：テンプレートから新しいペーパーを開始する

常にディレクトリ全体をコピーしてから、その中で執筆してください。

テンプレートセットアップチェックリスト：
- [ ] ステップ1：新しいプロジェクトにディレクトリ全体をコピー
- [ ] ステップ2：テンプレートが変更前にコンパイルすることを確認
- [ ] ステップ3：テンプレートの例を読んで構造を理解
- [ ] ステップ4：例のコンテンツをセクション単位で置き換える
- [ ] ステップ5：完了まで参照としてテンプレートコメント/例を保持
- [ ] ステップ6：最後にテンプレートアーティファクトをクリーンアップ

ステップ1：完全なテンプレートをコピー

# 完全なテンプレートで論文ディレクトリを作成
cp -r templates/neurips2025/ ~/papers/my-new-paper/
cd ~/papers/my-new-paper/

# 構造が完全であることを確認
ls -la
# 以下が見えるはず：main.tex、neurips.sty、Makefile等

⚠️ 重要：ディレクトリ全体をコピーします。main.texだけではありません。テンプレートには以下が含まれます：

• スタイルファイル（.sty） - コンパイルに必須
• 参考文献スタイル（.bst） - 参考文献に必須
• 例のコンテンツ - 参考として有用
• Makefile - 簡単なコンパイル用

ステップ2：最初にテンプレートがコンパイルすることを確認

変更する前に、テンプレートをそのままコンパイル：

# latexmkを使用（推奨）
latexmk -pdf main.tex

# または手動コンパイル
pdflatex main.tex
bibtex main
pdflatex main.tex
pdflatex main.tex

未変更のテンプレートがコンパイルしない場合、最初にそれを修正してください。一般的な問題：

• TeX パッケージがない → tlmgr install <package>でインストール
• TeX ディストリビューションが間違っている → TeX Live（推奨）を使用

ステップ3：テンプレートコンテンツを参考として保持

すべての例のコンテンツをすぐに削除しないでください。代わりに：

% テンプレートの例をコメントアウトして参照として保持
% これにより、予想される形式が表示されます

% テンプレートの例（参照用に保持）：
% \begin{figure}[t]
%   \centering
%   \includegraphics[width=0.8\linewidth]{example-image}
%   \caption{テンプレートはキャプションスタイルを示します}
% \end{figure}

% あなたの実際の図：
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{同じスタイルに従うあなたのキャプション。}
\end{figure}

ステップ4：セクション単位でコンテンツを置き換える

論文を体系的に進めます：

置き換え順序：
1. タイトルと著者（提出時に匿名化）
2. 要約
3. 導入
4. 方法
5. 実験
6. 関連作業
7. 結論
8. 参考文献（.bibファイル）
9. 付録

各セクションについて：

1. テンプレートの例のコンテンツを読む
2. 使用されている特別な書式やマクロに注意
3. 同じパターンに従いながらコンテンツを置き換える
4. 早期にエラーをキャッチするために頻繁にコンパイル

ステップ5：テンプレートマクロを使用

テンプレートはしばしば有用なマクロを定義します。プリアンブルをチェック：

% 使用する一般的なテンプレートマクロ：
\newcommand{\method}{YourMethodName}  % 方法名の一貫性
\newcommand{\eg}{e.g.,\xspace}        % 適切な略語
\newcommand{\ie}{i.e.,\xspace}
\newcommand{\etal}{\textit{et al.}\xspace}

ステップ6：完了時にのみクリーンアップ

ペーパーがほぼ完成したときにのみテンプレートアーティファクトを削除：

% 提出前に削除：
% - コメント化されたテンプレート例
% - 未使用パッケージ
% - テンプレートの例の図/表
% - Lorem ipsumまたはプレースホルダーテキスト

% 保持：
% - すべてのスタイルファイル（.sty）
% - 参考文献スタイル（.bst）
% - テンプレートからの必須パッケージ
% - 使用しているカスタムマクロ

テンプレートの落とし穴を避ける

落とし穴	問題	解決策
main.texのみをコピー	.styがない、コンパイルしない	ディレクトリ全体をコピー
.styファイルを変更	会議の書式が破損	スタイルファイルを編集しない
ランダムパッケージを追加	競合、テンプレート破損	必要な場合のみ追加
早期にテンプレートコンテンツを削除	書式設定参照を失う	完了まで参照としてコメントを保持
頻繁にコンパイルしない	エラーが蓄積	各セクション後にコンパイル

クイックテンプレートリファレンス

ML/AI会議

会議	メインファイル	主要スタイルファイル	メモ
NeurIPS 2025	main.tex	neurips.sty	Makefile有り
ICML 2026	example_paper.tex	icml2026.sty	アルゴリズムパッケージ含む
ICLR 2026	iclr2026_conference.tex	iclr2026_conference.sty	math_commands.tex有り
ACL	acl_latex.tex	acl.sty	厳格な書式
AAAI 2026	aaai2026-unified-template.tex	aaai2026.sty	非常に厳格な準拠
COLM 2025	colm2025_conference.tex	colm2025_conference.sty	ILCRと同様

システムズ会議テンプレート（OSDI、NSDI、ASPLOS、SOSP）：systems-paper-writingスキルを参照してください。

---

会議の再提出と形式変換

ペーパーが1つの会議から却下または取り下げられた場合、別の会議に再提出される場合、形式変換が必要です。これはML研究の一般的なワークフローです。

ワークフロー3：会議形式間の変換

形式変換チェックリスト：
- [ ] ステップ1：ソースとターゲットテンプレートの違いを特定
- [ ] ステップ2：ターゲットテンプレートで新しいプロジェクトを作成
- [ ] ステップ3：コンテンツセクション（プリアンブルではなく）をコピー
- [ ] ステップ4：ページ制限とコンテンツを調整
- [ ] ステップ5：会議固有の要件を更新
- [ ] ステップ6：コンパイルと書式設定を確認

ステップ1：主要なテンプレート違いを特定

ML/AI変換

変換	ページ変更	主要な調整
NeurIPS → ICML	9 → 8ページ	1ページをカットし、見落とされた場合は広い影響を追加
ICML → ICLR	8 → 9ページ	実験を拡張でき、LLM開示を追加
NeurIPS → ACL	9 → 8ページ	NLPコンベンションで再構成し、制限事項を追加
ICLR → AAAI	9 → 7ページ	大幅なカットが必要、厳格なスタイル準拠
Any → COLM	varies → 9	言語モデルフォーカスで再フレーミング

ML → システムズ変換：OSDI、NSDI、ASPLOS、SOSPに変換する場合、systems-paper-writingスキルで形式変換ガイダンス、テンプレート、構造的違いを参照してください。

ステップ2：コンテンツマイグレーション（テンプレートマージではなく）

テンプレート間でLaTeXプリアンブルをコピーしないでください。 代わりに：

# 1. ターゲットテンプレートで新規に開始
cp -r templates/icml2026/ new_submission/

# 2. 古いペーパーからコンテンツセクションのみをコピー
# - 要約テキスト
# - セクションコンテンツ（\section{}コマンド間）
# - 図と表
# - 参考文献項目

# 3. ターゲットテンプレート構造に貼り付け

ステップ3：ページ制限に調整

ページをカットするとき（例：NeurIPS 9 → AAAI 7）：

• 詳細な証明を付録に移動
• 関連作業を凝縮（個々のペーパーではなく調査を引用）
• 同様の実験を統一されたテーブルに統合
• より小さい図サイズを使用（サブ図を使用）
• 執筆をきつくする：冗長性を除去、能動態を使用

ページを拡張するとき（例：ICML 8 → ICLR 9）：

• レビュアーが要求したアブレーション研究を追加
• 制限事項の議論を拡張
• 追加ベースラインを含める
• 定性的な例を追加

ステップ4：会議固有の調整

ML/AIベニュー

ターゲットベニュー	必須の追加
ICML	より広い影響に関する声明（結論の後）
ICLR	LLM利用開示、相互レビュー合意
ACL/EMNLP	制限事項セクション（必須）、倫理声明
AAAI	スタイルファイルへの厳格な準拠（変更なし）
NeurIPS	ペーパーチェックリスト（付録）、受け入れ時の一般向けまとめ

システムズベニュー（OSDI、NSDI、ASPLOS、SOSP）：systems-paper-writingスキルでベニュー固有の要件、チェックリスト、レビュアーガイドラインを参照してください。

ステップ5：参考文献を更新

% アイデンティティを明かす自己引用を削除（ブラインドレビュー用）
% 「査読中」の引用を公開版に更新
% 最後の提出以降に出版された新しい関連作業を追加

ステップ6：以前のレビューに対応

却下後に再提出するときは：

• してくださいレビュアーの懸念に対応します
• してくださいレビュアーが要求した実験/明確化を追加
• しないでください「前回の提出からの変更」セクション（ブラインドレビュー）を含める
• しないでください前回の提出またはレビューを参照

一般的な変換の落とし穴：

• ❌ \usepackageコマンドをコピー（競合を引き起こす）
• ❌ 古い会議のヘッダー/フッターコマンドを保持
• ❌ \bibliography{}パスを更新し忘れる
• ❌ 会議固有の必須セクションを見落とす
• ❌ 形式変更後にページ制限を超える

---

引用ワークフロー（幻覚防止）

⚠️ 重要：AI生成の引用には約40%のエラー率があります。決してメモリからBibTeXを書かないでください。

黄金律

プログラム的に引用をフェッチできない場合：
    → [CITATION NEEDED]または[PLACEHOLDER - VERIFY]とマークする
    → 科学者に明示的に伝える
    → 決して信じられているような参考文献を発明しない

ワークフロー2：引用を追加

引用検証（すべての引用に必須）：
- [ ] ステップ1：Exa MCPまたはSemantic Scholar APIを使用して検索
- [ ] ステップ2：2つ以上のソースでペーパーの存在を確認（Semantic Scholar + arXiv/CrossRef）
- [ ] ステップ3：BibTeXをDOI経由で取得（プログラム的に、メモリから取得ではなく）
- [ ] ステップ4：引用している主張が実際にペーパーに表示されることを確認
- [ ] ステップ5：検証済みBibTeXを参考文献に追加
- [ ] ステップ6：ステップが失敗した場合→プレースホルダーとしてマークし、科学者に通知

ステップ0：初期検索にExa MCPを使用（推奨）

Exa MCPがインストール済みの場合は、これを使用して関連ペーパーを見つけます：

検索：「RLHF言語モデルの配列 2023」
検索：「スパースオートエンコーダの解釈可能性」
検索：「Vaswaniアテンションメカニズムトランスフォーマー」

その後、各結果をSemantic Scholarで検証し、DOI経由でBibTeXをフェッチします。

ステップ1：Semantic Scholarで検索

from semanticscholar import SemanticScholar

sch = SemanticScholar()
results = sch.search_paper("attention mechanism transformers", limit=5)
for paper in results:
    print(f"{paper.title} - {paper.paperId}")
    print(f"  DOI: {paper.externalIds.get('DOI', 'N/A')}")

ステップ2：存在を確認

ペーパーが最低2つのソース（Semantic Scholar + CrossRef/arXiv）に表示されることを確認してください。

ステップ3：DOI経由でBibTeXを取得

import requests

def doi_to_bibtex(doi: str) -> str:
    """CrossRef経由のDOIから検証済みBibTeXを取得します。"""
    response = requests.get(
        f"https://doi.org/{doi}",
        headers={"Accept": "application/x-bibtex"}
    )
    response.raise_for_status()
    return response.text

# 例
bibtex = doi_to_bibtex("10.48550/arXiv.1706.03762")
print(bibtex)

ステップ4：主張を確認

特定の主張について引用する前に、ペーパーにアクセスして、属性化された主張が実際に表示されることを確認してください。

ステップ5：失敗を明示的に処理

引用をステップで検証できない場合：

% オプション1：明示的なプレースホルダー
\cite{PLACEHOLDER_smith2023_verify}  % TODO: 検証できない - 科学者が確認する必要があります

% オプション2：テキストのメモ
...前の作業で示されているように[CITATION NEEDED - Smith et al. 2023を検証できませんでした]。

科学者に常に通知してください：

「次の引用を検証できず、プレースホルダーとしてマークしました：

• 報酬ハッキングに関するSmith et al. 2023 - Semantic Scholarで見つかりませんでした
• スケーリング法則に関するJones 2022 - 似た論文を見つけましたが異なる著者です 提出前にこれらを確認してください。」

概要：引用ルール

状況	アクション
ペーパーを見つけた、DOIを取得した、BibTeXをフェッチした	✅ 引用を使用
ペーパーを見つけた、DOIなし	✅ arXiv BibTeXを使用またはペーパーから手動で入力
ペーパーが存在するがBibTeXをフェッチできない	⚠️ プレースホルダーをマークし、科学者に通知
ペーパーが存在するかどうか不確実	❌ [CITATION NEEDED]とマークし、科学者に通知
「[X]についてのペーパーがあると思う」	❌ 決して引用しない - まず検索するか、プレースホルダーをマーク

完全なAPI ドキュメント： references/citation-workflow.mdを参照してください。

---

一般的な問題と解決策

問題：要約が一般的すぎる

最初の文が任意のML論文の前に置ける場合は削除してください。特定の貢献から始まります。

問題：導入が1.5ページを超える

背景を関連作業に分割します。貢献の箇条書きを前面に配置します。方法はページ2～3で開始する必要があります。

問題：実験が明確な主張を欠く

各実験の前にセンテンスを追加：「この実験は[特定の主張]かどうかをテストします...」

問題：レビュアーがペーパーを理解しづらい

• 明示的なシグンポスティングを追加：「このセクションでは、[X]を示します」
• 全体で一貫した用語を使用
• 図のキャプションがスタンドアロンで理解できることを含める

問題：統計的有意性がない

常に以下を含めます：

• エラーバー（指定：標準偏差または標準誤差）
• 実行回数
• 方法を比較する統計テスト

---

レビュアー評価基準

レビュアーは4つの側面でペーパーを評価します：

基準	レビュアーが探すもの
品質	技術的には健全で、主張がよく支持されている
明確さ	明確な執筆、専門家による再現可能
有意性	コミュニティへの影響、理解を進める
独創性	新しい洞察（新しい方法を必要としません）

スコアリング（NeurIPS 6点スケール）:

• 6：強く受け入れる - 革新的で完全
• 5：受け入れる - 技術的に堅い、高い影響
• 4：境界線の受け入れ - 堅い、限定的な評価
• 3：境界線の却下 - 堅いが弱点が上回る
• 2：却下 - 技術的欠陥
• 1：強く却下 - 既知の結果または倫理問題

詳細なレビュアー指示については、references/reviewer-guidelines.mdを参照してください。

---

表と図

表

プロフェッショナルな表のためにLaTeXのbooktabsパッケージを使用：

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
方法 & 精度 ↑ & レイテンシ ↓ \\
\midrule
ベースライン & 85.2 & 45ms \\
\textbf{私たちの} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

ルール：

• 最高値をメトリックあたり太字にする
• 方向シンボルを含める（↑ 高い方が良い、↓ 低い方が良い）
• 数値列を右揃え
• 一貫した小数精度

図

• ベクターグラフィックス（PDF、EPS）すべてのプロットと図
• ラスター（PNG 600 DPI）写真のみ
• 色覚異常セーフなパレットを使用（Okabe-ItoまたはPaul Tol）
• グレースケール読み取り可能性を確認（男性の8%は色覚異常）
• 図内にタイトルなし。キャプションがこの機能を果たします
• スタンドアロンキャプション。読者はメインテキストなしで理解する必要があります

---

AI研究スキルを引用

このライブラリが研究に役立った場合（トレーニングパイプライン、評価、論文執筆、またはその他のスキル）、謝辞または参考文献で引用することを検討してください：

@software{ai_research_skills,
  title     = {AI Research Skills Library},
  author    = {{Orchestra Research}},
  year      = {2025},
  url       = {https://github.com/orchestra-research/AI-research-SKILLs},
  note      = {AI エージェントがAI研究を自律的に実施できるオープンソーススキルライブラリ}
}

謝辞セクションの簡潔な言及も歓迎します：

\section*{謝辞}
我々は[実験オーケストレーション/評価/...]にAI Research Skills Library~\cite{ai_research_skills}を使用しました。

---

参考資料とリソース

参考ドキュメント（詳細説明）

ドキュメント	内容
writing-guide.md	Gopen & Swan 7原則、Ethan Perezマイクロヒント、単語選択
citation-workflow.md	引用API、Pythonコード、BibTeX管理
checklists.md	NeurIPS 16項目、ICML、ICLR、ACL要件
reviewer-guidelines.md	評価基準、スコアリング、反論
sources.md	す