工場の設備保全の担当が、製造中止の部品の代替の候補を、過去の置き換えの記録とメーカーの資料から OpenSearch で探し、仕様の違いを並べる

処理の起点を決める

起点は3つあります。メーカーの資料の取り込み、保全の記録の取り込み、保全の担当の検索のボタンです。

資料の取り込みは、共有フォルダの「メーカー資料」に PDF が置かれたら S3 へ写し、それを起点に Lambda を動かします。商社からメールで届いた案内も、担当がこのフォルダへ置くことを決まりにします。

保全の記録は、毎晩、前の日までの部品の交換の記録を書き出し、記録の番号で上書きして取り込みます。

検索のボタンは、保全の担当が品番と設備を入れて押します。製造中止の案内に品番が何十行も並んでいるときは、案内の PDF を選ぶと、その中の品番を自社の予備品の台帳と照らし、自社で使っている品番だけを1件ずつ検索にかけます。

入力データを集める

質を決めるのは、いちばん下の仕様の名前の表です。 メーカーごとに、同じ意味の仕様を違う名前で書きます。名前がそろっていないと、同じ定格電圧どうしが比べられず、違う項目として出てきません。 表に無い名前は、名前を書かれたまま残し、比べずに並べます。

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

品番は normalizer を付けた keyword で持ちます。 OpenSearch の公式のドキュメントでは、normalizer は analyzer に似ていますが1つのトークンだけを出し、文字単位の操作をするフィルターだけを持てるとされています。全角を半角に、ハイフン・空白・スラッシュを消し、大文字にそろえます。 検索の側の品番も、Lambda で同じ規則でそろえてから渡します。

仕様は nested の項目で持ちます。 公式のドキュメントでは、nested の項目の中の内側の条件は同じ1つのオブジェクトに一致しなければならず、object として持つと値が配列に平らにされ、同じ条件が別々のオブジェクトの値に一致してしまうとされています。仕様の行を object で持つと、「定格電圧」の名前と、別の行の「24」という値が結び付きます。

GET /maker_docs/_search
{
  "size": 10,
  "_source": ["doc_no", "maker", "doc_type", "part_no", "file", "page"],
  "query": { "bool": {
    "filter": [
      { "term": { "category": "proximity_sensor" } },
      { "term": { "doc_type": "spec_sheet" } },
      { "nested": { "path": "specs", "query": { "bool": { "filter": [
        { "term": { "specs.name": "supply_voltage" } },
        { "term": { "specs.unit": "V_DC" } },
        { "range": { "specs.value_min": { "lte": 24 } } },
        { "range": { "specs.value_max": { "gte": 24 } } } ] } } } },
      { "nested": { "path": "specs", "query": { "bool": { "filter": [
        { "term": { "specs.name": "thread_size" } },
        { "term": { "specs.value_text": "M12" } } ] } } } } ],
    "should": [
      { "nested": { "path": "specs", "score_mode": "max",
        "inner_hits": { "name": "sensing_distance" },
        "query": { "bool": { "filter": [
          { "term": { "specs.name": "sensing_distance" } },
          { "range": { "specs.value_max": { "gte": 8 } } } ] } } } } ] } },
  "highlight": { "fields": { "body": { "fragment_size": 120, "number_of_fragments": 3 } } }
}

inner_hits で、どの仕様の行に当たったかを取ります。 公式のドキュメントでは、一致した内側のオブジェクトが返り、_nested にその位置が入るとされています。

根拠の箇所は highlight で抜き出します。 公式のドキュメントでは、既定の方式は unified で文を単位に BM25 で点数を付け、fragment_size の既定は100文字とされています。「後継品」の行や注意書きを、資料を開く前に読めるようにします。

AIへ渡す前に整形する

