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

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠トラックの利用者向け 開始⁠（事業者向け5 完了に続く消費者側）——⁠荷主向け 配送ポータル⁠（集荷依頼・貨物追跡・配送履歴）。事業者を通じて利用者に届くタイプ（B2B2C）・モバイルファースト。

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

tsc 緑・375px mobile-first。予備知識ゼロの AI（群青を一度も触っていない設定）：

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

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

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

予備知識ゼロの AI「⁠SectionList＝摩擦ゼロ。配送履歴を月別に・グループごとの meta(¥合計)と footer(小計)・content に ListCard を入れた。索引が直接ここに誘導し、正しかった。手組みゼロ。⁠」

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

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

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

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

これは #160（RelationshipRow）と同じ⁠すり替える罠⁠＝⁠名前で正解に見えるが用途で崩れる⁠。→ その場で⁠索引を是正⁠（時間帯→SegmentedControl/RadioGroup に誘導・TimePicker は正確な時刻と明記）PR#423＋TimeBandPicker を課題に記録 #422。⁠今回 src の新規コンポーネントなし⁠（4.5/5・SectionList の翌回検証・索引是正）。

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

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

予備知識ゼロの AI「⁠RouteStops は 段階ごとの状態＋current＋aria-current がそのまま合う。だが時刻列が plannedTime/actualTime: 'HH:MM' 型で同日の遅延を計算する。消費者の追跡は日を跨ぐ(6/28 18:40→6/29 14-16時 予定)。HH:MM に入らないので hideTimes して日付を meta に押した。RouteStops は1日内のドライバー行路用で、複数日を跨ぐ積み替え輸送用でない。⁠」

→ RouteStops に ⁠dateLabel/自由形式のタイムスタンプ⁠を stop ごとに（#422）。RouteStops 自体は配送にそのまま合う（#159）だが、時刻モデルが1日内に固定。

学び — 「作る→検証の距離」が縮むのが土台成熟の最終指標

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

• #136→#153 Stringline＝⁠17回⁠（初期・土台が薄い）。
• #155→#159 Leaderboard＝⁠4回⁠。
• #161→#163 LimitMonitor＝⁠2回⁠（業種を越えて）。
• ⁠#162→#164 SectionList＝2回⁠（連続に近い）。

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

📊 コンポーネント化スコアボード（作成済 ⁠20個⁠）

…LimitMonitor / SectionList（このセッションで6コンポーネント） 進行中：TimeBandPicker(1/3)・Statistic goodWhen(2/3)・RouteStops 複数日(1/3)・MatchCard(1/3)

📋 モード進捗 — トラックの利用者向け 開始

• ✈️ 航空 ✅／🚆 鉄道 ✅／🚕 タクシー ✅／🚌 バス ✅
• 🚚 ⁠トラック：事業者向け5 ＋ 利用者向け1（荷主ポータル#164）⁠ ← 利用者向け 開始・対称完走へ

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

• トラックの利用者向けをさらに（個人の宅配追跡・再配達／荷主の請求・帳票）で対称完走へ。※次回までに決める。

試す

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

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