presentation-architect

name	presentation-architect
description	プレゼンテーション全体の設計を行うコアスキル。聴衆分析・ペルソナ最適化・ストーリーライン生成・ スライド構成・時間配分を実行し、requirements.md / storyline.md / slide-outline.md を出力する。 AI for Science / 政策提言 / 技術戦略（MEXT, Microsoft HQ, 経営層）向けに最適化。 Use when 「プレゼンを作りたい」「発表資料を作成して」「スライドを設計して」「構成を考えて」 「ストーリーラインを作って」「要件を定義して」。

Presentation Architect — Phase 1: 全体設計（★コアスキル）

概要

PrezenX スイートの中核スキル。プレゼンテーションのタイトルと基本情報から、 聴衆分析・ストーリーライン・スライド構成・時間配分を設計し、 以降のフェーズ（コンテンツ作成・HTML 生成）の基盤となる設計ドキュメントを生成する。

設計原則

1. 1スライド1メッセージ原則 — 各スライドは 1 つのメインメッセージのみ
2. 聴衆具体化原則 — 「幹部」ではなく「営業本部長の山田氏」
3. 行動変容設計 — プレゼンの目的は「聴衆の行動を変える」こと
4. エビデンス駆動 — 主張にはデータ・出典を紐付ける

実行手順

Step 1: 要件定義（requirements.md 生成）

ユーザーから以下の情報を収集し、requirements.md を生成する。 不足情報がある場合は具体的な選択肢を提示して確認する。

要件テンプレート: requirements.md

# プレゼンテーション要件定義

## 1. 基本情報
| 項目 | 内容 |
|------|------|
| タイトル | {仮タイトル — Phase 3 で確定} |
| 発表日 | {YYYY-MM-DD} |
| 持ち時間 | {N分}（Q&Aバッファ: {M分}含む） |
| 会場 | {会場名 / オンライン} |
| 発表者 | {氏名・役職} |
| 言語 | {日本語 / 英語 / バイリンガル} |

## 2. 聴衆分析
| 項目 | 内容 |
|------|------|
| 参加者数 | {N名}（推定） |
| 主要人物 | {具体名・役職 — 意思決定権限を持つ人} |
| 知識レベル | {技術: 高/中/低, ビジネス: 高/中/低} |
| 態度 | {好意的 / 中立 / 懐疑的} |
| 意思決定権限 | {予算承認 / 方針決定 / 技術選定 / なし} |
| 関心事項 | {ROI / 技術革新 / リスク / 競争力 / 政策整合性} |

## 3. 目的設定
| 項目 | 内容 |
|------|------|
| 主目的（行動変容） | {聴衆に何をしてほしいか — 動詞で記述} |
| 副目的 | {認知向上 / 関係構築 / 情報共有} |
| 成功基準（定量） | {例: 承認を得る / 予算確保 / 次回会議設定} |
| 失敗基準 | {例: 質問ゼロ / 否定的フィードバック} |

## 4. 制約条件
| 項目 | 内容 |
|------|------|
| コンテンツ制約 | {NDA対象, 未公開データ, 公開範囲} |
| 技術制約 | {投影環境, 解像度, ネットワーク有無} |
| アクセシビリティ | {色覚配慮, フォントサイズ最小値} |

## 5. リサーチ結果参照
{research-notes.md が存在する場合、主要発見を引用・参照}

Step 2: 聴衆分析の深掘り

主要人物ごとに以下を分析する:

分析項目	内容
名前・役職	具体名（「CFO」ではなく「CFO 田中太郎氏」）
関心領域	この人物が最も気にすること
懸念点	この提案に対して持ちうる不安
響くメッセージ	行動を促すのに最も効果的な表現
知識レベル	技術/ビジネスそれぞれのレベル

Step 3: ストーリーライン設計（storyline.md 生成）

起承転結型ではなく、以下の構造を使用する:

AI for Science / 政策提言向け構造

Background → Current State → Gap Analysis → Proposed Approach
→ Technical Architecture → Expected Impact → Timeline → Ask

経営層 / 投資判断向け構造

