製薬会社の安全性部門で、毎週の文献検索で集まった論文の要旨から自社製品の有害事象の報告に当たりうるものを一次判定し、担当者の確認に回す

処理の起点を決める

毎週月曜の早朝に定時で動かします。 いまの運用と同じ曜日にそろえるのは、週の区切りを変えると、どの週にどの文献を見たかの記録が前後でずれるからです。

早朝に動かすのには、もう一つ理由があります。 NLM の説明では、大きな処理は週末か、平日の米国東部時間の午後9時から午前5時に限るよう求められています。日本時間の月曜の早朝は、米国東部時間では日曜にあたります。 40成分の検索をまとめて回しても、この求めに沿います。

国内の文献データベースは、契約の範囲で書き出したファイルを担当者が所定のフォルダに置き、置かれたことをきっかけに同じ処理に流します。 自動でログインして取りに行く形にはしません。データベースの利用規約で認められているかを確かめないまま、自動の取得を組まないためです。

入力データを集める

質を決めるのは、成分の別名の辞書です。 (d)のように、要旨には一般名・略号・海外の販売名が混ざります。辞書に無い書き方の成分は、AIにも見つけにくくなります。 新しい販売名や略号を見つけたら、そのつど辞書に足します。

判定の規則は、手順書をそのまま渡すのではなく、条件の表に書き直します。 手順書の文章をAIに解釈させると、担当者ごとの読み方の違いが、そのままAIの揺れになります。

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

PubMed は、成分ごとの検索式で ESearch を呼んで文献の番号を取り、その番号で EFetch を呼んで要旨を取ります。

日付の範囲は、NLM の説明に沿って指定します。 datetype で日付の種類を選び、PubMed では crdt・edat・pdat・mhda が指定できるとされています。範囲を指定するには mindate と maxdate の両方が必要とされ、形式は YYYY/MM/DD などです。範囲は前週より数日広く取り、重なった分は文献の番号で除きます。 範囲をぴったり1週間にすると、登録のタイミングのずれで抜ける文献が出ます。

成分ごとの要求は、次のような形になります（検索式と日付は例です）。

ESearch:
https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi
  ?db=pubmed&term=<成分ごとの検索式>
  &datetype=edat&mindate=2026/10/02&maxdate=2026/10/12
  &retmax=1000&tool=<自社のツール名>&email=<部門の連絡先>

EFetch:
https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi
  ?db=pubmed&id=<ESearchで得た番号をカンマ区切り>
  &retmode=text&rettype=abstract&tool=<同上>&email=<同上>

検索式そのものは、いまの運用で使っているものをそのまま移します。 検索式を変えると、変える前と後で拾える文献が変わり、どちらが正しいかを確かめる手間が増えます。

要旨の取り方は、公式の例では retmode=text と rettype=abstract を指定しています。 1回の要求で取れる件数にも上限があり、ESummary と EFetch の retmax は最大10,000件とされています。1週間の件数はこれを大きく下回りますが、成分ごとに分けて呼びます。

要求の頻度は、1秒あたり3回を超えないよう求められています。 40成分を続けて呼ぶので、要求の間に待ちを入れます。tool と email のパラメーターも付けます。 すべての E-utilities の URL で使用が推奨されているとされ、問題があったときに NLM から連絡を受けられます。

AIへ渡す前に整形する

1. 重複の除去 … 文献の番号で、前週までに判定したものと同じ週の重複を除きます
2. PubMed と国内データベースの重複 … 同じ論文が両方に出ることがあるので、題名と雑誌と巻号で束ねます
3. 成分の印 … 別名の辞書で要旨の中の成分の記載を探し、［成分：一般名］ の形で印を付けます
4. 要旨の無い文献 … 要旨の無いものは判定せず、題名だけで「全文が要る」か「関係ない」を担当者が決める一覧へ回します
5. 言語の確認 … 英語・日本語以外の要旨は、AIの判定に回したうえで「言語」の印を付け、担当者が必ず読む扱いにします
6. 撤回された論文 … 撤回の告知とその元の論文は、判定とは別に担当者へ知らせます

3番目を前処理で行うのは、成分の見落としをAIの読みに任せないためです。 辞書で印が付いた要旨は、成分の記載が「ある」ことが機械的に確定します。AIには、その成分と事象が結びついて書かれているかを判定させます。

4番目も大事です。 症例報告は短く、要旨が付いていないこともあります。要旨が無いことを理由に「関係ない」へ入れないでください。

AIに処理させる

させるのは、要旨に書かれていることを項目ごとに判定し、根拠の文をそのまま写すことです。

下の2行は、評価ではなく「先に読む」ための印です。 重篤かどうか、報告の区分がどれかは担当者が全文を読んで決めます。AIが付けるのは、その語が要旨に書かれているかどうかだけです。

指示内容を固定する

あなたは製薬会社の安全性部門で、文献の要旨を一次判定する担当です。
渡された要旨に書かれていることだけで判定してください。推測で補わないでください。

【判定する項目】
1. drug_role：印の付いた成分が、投与された薬として書かれているか
   （administered ／ comparator_only ／ not_found）
