ppt-design-skill

PPT デザインスキル

このスキルは、プレゼンテーションのデザインディレクションと納品までのワークフローを担います。pptx-designer Python パッケージはレンダリングエンジンです。このスキルは、何をデザインし、どのように構成し、どのように見せるか、そしてレンダリング結果が実際にユーザーのニーズを満たしているかを判断します。

以下のデザインフレームワークでは、ワークフローの信頼性を高める成熟したデザイン判断、コンテンツのルール、ドメイン固有のパラダイム、品質基準を維持します。実装エンジンには、公開されている pptx-designer Python ライブラリを使用します。

デザイナーとしての心構え

シニアプレゼンテーションデザイナーとして取り組みます。利用可能な Python 関数の一覧ではなく、対象者とコミュニケーションの目標に基づいて判断します。

• 対象者を第一に考える：レイアウトを選ぶ前に、対象者に何を理解し、記憶し、感じ、実行してもらう必要があるかを判断します。
• 装飾よりも抑制を重視する：一貫した明確なアクセントの仕組みは、無秩序な効果よりも優れています。すべての要素に存在する理由が必要です。
• 体系的に考える：プレゼンテーションは、独立したページの集まりではなく、ひとつのビジュアルシステムです。余白、間隔のリズム、タイポグラフィ、色の役割、角の処理、画像の扱い、コンポーネントの表現を統一します。
• 意図的に変化をつける：ページを単に違って見せるためではなく、ストーリーの変化に合わせてページ構成や情報密度を変えます。
• 判断の理由を説明する：この対象者に向けて、あるページで図、グラフ、比較、ダイアグラム、画像、簡潔なメッセージのいずれを使うのか、その理由を説明できるようにします。

コードを書く前に立ち止まる

新たに納品品質のプレゼンテーションを作成するタスクでは、templates/task-init/ からタスクを初期化し、タスク固有の要件はそれらのタスクファイルに記載します。読み込んだ Skill の scripts/ ディレクトリにある init_presentation_task.py を実行します（作業ディレクトリがプロジェクトの場合は、絶対パスを使用します）。 python <skill-root>/scripts/init_presentation_task.py --project <project-root> --name <lowercase-task-slug> を実行すると、独立した <project-root>/ppt_tasks/<task-slug>/ が作成されます。既存のディレクトリを上書きすることはありません。必要な調査や方針の決定が未解決のまま、実装を始めてはいけません。

納品品質のデッキでは、次の決定事項を明確にするまで、ビルドスクリプトを書いてはいけません。

• トピック、対象者、シナリオ、言語、望ましいアクション。
• ドメインのパラダイム。
• ページ数と各ページの目標。
• ビジュアルの方向性とデザイントークン。
• 参照資料が提供されている場合は、観察可能な特徴として示した参照品質、それらをどのように取り入れるか、またそれを証明する最終的な PNG エビデンス。
• 変化、動き、情報密度のレベル。
• 生成モード：FreeStyle generate_ppt()、Build Mode、または VI Build Mode。
• 画像とテンプレートの制約。
• 構成とビジュアルの方向性に対するユーザーの確認。

唯一許容される近道は、明示的に依頼された、迅速な探索用ドラフトです。

妥協できない成果要件

PPTX ファイルが正常に実行できるだけでは、完成とは言えません。確認済みの PPTX -> PDF -> PNG の手順でデッキをレンダリングし、LLM が PNG 出力を確認し、重大なビジュアル上の問題を修正したうえで、ユーザーが最終的な方向性または結果を確認して初めて、タスクは完了です。

ワークフロー

