顧客から品質クレームを受けたときに、受付記録・調査結果・対策のメモから8Dレポートの下書きを作り、原因と対策のつながりの弱い箇所を品質管理の担当へ返す

処理の起点を決める

クレーム管理リストの「状態」が「8D下書き依頼」に変わったことを起点にします。 受付の時点では動かしません。調査が終わっていない段階で下書きを作っても、ほとんどの項目が未記載になり、指摘の一覧が「調査をしてください」で埋まるだけです。

状態を変えるのは、品質管理の担当です。「資料がそろった」と判断するのは人の仕事にします。 目安は、解析報告と製造課の聞き取りのメモが案件のフォルダに入り、暫定の対策の結果がリストに書かれていることです。

顧客の期限が2段階のときは、状態を2回使います。 暫定の回答（D3まで）の期限が近い段階で「8D下書き依頼（暫定）」、恒久対策まで出る段階で「8D下書き依頼（最終）」に変えます。暫定のときは、D4以降を作らせず、D3の内容と、D4以降で何を調べるかの予定だけを返させます。

同じ案件で何度でも動かせるようにします。指摘を受けて調査を足したら、状態を戻して再び依頼し、前回の指摘のうち何が解消されたかを並べて返します。

入力データを集める

最も大事なのは、いちばん下の記載ルールです。 「発生原因と流出原因は必ず分けて書く」「対策には実施日と担当部署を書く」「効果の確認には期間と数量を書く」といった自社の書き方を、1枚にまとめておきます。これが無いと、AIは一般的な8Dの書き方で埋め、顧客ごとの差し戻しの傾向が反映されません。

過去に差し戻された指摘も、この1枚に書き足していきます。 顧客に何を言われたかが、次の報告の点検の観点になります。

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

受付記録は、Logic Apps の SharePoint の操作でリストの項目を読みます。読むのは状態を変えた1件だけです。 案件のフォルダは、リストの「案件番号」の列からフォルダの場所を決め、中のファイルの一覧を取ります。

資料ごとに、ファイル名と資料の種類を付けて渡します。 後で「この数字はどの資料から取ったか」を照合するためです。渡すときに [資料A] 解析報告_第2版.pdf のような見出しを付け、AIにはこの記号で出典を書かせます。

版が複数あるときは、最新の版だけを渡します。 解析報告が第1版と第2版で原因の推定を変えていることがあり、両方を渡すと古いほうを根拠にした文が混ざります。フォルダの運用で、古い版は「旧版」のサブフォルダに移す決まりにしておくと、取得の側が単純になります。

AIへ渡す前に整形する

1. 形式の確認 … PDF、テキスト、Word を受け付けます。Responses API にファイルとして渡すのはPDFだけにし、Word のメモはテキストに起こしてから渡します
2. 大きさの確認 … 各ファイルが50MB未満、要求内の合計も50MBまでです。写真を高解像度で貼り込んだ解析報告は大きくなるので、超えたら写真のページを分けるか、解像度を下げたPDFを作り直してもらいます
3. 版の確認 … 同じ種類の資料が複数あれば、最終更新日が新しいものを選び、選ばなかったものを記録します
4. 受付記録の欠けの確認 … 品番、ロット、数量、発見の日が空なら、AIを呼ぶ前に担当者へ戻します。ここが空のまま下書きを作っても、D2が埋まりません
5. 個人名の置き換え … 聞き取りのメモに書かれた作業者の氏名を、「作業者A」のような記号に置き換えます。8Dレポートに個人名は要りません
6. 資料の記号付け … 資料ごとに [資料A] [資料B] の記号を振り、一覧を残します

5番目は、顧客に出す文書だからこそ必要です。 聞き取りのメモには、誰がどの作業をしていたかが書かれています。下書きにそのまま入ると、作業者個人の責任として顧客に読まれる文章になります。原因は仕組みの側に書くのが8Dの考え方で、氏名はその妨げにしかなりません。

AIに処理させる

させるのは、記録に書かれていることを8Dの項目に並べ直すことと、項目どうしの対応を表にすることです。

D4で発生原因と流出原因を分けさせるのが、この構成の要です。 ASQ の8Dの解説でも、D4では問題が起きた原因に加えて、起きたときになぜ気づかれなかったかも特定するとされています。記録に流出原因の検証が無ければ、AIはそれを埋めずに「流出原因：未記載」とし、指摘に回します。

対応表は、原因1つを1行にします。 列は「原因」「種類（発生／流出）」「検証の方法と結果」「対応する対策」「対策の実施日」「効果の確認」です。空欄のある行が、そのまま指摘になります。

最も起きやすいのは1行目です。 解析報告が「推定」で止まっている原因を、下書きでは断定の文にして書きます。指示で「検証の記録が無い原因には必ず『推定』と付ける」と書き、出力の側にも verified の真偽を持たせます。

指示内容を固定する

あなたは製造業の品質管理部で、顧客に提出する8Dレポートの下書きを作る担当です。
渡された資料に書かれていることだけを使って、D0〜D8の下書きと、
原因と対策の対応表を作ってください。

【資料】
資料には [資料A] のような記号が付いています。
文を書くときは、根拠にした資料の記号と、その資料の中の文をそのまま
evidence に写してください。資料に無いことは書かないでください。

【書き方の決まり】
- 発生原因（なぜ不良が作られたか）と流出原因（なぜ検査で見つからずに
  出荷されたか）は、必ず分けて書いてください。
- 原因に検証の記録（再現試験、測定、比較の結果）が資料にあれば
  verified を true にし、無ければ false にして、文の頭に「推定：」を付けてください。
