AI にタクシー配車管理を作らせてみた — 現場運用の最頻出の欠落「状態盤」が、4モード目でコンポーネント化（やってみた #141）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠新モード：タクシー⁠（鉄道・航空・バスに続く4モード目）——⁠配車管理コンソール⁠（車両状態盤・配車依頼・マッチング・要対応）。

結果 — 4/5、そして現場運用の土台の最頻出の欠落が作る合図に

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

⁠事務方の四天王（ActionQueue/StatGroup/Meter/MetadataList）は、タクシーという未知のモードにも、用途向けに作られていて用意されている＝1ミリも曲げずに乗った。⁠ ActionQueue の docstring は「配車 / 運用」を名指し・Meter の higher-is-better+target は実車率にあつらえたよう。 ⁠だが車両の状態盤に置き場所が無い。配車コンソールの、まさに中心が手組み。⁠

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

⁠#132（駅務の機器盤）で課題に記録し、#134（ランプの GSE 盤）で2回目⁠。そして #141（タクシーの配車盤）で——予備知識ゼロの AI がまた車両の状態盤を手組みした。⁠3回目（3/3）・しかも別モード。⁠ 予備知識ゼロの AI が頼まれず、3画面で同じ欠落・同じ正体を言語化：

「⁠状態盤 / device-grid / status-matrix のコンポーネントが無い。⁠ 各セルは ListCard で楽だが、⁠盤レベルの関心事＝状態を優先でソート・エリア別のグループ・『空車と故障が目立つ』手がかり は毎回再発明。⁠ StatusBoard/EntityGrid（items＋status→tone のマップ＋groupBy＋onSelect）なら ~80行が設定オブジェクトに潰れる。⁠配車/監視フロアの、まさに中心で、HeatmapChart はそれじゃない。今、運用の領域を横断して最も明確な欠落。⁠」

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

⁠駅務#132 + ランプ#134 + 配車#141 ＝ 別々3人の予備知識ゼロの AI が独立に手組み → 3回ルール。その場で作る。⁠

作る — 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[]・⁠故障を優先でソート⁠（rank→トーンの深刻度）・⁠グループ別の要対応件数⁠・onSelect で選択可（aria-pressed）・状態は⁠アイコン+ラベルの色に安全なピル⁠+トーンのアクセントの帯。
• ⁠HTML/CSS のタイル⁠（SVG でなくデータ駆動のレイアウト）・⁠サーバー描画で安全⁠（onSelect だけ任意指定）。
• ⁠Gantt(行×時間)/DataTable(ソートできる行の表)/HeatmapChart(読み取り専用の色で塗る行列)が構造的になれない盤⁠。索引も 状態盤→StatusBoard に是正（HeatmapChart への誤誘導を停止）。
• PR#393・ブラウザ検証（2エリアのセクション・7つの選択できるタイル・故障トグルで該当タイルが先頭に再ソート＋グループ件数が 4台→1件要対応 に反転・色に安全なピル・0 error）。

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

学び — 「現場運用の欠落は、4モード目で揃った」

事業者向けの土台は #130/#131 で「新業種でも揺るがない」と確認した。だが #132 で⁠初めて『データの形（表→ボード）が違う』欠落⁠＝状態盤が出た。それが #134（ランプ）・#141（タクシー）と⁠現場運用のフロアをまたいで3回⁠揃い、作った。

これは Stringline（#106→#133→#136・経路上を移動するもの）と同じ「⁠横断的な型の欠落は、モードをまたいで3回貯まって固まる⁠」パターンの2例目。⁠事務方の土台は『業種』では完成しているが、『データの形』では欠落が残っていた⁠——表（DataTable）/名簿（ScheduleGrid）/時間×距離（Stringline）/ボード（StatusBoard）。形ごとに1つずつ、3回ルールで埋まっていく。配車という4モード目が、現場運用の監視の最後の主要な形（ボード）を完成させた。

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

📋 モード進捗

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

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

• ⁠タクシーの利用者向け 配車アプリ⁠（呼出・到着まで○分・料金見積・乗車・決済）＝モバイル消費者の土台が4モード目の消費者でどう効くか＋リアルタイム呼出のパターン。

試す

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

現場運用の最頻出の欠落「状態盤」が、駅務→ランプ→配車の3モードをまたいで固まった——事務方の土台は業種でなく「データの形」で欠落が残り、形ごとに3回ルールで埋まる。