# Presentation Architect

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

- Skill: `nahisaho/presentation-architect` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nahisaho/presentation-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nahisaho/presentation-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: nahisaho (https://skillmd.com/u/nahisaho)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nahisaho/presentation-architect

---


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

## 概要

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

## 設計原則

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

## 実行手順

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

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

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

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

## 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`

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

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

| # | スライドタイトル | メインメッセージ | サポートデータ | ビジュアル指示 | トランジション | 想定時間(秒) |
|---|----------------|-----------------|---------------|--------------|---------------|-------------|
| 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` を元に、各スライドの詳細構成を定義する:

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

## スライド {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. **著作権侵害コンテンツの参照禁止** — 出典の権利関係を確認する