旅行会社が法人・団体旅行の行程表を、顧客の要望と訪問先・移動時間から下書きし、無理のある移動と営業時間の食い違いを指摘する

処理の起点を決める

営業担当が依頼シートのメニューから「下書きを作る」を押したときに動かします。 要望の聞き取りは電話や訪問が中心で、書き終わる時点は営業担当にしか分かりません。フォームの送信やシートの編集で自動に動かすと、書きかけの要望で下書きが作られます。

「点検だけ」のメニューも別に用意します。 営業担当が順番や滞在時間を直した後は、行程の案を作り直さず、3番から5番の点検だけを走らせます。直した箇所を、AIが作り直して元に戻すのを防ぐためです。 点検は何度押してもよく、押すたびに行程表の指摘の欄が書き換わります。

旅行日まで7日を切った案件は、点検のときに currentOpeningHours も見ます。 7日より先の旅行では、特別な営業時間がまだ反映されていないので regularOpeningHours だけで見ます。どちらで見たかを行程表に書き、旅行の直前にもう一度点検を走らせる運用にします。

入力データを集める

質を決めるのは、訪問先の台帳です。 特に「団体の受付の締め」と「季節の注意」の2列は、ベテランの頭の中にしか無かった情報です。「閉館16時30分、団体は16時まで」「12月〜2月は峠道を避ける」のように書いておくと、点検の規則に乗せられます。台帳は最初から全部をそろえる必要はなく、よく使う施設から埋めます。

参加者の名前や連絡先は渡しません。 行程を組むのに要るのは人数と配慮事項だけです。名簿は手配の段階で別に扱い、この構成には入れません。

データの取得方法を決める

AIに渡す台帳は、地域で絞ります。 宿泊地と行きたい場所から都道府県や地域を決め、その地域の施設だけを渡します。台帳を全部渡すと、AIは遠い施設を「似ているから」と入れることがあります。

Routes API の呼び出しは、AIが作った順番の区間だけを要素にします。 出発地の配列と目的地の配列を同じ並びにし、originIndex と destinationIndex が隣り合う組だけを使います。結果は順不同で返ることがあるので、添字で区間に当てはめます。 要素ごとにエラーが付くことがあり、condition が経路ありを示さない区間は「経路が見つからない」として人へ回します。

営業時間の periods は、曜日を数字（0が日曜）で持ちます。 旅行日の曜日を数字にして、その日の open と close を引きます。公式の説明では、期間の並びの始まりを日曜と決めつけないこととされているので、並び順ではなく day の値で引きます。

AIへ渡す前に整形する

1. 要望の確かめ … 日程・人数・出発地・宿泊地が空でないか。空なら下書きを作らず、営業担当に戻します
2. 台帳との照合 … 「行きたい場所」を台帳の施設名と照らし、見つからないものを「台帳外」に分けます
3. 台帳の絞り込み … 宿泊地と行きたい場所の地域で施設を絞ります
4. 人数での除外 … 団体の上限人数が参加人数より少ない施設、大型バスが停められない施設を候補から外します
5. 配慮事項の付け足し … 「歩く距離を短く」なら、滞在の目安に歩きの多い印のある施設を後ろに回すよう指示に足します
6. 曜日の準備 … 旅行の各日の曜日と、旅行日まで何日かを計算しておきます

2番の「台帳外」は、AIに渡しません。 顧客が名前を挙げた場所でも、台帳に無い施設は団体の受入れもバスの駐車も分かりません。AIに渡せば行程に入り、時刻まで付いた行程表が顧客に出ます。 台帳外の施設は、営業担当が確かめて台帳に足してから、もう一度下書きを作ります。

4番を前処理に置くのは、AIに判断させないためです。 「80名だから入れない」という判断は、台帳の数字で機械的に決まります。

AIに処理させる

AIを呼ぶのは2回です。1回目は行程の案、2回目は食い違いの説明です。

1回目で時刻を書かせない理由は、AIの時刻が「もっともらしい」からです。 「9:00出発、10:15到着」と書かれた行程は、地図で確かめていなくても正しそうに見えます。時刻の列を空のまま受け取り、APIの数字で埋めると決めておけば、根拠の無い時刻が行程表に残りません。

2回目で新しい食い違いを探させない理由も同じです。 AIが「この施設は冬は閉まっているかもしれません」と書くと、根拠のない指摘が規則の指摘と並びます。指摘の根拠は規則とAPIの数字だけにし、AIの役割は説明と案に限ります。

規則で拾う食い違いは次のとおりです。

連続運転の目安は、厚生労働省のバス運転者の改善基準告示に沿って自社で決めます。 告示では連続運転時間は4時間を超えないものとされ、高速バスと貸切バスの高速道路の実車運行区間では、おおむね2時間までとするよう努めることとされています。ただし、運行計画が基準に合うかを決めるのはバス会社で、この点検は「バス会社に組み直しを求められそうな行程」を先に見つけるためのものです。

指示内容を固定する

1回目（行程の案）の指示です。

あなたは旅行会社の法人営業部で、団体旅行の行程の案を作る立場です。
渡した「候補の施設」だけを使って、日ごとの訪問の順番と滞在分数を決めてください。

【要望】{request}
【候補の施設】{candidates}
（各施設：facility_id、施設名、滞在の目安分数、団体の受付の締め、季節の注意、歩きの多さ）
【自社の決まり】昼食は1回、11時〜13時30分の間に入る位置に置く。
             2時間に1回はトイレ休憩の位置を置く。

【厳守事項】
- 候補の施設に無い場所を行程に入れないでください。
  要望にある場所が候補に無いときは、unlisted_requests に名前を書くだけにしてください。
- 時刻を書かないでください。移動時間を見積もらないでください。
  時刻は別の仕組みで計算します。
