飲食店の店舗から写真付きで届く設備の故障の連絡を、写真と文面から機器・症状・緊急度に見分けて修理の依頼票にし、業者の手配と進み具合を追う

処理の起点を決める

店舗がフォームを送信したことを起点にします。 社内チャットに流れてくる自由な投稿を拾う形にはしません。写真と機器の場所が必ずそろう入口を1つに決めることが、聞き返しを減らす最初の一手です。

フォームには、写真を最大3枚（全体／症状の箇所／銘板）、機器の場所の選択、一言の文面、連絡先の担当者名を置きます。機器の場所は、設備の台帳の行から作った選択肢にします。「厨房の奥の冷蔵庫（2枚扉）」のように、店舗の人が見て分かる言い方にしておきます。

電話で届いた連絡は、受けた担当者が同じフォームから入れます。 入口を分けると、電話の分だけ依頼票が無い状態になります。

もう一つの起点は、毎朝8時の定時実行です。 こちらは手配した後の追いかけに使い、業者の返事が無い依頼票を拾います。

入力データを集める

質を決めるのは、設備の台帳の「機器の場所」と「保守の契約先」です。 写真から型式が読めても、台帳に型式が無ければ契約先を引けません。 逆に、機器の場所が選択肢で届けば、型式が読めなくても台帳の行が決まります。型式と場所の2つの道で台帳に当てます。

緊急度の規則表は、AIの外に置きます。 「冷蔵・冷凍の機器で、冷えない・霜が異常」は A、「空調の効きが弱い」は夏は A で冬は B、のように、季節と業態で変わる決まりを人が持ちます。

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

生成AIには、その店舗の機器の一覧を選択肢として渡します。 全店舗の台帳を渡すと、写真に似た別の店舗の機器を選ぶことがあります。選べるのは、その店舗にある機器だけにします。

写真は、Webhook で受けたファイルのデータのまま渡します。 Make の OpenAI アプリは画像をURLでもファイルのデータでも受け付けますが、URLで渡すには写真を誰でも見られる場所に置く必要があります。 厨房の写真を公開の場所に置かないため、ファイルのデータで渡す形にします。

過去の依頼票は、同じ機器の30日以内の修理を引きます。 直したばかりの機器がまた止まったなら、前回の業者に連絡して保証の範囲かを確かめるほうが早いからです。

AIへ渡す前に整形する

1. 形式の確認 … 写真が PNG、JPEG、WEBP、GIF のいずれかであることを確かめます。それ以外の形式は店舗に撮り直しを頼みます
2. 枚数の確認 … 1枚も無い連絡は、写真を求める定型文を返します
3. 銘板の写真の有無 … 銘板の写真が無いときは、型式の読み取りを試さず、機器の場所から台帳を引きます
4. 重複の確認 … 同じ店舗・同じ機器の場所で、2時間以内に別の連絡があれば、同じ依頼票にまとめます
5. 営業時間の判定 … 送信が夜間・休日かを付けます。業者の夜間・休日の連絡先を引くのに使います

4番目を入れないと、同じ故障に依頼票が2つできます。 店長が送った後に、社員がもう一度送ることはよくあります。業者に二重に依頼すると、出張の費用が2回かかります。

AIに処理させる

させるのは、写真と文面から見える事実を写し、その店舗の機器の一覧のどれに当たるかを選ぶことまでです。

3行目が、いちばん間違いやすいところです。 銘板の型式は小さな文字で、OpenAI の公式の制限でも小さな文字は苦手とされています。 読めない1文字を似た文字で埋めると、別の型式として台帳に当たり、別の業者に依頼が行きます。 読めない文字は ? のまま残し、照合は機器の場所の側で行います。

2行目と3行目は、とくに厳しく守らせます。 「コンプレッサーの故障と思われます」と依頼票に書くと、業者はその前提で部品を持ってきます。ガスのにおいの連絡に「使用を続けて問題ない」と返すことは、どんな場合も避けます。

指示内容を固定する

