AIスライド生成を作ってみたい　4日目

4日目：Codexを「1つの会話」に縛りすぎて崩壊しかけた話（そして立て直す）

4日目。

Codexを「1つのタスクの会話」に縛りすぎたせいで、コーディングがだんだんめちゃくちゃになってきました。

ChatGPTと同じで、会話が長くなるほど精度が落ちたり、話が噛み合わなくなったりするのは分かっていたのに……夢中になりすぎました。

ちょうど4日目は「HTMLコードで中間生成をする」工程に入っていたのですが、途中から挙動が明らかにおかしくなりました。

• 出力結果がまったく変わらない
• 修正したはずの内容が反映されない
• いつの間にかフォルダ構成が崩れていく

このまま突っ走ると、プロジェクトが壊れる未来しか見えなかったので、ここで一度立ち止まることにしました。

何が起きたのか（体感としての“崩れ方”）

今回の学びはシンプルで、

「会話を長くしすぎると、AIも人間も破綻する」

という当たり前の事実でした。

最初は気持ちよく進みます。
指示も通るし、修正も反映されるし、勢いでどんどん書ける。

でも、ある地点を超えると急に「微妙なズレ」が積み上がっていきます。

• AIが前提としているファイル構成と、実際の構成がズレる
• **“最新の仕様”**を言ったつもりでも、過去の会話ログに引っ張られる
• 修正指示が「差分」ではなく「別解」として出力され始める

この状態でHTML中間生成に入ったので、余計に破綻が目立ちました。

症状：壊れる前兆が全部出た

途中から、典型的な“やばい症状”が揃ってきました。

出力結果が変わらない

直したはずなのに、何度実行しても同じ結果。
これ、普通に考えると「キャッシュ」「参照先の取り違え」「処理が別の経路を通ってる」あたりですが、会話が長いと原因特定がさらに難しくなります。

修正が反映されない

「修正したはずのファイル」が実は見ていないファイルだったり、別の場所に同名ファイルが増殖していたり、そもそもAIが違う前提で作業していたり。

フォルダ構成が崩れる

これが一番まずい。
「直すために作ったもの」が増える → それがさらに混乱を生む、という雪だるま式。

このまま行くと、**“動いてるっぽいけど、何を根拠に動いてるのか分からない”**状態になります。
一番直しづらいやつです。

ここで撤退を決めた理由

正直、勢いで続けることもできたと思います。
でもその場合、終盤で絶対こうなるのが見えてました。

• バグが出る
• 直す
• 直らない
• さらに手当たり次第に触る
• ますます壊れる
• 「どこから直せばいいか分からない」

つまり、未来に負債を先送りするだけ。

だから4日目の時点で、ここはいったん止めました。

次にやること：基礎から作り直す

次の方針は決めました。

1. 仕様書（設計）に戻る

「今なにを作っているのか」を、会話ログじゃなくてドキュメントで固定します。

• 目的（何を自動化するのか）
• 入出力（何を渡して何が出るのか）
• ファイル構成（どこに何があるのか）
• 中間生成（HTML）の役割（何のために挟むのか）

ここが固まってないまま実装しても、結局ブレます。

2. ワークフローを整理する

工程の順序と役割を「手順」として明文化します。
特に今回は HTML中間生成が入るので、境界が大事。

• どこまでがアウトライン生成？
• どこからがHTML？
• HTMLからPPTXに行くとき、何を保証する？

“ここから先は別フェーズ”を切れるようにします。

3. Codex / Antigravity向けプロンプトを作り直す

会話の勢いでやるのをやめて、プロンプト自体を再利用可能な形にします。

• 1タスク = 1プロンプト（できれば短い）
• 前提情報は「冒頭にまとめて固定」
• 変更は差分指示で、対象ファイルを明示する

会話に全部を背負わせない設計に戻します。

4日目の結論

4日目は「進捗の日」じゃなくて「崩壊を防いだ日」になりました。

