AI時代のコンポーネントライブラリ制作──Sparkle Design for Reactで考えたこと
先日ついにガイドラインサイトとReactコンポーネントライブラリを公開した「Sparkle Design」。
グッドパッチ公式としては、上場以来初となるOSS（オープンソースソフトウェア）を実現する中で、考え続けたSparkle Design for React開発での工夫の数々をSparkle Designコアチームのテックリードである藤井（とうよう）が紹介します。
以前、エンジニアが執筆する技術ブログ「Goodpatch Tech Blog」の方で、Figmaプラグイン側の裏側も記事化したので、合わせてご覧ください。
https://goodpatch-tech.hatenablog.com/entry/sparkle-design-02-plugin
目次
デザインシステムのためのデザインシステム──いかにして理念を実現するか
Sparkle Designの中核となるコンセプトは「デザインシステムのためのデザインシステム」です。言い換えると、デザインシステムの専門家がいなくても、自分のプロダクトに合ったデザインシステムを一定の品質で持てるようにする。この体験を実装でどう支えるかが、全ての設計の判断軸となっていました。
そこで、Sparkle Designは基本としてshadcn/uiをベースに作成することにしました。ほとんどのコンポーネントがshadcn/uiのスタイルを調整する形で実装されています。
shadcn/uiの特徴は、コンポーネントを1個ずつ取得でき、手元で中身を自由に書き換えられること。パッケージとしてロックインされる従来のUIライブラリと違い、「必要な分だけ、自分のプロダクトの一部として取り込める」んです。
この性質をSparkle Designでも引き継ぐべく、shadcn/uiにオリジナルのコンポーネントなどを登録できる仕組みであるregistry機能にも早い段階から対応を進めてきました。2025年6月ごろからはMCP対応もされている機能なので、Cursor / Claude CodeなどのAIが必要なコンポーネントを自律的に取りに来られるようになっています。結果として、最低限の品質を簡単に保証しつつ、柔軟な導入ができる状態を作れました。
こうして、Sparkle Designのコンポーネントを柔軟に導入する、というコンセプトの一角を実現できましたがまだ足りません。「デザインシステムのデザインシステム」ということは、Figma PluginのSparkle Design Theme Settingsで実現したように、品質を保証したまま全く別のデザインシステムとして扱えるようにならないといけません。これはshadcn/ui形式だけでは不十分、というより自由度が高すぎるため適していませんでした。
そこでSparkle Design for Reactは、sparkle.config.jsonという設定ファイルとsparkle-design-cliという専用CLIツール（コマンドラインインターフェイス）の2つを用意しています。
Sparkle Design for Reactはそれ単体ではスタイルが当たっていません。一見不便なようですが、あえて外側からスタイルを当てる形式にすることでカスタマイズ性を実現しました。
具体的には、Sparkle Design for Reactを活用いただくプロジェクトでsparkle.config.jsonという名前で、以下のようなファイルを用意していただきます。
{
"primary": "blue",
"font-mono": "BIZ UDGothic",
"font-pro": "BIZ UDPGothic",
"radius": "md"
}
これはSparkle Design Theme Settingsで設定できる項目をJSON形式で表現したもので、Reactコンポーネントの公開と合わせて、Figmaプラグイン側の設定値をこのファイル形式で書き出せる機能もリリースしています。primaryカラー・フォント・角丸といった項目は、Figmaプラグイン側で扱える選択肢と基本的にそろえてあるので、デザインと実装の見た目がずれません。
このファイルを置いた上で以下のコマンドを実行すると、コンポーネントにスタイルを当てるためのファイル群が生成されます。
npx sparkle-design-cli generate
セットアップは1コマンドで終わらせる
そして、ここまで書いた一連の準備は、実は1コマンドにまとめてあります。
npx --yes sparkle-design-cli setup --assistant claude
依存関係の追加からCSS生成、AI向けガイドの設置まで、本来なら数十分〜数時間かけて環境を整える導入作業を、このコマンド一発で終わらせるようにしてあります。既存ファイルは上書きしないので、入れ直しや段階的な導入も安全。--assistant には claude / cursor / codex / generic から選べます。
この仕組みによって、「今日からSparkle Designで作ってみよう」と思ったその日のうちに、自分のプロダクトに合ったデザインシステムが動き始める状態を用意できました。まさに「デザインシステムのためのデザインシステム」を技術面で実現したわけです。
AI時代にふさわしい機能を考え続けた1年間
GitHubのコミット履歴を見ていただければ分かる通り、現在公開しているコンポーネント一式は比較的早い段階で仕上がっていました。残りの時間は、社内でほぼ初となるOSS公開のための調整を進めていたのですが、その間、世の中は次から次へと変わっていきます。
そう。生成AIの発展です。
そのため、ここ1年はひたすら、どういうことを実現すればAI時代にふさわしいコンポーネントライブラリになるか？を考え続けていました。
先ほど紹介したshadcn/ui registry機能によって、ある程度はshadcn MCP server経由でAI活用できます。またFigma Code Connect（Figmaのコンポーネントと実装コードを紐づけて、デザインから直接コードを参照できるようにする仕組み）も対応を進めていたので、Figma経由での活用も一定できるようになってました。
しかし、純粋にコンポーネントライブラリとして考えたとき、世に広く使われ、いい使い方が広まっているshadcn/uiなどに比べると、どうしてもAIによる生成コードのクオリティが下がってしまう、というのは避けようのない事実でした。
そこで、「AIに任せたときの成果物のクオリティを、Sparkle Designの文脈に合わせて引き上げる」ことを目標に、以下のような観点でエコシステムを構築していきました。
- 導入で迷わせない：人間もAIも同じコマンドでセットアップできるよう整え、指示のブレを最小化
- 使い方を伝える：Skillsという形でAIエージェント向けの手順書を用意し、迷いどころをあらかじめ潰しておく
- 誤用を自動で指摘する：CLIツールで、Sparkle Designとして望ましくない書き方をまとめてチェックできるようにする
- 外部連携で恩恵を受ける：shadcn/ui registryやFigma Code Connectなど、既存のAI活用導線にはまず乗せる
- OSS開発自体もAIと：リポジトリにもAIエージェント向けのガイドを揃え、追加実装もAIと進めやすい状態に
このように開発側・利用側の双方で、AIと人間が同じ品質の成果物に辿り着ける土台を整えていきました。
特にSkillsとCLIツールの用意には力を入れました。Skillsは、AIエージェントが「Sparkle Designを使うときはこの手順で」と自律的に判断するためのいわば“台本”。Agent Skillsという開かれた仕様に沿っていて、Claude CodeやGitHub Copilot、Cursor、Codexなどから利用できます。GitHub CLIにも公式のgh skillコマンドが用意されたので、リポジトリから直接インストール可能。どのAIアシスタントを使っていても同じ品質の提案が返ってくるようになっています。
このAI時代、デザインシステムを新規で作るというのは、学習データがない中で使ってもらうということでもあります。つまり、いかにAIにデザインシステムのことを正しく理解してもらうかが、最終的な成果物の品質を左右するわけです。
テーマだけであれば、それこそStitchで話題になったDESIGN.mdやCSSさえあれば事足りるのですが、それらは細かいインタラクションや、コンポーネントのコードとしての使い方を伝えるには至りません。
そこでセットアップや使い方、ガードレールといったところはSkillsとCLIに寄せてAIが自律的に判断できるようにしました。例えば、導入用のスキルはプロジェクトの状態を見て不足しているステップだけを案内しますし、CLIにはcheckコマンドを用意して、Sparkle Designを使う上でのアンチパターンをまとめて検出できるようにしています。できる限り機械的にできる部分はプログラムに起こすことで精度を向上させています。
最終的には、以下のようにFigmaを含めた全体が連動するように運用しています。
AI時代だからこその「デザインシステムのためのデザインシステム」
先日のClaude Designリリースなどもあり、デザインの価値もどんどん変化してきていると思います。
その中でSparkle Designの掲げる「デザインシステムのためのデザインシステム」がどういう立ち位置になるのか、を考えると、個人的には変わらない、むしろ価値が上がっていくだろうと考えています。
Claude Designにはデザインシステムを作る機能があります。一度動かしてみた方はご覧になったかと思いますが、ここで作られるのはSKILL.mdを中心としたデザインシステムのガイドライン群です。そういった意味では、デザインシステムを作ること自体も簡単になりました。ですが、それが本当にいいデザインシステムなのか？に確信を持てる人はなかなかいないのではないでしょうか。
そこでSparkle Designです。Sparkle Designはその思想の下、一貫していいデフォルトのままカスタマイズ可能にする、ということを心がけて作ってきました。
それがsparkle.config.jsonで何をどこまで変えられるかという制約の置き方であり、コードという形で公開することの価値でもあります。Claude Codeの開発を率いるBoris Chernyさんも語っている通り、AIに仕事をさせるときは、AIが自分の出力を検証できる手段を用意しておくことが精度向上の肝。Sparkle Designにおいては、sparkle-design-cli checkで機械的に検出できるアンチパターンや、コンポーネントのコード・型定義そのものがAIにとっての検証手段として働きます。
ですので、これからSparkle Designを使っていただく方は安心してお使いください。
実際、Sparkle DesignをClaude Designに読ませて作ったデザインと、Sparkle DesignのCLIやスキルといったエコシステムを活用してClaude Codeで作ったデザインでは、後者の方が精度の高い結果が得られることを確認できています。エコシステムが検証の足場になっている分、差が出る、という感触です。
実際のアウトプットの比較。レスポンシブとして崩れているのは別要因かもしれませんが、最上位モデルを利用するClaude Designに匹敵・もしくはそれ以上の精度を一回の命令かつ下位モデルで出力できるようになります
皆さんのコントリビュートをお待ちしています
冒頭でも書いた通り、Sparkle Design for ReactはOSSとして公開されています。具体的には、以下のような関わり方ができます。
- 新しいコンポーネントの提案・実装
公開版にしているものは、コンポーネントの数を絞っている状態なので、追加実装はいつでも歓迎です。リポジトリのコンポーネント公開状況テーブルに未実装のものを並べているので、興味があるものから手を付けていただけます - アンチパターンの報告
sparkle-design-cliのcheckコマンドで検出するルール自体は、非公開リポジトリで管理していますが、「こういう誤用をよく見る」「このパターンは検出できた方がいい」という声は sparkle-design リポジトリのIssueで受け付けています。ルールに反映していきます - Issueでの議論
実装まで踏み込まなくても、使ってみての違和感や要望をIssueで投げていただけると、それだけでうれしいです
簡単ではありますが、Sparkle Design for Reactとそれに関連するリリースの制作で意識したことをお話しいたしました。
今回OSSという形態にしたことから、お気付きの方もいるかと思いますが、これは完全体ではありません。皆さんに使っていただき、フィードバックやコントリビュートをもらうことでさらに進化を続けていくものになります。
ぜひ、皆さんのコントリビュートをお待ちしています！
