社内で使い続けたツールが、ある日オープンソースとして公開される。そういう経緯を持つライブラリは、公開を前提に設計されたものとは少し違う重みを持つことがあります。Astryxはまさにそのパターンで、Metaの内部で8年間、1万3千を超えるアプリを支えてきたデザインシステムが2025年にオープン化されたものです。「agent ready」という言葉がdescriptionに入っているのも気になるところで、この記事ではリポジトリの機能紹介と設計上の特徴を一緒に見ていきます。
どんなライブラリか
Astryxは、React 19以降をベースにしたUIコンポーネントライブラリです。150以上のアクセシブルなコンポーネント、ブランドレベルのテーマ機能、ダークモード対応、CLIツール、そして7種類のプリセットテーマ（neutral・butter・chocolateといった個性的な名前が並ぶ）をひとつのパッケージ群として提供しています。
ビルドプラグインやBabel設定は不要で、CSSのインポートとテーマプロバイダーを用意するだけで動き始めます。スタイリングはStyleXで書かれていますが、利用者はその事実をほぼ意識する必要がなく、TailwindでもCSSモジュールでもプレーンCSSでも上書きできます。現時点ではベータ版として公開されており、スター数は1万2千台に達しています。
設計でここが上手い
「スタイリング実装の隠蔽」と「上書きの自由」の両立
デザインシステムが抱えがちな矛盾として、「スタイルを一元管理したいが、プロジェクトごとのカスタマイズも許したい」というものがあります。Astryxはこれを、StyleXによる内部実装をコンシューマーに見せないという構造で解決しています。外から見たとき、コンポーネントはただのReactコンポーネントであり、classNameを渡せば既存のスタイルシステムで上書きができます。テーマはCSSカスタムプロパティの上書きセットとして実装されているため、コンポーネントのソースをフォークすることなくデザインをブランド化できます。この「内部の実装を握りながら、外への拘束を最小化する」構造は、ライブラリ設計として参考にできるアプローチだと思います。
swizzleによるエスケープハッチの設計
コンポーネントの内部構造を触りたくなったとき、ラッパーで囲み続けると最終的にコードが複雑になります。AstryxはswizzleというCLIコマンドでコンポーネントの完全なソースをプロジェクトにコピー出力し、以降はそのコピーを自分のコードとして管理できる仕組みを持っています。ライブラリの制約を超えたい場面で「フォーク全体」か「ラッパーを重ねる」かしか選択肢がないのは、導入者にとって地味にきつい問題です。swizzleはその間にある第三の選択肢として機能します。Gatsbyのプラグインやフレームワークのテンプレート上書き機構に近い発想ですが、コンポーネント単位でピンポイントに適用できる点が異なります。
「エージェント対応」をAPIとドキュメントの一貫性で実現
READMEには「人とAIアシスタントが同じ方法でビルドできる」という原則が明示されています。CLIのコマンドをpackage.jsonのscriptsに登録することを推奨しているのも、AIアシスタントが直接CLIを呼び出したときのパスエラーを防ぐための実用的な配慮です。また、各コンポーネントに.doc.mjsという専用のドキュメントファイルが置かれており、CLAUDE.mdにはそれをAIが参照するエントリポイントとして明示しています。「agent ready」という言葉を使うリポジトリは増えてきましたが、実際にドキュメント構造・CLI設計・AGENTS.md（vibe-testスクリプトの存在からその使われ方が分かる）を一体として設計しているケースはまだ少数派だと思います。
コンポーネントに「指針をコードで強制しない」という選択
READMEのPrinciplesに「Guidance over enforcement」という言葉があります。値を渡したらコンポーネントはそれをレンダリングする、という考え方です。これは裏返すと、利用者への「あなたを信頼している」というメッセージでもあります。ただし信頼だけに依存せず、命名・Props・合成のルールを全コンポーネントに統一し、ドキュメントに徹底的に記述することで予測可能性を担保しています。ルールを共有された規約として持ちながら、コードによるガードレールを最小化する、というバランスの取り方です。
こういう人に向くかも
React 19以降を使っているプロジェクトで、デザインシステムをゼロから組むコストを省きたいチームには合いそうです。特に、テーマ機能やダークモードを自分で実装するのが面倒で、かつ既存のスタイリング手法（TailwindやCSS modules）を捨てたくないという状況にはフィットします。
AIアシスタントを使ってUIを組む機会が増えているチームにも向くかもしれません。コンポーネントのドキュメントが機械可読を意識した構造になっているため、AIに「このコンポーネントをどう使うか」を尋ねたときの回答精度が上がりやすいです。逆に、独自のデザイン言語をすでに持っていてコンポーネントの見た目を抜本的に変えたい場合、テーマのカスタマイズ範囲で収まるか、swizzleが必要になるかを最初に確認すると判断しやすいと思います。
設計の良し悪しをどこで見るか
評価の切り口として、いくつか注目している観点があります。
ドキュメントの深度と一貫性
150以上のコンポーネントを持つライブラリで、ドキュメントの網羅性と品質を維持するのは相当な労力を要します。Astryxは各コンポーネントに.doc.mjsを置く構造を採用していますが、その記述がどれだけ均質かは実際にStorybook（https://facebook.github.io/astryx/storybook/ で確認できます）を眺めてみると分かります。ドキュメントが薄いコンポーネントが混在すると、「一度学べば後は予測できる」というPrinciplesの約束が崩れます。ここはベータ版であることを念頭に置きつつ、導入前に触れてみたいコンポーネント群のドキュメントを手動で確認しておくといいでしょう。
メンテナンスの継続性
Metaという大きな組織がバックにいることは、継続性という面では一定の安心感があります。ただし、社内向けシステムがオープン化されたあと、外部コントリビューターとの関係をどう育てるかは別の問題です。WikiにAPI規約・デザイン規約・コンポーネントライフサイクルが整備されており、コントリビューション前に読むべきルーブリックが用意されている点は、外部参加者を受け入れる準備がされている印象を受けます。Discordコミュニティの活発さも、継続性を判断する材料になりそうです。
トークン経済性（AIアシスタントとの協働コスト）
「agent ready」を標榜する以上、AIとの協働コストは特に見ておきたい観点です。CLAUDE.mdには、コンポーネントごとの.doc.mjsをオンデマンドで参照する構造が書かれており、150以上のコンポーネント全体のドキュメントをまとめてコンテキストに流し込む必要がない設計になっています。vibe-testというテストスクリプトが内部的にあり、「LLMがAstryxのコンポーネントを正しく使えるか」を定量評価する仕組みまで持っています。これは珍しい取り組みで、ライブラリ自体がAIとの相性を計測しながら改善されているという意味になります。
想定外の使われ方への備え
swizzleの存在がここで効いてきます。コンポーネントをそのまま使う・テーマで上書きする・swizzleでソースを取り出す、という3段階の逃げ道があることで、想定外の要件に対してもゼロから書き直さずに対処できる可能性が広がります。ただし、swizzleで取り出したコンポーネントは以降のバージョンアップの恩恵を自動では受けられなくなるため、その管理コストは利用者が引き受けることになります。
自分が書くなら、どこを変えるか
現在の実装を見て気になるのは、React 19以降というピアバージョン要件の高さです。エコシステム全体でReact 19への移行はまだ途中段階にあるチームも多く、「使いたいが既存プロジェクトのReactバージョンが合わない」という状況は起こりやすいです。導入可能な最小Reactバージョンをもう少し下げるか、移行ガイドを充実させるかのどちらかが、普及速度に影響するかもしれません。
もう一点は、@astryxdesign/chartsが@canaryタグにしか存在せず、安定版がない状態である点です。データ可視化を含むプロダクトを作ろうとしたとき、チャートだけ別ライブラリを持ち込む必要が出てきます。コア部分の安定化を優先するのは合理的な判断ですが、利用者に「どこまでが実用可能か」をREADMEでもう少し明示的に伝えると判断しやすくなるかなとは思います。ベータという表記はありますが、パッケージごとの成熟度の差が把握しにくいのが現状のもどかしさです。
導入を検討するときのチェック観点
- React 19以降を使っているか、または移行の目処がついているか
- 既存プロジェクトのスタイリング手法（Tailwind、CSS modulesなど）と
className上書きで共存できるか確認する - 使いたいコンポーネントのStorybook上のドキュメントが十分な内容か実際に開いて確認する
- テーマのカスタマイズ範囲でデザイン要件が満たせるか、それともswizzleが必要になるか見積もる
- チャートや実験的なコンポーネントを使う予定がある場合、
@canaryタグの安定度をissueやDiscordで確認する - AIアシスタントを使ってUIを書く場面があるなら、AGENTS.mdとvibe-testの仕組みを把握しておく
- MITライセンスであることを確認したうえで、プロジェクトのライセンス方針と照合する
設計思想の取り回し方
Astryxを一言で評価するなら、「実際に使い続けた人たちが作ったライブラリ」という密度を設計に感じるリポジトリです。swizzleのエスケープハッチ、StyleX実装の隠蔽、vibe-testによるAI相性の定量計測、といった機能はどれも、架空のユーザーではなく実際の痛みから生まれたものに見えます。ベータという段階を踏まえたうえで、React 19を使っているプロジェクトでコンポーネントライブラリを探しているなら、触ってみる価値は十分にあると思います。
