着物レンタル店が予約の申込を Zapier で受け、着付けの枠と身長に合う着物の残りを確かめて、AI で用途と言語に合わせた事前の案内を下書きする

処理の起点を決める

予約フォームの送信を、Webhooks by Zapier の Catch Hook で受けます。 サイトのフォームに、送信のたびに Zap の URL へ送る設定を足します。メールの通知はそのまま残します。 Zap が止まっていても、受付がメールで気づけるようにするためです。

フォームの送り方を、項目に分けた形にします。 Catch Hook は中身を項目に分けて受け取るので、「来店日」「時刻」「人数」「プラン」「言語」「長身の人数」「子どもを含む」「備考」を別々の項目で送るように、サイトの制作会社に頼みます。1つの文章にまとめて送ると、AIに読み分けさせることになり、日時や人数の読み違いが出ます。

大量に届いたときの遅れを知っておきます。 公式のヘルプでは、まとめて届いた要求は遅れることがあるとされています。観光の時期の週末に申込が重なっても、数分の遅れで下書きができれば足ります。

入力データを集める

身長はフォームで区分を選んでもらいます。 1人ずつ数字で書いてもらうと、長身の人数を数える作業が要ります。「〜150cm／150〜170cm／170cm〜」の区分ごとの人数をフォームの側で数えて送る形にします。数えるのをAIに任せると、6人の組で1人数え落とすことがあります。

質を決めるのは、案内の文書です。 プランごとに、当日の流れ、所要時間、着てくる服、持ち物、返却の時刻、雨の日の扱いを、同じ見出しで書いておきます。英語版も同じ見出しにします。見出しがそろっていれば、AIはプランが変わっても同じ並びで案内を書きます。

プランの名前は、フォームと文書で同じ書き方にします。 フォームが「散策プラン」、文書が「街歩きプラン」だと、AIはどの文書の記載を使うかを推し量ります。プランごとに短い記号（例：WALK、FORMAL、HAKAMA）を決め、フォームの値と文書の見出しの両方に入れます。

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

日時の鍵は、日付と時刻をつないだ1つの文字列にします。 来店日と時刻を別々に探すと、2つの条件で引くことになり、設定を誤りやすくなります。「2026-11-07_10:00」のように1つの鍵にし、ぴったり一致で引きます。

着付けに1枠を超える時間がかかる組を考えます。 6人の組は、席が6つあっても、ヘアセットを含めると次の枠にかかります。枠の表に「この人数を超える組は担当へ」という値を持たせ、超える組は案内を作らず担当に回します。複数の枠にまたがる計算を Zap に持たせないためです。

AIへ渡す前に整形する

1. 子どもを含むかの確認（Paths） … 子どもの着付けを含む申込は、担当に知らせてその分岐で終えます
2. 日時の確かめ … 来店日が過去、または受付の期間（例：3か月先まで）の外なら担当へ回します
3. 枠の空きの計算（Formatter） … 定員 − 予約済み − 人数 を出します
4. 長身用の計算（Formatter） … 長身の人数が1以上なら、その日の残り − 長身の人数 を出します
5. 分岐（Paths） … どちらかが0未満、または組の人数が上限を超えれば担当へ回します
6. 備考の確かめ（AI ①） … 配慮の要る事柄を拾い、あれば担当へ回します

1番目を、AIのステップより前に置くことが大事です。 最初の Paths で分け、子どもを含む分岐にはAIのステップを置きません。子どもを含む申込は、名前も身長もAIに渡らないまま担当に届きます。

6番目を、枠と在庫の確認の後に置くのは、AIのステップの数を減らすためです。 枠が足りずに担当へ回す申込まで、AIに備考を読ませる理由はありません。

Paths の入れ子の深さに気を付けます。 公式のヘルプでは、1つの Zap に入れ子にできる Paths は3段までです。この構成は、子どもを含むか（1段目）、枠と在庫が足りるか（2段目）、配慮の要る事柄があるか（3段目）で、ちょうど3段を使います。 4つ目の分岐を足したくなったら、同じ段の分岐を増やすか、Zap を2本に分けます。

