PL「明日の顧客説明、この資料で本当に大丈夫かな...？」
メンバA「設計書は更新済みです。ただ、提案資料まで手が回っていません...」
会議直前にこの会話が出ると、チーム全体の空気が一気に重くなります。
問題は個人の作業漏れではありません。更新の正本が分散した運用設計に原因があります。
この記事で解決すること
AIを活用した開発では、設計メモ、仕様整理、実装ノートをMarkdownで書くことが増えています。
一方で、顧客説明や上層部報告は今もPowerPoint/PDF中心です。
このギャップを放置すると、次の問題が起きます。
- Markdown側だけ更新され、説明資料が古くなる
- PowerPointの体裁調整に毎回時間が溶ける
- コード断片の貼り直しでミスが増える
これが「Markdown側だけ更新され続け、説明資料が追いつかない」という二重管理の典型的な崩れ方です。
本記事では、この構造的な問題を断ち切るために、Markdownを単一ソースにし、Slidevで説明資料へ接続する考え方を整理します。
対象環境は GitHub Copilot + VS Code + Windows 11 です。
前提条件
この記事は以下を前提にしています。
- GitでMarkdownを管理している
- VS CodeとGitHub Copilotを利用している
- 顧客・上層部向けにPowerPointまたはPDF提出が必要である
本記事でいう「正本」とは、更新時に最初に修正する唯一の原本を指します。
結論（先に要点）
最初に結論です。
- 設計情報の正本（唯一の更新元）はMarkdownに寄せる
- 説明用途はSlidevで派生生成する
- 1スライド1メッセージを守り、情報過密を禁止する
- PowerPoint前提でフォントと情報量の上限を先に決める
この4点を初期設計で固定すると、後工程のレイアウト崩れと差分修正が激減します。
なぜ今Markdown単一ソースなのか
従来の「設計書はWord、説明はPowerPoint、実装はコード」という分断は、AI活用時代だと非効率です。
理由はシンプルで、AI支援（要約、比較、差分確認）を使う場面では、一次情報がテキストのほうが扱いやすいからです。
Markdown中心にすると、次の利点があります。
- 差分管理がしやすい（Gitで追跡・PRでレビュー可能）
- Copilotで下書き、要約、整形を回しやすい
- 設計と説明の再利用が効く
- コードと文書を同じリポジトリで管理でき、実装と資料のズレを防げる
逆に、説明資料を手作業で別管理すると、更新整合性が最初に壊れます。
作成速度よりも、運用の持続性が先に限界を迎えます。
Slidevを選ぶ理由
Markdownからスライドを作る道はいくつかありますが、実務で扱いやすいのはSlidevです。
- Markdownでそのままスライド構成を書ける
- テーマやレイアウトを共通化しやすい
- エンジニアがVS Codeで完結できる
- 後工程でPDF配布にもつなぎやすい
重要なのは「見た目が作れる」ことではなく、テンプレート化できることです。
属人化した1回限りの資料作成ではなく、チーム運用に乗せられるかが判断基準になります。
運用アーキテクチャ（最小構成）
構成の検討として現時点では、まず迷わない構造だけ定義します。
slides-project/
docs/ # 設計メモ・仕様メモ（Markdown正本）
slides/ # Slidev原稿
assets/ # 図版、ロゴ、スクリーンショット
export/ # PDFなど最終出力
注意: これは概念上の構成例です。
npm create slidev@latestが生成するディレクトリ構造とは異なります。実際の手順と構成の対応は第2回で整理します。
運用ルールは次の2つだけで十分です。
- 仕様変更は必ず
docs/から更新する -
slides/は説明用に要約・再構成する（正本にはしない）
この役割分担が崩れると、再び二重管理に戻ります。
PowerPointで崩れないための実務ノウハウ
ここが現場で効くポイントです。第1回では「先に制約を決める」ことに集中します。
1. 1スライド1メッセージを固定する
ページ内に主張が2つ以上あると、最終調整で必ず詰みます。
収まらない場合は縮小ではなく分割します。
2. コードは4-8行単位で見せる
コード全文を1ページに押し込まないでください。
- 何を見せるか（意図）を先に決める
- その意図が伝わる最小行だけ抜粋する
- 詳細は補足スライドか別紙へ回す
3. フォントを早期固定する
Windows 11での配布を前提に、まず次の候補から始めるのが安全です。
- コード:
Consolas - 日本語本文:
Yu Gothic UIまたはMeiryo UI
この時点で、代替フォントの順番までルール化します。
配布先PCにフォントが無いと、行送りが変わってレイアウト崩れを起こします。
4. 最小フォントサイズを規約化する
目安として以下を初期値にします。
(仮の値で、実際の対象ドキュメントに応じてルール化しましょう。)
- タイトル: 30以上
- 本文: 20以上
- コード: 18以上
可読性より情報量を優先し始めたら、資料品質は一気に落ちます。
最小サンプルでの進め方
ここでは「動く最小単位」だけ作ります。詳細設定は次回で深掘りします。
- Slidevプロジェクトを作成する
- Markdownで3-5ページの短い説明資料を作る
- ブラウザで可読性を確認する（PDF出力の実検証は第2回で扱う）
最小実行例（Windows 11 / VS Codeターミナル）：
npm create slidev@latest
cd <project-name>
npm install
npm run dev
確認方法：
- ブラウザ表示でコードブロックの横はみ出しがない
- ブラウザ表示で本文とコードが可読である
- 1ページ1メッセージを満たしている
完了条件は次の3点です。
- 正本の説明文が
docs/に存在する - 同内容の要約版が
slides/に存在する - PDF出力時の確認観点（フォント、改行、見切れ）を定義できる
サンプルのスライド設計例：
- 1ページ目: 背景と課題
- 2ページ目: 提案アーキテクチャ
- 3ページ目: 導入効果
- 4ページ目: リスクと対策
- 5ページ目: 次アクション
この構成だけでも、上層部説明の最小ラインは満たせます。
目視チェック項目（PowerPoint提出想定）
スライド1ページごとの出力品質確認に使います。ワークフロー全体の設計確認は後述の「導入前チェックリスト」が対応します。
- 見出しが1行で読めるか
- 本文が詰まり過ぎていないか
- コードブロックがはみ出していないか
- 図版の文字が100%表示で読めるか
- ページごとの主張が1つに絞れているか
1つでもNGがあれば、フォント縮小ではなくページ分割を優先します。
失敗パターンと回避策
特に多い失敗は次の3つです。
- 最初からPowerPoint体裁で書き始める
- コード全文を1ページに載せる
- 提出直前にフォント差し替えが発生する
回避策は、運用順序を固定することです。
- 先にMarkdown正本を完成させる
- Slidevで説明粒度に要約する
- フォントと最小サイズを固定してから量産する
導入前チェックリスト（第1回終了時点）
ワークフロー全体の設計が整っているかを確認します。個々のスライド出力の品質確認は前節の「目視チェック項目」を使用してください。
- 正本と派生物の役割をチームで合意したか
- フォント候補とフォールバック順を決めたか
- 1スライド1メッセージのレビュー基準を定義したか
- 収まらない場合は分割する運用を明文化したか
- 提出前チェック項目をテンプレート化したか
Copilot活用ポイント（第1回版）
Copilotは万能化せず、用途を限定すると効果が出ます。
- Markdownの章立て下書き
- 長文の要約（3行要約、1行要約）
- 説明文のトーン調整（技術者向け/管理職向け）
逆に、最終メッセージの妥当性判断は人間が行う前提で運用してください。
まとめ
第1回の到達点は、結論で示した原則を「実際に回せる運用ルール」へ落とし込むことです。
- 正本（Markdown）と派生（Slidev）の境界を定義できる
- 1スライド1メッセージ、フォント、最小サイズの制約を先に固定できる
- 提出前チェックをレビュー可能な手順としてテンプレート化できる
次回は、これらを踏まえた環境整備に進みます。
日本語フォント設定、コード表示の崩れ対策、PDF出力検証を実際に行う予定です。