印刷会社のWebの見積依頼をスプレッドシートに受け、仕様を単価表の区分に読み替えて概算を出し、確認事項付きの返信を下書きする

処理の起点を決める

回答のスプレッドシートのフォーム送信をきっかけにします。 依頼が届いた直後に動くので、営業の担当が下書きを開くときには、読み替えと金額がそろっています。 相見積もりでは返信の早さが効くので、1日1回の定時実行にはしません。

処理は1件ずつ行い、回答の行の「処理状態」の列に「下書き済み」「要確認」「失敗」を書きます。 失敗した行は、1時間ごとの時間主導型のトリガーで拾い直します。処理状態が空のまま残っている行が、未処理の数です。

単価表の改定は、トリガーの外で行います。単価表のシートに改定日の列を持ち、計算に使った改定日を回答の行に残します。 改定の前後で同じ依頼の金額が違っても、どちらの表で出したかが分かります。

入力データを集める

区分の一覧は、たとえば次のような形にします。

質を決めるのは、区分の一覧と聞くべき点の一覧です。 区分の一覧に「つるつる」「光沢」がコート紙の言い方として載っていれば、読み替えは安定します。ベテランの担当の頭の中にあった読み替えを、この一覧に書き出すのが最初の作業です。

聞くべき点の一覧を表で持つのは、品目ごとに違うからです。 冊子ならページ数と綴じ方、名刺なら人数と両面か、ポスターなら掲示場所（屋外か）。一覧にあって依頼に無い項目は、AIに判断させず、スクリプトが確認事項に入れます。

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

選択肢の欄は、AIに渡しません。 「A4」「1,000部」「4色」のように選択肢で答えられた欄は、区分IDへの対応表で決まります。AIに通すと、正しい値が書き換わる余地が増えるだけです。 AIに渡すのは、自由記入の欄と備考、それに選択肢の欄の値（読み替えの手がかりとして）です。

区分の一覧は、品目で絞ってから渡します。 名刺の依頼に冊子用の用紙まで渡すと、選ぶ先が増えて読み替えがぶれます。

AIへ渡す前に整形する

1. 品目の確定 … 品目の欄で、使う単価表と区分の一覧を決めます。「その他」なら読み替えをせず人へ回します
2. 文字の正規化 … 全角の数字を半角に、「1000」「1,000」「千部」を数にそろえます
3. 部数の確認 … 単価表の部数の段階の範囲外（極端に少ない・多い）は、計算をせず人へ回します
4. 納期の日付化 … 「○月○日必着」は日付に、「なるべく早く」は空にして確認事項へ回します
5. 聞くべき点の照合 … 聞くべき点の一覧と回答を比べ、欠けている項目を確認事項の候補にします
6. 区分の一覧の作成 … 品目に合う区分のIDと名称と言い方を、スキーマの enum とプロンプトに入れます

6番目を軽く見ないでください。 区分IDを enum にしておけば、単価表に無い区分IDが返ってくることがありません。 表に無い区分で金額を出そうとして、計算が止まる失敗を前もって消せます。

AIに処理させる

させるのは、自由記入の仕様を区分IDの候補に読み替えることと、確認事項と返信の文面を書くことです。

最後の行が、この構成でいちばん大事な決まりです。 返信の文面には、金額を {estimate} のような差し込み位置として置かせ、数字はスクリプトが計算した値を後から入れます。 AIが文面の中で金額を書くと、計算した値と違う数字が紛れ込む余地が残ります。

2行目がいちばん起きやすい失敗です。 「和紙風の紙」のように区分の一覧に無い言い方が来ると、AIは近い区分を選んで埋めたがります。埋めると、扱っていない紙の金額を答えたことになります。 区分の一覧に無いものは「該当なし」と返させ、人に回します。

指示内容を固定する

あなたは印刷会社の営業部で、Webの見積依頼の仕様を自社の単価表の区分に読み替える担当です。
依頼に書かれていることだけをもとに判断してください。推測で埋めないでください。

【やること】
1. 自由記入と備考に書かれた用紙・サイズ・色数・加工を、【区分の一覧】の区分IDに読み替える
2. 読み替えの根拠にした依頼の文字列を evidence にそのまま写す
3. 1つに決まらないものは、候補を最大3つまで並べ、status を ambiguous にする
4. 書かれていないものは status を missing にする
5. ambiguous と missing のものと、【聞くべき点の欠け】を、依頼者に尋ねる質問文にする
6. 返信の文面を書く

【厳守事項】
- 区分IDは【区分の一覧】にあるものだけを使ってください。
  一覧に当てはまらない言い方（例：和紙風、金色の箔）は、status を not_in_list にし、
  候補を作らないでください。
- 金額を計算しないでください。返信の文面の中にも数字の金額を書かないでください。
  金額を書く位置には {estimate} とだけ書いてください。
- 納期に間に合うとは書かないでください。「工場の予定を確認のうえ、改めてご連絡します」
  の趣旨にとどめてください。
- 値引き、特急料金、印刷の可否には触れないでください。
- 質問は1つの文で1つのことだけを尋ね、依頼者が選びやすいよう選択肢を添えてください。
- 印刷の用語を使うときは、依頼者の書いた言い方を括弧で添えてください。
- 返信の文面は、依頼者の名前の宛名から始め、概算であることを最初に断ってください。

【依頼の選択肢の欄】{selected_fields}
【自由記入と備考】{free_text}
【区分の一覧】{category_list}
【聞くべき点の欠け】{missing_checklist}