でもこれは、個人的にはかなり大きい収穫です。

• 会話が長いほど破綻する
• 中間生成のように工程が増えるほど、設計がないと壊れる
• 壊れる前に止まれるかどうかが、プロジェクトの寿命を決める

次は、仕様書とワークフローを作り直して、改めてCodex/Antigravityに投げ直します。
ここからが「ちゃんと作るフェーズ」です。

ここから先は人間パートです

なんかもうすごい生成AIをつかう上での初歩的なミスというか、ChatGPTをまあまあ使ってきていてやらないことをCodexではやってしまいました。
ずっと同じ会話をし続けて、なおかつ違うことを指示しているという・・・
AIスライド生成に関するコーディングではあるのですが、今までの指示している内容の流れとして
1．AIスライド生成のフォルダとして、Antigravityに以下の手順書をなげる

実装手順書としてのプロンプト

AIスライド作成AIエージェント：最短MVP → 高品質版（拡張） 実装手順書（Markdown運用）

前提の仮定（明示）

• LLMは ローカル（Ollama等） で動かす想定

• 成果物は Markdown中心に管理し、最終的に PPTX（またはMarp/Slidev）へ変換

• 「中間表現（SlideSpec JSON）」を必須にして、再生成・部分修正・評価ができる設計にする

---

1. 全体設計（エージェントの役割分担 / 入出力 / 状態 / 評価）

1-1. 役割分担（MVPでも最低ここまで分ける）

• Orchestrator（司令塔）

  • ユーザー入力を受け取り、工程を順に実行し、成果物を保存

• Planner（構成設計）

  • 目的・聴衆・尺から、ストーリーとスライド構成を作る

• Writer（各スライド本文）

  • 1スライド=1メッセージの原稿を作る（結論形タイトル＋箇条書き＋Notes）

• Designer（デザイン指示）

  • レイアウトタイプ、強調、図解種別、配色トーンなどの“指示”を返す（画像生成ではなく設計）

• Reviewer（品質評価）

  • ルーブリックで採点し、修正指示を返す（事実誤認・冗長・抽象を潰す）

高品質版では「Fact-checker」「Diagrammer（Mermaid/PlantUML）」を追加

---

1-2. 入出力（最小のI/O定義）

入力（UserBrief）

• タイトル（仮でも可）

• 目的（何を決めさせたい？）

• 聴衆（誰が見る？前提知識は？）

• 尺（5分/10分/20分）

• 使える素材（テキスト/URL/社内メモ/数値）

• 禁止事項（言えないこと、出せない情報）

出力（Artifacts）

• outline.md（構成案）

• slides.md（Markdownスライド原稿）

• slidespec.json（中間表現：各スライドの仕様）

• review.md（採点と修正提案）

• changelog.md（改善履歴）

---

1-3. 状態管理（ローカルで破綻しない最低条件）

• Project（案件）/ Run（生成実行）/ Artifact（成果物）を分離

• 必ず保存するキー

  • project_id, run_id, user_brief, outline_v*, slidespec_v*, slides_md_v*, review_v*

• 重要：**「部分再生成」**ができるように、スライド単位でIDを固定

  • slide_id: S01, S02…（順番が変わっても追跡できる）

---

1-4. 中間表現（SlideSpec JSON：最重要）

自然言語→いきなりPPTX生成は保守不能。必ず SlideSpec を挟む。

{
  "deck": {
    "title": "デッキ全体タイトル",
    "audience": "想定聴衆",
    "duration_min": 10,
    "tone": "formal",
    "style": {
      "layout_density": "medium",
      "font_scale": "normal",
      "accent": "blue",
      "chart_style": "simple"
    }
  },
  "slides": [
    {
      "slide_id": "S01",
      "title": "結論：〇〇を今月中に決めるべき",
      "bullets": [
        "理由は3つ：①… ②… ③…",
        "今日決めたいのは『〇〇の方針』"
      ],
      "layout_type": "TITLE_BULLETS",
      "visuals": [
        {
          "type": "mermaid",
          "purpose": "全体像",
          "spec": "flowchart LR\nA[課題]-->B[施策]-->C[成果]"
        }
      ],
      "speaker_notes": "最初に意思決定事項を宣言。背景は後ろへ回す。",
      "sources": [
        {"type": "user", "ref": "ユーザー貼り付けメモ#1"}
      ]
    }
  ]
}

