はじめに

Claude Codeを使ってプレゼンテーション用のスライド自動生成システムを作り、実務で使えるレベルのものになってきたので、初のQiita投稿を書いてみたいと思います。

タイトル通り、AIに自由を与えるのをやめたら品質が安定したのですが、以前はAIに「いい感じに」作ってもらうことを繰り返していました。出てくるスライドのクオリティはそれなりに高い。でも毎回レイアウトが変わる。なぜそのレイアウトが選ばれたのか説明がつかない。そういう状態に行き詰まり、AIにルールという枠組みを与えたら上手くいきだした——というのがこの記事の話です。

試行錯誤の歴史とその設計の考え方を書きます。

なぜ既存サービスではダメだったのか

出発点はシンプルで、「綺麗なスライドをなるべくAIだけで作りたい」というものでした。

GensparkなどのAIスライド生成サービスもありますが、利用規約上の問題があります。GeminiなどのAIチャットでスライド構成を作ってもらう方法も試しましたが、デザイン品質でどうしても納得のいくものにはなりませんでした。

「自分で仕組みを作るしかない」という判断をしたのが始まりです。

試行錯誤の歴史

Phase 1：Remotionでスライド動画を作ろうとした

最初はReact製の動画生成フレームワーク Remotion を使って、スライドをそのまま動画として出力しようとしていました。Claude Codeに実装を任せると確かに動くものはできます。

ただ、デザインがどうしてもスカスカになる。情報は載っているけど「ちゃんとデザインされたスライド」という感じが全然出ない。何度試しても同じ壁にぶつかりました。

「動画は一旦置いておこう」という判断をしたのはこの頃です。

Phase 2：Slidevを発見する

スライド作成に特化したツールを探していたところ Slidev にたどり着きました。Markdownベースで書けてテーマも適用できる、プレゼンテーション向けのフレームワークです。

これはこれで動くのですが、次のステップで問題が起きました。

Phase 3：Figma MCPとの出会いと、素のHTML+CSSへの転換

当時、Figma MCPを使ってHTMLをFigmaにエクスポートし、Figma上でデザインを微調整してからPDF出力するというワークフローが可能だということを知りました。

ところが、SlidevのようなフレームワークベースのHTMLはFigma MCPとうまく噛み合わない。エクスポートしてもレイアウトが崩れたり、期待通りにならないケースが多発しました。

そこで「素のHTML+CSSだけで出力する」方向に切り替えてみたところ、Figmaへのエクスポートがきれいに通るようになりました。フレームワークを手放すことで、逆に問題が解決したのです。

Phase 4：停滞期

Figmaへのエクスポートはできるようになりましたが、ここで一旦停滞します。

Figmaで編集できるメンバーは限られています。かといってPPTXに変換する仕組みも思いつかない。「仕組みとしては動くけど、広く使ってもらえる状態ではない」という宙ぶらりんな状態で、しばらく寝かせることになりました。

Phase 5：Claude Designの登場で停滞が解消

約2ヶ月後、Claude Design（https://claude.ai/design）が登場します。

Claude DesignはAnthropicが提供するデザイン生成ツールで、HTMLやテキストをインプットとしてビジュアルデザインを生成し、PowerPointファイル（PPTX）として直接エクスポートできるのが特徴です。

HTMLをそのまま渡してみたところ、かなり精度を保ったままPPTXに変換できることがわかりました。停滞していたものが一気に動き出した瞬間でした。

核心：バラつきをなくすためにたどり着いた設計

ここまでは「どう出力するか」の話でした。並行してずっと格闘していたのが「バラつき」という問題です。

Claude Codeに「このMarkdownからスライドを作って」と指示するだけだと、同じ内容でも毎回違うレイアウトが出てきます。なぜそのレイアウトが選ばれたのか説明がつかない。品質にムラがある。

最初はたくさんのテンプレートを読み込ませれば解決すると思っていましたが、それだけでは不十分でした。

発想の転換：AIに「何を、なぜ使うか」のルールを与える

解決策として行き着いたのが、コンポーネント＋マッチングルールという設計です。

スライドの構成要素をレイアウトとパーツ（部品）に分離して、「どんなコンテンツのときにどれを使うか」のルールを明文化する。AIはそのルールに従ってコンテンツの意味を解析し、適切な組み合わせを選択する——という仕組みです。

SKILL.mdという設計書

このルールは SKILL.md という1つのMarkdownファイルに記述してあります。

Claude Codeには スキル機能 があり、.claude/skills/{スキル名}/SKILL.md にファイルを置いておくと、/slide-generator のようにスキルを呼び出したとき、Claude Codeが自動的にその設計書を読み込んで動作します。プログラムを書くのではなく、「どう動いてほしいか」を自然言語で定義するファイルです。

SKILL.mdでは、スライドの構造を3つの層として定義しています。