「金額を書く位置には {estimate} とだけ書く」を明記しないと、数字を書きます。 単価表を渡していなくても、印刷の相場らしい金額を文面に入れることがあります。禁じるのは、金額の数字を文面で作ることそのものです。

「一覧に当てはまらない言い方は候補を作らない」も同じ理由です。 何も言わなければ、いちばん近い区分を候補の1つ目に置き、扱っていない仕様の金額が概算として出ていきます。

出力形式を固定する

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

{
  "specs": [
    { "field": "paper | size | color | finishing",
      "status": "ok | ambiguous | missing | not_in_list",
      "candidates": ["coat_110", "coat_135"],
      "evidence": "つるつるした少し厚めの紙" }
  ],
  "questions": [ "" ],
  "reply_body": "",
  "needs_human": false
}

1つ目の理由は、candidates を区分IDの配列にしておけば、金額の幅がそのまま計算できることです。 候補が1つならその金額、2つ以上なら最小と最大を出します。スキーマで区分IDを enum にしておけば、表に無いIDは返りません。

2つ目は、status で人へ回すかを機械的に決められることです。 not_in_list が1つでもあれば needs_human を立て、下書きを作らずに担当へ回します。needs_human をAIにも返させますが、スクリプトの側でも status から決め直し、どちらかが立てば人へ回します。

3つ目は、evidence で確認が速くなることです。 担当は、どの言い方をどの区分と読んだかを、依頼を開き直さずに読めます。

スクリプトは reply_body の {estimate} に、計算した金額（幅の場合は「○円〜○円（税別）」）を入れてから下書きにします。{estimate} が文面に無いか、2つ以上あれば、下書きを作らずに人へ回します。

システムへ連携する

Gemini API への要求は、次のような本体を UrlFetchApp で POST します（キーは x-goog-api-key のヘッダーに入れます）。

{
  "model": "<利用するGeminiのモデル>",
  "input": "（プロンプトの全文。依頼の欄・自由記入・区分の一覧・聞くべき点の欠けを差し込んだもの）",
  "response_format": {
    "type": "text",
    "mime_type": "application/json",
    "schema": { "type": "object", "properties": { "specs": {}, "questions": {}, "reply_body": {}, "needs_human": {} },
                "required": ["specs", "questions", "reply_body", "needs_human"] }
  }
}

schema の中身は前の小見出しの形を JSON Schema で書いたもので、candidates の要素は品目ごとの区分IDの enum にします。enum の中身は品目ごとに変わるので、スキーマはスクリプトが区分の一覧から毎回組み立てます。 返ってきたテキストを JSON として読めなければ、処理状態を「失敗」にして拾い直しに回します。

メールは送らず、下書きを作ります。 GmailApp の createDraft は、公式の説明では、宛先・件名・本文と追加の引数で下書きを作り、HTML の本文（htmlBody）、送信者の名前（name）、返信先（replyTo）などを指定できます。送信は、担当が下書きを開いて直してから行います。

基幹の受注システムには書き込みません。 この構成が出すのは概算の返信までで、正式な見積と受注は既存の経路です。

公式の割り当ての表では、URL Fetch の呼び出しは個人のアカウントで1日20,000回、Google Workspace のアカウントで1日100,000回、1回の実行は6分までです。月400件なら、どちらにも遠く届きません。 Gemini API のキーはスクリプトのプロパティに置き、コードに書きません。

人が確認する

全件の下書きを担当が開きます。 ただし、見るところを3つに絞ります。

回答のスプレッドシートには、1依頼1行で「区分の読み替え（evidence つき）」「金額（幅）」「質問の数」「印」の列を並べ、担当はまずこの一覧で今日の依頼を眺めてから、下書きを順に開きます。 一覧で見れば、同じ言い方が何件も ambiguous になっていることにも気づけます。

1. 読み替えの結果 … evidence と選ばれた区分を見比べます。候補が複数のものは、返信の質問で尋ねる形になっているかを見ます
2. 金額 … 部数の段階と加工の加算が正しく入っているか。幅が大きすぎるときは、候補を絞れないかを考えます
3. 確認事項と文面 … 質問の数が多すぎないか。納期の約束や値引きの言葉が入っていないか

「納期確認」の印がある依頼は、工場に確かめてから送ります。 印があるまま送ると、間に合わない納期を引き受けたように読まれます。

needs_human の依頼は、下書きがありません。 担当がゼロから返信を書きます。月に1割前後という想定で、それより多い月は区分の一覧の言い方が足りていません。

目標は、400件をならして1件6分です。 15分のうち、読み替えと表引きが無くなり、直す作業が残ります。

例外に対処する

上の3行が大半です。 どれもAIの問題ではなく、単価表と区分の一覧の範囲の問題です。 「要確認」が多い品目は、区分の一覧か単価表を広げる候補です。

記録を残す

• 回答の行（依頼の全項目）と受け取った日時
• AIに渡した区分の一覧の版と、単価表の改定日
• Gemini API が返したJSONの全文
• 計算した金額（候補ごと）と、下書きに入れた金額
• 担当が直した記録 … 区分の読み替えを変えたか、金額を変えたか、質問を足したか削ったか
• 返信した日時と、正式な見積・受注に進んだか

5つ目が、区分の一覧を育てる材料になります。 担当が同じ言い方の読み替えを何度も直しているなら、その言い方を区分の一覧に足します。ベテランの読み替えが、記録を通じて表に移っていきます。

最後の行は、返信の早さが受注に効いているかを見るためのものです。 返信までの時間と受注の有無を並べて、構成の効き目を自社の数字で確かめます。