HTMLスライド PowerPoint変換 一式

仕様版 2026-09（リリース版）／2026-10 改訂（イメージ図ひな型 v1.3・変換 v0.9.0・チェッカー v0.9・deck-fix v1.8）

9点セットで運用する。ひな型4種と変換ツールは対になっているため、片方だけ差し替えないこと。4種のひな型は、変更禁止領域（deck-fix v1.8）の中身が寸法の数値を除いて同じである。チェッカーはひな型のルールに対応しているため、ひな型を改版したら検査項目も見直す。依頼様式は報告資料ひな型の欄と対応しているため、報告資料ひな型を改版したら様式も見直す。図キット（イメージ図の部品）は、イメージ図ひな型の中にあり、他のひな型へ移植して使う（3.6）。イメージ図の依頼様式も、イメージ図ひな型の作業ルール（【14】）と対応しているため、イメージ図ひな型を改版したら様式も見直す。

スライドひな型 v22 は廃止した（2026-09）。スライドひな型は、デジタル庁デザインシステム（DADS）に準拠した v23 以降だけを残す。v22 の骨格・型カタログ・文書モード・作業ルールは、DADS準拠版にそのまま引き継がれている（経緯は §6.0）。v22 で作った既存の資料は、変換ツール v0.9.0・チェッカー v0.9 で従来どおり扱える。

スライドひな型 v23（緑・青）など、deck-fix が v1.6 のままのひな型も、変換ツール v0.9.0・チェッカー v0.9 で従来どおり扱える（PDFの余白が画面と違う点と、原稿パネルが無い点だけが異なる）。

チェッカーは v0.9 に一本化してよい。図キットの部品が無いファイルでは、v0.8 と結果が完全に一致する（§6.18）。

変換ツールは v0.9.0 に一本化してよい。図キットを使っていないHTMLでは、v0.8.0 と出力がバイト単位で一致する（§6.16）。イメージ図、および図キットを移植した資料は v0.9.0 が必須で、v0.8.0 以前では線と人物・モノの絵がエラーにならずに抜け落ちる。

deck-fix v1.7 のひな型（スライド v24a・教材 v1.1・報告資料 v2.1a・イメージ図 v1.2）で作った資料は、「HTML保存」したファイルを開き直すと、はみ出し検知・一覧・番号ジャンプ・原稿パネルが動かない。ページ送りだけは動くので気づきにくい。deck-fix v1.8 のブロックを貼り直せば直る（9章、§6.17）。変換とチェッカーの結果には影響しない。

第1部　利用手順書

1. このセットでできること

生成AIに作らせたHTMLを、PowerPointで編集できる状態に変換する。

画像やPDFとして貼り付けるのではなく、タイトル・本文・カード・表がそれぞれPowerPointのオブジェクトになる。そのため、変換後に文言を直したり、図形を動かしたり、表に行を足したりできる。

変換はすべて端末内で完結する。HTMLファイルもPPTXファイルも外部に送信されない。

ひな型は4種類ある。作るものに合わせて選ぶ。

スライドひな型の緑と青は、色だけが違う。組織や資料の用途に合わせて選べばよい。

報告資料ひな型は、部長の報告資料の書き方（1議題1枚、結論が先、数字と期間を括弧で添える、主語は当部、など）をルールとして持っている。素材（提案書やメモ）を渡すと、AIが取捨選択して部長の書き方に書き直す。

イメージ図ひな型は、生命保険の現場の人物（営業職員、本社・支社の社員、お客様、コールセンターのオペレーターなど）とモノ（パソコン、営業職員端末、サーバー、書類など）の絵をカタログとして持っている。AIは絵を描かず、カタログのキーで呼ぶだけ。線は「どこからどこへ」だけを書き、座標は図キットが計算する。変換すると、線はPowerPointの本物の線（矢印つき）になり、端点をつまんで動かせる。

できないこと

• 写真・イラストの変換（HTMLに入れず、PowerPointにしてから挿入する）。24×24のSVGアイコンと、イメージ図ひな型のカタログにある人物・モノの絵は、画像（PNG）として変換される
• 任意のWebページの変換（このひな型で作ったHTML専用）
• 完全な見た目の再現（グラデーションは単色になる、など。詳細は第2部）

2. 準備

初回に一度だけ確認する。

1. BIZ UDPゴシックが端末に入っているか　変換ツールを開くと、左側の「健全性チェック」に利用可否が表示される。Windows 10 (1809) 以降なら標準で入っている。
2. ブラウザ　Microsoft Edge または Chrome。ツールのHTMLをダブルクリックで開くだけでよい。インストール作業は不要。

3. 資料を作る（スライドひな型 v24b・教材ひな型 v1.1a・イメージ図ひな型 v1.3）

いつもどおりの進め方でよい。

1. 生成AIと相談して、資料の骨格・設計書をまとめる
2. スライドひな型_v24b_DADS_緑.html（教材なら 教材ひな型_v1.1a.html。3.3。イメージ図なら イメージ図ひな型_v1.3.html とイメージ図用の依頼様式。3.5）を添付し、「これをひな型にして作成してほしい」と指示する
3. AIがひな型内のルール（スライドひな型は【0】〜【12】、教材ひな型は【0】〜【9】、イメージ図ひな型は【0】〜【20】）に従ってHTMLを生成する

ひな型にはPowerPoint変換のための構造ルール【9】が入っているため、特別な指示をしなくても変換しやすいHTMLが出てくる。

さらに骨格と型カタログ【10】【11】と、DADS に合わせるための規則【12】（色・コントラスト・文字サイズの段階値など）が入っている。本文スライドは「タイトル → ヘッドメッセージ（箇条書き2〜3行）→ ボディ → 出典」の骨格で作られる。

型は4種ある。AIは1枚ごとに、そこに並ぶ要素どうしの関係を先に判定して型を選ぶ。

調査報告・現状説明・用語整理は、ほとんどが「並列」である。どれにも当てはまらないとAIが判断した場合は、勝手に新しいレイアウトを作らず相談してくるようになっている。

3.1 文書モードを使うとき（スライドひな型のみ）

モードはこちらが指示する。AIは内容から推測しない。

指示しなければ常にスライドモードになる。「レポート」「メモ」「報告書」という言葉が会話に出てきても、それだけでは切り替わらない。確認の質問も来ない。

文書にしたいときは、指示に一言足す。

「これは文書モードで作って」
「本編はスライド、最後の確認事項だけ文書モードで」

指示した範囲だけが文書モードになる。1つの資料の中でスライドと文書が混在して構わない。

役員・社長に判断してもらう報告資料を作るなら、文書モードではなく 報告資料ひな型（4章） を使う。

3.2 指示するときの注意

• 写真やイラストは入れさせない。PowerPointにしてから挿入する
• 表にする内容（比較、課題と打ち手）は「表で」と明示する。Gridで似せた見た目より、本物の <table> のほうが変換後に扱いやすい
• 逆に、並列の説明を表にさせない。本文2行の表や、1列が出典・区分ラベルだけの表が出てきたら型④に作り直させる（【5】の下限）
• グラデーションは表紙だけにする

3.3 教材を作るとき（教材ひな型 v1.1a）

勉強会・研修で「投影しながら話して、理解してもらう」資料は、教材ひな型_v1.1a.html を添付して作らせる。スライドひな型との違いは次のとおり。

教材は配布用の読み物（Markdown など）とセットで作る。説明しきりたい内容は読み物に書き、画面には「見て分かるもの」だけを置く。

3.4 話す原稿（ノート欄）

教材ひな型では全ページに、スライドひな型では必要なときだけ、各ページの最後に話す原稿を置く。

<aside class="notes" data-notes="">
  <p>1段落目</p>
  <p>2段落目</p>
</aside>

• 画面・PDF・一覧には出ない。変換ツール（v0.8.0 以降）で、そのスライドのノート欄に入る（<p> 1つ＝1段落）
• HTMLで直すときは「編集」を押す。画面の下に原稿パネルが出るので、そこで書き換えて「HTML保存」する（パネルの1行＝1段落）。原稿の無いページで書くと、原稿が新しく作られる
• 報告資料ひな型では使わない（紙で読まれるため）

3.5 イメージ図を作るとき（イメージ図ひな型 v1.3）

組織体制・新システムのイメージ・新しい仕事の運用の流れなど、「誰が・何を・どこへ渡すか」を1枚で見せる図は、報告資料と同じく依頼様式で作らせる。

手順

1. イメージ図_依頼様式.md の様式をコピーする（LABトップにもコピーボタンがある）
2. 1〜10の欄を選ぶ。選択肢のある欄は使うものだけを残す。選ばずに貼った欄は既定値になる。空欄でもよい
3. 末尾の【要件定義】に、図にしたいことを自由に書く。メモ・箇条書き・会議資料の文章の貼り付けでよい。誰が・何が出てくるか、誰から誰へ何が渡るか、今の話か将来の話かが書いてあると、AIが仕分けやすい
4. イメージ図ひな型_v1.3.html を添付し、埋めた様式を貼って依頼する
5. AIが図と、チャットでの報告を返す。報告の「読み取った設定」「要件定義の仕分け」「仮の前提」を確認する
6. 5章（変換前の確認）へ進む

プロンプトは様式だけでよい。「1枚で」「吹き出しで」などの指示は、様式の選択肢とひな型のルールに入っている。

【イメージ図 作成依頼】
1. 図の名前　　：
2. 見せる相手　：
3. 伝えたいこと：
4. 枚数　　　　：1枚完結 ／ 複数枚でよい
5. 型　　　　　：おまかせ ／ F1 組織体制図 ／ F2 システム構成 ／ F3 業務フロー ／ F4 現状と将来
6. 強調　　　　：吹き出し ／ 図形の塗り
7. 密度　　　　：標準 ／ 高密度
8. 表紙　　　　：なし ／ あり
9. 文言の扱い　：加工してよい ／ そのまま使う
10. 補足　　　 ：
【要件定義】

様式で人が決めること、ひな型が決めること

欄の書き方と記入例は イメージ図_依頼様式.md（LABでは保護資料）にある。

図の部品

図の型は4つある。AIは内容の関係から型を選ぶ（様式5で指定してもよい）。どれにも当てはまらないときは、新しい書き方を作らずに相談してくる。

人物とモノはカタログ（2・3枚目）から選ぶ。人物12種（営業職員、営業職員が赤い営業職員端末をお客様に見せている姿、本社・支社の男性・女性社員（PC操作あり／なし）、管理職、お客様（おじいちゃん・おばあちゃん）、コールセンターのオペレーター、不特定の人）と、モノ15種（パソコン、営業職員端末、タブレット、スマホ、サーバー、データベース、クラウド、書類、審査・点検、チャット、AI、ヘッドセット、メール・郵送、本社・支社、お客様宅）がある。カタログに無い絵が必要なときは、AIは作らずに相談してくる。

• HTMLを開いて「編集」で文字を直すと、線・グループ枠・吹き出しの指し線は自動で付いてくる
• 直したい点は、図を直接直させるより、様式や要件定義を直して作り直させると早い

変換は v0.9.0 以降が必須である。v0.8.0 以前で変換すると、線と人物・モノの絵がエラーにならずに消える。

3.6 図を他のひな型へ移植するとき（図キット）

イメージ図の部品一式（図キット）は、スライドひな型・報告資料ひな型・教材ひな型にも入れて使える。コピーするのは2ブロックだけである（イメージ図ひな型【13】）。

1. <style id="fig-kit-style"> … </style> を、移植先の head の style の後ろに貼る
2. <script id="fig-kit-script"> … </script> を、移植先の deck-fix-script の後ろに貼る
3. 図のページを足す（スライドひな型なら .body-area の中に .fig を1つ）

• 色は移植先の主色に追従する（緑版に入れれば、営業職員の制服も緑になる）
• 報告資料ひな型（A4横）は図に使える面積が小さい。移植先の :root で --fig-person:80px; --fig-obj:64px; --fig-gap-x:40px; --fig-gap-y:28px; に下げてから作る
• 教材ひな型は文字の下限が20px。移植先の :root で --fs-fig-sub／--fs-fig-cap／--fs-fig-tag／--fs-fig-wrap を 20px 以上に再定義する（下げないとチェッカーでエラーになる）
• 移植先の :root での再定義は、図キット v1.2（イメージ図ひな型 v1.3）から効く。図キット v1.1 では、図キット側の既定値が後ろにあるため、:root に書いた値が画面で効いていなかった（チェッカーは書いた値で判定するので、指摘は出なかった）。v1.1 を移植した資料は、fig-kit-style を v1.3 のものに貼り替える（§6.18）
• 移植先の変更禁止領域（deck-fix）にも、図キットのCSSそのものにも触らない。値の調整は :root の --fig-*／--call-* の再定義だけで行う
• 吹き出しも図キットに入っている。移植するブロックは2つのまま

4. 資料を作る（報告資料ひな型 v2.1b）

4.1 手順

1. 依頼様式.md の様式を埋める。迷ったら、様式の「部長資料での実例」を見て、自分の資料に近いものを探す
2. 生成AIに次の3つを渡す。
   • 報告資料ひな型_v2.1b.html（添付）
   • 埋めた様式（プロンプトの冒頭に貼る）
   • 素材（提案書・メモ・集計表などのテキストを、様式の【素材】の下に貼る）
3. AIがHTMLと、チャットでの報告を返す。報告は4.3の順に確認する
4. 5章（変換前の確認）へ進む

プロンプトは様式と素材だけでよい。「部長の書き方で」「1枚で」などの指示は、ひな型のルールに入っているので書かなくてよい。

4.2 様式で人が決めること、ひな型が決めること

特に大事な欄は2つある。

• 2. 求めるもの（承認／報告／論点の共有）：これで資料の型が決まる。空欄だと、AIが作成前に質問してくる
• 3. 立場（当部の施策／他部署の施策の報告／外部情報の共有）：これで紙面の主語が決まる。ベンダーの提案書が素材でも、自分たちがやりたいなら「当部の施策」。空欄だと、AIが作成前に質問してくる

数字の欄は「空欄」と「未定」を区別する。空欄ならAIが素材から探す。「未定」なら素材にあっても使わず、●●●にする。

承認後の進め方や次の判断は、補足欄に書かない限り紙面に載らない。AIは素材に無い予定を作らないルールになっている。

4.3 AIの報告を確認する

AIはHTMLと一緒に、チャットで次を返す。上から順に確認する。

4.4 ●●●を埋める

●●●（黄色の網掛け）は、必須なのに素材に無かった値である。AIは数字・日付・金額を推定で埋めないため、人が埋める。

1. HTMLをブラウザで開き、ツールバーの「編集」を押す
2. ●●●をクリックして、値を書き換える
3. 黄色の網掛けが残る場合は、AIに「●●●を◯◯に置き換えて、網掛けを外して」と頼むか、HTMLの class="tbd" を消す

提出前に●●●がすべて埋まっているかは、チェッカーで確認できる（5.2）。

5. 変換前に確認する

この確認を飛ばさないこと。HTMLで文字が溢れている状態で変換すると、PowerPoint側では別の形で溢れる。

