デジタル庁デザインシステムのコンポーネント入手|GitHub 2リポジトリとStorybook手順
デジタル庁デザインシステムのサンプルコンポーネントを2024年頃の記事を頼りに探すと、当時と構成が変わっていることに気づきます。リポジトリは2025年にReact版のリネームとHTML版の新設を経て2本になり、古い解説を追うとHTML版の存在に行き着けません。この記事では2026年7月時点の一次情報をもとに、現在どこに何が置かれているか、ローカルのStorybookでコンポーネントを確認する手順、依存パッケージの実バージョン、そして自社プロダクトへ取り込む前に把握しておくべき変更の頻度を整理します。
まとめ
最短経路はリポジトリをクローンして npm install と npm run storybook の2コマンドです。これでコンポーネントのカタログがローカルに立ち上がります。対象はGitHubの digital-go-jp/design-system-example-components-html(素のHTML・CSS・JavaScript)と digital-go-jp/design-system-example-components-react(React+Tailwind CSS)の2本で、どちらもMITライセンスです。
ただしこの2本はnpmで配布されるUIライブラリではなく、コードをコピーして使うサンプル集です。npmパッケージとして配られているのはデザイントークンとTailwindプラグインだけで、コンポーネント本体はバージョン管理の外側にあります。取り込み方の判断は本文で扱います。
デジタル庁デザインシステムの現在地(2026年7月時点)
本体サイトは design.digital.go.jp にあり、サイト名の表記は「デジタル庁デザインシステムβ版 v2.16.0」です。中核となるFigmaのデザインデータv2.16.0は2026年7月8日に公開されました。専用サイトの公開は2024年5月30日で、以降2年以上にわたって更新が続いていますが、正式版ではなくβ版という位置づけのままです。社内で採用可否を諮る際は、この点を先に共有しておくほうが話が早く進みます。
グローバルナビは「はじめに」「ガイダンス」「基本デザイン」「コンポーネント」「リソース」「お知らせ」の6項目です。実装者が直接使うのはコンポーネントとリソース、そして変更を追うための「お知らせ」の3つになります。
コンポーネント一覧の顔ぶれ
コンポーネント一覧には49種類が並びます。汎用のUIライブラリと重なるものが大半ですが、行政サービスの画面を想定した部品が最初から含まれている点が違いです。
- 入力系:インプットテキスト、テキストエリア、セレクトボックス、コンボボックス、チェックボックス、ラジオボタン、スイッチ、日付ピッカー/カレンダー、ファイルアップロード/ドロップエリア
- ナビゲーション系:ヘッダーコンテナ、メガメニュー、水平メニュー、ドロワー、パンくずリスト、ページナビゲーション、ステップナビゲーション、目次、ボトムナビゲーション、ランゲージセレクター
- 通知・表示系:緊急時バナー、ノティフィケーションバナー、注釈ブロック、引用ブロック、モーダルダイアログ、プログレスインジケーター、カルーセル、イメージスライダー
- データ表示系:テーブル/データテーブル、テーブルコントロール、説明リスト、箇条書きリスト、リソースリスト、カード、チップタグ、チップラベル
ステップナビゲーションや緊急時バナー、ランゲージセレクターのように、公共サービス特有の要件から生まれた部品が揃っているのがこのデザインシステムの実質的な価値です。デザインシステム一般の考え方や構成要素から押さえたい場合は、デザインシステムとは?構成要素・作り方とデザインガイドラインとの違いを解説を先に読むと以降の話が通りやすくなります。
Figmaデザインデータの入手条件
デザインデータはFigma Community上で配布されており、取得にはFigmaの会員登録(無料)が必要です。現行はv2系で、v1系のデータについては「今後はエラー修正のみの更新」と公式に明記されています。これから新規に着手するなら、v1系を参照する理由はありません。
リポジトリ構成|HTML版とReact版の現在地
2025年の構成変更と現在の参照先
現在の正しい参照先は次の2つです。
https://github.com/digital-go-jp/design-system-example-components-html
https://github.com/digital-go-jp/design-system-example-components-react
経緯を正確に書くと、リポジトリが2本に割れたわけではありません。HTML版は2025年7月8日に新規リポジトリとして作成され、その後、2024年3月から存在していた既存リポジトリ design-system-example-components が -react 付きの名前へリネームされました。公式のお知らせ(コードスニペット)2025年8月26日の記載は「GitHubリポジトリのURLをHTML版の形式に揃うように変更」で、HTML版が先、React版のリネームが後です。
旧URLはGitHubのリダイレクトによって現在も -react 側へ解決されるため、古いリンクを踏んでも404にはなりません。問題はそこではなく、リダイレクト先がReact版なので、HTML版が別に存在することに気づかないまま「Reactでないと使えない」と判断してしまう点です。実際にはReactを使わない案件でも選択肢があります。
HTML版とReact版の選定基準
判断の分かれ目はプロジェクトがReactかどうかではなく、Tailwind CSSを使う前提があるかどうかです。React版はデジタル庁のデザイントークンを反映したTailwindプラグインの上に成り立っているため、Tailwindを入れない方針のReactプロジェクトに持ち込むと、結局スタイルを書き直すことになります。その場合はHTML版のCSSを読んで自前のコンポーネントに落とし込むほうが早く済みます。
| 項目 | HTML版 | React版 |
|---|---|---|
| 想定プロジェクト | Tailwind非採用・非React | React + Tailwind |
| 実装 | HTML / CSS / JavaScript | React v18 / Tailwind CSS v3 |
| 別途必要な依存 | なし | tailwind-theme-plugin |
| Storybook起動 | npm run storybook |
npm run storybook |
| 静的ビルド | npm run build-storybook |
npm run storybook:build |
| ライセンス | MIT | MIT |
静的ビルドのスクリプト名が2つのリポジトリで語順の逆になっている点は、CIの設定をコピーして流用するときに引っかかります。取り違えるとジョブがスクリプト未定義で落ちます。なおHTML版の「別途必要な依存なし」は、コードを自プロジェクトへ持ち込む際に追加のスタイルライブラリが要らないという意味です。リポジトリ自体はStorybookの動作確認用にNode製の開発依存を抱えているので、package.json を開くと依存が並んでいます。
Storybookでコンポーネントを確認する手順
React版のローカル起動手順
クローンして依存を入れ、Storybookを起動すれば全コンポーネントのカタログが開きます。
git clone https://github.com/digital-go-jp/design-system-example-components-react.git
cd design-system-example-components-react
npm install
npm run storybook
起動後は http://localhost:6006 にアクセスすると、コンポーネントごとにpropsを切り替えながら表示や挙動を確認できます。ここで見るべきなのは見た目よりキーボード操作とフォーカスの当たり方です。行政サービス向けに作られている以上、アクセシビリティの実装がサンプルの中心的な価値になります。Storybook自体の操作やストーリーの書き方に不慣れなら、Storybookの使い方|インストールからストーリー作成・Next.js連携・テストまで実装手順で解説で基本を押さえておくと、カタログの読み方が変わります。
自プロジェクトへ取り込むときの必須手順
リポジトリをそのまま動かす場合と違い、コンポーネントのコードを自分のプロジェクトへコピーするときはTailwindプラグインを別途インストールする必要があります。React版のREADMEに明記された手順で、これを飛ばすとクラス名だけが移ってスタイルが一切当たりません。
npm install @digital-go-jp/tailwind-theme-plugin
プラグインはデジタル庁のデザイントークンをTailwindのテーマとして展開する役割を担います。コンポーネントのコードとトークンは別配布であり、片方だけを持ってきても成立しません。色やタイポグラフィだけを既存のデザインへ寄せたい場合は、コンポーネントを使わずこのプラグインとトークンだけを導入する選び方もあります。
つまずきやすいバージョンの組み合わせ
React版の実装ベースはReact v18、Tailwind CSSはv3です。READMEには、React v19のプロジェクトへ取り込む場合に軽微な型エラーが出る旨が書かれています。動かないわけではなく型定義の差分に起因するもので、必要に応じて修正しながら使う前提です。新規プロジェクトをReact v19で立てているなら、この修正が誰の担当になるかを先に決めておかないと、コピーした人以外がメンテできないコードが残ります。
Tailwind側は注意して読み分けてください。@digital-go-jp/tailwind-theme-plugin のバージョン1.0.1(2026年6月16日公開)は、peerDependenciesとして ^3.4.17 と ^4.0.0 の両方を宣言しています。プラグインはTailwind v4対応です。一方でサンプル実装のクラス記述はv3前提なので、v4環境へコンポーネントをそのまま貼れば無傷という話ではありません。トークン単体の @digital-go-jp/design-tokens は2.0.1(2026年5月28日公開)で、いずれもMITライセンスです。
| パッケージ | 最新版 | 公開日 | 備考 |
|---|---|---|---|
| tailwind-theme-plugin | 1.0.1 | 2026-06-16 | tailwindcss v3.4.17 / v4 対応 |
| design-tokens | 2.0.1 | 2026-05-28 | トークン単体で利用可 |
いずれも npmレジストリ上の公開情報です。更新が続いているため、導入前に最新版を確認してください。
ドキュメントMarkdown一式の入手
公式リソースでは、デザインシステム本体を構成する全ドキュメントとアクセシビリティガイドラインがMarkdown形式でも配布されています。配布物は2026年7月22日版で、サイトのリソースページからzipで取得できます。
用途としては、コーディング支援AIやRAGの参照データに丸ごと投入する使い方が現実的です。ガイドラインの記述をチャットで都度引くより、リポジトリに置いてエージェントに読ませたほうが、コンポーネントの選定理由まで含めた回答が返ります。サイトをブラウズして規約を拾い直す作業が減る分、実装レビューの前段が短くなります。
コードスニペットの更新頻度と破壊的変更の実例
コードスニペットの更新は不定期です。2026年は2月10日、5月27日、6月24日、7月15日の4回で、2月から5月までは3か月半空きました。定期リリースを前提にした運用計画は立てられません。
注目すべきは新規追加より既存コンポーネントの仕様変更です。コピー済みのコードに影響する変更が実際に起きています。
- 2026年2月10日:React版で
Ul・Olコンポーネントを削除しListへ統合、名称も「リスト」から「箇条書きリスト」へ変更、ol要素を使わないマークアップに変更 - 2026年6月24日:HTML版・React版ともチップラベルのバリアント名を改称(
outline→outlined、filled-outline→filled-1、filled→filled-2) - 2026年5月27日:HTML版の「グローバルメニュー」を「水平メニュー」へ改称
- 2026年7月15日:React版のインプットテキスト、テキストエリア、日付ピッカーで
placeholderプロパティを never 型へ変更
コンポーネントの削除・統合とバリアント名の一斉改称は、npmで管理していれば差分を追って対応できますが、コピー運用では自動では伝わりません。placeholder を型レベルで受け付けなくする変更は、公式が理由を明記していないものの、プレースホルダーをラベル代わりに使う実装を封じる意図と読めます。古いコピーを持ち続けると、公式が意図的に排したパターンを使い続けることになります。
採用判断|割り切って使う場面と見送るべき場面
判断を明確にしておきます。デジタル庁デザインシステムのコンポーネントを自社プロダクトへ入れるべきでないのは、更新履歴を追う担当を置けない体制のときです。
理由は配布形態にあります。npmパッケージになっているのはデザイントークンとTailwindプラグインの2本だけで、コンポーネント本体はリポジトリのコードをコピーして使う前提です。コピーした瞬間から実質的なフォーク運用になり、上で挙げた削除・統合や改称は自分たちで追いにくくなります。半年放置すれば、参照元とは別物のコードが手元に残ります。この構造を許容できないなら、コンポーネントは参考実装として読むにとどめ、実際に導入するのはトークンとTailwindプラグインだけにするほうが、後の保守は明らかに楽になります。
逆に割り切って使うべきなのは、行政・自治体向けの申請フォームや手続き画面のように、アクセシビリティ要件が仕様として先に決まっている案件です。日付ピッカーやファイルアップロードをアクセシブルに自作するコストは大きく、公的機関が公開している実装を出発点にできる利点が、フォーク運用の面倒を上回ります。業務システム全般でのUI部品の選び方については、業務システムの画面デザイン|実装者向けUI設計パターンとライブラリ選定で判断軸を整理しています。
コピー運用を選ぶなら、見た目の差分を検知する仕組みをセットで用意してください。Storybookのストーリーがそのまま入っているため、ビジュアルリグレッションテストとの相性は良好です。実際の連携方法はChromaticとは何か?Storybook連携で広がるUI開発の可能性で扱っています。取り込んだコンポーネントを自社のレイアウトへ収める段では、幅に応じた出し分けを親要素ではなくコンポーネント側で完結させるCSS Container Queriesで実現するコンポーネント単位のレスポンシブ設計の考え方が噛み合います。
よくある質問
デジタル庁デザインシステムのGitHubリポジトリはどこですか
digital-go-jp organization 配下の design-system-example-components-html と design-system-example-components-react の2つです。HTML版が2025年7月8日に新設され、その後2025年8月26日に既存リポジトリが -react 付きの名前へ変更されました。旧URLはGitHubのリダイレクトで React版に解決されるため、古いリンクでも到達はできます。デザイントークンは design-tokens リポジトリに別途あります。
Storybookは何のために使われているのですか
公開されたコンポーネントを、アプリケーションを組まずに単体で確認するためです。HTML版・React版のどちらにもStorybookの設定とストーリーが同梱されており、npm run storybook で http://localhost:6006 にカタログが立ち上がります。propsやバリアントを切り替えながら、表示だけでなくキーボード操作やフォーカス挙動まで確認できるため、実装の参考にする際はこの状態で読むのが最も速い方法です。
Storybookのビルドが「スクリプトがない」と言われて落ちます
リポジトリを取り違えている可能性が高いです。静的ビルドのスクリプト名はHTML版が build-storybook、React版が storybook:build で、語順が逆になっています。開発サーバ起動の npm run storybook は両方共通のため、起動できたからといってビルド用スクリプト名も同じとは限りません。CIの設定を片方からコピーしたときに起きやすい事象です。
デザインデータの最新バージョンはいくつですか
2026年7月時点でv2.16.0、公開日は2026年7月8日です。サイトの表記も「デジタル庁デザインシステムβ版 v2.16.0」となっています。デザインデータのバージョンとコードスニペットの更新は同時ではないため、Figma側とGitHub側の双方で日付を確認してください。なおv1系のデザインデータは、今後はエラー修正のみの更新と公式に告知されています。
商用プロダクトで使えますか。ライセンスは何ですか
HTML版・React版のサンプルコンポーネント、design-tokens、tailwind-theme-pluginはいずれもMITライセンスで公開されています。MITであるためコードの利用自体に制約は小さいものの、デジタル庁のロゴや府省庁のブランド要素は別扱いです。公的機関が提供しているという見え方が誤解を生む用途では、リポジトリのライセンス表記と各素材の利用条件を個別に確認してください。
React v19のプロジェクトでも使えますか
使えますが、そのままとはいきません。React版の実装ベースはv18で、READMEにはv19のプロジェクトへ取り込む場合に軽微な型エラーが出ると明記されています。実行時に動かないという話ではなく、型定義の差分を必要に応じて直しながら使う前提です。v19で新規に立てる場合は、この修正分をあらかじめ見積もりに含めておくのが無難です。