LabHub

ブログ

Markdownプレゼンテーションツール 2026 — Marp / Slidev / RevealJS / Spectacle / Gamma / Beautiful.ai / iA Presenter 徹底比較

한국어English日本語

プロローグ — なぜまたプレゼンツールの記事か

2026年でも我々はプレゼンをする。社内ウィークリー、カンファレンスのキーノート、顧客デモ、投資家へのピッチ、博士論文の公聴会 — 形は違っても、結局は誰かが前に立ってスライドを送る。そしてそのスライドを作るツールは、この5年で静かに、しかし決定的に変わった。

大きな変化は3つ。

本稿は14章にわたってその風景を描く。誰が何を得意で、何が苦手で、2026年にどんなプレゼンをどのツールで作るべきか — 最後にコードデモ・学術・マーケ・役員プレゼンの4ペルソナで整理する。


1章 · 2026年Markdownプレゼンの地図 — 4陣営

ツールを一列に並べると比較にならない。まず4陣営に分類する。

陣営入力出力代表ツール
CLI / Markdown.md / .mdxHTML, PDF, PPTXMarp, Slidev, Quarto, Remark.js
Web / フレームワークJS/TS, JSX, VueHTMLRevealJS, Spectacle, Eagle.js, deck.js
AI生成自然言語プロンプトWebスライドGamma, Beautiful.ai, SlidesGPT, Decktopus, Plus AI
クラシックGUIマウス + キーボード.pptx, .key, GSlidesPowerPoint, Keynote, Google Slides, iA Presenter

この分類も完璧ではない。Slidevは「CLI Markdown」でもあり「Vueコンポーネント」でもあるので1・2陣営にまたがる。Plus AIは「AI生成」だが結局Google Slides上で動く。それでもこの4陣営を頭に入れてからツールを見ると差が見える。

CLI/Markdown陣営の核は「バージョン管理とdiffが効く」。git push一発でスライドがデプロイされ、PRでスライドをレビューし、同じ.mdからPDF・HTML・PPTXがビルドされる。開発者が好まないわけがない。

Web/フレームワーク陣営は「コードでスライドを書く」。RevealJSはHTMLで、SpectacleはReactで、deck.jsはその中間。Markdownより自由度が高くモーション・インタラクションも強いが学習コストはある。

AI陣営は2022–2024年に爆発し、2025年に一度整理された。生き残ったツールの共通点は「プロンプトを投げるとデザイン済みスライドが出る」、差は品質・価格・統合ポジション。

クラシックGUI陣営は死んでいない。役員・営業・マーケの7割以上は今もPowerPoint・Keynote・Google Slidesを使う。2026年の変化はこの陣営にAI Copilotが深く埋め込まれたこと。

2026年のトレンドは4陣営がお互いの領域に侵入中ということ。SlidevがAI統合を入れ、Gammaが.pptxエクスポートを強化し、PowerPointがDesigner + Copilotで「AI生成」をビルトイン化する。だから「どのツールを使うか」より「どのワークフローが自チームに合うか」が問いになる。


2章 · Marp (Microsoft) — 最も人気のCLI + VSCode

Marpは日本人開発者 服部 雄輝(Yuki Hattori)が2017年頃に始めたMarkdownスライドフレームワーク。2019年にMicrosoftが彼を雇用し、Marpは事実上Microsoft傘下のプロジェクトとなった。MITライセンス、GitHubスター1.5万以上。

なぜMarpが1位になったか。 3つの決断が決定的だった。

  1. VSCode拡張。 公式のmarp-team VSCode拡張は右パネルにライブプレビューを表示する。IDEを離れずにスライドを作れる。
  2. シンプルなMarkdown文法。 ---でスライドを区切る。それで全て。HTMLタグ、ディレクティブ、テーマ宣言(marp: true + theme: gaia)はオプション。
  3. マルチ出力。 marp-cli一発でHTML/PDF/PPTX/画像が出る。PPTX出力があることは、社内の役員に.pptxを渡さねばならない韓国・日本の文脈で決定的なアドバンテージだった。

