figures4papers：matplotlib の作図規約を skill として切り出したリポジトリ

このリポジトリが埋めるのは「図のスタイルが毎回バラつく」という穴

著者の Chen Liu は Yale 大学の CS 博士課程の学生で、README には Nature Machine Intelligence、ICML、NeurIPS、ECCV などで発表した図が掲載されていると書かれている。中身は論文用の図を作るための Python スクリプト集だ。

問題設定ははっきりしている。論文の図は、色、フォントサイズ、線幅、余白、保存形式を投稿先ごとに揃える必要があり、ふだん可視化を書かない研究者ほど毎回同じ調整を繰り返す。このリポジトリは、その調整を figure_* ディレクトリごとの実例と scientific-figure-making/ 以下の規約文書に固定し、再利用できる形にしたものだ。

対象読者は、matplotlib を使う研究者と、その研究を手伝う AI コーディングエージェントである。後者が明示的に想定されている点が、単なるスクリプト置き場との違いになる。README には「The scientific figure making skill lives in scientific-figure-making/」とあり、skill という語が単なる比喩ではなく、エージェントに読ませる単位として使われている。

scientific-figure-making/ の階層と、references/ に置かれた5つの文書

リポジトリの中心は scientific-figure-making/ で、README が示す階層は次のとおり。

scientific-figure-making/ ├── SKILL.md └── references/ ├── api.md ├── common-patterns.md ├── demos.md ├── design-theory.md └── tutorials.md

SKILL.md はメタデータ、使う場面、パターン、リンクをまとめた「Quick reference」と説明されている。references/ 側は役割が分かれていて、api.md は実装すべき API と規約（palette、helpers、export）、common-patterns.md は再利用できる図のパターン、demos.md は実在の figure_* プロジェクトと URL、design-theory.md はスタイルの根拠と設計原則、tutorials.md は手順のガイドである。

ここで注目したいのは、コードと文章が分離されている点だ。palette や export の規約は api.md に文章として書かれ、実装は figure_* 以下のスクリプトに置かれる。エージェントに読ませる対象が明確になり、プロンプトでどのファイルを参照すべきか指定できる。逆に言えば、api.md と実際の figure_* スクリプトが食い違えば、この仕組みは機能しない。README からは両者の同期を検証する仕組みは読み取れない。

エージェントに読ませる3つのファイルと、生成させるスクリプトの型

README が示すプロンプトの型は、対象パス、参照すべき3ファイル、実装すべきパターン、入力データ、出力ファイル、スタイルの一貫性という6項目で構成されている。参照先として名指しされているのは SKILL.md、references/design-theory.md、references/api.md の3つだ。

実装側で名指しされているのは apply_publication_style、make_* helpers、finalize_figure である。apply_publication_style は rcParams を一括で書き換える入口、make_* は棒グラフやレーダーチャートなど図種ごとの組み立て、finalize_figure は保存前の仕上げ（レイアウト、余白、書き出し）を担う、という役割分担だと README とファイル名から推測できる。ただし各関数の引数やシグネチャは README には載っておらず、実際の定義は api.md と figure_* のスクリプトを読む必要がある。

出力は <name>.png と <name>.pdf の2形式を指定する形になっている。PNG は確認用、PDF は入稿用という使い分けが想定されていると読める。プロンプトに「Keep the style consistent with this repository」と入れるよう促しているのは、エージェントが独自の配色やフォントを混ぜるのを防ぐためだろう。

導入は2通り：パス参照で済ませるか、skills ディレクトリに symlink するか

README は導入方法を2つに分けている。

1つ目はインストール不要のパス参照方式である。リポジトリを Cursor や Claude Code などのエージェントで開き、プロンプト内で scientific-figure-making/SKILL.md と references/ のファイルをパスで指定する。symlink もプラグインも不要だと明記されている。手順は、リポジトリを開く、対象フォルダ（例：figure_PROJECT_NAME/）に作図スクリプトを作らせる、design-theory.md などを明示的に参照させる、生成されたスクリプトを実行して書き出しを確認する、の4段階。

2つ目は skill としてインストールする方式で、リポジトリのルートから実行するコマンドがエージェント別に表で示されている。Cursor なら mkdir -p ~/.cursor/skills のあとに ln -s "$(pwd)/scientific-figure-making" ~/.cursor/skills/scientific-figure-making、Claude Code なら ~/.claude/skills、Codex なら ~/.codex/skills に対して同じ形の symlink を張る。リンク後にエージェントを再起動するか skill 一覧を更新すれば、パス参照に加えて名前でも呼べるようになる。

symlink 方式の注意点は、リンク先がリポジトリの作業ツリーそのものだということだ。リポジトリを移動したり削除したりすればリンクは切れる。恒久的に使うなら、リポジトリの配置場所を決めてから張るほうがよい。

