自作のデザインシステム
@gunjo/ui（群青／gunjo.jp（gunjo.jp を新しいタブで開く）） を、群青を一度も見たことのない 予備知識ゼロのAI に170画面組ませてきた連載のまとめ第3弾。「コンポーネントの蓄積が育つ」を数値で測る方法を、170画面の実データで示します。
「コンポーネントの蓄積が育つ」って、結局なんの話？
この記事で言うコンポーネントの蓄積とは、画面を組む人の手元にある既存コンポーネントの集まりのことです。蓄積が厚ければ、手組みなしで画面が組めます。足りない箇所は「足りないコンポーネント」——そこだけ手で組む羽目になります。
では、デザインシステムを持つ人が「うちのコンポーネント、だいぶそろってきました」と言うとき、具体的には何が起きているかを説明できるでしょうか。APIが固まった？ コンポーネント数が増えた？ カバレッジが広がった？——どれも正解ですが、どれも直接には成熟を語らない指標です。
170画面のコールドテストを回してみて、私は1つのシンプルな「ものさし」を手に入れました。
作ってから再発見までの距離 =「新しく作ったコンポーネントが、次に自力で見つけられるまでの間隔（ラウンド数）」
- 距離が大きい：作ったコンポーネントが次に使われるまで、他の画面をたくさん通る必要がある。蓄積がまだ薄い証拠
- 距離が縮む：作ったコンポーネントが翌回・翌々回で自力で見つかる。蓄積が育っている証拠
初期：Stringline は作ってから 17ラウンド離れて再発見された
連載で最初にはっきりデータが取れた例は、時間×距離の運行図表 Stringline でした。
- #136バス運行管理：予備知識ゼロのAIがSVG 210行で運行図表を手組み。3回確認を満たして
Stringline（gunjo.jp を新しいタブで開く） を実装（群青に追加） - #153バス運行計画・ダイヤ編成：予備知識ゼロの別のAIが「時間×距離の運行図表＝斜めの運行線」で
Stringline（gunjo.jp を新しいタブで開く） を自力で発見。SVGゼロで使用
#136 → #153 = 17ラウンド離れています。この17ラウンドの間、Stringline は誰にも使われませんでした。蓄積が薄く、他の分野（HR / 介護 / 飲食 / 保険）を通る間、次の運行図表の分野に戻るまでの空白が長かったのです。
初期はどのコンポーネントもこんな距離を持っていました。作った瞬間の「見通し」と、実際に再利用されるまでの「距離」のギャップ——これが「蓄積が薄い」ということです。
中盤：距離は4 → 2 → 連続近くに縮む
同じものさしで終盤を測ると、風景が変わります。
Leaderboard: #155バス安全（ワースト事故率）で実装 → #159トラック配車（稼働ランキング）で自力発見。距離 = 4LimitMonitor: #161トラック労務（拘束時間）で実装 → #163トラック原価（運賃比較）で自力発見。距離 = 2（業界越え）SectionList: #162トラック運賃請求で実装 → #164荷主ポータル（配送履歴の月別グループ）で自力発見。距離 = 2（連続に近い）NavRow: #168荷主向け請求ポータルで実装 → #169鉄道 路線別ダッシュボード（月次レポートのダウンロード行）で 同じセッション内で自力発見。距離 = 1
「距離が縮む」とは、同じ蓄積の上で作業する次の予備知識ゼロのAIが、作ったコンポーネントを「自分の作業道具」として即座に見つけられるということです。作っておいて他の17画面を通してから初めて使われるのと、翌画面で使われるのとでは、蓄積の意味が違います。
データ表：主要な「作る→再発見」の距離
170画面の代表的な「作る→再発見」ペアを並べます。
| コンポーネント | 作った回 | 次の自力発見 | 距離 |
|---|---|---|---|
Stringline | #136バス運行 | #153ダイヤ編成 | 17 |
PersonCell | #85評価 | #86勤怠 | 1 |
RelationshipRow | #90ケアプラン | #91介護記録 | 1 |
ActionQueue | #106鉄道指令 | #107乗務員 | 1 |
TicketStub | #128鉄道駅ナカ | #129きっぷ払戻し | 1 |
ExpiryBadge | #142タクシー乗務員資格 | #144タクシー車両（車検/保険） | 2 |
BottomActionBar | #147タクシー配車アプリ | #148タクシー予約 | 1 |
Leaderboard | #155バス安全 | #159トラック配車 | 4 |
LimitMonitor | #161トラック労務 | #163トラック原価 | 2 |
SectionList | #162トラック運賃請求 | #164荷主ポータル | 2 |
NavRow | #168請求ポータル | #169鉄道路線ダッシュ | 1 |
OriginDestination | #170鉄道特急予約 | — （最新のため未検証） | — |
初期は 17 ラウンド離れていた距離が、中盤に 4 になり、終盤には 1〜2 に縮む——「コンポーネントの蓄積が育っている」を、これだけ具体的に測れます。
番外：目標つきの Meter は 翌1ラウンドで16回使われた
もう1つ強い例を挙げます。#65品質検査で、目標値つきで「高いほど良い」メーター（Meter direction="higher-is-better" に target）を実装しました。翌 #66設備保全OEEダッシュボードで、予備知識ゼロのAIは同じ Meter を OEE指標全体に16回使いました。AI自身の言葉です。
文句なしの主役。何も強制せず、そのまま使えた。16回使って、一度も引っかからなかった。
距離 = 1、その1ラウンドの中で 16回再利用されました。これは「距離」の話のもう一段深い形——距離がゼロに近づくと、次の画面で「作業道具として愛される」コンポーネントになる、ということです。
対応表にも「作る→再発見」ループがある
もう一段面白いのは、コンポーネントを作るときだけでなく、対応表の修正にも「作る→再発見」ループがあることです。
- #164荷主ポータルで「集荷時間帯 →
TimePicker」の誤誘導を発見 → 対応表を是正（「時間帯 →SegmentedControl/RadioGroup」に明記） - #165宅配便 個人向け再配達で、予備知識ゼロのAIが「受け取り時間帯＝手組み不要・対応表に正しい注記がある」→
TimePickerの手組み ゼロ
コンポーネントを作らなくても、対応表の一文で塞げる罠は多い。安い修正が翌画面で機能したことを同じ距離で測ると、「対応表を直す」ことの複利が見えます。
同じ現象は、ActionDataTable を対応表に載せ直したときにも起きました。#159で塞ぎ、#160で予備知識ゼロのAIが対応表から直行——「案件一覧 + 一括割当 → ActionDataTable」に迷わずたどり着き、「まさに荷物を選択→オファー。偶然の発見ではなく、キット最強の瞬間」と書きました。
なぜ距離は縮むのか（仕組み）
コンポーネントの蓄積が育つ過程で、距離を縮める3つの複利が働きます。
① 3回確認ルールの複利：「3つの別々の画面で独立に手組みされた」時点で仕様が最も安定するので、作った直後は「その形が最も広く見つかる」状態になっています。次の画面で誰かがまた同じ形を欲しがる確率が高い。
② docstringとJSDocの質：#66 OEEの例のように、予備知識ゼロのAIは JSDocのタグと使用例だけで発見します。「配車 / checkout / ride / booking / food」のように docstringに複数の分野で名指ししておくと、翌日の別のAIがそれで釣れます。「docstringは、翌日の自力発見あての手紙」という言い方が、コールドテストで定着しました。
③ 対応表の成熟：初期は「経路 → Itinerary」の1対1が多かった対応表が、「経路（縦のシーケンス）→ Itinerary / 経路（横のA→B）→ OriginDestination」のように「形の軸」で枝分かれするようになると、使う人は迷わず直行できます。対応表の枝分かれが細かいほど、距離は縮みます。
「新しいコンポーネントを生む」から「既存が想定外の場面で再利用される」へ
170画面を回してきて、連載後半の主題が変わったのを強く感じました。
- 初期: 「まだ足りないコンポーネントを作る」。1画面で2〜3個を新設することもあった
- 中盤: 「あるはずのコンポーネントを確認する」。既存コンポーネントの言い回し（説明の間口）を広げれば済むことが増えた（教育の
ScheduleGridの例） - 終盤: 「既存コンポーネントが想定外の場面で再利用される」。新しいコンポーネントはほぼ出ず、代わりに
MeterがExpiryBadge・ReferenceValue・LimitMonitorと兄弟を増やして、「値を何かと比べる」仲間を形成する
距離がゼロに近い状態が長く続くと、コンポーネントの蓄積は「新しいコンポーネントを生む場」から「既存コンポーネントが磨かれる場」に変わります。これが「蓄積が育つ」の別の言い方です。
まとめ
- 「コンポーネントの蓄積が育つ」は 作ってから再発見までの距離で数値化できる
- 初期 = 17ラウンド、終盤 = 1〜2ラウンド。170画面で測れた事実
- 対応表の修正にも同じ距離のループがある（#159で塞ぎ #160で検証、時間帯の是正を #165で検証）
- 距離を縮める複利は ① 3回確認による仕様確定 / ② docstring / ③ 対応表の枝分かれの3つ
- 距離がゼロに近づくと、蓄積は「新しいコンポーネントを生む場」から「既存コンポーネントが磨かれる場」に変わる
デザインシステムを持つ人には、このものさしを勧めたいです。カバレッジやコンポーネント数の増加より、距離の縮み具合の方が「本当に使われているか」を直接に語ります。170画面かけて分かった、群青の一番はっきりしたものさしでした。
関連
- ユースケース別の対応表 (by-use-case)（gunjo.jp を新しいタブで開く） — 群青の対応表本体
- /cold-tests/why（考え方のページ）（gunjo.jp のコールドテストの記録を新しいタブで開く） — 3回確認の方法論
- 『ユースケース別の対応表』の落とし穴
- 「作るべき理由」には強さの段階がある
- 総集編（Zenn）（Zenn を新しいタブで開く）
この記事はZennにも掲載しています。Zenn版（Zenn を新しいタブで開く）
この記事のもとになった記録は、本にまとめました
『あなたがAIにUIを作らせると、何が起きるか』
予備知識ゼロのAIに、実在する業種の業務UIを175枚作らせ続けた記録です。何が組めて、何が組めなかったか。全175回の採点と、生まれた26コンポーネントの年表を載せています。
- Zenn版（Zenn を新しいタブで開く）（序章と第7章は無料で読めます）
- Amazon Kindle版
この連載は、作者がAI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
