荷主から届く配車依頼のメールとFAXを読み取って、配車表に転記する

処理の起点を決める

受付アドレスに依頼が届いたことを起点にします。 受付アドレスからZapierの受信用アドレスへ自動転送を設定し、Email by Zapier の「New Inbound Email」で受けます。1時間おきにまとめて処理する形にはしません。 夕方に集中する依頼を、届いた順に表に出していくためです。

3経路はすべてメールにそろえます。 FAXは複合機でPDFにしてメールで転送し、Webフォームは送信のたびに通知メールを受付アドレスへ送る設定にします。入り口を1つにしておくと、どれか1経路だけが転記されない日ができません。

気をつけたい点が2つあります。 Email by Zapier はいつZapが動くかを保証しておらず、遅れることがあるとされています。時間に厳しい処理では IMAP by Zapier や、アプリとの直接の連携を使うよう案内されています。当日の急ぎの依頼は、これまでどおり電話で受ける前提にしてください。 もう1つは、送信元のアドレスが無いメールではZapが動かないことです。Webフォームの通知メールがこれに当たることがあるので、最初に確かめます。

入力データを集める

質を決めるのは、荷主一覧です。 「いつもの倉庫」と書かれた依頼は、荷主一覧に既定の積地が無ければ住所になりません。ただし、AIに荷主一覧を渡して埋めさせることはしません。 AIは「いつもの倉庫」とだけ書き出し、既定の積地を当てるのはワークフローです。どこまでが依頼に書かれていて、どこからが自社で補ったのかを、行の中で分けて残すためです。

直近の受付は、変更か重複かを見分けるために持ちます。 同じ荷主から、同じ集荷日・同じ卸地の依頼が短い間隔で2通来たら、FAXとメールの二重送信か、内容の変更かのどちらかです。

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

受信日時は、必ず日本時間に直してから渡します。 Formatter の日付変換では、元のタイムゾーンを入れないと入力はUTCとして扱われ、夜の依頼の「明日」が1日ずれます。

荷主は、送信元のアドレスで引きます。 Lookup Spreadsheet Row は、列と値で探して最初に一致した行を返し、補助の列で2条件の検索も、最後の行からの検索もできます。 直近の受付は「荷主コード」と「集荷日」で最後の行から探します。

PDFは、OpenAI の Files API に上げます。 用途を user_data にして上げ、返ったファイルIDを次の手順で input_file として参照します。Webhooks で送れるのは5MBまでです。

AIへ渡す前に整形する

1. 空のメールの除外 … 転送設定の確認メールなど、本文も添付も無いものは記録だけ残します
2. 大きさの確認 … メールは添付込みで10MB未満、Webhooks で送るPDFは5MBまでです。超えるものは人に回します
3. 添付の種類の確認 … PDF以外（画像、Excel）は、この段階では人に回します
4. 本文の整理 … 署名、過去のやり取りの引用、定型の免責文を落とします。引用部分に古い依頼が残っていると、2件分を読み取ります
5. 受信日時の変換 … 日本時間の日付と曜日にします
6. 荷主の特定 … 送信元のアドレスで荷主一覧を引きます。引けない場合は荷主不明として続行し、行には書き込みません
7. 二重送信の検知 … 同じ荷主・同じ集荷日の行が直近にあれば、その行の中身を読み取りの手順へ一緒に渡します

4番目を軽く見ないでください。 返信の形で届く依頼は、下に前回の依頼がそのまま引用されています。引用を落とさないと、前回分を新しい依頼として書き込みます。 確実に落とせない場合に備えて、指示の側でも「引用部分は読まない」と書いておきます。

AIに処理させる

させるのは、依頼の種別を見分けることと、便ごとに項目を取り出し、項目ごとに記載の状態を付けることです。 そのうえで、「記載なし」「判読不能」の項目だけを並べた問い合わせ文案を作らせます。

