Meta、エージェント対応のReactデザインシステム「Astryx」をオープンソース化

Metaが社内で8年使ってきたデザインシステムを、外に出した。名前はAstryx。

ベータ版としての公開だが、想定する読み手は2種類いる。人間のエンジニアと、AIエージェントだ。

Astryxには、アクセシビリティに配慮したReactコンポーネントが150以上入っている。デザイントークンの仕組みも、StyleXという仕組みでのスタイル管理も含まれる。

さらにCLI（コマンドラインツール）とMCP（Model Context Protocol）にも対応していて、AIエージェントはコンポーネントの仕組みを推測しなくても、直接問い合わせられる。

これはMeta社内だけの話では終わらない。デザインシステムが機械にも読めるものになると、UIの土台に求められることそのものが変わっていく。それは同時に、周りの仕組みがまだ整っていない部分をあらわにする。

この記事のポイント

• Astryxは150以上のコンポーネントを持つReactデザインシステムで、Meta社内で8年育ってきたものがオープンソースのベータ版として公開された。
• StyleXという仕組みを使い、スタイルを実行時ではなくビルド時にCSSへ変換しておく。
• AIエージェントはCLIとMCPを通じて、コンポーネントやデザイントークンに直接問い合わせられる。仕組みを推測する必要がない。
• カスタマイズの主な手段はデザイントークンだ。チームはコンポーネントのコードを書き換えずに、自分たちのテーマを当てられる。
• 今回の公開は大きな流れの一部でもある。デザインシステムは、人がドキュメントを読むための道具から、ソフトウェアのエージェントが読み込んで使う土台へと変わりつつあるのだ。

社内ツールから公開標準へ

長年、多くの大企業はデザインシステムを社外に出さなかった。理由は分かる。

コンポーネント一式には、その会社らしい見た目、アクセシビリティの判断、エンジニアリングの約束事が詰まっている。めったに社外へ出ないものだった。

Metaはここで違う道を選んだ。UIの土台は、公開して標準化したほうが得をする基盤技術だという賭けだ。これはReactで既にやったことと同じ賭けでもある。

Reactが公開されているおかげで、Metaはその技術を知っているエンジニアを雇いやすい。外部の貢献者もエコシステムを育ててくれる。Astryxは、その論理を一段上のレイヤーで繰り返しているのだ。

このタイミングには、周辺技術の3つの変化が関わっている。

• React 19が成熟した。 Astryxは、React 19の並行処理機能に合わせて作られている。古いレンダリング方式を支える必要はない。
• StyleXが実用段階に入った。 Astryxはビルド時にスタイルを確定させるStyleXに依存している。その依存先が、もう安心して頼れる段階まで来たということだ。
• 社内利用が実績になった。 8年間の開発は、デモだけでなく、実際のプロダクトと実際の面倒な例外にも耐えてきたということを意味する。

ベータという表示は、中核部分への自信を示している。ただ、完成したとは言っていない。外部のチームがMetaの想定していない使い方をすれば、APIはまだ変わるかもしれない。

オープンソースとしての意見集めは、後付けの計画ではなく、最初から設計に組み込まれている。

この公開でいちばん目立つのは、最初から2種類の読み手を想定して作られている点だ。

Astryxは、後からAI用の拡張を付け足したコンポーネント集ではない。エージェント向けのツールは、コンポーネント本体と一緒に生まれてきた。

ここには、もっと広い流れが表れている。デザインシステムは、人がドキュメントで眺めるための道具から、ソフトウェアのエージェントが読み込んで使う基盤へと変わってきているのだ。

図2：Astryxの進化：内部ツール（8年間）からオープンスタンダードへの移行プロセス

Astryxの内側：コンポーネント、トークン、StyleX

Astryxの中心は3つの部分でできている。コンポーネントの集まり、トークンの仕組み、そしてスタイルを組み立てる仕組みだ。

この節のポイント

• 150以上のコンポーネントにはアクセシビリティが最初から組み込まれている。とはいえ、ページ全体のテストは依然として必要だ。
• デザイントークンを使えば、ライブラリを分岐させずに自分たちのブランドを反映できる。
• StyleXはビルド時にスタイルを確定させる。実行時のコストは減るが、スタイルを前もって決めておく必要がある。

アクセシビリティが最初から入っているコンポーネント

Astryxには150を超えるUIコンポーネントが入っている。Metaはこれらを「初期状態からアクセシブル」と説明する。

アクセシビリティを別のガイドラインで後付けするのではなく、各コンポーネントの中に組み込んでいるという主張だ。WCAGの基準を、そのまま満たす作りだとMetaは位置づけている。

