設計と購買から出る「この部品の代わりに使える承認済みの品番は」「この仕入先は承認済みか」の質問に、承認済み部品・仕入先の一覧（AVL）と変更の記録を根拠にチャットで答え、未承認のものを品質保証へ回す

処理の起点を決める

起点は、設計者か購買担当が窓口のチャットで質問を送ったことです。 画面は社内の ID でログインした人だけが使います。送信の前に、質問の種類を「代替品」「仕入先」の2つから選ばせ、品番か仕入先の欄と、使う製品の欄を必須にします。

使う製品の欄を必須にするのは、条件付きの承認があるからです。 「製品Aの電源基板に限る」という条件は、使う製品が分からなければ当てはまるかを決められません。欄が空なら、条件の引用だけを返し、「当てはまるかは使う製品で確かめてください」と添えます。

索引の更新は別に動かします。 代替品の承認書が承認されたとき、変更通知が文書管理の仕組みに登録されたときに、その文書だけを入れ直します。一覧の写しは毎晩の更新に加え、品質保証部が状態を「停止」「取消」に変えたときは、その行だけをすぐに写します。 停止した部品が翌朝まで「承認」として返るのを防ぐためです。

入力データを集める

質を決めるのは、品目マスタの「社内品番とメーカーの型番の対応」です。 承認書は社内品番で、変更通知はメーカーの型番で書かれていることが多く、対応が無いと、同じ部品の文書を一度に引けません。 メタデータには両方の番号を入れます。

変更通知には「自社の評価の状態」を必ず持たせます。 メーカーの通知は届いた時点では自社の評価が終わっていません。評価中の変更通知がある部品は、一覧の状態が承認でも、品質保証へ回します。

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

承認書と変更通知は、文書ごとにメタデータを付けて Cloud Storage に置きます。 公式のドキュメントでは、メタデータは JSON Lines の形で1行1文書とし、id、structData（または jsonData）、content（mimeType と Cloud Storage の uri）を書きます。非構造化データは1ファイル200MBまでで、1回に10万ファイルまで取り込めます。

絞り込みに使う項目は、データストアのスキーマで索引可能にしておきます。 公式のドキュメントでは、文字の項目は ANY() で完全一致、数値と日付は比較の演算子で比べ、AND／OR と NOT で組み合わせます。日付は ISO 8601 の文字列で書けます。索引可能にしても、絞り込みに使えない項目があるとされているので、試しに絞り込みを投げて確かめます。

ANY() は完全一致なので、メタデータの品番は書き方をそろえた形で入れます。 末尾の包装の記号を除いた形と、元の形の両方を持たせ、絞り込みにはそろえた形を使います。

AIへ渡す前に整形する

1. 品番の書き方をそろえる … 全角と半角、ハイフンの有無、末尾の包装の記号（テープ・リールなど）を、品目マスタの規則で同じ形にします
2. 社内品番と型番を結ぶ … 品目マスタの対応から、質問の品番をもう一方の番号にも置き換え、両方で一覧を引きます
3. 一覧を引く … 品番と仕入先コードの完全一致で行を取ります。一致が無いときに、近い品番を探しに行きません
4. 承認書を見出し付きで分割する … 承認書の「適用範囲」の段落に、承認書の番号と見出しが付くようにします
5. 変更通知の評価の状態を付ける … 品質保証部の評価の台帳から pcn_eval_status を付け直します
6. 古い承認書を確かめる … スキャンした古い承認書は、適用範囲が読めているかを20件ほど抜き出して確かめます

4番目は、データストアを作る前に決めます。 公式のドキュメントでは、レイアウトパーサーは PDF・DOCX などの表と見出しを検出し、分割の大きさは100〜500トークン（既定は500）で、includeAncestorHeadings は既定で無効、分割の設定はデータストアを作った後に切り替えられません。 適用範囲の段落に承認書の番号が付いていないと、どの承認書の条件か分からない引用が返ります。

3番目を守るのが、この構成でいちばん大事な前処理です。 一覧に行が無いことは、それ自体が答えです。近い品番を並べると、読む人は「承認済みの候補」として受け取ります。

AIに処理させる

検索と回答の作成は、answer メソッドに任せます。 中継プログラムが渡すのは、質問の文、絞り込み、指示の前置き（preamble）です。承認の状態は前置きの中で「一覧ではこう」と渡し、AIには状態を判断させません。

関連の薄い結果しか無いとき、answer は答えの代わりに理由を返します。 公式のドキュメントでは、関連が薄いと NO_RELEVANT_CONTENT、根拠の基準に届かないと LOW_GROUNDED_CONTENT が answerSkippedReasons に入ります。どちらも「承認書が見つからない」として品質保証へ回します。

生成AIにさせることは、3つに限ります。

3行目がいちばん起きやすい失敗です。 「C-10-4471 の代替は」と聞くと、生成AIは同じ容量の別メーカーの部品を「候補」として挙げがちです。承認の外の部品を候補として見せると、それだけで設計者は試作に使い始めます。

指示内容を固定する

answer メソッドの promptSpec の preamble に、次の指示を入れます。{} の中は中継プログラムが埋めます。

あなたは品質保証部で、部品と仕入先の承認の条件を社内に案内する立場です。
検索結果（代替品の承認書、変更通知、評価報告書、仕入先の監査報告）に
書かれていることだけを根拠にしてください。

