Astryxレビュー（feat. shadcn/ui）：バックエンド開発者にとってUIはまだ難しい

最近、作業がバックエンドからUIに移るたびに、少しずつ詰まる。データの流れ、API、認証、バッチ、障害対応などはそれなりに慣れている。でも、画面を見やすく、統一感のある形にするのは今でも難しい。会社のソリューションが Angular ベースなので、その感覚はさらに強い。React の世界では面白いUIツールが次々に出てくるが、会社のプロジェクトにそのまま持ち込めるわけではない。

そんな中で Meta の Astryx を見た。公式には「完全にカスタマイズ可能で agent-ready なオープンソースデザインシステム」と説明されている。GitHub では facebook/astryx として公開されており、2026年7月時点でスターは約6千。npm パッケージも @astryxdesign/core、@astryxdesign/cli、@astryxdesign/theme-neutral という形で公開されている。

Astryx は何を目指しているのか

Astryx は、単にボタンやカードを集めたUI部品集というより、AIコーディングツールがUIを間違えにくくするためのデザインシステムに近い。公式ドキュメントの Working with AI もかなり明確だ。AIモデルが一般的な React パターンに逃げたり、存在しない props を作ったりしないように、CLI がコンポーネントのインデックス、ルール、ドキュメントコンテキストを生成する。

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

つまり、人間がドキュメントを読んで一つずつ組み立てるだけの道具ではない。開発者とAIエージェントが、同じ設計ルールを見ながらUIを作るための仕組みに見える。

shadcn/ui とは何が違うのか

shadcn/ui はすでに多くの開発者に知られている。公式ドキュメントでも「component library ではなく、自分の component library を作る方法」と説明している。従来のUIライブラリのようにパッケージから import して使うというより、必要なコンポーネントのコードをプロジェクトに取り込み、自分で所有して修正する方式だ。

一方で Astryx は、@astryxdesign/core というコンポーネントパッケージをインストールして使う形に近い。そこに design token、theme、StyleX、Tailwind bridge、CLI、agent docs が付いてくる。

項目	Astryx	shadcn/ui
性格	Meta が公開した React デザインシステム	コピーして所有するUIコンポーネント配布プラットフォーム
使い方	`@astryxdesign/core` をインストールして import	CLIでコンポーネントコードをプロジェクトに追加
AI対応	agent docs、JSON API、CLIによるコンテキスト生成を強調	MCP、registry、v0 などAIフレンドリーな流れが強い
カスタマイズ	tokens、themes、StyleX、Tailwind、className	コードを所有して直接修正
考え方	一貫したデザインシステムとAIエージェント対応	オープンコードを自分のコンポーネントとして管理
今の自分にとっての惜しさ	React中心。Angularの直接サポートは見えない	こちらも主にReact中心で、Angularにはそのまま使いにくい

Astryx の良いところ

バックエンド開発者の視点では、Astryx の一番の魅力は「AIに渡す文脈」を道具側が意識している点だ。AIに画面を作ってもらうと、見た目はそれらしい JSX が出てくることがある。でも実際のデザインシステムのルールに合わなかったり、存在しないコンポーネントや props を作ったりする。Astryx はこの問題を正面から見ているように感じる。

コンポーネントの範囲も面白い。ボタン、カード、フォーム、メニューだけではなく、Chat 関連コンポーネント、App Shell、テンプレート、テーマ、token ドキュメントまで含まれている。単なるランディングページより、管理画面、AIチャットUI、設定画面のような用途に目が向く。

注意したいところ

もちろん注意点もある。Astryx はまだ Beta 色が強い。GitHub Issue は活発で、npm のバージョンも速く動いている。会社のプロダクトに入れるなら、APIの安定性、長期メンテナンス、デザインポリシーをもう少し見たい。

特に実際の利用者フィードバックを見ると、「良さそう」で終わる話ではない。GitHub Issue には、既存の React + Vite + Tailwind/shadcn スタイルのダッシュボードを Astryx、当時の XDS 系列へ段階的に移行しようとした記録があった。自分も React プロジェクトを変えている立場なので、この部分がかなり目に入った。

その記録では、@xds/* 時代の命名と、公開パッケージである @astryxdesign/* への移行の痕跡が見えた。パッケージインストール、Gitベースの依存関係、CLI実行、workspace パッケージ参照などで、初期統合コストがそれなりにあったようだ。その後のコメントでは、実際に XDSTheme、XDSLinkProvider、XDSAppShell、XDSTopNav、XDSSideNav などを付けながら移行を進めた記録もあった。

これは Astryx が悪いという意味ではない。既存の React プロジェクトに段階的に入れることも、決して簡単ではないという意味に近い。新規プロジェクトで決められた形から始めればかなりきれいに進みそうだが、すでに Tailwind や shadcn/ui スタイルで作られた画面があるなら、まず統合コストを考える必要がある。

そして会社の仕事で一番大きい制約は、やはり React 中心という点だ。公式例も Next.js、Vite、StyleX、Tailwind が中心。Angular ベースの会社ソリューションでは、コンポーネントをそのまま持ってきて使うのは難しそうだ。デザイントークンや画面構成の考え方は参考になるが、直接導入は簡単ではない。

それでも惜しいと思うところ

正直、一番惜しいのは Angular だ。会社のソリューションが Angular ベースなので、こういう道具を見ても「よし、明日から使おう」とはならない。しかも React プロジェクトでも、既存アプリの移行では命名変更、パッケージング、CLI設定、テーマラッパー適用などの摩擦がある。Angular なら壁はさらに高くなる。

バックエンド寄りの開発者としては、難しいのは細かいスタイルだけではない。どの画面でどのコンポーネントを使うべきか、レイアウトをどう統一するか、その場限りのUIにしないための基準が難しい。Astryx が Angular まで支援していたら、かなりうれしかったと思う。Angular 用コンポーネントでなくても、AIが参照できるデザイントークンやUI設計ルールを Angular プロジェクトへ楽に持ち込める方法があればよい。

それでも方向性は面白い。UIツールは、単に「きれいなコンポーネントがあります」という段階を越えつつある。AIエージェントが画面を作るときに必要なルールまで提供する方向に進んでいる。shadcn/ui が「コードを自分のプロジェクトに取り込んで所有する」流れを強くしたのだとすれば、Astryx は「デザインシステムをAIにも理解させる」方向に近い。

まとめ

今すぐ会社の Angular ソリューションに Astryx を適用するのは難しい。その点はかなり残念だ。ただ、UIでよく迷うバックエンド開発者として、これからどんな道具が助けになるのかを見るうえでは意味のあるサインだった。

自分が欲しいのは派手なUIビルダーではない。「この画面ではこのコンポーネントを使い、このルールで配置すればよい」という基準だ。Astryx はその基準を人間だけでなくAIにも渡そうとしているように見える。

今のところは、すぐ導入する実務ツールというより、React ベースの新規プロジェクトや AI UI 生成の流れを見るときの参考として覚えておきたい。Angular 側にも、こういう流れがもう少し強く来てほしい。バックエンド開発者も、UIの前であまり迷いたくないからだ。

参考文献

韓国語原文: この記事は韓国語版をもとに、日本語読者向けに少し整えたものです。韓国語の原文を読む。
韓国語もぜひ応援してください。