Claude Code や Cursor などの AI コーディングエージェントに「見栄えのいいスライドを作ってほしい」「管理画面の UI モックを組んでほしい」と指示を出したとき、返ってきた画面を見て頭を抱えた経験はないでしょうか。頼んでもいないサイバー空間のような虹色グラデーションが敷き詰められ、1 画面の中に 8 種類ものフォントサイズが乱立し、ボタンごとに角丸や余白のルールがバラバラになっている ── そんな「過剰に飾り立てられた生成物」を手作業で深夜に直す羽目になるケースは珍しくありません。

AI に自然言語で「センスよく」「シンプルに」と指示しても、モデルにとっての「いい感じ」は統計的な平均や学習データの派手な装飾に引きずられがちです。こうしたデザインのブレを抑え、エージェントに一定の視覚秩序を守らせるための仕様として、近年 Google Labs が提唱する DESIGN.md 1 2 が注目を集めています。DESIGN.md とは、AI コーディングエージェントに対して色・タイポグラフィ・余白・コンポーネントなどの視覚設計ルールと設計意図を永続的かつ構造化して伝えるための仕様です。

しかし、実務でいざ自前で DESIGN.md を書こうとすると、大きな壁に突き当たります。「ベースカラーとアクセントカラーのコントラスト比はどう設定すべきか」「見出しと本文のフォント階層は何段階が適切か」「余白の基準単位はどうするか」といった設計ルールを一から言語化し、保守し続ける作業は、デザイン専任ではないエンジニアやテックリードにとって過大な負担となります。

そこで私が提案したいのが、「センスを AI に求めるのをやめ、すでに国が徹底的に引き算して完成させた公開デザインシステムの Markdown をそのまま AI の設計図として転用する」というアプローチです。自前でゼロから DESIGN.md を書く代わりに、デジタル庁デザインシステム（略称: DADS）が公式配布している Markdown ドキュメントを入力として活用することで、労力を最小限に抑えつつ、堅牢な視覚的ハーネスを AI に与えることができます 3。

なぜ DADS の Markdown なのか：実務での選択理由

世の中には多くのデザインシステムが存在しますが、なぜ AI エージェントの「設計図」としてデジタル庁デザインシステム（DADS）が極めて優れているのでしょうか。その理由は、配布形態、利用規約、そしてルールが持つ「引き算の客観性」の 3 点にあります。

第一に、公式による Markdown ファイルの一括配布 です。デジタル庁は 2026 年 7 月 8 日より、ウェブサイトを構成する全ドキュメントおよびアクセシビリティガイドラインの一式を Markdown 形式の ZIP アーカイブとして公式に配布しています 4 5。2026 年 9 月 9 日版のアーカイブには 145 ファイルが含まれており 4、サイトの更新に合わせて定期的に最新版が提供されています。Figma や Storybook などの人間向けツール、あるいはデザイントークンの JSON 定義だけでは、AI エージェントに「なぜそのルールを守るのか」という設計意図を伝えるのが困難です 1。DADS のドキュメントは、背景の解説と具体的な数値定義が一体となった Markdown であるため、LLM がそのまま解釈するコンテキストとして極めて扱いやすい性質を持っています。

第二に、公的機関ならではの利用許諾の明快さ です。DADS は「公共データ利用規約（第1.0版）」（略称: PDL1.0、クリエイティブ・コモンズ・ライセンス CC BY 4.0 互換）に基づいて提供されています 6。商用・非商用を問わず、自由な複製、公衆送信、翻案が認められています。DADS の利用上の注意事項によると、コンテンツを編集・加工等して利用する場合は、出典の記載（例: 「出典：デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/」）に加えて、加工した旨（例: 「デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/ のコンテンツを加工して作成」）を明記することが求められています 7。法的な利用条件がクリアであることは、業務利用において不可欠な前提条件です。

