#163スコア 4/5運輸：トラック

AI にトラックの収支ダッシュボードを作らせてみた — トラック toB 完了、直近 build が次々再検証された（やってみた #163）

ルート: /truck-pl
デスクトップ表示
モバイル表示

375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。

解説記事

AI にトラックの収支ダッシュボードを作らせてみた — トラック toB 完了、直近 build が次々再検証された（やってみた #163）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。トラック toB 最後（配車#159・求貨求車#160・車両労務#161・運賃請求#162 に続く5枚目）——運送原価・収支ダッシュボード（車両別/荷主別収支・原価内訳・実車率/原価率・標準的運賃比較）。経営企画向け。

結果 — 4/5、そして直近 build が次々「再検証」された

tsc 緑・デスクトップ情報密度・可変データ駆動。cold AI（群青を一度も触っていない設定）：

このキットは日本の back-office 財務に異様に充実している。 文脈ゼロの adopter が密度の高いアクセシブルな P&L コンソールをほぼ全部 primitive で組めた。減点は1点＝反転 KPI の意味論の穴。

観測の核 — このセッションで build した部品が、トラック財務で再検証された

連載のこのセッションで Leaderboard(#155)・LimitMonitor(#161) を build した。#163 のトラック収支画面で、両方が cold AI に自力発見され native に嵌まった：

  • Leaderboard＝ベスト/ワースト収支ランキング・cold AI「caller-ordered・valueLabel で¥整形・tone per row・deltaTones で up=bad・worst-first の『要対応』を明示・完璧に嵌まった」。
  • LimitMonitor＝実勢運賃 vs 標準的運賃（2024）・cold AI「direction='floor'＋符号付き over が over/under にクリーンに適合」＝拘束時間で build した上限監視が、運賃比較で再利用された。
  • chart床（StatGroup/LineChart/LabeledDonutCard/Delta）＝全データ駆動・static 化ゼロ。

部品は build したら終わりでない＝後発の cold AI が別業種で自力発見して初めて『本当に汎用だった』と分かる。 トラック財務という新文脈で Leaderboard/LimitMonitor が native に嵌まったのは、#155/#161 の build が業種を超えて正しかった証拠だ。

観測の核2 — Statistic の反転 KPI は今 2/3

原価率（低いほど良い）・実車率（高いほど良い）の KPI——上昇=悪い/良いが指標で逆になる：

cold AI「Statistic/StatGroup に goodWhen/direction の概念が無い。tone は trend から既定＝上矢印は常に緑。原価率 +1.2pt(悪化)・実車率 −2.3pt(悪化) で trend(矢印=実際の変化)と tone(意味=良し悪し)を手で別管理した。Delta と Leaderboard は per-sign tones/deltaTones を持つのに Statistic は無い＝哲学でなく見落としに見える。追加すべき最重要は Statistic の good-direction。」

→ #412 goodWhen は今 2/3（#154 営業係数 → #163 原価率/実車率）。あと1回の財務/ops KPI 画面で3-confirm＝build（goodWhen:"high"|"low" で trend から反転トーン導出・明示 tone は優先）。今回は build せず＝goodWhen 専用の目撃はまだ2回（#155/#157 の『severity count の値 tinting』は別機能）。

学び — 「越境再検証」が床成熟の最終証明

連載で部品の検証は3段階で深まった：

  1. build した翌画面で自力発見（#136→#153 Stringline）＝同業種・近接画面。
  2. 別モードの native home で自力発見（#159 RouteStops が貨物配送に）＝業種跨ぎ・本来用途。
  3. 別業種で『たまたま』嵌まる（#163 LimitMonitor が運賃比較に・元は拘束時間）＝設計時に想定しなかった文脈で汎用性が証明される。

③が最も強い検証だ。LimitMonitor は「改善基準告示の拘束時間」のために build したが、cold AI は「標準的運賃との over/under」に当てた——同じ『値 vs 名前付き上限』の形だから。床が成熟すると、新画面は新部品をほぼ生まず、既存部品が想定外の文脈で再利用される。#163 はその最終証明＝トラック toB5 を完了しても、build は1つも出ず、代わりに3つの直近 build が再検証された。

拾った点

  • 🟡 Statistic goodWhen（反転 KPI）= #412 2/3。
  • 🟡 ChartLegend に formatValue 無し（chart 家系で非対称・value は ReactNode）。
  • 🟡 LimitMonitor が "RSC-safe" doc だが formatValue 関数 prop で server から渡すと next build 崩れ（"RSC-safe" は内部 hook の話で関数 prop ではない＝罠・doc 注記推奨）。
  • ✅ Delta が黒字/赤字・標準運賃差に per-sign tones で完璧・LabeledDonutCard が原価内訳に native。

今回 src build なし（4/5・トラック toB5 完了・Leaderboard/LimitMonitor 越境再検証・Statistic goodWhen 2/3）。

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

…LineChip / LimitMonitor / SectionList（このセッションで6部品） 進行中：Statistic goodWhen(2/3)・MatchCard(1/3)・ValidityTimer(1/3)

📋 モード進捗 — トラック toB5（toB 厚く完了）

  • ✈️ 航空 ✅／🚆 鉄道 ✅／🚕 タクシー ✅／🚌 バス ✅
  • 🚚 トラック：toB5（配車/求貨求車/車両労務/運賃請求/運送原価） ← toB 完了・次は toC へ

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

  • トラック toC へ（荷主の集荷依頼・貨物追跡＝B2B2C／個人の宅配・再配達追跡）でトラックも対称完走へ。※KeEem に確認。

試す

トラック toB が完了し、直近 build が次々再検証された——越境再検証（別業種で想定外に嵌まる）が床成熟の最終証明。LimitMonitor は拘束時間のために作ったが、運賃比較に当たった。

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

使用した @gunjo/ui コンポーネント

この画面のソースが直接 import している部品です。

ActionItemActionQueueBadgeCardCardContentCardDescriptionCardHeaderCardTitleChartLegendDataTableDeltaLabeledDonutCardLeaderboardLeaderboardItemLimitMonitorLineChartPageHeaderSegmentedControlSeparatorStatGroupStatisticProps

cold AI が組み上げた実コード

ファイル名をクリックでソースを展開できます。