Claude Code × Slidev：AIに全任せしないデザインシステムの育て方

1 AIにスライド、全部任せちゃダメなの？
2 良かったパターンを貯めると、自分のデザインシステムになる
3 どう貯めて、どう選ぶか
4 育てるほど速くなる。でも一発で完璧は狙わない
5 まとめ

AIにスライド、全部任せちゃダメなの？

ども！Slidev と Claude Code でスライドを量産してる龍ちゃんです。

前回（第3部）で、色やサイズを CSS変数で縛る話をしました。今回はその続きで、もう一段上の「育てる」話なんですけど、その前にひとつ、最近ふと思うことがあって。

AIにスライド、もう全部任せちゃえばよくないですか？って。

実際、ソースをポンと放り込んだら構成も中身も全部AIがまとめてくれるツール、増えましたよね。資料を要約する・理解するみたいな用途なら、全任せで十分だと思います。でも、自分が人前で話すプレゼンとなると、話が変わります。

スライドは、”自分の話しやすさ”とセットで形になると考えています。話す自分を想像しながら「ここはこう見せたい」「この順番で出したい」が決まっていく。人それぞれ、”話しやすいパターン”って絶対あるんですよね。

だから全任せだと、きれいなスライドは出てくるけど、“自分が話しやすい形”にはならない。他人が用意してくれた服を着てる感じ。間違ってないんだけど、なんとなく話しにくさが残ります。

つまりスライドには、「全任せでいい場面」と「方向性を自分で握りたい場面」があるということですね。プレゼンは完全に後者寄りなんですよ。じゃあ、その”方向性”ってどう持っておけばいいの？っていうのが、今回の話です。

良かったパターンを貯めると、自分のデザインシステムになる

で、方向性を自分で握るって言っても、毎回ゼロから「どう見せよう」を考えるの、しんどくないですか。

前のスライドで「お、この見せ方いいな、話しやすいな」ってパターンができたとするじゃないですか。なのに、そのデッキが終わるとそれっきり。次の発表でまた白紙から考え直す。せっかくの”自分の勝ちパターン”が、毎回使い捨てになってしまう。もったいないですよね。

答えはシンプルで。その良かったパターンを、捨てずに貯めればいい。貯めたものが積み上がると、それが”自分なりのデザインシステム”になります。

「デザインシステム」って言うと、大企業がガッチリ作り込むやつを想像して身構えるかもしれません。でも、色のルール（トークン）と、よく使う部品と、それを使う作法。これが揃ってれば、規模が小さいだけで構造は本物と同じなんですよ。僕はこれを「自分で育てた小さなデザインシステム」と呼んでます。要は、話しやすくて良かったパターンの集積です。

しかもこれ、上から設計したわけじゃないんですよ。「デザインシステムを作るぞ」じゃなくて、やって気に入ったものを記録してたら、「気づいたらできてた」が正しいです（笑）。

と、その前に前提を2つだけ置かせてください。ひとつ、この連載で作ってるのは全部 Slidev（Markdown でスライドを書けるツール。中身は Vue で、セットアップは第1部）の上の話だということ。もうひとつ、前回やった「色・サイズを CSS変数（トークン）で縛る」やつが、このデザインシステムの一番下の土台だということ。色の枠が決まってるから、その上に型や部品を積んでもトーンが崩れない。今回はその土台の上に積む話で、型・部品も Slidev（Vue）の仕組みに乗せて作ります（色まわりの”なぜ”は第3部に）。

貯め先は、ざっくり3つ。レイアウトの「型」、繰り返し使う「部品」、そして「ルール（作法）」です。

どう貯めて、どう選ぶか

貯めるって、要は「一度作って良かった／学んだものを、次も使える形に昇格させる」こと。型・部品・ルールの順に見ていきます。

レイアウトは「型」にする

良かったスライドの構造を、layouts/ に「型」として置いておくと、次から frontmatter で layout: 名前 と呼ぶだけで使えます。

第2部でも触れたとおり、Slidev のレイアウトはただの CSS クラスじゃなく Vue コンポーネント＝構造を持った部品です。だから「型にする」は、CSS をかき集めることじゃなくて、構造ごと部品に閉じ込めて、名前で呼ぶことなんですよ。

たとえば僕、Slidev でコンテンツの縦中央揃えにめちゃくちゃハマったことがあって（笑）。Slidev の標準レイアウトは高さを確定してくれないので、子要素に flex: 1 を付けても効かないんですよ。で、色々試した末に気づいたのが、毎回スライドで中央寄せの CSS と格闘するより、”縦中央揃え”そのものをレイアウトの型にしちゃえばいいってこと。Slidev は UnoCSS（Tailwind 互換）が標準なので、型の中身もユーティリティでスッと書けます。

<!-- layouts/centered.vue：縦中央揃えを、型の中に閉じ込める -->
<template>
  <!-- slidev-layout：style.css の .slidev-layout に置いた共通ベースを継ぐ（公式の標準パターン。自作レイアウトは自分で付ける） -->
  <!-- 高さは付かないので、h-full で確保して flex で縦中央寄せ -->
  <div class="slidev-layout h-full flex flex-col justify-center px-14 py-10">
    <slot />   <!-- スライドの中身がここに入る -->
  </div>
</template>

あとはスライド側から、こう呼ぶだけです。

---
layout: centered
---

# これが画面の縦中央に来る

中央寄せの CSS を毎回スライドに書くんじゃなくて、型を1個 layouts/ に置いて layout: centered と呼ぶだけ。ハマって解決した知見が、そのまま”呼べる型”になるんですよね。同じ罠を二度と踏まなくて済む。

