travel-itinerary

旅行日程

概要

旅行の確認書、予約メール、チケット、会議メモ、レストランの予約、突発的に発生した旅行の詳細を、社内出張向けの構造化されたエクスポート可能な日程にまとめます。

基本的な考え方：

Trip
└── Day
    ├── Stay / overnight base
    ├── Node 1
    ├── Link / route to next node
    ├── Node 2
    ├── Link / route to next node
    └── Node 3

• 旅行 — 旅行者、目的地、日付範囲、目的、プライバシー設定など、全体的なコンテキストです。
• 日 — 日付、宿泊先、当日のメモ、時刻順のノードです。
• ノード — フライト、列車、ホテルのチェックイン、会議、観光スポット、レストラン、乗り継ぎ、イベント、チケット制の観光施設、自由時間、事務連絡のリマインダー、自由形式のメモです。ノードには visibility が設定されており、社内向け、チーム共有向け、個人向け、出張管理担当者向けの各エクスポートで、安全に内容を変えられます。

信頼できる唯一の情報源は、正規の YAML です（templates/itinerary-schema.yaml を参照）。デフォルトの出力形式は Markdown で、.ics、PDF、DOCX、Google ドキュメント、チャット用の各形式にも出力できます。

使用する場面

ユーザーが次のことを希望する場合に、このスキルを使用してください。

• 転送または貼り付けられたメールから出張の日程を作成する。
• フライト、ホテル、列車、レストラン、チケット、会議、観光スポットを整理する。
• 散在する予約確認を、見やすい日ごとのスケジュールにまとめる。
• チーム共有用または役員向けの日程を作成する。
• 共有前に機密情報を非表示にする。
• 日程の各地点間の移動時間や地図リンクを追加する。
• Markdown、PDF、DOCX、Google ドキュメント、チャットメッセージ、またはカレンダーの .ics にエクスポートする。
• 新しい確認書や変更内容を反映して、既存の日程を更新する。

完全な旅行管理バックエンドとして、このスキルを使用しないでください。受信トレイの自動監視、複数の旅行を管理する永続データベース、リアルタイムのフライト状況、複数ユーザーによる編集、またはウェブアプリでの共有が必要な場合は、このスキルに加えて別のツールを提案してください。

このスキルは、ユーザーが提供した旅行情報、またはツールで取得した旅行情報を整理して出力します。現在のタスク中に利用可能なライブツールで確認していない限り、リアルタイムのフライト状況、現在の価格、施設の営業時間、所要時間、チケットの在庫、予約の空き状況を把握していると主張しないでください。

参考ファイル

このスキルは、必要な情報を段階的に参照できるよう分割されています。各トピックについて詳しく知りたい場合は、参考ファイルを読んでください。

• templates/itinerary-schema.yaml — 正規の YAML 構造。信頼できる唯一の情報源です。
• references/node-types.md — フィールドをノードタイプごとにまとめた詳細な表。フライトと列車に固有のフィールド、およびステータスのライフサイクルも含みます。
• references/exports.md — Markdown、チャット、役員向け、出張管理担当者向けのテンプレート、.ics の仕様、ファイル名の規則。
• references/privacy.md — 機密フィールド、編集パターン、各形式への項目の掲載マトリクス。
• references/routing.md — 座標の優先順位、Nominatim／OSM によるジオコーディング、Maps の URL パターン、デフォルトの経路に関するルール。
• examples/tokyo-trip.md — 最初から最後までの実例：元のメール → YAML → 4 種類すべてのエクスポート形式 → .ics。
• scripts/itinerary_utils.py — Google Maps の経路 URL、iCalendar のエスケープ／折り返し、.ics の整合性チェックなど、決定的に処理できる定型作業向けの軽量な標準ライブラリヘルパーです。python3 で実行します。

基本的なワークフロー

1. 入力を収集します。 転送されたメール、PDF の確認書、スクリーンショット、 手書きのメモ、更新の場合は既存の旅程を収集します。
2. 構造化された情報を抽出します。 事業者、予約番号、旅行者、 日付／時刻／タイムゾーン、出発地／到着地、住所、チェックイン／チェックアウトの規則、 キャンセルに関する注記、チケットの条件、連絡先、費用。
3. 各項目をノードとして分類します。 references/node-types.md にある type 列挙型を使用します。
4. 旅行と日ごとの構成に整理します。 おおよその目的地と日付の 範囲を推定します。各ノードを該当する現地の日付に割り当てます。ホテル情報は overnight_stay を使って該当する宿泊日に配置します。時刻が決まっているノードは時系列順に並べます。 時刻が決まっていないノードは「スケジュール調整／メモ」セクションに分けて記載します。
5. 必要な場所を選んでジオコーディングします。 通常は、経路の作成や共有に重要な 場所をジオコーディングします。ホテル、空港／駅、会場、予約済みのレストラン、予約済みの送迎が対象です。 オプションの POI や位置情報があるすべてのノードをジオコーディングするのは、ユーザーが地図や経路の情報を充実させた旅程を求めた場合に限ります。 座標を捏造してはいけません。references/routing.md を参照してください。
6. ノードを順番にリンクします。 重要度の高い移動のみ経路リンクを追加します（空港 ↔ ホテル、ホテル ↔ クライアントのオフィス、会議 ↔ 重要な夕食、都市間の移動など）。依頼がない限り、短い徒歩移動すべてに経路を設定する必要はありません。
7. 不確実な情報に印を付けます。 ターミナル、住所、タイムゾーン、乗客名、確認番号、チェックイン時刻、日付の欠落。矛盾、重複、ホテルの宿泊日が不明確な場合、旅行者の割り当てが曖昧な場合も含みます。これらは「未解決の質問／不足している詳細」に記載します。
8. 用途別のエクスポートを作成します。 依頼に応じて、社内向け完全版、チーム共有用、エグゼクティブサマリー、旅行管理担当者向け、チャット用、.ics を作成します。references/exports.md と references/privacy.md を参照してください。

