AI に配車・積込を作らせてみた — 容量メーターが3回目でコンポーネント化、Badge のサーバー/ブラウザずれバグも出た（やってみた #51）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。物流/倉庫(WMS)5枚目——⁠配車 / 積込 / 配送ルート⁠（便/車両 × トラック積載率メーター × 積込スキャン × 配送ルート/順序/ETA × 積み残し）。

#47-50 の倉庫内オペに続き、出庫の最後——トラックに積んでルートを組んで出発させる配送センターの配車画面。⁠車両の重量・容積の積載率⁠を見ながら出荷を割り当て、積込をスキャンし、配送順を並べて出発確定する。

結果 — 4/5

tsc/build 緑・console 0（Badge 修正後）・375px・閾値で色が変わる積載率メーター・出荷割当でメーターが「積んだら何%になるか」をプレビュー・超過は積み残しでブロック・積込スキャン・配送順の並べ替えで ETA 再計算・出発確定ゲート・h1 1個。

今回の本題① — 容量メーターが3回目 → コンポーネント化

倉庫の3画面（#48 棚の充填・#50 ロケーション充填・#51 トラック積載率）が、⁠同じ容量メーターを毎回手組み⁠していました。Progress＋tone で平らなバーは出せても、容量メーターが本当に欲しい3つを Progress は持ちません:

上位のコンポーネントが足りない: 容量用の Meter / Gauge だ。Progress は (a) ⁠閾値から色調を導く⁠ことができない（毎画面 fillTone(pct) を書く）・(b) ⁠現在＋入荷分の重ね表示⁠で「これを積んだら超過するか」をプレビューできない・(c) ⁠テーブルセル内のコンパクトなインライン⁠が無い。CapacityMeter.tsx を毎回手組み。

⁠3回ルール発火⁠で Meter(#230)（PR #235）を出荷:

<Meter label="重量積載率" value={2100} max={3000} incoming={350} unit="kg"
       thresholds={{ warning: 0.8, over: 1 }} />

<Meter size="inline" value={41} max={40} label="棚 D-03 充填" />

• role="meter"・thresholds から⁠色調を自動で導く⁠（満載間近→warning・超過→destructive）
• ⁠incoming⁠ が value の上に⁠縞模様の重ね表示⁠を重ね、色調も動かす——⁠確定前に超過を警告⁠（読み上げは「2100kg + 350kg → 82%」に）
• size="inline" はテーブルセル用の細いバー＋コンパクトな%・unit・label(読み上げ名)・aria-valuetext＝⁠色だけに意味を乗せない⁠・トークン駆動でダークモードもタダ

ブラウザ実証: 70%→success / 84%→warning / 100・102%→destructive、incoming で縞のセグメント（left 70%・幅 11.67%=350/3000）＋プレビューの読み上げ、inline がセル内に収まる。Progress は平らなバー用に tone(#229) を維持、Meter は容量に特化した兄弟（role="meter" vs progressbar）。

今回の本題② — Badge の「サーバーとブラウザでずれる」バグ（🔴 実バグ）

予備知識ゼロの AI が <Badge>到着 08:30</Badge> を <p> の中に置いたら、⁠実行時にクラッシュ（サーバーとブラウザの描画がずれる hydration の問題）⁠——「div cannot be a descendant of p」。tsc も next build も通り、⁠ブラウザでだけ捕まりました⁠。

Badge は既定が as="div" でした。ステータス表示のピルは、文章・段落・インラインの行の中に常に置かれる（文中に置ける要素であるべき）。ブロック要素の <div> を既定にするのはハマりどころ。Badge は inline-flex のスタイルなので <span> でも見た目は同一で、文中に置いても正しい HTML（onRemove の <button> も span 内で正しい）。→ ⁠既定を span に修正⁠（#233・PR #234）。⁠型チェックとビルドをすり抜けるバグは、予備知識ゼロの AI に作らせるテストで実際にブラウザに載せるからこそ出ます⁠。

複利も全採用

• ⁠ScanGate（#49 で作った）⁠ — 車両/便→カートンの2段積込スキャンに採用「使った、よく合う・advance:"stay" でカートンを連続スキャン」。⁠#49→#50→#51 と3回連続で別の画面に使われた。⁠
• Delta（残容量・空き=success/超過=destructive 上書き）・Statistic（残重量/容積・積載個数の KPI）・Badge/Alert（状態・積み残し読み上げ）・Progress tone も。

課題に記録だけした欠落（3回ルール未達）

• 🟠 ⁠配送ルート/立ち寄り先リスト⁠（#228・⁠2回目⁠＝#47 ピッキングの巡回経路＋#51 配送順）。順序付きの配送先（ETA 付き・並べ替え可）を Timeline(表示専用)/Stepper(固定のウィザード) では組めず手組み。RouteStops（or Timeline に onReorder＋各項目の time/eta）が理想。あと1回で作る。

学び — 同じ回で「3回目を作る」「実バグを直す」が両立した

作る（3回目の足りないコンポーネント）: 容量 Meter #230（#48+#50+#51）
直す（ブラウザでだけ出た実バグ）: Badge の <div> 既定 #233
課題に記録（2回目）        : 立ち寄り先リスト #228

予備知識ゼロの AI に作らせるテストの価値は、⁠(a) 頻度でコンポーネントを浮かび上がらせる⁠だけでなく、⁠(b) tsc/build をすり抜ける実行時のバグを、実ブラウザで捕まえる⁠こと。#51 はその両方が1回で出た回——容量メーターは3画面で育って Meter に、Badge は <p> の中という"普通の使い方"で初めてクラッシュした。規律（3回ルール）と検証（実ブラウザ）が、別々の欠落を同時に拾いました。

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

• ⁠物流をもう1枚⁠（返品入荷/リバース or 配送追跡）で立ち寄り先リスト#228 を3回目＝作る閾値へ、または別業界へ。方針: 1業界3〜5枚・可能な限り違う内容・業界特有UI最優先。

試す

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

まだ alpha。容量メーターが3回目でコンポーネント化し、Badge の「サーバーとブラウザでずれる」バグも実ブラウザで捕まえた回。