アイデア1行をPDFの論文に変えるspark-to-paper-skills──Claude Codeの13個のスキルだけで、数値を捏造せず図まで組む仕組み

3行まとめ

1. spark-to-paper-skillsは、「アイデア→文献調査→執筆→実験→図版→コンパイル済みPDF」までを、別アプリやオーケストレーションサーバーを介さずClaude Code上の1オーケストレータ＋13個のスキルだけで完結させるOSS。プレプリント（arXiv:2608.11924）は2026-08-13にHugging Face Daily Papersで1位を獲得した。
2. 中核の差別化ポイントとして公式READMEが挙げるのは「編集可能なベクター図」で、公式PaperBanana（画像生成ツール）が描いたラスター画像の意匠を学習した上で、論文本文の事実に基づき<text>・<path>要素として"ネイティブに描き直す"独自のts-figure-svgスキルを持つ。
3. 「Proposal mode（結果セルは空欄のまま、数値を絶対に捏造しない）」と「Data-aware mode（実データに基づく数値のみを過去形で報告し機械監査する）」という2つの整合性モードを持ち、run_gates.pyという決定論的なゲートがゼロ以外の終了コードでビルドを止める設計になっている。

1オーケストレータ・13スキルという構成

spark-to-paper-skillsのREADMEは、プロジェクトを"Drop a spark. Get a paper."（一粒の着想を、論文に）というキャッチコピーで紹介している。インストールはリポジトリをClaude Codeのスキルディレクトリにcloneするだけ。

git clone https://github.com/Spark-To-Paper-Skills/spark-to-paper-skills.git ~/.claude/skills/spark-to-paper-skills

使い方は「Run ts-paper on this proposal.」とアイデア・提案文・データを貼り付けるだけで、オーケストレータ（ts-paper）が入力を自動でルーティングし、フルチェーンを実行する。READMEが示すパイプライン図は次の7段階＋自動実験ステージ。

