不具合の連絡を受けたときの初動調査を、該当ロットと過去の類似事例からまとめる

処理の起点を決める

受付フォームにレコードが1件作られたことを起点にします。 不具合の連絡は時間を選ばずに入るため、定時実行にはしません。 1日1回にした瞬間、「報告を早く出す」という目的が失われます。

入力項目は製造番号、症状の文章、連絡を受けた日時の3つだけにします。品番や顧客名は製造番号から引けます。番号が聞き取れない連絡では起動せず、受付票だけを担当者に回します。

入力データを集める

この構成の質を決めるのは「製造番号とロットの対応」です。 ここが無ければ残りを整えても始まりません。逆にここさえあれば、他はロット番号で串刺しにできます。

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

6つのツールを定義し、エージェントに順に呼ばせます。 中身はすべて、自社プログラムからの読み取り専用の照会です。

ツール定義は、次のように書きます。

{
  "name": "lookup_lot_by_serial",
  "description": "製造番号から、その製品が属する製造ロットを1件返す。生産管理システムの製造実績テーブルを照会し、ロット番号・品番・製造日・製造ライン・作業班・製造数量・材料ロット番号を返す。実績に存在しない場合は found を false にする。不具合の調査では最初にこのツールを呼ぶこと。ロット番号が分からない状態で他のツールを呼んではいけない。",
  "strict": true,
  "input_schema": {
    "type": "object",
    "properties": {
      "serial_no": {
        "type": "string",
        "description": "銘板に刻印された製造番号。英字2文字・数字4桁・数字6桁をハイフンでつなぐ。例: PX-2409-018432"
      }
    },
    "required": ["serial_no"],
    "additionalProperties": false
  }
}

description の書き方が、この構成でいちばん効きます。 説明文には、（1）何を返すか （2）どのシステムの何を照会するか （3）いつ呼ぶか （4）見つからないときどうなるか の4つを書きます。「ロットを調べる」だけでは呼ぶ順番が安定しません。入力の書式を例つきで書くのも、後述する「足りない引数を勝手に補う」への対策です。

expand_lot_range は lot_no と scope を required にし、scope を ["adjacent", "same_day_line", "same_material"] の enum で持たせます。説明文に「3つの scope をすべて呼び、重複を除いた一覧を作ること」「範囲を自分の判断で狭めてはいけない」と書きます。 広げ方の定義をツール側に置くのがねらいです。

③から⑥は、②が終わったあとなら同時に呼べます。 ツールを1つずつしか呼ばせたくない場合は tool_choice に {"type": "auto", "disable_parallel_tool_use": true} を指定しますが、ここでは指定しません。早く出すことが目的です。

AIへ渡す前に整形する

1. 製造番号の書式検証 … 正規表現で確かめ、合わなければ起動しません
2. 症状の文章の整形 … 挨拶や経緯を落とし、症状の記述だけを残します
3. 検索語の組み立て … 「動かない」に対する「起動不良」「通電しない」を対応表から引きます
4. 顧客名の伏せ字化 … 顧客名と担当者名を CUST_A のような符号に置き換えます
5. 照会件数の上限設定 … 上限を設け、達した場合はその旨を結果に含めます
6. 同一連絡の検知 … 同じ製造番号で直近に調査済みなら、その調査番号を渡します

AIに処理させる

させるのは、「調べる手順」をたどることと、集まった事実を並べることの2つだけです。 6つのツールを順に呼び、台帳の検索が空振りしたら言い換えを試し、過去の事例から症状と品番が近いものを選び、集めた値を出どころ付きで並べ、照会できなかった項目を欠けとして書き出し、次に確かめることを候補として出します。

1行目がいちばん大事です。確実なのは、出力のスキーマに原因を書く場所を作らないことです。 structured outputs は additionalProperties: false に対応し、制約付きデコードでスキーマどおりの応答が保証されます。スキーマに無い項目は出力できません。 ただし自由文に推定が混じることはあるので、そこはプロンプトで縛ります。

指示内容を固定する

あなたは製造業の品質管理部門で、不具合の初動調査を支援する立場です。
与えられたツールを使って事実を集めてください。推測で答えないでください。

【調べる手順】
1. lookup_lot_by_serial に製造番号を渡し、ロットを特定してください。
   found が false のときは、そこで止めて data_gaps に理由を書いてください。
   他のツールを呼ばないでください。
2. expand_lot_range を scope を変えて3回呼び、
   関係する可能性のあるロットをすべて集めてください。
   範囲を自分の判断で狭めないでください。
   「関係なさそうだ」と思っても、一覧から外さないでください。
3. 1と2で得たロット番号について、list_lot_shipments（どこに何個出ているか）、
   get_inspection_records（検査記録）、get_process_records（工程の記録）、
   search_past_incidents（過去に似た不具合）の4つを調べてください。
4. search_past_incidents が0件のときは、渡された言い換えの検索語を
   順に試してください。すべて試して0件なら、0件だったと書いてください。

【厳守事項】
- 不具合の原因を書かないでください。推定も、可能性の示唆もしないでください。
  「〜が原因と考えられる」「〜の可能性がある」と書いてはいけません。
  similarity_reason には、症状と品番のどこが一致したかだけを書いてください。
