旅行代理店の旅程表・見積もりをClaude Codeで安全に作る手順

金曜の夕方に相談が重なり、「来週末、夫婦で京都2泊。予算は20万円前後で、紅葉と懐石を楽しみたい」という依頼を受けたとします。宿の候補、移動時間、料金、注意事項を一つの提案書にまとめる間にも、次の相談が待っています。

この記事では、この状況を再現した架空の京都2泊ケースを使います。実在する旅行者の個人情報、予約情報、旅行代理店の顧客データは使っていません。ClaudeCodeLabが確認したのは、要望メモから旅程の叩き台を作る手順と、架空の料金を検算するコードです。作業時間の短縮を実績として断定せず、自社で測る方法まで示します。

Claude Codeに任せるのは「組み立てと清書」です。料金、空室、キャンセル規定、最終提案は人が確認します。この境界を崩さないことが、安全に使う前提です。

この記事の要点

• 旅程表・見積もり・提案書の「組み立てと清書」はAIが得意。プランナーは行き先選びとお客様対応に集中できる
• そのまま貸せるプロンプト雛形と、料金の計算ミスを機械で弾く検証スクリプトを置いた
• 料金・在庫・キャンセル規定など「間違えたら事故になる数字」は人が必ず確認する。ここを線引きするのが安全に使う条件
• 個人情報は氏名や予約番号を伏せ字にしてからAIに渡す。生データを貼らない運用ルールを先に決める
• 時短効果は実績として決めつけず、導入前後の作業時間を同じ条件で測ってROIを計算する

そもそも旅行代理店の仕事のどこが重いのか

読者はおそらく、店舗や法人営業でオーダーメイド旅行を組むプランナーでしょう。パッケージを売るより、要望を聞いて一から組む比率が高い人ほど、この記事は刺さるはずです。

オーダーメイドの提案は、だいたいこんな流れで進みます。

1. ヒアリング：行き先、人数、予算、好み、外せない条件を聞く
2. 素材集め：宿、交通、現地体験の候補と料金を調べる
3. 組み立て：移動時間と空き状況を見ながら日程に落とす
4. 見積もり：宿泊、交通、手配料、税を足して総額を出す
5. 清書：旅程表と提案書に整え、注意事項を添える
6. 提示と修正：お客様に出し、「2日目を観光多めに」などの直しを反映する

このうち1と6は、人が担う仕事です。お客様の反応を見ながら希望の優先順位を決め、提案に責任を持ちます。一方で3から5は、確認済みの素材を決まった型に流し込む作業です。修正のたびに旅程と見積もりを更新するため、手戻りが生まれやすい工程です。

たとえば「2日目をもう少しゆっくりに」という変更では、移動時間と料金の両方を見直します。Excelの行を追加したのに合計範囲を更新し忘れると、誤った金額を提示しかねません。文章の修正と料金の検算を分ける理由はここにあります。

Claude Codeに任せる範囲と、人が判断する範囲

ここを曖昧にすると事故ります。先に線を引きます。

工程	AIに任せる	人が必ず判断する
ヒアリング	質問の抜け漏れチェック	予算の本音、相性、雰囲気の読み取り
素材集め	候補の下調べ、比較表の作成	在庫・空室の最終確認、おすすめの取捨選択
組み立て	移動時間を考えた日程の叩き台	無理のない動線か、体力に合うか
見積もり	計算式の組み立て、合計の下書き	仕入れ単価、為替、キャンセル規定の数字
清書	旅程表と提案書への整形、誤字チェック	最終承認、お客様名義の確定

覚えてほしい線引きは1つです。「間違えたら返金やクレームになる数字」は、必ず人が確認する。 料金、空室、キャンセル料、年齢別料金、為替。ここはAIの下書きを鵜呑みにせず、仕入れ先の正式な料金で照合します。AIは速い清書係であって、料金保証はしてくれません。

3つのUse case

Use case 1：要望メモから旅程表の叩き台を作る

ヒアリングのメモは、たいていバラバラの箇条書きです。ここでは、個人を特定できる情報を除いたメモをAIに渡し、日程表の形に整えます。

• 入力: 氏名・電話番号・予約番号を削った要望メモ
• 出力: 時間帯、移動、食事、未確認項目を並べた旅程表の初稿
• 人の確認: 空室、移動時間、営業日、旅行者の希望との一致

そのまま使えるプロンプト雛形がこれです。

あなたは旅行代理店のベテランプランナーです。
以下の要望メモから、移動時間に無理のない旅程表の叩き台を作ってください。

# 要望メモ
- 行き先: 京都
- 日程: 2泊3日
- 人数: 夫婦2名
- 予算: 総額20万円前後
- 希望: 紅葉スポット、夜は懐石、移動は詰め込みすぎない