Why Now → Problem → Solution → Evidence → Microsoft Positioning
→ Competitive Advantage → Roadmap → Call to Action

ストーリーラインテンプレート: storyline.md

# ストーリーライン: {タイトル}

## 全体構造: {構造タイプ名}

| # | スライドタイトル | メインメッセージ | サポートデータ | ビジュアル指示 | トランジション | 想定時間(秒) |
|---|----------------|-----------------|---------------|--------------|---------------|-------------|
| 1 | {title} | {1メッセージのみ} | {データ・出典} | {図解/グラフ/画像の種類} | {前後の接続} | {N秒} |

## 時間配分サマリー
| セクション | スライド数 | 合計時間 | 持ち時間比 |
|-----------|-----------|---------|-----------|
| 導入 | {N} | {M秒} | {X%} |
| 本論 | {N} | {M秒} | {X%} |
| 結論 | {N} | {M秒} | {X%} |
| Q&Aバッファ | — | {M秒} | {5-10%} |
| **合計** | **{N}** | **{M秒}** | **100%** |

Step 4: スライドアウトライン生成（slide-outline.md 生成）

storyline.md を元に、各スライドの詳細構成を定義する:

# スライドアウトライン: {タイトル}

## スライド {N}: {タイトル}
- **メインメッセージ**: {1つだけ}
- **ビジュアルタイプ**: {図解 / データグラフ / 画像 / テキスト主体}
- **コンテンツ要素**:
  - {箇条書き / データテーブル / 引用 / コード例}
- **データソース**: {出典 URL or research-notes.md 参照}
- **ノート**: {発表者ノートの要点}
- **トランジション**: {次スライドへの接続文}

Step 5: 時間配分の検証

制約	ルール
スライドあたり最大時間	120 秒（2 分）超過は分割を検討
スライドあたり最小時間	30 秒未満は統合を検討
Q&A バッファ	持ち時間の 5〜10% を確保
合計時間	持ち時間の ±5% 以内に収める
タイトルスライド	15〜30 秒
Thank You スライド	含めるが時間配分には加えない

典型的なスライド構成パターン

AI for Science（MEXT / 学術向け）: 15〜20 分

1. タイトル / 自己紹介
2. 背景 — なぜ今 AI for Science が重要か
3. 現状分析 — 国内外の研究動向
4. Gap Analysis — 課題と未解決問題
5. 提案アプローチ — 技術概要
6. Technical Architecture — システム構成
7. 予備結果 / PoC データ
8. 期待されるインパクト
9. タイムライン / ロードマップ
10. Ask — 協力依頼 / 予算要求

Microsoft HQ / 経営層向け: 30 分

1. Executive Summary
2. Why Now — 市場環境の変化
3. Problem — 現在の課題
4. Solution — 提案の全体像
5. Microsoft Positioning — 競争優位性
6. Technical Architecture（簡略版）
7. Evidence — 実績・データ
8. Customer Impact — 導入事例
9. Competitive Landscape
10. Financial Projections / ROI
11. Roadmap — 実行計画
12. Risk & Mitigation
13. Call to Action

Validation Loop（検証ループ）

設計検証チェック

1. requirements.md を走査:
   - 聴衆が具体名で記載されているか → 抽象的なら修正要求
   - 主目的が動詞で記述されているか → 名詞なら動詞に変換
   - 成功基準が定量的か → 定性的なら具体数値を追加

2. storyline.md を走査:
   - 各スライドのメインメッセージが 1 つか → 複数あれば分割
   - 時間合計が持ち時間の ±5% 以内か → 超過/不足なら調整
   - Q&A バッファが 5-10% 確保されているか → 不足なら追加

3. slide-outline.md を走査:
   - データソースが全スライドに付与されているか
   - ビジュアルタイプが指定されているか
   - トランジションが論理的に繋がっているか

4. 全チェック通過 → ⏸️ ユーザー承認 → Phase 2（コンテンツ作成）へ

Failure Recovery（失敗時リカバリ）

