Claude Code × Slidev：構文ゼロで作って、Git で管理する

1 AIで爆速、しかも Git 管理。スライド作りがコードになった
2 セットアップ
3 エクスポートで詰まったところ
4 エクスポートを実行する
5 まとめ
- 5.1 次回予告

AIで爆速、しかも Git 管理。スライド作りがコードになった

ども！Slidev と Claude Code を組み合わせてスライド作りにハマってる龍ちゃんです。

Slidev は Markdown でスライドを書ける、開発者向けのプレゼンツールです。テキストボックスをマウスで並べる代わりに、見出しや箇条書きを Markdown で書くと、それがそのままスライドになる。コードブロックもそのまま貼れてシンタックスハイライトも効くので、LT や登壇資料を作るエンジニアに人気のやつですね。

で、これを Claude Code に任せると、こんなスライドが日本語で頼むだけで出てきます。

↑ Claude Code に作らせた実物の1枚です（別のセミナー資料から）。こういう複雑な概念図でも、テキストボックスをこねくり回さず、Markdown と日本語の指示で組めるんですよ。

で、何が嬉しいか。もう手作業には戻れなくなる、僕が推したいのはこの3つです。

Git で差分管理できる：
調査もコードも素材も全部 Git に乗せてるのに、スライドだけ PowerPoint のバイナリで蚊帳の外——が地味に面倒だったんですよね。Slidev は中身がただの Markdown なので、素材もスライドも全部 Git の上に揃います
AIに頼むだけで爆速：
Slidev 独自の記法は Claude Code が肩代わり。公式が「AIと相性が良い」と明言していて、構文を丸ごと渡せる公式 Skill まで配ってます（公式が出してる＝AIに任せる前提、ってのが高ポイント）
見た目の調整も自然言語で：
スタイリングは Tailwind 互換（UnoCSS）で、Tailwind はAIが得意な記法。「ここもう少し大きく」で通るので、1px ずつ動かす作業から解放されます

実際セットアップして頼んだら、あっという間にでき上がって「これ最高じゃん」ってなりました。スライド作りが、コードを書くのと同じ開発体験になるんですよ。

この記事はその環境を作るセットアップまとめです。「なんで Marp じゃなく Slidev？」の比較は一本になるので次回に回します（Marp は別記事で書いてます）。今回は「作って、ちゃんと配れる状態になるまで」を最短で通しますね。

今回の内容です。

公式 Skill を入れるだけで、Slidev の構文ゼロでスライドが作れる
作ったスライドを PDF / PNG / PPTX として出力する手順
エクスポートで必ずハマる3つの罠（playwright-chromium・日本語フォント・PPTX は画像）の潰し方

セットアップ

前提

Node.js が入っていること（この記事のコマンドは npx skills も npm create slidev も npx slidev export も、ぜんぶ Node の上で動きます。逆に言えば Node さえあれば動きます）
Claude Code が使えること

1. 公式 Slidev Skill を入れる

npx skills add slidevjs/slidev

これだけで、Slidev の Skill がプロジェクトに追加されます。npx skills は Skill ファイルをリポジトリに配置する CLI で、Claude Code 専用の隠しコマンドとかじゃなく、ただの npx 実行です（だから Node さえあれば動く）。置かれた Skill は Claude Code が自動で拾うので、/skills を叩いて一覧に Slidev が出ていれば導入完了です。

中身は Slidev 公式リポジトリ（slidevjs/slidev）に同梱されている Skill で、コア構文・アニメーション・コードハイライト・図表（Mermaid / PlantUML / LaTeX）・レイアウト・エクスポートまで、52個のリファレンスが入っています。

2. Slidev プロジェクトを作る

npm create slidev

対話的にプロジェクト名などを聞かれるので答えると、slides.md を中心とした最小構成ができあがります。スライドの実体はこの slides.md というただの Markdown ファイルです。

3. 最初の1枚を Claude に頼む

あとは Claude Code に日本語で頼むだけです。僕がよくやるのは、いきなり「スライド作って」じゃなく、先にアウトライン → ストーリーボード（どの順で何を見せるか）→ 色の方向、をテキストで固めてから「これでスライド化して」と渡す流れですね。最近の社内 LT は、チャットで5分くらいダーッと喋って方向を固めて、そのまま「スライドにして」で一気に組んでもらいました。

