AI にトラックの荷主ポータルを作らせてみた — 前回 build した部品が「翌回」で自力発見された（やってみた #164）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。トラック toC 開始（toB5 完了に続く消費者側）——荷主向け 配送ポータル（集荷依頼・貨物追跡・配送履歴）。B2B2C・モバイルファースト。

結果 — 4.5/5、そして「最速の build→検証」

tsc 緑・375px mobile-first。cold AI（群青を一度も触っていない設定）：

渡され得る中で最も相性の良い画面。 /docs/by-use-case 索引が主要な部品すべてで正しく誘導し、ほとんどの部品が B2C 物流ポータルのために設計されたかのよう（JSDoc を見る限り、実際そう）。

観測の核 — SectionList が「前回 build→翌回 検証」された

前回 #162 で SectionList を build した。そして #164（連続する次の回）の cold AI が、それを自力発見しゼロ摩擦で使った：

cold AI「SectionList＝zero-friction。配送履歴を月別に・per-group meta(¥合計)と footer(小計)・content に ListCard を入れた。索引が直接ここに誘導し、正しかった。手組みゼロ。」

これは連載で最速の build→検証ループだ。#136→#153（Stringline）は17回離れていたが、#162→#164 はわずか2回。床が成熟すると、build した部品はほぼ即座に次の画面で再利用される——SectionList は荷主ポータルの配送履歴に、build した翌回で native に嵌まった。

観測の核2 — 索引の「すり替える罠」がまた出た（TimePicker）

集荷の希望時間帯（午前中/12-14時）——TimePicker を当てたくなる。だが：

cold AI「TimePicker はあるし索引は『時間帯』に勧める・だが正確時刻(HH:mm)の hour+minute select だった。荷主ポータルは 14:37 集荷を望まない・午前中/12-14時 を望む。索引にすり替えられた。バンドの Select に fallback した。追加すべき最重要は TimeBandPicker＝配達/集荷の時間帯は JP 物流/EC で普遍。」

これは #160（RelationshipRow）と同じすり替える罠＝名前で正解に見えるが用途で崩れる。→ その場で索引是正（時間帯→SegmentedControl/RadioGroup に誘導・TimePicker は正確時刻と明記）[PR#423]＋TimeBandPicker 起票 #422。今回 src build なし（4.5/5・SectionList 翌回検証・索引是正）。

観測の核3 — RouteStops は配送追跡に native、但し「1日内」設計

貨物追跡（集荷済→輸送中→配達完了）は RouteStops に native に嵌まった。だが：

cold AI「RouteStops は status-per-stage＋current＋aria-current が native。だが時刻列が plannedTime/actualTime: 'HH:MM' 型で同日の遅延を計算する。消費者の追跡は日を跨ぐ(6/28 18:40→6/29 14-16時 予定)。HH:MM に入らないので hideTimes して日付を meta に押した。RouteStops は1日内のドライバー行路用で、多日跨ぎのクロスドック輸送用でない。」

→ RouteStops に dateLabel/自由形式タイムスタンプを per-stop で（#422）。RouteStops 自体は配送に native（#159）だが、時刻モデルが intraday 固定。

学び — 「build→検証の距離」が縮むのが床成熟の最終指標

連載で build→検証の距離を測ると：

• #136→#153 Stringline＝17回（初期・床が薄い）。
• #155→#159 Leaderboard＝4回。
• #161→#163 LimitMonitor＝2回（越境）。
• #162→#164 SectionList＝2回（連続に近い）。

距離が縮むほど床は成熟している。 初期は build しても次に使われるまで遠かったが、今は build した翌々回・翌回で自力発見される＝穴が出る頻度が下がり、既存部品の再利用が主になった。トラック toC を開始しても、出たのは TimeBandPicker（1/3）と RouteStops 多日対応の2つだけで、画面の~90%は既存部品（多くは最近 build した SectionList/RadioCard/RouteStops）で組めた。

📊 結晶化スコアボード（build 済 20個）

…LimitMonitor / SectionList（このセッションで6部品） 進行中：TimeBandPicker(1/3)・Statistic goodWhen(2/3)・RouteStops 多日(1/3)・MatchCard(1/3)

📋 モード進捗 — トラック toC 開始

• ✈️ 航空 ✅／🚆 鉄道 ✅／🚕 タクシー ✅／🚌 バス ✅
• 🚚 トラック：toB5 ＋ toC1（荷主ポータル#164） ← toC 開始・対称完走へ

次回予告（やってみた #165）

• トラック toC をさらに（個人の宅配追跡・再配達／荷主の請求・帳票）で対称完走へ。※KeEem に確認。

試す

• gunjo.jp ／ セクションリスト SectionList ／ 配送ルート RouteStops ／ 選択カード RadioCard ／ 金額内訳 AmountBreakdown ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#163
• GunjoUI by UIXHERO

前回 build した SectionList が翌回で自力発見された——build→検証の距離が縮むのが床成熟の最終指標。17回が、2回になった。

---

<!-- 公開前: 相互URL差込／スクショ確定／EN(dev.to)ミラー -->