apollo-pptx

name	apollo-pptx
description	APOLLOの分析結果からコンサルティングファーム品質のPowerPointスライドを生成する。PPT作成、スライド作成、プレゼン資料作成で起動。
command	/pptx

APOLLO PPTXスキル — コンサルティングレポート品質のスライド生成

⚠️ 優先順位ルール（最重要・厳守）

スライド生成時は capcom_schema/templates/slides_spec.md を最優先で参照すること。

• 本SKILL.mdの記述（関数名・スライド比率・ポンチ絵パターン数・カラー定義など）と slides_spec.md の記述が矛盾する場合、必ず slides_spec.md を採用する
• 本SKILL.mdは概要・起動条件・運用ルールを示すメタ文書であり、実装仕様の正は slides_spec.md（現行 v5.0、スライドタイプ15種）にある
• 関数名の正は slides_spec.md 付録「コア関数一覧」/「スライドタイプ一覧」。古い別名（add_process_flow / add_matrix_2x2 / add_kpi_cards / add_pyramid / add_comparison_table / add_timeline / add_footer）を見たら、実在する add_process_slide（縦）・add_arrow_flow_slide（横）・add_matrix_2x2_slide（軸付き2×2・推奨）・add_kpi_slide・add_pyramid_slide・add_table_slide・add_timeline_slide・add_bottom_bar_and_footer 等に読み替えること

概要

APOLLOのCAPCOMセッションデータ（JSON + スナップショット画像）から、python-pptxを使ってコンサルティングファーム品質のPowerPointスライドを自動生成する。

起動条件

• ユーザーが /pptx コマンドを実行
• ユーザーが「スライドを作って」「PPTを生成して」「プレゼン資料を作って」と依頼

前提条件

• CAPCOMセッションフォルダ（output/session_xxx/ または ZIPを展開したフォルダ）が存在すること
• capcom_schema/templates/slides_spec.md を仕様書として参照すること
• capcom_schema/templates/apollo_template.pptx をテンプレートとして使用すること
• pip install python-pptx Pillow が必要

設計原則（slides_spec.mdに準拠）

可視化ファースト原則

• チャート・図が主役、テキストは注釈
• チャート+注釈スライドが40%以上
• テキスト主体（ナラティブ）は15%以下に制限

タイトル＝結論 原則

• スライドタイトルは結論そのもの（ラベルではない）
• 結論を1文で言い切る。波ダッシュ「～」は使わない（補足が要れば全角ダッシュ「—」か句点で短い2文に）
• 例: 「上位5クラスタが全体の58%を占有。技術集中化が加速し差別化領域の特定が急務」

■サブメッセージ

• タイトル直下に■マーカー付き1-2行テキスト
• KEY_MSG_BG背景ボックス + 左ACCENTバーで囲む

フォント

• Noto Sans JP 統一（日英とも）。ウェイトを多段に使い分ける（見出し=Black / サブメッセージ・小見出し=Medium / 本文=Regular / 出典・フッター=Light、強調語のみ Bold）。_apply_font(run, weight=...) 等で指定（slides_spec §フォント）
• 全runに lang="ja-JP" 明示
• 禁則処理適用

カラーパレット

NAVY:        #1B2A4A  (タイトル、強調)
BLUE:        #2E5090  (セクションヘッダー背景)
ACCENT:      #3B7DD8  (アクセントバー)
DARK_GRAY:   #333333  (本文)
MEDIUM_GRAY: #666666  (補足)
LIGHT_GRAY:  #F2F2F2  (テーブルゼブラ)
KEY_MSG_BG:  #E8F0FE  (強調ボックス)
RED_ACCENT:  #D64545  (マイナス指標)
GREEN_ACCENT:#2E8B57  (ポジティブ指標)

スライド構成

必須スライド

1. 表紙 — ネイビー背景、白文字タイトル + Mission Objective + 日付
2. エグゼクティブサマリー — KPI 3-4個 + 結論3点
3. 目次 — 章立て一覧

分析スライド（モジュール別、利用可能なデータに応じて選択）

⚠️ 下表の JSON/スナップショットは 「数値」と「図版」の供給源。「何を言うか（主張・論理・要点）」の供給源は完成レポート reports/report.typ（実装手順②）。下表だけを見て1モジュール1枚で機械的に割り付けず、レポートの論証に沿って束ねること。

