Marp と Slidev の使い分け：Git で管理したい僕がやる使い分け

Marp と Slidev、どう使い分ける？

ども！もともとスライドは全部 Marp で作ってて、そこそこ使い倒した末に Slidev へ移った龍ちゃんです。

Marp と Slidev は、どっちも Markdown でスライドを書ける開発者向けのツールです。で、両方を触ったことがある人なら、一度はこう思いますよね。

龍

「結局、どっち使えばいいの？」

僕は両方を Claude Code で使い倒してきました。Marp は80時間→11時間に短縮した話を書いたくらい使い込んだし、その上で今は Slidev に移ってます。で、行き着いた結論はシンプルです。手軽さと共有なら Marp、作り込んで育てたいなら Slidev。どっちが上って話じゃなく、用途で使い分けています。

この記事では、その「で、あなたはどっち？」に、両方を行き来した目線で整理をします。（そもそも Slidev って何？ってところやセットアップは 第1部 に書いてるので、気になる人はそちらもどうぞ。この記事は読んでなくても大丈夫です。）

大前提：Git で管理したい。だから候補は2つに絞られる

比較に入る前に、ひとつだけ僕のこだわりを置かせてください。スライドも、コードと同じようにテキストで書いて Git で管理したいんですよね。 差分が見えて、履歴が残って、「ここ直して」が効く。あの体験を一度味わうと、もう戻れないんですよ。

で、この前提を置いた瞬間、候補がスパッと絞られます。まず土俵から降りるのが PowerPoint と Google Slides。

• PowerPoint（.pptx）：中身は ZIP に XML を詰めたバイナリなんですよね。git diff しても返ってくるのは Binary files differ の一行だけ。どこを直したか読めないし、ブランチを分けてマージ、なんてのも事実上できません。テキストだけ抜き出す裏技はあるけど、図形やレイアウトの変更は追えないので、実用にはちょっと。
• Google Slides：そもそもローカルにファイルが存在しないんですよ。クラウドの上にあるので、git add する対象がない。独自の版履歴はあるけど、ブランチもプルリクもない。あれは Git とは別物です。

なので「Git で管理する」と決めた時点で、残るのはテキストで書く2強＝ Marp と Slidev だけ。ここからが本題です。

もちろん、「他部署の人が中身を直接いじる」みたいな用途なら、素直に PowerPoint が正解です。テンプレートとかやっぱり強い点がありますもんね！

Marp と Slidev、それぞれ何ができる？

ざっくり並べるとこんな感じです。

Marp の強さはなんといっても手軽さです。npx @marp-team/marp-cli で即動くし、VSCode 拡張を入れれば誰でも同じ画面でプレビューできる。.md 1枚とテーマ CSS 1枚で完結するので、思い立って5分で書き始められるんですよね。

一方の Slidev は Node + Vite + Vue のプロジェクトを抱えるぶん、立ち上げはちょっと重い。でも、その重さと引き換えに、「配置を書くコスト」と「型にして使い回す」この二つの点で優勢です。

見た目は両方で作れる。差は「書き方」に出る

「コード左・解説右」みたいな2カラムの1枚。これ、見た目だけならどっちでも作れます。試しにまったく同じ図解を Slidev で組んでみました。

正直に言っておくと、この見た目は Marp でも作れます。標準の記法・見出し・2カラム程度までなら Marp で十分だし、書き始めの手軽さはむしろ Marp に分があるくらい。（さすがに同じ図を二つ並べるのもくどいので、一枚だけ貼っておきます）

差が出るのは、この1枚を「どう書くか」 のほうです。中身の div 構造はだいたい同じで、違うのは「スタイルと共通パーツを、どう共有・再利用するか」です。両方の書き方を順に見ていきます。

Marp の書き方：テーマ CSS＋クラス指定で寄せる

先に言っておくと、Marp も毎回 <style> を書き散らすわけじゃないんですよ。僕も最初は「Marp ってベタ書きでしょ？」と思ってたんですけど、CSS は1枚のテーマ .css にまとめておけて、スライド側は theme: で呼ぶだけ。1枚ごとに見た目を変えたいときは <!-- _class: xxx -->、組み込みの lead／invert クラスや、ヘッダー帯を出す header: ディレクティブもある。ここはちゃんとしてるんですよね。

