TL;DR EU MDR Article 87-92 が要求する Vigilance（有害事象報告）対応で、Claude Code に「社内不具合DBのトリアージ → SAE判定の構造化 → Vigilance Report 初稿ドラフト」を任せる実装ログ。報告期限は IMDRF 基準（Immediate / 10日 / 15日 / 30日）に整合。初稿生成は2時間以内で完了したが、Seriousness 判定・因果評価・Reportability の最終確定は PRRC または安全管理責任者が必ず実施する。AI は「人間が判断するための材料を整える」位置づけに徹する。
目次
- はじめに：Vigilance はなぜ「終わらない仕事」なのか
- Vigilance の全体像（EU MDR Article 87-92）
- SAE（Serious Adverse Event）の判定フロー
- 報告期限：IMDRF Annex 5 準拠
- Trend Report / FSCA / FSN の関係
- 日本のクラスIV不具合報告制度との比較
- Claude Code/AI で何ができて何ができないか
- プロンプト設計 4要素
- 実際のプロンプト例
- 出力例：Vigilance Report の各セクション
- トリアージへの活用：社内不具合DB → 報告対象抽出
- 工数比較
- AI が苦手な点 / 限界
- 次の一手
- FAQ
- 関連リソース
はじめに：Vigilance はなぜ「終わらない仕事」なのか
QA/RA 担当者の中で、特に消耗するのが Vigilance（有害事象報告）対応です。
「夜中にカスタマーサポートから事象連絡が来た。2日以内に報告判断を下さないといけないが、何が serious で、何が reportable なのか、毎回ゼロから組み立てている」
Vigilance は「市販後にずっと続く仕事」です。製品が市場に出ている限り、事象は発生し続けます。EU MDR が完全適用されてから、Vigilance Report の要求レベルは大きく上がりました。Notified Body の検査でも Vigilance プロセスの不備は重大不適合として扱われます。
今回は Vigilance Report のドラフトと社内不具合DBのトリアージを Claude Code で半自動化する実装ログです。
結論: 「事象記述 → SAE 該当性 → Reportability → Vigilance Report 初稿」のパイプラインは AI で大幅に短縮できる。ただし最終判定は PRRC または安全管理責任者が必ず実施する。AI は判断材料を整える役割。
Vigilance の全体像（EU MDR Article 87-92）
EU MDR の Vigilance システムは Article 87-92 で規定されています。
| Article | 内容 |
|---|---|
| Article 87 | Reporting of serious incidents and field safety corrective actions（重篤事象・FSCA の報告義務） |
| Article 88 | Trend reporting（傾向報告） |
| Article 89 | Analysis of serious incidents and FSCAs（当局による分析） |
| Article 90 | Analysis of vigilance data（Vigilance データの分析） |
| Article 91 | Implementing acts |
| Article 92 | Electronic system on vigilance and on post-market surveillance（EUDAMED Vigilance モジュール） |
実務上、最も頻繁に参照するのは Article 87（個別の重篤事象報告）と Article 88（傾向報告）です。
ガイダンスとしては、MEDDEV 2.12-1 rev.8（旧 MDD 時代のガイダンス、現在も参照される）と MDCG 2023-3（EU MDR 下での Vigilance Q&A）、MDCG 2024-1（Periodic Summary Report の解釈）を押さえます。
SAE（Serious Adverse Event）の判定フロー
EU MDR Article 2(65) における Serious Incident の定義は以下のいずれかに該当する事象です。
- (a) 患者・使用者・第三者の 死亡
- (b) 患者・使用者・第三者の 健康状態の重篤・不可逆的な悪化
- (c) 公衆衛生上の 重大な脅威（Serious Public Health Threat）
判定フロー（簡略版）
[事象発生・認識]
↓
①事象に医療機器が関与しているか？
↓ Yes
②事象が Serious か？（Article 2(65) (a)/(b)/(c)）
↓ Yes
③医療機器の不具合・性能低下・ラベル/IFU 不備等が
「合理的に考えて」事象に関与した可能性があるか？
↓ Yes
④Reportable Serious Incident → Article 87 に基づき報告
↓
⑤報告期限（Immediate / 10日 / 15日）を判定このフローを すべての社内不具合報告に対して適用するのが Vigilance プロセスです。月数百件の事象を抱える製品では、この判定だけで人的リソースが枯渇します。
重要: 「合理的に考えて関与した可能性」（reasonably possible）の判断は medical/technical の両側面を含み、最終責任は PRRC（Article 15 で指名された規制適合責任者） にあります。AI に判定させてはいけません。
報告期限：IMDRF Annex 5 準拠
報告期限は IMDRF（International Medical Device Regulators Forum）の Adverse Event Reporting ガイダンス Annex 5 に準拠した区分が、EU MDR でも採用されています。
| 区分 | 期限 | 該当事象 |
|---|---|---|
| Immediate（即時） | 認識から 2日以内 | 公衆衛生上の重大な脅威（Serious Public Health Threat） |
| 10日報告 | 認識から 10日以内 | 死亡または健康状態の重篤・不可逆的悪化 |
| 15日報告 | 認識から 15日以内 | その他の Serious Incident |
| 30日報告（Trend） | 認識から 30日以内 | Trend Report（Article 88） |
注意: 「Immediate = 2日」「死亡 = 10日」の区分は MDCG 2023-3 Section 5 で確認可能ですが、各国所管当局がさらに短縮を求めるケースもあります。要原典確認。
起算日は Awareness Date（メーカーが事象を「認識」した日）。社内で誰が・いつ・何を知ったかが起算点になるため、社内SOPで Awareness の定義を明文化しておく必要があります。
Trend Report / FSCA / FSN の関係
| 用語 | 内容 | 根拠 |
|---|---|---|
| Vigilance Report | 個別の Serious Incident 報告 | EU MDR Article 87(1)(a) |
| Trend Report | 個別には報告対象外でも、頻度・重篤度が統計的に有意に増加した場合の報告 | EU MDR Article 88 |
| FSCA | Field Safety Corrective Action（市販後是正措置：リコール・修正・使用制限・回収など） | EU MDR Article 87(1)(b) |
| FSN | Field Safety Notice（FSCA をユーザー・患者に通知する文書） | EU MDR Article 89(8) |
| PSR | Periodic Summary Report（当局合意の上で個別報告を集約する形式） | EU MDR Article 87(9) |
実務的な関係性:
[個別事象]
├─→ Serious? → Yes → Vigilance Report（個別）
│ ↓
│ 根本原因分析・是正措置検討
│ ↓
│ 必要なら → FSCA 実施 → FSN 配布
│
└─→ 個別は Non-serious だが、傾向に有意な変化
↓
Trend ReportFSCA を実施した場合、EU MDR Article 89 に基づき所管当局への報告と FSN の配布が必要です。FSN は患者・ユーザーが理解できる平易な言葉で書く必要があり、ここも AI のドラフト支援が有効な領域です。
日本のクラスIV不具合報告制度との比較
日本では薬機法第68条の10、施行規則第228条の20に基づく「医療機器の不具合等報告」が Vigilance に相当します。
| 項目 | EU MDR Vigilance | 日本（薬機法） |
|---|---|---|
| 根拠法令 | EU MDR Article 87-92 | 薬機法第68条の10、施行規則第228条の20 |
| 報告先 | 製品上市国の所管当局 / 将来は EUDAMED | PMDA（独立行政法人医薬品医療機器総合機構） |
| 重篤死亡（国内） | 10日以内 | 15日以内 |
| 重篤死亡（外国症例） | — | 15日以内（一部 30日） |
| その他の重篤 | 15日以内 | 30日以内 |
| Public Health Threat | 2日以内（Immediate） | 個別判断（クラスIV等で随時） |
| 報告様式 | MIR（Manufacturer Incident Report） | 不具合症例報告書（PMDAフォーマット） |
重要: 期限・区分は法令改正で変動します。本表は2026年4月時点の理解で、最新の通知・施行規則は必ず原典で確認してください。
クラスIVの能動植込み医療機器など重篤性の高い製品では、報告基準・対応スピードが特に厳格です。グローバル展開している製品では、EU と日本で同じ事象に対して別々のドラフトを作成する必要があります。
Claude Code/AI で何ができて何ができないか
AI が「できる」こと ✅
- 事象記述（カスタマーサポート受付メモ・現場報告書など）から 構造化された事象サマリを生成する
- EU MDR / 薬機法それぞれの観点で Reportability の論点リストを提示する
- Vigilance Report（MIR）の章立てに沿ったドラフトを生成する
- 過去事例DBから類似事象を検索して比較材料を出す（RAGとの組合せ）
- タイムスタンプ整理（Awareness Date 候補の抽出）
- 多言語対応（英語 MIR ↔ 日本語不具合報告書のドラフト変換）
AI が「できない・してはいけない」こと ⛔
- Reportability の最終判定（PRRC・安全管理責任者の責任）
- Seriousness の医学的判定（医療専門家の判断が必要）
- 因果関係（causality）の最終評価（医学的・工学的判断の統合）
- Awareness Date の確定（法的解釈を含む）
- 当局への直接送信（必ず人間のレビュー後に送信）
明示的な但し書き: 本記事で扱う Claude Code の活用は トリアージ補助・初稿生成・整形作業の支援に限定する。Vigilance Report の Reportability 判定および提出可否の最終判断は、EU MDR では PRRC（Article 15）、日本では安全管理責任者・国内品質業務運営責任者など、規制で指名された有資格者が必ず行う。AI は「人間が判断するための材料を整える」位置づけに徹し、判定を代行させてはならない。
プロンプト設計 4要素
Vigilance タスクで Claude Code に渡すプロンプトは、以下の4要素を必ず含めます。
①役割: あなたは医療機器メーカーの Vigilance 担当補助 AI である
②背景: 製品情報・クラス分類・上市国・該当規制（EU MDR / 薬機法）
③手順: 事象を整理 → 論点リストを提示 → MIR/不具合報告書のドラフトを生成
④アウトプット形式: 構造化された章立て、確認すべき論点を明示、判定は人間に委ねる特に重要なのは ④ の「判定は人間に委ねる」を明示することです。これを書かないと、Claude が「Reportable と判定します」のように断定的な出力を出してしまうケースがあります。
設計テンプレ:
あなたは EU MDR Vigilance プロセスの補助 AI です。
最終的な Reportability 判定は PRRC が行います。
あなたの役割は、判定に必要な論点・根拠を構造化して提示することに限定されます。この一文を冒頭に置くだけで、出力のトーンが「判定する AI」から「判断材料を整える AI」に変わります。
実際のプロンプト例
ステップ1: 事象記述の構造化
あなたは EU MDR Vigilance プロセスの補助 AI です。
最終的な Reportability 判定は PRRC が行います。
【事象記述（カスタマーサポート受付メモ）】
2026-04-20 15:30、A病院のICU看護師から電話。
当社製の在宅用パルスオキシメータ（製品コード PXO-200）について、
「3日前から自宅で使用していた患者が、朝SpO2 99% 表示にも関わらず
チアノーゼで救急搬送された。実測SpO2は 78% だった」との報告。
患者は60代男性、COPD既往あり、現在ICUで人工呼吸管理。
【タスク】
以下の章立てで、事象を構造化してください。
- 事象サマリ（5W1H）
- 関与した医療機器の特定情報
- 患者の状態（事象前 / 事象時 / 事象後）
- 事象に関与した可能性のある要因（複数挙げる、断定しない）
- Awareness Date の候補とその根拠
- 不明な情報・追加調査が必要な項目ステップ2: Reportability の論点整理
上記の構造化事象に基づき、EU MDR Article 87 および
日本薬機法第68条の10 それぞれの観点で、
Reportability 判定の論点を整理してください。
【出力形式】
| 規制 | 判定軸 | 該当性の論点 | 必要な追加情報 |
判定そのものは行わず、論点と必要情報の提示に留めてください。
最終判定は PRRC / 安全管理責任者が行います。ステップ3: Vigilance Report（MIR）ドラフト生成
仮に上記事象が EU MDR Article 87 に基づく報告対象と
判定された場合の MIR（Manufacturer Incident Report）
ドラフトを生成してください。
MIR の章構成（A〜H）に沿って、現時点で記載可能な内容を
埋めてください。情報不足のフィールドは [要追加情報: XXX] と
明示してください。
A. Administrative information
B. Information on submitter
C. Information on manufacturer
D. Information on authorised representative
E. Information on medical device
F. Information on incident
G. Information on patient
H. Information on healthcare professional / userステップ4: 日本語不具合報告書ドラフト
同じ事象を、日本の薬機法第68条の10に基づく
「医療機器不具合等報告書」のドラフトに落とし込んでください。
PMDA様式に準拠した章立てで、英語 MIR との情報の重複・差分を
明示してください。出力例：Vigilance Report の各セクション
実際に Claude Code が生成した MIR ドラフトの一部（仮想事例）。
F. Information on incident（抜粋）
F.1 Date of incident: 2026-04-17（推定、要追加情報: 患者の最終測定時刻）
F.2 Date manufacturer became aware: 2026-04-20 15:30
F.3 Type of incident:
- Code: IMDRF AE Terminology AEC1003 (Inaccurate measurement)
[候補、要 medical reviewer による確認]
F.4 Description of incident:
患者宅で使用中の PXO-200 が SpO2 99% を表示していたが、
実測値は 78% であった。表示値と実測値の乖離により
低酸素状態の発見が遅延し、患者は救急搬送・人工呼吸管理に至った。
F.5 Consequences for patient:
[要追加情報: 主治医からの臨床経過情報]
現時点では「健康状態の重篤・不可逆的悪化」に該当する可能性
（Article 2(65)(b)）。最終判定は medical reviewer の評価による。
F.6 Manufacturer's preliminary analysis:
[要追加情報: 該当製造ロットの解析結果]
考えられる原因（断定しない）:
a) センサーの劣化・汚染による光学的測定誤差
b) 患者の末梢循環不全による測定限界
c) ソフトウェアの異常値ハンドリングの不備
d) 使用方法の誤り（IFU 逸脱）ポイント:
- 断定的表現を避け、「候補」「可能性」「要追加情報」で全フィールドを構造化
- IMDRF AE Terminology のコード候補を提示（最終的なコード確定は人間）
- 複数の原因仮説を列挙して、原因を1つに絞らない（メーカーの予断を避ける）
Public Health Threat 該当性チェック（Claude が補助的に出した分析）
[Public Health Threat 該当性の論点整理（判定ではない）]
論点1: 同一型式の他患者でも同様の事象が発生していないか？
→ 過去90日の社内不具合DBの確認が必要
論点2: 製造ロット起因か、設計起因か？
→ ロット解析とエンジニアリングレビューの両方が必要
論点3: 表示値と実測値の乖離が「systematic」か「random」か？
→ systematic ならリコール検討、random なら設計マージン再評価
→ Public Health Threat 該当（Article 87(1)(a) Immediate 報告）の
可能性を否定するためには、論点1〜3 の確認が不可欠。
現時点では Immediate / 10日 のいずれかの可能性を排除できない。
PRRC による速やかな評価を推奨する。このように、AI は「判定を保留しつつ、保留している理由と確認すべき論点を明示する」のが最も実務に役立ちます。
トリアージへの活用：社内不具合DB → 報告対象抽出
Vigilance プロセスで最も人的リソースを消費するのが、社内に上がってくる全事象（月数百件規模）から報告対象を抽出するトリアージです。
Claude Code でのトリアージワークフロー
[社内不具合DB（CRM/QMSの事象テーブル）]
↓ CSV/JSONエクスポート
[Claude Code に投入]
↓
①各事象を IMDRF AE Terminology コードでタグ付け（候補）
↓
②Severity 判定の論点を抽出（Serious 候補をフラグ）
↓
③過去類似事象との比較（Trend Report 候補の検出）
↓
④トリアージレポート生成
↓
[Vigilance 担当者（人間）がレビュー]
↓
[PRRC が最終判定]実装サンプルプロンプト
あなたは Vigilance トリアージ補助 AI です。
最終的な報告判定は PRRC が行います。
【入力データ】
社内不具合DB の過去30日分（CSV、150件）
【タスク】
各事象に対して以下を出力してください。
| ID | 事象要約 | IMDRF AE コード候補 | Serious 該当性論点 |
| Reportability 候補 | 類似過去事例 ID | 推奨アクション |
「推奨アクション」は以下のいずれか:
- A: PRRC 即時レビュー推奨（Immediate 候補）
- B: 24時間以内レビュー推奨（10日報告候補）
- C: 通常レビュー（15日報告候補）
- D: Non-serious 候補だが Trend 監視対象
- E: Non-reportable 候補
判定ではなく「候補」として出力してください。Trend Report 候補の検出
過去90日のデータを Claude Code に投入し、統計的に有意な増加を検出させる活用例:
過去90日の不具合データを以下の観点で分析してください。
①同一の IMDRF AE コードでの発生頻度の月次推移
②同一製造ロット内での不具合集中
③同一医療機関からの繰返し報告
統計的に有意な変化が見られたものについて、
Trend Report（Article 88）の検討対象として
論点を提示してください。
「有意」の判定は社内 PMS Plan の閾値（社内SOP参照）に
従うため、最終判定は安全管理部門が行います。このフローで、従来は2人体制で1日かけていたトリアージが、半日 + AIで完了するケースが出てきます（社内SOP・データ品質に依存）。
工数比較
| ステップ | 従来 | AI活用後 |
|---|---|---|
| 事象記述の構造化 | 1〜2時間/件 | 10〜20分/件 |
| Reportability 論点整理 | 2〜4時間/件 | 30〜60分/件 |
| MIR ドラフト初稿 | 4〜8時間/件 | 1〜2時間/件 |
| 日本語不具合報告書ドラフト | 3〜6時間/件 | 30〜60分/件 |
| 月次トリアージ（150件規模） | 30〜50時間 | 10〜15時間 |
| PRRC レビュー・判定 | 変わらず（必須） | 変わらず（必須） |
| 個別報告1件の合計工数 | 10〜20時間 | 3〜5時間 |
| 削減率 | — | 約60〜70% |
注意: 数値は条件付きです。社内SOP・データ品質・対象製品クラス・事象の複雑さによって変動します。PRRC レビュー時間は短縮対象ではない点に注意してください。
AI が苦手な点 / 限界
1. 医学的因果評価は AI に任せられない
「事象 A は機器の不具合 B に起因するか」という判断は、医学的・工学的・統計的知見の統合が必要です。AI が「可能性」を提示することはできますが、最終的な causality assessment は medical reviewer + engineering の合議で決めます。
2. Awareness Date の法的判定
「いつメーカーが認識したか」は法的争点になり得ます。社内のどの時点（営業 / カスタマーサポート / 品質保証 / PRRC のどの段階）で「認識した」と扱うかは、社内SOPと法的解釈に依存します。AI にタイムスタンプ整理は任せられても、起算日の確定は法務 + PRRC の判断が必要です。
3. 公衆衛生上の重大な脅威（Public Health Threat）の判定
Immediate（2日報告）の引き金となる Public Health Threat の判定は、疫学的視点が必要です。AI は単一事象の重篤性は記述できますが、「公衆衛生への波及」の判断は人間が担います。
4. 多国・多言語の同時報告
EU MDR Vigilance、米FDA MDR、日本不具合報告、その他各国の制度は 報告様式・期限・判断基準がすべて異なります。AI は変換の補助はできますが、各国の最新規制に整合しているかの確認は規制有資格者が必須です。
5. EUDAMED / 各国システムへの実送信
EUDAMED Vigilance モジュール、PMDA の SKWeb など、当局システムへの送信は 必ず人間がレビュー後に行う運用にしてください。AI が直接 API 経由で送信する設計は推奨しません。
6. ハルシネーション対策
Claude Code が IMDRF AE Terminology コードを「それらしく」出力するケースがあります。コードは IMDRF Annex A の最新版で必ず実在性を確認してください。
次の一手
Vigilance は単独で完結する仕事ではありません。以下と密接に連動します。
- PMS（市販後監視）計画と Vigilance の連動を Claude Code で設計 ← 次回記事化予定
- ISO 14971 リスクマネジメントファイルと Vigilance データの双方向更新
- PMDA 事前相談 Q&A を Claude AI で作る
- EU MDR 臨床評価報告書（CER）を Claude AI で設計する
- 医療機器 × AI 規制対応の全体像（ピラー記事）
特に PMS Plan ⇄ Vigilance の双方向フローは、Notified Body 検査でも重視される領域です。Vigilance で得た知見を PMS Plan の更新に反映するループを、AI で半自動化する次回記事を準備中です。
まとめ：Vigilance の「終わらない仕事」を AI で支える
Vigilance は「製品が市場にある限り、終わらない仕事」です。月数百件の事象を、規制で定められた期限内（最短2日）に判断し続けることは、人間だけでは不可能になりつつあります。
AI でできるのは:
「判断材料を整える」「初稿を作る」「過去事例と比較する」「論点を漏らさない」
AI でできないのは:
「Reportability の最終判定」「医学的因果評価」「公衆衛生上の脅威の判断」「当局への送信責任」
この 役割分担を明文化した社内SOP を持っているかどうかが、Vigilance プロセスの成熟度を分けます。Claude Code を導入する際は、**「AI の出力は必ず PRRC のレビューを経る」**を社内ルールに組み込んでください。
AI で速く整え、人間が深く判断する。 Vigilance はこの分担が最も重要な領域です。
FAQ
Q1. AI が「報告対象」と判定したら、そのまま当局に提出していいですか？ A. 絶対にNGです。EU MDR では PRRC（Person Responsible for Regulatory Compliance） が、日本では 安全管理責任者・国内品質業務運営責任者 が報告判定の最終責任を負います。AI の出力はあくまでトリアージ補助とドラフトであり、医学的因果評価・Seriousness 判定・Reportability 判定は規制有資格者が必ずレビューしてください。
Q2. 報告期限の起算日（Awareness Date）はAIで判定できますか？ A. Awareness Date（メーカーが事象を認識した日）は法的に重要な日付ですが、社内のどの時点で「認識した」とみなすかは社内SOPと法的解釈に依存します。AI にタイムスタンプの整理は任せられますが、起算日の確定は人間が行ってください。MDCG 2023-3 でも「最初に従業員が事象に気づいた時点」とされており、社内で誰が・いつ・何を知ったかを慎重に判断する必要があります。
Q3. FSCA（Field Safety Corrective Action）と FSN（Field Safety Notice）の関係は？ A. FSCA はメーカーが市販後にとる是正措置（リコール・修正・使用制限など）の総称で、FSN は FSCA をユーザー・患者に通知する文書です。EU MDR Article 87(1)(b) に基づき FSCA を実施する場合、所管当局への報告と FSN の配布が必要です。AI で FSN ドラフトの構造化は可能ですが、内容の正確性は必ず人間が確認してください。
Q4. 日本のクラスIV不具合報告と EU MDR Vigilance は同じ手法で扱えますか？ A. 報告の枠組みは似ていますが、報告様式・期限・判断基準が異なります。日本の薬機法第68条の10 では「不具合等報告」として15日以内・30日以内の区分があり、EU MDR Article 87 の「Immediate（2日以内）/ 10日 / 15日」とは整合しません。AI で両方のドラフトを作る場合、それぞれ別プロンプトで管轄を明示してください。
Q5. Trend Report はどのタイミングで出すべきですか？ A. EU MDR Article 88 では、個別には報告対象外でも、頻度・重篤度が統計的に有意に増加した場合に Trend Report が必要です。閾値の設定はメーカーごとの PMS Plan で定義します。AI は過去データから統計的傾向の検出を補助できますが、「有意な増加」の判定基準とアラート発報の最終判断は安全管理部門が行います。
Q6. EUDAMED が完全稼働したら、AI で生成したドラフトはどう連携させますか？ A. EUDAMED Vigilance モジュールへの送信は XML/Web UI 経由となり、MIR（Manufacturer Incident Report）テンプレートに準拠した構造化データが必要です。AI で生成した本文を、MIR フィールド（A〜H 章）に手動またはスクリプトでマッピングする運用が現実解です。EUDAMED API 直接連携は2026年時点で各社の運用次第のため、要原典確認。
Q7. AI がハルシネーションで誤った IMDRF コードを出してきたら？ A. IMDRF Annex A（AE Terminology）は2024〜2025年にかけて改訂が進んでいます。Claude Code が出力したコードは 必ず IMDRF 公式の最新版で実在性を確認してください。AE / Health Effect / Device Component / Cause / Investigation Conclusion 等のコード体系は階層構造を持つため、コード番号だけでなく 意味（Term）も併記して人間がレビューすることを推奨します。
関連リソース
続きとして読むべき記事
- 医療機器 × AI 規制対応の全体像（ピラー記事）
- EU MDR の臨床評価報告書（CER）を Claude AI で設計
- PMDA 事前相談 Q&A を Claude AI で作る
- ISO 14971 リスクマネジメントファイル全体を Claude Code で構築
即実践できるテンプレート
🛠 ISO 14971:2019 リスクマネジメントファイル Excelテンプレート【AI活用対応版】¥29,800
Vigilance で得た知見を、リスクマネジメントファイルの「市販後情報」セクションに反映する流れを本テンプレートで設計できます。Vigilance ⇄ RMF の双方向ループの起点として活用ください。
note の短縮版
Vigilance（有害事象報告）対応を Claude Code で半自動化したら、夜中の電話が少し落ち着いた話（公開準備中）
※ 本記事の内容は筆者の個人的な実験・見解です。Vigilance Report の Reportability 判定および提出可否の最終判断は、EU MDR では PRRC（Article 15）、日本では安全管理責任者・国内品質業務運営責任者が必ず行ってください。AI の出力をそのまま当局に提出することは認められません。各社の品質管理手順および規制要件に従って適切なレビューを実施してください。