深度旅行攻略制作法は何をしますか？

ワークフロー

順番通りに実行すること。順番を飛ばすと、後日になってツケが一気に回ってくる。

事前分岐：目的地未確定

ユーザーが「10月にどこに行こう？」のような質問だけをしてきた場合、いきなり日々の旅程を組み始めない。第0.5歩の旅行スタイルに従い、3つの候補地を提示し、それぞれについて以下の具体的な取捨選択を記述する：現地の季節と天候リスク、予算規模、ユーザーのパスポートに基づくビザ取得難易度（ただし、最終判断は断言せず、公式確認先を明記すること）、飛行時間／乗り継ぎの負担。ユーザーが目的地を選んだ後、第0歩に進む。

第0歩：まずハード制約を確定させる

すでに支払い済み、予約済みのものは「土台」であり「変数」ではない。 まずそれらを確認し、最上部に明記する：

予約済みの宿泊施設（住所、チェックイン／チェックアウト時刻、キャンセル期限、最終価格）
予約済みまたは確定済みの交通機関（フライト時刻、到着／出発の正確な時刻）
同行人数、明確に「必ず行きたい」場所と「興味がない」場所
選択肢に影響を与える身体的条件の有無（身長、足腰の状態、タトゥー、食事制限、乗り物酔い、小さな子供連れ、高齢者連れ）——これらが、多くの選択肢の可否を静かに決定する。

まず ${CLAUDE_SKILL_DIR}/scripts/trip_dates.py <国/地域コード> <開始日> <終了日> を実行すること。曜日を暗算で求めない。 スクリプトはネットワーク時刻検証を通過後、各日の曜日、祝日、連休を出力する。スクリプトがない、実行できない、または時刻チェックに失敗した場合、日付関連の計画を直ちに中止する：ユーザーに対して、日付が未検証であることを明確に伝え、完全なスキルディレクトリ（scripts/ を含む）のインストール、または検証可能なカレンダーの提供を要求する。決して暗算で代用しない。その上で、ユーザーから与えられた日付が過ぎていないか、曜日が彼らの言及した予定と合っているか（「週末に〇〇に行く」と言っているのに実際は水曜日）、確認する。ずれを発見したら、まずユーザーに質問してから作業を進める——誤った年で旅程を丸ごと作り直すことになる。

「基点」を決める。 各日のルートは、固定された出発点から展開する：都市旅行では、通常は宿泊施設の最寄り駅。ドライブ旅行では、宿泊施設そのもの（および駐車条件）。複数都市の旅行では、各セグメントごとに異なる基点を持つ。基点が決まれば、旅程の効率はほぼ決まる。

ユーザーがまだ宿泊施設を予約していない場合は、先に「宿泊施設の意思決定」（references/lodging-decisions.md 参照）を行う。後のすべての動線がそれに依存するため。

第0.5歩：旅行スタイルを聞き出し、好みを数値化する

この工程が、後続のすべての「閾値」を決定する。これを飛ばすと、自分のデフォルトの好みをユーザーの好みとして書き込んでしまうことになる。

同じ旅行でも、ミシュランを食べ尽くしたいカップルと、ただショッピングを楽しみたい友人グループとでは、全く異なる旅程になるべき。だから、まず質問する（またはユーザーの発言から推測し、推測できない場合は直接聞く）：

聞くべきこと	それが決めるもの
ペース：1日に何ヶ所行きたい？早起きはできる？	1日の行程数、バッファの量
食事の位置づけ：食事は旅行の主軸か、それとも補給か？	正式な食事の回数、レストランの予約に動線を縛るかどうか
待ち時間の許容度：行きたいお店に、最大どれだけ並べる？	待ち時間の上限値
買い物の比重：大量に買うのか、ざっと見るだけか？	予算の弾力性、手荷物許容量、免税手続きを重点的に書くかどうか
予算姿勢：節約重視、体験重視、それともあまり気にしない？	時間をお金で買うべき場面
確実性の好み：すべて予約済みが好きか、余白を残すのが好きか？	予約の数、候補として残す店の数