出力先

最終成果物は、ユーザーが選択したフォルダーまたは合意済みのワークスペースに保存します。 作業中のドラフトや中間 YAML はスクラッチパッドに保存できます。ファイル名には references/exports.md の規則を使用します。

ファイルを提示する際は、環境で利用できる方法を使用します。

• チャット／メッセージング環境：プラットフォームのファイル添付機能を使って、ローカルファイルを直接送信します。
• CLI／デスクトップ環境：絶対ファイルパスまたは対応しているローカルファイルへのリンクを提示します。
• クラウドドキュメントのエクスポート（Google Docs／Drive など）：検証済みの共有 URL を提示します。

時刻とタイムゾーンの規則

• YAML 内のすべての starts_at／ends_at／due_at の値は、明示的なタイムゾーンオフセットを含む ISO 8601 形式にします。例：2026-06-12T08:10:00+09:00。
• タイムゾーンをまたぐ航空便や列車では、starts_at のオフセットは出発地の現地オフセット、ends_at のオフセットは到着地の現地オフセットにします。IANA 名が異なる場合、または .ics を生成する場合は、timezone_start と timezone_end も設定します。
• 各日の local_timezone には IANA 名を設定します。これは、その日の trip.timezone_default を上書きします。旅行の途中でタイムゾーンの境界を越える場合に必要です。
• Markdown で表示する時刻は、日付を含む日の現地タイムゾーンで 24 時間表記の HH:MM を使い、その日の見出しにタイムゾーンを表示します（例：## Day 1 — Friday, 12 Jun 2026 (Asia/Tokyo)）。
• 夜間移動または深夜便の場合、Markdown ではノードを出発日に配置し、翌日に到着時刻に関する事務連絡用の注記を追加します。

ステータスのライフサイクル（概要）

各ノードの status は confirmed | tentative | cancelled | unknown のいずれかです。確認書に基づいて作成した項目は、既定で confirmed にします。保留中または「未定」の項目には tentative を使用します。キャンセル済みのノードは削除しないでください。status: cancelled を設定し、監査証跡として残します。共有用の表示では非表示になり、社内向けバージョンでは取り消し線が付きます。表示ルールと変更への対応の詳細は、references/node-types.md を参照してください。

OCR とソースの品質

スクリーンショットやスキャンした PDF から抽出する場合：

• source_item.ocr_quality に high、medium、low、または unreadable を設定します。
• 不確かなフィールドを source_item.ocr_uncertain_fields に列挙します。
• 不確かなフィールドは空欄のままにして、「未解決の質問」に追加するか、確認できた内容に ? を付けて引用します（"?ABC12?"）。黙って正規化してはいけません。
• ソースが unreadable の場合、そこからノードを生成せず、ユーザーに再送または文字起こしを依頼します。

プライバシーと共有用バリエーション

内部用の完全版と共有可能なバリエーションは、必ず区別してください。 機微なフィールド（支払い、パスポート、ロイヤルティ、予約 PIN、個人の連絡先）は、references/privacy.md のマトリクスに従ってマスキングまたは省略します。 デフォルト： ユーザーが対象者を指定せずに「旅程」を求めた場合は、内部用の完全版をデフォルトとし、チーム共有用を作成する前に確認してください。チーム共有用をデフォルトにしてはいけません。誤って共有範囲を広げることは、自分自身に情報を開示しすぎることよりも避けるべきです。

ルートと地図リンク

利用可能な場合は、ジオコーディング／地図ツール（Nominatim／OSM または地図 MCP）を使用します。地図ツールが利用できない場合は、座標を空欄にし、地図リンクには人が読める住所またはコードを使用します。