- 対策は「実施済み」と「予定」を分けてください。実施日が資料に無い対策は
  「予定」とし、日付を作らないでください。
- 数量・不良率・日付は資料の値をそのまま写してください。
  計算、丸め、単位の換算をしないでください。
- 作業者の個人名を書かないでください。原因は手順・設備・検査の仕組みの
  側に書いてください。
- 「再発はゼロになる」「今後一切発生しない」のような約束を書かないでください。
- D8 は空けてください。

【未記載の扱い】
資料に記載がない項目は、文を作らず status を missing にしてください。
missing の項目ごとに、何が分かれば埋まるかを need に書いてください。
迷ったときに文を作らないでください。

【対応表】
原因1つを1行にし、その原因に対応する対策、実施日、効果の確認を並べてください。
対応する対策が無い原因、どの原因にも対応しない対策も、そのまま行として残し、
link_status に no_action / no_cause / no_verification を入れてください。

【自社の記載ルール】{writing_rules}
【受付記録と暫定の対策】{intake_record}
【資料の一覧】{document_index}
【区分】{phase}（interim のときは D4 以降を作らず、調べる予定だけを書く）

「日付を作らないでください」を明記しないと、予定の対策に日付が付きます。 打合せメモの「来月から」という書き方を、具体的な日付に直して書くことがあります。顧客はその日付を、約束として受け取ります。

「対応しない対策も行として残す」も欠かせません。 何も言わなければ、AIは対応の取れる行だけを並べたきれいな表を返します。崩れた対応を見つけるための表なので、崩れたまま出させます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "claim_id": "",
  "phase": "interim | final",
  "sections": [
    { "d": "D2", "status": "ok | partial | missing",
      "text": "", "evidence": [ { "doc": "資料A", "quote": "" } ],
      "need": "" }
  ],
  "causes": [
    { "id": "C1", "type": "occurrence | escape", "text": "",
      "verified": false, "evidence": [ { "doc": "", "quote": "" } ] }
  ],
  "link_table": [
    { "cause_id": "C1", "action": "", "action_state": "done | planned",
      "action_date": "", "verification": "",
      "link_status": "ok | no_action | no_cause | no_verification" }
  ],
  "five_w2h_missing": [],
  "promises_detected": []
}

sections にはD0〜D8の9つを並べます。構造化出力では、スキーマのすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定します。値が無いときは空の文字列か空の配列で返させ、キーそのものは省かせません。 スキーマに置けるオブジェクトのプロパティは最大100個、入れ子は最大5レベルなので、この形はその範囲に収まります。

JSONで受け取る理由は3つあります。 1つ目は、evidence の quote をプログラムで元の資料と照合できることです。資料に無い文を引用したことにしている行は、照合で見つかります。

2つ目は、link_table の link_status から指摘の一覧を機械的に作れることです。指摘の文章をAIに書かせると、毎回書き方が変わります。状態の値から決まった文面を出すほうが、担当者が読み慣れます。

3つ目は、promises_detected で約束の表現を拾えることです。資料のメモに「再発ゼロを約束する」と書かれていた場合でも、下書きに入る前に責任者の目に触れます。

システムへ連携する

下書きは、リストの項目に書き込みます。 D0〜D8を列にし、指摘は別の列に箇条書きで入れます。取引先の様式のファイルへ直接は書き込みません。 様式は取引先ごとに違い、専用のシステムへの入力を求める取引先もあるため、最後に移すのは人の作業として残します。

Teams の通知には、指摘の件数と no_action の有無だけを書き、下書きの本文は載せません。 本文はリストで読みます。チャットに流れると、取引先の不具合の内容が関係のない人の目に触れます。

人が確認する

下書きはすべて人が確認します。 顧客に出す報告で、AIの出力をそのまま送る経路は作りません。

1. 指摘から先に見る … no_action と流出原因の欠けがあれば、文章を読む前に調査の依頼を出します
2. verified: false の原因を確かめる … 解析担当に、検証の記録があるかを聞きます。無ければ「推定」のまま出すか、検証をしてから出すかを決めます
3. 照合で外れた引用を見る … 資料に無い文が引用されていれば、その文を下書きから消します
4. 予定の対策の日付を確かめる … 対策の担当部署に、実施の見込みを確認します
5. 課長が全体を読む … 顧客に何を認め、何を約束するかを決めます

目標は、24件をならして1件75分です。 内訳は第10章に書きます。指摘が多い案件は75分を超えますが、それは書く時間ではなく、調査を足す時間です。

確認で直した箇所は、記録に残します。 どの項目を、どう直したかがたまると、記載ルールの1枚に足す観点が見えてきます。

例外に対処する

上から3行目は、運用の決まりで減らせます。 状態を「8D下書き依頼」に変える前に、解析報告がフォルダに入っていることを確かめる手順にしておけば、ほとんど起きません。

英語の提出は、この構成の外に置きます。 下書きの段階で英語にすると、確認する人が日本語と英語の両方で論理を追うことになり、つながりの点検が甘くなります。

記録を残す

• AIに渡した資料の一覧（ファイル名、版、最終更新日、記号）
• Azure OpenAI に送った指示と、返ってきたJSONの全文
• 引用の照合の結果（一致・不一致）
• 指摘の一覧と、それぞれが解消された日
• 人が直した箇所（どの項目を、どう直したか）
• 提出した8Dレポートの最終版と、顧客からの差し戻しの内容

Responses API の応答は、既定で30日間保持されます。 保存された応答はIDで削除できます。控えは自社の SharePoint に残し、サービスの側に置いたままにしない運用にします。

最後の行が、記載ルールを育てる材料です。 顧客の差し戻しの指摘を、次の案件の点検の観点に加えていきます。