コンテンツにスキップ

Kudo Proposal Deck Generator v2.7

工藤拓真（ブランディング戦略家・dof執行役員・BRANDFARM代表）のクライアント提案資料・講演資料を生成・編集する統合親スキル。

v2.7（2026-04-28）：PPTX物理品質の絶対遵守6原則を§11に新設。kudo-client-template-factory v0.7 §N PPTX Engineering SSOTを物理品質レイヤー実装SSOTとして参照。Phase 4 QAに「修復ダイアログテスト」を追加、Phase 5 Post-Processに「LibreOffice正規化」を必須化。

このスキルが扱うもの

  • 新規デッキ作成（Mode A）
  • 既存PPTX/PDFの磨き込み（Mode B）
  • 5つの型（Narrative / Consulting / Editorial / Lecture / Hybrid）から最適な構成を選んで生成
  • Dialogue / Final の2モードを使い分け
  • 工藤独自の戦略フレームワーク（記憶の箱、3つの門、版木、重力場 等）を活用したストーリーライン
  • v2.0新設：3レーン生成（A. python-pptx／B. Claude Design／C. Claude Code SVG）の選択・統合
  • v2.0新設★仮説：審美QAレーン（kudo-deck-aesthetic-qa）

子スキル・辞書型孫の構成（v2.0）

kudo-proposal-deck（親 v2.0）
├─【実装子】kudo-briefing
├─【実装子】kudo-schedule-budget
├─【実装子・新設】kudo-deck-generation-router v1.0
├─【実装子・新設★仮説】kudo-deck-aesthetic-qa v0.9
└─【辞書型孫】kudo-presenter-lens-library v1.0

子が親を呼ぶ原則

すべての子スキルは起動時に必ず本親スキルの5 Phase プロトコルを参照すること。

横断併走必須

  • kudo-writing：スライド内に文字列を1行でも生成する瞬間に必ず併走
  • kudo-strategist-lens-library（辞書型孫 of 戦略houshin）：Phase 1 ストーリーライン段階で参照
  • kudo-designer-lens-library：Phase 4 審美QAでペアレンズ選定時に参照

起動時の必須プロセス

スキル起動時は 必ず以下のフェーズ順 に進むこと。フェーズを飛ばすことは禁止。 特に型が確定する前にPPTX／HTML／SVG生成に進んではならない。

Phase 0  : Mode判定（A:ゼロから / B:既存資料を磨く）
Phase 0.3: 型判定（自動判定+確認）
Phase 0.5: テンプレ選択
Phase 0.7: 地形整備チェック（受け手の脳内反論を先回り設計）
Phase 1  : ストーリーライン3案提示
Phase 2  : ワイヤーフレーム
Phase 3  : 3レーン生成（v2.0改訂）→ kudo-deck-generation-router を経由
Phase 4  : QAレビュー（数値QA + 審美QA）→ kudo-deck-aesthetic-qa と連携
Phase 5  : Post-Process（v2.4新設）→ ページ番号自動化・フォント名検証・整合性チェック

Phase 0: Mode判定

ユーザーの依頼内容から、以下のいずれかを判定する。

Mode A：ゼロから新規作成 - 「提案資料を作って」「デッキを構成して」など、新規作成依頼 - 既存ファイルの添付なし

Mode B：既存資料を磨く - 既存PPTX/PDFが添付されている - 「これを磨いて」「改善して」「ブラッシュアップして」など改修依頼

判定後、ユーザーに「Mode A（新規作成）で進めます」「Mode B（既存資料の改修）で進めます」と明示すること。

Mode Bの追加プロセス

Mode Bの場合、Phase 0.3に進む前に必ず：

  1. 既存資料を読み込んで構造分析（python-pptx + markitdown）
  2. 現状の型・モードを自動判定して報告
  3. 例：「現状はEditorial + Dialogueモードで作られていますね」
  4. ユーザーに意図を確認
  5. 「同じ型で磨きますか？それとも別の型に作り直しますか？」
  6. 改修方針が決まってからPhase 0.3に進む

Phase 0.3: 型判定（自動判定+確認）

必ず references/template-types.md を読み込んでから判定すること。

5型（Narrative / Consulting / Editorial / Lecture / Hybrid）と2モード（Dialogue / Final）から、案件に最適な組み合わせを判定する。

判定の重み付け

  • 意図判定（70%）：誰に何をしてもらう資料か、受け手の状態、配布前提か
  • 構造指標（30%）：枚数、文字密度、フォント、写真使用率等

確信度3段階の運用

確信度 対応
高（80%+） 「○型 + ○モードで進めます。違う場合は教えてください」
中（50-80%） 「第一候補は○型、第二候補は○型。どちらで進めますか？」
低（50%未満） 「案件の意図を確認させてください：受け手は？反応は？配布前提？」

ユーザーの確認を得てからPhase 0.5に進むこと。

Phase 0.5: テンプレート選択

assets/templates/_index.md を確認し、確定した型に紐づくテンプレートPPTXを選択する。

テンプレートが未整備の場合は、Design Systemルールに従って Blank レイアウトから生成する。

Phase 0.7: 地形整備チェック

ストーリーラインを設計する前に、受け手の脳内に「この提案を受け入れやすい地形」を先に作る設計を行う。kudo-strategy-houshinの「方針提示の3作法」を、スライド構成レベルに翻訳したもの。

原則1：先回り否定スライド

位置： デッキ序盤、表紙直後〜課題提示の前

受け手が抱くであろう違和感・懐疑・諦めを、提案側が先にスライドとして書き出す。

S2: 「正直に言えば、こう思っていませんか」
    — ターゲット/クライアントの本音・違和感を箇条書き
S3: 「その感覚は、正しい」
    — 本音を肯定した上で、見落とされている構造を提示
S4: → だからこそ、本提案が必要
  • 受け手が「別に困っていない」と思っている案件 → 必須
  • 受け手が課題を自覚している案件 → 省略可（ユーザーに確認）

原則2：対比ブリッジスライド

位置： 課題提示〜戦略提示のブリッジ部分

「Aではなく、B」を1枚で視覚的に対比。論証を省略しても必然性が生まれる。

  • 左右2カラム型：左「このまま（BEFORE）」/ 右「こう変わる（AFTER）」
  • 上下転換型：上段「従来の発想」→ 下段「本提案の発想」（×印とチェック印）
  • 時間軸型：左→右へ「過去→現在→提案後の未来」を矢印で接続

原則3：N択クロージングスライド

位置： デッキ終盤、戦略提示後〜ネクストステップ前

抽象議論を「どれにしますか」と選べるN択に変換。

  • 方向性比較表（2〜3案の比較マトリクス、推奨案にアクセント色）
  • 段階選択（フェーズ1/2/3で「どこまでやるか」を選べる構造）
  • 投資レベル選択（松・竹・梅型の予算×施策セット）

地形整備チェックリスト（Phase 1進行前に確認）

  • 序盤に先回り否定が入っているか？（省略する場合はユーザーに報告）
  • 課題→戦略ブリッジに対比構造があるか？
  • 終盤にN択があるか？（Dialogueモード時は必須）
  • 3原則のうち最低1つは組み込まれているか？（0はNG）

Phase 1: ストーリーライン3案提示

必ず references/storyline-templates.md を読み込むこと。 v2.0より：辞書型孫 kudo-presenter-lens-library を併用し、用途別にプレゼンターレンズを2名選定してから3案を組むこと。

確定した型に最適な3つのストーリーラインを提示する。各案は以下のフォーマットで：

案A：「○○」型
[1-2行のメタファー説明]
[参照プレゼンターレンズ：例 佐藤可士和×Nancy Duarte]

具体構成：
1. [スライドのタイトル/役割]
2. [スライドのタイトル/役割]
...

→ [どんな案件・どんな受け手に最適かの1行]

重要：メタファー名（重力場型、版木型など）だけでは具体イメージが伝わらないため、必ず具体的なスライド構成を文章で併記すること。

ユーザーがどれかを選択するまでPhase 2に進まない。

Phase 2: ワイヤーフレーム