答えを具体的な数字に落として旅程に書き込むこと。形容詞のままにしない。「並ぶのが嫌い」は「待ち時間がX分を超えたら次の店に行く」に。「何か美味しいものを食べたい」は「予約が必要な正餐をN回、残りは日常的な価格帯の食事」に。

ユーザーが表明しなかった項目は、最も手間のかからないデフォルト値を使用し、その前提を説明する。 そうすれば、ユーザーは一目で否定できる。

第1歩：優先日と振替ルールを決める

旅程には、天候や季節に左右される項目が常にいくつかある（山岳展望、海辺散策、紅葉・桜鑑賞、屋外展望台、屋外撮影など）。それぞれに優先日を指定し、同時にどの日と振り替え可能かを明記する。

優先日は、週末や現地の連休を避け、平日を優先する。振替ルールは実行可能な文章で書く。「天候を見て決める」ではなく、「11/16の夜に最初の判断、11/17の夜に最終決定、先に切符の変更を処理する」のように。

第2歩：日ごとに旅程を組み、同時に削減階層を書き込む

各日について、時刻 → アクションの表を作成し、以下の3点を追加する：

非効率を避けた順序——地図上で確認すること。住所を読んで想像してはいけない。同じエリアは一気に回る。
絶対に外せない項目 / すべて削除可能な項目——毎日、明確にマークする。体力や天候で必ず何かが削られる。事前に何を犠牲にするか決めておく方が、当日に考えるより良い。
天候代替案——1日1つ。目的地の実際の天候リスクに基づく（雨、雪、猛暑、強風、台風シーズンなど）。「雨なら屋内に変更」ではなく、具体的に何に変更するかを書く。

旅程に隠れたコスト：乗り換え時間、出口を探す時間、ショッピングモールで店を探す時間、駐車場を探す時間。毎日、割り当てられないバッファを1ブロック確保する。 その長さは、ユーザーのペースの好みに応じて決める。詰め込む人は少なめに（ただし連鎖的な遅延リスクを受け入れる）、ゆったりしたい人は多めに。バッファがないと、最初の遅延が夜まで連鎖する。

到着日と出発日には、ハードな予定を入れない。 到着日には、キャンセル不可の正餐予約や、分刻みのゴールデンタイム、唯一の絶対的行き先をフライト着陸後に設定しない。荷物、入国、遅延、時差ボケからの回復をバッファに織り込む。時差がある場合、初日の夜は軽い散歩、食事、早めの就寝を優先し、その後2日間かけて通常ペースに戻す。出発日も同様に、航空会社、空港、交通機関の当該要件に基づいて出発時刻を逆算し、それより前にはいつでも削除できるアクティビティのみ配置する。免税手続き、レンタカー返却、荷物預け、最後の買い物などを「ついでにできる」と考えない。

第3歩：店ごとに検証する（この工程が最もおろそかにされやすく、最も価値がある）

「営業中」を確認するだけでは不十分。確認すべきは、「計画している日は何曜日で、その曜日に営業しているか、計画している到着時刻が営業時間内に収まっているか」である。

完全な方法は references/verification.md 参照。最低限必須のセット：

各店舗について、計画日の曜日と照らし合わせて営業時間と定休日を確認する
旅行期間中の現地の祝日と連休を確認する——連休は駅、観光地、コインロッカー、空港の混雑度を同時に高める
旅行期間中に制度変更が発効していないか確認する（免税、ビザ、入国手続き、チケットルールなど）
季節限定の見頃／開園期間があなたの日程をカバーしているか確認する。「その季節に行けばある」と決めつけない
現地の特別な日が旅程に含まれていないか確認する（祭り、記念日、新学期、大規模な展示会など）

