Shuichiro Ogawa
English

Notes ・ updated 2026-09-11

デザインシステムの6つの対立点を判定する証拠

design-system-practices の「未解決の対立」表は、6つの対立軸それぞれに「判定に必要な証拠」を1行で書いている。 その1行は、実際には複数の測定の組み合わせから成る。 「複数システムを運用する組織で、重複コンポーネント数と修正の反映時間を実測した比較」は、重複をどう数えるか、その計数が判定の閾値に対して安定するか、修正が反映されるまでの時間をどう測るか、運用するシステムの数を独立変数に置けるか、という別々の測定に割れる。

1つでも欠ければ、対立は判定できない。 本ノートは6つの1行を測定の単位に分解し、どこまで実測があり、どこが空かを確定する。

ピース：判定条件を分解した、これ以上は分けずに1つの測定として扱える単位。

証拠を探した層は3つある。

  • A：デザインシステムを直接対象にした実測。
  • B：デザインおよび HCI の文脈で行われた実測。
  • C：隣接分野（ソフトウェア工学、ソフトウェアエコシステム研究、組織研究、公的監査）の実測。

同じ1行でも、A で埋まるピースと C でしか埋まらないピースがある。

対立軸判定条件埋まっているピース空のピース最も近い実測
単一システムか複数システムか複数システムを運用する組織で、重複コンポーネント数と修正の反映時間を実測した比較P1 重複コンポーネント数、P2 重複判定の安定性、P3 修正の反映時間P4 システム数を独立変数に置く比較、P5 組織横断の比較と縦断の比較C（A の実測は質的研究1件のみで、計数も時間も測っていない）
一貫性は目的か手段か一貫性の水準を統制し、タスク成績と探索行動を同時に測った比較研究P1 一貫性の水準の統制、P2 タスク成績、P5 転移（成績側のみ）P3 探索行動、P4 成績と探索の同時計測B（A は DS 再利用の比較1件のみ）
トークンは網羅すべきか最小限にすべきか同一タスクでトークン数と生成品質の関係を測った統制実験P2 情報量の操作、P3 品質の測定、P4 文脈長、P5 断片数、P6 詳細度と圧縮、P7 用量反応、P8 消費コストP1 語彙数の操作、P9 DS を直接対象にした語彙数と品質C（DS 文脈の比較は B、語彙数の実測は A にも C にも無い）
統制するか自律に委ねるか統制の強度が異なる組織の縦断比較（導入率と外部貢献数の推移）P1 統制強度の操作定義、P3 越境貢献の計測、P4 縦断設計P2 導入率の計測、P5 対照群の並行比較、P6 因果の識別C（DS 直接の縦断は産業の単一時点の記述のみ）
改名して整理するか互換を保つか互換維持を選んだ組織で、旧トークンの残存期間と修正コストを追跡した事例P1 旧名の残存期間、P2 非推奨への反応率、P3 移行の修正コスト、P4 互換を破った場合の実害率、P5 非推奨マーカーの運用P6 DS を直接対象にした実測C（A はゼロ、産業側も見積と計画のみ）
DS を使えばアクセシブルになるかDS 採用サービスと非採用サービスのアクセシビリティ監査結果の比較P1 採用の同定、P2 対照設計、P3 監査結果、P5 交絡の統制P4 実装忠実度、P6 採用前後の縦断A（DS 成果物単位）と C（サービス単位は自動監査のみ）

37のピースのうち、何らかの実測があるのは25、該当研究を確認できないのは12である。

重複コンポーネント数と反映時間は測られているか

判定条件

複数システムを運用する組織で、重複コンポーネント数と修正の反映時間を実測した比較

何を測れば埋まるか

  • P1 重複コンポーネント数：同一の役割を持つコンポーネントが複数のシステムに何個あるかを、判定規則を固定して数える。
  • P2 重複判定の安定性：判定の閾値を動かしても計数が変わらないことを確かめる。
  • P3 修正の反映時間：一方のシステムに入れた修正が他方へ届くまでの時間を測る。
  • P4 システム数を独立変数に置く比較：単一運用と複数運用を並べ、結果の差を運用数に帰属させる。
  • P5 組織横断の比較と縦断の比較：複数の組織を同じ定義で追跡し、組織固有の事情を差し引く。

実測が届いている範囲

重複の計数は、隣接分野で測られている。 web アプリ17件のクローン検出では、クローン率が 17〜63% の幅に収まり、統制の記載はない（Rajapakse & Jarzabek 2005、DOI 10.1007/11531371_35）。 493k ページペアを人手で分類した研究は、閾値を最適化しても coverage を犠牲にせずに全機能的近重複を検出するアルゴリズムはないと結論した（Yandrapally, Stocco, Mesbah 2020、DOI 10.1145/3377811.3380416）。 産業システム1件を8コンポーネント、10チームに分けた研究は、チーム別のクローン導入数を測っている（Sundelin, Gonzalez-Huerta, Torkar, Wnuk 2024、DOI 10.1007/s10664-024-10598-7）。 観測期間とレビュー参加人数は未取得である [要一次検証]。

反映時間に近いのは、パッケージの更新遅延である。 890の共有パッケージを6つのディストリビューションで比較した研究は、update delay と time lag の2指標を定義し、10件に1件が古い状態にあることを示した（Legay, Decan, Mens 2021、DOI 10.1109/SoHeal52568.2021.00008）。 npm では120K パッケージ、1.4M リリース、8M 依存関係を解析し、技術的ラグが時間とともに増大し、semver の遵守がそれを軽減することを示した（Decan, Mens, Constantinou 2018、DOI 10.1109/ICSME.2018.00050）。

