工程の4M変更（人・設備・材料・方法）を申請するときに、過去の変更申請・評価結果・変更後の不具合の記録から似た変更を根拠付きで探し、確認すべき評価項目を先に出す

処理の起点を決める

起点は、担当が検索の画面で変更の内容を入れたことです。 申請書を書き始める前、変更の内容が決まった段階で使います。評価計画を書き終えてから引くと、出てきた項目を足すために計画を書き直すことになります。

品質保証が評価計画を確かめるときにも、同じ画面を使えるようにします。 担当が添付した候補一覧と、品質保証が自分で引いた結果を比べれば、担当が候補から外した項目に理由があるかを確かめられます。

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

入力データを集める

質を決めるのは、不具合の報告書の「原因と考えられる変更の番号」の欄です。 この欄が無いと、変更と不具合は検索の文の近さだけでつながり、関係の無い不具合が「似た変更の後の不具合」として出てきます。

評価の結果は「合格」だけで残さず、所見まで取り込みます。 「合格。ただし吸水後の寸法は規格の上限に近い」という所見は、次の似た変更で何を確かめるべきかを、いちばん直接に教えてくれる記録です。

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

台帳の1件の変更を、1つの案件票（HTML）にまとめて取り込みます。 台帳の行のままでは申請の本文と評価計画が別々の項目に分かれ、検索の単位になりません。中継プログラムが案件ごとに申請・評価計画・結果・所見を1枚にまとめ、評価報告書と不具合の報告書は別の文書として案件番号で結びます。

メタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書きます。defect_after は、不具合の報告書が取り込まれたときに、中継プログラムが原因の変更の番号を読んで案件票の側を yes に書き換えます。

絞り込みの式は、4M区分と工程の種類で書きます。 項目を索引可能にしておけば、change_type: ANY("material") AND process: ANY("molding") AND doc_kind: ANY("case", "evaluation") のように書けます。ラインや品番では絞りません。 他のラインの同じ種類の変更を引くことが、この構成の目的だからです。

不具合のあった変更は、ブーストで上位に出します。 answer メソッドの検索の指定に boostSpec を書き、defect_after: ANY("yes") という条件に正の値を与えます。値は −1 から 1 の範囲で、正の値で上に、負の値で下に動きます。 絞り込みで不具合のあった変更だけにすると、不具合の無かった似た変更が見えなくなるため、絞り込みではなく並べ方で寄せます。

データストアは、レイアウト パーサーとチャンク分割を有効にして作ります。 チャンクの大きさは100〜500トークンで、includeAncestorHeadings で見出しをチャンクに付けられます。評価報告書の測定値の表が単独で引かれても、どの変更のどの評価の表かが分かるようにします。

AIへ渡す前に整形する

1. 案件票を作る … 台帳の1件を、申請・評価計画・結果・所見の見出しを持つHTMLにまとめます
2. 4M区分と工程の種類をそろえる … 台帳の自由記述の区分を、決めた語に置き換えます。「型修理」は設備、「仕入先変更」は材料
3. 評価報告書に案件番号を付ける … ファイル名か表紙から案件番号を読み、メタデータに入れます。読めないものは品質保証に回します
4. 不具合の報告書をつなぐ … 原因の変更の番号が書かれたものだけを、変更とつないで取り込みます
5. 顧客名と図面番号を扱う … 顧客名は顧客の区分（自動車／産業機械）に置き換え、図面の画像は取り込みません
6. 古い記録に印を付ける … 承認から10年を超える記録は approved_at で見分け、画面で年代を示します

2番目を軽く見ないでください。 台帳の区分が「設備」「機械」「金型」とばらばらだと、絞り込みで同じ種類の変更の半分が落ちます。最初の取り込みの前に、区分の置き換えの表を品質保証と作ります。

4番目で、原因の番号が書かれていない不具合は取り込みません。 本文に「金型修理の後から」とだけある古い報告書は、品質保証が番号を確かめてから足します。

AIに処理させる

させるのは、似た過去の変更と、そのときの評価項目、変更の後に出た不具合を、出典付きで並べることです。 今回の評価計画で足りるかは書かせません。

4行目の確認項目の候補は、AIが新しく考えた項目ではありません。 過去の評価で測った項目と、不具合の報告書の対策に書かれた「今後確認する項目」を集め、重なりをまとめたものです。出典の無い項目は候補に入れません。

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

根拠の強さは、表示を変えるだけに使います。 スコアの低い文を消すと、ほかに記録の無い経験が落ちることがあります。灰色にして「出典を必ず確かめる」と添えます。

4行目がいちばん起きやすい失敗です。 材料の切り替えと聞くと、モデルは一般的な評価項目（引張強さ、色差、難燃性）を並べたくなります。それらは間違いではありませんが、この工場の記録ではありません。 一般論で埋まった候補一覧は、過去の失敗から引いた項目を埋もれさせます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます（2回目の不具合の呼び出し用）。

あなたは部品メーカーで、4M変更を申請する担当に、
似た過去の変更の後に出た不具合の記録を示す担当です。
読むのは、これから評価計画を書く生産技術・製造の担当です。

【前提】
検索の文の最初に、4M区分、工程の種類、ライン、変更の内容が並んでいます。
検索の対象は、過去の変更の案件票と、変更とつながった不具合の報告書だけです。

