製品ごとのクレーム・問い合わせの件数を毎日見て、いつもより増えている製品と現象を見つけ、品質管理に初動の調査を依頼する

処理の起点を決める

毎朝6時の定時実行を起点にします。 市場品質課が始業した時点で、前日までの件数で判定した警報の一覧がそろっているようにします。判定に使うのは「前日までに受け付けた記録」で、当日の途中の件数は入れません。 途中の件数を入れると、午前と午後で同じ組み合わせの判定が変わり、どの時点の結果で依頼したかが分からなくなります。

安全に関わる現象だけは、別に1時間ごとに見ます。 発煙・発火・異臭・けがの語を含む記録が入ったら、統計の判定を待たずに市場品質課へ知らせます。朝6時まで待ってよい現象と、待ってはいけない現象を、トリガーの段で分けます。 月曜日の朝に読む土日の記録は、日別に分けたまま数えます。

入力データを集める

質を決めるのは、3行目の現象の区分表です。 区分が粗すぎると、違う現象が1つにまとまって増え方が薄まります。細かすぎると、同じ現象が2つに割れて、どちらも「多い」に届きません。最初は20前後の区分で始め、含める例・含めない例を1つずつ書きます。 「電源が入らない」と「途中で電源が切れる」を分けるか、といった線引きを、ここで決めます。

4行目の対応表で、「ABC-100」「ABC100」「ABC-100W（色違い）」のような派生型式を1つにまとめます。 まとめないと、件数が割れて増え方が見えません。

5行目の出荷実績で、売れ筋ほど多く見える問題（第3章の（c））を補正します。 発売直後の型式は、使われている台数が月ごとに増えるので、不具合の割合が同じでも件数が増えます。その増え方を警報にしないために、普段の水準を出荷の累計に合わせて伸ばします。

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

問い合わせ管理システムから、前日に受け付けた記録をCSVで書き出し、Python の pandas で読み込みます。書き出しは問い合わせ管理システムの定時出力の機能か、API の提供があればそれを使います。

普段の水準は、直近の件数を含めずに出します。 pandas の rolling は closed='left' で窓の最後の点を除けますが、除きたいのは3日分なので、shift(3) でずらしてから窓を取ります。 判定する3日間を窓に入れると、増えた件数が普段の水準を押し上げ、増え方が自分で自分を打ち消します。

AIへ渡す前に整形する

1. 型式の名寄せ … 表記の揺れ（ハイフン、全角半角、色違いの記号）を型式の一覧で正規の型式にそろえます。一覧に無い型式は「型式不明」として残し、件数には入れません
2. 重複の除外 … 同じお客様の同じ製品について、1件目の受付から再度の連絡が入ったものは、1件として数えます。 製造番号と電話番号の組み合わせ（ハッシュ化したもの）で結び付けます
3. 不具合以外の除外 … 使い方の質問、在庫の問い合わせ、配送の苦情は外します。ここは相談室の区分ではなく、次の現象の区分で決めます
4. 現象の区分 … Claude API が内容の文を読み、区分表から1つ選びます（次の小見出し）
5. 日別の件数 … 型式×現象×受付日で数えます。件数0の日も行として作ります。 0の日が無いと、普段の水準が高く出ます
6. 普段の水準 … 直近3日を除いた過去56日の1日あたりの平均を出し、出荷の累計の伸びで補正します
7. 新しい型式の扱い … 発売から56日に満たない型式は、普段の水準を同じ系列の旧型式の値から借ります。借りる先が無いものは、最小の水準（1日0.1件）を置きます

5番目を省くと、判定のすべてがずれます。 pandas で型式×現象×日を数えると、件数のあった日しか行ができません。全部の日付を並べた表に0で埋めてから平均を取ります。 7番目の0.1件は本記事のモデル条件で、実際は過去の記録から決めます。

AIに処理させる

この構成の「AI」は、3つの部品に分かれます。 多いかどうかを確率で決めるのは SciPy の計算、偶然の警報を抑えるのも SciPy の補正、文を読むのが生成AIです。生成AIは件数も確率も扱いません。

