AI に配送追跡ボードを作らせてみた — 3回手組みされた「配送ストップ」を RouteStops に（やってみた #52）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。物流/倉庫(WMS)6枚目——⁠配送追跡 / 運行管理⁠（便一覧 × 配送ストップの状態追跡 × 予定vs実績ETA × 現在地 × 遅延/不在/再配達）。

#51 の配車（出発前）に続く、⁠運行中の監視ボード⁠。各便の配送ストップを、完了/配送中(現在地)/不在/遅延/未配の状態と、予定ETA・実績到着・遅延分とともに追う。配送センターのオペレーターが一日中眺める画面。

結果 — 4/5

tsc/build 緑・console 0・375px・便一覧＋進捗・便を選ぶとストップ一覧・現在地が判別可能（aria-current="step"）・状態更新・不在→再配達で KPI 再計算・遅延読み上げ・h1 1個。

今回の本題 — 「配送ストップ」が3回目 → RouteStops に

物流の3画面が、⁠順序付きの配送ストップ一覧を Timeline の中で手組み⁠していました（#47 ピッキングの巡回経路・#51 配送順・#52 追跡）。予備知識ゼロの AI が⁠最大の欠落⁠に名指しし、Timeline に何が足りないかを明確にしました:

上位のコンポーネントが足りない: RouteStops / Itinerary だ。Timeline は縦 <ol>・マーカー・variant をくれるが、追跡ルートには (a) ⁠現在地⁠ の概念が無い（aria-current を配線しない）・(b) ⁠予定vs実績⁠ の時刻ペアが無い（TimelineTime は単一）・(c) 項目ごとの ⁠status⁠ が無い（マーカー色を手で選ぶ）・(d) 末尾の ⁠操作ボタンの差込口⁠ が無い。~120行の、ストップごとの markup を手組み。

⁠3回ルール発火⁠で RouteStops(#228)（PR #236）を出荷:

const stops: RouteStopItem[] = [
  { id: "1", title: "佐藤 一郎", status: "completed", plannedTime: "09:30", actualTime: "09:28" },
  { id: "3", title: "高橋 花子", status: "current", plannedTime: "10:15", actualTime: "10:21",
    actions: <Button size="sm">完了</Button> },
  { id: "4", title: "田中 工業", status: "failed", actions: <Button size="sm">再配達を設定</Button> },
  { id: "5", title: "山田 太郎", status: "delayed", delayMinutes: 18 },
]
<RouteStops stops={stops} />

• 各ストップの ⁠status⁠（pending/current/completed/failed/delayed）が⁠マーカー⁠（完了→check・不在→×・遅延→clock・他→番号）・状態 ⁠Badge⁠・current は ⁠aria-current="step"＋ring＋現在地⁠ を駆動
• ⁠plannedTime/actualTime⁠（"HH:MM"）が ⁠予定/実績ペア⁠ と ⁠符号付き遅延（Delta）⁠ を描画（遅れ→destructive・早着→success）——時刻から自動計算、または delayMinutes
• ストップごとの ⁠actions（操作ボタンの差込口）⁠・meta・コネクタ線
• 出荷済みの ⁠Badge＋Delta を合成⁠（またコンポーネントが積み重なった）・トークン駆動でダークモードもタダ

ブラウザ実証: 6ストップ・current は1つだけ aria-current="step"・「2分 早着」(09:28 vs 09:30=success)・「8分 遅れ」(destructive)・明示 delayMinutes:18・per-stop ボタン。

複利も確認

• ⁠Meter（前回 #51 で作った）⁠ — 便の進捗（完了/総数）に採用「role="meter"＋読み上げ名/valuetext がタダ」。
• ⁠Badge（#51 で span に修正）⁠ — 全状態バッジに採用「inline <span>・⁠サーバー/ブラウザずれ（hydration）なし⁠」＝前回の修正がこの画面でクラッシュを防いだ。
• Delta（±分の早着/遅れ）・Statistic（6 KPI）・Progress tone・Alert(aria-live) も。

課題に記録だけ / 軽微（3回ルール未達 or docs）

• 🟡 ⁠Meter の自動色調は"容量"の意味⁠（満載→warning/超過→destructive）で、⁠"進捗"には逆⁠（完了=good）。予備知識ゼロの AI は進捗に Meter を使い tone を明示で上書き。⁠進捗には Progress(tone)、容量には Meter⁠ が正しい住み分け（docs で明確にすべき）。
• 🟡 ⁠EmptyState の headingLevel の既定が 2⁠——<h2> を持つ section 内では headingLevel={3} を渡さないと見出し階層が飛ぶ（CardTitle as と同系の見つけやすさの問題）。

学び — コンポーネントがコンポーネントを積み上げる段

Badge + Delta（既存）→ RouteStops（合成）
ScanInput → ScanGate（合成）/ Progress tone → Meter（拡張）

50回を超えて、新しいコンポーネントは⁠ゼロから作る⁠のではなく、⁠すでに出荷したコンポーネントを合成して作る⁠段に入りました。RouteStops は Badge と Delta を内部に持つ。ScanGate は ScanInput を、Meter は Progress の隣に。ライブラリが厚くなると、欠落を埋めるコンポーネント自体が⁠既存コンポーネントの合成⁠になり、一貫性（トークン・アクセシビリティ・ダークモード）が自動で乗る。予備知識ゼロの AI に作らせるテストが浮かび上がらせる欠落は、もう"基礎コンポーネントの不在"ではなく"基礎コンポーネントの組み合わせ方"へ移りました。

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

• ⁠別業界へ⁠（医療/不動産/製造など業界特有UI）。物流は6枚で十分育った（ScanInput/ScanGate/Meter/RouteStops/Delta を残した）。次の業界で、これらが発掘されるか観測。方針: 1業界3〜5枚・可能な限り違う内容・業界特有UI最優先。

試す

• ⁠gunjo.jp⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠
• 前回まで: #1〜#51
• ⁠GunjoUI by UIXHERO⁠

まだ alpha。3回手組みされた配送ストップを、既存の Badge＋Delta を合成した RouteStops に括り出した回。