デザインシステムを直接対象にした唯一の質的研究はボトムアップ型を支持したが、重複数も反映時間も測っていない（Lamine & Cheng 2022、DOI 10.1007/s10664-022-10181-y）。 組織構造と技術構造の対応は、実証研究102件のレビューで69%の研究に成立し、企業内、企業間、オープンコミュニティの順に弱まる（Colfer & Baldwin 2016、DOI 10.1093/icc/dtw027）。

確認できなかった測定

運用するシステムの数を独立変数にした査読研究は、9本の探索語で見つからなかった。 UI コンポーネントで修正の反映時間を測った査読研究もなく、設問レベルで確認した4つの産業調査（zeroheight 2026年版と2025年版、Sparkbox 2020年版と2021年版）のいずれにも重複数と反映時間の設問はない。 産業側の数値は仕様から実装までの平均 3.7週と不一致 46.3% の1件だけで、設問と回収期間は非開示である [要一次検証]（UX Tools、https://www.uxtools.co/survey/design-systems/overview）。

隣接分野からの移用

移用が成立するのは、測定対象を両群に共通する部分へ絞れる場合である。 890の共有パッケージへの限定が比較を可能にし（Legay, Decan, Mens 2021）、更新遅延が規約の遵守に依存するという機構が同じなら反映時間の測定も同じ形で当てられる（Decan, Mens, Constantinou 2018）。 組織構造と技術構造の対応は企業内で最も強く成立するので、同一企業内で複数のシステムを運用する状況はこの条件を満たしやすい（Colfer & Baldwin 2016）。

移用が崩れるのは、重複の計数が手続に依存する場合である。 閾値を最適化しても全近重複を検出する方法はなく、クローン率 17〜63% の幅も統制がない以上システム数以外の要因を含む（Yandrapally, Stocco, Mesbah 2020、Rajapakse & Jarzabek 2005）。 組織構造との対応はオープンコミュニティで弱まり、外部に開かれたデザインシステムでは前提が崩れる（Colfer & Baldwin 2016）。

一貫性の水準を統制して成績と探索を同時に測れるか

判定条件

一貫性の水準を統制し、タスク成績と探索行動を同時に測った比較研究

何を測れば埋まるか

  • P1 一貫性の水準の統制：一致の程度を段階または属性として操作し、他の条件を固定する。
  • P2 タスク成績：完了率、所要時間、エラー数といった成績指標を測る。
  • P3 探索行動：使われなかった機能の発見、試行の広がり、操作の系列を測る。
  • P4 成績と探索の同時計測：同一の被験者で両方を測り、一方の改善が他方を損なわないかを確かめる。
  • P5 アプリ間の転移とタスク間の転移：ある画面で学んだ操作が別の画面で効くかを測る。

実測が届いている範囲

一貫性の水準の統制は、デザインと HCI の文脈で蓄積がある。 2つのアプリにまたがる一貫性を2属性（表示画面の外観と言語の構文）で操作した実験は、n=114 で操作数と正確性を測った（Satzinger & Olfman 1998、DOI 10.1080/07421222.1998.11518190）。 課題内容と時間計測、盲検の有無は未取得である [要一次検証]。 web ページの一貫性を物理、伝達、概念の3要素に分解した実験は、4群の被験者間設計で計40名を割り当て、エラー率、所要時間、満足度を測った（Ozok & Salvendy 2000、DOI 10.1080/001401300184332）。 盲検の記載はない。

デザインシステムを直接対象にした比較は1件だけで、そのまま再利用した GUI と設計原則で修正した GUI をクレーン操作者 n=8 で比べた（Opsahl & Sitompul 2025、DOI 10.1109/CHIuXiD68326.2025.11323756）。

成績側の結果は収束していない。 画面外観の不一致は精度と満足度を上げ、命令言語の不一致は操作数を増やした（Satzinger & Olfman 1998）。 web ページでは性能と満足度の仮説が支持されず（Ozok & Salvendy 2000）、クレーン操作では達成率が両条件とも100%で時間差がなく修正版の満足度が高かった（Opsahl & Sitompul 2025）。

転移は成績側でだけ測られ、命令言語の学習しやすさが規則の一貫性構造に依存するという予測は構文学習実験で支持された（Payne & Green 1989、DOI 10.1016/s0020-7373(89)80011-2）。 標本、独立変数、従属変数、統制のすべてが未取得である [要一次検証]。

確認できなかった測定

一貫性を操作する研究と探索行動を測る研究を組み合わせたものは、7本の探索語で見つからなかった。 デザインシステムで一貫性の水準を統制した比較研究も、探索行動の測定も確認できない。 同一の被験者で成績と探索の両方を測った研究は0件である。 産業側にも一貫性を統制した比較はなく、唯一の統制実験とされる Sparkbox の Carbon の比較は操作変数が DS の有無で、一次 URL も特定できていない [要一次検証]。 探索行動の測定法として最も近い文献（Thomas 1996、SIGCHI Bulletin）は、Crossref に該当レコードがなく書誌を確認できないため採録していない。

隣接分野からの移用

