academic-paper

学術論文 — 学術論文執筆エージェントチーム

汎用的な学術論文執筆ツールです。あらゆる分野に対応する12エージェントのパイプラインを備え、高等教育分野を既定の参考領域としています。

v2.5 では、執筆品質に関する2つの機能が追加されました。

• スタイル調整（インテークのステップ10、任意） — 過去の論文を3本以上提供すると、パイプラインがあなたの文体（文のリズム、語彙の好み、引用の組み込み方）を学習します。執筆時にはソフトガイドとして適用されますが、分野の慣習が常に優先されます。shared/style_calibration_protocol.md を参照してください。
• 執筆品質チェック（references/writing_quality_check.md） — 下書きの自己レビュー段階で適用される執筆品質チェックリストです。AIにありがちな用語の多用、em dash の多用、前置きの長い書き出し、段落の長さの均一化、単調な文のリズムを検出します。これらは文章を改善するためのルールであり、検出回避を目的とするものではありません。

ルーティング規律（v3.9.2）： スキルをまたぐルーティングルールについては、.claude/CLAUDE.md の「Routing Discipline (v3.9.2)」と shared/references/intent_clarification_protocol.md を参照してください。このスキルはルーティングがすでに確定していることを前提としています。フェーズをまたぐ資料に曖昧さがある場合は、上流で確認されている必要があります。

クイックスタート

最小コマンド：

Write a paper on the impact of AI on higher education quality assurance

Write a paper on the impact of declining birth rates on private university management strategies

実行フロー：

1. 設定に関するヒアリング — 論文の種類、分野、引用形式、出力形式
2. 文献検索 — 体系的な検索戦略、情報源のスクリーニング
3. 構成設計 — 論文の構成、アウトライン、語数の配分
4. 論証の構築 — 主張と証拠の連鎖、論理の流れ
5. 全文の執筆 — セクションごとの下書き、文体の調整
6. 引用規則への準拠 + バイリンガルの要旨（並行処理）
7. 査読 — 5つの観点からの評価、修正案
8. 出力形式の整形 — LaTeX/DOCX（Pandoc 経由）/PDF/Markdown

---

起動条件

起動キーワード

英語: 論文を書く、学術論文、論文のアウトライン、要旨を書く、論文を修正する、文献レビュー論文、引用を確認する、LaTeX に変換する、形式を変換する、論文を整形する、学会論文、学術誌論文、学位論文の章、研究論文、論文執筆を案内して、論文の計画を手伝って、段階的に論文を書く、原稿の下書きを作る、方法論を書く、考察を書く、査読意見を解析する、修正ロードマップ、修正を手伝って、査読者のコメントを受け取った、引用形式を変換する

繁體中文: 論文を書く、学術論文、論文のアウトライン、要旨を書く、論文を修正する、文献レビュー論文、引用を確認する、LaTeX に変換する、形式を変換する、学会論文、学術誌論文、学位論文、研究論文、論文執筆を案内して、論文の計画を手伝って、段階的に論文を書く、方法論を書く、考察を書く、査読意見、修正ロードマップ、修正を手伝って、査読意見を受け取った、引用形式を変換する

プランモードの有効化

ユーザーが案内や段階的な計画を求めている場合、または論文の構成に不安を示している場合は、plan モードを有効にしてください。既定のルール：plan と full のどちらか判断がつかない場合は、plan を優先してください。

意図のシグナルと有効化ルールの詳細については、references/plan_mode_protocol.md を参照してください。

起動しないケース

シナリオ	代わりに使用
詳細な調査／ファクトチェック（論文執筆ではない）	deep-research
論文の査読（構造化レビュー）	academic-paper-reviewer
研究から論文執筆までの全工程	academic-pipeline

deep-research との違い

特徴	academic-paper	deep-research
主な出力	出版可能な論文の下書き	調査レポート
構成	学術誌への投稿に適した形式（IMRaD など）	APA 7.0 レポート
引用	複数形式（APA/Chicago/MLA/IEEE/Vancouver）	APA 7.0 のみ
要旨	バイリンガル（zh-TW + EN）	単一言語
査読	5つの観点からの模擬査読	編集レビュー
出力形式	LaTeX/DOCX（Pandoc 経由）/PDF/Markdown	Markdown のみ
修正ループ	的を絞ったフィードバックで最大2ラウンド	最大2ラウンド

---

エージェントチーム（12 エージェント）

#	エージェント	役割	フェーズ
1	intake_agent	設定ヒアリング：論文の種類、専門分野、ジャーナル、引用形式、出力形式、言語、語数。引き継ぎの検出。Plan モードでは簡略化したヒアリング	フェーズ 0
2	literature_strategist_agent	検索戦略の設計、情報源の選別、注釈付き書誌、文献マトリックス	フェーズ 1
3	structure_architect_agent	論文構成の選定、詳細なアウトライン、語数の割り当て、エビデンスのマッピング	フェーズ 2
4	argument_builder_agent	論証の構築、主張とエビデンスの連鎖、論理展開、反論への対応。Plan モードでは論証のストレステスト	フェーズ 3 / Plan ステップ 3
5	draft_writer_agent	セクションごとの全文執筆、専門分野に応じた文体の調整、語数の追跡	フェーズ 4
6	citation_compliance_agent	引用形式の検証、参考文献リストの網羅性確認、DOI の確認	フェーズ 5a
7	abstract_bilingual_agent	二言語のアブストラクト（zh-TW + EN）、各言語 5～7 個のキーワード	フェーズ 5b
8	peer_reviewer_agent	模擬二重盲検査読、5 つの観点での採点、修正案（最大 2 ラウンド）	フェーズ 6
9	formatter_agent	LaTeX／DOCX（Pandoc 経由）／PDF／Markdown への変換、ジャーナル書式への整形、カバーレター、引用形式の変換（APA 7／Chicago／MLA／IEEE／Vancouver）	フェーズ 7
10	socratic_mentor_agent	Plan モードのソクラテス式メンター：章ごとのガイダンス、収束基準（4 つのシグナル）、質問分類（4 種類）、INSIGHT の抽出	Plan ステップ 0～3
11	visualization_agent	論文のデータを解析し、APA 7.0 書式、色覚多様性に配慮した配色、LaTeX 連携に対応した、出版品質の図表コードを生成（Python matplotlib／R ggplot2）	フェーズ 4 / フェーズ 7
12	revision_coach_agent	構造化されていない査読者コメントを構造化された Revision Roadmap に変換。コメントの分類、対応付け、優先順位付けを行う。事前のパイプライン実行なしでも単独で動作	Revision-Coach モード

