自作のデザインシステム
@gunjo/ui（群青／gunjo.jp（gunjo.jp を新しいタブで開く）） を、群青を一度も見たことのない 予備知識ゼロのAI に170画面組ませてきた連載のまとめ第5弾。「3つの別々の画面で独立に手組みされたら正式に作る」ルール（3回確認）を積み重ねて群青に加わったコンポーネントたちを、8つのグループに束ねて一気に紹介します。長いので目次からどうぞ。
ルールのおさらい：3回確認とは
群青のコールドテストでは、想像でコンポーネントを作りません。予備知識ゼロのAIに実業種の画面を組ませ、「このコンポーネントが無いから手組みした」という正直な報告を集めます。そして、
- 1回目：足りないコンポーネントとして課題に記録するだけ
- 2回目：対応表やdocsを調整するだけ
- 3回目：初めて正式に作る（群青に加える）
同じ「足りないコンポーネント」が3つの別々の画面で独立に出るまで待つのは、形が安定するのを見届けるためです。早すぎるとAPIを狭く固めてしまいます。この運用を170画面続けた結果、実際に群青に加わった新コンポーネント・拡張は26。カタログのカテゴリ別扉ページ（gunjo.jp のコールドテストの記録を新しいタブで開く）には、再利用の記録まで含めた 71エントリ（重複を除いた分類総数）が並んでいます。
以下、グループごとに「どの3画面が3回確認を満たしたか」を辿ります。
グループ①：金額 —「数の意味」を構造で見せる
銀行5画面（#32〜36）から始まった、連載で最も業界を越えたグループです。
AmountBreakdown — 金額の導出を構造で見せる
「内訳 → 中間値 → 最終値」を1ブロックで導出表示するコンポーネント。カード明細（#36）で原型 → 保険の支払明細（#101認定額−過失相殺−免責−既払）→ 保険料内訳（#102）→ #103で3回確認に到達して実装。
実装した翌回の #104生保引受で、別の予備知識ゼロのAIが保険料計算で自力発見。その後は鉄道特急の運賃内訳・タクシーの料金・トラックの運賃表・払戻し内訳まで、「金額を説明する場面」ほぼ全部で使われるようになりました。AIの言葉です。「運賃−手数料＝払戻額が1つのコンポーネント。控除は打ち消し表示＋符号＋式つき。この画面のために作られていた」。
EditableDataTable — その場で編集できる表
請求書の明細行（#37複数税率・税率別内訳）で生まれ、実地棚卸（#43理論在庫×実数の差異）、介護報酬請求（#92）まで横断しました。「編集する金額表」と「読む金額表（AmountBreakdown）」の分離は、対応表の誤誘導（#102）を経て明確になりました。
DocumentRow — 書類ダウンロード行（作る理由が最強クラス）
帳票ダウンロード（#168）・月次レポートダウンロード（#169）・HR書類ダウンロード（#171）で3回確認。ListCard.onSelect はカード全体を1つのボタンにするため、独立したダウンロードボタンを入れると、ボタンの中にボタン＝不正なHTMLになる ——「既存のコンポーネントではHTML構造上つくれない」という最も反論の余地ない「作る理由」が立ったコンポーネントです。
グループ②：責任の重い操作 — 医療で生まれ、業界を越えた
医療7画面（#53〜59）が生んだ、群青で最も「重い」グループ。どれも医療専用ではなく、責任の重い操作を扱うあらゆる画面で使われています。
ScanGate — 3点認証の安全ゲート
原型は小売の入荷検品（#46 ScanInput）と物流の2段スキャン（#47〜49）。医療の与薬（#53）で「患者リストバンド → 薬剤 → 指示」の3点照合として完成。倉庫のコンポーネントが患者の取り違え防止に効いた、業界横断の代表例です。
ReferenceValue — 基準値つきの数値
バイタルのH/Lフラグ（#54）・検査値の危険値（#55）・処方の用量レンジ（#56）で3回確認。後に、生保引受のBMI / 血圧判定（#104）・教育の赤点判定（#71）・点呼のアルコール0.00（#137）まで、「数値をある範囲で判断する」場面すべてに広がりました。
SafetyBanner / CoSign / SignedRecord — 警告・2人確認・署名ロック
SafetyBanner（#56）: アレルギー・相互作用・要注意薬の「画面に残し続けるべき警告」。Alertより重い役割CoSign（#58）: 手術の器械カウント・麻薬・輸血の「独立した2人の合意」。後に保険の高額査定・介護記録・点呼までSignedRecord（#59）: 看護記録・手術記録・退院サマリの3画面で独立に手組みされた「署名 → ロック → 追記のみ」。原型は不動産の賃貸借契約（#61）
ApprovalWorkflow — 多段の審査
経費精算（#39）→ 不動産の入居審査（#63）→ 公共の窓口/給付金審査（#75/#76）で3回確認。その後、メディアの編集CMS・保険の査定・タクシーの苦情管理まで。「事務方を作ったことがある人が設計したと最も感じさせた1つのコンポーネント」と、予備知識ゼロのAIに評されました。
グループ③：マトリクス（時間×何かの表）— 説明の間口が命だった
ScheduleGrid — 時間×何かのマトリクス
時間割（#70）で実装。だが直後の成績管理（#71）で予備知識ゼロのAIに見つけてもらえなかった——「作ったコンポーネントが見つからない＝無いのと同じ」という、連載で最も怖い学びです。説明の間口を広げた途端、出欠（#72）・LMS（#73）・面談予約（#74）と3連続で刺さり、後に介護の週間計画・HRの月次勤怠・飲食のシフト・公共の施設予約まで広がりました。
Gantt（1日の中の時間帯）/ EventCalendar / LineageGraph
Gantt resolution="hour"（#153）: 機材繰り・車両運用の「1営業日」が44pxに潰れる問題を解消EventCalendar（#82）: 「月カレンダー＋イベント」という連載中に何度も顔を出し続けた大きな不足を、整備ラウンドで実装LineageGraph（#82）: 製造のロット系譜（#67）とメディアのOSMU（1つの素材を多用途に展開）派生系譜——単親のTreeViewでは描けない、親が複数ある系譜図——を2業界がまたいで証明した、大きなコンポーネント
グループ④：人と組織 — PersonCell から MatchCard へ
「人を1行でどう表すか」から始まり、組織・組み合わせへ伸びたグループ。複利の最短距離もここで記録されました。
PersonCell — 人物の識別セル
採用パイプライン（#83）・組織図（#84）で2回手組み → 評価管理（#85）で3回目に実装。翌回 #86の別のAIが勤怠管理で自力発見——「作ったコンポーネントが翌回でそのまま使われる」最短検証の1例目です。
RelationshipRow — 「2人の関係」の行
1on1の上司↔部下（#88）で原型 → 介護のケアプラン（#90利用者↔ケアマネ）で3回確認して実装 → 翌回 #91でまた自力発見。PersonCell→RelationshipRow と、3回ルールが2層で連続発火しました。
MatchCard + CompanyCell — 二者の組み合わせと組織セル
求貨求車（#160荷物×空車）・M&A（#172買い手×売り手）・補助金マッチング（#173会社×制度）で3回確認。決定打は、3回目が 種類の違う組み合わせ（会社×制度）だったこと——もし1〜2回目の同じ種類どうしで作っていたら「会社×会社に固定」した狭い作りにしていたかもしれません。種類の違う組み合わせだったからこそ、左右をどんな対象でも入れられるようにする設計を迫られたのです。CompanyCell は「人のコンポーネント（PersonCell）があるなら、組織のコンポーネントも要る」の組織版として、同時に実装しました。
グループ⑤：値を何かと比べる — 4種類が揃うまで
「値を何かと比較して読む」コンポーネントは、実は4つの別の軸に分かれます——170画面かけて、この4種類の全体像が完成しました。
| コンポーネント | 軸 | 3回確認の3画面 |
|---|---|---|
Meter | 容量に対する充足 | 棚別充填率 #50 / OEE #66 / 積載率 #51 |
ReferenceValue | 範囲（基準値・H/L） | バイタル #54 / 検査値 #55 / 用量 #56 |
ExpiryBadge | 期限（残りN日） | 航空乗員資格 #131 / バス運転士 #137 / タクシー乗務員 #142 |
LimitMonitor | 名前つきの上限（ソフト/ハード） | 営業係数 #154 / 拘束時間 #159 / 改善基準告示 #161 |
4種類が揃う前は、予備知識ゼロのAIは毎回 Meter target に誤誘導されて、拘束時間や車検期限で詰まっていました。4種類が揃い、対応表が軸ごとに枝分かれした後は誤誘導ゼロ。ExpiryBadge はその後、乗務員資格 → 車検/保険 → クーポン期限 → 電子チケットと4つの分野を横断しています。
Statistic goodWhen — 「増えるほど悪い」指標に対応
「上昇＝良い」とは限りません（遅延件数・原価率・混雑率）。バス営収（#154）・トラック原価（#163）・鉄道定時性（#169）で3回手組みされ、goodWhen: "higher" | "lower" として実装しました。同じ仲間の Delta / Leaderboard / Meter は反転を解けるのに Statistic だけ解けなかった、というグループ内の非対称が3回確認で埋まった例です。
グループ⑥：モバイルの利用者向け — 消費者側を掘って生まれた
タクシーで「利用者向けを1枚だけ作って完走」としかけたのを差し戻して以来、利用者向けを事業者向けと同じ厚さまで掘るのがルールになりました（その一部始終はまとめ第6弾に書きます）。このグループは、その利用者向け深掘りの成果です。
PageHeader（#125）: モバイルのアプリバー。空港案内 #122・振替 #125・ラウンジ #127で3人のAIが独立に手組み。戻るボタンが44×44px を最初から満たすBottomActionBar（#147）: 下部に固定するCTAバー。振替 #125・払戻し #129・高速バス予約 #139・配車 #147で3回確認。PageHeader（上）と対になるコンポーネント。実装した翌日 #148で自力発見TicketStub（#128）: 券面。eチケット #123・駅ナカ会員証 #128で3回確認。クーポン提示・遅延証明書QR・モバイル乗車券までSeatMap（#114）: 鉄道 #109・機内 #112・チェックイン #114。新幹線も説明文に名指しFilterChips（#122）/SegmentedControl（#156）/LoyaltySummaryCard（#118）: カテゴリのナビ・2〜4等幅の切替・残高/ランクの主役ブロック。マイル #116 → 鉄道IC #117 → 小売ポイント #118 の3回確認は「業界が違っても同じ主役ブロック」の証明
グループ⑦：現場オペレーション — 指令室と営業所の道具
運輸5モード（鉄道・航空・バス・タクシー・トラック）の事業者向けが育てた、情報密度の高いコンソール群です。
ActionQueue（#106）: 要対応リスト。運転指令で実装 → 翌回 #107の乗務員区で自力発見（「対応表 →ActionQueueで即着地」）StatusBoard（#141）: 空間配置の状態ボード。駅務 #132・ランプ #134・タクシー配車 #141で3回確認。「現場オペレーションで最も多い不足」Stringline（#136）: 時間×距離の運行図表。#106で課題に記録してから30ラウンド、最も古い在庫が鉄道2回＋バスで満ちました。AIの言葉です。「この画面のために作られている。SVGを1行も書いていない。この分野でキット最重要のコンポーネント」Leaderboard（#155）: ベスト/ワースト順位表。タクシー営収 #143・バス収支 #154・バス安全 #155LineChip（#157）: 路線色＋自動コントラスト。接近案内 #138・経路検索 #140・運行情報 #157RouteStops: 配送追跡（#52）で原型 → 手荷物追跡・折り返し進捗と広がり、複数日のタイムスタンプ（dateLabel）が荷主 #164・宅配 #165・国際物流 #166の3回確認で拡張
グループ⑧：構造 — 並べ方そのものがコンポーネントになる
SectionList（#162）: グループ見出し＋本文＋グループ小計フッター。タクシー月別履歴 #149・バスIC台帳 #158・運賃請求 #162。実装した翌回 #164で自力発見（距離2）NavRow（#168）: 端まで詰めた設定行。法人配車 #152・宅配設定 #167・請求ポータル #168。対応表がListCard（aria-pressedのトグル＝ナビに不適）へ誤誘導するアクセシビリティの不具合も同時に是正OriginDestination（#170）: A→Bの横並びの区間ヘッダ。国際物流 #166・路線実績 #169・特急予約 #170。「経路」の対応表が縦のシーケンス（Itinerary）に誤誘導していた形の軸の罠を塞ぎました
数字で振り返る
- 実際に群青に加わった新コンポーネント・拡張26（カタログの20カテゴリ扉ページ＝14業種＋運輸5モード＋汎用UIには、再利用の記録も含む71エントリ → gunjo.jp/cold-tests（gunjo.jp のコールドテストの記録を新しいタブで開く））
- 3回確認までの最長待機：
Stringline（#106で課題に記録 → #136で実装、30ラウンド） - 最短の再発見：
PersonCell/RelationshipRow/ActionQueue/BottomActionBar/NavRow（いずれも実装した翌回） - 最多の分野横断：
ExpiryBadge（乗務員資格 → 車検/保険 → クーポン → チケットの4分野） - 最強の「作る理由」：
DocumentRow（HTML構造上、既存のコンポーネントではつくれない）
まとめ
こうして並べて見えるのは、コンポーネントは1個ずつでなく、関連するグループでまとまって育つということです。金額、責任の重い操作、マトリクス、人と組織、値を何かと比べる、モバイルの利用者向け、現場オペレーション、構造——それぞれのグループの中で、コンポーネント同士が対応表の枝分かれを細かくし、説明文が次の発見を早くし、グループが揃った瞬間に誤誘導が消えます。
「想像で作らず、3回証明された『足りないコンポーネント』だけを正式に作る」を170画面続けると、デザインシステムはこういう形に育つ、という記録でした。
関連
- /cold-tests（170画面の常設カタログ）（gunjo.jp のコールドテストの記録を新しいタブで開く） — 業種別の扉ページから、各コンポーネントが生まれた画面に飛べます
- /cold-tests/why（考え方のページ）（gunjo.jp のコールドテストの記録を新しいタブで開く） — 3回確認の方法論
- 『ユースケース別の対応表』の落とし穴
- 「作るべき理由」には強さの段階がある
- 作ってから再発見までの距離が縮む
- 総集編（Zenn）（Zenn を新しいタブで開く）
この記事のもとになった記録は、本にまとめました
『あなたがAIにUIを作らせると、何が起きるか』
予備知識ゼロのAIに、実在する業種の業務UIを175枚作らせ続けた記録です。何が組めて、何が組めなかったか。全175回の採点と、生まれた26コンポーネントの年表を載せています。
- Zenn版（Zenn を新しいタブで開く）（序章と第7章は無料で読めます）
- Amazon Kindle版
この連載は、作者がAI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
