製品の修理依頼フォームの内容から、製品・型番・症状・購入時期・保証の有無を修理受付票にそろえ、保証の見込みと送付方法を案内する返信を下書きする

処理の起点を決める

修理受付のテーブルに新しいレコードが入ったことを起点に、1件ずつ動かします。 フォームの送信の後の動きを「Zap を動かす」にする方法もありますが、テーブルを起点にすれば、受付票の行と Zap の処理が必ず1対1になります。 担当者がテーブルの画面で手で足した依頼（電話で受けたもの）も、同じ流れに乗ります。

夜間や休日に届いた依頼も、届いた時点で処理します。 安全の印の付いた依頼が、翌朝まで誰にも見られずに残らないようにするためです。品質保証の担当への知らせは、休日の当番の連絡先にも届く経路にします。

入力データを集める

質を決めるのは、製品の一覧です。 とくに型番の列は、銘板に書かれている表記のとおりにそろえます。「GT18V」「GT-18V」「ＧＴ－１８Ｖ」のどれで書かれても引けるように、検索に使う列はハイフンと空白を除いた半角の大文字で別に持ちます。

保証期間は月数で持ちます。 「1年」「2年」と書くと、後の計算の式に入れられません。本体と充電池で期間が違う製品は、行を分けます。

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

製品の一覧の検索は、AIが抜き出した型番を検索用の形に直してから行います。 Zapier Tables の検索は、すべての検索の項目に合うレコードだけを見つけるとされています。表記がそろっていないと、合う行があっても見つかりません。見つからなかったときは、型番の候補を受付の担当者が選ぶ流れにします。検索のアクションには見つからないときにレコードを作る設定もありますが、製品の一覧に行を足すのは人の仕事なので、使いません。

保証の終わりの日は、Formatter の Date/Time の Add/Subtract Time で計算します。 入力に購入日を入れ、式の欄に「+24 months」のように保証期間を足す式を入れます。式の欄は「+1 month -2 days」のような書き方を受け付けるとされています。出力の形は、後の比較で使えるよう年月日の形にそろえます。

AIへ渡す前に整形する

1. 製品の種類が「その他」なら、AIに渡さない … 製品の一覧に当てはまらないので、受付票に載せて人に回します
2. 自由記入の欄が空なら、AIに渡さない … 型番・購入時期・症状をすべて missing として、聞き返しの下書きを作ります
3. 全角・半角と改行をそろえる … 型番の英数字は半角にします。日付の書き方は直さず、原文のまま渡します
4. 同じ人からの重複を見る … メールアドレスと製造番号が同じ依頼が直近7日にあれば、受付票に印を付けます

3番目で日付を直さないのは、意図してのことです。 「R7.3」「2025年春」「昨年3月」を前処理の規則で日付にすると、あいまいな購入時期が確かな日付に見えてしまいます。 あいまいかどうかの見分けはAIの区分に任せ、原文を受付票に残します。

AIに処理させる

させるのは、自由記入の欄から6つの項目を書かれたとおりに抜き出し、3つの区分のどれかを付け、根拠にした原文を書き出すことと、安全に関わる言葉の有無を見ることです。

購入時期が年月までのときは、月の1日として計算に回し、受付票に「年月のみ」と印を付けます。 保証の終わりの月に近いものは、後段の比較で人に回します。

2行目がいちばん起きやすい失敗です。 生成AIは「2年くらい前」から受付日の2年前の日付を作りがちで、それが保証の計算に入ると、根拠の無い「保証期間内の見込み」になります。 第3章の（b）を、そのまま機械で繰り返すことになります。

最後の行も外せません。 「少し熱くなる」程度の書き方でも、迷ったら印を付けさせます。印の付けすぎは品質保証の担当が外せば済みますが、付け漏れは取り返しがつきません。

指示内容を固定する

Analyze and Return Data の指示の欄に、次のように書きます。

あなたは電動工具・園芸機器のメーカーで、修理の依頼を受け付ける担当です。
依頼の自由記入の欄を読み、次の項目を書かれたとおりに抜き出してください。
model_no（型番）、serial_no（製造番号）、purchase_date（購入時期）、
shop（購入店）、symptom（症状）、usage（使い方の状況）

【区分の選び方】
- filled .... 値が具体的に書かれており、1つに決まる
- missing ... 書かれていない
- unclear ... 書かれているが、値が1つに決まらない
              （「くらい」「ごろ」「たぶん」、型番の末尾が無い、など）
迷ったときに filled を選ばないでください。

【厳守事項】
- あいまいな購入時期を日付に直さないでください。「2年くらい前」は
  原文のまま value に入れて unclear にしてください。
- 購入時期が年月日または年月で書かれているときだけ、purchase_ymd に
  YYYY-MM-DD の形で入れてください。年月だけのときは日を 01 にし、
  ym_only を true にしてください。それ以外は purchase_ymd を空にしてください。
