登壇スライドのストーリーの型

登壇スライドは読ませる資料ではない。話し手が話しやすい紙芝居であり、聞き手が「いまどの話のどこにいるか」を見失わないための道具である。投影して口頭で補う前提なので、配布資料に必要な網羅性や注記は要らない。

この型は、作者（みのるん）が数年分の自作デッキを読み返して抽出したもの。AIエージェントにスライドを書かせると体裁は整うのに中身が薄くなりがちで、その原因の大半は下に挙げる規則のどれかを外していることにある。

着手の順序

1. 主催者の告知ページで、正式なタイトル・概要・持ち時間を確かめる。応募時の原稿で代用しない。告知で約束した論点が資料に入っているかを、骨子の段階と完成時に照合する
2. 話し手本人の過去のデッキを1本、実物で読む。型は文章の説明より実物から掴める
3. 何を伝えたいか、聞き手は誰か、どの話で驚かせるかを、話し手と言葉で詰める
4. 紙芝居の流れを骨子として合意する
5. そのページでしか成立しない中身（図、具体例、実物のスクリーンショット、数字）を決める
6. 体裁はそのあと

テンプレートの型へ内容を流し込む作り方はしない。「アイコン＋太字の見出し＋1行の説明」のカードを3枚並べた構成を全ページで繰り返すと、体裁は整うのに何も伝わらない資料になる。

やってはいけないこと

• 申請書や審査資料のような「読ませる資料」の型（カード、対比図、フロー、ハブ図）を持ち込まない。1スライドに4ブロック詰まって、情報が並ぶ割に全部薄くなる
• 主催者から受け取ったテンプレートや既存スライドの構成を真似ない。合わせるのは画面比率・ロゴ・書体までで、中身の作り方は話し手の型を通す
• カリキュラム表やアジェンダの項目を、そのままスライドの章とスライド数にしない。要件の網羅は資料の役目ではない

骨格

つかみは聴衆の現在地から

概念の定義から始めない。作者の人気デッキ21本を調べたところ、定義から始まるものは1本もなかった。型は4つある。

• 共感と困りごとの代弁（「最近、MCPってよく聞きますよね！ …ざっと調べても、イマイチ分かりづらくないですか？」）
• 挑発するクイズ（「AIエージェントとは何か、自分の言葉で説明できますか？」）
• 時事のフック（「先日、新しいモデルがリリースされました！」）
• 自分の近況

自己紹介の次は、聴衆への問いかけのスライド2つから入る。「使ってますか？」の次に「作ってますか？」のように、2つ目で手が減る問いを置くと、そこが本編の入口になる。海外のイベントや英語のデッキでも同じ。

セクションの接続は「聴衆の心の声」の中扉

技術カタログの章立てをしない。聞き手がいま抱いたはずの疑問を中扉に書き、次の技術が必然として登場する形にする。

• 「え、じゃあAIエージェントって何なの…？」
• 「よし、エージェント書けた！ …どこにデプロイする？」
• 「でも、作るの難しいんでしょ？」

中扉には守る条件がある。

• 直後のスライドが、その問いの答えになっていること。答えていない中扉は消す。中扉を書いたら、次のスライドの見出しを1スライドずつ確かめる
• 1行だけにする。小さい文字のサブ行、章ラベル、番号を足さない
• 連続は2スライドまで。3スライド続くと不自然になる
• 間隔は本文3〜6スライドごと。本文のスライドが10続くと単調になる

概念の導入は3点セット

1. 「◯◯ is 何？」（1行の定義と語源の分解。エージェント＝代理人 → 誰の？ → あなた）
2. 「何が嬉しいの？」（Before と After）
3. 「つまり、すごく雑に言うと◯◯」（キメの一言。厳密さは脚注へ逃がす）

説明は抽象 → 具体 → 比喩の3段で進める。比喩は身近で大胆なものがよい（LLMを国民的アニメのロボットに、実行環境を「使い捨ての仮想PC」に喩える）。比喩を出したら、次のスライドではその比喩から製品を導く。比喩の直後に別の切り口の定義を置くと、つながりが切れる。

本編の運び

1. いきなり具体例（「こんなものが作れます」を先に見せる）
2. いまのやり方の限界（なぜ次の話が必要か）
3. 仕組みの説明（図1枚）
4. やってみる、どう作るか
5. 詰まるポイント（候補と困りごとを表で並べる）
6. 解決するもの
7. 次の一歩

主張と実例は隣に置く。あいだに別の話題を挟むと、説得力の出る例までが遠くなる。雑務の例を主役にしない。中扉で「例えば」と明示し、本質のメッセージを上位に置く。

締め方

