製薬会社のくすり相談窓口が受けた電話の記録から副作用に当たりうるものを安全性の報告の項目に整理し、欠けた情報と報告期限の区分の候補を担当者に渡す

処理の起点を決める

「副作用の可能性あり」の印が付いた応対記録の保存を起点にします。 相談員が記録を保存すると、問い合わせ管理システムが Azure Functions に通知します。1日1回のまとめ処理にはしません。 期限は会社が知った日から数えるので、まとめて処理すると、その分だけ担当者の持ち時間が減ります。

追記も起点にします。 追加の聞き取りの結果を相談員が記録に追記したときも、同じ記録をもう一度処理します。2回目以降は、前回の出力との差分を担当者に示します。 追加の情報で重篤に変わったときは、その追記の日時が新しい起点の候補になるためです。

印の付け忘れに備え、印の無い記録も夜間に軽く見ます。 症状を表す語（発疹、かゆみ、めまい、入院など）を含むのに印が無い記録を一覧にし、翌朝に相談窓口のリーダーが印を付けるかを決めます。 この一覧の作成は語の照合で行い、生成AIは使いません。

入力データを集める

質を決めるのは、いちばん下の聞き取りの項目表です。 相談員が「聞いたが不明」を「不明（本人覚えていない）」のように書く決まりがあれば、AIはそれを「相手が知らない」に区分できます。決まりが無いと、「不明」が聞き漏らしなのか答えなのかを記録から判断できません。 導入の前に、項目表に書き方の決まりを足します。

製品の一覧は、被疑薬の名前を正すために渡します。 患者は「白い丸い薬」「血圧の薬」のように話します。AIには一覧にある名前だけを製品名として返させ、一覧に当てはまらない言い方は、そのままの言葉で別の欄に残させます。

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

応対記録と受付の日時は、問い合わせ管理システムの API で、記録の番号を指定して取ります。受付の日時は、AIには渡しません。 期限の計算は Azure Functions が受付の日時から行い、AIの出力とは混ぜません。

添付文書の使用上の注意は、この段階では渡しません。 予測できるかどうかの判断は担当者が行うもので、AIに添付文書を渡すと、予測性の結論を書き始めます。 担当者の確認の画面に、被疑薬の添付文書へのリンクを出すところまでにします。

AIへ渡す前に整形する

1. 相談員の定型の文を外す … 「お電話ありがとうございました」のような記録の定型の書き出しと締めを外します
2. 連絡先を伏せる … 電話番号・住所・メールアドレスを [連絡先] に置き換えます。連絡先は安全性の項目に要りますが、AIには渡さず、問い合わせ管理システムから担当者の画面に直接出します
3. 氏名をイニシャルにする … 患者と報告者の氏名を、記録の選択欄からイニシャルに置き換えます。識別可能な患者の条件はイニシャルや年齢でも満たせるので、氏名そのものは渡しません
4. 文に番号を振る … 記録を文ごとに s01 からの番号で区切ります。根拠の照合を番号で行うためです
5. 追記を区切る … 追記の部分に、追記の日時の印を付けます。どの情報がいつ得られたかを、出力の根拠から追えるようにします
6. 長さを確かめる … 記録が極端に長いものは、会話の要点のまとめが先頭にあるかを確かめ、無ければ相談員に戻します

2番目と3番目は、外部の処理に渡す情報を減らすためです。 健康の情報と結び付いた氏名や連絡先は、AIの処理に要らないので、そもそも渡しません。 識別に要る最小限（イニシャル、年齢、性別、相手の区分）だけを残します。

AIに処理させる

させるのは、記録に書かれたことを項目に移し、根拠の文の番号を付け、欠けた項目に理由の区分を付けることだけです。

欠けたときの区分は3つです。 not_asked は記録に聞いた跡が無いもの、unknown_to_caller は「覚えていない」「分からない」と相手が答えたもの、unclear は書かれているが読み取れないものです。追加の聞き取りの依頼に載せるのは not_asked だけです。

重篤性の手がかりは、判定ではなく引用です。 医薬品医療機器等法施行規則は、15日以内の報告の対象として、死亡、障害、死亡や障害につながるおそれのある症例、治療のための入院や入院期間の延長、それらに準じて重篤な症例、後世代の先天性の疾病や異常を挙げています。AIはこれらに触れた文を拾って並べるだけで、重篤かどうかは書きません。

4行目がいちばん起きやすい失敗です。 「先週の月曜くらいから」を、受付の日から逆算して日付にしてしまいます。話された言葉のまま onset_text に写させ、日付にするかどうかは担当者が決めます。

指示内容を固定する

あなたは製薬会社の安全管理部で、相談窓口の応対記録を
安全性の情報の項目に整理する作業を手伝う立場です。
記録に書かれていることだけを項目に移してください。推測で埋めないでください。

【応対記録】{record}
（s番号付きの文。[追記 日時] の印から後は、後から追記された部分です）

【自社の製品の一覧】{products}
【相談員の聞き取りの項目表と、書き方の決まり】{interview_rules}

【欠けた項目の区分】
- not_asked .......... 記録に、その項目を聞いた跡が無い
- unknown_to_caller .. 相手が「覚えていない」「分からない」と答えた記録がある
- unclear ............ 書かれているが、値として読み取れない
迷ったときは not_asked を選ばないでください。迷ったら unclear です。

【厳守事項】
- 各項目には、根拠にした文の s番号を必ず付けてください。
- 症状は、話された言葉のまま写してください。医学用語に置き換えないでください。
- 発現日・使い始めた日は、記録の言葉のまま写してください。
  「1週間前」「先月」を日付に直さないでください。
