貸切バス会社に届く見積依頼のメールとフォームから、行程・日時・人数・乗降地を整理して、届出の運賃表による見積の下書きと確認事項の返信案を作る

処理の起点を決める

依頼のメールとフォームの通知に、Gmail のフィルタでラベルが付いたことを起点にします。 フォームの通知は送信元と件名が決まっているので、フィルタで確実に拾えます。メールの依頼は、件名や本文の語（「見積」「貸切」「バス」）で拾い、拾い漏れは担当が受信箱で見つけて手でラベルを付けます。

Watch emails は10分おきに動かし、条件は「すべて」にします。担当が先に開いて既読にしても漏れないようにするためです。 処理済みのメールには別のラベルを付け、Gmail の検索式で除きます。

同じ依頼者からの追加のメール（「人数が変わりました」など）も、同じスレッドで届きます。 スレッドのIDで見積の台帳を引き、既にある見積への追加として扱い、新しい見積を作りません。

入力データを集める

質を決めるのは、行程の文章を区間に直す精度です。 配車地・立寄地・到着地と、それぞれの時刻が区間の表になっていれば、残りは式と地図の仕事です。AIに頼むのはここだけと決めておくと、どこを確認すればよいかがはっきりします。

車種の区分は、資料の定義に合わせて車両の一覧に持ちます。 同じ資料では、大型は車両の長さ9メートル以上または旅客席数50人以上、小型は長さ7メートル以下かつ旅客席数29人以下、中型はそれ以外とされています。

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

距離と時間は、区間ごとに1回ずつ求めて足します。 営業所→配車地、配車地→立寄地、立寄地→到着地、到着地→営業所、のように区間を分け、それぞれ出発地と目的地を送ります。区間ごとに残すと、営業が直すときに、どの区間の目安が外れているかが分かります。

1区間の要求は、次のような形になります。公式のページでは、地点は place ID（推奨）、緯度経度、住所の文字列などで指定できるとされています。ここでは住所の文字列で渡し、営業所や常連の配車地は place ID を台帳に持たせます。

POST https://routes.googleapis.com/directions/v2:computeRoutes
X-Goog-FieldMask: routes.duration,routes.distanceMeters

{
  "origin":      { "address": "（営業所の住所）" },
  "destination": { "address": "（配車地。区間の表の place_text）" },
  "travelMode":  "DRIVE"
}

travelMode は DRIVE で、乗用車の経路と時間です。 バスが通れない道や、バスの走行に合わない時間が返ることがあるため、第7章の「人間の確認」で営業が直す前提にします。返った duration は秒の文字列なので、計算シートで時間に直します。

営業所からの回送の区間を、必ず先頭と末尾に足します。 依頼の文章には書かれていないため、AIの書き出しには含めず、ワークフローの側で足します。 キロ制運賃は出庫から帰庫までの走行キロで出すため、ここが抜けると見積が低く出ます。

AIへ渡す前に整形する

1. 本文の整理 … 引用された過去のやり取りと署名を除き、新しく書かれた部分だけを渡します
2. フォームの欄の分解 … フォームの通知は欄の名前と値に分け、利用日・人数・連絡先はそのまま使います。行程の欄だけを AI に渡します
3. 添付の確認 … 旅行会社の行程表が添付で届くことがあります。添付があれば台帳に印を付け、この構成では営業が添付を見て区間の表を確かめます
4. 既存の見積の確認 … スレッドのIDで台帳を引き、既にあれば追加の連絡として扱います
5. 受信日の付加 … 「来月の第2土曜」のような書き方のために、受信日を入力に足します

2番目で行程の欄だけを渡すのは、AIが読む量を減らすためだけではありません。 利用日や人数のように欄で決まっている値まで AI に読ませると、欄の値と自由記述の値が食い違ったときに、どちらを取ったかが分からなくなります。 欄の値はそのまま使い、食い違いは規則で検知します。

AIに処理させる

させるのは、行程の文章を区間の表に直し、日時・人数・車種の希望を根拠つきで書き出すことだけです。

区間の地点は、書かれた名前をそのまま写させます。 「水族館」とだけ書かれていたら、近くに水族館が2つある地域では、どちらか分かりません。AIに正式名称を補わせず、地図のAPIで引けなかった地点は聞き返す項目にします。

規則で決めること：

深夜早朝の印は、国土交通省の資料に沿います。 同じ資料では、22時以降翌朝5時までの間に点呼点検時間や走行時間（回送時間を含む）が含まれた場合、その時間の1時間あたりの運賃と交替運転者配置料金に2割の割増を適用するとされています。印を付けるのはワークフロー、適用を確定するのは営業です。

指示内容を固定する

あなたは貸切バス会社の営業の担当で、見積依頼の行程の文章を、
見積の計算に使う区間の表に直す役です。
書かれていることだけを書き出してください。推測で埋めないでください。

【書き出す項目】
- days: 利用日ごとに分ける。日付の書き方はそのまま写す
- segments: 日ごとに、配車地 → 立寄地 → 到着地 の順に並べる。
  各地点に、到着・出発の時刻と滞在の時間が書かれていれば添える
- passengers: 乗車する人数。引率・添乗員を含むかの記載
- vehicle_request: 車種・台数・補助席の希望
- luggage: 荷物
- expense_hints: 有料道路・駐車場・乗務員の宿泊についての記載
- requester_type: agency / school / company / group / individual / other