選択されたストーリーラインの各スライドについて、以下を定義する。

  • スライド番号
  • タイトル（アクションタイトルで）
  • レイアウトタイプ（タイトル/コンテンツ/2カラム/データ/引用/CTA）
  • 必要な図形リスト（タイトルTextBox、本文TextBox、画像プレースホルダー等）
  • 想定文字数
  • Dialogueモードの場合、緑字で入れる論点
  • v2.0追記：そのスライドが想定する生成レーン（A/B/C）の暫定割当（Phase 3 で再検討）

ユーザーに提示し、調整を求めること。OKが出たらPhase 2.5に進む。

Phase 2.5: 所要時間シミュレーション（v2.2新設・2026-04-25）

Phase 2でワイヤーフレーム合意が得られた直後、Phase 3生成に進む前に、必ず所要時間の機械的試算を行う。

なぜこのPhaseが必要か

工藤さんが2026-04-25のdof向け歌舞伎ブリーフィング案件で「ほんとに30分でプレゼンできるボリューム？」と指摘するまで、Claudeは台割の枚数だけで「1枚○分」と暗算して時間見積もりを済ませていた。v1→v2→v3と3回台割を作り直した経緯がある。この失敗を構造的に防ぐため、Phase 2.5を新設する。

原則：「枚数 × 1分」という雑な掛け算は禁止。各スライドの情報密度から1枚ずつ機械的に所要時間を試算する。

起動条件

以下のいずれかに該当する場合、Phase 2.5は必須：

  • 「○分のプレゼン／講演／説明会／ブリーフィング」など時間枠が明示された案件
  • 「登壇」「社内報告」「クライアント訪問」など口頭発表が前提の案件
  • ナレーションやセミナー動画の台割

配布用・アーカイブ用・読み物用のデッキでは、Phase 2.5はスキップ可能（ユーザーに確認）。

スライド種別ごとの所要時間テーブル

種別 典型例 所要時間（標準） 備考
カバー／締め 表紙、終了スライド 20〜40秒 挨拶込みで計算
シンプル1メッセージ 名言引用、大見出し1行、巨大な数字 60〜90秒 間を取るなら×1.5
中密度 見出し＋本文段落＋図1つ／3カラム／タイムライン 90〜120秒 デフォルト想定
高密度 見出し＋表＋本文＋図＋引用、マトリクス、5項目以上のリスト 150〜180秒 読み込み時間含む
ドラマ語り指定 「ここは厚く語る」★指定／ストーリー起承転結の核 ×1.5〜2倍 工藤さんの指定ペース配分に従う
Dialogue問いかけ 緑字の論点、聴衆への問い +15〜30秒 間と反応時間
質疑応答枠 Q&Aタイム 5〜10分 案件の性質で判断

試算プロトコル

  1. 各スライドを上記テーブルに照合し、標準時間を割り当てる
  2. 工藤さんの「★厚く語る」指定が入っているスライドは×1.5倍
  3. Dialogueモードの緑字があるスライドは+20秒
  4. 質疑応答枠を最後に加算（案件性質から判断、または工藤さんに確認）
  5. 合計時間を算出し、想定枠と比較

アウトプットフォーマット

工藤さんに以下を提示：

【所要時間シミュレーション】
想定枠：30分（質疑込み）
試算合計：○分（質疑△分含む）
オーバー率：×1.○

各スライド内訳：
S01: ○秒  (カバー)
S02: ○秒  (シンプル1メッセージ)
S03: ○秒  (中密度)
...

判定：[✅枠内 / ⚠️オーバー±N分 / 🚨大幅オーバー（×1.3以上）]

オーバー時の対応（3択提示）

試算合計が想定枠を×1.1以上超えた場合、必ず工藤さんに以下3択を提示する：

  • A案：枚数を削る（どのScene／Sceneの何枚を削るか具体案2-3個）
  • B案：時間枠を拡げる（30分→45分／60分への変更交渉）
  • C案：圧縮版＋補完資料のハイブリッド（30分版デッキ＋事前/事後配布の深堀り資料）

工藤さんの選択を得てから、Phase 2のワイヤーフレームに戻って再設計する。再設計後、再度Phase 2.5で時間試算を行い、枠内に収まることを確認してからPhase 3へ進む。

アンダー時の対応

試算合計が想定枠を×0.85以下で下回った場合、情報が薄い可能性を工藤さんに報告し、追加スライドの候補（エピソード、事例、引用など）を2-3個提示する。ただし工藤さんが「このままで良い」と判断したら進む。

工藤さんの発話スピード補正

工藤さんは自認として「喋るのが早い」タイプ。案件によっては「早口で詰められる」指示が入る。その場合：

  • 標準時間の0.75〜0.85倍で再計算する
  • ただし「厚く語る」指定スライドは補正しない（感情ピークの間は速度を落とすべき）
  • 最終判定は工藤さん本人の判断に委ねる

Phase 2.5 完了条件

  • 各スライドの所要時間を機械的に試算した
  • 合計時間を想定枠と比較した
  • オーバー時は3択提示して工藤さんの選択を得た
  • 選択に応じてPhase 2またはPhase 3へ進む方針が決まった

Phase 3: 3レーン生成（v2.0改訂）

v2.0からの最重要改訂点。 Phase 3 開始時に 必ず kudo-deck-generation-router を起動 すること。

Phase 3 入口：レーン選択

Phase 3 開始
  ↓
[kudo-deck-generation-router v1.0 起動]
  ↓
S1〜S4 採点（枚数 / 編集可能性 / 審美要求 / 即応性）
  ↓
レーン選択（A単独 / B単独 / C単独 / ハイブリッド4パターン）
  ↓
各スライドのレーン割当（スプレッドシートまたは表で可視化）
  ↓
各レーンで並列生成
  ↓
ハンドオフで1つのデッキに統合

レーンA：python-pptx（既存・継続）

必ず references/shape-rules.md と references/design-system.md を読み込むこと。 scripts/font_setter.py を使って日本語フォントを正しく設定すること。

  • 新規生成（Mode A）：python-pptxでBlankレイアウトから組み立てる
  • 既存編集（Mode B）：既存PPTXを開いてpython-pptx + OOXMLで差分編集する
  • Shape Rules（最大8図形・GroupShape禁止・アクセント線禁止）厳守
  • Text Brevity Rules（タイトル25文字・箇条書き35文字×5・1スライド150文字以下）厳守

レーンB：Claude Design（v2.0新設）

  • HP型Hero／モダンレイアウト／タイポ映え／高解像度プレビューに使用
  • kudo-deck-generation-router §2 のプロンプトテンプレートを使用
  • HTML出力をPPTXへ統合する場合は §4 ハンドオフ仕様に従う

レーンC：Claude Code SVG（v2.0新設）

  • 1ページに魂を込める用途（カバー／核概念図解／印刷対応）
  • kudo-deck-generation-router §3 のプロトコルに従う
  • ベクター出力（SVG／PDF）を維持

Design System（唯一のソース参照・SSOT原則）

本スキルではカラー・フォント仕様をハードコードしない。2026-04-24以降、デザイントークンは下記1箇所を唯一のソースとする：

一次ソース（Single Source of Truth）： - claude/claude-reference/design-tokens/kudo-brand-tokens.json（VM内：/sessions/<session>/mnt/claude-reference/design-tokens/kudo-brand-tokens.json） - CLAUDE.md §6（一次ソースの要約・運用ルール） - ユーザー個人設定「カスタマイズ > 指示・好み」項目8（一次ソースの要約・あらゆるセッションで自動ロード）

セッション開始時に必ず上記を読み込み、最新の v5-FINAL パレット（Layer 1/2/3 + 予備2色）と Pattern B-Hiragino フォント（DISPLAY/READING/UI 3モード・Hiragino Mincho ProN W6/W3＋Helvetica Neue）と納品運用(a) PDF-first を参照すること。本スキル本体にはカラーコード・書体名を書かない。

スキル固有の運用ルール（本スキルのみの追加規定）

