AIエージェントが読めるデザインシステムとは何か、Astryxで考える

Claude Code や Codex にコンポーネント実装を任せたとき、なぜか「いかにもAIが作りました感」が漂う画面が出てくる。
ボタンの高さが画面ごとに微妙にズレていたり、やたらと影が強かったり、同じプロダクトなのにスペーシングのトーンが揃わなかったり。
これはエージェントの能力の問題ではなく、 渡している情報の設計 の問題です。

そこに正面から向き合ったのが、Meta が公開した Astryx というデザインシステムです。
「agent ready」を設計思想の軸に据え、人間とエージェントが同じツールで並走できることを目指して作られました。

「エージェント対応」という言葉が設計上どういう意味を持つのかを具体的に読み解きながら、Astryx を MUI・shadcn/ui と比較していきます。
自分のプロジェクトで Astryx を採用すべきかどうかを判断できる視点を持ち帰ってもらえれば十分です。

AIエージェントがデザインシステムを「読む」とはどういうことか

エージェントはドキュメントサイトを読んでいません。
コンテキスト窓に流し込まれたソースコード・型定義・命名規則を手がかりに、次のコードを確率的に生成しています。

つまりエージェントにとって「デザインシステムを読む」とは、型定義から props の意図を推測し、ファイル構成から設計の文脈を読み取り、命名規則からバリアントの使い分けを判断する、という一連の推論プロセスのことです。
ここで重要なのは 構造的な明示性 で、「暗黙の設計意図」がコードの奥に埋まっていると、エージェントは学習データの平均値に引っ張られます。

坪田朋さんが自前のデザインシステムを作った際の記録に、この問題の本質がよく表れています。
「いい感じに」「シンプルに」と指示してもダメで、AIには「いい感じ」の基準がない。
基準がないから、学習データの中で「よくあるデザイン」を確率的に再現してしまう。
その結果、同じプロダクトなのに画面ごとにボタンの高さが違い、色のトーンがズレ、スペーシングがバラつく。

この観察が示しているのは、問題の所在がAI側ではなくこちら側にある、ということです。
ブランドの個性や設計上の制約は、明示的に構造化して渡さないと出力に反映されない。
コンテキスト窓に収まる情報が曖昧であればあるほど、エージェントは「インターネットの平均」に向かって収束していく。
では「明示的に構造化する」とは、具体的にどういう設計を指すのか。それが次の問いになります。

MUI・shadcn/ui でエージェントに実装させると何が起きるか

MUI と shadcn/ui はそれぞれ異なる理由でエージェントとの相性に課題を持っています。
問題の根っこは共通していて、「設計意図がコードとして読み取れない」という点です。

MUI の場合、sx prop とカスタムテーマの上書きが共存できる設計が問題を生みます。
以下のようなコードを見てください。

// MUI でよく起きる「どちらの流儀で書くか」問題

// パターンA: sx prop でインラインスタイルを当てる
<Button
  sx={{
    backgroundColor: '#1a73e8',
    borderRadius: '8px',
    padding: '10px 24px',
  }}
>
  送信
</Button>

// パターンB: テーマで定義した値を使う（本来こちらが正しい）
<Button variant="contained" color="primary">
  送信
</Button>

// パターンC: 両方が混在する（エージェントが量産しがちな状態）
<Button
  variant="contained"
  sx={{ borderRadius: '8px' }}
>
  送信
</Button>

エージェントはこの3パターンのどれを選ぶべきか、型定義だけからは判断できません。
テーマに borderRadius が定義されているかどうかはランタイムの情報であり、コンテキスト窓に乗らないからです。
結果として、エージェントはパターンAとパターンCを混在させたコードを量産し、複数画面を並べると一貫性が崩れます。

shadcn/ui の場合は少し事情が違います。
コンポーネントのソースコードがプロジェクト内に展開される設計は、エージェントにとって「読めるコードが手元にある」という意味で相性が悪くありません。
ただし Tailwind CSS のクラスの組み合わせが事実上無限にあるため、エージェントが複数画面を実装していくうちに一貫性が崩れやすい。
「このボタンは px-4 py-2 で、あのボタンは px-3 py-2 で」という微妙なズレが積み重なります。

共通する構造的な問題は、コンポーネント間の依存関係やバリアント命名の暗黙の意図が、エージェントのコンテキストに乗らないことです。
「このバリアントはこの文脈でしか使わない」という設計上の判断は、ドキュメントの中にしか存在せず、コードからは読み取れません。

Astryx が「agent ready」のために施している設計の具体

Astryx が「agent ready」を謳う根拠は、いくつかの具体的な設計判断に裏付けられています。

まず StyleX による静的・決定論的なスタイル記述 です。
StyleX は Meta が開発した CSS-in-JS ライブラリで、ランタイムでのスタイル計算を排除し、ビルド時に静的なクラスを生成します。
MUI の sx prop のように「どこでも何でも書ける」自由度がなく、スタイルの記述方法が一意に決まります。
エージェントが「正しい書き方」を選ぶ際に迷う余地を、設計レベルで削っています。

次にトークン体系の設計です。
Astryx はセマンティック層とプリミティブ層を分離し、型として公開しています。
セマンティック層のトークンは値ではなく用途を名前で表現する設計で、エージェントが補完候補を受け取ったとき「この文脈でどのトークンを使うべきか」を名前から推論できます。
プリミティブ層（生の色値）とセマンティック層（用途別の参照）を分離することで、エージェントが「なんとなく合いそうな色」を直接書くことを防ぐ構造になっています。

