運転代行の事業者が Web・LINE の予約を Make で受け、迎えの場所・行き先・車種を整えて配車の候補と料金の目安を出す

処理の起点を決める

自社サイトの予約フォームの送信と、LINE の公式アカウントに届いたメッセージの2つを起点にします。 どちらも即時に動かします。運転代行の依頼は「いま店を出たい」が多く、15分おきの見回りでは間に合いません。

LINE の依頼には、AIを呼ぶ前に受付の知らせを返します。 LINE の Messaging API の公式のリファレンスでは、応答メッセージに使う応答トークンは1回しか使えず、Webhook を受けてから1分以内に使う必要があり、1分を超えると動く保証は無いとされています。AIの呼び出しと台帳の読み書きを先にすると1分を超えるおそれがあるので、シナリオの最初で「受け付けました。配車係から料金の目安と到着の目安をお送りします」という決まった文を返します。 応答メッセージは、公式の料金のページでメッセージ数に数えない送り方とされています。

料金の目安と配車の返事は、配車係が台帳で「送る」に印を付けたときに送ります。 台帳の印は Google Sheets の Watch Changes で拾います。公式のページでは、Watch Changes は Google スプレッドシートの画面で人が編集した変更だけを拾い、スクリプトや API での変更、新しく足された行は拾わないとされています。配車係が画面で印を付ける運用に合います。この返事はプッシュメッセージで送り、メッセージ数に数えられます。

入力データを集める

質を決めるのは、区域の表の「主な店・ホテルの名前」の列です。 依頼の多くは住所ではなく、「〇〇駅前の△△（店名）」で迎えの場所を書きます。取次ぎの多い店とホテルを区域の表に載せておくと、AIは店名から区域の候補を挙げられます。 載っていない店は候補が出ず、配車係へ回ります。

境の町の扱いも、表に書いておきます。 同じ町名でも、国道の東と西で区域が違う町があります。「境の町」の印のある町は、AIに区域を選ばせず、配車係へ回します。

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

LINE の依頼は、1つの依頼が何通かに分かれて届きます。 「今から迎えお願いします」「〇〇駅前です」「行き先は△△町」と3通に分かれることがよくあります。同じユーザーの ID から5分以内に届いたメッセージは、受付台帳の同じ行にまとめ、最後の1通から1分待っても続きが無ければ AI を呼びます。 1通ずつ AI を呼ぶと、行き先の無い依頼として聞き返してしまいます。

班の待機の表は、班が無線で知らせたことを配車係が書き込んで保っています。 シナリオは表を読むだけで、班の状態を書き換えません。

AIへ渡す前に整形する

1. 重複の確認 … フォームは送信の時刻と電話番号、LINE はユーザーの ID と受信の時刻で受付台帳を引きます
2. 分かれたメッセージをまとめる … 同じユーザーの ID の5分以内のメッセージを1つの依頼にします
3. 依頼した人の立場の印 … LINE のユーザーの ID が「取次ぎの店」の一覧にあれば、店からの依頼の印を付けます
4. AIに渡す範囲を絞る … 電話番号と LINE のユーザーの ID は渡しません。行き先の住所は、番地より後を落として町名までにして渡します
5. 時刻の基準 … 受信の時刻を渡し、「30分後」「いまから」を時刻に直す基準にします

4番目で番地を落とすのは、行き先がたいてい利用者の自宅だからです。 料金の目安を出すのに要るのは区域で、区域を決めるには町名で足ります。番地まで含んだ住所は、受付台帳にだけ残し、班には配車のときに配車係が伝えます。

AIに処理させる

させるのは、依頼の文を取り出すことと、区域の表の候補に結び付けることの2つです。

null を返させるのが、この構成でいちばん大事な決まりです。 「家まで」と書かれた依頼で、同じ人の前回の行き先が分かっていても、行き先を補いません。 引っ越しや、その夜は実家へ帰る、ということがあるからです。書かれていない項目は、返事の下書きで聞き返します。

車種は、とくに推し量らせません。 「軽です」とあればオートマチックの車が多いのは確かですが、AT／MT が書かれていなければ null にし、聞き返します。 マニュアルの車を受けない事業者にとって、ここを推し量ると空振りの原因になります。

指示内容を固定する

あなたは運転代行の事業者の配車係で、Web と LINE で届いた依頼を
受付台帳に起こす担当です。下に渡す依頼の文から項目を取り出し、
区域の表の候補に結び付けてください。
料金、配車する班、到着の時刻は答えないでください。

【取り出す項目】
1. 迎えの場所（pickup）：書かれた場所をそのまま写し、
   区域の表の町名・駅・店・ホテルから区域の番号（zone）を選ぶ。
2. 行き先（destination）：同じく写し、区域の番号を選ぶ。
3. 希望の時刻（time）：受信の時刻を基準に時刻に直す。
   「いまから」「すぐ」は now。「22時ごろ」「宴会が終わったら」の
   ように決められないときは time を空にし、time_text に原文を写す。
4. 車種（vehicle）：車名、AT／MT、業務用か、を書かれたとおりに写す。
5. 同乗の人数（passengers）：運転してもらう人のほかに乗る人数。
6. 依頼した人の立場（requester）：self／venue（店・ホテル）／unknown。

【厳守事項】
- 書かれていない項目は null にする。前回の依頼や一般的な傾向から
  補わない。「家まで」の行き先を補わない。