- 製品名は、一覧にある名前に当てはまるときだけ product に入れてください。
  当てはまらない言い方は、spoken_name にそのまま写してください。
- 入院・入院の延長・死亡・障害・命に関わる状態・生まれた子の異常に
  触れた文があれば、seriousness_clues にすべて写してください。
  重篤かどうかは書かないでください。
- 副作用かどうか、添付文書から予測できるかどうか、報告が要るかどうかは
  書かないでください。
- 記録が副作用の話を含まないと判断した場合は、
  項目を埋めず、no_event_reason に理由を1文で書いてください。

「迷ったら unclear」は、聞き取りの依頼を絞るためです。 not_asked は相談員に折り返しを頼む区分なので、迷ったものまで入れると、患者に同じことを聞く電話が増えます。 unclear は担当者が記録を読んで決めます。

「医学用語に置き換えない」も明記します。 患者が「顔が赤くなってほてった」と話したものを、AIは「紅潮」や特定の病名に言い換えがちです。用語への置き換え（コーディング）は担当者が評価のときに行います。 言い換えた時点で、話された内容の幅が消えます。

出力形式を固定する

次の形の JSON を、構造化出力で受け取ります。

{
  "record_id": "",
  "has_event": true,
  "no_event_reason": "",
  "patient": { "age_text": "", "sex": "male | female | not_stated", "initials": "", "pregnant": "yes | no | not_stated", "src": ["s03"] },
  "reporter": { "caller_type": "patient | family | pharmacist | physician | nurse | other", "src": ["s01"] },
  "suspect_drugs": [
    { "product": "", "spoken_name": "", "dose_text": "", "start_text": "", "stop_text": "", "lot": "", "src": ["s05"] }
  ],
  "events": [
    { "symptom_text": "", "onset_text": "", "course_text": "", "outcome": "recovered | recovering | not_recovered | unknown | not_stated", "src": ["s07"] }
  ],
  "seriousness_clues": [ { "text": "", "src": "s11" } ],
  "missing": [
    { "field": "", "reason": "not_asked | unknown_to_caller | unclear", "src": [] }
  ]
}

1つ目の理由は、最低限の4つがそろったかを機械的に見られることです。 events に1件以上、suspect_drugs の product か spoken_name に1件以上、patient に年齢・性別・イニシャルのどれか、reporter の caller_type があるかを Azure Functions が確かめます。そろわないものは「報告の基準を満たす前」の印を付け、missing の聞き取りを急ぎます。

2つ目は、期限の区分の候補を規則で出せることです。 AIの出力そのものには区分を書かせません。

期限日の計算は、受付の日時から行います。 施行規則の期間は、会社が事象を知ったときから数えるものです。ICH E2D(R1) でも、会社の担当者（委託先を含む）が最低限の基準を満たす情報を得た日を起点とする考え方が示されています。 追記で重篤の手がかりが新しく出たときは、追記の日時を新しい起点の候補として担当者に示します。

3つ目は、スキーマの制約を前提に後段で確かめられることです。 構造化出力では、すべてのフィールドを必須にし、additionalProperties: false を設定します。配列の minItems などは使えないため、src が空でないかは受け取った後にプログラムで確かめ、空なら担当者の画面で印を付けます。

システムへ連携する

相談員への依頼は、担当者が送ります。 依頼の下書きは自動で作りますが、送るかどうかは担当者が確かめてから決めます。 患者に再び電話をかけるかどうかは、相手の状況を見て決めることだからです。ただし、最低限の4つがそろっていないものは、確認の画面の一番上に出します。

Chat Completions API を使い、Responses API の会話の履歴の保存は使いません。 1件ずつ抜き出して終わる処理で、健康の情報をサービスの中に残す場所を増やす必要がないからです。

人が確認する

AIの下書きは、全件を担当者が確かめます。 安全性の情報に入る値は、どれも報告の内容になりうるからです。

1. 最低限の4つがそろっていないものを先に見る … missing の聞き取りの依頼を確かめて相談員へ送ります
2. 重篤性の手がかりを読む … 根拠の文を記録で確かめ、手がかりが拾い漏れていないかも記録の全文で見ます
3. 被疑薬を確かめる … spoken_name だけのものは、製品を特定できるかを担当者が決めます
4. 項目を管理システムに登録する … 確かめた値だけを登録します
5. 評価する … 重篤性・予測性・因果関係を評価し、期限の区分を確定させます

2番目で記録の全文を見るのは、拾い漏れが期限に直結するからです。 入院の一言をAIが拾わなかったとき、それに気づけるのは記録を読む担当者だけです。AIの手がかりは「ここは必ず見る」という印で、「ここ以外は見なくてよい」という意味ではありません。

目標は、1件7分です。 転記と探す作業が無くなり、確かめて登録する時間が残ります。7分を大きく超える月は、相談員の記録の書き方の決まりが守られていないか、unclear が多すぎます。

例外に対処する

下から2行目が、期限を守るための決まりです。 AIが止まっても、期限は止まりません。未処理の一覧を、担当者が毎朝見る画面の一番上に置きます。

記録を残す

• 入力した記録（伏せ字の後の本文）と、受付の日時・追記の日時
• AIに渡した製品の一覧と聞き取りの項目表の版、指示文の版
• AIの出力の JSON 全文と、照合で空にした項目の記録
• 規則が出した期限の区分の候補と、計算した期限日
• 担当者が直した項目と、確定させた評価・期限の区分
• 相談員への聞き取りの依頼と、その結果の追記
• missing の区分ごとの件数（相談員ごと）

最後の行は、相談員の聞き取りを良くする材料です。 not_asked が多い相談員には、聞き取りの項目表の使い方を伝えます。記録の質が上がれば、AIの抜き出しも、担当者の確認も速くなります。