PPTAgent と DeepPresenter: 既存テンプレートを解析して PPTX を組み立てるエージェント
An Agentic Framework for Reflective PowerPoint Generation
ひと目でわかる
- これは何？
- PPTAgent は、スライド生成を「ゼロからの描画」ではなく「参照 PPTX の構造解析と編集」として扱う Python フレームワークである。v2.0.0 で DeepPresenter が統合され、調査・素材生成・サンドボックス実行まで含む構成に変わった。その仕組みと、採用前に確認すべき境界を整理する。
- 誰に向いている？
- 導入を検討すべきなのは、既存の PPTX テンプレートを資産として持っていて、そのレイアウトを保ったまま内容だけを差し替えたいチームである。逆に、デザインを毎回ゼロから設計したい場合や、Windows ネイティブ環境しか用意できない場合は、この構成は噛み合わない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
PPTX を白紙から描かず、参照デッキの構造を写して作るという発想
多くのスライド生成ツールは、テキストから新しいレイアウトを毎回組み立てる。PPTAgent の README が示す方向はこれと逆で、参照となる PPTX を解析し、その構造を再利用して出力を組み立てる。タイトル、本文、図の位置といった要素を既存デッキから取り出すため、生成物の見た目は元テンプレートの制約に従う。発表資料のフォーマットが組織内で固定されている状況では、この制約は欠点ではなく前提条件になる。
対象読者は、報告書や提案資料を定期的に大量生産する必要があり、かつ社内テンプレートという逃げられない制約がある人である。逆に、スライドの見た目そのものを毎回デザインしたい人には、この設計は窮屈に映る。README には参照デッキの解析手順そのものは詳しく書かれていないので、内部でどの程度レイアウトを忠実に再現するかは、リポジトリのコードを読むまで確定できない。
v2.0.0 で DeepPresenter が統合され、生成の前段が厚くなった
リリース情報では v2.0.0 が「PPTAgent V2: DeepPresenter Integrated」と説明されている。ニュース欄によれば 2025年12月に DeepPresenter のコードベースが公開され、Deep Research Integration、Free-Form Visual Design、Autonomous Asset Creation、Text-to-Image Generation、そしてサンドボックスと 20 以上のツールを持つ Agent Environment が含まれる。つまり v0.1.0 相当の「テンプレート解析と編集」に、調査と素材生成の層が上乗せされた形になっている。
この統合は、単に機能が増えたという話ではない。生成の途中で外部サービスやサンドボックス上のツール呼び出しが挟まるため、失敗点が増える。Web 検索、PDF 解析、画像生成のどこでつまずいたのかを切り分ける必要が出てくる。README が任意サービスとして Tavily、MinerU、text-to-image モデルを列挙しているのは、この前段が品質のボトルネックになりやすいことの裏返しだと読める。
uvx pptagent onboard から generate までの最短経路
README が最初に推奨しているのは CLI と最小タスクでの確認である。インストールは uv を入れてから、対話形式のセットアップを実行する。
curl -LsSf https://astral.sh/uv/install.sh | sh uvx pptagent onboard uvx pptagent generate "Single Page with Title: Hello World" -o hello.pptx
添付ファイルを渡す場合は -f を繰り返し、ページ範囲は -p で指定する。README の例では -p "10-12" のようにレンジで書かれている。
uvx pptagent generate "Q4 Report" -f data.xlsx -f charts.pdf -p "10-12" -o report.pptx
Docker Compose やソースビルドの場合は対話セットアップに頼らず、設定ファイルを手で用意する。
cp deeppresenter/config.yaml.example deeppresenter/config.yaml cp deeppresenter/mcp.json.example deeppresenter/mcp.json
ここで注意すべきは、onboard が設定を作る側であり、手動構築の場合はこの 2 ファイルを自分で埋める必要があるという点である。README は Windows をサポートしないと明記し、WSL の利用を求めている。macOS では CLI が Homebrew、Node.js、Docker、poppler、Playwright、llama.cpp を自動導入することがあると書かれており、Linux では環境を自分で用意する前提になっている。
config.yaml と mcp.json に何を入れるかで生成品質が変わる
任意サービスは 3 つ挙げられている。Tavily は Web 検索の品質を上げ、API キーを deeppresenter/mcp.json の TAVILY_API_KEY に設定する。MinerU は PDF 解析の品質を上げ、mineru.net で取得したキーを MINERU_API_KEY に入れるか、ローカルにデプロイして MINERU_API_URL を設定する。画像生成は deeppresenter/config.yaml の t2i_model で設定する。
完全オフラインで動かしたい場合は、MinerU をローカルにデプロイしたうえで config.yaml の offline_mode を true にする。README の説明では、これにより Web 検索のようなネットワーク依存ツールを読み込まなくなる。ここは設計上のトレードオフがはっきり出る箇所で、オフラインにすれば調査の深さは落ちる。逆にオンラインのままにすれば、Tavily や MinerU の可用性とレート制限がそのまま生成の失敗率に反映される。
設定可能な変数の全体は deeppresenter/utils/constants.py にあると README は案内している。example ファイルと constants.py の両方を見ないと、どのキーが実際に効くのかは判断しにくい。
MCP サーバー対応と、Windows 非対応という境界
2025年9月に MCP サーバー対応が追加され、設定の詳細は PPTAgent/DOC.md の MCP Server の節に置かれている。MCP 経由で呼び出す構成を取るなら、CLI の generate ではなくこのドキュメントを起点にしたほうが早い。トピックに mcp が含まれていることからも、外部エージェントからツールとして使う想定が明確である。
制約として大きいのは Windows 非対応である。WSL を使う前提なので、Windows ネイティブの CI や社内配布環境にそのまま載せることはできない。また macOS では CLI が複数のローカル依存を自動導入する。これは初回体験としては楽だが、何が入ったのかを把握しないまま本番環境の設計に進むと、後で依存関係の出所が分からなくなる。Linux で自前構築する場合は、この自動導入がないぶん、必要なものを自分で洗い出す作業が発生する。
もう一点、README は「fine-tuned model のデプロイを強く推奨する」とし、実験で既存のオープンソースモデルを大きく上回ると主張している。ただしこれは README の主張であり、本記事でその数値を検証したわけではない。汎用モデルで動かす場合と DeepPresenter-9B を使う場合で挙動が変わる可能性は、前提として持っておくべきである。
python-pptx 的なライブラリ直接利用との違い
比較対象として分かりやすいのは python-pptx のようなライブラリを自分で呼ぶ方式である。あちらは「スライドを追加し、テキストボックスを置き、段落を書く」という手続きを開発者が書く。レイアウトの再利用は自分で実装するか、テンプレートのプレースホルダ名を決め打ちして埋めることになる。決定的なのは、どのテキストをどの枠に入れるかを人間が決める点である。
PPTAgent はこの割り当てをモデルに委ねる。参照デッキの構造を解析し、内容を生成し、必要なら調査や画像生成まで行う。そのぶん、出力は毎回同じにはならない。CI で決まった資料を吐かせたい用途では、python-pptx のほうが再現性は高い。逆に、資料の構成自体を毎回考えさせたい用途では、プレースホルダを手で埋める方式はスケールしない。どちらが優れているという話ではなく、決定論を取るか、構成の生成まで任せるかの選択である。
メンテナンスとライセンスの見取り図
ライセンスは MIT である。リポジトリはアーカイブされておらず、最終 push は 2026年9月7日、最新リリースは v2.0.0（2025年12月16日）である。v0.1.0 が 2025年4月、v0.2.0 が 2025年10月なので、およそ半年から 1 年おきに大きな区切りが入るペースだったが、v2.0.0 では DeepPresenter 統合という構成変更が入っている。マイナー更新ではなく、設定ファイルの構成や依存が変わる種類の更新と見てよい。
アップグレードコストとして効いてくるのは、config.yaml と mcp.json の example が更新される可能性である。手動で設定を維持している場合、example との差分を追わないと、新しいキーが無言で無視される。onboard を使っていれば追従は楽になるが、そのぶん何が変わったかが見えにくい。MIT なので自組織のコードに取り込む際の制約は小さいが、同梱されるモデルや外部サービス（Tavily、MinerU、DeepPresenter-9B の配布元）はそれぞれ別の条件を持つ。ライセンス判断は各配布元の表示を確認する必要があり、ここで法的な助言はできない。
採用前に潰しておくべき確認項目
第一に、参照デッキとして何を渡すと期待どおりの出力になるかを、最小タスクで確かめる。README の例は "Single Page with Title: Hello World" という 1 枚ものなので、まずここで依存関係と環境が正しいことを確認する。
第二に、offline_mode を true にした状態と、Tavily と MinerU を有効にした状態で、同じ入力の出力がどう変わるかを見る。任意サービスが「品質を上げる」と書かれている以上、オフライン構成は品質を意図的に落とす選択である。どれだけ落ちるかは自分の資料で測るしかない。
第三に、MCP サーバーとして使うのか、CLI で完結させるのかを先に決める。前者なら PPTAgent/DOC.md の MCP Server の節、後者なら constants.py と example ファイルが主な参照先になる。Windows しかない環境では、この検討自体が WSL 前提になる。
最後に、生成された PPTX をそのまま配布するのか、人間が校正する前提なのかを決めておく。エージェントが構成まで決める以上、内容の正しさを保証する仕組みはこのフレームワークの外側に置く必要がある。
編集部の結論
導入を検討すべきなのは、既存の PPTX テンプレートを資産として持っていて、そのレイアウトを保ったまま内容だけを差し替えたいチームである。逆に、デザインを毎回ゼロから設計したい場合や、Windows ネイティブ環境しか用意できない場合は、この構成は噛み合わない。最初に確認すべきは、uvx pptagent onboard が生成する deeppresenter/config.yaml と deeppresenter/mcp.json の中身、そして offline_mode を true にしたときにどのツールが落ちるかである。ここを読まずに Tavily や MinerU のキーだけ入れると、生成品質の差がどこから来ているのか切り分けられなくなる。
コミュニティノート