追補ノート（2026年4月18日）
本連載は2026年4月16日に執筆を完了したのですが、公開準備を進めていた翌17日、Anthropic Labs から Claude Design が発表されました。連載で論じてきた「AIがデザインシステムを読む時代」が、製品として具体化した瞬間です。
この発表を受けて、連載に 第6回「追補 — 予測が実装になった一週間」 を書き下ろしました。第1〜5回の本文は執筆時のまま残し、「予測が実装に追い抜かれた瞬間」の記録として公開します。
美しい文書が、静かに腐る
ここまでの4回で、DESIGN.md の可能性を見てきました。デザイナーの審美眼が言葉に結晶する場所であること。Linear の weight-510 や Stripe の weight-300 のように、ビジュアルの選択がビジネスの選択と地続きであること。Spotify が三層アーキテクチャで再構築に成功し、Indeed が4,300のプロトタイプを量産していること。
しかし、最終回ではあえて地味な話をします。
どんなに美しく書かれた DESIGN.md も、運用されなければただのテキストファイルです。そして運用を怠った DESIGN.md は、美しいまま静かに腐り、やがてプロジェクトに害をなし始めます。
今回は、DESIGN.md を「生きた文書」として維持するために知っておくべき現実——staleness（陳腐化）の恐ろしさ、AI が従える命令量の限界、チームでの運用ルール——を整理します。華やかさのない話ですが、ここを押さえないと、第1回から第4回までの話はすべて絵に描いた餅で終わります。
Staleness：AI は古い情報を疑わない
DESIGN.md の最大の敵は、陳腐化です。
人間のデザイナーは、ドキュメントが古いことに気づく能力を持っています。「このガイドライン、半年前に更新されたきりだな。今のブランドカラーと違うかもしれないから、実物を確認しよう」——と、経験ある人間は無意識にそうする。
AI にはこの能力がありません。DESIGN.md に書いてあることを、AI はそのまま信じます。
たとえばブランドカラーが3ヶ月前に #2A6FDB から #1E4FA3 に変わっていたとしても、DESIGN.md に古い値が残っていれば、AI は旧カラーで新しい画面を生成し続けます。廃止したコンポーネント名が残っていれば、AI はそのコンポーネントを自信を持って使おうとします。しかも AI は「これは古い情報かもしれません」とは言わない。正しいと確信した顔で、間違った UI を量産します。
この問題は、AI が賢くなればなるほど深刻になります。性能の低い AI は指示を無視することがありますが、性能の高い AI ほど DESIGN.md の記述に忠実に従います。つまり優秀な AI ほど、古い DESIGN.md に引きずられる。
デザインシステムの保守負担が小さくないことは、Romina Kavcic 氏の観察が示す通りです。彼女はデザインシステムチームの時間のうち 30〜40% が純粋な保守作業——アクセシビリティ回帰、トークンの誤用、ドキュメントと実装の乖離——に費やされていると述べています。AI を導入しても、この保守が追いつかなければ、乖離は加速するだけです。
Instruction Budget：全部を書こうとしない
もうひとつの現実は、AI が一度に従える命令量には上限があるということです。
HumanLayer が提唱する "instruction budget"（命令予算）の概念によれば、命令予算はコンテキストウィンドウのサイズとは独立した、モデルごとの「指示追従性の限界」を指します。そして HumanLayer 創業者 Dexter Horthy 氏は、Heavybit のインタビューで「フロンティアクラスの LLM が一貫して従える命令数はおおよそ 150〜200 が上限」という経験則を紹介しています。しかもこの数字は DESIGN.md 単体のものではなく、AGENTS.md や CLAUDE.md、システムプロンプト、ツール定義、MCP サーバーから流れ込む命令など、コンテキスト全体に含まれる命令の合計です。
AI エージェントのコンテキストにおける命令予算の概念図。DESIGN.md、AGENTS.md、CLAUDE.md の合計で約 150〜200 命令が上限。超えると、後から読み込まれた命令ほど無視されやすい。
命令数の増加に伴う性能劣化は、モデルの規模や推論能力によっても変わりますが、小規模モデルほど早い段階で、命令の取りこぼしが急速に顕在化するとされています。つまり、DESIGN.md に200行の Do's and Don'ts を書いたら、後半はほぼ無視される可能性がある、ということです。
HumanLayer のLong-Context Isn't the Answerが指摘している通り、コンテキストウィンドウが 200k や 1M に拡張されても、この問題は解決しません。むしろ「干し草の山が大きくなっても、針のサイズはそのまま」——関連する命令を見つけ出す難易度は、コンテキストが膨らむほどに上がります。この制約を克服するには、別記事Advanced Context Engineering for Coding Agentsで提示されている frequent intentional compaction（意図的な頻繁な圧縮）——文脈窓の利用率を 40〜60% に抑えながら、必要な情報だけを継続的に組み直す手法——のような規律が要求されます。
第4回で紹介した Spotify の三層アーキテクチャが「Foundations だけを常時読み込み、コンポーネント詳細は MCP でオンデマンド提供」という設計を選んだのは、まさにこの制約への対応です。
実務上のルール：DESIGN.md は短く保つ。目安として、9つのセクションすべてを合わせてもA4で3〜4ページ程度に収める。それ以上になったら、コンポーネント詳細を別ファイル（references/ ディレクトリなど）に切り出し、DESIGN.md 本体は Foundations（色、タイポ、間隔、基本原則、Do's and Don'ts）だけに絞る。
トラストレベル：AI にどこまで任せるか
DESIGN.md を導入すると、AI エージェントがデザインシステムに基づいて UI を生成し始めます。便利ですが、ここで必ず決めておかなければならないことがあります。AI にどこまでの判断を任せるか。
Romina Kavcic 氏が Into Design Systems カンファレンスで提示し、Sil Bormüller 氏が解説記事で紹介したトラストレベルの整理が実務的で分かりやすいので、取り上げます。Romina 氏はこの階層を「チームメンバーのキャリア・プログレッション」になぞらえています。
Auto-merge（自動マージ）
AI が判断し、人間の承認なしに実行して良い範囲。DESIGN.md の typo 修正、ドキュメントの誤字脱字、アクセシビリティラベルの追加など、間違えても被害が小さく、正解が明確なもの。
Draft PR（ドラフトPR）
AI が変更案を作り、人間がレビューしてから適用する範囲。トークン値の微調整、コンポーネント説明のリライトなど、正解が一つとは限らないが、方向性は AI に任せられるもの。
Suggest only（提案のみ）
AI は提案を Issue として起票するだけで、実際の変更は人間が行う範囲。新規コンポーネントの追加、色トークンの変更、破壊的変更、ガバナンスに関わる意思決定など、ブランドの根幹や API 互換性に関わるもの。
Romina 氏は、このフレームワークのポイントを「エージェントごとではなく、アクションごとに信頼度を定義する」と整理しています。同じ AI でも、タイポ修正には信頼して任せ、トークンの破壊的変更には自動実行を許さない。この粒度の使い分けがないと、「なんとなく AI に任せる」状態が常態化し、どこかで事故が起きます。
なお Romina 氏は自身のThe Self-Healing Design Systemにおいて、この整理をさらに「低リスク×高確信なら Auto-merge」「低リスク×低確信なら Draft PR」「高リスクは常に人間レビュー」「未知なら学習と提案」という4段階の decision matrix として精緻化しています。本稿では実務導入のしやすさを優先し、Bormüller 氏が紹介している3段階版をそのまま採用しました。
GitHub の Primer デザインシステムでは、エージェントが Issue を起票することしかできないよう構造的に制限し、日次の QA とメンテナンスのワークフローは常に「人間のレビューを要する safe outputs」として設計されている、という事例も紹介されています。
このレベル分けは、プロジェクトの規模や文化によって調整するものです。重要なのは「なんとなく AI に任せる」ではなく、チーム内で明文化し、合意しておくこと。これは AGENTS.md や CLAUDE.md に書いておくべき項目です。
DESIGN.md を「生きた文書」にする5つの儀式
陳腐化を防ぎ、命令予算を守り、トラストレベルを維持するために、以下の5つの運用ルールを提案します。ここに書くのは筆者（unType）が受託・自社プロダクト双方の実務で有効と考えているパターンであり、現場の規模や文化に合わせて調整してください。華やかさはありませんが、これが DESIGN.md の生命線です。
儀式1：コード変更と同じPRで更新する
トークンやコンポーネントに変更を加えたとき、DESIGN.md の該当箇所も同じプルリクエストで更新します。「後で直す」は「永久に直さない」の同義語です。コードの変更と DESIGN.md の更新がセットになっていなければ、PR を承認しない——というルールにするのが最も確実です。
儀式2：四半期の棚卸レビュー
3ヶ月に一度、DESIGN.md を最初から最後まで通読し、実際の CSS と照合します。実装との乖離がないか、廃止されたコンポーネントが残っていないか、Do's and Don'ts の記述が現状と矛盾していないか。地味ですが、この棚卸が staleness を防ぐ最後の砦です。
儀式3：一人の所有者を決める
DESIGN.md にはオーナーを明示的に決めます。全員が少しずつ直す運用は、全員が誰かがやると思って誰もやらない運用になりがちです。オーナーは DESIGN.md への変更 PR のマージ権を持ち、四半期レビューの実施責任を負います。
儀式4：CI で鮮度を監視する
DESIGN.md の最終更新日が90日以上前になったら、CI が警告を出す仕組みを入れます。技術的にはシンプルな Git hook で実現できますが、この自動警告があるだけで「放置されている」ことへの気づきが生まれます。
この発想を一歩進めたものが、Romina Kavcic 氏の提唱するセルフヒーリング・デザインシステムです。IBM が autonomic computing イニシアチブ（2001年開始、2003年の Kephart & Chess 論文で学術的に定式化）の中で提唱した MAPE-K コントロールループ（Monitor / Analyze / Plan / Execute with Knowledge）というアーキテクチャをデザインシステムに適用し、Figma API・CI フック・利用分析からのシグナルをドリフト・スコアリング・エンジンに流し込み、不整合を検出したら自動で PR を作るという構想です。一気通貫のパイプラインを最初から作る必要はなく、「意味のレイヤー間の整合性を検証する」ことから始めれば十分、というのが彼女の助言です。
儀式5：変更理由を必ず書く
DESIGN.md の PR には、何を変えたかだけでなく、なぜ変えたかを必ず書きます。「色を #2A6FDB から #1E4FA3 に変更」だけでなく、「ブランドリフレッシュに伴い、より落ち着いたトーンに寄せるため変更。Marketing チームの承認済み（Slack #design-system 2026-04-10）」のように。
この習慣は、DESIGN.md そのものよりも長く生きる資産になります。なぜなら Git の履歴に残るからです。1年後に「なぜこの色になったのか」を追えるかどうかは、この一手間にかかっています。
一次情報で検証する規律
第1回で見た cv01（数字の1の代替形）と ss03（丸い引用符）の事例を、もう一度だけ思い出してください。awesome-design-md の書き手が「タイポグラフィの根幹」と断じた機能が、実際には微細な変更だったという話です。第3回で触れた Stripe の HEX 値のズレ（観察値 #061b31 / #533afd vs 公式 #0A2540 / #635BFF）も、同じ系統の教訓でした。
この教訓は、運用においても常に付いて回ります。
外部の DESIGN.md を参考にするとき。AI に DESIGN.md のドラフトを生成させるとき。AI にデザインの意図を解説させるとき。書かれている「なぜ」を、一次情報で検証する工程を省略してはいけません。
具体的には、公式ドキュメントを確認する。実際のサイトの CSS を見る。ブランド担当者に質問する。AI の解説が「もっともらしい」ほど、検証は怠りやすくなります。しかし「もっともらしい」ことと「正しい」ことは、別のことです。
この検証の規律は、AI 時代のあらゆる仕事に通じます。しかしとりわけデザインシステムにおいては、検証されなかった誤りが、AI を通じて大量のUIに複製されるという増幅リスクがあるため、重要度が際立ちます。
デザイナー・エンジニア・AI が同じ文書を読む時代へ
この連載の冒頭で、こう書きました。「敵は AI ではなく、凡庸」だと。
5回を通じて見てきたのは、その凡庸と戦うための道具立てでした。DESIGN.md は、デザイナーの審美眼を言葉に結晶させる場所であり、AI エージェントに「どう見えるべきか」を伝える設定ファイルであり、エンジニアとの共通言語であり、そして正しく運用されなければ静かに腐るテキストファイルでもある。
しかし最も大切なことは、道具の話ではありません。
DESIGN.md は、あなたが普段何を見て、何に触れ、何を読んできたかの鏡です。そこに置ける言葉の解像度は、あなたのインプットの厚みに比例します。Linear の書き起こしを読んだとき、-1.584px を「工学的」と呼べた書き手の語彙は、フォントに関する膨大な経験から生まれています。Stripe の影を「薄暮の空」と表現できた書き手の語彙は、光と色についての蓄積から生まれています。
AI は平均値を生成します。その平均値を見抜き、「ここはこうあるべきだ」と方向を示せるのは、平均から外れたものを大量に見てきた人間だけです。
美術館に行くこと。古典を読むこと。映画を観ること。建築を歩くこと。工芸に手で触れること。それらの蓄積が、AI 時代にむしろ希少価値を上げていく。DESIGN.md はその蓄積を「チームで共有可能な形」に変換する装置です。
この連載の次に
この連載は、DESIGN.md というフォーマットを起点に、「AI 時代のデザインシステムとは何か」を5回にわたって探索してきました。
しかしこれは、始まりに過ぎません。
ここで見てきた話の多くは、自社プロダクトのデザインシステムを前提にしています。では、受託制作において——クライアントのブランドを預かり、DESIGN.md を書き、AI と協働しながら成果物を納品する——という文脈では、何が変わるのか。顧客とどのようなコミュニケーションを取れば、新しい時代のデザインシステムが活きるのか。
それは、次の機会に掘り下げたいテーマです。
そしてもうひとつ。この連載を通じて繰り返し触れた「インプットの厚み」——審美眼を鍛える具体的な方法についても、別の機会に書いてみたいと考えています。
最後の小さな実験
連載の最後に、ひとつだけ。
あなたが今関わっているプロジェクトの DESIGN.md を、今日から書き始めてみてください。
完璧でなくていい。9つのセクションを全部埋めなくていい。まず第一セクション「Visual Theme & Atmosphere」を、3〜5行だけ書いてみる。そのプロダクトが世界の中でどういう"表情"をしているのか。顧客にどう感じてもらいたいのか。
AI にドラフトを任せてもいい。第4回で紹介した Katherine Yeh 氏が実践しているように、「このブランドのデザイン原則を書いて」と Claude に話しかけてみる。返ってきた文章を読んで、「ここは違う」「ここはもっとこうだ」と直す。その「直す」行為の中に、あなたの審美眼のすべてが詰まっています。
そしてその文章が、デザイナーにもエンジニアにも AI にも読めるものになったとき——それは、顧客にも読める言葉になっているはずです。
あなたのブランドを、あなたの言葉で。
参考文献
Into Design Systems: Your Design System Is Not Ready for AI Agents — Sil Bormüller 著。Romina Kavcic / Diana Wolosin / Jan Six など複数の発表者の知見を統合した解説。3段階のトラストレベル（Auto-merge / Draft PR / Suggest only）、ドキュメントドリフト、30〜40% 保守負荷の一次出典
Romina Kavcic: The Self-Healing Design System — トラストレベルを career progression になぞらえた整理（自著では4段階の decision matrix として精緻化）と、IBM MAPE-K を応用したセルフヒーリング・デザインシステムの提唱
Romina Kavcic: Should you build an agent for your design system — エージェント導入の判断基準（決定性、監査性、再現性、説明可能性）
Romina Kavcic: Design systems team structure in 2026 — 3人チームが 10人チームを上回る AI 時代のチーム構造論
GitHub Primer Design System — エージェントが Issue 起票のみに制限された安全な AI 運用の事例
HumanLayer: Long-Context Isn't the Answer — "instruction budget" 概念の定義。コンテキストウィンドウが拡張されても命令追従性は比例して向上しないことを実証
Heavybit: What's Missing to Make AI Agents Mainstream? — HumanLayer Dexter Horthy 氏インタビュー。「フロンティアクラスの LLM が一貫して従える命令数はおおよそ 150〜200」の数値出典
HumanLayer: Advanced Context Engineering for Coding Agents — frequent intentional compaction（意図的な頻繁な圧縮）の実践的研究。文脈窓の 40〜60% 利用で最良の結果を得る手法
Anthropic Engineering: Effective context engineering for AI agents — コンテキスト・エンジニアリングの Anthropic 公式ガイド
Wikipedia: Autonomic computing — IBM が 2001年に提唱した autonomic computing と、その中核概念である MAPE-K コントロールループ（2003年の Kephart & Chess 論文で学術的に定式化、2005〜2006年の IBM Architectural Blueprint で実装指針を公開）。20年以上にわたりサーバーファームやクラウドプラットフォームで運用されてきたアーキテクチャ
この記事をシェアする
