営業が顧客へ送る見積の案内メールの下書きを、送る前に見積書の金額・納期・型番・有効期限と照らして校正し、食い違いと言い回しの直しを返す

処理の起点を決める

点検用のアドレスへのメールの着信を起点にします。 営業担当は、顧客へ送る前の下書きを、宛先だけ点検用のアドレスにして送ります。下書きフォルダを見張る方法も考えられますが、営業担当が書きかけの下書きまで点検に回ってしまいます。 「点検に出す」という操作を1つ挟むことで、書き終えたものだけが回ります。

Make の Gmail の Watch emails は、ラベル、送信元、件名、含む語で絞り込め、添付のあるメールだけに絞ることもできます。点検用のアドレスに届くメールに Gmail のフィルタで「見積点検」のラベルを付け、そのラベルの添付付きのメールだけを見張ります。 送信元は社内のドメインだけに絞り、社外から届いたメールは点検しません。

見張る間隔は5分にします。 営業担当は点検の結果を待ってから送るため、ここが遅いと送るのが遅れます。結果の返信は、点検に出してから数分で届く想定です。

入力データを集める

質を決めるのは、下の2つです。 顧客の一覧が無ければ、本文に残った前の顧客の社名を「社名らしい語」としか見分けられません。一覧と照らすから、「この顧客ではない社名」として挙げられます。

社内の表記の決まりは、言い回しの直しの基準になります。 「金額は税抜と税込を必ず併記する」「納期は『ご発注から〇週間』と書き、日付で約束しない」のような決まりがあれば、言い回しの直しが、好みではなく社内の決まりに沿ったものになります。

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

見積番号は、件名から先に探し、無ければ本文から探します。 正規表現で社内の見積番号の形（たとえば「Q-」で始まり、末尾に「-版の番号」が付く形）を拾います。見積番号が見つからないものは、点検を止めて営業担当に返します。 台帳と照らせないまま読み比べだけをしても、版の取り違えを拾えないからです。

Upload a File について、Make のアプリの説明には受け付けるファイルの形式が書かれていません。 Files API 自体は PDF を document のブロックで扱えるので、最初に1件のPDFで上げて file_id が返るかを確かめてから組みます。 動かなければ、Make an API Call で /v1/files へ直接上げます。

AIへ渡す前に整形する

1. 添付を PDF だけに絞る … 見積書以外の添付（仕様書や図面）が付いていることがあります。ファイル名に見積番号を含む PDF を見積書とし、それ以外は読み比べに渡しません
2. 見積書が1つかを確かめる … 見積書の PDF が2つ以上あれば、版の違うものが混ざっています。点検を止めて、営業担当に返します
3. パスワードを確かめる … 見積書にパスワードを付ける顧客向けの運用がある場合、そのままでは読めません。点検にはパスワードを付ける前の PDF を送る決まりにします
4. 本文の引用と署名を落とす … 前のやり取りへの返信として見積を送る場合、本文の下に顧客のメールが引用されています。引用を残すと、顧客が書いた数字を食い違いとして挙げてしまいます
5. 顧客を決める … 本文の先頭に書いた顧客へ送るときの宛先から、顧客の一覧の正式な社名を引きます

4番目を落とすと、指摘の半分が引用の中から出ます。 顧客が「前回は〇〇円でした」と書いていれば、それは見積書と違って当然の数字です。点検するのは、営業担当が書いた部分だけです。

AIに処理させる

させるのは、下書きの本文に書かれた事柄を見積書と1つずつ照らし、食い違いと書き方の問題を箇所ごとに挙げることだけです。

右端の列は、AIに選ばせません。項目で決まります。 金額の食い違いを「直したほうがよい」に入れられると、一覧の下のほうに回って読み飛ばされます。 何を「必ず直す」とするかは、指示の側で項目ごとに固定します。

最後の行の「約束と読める文」は、言い回しの中でいちばん大事な指摘です。 「必ず間に合わせます」「この価格で据え置きます」のような文は、見積書に書いていない約束を、メールで加えたことになります。AIは挙げるだけで、約束してよいかは営業担当と上長が決めます。

1行目を禁じるのは、全文を返させると、直す必要の無い文まで書き換わるからです。 営業担当が顧客に合わせて選んだ言い回しが、気づかないうちに消えます。返すのは箇所と直し方だけにします。

指示内容を固定する

あなたは専門商社の営業部で、顧客へ送る前の見積の案内メールを点検する係です。
メールの本文と添付の見積書（PDF）を読み比べ、直す箇所を挙げてください。
本文を書き直した全文は返さないでください。

【必ず直す（must_fix）として挙げるもの】
1. 本文の金額（小計・消費税・合計）が見積書と違う。税抜・税込の書き方が無い、
   または見積書と逆
2. 本文の数量・単価が見積書の明細と違う
3. 本文の型番・品名が見積書の明細に無い（1文字の違いも挙げる）
4. 本文の納期・有効期限・支払条件が見積書と違う
5. 本文に、送る先の顧客（{customer_name}）以外の社名が書かれている
6. 本文の見積番号が見積書と違う。「添付」と書いているが見積書の話と合わない

【直したほうがよい（suggest）として挙げるもの】
7. 誤字、敬称の誤り、社内の表記の決まり（{style_rules}）に沿わない書き方
8. 意味が曖昧な文。見積書に書かれていない約束と読める文

