工場の不具合報告書を読み、事実・推定・対策が混ざった記述を分けて書き直し案を作り、足りない情報を報告者への質問にする

処理の起点を決める

フォームの送信を起点にします。 報告者が送信した瞬間に処理が動き、数分以内に書き直し案と質問が報告者へ届きます。報告者がまだ現場にいるうちに質問が届くことが、この構成でいちばん効くところです。

夜勤の報告も同じように動きます。夜勤の作業者が帰る前に質問が届けば、その場で答えてもらえます。 1日1回まとめて処理する形にすると、翌朝には報告者が帰っていて、聞き直しの往復が今と変わりません。

同じ報告者が数分のうちに2回送信したときは、後のほうを訂正として扱い、前の結果を「取り下げ」にします。 書き直して出し直す人が多いためです。

入力データを集める

質を決めるのは、台帳の項目の定義です。 「検出工程」「発生工程」「流出の有無」のような項目が何を指すかを書いておかないと、AIは一般的な意味で解釈し、工場の使い方とずれた質問を作ります。 定義は、今の台帳の記入例から作れます。

言葉の一覧には、品質管理課が書き直している言葉を集めます。 「不注意」「うっかり」「確認不足」「ちゃんと」「いつもより多め」。人を責める言葉と、量や程度があいまいな言葉の2種類に分けて並べます。

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

報告はフォームの送信イベントから受け取ります。品番一覧は、毎朝生産管理システムから書き出したものをスプレッドシートに置いておき、そこを読みます。

品番一覧は毎朝の書き出しなので、その日に切り替わった新しい品番は載っていないことがあります。 照合で見つからなかった品番は、すぐに打ち間違いとは決めず、「品番の確認」の質問にとどめます。 報告者が正しいと答えたら、品質管理課が品番一覧の更新を待って台帳に登録します。

同じ品番の直近の報告は、AIには渡しません。 渡すと、AIは過去の原因を今回の報告に当てはめて推定を書き足します。今回の報告に書かれていることだけを整理させ、過去との関係は品質管理課が見ます。 一覧には「同じ品番で直近30日に3件」のような印だけを付けます。

AIへ渡す前に整形する

1. 品番の照合 … フォームに書かれた品番が品番一覧にあるかを確かめます。無ければ「品番の確認」を質問に入れます
2. 発生日時の確認 … 空欄か、送信日時より後の日時なら「発生日時の確認」を質問に入れます
3. 本文の長さの確認 … 数文字しか書かれていないもの（「外径NG」だけなど）は、AIに渡さず、決まった質問の一式を返します
4. 文の区切り … 本文を句点と改行で文に区切り、番号を振ります。1つの文が長すぎるものは、そのまま1文として渡します
5. 個人名の扱い … 本文に書かれた作業者の名前は「作業者A」のような記号にしてから渡します

1番目から3番目をAIにさせないのは、規則で確実に見られるからです。 品番が一覧にあるかは照合で分かり、日付の前後は比較で分かります。AIには、文を読まなければ分からない「何が事実で何が推定か」だけを渡します。

5番目は、報告の目的に合わせるためです。 不具合の報告で大事なのは、誰がやったかではなく、何が起きたかです。名前を記号にしておくと、AIの書き直し案にも名前が出ず、人を責める読み方になりにくくなります。 台帳には、品質管理課が必要と判断した範囲で担当の工程を記録します。

AIに処理させる

させるのは、4つのことだけです。

いちばん大事なのは、1つ目の「文を分けて分類する」です。 「作業者の確認不足により外径不良が5個発生したため全数検査を実施した」は、「外径不良が5個見つかった」（事実）、「作業者の確認不足による」（推定）、「全数検査を実施した」（対策）の3つに分けます。分けた結果を報告者が見て、「確認不足」が自分の推測だったと気づくことが、この構成の狙いです。

1行目がいちばん起きやすい失敗です。 外径不良と書かれていると、AIは「刃物の摩耗」「材料のばらつき」と原因の候補を挙げたがります。それが書き直し案に入ると、報告者が書いていない推定が報告に載ります。

指示内容を固定する

あなたは工場の品質管理課で、現場から届いた不具合報告を受理できる形に整える担当です。
報告に書かれていることだけを扱ってください。書かれていないことを補わないでください。

【1. 文の分類】
番号付きの文を、次の4つに分けてください。
- fact ...... 見た・測った・数えた・起きたこと
- estimate .. 原因の見立て（「〜により」「〜のため」「たぶん」「思われる」）
- action .... 実施した処置、これから行う処置
- opinion ... 感想、人への評価
1つの文に複数が含まれるときは、文を分けて、それぞれを分類してください。
分けたあとの文は、元の文の言葉をできるだけそのまま使ってください。

【2. 書き直し案】
台帳の項目の定義に沿って、分類した文を並べ直してください。
- 推定は「推定原因（報告者の見立て）」の欄にだけ入れてください。
- 書かれていない項目は空欄にしてください。

【3. 質問】
空欄の項目と、「くらい」「多め」「何個か」のような量や程度のあいまいな記述について、
報告者に聞く質問を作ってください。
- 1件につき5問まで。答えやすい順に並べてください。
- はい／いいえ か、数字で答えられる聞き方にしてください。
- 人を責める聞き方（「なぜ確認しなかったのか」など）をしないでください。

【4. 言葉の指摘】
言葉の一覧にある語と、それに近い語だけを指摘し、言い換えの例を1つ出してください。

【厳守事項】
- 原因の候補を挙げたり、書き足したりしないでください。
- 数量・日時・品番を推測で補わないでください。
- 処置が正しいか、重大かどうか、出荷してよいかは書かないでください。
- 迷ったときは、fact ではなく estimate を選んでください。