移用が成立するのは、操作と表示の対応が固定されていて、一致の程度を連続量として扱える場合である。 刺激と反応のコードの空間的一致は情報伝達率で定式化され（Fitts & Seeger 1953、DOI 10.1037/h0062827）、装置モデルの利得が操作手順を直接推論できる場合に限られることも3実験で示されている（Kieras & Bovair 1984、DOI 10.1016/s0364-0213(84)80003-8）。 参加者数と試行数は未取得である [要一次検証]。

移用が崩れるのは、まとめて「一貫性」と呼んでいる対象の符号が揃っていない場合である。 画面外観の不一致が精度と満足度を上げる一方で命令言語の不一致は操作数を増やしたので（Satzinger & Olfman 1998）、外観と操作言語を1つの変数にまとめると逆向きの2つが混ざる。 規則の一貫性構造をデザインシステムのコンポーネントの使い方に写せるかは、標本と統制が未取得のため確認できない（Payne & Green 1989）。

トークン数と生成品質の関係は測られているか

判定条件

同一タスクでトークン数と生成品質の関係を測った統制実験

何を測れば埋まるか

  • P1 語彙数の操作：同一のデザインシステムで、トークン定義の数だけを変える。
  • P2 文脈に載せる DS 情報の量の操作：DS 文書のうちどれだけをプロンプトに入れるかを変える。
  • P3 品質の測定：生成物が DS に準拠しているかを採点する。
  • P4 文脈長だけを増やす：課題と無関係なトークンで埋め、長さのみを変える。
  • P5 断片の数だけを増やす：全体の長さを固定し、文書数や例示数だけを変える。
  • P6 詳細度を上げる、または圧縮する：同じ内容を詳しく書くか短く書くかを変える。
  • P7 用量反応の形：増減に対して品質が単調に動くか、最適点があるかを推定する。
  • P8 消費コストの同時計測：同じ試行の中でトークン消費を測る。
  • P9 DS を直接対象にした語彙数と品質の関係：P1 と P3 を同一の実験で満たす。

実測が届いている範囲

デザインシステムを文脈として渡す比較は1件ある。 DS 文脈の渡し方3方式を同一課題で比べた研究では、レジストリ方式が準拠率 95.08%（±4.77）で最も高く分散も最小だったが、情報の量と構造が同時に変わるため量だけの効果は分離できない（Cha, Jo, Shin, Seo 2026、6画面×3反復、https://pure.seoultech.ac.kr/en/publications/design-system-compliant-user-interface-generation-with-llm-agents/）。 採点手続、評定者、盲検は未取得である [要一次検証]。

隣接分野では、量を操作する統制実験が蓄積している。 同一課題のままパディングの量、種類、位置だけを変えた実験では、技術的な上限よりはるかに短い入力長で推論性能が低下し、次トークン予測の精度は逆相関した（Levy, M., Jacoby, A., Goldberg, Y. 2024、入力長250〜3000トークンの5水準、DOI 10.18653/v1/2024.acl-long.818）。 perfect retrieval を統制しても入力長だけで性能が 13.9〜85% 低下し、無関係なトークンを空白に置換してもマスクしても低下が残った（Du, Y., Tian, M., Ronanki, S. ほか 2025、DOI 10.18653/v1/2025.findings-emnlp.1264）。 文脈長と支持文書の位置を固定して文書数だけを変えた実験では、大半のモデルで最大20%低下し、Qwen2.5 は安定していた（Levy, S., Mazor, N., Shalmon, L., Hassid, M., Stanovsky, G. 2025、arXiv:2503.04388）。 例示数を最大 8,192 まで増やす実験では XSum が 50 shot 超で劣化し MATH は 125 でピークに達した後に低下し、次トークン予測の損失は下がり続けるため品質の代理指標にならないことも示された（Agarwal, R., Singh, A., Zhang, L. M. ほか 2024、arXiv:2404.11018）。 詳細度を上げると pass@1 が上がり ParEval-OMP では最大 +0.30 だったが [要一次検証]（Zi, Y., Menon, H., Guha, A. 2025、DOI 10.18653/v1/2025.ijcnlp-long.128）、制約ブロックの符号化を圧縮して制約部のトークンを約71%、プロンプト全体を25〜30%削減しても準拠率に有意差は出なかった（Tang, H. 2026、11モデル、830回超の呼び出し、Cliff’s δ < 0.01、arXiv:2604.07192）。

品質は自動採点で測られることが多い（Cui, Y. 2025、1,000課題、20領域、19モデル、arXiv:2505.09027）。 この文献は arXiv の管理注記が別の論文とのテキスト重複を指摘しており、結論部のモデル数（18）がアブストラクト（19）と一致しない。

産業側の3件は、方向が割れている。 自社 DS の AI 可読化では、4タスク合計の使用量が 19M から 10.4M へ減り、設計からコードのシナリオで 39% 減ったが、品質は自社エンジニアの判定で盲検でも自動採点でもないと著者自身が記している（BILL、https://www.bill.com/engineering/how-we-made-our-design-system-bilingual）。 Code Connect の有無を比べた27ケースでは、中央値のタスクでトークンが 29.5%、所要時間が 19.6% 減り、品質が1〜4の尺度で2から3へ上がったが、判定は LLM judge でモデル名と人手照合の有無は非開示である [要一次検証]（Figma、https://www.figma.com/blog/the-benefits-of-code-connect-in-mcp/）。 文脈の渡し方を4方式で比べた自社実験では、平均トークンが文脈なし 4.20M、MCP 3.75M、DESIGN.md 7.21M で、出典自身は DESIGN.md 条件について「required ~92% more tokens」と記し、実行間の分散が約2.7倍になったとも書く（Atlassian、単一タスク、品質は未測定、出典は既存コーパス source/review/design-system-practices/industry.md の DS-15）。

