academic-pipeline

Academic Pipeline v3.15.0 — 学術研究ワークフロー全体のオーケストレーター

研究の探索から最終原稿まで、学術研究パイプライン全体を管理する軽量なオーケストレーターです。実質的な作業は行わず、段階の検出、モードの推奨、スキルの呼び出し、移行の管理、状態の追跡のみを行います。

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

v3.6.3（オプトイン）： ARS_PASSPORT_RESET=1 を設定すると、FULL チェックポイントをコンテキストリセットの境界として扱います。新しいセッションで resume_from_passport=<hash> を使用すると、記録された段階から続行できます。references/passport_as_reset_boundary.md を参照してください。

v3.8（オプトイン）： ARS_CLAIM_AUDIT=1 を設定すると、Stage 4 → Stage 5 の移行時に L3 主張忠実度監査ゲートが有効になります。このフラグが設定されている場合、オーケストレーターは v3.7.1 Cite-Time Provenance Finalizer の後、formatter_agent のハードゲートの前に claim_ref_alignment_audit_agent を呼び出します。監査では、8 行のマトリクスに従って、claim_audit_results[] + uncited_assertions[] + claim_drifts[] + constraint_violations[] + audit_sampling_summaries[] の集計結果を出力します。HIGH-WARN クラスは、フォーマッターの REFUSE ルール 6-10 に基づき、出力を拒否します。v3.8.0 ではデフォルトで OFF です。段階的な有効化計画は、較正後のエビデンスが得られるまで延期されています（仕様 §5 のモードフラグの根拠）。agents/claim_ref_alignment_audit_agent.md と、オーケストレーターの §3.6 の説明を参照してください。

v2.0 の主な改善点：

1. 必須のユーザー確認チェックポイント — 各段階の完了後、次のステップに進む前にユーザーの確認が必要です
2. 学術的誠実性の検証 — 論文の完成後、査読への提出前に、参考文献とデータを 100% 検証する必要があります
3. 2 段階の査読 — 最初に全体を査読し、改訂後に重点項目を検証する査読を行います
4. 最終的な誠実性チェック — 改訂完了後、すべての引用とデータが 100% 正確であることを再検証します
5. 再現可能 — 毎回一貫した品質保証を実現する、標準化されたワークフローです
6. プロセスの記録 — パイプラインの完了後、人間と AI の協働履歴を記録した「論文作成プロセス記録」PDFを自動生成します

クイックスタート

全ワークフロー（最初から開始）：

I want to write a research paper on the impact of AI on higher education quality assurance

--> academic-pipeline が起動し、ステージ 1（RESEARCH）から開始します

途中から開始（既存の論文がある場合）：

I already have a paper, help me review it

--> academic-pipeline が途中からの開始を検出し、ステージ 2.5（INTEGRITY）から開始します

改訂モード（査読者からのフィードバックを受け取った場合）：

I received reviewer comments, help me revise

--> academic-pipeline が検出し、ステージ 4（REVISE）から開始します

パスポートから再開（セッションをまたぐコンテキストのリセット、オプトイン）：

resume_from_passport=<hash> [stage=<n>] [mode=<m>]

--> Material Passport（Schema 9）を読み込み、<hash> に一致する kind: boundary エントリを探し、それを消費する後続の kind: resume エントリがないことを確認します。pending_decision が設定されている場合は、ユーザーの分岐選択を監査台帳に記録するため、最初に決定プロンプトを表示します。ユーザーが stage= を指定していても、プロンプトは省略されません。プロンプト表示後（または pending_decision がない場合は直ちに）、次のステージは次のように決定されます：（a）指定されていれば CLI の stage=<n> 上書き、そうでなければ（b）一致したオプションの next_stage、それもなければ（c）boundary エントリに記録された next フィールドです。CLI の stage=／mode= 上書きはオプションのルーティングより優先されます。

• ゲート（記録）：記録を行うセッションで ARS_PASSPORT_RESET=1 を設定する必要があります。このフラグがない場合、kind: boundary エントリは書き込まれず、再開元となるエントリもありません。
• ゲート（再開）：フラグは不要です。ハッシュに一致する有効な boundary エントリを含むパスポートがあれば、どのセッションからでも resume_from_passport=<hash> を実行できます。
• 意図：新しい Claude Code セッションで実行してください。boundary を記録したセッション内で再開してもトークンの節約にはならず、セッション内でまだ有効なコンテキストが失われる可能性があります。
• ステージ：任意です。上記のルーティング規則によって決まるステージから再開します。
• リファレンス：references/passport_as_reset_boundary.md — §"resume_from_passport mode contract" を参照してください。

実行フロー：

1. ユーザーの現在のステージと利用可能な資料を検出します
2. 各ステージに最適なモードを提案します
3. 各ステージに対応するスキルを実行します
4. 各ステージの完了後、積極的に確認を促し、ユーザーの確認を待ちます
5. 全体を通して進捗を追跡します。Pipeline Status Dashboard はいつでも利用できます

---

トリガー条件

トリガーキーワード

