AIにお願いすれば画面はすぐに出来上がる。ここ1年で、プロダクト開発のスピードは一気に変わりました。一方で、出てきた画面を見ながら、こんなふうに思ったことはないでしょうか。

• 「悪くはないけど、なんか違う」と思いつつ、そのまま採用してしまった
• 手で1画面ずつ作っていたころの方が、プロダクトの「らしさ」が出ていた気がする

早くはなったけれど、デザインの癖や特徴が薄まっている。AIによるプロダクト開発に、私自身そんなモヤモヤを感じていました。このモヤモヤの正体は、AIが参照できる「このプロダクトらしさ」が、どこにも置かれていないことだったと思っています。

私が担当しているプロダクトのデザインシステムは、デザイナー4人が議論を重ね、エンジニアとともに1ピクセル単位で調整したものです。既製のUIライブラリをそのまま使えば数日で立ち上がるところを、なんと半年。AIによる自動生成とスピードが正義とされる今の開発文化からすると、少し時代に逆行しているように見えるかもしれません。

でも、やってみて分かったのは、これがAI時代のプロダクトづくりの正攻法の1つかもしれないということです。半年かけて気付いたのは、次の2つでした。

• 思想が染み込んだシステムがあるから、AIが生成するUIにも「らしさ」が宿る
• ていねいにつくったデザインシステムが、高速な開発のための強い基盤になる

単なるコンポーネントのカタログではなく、プロダクト固有のこだわりを織り込んだデザインシステムを、どうやってつくってきたのか。半年間でやったことと、そこからの気付きをまとめました。デザインシステムに興味はあるけれど、何から始めればいいか分からない方や、既成のライブラリで運用していて違和感を覚えている方に届くとうれしいです。

デザインシステムの構成

まず、私たちがつくったものの中身を簡単に紹介します。構成自体は、オーソドックスなデザインシステムと変わりません。

【関連記事】デザインシステムとは？作り方を5ステップで解説！事例や導入メリットも＜Figma公開中＞

1.トークンライブラリ

カラー、シャドウ、タイポグラフィ、角丸といったスタイルの最小単位を定義したもの。

2. コンポーネントライブラリ

コンポーネントのページは、次の3つの情報を1セットにしています。

1. コンポーネントデータ — 実際に使えるFigmaのパーツ
   
   
2. コンポーネントのプロフィール情報 — このコンポーネントはどんな性質を持つのか
   
   
3. 使用ルール — どんなときに使うのか、正しい／誤った使い方
   

これら3つの情報を1単位として、現在は50コンポーネントほどが登録されています。

3. 横断ガイドライン

「モーダルビューの使い分け方」「通知方法の選び方」など、複数のコンポーネントにまたがるルールは、横断的なガイドラインとして整備しています。

上記のように、私たちのデザインシステムは、トークンやコンポーネントなど「パーツだけ置いてある」状態ではなく、「誰が見てもどう使うのか分かる」状態まで、多角的にルールを定めて作り込みました。

最重要事項：Figmaとコードが繋がっていること

そして重要なのが、これらすべてが開発側のコードやドキュメントにも同じかたちで登録されていることです。Figmaとコードが連動している状態を作れないと、AI駆動の開発でデザインシステムを使いこなすことが難しくなります。

さらにその上で、AIがこのデザインシステムを正しく使えるようにするためのDESIGN.mdやAgent Skillsも重ねて整備しています。

【関連記事】AI時代のコンポーネントライブラリ制作──Sparkle Design for Reactで考えたこと

既製のUIライブラリと何が違うのか

デザインシステムを導入するとき、まず思い浮かぶのはshadcn/uiやMUIといったオープンソースライブラリを転用する方法です。実際、それで十分うまくいくプロダクトもたくさんあります。ただ、手作りした私たちのデザインシステムには、大きく違う点が3つありました。

1. ルールがボトムアップで決まっている