【台帳の項目の定義】{ledger_fields}
【言葉の一覧】{word_list}
【報告の項目】{form_fields}
【報告の本文（文番号付き）】{report_sentences}

「迷ったら estimate」は、分類の誤り方を片側に寄せるための指示です。 推定を事実に入れる誤りは原因分析を誤らせますが、事実を推定に入れる誤りは報告者が確かめれば直ります。どちらかに誤るなら、害の小さいほうに誤らせます。

「元の文の言葉をできるだけそのまま」も大事です。 書き直し案が整った文章になりすぎると、報告者は自分の報告だと思えず、確かめずに承認します。報告者が自分の言葉を見つけられる程度に、言い換えを抑えます。

出力形式を固定する

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

{
  "report_id": "",
  "sentences": [
    { "source_no": 1, "text": "", "class": "fact | estimate | action | opinion" }
  ],
  "rewrite": {
    "occurred_at": "", "process": "", "part_no": "", "phenomenon": "",
    "quantity": "", "detection": "", "containment": "", "estimated_cause": ""
  },
  "questions": [
    { "field": "", "question": "", "answer_type": "yes_no | number | text" }
  ],
  "word_flags": [
    { "source_no": 1, "word": "", "type": "blame | vague", "suggestion": "" }
  ]
}

1つ目の理由は、分類を数えられることです。 class は4つの値に限っているので、報告ごとに事実と推定の割合が出せます。推定の割合が高い報告が続く工程は、書き方を一緒に見直す相手になります。

2つ目は、source_no で元の文に戻れることです。 分けた文がどの文から来たかが番号で分かるので、報告者も品質管理課も、元の報告と並べて確かめられます。 元の番号が無い文が sentences に入っていたら、AIが書き足した文として一覧で目立たせます。

3つ目は、questions をそのままメールに流し込めることです。 報告者へのメールには、質問を番号付きで並べ、答えをそのまま返信すれば品質管理課の一覧に入るようにします。

answer_type を持たせるのは、答えやすさのためです。 yes_no と number の質問は、返信で「1 はい」「2 12個」のように番号と答えだけを書けば済むようにします。文で答える質問が多いと、夜勤明けの作業者は返信を後回しにします。 文で答える質問は1件につき2問までに抑えるよう、指示の側で決めておきます。

システムへ連携する

台帳へは書き込みません。 台帳は工場の品質の記録で、AIの書き直し案がそのまま入ると、確かめていない分類が記録になります。 品質管理課が確かめた内容だけを、人が登録します。

確認待ちの一覧は、状態を持たせます。 「質問中」「回答あり」「受理」「取り下げ」の4つで、質問中のまま2日たったものは品質管理課に知らせます。

人が確認する

書き直し案は、報告者と品質管理課の2段で確かめます。

1. 報告者が事実の欄を確かめる … 自分が見たこと・数えたことと合っているかを見ます。違っていれば返信で直します
2. 報告者が質問に答える … 数字で答えられるものは数字で答えます。分からないものは「分からない」と答えます
3. 品質管理課が分け方を確かめる … 推定が事実の欄に入っていないか、AIが書き足した文が無いかを見ます
4. 品質管理課が台帳に登録する … 確かめた書き直し案を台帳の書式で登録します

3番目で見るのは、source_no の無い文と estimate の扱いです。 書き足された文が無いことと、推定が推定の欄にだけあることを確かめれば、報告の中身の正しさは報告者が確かめているので、品質管理課の確認は数分で終わります。

品質管理課が分け方を直したときは、直した理由を一言残します。 「『〜と思われる』が付いていないが、測っていないので推定」のような理由がたまると、次の指示の改善と、報告者への説明の両方に使えます。 報告者には、直した結果を受理の通知と一緒に返し、自分の報告がどう分けられたかを見てもらいます。

重大な不具合は、この流れを待ちません。 流出の疑いがある、安全に関わる、といった報告は、今までどおり報告者がすぐ電話で品質管理課に伝えます。 この構成は、受理の書類を整えるためのもので、初動の連絡の代わりにはしません。

例外に対処する

報告者の返信が質問の番号に沿っていないこともあります。 「全部で10個くらいで、たぶん朝からです」のような返信は、AIに番号との対応付けをさせず、品質管理課が読んで反映します。 返信の読み取りまで自動にすると、あいまいな答えが確かな数字として書き直し案に入るからです。番号と答えだけの返信は、プログラムが該当の欄に入れ、「回答あり」の状態にします。

「AIが書き足した文」を見つける仕組みは必ず作ります。 番号の無い文は、元の報告に無かった文です。この1行の検査で、原因の書き足しのほとんどを止められます。

記録を残す

• 元の報告（フォームの送信内容）
• Claude API に送った内容と、返ってきたJSON
• 報告者の回答と、事実の欄への直し
• 品質管理課が直した分け方（どの文の分類をどう変えたか）
• 台帳に登録した日時と登録者
• 使った言葉の一覧と台帳の項目の定義の版

4つ目は、指示を直す材料です。 品質管理課が fact を estimate に直すことが多い言い回しがあれば、指示に例として足します。直しの記録が、そのまま分類の基準になっていきます。

ログは確認待ちの一覧と同じスプレッドシートの別のシートに、報告番号で並べて残します。 送った内容と返ってきたJSONを1行ずつ持っておくと、指示を直したときに、同じ報告を新しい指示で分け直して、分け方がどう変わったかを比べられます。

元の報告は消しません。 台帳に載るのは書き直した報告ですが、原因分析で「最初に何と書かれていたか」を見たくなることがあります。 元の報告と書き直しを並べて見られるようにしておきます。