確認できなかった測定

デザイントークンの語彙数（定義数）を独立変数にした統制実験は、14本の探索語と OpenAlex の検索で見つからず、語彙数のアブレーションも存在しない。 デザイントークンの直接操作を扱った研究はあるが、視覚的なトークンは言語モデルのトークン数とは別の概念で、語彙数と生成品質の関係は測っていない（Brickify 2025、DOI 10.1145/3706598.3714087）。 産業側の近接例も、トークン数と品質の関係を測定対象にしていない。 評点を公開しているベンチマークは判定が処理条件に対して盲検だと記すが、README に「898 runs」と「+23〜26pt」は存在しない [要一次検証]（Open Design System Bench、https://github.com/christophhdesign/open-design-system-bench）。

隣接分野からの移用

移用が成立するのは、増分が課題と無関係であることを統制できる場合である。 パディングの量、種類、位置だけを変えた設計は長さの効果を内容から分離し（Levy, M., Jacoby, A., Goldberg, Y. 2024）、文書数だけを変えた設計は長さと位置を固定している（Levy, S. ほか 2025）。 perfect retrieval を統制しても低下が残ることは、検索の失敗を除いても長さ自体のコストが残ることを示し、その分は DS 文脈の量にも同じ形で現れうる（Du, Y. ほか 2025）。

移用が崩れるのは、増分が解釈対象の文書ではなく実行可能な部品である場合である。 レジストリ方式は最多のトークンで最高の品質を出しており（Cha, Jo, Shin, Seo 2026）、同じ研究の中で文脈なしに対する平均トークンが MCP では減り DESIGN.md では増えるという逆転も起きている（Atlassian）。 損失を品質の代理指標にすると用量反応の形を取り違え（Agarwal, R. ほか 2024）、詳細度を上げる操作と圧縮する操作では符号が逆か null になる（Zi, Y. ほか 2025、Tang, H. 2026）。

統制強度の異なる組織を縦断で比較できるか

判定条件

統制の強度が異なる組織の縦断比較（導入率と外部貢献数の推移）

何を測れば埋まるか

  • P1 統制強度の操作定義：統制の強さを段階または類型として定義する。
  • P2 導入率の計測：対象サービスのうち DS を採用したものの割合を測る。
  • P3 外部貢献数の計測：組織の外からの貢献の件数と推移を測る。
  • P4 縦断設計：同じ組織を複数の時点で追う。
  • P5 対照：統制強度の異なる組織を同時に並べる。
  • P6 因果の識別：統制の変更が結果を動かしたのかを、交絡を除いて示す。

実測が届いている範囲

統制の強度に相当するものは、組織構造の分離として測られている。 製品部門とプラットフォーム組織の分離が納期遅延、欠陥率上昇、コンポーネント重複の根本原因だと、3組織のマルチケース分析が結論した（Riehle, D., Capraro, M., Kips, D., Horn, L. 2016、DOI 10.1109/TSE.2016.2554553）。 期間、データ源、定量指標は未取得である [要一次検証]。 デザインシステムでは、単一組織の導入阻害を76名のインタビューで整理した研究があり、導入率は「uptake has stayed limited」という定性の記述にとどまる [要一次検証]（Richter, K. S., Rüssel, J., Karczewski, K. 2025、DOI 10.1145/3706599.3706705）。 越境する貢献の計測法は定義され、1社では全貢献の 47.9% が組織単位間、42.2% が異なる製品を担当する単位間だったが、測っているのは社内の越境であって外部コミュニティからの貢献ではない（Capraro, M., Dorner, M., Riehle, D. 2018、DOI 10.1145/3196398.3196417）。

縦断の設計は、隣接分野に3件ある。 単一企業のインセンティブ制度を記述的に追った報告はプロジェクト数と参加者数が増えたとするが、数値は図中のみで本文になく、著者自身が因果の確定には無作為化比較試験が必要だと明記している（Dey, T., Jiang, N., Fitzgerald, B. 2022、DOI 10.1109/MS.2022.3192647）。 統制への反応が新規参加者の定着を下げたという縦断ログ分析は、期間、標本、統計手法が未取得である [要一次検証]（Halfaker, A., Geiger, R. S., Morgan, J. T., Riedl, J. 2013、DOI 10.1177/0002764212469365）。 統治の分散宣言と開発の実態の乖離を測った研究は、加重 Gini 0.82、上位1名が 24%、コア約半数が 98.1% という集中を示した（Destefanis, G., Xu, J., Bartolucci, S. 2026、GitHub アクション 6,741件、2020年9月〜2025年2月、DOI 10.1016/j.is.2026.102695）。

