AI にバスの配車・乗務員管理を作らせてみた — 土台は3モード目でも揺るがず、欠落は「3つ目の軸」を指した（やってみた #137）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠バスの事業者向けを厚く⁠（運行管理に続く2枚目）——⁠営業所の配車・乗務員管理コンソール⁠（仕業交番・配車・点呼/アルコール・拘束時間・資格期限）。鉄道乗務員#107／航空乗員#131 のバス版。

結果 — 4.5/5、乗務員/配車の土台が3モード目でも全て摩擦ゼロ

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

⁠事務方の一式は、バス乗務にも本当に用途向けに作られていて用意されている＝後付けでない。⁠ 仕業交番(ScheduleGrid)・拘束時間の消費vs限度(Meter・改善基準告示を direction/thresholds で明快に表現)・閾値判定(ReferenceValue+flagValue)・要対応(ActionQueue)・署名/2人確認(SignedRecord/CoSign)・人セル(PersonCell) が⁠全部 摩擦ゼロ・一つも手こずらなかった・モードに依存しない乗務員運用のコンポーネントで、それが分かる⁠。

鉄道乗務員#107→航空乗員#131→⁠バス配車乗務員#137⁠。3モード続けて 乗務員/配車 の土台は構造的な手組みゼロ。

観測の核1 — ExpiryBadge 2回目＝「3つ目の軸」が浮かんだ

運転士の資格期限（大型二種免許／適性診断／健康診断 → 有効/期限間近/失効）を、予備知識ゼロの AI がまた手組みした（PersonCell×{免許,適性,健診} の CSS グリッド＋残日数 Badge）。⁠#131（航空乗員資格）に続き2回目（2/3）。⁠ そして予備知識ゼロの AI が、頼まれず⁠ライブラリに欠けている「3つ目の軸」⁠として言語化：

「⁠ExpiryCell/CurrencyBadge＝日付vs期限→有効/期限間近/失効+残N日・色に依存しない。これは Meter（容量＝値vs上限）と ReferenceValue（値vs範囲）の、日付の領域の兄弟。ライブラリは 値vs上限 と 値vs範囲 を美しくカバー済み——欠けているのは 値vs期限 の軸。全モードの 乗務員/資産/法令遵守 のコンソールに要る（鉄道 動力車操縦者免許・航空 乗員の資格有効性・バス 大型二種・フォークリフト技能講習）。⁠」

→ #383 に2回目を追記。⁠Meter/ReferenceValue/ExpiryBadge ＝ 容量/範囲/期限 の3点セット⁠＝欠落が「個別のコンポーネント」ではなく「⁠直交する軸の欠け⁠」として見えた。

観測の核2 — #131 で打った索引の修正が、効いた

#131（航空乗員）で「資格期限→ReferenceValue」の誤誘導を是正し、「ReferenceValue は数値専用・期限は ScheduleGrid+残日数 Badge で構成」と索引に書いた（PR#384）。それが #137 で：

予備知識ゼロの AI「⁠ライブラリは正直＝索引が『ScheduleGrid のマトリクス＋残日数で色分けした Badge を使え』と言う。⁠ 存在しないコンポーネントを探さずに済んだ。」

⁠索引は仕事をしている（誤誘導を防いだ）。欠落のコンポーネント自体はまだ 2/3。⁠ 索引で「無いことを正しく伝える」のと、3回貯めて「コンポーネントにする」のは、別のレイヤーで同時に進む。

拾った点

• 🟡 ⁠ThresholdGate（アルコール点呼の可否判定）⁠：酒気帯び(値vs0.00) を ReferenceValue（医療系 H/HH 高値/異常高値）に押し込み、labels を全上書きして医療っぽさを消した。⁠点呼義務の中核のチェックが、検査値の表記を借りている⁠＝可否のゲートは StatusLevel(#376) の段階的な仲間→#376 追記。
• 🟡 ⁠status-grid（MetadataList と DataTable の中間）⁠：点呼/資格パネルを grid-cols-[…] で手組み（DataTable は TanStack で5行を常時表示するには重い）＝#133/#134 に続き再確認。

⁠今回 src の新規コンポーネントなし⁠（4.5/5・土台が3モード目も効く＋ExpiryBadge 2/3）。

学び — 「欠落が個別でなく『軸』で見えると、設計が決まる」

ExpiryBadge は #131 で1回目、#137 で2回目。だが #137 の収穫は回数より、予備知識ゼロの AI が⁠欠落を軸として位置づけた⁠こと：ライブラリは「値vs上限(Meter)」「値vs範囲(ReferenceValue)」を持つが「値vs期限」が無い。⁠欠落を『Meter/ReferenceValue の欠けた第3軸』と捉えると、APIの形（日付+しきい値→3状態+残N日・色に依存しない）が既存の2コンポーネントから自動的に決まる。⁠ 3回を待つ間に、欠落の「形」は既に確定した——3回目が来たら、迷わず最良の形で作れる。これは Stringline(#136) を30回寝かせて最良の仕様で固めたのと同じ、「⁠寝かせる間に仕様を熟成させる⁠」の別パターン。

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

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / Stringline 進行中：⁠ExpiryBadge 2/3⁠・StatusBoard 2/3・Gantt 日中モード(一歩手前)・StatusLevel/ThresholdGate・status-grid・CheckboxCard

📋 モード進捗

• ✈️ 航空：事業者向け5 + 利用者向け6 ✅／🚆 鉄道：事業者向け5 + 利用者向け6 ✅
• 🚌 ⁠バス：事業者向け 2枚（運行管理/配車乗務員）⁠ ／ 残り 利用者向け（路線/接近/運賃）

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

• ⁠バスの利用者向け⁠（バス停・接近案内・運賃・乗車）＝モバイル消費者土台（PageHeader/ListCard/FilterChips/StatusLevel…）がバスにどう効くか＝利用者向けの業界を越える地力テストを3モード目で。

試す

• ⁠gunjo.jp⁠ ／ ⁠スケジュールグリッド ScheduleGrid⁠ ／ ⁠メーター Meter⁠ ／ ⁠基準値 ReferenceValue⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠ ／ 前回まで #1〜#136
• ⁠GunjoUI by UIXHERO⁠

土台は3モード目でも揺るがず、欠落は「Meter/ReferenceValue の欠けた第3軸（期限）」を指した——欠落が軸で見えると、3回目を待つ間に仕様は熟成する。