基本的な使い方。 MarpのMarkdownはこう。

---
marp: true
theme: gaia
paginate: true
---

# チーム2026ロードマップ

著者 · 2026-05-16

---

## Q1 — 検索リニューアル

- インデックス再設計
- ランキングモデルV3
- p99 200ms

---

## Q2 — 推薦システム

![bg right](./recommendation.png)

- Two-Towerモデル
- リアルタイム特徴量

CLIはこう使う。

npx @marp-team/marp-cli@latest deck.md --pdf
npx @marp-team/marp-cli@latest deck.md --pptx
npx @marp-team/marp-cli@latest deck.md --html
npx @marp-team/marp-cli@latest deck.md --server

テーマ。 ビルトインは defaultgaiauncover の3つ。軽いカスタマイズはMarkdown内の <style> タグ、重いカスタマイズは別CSSファイルで行う。marp-themesのようなコミュニティテーマも存在。

弱点。 自由度が低い。複雑なモーションやインタラクションが要るならSlidevかRevealJSが向く。ビルトインコンポーネントはなく、チャートやダイアグラムは画像かMermaidコードブロックで処理(MarpはMermaidを直接レンダリングしない。プラグインかビルド前変換が必要)。

いつMarpか。


3章 · Slidev (Anthony Fu) — Vue + AI統合

SlidevはVueコアメンバーのAnthony Fuが2021年に作ったMarkdownスライドツール。Vite・Vue 3上に乗り、「開発者のためのスライド」というスローガンを明示する。MITライセンス、GitHubスター3万以上。

なぜSlidevが急成長したか。 Marpが「シンプルさとPPTX互換」で伸びたとすれば、Slidevは「美しさとコード親和性」で伸びた。

  1. Vueコンポーネント統合。 スライドにコンポーネントをそのまま埋める。自分でVue SFCを書いてインポートしてもOK。
  2. Shikiベースのコードハイライト。 開発者プレゼンの8割はコードスライド。SlidevはVS Codeと同じShikiを使うので、IDEと同じ見た目で出る。行ハイライト、diff、magic-move(コードが滑らかに変形するモーション)まで対応。
  3. Vite HMR。 スライドを書き換えると100msで反映される。発表直前の秒単位の調整が現実的。
  4. ビルトイン手描き / Presenter Mode。 発表中に画面に絵を描いたり、発表者モードで次のスライド・ノート・タイマーを同時に見られる。

基本的な使い方。

npm init slidev@latest my-slides
cd my-slides
npm run dev

slides.md はこう。

---
theme: seriph
layout: cover
background: https://images.unsplash.com/photo-1605379399642-870262d3d051
---

# チーム2026ロードマップ

Anthony Fu · 2026-05-16

---
layout: two-cols
---

## Q1 検索リニューアル

- インデックス再設計
- ランキングV3

::right::

```ts
const score = (q, d) => bm25(q, d) * 0.6 + neural(q, d) * 0.4
```

---
layout: center
---

ここにYoutube埋め込みコンポーネントを置く。

AI統合 (2025–2026)。 Slidev 0.50系から「AI統合」ワークフローが入った。要点は2つ。

テーマ。 ビルトインは defaultseriphapple-basicbricksshibainu など。NPMに100以上のコミュニティテーマがある(検索: slidev-theme-*)。

弱点。 PPTXエクスポートが弱い。「1スライド1画像でPPTX化」はできるが、テキスト編集可能な本物のPPTXではない。社内に.pptxで渡すならMarpが優位。Vueを知らないと若干の壁がある(Markdownだけでも十分作れるが、本当の強みはコンポーネントにある)。

いつSlidevか。


4章 · RevealJS — 元祖

RevealJSはHakim El Hattabが2011年に作ったHTMLプレゼンフレームワーク。「Webスライドの元祖」と呼べる。MITライセンス、GitHubスター6.8万 — このカテゴリ最多。

