AIとスライドを作る進め方|「なんか違う」修正ループが終わらない人へ

Japanese hero banner for SIOS Tech.Lab: large dark blue text reads 'AIに頼むと修正が終わらない。' with logo in the top-right and decorative arrows on a pale background.

ども!最近、社内セミナーのスライドをAIと一緒に作り続けている龍ちゃんです。

「AIにスライド作ってもらえば楽じゃん」と思って、一発で頼んだことありますよね。わかります。僕も最初はそうやってました。返ってきたのは、きれいで整ったスライドでした。でも見た瞬間、「あ、なんか違う」ってなるやつです。

直そうとすると、直すたびに別の何かがズレる。修正ループが延々続いて、最終的に自分でほぼ作り直す羽目になる。何度か繰り返してようやく「これ、頼み方の問題だ」と気づいたんですよね。

今回の話は、「速くする魔法」でも「修正がゼロになる魔法」でもないです。作り直しはなくなりません。でも outline → storyboard → slide の3段階で順序立てると、「終わりの見えない無秩序な手戻り」が「1枚ずつ確実に良くなる往復」に変わります。具体的には「outlineで決めた核メッセージが、最後まで薄まらずに残る」「やみくもな作り直しが減る」この2点が変わる。速くなるかはセミナー次第ですが、ここは何本も作ってきた僕の実感です。

ツールはMarpでもSlidevでもPowerPointでも関係ない話です。「進め方」の話をします。

目次

なぜAIに一発でスライドを頼むと外れるのか

一発で頼むと「きれいだけどなんか違う」が出てくる理由は、ひとつです。

合意を飛ばして最終形を作らせているから。

スライドの確認は、細かく挙げればいくらでも出てきます。でもこの記事では、大きく3つのレイヤーに束ねて考えます。

  1. どこに着地させるか(誰に、何を伝えて、聞き終えたあとどうなってほしいか)
  2. 論理・整合性(主張の順序・飛躍・抜け漏れはないか)
  3. 見せ方(主役が一番大きく見えるか/変化量が一目で分かるか/抽象語が数字や図に変わっているか)

一発依頼はこれを全部飛ばして「見せ方の最終形」を出力させています。出てくるスライドはデザイン的にきれいですが、「頭の中で想像していた成果物」とは微妙にズレている。頭の中のイメージを、段階を踏んで渡せていないからです。

直そうとすると今度は「見せ方だけを直しているのか」「論理ごと変えているのか」「そもそもの着地点から外れているのか」が混在して、修正の手が止まらなくなります。これが延々続く手戻りの正体です。すでにある成果物に引っ張られて議論がとっ散らかるみたいなのもありますねw

レイヤーを切り分けて、順番に合意しながら一段ずつ具体に降りていく。それだけで詰まり方が全然変わります。


スライド作りを3段階に分ける(outline / storyboard / slide)

3つのレイヤーを整理します。「成果物ごとに読み手と決めることが違う」というのが軸です。

outline = 合意レイヤー

ここで決めるのは「どこに着地させたいか+そこに至る展開」です。逆に「ここでは決めないこと」もはっきりさせておくと、後工程がブレません。

ここで決める(書く)

  • 核メッセージ:これだけは持ち帰ってほしい、という1行
  • ペルソナ:誰向けか(役職・立場・知識レベル)
  • 尺:何分のセミナーか
  • 着地点:聞き終えたあと、どうなっていてほしいか
  • 大まかな展開:章立てと、各章の狙い
  • 核セクションの主張・根拠:言いたいことと、なぜそう言えるか

ここでは決めない(後工程に渡す)

  • スライド割り(1枚に何を出すか)→ storyboard の仕事
  • デザイン・レイアウト・見た目 → slide の仕事
  • 細かいトーク原稿・言い回し

「だいたいどういう展開になるか」までを人間が合意する場所、と考えると分かりやすいです。

outlineがズレていたら、以降が全部無駄になります。後工程すべての歯止めになる成果物なので、ここだけは人間が主導して固めます。

