ECサイトの注文が入るたびに配送先の番地抜け・建物名の欠け・郵便番号との不一致を見つけ、出荷前に購入者へ確認のメールを送る

処理の起点を決める

Shopify の New Order で、注文が確定するたびに動かします。 即時のトリガーなので、注文から数分以内に判定が終わります。正午の締めの直前に入った注文も、出荷の準備が始まる前に結果が出ます。

1日1回まとめて判定しない理由は、確認の返事を待つ時間です。 午前中にまとめて判定すると、確認のメールが届くのが正午の締めの直前になり、返事を待てずに翌日へ回る注文が増えます。 注文の直後にメールが届けば、購入者がまだ画面の前にいることが多く、その場で返事が来る見込みが高くなります。

注文の取り消し（New Cancelled Order）は、別の Zap で受けます。 取り消された注文が保留の一覧に残っていれば、保留を外して確認メールの返事を待たないようにします。

入力データを集める

質を決めるのは、郵便番号のデータの入れ方です。 日本郵便のページでは、表計算ソフトで開くと郵便番号の先頭の「0」や「00」が表示されない場合があると注意されています。北海道（0から始まる郵便番号）の注文が、すべて「見つからない」になります。郵便番号の列は文字列として取り込み、7桁の数字のまま持たせます。

全国のデータは約12万件あり、一般的な表計算ソフトでは全件を読み込めない場合があるとも書かれています。スプレッドシートに入れるのは、郵便番号・都道府県・市区町村・町域の4列と、後で足す印の列だけにし、読みの列などは落として大きさを抑えます。

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

郵便番号のデータを引くのは、Google Sheets の Lookup Spreadsheet Row の手順です。検索する列（Lookup Column）に郵便番号の列を指定し、注文の郵便番号で行を探します。見つからなかったときの動きは設定で決められます。 行を作る設定にはせず、見つからなかったことを次の手順へ渡します。

この手順で気をつけるのは、1つの郵便番号に町域が複数ある場合です。 Lookup Spreadsheet Row が返すのは見つかった1行で、同じ郵便番号の別の町域の行は返りません。 そのまま町域を比べると、正しい住所を「食い違い」と判定します。データを取り込むときに、郵便番号ごとの行数を数えて「複数」の印の列を作っておき、印のある郵便番号では市区町村までしか比べません。

事業所の個別郵便番号は、会社あての注文で出てきます。 住所のデータで見つからなかったときにだけ、こちらを引きます。両方で見つからなければ、郵便番号そのものの誤りとして扱います。

郵便番号のデータは毎月入れ替えます。 日本郵便は毎月、追加と廃止の差分を公開しています。差分を当てる作業を月初の担当の仕事に入れておかないと、新しい郵便番号の注文が「見つからない」になります。

AIへ渡す前に整形する

1. 郵便番号をそろえる … Formatter で、全角の数字を半角に、ハイフンと空白を除いて7桁にします
2. 7桁でなければ検索しない … 6桁や8桁は、郵便番号の誤りとして判定に渡します
3. 住所の空白をそろえる … 全角と半角の空白、改行を1つの空白にします
4. 数字の表記を残す … 「一丁目」と「1丁目」、「1-2-3」と「1丁目2番3号」はそのまま渡し、AIに読ませます
5. 会社名の欄を見る … 会社名が入っている注文は、事業所の個別郵便番号の可能性を判定に伝えます
6. 住所1と住所2をつなげない … 建物名の欠けを見るため、別々のまま渡します

4番目で数字の表記を機械的に直さないのは、直し方を誤ると番地そのものが変わるからです。 「1-2-3」を「1丁目2番3号」に直す規則は、地域によって当てはまりません。読み替えは判定の中でAIに任せ、元の文字列は変えません。

6番目も同じ考え方です。 住所1に建物名まで書く人と、住所2に分けて書く人がいます。つなげてしまうと、建物名がどちらに書かれていたかが分からなくなります。

AIに処理させる

させるのは、3つの項目それぞれについて、疑いがあるかを判定し、根拠を書くことです。

右端の列が大事です。 建物名の欠けは、根拠が無いときは疑わない側に倒します。「1-2-3」で終わるだけの住所をすべて疑うと、一戸建ての購入者全員に確認メールが届きます。疑うのは、部屋番号らしい「1-2-3-405」のような書き方と、過去の注文との違いがあるときだけです。

1行目がいちばん起きやすい失敗です。 郵便番号と町名が合わない注文を見せると、AIは「正しくは〇〇町と思われます」と書き足します。それを確認メールに載せると、引っ越し前の住所に送るよう勧めることになりかねません。

指示内容を固定する

あなたはECサイトの出荷前に、配送先の住所に不備の疑いがあるかを点検する立場です。
次の情報だけを根拠に判定してください。住所についてのあなたの知識で補わないでください。

【注文の配送先】
郵便番号：{zip}　都道府県：{pref}　市区町村：{city}
住所1：{address1}
住所2：{address2}
会社名：{company}

【郵便番号のデータ（日本郵便）】
都道府県：{jp_pref}　市区町村：{jp_city}　町域：{jp_town}
同じ郵便番号に町域が複数あるか：{multi_town}
事業所の個別郵便番号の場合の所在地：{office_address}
検索の結果：{lookup_status}

【同じ購入者の過去の配送先】
{past_addresses}

【判定する3項目】
1. banchi … 町域のあとに番地・号にあたる数字があるか
2. building … 建物名・部屋番号が欠けている疑いがあるか
3. zip_match … 郵便番号のデータと住所が合っているか

