飲食店の店長がチャットに書いた仕入れのメモから、仕入先ごとの品目・数量・納品日を拾って発注の文を下書きし、いつもの発注量と大きく違うものを示す

処理の起点を決める

店舗ごとの仕入れのチャンネルに新しいメッセージが加わったことを起点にします。 シナリオは15分ごとに動かします。Make のスケジュールは一定の間隔、毎日、平日、週ごと、月ごと、日付の指定などから選べ、一定の間隔の最小の長さはプランによって決まるとされています。閉店の後に書かれたメモが、15分以内に下書きになって返ってくれば、店長が帰る前に発注を済ませられます。

チャンネルにはメモ以外の書き込みも混ざります。 「明日のランチ、豆腐が足りないかも」のような相談や、本部からの連絡です。そこで、仕入れのメモは先頭に「【仕入れ】」を付けて書く決まりにし、シナリオの最初のフィルターで先頭の記号を見ます。記号の無い書き込みはAIに渡しません。AIに「これは仕入れのメモか」を判断させると、相談の文から品目を拾って下書きを作ってしまいます。

同じ日のメモが2本あるときは、後の1本をその日の正とします。 店長が書き直したときに、前の下書きと混ざらないようにするためです。2本目の下書きの冒頭には「先のメモを置き換えました」と書きます。

入力データを集める

質を決めるのは、品目の一覧の「呼び方」の列です。 「生中の樽」「生樽」「ビール樽」「中生10L」が同じ品目だと分かる手がかりは、この列にしかありません。AIが一般的な知識で「たぶんこれ」と当てるのではなく、この列から選ぶように作ります。

入数の列も同じくらい効きます。 「玉ねぎ1箱」を八百屋が受け付ける単位に直すには、1箱が何キロかを知っている必要があります。入数が空の品目は換算せず、確認に回します。

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

メモは Slack のトリガーが返す本文とタイムスタンプをそのまま使います。チャンネルから店舗を決めるので、チャンネルと店舗の対応はスプレッドシートの仕入先のシートに1列持たせます。

品目の一覧は、全品目ではなくその店舗が取引のある仕入先の品目だけを渡します。 全店の品目を渡すと、その店舗では扱っていない仕入先の品目に当ててしまいます。1店舗あたり150品目前後に収まります。

過去4週の同じ曜日の発注量は、シナリオで計算しません。 スプレッドシートに集計のシートを1枚作り、発注記録のうち「確定」の行から、店舗・品目・曜日ごとの中央値を関数で出しておきます。 シナリオはそれを Search Rows で引くだけです。計算の式がシートの上に見えているので、本部の購買が倍率や期間を変えたいときに、シナリオを開かずに直せます。

AIへ渡す前に整形する

1. 先頭の記号の確認 … 「【仕入れ】」で始まらないものは、ここで終わりにします
2. 投稿者の確認 … その店舗の店長と、登録した応援の社員だけを通します。ボット自身の投稿は除きます
3. 日付の手がかりの用意 … 投稿した日時から、その日から14日分の日付と曜日の表を作ってAIに渡します。「明日」「金曜」を日付に直すのはこの表だけを根拠にさせます
4. 閉店後の日付のずれの処理 … 0時を過ぎてから書かれたメモは、営業日としては前日のメモとして扱います。「明日」が1日ずれるのを防ぐためです
5. 全角と半角の統一 … 数字と記号を半角にそろえます。「５キロ」「5ｋｇ」を同じ形にします
6. 重複の確認 … 同じ店舗の同じ営業日のメモが既に処理されていれば、置き換えとして印を付けます

4番目を忘れると、0時を回る店では「明日」が店長の頭の中より1日先になります。

AIに処理させる

させるのは、メモを1品目ずつの行に分け、品目の一覧の中から当てはまる品目を選び、書かれた数量・単位・納品日をそのまま写すことだけです。

