Shuichiro Ogawa
English

Notes ・ updated 2026-09-11

デザインシステムのベストプラクティス

デザインシステム（以下 DS）は、普及の証拠と効果の証拠が釣り合っていない数少ない領域である。

zeroheight の2026年版調査（回答147名）では、専任の DS チームを持つ組織が83%に達した。 同調査が示す1年前の値は78%で、普及はまだ続いている。 回答者の39%は従業員5,000人以上の組織に属する。

効果の側は数字が細い。 同じ調査で ROI を計測していると答えたのは5%、開発速度は31%、採用状況とデザインツール上のコンポーネント利用がそれぞれ41%である。 Sparkbox の2021年調査（回答376件）でも、指標を計測している組織は31%だった。

導入した組織の大多数が、導入の効果を測っていない。 証拠が積み上がっている実践と、通説だけが先行している実践は、同じ DS という語の中に混在している。

DS を AI のコンテキスト層として読む視点は design-systems-ai-infrastructure と mcp-design-agent-integration が扱った。 ここで並べるのは、その手前にある設計と運用の証拠である。

証拠が支える設計の実践

色の抽象化を層に分ける設計を、IBM Carbon は設計文書で明文化している。

Token は「code identifier for a unique role or set of roles」、Role はテーマをまたいで変えられない役割、Value は16進の値、Theme は値の集合である。 トークンは全テーマで共通で、テーマを切り替えても動くのは値だけになる。

Carbon は再利用にも条件を付けた。 「A single token can be associated with multiple roles, but only if the color value is used consistently across those roles」。 同じ値を複数の役割で使い回すのは、その値がどの役割でも同じ意味で使われる場合に限る。

制約は数値でも書かれている。 各テーマは特定の primary background に固定し、混合トーンを避け、アクセシビリティは明度差50以上を要求する。 既定は4テーマで、「IBM products should use one of the four IBM default themes」と定める。

Salesforce は層の分離を別の向きから進めた。 SLDS 2 の CSS アーキテクチャは既定の見た目から切り離され、「no longer locked into predefined design choices for buttons, modals, fonts, and borders」になる。 切り替えはグローバルな styling hooks（CSS custom properties）で行い、「One change updates everything」になる。

Salesforce の命名規則は意味を基準にする。 radius-border-4、font-scale-4 のような名前は見た目ではなく役割を指す。 Figma キットと同じ語彙を共有することで「a shared vocabulary that bridges design and development」になる。

W3C の Design Tokens Community Group（DTCG）は2025年10月に交換形式の安定版を出した。 仕様は $value、$type、$description、$deprecated を持ち、グループ継承、エイリアス、型を定める。 型が標準で決まったことで、ツール間の受け渡しが機械可読になった。

標準が型を決めても、名前の意味は決まらない。 Adobe Spectrum の RFC は、自リポジトリの命名が抱える問題を自認した。 名前の意味が暗黙で、“text-to-visual” が何を指すか読んで分からない。 命名規約の検証がなく、“show me all spacing tokens” のように問い合わせることもできない。 「This makes it difficult to build tooling, enforce governance, or provide semantic guidance」という整理である。

提案は JSON Schema による検証と統制語彙への寄せだった。 プロトタイプは2,338トークン、8ファイルで動かし、schema validation のカバレッジは82%（1,929件）、parser は2秒未満、validation は約500ms だった。 19.5%にあたる455件は、追加スキーマを要する Special Tokens として残った。

設計上のトレードオフも記録されている。 keyed object はテーマ間で名前を重複できないため却下し、anonymous array を採った。 LLM にパースさせる案は「Non-deterministic」を理由に却下した。

2026年4月、著者自身が「this RFC is not the conformance target」と訂正した。 入れ子の name.structure は平坦化され、9カテゴリは Nate Baldwin の枠組みに沿う分類へ置き換わった。 最初の統制語彙も、そのままでは確定解にならなかった。

トークンは名前を変えると壊れるから、改名と移行も設計の一部になる。

Carbon v11 はトークン名を理解しやすい形に変えながら、「Tokens that are changing will continue to work in v11」と互換を明記した。 v10 で非推奨にした資産も v11 に残し、v12 で外すと予告する。 IBM Design Language 自体は変わらないため、製品の再設計は不要だと説明する。