失敗パターン	原因	リカバリ手順
聴衆情報が不足	ユーザーが詳細を知らない	想定ペルソナ 3 パターンを提示し選択させる
持ち時間が未定	会議アジェンダ未確定	15分 / 30分 / 60分の 3 パターンで設計
目的が曖昧	「情報共有」のみ	「情報共有の結果、何が起きてほしいか」を質問
スライド数過多	内容詰め込み	1スライド1メッセージ原則で統合・削減
構造タイプ不一致	聴衆に合わない構造選択	聴衆分析を再実行し構造を再選定

Quality Gates（品質ゲート）

• requirements.md の全項目が埋まっている（TBD なし）
• 聴衆の主要人物が具体名・役職で記載されている
• 主目的が行動変容（動詞）で記述されている
• 成功基準が定量的に設定されている
• storyline.md の各スライドのメインメッセージが 1 つだけ
• 時間配分の合計が持ち時間の ±5% 以内
• Q&A バッファが持ち時間の 5〜10% 確保されている
• ストーリーライン構造が聴衆タイプに適合している
• slide-outline.md の全スライドにデータソースが明記
• research-notes.md が存在する場合、主要発見が反映されている

Gotchas（落とし穴）

1. ペルソナ過最適化の罠 — 特定 1 名への過剰適応

意思決定者 1 名（例: 予算承認者）に最適化しすぎると、他の参加者を置き去りにする。 主要人物は最大 3 名まで設定し、各人物の関心事項をバランスよくカバーすること。 特に MEXT 向けでは「政策担当者」と「研究者」の両方を意識する。

2. 時間見積もりの甘さ — Q&A バッファ不足

発表者は自分のスピードを過大評価する。Q&A バッファとして持ち時間の 5〜10% を 必ず確保する。30 分の発表なら 2〜3 分の Q&A 時間を確保。 日本の会議ではQ&Aが延びやすいため、10% 推奨。

3. 要件の抽象化禁止 — 「幹部」を使わない

「経営幹部向け」「管理職向け」のような抽象的な記述は設計品質を著しく低下させる。 具体名・具体役職・具体的な関心事項で記述すること。 情報がない場合は「想定ペルソナ」として仮名・仮役職を設定する。

4. ストーリーラインの過詳細化 — Phase 1 の境界

Phase 1 では構造と流れを決める。スライド内の具体的な文言・表現・ ビジュアルの詳細は Phase 3（コンテンツ作成）の領域。 ここで文章を書き始めると手戻りが発生する。

5. 起承転結型の使用回避

日本語プレゼンでありがちな「起承転結」構造は、経営層・政策立案者には不向き。 結論（Ask）を先に持ってくる構造を採用する。 ただし学術発表では Background-first が適切な場合もある — 聴衆分析で判断する。

Memory Persistence（記憶の永続化）

過去の設計で学んだパターン:

• MEXT 向け: 「国家戦略との整合性」セクションは必須。予算要求なら 第6期科学技術・イノベーション基本計画との紐付けが効果的
• Microsoft HQ 向け: 最初の 3 スライドで結論を伝える。Detail は Appendix に
• 経営層: ROI を提示するなら「投資しない場合のコスト」も併記すると説得力が増す
• 時間配分: 実測では計画の 1.2〜1.5 倍かかる。設計時点で 80% 目安にすると安全
• AI for Science: 「なぜ AI なのか」「なぜ今なのか」の 2 つの Why が導入部で必須

禁止事項

1. 1スライド複数メッセージ禁止 — 各スライドのメインメッセージは必ず 1 つ
2. 抽象的聴衆記述禁止 — 「幹部」「関係者」ではなく具体名・役職で記載
3. 時間配分なし設計禁止 — 全スライドに想定時間（秒）を付与する
4. Q&A バッファ省略禁止 — 持ち時間の 5% 以上を Q&A に確保する
5. 起承転結構造の無条件採用禁止 — 聴衆分析に基づき構造を選択する
6. Phase 3 領域への侵入禁止 — 具体的な文言・表現の作り込みは行わない
7. research-notes.md の無視禁止 — 存在する場合は必ず参照・反映する
8. 著作権侵害コンテンツの参照禁止 — 出典の権利関係を確認する