AI にタクシーの苦情・事故管理を作らせてみた — 型は通るのに無視される「嘘の prop」を見つけた回（やってみた #145）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。タクシー toB をもう1枚（配車・乗務員・営収・車両管理に続く5枚目）——苦情・事故・安全管理（苦情/事故のケース管理・対応フロー・無事故KPI・報告書確認）。

結果 — 4.5/5、ケース管理という別系統も床に乗った

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

back-office のケース console として、群青は適応でなく purpose-built。 最難関の2つ——ケースのライフサイクルフローと lock-after-sign の報告書——が、それぞれ専用部品で near-zero friction に乗った。

これまでタクシー toB は 配車(ops)・乗務員(crew/点呼)・営収(analytics)・車両(保守) を見てきたが、#145 はケース/インシデント管理＝サポートデスク的なライフサイクルという別系統。結果は：

観測の核1 — ケースライフサイクルは ApprovalWorkflow が適合

受付→事実確認/調査→対応(乗務員指導/謝罪/賠償)→再発防止→完了 のフローを——

cold AI「ApprovalWorkflow が完璧に嵌まった・手組みゼロ。docstring が文字通り『case management, benefit/application screening, ringi/expense approval … any staged back-office review』＝case management を筆頭に名指し。controlled value/onChange・差戻し(理由つきで前段に戻し record rollback)・却下(terminal)・各段に actor/time/comment＝サポートデスク/苦情ワークフローの定義そのもの。RouteStops/Stepper/Timeline は段ごとの actor/timestamp/comment や advance/sendback/reject を持たず不適。」

承認ワークフロー部品が、稟議だけでなく『ケースのライフサイクル全般』に効く＝ApprovalWorkflow の定義域が苦情/事故対応にも届いた。RouteStops(状態追跡)・ApprovalWorkflow(差戻しありの段階レビュー) の住み分けが、また一つ確定。

観測の核2 — 「型は通るのに silently 無視される prop」＝嘘の prop を発見

cold AI が実バグを踏んだ：

「ActionDataTable の getRowState は罠。継承(Omit)で型に在るので type-check は通るが、コンポーネントは {...props} を spread した直後に自分の selection ロジックで getRowState を hard-override する。私の getRowState={row => row.id===selectedId ? 'selected'} は綺麗にコンパイルされ、実行時に黙って何もしなかった。docs/types の嘘。tsc だけの検証では絶対に surface しない。」

→ 即修正 PR#398：呼び出し側の getRowState を destructure して compose——選択行は "selected"(選択ハイライト優先)、それ以外は呼び出し側の getRowState にフォールバック。danger/warning の行 tint が selection と共存。browser で regression 検証（選択で data-state=selected が 0→1）。

これは越境発掘や穴とは違う、第4の cold-test 成果＝『嘘の型表面』の発見。 部品が prop を「受け取れる」と型で言いながら実行時に捨てる——cold AI が実際に渡して初めて露見する。tsc 緑・design:verify 緑でも残る欠陥を、実使用が炙り出した。

学び — 「cold-test は4種類の欠陥を炙り出す」

やってみたループが見つけてきた欠陥を整理すると4種類：

1. 穴（部品が無い）→ 3-confirm で build（14個）。
2. 誤誘導（索引が間違った部品に誘導）→ 索引是正（多数）。
3. 越境の浅さ（部品が adequate-not-native）→ legs[] 等の深掘り（#358）。
4. 嘘の型表面（prop が型に在るのに実行時 silently 無視）→ #145 ActionDataTable getRowState。

①②③は「文脈ゼロで作らせる」から出る。だが④は**「実際に prop を渡して動かす」から出る**——型と docs を信じた文脈ゼロ開発者が、コンパイル成功・無反応という最も気付きにくい形で踏む。cold-test の価値は「網羅的に作る」だけでなく「信じて使う」ことにある。

拾った点

• 🟡 CaseTable/IncidentRow preset：ケースのライフサイクル(ApprovalWorkflow)は first-class だが、それを供給する案件一覧は DIY(種別/状態/優先度/担当 列を毎回手組み)＝#399（Leaderboard #395 と同類＝「DataTable preset を毎回手組みさせる」）。派生値ソート・Meter.direction/Statistic の trend≠tone の型ガイド不足も併記。

今回 src 変更 = ActionDataTable バグ修正（4.5/5・嘘の型表面を honor に）。

📊 結晶化スコアボード（build 済 14個・shipped 修正多数）

…Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge 進行中：DesktopPageHeader 4回目・CaseTable/Leaderboard(DataTable preset 系)・BottomActionBar 3/3・StatusLevel 2/3

📋 タクシー進捗

• 🚕 タクシー：toB 5枚（配車/乗務員/営収/車両管理/苦情事故） ／ toC 0枚

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

• タクシーを締めるなら残りは toC（配車アプリ）。or タクシー toB はこれで十分なら次の判断へ。※勝手に進めず KeEem に確認する。

試す

• gunjo.jp ／ 承認ワークフロー ApprovalWorkflow ／ データテーブル ActionDataTable ／ 署名記録 SignedRecord ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#144
• GunjoUI by UIXHERO

型は通るのに実行時に無視される「嘘の prop」を、文脈ゼロ AI が実際に渡して炙り出した——cold-test の価値は網羅でなく「信じて使う」ことにある。

---

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