ねじ・ファスナーの商社の営業が、客先からの呼び径・長さ・材質のあいまいな問い合わせを OpenSearch で引き、合う品番の候補と外れた条件を並べる

処理の起点を決める

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

取り込みは、販売の管理の仕組みから品番の追加と在庫の変化を書き出して、索引を更新します。索引の在庫は「あるか無いか」の目安にだけ使い、返事に書く数は必ず照会で取り直します。 日中の出荷で在庫は変わるからです。

検索のボタンは、営業が問い合わせを貼るか電話のメモを打ち込んだ後に押します。FAX は営業が読んで打ち込みます。 呼び方の辞書は、新しい呼び方が見つかるたびに表に足し、月に1回まとめて索引に適用します。

入力データを集める

質を決めるのは、品番の記録のピッチと材質の項目です。 ピッチが空の品番は、並目か細目かを候補の時点で示せません。取り込みのときに空の数を数え、空の品番は画面に「ピッチの記録なし」と出します。

客先の会社名と担当者名は、生成AIに渡しません。 問い合わせの本文に書かれていれば伏せ、仕様の言葉と数量だけを渡します。

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

呼び方の辞書は synonym_graph で、検索の分析器にだけ使います。 OpenSearch の公式のドキュメントでは、synonym_graph は検索の分析器でだけ使うべきで、索引の分析器で使うと複数の語の同義語が後ろの語の位置をずらす、とされています。辞書は S3 に置き、OpenSearch Service のカスタムパッケージとして取り込んで、synonyms_path に analyzers/<パッケージの ID> を指定します。

辞書を更新するときは、S3 に置くだけでは足りません。 AWS の公式ページでは、S3 に新しい版を置いても OpenSearch Service のパッケージは自動では更新されず、パッケージを更新してドメインに適用する必要があるとされています。updateable: true は検索の分析器にだけ使え、後から検索の分析器を自動で更新したいときに要るとされています。

合った条件は、名前付きの検索で拾います。 公式のドキュメントでは、どの検索の句にも _name を付けられ、文書が一致すると、一致にかかわった句の名前が matched_queries の配列で返るとされています。材質・表面処理・ねじ部の形・ピッチの句に名前を付け、返ってこなかった名前を「外れた条件」とします。

GET /fasteners/_search
{
  "size": 15,
  "_source": ["item_no", "name", "size", "pitch", "length_mm", "material",
              "surface", "thread", "in_stock"],
  "query": { "bool": {
    "must": [
      { "match": { "name": "キャップ" } } ],
    "filter": [
      { "term":  { "size": "M6" } },
      { "range": { "length_mm": { "gte": 18, "lte": 22 } } } ],
    "should": [
      { "term": { "material": { "value": "sus304",  "_name": "material" } } },
      { "term": { "thread":   { "value": "full",    "_name": "thread" } } },
      { "term": { "length_mm": { "value": 20,      "_name": "length_exact" } } },
      { "term": { "in_stock": { "value": true,     "_name": "in_stock" } } } ] } }
}

should の句は、一致しなくても候補から外れません。 公式のドキュメントでは、bool に must か filter があると minimum_should_match の既定は0で、should の句に一致しなくても文書は返るとされています。一致した should の句は点数を上げるので、条件の多く合う品番が上に来ます。

ピッチは、問い合わせに書かれているときだけ should に入れます。 書かれていなければ句を作らず、確かめる点に回します（第7章「前処理」）。

辞書に入れない語の一覧を、辞書を作るときに必ず見ます。 「並目」と「細目」を同じ語にすると、細目の問い合わせで並目の品番が同じ点数で出ます。呼び方が近くても品の違う語は、辞書の外に置きます。

AIへ渡す前に整形する

1. 呼び径をそろえる … 「M6」「m6」「6mm」「Ｍ６」を M6 にします。インチの呼び（「3/8」「1/4」など）は inch_3/8 のように別の区分にし、ミリねじと混ぜません
2. ピッチを区分にする … 「並目」「細目」「P1.0」を区分にします。書かれていなければ unknown にし、並目と見なしません
3. 長さを数にする … 「長さ20」「L=20」「20mm」を 20 にし、「くらい」「前後」が付いていれば幅を付けます（既定は前後2mm）
4. 材質と表面処理を区分にする … 「ステン」「SUS」はステンレスの区分にし、「SUS304」と書かれていればその区分まで細かくします
5. ねじ部の形を区分にする … 「全ねじ」「全ネジ」を full、「半ねじ」を half にします。書かれていなければ unknown にします

2番目で並目と見なさないのが、第3章の（b）を防ぎます。 呼び径だけの問い合わせは多く、慣れた営業ほど並目と思い込みます。unknown の問い合わせには、確かめる点に「ピッチ（並目か細目か）」を必ず入れます。

4番目で「ステン」をステンレスの区分にとどめるのは、ステンレスの中の区分を推し量らないためです。 問い合わせが「ステン」だけなら、SUS304 も SUS316 も「材質は合う」と出し、確かめる点に「ステンレスの種類」を入れます。 品番の記録の材質の項目は、細かい区分のまま持ちます。

3番目の幅は、営業が画面で変えられるようにします。 長さの決まった品の注文で幅を広げすぎると、合わない長さの品番が上に来ます。

