paper-writer

論文執筆

概要

このスキルは、研究者のアイデアや資料を、投稿可能な論文の文章に仕上げます。段落ひとつでも、論文全体でも対応できます。

アウトライン生成ツールでも、文章指導ツールでもありません。譲れない条件のもとで文章を執筆します。その条件とは、書かれたすべての言葉が根拠をたどれることです。内容（アイデア、設計、結果、結論）は著者が担い、このスキルが担うのは、その内容を言語として表現することだけです。それ以上のことは行いません。

厳守事項

このスキルが行うすべてのタスクに、以下が適用されます。

1. すべての事実に関する主張は、ユーザーの資料、このセッションで検証した検索結果、または数字・固有名詞・比較を含まない分野の一般知識の、いずれか一つに基づきます。モデルの記憶を情報源として使うことはありません。
2. 提出する文章には、種類を問わず、角括弧付きのプレースホルダータグを一切含めません。出典のない主張は、タグを付けるのではなく、検索、書き換え、または削除によって解決します。
3. ユーザーが提供していない具体的な詳細は記述しません。シナリオ、メカニズム、規模、手順、識別子を捏造することはありません。
4. 主張の強さが、根拠の強さを超えることはありません。
5. 実際の結果と、計画中または予想される結果は異なる表現にし、決して混同しません。
6. 内部の計画が出力に漏れることはありません。

根拠の優先順位や Evidence Map を含む詳細な方針については、references/evidence-discipline.md を参照してください。

このスキルを使う場面

• 「このアイデアを英語の序論の段落にまとめてください。」
• 「特定の投稿先のスタイルで考察を下書きしてください。」
• 「論文の初稿全体を書いてください。」
• 「このメモを方法のセクションにまとめてください。」
• 「抄録を作成してください。」

このスキルを使わない場面

• ユーザーが序論の執筆を具体的に求めている場合：そのセクションは intro-drafter が担当します（このスキルが自動的にそちらへ振り分けます）。
• ベンチマーク論文の計画を立てている段階の場合：まず benchmark-paper-template を使い、その後、文章の執筆に戻ってください。
• 既存の文章を言語面で推敲する場合：paper-polish を使ってください。
• 論理構成がまだ固まっていない場合：まず tech-paper-template を使ってください。
• アイデア自体がまだ検証されていない場合：idea-evaluator を使ってください。

機能の確認（セッションごとに1回実行）

このスキルは2つの環境機能を利用します。利用できない機能がある場合は、その制約に応じて対応します。

• 文献検索：実行環境が提供する学術検索ツールを使用します。提供されていない場合は、学術インデックスを対象にウェブ検索を行います。それもできない場合は、シェルから公開 API（Crossref、Semantic Scholar、arXiv、DBLP）にアクセスします。いずれも利用できない場合は、外部検索を行わずに作業し、ユーザー提供の参考文献のみを引用します。引用に関する主張は引用レベルにとどめ、独立した検索を行えなかったことを提出時の注記で明らかにします。
• 新規コンテキストのサブエージェント：引用を独立して検証するために使用します。利用できない場合は、同一コンテキスト内での根拠確認に切り替えます。検証の段階と制約の開示ルールについては、references/verification-ladder.md を参照してください。

上記の根拠に関するルールが緩和されることはありません。変わるのは検証方法だけであり、制約が生じた場合はその旨を開示します。

ワークフロー

6つのフェーズがあります。論文全体を執筆する場合は、すべてのフェーズを明示的に進めます。単一のセクションの場合は、同じフェーズを簡略化して進めますが、根拠の確認やレビューを省略することはありません。

フェーズ 1：範囲

ユーザーに詰問することなく、次の 3 点を手早く決めます。

• 粒度：論文全体（作業ファイルとして、エビデンスマップ、章構成案、続いて草稿を作成）か、単一のセクションまたは段落（頭の中で資料を整理し、文章を直接提出）か。
• パラダイム：分野名ではなく、研究手法で判断します。実験、ベンチマーク、モデル、アルゴリズムなら STEM、テキスト分析、アーカイブ、概念的議論なら人文学、調査、インタビュー、回帰分析、フィールドワークなら実証社会科学、操作変数、差の差法、パネルデータなら経済学、法令、判例、法理なら法学、既存研究の統合ならレビューです。不明な場合は、中心的な手法と投稿先について質問を 1 つだけします。
• モード：草稿（既定。構造上のプレースホルダーを許可するのは表のみ）か、最終版（ユーザーが投稿可能な状態を求めた場合。未解決事項は一切許容しません）。

フェーズ 2：エビデンス

文章を書く前に、エビデンスベースの内容を明らかにします。

1. ユーザーの資料を確認します。ワークスペースのファイルにある場合はファイルを読み、パスを記録します。読める資料をユーザーに貼り付けてもらわないでください。
2. 異なるキーワードを使って 2〜3 回検索し、文献プールを構築します（論文全体の場合、目標規模はおよそ 20 件ですが、件数より網羅性が重要です）。
3. エビデンスの欠落を特定します。予定している主張のうち、現時点で L1〜L3 の情報源がないものはどれですか。