一次ソースで定義されていない、kudo-proposal-deck 固有の運用：

  • Forest #2D5A3A（Layer 3 緑）は Dialogue モードの議論ポイント専用（本編強調には使わない）
  • Crimson #BC002D（Layer 2 紅）は本編の強調専用（シグネチャーとしての純粋想起形成を目的）
  • アクセント運用比率の目安：ニュートラル 75% / プライム 15% / セカンダリー 10%
  • 予備色（Wine Burgundy / Smoked Navy）の発動判断は案件キックオフ（Phase 0）で工藤さんが明示的に指示した場合のみ

Phase 4: QAレビュー（v2.0改訂・2レーン構造）

レーン1：数値QA（既存）

必ず scripts/qa_check.py を実行すること。

  • 不要図形の混入（5pt以下の小図形、装飾的な極小TextBox）
  • フォント設定の正しさ（東アジアフォントスロットも含む）
  • 文字数オーバー
  • カラーパレット外の色使用
  • グループ化の有無（あれば警告）

問題があれば scripts/cleanup.py で自動修正を試み、それでも残るものはユーザーに報告する。

レーン2：審美QA（v2.0新設）

起動時、kudo-deck-aesthetic-qa v1.2 を呼び出す。

  • デザイナーペアレンズ2名選定（kudo-designer-lens-library から）
  • 8軸採点（タイトル比率／余白／階層／視線誘導／カラー配分／タイポ統一／アクセント多様性／ストーリー流れ）
  • 判定分かれ（Δ≥2）抽出
  • Claude初期診断 + 工藤最終判定（デュアルレーン）

レーン3：物理品質QA（v2.7新設・PPTX限定）

python-pptxレーンで生成したPPTX/.potxの場合、必ず以下を実行：

  • 修復ダイアログテスト：生成 .pptx / .potx を実機 PowerPoint Mac で開き、修復ダイアログが出ないことを確認
  • 出る場合：kudo-client-template-factory v0.7 §N PPTX Engineering SSOT 6原則のどれを破っているか診断
  • 修復押下後の保存 byte 差分が 5KB 以下なら実用上は許容（中身は完全保存）
  • PPTX エンジニアリングSSOT準拠チェック：kudo-client-template-factory v0.7 §N の6原則すべてを満たしているか、build script を grep して確認
  • LibreOffice正規化が build script の最終ステップにある
  • ref-template-17 の slide1.xml をベースに上書きする実装になっている
  • XML declaration が Office標準フォーマットで出力されている
  • shape構造が必要最小限（不要な extLst や spPr 追加なし）
  • text に raw \n を含めず、<a:p> 段落分けまたは最小 <a:br> を使っている
  • theme1.xml の effectStyleLst から shadow effect が完全除去されている
  • shadow完全除去確認：unzip -p output.potx ppt/theme/theme1.xml | grep -E '(outerShdw|innerShdw|reflection|glow)' が0件

詳細評価は kudo-deck-aesthetic-qa v1.2 のA18/A19/A20軸を呼び出す。

Phase 5: Post-Process（v2.4新設・2026-04-27）

Phase 4 QAが完了した後、納品前に必ず実行する後付け工程。 生成時にハードコードできない／するべきでない設定を、生成済みPPTXに対して動的に注入・検証する。

なぜこのPhaseが必要か

工藤さんが2026-04-26のdof向け歌舞伎ブリーフィング案件で2つの破綻に遭遇したことが起点：

  1. ページ番号の破綻：python-pptxで '01 / 25' 等の固定文字列を生成時にハードコードしていたため、工藤さんが冒頭3枚を追加した瞬間、全スライドのページ番号が破綻。手動で全削除が必要になった。
  2. フォント名の破綻：生成時に '凸版文久見出し明朝 StdN' 等のサフィックス付き名を使っていたため、Mac PowerPoint実機で游明朝にフォールバック表示。原因特定に時間がかかった。さらにv2.5（2026-04-28）でApple版凸版・Adobe版源ノ明朝でも「ファミリー名+別ウェイト」構造のフォントは theme XML 解決失敗することが判明し、Hiragino Mincho ProN W6/W3 へ全面切替。

共通構造：両者とも「生成時には正しそうに見えるが、実機で破綻するハードコード値」という同じ病気。「生成」と「仕上げ」を別工程に分けることで構造的に防ぐ。

Phase 5 の4つのモジュール（v2.7で4つ目を新設）

Phase 5: Post-Process
├─ Module 5-1: ページ番号自動化（add_page_numbers.py）
├─ Module 5-2: フォント名検証・正規化（verify_fonts.py）★仮説・未実装
├─ Module 5-3: デザイントークン整合性検証（verify_design_tokens.py）★仮説・未実装
└─ Module 5-4: LibreOffice 正規化（v2.7新設・必須）

Module 5-4: LibreOffice 正規化（v2.7新設・必須）

目的：python-pptx 系で生成した .pptx / .potx は PowerPoint Mac の修復ダイアログ問題を抱える（Issue #87 12年既知）。LibreOffice headless で1回読み込み・再保存することで、PowerPoint Mac互換のXML形式に正規化される。

実装： 

import subprocess
import shutil
from pathlib import Path

def normalize_via_libreoffice(pptx_path: Path) -> None:
    norm_dir = pptx_path.parent / ".lo_norm_tmp"
    norm_dir.mkdir(exist_ok=True)
    try:
        subprocess.run(
            ["libreoffice", "--headless", "--convert-to", "pptx",
             "--outdir", str(norm_dir), str(pptx_path)],
            capture_output=True, timeout=60, check=True)
        normalized = norm_dir / pptx_path.name
        if normalized.exists():
            shutil.copy(normalized, pptx_path)
    finally:
        shutil.rmtree(norm_dir, ignore_errors=True)

前提：LibreOffice インストール済み（brew install --cask libreoffice）

効果：PowerPoint Mac の修復ダイアログを撲滅。中身（テキスト・図形・色）は変わらず、XML構造だけが Office互換にクリーンアップされる。

起動条件：python-pptx で .pptx / .potx を生成したすべての案件で必須。Module 5-4 を経ずに納品することは禁止（v2.7 禁止事項#16）。

Module 5-1: ページ番号自動化（実装済・2026-04-27）

目的：固定文字列のページ番号を、PowerPointの自動更新フィールド（<a:fld type="slidenum">）に置換する。順序変更・追加・削除しても番号が自動更新される状態にする。

スクリプト：scripts/add_page_numbers.py（独立実行可能）

使い方： 

# 基本：全スライドに番号
python3 add_page_numbers.py input.pptx output.pptx

# 冒頭スキップ（表紙等）
python3 add_page_numbers.py input.pptx output.pptx --skip-slides 1,2,3

処理内容： 1. 既存の固定ページ番号テキストボックス（"NN / MM" パターン）を正規表現で検出・除去 2. 各スライドの </p:spTree> 直前に新しい <p:sp> を挿入 3. その中に <a:fld type="slidenum"> フィールドを埋め込み 4. 配置：右上、Mushroom #7E7B76、9pt、Noto Sans JP

形式：「01」「02」「03」のシンプル表記（総枚数なし）。総枚数表示は手動更新が必要なため除外。

冪等性：何度実行しても安全。既に自動フィールドが入っている場合はスキップ。

Module 5-2: フォント名検証・正規化（★仮説・未実装）

目的：生成済みPPTX内の全テキストのフォント名が、Mac実機表示名と一致しているか検証する。一致しないものを自動正規化する。

起動条件： - 新規PPTX生成後・納品前 - 既存PPTX修正時、フォント名混在の疑いがある場合 - Phase 3 のレーンA（python-pptx）使用時は必須

処理内容： 1. PPTX内の全 typeface="..." 属性を抽出 2. Mac実機表示名リスト（claude/claude-reference/design-tokens/kudo-brand-tokens.json 一次ソース）と照合 3. サフィックス付き／別名のフォントを検出 4. 自動正規化（'凸版文久見出し明朝 StdN' → '凸版文久見出し明朝' 等） 5. 正規化マッピング辞書は kudo-brand-tokens.json に集約

