聞く・調べる・提案する
家族の条件と希望を整理。公式サイトや交通情報の本文を確認し、残った候補の良さと見送る理由を説明します。
家族の希望を聞き、今の公式情報を調べ、候補を比べ、無理のない計画を作る。誰が判断し、何が検査され、何が手元に残るのか。2つの架空家族で、旅の支度を最初からたどれます。
希望を形にする対話、入力の整合を守るコード、家族が実際に使う画面を分けています。
家族の条件と希望を整理。公式サイトや交通情報の本文を確認し、残った候補の良さと見送る理由を説明します。
片道上限、年齢、予算、休憩、時間帯、出典期限を検査。選定と承認の内容をハッシュで固定します。
承認済みの情報から、楽しみ・準備・当日の3導線を制作。HTMLの見た目と操作は別に検品します。
2種類のゲート: G1〜G6 はスキルそのものの開発・配布を確認した品質ゲート。この図の「選定」「計画承認」は、旅行ごとに家族が行う判断です。ソフトウェアの完成が、個別の旅の承認を代行することはありません。
各段階を押すと、誰が何を決めるかと出力が見えます。色の帯は、人の判断・ハーネスの検査・制作を示します。
AIは候補を調べて提案できます。家族の選定・承認、公式情報の対象日確認、出荷判断には人の確認が残ります。
スマートフォンでは表を左右に動かして読めます。
出典の確認日だけを更新した場合と、旅程や費用を変えた場合では影響が違います。ハッシュは変更検出であり、本人確認の仕組みではありません。
intake条件・根拠を整理中no_eligible_candidates条件に合う候補なしawaiting_selection家族の選定待ちplanning詳細計画を修正中awaiting_plan_approval計画承認待ちapproved承認版の検査が通るハーネスが検査できるのは入力の整合と根拠の状態です。公式サイトの本文が正しく読まれたか、交通が実際に動くか、予約できるかは調査と出発前の再確認が必要です。
入力の正本と、家族に渡す出力を混ぜない。完成済みのHTMLにも、元になった版と検査記録を残します。
CASE/trip.json条件、根拠、候補、選定、詳細計画、承認を保持。実家族なら個人情報は `private.json` へ分けます。
check / status候補や計画の条件違反と現在状態を表示。該当候補がない状態も正常な結果です。
export → trip-public.json承認済みの旅程・準備・予算・出典を抽出。family と public で公開範囲を変えます。
index.html + build-record.jsonしおり、準備メモ、制作指示とファイルハッシュを出力。`verify-export` は版の一致を確認します。
家族像と選定・承認は説明のための仮定です。施設・交通の記載は各ケースの調査記録へたどれます。実旅行への転用時は対象日・空き・料金を調べ直します。
両家族の居住地は架空の横浜・福岡。移動上限の検証起点は横浜駅・博多駅で、自宅から駅までの時間は含みません。


移動は駅から施設までの計画上の見積り。家族・希望・選定・承認はデモ用の仮定です。
ハーネス実測:横浜2候補、福岡2候補が選定可能。両方の詳細計画と模擬承認後の出力整合を確認。福岡のマリンワールドは対象日の根拠を調査していないため除外しました。出発前には営業・運行・料金・体験枠を再確認します。
架空デモを実在の旅行保証に見せないため、ケースごとの確認記録と限界を分けて置きます。
毎回すべてを高コストのモデルに渡さず、作業を小さく分けています。モデルの実費は呼び出し環境に依存するため、ここでは役割を示します。