産業側の採用台帳は、単一時点か推定値である。 IBM Cloud では155サービスのうち116が Carbon 10 を採用し、残りの21は例外承認により採用しないとされ（IBM Carbon、2021年1月時点、https://v10.carbondesignsystem.com/case-studies/consistency-in-the-cloud/）、同じページの NPS 改善 57% と選好 88% は定義、比較対象、標本、設問が非開示である [要一次検証]。 GOV.UK Frontend の版数トラッカーは6サービスがバージョン5に更新済みという単一時点の値で分母が非開示であり（X-GOVUK、2023-12-20、https://x-govuk.org/posts/govuk-services-frontend-stats/）、GDS の「1,200超」は標本も算出方法も基準日も記載のない推定値である（GDS、https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/）。

計測基盤を持つ組織はあるが、数値は公開されていない。 GitLab は38の基盤コンポーネントを追跡していると記すだけで、ページにある「88%」と「2256/16728」は書式の例示であり実測値ではない（GitLab、https://gitlab.com/gitlab-org/gitlab-design/-/issues/2495）。 Brevo も採用率の実測値を本文に置かず、分母も非開示である（Brevo、https://engineering.brevo.com/how-to-track-design-system-adoption/）。

確認できなかった測定

査読研究の側に、導入率を測ったものが見つからない。 導入率を集計する実務ツールの妥当性を検証した研究も、統制強度の異なる組織を並行して比較した研究も、因果を識別した研究も該当がゼロである。 産業側でも同一組織を追うパネル調査は存在せず、外部貢献数の推移を公開している DS も見つからない。 GOV.UK DS は2025年のコミュニティ目標で貢献量の増加を「TBD」としており目標の値そのものが未設定であり（GOV.UK Design System チーム、https://team-playbook.design-system.service.gov.uk/community/community-objectives/）、計測の不在は隣接分野でも指摘されて、inner source の業務影響の計測は未研究だと系統的レビューが結論している（Buchner, S., Riehle, D. 2023、DOI 10.1145/3611648）。

隣接分野からの移用

移用が成立するのは、境界の定義とログの対応が取れる場合である。 組織境界を越える貢献の計測は、境界の定義を先に固定し、そこを越える変更を追う形で成立している（Capraro, M., Dorner, M., Riehle, D. 2018）。 宣言文書と貢献ログの両方が取れる対象では、統治の宣言と実態の乖離を測れる（Destefanis, G., Xu, J., Bartolucci, S. 2026）。

移用が崩れるのは、測っている貢献の種類が変わる場合である。 越境貢献の計測法が数えるのは社内の越境であり、外部貢献数に読み替えると対象そのものが変わる（Capraro, M., Dorner, M., Riehle, D. 2018）。 前後比較は因果の識別にならず（Dey, T., Jiang, N., Fitzgerald, B. 2022）、単一プロトコルの事例では HHI と統計検定が未取得で（Destefanis, G., Xu, J., Bartolucci, S. 2026）、統制への反応を扱った縦断分析も期間、標本、統計手法が未取得のため機構をそのまま引き写せない [要一次検証]（Halfaker, A. ほか 2013）。

互換維持下の残存期間と修正コストは追跡されているか

判定条件

互換維持を選んだ組織で、旧トークンの残存期間と修正コストを追跡した事例

何を測れば埋まるか

  • P1 旧名の残存期間：非推奨になった名前が実際に使われ続けた期間を測る。
  • P2 非推奨への反応率：告知の後にどれだけの利用者が移行したかを測る。
  • P3 移行の修正コスト：移行に要した変更量と工数を測る。
  • P4 互換を破った場合の実害率：破壊的変更が利用側にどれだけ影響したかを測る。
  • P5 非推奨マーカーの運用：告知、代替の提示、削除時期が守られたかを確かめる。
  • P6 DS を直接対象にした実測：P1 から P5 をデザイントークンで測る。

実測が届いている範囲

残存期間に最も近いのは、パッケージエコシステムの lagging time である。 Android では平均 115 API 更新/月で進化し、クライアントの API 参照の 28% が旧版で、lagging time の中央値は16か月、伝播時間は14か月だった（McDonnell, Ray, Kim 2013、DOI 10.1109/ICSM.2013.18）。 deprecate から replace、remove に至るサイクルもリビジョンをまたいで観察されているが、API 数、アプリ数、期間は本文外で未取得である [要一次検証]（Li, Gao, Bissyandé, Ma, Xia, Klein 2020、DOI 10.1007/s10664-019-09764-z）。

非推奨への反応は、乏しい。 5つの Java API のクライアント 25,000 超と JDK クライアント 60 を追った研究では、クライアントはバージョンを上げず、反応する場合も推奨の代替ではなく削除を選ぶ傾向があった（Sawant, Robbes, Bacchelli 2018、DOI 10.1007/s10664-017-9554-9）。 観測期間と追跡方法は未取得である [要一次検証]。 npm では、収集時点で 27% のクライアントが非推奨リリースを直接採用していた（Cogo, Oliva, Hassan 2022、DOI 10.1109/TSE.2021.3055123）。