検証対象フォント名（v2.5項目4-5 準拠・Pattern B-Hiragino）： - Hiragino Mincho ProN W6（DISPLAY 和文） - Hiragino Mincho ProN W3（READING 和文） - Hiragino Sans W3（UI 和文） - Helvetica Neue（欧文＋bullet）

実装優先度：高（次回dof案件着手前に作成）

Module 5-3: デザイントークン整合性検証（★仮説・未実装）

目的：色・余白・フォントサイズがkudo-brand-tokens.jsonと一致しているか検証する。逸脱を検出して報告する。

処理内容： 1. PPTX内の全色値（srgbClr）を抽出し、tokens.json の v5-FINAL パレット11色＋予備2色と照合 2. 逸脱色を検出してリストアップ 3. 余白値（bodyPr の lIns/tIns/rIns/bIns）の標準値からの逸脱検出 4. フォントサイズの極端値（5pt未満／60pt超）警告

実装優先度：中（複数案件で需要が確認できてから）

Phase 5 の起動原則

案件種別 Phase 5 必須モジュール
新規生成（Mode A）レーンA（python-pptx） 5-1, 5-2
新規生成（Mode A）レーンB/C（HTML/SVG） 5-2のみ（5-1は不要）
既存改修（Mode B） 必要に応じて 5-1, 5-2
配布前最終QA 5-1, 5-2, 5-3 全モジュール

Phase 5 を飛ばしてよい場合

  • 工藤さん本人が「post-processはいらない」と明示的に指示
  • 1〜3枚の超小規模デッキ
  • 検証用の試作デッキ（破棄前提）

Phase 5 の出力命名規則

[元ファイル名]_postprocessed.pptx または [元ファイル名]_final.pptx

§生成・QA共通：絶対遵守・PPTX制作11項目（Phase 3/4 にまたがる横断ルール）

工藤さんが過去何度も指摘してきたPPTX制作ストレスポイントを11項目に整理。Phase 3（生成）の制約とPhase 4（QA）の検査基準の両方を兼ねる横断ルール。違反があるデッキはPhase 4 QAで自動検出され、修正されるまでユーザー提示しない。

注意：4-1〜4-4 の Theme Colors / Slide Master / Theme Font まわりは python-pptx のネイティブAPIだけでは完全実装できず、theme.xml への lxml 直接介入が必要（★仮説：実装可能性要検証）。また HTMLレーン（Claude Design）／SVGレーン（Claude Code）では「Theme Colors」概念自体が存在しないため、4-1/4-2/4-4 は実質的にレーンA（python-pptx）限定ルールとして扱う。

1. 資料構成

# ルール Claude側の実装・検査
1-a 背景はJet系（濃色）を表紙・目次・スケジュールのみ／他はPaper（白）／特殊演出は事前合意 tokens.json の background_rules（別途定義）を参照。Phase 4 A9軸で自動検査
1-b 右上にページ番号、左上にデッキ全体タイトル（1行・グレー）を配置。共通フォーマット Slide Master の Placeholder として定義。Phase 4 A14軸で座標を自動検査（★仮説・レーンA限定）
1-c ページ番号は Slide Number Placeholder 使用で並び替え自動連動。実装不可なレーンではページ番号自体を入れない v9.3テンプレ起点：自動合格（各slide.xmlに固定textbox+<a:fld type="slidenum">埋め込み済）。Phase 5 Module 5-1は不要。それ以外：python-pptx: slide.placeholders[<idx>] 制御。手打ち"01/16"禁止
1-d 左上説明は 9pt以上（推奨10-11pt）。極小文字での情報詰込禁止 Phase 4 A11軸で自動検査
1-e 左上説明は全ページ共通の1行（デッキタイトル等）／ページ固有説明はスライドタイトルに集約 v9.3テンプレ起点：左上共通説明用テキストボックスが各スライドに配置済み。直接編集して入力。Phase 4 A11軸で共通性検査

2. カラーリング

# ルール Claude側の実装・検査
2-a ハイライトは Crimson、他はモノトーン基調（Paper/Stone/Mushroom/Ink/Jet）／Prussian/Ochre/Forest/Saddle は戦略意図ある時のみ tokens.json §6 参照。Phase 4 A5／A7軸で検査
2-b 戦略意図ありorビジュアライズ必要時のみ色分け／「おしゃれに見えるから」の多用禁止 Phase 4 A7軸でアクセント色出現回数を可視化

3. 図形とテキストボックス

# ルール Claude側の実装・検査
3-a 影・グラデ・3Dベベル・光彩・反射・発光・装飾一切禁止 tokens.json design_system_rules 準拠。python-pptxで shape.shadow.inherit = False 明示。Phase 4 A15軸で検査
3-b 矩形図形＋別テキストボックスの重ね置き禁止／shape.text_frame に直接テキスト書込で一体化 python-pptx: add_shape() 直後に .text_frame.text = "..." で一体化。Phase 4 A12軸で「同座標の矩形+TB」を検出
3-c テキストボックスの長さは内容に沿わせる／auto_size = MSO_AUTO_SIZE.SHAPE_TO_FIT_TEXT 標準化 Phase 4 A15軸で auto_size未設定・内容はみ出し・過剰空白を検査

4. 編集しやすさ（★仮説・レーンA限定）

# ルール Claude側の実装・検査
4-1 Theme Colors に Paper/Ink/Crimson等を登録／RGB直指定禁止／Theme Color参照で記述 theme.xml への lxml介入が必要（python-pptx単独不可）。★仮説：実装方法要確立。Phase 4 A13軸で検査
4-2 Slide Master / Layout で共通要素（フッタ・左上タイトル・右上ページ番号・背景色）を定義／個別オーバーライド最小化 python-pptx slide_master / slide_layout 活用。新規スライド追加時も自動継承。★仮説・レーンA限定
4-3 GroupShape 禁止（選択・編集時の障壁） tokens.json design_system_rules.group_shape_prohibited: true と整合。Phase 4 A15軸で検査
4-4 Theme Font の majorFont / minorFont に Pattern B-Hiragino 3モード（Hiragino Mincho ProN W6/W3＋Helvetica Neue）を登録／フォント直指定禁止 theme.xml への lxml介入が必要。kudo-master-v8.2-hiragino.potx で実装パターン確立。Phase 4 A13軸で検査
4-5 【鉄則・2026-04-28更新v2.5】Mac PowerPoint theme XML 和文フォント解決鉄則：和文フォントは「ウェイトを含むファミリー名」で書く（W6/W3が family の一部であるフォント）。「ファミリー名+別ウェイト」の2段構造フォント（凸版文久・源ノ明朝等）はtheme XML で解決失敗する。さらに（a）Adobe版サフィックス禁止（StdN／Pr6N R／Display Pro／Text Pro 等）（b）実機未インストールフォントの規定禁止（Font Bookで実在確認必須）（c）slideMaster の bullet font も Arial デフォルトを Helvetica Neue に統一する4条件を併満たすこと Phase 3 生成前に必ず以下4フォント名を使用：Hiragino Mincho ProN W6（見出し和文）／Hiragino Mincho ProN W3（本文和文）／Hiragino Sans W3（UI 和文）／Helvetica Neue（欧文＋bullet）。Phase 4 A13軸で全フォント名を実機リスト照合。kudo-master-v8.2-hiragino.potx で実証済み（2026-04-28、v6/v7で凸版・源ノ明朝が解決失敗→v8で本文確定→v8.1でbullet統一→v8.2で背景属性化）
4-6 【鉄則・2026-04-28新設v2.5】背景色は <p:bg> 属性方式で指定する：色ボックス（フルサイズの<p:sp>矩形）を被せて背景色を作る方式は禁止 python-pptx／lxml で各 slide.xml の <p:cSld> 直下に <p:bg><p:bgPr><a:solidFill><a:schemeClr val="lt1"/> 等を配置。schemeClr 推奨（lt1=Paper／lt2=Oatmeal／dk1=Ink／accent1=Crimson）。色ボックス方式だと（i）「背景」として認識されない（ii）誤って削除/移動するリスク（iii）shape数が増える（iv）レイアウト変更時の編集障害になる。kudo-master-v8.2-hiragino.potx で実証済み

