AI に旅程管理を作らせてみた — 4回さまよった「経路の部品」が、やっと結晶化した(やってみた #126)
/trip-itinerary375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に旅程管理を作らせてみた — 4回さまよった「経路の部品」が、やっと結晶化した(やってみた #126)
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui(群青)を、文脈ゼロの cold な AI に実 UI で作らせる連載。航空 toC 深掘り(toC バックログ)——旅程管理/ご旅行プラン(往路便+ホテル+現地+復路便を日程別タイムラインで)。
結果 — 3.5/5、そして「経路の部品」がついに結晶化
tsc 緑・375px mobile-first。cold AI(群青を一度も触っていない設定):
PageHeader— これのために作られた。zero friction。 docstring に「消費者の各画面に要る上部バー…≥44px…safe-area(ノッチ)」と明記。onBack/actions/align="center"全部ある。唯一の真に B2C ネイティブな部品。 だが画面の主役=日程別の複合タイムラインに専用部品が無い。
#125 で build した PageHeader が、その次の #126 で自力発見された(越境発掘がまた1ラウンドで)。
観測の核 — 4回さまよった末の Itinerary 結晶化
連載で「経路/旅程の部品」は4回さまよった:
- #110 乗換案内の leg 経路、#123 国際線の往路/復路 leg、#120/#122 の道案内——全部
RouteStopsを配送語彙のまま流用(未配/配送中/予実)。 - #124 手荷物追跡で初めて RouteStops が正しく嵌まった(状態トラッキング)。
そして #126 で cold AI が言語化:
日程別の複合タイムライン=手組み。頭の穴。
RouteStopsは配送 locked で未来の旅程に不適。Timelineは bare すぎ(種別も日グループも tap も無い)。「TripItinerary/Itineraryprimitive が要る——日グループ+項目ごとの kind→アイコン/トーン+リッチ内容スロット+tap。単一最大の追加。」
乗換 leg #110+国際線 leg #123+旅程 #126=3回=Itinerary の手組み3回。RouteStops は『状態トラッキング』(#124 で確定)、Itinerary は『未来の旅程/経路』——定義域が割れた。 その場で build した。
build — Itinerary(旅程)
const days: ItineraryDay[] = [
{ label: "1日目", sublabel: "6月27日(土)・東京 → ホノルル", items: [
{ time: "21:55 発 → 10:25 着(現地)", icon: <IconPlane/>, tone: "primary",
title: "NH182 羽田(HND) → ホノルル(HNL)", description: "往路・所要 約7時間30分・座席 32K",
trailing: <Badge variant="info">往路</Badge>, onSelect: () => openFlight() },
{ time: "チェックイン 15:00", icon: <IconBuildingPavilion/>, tone: "success",
title: "ハイアット リージェンシー ワイキキ", description: "3泊・予約番号 RZ8K4P", onSelect: () => openHotel() },
]},
]
<Itinerary days={days} /> // or flat: <Itinerary items={...} />
days[](日見出し+場所サブ+項目)or フラットitems[]・項目は便/ホテル/アクティビティ/leg 混在・kind ごとの アイコン+トーン マーカー+connector・リッチ内容スロット・onSelectで ≥44px tappable。- #358 を解決:未来の旅程/乗換経路は Itinerary・ノード中心の状態トラッキング(配送/注文/修理/手荷物)は RouteStops——索引も2つに割って RouteStops への旅程誤誘導を止めた。
- PR#375・実機375pxで2日セクション+混在 kind マーカー+3 tappable 行+0 overflow。
今回 src build = Itinerary(3-confirm・10個目の結晶化)。
学び — 「定義域が割れて、両方が部品になる」
RouteStops は4回さまよったが、それは1つの部品に2つの役割を背負わせていたから——状態トラッキングと未来の旅程。#124 で「状態トラッキングは RouteStops」が確定し、#126 で「未来の旅程は Itinerary」が結晶化した。深掘りは、混同していた2つの役割を割って、それぞれを正しい部品にする。 これは「穴を埋める」とも「定義域を確定する」とも違う、第3の成果——1つの曖昧な部品から、2つの明確な部品が生まれた。 toC 深掘りで地図がさらに精密になった。
📊 結晶化スコアボード(build 済 10個)
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary 進行中:TicketStub 2/3・SegmentedControl・StatusScreen success・Gantt hour-axis・FlightSegment・bottom-bar
次回予告(やってみた #127)
- toC バックログ残り——航空(ラウンジ・優先サービス)or 鉄道残り(駅ナカ提案=TicketStub 3回目を会員証/クーポンで / 払戻し)。toC 深掘りがほぼ一巡。
試す
- gunjo.jp / 旅程 Itinerary / ページヘッダー PageHeader / npm
@gunjo/ui/ GitHub / 前回まで #1〜#125 - GunjoUI by UIXHERO
4回さまよった経路の部品が、定義域を割ってやっと結晶化——1つの曖昧な部品から、2つの明確な部品が生まれた。
<!-- 公開前: 相互URL差込/スクショ確定/EN(dev.to)ミラー -->
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import している部品です。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。