# 出力ルール
- 1日ごとに「午前/午後/夜」で区切る
- 各項目に所要時間の目安と移動手段を書く
- 移動が1時間を超える箇所には「★移動長め」と注記する
- 料金が必要な箇所は [要確認:料金] と書き、数字は勝手に埋めない
- 最後に「確認が必要な項目」を箇条書きで列挙する

最後の2行が肝です。料金は勝手に埋めさせず、[要確認:料金] のプレースホルダにしておく。 こうすると、AIがそれらしい未確認価格を書く事故を防げます。出てきた叩き台には、担当者が予約システムや仕入れ先で確認した正式な料金だけを入れます。

Claude Codeの基本操作にまだ慣れていない人は、先にClaude Code はじめ方ガイドを読んでおくと、この雛形をすぐ試せます。

Use case 2：見積もりの合計ミスを機械で弾く

提案書で一番怖いのが、料金の足し算ミスです。1泊2食を人数分、税とサービス料、手配料。Excelで組むと、行を1つ足したときに合計範囲がズレて、気づかず低い金額で出してしまう。これは謝罪と差額の自腹コースです。

• 入力: 担当者が公式画面で確認した料金内訳と、提案書に載せる総額
• 出力: 内訳と総額が一致すれば OK、違えば差額付きの NG
• 人の確認: 単価、税区分、取消料、通貨、提示総額の転記

そこで、見積もりの内訳を機械でチェックするスクリプトを用意しました。Node.jsがあれば動きます。内訳の小計を全部足し直して、提示している総額と一致するかを検算するだけのものです。

// verify-quote.mjs  料金の内訳と総額が一致するか検算する
// 実行: node verify-quote.mjs

const quote = {
  customer: "（伏せ字）様",
  items: [
    { label: "宿泊 1泊目 旅館A 2名", amount: 48000 },
    { label: "宿泊 2泊目 旅館B 2名", amount: 52000 },
    { label: "新幹線 往復 2名", amount: 56000 },
    { label: "現地ガイド 半日", amount: 18000 },
    { label: "手配料", amount: 8000 },
  ],
  tax: 14400, // 消費税など
  presentedTotal: 196400, // 提案書に書く総額
};

const subtotal = quote.items.reduce((sum, item) => sum + item.amount, 0);
const calcTotal = subtotal + quote.tax;

console.log(`小計: ${subtotal.toLocaleString()}円`);
console.log(`税:   ${quote.tax.toLocaleString()}円`);
console.log(`計算上の総額: ${calcTotal.toLocaleString()}円`);
console.log(`提案書の総額: ${quote.presentedTotal.toLocaleString()}円`);

if (calcTotal === quote.presentedTotal) {
  console.log("OK: 内訳と総額が一致しています");
} else {
  const diff = quote.presentedTotal - calcTotal;
  console.log(`NG: ${Math.abs(diff).toLocaleString()}円ずれています。提案書を出す前に直してください`);
  process.exit(1);
}

このスクリプトに presentedTotal を提案書の数字に合わせて入れておけば、ズレた瞬間に NG で止まります。お客様に出す前の最後の門番です。items の単価そのものは人が仕入れ先で確認した値を入れる前提で、ここは検算しかしません。検算と料金確認は別、と割り切るのが大事です。

プロンプトの精度をもっと上げたい人は、プロンプトの精度を上げるコツもあわせてどうぞ。

Use case 3：「2日目をゆっくりに」の修正を一発で反映する

提示後の修正では、変更点を明示させると確認しやすくなります。架空ケースでは、次のように依頼します。

• 入力: 直前の旅程表と「2日目をゆっくりに」などの変更要望
• 出力: 変更箇所を明示し、料金が動く項目を未確認へ戻した改訂案
• 人の確認: 前後の移動、予約可能性、料金の再計算、要望の取りこぼし

先ほどの旅程表に、次の修正を反映してください。
- 2日目: 午前の予定を1つ減らし、午後はホテルでの休憩を1時間入れる
- それにより移動が変わる箇所は所要時間を書き直す
- 料金が変わる項目は [要確認:料金] に戻す
- 変更した箇所の先頭に「▼変更」と付け、何を変えたか一行で説明する

「変更箇所に印をつけて」と頼むのがコツです。どこが変わったかを追いやすくなります。料金が動く項目は [要確認:料金] に戻させ、再計算は人が行います。これにより、「旅程は直したが合計だけ古いまま」という見落としを確認項目として切り出せます。

旅程と提案書のひな型をプロジェクトに覚えさせておくと、毎回ゼロから指示せずに済みます。やり方はCLAUDE.md の書き方が参考になります。

コピペで使えるプロンプトと確認チェックリスト

提案書を出す前の最終確認は、紙でもメモでもいいので毎回これを通してください。

