はじめに
PowerPointのスライドをAIに生成してほしいというニーズはありませんか？
会社で与えられたツールはM365Copilotだけで、PowerPointスライドをうまく作成できなかった経験はありませんか？
Copilot に自然言語で「◯◯の内容を分析してPowerPoint資料を出力してください」と指示しても、ただの文字のベタ打ちのような使えない資料となった経験はないでしょうか。
この記事では、Copilot Chatで文章の構成をJSON化し、それをそのままCopilot for PowerPointに貼り付けてスライドを生成するという、再現性の高いワークフローを紹介します。
Copilot in PowerPointを前提にしておりますが、他の生成AIでも同じ流れで生成AIにプロンプト命令をかけてもスライド作成することは可能です。
全体像：3ツールの分業
ツール役割ポイント
- Copilot Chatテキスト・構成・JSON設計の司令塔作業の8割はここで完結させる
- Copilot for Excel数値計算・グラフ作成（必要な場合のみ）グラフはExcel内Copilotで作るのが安定
- Copilot for PowerPoint JSONからスライド生成専任ここでは「考えさせない」。生成とマッピングだけを担わせる流れは一直線です。
Chatで構成設計 → （必要ならExcelでデータ整備）→ Chatで最終JSON化 → PowerPointにJSONを投入してスライド生成
なぜJSONなのか
自然言語プロンプトとJSONの違いを整理すると、こうなります。
課題自然言語プロンプトの弱点JSONでの解決書式・役割の推測ミスタイトルと本文の区別が毎回ブレるroleやfewWordで要素ごとの役割を明示レイアウト指示の黙殺複雑な配置指示が反映されないことがあるlayout（配置）とstructure（見せ方）を分離して指定境界の曖昧さコピペ時に区切りが不明確で重複・欠落が起きる{ } で物理的にデータが区切られるため事故が減る
ポイントは、「配置（Layout）」と「表現（Structure）」を独立したパラメータにすることと、要素ごとの役割（role）を強制的に固定することです。この2つによって、Copilotの解釈ブレをかなり抑え込めます。
手順
STEP1：Copilot ChatでJSONを生成する
PowerPoint化したい文章ができたら、まず、下記の「JSON生成プロンプト」をCopilot Chatに投入し、テーマを渡してJSONを出力させます。このプロンプトは20種類のスライド構造タイプ（比較表・ロジックツリー・ロードマップ・リスク対応表など）を状況に応じて自動選定し、slideSchemaVersion: 3.0 のスキーマに準拠したJSONを出力するように設計されています。
JSON画面イメージ
MIDDLEのパターン（20種類）
JSON生成プロンプト（クリックで展開）
PPT構成生成プロンプト
あなたは「PPT構成の編集者」兼「JSONスキーマ厳守の構造化ライター」です。
指定テーマのプレゼンを、全スライド分、スキーマ準拠のJSONで出力してください。
## 用途の指定(最重要・生成前に確定)
生成開始前に、今回作成する資料の用途を1つ選び、JSON冒頭のメタ情報 `presentationPurpose` に明記すること。用途によって以降のルール(intentの書き方・重視するtype・aiPromptHintのトーン)が変わる。
| purpose | 想定用途 | ゴール |
|---|---|---|
| `proposal` | 社内プレゼン・企画提案・稟議 | 意思決定を促す |
| `training` | 研修資料・マニュアル・オンボーディング | 理解・習得を促す |
| `report` | 定例報告・進捗報告・実績共有 | 事実を簡潔に伝える |
| `general` | 上記に当てはまらない汎用資料 | 制約なし |
ユーザーから用途の指定がない場合は、テーマ・依頼文から最も近いものを推定し、`presentationPurpose` に明記した上で生成する(無指定のまま`general`扱いにしない)。
## 基本ルール
- 出力はJSONのみ(説明禁止)
- 生成前に**総スライド数を固定**し、JSON冒頭のメタ情報として `totalSlides` に明記する(頻度制約の計算基準とするため)
- スライドごとに `topSection.intent` と `bottomSection.expectedOutcomes` が矛盾しないよう整合させる
- 索引・引用・参照元は明記する。インターネットから引用する場合はURLも記載する
- 配色・視覚スタイルは資料全体で統一する。`meta.designDefaults` に1回だけ定義し、個別スライドで例外的に変更したい場合のみ `designOverride` を使う(詳細は「デザイン指示ルール」参照)
## topSection / bottomSection の書き方(purpose別)
`intent` と `expectedOutcomes` は、purposeに応じて以下のように書き分ける。`expectedOutcomes` は配列とし、1スライドから複数の決定事項・複数の学習到達点が導かれる場合は複数要素を記述してよい(単一の場合も要素数1の配列とする)。
| purpose | topSection.intent の書き方 | bottomSection.expectedOutcomes の書き方 |
| ---------- | ------------------------ | ----------------------------------- |
| `proposal` | 「このスライドで求める判断は何か」 | 「このスライドから導き出されるべき意思決定」(複数可) |
| `training` | 「このスライドで習得させたい知識・スキルは何か」 | 「このスライドの重要事項、訴求事項」(複数可) |
| `report` | 「このスライドで共有すべき事実は何か」 | 「このスライドから読み取るべき現状認識」(複数可) |
| `general` | 「このスライドの目的」 | 「このスライドの結論・まとめ」(複数可) |
`bottomSection.note` には、決定事項・到達点の前提条件や補足(例:「予算承認が前提」「STEP1未了の受講者は別途フォロー」)を記述する。出典は書かない(出典は `sourceReference` / `citations` に記載)。
`middleSection.fewWord` も固定値にせず、purposeに応じて以下を目安に設定する。
- `proposal` → `"Decision material"`
- `training` → `"Learning content"`
- `report` → `"Status summary"`
- `general` → 内容に応じて自由記述
## structure.type 一覧
description | list | comparison | decisionTree | matrix | dataEvidence |
illustration | hybrid | pyramid | logicTree | kpiTree | framework |
valueChain | waterfall | asIsToBeGap | roadmap | scoring |
stakeholderMap | riskMitigation | actionPlan
`cards` と `flow` と `causeEffect` は仕様から除外済み。これらのtypeは生成しないこと。
- カード形式で並列施策を見せたい場合 → `pyramid`(結論+根拠)または `scoring`(選択肢比較)で代替する
- 時期を伴わない単純な手順の流れを見せたい場合 → `roadmap`(時期不明なら period を「未定」とする)または `list` で代替する
- 原因分析をしたい場合 → `asIsToBeGap.gaps` に統合して記述する
## structure.type 選定ルール(頻度制御)
- 同一 `structure.type` を2枚連続で使用しない
- `description` は単独、または `hybrid`(下記「hybrid運用ルール」参照)を通じて、全スライドの50%以上に含める
- `hybrid` の使用は全体の15%以下を目安とする
## structure.type 選定ルール(purpose別の重視クラスター)
purposeに応じて、以下のクラスターを優先的に採用する。ただし他クラスターの使用を禁止するものではない。
- `proposal` → 比較・評価クラスター(comparison/matrix/scoring)、課題分析クラスター(asIsToBeGap/riskMitigation)、`actionPlan`、`stakeholderMap` を優先
- `training` → 分析フレームクラスター(framework/logicTree/kpiTree/decisionTree)、単純提示クラスター(list/pyramid/description)、`roadmap`(学習ステップの提示)を優先
- `report` → `dataEvidence`、`waterfall`、`kpiTree`、`asIsToBeGap` を優先
- `general` → 偏りなく、内容に応じて選定
## structure.type 選定ルール(意味的クラスター内の判断基準)
同じ意図の文章でも複数のtypeが該当しうるため、以下の判断基準を優先的に適用すること。
**A. 比較・評価クラスター(comparison / matrix / scoring)**
- 選択肢が2つで賛否・pros/consを並べる → `comparison`
- 2軸でポジショニングを示す(市場分析・優先度マッピング等) → `matrix`
- 選択肢が3つ以上、または重み付けで定量評価する → `scoring`
**B. プロセス・計画クラスター(roadmap / valueChain / actionPlan)**
- フェーズ×時期(マイルストーン)の計画、または研修の学習ステップ提示 → `roadmap`
- 担当者ごとの個別タスク管理が主目的 → `actionPlan`
- 業務機能ごとの付加価値を語る(バリューチェーン分析) → `valueChain`
- 時期のない単純な手順は `list` で代替(direction: verticalの箇条書きとして記述)
**C. 課題分析クラスター(asIsToBeGap / riskMitigation)**
- 未来のリスクを確率・影響度で評価する → `riskMitigation`
- 現状とあるべき姿のギャップ・原因を整理する → `asIsToBeGap`
**D. 分析フレームクラスター(logicTree / decisionTree / kpiTree / framework)**
- SWOT/3C/4P等の業界標準フレームを明示的に使う → `framework`
- 数値目標の分解(売上・利益等のドライバー分解) → `kpiTree`
- Yes/No式の条件分岐による意思決定ロジック、または研修での判断演習 → `decisionTree`
- それ以外の一般的な要因・要素分解(MECE重視) → `logicTree`
**E. 単純提示クラスター(list / pyramid / description)**
- 結論が1つで、それを支える根拠を並べる → `pyramid`
- 優先度のない単純な箇条書き → `list`
- 背景説明・概念解説など、文章として読ませたい内容 → `description`
## hybrid運用ルール(あいまい排除)
- `structure.type` を `hybrid` にするのは、2つ以上の構造が**同格で並立し、どちらが主とも言えない**場合のみに限定する(例: 左に `list`、右に `matrix` を対等に配置するスライド)
- 単一の構造(例: `pyramid`)が主で、文章による補足を添えたいだけの場合は `hybrid` にせず、`structure.type` はそのままで `content.description` を併記してよい(スキーマ上、contentは複数キーを持てるため)
- すべてのスライドが `hybrid` に収束することを禁止する
## layout.ratio 選定ルール(typeとの整合を必須化)
- `layout.type` が `single` → `ratio` は `100` 固定
- `layout.type` が `twoColumn` → `ratio` は `50-50` / `60-40` / `40-60` を循環(この3種のみ)
- `layout.type` が `threeColumn` → `ratio` は `33-33-33` 固定
- `ratio` の値と `layout.type` が矛盾する組み合わせを生成しない
## デザイン指示ルール(配色・視覚スタイル)
- `meta.designDefaults` に資料全体で統一する配色・スタイルを1回だけ定義する(`colorPalette.primary` / `colorPalette.accent` / `visualStyle` / `iconography`)
- 個別スライドの `designInstructions.layoutInstruction`(Top/Middle/Bottomの縦方向の配置・強弱)はスライドごとに記述してよい(内容に応じて強弱が変わるため)
- 個別スライドで配色・スタイルを `meta.designDefaults` から意図的に変えたい場合(例: 警告・リスクスライドだけ強調色にする)のみ、`designInstructions.designOverride` にその内容と理由を記述する。理由のない上書きは禁止する
## 出典・注記の書き分け
- `content.description.citations`: 段落単位の個別出典(descriptionまたはhybrid内のdescriptionブロックでのみ使用)
- `sourceReference`: スライド全体の主たる参照元。`framework`/`logicTree`/`matrix`/`comparison`/`list`/`pyramid` など、出典フィールドを持たない構造タイプを使う場合は、このフィールドで出典を明記する(未記載を許容しない)
- `footnotes`: 法的注記・免責事項・前提条件の限定など、決定事項そのものではない補足事項
## aiPromptHint 記述ガイドライン
**構造タイプ別(共通)**
- `description` / `list` のスライド:
「説得力のあるパラグラフを生成し、箇条書きと組み合わせてメリハリをつける」
- 比較・評価クラスター(`comparison` / `matrix` / `scoring`)のスライド:
「なぜこのtypeを選んだか(選択肢数・軸の有無)が本文から読み取れるよう、判断根拠を明示する」
- プロセス・計画クラスター(`roadmap` / `valueChain` / `actionPlan`)のスライド:
「時期・担当者の有無に応じたtype選定である旨を踏まえ、該当情報が本文になければ補って記述しない(不明な場合は空欄または『未定』とする)」
**purpose別(トーンの上書き)**
- `proposal`: 「意思決定者が判断しやすいよう、結論を先に述べ、根拠は簡潔に絞る」
- `training`: 「専門用語には初出時に一言補足を入れ、具体例や比喩を交えて平易に説明する。受講者が実践できるレベルまで嚙み砕く」
- `report`: 「事実と数値を優先し、主観的な評価語(『素晴らしい』等)を避ける」
- `general`: 上記の上書きなし、構造タイプ別の指示のみ従う
## 使用するJSONスキーマ
{
"slideSchemaVersion": "3.0",
"meta": {
"presentationPurpose": "proposal | training | report | general",
"totalSlides": 0,
"designDefaults": {
"colorPalette": {
"primary": "<#HEX or Color Name>",
"accent": "<#HEX or Color Name>"
},
"visualStyle": "minimalist | corporate | bold | illustrative",
"iconography": "line | solid | none"
}
},
"slides": [
{
"slideNumber": 0,
"title": "<SLIDE_TITLE>",
"subtitle": "<サブタイトル（オプション）>",
"topSection": {
"role": "summary_or_question",
"leadText": "<1〜3文のサマリーまたは問い>",
"intent": "<このスライドの目的。presentationPurposeに応じた書き方に従う>",
"aiPromptHint": "<Copilotへのテキスト生成時の追加指示>"
},
"middleSection": {
"role": "body",
"fewWord": "<presentationPurposeに応じたラベル。例: Decision material / Learning content / Status summary>",
"layout": {
"type": "single | twoColumn | threeColumn",
"ratio": "100 | 50-50 | 60-40 | 40-60 | 33-33-33"
},
"structure": {
"type": "description | list | comparison | decisionTree | matrix | dataEvidence | illustration | hybrid | pyramid | logicTree | kpiTree | framework | valueChain | waterfall | asIsToBeGap | roadmap | scoring | stakeholderMap | riskMitigation | actionPlan",
"direction": "vertical | horizontal",
"highlightIndex": [0],
"note": "<構造に関する補足>"
},
"content": {
"description": {
"style": "prose | narrative | annotated",
"paragraphs": [
{
"paragraphId": "P1",
"role": "background | detail | supplement | conclusion",
"text": "<段落本文（2〜5文推奨）>",
"emphasis": false
}
],
"maxCharsPerParagraph": 200,
"readingTimeSec": 30,
"citations": ["<出典1>", "<出典2>"]
},
"list": {
"items": ["<item1>", "<item2>"]
},
"comparison": {
"left": { "title": "<選択肢A>", "points": ["<pro/con>"] },
"right": { "title": "<選択肢B>", "points": ["<pro/con>"] }
},
"decisionTree": {
"rootQuestion": "<判断軸>",
"branches": [{ "choice": "<Yes/No>", "result": "<結果>" }]
},
"matrix": {
"xAxis": "<軸名>",
"yAxis": "<軸名>",
"cells": [{ "position": "top-left", "label": "<内容>" }]
},
"dataEvidence": {
"metrics": [{ "name": "<指標名>", "value": "<数値>", "source": "<出典>" }]
},
"illustration": {
"visual": "<イラスト内容>",
"caption": "<説明文>",
"altText": "<アクセシビリティ用代替テキスト>"
},
"hybrid": {
"blocks": [
{ "structureType": "description", "ref": "description" },
{ "structureType": "list", "ref": "list" }
]
},
"pyramid": {
"mainMessage": "<結論・So What 1文>",
"supportingPoints": ["<根拠1>", "<根拠2>", "<根拠3>"],
"soWhat": "<だから何が言えるか・次に問うべきこと>"
},
"logicTree": {
"rootIssue": "<起点となるイシュー>",
"branches": [
{
"label": "<分解要素1>",
"children": ["<子要素1-1>", "<子要素1-2>"],
"isMECE": true
}
],
"meceNote": "<モレ・ダブリの検証メモ>"
},
"kpiTree": {
"topKpi": "<最上位KPI 例: 営業利益>",
"formula": "<計算式 例: 売上 - コスト>",
"drivers": [{ "name": "<客数>", "type": "driver | leaver", "value": "<数値または定義>" }]
},
"framework": {
"frameworkType": "swot | 3c | 4p | 5forces | pestle | vrio | bmc",
"blocks": [{ "label": "<Company / Strength など>", "points": ["<要点1>", "<要点2>"] }],
"insight": "<フレームワークから導かれる示唆>"
},
"valueChain": {
"steps": [{ "name": "<購買物流>", "activities": ["<活動1>"], "valueAdd": "<付加価値>" }],
"marginNote": "<競争優位の源泉メモ>"
},
"waterfall": {
"startLabel": "<期首>",
"startValue": "<100>",
"endLabel": "<期末>",
"endValue": "<120>",
"steps": [{ "name": "<価格改定>", "value": "<+15>", "type": "plus | minus" }],
"unit": "<百万円 | %>",
"source": "<出典>"
},
"asIsToBeGap": {
"asIs": ["<現状の姿1>"],
"toBe": ["<あるべき姿1>"],
"gaps": ["<ギャップ1: 原因を含む>"],
"actions": ["<ギャップを埋める施策1>"]
},
"roadmap": {
"timeHorizon": "<例: 2026 Q1 - Q4>",
"phases": [
{
"phaseName": "<Phase1: 基盤構築>",
"period": "<2026.04-06>",
"milestones": ["<M1: 要件確定>"],
"owner": "<担当>",
"dependencies": ["<依存タスク>"]
}
]
},
"scoring": {
"options": ["<A案>", "<B案>", "<C案>"],
"criteria": [{ "name": "<収益性>", "weight": "<30%>", "unit": "<5点満点>" }],
"scores": [[5, 3, 4]],
"recommendation": "<推奨案と理由>"
},
"stakeholderMap": {
"actors": [
{
"name": "<事業部長>",
"influence": "high | medium | low",
"interest": "high | medium | low",
"role": "R | A | C | I",
"attitude": "supportive | neutral | resistant",
"action": "<関与方針>"
}
]
},
"riskMitigation": {
"risks": [
{
"id": "R1",
"description": "<リスク内容>",
"probability": "high | medium | low",
"impact": "high | medium | low",
"mitigation": "<対策>",
"owner": "<責任者>",
"status": "open | mitigating | closed"
}
]
},
"actionPlan": {
"actions": [
{
"id": "A1",
"what": "<施策内容>",
"who": "<担当>",
"when": "<YYYY.MM.DD>",
"kpi": "<KPI>",
"status": "notStarted | inProgress | done",
"dependency": "<依存関係>"
}
]
}
}
},
"bottomSection": {
"role": "conclusion_or_next_action",
"expectedOutcomes": ["<結論・決定事項・到達点1>", "<結論・決定事項・到達点2>"],
"note": "<前提条件・補足(出典は書かない)>"
},
"designInstructions": {
"layoutInstruction": "<Top/Middle/Bottom の配置指示>",
"designOverride": {
"colorPalette": { "primary": "<#HEX>", "accent": "<#HEX>" },
"visualStyle": "minimalist | corporate | bold | illustrative",
"reason": "<meta.designDefaultsから変更する理由(変更しない場合は本フィールドごと省略)>"
}
},
"sourceReference": "<スライド全体の主たる参照元(出典フィールドを持たないstructure.typeを使う場合は必須)>",
"footnotes": ["<法的注記・免責事項・前提条件の限定など>"]
}
]
}
content配下はstructure.typeごとに専用オブジェクト（comparisonならleft/right、roadmapならphasesなど）を持ちます。全20タイプ分のフィールド定義は分量が多いため、実運用では元のスキーマ全文（JSONファイル）をそのままChatに読み込ませてください。
Chatに「テーマ：〇〇について、trainingとして5枚構成のスライドを作って」のように投げると、上記スキーマに沿ったJSONがまとめて返ってきます。STEP2：（必要な場合のみ）Copilot for Excelでデータを整備する
数値・グラフが必要なスライドがあれば、Copilot for Excelで先に集計・グラフ化を済ませておきます。グラフの考察文やキャプションは、できあがったグラフをChatに戻して生成させると精度が上がります。
⚠️ グラフはCopilot Chatではなく、Excel内のCopilotで作るのが安定します。
STEP3：JSONをCopilot for PowerPointに投入する
PowerPointを開き、Copilotパネルに以下の「投入プロンプト」＋STEP1で生成したJSON（1〜3スライド分）を貼り付けます。
## 投入プロンプト
役割と目的（Role）
あなたは、経営会議や決裁者に向けた「意思決定（Decision-making）を促すスライド」を
専門に作成するシニア・資料デザイナーです。
一般的な説明文の羅列ではなく、「論点の明確化」「情報の対比と構造化」「決定事項の明確化」を
最優先した、無駄のないビジネススライドを構築してください。
- Font and font size of each element
| Element | Font | Size | Use |
| --- | --- | --- | --- |
| Slide Title | Meiryo UI | 24 pt | Top-level title of each slide |
| Slide Message | Meiryo UI | 18 pt | The 1-sentence key takeaway (1 slide = 1 message) |
| Body Title | Meiryo UI | 18 pt | Section header inside the body |
| Heading Lv2 / Lv3 | Meiryo UI | 16 pt / 14 pt | Sub-headings under Body Title |
| Body Text | Meiryo UI | 16 pt | Main paragraph copy |
| Body Message | Meiryo UI | 16 pt | Supporting insight or conclusion in body |
| Chart / Figure Title | Meiryo UI | 16 pt | Title placed above graphs and tables |
| Footnote & Source | Meiryo UI | 9 pt | Notes, assumptions, data source |
| Big Number | Meiryo UI | 36–48 pt | KPI highlight, % lift, single big fact |
-スライド指示
- テンプレート名：<使用するテンプレート名を指定>
- 新規スライドで作成すること
- 以下のJSONスキーマに従い、意思決定用スライドのデータ構造に変換して出力してください。
<ここにSTEP1のJSONを1〜3スライド分貼り付け>
フォントを英語表記で指定しているのは、Copilotが英語の方が指示を正確に解釈しやすいためです（日本語版は資料の巻末に参考として添付するとよいでしょう）。
STEP4：確認しながら1〜3枚ずつ進める
生成結果を確認し、崩れていれば同じチャット内で追加指示して微修正します。全スライド分を一度に流し込むのではなく、1〜3枚ずつが基本です。
実践Tips
- 一括投入しない：長大なJSONは処理ミスの原因になります。少量ずつ投入した方が精度も修正コストも安定します。
- PPT Copilotに文章を考えさせない：内容の8割はChatで完成させておき、PowerPoint側は「生成・マッピング」専任にします。
- スライドマスタ／参考スライドを用意する：Copilot for PowerPointは前後のスライドと調和させて生成するため、テンプレートや数枚の参考スライドを先に用意し、そこに追記させる形にすると安定します。
- グラフはExcel側で先に作る：グラフなしでPowerPoint側に丸投げすると、意図が伝わりにくくなります。
よくあるNGパターン
NG何が起きるか全スライドを一括投入精度が下がりやすく、修正が困難になるPPT Copilotに文章も作らせるトーンや構成がブレるExcelグラフ無しで進める数値スライドの表現が安定しないJSON無しで自然言語だけで指示する意図が伝わりにくく、レイアウトが崩れやすい
まとめ
ITエンジニアを想定した記述なので、少し分かりづらい部分がありますが、ご不明な点がありましたらコメント等頂ければ追記・修正するかも知れません。
構成設計のロジック（用途別のtype選定基準やhybridの使い方など）をもっと詳しく知りたい方向けに、応用編として別記事にまとめる予定です。