最初の1枚なら、こんな雑な頼み方で十分です。

slides.md に、タイトルスライドと「自己紹介」「今日話すこと」の3枚を作って。
今日話すことは箇条書きを v-click で1つずつ出すアニメーションにして。

v-click（クリックで要素を順番に表示するアニメーション）のような Slidev 固有の記法も、Skill を入れてるから Claude がちゃんと書いてくれます。こっちは記法を知らなくていい。これが地味に最高なんですよね。

4. ブラウザで確認する

npm run dev

http://localhost:3030 を開くと、作ったスライドが表示されます。ここまでは驚くほどスムーズに進むはずです。

……で、ここまでは本当に呆気ないくらい順調なんですよ。
ここからは、僕が詰まった点を共有しておきますね。

エクスポートで詰まったところ

「画面では完璧」と「ファイルとして配れる」は、まったくの別物なんですよね。スライドは最終的に PDF やパワポにして配ることになるんですが、そのエクスポートの段階で知らないと「結局使えないじゃん」で終わる罠が3つあります。

出力の前提・出力結果のフォント・出力フォーマットの性質、の3つです。順に潰していきますね。

レイアウトが上に寄る、要素が重なる、といった CSS / デザイン起因の崩れは、エクスポート機構そのものの罠とは別問題なので、この記事では扱いません。デザイン編（続編）に切り出します。

罠①：playwright-chromium がないと、そもそも出力できない

Slidev のエクスポートは内部でヘッドレスブラウザ（Chromium）を使ってスライドをレンダリングして PDF / PNG / PPTX に変換しています。なので Chromium を動かすための依存パッケージが必要なんですよね。

npm install -D playwright-chromium

これを入れていないと、エクスポートコマンドがブラウザ関連のエラーで止まります。「export できない」とハマったら、まずこれを疑ってください。最初わからんかったんですが、Slidev 公式のエクスポートガイドを見たら前提として明記されていましたね。

コンテナの場合：僕みたいに python:3.12-slim のような軽量イメージで動かしてると、playwright-chromium を入れてもそれだけじゃ動きません。Chromium 本体を動かすための system ライブラリ（共有ライブラリ）が OS 側に無いからです。僕は Dockerfile に apt で chromium を入れて解決しました（npx playwright install-deps でも依存ライブラリだけ入ります）。

罠②：日本語が豆腐になる / 文字化け

これ、コンテナや CI みたいなまっさらな環境だと刺さるやつです。dev サーバーでは普通に日本語が表示されてたのに、PDF にしたら文字が□（豆腐）になったり、文字化けしたりするんですよ。正直「壊れた？」ってなりました（笑）。

原因は、フォントを明示指定していないことです。指定がないと、レンダリングするブラウザ環境にあるフォントが使われてしまって、日本語フォントが無い環境では化けてしまうんですね。逆に言うと、普通の Mac / Windows なら OS が日本語フォントを持ってるので、指定しなくても化けないことが多いです。

対策は、slides.md の先頭（headmatter）でフォントを明示することです。

---
fonts:
  sans: 'Noto Sans JP'
  serif: 'Noto Serif JP'
---

Slidev は、ここで指定したフォントを Google Fonts から自動的に読み込んでくれます。Noto Sans JP のように Google Fonts に存在する日本語フォントを指定しておけば、エクスポート時もちゃんと日本語が出ます。これも公式のフォント設定ガイドどおりの挙動ですね。基本は、この fonts: 指定さえしておけば豆腐は防げます。

コンテナの場合：python:3.12-slim のような軽量イメージは、そもそも OS に日本語フォントが入っていません。fonts: で Google Fonts から取れる環境ならそれで足りますが、ネットに繋ぎたくない・繋がらないときの安全網として、OS 側にも日本語フォント（fonts-noto-cjk パッケージ）を入れておくと確実です。僕の DevContainer は Dockerfile で fonts-noto-cjk を入れてます。

罠③：PPTX に書き出しても、中身は「画像」

「Slidev は PPTX エクスポートにも対応してる、これでパワポで提出できる！」——僕も最初そう思ってたんですが、ここが3つ目の罠でした。

npx slidev export --format pptx

たしかに PowerPoint ファイルは出てきます。が、開いてみると各スライドは編集可能なテキストや図形ではなく、1枚の画像として貼り付けられているんです。これは Slidev の仕様で、公式にもこう書かれています。

