AI にタクシー配車管理を作らせてみた — 物理opsの最頻出穴「状態盤」が、4モード目で結晶化（やってみた #141）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。新モード：タクシー（鉄道・航空・バスに続く4モード目）——配車管理コンソール（車両状態盤・配車依頼・マッチング・要対応）。

結果 — 4/5、そして物理ops床の最頻出穴が build トリガーに

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

back-office の四天王（ActionQueue/StatGroup/Meter/MetadataList）は、タクシーという未知のモードにも purpose-built で ready＝1ミリも曲げずに乗った。 ActionQueue の docstring は「dispatch / ops」を名指し・Meter の higher-is-better+target は実車率にあつらえたよう。 だが車両状態盤に住所が無い。配車コンソールの literal な中心が手組み。

観測の核 — StatusBoard 3回目（#132 → #134 → #141）＝3-confirm 発火

#132（駅務 機器盤）で起票し、#134（ランプ GSE 盤）で2回目。そして #141（タクシー 配車盤）で——cold AI がまた車両状態盤を手組みした。3回目（3/3）・しかも別モード。 cold AI が頼まれず、3画面で同じ穴・同じ正体を言語化：

「status-board / device-grid / status-matrix 部品が無い。 各セルは ListCard で楽だが、盤レベルの関心事＝状態優先ソート・エリア別グループ・『空車と故障が目立つ』affordance は毎回再発明。 StatusBoard/EntityGrid（items＋status→tone map＋groupBy＋onSelect）なら ~80行が config オブジェクトに潰れる。配車/監視フロアの literal な中心で、HeatmapChart はそれじゃない。今 ops ドメイン横断で最も明確な miss。」

しかも索引バグも再発見：「索引は状態盤を HeatmapChart に誤誘導した＝値の色塗り行列で、ラベル付きクリック可能な状態エンティティの盤ではない。」

駅務#132 + ランプ#134 + 配車#141 ＝ 別々3人の cold AI が独立に手組み → 3-confirm。その場で build。

build — StatusBoard（状態盤）＝13個目

const groups: StatusBoardGroup[] = [
  { label: "渋谷エリア", items: [
    { id:"501", label:"501号車", icon:<IconCar/>, status:"空車", tone:"success", location:"佐藤 乗務", note:"渋谷駅付け待ち", onSelect:()=>open("501") },
    { id:"508", label:"508号車", status:"故障", tone:"danger", note:"エンジン警告灯・対応要", onSelect:()=>open("508") },
  ]},
]
<StatusBoard groups={groups} />   // or flat: <StatusBoard items={...} />

• items[] or groups[]・fault-first ソート（rank→トーン重大度）・グループ別 要対応件数・onSelect で選択可（aria-pressed）・状態はアイコン+ラベルの色安全ピル+トーンのアクセントレール。
• HTML/CSS タイル（SVG でなくデータ駆動レイアウト）・RSC-safe（onSelect だけ opt-in）。
• Gantt(行×時間)/DataTable(ソート行表)/HeatmapChart(読み取り専用の色塗り行列)が構造的になれない盤。索引も状態盤→StatusBoard に是正（HeatmapChart 誤誘導を停止）。
• PR#393・browser検証（2エリアセクション・7選択可タイル・故障トグルで該当タイルが先頭に再ソート＋グループ件数が 4台→1件要対応 に反転・色安全ピル・0 error）。

今回 src build = StatusBoard（3-confirm・13個目の結晶化・#385 クローズ）。

学び — 「物理opsの穴は、4モード目で揃った」

toB床は #130/#131 で「新業種でも揺るがない」と確認した。だが #132 で初めて『データの形（table→board）が違う』穴＝状態盤が出た。それが #134（ランプ）・#141（タクシー）と物理opsフロアを跨いで3回揃い、build。

これは Stringline（#106→#133→#136・経路上を移動するもの）と同じ「横断的な型の穴は、モードを跨いで3回貯まって結晶化する」パターンの2例目。back-office の床は『業種』では完成しているが、『データの形』では穴が残っていた——table（DataTable）/roster（ScheduleGrid）/time-distance（Stringline）/board（StatusBoard）。形ごとに1つずつ、3-confirm で埋まっていく。配車という4モード目が、物理ops監視の最後の主要な形（board）を完成させた。

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

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

📋 モード進捗

• ✈️ 航空：toB 5 + toC 6 ✅／🚆 鉄道：toB 5 + toC 6 ✅／🚌 バス：toB 2 + toC 3
• 🚕 タクシー：toB 1枚目（配車管理）開始 ／ 残り toB・toC（呼出アプリ）

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

• タクシー toC 配車アプリ（呼出・到着まで○分・料金見積・乗車・決済）＝モバイル消費者床が4モード目消費者でどう効くか＋リアルタイム呼出 archetype。

試す

• gunjo.jp ／ 状態盤 StatusBoard ／ アクションキュー ActionQueue ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#140
• GunjoUI by UIXHERO

物理opsの最頻出穴「状態盤」が、駅務→ランプ→配車の3モードを跨いで結晶化——back-office 床は業種でなく「データの形」で穴が残り、形ごとに3-confirm で埋まる。

---

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