モジュール	スライドタイプ	データソース
ATLAS	出願トレンド（棒グラフ+注釈）	atlas_statistics.json
ATLAS	出願人ランキング + HHI/Entropy/Gini	atlas_statistics.json
Saturn V	技術ランドスケープ（スナップショット画像+注釈）	saturnv_clusters.json + snapshots/
Saturn V	クラスタ動態マップ（4象限+注釈）	saturnv_clusters.json の cluster_dynamics
Saturn V	ノイズ分析（萌芽テーマ）	saturnv_clusters.json の noise_analysis
MEGA	PULSE 4象限（軸別・スナップショット+注釈）	mega_momentum_<軸>.json (applicant/ipc/fterm) + snapshots/
Explorer	共起ネットワーク（スナップショット+注釈）	snapshots/
Explorer	急上昇キーワード（テーブル）	explorer_*.json
CREW	ネットワーク分析（スナップショット+注釈）	snapshots/
NEBULA	Hype Cycle（スナップショット+注釈）	nebula_hype_cycle.json
NEBULA	学術ランドスケープ（スナップショット+注釈）	nebula_academic_clusters.json
NEBULA	学術クラスタ動態マップ	nebula_academic_clusters.json の cluster_dynamics

必須締めスライド

• 仮説検証サマリー — CAPCOMレポートの仮説検証テーブルをスライド化。各仮説の判定（✅/❌/⚠️）と根拠を1行ずつ
• 戦略提言 — add_process_slide()（縦STEP）または add_arrow_flow_slide()（横向き矢羽根）で短期→中期→長期のフロー ← テキストのみ禁止、ポンチ絵必須
• Appendix — データセット概要、分析パラメータ

テキストのみスライドへのポンチ絵割り当て（⚠️ 必ず適用）

以下のスライドタイプは画像がないためテキストのみになりがち。必ず対応するポンチ絵を生成すること:

スライド	ポンチ絵	関数
エグゼクティブサマリー	KPIカード行（3-4指標）	add_kpi_slide()
超領域解説（Saturn V）	2×2マトリクス（成長/成熟ポジション・軸付き）	add_matrix_2x2_slide()
ホワイトスペース	ピラミッド（特許化の機会を層別表示）	add_pyramid_slide()
主要発見サマリー	横向き矢羽根フロー（発見1→2→3→4）	add_arrow_flow_slide()
構成比（クラスタ別件数・出願人シェア）	ドーナツ図	add_donut_slide()
論点分解（なぜ?の要因分析）	Issue Tree／ロジックツリー	add_issue_tree_slide()
推奨アクション	プロセスフロー（短期→中期→長期）	add_process_slide() / add_arrow_flow_slide()
仮説検証	仮説検証テーブル（仮説/判定/根拠）	add_hypothesis_slide() / add_table_slide()
NEBULAマクロ環境	タイムライン（政策イベント時系列）	add_timeline_slide()
競争構造	2×2マトリクス（業種×ポジション・軸付き）	add_matrix_2x2_slide()

スライドレイアウト種別

1. チャート+注釈（最頻出、40%以上使用）

|  チャート画像 (60%)  |  テキスト注釈 (40%)  |
|  snapshots/xxx.png  |  ■ 要点1          |
|                     |  ■ 要点2          |
|                     |  ■ 要点3          |

2. デュアルパネル（比較用）

|  チャート1 (50%)    |  チャート2 (50%)    |
|  Before / Patent    |  After / Academic   |

3. テーブル+注釈

|  データテーブル (60%) |  テキスト注釈 (40%) |

4. ナラティブ（エグゼクティブサマリー等、最小限）

|  タイトル（結論型）                        |
|  ■ サブメッセージ                         |
|  本文テキスト（箇条書き、最大5項目）        |

レイアウト連動ルール（重要）

タイトルとサブメッセージの位置は必ず連動させること。固定座標でハードコードしてはならない。

# ✅ 正しい使い方: タイトルの戻り値でサブメッセージの位置を決める
sub_y = add_title_shape(slide, "上位5クラスタが全体の58%を占有。技術集中化が加速")
content_y = add_sub_message(slide, "クラスタ0「CNF強化ゴム」が最大（48件）...", y=sub_y)  # 先頭に■を付けない（自動付与）

# ❌ 間違い: y座標をハードコードするとタイトルとボックスが重なる
add_title_shape(slide, "長いタイトル...")
add_sub_message(slide, "...", y=0.90)  # タイトルが長いと重なる

add_title_shape() はタイトルの長さに応じてフォントサイズと高さを動的調整し、サブメッセージの開始y座標を返す。add_sub_message() はボックス下端のy座標を返す。コンテンツ（チャート・テーブル等）はその戻り値を起点に配置する。

