豆腐の製造所が飲食店・スーパーからメールで届く注文を n8n で受け、品目・数・納品日を抜き出して翌日の製造の指示にまとめる

処理の起点を決める

受け付けの流れは Gmail Trigger の Message Received で動かします。 Gmail Trigger は決まった間隔でメールを見にいく方式で、間隔は Poll Times の Mode で決めます。13時台の集中を考えて、間隔は数分ごとにします。 1回で拾うメールの数は Max Emails per Poll（既定10、最大50）で決まり、超えた分は次の回に回ります。 13時台に数十通が重なる日は、50にしておきます。

絞り込みは Filters で行います。 受付のアドレスに届くメールに Gmail の側で「注文」のラベルを付け、Label Names or IDs でそのラベルだけを拾います。Read Status の既定は「未読だけ」なので、担当が先にメールを開くと拾われません。 このため Read Status は既読も含めるにし、Search に -label:処理済み のような Gmail の検索の書き方を入れて、処理したものを除きます。 処理が終わったメールには、n8n の側で「処理済み」のラベルを付けます。ラベルを付けるのは注文の表に書けたときだけにし、途中で止まったメールは次の回にもう一度拾われるようにします。

締めの流れは Schedule Trigger で毎日14時に動かします。 ここでいちばん気をつけるのはタイムゾーンです。ワークフローにタイムゾーンを設定していないと n8n のインスタンスのタイムゾーンが使われ、自分で立てた n8n の既定は America/New York です。 そのままだと14時が日本の午前3時か4時になります。ワークフローの設定で Asia/Tokyo にします。

入力データを集める

質を決めるのは、通称の表と入数の表です。 「揚げ」をその得意先がどちらの意味で使うかは、得意先ごとに表に書いておくしかありません。 同じく「1ケース」の丁数は、スーパーと給食の業者で違います。

通称の表を得意先ごとに持つのが、この構成の工夫です。 全得意先で共通の表にすると、ある店の「揚げ」を直したときに、別の店の「揚げ」まで変わります。

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

Get Row(s) で絞り込んだときの既定は、最初に一致した1行だけです。 通称・入数・前の注文はどれも複数行あるので、When Filter Has Multiple Matches を Return All Matches にします。 これを忘れると、得意先の最初の通称しか引けず、2品目以降がすべて「当たらない」になります。

Gmail Trigger の Simplify は既定でオンです。 オンのときに返るのは ID・ラベル・ヘッダー（From・To・Subject など）が中心です。本文を Information Extractor に渡すので、Simplify をオフにして生のデータを受け、本文の部分を取り出します。 署名と引用された過去のやり取りは、前処理で落とします。

AIへ渡す前に整形する

1. 得意先を引く … 送り主のアドレスで得意先を探します。見つからなければ抜き出しをせず、担当へ回します
2. 引用を落とす … 返信で届いたメールは、「>」で始まる行や「〜wrote:」以降の過去のやり取りを落とします。落とさないと、前の注文の数をもう一度抜き出します
3. 署名を落とす … 店の住所・電話番号の行を落とします
4. 数字をそろえる … 全角と半角をそろえます。漢数字は残します
5. 受信の日時を付ける … 「明日」「今日の分」を解くために、日本時間の受信の日時を本文の前に付けます
6. 締めの後かを印す … 14時を過ぎて届いた翌日分の注文には after_cutoff の印を付けます
7. スーパーの店舗の行を分ける … 本文に店舗ごとの数が表のように並ぶメールは、店舗の名前が並ぶ行で区切り、店舗ごとに1件として抜き出しに回します。 1通のまま渡すと、店舗と数の組み合わせがずれることがあります

2番目を省かないでください。 得意先が前のメールに返信して「追加で絹3」と書くと、引用の中の「木綿10 絹5」まで今回の注文として抜き出されます。

AIに処理させる

させるのは、メールの本文から注文の行を書かれたとおりに抜き出し、行の種類を分けることだけです。 n8n の Information Extractor ノードに Anthropic Chat Model をつなぎ、スキーマを JSON Schema で定義します。

右から2列目の「書かれたとおり」が、この構成でいちばん大事な決まりです。 「明日」を日付に直すのも、「2ケース」を丁数に直すのも、AIではなく n8n のコードノードがやります。 AIが直した値は、どこまでが書かれていたことかが見分けられなくなります。

行の種類を分けさせるのは、取り消しの見落としを止めるためです。 cancel と change の行は、注文の表に新しい行として足さず、同じ得意先・同じ納品日の前の行を探して差し引きます。

1行目がいちばん起きやすい失敗です。 入数の表を渡して換算させると、表に無い組み合わせでも、それらしい入数を当てはめて丁数を出します。

指示内容を固定する

Information Extractor ノードの System Prompt Template に次の文を入れます。出力の形式の指示はノードが自動で足すので、ここには書きません。

あなたは豆腐の製造所の受付で、得意先から届いた注文のメールを読む立場です。
本文に書かれていることだけを、決まった項目に書き出してください。

【書き出すもの】
- lines：注文の行ごとに、品目・数・単位・納品日・店舗・行の種類
- missing：注文を受けるのに足りない情報
- questions_for_staff：担当が得意先に確かめるべきこと

