デザインシステムの本当のコスト、そして多くが静かに朽ちていく理由

この日本語版は AI による下書きで、ネイティブのレビュー前です。内容は英語版が正です。

デザインシステムは一度買えば終わる資産ではありません。運用し続けるか、少しずつ失っていくかのどちらかのサービスです。

リターンは本物だが、スライドで語られるほど大きくはない

デザインシステムのビジネスケースは、たいてい二つの研究に基づいています。どちらも誠実な研究で、どちらも引用されるときより小さな研究です。

Figma の研究では、最新のデザインシステムがあるとき、デザイナーはタスクを 34% 短い時間で終えました（Figma, 2019）。何人のデザイナーが参加したかは公表されていません。著者は慎重で、テストで使われたシステムが最新でタスクに合っていたため、これは実際の業務で見込める最大値だろうと述べています。

Sparkbox の研究では、8 人の開発者が一つのお問い合わせフォームを、IBM の Carbon デザインシステムを使って中央値 2 時間で作りました。ゼロから作った場合は 4.2 時間でした（Sparkbox）。著者自身が「少数の優秀な開発者による小さな研究」と呼んでいます。フォームは必ずゼロからの版を先に作り、ゼロから作った版のうち二つは、Carbon の版よりアクセシビリティが高い結果でした。

私が知る中で最も透明性の高いモデルは、Maximilian Speicher と Guido Baena Wehrmann によるものです。計算式を公開し、前提を並べ、どんな結果にもおよそ ±25% の幅をつけて報告するよう勧めています（Smashing Magazine, 2022）。その時間短縮の値は、上の二つのような研究の平均です。良いモデルです。それでも、モデルです。

組織全体で、長期にわたってデザインシステムのリターンを測った独立した研究を探しましたが、見つかりませんでした。これが ROI の議論の正直な限界です。そして、最良の根拠の中に隠れた条件に注目してください。システムが最新であることです。ドリフトしたシステムは、これらの研究が測った時間を返してくれません。

ドリフトとは、同じ作業を二度行うこと

三つのアプリと一つのデザインシステムを持つプロダクト企業を想像してください。3 月、あるデザイナーがリリース日に間に合わせるため、カードコンポーネントのインスタンスを切り離します。4 月、別のチームのエンジニアが新しいダイアログを作ります。システムのダイアログはフッターに対応しておらず、依頼に期限内の返事がなかったからです。5 月、AI コーディングエージェントがそのダイアログを三つ目のアプリにコピーします。それが一番近い例だったからです。どの選択も、それぞれには筋が通っていました。誰もシステムから離れると決めたわけではありません。夏には、ダイアログが三つ、カードが二つあり、Figma ライブラリはそのどれも表していません。

これがドリフトで、実務者ははっきりと報告しています。メンテナーは、技術的または表現上の負債（43%）と、デザインとコードの一致（37%）を最大の課題に挙げています（Sparkbox Design Systems Survey 2022）。AI はそれを加速させます。実務者の 59% がデザインシステムを迂回したインターフェースを報告し、半数がすでに実際の問題を起こしていると答え、組織の 44% がそれを容認しています（zeroheight, State of AI in Design Systems 2026、回答者 123 人）。

ドリフトのコストは、重複そのものではありません。その後に続くすべてです。アクセシビリティの問題が見つかれば二つのコンポーネントを直し、どちらを使うべきかと聞かれれば二つの答えがあり、そのたびにシステムへの信頼が少し下がります。

陳腐化とは、システムがプロダクトに追いつけなくなること

プロダクトは毎週変わります。四半期ごとにしか変わらないシステムは遅れ、チームは待つのをやめます。これが陳腐化です。システムはまだ存在しますが、プロダクトの実際の作り方を表さなくなっています。

採用率の数字がそれを示しています。zeroheight の 2025 年の調査では、システムの 40% が広く採用され、10% が完全に採用されていました。つまり半数はそうではありません（zeroheight Design Systems Report 2025）。研究インタビューでは、デザインシステムのリーダー 9 人のうち 6 人が、プロダクトとともにシステムを進化させ続けることは難しいと答えました。ある人は、その課題を「維持すること、数年たってもまだ意味があるようにすること」と表現しています（Lamine and Cheng, 2022）。

