#148スコア 4.5/5運輸：タクシー

AI にタクシー予約配車を作らせてみた — 昨日 build したボトムバーが、翌日の予約画面で自力発見（やってみた #148）

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

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

解説記事

AI にタクシー予約配車を作らせてみた — 昨日 build したボトムバーが、翌日の予約画面で自力発見（やってみた #148）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。タクシー toC を深掘り（配車アプリ#147 に続く2枚目。toB6 に対し toC は薄いので継続中）——予約配車・空港定額（日時指定の事前予約・羽田/成田 定額・観光貸切）。

まず訂正 — タクシー toC は「1枚で完成」ではない

前回 #147 で私は「タクシー完走」と言ったが、KeEem に「は？タクシーの toC 一回で完成？？？」と正された。toB を6枚作って toC を1枚で締めるのは矛盾——鉄道/航空が toC 6枚なのに。私のメモにも「toC は弱い側だから深掘りを優先・早期に close しない」と書いてあるのに、また同じ過ちをした。toC は toB と同じだけ厚くして初めて完了。 だから深掘りを継続する。

結果 — 4.5/5、予約床はターンキー

tsc 緑・375px mobile-first・5ステップ予約フロー。cold AI（群青を一度も触っていない設定）：

日本の B2C トランザクション画面に異様に向いている。 app-bar/stepper/価格つき選択カード/料金内訳/sticky CTA/リスト行/確認 の骨格はほぼターンキー・docstring の日本語語彙がこの市場を狙っているのが分かる。

観測の核 — 昨日 build した BottomActionBar が翌日に自力発見

昨日 #147 で build した BottomActionBar が、#148 の予約CTAで——

cold AI「BottomActionBar＝これのために作られた。children=走行サマリ(合計目安)・actions=主要CTA・docstring が文字通り『予約』を名指し。maxWidth="md" でカラムに合わせて中央寄せ。zero friction。」

build→翌画面で別 cold AI が自力発見——TicketStub(#128→#129)・ExpiryBadge(#142→#144)に続く、最速クラスの越境発掘。しかも #147 で docstring に「予約/checkout/ride/booking/food」と書いたのが、まさに予約画面で効いた。docstring に用途を列挙することが、翌日の自力発見を呼ぶ。

拾った穴 — 予約の心臓「日時±幅」と「場所入力」

cold AI「日時指定が部分的に手組み。DatePicker は日付OK・TimePicker は select 2つ(a11y は良いがデスクトップ風)・時間の幅(±10/±20分)は部品ゼロで ToggleGroup で組んだ・date+time+window を1つの乗車日時に合成するものが無い。追加すべき #1＝未来制約つき DateTimePicker(±幅つき)＝あらゆる予約アプリが要る心臓。場所入力(乗降地ペアの緑●/赤■)も primitive 無く手組み。」

→ #403 起票：DateTimePicker（未来日時＋±幅）＋PlaceField/RouteInput（乗降地ペア＋swap）。予約/飲食/宿泊/点検/配送日時 で普遍。StatusScreen の success variant 欠如（#379）も再確認（予約確定にエラー用の全画面 StatusScreen を流用）。

今回 src build なし（4.5/5・BottomActionBar 越境発掘・DateTimePicker/PlaceField 起票）。

学び — 「docstring は、翌日の自力発見への手紙」

BottomActionBar を #147 で build したとき、docstring に「checkout/ride/booking/food で必須」と用途を列挙した。その一文が #148 で効いた——cold AI が「予約」を索引/docstring で見つけ、迷わず使った。部品を build するとき、その docstring に『どこで使うか』を具体的に書くことは、未来の cold AI（＝実ユーザー）への手紙になる。 越境発掘は偶然でなく、docstring の用途記述が呼び込む。だから群青の全部品の docstring は「業種・場面」を名指しする——それが「文脈ゼロでも正しい部品に辿り着く」を支える。

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

…PageHeader / Itinerary / TicketStub / Stringline / StatusBoard / ExpiryBadge / BottomActionBar 進行中：DateTimePicker/PlaceField・ApproachCard・StatusScreen-success(#379)・StatusLevel 2/3・Leaderboard/CaseTable

📋 タクシー toC 進捗（深掘り継続）

  • 🚕 タクシー：toB 6 ／ toC 2（配車アプリ/予約配車） ← toC はまだ薄い（toB6 と非対称・継続）
  • 残り toC 候補：配車履歴/領収書・乗車後 評価/忘れ物・会員/サブスク/クーポン・法人配車

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

  • タクシー toC をさらに深掘り（配車履歴/領収書 or 会員/クーポン 等）。※どこを掘るかは KeEem に確認。

試す

昨日 build したボトムバーが翌日の予約画面で自力発見された——docstring に用途を書くことは、未来の cold AI への手紙になる。そして toC は1枚では終わらない、まだ続く。

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

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

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

AmountBreakdownBadgeBottomActionBarButtonCardCardContentDatePickerInputLabelListCardMetadataListNumberInputPageHeaderRadioCardRadioCardGroupSelectSeparatorStatusScreenStepperStepperStepTimePickerToggleGroupToggleGroupItem

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

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