AI にトラックの労務コンプライアンス画面を作らせてみた — value-vs-X 家系の4番目が結晶化（やってみた #161）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。トラック toB を厚く（配車#159・求貨求車#160 に追加）——車両・労務管理（車検・デジタコ運転傾向・改善基準告示 拘束時間/連続運転/休息）。運行管理者向けの情報密度コンソール。

結果 — 4/5、そして「value-vs-X 家系」が4人になった

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

このキットはまさにこのドメインのために作られたかのよう（suspiciously）。 ExpiryBadge の docstring は車検を名指し、StatusBoard は配車盤、ActionQueue は失効防止。generic shadcn を曲げたのでなく、誰かが既に日本のフリート/労務コンソールを出荷した感触。唯一の穴は拘束時間の上限モニター——それがこれが5点でない理由。

観測の核 — LimitMonitor が3回目で結晶化（家系の4番目）

拘束時間/連続運転/休息を改善基準告示の上限と比べる——Meter を当てたくなる。だが：

cold AI「Meter の target は『参照のみ・トーンを駆動しない』と docstring が書く＝上限線は描けるが超過状態は自分で分類が要る。しかも閾値が max の割合なので『13h 上限の90%で警告』が 13×0.9/16 と back-compute になり脆い。ReferenceValue は超過状態の意味論はあるがバーも上限線も無い＝『どれだけ近いか』を見せられない。」

cold AI が LimitMonitor.tsx を手組みした。これは #154（営業係数＝Meter の max 割合問題）・#159（拘束時間＝Meter+ReferenceValue で composite）に続く3回目＝3-confirm。その場で build した：

• LimitMonitor＝値 vs 名前付きソフト/ハード上限（実単位そのまま・基準13h/上限16h）・超過トーンをそこから導出（ok/near/over/critical）・上限を線で描画・どれだけ近い/超過かのバー。direction="floor" で下限（休息11h）。
• value-vs-X 家系の4番目＝ExpiryBadge（値 vs 期限）・ReferenceValue（値 vs 範囲）・Meter（値 vs 容量）・LimitMonitor（値 vs 名前付き上限）。それぞれ純関数のペア（classifyExpiry / flagValue / … / classifyLimit）を持つ。
• Meter の罠を根治：target が参照のみ＋閾値が max 割合、という cold AI が walked the dead-end path を、実単位の上限＋導出トーンで解消。索引も value-vs-limit → ReferenceValue/Meter の誤誘導を是正。

ブラウザで 拘束12.5h（基準13h・1h 前から near）→基準間近・休息9.5h（下限11h・floor）→下限まで1.5h不足 を確認＝PR#420（#417 クローズ）。結晶化 19個目。

学び — cold AI が「自分で指摘した罠」に自分で落ちた

面白い事件があった。cold AI はレポートで**「SSR 境界は型システムに守られていない＝function prop を server component に import しても tsc は通り next build だけが捕まえる」と自ら警告**した。そして、まさにその罠に自分で落ちた——手組みの classifyLimit を "use client" の LimitMonitor.tsx に置き、それを server の page.tsx から呼んで 実行時 500（tsc は緑だった）。

これは2つのことを教える：

1. 「知っている」と「やる」は別＝cold AI は SSR 境界を正しく説明できたのに、純関数を client ファイルに同居させて踏んだ。型で守られない規約は、説明できても破られる。
2. だから shipped 版が効く＝群青の LimitMonitor/classifyLimit は RSC-safe 設計（"use client" 無し・純関数は server 呼び可）。cold AI の手組みは spurious な "use client" で500したが、shipped 版を adopt すれば設計でこの罠が消える。これが「部品を build する」価値の核＝正しい a11y/SSR 規約を部品に焼き込み、adopter が知らなくても守られる。

（※ギャラリー用に、cold AI 画面の spurious な "use client" 1行を削除して描画を回復＝純コンポーネントなので挙動不変。）今回 src build = LimitMonitor（#417→PR#420）。4/5・家系完成・SSR 規約の焼き込み。

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

…Leaderboard / SegmentedControl / LineChip / LimitMonitor 進行中：MatchCard/PairingPanel(1/3)・SectionList(2/3)・ValidityTimer(1/3)

📋 モード進捗 — トラック toB3

• ✈️ 航空 ✅／🚆 鉄道 ✅／🚕 タクシー ✅／🚌 バス ✅
• 🚚 トラック：toB3（配車#159/求貨求車#160/車両労務#161） ← toB を厚く中

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

• トラック toB をさらに（運賃・請求／運送原価）／その後 toC（荷主の集荷依頼・貨物追跡）。※KeEem に確認。

試す

• gunjo.jp ／ 上限監視 LimitMonitor（新）／ 有効期限 ExpiryBadge ／ 基準値 ReferenceValue ／ メーター Meter ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#160
• GunjoUI by UIXHERO

value-vs-X 家系の4番目が結晶化した——そして cold AI が自分で指摘した SSR 罠に自分で落ちた。型で守られない規約は説明できても破られる。だから shipped 版が、正しい規約を部品に焼き込んで効く。

---

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