5. 生成時ハードコード禁止（v2.4新設・Phase 5連動）

# ルール Claude側の実装・検査
5-1 【鉄則】ページ番号文字列を生成コード内にハードコードしない：固定値の "01 / 25" 等は禁止。Phase 5 Module 5-1（add_page_numbers.py）で動的フィールド化する python-pptx生成スクリプトでは add_header_footer() 等にページ番号を含めない。生成完了後、必ず Phase 5 Module 5-1 を実行
5-2 【鉄則】フォント名は生成時にウェイト含むファミリー名で記述、Phase 5で実機リスト照合：項目4-5（v2.5）の運用補強 生成スクリプト内で Hiragino Mincho ProN W6／Hiragino Mincho ProN W3／Hiragino Sans W3／Helvetica Neue 以外のフォント名を使わない。slideMaster の <a:buFont> も Helvetica Neue で統一
5-3 【鉄則・v2.5】背景色は生成時から <p:bg> 属性方式で書く：色ボックス（フルサイズ矩形）で背景を作る生成は禁止 python-pptx／lxml で <p:cSld> 直下に <p:bg> を直接挿入する
5-4 【鉄則・v2.7新設】raw \n 禁止／ 段落分け原則：テキスト中に \n を含めると PowerPoint Mac の修復対象になる 改行表現は2択：(a) 段落として分けたい場合は \n で split し各行を独立した <a:p> として並べる（multiline_para_xml ヘルパー使用）／(b) 同一段落内で改行したい場合は <a:br><a:rPr lang="ja-JP"/></a:br> の最小形式のみ使用（rPr に他属性追加禁止）。最も安全なのは「段落分け一択」。本文・キャプション・スピーカーノート全てこの原則を貫く
5-5 【鉄則・v2.7新設】XML declaration Office標準フォーマット：lxml デフォルト出力（<?xml version='1.0' encoding='UTF-8'?>）では PowerPoint Mac の修復対象になる 必ず以下を強制：data = etree.tostring(tree, xml_declaration=False, encoding="UTF-8") → re.sub(r'>\s+<', '><', data_str) で minify → <?xml version="1.0" encoding="UTF-8" standalone="yes"?>\r\n を先頭に付与。ポイント4点：(a) ダブルクォート必須 (b) standalone="yes" 付与 (c) 末尾CRLF (d) タグ間空白・改行を minify

6. PPTX物理品質・修復ダイアログ撲滅（v2.7新設）

# ルール Claude側の実装・検査
4-7 【鉄則・v2.7新設】ref-base 上書き原則：python-pptx の add_slide(blank_layout) で生成される slide.xml は PowerPoint Mac の検証を完全には通らない（Issue #87 既知問題） スライド7枚目以降は ref-template-17.pptx の slide1.xml をベースに上書き し、shape を全て自前で構築する。詳細は kudo-client-template-factory v0.7 §N 原則2を参照
4-8 【鉄則・v2.7新設】LibreOffice 正規化必須：python-pptx 系で生成した .pptx / .potx は、最終ステップで LibreOffice headless で読み込み・再保存 することで PowerPoint Mac の修復ダイアログ問題が解消する 前提：brew install --cask libreoffice 済み。詳細は Phase 5 Post-Process Step 3 を参照

運用原則

  • 11項目はPhase 3生成時の制約として守り、Phase 4 QAで A9-A15軸により自動検査
  • ★仮説マークの項目は実装可能性を実案件で検証／不可判明時はスキル v2.4改訂で再設計
  • レーンB（Claude Design HTML）／レーンC（Claude Code SVG）では 1-c・4-1・4-2・4-4 は適用外、代替の HTML/CSS/SVG原則で担保
  • 項目4-5（フォント名鉄則）はレーンを問わず全レーンで適用。HTMLレーンでは font-family: 'Hiragino Mincho ProN W6', serif; の形式で記述
  • 項目4-6/5-3（背景方式）はpython-pptxレーン限定。HTML/SVGレーンでは background-color プロパティで対応

v2.0新設：§7 スライドレベル戦術層（★仮説）

Phase 0.7の3作法翻訳（先回り否定／対比ブリッジ／N択クロージング）を、スライド単位の視覚文法に展開する。

§7.1 先回り否定スライドの視覚文法（★仮説）

要素 推奨 理由
レイアウト 上1/3 タイトル＋下2/3 箇条書き 違和感を「列挙」する見え方
カラー 濃色1背景＋淡色1テキスト 暗めにして「真剣な告白」感
アクセント 各箇条書きの先頭にアクセント1（赤）小さく 違和感の強さを赤で示す
フォント Noto Sans JP 400、サイズ小さめ（24pt） 慎重に語る雰囲気

§7.2 対比ブリッジスライドの視覚文法（★仮説）

要素 推奨 理由
レイアウト 左右2カラム or 上下2行 対比の視覚化
カラー 左/上 = 淡色2グレー（過去）／右/下 = アクセント色（未来） グレー→カラーの転換
矢印 中央に → 1本 移行の方向性
フォント Hiragino Mincho ProN W6（核フレーズ） 重み

§7.3 N択クロージングスライドの視覚文法（★仮説）

要素 推奨 理由
レイアウト 横並び3カラム or 階段状 選択の視覚化
カラー 推奨案にアクセント1（赤）枠線、他は淡色2 推奨を明示
比較項目 3〜5項目（投資・期間・リスク・効果） 多すぎないこと
フォント Noto Sans JP 400、表は5pt〜7pt 編集容易性

§7はすべて★仮説です。戻り次第工藤レビュー前提。

v2.0新設：§8 kudo-writing 併走原則

スライド内に 文字列を1行でも生成する瞬間 には kudo-writing を併走起動すること。

§8.1 併走必須シーン

  • 表紙のタイトル／サブコピー
  • 章扉のキャッチ
  • 各スライドのアクションタイトル（25文字以内）
  • N択クロージングの3選択肢の言葉
  • 締めスライドのタグライン
  • 引用スライドの選定

§8.2 ハンドオフ

  • 本スキルは「視覚文法・生成レーン・Phase進行」担当
  • kudo-writing は「言葉そのもの」担当
  • 重複領域はあるが、最終決定は kudo-writing に委ねる

工藤独自概念の活用

ストーリーライン構築時、以下の工藤独自フレームワークを積極的に参照すること。詳細は references/kudo-concepts.md。

  • 記憶の箱（BRAND = 過去関係値の蓄積 + 未来期待値の滲み）
  • 3つの門（重要性 → 好意度 → 納得性）
  • 版木と版画（ブランドコンセプト vs マーケティングコンセプト）
  • 重力場としてのコンセプト（家族的類似性モデル）
  • Pre-POSITIONING（データの前に確信を叫ぶ）
  • 3記述構造（名詞/動詞/形容詞）

これらの概念は社内・対工藤さん向けには直接使ってよいが、クライアント向けスライド本文では平易な言葉に翻訳すること（ユーザー設定6条より）。

既存スキルとの連携（v2.0更新）

このスキルは以下のスキルと連携する：

上流（戦略・見立て・ブリーフィング）

  • kudo-mitate：上流。案件の見立て・必然性立ち上げ
  • kudo-strategy-houshin：戦略方針立案
  • kudo-strategist-lens-library：辞書型孫。戦略思考のレンズ
  • kudo-brand-lens：上流。ブランド診断
  • kudo-marketing-strategy / kudo-brand-architecture：戦略フレームワーク提供
  • kudo-briefing：オリエン受発注の前提整理

同階層・実装（v2.0新設含む）

  • kudo-deck-generation-router：Phase 3 レーン選択（v2.0新設・必須経由）
  • kudo-deck-aesthetic-qa：Phase 4 審美QA（v2.0新設★仮説）
  • kudo-schedule-budget：スケジュール・予算スライド生成
  • kudo-presenter-lens-library：辞書型孫。プレゼンターレンズ16名