確認は2段階ある。はみ出しは高さの問題、チェッカーは構造の問題を見る。どのひな型で作ったHTMLでも、手順は同じである。

5.1 はみ出しの確認（目視）

1. 作成されたHTMLをブラウザで開く
2. ツールバーの「はみ出し」ボタンをONにする
3. 全ページを送り、赤枠が1つも出ないことを確認する
4. 赤枠が出たら、AIに文言の短縮やページ分割を依頼して直す

スライドひな型の文書モードで1ページに入りきらなくなったら、文字を詰めるのではなく section.slide.doc をもう1枚足し、節の切れ目で分ける。報告資料ひな型では、まず要点を削る。それでも入らない根拠（コスト内訳・日程など）だけを2枚目に回す。

5.2 残骸とルール違反の確認（チェッカー）

html-slide-lint-v0_9.html をダブルクリックで開き、HTMLファイルをドロップする。検査は端末内で完結し、ファイルは外部に送信されない。

どのひな型で作ったHTMLかは、チェッカーが自動で判定する。結果の上に「スライドひな型として検査」「教材ひな型として検査」「報告資料ひな型として検査」「イメージ図ひな型として検査」のどれかが表示される。判定は <meta name="slide-spec-version"> の値（lesson を含めば教材、figure を含めばイメージ図、report を含めば報告資料）で行う。図キットを移植した資料は、移植先のひな型として検査され、あわせて図の検査も行われる（「図キットの図 N 個」と表示される）。

エラーが0件であることを確認する。警告と情報は内容を見て判断してよい。

ひな型そのものを読ませたときの結果が基準線になる。資料側でそれ以外が出たら、自分が足したものと考えてよい。

図キットを移植した資料の基準線は、移植先のひな型と同じである（図の部品は誤検知しない）。

報告資料ひな型で作った資料に特有の結果

• 「●●●（未記入の必須要素）が残っている」（情報）：提出前にすべて埋める
• 「ベンダー提案書の主語が残っている（貴社・御社・弊社）」（エラー）：提案書の視点のまま作られている。AIに当部の視点で作り直させる
• 「番号付きの見出しが .sec になっていない」（エラー）：見出しの見た目が揃っていない。AIに直させる
• 「見本ページが残っている」（警告）：ひな型の見本（架空の題材）を消し忘れている
• 「未使用のCSSクラス」（警告）：使わなかった部品のCSSが残っているだけなので、気にしなくてよい

教材ひな型で作った資料に特有の結果

• 「話す原稿が無いページ」（警告）：教材では全ページ必須。AIに書かせるか、原稿パネルで書く
• 「話す原稿に data-notes が無い（古い書き方）」（警告）：教材ひな型 v1 で作った資料。変換はできるが、原稿パネルで直せない。<aside class="notes" data-notes=""> に直す
• 「20px未満の文字」（エラー）：投影で読めない。説明を話す原稿へ移す → 配布資料に回す → ページを分ける、の順で直す
• 「他のひな型の部品が混入」（エラー）：スライドひな型・報告資料ひな型の部品を使っている。AIに作り直させる
• 「強調が多すぎる」「表の行が多すぎる」「見本ページが残っている」（警告）：ひな型のルールどおりに直す

イメージ図ひな型で作った資料、図キットを移植した資料に特有の結果

• 「カタログに無い絵のキー（data-pict）」（エラー）：画面では赤い破線の四角になっている。綴りを直すか、カタログにある絵に替えさせる
• 「線・ラベル・グループ枠のつなぎ先が無い」（エラー）：data-from／data-to／data-for／data-wrap の宛先の部品が無い。図キットはエラーを出さずにその線を消すため、画面で線が足りないことに気づきにくい
• 「data-id の重複」「線・ラベル・グループ枠が .fig の直下に無い」（エラー）：線が別の部品につながる、または位置が計算されない。AIに直させる
• 「ブロックが無い」（エラー）：図キットの2ブロックのどちらかが無い。3.6 の手順で入れ直す
• 「図の文字が小さすぎる」（エラー）：--fs-fig-* を下限より小さくしている。教材に移植した図では、教材の下限20pxが適用される（3.6）
• 「カタログを使わずに描いたSVG」（エラー。イメージ図のみ）：AIが絵を自分で描いている。カタログのキーで呼ばせる
• 「インライン style が決まりの2種類以外」「図の部品が目安より多い」「1ページに図が2つ以上」（警告）：ひな型のルールどおりに直す。ツールバーの A＋／A－ で付いた文字サイズは指摘しない。目安は部品14個・線14本・グループ枠3つ（吹き出しと指し線は数えない）。高密度モードの図（.fig に data-density="high"）は部品20個・線20本・グループ枠4つ
• 「指し線（.f-pt）に data-head="none" が無い」（エラー）：PowerPoint で吹き出しの指し線に矢印が付く。AIに直させる
• 「指し線の吹き出しと対象が同じ行に無い」「吹き出しが5つ以上」「吹き出しと .f-key を同じ図で使っている」（警告）：ひな型のルール【16】【15】どおりに直す
• 「見本・カタログのページが残っている」（警告。イメージ図のみ）：表紙（見出しが「イメージ図ひな型」のまま）、カタログ（2・3枚目）や見本（4〜10枚目）を消し忘れている
• 「存在しないスライドを指すCSS」（エラー）：見本09・10を複製したとき、ページ固有の調整（.slide[data-no="09"] など）の番号を合わせていない。番号を合わせ、使わない方を消させる
• 「未使用のCSSクラス」（警告）：見本・カタログを消すと必ず出る。気にしなくてよい

このツールが必要な理由は2つある。

ひとつは、ひな型のセルフチェックがAIの自己申告にすぎないこと。守られたかどうかを人間側で検証する手段がなかった。

もうひとつは、ブラウザで見ても分からない種類の問題があること。使われていないCSS、存在しないスライド番号を指すルール、宣言ブロックが欠けた壊れたセレクタ。いずれも画面上は何も起きないため、目視では気づけない。

検出できないものもある。文字が溢れているかは判定できないため、5.1 の目視と併用すること。報告資料の中身が素材どおりか（事実の創作が無いか）も判定できないため、4.3 のAIの報告と併せて確認する。

6. PDFにする

1. HTMLをブラウザで開き、ツールバーの「PDF出力」を押す
2. 印刷画面で「PDF として保存」を選ぶ
3. 余白は「なし」、「背景のグラフィック」をONにして保存する

報告資料ひな型のPDFは、A4横と同じ比率（14.6×10.3in）で出力される。A4用紙に印刷するときは「用紙に合わせる」を選べば、そのままA4横になる。

7. PowerPointに変換する

1. html-slide-to-pptx-v0.9.0.html をブラウザで開く
2. 「HTMLファイルを選択」を押すか、HTMLをウィンドウにドロップする
3. 左側の健全性チェックを確認する。次の2つに ✓ が付いていること。! が出ている場合は変換しない（9章）
   • 「ステージ実測が ◯×◯ か」：スライドひな型・教材ひな型・イメージ図ひな型なら 1600×900、報告資料ひな型なら 1403×992
   • 「全スライドを計測できたか」：分子と分母が一致していること
   • 教材ひな型では、あわせて「話す原稿（ノート欄へ転写）」が全ページ数と一致していることを確認する（無くても変換はできる）
   • イメージ図（図キットを移植した資料を含む）では、あわせて「線（PowerPointの線として転写）」の本数が、図の線の本数（吹き出しの指し線を含む）と一致していることを確認する。! が出たら、つなぎ先の無い線がある（チェッカーでもエラーになる）
4. 右側のプレビューで、検出された要素の枠が元のページと同じ形に並んでいるか目視する
5. 「PowerPointに変換」を押す
6. PPTXがダウンロードフォルダに保存される

ステージの寸法は、変換ツールがHTMLの中の設定（<meta name="slide-stage">）から自動で読み取る。報告資料ひな型には「1403x992」が入っているので、変換後のスライドはA4横（11.69×8.27in）になる。この設定が無いHTML（スライドひな型など）は、従来どおり1600×900（16:9）として変換される。

保存ダイアログは出ない。ブラウザの制約で「名前を付けて保存」を表示できないため、ダウンロードフォルダに直接保存される。必要に応じて後から移動する。

変換後、ボタンの下に結果が表示される。

図形 18／文字 116／表 1／枠線の分解 7
アイコン 10 / 10 件を挿入しました。
グラデーション 2 件を再現しました。
話す原稿 11 枚分をノート欄に入れました。

イメージ図では、次のように線の本数が出る。人物・モノの絵は「アイコン」に数えられる。

図形 66／文字 160／表 0／枠線の分解 0／線 26
アイコン 55 / 55 件を挿入しました。

8. 変換後にやること

1. PowerPointで開いて、崩れがないか確認する
2. 写真・イラストを挿入する
3. アイコンが挿入できなかった場合は手で追加する　変換結果に「アイコン ○件は挿入できませんでした」と出たときだけ
4. 話す原稿を使う場合は、ノート欄を確認する　表示 → ノート で、段落が分かれて入っているか見る
5. イメージ図の場合は、線と矢印を確認する　直線は「線」、折れ線は「フリーフォーム」になっている。吹き出しの指し線には矢印が付かない。吹き出しの枠と文字は別の図形なので、動かすときは両方を選ぶ。端点や頂点はつまんで動かせる（フリーフォームは右クリック →「頂点の編集」）。箱を動かしても線は付いてこないので、大きく直すときはHTML側で直して変換し直す

9. うまくいかないとき

変換ツールの「計測結果をJSONで保存」で出力されるファイルには、検出された全要素の座標・色・書式が入っている。原因が分からないときはこれを見る。

10. GON KIKAKU LABを更新・公開する

LABの公開先は Cloudflare Workers Static Assets である。認証処理を含むため、Cloudflare管理画面の「静的ファイルをアップロード」やZIPアップロードは使わない。これらの画面では静的なHTML・CSS・JavaScriptしか配置できず、保護資料の認証処理を更新できない。

公開は、作業フォルダ直下の wrangler.jsonc を使って行う。

10.1 普段の更新

1. lab.gon-kikaku フォルダ内のHTMLやMarkdownを更新する
2. リンク切れ、noindex、ひな型・チェッカー・変換ツール・マニュアルの対応関係を確認する
3. 作業フォルダ gon-kikakuドットコム でPowerShellを開く
4. 次を実行する

npx.cmd --yes wrangler@4 deploy --config wrangler.jsonc

Uploaded labgon-kikaku と Deployed labgon-kikaku が表示されれば公開完了である。ログイン期限が切れている場合はCloudflareのログイン画面が開くので、許可後にそのまま待つ。

Codexへ更新を依頼している場合は、最後に 「修正後、Cloudflareにも反映して」 と指示すればよい。

通常の更新では、合言葉とCookie署名キーの再登録は不要である。Cloudflareに登録済みのSecretは、HTMLやMarkdownを再配置しても保持される。

10.2 公開ファイルと保護資料の置き場所

protected フォルダに追加したファイルは、自動的に認証対象になる。トップページなどからリンクするときも、必ず /html2pptx/protected/ のURLを指定する。認証状態は同じブラウザで8時間共有されるため、1つの保護資料で認証すると、別の保護資料は再入力なしで開く。

