AI に宅配の追跡・再配達画面を作らせてみた — 前回の索引修正が「翌回」で検証された（やってみた #165）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。トラック toC を厚く（荷主ポータル#164 に続く受取人=個人 C 側）——宅配便 配送追跡・再配達（追跡・再配達依頼・受け取り時間帯/方法・通知）。モバイルファースト。

結果 — 4/5、そして「索引修正が翌回で検証された」

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

本物の強い B2C/モバイルキット。 必要な部品はほぼ存在し、モバイルファーストが既定で、reverse-lookup 索引が全判断で正しく誘導した。減点は1点＝多日追跡タイムラインの穴。

観測の核 — 前回の索引「SWAP 修正」が翌回で検証された

前回 #164 で「TimePicker は正確時刻なのに索引が時間帯に見せる SWAP 罠」を見つけ、[PR#423] で索引を是正（時間帯→SegmentedControl/RadioGroup・TimePicker は正確時刻と明記）した。そして #165（翌回）の cold AI は：

cold AI「受け取り時間帯（time BAND）＝手組み不要・混乱なし。by-use-case 索引に明示の正しい注記『配達/集荷の時間帯は SegmentedControl か RadioGroup で、TimePicker ではない』があった。SegmentedControl を使った。TimePicker はあるし naïve な adopter は掴むかもしれない——索引が積極的にその rake から逸らす。良い。」

TimePicker 手組み = 0。 #164 で見つけた SWAP 罠を #423 で塞ぎ、#165 でその修正が翌回検証された——cold AI は rake を踏まずに正解（SegmentedControl）に着地した。これは部品の build→検証だけでなく、索引修正にも build→検証ループがあることを示す。安い修正（索引追加）でも、後発の cold AI が rake を避けて初めて『効いた』と分かる。

→ 結果、TimeBandPicker（専用部品）は ~1/3 のまま＝索引修正で friction が解消したので、専用 build は急がない。すり替える罠は、まず安い索引修正で塞ぎ、効果を翌回で測る。 これが #160→#162 で学んだ「誠実さを上げる作業」の実践だ。

観測の核2 — RouteStops の多日対応が 2/3

配送追跡（受付→輸送中→お届け完了）は RouteStops に native。だが宅配は日を跨ぐ：

cold AI「RouteStops は正しく索引推奨の部品だが、per-step 時刻モデルが plannedTime/actualTime: 'HH:MM' の時刻文字列のみで日付フィールドが無い。宅配タイムラインは日を跨ぐ(受付 6/27→配達中 6/29)・RouteStops は表現できず delayMinutes も同日前提・日付を meta スロットに注入した。欠けているのは RouteStopItem の date/timestamp フィールド＋任意の日別グループ。parcel/物流で追加すべき最重要。」

→ #422 RouteStops 多日タイムスタンプ 2/3（#164 荷主ポータル → #165 宅配追跡）。あと1回の多日追跡画面で 3-confirm → build（per-stop に自由形式 dateLabel/timestamp・HH:MM は intraday 用に維持）。

学び — 「索引修正の検証」も build→検証ループの一種

連載で検証ループは2層になった：

1. 部品の build→検証＝build した部品が後の画面で自力発見される（SectionList #162→#164＝2回）。
2. 索引修正の build→検証＝索引を直すと後の cold AI が rake を避ける（TimePicker SWAP #423→#165＝1回）。

②は安い（1行の索引追加）が、効果は①と同じく後発の文脈ゼロ AI が踏まないことでしか測れない。床成熟後の cold-test は、この2層のループを回す——穴を部品で塞ぎ（①）、罠を索引で塞ぎ（②）、両方を翌回以降で検証する。#165 は②の最初の明確な検証回＝安い索引修正が、翌回で『TimePicker 手組み 0』として効いた。

拾った点

• 🟡 RouteStops 多日タイムスタンプ = #422 2/3（あと1回で build）。
• ✅ 索引の TimePicker SWAP 修正（#423）が翌回検証＝TimeBandPicker は ~1/3 で急がず。
• ✅ RadioCard（受け取り方法）/SegmentedControl（時間帯）/DatePicker/BottomActionBar/Switch 全て native・「未配/不在/持ち戻り」が RouteStops の既定語彙に。

今回 src build なし（4/5・索引修正の翌回検証・RouteStops 多日 2/3）。

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

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

📋 モード進捗 — トラック toC2

• ✈️ 航空 ✅／🚆 鉄道 ✅／🚕 タクシー ✅／🚌 バス ✅
• 🚚 トラック：toB5 ＋ toC2（荷主ポータル#164/宅配追跡#165） ← 対称完走へ

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

• トラック toC をさらに（荷主の請求帳票／個人の受取場所・置き配設定 等）で対称完走へ。RouteStops 多日が3回目なら build。※KeEem に確認。

試す

• gunjo.jp ／ 配送ルート RouteStops ／ セグメント切替 SegmentedControl ／ 選択カード RadioCard ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#164
• GunjoUI by UIXHERO

前回の索引修正が翌回で検証された——索引修正にも build→検証ループがある。すり替える罠は、まず安い索引修正で塞ぎ、効果を翌回で測る。TimePicker 手組みは0だった。

---

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