品質担当と製造現場から出る「この顧客の品質要求はどうなっているか」の質問に、顧客ごとの品質保証協定書・図面の特記・要求事項を根拠にチャットで答える

処理の起点を決める

起点は、担当者が品質要求チャットに質問を送ったことです。 チャットは社員番号でログインした人が使え、質問した人の所属と、品番から引いた顧客で、回したときにどの担当者の待ち行列に載せるかを決めます。

品番を必須にします。 品番が分からない営業の質問もあるので、顧客と事業部を選ばせる道も残しますが、その場合は図面の特記を答えに使いません。 図面の版が決まらないからです。

1件の質問は、1つのセッションで最後まで続けます。 「では材料の購入先を変える場合は」のような続けての質問も同じセッションでつなぎ、別の品番の話は新しいセッションで始めます。 前の品番の顧客が言い換えの中に残るからです。

入力データを集める

質を決めるのは、図面の特記の一覧です。 図面はスキャンした画像や CAD から出したPDFが多く、特記は図面の枠の隅に小さく書かれています。 図面そのものを取り込まず、品質保証課が品番と版ごとに特記の文を表に起こし、特別な特性の記号もその表に書きます。

協定書の「文書の優先」の条項は、表にもします。 協定書と図面と個別の取り決めが違うときどれが優先するかは、顧客ごとに協定書に書かれています。 中継プログラムが食い違いを見つけたとき、どの条項を担当者に示すかに使います。

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

協定書・要求の文書・特記の一覧・過去の回答は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、顧客、協定書の区分、文書の種類、図面の版、改訂日、見てよいグループを持たせます。

絞り込みの式は、顧客と区分と版で書きます。 項目を索引可能にしておけば、customer: ANY("C023") AND agreement_unit: ANY("C023-AUTO") AND drawing_rev: ANY("72-1045-E", "NONE") AND superseded: ANY("false") のように、その顧客のその事業部の協定書と、現行の版の特記と、置き換えられていない回答だけを引けます。NONE は図面に関係しない協定書と要求の文書に付けます。

見てよいグループは、顧客の担当ごとに作ります。 品質保証課の全員と、その顧客の品番を作るラインの職長、その顧客の営業を入れます。文書ごとに人を書くと、異動のたびに3,000品番分の書き直しになります。

AIへ渡す前に整形する

1. 協定書を条項ごとに分ける … 条の見出しが付いた形で取り込み、顧客と区分を付けます
2. 要求の文書を章ごとに分ける … 変更の管理、記録、不適合、表示の章の見出しを残します
3. 図面の特記を起こす … 品番と版ごとに、特記の文と特別な特性の記号を表にします
4. 古い版に印を付ける … 協定書と要求の文書の改訂、図面の改訂のたびに、古い版に置き換えの印を付けます
5. 過去の回答を整える … 顧客、文書の版、置き換えの有無を付けます
6. 見てよいグループを付ける … 顧客ごとに、担当のグループを acl_info に書きます
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

3番目が、この構成でいちばん手間がかかり、いちばん効きます。 量産品番3,000の特記を一度に起こすのは現実的でないので、質問の多い顧客の品番から始め、図面の改訂のたびに足していきます。

6番目と7番目は、データストアを作る前に決めます。 アクセス制御も分割も、作成のあとでは有効にも無効にもできません。 見出しを含める設定は既定では無効で、協定書の条項は見出しが無いとどの顧客のどの章か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、台帳で決めた顧客と版の協定書・要求の文書・特記から、質問に当たる決まりを見つけ、何をすればよいかを根拠を付けて短く返すことです。 顧客と版を決めること、数字と食い違いを確かめること、回すかどうかは、中継プログラムが行います。

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

3行目がいちばん起きやすい失敗です。 協定書に「記録は15年」、要求の文書に「品番の生産終了後10年」とあると、モデルは二つを一つの文にまとめ、どちらとも違う答えを作ります。 食い違いは解かせず、後段で見つけて人へ回します。

指示内容を固定する

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

あなたは部品メーカーの品質保証課の担当者として、
製造現場・営業・品質の担当者から、顧客の品質要求の質問に答えます。
読むのは、作業を始める前にチャットを見ている担当者です。短く答えてください。

【前提】
検索の文の最初に、品番、顧客、協定書の区分、現行の図面の版、
質問の種類が並んでいます。
顧客と版はすでに決まっています。その顧客とその版の文書だけを使って答えてください。

【答え方】
1. 最初に、質問に当たる決まりを、文書の文言のとおりに書いてください。
2. 次に、誰が、何を、いつまでにするかを書いてください。
3. 図面の特記に関係する指示があれば、特記の番号と文を書いてください。
4. 根拠にした協定書の条、要求の文書の章、特記の番号を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  業界の一般的な要求や他の顧客の決まりで補わないでください。
- 日数・年数・時間などの数字は、文書に書かれたとおりに写してください。
  言い換えたり、丸めたり、換算したりしないでください。