一般的なライブラリは、どんなプロダクトでも使えるよう汎用性を前提に設計されています。しかし、私たちのプロダクトには、独自のプロダクトブランディングや操作体験へのこだわりがありました。そのため、私たちは「汎用」の逆の考え方で、デザイナー4人が日々感じていた「この場面ではこう使いたい」「このパターンが何度も出てくる」という実態から積み上げてルールを作っていくやり方をとりました。

具体的なプロセスはこうです。

1. まずルールに縛られず、画面に対して局所最適でコンポーネントをデザインする
2. できたものを既存ルールと照らし合わせる

• 近いものがあれば統合を試みる
• 既存ルールでカバーできなければ、新しいルールとして定義する

ここで大事にしているのが、無理に既存ルールへ統合することでデザインの良さが損なわれるなら、新しくルールを立てるという判断です。

例えば、局所最適でデザインした画面には、Side SheetとSide Panelという似たようなコンポーネントが存在していました。どちらも画面の横から現れるもので、役割は近いけれど、挙動と使う場面が微妙に違います。

どちらか1つに統合することもできますが、そうすると画面のレイアウトが単調になり、ユーザーが機能の違いを学習しづらくなってしまいます。

そこで初めて、「2つとも残しつつ、使い方がカオスにならないようルールを整備しよう」とチームで判断しました。結果として、この2つだけでなくモーダルビュー全般をどう使い分けるかのフローチャートを整備しました。

局所最適 → 全体最適、という順番で丁寧に議論を重ねることで、「いいデザインを妥協しない」けれど「カオスは許容しない」というバランスをとっています。ルールのために良いデザインを諦めるのは、私たちのやり方ではないからです。

2. やらないことを決めている

デザインシステムをつくっていると自然と「こう使う」のルールが増えてきますが、私たちがより力を入れたのは「これはやらない」の定義です。

関わる人が増えれば、どうしても解釈はバラけます。いろいろな使い方を許容する設計にしてしまうと、気付いたときには体験の一貫性がなくなったり、ブランドがぼんやりしていた、ということが起きます。最初から「このプロダクトではこれをしない」と明確に決めておくことで、誰が作っても思想がぶれない状態を目指しました。

3. こだわりの部分は、あえて一般解から外れる

世間で通用している一般解は強力ですが、それだけではプロダクトの「らしさ」は出ません。どこを一般解とし、どこに独自のルールを作るか。その線引きこそがデザインシステム設計の要だと思います。

分かりやすい例が、カラーパレットです。私たちのパレットには、グレーとグリーン系の色がかなり多く並んでいます。一般的なデザインシステムの基準で見れば「複雑すぎる」と言われる数。

ただ、プロダクトのコンセプトを体現するには、微妙なトーンの差がどうしても必要でした。そこで、ニュアンス表現のために色を使い分ける必要のある箇所では、通常のグレーである「Neutral」に加えて、わずかに色味を足した「Tint」というカラーグループを別に用意し、少し緑を足したいといった微妙な調整に耐えられるようにしました。

大事なのは、こだわりを持ちながらもカオスに見せないこと。もっと言えば、デザイナーが変わってもそのこだわりを踏襲できることが理想だと思っています。

開発環境がどう変わったか

こうして、ていねいにデザインシステムを育ててきたことで、開発環境は半年前から大きく変わりました。

	Before（半年前）	After（今）
Figma	デザイナー4人がそれぞれ突貫で用意したコンポーネントでなんとか運用	コンポーネントごとにページが整理され、ルールも併記された状態に
実装	エンジニアごとに個別の方法で実装	Figmaとコードが一致し、全員が同じソースを参照
プロダクト	見た目や挙動がバラバラ	同じコンポーネントはすべてスタイルと挙動が揃っている
AI生成	—	バイブコーディングでもある程度「らしい」UIが出てくる
デザインQA	デザインと実装の齟齬の洗い出しに多大な時間を消費	共通パーツはもともと揃っているので、フィードバック不要
デザイン初稿	デザイナーが1から手動で作成	AIである程度のたたき台をつくれるように