第4歩：交通機関をセグメントごとに確定する

基点から出発し、各日の往路と復路を確定する。公共交通機関は、「路線＋乗り換え駅＋所要時間＋運賃」の形式で。ドライブは、「ルート＋走行時間＋駐車＋料金」の形式で。

詳細は references/transit-and-maps.md 参照。共通原則：各セグメントを書き終えたら、「土地勘のない人がこの一文で正しく移動できるか？」と自問すること——「地下鉄で便利」では不合格。「X線各停直通Y駅、20分、乗り換え0回、急行は停車しないので、乗車前に車両前面表示を確認」で合格。

チケットの判断基準：デフォルトは都度払い。ただし元が取れる日／セグメントに限り、パスを購入することを提案し、その計算式をユーザーに示す。

第5歩：地図への落とし込み

旅程がドキュメントの中だけで完結してはいけない。references/transit-and-maps.mdの「地図の3層法」を参照。核心：カスタムマップはオフラインでもナビゲーションもできないため、現地では別の2層の連携が必要。

第6歩：予算

「自国通貨での直接支出」と「目的地通貨での支出」の2ブロックに分け、最後に合算する。詳細は references/budget-and-customs.md 参照。

重要なのは、唯一上限がない項目（通常は買い物）を特定し、それに3つの段階を設定し、ユーザーにハードリミットを設定してスマートフォンに書き留めるよう提案すること。

第7歩：カウントダウン表

すべてのハードデートを1つの表にまとめ、時間順に並べる：チケット発売開始日、無料キャンセル期限、予約受付期間、アカウント登録締切、再確認期限。

特に、同じ日に重なる2つのイベントに注意する——例えばキャンセル期限とチケット発売日が同じ日など。重なりを指摘する。

第8歩：納品前の自己チェック

第0歩のハード制約表と第0.5歩で決めた嗜好数値を逐次見直し、各日がそれらに違反していないか確認する。その後、「既存の旅程をレビューする」ための7つのチェック項目を、自分が書いたばかりの成果物に適用する：内部矛盾、遠回り、逆算、検証漏れ、空白、リスク日の代替案、期待のズレ。

納品物の末尾に、今回の自己チェック結果を残す。 黙ってチェックしてはいけない。ユーザーは、どのハード制約が満たされ、どの情報がまだ出発前の再確認事項としてマークされているかを知る必要がある。

全行程にわたる意思決定ルール

これらのルールの役割は、「その時になって決める」を「その時になったらこのルールに従って実行する」に変換することです。

⚠ 営業時間、定休日、価格と運賃、走行時間と乗り換え回数、予約ルールと受付時間、祝日、季節の窓の実際の予測期間、バリアフリー情報とスロープ・段差の実態については、今回の調査で確認した出典が必要です。トレーニングデータ内で「記憶している」値はすべて期限切れとみなす：これらのフィールドは常に変更される可能性があり、モデルは自分が何年のデータを覚えているかを認識していない。出典が書けないなら、その数字を書いてはいけない。代わりに「出発のX日前に再確認」と書き、どこで再確認するかを明記する。正直な空白は、誤った自信のある数字よりも有用です。

⚠ 以下に挙げるすべての数字はプレースホルダーであり、推奨値ではありません。 これらは第0.5歩で確認したユーザーの嗜好に基づく必要があります。他人の嗜好をデフォルト値として旅程に書き込むことは、このスキルが最も犯しやすい間違いです。

具体的な待ち時間、候補数、正餐、予約、逆算、時間をお金で買う判断、A/Bテストのクローズ閾値、情報源の役割分担については、references/decision-thresholds.md を参照。旅程を組み始めるか、選択肢の結論を出す前に必読すること。別ファイルに分けているのは入り口ファイルを軽くするためであり、ルールを緩和するためではありません。

出力形式

