【2026年最新】製薬の文献監視をClaude Codeで自動化

導入: 「金曜の夜にPubMedを巡回している自分」を辞めたかった

正直に書きます。製薬企業のメディカルアフェアーズ部門で働く知人と、夜中の23時にメッセンジャーで「来週のMR向け勉強会、まだ資料できてないんだよね」というやり取りをしたことが、この記事を書くきっかけでした。彼/彼女がやっていたのは、PubMed の検索結果を Excel に貼り付けて、Abstract を翻訳して、エビデンスレベルを判定して、社内テンプレートに落とし込む、というほぼ手作業のフローです。「これ、もうしんどい。でもAIに任せるのは怖い」というのが現場の本音でした。

怖がる理由はもっともです。製薬業界における情報の扱いは、他業種よりはるかに厳しい制約があります。GVP(医薬品の製造販売後安全管理基準)・GPSP(製造販売後の調査及び試験の実施の基準)・販売情報提供活動ガイドラインといった枠組みがあり、副作用が示唆される情報を見つけたら所定のフローで報告する義務が発生します。AIに丸投げしたら、見落としが薬害につながる可能性すらある。だから「AI使ってラクしました」では済まない。

ただ、よくよく業務を分解していくと、「文献を集める」「Abstract を要約する」「重要度をスクリーニングする」「人に渡すための整形をする」という一連の作業のうち、判断を伴わない単純作業の比率が想像以上に大きいことがわかります。私が普段、企業のClaude Code導入を伴走していて感じるのは、製薬DXは「全自動」ではなく「人間の判断ポイントを残しつつ、その前後の準備作業を圧縮する」設計が一番フィットするということでした。

この記事では、Claude Code を使って「文献監視」「MR向け学術情報整理」「MSL向けQ&A集構築」という3つの業務を、判断は人間に残しつつ前後工程だけを自動化する形で組み立てるプロンプトと、絶対に避けるべき失敗パターンをまとめました。Claude Code のターミナルで `claude` と叩いた状態から、コピペで動かせる粒度で書いています。

全体像: 文献監視 → 要旨整形 → MR/MSL向け派生資料 までの4レイヤー

製薬企業のメディカルアフェアーズ・MR教育・薬事担当周辺の業務を、Claude Code で扱う前提に整理すると、おおむね以下の4レイヤーに分かれます。

1. 収集レイヤー: PubMed、医中誌(医学中央雑誌)、各種学会ジャーナルのRSS/API、社内文献データベース、薬事日報・ミクスオンラインなどの業界紙RSS。ここは「広く・漏れなく」が原則。
2. スクリーニングレイヤー: 自社薬剤関連キーワード(一般名・販売名・コード名)、競合薬剤、適応疾患、副作用候補語などで該当度を判定。「拾う/拾わない」の一次判断を Claude Code に下書きさせる。
3. 整形レイヤー: Abstract を社内テンプレート(PICO形式、エビデンスレベル、対象集団、主要評価項目、結論、限界点)に落とし込む。日本語で読める形にする。
4. 派生レイヤー: 整形済みデータを起点に、MR向け勉強会資料、MSL向けFAQドラフト、社内安全管理担当への一次共有メモなど、用途別の出力を作る。

このうち、Claude Code の効果が一番大きいのは 整形レイヤーと派生レイヤー です。収集レイヤーは PubMed E-utilities や各DBの公式APIで取ってくる方が確実(後述)で、スクリーニングは「下書きはAI・最終判定は人間」が鉄則。整形以降は「定型作業の高速化」なので、AIの相性が最も良いゾーンになります。

以降の章では、この4レイヤーに対応する形で、実際に動かせるプロンプトと、それを Claude Code でジョブ化するための設計指針を書いていきます。なお、ここで紹介する内容はあくまで一般的な業務フローに基づく汎用例です。実在の薬剤名・論文ID・副作用症例を具体的に持ち出すことは、薬機法・GVP・販売情報提供活動ガイドラインの観点から避け、自社で運用する際は必ず社内の薬事・コンプライアンス部門のレビューを通してください。

レイヤー1: 文献の自動収集ジョブを Claude Code で設計する

まず収集レイヤーから。製薬企業の文献監視で使われる主なソースは以下のとおりです。

• PubMed: 米国国立医学図書館(NLM)が運営する世界最大級の医学文献データベース。E-utilities(eSearch、eFetch、eSummary)というREST APIが公開されており、検索式と日付範囲で結果をXML/JSON取得できます。
• 医中誌Web: 国内医学文献の網羅性が高い。法人契約が必要だが、APIまたは検索エクスポート機能を経由してCSV/Excelで取得することが多い。
• 各学会ジャーナル: 該当領域の主要ジャーナル(循環器・腫瘍・神経・代謝など)はRSSフィードを持っているものが多く、新着論文を機械的に取得できます。
• 業界紙: 薬事日報、ミクスオンライン、PharmaTribuneなどはRSSや有料APIで配信。
• 規制当局情報: PMDAの医薬品医療機器情報、FDAやEMAの安全性情報、厚労省の薬事関連通知など。これらは別建てで監視する必要があります。

Claude Code に直接「PubMedを巡回して」と頼むより、まずはこれらを取得する小さなPythonスクリプトを Claude Code に書かせて、cron や Windowsタスクスケジューラで定期実行させるのが堅実です。以下が、PubMedのE-utilitiesを使った日次収集スクリプトを Claude Code に作らせるためのプロンプトです。

