撮影・映像制作の見積依頼から、過去の見積と単価表を使って見積書の明細案を作る

処理の起点を決める

見積依頼のフォームの送信を起点にします。 スプレッドシートの側にフォームの送信のトリガーを付け、回答の1行が増えるたびに動かします。

依頼をメールから直接読み取る形にはしません。 依頼の書き方がばらばらで、見積に必要な条件がどこに書かれているかが決まらないからです。営業がフォームに書き写す手間は残りますが、そのときに「尺は聞いたか」「媒体は聞いたか」を営業自身が確かめる機会になります。 フォームの項目に、尺、使用する媒体、使用する期間、納品の形式、撮影の希望日を並べておきます。

再見積は、同じフォームに「元の見積番号」の欄を設けて受けます。 元の見積番号があれば、似た過去の見積を探す代わりに元の見積の明細を渡し、変わった条件だけを書かせます。

フォームの送信から見積書の下書きまでを、1回の実行で終えます。 途中で止まった場合に備えて、回答の行に「処理の状態」の列を持ち、処理済み になった行はもう一度動いても処理しません。

入力データを集める

AIへ渡す単価表は、項目コードと項目名だけにします。 単価は渡しません。単価を渡すと、AIは合計の予算感に合わせて数量を調整しようとします。 数量は案件の条件で決まるもので、金額から逆算するものではありません。

「外部見積が要る」の印は、単価表で持ちます。 出演者、ロケ地の使用料、特殊な機材、楽曲の使用料などは、案件ごとに外部の見積を取らないと金額が決まりません。この印の付いた項目は、金額を入れずに「別途」として明細に載せます。

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

似た過去の見積は、スクリプトの中で点数を付けて選びます。 ベクトル検索のような仕組みは使いません。見積台帳の列で比べれば足ります。

点数の高い順に3件を選びます。 同じ点数なら新しいものを選びます。1件ではなく3件にしているのは、1件だけだとその案件の特殊な項目まで引き継いでしまうからです。 3件に共通する項目は載せる候補として強く、1件にしか無い項目は根拠を確かめる対象になります。

再見積のときは、この点数付けを使いません。 フォームの「元の見積番号」で見積台帳を引き、元の見積の明細と条件をそのまま渡します。 似た過去の見積を混ぜると、元の見積に無かった項目が紛れ込み、「尺を縮めただけなのに項目が増えた」という見積になります。再見積で変わるのは条件だけで、比べる相手は元の見積だけです。

見積台帳の読み込みは、必要な列だけにします。 5,000件分の明細をすべて読むと時間がかかるので、案件ごとの条件の列で先に絞り、選んだ3件の明細だけを読みます。

AIへ渡す前に整形する

1. フォームの回答の空欄を確かめる … 尺、媒体、期間、納品の形式が空かどうかを記録します。空のまま進め、AIに質問を作らせます
2. 企画書の本文を整える … 貼られた本文から、あいさつや会社の紹介の部分を落とします
3. 過去の見積の明細を項目コードでそろえる … 項目コードの無い古い明細は、項目名で単価表と照らし、当たらないものは渡さずに除きます
4. 過去の見積の単価と金額の列を落とす … AIへは数量と単位までを渡します
5. 項目の一覧を添える … AIが選べるのは、この一覧にある項目コードだけです

4番目は、第7章の入力データで単価表の単価を渡さないのと同じ理由です。 過去の見積に金額が付いていると、AIは「前回と同じくらいの金額にする」方向で数量を寄せます。 金額の列を落とすだけで、この寄せ方は起きなくなります。

AIに処理させる

させるのは、項目と数量を選び、その根拠を書き、足りない条件を質問にすることです。

「抜けの候補」を明細とは別に出させるのが、この表の要点です。 過去の見積に予備日があったが今回は屋外か分からない、というとき、載せれば金額が膨らみ、載せなければ抜けます。 どちらにするかは営業が決めるので、AIには候補として並べさせるだけにします。

3行目が、いちばん起きやすい失敗です。 使用期間が空欄の依頼を渡すと、AIは「一般的には1年」と仮置きして数量を決めます。その1年が見積書に残ると、第3章の（c）がそのまま起きます。

指示内容を固定する

あなたは広告制作会社で、撮影・映像制作の見積の明細を組む立場です。
渡す見積依頼と、似た過去の見積3件だけを見て組んでください。
推測で条件を補わないでください。

【やること】
1. 項目の一覧から、今回の依頼に要る項目を選び、item_code と数量を
   書いてください。一覧に無い項目が要ると考えたときは、item_code を
   "not_in_list" とし、item_name に名前を書いてください。
2. 数量ごとに、根拠を basis に書いてください。
   依頼の記載から決めたときは、その記載をそのまま写してください。
   過去の見積から決めたときは、何件目の見積かを書いてください。
3. 過去の見積にあって、今回要るかどうか依頼からは決まらない項目は、
   明細に入れず consider に並べ、要るかどうかを決める条件を書いてください。
4. 依頼に書かれていない条件について、広告主への質問を1問ずつ
   questions に書いてください。特に、尺、使用する媒体、使用する期間、
   納品の形式、撮影の場所が空欄なら、必ず質問にしてください。

【厳守事項】
- 単価、金額、値引き、掛率を書かないでください。
- 書かれていない条件を仮に決めないでください。
  「一般的には」「通常は」を根拠にしないでください。
  条件が決まらない数量は quantity_basis を "未確定" にしてください。
