ペットシッターの事業者が予約のフォームを Make で受け、ペットの情報・鍵の受け渡し・世話の内容を整えて、担当シッターへの指示と確認の連絡を作る

処理の起点を決める

予約のフォームの送信を起点にします。 フォームは送信のたびに、Make のカスタム webhook の URL へ項目を送ります。公式のページでは、即時の webhook は届いた時点でシナリオを動かし、既定では並行して処理するとされています。

この構成では、Process data in order を有効にします。 公式のページでは、これを有効にすると前の実行が終わるまで次を始めないとされています。同じ顧客が予約を送り直したときに、2つの実行が同時に顧客の台帳を書き換えるのを防ぎます。 300件の予約で並行の速さは要りません。

webhook のログは3日間残るとされています。台帳に行を書けなかった予約を後から探せるのは3日までなので、受付の確認の列に「受け取ったが処理できなかった」行を必ず書きます。

入力データを集める

質を決めるのは、前回の世話のカードです。 カードがあれば、「前と同じ」と書かれた予約でも、何が前と同じなのかを項目で示せます。無ければ、「前と同じ」は何も書かれていないのと同じです。 初めての顧客の予約で作ったカードを、次の予約のための材料として残します。

フォームの自由記述の欄の上に、「ごはん・お薬・お散歩・トイレ・気をつけてほしいこと」と見出しの例を置きます。 書き方を縛るのではなく、思い出してもらうための見出しです。

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

顧客の照合は、メールアドレスで行います。 名前で引くと、同じ名前の別の顧客や、家族が代わりに予約した場合に取り違えます。メールアドレスが台帳に無ければ初めての顧客として扱い、似た名前の顧客がいても自動では結び付けません。

HTTP の Make a request は、応答を解析する設定にすると、後のモジュールで項目を選んで使える形になるとされています。抜き出した JSON の項目を、そのまま比較と下書きのモジュールに渡します。

AIへ渡す前に整形する

1. 鍵と防犯の番号の切り離し … キーボックスの番号と警備の解除の番号の欄は、AIへの入力に入れません。鍵の台帳に書いてから、その値をシナリオの後の処理で使わないようにします
2. 自由記述の中の番号の検知 … 自由記述に4桁から8桁ほどの数字の並びがあれば、AIに渡す前に「（番号）」に置き換え、受付の確認の列に印を付けます。飼い主が自由記述に番号を書いてしまうことがあるからです
3. AIに渡す範囲を絞る … 顧客の名前、住所、電話番号は渡しません。ペットの名前と世話の内容だけで抜き出しは足ります
4. 前回のカードの付け足し … リピートなら、前回のカードを「前回の世話」として一緒に渡します
5. 日付の確認 … 訪問の日がすでに過ぎていないか、開始が終了より後になっていないかをワークフローが確かめます
6. 重複の確認 … 同じメールアドレスで同じ日の予約が届いていれば、送り直しとして印を付けます

2番目を省かないでください。 決まった欄で番号を受けていても、自由記述に「キーボックスは玄関の右、番号は〇〇〇〇です」と書く飼い主はいます。置き換える前の自由記述は、鍵の台帳と同じ閲覧の絞られた場所にだけ残します。

AIに処理させる

させるのは、自由記述とペットの欄から、ペットごとの世話の内容と鍵の受け渡しの方法を項目に抜き出すことだけです。

薬の欄を「原文のまま」にするのが、この構成でいちばん大事な決まりです。 「朝晩半錠ずつ」を「1日1錠」と整えると、シッターは朝に1錠を与えます。量と時間は、飼い主が書いた言葉をそのまま指示書に載せます。

4行目がいちばん起きやすい失敗です。 前回のカードを渡しているので、今回の自由記述に散歩の話が無くても、AIは前回のカードから散歩の内容を写したくなります。写させず、not_stated のまま返させ、比較の段で「前回あり・今回記載なし」と出します。 それを飼い主に「前回と同じでよろしいですか」と聞くのが、確認の連絡の役目です。

指示内容を固定する

あなたはペットシッターの事業者の受付の補助です。
飼い主が予約のフォームに書いた自由記述とペットの欄から、ペットごとの
世話の内容と、鍵の受け渡しの方法を項目に抜き出してください。

【厳守事項】
- 自由記述とペットの欄に書かれたことだけを抜き出してください。
- 薬の名前・量・時間・与え方は、自由記述の言葉をそのまま写してください。
  言い換えたり、まとめたり、計算したりしないでください。
- 書かれていない項目は not_stated にしてください。一般的な世話の
  しかたで補わないでください。
- 「前回の世話」は比べるための参考です。今回の自由記述に書かれていない
  ことを、前回の世話から写さないでください。
- 自由記述に「前と同じ」「いつもどおり」とあれば、どの項目について
  そう書かれているかを same_as_last に書いてください。範囲が分から
  なければ same_as_last_scope を unclear にしてください。