プロンプト1: PubMed日次収集スクリプトの設計

あなたは製薬企業のメディカルアフェアーズ部門で動く社内ツール開発者です。
以下の要件で、PubMed E-utilities を使った日次文献収集スクリプトを Python で作ってください。

【要件】
- 入力: キーワード辞書(JSON) — 自社薬剤の一般名・販売名候補・適応疾患名・主要競合薬一般名を含む
- 出力: 当日新着のPMID、タイトル、Abstract、著者、ジャーナル名、出版日、DOI を含むJSONL
- 期間: 前日0:00 〜 当日0:00 (JST) の publication date でフィルタ
- 検索式: キーワードを (kw1[Title/Abstract] OR kw2[Title/Abstract] ...) で組み立てる
- レート制限: NCBI規定に従い、APIキーなしの場合は3 req/sec、ありの場合は10 req/sec を上限
- リトライ: 5xx と 429 は指数バックオフで最大5回
- 出力先: ./data/pubmed/{YYYY-MM-DD}.jsonl
- 既存ファイルがあれば追記でなく上書き、重複PMIDは除外
- すべての通信エラー・パース失敗は ./logs/pubmed_{YYYY-MM-DD}.log に記録

【コード設計の注意】
- APIキーは環境変数 NCBI_API_KEY から読む
- requests + tenacity + python-dateutil を使う
- argparse でドライランモード(--dry-run)を実装し、検索式と件数だけ出して終了できるようにする
- 主要関数: build_query() / fetch_pmids() / fetch_details() / save_jsonl() に分割

【出力】
コード全体 + 簡単な実行例 + 環境変数の説明 + テスト用ダミーキーワードでの動作確認手順

このプロンプトを Claude Code に投げると、`requests` でE-utilitiesを叩いて、eSearch → eFetch の2段階で取得するスクリプトを書いてくれます。重要なのは 「APIキー」「レート制限」「リトライ」「ログ」 を最初の指示に必ず含めること。これを書き忘れると、Claude Code は手軽に動くコードを優先して、本番運用に耐えない実装を出してくることがあります。

医中誌Web の場合は公開API仕様が公開契約者向けなので、CSVエクスポートを定期的にネットワーク共有フォルダに置き、それを Claude Code で読み込むパターンが現実的です。「医中誌の検索結果CSVを規定フォーマットに正規化するスクリプトを作って」というプロンプトに、CSVのサンプル1行を貼って渡せば、ほぼ一発でパーサが出ます。

レイヤー2: スクリーニングをClaude Codeで「下書き」させる

収集した文献リストに対して、「これは自社にとって重要か」「副作用報告に該当しそうか」「MR教育で扱う価値があるか」を判定する作業を、人間が一件ずつやると気が遠くなります。とはいえ全自動も危険。なので Claude Code には「人間が15秒で判断できるための下書きを作る」役割を任せます。

プロンプト2: 文献スクリーニング下書き(JSONL一括処理)

あなたは製薬企業メディカルアフェアーズ部門のスクリーニング担当補助者です。
以下のJSONL形式の文献データを1件ずつ読み、定義済みカテゴリでタグ付けしてください。
ただし、最終判定は人間が行います。あなたは「人が15秒で判断できる下書き」を作る役割です。

【入力データ形式】
{"pmid": "...", "title": "...", "abstract": "...", "journal": "...", "pubdate": "...", "authors": [...]}

【自社関連キーワード】
- 一般名: {generic_name_1}, {generic_name_2}
- 適応疾患: {disease_1}, {disease_2}
- 競合一般名: {competitor_1}, {competitor_2}
- 副作用候補語: {ae_term_1}, {ae_term_2}, ...

【タグ付けカテゴリ】
- relevance: "high" / "medium" / "low" / "unrelated"
- topic: "efficacy" / "safety" / "pk_pd" / "guideline" / "real_world" / "review" / "other"
- ae_signal: "possible" / "none" / "uncertain" — 副作用報告に該当する可能性が示唆される記述があるか
- mr_use: "training_material" / "competitive_intel" / "background" / "skip"
- msl_use: "kol_briefing" / "faq_seed" / "skip"
- reasoning: 60〜120文字の日本語で、判定根拠を簡潔に

【出力ルール】
- 元データに上記タグを足したJSONLを返す
- ae_signal が "possible" または "uncertain" の文献は、reasoning の冒頭に "【要人間確認】" を必ず付ける
- AbstractがないPMIDは relevance="unrelated", reasoning="抄録なし、人間判断必須" とする
- 判断に迷ったら必ず relevance="medium", reasoning に "判断保留: ..." を書く
- 出力前に、ae_signal="possible" の件数を1行目にコメントとして必ず出す: # ae_possible_count: N

【絶対ルール】
- 副作用報告の判定そのものは絶対にしない。あくまで「人間に escalation すべきかの下書き」だけ
- 統計データを捏造しない、不明な点は "unknown" と書く
- 推測で薬剤名や疾患名を補完しない

このプロンプトのポイントは、「判定そのものはしない、人間が15秒で判断する下書きを作る」と明示的に書いているところです。Claude Code はこう書いておかないと、たまに「自信を持って判定する」モードに入ってしまい、過剰にスクリーニングを掛けて重要な文献を「unrelated」に振ってしまうことがあります。

