生花店が葬儀の供花の注文を Make で受け、葬家・札名・届け先・時刻を抜き出して、式場ごとの手配の一覧を作る

処理の起点を決める

経路は3つで、入口は2つです。 Web の注文フォームと店内用のフォームは、送信と同時に Custom webhook に届きます。葬儀社の取りまとめのメールは、Gmail の Watch emails で拾います。 Watch emails のフィルターには、条件を選ぶ簡単なフィルターと、Gmail の検索の書き方で指定する方法があり、1回に扱う上限は500件以下とされています。

Watch emails は5分ごとに動かします。 通夜の当日の昼に届いた注文を、夕方の搬入に間に合わせるためです。Gmail の検索の書き方で、取引のある葬儀社の送信元のアドレスだけに絞ります。 個人からのお悔やみのメールや広告は拾いません。

拾ったメールにはラベルを付けます。 「処理済み」のラベルは、手配表への書き込みまで通ったときだけ Update email labels で付けます。既読にする設定は使いません。 店員が先にメールを開くと、「未読だけ」の設定では拾われなくなるからです。

電話の注文は、店内用のフォームに打ち込んでもらいます。 紙のメモを残すと、写す作業が残ります。項目は分けず、聞いたことをそのまま書く1つの欄と、受けた店員の名前だけにします。 電話を受けながら項目を選ぶ余裕は無く、分けるのは AI の仕事です。

入力データを集める

質を決めるのは、式場の台帳の通称の列です。 注文には「◯◯会館」「◯◯斎場の2階」「◯◯ホール東館」のように、正式な名前ではない呼び方で書かれます。通称を並べておけば、抜き出した呼び方から式場を引けます。 台帳に無い呼び方は、要確認に回して台帳に足します。

手配表は、葬家の候補を付けるために読みます。 同じ式場・同じ日の通夜の行が手配表にあれば、それが同じ葬家の候補です。

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

Web の注文は、項目ごとに分かれたまま Webhook に届きます。 それでも Claude に渡すのは、備考の欄に札名や届けの指定が書かれることが多いからです。項目と備考を1つの文面にまとめて渡し、備考に書かれた指定も抜き出させます。

葬儀社のメールの本文は、HTML のことがあります。 Make の側で文字だけにしてから渡します。表の形の本文を文字にすると、項目名と値が離れることがあるので、改行を残す形で文字にします。 1通のメールに複数の注文が並んでいることがあるので、1通から注文の配列で返させます。

締めの時刻は、Make が出します。 抜き出した通夜の開始の日時から、式場の台帳の「何時間前」を引いた時刻です。告別式だけに届ける注文は、告別式の開始から引きます。 どちらに届けるかが注文に書かれていなければ、通夜に間に合わせる前提で締めを出し、要確認の印を付けます。

Iterator は、配列を1件ずつのバンドルに分けるモジュールとされています。 Array の欄に orders を入れます。配列の中身の形を Iterator が知らないうちは、対応づけの画面に件数と順番しか出ないとされているので、作るときに一度、取りまとめのメールでシナリオを動かして形を覚えさせます。

Search Rows の Limit は1にしません。 同じ式場・同じ日の行が2つの葬家に分かれて返ったら、同じ日に同じ式場で2件の葬儀があるか、書き写しの誤りです。どちらも店員が確かめます。

AIへ渡す前に整形する

1. 送信元の確認 … メールは取引のある葬儀社の送信元か確かめます。違えば処理しません
2. 本文を文字にする … HTML を改行つきの文字にし、署名と過去のやり取りの引用を外します
3. 文面をまとめる … Web の注文は、項目名と値を「項目名：値」の行にして備考と一緒に1つの文面にします
4. 受信日時を添える … 「明日の通夜」のような書き方を日付にするため、受信の日時を一緒に渡します
5. 同じ注文の二度目を外す … Webhook の注文番号、メールの ID が処理済みの一覧にあれば処理しません

4番目が、日時の取り違えを減らします。 「明日」「今夜」を日付にするには、いつ書かれたかが要ります。受信の日時を渡し、どう読んだかを date_basis に書かせます。

注文者の電話番号は渡します。 店員が確かめの電話をかけるときに使うので、抜き出させずに、Make が元の項目から手配表に写します。 AI の出力には含めません。

AIに処理させる

させるのは、注文の文面から次の項目を原文の表記のまま抜き出すことだけです。

札名を整えさせない理由は、第1章のとおりです。 加えて、札名に読めない字や旧字があっても直させません。 「髙」「﨑」のような字を「高」「崎」に直すと、立札では別の名前になります。

指示内容を固定する

あなたは生花店で、葬儀の供花の注文を受け付ける担当です。
渡された注文の文面から、手配に必要な項目を抜き出してください。
文面に書かれていることだけを使い、推測で埋めないでください。

【抜き出す項目】
- 葬家・故人・喪主：書かれたとおりに写す
- 式場：書かれた呼び方のまま写す。正式な名前に直さない
- 通夜・告別式の日時：YYYY-MM-DDTHH:MM にする。
  「明日」「今夜」などは受信日時を基準に日付にし、date_basis に元の言葉を写す
- 届ける先の式：wake（通夜）／funeral（告別式）／unspecified
- 札名：書かれたとおりに一字も変えずに写す。改行の位置は「／」で示す
- 商品と数量、請求先、指定と注意

【厳守事項】
- 札名を整えない。役職・敬称・「一同」・会社の種類を足したり削ったりしない。
  旧字や異体字を常用の字に直さない。
