電子機器メーカーの購買部が部品の新規登録の依頼を受けたときに、抵抗値・容量・チップのサイズ・ねじの呼びの表記ゆれを正規化して既存の部品コードを探し、二重登録を防ぐ

処理の起点を決める

処理の起点は2つあります。 1つは、設計者が登録の依頼を送ったとき。依頼の書式が共有の受付に置かれると、行ごとに処理が動きます。もう1つは、毎晩の部品マスタの書き出しで、前日に登録・変更された部品を索引に入れ直すときです。

索引の入れ直しを毎晩にするのは、その日に登録した部品を翌日の依頼で見つけるためです。 同じ部品の依頼が別の設計者から続けて届くことがあり、索引が古いと、前の日に登録したばかりの部品と重複させます。その日のうちに登録した部品は、登録の画面から索引にも1件ずつ足します。

入力データを集める

質を決めるのは、下の2つの表です。 単位と接頭辞の表が欠けていると値を数値に直せず、サイズの対応表が無いとキーがそろいません。どちらも、部品の種類を増やすたびに購買の担当が足します。

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

部品マスタは毎晩、全件を書き出して、仕様のキーを作ってから索引に入れます。 既存品の仕様の欄も、依頼と同じ規則で項目に分けます。既存品の側で分けられなかったものは「キーなし」として入れ、品名の文字の近さでだけ探される扱いにします。

spec_key は、たとえば次のようになります。

抵抗   10kΩ ±1% 1/10W 1608     → RES|10000|F1|0.1W|1608
抵抗   10K 1% 0.1W 0603(inch)   → RES|10000|F1|0.1W|1608
コンデンサ 0.1uF 50V X7R 1005   → CAP|1.0E-7|50V|X7R|1005
コンデンサ 104 50V B 0402(inch) → CAP|1.0E-7|50V|B|1005
ねじ   M3×8 なべ 小ねじ SUS     → SCR|M3|8|PAN|SUS

2行目と4行目は、文字が違っても1行目・3行目とキーが一致します。 4行目の温度特性の「B」と「X7R」は規格が違うので、キーは別のままにし、同等かどうかは担当が判断します。

AIへ渡す前に整形する

1. 文字をそろえる … 全角を半角に、「μ」「u」を同じ記号に、「Ω」「ohm」を同じ記号にします
2. 値と単位を分ける … 「10kΩ」を値10、接頭辞k、単位Ωに分け、基本の単位の数値10000にします
3. 3桁の数字の表記を直す … 抵抗の「103」は 10×10の3乗＝10000Ω、コンデンサの「104」は 10×10の4乗 pF＝0.1μF として扱います。部品の種類が分からない行では直しません
4. 分数の定格を直す … 「1/10W」を0.1Wにします
5. サイズの系をそろえる … 依頼で選ばれた系に従ってメートルの表記に直します。系が選ばれていない4桁は、そのまま「系不明」にします
6. ねじの呼びを分ける … 「M3×8」「M3-8」「M3X8」「M3x8L」を、呼び径M3と長さ8に分けます
7. 規則で分けられない行を分ける … 規則に当たらなかった行だけを Claude API に渡します

3番目と5番目に「直さない」場合を書いているのが大事です。 「103」は抵抗なら10kΩですが、品番の一部や数量のこともあります。部品の種類が分からないまま直すと、関係のない数字が値になります。 サイズも、系が分からない4桁をどちらかに決め打ちすると、第1章の取り違えがそのまま起きます。

メーカー品番の正規化は、normalizer で索引の側に持たせます。 pattern_replace の文字フィルタで空白・ハイフン・スラッシュを落とし、cjk_width で全角を半角に、uppercase で大文字にそろえます。依頼の側の品番も、同じ normalizer を通して完全一致で比べます。

AIに処理させる

させるのは、規則で項目に分けられなかった仕様の文を、決まった項目に分けることだけです。 値を数値に直すこと、キーを作ること、同一かどうかを決めることはさせません。

数値への変換をAIにさせないのは、桁を誤ったときに見分けがつかないからです。 「4.7kΩ」を4700にするのは規則で確実にできます。AIに変換させて470と返ってきても、その数値は正しい形をしているので後段で止まりません。 AIには文字を項目に写させるだけにし、変換は規則の側で行います。

検索は3段で行い、上の段で見つかったら下の段は参考に回します。

③の fuzzy は、品名の打ち間違いを拾うためだけに使います。 公式のページでは、fuzzy は Damerau–Levenshtein の距離の範囲で似た語を探し、fuzziness の既定は AUTO、max_expansions の既定は50、prefix_length の既定は0です。値やサイズの項目には fuzzy を使いません。 「1608」と「1068」は距離1の近さで、fuzzy に任せると同じものとして拾います。

品名の言い換えは、同義語の辞書で吸収します。 公式のページでは、synonym_graph は複数語の同義語を扱え、検索の側の analyzer でだけ使うよう注意書きがあります。索引の側で使うと、複数語の同義語の後ろの語の位置がずれるためです。

指示内容を固定する

あなたは電子機器メーカーの購買部で、部品の登録の依頼に書かれた
仕様の文を、決まった項目に分ける立場です。
文に書かれていることだけを写してください。推測で埋めないでください。

【項目】
- category: resistor / capacitor / inductor / connector / screw / other
- value_text: 値（数字の部分）を書かれたとおりに
- prefix: 単位の接頭辞（p, n, u, m, k, M）。書かれていなければ null
- unit: 単位（ohm, F, H）。書かれていなければ null
- tolerance: 許容差を書かれたとおりに
- rated: 定格（電圧・電力）を書かれたとおりに
- size_digits: サイズの4桁の数字を書かれたとおりに
- size_system: inch / metric / unknown
- temp_char: 温度特性（X7R, B など）を書かれたとおりに
- thread: ねじの呼び径（M3 など）。ねじ以外は null
- length: ねじの長さ。ねじ以外は null

