観光船の事業者が、フォームとメールで届く貸切・団体の問い合わせから日時・人数・航路を Zapier で抜き出し、運航表の空きを添えた返信の下書きを作る

処理の起点を決める

入口は2つで、Zap も2つ作ります。 フォームの送信で動く Zap と、Gmail のラベルで動く Zap です。2つ目以降のステップは同じ形にして、複製で作ります。

メールの側は Gmail の「New Labeled Email」を使います。 ラベルは、旅行会社のドメインと、件名の「貸切」「団体」などで Gmail のフィルタが付けます。フィルタに当たらなかった問い合わせは、窓口が手でラベルを付ければ同じ経路に乗ります。 このトリガーは同じ会話に返信が付いたときにも動くので、先方からの返事も流れてきます。 返事は新しい問い合わせとして扱わず、第7章の「例外処理」の手順で窓口に回します。

「New Email」や「New Email Matching Search」でも組めますが、検知の対象は直近1時間のメールに限られます。 Zapier が一時止まっていた後で取りこぼさないよう、ラベルの経路にします。

定時にまとめて動かす形にはしません。 第3章の（a）のとおり、この業務の価値は返信の早さにあります。

入力データを集める

受けた日を渡すのは、AIに日付を計算させるためではありません。 「10月30日（金）」のように曜日付きで書かれた日付の年を決めるため、と、「来月の第2土曜」のような書き方が来たときに、それを日付にしないで原文で残す判断をさせるためです。

航路の一覧の「よく使われる呼び方」が、抜き出しの質を決めます。 先方は「島を回るやつ」「1時間のコース」「夕日の便」のように呼びます。一覧の番号から選ばせ、一覧に無い呼び方なら「不明」にさせます。

時間帯の決まりは、第3章の（b）を防ぐ表です。 「午後」が13時と15時の便のどちらを含むかを、事業者の側で先に決めておきます。AIに選ばせるのは「午後」という言葉までで、どの便が当たるかは表で決めます。

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

フォームは、送信の内容がそのまま Zap に渡ります。 メールは、トリガーが本文と差出人を渡します。

空きの確認は、Zapier が運航表を読むのではなく、表の側で計算させます。 流れは2段です。

「問い合わせ」シートには、結果を出す式の列を先に用意しておきます。 たとえば「希望1の残席」は、運航表から日付・航路・時間帯の範囲が一致する便の残席を引く式、「希望1の判定」は人数の上限と残席を比べる式です。貸切なら、貸切枠の表から状態が「空き」で定員が人数の上限以上の枠を引きます。 代わりの便も、同じ日の前後の便から式で1つ選びます。

Lookup Spreadsheet Row は、列と値で1行を探し、見つかれば行全体を返します。 問い合わせID は1件ごとに一意なので、1行だけが返ります。

なぜ Zapier の側で運航表を読まないのか。 複数の行を返す操作（Lookup Spreadsheet Rows (Advanced)）もあり最大500行まで取れますが、取った行のなかから条件に合う便を選ぶのは、ノーコードの部品では組みにくく、AIに任せたくなります。 表の式に置けば、窓口がいつでも開いて計算を確かめられます。

AIへ渡す前に整形する

1. 自社からのメールを止める … 差出人が自社のドメインなら Filter で止めます
2. 引用と署名を落とす … 返信の区切りの文字列から後ろを落とします。残すと、前のやり取りの希望日を新しい希望として拾います
3. フォームの欄を文にそろえる … フォームの「希望日」「人数」「備考」を、欄の名前付きの1つの文にして渡します。備考に第2希望が書かれていることが多いので、欄ごとに別々に渡しません
4. 受けた日と曜日を添える … トリガーの日時から作ります
5. 航路の一覧と時間帯の決まりを文にする … 「1: 島めぐり60分（島を回る、1時間のコース）」のように番号付きで渡します
6. 全角と漢数字を残したまま渡す … 「四十名」「４５名」を前処理で数字に直そうとすると、「四十〜五十」のような幅の書き方を壊します。数字への直しは AI の抜き出しに任せ、出力の型を数字に決めておきます

3番目を軽く見ないでください。 フォームの「人数」の欄に「40」、備考に「最大45名になるかもしれません」と書かれるのは普通です。欄だけを渡すと40で計算され、第3章の（b）がそのまま起きます。

AIに処理させる

させるのは、問い合わせから次の項目を決まった形で抜き出すことだけです。

人数を下限と上限に分けるのが、この表でいちばん効く点です。 空きの判定は上限で行い、返信の下書きにも「最大45名様として確認しました」と書きます。上限で見ておけば、確定の段で人数が増えても席が足りなくなりません。

種類の unknown は、遠慮なく出させます。 「30名で乗りたい」だけなら unknown にし、返信の下書きで「貸切と、定期便に団体でご乗船の2通りがございます」と両方の空きを案内します。AIに推させて片方だけを返すより、1往復が確実に減ります。

2行目が、いちばん起きやすい失敗です。 生成AIは「来月の第2土曜」を親切に計算して日付にします。月の境目や、受けた日が月末かで結果がずれ、ずれた日付の空きが返信に載ります。 日付にするのは、窓口が先方に確かめてからです。

指示内容を固定する

あなたは観光船の予約センターで、貸切と団体の問い合わせから
空きを確かめるのに必要な項目を抜き出す係です。
空きの判断、料金、運航できるかどうかは書きません。

【抜き出す項目】
- kind: charter（船を貸し切りたい） / group（定期便に団体で乗りたい） / unknown
- wishes: 希望を3つまで。各希望に date, date_text, time_slot を入れる
  - date: 年月日が明記されているときだけ YYYY-MM-DD。
          曜日だけ付いて年が無い日付は、【受けた日】以降で最も近い年にしてよい
  - date_text: 問い合わせに書かれた日付の言葉をそのまま
  - time_slot: morning / noon / afternoon / evening / 時刻（例 13:00） / any