通常ページはWorkerを経由せず静的配信される。認証処理とWorkers無料枠を使うのは、/html2pptx/protected/* へのアクセスだけである。

10.3 合言葉を変更するとき

合言葉やCookie署名キーは、Markdown、HTML、worker/index.js、wrangler.jsonc に書かない。CloudflareのSecretとして登録する。

合言葉を変更するときは、作業フォルダで次を実行し、表示された入力欄へ新しい値を入力する。

npx.cmd --yes wrangler@4 secret put DOCS_PASSPHRASE --config wrangler.jsonc

Cookie署名キーを変更するときは次を実行する。変更すると、それまでの認証状態はすべて無効になり、利用者は合言葉の再入力が必要になる。

npx.cmd --yes wrangler@4 secret put DOCS_COOKIE_KEY --config wrangler.jsonc

Secretの値はコマンド履歴や手順書へ書かず、対話式の入力欄へ貼り付ける。

第2部　仕様書

0. この文書の位置づけ

主な読み手はAIである。 この一式の改修を再びAIに依頼するとき、本章以降をそのまま読ませれば、経緯・判断・地雷を再導出せずに作業を再開できる。

そのため、以下を意図的に含めている。

• なぜその設計にしたのか（採用しなかった案とその理由を含む）
• 実装中に踏んだ落とし穴と、その回避方法
• 実測で確認済みの数値（推測ではない事実）

重要：本書に「検証済み」と書かれた事項は、実際に動かして確認したものである。再検証は不要だが、疑わしければJSONと生成物で追試できる。

1. 経緯と設計判断

1.1 出発点

生成AIを使うと、HTML+CSSでデザイン性の高いスライドを容易に作れる。一方、社内での共有・修正・再利用ではPowerPointが求められる。画像やPDFで貼ると編集できない。この両立が目的。

1.2 採らなかった案と理由

記号の字幅を疑ったが、原因は別だった（重要）

カプセル型のバッジ（.layer-priority「★ 今回、最も重視」）で、文字が右へ5px・下へ6pxずれ、末尾がカプセルからはみ出す症状が出た。

このとき「BIZ UDPゴシックに★が入っておらず、ブラウザとPowerPointが別々の書体で代替しているため字幅が食い違う」と判断し、記号に別書体を指定する仕組み（.sym）をひな型と変換器の両方に実装した。

これは誤りだった。 実際の原因は次の2つで、いずれも書体とは無関係である。

両方を修正したうえで .sym を全廃したひな型（v18）で検証したところ、文字はカプセル内に正しく収まった（左12.6 / 右11.4 / 上5.7 / 下8.0 px、CSSの指定は左右11・上下4）。★はBIZ UDPゴシックで正常に描画されている。

誤診の経緯を残す。次に同じ症状を見たときに同じ遠回りをしないため。

• 表示倍率の異なる2枚のスクリーンショットから墨面を切り出して字幅を比較し、「★はPPTXで18.8px、HTMLで12.2px」という数値を得た。倍率補正と閾値処理の誤差が大きく、この精度で結論を出すべきではなかった
• 同じ測定で文字列全体の墨面の幅は131pxと133pxでほぼ一致していた。★だけが6px広いなら全体も広くなるはずで、矛盾している。この矛盾を検討せず、仮説に合う数値だけを採用した
• 縦横がほぼ同量ずれていたことが決め手だった。字幅の問題なら横にしかずれない。四方から等しく寄っているなら図形側を疑うべきである

症状から原因への対応：

「その字を書体が持っているか」の自動判定は諦めた

上の誤診を確かめようとして2つの方法を試し、どちらも誤った結果を出した。

document.fonts.check() も、仕様上は「フォントが読み込み済みか」を返すもので、グリフの有無を返さない。

教訓：この種の判定を実装するときは、答えの分かっているデータ（確実にある字・確実にない字）での検算を先に作ること。 上の2つは、検算がなければ「動いているように見える誤った結果」をそのまま採用していた。

1.3 中核となる設計判断

(a) CSSを一切パースしない

getComputedStyle() はカスケード・!important・CSS変数・メディアクエリ・Grid/Flexの計算結果をすべて解決した最終値を返す。したがってCSSパーサは不要。

この方針が重要なのは、ひな型から生成されるHTMLのクラス名が世代間で安定していないためである。実測では2つのデッキ間でクラスの共通率は78個中19個しかなかった。生成AIはルールと骨格は守るが、クラス語彙は毎回作り直す。よってクラス名に依存する変換ロジックは必ず破綻する。幾何とタグと data-editable だけで判定すること。

この方針には副次的な効果がある。 v22 で文書モードを足したとき、変換ツールは1行も改修が要らなかった。文書モードも「1600×900のステージ上に文字要素が並んでいるだけ」であり、変換器はクラスを見ていないため区別する必要がない（§6.10）。

(b) 忠実な転写に徹する

意味の解釈（これはタイトルだ、カードを等間隔に整列しよう）は一切しない。ブラウザが計算した矩形をそのまま写す。崩れたらHTML側を直す運用。

(c) 表だけはPowerPointの表オブジェクトにする

この一式で唯一、忠実さより編集性を優先している箇所。図形とテキストボックスの集合にすると、行を1つ足すだけで全部を手で動かすことになる。表オブジェクトなら行追加・列幅調整・罫線変更がその場でできる。

(d) 変換は常にBIZ UDPゴシックの計測値で行う

変換ツールは内部で *{font-family:BIZ UDPGothic!important} を注入した状態で測る。したがってひな型のフォントを差し替えていないHTMLでも正しく変換できる。測定側と描画側で同じ書体を使うことで、日本語の折り返し位置がほぼ一致する。

(e) 画像は変換対象外

ユーザーがPowerPoint側で挿入する運用。これによりラスタライザもBase64の埋め込み処理も不要になった。

2. 座標系（検証済み）

                スライドひな型 v24b         報告資料ひな型 v2.1b
                教材ひな型 v1.1a
                イメージ図ひな型 v1.3
ステージ        1600 × 900 px（16:9）       1403 × 992 px（A4横）
PowerPoint      13.3333 × 7.5 in            11.6917 × 8.2667 in
換算            120 px = 1 in（両方共通）
フォント        pt = px × 0.6    （72 / 120）
罫線幅          pt = px × 0.6

ステージの寸法は、変換ツール（v0.7.0 以降）が変換元HTMLの <meta name="slide-stage"> から読む。無ければ 1600×900 とみなす（§6.12、地雷23）。

実測で deck の矩形が誤差0でステージ寸法どおりになることを確認済み（v0.7.0 のときにスライドひな型 v22 と報告資料ひな型 v1 で、v0.8.0 のときにスライド・教材・報告資料の3種で、v0.9.0 のときにイメージ図ひな型で確認）。換算は120px＝1inで共通なので、丸め誤差を考えなくてよい。

スライドひな型は、文書モードでもこの座標系を変えない。紙（A4）の比率で作り直さないこと。理由は §6.10 を参照。A4横が必要な報告資料は、報告資料ひな型（1403×992）を使う（§6.12）。

3. 計測（測定側）

3.1 手順

1. HTMLをテキストとして読み、iframe の srcdoc に流し込む
2. requestAnimationFrame を2回待つ
3. 測定用CSSを注入する
4. 変換元に window.figLayout()（図キット）があれば呼び、線とグループ枠を引き直す（v0.9.0、地雷29）
5. 全 section.slide を走査する
6. フォント上書きCSSを追加注入し、4・5 をもう一度行う（差分比較用）

3.2 測定用CSS（必須）

.deck{--stage-scale:1 !important;
      transform:translate(-50%,-50%) scale(1) !important}
.slide{display:flex !important;flex-direction:column !important}
.controls,.toast,.edit-badge,.ov,.jump,.progress,.of-badge{display:none !important}

書体を揃えるパスでは、さらに次を注入する。

*:not(.sym){font-family:"BIZ UDPGothic","BIZ UDPゴシック",sans-serif !important}

:not(.sym) は、ひな型側で一部の文字に別の書体を当てたときに !important で潰さないためのもの。現在のひな型（v18以降）は .sym を使っていないので実質的な効果はないが、この形にしておくと将来ひな型側で書体を指定したときに変換へ届く。

地雷1：--stage-scale　ひな型のスクリプトは deck.style.setProperty('--stage-scale', s) でインラインstyleに書く。インラインstyleはスタイルシートより優先されるため、!important を付けないと上書きできない。これを忘れると、ウィンドウサイズによって出力PPTXの座標が変わるという再現しづらいバグになる。

地雷2：display:none　.slide は .active のときだけ display:flex になる。そのままでは非表示スライドの getBoundingClientRect() が全部0を返す。1枚ずつ .active を付け替える方法もあるが、各スライドは position:absolute; inset:0 で .deck 上に独立してレイアウトされるため、全部同時に表示しても互いに干渉しない。視覚的に重なるだけで測定値は正しい。1パスで済むこちらを採用した。

地雷3：srcdoc のオリジン　file:// で開いた親から iframe.contentDocument にアクセスできるか懸念があったが、srcdoc は親と同一オリジンとして扱われるため問題なく動作する（検証済み）。

3.3 分類ルール

section.slide 自身を先頭に記録してから、子を再帰的に走査する。

地雷4：図形とテキストを排他にしてはいけない　初版は shape と text を排他にしていたため、背景を持つテキスト要素（実測でv13の135要素中59個、4割）が図形として認識されず、円とカプセルが1つも検出されなかった。PowerPointの図形はテキストを持てるため、1オブジェクトにまとめるのが正解。編集時に枠を動かすと文字が追従するという実利もある。

地雷5：透明なレイアウト用コンテナを図形化しない　背景も枠線もない div（Grid/Flexのコンテナ）を図形にすると、PowerPoint上に透明な四角が数十枚積み重なり、クリックのたびに空の図形を掴む使いにくい資料になる。3行の判定で防げるが、入れ忘れると実用性が大きく落ちる。　文書モードの .doc-page と .doc-sec も背景・枠線を持たないため、この判定によって図形化されず素通りする（設計どおり）。

地雷6：インラインSVGがテキストに飲み込まれる

<div class="role" data-editable><span><svg>…</svg></span>役割名</div>

.role は直下にテキストを持つため text と判定され、子に降りない。結果、中のSVGが消える。テキスト分解時に querySelectorAll('svg') で別途拾う必要がある。 実測で10件が失われていた。

地雷7：section.slide 自身も測る　子だけを走査すると、.slide::after のページ番号（content:attr(data-no)）が取れず、スライド単位のはみ出し判定もできない。

3.4 形状判定

border-radius が全角 50% 以上（％指定）        → ellipse
最大半径 ≦ 0.5px                              → rect
最大半径 ≧ 短辺の半分                          → 正方形に近ければ ellipse、横長なら capsule
それ以外                                       → roundRect（adj = 半径 ÷ 短辺の半分 × 50000）

地雷8：border-radius:50% は getComputedStyle が "50%" のまま返す　parseFloat("50%") は 50 を返すため、偶然 50px として動いてしまい、バグに気づきにくい。% を検出して分岐すること。

「正方形に近い」の判定は |w - h| ≦ max(w,h) × 0.08 としている。

3.5 テキストの分解

段落の配列に分解し、各段落をランの配列にする。

• <br> で段落を割る
• display:block の子要素でも段落を割る（地雷9）
• <strong> などはランとして太字・色・サイズ・書体を個別に持たせる（地雷21）
• <ul> は li ごとに1段落＋ビュレット
• <svg> は {icon:true} のマーカーとして位置を保持する

地雷21：ランごとの font-family を捨てない　当初 styleOf() が拾っていたのは太字・色・サイズだけで、font-family を見ていなかった。文中で書体を変える書き方（<span style="font-family:…">）が、変換で黙って消える。計測側で cs.fontFamily を記録し、生成側でラン単位の fontFace として渡すこと。書体名は font-family リストの先頭を採り、それが既定（BIZ UDPGothic）なら指定しない。この修正は §1.2 の誤診の過程で入れたものだが、誤診とは独立した取りこぼしなので残してある。

地雷9：display:block な <strong>　ひな型の .reasonbox は <strong>見出し</strong>説明文 という構造で、CSSで strong{display:block} になっている。画面上は2行に見えるが、<br> がないため素朴な実装では1行に潰れる。ブロック要素でも段落を割ること。

なお文書モードの .doc-item（<strong>01｜見出し</strong>　説明文）は、strong をインラインのままにしてある。1段落の中で先頭だけ太字になるのが正しいためで、地雷9の逆のケースである。strong を block にするかどうかが、そのまま段落を割るかどうかになると理解しておくとよい。

3.6 判定フラグ

地雷10：見切れ判定の閾値　閾値なし（1px単位）にすると誤検知が大量に出る。原因は遊ゴシックの行ボックスが指定行高より背が高いこと。1行しかない見出しでも scrollHeight が1〜3px超過する。実測でv13が8件、v4が29件の誤検知。閾値3pxを入れたうえで、BIZ UDPゴシックに差し替えた側では両ファイルとも0件になることを確認済み。BIZ UDPゴシックのほうが縦方向の圧迫が少ない。

地雷11：入れ子の箱 は text 系にだけ適用する　全種別に適用すると、shape（カードの中に子ボックスがある正常な構造）で誤検知する。実測でv13が7件、v4が14件すべて誤検知だった。

4. 生成（PPTX側）

PptxGenJS 4.0.1 を使用（MITライセンス、JSZip同梱、bundle版 460KB）。

4.1 対応表

4.2 テキストボックスの設定

margin: [左, 上, 右, 下]   // pt。CSSのpaddingは[上,右,下,左]なので並べ替える
fontFace: 'BIZ UDPGothic'
fontSize: px × 0.6
charSpacing: letterSpacing(px) × 0.6
lineSpacing: computed line-height(px) × 0.6   // pt。倍率指定は使わない（地雷19）
align:  text-align。Flex/Grid なら justify-items / justify-content（地雷18）
valign: vertical-align。Flex/Grid なら align-items / align-content（地雷18）
fontFace: ランごとに font-family の先頭を渡す（地雷21）
fit: 'none'                // 自動調整オフ
wrap: HTMLで1行だったなら false

地雷12：PptxGenJS の margin 配列は [左, 上, 右, 下]　CSSの [上, 右, 下, 左] とは違う。そのまま渡すと左右の余白が上下に入る。生成XMLの lIns/tIns/rIns/bIns を直接読んで発覚した。表のセルの margin も同じ順序。

地雷13：HTMLで1行だった文字がPowerPointで折り返す　ブラウザとPowerPointの禁則処理の差で、境目の1文字が送られる。フォントを揃えても完全には一致しない。対処：段落数が1で、要素の高さが1行分（line-height × font-size × 1.35）以内なら wrap: false にする。これで折り返しが起きない。表紙の「DX戦略部」が2行になる事象がこれで解消した。

地雷18：Flex/Grid の寄せは、主軸と交差軸を水平・垂直に読み替える　display:grid の要素で、その要素自身の中身の寄せを決めるのは justify-items / align-items である（place-items:center はこの2つに展開される）。justify-content ではない。display:flex では flex-direction:column のとき主軸と交差軸が入れ替わり、水平が align-items、垂直が justify-content になる。当初は水平方向を text-align だけで判定していたため、ひな型の丸数字（.layer-num、place-items:center）が円の中で左寄せになっていた。縦は合っていて横だけずれる、という形で現れる。

地雷19：行間は倍率ではなく実寸(pt)で渡す　PptxGenJS の lineSpacingMultiple は <a:lnSpc><a:spcPct> になる。PowerPointの百分率指定は、フォントサイズに対する倍率ではなく「書体が持つ既定の行送り」に対する倍率である。 和文書体の既定行送りは字面の1.15〜1.3倍あるため、CSSの line-height:1.2 をそのまま120%として渡すと行が26%ほど高くなり、文字が下へずれる。lineSpacing（pt指定、<a:spcPts>）を使い、line-height(px) × font-size × 0.6 を実寸で渡せばCSSと一致する。実測：.layer-priority（156.38×28.39、17px/1.2、padding 4/11）で、文字が下へ6px・右へ5pxずれ、カプセルから descender がはみ出していた。図形の寸法も文字の幅も一致しており、位置だけがずれるのが特徴。

地雷22：角丸図形は文字の領域が内側に食い込む　OOXMLのプリセット図形 roundRect は、図形の外形とは別に文字用の矩形を定義しており、角の丸みのぶんだけ四方から内側に寄っている。

食い込み = 角の半径 × 29289/100000  ≒ 半径 × 0.293

lIns=12px と指定しても実際の描画開始位置は 12 + 食い込み になる。あらかじめ差し引いてインセットを渡すこと（0未満は0に丸める）。

実測：高さ33pxのカプセル（半径16.5px → 食い込み4.8px）で、文字が右へ6.3px・下へ6.7pxずれていた。補正後は左12.6 / 右11.4 / 上5.7 / 下8.0 px（CSSの指定は左右11・上下4）。

縦横がほぼ同量ずれるのがこの現象の見分け方。行間の問題なら縦にしかずれない。

この食い込みはPowerPointが描画するときに適用されるもので、生成XMLには現れない。「生成XMLを読んで検証する」という原則が使えない数少ない箇所であり、見た目で判断するしかない。係数0.293はプリセット図形の定義から採った値で、実機で妥当性を確認済み。

右寄せ1行テキストの右インセット（未確認の制約）

padding-right は margin の第3要素として右インセットに正しく渡している。にもかかわらず、右寄せ1行のテキストでは変換後に右インセットが効かず、ページ番号と重なる事例が出た（ひな型v19a の出典行）。

isSingleLine() が真になると wrap:false（OOXMLの wrap="none"）が付くため、PowerPoint が折り返し用の矩形を無視して右インセットを効かせない、というのが現時点の推測だが、確認していない。

回避策として、ひな型v19b 以降は出典を左寄せにしている（ルール【10】）。isSingleLine() は地雷13（ブラウザとPowerPointの折り返し位置の差で2行になる）への対処として入れたものなので、ここを触るときは地雷13の再発に注意すること。

4.3 図形

• 塗り：backgroundColor の alpha を transparency（0〜100）に変換
• グラデーション：PptxGenJSに塗りのAPIがない（検証済み。テーマ内でしか gradFill を使っていない）。そのため、生成後のPPTX（ZIP）を開いてスライドXMLを直接書き換える方式で対応した（地雷14）
• 影：box-shadow から距離・角度・ぼかし・不透明度を算出して outerShdw に
• 片側ボーダー：PowerPointの図形は四辺一括の枠線しか持てない。枠線なしの本体＋細い矩形（各辺）に分解する。実測でv13が7本、v4が2本
• この分解は shapeText（文字を持つ要素）でも正しく働く。v22の文書モードは見出しに border-bottom を使っており、実機変換で問題なく分解されることを確認済み（§6.10）

4.4 表

• 行×列のグリッドを先に構築する。colspan/rowspan は占有マスを埋める方式。OOXMLでは結合された側のセルも存在するため、HTMLのように「無い」扱いにするとファイルが壊れる（検証済み：3行×4列に colspan=2・rowspan=2・colspan=3 を混在させて正しく展開されることを確認）
• 罫線はセル4辺を個別に読む。CSSの border-right + :last-child で打ち消すイディオムに引きずられない。getComputedStyle は打ち消し後の値を返す
• 列幅・行高は宣言値ではなく実測値（1行目・1列目から取得）
• 全セルに明示的な塗りと罫線を書く。PowerPointの既定テーマスタイル（縞模様）が効いてしまうため
• PowerPointの表の行高は指定値を下回らないが、内容が入りきらなければ勝手に伸びる。無効化できない。ユーザー判断により、はみ出し警告は実装しない（そのまま出力する）

4.5 グラデーション（地雷14）

PptxGenJS の objectName オプションで図形に目印を付けておき、pptx.write() の後にJSZip（PptxGenJSのbundle版に同梱、window.JSZip で参照できる）でZIPを開き、ppt/slides/slideN.xml の該当図形の <a:solidFill> を <a:gradFill> に差し替える。スライド背景は <p:bgPr> の中を差し替える。

角度の換算に注意。 CSSは「上向きが0度・時計回り」、OOXMLは「右向きが0度・時計回り・60000分の1度単位」。

ooxmlAng = ((cssDeg - 90) mod 360) × 60000
例：css 135deg → ooxml 45度 → ang="2700000"

色停止の位置は pos（10万分率）。位置未指定のストップは等間隔で補完する。rgba() の透過は <a:alpha> で表現できる。

安全性の設計。 目印が見つからない・XMLが想定と違う場合は何もせずに単色のまま通す。変換ツール側も、この処理が例外を投げたら通常出力にフォールバックする。したがってこの機能が原因でPPTXが壊れることはない（最悪でも単色に戻るだけ）。

検証済み：v13で2件、v4で5件を適用し、python-pptxで開けること・ZIP整合・全XMLのパースを確認。LibreOfficeでの描画も目視確認済み。副次的に、JSZipで再圧縮されるためファイルサイズが 257KB → 37KB に減った。

4.6 SVGアイコン（地雷15）

PptxGenJS のSVG埋め込みは使ってはいけない。 addImage に image/svg+xml を渡すとOffice 2016 の asvg:svgBlip 拡張を出力するが、PNGフォールバックとして書き出すファイルの中身がSVGのままになる（ppt/media/image-N-1.png の先頭が <svg xml）。検証済み。PowerPointが修復を求める可能性があるため採用しなかった。

代わりに、ブラウザ自身のレンダラでPNGにしてから貼る。

1. 計測時に serializeSvg() でSVGを単体で完結した文字列にする。stroke:currentColor は文書外では解決できないため、計算済みの値を各要素の属性として焼き込む（fill stroke stroke-width stroke-linecap stroke-linejoin opacity）。xmlns と width/height も付ける
2. 変換時に Image + canvas で 8倍に描いて toDataURL('image/png')
3. addImage でPNGとして貼る

ラスタライズに失敗したアイコンは挿入しないだけで、他には影響しない。

地雷16：アイコン分の字下げ　アイコンは幅24px＋右余白8pxの計32pxを占める。テキストボックスの左インセットを0のままにすると、文字がアイコンに重なる（実際に重なった）。計測時に Range で最初の非空テキストノードの左端を実測し（textStartX）、生成時に左インセットをそこまで広げる。CSSの margin-right や gap を推測せずに済むので、どのレイアウトでも正しく合う。

地雷17：Range.getBoundingClientRect() は複数行だと使えない　地雷16の実測に getBoundingClientRect() を使うと、折り返した要素だけ字下げが効かない。このメソッドは複数行にまたがる範囲に対して全行を囲む1つの矩形を返す。2行目はアイコンの下、つまり要素の左端から始まるため、left が左端になってしまう。

折り返しなし → 正常（1行しかないので union = 1行目）
折り返しあり → left が 0 になり、字下げなし＝アイコンと文字が重なる

getClientRects() の先頭（＝1行目の断片）を使うこと。実機のPowerPointで、1行の見出しだけ正常・2行の見出しが重なる、という形で発覚した。症状が要素によって出たり出なかったりするため、原因を見誤りやすい。

4.7 未対応

5. 実測値（検証済み）

2つのデッキで確認した数値。改修後の回帰確認に使える。

5.1 v13（現場主導型AI 役員説明資料、5枚）

ステージ           1600 × 900（誤差0）
要素               135
  図形のみ          18
  図形＋文字        59
  テキストのみ      57
  表                 1（5行×8列、40セル、結合なし）
  SVG                0
疑似要素             6（ページ番号5＋その他1）
data-editable      159
形状  roundRect 61 / rect 8 / capsule 5 / ellipse 3
片側ボーダー        7
生成PPTX           257 KB

5.2 v4（AIによるデータ分析業務の高度化、8枚）

要素               180
  図形のみ          20
  図形＋文字        67
  テキストのみ      83
  SVG               10（すべてインライン）
疑似要素            14
形状  roundRect 72 / rect 2 / capsule 10 / ellipse 3
片側ボーダー        2
生成PPTX           252 KB

5.3 フォント差し替え（遊ゴシック → BIZ UDPゴシック）の影響

                        v13        v4
位置が動いた要素      115/135    139/170
 うち15px以内           110        138
寸法が変わった要素     37/135     60/170
 うち1px以内             98        110
最大の幅の変化         +34 px     +95 px   （字送り付きの欧文）
最大の高さの変化      +25.6 px   +39.8 px
スライド外              なし       なし
見切れ（現行→BIZ）     8 → 0     29 → 0

移動の大半はFlex配置の連鎖によるもので、スライドからのはみ出しは発生しない。差し替えは縦方向の圧迫をむしろ減らす。注意すべきは字送り付きの欧文が横に伸びる点（.tag などのバッジ）。カプセル型は背景も伸びるため破綻しない。

6. ひな型（現行：スライドひな型_v24b_DADS_緑.html／_青.html、教材ひな型_v1.1a.html、報告資料ひな型_v2.1b.html、イメージ図ひな型_v1.3.html）

6.0 スライドひな型の系譜と、v22 の廃止

この章の §6.1〜§6.11 は、スライドひな型 v14〜v22 を作ってきた経緯である。v22 は 2026-09 に廃止したが、そこで決めた骨格・型カタログ・文書モード・作業ルールは、そのまま現行の DADS準拠版に引き継がれている。現行版の「なぜこうなっているか」は、§6.1〜§6.11 を読めば分かる。以下、本文中の「v22」は、その時点での最新版を指す。

v23 の内容（DADS準拠）

• 色は :root のトークンだけで決め、値は DADS のプリミティブカラーから選ぶ。キーカラーは緑版が Green-800（#197a4b）、青版が Blue-900（#0017c1）。変数名の --blue --cyan は、変更禁止の deck-fix が参照しているため、緑版でも名前だけ残している
• 文字と背景のコントラストは、文字サイズにかかわらず 4.5:1 以上。補足文字は --muted（#666666）より薄くしない
• 文字サイズ・行高は DADS の段階値（16/17/18/20/22/24/26/28/32/36/45/48/57/64px、行高1.2〜1.7）から選ぶ。太さは 400 と 700 だけ
• 影とグラデーションを廃止し、平面の塗りと罫線で表現する。表の角丸は 0
• 書体は BIZ UDPゴシックのまま（DADS は Noto Sans JP だが、変換で書体を一致させるため）
• 守るべき規則はひな型の【12】にまとめた
• チェッカーの基準線は v22 と同じ（エラー0・警告3）。変換ツール・チェッカーの改修は不要だった（§1.3(a) のとおり、クラス名ではなく計算結果を読むため）

v24 の内容

• 型④（.t-par）の余った高さを、カード帯の上下ではなくカード自身に吸収させる（align-content:center → stretch）
• 密度プリセット density-low／density-high で、文字サイズの変数を一式で切り替える
• 【5】に情報量の下限（本文エリアの7割）と、足りないときの手順（density-low → 型の見直し → 統合）を追加

v22 で作った資料の扱い：既存の資料はそのまま変換・検査できる（仕様版 meta が 2026-09 で、チェッカーはスライドモードで検査する）。新しく作る資料は v24b を使う。

保護領域（deck-fix-style / deck-fix-script / @media print）は、各版で意図した箇所以外が変わっていないことを、元ファイルとの差分で確認している。

6.1 v13 → v14

1. html,body の font-family を BIZ UDPGothic に（宣言は1箇所のみ）
2. <meta name="slide-spec-version" content="2026-09"> を追加する予定だった
3. .role-highlight の <div><br/></div>（contenteditableの残骸）を除去
4. 【0】保護領域に font-family と meta を追加
5. 【7】セルフチェックに変換対応の3項目を追加
6. 【8】に変換手順を追記
7. 【9】PowerPoint変換のための構造ルールを新設

【9】の冒頭に「変換ツールはCSSの書き方そのものは読んでいない」と明記している。これがないと、生成AIが変換を気にして表現を萎縮させるおそれがあるため。

2 は実際には入っていなかった。【0】の説明文の中に文字列として出てくるだけで、head には無い状態がv17まで続いていた。v18で追加している（§6.4）。この文書に「対応した」と書いてあっても、ファイルを確認すること。

6.2 記号の書体（v16で追加し、v18で撤回）

BIZ UDPゴシックに無い記号に別書体を当てる .sym を導入したが、そもそも問題が存在しなかったため撤回した。経緯は §1.2 を参照。

現在のひな型に .sym はない。記号はすべてBIZ UDPゴシックで描画され、変換後も正しく収まる（検証済み）。

6.3 line-height をグローバルに指定してはいけない

.sym を導入する過程で、書体が変わっても行の高さが伸びないようにする目的で html,body{line-height:1} を入れた（v15）。ブラウザ上の見た目は変わらず、はみ出しチェックも0件だったため無害と判断したが、変換すると壊れた。

原因は2つの組み合わせである。

• ひな型には line-height を指定していない要素が28個ある。normal のままなら変換器は行間を渡さず、PowerPoint既定の行間になる
• そこへ line-height:1 が継承されると、地雷19の実寸指定によって行間ちょうど1emが渡る

該当したのはスライド03右パネルの ul で、HTMLでは flex-direction:column; justify-content:space-evenly により6項目を459pxの箱いっぱいに配分している。行間で間隔を作っていない。 それが96pxに詰め込まれ、行が重なった。

教訓：ブラウザ上の見た目が変わらないことは、変換後の見た目が変わらないことを意味しない。 ひな型のCSSを触ったら、必ず変換まで通して確認すること。

なお、このとき「BIZ UDPゴシックの既定の行送りは1.0倍」と推定したが、根拠にした要素はすべてFlex/Gridで高さが決まっていた。行ボックスの高さを測ったつもりで、レイアウトが決めた高さを見ていた。line-height 未指定の要素の高さから書体の metrics を逆算してはいけない。

6.4 v18 の内容

v15〜v17で加えた変更（line-height:1、.sym）はいずれも撤回したため、スライドの表現に関わる部分は実質 v14 と同じである。今回の一連の修正は、すべて変換ツール側で完結した。

あわせて、ひな型として使うための整備を行った。v14〜v17は生成済みデッキをそのまま流用していたため、ひな型としての体裁が欠けていた。

1. <meta name="slide-spec-version" content="2026-09"> を head に追加（v14〜v17には入っていなかった）
2. <title> を「スライドひな型 v18」に
3. 冒頭コメントに版と、変換ツール v0.6.1 と対で運用する旨を明記
4. 【0】保護領域に「複製して資料を作るときも meta を残すこと」を追記
5. 【7】セルフチェックに2項目追加（metaを消していないか／titleを資料名に変えたか）

スライド5枚の内容はそのまま残してある。今後パターンを増やしていく際の出発点として使う。抽象的なルールより具体例のほうがAIには効く。ただし社内の具体的な内容が埋まっているため、外部に渡す場合は文言の差し替えが必要になる。

6.5 v19 の内容 ― 骨格と型カタログ

ひな型の中身を充実させる作業の第1弾。AIに渡すのは構文（壊れない書き方）だけで、語彙（何をどう書くか）が無かったため、レイアウトを毎回ゼロから発明していた。

きっかけは、経産省の公開報告書（351ページ）を1枚ずつ分類したところ型が7つしかなかった、という外部記事。ただし分析対象は読ませる提出用の報告書であり、比率をそのまま目標にはしていない。投影して自分で話す資料では、拾い読みする読者層が存在しないため、必要な骨格が違う。型のカタログとしてのみ採用した。

骨格は次の2段構成とした。

記事が推奨する「リード帯（主張を1行で言い切る青帯）」は採らなかった。投影用ではリード帯とヘッドメッセージが内容の繰り返しになり冗長になる。ただし1枚だけ単独で回覧される可能性があるページ用に、任意の部品として残してある。

代わりに、リード帯が担っていた役割をルールで回収した。「ヘッドメッセージの各行は体言止めにせず、述語のある文で断定する。名詞の羅列はサマリではなく目次である」。

ヘッドメッセージの装飾は、白カード＋四辺枠線を採用した。左罫線案（片側ボーダー）は、§4.3 のとおり変換後に本体と線用の細い矩形の2オブジェクトに分解されるため、PowerPoint側での編集が面倒になる。四辺枠線なら角丸矩形1つで済む。

型カタログは3種。（v21で型④を追加し4種になった。「迷ったらこれ」も廃止した ― §6.9）

②データチャートは、グラフ自体が §4.7 のとおり変換対象外のため見送った。記事の主張も「グラフは証拠品で、価値があるのは横に置く注釈のほう」なので、枠だけ用意してグラフは変換後に挿入する形になる。④⑤⑥は第2弾とした（④はv21で実装。⑤⑥は未着手 ― §6.9、§7）。

箇条書きの行頭記号でつまずいた。 当初「::marker は疑似要素だから転写されない」と考えて ■ を実文字で書いたところ、変換後にビュレットと二重になった。変換ツールは ::marker を読むのではなく、<ul> という要素の存在から独自にビュレットを生成している（§3.5）。現在は行頭記号を書かず、PowerPoint側のビュレットに任せている。記号を変えたいときは変換後に段落を選んで差し替える。

6.6 v20 の内容 ― CSSの整理とトークン層

未使用CSSを削除し、CSSルールは287本から226本に減った（v20で57本、v20aでさらに4本）。セレクタに含まれるクラスがすべて未使用で、どの要素にも当たりようがないものだけを対象にしている。.slide[data-no="03"] .card:before のように、.card が存在しないため死んでいたルールも含まれる。削除しても表示は変わらない。

トークン層を導入した。文字サイズと余白を :root の変数に集約し、共通部品と型カタログから参照する形にした。色は元から変数だったので、サイズ側が追いついた形になる。

あわせて【10】に次の決まりを入れた。

○ .slide[data-no="07"]{--fs-cell:19px}
× .slide[data-no="07"] .t-arg tbody td{font-size:19px}

個別調整は変数の再定義のみとし、プロパティを直接指定しない。v18では h3 の指定が 29px・28px・28px・27px と4通りに分かれていたが、この差に設計意図はなく、840pxに収めるための微調整が沈殿したものだった。!important を積むのと同じ現象が、data-no スコープという別の形で起きていた状態である。

アクセントバーを実要素にした。.reason-title:before の7×28pxの青い縦棒は疑似要素だったため変換後に消えていた。ここは注意が要る。バーを .reason-title の子にすると、今度は「文字を持つ要素の中に背景を持つ子要素」という別の違反になる（【9】）。.reason-head というコンテナを挟んで兄弟にしてある。

6.7 参考デザインの扱い（ルール【11】）

02〜05は元デッキ由来のスライドで、型としては未整理のまま残してある。デザインの質は高く、④絵解き・⑤フレームワークに整理する際の素材になる。

ただしこのまま置くとAIが「使えそうなクラスがある」と判断して流用する。型として整理される前に流用されると、また出自の分からないCSSが増えるため、【11】で「02〜05のCSSを新しいスライドに流用しない。使いたい場合は相談する」と明示した。

v21で02〜05のCSSを整理した。位置づけは「参考デザイン集」として変えず、見た目も変えずに、残骸だけを落としている。

• HTMLのどこからも参照されていないルール30本を削除（.grid2 .box .effect .panel .q .arrow .num .most .criterion-line .dept-step-image .think-icon ほか。以前の版のスライドが残していったもの）
• .slide[data-no="04"] .layer{…} のようなスライド個別指定48本を、クラス側へ統合。そのスライドでしか使われていないクラスに限定して接頭辞を外している
• 結果、個別ルール数は 02が21本→2本、04が37本→4本。【3】の20本制限を大きく下回った
• 【9】違反だった .role-panel:nth-child(2) ul の space-evenly を、行間と余白で間隔を作る形に置き換え（§7の積み残し3を解消）
• .criterion-item の min-height:54px をパディングに変換

統合前後で宣言が1つも失われていないことを、機械的な突き合わせで確認した。欠落は上記2件の意図的な変更のみ。宣言の位置が前方から後方へ動く箇所20件についても、間に挟まるルールがすべて詳細度で上回るか、別の要素を指していることを確認している。スライドのHTMLと保護領域は無変更。

6.8 チェッカー（html-slide-lint-v0_3.html。v0.4 は §6.12）

ひな型のルール【0】【2】【3】【4】【9】【10】【11】に対応した静的解析ツール。検査は端末内で完結する。id="deck-fix-style" は保護領域のため対象外（!important が55個あるが、それが正しい設計であるため）。

検査項目

誤検知を避けるための絞り込みを入れてある。幅も高さも固定された小さな要素はアイコン・バッジとみなして高さ検査から除外し、.progress のようなUI部品はスライド本文と区別して対象外にしている。この絞り込みを入れる前はエラーが24件出ていたが、実際に直すべきものは8件だった。

表の角丸は「情報」に落としてある。PowerPointの表は角丸にできないが、ブラウザ上の見た目を優先してあえて残す判断をしたため。

検算　v18 を読ませると、手作業で見つけた不具合（存在しないスライド06〜08を指すルール31本、宙ぶらりんセレクタ1件）をそのまま検出する。v20a ではこの2グループが0件になる。v21 と v22 ではエラー0件・警告3件（.table のセル高さのみ）になる。

v0.2 の内容

1. 型カタログが06〜09になったため、案内文を修正
2. 参考デザイン検知の対象を拡張。v0.1 は ai3- dept- role- layer- などの接頭辞しか見ておらず、thinking think-item product-tag use-chip reasonbox nextline nstep who accent-bar などが素通りしていた。逆に legend table grade-* は型③でも使うため対象から外している
3. 除外条件の穴を塞いだ。 v0.1 は「2〜5枚目は参考デザインだから検査しない」と番号で決め打ちしていたため、資料のHTMLでも2〜5枚目が検査対象外になっていた。資料では2〜5枚目はただの本文スライドである。v0.2 は <title> に「ひな型」を含むファイルのときだけ、その4枚を除外する
4. 画面の表示崩れを修正。ドロップ領域の <label> に display:block が無く、インライン要素の上下パディング（34px）が前後の文章の行に重なっていた。中の <strong> だけがブロックだったため、枠が途中で切れて右にずれてもいた。v0.1 からの不具合

v0.3 の内容

1. 文書モードへの対応。案内文とヒント文を「型カタログ06〜09／文書モード10」に更新。検査結果の見出しに、文書モードのページ数を出すようにした
2. 【10】の検査を1本追加。文書モードのページにスライドの型が混入していたらエラーにする。詳細と設計判断は §6.11

検証方法　v0.2 は jsdom で headless 実行して確認した。v0.3 は headless Chromium でツールのHTMLを読み込み、inspect() を直接呼んで確認している。いずれにせよチェッカーの判定ロジックを別に書き直して照合するのではなく、ツールそのものを動かすこと。再現を書くと、再現側の取りこぼしに気づけない。実際、v0.2 のとき再現スクリプトは data-editable の付け漏れ6件（02の「＋」、03の「▶」2つ、04の「•」3つ）を見落としており、本体を動かして初めて出た。

v0.3 では3本のファイルを通している。ひな型v22（基準線＝エラー0・警告3）、検知テスト（文書ページに .head-msg と .par-note を混入 → エラー1件、該当3クラスを列挙）、誤検知テスト（文書ページに .table .grade-good .legend を正当に使用 → エラー0）。検知テストと誤検知テストを対で作ること。片方だけでは、何も検出しない実装も、何でも検出する実装も通ってしまう。

限界　機械で判定できるのは書き方の規約であって、何を書いたかではない。「ヘッドメッセージが体言止めの羅列になっていないか」「型の選択が内容に合っているか」は【10】の中身に関わる部分であり、人間が見る領域として残る。

6.9 v21 の内容 ― 型④と、型の選び方

きっかけは、ミャンマーの生保業界を調べて v20a で作らせた18枚の資料である。本文14枚が例外なく型①論証テーブルになり、うち11枚に「備考」列があった。5・6・8・14枚目は本文2行で、備考列の中身は「業界横断」の4文字だけ。.t-arg は1列目300px・2列目440pxを指定し3列目に幅指定が無いため、残り約730pxがその4文字に割り当てられていた。

ひな型のデザインではなく、ひな型の中のルールが原因だった。

• 本文で使える型が①③の2つしかなく、どちらも表だった。骨格の説明も「ボディ　表・図はここだけ」で、「図」に対応する型もCSSも用意していなかった
• 「迷ったら型①です」が既定値として働いた。調査報告は課題→打ち手ではないのに、迷ったときの受け皿が型①しかなかった
• 逃げ道が「相談してください」だけだった。作業を止める選択肢しか無いため、AIは型①に当てはめるほうを選ぶ。18枚分繰り返せば全滅する
• 型①のtheadが3列（課題／現状／打ち手）だった。打ち手の無い内容でも3列目の器が残り、行き場のない出典が「備考」という名前でそこに入った。【10】には .source があるのに、デッキ全体で1回しか使われていない
• 【7】のチェックリストが片側にしか効かなかった。「表になる内容を <table> で書いたか」はあるが、「表にすべきでない内容を表にしていないか」は無い。【5】の「縦7行×横8列まで」も上限だけで下限が無く、2行×3列の"表"が全項目を通過した

対処は4点。

1. 型④ 絵解き（並列）を新設（.t-par）。カード2〜3枚を並べる型。枚数は grid-auto-flow:column に任せるので個別指定は要らない。余った高さは align-content:center でカード帯の上下に等分し、カード最下段（.par-note）は margin-top:auto で3枚の下辺をそろえる。文字サイズは --fs-par-title / --fs-par-li としてトークン化した（§6.6の方針）。02のCSSは流用せず、型として書き直している
2. 型の選び方を、内容の関係で判定させる。比較→③、因果→①、並列→④。「調査報告・現状説明・用語整理はほとんどが並列」「打ち手の無い内容を型①に入れると3列目が備考という空き箱になる。これは失敗」と、起きたことをそのまま明記した。型①を選ぶ前に、打ち手の列に書く内容が実在するか確かめる一文も入れている
3. 表の下限を【5】に追加。本文3行以上、かつ全列に固有の内容が入ること。本文2行以下／1列が出典・区分ラベルだけ／実質2列で3列目の名前をひねっている、のいずれかに当てはまるものは表にしない。出典は列ではなく .source に出す
4. 【7】に逆向きのチェック項目を追加。「表にすべきでない内容を表にしていないか」「本文スライドの型が型①に偏っていないか」

結果　同じ資料を v21 で作り直したところ、表は16個から4個に減り、本文14枚のうち11枚が型④になった。残った表も、4列の比較（型③として妥当）と、本文3行で3列目に実質的な内容が入るもの（下限クリア）だけである。

ただし失敗は形を変えて残った。多くのカードの .par-note が「業界横断」「個社」だけになり、備考列がチップに引っ越しただけの状態になった。14枚目は2枚とも「個社」で完全に同じである。そのため【10】に「.par-note はカードごとに異なる内容があるときだけ置く。全カードが同じ値になるなら .source にまとめる」を追記し、【7】にも確認項目を足した。空き箱は、器を変えても空き箱である。

あわせて参考デザイン（02〜05）のCSSを整理し、data-editable の付け漏れ6件を解消した（§6.7、§6.8）。ひな型をチェッカーにかけると、エラー0件・警告3件になる。

6.10 v22 の内容 ― 文書モード

何を解いたか

ひな型は投影用スライドしか作れなかったが、実務では「シンプルなレポートをPPTXで出したい」場面がある（報告メモ、議事メモ、概要説明）。これをスライドのレイアウトに当てはめると、§6.9 と同じ失敗（器があるからAIが埋める）を別の形で繰り返す。

ファイルを2本に分けなかった理由

レポート用のひな型を別ファイルにする案は却下した。共通部分が「高いほう」だから。

加えて「ひな型と変換ツールは対」という運用が「ひな型2種×変換ツール」に増え、版ずれの面が倍になる。

ただし将来分割できる余地は残した。 文書モードのCSSはスタイルの末尾に /* v22 追加：文書モード（doc）ここから 〜 ここまで */ の1ブロックで隔離してある。分割も削除も切り取り1回で済む。統合を選んだ理由の半分はこれである。混ぜて書くと、分割が不可逆に高くなる。