そして、ここが地味に一番大事です。着手前に「核メッセージ」と「合意」が取れるから、何周往復しても軸がブレない。outlineを先に固める価値はここにあります。

storyboard = 論理・整合性レイヤー

outlineを受けて、1スライド単位に落とした構成案です。ここでも「書くこと/落とすこと」を分けておきます。

ここで書く

  • スライド割り:1枚に何を出すか/何を言うか
  • 各スライドの役割:なぜそのスライドが要るか
  • 論理のつながり:主張の順序・飛躍・抜け漏れがないか

ここでは落とす(書かない)

  • デザイン情報(色・レイアウト・フォント)→ slide の仕事
  • 図の具体的な作り込み → レンダリングを見ながら slide で詰める
  • 核メッセージ・着地点の再定義 → outline が正

見た目を落とすことで、「論理の飛躍・順序・抜け漏れ」だけに集中できます。長くて人間が通読するのは正直しんどいんですが、それでいいんですよね。整合性チェックはAIの得意分野です。AIに「主張の飛躍はないか、抜けはないか」を見させて、人間も論理だけ確認する。
また、文章だけのMarkdownにしておくと、AIに渡すコンテキストも節約できます。

実際にやってみると、storyboardにはトランジション意図という欄も入れておくと便利です。「このスライドから次のスライドへ、何をバトンとして渡すか」を一行書いておく。後の章をまたぐ整合チェックで、これが判断基準として効いてきます。

「デザインが乗っていないからこそ、構造の良し悪しが見える」成果物です。

slide = 見せ方レイヤー

ここで初めてデザインに着手します。最終的に見るのは人間です。slideで「やること/やらないこと」はこうです。

ここで作り込む

  • デザイン・レイアウト・ビジュアル化
  • 主役の強調:主役にしたいものが一番大きく見えるか
  • 変化量・対比を一目で:抽象語を数字・図・具体例に
  • 理解のための補足:論理的には不要でも、伝わるために要る例示・対比・図・間

ここではやらない(差し戻す)

  • 論理構造そのものの変更 → 穴を見つけたら storyboard に戻す
  • 核メッセージ・着地点の変更 → outline が正

「このサイズ感では主張が弱い」「この情報量では伝わらない」を人間が判断するのがここです。

論理が通っている=人に伝わる、ではないんですよね。

上の「理解のための補足」がまさにそれです。論理的には不要でも、伝わるために要る見せ方がある。こういうのは、slideにして一枚の絵にし、受け手がどう感じるかを見て初めて分かります。storyboardでいくら論理を確認しても見えません。

だから往復が要ります。


storyboard ⇄ slide を往復してAIレビューで詰める

ここが記事の本体です。通し実例で見ていきます。

題材は架空の社内セミナー「生成AIを業務に取り入れる3ステップ」(20分・現場リーダー向け)です。中身はダミーで、フローだけ本物に揃えています。

まず outline を固める

こんな形で合意しました。

# outline:生成AIを業務に取り入れる3ステップ(20分)

核メッセージ:「いきなり全部AI化しない。小さく始めて、効いた所から広げる」

ペルソナ:現場チームのリーダー。AIに興味はあるが何から手を付けるか分からず止まっている。

着地点:「来週、自分のチームでステップ1を試せる気がする」

展開:
  S1. 掴み         3分  「AI入れたいけど止まってる」あるある共感
  S2. なぜ止まるか  3分  全部いっぺんにやろうとして詰む構造
  S3. 3ステップ    10分  核(ステップ1=小さく始める、2=効果を見る、3=広げる)
  S4. まとめ        2分  来週やる1個を決めて帰ってもらう

