金型の補修履歴と成形不良の記録から、いま出ている不良に近い過去の補修事例と効いた対策を探し、補修の段取りの材料にする

処理の起点を決める

品質管理のシステムに不良が登録され、その区分が「金型起因の疑い」または「補修の検討が要る」のときに動かします。 材料のロットの不良や外観の軽微な不良まで動かすと、担当の画面が関係の薄い結果で埋まります。区分は品質管理と金型保全で決め、登録の画面の選択肢にします。

もう1つの起点は、補修の完了です。 担当が補修の記録を登録したときに、補修の事例を索引に足します。再発の有無は、補修から30日・90日の時点で品質管理の不良の記録を見て、プログラムが更新します。 同じ金型・同じ不良の種類・同じキャビティの不良が登録されていれば「再発あり」、無ければ「再発なし」とします。

再発の判定を後から足す形にするのは、補修の直後には結末が分からないからです。 補修の時点で事例を索引に入れ、結末が分かったら書き足します。

入力データを集める

質を決めるのは、補修の事例の「再発の有無」と、金型台帳の「系列」と「改造の元の金型」です。 再発が無ければ効いた直し方が分からず、系列が無ければ同じ金型にしか探しに行けません。系列の情報は、ベテランへの聞き取りで台帳に書き足すのが最初の仕事です。

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

検索パイプラインと検索の形は、次のようになります。

PUT /_search/pipeline/repair-hybrid
{
  "phase_results_processors": [
    { "normalization-processor": {
        "normalization": { "technique": "min_max" },
        "combination": { "technique": "arithmetic_mean",
                         "parameters": { "weights": [0.6, 0.4] } } } }
  ]
}

POST /mold-repairs/_search?search_pipeline=repair-hybrid
{
  "size": 10,
  "_source": ["case_id", "mold_id", "mold_family", "resin", "defect_type",
              "location", "cause", "repair_type", "repair_detail",
              "condition_change", "outsourced", "downtime_hours",
              "recurrence_90d", "repaired_on"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "symptom": "PL面 キャビティ2 ゲート反対側 バリ 0.2mm" } },
        { "knn": { "symptom_vector": { "vector": [0.0], "k": 30 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "mold_family": "DP-120" } },
            { "term": { "defect_type": "flash" } }
          ]
        }
      }
    }
  }
}

ハイブリッドクエリの filter は1つの検索の形で書き、複数の条件は bool にまとめます。 3段の絞り込みは、まず mold_id で検索し、上位の件数が3件に満たなければ mold_family に、さらに足りなければ resin と defect_type に広げて検索し直します。どの段の結果かを match_level として画面に渡します。

min_max の正規化は、返った結果の中の最小と最大でそろえます。 公式の説明では、結果が1件しかない検索ではその1件が1.0になるとされています。同じ金型の事例が1件しか無いときに、近さの点数が高く見えることがあるので、点数だけで近さを判断せず、match_level と一緒に表示します。

効いた対策の件数は、ハイブリッドクエリとは別の通常の検索で数えます。

POST /mold-repairs/_search
{
  "size": 0,
  "query": { "bool": { "filter": [
    { "term": { "mold_family": "DP-120" } },
    { "term": { "defect_type": "flash" } }
  ] } },
  "aggs": {
    "by_repair": {
      "terms": { "field": "repair_type", "size": 10 },
      "aggs": { "recurrence": { "terms": { "field": "recurrence_90d", "missing": "unknown" } } }
    }
  }
}

集計を別の検索にするのは、母数をはっきりさせるためです。 ハイブリッドクエリに集計を付けると、global を除いてハイブリッドクエリが返す文書の範囲で数えます。 「この系列のバリの補修のうち、研磨は12件で再発なし8件」と言うには、絞り込みに当たる全件を母数にしたいので、通常の検索で数えます。missing を指定すると、再発の判定がまだの事例を1つの区分にまとめて数えられます。

AIへ渡す前に整形する

1. 補修票の起こし直し … 過去の補修票のスキャンを担当が読み、補修の事例の項目に入れます。手書きの読み取りに頼らず、直近3年分から人が起こします
2. 言葉のそろえ … 「バリ」「PL面のはみ出し」を flash、「肉盛り」「TIG補修」を weld_buildup のように、不良の種類と補修の種類を決まった区分にします。そろえられないものは other にして原文を残します
3. 箇所の書き方 … キャビティの番号、PL面・ゲート・エジェクタピン・スライドなどの部位を区分で持ちます
4. 再発の判定 … 補修から30日・90日の時点で、同じ金型・不良の種類・キャビティの不良の記録を引き、recurrence_30d・recurrence_90d を入れます
5. 症状の文と埋め込み … 不良の種類・箇所・寸法・発生の状況をつないだ200字程度の文を作り、Titan Text Embeddings V2 で埋め込みます
6. 系列の付与 … 金型台帳の系列と改造の元の金型を、すべての事例に付けます

補修の事例の1件は、次のような形にします。集計に使う項目はすべて keyword にし、症状と原因の文だけを kuromoji で解析する text にします。