設計判断

ステージは 1600×900 のまま。 A4比率で作り直さない。PowerPointの用紙はどのみち16:9になるため、HTML側で紙の比率を作っても変換後に戻る。変えると変換ツールの健全性チェック（ステージ実測が1600×900か）と120px=1in換算に手が入る。読みやすい行長は、ステージではなく余白で作る。

左右の余白は .doc-page で作る。.slide の padding は触らない。 @media print が .deck .slide{padding:32px 56px 28px!important} で戻すため、.slide.doc に余白を書くとPDF出力のときだけ行長が変わる。保護領域なのでそちらは直せない。実測値は .doc-page が max-width 1392px・左右 padding 48px で、本文幅 1296px。

見出しの下線は border-bottom。 片側ボーダーなので §4.3 のとおり「枠線なしの本体＋細い矩形」の2オブジェクトに分解されるが、下線を別要素にしてもオブジェクト数は同じ2つになるため、単純なほうを採った。§6.5 でヘッドメッセージに四辺枠線を選んだのとは状況が違う（あちらは1オブジェクトで済む代案があった）。実機変換で正しく分解されることを確認済み。

縦は上詰め。 文書は下に余白が残るのが正しい状態なので、【2】の「伸ばして配る」は文書モードに適用しない。これを明記しておかないと、AIが space-between で行間を引き伸ばす。