論文全体の場合は、エビデンスマップを文書化します。セクションの場合も同じ確認を頭の中で行います。テンプレート、レベル、ゲートについては、references/evidence-discipline.md を参照してください。

ゲート：L0〜L3 の情報源がない主張を事実として記述してはいけません。まず検索します。キーワードの異なる 2〜3 通りで検索しても何も見つからない場合は、その主張を削除して文を書き換えるか、主張そのものを削除します。

フェーズ 3：構成案

パラダイムとセクションに応じて進め方を決めます。

ケース	進め方
STEM の序論	intro-drafter に引き継ぎます（内部用の 6 段落構成案）。
STEM のその他のセクション	references/section-guidance.md の内容要件に従います。
非 STEM のすべてのセクション	各段落を CER の骨子で計画します：Claim（読者に何を信じてもらうか）、Evidence（何が、どのレベルで裏付けるか）、Reasoning（そのエビデンスがなぜ主張を裏付けるか）、Role（動機付け、位置付け、提案、実行、提示、解釈、限定、または接続）。
ベンチマーク論文	benchmark-paper-template で計画してから、ここに戻ります。

論文全体の場合は、作業ファイルとして章構成案を作成します。セクション、役割、中心的な判断、エビデンス ID、未解決の欠落を記載します。STEM の研究では、論理の連鎖を最初から最後まで確認します。限界が中心的なアイデアにつながり、中心的なアイデアが課題を提起し、各モジュールが課題に 1 対 1 で対応し、貢献が各モジュールを網羅していることを確認します。つながりが途切れている場合は、文章で取り繕わず、計画の段階で修正します。

以上はすべて内部作業です。成果物には含めません。

フェーズ 4：草稿

設計図に沿って、流れのある文章を書きます。出典の来歴を意識し、各段落を書く前に、その段落で何を主張するか、各主張をどの出典が裏付けるかを内部で整理します。出典のない主張は、計画段階で除外します。文中には、いかなる種類のマーカーも埋め込まず、読みやすい文章にします。

執筆時の厳守事項：

1. モデルの記憶から内容を生成しないでください。 正当な情報源は、ユーザー、検索、L0 の 3 つだけです。不確かな事実は検索で確認します。確認できなければ、タグを付けず、書き直すか削除します。
2. 根拠のレベルが主張の強さの上限を決めます。 L1 はあらゆる主張を裏付けます。L2 は方向性を示す要約を裏付けます。L3 は引用レベルの記述のみを裏付けます。L4 は何も裏付けません。
3. 具体的な情報を捏造しないでください。 5 つの危険なカテゴリ（シナリオ、メカニズム、規模、手順、識別情報）は禁止事項です。もっともらしい内容を捏造するくらいなら、省略してください。
4. 実際の結果と予定されている結果を区別してください。 確認済みの結果には、「観察されます」「結果は示しています」を使います。予測される結果や未確認の結果には、「著者らは報告しています」「予備的な結果は示唆しています」を使います。
5. 著者に代わって誇張しないでください。 根拠がない場合は、「可能性があります」「有望です」「期待されています」を使います。
6. 各セクションは、それぞれの役割を一度だけ果たします。 序論では、読者の関心を引き、研究上のギャップを示し、目的を述べます。方法では、ほかの研究者が再現できるようにします。結果では理由を述べずに観察内容を報告します。考察では理由を説明し、先行研究と関連付け、限界を認めます。結論では序論の問いに答えます。要旨は最後に書く、単独で読める小さな論文です。同じ知見を記載するセクションは、多くても 3 つまでです。
7. 内部の下書き用構造を出力に含めないでください。 CER の骨格、パラダイムの呼び出し、連鎖の確認はすべて内部にとどめます。

フェーズ 4.5：危険信号（執筆中の停止サイン）

考えたこと	適切な対応
「この尺度は 10 項目だったはずです」	停止。不確かです。項目数を省略します
「この論文ではメタ分析を使っていたはずです」	停止。全文を確認していません。引用レベルにとどめて、「X ら（年）は Y を研究しました」とします
「この事例の引用番号を覚えています」	停止。数字が 1 桁違えば誤りです。識別情報を省略します
「この材料の導電率はおよそ……」	停止。ユーザーが数値を示していない限り、材料間の比較はしません
「この国の政策は……のように機能します」	停止。制度に関する詳細は、ユーザーの説明どおりに限ります
「背景ではこの分野の発展に触れるべきです」	停止。L0 を超える背景情報の主張には、L1～L3 の出典が必要です。検索し、見つからなければ書きません
「読者はここで同意に関する詳細を期待しています」	停止。情報が提供されていなければ省略します
「表はすべて埋まっているほうが専門的に見えます」	停止。セルに -- と記載するほうが、値を捏造するより 100 倍安全です
「この考察はもっと充実させるべきです」	停止。捏造したメカニズムではなく、根拠を加えて内容を充実させます。長くて空虚な文章より、短く正確な文章を優先します
「この方法はソーラーファーム／自動運転にも応用できるでしょう……」	停止。ユーザーはそのようなシナリオを挙げていません
「スペクトル分解／勾配結合によって機能します……」	停止。ユーザーはそのようなメカニズムを説明していません
「対象の規模は 10 倍異なる／ピクセル数は 10 未満／クラス数は数百です」	停止。ユーザーはそのような規模を示していません
「具体的な失敗例を挙げれば分かりやすくなります」	停止。分野に関する事例を捏造しません。ユーザー自身の説明を使います

