design toolsJune 23, 20267 min read

2026年、マシンリーダブルなデザインシステムは必須だ

AIツールは今や、スクリーンショットだけでなくデザインシステムそのものからビルドする。混乱を増幅させずに、トークン、コンポーネント、ステートをマシンが読める構造にする方法。

By Boone
XLinkedIn
machine readable design systems

今やマシンが読むのはスクリーンショットではなくシステムだ

デザインシステムを今すぐマシンリーダブルにしろ。AIデザインツールは完成した画面の画像からではなく、作業の下にある構造からビルドする。そしてその構造こそが、今やツールが作用する対象だ。

Figma AI と Claude Design はもはや、フラットな画像からあなたの意図を推測しない。トークン、コンポーネント定義、名前付きバリアントを読み取り、見つけたものをもとにビルドする。システムを読み取るツールは、そこにエンコードされたすべての決定を引き継ぐ。きれいなものも、手抜きなものも、等しく。

つまり、構造が出力品質の上限を決める。鋭いシステムは鋭い生成物を生む。雑なシステムは雑な生成物を、しかも高速で生む。

AIツールに読み取られる構造化されたデザインシステムレイヤーのボクセルイラスト
AIツールに読み取られる構造化されたデザインシステムレイヤーのボクセルイラスト

マシンリーダブルが実際に意味すること

マシンリーダブルとは美しいという意味ではない。ツールがすべての値、名前、関係を推測なしに解決できるという意味だ。

人間のデザイナーは少しずれたグレーのボーダーを見て、肩をすくめ、だいたい合わせる。マシンは肩をすくめられない。border.subtle というトークンを見つけて使うか、あるコンポーネントにハードコードされた迷子の #E3E3E1 を見つけて、その事故をルールとして扱うかのどちらかだ。

4つの要素がシステムをマシンにとって読みやすくする:

  • すべての値を名前で定義するトークン。コンポーネント内に生のhex値を浮かせない
  • 一度定義されたコンポーネント。バリアントはコピーではなく名前付きプロパティとして
  • default、hover、focus、disabled、error として明示的なバリアントで記述されたステート
  • 所属するシステムをひっそりと矛盾させるデタッチされた一品物がないこと

雑なシステムがAIを遅くするのではなく悪化させる理由

雑なシステムはAIツールを遅くしない。雑さの生産を加速する。ほとんどの人はこれを逆に理解している。

デザイナーが混沌としたファイルを引き継いだとき、その混沌は自己制限的だった。人間のコピペ速度には限界があり、3つのボタンが食い違っていれば気づく傾向があるからだ。マシンにはそんな摩擦はない。4つの競合する「プライマリ」ボタンを持つシステムに Figma AI を向ければ、4つすべてを使った5つ目の画面を喜んで生成する。構造の中にどれが本物か教えるものが何もないからだ。

AIは雑なデザインシステムを修正しない。雑さをより速く出荷する。

リスクの全体が一行で言える。ツールはアンプであり、アンプは信号が良いかどうかを気にしない。

競合するボタンバリアントとハードコードされた値を持つ混沌としたデザインファイルのボクセルイラスト
競合するボタンバリアントとハードコードされた値を持つ混沌としたデザインファイルのボクセルイラスト

トークンはマシンが読める単位だ

reference、system、componentの階層を示す Material Design 3 トークンの概要
reference、system、componentの階層を示す Material Design 3 トークンの概要

m3.material.io でトークンシステムを見る

トークンはマシンが確信を持って読める最小単位だ。だからこそ、マシンリーダビリティはここで勝敗が決まる。トークンは値を指す名前付きの決定、color.surface.raisedspace.4radius.md だ。

これは2年前より今の方が重要だ。名前は解釈を生き延び、hexコードはそうでないからだ。マシンが color.text.danger を見ると意図がわかる。#D72638 を見ると数字しかわからず、dangerを表示するつもりのなかった場所にその数字を再利用する。

実際のシステムが正しく行われた例を示している。Material Design 3 はトークンを階層構造としてドキュメント化している。reference から system へ、component へ。ツールが辿れる名前付き階層だ。Shopify Polaris はトークンを、誰かが目視しなければならない Figma ファイルではなく、公開されたクエリ可能なセットとして出荷している。

デザインシステムオーナーマシン向けに公開しているもの
PolarisShopify公開されたクエリ可能なトークンと構造化されたコンポーネントカタログ
Material Design 3Google階層化されたデザイントークン、reference から system へ、component へ
PrimerGitHubバージョン管理されたコードとして出荷されるトークンとコンポーネント
Atlassian Design SystemAtlassian製品横断の名前付きトークンとドキュメント化されたコンポーネントステート

マシンが解決できるコンポーネントとステート

名前付きUIコンポーネントのクエリ可能な構造化されたカタログを示す Shopify Polaris コンポーネントページ
名前付きUIコンポーネントのクエリ可能な構造化されたカタログを示す Shopify Polaris コンポーネントページ

polaris.shopify.com でカタログを閲覧する

コンポーネントがマシンリーダブルなのは、マシンがバリアントを名前で区別できる場合だけだ。variant プロパティが primary、secondary、tertiary に設定された1つのボタンは読みやすい。"Button"、"Button 2"、"Button final"、"Button (new)" という名前の5つの別々のコンポーネントは推測ゲームであり、マシンは推測する。

