楽器店が修理の依頼を Make で受け、楽器の種類と症状を見分けて、店の工房と外部の修理先へ振り分け、預かる前に確かめることをそろえる

処理の起点を決める

修理受付フォームの送信を起点にします。 フォームの送信先を Make のカスタムの Webhook のURLにし、1件ずつシナリオを動かします。修理の依頼は、返事が早いほど他の店に流れません。 まとめて処理する理由がないので、届いたらすぐ動かします。

受付番号は Webhook response のモジュールで返し、フォームの完了画面に出します。 お客様が電話で問い合わせてきたときに、受付番号で台帳を引けます。ただし、途中に置くと後のモジュールのエラーでシナリオが止まらなくなるとされているので、エラーの通知は別に設けます。

同じお客様が送信を二度押すことがあります。 即時の Webhook は既定で並行して動くので、連絡先と送信の時刻で台帳を引き、5分以内の同じ依頼は1件にまとめます。

入力データを集める

質を決めるのは、振り分けの表です。 職人がこれまで頭の中で決めていた「この楽器のこの症状はここ」を、表に書き出します。最初は、過去半年の受付台帳から回し先ごとに多い組み合わせを拾い、職人と30分ほどで埋めます。

修理先の一覧の「受けない楽器」の列も大事です。 提携の管楽器工房でも、古い楽器や特定のメーカーは受けないことがあります。表で回し先が決まっても、この列に当たれば要相談に回します。

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

写真は、URLのまま Responses API に渡します。 画像入力は input_image で、完全なURL、Base64 のデータURL、Files API に上げたファイルのIDのどれかで渡せます。フォームの保管先が期限付きのURLを出せるなら、それがいちばん手軽です。 期限は、シナリオが終わるまでの数分で足ります。

Make a request の本文は「Data structure」で組みます。 JSON の予約文字が自動でエスケープされるので、症状の文に引用符や改行があっても壊れません。「Return error if HTTP request fails」を有効にし、4xx・5xx で止めて通知します。

AIへ渡す前に整形する

1. 写真の形式の確認 … 画像入力が受けるのは PNG・JPEG・WEBP・アニメーションでない GIF です。スマートフォンの HEIC はフォームの側で JPEG にするか、受けられない旨を出します
2. 写真の枚数の確認 … 0枚なら文だけで区分させ、確信を下げる前提で扱います
3. 型番の表記をそろえる … 全角を半角に、空白とハイフンの揺れを落とします
4. 購入時期を日付にする … 「去年の春」のようにあいまいなものは日付にせず、そのまま渡します
5. AIに渡す範囲を絞る … 名前・連絡先・住所は渡しません。渡すのは楽器の種類の選択、メーカー・型番、症状の文、写真だけです
6. 重複の確認 … 連絡先と送信の時刻で台帳を引き、二重の送信をまとめます

4番目で日付にしないのは、保証の印を表の式で付けるからです。 「去年の春」を日付に直すと、それだけで保証の期間内かが決まってしまいます。あいまいなものは「保証の確認が要る」として、お客様に保証書の有無を聞きます。

AIに処理させる

させるのは、依頼の文と写真から次の区分を選ぶことだけです。 どれも、表で回し先を引くための鍵です。

楽器の種類で「エレアコ」を分けているのが、第2章の選び間違いへの答えです。 アコースティックギターでも、ピックアップが付いていれば配線の症状が起きます。写真に出力端子が写っているか、文に「アンプにつなぐと」とあるかで見分けさせます。

「割れ」を症状とは別に聞くのは、文に書かれないことが多いからです。 お客様は「音がビビる」と書き、割れには気づいていないことがあります。写真に割れが見えれば、症状の区分が何であれ担当者に回します。 割れは修理先と費用を大きく変えるからです。

2行目がいちばん起きやすい失敗です。 何も言わなければ、AIは「タンポの交換で直る見込みです」と書きます。その一文がお客様への返事に混ざると、職人が見る前に修理の内容を約束したことになります。

指示内容を固定する

あなたは楽器店の修理受付で、届いた依頼を区分に分ける立場です。
依頼の文と写真だけを見て、決めた区分から選んでください。

【楽器の種類】instrument から1つ選ぶ
- お客様が選んだ種類（customer_choice）は参考にとどめ、
  文と写真から見立ててください。
- アコースティックギターでも、出力端子やピックアップが写っている、
  または文に「アンプ」「ライン」とあれば acoustic_electric にしてください。
- 電子ピアノ・キーボードとアコースティックピアノは、
  写真の形と文から分けてください。分けられなければ unknown です。

【症状】symptom から1つ選ぶ。複数あるときは、お客様が一番困っているものを選び、
  ほかは other_symptoms に区分で並べてください。

【電気まわり】electrical：電源・電池・配線・ピックアップ・ジャックの症状なら yes
【割れ】crack：写真か文に、割れ・ひび・剥がれが見えれば yes。
  文に書かれていなくても、写真に見えれば yes にしてください。
  写真が無い、または見えにくいときは unclear です。

【確信の度合い】confidence：high / medium / low
- 写真が無い、文が短い、型番が無いときは high にしないでください。