分岐の条件は互いに重ならないように書きます。 公式のヘルプでは、Paths の分岐は左から順に評価され、条件に合う分岐はすべて動きます。 「枠が足りない」と「長身用が足りない」を別々の分岐にすると、両方が足りない申込で担当への知らせが2通届きます。「枠が足りない、または長身用が足りない」を1つの分岐にし、どちらが足りないかは知らせの本文に書きます。

AIに処理させる

2つのステップに分けます。 ①は備考からの拾い出し、②は事前の案内の文面です。

①は拾うだけで、受けられるかは判断させません。 「妊娠5か月」とあれば body_condition として拾い、原文を写して担当に回します。 着付けの仕方を変えるか、受けるかは、着付け師と担当が決めます。

②は、案内の文書に書かれたことだけで組み立てさせます。 返却の時刻、所要時間、雨の日の扱いは、プランごとの文書の値を写します。

4行目がいちばん起きやすい失敗です。 「10時来店、返却は当日17時まで」というプランで、AIは来店の時刻から「7時間後の17時」と計算し直し、来店が11時だと「18時」と書きます。 返却の時刻はプランで決まっているので、計算させずに写させます。

指示内容を固定する

案内の文面を作るステップ（②）の指示に、次のように書きます。

あなたは着物レンタル店の予約の受付として、予約の申込をいただいた方への
事前の案内の下書きを作ります。送る前に担当が読みます。

【入力】
- 言語：{language}（ja または en）
- 来店日と時刻：{date} {time}
- 人数：{headcount}名
- プラン：{plan}
- ヘアセット：{hair}
- 知識の元：プランごとの案内の文書（日本語版と英語版）

【本文の組み立て】
1. お礼を1文。
2. 申込の内容（来店日と時刻、人数、プラン）を箇条書きで復唱。
3. 当日の流れと所要時間を、案内の文書のそのプランの記載から。
4. 着てくる服と持ち物を、案内の文書のそのプランの記載から箇条書きで。
5. 返却の時刻を、案内の文書のそのプランの記載のまま。
6. 雨の日の扱いとキャンセルの決まりを、案内の文書の記載から1〜2文。
7. 内容に誤りがあれば返信で知らせてほしいことを1文。

【厳守事項】
- {language} が en なら英語版の文書だけを、ja なら日本語版だけを使ってください。
- 返却の時刻を来店の時刻から計算しないでください。
  案内の文書のそのプランの記載をそのまま写してください。
- 案内の文書に無い時刻、料金、サービスを書かないでください。
- 「ご予約が確定しました」とは書かず、「ご予約を承りました。
  内容をご確認ください」と書いてください。
- 着物の柄や色の提案をしないでください。
- 本文は日本語なら600字、英語なら250語程度。署名は入れないでください。

備考を読むステップ（①）の指示は、次のように短くします。

予約の申込の備考を読み、担当が事前に確かめるべき事柄を拾ってください。

【備考】{notes}

- 体の事情（妊娠、けが、持病、車いす、杖など）は body_condition に。
- 自分の着物や帯の持ち込みは bring_own に。
- 遅れる見込み、時刻の変更の希望は timing に。
- プランに無い頼みごと（出張の着付け、撮影の手配など）は special_request に。
- それぞれ quote に備考の原文をそのまま写してください。
- 受けられるか、どう対応するかは書かないでください。
- 当てはまる事柄が無ければ、空の一覧を返してください。

「返却の時刻を計算しない」を、文書から写す指示と並べて書きます。 写すように言うだけでは、来店の時刻を見て親切に直します。計算そのものを禁じます。

「ご予約が確定しました」を禁じるのは、担当の確認の前に下書きができるからです。 担当が枠の表を見直して時刻をずらすことがあります。「承りました。内容をご確認ください」なら、担当が直しても文の意味が崩れません。

①の「対応を書かない」も効きます。 書かないと、「妊娠中の方には帯をゆるめに着付けますのでご安心ください」と店がしていない約束を書きます。