Bootstrap は v5 で全面刷新を選ばなかった。 v3 から v4 への移行が難しかった経験がある。 「we’re now able to drop jQuery as a dependency, but you’d never notice otherwise」と書き、IE サポートの終了と引き換えに CSS custom properties を使い始めたと説明する。 グリッドの拡張に留め、CSS Grid については「we haven’t made use of it here yet, we’re continuing to experiment」と述べる。

Salesforce の SLDS 2 は移行を任意にした。 「You’re not required to switch」と明記し、位置づけを「it’s an upgrade, not a full rebuild」とする。 複雑なカスタマイズを抱える組織には「it may take more effort」と付け加え、dark mode が未提供で roadmap 上にあることも開示した。

三社に共通するのは、変更の範囲を先に区切り、壊れる範囲を明示している点である。

証拠が支える運用の実践

範囲を区切るだけでは、変更は回り続けない。 運用の証拠は、自動検証と貢献の受け入れ方に集まっている。

GitHub の Primer は色のコントラスト改修で、100を超えるカラーペアを監査した。 要求比は4.5:1と3:1である。 ここで効いたのは、色が独立していないという事実だった。 「colors are often part of multiple color pairs, which means that improving one pair may break the contrast for another」。 1組を直すと別の組が壊れる。

だから手動検証をやめ、スクリプトにして GitHub Action として毎PRで走らせた。 opacity は背景に依存するため、2段階ブレンドで解決した。 ブランドに関わる大きな変更は「intentionally leaving larger brand-impacting changes as a separate issue」として別 issue に切り出し、feature flag と社内インタビュー、数週間の監視を経て出した。

Harvey は採用率を閾値で管理する。 採用率80%で警告、95%で pre-commit エラーになる。 Figma variables を GitHub Action で同期し、Figma 側を正とする。

USWDS は内部テストの手段として VoiceOver、JAWS、キーボード、ズーム、タッチ、自動スキャンを使い、「if it doesn’t pass, we don’t merge」という規則を置く。 ただし自ら「Building with accessible USWDS components does not guarantee an accessible service」と警告する。

この方向には研究側の対応物がある。 UIS-Hunter は Android アプリの UI からガイドライン違反を検出し、該当する Material Design のガイドラインを示す。 GUIPilot はデザインモックアップと実装の不一致を検出し、80アプリと160のモックアップで precision 99.8%、recall 98.6% を報告した。 どちらも DS そのものではなく、DS への準拠を機械的に検査する系譜である。

受け入れ側の設計は、GOV.UK Design System が9段階と3役割の表で公開している。 prioritise、gather evidence、consolidate designs、scope、rough proposal、build working version、user research、build robust version、publish の9段階に、driving、supporting、awareness の3役割が対応する。

チームは「There is no one-size-fits-all process for how we work」「is process agnostic」と明記し、自らを非規定のモデルとする。 役割は2023年のチーム内ワークショップで定義した。

このモデルに至る転換が記録されている。 以前は「In the past, we often waited for teams to approach us for proposals for patterns and components」という待ちの姿勢で、「did not always match with the community’s needs」だった。 優先順位を先に公表し、コミュニティに参加を求める方式へ反転した。 「Facilitating contributions to design systems is hard. Not everything will work」とも書く。

Shopify Polaris は逆に、引き受けない範囲を先に決めた。 「The Polaris team should never be pulled in to unblock a team from shipping something quickly」とし、カスタムコンポーネントは作った製品チームが所有する。 製品全体の変更が起きたときも、そのチームが自分のカスタムを更新する責任を負う。

ただしトークンだけは例外で、「always use Polaris tokens」と統一を求める。 カスタムで作った解決には「the team should make an effort to systematize the custom solution down the road」と、後からシステムに取り込む努力も義務づける。

コンサルタントの Nathan Curtis は、取込を Support request、Feature request、Contribution proposal、Defect の4種類に分け、design と dev の Trafficer が振り分ける運用を示す。 workflow に DRI を置き、「doneness」を定義する。 リリースごとに「54 Preassigned tasks」を割り当てる。 自分の資料を「All the checklists, oh my!」と自嘲し、Figma の資産にも plan、test、review を求める。 約85システムの支援経験に基づく設計で、標本の内訳と期間は開示されていない。

自動検証と貢献モデルのどちらも、決めているのは例外の扱いである。 何を機械に任せ、何を人が引き受け、何を断るかである。

導入を止めている組織要因

運用の型が揃った組織でも、導入は広がらないことがある。 研究はその理由を技術の外に置く。