【行の種類】
- new ........... 新しい注文
- change ........ 前に送った注文の数を増やす・減らす（direction に up か down）
- cancel ........ 前に送った注文を取り消す
- same_as_usual . 「いつも通り」「いつもの」とだけ書かれている
- unclear ....... どれか決められない

【厳守事項】
- 品目は書かれた語のまま書いてください。「揚げ」を厚揚げか油揚げかに決めないでください。
- 数と単位は書かれたとおりに書いてください。ケースや箱を丁数に直さないでください。
  計算をしないでください。漢数字は漢数字のまま書いてください。
- 単位が書かれていなければ空にしてください。「丁」を補わないでください。
- 納品日は書かれた言い方のまま書いてください。暦の日付に直さないでください。
- 「減らして」「やめて」「キャンセル」は new にしないでください。
  減らす数が書かれていれば change、全部やめるなら cancel にしてください。
- 「いつも通り」の中身を推測しないでください。same_as_usual にして、数は空にしてください。
- 引用された過去のメールの内容は書き出さないでください。
- 注文でない文（お礼、請求の問い合わせなど）なら lines を空にし、
  questions_for_staff に文の種類を書いてください。

【得意先】{customer_name}
【受信の日時（日本時間）】{received_at}
【本文】
{body}

「減らして」を new にしないことを、例を挙げて書いています。 何も言わなければ、「厚揚げ 5枚 減らして」の中の「厚揚げ」「5」「枚」を新しい注文として書き出すことがあります。取り消しの見落としは、作りすぎに直結します。

出力形式を固定する

次の形の JSON で受け取ります。 スキーマはノードの「Define using JSON Schema」で定義します。

{
  "message_type": "order | change | cancel | other",
  "lines": [
    { "item_text": "揚げ", "qty_text": "20", "unit_text": "枚",
      "delivery_text": "明日", "store_text": "", "line_type": "new",
      "direction": "" }
  ],
  "missing": [],
  "questions_for_staff": []
}

AIが埋めるのはここまでです。 この後ろに、n8n のコードノードが規則で次の項目を足します。

1つ目の理由は、AIの書き出しと換算を別の層に置けることです。 入数が変わったら、入数の表を直すだけで、同じ書き出しから正しい丁数が出ます。

2つ目は、status で担当が見る行を絞れることです。 ok の行は締めの集計にそのまま入り、needs_check と after_cutoff の行は担当が確かめるまで集計に入れません。

システムへ連携する

注文の表への書き込みは、新規は Append Row、増減と取り消しは Update Row で行います。 Update Row は既存の行だけを更新し、新しい行は足しません。取り消しは行を消さず、状態を「取り消し」にして元の文を残します。

締めの集計は Summarize ノードで行います。 Fields to Split By に品番を入れ、丁数を Sum で足し上げます。SQL の GROUP BY と同じ働きです。集計の結果に配合の表を当てて、仕込みの回数と大豆の使用量を出すのはコードノードです。 1仕込みの単位で切り上げるので、端数の扱いを責任者と決めておきます。

返事は下書きまでにします。 Create a draft の Thread ID に届いたメールのスレッドを入れると、得意先とのやり取りの流れの中に下書きができます。

人が確認する

担当が開くのは needs_check と after_cutoff の行だけです。 ok の行は、元の文と丁数が並んだ注文の表で流し見ます。

1. needs_check を先に見る … 通称が当たらない、入数が無い、取り消しの当て先が無いもの。直したら通称の表か入数の表に足します
2. same_as_usual を見る … 得意先の定番の数が出ているので、曜日の違いが無いかを見ます
3. after_cutoff は責任者に回す … 受けるかどうかは製造の責任者が決めます
4. 下書きを見て送る … 受け付けた品目と丁数が書かれているので、得意先が数の違いに気づけます
5. 14時の指示の案を責任者が確定する … 予備の数を足し、仕込みの回数を決めます

4番目の返事に丁数を書くのは、得意先に確かめてもらうためです。 「絹 2ケース（24丁）で承りました」と返せば、入数の取り違えがあれば得意先の側で気づきます。

直した組を表に足すことを続けるのが、精度を上げる方法です。 通称の表に足した組は、次の注文から ok で出ます。

目標は、900件をならして1件1分です。

例外に対処する

6行目は、締めの直前に起きると取りこぼしになります。 13時50分の時点で、受付のラベルの未読が0になっているかを担当が確かめる手順を入れます。

記録を残す

• 元のメールの ID・送り主・受信の日時・本文
• AIの書き出しの JSON と、規則が足した sku・pieces・delivery_date・status
• 取り消し・増減を当てた前の行と、差し引く前の数
• 担当が直した項目と直す前の値
• 送った返事と送信の日時
• 毎日の製造の指示の案と、責任者が確定した数（予備を含む）
• そのとき使った通称の表と入数の表の版

最後の行の「表の版」は、入数を直した日の前後で丁数が変わるために残します。 表を直した後に過去の注文を見返しても、当時の換算が分かります。

3つ目の「差し引く前の数」が、翌朝のもめごとを止めます。 「減らしたはずなのに届いた」と言われたとき、いつ、どの行から、何丁を引いたかが残っていれば、すぐに答えられます。