横断併走

  • kudo-writing：スライド内のコピー生成（タイトル、キャッチ、見出し）— v2.0で「併走必須」明記
  • kudo-designer-lens-library：Phase 4審美QAでペアレンズ選定
  • kudo-design-mockup：ロゴ・VIのモックアップ生成
  • kudo-binary-fusion：叙述の骨格を組む際のメタ論法

ファイル出力プロトコル（SSOT参照）

保存先・マウント運用・NFC/NFD対策・present_filesのフォールバック挙動は、すべて CLAUDE.md §3「作業環境」および §3「Coworkビューワーの正しい使い方」が一次ソース。本スキルではハードコードしない。

スキル固有の運用ルール： - PPTX／HTML（Claude Design）／SVG（Claude Code SVG）は同じ案件フォルダにまとめて出力する（3レーン混在時の整合性のため） - 案件フォルダ名は [案件名]_YYYY-MM-DD 規則で統一 - ユーザーがダウンロードして実機確認するまでが完了

禁止事項（v2.0更新）

  1. 型確定前のPPTX/HTML/SVG生成
  2. ワイヤーフレーム合意前のPPTX/HTML/SVG生成
  3. Phase 3 で kudo-deck-generation-router を経由しない（v2.0新設）
  4. 8個を超える図形の追加（python-pptxレーン）
  5. GroupShapeの使用（python-pptxレーン）
  6. タイトル下アクセント線
  7. プレースホルダー文字（Lorem ipsum等）の残留
  8. クライアント向けスライド本文での独自概念語の直接使用
  9. カラーパレット外の色使用（全レーン共通）
  10. Variable Font版Noto Sans JPの使用（必ずStatic版指定）
  11. アクセント5色全部を1デッキで使う（v2.0新設）
  12. kudo-writing を併走せず文字列を確定させる（v2.0新設）
  13. Phase 4 で審美QAレーンを飛ばす（v2.0新設★仮説）
  14. 生成スクリプト内でページ番号を文字列ハードコード（v2.4新設）：Phase 5 Module 5-1で動的化することを前提に、生成時には書かない
  15. Phase 5 Post-Process を飛ばして納品（v2.4新設）：超小規模試作以外では必須実行
  16. 【v2.7新設】LibreOffice 正規化（Module 5-4）を経ずに python-pptx 生成 .pptx / .potx を納品する：修復ダイアログ問題が再発する。実機 PowerPoint Mac での A18 修復ダイアログテストを通すまで提出禁止
  17. 【v2.7新設】テキスト中に raw \n を含めて生成する：PowerPoint Mac の修復対象になる。<a:p> 段落分けまたは最小 <a:br> のみを使う
  18. 【v2.7新設】lxml デフォルトの XML declaration（シングルクォート・改行なし）で書き出す：PowerPoint Mac の修復対象になる。Office標準フォーマット必須

トラブル対応

日本語フォントがThinに化ける場合

Noto Sans JP Variable Font版が原因。scripts/font_setter.py の set_japanese_font_static() を使用すること。

図形が選択ペインで識別できない場合

全図形に shape.name = 'S{slide}_{role}' の命名を付与。

Mode Bで既存テンプレを保ちつつ内容を差し替えたい場合

python-pptxの inventory.py パターンでテキスト在庫を抽出 → 差し替え。新規スライド追加は最小限に。

Claude Design 出力をPPTXに統合したい場合

kudo-deck-generation-router §4 のハンドオフ仕様に従う。

SVG出力の印刷時に色が変わる場合

RGBカラープロファイルを sRGB に固定し、印刷時は CMYK 変換版を別出力する。

§子スキル参照（v2.7更新）

kudo-client-template-factory v0.7（PPTXエンジニアリングSSOT）

本スキル（kudo-proposal-deck）の 物理品質レイヤー を担う実装SSOT。Phase 3 で生成ルートを「python-pptx」に決めた瞬間に、kudo-client-template-factory v0.7 §N PPTX Engineering SSOT の6原則を満たすよう build script を構築すること。本スキルは「論理品質レイヤー（構成・ナラティブ・コンテンツ）」を担い、kudo-client-template-factory が「物理品質レイヤー（XML構造・修復ダイアログ・互換性）」を担う関係。

6原則（kudo-client-template-factory v0.7 §N より引用要約）： 1. LibreOffice 正規化を build script の最終ステップに必ず組み込む 2. ref-template-17 の slide1.xml をベースに上書きする 3. XML declaration は Office標準フォーマット（ダブルクォート＋standalone="yes"＋CRLF＋minify） 4. shape構造は必要最小限（不要な extLst や 空の spPr 禁止） 5. text に raw \n を含めず、<a:p> 段落分け or 最小 <a:br> のみ 6. theme1.xml の effectStyleLst から shadow effect を完全除去

詳細プロトコルは kudo-client-template-factory v0.7 のフルSKILL.md を参照すること。

§9 FRAMEWORK式ナラティブ構成（デフォルトプロトコル・v2.8新設・2026-05-07）

§9.0 なぜこのプロトコルが必要か

工藤拓真がクライアントワークで関わる相手は、ブランディング・マーケ戦略の専門家でないことがほとんどである（経営者／編集者／クリエイター／プロダクト担当者など）。 彼らは結論を急がれると「論理プロセスへの納得感」を得られない。 本プロトコルは「議論ナビゲーション付きデッキ構成」として、結論を急がず6つの問いを順番に埋めていく構造を取る。

§9.1 適用条件・例外条件

デフォルト適用するケース（つまりほぼ全てのクライアント案件） - 相手がブランディング・マーケ戦略の議論に慣れていない - 提案の論理プロセスを相手と共有したい - 結論だけ提示して終わり、ではなく合意形成型で進めたい - 中量・体系化型のデッキ（kudo-deck-generation-router でレーンA／ハイブリッド選択）

適用しない例外 - 軽い社内資料・データ報告・アップデート報告（軽量レーン） - 既存の意思決定者向け短時間資料（5-10分プレゼン） - 講演資料でプレゼンター主導で進めるとき（kudo-presenter-lens-library に従う）

§9.2 6つの問い設計法

ペーパー全体を「6つのQ&A」の構造として組み立てる。Q1〜Q6は独立した章として展開する。

汎用テンプレート（案件で具体化する）

Q 問いのタイプ 何を決めるか
Q1 立て方・位置づけの問い カテゴリー／コンセプト／記憶の箱の決定
Q2 構造の問い ブランドフォーメーション／組織構造／関係性
Q3 誰に届けるかの問い ターゲット顧客像の解像
Q4 市場規模・実現可能性の問い TAM/SAM/SOM／売上シミュ
Q5 差分の問い BEFORE/AFTER／いまと未来の違い
Q6 実装の問い ロードマップ／フェーズ／スケジュール

数の柔軟性：5〜7問の範囲で調整可。ただし6を基準とする。多すぎると俯瞰しづらく、少なすぎると論理が雑になる。

§9.3 4種類のスライド役割分担（必須）

種類 視覚的特徴 役割
①本編スライド 白背景／サンセリフ／論点提示 議論の主たる流れ
②語りスライド 明朝体／余白多め／引用符／問いかけ 論点と論点の橋渡し
③コラムスライド 黒太枠（5px）＋赤縁（1px）＋赤帯COLUMNバッジ／明朝体 補足知見・事例・引用
④★答えスライド 章末／問い＋答え＋根拠の3層構造／フォントサイズ大 章の結論を確定・進捗可視化

原則：4種類が視覚的に瞬時に区別できる必要がある。違反は kudo-deck-aesthetic-qa の機械検査軸 A21〜A23 で検出（連動）。

§9.4 ペーパーの読み方ガイドスライド（P3〜P5に配置）

冒頭オリエンテーション部分に、4種類のスライドを解説するスライドを必ず1枚作る。 慣れていない相手が「いまどの種類のスライドを読んでいるか」を見失わないため。

§9.5 各章末★答えスライドの構造（必須）

[Q◯] 問い：◯◯◯
─────── 横線 ───────
[A.] 本日の答え
     ◯◯◯◯◯◯（フォントサイズ大・明朝体）
     ◯◯◯◯◯◯◯（短い説明文）
     根拠：◯◯◯◯（事実ソース・既存議論への参照）