- 体調、持病、薬の効き目について、あなたの考えを書かないでください。
- どのペットの話か分からない文は、pet を unknown にしてください。
- 項目ごとに、根拠にした文を evidence にそのまま写してください。
- 「（番号）」と置き換えられた箇所の中身を推し量らないでください。
- 飼い主に確かめたほうがよいことを questions に、飼い主への質問の形で
  書いてください。

【ペットの欄】{pets}
【前回の世話】{last_card}
【自由記述】{free_text}

「前回の世話から写さない」と「same_as_last を書く」を並べているのは、片方だけでは足りないからです。 写させないだけだと、「前と同じ」と書かれた予約がすべて not_stated になり、確認の連絡が質問だらけになります。どの項目が「前と同じ」と言われたのかを返させれば、そこだけ前回のカードの内容を飼い主に示して確かめられます。

「どのペットの話か分からない文は unknown」を入れるのは、多頭飼いの予約で取り違えが起きるからです。 「この子は薬を嫌がります」の「この子」が犬か猫かは、文の前後で決まらないことがあります。

出力形式を固定する

構造化出力で、次の形の JSON を返させます。

{
  "booking_id": "",
  "pets": [
    {
      "pet": "ココ（犬）",
      "food": { "status": "stated", "text": "朝だけ。計量カップ1杯", "evidence": "" },
      "medicine": { "status": "stated", "text": "朝晩半錠ずつ、ちゅーるに混ぜて", "evidence": "" },
      "walk": { "status": "not_stated", "text": "", "evidence": "" },
      "toilet": { "status": "not_stated", "text": "", "evidence": "" },
      "cautions": ["玄関を開けると飛び出すことがある"],
      "same_as_last": ["walk"]
    }
  ],
  "house": ["郵便受けの中を玄関へ"],
  "key": { "method": "keybox | hand | manager | post", "handover_date": "", "return": "not_stated", "evidence": "" },
  "same_as_last_scope": "clear | unclear",
  "questions": ["お散歩は前回と同じく朝夕20分ずつでよろしいですか。"]
}

公式のページでは、構造化出力は output_config.format に type: "json_schema" を指定し、オブジェクトの additionalProperties を false にします。refusal や max_tokens で止まったときは、出力がスキーマに合わないことがあるとされているので、Make の側で stop_reason を見て、end_turn 以外なら受付の確認の列に回します。

1つ目の理由は、前回のカードと項目どうしで比べられることです。 Make の側で、ペットごと・項目ごとに次のように印を付けます。

2つ目は、Router で振り分けられることです。 公式のページでは、Router の道は1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックの道で受けられるとされています。

どの道に入っても、受付の担当の確認を通ります。 道の違いは、確認の列のどの欄に印が付くかと、確認の連絡の下書きにどの質問が入るかです。

3つ目は、指示書と連絡の下書きを同じ項目から作れることです。 指示書には項目と根拠の文を、連絡の下書きには項目と questions を入れます。同じ JSON から作るので、指示書と飼い主への確認の内容が食い違いません。

システムへ連携する

飼い主への連絡は、下書きまでです。 Gmail のアプリには Send an email のモジュールもありますが、使いません。送るのは、受付の担当が下書きを読んでからです。

世話のカードのシートには、飼い主の返事で確定した内容だけを書きます。 抜き出しの段階の内容をカードにすると、次の予約で「前回」として誤った内容が渡ります。

人が確認する

1. 「薬あり」を最初に見る … 指示書の薬の欄が、自由記述の原文と一字も違わないかを見ます
2. 「変更あり」「記載なし」を見る … 確認の連絡の下書きに、その質問が入っているかを確かめます
3. 鍵の取り決めを見る … 受け渡しと返し方の両方が決まっているか。番号は鍵の台帳で確かめ、指示書には書きません
4. 担当シッターを決める … 予定表の候補から、区域・空き・そのペットとの相性で決めます
5. 確認の連絡を送る … 下書きを直して送ります
6. 飼い主の返事で指示書を確定し、世話のカードを更新する

1番目を省かないでください。 薬の量の取り違えは、シッターの訪問の中で取り返しがつきません。原文と指示書を左右に並べて表示し、薬の欄だけは担当が確認の印を押さないと次に進めないようにしておきます。

目標は、300件をならして1件5分です。 印の少ないリピートの予約は2〜3分、薬のある予約と初めての顧客の予約は10分ほどかかる想定です。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、飼い主の書き方の問題です。 フォームの見出しの例と、決まった欄の説明を直すと減ります。

記録を残す

• 予約の項目の全文（鍵と防犯の番号を除く）と、受け取った日時
• 鍵と防犯の番号（閲覧を絞った鍵の台帳にだけ）
• 抜き出しの JSON の全文と、前回のカードとの比較の結果
• 受付の担当が直した記録 … どの項目を、どう直したか
• 飼い主の返事と、確定した世話のカード
• 指示書をシッターへ送った日時

鍵の台帳は、訪問が終わって鍵を返したら番号を消します。 次の予約でまた受け取ります。番号を残し続けると、使わなくなった番号の一覧ができあがります。