AIに論文を書かせる前に、品質ゲートを作る——Scholarly Agent Skillsの設計思想
AIを使えば、論文らしい文章を短時間で生成できる。
しかし、文章が流暢であることと、論文として検証可能であることは同じではない。引用した論文を本当に読んだのか。数字の出所を再確認できるか。反対説を見落としていないか。AIが提案した結論を、人間が根拠とともに説明できるか。
私が公開している「Scholarly Agent Skills」は、この問題を「もっと性能の高いAIを使うこと」ではなく、研究と執筆の工程を設計することで扱おうとするオープンソースのスキル・ルール・検査ツール集である。
一言で表すなら、ソフトウェア開発の品質規範を論文執筆へ移植する試みだ。
「AIに論文を書かせる」ためのプロンプト集ではない
このリポジトリの副題は、Thesis-Driven Developmentである。
ソフトウェア開発では、要求を定義し、概念をモデル化し、テストを書き、変更をレビューし、リリース前に品質ゲートを通す。複雑なシステムを、実装者の記憶と注意力だけに頼って作ることはしない。
ところがAIを使った論文執筆では、「テーマを渡して本文を生成する」という一回の対話に、研究計画、概念定義、文献調査、引用確認、反論検討、文章化をまとめて押し込んでしまいがちである。その結果、もっともらしい文章はできても、どの主張がどの資料に支えられているか分からなくなる。
Scholarly Agent Skillsが目指すのは、優れた一つのプロンプトではない。研究を複数の工程と成果物に分け、AIと人間がどこで何を確認したかをリポジトリへ残すことである。
開発の規律を、研究の規律へ読み替える
中心にあるのは、次の対応関係である。
| ソフトウェア開発 | 研究・論文執筆への読み替え |
|---|---|
| 要求定義 | 研究問い、想定読者、完成条件を先に決める |
| DDD・ユビキタス言語 | 中核概念を定義し、論文内の意味を揃える |
| 仕様ギャップ分析 | 先行研究の到達点と自説の差分を明示する |
| TDD | 本文の前に想定反論と反例を書く |
| 不変条件監査 | 主張と一次資料の対応をゲート判定する |
| 静的解析 | 引用、用語、章番号、内部記号の露出を検査する |
| リリースゲート | 投稿前のWARNとFAILを著者が仕分ける |
| セッションハンドオーバー | 長期執筆の文脈と未解決事項を次回へ残す |
たとえばcounter-argument-tddでは、節を書き始める前に、査読者が提起しそうな反論を列挙する。TDDで最初に失敗するテストを書くように、まだ防御できていない主張を先に可視化する。その反論を乗り越える本文を書き、最後に論理と文体を整理する。
scholarly-concept-modelingでは、DDDのユビキタス言語に相当する概念インベントリを作る。同じ用語を章ごとに違う意味で使ったり、近い概念を無意識に混同したりすることを防ぐ。
開発手法の用語を論文本文へ持ち込むことが目的ではない。これらは内部の設計工程であり、公開原稿には通常の学術的な文章だけを残す。
文章ではなく、4層の品質基盤として作る
このプロジェクトは、概ね四つの層で構成される。
1. ルール層——守るべき不変条件
ルールは、個別の作業を超えて常に守る制約である。
代表例が「ファクト・グラウンディングルール」である。このルールでは、LLMの記憶や検索結果のスニペットだけを根拠に、学術文献の内容、統計値、固有の事実を本文へ書かない。
文献検索は候補を見つけるDiscoveryにすぎない。論文の内容を引用するには、利用権を確認したPDFやオープンアクセス全文を取得して構造化するか、入手できない資料ならページ番号付きの手動ノートを作る。統計値は公式資料やAPIから取得し、原数値と算式を残す。
つまり「AIが知っている」から「リポジトリ内の資料で再確認できる」へ、根拠の状態を変える。
2. スキル層——作業の手順と受け渡し
スキルは、発動する場面、前提、手順、成果物を定義する。
2026年8月27日時点で、日本語版と英語版にそれぞれ23スキルがある。ただし、最初からすべてを使う必要はない。基本的な流れは次のとおりである。
research-plan-workshopで研究問いを一文にするscholarly-concept-modelingで中核概念を定義するliterature-searchで候補を探すsource-criticism-gateで情報源を評価するpdf-paper-ingestionで一次資料を実体化するliterature-gap-analysisで先行研究との差分を整理するcounter-argument-tddで反論を先に置くclaim-evidence-gateとcitation-traceability-auditで主張と出典を監査する- 可読性、用語、センシティブ表現のゲートを通す
pre-submission-triageで残った警告を著者が判断する
全体像は日本語版スキルカタログにまとめている。
3. スクリプト層——決定論的に検査できる部分
LLMによるレビューは柔軟だが、同じ入力に常に同じ判定を返すとは限らない。そこで、機械的に検出できる問題はPythonスクリプトへ分離している。
たとえば、本文中の根拠不明な数値候補、引用と文献ノートの不一致、用語の表記揺れ、章番号の重複、内部管理コードの本文露出、センシティブな絶対表現などを検査する。原稿のMarkdown統合、HTML・PDF変換、文献検索、PDF取り込み、PIIマスキングを支援するスクリプトも含む。
現在は25本のPythonスクリプトと23のテストモジュールがあり、GitHub Actionsとローカルのpre-push gateで、ユニットテストとスキル定義の整合性検査を実行する。本稿執筆時点のローカル検証では157件のユニットテストが通過し、日英46個のスキル定義も検査を通過した。ただし、これは将来の研究成果や生成物の正しさを保証する数字ではなく、リポジトリ自身の回帰検査の状態を示すものである。
4. 成果物層——チャットではなくリポジトリを正本にする
AIとの会話は便利だが、そのままでは長期研究の正本になりにくい。そこで成果物を、次の五分類で管理する。
docs/<paper-id>/
├── manuscript/ # 完成原稿・HTML・PDF
├── chapters/ # 章ごとの本文
├── design/ # 研究計画・概念・反論・ゲート記録
├── literature/ # 文献マトリクス・論文ノート・原本
└── data/ # 統計・集計・一次データ
AIとのチャットが途切れても、研究問い、採用した定義、確認済み文献、棄却した提案、残っている警告をファイルから復元できる。Gitの差分は、論文がどう変わったかだけでなく、判断の過程を後から確認する手がかりにもなる。
認知スキャフォールディング——大量の質問を返さない
品質を厳しくすると、今度は工程が重くなり、着手できなくなる危険がある。そこで全スキルに、認知スキャフォールディング原則を適用している。
- 巨大な作業を、一分以内に始められる最初の一歩へ分解する
- 非構造化なアイデアを箇条書きや分類として外部化する
- 中断前に文脈と未解決事項を保存する
- 一度に問う意思決定を一つに絞る
論文執筆の支援で、最初に十個の質問へ答えるよう求めても、認知負荷をAIへ外部化したことにはならない。AI側が散らばった思考を保持し、人間が今決めるべき一点だけを提示する必要がある。
ここには、速度と厳密さを両立させるための設計上の緊張がある。自由な着想は止めずに外へ置く。しかし、本文へ入れる段階では根拠を要求する。生成を許す場所と、検証なしに通過させない場所を分ける。
具体例——AIが「もっともらしい先行研究」を書いたら
仮にAIが、本文へ「先行研究ではこの傾向が広く確認されている」と書いたとする。
通常の対話なら、そのまま文章を整えて次へ進めてしまうかもしれない。このワークフローでは、次のように戻る。
- 「広く確認」という主張の強さを分解する
- 根拠として挙げた文献が実在するか確認する
- 検索結果ではなく、本文を読める一次資料を取得する
- その文献が本当に同じ対象・条件・尺度を扱っているか確認する
- 反対結果や学説上の対立がないか探す
- 根拠が一例しかなければ、「広く」を削り、存在例として書き直す
- 主張と根拠の対応を監査記録へ残す
ここでAIは、文章の生成、候補探索、資料の構造化、反論候補の提示を担当できる。しかし、どの表現を本文へ残すかは著者が決める。
はじめ方
リポジトリはMIT Licenseで公開している。共同研究や複数環境で再現しやすい方法は、論文リポジトリへGit submoduleとして追加する方法である。
git submodule add https://github.com/hideshi/scholarly-agent-skills.git .scholarly-agent-skills
python3 .scholarly-agent-skills/scripts/setup_submodule.py --lang ja
手元の複数プロジェクトで同じ最新版を参照したい場合は、シンボリックリンク方式も使える。詳しい手順はREADMEに記載している。
最初の一週間で23スキルすべてを覚える必要はない。まず研究問いを一文にし、数字や文献を本文へ書く前に根拠ファイルを置き、一章できたら一つのゲートを回す。それだけでも、「AIとの会話」から「再確認できる研究工程」へ移行し始められる。
このツールが保証しないこと
Scholarly Agent Skillsは、論文の正確性、網羅性、学術倫理、査読通過、投稿規定への適合を保証しない。品質ゲートにも誤検出と見落としがありうる。
インタビューやアンケートの倫理審査、個人情報の適法な取り扱い、PDFの取得・翻訳・再配布に必要な権利、外部APIの利用規約は、利用者が確認しなければならない。PIIマスキングやAI Ignoreは支援機能であって、十分な匿名化を認証するものではない。
提出先のAI利用方針やプレプリント規定も変わる。submission-venue-advisorは確認項目を整理するが、投稿してよいとは断定しない。詳細はDISCLAIMERに記載している。
最終責任が人間に残るからこそ、このプロジェクトは、人間の注意力だけに責任を背負わせない仕組みを作ろうとしている。
自分の論文執筆から生まれ、摩擦をスキルへ戻している
このプロジェクトは、完成した理論から一度に設計したものではない。私自身がAIと論文を書く過程で、文献の原本が保存されていない、内部用の記号が本文へ露出する、章番号の挿入が崩れる、古い文脈へ復帰できない、といった摩擦を経験し、その再発を防ぐルール、スキル、テストへ戻しながら発展させてきた。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』では、AIへ低い層の認知負荷を外部化しつつ、主張の強さ、採否、最終責任を人間に残す分業を扱った。
『地頭至上主義の系譜と認知資源の多元主義』では、外部資源を使ったかどうかではなく、その出力を検証し、統合し、使用に責任を持てるかを問う必要があると論じた。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』では、人間が根拠を示し、誤りを検出・訂正し、採否を決定できる範囲を、外部化の一つの境界として整理した。
Scholarly Agent Skillsは、これらの問題意識を日々の作業へ落とす参照実装である。ただし、これらの論文と実装は、一般的な効果を実証したものではない。現時点では、著者自身の実践から生まれた設計と存在例として公開している。
AI導入を「利用」から「工程設計」へ
AI活用の議論は、どのモデルを選ぶか、どんなプロンプトを書くかに集中しやすい。しかし、組織で継続して使うなら、より重要なのは、入力をどう管理し、出力をどこで検査し、誰が採否を決め、証拠をどう残すかである。
これは論文執筆だけの問題ではない。調査報告書、要件定義、設計文書、監査資料など、根拠と説明責任が求められる認知作業にも共通する。
Scholarly Agent Skillsは、その中でも論文執筆を対象に、AIとの協働を工程として設計した一つの実装である。AIを導入することと、AIが組織の品質基準の中で働けることの間には距離がある。その距離を、ルール、スキル、検査、成果物で埋めていきたい。
リポジトリはGitHubで公開している。試して見つかった摩擦や改善案は、IssueやPull Requestで共有してもらえるとうれしい。
また、論文に限らず、AIを要求定義、調査、設計、レビューへ組み込みながら、組織として検証可能な工程へ整えることに関心がある。AI活用プロセスや品質ゲートの設計について相談があれば、X（@hdsh0428）から連絡してほしい。