自転車店が修理の予約と問い合わせを Make で受け、AI で症状を作業の種類に分けて所要時間と概算を出し、作業台の空きから予約の枠を返す

処理の起点を決める

修理予約フォームの送信と、代表アドレスへの依頼のメールの2つを起点にします。 フォームは送信のたびに Make の Custom webhook の URL へ項目を送ります。メールは Gmail の Watch emails で、「修理の依頼」のラベルを見張ります。ラベルは Gmail のフィルタで、件名や本文に「修理」「パンク」「ブレーキ」などが含まれるものに付けます。

フォームは即時、メールは10分おきにします。 フォームから予約する人は、その場で予約が取れたかを知りたい人です。営業時間外の送信でも、仮の予約と返事が出ている状態にします。

Webhook には待ち行列があり、上限を超えた分は受け取りません。 公式のページでは、即時に処理されなかったデータは待ち行列にため、その上限は契約のクレジット1万ごとに667件、最大1万件です。シナリオを止めるときは、フォームの側に予約の停止を出します。

入力データを集める

質を決めるのは、作業メニュー表の種類の分け方です。 例えば次のような表です。

diagnosis を種類の1つとして持つのが大事な点です。 症状から作業を決められないときの行き先が無いと、AIは近い作業に当てはめます。 点検の枠に来てもらい、実車を見てから作業の時間を決めます。

ブレーキの種類を自動で受けないのは、乗って持ってくると危ないからです。 返事に「乗らずに押してお持ちください」を書き添えたうえで、店頭のスタッフが内容を確かめてから送ります。

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

Free/Busy の問い合わせには、timeZone に Asia/Tokyo を入れます。 Google Calendar API の公式のページでは、timeZone は応答に使うタイムゾーンで、省略すると UTC になるとされています。営業時間の10時〜19時と比べる段で9時間ずれ、閉店後の時間に予約を入れてしまいます。 timeMin と timeMax も +09:00 を付けて渡します。

空き時間の計算は、ワークフローの式で行います。 作業台ごとに、予約に使ってよい時間（例：10時〜12時と14時〜17時）から busy の時間帯を引き、合計の作業時間が続けて取れる時間の始まりを候補にします。 30分刻みで見ます。

AIへ渡す前に整形する

1. 重複の確認 … フォームは送信の時刻とメールアドレス、メールはメッセージIDで受付の記録を引き、記録があれば止めます
2. 返信の引用を落とす … メールの返信では、前の返事の全文が下に付いてきます。引用の部分を落とします
3. 自転車の種類をコードにする … フォームの選択肢（街の自転車・子ども用・スポーツ自転車・電動アシスト）をコードに置き換えます
4. 前回の修理を添える … 同じ人の直近の修理の種類と日付を添えます。先月チューブを替えた人のパンクは、タイヤの傷みを疑う材料になります
5. AIに渡す範囲を絞る … 名前、電話番号、メールアドレスは渡しません

4番目は、AIに作業を決めさせるためではなく、整備士に回す材料です。 前回と同じ症状がすぐにまた出ているなら、AIに recurring の印を付けさせ、自動では受けずに整備士へ回します。

AIに処理させる

させるのは、症状の文を作業メニュー表のコードに分類し、印を付けることだけです。

ブレーキの印は「迷えば付ける」にします。 「ブレーキがキーキー鳴る」は音だけのことも、効きが落ちていることもあります。付け過ぎても下書きに回るだけですが、付け漏れると、効かない自転車に乗って来るよう案内することになります。 道路交通法は、基準に合う制動装置を備えていないため交通の危険を生じさせるおそれがある自転車の運転を禁じています。

指示内容を固定する

あなたは自転車店の受付として、修理の依頼の症状を、作業メニュー表の
コードに分類します。時間と金額は書かないでください。日時も決めないで
ください。

【すること】
1. work_codes：症状に当てはまる作業のコードを、メニュー表から選ぶ。
   複数の症状があれば複数選ぶ。
   症状から作業を1つに決められないときは diagnosis を選ぶ。
2. brake_issue：ブレーキが効かない・効きが弱い・片方だけ効く・
   レバーが戻らないなど、止まる力に関わる症状があれば true。
   音だけに見えても、効きに触れていそうなら true にする。
3. e_assist_issue：電動アシストのバッテリー・モーター・表示の
   不具合なら true。
4. tire_size：タイヤ交換のとき、依頼に書かれた寸法をそのまま写す。
   書かれていなければ null。
5. recurring：前回の修理と同じ部位の症状なら true。
6. evidence：コードを決めた症状の文を、そのまま写す。

