frontend-slides

フロントエンドスライド

ブラウザー内だけで動作する、依存関係ゼロでアニメーション豊富な HTML プレゼンテーションを作成します。

基本原則

1. 依存関係ゼロ — CSS／JS をインラインで記述した単一の HTML ファイルを使います。npm もビルドツールも不要です。
2. 説明より実物を見せる — 抽象的な選択肢ではなく、視覚的なプレビューを生成します。人は目で確かめることで、自分の求めるものを見つけられます。
3. 個性のあるデザイン — ありきたりな「AI っぽい粗雑なデザイン」は避けます。どのプレゼンテーションも、個別に丁寧に作り込まれた印象にします。
4. 段階的な情報開示 — まず軽量なスタイル一覧を読み込みます。大胆なテンプレートの場合は、小さなプレビューカードでスタイルを確認し、ユーザーがテンプレートを選んでから完全版の design.md を読み込みます。
5. 16:9 の固定ステージ（絶対厳守） — すべてのデッキで、1920×1080 のスライドキャンバス全体をビューポートに合わせて拡大縮小します。スマートフォンを含むあらゆる画面で、スライドの比率を 16:9 に保ちます。デバイスに合わせてスライドの内容を組み替えてはいけません。

デザインの美学

ありきたりな「平均的」な出力に収束しがちです。フロントエンドデザインでは、これがユーザーの言う「AI っぽい粗雑なデザイン」につながります。これを避け、創造的で個性のある、驚きと喜びをもたらすフロントエンドを作りましょう。

次の点を重視します。

• タイポグラフィ：美しく、独自性があり、興味を引くフォントを選びます。Arial や Inter のようなありきたりなフォントを避け、フロントエンドの美しさを高める個性的なフォントを選びます。
• 色とテーマ：一貫性のある美学を貫きます。一貫性を保つために CSS 変数を使います。控えめで均等に配色されたパレットより、存在感のある色と鮮やかなアクセントが効果的です。IDE のテーマや文化的な美学から着想を得ます。
• モーション：エフェクトやマイクロインタラクションにアニメーションを使います。HTML では CSS のみのソリューションを優先します。利用できる場合は、React で Motion ライブラリを使います。効果の大きい瞬間に焦点を当てます。段階的な表示（animation-delay）を使って、統一感のあるページ読み込みアニメーションを一度実行するほうが、散発的なマイクロインタラクションよりも大きな喜びを生みます。
• 背景：単色を安易に使うのではなく、雰囲気と奥行きを作ります。CSS グラデーションを重ねたり、幾何学模様を使ったり、全体の美学に合った文脈的なエフェクトを加えたりします。

ありきたりな AI 生成風の美学を避けます。

• 使い古されたフォントファミリー（Inter、Roboto、Arial、システムフォント）
• ありふれた配色（特に白い背景に紫のグラデーション）
• 予想どおりのレイアウトやコンポーネントパターン
• 文脈に応じた特徴のない、型にはまったデザイン

創造的に解釈し、文脈に合った、本当にデザインされたと感じられる意外性のある選択をしましょう。ライトテーマとダークテーマ、異なるフォントや美学を使い分けます。それでも、世代をまたいで Space Grotesk などのよくある選択肢に収束しがちです。これを避け、常識にとらわれずに考えることが何より重要です。

固定ステージのルール

次の不変条件は、すべてのプレゼンテーションのすべてのスライドに適用されます。

• すべてのデッキに、ブラウザーウィンドウ全体を埋めるビューポート用ラッパーを設けます。
• すべてのスライドを、固定サイズの 1920×1080 ステージ内に作成します。
• ステージはビューポートに収まるよう均等に拡大縮小します。レターボックスまたはピラーボックスが生じてもかまいませんが、コンテンツのレイアウトを変更してはいけません。
• スマートフォン向けにスライドの内容を並べ替えるレスポンシブブレークポイントは使いません。
• 1920×1080 のデザインサイズを基準に、スライド内の寸法を固定します。
• スライドの表示状態は、viewport-base.css の visibility、opacity、pointer-events を使い、.active／.visible で制御します。スライドの切り替えに display: none／display: block を使ってはいけません。.slide-content { display: flex; } のような後続のレイアウトクラスによって表示状態が上書きされ、すべてのスライドが一度に表示されることがあります。
• clamp() は、ステージ外のスライド以外の UI、または完全なステージを表示するのが現実的でない小さなフォールバックプレビューにのみ使います。
• prefers-reduced-motion に対応します。
• CSS 関数を直接否定してはいけません（-clamp()、-min()、-max() は無視されます）。代わりに calc(-1 * clamp(...)) を使います。