特に実感が大きいのは、デザインQAの負荷が減ったことです。以前は「ここのpaddingが違う」「この角丸が違う」を毎回指摘していましたが、今はその指摘自体が発生しません。

また、開発チームのエンジニアに、実際に感じる効果を聞いてみたところ、以下のような意見をもらいました。

AIにUIを書かせるときの迷いがなくなりました。以前は同じ「ボタン」でも出どころが複数あり、統一性がありませんでした。今はトークンが1カ所にまとまり、外れた指定は自動で弾かれるので、見た目ではなく「この画面で何をしたいか」だけを見ればよくなりました。

一番変わったのは、AIに生成させたUIがそのまま使えるようになったことです。以前は出てきたものを結局手で直していたのですが、今は参照先が明確なぶん最初から妥当なUIが出てきます。既製のライブラリをそのまま使っている環境だと、「それっぽいけど自分たちのものではない」で止まりがちな気がします。

デザインシステム開発までの8ステップ

ここからは、半年間実際に何をやってきたのか、進め方を詳しく紹介します。地味な話が続きますが、これから始める方にはこの部分が最も参考になるかもしれません。

Step.1｜まずは「なぜ必要か」の説明から始めた

デザインシステムは、エンジニアやデザイナー以外からは効果が見えにくく、すぐに事業成果につながるタスクではありません。POやクライアントから「デザインシステムをつくってください」と言われることはなかなかなく、むしろ存在自体を知られていないことも多いです。

そのため、まずは「AI駆動の開発にデザインシステムが不可欠である」ことや「今やらないと後でしんどくなる」といったやる意義を地道に伝えました。

Step.2｜全コンポーネントを並べて優先度をつけた

次にやったのは、全コンポーネントの洗い出しです。スプレッドシートに一覧化し、「実装頻度が高いか」「今の課題が大きいか」の2軸で優先度をつけました。

Step.3｜ルールやデザインは4人で徹底的に議論

一覧表をもとに、トークンの設計から始め、コンポーネントごとにバリアントと使用ルールを整備していきました。整備できたものは必ず他のデザイナー3人にチェックしてもらい、それぞれ自分が使う場面を想定しながら、見える課題がなくなるまで議論しました。

この、4人で議論を尽くす工程はいちばん時間がかかりましたが、その反面、最も重要だったと思います。他のメンバーが運用できない形骸化したルールにしては意味がありませんし、この場で交わされた議論の結果が、そのまま説得力のあるガイドラインとなるからです。

Step.4｜エンジニアと二人三脚でコードにつなげた

デザインシステムは、Figmaとコードが一致してはじめて意味をなします。そのため、デザイナーとエンジニアとの連携が非常に重要です。

お互いに本業を抱えながらのサイドタスクになるので、ゆるいスプリントで中期スケジュールを引き、無理なく進めました。実装の制約とデザインのこだわりをすり合わせながら、少しずつ精度を上げていきました。

Step.5｜1ピクセルのずれも妥協しない実装修正

実装できたコードを確認し、デザインと1ピクセルでもずれていたら修正依頼を出す作業を繰り返しました。「細かすぎる」と思われることもあるかもしれませんが、「らしさ」は細部の積み重ねだと思っているので、ここは妥協しませんでした。

Step.6｜モーションの実装は集中作業で

コンポーネントの形ができてから、モーションも丁寧に整備していきました。モーションは、プロトタイプを渡すだけではなかなか意図が正確に伝わりません。そこで事前にプロトタイプを共有した上で、エンジニアと出社してがっつり作業時間をとりました。

普段はリモートが中心ですが、このタスクだけ出社にこだわったのは正解でした。認識のズレが最小化され、完成度が大きく変わりました。

Step.7｜大規模なリファクタリング

