印刷会社の営業が、新しい見積の依頼に近い過去の受注を、紙・加工・部数・判型の仕様から探し、当時の原価の内訳と仕様の違いを並べる

処理の起点を決める

起点は2つあります。毎晩の取り込みと、営業のボタンです。

毎晩の取り込みは、基幹の仕組みからその日に原価が確定した受注を書き出して索引に足します。原価が確定していない受注は入れません。 見積の金額だけで原価の無い記録は、見積の材料になりません。

ボタンは、営業が依頼の文を画面に貼った後に押します。部数が複数ある依頼（3,000部・5,000部・10,000部の見積）は、部数ごとに探して並べます。 部数で原価の内訳の割合が大きく変わるからです。

入力データを集める

質を決めるのは、紙の表です。 紙の厚さは、連量（決まった寸法の紙1,000枚の重さ、kg）と坪量（1平方メートルあたりの重さ、g/m²）の2つの書き方があり、連量は紙の寸法（四六判・菊判など）によって同じ紙でも値が変わります。 工務の担当が、銘柄と寸法ごとに坪量への換算を表にし、取り込みですべて坪量にそろえます。

原価の内訳は、項目を分けたまま持ちます。 合計だけでは、紙代を今の値段で置き換えられません。

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

索引の主な項目は次のとおりです。

PUT /print_jobs
{ "mappings": { "properties": {
    "job_no":       { "type": "keyword" },
    "product":      { "type": "keyword" },
    "size":         { "type": "keyword" },
    "pages":        { "type": "integer" },
    "paper_type":   { "type": "keyword" },
    "paper_gsm":    { "type": "float" },
    "paper_brand":  { "type": "keyword" },
    "colors":       { "type": "keyword" },
    "qty":          { "type": "integer" },
    "qty_log10":    { "type": "float" },
    "ordered_on":   { "type": "date" },
    "processes": { "type": "nested", "properties": {
      "kind":   { "type": "keyword" },
      "side":   { "type": "keyword" },
      "vendor": { "type": "keyword" } } },
    "cost": { "properties": {
      "paper": { "type": "integer" }, "plate": { "type": "integer" },
      "press": { "type": "integer" }, "finishing": { "type": "integer" },
      "outsourced": { "type": "integer" }, "delivery": { "type": "integer" } } },
    "order_amount": { "type": "integer" }
} } }

部数は対数（qty_log10）でも持ちます。 3,000部と6,000部の違いと、30,000部と60,000部の違いは、原価の構造の上では同じくらいの違いです。部数のまま近さを測ると、大きな部数の案件ほど近さが厳しくなります。 対数にすれば、「倍・半分」を同じ幅で扱えます。

探す形は次のとおりです（依頼は A4・16ページの冊子、5,000部）。

POST /print_jobs/_search
{ "query": { "function_score": {
    "query": { "bool": {
      "filter": [
        { "term":  { "product": "booklet" } },
        { "term":  { "size": "A4" } },
        { "range": { "pages": { "gte": 12, "lte": 20 } } },
        { "exists": { "field": "qty_log10" } },
        { "exists": { "field": "ordered_on" } } ],
      "should": [
        { "term":  { "paper_type": "matte_coated" } },
        { "range": { "paper_gsm": { "gte": 115, "lte": 140 } } },
        { "term":  { "colors": "4/4" } },
        { "nested": { "path": "processes",
            "query": { "term": { "processes.kind": "pp_matte" } },
            "inner_hits": {} } },
        { "nested": { "path": "processes",
            "query": { "term": { "processes.kind": "saddle_stitch" } } } } ] } },
    "functions": [
      { "gauss": { "qty_log10": { "origin": 3.7, "offset": 0.1, "scale": 0.3 } } },
      { "gauss": { "ordered_on": { "origin": "now", "offset": "180d", "scale": "730d" } } } ],
    "score_mode": "multiply",
    "boost_mode": "multiply" } },
  "size": 10 }

qty_log10 の origin は依頼の部数の対数（5,000部なら約3.7）です。 scale の0.3は部数でおよそ2倍・半分にあたり、そこで点数が半分になります。受注日は半年までは満点、そこから2年で半分にします。

加工は nested で持ちます。 公式のドキュメントでは、物の配列は各項目の値が平らにまとめて持たれ、どの値が同じ物のものかが分からなくなります。 nested にすると各物が別の隠れた文書として持たれます。「マットPPを表紙の片面に」と「グロスPPを両面に」のように、加工の区分と面の組み合わせを崩さずに探すためです。 nested の検索は親の文書を返すので、inner_hits で当たった加工を画面に出します。

AIへ渡す前に整形する

1. 紙の厚さを坪量にそろえる … 紙の表で、連量（kg）と寸法から坪量（g/m²）を引きます。表に無い銘柄は paper_gsm を入れず、印を付けます
2. 紙の種類をそろえる … 銘柄から、コート・マットコート・上質・特殊紙などの区分を引きます
3. 加工の呼び方をそろえる … 加工の表で、呼び方を区分と面に分けます（「表紙のみマットPP」→ pp_matte・cover）
4. 判型と品目をそろえる … 「A4」「210×297」を同じ値に、「パンフ」「会社案内」を品目の区分に当てます
5. 部数の対数を足す … qty_log10 を計算して入れます
6. 原価が確定していない記録を外す … 原価の内訳が空の受注は取り込みません
7. 依頼の文を整える … 得意先の担当者の名前と電話番号は、Claude に渡す前に伏せます

