open-slideとは｜Claude Codeでスライド作成する使い方とMarp・Slidevの違い

Claude Codeでスライド作成する方法を調べると、出てくる答えはたいていMarpかHTMLかpython-pptxだ。どれもエージェントに書式を書かせるアプローチで、レンダリングや画面遷移は既存ツールに任せている。open-slideはそこを逆から攻める。スライドを書くのはエージェント、キャンバス・拡大縮小・ページ送り・発表モード・書き出しはフレームワーク側が持つ、という分担だ。2026年4月26日公開のMITライセンスOSSで、本記事執筆時点で6,899スター・494フォーク。

Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き

なお、ハイフンの無い openslide（openslide.org）は病理のホールスライドイメージを読むCライブラリで、本記事の対象とはまったくの別物だ。検索するときは 1weiho/open-slide で絞ると混ざらない。

open-slideとは——Claude Codeがスライドを書くための実行基盤

open-slideはリポジトリの説明文で自らを “A slide framework built for agents.” と定義している。ここでいうframeworkは、スライドを生成するアプリではなく、エージェントが書いたコードを動かす土台を指す。

役割分担ははっきりしている。エージェントが担当するのは slides/<id>/index.tsx の中身だけで、それ以外——ページ送り、サムネイル一覧、発表者ノート、タイマー、書き出し、ホットリロード——はすべて @open-slide/core が持つ。だからエージェントは「見た目と中身」だけに集中でき、プレゼンツールとして成立させるための周辺実装を毎回書かされずに済む。

ページの契約は驚くほど小さい。同梱の slide-authoring スキルが定めるファイル契約は次の形だ。

// slides/<id>/index.tsx
import type { Page, SlideMeta } from '@open-slide/core';

const Cover: Page = () => <div>…</div>;
const Body: Page = () => <div>…</div>;

export const meta: SlideMeta = {
  title: 'My slide',
  createdAt: '2026-05-16T12:00:00Z',
};
export default [Cover, Body] satisfies Page[];

export default が「propsを取らないReactコンポーネントの配列」であること、それだけがルールだ。1要素が1ページに対応し、順序がそのままページ順になる。レイアウト用のコンポーネントも、スライド種別の列挙も、テーマの継承階層も無い。デモスライドの表現を借りれば「No templates. No opinions.」——枠を与えないかわりに、React とWeb標準でできることは全部できる。

キャンバスは1920×1080固定で、フレームワーク側が表示領域に合わせて拡大縮小する。書く側は常に1920×1080の座標系で考えればよく、スキルは rem や vw、% ではなく絶対ピクセルを使うよう指示している。レスポンシブを捨てる代わりに、エージェントが「この見出しは何ピクセルか」を決め打ちできる——生成物の再現性という点では合理的な割り切りだ。

読者の3問に先に答えておく

何ができるのか。 自然言語でエージェントに指示して、発表できる品質のスライドを作り、ブラウザで発表し、HTML・PDF・画像PPTXとして配布できる。

何を解決するのか。 「エージェントにスライドを書かせる」ときに毎回発生する土台づくり——ページ送りの実装、1920×1080への収まり、発表者ビュー、書き出し——を肩代わりする。エージェントが書くべき対象を1ファイルに閉じ込める効果もある。

何を代替できるのか。 Marp・Slidev の置き換え候補になる。ただし後述の比較表のとおり、Markdownで手早く書きたい用途では置き換えにならない。置き換わるのは「凝った見た目をエージェントに作らせたい」ケースだ。

インストールと使い方——npx一発でスライド作成環境が立ち上がる

導入はコマンド1本で完結する。実際に手元（Node v22.13.1 / npm 11.1.0 / macOS）で流した結果を書く。

# 1. スキャフォールド（依存インストールまで一括）
npx @open-slide/cli init my-slide --use-npm

# 2. 開発サーバー起動 → http://localhost:5173/
cd my-slide
npm run dev

# 3. 静的サイトとしてビルド
npm run build

init は対話式でパッケージマネージャを選ばせるが、--use-npm / --use-pnpm / --use-yarn / --use-bun で明示指定できる。--no-install（依存インストールを飛ばす）と --no-git（git初期化とinitial commitを飛ばす）も用意されている。筆者環境では407パッケージ・約20秒でインストールが終わり、そのまま npm run dev が通った。