修正コストは、移行の差分として計量されている。 Python の335移行を手作業で分類した研究では、移行あたりの変更が中央値8行、使用する API が7つ、最大は758行で、関数呼び出しの単純置換で済むものは 16.4% にとどまる（Islam, Jha, Akhmetov, Nadi 2024、DOI 10.1145/3643731）。 互換を破った場合の実害率も測られ、Maven Central の7年分ではリリースの約3分の1が少なくとも1件の破壊的変更を含み、その割合は minor と major で同じだった（Raemaekers, van Deursen, Visser 2014、DOI 10.1109/SCAM.2014.30）。 別の大規模解析では 83.4% が semver に準拠し、影響を受けたのは全クライアントの 7.9% のみだった（Ochoa, Degueule, Falleri, Vinju 2022、119,879 のライブラリ更新と 293,817 のクライアント、DOI 10.1007/s10664-021-10052-y）。 非 major 更新でも影響は起き、クライアントパッケージの 11.7%、リリースの 13.9% が影響を受け、顕在化した破壊的変更は minor と patch に各 43.75% だった（Venturini, Cogo, Polato, Gerosa, Wiese 2023、DOI 10.1145/3576037）。 復旧までの日数（クライアント134日、プロバイダ7日）は、アブストラクトに記述を確認できない [要一次検証]。

非推奨マーカーの運用は守られておらず、Maven Central ではタグなしで削除が行われ（Raemaekers, van Deursen, Visser 2014）、npm では非推奨リリースを持つパッケージのうち 66% が全リリースを非推奨にしたため置換先へ移れず、部分的非推奨の 31% には置換先がなかった（Cogo, Oliva, Hassan 2022）。

産業側には計画はあるが追跡結果がなく、Backbase は 2025.04 リリースで非推奨トークンを削除し長期サポートを含めて2年の移行期間を置くと告知している（ページ更新 2025-12-04、https://designsystem.backbase.com/latest/design-tokens/value-and-cost-of-migration-YSNi7jJT）。 移行コストは「5日とカスタムジャーニーあたり4時間」といった形で示されるが、すべて Estimated のラベルが付いた見積であり、実測ではない。

確認できなかった測定

デザインシステムを直接対象にした改名と非推奨の実測は、7本の探索語で見つからなかった。 デザインと HCI の文脈でも、DS の変更管理を測った査読研究は見つからなかった。 OpenAlex で design system deprecation を主題にする研究を探しても364件のヒットに該当がなく、旧トークンの残存期間と修正コストの事後実測も見つからない。 Microsoft Fluent の一次証言は、v9 が v8 とのパリティに達する時期について「How long this will take I can’t tell you, that’s a question that has a lot of variables」と述べたもので、並置期間を問われた回答ではない（2022-06-24、https://github.com/microsoft/fluentui/discussions/23183）。 発言者の Microsoft 雇用の明記はページ上にない [要一次検証]。 産業調査でも State of Design Tokens 2024 は節構成のみが公開され、トークンの廃止や移行期間の設問の有無は判定できない。

隣接分野からの移用

移用が成立するのは、依存がバージョン識別子で管理され、参照が静的に取れる場合である。 Android の lagging time は、API の版とクライアントの参照を突き合わせて中央値16か月という値を出し（McDonnell, Ray, Kim 2013）、移行の修正コストも変更が差分として現れる限り同じ単位で数えられる（Islam, Jha, Akhmetov, Nadi 2024）。 非推奨のサイクルがリビジョン横断で観察できるなら、残存期間は分布として測れる（Li, Gao, Bissyandé, Ma, Xia, Klein 2020）。

移用が崩れるのは、識別子が互換性の宣言として機能していない場合である。 破壊的変更を含むリリースの割合が minor と major で同じなら、版の識別子から残存期間を読む前提が崩れる（Raemaekers, van Deursen, Visser 2014）。 移行先が定義されていない場合、残存期間は「移行しなかった時間」ではなく「移行できなかった時間」になる（Cogo, Oliva, Hassan 2022）。 告知があっても、反応する側が推奨の代替ではなく削除を選ぶなら、告知は移行を導かない（Sawant, Robbes, Bacchelli 2018）。

DS 採用と非採用の監査結果は比較できるか

判定条件

DS 採用サービスと非採用サービスのアクセシビリティ監査結果の比較

何を測れば埋まるか

  • P1 採用の同定：どのサービスがどのデザインシステムを使っているかを特定する。
  • P2 非採用群の同定と対照設計：条件の揃った非採用サービスを並べる。
  • P3 監査結果：両群に同じ監査を当てる。
  • P4 実装忠実度：採用したサービスが実際にそのコンポーネントを使ったかを測る。
  • P5 交絡の統制：規模、年代、技術カテゴリなどの差を除く。
  • P6 採用前後の縦断：採用の前後で同じサービスを測る。

実測が届いている範囲

デザインシステムの成果物そのものの評価はある。 大手4社のデザインシステムを WCAG 2.2 の46基準（91基準から DS が担える分を選別）で評価した研究は、不適格なコンポーネントを基準別に数え、1.4.3 が7件、2.5.5 が12件、4.1.2 が6件とした（Diniz & Gama 2024、DOI 10.5753/sbes.2024.3566）。 これは成果物単位の評価であり、採用したサービスの監査結果ではない。

サービス単位で最も近いのは、技術カテゴリを考慮した大規模な自動監査である。 UI frameworks カテゴリでは採用ページが 0.655、非採用ページが 0.672 で（Martins & Duarte 2024、A3 指標で低いほど良い、p<0.001、1,072,937 ページ、DOI 10.1007/s10209-023-01010-0）、調査全体は 2,884,498 ページと 166,311 サイトを対象とし、平均30エラー/ページ、0エラーのページは 0.5% である。 ただし同一カテゴリ内の技術差は最大 0.196 でカテゴリの効果 0.017 を上回り、比較されているのは技術カテゴリの採用と非採用であってデザインシステムの採用ではない。

