紙の代理店が、印刷会社・製本会社からの銘柄・連量・寸法の問い合わせを OpenSearch で引き、在庫と代わりの紙を違いを添えて返す

処理の起点を決める

起点は2つあります。1時間ごとの商品と在庫の取り込みと、営業の担当の検索のボタンです。

取り込みは、販売と在庫の管理の仕組みから、品目の追加と在庫の変化を書き出して索引を更新します。索引の在庫は「あるか無いか」の目安にだけ使い、回答に書く数は必ず照会で取り直します。 1時間の間に別の営業が引き当てた分は、索引には入っていないからです。

検索のボタンは、営業の担当が問い合わせを貼るか電話のメモを打ち込んだ後に押します。受発注の画面から来た問い合わせは、品目の番号が付いていればそのまま照会し、自由記述なら読み替えから動かします。 FAX は担当者が読んで打ち込みます。略称の辞書は週に1回更新します。

入力データを集める

質を決めるのは、判の寸法の表です。 米坪の計算はこの表の面積で決まります。断裁した寸法の品目は、判ではなく実際の寸法の面積で計算します。 表に無い判の品目は、米坪を空のまま残します。

得意先の名前と担当者の名前は、生成AIに渡しません。 問い合わせの本文に書かれていれば、伏せてから渡します。

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

代わりの紙は function_score の gauss で米坪の近さを点数にします。 OpenSearch の公式のドキュメントでは、減衰の関数は origin からの距離で点数を下げ、offset の内側は点数1、scale＋offset の距離で decay（既定0.5）の点数になるとされています。元の紙の米坪を origin に、±2g を offset に、8g を scale にすると、±2g は同じ扱い、±10g で点数が半分になります。

ここで大事なのが、exists の絞り込みです。 公式のドキュメントでは、減衰の関数は項目の無い文書に点数1を返すとされています。米坪が空の品目は、元の紙とちょうど同じ米坪の品目と同じ点数で上位に並びます。exists で米坪のある品目に絞り、空の品目は別に「米坪の記録なし」として出します。

GET /papers/_search
{
  "size": 10,
  "query": { "function_score": {
    "query": { "bool": {
      "filter": [
        { "term":   { "paper_type": "matte" } },
        { "term":   { "grain": "T" } },
        { "term":   { "size_class": "shiroku" } },
        { "term":   { "in_stock": true } },
        { "exists": { "field": "basis_weight" } } ],
      "must_not": [ { "term": { "item_no": "元の品目の番号" } } ] } },
    "functions": [
      { "gauss": { "basis_weight": { "origin": 104.7, "offset": 2, "scale": 8, "decay": 0.5 } } } ],
    "boost_mode": "replace" } }
}

判・目・種類・在庫は filter に置きます。 点数に関わらない絞り込みなので、米坪の近さの順をくずしません。目を絞り込みに入れるのは、目の違う紙を「近い紙」として上に出さないためです。 目の違う紙も見たいという得意先には、目の条件を外した2回目の検索を別に示し、画面で分けて並べます。

boost_mode は replace にします。 公式のドキュメントでは、boost_mode の既定は multiply で、replace にすると問い合わせの点数を無視して関数の点数だけを使うとされています。絞り込みだけの問い合わせでは問い合わせの点数に意味が無いので、米坪の近さだけで並べます。

AIへ渡す前に整形する

1. 米坪を計算する … 品目の連量と判の面積から、米坪＝連量÷（面積×1,000枚）で計算し、小数1桁で持ちます
2. 判と目をそろえる … 「四六」「4/6」「46判」を shiroku、「T目」「タテ」「縦目」を T にします
3. 元の米坪を残す … 製紙会社が米坪を示している銘柄は、その値を basis_weight_maker に残し、計算の値と並べます
4. 板紙を分ける … 五條製紙のページでは、板紙の1連は100枚で、板紙連量＝米坪×面積×100枚とされています。板紙の品目は洋紙と別の式で計算します
5. 空の値を空のまま持つ … 目や寸法が品目に無いものは、値を入れずに残します

1番目の計算の例です。 四六判（面積0.860㎡）の110kgは、110÷（0.860×1,000）で約127.9g/㎡、菊判（面積0.597㎡）の76.5kgは、76.5÷（0.597×1,000）で約128.1g/㎡です。連量の数字は110と76.5で大きく違いますが、米坪にすれば0.2gの差で、同じ厚さの紙として引けます。 問い合わせの側も同じ式で米坪に直してから引きます。

3番目で計算の値と製紙会社の値を並べるのは、ずれを見るためです。 判の面積を小数3桁に丸めると、計算の米坪は製紙会社の示す値と少しずれます。ずれが大きい品目は、判の寸法の表か品目の記録の誤りを疑います。

4番目を忘れると、板紙の米坪が10分の1になります。 洋紙の式で板紙を計算すると、厚い板紙が薄い洋紙の代わりの候補に出ます。

AIに処理させる

AIの仕事は2つです。 問い合わせを探す条件に読み替えることと、候補を記録のまま並べて違いを書いた回答の下書きを作ることです。

「同等です」と言わせないのが、この構成でいちばん大事な線です。 米坪が同じでも、紙厚・白さ・表面の加工は銘柄で違います。印刷会社は「同等」と言われた紙で刷り、仕上がりが違えば代理店に戻ってきます。 違いを数字で示し、判断は印刷会社に委ねます。

判を連量から推し量らせないのも同じ理由です。 「110kg」と書かれていれば四六判のことが多いですが、菊判の110kgという紙もあります。 判が無ければ聞き返します。

指示内容を固定する