- 札名が複数あるときは、1つずつ別の要素にする。連名は1つの札名として写す。
- 1つの文面に複数の注文があれば、orders に1件ずつ分ける。
- 通夜と告別式のどちらの日時か分からない時刻は、どちらにも入れず notes に書く。
- 年が書かれていないときは、受信日時より後で最も近い日付にし、
  year_inferred を true にする。
- 締めの時刻、持ち込みの可否、花の色や形を考えない。
- 電話番号やメールアドレスは抜き出さない。

【受信日時】{received_at}
【経路】{channel}
【文面】{text}

「連名は1つの札名として写す」を入れているのは、立札の数を間違えないためです。 「◯◯・◯◯」と2人の名前が並んだ札は1基の札で、2基の注文ではありません。分けてしまうと、立札が2本になり、花の数も2倍で手配されます。

「改行の位置は『／』で示す」も効く一文です。 会社名と役職と名前を3行で書く札は、行の分け方まで注文者の指定です。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "orders": [
    {
      "family": "◯◯家",
      "deceased": "故 ◯◯ ◯◯ 様",
      "chief_mourner": "◯◯ ◯◯",
      "venue_text": "◯◯会館 2階",
      "wake_at": "2026-11-05T18:00",
      "funeral_at": "2026-11-06T11:00",
      "date_basis": "明日18時より通夜",
      "year_inferred": false,
      "deliver_to": "wake",
      "card_names": ["株式会社◯◯／代表取締役社長／◯◯ ◯◯"],
      "item": "供花", "quantity": 1, "unit": "基",
      "bill_to": "株式会社◯◯",
      "instructions": ["白でまとめて"],
      "notes": ""
    }
  ]
}

1つ目の理由は、1通から複数の注文を受けられることです。 葬儀社の取りまとめのメールには、10件の注文が並ぶことがあります。orders の配列を Make の Iterator で1件ずつに分け、手配表の1行ずつにします。

2つ目は、null と unspecified でルーターを分けられることです。

Make のルーターは、ルートを順に処理し、ほかのどのルートの条件にも合わないものをフォールバックのルートで処理するとされています。フォールバックは、どの条件にも当たらなかった想定外のものを要確認に落とす場所にします。

3つ目は、札名が配列で残ることです。 手配表には札名を1行に1つずつ置き、店員は原文の札名と並べて一字ずつ見比べます。

手配表の1行は次の形にします。

システムへ連携する

手配表の列の対応は、見出しの名前で持たせます。 Google Sheets のモジュールには、見出しの名前を列の ID として使う設定があり、見出しを変えなければ列を並べ替えても対応が崩れないとされています。配達の担当が列を並べ替えることがあるので、この設定を使います。

Make an API Call の本文には、モデル名、出力の上限のトークン数、messages に指示文と注文の文面、output_config.format に第7章の形の JSON Schema を書きます。 構造化出力では、オブジェクトに additionalProperties: false を付ける必要があり、数値の範囲や文字列の長さの制約は使えないとされています。数量が1以上か、といった確かめはルーターの条件で行います。

注文者への返信は自動で送りません。 受付の確認が要る経路では、店員が手配の一覧を確かめたあとに電話かメールで伝えます。札名の誤りがある状態で「承りました」と返すと、直す機会を逃します。

人が確認する

1. 要確認の一覧を先に見る … 台帳に無い式場、持ち込みが不可の式場。葬儀社に電話で確かめます
2. 札名を原文と見比べる … 手配表の札名と、注文の原文（Webhook の中身かメール）を並べ、一字ずつ見ます
3. 日時と届ける先を見る … 通夜か告別式か、締めの時刻が間に合うかを見ます
4. 葬家の候補を決める … 2つに分かれた行は、故人・喪主の名前で決めます
5. 「確認済み」にする … 確かめた店員の名前を状態の列に入れます

2番目を省かないでください。 札名の誤りは、式場に並んだ時点で取り返しがつきません。 抜き出しの誤りより、注文者の書き間違いのほうが多いこともあり、会社の正式な名前や役職が怪しいものは注文者に聞きます。

立札の並び順は、この構成では決めません。 式場での供花の並びは、葬儀社が喪家と相談して決めることが多く、店が手配表の順で並べると、喪家の意向と違うことがあります。 手配表には届いた順を残すだけにし、並び順の指示は葬儀社から受けます。

目標は、360件をならして1件3分です。 Web の注文は項目がそろっているので見比べるだけ、電話と葬儀社のメールは原文を読み直すので長くかかります。

例外に対処する

最後の行は、会社の注文で起きやすいものです。 総務の担当が Web で頼み、同じ会社の営業が葬儀社にも頼む、ということがあります。

上の2行が、店の判断が要るものです。 持ち込みの可否は葬儀社と式場の決まりで、変わったときに台帳を直すのは店の仕事です。

記録を残す

• 注文の原文（Webhook の中身、メールの ID と本文）と受信の日時
• Claude が返した JSON の全文
• 引いた式場の台帳の行と、出した締めの時刻
• 手配表の行に加えた変更と、確認済みにした店員
• 注文者・葬儀社に確かめた内容
• 要確認に回した理由

3つ目で「引いた台帳の行」を残すのは、式場の決まりが変わるためです。 搬入の締めが早まったあとで「間に合わなかった」ことが起きたら、そのとき台帳が直っていたかを行の記録で確かめられます。

最後の行は、月に一度数えます。 「台帳に無い式場」が多ければ通称の列の手入れが、「札名が無い」が多ければ Web の注文フォームの項目の見直しが要ります。