【厳守事項】
- 修理の方法、直るかどうか、費用、期間を書かないでください。
- どこに回すかを書かないでください。
- 型番から年式や仕様を推測しないでください。
- 保証の期間内かどうかを判断しないでください。
- evidence には、区分の根拠にした文をそのまま写すか、
  写真の何を見たかを短く書いてください（例：「2枚目、ボディのくびれ付近に線状のひび」）。
- 修理の依頼ではない内容（買取・購入の相談・苦情など）なら、
  区分をせず request_type にその種類を書いてください。
- 確かめたいことがあれば、お客様に聞く形で questions に並べてください。
  ただし、聞くのは型番・購入時期・症状の出る場面・写真の撮り直しに限ります。

【依頼】{request}
【お客様が選んだ種類】{customer_choice}
【写真】（input_image で添付）

「どこに回すかを書かない」を明記しないと、AIは親切に回し先を書きます。 書かれた回し先が表と違えば、担当者はどちらを信じるかで迷います。AIの出力に回し先の欄そのものを置かないのは、そのためです。

questions の範囲を絞っているのは、聞きすぎを防ぐためです。 制限しないと「普段どのくらい弾きますか」「保管の環境は」まで聞き、お客様の返事が遅れます。

出力形式を固定する

Responses API の text.format に JSON スキーマを渡し、strict: true で次の形を受け取ります。

{
  "request_type": "repair",
  "instrument": "electric_guitar | acoustic_guitar | acoustic_electric | bass | woodwind | brass | violin_family | acoustic_piano | digital_piano | synthesizer | drums | other | unknown",
  "symptom": "setup | frets | wood_crack | wiring_noise | pads_keys | dent_stuck | keyboard_action | power_board | cosmetic | other | unknown",
  "other_symptoms": [""],
  "electrical": "yes | no | unclear",
  "crack": "yes | no | unclear",
  "mismatch_with_customer_choice": true,
  "confidence": "high | medium | low",
  "evidence": [""],
  "questions": [""]
}

1つ目の理由は、区分を表の鍵として使えることです。 instrument と symptom の組で振り分けの表を Search Rows で引けば、回し先と預かりの店が決まります。自由文で「サックスのキィの不調」と返されても、表は引けません。

2つ目は、担当者に回す条件をルーターで書けることです。

スキーマで気をつけることがあります。 構造化出力では、すべての項目を required にし、オブジェクトに additionalProperties: false を付ける必要があります。項目を任意にしたいときは、型を null との組み合わせにします。 スキーマの enum の値は全体で1,000個までで、この記事の区分は十分に収まります。新しいスキーマの最初の呼び出しは時間がかかるとされているので、試すときはそれを見込みます。

システムへ連携する

振り分けの表には書き込みません。 回し先を変えるのは職人と担当者で、シナリオは読むだけです。表を書き換える権限を持つ人を2〜3名に絞ります。

修理先への引き継ぎの票は、回し先ごとに項目を変えます。 修理先の一覧の「引き継ぎに要る項目」の列を読み、その項目だけを台帳から埋めます。

票の項目が欠けていれば、それがそのまま「お客様に確かめること」になります。 たとえばメーカーへ回す依頼で製造番号が無ければ、questions の下書きに「本体の裏のラベルの番号を写真でお送りください」を足します。修理先から聞き返される前に、受付の段階で埋めるための仕組みです。

人が確認する

担当者が開くのは、第7章の出力形式の表で「担当者が確かめる」になったものだけです。 店の工房へ回す、確信の高い依頼は、一覧で区分と回し先を流し見て返信します。

1. 割れの印があるものを先に見る … 写真を開き、割れが本当に見えるかを確かめます
2. 外へ出すものの回し先を確かめる … 型番と症状の文を読み、表の回し先でよいかを見ます
3. 確かめることを直して送る … questions の下書きを整え、発送の場合は梱包の注意を足します
4. 要相談は職人に回す … 職人には、区分と写真と evidence をまとめて見せます
5. 区分を直したら記録する … どの区分を、どれに変えたかを残します

5番目の記録は、振り分けの表を育てる材料です。 同じ組み合わせで何度も直すなら、表の行が足りていません。

目標は、300件をならして1件3分です。 外へ出すもの・迷ったものは4割前後という想定です。

例外に対処する

1行目は、思ったより多く起きます。 スマートフォンで撮った写真をそのまま上げてもらう形のため、フォームの側の変換があるかどうかで、写真を使える依頼の割合が大きく変わります。

記録を残す

• 依頼の全項目と受付番号、受け付けた時刻
• 写真（店のファイルの保管先に。AIへの受け渡しはURLだけ）
• AIの区分の JSON の全文と、プロンプトの版
• 振り分けの表で引いた回し先と、そのときの表の版
• 担当者が直した区分と回し先、職人に回した記録
• 修理先から差し戻された記録（回し先の間違い・確認の不足）

最後の行が、この構成の成績表です。 回し先の間違いで差し戻された件数が減っていれば、表とAIの区分が合っています。Make の実行の記録は3日（Enterprise は30日）しか残らないので、台帳の側に残します。