生成時には viewport-base.css を読み込み、その内容全体を各プレゼンテーションに含めてください。

コンテンツの密度モード

主に閲覧するスライドデッキか、発表するスライドデッキかをユーザーに尋ね、その回答に合わせて設計します。

密度モード	最適な用途	デザインの方針
低密度／発表者主導	公開講演、基調講演形式の共有、ライブでの説明	1 枚につき 1 つのアイデア、大きな文字、明確な視覚的階層、十分な余白、箇条書きは最大 1～3 項目、必要に応じてスライドを増やす
高密度／閲覧優先	レポート、配布資料、非同期レビュー、詳細な社内文書	1 枚で内容が完結するスライドを増やし、構造化されたグリッド／表／注釈を活用し、読みやすさを保ちながら箇条書きは 4～8 項目、またはカードは 4～6 枚にし、間隔は詰めつつも意図的に調整する

基本の制限は引き続き適用されます。スクロール、はみ出し、パネルの重なり、快適に読めるサイズを下回る文字は許容されません。コンテンツが選択した密度モードに収まらない場合は、窮屈になるまで文字を小さくするのではなく、スライドを分割してください。

---

フェーズ 0：モードの判定

ユーザーの要望を判定します。

• モード A：新規プレゼンテーション — ゼロから作成します。フェーズ 1 に進みます。
• モード B：PPT の変換 — .pptx ファイルを変換します。フェーズ 4 に進みます。
• モード C：改善 — 既存の HTML プレゼンテーションを改善します。内容を読み、理解したうえで強化します。以下のモード C の変更ルールに従ってください。

モード C：変更ルール

既存のプレゼンテーションを改善する場合、固定サイズのスライドに内容を収めることが最大のリスクです。

1. コンテンツを追加する前に： 既存の要素を数え、密度の上限を確認します
2. 画像を追加する場合： 画像を 1920×1080 のスライドキャンバス内に収めます。すでにスライドのコンテンツが上限に達している場合は、2 枚に分割します
3. テキストを追加する場合： 1 枚あたりの箇条書きは最大 4～6 項目です。上限を超える場合は、続きのスライドに分割します
4. 変更を加えるたびに、必ず確認します： スライドのステージが 16:9 のままであること、テキストがカードからはみ出していないこと、パネルが重なっていないこと、1280×720 およびスマートフォンのビューポートでスクリーンショットが正しく表示されること
5. 事前に構成を見直します： 変更によってはみ出しが発生する場合は、コンテンツを自動的に分割し、ユーザーに伝えます。依頼されるまで待ってはいけません

既存のスライドに画像を追加する場合： 画像を新しいスライドに移すか、先に他のコンテンツを減らします。既存のコンテンツが 1920×1080 のスライドステージをすでに埋めていないか確認せずに、画像を追加してはいけません。

---

フェーズ 1：コンテンツの確認（新規プレゼンテーション）

ユーザーが一度にすべて回答できるよう、質問はすべてまとめて尋ねます。現在の環境にネイティブの構造化質問 UI がある場合はそれを使用し、ない場合は番号付きの選択肢を明確に示した簡潔なメッセージで一度に尋ねます。

質問 1 — 目的（ヘッダー：「目的」）： このプレゼンテーションの用途は何ですか？選択肢：ピッチデッキ／教育・チュートリアル／カンファレンストーク／社内プレゼンテーション

質問 2 — 長さ（ヘッダー：「長さ」）： スライドはおよそ何枚ですか？選択肢：短め 5～10 枚／中程度 10～20 枚／長め 20 枚以上

質問 3 — コンテンツ（ヘッダー：「コンテンツ」）： コンテンツはすでに用意されていますか？選択肢：すべて用意済み／大まかなメモがある／トピックのみ