【厳守事項】
- メニュー表に無いコードを作らない。
- 「変な音」「重い」「なんとなく」など、作業を決められない書き方は
  無理に当てはめず diagnosis にする。
- タイヤの寸法を、自転車の種類から推し量らない。
- 部品を替える必要があるかを書かない。
- 作業時間、工賃、部品代、日時を書かない。

【作業メニュー表（コードと作業の名前）】{menu}
【自転車の種類】{bike_type}
【前回の修理】{last_repair}
【症状】{symptom}

メニュー表には、コードと作業の名前だけを渡します。 時間と工賃の列を渡すと、AIは聞かれていなくても「30分ほどで」「2,000円前後」と書きます。 渡さなければ書けません。

「タイヤの寸法を推し量らない」を書くのは、子ども用やスポーツ自転車のタイヤの寸法が一様でないからです。 推し量った寸法で予約を受けると、当日に在庫が合わず、作業台の時間だけが埋まります。

出力形式を固定する

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

{
  "request_id": "",
  "work_codes": ["puncture"],
  "brake_issue": false,
  "e_assist_issue": false,
  "tire_size": null,
  "recurring": false,
  "evidence": "",
  "questions": []
}

work_codes から先は、ワークフローの規則で決めます。

構造化出力にする1つ目の理由は、コードでメニュー表をそのまま引けることです。 work_codes を1つずつ Search Rows に渡せば、時間と工賃が返ります。作業の名前で引くと、「パンク修理」と「パンクの修理」の違いで引けなくなります。

2つ目は、数の扱いをワークフローに残せることです。 公式のページでは、構造化出力は数値の minimum・maximum のような制約に対応しないとされています。時間と金額をスキーマに入れないので、範囲の制約に頼る場面がありません。

3つ目は、値の照らし方を決めておけることです。 公式のページでは、文字列の enum の大文字・小文字は保証されないとされています。コードは小文字にそろえてからメニュー表と比べます。 また、stop_reason が refusal か max_tokens のときは出力がスキーマに合わないことがあるとされているので、JSON を読む前に stop_reason を見ます。

システムへ連携する

ルーターのルートは、整備士へ→下書き→自動→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理されるとされています。電動アシストやブレーキの依頼が、自動のルートまで流れないように、先のルートで拾います。

自動のルートでは、仮の予定を入れてから返事を送ります。 予定の件名に「仮」と種類のコード、説明に概算と症状の文を入れます。予定の作成に失敗したら、返事を送らずに店頭のスタッフへ回します。 下書きのルートでも、希望の日時に取れるときは仮の予定を入れ、下書きを送るまでの間に枠が埋まらないようにします。

返事には、概算が「目安」であることを必ず書きます。 実車を見て部品の交換が要れば、金額は変わります。金額の文は、メニュー表の幅をワークフローが差し込む定型の文にし、AIには書かせません。

人が確認する

店頭のスタッフが確かめるのは、下書きに回ったものです。

1. ブレーキの下書きを先に見る … 「乗らずに押してお持ちください」が入っているかを確かめます。遠方の人には、引き取りの相談を足します
2. 種類の根拠を見る … evidence が症状の文に合っているかを見ます
3. 部品の在庫を見る … チェーンとタイヤは、在庫を確かめてから送ります
4. 送る … Gmail の画面から送り、仮の予定の件名から「仮」を外します

整備士が見るのは、自分に回ってきた依頼だけです。 電動アシストと繰り返しの症状と、作業が3つ以上の依頼です。整備士は作業の合間に、時間の見立てと点検の枠のどちらで受けるかを決めます。

自動で返した分は、閉店後に件数と種類を流し見ます。 作業メニュー表を書き換えた日は、自動のルートを止めて、すべてを下書きにします。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、作業台の空きの持ち方とフォームの欄の作り方の問題です。 寸法の聞き返しが多いなら、フォームに「タイヤの側面に書かれた数字」の欄を足すほうが早く効きます。

記録を残す

• 依頼の元の項目とメールの本文（引用を落とす前のもの）
• 返ってきた JSON の全文と stop_reason
• そのときの作業メニュー表の版と、出した時間と概算
• Free/Busy を引いた日時と、選んだ枠
• 送った返事の本文と、送り方（自動／下書き／整備士へ）
• 当日の実際の作業と時間（整備士が作業の後に記録する）

最後の行が、この構成を育てる材料です。 diagnosis で受けた依頼が実際に何の作業だったか、目安の時間と実際の時間がどれだけ違ったかを、種類ごとに見ます。 ずれの大きい種類は、メニュー表の目安の時間を直します。