英語：academic pipeline, research to paper, full paper workflow, paper pipeline, end-to-end paper, research-to-publication, complete paper workflow

トリガーされないケース

ケース	使用するスキル
資料の検索または文献レビューのみが必要	deep-research
論文の執筆のみが必要（研究フェーズは不要）	academic-paper
論文の査読のみが必要	academic-paper-reviewer
引用形式の確認のみが必要	academic-paper（citation-check モード）
論文形式の変換のみが必要	academic-paper（format-convert モード）

トリガーの除外条件

• ユーザーが単一の機能のみを必要としている場合（資料の検索のみ、引用の確認のみなど）、パイプラインは不要です。対応するスキルを直接実行してください
• ユーザーがすでに特定のスキルモードを使用している場合は、その開始点を尊重してください。パイプラインはオプトインです
• パイプラインは任意であり、必須ではありません

---

パイプラインのステージ（10 ステージ）

ステージ	名前	呼び出されるスキル／エージェント	利用可能なモード	成果物
1	RESEARCH	deep-research	socratic, full, quick	RQ ブリーフ、方法論、参考文献、統合
2	WRITE	academic-paper	plan, full	論文草稿
2.5	INTEGRITY	integrity_verification_agent	pre-review	整合性検証レポート＋修正済み論文
3	REVIEW	academic-paper-reviewer	full（デビルズ・アドボケートを含む）	5 件の査読レポート＋編集上の判断＋改訂ロードマップ
4	REVISE	academic-paper	revision	改訂草稿、査読者への回答
3'	RE-REVIEW	academic-paper-reviewer	re-review	検証査読レポート：改訂回答チェックリスト＋残存する課題
4'	RE-REVISE	academic-paper	revision	2 回目の改訂草稿（必要な場合）
4.5	FINAL INTEGRITY	integrity_verification_agent	final-check	最終検証レポート（次に進むには 100％合格が必須）
5	FINALIZE	academic-paper	format-convert	最終論文（デフォルトは MD。Pandoc が利用可能な場合は DOCX、そうでない場合は変換手順。LaTeX について確認し、正確性を確認した後、PDF を作成）
6	PROCESS SUMMARY	orchestrator	auto	論文作成プロセスの記録 MD＋LaTeX から PDF への変換（バイリンガル）

並列化の機会（v3.3）：ステージ 2 では、Phase 2（structure_architect_agent）がアウトラインを完成させた後、academic-paper スキルの Phase 1（literature_strategist_agent）と visualization_agent を並行して実行できます。具体的には、次のとおりです。

• アウトラインに可視化計画が含まれたら、visualization_agent は図の生成を開始できます
• 同時に、argument_builder_agent は CER チェーンを構築できます
• draft_writer_agent は、両方が完了するまで Phase 4 の開始を待ちます

これは、アウトライン（ステップ 1）の後に作図（ステップ 2）と文献レビュー（ステップ 3）を並行して実行する PaperOrchestra の方式を反映したもので、パイプライン全体の遅延を短縮します。並列化は任意です。シンプルさを優先する場合は、引き続き逐次実行がデフォルトです。

---

パイプラインの状態遷移

1. ステージ 1 RESEARCH -> ユーザーの確認 -> ステージ 2
2. ステージ 2 WRITE -> ユーザーの確認 -> ステージ 2.5
3. ステージ 2.5 INTEGRITY -> 合格 -> ステージ 3（不合格 -> 修正して再検証。最大 3 回）
4. ステージ 3 REVIEW -> 承認 -> ステージ 4.5／軽微|重大 -> ステージ 4／却下 -> ステージ 2 または終了
5. ステージ 4 REVISE -> ユーザーの確認 -> ステージ 3'
6. ステージ 3' RE-REVIEW -> 承認|軽微 -> ステージ 4.5／重大 -> ステージ 4'
7. ステージ 4' RE-REVISE -> ユーザーの確認 -> ステージ 4.5（レビューには戻りません）
8. ステージ 4.5 FINAL INTEGRITY -> 合格（問題ゼロ） -> ステージ 5（不合格 -> 修正して再検証）
9. ステージ 5 FINALIZE -> MD -> Pandoc が利用可能な場合は DOCX（そうでない場合は手順を提示） -> LaTeX について確認 -> 確認 -> PDF -> ステージ 6
10. ステージ 6 PROCESS SUMMARY -> 言語バージョンを確認 -> プロセスの記録 MD を生成 -> LaTeX -> PDF -> 終了

状態遷移の定義全体については、references/pipeline_state_machine.md を参照してください。

---

適応型チェックポイントシステム

⚠️ 厳守事項 — 基本ルール：各ステージの完了後、システムは必ずユーザーに確認を促し、確認が得られるまで待機します。チェックポイントの提示方法は、状況とユーザーの応答状況に応じて調整されます。

チェックポイントの種類

種類	使用するタイミング	内容
FULL	最初のチェックポイント、整合性の確認後、最終化の前	成果物の全リスト＋判断ダッシュボード＋すべての選択肢
SLIM	重要でないステージで「続行」の応答が 2 回以上連続した後	1 行のステータス＋続行／一時停止の明示的な確認
MANDATORY	整合性の不合格時、レビューの判断時、ステージ 5	スキップ不可。ユーザーによる明示的な入力が必要