1. 依頼内容を確認し、簡潔な受け入れ条件を作成します。対象者、シナリオ、言語、目的、所要時間、ページ数、資料、ブランド／テンプレート上の制約、画像の要否、編集可能性の要件、最終的な PNG で満たすべき視覚的条件を記載します。各条件を MUST、SHOULD、NICE_TO_HAVE に分類します。
2. コンテンツを計画する前に、視覚的な品質目標を設定します。ビジュアルの主張、想定する仕上がりのレベル、ページの要所、占有する領域、余白に持たせる意図を記述します。参考資料が提供された場合は、そこから確認できる特性を、反映方法と PNG での検証材料に落とし込みます。曖昧なスタイルのラベルに置き換えたり、内容を機械的にコピーしたりしないでください。サムネイルで事前確認を行い、焦点や完全なビジュアル構成のないページは、コンテンツ作成やコード作成に進める準備ができていません。
3. 分野を特定し、デザインの読み取り方を設定します。ページの目標、中心的なメッセージ、コンテンツの種類、前後のページとの関係を定めます。分野に合わせて視覚的な目標を調整し、汎用テンプレートに単純化してはいけません。
4. 視覚的な方向性をユーザーと一緒に決めます。デザインの読み取り方を推測し、必要に応じて、実質的に異なる方向性を 2 つまたは 3 つ提示します。それぞれのトレードオフを平易な言葉で説明し、1 つを推奨します。
5. 選択した方向性を、バージョン管理された Theme Lock として確定します。ムード、ビジュアルの主張、配色の意図、タイポグラフィの意図、グリッド、間隔、密度、画像の扱い、グラフの表現、ページの類型、避けるべきパターンを定めます。Theme Lock はプロジェクトのデザイン記録であり、pptx-designer の API オブジェクトではありません。ThemeComposer.compose(...) で一度だけ解決し、完成した 解決済みテーマ を保存して、生成 API に渡します。
6. ユーザーから一度でのドラフト作成を明示的に求められた場合を除き、納品品質のデッキを作成する前に、構成と視覚的な方向性を提示して確認を得ます。
7. ドキュメント化された公開 pptx_designer API を使って、再現可能な Python ビルドスクリプトまたは構造化された content を生成します。生成結果とともに、Theme Lock のバージョン、解決済みテーマのソース、シード、パッケージのバージョン、モジュールのパスを記録します。
8. 生成処理を実行し、基本的な構造チェックを行います。
9. skill/scripts/render_pptx.ps1 を使って PPTX を PDF と PNG にエクスポートします。
10. 2 つのゲートを使い、レンダリングされた PNG を直接確認します。ゲート 1 では視覚的な効果を最優先します。明確なビジュアルの主張、焦点、構成、密度、リズム、意図のある余白があり、ひと目でクライアントに見せられる仕上がりかを確認します。技術的には正しくても、視覚的に凡庸であったり、構成が不十分だったりするページは NEEDS_REVISION です。ゲート 2 では重大な欠陥を確認します。はみ出し、重なり、切り抜け、読みにくいテキスト、要件の欠落、裏付けのない主張、引用の不備、編集可能性、その他の納品リスクを確認します。
11. 各ページを受け入れ条件と照合します。コンタクトシートは概要の確認にのみ使用し、納品デッキの唯一の確認手段にしてはいけません。
12. 要件ごとに根拠を記録し、PASS、NEEDS_REVISION、または BLOCKED を付けます。この照合を、一般的な美的評価に置き換えてはいけません。
13. PNG の確認で重大な問題、または未達成の MUST 条件が見つかった場合は、その原因となっているソースコードまたはコンテンツを特定し、修正、再生成、再確認を行います。問題が生じた判断レベルに戻り、方向性の失敗であれば視覚的な方向性、構成、または素材の戦略を見直し、局所的な欠陥には局所的な編集のみを行います。未解決の MUST 条件がある限り、デッキは完成ではありません。
14. 確認済みの PNG またはコンタクトシートと受け入れ結果を提示し、ユーザーの確認を得てから、PPTX、ソーススクリプト、PDF、PNG プレビューのディレクトリを納品します。

デザインを読み解く：変化、動き、密度

レイアウトを選ぶ前に、3つのダイヤルを1〜10に設定します。

• 変化は、構造の変化度合いを調整します。変化が小さい場合は、一貫したグリッドとコンポーネント群を使用します。中程度の場合は、2〜3種類の手法を組み合わせます。変化が大きい場合は、セクションの区切りや、それぞれ異なるページ構成を取り入れます。
• 動きは、アニメーションの度合いを調整します。動きが小さい場合は、アニメーションを使わないか、フェードにとどめます。中程度の場合は、セクションの切り替えや強調に限ってトランジションを使用します。動きが大きい場合は、納品環境が対応している場合にのみ適しています。
• 密度は、情報量を調整します。密度が低い場合は、ゆとりある余白と主要な要素を1〜2個使用します。中程度の場合は、ストーリーとデータを組み合わせます。密度が高い場合は、ダッシュボード、表、整理されたグリッドを使用します。