---

出力形式

テキスト形式

LaTeX（.tex + .bib）、DOCX（Pandoc 経由）、PDF（LaTeX または Pandoc 経由）、Markdown。

図表

論文に定量的な結果が含まれる場合、visualization_agent は APA 7.0 書式と色覚多様性に配慮した配色で、出版に適した図表を Python（matplotlib／seaborn）または R（ggplot2）で生成できます。図表は実行可能なコードと LaTeX の \includegraphics 連携コードとして提供されます。グラフの種類を選ぶための判断ツリーとコードテンプレートについては、references/statistical_visualization_standards.md を参照してください。

引用形式

APA 7.0（デフォルト）、Chicago（著者・年方式または注・文献目録方式）、MLA 9、IEEE、Vancouver。formatter_agent は「Convert citations to [format]」を使って、サポートされている任意の 2 つの形式間で、後工程での引用形式変換に対応しています。

---

オーケストレーションのワークフロー（8 フェーズ）

Phase 0: CONFIG        -> [intake_agent]              -> Paper Configuration Record
Phase 1: RESEARCH      -> [literature_strategist]      -> Search Strategy + Source Corpus
Phase 2: ARCHITECTURE  -> [structure_architect]        -> Paper Outline + Evidence Map
Phase 3: ARGUMENTATION -> [argument_builder]           -> Argument Blueprint
Phase 4: DRAFTING      -> [draft_writer]               -> Complete Draft
Phase 5a: CITATIONS    -> [citation_compliance] ──┐    -> Citation Audit Report
Phase 5b: ABSTRACT     -> [abstract_bilingual]   ─┘    -> Bilingual Abstract + Keywords  (parallel)
Phase 6: PEER REVIEW   -> [peer_reviewer]              -> Review Report (max 2 revision loops)
Phase 7: FORMAT        -> [formatter]                  -> Final Output Package

フェーズごとのエージェントの動作と出力の詳細については、references/workflow_phase_details.md を参照してください。

チェックポイントのルール

1. ⚠️ 絶対ルール：フェーズ 1 に進む前に、ユーザーは論文設定レコードを確認する必要があります
2. フェーズ 2 → 3：ユーザーはアウトラインを承認する必要があります（再構成をリクエストできます）
3. ⚠️ 絶対ルール：修正ループは最大 2 回です。未解決の項目は「Acknowledged Limitations」に移します
4. 査読で重大度が Critical の問題が見つかった場合、フェーズ 7 への進行はできません
5. ユーザーは自分で情報源を提示する場合、フェーズ 1（文献）をスキップできます

---

v3.4.0 準拠（full モードに適用）： 最終化の前に、compliance_agent が RAISE の原則のみを対象とするチェックを実行します（警告のみ。一次研究は PRISMA-trAIce の適用範囲外です）。警告は開示文に記載されますが、パイプラインを停止させることはありません。shared/raise_framework.md §Scope disclaimer を参照してください。

フェーズごとの呼び出し契約（v3.9.2）

academic-paper パイプラインは8つのフェーズで実行されます（Phase 0 受付 → 7 体裁調整）。呼び出しモードは2種類あります。

Mode A — オーケストレーター主導（デフォルト）： pipeline_orchestrator_agent（academic-pipeline スキル内）が、Material Passport による状態追跡を行いながら、すべてのフェーズをエンドツーエンドで実行します。

Mode B — フェーズごとの呼び出し（セッションをまたいだ再開）： 長期プロジェクトで、ユーザーがセッションをまたいで各フェーズに1つずつエージェントを呼び出します。一般的なパターンは、あるセッションで草稿を書き、翌週に戻って引用チェック、アブストラクト作成、または査読を個別に行うことです。

Mode B では、単一フェーズエージェント（docs/design/2026-05-18-ars-v3.9.2-agent-phase-classification.md における Bucket A）は、書き込みを割り当てられたフェーズ内に厳密にとどめます。academic-paper の7つの Bucket A エージェントは、literature_strategist（P1）、structure_architect（P2）、draft_writer（呼び出しに応じてP4/P6）、citation_compliance（P5a）、abstract_bilingual（P5b）、peer_reviewer（P6）、formatter（P7）です。上流フェーズの読み取りは許可されます。

複数フェーズエージェント（Bucket B：argument_builder P3+Plan、visualization P4+P7）は、呼び出し元がそのフェーズについて指定した作業のみを行い、同じ呼び出しで他のフェーズにまで作業を広げません。以下の v3.6.6 ジェネレーター・エバリュエーター契約はさらに、draft_writer と peer_reviewer のサブフェーズ動作（Phase 4a/4b、Phase 6a/6b）を制約します。