AIに処理させる

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

「代わりになります」と言わせないのが、この構成でいちばん大事な線です。 材質が SUS316 から SUS304 に変わると、使う場所によっては錆びます。代わりで済むかを決めるのは、使う場所と条件を知っている客先です。 出すのは「材質が違います」という事実だけです。

インチをミリに直させないのも同じ理由です。 「3/8」を近いミリの呼び径に直すと、ねじ山の合わない品番が候補に出ます。

指示内容を固定する

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

あなたはねじ・ファスナーの商社の営業で、客先からの問い合わせを整理する立場です。
【問い合わせ】から、品番を探すための条件を取り出してください。

【取り出すもの】
- name_raw: 品名。書かれたまま（「キャップ」など）
- size_raw: 呼び径。書かれたまま（「M6」「3/8」など）
- pitch_raw: ピッチ。書かれたまま。無ければ空
- length_raw: 長さ。書かれたまま（「20くらい」など）
- material_raw: 材質。書かれたまま（「ステン」など）
- surface_raw: 表面処理。書かれたまま。無ければ空
- thread_raw: ねじ部の形。書かれたまま。無ければ空
- qty_raw: 数量。書かれたまま
- missing: 書かれていない項目の名前

【厳守事項】
- ピッチ・材質の種類・ねじ部の形が書かれていなければ空にしてください。
  品名や用途から推し量らないでください。
- インチの呼びをミリに直さないでください。書かれたまま写してください。
- 長さや数量を計算しないでください。
- 客先の会社名・担当者名は写さないでください。

【問い合わせ】{inquiry_text}

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

あなたはねじ・ファスナーの商社で、客先への返事の下書きを作る立場です。
【候補】は品番の記録と、照会した在庫の数です。
【外れた条件】と【確かめる点】は、システムが作ったものです。

【書き方】
- 候補ごとに、品番・品名・呼び径・ピッチ・長さ・材質・表面処理・
  ねじ部の形・在庫の数を、記録の値のまま書いてください。
- 【外れた条件】は候補ごとに、文言を変えずにそのまま書いてください。
- 【確かめる点】は最後にまとめて、文言を変えずに書いてください。

【厳守事項】
- 「代わりになります」「問題ありません」「同等品です」と書かないでください。
- 強度・耐食・締め付けについて書かないでください。
- 記録に無い数字を書かないでください。

【問い合わせの条件】{conditions}
【候補】{candidates}
【外れた条件】{unmatched}
【確かめる点】{check_points}

「外れた条件を文言を変えずに書く」が、2回目の指示の中心です。 AIは「材質が違います（記録：SUS304）」を「材質はステンレスです」のように丸めて書くことがあります。丸めると、外れた条件が合った条件に見えます。 写させて、後で照合します。

出力形式を固定する

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

{
  "inquiry_no": "",
  "conditions": { "name": "", "size": "", "pitch": "coarse | fine | unknown",
                  "length_mm": 0, "material": "", "thread": "full | half | unknown" },
  "candidates": [
    { "item_no": "", "name": "", "size": "", "length_mm": 0, "material": "",
      "stock": "", "matched": [""], "unmatched": [""] } ],
  "check_points": [""],
  "draft": ""
}

AWS の公式ページでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えるとされています。すべての object に additionalProperties: false が要り、数値の minimum・maximum は使えません。 ピッチとねじ部の形は enum で縛り、unknown を必ず選べるようにします。

1つ目の理由は、matched と unmatched を検索の結果と照合できることです。 unmatched は、検索で作った名前のうち matched_queries に無かったものです。下書きの unmatched が Lambda の作ったものと1つでも違えば、下書きを出さずに作り直します。

外れた条件の文は、次の規則で作ります。

確かめる点は、unknown の区分から次のように作ります。

システムへ連携する

返事の送信は、営業がいつものメールか電話で行います。 この構成から客先へ直接送る経路は作りません。

人が確認する

1. 読み替えを見る … 呼び径・ピッチ・長さ・材質が、問い合わせのとおりに取り出されているかを確かめます
2. 確かめる点を見る … ピッチや材質の種類が分からない問い合わせは、聞き返してから品番を決めます
3. 外れた条件を見る … 外れた条件のある候補を返すときは、外れたことが下書きに残っているかを確かめます
4. 在庫と納期を確かめる … 照会の数と入荷の予定を確かめて返します

3番目を省かないでください。 第3章の（c）はここで防ぎます。外れた条件を書かずに返すと、客先は全部の条件が合っていると思って注文します。

例外に対処する

4行目が、この構成でいちばん多い例外です。 外れた条件の少ない順に並べても、どの条件が外れてよいかは客先によって違います。 外れた条件を添えて候補を返し、選ぶのは客先に任せます。

記録を残す

• 問い合わせごとの、問い合わせの文（客先の名前を伏せたもの）、1回目の JSON、営業が直した箇所
• 検索の条件、候補、matched_queries、外れた条件と確かめる点、2回目の JSON と照合の結果
• 返事で出した品番と、客先が注文した品番
• 呼び方の辞書と辞書に入れない語の一覧を更新した日と担当

3つ目は、辞書を育てる材料になります。 候補に出なかった品番を客先が注文していれば、どの呼び方で引けなかったかが分かります。