さらに重要なのが ae_signal(副作用シグナル)が possible/uncertain だった件は必ず人間にエスカレーション する設計です。GVPに基づき、副作用の可能性を示唆する文献を見つけた場合、企業は安全管理責任者を通じて所定の評価・報告フローに乗せる義務があります。Claude Code はあくまで「これは確認した方がいい候補」と並べるだけで、判定もカウントも行いません。

チェックリスト1: スクリーニング下書きを本番運用に乗せる前の必須確認3項目

• □ 副作用関連の判定権限・最終確認権限を、社内安全管理部門の担当者に明確に紐付けたか
• □ ae_signal が “possible” / “uncertain” の出力に対して、24時間以内に人間が一次確認する SLA を社内ルール化したか
• □ Claude Code のスクリーニング出力を「正式記録」ではなく「下書き」と扱う旨を、社内文書(SOP・業務手順書)に明記したか

レイヤー3: 要旨整形 — Abstract を社内テンプレートに落とす

スクリーニングで relevance=”high” となった文献を、MR教育・MSL向けに使える形に整形します。製薬企業でよく使われるのは PICO形式(Patient/Problem, Intervention, Comparison, Outcome)に、エビデンスレベル・主要評価項目・限界点を加えた構造です。

プロンプト3: 抄録を PICO + エビデンスレベル形式に整形

あなたは製薬企業の社内学術情報整理担当者です。
以下の英文Abstractを読み、社内標準テンプレートに落とし込んでください。

【出力テンプレート(Markdown)】
## 論文タイトル(原文)
## 論文タイトル(日本語意訳・直訳でなく医療従事者が読める日本語)
## 書誌情報
- 著者(筆頭): ...
- ジャーナル名: ...
- 出版年: ...
- PMID: ...
- DOI: ...

## 研究デザイン
- デザイン種別: (RCT / cohort / case-control / cross-sectional / case series / review / meta-analysis / その他)
- 規模: 被験者数・施設数
- 期間: 試験期間

## PICO
- P (対象): ...
- I (介入): ...
- C (比較): ...
- O (主要評価項目): ...

## 主要結果(数値があれば数値、なければ"記載なし")
- 主要評価項目の結果: ...
- 副次評価項目の結果: ...
- 統計的有意性: p値・信頼区間があれば原文表現のまま記載

## 著者が述べる結論
原文Conclusionの日本語意訳(200字以内)

## 限界点・注意点
- 著者自身が述べているlimitation: ...
- 読み手として注意すべき点(交絡因子・サンプルサイズ・追跡期間など): ...

## 暫定的なエビデンスレベル(参考)
- レベル: (Ia/Ib/IIa/IIb/III/IV/V のいずれか、または "判定不能")
- 根拠: なぜそのレベルと判断したか1-2文

## 社内利用上の注意
- MR教育資材で使う場合の留意点(承認外用法、海外データのため国内未承認 等)
- 販売情報提供活動ガイドラインの観点で気をつけるべき点

【絶対ルール】
- 抄録に書かれていない数値・結論を絶対に補完しない
- 「効果が高い」「優れた」など評価的表現を勝手に追加しない、原文の表現を尊重する
- 承認外の使用方法に関する記述は、必ず「(承認外用法に関する記述あり)」と明記
- エビデンスレベルはあくまで参考値であり、社内学術部門の最終判断が必要

【入力Abstract】
{abstract_text_here}

このプロンプトを使うと、英文の生Abstractから、社内で読みやすい構造化Markdownが出ます。重要なのは 「抄録に書かれていない数値・結論を絶対に補完しない」 の一文。これがないと、Claude Code は文脈から補完しようとして、論文に書いていない「ハザード比」や「症例数」を埋めにいくことがあります。これは医薬品の世界では致命的なので、必ず明示してください。

もうひとつのコツは、「承認外用法に関する記述あり」を明示させること。販売情報提供活動ガイドライン(2018年厚労省)では、承認された用法用量を逸脱した情報をMRが提供することが規制されています。論文中に承認外用法のデータが含まれている場合、それを MR教育で「使える」と扱うと社内ルール違反になるケースがあるため、最初の整形段階でフラグを立てておくのが安全です。

運用上の補足: PubMedクエリ式と医中誌・学会RSSの実務的な扱い方

レイヤー1の収集スクリプトを実際に動かしてみると、最初にぶつかるのが「クエリ式をどう組むか」の問題です。PubMedのMeSH(Medical Subject Headings)を活用するか、フリーキーワードで広く取るか、で取得件数が10倍以上変わります。製薬企業の文献監視では、「広めに取って、スクリーニングレイヤーで絞る」方針が一般的に推奨されます。これは、見落としによる副作用シグナル取り逃しのリスクが、ノイズが増える不便さよりはるかに重大だからです。

具体的には、自社薬剤の一般名・販売名・コード名(治験段階のもの含む)・主要な化学名候補・適応疾患のMeSH語・主要な副作用候補語、競合品の一般名、までを含むOR検索式を組みます。Claude Code に「以下の薬剤と疾患に対応するPubMedクエリを、Title/Abstract指定で組み立てて、MeSH語と通常表記の両方をORで繋いで」と指示すると、現実的な検索式の下書きが出ます。そのままは使わず、社内学術部門のレビューを通すのが安全です。

医中誌Webは、PubMedと違ってAPI公開が公開契約者限定の領域なので、検索結果のCSVエクスポート → ネットワーク共有フォルダ → Claude Code 読込、というオフライン連携が現実的です。日本語ジャーナルは英語ジャーナルと違ってAbstractの構造が緩い(背景・方法・結果・結論が明示的に分かれていない論文も多い)ため、プロンプト3の整形時に「日本語論文の場合は構造が緩いことを考慮して、明示的に書かれていない欄は『記載なし』と書く」という分岐を入れておくと安定します。