【答え方】
1. 似た変更の後に出た不具合を、1件ずつ箇条書きにしてください。
2. それぞれに、案件番号、変更の内容、評価の結果、
   不具合の現象、変更から発生までの期間、報告書に書かれた原因と対策を、
   記録の言葉のまま書いてください。
3. 報告書に「今後確認する項目」が書かれていれば、そのまま書いてください。

【厳守事項】
- 検索結果の記録に書かれていることだけで答えてください。
  一般的な品質管理の知識や、他社の例で補わないでください。
- 今回の変更をしてよいか、評価計画で足りるかを書かないでください。
- 顧客に届け出る必要があるかを書かないでください。
- 不具合の原因を、報告書に書かれたもの以外で推測しないでください。
- 評価の結果が合格だった変更でも、後で不具合が出ていれば必ず書いてください。
- 似た変更の後に不具合の記録が見つからないときは、
  「似た変更の後の不具合の記録は見つかりません。不具合が無かったことを意味しません」
  とだけ書いてください。

1回目の申請と評価の呼び出しでは、【答え方】を「似た変更を5件まで、案件番号・ライン・変更の内容・測った項目・試作の数・評価の結果と所見の順に書く」に替えます。 【厳守事項】に「所見は省略せずに書く」を足します。

「合格だった変更でも、後で不具合が出ていれば必ず書く」が、この指示の要です。 何も言わなければ、モデルは評価の結果を見て「この変更は問題なく完了した」とまとめます。合格という記録が、後の不具合の記録を覆い隠します。

「不具合が無かったことを意味しません」を書かせるのも同じ理由です。 記録が見つからないのは、不具合が無かったからか、番号がつながっていないからか、区別がつきません。

出力形式を固定する

2回の応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "request_id": "",
  "change_type": "man | machine | material | method",
  "process": "",
  "line": "",
  "change_text": "",
  "similar_changes": [ { "case_id": "", "line": "", "summary": "", "result": "pass | conditional | fail",
                         "remarks": "", "approved_at": "", "defect_after": false, "uri": "" } ],
  "defects": [ { "case_id": "", "phenomenon": "", "months_after": 0, "cause": "", "action": "", "uri": "" } ],
  "check_items": [ { "item": "", "from": ["case_id"], "source": "evaluation | defect_action", "weak_support": false } ],
  "status": "found | no_similar | no_defect_record"
}

1つ目の理由は、defect_after で似た変更を2つに分けて見せられることです。 画面では、不具合のあった変更を上の枠に、無かった変更を下の枠に出します。担当は、評価が足りなかった例から先に読めます。

2つ目は、check_items の from と source で、候補がどこから来たかが分かることです。 evaluation は過去に測った項目、defect_action は不具合の後に「今後確認する」と書かれた項目です。後者は、過去の評価に無かった項目なので、特に落とせません。

3つ目は、weak_support で根拠の弱い文を見分けられることです。 根拠の強さが低かった文から作った候補には印が付き、画面では灰色になります。品質保証は、印の付いた候補から出典を確かめます。

4つ目は、status の no_defect_record を数えられることです。 似た変更はあるのに不具合の記録がつながらない検索が続く工程は、不具合の報告書に変更の番号が書かれていない工程です。

システムへ連携する

台帳へは書き込みません。 変更の申請と承認はこれまでどおり台帳で行い、この構成は申請の前の調べものだけを受け持ちます。 評価計画を自動で書く機能も作りません。候補をそのまま計画にすると、今回の変更に固有の確認（新しい設備の癖、新しい仕入先の工程）が抜けます。

人が確認する

担当は、評価計画に入れる前に、必ず出典の記録を開きます。 画面に出るのは要点で、測定の条件や規格の値は評価報告書にしかありません。

1. 年代を確かめる … 古い記録は、今と設備も規格も違うことがあります
2. 不具合のあった変更を先に読む … そのとき評価に何が足りなかったかを、報告書の対策で確かめます
3. 候補から外す項目に理由を書く … 外した理由を評価計画の備考に書きます。品質保証はそこを見ます
4. 灰色の候補は出典で確かめる … 根拠の弱い候補は、出典に書かれているかを目で見ます

品質保証の確認も変わります。 これまでは評価計画を読んで足りない項目を思い出していましたが、添付の候補一覧と計画を突き合わせ、外された項目の理由を読む作業になります。

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

目標は、60件をならして1件20分です。 出典を開いて確かめ、評価計画に入れる項目を選ぶ時間の平均です。

例外に対処する

6行目は珍しくありません。 設備の更新に合わせて加工条件も変える変更は、設備と方法の両方です。1つの区分で絞ると、もう一方の失敗例が落ちます。

記録を残す

• 変更の内容、4M区分、工程の種類、日時、担当
• 中継プログラムが組み立てた絞り込みとブーストの式
• answer メソッドの応答の全文（2回分。出典、文ごとの根拠の強さ、回答しなかった理由）
• 確認項目の候補と、担当が評価計画に入れたか・外した理由
• 品質保証が足した項目
• その変更の後に不具合が出たかどうか（後から結びつける）

最後の行で、この構成が効いたかを数えます。 候補一覧を見て評価計画を書いた変更の後に、どれだけ不具合が出たか。候補にあったのに外した項目で不具合が出たなら、外す理由の書き方を見直します。