初期状態からアクセシブルであることは、対応の手間を減らしてくれる。

ただし、それだけでページ全体の適合を保証するわけではない。

WCAGを満たすボタンがあっても、フォーカスの順序がおかしかったり、見出し構造が崩れていたり、コントラストに問題のある配色だったりすれば、ページ全体は良くならない。

完成したものは、やはりチーム自身でテストする必要があるのだ。

カスタマイズのためのデザイントークン

デザイントークンとは、色や余白、文字の大きさといった決まりごとに名前を付けたものだ。Astryxでは、これがシステムをカスタマイズする主な手段になっている。

企業は、コンポーネントを書き換えたり分岐させたりしなくても、トークンの値を変えるだけで自社のブランドを反映できる。

これは保守のしやすさに直結する。コンポーネント集を分岐させたチームは、本家の修正を1つずつ手作業で取り込まなければならない。一方、トークンを上書きするだけのチームは、更新をずっと楽に取り込める。

StyleX：実行時ではなくビルド時にスタイルを組む

Astryxが使うStyleXは、ビルドの段階でスタイルを小さな「原子的CSSクラス」にまとめてしまう仕組みだ。これは、Material UIやChakra UIのような有名なシステムとは違う方向性だ。

それらは、これまで実行時にCSSを組み立てる方式に頼ってきた。

この違いは、性能とできることの両方に影響する。

ビルド時にスタイルを決めておくと、実行時の負荷が減り、CSSの容量も小さく抑えられる。その代わり、スタイルは前もって分かっていないといけない。その場その場で自由にスタイルを組む余地は狭くなる。

分かりやすさと正しさのための、しぼられたAPI

Astryxのコンポーネントは、他の選択肢に比べてAPIの自由度が低めに作られている。

柔軟なpropsに慣れたチームには、最初は物足りなく感じるかもしれない。1つのコンポーネントがほぼどんな形にもなる、という使い方はできないのだ。

この制約は、わざとそうしてある。

きっちり決められたAPIは、動きが予測しやすい。予測しやすさは、2つの層に効いてくる。

• 人間にとっては、コンポーネントの仕様を読めば何をするか分かる。文書化されていないpropsの組み合わせを自分で調べる必要がない。
• エージェントにとっては、選べる選択肢が少なく、はっきりしている。propsが多すぎたり定義があいまいだったりするAPI相手に言語モデルがコードを書くと、見た目は正しそうでも動かない組み合わせを作りやすい。厳しいAPIは、そうした間違いの起きる余地そのものを狭めてくれる。

ここに、2種類の読み手を意識した設計の最初の現れが見える。機械にとって理解しやすくするための選択は、人間にとっても規律あるものになっているのだ。

エージェント向けの層：CLIとMCP

Astryxには、AIエージェントのために作られたツールが入っている。

コマンドラインインターフェースと、Model Context Protocol（MCP）への対応だ。ここで、デザインシステムはエージェントが実際に抱える問題に手を伸ばしている。

この節のポイント

• MCPを使えば、エージェントは訓練データからの推測ではなく、実際に存在するコンポーネントやトークンを直接調べられる。
• エージェントはコンポーネントのAPI、使えるデザイントークンを調べ、確認済みの部品から組み立てられる。
• 実際のコンポーネントとメタデータがずれてしまうと、エージェントが自信満々に壊れたコードを生み出す、という新しい失敗のパターンが生まれる。

MCPが「思い込み」と「実際」の差をどう埋めるか

AIエージェントが、デザインシステムの内部情報にアクセスできないままUIのコードを書くと、頼れるのは訓練データだけになる。そのデータは古かったり、抜けがあったり、まったく別のライブラリのものだったりする。

存在しないpropsを勝手に作ったり、名前が変わったトークンを使ったり、訓練時点より後に追加されたコンポーネントを見落としたりする恐れがある。

MCPは、エージェントに構造化された情報とツールを渡すための取り決めだ。Astryxはこれを使って、自分のコンポーネントやデザイントークンについての情報を外に出している¹。

エージェントは推測する代わりに、システムに直接聞ける。このコンポーネントはどんなpropsを受け取るのか。

使えるトークンは何か。そもそもどんなコンポーネントが存在するのか。

このツールがあることで、エージェントは次の3つを具体的にできるようになる。

• コンポーネントのAPI（受け取るpropsや選択肢を含む）を調べる
• 使えるデザイントークンを探す
• 推測ではなく、確認済みの部品からインターフェースを組み立てる

この発想は、エージェント向けツールの他の場所でも見かける形と重なる。