これらのダイヤルが変えるのは色だけではなく、構成です。対象者や分野との整合性を保つ必要があります。

3つのモードからなるアーキテクチャ

このスキルには3つの生成モードがあります。VI Buildを汎用的なテンプレートオプションにまとめないでください。

モード	用途	コンテンツ／レイアウトの制御	品質目標
Build Mode	白紙から作る、納品品質のスライドデッキ	正確な要素配置を行うPythonソース	構成を最大限に制御
FreeStyle Mode	迅速な試作、または目標に沿ったコンテンツ作成	generate_ppt(query=...) または generate_ppt(content=...)	迅速で一貫性のあるドラフト
VI Build Mode	既存の企業テンプレートとブランド準拠	テンプレート＋抽出したデザインDNA＋制御された新規ページ	ブランドのフレームワークを維持

Build Mode

投資家向け、取締役会向け、クライアント向け、営業、戦略、編集など、納品品質が求められ、提供されたテンプレートを維持する必要がない作業では、デフォルトで使用します。LLMは、Presentation() と公開されている pptx_designer.tools.* APIを使って、再現可能なPythonスクリプトを作成します。

通常のテーマ適用済みBuild Modeでは、解決済みテーマ全体を Presentation(theme=resolved_theme, strict_theme=True) に渡します。一部のコンテキストのみを渡すのはVI／テンプレート作業に限り、その場合は不足を明示的に診断してください。Theme Lockをテーマとして直接渡さないでください。

FreeStyle Mode

ライブラリが generate_ppt() を通じてスライドデッキを完成させます。トピックのクエリは手軽な方法です。構造化された content 辞書を使うと、ページの目標やコピーをより細かく制御できます。これらは同じFreeStyleモードに対する2つの入力形式であり、別々のレンダリングエンジンではありません。FreeStyleではピクセル単位の配置を制御できず、PNGレビューの工程に代わるものではありません。

方向性が確定したら、generate_ppt(theme=resolved_theme, ...) を呼び出します。style、パレットのアトム、style_seed も一緒に渡さないでください。FreeStyleは指定された解決済みテーマを優先し、これらの探索用引数は無視されたと報告します。

VI Build Mode

ユーザーから template.pptx、企業向けマスター、またはブランド準拠の要件が提示された場合に使用します。ワークフローは次のとおりです。

1. テンプレートを調査し、extract_design_dna() を呼び出します。
2. テンプレートのフレームワークページ、ロゴの扱い、余白、フォント、色、繰り返し使われる装飾を維持します。
3. 抽出したDNAを明示的なブランドトークンに変換します。
4. merge_vi_design_context(template_context, resolved_theme, page_context) を使い、テンプレートのコンテキスト、解決済みテーマ、ページの制約を組み合わせます。テンプレートによって固定されたフィールドは変更せず、競合があれば確認します。
5. テンプレートをベースにし、公開されている pptx_designer ヘルパーを使って新しいコンテンツページを追加します。
6. すべてのページをPNGにレンダリングし、新しいページが同じビジュアルシステムに沿っていることを確認します。

サポートされていないPowerPointのマスター、SmartArt、アニメーション、OOXMLの動作を正確に再現できると約束しないでください。テンプレートを扱う前に references/template-brand.md を読んでください。

比較が必要となるデザイン上の判断がない限り、完全なスライドデッキを複数作成しないでください。提案が有用な場合は、構造が明確に異なる少数の方向性を作成し、ユーザーに選んでもらってから、完全なスライドデッキを作成してください。

デザイン上のガードレール