• まとめスライドを作らない。締めは行動を促す中扉（「まずは◯◯から始めてみませんか？」）で着地させ、書影や告知の全面画像で終わる
• 宣伝スライドを最後に置くなら、その手前に「ありがとうございました」のスライドを入れない。同じ役目のスライドが2つ続いて締まらなくなる
• 行動喚起の倍率は大げさでよい（「理解の解像度が100倍上がりますよ」）。宣伝は隠さず、様式として堂々と置く

答えを先に出さない

情報を1つずつ足して認知負荷を下げるのが、この型の中心にある。結論や種明かしを先に置くと、その先の面白さが消える。

• 「今日はこの3つを話します」という予告スライドを作らない。アジェンダ、要点の先出し、結論の宣言はどれも同じ違反
• 問いを立てたら、答えはその後のスライドで順に開く。1スライドの中で問いと答えを閉じない
• スライドを足す前に、そのスライドが後の展開の要約になっていないかを確かめる。要約になっていたら要らない
• 冒頭に「全体像」「地図」「ループ図」を置くのも、同じ違反の別の形である。告知文の言葉が冒頭に出てこないことは欠陥ではない。その要素が自然に出てくる場面へ足す
• 講演を貫く一本の論理を設計するのは正しい。ただしそれは設計図に置くもので、スライドに書くのは1歩ずつの発見だけにする。「〜の2つです」「あとで証明します」と書きたくなったら、宣言型になっている

この規則は、スライドを作るときだけでなく、レビューでスライドの追加を提案するときにも当てはまる。

演出

資料全体で、次のどれかを最低2〜3か所に入れる。ゼロだと優等生的で単調になる。

• 段階ビルドアップ図解。仕組みの図は1スライドで完成させず、同じ図を3〜5スライドに割って要素を足していく
• 偽のエンディングからのどんでん返し（「めでたしめでたし」→「…人生そんなに簡単じゃないんです」）
• 吹き出しの寸劇。プロトコルや社内調整を、登場人物の会話に翻訳する
• 感情の絶叫（「多すぎる！！！」）
• 誤解の先回り（「もしかして、これのこと思い浮かべてませんか…？」）
• 想定反論と反駁の連打（「ハードル高いわ！」→「違います！」）
• 名前の由来の豆知識
• 正直な注意点を最低1スライド。売り込み一辺倒にしない
• 実体験への独自のネーミング

章が3つ以上あるなら、対応表やステップバーを章の変わり目に再掲して現在地を示す。

型は品質の下限を上げるが、上限は作らない。骨格や演出をなぞっても、ネタの面白さと実話の重みは生成できない。体験談やあるある系の資料は、先に話し手の実話を集めてから組む。この型の正しい使い道は、話し手が中身を出した後の構成チェックと演出の提案である。

ユースケースと固有名詞

• ユースケースは、その製品の売り（速さ、安さ、並列性など）が無いと成立しない場面だけを選ぶ。どの製品でも成り立つ例は差し戻される。公開されている実装と数字を、出典つきで載せる
• 課題を定義するスライドは、聞き手が今日使った道具の場面で書く。道具の名前、頼んだ言葉、返ってほしい答えの形まで具体的にする
• 固有名詞と数字は、話し手本人が説明できる形で置く。論文名には正体を、金額や点数には相場を同じスライドに添える。収まらないなら2スライドに割る
• 聞き手にエンジニア以外が混ざるなら、コマンド名や製品名を、それが何をするものかの言葉で書く。「git rebase で履歴を整える」は「変更の記録を整理する」にする。名前を知らない人にとって、名前は情報にならない
• 専門用語は初出で日本語を補う（レイテンシー（応答の遅れ））。英字の略語には正式名も添える（CDN（Content Delivery Network））

1スライドの情報量

項目	規則
1スライドの量	見出し1つと本文3〜4行。これ以上載せない
見出し	主張の一文。めくった瞬間に何の話か伝わること
本文	箇条書き3〜4項目、各1〜2文。階層は1段。4行になったら2スライドに割るか、意味の切れ目で改行する
強調	1スライドに1か所まで。デッキ全体では本文2〜3スライドに1か所
記号	ダッシュ（――）と全角コロンの多用を避ける
図	1スライドに1つだけ、大きく。同じ見出しで「図だけの1スライド」を作ってよい
表	2〜3列の単純なもの
見出しの行数	1行に収める。折り返すなら言い換える

図を主役にするスライドでは、テキストは見出しと導入の1行までにする。結論や応用は口頭で言えば済む。図の下に補足を2行足すと、図が縮んだうえ本文も詰まって、どちらも中途半端になる。文字を主役にするスライドでは、図は挿絵の大きさに留める。

