# 対話しながらビジネススライドを作る手順

AI がユーザーと合意を取りながら、そのまま商談・会議に出せる品質のスライド（.pptx または HTML デッキ）を作るための手順書。デザインの数値と禁止事項は [README.md](README.md)（共通ルール）と `systems/` の 1 ファイルが正本で、この手順書は **進め方** だけを決める。

目標は「デザイナーに外注した」と思われる品質。検証せずに納品しない。

## 0. 環境ごとの使い方

| 環境 | 渡し方 | 作るもの | 検証 |
|------|--------|----------|------|
| **Claude Code / Codex**（リポジトリを開ける） | このリポジトリで「slides/workflow.md に従って〇〇のスライドを作って」と頼む（入口は `AGENTS.md`・`CLAUDE.md`） | .pptx を `tools/pptx_kit.py` で組む | `check_pptx.py` → `render_pptx.sh` で全ページ目視 |
| **claude.ai / ChatGPT**（コード実行あり） | `README.md`・使うシステムの `.md`・この手順書・`implementation.md` を添付し、`tools/pptx_kit.py`・`tools/check_pptx.py` もアップロードする | .pptx を部品集で組む（[implementation.md §1](implementation.md) の「リポジトリの外で使うとき」） | `check_pptx.py`。画像化できない環境では README §2.5 の自己点検 |
| **コード実行なしのチャット** | 同じ `.md` を添付するか、公開 URL（リポジトリの README 参照）を読ませる | HTML デッキ（[implementation.md §3](implementation.md)）。Claude の Slides アーティファクトでもよい | README §2.5 の自己点検 |

以下の手順は環境によらず同じ。「質問ツール」「サブエージェント」など環境に無い道具は、同じ目的を普通の返信で果たせばよい。

---

## 1. 原則

1. **合意してから作る。** 目的・構成・デザイン方針の 3 点が決まる前に制作に入らない。作り直しのコストはヒアリングの数倍かかる。
2. **聞くのは足りない情報だけ、1 回にまとめて。** 会話や添付資料から読み取れることは聞かずに「こう理解しました」と要約して確認に回す。質問は各問に選択肢とおすすめ（理由つき）を添え、1 回に最大 4 問。選択式の質問ツールがある環境（Claude Code の AskUserQuestion など）ではそれを使う。
3. **小さな判断は宣言して進む。** 制作中に出た細かい判断（色の濃淡、改行位置など）で止まらず、「〜と判断した」と記録して納品時に報告する。止めて聞くのは成果物が実質的に変わる分岐だけ。
4. **全ページを画像で見てから納品する。** コードが正しいことと紙面が美しいことは別物。

---

## 2. 進め方

### Phase 0: ヒアリング

次のうち、分からないものだけを聞く。

- 資料のゴール（承認を得たい／受注したい／共有したい。何が起きれば成功か）
- 聞き手（役職・前提知識・関心事・懸念しそうなこと）
- 使用シーン（投影して口頭説明／送付して読んでもらう／印刷）→ 情報密度と文字量が変わる
- 素材（既存資料・データ・メモ）、枚数と持ち時間
- ブランドカラー・ロゴの有無
- 一番伝えたいメッセージを一文で言うと何か、根拠になる数字、想定される反論、比較できる材料（before／after・競合）

### Phase 1: 構成とデザイン方針の提案（1 回で出す）

往復を減らすため、構成案とデザイン方針を同じ返信で提示し、まとめてフィードバックをもらう。

**構成案:** 各スライドの「結論見出し＋使う図解＋テンプレート名」を 1 行ずつ。1 スライド＝1 メッセージ。話の流れ（結論先出し／課題 → 解決など）は聞き手と目的から選び、理由を添える（README §2.7）。提示する前に**見出しだけを通し読みし**、それだけで結論と根拠がつながるか確かめる。見出しは字数バジェット（各システム §6）に収まる長さで書く。内容の薄い箇所・数字の無い箇所があればここで追加質問する。

構成案の書式（この形で出すと、ユーザーが番号で直しを指示しやすい）:

```text
 1. 表紙            ｜ 物流センター自動化の提案
 2. キーメッセージ  ｜ 仕分けを自動化し、3 年で投資を回収する        ｜ 2 本線の対比
 3. 節区切り        ｜ 01 現状の課題
 4. 3 分割          ｜ 出荷遅延の 8 割は 3 つの工程に集中している    ｜ 工程別の番号＋要点
 5. ビッグメトリック｜ 年間の人件費を 3,200 万円削減できる           ｜ 決め数字＋内訳の横棒
 …
10. 締め            ｜ 本日、B 案での発注判断をお願いします
```

**デザイン方針:** [README.md §1](README.md) の 12 システムから、内容と聞き手に合う 1 つをおすすめし、次点を 1 つ添える（ブランドカラーがあれば色の定数を置き換えた版を示す）。なぜそのシステムがこの聞き手に合うかを 1〜2 文で説明する。

### Phase 2: 制作

- 選んだシステムの座標・テンプレート・図解決定表どおりに組む。16:9（13.333" × 7.5"）。
- .pptx は `tools/pptx_kit.py` で組む。テンプレートの組み方は `tools/sample_deck.py` の対応する関数（表紙 `cover`・要旨 `summary`・キーメッセージ `key_message`・節区切り `section`・3 分割 `three_columns`・ビッグメトリック `big_metric`・データ `chart`・折れ線＋考察 `line_trend`・比較表 `table`・2×2 `matrix`・期間表 `roadmap`・締め `closing`。目次は `agenda`）を真似る。部品集を使えないときも [implementation.md §2](implementation.md) の落とし穴を全部避ける。
- テキストを置く前に文字数バジェット（README §2.4）で検算する。部品集は溢れと泣き別れを警告として出すので、警告が 0 になるまで文言を直す。
- 数値データは PowerPoint ネイティブのチャートで入れる（あとで数字を直せるように）。
- 話す内容・補足は発表者ノートに入れる。
- 仮置きした箇所・判断した箇所をメモしておき、納品時に報告する。

### Phase 3: 検証（省略しない）

1. `python3 slides/tools/check_pptx.py deck.pptx --system <システム名>` で機械チェック。ERROR は 0 件まで直し、WARN は 1 件ずつ目視で判断する。
2. テキストを抽出して読み直す（誤字、抜け、プレースホルダーの残り、順序ミス、見出しの通し読み）。`python -m markitdown deck.pptx` が使えればそれで、無ければ python-pptx で抽出する。
3. `slides/tools/render_pptx.sh deck.pptx out/` で全スライドを画像にして 1 枚ずつ目視する（README §2.5）。サブエージェントを使える環境では画像を渡して別の目で見させる。見る観点:
   - テキストのはみ出し・見切れ（最優先）
   - 文字と図形・線・画像の重なり
   - 余白のアンバランス（片側だけ空いている・詰まりすぎと空きすぎの混在）
   - 列・カードの整列ズレ、低コントラスト、不自然な折り返し
   - スライド間で余白・サイズ・配色ルールが揃っているか
   - 共通の禁止事項（README §2.3）が出ていないか
   - 折り返しの最終行が 1〜3 字だけになっていないか（泣き別れ）
4. 直したスライドだけ再レンダリングして再確認する。
5. 「全◯枚を画像で確認し、◯件直した」と報告できる状態にする。

### Phase 4: 納品

- .pptx（または HTML）を渡し、各スライドの意図を 1 行ずつ説明する。
- Phase 2 で判断・仮置きした箇所を列挙する。
- 「直したいスライドの番号と内容を言ってもらえれば個別に直す」と添える。

---

## 3. 完成条件

1. 合意した構成・デザイン方針どおりか
2. 機械チェックの ERROR が 0 件で WARN を全件判断済み、かつ全スライドを画像で目視済みか
3. プレースホルダーや仮テキストが残っていないか
4. 共通の禁止事項に 1 つも該当せず、人間のデザイナーが作ったと言われて通用するか
5. そのまま会議・商談に持ち込めると胸を張って言えるか