右端の列の、付帯作業の行が、この構成でいちばん大事な区別です。 stated_none は荷主が「付帯作業なし」と明記したということ、not_stated は何も書かれていないということです。前者はそのまま配車に回せ、後者は聞き直すべきものです。

集荷日の相対表現にも気をつけます。 夜遅くに届いた依頼の「明日」が、荷主にとってどの日かは分かりません。日付に直したうえで relative の印を付けます。

4行目がいちばん起きやすい失敗です。 「鋼材 パレット8枚」とだけ書かれた依頼を渡すと、1枚あたりの重さを見積もって重量を埋めます。埋まった数字は、それらしく見えるぶん聞き直しの対象から外れます。

指示内容を固定する

あなたは運送会社の配車課で、荷主から届いた配車依頼を受け付ける立場です。
依頼の本文と添付のPDFだけを読み、書かれていることを取り出してください。
推測で埋めないでください。

【最初に決めること：request_type】
- new ....... 新しい配車の依頼
- change .... 既に依頼した内容の変更（日時・重量・卸地などを変える）
- cancel .... 既に依頼した内容の取り消し
- other ..... 配車の依頼ではない（請求、挨拶、営業など）
「先ほどの件」「変更です」「以下に訂正」などがあれば change を検討してください。
【直近の受付】に同じ集荷日・同じ卸地の行があれば、その内容と比べてください。

【便ごとに取り出す項目】
集荷日、集荷時間帯、積地、卸地、納品日、納品時間帯、品目、数量、重量、車格、付帯作業
1通に複数の便があるときは、便ごとに分けて shipments に並べてください。

【各項目の status】
- stated ....... 値が書かれている
- stated_none .. 「なし」「不要」と明記されている
- not_stated ... 何も書かれていない
- unclear ...... 文字はあるが読めない、または意味が1つに決まらない
迷ったときに stated を選ばないでください。

【厳守事項】
- 書かれていない項目は value を null、status を not_stated にしてください。
  他の項目や一般的な相場から補って埋めないでください。
- 付帯作業について何も書かれていないことを、「なし」として扱わないでください。
- 「いつもの倉庫」「前回と同じ」は、その文字列をそのまま value に入れてください。
  住所に直さないでください。
- 重量は書かれた数字と単位をそのまま入れてください。
  パレット数やケース数から重量を計算しないでください。
- 車格は書かれた表記のまま入れてください（例：4tワイド、ユニック）。
- 日付は raw に書かれた文字列を、date に【受信日時】を基準にした日付を入れてください。
  「明日」「来週」など相対的な表現なら relative を true にしてください。
  書かれた曜日と日付が合わない場合は status を unclear にしてください。
- メールの引用部分（「>」で始まる行や、過去のやり取り）は読まないでください。
- evidence には、根拠にした原文をそのまま写してください。
- どの車に載せるか、受けられるかは書かないでください。

【問い合わせ文案】
not_stated と unclear の項目だけを、便ごとに箇条書きで尋ねる文面を作ってください。
値を推測して「〜でよろしいでしょうか」と書かないでください。

【受信日時】{received_at_jst}
【荷主】{shipper_name}
【直近の受付】{recent_rows}
【本文】{body_text}

「付帯作業について何も書かれていないことを、なしとして扱わない」を明記しないと、stated_none になります。 依頼の多くは付帯作業に触れていないので、AIは「特に作業はない」と読みます。禁じるのは、触れていないことを否定と読む判断そのものです。

「〜でよろしいでしょうか」を禁じるのは、 推測を添えて尋ねると、荷主が確かめずに「はい」と返しがちだからです。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "request_type": "new | change | cancel | other",
  "change_target": { "pickup_date": null, "delivery_place": null },
  "shipments": [
    {
      "pickup_date": { "raw": "明日AM", "date": "2026-10-02", "relative": true,
                       "status": "stated", "evidence": "明日AM" },
      "pickup_place": { "value": "いつもの倉庫", "status": "stated", "evidence": "" },
      "cargo_weight": { "value": null, "status": "not_stated", "evidence": null },
      "extra_work": { "value": null, "status": "not_stated", "evidence": null }
    }
  ],
  "inquiry_draft": ""
}