学会ジャーナルのRSSフィードは、循環器・腫瘍・神経・代謝・呼吸器など主要領域でかなり整備されています。一方、希少疾患領域や新興領域はRSSが用意されていないジャーナルも多いため、その場合は「対象ジャーナルの新着論文ページを定期的にスクレイピングする」アプローチに切り替えます。Claude Code でクローラーを作る場合は、必ず robots.txt 遵守・アクセス頻度を1リクエスト/秒以下に絞る・User-Agentに連絡先メールを書く、という3点を最初にプロンプトに含めてください。スクレイピングは「相手のサーバーに迷惑をかけない」ことが最低限のマナーです。

レイヤー4: MR向け勉強会資料の下書きを生成する

整形済みの文献データから、MR向けの勉強会資料(スライド原稿・配布資料)の下書きを派生させます。ここでも Claude Code の役割は「最終資料を作る」ではなく「教育担当が15分で清書できる素材を作る」です。

プロンプト4: MR向け勉強会の章立て + 想定問答たたき台

あなたは製薬企業のMR教育担当補助者です。
以下の整形済み文献データ(複数件)を使い、MR向け30分勉強会の構成案と想定問答たたき台を作ってください。
ただし、最終承認・修正は教育担当の人間が行います。あなたは「教育担当が15分で清書できる素材」を作る役割です。

【入力】
- 複数の整形済み文献Markdown(レイヤー3で出力したもの)
- 対象MR層: 経験 {junior/mid/senior} / 担当領域: {disease_area}
- 学習目標: {learning_objective}
- 関連する自社製品: {product_code_or_generic}

【出力】
1. 勉強会タイトル案(3案、それぞれ20字以内)
2. 章立て(5〜7セクション、各セクションに見出し+ねらい1文)
3. 各セクションのキーメッセージ(各3点、最大40字 / 1点)
4. ディスカッション用問い(2点)
5. 想定問答たたき台(MRが医療従事者から受けそうな質問を10問、それぞれに回答ドラフト)
6. 注意事項リスト
   - 承認外用法に関する記述は「医療従事者からの自発的質問への回答」以外で扱わない
   - 安全性情報は最新の添付文書・適正使用情報を必ず確認するよう注記
   - 海外データの場合は国内未承認である旨を明記
   - 競合品との比較情報を扱う際は販売情報提供活動ガイドラインに従う

【出力ルール】
- 文献データに書かれていない情報を補完しない
- 「他社品より優れている」「劇的な効果」などの優越的・誇張的表現を絶対に使わない
- 自社製品を直接的に推奨する表現を避け、エビデンスの紹介に徹する
- 想定問答の各回答の末尾に「(最新の添付文書・適正使用情報を必ず参照のこと)」を必ず付ける
- すべての出力末尾に「本資料は教育担当の最終承認前のドラフトです」を必ず追記

【絶対ルール】
- 効能効果を承認範囲外で訴求するような表現は絶対に作らない
- 添付文書・適正使用情報・最新ガイドラインと矛盾しうる断定的表現を避ける
- 副作用に関する情報は、「軽微」「ほとんどない」など主観的程度表現を絶対に使わない

このプロンプトを使うと、PICO 形式に整形された文献データ複数本から、勉強会タイトル → 章立て → キーメッセージ → 想定問答 まで、まとめて素材が出ます。教育担当の方が話していたのは「想定問答を10問作るだけで丸1日溶ける」ということで、ここの下書きが出るだけで体感が大きく変わるそうです。

注意点として、「他社品より優れている」「劇的な効果」など優越的・誇張的表現を禁止と明示している部分は省略しないでください。販売情報提供活動ガイドラインでは、医療従事者に対する情報提供で「断定的表現」「優越性を強調する表現」を避けることが求められており、これに違反すると行政指導の対象になります。Claude Code はプロンプトで縛らないとつい強い言葉を使ってしまうので、ここは必須の安全弁です。

レイヤー4続き: MSL向けFAQ(想定問答集)を Q&A 形式で構築する

MSL(メディカルサイエンスリエゾン)は、KOL(キーオピニオンリーダー)とのサイエンティフィックな対話を担当する職種です。MRと違って販促活動ではなく、純粋に学術的な情報交換が役割なので、想定される質問の深さも違います。Claude Code を使って FAQ 集を構築する場合、MR向けと別建てで作るのが現実的です。

プロンプト5: MSL向け FAQ(想定問答集)のたたき台

あなたは製薬企業のメディカルアフェアーズ部門のMSL業務補助者です。
以下の整形済み文献データ(複数件)と、過去のKOLからの質問ログ(任意)を使い、MSL向けのFAQ(想定問答集)のたたき台を作ってください。
ただし、最終確認・社内承認は学術部門の人間が行います。

【入力】
- 複数の整形済み文献Markdown
- 対象疾患領域: {disease_area}
- 自社製品コード: {product_code}
- 過去質問ログ(あれば): {past_questions_text}

【出力構造】
各FAQは以下のフォーマット:

### Q. (KOLが聞きそうな質問。サイエンティフィックな粒度で)
**A.** 回答ドラフト本文(300〜500字)
- 引用文献: PMID xxxxxx, ジャーナル名, 出版年
- 信頼度メモ: 高/中/低 と、その理由を1文
- ガイドライン整合性: 日本/海外の主要ガイドラインとの整合性を1-2文
- 注意点: 承認外用法/海外データ/サンプルサイズ等の留意点

