なぜコールドテストするか
予備知識ゼロの AI に、公開 npm パッケージと gunjo.jp の docs だけで実在の業種の画面を組ませる。180 ラウンドの記録から、どんなコンポーネントが群青に加わったか。
出発点
@gunjo/ui は、「AI から使えるように設計した」とうたって公開されました。コンポーネントを型つきで一か所からまとめて呼べること、 コンポーネントの仕様を機械が読めること、AI にそのまま渡せる説明があること。AI が「眺める」だけでなく 「読んでそのまま使える」形を、最初から組み込んだ設計です。 でも、それはあくまで主張にすぎません。言葉にするだけなら、誰にでもできます。 このコールドテストは、本当にそうなのかを確かめる場として始まりました。
1ラウンドの作法
- まず、予備知識ゼロの AI に「あなたは群青を初めて使うエンジニアです。この業種のこの画面を、できるだけ群青のコンポーネントで作ってください」とお願いします。
- AI には、公開ドキュメント(gunjo.jp)と npm パッケージの中身だけを頼りに、実データの画面を組んでもらいます。ソースコードは見せません。
- そのうえで、「このコンポーネントが無かったので手で組みました」「docs のコンポーネント検索はこのコンポーネントを勧めてきましたが、用途には合いませんでした」と、正直に報告してもらいます。
- こうして集まった「手で組んだ跡」を見ていきます。3つの別々の画面で、それぞれ独立に同じものが手組みされていたら(これを「3回確認」と呼んでいます)、それは本当に足りないコンポーネントだと考えます。
- そこで初めて、正式なコンポーネントとしてデザインシステムに追加します。デザインソースから実装・docs まで一括で揃えて(=正が一つだけの状態・SSOT)、その回を記事にまとめます。
3回確認:1回・2回では作らない
群青では「同じ"足りないコンポーネント"が3回出てくるまで待つ」ことにしています。1回目はまだ課題として記録するだけ、 2回目は docs のコンポーネント検索や説明を調整するだけにとどめ、3回目になって初めてコンポーネントをつくります。その形が本当に安定するのを見届けるためです。 急いで正式なコンポーネントにすると、コンポーネントの形がひとつの用途に狭く固まってしまいます。たとえば MatchCard は、3回目(補助金マッチング=会社×制度という異なる種類どうしのペア)が決め手になりました。 もし1〜2回目(同じ種類どうしのペア)の時点でつくっていたら、「会社×会社」に固定してしまっていたかもしれません。 異なる種類のペアに出会ったからこそ、「左右はどんな対象でもよい」という設計にたどり着けたのです。 3回目は、数を合わせるためではなく、仕様を最終的に見極めるための回でした。
群青に加わったコンポーネント(抜粋)
180 画面を通るなかで、業種ごとの扉ページが取り上げたコンポーネントは重複を除いて 71 個。ここではその代表を抜粋しています。名前をクリックすると、それぞれのドキュメントへ移動します。
Stringline鉄道/バスの時間×距離 運行図表StatusBoard配車ボード・機器ボードLeaderboardベスト/ワースト・順位表ExpiryBadge有効期限の状態 BadgeLimitMonitor値 vs 名前付き上限(拘束時間・在庫など)SegmentedControl大人/小児・個人/法人 など二者択一の切替NavRow設定リストの行LineChip路線色+自動コントラストOriginDestination出発→到着の A→B 横並びSectionList請求の締め別グループ+小計DocumentRowDL ボタンを独立させた書類行MatchCard二者間ペアリング(会社×制度など)CompanyCell組織版の identity セル
予備知識ゼロの AI は、忖度せず「無い」と言う
予備知識ゼロの AI が「このコンポーネントは無い」と書いたとき、それは 「本当に無い」ことの、かなり強い証拠になります。 人が「なんとなく足りない気がする」と言うより、ずっと確かな手がかりです。 この AI にとっては手元のドキュメントだけが世界のすべてで、過去の経験や思い込みで隙間を埋めることができないからです。 手で組まれた跡は、"足りないコンポーネント"を正確に映した地図のようなもの。 その地図をたどっていくと、「これは本当に群青の側の問題なのか」「それとも AI の理解が足りなかっただけなのか」を、落ち着いて切り分けられます。
180 画面が示したこと
- 「完走」と言えるのは、事業者向けの画面と利用者向けの画面を同じだけ作り込んだときだけ。 事業者側だけ作って満足してしまうと、穴は消費者側に集まります。実際、タクシーは事業者側を6枚作っても新しいコンポーネントはゼロでしたが、利用者側を6枚掘ると7コンポーネント以上が出てきました。
- 「これは作るべきだ」という根拠には、強さの段階がある。 いちばん弱いのは「コンポーネントが無くて手で組んだ」。次が「docs のコンポーネント検索が間違ったコンポーネントを勧めてきた」。そして最も強いのが「既存コンポーネントでは HTML の構造上どうしても組めない」というケースで、これには反論の余地がほとんどありません。
- キャンバスが埋まるほど、作ったコンポーネントがすぐ次に使い回されるようになる。 初期は、作ったコンポーネントを次に別の AI が自力で見つけて使うまで、17回も離れていました。それが終盤には2回(ほとんど連続)にまで縮みました。新しい画面は「新しいコンポーネントを生む場」というより、「既存のコンポーネントが思わぬ場面で使い回される場」へと変わっていったのです。
- 業界の壁は、思っていたより薄い。 15 業種・運輸5モードを通ってみると、共通のキャンバス(汎用的な UI)に業界ならではのコンポーネントを少し重ねるだけで、その多くを組むことができました。業界ごとの作法はもちろんありますが、UI のコンポーネントレベルでは業界を越えて使い回されることが多いのです。
実際の画面を見る
ここから先
業界別の扉ページ(医療・運輸・金融…)は順次追加予定です。