部品は6つだけ。.doc-title / .doc-h / .doc-p / .doc-item / .doc-list / .doc-note。§6.9 の「器を用意すると、AIは中身が無くても埋める」を踏まえ、最小セットに絞って使いながら足す方針にした。

モードの決め方 ― 推測させず、指示に従わせる

当初は「内容の関係でAIに判定させる」形（型の選び方と同じ作り）にしていたが、運用に合わせて「指示があったときだけ文書モード」に変更した。

既定                                → スライドモード
ユーザーが文書モードを指示したとき  → 文書モード（.slide.doc）

• 指示がなければ常にスライドモード。「レポート」「メモ」「報告書」という言葉が会話に出てきても、それだけでは切り替えない。確認の質問もしない
• 指示があれば例外なく文書モード。見栄えを理由にスライドの型へ引き戻さない
• 指示の範囲だけを文書モードにする。1つの資料の中での混在は可

なぜ推測をやめたか。モードは内容から決まらないためである。同じ「研修の概要」でも、投影するのか読ませるのかで答えが変わり、それを知っているのは人間だけである。型の選び方（比較／因果／並列）は内容から決まるので判定させてよいが、モードは性質が違う。判定できないものを判定させると、§6.9 と同じで既定値のほうへ機械的に倒れる。

実際、既定はスライドに強く倒れる。 ファイル冒頭が「このファイルはスライドテンプレートです」で始まり、収録10枚のうち9枚がスライドモードの見本である。§6.9 の「既定値と受け皿の数が、そのまま出力の偏りになる」がそのまま効く。運用（明示したときだけ文書）とは方向が一致しているので、この偏りは問題にならない。

検証結果

• 文書モードがスライドに混入しないことの実測。 文書モードのCSSブロックと10枚目を取り除いた版を作り、01〜09を v22 と画素単位で比較したところ9枚すべて完全一致。.doc-* はクラスで閉じており、カスケードで勝手に効くことはない
• 逆方向（誤用）の実測。通常スライドの h2 に .doc-h を付けると 42px → 23px・下線つきになり、見た目は崩れずそれらしく表示される。つまり誤用は目視では気づけない（§6.11）
• レンダリング。headless Chromium で全10枚。はみ出しは10枚目0件。10枚目の内容高さ 818px ／ 使用可能 840px（Noto Sans CJK JP での値。BIZ UDPゴシックはこれより縦の圧迫が少ないので余裕はさらに増える）
• チェッカー。エラー0件・警告3件で v21 の基準線と一致
• PPTX変換。実機で確認し、問題なしと判断した（見出しの border-bottom を含む）

6.11 モードの混在をどう扱うか（v22／チェッカー v0.3）

混在の許容は非対称である。

理由はスライドの視覚的な寛容さにある。スライドの見出しが42pxではなく23pxで下線つきになっても、「そういうデザインのスライド」に見えるだけで実害が出ない。逆に、文書ページにカードや型①の表、青い結論バーが1つ入ると、その時点で文書ではなくなる。文書モードは「スライドの装飾が無いこと」そのものが仕様なので、混入＝機能の喪失である。

検査は .slide.doc のページ内に次のクラスがあればエラーとする。

head-msg / msg / body-area / source / t-arg / t-cmp / t-par / par-* /
divider / chapters / chapter-no / question / eyebrow / cover / lead / tag / meta