【作成すべきFAQ件数】
最低15件、最大25件。以下の観点をバランスよくカバー:
- 有効性データに関する質問(4-6件)
- 安全性プロファイルに関する質問(4-6件)
- 機序・薬理に関する質問(2-3件)
- 患者集団・適応に関する質問(2-3件)
- 競合品・併用に関する質問(2-3件)
- リアルワールドデータに関する質問(1-2件)

【絶対ルール】
- 引用していない数値・主張を絶対に作らない
- 自社製品の優越性を断定する表現を使わない、エビデンスを淡々と提示する
- 承認外用法に関する回答は、「該当する文献では〇〇と報告されているが、本邦では承認外用法であり推奨されない」と明記
- 副作用に関する記述で、軽重を主観的に評価しない
- 不確かな点は「現時点で十分なエビデンスはなく、今後の研究が待たれる」と明記
- 各回答の末尾に「(本回答は社内学術部門の最終確認前のドラフトです。最新の添付文書・適正使用情報を必ず参照してください)」を必ず付ける

【出力先】
Markdown形式。冒頭に作成日と対象文献PMID一覧を付ける。

このプロンプトの肝は 「引用していない数値・主張を絶対に作らない」 と 「不確かな点は『現時点で十分なエビデンスはなく』と明記」 の2点。MSLが扱う質問は科学的に深く、適当な答えをすると即座に信頼を失う領域なので、Claude Code には「わからないことはわからない」と書かせる方が結果的に役に立ちます。

運用上の補足: KOL質問ログを Claude Code に渡す前の前処理

プロンプト5で「過去のKOLからの質問ログ」を入力に含めていますが、ここは取り扱いに最も気を遣う部分です。KOLとの対話記録は、KOLの専門領域・関心テーマが浮き彫りになる情報を含み、場合によっては個人特定につながる固有名詞も入っています。Claude Code に投入する前に、以下の前処理を必ず行ってください。

• 個人名・所属機関名のマスキング: 「〇〇大学医学部 △△教授」のような特定可能情報を「KOL_A」「施設_B」のような汎用ラベルに置換する。Pythonで簡単なマスキング辞書を作って、Claude Code に投入する前のパイプに通すのが安全。
• 未公開の自社開発品コードの除外: 治験中の品目コードや、社外秘の臨床試験ID(社内管理番号)が混入していないか目視確認する。
• 機密ラベル付与: 質問ログそのものを「社外秘」「社内限り」のラベルでメタデータ管理し、Claude Code 経由で外部API利用する場合の利用規約・データ取扱いを情シス・法務でレビュー済みであることを確認する。

これらの前処理を抜くと、せっかく堅牢に組んだプロンプト設計も、入力データのところでコンプライアンス事故になります。Claude Code に渡すデータは「公開前提でも問題ない粒度まで一段抽象化されたもの」だけにする、というのが原則です。

Claude Code でジョブを組むときの実装パターン

上のプロンプト5本を、単発で叩くだけでもかなり役に立ちます。ただ、運用レベルに乗せるなら Claude Code の自動実行機能を組み合わせて、以下のような日次ジョブにするのが現実的です。

1. 毎朝6:00: PubMed E-utilities スクリプトが前日分の新着論文をJSONLで保存(レイヤー1)
2. 毎朝6:30: Claude Code が JSONL を読み、プロンプト2でスクリーニング下書きを生成(レイヤー2)。出力は ./data/screened/{date}.jsonl
3. 毎朝7:00: relevance=”high” かつ ae_signal が “none” 以外のものを Slack/Teams に Webhook 投稿。担当者が出社後すぐに目視確認
4. 担当者の判定後: “重要” と判定された文献に対して、プロンプト3で PICO整形(レイヤー3)
5. 週次・月次: 整形済み文献を集めて、プロンプト4(MR勉強会素材)とプロンプト5(MSL FAQ)を実行(レイヤー4)

Claude Code は、こうした「特定のファイルを読んで、特定のフォルダに出力する」処理を、自然言語の指示で組み立てやすいツールです。たとえば「./data/pubmed/ の中で当日分の.jsonl を読んで、スクリーニング下書きを ./data/screened/ に出して」と書くだけで、ファイル一覧取得 → 読込 → API呼び出し → 保存、までを自動で組み立ててくれます。

類似の業務フローを病院・医療事務側でどう設計するかは、別記事の 病院の電子カルテサマリ作成を Claude Code で補助する事例、医療機関のレセプトチェック補助を Claude Code で実装する事例、クリニックの予約・問診ワークフローを Claude Code で省力化する事例 でも詳しく書いています。製薬企業と医療機関で扱う情報の種類は違いますが、「判断は人間に残す・前後の準備作業だけ自動化する」という設計原則は共通です。

運用上の補足: ジョブの監視・ログ・例外処理の作法

Claude Code でジョブを組む時、最初は「動けばOK」で進めがちですが、製薬の文献監視のように毎日確実に動いてほしいジョブは、運用に乗せた瞬間から監視・ログ・例外処理が本体になります。私が現場で見ていて、ここを甘く設計したがゆえに数日分の文献を取り逃したケースが何件かあります。最低限おさえてほしい設計ポイントを3つ書きます。

