自動車整備工場で、客が訴える異音・警告灯・振動の症状から過去の整備記録と修理事例を探し、原因の候補と点検の順番を根拠付きで返す

処理の起点を決める

整備士が作業指示の画面で「症状の検索」のボタンを押したときに動かします。 受付の時点で自動で動かさないのは、故障コードが診断機をつないでから分かるからです。

ボタンは何度でも押せるようにします。 点検の途中で「左前から音がする」と分かったら、追記してもう一度押します。

もう1つの起点は、作業の完了です。 整備士が原因の区分を選んで作業の記録を確定したら、その記録を事例として索引に足します。足すのは原因の区分が選ばれた記録だけです。

入力データを集める

質を決めるのは、いちばん下の2つです。 系統の表が無ければ、同じ型式の事例が少ないときに探しに行く先がありません。

同じ車の過去の整備記録も別に引きます。 「前回、ベルトの交換をすすめたが見送り」と書かれていれば、点検の順番の最初に置く材料になります。

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

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

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

POST /repair-cases/_search?search_pipeline=symptom-hybrid
{
  "size": 10,
  "_source": ["case_id", "model_code", "platform", "engine_code", "mileage_km",
              "symptom", "dtc", "cause_category", "fix", "inspect_minutes",
              "repaired_on"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "symptom": "冷間始動 走り出し 前方 キュルキュル 数秒で止む" } },
        { "knn": { "symptom_vector": { "vector": [0.0], "k": 30 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "platform": "P-07" } },
            { "term": { "symptom_category": "noise_squeal" } },
            { "range": { "mileage_km": { "gte": 30000, "lte": 90000 } } }
          ]
        }
      }
    }
  }
}

filter は1つの検索の形で書き、複数の条件は bool にまとめます。 ハイブリッドクエリは検索の最上位に置くもので、function_score などの中に入れるとエラーか正規化が飛ばされることがあるとされています。新しい事例を上にしたくても、点数の関数で包まず、表示の段で並べ替えます。

3段の絞り込みは、まず model_code（上の例は2段目の platform）で検索し、上位が3件に満たなければ広げて検索し直します。 どの段の結果かを match_level として画面に渡します。min_max では、結果が1件しか無い検索ではその1件が1.0になるので、match_level と件数を一緒に表示します。

原因の区分ごとの件数は、ハイブリッドクエリとは別の通常の検索で数えます。

POST /repair-cases/_search
{
  "size": 0,
  "query": { "bool": { "filter": [
    { "term": { "platform": "P-07" } },
    { "term": { "symptom_category": "noise_squeal" } },
    { "term": { "condition": "cold_start" } }
  ] } },
  "aggs": {
    "by_cause": {
      "terms": { "field": "cause_category", "size": 10, "missing": "unrecorded" },
      "aggs": { "avg_minutes": { "avg": { "field": "inspect_minutes" } } }
    }
  }
}

集計を別の検索にするのは、母数を「絞り込みに当たる全件」にするためです。 terms 集計の対象は keyword などの項目で、size の既定は10です。missing を指定すると、原因の区分が入っていない記録を1つの区分にまとめて数えられます。

AIへ渡す前に整形する

1. 修理事例のノートの取り込み … 約1,800件の行を事例の項目にそろえます。原因が欠けた行は unrecorded にします
2. 整備記録からの事例の起こし … 直近3年の症状の入庫のうち、原因が書かれたものだけを整備士が区分を付けて起こします
3. 言葉のそろえ … 「ベルト鳴き」「Vベルト異音」を belt_squeal のように原因の区分に、「キュルキュル」「キーキー」を noise_squeal のように症状の区分にします。そろえられないものは other にして原文を残します
4. 車種の系統の付与 … 車種の系統の表から、すべての事例に platform を付けます
5. 故障コードの正規化 … 大文字にそろえ、現在のコードか過去のコードかを分けて持ちます
6. 症状の文と埋め込み … 症状の区分・出る条件・場所・客の言葉をつないだ150字程度の文を作り、Titan Text Embeddings V2 で埋め込みます

事例の1件は、次のような形にします。集計と絞り込みに使う項目は keyword にし、症状と直し方の文だけを kuromoji で解析する text にします。

{
  "case_id": "RC-2025-0612",
  "model_code": "XYZ-A10",
  "platform": "P-07",
  "engine_code": "E-1.5A",
  "mileage_km": 62000,
  "symptom_category": "noise_squeal",
  "condition": "cold_start",
  "location_hint": "engine_front",
  "symptom": "朝いちばんの始動から走り出しまでキュルキュル鳴り、数秒で止む。雨の日に強い",
  "dtc": [],
  "cause_category": "belt_tensioner",
  "fix": "オートテンショナー交換、ベルト同時交換",
  "inspect_minutes": 20,
  "repaired_on": "2025-11-08",
  "source": "notebook"
}

3番目が、件数の質を決めます。 そろえないまま数えると、同じ原因が「ベルト鳴き」「Vベルト」「補機ベルト」に割れ、どれも件数が少なく見えます。 当てはまらない言い方だけを生成AIで区分の候補に当て、整備士が確かめます。

AIに処理させる