デザインシステムが形になり、新規実装はきれいにつくれるようになりましたが、それ以前につくった既存画面には旧コードが残っています。ここもPMに説明し、一定期間を「リファクタリング期間」として確保。エンジニア約10名にコンポーネント単位で請け負ってもらい、プロダクト内が全て正しいコンポーネントとなるよう一気に差し替えました。

Step.8｜そして今：AIを育てている

Figmaとコードが一致した状態がつくれた今、DESIGN.mdやAgent Skillsを整備して、デザインのルールをAIがより深く理解できるよう育てるフェーズに入っています。

デザインシステムはパーツができて完成ではありません。ここからAIも人も、このデザインシステムをよりよく活用できるようになることが最も重要だと思っています。

「細かすぎる」ほどていねいにつくると、何が変わるのか

半年かけて分かった変化は、大きく以下の3つです。

1. プロダクトへの影響：作り直しが減る

既製ライブラリの転用から始めると、どこかで必ず使いづらさが出てきて、都度の調整が必要になります。

一方、私たちは最初から「自分たちにとってのベスト」をデザインシステムにしているので、途中でコンポーネントやルールをつくり直すことが非常に少ないです。遠回りに見えて、実は手戻りが少ない道だったと感じています。

2. プロダクトへの影響：細部から「らしさ」が滲み出る

このデザインシステムは、どこかがつくったルールをデフォルトにしたものではありません。1年間開発してきたプロダクトから「局所最適ないいデザイン」を集め、それを「全体最適のルール」へ汎用化する形でつくりました。

そのため、自然とチーム全員が一番良いと思っている思想が詰まっています。そのルールが基盤となり、UIの見た目だけでなく、ライティング・ふるまい・モーションといった細部にまで「らしさ」を吹き込んでいます。

3. チームへの影響：AIだけでなく人間同士の意思疎通も促す

デザインシステムがあることで、日々のデザインで積み重ねた議論を、ルールとして記録し蓄積できるようになります。これにより、新しく入ったデザイナーやエンジニアにも、これまでの意図や思想を伝えやすくなります。

AIでの開発が当たり前となった今でも、デザインシステムは「チームの意思決定のログ」となり、人間同士のコミュニケーションツールとして役立つと考えています。

4. AIへの影響：AIの出力にも「らしさ」が宿るように

私たちは、パーツのコードだけでなく、自分たちが守っているルールもDESIGN.mdやAgent Skillsといったドキュメントにして、リポジトリに格納しています。これによって、バイブコーディングでもある程度「このプロダクトらしい画面」が出てくるようになりました。

AIが参照する先が曖昧だと、出てくるものも特徴のないUIになります。デザインシステムによって思想が言語化されて置かれていることで、AIが文脈に合わせつつも「このプロダクトらしさ」を宿したアウトプットをしてくれるようになりました。これが冒頭に書いた「AI時代の正攻法の1つかもしれない」と感じる理由です。

【関連記事】組織にデザインシステムが必要な理由とは──その効果や価値を徹底解説

AIが作ったものにも「らしさ」が生まれる

デザインシステムを育てるのは地道な作業です。効果はすぐに見えず、説得も必要で、本業と並行しながら進めなければいけません。ですが、できあがったものは長く残る資産となり、開発チーム全体の速度と作りやすさに確実に寄与します。

そして今は、AIがこのデザインシステムを使って一発でよいデザインを作れるよう、環境整備に力を入れています。デザイナーの頭の中には、ユーザーの特性、プロダクトのポジショニングといった膨大な背景情報と、そこから導かれたプロダクトの設計思想があります。それらを本気でデザインシステムに落とし込んでいくことで、AIが作るものにもしっかりとした意図と、そこから生まれる「らしさ」が宿るようになると考えています。

今後も「静的なドキュメント」ではなく「チームの思想が宿るもの」として、私たちのデザインシステムはまだまだ進化していきます。