【Astryx】150種類以上のReactコンポーネントと、AIに正しい画面を書かせるMCPサーバーの仕組みを初心者向けに解説【2026/08/11】

前回は、パソコンの中で動いているプロセスが「なぜ動いているのか」を遡って辿るコマンドラインツールについて、ずいぶん長々と書いた。書きながら自分でも夢中になってしまったところがある。ただ今日は、その流れとはまったく関係のない方向へ行こうと思う。画面の見た目、つまり人の目に触れる側の話だ。

そもそも「デザインシステム」とは何なのか

Web サービスやアプリを作るとき、ボタン、入力欄、チェックボックス、表、ダイアログといった部品を、だれかが毎回どこかで作っている。1人で作っている小さなサイトなら、それでもさほど困らない。けれど関わる人が増え、画面の数が増えてくると、同じはずのボタンが微妙に違う色や角の丸みで散らばりはじめる。

デザインシステムというのは、その散らばりを防ぐための「共通の部品箱と、部品の使い方の取り決め」をまとめたもの、と考えてもらうのがいちばん近いと思う。色や文字の大きさといった基礎的な決めごとがあり、その上にボタンなどの部品があり、さらにその上に「フォームはこう組む」「表はこう組む」といった定番の組み方がある。

　　家を建てるときに、柱や窓枠の寸法をあらかじめ規格化しておくのに似ている。規格が決まっていれば、大工が10人に増えても、できあがった家の廊下の幅がばらばらになることはない。

Astryx が何者なのか

Astryx（アストリクス）は、Meta が社内で8年間使い続けてきたデザインシステムを、そのままオープンソースとして公開したものだ。ライセンスは MIT で、商用利用も含めてかなり自由に使える。2026年6月末から7月にかけて段階的に公開され、公開から数週間で GitHub のスターが9,000を超えている。

私が興味を持ったのは、この「8年」と「13,000」という数字だった。社内で13,000以上のアプリケーションに使われてきた、と説明されている。Facebook、Instagram、Threads も含まれるという。つまり、実験室で作られたきれいなものではなく、現場で削られ続けてきたものが出てきた、という話になる。

技術的には React と StyleX の上に載っている。StyleX というのは Meta が作っているスタイルの書き方の仕組みで、書いた見た目の指定をビルド時（アプリを組み立てる段階）にまとめて CSS に変換してくれるもの、と理解しておけばだいたい足りる。ただしここが少し面白いところで、Astryx を使う側は StyleX を意識しなくてよいように作られている。CSS はあらかじめ組み立てられた状態で配布されるので、ビルド用の追加設定は要らないとされている。

150種類以上の部品と、7つのテーマ

含まれるコンポーネントは150種類以上。すべて TypeScript の型が付いていて、アクセシビリティ（目が見えにくい人や、マウスを使わずキーボードだけで操作する人にも使えるようにする配慮）に対応していると説明されている。

見た目の着せ替えにあたる「テーマ」は7種類が最初から入っている。neutral、butter、chocolate、matcha、stone、gothic、y2k という名前が付いていて、名前を見るだけでなんとなく想像がつくのが少し楽しい。ダークモードにも標準で対応している。

そして着せ替えは、色・書体・角の丸み・動きといった「トークン」と呼ばれる細かい単位で書き換えられるようになっている。公式の説明では「トークンのレベルでカスタマイズするので、書き直しなしでアプリが自分のものになる」という言い方をしている。

構造は3層に整理されている。土台にあたる Foundations（文字組み、色、レイアウト、アクセシビリティの基本部品）、その上の Components（150以上の部品そのもの）、さらにその上の Patterns（表、フォーム、ウィザード、ナビゲーションといった、よくある画面の定番の組み方）。

私がいちばん面白いと思った部分

ここからが本題かもしれない。Astryx は「AI エージェントが読めること」を最初から設計に入れている。

近ごろは、AI に「ログイン画面を作って」と頼んで、そのまま動くコードを書いてもらう、という作り方をする人が増えた。ただ、これをやったことがある人なら、たぶん一度は同じ壁にぶつかっている。AI が、実在しないプロパティ（部品に渡す設定項目のこと）を堂々と書いてくることがあるのだ。それらしい名前で、それらしい書き方で、しかし存在しない。動かして初めて気づく。

　　外国語で書かれた説明書を、辞書を引きながら読んでいる人に似ている。文法は完璧で、文章としても自然なのに、辞書に載っていない単語をひとつだけ、自信満々に混ぜてくる。