2. patient：個々の患者の記載があるか（individual ／ population ／ none）
3. event_link：成分の投与と結びついた有害事象の記載があるか（yes ／ no ／ unclear）
4. safety_result：安全性に関わる研究結果があるか（yes ／ efficacy_only ／ none）
5. serious_terms：死亡、入院、障害、生命を脅かす、先天異常にあたる語を列挙
6. special_population：妊娠、授乳、小児の語を列挙

【厳守事項】
- 各項目に evidence として、根拠にした文を要旨から一字一句そのまま写してください。
  写せる文が無い項目は、evidence を空にしてください。
- 迷ったときは unclear を選んでください。no や none を選ばないでください。
- 「関係ない」と言える根拠が要旨に無いときに、none にしないでください。
- 報告に当たるか、重篤か、予測できるか、因果関係があるかは書かないでください。
- 要旨に無い患者の数、年齢、事象を補わないでください。
- 成分名は、印の付いた一般名で書いてください。別の成分と取り違えないでください。
- not_relevant_reason には、関係ないと考える理由を、要旨の文を引いて書いてください。

【成分の印が付いた要旨】{abstract}
【書誌】{bibliographic}

「迷ったら unclear」を明記しないと、モデルは no を選びがちです。 要旨の多くは有効性の研究で、事象の記載がはっきりしないものを「無い」と読むほうが自然だからです。この業務で高くつくのは拾い過ぎではなく、取りこぼしです。 指示の側で、取りこぼしの方向に倒れないようにします。

not_relevant_reason に要旨の文を引かせるのは、(c)の対策です。 担当者が「関係ない」の一覧を流し読みするとき、理由と根拠の文が並んでいれば、1件数秒で確かめられます。

出力形式を固定する

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

{
  "article_id": "",
  "source": "pubmed | domestic_db",
  "ingredient": "",
  "drug_role": "administered | comparator_only | not_found",
  "patient": "individual | population | none",
  "event_link": "yes | no | unclear",
  "safety_result": "yes | efficacy_only | none",
  "serious_terms": [],
  "special_population": [],
  "evidence": [
    { "item": "", "quote": "" }
  ],
  "not_relevant_reason": ""
}

振り分けは、この出力から規則で決めます。

1つ目の理由は、判定と振り分けを別の層に置けることです。 手順書の条件が変わっても、AIへの指示はそのままで規則の表だけを直します。

2つ目は、「関係ない」の条件を狭く書けることです。 成分が投与の薬として出てこないものだけを「関係ない」にし、それ以外はすべて人が読む側に残ります。

構造化出力では、すべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定する必要があるとされています。 列挙した語が無いときは空の配列で返させます。配列の要素数の上限（maxItems）は使えないとされているので、根拠の数はプログラムの側で確かめます。

システムへ連携する

照合は Azure Functions で行います。 quote が要旨の本文にそのまま無ければ、その項目の判定を unclear に置き換え、振り分けを「全文が要る」に寄せます。 根拠の無い判定を、そのまま「関係ない」の理由に使わないためです。

人が確認する

人が読む順番は、先頭に並んだものからです。

1. 重篤を示す語・妊娠・小児の印があるもの … どの振り分けでも先に読み、取り寄せを決めます
2. 症例の候補 … 要旨と根拠の文を読み、全文を取り寄せます
3. 全文が要るもの … 要旨で判断できるものは振り分けを直し、できないものは取り寄せます
4. 研究結果の候補 … 研究報告として扱うかを、手順書に沿って判断します
5. 関係ない … 理由と根拠の文を一覧で流し読みし、引き上げるものを選びます

5番目は全件に目を通します。 1件ずつ要旨を読み直すのではなく、理由と根拠の文を読み、理由が要旨と合っていないものだけを開きます。

判定を覆したら記録します。 どの項目を、どちらに変えたかを残し、AIが「関係ない」としたものを担当者が引き上げた件数を、毎週数えます。 これが、この構成の取りこぼしの目安になります。

目標は、1,200件をならして1件2分です。 症例の候補と全文が要るものは数分かかり、「関係ない」の一覧は数秒で済みます。

例外に対処する

最後の行は、期限に関わるので止まり方を決めておきます。 判定が終わらないまま週の半ばになるくらいなら、担当者がいまの手順で読み始めるほうが安全です。 「AIの判定待ち」で読む作業が止まる状態を作らないでください。

記録を残す

• 検索した日時、成分ごとの検索式、日付の範囲、取れた文献の番号の一覧
• 要旨の本文と書誌（そのとき取ったもの）
• AIの判定の全文（JSON）と、根拠の照合の結果
• 規則で決めた振り分けと、そのときの規則の版
• 担当者が判定を覆した記録 … どの文献の、どの項目を、どう変えたか
• 取り寄せを依頼した日時と、全文が届いた日時

検索式と日付の範囲を残すのは、「その週に何を検索したか」を後から示すためです。 監査や点検で、ある文献をいつ知り得たかを問われたときに、検索した日と判定した日と取り寄せた日がつながっている必要があります。

規則の版を残すのは、手順書が改訂されたときのためです。 振り分けの条件が変わると、過去の「関係ない」の意味が変わります。