各便には、ほかの項目（集荷時間帯・卸地・納品日時・品目・数量・車格）も同じ形で並べます。

1つ目の理由は、項目を落とさせないことです。 構造化出力では、指定したJSONスキーマに沿った応答を常に返し、必須のキーの欠落や選択肢の外の値を防ぐとされています。すべての項目を必須にし、additionalProperties を false にします。

2つ目は、「書かれていない」を形で表せることです。 すべての項目が必須なので、書かれていない値は型に null を加えた項目で表します。value が null で status が not_stated、が「聞き直す」の印です。

"extra_work": {
  "type": "object",
  "additionalProperties": false,
  "required": ["value", "status", "evidence"],
  "properties": {
    "value":    { "type": ["string", "null"] },
    "status":   { "type": "string", "enum": ["stated", "stated_none", "not_stated", "unclear"] },
    "evidence": { "type": ["string", "null"] }
  }
}

ただし、構造化出力が保証するのは形で、値の誤りまでは防げません。 だから evidence に原文を写させ、確認の画面で並べて見せます。既定の積地を当てたときも pickup_place は「いつもの倉庫」のまま残し、当てた住所は受付シートの別の列に書きます。

システムへ連携する

Paths は、決めた規則でZapの手順を分ける機能です。 最大10本の枝を置け、どの規則にも当たらなかったときだけ動く枝も作れます。ここでは4本にします。

複数便の依頼を最後の枝に回しているのは、半自動化の段階の割り切りです。 1通の依頼を便の数だけ行に分けて書く組み方は、利用するアクションとプランによって変わります。まずは人が分けて入力し、件数を見てから組むかを決めます。

配車を組むシートには書き込みません。 自動で書くのは受付シートだけです。機械が書いた行が、確かめられないまま配車に使われる経路を作らないためです。

人が確認する

配車担当は、受付シートの「要確認」の行を、原文と並べて見ます。 行には evidence と、元のメールへのリンクを入れておきます。

1. relative の印がある日付を先に見る … 「明日」が荷主の意図どおりの日付になっているかを確かめます
2. 既定の積地を当てた行を見る … 「いつもの倉庫」が今回も同じ倉庫かを、必要なら問い合わせ文案に1行足します
3. 付帯作業が not_stated の行を見る … ここは省かないでください。 聞き直すかどうかをこの場で決めます
4. 問い合わせ文案を直して送る … 送信は人が行います。電話で済ませた場合も、行に記録します
5. 確定させる … 状態を「確定」にし、配車を組むシートへ移します

3番目を省くと、この構成を入れた意味が半分になります。 書かれていなかった付帯作業は、転記の時点でしか拾えません。 配車が決まった後では、荷主に聞く理由がなくなります。

目標は、750件をならして1件2分です。 そろっている依頼は見比べるだけで1分かからず、聞き直しのある依頼は文案を直して送るので数分かかります。2分を大きく超える月は、荷主一覧の既定の積地か、車格の表記一覧が足りていません。

例外に対処する

上の3行とFAXのかすれが大半です。 どれも受け取り方の問題で、直すほうが精度を上げるより効きます。

記録を残す

• 元のメール（本文と添付）と、受信日時、Zapが動いた日時
• 生成AIに渡した本文と、返ってきたJSONの全文
• 受付シートに書いた行と、既定の積地を当てたかどうか
• 人が直した項目と、直す前後の値
• 問い合わせを送った日時と、荷主の返答で埋まった項目
• 荷主ごとの not_stated の多い項目

1つ目で2つの時刻を残すのは、起動の遅れを測るためです。 差が夕方に広がるなら、IMAP by Zapier への切り替えを検討します。

最後の行は、荷主と相談する材料になります。 毎回付帯作業を書かない荷主には、依頼書のひな形に欄を足してもらうほうが、聞き直しを毎回続けるより早く片づきます。