【status の選び方】
- ok ......... 疑いが無い
- suspect .... 疑いがある。根拠を evidence に書く
- unclear .... 判断できない
建物名は、部屋番号らしい数字だけがある場合と、過去の配送先に建物名があって
今回は無い場合だけ suspect にしてください。それ以外は ok にしてください。
町域が複数の郵便番号では、町域を比べず、市区町村までで判定してください。
検索の結果が「見つからない」場合、zip_match は suspect にしてください。

【厳守事項】
- 正しい住所を推測して書かないでください。
- 郵便番号と住所のどちらが正しいかを判断しないでください。
- 郵便番号のデータに無い町名を、あなたの知識で正しいと判断しないでください。
- evidence には、注文の住所と郵便番号のデータのどの部分が食い違うかを、
  それぞれの文字列をそのまま写して書いてください。
- 出荷してよいかを書かないでください。

「建物名を疑うのは2つの場合だけ」と絞らないと、疑いが増えすぎます。 AIは「マンションの可能性もあります」と慎重な側に寄せがちです。確認メールが多すぎると、購入者は確認のメールを読まなくなります。

「知識で補わない」も外せません。 郵便番号のデータに無い町名を、AIが「実在する町名です」と通すと、照合の土台をデータに置いた意味がなくなります。

出力形式を固定する

AI by Zapier の出力フィールドを、次の項目で定義します。

{
  "banchi": { "status": "ok | suspect | unclear", "evidence": "" },
  "building": { "status": "ok | suspect | unclear", "evidence": "" },
  "zip_match": { "status": "ok | suspect | unclear", "evidence": "" },
  "note_for_staff": ""
}

1つ目の理由は、項目ごとの status で分岐を決められることです。 分岐の決まりはワークフローの側に置きます。

2つ目は、evidence が確認メールの差し込みに使えることです。 定型のメールには「郵便番号〇〇〇-〇〇〇〇に対応する地域と、ご住所の『〇〇町』をご確認ください」のように、どこを見てほしいかを具体的に差し込みます。 漠然と「住所をご確認ください」と書くと、購入者はどこを見ればよいか分からず、返事が「合っています」だけになります。

B の分岐で送る定型の確認メールは、次のような形にします。

件名：【ご注文番号 {order_no}】お届け先のご確認のお願い

{name} 様

ご注文ありがとうございます。
お届けにあたり、次の点をご確認いただけますでしょうか。

・郵便番号 {zip} に対応する地域は「{jp_city}{jp_town}」です。
  ご入力のご住所は「{city_and_town}」となっております。

ご住所に誤りがない場合も、このメールにご返信ください。
{deadline} までにご返信をいただけた場合、当日の発送に間に合います。
ご返信をいただくまで、発送をお待ちしております。

「誤りがない場合も返信を」と書くのは、返事が無いことを「合っている」と読まないためです。 返事が来ない注文は保留のまま残り、正午の確認で担当が見ます。

3つ目は、判定と出荷の判断を分けておけることです。 AIが返すのは疑いの有無までで、保留を外すのは担当が一覧の上で行います。

システムへ連携する

Paths は Professional 以上の機能で、1つのグループに最大10の分岐を作れます。 Paths と Filter の手順そのものはタスクを数えず、数えるのは実行された分岐の中のアクションだけです。条件に当たらなかったときの予備の分岐（fallback）をグループごとに1つ置けるので、出力が欠けたときの受け皿にします。

出荷の側は、保留の一覧を見て送り状を作らないようにします。 この構成は出荷のソフトには触れず、倉庫の担当が送り状を作る前に、保留の一覧と注文番号を突き合わせる手順を足します。

Google の高度な保護機能（Advanced Protection Program）を有効にしているアカウントでは、Zapier の Gmail は使えません。 サポートの共有アドレスの設定を先に確かめます。

人が確認する

1. C（建物名の疑い）の下書きを見る … 根拠を読み、一戸建てと思われれば送らずに保留を外します
2. 正午の締めの前に保留の一覧を見る … 返事が来たものは住所を直して保留を外し、来ていないものは翌日に回すかを決めます
3. 予備の分岐に入ったものを見る … 郵便番号のデータを直接見て、確認メールを送るかを決めます
4. 2日以上返事の無い注文を見る … 電話での確認に切り替えるかを決めます

2番目を省かないでください。 保留の一覧は、見る人がいなければ (d) の問題がそのまま残ります。 一覧に「メールを送った時刻」の列を置き、古い順に並べておきます。

目標は、2,400件をならして1件0.5分です。 疑いの無い注文には人が触れず、保留の一覧に載ったものだけに時間を使います。

例外に対処する

上から3行目は、運用の抜けから起きます。 毎月の差分を当て忘れると、新しくできた郵便番号の注文がすべて B に入り、正しい住所の購入者に確認メールが届きます。

記録を残す

• 注文番号、配送先の住所（注文時のまま）、受け取った時刻
• 郵便番号のデータを引いた結果（見つかった行、または見つからない）
• AIの判定（3項目の status と evidence）
• 分岐の結果と、確認メールを送った時刻、または下書きを作った時刻
• 購入者の返事の有無と、直した住所、保留を外した時刻
• 担当が判定と違う扱いにした記録（C を送らなかった、B を取り消した）

最後の行は、判定の決まりを直す材料になります。 C を送らずに保留を外した件が多ければ、建物名の疑いの決まりが広すぎます。月ごとに数えて、指示の側を直します。 AI by Zapier は過去の実行から学習しないので、直すのは指示と決まりです。

確認の台帳は、次の注文の判定に使われます。 返事で直した住所を台帳に残せば、同じ購入者の次の注文では、過去の配送先として建物名の有無を比べられます。