academic-paper

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

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

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

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

ルーティングの規律（v3.9.2）： クロススキルのルーティングルールについては、AGENTS.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

---

トリガー条件

トリガーキーワード

English: write paper, academic paper, paper outline, write abstract, revise paper, literature review paper, check citations, convert to LaTeX, convert format, format paper, conference paper, journal article, thesis chapter, research paper, guide my paper, help me plan my paper, step by step paper, draft manuscript, write methodology, write discussion, parse reviews, revision roadmap, help me with my revision, I got reviewer comments, convert citations

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

Plan モードの有効化

ユーザーがガイダンスや段階的な計画を求めている場合、または論文の構成について不確かさを示している場合は、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 の受付から Phase 7 のフォーマット調整まで）で実行されます。呼び出し方法は2つあります。

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

モード B — フェーズごとの実行（セッションをまたいだ再開）： 長期プロジェクトでは、ユーザーがセッションをまたいで各フェーズのエージェントを1つずつ呼び出します。よくあるパターンは、あるセッションで草稿を作成し、翌週に戻って引用チェック、要旨作成、査読をそれぞれ独立して行う方法です。

モード 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）を制約します。

モード B へのルーティングには、明示的なユーザーの指示が必要です。/ars-<mode> スラッシュコマンド、または [direct-mode] プレフィックスを使用してください。フェーズをまたぐ入力の意図が曖昧な場合は、AGENTS.md（プロジェクトルート）の Routing Discipline と shared/references/intent_clarification_protocol.md に従って、デフォルトで確認を求めます。

適用の仕組み（v3.9.2）： Bucket A エージェントの Phase Boundary ブロックによるプロンプトレベルの制御と、アドバイザリー検証ツール（scripts/check_pipeline_integrity.py）で適用します。決定論的な PreToolUse フックと複数フェーズのエンベロープは、v3.10 のアクティブコンダクター（#134）まで保留されています。

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 では、契約 writer_full および evaluator_full によってゲートされる、論文を見ない／論文を参照できる呼び出しのペアに分けることで、Phase 4（ライターによる草稿作成）と Phase 6（ペア内エバリュエーターによるレビュー）を分割します。この分割は、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を参照してください。