---

2. スライド生成ワークフロー（ヒアリング→構成→本文→図解→デザイン→レビュー→修正）

2-1. MVP（最短で動く）

1. ヒアリング（UserBrief生成）

• 足りない情報は「仮定」で埋める（仮定は明記）

2. アウトライン生成

• スライド枚数目安：

  • 5分：5〜7枚 / 10分：8〜12枚 / 20分：12〜18枚

3. SlideSpec生成

• 1枚ごとに slide_id / title / bullets / notes / layout_type まで確定

4. Markdownスライド原稿生成（slides.md）

• “1スライド=1メッセージ”で固定フォーマット

5. レビュー（採点＋修正指示）

• 低得点のスライドだけ再生成（全再生成禁止）

---

2-2. 高品質版（拡張）

MVPに追加する工程：

• 根拠トレース：各スライドに sources[] を必須化

• 図解生成：Mermaid/PlantUML/Graphviz のいずれかを“1種類だけ”最初に採用して固定

• デザイン整合：StyleGuide（後述）を作り、全スライドへ適用

• レイアウト修正：文字量・はみ出し・箇条書き長の自動検知→短文化 or 分割

• A/B案：重要スライド（結論・提案・比較・費用対効果）だけ2案出す

---

3. プロンプト群（再利用テンプレ：System / Developer / User）

目的：毎回ゼロから悩まない。「構造固定」「失敗を潰す」「再生成が簡単」を最優先。

3-1. System（固定・最上位）

あなたは「AIスライド作成AIエージェント（プロンプトエンジニア兼スライドディレクター）」。
出力はMarkdown中心。必ず 1スライド=1ブロック、タイトルは結論形。
不明点は仮定して進め、仮定は明示する。
事実はユーザー入力を優先し、根拠不明な断定を避ける。

3-2. Developer（ガードレール＋工程制御）

## ミッション
ユーザーの入力から、(1)UserBrief (2)Outline (3)SlideSpec JSON (4)slides.md (5)review.md を生成する。

## 絶対ルール
- 1スライド=1ブロック。ブロックは「# Slide XX: タイトル / ## 要点 / - bullets / Notes:」で固定。
- タイトルは結論形（例：「結論：〜すべき」）。
- 箇条書きは最大5行、1行は全角40文字以内を目標。超える場合は短文化かスライド分割。
- “抽象語”だけで終わらせない。各スライドに「具体（数字/手順/例）」を最低1つ入れる。
- 図解が必要な場合は Mermaid などのテキスト図を「visuals.spec」に入れる。
- 出典がある場合は slide.sources[] に必ず入れる（ユーザー入力でもOK）。

## 生成手順（順番固定）
1) UserBrief（不足は仮定で補完）
2) Outline（スライド一覧：狙い・タイプ）
3) SlideSpec JSON（スキーマ準拠）
4) slides.md（人間が読む原稿）
5) review.md（ルーブリック採点＋修正指示）

## 出力フォーマット
- 最初に UserBrief（Markdown）
- 次に Outline（Markdown）
- 次に SlideSpec（JSONコードブロック）
- 次に slides.md（Markdown）
- 最後に review.md（Markdown）

3-3. User（運用時に貼る入力テンプレ）

## 依頼
- 作りたいスライド種別：{提案/社内説明/勉強会/営業}
- タイトル（仮でOK）：
- 目的（この資料で決めたいこと）：
- 想定聴衆（役職/知識レベル/関心）：
- 発表時間：{5/10/20}分
- トーン：{フォーマル/カジュアル/技術寄り}
- 使える素材（貼り付け可）：
- 制約（出せない情報/NG表現）：
- 希望（図解の有無、枚数上限など）：