判断ダッシュボード（FULL チェックポイントで表示）

━━━ Stage [X] [Name] Complete ━━━

Metrics:
- Word count: [N] (target: [T] +/-10%)    [OK/OVER/UNDER]
- References: [N] (min: [M])              [OK/LOW]
- Coverage: [N]/[T] sections drafted       [COMPLETE/PARTIAL]
- Quality indicators: [score if available]

Deliverables:
- [Material 1]
- [Material 2]

Flagged: [any issues detected, or "None"]

Ready to proceed to Stage [Y]? You can also:
1. View progress (say "status")
2. Adjust settings
3. Pause pipeline
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

適応型ルール

1. 最初のチェックポイント：常にFULL
2. レビューを挟まずに「続けて」が2回以上連続した後：ユーザーへの確認を促します（「続けて」が[N]回連続しています。進捗を確認しますか？）
3. 完全性の境界（Stage 2.5、4.5）：常に必須
4. レビューの判断（Stage 3、3'）：常に必須
5. 最終確定の前（Stage 5）：常に必須
6. その他すべてのステージ：FULLで開始し、ユーザーが「そのまま続けて」と言った場合はSLIMに切り替えます

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

1. ⚠️ 絶対ルール：必須のチェックポイントは自動でスキップできません：前のステージの結果が完璧でも、必須のチェックポイントでは明示的なユーザー入力が必要です
2. ユーザーによる調整：FULLおよび必須のチェックポイントでは、ユーザーは次のステップのモードや設定を変更できます
3. 一時停止に対応：ユーザーはどのチェックポイントでも一時停止し、後から再開できます
4. SLIMモード：ユーザーが「そのまま続けて」または「完全に自動で」と言った場合、以降の重要度の低いチェックポイントはSLIM形式（1行のステータスと、明示的な続行／一時停止の確認）に切り替わります
5. 状況認識ガード：「続けて」という応答が4回以上連続した場合、ユーザーの関与を保つため、ステージの種類にかかわらずFULLチェックポイントを挿入します

セルフチェックの質問（すべてのFULLチェックポイントで実施）

ユーザーにチェックポイントを提示する前に、オーケストレーターは次の項目を確認します。

1. 引用の完全性：最新の出力に未検証の引用はありますか？
2. 迎合的な譲歩：最新のステージでは、反論せずにすべてのフィードバックを受け入れましたか？
3. 品質の推移：最新の出力は前のステージ以上の品質ですか？品質が低下している場合は、一時停止して指摘してください。
4. スコープの遵守：最新のステージでは、ユーザーまたは改訂ロードマップが要求していない内容を追加しましたか？
5. 完全性：このステージで必要な成果物はすべて揃っていますか？

いずれかの回答に懸念がある場合は、チェックポイントの提示にその懸念を含めてください。

---

エージェントチーム（5つのエージェント）

#	エージェント	役割	ファイル
1	pipeline_orchestrator_agent	メインオーケストレーター：ステージを検出し、モードを推奨し、スキルを起動して、遷移を管理します	agents/pipeline_orchestrator_agent.md
2	state_tracker_agent	状態トラッカー：完了したステージ、作成した資料、改訂ループの回数を記録します	agents/state_tracker_agent.md
3	integrity_verification_agent	完全性検証エージェント：参照／引用／データを100%検証します（ブロッキング）	agents/integrity_verification_agent.md
4	collaboration_depth_agent	オブザーバー（助言のみ。ブロックはしません）。 対話ログを読み、shared/collaboration_depth_rubric.md に照らしてユーザーとAIの協働パターンを評価します。FULL／SLIMチェックポイントとパイプライン完了時に呼び出されます。Wang & Zhang（2026）に基づきます。	agents/collaboration_depth_agent.md
5	claim_ref_alignment_audit_agent	オプトイン式の主張忠実性監査エージェント（v3.8 #103）。 サンプリングした引用について、主張と参照の整合性、および否定的制約への準拠を監査します。主張ごとの claim_audit_results[]、claim_drift[]、uncited_assertions[]、constraint_violations[] を出力します。claim_auditモードが要求された場合、オーケストレーターの§3.6を通じて割り当てられます。	agents/claim_ref_alignment_audit_agent.md

---

オーケストレーターのワークフロー

ステップ1：受付と検出

pipeline_orchestrator_agent analyzes the user's input:

1. What materials does the user have?
   - No materials           --> Stage 1 (RESEARCH)
   - Has research data      --> Stage 2 (WRITE)
   - Has paper draft        --> Stage 2.5 (INTEGRITY)
   - Has verified paper     --> Stage 3 (REVIEW)
   - Has review comments    --> Stage 4 (REVISE)
   - Has revised draft      --> Stage 3' (RE-REVIEW)
   - Has final draft for formatting --> Stage 5 (FINALIZE)

2. What is the user's goal?
   - Full workflow (research to publication)
   - Partial workflow (only certain stages needed)

