PPT Agent — 建築提案向けAIプレゼン資料生成システム

1. 業務背景

利用シーン：建築家はコンペ提案や中間報告の段階で、数十から数百点のばらばらな素材を 30〜60ページほどの、統一感があり、話の流れが通ったプレゼン資料にまとめる必要があります。 設計事務所では、この作業にインターン1人が丸ごと1〜2週間かかることも珍しくありません。

主な課題：

• 素材の種類が多く、名前の付け方もばらばらで、ページ単位で整理しにくい
• 文章作成、レイアウト、図版選びが互いに絡み、何度も手戻りが起きる
• LLMにそのままスライドを作らせると制御しづらい。数字を作ってしまうか、レイアウトが崩れるかのどちらかで、一部分だけ直すのも難しい

2. システム全体像

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ フロントSPA  │───▶│   FastAPI    │───▶│ PostgreSQL   │
│ (フロー駆動) │    │   Routers    │    │ + pgvector   │
└──────────────┘    └──────┬───────┘    └──────────────┘
                           │
                  ┌────────┼────────┐
                  ▼        ▼        ▼
              ┌───────┐ ┌──────┐ ┌────────┐
              │ Agent │ │Celery│ │ Render │
              │  層   │ │Tasks │ │Engine  │
              └───┬───┘ └──┬───┘ └───┬────┘
                  │        │         │
                  └────────┼─────────┘
                           ▼
                    ┌──────────────┐
                    │ HTML→PNG→PDF │
                    └──────────────┘

重要な設計判断：

• 1つの Orchestrator Agent で全体を回すのではなく、FastAPI のバックグラウンドスレッド + Celery タスクを明示的につないでいます
• 状態管理はデータベースの Project.status に直接持たせ、途中再開は「DB を読む → 該当ステージから入り直す」で実現しています
• LLM 呼び出しは OpenRouter に統一し、自前の薄いラッパーでスキーマ検証、リトライ、同時実行数の制御を行います

3. 中核フロー：素材パッケージのパイプライン

ローカル素材フォルダ
    │
    ▼  ① ingest（ルールベースの走査 + 分類 + 重複排除）
MaterialPackage
  ├── MaterialItem    (元ファイル単位)
  ├── Asset           (派生アセット: グラフ、地図、事例カード)
  └── ProjectBrief    (素材から抽出した案件の基本情報)
    │
    ▼  ② BriefDoc Agent (LLM)
BriefDoc (ストーリーライン / 章構成)
    │
    ▼  ③ Outline Agent (Claude Opus 高性能モデル)
OutlineSpec (8〜12ページ設計: 各ページの目的と必要な素材タイプ)
    │
    ▼  ④ MaterialBinding (ルールベースの照合、LLMなし)
SlideMaterialBinding (各ページにひもづく素材 + 派生アセット + 根拠)
    │
    ▼  ⑤ VisualTheme Agent
案件全体のフォント / 配色 / 装飾ルール
    │
    ▼  ⑥ Composer Agent (Claude Haiku 高速モデル + asyncio 並列)
LayoutSpec × N (各ページの構造化レイアウト記述)
    │
    ▼  ⑦ Jinja2 + Playwright
HTML → PNG スクリーンショット
    │
    ▼  ⑧ Critic Agent (3段階レビュー + 自動修正 最大3回)
    │
    ▼  ⑨ Export
PDF

各ステージの説明

4. 設計上のポイント

4.1 素材パッケージ：幻覚を防ぐいちばん確実な方法

課題：初期版では、LLM に自由対話からそのままスライドを生成させていたため、 数字は作り物になり、引用元は追えず、1ページ直すだけでも全体を作り直す必要がありました。

対応：ユーザーの素材をまず MaterialPackage として固定し、 パイプライン全体の唯一の信頼できる情報源にします。以降の Agent は、 MaterialPackage にある内容しか使えず、勝手に補えません。

4.2 素材の対応付け：ルールベースの照合 vs LLM の判断

課題：LLM に「5ページ目にどの画像を置き、どの文章を添えるか」を決めさせると、 存在しない画像を参照したり、事例Aの画像を事例Bの文章の横に置いたりします。

対応：MaterialBinding は純粋な Python のルールベース処理です。 Outline で宣言された「必要な素材タイプ + tag」に沿って MaterialPackage から一致候補を探します。 LLM はこの段階に関与しません。

4.3 高性能モデルと高速モデルの使い分け

効果：単ページ生成は asyncio.gather で8並列にし、全体の待ち時間を抑えています。 さらに Critic の意味レビューで、高速モデルが落としがちな細部を補います。

5. レビューと修正の仕組み（Critic）

LLM 出力の不安定さは、3段階のレビュー + 局所修正で収束させます。

判定フロー

P0 修復不可       ──▶  ESCALATE_HUMAN  （失敗として扱い、人の対応を待つ）
P0/P1 自動修復可  ──▶  REPAIR_REQUIRED （自動修復、最大3回まで再試行）
P2 のみ           ──▶  REPAIR_REQUIRED （修復するが書き出しは止めない）
問題なし          ──▶  PASS

6. 参考事例RAG（pgvector）

案件の雰囲気に近い参考事例を事例庫から呼び出し、Outline / VisualTheme Agent の参考にします。

データフロー

ProjectBrief (建物種別 / スタイルの好み / 規模)
    │
    ▼  build_query_text()  → フィールドをつないで検索文を作る
    ▼  get_embedding()     → 1536 次元ベクトル
pgvector のコサイン距離検索 (IVFFlat インデックス)
    │
    ▼  rerank_cases()      → 業務ルールで並べ替え
    ▼  preference_summary  → 好みの要約 → VisualTheme Agent に渡す

主要 SQL

SELECT ..., 1 - (embedding <=> CAST(:vec AS vector)) AS similarity
FROM reference_cases
WHERE building_type = :building_type
ORDER BY embedding <=> CAST(:vec AS vector)
LIMIT :top_k

実装上の工夫

7. 技術スタック

8. 主な設計判断

9. 実装上の難所

10. 今後の拡張

• PPTX 出力：python-pptx の経路を補い、デザイナーが二次編集できるようにする
• 見た目レビューの閉ループ化：L3 の見た目レビューは今は問題を付けるだけで自動修正しないため、 Critic が修正指示を出し、Composer に戻す形にしたい
• 素材パッケージ単位の RAG：今は参考事例庫だけを対象にしているが、将来は案件自身の素材も索引化し、 「意味で素材を探す」を可能にしたい
• Workflow から Agent へ：現状は決まったパイプラインだが、「結果が気に入らない → どのページを直すかを自律判断 → 複数回再生成」のような要件が出たら、LangGraph で部分的な Agent 化を検討する

11. 覚えてほしい3つのポイント