花屋が電話のメモ・メール・Web のフォームで受けた注文を Make で集め、配達日時・届け先・用途・札の文言を作業の指示書にそろえて、記載の欠けを拾う

処理の起点を決める

3つの経路それぞれを起点にします。 自社サイトのフォームと電話のメモ用のフォームは、それぞれの回答のシートを Watch New Rows で見張ります。メールは、Gmail のフィルタで注文と分かるもの（件名や本文に「注文」「お届け」「スタンド花」などを含み、取引先の法人のアドレスから来たもの）に「注文」のラベルを付け、Watch emails でそのラベルを見張ります。

実行の間隔は15分にします。 当日の配達の注文が午前に入ることがあり、受けてから指示書ができるまでを短くしたいからです。 1回で扱う件数の上限は20にします。

フィルタに当たらないメールの注文は、受付のスタッフが手でラベルを付けます。 初めての注文者の個人のアドレスからの注文は、送信元で絞れません。ラベルを付ければ同じ流れに乗るので、受信箱を見たスタッフがラベルを付けるだけで済みます。

入力データを集める

質を決めるのは、電話のメモの打ち込み方です。 「来週月曜 ABCさん移転 2万 スタンド」と略して打ち込まれると、届け先の住所も札の名義も、AIは取り出しようがありません。 電話のメモのフォームには「注文者が言った言葉のとおりに打つ」と欄の説明に書き、札の文言だけは別の欄に分けて、注文者に1文字ずつ読み上げてもらって打ち込む運用にします。

店の決まりの必須の項目は、用途ごとに表にします。 例えば次のような表です。

お見舞いの最後の項目は、店の側では判断できない項目です。 病院によって花の持ち込みの扱いが違うので、注文者に確かめてもらったかを確認の項目に入れます。

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

メールの注文は、同じスレッドの続きにも注意します。 「先ほどの注文、札の名前を変えてください」という2通目は、新しい注文ではありません。スレッドIDで注文台帳を引き、同じスレッドの注文があれば「変更の連絡」として受付のスタッフへ回し、新しい指示書は作りません。 変更を指示書に反映するのは人です。

フォームの注文は、1回の回答が1件の注文です。 ただし、法人の注文では「同じ札で3か所に」のように1通のメールに複数の届け先が書かれることがあります。AIに届け先の数を返させ、2か所以上なら届け先ごとに注文台帳の行と指示書を分けて作ります。

AIへ渡す前に整形する

1. 重複の確認 … メッセージIDかフォームの回答の時刻で注文台帳を引き、記録があれば止めます
2. 引用と署名を落とす … メールの返信の引用と、法人の署名の長い定型文を落とします。署名の会社名は注文者の欄に使うので、別に取っておきます
3. 受付の日付を添える … 「来週月曜」「明後日」を読むための基準として、受付の日付と曜日を渡します
4. 札の欄を分けて渡す … 電話のメモとフォームでは、札の文言の欄を本文とは別に渡します
5. AIに渡す範囲を絞る … クレジットカードの番号などの支払の情報が書かれていたら、渡す前に伏せます

2番目で署名を落とすのは、札の名義と取り違えないためです。 署名の「株式会社ABC 総務部 山田」と、札に入れたい「株式会社ABCホールディングス 代表取締役 山﨑太郎」は別の名前です。署名を残したまま渡すと、AIが署名の名前を札に写すことがあります。

3番目は、日付を計算させないための準備です。 AIには「来週月曜」を原文のまま写させ、日付に直すのはワークフローで、受付の日付から計算します。 直した日付は指示書に原文と並べて書きます。

AIに処理させる

させるのは、注文の文から項目を書かれたとおりに取り出し、欠けを挙げることだけです。

札の文言で、AIにさせないことがはっきりしています。 旧字体を新字体に直さない、「株式会社」の位置を動かさない、連名の順番を変えない、「様」を足さない、頭書きを補わない。注文の文に「﨑」とあれば「﨑」、「崎」とあれば「崎」です。 どちらが正しいかは注文者にしか分かりません。

指示内容を固定する

あなたは花屋の受付の担当として、届いた注文から作業の指示書に書く
項目を取り出します。注文の文に書かれていることだけを使ってください。
推測で埋めないでください。

【取り出す項目】
- 配達日：原文をそのまま delivery_date_text に写す。日付に直さない。
- 配達の時間：原文をそのまま。書かれていなければ not_stated。
- 届け先：名前、住所、建物名・階・部屋、電話。欠けた部分は missing に。
- 用途：opening（開店・移転）、funeral（お供え）、get_well（お見舞い）、
  birthday（誕生日・記念日）、wedding（結婚）、other から1つ。
- 商品：種類、予算、色の希望の原文。
- 札の文言：頭書きと名義を、注文の文のとおり1文字も変えずに写す。
- メッセージカード：文言を1文字も変えずに写す。
- 届け先の数：何か所に届けるか。

【札とカードの厳守事項】
- 字を直さない。旧字体・異体字（﨑・髙など）を新字体に変えない。
- 「株式会社」の位置、連名の順番、空白を変えない。
- 「様」「御中」を足さない。頭書き（祝・供など）を補わない。
- 札の文言が書かれていなければ、空にして missing に "tag_text" を入れる。
- メールの署名の名前を、札の名義として使わない。

