AI にロケーション管理を作らせてみた — 前回作った ScanGate が、翌回そのまま使われた（やってみた #50）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠第50画面・物流/倉庫(WMS)4枚目⁠——⁠在庫ロケーション管理 / 棚卸移動⁠（ロケ一覧×充填率メーター × 在庫照会/滞留 × 棚→商品→棚の移動 × ゾーン集計）。

50回目。#47-#49 がオーダー単位のフロー（取り出す/格納する/出荷する）だったのに対し、今回は⁠在庫の俯瞰＋整理⁠——各棚がどれだけ埋まっているかを一覧し、滞留在庫を見つけ、棚から棚へ在庫を移す、整理の画面。

結果 — 4.5/5

tsc/build 緑・console 0・375px カード化・閾値で色が変わる充填メーター（緑/黄/赤）・充填率でソート・SKU 検索・移動（元棚→商品→先棚→数量）で過剰移動を制限＋容量チェック＋読み上げ・統合検知・KPI 再計算・h1 1個・36個のメーター全てに読み上げ名。

今回の主役 — 前回作ったコンポーネントが、翌回そのまま使われた（2連発）

この回がきれいに示したのは、⁠「前回反映した投資が、次の予備知識ゼロの AI にそのまま返ってくる」が連続している⁠ことです:

⁠① ScanGate（前回 #49 で作った）を、#50 の AI が移動フローに即採用:⁠

⁠ScanGate — 使った、きれいに合った、手こずらなかった。⁠ 3つの順序付きの段（移動元棚 → 商品 → 移動先棚）、onScan(code, ctx) が {ok, message, advance, value} を返し、ctx.values[stageId] で前の段を読み、handle.reset() で「次の移動へ」。⁠最終段の advance:"stay" で、数量入力のためにその場に留まれる——ちょうど必要だった逃げ道だ。⁠

ScanGate は #49 で「ピッキング/入庫/出荷の3画面が同じ2段ゲートを手組みした」から作ったコンポーネント。それを ⁠翌回の在庫移動（3段：元→商品→先）が、設計時に想定していない3段フローで、そのまま使いました⁠。API（advance/value/ctx.values/reset）が、別の作法に耐えた。

⁠② Progress の tone（前回 #48 で追加）が、#48 の小細工を消した:⁠

Progress の tone が出荷されたので、⁠#48 の重ねる小細工（bg-foreground 固定のバーの上に色バーを重ねる）はもう不要⁠——tone を直接使った。#48 から大きく改善。

#48 で「容量メーターの色が出せず -mt-2.5 で重ねた」と書いた、まさにその不備。tone を足したことで、#50 は重ねずに済みました。⁠不備を直すと、次の回でその回避策が消える⁠——これが複利の、最も具体的な形です。

横断的なコンポーネントも全採用: Delta（移動の純増減・移動元の減少は info-blue に上書き＝計画的な移動は"悪い"ではない）・DataTable（ソートできる本物の <button> ヘッダ・renderCard で375px・getRowState で満杯の行を着色）・Statistic（5 KPI）・toCsv/downloadCsv（BOM 付きの日本語ヘッダ）。

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

• 🟠 ⁠容量 Meter コンポーネント⁠（#230・⁠2回目⁠＝#48＋#50）。Progress+tone で平らなバーは足りるが、倉庫管理の充填メーターはさらに3つ欲しい——予備知識ゼロの AI が具体的な API を提示: <Meter value max incoming? thresholds={[{at:80,tone:"warning"},{at:100,tone:"destructive"}]} valueText size="sm|inline" />。(a) 閾値から色調を導く（毎画面 fillTone(pct) を書かない）・(b) ⁠現在＋入荷分の重ね表示⁠で「移動後」をプレビュー・(c) ⁠テーブルセル内のコンパクトなインライン⁠版。LocationMeter(~95行)で手組み。あと1回で作る。
• 🟡 DataTable の <table> が min-w-[720px] table-fixed で、renderCard を渡さないとモバイルで横スクロール（renderCard はあるので、明示的に有効化すればよい）。
• 🟡 ScanGate が確定値を内部の ref に持つので、自前の数量 input/Delta プレビュー/確定を動かすには onScan/onStageChange で React の state に写す（gate が自身のフローを持つ以上、想定内）。

学び — 複利のサイクルが「次の回」まで縮まった

#47-#49: 3画面の欠落 → ScanInput → ScanGate（数回かけて育つ）
#48 → #50: Progress tone を足す → 次の回で小細工が消える（1回で返る）
#49 → #50: ScanGate を作る → 次の回でそのまま使われる（1回で返る）

連載の前半は「数回かけて欠落がコンポーネントに育つ」でした。50回を超えて、⁠反映した投資が"次の1回"で返ってくる⁠ようになりました。ライブラリが厚くなるほど、新しい予備知識ゼロの AI は「探して・組み合わせる」だけになり、こちらの修正は⁠翌回に即検証されます⁠。第50画面は、その複利サイクルが最短になったことを示した回。物流4枚目も src 修正ゼロ＝ライブラリが持ちこたえました。

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

• ⁠物流をもう1枚⁠（配送ルート/積込 or 返品入荷(返品物流)）で 容量 Meter#230 を3回目＝作る閾値へ、巡回経路#228 も。または別業界へ。方針: 1業界3〜5枚・可能な限り違う内容・業界特有UI最優先。

試す

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

まだ alpha。第50画面。前回作った ScanGate が翌回そのまま使われ、前々回の Progress tone が前回の小細工を消した回。