除外に注意。.table と .grade-* .legend は文書モードでも使う設計なので検査対象に含めない。ここを間違えると、表を含む正当な文書ページがエラーになる。出典は .source ではなく .doc-note に書く（.source は検査対象）。

片方向にした判断を残しておく。両方向を検査するほうが一見きれいだが、許容すると決めた側まで検査すると、直す必要のない指摘が資料ごとに出続ける。チェッカーは「エラー0件が基準線」という運用で使うので、直さない指摘を出すと基準線そのものが意味を失う。検査項目を足すときは、それが出たら必ず直すか、を先に決めること。

6.12 報告資料ひな型 v1 と変換ツール v0.7.0（2026-09）

何を解いたか

部長が役員・社長報告用に作る資料（A4横の報告用紙、1テーマ1〜5枚）を、AIに同等の品質で作らせるためのひな型。分析の内容は Claude Docs「S農部長 報告資料の構成ルール分析」にある。スライドひな型 v22 を土台にし、ページ送り・編集・文字サイズ調整・はみ出し検知・一覧・HTML保存・PDF出力はそのまま引き継いだ。スライドの見本（表紙、参考デザイン02〜05、型カタログ06〜09、文書モード10）はすべて削除した。

ステージを A4横 にした（§6.10 の判断を、このひな型に限って覆した）

§6.10 では「A4比率で作り直さない」と決めていたが、報告資料は紙で配られるため、ユーザー判断で A4横 を採った。120px = 1in の換算は変えず、ステージを 1403×992px にした（11.69×8.27in ＝ A4横）。換算を変えないため、pt = px × 0.6 も、変換ツールの生成側の計算も、そのまま使える。

保護領域は数値だけを書き換えた。.deck の寸法、一覧サムネイル（.ov-frame 260×184、.ov-scaler scale .18532）、@media print の用紙・枠・余白、スクリプトの STAGE_W/STAGE_H。ロジックは1行も変えていない（元ファイルとの差分で確認済み）。

変換ツール v0.7.0 の変更（地雷23〜25）

地雷23：ステージ寸法の固定。v0.6.1 は STAGE_W=1600 と 13.3333×7.5in を計測側・生成側の両方に直書きしていた。v0.7.0 は変換元HTMLの <meta name="slide-stage" content="1403x992"> を読み、無ければ 1600×900 とみなす。スライド寸法・ページ番号の位置・健全性チェックの表示・プレビューの縦横比をステージから求める。スライドひな型 v22 を v0.6.1 と v0.7.0 で変換し、全10枚のスライドXMLがバイト単位で一致することを確認済み（後方互換）。

地雷24：下線が消える。部長資料は「認識してほしい事実」を黒の下線で示すが、v0.6.1 のランは太字・色・サイズ・書体しか持っていなかった。text-decoration は継承されない（計算値に出ない）ため、祖先に下線がある場合はラン生成時に引き継ぐ。表のセルも同じ。

地雷25：インライン要素の背景色。未記入の必須要素を示す「●●●」を黄色の網掛けにするため、display:inline の要素の背景色を PowerPoint の蛍光ペン（<a:highlight>）として転写する。あわせて、インライン要素の背景は「入れ子の箱」の判定から外した（図形ではないため）。inline-block は従来どおり箱として扱う。

ひな型の中身

• 型は A〜F の6種（A 全体像／B 進捗報告／C 投資判断／D 構想説明／E 外部情報／F 論点提起）。見本は1〜9枚目、すべて架空の題材
• 型ごとの必須要素と推奨要素を【8】に表で持つ。必須が欠けたら差し戻さず、紙面の本来の位置に <span class="tbd">●●●</span> を置いて最後まで作る。推奨は紙面に入れず提案のみ。数字を推定で埋めることを禁止した
• ●●●一覧はチャットで返す（資料HTMLには入れない）。各行に「役員に聞かれる質問」を添える【13】
• 色はページ単位。section.slide ＝ 赤（自社の方針・構想・全体像）、section.slide.blue ＝ 青（他社・外部情報、実績データ、試算）。強調文字は常に赤。トークンの付け替えだけで切り替わる
• 箇条書きは <ul> を使わず .it（記号 .mk ＋本文 .tx）。変換ツールは <ul> を「•」のビュレットにするため、部長資料の ✓ ・ ⇒ が再現できない
• 表で rowspan を使わない。ブラウザが行の高さを誤って報告し、ツールバーのはみ出し検知が赤枠を出す（実測）。colspan は問題ない
• 縦は上詰め（文書モードと同じ考え方）。報告用紙は下が空いていてよい

検証結果

• headless Chromium（BIZ UDPゴシック）で9枚すべて描画。はみ出し0件、コンソールエラー0件。一覧・編集・はみ出し検知が動作
• PDF出力：9ページ、1051.92×744pt（A4横と同比率）
• 変換ツール v0.7.0：健全性チェックすべて ✓（ステージ 1403×992、9/9枚）。図形28／文字202／表7／枠線の分解9。スライド寸法 10690890×7559070 EMU（11.69×8.27in）。蛍光ペンと下線がXMLに出ていることを確認。LibreOfficeでの描画を目視確認
• 実機のPowerPointでは未確認。最初の資料で必ず確認すること

既知の制約（持ち越し）

• 表のセルに複数のランがあると、PptxGenJS が同じ段落の中に <a:pPr> を2回書く。v0.6.1 でも同じ出力（v22の変換で11か所）で、実機で問題が出ていないため手を付けていない
• 表のセルには行間（lineSpacing）を渡していないため、セル内の改行はPowerPoint既定の行間になる（v0.6.1 から同じ）
• チェッカー html-slide-lint v0.3 は未対応 → v0.4 で対応（下記）

チェッカー v0.4（報告資料ひな型への対応）

1本のツールで両方のひな型を検査する。<meta name="slide-spec-version"> の値に report を含むか、<meta name="slide-stage"> があれば「報告資料モード」、それ以外は従来の「スライドモード」。ファイルを分けなかった理由は §6.10 と同じで、共通の検査（残骸・!important・重複・16px未満・疑似要素・data-editable）のほうが大きいため。

スライドモードの検査は1行も変えていない。報告資料モードでだけ、次を切り替えた。

§6.11 の方針（「直さない指摘を入れない」）に従い、エラーと警告は出たら必ず直すものだけにした。色の直書き検査は、#fff などの正当な指定で大量に出るため入れていない。

検算（ツールそのものを headless Chromium で動かして確認）

6.13 報告資料ひな型 v2 と依頼様式（2026-09）

何を解いたか

v1 で、ベンダー提案書（特徴量分析）を素材にSonnetで作らせたところ、次の4点の問題が出た。

原因はひな型のデザインではなく、ルールの前提にあった。

1. 入力を確定原稿として扱っていた。【6】はスライドひな型から引き継いだ「文言は一字一句変えない」が原則で、情報を捨てる工程が無かった。AIは誠実に全部を載せた
2. 「誰が誰に何を求める紙か」を決める工程が無かった。素材の出どころ（提案書か自部門の原稿か）も判定していない。そのため、提案書の視点がそのまま残った
3. 型をAIが内容から推測していた。「やりたい＝承認」なのにC型にならず、C型の必須要素（コスト・期間）が働かなかった。●●●が判断の中身（動詞）まで置き換えてよいルールだったため、中身の無い判断事項になった

§6.10 の教訓「内容から決まらないものをAIに判定させない」を、モード以外にも当てはめられていなかった。

設計：人が決めることは様式に、内容と作法はひな型に

様式が空欄のとき、止めるのは「求めるもの」と「立場」の2欄だけにした。この2つを推測すると型と主語がまとめて崩れるため。ユーザーは差し戻しを嫌う（§6.12 の●●●方針）ので、他の欄は推定・既定値・●●●で進め、報告で明示する。数字欄は「空欄＝素材から探す」「未定＝素材にあっても●●●」を区別した。

大前提：素材は稚拙、積極的に書き直す

ユーザー判断により、入力は作りたい資料より稚拙である前提とした。AIの仕事は素材を移すことではなく、選んで、主語を直して、部長の書き方で書き直すことである。これを冒頭と【6】に明記した。

• 数字・固有名詞・日付だけは変えない
• 「文言そのまま」は様式6で明示されたときだけ
• 捨てるものを素材の種類ごとに一覧にした（ベンダー提案書なら「弊社理解」、宣伝、売り文句、造語、提案書の見出し、繰り返し）

結論も積極的に書き直す。当初案は「人の結論はAIが言い換えない」だったが、ユーザー判断で「意味を変えない範囲で、部長の技法で意図的に変える」に改めた。技法は部長資料から6つ抽出した（【11】）。

変えないのは、判断の向き・相手・対象・人の数字。①段階化と④安心材料は、素材に根拠があるときだけ使う（無い条件を足すと事実が変わるため）。

その他の変更

• 型は様式の「求めるもの」で機械的に決まる。A全体像・D構想説明は単独で使わず、Cの前ページとしてだけ使う
• 役員の質問を先に書き、紙面はその答えだけで組む（Step4）。質問の表が、そのまま必須要素の表になる
• ●●●は値にだけ使う。判断事項の文型を固定し、判断の中身は必ず組み立てる
• 原則1議題1枚。2枚目は1枚目の根拠（コスト内訳・日程など）だけ
• 作成後の報告に3項目を追加。読み取った設定、結論の書き直し（元の文と技法番号）、捨てた情報（戻せるように）
• 見本10を追加。ベンダー提案書から当部の施策としてC型1枚に編集した例。HTMLコメントに「提案書の文 → 紙面の文」の対応と、使った技法を書いた。規則より見本が効く（§6.9）
• .lead-text の表示を修正。display:flex だったため、結論帯に●●●（span）を入れると、文字が flex の要素ごとに分かれて崩れた。v1 の見本は結論帯に span が無かったため気づかなかった

チェッカー v0.5

報告資料モードに1本追加した。紙面の「貴社・御社・弊社」をエラーにする。報告資料では出たら必ず直す語なので、§6.11 の方針と矛盾しない。HTMLコメント内の語は対象外（textContent はコメントを含まない）。

検証結果

Sonnet 自身が v2 と依頼様式で同じ品質を出せるかは未確認。作り直した1枚は Opus が v2 のルールに従って作成したもの。次の作業として、同じ素材と様式でSonnetに作らせ、差を見ること。

6.14 報告資料ひな型 v2.1（Sonnetでの確認を受けた修正）

確認の結果

v2 と依頼様式で、Sonnetに特徴量分析の資料を作らせた（素材は変えていない）。§6.13 の4つの症状はすべて解消した。1枚に収まり、主語は当部、コスト・期間は結論帯に入り、判断事項も文型どおりだった。新たに2つの問題が出た。

創作が起きた原因は3つの組み合わせである。

1. 【11】技法⑤「次の判断の時期を示す」に、①④のような「素材に根拠があるときだけ」の制限が無かった
2. 【10】の骨格と C型の定番が「最下段＝判断の条件と次の判断時期」で、器が必須に見えた（§6.9 の「器を用意するとAIは中身が無くても埋める」の再発）
3. ●●●のルールが「値が無いときは●●●（⑤の時期など）」と書いており、事柄ごと作って値だけ●●●にすることを許していた

素材の「目指す姿」（将来、AIが成約可能性を予測できる状態へ発展させる）が、⑤の器に流し込まれて「判断」に作り替えられた。

Opus が v2 のルールで作った1枚にも、同じ創作があった（「営業施策への本格適用を●●●の経営会議で判断する」）。ルールの穴であって、モデルの差ではない。v2.1 で作り直した。

v2.1 の修正

• ●●●は「素材にある事柄の値の欠け」にだけ使う。事柄そのもの（次の判断・会議・段階・将来の計画）を作らない。見分け方を1行で持たせた。「その文から●●●を取り除いたとき、残りの文の根拠を素材で指させるか」
• 技法①④⑤は、素材か様式に根拠があるときだけ使う。無いときは紙面に書かず、作成後の報告で「次の判断を置く案」として提案する
• 最下段は、素材に書くことがあるときだけ置く。承認を求めるページは、結論帯の判断事項で閉じているので最下段が無くてよい
• 素材の「目指す姿・将来像」は期待効果（中長期）として書く。判断や会議の予定に作り替えない
• 作成後の報告に「素材に無く足したもの」を追加（原則0件）
• 番号付き見出しは .sec に統一。横並びは .duo > .col > .sec（新設の .col は枠なしの列）。.tbox-h は番号の無い小見出し専用にした
• 見本10を修正。見出しを .sec に揃えた。最下段と⑤の根拠になる一文を、想定した素材としてHTMLコメントに明記した（「素材にあるから書ける」ことを見せる）
• 依頼様式の補足欄に「承認後の進め方や次の判断があれば書く」を追記した。AIが書かないものの説明も加えた

チェッカー v0.6

報告資料モードに1本追加した。「1.」「2.」で始まる見出しが .sec 以外（.tbox-h / .card-h / .sec-br / .sec-a / .phase-h）にあればエラーにする。全角の「１．」も検出する。①②や「A.」は対象外。

事実の創作は機械的に判定できないため、チェッカーでは扱わない（【12】のセルフチェックと【13】の報告で見る）。

教訓

• 見本の不統一は、そのまま出力の不統一になる。ひな型自身がルールを守っているか確認すること（§9 の申し送りと同じ）
• 「書き直してよい」と「事実を足してよい」は別物である。書き直しを積極的にさせるほど、事実の境界を明文化しないと創作が混ざる
• 技法を並べるときは、どれが「素材に根拠があるときだけ」かを1つずつ決める。1つでも漏れると、その技法が器になる

6.15 deck-fix v1.7・変換 v0.8.0・チェッカー v0.7・教材ひな型 v1.1・スライドひな型 v24a（2026-09）

何を解いたか

教材ひな型 v1（新規）とスライドひな型 v24 のレビューで、次の問題が見つかった。

変更禁止領域の改訂（deck-fix v1.6 → v1.7）

印刷CSSから、余白の上書き2行と、古い min-height:0 の1行を削除した。余白を「ひな型ごとに値を持つ」（報告資料ひな型 v1 が採った方法）のでも「変数化する」のでもなく、印刷で上書きしないことにした。

• 印刷で余白を上書きする理由が残っていない。各ひな型は画面の余白を自分で持っている
• ひな型ごとに値を書き換える方式は、ひな型が増えるたびに書き換え忘れが起きる（教材 v1 で実際に起きた）
• 変数化すると、変数と実際の padding を二重に管理することになる

検証：3行を消した版で、教材 v1.1・22ページの実例・スライドひな型 v24a・報告資料ひな型 v2.1a の全ページについて、画面用と印刷用のCSSで主要な箱の位置と大きさを比べ、差は0件だった。報告資料ひな型は、画面を等倍（1403×992のウィンドウ）にして測ること。縮小表示のまま測ると、縮小率（0.907）の分だけ全要素が違って見える。

話す原稿のパネルを追加した。