Mode B へのルーティングには、ユーザーからの明示的なシグナルが必要です。/ars-<mode> スラッシュコマンド、または [direct-mode] 接頭辞を使用します。フェーズをまたぐ入力が曖昧な場合は、.claude/CLAUDE.md の Routing Discipline と shared/references/intent_clarification_protocol.md に従い、デフォルトで確認を求めます。

適用（v3.9.2）： Bucket A エージェントに対する Phase Boundary ブロック、アドバイザリーベリファイアー（scripts/check_pipeline_integrity.py）、およびフック対応ランタイムにおける決定論的な PreToolUse 書き込みスコープガード（#134 rescope、PR #294）によって適用されます。複数フェーズの範囲は引き続き前方のみです（#134 Slices 3-5）。

v3.6.6 ジェネレーター・エバリュエーター契約プロトコル

academic-paper full モード内で、v3.6.6 の契約ゲート付きフェーズ分割を行うための、正式なオーケストレーションブロックです。v3.6.6 以降はスキーマ13.1（shared/sprint_contract.schema.json）です。テンプレート：shared/contracts/writer/full.json + shared/contracts/evaluator/full.json。設計仕様：docs/design/2026-04-27-ars-v3.6.6-generator-evaluator-contract-design.md §5。

academic-paper full モードにのみ適用されます。 9つの非 full モード（plan、outline-only、revision、revision-coach、abstract-only、lit-review、format-convert、citation-check、disclosure）は v3.6.5 から v3.6.6 でバイト単位の同一性が保たれており、このプロトコルは呼び出されません。（後から追加された rebuttal-audit モードも同様に非 full のため、このプロトコルを呼び出しません。）パイプラインの境界に変更はありません。academic-pipeline Stage 2 は academic-paper を plan または full モードでディスパッチします（このプロトコルを呼び出すのは full のみです）。Stage 3 は別個の academic-paper-reviewer スキル（外部編集者による5パネル査読）をディスパッチします。このプロトコルにおけるペア内の Phase 6 エバリュエーターと、Stage 3 のレビュアーは異なる査読レイヤーです。設計ドキュメント §5.1 の監査結論2を参照してください。

概要

v3.6.6 では、Phase 4（執筆者による草稿作成）と Phase 6（ペア内エバリュエーターによる査読）を、writer_full および evaluator_full 契約でゲートされた、論文非表示／論文表示の呼び出しペアに分割します。この分割は academic-paper-reviewer/references/sprint_contract_protocol.md（v3.6.2 のレビュアーパターン）を踏襲していますが、パネルを持たず（また、執筆者には）scoring_plan もない単一エージェントの生成モードに合わせて調整されています。

この仕組みの要となるのは、呼び出しを物理的に分離することです。執筆者の Phase 4a は実行時の草稿作成成果物を一切見ず、エバリュエーターの Phase 6a は執筆者の Phase 4b の草稿を一切見ません。これにより、ペア内の自己品質ゲートで「論文を読んでから基準を合理化する」という逸脱経路を断ちます。

4 回の呼び出し構成

academic-paper full を実行するたびに、Phase 4 と Phase 6 は、それぞれ 1 回の呼び出しから、個別のモデル呼び出し 4 回に分割されます。各呼び出しには、以下のシステムプロンプトとユーザーコンテンツの使い分けに従って、それぞれ独自のシステムプロンプトとユーザーコンテンツが設定されます。

1. Phase 4a — 論文を見ない状態でのライターによる事前コミットメント。
   • システムプロンプト：academic-paper/agents/draft_writer_agent.md の「v3.6.6 Generator-Evaluator Contract Protocol」§にある ### Phase 4a — Writer paper-blind pre-commitment サブセクション。
   • ユーザーコンテンツ：writer_full コントラクト JSON と論文のメタデータ（title、field、word_count）のみ。
   • 出力：## Acceptance Criteria Paraphrase セクションと、末尾の [PRE-COMMITMENT-ACKNOWLEDGED] タグ。
   • リント：構造チェック 3 項目（下記「Phase 4a / 6a output lint」§を参照）。
2. Phase 4b — 論文を確認したうえでのライターによるドラフト作成と自己採点。
   • システムプロンプト：同じエージェントファイルにある ### Phase 4b — Writer paper-visible drafting + self-scoring サブセクション。
   • ユーザーコンテンツ：writer_full コントラクト JSON（再注入）と、<phase4a_output>...</phase4a_output> データ区切り文字で囲まれた Phase 4a の出力、さらに上流のドラフト作成成果物（Paper Configuration Record、Paper Outline、Argument Blueprint、Annotated Bibliography、任意の Style Profile、任意の Knowledge Isolation Directive）。
   • 出力：## Draft Body → ## Dimension Scores → ## Failure Condition Checks → ## Writer Decision。
   • リント：構造チェック 4 項目（下記「Phase 4b / 6b output lint」§を参照）。
3. Phase 6a — 論文を見ない状態での評価者による事前コミットメント。
   • システムプロンプト：academic-paper/agents/peer_reviewer_agent.md の「v3.6.6 Generator-Evaluator Contract Protocol」§にある ### Phase 6a — Evaluator paper-blind pre-commitment サブセクション。
   • ユーザーコンテンツ：evaluator_full コントラクト JSON、論文のメタデータ、ライターの最新の <phase4a_output>（disagreement_handling.pre_commitment_check_protocol.check_writer_artifact に従って評価者が検証する必要のあるライターの成果物）。
   • 出力：## Contract Paraphrase と ## Scoring Plan（各ディメンションの dimension_id / what_to_look_for / what_triggers_block / what_triggers_warn）、および末尾の [PRE-COMMITMENT-ACKNOWLEDGED] タグ。
   • リント：構造チェック 5 項目。
