家族旅行アーカイブの行程ガントを実日程に合わせて大幅更新した話

夏の家族旅行（九州のある県、妻と子ども3人の5名）の行程を、自前のAstro製アーカイブ（localhost:4321）にひたすら流し込んだ一日。最初は2泊ぶんを足すだけのつもりが、便の変更や宿の制約が次々に出てきて、開始日を前倒し・終了日を延長・宿泊ブロックの統一・CSSの拡張・宿候補の探索まで芋づる式に広がった。「ガントの数値とスクリーンショットを見て自分が違和感を拾う係、編集を回すのはClaude Code係」という分担で進めた記録を残しておく。

ガント（タイムライン）に宿泊と移動を反映していく

このアーカイブは旅行ごとにMarkdownのfrontmatterで startDate / endDate / timeline を持ち、ページ側でガント（縦に日付、横にレーン）を描画する作りになっている。まずは高原エリアのキャンプ場2泊と、そこからテーマパークへの移動ルート（約1.5時間、休憩込み2時間）を timeline に追加させた。

ここで最初の気づき。timeline のスキーマに link フィールドが無く、Googleマップのルートリンクをそのまま持たせられない。表示側で note がどう描画されるかを先に確認させてから、ルートはメモ欄にリンクを埋め込む形に落とした。

既存データとの衝突もこのとき拾った。同じ夜に「実家泊」とキャンプ場泊が二重に入っていたので、キャンプ場を入れるぶん実家泊を置き換える、と判断。地名・施設名の表記ゆれ（自分が口頭で言った施設名と、地図URL上の正式名が違った）もここで正した。

開始日を前倒し、終了日を延長してカレンダーを縦に伸ばす

「終了日をもう少し後ろに伸ばしたい」という要望から、endDate を後ろにずらした。ここでガント描画ロジック（buildDays と日数計算）を先に確認させたのが効いた。日数が増えると 背景行のCSS（nth-child）が10日ぶんまでしか定義されておらず、それを超えた日の背景が崩れる と事前に分かったからだ。

/* 10日目までしか背景ストライプが無く、11日目以降が抜ける */
.gantt-bg-row:nth-child(n) { /* ...10まで... */ }

必要日数ぶんに nth-child を拡張して崩れを潰した。さらに後段で往路を前倒しして開始日も延ばしたため、最終的に表示は12日ぶんになり、背景行の高さ（1056px）まで数値で確認させて整合を取った。日数が変わるたびに「何日表示になるはず」を先に宣言してからリロードで答え合わせする、という進め方が安全だった。

宿泊ブロックを「18:00〜翌09:00」の均一幅に統一する

当初、実家泊が複数日にまたがる1本の長いバーになっていて、ガントが間延びして見えた。これを 毎晩「18:00〜翌09:00」の均一ブロック に分割するよう揃えた。実家泊だけでなく、キャンプ場2泊・高原のホテル・大型温泉ホテルも、すべて同じ幅のブロックに統一。夜のエリアだけを示し、横に広げない、というルールに寄せたら一気に見やすくなった。

# Before: 実家泊が5日ぶん1本の帯（間延び）
実家泊  ████████████████████  8/26〜8/30

# After: 1泊=1ブロックに分割（18:00〜翌09:00）で揃える
実家泊  ▓ ▓ ▓ ▓ ▓   各夜ごとに独立

便変更とレンタカー再見積を予算と予約テーブルに反映する

航空券（地方系LCC）とレンタカーが、行程の前後延長で再予約・再見積になった。ここは便名が1つ変わると連動する箇所が多く、何度もリロードで答え合わせした。

往路を前倒し、復路は同時刻のまま日付を後ろへ。便名が変わるたびに、空港→キャンプ場の移動時刻、レンタカーの受取・返却、最終日の空港戻りルートまで連動させた
レンタカーは当初7日 90,750円 → 約10日 119,445円（+28,695円、1日あたり約9,500円増）。確定値なので料金内訳テーブルとfrontmatterの予算（移動費・合計）を更新
航空券が確定したタイミングで、総額・座席数（5席）まで反映。予算は移動費 232,662円（航空券113,217＋レンタカー119,445）、合計 462,662円で整合を取った
便が確定する前は「変更予定（点線バー）」、確定後は「確定（実線バー）」とステータスを切り替え。frontmatterの予算と本文の予約テーブルの両方を、毎回そろえて直した

