TL;DR EU MDR の市販後調査(PMS:Post-Market Surveillance)は、PMS Plan / PMS Report / PSUR / PMCF Plan の4文書を、リスククラス別の頻度で更新し続けるという、品質部門で最も継続コストの高い領域。Claude Code で「文書設計フェーズ」を構造化したところ、新規構築で約70〜80%、年次更新で約60%の工数削減を達成。ただし実データの統計解析・トレンド判断・最終結論の責任は人間。データ収集側(CRM / 不具合DB / Vigilance Report)との接続設計まで含めた実装ログ。
目次
- はじめに:PMS は「書いて終わり」では済まない最も継続コストの高い領域
- PMS の全体像(EU MDR Article 83-86)
- PMS Plan / PMS Report / PSUR / PMCF Plan の関係図
- リスククラス別の頻度・要件(Class IIa / IIb / III)
- Claude Code で何ができて何ができないか
- プロンプト設計 4要素
- 実際のプロンプト例:PMS Plan のテンプレート生成
- 出力例:PMS Plan の章立てと PSUR の Trend Analysis セクション
- データ収集側との接続(CRM / 不具合DB / Vigilance Report)
- 工数比較:新規構築と年次更新
- AI が苦手な点・限界
- 次の一手:ピラー記事と Vigilance 記事への接続
- FAQ
- 関連リソース
はじめに:PMS は「書いて終わり」では済まない最も継続コストの高い領域
医療機器の品質部門で、「一度書いて終わり」にできない文書があります。
PMS(Post-Market Surveillance、市販後調査)関連文書
CE 認証を取得した瞬間から、製品がカタログから消えるまで、ずっと更新し続ける必要がある。新規開発のドキュメントは「終わりが見える」けれど、PMS は終わりがない。これが PMS が品質部門で最も継続コストの高い領域と言われる理由です。
EU MDR(Regulation (EU) 2017/745)が完全適用されてからは、PMS の要求が劇的に厳しくなりました。MDD 時代の「不具合報告だけ」では通用しません。Article 83-86 で求められる PMS は、事前計画書(PMS Plan)→ 収集 → 評価 → 報告書(PSUR)→ 改善へのフィードバックまで、一気通貫の文書体系を要求します。
「PMS Plan を見せてください」と Notified Body に言われて、慌てて Excel をつぎはぎする会社、まだ多いです。
今回は Claude Code で PMS 文書一式の設計フェーズを構造化する実験を共有します。結論から言うと、新規構築で約70〜80%、年次更新で約60%の工数削減が実現できました。ただし「データ解析」と「最終結論」は人間の領域です。この境界線をどう引くかが本記事の核心です。
PMS の全体像(EU MDR Article 83-86)
EU MDR の PMS は、4つの条文を軸に組み立てられています。
| 条文 | タイトル | 内容 |
|---|---|---|
| Article 83 | Post-market surveillance system of the manufacturer | 製造業者は QMS の一部として PMS システムを構築する義務 |
| Article 84 | Post-market surveillance plan | PMS の実施計画書(PMS Plan)の作成義務(Annex III §1.1 参照) |
| Article 85 | Post-market surveillance report | Class I 機器向けの PMS Report の作成・更新義務 |
| Article 86 | Periodic safety update report (PSUR) | Class IIa / IIb / III 向けの PSUR の作成・更新義務 |
加えて Annex III が PMS の technical documentation を、Annex XIV Part B が PMCF(Post-Market Clinical Follow-up)を規定しています。
PMS が要求している思想
PMS は単なる「不具合報告制度」ではありません。EU MDR は以下の循環を要求しています。
[計画] PMS Plan で「何を集めて、どう評価するか」を事前に定義
↓
[収集] 不具合・苦情・文献・Vigilance・PMCF データを継続収集
↓
[評価] トレンド分析、ベネフィット・リスク再評価、CAPA 起動判定
↓
[報告] Class I → PMS Report、Class IIa-III → PSUR
↓
[フィードバック] CER 更新、RMF 更新、IFU 改訂、設計変更
↓
[計画] PMS Plan の更新へ戻る
この循環を文書として証明できないと、Notified Body のサーベイランス監査で**Major NC(重大不適合)**を取りに行きます。
PMS Plan / PMS Report / PSUR / PMCF Plan の関係図
4つの文書がどう関係するか、まずは1枚で整理します。
┌─────────────────────────────────────────────────┐
│ PMS Plan(Article 84) │
│ 「何を・どこから・どの頻度で集めて評価するか」 │
│ 全製品共通の計画書(Annex III §1.1) │
└─────────────────────────────────────────────────┘
│ │
↓ 収集の方針を継承 ↓ 臨床データ収集を委ねる
┌──────────────────────┐ ┌──────────────────────┐
│ 日常の収集・評価活動 │ │ PMCF Plan │
│ - 不具合・苦情 │ │ (Annex XIV Part B) │
│ - 文献サーベイ │ │ 市販後に追加で取得 │
│ - Vigilance │ │ する臨床データの計画 │
└──────────────────────┘ └──────────────────────┘
│ │
↓ 集約・トレンド分析 ↓ PMCF Evaluation Report
┌─────────────────────────────────────────────────┐
│ Class I → PMS Report(Article 85) │
│ Class IIa-III → PSUR(Article 86) │
│ Class III/Implantable → PSUR + EUDAMED 登録 │
└─────────────────────────────────────────────────┘
│
↓ アウトプットを反映
┌─────────────────────────────────────────────────┐
│ CER 更新 / RMF 更新 / IFU 改訂 / CAPA / 設計変更 │
└─────────────────────────────────────────────────┘
ポイントは 「PMS Plan は計画書、PSUR は報告書、PMCF Plan は別文書、PMS Report は Class I 専用」 という4つの位置づけを混同しないことです。
実務では「PMS Plan に PSUR の章立てを混ぜ込んでしまう」「PMCF Plan を PMS Plan の付録扱いにしてしまう」といった構造の崩れが、Notified Body 指摘の典型パターンです。
リスククラス別の頻度・要件(Class IIa / IIb / III)
PMS の要求は、リスククラスによって大きく異なります。
| クラス | PMS Plan | 報告書 | 更新頻度 | EUDAMED登録 | NB レビュー |
|---|---|---|---|---|---|
| Class I | 必須 | PMS Report(Article 85) | 必要に応じて更新 | 任意 | 不要 |
| Class IIa | 必須 | PSUR(Article 86) | 最低2年に1回 | 任意 | 不要 |
| Class IIb | 必須 | PSUR | 毎年 | 任意 | 不要 |
| Class IIb implantable | 必須 | PSUR | 毎年 | 必須 | 必須 |
| Class III | 必須 | PSUR | 毎年 | 必須 | 必須 |
※ 上記は EU MDR Article 86(1)-(2) の解釈に基づく整理です。条文の正確な原文・各国当局の解釈は要原典確認。
実務上のインパクト
Class IIb / III の製品を10品目持っている会社の場合、年間10本以上の PSUR を更新し続ける必要があります。1本あたり初版で40〜80時間、年次更新でも10〜20時間かかると言われており、これが品質部門のリソースを継続的に圧迫します。
ここに AI を入れる余地がある。
Claude Code で何ができて何ができないか
正直に整理します。
Claude Code でできること ✅
| 領域 | できること |
|---|---|
| 構造設計 | EU MDR / MDCG 準拠の章立て、目次、見出し階層の設計 |
| テンプレート生成 | PMS Plan / PSUR / PMCF Plan の文書テンプレ初稿 |
| 記述例の生成 | 各章のサンプル記述、定型文、参照条文の埋め込み |
| データ集計後の言語化 | 集計済みのトレンドデータを文章化(「Q3 において苦情件数は前期比 +12% で推移」など) |
| 整合性チェック | PMS Plan と PSUR、CER との用語・記述の整合性チェック |
| 多言語化 | 英語版 PSUR の起こし(日本語ドラフト → 英語化) |
| MDCG ガイダンス参照 | MDCG 2022-21 等の主要ガイダンスを踏まえた章立て提案 |
Claude Code でできないこと ⚠️
| 領域 | できない理由 |
|---|---|
| 生データの統計解析 | 生データを Claude Code に投入することは個人情報リスク・幻覚リスクから推奨できない。統計解析は専用ツール(R / Python / JMP)で実施 |
| トレンドの臨床的判断 | 「この有害事象の増加は CAPA を起動すべき水準か」の判断は、臨床的・薬事的経験を持つ人間の責任 |
| ベネフィット・リスクの再評価 | リスクとベネフィットの天秤は、製品知識・臨床知識・規制知識の総合判断。AI の出力を鵜呑みにできない |
| Vigilance 報告の判断 | 「これはセリアスインシデントとして当局報告すべきか」の判定は人間の責任。AI に任せられない |
| PSUR への最終署名 | PSUR は PMS 責任者・QA 責任者の署名文書。AI が出力した結論をそのまま採用することはできない |
境界線:「構造化・言語化」は AI、「データ解析・判断・責任」は人間
この境界を最初から明確にしておくことが、PMS への AI 導入を失敗させないコツです。
プロンプト設計 4要素
Claude Code に PMS 文書を生成させる際、必ず 4要素を含めます。
要素1: ロール(Role)
あなたは EU MDR 認証取得経験のある PMS 責任者です。
Notified Body のサーベイランス監査対応経験があり、
MDCG 2022-21(PSUR ガイダンス)と Annex III §1.1 を熟知しています。
「QA 担当者」「薬事担当」ではなく 「PMS 責任者」と明示することで、出力の語彙・視点が PMS 文脈に寄ります。
要素2: 規制コンテキスト(Regulatory Context)
対象規制: Regulation (EU) 2017/745 (EU MDR)
- Article 83: PMS system
- Article 84 & Annex III §1.1: PMS Plan
- Article 86: PSUR
- Annex XIV Part B: PMCF
参照ガイダンス: MDCG 2022-21(PSUR 推奨章立て)
条文番号と Annex を明示することで、AI が「どの条文に基づいて何を書くべきか」を出力に含められるようになります。
要素3: 製品コンテキスト(Product Context)
対象製品: 在宅用パルスオキシメータ(Class IIa)
測定原理: フォトプレチスモグラフィ(PPG)
意図された使用: 在宅で SpO2 と脈拍数を継続モニタリング
リスククラス: Class IIa(EU MDR Annex VIII Rule 10)
販売国: EU 27カ国 + EFTA
販売開始: 2024年6月
クラスを明示すると、AI は Class IIa の更新頻度(最低2年に1回) を踏まえた構成を出してくれます。
要素4: 出力フォーマット(Output Format)
出力フォーマット:
- Markdown 形式
- 章番号は MDCG 2022-21 推奨章立てに準拠
- 各章の冒頭に「目的」「該当条文」「必要な入力情報」を明記
- 表が必要な箇所は Markdown 表で表現
- 自信のない箇所は【要原典確認】タグを付与
「【要原典確認】タグを付与せよ」を最初に指示することが、ハルシネーション対策の決定打になります。
実際のプロンプト例:PMS Plan のテンプレート生成
実際に投げたプロンプトの一例。
# ロール
あなたは EU MDR 認証取得経験のある PMS 責任者です。
Notified Body のサーベイランス監査対応経験があり、
MDCG 2022-21(PSUR ガイダンス)と Annex III §1.1 を熟知しています。
# タスク
EU MDR Article 84 / Annex III §1.1 に準拠した PMS Plan のテンプレート初稿を作成してください。
# 製品コンテキスト
対象製品: 在宅用パルスオキシメータ(Class IIa)
測定原理: フォトプレチスモグラフィ(PPG)
販売国: EU 27カ国 + EFTA
販売開始: 2024年6月
# 規制コンテキスト
対象規制: Regulation (EU) 2017/745 (EU MDR)
- Article 83 / 84
- Annex III §1.1
- Annex XIV Part B(PMCF Plan は別文書として参照)
# 出力要件
- Markdown 形式
- 章立ては MDCG 2022-21 推奨構造を踏襲
- 各章: ①目的 ②該当条文 ③必要な入力情報 ④記述例(200字以内)
- 自信のない箇所は【要原典確認】タグを付与
- 最後に「データ収集源(CRM / 不具合DB / Vigilance / 文献)との接続表」を付録として追加
出力例:PMS Plan の章立てと PSUR の Trend Analysis セクション
PMS Plan の章立て(出力結果の抜粋)
| 章 | タイトル | 該当条文 | 主な内容 |
|---|---|---|---|
| 1 | Scope and Product Identification | Annex III §1.1(a) | 対象製品、UDI-DI、Basic UDI-DI、適用範囲 |
| 2 | Roles and Responsibilities | Article 15(PRRC)/ Article 83 | PMS 責任者、PRRC、QA、設計、サービスの役割分担 |
| 3 | Methods and Sources of Data Collection | Annex III §1.1(b) | 不具合・苦情・文献・Vigilance・PMCF・SNS・サービスログ |
| 4 | Indicators and Thresholds | Annex III §1.1(b) | KPI 定義、トレンド検知閾値、再評価トリガー |
| 5 | Methods of Data Analysis | Annex III §1.1(b) | 統計手法、頻度分析、Severity-Frequency マトリクス |
| 6 | Effective Communication with Authorities | Article 87-92 | Vigilance、FSCA、トレンド報告のフロー |
| 7 | Linkage to Risk Management (ISO 14971) | Annex III §1.1(c) | RMF へのフィードバックループ |
| 8 | Linkage to Clinical Evaluation (CER) | Annex III §1.1(c) | CER への反映、PMCF データの統合 |
| 9 | PMCF Plan Reference | Annex XIV Part B | PMCF Plan は別文書として参照 |
| 10 | PMS Output Documents | Article 85 / 86 | PMS Report(Class I)/ PSUR(Class IIa-III)の作成計画 |
| 11 | Update and Review Cycle | Article 84 | PMS Plan 自体の見直し頻度 |
| 12 | Appendix: Data Source Mapping | — | 各データ源と章の対応表 |
11章までで構造化された初稿が出てきたのは、正直「ここまで出るのか」という感想でした。
PSUR の Trend Analysis セクション(出力例)
PSUR の中でも難易度が高いのが 「トレンド分析(Trend Analysis)」 セクション。AI が出してきた構造はこんな感じです。
## 5. Trend Analysis
### 5.1 Methodology
- 集計期間: 2025年1月〜2025年12月(4半期ごと)
- 集計対象: 苦情件数、不具合カテゴリ、Severity 分布
- 統計手法: 移動平均、四半期比、前年同期比
- トレンド検知閾値: 前期比 +20% または絶対件数 +10件
### 5.2 Aggregated Data Summary
【要:社内集計済みデータの挿入】
| 指標 | Q1 | Q2 | Q3 | Q4 | 前年比 |
|---|---|---|---|---|---|
| 苦情件数 | — | — | — | — | — |
| 不具合: SpO2精度 | — | — | — | — | — |
| 不具合: 皮膚障害 | — | — | — | — | — |
| 不具合: 誤警告 | — | — | — | — | — |
### 5.3 Trend Interpretation
【要:PMS 責任者による臨床的解釈】
- 統計的に有意なトレンドが検知されたか
- 既知のリスク評価との整合性
- CAPA 起動・FSCA・Vigilance 通報の必要性
### 5.4 Conclusion and Actions
【要:QA 責任者の最終判断】
- ベネフィット・リスクの再評価結果
- 設計変更・IFU 改訂・追加 PMCF の要否
ポイントは 「【要:〇〇】タグで人間の介入箇所を明示してくる」 こと。これは設計フェーズの最大の効率化です。
データ収集側との接続(CRM / 不具合DB / Vigilance Report)
PMS Plan が機能するには、「どのシステムから何を吸い上げるか」 の接続設計が不可欠です。Claude Code で接続表を設計させると、こんな出力が得られます。
| データ源 | システム例 | 取得頻度 | 取得項目 | PMS 内での用途 |
|---|---|---|---|---|
| 苦情管理 | Salesforce / Zendesk / 自社CRM | 日次 | 苦情件数、製品ID、症状カテゴリ、患者影響 | PSUR §5.2、トレンド分析 |
| 不具合DB | TrackWise / 自社QMS | 日次 | 不具合件数、Severity、原因分類、CAPA 連動 | PSUR §5.2、§7(RMF連動) |
| Vigilance Report | EUDAMED 提出記録 | イベントごと | MIR 番号、Serious Incident、FSCA | PSUR §6、Article 87-92 連動 |
| 文献サーベイ | PubMed / Google Scholar / 自社文献DB | 四半期 | 関連論文、有害事象報告、競合製品インシデント | PSUR §4、CER 更新 |
| PMCF データ | PMCF Study DB / Survey ツール | 半年〜年次 | 臨床指標、患者報告アウトカム | PSUR §3、CER §10 連動 |
| サービスログ | Field Service System | 月次 | 修理件数、原因、再発率 | PSUR §5.2 |
| ソーシャル/レビュー | Amazon レビュー / SNS | 月次 | ネガティブレビュー、症状言及 | PSUR §3 補助情報 |
Claude Code に丸投げしてはいけないこと
接続表は AI が設計できますが、実データの吸い上げ・匿名化・集計は社内で行うのが鉄則です。
悪い例: CRM の苦情ログ(個人情報含む)をそのまま Claude Code に投げる 良い例: 社内で集計・匿名化した「Q3 の苦情カテゴリ別件数表」を Claude Code に渡し、文章化させる
特に EU の GDPR、日本の個人情報保護法を考えると、個人を特定できるデータは Claude Code に投入してはいけない。これは PMS への AI 導入における最重要ルールです。
工数比較:新規構築と年次更新
実験ベースの工数比較です。製品1品目あたり。
新規構築(PMS Plan + 初版 PSUR + PMCF Plan)
| 文書 | 従来 | AI活用後 | 削減率 |
|---|---|---|---|
| PMS Plan 初版 | 40〜80時間 | 8〜16時間 | 約80% |
| PSUR 初版 | 40〜80時間 | 12〜24時間 | 約70% |
| PMCF Plan 初版 | 30〜60時間 | 8〜16時間 | 約75% |
| データ収集設計(接続表) | 16〜32時間 | 4〜8時間 | 約75% |
| 合計(設計フェーズ) | 126〜252時間 | 32〜64時間 | 約75% |
| データ解析・最終レビュー | 40〜80時間 | 40〜80時間(変わらず) | — |
| 総合計 | 166〜332時間 | 72〜144時間 | 約56% |
年次更新(PSUR の毎年更新を想定)
| ステップ | 従来 | AI活用後 | 削減率 |
|---|---|---|---|
| 前年データの取り込み | 4〜8時間 | 1〜2時間 | 約75% |
| トレンド表の更新 | 8〜16時間 | 2〜4時間 | 約75% |
| 文章ドラフトの更新 | 8〜16時間 | 2〜4時間 | 約75% |
| 統計解析・解釈 | 8〜16時間 | 8〜16時間(変わらず) | — |
| 最終レビュー・署名 | 4〜8時間 | 4〜8時間(変わらず) | — |
| 合計 | 32〜64時間 | 17〜34時間 | 約47% |
新規構築の削減率(約56%)より年次更新(約47%)が低めなのは、年次更新では「データ解析・解釈」の比重が大きいためです。設計フェーズが大きい新規構築ほど、AI のインパクトが大きい。
AI が苦手な点・限界
正直に書きます。Claude Code で PMS をやってわかった「ここはダメ」ポイント。
苦手1: 実データの統計判断
集計済みの数値を渡せば文章化はできるが、「このトレンドは統計的に有意か」「閾値を超えているか」の数学的判断は AI に任せきれません。R や Python での解析、必要なら統計家のレビューを挟むのが安全です。
苦手2: 臨床的・薬事的判断
「この有害事象の増加は、設計に起因する可能性があるか」「FSCA を実施すべきレベルか」といった判断は、製品知識・臨床経験・規制経験の総合。AI は仮説を出せても、最終判断は人間の責任です。
苦手3: Vigilance 通報の判定
EU MDR Article 87 のセリアスインシデント定義に基づく通報判定は、規制違反リスクを伴う判断。AI に「通報すべき」と言わせて、それを根拠に意思決定するのは絶対に避けるべきです。
苦手4: 最新のガイダンス変更への追随
MDCG ガイダンスは継続的に更新されます。Claude の学習データは特定時点でカットオフされているため、最新の改訂版は人間が確認し、プロンプトに明示する必要があります。
苦手5: 個人情報を含む生データの扱い
GDPR / 日本の個人情報保護法の観点から、個人を特定できる症例データを Claude Code に投入してはいけません。投入してよいのは集計済み・匿名化済みのデータのみ。
次の一手:ピラー記事と Vigilance 記事への接続
PMS は単独では完結しない領域です。前後の文書群との接続が重要。
内部リンク設計
- 手前: EU MDR の臨床評価報告書(CER)を Claude AI で設計 — CER の §10 で PMCF 計画を参照する設計と本記事の PMCF Plan が連動
- 横: ISO 14971 リスクマネジメントファイル全体を Claude Code で構築 — PMS Plan §7 で RMF へフィードバックする接続点
- 次: Vigilance Report(MIR)を Claude Code で起こす実験は近日記事化予定
- ピラー: 規制産業 × AI 実装ガイド 2026年版 — 全体像から本記事に降りてくる導線
PMS の AI 導入ロードマップ
- Phase 1(今すぐ): PMS Plan / PSUR / PMCF Plan のテンプレ化を AI で構造設計
- Phase 2(3ヶ月): 集計済みデータの文章化を AI で半自動化
- Phase 3(6ヶ月): CRM / 不具合DB との接続を Workflow ツールで自動連携、AI に集計表を渡す
- Phase 4(1年): PSUR の年次更新を「差分更新ワークフロー」として確立、人間は判断とレビューに集中
これが現実的なロードマップです。
まとめ:PMS の「継続コスト」を AI で削れる時代に入った
PMS は 「終わりがない」 からこそ、AI による効率化のインパクトが累積します。新規構築で 50% 以上、年次更新で 40% 以上の削減が現実的に見えてきた今、「PMS 担当者を 1 人増やす前に、AI 設計フェーズを試す」 という選択肢が出てきました。
PMS の構造設計と言語化は AI が得意。 データ解析・判断・最終署名は人間の責任。
この境界線を引いたうえで AI を導入すれば、PMS は「品質部門の重荷」から「継続的な改善ループ」に変えられます。
FAQ
Q1. PMS Plan は CER や RMF と何が違うのですか? A. PMS Plan は「市販後にどんなデータを集めて、どう分析し、どこに反映するか」の事前計画書です。CER(臨床評価)は有効性・安全性の根拠を示す文書、RMF(リスクマネジメント)はリスクのコントロールを示す文書。PMS Plan は両者へデータを供給する「収集設計図」に位置づけられます。EU MDR Article 84 が要求する単独文書です。
Q2. PSUR の更新頻度はクラスごとにどう違いますか? A. EU MDR Article 86 では、Class IIa は「必要に応じて、最低2年に1回」、Class IIb と III は「毎年」PSUR を更新する義務があります。Class III と implantable は加えて EUDAMED への登録、Notified Body によるレビューも要求されます。詳細は要原典確認(Regulation (EU) 2017/745 Article 86(1)-(2))。
Q3. PMCF Plan は PMS Plan と別に作る必要がありますか? A. はい。EU MDR Annex XIV Part B が PMCF Plan を独立文書として要求しています。PMS Plan は不具合・苦情・文献などを含む「広いデータ収集計画」、PMCF Plan は「市販後に追加で取得する臨床データの計画」。PMS Plan の中で PMCF Plan を参照する形が一般的です。
Q4. Claude Code に実データを投入してもよいのですか? A. 個人を特定できる患者データ・症例データはそのまま投入しないでください。投入するのはあくまで匿名化済みの集計値・トレンド指標・カテゴリ分類のみ。個人情報を含む CRM ログや Vigilance Report の生データは、社内で集計・匿名化したうえで Claude Code に渡すワークフローを組むべきです。
Q5. AI が出力した PSUR をそのまま Notified Body に提出して大丈夫ですか? A. ダメです。PSUR は「製造業者の市販後評価としての結論」を含む文書であり、最終署名と責任は人間(PMS 責任者・QA 責任者)にあります。AI 出力は初稿フレーム・章立て・記述例として活用し、データ解釈・結論の妥当性は必ず専門家がレビュー・修正してください。
Q6. PMS Plan のテンプレートは公開されていますか? A. EU MDR / MDCG が公式テンプレートを発行しているわけではありません。MDCG 2022-21(PSUR 向けガイダンス)、Team-NB の PSUR position paper、Notified Body 各社のチェックリストを参照しながら自社で構築するのが標準的なアプローチです(要原典確認)。
Q7. Class I 機器でも PMS Plan は必要ですか? A. 必要です。EU MDR Article 83 / 84 はクラスを問わず PMS システムと PMS Plan を要求しています。Class I は PSUR ではなく PMS Report(Article 85)で報告しますが、Plan の要求は同じです。
関連リソース
続きとして読むべき記事
- 規制産業 × AI 実装ガイド 2026年版(ピラー記事)
- EU MDR の臨床評価報告書(CER)を Claude AI で設計
- EU MDR の STED を Claude AI で書く
- ISO 14971 リスクマネジメントファイル全体を Claude Code で構築
即実践できるテンプレート
🛠 ISO 14971:2019 リスクマネジメントファイル Excelテンプレート【AI活用対応版】¥29,800
PMS Plan §7(RMF 連動)の設計時、本テンプレートのリスクファイル構造とそのまま接続できる構成にしてあります。PSUR §5.3 のトレンド解釈と RMF の残留リスク再評価を一気通貫で扱えます。
参照ガイダンス(要原典確認)
- Regulation (EU) 2017/745 Article 83-86, Annex III, Annex XIV Part B
- MDCG 2022-21(PSUR 向けガイダンス)
- MDCG 2020-7 / 2020-8(PMCF 向けガイダンス)
- Team-NB Position Paper on PSUR
※ 本記事の内容は筆者の個人的な実験・見解です。EU MDR 対応については、認定 Notified Body および規制専門家に必ず相談してください。条文番号・更新頻度・要求事項の詳細は、必ず原典(Regulation (EU) 2017/745)および最新の MDCG ガイダンスで確認してください。