なぜRevealJSか。 15年近く生き残った理由は明確。

  1. 純粋なHTML/CSS/JS。 ビルドツールなしで.htmlファイル1つで動く。GitHub Pagesに置けば完成。
  2. 垂直・水平スライド。 スライドを2次元に配置する。1つのトピックを深掘りする時は下方向に降りる、というスタイル。
  3. プラグインエコシステム。 Markdown、Highlight.js、MathJax、Notes、Search、Zoomなど公式プラグインが揃い、コミュニティプラグインも厚い。

基本的な使い方。

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="dist/reveal.css">
    <link rel="stylesheet" href="dist/theme/black.css">
  </head>
  <body>
    <div class="reveal">
      <div class="slides">
        <section>
          <h1>チーム2026ロードマップ</h1>
          <p>著者 · 2026-05-16</p>
        </section>
        <section data-markdown>
          <textarea data-template>
            ## Q1 — 検索リニューアル
            - インデックス再設計
            - ランキングV3
          </textarea>
        </section>
      </div>
    </div>
    <script src="dist/reveal.js"></script>
    <script>Reveal.initialize({ plugins: [RevealMarkdown] });</script>
  </body>
</html>

Slides.com — RevealJSのSaaSホスティング。 Hakim本人が作ったSaaS。RevealJSをGUIエディタで作ってホストする。個人無料、チーム有料。RevealJSのコマーシャルモデルとして機能。

弱点。 「元祖」の陰がある。ツールが古いのでデザイントレンドが少し古め、Marp/SlidevのMarkdown-first UXに比べて執筆が手間。ユーザーは毎回「自前HTMLビルド / Markdownインポート / GUI」のどれを選ぶか決める必要がある。

いつRevealJSか。


5章 · Spectacle (Formidable) — React + Theatre.js

Spectacleは米国 Formidable Labs(Nearformが2023年に買収)が2016年に作ったReactベースのプレゼンライブラリ。MITライセンス、GitHubスター9.7千。

なぜSpectacleか。 React陣営でスライドを作るならほぼ唯一の選択肢。

  1. JSXでスライドを書く。 スライド1枚 = Reactコンポーネント1つ。馴染んだJSX文法で書ける。
  2. タイポグラフィ。 フォント・余白・リズムのデフォルトが良い。デザイナーが作ったツールという感じ。
  3. ビルトインコンポーネント。 Heading、Text、ListItem、Image、CodePane(行ハイライト対応)など。

Theatre.js統合 (2024–2026)。 Spectacleの後期バージョンからTheatre.jsとの統合が強くなった。Theatre.jsはコードで作ったReactコンポーネントに「タイムラインベースのモーション」を載せるツール。After Effectsのキーフレームをコードに対して打てるイメージ。Spectacle + Theatre.jsで「コード駆動の発表資料に映画品質のモーション」が可能になる。

基本的な使い方。

import { Deck, Slide, Heading, Text, ListItem } from 'spectacle'

const Presentation = () => (
  <Deck>
    <Slide>
      <Heading>チーム2026ロードマップ</Heading>
      <Text>著者 · 2026-05-16</Text>
    </Slide>
    <Slide>
      <Heading>Q1 — 検索リニューアル</Heading>
      <ListItem>インデックス再設計</ListItem>
      <ListItem>ランキングV3</ListItem>
    </Slide>
  </Deck>
)

MDX対応。 SpectacleはMDXを一級市民として扱う。.mdxでスライドを書くと、MarkdownとJSXコンポーネントが自然に混ざる。

弱点。 Reactの壁。Reactを知らない人には勧められない。PPTXエクスポートは事実上ない(ブラウザレンダリング → 画像 → PPTX程度)。カンファレンストークには良いが社内共有には不向きなことが多い。

いつSpectacleか。


6章 · Quartoプレゼン — 学術

QuartoはRStudio(現Posit)が2022年にリリースした次世代ドキュメントシステム。R Markdownの後継であり、それ以上のもの。R・Python・Julia・Observable JSのコードブロックを実行して結果を文書に埋め込む「実行可能ドキュメント」の標準で、その出力の1つがスライド。