交絡の整理に近い結果は、公的サーベイにもある。 政府機関の自己申告を集計した評価では、実施指数が5点満点で 1.96、方針が 3.04、調達が 3.44、テストと修復が 2.00 で、実装度が適合を規定し機関の規模は規定しない（米国 GSA、FY2025、212機関の回答のうち60機関が政府全体分析に提出、https://www.section508.gov/manage/section-508-assessment/）。

確認できなかった測定

DS 採用と非採用のアクセシビリティ監査比較は、7本の探索語で見つからず、採用の前後を測った研究も実装忠実度を測った研究もない。 公的監視の側にも、DS 採用を変数に含む監査はない。 英国 GDS の監視報告には design system という語自体が出てこず（1,203のウェブサイトと21のモバイルアプリ、29,787件の問題、簡易テストの適合率 70%、期間 2022-01-01〜2024-09-01、https://www.gov.uk/government/publications/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024）、オランダのダッシュボードには DS や CMS の欄がない（9,101サイト、状態は A 874、B 4,414、C 537、D 2,359、E 917、https://dashboard.digitoegankelijk.nl/）。 日本の総務省調査も DS 採用を変数に持たず、2023年度は miChecker で解析可能な1,208団体の公式サイトの 48.8% に A/AA の問題ページがあり、ガイドラインの活用状況別では 29.2%（活用）から 48.4%（知らない）へ単調に増える（https://www.soumu.go.jp/info-accessibility-portal/webaccessibility/assets/documents/webaccessibility/chosa_houkoku_gaiyou_r5.pdf）。 組織の DS 採用と監査結果を結合できる公的登録簿も、見つかっていない。 WebAIM の技術カテゴリ別集計は、DS 採用の効果として引用できない。 同報告は Web frameworks の Bootstrap を 63.3、JavaScript frameworks の React を 43.5、Astro を 9.0 と記すが（2026年2月、上位100万ホームページ、平均 56.1エラー/ページ、95.9% のページに WCAG 2 の失敗、https://webaim.org/projects/million/）、分類は HTML から検出できる技術シグネチャであって DS 採用の有無ではなく、社内のデザインシステムや GOV.UK Frontend を使うサービスはどのカテゴリにも現れず、出典自身が技術への帰属不能を明記している。 DS 側も自己限界を認め、アクセシブルなコンポーネントを使うことがアクセシブルなサービスを保証しないと記し、VPAT は自コンポーネント44件のみで採用先との比較を行わない（USWDS、出典は既存コーパス source/review/design-system-practices/industry.md）。

隣接分野からの移用

移用が成立するのは、自動監査の検出範囲を先に確定できる場合である。 6種のツールのベンチマークは coverage が最大 50%、completeness が 14〜38%、correctness が 66〜71% という上限を測っており（Vigo, Brown, Conway 2013、テストページ集合と正解基準は未取得 [要一次検証]、DOI 10.1145/2461121.2461124）、カテゴリを揃えた大量標本なら技術採用の小さな差を取り出せる（Martins & Duarte 2024）。 実装度が適合を規定し機関規模は規定しないという整理は、対照群の設計に使える（米国 GSA、FY2025）。

移用が崩れるのは、カテゴリの粒度が DS 採用より粗い場合である。 同一カテゴリ内の技術差が最大 0.196 でカテゴリの効果 0.017 を上回るなら、カテゴリ内の差が DS の効果に重なる（Martins & Duarte 2024）。 技術カテゴリ別の集計は帰属不能だとして出典自身が限定しており（WebAIM 2026）、成果物単位の評価は採用したサービスの監査結果ではない（Diniz & Gama 2024）。 自動監査の coverage が最大 50% である以上、検出されない失敗は比較に現れない（Vigo, Brown, Conway 2013）。

6つに共通する欠け方

個別の空きとは別に、6つの条件を横断して現れる型がある。

1つめは、処置の操作定義が連続量を二分していることである。 動かせる量を採用と非採用、単一と複数、網羅と最小といった2値に切って比較しており、切った後の2群はどちらも内部に幅を持つ。 C1（運用するシステムの数）、C2（一致か不一致か）、C3（語彙数）、C4（統制の強度）、C5（改名か互換維持か）、C6（採用か非採用か）のすべてでこの形が現れる。 C6 では特に、比較されているのが技術カテゴリの採用と非採用であって DS 採用ではない（Martins & Duarte 2024）。

2つめは、時間スケールの欠落である。 縦断の問いを、横断データで答えようとしている。 C1 は反映時間を求めるが測られているのは断面の古さであり（Legay, Decan, Mens 2021）、C4 は推移を求めるが産業側の採用台帳は単一時点か推定値である（X-GOVUK 2023、GDS 2024）。 C5 は残存期間を求めるが対象になった大規模解析はスナップショットで時間の測定記述がなく（Cogo, Oliva, Hassan 2022）、C6 は採用前後を求めるが該当研究がない。

3つめは、帰属の欠落である。 結果が DS 由来か利用側の実装由来かを分離していない。 C6 が最もはっきりしていて、出典自身が技術への帰属不能を明記し（WebAIM 2026）、DS 側もアクセシブルなサービスを保証しないと書く（USWDS）。 C2 では一貫性の効果が画面外観と操作言語で符号を分け（Satzinger & Olfman 1998）、C5 では残存期間が利用側の事情によるものか提供側の設計によるものかを分離していない（Cogo, Oliva, Hassan 2022）。

