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

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠トラックの利用者向けを厚く⁠（荷主ポータル#164 に続く受取人=個人 C 側）——⁠宅配便 配送追跡・再配達⁠（追跡・再配達依頼・受け取り時間帯/方法・通知）。モバイルファースト。

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

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

⁠本物の強い 利用者向け/モバイルのライブラリ。⁠ 必要なコンポーネントはほぼ存在し、モバイルファーストが既定で、逆引きの索引が全判断で正しく誘導した。減点は1点＝複数日追跡タイムラインの欠落。

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

前回 #164 で「TimePicker は正確な時刻なのに索引が時間帯に見せる すり替えの罠」を見つけ、⁠PR#423 で索引を是正⁠（時間帯→SegmentedControl/RadioGroup・TimePicker は正確な時刻と明記）した。そして #165（翌回）の予備知識ゼロの AI は：

予備知識ゼロの AI「⁠受け取り時間帯＝手組み不要・混乱なし。by-use-case 索引に明示の正しい注記『配達/集荷の時間帯は SegmentedControl か RadioGroup で、TimePicker ではない』があった。SegmentedControl を使った。TimePicker はあるし、予備知識のない採用者は掴むかもしれない——索引が積極的にその罠から逸らす。良い。⁠」

⁠TimePicker 手組み = 0。⁠ #164 で見つけた すり替えの罠を #423 で塞ぎ、#165 でその修正が⁠翌回検証された⁠——予備知識ゼロの AI は罠を踏まずに正解（SegmentedControl）に着地した。これはコンポーネントの 作る→検証だけでなく、⁠索引修正にも 作る→検証ループがある⁠ことを示す。⁠安い修正（索引追加）でも、後発の予備知識ゼロの AI が罠を避けて初めて『効いた』と分かる。⁠

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

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

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

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

→ #422 ⁠RouteStops 複数日タイムスタンプ 2/3⁠（#164 荷主ポータル → #165 宅配追跡）。⁠あと1回の複数日追跡画面で 3回確認 → 作る⁠（stop ごとに自由形式の dateLabel/timestamp・HH:MM は1日内用に維持）。

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

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

1. ⁠コンポーネントの 作る→検証⁠＝作ったコンポーネントが後の画面で自力発見される（SectionList #162→#164＝2回）。
2. ⁠索引修正の 作る→検証⁠＝索引を直すと後の予備知識ゼロの AI が罠を避ける（TimePicker すり替え #423→#165＝1回）。

②は安い（1行の索引追加）が、効果は①と同じく⁠後発の予備知識ゼロの AI が踏まないこと⁠でしか測れない。土台成熟後のこのテストは、この⁠2層のループ⁠を回す——欠落をコンポーネントで塞ぎ（①）、罠を索引で塞ぎ（②）、両方を翌回以降で検証する。#165 は②の最初の明確な検証回＝⁠安い索引修正が、翌回で『TimePicker 手組み 0』として効いた。⁠

拾った点

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

⁠今回 src の新規コンポーネントなし⁠（4/5・索引修正の翌回検証・RouteStops 複数日 2/3）。

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

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

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

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

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

• トラックの利用者向けをさらに（荷主の請求帳票／個人の受取場所・置き配設定 等）で対称完走へ。RouteStops 複数日が3回目なら作る。※次回までに決める。

試す

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

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