ステートはほとんどのシステムがひっそりと失敗する場所だ。デザイナーはデフォルトステートを描いて出荷し、残りは誰かの頭の中の伝承として放置する。マシンは伝承を読めない。

すべてのインタラクティブなコンポーネントには、明示的な名前付きバリアントとして次の5つのステートが必要だ:

  • Default
  • Hover
  • Focus
  • Disabled
  • Error

ステートが名前付きバリアントでなければ、ツールは発明するか省略するかのどちらかだ。どちらも間違いだ。

リビルドなしでシステムをAI対応にする方法

システムを燃やす必要はない。マシンリーダビリティはほぼクリーンアップ作業であり、最も価値の高い修正は視覚的なものではなく構造的なものだ。

実際のファイルに対してこのチェックリストを使え:

  • ハードコードされたすべてのhex、スペーシング、radius値をトークン参照に置き換える
  • 重複したコンポーネントを名前付きバリアントを持つ1つの定義に統合する
  • 不足しているステートを明示的なバリアントとして追加する。default、hover、focus、disabled、error
  • システムと矛盾するデタッチされたインスタンスをすべて削除またはリアタッチする
  • 意図で名前をつける。red.600 ではなく text.danger とし、名前が意味を持つようにする
  • 人間が当然と思っているがドキュメント化されていないルールを、ツールが読めるテキストとして書き下す

構造的な修正を先にやれ。トークンと重複コンポーネントだ。それらがマシンが最初に読むものだからだ。読みやすいが地味なシステムは、デタッチされた一品物だらけの美しいシステムに、ツールが生成するたびに勝る。

Brainy はデザイナーが実際に出荷される作業で、より鋭い判断をより速く下せるよう支援する。Brainy クリエイターコミュニティと一緒にビルドしよう

コンポーネント定義内で生のhexコードを置き換える名前付きデザイントークンのボクセルイラスト
コンポーネント定義内で生のhexコードを置き換える名前付きデザイントークンのボクセルイラスト

これがデザイナーに何を変えるか

仕事が一段階上がる。百の画面にピクセルを押し込む時間が減り、それらの画面がコンパイルされるシステムを定義する時間が増える。あなたの仕事の価値は構造にエンコードされた決定にシフトする。

これはシステム思考が好きな人には朗報であり、実行速度を価値としていた人には悪いニュースだ。トークンからビルドするツールは、鋭いシステムデザイナーの価値を上げ、速いが雑なデザイナーの価値を下げる。

手抜きの決定のコストも上がる。ハードコードされた色はかつて1つの画面に収まっていた。今はツールが生成するすべての画面に伝播する可能性があるため、人間がボトルネックだったときには決してなかった方法で小さなショートカットが積み重なる。

FAQ

マシンリーダブルとはすべての値が名前で解決できることを意味する

トークンが生の値を置き換え、コンポーネントは名前付きバリアントで一度定義され、すべてのステートが明示的だ。マシンが名前を読む代わりにピクセルを解釈しなければならない場合、その部分はマシンリーダブルではない。

AIツールのためにデザインシステムをリビルドする必要があるか?

ない。作業の大部分はクリーンアップだ。ハードコードされた値をトークンに置き換え、重複コンポーネントを統合し、ステートに名前をつける。リビルドが答えになることはまれだ。まず構造を引き締めれば、同じファイルがツールにとってはるかに読みやすくなる。

マシンリーダブルな優れたリファレンスとなるデザインシステムはどれか?

Shopify Polaris と Material Design 3 が最も明確な公開例だ。どちらも構造化されたトークンとドキュメント化されたコンポーネントを公開しているからだ。GitHub Primer と Atlassian Design System も強力なリファレンスだ。どちらも静的ファイルではなくバージョン管理されたコードとしてトークンとコンポーネントを出荷している。

AIデザインツールはデザインシステム作業を置き換えるか?

逆だ。ツールがあなたのシステムからビルドするとき、システム自体が最も価値の高い成果物になる。反復的な画面構築が自動化され、トークンとコンポーネントにエンコードされた決定はより重要になる。

AIの出力を最も早く壊すものは何か?

デタッチされた一品物とドキュメント化されていないステートだ。デタッチされたインスタンスはツールに矛盾を教え、欠落したステートはツールに発明を強いる。どちらも確信に満ちた間違った出力を生み、確認するまで正しく見える。

まず構造、それからマシンにビルドさせろ

変化は述べるのは簡単で、実行するのは不快だ。ツールは今やシステムを読んでそこからビルドするため、システムが製品であり、画面はその副産物だ。

ツールを向ける前に構造を読みやすくしろ。値をトークン化し、コンポーネントを重複排除し、ステートに名前をつけ、デタッチされた一品物を殺せ。そうすれば Figma AI、Claude Design、そして次に出てくるものが、雑さの乗数ではなく力の乗数になる。

デザインシステムとツールについてのより詳しい解説は、Brainy のペーパーを読み続けてほしい。そして Brainy クリエイターコミュニティと一緒にビルドしたいなら、私たちが作っているものを見に来い。

Brainy はデザイナーが実際に出荷される作業で、より鋭い判断をより速く下せるよう支援する。

Brainy helps designers make sharper calls, faster, on the work that actually ships. See what we are building for creators.

Get Started

More from Brainy Papers

Keep reading