各編集のたびにdev serverのリロードでスキーマ検証（/trips/... が200を返すか＝frontmatter検証パス）を確認し、ガント配置を数値とスクリーンショットの両方で検証する、というループを徹底した。@astrojs/check の追加インストールを促されたが、それは入れず、dev serverのログとリロード結果で代替した。型チェックのためだけに依存を増やすより、すでに動いているdev serverの200応答とログを信じるほうが軽い。

ついでに「保有マイルがこの航空会社で使えるのか」という素朴な疑問も湧いたので調べさせた。記憶で答えると間違えやすい領域なので、公式情報で裏取りさせたうえで「独自マイルはあるが、今回の運賃区分では貯まり方が控えめで、この旅行ぶんだけで特典航空券にするのは現実的でない」と結論まで出してもらった。旅程の数字を詰めるついでに、こういう周辺の疑問もその場で潰せるのがアーカイブをコードで持っている強み。

ついでにSSOT化のリファクタ：参加者を家族マスタから導出

旅行一覧ページの「参加者」列が古い手入力データ（仮の名前）のままで、詳細ページの家族メンバー欄（src/lib/family 由来の正しい5名）と食い違っていた。二重管理になっていたので、Single Source of Truthに寄せるリファクタをかけた。

frontmatterの手入力 members（自由記述の名前）を廃止
代わりに任意の participants（家族マスタのrole参照、省略時は全員）に変更
一覧ページ・詳細ページの両方を、家族マスタから参加者を導出するよう書き換え

両ページを開いて、一覧の参加者列と詳細の家族欄が一致し、エラーが出ないことを確認した。画面の数字の食い違いに気づいたら、源泉を1本にまとめるところまで持っていく、という小さな掃除。

#	テーマ	試したこと	結果	気づき
1	ルートリンク	`timeline` に `link` を持たせようとした	失敗（スキーマに無い）	`note` 欄にリンクを埋める形へ。表示側を先に読んでおくと回避できた
2	カレンダー延長	`endDate` を後ろにずらす	部分的に崩れる懸念	背景行CSSが10日ぶんしか無いと先に判明。日数を変える前に描画ロジックを読む
3	背景行CSS	`nth-child` を必要日数ぶんに拡張	成功	12日表示でも背景の高さ1056pxまで数値確認して整合
4	宿泊バー	長い1本帯を「18:00〜翌09:00」の均一ブロックに分割	成功	幅を揃えるだけで間延びが消えた
5	便・予算連動	便変更→移動時刻・レンタカー・予算を芋づるで更新	成功	1箇所直すと3〜4箇所に波及。毎回リロードで答え合わせ
6	参加者の二重管理	手入力 `members` を廃し家族マスタから導出	成功	一覧と詳細の食い違いで気づき、SSOTに寄せた
7	宿の口コミ取得	WebFetchで口コミサイトのページネーション取得	失敗（`f_page` が効かず上位中心）	agent-browser（ログイン済みChrome）で全文取得に切り替え

今日の学び

日数が変わるUIは「背景の繰り返し定義」が落とし穴。ガントの nth-child が固定数までしか無いと、日数を伸ばした瞬間に静かに崩れる。日数を変える前に描画ロジックを読んで上限を確認しておくと事故らない
時間ブロックは幅を揃えるだけで見やすさが激変する。宿泊を均一の「18:00〜翌09:00」に揃えただけで、間延びしていたガントが一気に締まった
frontmatterの数値とリロード結果を毎回突き合わせるのが安全。便名・時刻・予算は連動する箇所が多く、1つ直すと3〜4箇所に波及する。リロードで200（スキーマ検証パス）＋数値＋スクショの3点確認をループにした
二重管理は画面の食い違いで露見する。一覧と詳細で参加者が違って初めて気づいた。気づいたらSSOTに寄せるところまでやる
WebFetchが詰まったらagent-browserに即フォールバック。ページネーションが効かない口コミサイトでも、ログイン済みChrome経由なら全文が取れた

明日やること

初日（未定）の宿を、遅着OKの候補から1つに絞って予約する
確定した宿が決まったら、ガントの点線（未定）を実線（確定）に切り替える
残りの宿候補の口コミメモも、同じ要領でagent-browser経由で網羅しておく