- 項目の一覧に無い item_code を作らないでください。
- 単価表で「外部見積が要る」の印がある項目は、数量だけを書き、
  external を true にしてください。
- 過去の見積の特殊な項目（その案件だけの事情によるもの）を、
  そのまま引き継がないでください。3件中1件にしか無い項目は、
  明細ではなく consider に入れてください。
- 再見積のときは、元の見積から変わった条件に関わる項目だけを
  changes に書いてください。

【見積依頼】{request}
【空欄だった条件】{blank_fields}
【似た過去の見積（3件）】{past_quotes}
【項目の一覧（項目コードと項目名）】{item_list}
【外部見積が要る項目】{external_items}
【元の見積（再見積のとき）】{original_quote}

「一般的には」を根拠にしないと書いているのは、AIが仮置きするときにこの言い回しを使うからです。 言い回しを名指しで禁じると、仮置きの根拠を書けなくなり、「未確定」に回るようになります。

「3件中1件にしか無い項目は consider に」は、過去の特殊な案件を引き継がないための指示です。 3件のうち1件が雪山のロケだったからといって、今回の見積に防寒の機材が載っていては困ります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で、output_config.format に JSONスキーマを指定して返させます。

{
  "request_id": "",
  "lines": [
    {
      "item_code": "",
      "item_name": "",
      "quantity": 0,
      "unit": "",
      "quantity_basis": "確定 | 未確定",
      "basis": "",
      "external": false
    }
  ],
  "consider": [
    { "item_code": "", "item_name": "", "condition": "" }
  ],
  "questions": [
    { "field": "duration | media | period | delivery | location | other", "question": "" }
  ],
  "changes": []
}

1つ目の理由は、金額の列にAIの出力を入れないで済むことです。 lines には単価も金額も無いので、スクリプトは item_code で単価表を引き、quantity と掛けるだけです。AIの出力の形そのものが、金額を書けないようにできています。

2つ目は、quantity_basis で未確定の数量を分けられることです。 未確定 の行は、見積書では数量の欄を空けて「条件確定後にお見積り」と書きます。仮置きの数量で金額を出すことがなくなります。

3つ目は、questions の field で、質問を条件ごとにまとめられることです。 広告主へのメールには、媒体と期間の質問を先に並べます。使用料に響く条件から答えてもらうためです。

たとえば「新商品の紹介動画、30秒、スタジオ、人物あり、使用する媒体と期間は空欄」という依頼なら、下書きは次のようになります。

出演者の行は、数量だけが入り金額は「別途」になります。 使用する媒体と期間が決まり、外部の見積が取れた時点で、営業が金額を入れます。

スクリプトの側で確かめることもあります。

構造化出力では、数値の範囲の制約をスキーマに書けないとされているため、数量が0以下でないかはスクリプトの側で確かめます。

システムへ連携する

見積台帳には書き込みません。 見積台帳に載るのは、広告主へ送った確定の見積だけです。下書きの段階で書き込むと、似た過去の見積を探すときに、確かめていない明細が参考として選ばれてしまいます。

広告主へはメールを送りません。 知らせる先は社内の営業だけで、見積書を送るのも、質問を送るのも営業です。

人が確認する

1. 営業が consider を判断する … 候補として並んだ項目を、載せるか外すか決めます。予備日、ヘアメイク、縦型の書き出しなどがここに並びます
2. 営業が 未確定 の行を確かめる … 数量が空いている理由が、質問に対応しているかを見ます
3. 営業が根拠を読む … basis を見て、数量の決め方が今回の依頼に合っているかを確かめます
4. プロデューサーが明細を確かめ、掛率を決める … 金額はここで初めて見積として確定します
5. 営業が質問を広告主へ送る … 質問の言い方は、広告主に合わせて直します

1番目が、この構成の価値のほとんどです。 抜けやすい項目が、営業が思い出すかどうかに関係なく、候補として目の前に並びます。 載せるかどうかの判断は残りますが、思い出す作業はなくなります。

目標は、1件あたり12分です。 明細を一から組む作業がなくなり、確かめる・選ぶ・直す作業だけが残る想定です。

例外に対処する

最後の行は、見落とされがちです。 インストール型トリガーは作った人のアカウントで動くので、その人のアカウントが止まると、見積の下書きも止まります。 誰のアカウントで作ったかを記録に残しておきます。

記録を残す

• フォームの回答と、空欄だった条件
• 選んだ過去の見積3件の見積番号と、その点数
• AIへ渡した入力と、返ってきたJSONの全文
• 作った見積書の下書きのファイル
• 営業とプロデューサーが直した記録 … 足した項目、消した項目、変えた数量
• 広告主へ送った最終の見積書の見積番号

選んだ過去の見積の番号を残すのは、明細案の根拠をたどるためです。 数量の根拠が「2件目の見積」なら、その見積を開いて確かめられます。

直した記録は、単価表と点数の付け方を直す材料になります。 同じ項目を毎回足しているなら、それは過去の見積に無い項目です。選ぶ過去の見積の点数の付け方を変えるか、単価表の項目を見直します。

consider を載せたか外したかの記録も、項目ごとに数えます。 載せる割合が高い項目は、案件の条件から決まる規則として明細の側へ移せます。たとえば「人物あり」ならヘアメイクを必ず載せる、という規則です。規則にできたものはスクリプトへ移し、AIに判断させる範囲を狭めていきます。