質問 4 — 密度（ヘッダー：「密度」）： スライドデッキの密度はどの程度にしますか？選択肢：

• 「低密度／発表者主導」— 大きなアイデア、少ない文字、視覚的な余白を多く取る
• 「高密度／閲覧優先」— 非同期での閲覧に適した、より完結した詳細を載せる

フェーズ 1 では、インライン編集について尋ねないでください。 ユーザーはドラフトを見る前に、編集方法を選ぶ必要はありません。インライン編集はドラフト作成後に利用できる機能です。ユーザーがロック済み／エクスポート専用のファイルを明示的に希望しない限り、デフォルトで含めてください。

ユーザーが選んだ密度を記憶してください。これはスライドの枚数、文字の大きさ、1 枚あたりのテキスト量、レイアウトの密度、シネマティックな発表者向けスライドと、内容が完結した閲覧向けスライドのどちらを優先するかに影響します。

ユーザーにコンテンツがある場合は、共有するよう依頼してください。

Step 1.2: 画像の評価（画像が提供された場合）

ユーザーが「画像なし」を選択した場合 → Phase 2 に進みます。

ユーザーが画像フォルダーを提供した場合：

1. スキャン — すべての画像ファイル（.png、.jpg、.svg、.webp など）を一覧表示します
2. 各画像を確認 — エージェントが利用できる画像理解機能を使用します。画像を読み取れない場合は、ファイル名やメタデータを使い、必要な場合にのみユーザーに詳細を尋ねます
3. 評価 — 画像ごとに、何が写っているか、使用可能か使用不可か（理由も記載）、どのようなコンセプトを表しているか、主な色を評価します
4. アウトラインを共同で作成 — 厳選した画像を、テキストとあわせてスライド構成に反映します。「先にスライドを計画してから画像を追加する」のではなく、最初から両方を考慮して設計します（例：スクリーンショットが3枚なら機能紹介スライドを3枚、ロゴが1つならタイトルスライドまたはクロージングスライドに使用）
5. アウトラインを確認 — 利用可能な場合は、同じ構造化された質問方法を使います：「このスライドのアウトラインと画像の選択でよろしいですか？」 選択肢：問題ありません / 画像を調整 / アウトラインを調整

プレビューでのロゴの使用： 使用可能なロゴが特定できた場合、Phase 2 の各スタイルプレビューに埋め込み（base64）、ユーザーが自社ブランドを3種類のスタイルで確認できるようにします。

---

Phase 2: スタイルの選定

ここでは「説明するより、見せる」ことを重視します。 デザインの好みを言葉で表現するのは難しいものです。

Step 2.0: スタイルのプレビューを3種類、直接生成する

目的、対象者、雰囲気、コンテンツの密度に基づいて、タイポグラフィ、色、アニメーション、全体的な美しさを示す、1枚構成のHTMLプレビューを3種類生成します。

オプションやプリセット選択画面を希望するかどうか、ユーザーに尋ねないでください。通常の選定方法は、常に視覚的な比較です。

ユーザーがすでに雰囲気を伝えている場合は、それを反映してください。伝えていない場合は、用途、対象者、コンテンツ、重要度から、適切な雰囲気を推測してください。最初から好みを言葉にしてもらわなくても、視覚的に反応できるよう、十分に異なる選択肢を用意してください。

ユーザーがプリセットや大胆なテンプレートを明示的に指定した場合は、それを選択肢の1つに採用し、残りのプレビュー枠を使って他の案を生成してください。

安全なプリセット候補については、STYLE_PRESETS.mdを確認してください。bold-template-pack/selection-index.jsonが存在する場合は、その簡潔なインデックスも読み込みます。ただし、この時点ではdesign.mdファイルを読み込まないでください。

雰囲気	推奨プリセット
感銘を受けた／自信に満ちた	Bold Signal, Electric Studio, Dark Botanical
興奮／活気に満ちた	Creative Voltage, Neon Cyber, Split Pastel
落ち着いた／集中している	Notebook Tabs, Paper & Ink, Swiss Modern
心を動かされた／感動した	Dark Botanical, Vintage Editorial, Pastel Geometry

プレビューの組み合わせルール：