第三に、スライドや UI に即座に効く 「3 つの客観ルール」 の存在です。DADS の最大の特徴は、華美な装飾を足すことではなく、アクセシビリティを確保するために要素を極限まで引き算している点にあります。この引き算の思想が、AI 特有の過剰な装飾癖を抑え込む強力なブレーキとして機能します。

  1. 余白 3 段階: DADS では余白の基準単位を 8 CSS px と定義しており、スタイルガイドの実装例として 8 CSS px（等倍）、24 CSS px（3 倍）、64 CSS px（8 倍）の 3 段階スケールが例示されています 8。余白を「なんとなく空いたスペース」ではなく、要素同士の論理的な近接度（グルーピング）を表す 3 種類の道具として AI に固定させることで、画面全体の整列感を保ちやすくなります。
  2. 文字 5 段階: DADS のタイポグラフィ定義では、フォントに Noto Sans JP を採用し、フォントサイズを Display（48〜64px）、Standard（16〜45px）、そして 14px 未満は原則不許容という明確な基準を設けています 9。DADS はこの範囲の中に多数のスタイルトークンを定義しており、スライドでどれを使うかは使う側が選びます。テツメモ氏はスライドへの転用にあたり、この範囲から表紙タイトル（48px）、大見出し（36px）、小見出し（24px）、本文（20px）、注釈（14px）の 5 段階を選んでいます 3 10。段数を限定して AI に渡すことで、場当たり的な文字サイズ変更を抑えられます。
  3. コントラスト比の客観判定: DADS では、テキストと背景色のコントラスト比を常に 4.5:1 以上、図形や枠線などの非テキスト要素は 3.0:1 以上を維持することが定められています 11。たとえばスライドのアクセントに目立つ黄色（#fbd212）を使おうとしても、白背景に対するコントラスト比は 1.47:1 しかないため機械的に不合格となります。その結果、可読性を担保できる濃い青（#155585、コントラスト比 7.87:1）を選ばざるを得なくなります 3。個人の「好み」ではなく「客観的な数値基準」によって AI の配色を決定できるのが、この規約の強みです。

自前でルールを一から作るアプローチと、既存の公開デザインシステムを転用するアプローチを比較すると、初期コストとアクセシビリティ担保の面で大きな差が出ます。

比較軸自前でゼロから DESIGN.md を書くDADS の Markdown を設計図として転用する
初期作成コスト高い（色・余白・フォントの値を一から選定し言語化する）低い（値をゼロから決める判断は不要。使う段の選択と要約ファイルの作成は残る）
客観性・アクセシビリティ個人の主観に依存しがち（コントラスト比等の漏れが発生）公的な基準として明文化済み（テキスト 4.5:1 / 非テキスト 3.0:1）
メンテナンス性自前で更新・管理し続ける負担がある公式が定期更新（サイト更新に同期して追従）
AI エージェントへの適合書式や構造の試行錯誤が必要公式が Markdown で配布しており、要約の素材としてそのまま使える

自前でのデザインルール策定にリソースを割けない現場ほど、公的機関が磨き上げた規約を借りることで、すぐに客観的な品質基準を手に入れることができます。

筆者も DADS の値を要約した設計ルールを AI に渡して資料を作ってみました。仕上がりはすっきりとした読みやすい資料で、同じ内容を単純に要約した文章を読むよりも数段わかりやすいと感じました。

実際に Claude Code などのツールで DADS を参照させる実践も始まっています。たとえば、Codex や Claude Code から DADS のドキュメントを直接参照して UI 生成やレビューを行う非公式 Agent Skill（apply-digital-agency-design-system）の実装事例 12 も報告されており、エージェントのハーネスとして外部デザインシステムを外付けする構成が現実的な選択肢となっています。

DADS の基本トークンを凝縮した最小の DESIGN.md 設定例

DADS を渡すといっても、145 ファイルをそのまま読ませるわけではありません。省けるのは値をゼロから決めて言語化する設計判断であり、それを DESIGN.md の形に要約する作業は残ります。Google Labs が提唱する DESIGN.md のフォーマットに合わせて要約したファイルを用意するのが効果的です。以下は、スライドや UI モックの作成に必要なエッセンス（余白 3 段階、文字 5 段階、コントラスト比）を抽出し、Google Labs の Token Schema に準拠させた最小構成の例です。

---
name: DADS-Minimal
colors:
  primary: "#155585"
  background: "#FFFFFF"
typography:
  display:
    fontFamily: Noto Sans JP, sans-serif
    fontSize: 48px
  heading-lg:
    fontFamily: Noto Sans JP, sans-serif
    fontSize: 36px
  heading-sm:
    fontFamily: Noto Sans JP, sans-serif
    fontSize: 24px
  body:
    fontFamily: Noto Sans JP, sans-serif
    fontSize: 20px
  caption:
    fontFamily: Noto Sans JP, sans-serif
    fontSize: 14px
spacing:
  sm: 8px
  md: 24px
  lg: 64px
---

## Overview

デジタル庁デザインシステム（DADS）の基本原則に基づく、スライドおよび UI 生成向けの最小構成ルール。