• デフォルトで、ルートや共有に重要な場所（ホテル、空港／駅、会場、予約済みのレストラン、予約済みの送迎）をジオコーディングします。
• オプションの POI または位置が特定されたすべてのノードをジオコーディングするのは、ユーザーが地図情報やルート情報を充実させた旅程を求めた場合に限ります。
• 利用可能な場合は座標を使って Maps URL を作成し、そうでない場合は URL エンコードした住所または IATA コードを使用します。座標を捏造してはいけません。
• デフォルトでは、価値の高い移動区間のみルートを設定します（ワークフローのステップ 6 を参照）。
• Markdown の読みやすさを保つため、座標と併せて人が読める住所も必ず記載します。

詳細なルール：references/routing.md。

確認ポリシー

曖昧さが旅程に重大な影響を与える場合に限り、確認してください。

次の場合は確認します。

• 2 つの予約が重複している。
• 旅行者の割り当てが不明確（例：フライトが 1 つ、旅行者が 2 人なのに、乗客名が 1 人分しかない）。
• ホテルの予約が、異なる宿泊日または旅行者の予約である可能性がある。
• 旅行グループの誰が参加するのか、または誰と面会するのかが会議情報に記載されていない（汎用の participants ではなく、2 つに分かれたフィールドです）。
• タイムゾーンが示されていない時刻によって、予定の順序が変わる可能性がある。
• ユーザーが共有を求めているが、プライバシーレベルが不明確。
• ジオコーダーが有力な候補を複数返し、明確な最有力候補がない。
• ソースの ocr_quality: unreadable が設定されている。

次の場合は確認しません。

• 妥当なデフォルトがあり、不確実性を「未解決の質問」に記載できる。
• 不足している詳細が些細である。
• ユーザーが明示的に簡易ドラフトを求めている。

よくある落とし穴

1. 早い段階で本格的なアプリを作り込みすぎること。 内部利用であれば、Markdown ＋ ファイル ＋ 必要に応じた Google Doc／PDF／.ics へのエクスポートで十分です。
2. 非公開の詳細と共有可能な詳細を混在させること。 他の人に共有するためにエクスポートする場合は、必ず内部用とチーム共有用のバージョンを別々に作成してください。
3. すべてのノードに経路を設定すること。 特に指定がない限り、重要な移動区間のみ経路を設定してください。
4. タイムゾーンを無視すること。 国境を越える移動では、出発地と到着地の両方で現地時刻とオフセットを維持してください。
5. ホテルの宿泊を単一のチェックインノードとして扱うこと。 宿泊する各日の overnight_stay からもホテルを参照してください。宿泊する夜ごとに宿泊ノードを作成しないでください。
6. 更新された確認情報を重複して追加すること。 新しいメールは変更通知の場合があります。追加する前に、提供元、参照番号、日時、場所を比較してください。古いノードには cancelled を設定し、新しいノードを指す非公開メモを追加してください。
7. 時刻のない POI を無理にスケジュールへ組み込むこと。 ユーザーから時刻の指定がない場合は、任意または未スケジュールのセクションに記載してください。
8. 経路の正確性を過大に主張すること。 所要時間をツールで確認していない場合は、省略するか推定値と明記してください。
9. 座標を捏造すること。 緯度／経度はジオコーダーから取得してください。記憶に基づく座標は、座標がないよりも望ましくありません。
10. 会議に汎用の participants を設定し、分割フィールドを省略すること。 会議ノードには必ず attending_from_travel_party と meeting_with を設定してください。
11. 静的な情報源に基づいて最新情報を断定すること。 現在のタスクでライブツールにより確認されていない限り、経路の所要時間、施設の営業時間、空き状況、料金、フライト状況を最新情報として提示しないでください。

確認チェックリスト

最終出力の前に、次の点を確認してください。

• 旅行のタイトル、日付範囲、目的地、同行者が記載されているか、または不明と明記されている。
• 各日付に正しい日付と local_timezone が設定され、該当する場合は正しい宿泊先が指定されている。
• 各日のノードが時系列順に並んでいる。
• フライト／列車の時刻について、出発地と到着地の両方で現地時刻とタイムゾーンが維持されている。
• ホテルのチェックイン／チェックアウト日が、overnight_stay で示されている宿泊日と一致している。
• lat／lon が、指定されている場合はジオコーダーから取得されており、座標が捏造されていない。
• 重要な住所と Google マップのリンクが、価値の高い移動区間に記載されている。
• ライブ状況、空き状況、経路の所要時間、営業時間、料金に関する記述は、ツールで確認されているか、情報源に記載された内容／現在未確認であると明記されている。
• 機密情報が references/privacy.md に従い、チーム共有用、役員用、チャット用のエクスポートでは伏せられているか、省略されている。
• キャンセルされたノードは削除されず、status: cancelled を設定して残されている。
• 会議ノードでは attending_from_travel_party と meeting_with のみを使用し、会議の participants は空になっている。
• 未解決の質問が隠されずに列挙されている。
• 出力ファイルがユーザーの選択したフォルダーに書き込まれ、読み取り可能であることが確認されている（.ics の場合は BEGIN／END ブロックの対応も確認する）。