自動車ディーラーの整備士が、入庫した車の症状と故障コードから、メーカーの技術情報とサービスキャンペーンの資料を引き、当てはまる対策と手順を探す

処理の起点を決める

起点は、整備士が整備の管理システムで故障コードを入れて検索のボタンを押したことです。 受付の時点では故障コードがまだ無いので、問診だけで先に動かすことはしません。 故障コードが出ない症状（音、におい、振動）は、故障コードの欄を「なし」にして押します。

もう一つのトリガーは、メーカーのポータルに新しい技術情報や資料が出たことです。 サービスの技術担当が毎日ポータルを見て、新しい文書をダウンロードし、メタデータを書いて置きます。取り消しや差し替えの通知が出た文書は、消さずに status を superseded にします。 取り込みは毎晩です。

入力データを集める

質を決めるのは、技術情報の適用の範囲をメタデータに正しく写すことです。 技術情報の適用範囲は、型式ごとに車台番号の始まりと終わりで書かれていることが多く、1つの文書に型式が3つあれば、範囲も3つあります。 そこで、技術情報を「型式と範囲の組」ごとに1行のメタデータにし、同じ文書を複数の行から指します。

過去の修理記録は、技術情報より下に置きます。 記録は「この店で、この車で、こうしたら直った」という1件の事実で、原因の切り分けの参考にはなりますが、対策の根拠にはなりません。

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

技術情報と資料は1件ずつPDFで Cloud Storage に置き、メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。車台番号の範囲は数の項目にします。

{"id":"tsb-2025-0318-a","structData":{"doc_kind":"tech_bulletin",
 "model_code":"ABC1","serial_from":100001,"serial_to":158400,
 "system":["steering","suspension"],"dtc":[],"status":"active",
 "issued_date":"2025-11-20T00:00:00Z"},
 "content":{"mimeType":"application/pdf","uri":"gs://svc-docs/tsb-2025-0318.pdf"}}

入庫のたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() で列挙した値との完全一致、数の項目は <=・>= などで数との比較、IN() で範囲の指定ができ、AND・OR・NOT と括弧で組み合わせられます。項目は索引可能にしておく必要があります。

model_code: ANY("ABC1")
AND serial_from <= 123456 AND serial_to >= 123456
AND NOT status: ANY("superseded")

故障コードがある場合は、絞り込みではなく検索の文に入れます。 技術情報には故障コードを書いていないものもあり、故障コードで絞ると、コードの書かれていない対策が落ちます。 故障コードの一致は、並べるときに中継プログラムが印を付けるだけにします。

過去の修理記録は、型式で絞り、連番の範囲は見ません。 同じ型式の近い連番の記録も、切り分けの参考になるからです。記録は別の呼び出しにし、技術情報と混ぜません。

データストアは、技術情報・資料用と過去の修理記録用で分けます。 修理記録は毎晩増え、技術情報より件数が多くなります。同じデータストアに入れると、件数の多い記録が検索の上位を占め、技術情報が押し出されます。

技術情報の図には、レイアウト パーサーの Image annotation を使います。 部品の位置の図や配線の図に説明が付き、「助手席側の足元のコネクタ」のような問診の言葉からも図の載った節が引かれやすくなります。図の説明はメーカーの原文ではなくパーサーが付けた文なので、根拠として写すのは図そのものと本文の節の番号にします。

AIへ渡す前に整形する

1. 車台番号を分ける … 車検証の車台番号を、型式の部分と連番に分けます。輸入車でシリアル番号の書式が違う車は、連番に分けられないので範囲の絞り込みを外し、型式だけで絞ります
2. 問診の言葉を言い換える … 症状の言い換えの一覧を当て、問診の言葉に技術情報の言葉を添えます。もとの言葉は消しません
3. 検索の文を作る … 系統（エンジン、変速機、ステアリング、空調、電装など）、症状、故障コード、走行距離を1つの文にします
4. 技術情報の適用範囲を写す … 新しい技術情報を置くとき、技術担当が範囲の表から型式と始まりと終わりの連番を書きます。写し間違いを防ぐため、2人で読み合わせます
5. 過去の修理記録を整える … お客様の名前・住所・電話・ナンバーを外し、型式・連番・症状・原因・部品・結果だけの文書にします

4番目の読み合わせを省かないでください。 範囲の連番を1桁写し間違えると、当たるはずの車に技術情報が出ず、当たらない車に出ます。 検索の精度より、この写しの正しさが効きます。

2番目の言い換えの一覧は、技術担当が月に一度、候補が出なかった問診の言葉を集めて足します。 「キュルキュル」「ガタガタ」のような音の言葉は受付担当ごとに書き方が違い、最初の版では足りません。

AIに処理させる

させるのは、絞り込まれた技術情報・資料の中から、症状と故障コードに当てはまりうる文書を探し、症状・原因・対策・手順の節を本文のまま引用して並べることです。

3つ目は、引用の照合で守ります。 中継プログラムが答えの中の部品番号と数値（N·m、mm、V などの付いた数）を拾い、引用したチャンクの本文にそのまま含まれるかを確かめます。 含まれなければ、その数を伏せて原文を開くよう表示します。