【厳守事項】
- 値を計算しないでください。「4.7k」を「4700」に直さないでください。
- 「103」「104」のような3桁の数字は、そのまま value_text に写し、
  prefix と unit は null にしてください。読み替えないでください。
- サイズの系は、文に「inch」「インチ」「metric」「メートル」と
  書かれているときだけ選んでください。それ以外は unknown です。
- 部品の種類が文から分からないときは other にしてください。
- メーカー品番の記号から仕様を読み取らないでください。
  品番の読み方はメーカーごとに違います。

【仕様の文】{spec_text}
【品名】{part_name}

「103を読み替えない」と書くのは、AIがこの読み替えを知っているからです。 知っているので、抵抗かコンデンサかが文から分からなくても読み替えます。読み替えは部品の種類が決まってから規則の側で行います。

「品番の記号から読み取らない」も同じ理由です。 メーカー品番には値やサイズを表す記号が入っていることが多いですが、記号の割り当てはメーカーごとに違い、AIがもっともらしく読むと誤りに気づけません。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONで受け取ります。 output_config.format に type: json_schema でスキーマを渡します。

{
  "category": "resistor",
  "value_text": "10",
  "prefix": "k",
  "unit": "ohm",
  "tolerance": "1%",
  "rated": "1/10W",
  "size_digits": "0603",
  "size_system": "unknown",
  "temp_char": null,
  "thread": null,
  "length": null
}

スキーマの制約は、公式のページの範囲に合わせます。 構造化出力は JSON Schema の一部に対応し、enum や required、additionalProperties: false は使えますが、数値の minimum／maximum、文字列の minLength／maxLength には対応せず、使うと400エラーになります。 category・prefix・size_system は enum で縛り、値の範囲は規則の側で確かめます。

1つ目の理由は、規則で分けた行と同じ形にそろえられることです。 規則で分けた行もこの形で持ち、その後の数値への変換とキーの作成は、どちらから来た行でも同じ規則を通ります。

2つ目は、size_system: unknown を機械的に止められることです。 unknown の行は ② の段の照合に入れず、設計者に系を聞く印を付けます。

画面に出す候補の一覧は、次の形です。

{
  "request_line": "R-2026-1015-07-03",
  "spec_key": "RES|10000|F1|0.1W|1608",
  "candidates": [
    {"part_code": "", "stage": 2, "class": "same | equivalent | different",
     "matched": ["category", "value", "tolerance", "rated", "size"],
     "unmatched": ["maker"], "status": "使用中"}
  ],
  "needs_input": ["size_system"]
}

matched と unmatched を並べるのは、担当がどこを見ればよいかを示すためです。 equivalent の候補では、unmatched にメーカーだけが入っていれば同等品の承認を見ればよく、許容差が入っていれば別の部品です。

システムへ連携する

部品マスタには書き込みません。 新しいコードの採番と登録は、購買の担当が生産管理のシステムで行います。この構成が誤ってコードを作る経路を持たないことが、重複を減らす仕組みが重複を作らないための条件です。

同義語の辞書は、カスタムパッケージで扱います。 公式のページでは、S3 に置いた辞書をパッケージとして取り込んでドメインに関連付け、synonyms_path に analyzers/<パッケージのID> を指定します。検索の側の analyzer で updateable: true にしておくと、パッケージを更新したときに自動で反映されます。 索引の側の analyzer で使うと、閉じて開くか索引を作り直す必要があります。S3 に新しい版を置くだけでは更新されず、パッケージの更新と適用が要ります。

人が確認する

購買の担当は、すべての依頼の行について候補の一覧を見て決めます。 自動で既存のコードを設計者に返すことはしません。

1. needs_input を先に見る … サイズの系が分からない行は、設計者に聞いてから照合をやり直します
2. same を確かめる … メーカー品番と仕様のキーが一致していても、status が廃止でないかを見ます
3. equivalent を判断する … メーカー違いの同等品は、品質保証の承認や顧客の指定を確かめます。キーが一致しても、同じコードに寄せてよいとは限りません
4. ③の段だけの候補は、項目を比べる … 文字が近いだけの候補は、unmatched を見て別の部品かを確かめます
5. 見つからなかった表記を記録する … 担当が手で見つけた既存品があれば、その書き方を辞書の追加の候補に残します

3番目を省かないでください。 同じ値・同じサイズでも、顧客が特定のメーカーを指定している機種では、同等品に置き換えられません。

目標は、1行あたり4分です。 same の行は確かめるだけで1分ほど、equivalent と③の段の行は数分かかります。

例外に対処する

5行目は、副産物として役に立ちます。 同じキーの既存品が複数あるのは、過去に重複して登録された証拠です。 これを集めると、まとめる候補の一覧になります。

記録を残す

• 依頼の行の原文と、規則か Claude API かの分け方の別、分けた項目、作った仕様のキー
• 3段のそれぞれで見つかった候補と、matched／unmatched
• 担当の決定（既存のコードを使う／新しく登録する）と、その理由の区分（同一、承認済みの同等品、別の部品）
• 担当が手で見つけた既存品と、そのときの書き方
• 同じ仕様のキーで複数の既存品が見つかった組
• 同義語の辞書の版と、適用した日付

4つ目が、辞書を育てる材料です。 毎月これを見て、「この書き方で見つからなかった」ものを同義語か前処理の規則に足します。 足した後に同じ書き方の依頼が見つかるようになったかを、翌月の記録で確かめます。