明日から真似できる、AIでデザインシステムを活用する方法

2026年8月21日開催「Vibe.TOKYO, AI & CRAFT」(主催: 株式会社ビビビット / 共催: Qiita株式会社)の登壇資料です。

DLsiteのデザインシステムを題材に、AIが仕様を理解しやすいドキュメントのつくり方、迷ったときに止まる条件の設計、フックによる自動チェックまで、明日からチームで真似できる「AI×デザインシステム」の実践方法を紹介しています。

登壇者: 臼井 重貴(株式会社viviON 開発部 プロダクトデザインチーム)

▼ ドキュメント作成の進め方やフックの具体的な作り方は、後日viviON公式noteで公開予定です
https://note.com/vivion_design

▼ X(最新情報を発信中)
https://x.com/vivion_design

Transcript

1. Vibe.TOKYO, AI & CRAFT 明日から真似できる、
 AIでデザインシステムを活用する方法 臼井 重貴
2. プロダクトデザインチーム 臼井 重貴 Shigetaka Usui 2023｜新卒でviviONに入社 2023｜DLsiteのプロダクトデザインを担当 2023｜DLsiteのデザインシステムを立ち上げ 2025｜viviONのデザインシステムを立ち上げ 現在 ｜DLsiteのリアーキテクチャ・デザインシステム全般を推進
3. AGENDA 01 viviONについて 02 DLsiteが抱える課題 本日の流れ 03 Nuxt化にデザインシステムを導入 04 ドキュメントをAIに読ませて実装の精度を確かめた 05 読まなくても守れるように、フックで止める 06 まとめ
4. 01 v i v i O N に つ いて
5. 01 viviONについて PURPOSE ユーザーとクリエイターが楽しみながら、 幸せに生きていける社会にする
6. 01 viviONについて viviONグループは、 二次元コンテンツを軸に30年間サービスを提供している会社 1996年のサービス開始から30年、ユーザー数は加速して増えています。 2013 50万人 2021 620万人 2024 1,300万人 現在 1,800 万人 二次元コンテンツ電子配信サービス VTuberプロダクション viviONグループ全体で約30のプロダクトやサービス、レーベルを運用 電子コミックのストア・アプリ 総合グッズオンラインストア
7. 01 viviONについて 多くのユーザー様に、さまざまなエンタメを届けている 全14言語 DLsiteの対応言語 ※ ピンクは対応14言語を公用語とする国・地域 639億円 2025年度 2023年度 529億円 2024年度 562億円 30期以上連続で前年比の売上を更新
8. 01 viviONについて 今回のテーマ DLsiteのデザインシステムを、 人とAIの両者が使いやすいように整えた話をします。 私の関わり 二次元総合ダウンロードサイト ・デザインシステムの設計・運用 ・開発環境のモダナイズ（デザインと実装の間で）
9. 02 DLsiteが抱える課題
10. 02 DLsiteが抱える課題 30年目! 今年で 同人誌・ゲーム・ボイス・電子書籍などを扱い、 クリエイターとユーザーをつなぐ二次元コンテンツのECサービス 約10万ファイルのコードベース 38の決済手段
11. 02 DLsiteが抱える課題 30年続いてきた結果、開発を難しくする負債も抱えていた 約3,300色あんねん サイトで使われている色 （似て非なる色が多い） 1万行超えのSCSS 1万行超のものを含めCSS関連ファイルが 900個近く存在し、影響範囲の特定が困難
12. 02 DLsiteが抱える課題 負債を解消するため、 サービスを止めずに旧環境からNuxt化を進行 段階的にNuxt環境へ移行 サービスを動かしたまま、機能単位で少しずつ移す。 旧環境と新環境がしばらく併存 ユーザーには、一つのサービスのまま提供。 全面刷新ではなく、動かしたまま少しずつ負債を解消。
13. 03 Nuxt化に デザインシステムを導入
14. 03 Nuxt化にデザインシステムを導入 進行中のNuxt化に、 デザインシステムを乗せることにした 乗せる共通基盤 ＝ デザインシステム トークン ／ UI部品 ／ 使い方のルール ▼ 乗せる 技術基盤 ＝ Nuxtなどの新しい開発環境 Nuxt化の完了後ではなく、移行中にデザインシステムを導入。 負債を新環境へ持ち込まないために、技術基盤とUI基盤を一緒に整える。
15. 03 Nuxt化にデザインシステムを導入 前提：viviONのデザインシステム構造について 職能 PD（プロダクトデザイン） FE（フロントエンド） ノンドメイン VDS VDS Framework トークン コンポーネント トークン コンポーネント Figma MCP ルール ※ viviONのサービスが横断で使う共通基盤（トークン・共通UI部品・ルール） プロダクト毎にVDSライブラリを追加して利用 ドメイン npmパッケージとして利用想定 React DLsite comipo Ci-en Web DLsite comipo Ci-en Web トークン トークン トークン トークン トークン トークン トークン トークン コンポーネント ※ プロダクト固有のUI・判断・運用ルール コンポーネント コンポーネント コンポーネント Figma MCP コンポーネント Claude コンポーネント コンポーネント コンポーネント
16. 03 Nuxt化にデザインシステムを導入 デザインシステムは、 デザイナーとフロントエンドエンジニア（FE）で
 一緒に作ってきた 🧑‍🎨 デザイナー Figmaで設計・仮実装 🧑‍💻 FE コードレビュー・組み込み ✅ 本番リポジトリへ反映 この文化が、後のAI実験でも「出力を一緒に評価し、ルールやフックへ戻す」土台になった。
