Smashing Magazine が How To Make Your Design System AI-Ready を公開しました。AI コーディングエージェントが UI 実装を担う場面が増えるなか、人間向けに作られたデザインシステムだけでは AI がうまく参照できず、規約を外れた UI を量産してしまうという課題が指摘されています。記事は、トークン・コンポーネント・利用ルールを AI が機械的に解釈できる形で整えることの重要性を説いています。
一方で受託Web制作の現場では、「デザインシステムを納品したのに、運用フェーズで AI 任せの実装が規約を無視し、UI がバラバラに崩れていく」という問題が起き始めています。受託でWeb制作を支える立場では、これは 「デザインシステムを作るか」ではなく、「人にも AI にも正しく使われ、運用で崩れない設計資産として引き渡せるか」を設計に組み込む課題だと捉えています。これまで コーポレートサイトリニューアルガイド（GH Media） で扱った リニューアル設計、Astro 6.4 によるコーポレートサイト刷新受託（GH Media） で扱った モダン制作基盤、AI エージェント時代にローコードは要らない（GH Media） で扱った AI 時代の制作観と接続して、本記事では 「AI-Ready デザインシステム構築」を 受託パッケージとして整理します。
なぜ「いま」AI-Ready デザインシステムなのか
| 観点 | 人間向けのみ（従来） | AI-Ready（2026） |
|---|---|---|
| トークン | デザインツール内 | コードで機械可読 |
| 利用ルール | ドキュメント / 口頭 | 構造化された規約ファイル |
| コンポーネント | 命名がばらつく | 一貫した命名 / メタ情報 |
| AI の参照 | 規約を見落とす | 規約を確実に参照 |
| 運用での崩れ | 徐々に逸脱 | 規約逸脱を検知 |
| 拡張 | 属人的 | ルールに沿って拡張 |
つまり AI が UI 実装を担う時代になったことで、受託でも 「AI が正しく参照できる形でデザインシステムを整え、規約から外れない UI を維持する」ことが品質の前提になりました。これにより 「AI 運用でも崩れない UI 一貫性」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「人間向けドキュメント」から「機械可読な規約」へ
口頭やページに散らばった規約は AI に伝わりません。受託では トークン・利用ルールを構造化ファイルに集約し、AI が確実に参照できる状態にします。
構造 2: 「作って終わり」から「逸脱を検知」へ
納品後に規約が崩れる事故は珍しくありません。受託では Lint / 自動チェックで規約逸脱を検知し、運用フェーズの一貫性を担保します。
構造 3: 「属人的な拡張」から「ルールに沿った拡張」へ
場当たりの追加はシステムを壊します。受託では コンポーネント追加のルールと手順を明文化し、人にも AI にも拡張可能な設計を提供します。
受託で提供する「AI-Ready デザインシステム構築」5 フェーズ
フェーズ 1: 現状診断（1〜2 週間）
- 既存 UI / コンポーネントの棚卸し
- トークン（色 / 余白 / タイポ）の抽出
- 規約のばらつき・逸脱箇所の特定
- AI 実装で崩れている箇所の確認
フェーズ 2: 設計・構造化（2 週間）
- デザイントークンのコード化
- コンポーネント命名・メタ情報の整理
- 利用ルールの機械可読な規約ファイル化
- AI エージェント向けガイドライン整備
フェーズ 3: 実装・整備（2〜3 週間）
- コンポーネントライブラリの実装 / 整理
- 規約 Lint・自動チェックの導入
- ドキュメントと実装の同期
- サンプル / 使用例の整備
フェーズ 4: 検証・運用設計（1 週間）
- AI 実装で規約が守られるかの検証
- 逸脱検知の動作確認
- 拡張手順のレビュー
フェーズ 5: 引き渡し・保守（継続）
- デザインシステム運用 Runbook
- コンポーネント追加・変更フロー
- 定期的な一貫性レビュー
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| トークン | Design Tokens（W3C 形式） | CSS カスタムプロパティ |
| コンポーネント | フレームワーク共通ライブラリ | Web Components |
| 規約ファイル | 機械可読ガイドライン | Markdown 規約 |
| 可視化 | Storybook | カタログサイト |
| 規約 Lint | Stylelint / ESLint | 独自チェック |
| AI 連携 | エージェント向け規約 | プロンプトテンプレート |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| AI で UI 実装を進める | 全て人手で丁寧に作る |
| 複数サイト / 製品で UI 共通化 | 単一の小さなページのみ |
| 運用で UI が崩れがち | ほぼ更新しない静的サイト |
| 複数の制作会社が関わる | 自社一社で完結 |
| 長期運用するブランド資産 | 短命なキャンペーン |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | トークン / コンポーネント範囲 | カバー範囲の合意 |
| AI 対応 | 機械可読規約の提供 | 利用エージェントの想定 |
| 一貫性基準 | 逸脱検知の方法 | 許容する例外 |
| 拡張ルール | 追加・変更フロー | 自社運用の前提 |
| 引き渡し | Storybook / Runbook | 保守体制 |
| 継続保守 | 一貫性レビュー | 運用費用 |
顧客側 ROI 試算（複数サイト運用 / UI 一貫性想定）
| 項目 | 既存（人間向けのみ） | AI-Ready DS | 差分 |
|---|---|---|---|
| UI のばらつき | 運用で崩れる | 規約で一貫 | ブランド毀損の回避 |
| AI 実装の手戻り | 規約逸脱で修正 | 規約準拠で削減 | 実装工数の削減 |
| 新規ページ制作 | 都度ゼロから | 部品の再利用 | 制作リードタイム短縮 |
| 引き継ぎ | 属人的で困難 | 規約で容易 | 運用の継続性向上 |
| 年間効果 | — | — | 制作工数の削減 + ブランド一貫性の維持 |
初期費用をかけて取り組んでも、複数サイトの制作工数削減とブランド一貫性の維持で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: ドキュメントだけ作る
人向けの文書は AI に伝わりません。機械可読な規約を用意します。
落とし穴 2: 逸脱検知を入れない
規約は守られないと崩れます。Lint で自動検知します。
落とし穴 3: 実装とドキュメントがずれる
乖離すると信頼されません。同期する仕組みを作ります。
落とし穴 4: 拡張ルールを決めない
無秩序な追加でシステムが壊れます。追加フローを明文化します。
落とし穴 5: AI 実装で検証しない
机上では分かりません。実際に AI に作らせて検証します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | UI 棚卸し + トークン抽出 |
| Week 3〜4 | トークンのコード化 + 規約構造化 |
| Week 5〜7 | コンポーネント実装 + Lint 導入 |
| Week 8〜9 | AI 実装検証 + 逸脱検知確認 |
| Week 10〜13 | Runbook 整備 + 運用開始 |
まとめ — 「人だけが使う」から「AI も正しく使える」設計資産へ
AI が UI 実装を担う時代になり、デザインシステムは AI が機械的に参照できる形で整えることが品質の前提になりました。受託でWeb制作を支える立場では、トークンを構造化し、規約を機械可読にし、逸脱を検知し、拡張ルールとともに引き渡す 「AI-Ready デザインシステム構築」が、AI 運用でも崩れない UI 一貫性を成果物として届ける新しい主力サービスです。
「AI 任せで UI が崩れる」「複数サイトの UI を統一したい」「運用しても崩れないデザインシステムが欲しい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