単位の換算はさせません。 「玉ねぎ1箱」は、quantity: 1、unit: "箱" として返させ、10キロへの直しはシナリオが入数の列で行います。AIに換算させると、入数を一般的な知識で補って、店ごとに違う箱の大きさを無視します。

3行目が、いちばん起きやすい失敗です。 「先週と同じで」と書かれたメモを渡すと、AIは過去の発注記録が無くても、それらしい品目を並べようとします。そういうメモは unclear_quantity で返させ、下書きを作らずに店長へ聞き返します。

指示内容を固定する

あなたは飲食店の本部で、店長が書いた仕入れのメモを品目ごとの行に分ける担当です。
メモに書かれていることだけを拾ってください。推測で埋めないでください。

【やること】
メモを1品目ずつに分け、品目ごとに次の項目を返してください。
- raw_text：メモのうち、その品目に当たる部分をそのまま写す
- item_code：下の【品目の一覧】の「呼び方」に当たる品目のコード
- quantity：書かれた数量の数字。書かれていなければ null
- unit：書かれた単位をそのまま（箱、キロ、玉、樽、ケースなど）。無ければ空
- delivery_date：下の【日付の表】から選んだ日付。書かれていなければ null
- note：「細めで」「大きめ」など、その品目に付いた注文
- status：ok / unknown_item / unclear_quantity / unclear_date のいずれか

【厳守事項】
- item_code は【品目の一覧】にあるものだけを使ってください。
  当てはまるものが無いときは item_code を空にし、status を unknown_item にしてください。
  似ているからといって別の品目のコードを当てないでください。
- 数量と単位は書かれたとおりに返してください。
  キロへの直し、箱の入数での掛け算などの換算はしないでください。
- 「いつもの」「先週と同じ」「少し」のように数量が書かれていないときは、
  quantity を null にし、status を unclear_quantity にしてください。
- 「明日」「金曜」などは【日付の表】だけを根拠に日付にしてください。
  2つの日付に読めるときは delivery_date を null にし、status を unclear_date にしてください。
- メモ全体に1つの納品日が書かれているときは、それを各品目に入れてください。
- 量が多い・少ないの意見、仕入先の提案、発注の文は書かないでください。
- 仕入れと関係のない文（相談・連絡）は、品目として返さないでください。

【このメモの営業日】{business_date}（{weekday}）
【日付の表】{calendar_14days}
【品目の一覧】{item_list}
【メモ】{memo_text}

「似ているからといって別の品目のコードを当てない」を書かないと、unknown_item がほとんど出なくなります。 一覧に「長ねぎ」しかない店で「青ねぎ」と書かれると、AIは長ねぎを当てます。一覧に無い品目は、一覧に足すか、別の仕入先に頼む品物かのどちらかで、どちらにしても人が決めることです。

換算の禁止を独立した1行にしているのは、AIが親切で換算するからです。 「1箱」を「10kg」と書き換えて返すと、シナリオがさらに入数を掛けて100キロになります。換算を1か所に決めておくことが、桁の間違いを防ぐいちばんの手当てです。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "store_code": "S05",
  "business_date": "2026-10-08",
  "items": [
    {
      "raw_text": "玉ねぎ1箱",
      "item_code": "V012",
      "quantity": 1,
      "unit": "箱",
      "delivery_date": "2026-10-09",
      "note": "",
      "status": "ok | unknown_item | unclear_quantity | unclear_date"
    }
  ],
  "not_order_text": ""
}

not_order_text には、メモの中で品目として拾わなかった文を入れます。店長が「ここは拾われていない」と気づける場所です。

JSONで受け取る1つ目の理由は、品目を1行ずつ規則にかけられることです。 Iterator で items を1品目ずつに分け、換算、締めと納品の曜日の確認、いつもの量との比較を、同じ手順で順にかけます。

2つ目は、status で振り分けられることです。 Router で、ok 以外の品目を確認の一覧へ、それ以外を仕入先ごとのまとめへ送ります。Router の経路は並行ではなく順に処理され、どの経路の条件にも合わないデータはフォールバックの経路が処理します。 確認の経路を先に置き、フォールバックを下書きの経路にします。

