AI に旅程管理を作らせてみた — 4回さまよった「経路のコンポーネント」が、やっと固まった（やってみた #126）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。⁠航空の利用者向け 深掘り（利用者向けバックログ）⁠——⁠旅程管理／ご旅行プラン⁠（往路便＋ホテル＋現地＋復路便を日程別タイムラインで）。

結果 — 3.5/5、そして「経路のコンポーネント」がついに固まる

tsc 緑・375px mobile-first。予備知識ゼロの AI（群青を一度も触っていない設定）：

⁠PageHeader — これのために作られた。摩擦ゼロ。⁠ docstring に「消費者の各画面に要る上部バー…≥44px…safe-area(ノッチ)」と明記。onBack/actions/align="center" 全部ある。⁠唯一の、本当に利用者向け生まれのコンポーネント。⁠ ⁠だが画面の主役＝日程別の複合タイムラインに専用のコンポーネントが無い。⁠

⁠#125 で作った PageHeader が、その次の #126 で自力発見された⁠（別業界での自力発見がまた1ラウンドで）。

観測の核 — 4回さまよった末の Itinerary のコンポーネント化

連載で「経路/旅程のコンポーネント」は⁠4回さまよった⁠：

• #110 乗換案内の区間経路、#123 国際線の往路/復路の区間、#120/#122 の道案内——全部 RouteStops を⁠配送の語彙のまま流用⁠（未配/配送中/予実）。
• #124 手荷物追跡で⁠初めて RouteStops が正しく嵌まった⁠（状態の追跡）。

そして #126 で予備知識ゼロの AI が言語化：

⁠日程別の複合タイムライン＝手組み。筆頭の欠落。⁠ RouteStops は配送に固定されていて未来の旅程に不適。Timeline は簡素すぎ（種別も日グループも tap も無い）。「⁠TripItinerary/Itinerary コンポーネントが要る——日グループ＋項目ごとの kind→アイコン/トーン＋リッチな内容の差込口＋tap。単一で最大の追加。⁠」

⁠乗換の区間 #110＋国際線の区間 #123＋旅程 #126＝3回⁠＝Itinerary の手組み3回。⁠RouteStops は『状態の追跡』（#124 で確定）、Itinerary は『未来の旅程/経路』——守備範囲が割れた。⁠ その場で作った。

作る — 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[]・項目は 便/ホテル/アクティビティ/区間 の混在・⁠kind ごとの アイコン＋トーンのマーカー＋コネクタ⁠・リッチな内容の差込口・onSelect で ≥44px のタップできる領域。
• ⁠#358 を解決⁠：未来の旅程/乗換経路は Itinerary・ノード中心の状態の追跡（配送/注文/修理/手荷物）は RouteStops——索引も2つに割って、RouteStops への旅程の誤誘導を止めた。
• PR#375・実機375pxで2日セクション＋混在した kind マーカー＋3つのタップできる行＋溢れ0。

⁠今回 src で作ったもの = Itinerary⁠（3回目・⁠10個目⁠のコンポーネント化）。

学び — 「守備範囲が割れて、両方がコンポーネントになる」

RouteStops は4回さまよったが、それは⁠1つのコンポーネントに2つの役割を背負わせていた⁠から——状態の追跡と、未来の旅程。#124 で「状態の追跡は RouteStops」が確定し、#126 で「未来の旅程は Itinerary」が固まった。⁠深掘りは、混同していた2つの役割を割って、それぞれを正しいコンポーネントにする。⁠ これは「欠落を埋める」とも「守備範囲を確定する」とも違う、第3の成果——⁠1つの曖昧なコンポーネントから、2つの明確なコンポーネントが生まれた。⁠ 利用者向けの深掘りで地図がさらに精密になった。

📊 コンポーネント化スコアボード（作成済 ⁠10個⁠）

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / ⁠Itinerary⁠ 進行中：TicketStub 2/3・SegmentedControl・StatusScreen success・Gantt 時刻軸・FlightSegment・下部バー

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

• 利用者向けバックログ残り——航空（ラウンジ・優先サービス）or 鉄道残り（駅ナカ提案＝TicketStub 3回目を会員証/クーポンで / 払戻し）。利用者向けの深掘りがほぼ一巡。

試す

• ⁠gunjo.jp⁠ ／ ⁠旅程 Itinerary⁠ ／ ⁠ページヘッダー PageHeader⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠ ／ 前回まで #1〜#125
• ⁠GunjoUI by UIXHERO⁠

4回さまよった経路のコンポーネントが、守備範囲を割ってやっと固まった——1つの曖昧なコンポーネントから、2つの明確なコンポーネントが生まれた。