4. Phase 6b — 論文を確認したうえでの評価者による採点と判定。
   • システムプロンプト：同じエージェントファイルにある ### Phase 6b — Evaluator paper-visible scoring + decision サブセクション。
   • ユーザーコンテンツ：evaluator_full コントラクト JSON（再注入）、<phase6a_output>...</phase6a_output> で囲まれた Phase 6a の出力、ライターの <phase4a_output>（pre_commitment_check_protocol.check_writer_artifact に従い無条件で含める）、およびライターの Phase 4b ドラフト（レビュー対象の成果物）。
   • 出力：## Dimension Scores → ## Failure Condition Checks → ## Review Body → ## Evaluator Decision。
   • リント：構造チェック 5 項目。

システムプロンプトとユーザーコンテンツの使い分け

sprint_contract_protocol.md §2 のレビュアーパターンをそのまま反映します。

• システムプロンプトに含めるのは、不変のポリシーテキストのみです：エージェントファイルの ## v3.6.6 Generator-Evaluator Contract Protocol ブロックにあるフェーズ別サブセクションの指示、リントの説明、フェーズ境界タグの規約です。
• ユーザーコンテンツには、コントラクト JSON（呼び出しごとに再注入）と、そのフェーズで許可される実行時入力を含めます：論文のメタデータ、<phase4a_output> / <phase6a_output> の区切りブロック、上流のドラフト作成成果物、論文のドラフトです。

動的な LLM 出力（Phase Na の実行時生成内容、論文の内容）はすべて、データ区切り文字を使ってユーザーコンテンツに置きます。システムプロンプトには決して含めません。これにより、論文ごとに変わる動的なコンテンツが、不変のポリシー領域に誤って取り込まれることを防ぎます。

スキーマのフィールド名と実行時の出力の違い

pre_commitment_artifacts（スネークケース、バッククォートで囲んだ表記）は、shared/sprint_contract.schema.json のスキーマフィールド名です。これは、固定された契約ベースラインにおける設定宣言です。「writer Phase 4a pre-commitment output」は実行時の出力、つまり writer エージェントが Phase 4a で生成する実際の Markdown テキストです。実行時の出力は <phase4a_output> 内にあり、Phase 4b / Phase 6a / Phase 6b に引き渡されます。disagreement_handling（スキーマフィールド）と「evaluator Phase 6a pre-commitment output」（実行時の出力）も同じ関係です。この2つを混同すると、契約ベースラインの設定と LLM が生成したコンテンツの区別がつかなくなります。

Phase 4a / 6a の出力リンティング

sprint_contract_protocol.md §4 の列挙規約に従った、モード固有の構造チェック数です。

• Writer Phase 4a（3チェック）：必須セクションの順序（## Acceptance Criteria Paraphrase、末尾の [PRE-COMMITMENT-ACKNOWLEDGED]）；言い換えの段落数 ≥ pre_commitment_artifacts.acceptance_criteria_paraphrase.minimum_dimensions；Phase 4a のコンテンツが参照するのは契約 JSON と論文のメタデータのみです。## Scoring Plan セクションはありません — writer_full に scoring_plan は含まれません。
• Evaluator Phase 6a（5チェック）：必須セクションの順序（## Contract Paraphrase、## Scoring Plan、末尾の [PRE-COMMITMENT-ACKNOWLEDGED]）；言い換えの段落数 ≥ disagreement_handling.paraphrase_minimum_dimensions；各受け入れ基準の次元に対応する ### <Dn>: <name> サブセクションが1つずつあること；各 scoring_plan サブセクションが disagreement_handling.scoring_plan.per_dimension_criteria の4フィールド形式（dimension_id、what_to_look_for、what_triggers_block、what_triggers_warn）を含むこと；Phase 6a のコンテンツが参照するのは契約 JSON、論文のメタデータ、writer の <phase4a_output> のみです（ドラフト全文や論文のコンテンツは含みません）。

再試行の動作：最初の試行でリンティングに失敗した場合 → システムプロンプトで具体的なリンティング上の不足を示して1回再試行します。2回目も失敗した場合 → 以下の「単一エージェント生成器の使用不可時の処理」に従い、このロールを使用不可としてマークします。

Phase 4b / 6b の出力リンティング

• Writer Phase 4b（4チェック）：必須セクションの順序 — ## Draft Body、## Dimension Scores、## Failure Condition Checks、## Writer Decision；Dimension Scores は7つの writer 次元 D1–D7（shared/contracts/writer/full.json に準拠）すべてに1対1で対応すること；Failure Condition Checks は F1 / F4 / F2 / F3 / F0 すべてに1対1で対応すること；Writer Decision が F 条件の重大度の優先順位から導出できること。複数の異議による再試行はありません（writer には異議を唱える scoring_plan がありません）。整合性チェックはありません（writer Phase 4a は scoring_plan のトリガートークンを出力しません）。
• Evaluator Phase 6b（5チェック）：必須セクションの順序 — ## Dimension Scores、## Failure Condition Checks、## Review Body、## Evaluator Decision；Dimension Scores は5つの evaluator 次元 D1–D5（shared/contracts/evaluator/full.json に準拠）すべてに1対1で対応すること；Failure Condition Checks は F1 / F2 / F3 / F6 / F4 / F5 / F0 すべてに1対1で対応すること；整合性チェック（Phase 6b のスコアが Phase 6a の disagreement_handling.scoring_plan.per_dimension_criteria のトリガートークンと部分文字列一致すること）；Evaluator Decision が F 条件の重大度の優先順位から導出できること。複数の異議による再試行はありません（evaluator のフェーズ内の意見の相違は、再試行のトリガーではなく、disagreement_handling.disagreement_resolution による F 条件のアクションとして表されます）。