デフォルトでは Markdown形式の旅程ドキュメント を出力します。ユーザーが別の形式を指定した場合を除く。出力の骨格、日次テンプレート、カウントダウン表、荷物生成法、緊急時対応カードは assets/planning-templates.md にあります。旅程の重点に応じて追加・削除し、テンプレートを埋めるために虚偽の情報を作成してはいけません。

よくある調整：食事が主軸の場合は、別途飲食店候補リストを作成する。買い物が主軸の場合は、価格比較、免税手続き、手荷物許容量に重点を置く。ドライブの場合は、区間、駐車、給油、道路状況、オフラインナビゲーションに書き換える。複数都市の場合は、都市ごとにセクションを分ける。小さな子供連れや高齢者連れの場合は、毎日最寄りの休憩ポイントを追加し、全体的にペースを落とす。

結論を先に、理由を後に。 各提案には実行条件を付ける。不明確な点は、再確認する時期と場所を明記する。既存の旅程を修正する場合は、元のファイルを直接編集し、並行して別のドキュメントを作成しない。

既存の旅程をレビューする場合

ユーザーが既存の旅程を持ち込んで「問題はないか？」と尋ねてきた場合、以下の順序で確認する。効果の高い順：

内部矛盾——同じ日の2つの時間が合わない（「14:30～15:00にA通りを歩く」と「14:40にBに到着しなければならない」）
遠回り——より短い乗り換えルートがあるのに、長いルートを書いている
逆算が成立しない——書かれた出発時刻では、設定されたゴールデンタイムに間に合わない
検証漏れ——曜日を確認していない、連休を調べていない、制度変更を確認していない
空白——2つの予定の間に不自然に50分の空きがある
リスク日の代替案がない——特に到着日と出発日
期待のズレ——ユーザーが見えると思っているものが、実際の季節や時間と合致しない
明らかな過密または自己矛盾——例えば10日間で12都市を巡るなど。なぜ実行不可能かを明確に指摘し、具体的な代替案を示した上で、ユーザーの決定に従って続行する。ただ警告するだけで、ブロックしたり、再確認を求めたり、繰り返し説得したりしない。

問題を指摘する際は、代替案も提示すること。「ここに問題があります」だけでは不十分。 そして、問題リストをユーザーに渡して自分で修正させるのではなく、直接元のドキュメントを修正すること。

参照ファイル

必要なときに読む。一度に全部読む必要はない：

references/verification.md — 店舗ごとの検証、祝日と連休、制度変更、季節の窓に対する期待値管理、ゴールデンタイムの逆算、ソーシャルメディアの使い方と限界。第3歩で必読。
references/transit-and-maps.md — 基点を中心とした交通機関の記述方法、公共交通機関の5つの落とし穴、ドライブの要点、パス購入の計算、現地の地図ツール、地図の3層法。第4、5歩で必読。
references/lodging-decisions.md — 税込み最終価格の横比較、部屋替えの判断基準、プラットフォームの設備説明の落とし穴、立地と動線の関係。ユーザーが「このホテルは良いですか／変えるべきですか？」と尋ねたときに読む。
references/budget-and-customs.md — 予算の構造、買い物の段階設定、税関の免税枠、現金と支払い、手荷物許容量。第6歩で読む。
references/entry-and-health.md — 国籍に基づくビザ／電子渡航認証の確認、入国登録、健康、パスポート残存期間、保険。目的地決定後、チケット予約前に読む。ビザに関する結論を断言してはならない。
references/decision-thresholds.md — 待ち時間／予約／逆算／ホテル変更などの閾値、およびソーシャルメディア、公式サイト、プラットフォーム、地図といった情報源の役割分担。旅程を組み始めるか、比較検討する前に読む。
assets/planning-templates.md — 出力の骨格、日次／カウントダウンテンプレート、荷物生成法、具体的な電話番号を記入する緊急時対応カード。ドキュメントを作成し始めるときに読む。

深度旅行攻略制作法