1. PDF から文字を取り出す … 文字が入っている PDF は Lambda で文字とページ番号を取り出します。文字の入っていない画像の PDF は「手入力が必要」として担当に回します
2. 品番の一覧と仕様の行を起こす … 生成AIに、取り出した文字から品番の一覧と、仕様の行（名前・値・単位・条件）を書かれたまま表にさせます
3. 仕様の名前と単位をそろえる … 仕様の名前の表で supply_voltage などの名前に、「DC24V」「24VDC」を value 24・unit V_DC に、「DC10〜30V」を value_min 10・value_max 30 にします
4. 品番をそろえる … normalizer と同じ規則の関数で part_norm を作ります
5. 置き換えの記録を起こす … 生成AIに、作業の報告の文から新しい品番と、取付けで変えたこと（ブラケット・配線・設定・ケーブル）を書かれたまま取り出させます
6. 置き換えた後の故障をつなぐ … 同じ設備で、置き換えから180日以内に同じ部品の故障があれば failed_after に記録の番号を入れます

3番目の範囲は、最小と最大に分けて持ちます。 1つの値しか書かれていない仕様は、最小と最大に同じ値を入れます。こうしておくと「24V が範囲に入っているか」を2つの range で引けます。

日本語の本文は kuromoji で分けます。 公式のドキュメントでは、IPAdic の辞書による形態素解析で、既定の search モードでは複合語を分けた語と複合語の形の両方を出し、user_dictionary_rules で辞書の行を直接書けるとされています。「近接センサ」「電磁弁」のような語を辞書の行に足します。

AIに処理させる

AIの仕事は3つです。 メーカーの資料から品番の一覧と仕様の行を起こすこと、作業の報告の文から新しい品番と取付けで変えたことを取り出すこと、候補と違う点を記録のまま並べた表を作ることです。

「互換あり」を書かせないのが、この構成でいちばん大事な線です。 定格電圧と取付けねじが同じでも、出力の形式やケーブルの向きが違えば使えません。急いでいる故障の場面ほど、その一言で手配が進みます。

安全に関わる部品は、さらに線を引きます。 非常停止や安全柵の扉のスイッチは、仕様が似ていても安全の機能の評価が変わります。取り込みのときに区分を付け、その候補には「安全の担当の確認が必要」を必ず出します。

指示内容を固定する

1回目（メーカーの資料を表に起こす）の指示です。

あなたは工場の設備保全の担当の補助として、メーカーの資料を整理する立場です。
【資料の文字】は、メーカーの PDF から取り出した文字とページ番号です。

【取り出すもの】
- doc_type: 資料の種類。eol_notice（製造中止の案内）／successor（後継品の案内）／
  spec_sheet（仕様表）／other から1つ
- parts: 資料に書かれた品番の一覧。品番ごとに、書かれたままの品番、ページ、
  製造中止の時期（書かれていれば）、メーカーが示した後継品の品番（書かれていれば）
- specs: 品番ごとの仕様の行。名前・値・単位・条件（「周囲温度23℃」など）を書かれたまま
- notes: 注意書き（「取付け寸法が異なります」など）を書かれたままと、そのページ

【厳守事項】
- 書かれていない仕様や後継品は空にしてください。似た品番から推し量らないでください。
- 品番の文字を直さないでください。ハイフン・空白・全角も書かれたまま写してください。
- 値と単位を書かれたまま写してください。単位の換算をしないでください。
- 「互換」「代替可能」の判断を書かないでください。資料に書かれている文はそのまま写します。

【資料の文字】{pdf_text}

3回目（候補の表）の指示です。

あなたは工場の設備保全の担当に、製造中止の部品の代わりの候補を示す立場です。
【候補】は OpenSearch が返した資料と置き換えの記録です。
【違う項目】はシステムが作ったものです。

【書き方】
- 候補を「メーカーが示した後継品」「過去に自社で置き換えた品」「仕様の近い品」に分けて
  並べてください。
