PaperBanana 検証：論文図をテキストから生成するマルチエージェントCLI
Open source implementation and extension of Google Research’s PaperBanana for automated academic figures, diagrams, and research visuals, expanded to new domains like slide generation.
ひと目でわかる
- これは何？
- Google Research の論文を非公式に実装したコミュニティ版。手法記述から図と統計プロットを生成するが、品質はプロバイダの画像モデルに強く依存する。
- 誰に向いている？
- 手法記述から図のドラフトを素早く作り、あとで人手で整える前提なら導入する価値がある。逆に、投稿規定に厳密に合ったベクター図を一発で得たい場合や、生成画像をそのままカメラレディに載せたい場合には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
PaperBanana が埋めようとしている穴
論文の図、とくにアーキテクチャ図やパイプライン図の作成は、研究室内でもっとも時間を食う雑務のひとつである。著者は手法を文章で説明できるが、それをブロック図に落とす作業は描画ツールの操作に依存する。PaperBanana はこの工程を、テキスト記述から画像を生成するパイプラインに置き換えようとする。README は「An agentic framework for generating publication-quality academic diagrams and statistical plots from text descriptions」と述べており、対象は AI 研究者、とくに NeurIPS などの締切前に図を量産する必要がある著者である。トピックに neurips や arxiv が並んでいるのはそのためだ。注意すべきは、これが Google Research の論文 arXiv:2601.23265 の非公式なコミュニティ実装であり、README 自身が「not affiliated with or endorsed by」と明記している点である。原論文のシステムと挙動が一致する保証はない。
二段階パイプラインと入力最適化層
README が示す構成は、二段階のマルチエージェントパイプラインと反復的な改善である。第一段階で入力テキストを解釈し、第二段階で画像を生成し、その結果を再度モデルに渡して修正させる。この往復を成立させるのが入力最適化層で、README は「Input optimization layer for better generation quality」と説明している。つまり生の手法記述をそのまま画像モデルに投げるのではなく、VLM 側で図として解釈しやすい形に整形してから生成に渡す。データの流れは、入力テキスト（または PDF）→ VLM による解釈と最適化 → 画像モデルによる生成 → VLM による評価と修正指示、という順序になる。auto-refine モードと、ユーザーのフィードバックを与えて実行を継続する仕組みが用意されているのは、このループが一発では収束しない前提だからだ。プロバイダは OpenAI（GPT-5.2 + GPT-Image-1.5）、Azure OpenAI / Foundry、Google Gemini、Atlas Cloud に対応する。VLM と画像生成モデルを別々に指定できるため、解釈は安いモデル、描画は高性能モデルという組み合わせも設定次第で可能になる。
インストールと最短の実行手順
Python 3.10 以上が必要で、pip で入れる。pip install paperbanana。開発目的ならリポジトリを clone して pip install -e ".[dev,openai,google]" とする。API キーは .env.example をコピーして設定する。cp .env.example .env の後、OPENAI_API_KEY か GOOGLE_API_KEY を記入する。Azure 経由なら OPENAI_BASE_URL に https://<resource>.openai.azure.com/openai/v1 の形式でエンドポイントを書く。Gemini のモデルを差し替えたい場合は GOOGLE_VLM_MODEL と GOOGLE_IMAGE_MODEL、プロキシを使う場合は GOOGLE_BASE_URL を設定する。Gemini 向けには対話式の paperbanana setup も用意されている。生成は paperbanana generate --input examples/sample_inputs/transformer_method.txt --caption "Overview of our encoder-decoder architecture" のように実行する。Docker も提供されており、docker run --rm -e GOOGLE_API_KEY paperbanana generate --help で動作確認できる。入力を渡す場合は -v "$(pwd)/method.txt:/work/method.txt:ro" と -v "$(pwd)/outputs:/work/outputs" でマウントする。PDF を手法の文脈として読ませる場合はオプションの paperbanana[pdf]（PyMuPDF）を入れ、ページ単位で選択できる。
バッチ処理、Studio、MCP という周辺機能
単発の生成だけでなく、YAML か JSON のマニフェストから複数の図を一度に作るバッチ生成がある。統計プロット用には paperbanana plot-batch があり、マニフェストの各項目に CSV か JSON を対応させて複数のプロットをまとめて処理する。これは論文一本に図が十数点ある状況を想定した設計で、対話的に一台ずつ作るより現実的である。ローカルの Gradio UI である PaperBanana Studio は paperbanana studio で起動し、図、プロット、評価、バッチ、実行履歴の閲覧をひとつの画面にまとめる。加えて MCP サーバとして公開されており、IDE から呼び出せる。Claude Code 向けには /generate-diagram、/generate-plot、/evaluate-diagram のスキルが同梱される。評価用のベンチマークデータ PaperBananaBench のミラーが bench-data-v1 としてリリースされている点も、生成結果を定量で見たい場合の材料になる。
生成物の品質は画像モデル側の制約をそのまま引き受ける
ここが最も冷静に見ておくべき部分だ。パイプラインがどれだけ入力を最適化しても、最終的な画素を描くのは外部の画像生成モデルであり、図中のラベル文字が正しく描かれるか、矢印の向きが論理と一致するかは、そのモデルの能力に依存する。README は生成品質を保証していないし、原論文のシステムと同一であるとも述べていない。したがって、得られるのは完成した出版用図ではなく、編集の出発点になるラフだと考えたほうがよい。とくに数式や記号、長い英語ラベルを含む図では、文字化けや綴りの破綻が起きる可能性が構造上残る。また、プロバイダを切り替えると出力の傾向が変わるため、同じ入力でも再現性は保証されない。API キーと従量課金が前提である点も見落とされやすい。反復改善を回すほどトークンと画像生成のコストが積み上がるので、auto-refine の回数は予算と相談して決める必要がある。
向かないケースと、代わりに検討する手段
ベクター形式の厳密な図が必要な場合、PaperBanana は適していない。投稿規定が PDF や SVG のベクター入稿を求め、線幅やフォントを指定する場合、ラスタ画像を生成してから手作業でトレースする手間が発生し、最初から TikZ や draw.io、Mermaid で書いたほうが速いことが多い。Mermaid はテキストから図を生成するという点で近いが、アプローチは根本的に異なる。Mermaid はノードとエッジの宣言的な記述を決定的なレイアウトエンジンで描画するため、出力は安定し、文字は必ず正しく描かれ、差分管理もしやすい。代わりに、表現できるのはフローチャートやシーケンス図の文法に収まる範囲に限られ、ニューラルネットの内部構造を模式的に描くような自由な表現はできない。PaperBanana は逆で、表現の自由度は高いが、出力は非決定的で、文字の正確さは保証されない。既存の論文図を TikZ で書き直す用途に Mermaid を使うのは無理があるし、逆に投稿規定が厳しい場面で PaperBanana に賭けるのも無理がある。用途で切り分けるべきであって、どちらかが上位互換という関係ではない。
ライセンスと保守の見取り図
ライセンスは MIT で、リポジトリの LICENSE に従う。MIT は寛容な条件だが、生成された画像そのものの権利は、利用したプロバイダの利用規約と生成モデルのライセンスに従う。MIT ライセンスが画像の権利まで保証するわけではないので、投稿先の規約とプロバイダの条件を別々に確認する必要がある。ここは法的助言ではなく、確認すべき項目の指摘にすぎない。保守面では、既定ブランチが main で、v0.2.0 と v0.3.0 が 2026 年 6 月に立て続けにリリースされ、その後 9 月まで push が続いている。ベンチマークデータが別リリースとして切られているため、コードとデータの更新は独立して追うことになる。依存は Pydantic v2 と Typer を土台に、プロバイダごとのオプション extras（openai、google、pdf）に分かれている。プロバイダのモデル名は設定で上書きできるため、上流の API 変更には .env の GOOGLE_VLM_MODEL や GOOGLE_IMAGE_MODEL を書き換える形で追随する。逆に言えば、モデル名の変更は利用者側の設定作業であり、リポジトリが自動で吸収してくれるわけではない。CI バッジと PyPI のダウンロード数が README に並んでいるが、これらは成熟度の根拠にはならない。導入判断は、自分の手法記述で試作し、生成された図のラベルが読めるかどうかを自分の目で確かめる以外にない。
編集部の結論
手法記述から図のドラフトを素早く作り、あとで人手で整える前提なら導入する価値がある。逆に、投稿規定に厳密に合ったベクター図を一発で得たい場合や、生成画像をそのままカメラレディに載せたい場合には向かない。導入前に確認すべきは、自分の手法記述がどの程度構造化されているか、選んだプロバイダの画像モデルが図中の文字をどこまで正しく描けるか、そして生成物のライセンス条件が投稿先の規約と衝突しないかである。
コミュニティノート