品目マスタへの新規登録の申請が出たときに、名称・型番・仕様の近い既存品目を検索して、重複登録と別名登録の候補を出す

処理の起点を決める

申請のワークフローで申請が提出されたことを起点にします。 提出から数十秒で比較表がマスタ担当者の画面に出るようにします。毎日まとめて処理すると、同じ日に同じ品物の申請が2件出たとき、互いに見つけられません。

そのため、申請中の品目も索引に入れます。 承認されるまでは「申請中」の状態を付けておき、同じ品物の申請が重なったときに候補として出るようにします。

品目マスタの索引は、毎晩の書き出しで更新します。新規に登録された品目と、別名が足された品目を、翌朝には候補として出せる状態にします。

入力データを集める

質を決めるのは、いちばん下の比較の規則です。 ねじなら「種類・径・長さ・材質・表面処理・規格」、ホースなら「内径・外径・長さ・材質・耐圧」、手袋なら「材質・サイズ・枚数の単位」のように、分類ごとに「どの項目が一致すれば同じ品物か」を決めます。 最初は申請の多い分類から10個程度で始めます。

品目マスタの「別名」の列は、この構成で育てるものです。 申請の書き方を既存品目に結び付けた記録を、検索の対象に含めます。

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

品目マスタの索引は、次の項目を持たせて作ります。

日本語の解析には、ICU の正規化で全角・半角をそろえ、kuromoji か Sudachi で語に分けます。 「ﾎﾞﾙﾄ」と「ボルト」が同じ語として扱われるようになります。

埋め込みは、Amazon Titan Text Embeddings V2 で作ります。 入力は最大8,192トークン（50,000文字）、出力は既定で1,024次元のベクトルです。英語に最適化されていて、日本語を含む多言語に対応するとされています。品目の名称と仕様は短い文なので、入力の上限は問題になりません。

検索は、ハイブリッドクエリに3つの問い合わせを入れます。

点数をまとめる検索パイプラインは、次のように作ります。

PUT /_search/pipeline/item-dup-pipeline
{
  "description": "品目の重複候補の点数をそろえる",
  "phase_results_processors": [
    {
      "normalization-processor": {
        "normalization": { "technique": "min_max" },
        "combination": {
          "technique": "arithmetic_mean",
          "parameters": { "weights": [0.4, 0.3, 0.3] }
        }
      }
    }
  ]
}

weights の並びは、ハイブリッドクエリの queries に入れた問い合わせの順に対応します。問い合わせの順を入れ替えたら、重みの順も必ず入れ替えます。 入れ替え忘れると、型番の一致より意味の近さが重く扱われ、第1章の M6 と M8 のような候補が上に来ます。

重みは合計が1になるように決めます。 正規化プロセッサーで、点数を最小・最大でそろえる方式（min_max）と、重み付きの平均（arithmetic_mean）を使います。型番の一致の重みを高くするのは、型番が一致すれば、それだけで強い手がかりになるからです。 ハイブリッドクエリの filter で status を「有効」と「申請中」に絞ります。

AIへ渡す前に整形する

1. 型番の表記をそろえる … 全角を半角に、英字を大文字に、ハイフン・スペース・スラッシュを取り除いた形を model_no_norm にします。元の型番もそのまま残します
2. メーカー名の表記をそろえる … 「株式会社」「(株)」を外し、表記ゆれの表で正式名に寄せます
3. 単位をそろえる … 「1箱(100本入)」と「100本」のように、入数と単位を分けます
4. 仕様の文章を項目に分ける … 生成AIで、品目の分類ごとの項目に分けます（次の小見出し）
5. 品目マスタの側も同じ処理をする … 毎晩の書き出しのたびに、新しい品目と変わった品目だけ処理します
6. 廃止の品目を分ける … 廃止の品目は検索の対象から外しますが、後継品の情報があれば、その品目の候補として出します

1番目で、元の型番を消さないでください。 表記をそろえた型番は検索のためのもので、マスタ担当者が比較表で見るのは、申請と既存品目の元の書き方です。 そろえた形だけを見せると、本当に同じ型番なのか、そろえたせいで同じに見えているのかが分かりません。

AIに処理させる

生成AIにさせるのは、仕様の文章を項目に分けることだけです。 探すのは検索基盤、比べるのは規則です。

規則での分け方は次のとおりです。

1行目がいちばん大事です。 生成AIに「この2つは同じ品物か」と聞くと、名称と用途が近ければ「同じ」と答えがちです。径が6と8で違うことは書かれているのに、それを小さな違いとして扱います。 比べるのは規則で、生成AIは項目に分けるところまでにします。

指示内容を固定する

あなたは製造業の購買部で、品目マスタの仕様を整理する係です。
次の【仕様の文章】から、【品目の分類】ごとに決められた項目の値を取り出してください。

【品目の分類】{category}
【取り出す項目】{attribute_list}
  （例：ねじ … 種類、呼び径、長さ、材質、表面処理、規格）
【名称】{name}
【型番】{model_no}
【仕様の文章】{spec_text}

【守ること】
- 書かれている値だけを取り出してください。書かれていない項目は value を空にし、
  status を missing にしてください。