第一に 「ジョブが動いていないこと」を能動的に検知する仕組み。PubMedのAPIが一時的に重い・社内ネットワーク側で外部通信が制限された・実行サーバの容量がフルになった、など、ジョブが止まる理由はいくらでもあります。「動かなかったらSlackに通知」だけでは、止まったこと自体が通知されません。代わりに 「動いた完了通知が毎朝来ない場合に検知するヘルスチェック」を別ジョブとして用意します。Cron監視サービス(Healthchecks.ioのような無料ツールもあります)を使うか、社内の監視基盤に組み込むかは、組織の規模次第です。

第二に 「Claude Code に投げたプロンプトと返ってきたレスポンスを必ず保存する」。これは監査対応の観点で重要で、後から「あの日のスクリーニング下書きはどういうプロンプトで作ったのか」を追跡できる状態にしておく必要があります。日次のジョブ実行時に、プロンプト本文・モデルバージョン・入力データのハッシュ・出力本文を、一定期間(社内ルールに合わせて1〜3年)保管する設計を最初から組み込んでください。プロンプト・出力はテキストなので容量はたかが知れています。

第三に 「Claude のモデル更新・APIバージョン変更を吸収する抽象レイヤー」を用意すること。Claude Code が使うバックエンドモデルは、定期的にバージョンアップ・廃止があります。プロダクションで運用するなら、Claude Code を直接呼ぶスクリプトを社内ライブラリで一段ラップして、モデル名・APIエンドポイントを設定ファイルで切り替えられるようにしておくと、移行が楽になります。これは特別なことではなく、外部APIに依存するシステム全般のセオリーですが、AI周りは見落とされがちです。

【要注意】製薬DXでやらかしがちな失敗パターン4選

ここから、私が現場の方から聞いた「これはやってしまった/やりかけた」失敗を、抽象化して4つ紹介します。製薬以外の業界でも応用できる注意点なので、ぜひ覚えて帰ってください。

失敗パターンを見る前に、ひとつだけ前提を共有させてください。ここで挙げるのは「製薬DXあるある」を抽象化したもので、特定企業の事故ではありません。ただ、業界横断で見ると、AI導入初期に同じところでつまずく企業が多いポイントなので、最初に潰しておく価値があります。Claude Code を扱う担当者だけでなく、その人を社内で支える法務・薬事・コンプライアンス部門にも目を通してもらえると、後の調整がスムーズになります。

失敗パターン1: 副作用シグナルの「判定」までAIに任せる

❌ NG: 「副作用に該当するかどうかも含めてAIに自動分類させ、該当ありのものだけ人間に回す」

⭕ OK: 「副作用に該当しそうな記述があるかどうかの『候補』だけAIに出させ、すべての候補を人間が確認する。AIは判定しない」

これが一番怖いやつです。GVP では、副作用と疑われる情報を入手した場合、企業は遅滞なく評価・報告する義務があります。AIに「該当しない」と判定された情報を見逃して報告漏れになると、行政指導から最悪は業務停止命令まであり得ます。Claude Code は副作用判定に使わない。判定の候補抽出と下書き整理のみに使う。これは絶対のルールにしてください。

失敗パターン2: 承認外用法のデータをMR向け資材にそのまま転用する

❌ NG: 海外論文で報告された承認外用法のデータを、Claude Code でPICO整形してMR向け勉強会資料に組み込み、そのまま現場で配布する

⭕ OK: 承認外用法に関する記述があれば自動で「(承認外用法に関する記述あり)」フラグを立て、MR向け資料に転用する前に必ず学術部門のレビューを通す

販売情報提供活動ガイドラインでは、承認された効能効果・用法用量の範囲を超えた情報をMRが提供することに厳しい制約があります。とはいえ「医療従事者からの自発的質問への回答」など、限定的な状況では扱える場合もあるため、一律禁止ではなく 運用ルールを社内で明文化する ことが重要です。Claude Code には「フラグを立てさせる」役割を任せて、扱い方の判断は社内ルールに沿って人間が行う、という分業が安全です。

失敗パターン3: 「業務効率化〇〇%」をKPIにして暴走する

❌ NG: 「文献監視の時間を50%削減」を最優先KPIにして、スクリーニング閾値を緩めたり、人間レビューをスキップする運用を始める

⭕ OK: 「文献の見落とし率0」「副作用シグナル候補の人間確認率100%」を不可侵KPIにした上で、副次的に「整形作業時間の削減」を追う

製薬DXで一番危ないのが、効率化を主目的にしてしまい、本来必要な人間の判断レイヤーを取っ払ってしまうこと。私が伴走している企業では、「品質の不可侵ライン」を先に決めて、それを守った上での効率化を測る、という順番を必ず守るようにしています。Claude Code はあくまで補助。判断は人間。これがブレなければ、製薬DXは堅実に進みます。

失敗パターン4: プロンプトに「日本の法規制を守って」とだけ書く

❌ NG: 「日本の薬機法・GVP・販売情報提供活動ガイドラインを守って文章を書いて」と1行だけ指示する

⭕ OK: 「承認外用法の記述は〇〇とフラグ」「優越的表現禁止」「断定的表現禁止」「数値の補完禁止」など、具体的にやってほしくない振る舞いを列挙する

Claude Code を含むLLMは、「法規制を守って」と書いても、法規制の中身を完全に理解して動いてくれるわけではありません。具体的に「やらないでほしいこと」をプロンプトに列挙する方が遥かに確実です。今回紹介したプロンプト3〜5には、製薬業界で特に外せない振る舞い禁止項目を入れてありますが、自社で運用するときは社内の薬事・コンプライアンス部門と一緒に、追加で禁止項目を増やしていく運用を推奨します。

