1. 研究執筆プロセスの再構築：AI 標準化スキルの導入

大規模な学術論文、特に博士課程の論文執筆において、情報管理の複雑さは主要なボトルネックとなります。複数のデータベースから入手した PDF 文献の整理、断片的なメモの統合、そして執筆途中での文献参照の困難さは、研究者の認知負荷を高め、創造的な執筆フローを阻害します。

この課題に対処するため、「学術執筆エージェントキット」と呼ばれる構造化されたスキルセットが注目されています。これは単なる文章生成ツールではなく、文献読解から原稿出力までの全プロセスを 8 つの標準化されたエージェントスキルに分解したシステムです。AI を単なる指示待ちの助手ではなく、標準操作手順（SOP）を理解した共同研究者として機能させることが目的です。

本システムの核となるのは「データ契約」と呼ばれる標準化されたノートファイル形式です。全てのスキルがこの形式に基づいてデータの読み書きを行うことで、情報の欠落や整合性の不備を防ぎます。以下では、このワークフローの設計思想、具体的なスキル構成、および実装における設定要点について解説します。

2. アーキテクチャ設計：パイプラインとデータスキーマ

本ツールキットの設計哲学は、従来のアドホックな AI 利用における非効率性を解消することにあります。主要な設計原則は「プロセスのパイプライン化」と「データ構造の標準化」の 2 点に集約されます。

2.1 構造化されたスキルパイプライン

従来の AI 利用では、プロンプトの質や出力形式がセッションごとにバラつきが生じがちです。本システムでは、以下の順序でデータが流れるパイプラインを定義しています。

/analyze → /record → /visualize → /compose → /check → /output

補助スキルとして /factcheck と /status が存在します。各スキルは単一責任の原則に基づいて設計されており、例えば /analyze は PDF の構造化解析のみを行い、/record はその結果を固定フォーマットで保存します。これにより、プロジェクトの初期段階でも終盤でも、AI とのインタラクション方法が一貫性を保ちます。

注記：このパイプラインは厳密な直列処理を意味するものではありません。実務では反復的な運用が可能です。例えば、/visualize で文献のカバレッジ不足を発見した場合、再度 /analyze に戻って特定の文献を深掘りし、/record でノートを更新するといった循環作業が行われます。

2.2 統一ノートフォーマット：データ契約

スキル間での連携を支えるのが、強制された Markdown テンプレートです。特に重要なのが「研究マッピングテーブル」と呼ばれる字段です。

主要なフィールドは以下の通りです：

1. State（状態）：processing または finalized。/status スキルによる進捗管理の基準となります。
2. Relevance（関連性）：論文のどの章や節与该文献が関連するかを明示します。
3. Mapping Table（マッピング表）：システムの中枢となるテーブルです。各ノートポイントが論文のどの構成要素に使用されるかを定義します。

| Content Point | Target Chapter | Target Section | Relation Type |
|---------------|----------------|----------------|---------------|
| 技術的決定論の批判 | Ch2 | S2.3 | 反論 (refutes) |
| 社会構成主義的アプローチ | Ch4 | S4.1 | 支援 (supports) |

このテーブルにより、個々のメモが論文の全体構造にアンカーされます。/visualize スキルはこのテーブルを集約して文献 - 章マトリクスを生成し、/compose スキルはこれに基づいて特定の章節に内容を自動配置します。

3. 主要スキルの機能と実装詳細

設計概念を理解した上で、各スキールの具体的な動作と設定ポイントを確認します。

3.1 /analyze：構造化文献解析

文献処理の起点となるスキルです。単なる要約ではなく、構造化された抽出を行います。

操作手順：プロジェクトルートで /analyze を入力し、PDF パス（例：docs/papers/theory_review.pdf）を指定します。

出力構成：

• 要約：全体概要
• 主要主張：中心的な論点
• 定義用語：キーコンセプト
• 研究方法：使用された手法
• 研究への寄与：自論文との関連性推論
• 引用候補：ページ番号付きの重要抜粋

設定_tip：一度に処理するページ数が多いと精度が低下します。設定ファイルで PAGE_LIMIT_PER_CALL を 10 ページ程度に制限することをお勧めします。長文文献の場合は、-r 1-10 のように範囲を指定して複数回実行します。

3.2 /record：標準化ノート保存

/analyze の出力を一時的なチャット履歴から永続的なストレージへ移行します。

動作：/analyze 実行後に /record を入力すると、解析結果が docs/notes/ ディレクトリ配下に Markdown ファイルとして保存されます。