Richter ら（2025）は、成熟した DS を持つ単一組織のインタビューから、導入が進まない理由を4つに整理した。 知識ギャップ、進化の遅さ、柔軟性不足、非効率である。 提案は inner source、つまり社内のソフトウェア開発慣行を DS の開発と保守に持ち込むことにある。

Lamine と Cheng（2022）は OSS の DS リポジトリの issue を分析し、リーダーにインタビューした。 課題は UI コンポーネントの振る舞いに集中する。 安定した設計知識と製品ごとの柔軟性を同時に満たすのは難しい。 この研究は進化をボトムアップで進めることを支持する。

Palomino ら（2024）は、DS の導入を開発者体験（DevEx）の問題として扱った。 開発チームをユーザと見なす UCD 的なケーススタディで、インタビューで抽出した課題を解消した結果、導入が成功し、開発者のオーナーシップと UX 側と開発側の協働が改善したと報告する。

起点は上から来ない。 Sparkbox の2021年調査では、DS 導入の起点が個人貢献者だと答えたのが57%で、経営層は22%だった。

現場の余力も足りない。 zeroheight の2026年版調査では、人員が「足りない」と答えたのが61%、最大の課題はリソースと人員で56%である。 ステークホルダーの buy-in に満足している割合は、2025年の42%から2026年には32%へ下がった。 欠員が最も大きい役割はアクセシビリティ専門家とプロダクトマネージャーで、いずれも44%である。

人材の入口も細い。 Rose ら（2023）は、DS が学位課程でほとんど教えられてこなかったとして、教育用の教授モデルを提示した。

組織の外の事情も効く。 Du と Xiao（2023）は、英語圏で先に作られたグローバル DS をそのまま現地に展開すると、グローバル基準にも現地ニーズにも合わない製品になる問題を、中国市場の事例から分析した。

学際チームでの導入はコミュニケーションの問題でもある（Sousa と Lélis 2026）[要一次検証]。 書誌は確認済みだが、abstract が非公開のため内容と手法は確認していない。 どのコンポーネントを DS に含めるかの基準も提案されている（Maia ら 2026）[要一次検証]。 こちらも abstract が非公開で、内容と手法は確認していない。

Richter らの4つの阻害要因は、DS の中身ではなく組織の性質である。 導入率を動かしているのは、DS の品質だけではない。

証拠が弱いまま流通している主張

ROI を扱った数値は大量に流通している。 出所までたどれるものはほとんどない。

産業コーパスの収集では、2021年から2026年の間に、標本と定義を公表した DS 専用の ROI 調査を確認できなかった。 残るのは統制実験1件と自己申告の事例である。

Sparkbox の実験は、開発者8名に同じコンタクトフォームを2条件で実装させた。 自作と IBM Carbon の使用である。 中央値は4.2時間から2.0時間へ減り、47%の短縮になった。 Carbon 条件には学習時間が含まれる。 視覚的な一貫性は8名中5名で改善し、上位2件は DS を使った実装だった。 アクセシビリティは混在で、3名は同等、2名は DS を使わなかったほうが上だった。

開発者は全員フルスタックでアクセシビリティ研修済み、うち2名は IAAP 認定である。 著者自身が一般化を留保している。

この実験の数値は、流通する過程で形を変えた。 「Sparkbox 2023 survey により開発47%高速化」という表現が広まるが、一次ソースは survey ではなく n=8 の統制実験である。 標本の規模も手法も違う。

ベンダー側の数値は算定式が開示されないことが多い。 Figma と HP の事例は、Dev Mode 利用者400名への調査で「80%が効率向上を実感」「1人あたり週98分の節約」と述べ、Veneer について2023年1月から12月で「500%のROI」とする。 算定式とコスト基準は非開示で、効果は自己申告である[要一次検証]。

計測の実態は、こうした数値の流通と対応していない。 zeroheight の2026年版調査で ROI を計測しているのは5%である。

「一貫性が良い」という前提も単純ではない。

Grudin（1989）は、一貫性が設計指針として信頼できないと論じた。 設計者が見るべきは一貫性の度合いではなく、ユーザが置かれている作業環境である、という主張である。

Kolko（2026）はデザインマネージャー17名にインタビューし、DS と組立生産が効率と一貫性をもたらす一方、探索を省略させ差別化を軽視させる経路で創造性を損ないうることを示した。