あなたは飲食チェーンの本部で、店舗の設備の故障の連絡を受け付ける担当です。
写真と文面に写っている事実だけを書いてください。推測で埋めないでください。

【あなたの仕事】
1. equipment_type を次から1つ選ぶ
   refrigerator / freezer / ice_machine / dishwasher / fryer / stove /
   air_conditioner / plumbing / lighting / other / unknown
2. 下の「この店舗の機器の一覧」から、当てはまる機器の asset_id を選ぶ
3. 銘板の写真があれば、メーカー・型式・製造番号を写す
4. 写真に見える症状と、文面に書かれた症状を、それぞれ別に書く
5. 写真の不備があれば書き、撮り直しの頼み方を1文で書く
6. 写真と文面から分からないことを、店舗への質問にする（最大3問）

【厳守事項】
- 型式・製造番号は、読めた文字だけを写してください。
  読めない文字は ? にしてください。似た文字で補わないでください。
- asset_id は「この店舗の機器の一覧」にあるものだけを選んでください。
  候補が2つ以上あるときは candidates に全部を入れ、asset_id は空にしてください。
- visible_symptoms には、写真に写っているものだけを書いてください。
  音・におい・温度・いつからか は写真からは分からないので書かないでください。
- 故障の原因を書かないでください。「〜の故障と思われます」も書かないでください。
- 緊急度、使い続けてよいか、どの業者に頼むかは書かないでください。
- 文面に「ガス」「焦げくさい」「煙」「漏電」「火花」があれば、
  safety_keywords にその語を写してください。判断はしないでください。
- 店舗への質問は、店舗の人がその場で答えられることだけにしてください。
  （例：表示パネルに出ている文字、庫内の温度計の数字、いつから）

【店舗】{store_name}
【送信日時】{submitted_at}
【店舗が選んだ機器の場所】{location_label}
【文面】{message}
【この店舗の機器の一覧】{asset_list}

「asset_id は一覧にあるものだけ」を書かないと、写真の機器を一般名で答えます。 「2枚扉の業務用冷蔵庫」と返されても、台帳のどの行かが決まらなければ契約先を引けません。

safety_keywords を写させるだけにしているのは、安全の判断を規則の側に置くためです。 語が1つでもあれば、緊急度はAにし、本部の手順で決めた定型文（機器の使用をやめ、ガスの元栓を閉め、ガス会社へ連絡する、など）を店舗に返します。 定型文は衛生と安全の担当が書き、AIには書かせません。

出力形式を固定する

Response Format で JSON schema を選び、次の形で受け取ります。

{
  "request_id": "RQ-2026-1006-031",
  "equipment_type": "refrigerator",
  "asset_id": "",
  "candidates": ["AS-0412", "AS-0413"],
  "nameplate": { "maker": "", "model": "", "serial": "" },
  "visible_symptoms": ["扉のパッキンの下側に霜が厚く付いている"],
  "message_symptoms": ["cooling_weak"],
  "safety_keywords": [],
  "photo_issues": [],
  "retake_request": "",
  "questions_to_store": [
    "庫内の温度計は何度を示していますか",
    "表示パネルに文字や番号は出ていますか"
  ]
}

1つ目の理由は、欠けた項目を作らせないことです。 Structured Outputs は、渡した JSON Schema に必ず沿った応答を返すとされ、必須の欄の抜けや、列挙に無い値を作ることがなくなります。 strict を有効にするときは、すべての欄を必須にし、additionalProperties を false にします。空でよい欄は、null を許す型にします。

2つ目は、AIの出力と規則の結果を分けられることです。 上のJSONに緊急度も業者も無いのは意図してのことです。受け取った後、ワークフローが次の規則で依頼票を仕上げます。

3つ目は、断りの応答を見分けられることです。 安全上の理由でモデルが応じないときは、スキーマに沿わず refusal の欄で返るとされています。その場合は人へ回す扱いにします。

依頼の文面の下書きは、JSONと台帳の値から差し込みで作ります。 生成AIに文面を書かせるのではなく、決まった型に値を入れるだけです。業者が見る項目の順を毎回そろえるためです。