見れば分かることを小さい文字で足さない。判定は「画面を見れば分かるか、今日の聴衆の判断が変わるか」の1つである。

• 画像、ロゴ、スクリーンショットに、それが何かを説明する文字を添えない
• バージョンや提供形態の但し書きは、聴衆の判断が変わるときだけ書く
• 締めの色文字、グレーの補足行、表の下の小さい注記を足さない
• 箇条書きは並べられるだけ並べない。4項目目を足す前に「これが無いと伝わらないか」を見る

新しく教える用語の初出は強調する

上の表の「強調は1スライドに1か所」とは別枠で、新しく教える用語や機能名は、地の文での初出1回を強調色の太字にする。

• 見出し・表・吹き出しの中では塗らない。2回目以降も塗らない
• 2つの用語を対比して導入するスライドでは、両方を塗る
• 同じ種類の用語は全部同じ扱いにする。1つだけ塗り忘れると、その用語だけ軽く見える
• 略語の後ろの括弧に添えた正式名は塗らない
• 強調で示すので、かぎ括弧では囲まない。見出しの中の用語、話し言葉の引用、画面のボタン名の引用は括弧のままでよい

見出しの文体は混ぜる

全部を敬体に揃えても、全部を常体に揃えても、機械が書いた資料に見える。常体、敬体、体言止め、問いかけ、「！」、口語の独白が入り混じり、その落差がテンポを作る。

1スライドごとに、どの型で書くかを先に決めてから文字にする。素直に書いてからあとで直す、という順序は取らない。敬体で発想した文を常体へ付け替えることになり、それ自体が不自然さの原因になる。

そのページの役割	見出しの型	例
図、コード、スクリーンショットが主役	体言止めの短いラベル（3〜6字でよい）	こうなりがち／アーキテクチャ例
主張、気づき	常体の言い切り	令和のAIエージェントは3行で書ける
驚き、良いニュース、転換	「！」で振り切る	デフォルトでストリーミング対応！
聴衆の心の声	口語の独白	よし、エージェント書けた！
想定反論への切り返し、宣伝、締め	敬体で落とす	…人生そんなに簡単じゃないんです
次のスライドへつなぐ	途中で切って引っ張る	技術的な下地は十分整ったが…
用語の導入	説明句と「用語」	AIに記憶をもたせる「メモリー」
中扉の問いかけ	「〜の？」	何を用意すればいいの？

不自然に聞こえる語尾

常体の言い切り全般が悪いわけではない。引っかかるのは次の2系統だけ。

敬体で発想した文の語尾だけを常体へ付け替えたもの。「割に合いません」を「割に合わない」へ、「育ちました」を「こうして育った」へ切り替えた文がこれに当たる。常体にしたくなったら語尾を切らず、体言止め、勧誘形（〜しよう）、「！」のどれかへ作り直す。

口語の砕けた語尾。「〜てる」（い抜き）、「〜ばいい」、「〜んです」は、機械が親しみやすさを演出するときの定番である。体言止め、「〜しよう」、「OK」へ置き換える。

rg -n '^# .*(てる|ばいい|んです)$' deck.md   # 0件が正

書き終えたら、全見出しを並べて数える

不自然さは語彙ではなく均一さとして出る。1スライドずつ見ると自然な日本語なので、通しで並べるまで気づけない。rg -n '^# ' deck.md で一覧にして実測する。作者の手作りデッキ2本（各57〜58スライド）の値は次のとおり。

指標	手作りの実測	外しているときの値
「！」を含むスライド	7〜20%	1%
「？」を含むスライド	10〜15%	7%
敬体のスライド	10〜12%	1%
最短の見出し	3〜6字	全スライドが15〜24字に揃う

型の反復も同時に数える。読点でタメて短く落とす二部構成（「覚える言葉は、この3つだけ」）、接続詞で頭を揃える見出し（しかも／実は／ちなみに）、コロン見出しの連発（「品質：」「量：」）は、3スライド以上続くと整理癖の署名になる。

ドキュメントの見出しルールをそのまま持ち込まない。READMEでは見出しを機能名の名詞に揃え、効能の売り文句を消すのが正しい。スライドでは逆で、聞き手を乗せるのが仕事なので「簡単」「〜するだけ！」は正当な要素になる。READMEの見出しは機能を探すための名札で、スライドの見出しは聞き手を次の話へ連れていく一言である。

本文も同じ目で数える

型の反復は本文にも出る。出やすいのは「Xすると、Yになります」「Xなら、Y」「Xしたら、Y」という条件＋読点＋帰結の形で、1文ずつは自然なので書いている最中には気づけない。1スライドに3つ並んだら、言い切り・体言止め・問いかけを混ぜる。箇条書き3行が全部「〜、〜」の同じ拍になっているときも同じ。

