取引先の品質監査を受ける前に、過去の顧客監査の指摘事項・是正回答・質疑の記録から、同じ顧客と同業の顧客で指摘されやすい点を探し、根拠の記録付きで準備資料にする

処理の起点を決める

監査の登録を起点にします。 担当者が顧客・工場・日程・対象の工程を登録した時点で、1件ずつ動かします。顧客から日程の連絡が届いてから準備までは2〜3週間なので、登録した日のうちに下書きが出れば、製造課に定着の確認を頼む時間が残ります。

監査の1週間前に、もう一度動かします。 登録から監査までのあいだに、ほかの工場で同じ顧客の監査があったり、同業の顧客で新しい指摘が出たりします。2回目は差分だけを下書きに足し、担当者に知らせます。

索引の更新は別に動かします。 監査の報告書を受け取ったとき、是正回答を出したとき、質疑のメモを登録したときに、その記録だけを索引に入れ直します。 監査は工場をまたいで続くので、夜にまとめて入れ直すと、前日のほかの工場の指摘が間に合わないことがあります。

入力データを集める

質を決めるのは、指摘事項の「区分」です。 集計は区分の値で行うので、区分が付いていないか、人によって付け方がばらばらだと、偏りが見えません。 区分は、自社の品質マネジメントの項目に沿った20〜30個の一覧にし、過去の指摘に付け直します。

是正処置の台帳の「効果の確認」を持たせる理由は、定着の確認につなげるためです。 完了の日だけでは、是正をやって終わったのか、その後に効いているかを確かめたのかが分かりません。効果の確認の記録が無い指摘は、準備資料で目立たせます。

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

監査の報告書は、指摘1件を1つの記録に分けて索引に入れます。 報告書1通をそのまま入れると、区分の集計が報告書の単位になり、1通の中に何件同じ区分の指摘があっても1件と数えられます。 分けたうえで、報告書の番号と指摘の番号を持たせます。

同業で多い区分は、terms で集計します。 公式のドキュメントでは、返す区分の数 size は既定で10です。各シャードから上位の候補を集めて合わせる仕組みなので、件数は近似になることがあり、応答の doc_count_error_upper_bound で誤差の上限が分かります。指摘の記録は数千件の規模なので、シャードを1つにしておけば誤差は気にせずに済みます。

significant_terms の結果が空になることがあります。 公式の説明では、前景が絞り込まれていないか、前景と背景の分布が同じときに区分が返りません。監査の回数が少ない顧客では前景が数件しかなく、偏りが出ないこともあります。その場合は「この顧客に特有の傾向は、記録が少なく出せない」と書き、同業の傾向で代えます。

偏りの点数の付け方は、一つの要求につき一つを選びます。 公式のドキュメントでは、JLH が多くの汎用の場面に向くとされ、件数の絶対的な増え方と、背景と比べた相対的な増え方の両方を見ます。ほかに相互情報量、カイ二乗などがあり、相互情報量とカイ二乗には、前景のほうが少ない語を外す include_negatives と、背景が前景を含むかを示す background_is_superset があります。この構成では背景（同じ業界の顧客）がこの顧客を含むので、含む前提のまま使います。点数には単位が無く、同じ要求の中の順位を比べるためだけのものなので、点数の値そのものを準備資料に書かせません。

AIへ渡す前に整形する

1. 報告書を指摘ごとに分ける … 報告書のPDFから指摘の一覧を取り出し、1件ずつの記録にします
2. 区分を付ける … 指摘ごとに、自社の区分の一覧から1つを付けます。付けた区分は品質保証の担当者が確かめます
3. 顧客の書き方をそろえる … 「重大」「メジャー」「Major」、「観察事項」「改善の機会」など、顧客ごとに違う重さの書き方を三つにそろえます
4. 是正回答と結び付ける … 是正回答に書かれた指摘の番号で、指摘の記録と結び付けます
5. 工程の名前をそろえる … 工場ごとに違う工程の呼び方を、共通の工程の一覧に寄せます
6. 顧客の名前を記録の外に出す … 本文に書かれた顧客の名前と担当者の名前を、顧客のコードに置き換えます

2番目は、生成AIに候補を出させてかまいません。 ただし、付けた区分をそのまま集計に使うのは、担当者が確かめた後にします。区分がずれると、偏りの集計がまるごとずれるからです。

6番目は、準備資料をほかの顧客に見せないためです。 同業の顧客の傾向を準備資料に入れると、ほかの顧客の名前と指摘が一つの資料に並びます。 監査の当日に資料を机に置いたまま席を外せば、顧客の目に入ります。索引の段階で顧客の名前をコードに置き換え、同業の傾向は「同業の顧客」とだけ書きます。

AIに処理させる

集計は検索基盤が行い、生成AIには集計の結果と記録を読んで、準備資料の下書きを書かせます。

2行目がいちばん起きやすい失敗です。 台帳に「完了」とあれば、生成AIは「是正済み」と書きます。完了と定着は別のもので、それを分けるのが準備の目的そのものです。

指示内容を固定する

あなたは品質保証部で、顧客による品質監査の準備資料の下書きを作る
立場です。渡した記録と集計の結果だけを根拠にしてください。

【今回の監査】顧客コード {customer_code}、工場 {plant}、
             対象の工程 {process}、監査の日 {audit_date}
【前回までの指摘】{past_findings}
【是正処置の台帳の状態】{capa_status}
【この顧客に特有の区分】{significant_terms_result}
【同業で多い区分】{terms_result}
【対象の工程の質疑】{qa_records}

【作る順序】
1. 前回までの指摘：指摘ごとに内容・是正の内容・台帳の状態を1行で
2. 定着の確認：効果の確認の記録が無い指摘を、製造課に確かめて
   もらう点として並べる