all the slides in the PPTX file will be exported as images, so the text will not be selectable.
（PPTX ファイル内のすべてのスライドは画像としてエクスポートされるため、テキストは選択できない）
— Slidev 公式 “Exporting”

つまり、「PowerPoint で開いて最後に文言だけ直す」「フォントを差し替える」「アニメーションを足す」といった編集は一切できません。スライドの絵が貼ってあるだけだからです。

これ、実際に困ったことがあって。作った資料を、PowerPoint ベースで作業してる人に渡して使い回してもらう場面があったんですよ。共有するなら、デザインの統一感的にも PowerPoint じゃないと困る。で、その人が「このデザインのまま中身を直したい」となったときに——直せない。中身は画像だから。結局 Markdown 側を持ってる僕しか直せないわけで、これはちょっと困りましたね。

ここを理解した上での付き合い方はこんな感じです。

修正はあくまで Slidev 側（Markdown）でやる。PPTX はあくまで「配布・提出用の最終形」と割り切る。
他部署や他人が PowerPoint で中身をいじる前提の用途には向かないので、その場合は素直に PowerPoint で作った方がいい。

逆に「PDF と同じく、見せる・配るだけ」の用途なら PPTX で何の問題もありません。自分が編集の主導権を Markdown 側に持つ、という運用さえ守れば罠にはならないんですよね。「スライドの実体は Markdown にある」と割り切れると、PPTX は単なる出力物になります。

エクスポートを実行する

罠を潰したら、あとは出力するだけです。

PDF（配布の定番）

npx slidev export --output export/slides.pdf --timeout 60000

--timeout を長めに取っているのは、スライドが多かったり画像が重かったりすると、デフォルトのタイムアウトではレンダリングが間に合わずに失敗することがあるからですね。実際、Claude にエクスポートを任せてると、たまにここでコケます（笑）。そういうときは一旦止めて、--timeout を伸ばしたコマンドを自分で打ち直すか、「このコマンドで出して」とまとめて投げ直すのが早いです。

ちなみに「エクスポートして」だけだと Claude がうまくコマンドを組めないこともあるので、僕はスライドを置いてるディレクトリの CLAUDE.md に、よく使うエクスポートコマンドをそのまま書いてます。こうしておくと「いつものやつで出して」で通るので、毎回コマンドを思い出さなくて済むんですよね。

PNG（1枚ずつ画像で確認したいとき）

npx slidev export --format png --per-slide --output export/slide

--per-slide でスライド1枚につき1ファイル出力されます。レイアウトを直したあとに「該当ページだけ素早く確認したい」ときは、--range で範囲を絞ると速いです。

npx slidev export --format png --range 1-5 --output export/slide

出力後は、PNG をざっと眺めてフォントが日本語で出ているか・レイアウトが崩れていないかを確認する習慣をつけておくと、配布直前の事故が減りますよ。

エクスポート成果物は Git に入れない

export/ ディレクトリ（PDF や PNG の出力先）は成果物なのでリポジトリにはコミットしません。.gitignore に入れておきましょう。

# Slidev build/export artifacts
dist/
.slidev/
export/

ソース（slides.md）さえ管理しておけば、成果物はいつでも再生成できます。これも「スライド＝コード」として扱う発想ですね。

まとめ

ここまでで、構文を一切覚えずに Claude Code でスライドを作って、PDF / PNG / PPTX として配れる状態ができあがりました。要点は2つです。

公式 Skill（npx skills add slidevjs/slidev）を入れれば構文学習はゼロでいいです。日本語で「こんなスライドを作って」と頼むだけ。
エクスポートの3つの罠（playwright-chromium・日本語フォント・PPTX は画像）を先回りで潰せば、Slidev は実用ラインに乗ります。

「AIにスライドを作らせてみた」で終わらず、ちゃんと配れるところまで来ると、スライド作りの体験は本当に変わります。なにより、爆速でスライドの形にして見た目まで確認できるのが便利なんですよね。テキストで書いて、差分で管理して、「ここ直して」で直る。この身軽さは一度味わうと、なかなか戻れないです。

……と言うと「いや、それ Marp でもよくない？」って思った人、いますよね。わかります（笑）。そのへんの使い分けは次回ちゃんと比較するので、ちょっと待っててください〜。