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

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

この型は、作者（みのるん）が数年分の自作デッキを読み返して抽出したもの。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 で履歴を整える」は「変更の記録を整理する」にする。名前を知らない人にとって、名前は情報にならない

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

そのページの役割	見出しの型	例
図、コード、スクリーンショットが主役	体言止めの短いラベル（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ページずつ見れば自然でも、通しで見ると浮く。既存のスライドが持っている癖（強調の入れ方、具体例の置き方、話題の担当範囲）が抜けるためである。足し終えたら、足した分と既存の分で次の3つを比べる。

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

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

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

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

タイトルの型

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

尺の見積り

スライドは持ち時間に収まって初めて成立する。構成が固まったとき、スライド数が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秒
15分前後の短い枠、スクリーンショット主体	約29秒
開発者向けカンファレンス（40分前後）	約37秒
オンライン配信（一般向け、40分前後）	約37秒
展示会、非エンジニア向け	約46秒

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

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

検品

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

1. 見出し1つと本文3〜4行を超えるスライドが無いか
2. 見出しが項目名になっていないか
3. 図が1スライドに2つ以上無いか
4. 強調が1スライドに2か所以上無いか。強調のあるスライドが本文の半分を超えていないか
5. 中扉の直後のスライドが、その問いに答えているか
6. 予告、まとめ、全体像の先出しが紛れていないか
7. 書き換えたスライドに tools/check-ai-smell.py を当てて、NGが0件か
8. 既存のデッキへ足した場合は、足した分の強調の比率と具体例が既存と揃っているか

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