重要タスク：この段階で「マッピング表」の記入を完了させる必要があります。文献の内容が新鮮なうちに、どの章節でどのように使用するかを決定します。

命名規則：Author_Year_Topic.md 形式（例：Smith_2022_AI_Ethics.md）を推奨します。状態は初期値 processing から、完了時に finalized へ手動変更します。

3.3 /factcheck：事実検証支援

学術的厳密性を保つための補助ツールです。

用途：文献内のデータや主張に対して疑義がある場合、テキストを選択して /factcheck を実行します。エージェントが Web 検索を行い、情報の妥当性を検証します。

警告：この機能はあくまで予備調査です。正式な引用には査読付き論文などの一次ソースを必ず参照してください。背景情報や日付の確認などに限定して利用するのが安全です。

3.4 /visualize：文献 - 章節マトリクス生成

多数の文献を管理下における全体把握を支援します。

機能：docs/notes/ 内の全ファイルからマッピング表を収集し、集約テーブルを生成します。

活用メリット：

• 章節ごとの文献密度の確認（引用の偏り検出）
• 主要文献の使用頻度分析（理論的支柱の特定）
• 論調のバランス確認（支援・反論・拡張の分布）

執筆中期と終盤に実行し、文献収集の方向性調整や構成のバランス確認に利用します。

3.5 /compose：自動原稿統合

分散したノートを章節ドラフトへ統合するコア機能です。

処理フロー：対象章節（例：Ch2）を指定すると、エージェントは以下の処理を行います。

1. 全ノートから Target Chapter が一致する項目を抽出。
2. Target Section ごとにグルーピング。
3. 該当する docs/drafts/ch02.md の適宜箇所へ内容を挿入。

これにより、ゼロから執筆するのではなく、素材が配置された状態から編集・深化作業を開始できます。

注意点：出力はあくまでドラフトです。文脈の接続や論理の飛躍については人間による修正が必須です。最終稿として直接使用しないでください。

3.6 /check：整合性監査

論文全体の一貫性を自動検証します。

検証項目：

• 用語の統一性（同一概念に対する表記ゆれ）
• 引用フォーマットの統一
• 相互参照の整合性（「第 5 章参照」などの記述と実体の一致）
• 論理矛盾の検出（_semantic analysis_ based）

最終推敲段階で、人的ミスによる不整合を洗い出すために有効です。

3.7 /status：進捗ダッシュボード

執筆モチベーション維持のための可視化ツールです。

表示内容：

• 文献処理状況：finalized 数 vs 総数
• 章節執筆状況：現在字数 vs 目標字数
• 全体進捗率

設定ファイルで目標字数を定義しておくことで、正確な進捗率が算出されます。

3.8 /output：形式変換とパッケージ化

最終成果物の出力を自動化します。

機能：docs/drafts/ 内の Markdown ファイルを Word 形式（.docx）へ変換し、関連ファイルを含めて ZIP アーカイブを作成します。

技術要件：内部で pandoc などの変換ツールを使用するため、環境へのインストールが必要です。出力後は Word 上で数式や図表のレイアウト確認を行ってください。

4. 環境構築と設定実務

本ワークフローは複数の AI コーディングアシスタントプラットフォームで動作しますが、機能サポートに差異があります。

4.1 プラットフォーム選定

プラットフォーム	スキル対応	設定ファイル	推奨用途
Claude Code	全 8 スキル対応	CLAUDE.md	大規模プロジェクト向け。自動認識機能により設定が最小限で済む。
Codex CLI / Gemini CLI	全 8 スキル対応	AGENTS.md / GEMINI.md	ターミナル操作を好む開発者向け。スクリプト連携に適する。
Cursor	ルールのみ対応	.cursor/rules/	編集機能重視。スキル命令は CLI エージェントとの併用が必要。
VS Code Copilot	要手動設定	スキルディレクトリ手動配置	既存 VS Code 環境を維持したい場合。

学術執筆のような長期プロジェクトでは、スキル統合が最もスムーズな Claude Code の利用が推奨されます。

4.2 初期設定とカスタマイズ

Claude Code を使用した場合の初期設定手順です。

ステップ 1：リポジトリの取得

# プロジェクトディレクトリとしてクローン
git clone <repository_url> thesis_project
cd thesis_project
# IDE 拡張機能経由でエージェントを起動

起動時に CLAUDE.md およびスキル定義ディレクトリが自動読み込みされます。

ステップ 2：設定ファイルの編集