S3の各ステップ:
  ステップ1=小さく始める
    主張: 全業務じゃなく、1業務だけAI化する
    根拠: 失敗してもダメージが小さい/成功体験を最短で得られる
  ステップ2=効果を見る
    主張: 入れっぱなしにせず、効いたか測る
    指標: 作業時間の前後比較(数字を1つ)
  ステップ3=広げる
    主張: 効いた型をチームに横展開する
    順番: 1業務 → 2〜3業務 → チーム展開(段階を踏む)

ポイントは「各ステップの主張・根拠まではここで合意する、でも1スライドに何を出すかはまだ決めない」です。スライド割りはstoryboardの仕事です。

storyboard に落とす

outlineを受けてスライド割りをします。核の「3ステップ」の部分だけ抜粋します。

【スライド #6】ステップ全体像
  表示         : ステップ1→2→3 の横並び(矢印1本)
  トーク        : 「やることは3つだけ。小さく始める、効果を見る、広げる」
  意図         : 先に地図を見せて「3つで済む」と安心させる
  トランジション意図: #7で「1業務だけ」の具体に入るための準備。地図を渡す

【スライド #7】ステップ1=小さく始める
  表示         : 1業務だけAI化する図(before/after)
  トーク        : 「全部じゃなく、まず1個。例えば議事録の要約だけ」
  意図         : "小さく"の具体イメージを1つだけ持たせる
  トランジション意図: #8で「効いたか測る」に繋ぐ。1業務の成果を定量化する流れ

【スライド #8】ステップ2=効果を見る
  表示         : 時間削減のビフォーアフター(数字1個)
  トーク        : 「効いたか測る。ダメなら次の業務に乗り換える」
  意図         : やりっぱなしにしない、撤退もアリと伝える
  トランジション意図: #9で広げる前に「2〜3業務に増やす」段階が要る(outline参照)

【スライド #9】ステップ3=広げる
  表示         : 1業務→チーム全体への波及図
  トーク        : 「効いた型をチームに横展開する」
  意図         : 個人の成功をチームの成果に接続する
  トランジション意図: S4まとめへ。「来週1個やってみる」の行動につなげる

ここをAIに「論理の飛躍や抜けはないか」とレビューを依頼します。AIからすぐ返ってきたのは「#7で”1業務”と言ったのに、#9で急にチーム全体ではないか。#8と#9の間に”2個目・3個目に増やす”が抜けていないか」という指摘でした。

確かに。でもこれ、outlineには「1業務→2〜3業務→チーム展開(段階を踏む)」とちゃんと書いています。storyboard化の段階で取りこぼしていました。

slide にして初めて見えた2種類の不足

storyboardの論理を直してから、実際にslideに起こしました。人間が見ると、storyboardでは見えなかった不足がさらに2種類出てきます。

ちなみに、storyboardに図の具体まで先に書き込んでから実装するのは二度手間なんですよね(お恥ずかしいところですが、最初そうしようとしてました)。レンダリングした状態を見ながら詰めたほうが正確だから、slideで詰めてstoryboardに差し戻すのが自然な流れになります。これが往復が必要な理由そのものです。

論理の穴(storyboardに戻す問題)

上で気づいた「#8.5:2個目を足す」を追加すると、1業務→2〜3業務→チーム展開という段階がちゃんと見えるようになりました。これはstoryboard側の構造問題です。

論理は通っているが、人間の理解には足りない見せ方

ステップ1の「議事録の要約だけ」、言葉では伝わります。でもslideにすると地味で、主役にしたい変化量が一目で分からないんですよね。論理的には不要ですが、理解と納得のために「AIなし=30分 / AIあり=5分」の対比を1枚足したくなりました。

左右で言ってることは同じです。論理は1ミリも変えてない。変えたのは見せ方だけ。でも右のほうが「やってみたい」が一瞬で伝わりますよね。

こちらはstoryboardを眺めていても、経験則でしか埋めることができない領域です。slideにして人間が見て初めて分かる種類の不足です。

往復の単位は1スライド、積み上げていく

ここを正直に書いておきます。往復は1周で終わらないです。でも「全体を何十周も回す」というイメージとは少し違います。