Quartoのスライド出力。 メジャーフォーマットは2つ。

さらに pptx 出力もあり、社内共有用のPowerPointも一発で出せる。

基本的な使い方。

---
title: "博士公聴会: 分散合意アルゴリズム"
author: "著者名"
format:
  revealjs:
    theme: serif
    incremental: true
---

## 研究の問い

なぜRaftはPaxosより理解しやすいのか。

## 実験結果

```r
library(ggplot2)
ggplot(results, aes(x = latency_ms, y = throughput)) + geom_point()
```

## 結論

コードブロックが実際に実行される。Rのグラフがスライド内に埋め込まれる。Python・Juliaも同様。

なぜ学術界がQuartoに移ったか。 R Markdown時代からのユーザーがそのまま移行した。「再現可能な研究」の原則と合致し、同じ.qmdから論文(PDF)・ブログ(HTML)・発表(スライド)を全て出せる。Posit Connectという社内ホスティングソリューションもあり、コンプラ要件の厳しい環境(製薬・銀行)でも使える。

弱点。 R/Pythonを知らないと意味が半減する。デザインが学術寄りなのでマーケスライドには不適。LaTeXが必要な出力(beamer/pdf)はセットアップが面倒。

いつQuartoか。


7章 · Eagle.js / deck.js / Remark.js / MDX Deck — その他の選択肢

このカテゴリには、かつて人気だったが今はメイン路線から外れた、あるいは特定ニッチに残ったツールがある。

Remark.js (2014–)。 Lennart Wittkuhnが作ったMarkdownスライドライブラリ。単一の.htmlに.mdを埋め込む方式。RevealJSより軽量。GitHubスター約1.2万。2020年以降は活発な開発は少ないが、「シンプルさが美徳」のユーザーが今も使う。

MDX Deck (2018–2022、終了)。 Brent Jacksonが作ったMDXベースのスライド。React + MDXの初期実験だった。2022年以降は事実上メンテなし。SpectacleがMDXを吸収して自然死。後継はSpectacle MDXとSlidev。

GitPitch (2017–2021、終了)。 GitHubリポジトリのPITCHME.mdをスライドとしてホストするSaaSだった。2021年にシャットダウン。「git pushでスライドを配布」というワークフローは良かったが、その席をGitHub Pages + Marp/Slidevが直接埋めた。

Eagle.js (2015–)。 Vue 1.x時代に生まれたスライドライブラリ。ユーザー数は極小。SlidevがVue 3時代の事実上の後継。

deck.js (2011–)。 RevealJSとほぼ同時期に出たHTMLプレゼンライブラリ。2010年代前半はRevealJSと二強だったが、今はほぼメンテなし。新規プロジェクトで採用する理由はない。

WebSlides、Impress.js。 Impress.jsは「Preziのようなズーム/回転」をHTMLで実装したライブラリ。視覚的に印象的だがユーザーは少ない。WebSlidesは軽量HTMLプレゼンフレームワーク。両方とも生きてはいるがメインではない。

まとめ。 この章のツールの共通結論は「昔は良かったが今はMarp/Slidev/RevealJSがその席を占めている」。新規プロジェクトで採用する理由はほぼない。ただし既存コードベースを保守するならRemark.jsは今も生きていて安定。


8章 · iA Presenter — Mac専用ミニマル

iA Writerで有名なドイツのiA(Information Architects)が2023年にリリースしたMac専用プレゼンアプリ。iA Writerのミニマリズム哲学をスライドにそのまま持ち込んだ。

哲学。 「デザインを気にするな、文章に集中せよ」。スライドのデザインをユーザーに委ねない。フォント・余白・色・整列は全てアプリが決める。ユーザーはMarkdownだけ書く。

主な差別化。

価格。 買い切り + アップグレードモデル。2026年時点で約39ドル(地域による)。SaaS購読が嫌なユーザーに刺さる。