CLAUDE.md を開き、プロジェクト固有のパラメータ进行调整します。

1. 目標字数の設定：## Goals セクションで定義します。

## Goals
- Total word count target: 55000

| Chapter | Title | Target Words |
|---------|-------|-------------|
| Ch1 | Introduction | 4500 |
| Ch2 | Background | 12000 |
| Ch3 | Methods | 9000 |
| Ch4 | Results | 18000 |
| Ch5 | Conclusion | 3500 |

2. 処理制限の調整：## Limits セクションでリソース制御を行います。

## Limits
- PAGE_LIMIT_PER_CALL: 10 # 1 コマンドあたりの最大ページ数
- SESSION_PAGE_CAP: 50 # 1 セッションあたりの累計上限

3. ディレクトリ構造の確認：必要に応じてパスを変更します。

## Paths
- Drafts: `docs/drafts/`
- Papers: `docs/papers/`
- Notes: `docs/notes/`
- Dist: `build/output/`

ステップ 3：ディレクトリ構成

初期化後の構造は以下のようになります。実作業は docs/papers/ と docs/drafts/ が中心となります。

thesis_project/
├── .claude/ # エージェント設定（自動）
├── docs/
│   ├── drafts/ # 章節ドラフト
│   │   ├── ch01.md
│   │   └── ...
│   ├── papers/ # 元文献 PDF
│   └── notes/ # 標準化ノート
│       └── _template.md
├── build/ # 出力用
├── CLAUDE.md # 主設定
└── README.md

5. 実践ワークフロー：章節作成の事例

具体的な運用例として、第三章（手法論）の作成プロセスを追います。

手順 1：解析と記録（/analyze + /record）

文献 docs/papers/qualitative_method_2020.pdf を処理します。

1. /analyze -r 1-10 で最初の 10 ページを解析。
2. 続けて /record を実行し、docs/notes/Qualitative_Method_2020.md を生成。
3. マッピング表に以下のように記入：

Content Point	Target Chapter	Target Section	Relation Type
半構造化インタビューの実施手順	Ch3	S3.1	支援 (supports)

手順 2：現状可視化（/visualize）

複数の文献ノート作成後に実行。Ch3 の S3.2（データ分析）に関する文献が少ないことが判明した場合、追加収集の指標とします。

手順 3：草稿生成（/compose）

/compose Ch3 を実行。エージェントは該当するノートを docs/drafts/ch03.md の S3.1 付近に配置します。

手順 4：人間による編集

生成されたテキストを基に、論理の接続詞を修正し、批判的考察を追加します。引用フォーマットを整え、学術的な文体へ統一します。

手順 5：最終確認（/check + /status）

用語の統一性を検証し、進捗ダッシュボードで字数目標への到達度を確認します。

6. トラブルシューティングと最適化

運用中に発生しうる問題とその対処法です。

6.1 コマンドが認識されない

• 原因：対応していないプラットフォームの使用、または設定ファイルの読み込み失敗。
• 対策：Claude Code など正式サポート環境か確認。CLAUDE.md がルートにあるか確認。セッションを再起動。

6.2 解析精度が低い

• 原因：一度に処理する情報量が過多。
• 対策：PAGE_LIMIT_PER_CALL を 5 ページ程度に低下させる。特定のセクションに焦点を当てるようプロンプトで指示を追加する。

6.3 統合後の文章が不自然

• 原因：ノート情報の断片化。
• 対策：/record 段階で「Content Point」を単なるキーワードではなく、文脈を含めた完整な文で記述する。章節全体ではなく、節単位（例：S3.1）で統合を実行する。

6.4 ファイル管理の複雑化

• 原因：ノートファイル数の増大。
• 対策：命名規則を厳守。Status フィールドを活用して未完了ファイルをフィルタリング。文献数が 50 を超える場合、notes/ 内にサブディレクトリを作成し、設定ファイルの検索パスを docs/notes/**/*.md へ変更する。

6.5 字数統計の不一致

• 原因：Markdown 原文字数と Word 組版字数の算出アルゴリズム差異。
• 対策：進捗管理は相対的な増加トレンドとして捉える。提出時には Word の公式統計を基準とする。

6.6 複数環境での同期

• 対策：プロジェクト全体を Git でバージョン管理することを強く推奨します。

git init
git add .
git commit -m "Init thesis structure"
git remote add origin <remote_url>
git push -u origin main

これにより、異なるデバイス間での作業継続と履歴管理が可能になります。build/output/ などの一時ファイルは .gitignore で除外してください。