家電の出張修理の業者が修理の依頼を Make で受け、AI で型番と症状から故障の型を見立てて持参する部品と作業時間の目安を引き、技術者の空きから訪問の枠を案内する

処理の起点を決める

フォームの送信を Make の Custom webhook で受けた時点で動かします。 公式のページでは、Custom webhook は任意のデータを送れる URL を作るもので、受け取るとすぐシナリオが動くとされています。フォームの送信先をこの URL にし、記入内容を JSON で送ります。

シナリオの設定で「Process data in order」を有効にします。 既定では Webhook で動くシナリオは前の実行を待たずに並行して動くとされています。同じ技術者の同じ空きを、2件の依頼に同時に案内してしまうのを避けるためです。月360件なら、順に処理しても待ちは問題になりません。

Webhook の受信は10秒あたり300件まで、キューの大きさは契約の枠に応じて決まるとされています。依頼のフォームから届く件数では上限に当たりませんが、シナリオを止めたまま5日（120時間）を超えると Webhook が無効になり、410を返すとされているので、止めるときは期間に気をつけます。

入力データを集める

AI に渡すのは、記入内容のうち品目・症状・エラーの表示・設置の場所と、その品目の故障の型の一覧だけです。 依頼者の名前・住所・電話番号は渡しません。故障の型を判定するのに、住所は要りません。

技術者の表は、技能を列で持たせます。 「エアコンの冷媒の作業」「ドラム式の分解」「2階以上の室外機の作業」のように、修理の事例の表の「必要な技能」と同じ言葉で列を作り、技術者ごとに可否を入れます。言葉がそろっていないと、事例の表で引いた技能から技術者を絞れません。 2名での作業が要る型は、事例の表に「2名」と書いておき、空きを2人分そろえて探します。

故障の型の一覧の「よくある書き方の例」が、判定の質を決めます。 「ランプが点滅」「タイマーのランプが光る」「チカチカする」はどれも同じ型を指します。受付の担当が過去に受けた依頼の書き方を、例として型ごとに3〜5個並べます。

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

型番は、表記をそろえてから引きます。 全角と半角、ハイフンの有無、末尾の色の記号（「-W」など）で引けないことが多いので、英数字だけを残した大文字の文字列を、型番の表の検索用の列と照らします。 完全に一致しなければ、先頭の8文字で前方一致を試し、それでも引けなければ「型番の表に無い」とします。

技術者の予定は、空き時間だけを見ます。 Google Calendar API の freebusy の問い合わせは、時刻の範囲とカレンダーの ID を渡すと、予定の入っている時間帯を busy の start と end で返すとされています。応答の既定のタイムゾーンは UTC とされているので、timeZone に Asia/Tokyo を渡します。取った時間帯から、作業時間に移動の30分を足した長さの空きを、Make の側で探します。

移動の時間は、依頼者の住所の区分で変えます。 市内は30分、近郊は45分のように、郵便番号の上3桁から区分を引く表を持たせます。住所そのものは空きの計算にだけ使い、AI には渡しません。 探す範囲は、希望の日があればその日から3日、無ければ受信の翌日から7日とし、午前・午後の希望があればその時間帯に絞ります。1日の最後の枠は、作業が延びても営業の時間を超えないよう、作業時間の目安に30分の余裕を足した長さで見ます。

AIへ渡す前に整形する

1. 型番の表記をそろえる … 英数字だけを残して大文字にします
2. 型番の表を引く … 一致、前方一致の順で引き、引けなければその旨を記録します
3. 品目を確かめる … フォームの品目と型番の表の品目が違えば、型番の表を優先し、違ったことを記録します
4. 危ない症状の言葉を見る … 「焦げ」「煙」「火花」「発火」「感電」「ガス臭い」などがあれば、受付に急ぎで通知します
5. エラーの表示を切り出す … 「H11」「E-3」のような英字と数字の並びを、そのまま値として残します
6. 購入の時期から保証の見込みを計算する … 購入から1年以内なら「メーカーの保証の可能性」と記録します
7. 個人の情報を外す … AI に渡す内容から、名前・住所・電話番号・メールアドレスを外します

4番目は、AI を呼ぶ前に行います。 AI の応答を待たずに、危ない症状の案内だけは先に出せるようにします。AI の判定に、使用をやめてもらう案内を預けません。

6番目で「メーカーの保証の可能性」が出たものは、案内の下書きでメーカーの窓口も紹介します。 保証の範囲かどうかを決めるのはメーカーで、この構成では判断しません。

AIに処理させる

させるのは、記入を読んで故障の型を判定することだけです。

1行目が、この設計の中心です。 AI はメーカーの部品の名前を知っているかのように書けますが、この業者の車に積んでいる部品と、過去にその症状で実際に替えた部品は、修理の事例の表にしかありません。

指示内容を固定する

あなたは家電の出張修理の受付で、修理の依頼の記入を読み、
故障の型を判定する係です。結果は受付の担当と技術者が確かめます。

【判定すること】
1. fault_codes：【故障の型の一覧】から、記入に当てはまる型のコードを最大2つ。
   当てはまる型が無いときは ["unclassified"] にしてください。