- 候補ごとに、品番、根拠の資料（ファイル名・ページ）または記録の番号を書いてください。
- 【違う項目】は、文言を変えずにそのまま書いてください。
- 過去の置き換えで変えたこと（ブラケット・配線・設定など）は、記録の文のまま書いてください。
- 置き換えた後に故障の記録がある候補は、その記録の番号を書いてください。
- 安全に関わる部品の区分が付いた候補には「安全の担当の確認が必要」と書いてください。

【厳守事項】
- 「互換あり」「代替可能」「おすすめ」「問題ありません」と書かないでください。
- 候補の順位を付けないでください。並べる順はシステムの順のままにしてください。
- 記録や資料に無いことを書かないでください。

【探す部品】{target}
【候補】{hits}
【違う項目】{differences}

2回目（作業の報告の文の取り出し）は、1回目と同じ厳守事項で、新しい品番と変えたことだけを書かれたまま取り出させます。

「候補の順位を付けない」を書くのは、AIが自分で並べ直すためです。 何も言わないと、一番上に置いた候補を「最も近い」と書き添えます。 並べる順は検索の点数と区分で決めます。

出力形式を固定する

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

{
  "target": { "part_norm": "", "maker": "", "equipment": "" },
  "groups": [
    { "kind": "maker_successor | past_replacement | spec_near",
      "candidates": [
        { "part_norm": "", "source": { "doc_no": "", "file": "", "page": 0 },
          "record_no": "", "differences": [""], "changes_made": [""],
          "failed_after": "", "safety_related": false } ] } ],
  "to_confirm": [""]
}

AWS の公式ページでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えるとされています。すべての object に additionalProperties: false が要り、数値の minimum・maximum と文字列の長さの制約は使えず、任意の項目は全体で12個までです。 新しいスキーマの初回は文法の組み立てに最大約90秒かかるため、Lambda の待ち時間を120秒以上にします。

1つ目の理由は、AIが返した品番と資料の場所を索引と照合できることです。 part_norm・doc_no・page が検索の結果に無ければ、表を出さずに作り直します。

2つ目は、differences を Lambda が作った文と1字ずつ照合できることです。 違う項目は次の規則で作ります。

3行目と4行目が大事です。 比べられなかった仕様を黙って落とすと、画面の上では違いが無いように見えます。 比べなかったことを、違う項目と同じ欄に出します。

システムへ連携する

決めた代替は、「見た資料と記録」と一緒に S3 に残します。 手配の依頼と台帳の更新は、いつもの手順で行います。

人が確認する

1. 品番を見る … 入れた品番が、部品の銘板と同じかを確かめます
2. 根拠の資料を開く … 後継品の候補は、製造中止の案内の該当のページで確かめます
3. 違う項目を見る … 比べていない仕様と書かれていない仕様を、メーカーの資料で確かめます
4. 過去に変えたことを見る … ブラケット・配線・設定の変更が今回も要るかを考えます
5. 安全に関わる部品は安全の担当に回す … 保全の担当だけで決めません
6. 決めて残す … 決めた代替、見た資料と記録の番号、変える予定のことを残します

2番目を省かないでください。 案内の表は行がずれて読まれることがあり、後継品が隣の行のものでも画面では区別がつきません。

例外に対処する

5行目が、記憶頼みの知識を拾う行です。 「後継品に替えたら半年で壊れた」は、記録の上では離れた2件の交換の記録です。つないで出すと、ベテランに聞かなくても気づけます。

記録を残す

• 取り込んだ資料ごとの、元の PDF の場所、取り出した文字、起こした表、担当が直した箇所
• 置き換えの記録ごとの、報告の文と取り出した新しい品番と変えたこと
• 検索ごとの、探した品番、検索の条件、候補、違う項目と照合の結果
• AIの出力を作り直した記録と、その理由
• 決めた代替と、見た資料と記録の番号、取付けで変える予定のこと、決めた担当
• 仕様の名前の表と品番のそろえ方の規則を見直した日と担当

5つ目が、次に同じ部品を探す人のための記録です。 実際に交換した記録が来たら、つながった1件の置き換えの例になります。