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

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠タクシーの事業者向けを厚く⁠（配車管理に続く2枚目）——⁠乗務員管理・日報・点呼⁠（点呼/アルコール・営収内訳・拘束時間・資格期限）。

結果 — 4/5、そして「値 vs 期限」の軸が作る合図に

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

⁠これまでで最も深い、事務方向けの React ライブラリ。⁠ ActionQueue + AmountBreakdown + CoSign + DataTable + Meter + StatGroup が 法令遵守 コンソールの背骨をほぼ手組みゼロでカバー・色のみに依存しない（アイコン+テキスト+sr-only）が標準。 ⁠だが資格の有効期限に置き場所が無い。配車#141 に続き2つ目の手組み。⁠

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

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

「⁠日付vs期限 を何もやらない。⁠ ReferenceValue は数値の範囲専用（Date を取れない）・Meter は数値の消費vs限度・Badge はただのピル。⁠<Currency value={date} warnWithin={60}/>＋純関数 currencyState(date) 分類器＝ReferenceValue が flagValue と対をなすのと全く同じ。これは 値vs上限(Meter)/値vs範囲(ReferenceValue)の『3つ目の軸＝値vs期限』。あらゆる 乗務員/法令遵守 のコンソールで手組みを強いる唯一の欠落。⁠」

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

作る — 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 の対）・⁠サーバー描画で安全⁠（hooks 無し・today はサーバー描画の再現性のため注入推奨、既定 new Date()）。
• ⁠索引を反転⁠：#131/#137 で書いた「未提供」を「日付の期限は ExpiryBadge」に・⁠Meter(容量)/ReferenceValue(範囲)/ExpiryBadge(期限) の3点セット⁠を明記。
• PR#394・ブラウザ検証（4状態が固定の基準日で valid/expiring/expired/null を正しく分類・日付+残日数・色に安全・0 error）。

⁠今回 src で作ったもの = ExpiryBadge⁠（3回目・⁠14個目⁠のコンポーネント化・⁠#383 をクローズ⁠）。

学び — 「欠落を『軸』で位置づけると、作るのは仕様確定の確認作業になる」

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

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

⁠3回ルールの神髄＝欠落を軸で位置づけられれば、3回貯まるまでに仕様は熟成し、作るのは迷いゼロのコンポーネント化になる。⁠ Stringline（30回寝かせて最良の仕様）・StatusBoard（形で位置づけ）に続く、3例目の「寝かせて熟成」パターン。

📊 コンポーネント化スコアボード（作成済 ⁠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

📋 モード進捗

• ✈️🚆 航空/鉄道：各 事業者向け5+利用者向け6 ✅／🚌 バス：事業者向け2+利用者向け3
• 🚕 ⁠タクシー：事業者向け 2枚（配車/乗務員管理）⁠ ／ 残り 利用者向け（呼出アプリ）

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

• ⁠タクシーの利用者向け 配車アプリ⁠（呼出・到着まで○分・料金見積・乗車・決済）＝モバイル消費者の土台の4モード目の業界越え＋リアルタイム呼出のパターン（BottomActionBar が4回目で作る合図に）。

試す

• ⁠gunjo.jp⁠ ／ ⁠有効期限 ExpiryBadge⁠ ／ ⁠基準値 ReferenceValue⁠ ／ ⁠メーター Meter⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠ ／ 前回まで #1〜#141
• ⁠GunjoUI by UIXHERO⁠

「値 vs 期限」の3つ目の軸が、航空→バス→タクシーの3モードをまたいで固まった——欠落を軸で位置づければ、作るのは迷いゼロの確認作業になる。