tools/check-ai-smell.py が、この型の反復と、決め台詞・過大な効能・地の文の終助詞などの定番の型を数える。既定では git の HEAD 版と比べて変わったスライドだけを見るので、既存のスライドを巻き込まず、新しく書いた文にだけ当たる。

python3 tools/check-ai-smell.py deck.md          # HEAD から変わったスライドだけ
python3 tools/check-ai-smell.py deck.md --all    # 新しいデッキは全スライド

引用枠と吹き出し

• 話し手の発言や実際のプロンプトとして載せる文は、実物のログからしか引かない。それらしい文を作文して「実際に言った」体で置くのは捏造になる。実物が無ければ、「実際に」という前提ごとスライドを書き換える
• 実物は原文のまま載せる。見栄えのために語尾を整えない。出典の注記（「実際のログより」）もスライドには書かない
• 色付きの引用枠へ、対句の格言のような「気の利いた一言」を入れない。入れてよいのは、具体的な工程・数字・実例と、実在するプロンプトだけ
• 吹き出しにスライドの結論を言い直させない。「大正解でした！」のような感嘆の要約ではなく、箇条書きに無い本音の具体を置く
• 枠は役割で塗り分ける。引用や話しかけ例は淡い地と枠線、結論のパンチラインはテーマ色のベタ塗りと白抜き。全部を同じ塗りにすると単調になる

結論の箱は繰り返さず、置くならページの最後

結論やまとめを入れる箱は、続けて使うほど目立たなくなる。

• 連続する5ページのうち、箱を置くのは2ページまで
• 本文の途中に置かない。箱の下に地の文が続くと、結論が結論に見えなくなる
• 箱を置きたくなったら、先に図にできないか、地の文で足りないかを考える。工程や分岐は箱より図が合う

補足のコラムのような色付きの箱も、デッキ全体で数か所に絞る。補足を見つけるたびに箱へ入れると、どのページも同じ見た目になる。吹き出しの直下と表の直下には置かない。形の似た濃い図形が縦に並んで重く見える。

過去のデッキがあるなら、そこから組む

同じテーマのパートが過去のデッキにあるなら、新しい資料はその組み合わせで作る。部品はたいてい既に存在していて、正しく組めばすぐ終わる仕事を、勝手な創作が何巡ものレビューに変える。

• 内容、順番、言い回しは原文のまま移植する。対で意味を成すもの（「理想はA → だめでもB」のような連鎖）を分解しない
• 手を入れてよいのは3つ。古くなった事実の更新、会場に合わせた最小限のつなぎ、尺のためのスライド単位の取捨
• 取捨に迷ったら勝手に落とさず、候補を並べて話し手に選ばせる。そのとき候補のスライドだけを見せない。前後2〜3スライドを含むブロックで、画像として並べる。ページ番号と要約の文章だけでは判断材料にならない
• 話し手が組み直しで外した枚を、肉付けの候補として戻しに行かない。過去のデッキを棚卸しするときは、構成メモで「入れて外した枚」を先に除いてから候補を出す
• スライドを足したくなったら、まず過去のデッキに実物が無いか探す。見出しで当たりを付け、PDFを焼いて目で確かめる。画像1枚だけのスライドは本文検索に出ない
• 見つけた実物は構造ごと写す。箇条書きを増やす、枠で締める、といった補強はすべて盛りすぎになる
• 定番のスライドを別のデッキへ移すときは、その図を含む全デッキを列挙し、いちばん後に直された版をコピー元にする。直っていない版は別のデッキに残り続ける
• デモをするスライドに専用の中扉を作らない。紹介スライドをそのまま映して実演する
• 導入用に作ったスライドを、別の文脈の中盤へ流用しない

再演の案件では、直前の回の構成メモを読むまで構成を提案しない。却下された案とその理由は、たいてい次の回にもそのまま効く。再演の依頼は「評判の良かったものをもう一度」なので、枠組みの作り替えは依頼の意図に反する。差を作るのは構成ではなく、事実の鮮度とスライド単位の入れ替えである。地方での開催は、聴衆の大半が初めて聞く前提で組む。

同じ元ネタから2会場ぶんのデッキが並行して育つと、項目ごとに新旧が逆転する。日付が後のほうが新しい、とは決めない。数字、図、言い回し、構成の1つずつを両方で突き合わせる。

派生のデッキで直したことを正本へ戻すときは、文面だけでなく構成（外した枚・動かした枚）も戻す。話し手の判断で外した枚と、章を寄せ直した並びは正本へ戻し、会場の尺で外しただけの枚は戻さない。文面だけ戻して構成を残すと、次の派生が古い並びから作られ、削ったはずの枚が復活する。尺に合わせて枚を削る抜粋版を作る前に、正本と直近の厳選版を見比べ、構成のずれが残っていないかを確かめる。