1回目（問い合わせの読み替え）の指示です。

あなたは紙の代理店で、印刷会社・製本会社からの問い合わせを整理する立場です。
【問い合わせ】から、在庫を探すための条件を取り出してください。

【取り出すもの】
- brand: 銘柄。書かれたまま（略称でもそのまま）
- paper_type: 紙の種類（コート・マット・上質など）。書かれたまま
- weight_raw: 連量・米坪の数字と単位。書かれたまま（「110kg」「128g」など）
- size_raw: 判・寸法。書かれたまま
- grain_raw: 目。書かれたまま（「T目」「タテ」など）
- quantity / due: 枚数・連数と納期。書かれたまま
- want_alternative: 代わりの紙を求めているか（yes / no / unknown）
- missing: 書かれていない項目の名前

【厳守事項】
- 書かれていない判・目を、連量の数字から推し量らないでください。
- 連量を米坪に計算しないでください。数字は書かれたまま写してください。
- 略称を正式名に直さないでください。
- 得意先の会社名・人の名前は写さないでください。

【問い合わせ】{inquiry_text}

2回目（回答の下書き）の指示です。

あなたは紙の代理店で、得意先への回答の下書きを作る立場です。
【候補】は商品の記録と、元の紙との違い（diff）と、照会した在庫の数です。

【書き方】
- 在庫のある品目は、銘柄・連量と判・目・寸法・出せる数を記録のまま書いてください。
- 代わりの紙は、元の紙との違い（米坪の差、目、判）を diff のまま書いてください。
- 代わりの紙には「印刷・加工への適否はご確認ください」と添えてください。
- 聞き返す項目があれば、最後にまとめて書いてください。

【厳守事項】
- 「同等です」「代わりに使えます」「問題ありません」と書かないでください。
- 紙の風合い・白さ・仕上がりについて書かないでください。
- 記録に無い数字を書かないでください。
- 価格・値引き・納期の約束を書かないでください。

【問い合わせの条件】{conditions}
【候補】{candidates}

「印刷・加工への適否はご確認ください」を添えさせないと、AIは候補を勧める文にします。 得意先は、代理店が勧めた紙は使えるものと読みます。勧めずに違いを並べることが、この下書きの役目です。

出力形式を固定する

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

{
  "inquiry_no": "",
  "requested": { "brand": "", "weight": "", "size": "", "grain": "", "quantity": "" },
  "in_stock": [ { "item_no": "", "listed": "", "available": "" } ],
  "alternatives": [
    { "item_no": "", "listed": "",
      "diff": { "basis_weight": "", "grain": "same | different | not_recorded",
                "size": "same | different" },
      "available": "" } ],
  "ask_back": [""],
  "draft": ""
}

AWS の公式ページでは、outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。すべての object に additionalProperties: false が要り、数値の minimum・maximum には対応していません。 diff と available は Lambda の計算と照会の結果を文字のまま渡して写させ、AIには計算させません。

1つ目の理由は、listed と available を記録と照合できることです。 品目の記録と照会の結果と同じかを Lambda で確かめ、違えば下書きを出さずに作り直します。 在庫の数を取り違えた下書きは、ここで止まります。

2つ目は、diff の grain で目の違いを先に見られることです。 目が different の代わりの紙は、営業の画面で色を変えて示します。製本の得意先には、目の違う紙を出す前に必ず確かめます。

システムへ連携する

略称の辞書のパッケージは、S3 のファイルを更新してから適用します。 AWS の公式ページでは、S3 に新しい版を置いただけではパッケージは更新されず、OpenSearch Service の側でパッケージを更新し、ドメインに適用する必要があるとされています。updateable: true を付けた検索の分析器だけで使っていれば、適用で索引は自動で更新されます。

人が確認する

1. 読み替えを見る … 銘柄・連量・判・目が、問い合わせのとおりに取り出されているかを確かめます
2. 米坪の計算を見る … 判が書かれていなかった問い合わせでは、どの判で計算したかを確かめます
3. 目の違う候補を確かめる … grain が different か not_recorded の代わりの紙は、得意先の用途を聞いてから出します
4. 代わりの紙は得意先と相談する … 違いを伝え、試し刷りの要否を含めて得意先に決めてもらいます
5. 下書きを直して回答し、引き当てる … 価格と納期は営業が書き足します

3番目を省かないでください。 目の違いは、刷った後の折りや製本で分かることがあります。数字の違いより、目の違いのほうが戻ってきたときの損が大きくなります。

2番目も、判の書かれていない問い合わせでは欠かせません。 下書きは判を聞き返す形になっているはずですが、営業が電話のメモに判を書き忘れただけのこともあります。得意先の過去の注文の判を見て、聞き返すか、営業の判断で判を入れて引き直すかを決めます。

例外に対処する

2行目の記録が、略称の辞書を育てる材料になります。 1行目は、判を推し量らずに聞き返すための行です。「110kg なら四六判だろう」と決めて計算すると、菊判の紙を探していた得意先に、厚さの違う紙を出すことになります。

記録を残す

• 問い合わせごとの、問い合わせの文（得意先の名前を伏せたもの）、1回目の JSON、営業が直した箇所
• 計算した米坪と使った判、検索の条件と候補、2回目の JSON と照合の結果
• 得意先が代わりの紙を採ったか、断ったか、その理由
• 回答した品目と、その後の返品や刷り直しの連絡の有無

3つ目は、代わりの紙の並べ方を見直す材料になります。 米坪が近くても断られ続ける組み合わせがあれば、紙の種類の分け方が粗すぎます。 種類を細かく分けるか、断られた組を記録して並べ方に戻します。