## 素材（テキスト）
（ここに本文を貼る）

---

4. 失敗しやすい点と対策（設計で潰す）

4-1. 情報不足でフワフワする

• 対策：UserBriefで必須項目を固定し、不足は仮定→明記

• レビューで「仮定の妥当性」をチェック対象に入れる

4-2. 冗長（文字が多い/読めない）

• 対策：箇条書き制限（最大5行、1行40字目標）

• 超過時の自動ルール：

  • 「短文化」→ダメなら「2枚に分割」→ダメなら「詳細はNotesへ退避」

4-3. 抽象的（結局何をすればいい？が不明）

• 対策：各スライドに最低1つ「数字/手順/例」

• 「結論→根拠→次アクション」の型を強制

4-4. デザインが崩れる（統一感がない）

• 対策：StyleGuideを先に固定（後述）

• 最初に“基準スライド（S01〜S03）”だけ作ってスタイル確定→残り生成

4-5. 事実誤認（それっぽい嘘）

• 対策：出典フィールド sources[] を必須化

• 不明は「推定/一般論/仮置き」と明示し、断定しない

---

5. 成果物テンプレ（コピペ運用OK）

5-1. slides.md テンプレ

# Slide 01: 結論：◯◯を今月中に決めるべき
## 要点
- 今日の意思決定は「◯◯の方針」
- 理由は3つ：①… ②… ③…
- 次アクション：担当と期限を確定

Notes: 最初に“決めたいこと”を宣言。背景説明は後ろへ回す。

# Slide 02: 背景：現状の課題は◯◯に集約される
## 要点
- 課題A：◯◯（具体例：…）
- 課題B：◯◯（数字：…）
- 放置すると：◯◯が起きる

Notes: 課題は2〜3個に絞る。抽象語だけで終わらせない。

5-2. スピーカーノートの運用ルール

• Notesは「読む原稿」ではなく「話す意図」と「補足」を書く

• 目安：1スライド 15〜30秒分（長ければ削る）

5-3. チェックリスト（提出前）

## スライド品質チェック
- [ ] タイトルが結論形になっている
- [ ] 箇条書きが最大5行（超えるなら分割/Notes退避）
- [ ] 各スライドに具体が1つ以上（数字/手順/例）
- [ ] デッキ全体の意思決定・ゴールが冒頭で明示されている
- [ ] 用語が聴衆レベルに合っている（専門語の説明あり）
- [ ] 重要主張に根拠（sources）が付いている
- [ ] “次アクション”が最後にある（担当/期限/成果物）

---

6. スライド品質評価ルーブリック（採点表）

5段階（1=悪い / 5=非常に良い）。合計100点。

観点	配点	1の状態	3の状態	5の状態
目的適合	15	目的が不明/ズレる	目的は見えるが弱い	目的→結論→判断が一直線
構成（流れ）	15	話が飛ぶ	概ね追える	起承転結が明快、迷わない
明瞭さ（可読性）	15	文字過多/長文	多少読める	1枚で瞬時に理解できる
具体性	15	抽象語だらけ	一部具体あり	数字/手順/例が適切に配置
一貫性（トーン/用語/型）	10	バラバラ	だいたい統一	すべて同じルールで統制
デザイン指示の妥当性	10	指示が曖昧	最低限の指示	レイアウト/強調/図が明確
根拠・信頼性	10	断定が多い	注意書きあり	出典/仮定が明示され安全
行動可能性（次アクション）	10	結局何する不明	一応ある	担当/期限/成果物が明確

---

7. 図解の指示（Mermaid例：そのまま差し込める）

7-1. 全体フロー（エージェント処理）

7-2. 提案資料の定番構成（型）

---

8. 運用ルール（1人運用で回るようにする）

