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

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠タクシーの事業者向けをもう1枚⁠（配車・乗務員・営収・車両管理に続く5枚目）——⁠苦情・事故・安全管理⁠（苦情/事故のケース管理・対応フロー・無事故KPI・報告書確認）。

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

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

⁠事務方のケース管理コンソールとして、群青は適応でなく用途向けに作られている。⁠ 最難関の2つ——ケースのライフサイクルのフローと 署名後にロックする報告書——が、それぞれ専用のコンポーネントでほぼ摩擦ゼロに乗った。

これまでタクシーの事業者向けは 配車(運用)・乗務員(点呼)・営収(分析)・車両(保守) を見てきたが、#145 は⁠ケース/事故の管理＝サポートデスク的なライフサイクル⁠という別系統。結果は：

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

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

予備知識ゼロの AI「⁠ApprovalWorkflow が完璧に嵌まった・手組みゼロ。docstring が文字通り『ケース管理、給付/申請の審査、稟議/経費の承認 … あらゆる段階的な事務方の審査』＝ケース管理を筆頭に名指し。controlled value/onChange・差戻し(理由つきで前段に戻し、記録をロールバック)・却下(terminal)・各段に 実行者/時刻/コメント＝サポートデスク/苦情ワークフローの定義そのもの。RouteStops/Stepper/Timeline は段ごとの 実行者/時刻/コメント や 次へ/差戻し/却下 を持たず不適。⁠」

⁠承認ワークフローのコンポーネントが、稟議だけでなく『ケースのライフサイクル全般』に効く⁠＝ApprovalWorkflow の守備範囲が苦情/事故対応にも届いた。RouteStops(状態の追跡)・ApprovalWorkflow(差戻しありの段階審査) の住み分けが、また一つ確定。

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

予備知識ゼロの AI が⁠実バグ⁠を踏んだ：

「⁠ActionDataTable の getRowState は罠。継承(Omit)で型に在るので型チェックは通るが、コンポーネントは {...props} を spread した直後に、自分の選択ロジックで getRowState を強制的に上書きする。自分の getRowState={row => row.id===selectedId ? 'selected'} は綺麗にコンパイルされ、実行時に黙って何もしなかった。docs/型の嘘。tsc だけの検証では絶対に表面化しない。⁠」

→ ⁠即修正 PR#398⁠：呼び出し側の getRowState を分解して ⁠組み合わせる⁠——選択行は "selected"(選択ハイライトを優先)、それ以外は呼び出し側の getRowState にフォールバック。danger/warning の行の色付けが選択と共存。ブラウザで再発の検証（選択で data-state=selected が 0→1）。

⁠これは別業界での自力発見や欠落とは違う、第4の成果＝『嘘の型』の発見。⁠ コンポーネントが prop を「受け取れる」と型で言いながら実行時に捨てる——予備知識ゼロの AI が実際に渡して初めて露見する。tsc 緑・design:verify 緑でも残る欠陥を、⁠実使用が炙り出した。⁠

学び — 「予備知識ゼロのテストは4種類の欠陥を炙り出す」

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

1. ⁠欠落⁠（コンポーネントが無い）→ 3回ルールで作る（14個）。
2. ⁠誤誘導⁠（索引が間違ったコンポーネントに誘導）→ 索引の是正（多数）。
3. ⁠業界越えの浅さ⁠（コンポーネントが十分だが専用でない）→ legs[] 等の深掘り（#358）。
4. ⁠嘘の型⁠（prop が型に在るのに実行時に黙って無視）→ #145 ActionDataTable getRowState。

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

拾った点

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

⁠今回 src 変更 = ActionDataTable のバグ修正⁠（4.5/5・嘘の型を、ちゃんと効くように）。

📊 コンポーネント化スコアボード（作成済 ⁠14個⁠・出荷済み修正多数）

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

📋 タクシー進捗

• 🚕 ⁠タクシー：事業者向け 5枚（配車/乗務員/営収/車両管理/苦情事故）⁠ ／ 利用者向け 0枚

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

• タクシーを締めるなら残りは ⁠利用者向け（配車アプリ）⁠。or タクシーの事業者向けはこれで十分なら次の判断へ。⁠※どれに進むかは、次回までに決める。⁠

試す

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

型は通るのに実行時に無視される「嘘の prop」を、予備知識ゼロの AI が実際に渡して炙り出した——予備知識ゼロで作らせるテストの価値は網羅でなく「信じて使う」ことにある。