ワイナリーが酒販店・飲食店から届く注文メールを Make で受け、銘柄・本数・納品日を取り出して出荷の予定と在庫の引当の案を作る

処理の起点を決める

受注の代表アドレスに届いたメールのうち、ラベル「注文」が付いたものを起点にします。 ラベルは Gmail のフィルタで付けます。送信元が取引先の一覧にあるアドレスで、件名か本文に「注文」「発注」「お願いします」「本」「ケース」が含まれるものです。取引先からのメールでも、請求や試飲会の案内は注文ではないので、ラベルの条件で外します。

シナリオは15分おきに動かします。飲食店は営業の前に「今日の夕方までに」と書いてくることがあるので、1日数回のまとめ処理にはしません。 15分おきでも、いま担当が手の空いたときに読んでいるより早く下書きが出ます。

処理が終わったメールには、ラベル「注文・処理済」を付け直します（Update email labels）。付け直すのは受注台帳に行を書けたときだけです。 ラベル「注文」が残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、商品マスタの「別名」の列です。 飲食店は銘柄の正式な名前ではなく、「畑の名前の赤」「樽のシャルドネ」のように呼びます。別名の列にこうした呼び方を書き足しておくと、AIは別名から品番の候補を挙げられます。 別名に無い呼び方は候補が出ず、担当へ回ります。

ケースの入数も欠かせません。 「2ケース」と書かれた注文は、750mL なら12本入りで24本、375mL なら24本入りで48本です。本数への換算は、AIではなくワークフローが入数を掛けて行います。 AIには「2」と「ケース」を分けて返させます。

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

商品マスタは販売中の品目だけを渡します。 約40品目なので、別名を含めても1回の呼び出しに収まります。終売の品目を渡すと、昔の呼び方で終売の品番を候補に挙げてしまいます。

在庫の表の引当できる本数は、シートの式で出しておきます。 シナリオはその値を読むだけにし、Make の中で在庫を数え直しません。 電話で受けた注文を担当が手で台帳に書いたときも、同じ式に入るからです。

AIへ渡す前に整形する

1. 重複の確認 … メッセージの ID で受注台帳を引き、行があれば止めます
2. 返信の引用を落とす … 取引先が前回の確認の返信に返事をしてくると、下に前回の注文の全文が付いてきます。引用を落とし、今回書かれた部分だけにします
3. 署名を落とす … 店の住所と電話番号の入った署名は、届け先の候補と紛れます。署名の区切り線から下を落とします
4. 取引先の特定 … 送信元のアドレスで取引先を引きます。一覧に無いアドレスは、AIを呼ばずに担当へ回します
5. 添付の確認 … 注文書の PDF や表が添付されていれば、本文と添付のどちらが注文かを担当に回して決めます（List email attachments and media で有無を見ます）

2番目を落とすと、前回の注文をもう一度受けてしまいます。 「ありがとうございます。追加で白を3本お願いします」という返事の下に前回の24本の明細が付いていると、引用を残したまま渡せば、24本と3本の両方を注文として読みます。

AIに処理させる

させるのは、注文の明細を取り出すことと、商品マスタの候補の品番に結び付けることの2つです。

stated と inferred_from_history を分けるのが、この構成でいちばん大事な区別です。 「いつもの赤を6本」とあれば、直近の注文から赤の品番を補えます。ただし、補ったものは書かれていたものではありません。 前回の注文が古いヴィンテージだったら、補った品番は古い年になります。inferred_from_history の明細は、返信の下書きで「前回と同じ〇〇の2023年でよろしいでしょうか」と確かめます。

ヴィンテージは、とくに推し量らせません。 年が書かれていない注文で、在庫の表に2つの年が並んでいても、AIに「新しいほう」を選ばせません。null のまま返させ、どちらを出すかは商品マスタの「優先して出す年」の列でワークフローが決めます。 切り替えの時期をいつにするかは、営業の責任者が決めることだからです。

指示内容を固定する

あなたはワイナリーの営業部で、取引先から届いた注文のメールを
受注台帳に起こす担当です。下に渡すメールの本文から注文の明細を取り出し、
商品マスタの品番の候補に結び付けてください。
在庫があるか、出荷できるかは判断しないでください。

【すること】
1. 注文された品目ごとに1つの明細を作る。
2. 明細ごとに、メールに書かれた呼び方（written_name）をそのまま写す。
3. 商品マスタの銘柄と別名から、品番の候補（item_code）を1つ選ぶ。
   候補が2つ以上あれば candidates に並べ、item_code は空にする。
4. ヴィンテージ・容量は、書かれていれば写す。書かれていなければ null。
5. 数量は数（qty）と単位（unit：bottle／case／unknown）に分けて写す。
   ケースを本数に直さない。
6. 納品の希望日を日付に直す。「来週の金曜」などは受信日を基準に直す。
   「月末まで」「来週中」のように幅があるときは date を空にし、
   date_text に原文を写す。
7. 明細ごとに source を付ける。
   - stated：品目がメールに書かれていた
   - inferred_from_history：「いつもの」「前回と同じ」などで、
     直近の注文から品目を補った

【厳守事項】
- ヴィンテージが書かれていなければ null にする。在庫の表や
  直近の注文から年を補わない。新しい年を選ばない。
- 「いつもの」「前回の」から補った明細は、必ず inferred_from_history にする。
  stated にしない。
- 商品マスタにない呼び方は、似ている品番に寄せない。item_code を空にし、
  candidates も空にする。
