| 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 つのメインメッセージのみ
- 聴衆具体化原則 — 「幹部」ではなく「営業本部長の山田氏」
- 行動変容設計 — プレゼンの目的は「聴衆の行動を変える」こと
- エビデンス駆動 — 主張にはデータ・出典を紐付ける
実行手順
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 分
- タイトル / 自己紹介
- 背景 — なぜ今 AI for Science が重要か
- 現状分析 — 国内外の研究動向
- Gap Analysis — 課題と未解決問題
- 提案アプローチ — 技術概要
- Technical Architecture — システム構成
- 予備結果 / PoC データ
- 期待されるインパクト
- タイムライン / ロードマップ
- Ask — 協力依頼 / 予算要求
Microsoft HQ / 経営層向け: 30 分
- Executive Summary
- Why Now — 市場環境の変化
- Problem — 現在の課題
- Solution — 提案の全体像
- Microsoft Positioning — 競争優位性
- Technical Architecture（簡略版）
- Evidence — 実績・データ
- Customer Impact — 導入事例
- Competitive Landscape
- Financial Projections / ROI
- Roadmap — 実行計画
- Risk & Mitigation
- 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（品質ゲート）
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 つ
- 抽象的聴衆記述禁止 — 「幹部」「関係者」ではなく具体名・役職で記載
- 時間配分なし設計禁止 — 全スライドに想定時間（秒）を付与する
- Q&A バッファ省略禁止 — 持ち時間の 5% 以上を Q&A に確保する
- 起承転結構造の無条件採用禁止 — 聴衆分析に基づき構造を選択する
- Phase 3 領域への侵入禁止 — 具体的な文言・表現の作り込みは行わない
- research-notes.md の無視禁止 — 存在する場合は必ず参照・反映する
- 著作権侵害コンテンツの参照禁止 — 出典の権利関係を確認する