OKF Agent Memoryは、AIコーディングエージェントのために持続する作業記憶を用意する仕組みで、Gitに保存することで、セッションをまたいでも知識が消えないようにしている。

どちらのプロジェクトも、エージェントが幻覚を起こしたり、同じ事実を毎回調べ直したりしないよう、信頼できる構造化された情報を渡そうとしている。ただ、働く層は違う。

見えてくる傾向は明快だ。エージェントは、モデルがたまたま覚えていることや推測に頼るより、構造化されて検証可能な情報源から動くほうが役に立つ。

新しい危険：メタデータが実態からずれること

エージェント向けのツールは、新しい責任も生む。MCPが渡すメタデータは、コンポーネントの実際の姿を正確に表していなければならない。

もしメタデータが実際の動きからずれてしまえば、エージェントは自信を持って壊れたUIを作ってしまう。渡された情報こそが正しいと信じているからだ。

この失敗は、普通の幻覚よりも見つけにくい。開発者は、モデルの単なる推測なら疑うかもしれない。しかし「公式」のメタデータから組み立てられたコードは、信頼できるように見えてしまうのだ。

メタデータは、いくつかの形でずれていく。

• コンポーネントのpropsが変わったのに、メタデータが更新されない
• トークンの名前が変わったり廃止されたのに、古い名前がメタデータに残っている
• 動きが変わったのに、メタデータには反映されていない。新しく必須になったpropsや、変わった既定値などがそうだ
• バージョンの不一致が起きる。コンポーネントとMCPツールで、チームが使っているバージョンが違う場合だ

デザインシステムを保守するチームにとって、これはバージョン管理とメタデータの同期を、エンジニアリングの中心業務にするということだ。

もっとも確実な方法は、ビルドの過程でコンポーネントのソースからメタデータを自動生成することだろう。そうすれば、両者はずれない。

公開された資料には、Astryxがこの方式かどうかは書かれていない¹。導入するチームは、メタデータが実際のコンポーネントとどう同期しているのか、自分で確かめる必要がある。

UIとデータの間にある、抜けている層

Astryxが扱うのは見た目の層だけだ。デザインシステムとしては妥当な範囲だが、これだけではエージェントが自力でできることには限りがある。

この節のポイント

• Astryxが担うのはUIの生成だ。エージェントが正しく動くには、信頼できるデータへのアクセス、意味の理解、APIの取り決めも別に必要になる。
• 見た目が整ったインターフェースでも、その下の層が固まっていなければ、壊れた仕組みを覆い隠してしまう。
• フロントエンドの仕事は、スタイルを手で書くことから、仕組みの設計や検証へと重心が移っていく。

エージェントがUI以外に必要とするもの

エージェントによる自動化を最初から最後まで通すには、いくつかの層がすべて機能する必要がある。

1. 意図の理解。 ユーザーや開発者が何をしたいのかを、エージェントが理解する。
2. データへのアクセス。 どのシステムに必要なデータがあり、どう問い合わせればいいかを知っている。
3. 意味の理解。 各項目が何を意味し、どう関係し合い、どんな規則があるかを理解する。
4. APIの取り決め。 決まった形のインターフェースを通じて、データを読み書きする。
5. 見た目の表現。 そのデータを見せたり集めたりする、正しくアクセシブルなインターフェースを組み立てる。

Astryxは5番目の層をずっと確かなものにしてくれる。ただ、最初の4つには手が届かない。

この差は、実際の場面で効いてくる。Astryxは、見た目が正しく、コンポーネントの使い方も正しく、ブランドのトークンにも沿った、アクセシビリティの基準も満たすフォームを、エージェントが作る助けになる。

しかし、データへのアクセス方法や意味の理解がしっかりしていなければ、そのフォームは間違ったデータを取ってきたり、間違った送信先に間違った形でデータを送ったりするかもしれない。

整った見た目は、壊れた仕組みに間違った安心感を与えてしまうのだ。

AIエージェントのためのデータ層設計についての議論も、似たことを指摘している。

エージェントが企業のシステムとやり取りするために必要なバックエンドの基盤は、UIの層と同じくらい重要だということだ。Astryxは、もっと大きな仕組みの一部でしかない。

各層への投資のバランス

エージェント主導でUIを生成する仕組みは、いちばん整っていない層の水準までしか信頼できない。投資は、次のようなバランスで進むかもしれない。

• データアクセス用のMCPサーバー。 Astryxがコンポーネントに使っているのと同じ、構造化されて問い合わせ可能な形にする。
• 意味のスキーマ。 業務上の対象物どうしの関係を、機械が読める形で記述する。
• 一貫したAPI。 命名やエラー処理、取り決めを予測しやすくする。これは、Astryxがコンポーネントのpropsに課している規律と同じ発想だ。