• デフォルトでは、プレビューを3種類生成します。STYLE_PRESETS.mdの安全なプリセットを1つ、bold-template-pack/selection-index.jsonの大胆なテンプレートを少なくとも1つ、そしてワイルドカードを1つ選びます。
• ワイルドカードには、2つ目の大胆なテンプレートか、独自にデザインしたカスタム案を使用できます。用途、対象者、雰囲気、コンテンツを踏まえて、最も強い対比を生み、役に立つ方を選んでください。
• 表現豊かな選択肢をすべてテンプレートライブラリから選ぶ必要はありません。要件に、利用可能なテンプレートよりも明確で具体的なデザインの可能性がある場合は、ワイルドカード枠で自由にデザインしてください。
• 保守的な資料や重要度の高い資料では、安全なプリセットを特に控えめなものにします。落ち着きがあり、フォーマルさの高い大胆なテンプレートを選び、ワイルドカードには、権威ある印象を与える別の控えめなテンプレートかカスタムデザインを使用します。装飾的なデザインは避けてください。
• 表現豊かな資料では、安全なプリセットを読みやすい予備案として残します。印象的な大胆なテンプレートを1つ選び、ワイルドカードには冒険的で、文脈に合わせた、他の2つとは明確に異なる案を使用します。
• 大胆なテンプレートがあまり合わない場合は、無理に選ばず、ワイルドカードにカスタムデザインを使用するか、別の安全なプリセットを選んでください。

カスタムのワイルドカードデザインのルール：

• 上記の「デザインの美学」セクションに従ってください。ありきたりな「AI スロップ」は避け、デフォルトのフォント・色・レイアウトも使わないでください。白地に紫のグラデーションを重ねるような使い古された表現や、型にはまったダッシュボード／カードの見た目も避けてください。
• ユーザーが示した用途、対象者、雰囲気、コンテンツの密度に合わせてください。カスタムデザインは、単に「スタイリッシュ」なだけでなく、このスライドデッキのために作り込まれたものに感じられる必要があります。
• 意図の明確なビジュアルコンセプトを打ち出してください。特徴的なタイポグラフィ、統一感のあるカラーパレット、認識しやすいレイアウトシステム、そして印象に残る雰囲気づくりやグラフィック表現をひとつ採用してください。
• デッキ全体に展開できるよう、実現可能なデザインにしてください。プレビューから、セクション、コンテンツ、引用、比較、締めくくりのスライドへ展開可能なデザインシステムが感じられる必要があります。
• 固定の 1920×1080 ステージ規則を使用し、他のすべての候補と同じプレビューの真正性チェックに合格してください。
• スライド自体に「カスタム」、「ワイルドカード」、「AI 生成」、「デザインプロセス」を示すラベルを表示しないでください。

大胆なテンプレート選択ルール：

• ユーザーの目的と雰囲気を、mood、tone、best_for、avoid_for、formality、density、scheme に照らして選んでください。
• best_for の例は参考情報として扱い、業界を厳密に絞り込む条件とはみなさないでください。
• 3 つのプレビューは、それぞれ明確に異なるものにしてください。
• 大胆なテンプレート候補を選んだ後は、選択インデックスに記載された preview_md パスから、該当候補の preview.md ファイルだけを読み込んでください。
• preview.md はタイトルスライドのプレビューにのみ使用してください。ユーザーが最終テンプレートを選ぶまでは、完全版の design.md ファイルを読み込まないでください。
• 選択した最終版の design.md に不可欠な実装の詳細が不足している場合を除き、template.html を読み込んだり、コピーしたりしないでください。

プレビューの真正性に関するルール（必須）：

• すべてのスタイルプレビューを、診断用カードではなく、ユーザーのデッキに実際に含まれる最初のスライドのように見せてください。
• スライド上に内部ワークフローのテキストを表示しないでください。「プレビュー」、「生成元」、「preview.md」、「テンプレート」、「プリセット」、「スタイルオプション」、「オプション A/B/C」、ファイル名、パス、元文書を示すラベルなどは禁止です。
• スライド自体にテンプレート名やスラッグ名を表示しないでください。テンプレート名／スタイル名を伝えるのはユーザーへのメッセージ内に限ります。
• 「鋭く挑発的」、「無難な選択肢」、「大胆な選択肢」、「社内共有用」、「対象者：...」など、ユーザーの要件に関するメモをスライドの内容として表示しないでください。ただし、ユーザーがその文言をデッキにそのまま表示するよう明示的に求めた場合は除きます。
• スライドにクロームが必要な場合は、デッキタイトル、セクションタイトル、日付、著者名、会社名、ページ番号、またはユーザーの資料に実際に含まれる表現のみを使用してください。
• プレビューを開く前に、表示されるテキストを確認し、内部メタデータが含まれていれば修正してください。