• 料金は仕入れ先の正式な見積もりと照合したか
• 空室・在庫を最終確認したか（AIの下書きを信用していないか）
• キャンセル規定と年齢別料金を本文に入れたか
• 検算スクリプトを通して合計が一致したか
• お客様の氏名・予約番号を正しい表記に戻したか
• 移動時間に無理がないか（高齢・小さい子ども連れは特に）

Pitfall: 個人情報と未確認料金をそのまま渡す

旅行の手配は、氏名、生年月日、パスポート番号、予約番号と、機微な情報の塊です。これをそのままAIに貼るのは避けます。

原因は、旅程の下書きに不要な個人情報までヒアリングメモからコピーしてしまうことです。未確認の料金をAIに補完させると、それらしい数字が正式料金のように残る問題も起きます。

対策として、入力前に氏名と予約番号を仮IDへ置き換え、料金欄を [要確認:料金] に固定します。生データを貼ってしまった場合は作業を止め、社内の情報管理ルールに従って履歴・共有範囲を確認し、匿名化したファイルで最初からやり直します。

運用ルールはシンプルに2つです。1つ、個人情報は伏せ字にしてから渡す。 氏名は「A様」、予約番号は「（伏せ字）」に置き換える。組み立てや清書に本名は要りません。2つ、生データはローカルで管理し、最後の名義差し込みだけ人が手元でやる。 AIには型を作らせ、個人を特定する情報は手元で埋める。この順番を守れば、外に出して困る情報は流れません。

会社として導入するなら、何を渡してよくて何がダメかを明文化しておくと安全です。チームでの線引きづくりは研修・相談で一緒に整理できます。判断基準を曖昧なまま全員に配ると、誰かが必ず生データを貼ってしまうからです。

時短効果を誇張せずに測る方法

効果は会社の帳票、案件の複雑さ、確認工程によって変わります。まず同じ種類の提案を5〜10件ずつ測り、中央値で比べてください。AIの出力待ちだけでなく、人による料金確認と修正時間も含めます。

測定項目	導入前	試験導入後
要望メモから初稿まで	5〜10件の中央値を記録	同条件で中央値を記録
修正依頼から再提示まで	修正内容別に記録	同じ修正内容で記録
検算で見つかった差異	件数と原因を記録	件数と原因を記録
人による最終確認	所要時間を記録	省略せず所要時間を記録

ROIは 月間提案件数 ×（導入前の中央値 - 導入後の中央値）÷ 60 で、月間の削減時間を見積もれます。以下は実績ではなく計算例です。 月60件で1件あたり20分短くなった場合は、月20時間です。そこからツール費、テンプレート整備、最終確認に増えた時間を引いて判断します。

非エンジニアでも使えるのか不安な人は、エンジニアでなくても使えるClaude Codeを読むと、最初の一歩のハードルが下がるはずです。

よくある質問

Q. AIが料金を勝手に決めてしまわないか心配です。 A. プロンプトで [要確認:料金] を使い、数字を埋めさせない運用にします。料金は人が仕入れ先で確認した値だけを入れる。AIは計算式と清書の係、と役割を固定すれば暴走しません。

Q. お客様の本名や予約番号を入れて大丈夫ですか。 A. 入れないでください。伏せ字にしてから渡し、最後の名義差し込みだけ手元でやります。組み立てと清書に個人名は不要です。

Q. うちは独自の旅程テンプレートがあります。再現できますか。 A. できます。自社の型と書式ルールをプロジェクトに覚えさせれば、毎回それに沿った形で出してくれます。詳しくは公式ドキュメントの設定方法を確認してください。

Q. 完全に自動化して、人の確認を省けますか。 A. おすすめしません。料金・在庫・キャンセル規定の確認は人が握る前提です。ここを省くと、ミスがそのままお客様に届きます。時短は「組み立てと清書」に限るのが安全です。

実際に試した結果

ClaudeCodeLabでは、この記事に掲載した検算コードを架空の料金だけで実行しました。掲載値のままでは、内訳182,000円と税14,400円の合計が提示総額196,400円と一致し、OK になりました。次に presentedTotal を2,000円だけ変更すると、コードは NG を表示し、終了ステータス1で停止しました。

旅程作成のプロンプトにも架空の要望だけを入力し、出力を目視で確認しました。料金欄が [要確認:料金] のまま残っていること、氏名・予約番号・パスポート番号などの個人情報（PII）が含まれていないことを確認しています。実在する顧客、仕入れ先、旅行代理店のデータでは試していません。

この検証で確認できたのは、架空データでのプレースホルダ維持と合計差異の検知までです。実務での正確性や時短効果を保証するものではありません。まず今日、実在情報を含まないテスト案件を1件置き、料金欄が未確認のまま残るか、検算コードが誤差を止めるかをチェックしてください。実務導入では担当者が正式料金、空室、キャンセル規定を照合します。最初の操作に迷ったらClaude Code はじめ方ガイドから始めるのが近道です。

公式の使い方はClaude Code 公式ドキュメントも参照してください。