package.json に定義されるスクリプトは dev / build / preview / sync:skills の4本だけで、Vite の設定ファイルはプロジェクト側に出てこない。Vite・React・tsconfig は @open-slide/core の内側に隠されている設計で、スキャフォールド直後のプロジェクトに置かれるのは slides/・themes/・assets/・open-slide.config.ts といった「自分が触る物」だけだ。

生成された構成のうち、エージェント関連は次のようになっていた。

# スキャフォールド直後の構成を自分で確認する
ls -la my-slide/.claude/skills/     # → 5本すべてシンボリックリンク
ls -la my-slide/CLAUDE.md           # → AGENTS.md へのシンボリックリンク
find my-slide/.agents/skills -name SKILL.md | wc -l   # → 5

.claude/skills/ の5エントリはいずれも ../../.agents/skills/<name> を指すシンボリックリンクで、実体は .agents/ 側にある。CLAUDE.md も AGENTS.md へのシンボリックリンクだ。つまり AGENTS.md 規約が正で、Claude Code向けの配置はそこへのリンクという二層構造になっている。READMEは「Claude Code, Codex, Cursor, … どのコーディングエージェントでも動く」と書いているが、実測すると .cursor/ に相当するファイルは生成されない。Cursorで使う場合はAGENTS.mdを自分で読ませる形になる。この使い分けの背景はAI mdファイルとは｜CLAUDE.md・AGENTS.md・.cursorrules・GEMINI.mdの違いと使い分け早見表に整理してある。

同梱スキル5本の中身——エージェントは何を読んでスライドを書くのか

open-slideの中核は、実はランタイムよりも同梱スキルにある。エージェントの振る舞いがここで決まるからだ。実測したところ、スキャフォールドが配置するのは5本・計1,307行だった。

READMEが挙げているのは /create-slide と /slide-authoring、それに /apply-comments の3本だけで、create-theme と current-slide は記載が無い。行数で見ると create-theme は2番目に大きいスキルなので、READMEだけ読んで判断すると機能を1つ見落とすことになる。スキルという配布形式そのものについてはClaude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説を参照してほしい。

create-slide が書き出し前に必ず確認する4点は、スキル本文に明記されている。

・アセティック（見た目の方向性） — 固定のプリセットからは選ばせず、その題材に合わせた3案をエージェント側が提案する
・ページ数 — 3〜5（短い）／6〜10（標準）／11〜20（深掘り）のブラケット
・1ページあたりの文字量 — minimal（1行や大きな数字1つ）／light／standard／dense（多段組）
・モーション — static（動きなし）／subtle（フェードや登場のみ）／rich（キーフレーム・段階表示・ループ）

面白いのは、テーマを先に選んだ場合はアセティックの質問を省く、題材が曖昧なら先に別途「題材・聴衆・下書き」を聞く、といった分岐まで書かれている点だ。質問を機械的に4つ並べるのではなく、すでに答えが出ている質問はスキップして言い直すよう指示されている。

インスペクタと apply-comments の往復

open-slideで一番特徴的な編集ループがこれだ。開発サーバー上で要素をクリックしてコメントを付けると、コメントはソース中のJSXマーカーとして永続化される。形式はスキルに正確に定義されている。

{/* @slide-comment id="c-<8hex>" ts="<ISO>" text="<base64url(JSON)>" */}

マーカーは対象要素の開きタグ直後、最初の子として挿入される（要素の上に浮かせるのではなく、中に落とす）。text は {"note": "...", "hint"?: "..."} をbase64urlエンコードしたものだ。/apply-comments を実行するとエージェントがこれらを読み、編集を適用し、マーカーを削除する。

「プロンプトで直す」のではなく「画面上で指差してから直させる」ため、どの要素の話かをテキストで説明する手間が消える。エージェントとの往復でいちばん摩擦が大きい部分を、UI側で解決している。

Marp・Slidev・Presentonとの違い——スライド作成4方式を比較

「Claude Codeでスライド作成」という検索意図に対して、日本語圏で先に定着しているのはMarpだ。open-slideをそこに並べると、違いは3つの軸に集約される。誰が中身を書くのか・出力の素材は何か・直すループがどこにあるのかだ。

判断の目安はこうなる。Markdownで済む内容ならMarpのほうが速い。箇条書き中心の勉強会資料に、Reactの表現力もエージェント用スキル1,307行も要らない。一方、図・アニメーション・凝ったレイアウトを含む「見せる」デッキをエージェントに任せたいなら、Markdownの表現力が先に天井を打つ。そこがopen-slideの領域だ。

