Banana Slides レビュー：nano banana pro で作る編集可能な PPTX と AGPL-3.0 の境界
一站式原生AI PPT生成应用，几分钟内生成一套幻灯片; 支持上传任意模板图片，上传任意素材&智能解析，一句话/大纲/页面描述自动生成PPT，口头修改指定区域、一键导出可编辑ppt、视频等 - An AI-native slides generator based on nano banana pro🍌
ひと目でわかる
- これは何？
- テンプレート画像と素材を投入し、プロンプトから編集可能な PPTX を生成する TypeScript 製アプリ。0.9.0 は RC7 の段階で、公開 Demo と Docker セルフホストのどちらを選ぶかで得られる機能が変わる。
- 誰に向いている？
- 向いているのは、テンプレート画像から自前のスライド生成パイプラインを組み、AGPL-3.0 の条件下でソースを管理できるチームだ。向かないのは、ネットワーク分離環境で完結させたい組織と、PPTX を外部 API に送れない案件。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
nano banana pro を「PPT の外側」で使うという設計判断
多くの画像生成ツールは、生成した 1 枚の絵で完結する。Banana Slides が解こうとしているのはその先で、README の説明では、アイデア、アウトライン、ドキュメント、画像、カスタムテンプレートから編集可能なプレゼンテーションを作ることを目的に掲げている。つまり出力の最終形は画像ではなく PPTX であり、生成はその途中工程に置かれている。
対象読者は、スライドの体裁そのものを毎回作り直すことに時間を取られている人だ。とくに、自社のテンプレート画像が既にあり、その見た目を保ったまま中身だけを差し替えたいケースを想定している。README ではテンプレート制御、素材解析、会話による編集、PPTX 書き出し、プロジェクト履歴、再現可能なワークフローが機能として並ぶ。生成の一回性よりも、同じ条件で作り直せることを重視した並びに見える。
ただし 0.9.0 は候補版の段階で、最新リリースは v0.9.0-rc.7（2026-09-05）だ。RC5 から RC7 までが 1 週間ほどに集中しており、この期間は不具合修正が主目的だったことがリリースノートから読み取れる。安定版としての運用実績は、この材料からは確認できない。
生成の流れと、外に出ていく 2 つの依存
リポジトリ構成とリリースノートから見える範囲では、処理は大きく 2 層に分かれる。テキスト側の主模型がアウトラインや各ページの記述を作り、画像側のモデルがスライドの絵を作る。RC7 の修正内容はこの分離をよく示している。Codex（OpenAI OAuth）で「接続済みなのに生図が 400 を返す」問題に対し、内部呼び出しの主模型を `gpt-5.4` から `gpt-5.6-terra` に更新し、画像モデルは `gpt-image-2` のまま据え置いた。テキスト用と画像用を別々に差し替えられる構造でなければ、こういう直し方はしない。
素材の解析側には MinerU が関与する。RC5 では PPT 改造時の MinerU 資格情報のエラー表示が改善され、RC2 では Windows デスクトップ版の可編集 PPTX における MinerU ディレクトリの不一致が修正されている。可編集 PPTX の書き出しが MinerU に依存していることは、この 2 件から読み取れる。
モデルの供給元は 1 社に固定されていない。2026-07-31 の更新では、デスクトップのパッケージ版が LazyLLM のオンライン供給元 11 社（qwen / doubao / deepseek / glm / kimi / minimax / sensenova / siliconflow / ppio / aiping / openai）を登録し、`Unsupported source: qwen` のエラーを解消したとある。抽象化レイヤーを挟む代わりに、そのレイヤー自体が障害点になる。RC4 がデスクトップ版の LazyLLM オンライン供給元の利用不可と SOCKS プロキシ依存の欠落を修正しているのは、まさにその現れだ。
起動方法：Docker と公開 Demo で得られるものが違う
README には Quick Start、Install、Usage、Deploy、Architecture などの導線が用意され、ローカルの Docker 展開とオンライン利用の両方が案内されている。手元で動かす場合は Docker ビルドのバッジが示すとおりコンテナ経由が想定され、具体的なコマンドは README の該当セクションに置かれている。この材料からコマンド文字列そのものを引用することはできないので、正確な手順はリポジトリの Deploy セクションを参照してほしい。
公開 Demo を使う場合は前提が変わる。Demo 側には Inferera、APIMart、火山 Agent Plan の固定モデル構成が用意され、API Key は訪問者ごとに分離される。ここで重要なのは、公開版では履歴が提供されないという点だ。README はプレビューページのリンクを保存して再度アクセスするよう案内している。また、生成要求の本文と条件は編集できるが、記述の追加フィールドの構成は固定される。
運用者向けの設定も公開されている。`.env` に `PUBLIC_DEMO_ADMIN_PASSWORD` を設定すると、`/admin/history` の口述エントリから履歴を確認できる。設定ページの各サービスのテストは同時に実行でき、結果は個別に表示される。自前で Demo を立てる場合、API Key の分離と履歴の扱いはこのパスワード設定の有無で変わる。
「口頭で修正」が実際に要求するもの
README の売り文句のひとつが、口頭で指定領域を修正するという操作だ。これはチャット欄に文章を書けば直るという意味ではなく、修正対象を先に特定させる必要がある。RC5 で「画像編集が既定で範囲選択状態に入る」よう変更されたのは、この前提を操作の側から支える変更だ。対象を選ばずに指示を出せば、意図しない場所が書き換わる余地が残る。
編集の粒度も段階的に整えられてきた。RC3 ではスライドのその場編集とフィールド契約 v2 が入り、テンプレート照合と可編集 PPTX の書き出しが改善された。2026-06-23 には逐页テンプレートが追加され、統一テンプレートとページごとの個別テンプレートの 2 モードを双方向に切り替えられるようになった。画像または PDF からプロジェクトのテンプレートライブラリを構築し、AI がスタイルを解析して各ページに割り当てる。手動でページごとに紐づけることもできる。
ここで気に留めておきたいのは、テンプレートの解析品質がそのまま出力の一貫性を決めるという点だ。テンプレートが複雑なレイアウトや装飾を含む場合、解析結果がどこまで意図を捉えるかは、この材料からは判断できない。判断材料がない以上、採用検討では自社テンプレートで試す以外に確かめる方法はない。
向かない場面：履歴なしの公開 Demo と、外部送信の前提
最初に挙げるべき制約は、公開 Demo に履歴がないことだ。README はプレビューページのリンクを保存するよう求めている。つまりセッションをまたいだ作業の再開は、リンクを手元に残すという運用側の努力に委ねられる。チームで同じ資料を育てる使い方には向かない。自前でホストし `/admin/history` を有効にすれば話は別だが、それは Demo の話ではなくセルフホストの話だ。
2 点目は、生成と解析の過程で内容が外部のモデル API と MinerU に渡るという構造そのものだ。社外秘の資料や個人情報を含むスライドを扱う場合、この経路が許容できるかどうかが導入の可否を決める。ローカルで完結する代替経路がこの材料からは確認できないため、ネットワーク分離環境を要件にしている組織には勧められない。
3 点目は RC 段階であることだ。0.9.0 は v0.9.0-rc.7 が最新で、RC6 ではデスクトップ起動時の更新チェックが追加され、更新カード、ダウンロード進捗、失敗時の再試行、再起動を伴うインストールが入った。RC5 ではデスクトップ版の更新チェックが RC チャンネルに正しく追従するようになっている。更新経路が既定で動くということは、検証環境では固定したい場面で意図しない更新が入り得るということでもある。
比較対象としての Marp と Slidev：生成か、記述か
同じ「テキストからスライド」の入口を持ちながら、設計の起点が逆にある道具がある。Marp と Slidev は Markdown を原本とし、レイアウトはテーマと CSS で決める。出力は決定的で、差分も Git で追える。代わりに、見た目は自分で作り込む必要があり、テンプレート画像からスタイルを読み取ってくれるわけではない。
Banana Slides の違いは、原本が記述ではなく生成結果の側にあることだ。テンプレート画像と素材を投入し、AI がスタイルを解析して各ページに割り当てる。得られるのは編集可能な PPTX で、PowerPoint 上で手を入れる前提になっている。決定的であることと、既存のテンプレートに寄せられることは両立しない。どちらを優先するかで選ぶ道具が変わる。
中間の選択肢として、Markdown で構成を書き、画像だけを生成モデルに任せる組み方もある。この場合、レイアウトの一貫性はテーマ側の責任のまま残る。テンプレート解析とページ単位の割り当てを自分で作りたくないなら、Banana Slides の逐页テンプレートはその部分を肩代わりする。逆に、スライドの構造をコードで管理したいなら、この肩代わりは邪魔になる。
AGPL-3.0 と、RC チャンネルを追うコスト
ライセンスは AGPL-3.0 で、リポジトリの LICENSE に置かれている。ネットワーク越しに利用者へ機能を提供する形態では、対応するソースの提供が求められる点が他のライセンスとの実務上の差になる。社内での閲覧利用と、顧客向けサービスへの組み込みでは、検討すべき範囲が変わる。ここで具体的な条件を断定することはできない。法務の確認は必要で、この記事は法的助言ではない。
保守の面では、追うべき対象が多い。モデルの供給元は LazyLLM 経由で 11 社が登録され、画像側は APIMart の OpenAI 互換プリセット、火山 Agent Plan、SenseNova U1 などが順次追加されてきた。RC6 では APIMart の OpenAI 互換の非同期画像タスク、非ストリーミング要求、1K/2K/4K の解像度指定が修正されている。供給元ごとに挙動の差を吸収する作業が続いているということだ。
更新の頻度も考慮に入る。RC5 が 2026-08-29、RC6 が 08-30、RC7 が 09-05 と、短い間隔で候補版が並ぶ。デスクトップ版の更新チェックは RC チャンネルに追従するため、検証環境ではチャンネルの扱いを決めてから配る必要がある。修正が速いことと、版が落ち着くまでの間は追従コストを払い続けることは、同じ事実の裏表だ。
編集部の結論
向いているのは、テンプレート画像から自前のスライド生成パイプラインを組み、AGPL-3.0 の条件下でソースを管理できるチームだ。向かないのは、ネットワーク分離環境で完結させたい組織と、PPTX を外部 API に送れない案件。導入前に確認すべきは 3 点で、第一に 0.9.0 が v0.9.0-rc.7 のままで RC チャンネルの更新チェックが既定で有効になっていること、第二に公開 Demo では履歴が提供されず `/admin/history` の閲覧に `.env` の `PUBLIC_DEMO_ADMIN_PASSWORD` が必要なこと、第三に可編集 PPTX の書き出しが MinerU の資格情報に依存し、その設定不備がエラーとして表面化する点だ。Docker で自前運用するなら、まず `docker compose` で立ち上げて MinerU の資格情報を設定し、1 スライドだけ書き出して PPTX を PowerPoint で開けるか確かめる。ここが通らなければ、このツールの中心的な価値は受け取れない。
コミュニティノート