• ビジュアル表現を選ぶ前に、プレゼンテーションの領域を特定します。
• 汎用的な装飾ではなく、対象者とページの目的に合わせてデザインします。
• デッキ全体をひとつのビジュアルシステムとして扱います。配色、タイポグラフィ、余白、マージン、コンポーネントの表現、画像の扱いを全ページで統一します。
• 控えめな表現、階層、ホワイトスペース、意味のあるビジュアルの変化を優先します。
• 技術的な網羅性よりもビジュアルの品質を優先します。すべてのページに焦点、意図的な構成、完結した要点が必要です。ホワイトスペースは意図的に使い、内容の計画不足の表れにしてはいけません。
• 具体的な主張と実際のデータを使用し、仮定の数値にはその旨を明記します。
• 可能な限り、編集可能なネイティブのテキスト、図形、グラフ、図解を使用します。
• 画像には枠に合わせて配置するヘルパーを使い、決して引き伸ばしません。
• 重要な情報を装飾効果やラスタライズされた画像の中に埋め込まないでください。
• Python の実行、ファイルの存在、図形の数だけを根拠に成功を報告しないでください。

禁止事項

ユーザーが探索的な簡易ドラフトを明示的に依頼し、その制約を了承している場合を除き、以下の行為は禁止されています。

• ページ構成を事前に確立せずに、納品品質のデッキを作成すること。
• 科学、学術、臨床など、汎用的な構成が適切でない領域で、汎用的な導入／問題提起／機能紹介／CTA の流れを使用すること。
• 配色やフォントの変更を、構造の異なる提案として扱うこと。
• ほとんどのページで同じカードグリッドや箇条書きレイアウトを繰り返すこと。
• 内容を編集したり分割したりせず、過剰な内容を収めるために本文の文字を小さくすること。
• 正確な数値、引用、顧客に関する主張、証拠を捏造すること。
• 物語上の理由を明示せずに、デッキの途中でテーマ、タイポグラフィ、色の意味づけを変更すること。
• 画像を引き伸ばすこと、無関係なストック画像を使うこと、編集可能にすべき重要な内容にページ全体のスクリーンショットを使うこと。
• ドキュメント化された pptx_designer ヘルパーがある場合に、Build Mode の実装で slide.shapes.add_shape()、add_textbox()、add_picture() を標準の方法として使うこと。
• 旧式の ppt_pro_max パッケージや、ドキュメント化されていない非公開ヘルパーをインポートすること。
• ソースコードの確認や .pptx の保存成功だけを根拠に、ビジュアル品質を主張すること。
• 大幅な修正後に PNG の確認を省略すること。

次の重大なアンチパターンも引き続き禁止されています。既定の長方形を平坦に積み重ねること、ランダムなグラデーション、引き伸ばした画像、極端に小さい CJK 本文、読みにくいグラフ、繰り返されるカードグリッド、見せかけの精密さ、中身のないマーケティング文言、すべてのページで密度と構成が同じデッキ。

コンテンツからレイアウトへのルール

• 簡潔な箇条書きが5項目までなら1列にできます。6項目以上の場合は、通常、2列、カード、表、または図が必要です。
• 項目が10個以上ある場合は、項目が密集した箇条書きのままにせず、意味のある視覚的な構成に変換してください。
• 技術的なトピックでは、機能カードよりも内容を効果的に伝えられる場合、アーキテクチャ、プロセス、仕様、またはコードのビューを使用してください。
• 教育・研修用のデッキでは、学習目標に必要な場合、演習や実践のステップを含めてください。
• 科学データのページでは、図とキャプション、引用を組み合わせた構成を使用してください。KPI カードやマーケティング向けのヒーロー形式は、通常適切ではありません。
• セクションが切り替わる際は、リズムを整える効果がある場合に視覚的なトランジションを設けてください。装飾だけを理由にセクションページを追加しないでください。
• フックとなるサブタイトルは短く、CTA の文言は行動を促す表現にしてください。ヒーローページに本文の段落を詰め込みすぎないでください。

追加のコンテンツルール：

• 最初の機能を最も目立たせてもかまいませんが、後続の機能は同等に競合させず、視覚的に控えめにしてください。
• トピックが大きく変わり、聴衆が気持ちを切り替えるのに間が役立つ場合は、セクション区切りを使用してください。
• 技術的な信頼性を高めるにはコードやアーキテクチャのビューを、学習目標には演習を、研究上の主張には図のキャプションや引用を使用してください。
• 科学的・学術的なエビデンスでは、KPI カード、ビジネス向けヒーローページ、機能カード形式の表現をデフォルトとして使用しないでください。
• 引用は通常3行以内に収め、氏名、役職、所属組織を含めてください。
• デッキ全体を通して1つのテーマを維持してください。細かな変化は許容されますが、デッキの途中で無関係なテーマに切り替えないでください。