Presentonは軸そのものが違う。あちらは中身をLLMが生成するツールで、open-slideは中身を書く主体を外部のコーディングエージェントに委ねる実行基盤だ。「テーマを渡したら資料が出てくる」ことを期待するならPresenton側が近い。詳しくはPresenton とは｜Gamma代替のOSS AIプレゼン生成をDocker・APIで自己ホストにまとめてある。

発表モードと書き出し——HTML・PDF・画像PPTXの3種はUIから実行する

発表モードと発表者ビュー

作ったデッキは、そのまま開発サーバー上で発表できる。上部右の「発表」ボタン（ショートカット F）でフルスクリーン再生に入り、キーボードでページを送る。隣のプルダウンには発表オプションがあり、発表者ビューを選ぶと現在ページ・次ページのプレビュー・発表者ノート・タイマーが並ぶ画面になる。

画面下部には常時「発表者ノート ◯ / ◯ ページ」が表示されており、ノートは各ページのコンポーネントに紐づけて書く。ブラウザのタブをそのまま投影に使う前提の作りで、PowerPointやKeynoteに移し替えなくても登壇できる——というのが、後述する書き出しの制約と表裏の関係にある設計思想だ。

書き出しの実際

READMEには「One command exports your deck as a self-contained static HTML site or a print-ready PDF」とある。ここは実測すると表現に注意が要る部分だった。

まずCLIのサブコマンドを確認すると、こうなる。

$ npx open-slide --help
Commands:
  dev [options]          Start the dev server
  build [options]        Build a static site
  preview [options]      Preview the production build
  sync:skills [options]  Sync built-in skills from @open-slide/core into this workspace

書き出し（export）コマンドは存在しない。 静的HTMLサイトを作るのは build で、PDFはCLIからは作れない。PDFとPPTXの書き出しはブラウザUIのダウンロードメニューにある。

メニューには4項目が並ぶ。

・HTML として書き出し — 自己完結の静的HTML
・PDF として書き出し — ブラウザの印刷経路を使う
・画像 PPTX として書き出し — 各ページを画像として貼り込んだPPTX
・PPTX として書き出し — 「近日公開」バッジ付きで無効

3番目のラベルが「画像 PPTX」となっている点が重要だ。ソースを確認すると exportSlideAsImagePptx という関数で、各ページを2倍解像度でキャプチャし、16:9（EMUで12192000×6858000＝13.333in×7.5in）のスライドに画像として配置している。つまりPowerPointで開いても文字は編集できない。テキストが生きた通常のPPTX書き出しはメニュー上に枠だけあり、現時点では実装待ちだ。PowerPointへの持ち込みを前提に導入を検討しているなら、ここは事前に確認しておきたい。

「自己完結」はどこまで本当か

npm run build の出力を検証した。結果は次のとおり（v1.19.1・デモデッキ13ページ）。

ビルド成果物に現れる外部URLは www.w3.org（SVG/XMLの名前空間）、schemas.openxmlformats.org（OOXMLの名前空間）、それにライブラリのエラーメッセージ中のドキュメントURLだけで、いずれも実際に取りに行くものではない。フォントも外部CDNではなくローカルのwoff2を同梱している。「自己完結」という主張は、実測した範囲では成立していた。

なお最大JSチャンクは1,192KB（gzip 352KB）で、ビルド時にVite自身が500KB超の警告を出す。スライド1枚を配るには重めだが、これはビューア・発表モード・インスペクタ・書き出しまで含んだランタイム一式の重量だと理解しておけばよい。

日本語UIと設定——open-slide.config.tsで変えられること

日本語話者にとって見逃せないのが、日本語UIが公式に同梱されている点だ。ロケールは en・繁體中文・简体中文・日本語の4種で、画面右上の言語スイッチャーから切り替える。

切り替えると「発表」「発表者ノート」「PDF として書き出し」「スライドを検索」「新規フォルダ」といったラベルが日本語になる。機械翻訳を後付けした風でもなく、UI文字列として整備されている。

設定ファイル open-slide.config.ts で変えられる項目は、型定義を読むと次のとおりだった。

locale に @deprecated が付いている点は押さえておきたい。型定義のコメントは「スライドUIの言語スイッチャーから選べ」と明示している。設定ファイルに書いても、ユーザーが一度でも切り替えればそちらが優先される。設定で固定できるものだと思って書くと、期待どおりに効かない。