## Colors

- **Primary (#155585):** コントラスト比 7.87:1 の濃い青。見出しと主要テキストに使用。
- **Background (#FFFFFF):** 白背景。
- テキストと背景色のコントラスト比は常に 4.5:1 以上、図形・枠線は 3.0:1 以上を維持する。

## Typography

- フォントファミリーは原則として `Noto Sans JP` を使用。
- 文字サイズは 48px, 36px, 24px, 20px, 14px の 5 段階に限定し、14px 未満は使用しない。

## Spacing

- 基本単位は 8px。
- 余白スケールは sm (8px), md (24px), lg (64px) の 3 段階のみを使用する。

このファイルはプロジェクトルートに置いただけでエージェントに自動で読み込まれる保証はないため、生成を指示するときにこのファイルを参照するよう明示します。参照させれば、エージェントは YAML フロントマターから数値トークンを、Markdown 本文のセクションから「なぜその数値を使うべきなのか」という設計意図を受け取ってコードやマークアップを生成できます。

メリットの裏にあるトレードオフと適用限界

公開デザインシステムを AI の設計図として転用する手法は非常に強力ですが、銀の弾丸ではありません。実務で運用する上では、避けて通れない 3 つのトレードオフと適用限界が存在します。

1. 145 ファイル丸ごと投入の罠（エッセンスの抽出）

「公式が 145 ファイルの Markdown を配っているなら、リポジトリに丸ごと放り込んで AI に読ませれば完璧なのではないか」と考えるかもしれません。しかし、これは明確なアンチパターンです。

145 ファイルもの膨大なドキュメント群をプロンプトやコンテキストに無差別に投入すると、コンテキスト長や実行コストを大きく浪費します。それ以上に深刻なのは、大量のコンテキストによってモデルの推論が圧迫され、指示同士が競合しやすくなる点です。ウェブサイト向けの細かなアクセシビリティチェック項目や個別コンポーネントの仕様が混ざることで、肝心のスライド全体のレイアウトや文字サイズといった大枠のルールが無視されやすくなります。

プロンプトやコンテキストで与えるルールは、先述の例のように「文字・余白・色などの最小限のエッセンス」に絞って渡すべきです。詳細なドキュメントは必要になったタイミングで個別に参照させるか、基本的なデザイントークンのみを凝縮して渡すのが、モデルの性能を引き出すうえで現実的です。

2. 予防と検収の分離（楽譜と演奏の品質管理）

どれほど完璧な設計図を与え、プログラムによる静的チェックをパスしたとしても、最終的な描画崩れをプロンプトだけで 100% 防ぐことは不可能です。

テツメモ氏の X 投稿 3 では、DADS のルールに基づいてスライドを生成し、文字のはみ出しや色のコントラストを機械的に判定する自動検査プログラムで「ALL GREEN（全項目合格）」を出したスライドであっても、実際に PowerPoint（.pptx）形式に変換してアプリで開いた瞬間、5 箇所の重大な描画崩れ（文字あふれ、行の重なり、カード要素の重複など）が発生したと報告されています。

同投稿によれば、これは、プログラムが検査していた「ファイルを生成した時点の静的な枠高」と、実際の PowerPoint アプリが文字を描画した際の「フォントや折り返しによる動的な枠の伸長」との間に乖離があったためです。さらに、文字列生成ロジックの重複バグなども重なっていました。

ここから得られる極めて重要な教訓は、「楽譜（設計図）のテストと、演奏（実物）の品質管理は絶対に切り離して運用しなければならない」 ということです 3。ルールによる予防（プロンプトや静的リント）だけですべてを守ろうとしてはいけません。生成されたスライドを画像化し、人間の目で最終的なレンダリング結果を確認する「検収ステップ」を、自動化パイプラインの中に独立した関所として組み込む必要があります。テツメモ氏が配布するスライド制作キットも、PowerPoint で実際に開いて画像へ出し、渡す前に実物を見る手順を残しています 10。

3. 指示出しの摩擦解消（座標指示・視覚フィードバック）

AI にスライドや UI を修正させる際、最もフラストレーションが溜まるのが「直したい箇所の指示出し」です。「3 枚目のスライドの、右上のカードの中にある数字をもう少し大きくして」と自然言語で作文するのは人間にとっても負担であり、AI が別の要素と取り違えて意図しない変更を加える原因になります。

この摩擦を解消する実践的なアプローチが、テツメモ氏が提案した「赤枠レビュー盤」のように、画像上で直したい領域を座標 [x: 620, y: 340, w: 200, h: 80] としてバウンディングボックスで指定する手法です 3。

言葉による曖昧な指示を排し、視覚的な要素・マークで直接指示を与えるというアプローチは、Microsoft Research が発表した Set-of-Mark Prompting（arXiv:2310.11441） 13 14 や、Web 要素の座標・セレクタを抽出してエージェントに渡す benjitaylor の agentation 15 など、近年のマルチモーダル AI に対する視覚的グラウンディング（Visual Grounding）の研究やツール群の発想とも通じるものがあります。人間と AI の協業においては、「言葉で説明し尽くそうとするのではなく、視覚的な記号や座標で指示を伝える」プロセスの設計が鍵を握ります。

前提が変われば結論はどう変わるか

ここまで述べてきたアプローチは、現在の AI エージェントのコンテキスト処理能力やツールの発展状況に基づいたものです。今後の技術環境の変化によって、この結論はどのように変わり得るでしょうか。

第一に、llms.txt や AI 向けインデックスの標準化 です。現在、DADS のサイトには llms.txt は存在せず、一括 ZIP アーカイブによる配布形態をとっています。しかし今後、ウェブサイトやデザインシステムにおいて AI 向けインデックス標準（llms.txt 等）の整備が進めば、145 ファイルを一括ダウンロードして手元で要約する手間は不要になります。エージェントが必要なコンポーネント仕様やトークン定義だけをオンデマンドで自律的に取得・参照する設計へとシフトしていくはずです。

第二に、デザインシステムを「社内資産」から「AI が共通参照する公共資産」へ捉え直す動きの広がり です。SmartHR は「情報をオープンにすることは、私たちの間で無用な齟齬・苦労を避けるだけでなく、社会にも“車輪の再発明”を減らすなど、良い影響をもたらす」という運営理念のもとでデザインシステムを公開しています 16。企業ごとにバラバラなデザイン規約をゼロから策定するのではなく、公開された優れたデザインシステムを共通の「型」として AI に参照させ、差分となるブランドカラーやロゴだけをオーバーライドするようなアーキテクチャが一般化していくと考えられます。

第三に、メディア間のアダプテーション（翻案）の前提 です。忘れてはならないのは、DADS の本来の射程はウェブサイトおよび Web アプリケーションであり、スライド専用に作られたものではないという事実です。スライドにはプロジェクター投影時の視認性や、16:9 の固定アスペクト比といった固有の制約が存在します。Web 向けの規約を別メディアへ転用しているという前提を常に意識し、媒体ごとの特性に応じた適切なチューニングを行う姿勢が求められます。

まとめ

公開デザインシステムを AI の設計図として転用する実践の要点は以下の通りです。

  • AI にデザインの「センス」を求めるな: 曖昧な自然言語プロンプトは装飾の過剰と出力のブレを招く。公的機関の規約を入力として与え、引き算のルールで統制する。
  • 自前で DESIGN.md をゼロから書く必要はない: DADS などの公開 Markdown 資産から、余白・文字・色の基本トークンを借りて設計図を仕立てるのがいちばんの近道である。
  • 全ファイルを投入せず、エッセンスに絞れ: 145 ファイルあるドキュメントを丸ごと投入すると推論を圧迫する。スライドや UI に必要な基本トークンに絞ってコンテキストを渡す。
  • 予防と検収を分離せよ: ルール（楽譜）が ALL GREEN であっても、アプリ描画の実物（演奏）ではフォントや動的伸長による崩れが起こる。実物の画像目視検収を独立した関所として配置する。
  • 指示は言葉ではなく座標や視覚マークで出せ: 位置の作文を排し、赤枠やバウンディングボックスによる指示でエージェントとの齟齬を無くす。

よくある質問（FAQ）

Q. デジタル庁デザインシステム（DADS）を商用スライドや自社 UI に使っても規約上問題ありませんか？

A. 結論として、出典の明記および加工した旨の明記を行うことで、商用・非商用を問わず自由に利用・翻案が可能です。

DADS は「公共データ利用規約（第1.0版）」（CC BY 4.0 互換）に基づいて配布されています。ドキュメント（Markdown）を加工・編集して自社の設計ルールやスライドに転用する場合は、利用上の注意事項に従い、出典の記載（例: 「出典：デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/」）と、加工した旨（例: 「デジタル庁デザインシステムウェブサイト https://design.digital.go.jp/dads/ のコンテンツを加工して作成」）の両方を記載してください。

Q. DADS の Markdown ファイル（145 ファイル）をすべて Claude Code に読み込ませるべきですか？

A. 結論として、すべてのファイルを読み込ませるべきではありません。

145 ファイル全体を無差別に読み込ませると、コンテキスト長の浪費や推論の指示競合を引き起こし、かえって出力の品質が低下します。スライドや UI モックの作成に必要な「余白 3 段階」「文字サイズ 5 段階」「カラー・コントラスト比」などの基本ルール・トークンのエッセンス（本記事で紹介した DESIGN.md のような要約ファイル）に絞って渡すのが最も効果的です。

開発プロセスの標準化、AI エージェントを活用したデザインシステム連携や AI Operations の導入設計について、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. DESIGN.md - AIコーディングエージェントのためのデザインシステム仕様 yamitake、2026年4月28日公開。二層構成のアーキテクチャ解説、Figma/JSON トークンの課題と解決。 ↩ ↩2

  2. google-labs-code/design.md Google Labs、2026年公開（v0.1.0 alpha）。AI コーディングエージェント向け二層仕様、npx lint CLI、WCAG AA 検査ルール。 ↩

  3. テツメモ｜AI図解×検証｜Newsletter on X (2026-09-20) テツメモ、2026年9月20日公開。DADS のスライド転用、固定 5 段階文字、余白 3 段階、コントラスト比検証、赤枠レビュー盤。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. リソース｜デジタル庁デザインシステムβ版 デジタル庁、2025年2月28日更新。ドキュメント（Markdown）2026年9月9日版 ZIP 配布の事実、同梱アセット。 ↩ ↩2

  5. お知らせ（その他）｜デジタル庁デザインシステムβ版 デジタル庁、2026年9月9日更新。2026年7月8日の Markdown 提供開始告知、その後の定期更新履歴。 ↩

  6. 公共データ利用規約（第1.0版）｜デジタル庁 デジタル庁、令和6年7月5日制定。商用利用・翻案の許諾条文、CC BY 4.0 互換性。 ↩

  7. 利用上の注意事項｜デジタル庁デザインシステムβ版 デジタル庁、2026年1月20日更新。出典記載ルール、加工時の編集明記ルール（notices 1-1, 1-2）。 ↩

  8. 余白（概要）｜デジタル庁デザインシステムβ版 デジタル庁、2024年12月20日更新。基準単位 8 CSS px、適用例（8px, 24px, 64px）の 3 段階スケール定義。 ↩

  9. タイポグラフィ（概要）｜デジタル庁デザインシステムβ版 デジタル庁、2025年11月28日更新。Noto Sans JP の採用、Display 48〜64, Standard 16〜45, 14px 未満不許容の定義。 ↩

  10. GPT-6 Astraの実例から、仕事の資料づくりへ。デジタル庁のデザインシステムでスライドを作り、赤枠で修正を依頼→パワポ化までできるSkillsキットを配布 テツメモ、2026年9月10日公開。dads-slide-deck-v1 配布、スライド向け文字サイズ 5 段階の選定、PowerPoint で開いて画像化し実物を確認する手順。 ↩ ↩2

  11. カラー（概要）｜デジタル庁デザインシステムβ版 デジタル庁、2024年12月20日更新。テキスト 4.5:1 以上、非テキスト 3.0:1 以上、Yellow-300 / Black フォーカス定義。 ↩

  12. デジタル庁デザインシステムをCodexとClaude Codeから呼び出すSkillを作った セカヤサAIブログ（itokoba）、2026年8月24日公開。非公式 Skill apply-digital-agency-design-system、Codex/Claude Code 連携。 ↩

  13. Set-of-Mark Prompting Unleashes Extraordinary Visual Grounding in GPT-4V Jianwei Yang et al. (Microsoft Research)、2023年10月23日公開。LMM の視覚的グラウンディング手法、マーク重畳による領域特定。 ↩

  14. microsoft/SoM Microsoft Research、2023年公開。Set-of-Mark Prompting の公式実装リポジトリ。 ↩

  15. benjitaylor/agentation Benji Taylor、2026年公開。ブラウザ上の要素選択と座標・Markdown 出力、AI エージェント連携仕様。 ↩

  16. 運営理念 | はじめに（SmartHR Design System） SmartHR、2026年公開。デザインシステムのオープン公開理念、「車輪の再発明を減らす」社会的価値。 ↩