プレビューは .frontend-slides/slide-previews/ に保存してください（style-a.html、style-b.html、style-c.html）。それぞれ自己完結型かつコンパクトな、アニメーション付きタイトルスライドを 1 枚表示してください。

各プレビューを自動的に開いて、ユーザーに表示してください。

ステップ 2.1：ユーザーが選択

質問（ヘッダー：「スタイル」）： どのスタイルプレビューがお好みですか？選択肢：スタイル A：[名前] ／ スタイル B：[名前] ／ スタイル C：[名前] ／ 要素を組み合わせる

「要素を組み合わせる」を選んだ場合は、具体的にどの要素を組み合わせるか尋ねてください。

---

フェーズ 3：プレゼンテーションを生成する

フェーズ 1 のコンテンツ（テキスト、またはテキストと厳選した画像）とフェーズ 2 のスタイルを使って、プレゼンテーション全体を生成します。

画像が提供されている場合、スライドのアウトラインにはすでにステップ 1.2 の画像が組み込まれています。画像がない場合は、CSS で生成するビジュアル（グラデーション、図形、パターン）で視覚的な魅力を加えます。これは正式にサポートされている第一級の方法です。

ユーザーが選んだ情報量を、デッキ全体に適用してください。

• 情報量少なめ／プレゼンター主導： 1 枚あたりのアイデアを絞り、スライド数を増やします。大きな見出し、短いフレーズ、視覚的な比喩、セクションの区切り、引用やメッセージを伝えるスライド、プレゼンターにとって扱いやすい進行を優先します。
• 情報量多め／読み物優先： スライドだけで内容が伝わるようにします。構成されたグリッド、比較表、注釈付き図解、キャプション、簡潔な説明文を活用します。文書をそのままスライドに貼り付けたように見えないよう、明確な階層を保ちます。

ユーザーのニーズが混在している場合は、中間案を作るのではなく、どちらか近いモードを選びます。ライブでの聴衆への訴求を目的とする場合は情報量少なめ、非同期での共有や詳細なレビューを目的とする場合は情報量多めをデフォルトとします。

情報量を増やす場合も、視覚的に煩雑にならないようにします。情報量の多いスライドがあふれそうな場合は、分割するか、より明確な構成に再設計します。

ユーザーが bold-template-pack のテンプレートを選んだ場合は、生成前にそのテンプレートの design.md 全体を読みます。他の太字テンプレートは読みません。design.md をデザインのレシピとして扱います。

• フォント、パレット、装飾の語彙、余白のリズム、コンポーネントの文法を維持します。
• 最終的なデッキは、ソーステンプレートがもともと deck-stage.js を使用していたか、ビューポートに応じて流動的に変化する CSS を使用していたかにかかわらず、ビューポートに合わせて均一に拡大縮小する固定サイズ 1920×1080 のステージとして生成します。
• design.md にあるビューポートに応じて変化する値は、1920×1080 のステージ座標に変換するデザイン比率として扱います。最終的なデッキでは、ビューポートに応じて再配置するルールとして残さないでください。
• 出力は、自己完結型の単一の Frontend Slides HTML ファイルにします。
• デモ用スライドの内容をコピーしたり、ソーステンプレートに忠実すぎる形で模倣したりしないでください。
• 選択したテンプレートの実装を参照する必要がある場合に限り、最後の手段として template.html を使用します。
• 生成後、レンダリングしたブラウザーのスクリーンショットで、コンテンツのはみ出しとパネルの重なりの両方を確認します。scrollHeight のチェックだけでは不十分です。グリッドのパネル同士が視覚的に重なって隠れる場合があるためです。

ユーザーが自己生成したカスタムワイルドカードを選んだ場合は、そのプレビューの CSS とレイアウトをデザインのレシピとして扱います。