複数の異議による再試行は reviewer 専用（academic-paper-reviewer スキル）です。generator モードにはパネルがなく、異議の基準となる scoring_plan もありません。

3つのモードにおけるリンティング数のまとめ：

フェーズ	Reviewer（タッチなし）	Writer	Evaluator
Phase 1 / 4a / 6a	5	3	5
Phase 2 / 4b / 6b	6	4	5

単一エージェント生成器が利用不能な場合の処理

執筆者フェーズまたは評価者フェーズが利用不能になった場合（Phase Na の lint が 2 回続けて失敗、または Phase Nb の lint が失敗）、academic-paper はフェーズレベルの中止タグを出力し、ユーザーによる対応に移ります。

• Writer Phase 4 が利用不能 → [GENERATOR-PHASE-ABORTED: role=writer, contract=<id>, reason=<lint_failure_kind>] → academic-paper Phase 4 を中止 → ユーザーが再試行／フォールバック／Phase 3（Argument Blueprint）への回帰を判断します。
• Evaluator Phase 6 が利用不能 → [GENERATOR-PHASE-ABORTED: role=evaluator, contract=<id>, reason=<lint_failure_kind>] → academic-paper Phase 6 を中止 → ユーザーが再試行／フォールバック／Phase 5（Drafting completion）への回帰を判断します。

[GENERATOR-PHASE-ABORTED] は有効な Phase 6b の出力とは見なされず、Stage 3 のレビュアーへのディスパッチには進めません。設計ドキュメント §5.1 によると、Stage 3 への有効な開始経路は 2 つあります。

• 標準経路：評価者の Phase 6b が F0 evaluator_decision=accept または F4 evaluator_decision=accept_with_dissent_note を出力します。
• 例外経路：ペア内の修正ループが第 2 ラウンドで尽き、必須ディメンションのブロックが再発した後、評価者の Phase 6b が F5 evaluator_decision=flag_for_reviewer_stage を出力します。

academic-paper は執筆者／評価者に関するパネルの要素数不変条件を持ちません（panel_size フィールドなし — Schema 13.1 §3.3.5 reviewer-conditional）。生成器側に [PANEL-SHRUNK] に相当するものはなく、[GENERATOR-PHASE-ABORTED] はフェーズレベルの中止です。

運用モニタリング：v3.6.6 のデプロイ後、最初の 3 か月間は [GENERATOR-PHASE-ABORTED] の発生率を追跡します。分母は academic-paper full の実行単位、つまりユーザーが認識する最上位の呼び出し 1 回です。5% のしきい値は (runs_with_any_abort) / (total_runs) です。発生率が 5% を超えた場合、v3.6.7 でグレースフルデグラデーションのフォールバックを導入します（下記「既知の制限事項」を参照）。

セッションをまたぐ再開の範囲

v3.6.6 の生成器・評価者ラウンド（Phase 4a + Phase 4b + Phase 6a + Phase 6b + ペア内の修正ループ）は、セッション内の不可分な単位です。ラウンドの途中でセッションを手動で分割すると、Writer Phase 4a の出力は失われ、新しいセッションでは Phase 0 から academic-paper full モードを再開する必要があります。

v3.6.3 の ARS_PASSPORT_RESET=1 reset_boundary[] メカニズム（academic-pipeline/references/passport_as_reset_boundary.md に記載）は、academic-paper 内部のフェーズ境界ではなく、academic-pipeline の Stage 境界で動作します。academic-paper 内部のフェーズ（4a / 4b / 6a / 6b）は境界ポイントではなく、その間に kind: boundary の台帳エントリは出力されません。運用データにより必要と判断された場合、v3.6.7 以降で pre_commitment_history[] を導入し、Writer Phase 4a の成果物をセッション間で保持する可能性があります。下記「既知の制限事項」を参照してください。

既知の制限事項

• v3.6.6 ではグレースフルデグラデーションのフォールバックなし：執筆者フェーズまたは評価者フェーズが [GENERATOR-PHASE-ABORTED] によって中止された場合、academic-paper full は中止され、ユーザーによる対応に移ります。v3.6.7 では、影響を受けるフェーズを v3.6.5 の単一呼び出しの動作に縮退させ、その縮退をログに記録するフォールバックを導入する可能性があります。v3.6.6 では中止のみの動作でリリースされます。運用上の 5%／3 か月のモニタリングについては、上記「単一エージェント生成器が利用不能な場合の処理」を参照してください。
• ラウンド途中でセッションをまたいで再開できない：生成器・評価者の 4 フェーズラウンドは、セッション内の不可分な単位です。ラウンドの途中でセッションを手動で分割すると、Writer Phase 4a の成果物が失われ、Phase 0 から再開する必要があります。v3.6.7 以降では、Schema 9 に pre_commitment_history[] の台帳エントリを導入して、Writer Phase 4a の成果物をセッション境界をまたいで保持する可能性があります。v3.6.6 では実装されません。
• ペア内の Phase 6 評価者と academic-paper-reviewer による外部レビュー：ペア内の peer_reviewer_agent（v3.6.6 のコントラクトゲートを使用する Phase 6 評価者）と、スタンドアロンの academic-paper-reviewer スキル（Stage 3 の 5 パネルによる外部編集レビュー）は異なるレビューレイヤーを担い、設計ドキュメント §1 の既知の制限事項に記載された技術的負債として残ります。ルーティング／マージの判断は v3.7.x 以降に延期されます。

運用モード（11種類）

詳細については、references/mode_selection_guide.mdを参照してください。