弱点。 Mac専用(iPad版はあるがWindows・Linuxはなし)。デザイン自由度はほぼ0(これが長所であり短所)。社内共有用の.pptxエクスポートは無難。

いつiA Presenterか。


9章 · AIプレゼン — Gamma / Beautiful.ai / SlidesGPT / Decktopus

2022–2024年にAIスライドツールは爆発し、2025年に一度整理された。2026年現在、生き残ったツールの地図を見る。

Gamma — シリーズB獲得の1位

Gamma(米国)は2022年創業、2024年にシリーズB調達。「プロンプト1行でデッキ1セット」を最もうまく実装したと市場に認められた。

特徴:

価格: 無料(制限あり)、Plus月10ドル、Pro月20ドル、Business月30ドル(2026年5月時点)。

Beautiful.ai — デザイン自動化

Beautiful.ai(米国)は2017年創業、ある意味「AIスライドの元祖」だ。当時の「AI」は「スマートテンプレート」に近かった。コンテンツを入れるとデザインが自動的に再調整される(要素を追加するとレイアウトが組み直される)。

2023–2025年にLLM統合を本格化し「AIデッキ生成」も追加。Gammaより伝統的な16:9に近く、「企業/チーム環境」にポジションする。

価格: Pro月12ドル、Team月40ドル/席。

SlidesGPT — 軽量GPTラッパー

SlidesGPT(名前そのものがコンセプト)はOpenAI APIを直接ラップしてスライドを作る軽量ツール。無料枠が太く、結果がPPTXで即ダウンロード。デザイン品質はGamma・Beautiful.aiより落ちるが速くて安い。

Decktopus — ビジネス特化

Decktopus(トルコ拠点)はビジネスプレゼン(ピッチデッキ、セールスデッキ、レポート)に特化したAIツール。「発表後のQ&A自動生成」「発表者ノート自動執筆」などビジネス親和の機能が強み。

Tome — 2024年シャットダウン

Tome(米国)は2020年創業、2023年にシリーズB調達で約7億ドルのバリュエーション。結果が美しくモバイルアプリが強かった。だが2024年後半にシャットダウンを発表。無料/有料ユーザーにデータダウンロード期間を与えてサービスを終了。理由は明示されなかったが「有料転換率が低く、Gammaが市場を取り、自前のビジネスモデルが見つからなかった」が一般的な分析。

Tomeのシャットダウンはこのカテゴリへの警告だった。AIスライドは参入障壁が低く、「綺麗」だけでは生き残れない。

比較表

ツール強み弱み価格(月)誰向け
GammaカードUI、プロンプト→デッキ、画像生成16:9発表が主軸でない無料/10/20/30スタートアップピッチ、レポート
Beautiful.aiデザイン自動整列、企業向け価格12/40セールス/マーケチーム
SlidesGPT速い、安いデザイン品質無料/低価格早い初稿
Decktopusビジネス特化機能デザイン平凡9.99/20セールス/ピッチデッキ
Tome(終了)

共通の弱み

AIスライドの共通弱点は2つ。


10章 · Plus AI for Google Slides — 既存ツール + AI

Plus AI(米国 Plus Docs)はGoogle Slidesのアドオン形式でAIを提供する。「Google Slidesを離れずにAIを使う」という賢いポジショニング。

なぜこれが賢いか。 企業の8割は既にGoogle WorkspaceかMicrosoft 365を使っている。その中で働く人に「新ツールへ移行を」は大きな摩擦。Plus AIはその摩擦を消す。

主な機能。

価格。 無料トライアル、Pro月15ドル/席、Enterpriseは別途。

競合。 GoogleがGeminiをSlidesにビルトインで入れているので、Plus AIの席が狭まる可能性がある。ただしPlus AIはより強いワークフロー(テンプレート、一括生成、データ統合)で差別化を狙う。

類似ツール (PowerPoint側)。

誰に向くか。


11章 · Tome (RIP 2024) — 短い栄光