判定の条件は3つを重ねます。 補正後の確率（q値）が0.05未満、直近3日の件数が3件以上、普段の水準の2倍以上。3つ目と2つ目を足すのは、件数の多い組み合わせで「わずかに多いだけ」が統計的に有意になるのを防ぐためです。 1日100件届く型式で105件になっても、品質管理が動く理由にはなりません。

補正は 'bh' で始め、警報が多すぎれば 'by' と比べます。 同じ型式の違う現象どうしは売れ方の影響を一緒に受け、独立ではないからです。

生成AIの2つ目の仕事は、統計では分からないところです。 「異音」が増えていても、中身が「ファンの音」と「扉の音」に分かれていれば1つの不具合ではありません。同じ現象の集まりかを same_phenomenon に返させます。

指示内容を固定する

判定の計算は次のとおりです。 毎朝、全部の組み合わせについて回します。

import pandas as pd
from scipy.stats import poisson, false_discovery_control

# daily: 型式×現象×日の件数（件数0の日も行がある）
daily = daily.sort_values("date")
g = daily.groupby(["model", "phenomenon"])["count"]
# 直近3日を除いた過去56日の平均（shift(3) で判定する3日を窓から外す）
daily["base"] = g.transform(lambda s: s.shift(3).rolling(56, min_periods=28).mean())
daily["base"] = (daily["base"] * daily["shipment_factor"]).clip(lower=0.1)
daily["recent3"] = g.transform(lambda s: s.rolling(3).sum())

today = daily[daily["date"] == target_date].copy()
mu = today["base"] * 3                                # 3日分の期待件数
today["p"] = poisson.sf(today["recent3"] - 1, mu)     # 直近3日の件数以上が届く確率
today["q"] = false_discovery_control(today["p"], method="bh")
today["alert"] = (today["q"] < 0.05) & (today["recent3"] >= 3) \
               & (today["recent3"] >= 2 * mu)

sf(k - 1) にしているのは、「k件以上」の確率が欲しいからです。 sf は「その値より大きい」確率なので、k件ちょうどを含めるには1つ下げて渡します。ここを sf(k) にすると、すべての確率が一段小さく出て、警報が出にくくなります。

現象の区分は、Claude API に次の指示で付けさせます。

あなたは家電メーカーの品質保証部で、お客様相談室の記録に不具合の現象を付ける立場です。
渡された記録の内容の文だけを読み、現象の区分表から1つを選んでください。

【現象の区分表】{phenomenon_table}
（コード、名前、含める例、含めない例、安全に関わるかの印）

【選び方】
- お客様が述べた症状を選んでください。担当者の推測やお客様の推測ではありません。
- 症状が2つ書かれている場合は、最初に起きた症状を選び、もう1つを secondary に書いてください。
- 不具合ではない記録（使い方の質問、在庫、配送、価格）は NOT_DEFECT を選んでください。
- どれにも当てはまらない、または文から読み取れない場合は UNKNOWN を選んでください。
  近いものを無理に選ばないでください。
- 発煙、発火、焦げたにおい、異臭、感電、けがのいずれかが書かれていれば、
  他の症状より優先して、その区分を選んでください。

【厳守事項】
- 区分表に無いコードを作らないでください。
- 原因（部品の故障、使い方の誤り など）を書かないでください。
- evidence には、選んだ根拠の文を記録から1文そのまま写してください。
- お客様の氏名・住所・電話番号が文に含まれていても、出力に写さないでください。

【記録】{record_text}
【型式】{model}

「近いものを無理に選ばない」を明記しないと、新しい現象が既存の区分に薄く散らばります。 UNKNOWN の増加は新しい現象の手がかりなので、型式ごとに数えて判定にかけます。

警報の確認と依頼文は、別の指示で作らせます。

あなたは品質保証部で、件数が増えた製品と現象について、設計・製造の部署に初動の調査を
依頼する文の下書きを書く立場です。

【渡す情報】
- 型式、現象の区分、直近3日の件数、普段の水準、補正後の確率（Python が計算した値）
- 該当する記録（受付番号、受付日、製造番号、購入時期、内容の文）

【させること】
1. 記録が同じ現象の集まりかを same_phenomenon に yes / no / mixed で答えてください。
   mixed の場合は、どう分かれるかを groups に書いてください。
