presentation-creation

プレゼンテーションの作成

このスキルを使うと、AI エージェントがアウトライン、ドキュメント、会議メモ、データなどの未加工のコンテンツを、プロフェッショナルなプレゼンテーション用スライドデッキに変換できます。エージェントは、1 枚のスライドにつき 1 つのアイデア、視覚的な階層、テキストの最小化といったスライドデザインの原則を適用し、明快で魅力的な、すぐにプレゼンテーションに使えるデッキを作成します。Marp Markdown、reveal.js HTML、Google Slides、PPTX など、複数の出力形式に対応しています。

ワークフロー

1. コンテンツを集め、対象者を定義します。 アウトライン、技術ドキュメント、会議メモ、要点の一覧など、ソース資料を集めます。対象者（経営幹部、エンジニア、顧客、投資家）とプレゼンテーションの目的（情報提供、説得、トレーニング、ピッチ）を特定します。対象者に応じて、語彙の専門性、詳細度、ビジュアルスタイルを決めます。投資家向けのピッチでは大胆な主張や数値を使い、技術的な詳細解説ではアーキテクチャ図やコードスニペットを使います。

2. ストーリーの流れを組み立てます。 導入のつかみ、問題提起、解決策または重要なメッセージ、裏付けとなる証拠、最後の行動喚起という論理的な流れに沿って、コンテンツを整理します。この流れをスライドごとのアウトラインに落とし込みます。一般的な 15 分のプレゼンテーションでは、10～15 枚のスライドを使います。各スライドで伝えるアイデアは 1 つにします。見出しが 2 つ必要なら、スライドを 2 枚に分けます。セクションの間に転換点を加え、ストーリーの流れを保ちます。

3. テキストを最小限にしてスライドの内容を書きます。 各スライドには、トピックではなく要点を示す、簡潔な見出し（8 語未満）を付けます。「売上概要」ではなく「売上が前年比 40% 増加」のようにします。本文は 3～5 個の箇条書き、または短い段落 1 つにまとめます。可能であれば、テキストを図表、ダイアグラム、スクリーンショット、画像などに置き換えて、要点がより早く伝わるようにします。各スライドには、発表者が口頭で伝える詳細な要点をスピーカーノートとして記載します。

4. ビジュアル要素とレイアウトを提案します。 各スライドに適したビジュアル表現を提案します。比較には棒グラフ、傾向には折れ線グラフ、プロセスにはフローダイアグラム、製品デモにはスクリーンショット、機能一覧にはアイコングリッド、感情に訴える場合には全面画像を使います。レイアウトは、タイトルのみ、タイトルと本文、2 列、左側に画像、全面画像などから指定します。統一感のあるカラーパレットとフォントの組み合わせ（例：見出しには Inter、本文には Source Sans）も提案します。

5. 指定された形式でスライドデッキを生成します。 要求された形式でデッキ全体を作成します。Marp の場合は、--- のスライド区切りと Marp ディレクティブを含む単一の Markdown ファイルを出力します。reveal.js の場合は、section タグを含む HTML ファイルを出力します。PPTX の場合は、python-pptx スクリプトまたはファイルそのものを生成します。Google Slides の場合は、Slides API と互換性のある構造化 JSON ペイロードを出力します。スピーカーノート、スライド番号、埋め込みメディアの参照も含めます。

6. 確認して仕上げます。 プレゼンテーションのベストプラクティスに照らして、デッキを確認します。本文が 40 語を超えるスライドがないこと、すべてのスライドに要点が明確な見出しがあること、ビジュアルに変化を付けて単調さを防いでいること（箇条書きのスライドばかりになっていないこと）、冒頭のスライドが関心を引くこと、最後のスライドに明確な次のステップが示されていることを確認します。デッキが長すぎる場合は、統合できるスライドや付録に移せるスライドを特定し、進行を調整します。

使用方法

ソースコンテンツ（またはトピックの説明）、対象者、希望するスライド枚数、出力形式をエージェントに提供します。エージェントは、スピーカーノート付きのスライドデッキ全体を返します。

プロンプト形式：

Create a presentation about [topic].
Source material: [outline, document path, or key points]
Audience: [who will see this]
Slide count: [target number of slides]
Output format: [marp / revealjs / pptx / google-slides]

例

例 1：製品ローンチ用スライドデッキ（Marp 形式）

入力：

Create a presentation for the launch of "Nimbus," a cloud cost optimization tool.
Audience: Engineering managers and VPs at mid-size SaaS companies.
Slide count: 7
Output format: marp

出力：

---
marp: true
theme: default
paginate: true
---

# Nimbus
## Cut your cloud bill by 35% — automatically

![bg right:40%](cloud-hero.png)



---

# The Problem: Cloud Spend Is Out of Control

- 73% of engineering leaders say cloud costs exceeded budget last quarter
- Idle resources, oversized instances, and forgotten dev environments
- Manual cost reviews happen quarterly at best — waste compounds daily



---

# How Nimbus Works

1. **Connect** — Link your AWS, GCP, or Azure accounts in under 5 minutes
2. **Analyze** — Nimbus scans utilization, traffic patterns, and billing data
3. **Optimize** — Get prioritized recommendations ranked by savings impact
4. **Automate** — Enable auto-scaling rules and scheduled shutdowns



---

# Results: What Our Beta Customers Achieved

| Company       | Monthly Savings  | Time to ROI |
|---------------|-----------------|-------------|
| Acme Corp     | $42,000 (31%)   | 2 weeks     |
| DataFlow Inc  | $67,000 (38%)   | 3 days      |
| Bright SaaS   | $28,000 (29%)   | 1 week      |