実装手順

1. capcom_schema/templates/slides_spec.md を設計ガイドとして読み込む（いつ・どのヘルパーを・どんな主張骨格で使うか）。ヘルパー実装は apollo_slides.py を import して使う（コピーしない）: 生成スクリプト冒頭で import sys; sys.path.insert(0, "capcom_schema/templates"); from apollo_slides import *
2. 🔑 完成レポート reports/report.typ を通読する（最優先） — デッキはレポートの論証の凝縮版であり、evidence の寄せ集めではない。各章の「主張・根拠（数値）・示唆（So what）・章どうしの繋がり」を把握し、スライドの章立て（物語アーク）をレポートの章順に合わせる（slides_spec §0.9）。report_executive.typ があれば要約版の骨子にも使う
3. セッションフォルダの data/ と snapshots/ と voyager/mission.json / voyager/context.json を確認
   • context.json の report_directives.image_slide_instruction を必ず読む: 値があれば「どの画像をどのスライドで使うか」をユーザー指示として最優先で反映する（例:「表紙にクラスタ動態マップ」「権利化率マップはスライド必須」）。空ならAIが最適な画像を選ぶ
   • 役割分担: レポート=「何を言うか（論理・要点）」／data/*.json=正確な数値／snapshots/=図版／voyager/*=Missionと画像指示。画像はクリーン版（要点・出典なし）なので スライドには要点（■サブメッセージ）が必須。要点は ②のレポート該当章 から作る（evidence の description だけで埋めない）
4. 利用可能なデータに応じてスライド構成を決定（モジュール羅列にせず、レポートの章順＝前提→サマリー→環境→俯瞰→動態→競争→クロス統合→仮説検証→結論・提言→将来 に沿わせる）
5. import した apollo_slides のヘルパー（add_* 各関数）を呼んで各スライドを生成（slides_spec.md の設計指針＝どのヘルパーをどう使うかに従う。ヘルパー実装を本文へ写経しない）
6. 各スライドのタイトル→サブメッセージ→コンテンツは必ず戻り値を連鎖させる
7. 出力先: reports/ フォルダに apollo_report_YYYYMMDD.pptx

デザインルール（厳守）

フッター

• フッターのテキストは**「APOLLO」のみ**（「APOLLO CAPCOM」は不可）
• add_bottom_bar_and_footer(slide, page_num)（フッターは「APOLLO」固定）

テキスト量と中身（薄さの根治・slides_spec §0.9）

• 論理を運ぶ（事実の刈り取り禁止）: 各スライドは「1論点」を 主張→根拠（数値）→示唆（So what） の最小ロジックで語る。レポート該当章に既にこの連鎖があるので凝縮する。
  • ❌ 薄い: 「■ 特許は2019年ピーク／■ 学術は増加中／■ ニュースは2017年」（事実断片の列挙）
  • ✅ 良い: 「■ 特許は2019年208件でピーク後に減少だが公開ラグで衰退と断定不可／■ 学術は2025年593件まで加速継続＝研究と特許化に位相差／■ この位相差が研究先行のホワイトスペースの根拠」
• 適量: コンテンツ面の本文（サブメッセージ＋注釈）は合計 250〜400字目安（良質デッキ実測 中央333字。下限で作ると薄くなるので250字を最低ライン）。図がある面も本文を薄くしない（リード文＋読み取り注釈を添える）。1枚に論点は1つ。薄い面がコンテンツ面の3割超で Phase D Check 16e FAIL。
• サブメッセージ（■ボックス）: 2行以内（80文字以内）。結論を述べる。
• 注釈テキスト（チャート横）: 4〜6項目、各1〜2行（各40〜70字）。各項目が「数値＋含意」の完結した思考。体言止めの単語だけにしない。
• 長い文章をそのまま1つのテキストボックスに入れることは禁止。必ず■マーカーで分割する
• テキストボックスの幅に対してフォントサイズが大きすぎると不自然な改行が発生する。注釈は14pt、サブメッセージは16ptを厳守

出所（出典）の書き方（⚠️ 分析モジュールを"出所"にしない・slides_spec §0.9-D）

• ❌ （出所）NEBULA ハイプサイクル分析 のように 分析モジュール名を出所として掲げない（出どころは分析機能でなくデータ）。モジュール/ブランド機能名（Saturn V TELESCOPE・MEGA PULSE 等）は 本文・サブメッセージ側で「〜分析によれば」と使う。
• ✅ 特許データ由来 → （出所）本分析の特許データセット（日本語公報 N件・期間）。学術/ニュース由来 → （出所）学術論文データ / ニュースデータ。
• ✅ Web調査由来の事実 → 実際の出所（サイト名・URL・取得日。reports/report.typ の脚注／付録C から転記）。同じ出所を全スライドに機械貼りしない。

図表・ポンチ絵の必須掲載

• 全分析スライド（セクション区切りを除く）に最低1つの視覚要素を含めること
• テキストのみのスライドは絶対禁止（エグゼクティブサマリーでもKPIカードを入れる）
• snapshots/ に画像がある場合はfit_image()で優先掲載する
• 画像がない章にはポンチ絵を積極的に生成する（slides_spec.mdのポンチ絵パターンを参照）

ポンチ絵の使用ガイド（コンサル・シンクタンク品質）

slides_spec.mdに6種のポンチ絵パターンのコードが定義されている。以下の基準で使い分けること:

パターン	関数名	使用場面
縦STEPプロセス	add_process_slide()	技術進化の段階、ロードマップ（例: 探索期→成長期→成熟期→第二成長期）
横向き矢羽根フロー	add_arrow_flow_slide()	横方向のプロセス/因果フロー（探索→俯瞰→動態→提言）。コネクタ厳禁・CHEVRON使用
2×2マトリクス（軸付き）	add_matrix_2x2_slide()	MEGA 4象限の解釈、クラスタ動態の4象限（成長リーダー/新興/成熟/ニッチ）。軸の矢印・象限ラベル自動描画
ドーナツ図	add_donut_slide()	構成比（クラスタ別件数・出願人シェア）。BLOCK_ARCで描画（色付き矩形の羅列にしない）
Issue Tree／ロジックツリー	add_issue_tree_slide()	「なぜ?」の要因分解・論証骨格（根→枝）。コネクタ厳禁・RIGHT_ARROW使用
KPIダッシュボード	add_kpi_slide()	エグゼクティブサマリー冒頭、各モジュールの主要数値（件数/CAGR/HHI等）
ピラミッド	add_pyramid_slide()	技術階層（基盤技術→応用技術→萌芽技術）、3段ロケット構造
テーブル+注釈	add_table_slide()	出願人TOP5比較、クラスタ間比較（読み取り結論を必ず併記）
仮説検証テーブル	add_hypothesis_slide()	仮説ID/内容/判定（✅/❌/⚠️）/根拠
タイムライン	add_timeline_slide()	NEBULA政策イベント、技術マイルストーン、出願の転換点

ポンチ絵の推奨使用場面（必ず検討すること）:

1. エグゼクティブサマリー: KPIカード行（4指標） ← 必須
2. ATLAS: タイムラインで出願の4期区分を可視化
3. Saturn V: 2×2マトリクスでクラスタ動態の4象限を図解
4. MEGA: 2×2マトリクスでPULSE 4象限のプレイヤー配置
5. 戦略提言: 矢印プロセスフローで短期→中期→長期アクションを表現
6. NEBULA: タイムラインで政策・市場イベントを時系列表示
7. 技術階層: ピラミッドで基盤→応用→萌芽の3層構造を図解

スライド構成比率の厳守

スライドタイプ	比率	条件
チャート+注釈	50%以上	画像左(60%) + 注釈右(40%)
デュアルパネル	10-15%	2画像並列比較
テーブル+注釈	10-15%	データテーブル + 考察
ナラティブ	10%以下	エグゼクティブサマリー・提言のみ
セクション区切り	残り	モジュール名 + 1行説明

タイトルの視認性

• タイトルは24pt Bold Navy。スライド上部に明確に配置
• タイトルの区切りは余白または背景色の差を既定とする（全幅アクセント線はAI生成スライドの典型のため既定では使わない。使うなら細く控えめに ← 上記「外部公開スキル由来 §C」を優先）
• サブメッセージとコンテンツの間にも十分な余白（0.1インチ以上）を確保

テキストの改行制御

• word_wrap = True を全テキストボックスに設定
• auto_size = MSO_AUTO_SIZE.NONE でテキストボックスのサイズを固定
• テキストが溢れる場合はフォントサイズを下げるか、テキストを短縮する
• 日本語テキストで句読点が行頭に来る禁則処理: _apply_kinsoku() を全段落に適用

外部公開スキル由来のベストプラクティス（Anthropic 公式 pptx スキル等を応用）

公開されている Anthropic 公式 pptx スキルの知見を APOLLO 用に取り込む。最大の差分は 「生成して終わり」にせず、レンダリング→目視検証→修正→再検証のループを必ず回すこと。

A. ビジュアルQA検証ループ（⚠️ 必須・最重要）

「最初のレンダリングはほぼ必ずどこか崩れている。確認ではなくバグ探しのつもりで臨む。問題ゼロに見えたら、見方が甘い。」

1. pptx を画像化する（要 LibreOffice soffice + poppler pdftoppm。無ければ PowerPoint で開いて目視）:

   soffice --headless --convert-to pdf reports/apollo_report_YYYYMMDD.pptx --outdir reports/
   pdftoppm -jpeg -r 150 reports/apollo_report_YYYYMMDD.pdf reports/slide
   ls reports/slide-*.jpg   # 0埋め桁数は枚数で変わるので実ファイル名を使う
   

2. 生成画像を自分で1枚ずつ目視し問題を洗い出す（CAPCOMのトークン制約によりサブエージェントは使わず本体で確認）:
   • 要素の重なり（テキストが図形を貫通、線が文字に被る）／テキストのはみ出し・見切れ
   • タイトルが2行折返しなのに装飾が1行前提でズレ／フッター・出典が上の内容と衝突
   • 余白不足（要素間 < 0.3in、スライド端 < 0.5in）／列・カードの不揃い
   • 低コントラスト（薄背景に薄文字・暗背景に暗アイコン）／プレースホルダ消し忘れ
3. 見つけた問題を列挙（無いと思ったらもう一度厳しく見る）→ 修正 → 直したスライドを再レンダリングして再検証（1つの修正が別の崩れを生む）
4. 1巡して新たな問題が出なくなるまで繰り返す。最低1回の「修正→再検証」を完了するまで完成としない

B. 内容QA

python -m markitdown reports/apollo_report_YYYYMMDD.pptx            # 抜け・誤字・順序
python -m markitdown reports/apollo_report_YYYYMMDD.pptx | grep -iE "xxxx|lorem|ipsum|プレースホルダ|ここに記載"

grep がヒットしたら必ず修正してから完成とする。

C. "AIっぽいスライド" を避ける（外部スキルの強い指摘）

• タイトル下の全幅アクセント線は AI 生成スライドの典型とされる。既定は「余白」または「背景色の差」でタイトルを区切り、アクセント線は使うなら細く控えめに留める（下記「タイトルの視認性」より本節を優先）。
• レイアウトを毎回同じにしない（2カラム/カード/大数値コールアウト/タイムラインを使い分ける）。本文は左揃え（中央揃えはタイトルのみ）。

D. 表現力の引き上げ

• 大数値コールアウト（60-72pt の数字＋小ラベル）で主要KPI・CAGR・権利化率を見せる。
• 1つの視覚モチーフ（色付き円のアイコン・角丸画像枠 等）を全スライドで反復し統一感を出す。
• 配色は APOLLO ブランド（NAVY 主体）を基本に、1色を支配的（60-70%）＋差し色1で「均等配色」を避ける。

公開スキルの所在: Anthropic 公式 pptx スキル（html2pptx / OOXML編集 / テンプレート差込の3経路＋QA手順）。APOLLO は python-pptx + slides_spec.md 実装を正とするが、上記 QA ループと設計指針を必ず併用する。

品質チェックリスト

• ビジュアルQA: pptxを画像化し目視検証→修正→再検証を最低1巡したか（重なり/はみ出し/余白/低コントラスト）
• 内容QA: markitdownで抜け・誤字・プレースホルダ消し忘れを確認したか
• フッターが「APOLLO」になっているか（「APOLLO CAPCOM」は不可）
• 全スライドのタイトルが結論型（ラベル型は不可）
• チャート+注釈スライドが全体の50%以上
• ナラティブスライドが10%以下（エグゼクティブサマリー+提言のみ）
• 全分析スライドに図表が含まれているか
• 全runに Noto Sans JP + lang="ja-JP"（役割別ウェイトを使い分け）
• ■サブメッセージが2行以内か
• 注釈テキストが3-5項目の箇条書きか（長文ブロック不可）
• タイトルとサブメッセージが重なっていないか
• カラーパレット遵守（NAVY/ACCENT/DARK_GRAY）
• 表紙にMission Objective記載
• エグゼクティブサマリーにKPI 3-4個

トークン効率の注意（ツァーリ・ボンバ対策）

• サブエージェントを起動しない
• slides_spec.md は1回だけ読み、以降は会話内で参照する
• snapshots/ の画像は必要なものだけ読み込む