AI にトラック配車システムを作らせてみた — 5モード目で部品が「本当の自宅」に帰った(やってみた #159)
/truck-dispatch375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI にトラック配車システムを作らせてみた — 5モード目で部品が「本当の自宅」に帰った(やってみた #159)
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui(群青)を、文脈ゼロの cold な AI に実 UI で作らせる連載。新モード=5モード目・最後=トラック配送を toB から——配車・運行管理コンソール(運送案件・車両/乗務員割当・集荷→配送ルート・拘束時間・運行状況)。配車担当向けの情報密度コンソール。
結果 — 4.5/5、最近 build した部品が次々「本当の自宅」に帰った
tsc 緑・デスクトップ情報密度。cold AI(群青を一度も触っていない設定):
これまでキットで見た中で最も purpose-built に近い適合。 いくつかの部品は、誰かが貨物配車盤を開きながら設計したかのよう。キットと戦う時間はほぼゼロだった。
トラック配車は、運輸 arc で build してきた部品の真の native homeだった。
観測の核 — native 検証ラッシュ(4部品が自宅に帰った)
RouteStops=貨物配送 route の真の自宅。cold AI「集荷→配送 の番号付き stop・各 stop の 済/配送中/未・plannedTime vs actualTime の自動 delta・これがまさにモデルする対象・誤適用ではない」。RouteStops は語彙が配送固定(未配/配送中/遅れ)で、旅程(#126/#358)では誤適用だった。ここで初めて本当の自宅に帰った。Gantt resolution="hour"(#153 build)=車両運用 intraday で自力発見。cold AI「1営業日(05:00-17:00)を1時間刻みで HH:MM ヘッダ・日軸と戦っていない・docstring が『日列だと1日が1セルに潰れる』と書く=この case が予期されていた・『built for this』の最良の瞬間」。#153 で build した intraday モードが、5モード後の cold AI に自力発見された=build 検証。StatusBoard(配車盤)/Leaderboard(稼働ランキング)/SegmentedControl(ビュー切替) 全て zero-friction=3部品とも自力発見検証。ReferenceValueのサプライズ勝ち=医療(vitals)向けと銘打たれているが汎用 value-vs-range として改善基準告示の「中断必須(4h超)」フラグに完璧適合。
cold AI「RouteStops/Gantt(hour)/StatusBoard/Leaderboard が turnkey・ReferenceValue は医療用途を超えて一般化・bespoke UI はほぼ書かなかった。」
学び — 「5モード目でも床は飽和しない」(が、出る穴の性質が変わる)
#158(バス完走)で「4モード目の完走では新部品がほぼ出ない=結晶化が一巡」と書いた。では5モード目(トラック)で本当に穴は出ないのか? ——答えは出る、が性質が変わった:
- ①新規部品の穴は激減(build した床が native に嵌まる検証ラッシュ)。
- ②残った穴は『既存部品が索引に隠れている』型=DataTable の一括選択割当は
ActionDataTable(selectedIds+bulkActions)が既に出荷しているのに、索引が DataTable に誘導して隠す。cold AI「配車は本質的に『未割当案件を N 件選択→車両に割当』なのに、それを手組みさせる唯一のワークフロー」。 - ③ニッチな業種特有の穴=拘束時間/改善基準の LimitMonitor(値 vs ソフト/ハード上限+超過状態)。Meter+ReferenceValue で composite できるが専用部品が欲しい。
つまり結晶化が一巡すると、cold-test の主産物は「新部品 build」から「索引の誤誘導是正(既存部品の発掘)」に移る。#155(Rankings→StatGroup)・#150(Rating→動かない)・#159(案件一覧→ActionDataTable 隠れ)は全て同型=部品はあるのに索引が間違った/不完全な答えを出す。これは #150 で書いた「能動的な誤誘導」が、床成熟後の主たる欠陥になるという予言の成就だ。
→ #159 のその場対応=索引是正(案件一覧+一括割当→ActionDataTable に誘導)PR#418+LimitMonitor #417/Meter 絶対閾値 #412 2回目。今回 src build なし(4.5/5・native 検証ラッシュ・索引是正)。
📊 結晶化スコアボード(build 済 18個)
…Gantt(intraday) / Leaderboard / SegmentedControl / LineChip 進行中:SectionList/TransactionList(2/3)・LimitMonitor/Meter絶対閾値(2/3)・ValidityTimer(1/3)
📋 モード進捗 — 5モード目(トラック)開始
- ✈️ 航空 ✅/🚆 鉄道 ✅/🚕 タクシー ✅/🚌 バス ✅
- 🚚 トラック:toB1(配車#159) ← 新モード・最後・toB から開始
次回予告(やってみた #160)
- トラック toB をさらに(求貨求車マッチング・運賃請求・車両整備 等)/その後 toC(荷主の集荷依頼・追跡)。※KeEem に確認。
試す
- gunjo.jp / 配送ルート RouteStops / ガント Gantt(intraday)/ 状態盤 StatusBoard / 一括操作表 ActionDataTable / npm
@gunjo/ui/ GitHub / 前回まで #1〜#158 - GunjoUI by UIXHERO
5モード目で部品が「本当の自宅」に帰った——結晶化が一巡すると、cold-test の主産物は新部品 build から「索引の誤誘導是正(既存部品の発掘)」に移る。
<!-- 公開前: 相互URL差込/スクショ確定/EN(dev.to)ミラー -->
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import している部品です。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。