デジタル庁は、デザインシステムをAIに読ませ始めた。Markdown配布が示すこと

2026年8月29日 16:10

こんにちは、How many designs です。
Web Design Talk というタイトルで、デザインに関するお話を少しだけ書いていこうと思います。気軽に読んでいただければ幸いです。

デジタル庁からMarkdownが配布されました。

デジタル庁デザインシステムは、FigmaのデザインデータとHTML／Reactのコードに加えて、全ドキュメントをMarkdownでも配り始めました。

一見すると、Webサイトに掲載されている文章を、テキストファイルとしてもダウンロードできるようにしただけに見えるかもしれません。

しかし、実際に配布されたファイルを確認すると、もう少し大きな変化が起きています。

配布物のREADMEには、このMarkdown一式が「主にAI参照用途」であると明記されています。デジタル庁は、デザインシステムを人間がブラウザで読むだけでなく、AIが検索し、必要な情報を取り出し、実装時に参照することまで想定して配り始めたのです。

これは、AI時代のデザインシステムがどのような形になるのかを考えるうえで、かなり象徴的な出来事だと思います。

デジタル庁は「AI参照用」のMarkdown一式を配り始めた

デジタル庁デザインシステムのお知らせによると、Markdownファイル一式の提供が始まったのは2026年7月8日です。

対象は、デジタル庁デザインシステムのWebサイトを構成する全ドキュメントと、アクセシビリティガイドラインです。

その後も、

7月22日
8月5日
8月19日

と、Webサイトの更新に合わせてMarkdown一式も更新されています。

執筆時点の最新版は2026年8月19日版で、デジタル庁デザインシステム本体のバージョンはv2.17.1です。

実際に8月19日版のZIPファイルを展開すると、125個のMarkdownファイルが収録されていました。内容は、49種類のコンポーネント、カラーやタイポグラフィなど8種類の基本デザイン、デザインシステムの使い方、アクセシビリティ、更新履歴などに分かれています。

さらに、ルートには収録内容を一覧できるMANIFEST.mdがあります。各文書の先頭には、タイトル、カテゴリー、文書種別、変換元のURLなどを示すYAML Front Matterも付けられています。

つまり、単にWebページをMarkdownへ変換したのではありません。

AIが最初に目次を読み、必要なカテゴリーを探し、関連する文書だけを参照できるように、ひとまとまりの資料として再構成されています。

配られたのは、1つのDESIGN.mdではない

以前、Google StitchのDESIGN.mdについて記事を書きました。

DESIGN.mdは、色、タイポグラフィ、余白、コンポーネントの使い方などを、AIが参照できるテキストとしてまとめる考え方です。

プロジェクトのルートに1つのファイルを置き、

「このDESIGN.mdを参照してUIを作ってください」

とAIに伝える。

小規模なWebサイトや個人開発であれば、この方法はかなり扱いやすいと思います。

一方、デジタル庁デザインシステムのMarkdown版は、1つの巨大なDESIGN.mdではありません。コンポーネントや基本デザインごとに文書を分割し、それらをMANIFEST.mdからたどれる構造になっています。

これは、デザインシステムの規模が大きくなったときに重要になります。

AIに毎回125ファイルすべてを読ませる必要はありません。まず目次を確認し、フォームを作るならボタン、インプットテキスト、エラー表示に関係する文書だけを読む。ナビゲーションを作るなら、ヘッダー、メニュー、パンくずナビゲーションに関係する文書を読む。

必要な情報だけを、その都度選んで参照できます。

1つのDESIGN.mdが「AIのためのデザイン説明書」だとすれば、今回のMarkdown一式は、AIが必要な設計資料を探すための小さな資料庫に近いものです。

ここに、単なるファイル形式の変更以上の意味があります。

Figmaとコードだけでは伝わらないもの

これまでのデザインシステムでは、Figmaとコードが中心的な役割を担ってきました。

Figmaを見れば、色、文字、余白、コンポーネントの状態などを視覚的に確認できます。コードを見れば、それがブラウザ上でどのように動くのかを確認できます。

ただし、Figmaとコードだけでは伝えにくい情報があります。

例えば、デジタル庁デザインシステムのボタンのガイドラインには、見た目やCSSの値だけでなく、次のような設計上の判断も書かれています。

プライマリーボタンは、1つの画面につき原則1つまで
セカンダリーボタンが多すぎる場合は、フロー自体を見直す
小さなボタンでも、操作できる領域は44×44 CSS px以上を確保する
入力が終わるまで送信ボタンを無効にする設計は、安易に採用しない

ボタンの色や形はFigmaで確認できます。44pxの操作領域はコードで実装できます。

しかし、なぜそのボタンをプライマリーにするのか。なぜ無効状態を避けるのか。どのような場合にフローを見直すべきなのか。

こうした「選ぶための基準」は、文章でなければ共有しにくいものです。

AI時代のデザインシステムは、次の3つの役割に分けて考えると分かりやすいかもしれません。

