はじめに
みなさんこんにちは。株式会社インプルの岩崎です。
今回は久しぶりにAIスライドの話題。最近業務が忙しくて触れられてませんでしたが、久しぶりに改良してみましょう！
AIスライドの振り返り
さて、久しぶり（約2ヶ月ぶり）の話題ですので、まずはこれまでの振り返りです！
まず最初は、デザインのいいスライドをAIで作りたい！という思いからスタートしました。
当時はスライドのテキストを考えることはうまくできるものの、スライドに載せようとすると、文字化けしたり、デザインがさほど得意ではなかったのです。そこで、HTMLとCSSを使って、デザイン性のいいスライドを作らせたのが始まりでした。
ちなみに、第一回目の記事は、おかげさまで2026年1月現在、rambleのランキング5位です。たくさん読んでくれてありがとうございます！
その後、テンプレートを量産してデザインパターンを増やしたり、JSONデータを使って内容をしっかりと考えさせたりしたのが2回目・3回目の内容です。
そして最新の記事では、すべてをLLMでできないかな？と、ルールを作ってAIが綺麗に作れるよう、パッケージ化までしてみました。
以上が、ざっくりとしたAIスライドの振り返りです！
トークン量に注目してみよう
さて、今回はLLMで作らせるからこそ、注意したいポイントについて、まとめてみました。
現在のスライドAIの構成
さて、現在のAIスライドは、下記の構成でできています。（実際はもう少し詰まっていますが笑）
AI_slide/
├── package.json # プロジェクト設定、依存関係（例: node-fetch, dotenv）
├── main.js # メイン実行ファイル (ユーザー入力、結果出力、コアサービスの呼び出し)
├── config/
│ └── rules.json # 【ルール定義】 構造、デザイン、トンマナの制約
└── core/
├── llm-generator.js # 【コアロジック】 プロンプト構築、API通信
└── templates.js # HTML/CSSテンプレートを文字列として保持（ファイル読み込みを省略するため）この構成の場合、基本的にcoreフォルダー以下でLLMはスライドを生成します。そのとき、cofig内のルールを読みながら生成します。
この構成でデザインパターンを増やしたい！
さて、この構成の時に、デザインパターンを増やす場合、templates.js にどんどん書き加えていくことになります。ここには、デザインのCSSがたくさん書かれており、これを参考にしながらLLMはスライドのデザインを制作します。
ここには、現在、オフィシャルデザインに関するスタイルや、箇条書きや文字の強調などしか含まれていないため、カード型のデザインを増やしたり、2カラムのデザインを増やしたりしたかったのです。
その際、ここにcssを追加していく形でデザインを増やしてくと、現在300行程度の量が、500行、1000行と、どんどん増えていく可能性がありました。すると、トークン量が少し心配になってきます。
トークン量とは
ここで、トークン量についておさらいしておきます。
LLMは、わかりやすく説明すると、読むことと書くことで、トークン量が決まります。読むことは、インプットの情報量で、書くことはアウトプットの情報量です。日本語の場合、1文字から数字で1トークンに達し、トークン数が多いほど処理量が増えコストも高くなるため、効率的なAI活用にはトークン数を意識したプロンプト設計が重要です。
つまり、トークン量は減らすことに越したことはなく、少ければ少ないほど、処理が減り、コストも安くなります。現在の設計でデザインを増やした場合、生成時・修正時*n回に、読むことのトークン量が毎回かかってしまいます。そのため、これを少しでも改善できないか、と考えました。
トークン量を減らす工夫
今回のツールの場合、どうしてもスライド生成時には、読むトークン量が毎回同じ量かかってしまいます。これを減らすためには、下記工夫が検討されます。
ファイルを分けてみる
まず簡単にできるのは、読むファイルを分けることです。
今回は、先述した通り、templates.js にすべてのデザインファイルを組み込みました。これを役割ごとに分割しました。
テキストに関する情報や、レイアウトに関する情報、オフィシャルデザインのcssなど、それぞれのcss情報ごとに、ファイルを分けてみました。
しかし、これだけではこれまでの templates.js を分別しただけにすぎません。なので、次の一つのファイルを作ってあげることで、LLMの読む量を減らしてあげます。
カタログ方式のデザインファイル
今回の方式では、これらのファイル一式を読まなくても済むよう、カタログ方式（勝手に命名）を採用することにしました。
これにより、いままでのように生のCSSを送るのに比べ、日本語の簡潔な説明（カタログ）を送る方がはるかに軽量で、APIコストも抑えられます。
イメージとしては、パーツをすべて見せてから何を作って欲しいかを聞くのではなく、カタログとしてこんなのが作れる・できるというものを見せてからデザインを作っていってもらうような形です。
下記のような形で、クラス名だけ含んだものを見せることで、LLMから返ってきた「クラス名を含んだHTML」に対し、実際のCSSを適用して表示・エクスポートするのはローカルPCの役割になるため、これまでのようにcssをたくさん参照する必要はなくなります。
これを踏まえた構成
大きな変更点としては、core/templates/ フォルダを新設し、デザインをパーツごとに分割しました。design-catalog.js にLLMが読むデザインガイドライン一式を用意し、base-css.js や layout-css.js には、これまで通り、オフィシャルスライドのcssや、レイアウトに関するcssなどが詰まっています。
それ以外はこれまで通りの機能をしており、デザインの情報が詰まっていた templates.js は、以前の構成との互換性を保つためのファイルとして残し、分割されたCSSファイルをアプリ内で1つに合流させる役割を持っています。
AI_slide/
├── package.json # プロジェクト設定、依存関係（例: node-fetch, dotenv）
├── main.js # メイン実行ファイル (ユーザー入力、結果出力、コアサービスの呼び出し)
├── config/
│ └── rules.json # 【ルール定義】 構造、デザイン、トンマナの制約
└── core/
├── templates/ # ここにテンプレート一式を収納
| ├── design-catalog.js # LLMにわたすデザインのカタログ
| ├── base-css.js
| └── layout-css.js
├── llm-generator.js # 【コアロジック】 プロンプト構築、API通信
└── templates.js # HTML/CSSテンプレートを文字列として保持（ファイル読み込みを省略するため）スライドを生成してみる
それでは早速、スライドを生成させてみましょう！
「iPhoneについて5枚程度スライドを生成して」とプロンプトに入力し、作成してみます。
今回は目にみえる変化としては、単純にデザインパターンが増えただけです。なので、下記のような形で、確かに2カラムに対応したり、付箋のデザインやカード型のデザインに対応していることがわかります。
デザイン的には、詰め込みでたくさん入れられているような気がしますので、ルールでこの辺りを調整できれば、さらに良くなりそうですね！
おわりに
いかがだったでしょうか？
これにより、デザインの量を増やしても、カタログに登録しておくだけで、LLMのトークンを押さえながら様々なデザインを作ることができます。今後、スライドで使うcss集、みたいなのも作りましょうかね笑
ご覧いただき、ありがとうございました！