デジタル庁デザインシステムとは：民間サイトでの利用可否とライセンス三層・準拠範囲

デジタル庁デザインシステムは、行政機関向けに公開されているUIコンポーネントとガイドラインの集合体です。ライセンス上は民間企業のサイトでも使えますが、配布物ごとに規約が分かれており、出典表示の義務も対象によって変わります。この記事で公式の記載を根拠に整理するのは、v2.17.0で何が手に入るのか、本体とFigmaとコードで異なる三層のライセンス、WCAG2.2の達成基準に対してどこまで準拠を助けてくれるのか、そして自社サイトに借りるべき案件と見送るべき案件の条件です。コンポーネントの入手手順そのものは別記事に譲り、ここは採用可否の判断に絞ります。

まとめ｜デジタル庁デザインシステムを民間サイトで使う際の可否と条件

民間企業が自社サイトに使うことは、規約上は可能です。デザインデータ（Figma）はCC BY 4.0、コードスニペットはMIT Licenseで公開されており、いずれも改変を前提としたリソース。加工して作った画面パーツを自社サイトで使う場合、出典の明記は不要です。

ただし三つの条件が付きます。ガイドラインやコンポーネント仕様といった「デザインシステム本体」だけは扱いが別で、引用すれば出典記載が要り、加工すればその旨の記載も要ります。デジタル庁のロゴやシンボルマークは利用ルールの適用外で、使うには許諾申請が必要です。そして、これを使ってもウェブアクセシビリティに適合したことにはなりません。公式が示す数字はWCAG2.2の86達成基準のうち43項目で、残りはサイト制作者の側の作業として残ります。

採用が噛み合うのは、申請フォームや手続き画面のように、意匠より確実な操作性が優先される画面です。ブランド表現そのものが競争要因になるサイトでは、上書きするCSSの量が増えて元の設計から離れるため、借りる利点が消えます。

デジタル庁デザインシステムの中身｜v2.17.0で配布される4種類のアセット

専用サイトは design.digital.go.jp/dads/ にあり、2026年8月16日時点のサイト名表記は「デジタル庁デザインシステムβ版 v2.17.0」、最終更新日は2026年8月5日です。公式の定義は「デザイン言語、UIコンポーネント、ガイドラインから構成されるデザインアセット」で、想定利用者は「官公庁や地方自治体などの行政機関や公共性の高い組織等」。民間企業は名指しされていない、という前提から話を始めます。

デザインシステム本体｜ガイドラインとコンポーネント仕様が担う範囲

公式が定義する「デザインシステム本体」とは、デジタル庁デザインシステムを構成する文書・ガイドラインその他一切の情報から、デザインデータ（Figma）とコードスニペットを除いたものです。Markdown形式で配布されるドキュメント一式も本体に含まれます。

中身は、価値観を指針化したデザインプリンシプル、各コンポーネントの仕様と作例、アクセシビリティガイドライン。公式は本体を「規約やルール」ではなく「デザインの考え方や枠組みとアクセシビリティを掛け合わせた仕組み」と位置づけており、守るべき規則ではなく判断の下敷きとして読む前提で書かれています。民間サイトに持ち込むときも、価値があるのはコンポーネントの見た目より、この仕様書の判断根拠のほうです。

デザインデータ（Figma）とコードスニペットの分業と入手経路

実物のアセットは二系統です。Figmaのデザインデータは基本デザインとコンポーネントをファイル化したもので、Figma Community上に公開されており、取得には無料の会員登録が要ります。コードスニペットはコンポーネントの一部を実装したサンプル集で、素のHTML／CSS／JavaScript版とReact＋Tailwind CSS版の2系統がGitHubで公開されています。

注意したいのは、コードスニペットがnpmで配布されるUIライブラリではない点です。npmパッケージとして配られているのはデザイントークンとTailwindプラグインで、コンポーネント本体はコードをコピーして使う設計。この構造が保守にどう効くかを含めた実装側の手順は、デジタル庁デザインシステムのコンポーネント入手｜GitHub 2リポジトリとStorybook手順で扱っています。