answer メソッドの設定は次のようにします。

根拠の弱い答えは生成されず、answerSkippedReasons に LOW_GROUNDED_CONTENT が返ります。 そのときは「範囲に入る技術情報で当てはまるものを確認できませんでした」と出し、過去の修理記録だけを並べて技術担当への相談を勧めます。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の指示を入れます。中継プログラムは、型式、走行距離、系統、故障コード、問診の言葉と言い換えを検索の文の先頭に付けます。

あなたは自動車ディーラーのサービス工場で、整備士の調べものを
手伝う立場です。読むのは整備士で、作業の前に必ず原文と
修理書を確かめます。

【前提】
検索の対象は、この車の型式と車台番号の範囲に当たる、メーカーの
技術情報とサービスキャンペーン等の資料だけです。

【答え方】
1. 症状と故障コードに当てはまりうる技術情報を、文書の番号・題名・
   発行日を付けて、当てはまりそうな順に3件まで示す
2. 各文書の症状と原因を、本文のまま引用する
3. 対策の部品と部品番号、作業の手順の節の番号を、本文のまま書く
4. 文書の症状と見比べるために整備士が確かめることを、3つまで挙げる
5. 系統が重なるリコール・改善対策・サービスキャンペーンの資料が
   あれば、届出番号や資料の番号を書き、「メーカーの照会で確認」と
   書き添える

【厳守事項】
- 「原因は〜です」と断定しないでください。
  「この文書の症状と一致する可能性があります」と書いてください。
- 部品番号、締め付けトルク、規定の値は、本文の文字のまま書き、
  丸めたり単位を換えたりしないでください。
- リコール等の対象である、実施済みである、とは書かないでください。
- 検索結果に無い作業の手順や、一般的な整備の知識で補わないでください。
- お客様の名前や車の登録番号を書かないでください。
- 当てはまるものが無いときは、
  「範囲に入る技術情報で当てはまるものを確認できませんでした」
  とだけ書いてください。

「当てはまりそうな順に3件まで」と数を決めるのは、候補を10件並べると整備士が全部を読まなくなるからです。 4件目以降は、画面で開けば見られるようにします。

出力形式を固定する

answer メソッドの返り値と入庫の項目を、中継プログラムが次の形にまとめます。

{
  "work_order_id": "",
  "model_code": "",
  "serial_no": 0,
  "serial_filter_applied": true,
  "dtc": [],
  "bulletins": [
    { "doc_id": "", "title": "", "issued_date": "", "dtc_match": false,
      "symptom_quote": "", "cause_quote": "", "parts": [],
      "procedure_section": "", "numbers_verified": true, "uri": "" }
  ],
  "campaign_candidates": [ { "doc_id": "", "kind": "recall | improvement | service_campaign",
                             "title": "", "maker_check": "required" } ],
  "past_repairs": [ { "record_id": "", "symptom": "", "cause": "", "parts": [] } ],
  "facts_to_check": [],
  "flags": []
}

campaign_candidates の maker_check は、いつも required です。 画面では、この欄だけ色を変え、「メーカーの照会で対象と実施の状況を確かめてください」と出します。国土交通省のリコール制度のページによれば、リコール・改善対策の実施済みの識別は、令和8年4月1日以降、各メーカーのホームページの車台番号による検索で確かめられるようになり、届出時の識別の方法と違う場合があります。車体のペイントの印で実施済みと見なさないよう、画面にも書いておきます。

システムへ連携する

作業の結果は、整備士が整備の管理システムに記録し、翌晩に過去の修理記録として取り込みます。 「技術情報のとおりの対策で直った」「直らず別の原因だった」が残り、次の検索の材料になります。

人が確認する

原因を決めるのはいつも整備士の点検と診断で、作業の手順はいつも修理書に従います。

1. 車が範囲に入っているかを確かめる … no_serial_filter が立っていたら、候補の文書の適用範囲を原文で読みます
2. 候補を原文で読む … 引用の前後の、発生の条件と適用の除外を確かめます
3. キャンペーン等はメーカーで照会する … 対象と実施の状況を、車台番号で照会します
4. 修理書で作業する … 締め付けの値や規定の値は、修理書の値で作業します

2番目の「適用の除外」を読み落とさないでください。 技術情報には、範囲に入っていても「寒冷地仕様を除く」のような但し書きがあります。

例外に対処する

記録を残す

• 入庫の番号、型式、連番、走行距離、問診の言葉と言い換え、故障コード
• 絞り込みの条件と、そのとき登録されていた技術情報の件数
• answer メソッドの返り値の全文（answerText、citations、references、answerSkippedReasons）
• 画面に出した候補と flags、整備士が開いた文書
• 作業の結果（候補の対策で直ったか）

最後の行が、この構成を育てる記録です。 候補の1件目で直った割合を月ごとに見ます。下がってきたら、適用範囲の写しの誤りか、言い換えの一覧の不足を疑います。