
アーム代表の伊藤です。
デザインシステム構築は一式で150万円〜かかります(アームの場合・2026年9月時点・税別)。この費用が無駄になるかどうかは作り方ではなく、作ったあと誰が維持するかが決まっているかで決まります。
維持の担い手がいないまま作ると、1年から2年で元の状態に戻り、費用は償却されずに消えます。この記事は、最初の表で6つの壊れ方と自社の位置を確かめ、作り直さずに立て直す手順まで最短でたどる構成にしています。
デザインシステムが壊れる原因は運用設計。直すのは正の宣言から
- 壊れ方は6段階で上から順に連鎖
- 6番目に到達するとデータは負債に変わる
- 最初の一手は正の宣言で作業はゼロ
デザインシステムが使われなくなる原因は運用の設計にあります。壊れ方は次の6段階で、上から順に連鎖します。まず自社がいまどこにいるかを確かめてください。
段階 | 起きていること | 直接のコスト |
|---|---|---|
1 | コンポーネントになっていない | 変更が画面数に比例する |
2 | スタイル名が意味を持っていない | 次の人が選べず、直接指定に戻る |
3 | 画像が部品化されていない | 比率とサイズの一括変更ができない |
4 | バリアブルの代わりに複製している | 変更のたびに複製の数だけ作業が増える |
5 | 担当者が代わり、正が分からなくなる | 判断の履歴が消え、誰も触れなくなる |
6 | 本番を正として後追いを始める | データが資産から負債に変わる |
最後の6番目、本番環境を正としてデザインデータを後追いで直す状態に到達すると、デザインデータは資産ではなく負債に変わります。
壊れていた場合の立て直しは棚卸しからです。最初の一手は正はどこかを1つ宣言すること。作業はゼロで、それだけで6番目の壊れ方は止まります。手順の全体は「最小の4手」の章に整理しています。
この記事の金額について
本記事の金額はアームの場合の税別価格で、2026年9月時点のものです。デザインシステム構築は部分整備が50万円〜、一式が150万円〜。現状の棚卸しだけならUIクイック診断・改善提案が無料です。
払った150万円が、1〜2年で消えていく瞬間
- 棚卸しはUIクイック診断で無料・最短1週間
- 維持担い手なしだと150万円は1〜2年で消える
- 効果は売上でなく販管費に表れる
アームの場合、デザインシステム構築は部分整備が50万円〜、一式が150万円〜です(2026年9月時点・税別)。現状の棚卸しだけを先にやりたい場合は、UIクイック診断・改善提案が無料で、最短1週間です。金額の考え方は費用と相場の考え方にまとめています。
回収の見方は、作った金額ではありません。維持の工数が誰の見積もりに入っているかです。
初期費用150万円をかけても、維持の担い手が決まっていなければ、1年から2年で6番目の状態に戻ります。そのとき150万円は償却されずに消えます。逆に50万円の部分整備でも、維持の担い手と判断のルールが決まっていれば、新しい画面が増えるたびに元が取れ続けます。
投資が表れるのは、売上ではなく販管費だった
デザインシステム構築への投資が事業のどこに表れるかも整理しておきます。表れるのは販管費です。画面追加のたびに発生していた確認と手戻りの時間、新しい人が立ち上がるまでの時間、実装との差分を埋める時間。
これらは毎月かかっている固定費なので、削れると効果が続きます。3年分の運用工数と比べてください。1回の制作費との比較では足りません。
直すか作り直すかを、画面・業務・データ・運用の4つの層で決める基準は、こちらで整理しています。
自社のデザインシステムの壊れ具合を、ファイルを開かず判定する4つの質問
- 質問は4つ、1つでも詰まれば兆候あり
- 2番に即答できなければ5番まで進行
- 本番に合わせ直した経験は6番到達
自社がいまどこにいるかは、4つの質問で判定できます。ファイルを開く必要はありません。
- 色を1つ変えるとき、何画面を触る必要がありますか
- 「いま何が最新ですか」と聞いて、即答できる人がいますか
- 登録済みのスタイルとコンポーネントのうち、実際に使われているのは何割ですか
- 新しい人が入った初日に、どこを見ればいいかを示せますか
1つでも答えに詰まるなら、6つの壊れ方のどこかがすでに始まっています。2番に即答できないなら、5番まで進んでいます。デザインデータを本番に合わせて直した経験があるなら、6番に到達しています。
ここからは、6つの壊れ方の中身と、立て直しの手順です。
デザインシステムが失敗するのは、作り方ではなく運用の設計
- 構成は原則・スタイルガイド・部品ライブラリの3つ
- 見積もりに「使われ続ける」工数は入らない
- 善意は担当者が代わるまでしか続かない
失敗したデザインシステムを見にいくと、たいてい中身は悪くありません。ボタンも色もきちんと登録されています。壊れているのは部品ではなく、部品を使い続ける仕組みのほうです。
デザインシステム構築とは。成否を分けるのは構成要素の数ではない
デザインシステム構築とは、UIの部品・値・命名のルールを1か所にまとめ、誰が作っても同じ品質の画面になる状態をつくる仕事を指します。デザイン原則、スタイルガイド、コンポーネントライブラリの3つで構成されるのが一般的な説明です。
ただし実務で成否を分けるのは、作ったあとに誰がそれを維持するかが決まっているかどうかです。
見積もりに入っていない「使われ続ける」ための工数
デザインシステム構築の見積もりには、作る工数が入っています。入っていないのは、使われ続けるための工数です。新しい画面が増えたときに部品へ還元する時間、命名を判断する時間、例外を記録する時間。これらは誰の見積もりにも入っていないまま、暗黙に誰かの善意で埋められます。
その善意が続くのは、だいたい担当者が代わるまでです。この記事は、デザインシステムを小さく作り始めたあとに起きることを扱います。
デザインシステム構築のあと、現場で実際に起きる6つの壊れ方
- 色変更が100画面中40画面なら年8時間
- スタイル名color1は使用率を見えなくする
- 複製は未来の自分あての請求書になる
ここからは、実際の現場で繰り返し見てきた壊れ方を6つに分けて並べます。特定の案件が分からないよう、複数の現場で共通して見た形にまとめています。
読んでいただきたいのは、6つが独立した問題ではないという点です。上から順に連鎖していて、最後の6番目に到達した時点で、そのデザインシステムは設計図ではなくなります。
見た目は整っているのに、部品になっていない
最も多いのがこれです。見た目は整っていて、色もフォントも揃っている。ただしボタンもカードもヘッダーも、すべてがただの図形の集合として置かれています。
見る場所 | 状態 | そこで起きること |
|---|---|---|
見た目 | 整っている | 色もフォントも揃っていて、一見問題がない |
構造 | 部品になっていない | すべてが図形の集合で、変更コストが画面数に比例する |
症状は1つで、変更コストが画面数に比例します。色を1つ変える作業を考えてください。部品になっていれば1箇所です。なっていなければ、その色を使っている画面の数だけ手で直します。
単純計算ですが、こうなります。
色を1つ変える | 40画面×3分=2時間 |
|---|---|
年4回あれば | 8時間 |
- 総100画面のうち、その色を使っているのは40画面。1画面3分の修正で計2時間かかる計算。
金額よりも重いのは、その8時間が「今回は直さない」という判断を生むことです。乖離はここから始まります。
色の名前が「color1」のまま止まっている
登録はされている。ただし名前が color1、color2、color3 のまま、一度もリネームされていない。これも頻繁に見ます。
項目 | 内容 | 補足 |
|---|---|---|
登録 | 済んでいる | 登録自体は5分で終わる作業 |
命名 | 手つかず(color1のまま) | 命名は設計。その色が何のためにあるかを決める仕事 |
見るべき指標 | 使用率 | 何個作ったかではなく、実際に何割使われているか |
登録は5分で終わりますが、命名は設計です。color1 という名前は、その色が何のために存在するかを誰も決めなかった証拠になっています。次に入った人は、どれを使えばいいか判断できません。判断できないと、スタイルを使わずに直接カラーコードを打ち込みます。
ここから、デザインシステム構築の健康度を測る軸が1つ出ます。見るべきは整備率ではなく使用率です。実際に何割が使われているかを見ます。登録数だけを報告書に書くと、この壊れ方は最後まで見えません。
比率を変えたいのに、画像だけ総当たり作業になる
画像は装飾だと思われがちなので、部品化が後回しにされます。ところが変更頻度でいえば、画像はテキストより高いことが多い領域です。
部品になっていないと、比率とサイズの一括変更ができません。カード内のサムネイルを16対9から4対3に変えたい、というよくある要望が、総当たりの作業になります。そして総当たりになる作業は、やはり実行されません。
バリアブルの代わりに複製で差分を持っている
バリアブルを作らずに、マスターコンポーネントごと複製して色違い・サイズ違いを作っている状態です。
差分の持ち方 | 判定 | 理由 |
|---|---|---|
バリアブルで持つ | 差分が値になる | Figma公式が「再利用可能な値」と説明 |
複製で持つ | 差分が実体になる | 当日は困らないが、色変更時に複製分の作業が増える |
Figmaの公式ガイドでは、バリアブルは「デザインのあらゆるプロパティやプロトタイプの動作に適用できる、再利用可能な値を保存する」ものと説明されています(出典: Figma「Guide to variables in Figma」)。差分を値として持つための仕組みです。
複製は、その差分を実体として持つやり方になります。厄介なのは、複製した当日は誰も困らないことです。動くので。困るのは3ヶ月後、ブランドカラーが変わったときで、複製の数だけ作業が増えます。複製は、未来の自分あての請求書です。
担当者が代わった瞬間、なぜ24pxかが消える
デザイン担当者は、いつか必ず代わります。業務委託なら数ヶ月単位で代わることもあります。それ自体は事故ではなく前提です。
引き継ぎの中身 | 実際 | 後任への影響 |
|---|---|---|
ファイル | 引き継がれる | データそのものは手元に残る |
判断の履歴 | 引き継がれない | なぜ余白が24pxかを知る人がいなくなり、怖くて触れなくなる |
問題は、代わるときに引き継がれるのがファイルだけで、判断の履歴が引き継がれないことです。なぜこの余白が24pxなのか、なぜこのボタンだけ角丸が違うのか。理由を知っている人がいなくなると、後任は触れなくなります。
触ると何かが壊れるかもしれないからです。そして触られないデータの隣で、本番の実装だけが進んでいきます。
設計図の役割が終わり、本番の後追いになる
最後がこれです。何が正しいか分からなくなった結果、いま公開されている本番環境を正とみなし、それに合わせてデザインデータを後から修正していく運用に変わります。
起きること | 意味 | その先 |
|---|---|---|
本番を正とみなす | デザインデータを後追いで直す運用になる | 設計図の役割が終わる |
更新が手作業になる | 本番に追いつき切れない | 記録としても不正確になる |
誰の意思決定にも使われない | 維持コストだけがかかる | 資産ではなく負債に変わる |
この時点で、デザインデータは設計図ではなくなっています。実装より後ろを歩いているものは、設計図ではなく記録です。しかも更新が手作業なので、記録としても不正確になっていきます。
ここが崩壊の完了地点です。維持コストだけがかかって、誰の意思決定にも使われない。デザインデータが負債に変わったと言えるのは、この線を越えたときです。
壊れる理由は怠慢ではない。今日最も速い選択の積み重ね
- 部品化しない方が当日は速いだけ
- 誰も怠けていない、締切には誠実だった
- 必要なのは部品を使う方が速くなる仕組み
6つを並べると、担当者の管理が甘かったように見えます。実際は逆です。
部品化しないほうが、今日は速い。複製したほうが、今日は速い。命名を考えないほうが、今日は速い。リリース日が決まっているなかで、どれも合理的な判断です。誰も怠けていません。むしろ締切に対しては誠実でした。
壊れるのは、その合理的な判断を打ち消す仕組みが置かれていないからです。だから担当者を責めても直りません。デザインシステム構築で本当に設計すべきなのは、忙しい日に部品を使うほうが速くなる状態のほうです。
同じ構造の壊れ方は、管理画面のUI改善でも起きています。
使われないデザインシステムは、作り直す前に棚卸しする
- 半年〜1年後に同じ相談が再発する
- 部品化は上位2割から始める
- 使われない部品は資産でなく在庫
壊れていると分かったとき、多くの現場が最初に検討するのは作り直しです。ただし作り直しは、たいていの場合最も筋の悪い選択になります。
作り直しても半年後に同じ相談が起きる理由
壊れたのはデータではなく運用だからです。新品のデザインシステムを、維持の担い手が決まっていない同じ組織に渡せば、同じ経路をたどって同じ場所に戻ります。半年から1年後に、同じ相談がもう一度発生するだけです。
作り直しの見積もりが出てきたら、その見積もりに維持の工数が入っているかを確認してください。入っていなければ、それは同じ失敗をもう一度買う契約になります。
立て直しは全部やらない。まず宣言、次に上位2割
全部を一度にやる必要はありません。順番があります。
手順 | やること | 作業量 |
|---|---|---|
1 | 正はどこかを1つ宣言する | 決めるだけ。作業ゼロ |
2 | 使用頻度の高い順に部品化する | 全部やらない。上位2割から |
3 | 命名を決める。色から始める | 最も差が出る。半日〜1日 |
4 | 変える予定のあるものだけ変数にする | 予定のないものは触らない |
1番目が最も重要で、最も軽い作業です。「これからはFigmaを正とします。本番と食い違ったらFigmaを直すのではなく、実装を直します」と宣言する。それだけで6番目の壊れ方は止まります。手を動かす前に、この線を引いてください。
立派に作り直さない。担い手を決めてから広げる
網羅性の高いデザインシステムは、作った瞬間が最も美しく、その後ずっと維持コストを払い続けます。いま困っている範囲から作ってください。使われない部品は資産ではなく在庫です。
そして作る前に、誰がどのタイミングで部品へ還元するかを決めます。ここが決まらないまま着手すると、6つの壊れ方のどこかに必ず入ります。決められない事情があるなら、決められる範囲までスコープを小さくするほうが安全です。
デザインシステム構築そのものの進め方と対応範囲はデザインシステム構築に整理しています。
費用の考え方全般は、UI/UXデザインの費用相場にまとめています。
AIに実装させる時代、デザインシステムの粗さがそのまま出力に出る
- MCPが読むのはバリアブル・部品・レイアウト
- AIは構造の粗さを人のように補完しない
- 整えるのは機械が読める状態にするため
デザインデータをAIに渡して実装させる流れが、ここ1年で前提を変えました。MCPは構造を読む道具であって、構造を作る道具ではありません。構造の無いファイルからは、取り込むものがありません。
MCPがコードに取り込むのは、バリアブルと部品とレイアウト
Figmaの公式ガイドでは、MCPサーバーについて「バリアブル、コンポーネント、レイアウトのデータを直接IDEに取り込む」機能だと説明されています。
あわせて「実際のコンポーネントを再利用することで出力品質が上がる」「Code Connectが生成コードの一貫性を保つ」とも書かれています(出典: Figma「Guide to the Figma MCP server」)。
読んでいただきたいのは、取り込む対象として挙げられているのが、バリアブル・コンポーネント・レイアウトだという点です。つまり、それらが無いファイルからは取り込むものがありません。
MCPは構造を読む道具であって、構造を作る道具ではないというのが、アームが実際に触ってみた範囲での実感です。
「たぶん同じ部品だろう」を、AIは読み替えてくれない
もう一段深いことも起きています。これまで、データの構造の粗さは実装者が目で補完していました。「たぶんここは同じ部品だろう」と読み替えて、きれいに実装してくれていた。AIはその補完をしません。書いてあるとおりに出します。
結果として、デザインシステム構築の品質が、そのまま実装品質になりました。これまで人の善意で見えなくなっていた負債が、いま可視化されている段階です。AIを入れれば速くなるはずなのに現場が速くならない場合、原因は、渡しているデータの構造にあることが多いです。
整えるのは見た目でなく、機械が読める状態にするため
コンポーネント、バリアブル、オートレイアウト、命名。これらは機械が読める状態にするために整えます。実装をAIに任せる前提が増えている以上、ここの精度がそのまま出力の精度になります。
プロダクトのUI全体の設計から相談したい場合は業務システムUI/UXデザインもあわせてご覧ください。
デザインシステム構築そのものの進め方と対応範囲はデザインシステム構築に整理しています。
公開デザインシステムは、見た目でなく壊れにくさで読む
- デジタル庁はv2.17.0のような版番号を公開
- SmartHRは窓口を独立ページで明文化
- Ubieは2024年1月に運用を再始動
読むべきは、「何が正で、誰がどう更新するか」を先に決めて公開しているという共通の装置です。この装置は1人のチームでも置けます。
デジタル庁・SmartHR・Ubie、壊れない仕掛けの共通点
デジタル庁やSmartHRの公開デザインシステムは、お手本としてよく紹介されます。ただ、部品の見た目を眺めるだけならカタログで終わります。読むべきは、なぜ壊れずに回り続けているのかのほうです。6つの壊れ方への対策が、公開ページの中に装置として置かれています。
事例 | 置かれている装置 | 止めている壊れ方 |
|---|---|---|
デジタル庁 | 版番号を付けてカテゴリ別に更新公開 | 5. 何が正か分からなくなる(正に版番号がある) |
SmartHR | 運用ガイドラインと窓口を明文化 | 2・5. 基準と窓口を仕組み化している |
Ubie | ドキュメントとライブラリを外部公開 | 5・6. 何が正かを、外から見える場所に置いている |
- デジタル庁: デザインデータにv2.17.0のような版番号を付け、ドキュメント・デザインデータ・コードスニペットのカテゴリ別に更新情報を公開し続けています
- SmartHR: 運用ガイドラインを独立したページとして持ち、社内外を問わないフィードバック窓口を明文化しています
- Ubie: ドキュメントサイトとコンポーネントライブラリを外部に公開し、公開していること自体を運用の動機づけのひとつに置いています
共通しているのは、「何が正で、誰がどう更新するか」を先に決めて公開していることです(出典: デジタル庁「デザインシステム」・SmartHR Design System、いずれも2026年8月に閲覧)。
中身の豪華さは組織の規模に依存しますが、この装置は1人のチームでも置けます。版を宣言する、更新の窓口を決める、変更を記録する。立て直しの4手が向かう先も、結局は同じ場所です。
Ubieの再始動|一度止まった運用をどう建て直したか
3つ目のUbieは、前の2つと事情が違います。一度運用が停滞したところから再始動した経緯を、自社で公開しています。
テックブログには、Notionで管理していた時期に「どこに何があるか誰がメンテナンスしているかが明瞭でなく」「中途半端で形だけのドキュメントが残される結果」になったと、率直に書かれています。6つの壊れ方の5番目にあたる状態です。
再始動で置いた装置が示唆的です。
ドキュメントサイトを外部に公開した理由として「公開できるものは公開していくことで運用することへの意識を高める狙いもあります」と、狙いのひとつに挙げられています(出典: Ubie「Rebooting Ubie Vitals Design Systems」2024年1月)。
公開は、放置できなくするための仕掛けとして使われています。これは社外公開でなくても再現できます。社内の誰でも見られる場所に置き、更新が止まったら分かる状態にするだけで、同じ圧力がかかります。
よくある質問
デザインシステム構築にはどのくらいの費用がかかりますか?
アームの場合、部分整備が50万円〜、一式が150万円〜です(2026年9月時点・税別)。棚卸しだけならUIクイック診断・改善提案が無料で、最短1週間です。業界共通の定価はないので、他社と比較するときは金額よりも維持の工数が含まれているかを見てください。
一度作ったデザインシステムが使われていません。作り直すべきですか?
多くの場合、作り直しは不要です。壊れたのは運用なので、同じ運用のまま新品を渡しても同じ場所に戻ります。まず「正はどこか」を宣言し、使用頻度の高い部品から順に整える部分整備で足りることがほとんどです。
デザインシステムとデザインガイドラインは何が違いますか?
デザインガイドラインは、判断のルールを文書にまとめたものです。デザインシステムはそこに、実際に使える部品と値、そして運用の仕組みまでを含みます。ガイドラインだけがあって部品が無い状態は、レシピ本はあるのに食材が無い状態に近く、現場では使われません。
社内にデザイナーが1人しかいなくても、デザインシステム構築はできますか?
できます。むしろ人数が少ないほど、部品化の効果は大きくなります。ただし1人体制はその人が抜けた瞬間に5番目の壊れ方に直行するので、判断の履歴を残す仕組みだけは最初に決めてください。
Figma MCPを使えば、デザインシステムが無くても実装を自動化できますか?
難しいです。Figma公式の説明でも、MCPサーバーが取り込むのはバリアブル・コンポーネント・レイアウトのデータとされています。それらが無いファイルからは取り込むものがないため、出力の品質も上がりません。自動化の前提として構造が要ります。
デザインシステム構築にはどのくらいの期間がかかりますか?
部分整備で1〜2ヶ月、一式で3ヶ月前後が目安です。ただし期間より決め手になるのは、その期間のあとに誰が維持するかが決まっているかどうかです。決まっていない場合、期間を延ばしても結果は変わりません。
デザインシステム構築で150万円を無駄にしないコツは、正を1つ宣言する立て直しにある
デザインシステム構築が失敗するのは運用の設計が抜けているからです。壊れ方には順番があり、本番環境を正としてデザインデータを後追いする状態まで進むと、データは負債になります。立て直しは棚卸しからで、正を1つ宣言するところから始まります。
アームは、デザインシステム構築の前段にある現状の棚卸しと、維持の担い手を決めるところから関わっています。作り直すべきかどうかの判断からで構いませんので、よければご相談ください。