フェーズ 5：レビュー

次の 3 つを、この順序で行います。

1. 情報源の想起確認とインラインチェックリスト。 references/verification-checklist.md に沿って、事実、根拠との一致、セクション間の規律、AI の痕跡の確認、数式と表、提出形式を確認します。
2. 引用の独立検証。 論文全体を作成する場合、Final モード、または引用が 3 件以上の場合は必須です。新しいコンテキストのサブエージェントに散文と参考文献リストだけを渡し、検索によって各項目を検証します。ステータス、解決方法、段階的な品質低下への対応については、references/verification-ladder.md を参照してください。未解決の問題が残る項目がなくなるまで、提出は行いません。
3. レビューでできないことを理解する。 同じコンテキストでのレビューは、機械的な問題（番号、形式、セクション間の重複）を確実に見つけられます。一方で、自ら作り出した内容の意味上の捏造を確実に見つけることはできません。シナリオをでっち上げたモデルは、読み返してもそのシナリオを正しいと判断します。本当の防御策は、フェーズ 2～4 の執筆時に根拠を必須とすることです。レビューは最後の安全網であり、引用レイヤーが独立した検証を受けるのは、機械的に外部へ委託できる唯一のレイヤーだからです。

フェーズ 6：提出

成果物と禁止事項については、references/prose-delivery.md を参照してください。

• セクションまたは段落が 1 つの場合：散文は会話内に記載し、引用がある場合は参考文献リストを付け、注記は 3 行以内にします。
• 論文全体の場合：原稿はワークスペースのファイル（Markdown または LaTeX）に記述し、参考文献を含めます。Evidence Map と設計図は別の作業ファイルとして保持し、求められた場合に提供します。原稿に埋め込んではなりません。
• 機能が低下した場合（検索を利用できない、サブエージェントを利用できないなど）は、注記に明記します。

文献の先回り検索

ユーザーから参考文献がすべて提供されるのを待ってはいけません。引用が少ないと意見文のように見え、査読者に却下されます。

参考文献の密度（目安であり、ノルマではありません）：論文の Introduction 全体では通常 15～25 件、特定の研究上のギャップや背景を扱う段落では 3～6 件、Related Work では 15～30 件、Methods では 3～8 件（引用する手法、データセット、プロトコル）、Discussion では 5～15 件、論文全体ではおよそ 20～40 件です。

執筆後ではなく、執筆前に検索します。 セクションの草稿を書く前に、異なる切り口で 3～5 回検索します。中核となる用語、手法やモデルの名称、応用分野、会場や著者名を切り口にします。検索で見つかった文献は、後から付け足す飾りではなく、論旨を組み立てる材料です。

検索で得られるのはメタデータ（L3）であり、裏付けられるのは引用レベルの記述に限られます。「Author et al. による最近の研究は、Y を用いて X に取り組みました」という記述は問題ありませんが、「その手法は 3 段階のパイプラインに依存しています」や具体的な数値は、ユーザーから要旨または全文が提供されていない限り使えません。L3 しか手元にない状態で全文レベルの内容が必要な場合は、引用レベルの表現で書き、より踏み込んだ一文を裏付けるためにどの情報源が必要かを注記でユーザーに伝えます。

草稿の引用が明らかに少ない場合は、もう一度検索し、実際の知見を織り込んでください。プレースホルダーで不足を埋めてはいけません。

引用と参考文献

標準のスタイルは、本文と相互に対応する References セクションを備えた、引用順の番号方式です。項目の形式、著者に関する規則、欠落したフィールドの扱い、その他のスタイル（APA、Chicago、Harvard、Vancouver）については、references/citation-style.md を参照してください。

出力言語

明示された言語の指定を最優先します。対象が中国語の学術誌または中国語の論文の場合は、中国語の学術文体で執筆します。それ以外では英語を標準とします。ユーザーが入力した言語から出力言語を推測してはいけません。中国語でアイデアを説明し、英語で提出するのは一般的なケースです。

関連スキルとの境界

• intro-drafter：序論の文章作成（このスキルは、STEM 分野の序論をここに振り分けます）。
• paper-polish：既存の文章の推敲（中国語から英語への翻訳を含む）。
• tech-paper-template：執筆前の論理構成の骨組み。
• benchmark-paper-template：ベンチマーク論文の計画。
• pre-submission-reviewer：完成した草稿の査読者視点での監査。
• idea-evaluator：そのアイデアをそもそも追求する価値があるかどうかの評価。

草稿の執筆を通じて、問題が「どう書くか」ではなく「中心的な主張は成り立つか」だと判明した場合は、その旨を納品メモではっきり述べ、pre-submission-reviewer または idea-evaluator を案内してください。ユーザー自身のデータが裏付けていない主張を擁護する文章は決して書かないでください。