3つ目は、値の大小を規則で比べられることです。 シナリオは換算した数量を、集計のシートの中央値と比べ、次の規則で印を付けます。

倍率は2倍と半分から始めます。 狭くすると印が毎日出て、読まれなくなります。

スレッドに返す下書きは、次の形です。

【八百屋 〇〇青果 様】（電話）10/9（木）納品
いつもお世話になっております。〇〇店です。
・キャベツ 3玉
・玉ねぎ 10kg（メモ：1箱）
・豚バラ → 精肉のほうへ
よろしくお願いいたします。

【確認してください】
⚠ 玉ねぎ：いつもの約2倍以上（いつもは5kg）
？ 「青ねぎ少し」：品目の一覧に無く、数量も書かれていません

換算した品目には、元のメモの書き方を括弧で残します。 「10kg（メモ：1箱）」とあれば、店長は入数の誤りにその場で気づけます。

システムへ連携する

仕入先へは何も送りません。 電話もFAXも発注サイトも、店長が下書きを見て行います。送信を自動にすると、印の付いた品目を確かめる前に発注が出ます。

確定は、店長が下書きの返信に決まった絵文字の反応を付けたことで行います。 2本目のシナリオを Slack の Watch New Events で作り、反応のイベントを受けます。反応が付いた返信のタイムスタンプで発注記録を引き、「下書き」を「確定」に更新します。 いつもの量の計算は「確定」の行だけを使うので、下書きのまま放置されたものが、いつもの量を狂わせません。

人が確認する

店長が見るのは、スレッドに返ってきた下書きの全文です。 ただし、時間をかけるのは「確認してください」の欄だけです。

1. 「確認してください」の欄を先に読む … 多い・少ない・初めて・締め切れ・曜日外と、拾えなかった品目
2. 換算の括弧を見る … 「10kg（メモ：1箱）」のように元の書き方と並べて、入数が合っているかを確かめる
3. 直すときは、メモを書き直す … 下書きの文を手で直すのではなく、【仕入れ】のメモを書き直して再投稿する。後の1本が正になる
4. 発注を終えたら反応を付ける … 付けたものだけが「確定」になり、いつもの量の計算に入る

3番目を「メモを書き直す」にしているのは、記録を1か所に保つためです。 下書きの文を手で直して送ると、発注記録には直す前の数量が残り、翌週のいつもの量が、実際に頼んだ量とずれます。

本部の購買は、毎週月曜に確認の一覧を見ます。 unknown_item が繰り返し出る呼び方は、品目の一覧の「呼び方」の列に足します。この作業が、翌週からの unknown_item を減らすいちばんの近道です。

例外に対処する

上から4行目までで、例外のほとんどを占めます。 どれもAIの精度ではなく、記号の付け忘れと、品目の一覧の手入れの問題です。 最初の1か月は、本部が毎朝この4種類の件数を数えます。

構造化出力でも、スキーマに沿わない応答が返る場面があります。 公式の説明では、応答を拒否したときは拒否のメッセージが優先されてスキーマに沿わないことがあり、max_tokens で止まったときは出力が途中で終わることがあるとされています。シナリオは stop_reason を見てから JSON を読みます。

記録を残す

• メモの本文、投稿日時、投稿者、チャンネル、タイムスタンプ
• AIが返したJSONの全文と、そのときの品目の一覧の版
• 換算した後の数量と、使った入数
• いつもの量の比較の結果（中央値、倍率、印）
• スレッドに返した下書きの全文とタイムスタンプ
• 確定の反応を付けた日時と人
• 置き換えたメモと、置き換えられたメモの対応

2つ目の「品目の一覧の版」を残すのは、呼び方の列が毎週増えるからです。 ある日の unknown_item が、そのときの一覧に無かったからなのか、AIが拾い損ねたからなのかは、当時の一覧が残っていないと分かりません。