Opsahl と Sitompul（2025）の比較は、その含意を具体的にする。 クレーン操作者8名に、DS をそのまま適用した GUI と、設計原則に沿って修正した GUI を試してもらった。 課題達成率はどちらも100%、速度にも差がなかった。 満足度は修正版のほうが大幅に高かった。

「そのまま使う」ことが最良の結果にはならなかった。

GOV.UK の政府デザイン原則は、この限界を11項目の中に取り込んでいる。 9番目の項目は「Be consistent, not uniform」である。

成熟度という語も、公的な定義を持たない。 収集の範囲では、DS の成熟度を定義する公的文書は見つからなかった。 存在しないと断定はできないが、参照できる定義がない状態である。

流通している成熟度の段階は商用の提案である。 UXPin と Whitespace の調査は大手企業のマネージャ19名にインタビューし、Stage 3「Design and Coded Components」に到達したのが63%と報告する。 実施時期は開示されていない[要一次検証]。

調査の間で DS の定義自体が揺れている。 Yew ら（2020）は Clarity 2019 の1,513名へのサーベイとインタビューから、定義の揺れと内製化の傾向を報告した。 定義が揃わなければ、調査間の数値を並べても意味を持ちにくい。

学術側の蓄積も薄い。 Vendramini ら（2021）は23件のソースをマッピングし、うち査読文献は6件だった。 学術データベースからの引用の少なさを指摘している。

研究が扱っていない領域も記録されている。 デザイントークンだけを主題にした査読研究はほぼ存在せず、OpenAlex で “design tokens” を題名検索して16件、うち査読会議論文は Brickify（CHI ‘25）のみだった。 DS のガバナンスを主題とする査読論文は見つかっていない。 DS の失敗パターンを主題とする査読論文も見つかっていない。

同じ調査の版をまたぐ比較もできない。 zeroheight は2026年版で2025年の専任チーム率を78%と記録するが、2025年版は同じ年を79%と記録する。 1ポイントのずれである。

標本の性質にも制約がある。 zeroheight と Sparkbox はいずれも自己選択の非確率標本であり、母集団の推計には使えない。

証拠が弱いことは、実践が無効であることを意味しない。 だが現状では、無効でないことも示されていない。

標準と法規制が決める前提

効果の証拠が薄くても、外から決まる前提はある。 トークンの交換形式と、アクセシビリティの要求水準である。

デザイントークンの交換形式は DTCG が定めた。 2025年10月28日に Final Community Group Report として公表された「Design Tokens Format Module」である。

これを W3C 標準と呼ぶのは正確でない。 仕様自身が W3C Standard ではなく Standards Track 上でもないと明記し、Community Group Report として公表されている。 W3C も「Community Group の見解は W3C メンバーシップやスタッフの見解を必ずしも代表しない」と注記する。 分類としては Candidate Recommendation 相当で、仕様は “considered stable” と書く。

2025.10 版は Format、Color、Resolver の3モジュールで構成される。 参加者は546名、議長は3名である。 発表時点で Style Dictionary、Tokens Studio、Terrazzo などが対応し、Figma、Penpot、Sketch、Framer、zeroheight など10を超えるツールが実装した。 寄与元には Adobe、Amazon、Google、Microsoft、Meta が名を連ねる。

統治も動いている。 2026年6月17日に Jina Anne と Val Head が co-chair を退任して chairs emerita になり、co-chair 選挙と会合の再開が予告された。

アクセシビリティの側は、標準と法規制と調達が重なる。

WCAG 2.2 は2024年12月12日付の W3C Recommendation である。 4原則と13ガイドラインを持ち、適合レベルは A、AA、AAA の3段階になる。 2.1 から9つの成功基準を追加し、4.1.1 Parsing を1つ削除した。 2.2 に適合する内容は 2.0 と 2.1 にも適合する。 ISO/IEC 40500:2025 としても承認されている。

W3C の WCAG のページは、AA が一般に要求される水準だとは記述していない。 実務で AA が基準として扱われるのは、法規制がそこを指定しているためである。

英国では、公共部門のウェブサイトとアプリに Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 が適用される。 2018年9月23日に発効した。 要求水準は WCAG 2.2 AA と明記されている。 accessibility statement の公表が義務で、イントラネットとエクストラネットも対象になる。 2019年9月23日より前に公開されたものは、更新時に適合が求められる。

