PL「正直、テンプレートって見た目をそろえるだけで、説明の粒度までは整わない気がするんだよね。」
メンバA「同感です。だから社内フォーマットの必須項目を、ページ構造に埋め込みます。」
PL「必須項目って、背景・判断基準・決定事項・次アクションみたいなやつ？」
メンバB「はい。章ごとに書く順番と上限を固定すれば、担当者が変わっても粒度をそろえられます。」
第2回で、フォント・行長・出力検証を固定した環境を作りました。
第3回では、その環境に現場ルールを埋め込んだ資料テンプレートを重ねます。
この記事で解決すること
Windows 11 + Slidev環境に、社内向け資料テンプレートを構築します。
- 現場ルールをテンプレートへ反映し、作成者が変わっても品質の下限を守る
- 記載内容の粒度を規定し、1ページ1メッセージを崩さない運用基準を定義する
結論（先に要点）
- テンプレートには見た目ではなく判断基準を埋め込む
- engineer向けとexecutive向けは後から分けず、最初から分ける
- 1ページの要素数と箇条書き数を上限化して密度暴走を防ぐ
- frontmatter規約でレイアウト選択の迷いをなくし、Copilotは初稿生成までに限定する
判断基準
第3回で重視する判断基準は3つです。
- 作った人の満足ではなく、受け手が判断できるか
- 1ページ1メッセージを守れているか
- PowerPoint/PDF提出時に崩れ・欠落・可読性低下が起きにくいか
評価対象は次の観点でそろえます。
- フォント置換で改行位置が変わっても主張が崩れない
- コードや表が横にはみ出さない
- 100%表示と125%表示のどちらでも読める
- ページごとに主張が1つに絞れている
前提環境
この手順は第2回の成果物を前提にします。
- Slidevプロジェクトが起動できる
- styles.cssでフォントとタイポグラフィを固定済み
- PDF出力を1回以上完走済み
確認方法:
-
npm run devでローカル表示できる - slidev export 対象md でPDFを出力できる
完了条件:
- 新規ページを追加しても既定ルールが自動で適用される
- reviewerが同じ基準で可否判定できる
実践手順
手順1: テンプレートの対象範囲を固定する
判断基準: 品質下限に直結するページだけをテンプレート化する。
対象ページ:
- 表紙
- 章扉
- 本文
- 結論
- 補足
ディレクトリ構成例:
slides/
layouts/
cover.vue # 表紙
default.vue # 本文
section.vue # 章扉
statement.vue # 結論
supplement.vue # 補足
slides.md
確認方法:
- 5種類のレイアウトを使い分けられる
- 本文と補足の分離基準を説明できる
完了条件:
- 新規スライド作成時に対象ページ種別を選べる
- 迷ったときの選択基準をチーム内で説明できる
手順2: frontmatter規約を定義する
判断基準: 記述量を最小化し、迷わず選べることを優先する。
---
layout: default # default / cover / section / statement
audience: engineer # engineer / executive
chapter: 3
title: フォント設計方針
---
適用ファイル: slides/TEMPLATE.md に規約サンプルを1件置き、新規作成時のコピー元にする。
確認方法:
- すべてのページで audience が明示される
- audience 切り替えで情報密度が意図どおり変わる
完了条件:
- frontmatter入力規約をチームで共有できる
- レイアウト選択の再現性がある
手順3: 情報密度ルールをテンプレートに埋め込む
判断基準: コメント運用ではなく、構造で制御する。
密度ルール:
- 箇条書きは最大5項目
- 1ページの視覚要素は最大3つ
- executiveページではコードを使わない
- 数値詳細は補足ページへ退避する
CSS実装例（styles.css）:
/* executiveページのコードブロックを非表示にする */
.slidev-layout.executive pre,
.slidev-layout.executive code {
display: none;
}
/* 6項目以上の箇条書きを警告色で表示して気づかせる */
.slidev-layout ul > li:nth-child(n+6) {
color: #e74c3c;
font-size: 0.85em;
}
確認方法:
- engineer版とexecutive版で差分が明確
- 5項目超の箇条書きが本文に残っていない
完了条件:
- 3種類以上のページでルール適用を確認できる
- 新規ページ追加時に同じ判定ができる
手順4: Copilotを章立て初稿に限定する
判断基準: 生成文の採用可否は密度ルールで判定する。
運用手順:
- 章の問いをプロンプト化して初稿を生成する
- 生成結果を密度ルールで削る
- 超過分を補足ページへ移す
プロンプト例:
以下の条件で1ページ分の初稿を生成してください。
- 対象読者: engineer
- ページの主張（1文）: [ここに主張を入れる]
- 根拠として使える情報: [箇条書きで渡す]
- 箇条書き上限: 5項目
確認方法:
- 初稿から1ページを完成版に変換できる
- 採用理由と不採用理由を説明できる
完了条件:
- Copilotの役割境界をチーム内で共有できる
- 最終品質責任が人間側にあることを説明できる
手順5: 提出フォーマット耐性を組み込む
判断基準: 提出直前の目視調整ではなく、平常時に崩れにくさを確保する。
実施項目:
- 100%表示で読めるか確認
- 125%表示で崩れないか確認
- PowerPoint変換時の改行ズレを確認
- PDFで図表文字が読めるか確認
はみ出し防止CSS例（styles.css）:
/* 表とコードの横スクロール防止 */
pre, table {
max-width: 100%;
overflow-x: auto;
}
確認方法:
- 100%と125%で同じ主張を維持できる
- コード枠と表で横はみ出しが発生しない
完了条件:
- 提出形式が変わっても説明内容が維持される
- レビューで可読性低下を再現可能に検出できる
よくある失敗パターンと回避策
-
失敗: テンプレートを作ったが運用されない
回避策: 既存資料を1本移植し、最初の成功例を配布する -
失敗: engineer向けとexecutive向けを後から分けようとして破綻する
回避策: 最初のページからaudienceを必須化する -
失敗: コンポーネントを増やしすぎて保守不能になる
回避策: レイアウトを5種類に固定し、追加は合意制にする -
失敗: Copilot生成文を密度評価せず採用する
回避策: 採用前に箇条書き上限と1ページ1メッセージで再判定する -
失敗: PowerPoint/PDF提出で改行ズレと見切れが発生する
回避策: 100%/125%の二段階確認をレビュー基準へ組み込む
Slidev変換例: engineer版とexecutive版
同じ設計情報を2系統で書き分けると、読者適合と説明責任を両立できます。
engineer版
---
layout: default
audience: engineer
title: engineer版のページ
---
# engineer版: 会員登録APIの設計判断
判断基準: 実装判断に必要な入力・エラー・完了条件を残す
| 観点 | 内容 |
|------|------|
| 入力項目 | メールアドレス、会社名、担当者名、電話番号 |
| エラー時挙動 | 重複は409、入力不備は400 |
| 完了条件 | 確認メール送信まで完了 |
executive版
---
layout: default
audience: executive
title: executive版のページ
---
# executive版: 会員登録APIの説明ポイント
結論: 入力項目、失敗時の扱い、登録完了条件を1ページで判断できるようにする
- 入力は4項目に限定
- 異常時応答は重複と入力不備の2系統
- 登録完了後は確認メール送信まで保証
まとめと次回予告
第3回の到達点は、環境整備から運用標準化への移行です。
- 現場ルールをテンプレートへ埋め込み、品質下限を固定した
- audience切り替えで読者別の情報密度を制御できるようにした
- Copilotと人間の責務境界を運用として定義した
次回の第4回では、1から3回で整えた正本、環境、テンプレートを統合し、Markdown正本からengineer版とexecutive版を生成して二重管理を再発させない運用設計を扱います。