1番目を軽く見ないでください。 坪量が入らない記録は、紙の厚さの range に当たらず、紙の近さで点数が上がりません。表に無い銘柄の一覧を毎月出し、工務の担当が表に足します。

AIに処理させる

AIの仕事は、依頼の文から探すための仕様を取り出すことだけです。 探すのも、近さを測るのも、原価を並べるのも、規則と索引の仕事です。

「換算をさせない」が、いちばん大事な線です。 連量から坪量への換算は紙の寸法によって変わり、AIがもっともらしい値を出すと、表の換算と食い違ったときに追えません。 換算は前処理の表だけで行います。

「見積の金額を出さない」も明記します。 依頼の文に「前回と同じくらいで」と書かれていても、金額は営業が決めます。

指示内容を固定する

あなたは印刷会社の営業を手伝う立場です。
得意先からの見積の依頼の文から、過去の案件を探すための仕様を取り出してください。
書かれていることだけを使い、推測で補わないでください。

【取り出すもの】
- product: 品目を【品目の区分】のどれかに当てる。決められなければ "unknown"
- size: 仕上がりの判型（書かれたまま）
- pages: ページ数。書かれていなければ null
- colors: 色数（表/裏）。書かれていなければ null
- paper: 紙の銘柄と厚さを、書かれた表記のまま（"マットコート 110kg" など）
- processes: 加工を【加工の区分】に当て、面（表紙・本文・片面・両面）も書く
- quantities: 部数をすべて。複数あれば配列で
- due: 納期（書かれたまま）
- missing: 探すのに足りない仕様

【厳守事項】
- 紙の厚さを換算しないでください。kg を g/m² に、g/m² を kg に直さないでください。
- 書かれていない紙・色数・加工を、品目からの一般論で補わないでください。
  例：冊子だから中綴じ、とは決めないでください。missing に入れてください。
- 「8P」「8頁」は8ページとしてください。
  「4枚両面」のような書き方は、ページ数に直さず missing に書いてください。
- 金額、単価、値引きを書かないでください。
  依頼の文に前回の金額が書かれていても、取り出さないでください。
- 加工の面が書かれていなければ、面を "unspecified" にしてください。

【品目の区分】{product_list}
【加工の区分】{process_list}
【依頼の文】{request_text}

「冊子だから中綴じと決めない」を明記しないと、AIは品目から加工を補います。 16ページの冊子なら中綴じが多いのは確かですが、無線綴じで頼まれていれば原価がまったく違います。 書かれていない加工は、営業が得意先に確かめることにします。

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、次の形で受け取ります。

{
  "product": "flyer | leaflet | brochure | booklet | envelope | ... | unknown",
  "size": "",
  "pages": null,
  "colors": null,
  "paper": { "as_written": "" },
  "processes": [ { "kind": "pp_matte | pp_gloss | saddle_stitch | perfect_bind | foil | die_cut | ...",
                   "side": "cover | body | one_side | both_sides | unspecified" } ],
  "quantities": [0],
  "due": "",
  "missing": [""]
}

公式のドキュメントでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。product と processes.kind を enum で閉じ、表に無い区分が返らないようにします。 数値の範囲の制約には対応していないので、ページ数と部数の値の確かめは Lambda で行います。

1つ目の理由は、仕様の項目がそのまま検索の条件になることです。 product と size は filter、paper は前処理の表で坪量にして range、processes は nested の条件になります。

2つ目は、quantities を部数ごとの検索に分けられることです。 配列の数だけ、qty_log10 の origin を変えて探します。

3つ目は、missing がそのまま得意先への確認になることです。

画面に出す候補の一覧は、検索の結果から Lambda が作ります。

「時期の注意」の列が、この一覧でいちばん大事な列です。 紙の値段の改定の日を工務の担当が表にしておき、受注日より後に改定があれば「紙代は改定前の値段」と印を付けます。

システムへ連携する

見積の表計算とはつなぎません。 候補の原価を見積に写すのは営業の手です。写す手間を残すのは、今の値段に置き換える判断をその場で必ず通すためです。

人が確認する

1. 取り出した仕様を見る … 特にページ数、加工の面、部数を確かめます
2. missing を得意先に聞く … 紙の指定が無い、加工の面が分からない、などを確かめます
3. 時期の注意を見る … 紙の値段の改定の前の案件なら、紙代を今の値段で置き換えます
4. 外注先を見る … 加工の外注先が今も同じかを確かめます

3番目を省かないでください。 一覧の原価は当時の原価です。今の見積に使えるのは、仕様の近さと原価の構造で、金額そのものではありません。

例外に対処する

4行目は、減衰の関数の性質によるものです。 項目が無いと満点になるので、条件で外さなければ、部数の分からない古い記録が上に並びます。

記録を残す

• 検索ごとの、依頼の文（伏せたもの）、取り出した JSON、営業が直した箇所
• 検索の条件と、広げた条件
• 候補の一覧と、営業が参考にした案件
• 最終の見積の金額と、その後の受注の結果（受注・失注）

最後の行を残すのは、参考にした案件と見積の結果を結び付けるためです。 同じ案件を参考にして失注が続くなら、その案件の原価の構造が今に合っていない可能性があります。