17. 03 Nuxt化にデザインシステムを導入 ただ、ここで問題が起きた
18. 03 Nuxt化にデザインシステムを導入 デザインシステムを社内に浸透する中で、
 詳しい人だけが分かる状態では限界があった 以前 現在 少人数が開発しており、ほぼ利用者=開発者。 そのため会話と経験で補えてしまっていた。 「この色は、どれ？」 複数のチーム・新しいメンバーが利用。 質問が多くなり、ドキュメント化が急務に。 「コンポーネントは、どう使う？」 暗黙知だった判断が、質問として一気に表面化した → ドキュメント整備へ。 「例外は、誰に相談する？」
19. 03 Nuxt化にデザインシステムを導入 そこで、人間が読んで理解できるように Notionでドキュメント化することにした 使う人が増えた 会話や経験だけでは 伝わらない 詳しい人の頭の中にあった 判断を、言語化する 会話や経験で補っていた“詳しい人の判断”を、みんなが参照できるようNotionに書こうとした。 ※ このときの“ドキュメント”は、Notionなど人間が読みやすい形の文書を想定していた。
20. 03 Nuxt化にデザインシステムを導入 人間だけではなく AIも読めるドキュメントを作るという目標に変えた 人間だけが読むドキュメント 人間とAIが同じルールを読むドキュメント 読み手： 読み手： 🧑‍🎨 デザイナー 🧑‍💻 エンジニア 🧑‍🎨 デザイナー ドキュメントに書いた内容 ① 設計意図・原則・使い方 ② 迷ったときに止まる条件 ③ 例外の相談方法 🧑‍💻 エンジニア 🤖 AI
21. 04 ドキュメントをAIに読ませて 実装の精度を確かめた
22. 04 ドキュメントをAIに読ませて実装の精度を確かめた 人間とAIが、同じ判断をできるドキュメントを作った 設計意図・原則・使い方 悪い例と良い例 迷ったときに止まる条件 例外の相談方法 なぜそうするのか・迷ったらどう判断するかまで書いたガイドライン。 「元データが無ければ実装せず、URLを依頼」などの停止ルール。 ❌ダメな例と✅良い例をセットで示し、行間を無くす。 理由を添えて届け出て、人間に承認してもらう手順。 検証方法：同じお題で20回（ドキュメントなし3回／あり17回）実装を回した。Claude Code (opus4.7) ＋Figma MCPを使用。 ※ 今回はカラー構造の移行期と重なったため、補助的にFigmaとコードの対応表も作成した。
23. 04 ドキュメントをAIに読ませて実装の精度を確かめた 作るときに気をつけた、3つのポイント 1 答えだけでなく、 判断のしかたを書く 意図・原則・使い方＋ 悪い例と良い例。 2 迷ったときに 止まる条件を決める 「元データが無ければ実装しない」 などの停止ルール。 3 移行中の情報は、 対応関係を補足する Figmaとコードの対応表を添える。
24. 04 ドキュメントをAIに読ませて実装の精度を確かめた ① 答えだけでなく、判断のしかたを書く AIには「結論」だけでなく、判断のしかたまで渡す ❌ AI向きではない書き方 「色はブランドカラーを適切に使い分ける」等の結 論だけ 行間は読み手が補ってくれる前提 AIはこの行間で毎回ちがう解釈をする ✅ AI向けの書き方 意図：なぜこの色を使うのか 原則：迷ったら止まって聞く 使い方：$color-primary を mixin 経由で使う、 ダメな例と良い例はこう 重要なルールは原文を読ませる。要約はニュアンスを落とす（要約だけに頼る挙動は、6回目で観測）。
25. 04 ドキュメントをAIに読ませて実装の精度を確かめた ② 迷ったときに止まる条件を決める 「迷ったら止まる」を、具体的な条件にした ## 停止条件（docの記述イメージ） - masterコンポーネントのFigma URLが無い場合、 実装を開始せず、URLを依頼して止まる - 対応するトークンが見つからない場合、 近似で埋めず、相談する 実装前に確認です。 masterコンポーネントのURLください。 「良い感じにして」は守れなくても、「◯◯が無かったら止まって」なら守れる。
26. 04 ドキュメントをAIに読ませて実装の精度を確かめた ③ 移行中の情報は、対応関係を補足する Figma blue 5%の値を参照した セマンティックカラーがある コード blue 5%の値を参照した セマンティックカラーがない AIが近似で補う そこで、移行期のあいだは Figmaとコードの対応表を添えた（小さな例） Figmaでの名前 コードのトークン 実装方法 surface_alpha $color-surface-alpha mixin経由で参照 ※ カラー構造の変更時期と検証が重なり、新旧の名前・値が併存していた。「いつでも対応表が必要」という一般論ではなく、移行期に必要な情報を補った事例。
27. 04 ドキュメントをAIに読ませて実装の精度を確かめた 実際にドキュメントを読んだ回は、ルール違反が減った ✅ 止まれるようになった ✅ 正しく辿れるようになった ✅ 相談するようになった 元データが無いと、実装せずに URLを請求してくるように。 対応表から正しいトークンに 辿り着き、勝手な近似が減った。 既存部品で表現できない例外を、 無断実装せず相談してくるように。 内容には効果があった（※改善は体感6〜8割。固定A/Bの定量比較ではない） しかし、さらなる問題が...
28. 04 ドキュメントをAIに読ませて実装の精度を確かめた ルールを守れた回と守れない回が行き来した ✅ 9回目 ❌ 10回目 ✅ 11回目 ❌ 12回目 ✅ 13回目 ❌ 14回目 ❌ 15回目 原文を 確認した 要約だけで 進めた 元データを 確認した 近い値で 補った 迷ったところで 止まれた 最後の確認が 抜けた 提出時の手順が 抜けた うまくいった次の回でも、別の手順が抜ける。 ドキュメントを用意しても、結果は安定しなかった。 ※ 回数との対応は、傾向を伝えるための概略。厳密な回別集計ではない
29. 05 読まなくても守れるように、 フックで止める
30. 05 読まなくても守れるように、フックで止める フックは決めたタイミングで自動的に動く きっかけ 自動で行う確認 ファイルを保存する 使ってはいけない値がないか、確認する コードをpushする 既存の動きに問題がないか、確認する 問題があれば警告し、必要に応じて先へ進めないようにする。 ❌ ガード(エラー): -packeges/hogehoge/hugahuga/component.vue:107 生カラー #4b4b4bを <style>に直書きしています。 色は必ずトークン(var(---xxx) / SurfaceColorStyle 等)で経由で書いてください(禁止2 / figma-tokenmap.md)
31. 05 読まなくても守れるように、フックで止める ドキュメントは“読まれて効く” フックは“自動で動く” 📖 ドキュメントの特徴 ・人やAIが”読んだとき”に効く ・理由や判断方法を伝えられる 🚧 フックの特徴 ・保存 / 提出など、決めたタイミングで自動で動く ・読んだかどうかに関係なく確認し、 問題があれば警告または停止する 「文章か仕組みか」ではなく、役割の違い。越えてはいけない線だけをフックで守る。
32. 05 読まなくても守れるように、フックで止める フックによって、3つの見落としを減らした Before フック（止める仕組み） After 元データの有無を確認 なければ止まって、 URLを依頼 使ってはいけない 色や値を使う 保存時に確認 修正するまで 先へ進めない 一つの箇所を直した影響で、 もともと動いていた 別の箇所に問題が出る 提出時に、関連する箇所も確認 問題を残したまま 提出しない 元データがないのに、 AIが近い値で補う
33. 05 読まなくても守れるように、フックで止める 人間が決め、AIが提案し、フックが違反を止める この役割分担で作業を行った事で... ✅ 属人化の解消 ✅ 品質を保ったまま、速く届く これまでデザインシステムに関わっていなかったメンバーで も、一定の品質でコンポーネントを作れるようになった コンテキストを把握したAIが工程を担い、
 フックが違反を止める。
 品質を保ったまま、実装までの時間が短くなった デザインシステムを整えることが目的ではない。 空いた時間を、ユーザーとクリエイターへの改善に使うために続けていく。
34. 06 まとめ
35. 06 まとめ 判断を助けるものはドキュメントに。 破綻を招くものはフックで止める。 📖 ドキュメントに書くこと ・「こうしてほしい」「こうしてほしくない」 ・設計意図・判断の原則 ・良い例と悪い例 ・迷ったときの相談方法 🚧 フックにすること ・「これをすると破綻する」条件 ・「ここだけは越えてはいけない」線 ・保存・提出時に自動で確認し、 該当したら止める 判断の余地は文書で伝え、破綻する線は仕組みで守る。
36. 06 まとめ 大切なおしらせ 後日、viviON公式noteで公開！ 🎁 どうやってドキュメント作成を進めたのか 🎁 フックの具体的な作り方 デザインチームの公式Xをフォローして、 公開情報をお待ちください。 @vivion_design