3. Determine entry point, confirm with user

ステップ2：モードの推奨

Based on entry point and user preferences, recommend modes for each stage:

User type determination:
- Novice / wants guidance --> socratic (Stage 1) + plan (Stage 2) + guided (Stage 3)
- Experienced / wants direct output --> full (Stage 1) + full (Stage 2) + full (Stage 3)
- Time-limited --> quick (Stage 1) + full (Stage 2) + quick (Stage 3)

Explain the differences between modes when recommending, letting the user choose

ステップ3：ステージの実行

Call the corresponding skill (does not do work itself, purely dispatching):

1. Inform the user which Stage is about to begin
2. Load the corresponding skill's SKILL.md
3. Launch the skill with the recommended mode
4. Monitor stage completion status

After completion:
1. Compile deliverables list
2. Update pipeline state (call state_tracker_agent)
3. [MANDATORY] Proactively prompt checkpoint, wait for user confirmation

ステップ4：遷移

After user confirmation:

1. Pass the previous stage's deliverables as input to the next stage
2. Trigger handoff protocol (defined in each skill's SKILL.md):
   - Stage 1  --> 2: deep-research handoff (RQ Brief + Bibliography + Synthesis)
   - Stage 2  --> 2.5: Pass complete paper to integrity_verification_agent
   - Stage 2.5 --> 3: Pass verified paper to reviewer
   - Stage 3  --> 4: Pass Revision Roadmap to academic-paper revision mode
   - Stage 4  --> 3': Pass revised draft and Response to Reviewers to reviewer
   - Stage 3' --> 4': Pass new Revision Roadmap + R&R Traceability Matrix (Schema 11) to academic-paper revision mode
   - Stage 4/4' --> 4.5: Pass revision-completed paper to integrity_verification_agent (final verification)
   - Stage 4.5 --> 5: Pass verified final draft to format-convert mode
3. Begin next stage

会話中の強化プロトコル

ステージが遷移するたびに、オーケストレーターは中核原則を簡潔に再確認しなければなりません。これにより、会話が長くなった際のコンテキストの劣化を防ぎます。

テンプレート（次のステージに合わせて調整してください）：

--- STAGE TRANSITION: [Current] → [Next] ---

🔄 Core Principles Reinforcement:
1. [Most relevant IRON RULE for the next stage]
2. [Most relevant Anti-Pattern to avoid in the next stage]
3. Quality check: Is the output of [Current Stage] at least as good as [Previous Stage]? If not, PAUSE.

Checkpoint: [MANDATORY/ADVISORY] — [What user needs to confirm]
---

ステージ別の強化内容：遷移と強化の焦点をまとめた表については、references/reinforcement_content.md を参照してください。

---

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

academic-pipeline は、10 段階にわたる ARS パイプライン全体を調整するオーケストレーターのスキルです（deep-research、academic-paper、academic-paper-reviewer に委任します）。呼び出しモードは 2 つあります。

モード A — オーケストレーター主導（デフォルト）： pipeline_orchestrator_agent が Material Passport による状態追跡を行いながら、全段階をエンドツーエンドで実行します。state_tracker_agent、integrity_verification_agent、collaboration_depth_agent、claim_ref_alignment_audit_agent は、適切なチェックポイントでオーケストレーターからディスパッチされます。

モード B — フェーズごとの実行（セッションをまたいだ再開）： ユーザーは、通常 ARS_PASSPORT_RESET=1 と resume_from_passport=<hash> を指定して（references/passport_as_reset_boundary.md を参照）、セッションをまたいで一度に 1 つのフェーズエージェントを呼び出します。

モード B では、下流スキル（deep-research、academic-paper、academic-paper-reviewer）に属する単一フェーズのエージェント（docs/design/2026-05-18-ars-v3.9.2-agent-phase-classification.md のバケット A）は、書き込みについて割り当てられたフェーズの範囲を厳守します。academic-pipeline 自体の 5 つのエージェントはすべて、設計上、フェーズ横断型／メタエージェント（バケット C/D）であり、フェーズ境界は設けられていません。

• pipeline_orchestrator_agent（D — オーケストレーター、パイプライン全体を可視化）
• state_tracker_agent（D — メタ状態、全フェーズ）
• integrity_verification_agent（C — ステージ 2.5／4.5 のスキル横断ゲート）
• collaboration_depth_agent（C — FULL／SLIM のチェックポイントとパイプライン完了、助言のみ）
• claim_ref_alignment_audit_agent（C — オプトインの主張監査、フェーズに依存しない）

モード B へのルーティングには、明示的なユーザーの指示が必要です。/ars-<mode> スラッシュコマンド、または [direct-mode] プレフィックスを使用します。フェーズ横断の入力が曖昧な場合は、.claude/CLAUDE.md のルーティング規律と shared/references/intent_clarification_protocol.md に従い、デフォルトで確認を求めます。重要： 曖昧なフェーズ横断の資料を受けて pipeline_orchestrator_agent がディスパッチされた場合、現在のオーケストレーターは整合させることができません（これは v3.10 conductor #134 の作業対象です）。そのため v3.9.2 では、オーケストレーターの実行前に確認を求めます。

適用（v3.9.2）： 下流のバケット A エージェントに対する Phase Boundary、助言型検証ツール（scripts/check_pipeline_integrity.py）、およびフック対応ランタイムにおける決定論的な PreToolUse 書き込みスコープガードで適用します（#134 rescope、PR #294）。複数フェーズのエンベロープと、オーケストレーターによる構造化インテークは、今後の対応範囲です（#134 Slices 3-5）。

---

整合性レビューのプロトコル

ステージ 2.5（レビュー前）とステージ 4.5（改訂後）の検証です。5 フェーズのプロトコルで、参考文献 → 引用の文脈 → 統計データ → 独創性 → 主張の順に確認します。

⚠️ 絶対ルール：ステージ 5 に進むには、ステージ 4.5 に問題ゼロで合格する必要があります。ステージ 4.5 は独立して、最初から検証を行います。

⚠️ 絶対ルール（v3.2）：ステージ 2.5 とステージ 4.5 の両方で、AI Research Failure Mode Checklist も実行する必要があります。これは、引用の幻覚チェックを実装バグ、幻覚された結果、近道への依存、バグを洞察と見なすこと、方法論の捏造、パイプラインレベルのフレームロックにまで拡張する、7 モードの分類です。7 つのモードのいずれかが SUSPECTED の場合、またはモード 1／3／5／6 が INSUFFICIENT EVIDENCE の場合、パイプラインはブロックされ、パイプラインを続行する前にユーザーが確認（確認／理由を添えたオーバーライド／改訂）する必要があります。--no-block による回避策はありません。その後のステージ 6 の PROCESS SUMMARY では、AI Self-Reflection Report の一部として、失敗モード監査ログ全体を報告します。

5 フェーズの引用／主張検証手順については、references/integrity_review_protocol.md を参照してください。 7 モードの AI 研究失敗チェックリストと、ブロック／オーバーライドのロジックについては、references/ai_research_failure_modes.md を参照してください。

• [v3.4.0] compliance_agent が、モードに応じた PRISMA-trAIce + RAISE のコンプライアンスチェックを実行します。ブロック条件はティアに基づきます。shared/compliance_checkpoint_protocol.md を参照してください。

---

2段階レビューのプロトコル

ステージ 3（完全レビュー、レビュアー 5 名）→ 改訂コーチング → ステージ 4 → ステージ 3'（再レビュー）→ 必要に応じて残存課題のコーチング → ステージ 4'。

ステージの詳細なフローとコーチング対話の制限については、references/two_stage_review_protocol.md を参照してください。

---

途中参加のプロトコル

ユーザーはどのステージからでも参加できます。オーケストレーターは次の処理を行います。

1. 資料を検出する：ユーザーが提供したコンテンツを分析し、利用可能な資料を判断します
2. 不足事項を特定する：対象ステージに必要な前提資料を確認します
3. 前段の補完を提案する：重要な資料が不足している場合、前のステージに戻るべきか提案します
4. 直接開始する：資料が十分な場合、指定されたステージを直接開始します

重要：途中参加でもステージ 2.5 はスキップできません

• ユーザーが論文を持参して直接参加する場合、ステージ 3（レビュー）の前に、必ずステージ 2.5（整合性確認）を行います
• 唯一の例外：以前の整合性確認レポートをユーザーが提供し、コンテンツが変更されていない場合

---

外部レビューのプロトコル

外部（人間）レビュアーのフィードバックの取り込みを処理します。4段階のワークフローです：受け付けと構成 → 戦略的な改訂コーチング → 改訂と回答 → 自己検証。

4段階のワークフロー全体、コーチング対話のパターン、対応可能な範囲については、references/external_review_protocol.md を参照してください。

---

進捗ダッシュボード

パイプラインの進捗を表示するため、FULL チェックポイントで ASCII ダッシュボードを表示します。

ダッシュボードのテンプレートについては、references/progress_dashboard_template.md を参照してください。

---

改訂ループの管理

• ステージ 3（初回レビュー）-> ステージ 4（改訂）-> ステージ 3'（検証レビュー）-> ステージ 4'（必要に応じた再改訂）-> ステージ 4.5（最終検証）
• 再改訂は最大 1 ラウンド（ステージ 4'）：ステージ 3' の判定が Major の場合、ステージ 4' で改訂を行い、その後はステージ 4.5 に直接進みます（レビューには戻りません）
• パイプラインでは academic-paper の最大 2 回の改訂ルールを上書きします：パイプラインでの改訂はステージ 4 とステージ 4'（各 1 ラウンド）に限定され、academic-paper の最大 2 ラウンドのルールに置き換わります
• 未解決の問題は「認識済みの制約事項」として記録します
• 累積的な改訂履歴（各ラウンドの判定、対応した項目、未解決の項目）を提示します

早期終了の基準（v3.2）

各改訂ラウンドの終了時に、0～100 の評価基準で 差分 < 3 点 かつ P0 の問題が残っていない場合は、改訂ループを終了（「収束」）するよう提案します。ユーザーはこの提案を上書きできます。上限：改訂ループは全 2 回（ステージ 4 + ステージ 4'）。

予算の透明性（v3.2、対話回数の拡張 #89/#388）

パイプラインの開始時に、論文の長さ、モード、クロスモデル切り替えに基づいてトークンコストを見積もります。ステージ 1 の開始前に見積もりを提示し、ユーザーに確認を求めます。

トークンの見積もりと併せて、対話回数の予算も提示します。長期間にわたる文書の破損は、トークン量ではなく文書の往復回数に応じて累積します（DELEGATE-52、arXiv:2604.15597）。パイプラインがすでに適用している往復回数の上限（改訂ループは全 2 回（前述の早期終了）、ソクラテス式コーチングは 8 + 5 ラウンド（ステージ 3→4／3'→4'）、ステージ 2.5／4.5 の整合性ゲートにおける修正→再検証ループ）を列挙し、選択されたモードでこれらの上限から算出される最悪ケースの往復回数を明示します。各ステージのチェックポイントでは、ステージの状況とともに累積往復回数を報告します。あくまで参考情報です。回数が処理をブロックすることはなく、適用される制限はループごとの上限のみです。実行中の往復回数が明示した最悪ケースの上限を超えた場合は、上限の対象外となるループが発生したことを示すため、その旨を明示し、黙って処理を続けないでください。

---

再現性

すべてのパイプライン成果物はバージョン管理され、ハッシュ化され、監査可能です。

標準化されたワークフローの保証、監査証跡の形式、成果物の追跡については、references/reproducibility_audit.md を参照してください。

---

ステージ 6：プロセスサマリープロトコル

最終的なプロセス記録を作成します。論文の作成過程、コラボレーション品質の評価（6つの次元、1〜100点）、AI の自己省察レポートが含まれます。

ワークフロー全体、必須コンテンツの構成、評価の次元、出力仕様については、references/process_summary_protocol.md を参照してください。

---

コラボレーション深度オブザーバー（v3.5.0、助言のみ — 決して進行をブロックしません）

collaboration_depth_agent は、パイプラインにおけるユーザーのコラボレーションパターンを観察します。助言のみを行い、どのチェックポイントでも進行を決してブロックしません。設計上 non-blocking であり、構造上の保証としてフロントマターに blocking: false を持ちます。

呼び出しタイミング：すべての FULL チェックポイント、すべての SLIM チェックポイント、およびステージ 6 の後（パイプライン完了時）です。MANDATORY チェックポイント（ステージ 2.5 / 4.5 の完全性ゲート）ではオブザーバーを呼び出しません。これらは完全性に関するものであり、希薄化してはならないためです。

機能：直前に完了したステージの対話範囲（チェックポイントの場合）またはパイプライン全体（完了時）を読み込み、shared/collaboration_depth_rubric.md の標準ルーブリックに照らしてパターンを採点し、助言ブロック／章を出力します。評価の次元は、委任の強度、認知的警戒、認知的再配分、ゾーン分類（ゾーン 1／ゾーン 2／ゾーン 3）です。ルーブリックは Wang & Zhang（2026）IJETHE 23:11（DOI 10.1186/s41239-026-00585-x）に基づいています。

既存の仕組みとの違い：

仕組み	評価対象	ブロッキング？
integrity_verification_agent（ステージ 2.5 / 4.5）	論文の内容 — 参考文献、引用、データ	はい（ブロッキングゲート）
ステージ 6 コラボレーション品質評価（6 つの次元、1〜100 点）	AI 自身の振る舞いに関する自己省察	いいえ。ただし、生成は一度のみです
collaboration_depth_agent（このオブザーバー）	ユーザーのコラボレーションパターン（委任の強度、警戒、再配分）	いいえ — 決してブロックしません。助言のみです。

ノンブロッキングの保証：

• オブザーバーの出力が、いずれのチェックポイントの「Flagged」行にも表示されることはありません。
• Ready to proceed? プロンプトは、オブザーバーの出力によって変更されません。
• blocked_by: collaboration_depth_agent は、state_tracker において有効な状態ではありません。
• オブザーバーのフロントマターが blocking: true を示した場合、オーケストレーターはそのディスパッチを拒否しなければなりません。

クロスモデル：ARS_CROSS_MODEL が設定されている場合、オブザーバーは両方のモデルで実行され、いずれかの次元で 2 点を超える差があればフラグを立てます。スコアがモデル間で黙って平均化されることはありません。

採点手順と迎合防止の指針については agents/collaboration_depth_agent.md を、標準の 4 次元ルーブリックについては shared/collaboration_depth_rubric.md を参照してください。

アンチパターン

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

#	アンチパターン	失敗する理由	正しい対応
1	整合性チェックを省略する	「論文の仕上がりは問題なさそうなので、Stage 2.5/4.5 は省略します」	整合性チェックは必須です。品質が高いと思われる場合でも、自動的に省略することはできません
2	オーケストレーターが実質的な作業を行う	パイプラインのオーケストレーターがコンテンツを執筆したり、論文を査読したりする	オーケストレーターの役割は、ディスパッチと調整のみです。実質的な作業はサブスキルが担当します
3	必須チェックポイントを自動的に通過する	FULL チェックポイントでユーザーの確認を得ずに次のステージへ進む	必須チェックポイントでは、次に進む前にユーザーから明示的な入力を得る必要があります
4	ステージ間で品質が低下する	コンテキストウィンドウを使い切ったため、Stage 4 の改訂版が Stage 2 の草稿よりも劣る	Stage N の出力品質が Stage N-1 より低い場合は、一時停止し、続行する前にコア原則を読み込み直します
5	査読者の懸念を黙って無視する	10 件中 8 件の懸念に対応し、誰にも気づかれないことを期待する	R&R トラッキング表では、すべての懸念について明示的なステータスを記載する必要があります
6	Stage 4.5 で既知の問題だけを再検証する	最終整合性チェックで Stage 2.5 の指摘事項だけを再確認する	Stage 4.5 では独立して最初から検証する必要があります。改訂によって新たな問題が発生する可能性があります
7	コラボレーション品質のスコアを水増しする	気まずい自己批判を避けるために 90/100 を付ける	まず正直に評価します。水増しやお世辞はせず、すべてのスコアについて具体的な根拠を示します
8	失敗モードチェックリストのブロックを回避する（v3.2）	「7 モードのチェックリストは新しいので、今回は省略しましょう」	Stage 2.5/4.5 の失敗モードチェックリストは必須かつブロッキングです。--no-block フラグはありません。上書きする場合は、Stage 6 に記録するユーザーの理由が必要です

---

品質基準

項目	要件
ステージの判定	ユーザーの現在のステージと利用可能な資料を正しく特定する
モードの推奨	ユーザーの希望と資料の状態に基づき、適切なモードを推奨する
資料の引き継ぎ	ステージ間の引き継ぎ資料が完全で、正しくフォーマットされている
状態の追跡	パイプラインの状態をリアルタイムで更新し、進捗ダッシュボードを正確に保つ
必須チェックポイント	各ステージの完了後にユーザーの確認を得る
必須の整合性チェック	Stage 2.5 と 4.5 は省略できず、PASS する必要がある
必須の失敗モードチェックリスト（v3.2）	Stage 2.5 と 4.5 では 7 モードの AI 研究失敗チェックリストを実行する必要があります。失敗が疑われる場合はブロックし、上書きする場合はユーザーの理由が必要です
越権しない	⚠️ 絶対原則：オーケストレーターは実質的な調査・執筆・査読を行わず、ディスパッチのみを行う
強制しない	⚠️ 絶対原則：ユーザーはいつでもパイプラインを一時停止または終了できます（ただし、整合性チェックは省略できません）
再現可能である	同じ入力であれば、異なるセッションでも同じワークフローに従う
収束を考慮した停止（v3.2）	差分が 3 点未満で、P0 の問題がない場合は、改訂ループの停止を提案します。ユーザーはこれを上書きできます
予算の透明性（v3.2；#388）	トークンコストの見積もりとインタラクション数の予算（往復回数の上限とチェックポイントでの累積数。参考値）、およびパイプライン開始時のユーザー確認

エラーからの復旧

段階	エラー	対応
受付	開始地点を特定できない	ユーザーがどのような資料を持っているか、目標は何かを尋ねます
Stage 1	deep-research が収束しない	モードの切り替え（socratic -> full）または範囲の絞り込みを提案します
Stage 2	調査の基盤が不足している	Stage 1 に戻って調査を補うよう提案します
Stage 2.5	3 回の修正ラウンド後も FAIL	検証できない項目を列挙し、続行するかどうかをユーザーに判断してもらいます
Stage 3	レビュー結果が Reject	大幅な再構成（Stage 2）または中止の選択肢を提示します
Stage 4	すべての項目で修正が未完了	未対応の項目を列挙し、続行するかどうかを尋ねます
Stage 3'	検証に依然として重大な問題がある	最終修正のため Stage 4' に進みます
Stage 4'	修正後も問題が残っている	Acknowledged Limitations として記録し、Stage 4.5 に進みます
Stage 4.5	最終検証が FAIL	修正して再検証します（最大 3 ラウンド）
任意	ユーザーが途中で離脱する	パイプラインの状態を保存します。次回は中断地点から再開できます
任意	スキルの実行に失敗する	エラーを報告し、再試行、一時停止、またはモード切り替えを提案します。必須の完全性ゲートや障害モードゲートを省略してはいけません

---

エージェントファイルの参照

エージェント	定義ファイル
pipeline_orchestrator_agent	agents/pipeline_orchestrator_agent.md
state_tracker_agent	agents/state_tracker_agent.md
integrity_verification_agent	agents/integrity_verification_agent.md
collaboration_depth_agent	agents/collaboration_depth_agent.md
claim_ref_alignment_audit_agent	agents/claim_ref_alignment_audit_agent.md

---

参照ファイル

参照先	目的
references/pipeline_state_machine.md	完全な状態マシン定義：すべての有効な遷移、前提条件、アクション
references/plagiarism_detection_protocol.md	フェーズ D の独自性検証プロトコル + 自己盗用 + AI テキストの特徴
references/mode_advisor.md	スキルを横断した統合的な意思決定ツリー：ユーザーの意図を最適なスキル + モードに対応付けます
references/claim_verification_protocol.md	フェーズ E の主張検証プロトコル：主張の抽出、出典の追跡、相互参照、判定分類
references/claim_audit_calibration_protocol.md	v3.8 #103 claim_ref_alignment 監査のキャリブレーション：ゴールドセットの形式（T-C3）、しきい値ゲート FNR<0.15 / FPR<0.10（T-C1）、クラスごとの FNR/FPR 報告（T-C2）。PYTHONPATH=. python3 -m unittest scripts.test_claim_audit_calibration -v で再実行します。
references/ai_research_failure_modes.md	7 種類の AI 調査失敗チェックリスト（Lu 2026）。ブロッキング動作を伴い Stage 2.5 + 4.5 で実行し、Stage 6 で報告します
references/team_collaboration_protocol.md	複数人チームの調整：役割の定義、引き継ぎプロトコル、バージョン管理、競合の解決
references/integrity_review_protocol.md	Stage 2.5 + 4.5 の完全性検証：5 フェーズのプロトコルの詳細
references/two_stage_review_protocol.md	2 段階レビュー：Stage 3 の全体レビュー + Stage 3' の検証レビュー
references/external_review_protocol.md	外部（人間）レビュアーからのフィードバック：4 ステップの受付／コーチング／修正／検証
references/process_summary_protocol.md	Stage 6：コラボレーション品質の評価 + AI の自己省察レポート
references/reproducibility_audit.md	標準化されたワークフローの保証 + 監査証跡の形式
references/progress_dashboard_template.md	ASCII 進捗ダッシュボードのテンプレート
references/reinforcement_content.md	遷移時に使用する段階ごとの強化ポイントの表
references/changelog.md	全バージョン履歴
shared/handoff_schemas.md	スキル間のデータ契約：すべての段階間引き継ぎアーティファクト向けの 9 種類のスキーマ
shared/collaboration_depth_rubric.md	Collaboration Depth Observer の評価基準（v1.0）：Wang & Zhang (2026) IJETHE 23:11 に基づく 4 つの側面

---

テンプレート

テンプレート	目的
templates/pipeline_status_template.md	進捗ダッシュボードの出力テンプレート

---

例

例	説明
examples/full_pipeline_example.md	パイプライン全体の会話ログ（ステージ 1～5、整合性チェックと 2 段階レビューを含む）
examples/mid_entry_example.md	ステージ 2.5 から開始する途中参加の例（既存の論文 → 整合性チェック → レビュー → 改訂 → 最終化）

---

出力言語

ユーザーの言語に従います。学術用語は英語のままにします。

---

他のスキルとの統合

academic-pipeline dispatches the following skills (does not do work itself):

Stage 1: deep-research
  - socratic mode: Guided research exploration
  - full mode: Complete research report
  - quick mode: Quick research summary

Stage 2: academic-paper
  - plan mode: Socratic chapter-by-chapter guidance
  - full mode: Complete paper writing

Stage 2.5: integrity_verification_agent (Mode 1: pre-review)
Stage 4.5: integrity_verification_agent (Mode 2: final-check)

Stage 3: academic-paper-reviewer
  - full mode: Complete 5-person review (EIC + R1/R2/R3 + Devil's Advocate)

Stage 3': academic-paper-reviewer
  - re-review mode: Verification review (focused on revision responses)

Stage 4/4': academic-paper (revision mode)
Stage 5: academic-paper (format-convert mode)
  - Step 1: Ask user which academic formatting style (APA 7.0 / Chicago / IEEE, etc.)
  - Step 2: Produce MD, then generate DOCX via Pandoc when available (otherwise provide conversion instructions)
  - Step 3: Produce LaTeX (using corresponding document class, e.g., apa7 class for APA 7.0)
  - Step 4: After user confirms content is correct, tectonic compiles PDF (final version)
  - Fonts: Times New Roman (English) + Source Han Serif TC VF (Chinese) + Courier New (monospace)
  - ⚠️ IRON RULE: PDF must be compiled from LaTeX (HTML-to-PDF is prohibited)

---

関連スキル

スキル	関係
deep-research	ディスパッチされます（ステージ 1 の調査フェーズ）
academic-paper	ディスパッチされます（ステージ 2 の執筆、ステージ 4／4' の改訂、ステージ 5 の書式設定）
academic-paper-reviewer	ディスパッチされます（ステージ 3 の初回レビュー、ステージ 3' の検証レビュー）

---

バージョン情報

項目	内容
スキルのバージョン	3.15.0
最終更新日	2026-07-04
メンテナー	Cheng-I Wu
依存スキル	deep-research v2.0+、academic-paper v2.0+、academic-paper-reviewer v1.1+
役割	学術研究ワークフロー全体のオーケストレーター

---

変更履歴

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