各章で議論した結論を、上記フレームに当てはめて1枚に圧縮する。 ペーパー全体の進捗が目で見えるようになる。

§9.6 FRAMEWORK完成版（クロージング前に必須配置）

6問×6答えを表形式で1枚に並べたスライドをクロージング直前に置く。 ペーパー全体の俯瞰となり、これが「今日決めたい3つ」への自然な橋渡しになる。

§9.7 抽象概念の脳内図解化（補助技法・任意）

ブランド理論・心理理論・記憶の箱など「お客さんの認識」が中心テーマのとき、抽象概念を脳内ビジュアル化する技法。

実装ルール - 脳の輪郭を破線（dasharray="4 3"）の有機的な曲線で描く - ラベル：「— お客さんの脳内 —」を脳の上部に配置 - 概念ボックスは脳の輪郭の内側に配置 - BEFORE/AFTERで脳を2つ並べて差分を見せる用法も有効

使用判断：必須ではない。テーマが「お客さんの認識」に強く関わるときに使う。

§9.8 すぐやる×未来構想ロードマップ分離（必須）

ロードマップを提示するとき必須の作法。

フェーズ分離原則 - Phase 1：即実装（〜数ヶ月）→ 視覚的にハイライト（プライムカラー枠線） - Phase 2〜3：中期構想（〜2年）→ 通常表示 - Phase 4〜5：中長期構想（〜5年）→ 「未来構想として議論」と明記＋色を落とす（Ochre系）

禁止事項：「全フェーズを並列に同じ重みで見せる」ことは禁止。「実装できないことばかり」と誤解されるリスクを排除する設計責任。

§9.9 連動スキル

スキル 連動内容
kudo-marketing-strategy 複数事業ライン（B2C/B2B/B2G）同一フォーマット解析、売上シミュ濃縮型
kudo-deck-aesthetic-qa 4種スライド差別化チェック（A21〜A23）、★答えスライドの構造チェック
kudo-presenter-lens-library レンズが選ばれた場合は本プロトコルに優先する（ナラティブ完走原則）
kudo-binary-fusion 各章末の論理組み立てに併走

§9.10 適用例

実証済み案件：問い読リブランディング提案（2026-05-08 MTG用 / 全55ページ） - Q1：どんな記憶の箱を立てるか？ → 答え「読書ジム」 - Q2：B2CとB2Bは別の箱で立てるか？ → 答え「Y字ラダー」 - Q3：その箱に誰が来るのか？ → 答え「30-40代×自分を変えたい層」 - Q4：その市場はどれだけの規模か？ → 答え「B2C 3,000人／B2B 数十社」 - Q5：いまと、これからの差分は？ → 答え「4つの構造的変化」 - Q6：いつ、何を、どう動かすか？ → 答え「5フェーズで段階実装」

このフォーマットで、岩佐さん・井上さん（編集者出身）への提案を組み立てた。

§9.13 可読性・密度ハードガード（v2.10新設・2026-05-08）

工藤さんの2026-05-08「スキル群がちょっと複雑になっちゃってる、出力PPTがUPDATEされるようにチェックして」発話を起点に、目次・密度・最小フォント・統一書体を本スキルに永続実装する。本節は強制ハードガードであり、kudo-deck-aesthetic-qa A24-A27でFAIL判定の根拠となる。

§9.13.1 目次は問いの形式で3-5問に絞る

  • 目次スライドは章名の羅列ではなく、問いの形式で記述する（FRAMEWORK式 §9と整合）
  • 項目数は3問以上5問以下（6問以上はFAIL扱い、kudo-deck-aesthetic-qa A24）
  • 6問を入れたい場合は、必ず2問を統合 or 1問を後段の補足に降格させる

§9.13.2 1スライドあたりのテキスト要素数上限

  • 1スライドのShape／Text Box合計 ≤ 12個（kudo-deck-aesthetic-qa A26でFAIL判定）
  • これを超える場合、必ずスライド分割 or 図解化（脳内図解化＝§9.7）で要素を減らす
  • 例外：FRAMEWORK完成版・データ密度型コンサルスライド・年表は §9.13.5 で別ガード

§9.13.3 最小フォント基準（50代男性ノートPC可読・ハードガード）

種別 最小サイズ 推奨レンジ
DISPLAY（見出し） 32pt 32-54pt
READING（本文） 18pt 18-24pt
UI（注釈・キャプション） 14pt 14-18pt
  • 9-13ptの混入は絶対禁止（kudo-deck-aesthetic-qa A25でFAIL判定）
  • 旧Pattern B-Hiraginoの「READING 11-16pt／UI 9-12pt」は廃止された旧基準
  • 情報量が入りきらない場合は、必ずスライド分割で対応（フォントを下げて入れる行為は禁止）

§9.13.4 統一書体ハードガード

  • 本節はフォント名を直接書かない。フォントファミリーの指定は個人設定§8およびkudo-brand-tokens.json（一次ソース）を必ず参照すること
  • 構造的ルール（フォント名に依存しない普遍規則）：
  • theme XMLでは <a:latin> と <a:ea> に同じファミリー名を指定（混植廃止・フォールバック事故ゼロ）
  • ウェイト指定はファミリー名に含めず <a:rPr b="1"> および Style 名（Regular／SemiBold／Bold等）で制御
  • 「ファミリー名+別ウェイト」の2段構造フォントを採用する場合は、kudo-client-template-factory §N PPTX Engineering SSOT で実機検証済みのワークアラウンドを通すこと
  • 「逸脱」許容条項：キービジュアル・表紙・キーコピー単体で、規範フォントを意図的に外して別フォントを使うことは禁止しない（ブランディング表現として推奨）。逸脱は「全体規範を理解した上で意識的に外す」場合のみ
  • kudo-deck-aesthetic-qa A27：theme1.xml に latin/ea が同一ファミリーで揃っているか／個人設定§8で指定されたファミリー名と一致するかを機械検査
  • パターン履歴（2026-05-08時点）：旧Pattern B-Hiragino → 旧Pattern C-Yu案 → 確定 Pattern D-Noto。今後 Pattern が改訂された場合も、本節は変更不要（個人設定§8が一次ソース）

§9.13.5 例外条項（密度上限を超えてよい場合）

  • FRAMEWORK完成版1枚（§9.6）：6問の答えを並置するため最大18要素まで許容
  • データ密度型コンサルスライド：表形式は元から「行×列」の数の話なので要素数カウントから除外
  • 年表・タイムライン：時間軸を持つシークエンスは要素数より「時間ステップ数」で評価
  • これらの例外は明示的にスライドノートに「§9.13.5 適用」と記載すること

§9.13.6 HTMLプレビュー先行プロトコル（新規デッキ必須）

  • 新規デッキは PPTX 化前に必ず HTML 一枚物（16:9 比率）で構成・密度・font段階を確認
  • 詳細は kudo-deck-generation-router §1.6（v1.2新設）を参照
  • HTMLで OK が出てから PPTX 化に進むこと。順序を逆にしない
  • 既存デッキの磨き込み（Mode B）はこのプロトコルを免除（差分作業のため）

§9.13.7 「あとで編集しやすい形式」の維持原則

  • 自動ページネーション：必ずslideMasterの右上fixed textboxで実装（kudo-client-template-factory v0.7準拠）
  • 図形数最小化：装飾的なshape（重ね飾り・shadow）は禁止、内容を伝える図形のみ
  • グループ化禁止：GroupShape は使わず、個別Shape として配置（クライアント側で個別編集可能に）
  • テーマカラー参照：直接hex指定でなく theme color slot 経由で配置（クライアント側で「テーマの色」変更でデッキ全体が連動）