build.* の3つは配布形態を決める実用的なスイッチだ。社外に配るデッキで一覧や編集UIを見せたくないなら showSlideBrowser と showSlideUi を落とす、といった使い方になる。

導入前に確認したい注意点——依存の脆弱性と単一ファイルの肥大

好意的な点だけ並べても判断材料にならないので、実測して気づいた注意点を3つ挙げる。

1. スキャフォールド直後に npm audit が3件出る

インストール直後の状態で監査すると、次の結果になった。

$ npm audit
# high     : vite  <=6.4.2
#   - Path Traversal in Optimized Deps `.map` Handling
#   - server.fs.deny bypass on Windows alternate paths
# moderate : esbuild <=0.24.2
#   - dev server が任意サイトからのリクエストに応答しうる

スキャフォールドの devDependencies は vite: ^5.4.10 を指定しており、筆者環境では 5.4.21 が入った。いずれも開発サーバー側の問題で、build した静的成果物には同梱されない。とはいえ「開発サーバーを社内LANや --host で外に出す」使い方をするなら影響範囲に入る。自分の環境がどうなっているかは次で確認できる。

# 入っているViteの実バージョンを確認する
node -p "require('./node_modules/vite/package.json').version"

# 開発サーバーを外部公開していないか（config側の設定を確認）
grep -n "allowedHosts\|port" open-slide.config.ts

対処としては、開発サーバーを外部公開しないこと、公開する必要があるなら allowedHosts を絞ることが現実的だ。Vite本体のメジャー更新は @open-slide/core 側の追随を待つことになる。

2. 1スライドが1ファイルに集約され、かなり大きくなる

同梱のデモスライド getting-started は13ページで3,406行の単一 index.tsx だった。slide-authoring スキル自身も「完成したスライドはよく1,000〜1,800行になる」と書いており、1ページだけ直すときはファイル全体を読まず grep -n ": Page = " で目的のページを探して部分読みするよう指示している。

これは設計上の割り切りだが、エージェントのコンテキストを食う要因でもある。ページ数が増えるほど「全体を見渡す」系の依頼（パレット監査、ページ並べ替え）のコストが上がる点は見込んでおきたい。

3. READMEと実装にずれがある

本記事で確認しただけでも3か所あった。

・スキルは5本同梱されるが、READMEの記載は3本
・「One command exports … PDF」と書かれているが、CLIに書き出しコマンドは無い（PDFはブラウザUIから）
・「Claude Code, Codex, Cursor, …」とあるが、生成されるのは .claude/ と .agents/ のみで .cursor/ は作られない

活発に開発されているプロジェクト（npm公開は2026年4月19日、@open-slide/core は55バージョン、直近リリース1.19.1は2026年8月21日）ではよくあることで、欠陥というより文書の追随待ちだ。ただしREADMEの記述だけで導入を決めると期待値がずれるので、機能の有無はスキャフォールドして自分の目で確認するのが早い。AGENTS.md規約そのものの読み方はAGENTS.md 書き方・とは｜Codex/Devin/Claude Codeが読む指示ファイルとCLAUDE.mdの違いが参考になる。

結局どんなときに選ぶか

open-slideは「AIにスライドを作らせるツール」ではなく、「エージェントが書いたスライドを成立させる実行基盤」だ。この違いが、導入判断をほぼ決める。

選ぶ価値があるのは、Reactの表現力を使った凝ったデッキをエージェントに任せたいとき、画面を見ながら指差しで直す往復を重視するとき、そしてUIが日本語で動くことに価値を感じるときだ。1920×1080固定・絶対ピクセルという割り切りは、エージェントに書かせる前提では素直に効く。

選ばないほうがよいのは、箇条書き中心の資料をMarkdownで手早く作りたいとき（Marpが速い）、PowerPointでのテキスト編集を前提に配布したいとき（現状の書き出しは画像PPTX）、そして開発サーバーを外部公開せざるを得ない環境だ。

MITライセンスで、npx @open-slide/cli init から npm run build まで数分で確かめられる。判断に迷うなら、READMEを読み込むより一度スキャフォールドしてしまうほうが早い。

参照ソース

• 1weiho/open-slide — GitHub リポジトリ（README・AGENTS.md・ライセンス。スター数・フォーク数は2026年8月25日時点のGitHub API値）
• open-slide 公式サイト / ドキュメント
• @open-slide/core — npm（バージョン履歴・公開日）
• @open-slide/cli — npm
• OpenSlide（病理ホールスライドイメージ用Cライブラリ・別プロジェクト）