---
marp: true
theme: my-theme        # ← 共有テーマCSSを適用
header: 「同じ1枚」を、どう書くか
---

<!-- _class: cmp -->               <!-- ← この1枚にレイアウト用クラスを当てる -->

<div class="cmp-row marp"> … </div>
<div class="cmp-row slidev"> … </div>

その my-theme の中身自体は、やっぱり長めの CSS です（このサンプルだと90行ほど）。

/* my-theme.css（抜粋）：section やコードブロックの見た目を定義 */
section { display:flex; flex-direction:column; }
.cmp-row pre { background:var(--navy-900) !important; border-radius:10px; }
/* …配色トークンやヘッダー帯の定義が続いて、全体で90行ほど */

「共有 CSS＋名前でレイアウトを呼ぶ」という発想は、Marp にもあります。裏に長めのテーマ CSS が控えるのも、一度書けば共有できるのも Slidev と同じ。ここは互角です。

ただ、Marp のテーマやクラスでできるのは、基本「すでにある要素に見た目を当てる」ところまでなんですよ。さっきのコードで言うと、<!-- _class: cmp --> はスライドに cmp って名前を付けるだけ。中身の箱 ── 2カラムなら左右の枠 ── は1個も生えてこないんです。だから <div class="cmp-row marp">…</div> みたいな箱を自分で書いて、そこに CSS が当たるのを待つ、という順番になる。CSS は「.cmp-row があればこう並べてこう塗る」とは言えても、.cmp-row という箱そのものは作ってくれないんですよね。

要するに、Marp が面倒を見てくれるのは「見た目（スタイル）」だけで、「どこに何の箱を置くか（配置・構造）」は毎回こっちが手で組む担当。header: や lead／invert くらいの切り替えなら CSS 側で寄せられるけど、込み入った配置になると結局 <div> をその都度こしらえることになる。さっきの縦積みの比較図も、僕は毎回 div を手で組んでました。テーマで寄せられるのは骨格まで。地味にこれがしんどいんですよ。（まぁ大体 div 地獄になって大変です）

Slidev の書き方：style.css＋レイアウト”部品”

Slidev も、もちろん CSS は書けますよ。全体に統一して効かせたいスタイル、つまり配色トークンや書体、コードブロックの見た目みたいな「deck 全体の地」は、style.css に素の CSS で書けばいい。一度書けば全スライドが継承します。

