まずはこのスライドを見てください。これはこの記事の内容からGeminiで生成したスライドです。
https://gemini.google.com/share/440c57937c4e
※見れない場合はこちら
どうでしょうか？
AI生成のスライドを見慣れていない人は結構衝撃的に感じるクオリティだと思います。見慣れている人にはそこまででもないかもしれないです。
このスライドはプロンプトを作り込んだわけではなく、プロセスを整理して事前に定めたルールに沿ったファイルを用意しておくことで、ある程度どんなものが出てくるかを制御して生成させたものです。
AIのランダム性をかなり排除できていて、何度生成させてもだいたい同じようなスライドが生成されますし、内容を変えても同じような見た目で生成されます。
この記事は、AIによるスライド生成についてどのように考えて活用していくのがよいのかを、自分の考えを整理するためにまとめた記事になります。
途中で出てくるファイルや生成させたものは以下に置いてあります。
https://github.com/hurry-co-jp/ai-slide-design/tree/main
はじめに
今までにもスライド作成AIはありましたが、Geminiのスライド生成対応、Nano Banana ProおよびNotebookLMのスライド生成機能が登場したことでかなり雑な指示でも簡単にそれっぽいスライドを生成できるようになりました。
しかし、何度かAIに生成させたものを見ていると「なんか既視感あるな、AIっぽいな」という感覚になってきます。
また、同じ内容で生成させても毎回異なる内容、異なるデザインで生成されるため、文章や画像以上にいい感じのものを生成してもらうことが難しいです。
これでは簡易的なその場しのぎのスライドとしては通用しても、ちゃんとした発表で使うスライドとしては流石に厳しいものがあります。
そこで同様のことに課題意識を持った人たちが多くの工夫を考えていますが、中でもとくに再現性が高くて汎用性があると思えたのが以下のような「情報を構造化して与える」というアプローチです。
https://note.com/yoshifujidesign/n/n7412bccb5762
https://note.com/samuraijuku_biz/n/ncace2a0775ac
私は今までもAIと対話していてある程度考えがまとまったら一旦MarkdownでまとめさせたりMermaid形式のフローチャートなどで整理させたりしていたのですが、アウトプットにランダム性のあるAIに対してはこのような構造化された形式で出力を行わせると、格段に自分とAIとの認識を一致させやすくなると感じています。
ちょっと認識が違うときは出力されたものを自分で修正して渡すことで、AIに対してだいぶ正確に意図通りの修正を行わせることもできます。
同様のやり方をスライド生成に対しても行えば、当然スライドも格段に自分の意図通りのものを生成させやすくなると考えられます。
そこで今回はエンジニアリングの観点からプロセスを分解し、適切に制御することで効率的に実用的なスライドを生成させることを目指します。
プロセスを考える
1記事にしようとしたら思ったより長くなってしまったので、フロー図を作るところまでの思考過程は以下の記事に分けています。
最終的に以下のフロー図を作成しています。
実際にやってみる
今回の記事の内容をテーマとして、実際に上記で考えたプロセスでスライドを生成させてみます。実際に使ったのはGeminiとNotebookLMです。
インプットの用意
「原稿」はこの思考過程の記事の文章とします。
「デザイン定義書」、「レイアウト定義書」、「スライド設計書サンプル」は適当にAIで生成します。
「レイアウトリファレンス」は用意するのが面倒なのでどうしようかと思いましたが、レイアウト定義書だけからスライドを作らせたらとりあえず最低限使えそうなものができたので、これをレイアウトリファレンスとします。正直このレベルでどれだけ効果があるのかは不明ですが。
なお、NotebookLMではYAMLやJSONなどの構造化データとして用いられる形式のファイルをサポートしていなかったため、もともとYAMLを想定していたものは拡張子だけmdにしてMarkdownファイルとしています。箇条書きのみのMarkdownで表現していると思えば、おそらくこれで何か大きく影響でるようなことはないでしょう。
スライド設計書を作成する
用意したインプットをAIに渡します。
上述したように、原稿以外は適当にAIでサクッと生成させたものです。今後使うことを考えてもっと作り込もうかと思いましたが、意外とこの程度でもそれなりのスライドが生成されたのでまぁいっかとしています。
- 原稿.md
- 原稿から参照させる画像など（今回は無し）
- デザイン定義書.yaml
- レイアウト定義書.yaml
- レイアウトリファレンス.pdf
- スライド設計書サンプル.md
アップロードが終わったら以下のような指示を出します。
「原稿とスライド設計書サンプルをもとに、13ページ程度のスライド設計書を作成してください。」
これでスライド設計書の叩き台ができます。
本来はこれを精査して適宜修正していくべきですが、今回はとりあえずそのまま使うことにします。
スライドを作成させる
前述したように、ここでAIにどんなアウトプットを出させるかが、大きなポイントになります。
現状話題になっているNotebookLMでは、普通にスライドを生成させたら画像として生成されます。
しかし、画像では人間による修正が困難です。
ここでPowerPointの構造を思い返してみると、PPTXファイルの中身は画像ではなくXMLの集合体です。
MarpというMarkdown形式でスライドを作成できるツールもありますし、reveal.jsというHTML形式でスライドを作成できるツールもあります。
要するにスライドは構造化されたテキストを作れば作成できるのです。
テキストであれば人間が編集することは容易ですし、構造化されたテキストを生成するのはAIの得意とするところです。
そして、GeminiのCanvasを使って生成したスライドはHTMLとCSS（＝テキスト）で作られたものであり、さらにGoogleスライドへエクスポートして細かい編集を行うことが可能です。
このことから、生成後に人間が手を加えたいということを考えると、 「現状のGeminiでは」 Canvasでスライドを生成するのがよいかと思われます。
注意しておきたいのは、Gemini→Googleスライドは一方通行だということです。
つまり、Googleスライドにしたあとに変更したものをもとのファイルに反映させるには手動で頑張るしかありません。
スライドだけが成長して原稿とスライドの内容が乖離してしまうと、もとの原稿が使い物にならなくなってしまいます。
そのため、Googleスライドにしたあとの変更は軽微なもののみに留めておき、大きな変更を行いたい場合はもとのファイルの方を見直して再度AIに生成させ直すというやり方にするのがよいと思います。
これでできたものが、冒頭でリンクをはった以下のものです。
https://gemini.google.com/share/440c57937c4e]
Googleスライドにエクスポートできなくなりますが、少し指示を与えるとコードとプレビューを切り替えて表示できるようになるので、実際にどんなHTMLが生成されているのかを見ることもできます。
※右下のトグルボタンで切り替える
https://gemini.google.com/share/bfbe363ffee8
※GitHubに置いてあるものと同じです。
評価と考察
- 各ファイルが意図通りに認識されている
- スライド設計書がサンプルで示した通りの意図で生成されている
- スライド設計書と完成版のスライドを見比べると、しっかり指示通りのレイアウトで表現されている
- 再現性が高い
- 何回か生成してみると、多少のブレはあるが概ね同じようなデザインのスライドが生成されている
- 画像を載せたいときは使ってほしい画像をあらかじめ用意しておいた方がよい
- AIがそれっぽい画像を生成してくれるが、見ての通りなんかそれっぽいけど内容のない画像になっている
- 別途AIで作成させたものを使うのは別にいいが、ここで試行錯誤するのは明らかに非効率
- 原稿を作ってからドラフト版のスライドを作るまでが数分で終わる
- テキストなので生成コストが低く、運任せの試行錯誤ではなくインプットとなるファイルを作り込むための試行錯誤になるため、着実に洗練させていける
なお、前項で 「現状のGeminiでは」 と書きましたが、今回のポイントは以下の2点です。
- 画像ではなくHTMLでスライドを生成させた
- 生成後のHTMLをスライド作成ツール（今回はGoogleスライド）で編集可能な形式にした
これと同様のことはプロンプトの与え方次第で他の生成AIサービスでも実現可能なため、「Geminiだからできる」というわけではありません。
たしかにGeminiはCanvasという機能でスライドを生成させることが想定されており、そこからワンクリックでGoogleスライドに落とし込めるようになっているため、プロンプトを作り込まなくても簡単に再現が可能という点で優れていると思います。
しかしAIの進化は早く、いろいろなサービスや使い方も日々登場しているため、翻弄されないためにも「どういうAIの使い方をしたらどういうものができるのか」というプロセスで理解しておくのが大事だと思います。
エンジニアリングによるメリット
改めて考えてみると、スライド作成の目的は「自分の考えを相手に伝えること」です。デザインにどれだけ頑張ったのかを見せたいわけではありません。
とはいえ、読みづらいスライドでは内容は伝わりません。しかし、プロレベルの「伝わるデザイン」を作るには、専門的な知識と経験が必要です。
ここでAIに期待することは、「とりあえず最低限のクオリティでいいから手早くいい感じのスライドを作ってほしい」です。
ですが、デザインスキルのない私には「最低限のいい感じ」が具体的にどんなものなのかイメージできません。
この状態でAIとの対話を頑張ってプロンプトを工夫していっても、「なんかいい感じ」と感じるスライドが出てくることを祈って試行錯誤を繰り返す作業に時間を費やすことになってしまいます。全然手早く作れていません。
もちろん一発でいい感じの「当たり」が出てくる可能性もありますが、何回やってもピンとこない「ハズレ」が出てくる可能性もあります。まさにガチャです。しかも当たりの確率は誰にもわかりません。なんなら当たりなのかどうかも明確にはわかりません。
AIの進化やプロンプトを工夫することで当たりの確率が2倍や3倍になるかもしれませんが、根本的に運任せだということには変わりないです。
しかし、今回のやり方では着実に「これを作れば前に進むはずだ」という作業を積み重ねていくことになります。
「1%の確率で引けるSSR」が「このタスクを終わらせれば確実にもらえるSSR」になるようなイメージです。
これこそが、今回の「エンジニアリングする」というアプローチの活きてくるところだと考えます。
本来注力すべき原稿さえ作れば、後はあらかじめ用意しておいたデザイン定義書などと一緒にAIに投げることで、ある程度予測可能な完成度のスライドが極めて短時間で生成されることになります。
これはつまり、「やってみないと何時間かければ納得のいくものが作れるかわからない」から「原稿を作ってから数十分あればとりあえず体裁の整ったレベルのものができるはずだ」のように具体的な見積もりをできることになります。
あるいは数十分あればスライド化までできるのだから、原稿作成→スライド化→原稿修正のサイクルを何度も繰り返して完成度を高めていくといったやり方をしてもいいと思います。
こうなることで、上手くいかなかった場合はどこに問題があったのかを振り返って改善ができます。
運任せのガチャのままでは当たりが出なかったのが悪いとしか言えず、とにかくリソース（≒時間）を増やして試行回数を増やす以外には改善できません。もしくは、結局AIはまだ使い物にならないという結論になって使わなくなるかもしれないです。
まとめ
「情報を構造化して与える」というアプローチで、なるべく意図通りのスライドを生成させるプロセスを考えてみました。
AIによる高精度な画像生成が必須となるプロセスではないので、今までのAIでも十分実現できたことになります。実際、HTMLでスライドを作ることが当たり前になっていた人たちは以前からこのような方法で作成していたのではないでしょうか。
AIがバージョンアップしたときにポン出しを見て一喜一憂したり、小手先の工夫だけして微妙な使い方をしないよう、現状での全体的な整理と今できることやAIがどれだけ進化しても変わらないことなどを理解しておくことは大事だと思いました。
なお、途中で察した方もいるかと思いますが、今回整理したこのプロセスはAIを使う場合だけでなく、人間に指示を出す場合を想定しても同じやり方で概ね上手くいくだろうということが予想できます。
人間に対して「いい感じでやって」と言っても、自分の意図通りのものを作ってもらうなんてことはできません。しっかり言語化して、必要なものを用意して、相手にやってほしいことを伝えて、ようやく相手は自分の意図に近いものを作れるようになります。
AIは雑な指示でも文句を言わずに簡単にそれっぽいものを生成してくれますが、それは意思のない平均的な正解の寄せ集めです。
かといって、AIを使ったらそれは誰にでもできる価値のないことだなんてことはないです。
どこにAIを使うかが重要で、AIを使ってラクしてもいいところ、ラクができるようになったからこそ時間をかけて作り込むところ、そこを間違えないようにAIを使っていくことが大事だと思います。
そして、自分のAIの使い方が間違っていないかを判断するためにしっかりとした知識やプロセスを理解しておく必要があると思います。
おまけ
冒頭にはったフロー図もAIに作成させたものですが、最初はNano Banana Proで生成させた画像でした。
この画像もHTMLで作れるのでは？と思ってCanvasに画像を入れてHTMLで再現してと指示したら勝手にReactまで使って予想以上に再現度高いものを作ってくれました。
画像を生成したいときに、「欲しいものは本当に画像である必要がありますか？HTMLで表現できるものではないですか？」という考えは持っておいた方がいいのかもしれません。
Nano Banana Proで生成したフロー図
Canvasを使ってHTMLで再現させたフロー図