- AT／MT が書かれていなければ null にする。車名から決めない。
- 区域の表に無い場所は、似た名前の場所に寄せない。zone を空にする。
- 区域の表で「境の町」の印のある町は、zone を空にし boundary を true にする。
- 料金、到着の時刻、配車する班を書かない。
- 酔いの程度や利用者の様子について何も書かない。
- 確かめたいことは questions に、利用者への質問の形で書く。

【区域の表】{zones}
【受信の時刻】{received_at}
【依頼の文】{request}

「前回の依頼から補わない」を書くのは、同じ利用者の依頼を並べて渡すと、AIが前回の行き先で埋めようとするからです。 この構成では直近の依頼は AI に渡さず、配車係の画面にだけ並べます。それでも指示に書いておくのは、依頼の文の中に「いつもの所まで」と書かれることがあるからです。

出力形式を固定する

次の形の JSON を返させます。

{
  "request_id": "",
  "requester": "self | venue | unknown",
  "pickup": { "text": "駅前の焼き鳥〇〇", "zone": "Z03", "boundary": false },
  "destination": { "text": "△△町", "zone": null, "boundary": true },
  "time": "",
  "time_text": "宴会が終わったら",
  "vehicle": { "text": "軽", "transmission": null, "commercial": null },
  "passengers": 1,
  "questions": ["お車はオートマチックでしょうか。", "お迎えのご希望の時刻を教えてください。"]
}

1つ目の理由は、取り出しと料金・配車を別の層に置けることです。 料金の目安は、pickup.zone と destination.zone で料金の表を引き、時刻で深夜の加算を足してワークフローが出します。振り分けの規則は次のとおりです。

2つ目は、数の確かめをワークフローで行えることです。 同乗の人数が車の定員から1を引いた数を超えないかは、Make の式で確かめます。公式のページでは、構造化出力は数値の minimum・maximum のような制約に対応せず、使うと 400 のエラーになるとされているので、範囲はスキーマに書きません。

3つ目は、選んだ値の照らし方を決めておけることです。 公式のページでは、文字列の enum の大文字・小文字までは保証されないとされています。ルーターで比べる前に、requester を小文字にそろえます。

返事の下書きは、AIの JSON とワークフローの計算から、決まった型に差し込んで作ります。 例えば次のような形です。

【受付の内容】
お迎え：駅前の焼き鳥〇〇（区域3）
行き先：△△町
料金の目安：（配車係が区域を確かめてから入ります）

【お伺いしたいこと】
・お車はオートマチックでしょうか。
・お迎えのご希望の時刻を教えてください。

料金は当社サイトに掲示している料金表によります。
到着した運転者から、料金とご利用の条件をご説明します。

料金の目安の欄は、区域が決まったときだけ数字が入ります。 境の町や区域の表に無い場所のときは、配車係が区域を決めてから数字を入れます。AIに返事の文章そのものを書かせないのは、料金や到着の時刻を文中に書き足すのを防ぐためです。

システムへ連携する

ルーターのルートは、配車係がすぐ見る→聞き返し→そのまま案内できる→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。受けない車の依頼が、料金の目安を添えた案内のルートまで流れないように、配車係がすぐ見るルートを先頭に置きます。

返事の下書きには、料金の目安と一緒に、料金を掲示している自社サイトの場所を書きます。 自動車運転代行業の業務の適正化に関する法律は、事業者が料金を定めて営業所に掲示し公衆の閲覧に供すること、代行運転を提供しようとするときに、利用者が受けようとする内容を確かめたうえで料金や約款の概要などの条件を説明することを定めています。返事の目安は説明の代わりではなく、到着した運転する人が条件を説明します。

人が確認する

配車係が、すべての返事を確かめてから送ります。 送るのは配車係が台帳で「送る」に印を付けたときだけです。

1. 配車係がすぐ見る依頼を先に見る … 受けない車、区域の外、境の町、本人の連絡先が無い店からの依頼です。店からの依頼は、店に本人の名前と連絡先を聞き返します
2. 聞き返しの下書きを確かめる … questions が依頼の文に合っているかを見ます。AT／MT の聞き返しは必ず残します
3. 班を選ぶ … 候補の班の様子を無線で確かめて選び、到着の目安を下書きに書き足します
4. 料金の目安を確かめる … 区域の組み合わせが依頼の文と合っているかを見ます
5. 送る … 台帳の「送る」に印を付けます

店からの依頼は、とくに丁寧に見ます。 依頼した人と乗る人が違うので、到着したときに誰の車かが分かる手がかり（名前・車の色・ナンバーの下4桁）を、店に聞き返してから配車します。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、LINE の使われ方と区域の表の整え方の問題です。 区域の表に無い店が多い週は、取次ぎの多い店から表に書き足します。

記録を残す

• 依頼の元の項目と LINE のメッセージの本文（まとめる前の1通ずつ）
• 返ってきた JSON の全文と stop_reason
• ワークフローが出した料金の目安と、そのときの料金の表の版
• 配車係が選んだ班と、候補に並んでいた班
• 送った返事の本文と送った時刻、配車係が直した箇所
• 苦情や料金の行き違いがあったときの記録

3つ目で料金の表の版を残すのは、料金を改定した月に「前と言われた額が違う」と言われたときのためです。 同法は、苦情の処理に関する帳簿などを営業所ごとに備え付けることも定めています。行き違いの記録は、この構成のログとは別に、苦情の帳簿にも人が書きます。