モード	トリガー	エージェント	出力
full	「論文を書いて」	全9種類（定量的な場合は11種類）	論文の完全な草稿（該当する場合は図を含む）
outline-only	「論文のアウトライン」	1->2->3	詳細なアウトライン＋エビデンスマップ
revision	「論文を改訂して」	8->5->6	パッチドキュメント＋決定論的に適用された改訂草稿＋適用レポート（#390；改訂ログはtemplates/revision_tracking_template.mdを参照）
abstract-only	「アブストラクトを書いて」	1->7	バイリンガルのアブストラクト＋キーワード
lit-review	「文献レビュー」	1->2	注釈付き参考文献リスト＋統合
format-convert	「LaTeXに変換」／「引用を[形式]に変換」	9のみ	書式設定済みドキュメント。引用形式の変換（APA 7／Chicago／MLA／IEEE／Vancouver）を含む
citation-check	「引用をチェック」	6のみ	引用エラーレポート
plan	「論文の指針を示して」／「論文の計画を手伝って」	1->10->3->4	章構成計画＋INSIGHTコレクション
revision-coach	「査読コメントを整理して」／「改訂ロードマップ」／「査読者のコメントを受け取った」／「反論すべきか」／「学会への回答」／「研究助成審査パネルへの回答」	12のみ	改訂ロードマップ＋任意のトラッキングテンプレート＋回答書の骨子（反論／不同意の姿勢、およびジャーナル／学会／研究助成審査パネル／査読後の投稿先変更のケースに対応）
disclosure（v3.2）	「Nature向けのAI開示」／「AI使用に関する声明を作成」	9のみ	投稿先に応じたAI使用開示文（段落）＋記載位置の指示
rebuttal-audit	「回答書を監査して」／「反論をチェックして」／「査読者のコメントを見落としていないか」（査読者のコメントと既存の回答書草稿の両方が必要）	12のみ（解析専用）	回答書の品質保証レポート：コメントごとの対応状況＋不足点＋リスクフラグ。新たな回答は生成しません。助言のみを行います。Schema 11／Material Passport／検証済みステータスは出力しません。

モード選択クイックガイド

状況	推奨モード	スペクトラム
明確なRQがあり、ゼロから始める	full	バランス
執筆前に計画を立てる支援が必要	plan	独自性
アウトラインだけが必要	outline-only	バランス
草稿があり、査読フィードバックを受け取った	revision	忠実性
整理されていない査読者コメントがある	revision-coach	バランス
アブストラクトだけが必要	abstract-only	忠実性
引用の確認／修正が必要	citation-check	忠実性
形式（LaTeX、DOCX）または引用スタイルの変換が必要	format-convert	忠実性
体系的な文献レビュー論文を作成したい	lit-review	忠実性
投稿先に応じたAI使用開示文が必要	disclosure	忠実性
査読者コメントと照合して品質確認するための、作成済み回答書草稿がある	rebuttal-audit	忠実性

スペクトラム（v3.2）：忠実性＝テンプレートを多用し、予測可能な出力；バランス＝デフォルト；独自性＝探索的で、テンプレートへの依存を抑えた出力。スキル全体のスペクトラム表については、shared/mode_spectrum.mdを参照してください。

迷った場合は、planから始めてください。手順に沿って案内します。disclosureは仕上げのステップです。論文の草稿ができた後、投稿予定の投稿先を指定して実行してください。

モード選択ロジック

トリガーとモードの対応、および選択フローチャート全体については、references/mode_selection_guide.mdを参照してください。

---

反論監査モード

rebuttal-audit は、著者の既存の反論／査読者への回答草案を、網羅性・トーン・根拠の観点から評価します。これは助言的な QA であり、回答を作成したり書き換えたりするものではありません。

入力ゲート（ルーティング）: rebuttal-audit を有効化するのは、ユーザーが (a) 査読者コメント／決定通知書 と (b) 評価対象となる既存の反論／回答草案 の両方を提供した場合のみです。(a) のみが存在する場合（草案がまだない場合）は、revision-coach（回答の骨子を生成する）へルーティングしてください。意図が曖昧な場合は、推測せずに確認してください。

生成されるもの:

• コメントごとの網羅性テーブル — 査読者の懸念事項のすべてを、草案内で addressed / partially / missing としてマークします。
• ギャップ一覧 — 草案が回答できていない懸念事項。
• リスクフラグ — トーンが攻撃的すぎる、根拠なく主張されている、または査読者の実際の指摘を誤解している回答。
• 改善提案（助言的）。

鉄則 — 整合性の境界（虚偽の認定を行わない）: rebuttal-audit は revision_coach_agent のコメント解析機能を再利用しますが、単独での呼び出しはパイプラインの外で実行されるため、Stage 4.5 の最終整合性を決して通過しません。これは Schema 11 の commitment_extracted 台帳を出力してはならず、Material Passport に書き込んではならず、パッケージを ready_to_submit またはいかなる検証済みステータスにもマークしてはなりません。Schema 11 の成果物を生成することは、回答がパイプラインのトレーサビリティシステムに入ったと誤って示唆することになります。出力は助言的な QA レポートのみです。

re-review との境界: academic-paper-reviewer の re-review モードは、改訂稿（著者が主張する変更が実際に論文に反映されているか）を検証し、パイプライン内で実行されます。rebuttal-audit は、回答書そのもの（反論がすべてのコメントを網羅しているか、そのトーン／根拠は妥当か）を検証し、単独で助言的に実行されます。成果物も層も異なります。

---

改訂モードのパッチプロトコル（#390）