【一覧で決まっていること（変えないでください）】
対象の品番：{part_no}　一覧の状態：{avl_status}
一覧に記録された承認書の番号：{approval_doc_no}
使う製品：{product}

【答え方】
1. 最初に、根拠にした承認書の番号を書いてください。
2. 承認書の「適用範囲」に書かれた製品・顧客・期限の条件を、
   原文のまま書いてください。言い換えたりまとめたりしないでください。
3. 評価が終わっていない変更通知があれば、変更の内容と実施の時期を
   原文のまま書いてください。

【厳守事項】
- 承認済みかどうかを、あなたが判断して書かないでください。
  状態は上の一覧の状態だけです。
- 一覧に記録された番号と違う承認書を根拠にしないでください。
- 検索結果に無い部品や、似た品番を候補として挙げないでください。
- 代替品として性能や形状が同等かを書かないでください。
- 使う製品が条件に当てはまるかを結論として書かないでください。
  条件の原文を示すだけにしてください。
- 条件が書かれていなければ「記載なし」としてください。

「承認済みかを判断しない」と「似た品番を挙げない」を両方書くのは、別の失敗だからです。 前者は状態の取り違え、後者は承認の外への広がりです。どちらか一方だけを禁じると、もう一方の形で出てきます。

一覧の状態を前置きで渡すのは、答えの文の中で状態と矛盾させないためです。 渡さないと、承認書の本文の「承認する」という文を根拠に、停止中の部品を「承認済み」と書くことがあります。

出力形式を固定する

answer の応答と一覧の行から、中継プログラムが次の形に組み立ててチャットへ返します。 公式のドキュメントでは、応答の citations に答えの中の位置（startIndex・endIndex）と出典の参照が入り、references に分割の本文（chunkInfo の content）と文書のメタデータが入ります。位置は文字ではなく UTF-8 のバイトで数えられるので、日本語の答えはバイト列で切り出します。

{
  "question_id": "",
  "question_type": "substitute | supplier",
  "part_no": "",
  "product": "",
  "avl": {
    "row_found": true,
    "status": "approved | conditional | suspended | revoked | not_listed",
    "approval_doc_no": "",
    "supplier_code": ""
  },
  "conditions_quoted": "",
  "open_pcn": [{ "pcn_no": "", "change": "", "effective": "" }],
  "sources": [{ "doc_type": "", "doc_no": "", "quoted_text": "" }],
  "doc_no_check": "matched | mismatch",
  "route": "answered | escalate",
  "escalate_reason": "not_listed | suspended | open_pcn | doc_mismatch | no_document | product_unclear"
}

1つ目の理由は、avl と conditions_quoted を別の層に置けることです。 avl は一覧から機械的に入り、conditions_quoted は検索の結果から入ります。画面では状態を一覧の側から表示し、AIの文は条件の欄にしか出しません。

2つ目は、doc_no_check で取り違えを止められることです。 sources の承認書の番号が avl.approval_doc_no と一致しなければ mismatch にし、答えを返さずに escalate にします。

3つ目は、escalate_reason で品質保証の待ち行列を仕分けられることです。 一覧に無いものは承認申請の受付、停止中のものは代わりの部品の相談、評価中の変更通知は評価の担当と、することが違います。

システムへ連携する

一覧へは書き込みません。 検索の結果と一覧が食い違っていても、一覧を直すのは品質保証部の担当です。 食い違いは待ち行列に「一覧の更新漏れの疑い」として渡します。

承認申請の起票もしません。 一覧に無い品番は、申請の様式への案内を返すだけにします。申請を出すかどうかは、設計と購買が決めることです。

人が確認する

1. 引用の確認（質問した人） … 条件の引用から承認書を開き、使う製品が適用範囲に入るかを確かめます
2. 回ってきた質問への回答（品質保証の担当） … 一覧に無いもの、停止中のもの、評価中の変更通知があるものに答えます
3. 一覧の更新漏れの確認（品質保証の担当） … 食い違いが出た行を確かめ、一覧を直します
4. 答えの当たり外れ（質問した人） … 答えが役に立ったかを、チャットのボタンで残します

目安は、360件をならして1件8分です。 質問した人が承認書を開いて条件を確かめる時間と、品質保証の担当が回ってきた質問に答える時間を合わせた平均です。回る質問は2割強という想定で、それより多い月は、メタデータの品番が足りていないか、変更通知の評価が滞っています。

条件付きの承認は、必ず原文を開いてもらいます。 引用は適用範囲の段落だけなので、別紙で条件が足されている承認書は、本文を開かないと分かりません。

例外に対処する

最後の行で一覧の状態だけを返せるのは、状態を検索の仕組みに頼っていないからです。 検索が止まっても、「承認済みか」には答えられます。

記録を残す

• 受け取った質問、質問の種類、品番、使う製品、質問した人
• そのとき引いた一覧の行の内容
• 渡した絞り込みと前置き、answer の応答の全文（答え、引用、根拠のスコア、answerSkippedReasons）
• 承認書の番号の照合の結果と、回した理由
• 質問した人が付けた当たり外れと、品質保証が答えた内容

2行目で一覧の行を残すのは、状態が後から変わるためです。 部品が後で停止になったとき、質問の時点で承認だったのか、すでに停止だったのかが分からないと、誤った答えだったのかを確かめられません。