Astryx がこれに対して用意した答えは、わりと素朴だ。人間向けのドキュメントを読ませるのをやめて、機械が読むための一覧を別に用意した。付属の CLI（コマンドラインで動かす道具）が、使えるコマンド、引数、フラグ、返ってくる値の型を、JSON という機械可読の形式ですべて吐き出す。これを manifest（マニフェスト）と呼んでいる。

さらに、MCP サーバーが組み込まれている。MCP は Model Context Protocol の略で、AI に対して「こういう道具と情報がここにあります」と教えるための共通の作法だと思ってもらえばいい。Cursor、Claude Code、GitHub Copilot、Windsurf、VS Code といった環境から、この作法を通じて Astryx の部品情報を直接参照できる。

つまり、AI が推測で書くのではなく、正解表を見ながら書けるようにした、ということになる。派手さはないが、私はこの方向がかなり現実的だと感じている。モデルを賢くする話ではなく、モデルに渡す情報の側を整える話だからだ。

公式が掲げている原則のひとつに「One system for humans and AI」という言葉がある。人間と AI が同じ API、同じ作法で同じように作る、という意味だ。もうひとつ「Guidance over enforcement」（強制ではなく案内）という原則も挙げられていて、部品の内部が閉じておらず、どの階層でも組み替えられるようになっている。className を使って Tailwind CSS や CSS Modules、素の CSS で上書きすることもできる。StyleX に縛りつけない、と明言されている。

導入してみるには

インストールは npm なら次のようになる。

npm install @astryxdesign/core @astryxdesign/theme-neutral
npm install -D @astryxdesign/cli

pnpm を使っているなら pnpm add に読み替えればよい。CLI については、package.json のスクリプトに `"astryx": "node node_modules/@astryxdesign/cli/bin/astryx.mjs"` を追加しておく形が推奨されている。

パッケージは役割ごとに分かれていて、部品とテーマの仕組みが入った core、雛形の生成やドキュメント表示やバージョン移行を担う cli、StyleX のビルド用プラグインが入った build、そして7つのテーマがそれぞれ theme- で始まる名前で用意されている。

CLI でできることは、テンプレートの雛形生成、コンポーネントのドキュメント表示、テーマの生成、codemod（コードを自動で書き換える仕組み）によるバージョン移行、そして先ほどの機械可読なドキュメント出力だ。

対応環境については、React は19以上が必須で、react-dom とあわせてピア依存として要求される。Next.js（Tailwind と組み合わせても、StyleX と組み合わせてもよい）、Vite、Create React App、それに UMD バンドルを使った CDN 経由での読み込みに対応している。PostCSS や Babel の設定は不要とされている。開発側の環境としては Node.js 22以上、パッケージマネージャは pnpm 11 が想定されている。

気をつけておきたいところ

正直に書いておくと、まだ Beta と明示されている。9,000を超えるスターの一方で、公開されている issue は150件を超えているし、pull request も100件以上が並んでいる。動きの速い段階にあるとみたほうがいい。

React 19以上、Node 22以上という要求も、既存のプロジェクトにそのまま入れようとすると引っかかる可能性がある。新しく始めるものに使うか、あるいは小さく試す場所を切り出してから考えるほうが安全だと思う。

それから、これは制約というより性質の話なのだけれど、8年ぶんの社内の判断が織り込まれた道具だということは、頭の片隅に置いておいたほうがいいかもしれない。よくできた規格というのは、たいてい誰かの前提の上に成り立っている。

　　誰かの家で長年使われてきた台所道具を譲り受けるのに近い。よく手に馴染むし、丁寧に使い込まれている。ただ、その人の背丈や料理の癖に合わせて少しずつ削られていることもある。

終わりに

私がこのプロジェクトを面白いと思ったのは、部品が150種類あることでも、テーマが7つあることでもなかった。人間が読むための文章と、機械が読むための一覧を、はっきり分けて両方用意した、という判断のほうだ。

AI にコードを書かせるとき、私たちはつい「もっと賢いモデルなら間違えないはずだ」と考えてしまう。けれど、間違いの少なくない部分は、渡している情報の形が人間向けにできていることから来ているのかもしれない。だとすれば、直すべきなのは読む側ではなく、書いておく側なのだと思う。

そう考えると、これは見た目を整える道具の話であると同時に、これから何かを公開する人が「誰に読ませるつもりで書くのか」を問い直す話でもある気がしている。私はしばらく、手元の小さなプロジェクトで触ってみるつもりだ。