改訂モードでは、draft_writer_agent は論文全体を再出力しません。このラウンドでは、アンカー化 → パッチ → 決定論的な適用 → 最終処理の順に進み、再生成の対象を改訂で明示的に指定されたブロックに限定します（DELEGATE-52 による影響範囲の封じ込め。仕様書は docs/design/2026-06-10-390-diff-patch-revision-mode-spec.md）：

1. 原稿をアンカー化する（scripts/ars_anchorize_draft.py — 冪等で、内容に影響しません）：すべてのブロックに安定した `` マーカーが付与され、ブロックマニフェスト（base_draft_hash + ブロックごとの old_hash）が再生成されます。この手順から適用までの間に、原稿を書き換えてはなりません。
2. ライターがパッチ文書を出力する（shared/contracts/patch/revision_patch.schema.json）。これは phase6_*/ のフェンス内にサイドカーファイルとして保存されます。ブロック操作にはマニフェストからコピーしたハッシュの前提条件が含まれ、各操作は roadmap_item_ids をたどって追跡できます。agents/draft_writer_agent.md § パッチ文書による改訂の出力を参照してください。
3. 決定論的に適用する（scripts/ars_apply_revision_patch.py）：2 段階のフェイルクローズ方式です。ハッシュが 1 つでも古ければ、ベース原稿のバイト列を一切変更せずにパッチ全体を拒否します。変更対象外のブロックは、構造上、バイト単位で完全に保持されます。構造上の変更（見出しの書き換え／削除、セクション数の変更、変更対象比率が 0.6 超）は、第 3.6 節のエスカレーションチェックポイントのみが許可できる、明示的な承認がない限り拒否されます。適用レポート（preserved_ratio、操作、新しいブロック ID、構造フラグ）は、改訂後の原稿とともに再レビューに必須の入力です。
4. エスカレーションを行い、暗黙のフォールバックはしない：再構成が必要なラウンドは、必須のユーザーチェックポイントに進みます。全体の再出力が確認されたラウンドには、来歴として mode: full_reemission_escalated が記録され、その後、原稿は再度アンカー化されます（ID を新たに生成）。

オーケストレーションされた実行では、pipeline_orchestrator_agent.md § 改訂ラウンドのパッチ処理順序に従います。モード B（フェーズごとの手動実行）のユーザーは、同じスクリプトを手動で実行します。正確なコマンドは references/revision_patch_protocol.md に記載されています。正直な制約を一度だけ明記します。パッチモードは、改訂で触れないテキストに対する暗黙の歪曲を防ぎますが、改訂そのものの質を高めるものではありません。academic-paper full のペア内フェーズ 6 → 4 ループはパッチを採用していません（フェーズ 4b の lint には完全な ## Draft Body が必要です。項目 9 の制約、および仕様書 §5.2／§7 を参照）。

---

プランモード：章ごとのガイド付き計画

ユーザーを一度に 1 章ずつ論文の計画作成に導くソクラテス式モードです。対話を構造化して、完全な論文ブループリントを作成します。

章ごとの対話の流れと論文ブループリントの構成については、references/plan_mode_protocol.md を参照してください。

---

引き継ぎプロトコル：deep-research → academic-paper

intake_agent は deep-research の資料（RQ ブリーフ／参考文献一覧／統合／INSIGHT コレクション）を自動的に検出し、重複する手順を省略します。引き継ぎ資料の形式全体については、deep-research/SKILL.md の引き継ぎプロトコルを参照してください。

---

失敗時の処理

詳細は references/failure_paths.md を参照してください。クイックリファレンス：

失敗シナリオ	対応方法
研究の基盤が不十分	まず deep-research を実行するよう提案する
誤った論文構成が選択された	フェーズ 2 に戻り、別の構成を提案する
目標語数を大幅に超過／不足している	問題のある章を特定し、削減または拡充を提案する
引用形式がまったく誤っている	引用フェーズ全体を再実行する
査読で却下された	却下理由を分析し、大幅な改訂または再構成を提案する
プランモードで収束しない	アウトラインのみのモードへの切り替えを提案する
引き継ぎ資料が不完全	不足項目を列挙し、補完または再実行を提案する
ユーザーが途中で中断した	完了済みの章計画を保存する

---

学術論文の全パイプライン

ワークフロー全体については、academic-pipeline/SKILL.md を参照してください。

---

フェーズ 0：設定のヒアリング

フェーズ 0 の設定ヒアリングにおける項目の定義については、agents/intake_agent.md を参照してください。ヒアリングでは、論文の種類、専門分野、投稿先ジャーナル、引用形式、出力形式、言語、要旨、語数、既存資料の 9 つの主要項目に加え、共著者、資金提供、任意の文体調整、分野別エビデンスプロファイル（ステップ 12）、引用検証レベル（ステップ 13、#392：デフォルトではマークのみ／厳格な検証は明示的なオプトインとし、terminal_policies.citation_existence に初期値を設定）を確認します。出力として論文設定記録を作成し、ユーザーの確認を待ちます。

---

ファイル構成

エージェント定義：agents/{agent_name}.md — エージェントごとに 1 ファイル（合計 12 ファイル。上記のエージェントチーム表に対応）。

参考資料（references/ 内に 20 ファイル）：

• 引用：apa7_extended_guide、apa7_chinese_citation_guide、citation_format_switcher
• 執筆：academic_writing_style、writing_quality_check、writing_judgment_framework
• 構成：paper_structure_patterns（6 種類）、abstract_writing_guide
• 分野：hei_domain_glossary（二言語）、journal_submission_guide、latex_template_reference
• プロセス：failure_paths（12 のシナリオ）、mode_selection_guide（11 のモード）、plan_mode_protocol、workflow_phase_details、revision_patch_protocol（#390 モード B のコマンドとマーカーのライフサイクル）
• 倫理：credit_authorship_guide（CRediT の 14 の役割）、funding_statement_guide、statistical_visualization_standards
• 開示（v3.2）：disclosure_mode_protocol（投稿先固有の AI 使用声明の生成）、venue_disclosure_policies（v1 データベース：ICLR、NeurIPS、Nature、Science、ACL、EMNLP）
• その他：deep-research/references/apa7_style_guide.md（基本資料。ここで拡張）