β版表記のまま2年以上更新が続く現状から読む採用時の安定性の目安

専用サイトの公開は2024年5月30日。2年以上にわたって更新が続いていますが、表記はβ版のままです。バージョンはv2系で、2026年8月時点でv2.17.0まで上がっています。

β版という表記だけで採用を止める判断は、実態と合いません。更新が止まっているプロジェクトではなく、むしろ改訂の頻度が高い側です。判断に効くのは表記ではなく、変更をどう受け取るかの体制。コードをコピーして使う前提である以上、上流の変更は自動では降ってきません。社内で採用可否を諮る場では、β版であることより「更新履歴を追う担当を置けるか」を先に決めておくほうが話が早く進みます。

ライセンスの三層構造｜本体・Figma・コードで異なる出典表示の義務範囲

民間利用でつまずきやすいのがここです。「ライセンスはMIT」という説明を見かけますが、正確には配布物ごとに三つに分かれています。公式の「利用上の注意事項」（2026年8月5日更新）を対象別に整理すると次のとおりです。

実務上の意味はひとつ。作ったUIを自社サイトで動かすだけなら出典表記は要りません。要るのは、加工せずそのまま配ったり見せたりする場合と、ガイドラインの文章を引用する場合です。

デザインシステム本体はPDL1.0準拠｜出典と加工表示の2段構え

本体には、デジタル庁ウェブサイトのコピーライトポリシーが適用されます。同ポリシー（最終更新日2026年5月12日）が定めるのは「公共データ利用規約（第1.0版）」、通称PDL1.0です。政府標準利用規約と混同されがちですが、デジタル庁が明示しているのはPDL1.0のほうです。

求められる記載は2段構えです。コンテンツを利用する際は出典を記す。編集・加工して利用する場合は、それとは別に加工した事実とその主体を記す。公式の記載例は「デジタル庁デザインシステムウェブサイト（URL）をもとに○○株式会社作成」という形です。

そして条文には、加工した情報を「あたかもデジタル庁が作成したかのような態様で公表・利用してはいけません」と明記されています。この一文が、後述する民間利用の実務上の制約に直結します。

FigmaデータはCC BY 4.0｜出典表示が不要になる加工の条件

Figma Communityで公開されているデザインデータには、CC BY 4.0が適用されます。表示さえすれば商用利用も改変も再配布も認める、広く使われている条件です。

ここで効くのが、デジタル庁が付けている例外規定です。公式は「デザインデータ（Figma）は編集・加工等して利用することが前提のリソースのため」として、加工して作成したUI等の画面パーツを利用者のウェブサイトで使う場合、出典を明記する必要はないと明記しています。CC BY 4.0の表示義務を、そのまま画面に持ち込まなくてよい設計になっているわけです。逆に、データを編集せずそのまま公開する場合は出典記載が要ります。

なおFigmaデータには一部Material Symbolsのアイコン素材が含まれ、その部分にはApache License 2.0が適用されます。アイコンだけを抜き出して別の素材集に混ぜて配布するなら、この差分の確認が要ります。

コードスニペットはMIT｜第三者素材の別ライセンスが混ざる箇所

GitHubで公開されているコードスニペットにはMIT Licenseが適用されます。出典の扱いはFigmaと同じで、加工して作った画面パーツを自社サイトで使う分には記載不要です。

見落としやすいのがサードパーティライセンスの節です。公式サイトが改変・再配布している第三者のアセットとして、たとえばフォントのNoto SansがSIL Open Font License 1.1で列挙されています。フォントは「単体では販売しない」という条件で、コードのMITとは条項の性質が別物。コードとフォントと素材を一括りに「MITだから自由」と社内説明すると、後で誤りが出ます。

ロゴとシンボルマークは利用ルール適用外｜許諾申請が要る境界線

コピーライトポリシーの1.4は、利用ルールが適用されないコンテンツを列挙しています。その筆頭が「組織や特定の事業を表すシンボルマーク、ロゴ、キャラクターデザイン」で、ロゴの使用には別途、許諾申請が必要と案内されています。