監視は GDS が年次サンプリングで行い、不備を認定した機関の名前と決定が公表される。 執行は EHRC と ECNI が担い、unlawful act notice と訴訟の手段を持つ。 対応が過大な負担になるという主張には、評価と記録が必要になる。

DS 自身も適合を宣言する。 GOV.UK Design System は website、Frontend documentation website、Frontend codebase の3対象すべてが WCAG 2.2 AA に「fully compliant」だと述べる。 外部監査は Digital Accessibility Centre が2024年7月などに実施した。 非適合コンテンツは「no known non-compliant content」で、追跡中の懸念2件も公表している。

EU では Web Accessibility Directive（Directive (EU) 2016/2102）が2016年12月22日から効力を持つ。 公共部門のウェブサイトとアプリが対象で、broadcasters と live streaming などに限定的な除外がある。 義務は accessibility statement、フィードバック機構、加盟国による定期監視と3年ごとの欧州委員会への報告である。

技術的基盤は整合規格 EN 301 549 v3.2.1 である。 ここで版ずれが起きている。 EN 301 549 の現行版は WCAG 2.1 を使っており、WCAG 2.2 に移るのは次版になる見込みである。 W3C は旧版が廃止されたわけではなく、最新版の使用を推奨すると述べる。

EN 301 549 の条項原文は ETSI の PDF が403で直接確認できず、版号と位置づけは欧州委員会のページ経由でしか確認していない[要一次検証]。

欧州委員会はオーバーレイについて「It is best to fix accessibility issues at their source」と書き、テストには「always involve persons with disabilities」を求める。 EU 人口の約1億人が何らかの障害を持つと推計されている。

米国は Section 508 of the Rehabilitation Act を根拠にする。 2018年の更新で WCAG 2.0 Level AA を採用し、これを「the baseline of conformance for legal compliance」と位置づける。

USWDS 自身の目標はそれより高い。 WCAG 2.1 AA の達成を「works to achieve the higher standard」と表現し、WCAG 2.2 は必須ではないが「we strive to achieve as many of the latest success criteria as we can」とする。 conformance report は VPAT 2.5 で作り、USWDS 3.11.0 の44コンポーネントを2025年3月に評価して5月に公表した。

法的基準と DS の目標は一致していない。 DS を使えば準拠する、という関係にはならない。

日本ではデジタル庁がデザインシステムβ版を公開している。 デザイン言語、UIコンポーネント、ガイドラインの3部構成で、デザイントークンとサンプルコードを GitHub と Storybook で配布する。 HTML 版と React 版、Figma データ、Markdown 版が用意されている。 版は v2.18.0 で、更新日は2026年9月9日である。

「β」はリビングスタンダードであることを示すと説明される。 最新の更新バッチでは約20のコンポーネントが公開された。 WCAG の適合レベルは本文に記載がない。

カナダは義務の形をとる。 Directive on the Management of Communications and Federal Identity の Appendix D が根拠で、Financial Administration Act の Schedule I、I.1、II に列挙された機関の public-facing なサイトとデジタルサービスに Canada.ca design requirements の適用を求める。 技術やプラットフォームは問わない。 global header と footer は適用も複製もできない。

規範文書の側にも設計上の判断がある。 英国の政府デザイン原則は11項目で、2025年の更新で「Minimise environmental impact」が加わった。 Service Standard は14項目で、第13点は「Use and contribute to open standards, common components and patterns」である。 設計システムという語を明示する項目はない。

研究は DS をアクセシビリティの配送手段と位置づける。 Wahid（2024）は組織横断でアクセシビリティ支援をスケールさせる考え方を論じた（ACM Queue、非査読）。 Diniz と Gama（2024）は主要 DS のアクセシビリティ対応状況を調査し、アクセシビリティを織り込んだコンポーネントパッケージを開発者に試用させた。

標準と法規制は、DS の設計判断の外側にある制約である。 DTCG は交換形式を揃え、アクセシビリティ法制は適合水準を決める。 どちらも DS 単独では変えられない。

各社が何を選び何を捨てたか

集計では、個々の判断は見えない。 判断の中身は、各社が何を捨てたかの記録に現れる。

Brad Frost は単一システムへの一元化を否定する。 「it would be a disaster if ALL user interface at an organization originated from a single design system」と書き、共有基盤の上に各チームの自律を載せる layer-cake 型を主張する。 DS は制約を持ち込むものでありながら、「efficiency, quality, & scale」と「flexibility and agency」の両方を満たす必要がある、という整理である。