- 滞在分数は、候補の施設の滞在の目安から前後30分の範囲で決めてください。
- 季節の注意に書かれていることに反する並べ方をしないでください。
- 参加者の配慮事項があるときは、どこにどう反映したかを note に書いてください。
- 営業時間や定休日を推測して書かないでください。
- 行程の良し悪しや、顧客への提案文は書かないでください。

2回目（食い違いの説明）の指示です。

あなたは、行程の点検結果を営業担当に伝える立場です。
渡した「点検の結果」は、地図のAPIの数字と自社の規則で決まったものです。

【行程】{itinerary_with_times}
【点検の結果】{violations}
【自社の規則】{rules}

【やること】
- 点検の結果の1件ごとに、何が起きているかを1〜2文で書いてください。
- 直し方の案を2つまで書いてください（順番の入れ替え、滞在の短縮、施設の差し替えなど）。
  差し替えるときは、候補の施設の中から選んでください。

【厳守事項】
- 点検の結果に無い問題を新しく書かないでください。
- 点検の結果の時刻と分数を書き換えないでください。計算し直さないでください。
- 「たぶん大丈夫」など、点検の結果を打ち消す書き方をしないでください。
- 運転者の労働時間の基準に合うかどうかを判断しないでください。

「候補に無い場所は unlisted_requests に書くだけ」を明記しないと、AIは顧客が挙げた名所を行程に入れます。 要望を満たそうとするのは自然な振る舞いで、禁じるだけでなく、書き込む先を用意することで、要望を落とさずに台帳の外へ出せます。

2回目の「打ち消す書き方をしない」も効きます。 AIは食い違いを伝えるときに「多少の余裕があれば問題ない場合もあります」と和らげがちで、読んだ営業担当が直さずに出してしまいます。

出力形式を固定する

1回目は、次の形のJSONで受け取ります。

{
  "trip_id": "T2026-118",
  "days": [
    { "day": 1,
      "stops": [
        { "seq": 1, "facility_id": "F-0412", "kind": "visit | lunch | rest | hotel",
          "stay_min": 60, "note": "" }
      ] }
  ],
  "unlisted_requests": ["顧客が挙げたが候補に無い場所"],
  "assumptions": ""
}

時刻の欄が無いのは意図してのことです。 時刻は Apps Script が duration と規則から埋め、次の形で行程表に書きます。

「移動（API）」と「移動（係数後）」を並べるのが、（a）への答えです。 APIの所要時間に自社の係数と乗降の分数を足した値で時刻を組み、両方を見せることで、営業担当が係数の妥当さを現地の経験と照らせます。

構造化出力は、Gemini API の /v1beta/interactions に送るリクエストの response_format で指定します。 mime_type に application/json を入れ、schema にJSONスキーマを書きます。kind は enum、facility_id と stay_min は required にします。公式のページは、スキーマに合ったJSONでも値が誤っていることがあるので、アプリケーションの側で値を確かめるよう案内しています。 Apps Script で、facility_id が渡した候補にあるか、stay_min が目安の範囲か、昼食が1回だけかを確かめ、外れていれば作り直しを1回だけ行い、それでも外れれば営業担当に回します。

2回目は、指摘ごとに violation_id、explanation、options（2件まで）を返させ、行程表の「指摘」の欄に書き込みます。

システムへ連携する

APIキーは、Apps Script のスクリプトのプロパティに置き、コードに書きません。 地図のAPIのキーは、使うAPIを Routes API と Places API に絞る制限をかけておきます。

行程表は下書きとして新しいシートに作り、顧客には直接送りません。 顧客に出すのは営業担当が直し、施設とバス会社に確かめた後の版です。案件の管理表にも、この構成からは書き込みません。

人が確認する

すべての下書きを、営業担当が直してから使います。 そのうえで、見る順番を決めておきます。

1. 「台帳外」を最初に見る … 顧客の希望なので、落とせば提案に響きます。施設に電話して受入れとバスの駐車を確かめ、台帳に足します
2. 営業時間外・定休日の指摘を直す … 直し方の案から選ぶか、自分で並べ替え、「点検だけ」を押し直します
3. 連続運転と1日の長さの指摘を見る … 直せないときは、バス会社に先に相談します
4. 「要確認」の施設に電話する … 予約の要る施設、団体の受付の締めが台帳に無い施設です
5. ベテランは、指摘が残ったまま出そうとしている行程だけを見る … 全件の見直しはしません

5番が（d）への答えです。 点検の結果が空になった行程は、営業時間と移動の数字の上では食い違いがありません。ベテランが見るのは、指摘が残っているのに出す理由がある行程だけになります。 その理由は行程表の備考に書いてもらいます。

例外に対処する

「点検未完了」を必ず書くのは、空の指摘欄が「問題なし」と読まれるためです。 点検が途中で止まった行程と、点検して何も見つからなかった行程を、見た目で区別できるようにします。

記録を残す

• 要望の行、AIに渡した候補の施設、1回目の指示と返ってきたJSON
• Routes API と Places API の返却のうち、点検に使った値と取得日時
• 点検の結果（規則ごとの判定）と、2回目のAIの説明
• 営業担当が直した点と、「点検だけ」を押した回数
• 指摘が残ったまま顧客に出した行程と、その理由
• 「台帳外」として出てきた場所と、台帳に足したかどうか

「指摘が残ったまま出した理由」は、規則を育てる材料です。 同じ施設で同じ理由が続くなら、台帳の受付の締めか、規則の係数が実態と合っていません。ベテランの経験が台帳と規則に移っていくのは、この記録を通してです。

地図のAPIから取った値の保存期間は、Google Maps Platform の規約を確かめて決めます。 点検の根拠として残す値と、次の点検で取り直す値を分けておきます。