境界線はこう引かれます。ボタンや入力欄といったコンポーネント、色やフォントサイズといったトークンは自由に持ち出せる。デジタル庁という組織を指し示す記号は持ち出せない。民間サイトで問題になるのは前者ではなく、資料や実績紹介にロゴを添えたくなる場面のほうです。

アクセシビリティ準拠の実効範囲｜WCAG2.2の86項目中43項目という上限

「これを使えばアクセシビリティ対応が済む」という理解は、公式の記載と食い違います。デジタル庁ニュースの記事（2025年10月14日公開）は、WCAG2.2には86項目の達成基準があり、デザインシステムを利用することでそのうち43項目について「適合できる」または「適合が容易になる」と説明しています。数字で言えばちょうど半分。しかも43項目には「適合が容易になる」だけの項目も含まれます。

デザインシステム側が引き受ける7つの設計要素と担保される範囲

公式のアクセシビリティガイダンス（2025年10月29日更新）は、特に注意を払って構築した領域として次の7点を挙げています。

• 色の組み合わせとコントラスト比
• フォントサイズ
• キーボード操作、フォーカスインジケーター
• リンクやボタン等のターゲットサイズ
• 操作に対応したインタラクション表現
• 動きのあるオブジェクトの扱い
• 大きさの可変や内容量の増減を踏まえた外観構造

並べてみると性格がはっきりします。7点はいずれも「部品の作り」で決まる項目です。コントラスト比のように数値で判定できる基準は、トークンとコンポーネントを正しく使えば自動的に満たせます。この種の基準を自動検証だけでは取りこぼす理由は、Webアクセシビリティのコントラスト比：4.5対1と3対1の適用範囲・CSS実装・自動検証の落とし穴にまとめました。コードスニペットはデジタル庁内のアクセシビリティスペシャリストによるチェックを経ていると公式に記載があり、キーボード操作やスクリーンリーダーでの挙動は実装済みの状態で配布されています。

制作者側に残るコンテンツ自体のアクセシビリティ確保の作業範囲

同じガイダンスは、引き受けない範囲もはっきり書いています。「デザインシステムを利用して開発されるウェブサイトが独自にもつコンテンツ自体のアクセシビリティは、各ウェブサイトの制作者の側にて確保する必要があります」。締めくくりは「デザインシステムによって達成できるアクセシビリティは、考慮すべきアクセシビリティ全体の一部であることに留意してください」です。

残るのは、画像の代替テキスト、見出しの階層、リンクテキストの具体性、動画の字幕、フォームのエラーメッセージの文言、PDFの中身。どれもコンポーネントでは解決しない、書く側の作業です。ガイダンスは、状態を維持するには「アクセシビリティを踏まえたコンテンツ運用設計と、それを実現するための予算や人材の調達が不可欠」とまで書いています。制作時の一発対応ではなく運用の話、という整理になります。

改正障害者差別解消法の努力義務との対応関係と誤解しやすい線引き

法令との関係も、公式ガイダンスが位置づけを明示しています。2024年4月1日施行の改正障害者差別解消法では、義務である合理的配慮の提供に先立つ事前的改善措置として「環境の整備」が努力義務とされ、ウェブサイトにおいてはアクセシビリティの確保がこれに該当する、という整理です。

ここを「ウェブサイトのアクセシビリティが義務化された」と読むのは誤りです。義務は合理的配慮の提供であって、サイト側の整備は努力義務。これを取り違えたまま社内稟議を書くと、要件も予算も過不足が出ます。法令の条文レベルの線引きと企業が実際にやるべきことは、Webアクセシビリティは義務化されたのか？2024年改正法の線引きと企業がやるべきことで扱っています。なお公式が参照規格として挙げるのは、最新版のWCAG2.2と、WCAG 2.0互換であるJIS X 8341-3:2016です。

民間サイトへの採用判断｜借りて始める案件と見送るべき案件の条件

ここは言い切ります。判断を分けるのは業種でも予算でもなく、そのサイトで意匠が競争要因になっているかどうかです。