Atlassian はタイポグラフィのトークン化を18以上のアプリで実施し、後悔を記録した。 「We allotted little design time to the tokenization, which we quickly realised was a mistake」と、設計工数の過小配分を認めている。 やり方は3段階で、まず「no visual changes」のままトークンで旧体系を再現し、後から新フォントへ移した。 最小の見出しと本文を11pxから12pxに上げ、minor third scale を採用した。

不要と判断したものも捨てた。 出荷済みだった「UI text」スタイルは混乱を解消しなかったため破棄した。 判断の基準は「When in doubt, take it out」である。

Harvey はリビルドを選んだ。 引き金は「Our product complexity was growing faster than our design infrastructure could support」である。 当時の自評は「more of a collection of components than a fully realized design system」で、トークンは「transformed organically over time, which is a polite way of saying it was chaotic」だった。 色によっては2値しかなく、中性色は910から940、他の色は100から1000と50から950の2体系が混在していた。 同じコンポーネントの複数版が別ファイルに生き、「There was no clear ownership or contribution process」という状態だった。

新トークンには hy- prefix を付け、Figma variables を GitHub Action で同期し、Figma を正とする。

Ant Design は自らの方式の弱点を認めた。 メンテナの @MadCcc は、CSS-in-JS の方式がコンポーネントの props に追随しないため、使ったコンポーネントの全スタイルが導入されると書く。 SSR でスタイルをインライン化すると、生成される CSS が膨らむ。 テーマ切替の引っかかりと、リロード時の明から暗へのフリッカーも、自社が同じ問題を抱えていると認めた。

解決は CSS 変数の注入で、5.12.0 から CSS 変数モードを提供する。 Mantine のように柔軟なテーマ能力を捨てる選択は取らなかった。 代償として、入れ子の多テーマでは生成される CSS が増える負担が残ると明記する。

OpenProject は自前の DS を捨て、外部の成熟したシステムに乗る判断をした。 「lean on the experience and expertise of more mature open source projects」が理由で、浮いた工数を本体機能へ回す意図がある。 移行は軽くない。 「it is nevertheless a significant amount of effort」と書き、途中は「you might notice a mix of old design elements and new Primer components」「This blending is temporary but essential」という状態になる。 副作用として、フォントサイズが採用先の基準に合わせて小さくなった。 採用先にも制約があり、「not all existing components are reviewed for accessibility」と記されている。

Google は反例も出した。 Expressive 版の Material Design は46の研究、18,000人を超える参加者、10アプリでの比較に基づく。 「the most researched update to Google’s design system, ever」と自ら述べる。 手法は eye tracking、サーベイとフォーカスグループ、実験、ユーザビリティテストである。

成果と一緒に、効かなかった変更も開示した。 「removing text labels from email actions resulted in decreased usability」。 ラベルを消すと使いやすさが下がった。 「a strong minority of users preferred calmer, less intense versions」。 強い少数はおとなしい版を好んだ。 結論として「it’s not a one-size-fits-all solution」と書く。 アクセシビリティについては「we chose to exceed existing standards for tap target size, color contrast」と、基準を上回る選択を明示した。

Storybook はスタイリング基盤を Styled Components から Emotion へ移した。 541コンポーネント、5コードベース、2,300を超える stories が対象で、1四半期かかった。 移行の難所は CSS の文脈依存性である。 「Refactoring CSS is one of the most challenging tasks as a frontend developer」であり、「minor changes in one file can have unintended consequences without warnings」になる。 二重管理は「Maintaining parity between two versions of the same components slowed us down」として速度を落とした。 Emotion に attrs がないため defaultProps と wrapper で回避し、SSR の zero-config は動かず manual setup に切り替えた。

Atlassian の別チームは、DS を1ファイルに畳む試みの代償を実測した。 ログイン画面の生成で DESIGN.md を唯一の DS 情報源にすると、トークン消費が約92%増え、実行間のばらつきが約2.7倍になったと報告する。 比較は4方式である。 文脈なしが平均4.20Mトークンで6分19秒、43ターン。 ADS MCP が3.75Mで5分1秒、35.1ターン。 ADS skill が4.43Mで5分23秒、36ターン。 DESIGN.md が7.21Mで6分46秒、45.3ターン。 いずれも平均値で、試行回数は非開示である。