- 数量が書かれていない品目は qty を null にする。1本と決めない。
- 価格、値引き、支払いの条件については何も書かない。
- 注文の取り消しや変更の依頼であれば、intent に cancel または change と書く。
- 確かめたいことは questions に、取引先への質問の形で書く。

【商品マスタ（販売中の品目）】{item_master}
【この取引先の直近の注文】{recent_orders}
【この取引先の届け先】{destinations}
【メールの受信日】{received_date}
【注文のメール】{mail_body}

「新しい年を選ばない」を書くのは、AIが親切に埋めようとするからです。 何も言わなければ、在庫の表にない情報でも「通常は最新のヴィンテージ」と考えて年を入れます。入れられた年は、確かめの対象から外れてしまいます。

「似ている品番に寄せない」も同じ理由です。 「樽の白」と書かれた注文に、別名が登録されていない樽熟成のシャルドネがあると、AIは寄せたくなります。寄せずに空にさせ、担当が別名の列に書き足します。 書き足した呼び方は次から候補に出ます。

出力形式を固定する

次の形の JSON を返させます。

{
  "message_id": "",
  "intent": "order | change | cancel | other",
  "lines": [
    {
      "written_name": "いつもの赤",
      "item_code": "R-HATAKE-750",
      "candidates": [],
      "vintage": null,
      "volume": null,
      "qty": 6,
      "unit": "bottle | case | unknown",
      "source": "stated | inferred_from_history",
      "evidence": "いつもの赤を6本お願いします"
    }
  ],
  "delivery": { "date": "2026-11-06", "date_text": "", "destination": "default" },
  "questions": ["前回と同じ畑の赤の2023年でよろしいでしょうか。"]
}

1つ目の理由は、取り出しと引当を別の層に置けることです。 lines はAIが埋め、引き当てられるか・出荷はいつかはワークフローが表と式で決めます。規則は次のとおりです。

2つ目は、数の確かめをワークフローで行えることです。 unit が case なら入数を掛けて本数にし、在庫の表の引当できる本数と比べます。公式のページでは、構造化出力は数値の minimum・maximum のような制約に対応せず、使うと 400 のエラーになるとされています。数量が0や桁違いでないかは、Make の式で確かめます。

3つ目は、選んだ値の照らし方を決めておけることです。 公式のページでは、構造化出力は文字列の enum の大文字・小文字までは保証しないとされています。ルーターで比べる前に、source と unit を小文字にそろえます。

出荷の予定日は、ワークフローが出します。 配送の日数の表で届け先の地域の日数を引き、希望日から引いた日より前で、いちばん近い出荷の曜日（火・水・金）を選びます。その日が今日の出荷の締めを過ぎていれば、間に合わないとして確かめが要るに回します。

システムへ連携する

ルーターのルートは、担当が見る→確かめが要る→そのまま確認できる→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。取り消しや割当ての超過の注文が、仮の引当まで流れないように、担当が見るルートを先頭に置きます。

仮の引当は、受注台帳に行を書けたときだけ在庫の表に反映します。 受注台帳の行には「仮」の印と書いた日時を付け、3営業日たっても確定にならない行は、毎朝の別のシナリオで引当を戻します。 確かめの返信に取引先が答えないまま、在庫が押さえられ続けるのを防ぎます。

確かめが要る注文でも、引き当てられる明細は仮で引き当てます。 「いつもの赤」の確かめを待つ間に、別の店の注文で同じ品目の最後の数本が出てしまわないようにするためです。

人が確認する

営業の担当が、すべての下書きを確かめてから送ります。 送るのは人で、この構成は送りません。

1. 担当が見る注文を先に見る … 取り消し・変更、品番の決まらない明細、割当ての超過です。割当ての超過は営業の責任者に回します
2. 補った明細を確かめる … inferred_from_history の明細で、補った品番とヴィンテージが取引先の店のリストに合っているかを見ます。返信の下書きの確かめの一文は消さずに送ります
3. 欠品と出荷日を確かめる … 足りない明細に代わりの品目を勧めるか、入荷を待ってもらうかを決めます
4. 送って確定にする … 下書きを送り、受注台帳の行を「確定」にします

出荷の担当は、出荷の前日に出荷の日ごとの一覧を確かめます。 一覧に載るのは「確定」の行だけです。出荷した後に、出荷の担当が台帳と帳簿に記録します。 酒税法は、酒類の製造者が製造場から移出した酒類について酒税を納める義務を負い、製造・貯蔵・販売に関する事実を帳簿に記載しなければならないと定めています。この構成が作るのは引当と出荷の予定の案で、帳簿の記載はその案ではなく、実際に出荷した記録から人が行います。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの誤りではなく、取引先の一覧と商品マスタの別名の整え方の問題です。 担当へ回る注文が多い週は、別名の列に何を書き足したかを数えると、整い具合が分かります。

記録を残す

• 注文のメールの本文（引用を落とす前のもの）と、メッセージの ID・スレッドの ID
• AIに渡した商品マスタの版と、直近の注文
• 返ってきた JSON の全文と stop_reason
• ワークフローが出した本数の換算、引当できる本数、出荷の予定日と、そのときの在庫の表の値
• 送った返信の本文と、担当が下書きから直した箇所
• 仮の引当を書いた日時と、確定・戻しの日時

4つ目で「そのときの在庫の表の値」を残すのは、欠品の連絡が遅れたときに理由を追うためです。 引き当てた時点で足りていたのか、後から別の注文で減ったのかが分かります。