- ツールが返した値以外の数値・日付・ロット番号・出荷先を書かないでください。
  四捨五入も、単位の変換も、概算への言い換えもしないでください。
- すべての事実に source を付けてください。
  「どのシステムの、どのレコードか」が分かる形にしてください。
  例: 生産管理システム/製造実績/LOT-2409-0182
- ツールが値を返さなかった項目は、空のままにしてください。
  data_gaps に「どのツールが、なぜ返さなかったか」を書いてください。
  空欄を埋めるために、他の項目から補わないでください。
- 出荷を止めるべきかどうか、対応の要否や緊急度を書かないでください。
- next_checks には「何を」「なぜ」「誰が」「どこで」の4つをそろえ、
  そこに原因の推定を書かないでください。

【受付内容】{intake}
【台帳検索用の言い換え】{search_terms}
【過去に同じ製造番号で調査した記録】{past_investigation}

「原因を書かない」を3回に分けて書いているのは、書き方を変えて出てくるためです。 「原因」を禁じると「要因」と書き、それも禁じると「傾向として」と書き始めます。禁止する対象は言葉ではなく、文の形で示します。

「範囲を狭めない」と「0件だったと書く」も必要です。 何も言わないと、関係が薄そうなロットを気を利かせて落とし、似た事例が無いときは一般的な事例を持ち出します。落とされたことは出力から分かりません。

出力形式を固定する

output_config.format に、次のJSONスキーマを渡します。

{
  "intake_id": "", "serial_no": "", "reported_symptom": "",
  "identified_lot": { "found": true, "lot_no": "", "part_no": "", "production_date": "",
    "line": "", "shift": "", "material_lot_no": "", "source": "" },
  "lot_range": [
    { "lot_no": "", "scope": "target | adjacent | same_day_line | same_material", "source": "" }
  ],
  "shipments": [
    { "lot_no": "", "customer_code": "", "ship_date": "", "quantity": 0, "slip_no": "", "source": "" }
  ],
  "inspection_records": [
    { "lot_no": "", "item": "", "spec": "", "measured": "", "judgment": "", "source": "" }
  ],
  "process_records": [
    { "lot_no": "", "equipment": "", "condition": "", "value": "", "alarm": "", "source": "" }
  ],
  "similar_past_cases": [
    { "incident_no": "", "occurred_on": "", "symptom": "", "cause_category": "",
      "action_taken": "", "similarity_reason": "", "source": "" } ],
  "next_checks": [ { "what": "", "why": "", "who": "", "where": "" } ],
  "data_gaps": [ { "tool": "", "reason": "" } ]
}

1つ目の理由は、原因を書く場所を作らないためです。 このスキーマには cause も root_cause もありません。similar_past_cases の cause_category は過去の事例に記録されている原因区分であって、今回の原因ではありません。

2つ目は、出どころの確認を速くするためです。 すべての事実に source が付くので、担当者は「この測定値はどのレコードか」を1行で確かめられます。本文だけでは値ごとに元のシステムを開くことになり、確認が元の30分に戻ります。3つ目は、lot_range と shipments から「止める候補の出荷伝票の一覧」を機械で作れることです。

使えるJSON Schemaの機能には範囲があります。enum、const、required、additionalProperties: false、$ref や $def は使えますが、minimum／maximum、minLength／maxLength は使えず、書くと400エラーになります。 数値の範囲の検証は後段のプログラムで行ってください。

システムへ連携する

すべての照会を読み取り専用にしてください。 検査記録と工程の記録は日次のCSVでもかまいませんが、製造実績と出荷実績は、その日のデータが見えないと意味がありません。

人が確認する

全件、人が確認します。確認せずに報告を出す設計にしません。

1. 事実の出どころを確かめる … source のレコードを開き、出荷数量・測定値・製造日の3つは必ず見ます
2. ロット範囲を絞る … 症状と関係しないロットを外し、外した理由を記録に残します
3. 次に確かめることを決める … next_checks は候補です。順番と担当を決めるのは人です

2番目が、この構成の中心の作業です。 機械は広げるだけ広げ、人が絞ります。絞る判断には、「同じ材料ロットでも、この工程を通っていれば影響しない」といった現場の知識が要ります。 その知識を持つ人の時間をここに使えるようにするのがねらいです。

確認の目標は1件39分です。 それ以上かかるなら source の粒度が粗いか、lot_range が広すぎます。広すぎる場合は expand_lot_range の範囲の定義を見直します。プロンプトで狭めさせるのではありません。

例外に対処する

最後の行を軽く見ないでください。 プロンプトの制約は必ずすり抜けるので、出力の側でも文末表現を機械で検知し、 印を付けて担当者が先に読む形にします。

記録を残す

• 受付内容（製造番号、症状の文章、連絡を受けた日時と経路）
• エージェントが呼んだツールの順番と引数、各ツールが返した結果とJSONの全文
• 担当者が lot_range から外したロットと、外した理由
• 一次報告の確定版と、配布した先と日時
• 後日判明した実際の原因と、そのときの対処

3つ目と5つ目を突き合わせると、絞る判断の基準を見直すべきかが分かります。