自作のデザインシステム
@gunjo/ui（群青／gunjo.jp（gunjo.jp を新しいタブで開く）） を、群青を一度も見たことのない予備知識ゼロのAI に、実在する業種の本物の画面を作らせ続ける——「やってみた」連載のまとめ本編です。170画面（#1〜#173・欠番あり） を通って分かったことと、その過程で群青に加わった26個のコンポーネントを1本にまとめました。
この記事は、コールドテストが 170画面まで進んだ時点（2026年7月）の記録 です。検証はその後も続いていて画面数は増えていますが、本文の数字は当時のまま残しています。この記事の値打ちは最新の集計ではなく、そこまでの過程で何が起きたかにあるからです。いまの画面数は gunjo.jp/cold-tests（gunjo.jp のコールドテストの記録を新しいタブで開く） で確認できます。
何をやっているのか
ルールはシンプルです。
- 予備知識ゼロのAI に「あなたは群青を初めて使うエンジニアです。この業種のこの画面を、できるだけ群青のコンポーネントで作ってください」と頼む。
- AIは 公開ドキュメント（gunjo.jp）とnpmの中身だけを頼りに、実データの画面を組む。ソースコードは見せません。
- AIが「このコンポーネントが無いから手組みした」「docsのコンポーネント検索がこれを勧めたが用途に合わない」と正直に報告する。
- その手組みの跡を集める。3つの別々の画面で独立に同じものが手組みされたら（これを「3回確認」と呼んでいます）、それは「本当に要るコンポーネント」だと確定 → 正式に作って群青に加える。
- 実装はコンポーネント本体だけでなく、設計の「一つの正」（SSOT＝デザイン・実装・ドキュメントが食い違わない大元）までそろえてから、記事にする。
つまり、AIが既存のコンポーネントだけでどこまで組めて、どこで詰まるかを毎回測り、詰まった所だけをコンポーネントにしていく。デザインシステムを「想像で」広げるのではなく、必要だと3回証明されたものだけを正式なコンポーネントにする、という進め方です。
規模
- 170画面（#1〜#173・欠番あり）。
- 14業種（金融/会計/小売/物流/医療/不動産/製造/教育/公共/メディア/HR/介護/飲食/保険）＋運輸5モード（航空・鉄道・タクシー・バス・トラック）を、事業者向けと利用者向けの両面で完走。
- 各画面は予備知識ゼロのAIが一から組み、5段階で採点（多くが4〜4.5/5）。
群青に加わった26のコンポーネント（抜粋）
「3回手組みされたら正式なコンポーネントにする」を積み重ねて生まれたもの：
- 時間×距離の運行図表
Stringline（鉄道/バスのダイヤグラム） - 状態ボード
StatusBoard（配車ボード・機器ボード）／ ランキングLeaderboard（best/worst） - 有効期限
ExpiryBadge↔ 上限監視LimitMonitor（値vs名前付き上限・拘束時間/在庫） - セグメント切替
SegmentedControl（大人/小児・個人/法人）／ ナビ行NavRow（設定行） - 路線チップ
LineChip（路線色＋自動コントラスト）／ 区間ヘッダOriginDestination（出発→到着・横並びのA→B） - セクションリスト
SectionList（請求を締め別グループ＋小計）／ 書類行DocumentRow（ダウンロードボタン独立） - マッチカード
MatchCard＋ 企業セルCompanyCell（会社×制度の組み合わせ表示） - 既存コンポーネントの拡張：Ganttの時刻軸（1日の中の時間帯）・RouteStopsの多日タイムスタンプ・Statisticの
goodWhen（増えるほど悪い指標に対応） …
170画面で見えた5つの法則
コンポーネントそのものより、作り続けて初めて見えた法則の方が面白いかもしれません。
1. 「完走」とは、事業者向けと利用者向けが対称になること
ある交通モードを「事業者向けだけ作って終わり」にすると、利用者向けにこそ、足りないコンポーネントが集まる。タクシーで事業者向けを6枚作っても新しいコンポーネントはゼロだったのに、利用者向けを6枚掘ると7つ以上の新コンポーネントが出ました。だから完走の基準を「事業者向けと利用者向けが同じだけ厚い」に置くと、最も弱い側から掘ることになり、足りないコンポーネントが表に出る。
2. 「作るべき理由」には強さの段階がある
この節はまとめ連載で詳しく扱っています：「作るべき理由」には強さの段階がある
- 弱：必要なコンポーネントが無い（＝足りないコンポーネント）→ 手組みされる。
- 中：docsのコンポーネント検索が間違ったものを勧める（誤誘導）→ 使う人が信じて詰まる。
- 強：既存のコンポーネントではHTMLの構造上どうやっても作れない。例：ダウンロード書類の行を
ListCardで作れないのは、ListCard.onSelectがカード全体を1つの<button>にするから——その中に独立したダウンロードボタンを入れると ボタンの中にボタン＝不正なHTML になる。これは「拡張すれば済む」では解けない、最も反論の余地ない「作る理由」。
3. 「用途からコンポーネントを探す」機能の落とし穴は6種類あった
「経路の画面だから Itinerary（旅程用のコンポーネント）」のように意味のキーワードでは合っているのに、画面の形（横にA→Bと並べるのか、縦に手順を積むのか）が逆だったり、「2つ並べるなら RelationshipRow」が人専用のつくりで、会社×制度に使うと型（TypeScript）が通らない（＝扱う対象を取り違えている）だったり。検索機能の質は、型・アクセシビリティ・画面の形・扱う対象が人か組織かまで含めて評価すべきだと分かりました。
4. 「3回目」は数合わせでなく、仕様を最終確定させる
MatchCard（2つのものを組み合わせて見せるカード）は3回手組みされましたが、3回目（補助金マッチング＝会社×制度という種類の違う組み合わせ）が決定打でした。もし1〜2回目（同じ種類どうし）で作っていたら「会社×会社に固定」してしまったかもしれません。種類の違う組み合わせだったからこそ、「左右をどんな対象でも入れられるようにする」という設計を迫られた。3回目は、数合わせではなく仕様を最終的に固める回だったのです。
5. コンポーネントの蓄積が育つほど「作ってから再発見までの距離」が縮む
この節はまとめ連載で詳しく扱っています：作ってから再発見までの距離が縮む
作ったコンポーネントが、次にどの画面でAIに自力で見つけられるか——その間隔を測ると、初期は 17回離れていたのが、終盤は 2回（ほぼ連続）まで縮みました。距離が縮むほど蓄積は育っていて、新しい画面は「新しいコンポーネントを生む」より「既存のコンポーネントが思わぬ場面で再利用される」のが主になります。
いま、ベータへ
170画面の検証を経て、群青（@gunjo/ui）は「想像で作ったコンポーネントの寄せ集め」ではなく、必要だと3回確かめられたコンポーネントで組まれたデザインシステムになりました。この連載は、その過程を全部公開する記録です。
- ライブラリ：npm
@gunjo/ui - プロダクト紹介：AIから使えるデザインシステムを作りました — @gunjo/ui（群青）はじめました（Zenn を新しいタブで開く）
- ドキュメント／パターン：gunjo.jp（gunjo.jp を新しいタブで開く）
- 検証ログ（全公開）：gunjo.jp/cold-tests（gunjo.jp のコールドテストの記録を新しいタブで開く）
- ソース：GitHub
- 連載：このあと #1から順に、各画面で「何が起き、何が群青に加わったか」を公開していきます。
- まとめ連載：連載で見えたことを、テーマごとに整理しています。
予備知識ゼロのAIは、優秀な「正直者」でした。手組みされた跡は、どのコンポーネントが足りないかを示す正確な地図だった——その地図をたどって、群青はここまで来ました。
この記事はZennにも掲載しています。Zenn版（Zenn を新しいタブで開く）
この記事のもとになった記録は、本にまとめました
『あなたがAIにUIを作らせると、何が起きるか』
予備知識ゼロのAIに、実在する業種の業務UIを175枚作らせ続けた記録です。何が組めて、何が組めなかったか。全175回の採点と、生まれた26コンポーネントの年表を載せています。
- Zenn版（Zenn を新しいタブで開く）（序章と第7章は無料で読めます）
- Amazon Kindle版
この連載は、作者がAI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