（この centered.vue を含めて、型・部品・ルールまで全部組んだ“動くデッキ一式”のフルコードは、実物編（全部入り）で公開しています。ここでは“ハマった知見を型に閉じ込める”という発想だけ掴んでもらえればOKです。）

繰り返すパーツは「部品」にする

2回以上出てくるパーツは、Vue コンポーネントにして components/ に置いちゃう。僕の手元には、RAG の概念図とかフロー図とか、そういう部品が20個以上貯まってます。たとえば RAG パイプライン全体像の図は、もうこう呼ぶだけ。

---
layout: none
---

<RagConcept />

`<RagConcept />` と1行書くだけで出てくる RAG パイプライン全体像の図

<RagConcept /> って書くだけ。中身の HTML はコンポーネントが持ってるので、毎回書かせなくていいし、見た目も必ず揃う。これ、めちゃくちゃ気持ちいいんですよ。HTML を毎回手で書いてた頃は、地味に毎回ちょっとずつ違う図ができてたので（笑）。

「AIっぽい」と気づいたら「ルール」にする

「あ、これやるとAIっぽいな」って気づいたことは、ルールとして文章にしておく。僕の素材カタログだと、こんな作法が貯まってます。

本文は 19px 以上（投影で読めなくなるので。Tailwind なら text-xl 以上。text-lg は18pxで割れる）
色は CSS変数か theme の色クラスを使う（生 HEX の直書きはしない）
1つの図に1メッセージ（詰め込まない）

これに、「AI製に見えるパターン」を避けるルールも足していきます。

やりがち（AIっぽい）	代わりにこうする
Inter / Poppins フォント	Noto Sans JP に寄せる
紫〜青のグラデ背景	単色＋薄いノイズ
完全対称なレイアウト	わざと少し非対称に
同じカードを3枚横並び	矢印でつなぐフロー形式に

型も部品もルールも、やってることは全部おんなじです。一度作って良かったものを、次も使える形に昇格させる。ルールに書いておけば、次は同じ罠を先に回避できます。

貯めたものは、カタログにして「見て選ぶ」

で、ここが大事なんですけど。貯めるだけだと、どこに何があるか自分でも忘れるんですよ（笑）。部品が20個もあると、もう「あれ、あの図どこ作ったっけ」ってなる。

だから、貯めた素材は一覧、つまりカタログにしておきます。僕は、素材の一覧に「名前・用途・プレビュー画像」の表を作ってあって、パッと見て選べるようにしてる。

で、新しいスライドを作るときは、このカタログを眺めて「これ使お」って自分で選ぶ。ここ、地味だけど超大事で。部品選びまでAIに丸投げしないんですよ。どの型でどの部品をどう並べるか、っていう”方向性”は人間が握る。AIに渡すのは「ルールはこれね、素材はカタログから選んでね」くらい。

これ、最初に言った「全任せにしない」が、運用レベルで具体になってるんですよね。全任せは、選ぶところまで含めてAI。僕のやり方は、素材はAIと一緒に作るけど、選んで組むのは自分。この差が、”自分が話しやすいスライド”になるかどうかの分かれ目だと思ってます。

育てるほど速くなる。でも一発で完璧は狙わない

ここまでの話、正直に言うと、最初はそんなに速くないです（笑）。

型も部品もまだ無いから、最初の何枚かはゼロから作るのと変わらない。むしろ「これ型にしとくか」「これ部品にするか」って考える分、ちょっと遅いくらい。

でも、2枚目、3枚目、次のデッキ、と進むほど効いてくる。もうカタログに型も部品も貯まってるから、新しいスライドが「ゼロから」じゃなくて「カタログから選んで組むだけ」になるんですよ。これがほんとにラクで、一度この状態に入ると戻れないんですよね（”爆速”って言いたくなるやつですが、何分が何分に、みたいな計測はしてないので体感の話です）。

そして、ここが冒頭の問い「全部任せちゃダメなの？」への答えです。貯まってるのは”自分が話しやすい型”の集積だから、速いのに、ちゃんと”自分の”スライドになる。全任せ（速いけど自分の形にならない）でも、毎回ゼロ（自分の形だけど遅い）でもない。使い捨てだったパターンが、次の速さに変わるんですよね。

ただ、最後に正直なことも言っておきます。育てても、初見のスライドはやっぱりズレます。 一発で完璧、みたいな魔法はないです。新しいテーマだと、貯めた型に当てはまらないパーツが必ず出てくるんですよ。

でも、それでいいんです。ズレたら、それをまた型なり部品なりに貯めればいい。「育てる」って、そうやってズレを貯め続ける作業そのものなんですよね。これ、前にClaude Code の失敗をバグチケット化して潰す話を書いたんですけど、それと同じ発想で。ミスを記録して、次に活かせる形に変える。スライドのデザインもまったく一緒です。

ここまで育ったら、「theme にまとめる」という話も自然に出てきます。Slidev の theme は layouts/ components/ styles/ を1パッケージにするもので、ローカルの置き場所と規約がほぼ同じ。だから移行は書き直しじゃなく、package.json を1枚追加して切り出すだけです。

「theme 作るぞ！」と気合いで入ると燃え尽きることが多いんですけど（笑）、作って壊してを繰り返してズレを貯め続けた後、最後に残ったものを theme に収める。それくらいの温度感がちょうどいいかなと思ってます。theme は目的地であって、出発点の意気込みではないので。

それともう1つ。第3部でも言いましたけど、ルールに書いた、イコール画面でその通り出てる、とは限らない。型を指定したのに崩れてた、なんてのは普通に起きます。だから最後は必ず PNG に書き出して、その画像を目で見て確認しています。

この「画像を見て直す」を仕組みにする話は、それだけで一本になるテーマですね。作る、育てる、ときたら、最後は回す、です。