Tomeの物語は1章を割いて整理する価値がある。2020年代のAIスライドバブルの最も象徴的な事例だからだ。

誕生。 2020年、Adobe出身のデザイナーが創業。「ストーリーテリング中心のプレゼン」を掲げ、伝統的な16:9の箱から抜けて、スクロール可能な「タイル」UIを作った。

全盛期 (2022–2023)。 OpenAIがChatGPTを公開した直後、TomeはGPT-3を最速で統合したスライドツールの1つ。「プロンプト1行でデッキ1セット」が初めて現実になった時期。シリーズBで約7億ドルのバリュエーションを得た。日本・韓国でもインディハッカーやデザイナーの間で急速に広まった。

問題 (2024)。 無料ユーザーは急増したが有料転換率は低かった。出力は綺麗だが「これで何をするのか」が不明確だった。カンファレンス発表はRevealJS/Slidevが取り、役員報告はPowerPoint/Google Slidesから出なかった。デザイン自由度が低くマーケチームのディテールを満たせなかった。

シャットダウン (2024年後半)。 Tomeは「サービス終了」を告知し、無料/有料ユーザーにデータダウンロード期間を与えた。一部の機能や人材は他社が引き継いだという推測はあるが公式発表は限定的だった。

3つの教訓。

  1. AIはツールの十分条件ではない。 「AIでスライドを作る」自体は差別化にならない。同じ技術をGoogle・Microsoftがビルトインで載せられる。
  2. 有料転換モデルがないと生き残れない。 無料ユーザー数は問題ではなく、有料に行く具体的な理由(ワークフロー・統合・コンプラ)が必要。
  3. ポジショニングが揺れると死ぬ。 Tomeは「プレゼンツールか、ストーリーテリングツールか、デザインツールか」が最後まで曖昧だった。

12章 · Keynote / PowerPoint / Google Slides — 非Markdownのクラシック

本稿はMarkdownツール中心だが、2026年でもスライドの7割以上はここで作られる。クラシック3強も整理する。

Keynote (Apple)

PowerPoint (Microsoft)

Google Slides

クラシック3強の2026変化

最大の変化は AIがビルトインで埋め込まれた こと。Microsoft CopilotはPowerPointを事実上「Gamma的ツール」にする。Google GeminiはSlidesで同じことをする。この流れが続けば2027–2028年に独立系AIスライドツールの価値はさらに狭まる可能性がある。


13章 · 韓国 / 日本 — カカオスライド、ピクシブ、CyberAgentのプレゼン文化

韓国・日本のプレゼン文化はグローバルトレンドと少し違う。整理する。

韓国

日本

グローバル vs 韓国・日本

領域グローバル韓国日本
社内報告PowerPoint / Google SlidesPowerPointPowerPoint
開発者カンファレンスSlidev / RevealJS / KeynoteMarp / Slidev / KeynoteMarp / Slidev
AIスライドGamma、Plus AI初期初期
共有プラットフォームSlideShare(衰退)、NotionGitHub PagesSpeaker Deck
スタートアップピッチKeynote、Pitch.comKeynote、PowerPointKeynote、PowerPoint

14章 · 誰が何を選ぶべきか — 4ペルソナ

最終章。ツール比較は結局「私は誰で何をするのか」に帰着する。4ペルソナで整理する。

ペルソナA: カンファレンストーク / コードデモ

ペルソナB: 学術 / 博士公聴会 / 研究発表

ペルソナC: マーケティング / セールス / ピッチデッキ

ペルソナD: 役員報告 / 社内発表 / 四半期レビュー

ワンライナーの意思決定

最後の一行

2026年の真実: 「1ツールで全プレゼンをする」はほぼ不可能。 同じ人がカンファレンスではSlidev、社内報告はPowerPoint、速い初稿はGammaを使うのが普通。ツールは内容の形と聴衆によって変わる。

ツールを統合しようとせず、状況に合うツールを選んでワークフローを定義するのがベストプラクティス。


参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます