method-section-writer について
研究論文の明確で再現可能な手法セクションを作成するライティングスキルです。新規の貢献と標準的な要素を区別し、査読に必要な形式的な詳しさを調整します。
主な機能
- 01中核要素と依存関係の分析
- 02数式の前に記号を定義
- 03手法セクションの構成案
- 04形式化の前に直感を説明
- 05アルゴリズムと図の指針
- 06詳細度と付録内容の調整
活用シーン
- 01研究論文の手法セクションの草稿作成
- 02どの要素が新規かの整理
- 03本文だけで再現できるかの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ jurgendn/ agent-skills --skill method-section-writerインストール後、Claude Code で/method-section-writerを入力して読み込まれたか確認します。
詳細
Method Section Writer
メソッドセクションの役割はひとつです。主張されている結果が妥当かどうかを評価し、原理的には研究を再現できるだけの理解を読者に与えることです。
完全な実装ガイドではありません。また、その手法が基盤としているすべての要素を解説するチュートリアルでもありません。何が新しく、なぜうまくいくはずなのかを理解するために必要な、最小限の形式的な説明です。
2つの失敗パターン
詰め込みすぎ:記法を一度に大量に導入し、複数のサブコンポーネントを同じ抽象度で示し、動機づけのない数式を並べることです。読者は各行を追えても、要点をつかめません。
曖昧すぎ:手法が何をするかを説明するだけで、どのように行うかを示さないことです。「入力をコンテキスト表現でエンコードする」は手法ではなく、出力の説明にすぎません。読者はそれを再現できず、新規性があるかどうかも評価できません。
目標:懐疑的な査読者が、貢献に実質があるかを確認できるだけの精度で、重要なアイデアを提示することです。
ワークフロー
1. 手法の中核となるコンポーネントを特定する
執筆前に、以下を列挙します。
- この手法で本当に新しいものは何ですか?
- 標準的なもので、説明する代わりに引用できるものは何ですか?
- サブコンポーネントには何がありますか?主張の中核となるものと、エンジニアリング上の選択肢はそれぞれどれですか?
依存関係ツリーを書きます。どのコンポーネントを理解してからでないと、ほかのコンポーネントを理解できないでしょうか?このツリーがセクションの構成になります。
**中核となるコンポーネントに最も多くの紙幅を割きます。**それ以外は、標準的なものであれば引用し、エンジニアリング上の選択肢であれば簡潔に説明します。
2. 数式の前に記法を設定する
記法の誤りは、査読者から最もよく指摘される問題のひとつです。記法は、セクションの早い段階で、使用する数式より前にまとめて導入します。
各記号について、以下を明記します。
- 何を表すか。
- 型と形状(スカラー、ベクトル、行列、集合、関数)。
- 自明でない場合は、その値域または定義域。
Let G = (V, E) be a graph with node set V (|V| = n) and edge set E ⊆ V × V.
Each node v ∈ V has a feature vector x_v ∈ ℝ^d.
We denote the adjacency matrix as A ∈ {0,1}^{n×n} and the degree matrix as D.
ルール:
- 論文全体を通じて、同じ概念には同じ記号を使います。
- 添字を一貫して使います(時間インデックス、層インデックス、バッチインデックスなど。添字の位置ごとに規則をひとつ選びます)。
- ベクトルと行列には太字、スカラーにはイタリック体を使います。または、規則を明示します。
- 図のキャプションで、本文に登場する前の記号を導入してはいけません。
3. セクションを構成する
深層学習論文のメソッドセクションは、通常、次の構成になります。
3. Method
3.1 Problem formulation ← define input, output, and objective
3.2 [Core component name] ← the main novel contribution
3.3 [Secondary component] ← only if needed for the claim
3.4 Training objective ← loss function, optimization details
3.5 Complexity (optional) ← only if runtime is part of the contribution
論文の種類に応じて調整します。
- 理論論文:問題 → 定式化 → 主定理の記述 → 証明の概略 → 系。
- システム論文:問題 → アーキテクチャの概要 → コンポーネントの設計 → 実装の詳細 → 分析。
- データセット/ベンチマーク論文:タスクの定義 → データ収集 → アノテーションプロトコル → 品質管理 → 統計。
より具体的なサブタイトルを付けずに、「概要」や「アプローチ」という名前のセクションを設けるのは避けます。こうした見出しは、著者がセクションの役割を決められていないことを示唆します。
4. 完全な定式化の前に重要なアイデアを示す
まず直感的な説明を述べ、その後で形式化します。直感を理解した査読者は、数式も追いやすくなります。
各サブコンポーネントは、次の順に構成します。
- 動機:なぜこのコンポーネントが必要なのですか?より単純な代替手段では解決できない、どのような問題を解決しますか?
- 直感:言葉で説明すると、どのようなアイデアですか?
- 形式化:数式またはアルゴリズム。
- 解釈:形式化の内容を言葉で説明します。重要な項を示します。
例:
Adaptive walk length. Fixed walk-length methods treat all graphs uniformly,
ignoring that mixing time varies with graph density. We select the walk length
proportional to the inverse spectral gap, which captures how quickly information
spreads across the graph.
Formally, given graph G with normalized Laplacian eigenvalues 0 = λ_1 ≤ λ_2 ≤ ... ≤ λ_n,
we define the adaptive walk length as:
t* = ⌈1 / λ_2⌉ (1)
where λ_2 is the Fiedler value. Intuitively, small λ_2 (slow mixing) requires
longer walks to capture community structure; large λ_2 (fast mixing) allows
shorter walks without information loss.
5. アルゴリズムボックス
次の場合は、アルゴリズムボックスを使用します。
- 手法が、明確な手順に沿って進む手続き的なものです。
- 論文が、学習手順または推論アルゴリズムを扱っています。
- 正しさを評価するために、査読者が擬似コードを確認する必要があります。
次の場合は、アルゴリズムボックスを使用しません。
- 手法が単一の式です。
- 手順が、わずかな変更を加えた標準的な学習ループです。
アルゴリズムボックスの規則:
- アルゴリズムに名前を付けます。
- 入力と出力を明示します。
- 行に番号を付けます。
- ボックス内の変数名を、本文中の変数名と一致させます。
- 10~15行に収めます。それより長くなる場合は、サブルーチンを付録に移します。
6. 手法セクションの図
手法の図(アーキテクチャ図、パイプラインの可視化)は、通常、論文で最もよく見られる図です。次の点に留意してください。
- データの流れを最初から最後まで示します。
- 本文と同じ変数名を使います。
- 掲載される段幅で読みやすくします。
- 構造を理解するために、キャプションを読む必要がないようにします。
ほとんどの場合、手法の図は2つより1つのほうが適切です。複数の図が必要な場合は、それぞれ異なる要素を示すようにします。同じものを異なる視点から示す図にしないでください。
7. 付録に含める内容
次の内容は付録に移します。
- 証明全体(定理は本文に記載し、証明は後に回します)。
- ハイパーパラメータの表。
- 中核となる手法に影響しない実装の詳細(フレームワークのバージョン、GPU の種類)。
- 詳細な導出。
- 主要なアブレーションの範囲を超える失敗事例と感度分析。
- 実験を理解するのに必要な範囲を超えるデータセットの詳細。
次の内容は付録に移してはいけません。
- 損失関数の定義。
- 記法の表(長い場合は付録に記載してもかまいませんが、本文の早い段階で参照してください)。
- 主な結果が依存する要素。
8. 詳細度の調整
各要素について、次のように問いかけます。「読者は本文だけからこれを実装できるでしょうか?」
中核となる貢献について答えが「いいえ」の場合は、詳細を追加します。 標準的な要素(例:マルチヘッドアテンション)について答えが「はい」の場合は、詳細が多すぎます。代わりに、元の論文を引用してください。
適切な確認方法:数式を隠して、文章だけを読んでみます。読者は手法の内容と、その理由を理解できるでしょうか。できる場合は、文章が役割を果たしています。できない場合は、文章が数式のキャプションになっているだけです。
9. 学習目的関数
損失関数と最適化の設定には、最低限、次の情報が必要です。
- 完全な記法による損失関数(「クロスエントロピー損失」とだけ書かず、式を記載するか、定式化を引用してください)。
- 目的関数がエンドツーエンドなのか、独立した学習段階があるのか。
- 正則化項とそのハイパーパラメータ名(値を実験セクションに記載する場合も含みます)。
- オプティマイザーの名前と主要なハイパーパラメータ(学習率スケジュール、重み減衰)。
損失関数が標準的でない場合、または損失関数自体が貢献となる場合は、独立した小節を設けます。
よくある査読者の指摘とその予防方法
| 指摘 | 根本原因 | 対応 |
|---|---|---|
| 「記法に一貫性がない」 | 記号の使い回し、または未定義の記号 | セクションの冒頭に記法の表を置きます |
| 「先行研究と何が違うのか分からない」 | 新規性を明示する指標がない | 「[X]とは異なり、提案手法では……」または「主な違いは……」を加えます |
| 「手法の説明が不十分だ」 | 自明でない手順に数式を用いず、文章だけで説明している | 新しい各要素に形式的な定義を加えます |
| 「手法の説明が細かすぎる」 | 標準的な要素について、実装の詳細を手順ごとに説明している | 引用して参照し、導出を繰り返さないようにします |
| 「なぜこれが機能するのか分からない」 | 直感的な説明がない | 各数式の前に、動機を説明する文を1つ加えます |
| 「図が本文と一致していない」 | 本文と図で変数が異なる | 両方の記号をすべて確認します |
出力形式
# Method Section Draft
## [Section number]. Method / Approach / [Custom name]
### [N.1] Problem formulation
[Input, output, objective — with full notation setup]
### [N.2] [Core component]
[Motivation → Intuition → Formalization → Interpretation]
[Equation / Algorithm box if applicable]
### [N.3] [Secondary component — if needed]
...
### [N.4] Training
[Loss function, optimizer, training procedure]
---
## Notes
**Notation defined:** [list of all symbols introduced]
**Moved to appendix:** [list with reason]
**What to cite rather than explain:** [list]
**Figures needed:** [description of each, with what it should show]
**Reviewer risks:** [anything likely to draw pushback, with mitigation]
既存の草稿を修正する場合は、次も含めます。
## Diagnosis
[Which failure mode(s) the current draft has]
## Changes made and why
品質基準
手法のセクションを読んだレビュー担当者が、次のことをできる必要があります。(1)核心となるアイデアを一文で述べる。(2)先行研究と比べて新しい点を特定する。(3)順伝播またはアルゴリズムの概要を描く。(4)どの構成要素が新規で、どれが標準的なものかを把握する。いずれかができない場合は、セクションを改訂する必要があります。