デザインシステムは要らない

おそらくあなたにデザインシステムは要りません。必要なのは、いくつかのデザイントークンと、小さなコンポーネントライブラリと、センスのある人がチームに一人いることです。お気に入りのデザイン系Twitterアカウントが延々と投稿している、公開コンポーネント400個、テーマ12個のFigmaファイル。あれはフルタイムのプロダクトであり、8人のスタートアップは代金を払うだけで回収できていません。

これは業界の誰もが真実だと知っていて、誰も口に出さない意見です。保守コストは現実です。見返りはほぼ想像上のものです。そこにAI生成が、その差をさらに広げました。

デザインシステムを出荷しているチームの95%は、成熟度ごっこをしているだけです。本当に必要な5%は、たいてい「要りますか?」と質問してくるチームではありません。

デザインシステムはプロダクトであり、寄り道ではない

本物のデザインシステムには、独自のロードマップ、独自の変更履歴、独自の顧客がいます。 その顧客とは、実際のプロダクトを出荷しているエンジニアとデザイナーです。保守を担当する人員がいないなら、それはシステムではありません。スナップショットです。

デザインシステムをうまく運用している組織を見てください。Stripeには専任のデザインインフラチームがあります。Shopify Polarisには専用の組織があります。GitHub Primerはバージョンリリース付きの公開リポジトリを持っています。

Atlassianは、ほとんどのチームが規模で到底届かないシステムに何年も投資しています。どれも、数千人規模の社内顧客に向けてツールを作るプロダクトチームです。

では典型的なパターンを見ましょう。シニアデザイナーがFigmaに6週間かけ、80個のコンポーネントを公開し、エンジニアの誰も読まないNotionページを書き、テーマを2つ出荷しました。半年後、コンポーネントの半分は古くなり、トークンはコードベースからずれ、チームはTailwindのクラスをコピペする生活に戻っています。システムが失敗したのではありません。チームがそれを維持する人員を割けなかったのです。

スライドに載らない保守コスト

見返りの売り文句はこうです。一度作れば、永遠に再利用できる。実際の計算はこうです。一度作り、永遠に保守し、たまに一部を再利用する。

存在するすべてのデザイントークンは、Figmaとコードの間で同期し続ける必要があります。すべてのコンポーネントバリアントは、フレームワークのアップグレード時にテストが必要です。RadixやReactやTailwindの破壊的変更は、依存するすべてのプロダクトに波及します。ドキュメントは四半期で腐ります。

Storybookは依存関係の更新で壊れ、3週間誰も気づきません。公開済みのFigmaライブラリはコードベースより1リリース遅れます。テーマは乖離します。システム内のコンポーネントは、プロダクト内のコンポーネントとは別物になります。

正直に計算するとこうです。6コンポーネントの「システム」なら、本当に時間を節約できます。社員12人の会社にある200コンポーネントのシステムは、ただの税金です。見返りの時間は線形ですが、保守の時間は複利で膨らみ、どこかで線が交差します。多くのチームは気づかないまま交差させます。保守は損益計算書の項目ではなく、金曜午後のSlackメッセージとして現れるからです。

AI生成が計算を崩壊させた

デザインシステムの根拠はすべて、ひとつの数字に支えられていました。見た目の整った新しいコンポーネントを作るコストです。その数字は今や誤差の範囲です。

ジュニアエンジニアが「サイドバーと3つのセクション、それにローディング状態のパターンに従う保存バーがついた設定ページを作って」と打てば、20分で動くコンポーネントを出荷できます。v0はデフォルトでShadcn形式の出力を生成します。CursorとClaudeは、既存のプリミティブに合わせてフロー全体をリファクタリングできます。デザインシステムがかつて提供していた見返り、つまり一貫した見た目のUIを素早く生成することは、今やあらゆるIDEが無料で提供するサービスです。

システムの税は変わっていません。見返りが暴落したのです。話はそれだけです。2022年に出力を速くするためにデザインシステムを作ったチームは、今ではShadcn+Tailwind+プロンプトで出荷するチームより遅くなっています。あらゆるAIツールが後者で学習されていて、前者を無視するからです。

デザインシステムが本当に必要な5%

本物のデザインシステムが元を取れるのは、特定の条件がすべて揃ったときだけです。ひとつでも欠ければ計算は崩れます。

1. 複数のプロダクトがひとつのアイデンティティを共有している。 AtlassianにはJira、Confluence、Trello、ほかにも多数あります。アイデンティティはひとつ、接点は多数。システムが統一レイヤーになります。
2. 人員が数十人ではなく数百人規模。 プロダクトエンジニアが50人未満なら、どのコンポーネントもSlackメッセージ一通で直せます。200人を超えるとそれは通用せず、システムが唯一の道になります。
3. 専任のデザインオプスまたはデザインインフラチームがいる。 オーナーのいないデザインシステムは墓場です。オーナーは正式な役割であって、20%ルールの片手間プロジェクトではありません。
4. 外部の利用者がいる。 GitHub PrimerやShopify Polarisのようなオープンソースのデザインシステムは、開発者向けプロダクトでもあります。保守コストは外部での採用によって正当化されます。
5. 規制の厳しい、またはアクセシビリティ要求の高い領域。 医療、金融、行政。システムがコンプライアンスと監査対応力を符号化します。これは個々のチームには再現できない見返りです。

5つすべてに当てはまるなら、デザインシステムは正しい選択です。1つか2つしか当てはまらず、エンジニア40人で1つのプロダクトを出荷しているなら、デザインシステムはコスプレです。アンチダッシュボードの記事は、まだ到達していない組織規模のためにインフラを作るという、関連するパターンを扱っています。