2. evidence：判定に使った記入の文を、そのまま写してください。
3. error_display：記入にエラーの表示（英字と数字の並び）があれば、そのまま写してください。
4. questions：型を1つに絞るために依頼者に聞くべきことを、最大3つ。
5. staff_checks：担当に確かめてほしいこと。
   - 焦げ臭い、煙、火花、感電、水が床に広がっている などの記入
   - 設置の場所が高い・狭い、2階以上の室外機 などの記入
   - 記入の品目と症状が合わないところ

【してはいけないこと】
- 部品の名前を書かないでください。
- 作業時間や料金を書かないでください。
- 故障の原因を断定しないでください。「〜の可能性」と書くことも避け、型のコードだけを返してください。
- 修理するか買い替えるかを勧めないでください。
- 記入に無いエラーの表示や症状を補わないでください。
- 一覧に無いコードを作らないでください。

【品目】{product}
【メーカー】{maker}
【記入された症状】{symptom}
【記入されたエラーの表示】{error_text}
【設置の場所】{location}
【故障の型の一覧（コード・説明・よくある書き方の例）】{fault_list}

「可能性と書くことも避ける」まで書いているのには理由があります。 「部品を書かない」だけだと、「基板の不具合の可能性があります」と説明の文の中に部品が入ります。その文が手配の票に写ると、技術者が基板を持って行く判断をしかねません。 返すのはコードだけ、と絞ります。

unclassified を明示するのは、無理に当てはめさせないためです。 一覧に近い型があると、どれかに寄せたくなります。当てはまらない依頼は、現地で診断する枠として扱うほうが安全です。

出力形式を固定する

{
  "fault_codes": ["AC-03"],
  "evidence": "運転ランプが点滅して、送風しか出ない",
  "error_display": "H11",
  "questions": ["室外機のファンは回っていますか"],
  "staff_checks": [
    { "kind": "danger | location | mismatch", "text": "" }
  ]
}

evidence を返させるのは、担当が判定を数秒で確かめられるようにするためです。 記入の全文を読み直さなくても、どの文からその型を選んだかが分かります。根拠の文が記入に無い文なら、判定そのものを疑います。 Make の側で、evidence が記入の症状の欄に含まれているかを文字列で照らし、含まれていなければ担当に回します。

JSON にする1つ目の理由は、コードで表を引けることです。 fault_codes のコードで修理の事例の表を引き、部品・作業時間・技能を取り出します。コードが一覧に無ければ、事例の表は引かずに担当に回します。

2つ目は、ルーターで振り分けられることです。 Make のルーターは、各ルートのフィルターを順に評価し、どれにも当たらないものはフォールバックのルートに流れるとされています。

型が2つ返ってきて作業時間が違うときは、長いほうで枠を取ります。 短いほうで取ると、現地で長いほうだったときに次の訪問に食い込みます。

スキーマでは kind を enum にし、各オブジェクトに additionalProperties: false を付けます。fault_codes が2つまでかは、Make のフィルターで確かめます。

システムへ連携する

技術者のカレンダーには書き込みません。 依頼者が枠を選ぶまで、仮の予定を入れると技術者の1日が埋まって見えます。訪問を入れるのは、依頼者の返事を受けた担当です。

部品の発注もしません。 事例の表で「取り寄せ要」と出た部品は、手配の票に印を付けるだけにし、担当が在庫を見て発注します。

人が確認する

下書きと手配の票は、全件を担当が見ます。

1. 急ぎの通知を先に見る … 危ない症状のものは、電話で使用をやめてもらうよう伝えます
2. 故障の型と根拠の文を見る … evidence を読み、記入と型が合っているかを見ます
3. 部品と取り寄せを見る … 取り寄せ要の部品があれば、届く日より後の枠だけを案内します
4. 保有期間の案内を見る … 過ぎているものは、訪問するかどうかを依頼者に選んでもらう文になっているかを見ます
5. 送る … 送ったら受付の記録に印を付けます

3番目は、AI では分からないことです。 部品が何日で届くかは問屋とメーカーの事情で決まります。届く前の枠を案内すると、1回目が診断だけで終わる出直しが残ります。

目標は、360件をならして1件3分です。 型が1つに決まり、部品が車に積んであるものは、根拠の文と枠を見て送るだけで済みます。手配の票で直した箇所を記録しておくと、事例の表のどこが実態と合っていないかが分かります。

例外に対処する

2行目がいちばん多く起きます。 フォームの型番の欄を必須にしても、「わからない」と書かれることがあります。銘板の場所を品目ごとに図で示したページをフォームに添えると、空欄が減ります。

記録を残す

• 受付の記録に1件1行：受信日時、品目、型番（記入のまま／そろえた後）、型番の表の引け方
• Claude に渡した内容と、返ってきた JSON の全文
• 事例の表から引いた部品・作業時間・技能、保有期間の計算の結果、ルーターの行き先
• 担当が下書きや手配の票を直したか
• 訪問の結果：現地での故障の原因、実際に替えた部品、実際の作業時間、出直しになったか

最後の行が、修理の事例の表を育てます。 訪問の結果を故障の型と並べて月に一度集計すると、事例の表の部品と作業時間を実際の値に合わせて直せます。 AI の判定と現地の原因が食い違った依頼を並べると、故障の型の一覧の「よくある書き方の例」を足すべきところが分かります。