図の種類ごとに分かれた figure_* ディレクトリと、Python 外の作業を分ける assets/

README には図の例が種類別に並んでいる。棒グラフ（figure_ImmunoStruct/figures/bars_comparison_IEDB.png）、構成比の棒グラフ（figure_Brainteaser/figures/brute_force.png）、3D 球（figure_Dispersion/figures/illustration.png）、レーダーチャート（figure_VIGIL/figures/comparison_radar.png）、折れ線（figure_VIGIL/figures/comparison_posttraining.png）、概念図（figure_VIGIL/figures/concept.png）、トレンド（figure_ophthal_review/figures/trend_by_month.png）。

構成として重要なのは、assets/ が別扱いされていることだ。README はこのディレクトリについて「figures not made end-to-end in Python」と明記し、Python で部分的にしか作っていない図を、それに費やした時間を認める意味で含めていると説明している。つまり、このリポジトリは自分の守備範囲を Python で完結する図に限定しており、Illustrator などで仕上げた模式図は再現対象ではなく記録として置かれている。

この線引きは、そのまま採用判断の材料になる。模式図やティーザー図を主力にする研究グループにとって、このリポジトリが提供するのは棒グラフや折れ線の規約であって、模式図の作り方ではない。

向かないケースと、代替になるアプローチ

このリポジトリが向かないのは、まず対話的な可視化や Web への埋め込みが目的の場合だ。出力は PNG と PDF に固定されており、HTML やインタラクティブなグラフを出す仕組みは README には出てこない。ダッシュボードやノートブック上での探索的可視化が主目的なら、Plotly や Vega-Lite のような宣言的な可視化ライブラリのほうが適している。違いは抽象度にある。figures4papers は matplotlib の rcParams と描画関数を直接扱う前提で、最終的な紙面の見た目を制御する。一方の宣言的ライブラリは、データとエンコーディングの対応を記述し、描画の詳細はライブラリに委ねる。前者は投稿規定への追従に向き、後者は探索と共有に向く。

もうひとつの代替は、出版済みのスタイルシートをそのまま使う方法だ。たとえば SciencePlots のような matplotlib スタイル集は、plt.style.use() で既成のスタイルを適用する。figures4papers との違いは、適用する単位がスタイル名か、API とヘルパー関数を含む skill かという点にある。スタイル集は見た目を揃えるが、図の組み立て方までは指定しない。figures4papers は make_* や finalize_figure といった組み立ての型まで含めてエージェントに渡す。逆に、既存のスタイル集で満足できるなら、skill を読み込ませる手間は不要である。

3つ目の落とし穴は、NOASSERTION というライセンス表記だ。GitHub 上でライセンスが自動判定できなかったことを意味し、許諾条件が明確でない。研究室内で参考にする分には問題が小さくても、配布物や製品にコードを流用する場合は、リポジトリの LICENSE ファイルを自分で確認する必要がある。ここでは法的助言はできない。

維持コストは「規約と実装のずれ」に集約される

このリポジトリにはリリースがなく、バージョン番号も付けられていない。README の最終更新は 2026年9月時点で、著者個人のスクリプト集という性格が強い。したがって、依存する側が負うコストは、アップグレード対応ではなく、規約文書と実装のずれを自分で埋める作業になる。

具体的には、api.md に書かれた palette や export の規約と、figure_* 以下のスクリプトの実際の呼び出しが一致しているかを確認する必要がある。エージェントは api.md を読んでコードを書くため、文書が古ければ古い書き方のコードが生成される。SKILL.md が Quick reference としてメタデータと使う場面を持つ以上、参照先の記述が実装より先行して更新される可能性は十分にある。

もう一点、図のスタイルは投稿先の要求と結びついている。カラム幅、フォントの埋め込み、線幅の下限はジャーナルごとに異なる。apply_publication_style() が設定する rcParams が自分の投稿先の要求を満たすかは、採用前に自分のデータで1枚書き出して確認するのが早い。満たさない場合、skill を symlink しても結局は手作業の微調整が残る。

編集部の結論

向いているのは、matplotlib で図を書き、そのスタイルを AI コーディングエージェントに毎回同じ形で再現させたい人である。逆に、対話的な可視化や Web 埋め込み、Illustrator 前提のワークフローを使う人には不要で、assets/ 以下の図が示すとおり、このリポジトリ自身が「Python で end-to-end に作っていない図」を別扱いしている。採用前に確認すべきは一点で、自分の環境で apply_publication_style() を呼んだときに rcParams が想定どおり変わるか、そして references/api.md に書かれた palette と export の規約が自分の投稿先の要求（フォント埋め込み、線幅、カラム幅）と衝突しないかを見ておくこと。ここが合わなければ、skill を symlink しても結局は手作業の微調整に戻る。

公式情報源

1. ChenLiu-1996/figures4papers on GitHub
2. Issues
3. Project website
4. README