最小限の実用ビジュアルシステム

95%のチームにとっての答えは、保守コストがほぼゼロで、成果物はほぼ同等になる3層のスタックです。

スタックはこれがすべてです。トークンが一貫性をもたらします。プリミティブがアクセシビリティと挙動をもたらします。センスは、どんなシステムにも符号化できないレイヤー、つまりルールをいつ曲げるべきかという判断をもたらします。

2026年に最もすっきりしたプロダクトを出しているチームは、これの変形を使っています。Linearは小さなトークンセットと自作のプリミティブ、そして執念深いセンスで動いています。Vercelは分厚いTailwind configと自社のプリミティブを出荷しています。

Cal.comはプリミティブを公開しています。ResendとLoopsは、独自トークンを載せたShadcn形式のUIを出荷しています。

Notionは少数のトークンと、意図的に絞ったコンポーネントの語彙で動いています。どこもAtlassian的な意味での「デザインシステム」は持っていません。それでもすべてが、10倍の規模の会社より一貫して見えるマーケティングサイトのスタックを持っています。

なぜShadcnがデザインシステム市場を食っているのか

Shadcnはコンポーネントライブラリではありません。新しいデフォルトの配信メカニズムです。プリミティブはコードベースに取り込まれ、Tailwindでスタイルされ、内部ではRadixが重い仕事を担うのでアクセシブルです。ユーザーはコンポーネントを所有し、自由に編集でき、上流のリリースに足止めされることがありません。

これが、ほとんどの社内デザインシステムにとっての致命傷です。かつてチームが自作した理由はコントロールでした。Shadcnはそのコントロールをタダで与えます。かつてStorybookを出荷した理由は発見しやすさでした。

Shadcnはドキュメントを公開していて、AIツールがそれをインデックスします。かつてFigmaライブラリを公開した理由は一貫性でした。Shadcnのプリミティブは十分に一貫しているので、それに対するどんなプロンプトも、チームがすでに評価方法を知っている出力を生みます。

Shadcn+Tailwind+トークンセットが、2026年のデフォルトのビジュアルスタックです。現代のAIコード生成ツールがデフォルトで出力するのもこれです。新しいプロダクトチームがまず出荷するのもこれです。プリミティブ+センスのモデルが、2つのリポジトリと1つの設定ファイルに収まっています。独自の公開パイプラインと独自のチームを持つ、独立した成果物としてのデザインシステムは、今や特殊なケースです。

本物のシステムがついに元を取るとき

「デザインシステムは必要か?」という問いの正直な言い換えは、「もう保守の閾値を越えたか?」です。

これらのシグナルのうち3つ以上に当てはまるなら、本物のシステムは正当化されます。1つなら、トークンファイルで十分です。価格ページ問題やオンボーディングなきオンボーディングも同じ論理で、調整の問題をシステムのレベルではなく表層のレベルで解いています。

パターン、そしてオチ

成熟度の見せびらかしは上下が逆です。2026年に最も一貫したプロダクトを出しているチームは、最大のデザインシステムを持つチームではありません。最小のビジュアル負債を持つチームです。引き締まったトークンセット、薄いプリミティブ層、そして頻繁に「ノー」と言えるセンスのあるデザイナー。

本物のデザインシステムは、代替手段では収まらなくなった組織のためのインフラです。すべてのチームが到達すべきマイルストーンではありません。ステータスシンボルでもありません。「もっとプロっぽく見せたい」への答えでもありません。

保守の予算を稼ぐ前にデザインシステムを作るチームは、同じプロダクトを、遅い時計と重いファイルで出荷することになります。トークン+Shadcn+センスで出荷するチームは、同じプロダクトを速い時計で出荷し、浮いた時間を使って代わりに設定ページ問題を直します。

問いは「デザインシステムはあるか?」ではありません。「適切な抽象度のレベルで保守コストを払っているか?」です。

FAQ

デザインシステムとコンポーネントライブラリの違いは?

コンポーネントライブラリは、再利用可能なUIパーツの集合です。デザインシステムは、コンポーネントライブラリにトークン、ドキュメント、ガバナンス、オーナー、リリースの周期を足したものです。多くのチームはコンポーネントライブラリを出荷して、それをシステムと呼んでいます。両者は同じではなく、後者には前者にない保守コストがかかります。

Shadcnはデザインシステムですか?

いいえ。Shadcnはプリミティブの配信メカニズムです。コンポーネントはコードベースに取り込まれ、チームが所有します。中央のライブラリも、上流のリリーススケジュールも、ガバナンスもありません。

それが肝です。保守コストを払わずに、システムの見返りだけをチームに与えてくれます。

スタートアップはいつデザインシステムに投資すべき?

次のうち少なくとも3つが当てはまるときです。アイデンティティを共有する複数のプロダクト、UIを出荷する50人以上のエンジニア、専任のデザインオプス担当、コンポーネントの外部利用者、規制のある領域。その基準に届かないうちは、トークン+プリミティブ+センスで出荷し、浮いた時間を実際のプロダクトに注ぎましょう。

CTA

チームの規模に見合ったビジュアルシステムを持つプロダクトが欲しいですか? Brainyは、95%向けにはトークン+プリミティブのスタックを、5%向けには本格的なデザインシステムを、実際の保守予算に合わせて出荷します。Brainyに依頼する。間違った成果物に四半期を費やす前に、あなたがどちら側にいるのかをお伝えします。