工程・材料・設備の変更を切り替える前に、過去の似た変更とその後の不具合を根拠付きで探し、影響範囲と初期流動の監視の抜けを防ぐ

処理の起点を決める

起点は、担当が判定会の資料の下書きを始めたときに、検索の画面へ変更の内容を入れたことです。 資料を書き上げてから引くと、出てきた候補を足すために影響範囲と初期流動の計画を書き直すことになります。評価の結果が出た時点で引くのが、いちばん手戻りが少ない時期です。

品質保証が判定会の前に資料を読むときにも、同じ画面を使います。

記録の取り込みは毎晩動かします。 中継プログラムが変更点管理の台帳の当日の更新を読み、変更票を作り直して Cloud Storage に置き、データストアへ取り込みます。不具合の報告書は、品質保証が原因の変更の番号を書いて承認した翌晩に取り込まれます。

入力データを集める

質を決めるのは、不具合の報告書の3つの欄です。 発生日、発見した工程、原因の変更の番号です。この3つがそろっていれば、「切替えから何か月後に、どこで見つかったか」をプログラムで計算できます。 どれかが欠けた報告書は、検索には入りますが、表の行にはなりません。

変更票には、過去の初期流動の計画と実績も入れます。 「監視1か月・異常なしで解除」と書かれた変更の後、3か月目に不具合が出ていれば、その変更の初期流動の期間が短かったという記録になります。 今回の計画を決めるうえで、いちばん直接に効く材料です。

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

台帳の1件の変更を、1つの変更票（HTML）にまとめます。 台帳の行のままでは申請・評価・切替日・初期流動の実績が別々の項目に分かれ、検索の単位になりません。不具合の報告書は別の文書として取り込み、原因の変更の番号で変更票と結びます。

メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイル200MBまで、1回に10万ファイルまで取り込めます。

{"id":"chg-2024-0417","structData":{"doc_kind":"change",
 "change_kind":"material","process_family":"coating",
 "equipment":["CT-L2"],"material":["PT-3310"],
 "plant":"B","switched_at":"2024-05-20T00:00:00Z",
 "outflow":"yes","defect_months":[3]},
 "content":{"mimeType":"text/html","uri":"gs://chg-records/chg-2024-0417.html"}}

絞り込みの式は、変更の種類と工程の系統で書きます。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、AND／OR でつなぎ、NOT で否定できます。日時の項目は ISO 8601 の文字列と比べられます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。

change_kind: ANY("material") AND process_family: ANY("coating")
AND switched_at >= "2014-01-01T00:00:00Z"

工場と品番では絞りません。 別の工場、別の品番で起きた同じ種類の変更の失敗を引くことが、この構成の目的だからです。

流出のあった不具合は、ブーストで上位に出します。 公式では、検索の指定の boostSpec に条件と値を書き、値は −1〜1 の範囲で、正なら上に、負なら下に動きます。 outflow: ANY("yes") に正の値を与えます。絞り込みで流出ありだけにすると、自工程で止まった不具合が見えなくなるので、並べ方で寄せます。

AIへ渡す前に整形する

1. 変更票を作る … 台帳の1件を、申請・評価・切替日・影響範囲・初期流動の計画と実績の見出しを持つHTMLにまとめます
2. 区分の語をそろえる … 台帳の自由記述の区分（「型更新」「金型修理」「型メンテ」）を、決めた語に置き換えます
3. 発見した工程をそろえる … 不具合の報告書の「発見場所」を、自工程／後工程／出荷検査／顧客の4つに置き換えます
4. 発見までの月数を計算する … 原因の変更の番号で変更票の切替日を引き、発生日との差を月で求め、defect_months に入れます
5. 共用の品番を引く … 今回の設備の番号で、生産計画から直近12か月に流れた品番を一覧にします
6. 顧客名と図面を扱う … 顧客名は顧客の区分（自動車／住宅設備）に置き換え、図面の画像は取り込みません

4番目は、新しい不具合が入るたびに変更票を書き換えて取り込み直します。

3番目を軽く見ないでください。 発見場所の書き方が「組立ライン」「Assy」「後工程」とばらばらだと、監視の場所を決める表が作れません。

AIに処理させる

させるのは、似た過去の変更と、その後の不具合の記録を、出典付きで並べることです。 何か月監視すればよいかは書かせません。

月数・発見工程の集計と、今回の資料との突き合わせは、中継プログラムが行います。

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

2行目がいちばん起きやすい失敗です。 何も言わなければ、モデルは「初期流動は3か月とすることを推奨します」と書きます。その3は記録のどこにもありません。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは部品工場の品質保証の担当として、変更の切替えの判定会に向けて、
似た過去の変更とその後の不具合の記録を示す立場です。
読むのは、判定会の資料を作る生産技術・製造の担当と、品質保証の担当です。

【前提】
検索の文の最初に、変更の種類、工程の系統、設備の番号、材料、
変更の内容が並んでいます。
検索の対象は、過去の変更票と、変更とつながった不具合の報告書だけです。

