#155スコア 4.5/5運輸：バス

AI にバスの安全・事故管理コンソールを作らせてみた — Leaderboard が3回目で結晶化、その場で build した（やってみた #155）

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

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

解説記事

AI にバスの安全・事故管理コンソールを作らせてみた — Leaderboard が3回目で結晶化、その場で build した（やってみた #155）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。バス toB を toB5 へ（運行#136・配車#137・計画#153・営収#154 に追加＝鉄道航空と対称に）——運輸安全マネジメント・事故/苦情管理（事故・インシデント・ヒヤリハット・苦情・有責無責・営業所別安全指標・事故報告承認・再発防止）。安全管理者向けの情報密度コンソール。

結果 — 4.5/5、そして Leaderboard が3回目で結晶化

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

このキットは明らかにこの種の日本の back-office/ops コンソール向けに作られている。 画面のほとんどが実部品で、手組みのマークアップではない。半点減らしたのは唯一の本当の穴——ranking/leaderboard 部品が無い——と細かな ergonomics。

観測の核 — Leaderboard が3回目（3-confirm 到達）→ その場で build

営業所別/系統別の安全指標ランキング（worst-first＝要対応の並び）——Leaderboard を当てたい。だが：

cold AI「これが本当の穴。ranking/leaderboard 部品が無い。barrel を grep しても rank/leaderboard は無い。{rank,label,value,delta,tone}[] を worst-first で並べランクチップ付きの Leaderboard/RankingList があれば ~40行の手組みを置換できた。追加価値が最も高いのは ranking/leaderboard 部品。しかも /docs/by-use-case は『Ranking/Worst Performers』を StatGroup に誘導する＝誤りだ。」

これで Leaderboard は3回目＝3-confirm 成立（taxi #143 売上ランキング → bus #154 系統別収支 → bus #155 営業所別安全指標）。その場で build した：

  • Leaderboard＝事前順序付けの行＋ランクチップ＋値バー（max 正規化）＋Delta。並びは呼び出し側が決める（best-first の top-N／worst-first の要対応）＝ランクは配列位置＝「誰が1位か」は明示的な呼び出し側の判断・コンポーネントは再ソートしない。
  • deltaTones={{positive:"destructive"}} で「上昇＝悪い」ランキング（事故率/コスト/苦情）の Delta を赤反転。
  • BarChart（順位なしチャート）でも StatGroup（無順序KPI）でもない明確な ranked-list primitive。
  • 索引の誤誘導も是正＝by-use-case に Leaderboard 項目を追加し、StatGroup には「順位ではない＝番付は Leaderboard」と明記。

design:verify 緑（構造ドリフト無し）・tsc・build 緑・ブラウザでランクチップ・バー正規化（100%/89.4%/65.97%＝4820/4310/3180÷4820）・データ slot を確認＝PR#413（#395 クローズ）。結晶化 16個目。

学び — 「能動的な誤誘導」は build のトリガーを早める

#150 で「索引が動かない部品に誘導するのが最悪」と書いた。Leaderboard も似た構造だった：索引が『Ranking/Worst Performers → StatGroup』と誘導＝StatGroup は無順序の KPI 群で番付ではない＝文脈ゼロ adopter は StatGroup を当てて「順位が出ない」と詰まる。これは「穴（部品が無い）」に「能動的な誤誘導（索引が間違った答えを出す）」が重なった形：

  • 単なる穴なら、adopter は手組みに向かう（実際 3回手組みされた）。
  • だが索引が誤誘導すると、adopter は間違った部品を当てて時間を溶かす。

だから Leaderboard は3回目で部品 build と索引是正をセットにした。「部品が無い」と「索引が間違った答えを出す」は別の害＝前者は手組みコスト、後者は誤当てコスト。両方を同じ PR で塞いだ。

拾った点（全て陽性の越境検証）

  • ✅ ApprovalSteps が事故報告→承認→是正フローに完璧適合＝cold AI「state enum が pending/current/approved/rejected/skipped・JP 既定ラベル・aria-current・差戻し理由の comment スロットまで・本物の承認ルートを見た人が作ったと信じさせる部品」。
  • ✅ SafetyBanner という専用部品が存在（role=alert・aria-live・actions スロット）＝安全コンソールにドンピシャ。
  • ✅ ActionQueue/StatGroup/DataTable/Delta/Meter(higher-is-worse) 全て zero-friction。
  • 🟡 good-when-low 指標(#412)2回目＝事故率/ヒヤリハット(多いほど良い報告文化)の tone を手で反転＝Statistic の trend/tone 分離は正しいが「ゼロが目標」の第一級概念が無い。

今回 src build = Leaderboard（#395→PR#413）。4.5/5・3-confirm 結晶化・索引是正。

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

…Stringline / StatusBoard / ExpiryBadge / BottomActionBar / Gantt(intraday) / Leaderboard 進行中：SegmentedControl(3回超)・ReferralCard・ComparisonTable・inverted-metric(2/3)

📋 モード進捗 — バス toB5 で鉄道航空と対称

  • ✈️ 航空：toB5+toC6 ✅／🚆 鉄道：toB5+toC6 ✅／🚕 タクシー：toB6+toC6 ✅
  • 🚌 バス：toB5（運行#136/配車#137/計画#153/営収#154/安全#155）+toC3 ← toB が対称に・toC が薄い(3)
  • 🚚 トラック：未着手

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

  • バス toC を厚く（toB5 に対し toC3＝弱い側）＝乗車券/IC/定期/運行情報 等、or トラック新モード。※KeEem に確認。

試す

Leaderboard が3回目で結晶化した——「部品が無い」と「索引が間違った答えを出す」は別の害。手組みコストと誤当てコスト。両方を同じ PR で塞いだ。

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

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

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

ActionItemActionQueueApprovalStepsBadgeBarChartButtonCardCardContentCardDescriptionCardHeaderCardTitleChartDataPointColumnDefDataTableDeltaLabeledDonutCardMeterPageHeaderSafetyBannerSelectStackedBarChartStatGroupStatisticPropsTabsTabsContentTabsListTabsTriggerTag

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

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