【その他の厳守事項】
- 書かれていない時間・住所・日付を補わない。
- 用途ごとの必須の項目（下の表）のうち、書かれていないものを
  missing にすべて挙げる。
- 注文の中で食い違う記述（日付と曜日が合わない、など）があれば
  conflicts に原文を並べて書く。
- 支払の情報は写さない。

【経路と受けたスタッフ】{channel} / {staff}
【受付の日付と曜日】{received_date}
【用途ごとの必須の項目】{required_items}
【札の文言の欄（電話のメモ・フォーム）】{tag_field}
【注文の文】{order_text}

「署名の名前を札の名義に使わない」を明記するのは、法人の注文で起きやすいからです。 札の名義が本文に書かれていないとき、AIはいちばん近くにある会社名と人の名前、つまり署名を写します。それは注文者の名前で、贈り主の名義とは限りません。 書かれていなければ空にして、確認に回します。

異体字の例を指示に書くのは、AIが字を「正しく」直そうとするからです。 「髙」を「高」に直した札は、贈り主にとっては名前の誤りです。

出力形式を固定する

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

{
  "order_id": "",
  "destinations": [
    {
      "delivery_date_text": "",
      "delivery_time_text": "",
      "recipient_name": "",
      "address": "",
      "building_floor": "",
      "phone": "",
      "tag_text": "",
      "card_text": ""
    }
  ],
  "purpose": "opening | funeral | get_well | birthday | wedding | other",
  "product_type": "",
  "budget_text": "",
  "color_text": "",
  "orderer": { "name": "", "company": "", "contact": "" },
  "missing": [],
  "conflicts": [],
  "needs_attention": false
}

構造化出力にする1つ目の理由は、指示書のひな形のタグにそのまま差し込めることです。 destinations の要素ごとに、配達日時・届け先・札の文言をタグに入れて指示書を作ります。OpenAI API の Structured Outputs は、Responses API の text.format に type: "json_schema" と strict: true を付けてスキーマを渡す仕組みです。公式のページの例では、値が無いかもしれない欄を null との組み合わせの型で表しています。 この構成では、空の文字と not_stated で表し、欠けは missing に集めます。

2つ目は、札の文言をワークフローが照合できることです。 tag_text と card_text が、注文の文か札の欄にそのままの文字の並びで含まれているかを確かめます。含まれていなければ、AIが字を直したか補ったということなので、指示書の札の欄に「要確認：原文と不一致」と書きます。 あわせて、purpose から頭書きの一覧を引き、tag_text の頭書きが一覧の候補と食い違えば印を付けます（お見舞いに「祝」など）。

3つ目は、応答の状態を確かめられることです。 公式のページでは、拒否のときは refusal が返り、出力が上限で止まったときは status と incomplete_details で分かるとされています。どちらのときも指示書を作らず、受付のスタッフへ回します。

作業の指示書のひな形には、次の欄を置きます。

システムへ連携する

ルーターのルートは、次の順に並べます。 1本目は needs_attention か札の照合の不一致があるもの、2本目は missing か conflicts があるもの（確認のメールの下書き）、3本目は欠けの無いもの（「確認待ち」の通知）、最後にフォールバックです。公式のページでは、ルートは1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが受け持つとされています。

確認のメールの下書きには、欠けた項目だけを並べます。 下書きの文はAIに書かせず、missing の項目名を店の決まった文に差し込むだけにします。お供えの注文者に、確認の文が長く届くのは負担だからです。電話の注文は下書きを作らず、受付のスタッフが電話で確かめる一覧に回します。

人が確認する

受付のスタッフが、すべての注文を「制作可」にする前に確かめます。

1. 札の文言を1文字ずつ見る … 指示書の札の欄と、注文の原文（メール・フォーム・電話のメモ）を並べて見ます。照合の印が付いたものは、注文者に確かめます
2. 頭書きの印を見る … 用途と頭書きが食い違う印があれば、注文者に確かめます
3. 配達日時を見る … 原文とワークフローが直した日付が合っているかを見ます
4. 欠けを確かめる … 確認のメールを直して送るか、電話で確かめます
5. 「制作可」にする … 確かめた内容を指示書に書き足し、注文台帳の状態を変えて、指示書を印刷します

制作の担当は、「制作可」の指示書だけを見ます。 確認の済んでいない注文は、制作の棚に置きません。当日の配達の注文で確認が間に合わないときは、店長が判断します。

例外に対処する

上の2行が大半を占めます。 どちらもAIの誤りというより、札の文言の書かれ方と法人の注文の形の問題です。 照合の不一致が多い経路は、電話のメモの打ち込み方か、フォームの札の欄の説明を見直すほうが効きます。

記録を残す

• 注文の原文（メールのメッセージID、フォームの回答の行、電話のメモの行）
• 返ってきた JSON の全文と、応答の状態
• 札の照合の結果と、頭書きの照合の結果
• ワークフローが直した配達日と、その基準にした受付の日付
• 作った指示書の文書と、受付が書き足した内容
• 注文者への確認の内容と、返事で直った項目

3つ目を残すのは、札の誤りがどこで入ったかを追うためです。 照合を通ったのに札が誤っていたなら、注文の原文がすでに誤っていたことになり、注文者との確認の記録が意味を持ちます。

最後の行は、フォームの見直しの材料になります。 同じ項目の欠けが続くなら（お供えの通夜の日時など）、フォームに必須の欄を足せば、確認の手間ごと減らせます。