3. この顧客に特有の区分：区分ごとに、根拠の指摘を2〜3件
4. 同業で多い区分：区分ごとに、自社のほかの工場で同じ指摘が
   あったか
5. 想定質問：過去に出た質問と、当日の回答

【厳守事項】
- 台帳が「完了」でも「是正が定着している」と書かないでください。
  定着は現場で確かめるまで「未確認」としてください。
- 今回の監査で何を指摘されるかを予測しないでください。
  「過去にこう指摘された」までにしてください。
- 集計の件数と順位は、渡した値をそのまま使ってください。
- ほかの顧客の名前、顧客のコードを書かないでください。
  同業の傾向は「同業の顧客」とだけ書いてください。
- 是正回答の内容を言い換えたり、改善案を足したりしないでください。
- 記録に無い内容は「記録なし」としてください。

「完了でも定着と書かない」を明記しないと、2番目の項目が空になります。 台帳がすべて「完了」なら、生成AIには確かめるべき点が無いように見えます。完了と定着を言葉として分けて渡すことで、確認の依頼が出るようにします。

「ほかの顧客のコードも書かない」も同じ理由です。 名前を消しても、コードが資料に残れば、社内の人が見ればどの顧客かが分かります。 準備資料に残すのは、自社の顧客自身の記録と、同業の集計の結果だけです。

記録は、Claude の検索結果のブロックで渡します。 公式の説明では、source・title・content を持つブロックで渡すと、自社の文書を引用付きで答えられ、Amazon Bedrock でも使えます。source には報告書の番号と指摘の番号を入れ、準備資料のどの行がどの記録に基づくかを、担当者がすぐに開けるようにします。

出力形式を固定する

次の形のJSONで受け取り、準備資料の書式に流し込みます。

{
  "audit": { "customer_code": "C-031", "plant": "第2工場", "process": "樹脂成形", "date": "2026-11-12" },
  "past_findings": [
    { "finding_id": "AR-2025-044-03", "plant": "第1工場", "category": "変化点管理",
      "severity": "minor", "corrective": "", "capa_status": "完了",
      "effect_checked": false, "sustainment": "未確認" }
  ],
  "check_requests": [{ "finding_id": "AR-2025-044-03", "what_to_check": "" }],
  "distinctive_categories": [
    { "category": "初物の記録", "doc_count": 7, "bg_count": 12, "examples": ["AR-2024-112-01"] }
  ],
  "common_in_industry": [
    { "category": "計測器の校正", "count": 15, "our_other_plants": ["AR-2026-008-02"] }
  ],
  "expected_questions": [{ "question": "", "past_answer": "", "source": "QA-2025-031" }],
  "notes": ""
}

1つ目の理由は、capa_status と sustainment を別の項目に置けることです。 台帳の状態は記録から引いた事実、定着は現場で確かめる事実です。同じ「済み」でも、確かめた人と日が違います。 sustainment は製造課が確かめた後に人が埋めます。

2つ目は、distinctive_categories に件数を残せることです。 doc_count と bg_count が並んでいれば、偏りが7件と12件の比なのか、1件と2件の比なのかが分かります。 件数が少ない区分は、偏りがあっても参考程度に読みます。

3つ目は、our_other_plants で自社のほかの工場の記録が見えることです。 同業で多い指摘を、自社のほかの工場がすでに受けていれば、その是正をこの工場にも横展開できているかを確かめる材料になります。

システムへ連携する

是正処置の台帳には書き込みません。 準備の中で定着が確かめられても、台帳の更新は品質保証の担当者がこれまでどおりの手順で行います。 下書きの仕組みが台帳を書き換えると、誰が確かめたのかの記録が残りません。

索引には、細かなアクセス制御を掛けます。 公式のドキュメントでは、役割ごとに索引・文書・項目の単位で見える範囲を決められます。 工場の担当者には自分の工場と同業の集計を、本社の品質保証には全工場を見せる、という分け方ができます。

人が確認する

下書きは、すべて担当者が確かめます。

1. 前回の指摘の一覧を見る … 工場をまたいだ指摘が並んでいるか、抜けている報告書が無いかを確かめます
2. 定着の確認を依頼する … check_requests を製造課に渡し、現場で確かめてもらいます。結果は sustainment に人が書きます
3. 特有の区分の根拠を開く … 偏って多い区分ごとに、根拠の指摘を1件は開いて読みます
4. 資料から顧客の情報が漏れていないかを見る … ほかの顧客を推測できる書き方が残っていないかを確かめます

2番目を省かないでください。 準備資料のいちばん大事な欄で、ここが「未確認」のまま監査の日を迎えると、準備の意味がありません。

目標は、1件120分です。 下書きを読み、根拠を確かめ、製造課への依頼を出し、打ち合わせの資料に整えるまでの時間です。探す時間がほぼ無くなり、残るのは読んで判断する時間です。

例外に対処する

上から2行目を、きちんと結果にしてください。 集計が空なのに何も書かないと、担当者は仕組みが動かなかったのか、偏りが無いのかを区別できません。

記録を残す

• 監査の登録の内容と、検索と集計の条件
• 集計の結果（区分ごとの件数・背景の件数・偏りの強さ）
• 生成AIに渡した記録と、返ってきたJSONの全文
• 製造課が確かめた定着の結果と、確かめた人と日
• 監査の当日に実際に受けた指摘
• 下書きに出ていた区分と、実際の指摘の区分の重なり

最後の行が、仕組みを良くする材料になります。 実際の指摘が下書きの特有の区分や同業の区分に入っていたかを数えれば、準備資料が効いているかが分かります。 入っていなかった指摘は、区分の一覧の見直しか、新しい見方の追加の材料にします。