• 原稿は section.slide 直下の <aside class="notes" data-notes="">。<p> 1つ＝1段落
• 保護領域に [data-notes]{display:none!important} を置き、ひな型側のCSSに関係なく、画面・PDF・一覧に出ないようにした
• 編集モードのときだけ、画面の下に原稿パネル（高さ200px）を出す。fit() はパネルとその上のツールバーの分（200＋64px）を除いた高さにステージを収め、上に寄せる。当初はパネルの分だけ除いていたため、ツールバーがスライド下端の「つまり」帯に重なった
• パネルの入力は、その場でページの aside に書き戻す（原稿の無いページでは作る）。パネル自体は data-injected なので、HTML保存では残らない。保存時は .deck の top も取り除く
• 原稿のあるファイルでだけパネルを出す（読み込み時に body.has-notes）。原稿の無いスライドひな型・報告資料ひな型では、動きは v1.6 と同じ
• data-editable は原稿に付けない。data-editable は「画面に見える文字で、はみ出し検知・文字サイズ調整の対象」という意味なので、見えない原稿とは分けた

あわせて、一覧のキャプションを、h1〜h3 の無いページでは最初の [data-editable] から取るようにした。

3ひな型への展開：1600×900 版と 1403×992 版の2系統。違いは寸法の数値（ステージ、一覧サムネイル、@page、STAGE_W/H）だけで、今までと同じ。ページ送り・一覧・番号ジャンプ・はみ出し検知・文字サイズ調整・HTML保存を、3つとも headless Chromium で動かして確認した。

変換ツール v0.8.0（地雷26・27）

地雷26：PptxGenJS の addNotes() は段落を分けない。addNotes("1段落目\n2段落目") の生成XMLを読むと、ノート欄のプレースホルダーに <a:p> が1つだけあり、改行は <a:t> の中に生のまま入る。言語も lang="en-US" になる。そこで生成後に ppt/notesSlides/notesSlideN.xml を開き、その1段落を段落ごとの <a:p> に分け、言語を ja-JP（altLang en-US）にする。グラデーション（地雷14）と同じ後処理方式で、形が想定と違えば何もしない。

地雷27：原稿の要素を走査から外す。v0.7.0 も display:none の要素は読み飛ばしていたが、ひな型のCSSに依存していた。v0.8.0 は [data-notes]（と互換の aside.notes）を明示的に飛ばす。

• 原稿の取り出しは section.slide の直下だけを見る。<p> があれば1つを1段落、無ければ全体を1段落。和文の途中の改行は詰め、それ以外の空白は1つにする
• 識別は data-notes 属性を正とする（§1.3(a) のとおりクラス名に依存しない）。aside.notes は、教材ひな型 v1 で作った資料のための互換
• 計測結果のJSONに notes:[…] を足した（計測 v0.4.0）。健全性チェックに「話す原稿（ノート欄へ転写）N / M 枚」を足した（情報。0枚でも ! にしない）

検証：

実機のPowerPointで確認済み。教材のノート欄を含め、公開に問題がないことを確認した。

チェッカー v0.7

• 判定を「仕様版に lesson → 教材、report または slide-stage が 1403x992 → 報告資料、それ以外 → スライド」に変えた
• 全モード共通で、話す原稿の文字を「data-editable の付け漏れ」から外した
• 教材モードの検査（エラー）：ステージmeta 1600x900／ul・ol／rowspan／20px未満の文字（直書きと :root の --fs-*。ページ番号は除く）／他のひな型の部品の混入。（警告）：原稿の無いページ・空の原稿・data-notes の無い原稿・1ページに2つ以上／表の本文8行以上／.key 2か所以上・強調4か所以上／見本ページの残り
• 教材モードでは、参考デザインの流用・文書モードへの混入・align-content:start・報告資料の検査を行わない

検算（ツールそのものを headless Chromium で読み込み、inspect() を呼んだ）

教材ひな型 v1.1

• deck-fix v1.7 に差し替え。.body と .t-div を justify-content:safe center に（溢れを下側だけにする。実測で検知量が 298px → 596px になり正しくなった）
• 原稿を data-notes と <p> の形に。【6】を書き直した
• 【2】に「L7 要素紹介は .intro-name がタイトルを兼ねるので .pg-title を置かない」を追記（v1 は見本と規則が食い違っていた）
• .div-q と .key-main を h2 に（一覧のキャプション）。表紙のページ番号の色をトークン --pgno に
• 密度プリセットを .density-low の1クラスに（スライド個別の上書きが常に勝つ）
• 未使用だった .card.pale と .b を削除。.key .em .ul .nt .cat .w-s .down .target は見本で使う形にした（基準線を警告0にするため）
• 仕様版を 2026-09-lesson-v1.1 に

スライドひな型 v24a

• deck-fix v1.7 に差し替え
• 密度プリセットを .density-low／.density-high の1クラスに。【4】に「個別の上書きが優先される」を追記
• density-high の見本を、効果の無かった05から型①の07へ
• 【5】の下限を「カード内の文字が占める高さ」で判断する形に（型④はカードが常に本文エリアいっぱいに伸びるため、箱の高さでは常に10割になる）
• 話す原稿を「ユーザーが求めたときだけ書く」任意の部品として【10】に追加
• 冒頭の対応版表記（v0.6.1 のままだった）と【0】の meta の説明を修正
• 仕様版は 2026-09 のまま。道具の動きが変わらないため（下記）
• 青版も作った。緑版 v24a を土台に、色に関わる箇所だけを v23（青）の値に戻した。v23（青）と v24a（青）の差分に、色コードの変更は無い（原稿パネルの色を除く）

仕様版を変える基準

チェッカーか変換ツールが、その版を見分けないと正しく扱えなくなったときだけ変える。v24 の密度プリセットや v24a の deck-fix 差し替えはこれに当たらない。系統は、スライドひな型＝2026-09、教材＝…-lesson-…、報告資料＝…-report-… で見分ける。変換ツールはモードを持たず、ステージを slide-stage、原稿を data-notes から読むだけである。

教訓

• 変更禁止領域の中にも、過去のデッキ向けの残骸がある。.steps のように、新しいひな型が同じクラス名を使った瞬間に効き出す。保護領域だからといって検査しないままにしない
• 中央寄せは、溢れを検知の外に逃がす。justify-content:center で溢れた分の上側は scrollHeight に現れない。中央に寄せるときは safe center を使う
• meta の「有無」で種類を判定しない。値で判定する。判定の材料が他のひな型にも現れたとき、誤判定になる

6.16 イメージ図ひな型 v1.2・図キット v1.1・変換 v0.9.0（2026-10）

何を解いたか

組織体制、新システムのイメージ、新しい仕事の運用の流れなど、「人物・モノ・箱を線でつないだ図」を生成AIに作らせ、編集できるPowerPointにしたい。既存のひな型には、人物の絵も、部品どうしを線でつなぐ仕組みも無かった。

ユーザーが決めたこと：

• イメージ図用のひな型を独立して作る。図の部品はスライドひな型・報告資料ひな型・教材ひな型でも使えるようにする
• ルールはこれまでどおりHTMLに書き込む（Copilot など会社環境でも使えるように）
• 人物はSVGで一覧として定義する。生命保険の現場の人物（営業職員、支社・本社の男性、女性総合職（PC操作あり／なし）、お客様（おじいちゃん・おばあちゃん）、コールセンターのオペレーター（ヘッドセット））
• 人物はフラットなピクトグラム風、目鼻口なし。頭（顔）を大きめにしてかわいく。肌は白地に埋もれない濃さ
• 営業職員の端末は赤いノートPC。お客様に見せるためのものなので、画面をお客様に向けて見せている姿にする
• 線は変換ツールを v0.9.0 に上げて、PowerPointの本物の線にする。人物・モノは今の仕組みのまま PNG 画像で入れる
• 用紙は16:9。テキストは編集できること。PPTX変換の仕組みは他のひな型と共用

設計：AIに書かせるのは「キー」と「つなぎ先」だけ

経路は auto／h／v／hv／vh／hvh／vhv。組織図は vhv で「木」の形になる（兄弟の横線が1本に重なる）。

図キットは2ブロック（fig-kit-style／fig-kit-script）で完結させた。他のひな型へは、この2つをコピーするだけで移植できる。保護領域であり、値の調整は :root の --fig-* の再定義だけで行う。

変換ツール v0.9.0（地雷28〜31）

地雷28：図キットの線を、PowerPointの線にする。data-conn の SVG を line という種別で計測し、2点なら prstGeom line（flipH／flipV で向き）、3点以上なら custGeom（フリーフォーム）にする。矢印は triangle（data-head：end／start／both／none）、破線は dash、色・太さは線の path の計算済みスタイルから読む。画像にしないので、PowerPointで端点や頂点を動かせる。

地雷29：計測の直前に figLayout() を呼ぶ。計測用CSS（--stage-scale:1 など）や BIZ UDPゴシックへの差し替えで部品の大きさが変わると、ひな型の画面で計算した線の位置がずれる。両方のパスの前に呼ぶ。図キットの失敗で計測全体を止めないよう、例外は握りつぶす。

地雷30：点列の無い線を健全性チェックに出す。 図キットは、つなぎ先の部品が見つからない線をエラーにせず非表示にする（data-pts を消す）。変換ツールは line-missing として数え、「線（PowerPointの線として転写）」に ! を出す。チェッカー v0.8 でも、つなぎ先の無い線をエラーにした（§6.17）。

地雷31：文字の外に単独で置いたSVGが、変換で黙って落ちていた（既存の不具合）。v0.8.0 までは、SVGを PNG にするための単体化（serializeSvg）を、文字の中のアイコン（地雷6）にしか行っていなかった。単独のSVGは svg として計測されるのに svgMarkup が無く、生成側で黙って捨てられていた。今までのひな型ではSVGが必ず文字の中にあったため表面化せず、図キットの人物で初めて分かった。v0.9.0 は単独のSVGも単体化する。

回帰：線も単独SVGも無いHTMLを v0.8.0 と v0.9.0 で変換し、スライドXML・ノートXMLがバイト単位で一致することを確認した。

改版の経緯

• v1.1（人物の見直し）：頭まわり（後ろ髪・頭・前髪・ヘッドセット）を <g transform> でまとめて1.28倍にし、体を少し細くした。肌 --fig-skin を #f6d2b8 → #f0b48a に。営業職員端末を赤いノートPCにし、人物 sales-pc（画面をお客様に向けて両手で見せる姿）とモノ sales-dev を追加。色は --fig-sdev（#d6302a）で、意味色の赤（×・エラー）とは別のトークン。変換ツールは transform を保ったまま PNG にするので改修不要
• v1.2（図キット v1.1）： 図キットを最新のスライドひな型 v24a（緑）と報告資料ひな型 v2.1a に移植して試したところ、報告資料で箱の文字に赤の下線が付いた。図キットの .f-box.key が、報告資料・教材の強調 .key（赤＋太字＋下線）とぶつかったため。種類のクラスをすべて f- 付きに改名した（.key→.f-key／.soft→.f-soft／.plain→.f-plain／.dash→.f-dash／.tall→.f-tall／.mute→.f-mute／小さい人物・モノ .s→.f-sm）

検証結果

教訓

• 黙って落ちる不具合は、新しい種類の入力で初めて出る。地雷31は v0.5 からあったが、ひな型がSVGを文字の中にしか置かなかったため4版にわたって見えなかった。新しい要素を足したら、変換の「入った件数」が入力の件数と一致するかを数えること（今回は絵55/55件、線26本で確認した）
• 移植する部品のクラス名は、移植先のどのひな型とも重ならない接頭辞にする。汎用の名前（.key .soft .s）は、どこかのひな型で別の意味に使われている
• ルールの説明文（HTMLコメント）にブロックの書き方の例を書くと、文字列検索で先頭を拾う道具が誤る。【13】に <script id="fig-kit-script"> と書いてあるため、indexOf で探すとコメントの中を拾う。チェッカー v0.8 は、カタログのキーを DOM として読んだ script#fig-kit-script の中身から取っている

6.17 deck-fix v1.8・チェッカー v0.8・各ひな型の英字版（2026-10）

何を解いたか

ひな型（どれでも）をブラウザで開き、「HTML保存」で保存したファイルを開き直すと、スクリプトが TypeError: Cannot read properties of null (reading 'classList') で止まった。ページ送りは動くが、はみ出し検知・スライド一覧・番号ジャンプ・原稿パネルの更新が動かない。開き直したファイルからは、もう一度「HTML保存」することもできなかった（保存の途中の closeOverview() で止まる）。

原因：deck-fix の静的な要素3つ（.of-badge、#jump、#ov）に data-injected="1" が付いていた。saveHtml() は保存時に [data-injected] をすべて取り除くため、この3つも保存ファイルから消える。開き直すと ovEl（#ov）が null になり、show() の ovEl.classList.contains('open') で落ちる。show() は落ちる前に .active の付け替えを済ませているので、ページ送りだけは動いて見える。

deck-fix v1.8

スクリプトの冒頭（要素を取得する前）で、3つの要素が無ければ作るようにした。作った要素にも data-injected を付けるので、保存では今までどおり消え、開き直すたびに作り直される。

静的な要素から data-injected を外す案も考えたが、採らなかった。v1.7 で保存して要素を失ったファイルにも、v1.8 のブロックを貼り直せば直るため。

• 1600×900 版と 1403×992 版の2系統。違いは今までどおり寸法の数値だけ
• 静的な要素（.of-badge／#jump／#ov）はブロックに残した。見た目と動きは v1.7 と同じ

各ひな型の差し替え

冒頭の「変換ツール ○○ 以降」の表記は、ひな型ごとにばらばら（報告資料は v0.7.0、スライド・教材は v0.8.0）だったので、すべて「変換ツール v0.9.0 以降、チェッカー v0.8 以降」にそろえた。仕様版 meta は変えていない（道具が版を見分ける必要が無いため。§6.15）。

検証：

チェッカー v0.8

判定：仕様版に lesson → 教材、figure → イメージ図、report または slide-stage が 1403x992 → 報告資料、それ以外 → スライド。v0.7 はイメージ図ひな型をスライドモードで検査し、図キットのCSSについて警告2件（未使用クラス f-cap2 f-tall pk-soft、:root の重複）を出していた。

全モード共通：fig-kit-style を deck-fix-style と同じく保護領域にした（変更禁止のブロックなので検査しない）。図キットのクラスは「CSS未定義」に数えない。

図キットの検査（全モード。図の部品があるファイルだけ）：図を移植したスライド・報告資料・教材も対象になる。

イメージ図モードだけの検査：ステージ meta（1600x900）の欠落・不一致（エラー）／data-pict・data-conn の無いSVG＝AIが絵を描いている（エラー）／見本・カタログのページの残り（警告。ひな型本体では検査しない）。参考デザインの流用・文書モードへの混入・align-content:start は検査しない。

検算（ツールそのものを headless Chromium で読み込み、inspect() を呼んだ）：

教訓