ここで注意しておきたいのは、Astryx の具体的なトークン名やAPIの詳細は現時点では公式リポジトリを直接確認する必要があるという点です。
以下は StyleX とセマンティック/プリミティブ分離という 設計思想を示す擬似コード であり、実際の Astryx のAPIとは異なる可能性があります。

// 設計思想を示す擬似コード（実際のAstryxのAPIではありません）
// StyleX では stylex.create() でスタイルを定義し、
// セマンティックトークンを参照することで「なぜこの値か」が名前から読める

import * as stylex from '@stylexjs/stylex';

// プリミティブ層: 生の値
// セマンティック層: 用途を名前で表現したトークンを参照する
const styles = stylex.create({
  container: {
    // 「surface の default 背景色」という用途が名前から読み取れる
    backgroundColor: tokens.color.surface.default,
    // 「medium サイズの余白」という意図が補完候補に現れる
    padding: tokens.spacing.medium,
  },
});

// variant に渡せる値は型定義として公開されており
// エージェントが型推論で把握できる
<Button variant="primary" size="medium">
  送信
</Button>

この設計の肝は、エージェントが「なんとなく動くコード」ではなく「設計意図に沿ったコード」を選べるように、選択肢を型と命名で絞り込んでいる点です。
自由度を意図的に削ることで、エージェントの出力が収束する先を「インターネットの平均」ではなく「このシステムの設計」に変えています。

もう一つ重要なのが コンポーネントの内部構造が「開いている」 という点です。
Astryx は「どの粒度でも合成できる設計」を明示しており、エージェントが部分的に操作しやすい構造になっています。
モノリシックなコンポーネントではなく、内部の構成要素を取り出して組み合わせられる設計は、エージェントが「このコンポーネントの一部だけ変えたい」という操作を自然に表現できることを意味します。

そして TypeScript 比率約76%（GitHub リポジトリより）という数字も、エージェントの型推論を助ける実質的な指標です。
型が充実しているほど、エージェントはコンテキスト窓の情報から設計意図を読み取れます。

現時点の制約と、それでも試す価値があるかどうか

正直に言うと、Astryx はまだ「使い始めるのに覚悟がいる」段階です。

現在ベータで、リポジトリには lab パッケージ（実験的コンポーネント）と vega パッケージ（チャートラッパー）が存在しますが、どちらも npm には未公開と明記されています。
公開直後の GitHub スター数・フォーク数も少なく、外部コミュニティの成熟度はこれからという状況です。

Meta 内部で8年・13,000以上のアプリという実績は確かに重みがあります。
ただしそれは Meta の内部環境での話であり、外部プロジェクトでの検証はまだ薄い。
「大企業内で磨かれた」と「外部で使える」は別の話で、ここは冷静に見ておく必要があります。

スタックの依存も考慮が必要です。
Astryx は React と StyleX の上に成り立っています。
既存プロジェクトが別のスタイリング手法を使っている場合、導入コストは単純なライブラリ追加では済みません。
StyleX 自体の学習コストも含めて見積もる必要があります。

日本語情報がほぼない点も現実的な障壁です。
英語のリポジトリとドキュメントを一次情報として読み進められるチームかどうかが、採用判断に直接影響します。

ただ、一つ持ち帰ってほしい視点があります。
「設計の明示性」という思想自体は、Astryx を採用しなくても自前のデザインシステムや CLAUDE.md に応用できます。
トークンをセマンティック層で命名する、バリアントの使い分けを型で制約する、スタイルの記述方法を一意にする。
これらは既存のスタックの上でも実践できる判断です。
Astryx を試さなくても、この設計思想を知っておくこと自体に価値があります。

どのデザインシステムを選ぶか——判断の3軸

「エージェントに UI 実装を任せるなら Astryx 一択」とは言い切れません。
プロジェクトの状況によって答えは変わりますし、正直なところ shadcn/ui が依然として有力な場面の方が多いと思っています。

判断の軸として意識しているのは3つです。
エージェントへの依存度がどのくらいか、プロジェクトが新規か既存スタックへの追加か、そしてチームが StyleX と英語ドキュメントを扱える体制にあるか。

Astryx が本領を発揮するのは、新規の React プロジェクトでエージェントに UI 実装を大量に任せる予定があり、かつ StyleX を受け入れられるチームである場合です。
この条件が揃っていれば、「設計意図がコードに乗る」という恩恵を最大限に受けられます。
逆に、既存プロジェクトへの後付け、StyleX 以外のスタイリング手法が確定している場合、ベータ段階のライブラリをプロダクションに乗せるリスクを許容できない場合は、素直に見送った方がいいです。

shadcn/ui については、エージェントとの相性が「意外と悪くない」という評価を持っています。
コンポーネントのソースがプロジェクト内に展開されているため、エージェントはそれをコンテキストとして直接読めます。
Tailwind の一貫性問題は確かにありますが、トークン設計と命名規則を自前で整備することである程度カバーできます。
エコシステムの成熟度・日本語情報の豊富さ・コミュニティの大きさを重視するなら、shadcn/ui は今でも有力な選択肢です。

結局のところ、Astryx が提示した「エージェント対応」という設計思想の価値は、Astryx を使うかどうかとは独立しています。
「設計意図をコードとして明示的に表現できているか」という問いは、どのデザインシステムを選んでもエージェントと並走する開発では問い続ける価値があります。

株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援に取り組んでいます。
エージェントを使った開発フローの設計や、デザインシステムの整備についてご相談があれば、お気軽にご相談ください。
詳しくはお問い合わせページからご連絡ください。