dek の設計思想
スライドは、喋るためにあります。ところが主流のツールは、どれもその前提で作られていません。PowerPoint も Keynote も Google Slides も、Marp も Slidev も、まず空のスライドを用意して、それを埋めるところから始まる。見出しを足し、図を置き、アニメーションを付ける。資料が立派になるほど、本番で喋り切るのが難しくなる。当日は時計を見て、3 枚飛ばして、いちばん言いたかったことを言い残す。
dek は逆の順で作ります。何を、どの順で、どれだけの尺で喋るかを先に書く。そのうえで「この瞬間、画面に何が出ているべきか」を考える。台本が親で、スライドはそこから派生するものです。
言い換えると、dek は発表のビルドシステムです。script.md がソースで、dekc sync はそこからスライドの骨格を生成します。ビルドがコードを生成するのと同じです。dekc lint はコンパイラが型を確かめるようにテーマの語彙に照らして各スライドを確かめ、--visual はテストのように描画して測ります。ビルドの成果物を出すのは dekc build、dekc pdf、dekc video です。ビルドがきれいに通れば、デッキに不備はありません。良いかどうかは、やはり作者が決めます。
dek が解きたい 3 つの問題
トークは一度きりではない
多くのスライドツールは、1 つのデッキを 1 つのプロジェクトとして扱います。発表のたびに新しいリポジトリを切り、テーマも規約もゼロから積み直す。前回学んだことは、前回のリポジトリに残ったままになります。
dek では プロジェクト が複数の デッキ を入れる場所です。規約はプロジェクトのもの。見た目は前回のデッキの続きから。台本とスライドはデッキごと。過去のトークが、次のトークの出発点になります。
エージェントには小さなファイルが要る
3,000 行の slides.md の 7 枚目だけを直す。人間にとっては単純な作業ですが、言語モデルにとっては妙に難しい仕事です。コンテキストが膨らみ、差分にノイズが乗り、ひとつの編集ミスがデッキ全体をだめにします。
dek では 1 スライドが 1 つの HTML ファイル、およそ 40 行です。編集対象は小さく、差分は読め、ミスがあってもその 1 枚で済む。dek を Slidev のテーマではなく独立したツールとして作った最大の理由がこれです。
エージェントは自分の描画結果を見られない
HTML を書いたエージェントは、その文字が枠に収まっているかを知りません。マークアップとしては完璧に見える。はみ出しに気づくのは、本番 30 分前の人間です。
dek はスライドを実際に描画し、見えたものを機械可読な診断として返します。はみ出し、コントラスト、欠けた画像。エージェントは書き、確認し、結果を読み、自分の間違いを自分で直す。人間を挟まずにこのループを回せます。
三原則
dek の設計はすべて 3 つのルールから来ています。どのルールも、文書に書いておくだけではなく、構造か lint で守られています。
1. script.md がすべての元になる
順序、喋る言葉、尺。この 3 つは script.md にだけあります。スライドの HTML は、その台本のセクションに従属するファイルです。親子関係が構造で固定されているので、台本とスライドのどちらか一方だけが更新されて食い違うことはありません。
だからスライドのファイル名に連番はありません。順序を持っているファイルは台本だけです。スライドの中でも同じで、要素は台本のビートの順に現れ、HTML はビートを id で指すだけです。data-step の数字は「この枚の k 番目のビート」の省略形にすぎません。
2. スライドは <section class="slide"> ひとつ
slides/ の各ファイルは、ルートが <section class="slide"> ひとつです。見た目は theme.css と、その枚だけにスコープされる任意の slides/<id>.css が受け持ち、文書の殻とプレイヤーはレンダラが付け足します。エージェントに渡すのは 40 行のフラグメントで、必要な文脈はそのファイルひとつで足ります。
デッキディレクトリにも同じ性質があります。デッキは外を参照しません。テーマも画像も声の設定も、すべて中にある。ディレクトリごとコピーしても、zip で送っても、5 年後に開いても同じように描画されます。プロジェクトはデッキを置く場所であって、デッキが依存する実行環境ではありません。
3. 規約は lint で守らせる
「使える CSS クラスはこれだけ」「トークン以外の生値は書かない」「デッキの外を参照しない」。こうした規約は、書き残しただけでは守られません。dek はそのすべてを lint ルールとして実装し、SARIF で出力します。
lint は測れるものを判定し、それ以上はしません。 lint が通らないうちはデッキは完成していません。通れば、ルールで判定できるものに問題はありません。開発サーバは保存のたびに lint を走らせるので、作業中のデッキは常に「通っている」か「なぜ通らないかが分かっている」かのどちらかです。スライドの釣り合いや話が成り立っているかのように、lint が判定できないことはあなたが決めます。dek はそのための材料として、シートと台本を渡します。声を付けても診断が増えるだけで、通っていたデッキが失敗に変わることはありません。
声と動画は台本の派生物です。台本自体には、どう見えるかもどう聞こえるかも書かれていません。
他のツールとの違い
| PowerPoint / Keynote | Marp | Slidev | dek | |
|---|---|---|---|---|
| 作る順序 | スライド先行 | スライド先行 | スライド先行 | 台本先行 |
| 作業の単位 | 1 ファイル = 1 デッキ | 1 ファイル = 1 デッキ | 1 リポジトリ = 1 デッキ | 1 プロジェクト = N デッキ |
| スライドの実体 | バイナリ | Markdown | 単一の slides.md | 1 スライド 1 HTML |
| 発表者の台本 | ノート（子） | 弱い | HTML コメント（子） | script.md（親） |
| 段階表示 | アニメーション | 部分的 | v-click（順序はスライド側） | ### ビート（順序は台本側） |
| 尺 | なし | なし | なし | duration + 字数 +（任意）TTS の実尺 |
| 動き | 独自 | CSS | Vue + 独自 DSL | CSS + View Transitions |
| エージェント接点 | 弱い | テキスト | MCP サーバ | CLI + AGENTS.md |
| 向いている用途 | 汎用 | 簡単な Markdown スライド | デモを含む技術トーク | 喋りが主役のトーク |
Slidev はこの領域で最も成熟したツールで、dek は多くを借りています。発表者ビューの同期、Playwright の任意依存化、CSS のスコープ規約はいずれも Slidev の解法です。決定的に違うのは、ファイルの粒度、台本の位置づけ、そして作業の単位です。
dek は Vue も UnoCSS も Monaco も Mermaid も依存に含めません。そのぶん lint と build が単純になり、素の HTML と CSS だけで完結することを制約ではなく強みとして保てます。
dek が向いていないこと
次のどれかが必要なら Slidev を使ってください。
- スライド内のインタラクション。クリックで動くデモや、聴衆の操作に反応するコード。dek のスライドスクリプトは時間の関数を描くだけです
- ライブコーディングや埋め込みエディタ
- npm で配布されるテーマのギャラリー
- CSS とシーク可能な
draw(t)の外に出るアニメーション DSL - PowerPoint で編集できる図形、Keynote 形式への書き出し、WYSIWYG 編集。
dekc pptxは文字を編集できる形で、台本をノートに入れて渡せますが、各スライドの図形は画像です
dek は、ひとりで保守できる大きさを守り、喋りが主役のトークに集中します。細かい境界は FAQ にあります。
次
はじめるで、HTML を書かずに同梱テーマのまま発表できるところまで進みます。