実際の回し方はこうです。1枚ごとに「storyboardどおり実装 → PNG(またはプレビュー)で確認 → 対話で判断(このタイミングで後述の型1・型2を使います)→ slide修正 → storyboardに同期」を小さく回す。章が終わったら章まとめをして次章へ進む。揉めないスライドは1〜2往復でサクッと確定します。揉めたスライドだけ複数回往復する。1枚ずつ必要な分だけ往復するのが実態です。

重いレビュー(論理チェック・整合チェックを通しで回すやつ)は章ごとに要否を判断します。毎章必ずやるわけじゃない。「この章は揉めた箇所が多かったから締めにやろう」という判断です。

回し方はこうです。まず前半(掴みと「なぜ止まるか」)をスライド単位で順番に往復する。次に核の「3ステップ」を同じように回す。まとめも同様。そのあと、全体を通して「核メッセージがブレてないか」を確認する。

1周ごとに確実に1個ずつ潰れていく。回すほど、一発で出てきたものを超えていく感覚があります。最初から「何往復かするもんだ」と構えておくのがコツです。

なお、ここで使う outline・storyboard・slide のコピペ用テンプレは、記事の最後(付録)にまとめてあります。手を動かすときはそっちをどうぞ。

章をまたいでスライドの辻褄を合わせる

スライド単位の往復を積んでいくと、あるタイミングで「前の章と辻褄が合わなくなってきた」問題が出てきます。ここ、けっこうハマりやすいんですよね。

さっきの「生成AI3ステップ」の例で、実際に起きた2つの動きを紹介します。

例:先食いを防ぐ

「なぜ止まるか(全部いっぺんやろうとして詰む)」のスライドに、勢いで「で、答えは”小さく始める3ステップ”です」まで書きたくなったんですよ。そのほうが流れがいい気がして。でもstoryboardの「トランジション意図」欄を見ると、このスライドの役割は「”詰む”構造を見せて”じゃあどうすれば?”と引っ張る」ことでした。ここで答えまで出すと、次の「3ステップ」の章で初めて見せるはずの解を先食いしてネタバレになる。だから問題提起に徹して、解は次の章に温存。storyboardに「ここでは答えを出さない(3ステップの章へ渡す)」と注記して戻しました。改善案が”悪い案”だったわけじゃないんですよね。でも前後の章との関係で見ると、そこで出しちゃいけなかった。

例:回収先を設計する

「全部いっぺんは詰む」という問題を出すスライドと、「3ステップ」のステップ1「だから1業務だけ」という答えのスライド。この2枚は問題と答えのペアです。問題側に「だから小さく始めるのが大事」と結論っぽい一言を足したくなるんですが、それ、ステップ1と意味が二重になります。だったら問題側は「詰む」に徹して、「小さく始める」という結論はステップ1が回収する。論理が「詰む → だから1業務だけ(その裏返しの答え)」と一筆書きになります。storyboardでは問題側を「結論は持たせない、ステップ1で回収」と同期し、変更不要なステップ1側は「同期不要」と明示しました。

この2つに共通するのは、storyboardの「トランジション意図」欄が判断基準になったことです。スライド単体を見ていては気づけない。「このスライドから次へ、何を渡して何を温存するか」で見ていると見えてきます。

outline は「照らす基準」として使う

往復するのは storyboard ⇄ slide です。outline は往復に巻き込みません。最初に合意した内容を、途中で変えない基準として使います。往復のたびに、outlineに戻って同じことを確かめるだけです。たまにですが、AIと話していくと主張そのものがずれていく時があります。そういう時は、outlineを正として評価することで行き過ぎを防げます。

今回の実例で確認するとこうなります。

変更内容outline照合判断
#8.5「2個目を足す」を追加「1業務→2〜3業務→チーム展開」と一致採用
#7に時間対比スライドを追加現場リーダー向け・数字対比は効く採用
「ステップ4:全社展開」を足したくなった「現場リーダー・小さく始める」から外れるoutline変更に格上げして判断