この型は、層をまたいで繰り返し現れる。AstryxがUIでやっていること、つまり厳しい取り決めと構造化されたメタデータの組み合わせは、データの層にも必要なのだ。

エンジニアのスキルとエコシステムへの圧力

フロントエンドの仕事はどう変わるか

デザインシステムが人間とエージェントの両方に向けたものになると、フロントエンドの仕事には具体的な変化が起きる。

• コンポーネントAPIは、より厳しく、自己説明的になる。 柔軟で何でも受け取れるpropsは、むしろ問題になる。エージェントがそれを誤用しやすいからだ。
• 命名の重みが増す。 はっきりした名前のコンポーネントやトークンは、エージェントが見つけて正しく使いやすい。
• トークンの規律が必須になる。 値を直接書き込んでしまうとシステムを迂回することになり、エージェントの目には見えなくなる。それでは、この仕組み全体が意味をなさない。

これは、フロントエンドの専門性が要らなくなるという話ではない。求められる場所が変わるということだ。

スタイルやレイアウトを手で書く時間は減り、仕組みの設計や検証、そしてエージェントと人間が同じようにコンポーネントを理解できるようにする作業が増えていく。

想定される変化を整理すると、こうなる。

これから伸びていくスキル、つまりスキーマの設計、トークンの管理、検証といった仕事には、自動化しにくい判断力が必要になる。

コンポーネントAPIがなぜその形に制約されているのかを理解しているエンジニアは、ただ使えるだけのエンジニアより価値を持つ。

他のデザインシステムへの競争圧力

Astryxの登場は、他のオープンソースのデザインシステムに対する期待も引き上げている。

Material Design、Ant Design、Radixベースのライブラリといった既存の仕組みは、同等のエージェント向けツールを追加する圧力を感じるかもしれない。

その圧力がどこまで強まるかは、まだ定まっていない条件によって決まる。

• MCPの普及具合。 コーディングエージェントがツールや文脈を取り込む方法として、MCPが広く使われるようになれば、MCP対応はデザインシステムの標準機能になっていくだろう。逆に、対抗する規格が並び立つ状況になれば、その圧力は弱まる。
• 実際の効果の証拠。 エージェントが読めるメタデータによって、壊れたUI生成が明らかに減るという事例が示されれば、他のプロジェクトも追随するはずだ。効果がわずかなら、エージェント向けのツールは一部の限られた機能にとどまるかもしれない。
• Astryx自身の広がり方。 大企業によるベータ版公開だからといって、必ず使われるとは限らない。今後のリリースを重ねる中で、コミュニティがどう受け止めるかが試される。

これらの条件がそろえば、少数のエージェント対応システムに集約されていく可能性が高い。CLIやMCPの基盤への投資規模で、Metaに匹敵するのは小さなチームには難しいだろう。

エージェント対応への投資をしないプロジェクトも、手作業でUIを書くチームには十分使えるままかもしれない。ただ、エージェントがインターフェースの多くを書くような現場からは、外れていく可能性がある。

一方で、それを打ち消す要素もある。エージェント対応を支える中身、つまり厳しいAPI、明確な命名、構造化されたメタデータは、規模の話ではなく、どれだけ規律を守れるかの話だ。

よく設計され、メタデータが自動生成される小さなデザインシステムは、大きくて緩いシステムより、エージェントにとって使いやすいかもしれない。小さなプロジェクトにも道は残っている。

ただし、意図して設計する必要がある。

ちょっと立ち止まって

デザインシステムを選ぶとき、つい「コンポーネントの数が多いもの」「見た目が洗練されているもの」を基準にしていないだろうか。

Astryxが示しているのは、これからは「機械にも読めるかどうか」が同じくらい効いてくるということだ。

今使っているツールやライブラリは、あなたのチームだけでなく、エージェントにとっても分かりやすい形をしているだろうか。

そして、もし自分のチームがコードを書く役割の一部をエージェントに委ねていくなら、UIの見た目が整っていることに、どこまで安心してよいものだろうか。その下にあるデータやAPIの層は、本当に信頼できる状態だろうか。

図3：Astryxのアーキテクチャ：コンポーネント、トークン、StyleXの関係

図5：AIエージェント層：CLI と MCP を通じたコンポーネント・トークンへのアクセス

図7：UI Meets Data：欠落していたレイヤーの統合

図10：チームへの影響：Astryx導入による段階的な変化

脚注

1. https://www.meta.com/blog/quest/open-sourcing-astryx-metas-agent-ready-design-system/ ↩ ↩²