#142スコア 4/5運輸：タクシー

AI にタクシー乗務員管理を作らせてみた — 「3つ目の軸（期限）」が3モードを跨いで結晶化（やってみた #142）

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

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

解説記事

AI にタクシー乗務員管理を作らせてみた — 「3つ目の軸（期限）」が3モードを跨いで結晶化（やってみた #142）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。タクシー toB を厚く（配車管理に続く2枚目）——乗務員管理・日報・点呼（点呼/アルコール・営収内訳・拘束時間・資格期限）。

結果 — 4/5、そして「値 vs 期限」の軸が build トリガーに

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

これまでで最も深い back-office React キット。 ActionQueue + AmountBreakdown + CoSign + DataTable + Meter + StatGroup が compliance コンソールの背骨をほぼ手組みゼロでカバー・色のみに非依存（アイコン+テキスト+sr-only）が標準。 だが資格の有効期限に住所が無い。配車#141 に続き2つ目の手組み。

観測の核 — ExpiryBadge 3回目（#131 → #137 → #142）＝3-confirm 発火

#131（航空乗員資格）で初出・#137（バス運転士資格）で2回目。そして #142（タクシー運転士の普通二種免許/適性診断/健診）で——cold AI がまた currencyState() 分類器＋Badge ラッパーを手組みした。3回目（3/3）・3モード跨ぎ。 cold AI が頼まれず、3画面で同じ穴・同じ正体・同じ仕様を言語化：

「date-vs-deadline を何もやらない。 ReferenceValue は数値レンジ専用（Date を取れない）・Meter は数値の消費vs限度・Badge はただのピル。<Currency value={date} warnWithin={60}/>＋純関数 currencyState(date) 分類器＝ReferenceValue が flagValue と対をなすのと全く同じ。これは値vs上限(Meter)/値vsレンジ(ReferenceValue)の『3つ目の軸＝値vs期限』。あらゆる crew/コンプラ コンソールで手組みを強いる唯一の穴。」

しかも索引が正直に機能した：「索引は『期限カレンシーの専用部品は未提供』と明記し、存在しない部品を探さずに済んだ。」#131/#137 で「ReferenceValue は数値専用・期限は ScheduleGrid+Badge で」と索引に書いた誘導（PR#384）が、3回 adopter を誤誘導から守りつつ、3回貯まった——索引の正直さが build のタイミングを計る計器になった。

build — ExpiryBadge ＋ classifyExpiry（有効期限）＝14個目、第3軸を完成

<ExpiryBadge value="2026-07-20" today={today} warnWithinDays={60} />
// 純関数（flagValue の対）— 表/ソート/件数を自前駆動
const { state, days } = classifyExpiry("2026-07-20", { today, warnWithinDays: 60 })
// → { state: "expiring", days: 22 }   // valid / expiring / expired / missing
  • 有効/期限間近/失効/未登録 を色安全な状態チップ（アイコン+ラベル）+日付+残N日/N日超過で。
  • 純関数 classifyExpiry（ReferenceValue の flagValue の対）・RSC-safe（hooks 無し・today は SSR 決定性のため注入推奨、既定 new Date()）。
  • 索引を反転：#131/#137 で書いた「未提供」を「日付の期限は ExpiryBadge」に・Meter(容量)/ReferenceValue(レンジ)/ExpiryBadge(期限) の三幅対を明記。
  • PR#394・browser検証（4状態が固定基準日で valid/expiring/expired/null を正しく分類・日付+残日数・色安全・0 error）。

今回 src build = ExpiryBadge（3-confirm・14個目の結晶化・#383 クローズ）。

学び — 「穴を『軸』で定位すると、build は仕様確定の確認作業になる」

#137 で既に「ExpiryBadge は Meter/ReferenceValue の欠けた第3軸」と書いた。だから #142 の build は、設計を考える作業ではなく、3回目の手組みで仕様が安定したのを確認して写経する作業だった：

  • API（date+thresholds→4状態+残N日）は #137 の時点で既存2部品（Meter/ReferenceValue）から自動的に決まっていた。
  • 純関数 classifyExpiry は flagValue の対として形が決まっていた。
  • 索引の正直な「未提供」が、3回の手組みを数えるカウンタとして働いた。

3-confirm ルールの神髄＝穴を軸で定位できれば、3回貯まるまでに仕様は熟成し、build は迷いゼロの結晶化になる。 Stringline（30回寝かせて最良仕様）・StatusBoard（形で定位）に続く、3例目の「寝かせて熟成」パターン。

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

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge 進行中：BottomActionBar 3/3接近・StatusLevel 2/3・TransitItinerary(legs) 2/3・LineChip 2/3・ThresholdGate

📋 モード進捗

  • ✈️🚆 航空/鉄道：各 toB5+toC6 ✅／🚌 バス：toB2+toC3
  • 🚕 タクシー：toB 2枚（配車/乗務員管理） ／ 残り toC（呼出アプリ）

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

  • タクシー toC 配車アプリ（呼出・到着まで○分・料金見積・乗車・決済）＝モバイル消費者床の4モード目越境＋リアルタイム呼出 archetype（BottomActionBar が4回目で build トリガーに）。

試す

「値 vs 期限」の3つ目の軸が、航空→バス→タクシーの3モードを跨いで結晶化——穴を軸で定位すれば、build は迷いゼロの確認作業になる。

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

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

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

ActionQueueAlertAlertDescriptionAlertTitleAmountBreakdownBadgeButtonCardCardContentCardHeaderCardTitleCheckListCoSignCoSignValueColumnDefDataTableMetadataListMeterPersonCellReferenceValueSeparatorStatGroupTabsTabsContentTabsListTabsTrigger

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

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