短尺版は、いちばん新しい正本1本を削って作る

複数のデッキから使えそうな枚を集めて繋ぐと、脈絡のない継ぎはぎになる。土台を1本に決め、そこから落とす方向だけで組む。

• 土台は、直近で本番を通した版にする。古いデッキの枚は磨き込みが足りず、表が詰まっていて図も古い。同じ見出しの枚が両方にあるなら、新しい側から取る
• 聞き手に合わせた差分は、汎用の短尺版を先に仕上げてから派生させる。数枚だけ直す形にすると、どこを変えたかがそのまま報告になる
• 枚数は尺から決める。削り切れずに他のデッキから足したくなったら、土台の選び方を間違えている

別の聞き手へ流用するときは、聞き手の手元の道具で1枚ずつ判定する

同じテーマでも、聞き手がすでに持っている道具と導入状況で、要る枚は変わる。導入前の組織に向けた枚（導入の手続き、製品の選び方、準備の手順）は、導入済みの組織には要らない。逆に導入済みの組織には、すでに使っている道具との使い分けを足す。

構成案を出す前に、全スライドを「その時点の聞き手が、手元の道具でできる話か」で判定した表を作る。

• 列は、枚番号・見出し・前提にしている道具・その道具はそこまでに登場済みか
• 概念の話も、例や効能が特定の道具でしか実現できないなら、その道具の前提に数える
• 前提の合わない枚は削らず、その道具を紹介した後ろへ移す
• 1枚足したら、その枚と役割の重なる枚を同じ作業のうちに外す

既存のデッキへ足したら、通しで数える

足したスライドは、1ページずつ見れば自然でも、通しで見ると浮く。既存のスライドが持っている癖（強調の入れ方、具体例の置き方、話題の担当範囲）が抜けるためである。足し終えたら、足した分と既存の分で次の3つを比べる。

• 強調の比率。既存には数ページに1回ずつ強調があるのに、足した分には1つも無い、という偏りが出やすい。上限だけでなく下限も見る
• 同じ具体例が2か所に出ていないか。足したスライドの例は、既存のスライドが担当していた話題と重なりやすい。固有名詞で rg -n して数える
• 尺。節を1つ足したら、スライド数の増減が小さくても着地時間を出し直す

既存の文を「元からある」と判断する前に、誰が書いたかを履歴で確かめる。デッキの中には、話し手が書いた文と、過去にエージェントが書いた文が混ざっていて、見ただけでは区別できない。

git log --format='%h %ad %s' --date=short -S'<その文の一部>' -- deck.md | tail -3

エージェントが書いた文だと分かったら、派生元のデッキも同じように直す。直さないと、次の登壇へそのまま乗り続ける。

直すとき

前後の枚と並べて見る

1枚を直す前に、前後2〜3枚を並べた画像で見る。1枚ずつなら問題なくても、並びで崩れることが多い。

• 同じ形式を3枚続けない。表が3枚続く、同じ位置に同じ色の箱が続く、は単調に見える。1枚を図や挿絵にする、表を後ろへ移す、箱の塗りを変える、左右を入れ替える、のどれかで崩す
• 1枚だけ際立たせるために、その枚だけ部品のデザインを変えない。そこだけ違和感が出る。共通の部品のまま、列の数と並べ方で差を出す
• 2つを対比させたい表に、3つ目の列（提供元など）を同じ並びで置かない。三並列に見えて対比が消える。対比の軸以外は行ラベルか本文へ逃がす。表を2つに割るのも見栄えが悪い。表をやめるなら、何を軸に並べたかが見出しと配置で分かる形にする
• 列が4つ並ぶ表は、大分類2つと小分類に階層化する（「手作り／AI任せ（下書きだけ・仕上げまで）」）
• 詰まったスライドを、文字を小さくして直さない。結論の箱は大事なことを言っているので、本文と同じ大きさに保つ。直す順は、①重複を削る（説明と引用で同じことを2回言わない）②レイアウトで空きを作る（挿絵を上へ移し、下のブロックを横に広げる）③それでも溢れたら前後の枚へ分ける
• 短くするときに意味を変えない。端折った結果、意味が通らなくなったり別の主張になったりしたら、要約ではなく改変である。直した文を元の文と並べ、同じことを言っているか確かめてから出す

指摘を受けたら