- 型番を補ったり、似た型番に直したりしないでください。
- 故障の原因、修理の費用、保証の適用について書かないでください。
- evidence には、根拠にした文を自由記入の欄からそのまま写してください。
- 煙、発火、焦げ、異臭、溶けた、異常な発熱、破裂、感電に当たる
  ことが書かれていたら safety_flag を true にしてください。
  迷ったときは true にしてください。
- 修理の依頼でない（使い方の質問、部品の購入、苦情など）と判断したら、
  項目を抜き出さず request_kind に種類を書いてください。

【製品の種類】{product_type}
【保証書の有無】{warranty_card}
【自由記入の欄】{free_text}

「年月日か年月のときだけ purchase_ymd に入れる」が、この指示の要です。 計算に使う日付の項目を、あいまいな値では空のままにさせることで、後段の Formatter に渡る日付は、お客様が書いた日付だけになります。

「迷ったら safety_flag を true」を入れているのは、安全の印の誤りの重さが左右で違うからです。 付けすぎた印は人が外し、付け漏れた印は誰も気づきません。

出力形式を固定する

Analyze and Return Data の出力の項目を、次のように定義します。 見やすさのため JSON の形で示します。

{
  "request_kind": "repair | usage_question | parts | complaint | other",
  "safety_flag": false,
  "items": [
    { "key": "model_no", "value": "", "status": "filled | missing | unclear",
      "evidence": "" }
  ],
  "purchase_ymd": "",
  "ym_only": false,
  "missing_keys": [""],
  "unclear_keys": [""]
}

request_kind と safety_flag は必須の項目にします。

1つ目の理由は、safety_flag と request_kind で最初の分かれ道を決められることです。 Paths は1つのグループに最大10本の分かれ道を持て、どの規則にも当たらないときに動く Fallback を1本置けるとされています。

2つ目は、purchase_ymd から保証の見込みを規則で決められることです。 Formatter で出した保証の終わりの日を、Paths の規則で受付日と比べます。Zapier の規則の種類には、日付が指定の日付より後かを見る (Date/time) After と、前かを見る Before があります。

比較の規則は、保証の終わりの日の前後の日付を使った試しの依頼で、必ず境目を確かめてから使います。 終わりの日の当日をどちらに入れるかは、自社の保証の規定に合わせます。

3つ目は、見込みと送付方法から下書きを組み立てられることです。 文面のテーブルを見込みと送付方法の2つの列で検索し、当てはまる文を並べます。

〇〇様

修理のご依頼をいただき、ありがとうございます。
ご依頼の製品（GT-18V-A コードレス草刈り機）について、ご案内いたします。

【保証について】
ご記入の購入日（2025年3月）から、保証期間内の見込みです。
保証の適用は、製品と保証書を確認したうえで決めさせていただきます。
保証書（購入日と販売店の記載のあるもの）を必ず同梱してください。

【お送りいただく方法】
宅配でお送りください。充電池は本体から外し、同梱しないでください。

「見込み」と「保証書を確認したうえで決める」を、どの文面にも入れます。 受付の段で保証を約束しないことが、第3章の（b）の取り消しを減らします。

システムへ連携する

Gmail は Create Draft までにし、Send Email は使いません。 Zapier の Gmail のアクションには Send Email もありますが、保証の見込みの案内はお客様への約束に近い文面です。 確かめないまま送る経路を、最初から作りません。

人が確認する

1. 安全の印のものを最初に見る … 品質保証の担当が依頼を読み、使用の中止の案内と、社内の製品事故の手順に回すかを決めます。印を外すのも品質保証の担当です
2. 保証の見込みと根拠を見る … 受付票の購入時期の原文と purchase_ymd を見比べ、計算に回った日付がお客様の書いた日付かを確かめます
3. 型番の候補を選ぶ … 製品の一覧が見つからなかった依頼で、候補から選ぶか、お客様に銘板の写真を頼みます
4. 下書きを直して送る … 同梱物と送付方法の案内が製品に合っているかを見ます

2番目が、この構成の要です。 ym_only の印と、保証の終わりの月の近さを見て、迷うものは「判定できない」の文面に差し替えて送ります。

目標は、600件をならして1件3分です。 見込みが出て型番も引けた依頼は1分ほどで送れ、型番の候補を選ぶ依頼や判定できない依頼は数分かかる想定です。

例外に対処する

上の1行目を、受付の順番に並べないでください。 安全に関わる依頼は、修理の受付ではなく製品の安全の問題です。

記録を残す

• 依頼の原文と、送信日時（修理受付のテーブルのレコード）
• AIの出力の全文（項目ごとの値、区分、根拠、安全の印）
• 保証の終わりの日の計算に使った購入日と保証期間
• 下書きの文面と、受付の担当者が送った文面
• 修理センターで決まった保証の適用と、受付の見込みが合っていたか
• 安全の印の付いた依頼と、品質保証の担当の判断

5つ目が、この構成の物差しです。 見込みと結果が食い違った依頼を数えると、直すべきが指示の区分なのか、製品の一覧の保証期間なのか、比較の規則なのかが分かれて見えます。