陳腐化には独自の請求書があります。プロダクトが取り込めないリリースは、誰かが先送りするアップグレードになります。先送りされたアップグレードは、次のアップグレードをさらに高くつかせます。

保守の負荷は、ごく少数の人にかかる

システムを最新に保つ仕事は、小さなチームにかかります。zeroheight の 2026 年の調査では、デザインシステムチームの 5 つに 3 つが、目標を達成するのに十分な人数がいませんでした（zeroheight Design Systems Report 2026、回答者 147 人）。平均的なチームの人数は、従業員 100 人未満の企業で 3 人、100 人から 499 人で 4 人、500 人以上で 9 人でした（zeroheight Design Systems Report 2025）。

4 人のチームでは、すべての依頼に答え、すべてのプルリクエストをレビューし、すべての Figma の変更を確認し、エージェントが書くすべての行を読むことはできません。そこで優先順位をつけ、目立たない仕事から削られていきます。zeroheight の 2025 年のレポートはその結果を、アクセシビリティやドキュメントのような重要な要素が「朽ちるまま放置される」と表現しています。

ドリフト、陳腐化、過負荷のチームは、三つの問題ではありません。一つの問題を三つの側から見たものです。

ツールは問題を数え、運用が問題を直す

デザインチームはすでに良いツールを持っています。Figma は切り離されたインスタンスを示します。ドキュメントのプラットフォームはシステムをよく説明します。リンターは生の値を見つけます。これらのツールをとても上手に使っているチームもあり、続けるべきです。

しかしツールは、誰がルールを持つのか、誰が変更をレビューするのか、例外がどれだけ続いてよいのか、期限と基準がぶつかったときに何が起きるのかを決めません。合意された進め方のないまま 5 人のデザイナーが一つのライブラリを共有すると、それぞれが筋の通った選択をし、システムはばらばらになります。それは人の失敗ではありません。構造が欠けているのです。

だからこそ私は運用を主張します。名前のあるオーナー、サービスレベルのある一つのレビューキュー、期限の切れる例外、データから準備される定例、そしてシステムの健全性を時間とともに見る方法です。運用は、ドリフトを「チームに起きること」から「チームが管理すること」に変えます。

Loom はそれぞれのコストにどう取り組むか

私たちは、この仕事をデザインチームと一緒に、チーム自身のリポジトリの中で進めるために Loom を作りました。

ドリフトに対しては、監査がリポジトリを読み、生の値や作り直されたコンポーネントを含む 8 つの領域を根拠つきで採点します（監査の仕組み）。エージェントは引き渡しの前に自分の作業をシステムと照らし合わせるため、システム外のインターフェースは書かれたその場で見つかります（エージェントと MCP）。例外は認められますが、それぞれ最長 90 日で、期限が来るとオーナーに戻ります（ガバナンス）。

陳腐化に対しては、破壊的な変更はコントラクトの差分で判断され、非推奨には代替と日付がつき、監査が残っている使用箇所をすべて報告します。人やエージェントがシステムの中に見つけられなかったニーズは依頼数とともに記録されるので、オーナーはシステムに何が足りないかを見ることができます。

保守の負荷に対しては、すべての依頼が一つのレビューキューで、オーナー、期日、営業日で数えるサービスレベルとともに待ちます（運用）。エージェントは MCP サーバーと AGENTS.md パックを通じてルールを受け取るので、日常的な質問にはチームではなくシステムが答えます。

新しいものもあり、どれだけ新しいかをはっきり述べておきます。健全性の推移、繰り返されるニーズを下書きに変えるレーダー、コードモッドと移行のプルリクエストは、私たちのサンプルシステムでは動いていますが、まだクライアントのリポジトリでは動かしていません。システムが変わったときに人々を最新に保つ Academy は、これから提供するものです。Loom はまた、削減効果の数字を引用しません。自社で測定したクライアントの仕事からのみ数字を示し、それはまだありません。その代わりに提供するのが計算ツールです。自分の数字を入れ、計算式を見て、約束ではなく幅を得ることができます。