させるのは2つです。受付のメモから検索に使う症状の区分を取り出すことと、検索の結果から事例の要点と点検の順番の案を並べることです。

3行目がいちばん起きやすい失敗です。 生成AIは「ウォーターポンプの可能性もあります」と書けますが、それは自社の記録ではなく一般論です。

点検の順番の案は、件数だけで並べません。 件数が多くても点検に1時間かかる原因より、5分で確かめられる原因を先に見るほうが早く着くことがあります。件数と平均の点検時間を両方渡し、並べる決まりをプロンプトに書きます。

指示内容を固定する

あなたは自動車整備工場の整備課で、症状の訴えで入庫した車について、
自社の過去の修理事例を整理し、点検の順番の案を作る立場です。
原因を決めないでください。決めるのは車を見た整備士です。

【やること】
1. 検索で見つかった事例を読み、事例ごとに症状・原因・直し方を1〜2文でまとめてください。
2. 集計の結果（原因の区分ごとの件数と平均の点検時間）を使い、
   点検の順番の案を作ってください。並べ方の決まり：
   - 件数が多く、平均の点検時間が短いものを先にする
   - 件数が同じくらいなら、点検時間が短いものを先にする
   - 同じ車の過去の記録で「見送り」になった項目があれば、最初に置く
   各項目に、並べた理由を1行と、根拠の事例番号（case_id）を付けてください。
3. 受付のメモで欠けている条件を、客に確かめる質問として最大3つ挙げてください。

【厳守事項】
- 件数を自分で数えないでください。集計の結果の数字だけを使ってください。
- 検索結果に無い事例番号を書かないでください。
- 事例に無い原因を、一般的な知識から足さないでください。
- match_level が platform や engine の事例は、同じ型式の事例ではないことを必ず書いてください。
- cause_category が unrecorded の件数は、原因の記録が無い件数として書いてください。
- 「安全です」「走行に問題ありません」など、車の状態を判断する表現を書かないでください。
- 故障コードがある場合、コードが一致する事例とそうでない事例を分けて書いてください。

【受付のメモと故障コード】{intake}
【車両】{vehicle}
【同じ車の過去の記録】{history}
【検索結果（上位の事例と match_level）】{cases}
【集計（原因の区分ごとの件数と平均の点検時間）】{aggregations}

「事例に無い原因を足さない」を明記しないと、一般論が混ざります。 整備士は画面の候補を自社で見つかったものと読むので、記録の上ではいちばん少ない原因から点検を始めることになります。 match_level の一文も同じで、同じエンジンでもベルトの取り回しが違う車があります。

出力形式を固定する

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

{
  "symptom": {
    "category": "noise_squeal | noise_knock | noise_grind | warning_light | vibration | other",
    "condition": [],
    "location_hint": "",
    "since": "",
    "frequency": ""
  },
  "cases": [
    { "case_id": "RC-2025-0612", "match_level": "model | platform | engine",
      "dtc_match": true, "summary": "" }
  ],
  "inspection_order": [
    { "step": 1, "cause_category": "", "count": 0, "avg_minutes": 0,
      "reason": "", "evidence_cases": [] }
  ],
  "questions_for_customer": [],
  "unrecorded_count": 0
}

1つ目の理由は、evidence_cases と cases の事例番号を照らせることです。 検索結果に無い番号が evidence_cases に入っていたら、その行は表示しません。

2つ目は、count と avg_minutes を集計の結果と照らせることです。 AIが書いた件数が集計の数字と違えば、その行は集計の数字で表示し直します。 構造化出力は数値の最小・最大の制約に対応していないため、件数の範囲の確かめはプログラムの側で行います。 応答が refusal や max_tokens で終わったときは、スキーマに合わないことがあるので受け付けずにやり直します。

システムへ連携する

外部の呼び出しに対応していない整備管理のシステムでは、別の検索画面から始めます。

人が確認する

1. match_level と dtc_match を見る … 同じ型式・同じ故障コードの事例が上にあるかを確かめます
2. 根拠の事例を1〜2件開く … 症状の書き方が目の前の車と同じかを読みます
3. 車を見て順番を決める … にじみ、前回の修理の跡、後付けの部品など、記録に無いものを見ます
4. 原因を記録する … 原因の区分を選び、説明を1行書きます。案と違う原因だったときこそ必ず記録します

4番目を省かないでください。 案と違う原因の記録が、次の同じ症状の件数を変えます。案どおりの原因ばかりが記録されると、件数は今の傾向を強めるだけになります。

目標は、240件をならして1件10分です。

例外に対処する

1行目と3行目が、始めて数か月はいちばん多く出ます。 AIの問題ではなく、事例と表が足りないことの表れです。

記録を残す

• 受付のメモ、故障コード、型式と走行距離、取り出した症状の区分
• 検索の条件（filter、match_level、重み）と、上位の事例番号と点数
• 集計の結果と、unrecorded の件数
• Claude API の出力と、指示の版
• 整備士が決めた点検の順番と、実際に見つかった原因の区分

最後の行が、この仕組みを育てます。 案の1番目で原因が見つかった割合を毎月数えると、系統の表か言葉の対応表を見直すべき型式が分かります。