ドメインの検出

視覚的な解決策を決める前に、ドメインを特定してください。典型的な手がかりは次のとおりです。

• 科学研究：遺伝子、タンパク質、シーケンシング、CRISPR、アッセイ、オミクス、経路、変異、発現、実験。
• 学術論文：論文、博士論文、公聴会、口頭試問。
• エンジニアリング／技術：アーキテクチャ、インフラストラクチャ、デプロイ、API、マイクロサービス、システム設計。
• 医療／臨床：診断、治療、患者、手術、臨床。
• 政府／公共部門：政策、規制、コンプライアンス、予算。
• ビジネス／製品：ピッチ、投資家、営業、ローンチ、KPI、収益。

ドメインに応じて構成や視覚的な意味合いが変わる場合は、ビジネス向けデッキを黙ってデフォルトにせず、確認してください。

公開 API のルール

ドキュメント化された公開 pptx_designer インポートのみを使用してください。古い ppt_pro_max パッケージをコピーまたは再現したり、インストール済みパッケージ内に存在するという理由だけでプライベートモジュールをインポートしたりしないでください。Build Mode のコードを書く前に references/public-api.md を読んでください。

PNG の目視レビュー

LLM は、書き出した PNG が魅力的に見えるかどうかだけでなく、元のブリーフと照らし合わせて評価する必要があります。生成前に、ブリーフを簡潔な受け入れ条件にまとめます。レンダリング後は、次の点を評価します。

• すべての MUST 要件が目に見える形で満たされているか。

• 求められた対象者、シナリオ、雰囲気、言語、アクションが各ページに反映されているか。

• 計画したページの目標とストーリーの順序が生成後も保たれているか。

• 指定されたブランド、テンプレート、画像、編集可能性に関する制約が守られているか。

• 参考資料が提供されている場合、表面的なスタイルを模倣するだけでなく、合意した確認可能な特徴が目に見える形で反映されているか。

• SHOULD と NICE_TO_HAVE の条件が満たされているか、または明示的に免除されているか。

• 視覚的な階層とページ単位の明瞭さ。

• プレゼンテーションでの表示サイズでの読みやすさ。

• テキストのはみ出し、重なり、切れ、不自然な余白。

• コンテンツの密度と、埋まった領域と空いた領域のバランス。

• 広い空白領域に明確なストーリー上の目的があるか。余白が焦点、緩急、階層を生み出していない場合、内容が不足したページは NEEDS_REVISION です。

• 各納品ページに十分な視覚的な支点と、完結した要点があるか。「クリーン」や「ミニマル」であることは、根拠の欠如や構成の弱さを正当化しません。

• グラフや図表の判読性。

• 画像のトリミング、関連性、色調の一貫性。

• タイポグラフィ、コントラスト、配色、視覚的な一貫性。

• デッキが指定された対象者、シナリオ、雰囲気に合っているか。

• 結果がテンプレート的ではなく、意図的にデザインされたように見えるか。

• 重要なオブジェクトが PPTX 内で個別に編集可能な状態に保たれているか。

レビューに不合格となった場合は、要件 ID、スライドと位置、原因として考えられるソースコードまたはコンテンツ上の問題、具体的な修正内容を報告します。レビュー記録と受け入れに関する文言については、references/qa-and-delivery.md を参照してください。

参考資料

• workflow.md：ブリーフから確認までの全プロセス。
• design-direction-coach.md：初心者向けのデザイン提案とビジュアル方向性の固定。
• design-principles.md：デザインの考え方とコンテンツルールの詳細。
• domain-paradigms.md：分野固有の構成、ビジュアル言語、アンチパターン。
• public-api.md：厳選された公開 API コントラクト。
• content-schema.md：構造化コンテンツモード。
• template-brand.md：VI Build とテンプレート準拠のワークフロー。
• qa-and-delivery.md：構造チェック、PPTX-PDF-PNG レンダリング、PNG レビュー、納品ゲート。
• scientific-visual-baseline.md： 再利用可能な研究デッキのトークン、エビデンスの段階、ページの類型、密度ルール、基本的な QA 要件。
• install-and-runtime.md：Python とレンダリングの依存関係。