Figma：見た目や状態を共有する
コード：動作と実装を共有する
Markdown：利用条件、例外、設計理由を共有する

もちろん、実際にはきれいに分離できるわけではありません。Figmaにも説明は書けますし、コードにもコメントやテストがあります。

それでも、3つの役割を意識すると、これまでデザインシステムのどこに情報が欠けていたのかが見えやすくなります。

MarkdownによってAIが理解できること、できないこと

Markdownを置けば、AIがデザインシステムを完全に理解し、必ず正しいUIを作るようになるわけではありません。

AIが参照できるのは、文書に書かれていることだけです。

プロジェクト固有の目的、利用者の状況、既存システムの制約などが書かれていなければ、AIはそれらを正確には判断できません。関係する文書を読み忘れることもあれば、ルールを理解していても実装を間違えることもあります。

デジタル庁のMarkdown版も、READMEで、人間が読む一次情報としてはWebサイトを参照するよう案内しています。各Markdownファイルには変換元のsource_urlが記載され、完全な内容が必要な場合は公式ページを確認する構造です。

Markdownは、正しさを保証する仕組みではありません。

どのルールを参照すべきかをAIに伝え、設計判断の根拠を探しやすくする仕組みです。

実際の動作を保証するのはコードであり、テストです。アクセシビリティについても、ガイドラインを読ませただけで適合が保証されるわけではありません。AIが作った結果を、人間が確認する必要があります。

だからこそ、Figma、コード、Markdownのどれか1つに置き換えるのではなく、相互に参照できる状態が重要になります。

デジタル庁デザインシステムをCSSで再実装して分かったこと

2025年1月に、私は「デジタル庁デザインシステムをもっと使いやすく」という記事を書きました。

当時は、デジタル庁デザインシステムをReactに依存しない形で使いたいと考え、標準的なCSS／SCSSで再実装する試みを始めました。

現在は公式から、HTML／CSS／JavaScript版とReact／Tailwind CSS版のコードスニペットが公開されています。以前よりも、実装へ取り入れやすい状態になっています。

この変化自体も、デザインシステムが1つのツールやフレームワークに閉じず、複数の形で配布されるようになった例だと思います。

CSSとして再実装すると、色、余白、文字サイズ、角丸などの値は移植できます。ボタンやフォームの見た目も再現できます。

しかし、CSSだけでは、「なぜこの値なのか」「どの場面でこのコンポーネントを選ぶのか」までは伝えられません。

反対に、Markdownだけでは、ホバー、フォーカス、レスポンシブ表示などの細かな挙動を保証できません。

実装して初めて分かる制約があり、文章を読んで初めて分かる判断があります。

今回、Figma、HTML／Reactのコード、Markdownが並んだことで、デザインシステムは「完成した画面パーツを配るもの」から、「設計と実装の判断材料を複数の形で配るもの」へ近づいたように感じます。

制作会社が設計資料を機械可読にするための第一歩

デジタル庁デザインシステムと同じ規模のMarkdown一式を、すべての会社が作る必要はありません。

特に小規模な制作会社では、最初から完全なデザインシステムを整備しようとすると、それ自体が大きな負担になります。

まずMarkdownにすべきなのは、制作のたびに判断がぶれる部分です。

例えば、次のような内容です。

プライマリーボタンを選ぶ基準
余白や文字サイズの基本単位と、例外を認める条件
フォームのエラーを、いつ、どこに、どのように表示するか
新しいコンポーネントを増やす前に確認すること
AIに変更させてよい範囲と、人間がレビューする範囲

最初は1つのDESIGN.mdでも十分です。

内容が増えたら、基本デザイン、コンポーネント、アクセシビリティ、プロジェクト固有のルールへ分割する。目次を作り、各文書に更新日と参照元を残す。

重要なのは、Markdownという形式そのものではありません。

これまでFigmaの中やコードの中、あるいはデザイナーやエンジニアの頭の中にあった判断を、更新し、配布し、再利用できる状態にすることです。

デザインシステムは、AIへの指示書にもなる

AIがコードを書けるようになったことで、デザインシステムの役割は小さくなるようにも見えます。

しかし実際には、その逆かもしれません。

コードを作る速度が上がるほど、何を基準に作るのかが重要になります。画面ごとに違う判断をさせないためには、AIが参照できる設計基準が必要です。

デジタル庁がMarkdown一式を配り始めたことは、デザインシステムが人間同士の共有物だけではなく、AIと協働するための参照情報にもなったことを示しています。

Figmaは見た目を伝えます。コードは動作を伝えます。Markdownは、その選択に至る判断を伝えます。

この3つがそろって初めて、AIは単に似た画面を作るだけでなく、既存の設計思想を参照しながら実装できるようになります。

AI時代のデザインシステムに必要なのは、完成した部品を増やすことだけではありません。

人間が積み重ねてきた判断を、AIも読める形で残すことなのだと思います。

参照元

いいなと思ったら応援しよう！

AI時代のWebデザインとフロントエンドについて、経験と検証をもとに記事を書いています。よろしければ応援・フォローお願いします。