【チェックリスト2】製薬企業がClaude Code導入前に揃えるべき社内整備項目

• □ Claude Code の利用範囲を「文献監視・要旨整形・下書き作成の補助」に限定する旨を、社内SOP(標準業務手順書)に明記
• □ 副作用シグナル候補の人間確認SLAを定義(例: 24時間以内に一次確認)
• □ ae_signal が “possible” / “uncertain” の文献を一元管理するワークフロー(Teams/Slack + 安全管理部門への自動エスカレーション)を整備
• □ 承認外用法に関する記述を扱うルール(MR配布不可、MSL対応のみ、学術部門レビュー必須など)を文書化
• □ Claude Code への入力データ(社内文書・KOL質問ログなど)の機密区分を整理し、外部送信可否を法務・情シスでレビュー
• □ Claude Code 出力の「ドラフト性」を全資料に明記する旨を運用ルールに含める
• □ プロンプト・実行ログ・出力を一定期間保管する社内ルール(監査対応)
• □ ベンダーロックインを避けるため、プロンプト・出力フォーマットは社内資産として版管理(Git)

【チェックリスト3】MR/MSL向け資材の最終確認3点

• □ 自社製品の優越性を断定する表現が含まれていないか(販売情報提供活動ガイドライン観点)
• □ 副作用に関する記述で、軽重を主観的に評価する表現(「軽微」「ほとんどない」など)が含まれていないか
• □ 承認外用法に関する記述がある場合、明示的にその旨が記載されており、社内ルールに沿った扱いになっているか

運用上の補足: 「人間がレビューする時間」をどう確保するか

製薬企業でClaude Code導入を支援していて気づいたのは、技術的な設計より「人間がレビューする時間をどう業務に組み込むか」のほうが難しいということでした。Claude Code がいくら良い下書きを作っても、それを学術部門・薬事部門・安全管理部門が確認する時間が確保できなければ、ボトルネックは前から後ろに移るだけです。

現実的に効くアプローチは、レビュー作業を「定型化された短時間のチェックリスト方式」に変えることです。フリー記述で「気になる点を書いてください」という形式だと1件あたり20〜30分かかりますが、「以下の10項目に○×を付けてください、×が1つでもあれば差し戻し」という形式にすると、1件5分以内で回ります。Claude Code に出力させる時点で、このチェック項目が浮かびやすい構造化Markdownにしておく(PICO・限界点・承認外フラグ等)のは、レビュー高速化の観点でも効きます。

もうひとつのコツは、「初期は確認頻度を高くして、AIの傾向を掴んでから徐々に間隔を空ける」運用です。導入1ヶ月目は毎日全件レビュー、2ヶ月目は週次でサンプル50%レビュー、3ヶ月目以降は週次でランダム10件抽出レビュー+異常検知ベース、というように段階的に運用負荷を下げていきます。これは品質と効率のバランスを取る古典的な手法で、新規メンバーの研修期間と同じ考え方です。

FAQ: 製薬企業 × Claude Code の現場でよくある質問

Q. Claude Code に社内の文献データベース全部を読み込ませても大丈夫?

A. 機密区分次第です。論文Abstract(公開情報)は問題ないことが多いですが、社内の安全性データ・症例報告・KOL質問ログなどは個人情報・営業秘密・薬事規制対象情報を含むことがあるため、必ず情シス・法務・薬事部門のレビューを通してから取り扱い範囲を決めてください。Claude for Enterprise(Anthropic公式の法人プラン)や、自社のセキュアな実行環境内で Claude API を呼ぶなど、利用形態によって対応が変わります。

Q. PMDAやFDAの規制関連情報も Claude Code で監視できる?

A. 公式サイト・公開ニュースの監視はできます。PMDAの医薬品医療機器情報のRSS、FDAのDrug Safety Communicationsなど、公開情報源を巡回するスクリプトは Claude Code で組めます。ただし、規制関連情報は解釈に専門性が必要な領域なので、AI は「タイトル・概要の収集と整理」までに留め、解釈は薬事部門が行う設計を強く推奨します。

Q. MR向け資材を Claude Code で量産すれば、教育担当の工数を半減できる?

A. 「下書きの作成時間」は大幅に短縮できますが、「最終承認・修正・社内レビュー」のプロセスは短縮できません。教育担当の本質的な仕事は、コンテンツの品質保証と現場の声を反映した教育設計なので、そこを削ると逆に教育品質が下がります。Claude Code は「最初の素材作り」に使う、と割り切るのが現実的です。

Q. 副作用報告は最終的に誰の判断?

A. 製造販売業者の安全管理責任者が、GVP に基づき所定の評価・報告フローで判断・報告します。Claude Code は副作用に関する判定を一切行わず、あくまで「人間に確認してもらうべき候補」を並べる役割に徹してください。最終的な医学的判断・処方判断は医療従事者(医師・薬剤師)が行います。

Q. AIが作った資材を MR が現場で使った場合の法的責任は?

A. AIが作っても人間が作っても、企業として情報提供活動を行った時点で、その内容に対する責任は製造販売業者にあります。AIが下書きしたから責任が軽くなる、ということはありません。だからこそ、AI出力は「下書き」と明確に位置付け、学術部門・薬事部門のレビューを必ず通す社内ルールが重要になります。