§10 更新履歴

  • v2.10（2026-05-08）：§9.13「可読性・密度ハードガード」新設。工藤さんの「スキル群が複雑」発話を起点に、(1)目次3-5問形式、(2)1スライドtext要素12個以内、(3)最小font 18pt本文/14pt注釈、(4)統一書体Pattern C-Yu（游明朝/游ゴシック2書体のみ・Hiragino×Helvetica混植廃止）、(5)HTMLプレビュー先行プロトコル必須化、(6)theme XML latin/ea同一ファミリー指定、を本スキルに永続実装。kudo-deck-aesthetic-qa A24-A27と連動。kudo-deck-generation-router §1.6（HTML先行）と連動。個人設定§8もPattern B-Hiragino → Pattern C-Yuに改訂（2026-05-08同期）。

  • v2.8（2026-05-07）：§9 FRAMEWORK式ナラティブ構成をデフォルトプロトコルとして新設。問い読リブランディング案件（5/8 MTG）での実証を踏まえ、議論慣れしていない相手（経営者・編集者・クリエイター）向けに、6つの問い・4種スライド役割分担・★穴埋め式・脳内図解化・すぐやる×未来構想分離を体系化。kudo-marketing-strategy／kudo-deck-aesthetic-qaと連動。

  • v2.7（2026-04-28）：(1)PPTX生成の絶対遵守6原則を §11 項目4-7／4-8／5-4／5-5 として新設。kudo-client-template-factory v0.7 §N PPTX Engineering SSOTを物理品質レイヤー実装SSOTとして参照する関係を明文化。(2)Phase 4 QAに「物理品質QAレーン（レーン3）」追加：修復ダイアログテスト／6原則準拠チェック／shadow完全除去確認の3項目。(3)Phase 5 Post-Process に Module 5-4「LibreOffice正規化」を必須化。(4)禁止事項に項目16-18を追加（LibreOffice正規化スキップ禁止／raw \n禁止／XML declaration デフォルト禁止）。kudo-deck-master.potx 開発（2026-04-28）の「python-pptx 12年既知問題（Issue #87）を LibreOffice 正規化で解決」という発見を構造化し、未来の全PPTX案件に効かせるための改訂。

  • v2.6（2026-04-28）：kudo-master-v9.3-hiragino.potx 連動。各slide.xmlに固定textbox（左上共通説明・右上自動連動ページ番号）を直接配置する方式を確立。v9～v9.2でPlaceholder方式が PowerPoint Mac で表示されない問題を発見し、固定textbox方式へ方針転換。<a:fld> id属性はhex GUID必須（英字混入不可）の鉄則を確立。
  • v2.5（2026-04-28）：Mac PowerPoint theme XML 和文フォント解決鉄則を確立。v2.3鉄則（サフィックス禁止）は和文ファミリー名指定の問題を捉えていたが、「ファミリー名+別ウェイト」の2段構造フォント（凸版文久・源ノ明朝）が theme XML 経由で解決失敗する根本問題を見落としていた。kudo-master-v6.potx（Apple版凸版・ファミリー名のみ）と v7-sourcehan.potx（源ノ明朝 Heavy）で順次実証→ v8-hiragino.potx（Hiragino Mincho ProN W6/W3）で本文確定→ v8.1-hiragino.potx で slideMaster の bullet font Arial 9箇所を Helvetica Neue に統一→ v8.2-hiragino.potx で背景色を色ボックス被せ方式から <p:bg> 属性方式に統一。鉄則を以下に拡張：項目4-5（4条件：ウェイト含むファミリー名／Adobe版サフィックス禁止／実機未インストール禁止／bullet統一）、項目4-6（背景は属性、色ボックス被せ禁止）、項目5-3（生成時から方式）。Pattern B → Pattern B-Hiragino へ改名し、4フォント名を Hiragino Mincho ProN W6／W3／Hiragino Sans W3／Helvetica Neue に更新。スピーカーノートは theme継承で自動Hiragino化される（明示指定不要・notesMaster点検で確認）。CLAUDE.md §6 およびユーザー設定#8 の修正提案も発生。
  • v2.4（2026-04-27）：Phase 5「Post-Process」を新設。生成と仕上げを分離する設計思想を導入。dof向け歌舞伎ブリーフィング案件（2026-04-26）でページ番号の固定文字列ハードコードとフォント名のサフィックス問題が連続発生したことが起点。両者は「生成時にハードコードして実機で破綻する」共通構造を持っており、構造的に防ぐためにPost-Process工程を独立化した。Module 5-1（add_page_numbers.py・実装済）、5-2（verify_fonts.py・★仮説）、5-3（verify_design_tokens.py・★仮説）の3モジュール構成。絶対遵守項目を11→13に拡張、禁止事項を13→15に拡張。
  • v2.3（2026-04-25）：絶対遵守11項目に項目4-5「フォント名Mac実機表示名鉄則」を追加。dof向け歌舞伎ブリーフィングPPTX（19枚版）でMac PowerPoint上にフォントが反映されない事故が発生し、原因がフォント名のサフィックス（StdN/Pr6N R/Display Pro等）にあったことから永続ルール化。今後すべてのPPTX生成で 凸版文久見出し明朝／凸版文久明朝／Noto Sans JP／Neue Haas Grotesk Text Pro の4フォント名を厳守。CLAUDE.md §6 およびユーザー設定#8 の修正提案も発生。
  • v2.2（2026-04-25）：Phase 2.5「所要時間シミュレーション」を新設。Phase 2合意後、Phase 3生成前に必須の機械的時間試算工程を組み込んだ。スライド種別ごとの所要時間テーブル、オーバー時の3択提示、工藤さんの早口補正（×0.75-0.85）を内蔵。
  • v2.0.1（2026-04-24）：ファイル出力プロトコル（v2.1節）のパス記述を短縮形（~/working/claude/claude-reference/）からフルパス（~/Library/CloudStorage/OneDrive-くどう商店/working/claude/claude-reference/）に統一。短縮パスは実在せず、AIエージェントから参照不能なため（全スキル横断のパス整合タスクの一環）。

  • v2.0（2026-04-21）：大胆アップデート。Phase 3を3レーン化（A. python-pptx／B. Claude Design／C. Claude Code SVG）し kudo-deck-generation-router を経由必須に変更。Phase 4に審美QAレーン追加（kudo-deck-aesthetic-qa★仮説）。スライドレベル戦術層§7新設（★仮説）。kudo-writing併走原則§8明文化。子スキル一覧更新（4実装子＋1辞書孫）。アクセント5色同時使用禁止追加。工藤12時間不在中の自律実行で改訂。★仮説マーカー付箇所は戻り次第レビュー前提。

  • v1.x（既存）：5型×2モード、5 Phaseプロトコル、3作法翻訳地形整備、python-pptx単一ルート。

§11 戻り次第レビューしてほしい★仮説一覧

  1. ★仮説：Phase 3 を kudo-deck-generation-router 経由必須化することの是非
  2. ★仮説：Phase 4 審美QAレーンの独立スキル化（vs 親統合）
  3. ★仮説：§7 スライドレベル戦術層の3作法視覚文法（カラー指定／レイアウト指定）
  4. ★仮説：アクセント運用比率 70:25:5
  5. ★仮説：アクセント5色同時使用禁止の徹底
  6. ★仮説：kudo-writing「併走必須」のトリガー定義（1行でも生成する瞬間 = 範囲広すぎないか）
  7. ★仮説（v2.4）：Phase 5 Module 5-1 のページ番号配置位置（右上 11.05inch / 0.25inch）が全テンプレで適切か
  8. ★仮説（v2.4）：Phase 5 Module 5-2 verify_fonts.py の正規化マッピングを kudo-brand-tokens.json に集約する設計
  9. ★仮説（v2.4）：Phase 5 Module 5-3 verify_design_tokens.py の実装優先度（複数案件需要が貯まってからでよいか）
  10. ★仮説（v2.5）：項目4-6「背景は属性方式」の生成スクリプトでの実装方法（python-pptxのslide.backgroundAPI動作検証）
  11. ★仮説（v2.5）：項目5-3「生成時から」をPhase 5で機械検査する verify_background.py の実装

v2.5 (2026-04-28) は、kudo-master.potx のフォント・背景設計を v5FINAL→v8.2-hiragino へ全面更新する作業の中で確立した。実証済み版（v8.2-hiragino.potx）を Templates.localized の正本として運用すること。