DESIGN.md は約19,800トークンに収めるため、50を超えるコンポーネントの利用ガイダンスを削除した。 欠落はエージェントが実装を読んで補う。 DS の内部を文章化した結果、「DESIGN.md was more likely to re-create components rather than use the existing system」という傾向が観察され、技術的負債を生む方向に働いた。

著者は「These results should not be seen as conclusive; this blog is not a research paper」と留保する。 単一タスクでの比較であり、DS を AI のコンテキストとして渡す設計は、渡し方を変えるだけで結果が変わる段階にある。 これは design-agent-tools-landscape-2026 が扱った領域でもある。

捨てたものの記録が残っているのは、判断が難しかった場所である。 語彙を増やすか減らすか、システムを一つにするか複数にするか、拡張を急ぐか待つか。

未解決の対立

同じ問いに反対の答えを出している実践が、複数ある。

対立軸立場A（出典）立場B（出典）判定に必要な証拠
単一システムか複数システムか全 UI が単一 DS 由来になるのは「a disaster」であり、共有基盤と自律の layer-cake 型を取るべき（Brad Frost 2025、developer-voice）実際の運営モデルは centralized が51%、hybrid 31%、federated 13%で集権が過半（zeroheight 2026、n=147、自己選択標本）複数システムを運用する組織で、重複コンポーネント数と修正の反映時間を実測した比較
一貫性は目的か手段かトークンと役割の統一を設計の核に置く（IBM Carbon）、「One change updates everything」（Salesforce SLDS 2）。いずれも一次資料一貫性は設計指針として信頼できない（Grudin 1989、学術）。DS は探索の省略を通じて創造性を損ないうる（Kolko 2026、n=17、学術）。GOV.UK の原則は「Be consistent, not uniform」一貫性の水準を統制し、タスク成績と探索行動を同時に測った比較研究
トークンは網羅すべきか最小限にすべきか2,338トークンを JSON Schema と統制語彙で管理する方向を提案（Adobe Spectrum RFC、プロトタイプ実測）文脈を増やすとトークン消費が約92%増え、ばらつきが約2.7倍になった（Atlassian DESIGN.md 実験、単一タスク、著者自身が一般化を留保）同一タスクでトークン数と生成品質の関係を測った統制実験
統制するか自律に委ねるか緊急対応は断り、カスタムの所有を製品チームに置く（Shopify Polaris、運用ルール文書）。9段階と3役割のプロセスを公開する（GOV.UK、チーム文書）阻害要因は知識ギャップ、進化の遅さ、柔軟性不足、非効率で、inner source が提案される（Richter ら 2025、単一組織）。導入の起点は個人貢献者57%（Sparkbox 2021、n=376、自己選択）統制の強度が異なる組織の縦断比較（導入率と外部貢献数の推移）
改名して整理するか互換を保つかトークン名を変えつつ v11 で旧名も動かし、v12 で外すと予告（IBM Carbon v11、リリース告知）v3 から v4 の移行困難から全面刷新を避けた（Bootstrap v5、作者ブログ）。移行は任意で「You’re not required to switch」（Salesforce SLDS 2）互換維持を選んだ組織で、旧トークンの残存期間と修正コストを追跡した事例
DS を使えばアクセシブルになるか「Building with accessible USWDS components does not guarantee an accessible service」。法的基準は WCAG 2.0 AA で、DS の目標は 2.1 AA（USWDS、一次資料）DS をアクセシビリティ支援の配送手段と位置づけ、組織横断でスケールさせる（Wahid 2024、ACM Queue、非査読）DS 採用サービスと非採用サービスのアクセシビリティ監査結果の比較

参照文献

すべての URL のアクセス日は 2026-09-11。

学術文献

公的機関と標準

産業調査

実務一次証言

未検証事項

  • zeroheight 各年版の回答受付期間が非開示（2026年版、2025年版とも）
  • Sparkbox の ROI 統制実験の実施時期
  • UXPin と Whitespace の調査実施時期
  • Figma と HP の事例における ROI 算定式とコスト基準
  • IBM Carbon v10 カラーページ、Google Design の記事、Shopify Polaris の contributing 文書の公開日
  • Sousa と Lélis（2026）、Maia ら（2026）の内容と手法
  • EN 301 549 の条項原文（ETSI の PDF が403）、および ISO/IEC 40500:2025 の ISO 側の書誌

← Notes 一覧 ・ ホーム