出力形式を固定する

①の拾い出しは、AI by Zapier の出力項目で次の形に決めます。

{
  "notes_language": "ja | en | other",
  "flags": [
    { "type": "body_condition | bring_own | timing | special_request",
      "quote": "妊娠5か月です" }
  ],
  "has_flags": true
}

1つ目の理由は、has_flags を Paths の条件にそのまま使えることです。 真偽で返させるので、「配慮が要るかもしれません」のような文で分岐が揺れません。

2つ目は、quote で担当がすぐ読めることです。 担当への知らせのメールに、種類と原文を並べます。申込を開き直さずに、電話で何を聞くかが分かります。

3つ目は、notes_language で英語以外の備考を拾えることです。 フォームの言語は日本語と英語ですが、備考が中国語や韓国語で書かれることがあります。 other のときは担当に回し、AIに訳させません。

②の案内は、件名を付けずに本文だけを返させます。件名は Zap の側で「【ご予約の内容のご確認】11月7日 10:00 3名様」のように、申込の項目から組み立てます。 件名の日時をAIに書かせると、本文と件名で日時が食い違うことがあります。

システムへ連携する

枠の表は、下書きを作る前に更新します。 担当が送るまで待つと、その間に届いた次の申込が同じ空きを使います。受けられると決めた時点で予約済みを足し、 担当が断ると決めたら、担当が表の数を戻します。戻した記録は申込の記録に残します。

Gmail は、お客様あてを Create Draft、担当あてを Send Email と分けます。 Zapier の Gmail のページでは、Create Draft は件名と本文を必須とする下書きの作成です。宛先にお客様のメールを差し込むステップでは、送る操作を使いません。

人が確認する

担当が、すべての下書きを読んでから送ります。

1. 復唱の内容を申込と見比べる … 日時、人数、プランが申込と同じかを見ます
2. 返却の時刻を確かめる … プランの返却の時刻が、案内の文書のとおりかを見ます
3. 持ち物と服装を確かめる … プランに合った内容か（袴なら履物、参列なら長襦袢の扱いなど）を見ます
4. 送る … 送ったら、申込の記録に送った日時を書きます
5. 担当に回った申込に返事をする … 枠が足りない申込には近い時刻を、配慮の要る申込には電話か返信で話を聞きます

2番目を必ず見ます。 返却の時刻の誤りは、夕方に返しに来たお客様と、延長の料金でもめる形で表に出ます。

4番目の「送ったら記録に書く」を省くと、送り忘れが分かりません。 下書きは Gmail の下書きのフォルダにたまるだけで、送っていない申込を知らせる仕組みはありません。 毎朝、申込の記録で「下書きあり・送信なし」の行を数え、前日の分が残っていないかを見ます。

目標は、600件をならして1件2分です。 下書きを読んで送るのに1〜2分、担当に回った申込は近い時刻を探したり電話をしたりで5分以上かかります。担当に回るのは全体の1〜2割という想定です。

例外に対処する

上から2行目は、観光の時期に多く出ます。 近い時刻を探すには、前後の枠の空きを何度も引くことになり、Zap が長く複雑になります。 担当が表を見て探すほうが確実です。

最後の行で、枠の更新を先に済ませていることが効きます。 案内の下書きが作れなくても、枠は押さえてあるので、同じ時刻に別の申込が入りません。

記録を残す

• 申込の記録（申込の番号、受けた日時、判定、担当に回した理由）
• 枠と在庫の計算の結果（そのときの定員、予約済み、残り）
• 備考の拾い出しの結果（種類と原文）
• 下書きを作った日時と、担当が送った日時
• 担当が表の数を戻した記録 … 断った申込と、戻した数
• 担当が下書きで直した箇所

5つ目は、表の数がずれたときに追うための記録です。 予約済みの数と実際の予約が合わないとき、どの申込で足し、どの申込で戻したかをたどれます。

6つ目は、案内の文書を直す材料になります。 同じプランで担当が毎回同じ箇所を直しているなら、直すべきは文書の書き方です。