slide-studio — デザイン主導のスライド制作パイプライン

「モックアップで合意してから実装する」のがこのスキルの核。実装後の構図手戻り（色・フォント違いだけの使い回し、図の欠落）を、実装前の画像合意で潰す。

Phase 0  ヒアリング・素材取り込み・要件定義
Phase 1  代表3ページ × 3デザイン案のモックアップ
Phase 2  デザイン選定（1〜3案）
Phase 3  全ページモックアップ（章単位で逐次合意）← 実装の設計図
Phase 4  マスターPPTXビルド → 選択された出力先へ書き出し
Phase 5  出力先ごとの検証 → 納品

前提条件

必須

推奨（無くても進行できるが、精度・工数が悪化する）

課金が発生する箇所と目安

このスキルは画像生成を多用する。着手前に必ず概算をユーザーへ提示し、了承を取ること。

• 生成はやり直しが前提。差し戻し1回で10〜20枚増えるので、上振れ幅も含めて伝える
• 無償枠のあるサービスでも、並列生成は同時実行上限と従量課金の両方に当たる。波に分けて回す

対応環境

macOS / Linux 想定（soffice・シェルスクリプト前提）。Windows は WSL 推奨。

作業ディレクトリ

作業は任意の作業ディレクトリ（案件ごとに1つ）で完結させ、scripts/ 一式をそこへコピーして使う。 配置場所の規約は各自の運用に合わせてよい。