• 見出しへの指摘は、指摘された語だけを差し替えて済ませない。そのスライドが何を言うためにあるのかに戻って作り直す。読点を外しただけの見出しは、たいてい意味が伝わらなくなる
• 「浮いている」「流れがおかしい」と言われたスライドを黙って外さない。正本の流れでそのスライドが本来どこにあったかを探して移す。外すなら、外す候補として先に聞く
• 採否が決まったら、構成メモに記録して終わりにせず、同じ作業のうちにデッキへ反映し、書き出しと検査まで進める。反映するのは採用と言われたものだけにして、まだ採否を聞いていない案は報告で「未反映（未承認）」と分ける
• 直したら、全ページの一覧に加えて、直したスライドの Before/After を前後の枚ごと見せる。一覧だけでは、どこが変わったかを話し手が探すことになる。新しく足した枚には「新規」と印を付ける。印が無いと、いつからあった枚なのか分からない

1枚を消す・統合するとき

• 消す前に、その枚の中身（本文・箱・注意書き・吹き出し・脚注）を1行ずつ列挙し、別の枚へ移すものと一緒に捨てるものを示してから消す。頼まれたのが手順の削除でも、同じ枚に載っている補足（仕様変更の告知、プランの注意など）はたいてい残したいものである
• 消したあと、差分の削除行を見て、列挙に無い行が消えていないかを確かめる
• 2枚を1枚に統合するとき、消す側の文言を図の箱へ詰め込まない。箱に入れるのは短いラベル1行にして、消す側の説明は本文の1行か口頭へ回す。ラベルと説明の2行を箱に積むと、情報が詰まって機械が作った図に見える

講義・ハンズオンのデッキ

聞き手が手を動かす講義やハンズオンは、登壇のデッキより説明の責任が重い。画面が1つ違うだけで、参加者はその先へ進めなくなる。

手順

• 参加者が手を動かす操作は、1つも「〜したら」の前置きで流さない。ファイルのアップロードのように画面操作が要るものは、手順スライドを1枚立てて実機のスクリーンショットで示す。手順を組んだら、参加者の操作を1つずつ書き出し、どのスライドが受け持つかを突き合わせる
• 手順スライドは、番号つきの手順から始めない。冒頭に、何のためにその操作をするかを1〜2行のリード文で置く。用語の初出がリード文に来たら、強調もリード文へ移し、後ろのスライドの重複した説明は削る
• 番号つきの手順の外で、本文から画面操作を直接指示しない。「画像の1、2の順に押してください」のような指示は、スクリーンショットの番号と矢印が受け持つ。本文には、何が起きるか・どう進めるかを書く（「初回だけ、ファイルの読み取りを許可する必要があります」）
• 手順の文は、画面のどこを押すかが分かる書き方にし、画面の表記と一字一句そろえる（「左下のユーザー名から設定を開く」）。英語のドキュメントの表記ではなく、聞き手が見る日本語の画面に合わせる。書き出しは「サイドバーの◯◯をクリック」より「サイドバーから◯◯を開く」
• UIが変わりうる操作を「講師の画面を見てください」で済ませない。画面が違った参加者が進めなくなる。新しい画面での操作を公式ドキュメントで確かめ、1行で書く
• 講師の作業（「チャットに貼ります」）や運営上の案内（「会議ツールのチャットからコピーできます」）をスライドに書かない。口頭で足りる
• 参加者に送らせる依頼文は、デッキ全体で口調をそろえる。丁寧語を基本にして、タメ口の例と混ぜない。スクリーンショットに送信文が写っているなら、文面を変えたら撮り直す
• 依頼文の吹き出しや引用を単独で置かない。前に「AIにこう頼みます」のような導入を1行書き、中身はそのまま送って動く文にする。会話の中に無いファイルやURLを前提にしない

構成

• 見出しには、そのスライドで聞き手にしてほしいことを書く。付加情報（「保存しなくても大丈夫です」）は本文の最後に小さく添える
• 本文スライドの見出しに、説明の1文目を書かない。見出しはそのページの話題を指すラベル（「今回のハンズオンのシナリオ」）にして、説明の文は本文の1行目に置く（「あなたは来週、社内勉強会で10分話すことになりました。」）。主張や驚きを見出しにしてよいのは中扉である。本文の見出しが文になっていると、本文の最初の文と同じことを2回言う形になる
• テーマが変わる手前には中扉を入れる。本筋から外れる発展的な話は、「おまけ（発展編）」と付けて分ける
• 仕組みの図は、登場するものを全部同じ図に描いて関係を見せる。一部だけの図では、次に出てくる要素がなぜ出てくるのか分からない
• まだ紹介していない比較対象を前提にした書き方をしない。比べる相手が出てくるまでは、その道具だけの話として書く
• セキュリティのような補足は、便利さをひととおり話し終えてから補強として置く。聞き手が不安を持ちそうな瞬間に答えようとして機能の説明の直後へ差し込むと、便利さの話が途中で止まって浮く。補足1枚のために中扉を立てるのも釣り合わない
• 論文を見せるスライドは、1ページ目の画像の下に書誌のキャプション（「著者 ほか『タイトル』（会議名 年）」）を小さく付け、本文は日本語の説明だけにする。英語の書誌を本文に並べても、聞き手には情報にならない
• 用語は講義全体で1つに統一する。同じ概念の別名を混ぜない。別名は1か所で触れるにとどめる
• 聞き手の心の声を置くスライドには、前後に俯瞰した一文を付ける（前に「こんな声をよく聞きます」、後に「今日はそれを〜します」）。心の声だけだと、何のスライドか分からない
• 講座の表紙は、主催者が決めた回の正式名をそのままタイトルにする。社内の正式な場の表紙は、会社名・肩書・本名にして、SNSのIDを載せない