• data-injected は「保存で消してよいもの」の印である。静的に書いた要素に付けると、保存で消える。消える要素をスクリプトが前提にしているなら、スクリプト側で作り直すこと
• 保存して開き直す確認を省かない。ひな型を開いた直後の確認では出ず、保存→開き直しでしか出ない不具合がある。ページ送りだけは動くので、目視でも気づきにくい
• 保護領域は、検査から外すだけでなく「定義済み」として扱う。図キットのCSSを検査から外しただけでは、図キットのクラスがすべて「CSS未定義」に並ぶ
• 図の検査は「図があるファイルだけ」に限る。図の無いファイルの結果を1件も変えないことで、既存の基準線をそのまま使える

6.18 イメージ図ひな型 v1.3・図キット v1.2・チェッカー v0.9（2026-10）

何を解いたか

イメージ図ひな型で「Snowflake導入で実現する未来のイメージ」の図を作った際、次の問題が出た（詳細は改善提案書）。

• 依頼者の典型的な意図は「1枚で完結し、伝えたいことが伝わる図」だったが、ひな型は「上限を超えたら2枚に分ける」「強調は .f-key（今回の主役）だけ」が前提だった
• 伝えたいハイライトを示す部品（吹き出し）が無かった
• 線ラベルが短い線を隠す、日本語の折り返し、高さの見積もりなど、作図の試行錯誤が多かった
• 毎回同じ指示（1枚で、吹き出しで、表紙なし）をプロンプトに書く必要があった
• 図の中身を、人が部品（人・システム・流れ）に仕分けて書くのは難しい

依頼様式（報告資料と同じ形）

報告資料ひな型と同じく、依頼は依頼様式で受け取る。様式の1〜10は選ぶだけ・空欄でもよい欄で、図の中身は末尾の【要件定義】に人が自由に書く。部品（人・システム・流れ・まとまり）への仕分けと、図に載せる言葉への言い換えは、ひな型のルール（【19】【18】）でAIが行う。

当初の案（v1.3案）は、判断を書く「プロンプト」と、図の中身を表に書き分ける「要件定義ひな型」の2つに分けていた。しかし、ハイライト・登場するもの・流れを人が表に仕分けて書くのは現実的でないため、報告資料と同じ「様式＋自由記述」の形に改めた。

様式に書かれたことは人が決めたこととして、AIが推測で上書きしない。「」で囲んだ言葉は一字も変えない。要件定義に無い人・システム・流れは足さず、足したものは報告の「仮の前提」に出す。

図キット v1.2

• 吹き出し .f-box.f-call と指し線 .f-line.f-pt を追加（CSSだけ。スクリプトは v1.1 のまま）。色は --call-bg／--call-line、見出しは --fs-call-title（22px）
• 指し線は HTML に data-head="none" を必須にした。変換ツール v0.9.0 は、矢印の有無を計算済みスタイルではなく data-head 属性から読む。図キット側で矢印を消すだけでは、PowerPoint で矢印が付く
• 既定値を :where(:root) に書いた。図キットの style は主ひな型の style の後ろにあるため、v1.1 までは同じ詳細度の :root で後ろの図キットが勝ち、ページの :root に書いた --fig-* が効いていなかった（【13】の「報告資料・教材では :root で再定義」も画面では効いていなかった）。:where() は詳細度0なので、ページの :root が優先される。既定値そのものは変えていない

高密度モード

様式7「密度：高密度」で切り替える。.fig に data-density="high" を付け、チェッカーが上限を切り替える。

線ラベルの決め方

v1.3案では「列の間隔ごとの文字数の表」（56px なら2文字）にしていたが、見本06は既定の間隔で5〜8文字のラベルを問題なく表示している（線が空いた列をまたぐため）。基準を「8文字まで、かつラベルの幅（文字数×16＋26px）が線の見えている長さより短い」に改め、表は隣り合う箱どうしの場合の例として残した。

チェッカー v0.9

検証

v1.4 以降に持ち越したもの

ラベルの自動回避、自己検査 figCheck()、指し線の端の丸（変換ツールの対応が必要）、word-break:auto-phrase（PowerPoint の折り返しには効かない）、data-anchor="pict"、カタログの追加。理由は改善提案書 §8。

教訓

• レビュー用の案は、公開中の版から作る。v1.3案は1つ前の v1.2 から作られており、公開済みの不具合修正（deck-fix v1.8）が巻き戻っていた。差分を取れば一目で分かる
• 変換ツールが何を読むかを確かめてから部品を作る。矢印は見た目ではなく属性で決まっていた
• 詳細度が同じなら後ろが勝つ。移植前提の部品の既定値は :where() で書く
• 見本ページにページ固有のCSSを持たせたら、複製したときの番号の付け替えまでルールに書く

7. 今後の作業候補

優先度順。

1. 型カタログの第3弾　⑤フレームワーク・⑥ロードマップ。04が素材になる（§6.7）。型クラスへ寄せる作業が中心で、ゼロから作るより早い。⑥のスイムレーンは矢羽根の形状が問題になる。clip-path は転写されないため、角丸長方形で代替する必要がある。④絵解き（並列）は v21 で完了（§6.9）。絵解きのうちフロー版（03が素材）は未着手
2. 文書モードの使われ方の観察　部品を6つに絞ってあるため、足りないものが出る。予想されるのは、表を含む節、2段組、別紙一覧、日付・宛先・発信部署のヘッダ。数本作らせてから、何を足すかを決める。足すときは §6.9 の教訓に従い、「そこに書くことが無い場合はどうするか」を同時に決めること
3. 型④の使われ方の観察　.par-note が全カード同じ値になる失敗は【10】で潰したが、これは「器だけ埋める」類の失敗であり、別の形で再発する可能性が高い
4. 資料側の未使用CSS　ひな型を複製して作った資料には、使わなかった型のCSSが丸ごと残る。ミャンマー資料v21では未使用クラス8件（grade-* legend opinion owner eyebrow ほか＝型③のもの）が出ている。v22 では文書モードのCSSも同じ状況になりうるが、こちらは1ブロックにまとまっているため削除は容易で、チェッカー v0.3 のヒント文にもその旨を書いてある
5. 右寄せ1行テキストの右インセット　§4.2 の未確認の制約。左寄せで回避できているため、右寄せの注記が必要になってから着手する。isSingleLine() を触ると地雷13が再発する側のリスクがあるため慎重に
6. ビュレット記号の指定　変換ツールは characterCode: '2022'（•）の決め打ち。25A0（■）にするのも指定可能にするのも容易だが、変換後にPowerPoint側で変える運用としたため、現時点では不要
7. 企画書の改訂　実測値が揃ったので、承認プロセス用に書き直せる
8. 変換ツールの「記号のグリフ確認」パネル　目視で並べるだけの表示に戻してある。§1.2 のとおり判定は成立せず、記号の字幅も問題ではなかったため、削除してよい
9. イメージ図の実機確認　変換 v0.9.0 の線（矢印の大きさ、フリーフォームの頂点の編集）、人物PNG、吹き出しの見え方は、LibreOffice でしか確認していない。最初の図を作ったときに実機のPowerPointで確認する（§6.16、§6.18）
10. イメージ図ひな型の緑版　図の色は移植先・:root に追従するため必須ではない。必要になったら :root の色だけを緑の値にした版を作る
11. カタログの絵を足すとき　図キットの版を上げ、イメージ図ひな型と、図キットを移植した全ひな型を差し替える。チェッカーはカタログを図キットのスクリプトから読むので、チェッカーの改修は要らない。イメージ図依頼様式の記入例に影響がないかも確認する
12. イメージ図の再現テスト　依頼様式の記入例で、別のセッションから見本09と同等の図が出るかを試す。高密度は見本10が目安（§6.18）
13. イメージ図 v1.4 の候補　ラベルの自動回避、figCheck()、指し線の端の丸（変換ツールと同時に）。改善提案書 §8

8. 改版履歴

9. AIへの申し送り

この一式を改修するとき、以下を守ること。

• クラス名に依存する処理を書かない。世代間で安定していない
• ひな型を改版したら、必ずチェッカーにかけてから配る。v18 には壊れたセレクタが長く残っていた。人間の目視では見つからない種類の問題がある
• ひな型自身がルールを守っているか確認する。v18 はひな型でありながら表の角丸と疑似要素の装飾という自分のルール違反を含んでいた。ひな型が破っていれば、AIはそれを見て真似る
• ひな型のCSSを触ったら、ブラウザで見た目が変わらなくても変換まで通す。地雷22の教訓。特にトークン化のような「値は同じはず」の変更で気を抜かないこと
• 計測と生成は別の関心事として保つ。計測結果のJSONが両者の境界であり、この形が変わらない限り片方だけ差し替えられる
• 地雷1〜22は再発しやすい。特に地雷4（図形とテキストの排他）、地雷12（margin順序）、地雷17（Rangeの複数行）、地雷18（Grid/Flexの寄せ）は、一部のケースでは正しく動いてしまうため気づきにくい
• 文字の位置がずれたら、ずれの向きで原因を絞る。縦横同量なら図形（地雷22）、縦だけなら行間（地雷19）、横だけなら寄せ（地雷18）。§1.2 のとおり、ここを飛ばして書体を疑うと大きく遠回りする
• スクリーンショットから測るときは、表示倍率を実測値で補正し、測定精度に見合った結論だけを出す。§1.2 の誤診は、倍率の異なる2枚から墨面を切り出した測定を根拠にしたことが発端である。同じ測定の中に矛盾する数値がないか必ず確認すること。あった場合、仮説に合うほうを選んではいけない
• 変換ツールのスクリプトブロックは3つに分かれている。1つ目がPptxGenJS、2つ目が生成側（(function(root, factory){…}) で包まれた即時実行関数）、3つ目が計測とUI。2つ目の中の定数は外から見えない。ブロックをまたいで定数を参照すると ... is not defined で落ちる。実際に踏んだ
• 判定機能を作るときは、答えの分かっているデータでの検算を先に作る。検算がないと「動いているように見える誤った結果」を採用してしまう（§1.2）
• 生成XMLを直接読んで検証する。PptxGenJSのオプション名から挙動を推測しない。地雷12はXMLの lIns を読んで初めて発覚した
• ひな型を編集するときは保護領域に触らない。変更後は元ファイルとの差分を取り、意図した箇所だけが変わっていることを確認する
• 改版は、いま公開している版を土台にする。持ち込まれた案が古い版から作られていないか、公開版との差分で確かめる（§6.18）
• イメージ図ひな型を改版したら、イメージ図の依頼様式も見直す。欄と選択肢と既定値は、ひな型【14】と一致させる。ルールの中身はひな型にだけ書く
• ユーザーの文言は勝手に変えない。これはひな型のルール【6】であり、この一式全体の方針でもある
• AIに「当てはまらなければ相談してください」と書いても、逃げ道にはならない。作業を止める選択肢しか用意しなければ、AIは手持ちの型に無理やり当てはめる。既定値（「迷ったら①」）と、受け皿の数が、そのまま出力の偏りになる。型を1つ足すことは、注意書きを10行足すより効く（§6.9）
• チェックリストは両方向に書く。「Xで書いたか」だけを並べると、Xにすべきでないものまで通る。上限を書いたら下限も書くこと（§6.9）
• 器を用意すると、AIは中身が無くても埋める。型①の3列目が「備考」で埋まったのと同じことが、型④の .par-note でも起きた。列・スロット・チップを足すときは、「そこに書くことが無い場合はどうするか」を同時に決めること（§6.9）
• 内容から決まらないものをAIに判定させない。型の選び方（比較／因果／並列）は内容から決まるので判定させてよい。モード（投影用か読ませる用か）は内容からは決まらず、人間しか知らない。判定できないものを判定させると、既定値のほうへ機械的に倒れる（§6.10）
• チェッカーを自作の再現で代用しない。判定ロジックを別に書き直して照合すると、再現側の取りこぼしに気づけない。ツールそのものを動かすこと。実際、再現スクリプトは data-editable の付け漏れ6件を見落としていた（§6.8）
• 検査を足すときは、検知テストと誤検知テストを対で作る。片方だけでは、何も検出しない実装も、何でも検出する実装も通ってしまう（§6.8）
• チェッカーに「直さない指摘」を入れない。エラー0件を基準線として運用するため、直す必要のない指摘が出続けると基準線そのものが意味を失う。検査項目を足すときは「それが出たら必ず直すか」を先に決めること（§6.11）
• LABの公開はCloudflare Workers Static Assets＋Wranglerで行う。管理画面の静的ファイル／ZIPアップロードではWorkerの認証処理を配置できない。worker/index.js と wrangler.jsonc を維持し、npx.cmd --yes wrangler@4 deploy --config wrangler.jsonc で公開する。保護対象は /html2pptx/protected/* だけに限定する
• meta の有無ではなく値でひな型を判定する。チェッカー v0.6 は slide-stage があるだけで報告資料とみなし、教材ひな型を誤判定した（§6.15）
• 変更禁止領域（deck-fix）も、新しいひな型を足すたびに中身を読み直す。印刷CSSに残っていた古い .steps{min-height:0} が、教材の .steps に当たった（§6.15）
• 画面とPDFの比較は、等倍で測る。縮小表示のまま測ると、縮小率の分だけ全要素が違って見える（§6.15）
• 話す原稿は data-notes で見分け、data-editable と混ぜない。見えない文字に contenteditable や文字サイズ調整を効かせない（§6.15）
• スライドひな型 v22 は廃止した。改修や新しい型は、DADS準拠の現行版（v24b の緑・青）に対して行い、緑と青の両方に入れる。§6.1〜§6.11 の v22 の記載は、現行版の設計理由として読むこと（§6.0）
• 文字の外に単独で置いたSVGも変換で拾うこと。v0.8.0 までは文字の中のアイコンしか対象になっておらず、単独のSVGはエラーにならずに落ちていた。図キットの人物で初めて表面化した（§6.16 地雷31）
• 移植する部品のクラス名には、移植先のどのひな型とも重ならない接頭辞を付ける。図キット v1.0 の .f-box.key が報告資料・教材の強調 .key（赤＋下線）とぶつかった。図キットのクラスは f- か pk- で始める（§6.16）
• ルールの説明文（HTMLコメント）に、ブロックの書き方の例を書くと、文字列検索で先頭を拾う道具が誤る。イメージ図ひな型の【13】には <script id="fig-kit-script"> と書いてある。移植や検査の道具は、DOMとして読むか、最後の出現を使うこと（§6.16）
• data-injected は「HTML保存で消してよいもの」の印である。静的に書いた要素に付けると保存で消え、開き直したときにその要素を前提とする処理が止まる。付けるなら、スクリプト側で「無ければ作る」こと（§6.17）
• 保存したファイルを開き直す確認を省かない。deck-fix v1.7 の不具合は、ひな型を開いた直後の確認では出ず、保存→開き直しでしか出なかった。ページ送りだけは動くため、目視でも気づきにくい（§6.17）
• 共通ブロック（deck-fix・図キット）は、ひな型の側で書き換えない。直すときはブロックの版を上げ、入っているひな型すべてを差し替え、元との差分が意図した箇所（と寸法の数値）だけであることを確かめる（§6.17）
• 図キットの線は data-conn と data-pts で見分ける。変換ツールはクラス名ではなくこの2つの属性だけを読む（§1.3(a)）。図キット側の見た目を変えても変換は改修不要（§6.16）