件名：【修理依頼／緊急度A】〇〇店 冷蔵庫（厨房奥・2枚扉）RQ-2026-1006-031

店舗：〇〇店（住所・電話・店舗の担当者名）
機器：業務用冷蔵庫 メーカー〇〇 型式 XX-12?4（銘板の写真で一部判読できず）
台帳の型式：XX-1234（設置2019年／保守契約：契約あり）
店舗からの連絡：冷えが弱い（10月6日 9:12）
写真に見える状態：扉のパッキンの下側に霜が厚く付いている
店舗に確認中の事項：庫内の温度、表示パネルのエラー
前回の修理：なし（30日以内）
添付：写真3枚（全体／症状／銘板）
訪問の可否と予定日時をご返信ください。

「一部判読できず」と台帳の型式を並べて書くのは、業者に判断の材料を渡すためです。 写真の型式と台帳の型式が違えば、業者は訪問の前に確かめられます。本部の側で片方に寄せて書かないことが、二度訪問を防ぎます。

システムへ連携する

設備の台帳には書き込みません。 写真から読んだ型式が台帳と違っていても、台帳を直すのは担当者が業者に確かめてからです。依頼票に「台帳と型式が違う」の印を付けるだけにします。

修理の台帳には、状態の列を1つ持たせます。 写真待ち／店舗回答待ち／送付待ち／業者返事待ち／訪問予定／部品待ち／完了確認待ち／完了 の8つで、毎朝の追いかけはこの列と最後に更新した日時だけを見ます。 「業者返事待ち」のまま緊急度Aで2時間、Bで翌営業日の朝を過ぎたものと、「訪問予定」の日を過ぎても「完了確認待ち」に進んでいないものを拾います。

店舗の回答は、同じ依頼票に戻します。 店舗への質問には依頼票の番号を付けて送り、店舗はチャットの返信かフォームの「回答」の欄で答えます。回答が付いたら状態を「送付待ち」に進め、担当者の一覧に上げます。

人が確認する

人が見るのは、すべての依頼票です。 ただし、見る深さを分けます。

1. 緊急度Aを先に見る … 依頼票と写真を開き、業者に電話で連絡します。安全に関わる語のあったものは、店舗に定型文が届いているかも確かめます
2. 人へ回したものを見る … 候補が複数の機器は店舗の回答を待って決め、写真の不備は撮り直しを待ちます
3. それ以外は下書きを確かめて送る … 機器・契約先・写真の3つが合っていれば、下書きのまま送ります
4. 完了を確かめる … 業者の報告と店舗の確認がそろったら依頼票を閉じ、修理の内容と費用を記録します

3番目で見るのは3つだけです。 文面の言い回しを直す時間は取らない想定で、目標は300件をならして1件5分です。

1番目では、AIの読み取りより店舗の声を優先します。 写真では霜が見えなくても、店長が「庫内が10度を超えている」と答えれば、それが判断の材料です。読み取りと店舗の回答が食い違ったら、店舗の回答で緊急度を見直します。

例外に対処する

上から2行目と3行目が大半です。 銘板は汚れや油で読めないことが多く、機器の場所の選択肢が、型式の読み取りより確実な手がかりになります。

記録を残す

• フォームの送信内容と写真、受け付けた日時
• 生成AIの出力（JSONの全文）と、使ったモデル
• 規則で決めた緊急度・送り先と、そのときの規則表の版
• 依頼票の状態の履歴（作成、送付、業者の返事、訪問、完了）
• 担当者が直した項目（機器・契約先・緊急度）
• 修理の内容と費用、同じ機器の修理の回数

5つ目は、規則表と台帳を直す材料です。 担当者が緊急度を上げた症状が続けば規則表を、契約先を直した機器が続けば台帳を直します。最後の行は、入れ替えの検討に使えます。 同じ機器の修理が年に何度も続けば、修理より入れ替えのほうが安い場合があります。