言い回し

• 講義の本文は丁寧語で書く。常体の言い切りばかりだと、講義の語り口にならない。箇条書きの短い項目は体言止めでよい
• 本文で急に「〜しよう」と呼びかけない。敬体の本文の中でタメ口に聞こえる。本文の呼びかけは「〜しましょう」にする。見出しの「〜しよう」は使ってよい
• 中扉は聴衆へ語りかける1行なので丁寧語にする（「理由は2つあります」）。ただし理由や項目を並べる中扉は、箇条書きの1項目なので言い切りにする（「時間が足りない」）。ハンズオンやおまけの名札にあたる中扉は「〜しよう」にする
• 緩急のための中扉は短い1行にする（「さっそく使ってみましょう！」）。次のスライドで話す製品名や前提を中扉に詰めない
• 新しく書く見出しに読点を打たない。「〜は、〜」「〜だけ、〜」と読点でためる見出しは、機械が書いた型に見える。話し手が口頭で指定した文言はそのまま使う
• 見出しを全角スペースで2つの語句に区切らない（「検品　全ページを並べる」）。2つ並べた意味が伝わらない。1つの普通の句にする。手順の番号（「手順1　〜」）は残してよい
• 動詞を名詞にした和語（「書き留め」「書き戻し」）を使わない。「メモを残す」と動詞のまま言う
• 抽象的な仕組みや状態を、体の動きの動詞で言わない（「手が止まる」「目標まで走る」「道具を持てば」）。「どう任せればいいのか分からない」「目標を達成するまで作業を続ける」「道具を使えば」と普通に言う
• 仕組みの説明を短い動詞で畳みかけない（「AIは下書きを出す。人が直す。だから速い」）。主語と動作をそろえた敬体の文で言う
• 注記（プランの制限など）は行頭に「※」を付ける。箇条書き・注記・箱のあいだは均等に空ける
• 強調に下線を使わない。色付きの箱の中の強調も、太字と色で付ける

書いたら、全ページを機械で拾う。

rg -n '^# .*、|^# .*　|手が止ま|走|しよう。|貼ります' deck.md

箱と表

