propを幻覚するAIのために、MetaのデザインシステムastryxはMCPを積んだ

CursorやClaude Codeに「そのボタン、いい感じにして」と頼むと、たまに <Button variant="primary" size="lg"> みたいなコードが返ってくる。動かして初めて気づく。そのコンポーネントに variant なんてpropは存在しない。AIが、それっぽいAPIをでっち上げていた。

これは能力不足というより構造的な問題だ。LLMはあなたのデザインシステムの中身を知らない。学習データに含まれる無数のUIライブラリの平均像から「たぶんこういうpropがあるはず」と補間する。社内独自のコンポーネントほど、この幻覚(hallucination)は起きやすい。ドキュメントを毎回コンテキストに貼れば減るが、人間がそれをやり続けるのは現実的ではない。

Metaが6月にMITライセンスで公開し、7月16日に再びGitHubトレンド入りした astryx は、この問題に正面から答えたReactデザインシステムだ。売りは150以上のアクセシブルなコンポーネントでも7種のテーマでもない。設計の出発点が「人間とエージェントの両方が読める」ことに置かれている点にある。公式ドキュメントの表現を借りるとこうだ。

built for how we build now: by people and the agents working alongside them.

🤖 エージェントを一級の読者として扱う

普通のデザインシステムは、ドキュメントを人間向けのWebサイトとして公開する。AIにそれを読ませたければ、開発者がページをコピペするか、スクレイピング頼みになる。astryxはここを逆転させ、エージェントが直接クエリできる経路を最初から用意した。

中心にあるのがMCP(Model Context Protocol、AIツールが外部データソースに接続するための共通規格)サーバーだ。Metaがホストするエンドポイントを設定ファイルに1つ書くだけで、Claude DesktopでもCursorでもWindsurfでも、同じ口からデザインシステムを引ける。

{
  "mcpServers": {
    "xds": {
      "type": "url",
      "url": "https://astryx.atmeta.com/mcp"
    }
  }
}

このサーバーが公開するツールは2つだけ、というのが潔い。自然言語でコンポーネントやテンプレートを探す search(query) と、名前を渡してprop・使い方・コード例つきの完全なドキュメントを引く get(name)。エージェントは「Dialogのpropは何か」を推測せず、その場で正解を取りに行ける。幻覚を後段で検出するのではなく、そもそも推測させないアプローチだ。

MCPを使わない、あるいは使えないツール向けの道も塞いでいない。CLIには --dense というフラグがあり、公式ドキュメントいわく「AIのコンテキストウィンドウ向けにトークン効率化した形式」でドキュメントを吐く。ChatGPTやClaudeのチャット欄に貼る前提の出力だ。

astryx component --list
astryx component Dialog --dense
astryx docs styling --dense

🛠️ 実際に組み込む

導入自体は普通のnpmパッケージと変わらない。coreとテーマ、CLIを入れて初期化する。

npm install @astryxdesign/core @astryxdesign/theme-neutral @astryxdesign/cli
npx astryx init

npx astryx init はプロンプトを出さない非対話コマンドとして作られている。ドキュメントは「no prompts — so it's safe for AI agents, CI, and scripts」と明記していて、エージェントに init を任せても対話待ちで固まらない。エージェントが実行しても詰まらない配慮が随所にある点が、後付けのAI対応との差だ。

コンポーネントはカテゴリ別のサブパスからimportする。

import {Button} from '@astryxdesign/core/Button';
import {VStack} from '@astryxdesign/core/Layout';

export default function Page() {
  return (
    <VStack gap={2}>
      <Button label="Hello Astryx" onClick={() => alert('Hi!')} />
    </VStack>
  );
}

もう一つ実務で効くのが、ツール別のルールファイルを生成するコマンドだ。エージェント向けの規約を、各ツールが期待する場所とフォーマットで書き出してくれる。

npx @astryxdesign/cli init --features agents --agent claude   # .claude/CLAUDE.md
npx @astryxdesign/cli init --features agents --agent cursor   # .cursorrules
npx @astryxdesign/cli init --features agents --agent codex    # AGENTS.md

見てのとおり、CLAUDE.md・.cursorrules・AGENTS.md と出力先が全部違う。エージェント向けの規約をどこにどう置くかの標準はまだ乱立していて、astryxはそれを1つに賭けず全部生成する側に回った。この割り切りは現状を正直に映す。

📊 何が新しいのか

構造化されたコンポーネントドキュメント自体は目新しくない。Storybookのdocsもpropの型を持っている。違いは、ドキュメントを「人間が見る成果物」ではなく「エージェントが叩くAPI」として設計・配布した点にある。バックエンドがOpenAPIで10年前にやったこと(実装とは別に、機械可読な契約を先に定義し、そこから人も機械も生成する)を、フロントのデザインシステムに持ち込んだと捉えるのが一番しっくりくる。実際、MarkTechPostは同梱のJSONマニフェストをOpenAPI仕様になぞらえて報じている。

	従来のデザインシステム	astryxのやり方
AIへの情報供給	人がドキュメントをコピペ	MCPで直接クエリ / --dense出力
propの正しさ	学習データからの推測に依存	get(name) で実物を取得
規約の配布	READMEに散在	ツール別ルールファイルを生成
初期化	対話プロンプトが混じる	非対話でエージェント/CIが実行可

astryxはReact 19以上を前提に、Metaのコンパイル時CSSエンジンStyleXの上に構築されている。報道ベースの数字だが、社内では8年かけて1万3千を超えるアプリで揉まれてきたという。つまり公開されたのは実験的プロトタイプではなく、実運用の蓄積を持つ内製システムだ。

冷静に見ておきたいこと

過度な期待は禁物だ。MCPで正しいpropを引けても、エージェントがそれを正しく使う保証はない。取ってきたドキュメントを無視して幻覚する余地は残る。astryxがやったのは幻覚をゼロにすることではなく、正解へのアクセスコストを推測より低くして「わざわざ間違える理由」を減らしたことだ。

導入判断の材料として現実的なのは、これがMeta内製XDSの思想がそのまま出たものだという点だろう。コンポーネントの設計思想もテーマ体系(neutral, butter, chocolate, gothic, matcha, stone, y2k)もMetaの流儀で、既存プロダクトへの部分導入には向かない。StyleX前提であることも、スタックによっては摩擦になる。それでも、AIがコードを書く割合が増え続けるなら、「エージェントが読めること」をライブラリの一級要件に据える発想は、astryx固有の話では終わらない。自作のコンポーネント群にMCPの口とルールファイル生成を足すだけでも、社内でAIに書かせるUIの事故はかなり減るはずだ。そのテンプレートを、Metaが公開ソースで見せてくれた意味は小さくない。

一次ソースは以下。