- 推測で埋めないでください。「M6」とだけあり長さが無ければ、長さは missing です。
- 数字と単位は、書かれているとおりに取り出してください。
  単位を換算しないでください。「1/4インチ」を「6.35mm」にしないでください。
- 材質や表面処理の書き方をそろえないでください。「ステンレス」は「ステンレス」のまま
  value に入れてください。そろえる作業は別の処理で行います。
- 1つの項目に値が2つ以上書かれている場合は、status を ambiguous にしてください。
- この品物が既存のどの品目と同じかは書かないでください。
- evidence には、その値を取り出した元の文字列をそのまま写してください。

「単位を換算しない」「書き方をそろえない」を明記しないと、親切にそろえます。 そろえた値が正しくても、元の書き方が消えると、マスタ担当者が申請と見比べるときに探せなくなります。 そろえるのは表記ゆれの表を持つ規則の側で、そろえた値と元の値を並べて持ちます。

「長さは missing」の例を具体的に書くのは、ねじやボルトで最も多い失敗だからです。 よく使われる長さを入れて埋めると、variant になるはずの候補が alias になります。

出力形式を固定する

項目分けは、Claude API の構造化出力で次の形にします。

{
  "category": "ねじ",
  "attributes": [
    { "name": "種類", "value": "六角ボルト", "status": "ok", "evidence": "六角ボルト" },
    { "name": "呼び径", "value": "M6", "status": "ok", "evidence": "M6" },
    { "name": "長さ", "value": "20", "status": "ok", "evidence": "×20" },
    { "name": "材質", "value": "SUS304", "status": "ok", "evidence": "SUS304" },
    { "name": "表面処理", "value": "", "status": "missing", "evidence": "" },
    { "name": "規格", "value": "", "status": "missing", "evidence": "" }
  ]
}

構造化出力は output_config.format に type: "json_schema" を指定して使います。オブジェクトには additionalProperties: false を付けます。status は ok ／ missing ／ ambiguous の列挙にします。

規則の照合の結果は、マスタ担当者の比較表として次の形で渡します。

{
  "request_id": "",
  "candidates": [
    {
      "item_code": "",
      "name": "",
      "model_no": "",
      "status": "有効",
      "search_score": 0.0,
      "match": "same | alias | variant | different",
      "diff_attributes": [ { "name": "呼び径", "request": "M6", "existing": "M8" } ],
      "missing_in_request": ["表面処理"]
    }
  ]
}

1つ目の理由は、diff_attributes で違う項目だけを見せられることです。 マスタ担当者は、候補ごとに仕様の全文を開かなくても、どこが違うのかを一目で読めます。

2つ目は、missing_in_request で申請の側の書き漏れを示せることです。 申請に表面処理が書かれていなければ、既存品目のどれと同じかは決められません。その場合は申請者に確かめるのが正しい対応で、構成の側で決めません。

3つ目は、search_score と match を分けていることです。 点数が高くても variant のことがあり、点数が低くても alias のことがあります。並び順は点数、判断の材料は規則の結果、と役割を分けます。

システムへ連携する

品目マスタへは、この構成から書き込みません。 登録と別名の記録は、マスタ担当者の判断を受けて、既存の登録の手順で行います。

人が確認する

人が見るのは、すべての申請です。ただし、見る場所は比較表に絞ります。

1. same の候補があれば、元の型番とメーカーを見比べる … そろえた形で一致しただけでないかを確かめます
2. alias の候補は、比較の規則の項目を見る … すべて一致していれば、既存のコードを使うよう申請者に返します
3. variant の候補は、違う項目が本当に違う品物を意味するかを見る … 寸法の違いは別品目、色の違いは社内の取り決め次第、などの判断です
4. missing_in_request があれば、申請者に確かめる
5. 既存のコードを使うと決めたら、申請の名称を別名として記録する

1番目を省かないでください。 型番の表記をそろえると、まれに別のメーカーの同じ文字列の型番が一致します。メーカーまで一致しているかを必ず見ます。

判断に迷った申請は、その場で決めずに保留の印を付けます。 保留が週に数件たまったら、購買と設計の担当がまとめて見て、比較の規則に足すかを決めます。1件ずつその場で決めると、担当者ごとに判断が分かれ、規則に戻ってきません。

目標は、比較表を開いてから判断までを数分にすることです。 それより長くかかる申請が多い分類は、比較の規則の項目が足りないか、申請の仕様の書き方がそろっていません。

例外に対処する

最後の行で、「見つからない」を「無い」と言い切らせないでください。 表記ゆれの表や別名が育つまでは、見つからないだけの重複が残ります。

記録を残す

• 申請の内容と、表記をそろえた型番・メーカー名
• 項目分けの結果（値、status、evidence）
• 検索の候補と点数、規則の照合の結果、そのとき使った比較の規則と表記ゆれの表の版
• マスタ担当者の判断（既存のコードを使う／新規に登録／申請者に確かめる）と、判断した人・日時
• 別名として記録した書き方

4つ目の判断の記録を、規則の見直しに使います。 variant と出たのに担当者が「同じ品物」と判断した組み合わせが多い項目は、比較の規則が厳しすぎるか、表記ゆれの表が足りません。