• 引用ボックスや吹き出しにキャプション（小見出し）を付けない。何の文かは、直前の前置きを読めば分かるように書く。箱の種類は意味で分け、依頼文は吹き出し、聞き手の声は引用にする
• 依頼文の吹き出しは、しっぽを右下に付け、先端も右下へ向ける（border-width: 22px 0 0 24px で上辺だけ色を付ける）。左下だと、下の本文から生えているように見える
• 見出しの直後を表や図で始めない。表や図の前に、何の表かを言う地の文を1行置く。表の後に文があっても、先頭が表なら違反である。検査は「見出しの次の要素が | か ![ か」で全ページを数える
• 表の見出し行に空のセルを作らない。左上の角にも見出しを入れる
• 表と吹き出しは、前後の本文と間隔を空ける（表は上下1em前後、吹き出しは上22px・下52px程度）

他社の製品を並べて紹介するとき

• 「◯◯にあたる機能」と対応づける前に、各社の公式ドキュメントで機能単位に確かめる。名前や見た目が似ていても別の機能のことがある。話し手が実機で触った感触と食い違ったら、話し手の観察を正として調べ直す
• 機能はあるが振る舞いが違うなら、違いを1語で添える（「無料プランでは使えない」）
• ハンズオンは聞き手全員が使える道具で組み、他の道具は解説の後に「今使った機能は、他のサービスだと以下が近いです」と補足で紹介する。「◯◯にあたる機能です」と言い切ると、前のスライドとのつながりが見えない
• 並べる順はデッキ全体で1つに固定する
• 製品名は提供元が分かる形で書く。同じ名前の製品を複数の会社が出しているなら、会社名を添える
• 呼び方はデッキ内で統一し（Web版／デスクトップ版）、画面の表記は日本語のUIに合わせる。改称した製品は「（旧称：◯◯）」と添える

タイトルの型

よく読まれるタイトルは、読者の「遅れているかも」という不安を救う。「やさしい◯◯入門」「◯◯をやさしくおさらい」「まだ間に合う！」「今さら聞けない!?」。上から教えず、遅れても大丈夫と請け合う。

尺の見積り

スライドは持ち時間に収まって初めて成立する。構成が固まったとき、スライド数が5以上増減したとき、提出前、前日の4回、着地時間を出す。

• 単価は本文1スライドあたりで持つ。中扉と表紙は数秒で通過するので、1スライド8秒として別に数える
• 本文のスライド数は、総スライド数から中扉と表紙を引いて出す
• デモと質疑は、スライド数と無関係な固定枠として足す。ライブデモは画面の切り替えと待ち時間で0.5分を上乗せする

F="deck.md"; awk '/^---$/{n++} /_class: crosshead/{c=1} /^# /{printf "p%02d %s %s\n", n-1, (c?"[中扉]":"[本文]"), $0; c=0}' "$F"

単価は客層と枠の長さで変わる。下は作者の実測で、自分の実績が取れたら置き換える。

場	本文1スライドあたり
5分のLT	約30秒
10分のLT	約16秒（中扉を含む全スライドで割った値。35枚前後で組む）
15分前後の短い枠、スクリーンショット主体	約29秒
開発者向けカンファレンス（40分前後）	約37秒
オンライン配信（一般向け、40分前後）	約37秒
展示会、非エンジニア向け	約46秒

前提の説明を飛ばせるかどうかが単価に効く。短い枠では前置きも言い直しも消えるので速くなる。総スライド数に一律の秒数を掛ける計算は、本文と中扉を混ぜるぶん必ず遅い側へ外れ、要らない削減を提案することになる。

枠が短いほど単価は下がる。20分以下の枠に、45分枠の単価を当てない。長い枠の単価は前置きと言い直しを含むので、短い枠では大きく過大に出る。見積りを出す前に、同じ素材を別の尺で話したデッキの枚数と並べ、枠の長さに比例して枚数が増えているかを見る。余った時間を「口頭で厚くする」で埋める見積りにしない。話す中身が決まっていない時間は見積りではない。

• 会場での登壇は、枠ぴったりではなく5分弱の余裕を狙う。余裕が3分台なら、削れそうなスライドを2〜3個挙げて話し手に選んでもらう
• 講演と質疑が別枠で確保されたオンライン配信は、枠いっぱいで設計してよい
• 過去の実績から単価を逆算するときは、その回にデモや質疑が含まれていたかを先に確かめる。差し引かずに割ると単価が過大になる
• 事前に削るより、時計の基準点を決める。「この中扉を◯分より後に通過したら、後半のこの1スライドを飛ばす」の形で、2か所まで。中扉は飛ばさない
• 登壇後に、実績を1行だけ残す（「45分枠に対し約38分。デモなし、本文45スライド」）。次回の精度が変わる

ハンズオンは、話す時間と待つ時間を分けて積み上げる

パート単位でざっくり配分すると、見積りが膨らむ。1枚ずつ積み上げる。

• 話す時間は、本文1枚ずつ秒数を置く（中扉は8秒）。論文や仕組みの図は60秒前後まで伸びる
• 待つ時間は、参加者の1動作ごとに置く。設定を開く、ファイルを保存する、アップロードする、生成を待つ、結果を確かめる、つまずいた人へ案内する。大人数では全員を待たず、半数ほどの反応で進める前提にする
• 生成を待つ間に話せるスライドは、待ち時間と重ねて差し引く
• 時間が余るなら、見るだけ・聞くだけの箇所を参加者の操作に変える方向で考える。説明のスライドを足すより、学びが体験になる

検品

PDFへ書き出して1ページずつ見る。

1. 見出し1つと本文3〜4行を超えるスライドが無いか
2. 見出しが項目名になっていないか
3. 図が1スライドに2つ以上無いか
4. 強調が1スライドに2か所以上無いか。強調のあるスライドが本文の半分を超えていないか
5. 中扉の直後のスライドが、その問いに答えているか
6. 予告、まとめ、全体像の先出しが紛れていないか
7. 書き換えたスライドに tools/check-ai-smell.py を当てて、NGが0件か
8. 既存のデッキへ足した場合は、足した分の強調の比率と具体例が既存と揃っているか
9. 直したスライドを、前後の枚と並べて見たか
10. 講義・ハンズオンでは、見出しの直後が表や図で始まっていないか。参加者の操作がすべて手順スライドに載っているか

見た目の検査は slide-design-dark と tools/ を使う。