/* style.css（抜粋）：deck 全体に効かせる素のCSS */
:root { --navy-900:#0B1F3A; --accent:#C2410C; /* …配色トークン */ }
.slidev-layout { font-family:'Noto Sans JP',sans-serif; background:var(--bg-white); }
.cmp-row pre { background:var(--navy-900) !important; border-radius:10px; }
/* …全体で162行。一度書けば全スライドが継承する */

ここは Marp と一緒です。「全体に効かせる CSS は1枚に集約」って発想は、どっちも変わらない。差がつくのはこの先なんですよ。

違うのは、layout: で呼ぶものが CSS クラスじゃなく Vue コンポーネント（＝構造を持った部品）だということ。さっきのヘッダー付きスライドは、こう書くだけです。

---
layout: fixed-header
heading: 「同じ1枚」を、どう書くか   # ← この文字列を部品がヘッダーに描く
---

<div class="flex flex-col gap-8">
  <div class="rounded-xl bg-[var(--navy-900)] p-5 shadow-lg"> … Marp の行 … </div>
  <div class="rounded-xl bg-[var(--navy-900)] p-5 shadow-lg border-l-4 border-[var(--accent)]"> … Slidev の行（朱アクセント） … </div>
</div>

この fixed-header の実体は Vue コンポーネントで、heading を受け取って <header> の DOM を自分で組み立てて、本文は <slot /> に流し込みます。

<!-- layouts/fixed-header.vue（抜粋）：構造を部品側が持つ -->
<template>
  <header class="slide-fixed-header">
    <h2 v-if="heading">{{ heading }}</h2>    <!-- ← ヘッダーの DOM を生成 -->
  </header>
  <main class="slide-body"><slot /></main>     <!-- ← 本文はここに入る -->
</template>

つまり Slidev のレイアウトは「スタイルを当てる」だけじゃなく、構造ごと部品から供給されるんですよ。しかも本文側は、さっきの flex flex-col gap-8 みたいに、構造のすぐ隣にデザインをそのまま書ける ── Tailwind 互換のユーティリティ（UnoCSS）が標準で効くんです。正直、フロント大好きマンとしてはここだけで大興奮です（笑）。 別ファイルの CSS に飛んで .cmp-row を探さなくていいし、two-cols の ::right:: スロットも込みで「Vue を書く感覚のまま組める」。これだけでも Marp から乗り換える価値あったな、って思ったんですよね。

で、ここまでは前置きなんですよ。もっと効いてくるのが次の話、「部品として定義して、何度も呼べるか」です。

決定的なのは複雑な図も「部品にして使い回せる」

書き方の差より、もっと効いてくるのが再利用です。実際のセミナーで使った RAG の概念図がこれ。

これ、Vue コンポーネントなんですよ。中身は591行あって <style scoped> も同居してる。でも、スライドからは <RagConcept /> の1タグで呼べる。一度作れば別のスライドでも使い回せるし、props で中身も変えられる。実際これ、3本のセミナーで使い回してます。

Marp には部品を定義して名前で呼ぶ仕組みがないので、こういう図は型にできず毎回手書きになります（単純なコピペ or 画像で使いまわしです）。単発で HTML や SVG を直書きすれば凝った図が作れないわけじゃないけど、差が出るのは「型として定義して再利用できるか」のところですね。Marp でやろうとすると、関連する CSS を引っ張ってきて div と見比べる…って手間がかかるんですよね。Slidev でコピって参照を貼るだけのお手軽さを知っちゃうと、もう戻れないです。

で、この「閉じた部品にできる」のが、そのままAIと相性がいい理由なんですよ。生 CSS はグローバルに効くから、1枚直すだけでも「他のスライドに副作用は出ないか」を全部確認しないといけない。Marp でも鬼の !important で対応するってのもできますが、影響のある CSS をすべてまっさらにするって形になって諦めました。Slidev では、scoped CSS と部品は影響範囲がその中に閉じてるから、AI（Claude）はその部品だけ読めば安全に直せます。最初の1枚を書かせるだけなら Marp も得意（記法が素朴で外しにくい）。差が出るのは「直し続ける・育てる」段階で、影響範囲が閉じてるぶん Slidev は何度手を入れさせても事故りにくいんですよね。この「育てる」話は、次回から具体的に入っていきます。

使い分け

で、「どっちが上か」じゃなくて「どう使い分けるか」なんですよ。僕の振り分けはこんな感じです。

• Marp を選ぶ場面：
  とにかく手軽に、サッと枚数を出したいとき。VSCode 拡張で誰でも同じ画面が見られるから、共有もしやすい。凝らずにコンテンツ勝負、大量に量産、CI で回す。このへんは Marp が強いです。凝ったデザインは無理、と割り切れるならむしろ最高。
• Slidev を選ぶ場面：
  外部向けの、作り込んだ資料を作りたいとき。コードや図を綺麗に見せたい、コンポーネントで部品化して一度作った資産を使い回して育てたいとき。Vue が土台だからこそできる芸当ですね。僕が Marp から移ったのも、まさに「外部向けを Marp で作り込むのが苦しくなった」のが理由でした。

どっちが正解ってわけじゃなくて、今回の用途に合うほうを選ぶだけ。両方テキストで書けるので、乗り換えのコストも実は低いんですよ。

そしてこのシリーズで僕が Slidev を主役にしてるのは、その「部品化して育てる」というのが、直近の活動と合致しているからです。

まとめと、次回

• スライドを Git で管理したいと決めると、PowerPoint / Google Slides は外れる
• 残った Marp と Slidev は優劣じゃなくてできることが違う
• 手軽さ・共有なら Marp、部品化して育てるなら Slidev。僕はこう振り分けてます

次回（第3部）は、その Slidev を「育てる」第一歩、デザイントークン編です。デフォルトのままAIにスライドを書かせると色もサイズも暴走するんですけど、それを style.css に「枠」として先に定義してAIを縛る、っていう即効性のある処方箋を書きます。お楽しみに。

ほなまた〜