AI にトラックの労務コンプライアンス画面を作らせてみた — 「値 vs X」系統の4番目がコンポーネント化（やってみた #161）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠トラックの事業者向けを厚く⁠（配車#159・求貨求車#160 に追加）——⁠車両・労務管理⁠（車検・デジタコ運転傾向・改善基準告示 拘束時間/連続運転/休息）。運行管理者向けの情報密度コンソール。

結果 — 4/5、そして「値 vs X」系統が4つになった

tsc 緑・デスクトップ情報密度。予備知識ゼロの AI（群青を一度も触っていない設定）：

⁠このライブラリはまさにこの領域のために作られたかのよう（怪しいほど）。⁠ ExpiryBadge の docstring は車検を名指し、StatusBoard は配車盤、ActionQueue は失効防止。汎用の shadcn を曲げたのでなく、誰かが既に日本の車両/労務コンソールを出荷した感触。唯一の欠落は拘束時間の上限モニター——それがこれが5点でない理由。

観測の核 — LimitMonitor が3回目でコンポーネント化（系統の4番目）

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

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

予備知識ゼロの AI が LimitMonitor.tsx を手組みした。⁠これは #154（営業係数＝Meter の max 割合問題）・#159（拘束時間＝Meter+ReferenceValue で組み合わせ）に続く3回目＝3回確認。その場で作った⁠：

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

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

学び — 予備知識ゼロの AI が「自分で指摘した罠」に自分で落ちた

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

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

1. ⁠「知っている」と「やる」は別⁠＝予備知識ゼロの AI はサーバー/クライアント境界を正しく説明できたのに、純関数を client ファイルに同居させて踏んだ。⁠型で守られない規約は、説明できても破られる。⁠
2. ⁠だから出荷版が効く⁠＝群青の LimitMonitor/classifyLimit は ⁠サーバー描画で安全な設計（"use client" 無し・純関数は server から呼べる）⁠。予備知識ゼロの AI の手組みは余計な "use client" で500したが、⁠出荷版を採用すれば設計でこの罠が消える⁠。これが「コンポーネントを作る」価値の核＝⁠正しいアクセシビリティ/サーバー描画の規約をコンポーネントに焼き込み、採用者が知らなくても守られる⁠。

（※ギャラリー用に、予備知識ゼロの AI 画面の余計な "use client" 1行を削除して描画を回復＝純粋なコンポーネントなので挙動不変。）⁠今回 src で作ったもの = LimitMonitor（#417→PR#420）⁠。4/5・系統が完成・サーバー描画の規約の焼き込み。

📊 コンポーネント化スコアボード（作成済 ⁠19個⁠）

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

📋 モード進捗 — トラックの事業者向け3

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

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

• トラックの事業者向けをさらに（運賃・請求／運送原価）／その後 利用者向け（荷主の集荷依頼・貨物追跡）。※次回までに決める。

試す

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

「値 vs X」系統の4番目がコンポーネント化した——そして予備知識ゼロの AI が自分で指摘したサーバー描画の罠に自分で落ちた。型で守られない規約は説明できても破られる。だから出荷版が、正しい規約をコンポーネントに焼き込んで効く。