テンプレート（templates/ 内に 11 ファイル）：imrad、literature_review、case_study、theoretical_paper、policy_brief、conference_paper、latex_article_template.tex、bilingual_abstract、credit_statement、funding_statement、revision_tracking（4 種類のステータス）。

例（examples/ 内に 9 ファイル）：imrad_hei_example、literature_review_example、plan_mode_guided_writing、chinese_paper_example、revision_mode_example、revision_recovery_example、clinical_citation_verification_checklist、clinical_epistemic_status_example、version_family_reconciliation_example。

---

アンチパターン

よくある失敗を防ぐための明示的な禁止事項：

#	アンチパターン	問題点	正しい対応
1	AI にありがちな多用表現	「delve into」、「crucial」、「it is important to note」は、すぐに AI 生成と見抜かれます	分野固有の語彙を使用してください。references/writing_quality_check.md を参照
2	ダッシュの多用	1 ページにダッシュが 2 つを超えると、AI 生成の文章である兆候になります	括弧や読点を使うか、文の構成を変えてください
3	前置きだけの書き出し	「このセクションでは、〜について説明します」は情報を加えません	主張や知見から直接書き始めてください
4	段落の長さが均一	すべての段落が 4〜5 文だと、単調な AI らしいリズムになります	段落の長さに自然な変化をつけてください（2〜8 文）
5	⚠️ 絶対遵守：捏造した引用	実在しない、もっともらしい参考文献をでっち上げること	すべての引用を DOI または WebSearch で検証してください。academic-pipeline/agents/integrity_verification_agent.md を参照
6	迎合的な改訂	査読者の指摘を批判的に評価せず、すべて受け入れること	査読者の指摘が誤っている場合は REVIEWER_DISAGREE ステータスを使用し、根拠を示してください
7	改訂中のスコープ拡大	論文を「改善」するために、依頼されていないセクションや分析を追加すること	改訂では査読者の懸念のみに対応してください。新しい内容にはユーザーの明示的な承認が必要です
8	失敗時の対応経路を無視	デスクリジェクトの兆候や致命的な方法論上の欠陥があるのに、そのまま続行すること	references/failure_paths.md を確認し、該当する場合は F11 デスクリジェクトからの回復を実行してください

---

品質基準

執筆品質

1. すべての主張に引用を付けるか、論文自体のデータで裏付ける必要があります
2. 引用の孤立をゼロにする — 本文中の引用と参考文献リストを完全に一致させます
3. 文体を統一する — 専門分野にふさわしい学術的な文体にします
4. 論理的な流れ — 段落やセクション間を明確につなぎます
5. 語数の遵守 — 目標語数の±10％以内に収めます

バイリンガル要旨の品質

6. 独立した執筆 — zh-TWとENの要旨は個別に作成し、機械的に翻訳しません
7. 構成の整合性 — 両方の要旨で、同じ要点を同じ順序で扱います
8. キーワード — 各言語で5～7個とし、論文の中核概念を反映させます
9. 語数 — EN：150～300語、zh-TW：300～500文字

引用の品質

10. 書式の遵守 — 選択した引用スタイルに100％準拠します
11. ⚠️ 絶対遵守事項：DOIの記載 — DOIがあるすべての文献に記載します。すべての引用について、DOIまたはWebSearchで確認する必要があります
12. 新しさ — 10年以上前の文献に注意を促します（重要な基礎文献を除く）
13. 自己引用率 — 15％を超える場合は注意を促します

査読

14. 5つの評価軸 — 独創性（20％）、方法論の厳密性（25％）、エビデンスの十分性（25％）、論旨の一貫性（15％）、執筆品質（15％）
15. 実行可能なフィードバック — すべての批判に具体的な提案を添えます
16. 改訂は最大2回 — 解決されなかった項目は「認識済みの限界」として扱います

必須項目

⚠️ 絶対遵守事項：すべての論文に以下を含める必要があります：データ利用可能性に関する声明、倫理に関する宣言、著者の貢献（CRediT）、利益相反に関する声明、資金提供に関する謝辞。 17. AI使用の開示声明 — すべての論文に、AIツールの使用に関する声明を含める必要があります 18. 限界のセクション — 研究の限界を明示的に論じます 19. 倫理に関する声明 — 該当する場合（人を対象とする研究、機微データなど）に記載します

---

出力言語

ユーザーの言語に従います。学術用語は英語のままにします。本文の言語にかかわらず、バイリンガル要旨を必ず提示します。

---

他のスキルとの統合

academic-paper + tw-hei-intelligence  -> Evidence-based HEI paper with real MOE data
academic-paper + deep-research        -> Deep research phase -> paper writing phase (auto-handoff)
academic-paper + report-to-website    -> Interactive web version of the paper
academic-paper + notebooklm-slides-generator -> Presentation slides from paper
academic-paper + academic-paper-reviewer -> Peer review -> revision loop

---

バージョン情報

項目	内容
スキルのバージョン	3.2.0
最終更新日	2026-06-01
メンテナー	Cheng-I Wu
依存スキル	deep-research v1.0+（上流）、academic-paper-reviewer v1.0+（下流）

---

バージョン履歴

全バージョン履歴については、references/changelog.mdを参照してください。