運用が回り始めてからの「次の一手」

レイヤー1〜4が安定運用に乗ったあと、製薬企業の現場で次に出てくるニーズは大きく2方向に分かれます。ひとつは 「過去文献の遡及整理」。新しく入ってきたMR・MSL・教育担当者向けに、過去5〜10年分の主要論文を整形済みデータベース化したい、というニーズです。これは Claude Code に「過去のPubMed検索結果CSV(数千件)を、プロンプト3のテンプレートで一括整形する」バッチ処理を任せる形で対応できます。1日1,000件処理しても、コスト的にも時間的にも現実的な範囲に収まります。

もうひとつは 「KOL別・領域別のパーソナライズ」。MSLが特定のKOLと対話する前に、そのKOLの過去発表論文・関心領域・直近の質問履歴をまとめた「KOLブリーフィングメモ」を Claude Code に生成させる、という使い方です。これは MSL の準備時間を大幅に短縮できる一方、KOLの個人情報・嗜好データを扱うので、社内のデータガバナンスルール(個人情報保護・営業秘密管理)との整合性確認が必須になります。技術的にはレイヤー4の延長で組めますが、ルール整備のほうが先です。

これからの30日でやってみたいこと(3アクションCTA)

ここまで読んでくださった方に、すぐ着手できる3つのアクションをお勧めします。

1. 今日: プロンプト3(PICO整形)を社内の検証環境で1回試す — 自社で過去に扱った英文Abstractを1本選び、本記事のプロンプト3に貼り付けて、社内テンプレートに落ちるかを確かめる。ここで違和感のあるフィールド・足りないフィールドをメモして、自社向けにカスタマイズする。
2. 1週間以内: 副作用シグナル候補のエスカレーション SLA を社内で議論する — 法務・薬事・安全管理・情シスを集めて、「Claude Code が候補抽出したらどの経路で誰が何時間以内に確認するか」を決める。これがないと運用に乗せられない。
3. 30日以内: 文献監視ジョブを1疾患領域だけで Pilot 運用 — 全社展開せず、1つの疾患領域(例えば自社の重点品目1つ)に絞って、レイヤー1〜3を稼働させる。週次で運用レビューを開き、見落とし・誤検出・整形品質を計測する。

Claude Code の導入を伴走する Uravation の個別指導では、こうした「業務分解 → プロンプト設計 → 運用ルール化」のサイクルを、現場の方と一緒に1ヶ月ペースで回しています。製薬・医療領域は規制が厳しい分、AI導入を慎重に進めたい業界です。だからこそ、最初に「やらないこと・人間に残すこと」を決めてから、効率化に進む順番を強く推奨します。

もうひとつだけ補足すると、こうした取り組みは一人で抱え込むと続きません。最初の検証フェーズから、メディカルアフェアーズ・薬事・情シス・法務の最低4部門から1名ずつでも巻き込んで、月1の定例で運用状況を共有する場を作っておくと、スケールアップのときに合意形成がぐっと楽になります。「AIに何をやらせて、何をやらせていないか」を、社内のステークホルダーが共通言語で語れる状態にしておくこと。これが、製薬DXを腰折れさせずに進める一番の地盤づくりだと感じています。

参考出典

• 厚生労働省「医薬品の製造販売後安全管理の基準に関する省令(GVP省令)」 — 製造販売業者の安全管理体制・副作用報告義務に関する基準
• 厚生労働省「医療用医薬品の販売情報提供活動に関するガイドライン」(2018年策定) — MR等による情報提供活動の規範
• National Library of Medicine “Entrez Programming Utilities (E-utilities)” — PubMed公式API仕様。検索・取得・サマリの3系統を持つREST APIで、ベース URL は eutils.ncbi.nlm.nih.gov
• PMDA(独立行政法人医薬品医療機器総合機構)公式サイト — 国内医薬品安全性情報・副作用報告様式・最新通知
• 厚生労働省「医薬品リスク管理計画(RMP)」関連通知 — 製造販売後の安全管理計画の枠組み

著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向け生成AI研修・導入支援を担当。著書『AIエージェント仕事術』(SBクリエイティブ)、SoftBank IT連載7回執筆。Claude Code の業界別実装事例を整理した本メディア(claudecode-cases.com)を運営しています。

※本記事の医療・薬事領域に関する注意: 本記事で紹介した内容はあくまで Claude Code を「文献整理・要旨整形・下書き作成の補助ツール」として使うための一般的な業務フローと実装例です。最終的な医学的判断・処方判断は医師・薬剤師が行うべきであり、本記事のプロンプト・スクリプトをもって自社の薬事業務・安全管理業務を自動化することは推奨していません。MR/MSLによる情報提供活動はGVP・販売情報提供活動ガイドラインに従って運用し、副作用報告は所定の社内フローを通じて安全管理責任者の判断のもとで行ってください。実在の薬剤名・論文・副作用症例については、本記事では具体例として持ち出さず、一般的な業務フローに留めて記述しています。

関連記事（自動）

• ▸ 【2026年最新】介護事業所のClaude Code活用｜ケアプラン・記録・家族説明資料の自動化
• ▸ 【2026年最新】美容クリニックの予約・カウンセリングをClaude Codeで
• ▸ クリニック予約業務をClaude Codeで整理｜受付FAQと日次レポート自動化の実装例
• ▸ 医療レセプト点検をClaude Codeで自動化｜返戻率40%削減の実装パターン