8-1. “再生成”の原則

• 全再生成は禁止（現場で嫌われる）

• 低得点スライドのみ差し替え

• 変更要求は 指示の種類 を固定して受ける

  • 例：「短く」「具体を入れる」「図をMermaidに」「比較表に」

8-2. バージョン管理（最低限）

• v1：初回生成

• v2：レビュー反映（部分修正）

• v3：最終（提出用）

• changelog.mdに「何をどう直したか」だけ残す

8-3. StyleGuide（最初に固定する“デザイン憲法”）

## StyleGuide（固定）
- 1スライド1メッセージ
- タイトル：結論形、最大1行
- 箇条書き：最大5行、1行短く
- 強調：太字は各スライド最大2箇所
- 数字：可能な限り入れる（Before/After、期限、規模）
- 図：Mermaidのみ（MVP）。必要スライドに限定

---

9. 代替案（用途別の作り分け：汎用性を保つ）

9-1. 用途別「最初の3枚」の定石

• 提案資料：結論→課題→提案の全体像

• 社内説明：目的→変更点→影響範囲（誰が何を変える）

• 勉強会：学ぶゴール→前提→全体マップ

• 営業：相手課題→解決策→導入イメージ（事例/数字）

9-2. 出力ターゲット別

• PPTX前提：SlideSpecを厚く（layout_type/visualsを増やす）

• Marp/Slidev前提：Markdownを厚く（区切り/図/コードを増やす）

---

ミニ要約（全体の要点）

• 中間表現（SlideSpec JSON）を必須にして、再生成・部分修正・評価ができる設計にする。

• 最短MVPは「UserBrief → Outline → SlideSpec → slides.md → review」で回し、低得点スライドだけ差し替える。

• 失敗の原因（情報不足・冗長・抽象・統一感・事実誤認）は、ルール固定（制限）＋ルーブリック評価で先に潰す。

• まずは図解は Mermaid 1種類だけに絞って運用し、品質が安定してから拡張する。

---

必要なら、次のステップとして「SlideSpecのJSON Schema（厳格版）」と「部分再生成コマンド（指示テンプレ）」まで一気に固定する案も出します。

2．Antigravityで生成してもらったコーディングをCodexにいじってもらう
3．初めの会話としてコーディングのレビューをしました
4.そこから、レイアウトパターンを増やす→品質強化→中間成果物としてHTMLコードで生成する
5．なんか変だぞ・・・？？？←今ここ

明らかに4番の指示をそれぞれ別の会話に分けるべきでした。
あとはCodexにはそれぞれの実装がおわったあとにレビューをしてもらって、そのレビュー結果をChatGPT5.2thinkingになげて、仕様書として整形しなおしてもらうということをしたほうがいいのかなと感じています。
あとはせっかくリポジトリとしているのに、エンドポイントというか戻るためのセーブみたいなことをしていないことにも気が付きました。
そしてAIをひたすらさわっている方々ならすでにご存知のMCPを上手に使う必要あることを知りました。
あとは多分なんですけど、現状AIスライド生成はClude関連で作成するのがベストというかMCPのかかわりという点でも作りやすいことがわかってもきました。
しかし、あえて私はCodexでつくれないかなーってやってます。
まあ、それぞれの違いを明確に差別化できてないだけですけど・・・
なんとなくCodexってプロのエンジニアの方々がつかうと効果を発揮しやすいけど
初心者というか知識がないひとがなんとなくプロンプトなげて、こんなかんじでつくれないかなーってやる分にはAntigravityとかClaude codeよりは効果を発揮しづらいのかなって思ってます。

なので反省点として
コーディングのプロンプトとしての指示はAntigravityかClaude codeにする
その指示をつくるための評価とかレビューをCodexにしてもらって
レビュー結果をChatGPT5.2thinkingになげて、より質のたかいプロンプトにして
Antigravityなどに理解してもらいやすくする

ということを考えて明日からまたいろいろ試行錯誤していきます