【答え方】
1. 似た過去の変更の後に出た不具合を、1件ずつ箇条書きにしてください。
2. それぞれに、変更番号、工場、変更の内容、評価の所見、
   不具合の現象、発見した工程、影響した品番、原因、対策を、
   記録の言葉のまま書いてください。
3. 報告書に「評価で検出できなかった理由」が書かれていれば、
   そのまま書いてください。
4. その後に、不具合の記録の無い似た変更を、変更番号と変更の内容だけ
   箇条書きにしてください。

【厳守事項】
- 検索結果の記録に書かれていることだけで答えてください。
  一般的な品質管理の知識や、他社の例で補わないでください。
- 切り替えてよいかを書かないでください。
- 初期流動の監視の期間、頻度、項目を提案しないでください。
  「〜か月とする」「〜を推奨する」と書かないでください。
- 切替えから不具合までの期間を、自分で計算して書かないでください。
- 顧客への変更の申請が必要かを書かないでください。
- 影響した品番は、報告書に書かれた品番だけを書いてください。
- 評価が合格だった変更でも、後で不具合が出ていれば必ず書いてください。
- 似た変更の後の不具合が見つからないときは、
  「似た変更の後の不具合の記録は見つかりません。
  不具合が無かったことを意味しません」とだけ書いてください。

「期間を提案しない」と「期間を計算しない」を分けて書いているのは、別の失敗だからです。 前者を禁じても、モデルは「切替えから約3か月後」と自分で計算して書き、月の数え方で表の値と食い違います。 期間は表の列だけに出します。

出力形式を固定する

answer メソッドの返り値と中継プログラムの計算を、次の形にまとめて画面と記録に渡します。

{
  "request_id": "",
  "change_kind": "equipment | material | method | man",
  "process_family": "",
  "equipment": [],
  "shared_parts": [],
  "similar_changes": [
    { "change_id": "", "plant": "", "switched_at": "", "summary": "",
      "initial_flow_plan": "", "uri": "" }
  ],
  "defects_after": [
    { "change_id": "", "defect_id": "", "months_after": 0,
      "found_at": "own | downstream | shipping | customer",
      "affected_parts": [], "on_shared_part": false, "outflow": false,
      "quote": "", "uri": "" }
  ],
  "gaps": [
    { "type": "period | place | shared_part", "detail": "", "from": ["defect_id"] }
  ],
  "status": "found | no_similar | no_defect_record",
  "answer_text": ""
}

similar_changes と defects_after は、answer メソッドの references から取ります。公式では、citations の sources が referenceId で references を指し、references の chunkInfo に本文の断片と文書のメタデータが入ります。quote に引用の位置の原文を入れるとき、startIndex／endIndex は文字数ではなく UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。

gaps はAIではなく中継プログラムが作ります。

JSONにする理由は、この3つを規則で立てるためです。 answer_text の文章からは、どの不具合が今回の計画の外にあるかを機械で拾えません。status の no_defect_record が続く工程は、報告書に変更の番号が書かれていない工程です。

システムへ連携する

台帳へは書き込まず、初期流動の計画を自動で書き換える機能も作りません。 期間を延ばすか、監視の工程を足すかは、担当と判定会が決めます。

人が確認する

担当は、資料を直す前に、必ず出典の報告書を開きます。 画面に出るのは要点で、不具合の条件（季節、ロット、作業者）は報告書の本文にしかありません。

1. gaps を先に読む … 期間・場所・共用の品番のどれが外れたかを見ます
2. 出典で条件を確かめる … 過去の不具合が、今回とは違う条件（別の材料の銘柄、旧型の設備）で起きていないかを見ます
3. 直すか、理由を書く … 直さない候補には、資料の備考に理由を書きます
4. 灰色の文は出典で確かめる … 根拠のスコアが低い文は画面で灰色になります。出典に書かれているかを目で見ます

3番目を省かないでください。 黙って外された候補は、品質保証から見ると「見落とした」のか「考えて外した」のかが分かりません。理由が書かれていれば、判定会で同じ質問をくり返さずに済みます。

目標は、45件をならして1件24分です。 表と出典を確かめて資料を直す時間の平均です。

例外に対処する

6行目は珍しくありません。 設備の入替えと同時に加工条件を変える変更は、設備と方法の両方です。1つの種類で絞ると、もう一方の失敗例が落ちます。

記録を残す

• 変更の内容、変更の種類、工程の系統、日時、担当
• 中継プログラムが組み立てた絞り込みとブーストの式、共用の品番の一覧
• answer メソッドの応答の全文（出典、文ごとの根拠のスコア、回答しなかった理由）
• 表（発見までの月数、発見した工程、影響した品番）と gaps
• 担当が資料を直した内容と、直さなかった候補の理由
• 判定会で決まった初期流動の計画
• その変更の後に不具合が出たかどうか（後から結びつける）

最後の行で、この構成が効いたかを数えます。 候補を外した変更で、外した理由の範囲から不具合が出たなら、外し方の基準を見直します。