採用が噛み合う条件｜申請フォームと手続き画面を持つ業務系サイト

借りる価値が最も出るのは、入力と手続きが主目的の画面です。日付ピッカー、ファイルアップロード、ステップナビゲーション、エラー表示を伴うフォーム。この種の部品をアクセシブルに自作するコストは大きく、キーボード操作とスクリーンリーダーでの検証まで含めれば工数は跳ね上がります。公的機関がチェック済みで公開している実装を出発点にできる利点は、そのまま設計工数に効きます。

具体的には、会員向けの申請フォーム、社内向け業務システムの入力画面、自治体案件の受託、公共性の高い法人のオンライン手続きがこれにあたります。いずれも意匠の独自性が評価されない領域で、デザインシステムが引き受ける7領域と要件がそのまま重なる画面です。画面設計をどこまで自前で持ち、どこから外部に頼るかの線引きは、UI/UXデザインの設計段階で決めておくと、実装に入ってからの手戻りが減ります。

見送るべき条件｜意匠そのものが差別化要因になるブランドサイト

逆に、採用すべきでないのはコーポレートサイトやブランドサイト、採用サイトです。理由は好みではありません。デザインシステムは「誰一人取り残されない」という設計思想のもとで、色数を抑え、余白を広く取り、動きを控えめにする方向に振ってあります。ブランド表現でこの方向と逆を求めるなら、トークンを上書きし、CSSを書き換え、アニメーションを足す作業が積み上がります。

上書きが増えるほど、元のコンポーネントが担保していたコントラスト比やターゲットサイズは崩れます。半年も経てば、参照元とは別物のコードが手元に残り、アクセシビリティの根拠だけが失われた状態になる。それなら最初から自社の要件で組んだほうが、保守も説明も通ります。実績としての体裁だけを目的に公的なデザインシステムを選ぶのは、最も割に合わない使い方です。

公的機関が作ったように見える誤認を避ける表示と改変の実務手順

採用すると決めたら、表示まわりの整理を先に済ませます。コピーライトポリシーは、加工した情報を国や府省等が作成したかのような態様で公表・利用することを禁じています。民間サイトでは次の順で確認すると漏れません。

1. デジタル庁のロゴ、シンボルマーク、府省庁名を画面・資料の双方から外す
2. 加工せず転載するガイドライン文言があれば、出典と加工の有無を記載する
3. 実績紹介や提案資料で「デジタル庁デザインシステム採用」と書く場合、採用したのがFigmaデータかコードかを明示し、デジタル庁との関係を示唆する表現を避ける
4. 改変したコンポーネントについて、どこを変えたかを社内のドキュメントに残す

4番目は規約上の義務ではありませんが、上流の更新を取り込む段で効きます。改変箇所の記録がないと、v2.18.0以降の差分を当てるときに手が止まります。

自社デザインシステムとの使い分け｜借りる・作る・混ぜるの分岐点

デジタル庁デザインシステムの採用は、自社でデザインシステムを持つかどうかという判断と地続きです。両者を別々に検討すると、どちらも中途半端になります。

出発点として借りる場合に先に決めておく改変範囲とトークンの扱い

混ぜる使い方、つまりトークンだけ自社の色に差し替えてコンポーネントは借りる形が、現実的な落としどころです。npmパッケージとして配布されているのはデザイントークンとTailwindプラグインで、この2つはバージョン管理の内側にあります。コンポーネントをコピーせずトークンだけ取り込めば、上流の更新をパッケージ経由で受け取れます。

この形を選ぶなら、最初に決めるべきは色とフォントサイズをどこまで変えるかです。コントラスト比の基準を保ったまま自社カラーを載せられるかは、配色の段階で検証しておきます。デザインシステムの構成要素や自社で一から作る手順は、デザインシステムとは？構成要素・作り方とデザインガイドラインとの違いを解説で整理しています。

自前構築へ切り替える分岐点｜自作コンポーネントの数で見る境目