「全社展開」はstoryboard側の往復では決めません。outlineを変えるかどうかの判断に格上げします。outlineをコロコロ変えると、そもそも合意した意味がなくなりますよね。
だからと言って、outlineを変更しないと意固地になるのもよくないです。そこは柔軟に判断します。

AIにスライドをレビューさせるプロンプトの型(コピペ可)

往復の中でAIに投げるプロンプト、実際にやってみると「型」が決まってくるんですよね。特に効いたものを3つ紹介します。

AIが速くやってくれるのは論理チェックと整合確認です。でも投げ方を間違えると「全部直してしまう」「同じレビューを3周回す」という過剰改修ループにはまります。

型1:改善案の衝突検出

この slide で [こういう改善/追加] をしようと思う。
storyboard #N の「設計意図(トランジション意図)」と衝突しないか先に確認して。
特に、前後のスライド(#N-1 / #N+1)の役割を侵食したり、
後段で出すはずの要素を先食いしていないかを見て。

AIがstoryboardの意図欄を引用して「衝突するのはこの1点」と限定して返してくれます。OKならslide修正、衝突なら設計を守る方向に案を絞ります。往復手順の「対話で判断」ステップで、まず最初に使うのがこれです。

型2:章をまたぐ要素の重複チェック

この要素、後段のスライドと意味が二重になっていないか?
二重なら、どちらのスライドで回収するのが論理が一筆書きになるか。
このスライドの役割を一言で言うと何で、残りはどこが引き取る?

型3:レビューに歯止めをかける

この章(スライドN〜M)の論理だけを1回チェックして。
何周も回さなくていい。直すのは論理が破綻している所だけ。
表現の好みや言い回しは触らないで。

「1回だけ/何周も回さない/直すのは論理破綻だけ/表現は触るな」というのが肝です。歯止めを書かないと、AIは丁寧に何周も直そうとして、いじらなくていい所まで変えてきます(笑)。過剰改修ループを避けるための、意外と大事な一行です。

AIレビューを観点ごとにエージェント化する

型1〜3、最初は毎回手でコピペして投げてました。でも何本も作ってると「毎回同じこと言ってるな」と気づくんですよね。僕はこの型を Claude Code のエージェントに落とし込んで、「論理だけ見る奴」「辛口で殴る奴」「ペルソナになりきる奴」みたいに観点ごとに分けて持ってます。

ここはツールの力を半歩借りる話なので、進め方の本筋からは外れます。でも「どういう目線でエージェントを作るか」だけは、この記事の背骨とまったく同じなので置いておきます。

1エージェント=1観点。混ぜない。

これ、storyboardでデザインを落とすと論理が見えてくる、という話と同じ構造です。レビューも観点を1つに絞るから良し悪しが見える。

どれくらい絞るかというと、採点の起点からして観点ごとに逆になります。同じスライドを渡しても、論理を見る奴は「破綻がなければ100点」から始める。辛口で殴る奴は「とりあえず0点(ゴミ箱行き)」から始めて、なぜダメかの証拠を挙げにいく。観点が違えば見方の前提ごと変わるんですよね。1つの奴に全部やらせると、この前提が混ざって焦点を失います。

そしてもう一つの肝が、各エージェントに「何を見ないか」を書いておくこと。論理担当には「“このペルソナは離脱する”みたいな感情の話はするな、それは別の奴の仕事だ」と明示してあります。型3で「論理だけ見て、表現は触るな」と歯止めをかけたのと同じことを、エージェントの定義そのものに焼き込んでるわけです。

逆に「全部いい感じに見て」という何でも屋を作ると、返ってくるのは“きれいだけどなんか違う”レビューの裏返し——「色々指摘されたけど、で、何を直せばいいの?」という焦点のないやつになります。一発依頼が外れるのと同じ理由ですね。

実際こうやって作っています

こういうエージェント、いろいろ作っていて、今は僕の環境で29個動いてます。レビュー系だけじゃなく検索や下書き用も混ざってますが、考え方は全部同じで「1個=1仕事」。ここでは、いま話したスライドレビューの中から2個だけ、「何を渡して/何を見させて/何を見させないか」の形で出します。

1つ目は、見せ方の評価で効くペルソナに憑依する奴。この記事でずっと「誰の目線で見せ方を評価するか」と言ってきましたよね。それをそのままエージェントにしたものです。

エージェント:現場リーダーになりきる奴(ペルソナ憑依)

与える情報:
  - ペルソナ設定(現場リーダー。AIに興味はあるが何から手を付けるか
    分からず止まっている = outlineで決めたペルソナそのもの)
  - レビューする章のスライドだけ(例:S2「なぜ止まるか」)
  - ※先の章(解=3ステップ)は渡さない=先読みさせない

見る観点(これだけ):
  - 1枚ずつ前から体験して「いまの気持ち」を返す
  - 温度が上がったか下がったか(↑→↓)、内心の声、冷めた/警戒した点

見ないもの:
  - 点数化・ランク付け(しない)
  - 俯瞰で構造の良し悪しを論じること(それは別の奴の仕事)

2つ目は、型3「論理だけ見て、表現は触るな」をそのまま常駐させた論理だけ見る奴です。

エージェント:論理だけ見る奴(型3を固定したもの)

与える情報:
  - storyboard と slide(論理の通りを確かめたい範囲)
  - 見る章の範囲(例:S3「3ステップ」全体)

見る観点(これだけ):
  - 主張→結論の飛躍、用語のすり替え、回収されない伏線、抜けた依存、矛盾
  - 破綻がなければ「論理的に破綻なし」で終える(無理に粗探ししない)

見ないもの:
  - 表現の好み・言い回し(=型3の「表現は触るな」そのもの)
  - 「このペルソナは離脱する」みたいな感情の話(別の奴の仕事)
  - 鮮度や物理限界(「30分で15枚は多い」等)

2つとも、効いてるのは「与える情報」です。ペルソナの奴に渡す人物像は outline で合意したペルソナそのもの。論理の奴に渡す範囲は、いま整合を確かめたい章だけ。何を見させたいかは、何を渡すかで半分決まるんですよね。先読みさせたくないなら先のスライドを渡さない。ここでも outline がマスターとして効いてます。

こちらのエージェントは一番汎用性を持っています。

エージェントの具体的な中身(どう定義して、どんな出力が返ってくるか)は、それだけで1記事になるので別記事に書きました。ここで持って帰ってほしいのは「型が固まったら観点ごとに固定する、ただし1エージェント1観点で混ぜない」という目線だけです。

スライド作成で人間とAIをどう分担するか

このワークフローは「全部AIに任せる」ではありません。作業はどんどんAIに任せます。でも「何を言いたいか」だけは、人間が絶対に手放しちゃいけない。任せきると、主張そのものが消えるからです。

まず、レイヤーごとに任せられる所と、人間が握り続ける所を整理します。

レイヤーAIに任せる人間が握る(手放せない)
outlineペルソナ分析の素案、展開パターン提案、抜けの指摘何を伝えたいか・どこに着地させるか(意志)、誰に向けるか
storyboard論理の飛躍・整合性・順序・抜けのチェック、長いmarkdownの通読「この主張は本当に言いたいことか」の取捨、優先順位
slideデザイン量産、レイアウト案、ビジュアル化主役が一番大きく見えるか・変化量が一目で分かるか(見せ方の最終判断)、ペルソナ目線の評価
往復・歯止め差し戻し後の論理破綻の再チェック大枠を変えるかの意思決定(outline変更への格上げ判断)

では、なぜ「何を言いたいか」だけは手放しちゃいけないのか。これ、最初から分かってたわけじゃないんですよね。正直に言うと、一度ぜんぶ自動で回せないか試したことがあります。outlineだけ人間が作って、storyboard以降の往復はエージェントにループで回させる、みたいな。

結果、うまくいきませんでした。理由が大事で、エージェントって基本「引き算」する装置なんですよ。僕が作ってるレビュー用エージェントは「自分に足りない観点を補う」ために作ってる。つまり「ここが弱い」「ここは要らない」と削る方向に働く。これをループで回すと、回すほど引き算が続いて、最後は人間の主張そのものまで削られて核が落ちる。論理だけ厳しくしすぎた結果、整ってるけど何も言ってない、伝わらないスライドが出来上がるんですよね。

もう一つ厄介なのが、AIを説得できてしまうこと。「ここ弱くない?」に対して「いや、ここは意図してこうしてるから論理は通ってる」と返すと、AIはわりとすんなり「たしかに」と引き下がります。こっちが間違っていても、です。本来きびしい批判者だったはずのエージェントを、自分の言葉で丸め込めてしまう。しかも同じセッションで続けてると、その“説得した履歴”が溜まって、どんどん寄り添ってくる(=甘くなる)。だから僕は要所でセッションを切って、まだ説得されてない新しい批判者に戻します。これは人間が意識してやる設計です。

だから結論はこうです。正(マスター)=「何を言いたいか」は、人間が手放しちゃいけない。エージェントは優秀な批判者だけど、言いなりになると主張ごと消す。だから僕はエージェントとは“喧嘩する”くらいの距離感で使ってます。outlineをマスターに固定したのも、結局これと同じ理由なんですよね。

ちなみに、ここを乗り越えて往復をループでぶん回せるようにするには、削るエージェントだけじゃなく「主張を守る側」のエージェントも要るはず。それをいま、どんな形で作ればいいのか模索しているところです。

AIが速くやってくれるのは「論理チェック・叩き台生成・デザイン量産」という作業です。逆に、意志と人間理解の判断 ──「何を言うか」「誰にどう伝わるか」── は、そもそもAIに渡しちゃいけない種類だから残ります。「効率化されなかった」んじゃなくて、渡しちゃいけないんですよね。作業が速くなった分、スライドの「きれいさ」より「核メッセージをどう通すか」に頭を使えるようになりました。

ツールはMarp / Slidev / PowerPointどれでもいい(往復しやすさの差)

進め方そのものはMarpでもSlidevでもPowerPointでも同じです。道具の前に進め方があります。

ただ、往復を前提にすると「storyboardとslideは近くにあるべき」という論点が出てきます。

storyboard も slide も同じリポジトリにテキスト(markdown)として置けるツールほど、論理⇄見せ方の行き来がラクになります。slideもmarkdownなら、storyboardと並べて差分で管理できるし、AIも両方そのまま読める。AIへの指示や人間の判断という手間は残りますが、少なくとも「slideを別ファイルに書き出して同期する」手間が消えます。

PowerPointで一度やったことがあって、storyboardのmarkdownを直してもPowerPointに戻すのが面倒で途中から同期が崩れました。結局スライドだけ手動で直してstoryboardが古いまま残るパターンです。とはいえ、PowerPointやGammaしか使えない場面もありますよね。その場合は、storyboardを別のmarkdownで持っておいて、スライドを直したら人間が手でstoryboardにも反映する。運び役を自分でやれば、道具を問わずこのworkflowは回せます。

ツール別の具体(セットアップや使い分け)は、末尾のシリーズ記事にまとめています。

まとめ:AIと往復しながらスライドを作る進め方

outlineを動かさず、storyboard ⇄ slideを1枚ずつ往復する(上の図のとおりです)。

往復で何か直すたびに、outlineに戻って同じことを確かめます。

  • 核メッセージが、最後まで薄まらずに残っているか
  • 誰の目線で見せ方を評価しているか

一発依頼が外れるのは、このレイヤーを全部飛ばして最終形を出力させているからです。一段ずつ具体に降りながら合意していくと、「なんか違う」が消えて、「終わりの見えない手戻り」が「1枚ずつ前に進む往復」に変わります。

試行錯誤の順序を変えて、AIが読める中間ファイルを挟んで、1枚ずつ往復しながら回す。それだけです。やみくもな作り直しが減って、outlineで決めた核メッセージが最後まで残る。速さはセミナー次第ですが、この2点は何本も作ってきた僕の実感です。

スライドの作り方そのものの話はここで一度切ります。実際の道具の話は、この下のシリーズ記事にまとめてあります。

ほなまた〜

シリーズ:AI×スライドづくり

AIに丸投げせず、制約とルールで「意図どおりの95点」を毎回そろえて作るシリーズです。

付録:outline の型(コピーして使ってください)

「で、最初のoutlineって何を書けばいいの?」という人向けに、僕が毎回使っている型を置いておきます。いきなり「スライド作って」と投げる代わりに、これを埋めてからAIに渡す。それだけで話が一気に早くなります。

# outline:[タイトル]

## 設計思想
- 核メッセージ:[1行。これだけは持ち帰ってほしいこと]
- ターゲット   :[誰向け。役職・立場]
- 想定参加者像 :[どんな状況・知識レベルか]
- 応えるべき問い:[参加者が内心抱えている問い]
- 着地点       :[聞き終えたあと、どうなっていてほしいか]

## セクション構成(全N分)
- S1. [掴み]   (N分)狙い:[一言]
- S2. [...]    (N分)狙い:[一言]
- S3. [核]     (N分)狙い:[一言]
- S4. [まとめ] (N分)狙い:[一言]

## 各セクションの中身(主張まで。スライド割りはまだしない)
[核のセクション]
  - 主張:[このセクションで言いたいこと]
  - 根拠:[なぜそう言えるか]
  - 例  :[具体例]

ポイントは「各セクションの主張・根拠までは決めるけど、1スライドに何を出すか(スライド割り)はまだ書かない」こと。スライド割りは次のstoryboardの仕事です。

埋め終わったら、AIにこう渡します。

このoutlineをstoryboardに起こして。
各スライドは「表示/トーク/意図/トランジション意図」の4行で書く。
デザインのことは書かないで、論理と構成だけ詰めて。

付録:storyboard の型(1スライドの記法)

storyboardに落とすとき、1スライドの書き方に迷ったらこの雛形を使ってください。

【スライド #N】[スライドタイトル]
  表示         : [スライドに出す要素。図・テキスト・数字など]
  トーク        : 「[このスライドで実際に話すこと。1〜2文で]」
  意図         : [このスライドがある理由。聴衆に何を持たせたいか]
  トランジション意図: [次のスライドへ何を渡し、何を温存するか。1行で]

ポイントは「デザインのことは書かない」ことと「トランジション意図を必ず書く」ことです。後者は章をまたぐ整合チェックで判断基準として効いてきます。

付録:slide を見るときの問いの型

slideをレンダリングして人間が目で見るとき、僕が自分に問うチェックリストです。storyboardの論理チェックでは見えてこない、見せ方レイヤー固有の問いです。

【主役の強さ】
- このスライド、主役にしたいものが一番大きく・目立って見えてる?
- 変化量や対比が、一目で分かるサイズ・配置になってる?
- 抽象的な言葉が、数字・図・具体例に変わってる?

【補足の必要性】
- 論理的には要らないけど、"理解のため"に足したい補足はある?
  (対比・例示・補足の一言など。あるならslideに追加してstoryboardに差し戻す)

【前後との関係】
- 前のスライドと役割がかぶってない?同じことを二重に言ってない?
- 後のスライドで出すはずの要素を、ここで先食いしてない?
- このスライドから次へ、何を渡して何を温存する設計になってる?

これをstoryboardの「トランジション意図」欄と照らし合わせながら見ていくと、往復の精度が上がります。

ここから先は、本文で書いた storyboard ⇄ slide の往復に入っていく、という流れです。

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。
エンジニア募集中!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です