dembrandt（dembrandt/dembrandt・GitHubスター3,394・MIT）は、任意のWebサイトのデザインシステムを1コマンドでデザイントークンに変換するCLIです。ロゴ、色、タイポグラフィ、余白、境界線、影、モーション、コンポーネント——これらをW3Cのデザイントークンとして数秒で取り出します。開発の中心はデザインとコードの間を埋める「design-to-code」で、Playwrightで実際にページを描画し、DOMの計算済みスタイルを読むのが特徴です。
「任意のサイトをトークン化」という主張は強力なので、v0.31.1を実際に入れて、抽出・W3C出力・CIドリフト検出・MCP連携までを確かめました。結論を先に言うと、仕組みは「ソースの推測」ではなく「描画結果の観測」で、そのぶんCanvas/WebGL描画のサイトは読めないといった限界も明確でした。まず何ができて、どこで止まるのかを実測で切り分けます。
30秒でわかる dembrandt
・何をする？ Webサイトの色・タイポ・余白・影・モーションをW3Cデザイントークンとして1コマンドで抽出
・どう読む？ Playwrightで実際に描画し、DOMの計算済みスタイルを観測（ソース推測ではない）
・出力： --dtcg（W3C標準）・--tailwind（v4 @theme）・--design-md（AI向け）・--wcag（AA/AAA判定）
・CI： --compare baseline.json でドリフト時に終了コード1。GitHub Actionも提供
・限界： Canvas/WebGL描画は解析不可、ダークモードは --dark-mode 必須、既定は1920×1080
・ライセンス/版： MIT・v0.31.1（2026-09-02）・★3,394・活発。他サイトへ向ける前に利用規約の確認が必要
デザイントークンが「デザインシステムのどこに位置するのか」は、デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】 で全体像を整理しています。dembrandtはその最下層——個々のトークンを、既存サイトから逆算して取り出すツールだと捉えると位置づけが掴めます。
dembrandtとは——描画結果からトークンを逆算する
デザイントークンは、色や余白といったデザインの決定を「名前付きの値」として持つ最小単位です。ふつうはデザインシステムを作る側が定義しますが、dembrandtは逆に、既に公開されているサイトの描画結果からトークンを抽出します。
キモは「ソースを読む」のではなく「描画結果を観測する」点です。Playwrightがページをレンダリングし、dembrandtはDOMの計算済みスタイル（computed styles）を読み取ります。そのうえで色の使用頻度と確信度を分析し、近いタイポグラフィをまとめ、余白のパターンを検出してトークン化します。CSSファイルを静的に解析するのではなく、ブラウザが最終的に適用した値を拾うので、SassやCSS-in-JSでどう書かれていても結果は同じ土俵に乗ります。
抽出できる主な要素は次のとおりです。
| 種類 | 抽出内容 |
|---|---|
| 色 | セマンティックカラー・パレット・CSS変数・グラデーション |
| タイポグラフィ | フォント・サイズ・ウェイト・出典・フォントファイルURL |
| 余白 | margin/paddingのスケール |
| 境界線・影 | 角丸・線幅・スタイル・色／シャドウ |
| モーション | 時間スケール・イージング・コンポーネント別のホバー挙動 |
| コンポーネント | ボタン・バッジ・入力・リンク／ブレークポイント／アイコン・フレームワーク |
実測：dembrandtのインストールと抽出
手元での実測です。Node.js 18以上が要件で、Node 22の環境で確認しました。インストールは2段階です。
npm install -g dembrandt
dembrandt install-browser # 一度だけ：対応するChromiumを取得
dembrandt example.com # 抽出（自分が所有・許可されたサイトに）
install-browser が要るのは、dembrandtが playwright-core 経由でChromiumを動かすものの、playwright-coreがブラウザ本体を同梱しないためです。この一手間を省くと browser engine not available で止まります。npx dembrandt <URL> でも同じ流れです（先に npx dembrandt install-browser）。
向ける先には制限があります。 READMEの「Intended Use」は、自分が所有するサイトか、自動アクセスが利用規約で許可されたサイトにのみ実行するよう求めています。本記事の実測は、ドキュメント用に予約されたドメイン（example.com）を対象にしました。競合サイトの配色を調べる用途は技術的には可能ですが、robots.txt・レート制限・著作権を尊重し、抽出物で第三者のロゴ・商標を複製しないこと、という条件が付きます。
実際に dembrandt example.com --wcag を走らせると、Chromiumで描画したうえで次のようなトークンを返しました（example.com はドキュメント用の予約ドメインで中身が最小限のため、値も素朴です）。
Colors ● #eeeeee background ● #000000 text
Typography system-ui [ 24px (heading-1), 16px (body) ] Weights: 700
Spacing System: 8px
Links #334488 decoration: underline
WCAG 18.1:1 AAA (#000000/#eeeeee) 7.79:1 AAA (#334488/#eeeeee) 2/2 pairs pass AA
「背景 #eeeeee・文字 #000000・8pxの余白システム・本文16px」といった値が、CSSソースの解釈ではなく描画後の計算済みスタイルから取れているのが分かります。--wcag を付けたので、抽出した色ペアのコントラスト比（AA/AAA判定）まで同時に返っています。JavaScriptの重いサイトでは「Main content selector がタイムアウトした（抽出が不完全な可能性）」といった注意も併記され、取りこぼしの可能性を黙って隠さない作りでした。
用途に応じて出力形式を切り替えます。ここが実務での価値の中心です。
dembrandt example.com --dtcg # W3C Design Tokens（Style Dictionary / Tokens Studio向け）
dembrandt example.com --tailwind # Tailwind v4 の @theme CSS（観測値のみ）
dembrandt example.com --design-md # AIエージェント向け DESIGN.md
dembrandt example.com --wcag # 実DOMのペアでWCAGコントラストをAA/AAA判定
dembrandt example.com --crawl 10 # 10ページを1出力にマージ（クロスページで確信度を補強）
--dtcg はW3C標準のデザイントークンなので、Style DictionaryやTokens Studioにそのまま流し込めます。--tailwind は観測した値だけをTailwind v4の @theme として吐くため、既存デザインをTailwind設定へ写すのに使えます。--design-md は、AIコーディングエージェントにデザインの文脈を渡すための DESIGN.md を生成します。
実測：CIドリフト検出とMCP連携
dembrandtが単なる抽出ツールに留まらないのは、デザインの逸脱をCIでゲートできる点です。プレビュー環境を抽出し、コミット済みのベースラインと比較して、トークンが動いたらジョブを落とします。
# GitHub Actions
- uses: dembrandt/[email protected]
with:
url: https://preview.example.com
baseline: .dembrandt/baseline.json
GitHub以外のCIでも、dembrandt URL --compare baseline.json --json-only がドリフト時に終了コード1を返し、トークンごとの変化を changes[] として出力します。「色や余白が意図せず変わっていないか」を、テストと同じ感覚でPRに対して検査できます。
AIエージェントからも呼べる：MCPサーバとして claude mcp add --transport stdio dembrandt -- npx -y --package dembrandt dembrandt-mcp で追加すると、Claude Code・Cursor・WindsurfなどのMCP対応クライアントから使えます。エージェントに「このサイトの配色を抽出して」と頼むと自動で呼び出され、get_design_tokens・get_color_palette・get_typography などのツールが応答します。抽出は job_id を返し、get_job_status でトークンを受け取り、export_dtcg などの純解析ツールへ同じidを渡す——という非同期の作りです。
抽出できないケースと、使いどころ
dembrandtの限界ははっきり文書化されています。ここを理解しておかないと「取れないサイト」で時間を溶かします。
主な限界：
・Canvas/WebGLで描画するサイトは解析不可——読むべきDOMが存在しないためです（ゲームやビジュアライゼーション系は要注意）
・ダークモードは自動検出されず、--dark-mode フラグが要る
・ホバー／フォーカス状態はCSSからの抽出で、完全に対話的な再現ではない
・JavaScript依存の重いサイトはハイドレーション時間（初期8秒＋安定4秒）が要り、--slow でタイムアウトを3倍に
・既定ビューポートは1920×1080（モバイルは --mobile で390×844）
使いどころは明確です。既存サイト（自社プロダクトや、許可を得た対象）のデザインを棚卸ししてトークン化したいとき、リデザインの前に現状の色・タイポ・余白を数値で把握したいとき、そしてデザインの逸脱をCIで監視したいときに向きます。逆に、Canvas/WebGL中心のサイトや、まだ公開されていないデザインには使えません（描画された実DOMが前提のため）。
「サイトのデザイントークンを1コマンドで抽出する」という同じ発想のツールは他にもあり、designlangとは｜サイトのデザイントークンを1コマンドで抽出、npx版の落とし穴まで実測 と比べると、出力形式やCI連携の設計思想の違いが見えます。抽出したトークンを「毎晩自動で採点・比較する」ところまで運用する例はAstryxとは｜Metaのデザインシステムが「agent ready」を毎晩shadcn/uiと採点比較している が参考になります。
開発状況と、いま使うかの判断
dembrandtは活発に開発されています。最新はv0.31.1（2026年9月2日）、GitHubスター3,394、既定ブランチへの最終pushは2026年9月8日。CLI本体はMITで無料、スポンサーシップは「強制レイヤ」（コミット済みベースライン・CI/CD向け取り込みAPI・スナップショット履歴のAppプラットフォーム）を支える、というオープンコア構成です。
つまり、抽出とW3C／Tailwind出力・単発の --compare まではMITのCLIで完結し、チームでの継続的なドリフト監視ダッシュボードやSlack/GitHub通知が要る段階でApp／スポンサー層が視野に入る、という切り分けです。まずは無料のCLIで手元のサイトを1本抽出し、出力が期待どおりかを見てから、CI組み込みへ進めるのが現実的です。
参照ソース
- dembrandt/dembrandt — GitHubリポジトリ（README・出力フラグ・CI連携・限界事項。2026-09-09時点でv0.31.1を確認）
- dembrandt — 公式サイト / Recipes（役割別のコマンド例・ドキュメント）
- 実測：Node.js 22環境でv0.31.1を導入し、
install-browserでChromiumを取得のうえexample.comを--wcag付きで実抽出（背景#eeeeee・文字#000000・8px余白・WCAG 18.1:1 AAA等を取得）し、全出力フラグを確認（2026-09-09）