mkdir -p <project>/{assets,mockups,output} && cd <project>
cp <このスキルのディレクトリ>/scripts/* .

Phase 0: ヒアリング・素材取り込み・要件定義

最初に確定させる項目（複雑案件は着手前ヒアリング必須）:

1. コンテンツ素材の有無（既存資料・原稿・箇条書きメモ）
2. 参考デザインの有無（トンマナ指定・参考資料・参考URL）
3. 対象読者と利用シーン（投影/送付、顧客向け/社内向け/代理店向け）
4. 出力先（複数選択可）: PPTX / Googleスライド / Canva
5. ページ数感・納期・複数バリアント（読者別デッキ）の要否

素材取り込みの鉄則

• Googleスライド/Docsはテキスト抽出だけで済ませない。図・グラフ・チャートの中身が欠落する。必ず PDFエクスポート（Drive の export 機能で application/pdf を指定。CLI・API・MCP・ブラウザのいずれでも可）→ 実画像として開いて全ページ照合する。テキスト抽出は文言コピーの補助にとどめる
• 図の数値が読めない場合も推測で埋めない。実画像で確認できたものだけ反映し、できないものは確認事項に残す
• 素材が無い場合はサブエージェント並列リサーチで原稿を起こす: 市場・競合・構成事例など切り口別に並列調査し、統合してから構成案を作る

要件定義（requirements.md）

■目的/■現状/■課題/■実現したいこと の型で書き、構成マップ（ページごとの型・内容・必要素材）、トンマナ定義、確認事項（実績数字・ロゴ・写真など不足素材）を含める。不足素材はダミー明記（スライド上にも「※数値はダミー」注記）で先行し、確認事項を残したまま50-60%で共有して進める。

Phase 1: モックアップ第1弾（代表3ページ × 3デザイン案）

先に references/art-direction-spec.md を埋める（MUST）

様式名で生成指示を書かない。数値で書く。 「エディトリアル風に」「Swiss Style で」程度の指示では モックアップの質は上がらず差し戻しになる（実案件で発生）。 マージン・グリッド・タイプスケールの段階数・行長・行間・線幅・色数・図解の要素数・人物の撮り方までを 具体値で確定し、全生成プロンプトの先頭に丸ごと貼る。実装（Phase 4）でも同じ数値を使う。

方向の作り方

代表3ページ（例: 表紙・商材の概念図・データ密度の高いページ）を、構図から異なる3方向で生成する （配色・フォント違いだけの3案は作らない）。参考デザインが無い場合は、先にサブエージェントでデザイン事例を リサーチしてから方向を決める（いきなりカード型に逃げない）。

様式カタログから3つ選ぶのではなく、最低1つは案件のテーマそのものを図法で語れる方向を発明する。 例: 「ツールを"定着"させる支援」→ 設計図の分解組立図で層を重ね最下層にピンを打つ（定着＝固定を図で言い切る）。 汎用スタイルを3つ並べただけの案は、どれを選んでも凡庸になる。

崩してよいのは構図・図法・色。マージン・タイプスケール・行長・行間・コントラストは固定する。 投影案件では明背景ベースを優先する（暗背景は明るい会議室で白飛びし、実案件で不採用になった）。

画像生成のフォールバックチェーン

上から順に、その環境で使えるものを使う。

1. 接続済みの画像生成CLI/スキルがあればそれを使う（生成・待機・URL回収まで1コマンドで完結するものが望ましい）。 並列時は同時実行上限に注意し、超過分は波に分ける。1枚2〜3分かかる系のモデルでは、3枚以上をフォアグラウンド直列にしない。 バックグラウンド実行のスクリプトにして同時4本程度の波で回し、ジョブごとに > name.log へ書いて最終行のURLを回収する形にすると、中断からの再開・差分再生成に強い（pitfalls 27）
2. 無ければ 画像生成APIのキー（環境変数に設定されているもの）を確認し、APIを直接叩くスクリプトを書く
3. どちらも無ければ 生成AIのWeb版をブラウザ自動化で叩いて生成・ダウンロードする
4. いずれも使えなければ、手描きラフ・既存資料の再構成で代替し、画像モックアップより精度が落ちることをユーザーに明示する

生成プロンプトの鉄則

• 実在ブランド名・ロゴを入れない。ロゴ位置は「LOGO」プレースホルダー、数値はダミーであることを明記
• 人物素材は生成してよい（会議風景・作業中の人・手元・後ろ姿・モデル的な人物）。資料は人が写っている方が伝わる場面が多いので、無理に無人の絵に逃げない。 禁止は実在の特定個人の代役として生成することだけ（代表・講師・顧客・受講生など「その人」を指す枠に別人の顔を当てるのは肖像の捏造）
• 日本語の文字列は「指定したものだけを正確に描く」と指示し、短く絞る
• プロンプトに no incidental text inside any illustration or photograph を入れる。 それでも指定外のテキストは混入する（図面枠に架空の図番・作成日、写真のホワイトボードにもっともらしい書き込み、 数字と単位の分離）。実案件で全部発生した
• 生成後は全数目視: 文字化け・実在IP混入・意図しない人物の写り込み・指定外テキストの混入をチェックしてから提示する

Phase 2: デザイン選定

3案を並べて提示し、ユーザーに1〜3案選んでもらう。「Aベースで大数字ページだけB」のようなハイブリッド指定も受ける。根拠付きの推薦を添える（Yes-manで全部並べるだけにしない）。

推薦は見た目の良さではなく、案件のテーマと図法が一致しているかで書く。併せて必ず示す:

• 各案の向く場面と向かない場面
• 実装コストの差。凝った図法ほど PptxGenJS 再現が重い。目安を添えたうえで、 ①完全ネイティブ（全要素編集可・工数大）か ②ハイブリッド（図だけSVG/画像・図内文字は編集不可）かをユーザーに選ばせる

Phase 3: 全ページモックアップ（このスキルの核）

選定された案ごとに、全ページ分をモックアップ画像で生成する。ここで構成・文言・レイアウトを確定させ、実装の設計図にする。

• 章単位で「これでいいですか」を挟む逐次確認ループ。修正はモックアップ段階で吸収する（実装後の構図修正はコストが一桁違う）
• 表・図解・グラフのページも必ずモックアップ化する（あとで「図が違う」となる最頻ポイント）
• IMPORTANT: 全ページ承認は飛ばせない必須ゲート。 承認が返るまで Phase 4 に進まない。 納期が近い・ユーザーが不在・「後から直せる」は、飛ばしてよい理由にならない（飛ばすと実装後の作り直しになり、結局そちらの方が遅い）。 返事が来ない場合は、生成だけ進めて手を止めて承認待ちであることを明示する。「進みます」と書いて自分で先に行かない
• 承認は章ごとに取り、最後に全ページ通しでもう一度「この構成・このデザインで確定でよいか」を取る
• 承認済みモックアップは実装の合格ライン。承認済みモックアップと実装の乖離は不具合として扱う

Phase 4: マスターPPTXビルド → 出力先へ書き出し

マスターPPTX（PptxGenJS ネイティブ実装）

build_template.js を案件用にコピーして書く。実装原則:

• IMPORTANT: 合格ラインは「構図が合っている」ではなく「モックアップの再現」。 モックアップにある要素（帯・罫線・写真の掛かり方・文字ウェイトの差・余白の比率・図の要素数）を省略しない。 PptxGenJS で表現しきれない箇所が出たら、黙って簡略化せず、その場でユーザーに相談して代替を決める（グラデーション・写真の合成・特殊な文字組みが該当しやすい）
• モックアップを開いて、同じ画面に並べながら実装する。記憶で書かない
• デザイントークン（色・フォント・余白）を先頭で定義し、ページ×案ごとにレンダラーを書く。複数案が生き残っている場合、「色・フォント違いだけ」の共通レンダラーは禁止（構図から分ける）
• 1ソース多デッキ: スライド定義を共有オブジェクト＋変種オブジェクトにし、デッキごとの順序配列で組む（読者別デッキ・出力違いに強い）
• レイアウトlint内蔵（deck_lint.js）: 枠あふれ・テキスト衝突・図形との半重なり（円・三角は実形状判定）・罫線横断・矢印の接続先・スライド外はみ出しを毎ビルド自動検知。警告ゼロが納品条件
• 長文タイトルは fitFs() でオートフィット（文言差し替えに強くする）
• 素材は使用枠のアスペクト比に事前クロップして配置する（prep_assets.py。sizing頼みにしない＝歪みゼロ）。ロゴは背景透過で切り出し、暗背景用/明背景用の2色を背景に応じて使い分ける
• 不足素材はプレースホルダー（LOGO/PHOTO枠＋差し替え注記）。汎用の人物素材はAI生成で用意してよい。実在の特定個人を指す枠（代表・講師・顧客の顔）だけは支給されるまでプレースホルダーのままにする
• フォントは Noto Sans JP / Noto Serif JP を基本とし、納品先の環境差はフォント埋め込みかPDF併用で案内する

出力先書き出し（複数選択可）

PPTXがマスター。修正は必ずマスター側を直して再書き出す（変換先の直接編集は次の修正で消える）。

Phase 5: 検証 → 納品

1. lint（ビルド時に自動実行・警告ゼロ）
2. PPTX→PDF→全ページ目視: soffice --headless --convert-to pdf → 1ページずつ実画像で確認（重なり・折り返し・コントラスト・誤字・実在IP）
3. モックアップ差分照合（必須）: 承認済みモックアップと PPTX レンダを1ページずつ並べて見比べ、 構図・余白比・文字ウェイト・帯や罫線の有無・写真の掛かり方の差を洗い出す。 「構図が合っているから可」で通さない。 差はモックアップ側を正として実装を直す。 直せない差が残る場合は、勝手に妥協せず差分リストとしてユーザーに提示して判断を仰ぐ
4. 出力先ごとの検収: Googleスライド=PDFエクスポートで照合 / Canva=ブラウザでページ送りスクショ照合
5. 修正 → 再ビルドで 1〜4 を自動的に再実行。大型案件（数十ページ級）は並列サブエージェントで全数検収する

LibreOfficeレンダはPowerPoint実機と微差があるため、納品直前にPowerPoint実機で1周見ることを推奨として案内する。

落とし穴

実案件で踏んだものを references/pitfalls.md にまとめてある。Phase 0 の素材取り込みと Phase 4 の実装前に必ず読む。

アートディレクションの数値仕様と方向出しの作り方は references/art-direction-spec.md。Phase 1 の前に必ず読む。