【厳守事項】
- 本文に書かれていない項目は、点検しないでください。
  見積書にある項目が本文に無いことは、指摘しないでください。
- 金額を自分で計算し直して、正しい値を決めないでください。
  本文と見積書の数字が違うことだけを挙げてください。
- 見積書の側が誤っていると思っても、見積書を正として扱い、
  「見積書の値も確認してください」と note に書くだけにしてください。
- draft_text には本文の該当箇所を、quote_text には見積書の該当箇所を、
  そのまま写してください。
- severity は上の番号で決まります。自分で変えないでください。
- 約束してよいか、値引きしてよいかを書かないでください。
- 引用された顧客のメールは点検の対象外です。

【送る先の顧客】{customer_name}（よく使う略称：{customer_aliases}）
【メールの件名】{subject}
【メールの本文】{draft_body}
【見積書】添付の PDF

「本文に無い項目は点検しない」を明記しないと、指摘が見積書の項目の数だけ並びます。 見積書には明細が何十行もあり、本文に書いたのはそのうちの主な型番だけです。書いていない型番について「本文に記載がありません」と並ぶと、読む気が無くなります。

「見積書を正とする」も同じ理由です。 見積書の消費税の端数の扱いを疑って本文の数字を正しいとする指摘が出ると、営業担当はどちらを直せばよいか分からなくなります。 正はいつも見積書と台帳の側に置きます。

出力形式を固定する

次の形の JSON を構造化出力で受け取ります。

{
  "quote_no_in_draft": "Q-2610-0412-3",
  "quote_no_in_pdf": "Q-2610-0412-3",
  "issues": [
    {
      "severity": "must_fix",
      "category": "amount",
      "draft_text": "合計金額は1,284,000円です",
      "quote_text": "合計（税込）1,412,400",
      "note": "本文に税抜・税込の記載が無く、見積書の税込の合計と違う"
    },
    {
      "severity": "must_fix",
      "category": "other_customer_name",
      "draft_text": "〇〇工業様向けの仕様と同じく",
      "quote_text": "",
      "note": "送る先の顧客と違う社名"
    }
  ]
}

category は amount ／ quantity_price ／ part_no ／ delivery ／ validity_terms ／ other_customer_name ／ quote_ref ／ typo_style ／ wording のどれかにします。

1つ目の理由は、severity で返信の並びを決められることです。 must_fix を上に、suggest を下にして返信を組み立てます。must_fix が0件なら、件名に「点検済み」と付けて返します。

2つ目は、draft_text と quote_text で営業担当がすぐ直せることです。 本文のどこを、見積書のどこと比べたかが並ぶので、PDF を開いて探し直す時間がかかりません。

3つ目は、quote_no_in_pdf を台帳と機械で比べられることです。 台帳の最新の版と違えば、AIの指摘とは別に「添付が最新の版ではありません」を must_fix の先頭に足します。版の比較は、ワークフローの側の条件分岐で行います。

構造化出力のスキーマでは、severity と category を列挙の型にし、additionalProperties は false にします。構造化出力は、数値の上限・下限や文字列の長さの制約に対応していないため、件数や長さの確かめはワークフローの側で行います。

システムへ連携する

返信は Reply to an email で、送信元の営業担当だけに返します。 返信の方法には「送信元だけに返す」の設定があります。下書きの本文に顧客のアドレスが書かれていても、顧客へは何も送りません。 この構成が顧客へ送るものは、1つもありません。

点検が終わったら、上げた PDF を Files API から削除します。 Make an API Call で DELETE /v1/files/{file_id} を呼びます。上げるときに期限を付けることもでき、期限は1時間から90日の間で決めます。削除し損ねたときの備えとして、1時間の期限も付けておきます。

人が確認する

営業担当は、すべての点検の結果を読みます。 点検の結果は、直す箇所の一覧です。直すのも送るのも営業担当です。

1. must_fix を全部直す … 直したら、もう一度点検に出します。2回目で must_fix が0件になってから送ります
2. suggest を読んで選ぶ … 直すかどうかは営業担当が決めます
3. 読み合わせに回すかを決める … 次のどれかに当たるものは、営業事務か上長に読み合わせを頼みます

目標は、480件をならして1件3分です。 点検に出して結果を読むのに1分、直してもう一度点検に出すのに1分、読み合わせに回る一部の見積の時間をならして1分という内訳です。

例外に対処する

6行目の書き方が大事です。 失敗したときに何も返さないと、営業担当は「指摘が無かった」と受け取って送ります。失敗は失敗として、はっきり返します。

記録を残す

• 点検に出したメールの ID、営業担当、見積番号、顧客、受け取った日時
• 台帳から引いた最新の版と合計、見積書から読んだ版
• Claude API が返した JSON の全文と、営業担当に返した返信
• 2回目以降の点検で、同じ見積番号の must_fix が0件になった日時
• category ごとの件数と、営業担当ごとの件数
• Files API の file_id と、削除した日時

category ごとの件数は、どこで誤りが起きているかを見るためです。 other_customer_name が多いなら、前のメールを写す書き方そのものをやめ、見積の案内のひな形を作るほうが早く減ります。