1. ts-paper-plan   → blueprint.json（タイトル・キーワード・貢献・記法・語数目標）
2. ts-paper-cite   → refs.bib（WebSearch＋Crossrefで検証した実在の参考文献40件以上）
3. ts-paper-write  → sections/*.tex（全セクションを1回の一貫した執筆パスで生成）
4. ts-paper-refine → 右サイズ化＋AI臭除去＋論理の自己点検
5. ts-paper-review → 敵対的レビュー（複数レビュアーによる耐性強化）
6. ts-paper-figure → 図版＋ネイティブSVG（PaperBanana→意匠学習→再描画＋監査）
7. ts-paper-latex  → main.pdf（組版＋コンパイル）
8. ts-paper-experiment（自動）→ 実行可能な実験を走らせ、結果表を埋めてから再コンパイル

入力は「(a) 一行のアイデア」「(b) 問題・手法・評価はあるが実測結果が無い提案」「(c) 実測結果やデータファイル付きの提案」「(d) 既存のstory.json」の4クラスに自動振り分けられ、(a)(b)(d)は「Proposal mode」、(c)は「Data-aware mode」で処理される。

数値を捏造しない仕組み──2つの整合性モード

READMEが最も強調している設計原則が、この2モードの「正反対の整合性ルール」だ。

これを支える「品質スタック」は4層に分かれている。①決定論的ゲート（セクション構成・語数バンド・捏造禁止・引用の完全性・ベクターPDFの存在をチェック）、②自己レビュー（右サイズ化・用語の一貫性・整合性・AI臭のスクラブ）、③敵対的レビュー（複数の独立したレビュアーが逐語引用による読み飛ばし防止付きで全文を読み、視点の異なる懐疑派が各指摘に反論を試みるループ）、④視覚批評（レンダリングされた各図を読み、忠実性・可読性・美観をチェック）。run_gates.py <workdir> allが非ゼロを返すと「未完了」扱いになる。

図版エンジン──PaperBanana+

READMEが「本プロジェクトの中核的な差別化要因」と位置づけるのがts-figure-svgスキルだ。公式のPaperBanana（Retriever→Planner→Stylist→Visualizer→Criticという5段階の画像生成パイプライン）が候補図を描き、そこから「意匠言語（パレット・タイポスケール・余白・慣用表現）」を学習した上で、内容そのものは論文の手法本文から再導出し、<rect>/<path>/<text>といった本物のベクター要素として"ネイティブに描き直す"、というのがREADMEの説明だ。決してピクセルをトレースしない、と繰り返し強調されている。

監査スクリプトaudit_svg.pyはスタンドアロン（レンダラー・APIキー・モデル不要、Adobeのcore-14 Timesのメトリクスのみ使用）で、「キャンバス/カードのはみ出し」「ラベルの上に図形が重なっている」「markerUnits=\"strokeWidth\"で矢印が巨大化する」「コネクタが何にも接続していない」「読めないほど縮小されたテキスト」「埋め込みラスター画像やトレースされたピクセルパス」といった、目では見逃しやすい欠陥を機械的に検出する。フォールバックの順序は「ネイティブ再描画→ローカルなラスター保持最適化→承認済みPNGをそのまま使う」の3段階で、劣化を伴う再描画や、単純な箱と矢印への退行は絶対にしない、とREADMEは明記している。

バージョン履歴:v1.0からPaperBanana+統合まで

READMEの「What's New」セクションによれば、このプロジェクトは次の順序でバージョンを重ねてきた。

GitHub Releases APIで確認したところ、v1.0・v1.0.1・v1.1.0の3つは同日（2026年6月26日）に公開され、PaperBanana+統合のv1.2はそれから約1ヶ月半後の2026年8月7日に公開されている。リポジトリ自体の作成日は2026年6月18日。GitHub APIで取得したリポジトリ情報では、star数852・fork数17・open issue数1だった（本記事執筆時点のスナップショット）。図エンジンが依存する外部プロジェクト「PaperBanana」（dwzhu-pku/PaperBanana）もGitHub APIで実在を確認し、説明文は「PaperBanana: Automating Academic Illustration For AI Scientists」、star数は7,022だった。

READMEのFAQセクションには「結果を捏造して論文を完成させたように見せかけないか」という質問への回答もある。Proposal modeではdraft_lintが、データの裏付けのない本文中の数値でビルドを失敗させ、Data-aware modeではresults.facts.jsonというファイルを基準に本文中の数値をチェックする、という説明だ。またREADMEは「main.pdfが存在し中身が空でない・LaTeXエラーがゼロ・main.bblが全引用を解決・すべての\cite{}がrefs.bibの完全なエントリに対応・捏造された数値が一切ない・すべての図が編集可能なベクターPDFとして埋め込まれている・敵対的レビュー段階が実行済み・run_gates.py <workdir> allが0を返す」という8項目を「Definition of Done（完了の定義）」として明記している。

対応テンプレートと必要環境

READMEは他の類似プロジェクト（academic-research-skills、Idea2Paper、AutoResearchClaw、AI-Scientist、Kosmos、karpathy/autoresearch、auto_research）との比較表も掲載しており、「AutoResearchClawやAI-Scientistのような重量級の自律科学者はスコープの広さでは並ぶが、スタンドアロンのPythonプロダクトとして出荷される。ARSやIdea2Paperのような軽量スキルは、実験・図版までの経路をカバーしていない」と自己位置づけしている（2026年8月時点でのリンク先ドキュメント確認に基づく比較だとREADME自身が注記している）。

生成された論文の中身について確認できていないこと

筆者はこのスキル群を実際にClaude Code上で動かし、論文を1本生成する検証はしていない。本記事の執筆環境にLaTeX環境が整っているかどうかも確認しておらず、外部WebSearch・Crossref呼び出しを伴う点も踏まえて見送った。ショーケースの7本の論文についても、READMEに掲載されている説明を紹介したのみで、生成された論文の中身（引用の正確性、実験結果の妥当性）を個別に検証してはいない。他プロジェクトとの比較表もREADME側の自己申告であり、第三者による中立的な比較レビューは今回の調査範囲では見つけられなかった。図エンジンが依存している外部プロジェクト「PaperBanana」（dwzhu-pku/PaperBanana）自体のリポジトリは、GitHub APIでの存在確認とREADMEの説明文の取得までは行ったが、その実装コードの中身までは読んでおらず、独立した動作検証はしていない。Zenn記事検索では「Spark-to-Paper」という文字列の該当記事はこの記事作成時点で見当たらなかった。

関連記事

• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• AI論文検索・読解ツール おすすめ比較