2. 製造番号の範囲、購入時期、使用年数、使用状況に共通点があれば common_points に
   書いてください。記録に書かれていることだけを使ってください。
3. 依頼文の下書きを書いてください。件数と確率は渡された値をそのまま書いてください。

【厳守事項】
- 原因を推定しないでください。「〜の故障と思われる」と書かないでください。
- 共通点が見つからなければ「記録からは共通点を確認できない」と書いてください。
- リコール、出荷停止、お客様への告知の要否を書かないでください。
- 受付番号以外の、お客様を特定できる情報を書かないでください。

「原因を推定しない」は、依頼文の受け手のためです。 「ファンモーターの不良と思われる」と書かれていれば、設計の部署はそこから調べ始めます。

出力形式を固定する

次の形のJSONを、警報1件ごとに作ります。 件数と確率は Python が埋め、same_phenomenon 以下を Claude API の構造化出力（output_config.format に type: "json_schema"）で受け取ります。

{
  "alert_id": "A-20261007-004",
  "model": "ABC-100",
  "phenomenon": "P07 途中で電源が切れる",
  "recent3": 6,
  "expected3": 1.2,
  "q_value": 0.012,
  "rule": "statistical",
  "record_ids": ["Q-1006-0213", "Q-1006-0388"],
  "same_phenomenon": "yes",
  "groups": [],
  "common_points": "製造番号が 2608 から始まる範囲に5件。購入から2か月以内が5件。",
  "request_draft": "",
  "status": "open"
}

1つ目の理由は、計算の値と生成AIの文を別の欄に置けることです。 recent3 expected3 q_value は計算の値で、依頼文にもこの値を差し込みます。生成AIが件数を言い換えて書く余地を残しません。

2つ目は、rule で警報の出どころを分けられることです。 statistical は確率の判定、safety は安全に関わる現象の1件警報です。後から警報の当たり外れを見直すとき、2つは別に数えます。 安全の警報は外れても出すべきもので、確率の警報と同じ基準で評価しません。

構造化出力のスキーマでは minimum maximum などの制約が使えないので、選択肢は enum で縛り、範囲の確認は受け取った後に Python で行います。

システムへ連携する

設計・製造の部署へは、この構成から直接送りません。 依頼するかどうかを決めるのは市場品質課の担当で、送るのも担当です。 警報が外れていたときに、他部署の手を止めることになるからです。

毎朝の一覧は、警報が0件の日も「警報なし、記録は何件」と投稿し、処理の停止と見分けます。

人が確認する

人が開くのは、警報の出た組み合わせだけです。 警報が出ない記録は、現象の区分の一覧を流し見るだけにします。

1. 安全の警報を先に見る … rule が safety のものは、記録の原文を読み、すぐに課長へ上げるかを決めます
2. 確率の警報の記録を読む … same_phenomenon と common_points を参考に、原文で同じ現象かを確かめます
3. 依頼するかを決める … 依頼するものは下書きを直して送ります。見送るものも、理由を一言残します
4. 区分の付け間違いを直す … 直した記録は、区分表の「含める例・含めない例」の見直しに使います

3番目の「見送りの理由」がたまると、判定の条件のどこを直せば外れが減るかが分かります。

目標は、900件をならして1件1分です。

例外に対処する

1行目と5行目は、件数0として判定すると「何も増えていない」という誤った安心が出るので止めます。最後の行は統計では区別できないので、警報は止めずに人が判断します。

記録を残す

• 毎朝の書き出しのファイルと、読み込んだ件数
• 記録ごとの現象の区分、evidence、区分を付けた日時と区分表の版
• 型式×現象×日の件数、普段の水準、出荷の補正の値
• 警報ごとの確率・補正後の確率・判定の条件と、そのときの補正の方法（bh か by か）
• 人の決定（依頼した／見送った）と理由、依頼を送った日時
• 人が区分を直した記録 … どの記録を、どの区分からどの区分へ

区分表の版を残すのは、区分を変えると過去の件数の意味が変わるためです。 「異音」を2つに分けたら、分けた日以前の記録を新しい区分表で付け直します。