【厳守事項】
- 書かれていない項目は空にしてください。
- 地点の名前は書かれたとおりに写してください。正式名称に直したり、
  住所を補ったりしないでください。
- 「夕方」「お昼ごろ」「2時間くらい」は、そのまま写してください。
  時刻や分に直さないでください。
- 帰着の時刻が書かれていないとき、到着地や立寄地の時刻から
  推し量らないでください。
- 運賃・料金・距離を計算しないでください。
- 各項目の evidence に、根拠にした文をそのまま写してください。
- 本文に複数の案（A案・B案など）があれば、案ごとに分けてください。

【受信日】{received_date}
【フォームの欄の値】{form_fields}
【行程の文章】{itinerary_text}

「時刻や分に直さない」を書かないと、「夕方」が「17:00」に、「2時間くらい」が「120分」になります。 その値で時間制運賃が出ると、依頼者が18時に戻るつもりだったとき、見積が1時間分低く出ます。 写したまま残せば、規則が「帰着の時刻が空」と判定し、聞き返す項目に入ります。

「案ごとに分ける」は、学校の依頼に多い書き方への対策です。 「雨天の場合は〇〇へ変更」のような書き方があると、区間が混ざります。案ごとに分けておけば、営業が案ごとに見積を出すかを決められます。

出力形式を固定する

{
  "message_id": "",
  "requester_type": "agency | school | company | group | individual | other",
  "plans": [
    {
      "plan_label": "",
      "days": [
        {
          "date_text": "",
          "segments": [
            { "seq": 1, "role": "pickup | stop | destination",
              "place_text": "", "arrive_text": "", "depart_text": "",
              "stay_text": "", "evidence": "" }
          ],
          "return_time_text": ""
        }
      ]
    }
  ],
  "passengers": { "value": "", "includes_staff": "", "evidence": "" },
  "vehicle_request": { "value": "", "evidence": "" },
  "luggage": { "value": "", "evidence": "" },
  "expense_hints": [{ "value": "", "evidence": "" }]
}

1つ目の理由は、segments をそのまま Routes API の要求に変えられることです。 seq の順に、前の地点を出発地、次の地点を目的地として要求を作ります。先頭と末尾に営業所の区間を足すのはワークフローの側です。

2つ目は、_text の項目が空かどうかで聞き返す項目が決まることです。 AIに「何を聞くべきか」を考えさせないため、聞き返す項目が担当によってぶれません。

3つ目は、plans で案を分けられることです。 案ごとに計算シートの行を分けます。

計算シートには、区間ごとの距離（km）と時間、合計の走行キロと走行時間、車種と台数の候補、深夜早朝と長距離の印を書き込みます。時間制運賃・キロ制運賃・料金の列は、シートの式が運賃表を参照して出します。 式は、時間制運賃が（走行時間＋2時間）×時間単価（3時間を下回るときは最低運賃）、キロ制運賃が走行キロ×キロ単価で、端数の扱いは自社の届出の運賃表の定めに合わせます。

システムへ連携する

Routes API の要求は、返す項目を routes.duration,routes.distanceMeters に絞ります。 経路の線などの要らない項目を返させないためです。distanceMeters はメートルで返るので、計算シートで km に直します。

返信案は、受付のお礼と確認事項だけです。 金額は入れません。確認事項は、規則で決めた聞き返す項目を、依頼者が答えやすい順（利用日、人数、配車地と時刻、帰着の時刻、立寄地の名前）に並べます。

人が確認する

1. 区間の表と根拠を照らす … evidence と依頼の本文で、地点の順と時刻が合っているかを見ます
2. 距離と時間の目安を直す … Routes API の時間は乗用車の走り方による目安です。バスの速度、休憩、駐車場での乗降の時間を足して直します
3. 運行管理が確かめる … 長距離の印と深夜早朝の印のある見積は、交替運転者の要否と配車の空きを運行管理が確かめます
4. 見積を確定する … 実費（有料道路・駐車場・乗務員の宿泊）と割引の扱いを決め、金額を確定します
5. 返信案を直して送る … 確認事項の返信案を直し、確定した見積を添えて返します

2番目を省かないでください。 地図の目安のまま時間制運賃を出すと、実際の運行より短い時間で見積が出ます。 営業所の経験で、区間の種類（高速道路・山道・市街地）ごとの補正の目安を持っておくと、直す時間が短くなります。

3番目は、見積の段階で行います。 受注の後で交替運転者が要ると分かると、交替運転者配置料金が加わり、依頼者に見積の出し直しを頼むことになります。

例外に対処する

7行目は、急ぎの例外です。 当日や翌日の依頼は、配車の空きを先に確かめないと答えられません。ワークフローが計算を待たずに、営業のチャットへ知らせます。

記録を残す

• 元のメールとフォームの通知（Gmail に残る）、処理済みのラベル
• AIの出力の JSON の全文
• 区間ごとの Routes API の距離と時間、営業が直した後の距離と時間
• 計算シートの行（そのときの運賃表の版を含む）
• 確定した見積の金額と、受注したかどうか
• 運行管理の確認の結果（交替運転者の要否）

営業が直した距離と時間の記録は、補正の目安を作る材料になります。 区間の種類ごとに、地図の目安とバスの実際の差がどれくらいかが分かります。

受注したかどうかを残すのは、返事までの時間と受注の関係を見るためです。 返事が早い見積ほど受注しているなら、この構成の効き目がそこに出ます。