4つめは、自己選択である。 導入できる能力と結果の差が交絡する。 C4 は自己選択標本の調査しか持たず（zeroheight の n=147、Sparkbox の公募標本）、C6 では採用が無作為化されておらず規模、年代、チーム体制と相関する。 C1 の産業側の比較も、複数システムを運用している組織が名乗り出た標本である。

5つめは、計測主体が当事者で盲検がないことである。 C3 では削減を報告した事例が品質を自チームで判定したと自認し（BILL）、別の事例は販売対象の自社評価である（Figma）。 C4 では採用の内訳以外の指標が定義不明で（IBM Carbon）、計測基盤を記述したページに実測値がない（GitLab）。 C5 ではコストがすべて見積のラベル付きで（Backbase）、C2 では時間計測と盲検が未取得か記載なしである（Satzinger & Olfman 1998、Ozok & Salvendy 2000）。 一方で、判定が処理条件に対して盲検だと明記している例はある（Open Design System Bench）。

6つめは、効果量が測定上限に埋もれることである。 C6 では自動監査の coverage が最大 50%（Vigo, Brown, Conway 2013）、使われたツールが覆うのは WCAG 2.1 の30基準で38% にとどまり（Martins & Duarte 2024）、カテゴリの効果 0.017 が同一カテゴリ内の技術差 0.196 に埋もれる。 C2 では達成率が両条件とも100%に達して時間差が出ず（Opsahl & Sitompul 2025）、C1 では重複の計数が閾値の選択に左右される（Yandrapally, Stocco, Mesbah 2020）。

6つの型は独立ではない。 処置を2値に切ると時間軸が潰れ、時間軸が潰れると帰属も自己選択も分離できなくなる。 DS を直接対象にした実測が2件しかないことも、この連鎖の結果として現れている。

参照文献

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

学術文献

公的機関と標準

産業一次資料

未検証事項

  • C1-01（Lamine & Cheng 2022）の標本件数、C1-02（Sundelin ほか 2024）の観測期間とレビュー参加人数 [要一次検証]
  • C2-01（Satzinger & Olfman 1998）の課題内容、時間計測の有無、盲検の有無 [要一次検証]
  • C2-05（Payne & Green 1989）の標本、独立変数、従属変数、統制（出版社がアブストラクトを非掲載、本文が有料壁）[要一次検証]
  • C2-09（Fitts & Seeger 1953）の参加者数と試行数 [要一次検証]
  • C3-01（Cha ほか 2026）の遵守率の採点手続、評定者、盲検、試行数、統計とトークンの実測値 [要一次検証]
  • C3-07（Zi ほか 2025）の ParEval-OMP における最大 +0.30 [要一次検証]
  • C3-05（Cui 2025）は arXiv の管理注記が別論文とのテキスト重複を指摘し、結論部のモデル数（18）がアブストラクト（19）と一致しない
  • C3-10（Brickify 2025）の数値は、取得した HTML の切断により未取得
  • C4-02（Riehle ほか 2016）の期間、データ源、定量指標（統制、導入率、貢献数、縦断、対照のすべて）[要一次検証]
  • C4-05（Halfaker ほか 2013）の期間、標本、統計手法（本文到達不可）[要一次検証]
  • C4-06（Destefanis ほか 2026）の HHI 値と統計検定 [要一次検証]
  • C4-08（Richter ほか 2025）のインタビュー期間、分析手続、導入率の数値 [要一次検証]
  • C5-01（Sawant ほか 2018）の観測期間、追跡方法、反応までの時間 [要一次検証]
  • C5-03（Li ほか 2020）の API 数、アプリ数、具体期間 [要一次検証]
  • C5-07（Venturini ほか 2023）の復旧までの日数（クライアント134日、プロバイダ7日）[要一次検証]
  • C6-01（Diniz & Gama 2024）は DS 4件と46基準を本ノートの記載の根拠とし、それ以外の採録条件は未取得 [要一次検証]
  • C6-05（Vigo ほか 2013）のテストページ集合と正解基準 [要一次検証]
  • UX Tools の n=2,220 が当該節の母数か全サーベイの値か、回収期間、設問文は非開示 [要一次検証]
  • IBM Carbon の NPS +57% の定義と比較対象、88% の設問、155と116の母集団定義は一次ページに記載がない [要一次検証]
  • Figma Code Connect の LLM judge のモデル名、プロンプト、人手照合の有無、27ケースの選定基準は非開示 [要一次検証]
  • Open Design System Bench の「898 runs」と「+23〜26pt」は README ページに不在。リポジトリ内の別ファイルに存在するかは未確認 [要一次検証]
  • Microsoft Fluent の発言者の Microsoft 雇用の明記はページ上にない（スレッドのラベルは Maintainer）[要一次検証]
  • Sparkbox の Carbon を題材にした DS 有無2条件の比較は、一次 URL を特定できていない [要一次検証]
  • WebAIM の技術同定手法（シグネチャ検出か）は一次ページに記載がない
  • 既存ノート design-system-practices が C5 の立場B として引く「Fluent は並置期間に答えられない」は、出典の発言の範囲を超えている。本ノートはこの証言を、v9 の v8 パリティ到達時期についての発言として限定して扱った

← Notes 一覧 ・ ホーム