Layer 1: 共通外枠（ヘッダー・フッター）  ← 全スライド共通、変えない
Layer 2: レイアウト枠（5種類の配置パターン） ← コンテンツ量・性質で選ぶ
Layer 3: コンテンツ（パーツ or 自由作成）  ← 内容の意味に合わせて選ぶ

Layer 3のパーツ選択には、こういったマッチングテーブルが定義されています。

コンテンツの性質	使うパーツ
明確な手順・工程	矢羽ステップ（step-arrow）
数値比較・KPI一覧	罫線型テーブル（part-table--normal）
各項目に説明文がある一覧	カード分離型テーブル（part-table--grid-card）
引用・キーメッセージ	引用ブロック（part-quote）
数値ハイライト	KPIカード（kpi-card）

AIは自由に表現を選ぶのではなく、まずコンテンツの意味を読んでこのルールに照らし合わせる。「なぜこのレイアウトか」が説明できるようになり、同じ性質のコンテンツには同じパーツが選ばれるという再現性が生まれました。

また、パーツで表現できないケース（グラフ、フロー図、概念図など）は「自由にHTML/CSS/SVGで作る」と明示し、その場合に従うべきデザイン原則もSKILL.mdに記述しています。コントラスト・反復・整列・近接からなるC.R.A.P.原則、情報の優先順位を視覚的に表現するVisual Hierarchy、不要な装飾を排してデータを際立たせるTufte原則などです。

デザイントークンで色・余白を統一する

もう一つの安定化の仕組みがデザイントークンです。色・フォント・余白の値をすべてtokens.cssに定義し、AIはその変数だけを使うルールにしています。

/* tokens.css の一部 */
--color-coral: #e8747c;
--color-coral-light: #f2a5ab;
--color-primary: #00708d;

AIがコードを書く際に「この色のRGB値はなんだっけ」という判断をしなくて済む。どのスライドを生成しても色がブレない、という状態が作れます。

Claude Design対応で気づいたHTML設計の落とし穴

この仕組みをClaude Designで出力してみると、PPTX変換時に崩れるHTMLの書き方があることがわかりました。そこで得た知見もSKILL.mdに反映し、設計書として育てていきました。主な対応を紹介します。

① SVGの色はCSSクラスではなく属性で書く

<!-- NG: CSSクラスで色を設定（PPTX変換でCSSが解決されない） -->
<polygon points="..."/>

<!-- OK: fill属性に直接書く -->
<polygon fill="var(--color-coral)" points="..."/>

② backdrop-filterは使わない

すりガラス効果はPPTXで再現できないため、background: rgba(...) のフラットな半透明で代替します。

これらの制約もSKILL.mdに追記してあるので、今後生成されるスライドでは自動的に守られます。設計書を育てることで、品質が積み上がっていく仕組みです。

現在のワークフロー

Markdownでコンテンツを書く
      ↓
Claude Code（/slide-generator）がSKILL.mdを読み込み
レイアウト・パーツを選択してHTML+CSSを生成
      ↓
      ├─── Claude Design → PPTXエクスポート（スピード重視・そのまま配布）
      │
      └─── Figma MCP → Figmaにエクスポート → デザイン微調整（仕上げ重視）

用途に応じて2つの出口を使い分けています。社内向けの報告資料や勉強会スライドを、Markdownを書いてからスライド完成まで作れるようになりました。AIにコンテンツを考えてもらったとしても、レイアウトを整えて仕上げるまでには以前それなりの時間がかかっていました。そこが自動化されたのが一番の変化です。

振り返って気づいたこと

作りながら気づいた一番大切なことは、

「AIに『いい感じ』を求めるのか、『再現性』を求めるのかで、方法論は根本から変わる」

ということです。

自由にやらせれば「今回はいい感じ」になるかもしれません。でも次回は違うものが出てくる。業務で使うには毎回同じ品質が出ることの方がずっと重要です。

このプロジェクトは「再現性を選んだ」からこそ、SKILL.mdというルール設計が生まれました。AIの自由度を意図的に制約することで、安定した出力が得られるようになったのです。

そしてここが、冒頭に戻る部分です。

「なぜ非エンジニアがこれを作れたのか」——それは、コードを書く技術がなくても**「どう動いてほしいか」を設計する力**があれば、Claude Codeはそれを実装できるからだと思っています。むしろ「業務で使えるか」「毎回同じ品質が出るか」という実用的な問いは、エンジニア的な発想よりも、使う側の立場で考えた方が鋭くなるかもしれません。

おわりに

まだまだ進化中のプロジェクトですが、「AIだけで再現性の高いスライドを作る」という当初の目標はかなり達成できています。

次の試みとして、せっかくHTMLで一度出力するというひと手間を挟んでいることもあり、スライドをHyperframes（HTMLベースのプレゼンテーションを映像として出力できるツール）と組み合わせて映像化することも挑戦しています。最初にRemotionで動画を作ろうとして始まったことを思うと、少し面白い一周感があります。

Claude Codeを触り始めたばかりの方や、同じような課題を持つ方の参考になれば嬉しいです。