Average: **35% cost reduction** within the first month.



---

# Built for Engineering Teams, Not Finance

- No code changes required — works at the infrastructure layer
- Slack and PagerDuty integration for real-time alerts
- Granular controls per team, environment, or service
- Full audit log — every optimization is logged and reversible



---

# Pricing

- **Starter:** Free for accounts under $10K/month cloud spend
- **Pro:** 5% of realized savings (you only pay when you save)
- **Enterprise:** Custom pricing with dedicated support and SLAs

No upfront commitment. Cancel anytime.



---

# Get Started Today

**Start your free trial at nimbus.io/start**

- 5-minute setup, no credit card required
- See your first savings recommendations within 24 hours
- Questions? Email [email protected]

例 2：技術ドキュメントをプレゼンテーションのアウトラインに変換

入力：

Convert the following technical document summary into a presentation outline.
Source: "Our API gateway handles 2.3M requests/day. Current P99 latency is
450ms, target is under 200ms. Root cause: synchronous auth middleware. Proposed
fix: move auth to async verification with JWT caching. Expected impact: 60%
latency reduction. Rollout plan: canary 5% then 25% then 100% over 3 weeks."
Audience: Backend engineering team
Output format: outline

出力：

Slide 1: Title
  Headline: "Cutting API Gateway Latency by 60%"
  Subtitle: Backend Architecture Proposal — February 2026
  Visual: None (clean title slide)

Slide 2: Current State
  Headline: "Our P99 Latency Is 2x Over Target"
  Bullets:
    - 2.3M requests/day through the API gateway
    - Current P99: 450ms | Target: under 200ms
    - Latency spikes correlate with auth middleware execution
  Visual: Line chart showing P99 latency over past 30 days with 200ms target

Slide 3: Root Cause
  Headline: "Synchronous Auth Is the Bottleneck"
  Bullets:
    - Every request performs a synchronous token validation round-trip
    - Auth middleware adds 180-250ms per request at P99
    - Blocking call prevents connection reuse under load
  Visual: Request waterfall showing auth middleware segment highlighted

Slide 4: Proposed Solution
  Headline: "Async Auth with JWT Caching"
  Bullets:
    - Replace synchronous token validation with async JWT verification
    - Cache validated tokens in Redis with 5-minute TTL
    - Fall back to synchronous validation on cache miss
  Visual: Before/after architecture diagram showing the request flow

Slide 5: Expected Impact
  Headline: "60% Latency Reduction, Zero Downtime"
  Bullets:
    - Projected P99: ~180ms (under the 200ms target)
    - Cache hit rate expected at 92%+ based on token reuse patterns
    - No API contract changes — fully backward compatible
  Visual: Bar chart comparing current vs. projected P99 latency

Slide 6: Rollout Plan
  Headline: "Canary Rollout Over 3 Weeks"
  Bullets:
    - Week 1: 5% canary with real-time latency monitoring
    - Week 2: 25% rollout if P99 stays under 200ms
    - Week 3: 100% rollout with automated rollback trigger
  Visual: Timeline graphic showing the three rollout phases
  CTA: "Review the RFC by Friday — link in Slack #backend-arch"

ベストプラクティス

• 1枚のスライドにつき、アイデアは1つにします。 スライドに見出しを2つ載せる必要がある場合は、スライドを2枚に分けます。認知的な過負荷は記憶の定着を妨げます。聞き手の記憶に残るのは、明快で要点を絞ったメッセージです。
• トピックではなく、要点を伝える見出しを付けます。 「売上高が前年比40％増」は「売上高の概要」よりも適切です。見出しだけで、スライドの主旨が聞き手に伝わるようにします。
• ビジュアルとテキストの比率を3：1にします。 グラフ、画像、図解を使ったスライド3枚につき、テキスト中心のスライドは最大1枚にします。視覚的な変化が集中力を保ちます。
• すべてのスライドに発表者ノートを作成します。 スライドは聞き手が目にする内容であり、発表者ノートは発表者の台本です。口頭で伝えるべき内容をスライドに載せないでください。
• 発表時間1分あたりのスライド枚数を1枚未満にします。 15分の発表枠なら、スライドは最大12～15枚です。情報量の多いスライドを急いで説明するより、内容を削るほうが適切です。
• 最後に、明確な次のステップを示します。 最終スライドでは、URLへのアクセス、会議の設定、提案の承認、特定の日付までの文書の確認など、聞き手が何をすべきかを具体的に伝えます。

エッジケース

• ソース資料が提供されていない場合。 ユーザーが裏付けとなる資料を示さず、トピックだけを提示した場合は、プレースホルダーデータを使ってアウトラインを作成し、仮定を明確に示します。主要な指標や主張を提供するようユーザーに促します。
• 技術に詳しくない聞き手向けの、高度に技術的な内容。 専門用語をわかりやすくし、アーキテクチャ図を大まかな比喩に置き換え、実装の詳細よりも成果（コスト削減、速度の向上）に重点を置きます。
• 非常に大きなソース文書（10ページ以上）。 内容を徹底的に絞り込み、最も重要な3～5点を特定して、補足情報は付録スライドに移します。要約版と詳細な参考版の両方を作成することを提案します。
• アクセシビリティ要件。 十分な色のコントラスト（WCAG AA）を確保し、すべてのビジュアルに代替テキストの説明を付け、色だけで意味を伝えないようにします。大きなフォント（本文は24pt以上、見出しは32pt以上）を使用します。
• 複数の出力形式が求められる場合。 まず、最も移植性の高い形式であるMarp Markdownで標準版を作成し、その後、追加形式への変換手順またはスクリプトを提供します。