• フォント、パレット、装飾の語彙、余白のリズム、グリッドのロジック、コンポーネントの文法を維持します。
• 同じビジュアルシステムをデッキ全体に展開します。ユーザーがカスタムの方向性を選んだ後に、プリセットや太字テンプレートへ切り替えないでください。
• スライドのレイアウトが不足している場合は、別のスタイルからパターンを取り込まず、同じシステムに基づいてデザインします。
• 他のすべてのデッキと同様に、固定ステージ、単一ファイルとし、見た目を検証します。

生成する前に、以下の補助ファイルを読んでください。

• html-template.md — HTML のアーキテクチャと JS の機能
• viewport-base.css — 必須の CSS（全内容を含める）
• animation-patterns.md — 選択した雰囲気に合わせたアニメーションのリファレンス

主な要件：

• 自己完結型の単一 HTML ファイルとし、すべての CSS／JS をインラインにする
• <style> ブロックに viewport-base.css の全内容を含める
• Fontshare または Google Fonts のフォントを使用し、システムフォントは使用しない
• 各セクションを説明する詳しいコメントを追加する
• 各セクションに、明確な /* === SECTION NAME === */ コメントブロックを付ける

フェーズ 4：PPT への変換

PowerPoint ファイルを変換する場合：

1. コンテンツを抽出する — python scripts/extract-pptx.py <input.pptx> <output_dir> を実行します（必要に応じて python-pptx をインストールします：pip install python-pptx）
2. ユーザーに確認する — 抽出したスライドのタイトル、コンテンツの概要、画像の数を提示します
3. スタイルを選択する — スタイルの調査を行うため、フェーズ 2 に進みます
4. HTML を生成する — すべてのテキスト、画像（assets/ 内のもの）、スライドの順序、発表者ノート（HTML コメントとして）を保持し、選択したスタイルに変換します

---

フェーズ 5：納品

1. クリーンアップする — .frontend-slides/slide-previews/ が存在する場合は削除します
2. 開く — open [filename].html を使ってブラウザーで開きます
3. 概要を伝える — ユーザーに次の内容を伝えます：
   • ファイルの場所、スタイル名、スライド数
   • ナビゲーション：矢印キー、Space、有効になっている場合はスワイプ／タップ
   • カスタマイズ方法：色には :root の CSS 変数、タイポグラフィにはフォントリンク、アニメーションには .reveal クラスを使用します
   • テキストを直接編集できます：左上隅にカーソルを合わせるか E キーを押して編集モードに入り、テキストをクリックして編集し、Ctrl+S で保存します
   • 下書き後に自然に行える操作として、修正の依頼、ブラウザーでのテキストの直接編集、エクスポート／共有を提案します

---

フェーズ 6：共有とエクスポート（任意）

納品後、ユーザーに次のように尋ねます： 「このプレゼンテーションを共有しますか？あらゆるデバイス（スマートフォンを含む）で使えるライブ URL にデプロイするか、PDF としてエクスポートできます。」

選択肢：

• URL にデプロイ — あらゆるデバイスで使える共有リンク
• PDF にエクスポート — メール、Slack、印刷に使える汎用ファイル
• 両方
• いいえ

ユーザーが断った場合は、ここで終了します。どちらか、または両方を選んだ場合は、以下に進みます。

6A: ライブ URL にデプロイする（Vercel）

プレゼンテーションを無料のホスティングプラットフォームである Vercel にデプロイします。リンクはスマートフォン、タブレット、ノート PC など、どのデバイスでも開けます。また、ユーザーが削除するまで公開されます。

ユーザーがデプロイしたことがない場合は、手順を追って案内してください：

1. Vercel CLI がインストールされているか確認する — npx vercel --version を実行します。見つからない場合は、先に Node.js をインストールします（macOS では brew install node を実行するか、https://nodejs.org からダウンロードします）。