{
  "case_id": "MR-2025-0318",
  "mold_id": "DP-120-03",
  "mold_family": "DP-120",
  "base_mold": "DP-120-01",
  "resin": "PP-GF20",
  "machine": "M-35",
  "defect_type": "flash",
  "location": "parting_line",
  "cavity": "2",
  "symptom": "キャビティ2のゲート反対側のPL面に0.2mmのバリ。型温を上げた日に増える",
  "cause": "PL面の当たりの摩耗",
  "repair_type": "weld_buildup",
  "repair_detail": "PL面の肉盛り溶接と仕上げ研磨",
  "condition_change": "型締力を5%上げる（暫定）",
  "parts_used": [],
  "outsourced": true,
  "downtime_hours": 18,
  "shots_at_repair": 820000,
  "recurrence_30d": "none",
  "recurrence_90d": "none",
  "repaired_on": "2025-06-12",
  "customer_group": "auto_interior"
}

2番目が、集計の質を決めます。 区分にそろえないまま数えると、同じ補修が別々の区分に割れます。区分の一覧は金型保全と品質管理で決め、決まった言い方への当てはめはプログラムで行います。 当てはまらない言い方だけを、生成AIで区分の候補に当て、人が確かめます。

Titan Text Embeddings V2 は英語に最適化されたモデルで、日本語は多言語の対応（プレビュー）に入っています。 症状の文の書き方は現場ごとの癖が強いので、単語の一致の検索を並べ、自社の事例でどこまで当たるかを最初に確かめます。

AIに処理させる

させるのは2つです。不良の記録から検索に使う区分を取り出すことと、検索の結果から事例の要点と段取りの論点を並べることです。

4行目を外すのは、もっともらしい原因を作らせないためです。 生成AIは、症状から「ガス抜き不足と考えられます」と書くことができます。しかしそれは事例の記録ではなく推測です。 推測は担当が金型を見て行います。

指示内容を固定する

あなたは射出成形の工場の金型保全課で、成形不良が出た金型の補修を
検討する担当のために、過去の補修事例を整理する立場です。
補修の方法を決めないでください。決めるのは担当です。

【やること】
1. 検索で見つかった補修事例を読み、事例ごとに原因・補修の内容・
   成形の条件の変更・再発の有無を1〜2文でまとめてください。
2. 段取りの論点として、過去の事例で使った部品、外注の有無、
   停止の時間を、事例番号（case_id）付きで並べてください。
3. 集計の結果を読み、補修の種類ごとの再発なしの件数をそのまま書いてください。
4. 再発ありの事例の補修は「再発あり」として挙げてください。

【厳守事項】
- 件数を自分で数えないでください。集計の結果の数字だけを使ってください。
- 検索結果に無い事例番号を書かないでください。
- 事例に書かれていない原因を推測して書かないでください。
- 停止の時間は事例の値を並べるだけにし、「〇時間で済みます」と断定しないでください。
- match_level が family や resin の事例は、同じ金型の事例ではないことを必ず書いてください。
- 再発の判定がまだ（unknown）の事例は、効いたかどうか分からないと書いてください。

【いまの不良】{defect}
【検索結果（上位の補修事例と match_level）】{cases}
【集計（補修の種類ごとの再発の有無）】{aggregations}

「match_level が family や resin の事例は、同じ金型の事例ではないと書く」を入れないと、系列の別の金型の補修を、この金型の過去の補修のように書きます。 担当は「前にこの型で直した」と読み、同じ直し方が効くと思い込みます。

「件数を自分で数えない」は、上位の10件から割合を作らせないためです。 集計の母数は絞り込みに当たる全件で、上位の10件とは違います。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "defect": { "mold_id": "", "defect_type": "", "location": "", "cavity": "", "note": "" },
  "cases": [
    { "case_id": "MR-2025-0318", "match_level": "mold | family | resin",
      "summary": "", "recurrence_90d": "none | recurred | unknown" }
  ],
  "repair_counts_used": [
    { "repair_type": "", "total": 0, "no_recurrence": 0 }
  ],
  "setup_points": [
    { "topic": "parts | outsourcing | downtime", "finding": "", "evidence_cases": [] }
  ],
  "recurred_repairs": []
}

1つ目の理由は、evidence_cases と cases の事例番号を照らせることです。 検索結果に無い番号があれば、その論点は表示しません。

2つ目は、repair_counts_used を集計の結果と照らせることです。 AIが書いた件数が集計の数字と一致しなければ、その行は集計の結果をそのまま表示し直します。

3つ目は、match_level が画面の並びを決められることです。 同じ金型の事例を上に、系列・樹脂の事例をその下に分けて表示します。

応答が refusal や max_tokens で終わったときは、スキーマに合わないことがあるので、受け付けずにやり直します。

システムへ連携する

人が確認する

1. 事例の補修票と写真を開く … 上位の2〜3件は原本を読みます
2. 不良品と金型を見る … 事例と同じ箇所・同じ症状かを確かめます
3. 補修の方法と段取りを決める … 再発ありの対策を選ぶときは、理由を記録に残します
4. 補修の記録を登録する … 補修の種類・内容・部品・外注・停止の時間を、決まった区分で入れます

2番目を省かないでください。 記録の上で近くても、金型の摩耗の進み方や、前回の補修の跡で状況は違います。

目標は、120件をならして1件15分です。 同じ金型の事例が見つかるものは数分、系列まで広げたものは原本を読むのに時間がかかります。

例外に対処する

記録を残す

• 不良の記録と、取り出した区分
• 検索の条件（filter、match_level、重み）と、上位の事例番号と点数
• 集計の結果
• Claude API の出力と、指示の版
• 担当が決めた補修の方法と、再発ありの対策を選んだ理由
• 補修のあとの再発の判定（30日・90日）

最後の行が、この仕組みを育てます。 補修の記録と再発の判定がそろうと、次に同じ不良が出たとき、効いた直し方の件数が増えています。