デザインシステムの本質と、AI時代の設計思想

沢山あったら、それは便利なのか？

例えば、汎用性を考えて100色のカラーパレットを用意しても、実際に使用するのが20色程度なら、残りの80色にはどのような役割があるのでしょうか。各色の用途や使用条件が明確でなければ、ページや画面ごとに色の使い方がばらつき、アクセシビリティの確認にも余分な工数が発生します。ボタンやフォームなどのコンポーネントも同様です。

デザインシステムで重要なのは、判断基準を共有して不要な迷いやばらつきを減らし、誰が実装しても一定水準以上の品質を保てることです。

UIコンポーネントライブラリとデザインシステム

UIコンポーネントライブラリとデザインシステム、私は両者を次のように分けて考えています。

• UIコンポーネントライブラリ：
  再利用可能な素材や部品を体系的に管理するもの
• デザインシステム：
  再利用可能な素材や部品の利用原則から実装仕様までを体系的に規定する仕組み

例えば、モーダルウィンドウ。
デザインツール上では、背景を暗くして中央にウィンドウを表示すれば、それらしいものが完成します。しかし、実際に動作するUIとして考えると多くの定義が必要です。

ここには設計と実装において、二つの異なる基準があります。

一つは、そもそもモーダルを採用すべきなのかという設計上の基準。もう一つは、採用したモーダルをどのような仕様で動作させるのかという実装上の基準です。見た目が同じであっても、これらの基準が異なれば、ユーザー体験やアクセシビリティに差が生じます。

実装における共通の仕様を用意し、定義された品質基準を満たした状態で再利用できるようにする。さらに、その部品を採用する理由や使用条件まで共有する。ここまで含めて設計することでデザインシステムはシステムとして機能すると私は考えています。

実装者に依存しないためのデザインシステム

もう一つ重要なのが、コンポーネントを組み合わせる際の基準です。

例えば、同じカード型コンポーネントを使っても、「商品一覧」「ニュース一覧」「採用情報」では、それぞれ伝えたい情報が異なります。何を見出しにするか、画像をどこに配置するか、どの情報を優先するか。ここでの取捨選択は、個々のコンポーネントの仕様だけでは決まりません。コンテンツの目的や情報構造に応じて、適切なレイアウトや表現方法を選択する必要があります。

また、見出しや本文の階層、文章の長さ、注釈の扱いなども、ページ全体の構成に関わります。これらの選択基準が定義されていなければ、実装者は画面を制作するたびに、適切な構成や表現方法を検討し、試行錯誤しなければなりません。同じような画面であっても、その都度設計を繰り返すことになり、余分な労働コストが発生します。

さらに、選択が実装者個人の経験や技量に委ねられることで、同じ目的の画面でも情報の優先順位やレイアウトに違いが生じ、品質のばらつきにつながります。そのため、デザインシステムでは、個々のコンポーネントだけでなく、情報の表現方法や構成パターンにも共通の選択基準を設け、実装の属人化と重複作業を減らすことが重要だと考えています。

プロジェクトの共通基盤へ

一方で、デザインシステムだけでは扱いきれない領域もあります。

例えば、WebサイトやWebシステムには「どのようなページ、画面が必要なのか」「どの情報を優先するのか」「どのような導線を設計するのか」と言った、部品のみならず画面構成や情報設計に関わる品質管理です。これらはプロジェクトの目的や要件、コンセプト、UX/IAなどに基づいて決める必要があります。

私たちは現在、こうした領域まで含めて体系化するため、『「K2 Project Base（新しいタブで開きます）」』という事業基盤の開発を進めています。これは、要件定義からコンセプト設計、UI/UX設計、実装、運用までを一貫した考え方で進め、制作の品質と生産性を高めるための仕組みです。

共通基盤の活用と継続的な改善

K2 Project Baseでは、プロジェクトの目的や要件、コンセプト、画面構成などの設計情報を各工程で共有し、デザインシステムの共通規則を適用して実装します。共通マスターからプロジェクト専用の環境を作り、要件定義から設計・実装・運用まで進めます。そこで生まれた改善や新しい機能をマスターにも反映し、次のプロジェクトに活用します。制作を重ねるほど共通基盤を進化させ、品質の安定化と制作コストの削減につなげる仕組みです。

K2 Project Base（新しいタブで開きます）

デザインシステムによる品質の標準化

そこで重要になるのが、使用する色や余白、アイコン、コンポーネントなどの仕様だけでなく、それぞれの選択基準や使用条件まで明確に定義されたデザインシステムです。AIがそれらを参照して生成することで、ページや図版ごとのばらつきを抑えることができます。

さらに、デザインシステムで定義されている共通の品質基準に基づいて、生成結果を別のAIエージェントに検証させることで、人間による確認や修正の負担も軽減できます。

ただし、デザインシステムだけでは限界があります。

共通の規則に従ってUIを生成できても、そのプロジェクトにどのようなページや画面が必要なのか、どの情報を優先するのかを判断するには、プロジェクト固有の目的や要件が必要です。例えば、ボタンの適切な形状や動作を定義できても、そのボタンをどこに配置し、ユーザーにどのような行動を促すべきかは、プロジェクトの目的や情報設計によって変わります。AIにこれらの判断を任せるためには、その根拠となる上位の設計情報も共有する必要があります。

一貫性あるプロジェクト設計の要

そこで、先ほど紹介した「K2 Project Base」が重要になります。

デザインシステムがUIの設計・実装規則を担うのに対し、Project Baseでは、その上位にある要件定義やコンセプト設計、UX/IAなどの設計情報も管理します。AIが各工程で共通の設計情報を参照できるようになれば、制作の途中で判断基準が変わったり、工程ごとに異なる解釈が生じたりする問題を減らせると考えています。

例えば、要件定義で定めた目的やコンセプトを基に画面を設計し、デザインシステムの共通規則に従って実装・検証する。各工程で共通の設計情報を参照することで、AIを活用しても一貫した品質基準を維持しやすくなります。現在は、AIを活用してワイヤーフレームをFigmaに展開し、デザイン生成から実装までを連携させる仕組みを検証しています。将来的には、こうした仕組みをさらに発展させ、要件定義から設計、デザイン、実装、検証までをAIと連携させていくことを考えています。