2. ユーザーがログインしているか確認する — npx vercel whoami を実行します。

   • ログインしていない場合は、次のように説明します： "Vercel は無料のホスティングサービスです。デプロイするにはアカウントが必要です。手順をご案内します："
     • 手順 1：ブラウザーで https://vercel.com/signup にアクセスするようユーザーに依頼します
     • 手順 2：GitHub、Google、メールアドレスなど、最も簡単な方法で登録できます
     • 手順 3：登録後、vercel login を実行して画面の指示に従います（認証のためにブラウザーウィンドウが開きます）
     • 手順 4：vercel whoami でログインを確認します
   • 続行する前に、ログインできたことをユーザーに確認してください。

3. デプロイする — デプロイスクリプトを実行します：

   bash scripts/deploy.sh <path-to-presentation>
   

   このスクリプトは、フォルダー（index.html を含む）または単一の HTML ファイルを受け付けます。

4. URL を共有する — ユーザーに次のことを伝えます：

   • ライブ URL（スクリプトの出力に表示されます）
   • どのデバイスでも開けること。テキストメッセージ、Slack、メールで共有できます
   • 後で公開を終了するには、https://vercel.com/dashboard にアクセスしてプロジェクトを削除すること
   • Vercel の無料プランは十分な内容があり、料金は発生しないこと

⚠ デプロイ時の注意点：

• ローカルの画像や動画は HTML と一緒にアップロードする必要があります。 デプロイスクリプトは HTML 内の src="..." で参照されているファイルを自動検出してまとめます。ただし、プレゼンテーションが CSS の background-image や一般的でないパスでファイルを参照している場合、検出されないことがあります。デプロイ前に確認してください： デプロイした URL を開き、すべての画像が読み込まれることを確認します。画像が表示されない場合は、HTML とすべてのアセットを 1 つのフォルダーにまとめ、単独の HTML ファイルではなくフォルダーをデプロイするのが最も確実な解決策です。
• アセットが多いプレゼンテーションでは、フォルダーでのデプロイを優先してください。 画像が同じフォルダー内にある場合（例：my-deck/index.html と my-deck/logo.png）、フォルダーを直接デプロイします：bash scripts/deploy.sh ./my-deck/。フォルダー全体の内容がそのままアップロードされるため、単一の HTML ファイルをデプロイするより確実です。
• ファイル名にスペースが含まれていても動作しますが、問題が起きることがあります。 スクリプトはファイル名のスペースを処理しますが、Vercel の URL ではスペースが %20 にエンコードされます。可能であれば、画像ファイル名にスペースを使わないでください。ユーザーの画像ファイル名にスペースが含まれている場合も、スクリプトで処理できます。それでも画像が表示されない場合は、ファイル名のスペースをハイフンに置き換えると解決できます。
• 再デプロイすると、同じ URL が更新されます。 同じプレゼンテーションでデプロイスクリプトを再実行すると、以前のデプロイが上書きされます。URL は変わらないため、新しいリンクを共有する必要はありません。

6B: PDF へのエクスポート

各スライドをスクリーンショットとしてキャプチャし、それらをまとめて PDF にします。メールへの添付、ドキュメントへの埋め込み、印刷に最適です。

注意： アニメーションやインタラクティブ機能は保持されず、PDF は静的なスナップショットになります。これは正常な動作です。ユーザーが驚かないよう、その旨を伝えてください。

1. エクスポートスクリプトを実行します：

   bash scripts/export-pdf.sh <path-to-html> [output.pdf]
   

   出力先を指定しない場合、PDF は HTML ファイルと同じ場所に保存されます。

2. 内部で行われる処理（ユーザーに簡潔に説明してください）：

   • ヘッドレスブラウザーがプレゼンテーションを 1920×1080（標準的なワイドスクリーン）で開きます
   • 各スライドを順番にスクリーンショットとして撮影します
   • すべてのスクリーンショットを 1 つの PDF にまとめます
   • スクリプトには Playwright（ブラウザー自動化ツール）が必要です。見つからない場合は自動的にインストールされます

3. Playwright のインストールに失敗した場合：

   • 最もよくある原因は、Chromium をダウンロードできないことです。次を実行してください：npx playwright install chromium
   • それでも失敗する場合は、ネットワークまたはファイアウォールの問題が考えられます。別のネットワークで試すようユーザーに依頼してください。

4. PDF を渡します — スクリプトが自動的に開きます。次の内容をユーザーに伝えてください：

   • ファイルの場所とサイズ
   • メール、Slack、Notion、Google Docs、印刷など、どこでも使えること
   • アニメーションは最終的な表示状態に置き換わること（静止画になりますが、見栄えは良好です）