- party_min, party_max: 人数の下限と上限（数字）
- route_no: 【航路の一覧】の番号。決められなければ "unknown"
- client_type: travel_agency / company / group / individual / unknown
- ask_back: 決められなかった項目の名前の一覧

【厳守事項】
- 「来月の第2土曜」「連休の初日」「再来週あたり」のような書き方を、日付に直さないでください。
  date を空にし、date_text に原文を写し、ask_back に入れてください。
- 人数に幅があるときは、下限と上限に分けてください。丸めたり平均したりしないでください。
- 「30名で乗りたい」のように貸切か団体かが書かれていなければ、kind は unknown です。
- 航路の一覧に無い名前を作らないでください。
- 空いているか、乗れるか、料金はいくらかを書かないでください。
- 書かれていない項目を推測で埋めないでください。

【受けた日】{received_date}（{weekday}）
【航路の一覧】{routes}
【問い合わせ】{inquiry_text}

曜日付きの日付だけ年を決めてよいとしているのは、旅行会社の問い合わせのほとんどが「11/14（土）」の形だからです。 ここまで禁じると、ほぼすべての日付が ask_back に入り、聞き返しのメールばかりになります。年の補い方を「受けた日以降で最も近い年」と1つに決めたうえで、それ以外の推測を禁じます。

出力形式を固定する

AI by Zapier の出力項目を次のように定めて受け取ります。

{
  "kind": "group",
  "wishes": [
    { "date": "2026-11-14", "date_text": "11/14（土）", "time_slot": "afternoon" },
    { "date": "", "date_text": "その翌週の土曜", "time_slot": "afternoon" }
  ],
  "party_min": 40,
  "party_max": 45,
  "route_no": "1",
  "client_type": "travel_agency",
  "ask_back": ["wishes[1].date"]
}

1つ目の理由は、そのまま表の列に書き込めることです。 希望1〜3の日付・時間帯、人数の下限と上限、航路の番号が、「問い合わせ」シートの列に1対1で入ります。表の式はこの列を前提に組んであるので、形が崩れると式が空を返します。

2つ目は、date と date_text を両方残せることです。 窓口は返信の前に、AIが日付にしたものと原文を横に並べて見られます。

式が出した結果を読むと、次のような行になります。

全体の判定は all（全希望に空き）・partial（一部）・none（空き無し）・check（要確認）の4つで、これも式で出します。 check は、種類が unknown、航路が unknown、人数が空のいずれかです。

システムへ連携する

分岐は Paths で、全体の判定の4つの値で分けます。 1つのまとまりに分岐は10本まで置け、当たらなかったものは Fallback に流せます。Fallback は check と同じ扱いにし、「下書きを作らず窓口に知らせる」にします。 判定の値は文字の条件「Exactly matches」で見ます。文字の条件は大文字と小文字を区別しません。

返信の下書きの文面は、Zapier の側の定型の文に式の結果を差し込んで作ります。 AIに文面を書かせないのは、空きの数字を文の中で言い換えさせないためです。「残席52」が「50席ほど」になると、確定の段で話がずれます。

運航表と貸切枠の表には書き込みません。 仮押さえを入れるのは窓口です。

下書きは窓口の共有の受信箱に作ります。 3名のうち手の空いた人が開けるようにし、だれが送ったかは「問い合わせ」シートの担当の列に、送った人が自分で書きます。 同じ下書きを2人が送る事故は、この列を見る習慣で防ぎます。

人が確認する

下書きはすべて窓口が開いて送ります。 確かめるのは3つです。

1. 日付 … date と date_text を見比べ、年と曜日が合っているか
2. 人数 … 上限で判定されているか。備考の「増えるかも」を拾えているか
3. 航路と種類 … 先方の呼び方が一覧のどの航路に当たったか、貸切か団体か

check の問い合わせは、窓口が原文を読んで手で返します。 その多くは「来月の第2土曜」のような日付と、貸切か団体かの不明です。聞き返しの文案だけは下書きに入れておくので、手で書く量は減ります。

仮押さえは窓口が表に入れます。 先方から「その便で押さえてください」と返事が来たら、運航表または貸切枠の表に、期限付きの仮押さえを書きます。

最初の2週間は、下書きとは別に窓口が自分でも運航表を開いて空きを確かめます。 式の判定と窓口の判断が食い違った件を数え、食い違いが無くなってから、運航表を開くのをやめます。 式の誤りは、窓口がいちばん早く気づきます。

例外に対処する

1行目の扱いが、運用の手間を左右します。 返事を新しい問い合わせとして流すと、「では13時で」という1行から人数も日付も取れず、check が積み上がります。スレッドの ID で前の行を探し、見つかれば窓口に知らせるだけにします。

記録を残す

• 「問い合わせ」シートの全行（受けた日時、経路、抜き出した値、式の結果、全体の判定）
• 窓口が直した記録 … 日付・人数・航路・種類を、何から何に変えたか
• 返信を送った日時と、受けてから送るまでの時間
• 仮押さえにつながったか、確定したか、断られたか
• 月ごとの、経路別・先方の種別・航路別の件数

2つ目は、航路の一覧の呼び方と時間帯の決まりを直す材料です。 「サンセット」が航路の unknown に何度も出るなら、一覧の呼び方に足します。

3つ目の「受けてから送るまでの時間」が、この構成の効き目を測る数字です。 第3章の（a）が減ったかどうかは、ここに出ます。