- 二つの文書で書いてあることが違うときは、まとめずに両方をそのまま書き、
  「文書の間で記載が異なります」と書いてください。
- 顧客へ届け出るべきか、届け出なくてよいかの結論を書かないでください。
- 該当する記載が見つからないときは、
  「協定書と要求の文書に該当する記載が見つかりません。品質保証課へ回します」
  とだけ書いてください。

「数字は写す」「違うときはまとめない」が、この指示の要です。 何も言わなければ、モデルは「10営業日」を「約2週間」と言い換え、二つの年数を「10年以上」とまとめます。読みやすくするつもりの言い換えが、そのまま協定違反の元になります。

検索の文は、中継プログラムが組み立てます。 例えば「品番：72-1045、顧客：C023（自動車事業部）、図面：72-1045-E、種類：変更の届出、変えるもの：金型の補修。顧客への届出は要るか」のように、条件を先に並べ、担当者の質問の文を最後に足します。 顧客は社名ではなく、台帳のコードで渡します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "part_no": "72-1045",
  "customer": "C023",
  "agreement_unit": "C023-AUTO",
  "drawing_rev": "72-1045-E",
  "category": "change_notice | records_labeling | nonconformity | other",
  "conditions": { "change_item": "", "already_happened": false },
  "status": "answered | escalated | skipped",
  "escalate_reason": "shipped_defect | concession | change_not_in_agreement | new_requirement | number_not_in_source | conflict | part_unknown | not_in_docs | skipped | user_request | none",
  "answer_text": "",
  "numbers": [ { "text": "10営業日", "found_in_ref": true } ],
  "refs": [ { "doc_type": "agreement | requirement | drawing_note | qa", "title": "", "section": "", "revision": "", "uri": "" } ],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、numbers を回答の文と別に持てることです。 中継プログラムが回答の文から日数・年数・時間を拾い、応答の references に入っている断片の中身に同じ文字列があるかを照らします。1つでも false があれば、回答を出さずに number_not_in_source で回します。

2つ目は、refs の文書の種類ごとに根拠を並べられることです。 協定書と特記が両方根拠になっていれば、担当者は両方を開いて確かめるべきだと画面で分かります。回答の文に「文書の間で記載が異なります」があれば、conflict で回します。

3つ目は、escalate_reason で回った理由を数えられることです。 not_in_docs が多い顧客は協定書の取り決めが足りない、part_unknown が多ければ台帳の協定書の区分が埋まっていないことが分かります。

システムへ連携する

品番の台帳と図面管理の仕組みには、書き込みません。 台帳の顧客や版が違っていると分かっても、チャットからは直しません。台帳の訂正は、生産管理の手順で行います。 品番の顧客を現場の申告で書き換えると、別の顧客の協定で答える回答が残ります。

人が確認する

質問した人は、回答を読んだあと、根拠の協定書の条と図面の特記を開いてから作業に入ります。 回答の上には、台帳から引いた顧客と図面の版を並べて表示します。

1. 品番と版が合っているかを見る … 現場にある図面の版と、画面の版が同じかを確かめます
2. 根拠を開く … 協定書の条と特記を開き、数字が回答と同じかを見ます
3. 評価を付ける … 解決した／品質保証課へ回した／誤りを選びます

1番目を軽く見ないでください。 図面の改訂が現場に届くまでに日数がかかると、画面の版のほうが新しいことがあります。 違っていたら、現場の図面の差し替えが先です。

品質保証課の担当者は、回ってきた質問だけを見ます。 shipped_defect はその日のうちに顧客への連絡の要否を決め、協定書の連絡の期限から逆算して動きます。

目標は、240件をならして1件7分です。 チャットで解決した質問の記録の確認と、回ってきた質問を担当者が判断する時間の平均です。

例外に対処する

3行目は、運用の約束として現場に伝えておきます。 すでに出荷した不良を相談できる窓口だと分かっていないと、現場は「これから出たら」という形で聞き、連絡の期限を過ぎてから品質保証課が知ることになります。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、所属
• 台帳から引いた顧客・協定書の区分・図面の版と、そのときの台帳の更新日
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、根拠の断片、根拠のスコア、回答しなかった理由）
• 数字の照合と食い違いの判定の結果
• 回す・回さないの判定と、その理由、品質保証課が最終的に答えた内容
• そのとき効いていた協定書・要求の文書・図面の版

最後の行は、顧客の監査で効きます。 協定書が改訂されたあとで、当時なぜその答えで変更を進めたかを並べて見られるようにしておきます。

記録は、顧客ごとに見られる人を分けます。 問い合わせの記録にも協定書の文言と特記が写るので、記録の閲覧の権限も、データストアと同じ顧客の担当のグループで付けます。 全社で見られる表に残すと、アクセス制御で守った範囲がそこから漏れます。