Metaが社内で育ててきたデザインシステム Astryx（facebook/astryx）が2026年に公開され、★11,754を集めている。掲げる看板は「fully customizable and agent ready」——人間とAIエージェントの両方が同じ作法で組み立てられるUIライブラリだ。だがこの手の「AI対応」は看板だけのことも多い。本記事は公式ドキュメントの主張をなぞらず、MCPサーバーを実際に叩き、CLIの出力バイト数を測り、Metaが公開している98回分の夜間ベンチ結果を集計して、その看板が実体を伴うのかを確かめる。
30秒でわかるAstryx
・正体：Metaが社内で約8年使い13,000超のアプリを支えてきた（README記載）デザインシステムのOSS版。React 19+ / StyleX、MIT、2026年8月時点でBeta・npm安定版は 0.3.0
・規模：CLIが返すコンポーネント数は155、テーマは7種、ページテンプレートとCLIまで一式
・agent readyの実体：①公式サイトのMCPサーバー（search/getの2ツール・稼働確認済み）②llms.txt ③CLIの --dense モード。3つとも本記事で実際に応答を確認した
・最大の特徴：毎晩AIに同じ課題を解かせて自社システムを採点し、結果をWikiで公開している。比較対象はshadcn/ui＋Tailwind
・そして負けている：公開98回中、勝者がshadcn/ui側だったのは54回、Astryx単体は20回。総合平均は90.3点 対 94.4点
デザインシステムそのものの構造（トークン・コンポーネント・ガイドラインの3層）を先に押さえたい場合は、デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】を先に読むと本記事の位置が掴みやすい。
Astryxとは——Metaの社内標準がそのまま出てきた
Astryxとは何か、を一言でいえば「Meta デザインシステムの社内標準がほぼそのまま出てきたもの」だ。2026年1月にGitHubへ現れ、8月時点で★11,754・fork 996・オープンissue 329という規模で動いている。pushed_at は本記事執筆当日で、開発は現在進行形だ。
READMEによれば、Astryxは「Metaの中で過去8年にわたって育ち、社内で最も使われ最大のデザインシステムになった」もので、13,000以上のアプリを支えてきたという。これはMeta側の自己申告であり外部から検証できる数字ではないが、成果物の作り込み——207個のコンポーネントドキュメント、7つの完成テーマ、コードモッド付きのCLI——を見る限り、社内で長く使われた蓄積があること自体は疑いにくい。
技術的な土台は2つに絞られる。React 19以降（react/react-dom はpeer依存）と、Metaが開発したCSS-in-JSの StyleX だ。ただしStyleXは「内部の実装言語」であって、利用側に強制されない。ここがAstryxの設計上の核心で、READMEは「Astryxは自身のスタイルをStyleXで書くが、それは利用者からは見えない」と明言している。利用側はビルド済みCSSをimportし、型付きのReactコンポーネントを使うだけ。上書きは className 経由でTailwindでもCSS Modulesでも素のCSSでも構わない。
component --list が返す実数は155だった（@astryxdesign/core 0.3.0 で本記事調べ）。READMEの「150+」表記と整合するREADMEは「150+ components」と書くが、実際の数え方は複数ある。リポジトリの packages/core/src 配下の .doc.mjs は207ファイル、ディレクトリ単位では122。CLIが component --list で返す「Components」の見出しは 155。これは誤りではなく数え方の違いで、.doc.mjs にはサブコンポーネント（AvatarGroupOverflow や AvatarStatusDot のように親と同じモジュールからexportされる部品）やフックの定義も含まれる。読者が「使える部品の数」として受け取るべきはCLIの155に近い。
何を解決するのか——「囲い込まないAPI」という賭け
Astryxが解こうとしている問題は、READMEの4つの主張に凝縮されている。
・Open internals：コンポーネントはどの階層でも合成できるよう作られ、内部の構成部品も直接exportされる。さらに深く触りたければ swizzle でソースごと自分のプロジェクトへ取り出せる
・No styling lock-in：StyleXは内部実装。利用側のスタイリング手段は自由
・Customize without wrapping：テーマはCSSカスタムプロパティの上書き集合なので、forkもラッパーも書かずに見た目を自分のものにできる
・Built for people and agents：API・ドキュメント・CLIを一体で設計し、人間とAIが同じ参照先から同じやり方で組み立てる
4つ目が本記事の主題だが、3つ目も実物で確認できる。公式サイトのThemesページでは、Neutral / Stone / Gothic / Matcha など7テーマを切り替えると、同じ画面構成のままトーンだけが差し替わる。
Astryxの使い方——インストールと最初の一歩
導入はビルドプラグインを必要としない。コア・テーマ・StyleXランタイムを入れ、CLIを開発依存に置くだけだ。
npm install @astryxdesign/core @astryxdesign/theme-neutral @stylexjs/stylex
npm install -D @astryxdesign/cli
CLIは package.json にスクリプトとして登録する運用がREADMEで推奨されている。理由が興味深く、「AIアシスタントや新しい開発者が直接CLIを叩いたときのパス誤りを避けるため」と明記されている。エージェントが自分のツールを正しく呼べるかまで想定して導線を設計しているわけだ。
"scripts": {
"astryx": "node node_modules/@astryxdesign/cli/clients/cli/bin/astryx.mjs"
}
登録後は npm run astryx -- component --list のように使う。CLIには component / docs / template / swizzle / theme / upgrade / doctor / search のほか、manifest --json（CLI全機能の機械可読な目録）まで用意されている。エージェントが「このCLIで何ができるか」を自力で列挙できるようにするための口だ。
読者の3つの問いへの答え
・何ができる：React 19の上に155のアクセシブルなコンポーネント、7テーマ、ページテンプレートを、ビルド設定をほぼ足さずに導入できる
・何を解決する：AIにUIを書かせると起きる「デザイントークンを無視した mt-[13px] 的な値の散乱」「セッションごとに違う実装スタイル」を、型付きAPIと単一の参照先で抑え込む
・何を代替できる：shadcn/ui＋Tailwindの組み合わせ。ただし後述するとおり、AI生成の総合点では現時点でshadcn/uiが上に立っている
「agent ready」の実体は3つの経路
看板の中身を、実際に叩いて確かめる。Astryxがエージェントへ知識を届ける経路は3つある。
astryx.atmeta.com/mcp"] A --> C["② llms.txt
astryx.atmeta.com/llms.txt"] A --> D["③ CLI
astryx docs / component"] B --> E["search: 自然文で候補を返す
get: props・例・テーマ情報"] D --> F["--dense: 散文を圧縮して出力"] E --> G["生成されたUIコード"] F --> G C --> G
①MCPサーバーは公式ドキュメントサイトに同居している。route.ts の実装では search と get の2ツールだけを公開し、サーバー名は astryx、バージョンは 2.0.0。実際に tools/list を投げると、実装どおりの2ツールが返ってきた。さらに search で「table with sorting」を問い合わせると、Table を筆頭に候補と import 文まで返る。
設計で目を引くのはコンテキスト予算の管理だ。ソースには「1件あたり約1.5Kトークン」というコメントがあり、大きなドキュメントトピックは MAX_TOPIC_BRIEF_CHARS = 4000 を超えると全文を返さず、セクション見出しの一覧と「section を指定して取り直せ」という誘導に切り替わる。コード中のコメントはこれを “context bombs”（コンテキスト爆弾）への防御と呼んでいる。ドキュメントを大量に持つ側が、読ませる量を自分で絞る作りになっている。
②llms.txt はドキュメントサイト上で配信されており、HTTP 200で取得できることを確認した。③CLI は次章で実測する。
確認したこと／していないこと
MCPサーバーの稼働（tools/list と search の応答）、llms.txt とStorybook・Sandboxの200応答、CLIの出力バイト数は本記事で実際に取得した。一方、「社内13,000アプリ」「8年の歴史」はREADMEの記述であり、外部から検証する手段がない。前者はMeta側の主張として扱っている。
--dense は何を、どれだけ削るのか（実測）
CLIには --dense（--lang dense と等価）という、エージェント向けにドキュメントを圧縮するモードがある。リポジトリには圧縮のルールを定めた専用のプロトコル文書まであり、「冠詞や埋め草の動詞を落とす」一方で「must / never / instead のような振る舞いを変える語は必ず残す」「コンポーネント名は省略しない」と細かく規定されている。
では実際にどれだけ減るのか。@astryxdesign/cli 0.3.0 で、同じ対象を通常モードと --dense で出力してバイト数を比較した。
結果ははっきり割れた。設計原則の散文である docs principles は 2,601→1,597バイトで38.6%減。一方 docs color と docs typography、docs spacing は1バイトも減らない（0.0%）。コンポーネントでも、説明文が主体の Toast は17.9%減るのに、巨大なprops表を抱える Button は4.7%しか減らない。主要8コンポーネントの合計では77,221→73,052バイト、削減率5.4%にとどまった。
これは不具合ではなく仕様どおりだ。圧縮プロトコルは「prop名・型・デフォルト値は docs 側に残す」「サンプルコードも残す」と明記している。つまり --dense が圧縮するのは散文だけで、トークン表・型定義・コード例には手を付けない。そして多くのコンポーネントドキュメントでは、バイト数の大半を後者が占める。
念のため「圧縮版が用意されていないだけではないか」も確認した。圧縮プロトコルには「未整備なら英語版に黙ってフォールバックする——利用者は圧縮されていないことに気づけない」という警告があるためだ。しかし実測では、npm公開版の .doc.mjs 208ファイル中207、mainブランチでは207/207に docsDense が存在した。カバレッジはほぼ100%で、5.4%という数字は「未整備」ではなく「圧縮対象がそもそも散文だけ」という設計の帰結である。
期待値として押さえておきたいのは、--dense はコンテキストを劇的に減らす魔法ではないということだ。設計原則やガイドラインをまとめて読ませる場面では効くが、個別コンポーネントのAPIを引く用途では削減幅は一桁%に収まる。
毎晩の「vibe test」——Metaは自社システムを採点し、公開している
ここがAstryxを他の「agent ready」を名乗るライブラリと決定的に分ける部分だ。AstryxはAIがこのデザインシステムでUIを正しく書けるかを毎晩測り、その点数をWikiで公開している。
仕組みはリポジトリ内の internal/vibe-tests に入っている。骨格はこうだ。
・同じプロンプト70本を用意し、10カテゴリ（制約つき機能・ワークフロー・データ表示・レスポンシブ・タイポグラフィ・テーマ変更など）と3段階の複雑さに分類
・それを4つの環境へ同一条件で与える：Astryx／Astryx+Tailwind／Baseline（実物のshadcn/ui＋Radix＋Tailwind、24コンポーネント）／生HTML
・期待コンポーネント名はエージェントに渡さない（評価用にのみ使う）。エージェントはプロジェクト内のファイルを自力で探索して使い方を知る
・採点は出自を伏せて行い、全環境に同じ基準を適用する。READMEには「公平な評価者」「差異は被験システムのみ」「答えを漏らさない」といった不変条件がチェックリストとして明記されている
・人格（naive / experienced / adversarial）や、10ターンの会話を挟んで品質がどう劣化するかを0・6・8・10ターン目で測るモードまである
採点軸は6つで、Wikiに定義がある。Correctness（存在しないpropやimportを書いていないか）、Accessibility、Code Quality、Efficiency、Maintainability、そして参照画像がある場合のみのDesign。なおスコアはあくまで数値の台帳で、そこで見つかったAPI上の問題は別途 Vibe Test — API Concerns（issue #3164） に集約する運用になっている。agent ready デザインシステムを名乗る以上、指標と改善の導線まで分けて回している格好だ。
そして結果が公開されている。2026-03-20から08-05までの98回分を集計した。
集計結果は、Metaにとって都合の良いものではない。
・勝者の内訳：Baseline（shadcn/ui）が54回で最多。Astryx単体は20回、引き分け14回、Astryx+Tailwindが10回
・平均点：Astryx 90.3、Astryx+Tailwind 94.1、Baseline 94.4、生HTML 81.1
・直接対決：AstryxとBaselineを1日ずつ比べると27勝65敗6分とAstryxの負け越し
・直近30回でもBaseline 13回・引き分け6回・Astryx 6回・Astryx+TW 5回で、傾向は変わっていない
一方で明確に分かることもある。どの構成もAIに素のHTMLを書かせるより20点前後高い（生HTML平均81.1）。デザインシステムを与えること自体の効果は、4環境の比較の中で一貫して出ている。そしてAstryx+Tailwindは平均94.1でBaselineとほぼ互角（21勝19敗7分）だ。StyleX前提の使い方より、Tailwindと併用したほうがAIの成績が良いという結果になっている。
崩れるのは「正しさ」だけ
さらに、Astryx側は6軸の内訳も39回分公開している。これを集計すると、負けの正体が見える。
・Accessibility 98.9点・Code Quality 99.4点——ほぼ満点で、しかも極めて安定している（Code Qualityは39回すべてが98点以上）。「a11yを既定の道にする」という設計目標は、少なくともこのベンチ上では達成されている
・Correctness は平均79.2・標準偏差23.2と乱高下する。最低は2点、一方で満点の100点も10回ある
・つまり総合点の上下は、ほぼCorrectnessの上下。AIがAstryxで書いたコードは「読みやすくアクセシブルだが、日によって動かない」
Correctnessは「存在しないpropやimportを書いていないか」を測る軸だ。155のコンポーネントを持つ発展途上のAPIに対し、AIがハルシネーションを起こす頻度が日によって大きく振れている、と読める。API変更が続くBeta期のシステムでは避けにくい現象でもある。
この数字の読み方に注意
これは「shadcn/uiのほうが優れたデザインシステムだ」という結論ではない。測っているのはAIエージェントが初見でどれだけ正しくコードを書けるかという一点だけで、実行時性能・バンドルサイズ・デザインの質・大規模運用での保守性は対象外だ。shadcn/uiはコードを自分のリポジトリへコピーする方式で学習データにも大量に含まれるため、この種の指標では有利になりやすい。Astryxは2026年に公開されたばかりで、LLMの学習データにほとんど存在しない。それでもなおMetaが自社不利のスコアを毎晩公開し続けている点こそが、この題材で最も評価すべき部分だと言える。
shadcn/ui 比較——他のUIツールとどう使い分けるか
AIにUIを書かせる文脈で並ぶ選択肢を、性格の違いで整理する。
| Astryx | shadcn/ui | tweakcn等のテーマ編集 | 生成UI（tambo等） | |
|---|---|---|---|---|
| 提供形態 | npmパッケージ（@astryxdesign/core） |
ソースをコピーして自分の物に | 既存テーマの視覚編集 | 実行時にLLMが部品を選ぶSDK |
| 出自 | Meta（社内8年・README記載） | コミュニティ | 個人/コミュニティOSS | スタートアップ |
| スタイリング | StyleX（内部実装・利用側は自由） | Tailwind必須 | Tailwind/CSS変数 | 任意 |
| 部品数 | 155（CLI実測） | 必要な物だけ選んで導入 | — | 自分で登録 |
| AI向け導線 | MCP・llms.txt・--dense CLI |
学習データに豊富に存在 | — | SDKがAIの実行を前提 |
| AI生成の実測 | 公開ベンチあり（本記事集計で平均90.3） | 同ベンチのBaseline（同94.4） | — | — |
| ライセンス | MIT | MIT | 各OSS準拠 | 各OSS準拠 |
使い分けの目安はこうなる。
・いま業務で堅実に選ぶなら：shadcn/ui。エコシステム・情報量・AIの初見成功率いずれも現時点で優位。テーマの作り込みはshadcn studio - テーマ生成機能付きshadcn/uiコンポーネント集の活用法のようなツールで補える
・Astryxが刺さるのは：React 19前提の新規プロジェクトで、Tailwindのユーティリティ地獄を避けたい／アクセシビリティを既定にしたい／テーマでブランドを作り込みたいケース。とくにAstryx+Tailwind構成はベンチ上でBaselineと互角だった
・AIとデザインシステムの接続そのものに関心があるなら：複数のデザインシステムとエージェントを繋ぐOpen Design：Claude DesignのOSS代替、72デザインシステム×10AIエージェント対応と読み比べると、「システム側がAIに合わせる」Astryxのアプローチの特異さが際立つ
導入前に知っておくべき制約
・Beta表記かつ安定版は 0.3.0。npmには684バージョンが登録され、直近はcanaryが1日に数回公開される速度で動いている。API変更は当然起こる前提で組む必要がある
・React 19以降が必須。React 18のプロジェクトはまず本体の移行が要る
・一部パッケージは未成熟。チャート系の @astryxdesign/vega と @astryxdesign/charts は @canary タグでのみ公開され、安定版が存在しない。実験的コンポーネント群の @astryxdesign/lab はnpm未公開
・CLIはプロジェクト構成に依存する。@astryxdesign/core を入れていない場所で component を叩くと失敗する（本記事の検証中も、CLI単体だけを入れた状態では Could not find @astryxdesign/core package で止まった）
・日本語の情報がほぼ無い。公式ドキュメント・Wikiとも英語で、CLIの多言語出力も現状は英語・中国語・dense形式のみ
週間ダウンロード数は @astryxdesign/core で118,646（2026-07-29〜08-04）。公開から2か月弱の新参としては動きがあるが、shadcn/uiのエコシステム規模とは桁が違う点は踏まえておきたい。
まとめ——看板は本物だった、ただし成績は正直だった
冒頭の問いに答える。Astryxの「agent ready」は実体を伴っている。MCPサーバーは実際に稼働して応答を返し、llms.txt は配信され、CLIにはエージェント向けの圧縮モードと機械可読な機能目録がある。README冒頭からCLIのスクリプト登録手順に至るまで、「AIが自分のツールを正しく呼べるか」を織り込んで設計されている。
しかし本当に価値があるのは、その先だ。Astryxは主張を測っている。同じ課題を競合構成に解かせ、出自を伏せて採点し、自社が負けている結果をそのまま毎晩公開している。98回中54回でshadcn/uiに敗れ、平均点でも4ポイント下という数字を、Wikiに積み上げ続けている。
読者にとっての実務的な結論は「いますぐ乗り換える理由は薄い」だ。だが「AI時代のデザインシステムはどう評価されるべきか」という問いに対して、Astryxはキャッチコピーではなく再現可能な採点手順という形で一つの答えを出している。--dense が5.4%しか削らない事実も、Correctnessが2点まで落ちる日がある事実も、彼ら自身が公開したデータから導ける。その透明性こそが、このリポジトリの一番の見どころだろう。
参照ソース
・facebook/astryx — 公式リポジトリ（README・internal/vibe-tests・apps/docsite/src/app/mcp/route.ts・.claude/skills/dense-compression-protocol.md）
・Astryx 公式ドキュメント
・Astryx Wiki — Vibe Test Scores（夜間ベンチの公開スコア。本記事の集計元）
・Astryx Wiki — Vibe Evaluation（6軸の定義とベンチ実施手順）
・@astryxdesign/core — npm（版数・公開日・ダウンロード数）
