はじめに
GMOコネクトの永田です。
提案書、作るの辛くないですか？😇
特に官公庁向け提案書は、評価項目ごとにページを作成していくと数十〜数百ページになることも珍しくありません。PowerPoint で作る場合、こんな苦痛が待っています：
- コピペ地獄: スライドをコピーして本文を差し替えて、表のセル幅を調整して……を数十回
- デザイン崩壊: 30ページを超えたあたりからフォントサイズや色がバラつき始める
-
バージョン管理不能:
提案書_v3_最終版_本当の最終版_修正2.pptx - レビューが困難: 「前回からどこが変わったの？」に答えられない
エンジニアとしては正直、一番やりたくない作業の筆頭です。
もし Markdown を書くだけ で、デザインが自動で統一されて、git diff でレビューできる、としたら？
本記事では Slidev + Claude Opus 4.6 でこれを実現した方法を、素の Markdown → 完成スライドの Before/After 付きで紹介します。
2026/02/20追記 本記事の続きを書きました。
まとめ（先に結論）
結論から先にお伝えします。
- Slidev + Vue コンポーネントで提案書の「デザインシステム」を構築できた
- 提案内容の執筆者は Markdown だけ書けばいい（HTML テーブル記述ゼロ、CSS 知識不要）
- Claude との相性が抜群（Markdown は LLM のネイティブ言語。Vue タグも安定して生成可能）
- Git 管理できる提案書（diff、branch、PR レビューが自然に機能する）
- 制約: 複雑な図版やアニメーションは PowerPoint に劣る（正直に）
今回構築したテンプレートの規模感：
| 指標 | 数値 |
|---|---|
| Vue コンポーネント数 | 15個 |
| レイアウト数 | 6種類 |
| CSS 変数（デザイントークン） | 20+ |
| 執筆者が触るファイル | slides.md の1ファイルだけ |
Slidev とは
概要
Slidev は、Markdown ベースのプレゼンテーションフレームワークです。Vue 3 + Vite で構築されており、以下の特徴があります：
- Markdown でスライドを記述
- Vite の HMR（Hot Module Replacement）で保存するたびに即座にプレビュー反映
- PDF / PNG / PPTX / SPA（デプロイ可能な Web アプリ）にエクスポート可能
- ローカルテーマ:
layouts/、components/、styles/に置いた Vue ファイルが自動登録される
Slidev の一般的な紹介については以下の記事が詳しいです。本記事では「提案書作成」という具体的なユースケースでの活用に焦点を当てます。
PptxGenJS との比較
プレゼンテーション生成の選択肢として、PptxGenJS があります。Claude の Cowork 機能などでも使われている、JavaScript で .pptx を生成するライブラリです。
| 比較軸 | PptxGenJS | Slidev |
|---|---|---|
| 出力形式 | .pptx（ネイティブ PowerPoint） | PDF / PNG / PPTX / SPA |
| コンテンツ記述 | JavaScript API 呼び出し | Markdown + Vue コンポーネントタグ |
| 執筆者の前提知識 | JavaScript | Markdown |
| デザイン統一 | 要素ごとにスタイル指定（統一は自己管理） | CSS 変数 + Vue コンポーネントで全ページ自動統一 |
| バージョン管理 | バイナリ .pptx（diff 不可） | プレーンテキスト Markdown（完全 diff 可能） |
| ホットリロード | なし（生成 → ファイルを開く） | あり（Vite HMR で即時反映） |
| LLM との親和性 | JS コード生成（構文エラーしやすい） | Markdown 生成（LLM の得意領域） |
PptxGenJS は .pptx ネイティブ出力が必要な場合に最適です。一方 Slidev は開発体験（DX）と Git 管理を重視する場合に適しています。
今回のプロジェクトでは、Claude が生成した内容をdiffでレビューしたかったため、Markdown ベースの Slidev を選びました。
実際に Slidev で作ってみた
アーキテクチャ
今回構築したテンプレートのディレクトリ構成です。
slidevのコンポーネントは手動作成ではなく、過去の提案書の画像をClaude Opus 4.6に解析してもらい、自動生成してもらいました😊
slidev-template/
├── styles/theme.css # CSS 変数 20+（デザイントークン）
├── layouts/ # 6 レイアウト
│ ├── cover.vue # 表紙
│ ├── section.vue # 章区切り
│ ├── eval-top.vue # 評価基準テーブル（上部）+ 全幅コンテンツ
│ ├── eval-top-2p.vue # 2 評価項目の同時表示
│ ├── eval.vue # 2 段組（サイドパネル + メイン）
│ └── default.vue # 全幅 + ヘッダーバー
└── components/ # 15 コンポーネント
├── DataTable.vue # 配列駆動テーブル（69 行）
├── CompareCards.vue # A/B/C 比較カード（31 行）
├── PolicyTagMap.vue # CSS Grid カードマップ（24 行）
├── StepFlow.vue # プロセスフロー図（29 行）
├── KpiHighlight.vue # 大型数値ハイライト（18 行）
├── ChallengeBox.vue # 課題箱型レイアウト
├── PointCallout.vue # キーメッセージ強調
└── ... 他 8 個
デザインの統一は、CSS 変数（デザイントークン）で管理しています：
:root {
--c-navy: #1B3A5C; /* ヘッダー、強調テキスト */
--c-accent: #B22234; /* KPI、タグ、バッジ */
--c-accent-light: #F2D4D7; /* 評価パネル背景 */
--c-bg-light: #F5F7FA; /* カード背景 */
--font-main: "Meiryo UI", "Yu Gothic UI", sans-serif;
}
ポイント: 執筆者が触るのは slides.md の1ファイルだけ。--c-accent を1行変更すれば、全スライドの PolicyTag、ChallengeBox、バッジカラーが一括で更新されます。
ワークフロー: 素の Markdown → Claude → Slidev Markdown → 完成スライド
ここが本記事の一番伝えたいところです。実際のワークフローを3段階で見てみましょう。
Step 1: エンジニアが書く素の Markdown
エンジニアは 普通の Markdown で提案内容を書きます。特別な知識は不要です。コンポーネントのヒントを括弧やキーワードで添えておくだけです。
## 【スライドN】従来型ウォーターフォールの課題と段階移行
**レイアウト**: default
### 従来型ウォーターフォールの3つの課題を段階移行で解消
**従来の課題**（ChallengeBox）:
従来型の一括移行方式では、以下の構造的課題がありました：
- 全機能を一度に切り替えるため、障害発生時の影響範囲が広い
- 並行稼働期間がなく、切戻し判断の猶予が極めて短い
- 移行リハーサルの実施回数が限られ、本番環境での未検証リスクが残る
#### 本提案の対応方針
| 課題 | 本提案のアプローチ | 期待効果 |
|------|------------------|----------|
| **影響範囲の拡大** | 機能群ごとの段階移行で影響を局所化 | 障害時の影響範囲を **1/4以下** に限定 |
| **切戻し猶予不足** | 1ヶ月の並行稼働期間を設定 | 切戻し判断に **十分な評価期間** を確保 |
| **未検証リスク** | 本番同等環境で移行リハーサルを2回実施 | 本番移行前に **全手順を検証済み** |
**Point**: 段階移行により障害影響を1/4以下に局所化し、並行稼働＋リハーサル2回で未検証リスクを排除します。
見ての通り、普通の Markdownです。（ChallengeBox） のようなコンポーネント名のヒントや、箇条書き、Markdown テーブルを書くだけ。Vue コンポーネントの知識は一切不要です。
Step 2: Claude Opus が Slidev Markdown に変換
Claude に GUIDE.md（Slidevテンプレートの使い方ガイド、ClaudeOpus4.6で生成）を読み込ませた状態で、上記の素の Markdown を渡すと、以下のような Slidev Markdown を生成してくれます：
---
layout: default
section: "組合せ1. 課題→解決策パターン"
evalBadge: 組合せ例
---
### 従来型ウォーターフォールの3つの課題を段階移行で解消
<ChallengeBox
lead="従来型の一括移行方式では、以下の構造的課題がありました："
:items="[
'全機能を一度に切り替えるため、障害発生時の影響範囲が広い',
'並行稼働期間がなく、切戻し判断の猶予が極めて短い',
'移行リハーサルの実施回数が限られ、本番環境での未検証リスクが残る',
]"
/>
<DataTable
:cols="['課題', '本提案のアプローチ', '期待効果']"
:colWidths="['20%', '48%', '32%']"
:boldCols="[0]"
:accentCols="[2]"
:rows="[
['影響範囲の拡大', '機能群ごとの段階移行で影響を局所化', '障害時の影響範囲を <b>1/4以下</b> に限定'],
['切戻し猶予不足', '1ヶ月の並行稼働期間を設定', '切戻し判断に <b>十分な評価期間</b> を確保'],
['未検証リスク', '本番同等環境で移行リハーサルを2回実施', '本番移行前に <b>全手順を検証済み</b>'],
]"
/>
<PointCallout text="段階移行により障害影響を <b>1/4以下</b> に局所化し、並行稼働＋リハーサル2回で <b>未検証リスクを排除</b> します。" />
何が起きたかというと：
-
frontmatter で
layout: default、section（ヘッダー）、evalBadge（右上バッジ）を自動設定 - 箇条書き →
<ChallengeBox>コンポーネント（箱型の課題レイアウト）に変換 - Markdown テーブル →
<DataTable>コンポーネント（boldColsで太字列、accentColsで赤色列を指定）に変換 -
**Point**:→<PointCallout>コンポーネント（キーメッセージの強調帯）に変換
Claude は GUIDE.md を参照して、どのコンポーネントを使うべきか、props にどんな値を渡すべきかを判断しています。エンジニアが素の Markdown にコンポーネント名のヒントを書いておけば、変換精度はさらに上がります。
Step 3: Slidev が完成スライドをレンダリング
普通の Markdown を書いただけなのに、ネイビーのヘッダーバー、赤いバッジ、箱型の課題レイアウト、装飾付きテーブル、強調メッセージ帯が自動で付与されたスライドが完成します。
ショーケース 1: CompareCards — 3方式比較 + KpiHighlight
まず、エンジニアが書く素の Markdown です：
### 3方式の比較検討から、クラウドネイティブ運用を選定
3つの運用方式を比較評価し、コスト・可用性・運用負荷の総合評価で最適な方式を選定しました。
#### 比較表（CompareCards、推奨=クラウドネイティブ）
| | 従来型オンプレ運用 | ハイブリッド運用 | クラウドネイティブ（推奨） |
|---|---|---|---|
| 運用コスト | 年間1,800万円 | 年間1,100万円 | 年間580万円 |
| 障害対応時間 | 平均4時間 | 平均2時間 | 平均30分 |
| スケーラビリティ | 手動・2〜3ヶ月 | 一部自動・1週間 | 全自動・即時 |
| 運用人員 | 5名常駐 | 3名常駐 | 1名＋自動化 |
**KPI**: 運用コスト削減効果 → 年間 1,220 万円（68%）削減（約3.6人月相当）
普通の Markdown テーブルです。（CompareCards、推奨=クラウドネイティブ） のようなヒントを添えているだけ。
これが Claude + Slidev を通すと、こうなります：
3列のカードに自動整形されて、推奨方式にはネイビー枠 + ★マーク。下部には大型の KPI ハイライト。Markdown テーブルからは想像できない見た目になります。
recommended: true でネイビー枠 + ★が自動付与。KpiHighlight は大きなフォントサイズの数値と赤いアクセントの注釈を自動レンダリングします。
ショーケース 2: eval-top レイアウト + DataTable + PolicyTagMap
次は、提案書で最も頻繁に使う「回答サマリー」ページです。エンジニアが書く素の Markdown はこちら：
## 【スライド2】評価基準・回答サマリー
**レイアウト**: eval-top
**評価項目**: 24（加点・10点）
**評価詳細**: データ移行の計画立案から実施まで、既存データの整合性を確保しつつ移行リスクを最小化する提案。
**提案のポイント**:
- 3フェーズの段階的移行で停止時間を最小化
- 差分同期による整合性担保（RPO=0を実現）
- 移行リハーサル2回実施でリスクを事前排除
### 評価基準のキーワードを分解し、各キーワードへの回答を一覧化
| 評価キーワード | 本提案での対応 | 詳細スライド |
|---|---|---|
| **移行計画** | 3フェーズの段階的移行計画を策定 | スライド1-2 |
| **データ整合性** | AWS DMS による差分同期でRPO=0を実現 | スライド1-3 |
| **移行リスク** | 本番同等環境でのリハーサル2回実施 | スライド1-4 |
**PolicyTagMap**:
| キーワード | 詳細スライド | サマリー |
|---|---|---|
| **段階的移行** | スライド1-2 | 3フェーズで停止時間を最小化 |
| **差分同期** | スライド1-3 | RPO=0のデータ整合性担保 |
| **移行リハーサル** | スライド1-4 | 2回のリハーサルでリスク排除 |
**レイアウト**: eval-top で使いたいレイアウトを指定し、評価項目の情報と Markdown テーブルを書いているだけです。**PolicyTagMap**: は「このテーブルはカード型で表示してほしい」というヒント。
Claude + Slidev を通すと：
上部に評価基準テーブル（YAML frontmatter から自動生成）、中部にキーワード分解テーブル、下部にカード型ナビゲーション。素の Markdown の情報量と、完成スライドの見た目のギャップが大きいですね😊
このスライドは3層の仕組みで成り立っています：
- レイアウト（eval-top.vue）: frontmatter の YAML を書くだけで上部の評価基準テーブルが自動描画。HTML テーブルの記述は不要
-
DataTable（69行）: 配列を渡すだけでネイビーヘッダー・ゼブラストライプ付きテーブルを自動生成。
boldCols、accentColsで列ごとの装飾を指定可能 - PolicyTagMap（24行）: CSS Grid + subgrid でカード内の行が自動整列。PowerPoint でのアライメント調整が不要に
おまけ: 開発体験のポイント
-
ホットリロード:
slides.mdを保存するだけで、localhost:3030にリアルタイム反映。PowerPoint の「保存 → 閉じる → 再度開く」が不要 -
A4 縦印刷対応: frontmatter に
canvasWidth: 680、aspectRatio: 210/297の2行を追加 +<PortraitPrint />コンポーネントを1行挿入するだけで、画面表示と印刷出力を両対応 -
PDF エクスポート:
npx slidev export slides.md --output proposal.pdfで一発
まとめ（再掲）
Slidev + ClaudeOpus4.6で、提案書の「デザインシステム」を構築できました。
- エンジニアは 普通の Markdown で提案内容を書く
- Claude Opus がそれを Slidev Markdown に変換（GUIDE.md を参照して適切なコンポーネントを選択）
- Slidev が プロフェッショナルなスライド をレンダリング
- 全てが Git 管理可能。diff でレビュー、branch で並行作業、PR でマージ
ただし制約もあります：
- 複雑な図版（ネットワーク構成図、組織図など）は外部で画像を作成して挿入する必要がある
- ネイティブ .pptx 出力の品質は PptxGenJS に劣る（slidevのPPTX出力は、編集不可の画像として埋め込まれる）
- テンプレート（レイアウト + コンポーネント）の初期構築には Vue / CSS の知識が必要（ただし1回限りのコスト）
向いているチーム: 一貫したフォーマットで繰り返し提案書を作成する組織。一度テンプレートを構築すれば、以降の提案は Markdown を書くだけで済みます。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。