自前に切り替える境目は、扱う画面の種類が増えたときです。手続き画面だけなら借り物で足りますが、マーケティング用のランディングページ、ダッシュボード、モバイルアプリと対象が広がると、埋まらない部品が出てきます。足りない部品を継ぎ足すたびに、借りた設計思想と自作部分の思想が食い違う。

目安をひとつ挙げるなら、自作コンポーネントの数が借用分を上回った時点です。そこを越えたら、借りているのは実装ではなく体裁だけ。運用の主体を自社に移し、デジタル庁デザインシステムは参照する仕様書として残すほうが、その後の意思決定が速くなります。

よくある質問

民間利用の判断前によく聞かれる点をまとめます。

デジタル庁デザインシステムは民間企業のウェブサイトでも使えますか？

使えます。デザインデータ（Figma）はCC BY 4.0、コードスニペットはMIT Licenseで公開されており、いずれも商用利用と改変を認める条件です。ただし公式の想定利用者は「官公庁や地方自治体などの行政機関や公共性の高い組織等」で、民間企業向けに作られたものではありません。使えるかの答えは可、使うべきかは画面の性質しだい、という二段構えで考えるほうが実態に合います。

これを使えばJIS X 8341-3:2016のAAに適合したことになりますか？

なりません。公式が示す範囲は、WCAG2.2の86項目の達成基準のうち43項目について「適合できる」または「適合が容易になる」というものです。JIS X 8341-3:2016はWCAG 2.0と互換の規格で、適合を宣言するには自社のコンテンツを含めた試験が要ります。公式ガイダンスも、サイト独自のコンテンツのアクセシビリティは制作者の側で確保する必要があると明記しています。

コードを改変して使う場合、出典の記載は必要ですか？

不要です。公式の「利用上の注意事項」は、コードスニペットもデザインデータ（Figma）も編集・加工して利用することが前提のリソースであるとして、加工して作成したUI等の画面パーツを自社サイトで使う場合に出典を明記する必要はないと記載しています。記載が要るのは、編集・加工せずそのまま利用し公開する場合です。なおガイドライン等の「デザインシステム本体」を引用するなら、加工の有無にかかわらず出典記載が必要で、加工したならその旨も別途書きます。

β版のまま採用して、正式版が出たら作り直しになりませんか？

作り直しのリスクはβ版という表記より、配布形態から来ます。コンポーネント本体はnpmパッケージではなくコードをコピーして使う設計のため、採用した時点でフォーク運用になります。上流でv2.17.0からさらに版が上がっても、差分は自動では反映されません。更新履歴を追う担当を置けない体制なら、コンポーネントは参考実装として読むにとどめ、npm配布のデザイントークンとTailwindプラグインだけを取り込むほうが、後の保守は軽く済みます。

デジタル庁のロゴやシンボルマークは一緒に使えますか？

使えません。デジタル庁ウェブサイトのコピーライトポリシー1.4は「組織や特定の事業を表すシンボルマーク、ロゴ、キャラクターデザイン」を利用ルールの適用外と定めており、ロゴの使用には許諾申請が必要と案内しています。コンポーネントやトークンが自由に使えることと、組織を指し示す記号が使えることは別の話。提案資料や実績紹介で添えたくなる場面が最も事故りやすいため、社内のテンプレート段階で外しておきます。

関連記事

• Webアクセシビリティ方針の書き方：対象範囲・適合レベル・達成期限の文面と試験結果の書式：採用後に適合レベルをどう宣言するかの文面例です。
• Webアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準：制作者側に残る検証をどこまで行うかの設計です。
• Webアクセシビリティ対応の費用：診断・改修・運用の三層で見積を分解する：ガイダンスが挙げる「予算や人材の調達」を金額に落とす方法です。
• Webアクセシビリティのスクリーンリーダー対応：NVDA・VoiceOverでの実機検証と読み上げ順序の設計：組み合わせた後の読み上げ順序を実機で確かめる手順です。
• レスポンシブデザインとは？仕組み・メリットとスマホ対応方式の選び方を制作目線で解説：可変幅への対応方式を選ぶ視点で外観構造の設計と接続します。