⚠ PDF エクスポート時の注意点：

• 初回の実行には時間がかかります。 スクリプトは Playwright をインストールし、一時ディレクトリに Chromium ブラウザー（約 150MB）をダウンロードします。これは実行ごとに 1 回行われます。初回は 30～60 秒かかる場合があります。ユーザーにその旨を伝えてください。同じセッション内での以降のエクスポートはより速くなります。
• スライドには class="slide" を使用する必要があります。 エクスポートスクリプトは .slide 要素を検索してスライドを見つけます。プレゼンテーションで別のクラス名を使用している場合、スクリプトは「0 slides found」と報告して失敗します。このスキルで生成されるプレゼンテーションはすべて .slide を使用するため、これは外部で作成された HTML の場合にのみ問題となります。
• ローカル画像は HTTP 経由で読み込める必要があります。 スクリプトはローカルサーバーを起動し、そこを通じて HTML を読み込みます（Google Fonts と相対画像パスを使用できるようにするためです）。画像で相対パス（例：src="photo.png"）ではなく、絶対ファイルシステムパス（例：src="/Users/name/photo.png"）を使用している場合、画像は読み込まれません。生成されるプレゼンテーションでは常に相対パスを使用しますが、変換されたデッキやユーザー提供のデッキではそうでない可能性があるため、必要に応じて確認して修正してください。
• ローカル画像は、HTML ファイルと同じディレクトリ内、または HTML ファイルからの相対パス上にある限り PDF に表示されます。 エクスポートスクリプトは HTML の親ディレクトリを HTTP 経由で配信するため、src="photo.png" のような相対パスは、ファイル名に空白が含まれていても正しく解決されます。それでも画像が表示されない場合は、次の点を確認してください：（1）画像ファイルが参照先のパスに実際に存在すること、（2）/Users/name/photo.png のような絶対ファイルシステムパスではなく、相対パスを使っていること。
• プレゼンテーションの規模が大きいと、PDF ファイルも大きくなります。 各スライドは 1920×1080 の PNG スクリーンショットとしてキャプチャされます。18 枚のスライドで約 20MB の PDF が生成される場合があります。PDF が 10MB を超える場合は、ユーザーに次のように尋ねてください："PDF のサイズは [size] です。圧縮しましょうか？少し鮮明さは失われますが、ファイルサイズは大幅に小さくなります。" 希望する場合は、--compact フラグを付けてエクスポートを再実行してください：

  bash scripts/export-pdf.sh <path-to-html> [output.pdf] --compact
  

  これは 1920×1080 ではなく 1280×720 でレンダリングします。通常、見た目への影響を最小限に抑えながら、ファイルサイズを 50～70％削減できます。

---

参考ファイル

ファイル	目的	読むタイミング
STYLE_PRESETS.md	色、フォント、特徴的な要素を含む、厳選された12種類のビジュアルプリセット	フェーズ2（スタイルの選択）
bold-template-pack/selection-index.json	候補選定用のコンパクトなボールドテンプレートのメタデータ	フェーズ2（スタイルの選択）
bold-template-pack/templates/*/preview.md	候補を絞り込んだボールドタイトルのプレビュー用の軽量なスタイルカード	候補を絞り込んだ後のフェーズ2
bold-template-pack/templates/*/design.md	選択されたボールドテンプレートのみを対象とした、詳細なデザインシステムのドキュメント	ユーザー選択後のフェーズ3
viewport-base.css	必須の固定ステージCSS — すべてのプレゼンテーションにコピーします	フェーズ3（生成）
html-template.md	HTML構造、JS機能、コード品質基準	フェーズ3（生成）
animation-patterns.md	CSS/JSアニメーションのスニペットと、効果と印象のガイド	フェーズ3（生成）
scripts/extract-pptx.py	PPTコンテンツ抽出用のPythonスクリプト	フェーズ4（変換）
scripts/deploy.sh	スライドをVercelにデプロイしてすぐに共有	フェーズ6（共有）
scripts/export-pdf.sh	スライドをPDFにエクスポート	フェーズ6（共有）