自作のデザインシステム
@gunjo/ui（群青／gunjo.jp（gunjo.jp を新しいタブで開く）） を、群青を一度も見たことのない 予備知識ゼロのAI に170画面組ませてきた連載のまとめ第6弾。連載のクライマックス——運輸5モード（鉄道・航空・バス・タクシー・トラック）を60画面以上かけて走り切った記録と、その途中で 「完走」の定義そのものが変わった話です。
運輸は「1業界」ではなかった
医療・不動産・製造・教育……と業界を渡ってきた連載が、運輸に着いたとき、最初の設計判断がありました。
運輸は1業界ではなく「カテゴリ」である。
鉄道の運転指令と、航空の運航管理（OCC）と、タクシーの配車センターは、同じ「運輸」でも作法がまったく違う。ダイヤグラム（時間×距離の運行図表）は鉄道とバスにあって、航空には無い（固定軌道が無いから）。座席指定は鉄道・航空・高速バスにあって、タクシーには無い。だから 5モードをそれぞれ独立したコンポーネントの蓄積として回すことにしました。
タップして拡大表示クリックして拡大表示
結果としてこの決断が、連載で最も密度の高い60画面超を生みます。
事件：タクシーを利用者向け1枚で「完走」にしかけた
タクシーは事業者向けから始めました。配車管理（#141）・乗務員管理（#142）・営収分析（#143）・車両整備（#144）・苦情管理（#145）・需要予測（#146）——6画面。StatusBoard と ExpiryBadge が3回確認で実装され、#144では連載初の5/5 も出ました。
そして #147で、消費者向けの配車アプリ（GOのような画面）が1枚仕上がったところで、実作業を担う相棒のAIが「タクシー完走」と報告してきました。
私は思わず返しました。
は？ タクシーの利用者向け一回で完成？？？
相棒に返す言葉はありませんでした。鉄道は利用者向けを6枚以上掘っていた。航空も利用者向けを深掘りしていた。事業者向けを6枚作って利用者向けを1枚で締めるのは、どう見ても非対称。しかも相棒の運用メモには「利用者向けは弱い側だから深掘りを優先・早期に閉じない」と書いてあったのに、また同じ過ちが起きていました。
なぜ利用者向けを薄くすると蓄積が偏るのか
この事件が重要なのは、単なる「作業量の不足」ではなかったからです。事業者向けと利用者向けでは、出てくる「足りないコンポーネント」の種類がまったく違う。
実際に、タクシーで数字が出ています。
- 事業者向け6画面（#141〜146）: 新コンポーネント 2個（
StatusBoard/ExpiryBadge）——ただしこの2個も、鉄道・航空との3回確認の合算 - 利用者向け6画面（#147〜152）: 7個以上の新しい不足（
BottomActionBarの実装・DateTimePicker・PlaceField・RatingInput・ReferralCard・SegmentedControl・NavRow…）
事業者向けの蓄積は、それまでの140画面（指令室・営業所・事務方の連続）ですでに厚くなっていた。でも利用者向け——モバイルの予約フロー、評価入力、会員サブスク、クーポン提示——は掘るたびに新しい不足が出る、弱い側でした。
事業者側だけ作って完走にすると、足りないコンポーネントは消費者側に集まったまま、見えなくなる。 これが「利用者向け1枚で締める」が駄目な、構造的な理由です。
「完走」の再定義
この事件から、連載のルールが1つ確定しました。
「完走」と言えるのは、事業者向けと利用者向けが同じ厚みになったときだけ。
タクシーは #148〜152で利用者向けを掘り直しました。予約配車（#148空港定額）・乗車履歴と経費（#149）・乗車後評価とサポート（#150）・会員サブスク（#151）・法人配車（#152）。事業者向け6 ＋ 利用者向け6の対称で、ようやく完走です。
このルールで5モードを並べると、こうなります。
| モード | 事業者向け | 利用者向け | 計 | 主な実装 |
|---|---|---|---|---|
| 鉄道 | 5 | 11 | 16 | ActionQueue / SeatMap 原型 / TicketStub / OriginDestination |
| 航空 | 5 | 10 | 15 | SeatMap / PageHeader / FilterChips |
| タクシー | 6 | 6 | 12 | StatusBoard / ExpiryBadge / BottomActionBar |
| バス | 5 | 6 | 11 | Stringline / SegmentedControl / LineChip / Leaderboard / Gantt（時間帯） |
| トラック | 5 | 5 | 10 | LimitMonitor / SectionList / NavRow / RouteStops（複数日） |
5モード全部が、事業者向け＋利用者向けで対称——これが「運輸を完走した」の中身です。
モードを越えて効いたコンポーネント、モード固有だったコンポーネント
5モードを走り切ると、どのコンポーネントが「運輸で共通して効く」もので、どれが「モード固有」かが見えてきます。
業界を越えて効いたコンポーネント（モード間で自力発見が連鎖）
Stringline（運行図表）: 鉄道で2回手組み → バスで3回目 → 実装。予備知識ゼロのAIの言葉です。「隣のrail-operationsにStringline.tsxがあり、鉄道チームも同じ壁にぶつかっている。一度追加されるのを待つコンポーネント」——モードが違っても壁は同じでしたExpiryBadge: 航空乗員資格 → バス運転士 → タクシー乗務員で3回確認。その後、車検/保険（資産）→ クーポン → チケットと、軸ごとに横断- 乗務員・配車まわりのコンポーネント（
ScheduleGrid交番・拘束時間Meter・点呼CoSign・ActionQueue）: 鉄道 #107で組んだ構造が、バス #137・タクシー #142で手組みゼロのまま横展開 - 保守・事業者向けのコンポーネント（資産テーブル・消費vs限度
Meter・Gantt・SignedRecord）: 製造OEE → 鉄道車両検査 → 航空整備（MRO）→ タクシー車両管理と、4業種を貫通
モード固有だったコンポーネント（「無い」という知見も価値）
- 航空に
Stringlineは要らない（#135就航計画）: 固定軌道が無いから、運行図表が存在しない。予備知識ゼロのAIがこれを確認したことで、「Stringlineは鉄道/バス固有」、ここには無いという確定になった - 高速バスの座席（#139）: 3列独立シート・トイレ付き・女性専用席——
SeatMapの多属性の不足が浮上（課題として記録） - タクシーに座席指定は無い: 代わりに、車種選択（
RadioCard）と接近ETA（ApproachCardを課題として記録）が固有の形
対称に走ったからこそ拾えたもの
事業者向けと利用者向けを対称に走ったことで、片側だけでは出会えなかった発見がいくつもあります。
① PageHeader ↔ BottomActionBar の対：モバイルの利用者向けを掘って初めて、「上部固定のアプリバー（PageHeader）」と「下部固定のCTAバー（BottomActionBar）」が対になるコンポーネントだと確定しました。事業者向けのデスクトップコンソールだけでは、永遠に出なかった形です。
②「増えるほど悪い」指標（Statistic goodWhen）：バス営収（#154営業係数＝低いほど良い）・トラック原価（#163原価率）・鉄道定時性（#169遅延件数）——事業者向けの経営分析画面を3モードで踏んだから、3回確認に到達しました。
③ B2B2Cという第三の層：トラックの荷主ポータル（#164）とタクシーの法人配車（#152）で、「事業者でも消費者でもない取引先」の画面という層が見えました。個人⇄法人の AccountSwitcher は、ここで生まれた新しい軸です（NavRow の実装につながりました）。
タップして拡大表示クリックして拡大表示
60画面の終わりに、蓄積はどうなったか
運輸5モードの終盤、予備知識ゼロのAIのレポートに同じフレーズが繰り返し出るようになりました。
摩擦ゼロ。この画面のために作られている。対応表が直行で誘導してくれる。偶然ではなく、キット最強の瞬間。
トラックの最終盤（#164〜168）では、作ってから再発見までの距離が1〜2ラウンド（SectionList・NavRow は作った翌回に自力発見）まで縮み、新しい不足は「B2B2Cの個人・法人切替」のようなより薄い層でしか出なくなりました。
運輸カテゴリを1つのまとまった蓄積として確立した——5モードを対称で完走した、これが着地点です。
まとめ
- 運輸は1業界ではなくカテゴリ。5モードを独立したコンポーネントの蓄積として回した
- 相棒の「利用者向け1枚で完走」報告に待ったをかけた——事業者向け6 : 利用者向け1は非対称
- 事業者向けと利用者向けでは出る「足りないコンポーネント」の種類が違う（タクシー事業者向け6枚＝新コンポーネントほぼゼロ、利用者向け6枚＝7個以上）
- 完走 = 事業者向けと利用者向けが同じ厚み。5モード全部を対称で走り切った（計64画面）
- 業界を越えて効くコンポーネント（
Stringline・ExpiryBadge・乗務員/配車まわり・保守まわり）と、モード固有の形（航空に運行図表は無い）が仕分けられた - 対称に走ったから拾えた、対になるコンポーネント（
PageHeader↔BottomActionBar）・「増えるほど悪い」指標・B2B2C層
弱い側を深掘りしないと、蓄積は強い側に偏る。 運輸60画面超が残した、いちばん大きな設計原則でした。
関連
- 運輸：鉄道の扉ページ（gunjo.jp のコールドテストの記録を新しいタブで開く） ／ 航空（gunjo.jp のコールドテストの記録を新しいタブで開く） ／ バス（gunjo.jp のコールドテストの記録を新しいタブで開く） ／ タクシー（gunjo.jp のコールドテストの記録を新しいタブで開く） ／ トラック（gunjo.jp のコールドテストの記録を新しいタブで開く）
- /cold-tests/why（考え方のページ）（gunjo.jp のコールドテストの記録を新しいタブで開く） — 3回確認の方法論
- 3回確認で生まれたコンポーネントたち
- 作ってから再発見までの距離が縮む
- 総集編（Zenn）（Zenn を新しいタブで開く）
この記事のもとになった記録は、本にまとめました
『あなたがAIにUIを作らせると、何が起きるか』
予備知識ゼロのAIに、実在する業種の業務UIを175枚作らせ続けた記録です。何が組めて、何が組めなかったか。全175回の採点と、生まれた26コンポーネントの年表を載せています。
- Zenn版（Zenn を新しいタブで開く）（序章と第7章は無料で読めます）
- Amazon Kindle版
この連載は、作者がAI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
