[{"data":1,"prerenderedAt":164},["ShallowReactive",2],{"blog-eqms-comparison":3,"related-blogs-eqms-comparison":41},{"id":4,"createdAt":5,"updatedAt":6,"publishedAt":7,"revisedAt":6,"title":8,"content":9,"eyecatch":10,"description":14,"reviewer":15,"category":28},"eqms-comparison","2026-10-26T01:49:38.024Z","2026-11-09T01:28:32.457Z","2026-11-09T01:15:45.666Z","eQMS（電子QMS）の選び方｜医療機器メーカー向け比較ガイド","\u003Cp>eQMS（電子QMS）とは、品質マネジメントシステムの文書・記録・教育訓練・CAPAなどをシステム上で一元管理する仕組みです。文書の版管理と配付を主目的とする文書管理システム（DMS）に対し、eQMSは文書と記録、さらに教育訓練や是正措置といったプロセス同士を紐付けて管理する点が異なります（導入メリットや段階導入の進め方は「\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Feqms-introduction\">電子QMS導入のメリットと課題\u003C\u002Fa>」で解説しています）。\u003C\u002Fp>\u003Cp>eQMSを選ぶ基準は、機能の多さではありません。\u003Cstrong>QMS省令とER\u002FES指針が求める要件を、自社のリスクと規模に見合う負担で満たせるか\u003C\u002Fstrong>が判断の軸です。本記事では製品名ではなく「4つの類型」と「10の評価軸」で比較し、RFPチェックリストと規模別の選び方まで整理します。\u003C\u002Fp>\u003Ch2 id=\"h926331b931\">結論：eQMS選定で外せない3つの判断基準\u003C\u002Fh2>\u003Cp>eQMS選定で外せない判断基準は、法令要件を仕組みで満たせるか、バリデーション負担がどこまで減るか、規模・製品に見合う範囲と費用か、の3つです。この3点で候補を絞り、操作性や価格の細部はその後に比べるのが失敗の少ない順序です。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>判断基準\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>確認すること\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>主な根拠\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>① 法令要件を仕組みで満たせるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>文書の版管理・承認、記録のセキュリティ確保と完全性の確保、監査証跡・アクセス制御・バックアップを、手作業ではなくシステムの機能で担保できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令第8条・第9条、施行通知 104．（7）、ER\u002FES指針\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>② バリデーション負担がどこまで減るか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ベンダーが提供する資料（要求仕様、テスト記録、変更時のリリース情報）と、自社が使用意図に沿って確認すべき範囲の切り分け\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令第5条の6\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>③ 規模・製品に見合う範囲と費用か\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>必要なモジュール、ユーザー数、保管期間を通じた総費用、解約時のデータ移行\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令第67条・第68条（保管期間）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>本記事の「施行通知」は、QMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令）の逐条解説である「医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令の一部改正について」（令和3年3月26日付 薬生監麻発0326第4号、令和7年1月31日付 医薬監麻発0131第1号により一部改正）を指します。以下、施行通知の項目番号は同通知「第2 逐条解説」の番号です。\u003C\u002Fp>\u003Ch2 id=\"h021a9b41d2\">eQMSの選択肢は4類型 — 紙・Excelから医療機器特化型までの比較\u003C\u002Fh2>\u003Cp>どの類型でもQMS省令への適合は可能ですが、\u003Cstrong>システムが担保しない要件は手順と人手で補う必要があり、その負担の大きさが類型ごとに異なります。\u003C\u002Fstrong>\u003C\u002Fp>\u003Ch3 id=\"hc37b431353\">類型1：紙・Excel・共有フォルダ運用\u003C\u002Fh3>\u003Cp>初期費用はほぼかかりませんが、記録の「セキュリティ確保」と「完全性の確保」（QMS省令第9条第2項）を手順で担保します。手順の例は施行通知 15．第9条関係（3）に示されています。Excelのように\u003Cstrong>記録を電子データのまま保管する場合\u003C\u002Fstrong>は、施行通知 104．（7）の措置（指定された作業者の認識、変更・削除の内容と理由・日時・作業者の記録、バックアップなど）も運用で補う必要があります。\u003C\u002Fp>\u003Ch3 id=\"h2277c42cbb\">類型2：汎用ファイル共有／汎用ワークフロー（グループウェア・電子承認）\u003C\u002Fh3>\u003Cp>文書の申請・承認だけを電子化する運用です。承認履歴は残りますが、SOP改訂の承認はワークフロー、再教育の記録は別のExcel、という分断が起きやすくなります。\u003C\u002Fp>\u003Ch3 id=\"h5c11a6fc1b\">類型3：汎用の文書管理SaaS（DMS）\u003C\u002Fh3>\u003Cp>業種を問わない文書管理クラウドです。文書そのものの管理機能は充実している一方、QMSプロセスは標準機能に含まれないことが一般的です。文書管理の要件そのものは「\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fdocument-management\">QMSの文書管理システムとは？\u003C\u002Fa>」で解説しています。\u003C\u002Fp>\u003Ch3 id=\"h70fe7002b6\">類型4：医療機器QMS特化型eQMS\u003C\u002Fh3>\u003Cp>QMS省令やISO 13485を前提に設計され、文書管理と教育訓練・苦情・CAPA・内部監査などのモジュールが連携します。使わないモジュールまで契約すると費用と定着の負担が増えるため、範囲の見極めが必要です。\u003C\u002Fp>\u003Ch3 id=\"hbe1b87b3d3\">【比較表】4類型 × 評価軸\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>評価軸\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>類型1 紙・Excel・共有フォルダ\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>類型2 汎用ワークフロー\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>類型3 汎用DMS（SaaS）\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>類型4 医療機器QMS特化型eQMS\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>版管理・承認履歴\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>手作業（改訂履歴表・押印）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認履歴は残る。版管理は別運用になりやすい\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>標準機能として備える製品が多い\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>標準機能として備える\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>監査証跡\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>手順と人手で担保\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認操作のみ記録されることが多い\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ファイル操作のログを備える製品が多い。変更理由の記録は製品により異なる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>変更内容・理由・日時・作業者の記録を前提に設計されていることが多い\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>なし（手書き署名・押印）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認ボタン。署名の意味の表示や記録との紐付けは製品により異なる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品により異なる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ER\u002FES指針・Part 11を意識した機能を持つ製品が多い（運用手順とセットで確認が必要）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>CAPA・教育訓練等の連携\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>手作業で紐付け\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象外が一般的\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象外が一般的\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>モジュール間で連携\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション負担\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>表計算の計算式等は自社で確認\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社で使用範囲を定義して確認\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社で確認。QMS前提の資料が乏しい場合がある\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ベンダー資料を活用でき、自社は使用意図に沿った確認が中心\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>初期・運用コスト\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>低い（人件費・保管コストは別）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>既存ツールの流用なら低い\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>中程度\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>相対的に高い\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社運用で手当てが必要な点\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第2項の手順、施行通知104．（7）の措置をすべて人手で\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認以外の版管理・記録管理・監査証跡\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMSプロセス（教育訓練・CAPA等）の管理、QMS前提のバリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>使わないモジュールの整理、契約・解約時のデータ取扱い\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>向いている企業の条件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>・承認者が数名で品目数が少ない\u003Cbr>・文書の改訂が年に数回程度\u003Cbr>・監査証跡を手順と人手で担保できており、査察で指摘を受けていない\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>・電子承認は回っている\u003Cbr>・CAPA・教育訓練の記録が別々のExcelに分散している\u003Cbr>・それらの紐付けを手作業で行っており、まだ負荷が許容範囲\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>・文書の版管理・検索が主な課題\u003Cbr>・CAPA・教育訓練は既存の仕組みで回っている\u003Cbr>・文書の電子化を先行させたい\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>・SOP改訂のたびに教育訓練の再実施と記録が発生する\u003Cbr>・査察や監査で記録の網羅性を一括提示する必要がある\u003Cbr>・苦情・不適合・CAPAの件数が増え、Excelでの追跡が限界に近い\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>「向いている企業の条件」が最も多く一致する類型が出発点の目安です。SOP改訂の頻度が上がる見込みがあるなら、類型4も比較対象に含めておきます。\u003C\u002Fp>\u003Ch2 id=\"hd6465c7294\">eQMSを比較する10の評価軸 — QMS省令・ER\u002FES指針との対応\u003C\u002Fh2>\u003Cp>各評価軸は「法令上の根拠」と「ベンダーに確認すること」をセットで押さえます。法令要件に結びつけておけば、機能一覧の多寡ではなく自社に必要な要件で候補を比べられます。\u003C\u002Fp>\u003Ch3 id=\"h9e2e2a3947\">法令要件との対応表\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>評価軸\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令（現行）\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知・指針\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ISO 13485:2016\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>① 版管理・改訂状況の識別\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第3号・第4号\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>14．第8条関係\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4.2.4\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>② 承認フロー・配付・廃止文書\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第1号・第2号・第6号・第8号、第3項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>14．第8条関係\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4.2.4\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>③ 記録管理\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第2項・第4項・第5項、第67条・第68条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>15．第9条関係、79．第67条関係、80．第68条関係\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4.2.5\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>④ 監査証跡・アクセス権限・バックアップ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第7号、第9条第2項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>14．第8条関係（8）、104．（7）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑤ 電子署名\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—（第8条関係の通知で参照）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>14．第8条関係（9）、ER\u002FES指針\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑥ モジュール範囲\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第23条第5号、第37条、第55条の2、第56条、第63条、第64条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>各条の関係項目\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>6.2、7.4.1、8.2.2、8.2.4、8.5.2、8.5.3\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑦ バリデーション支援の範囲\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>10．第5条の6関係\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4.1.6\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑧ クラウド・セキュリティ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第2項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>104．（7）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑨ 費用構造\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第67条・第68条（保管期間を通じた費用）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑩ 国産か海外製か\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>—\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3 id=\"h546a8dd702\">① 版管理・改訂状況の識別\u003C\u002Fh3>\u003Cp>QMS省令第8条第2項は、文書の管理方法として「変更内容及び最新の改訂状況が識別できるようにすること」（第3号）と「改訂版を利用できるようにすること」（第4号）を求めています。版の自動採番、改訂理由の記録、最新版だけが表示される仕組みを比べ、「旧版を参照した利用者に最新版の存在がどう示されるか」を確認します。\u003C\u002Fp>\u003Ch3 id=\"h9173ea8b73\">② 承認フロー・配付・廃止文書の管理\u003C\u002Fh3>\u003Cp>同じく第8条第2項は、発行時の照査・承認（第1号）、更新時の承認（第2号）、外部で作成された文書の識別と配付管理（第6号）、廃止文書の誤使用防止（第8号）を求めています。限定第三種医療機器製造販売業者を除き、変更は最初に承認した部門等に照査・承認させる必要があります（第3項）。文書ごとの承認者設定、外部文書の区別、廃止文書の識別を確認します。\u003C\u002Fp>\u003Ch3 id=\"h15129a2f3e\">③ 記録管理（セキュリティ確保・完全性の確保・検索・保管期間）\u003C\u002Fh3>\u003Cp>QMS省令第9条第2項は、記録の識別・保管・セキュリティ確保・完全性の確保・検索・保管期間・廃棄について手順の文書化を求め、完全性の確保を「記録が正確であり、記録が作成された時点から不適切な改変がない状態を保つこと」と定義しています。記録の検索性（第4項）と、第68条の保管期間（作成の日から5年、特定保守管理医療機器は15年。有効期間に1年を加えた期間がこれより長い場合はその期間。教育訓練は5年）を満たせるか、文書は第67条により廃止の日から同様の期間保管できるか、期間中の削除を防げるかを確認します。\u003C\u002Fp>\u003Ch3 id=\"h64e7f815cb\">④ 監査証跡・アクセス権限・バックアップ\u003C\u002Fh3>\u003Cp>記録を電子媒体で保管する場合の措置は、施行通知 104．（7）に示されており、そのまま確認リストとして使えます。\u003C\u002Fp>\u003Cul>\u003Cli>□ あらかじめ指定された作業者を認識し、指定外の者による入力・変更・削除を防止できる（104．（7）1）ア）\u003C\u002Fli>\u003Cli>□ 定められた手順によらない入力・変更・削除を禁止できる（同 イ）\u003C\u002Fli>\u003Cli>□ 入力・変更・削除の内容、変更・削除の理由、日時、作業者を特定する情報、入力を行った電子媒体等を特定する固有標識が記録される（同 ウ）\u003C\u002Fli>\u003Cli>□ バックアップを作成・保管できる（同 エ）\u003C\u002Fli>\u003Cli>□ 記録を印字・画面表示できる（104．（7）2））\u003C\u002Fli>\u003Cli>□ 保管方法・期間・場所・責任者、劣化防止と劣化時の措置を定められる（104．（7）3））\u003C\u002Fli>\u003C\u002Ful>\u003Cp>文書についても、施行通知 14．第8条関係（8）は、電磁的に管理する場合のバックアップ等の管理方法を、劣化・紛失防止（第8条第2項第7号）の例として挙げています。考え方は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fdata-integrity\">データインテグリティ（ALCOA+）の解説記事\u003C\u002Fa>で扱っています。\u003C\u002Fp>\u003Ch3 id=\"hb28ead7bf1\">⑤ 電子署名とER\u002FES指針・Part 11対応\u003C\u002Fh3>\u003Cp>施行通知 14．第8条関係（9）は、文書の電磁的管理の方法について、ER\u002FES指針「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（平成17年4月1日付 薬食発第0401022号）を参照することが望ましいとしています。署名者・日時・署名の意味（作成・照査・承認など）が表示されるか、署名が記録と切り離せないかを確認します。米国向け製品では21 CFR Part 11も対象です。要件の詳細は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fcfr-part11\">21 CFR Part 11の要件とベンダー確認項目\u003C\u002Fa>、ER\u002FES指針の内容は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fsoftware-validation-guide\">ソフトウェアバリデーション実践ガイド\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"h245b0f2952\">⑥ モジュール範囲（CAPA・教育訓練・内部監査・苦情・供給者管理）\u003C\u002Fh3>\u003Cp>教育訓練（第23条第5号）、供給者の評価・再評価（第37条）、苦情処理（第55条の2）、内部監査（第56条）、是正措置（第63条）、予防措置（第64条。限定第三種医療機器製造販売業者は適用除外）はいずれも記録を伴い、相互に参照し合います。これらを一続きで追えるのが一元管理の価値ですが、一括契約は使わない機能にも費用がかかるため、件数の多いプロセスから優先します。\u003C\u002Fp>\u003Ch3 id=\"he07be3aec3\">⑦ バリデーション支援の範囲\u003C\u002Fh3>\u003Cp>QMS省令第5条の6は、品質管理監督システムにソフトウェアを使用する場合、バリデーションの手順を文書化し（第1項）、初めて使用するとき及び変更するときに\u003Cstrong>あらかじめ\u003C\u002Fstrong>バリデーションを行い（第2項）、リスクに応じて実施し（第3項）、その記録を保管する（第4項）よう求めています。施行通知 10．第5条の6関係（2）は対象の例に「文書・記録の管理システム」と「苦情、不適合、是正・予防措置管理システム」を挙げており、文書管理とCAPA等を担うeQMSは典型的な対象です。\u003C\u002Fp>\u003Cp>ベンダー資料の範囲と自社が確認すべき範囲を切り分けます。SaaSでは\u003Cstrong>更新前にリリース内容と影響範囲が通知されるか\u003C\u002Fstrong>が、第2項の「あらかじめ」に対応できるかを左右します。施行通知 10．（4）は、表示上の変更や操作手順の合理化など品質等に影響しない変更について、①変更前にバリデーションが不要であることを文書で示すか、②あらかじめバリデーションを不要とする変更範囲を文書で明示しておけば、変更前のバリデーションを不要にできるとしています（この場合も変更後のバリデーションは必要です。第5条の6第2項ただし書）。更新頻度の高いSaaSでは、②の「不要とする変更範囲」を手順書で先に定めておくと、リリースのたびの判断負担を減らせます。手順の詳細は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fcsv-csa\">CSV・CSAの実務解説\u003C\u002Fa>で扱っています。\u003C\u002Fp>\u003Ch3 id=\"hce8af0fe72\">⑧ クラウド・セキュリティ\u003C\u002Fh3>\u003Cp>クラウド型では記録のセキュリティ確保（第9条第2項）を自社だけで完結できないため、保管場所・バックアップ・復旧手順・第三者認証などベンダーの管理体制を評価します。記録を印字・画面表示できる手段（施行通知 104．（7）2））と、障害時にその手段をどう確保するかも契約前に確認します。\u003C\u002Fp>\u003Ch3 id=\"h2e8ed01cc6\">⑨ 費用構造\u003C\u002Fh3>\u003Cp>費用は初期費用、ユーザー課金、モジュール課金、バリデーション支援・データ移行の別料金の組み合わせで決まります。第67条・第68条の保管期間は5年から15年以上に及ぶため、単年度ではなく\u003Cstrong>記録の保管期間を通じた総費用\u003C\u002Fstrong>で比べ、解約後に記録を閲覧する手段（データの書き出し、閲覧専用契約）も含めて評価します。\u003C\u002Fp>\u003Ch3 id=\"ha3be6dbd09\">⑩ 国産か海外製か\u003C\u002Fh3>\u003Cp>優劣ではなく「自社が主に対応する規制とサポートの必要性」で選ぶ軸です。国産では法令改正への追従や国内の適合性調査を想定した支援、海外製ではFDA・EU MDRへの対応や多言語対応を強みとする製品が多く、いずれも個別に確認が必要です。国内市場中心なら国産、海外向け製品の比重が大きいなら海外製を軸に比較します。\u003C\u002Fp>\u003Ch2 id=\"hf7080732bf\">要件定義・RFPチェックリスト — ベンダーに確認すべき項目\u003C\u002Fh2>\u003Cp>自社の要件をURS（ユーザー要求仕様）として書き出し、全候補に同じ質問を投げると、回答の差がそのまま比較表と稟議の根拠資料になります。\u003C\u002Fp>\u003Ch3 id=\"hc0c7e23752\">要件定義の進め方（3ステップ）\u003C\u002Fh3>\u003Col>\u003Cli>\u003Cstrong>現状の文書・記録を棚卸しする\u003C\u002Fstrong> — 文書・記録の種類・件数・保管場所を一覧にします。起点には\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fqms-required-documents\">QMSで必要な文書・記録のリスト\u003C\u002Fa>が使えます。\u003C\u002Fli>\u003Cli>\u003Cstrong>必須要件と希望要件を切り分ける\u003C\u002Fstrong> — 法令要件（評価軸①〜⑤⑦）に関わる項目は必須、操作性や外部連携は希望とします。\u003C\u002Fli>\u003Cli>\u003Cstrong>リスクに応じて重みを決める\u003C\u002Fstrong> — 品質や安全性に影響する記録を扱う機能ほど重く評価します（第5条の6第3項と同じ考え方）。\u003C\u002Fli>\u003C\u002Fol>\u003Ch3 id=\"h29e6fe85c6\">RFPチェックリスト（法令要件／機能／バリデーション／セキュリティ／費用／サポート）\u003C\u002Fh3>\u003Cp>そのまま質問票として使え、〇・△・×と補足で回答してもらう形式がおすすめです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>No\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>区分\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>確認項目\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>関連する根拠・評価軸\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>1\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>文書の変更内容と最新の改訂状況（版）を識別でき、改訂理由が記録されるか（版の自動採番の有無も確認）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第3号／①\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>利用者に最新版のみが表示され、旧版の誤使用を防げるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第4号・第8号／①\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>3\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>文書ごとに照査者・承認者・承認部門を設定できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第1号・第2号、第3項／②\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>外部文書（規格・顧客仕様等）を識別し、配付先を管理できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第6号／②\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>廃止文書を「廃止」と識別したまま保持できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8条第2項第8号／②\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>6\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>記録の保管期間を設定でき、期間中の削除を防止できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第5項、第68条／③\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>記録を条件指定で検索し、読みやすい形で表示できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第4項／③\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>8\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>指定された作業者以外の入力・変更・削除を防止できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知104．（7）1）ア／④\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>9\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>入力・変更・削除の内容・理由・日時・作業者が自動記録されるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知104．（7）1）ウ／④\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>10\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>監査証跡自体を利用者が修正・削除できない設計か\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知104．（7）1）イ・ウの趣旨／④\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>11\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令要件\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名に署名者・日時・署名の意味が表示され、記録と切り離せないか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ER\u002FES指針、Part 11／⑤\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>12\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>SOP改訂時に、対象者への教育訓練の割当てと実施記録が連動するか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第23条第5号／⑥\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>13\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>苦情からCAPAへの起票、CAPAから文書改訂への紐付けができるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第55条の2、第63条／⑥\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>14\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>内部監査の計画・指摘・是正の記録を管理できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第56条／⑥\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>15\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>必要なモジュールだけを選んで契約・追加できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑥⑨\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>16\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認フローを自社の組織・文書種別に合わせて設定できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>②\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>17\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>査察・監査時に、文書と関連記録を一括で提示・出力できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>③\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>18\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション用の資料（要求仕様、テストスクリプト、実施記録）が提供されるか。費用は別か\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6／⑦\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>19\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能更新の前に、リリース内容と影響範囲が通知されるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6第2項／⑦\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>20\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社の使用意図に沿った確認（設定値・承認フロー等）の支援範囲はどこまでか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6第3項／⑦\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>21\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>検証用の環境（本番と分離したテスト環境）が利用できるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑦\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>22\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>データの保管場所（国・リージョン）と、バックアップの頻度・保管先\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9条第2項／⑧\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>23\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>障害時の復旧目標と、記録を閲覧・印字する手段（障害時を含む）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知104．（7）2）／⑧\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>24\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>多要素認証、ロールベースの権限設定、パスワードポリシーの設定可否\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知104．（7）1）ア／④⑧\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>25\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>情報セキュリティに関する第三者認証の取得状況\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑧\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>26\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>費用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>初期費用、ユーザー課金、モジュール課金の内訳と最低契約期間\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑨\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>27\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>費用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>データ移行・教育・バリデーション支援の費用が含まれるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑨\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>28\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>費用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>解約時のデータ書き出し形式と費用、解約後の閲覧手段\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第67条・第68条／⑨\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>29\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>サポート\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>日本語でのサポート窓口・対応時間・マニュアルの有無\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑩\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>30\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>サポート\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令・施行通知の改正時に、機能やテンプレートがどう更新されるか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑩\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>31\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>サポート\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>適合性調査や監査でシステムの説明が必要になった際の支援内容\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>⑩\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3 id=\"hd3fd39969d\">選定時に確認すべきこと\u003C\u002Fh3>\u003Cp>回答書の「対応」は、自社の実際のSOPと記録様式を使った操作で確かめます。\u003C\u002Fp>\u003Cul>\u003Cli>□ 文書を改訂し、差戻し・再承認を経て最新版が公開されるまでの流れ\u003C\u002Fli>\u003Cli>□ その改訂に伴う監査証跡を、変更理由を含めて画面表示・出力できるか\u003C\u002Fli>\u003Cli>□ 承認済み文書を誤って編集しようとした場合に、どう制御されるか\u003C\u002Fli>\u003Cli>□ 過去の記録を、品目・期間・作成者などの条件で検索できるか\u003C\u002Fli>\u003Cli>□ SOP改訂から教育訓練の割当て・完了記録までが連動するか\u003C\u002Fli>\u003Cli>□ 権限のない利用者で、閲覧・編集できる範囲が正しく制限されるか\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"h140b0634eb\">規模・事業形態別のeQMSの選び方\u003C\u002Fh2>\u003Cp>eQMSの選び方は、規模と事業形態によって評価軸の重み付けが変わります。小規模・中堅・多拠点の3区分で、重視する軸を整理します。\u003C\u002Fp>\u003Ch3 id=\"hda02e96976\">小規模・スタートアップ（SaMD含む）\u003C\u002Fh3>\u003Cp>文書体系を作る段階からeQMSに載せると、後から紙・Excelの記録を移行する手間を避けられます。⑥（必要なモジュールだけで始められるか）、⑨（ユーザー数に応じた費用か）、⑦（ベンダー資料でバリデーション負担を減らせるか）を重く見ます。\u003C\u002Fp>\u003Cp>なお、限定第三種医療機器製造販売業者（限定一般医療機器のみを製造販売する製造販売業者）は、第5条の6第1項の括弧書きにより同条の適用から除かれますが、第8条（第3項を除く）・第9条の要求は適用されます。プログラム医療機器（SaMD）でも管理医療機器以上を扱うなら、この除外には該当しません。\u003C\u002Fp>\u003Cp>また、令和7年1月31日付の施行通知改正（令和7年4月1日適用）により、管理医療機器であるプログラム医療機器の製造販売のみを行う第二種医療機器製造販売業者のうち小規模企業者は、所定の研修修了と外部アドバイザーへの助言委託を条件に、ソフトウェア開発業務等の経験を国内品質業務運営責任者の「3年以上」の業務経験に含められるようになりました。体制づくりの初期段階で、教育訓練記録や外部アドバイザーとのやり取りを最初からeQMSに残しておくと、適合性調査で説明しやすくなります。\u003C\u002Fp>\u003Ch3 id=\"hcf1a35c9bf\">中堅メーカー（紙・Excelからの移行）\u003C\u002Fh3>\u003Cp>移行範囲を段階に分け、改訂頻度が高い文書管理から教育訓練、苦情・CAPAへと広げるのが現実的です。①〜④と、段階的に追加できる契約形態（⑥⑨）を重視し、既存記録の移行方法をRFPで確認します。\u003C\u002Fp>\u003Ch3 id=\"h929e50ea0e\">多拠点・海外展開（FDA／MDSAP）\u003C\u002Fh3>\u003Cp>⑤（電子署名とPart 11）と⑩（海外規制・多言語）の比重が大きくなります。米国では2026年2月2日に、ISO 13485:2016を引用する改正21 CFR Part 820（QMSR）が施行されました。MDSAPの監査を受ける場合は、複数の国の要求事項に関わる記録を監査時にまとめて提示できるかも確認します。あわせて、拠点ごとの権限分離、言語切替、拠点間のCAPA追跡を確認します。各国規制の全体像は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Foverseas-regulations\">海外規制の解説記事\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch2 id=\"hea8495e54a\">eQMS導入でよくある失敗パターンと回避策\u003C\u002Fh2>\u003Cp>失敗の多くは選定段階の誤解から生じ、査察で指摘を受けてから気づくことが少なくありません。段階導入やデータ移行の進め方は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Feqms-introduction\">電子QMS導入のメリットと課題\u003C\u002Fa>で扱っています。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>誤解・失敗\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>起きること\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>回避策\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>SaaSだからバリデーションは不要\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6の手順・記録がなく、適合性調査で指摘される\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ベンダー資料を活用しつつ、自社の使用意図での確認と記録を残す\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>「Part 11対応」「ER\u002FES対応」と書いてあれば適合\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>運用手順が伴わず、アクセス管理や署名の運用が形骸化する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機能と自社の運用手順をセットで評価する\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>全ての業務を一気に電子化\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>現場が混乱し、業務に支障が出ます\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>フェーズを区切って段階的に電子化を進める\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>既存文書をそのまま移行\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>版の混乱や重複文書をシステムに持ち込む\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>移行前に文書体系と版を整理する\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"hb8921a7087\">eQMSと文書管理システム（DMS）の違いは何ですか？\u003C\u002Fh3>\u003Cp>DMSは文書の版管理・承認・配付・検索が主な対象で、eQMSはそれに加えて教育訓練・苦情・CAPA・内部監査などの記録とプロセスを連携させます。文書の電子化だけが課題ならDMS、記録同士の紐付けまで課題ならeQMSが候補です。\u003C\u002Fp>\u003Ch3 id=\"hc0595d1746\">Excelや共有フォルダでもQMS省令に適合できますか？\u003C\u002Fh3>\u003Cp>Excelや共有フォルダでも、QMS省令に適合することは可能です。QMS省令は特定のシステムの使用を求めておらず、第8条・第9条の手順を文書化し、そのとおり運用することが基本です。ただし記録を電子データのまま保管する場合は、施行通知 104．（7）の措置を手順と人手で担保する必要があり、件数が増えるほど負担が増します。また、記録の管理にExcel等を使う場合は第5条の6の対象になり得るため、使用範囲とリスクに応じたバリデーション（計算式の確認など）とその記録も必要です。\u003C\u002Fp>\u003Ch3 id=\"h776882ad1f\">クラウド型eQMSのバリデーションは誰が実施しますか？\u003C\u002Fh3>\u003Cp>義務を負うのは、eQMSを使用する製造販売業者等です（QMS省令第5条の6）。ベンダーのテスト記録は活用できますが、自社の設定や使用意図に沿った確認と記録の保管は自社で行います。役割分担の詳細は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fcsv-csa\">CSV・CSAの実務解説\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"h5c7bd7a90a\">「Part 11対応」「ER\u002FES指針対応」のeQMSを使えば自動的に適合しますか？\u003C\u002Fh3>\u003Cp>「Part 11対応」「ER\u002FES指針対応」のeQMSを使っても、自動的には適合しません。電子記録・電子署名の要件は、システムの機能と、権限付与・パスワード管理・署名の運用といった自社の手順を組み合わせて満たすものです。Part 11の要件は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fcfr-part11\">21 CFR Part 11の解説記事\u003C\u002Fa>で整理しています。\u003C\u002Fp>\u003Ch3 id=\"h06ad3636ad\">小規模メーカーでもeQMSは必要ですか？\u003C\u002Fh3>\u003Cp>小規模メーカーでも、eQMSの導入は法令上の義務ではありません。承認者が数名で改訂頻度が低く、手順と人手で監査証跡を担保できているなら紙・Excelでも問題なく、SOP改訂と再教育の頻度が上がってきた時点が比較を始める目安です。\u003C\u002Fp>\u003Ch3 id=\"h0d17c0c9ad\">eQMSの導入にはどれくらいの期間と費用がかかりますか？\u003C\u002Fh3>\u003Cp>eQMSの導入期間は、モジュール数、移行量、バリデーションの範囲で大きく変わります。費用は初期費用、月額・年額、別料金の組み合わせで決まり、見積もり制のベンダーもあります。価格や条件は変更されることがあるため、最新の条件は各社の公式情報で確認してください。\u003C\u002Fp>\u003Ch2 id=\"hed721b1efe\">まとめ — 比較の軸を決めてからベンダーを選ぶ\u003C\u002Fh2>\u003Cp>eQMS選定で最も重要なのは、ベンダーを見る前に比較の軸を決めておくことです。\u003C\u002Fp>\u003Cul>\u003Cli>判断基準は「法令要件」「バリデーション負担」「規模に見合う範囲と費用」の3点\u003C\u002Fli>\u003Cli>4類型の比較表の「向いている企業の条件」で自社の出発点を判断する\u003C\u002Fli>\u003Cli>10の評価軸は、QMS省令第8条・第9条・第5条の6、施行通知 104．（7）、ER\u002FES指針に結びつけて確認する\u003C\u002Fli>\u003Cli>SaaSでもバリデーションは自社の義務。「Part 11対応」表記は運用手順とセットで評価する\u003C\u002Fli>\u003Cli>費用は記録の保管期間（第67条・第68条）を通じた総額で比べる\u003C\u002Fli>\u003C\u002Ful>\u003Cp>次の行動は、①棚卸し、②必須・希望要件の切り分け、③RFPでのベンダー比較、④自社SOPでのデモの順です。QMSのデジタル化をめぐる業界の動向は\u003Ca href=\"https:\u002F\u002Fyakuji-navi.com\u002Fblogs\u002Fqms-trend\">医療機器QMSの最新トレンド\u003C\u002Fa>でも紹介しています。\u003C\u002Fp>\u003Cp>候補の一つとして、当サイトを運営する株式会社Berryが提供する\u003Ca href=\"https:\u002F\u002Fservice.qm-smart.com\u002F?utm_source=yakuji-navi&utm_medium=link&utm_campaign=eqms-comparison\">\u003Cspan style=\"color: #005aff\">QMSmart\u003C\u002Fspan>\u003C\u002Fa>のように、文書のQMS省令・ISO 13485への適合性をAIでチェックする機能や、ソフトウェアバリデーションパッケージの無償提供を備えたeQMSもあります。比較の際は、本記事の評価軸とRFPチェックリストをそのまま当てはめて確認してください。\u003C\u002Fp>",{"url":11,"height":12,"width":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F608641648d7049a8a4cbfe67faebbb2c\u002Feqms-comparison.webp",941,1672,"医療機器メーカー向けにeQMS（電子QMS）の選び方を解説。紙・Excelとの違い、国産と海外製の比較ポイント、ベンダーに聞くべき要件チェックリスト、費用の考え方と公開価格の例、規模別の選び方、導入でよくある失敗例までまとめました。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":20,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},"nakano-hiroshi","2026-08-26T03:39:51.777Z","2026-08-26T06:00:24.072Z","中野 裕士",{"url":21,"height":22,"width":23},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002Fe46a86ad1efb41e1a5c9c79aa073373d\u002Fnakano.webp",1402,1122,"\u003Cp>東京工業大学大学院電子物理工学専攻修了。ITベンチャー、戦略コンサルティングファーム、医療機器ベンチャーを経て、株式会社Berryを創業。\u003C\u002Fp>\u003Cp>小児向け医療機器の設計開発から製造販売までを手がける医療機器製造販売業者の代表として、薬事承認の取得、QMS体制の立ち上げ、監査対応までを自ら一通り経験。ソフトウェアエンジニア出身の経歴を活かし、一品一様の製品における製造工程管理の課題を解決するため、医療機器メーカー向けクラウド型eQMSである「QMSmart」を自社開発。\u003C\u002Fp>","医療機器メーカー代表／QMSmart開発者","https:\u002F\u002Fwww.berryinc.co.jp\u002F#member","https:\u002F\u002Fservice.qm-smart.com\u002Finterviews\u002Fou0jrft6qi2",[29,33,37],{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},"ahi_3qbg7","2025-04-04T09:17:49.229Z","ソフトウェア",{"id":34,"createdAt":35,"updatedAt":35,"publishedAt":35,"revisedAt":35,"name":36},"li42d_41r","2024-10-22T03:22:45.239Z","文書管理",{"id":38,"createdAt":39,"updatedAt":39,"publishedAt":39,"revisedAt":39,"name":40},"data-integrity","2026-08-26T03:35:39.491Z","データインテグリティ",[42,70,92,107,122,138],{"id":43,"createdAt":44,"updatedAt":45,"publishedAt":46,"revisedAt":45,"title":47,"content":48,"eyecatch":49,"description":53,"reviewer":54,"category":56},"samd-qms","2026-08-26T03:31:05.649Z","2026-09-08T06:42:24.726Z","2026-08-31T13:37:35.762Z","SaMD（プログラム医療機器）の規制とQMSガイド","\u003Cp>SaMD（Software as a Medical Device、プログラム医療機器）は、ソフトウェア単体で医療機器として規制される製品カテゴリです。日本では薬機法上の「医療機器プログラム」として承認・認証の対象となり、開発企業にはQMS省令に基づく品質管理監督システムの構築が求められます。本記事では、医療機器該当性の判断からQMS構築の実務までを条番号と一次通知に基づいて整理し、令和7年4月1日から適用された小規模SaMD製造販売業者向けの国内品質業務運営責任者の要件拡張についても正確に解説します。\u003C\u002Fp>\u003Ch2 id=\"hfa40d95296\">SaMDの規制対応で押さえるべき5つの要点\u003C\u002Fh2>\u003Cp>SaMDの規制対応は「該当性の判断」「業許可と三役の設置」「承認・認証」「QMSの構築」「市販後の変更管理」の5工程に分解できます。ソフトウェア企業がつまずきやすいのは、QMS省令とJIS T 2304（IEC 62304）の関係、そして国内品質業務運営責任者の人選です。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>論点\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>結論\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>根拠\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>法令上の位置づけ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>「医療機器プログラム」として医療機器そのものに該当する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>薬機法第2条第13項\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>該当性の判断\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>表示・説明資料・広告等に基づき、\u003Cstrong>使用目的とリスクの程度\u003C\u002Fstrong>が医療機器の定義に該当するかで判断する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>該当性ガイドライン3\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令の適用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発（第30条〜第36条の2）を含め全面的に適用される\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>JIS T 2304との関係\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令の代替ではなく、上乗せで求められる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>基本要件基準第12条第2項\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>国内品質業務運営責任者\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>3年以上の経験要件は維持。小規模SaMD企業に限りカウントできる職種が拡張された\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>医薬監麻発0131第1号\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>本記事は2026年8月時点の法令・通知に基づきます。改正が続く領域のため、実務判断では厚生労働省・PMDAの一次情報を必ず確認してください。\u003C\u002Fp>\u003Ch2 id=\"he8782f3a8a\">SaMD（プログラム医療機器）とは\u003C\u002Fh2>\u003Cp>SaMDとは、ハードウェアに組み込まれず、ソフトウェア単体で医療機器としての機能を果たす製品です。日本の法令用語では「医療機器プログラム」および「プログラム医療機器」がこれに対応します。\u003C\u002Fp>\u003Cp>薬機法における「医療機器プログラム」の定義は、独立した定義条項ではなく\u003Cstrong>第2条第13項（「製造販売」の定義）の括弧書き\u003C\u002Fstrong>に置かれています。同項は製造販売を「…をし、又は輸入をした医薬品（原薬たる医薬品を除く。）、医薬部外品、化粧品、医療機器若しくは再生医療等製品を、それぞれ販売し、貸与し、若しくは授与し、又は医療機器プログラム（医療機器のうちプログラムであるものをいう。以下同じ。）を電気通信回線を通じて提供すること」と規定しています。物理的な引き渡しを伴わないダウンロード配信も製造販売として捉える条文構造になっており、その中で医療機器プログラムが定義されています。行政通知で使われる「プログラム医療機器」は、医療機器プログラム又はこれを記録した記録媒体たる医療機器を指します。\u003C\u002Fp>\u003Ch3 id=\"hff680da4d4\">SaMDとSiMDの違いは条文上も確認できる\u003C\u002Fh3>\u003Cp>SaMDと対比されるのがSiMD（Software in a Medical Device、組込みソフトウェア）です。両者の違いはQMS省令の「構成部品等」の定義に現れています。施行通知「2．第2条（定義）について（3）」は構成部品等を「…製品の一部となるもの及び\u003Cstrong>製品のソフトウェア（製品が法第2条第13項に規定する医療機器プログラムである場合を除く。）\u003C\u002Fstrong>」と説明しており、組込みソフトウェアは構成部品等、SaMDは製品そのものという扱いの違いが読み取れます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>観点\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>SaMD\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>SiMD\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品としての単位\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェア単体が医療機器\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ハードウェア医療機器の一部\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令上の扱い\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品そのもの\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>構成部品等（第2条第3項）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>提供形態\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電気通信回線を通じた提供、記録媒体\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ハードウェアに組み込んで出荷\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認・認証の単位\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>プログラム単位\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ハードウェア医療機器として\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>なお「SaMD」はIMDRF（International Medical Device Regulators Forum）による国際的な呼称で、日本の法令には登場しません。承認申請書や社内文書では「医療機器プログラム」「プログラム医療機器」を使います。\u003C\u002Fp>\u003Ch2 id=\"h65075b0529\">医療機器該当性の判断と上市までの規制ルート\u003C\u002Fh2>\u003Cp>自社ソフトウェアが医療機器に該当するかは「\u003Ca href=\"https:\u002F\u002Fwww.pmda.go.jp\u002Ffiles\u002F000240233.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">プログラムの医療機器該当性に関するガイドライン\u003C\u002Fa>」（令和3年3月31日付け薬生機審発0331第1号・薬生監麻発0331第15号。令和5年3月31日付け薬生機審発0331第1号・\u003Ca href=\"https:\u002F\u002Fwww.mhlw.go.jp\u002Fweb\u002Ft_doc?dataId=00tc7534&dataType=1&pageNo=1\" target=\"_blank\" rel=\"noopener noreferrer\">薬生監麻発0331第4号により一部改正\u003C\u002Fa>）で判断します。該当すれば製造販売業許可の取得と、承認または認証の手続きが必須になります。\u003C\u002Fp>\u003Ch3 id=\"h5885203cf0\">該当性は「使用目的」と「リスクの程度」で判断する\u003C\u002Fh3>\u003Cp>同ガイドラインは、該当性が「製造販売業者等による当該製品の表示、説明資料、広告等に基づき、当該プログラムの使用目的及びリスクの程度が医療機器の定義に該当するか」により判断されると定めています（「3 該当性の基本的考え方」）。同じ機能を有するプログラムであっても使用目的が異なれば判断は変わりうるため、開発の企画段階で、どのような表示・説明資料・広告を行うかまで含めて使用目的を設計することが実務上の要になります。なお、副作用または機能の障害が生じた場合でも人の生命及び健康に影響を与えるおそれがほとんどないプログラム（一般医療機器＝クラスIに相当するもの）は、医療機器の範囲から除かれます。\u003C\u002Fp>\u003Cp>リスクの程度は原則としてGHTFクラス分類ルールで判断しますが、同ルールでは判断し難い場合について、同ガイドライン「6 人の生命及び健康に影響を与えるリスクの程度の考え方」が次の2点を考慮するよう示しています。\u003C\u002Fp>\u003Col>\u003Cli>医療機器プログラムにより得られた結果の重要性に鑑みて疾病の治療、診断等にどの程度寄与するのか\u003C\u002Fli>\u003Cli>医療機器プログラムの機能の障害等が生じた場合において人の生命及び健康に影響を与えるおそれ（不具合があった場合のリスク）を含めた総合的なリスクの蓋然性がどの程度あるか\u003C\u002Fli>\u003C\u002Fol>\u003Cp>また同ガイドラインは、医療機器に該当しない典型的な事例として、患者説明を目的とするもの、院内業務支援・メンテナンスを目的とするもの、使用者が自らの医療・健康情報を閲覧等することを目的とするもの、生命及び健康に影響を与えるリスクが低いと考えられるものの4類型を挙げています。電子カルテやレセプト請求は原則非該当ですが、同じデータから解析結果を提示して診断を支援する機能を加えると該当性の検討が必要です。判断に迷う場合はPMDAの「医療機器プログラム総合相談」のうち「医療機器該当性に関する相談」を利用できます。\u003C\u002Fp>\u003Ch3 id=\"h7325960997\">業許可・クラス分類と二段階承認\u003C\u002Fh3>\u003Cp>上記のとおりクラスI相当のプログラムは医療機器の範囲から除かれるため、SaMDはクラスII（管理医療機器）以上が対象になります。認証基準があるものは登録認証機関の認証、ないものはPMDAの審査を経た承認です。クラス分類と承認・認証・届出の使い分けは\u003Ca href=\"\u002Fblogs\u002Fdevice-classification\">医療機器のクラス分類と承認・認証・届出の違い\u003C\u002Fa>で解説しています。製造販売業許可は扱う医療機器のクラスに応じて第一種・第二種・第三種に分かれ、クラスIIのSaMDのみを扱う企業は第二種医療機器製造販売業許可が必要です。許可要件には総括製造販売責任者・国内品質業務運営責任者・安全管理責任者の三役の設置が含まれます。\u003C\u002Fp>\u003Cp>SaMDは開発期間に比べ技術と外部環境の変化が速いため、制度面の手当ても進んでいます。「プログラム医療機器実用化促進パッケージ戦略（DASH for SaMD）」の第2弾として2023年9月に二段階承認の考え方が施策化され、「\u003Ca href=\"https:\u002F\u002Fwww.pmda.go.jp\u002Ffiles\u002F000265514.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">プログラム医療機器の特性を踏まえた二段階承認に係る取扱いについて\u003C\u002Fa>」（令和5年11月16日 医薬機審発1116第2号）が発出されました。PMDAも2024年7月1日に「プログラム医療機器審査室」を「プログラム医療機器審査部」へ組織改編し、審査員の増員により1チーム体制から領域別2チーム体制へ拡充しています。\u003C\u002Fp>\u003Ch2 id=\"h24a7f75733\">SaMDに求められるQMS ― QMS省令とJIS T 2304の関係\u003C\u002Fh2>\u003Cp>SaMDにもQMS省令は全面的に適用され、設計開発（第30条〜第36条の2）も例外ではありません。\u003Cstrong>JIS T 2304（IEC 62304）はQMS省令の代替ではなく、上乗せの要求\u003C\u002Fstrong>である、という理解が出発点になります。\u003C\u002Fp>\u003Ch3 id=\"hf00f68f3d8\">【よくある誤解】「SaMDはJIS T 2304だけでよい」は誤り\u003C\u002Fh3>\u003Cp>「QMS省令の設計開発はハードウェア中心の要求なので、単体プログラムはJIS T 2304に従えばよい」という説明を見かけますが、これは誤りです。正しくは次の2層構造です。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>QMS省令\u003C\u002Fstrong>：設計開発を「どう管理するか」を要求する。計画・入力・出力・照査・検証・バリデーション・移管・変更管理・記録簿の各条文が適用される\u003C\u002Fli>\u003Cli>\u003Cstrong>基本要件基準第12条第2項\u003C\u002Fstrong>：プログラムを用いた医療機器について、JIS T 2304への適合をもって同項への適合を確認したものとする（「医療機器の基本要件基準第12条第2項の適用について」薬生機審発0517第1号・平成29年5月17日。同項は平成29年11月25日から適用され、平成29年11月24日が経過措置期間終了日）\u003C\u002Fli>\u003C\u002Ful>\u003Cp>QMS省令の設計開発プロセスを構築したうえで、その中でJIS T 2304のライフサイクルプロセスを回す必要があります。国際的に認知された他の適切な規格による場合は、その妥当性を承認・認証申請で説明することとされています。\u003C\u002Fp>\u003Ch3 id=\"h14221ce940\">設計開発の条文とソフトウェア開発の対応\u003C\u002Fh3>\u003Cp>設計開発そのものの基礎は\u003Ca href=\"\u002Fblogs\u002Fqms-design-development\">QMSの設計開発とは？\u003C\u002Fa>で解説しています。SaMD開発での論点は次のとおりです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>見出し\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>SaMD開発での論点\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ISO 13485:2016\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第30条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第4項（1号 段階／2号 照査／3号 検証・バリデーション・設計移管／4号 責任権限／5号 追跡可能性／6号 資源）を文書化。ソフトウェア開発計画と一体で作る\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.1／7.3.2\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第31条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発への工程入力情報\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェア要求仕様（SRS）が該当\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.3\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第32条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発からの工程出力情報\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第1項第3号の「出荷可否決定等基準」がリリース判定基準に相当\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.4\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第33〜35条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>照査／検証／バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>JIS T 2304のソフトウェア検証とは対象が異なる。用語の対応を社内で定義する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.5〜7.3.7\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第35条の2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計移管業務\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>（実務解釈）SaMDでは「実際の製造」がビルド・配布のプロセスに相当すると整理できる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.8\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発の変更の管理\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>変更により製品標準書（第7条の2）と記録簿の見直しが生じる（施行通知44．第36条関係（7））\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.9\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条の2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>設計開発に係る記録簿\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知45．（3）が「ソフトウェアの検証及びバリデーション結果」を明記。同（4）でDHFに相当と説明\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.10\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>ソフトウェア安全クラス分類やライフサイクルプロセスの詳細は\u003Ca href=\"\u002Fblogs\u002Fiec-62304\">IEC 62304入門：医療機器ソフトウェアライフサイクル\u003C\u002Fa>を参照してください。あわせてISO 14971（リスクマネジメント）、IEC 62366（\u003Ca href=\"\u002Fblogs\u002Fusability\">医療機器のユーザビリティとは？\u003C\u002Fa>）への対応が必要です。\u003C\u002Fp>\u003Cp>サイバーセキュリティについては、基本要件基準第12条第3項が「\u003Cstrong>プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用するもの、又は外部からの不正アクセス等が想定されるもの\u003C\u002Fstrong>」を対象としています。オンラインで提供されるSaMDはほぼ該当すると考えてよいものの、要求は無条件ではなく、この適用範囲に当たるかをまず判定してください。該当する場合はJIS T 81001-5-1への適合をもって同項への適合を確認します。関連通知は二層構造で、取扱い通知（令和5年3月31日 薬生機審発0331第8号）が条項の解釈を示し、適合性確認通知（令和5年5月23日 薬生機審発0523第1号）が申請時に示すべき資料を具体化しています。既存品目についても、令和6年4月1日以降に製造販売を継続するのであれば改正後の基本要件基準への適合を確認しておく必要があります。\u003C\u002Fp>\u003Ch3 id=\"h36106699a4\">【混同注意】QMS省令第5条の6は「製品のソフト」ではない\u003C\u002Fh3>\u003Cp>QMS省令第5条の6（ソフトウェアの使用）はSaMDそのものへの要求ではなく、\u003Cstrong>品質管理監督システムの運用に使うソフトウェアのバリデーション\u003C\u002Fstrong>を求める条文です。施行通知「10．第5条の6関係（2）」は対象例として基幹系情報システム（ERP・MES）、文書・記録の管理システム、CAD、苦情・不適合・是正措置および予防措置の管理システムを挙げ、経理処理や事務処理用のソフトウェアは対象外と明記しています。\u003C\u002Fp>\u003Cp>同条はバリデーション手順の文書化（第1項）、初回使用時と変更時の事前バリデーション（第2項）、リスクに応じた実施（第3項）、記録の保管（第4項）で構成されます。実務は\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation\">QMSのソフトウェアバリデーションとは？\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch2 id=\"h23cd983603\">【令和7年4月適用】小規模SaMD製造販売業者は国内品質業務運営責任者の要件が拡張された\u003C\u002Fh2>\u003Cp>令和7年（2025年）4月1日から、一定要件を満たす小規模なSaMD企業に限り、国内品質業務運営責任者としてカウントできる職務経験の範囲が拡張されました。\u003Cstrong>3年以上の実務経験という要件そのものが免除されたわけではありません。\u003C\u002Fstrong> 変わったのは「どの職務経験を3年としてカウントできるか」であり、研修の修了と外部アドバイザーへの委託が条件になります。\u003C\u002Fp>\u003Cp>根拠は令和7年1月31日 医薬監麻発0131第1号で、改正されたのは施行通知の逐条解説「84．第72条（国内品質業務運営責任者）関係（3）」です。背景には規制改革実施計画（令和6年6月21日閣議決定）の「スタートアップ等によるSaMDの開発及び生産を円滑化する観点から」という要請があります。\u003C\u002Fp>\u003Cp>QMS省令第72条第1項第2号は国内品質業務運営責任者の要件として「品質管理業務その他これに類する業務に\u003Cstrong>三年以上\u003C\u002Fstrong>従事した者であること」を定めています。従来この要件に該当する者は、施行通知84．（3）が示す1)〜6)の類型（第一種医療機器製造販売業者は1)〜5)まで、第二種・第三種医療機器製造販売業者および体外診断用医薬品製造販売業者は1)〜6)まで）に限られていました。具体的には、1) 管理監督者、2) 管理責任者、3) 医療機器等総括製造販売責任者、4) 旧法下における品質保証責任者・製造管理者・責任技術者、5) 製造販売業者または製造業の製造管理・品質管理に係る業務に従事した者、6) ISO 9001またはISO 13485の認証を受けた事業者等（製品の製造販売または製造を行うものに限り、サービス提供等のみを行うものを除く）に係る品質マネジメントシステムの継続的改善または維持に係る業務に従事した者、です。\u003C\u002Fp>\u003Ch3 id=\"he3d091c8a1\">対象となる企業の3条件\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>#\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>要件\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>1\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>管理医療機器であるプログラム医療機器（薬機法第2条第13項に規定する医療機器プログラム又はこれを記録した記録媒体たる医療機器）の製造販売\u003Cstrong>のみ\u003C\u002Fstrong>を行うこと\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第二種医療機器製造販売業者であること\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>3\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>中小企業基本法（昭和38年法律第154号）第2条第5項の小規模企業者であること（おおむね常時使用する従業員20人以下。商業またはサービス業を主たる事業とする場合は5人以下）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>実務上の分岐点は3の判定です。同項の基準は原則として常時使用する従業員20人以下ですが、商業またはサービス業を主たる事業とする場合は5人以下となります。SaaSとしてSaMDを提供する事業者や受託開発を主業とする事業者は「サービス業」と整理される可能性があり、その場合の基準は5人以下です。日本標準産業分類上の主たる事業で判断されるため、\u003Cstrong>20人以下だからと自己判断せず、許可権者である都道府県に確認してください。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>さらに、通常の該当者（1)〜6)）を\u003Cstrong>国内品質業務運営責任者として置くことが困難な場合\u003C\u002Fstrong>に限られます。無条件の緩和ではありません。ハードウェア医療機器も扱う企業や、高度管理医療機器のSaMDを扱う企業は対象外です。\u003C\u002Fp>\u003Ch3 id=\"h9af9ee2565\">追加された3類型と研修\u003C\u002Fh3>\u003Cp>対象企業では、次の7)〜9)のいずれかに該当し、かつ厚生労働省が指定する研修を修了した者を置くことができます。いずれも3年以上の従事が必要で、この年数は自社・他社を問わず合計で構いません。\u003C\u002Fp>\u003Cul>\u003Cli>7) プログラム医療機器の製造販売業者または製造業者において、プログラム医療機器のプログラムの設計開発に係る業務に3年以上従事した者\u003C\u002Fli>\u003Cli>8) 同じく、プログラムの設計開発に係る業務および品質管理に係る業務に合わせて3年以上従事した者\u003C\u002Fli>\u003Cli>9) ソフトウェア開発に係る業務に主たる開発の責任者として3年以上従事した者\u003C\u002Fli>\u003C\u002Ful>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>研修科目（表1）\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>時間\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>一 薬機法その他関連法規／二 国内品質業務運営責任者の役割／三 医療機器及び体外診断用医薬品の製造管理及び品質管理の基準／四 体制省令（平成26年厚生労働省令第94号）・区分省令（同第95号）・QMS調査／五 医療機器の不具合報告制度・回収報告制度／六 医療機器の製造販売後安全管理の基準\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>8時間（表1の時間欄）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>受け皿として、公益財団法人医療機器センターが「SaMD製造販売業のための国内品質業務運営責任者研修」をeラーニングで実施しています（令和7年3月24日付け厚生労働省医薬局監視指導・麻薬対策課事務連絡により指定）。2026年8月時点の受講料は55,000円（税込）、全講義動画の視聴と修了テストの合格が修了要件です（\u003Ca href=\"https:\u002F\u002Fwww.jaame.or.jp\u002Fworkshop\u002Fcorp\u002Fqmsrelief\u002Ftop.html\">公益財団法人医療機器センター\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch3 id=\"h96c1e70ef3\">外部アドバイザーの要件と委託業務\u003C\u002Fh3>\u003Cp>7)〜9)の者を国内品質業務運営責任者とする場合は、表2の要件をすべて満たす外部アドバイザーとの間で契約を締結し、当該外部アドバイザーに表3の業務を委託することが求められます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>外部アドバイザーの要件（表2）\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>一 1)〜6)のいずれかの者として3年以上従事した者\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>二 国内の品質管理業務を適正かつ円滑に遂行しうる能力を有する者\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>三 他の製造販売業者の国内品質業務運営責任者を兼務していないこと（複数の小規模SaMD製造販売業者の外部アドバイザーの兼務は可能だが、各社の業務に支障を来さないこと）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>委託する業務内容（表3）\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>一 定期的に国内品質業務運営責任者と会議を実施するとともに、第72条第2項に係る業務を適切かつ遅滞なく遂行できるよう必要な指導、助言を行う\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>二 品質等に関する情報を得たときや回収を行うとき等、速やかな対応を要する場合に、対応が適切かつ迅速に行われるよう必要な指導、助言を行う\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>この取扱いは恒久措置ではありません。通知本文には「本運用は、医療機器業界において、ソフトウェア開発及び品質管理の両領域の知見を有する人材が充実するまでの間の\u003Cstrong>暫定的な運用\u003C\u002Fstrong>であり、…利用実態調査の結果等を踏まえ、取扱いを変更・廃止する際には、厚生労働省からその旨を連絡する」と明記されています。この枠組みで体制を組む場合も、社内で品質管理経験を積んだ人材を育てる計画を並行して持つべきです。\u003C\u002Fp>\u003Ch2 id=\"h15feb9af9a\">SaMDのQMS構築 6ステップとチェックリスト\u003C\u002Fh2>\u003Cp>SaMDのQMS構築は、該当性の確認から市販後対応まで6ステップで進めます。設計開発プロセスは既存の開発体制を土台にできる一方、文書・記録の管理と市場出荷判定の仕組みはゼロから作るのが通例です。\u003C\u002Fp>\u003Col>\u003Cli>\u003Cstrong>該当性の確認\u003C\u002Fstrong>：該当性ガイドラインで自己判断し、判断が割れる場合はPMDA相談を利用する\u003C\u002Fli>\u003Cli>\u003Cstrong>業許可と三役の設置\u003C\u002Fstrong>：製造販売業許可の申請と三役の選任。国内品質業務運営責任者の人選に困った場合は前セクションの枠組みが使えるか確認する\u003C\u002Fli>\u003Cli>\u003Cstrong>QMS文書体系の整備\u003C\u002Fstrong>：品質管理監督システム基準書（第7条）、製品標準書（第7条の2）、各手順書と記録様式を整備する\u003C\u002Fli>\u003Cli>\u003Cstrong>設計開発プロセスの構築\u003C\u002Fstrong>：第30条〜第36条の2の要求を満たす手順にJIS T 2304、ISO 14971、IEC 62366を組み込む\u003C\u002Fli>\u003Cli>\u003Cstrong>QMS適合性調査への対応\u003C\u002Fstrong>：承認・認証の申請に伴い、PMDAまたは登録認証機関の調査を受ける\u003C\u002Fli>\u003Cli>\u003Cstrong>市販後の運用\u003C\u002Fstrong>：不具合報告、市場への出荷判定、アップデートの変更管理とサイバーセキュリティ対応を回す\u003C\u002Fli>\u003C\u002Fol>\u003Cp>ステップ3で多くの企業が直面するのが文書・記録の管理です。SaMD開発チームはソースコードのバージョン管理には慣れていても、QMS省令第8条（品質管理監督文書の管理）が求める改訂状況の識別や最新版の利用可能性、第9条（記録の管理）が求める記録の完全性の確保を、汎用のクラウドストレージや表計算ソフトで満たすのは容易ではありません。医療機器QMSに特化した電子QMSであれば版管理・承認履歴・監査証跡が標準機能として備わり、少人数のチームでも適合状態を維持しやすくなります。\u003Ca href=\"https:\u002F\u002Fservice.qm-smart.com\u002F?utm_source=yakuji-navi&utm_medium=link&utm_campaign=samd-qms\">QMSmart\u003C\u002Fa>のような電子QMS自体も第5条の6にいう「品質管理監督システムに使用するソフトウェア」に当たるため、選定時にはバリデーションの支援体制も確認しておくとよいでしょう。\u003C\u002Fp>\u003Ch3 id=\"ha32c938f8d\">SaMDのQMS立ち上げチェックリスト\u003C\u002Fh3>\u003Cul>\u003Cli>[ ] 表示・説明資料・広告等に基づく使用目的とリスクの程度から該当性を検討し、根拠を文書化した\u003C\u002Fli>\u003Cli>[ ] クラス分類と、承認・認証のいずれのルートかを確定した\u003C\u002Fli>\u003Cli>[ ] 三役の候補者が要件を満たすか確認した\u003C\u002Fli>\u003Cli>[ ] 国内品質業務運営責任者が第72条第1項第2号の3年要件を満たすか、満たさない場合に令和7年改正の枠組みが使えるかを判定した\u003C\u002Fli>\u003Cli>[ ] 品質管理監督システム基準書（第7条）と製品標準書（第7条の2）を作成した\u003C\u002Fli>\u003Cli>[ ] 設計開発手順書が第30条第4項の6項目をすべて文書化している\u003C\u002Fli>\u003Cli>[ ] 工程出力情報（第32条）に出荷可否決定等基準を含めた、または参照可能にした\u003C\u002Fli>\u003Cli>[ ] 要求とテストのトレーサビリティを確保する仕組みを整備した（第30条第4項第5号）\u003C\u002Fli>\u003Cli>[ ] 設計開発に係る記録簿（第36条の2）にソフトウェアの検証・バリデーション結果を含めた\u003C\u002Fli>\u003Cli>[ ] アップデート時の変更管理手順に、製品標準書と記録簿の見直しを組み込んだ\u003C\u002Fli>\u003Cli>[ ] QMS運用に使うソフトウェアについて第5条の6のバリデーション手順を文書化した\u003C\u002Fli>\u003Cli>[ ] 市場への出荷判定（第72条第2項第3号）の手順と記録様式を整備した\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"hd69c13e30c\">SaMDとSiMDは何が違いますか？\u003C\u002Fh3>\u003Cp>SaMDはソフトウェア単体で医療機器に該当するもの、SiMDはハードウェア医療機器に組み込まれたソフトウェアです。日本の法令上、SaMDは「医療機器プログラム」として製品そのものとして扱われ、SiMDはQMS省令第2条第3項の「構成部品等」に含まれます。施行通知2．第2条（定義）について（3）は構成部品等の定義から医療機器プログラムを明示的に除外しており、扱いの違いが条文上も確認できます。\u003C\u002Fp>\u003Ch3 id=\"h1380bc2e4e\">健康管理アプリは医療機器プログラムに該当しますか？\u003C\u002Fh3>\u003Cp>原則として非該当ですが、機能によっては該当します。該当性ガイドラインは「使用者が自らの医療・健康情報を閲覧等することを目的とするプログラム」と「生命及び健康に影響を与えるリスクが低いと考えられるプログラム」を該当しない典型例に挙げています。ただし取得データを解析して診断や治療方針の判断に用いる機能を加えると該当性の検討が必要です。\u003C\u002Fp>\u003Ch3 id=\"hfdaf90259e\">SaMDにもQMS省令はすべて適用されますか？\u003C\u002Fh3>\u003Cp>適用されます。SaMDは医療機器そのものであるため、設計開発（第30条〜第36条の2）についてもソフトウェアだからという理由で適用が外れることはありません。滅菌や清浄度管理のように製品の性質上該当しない条文はありますが、適用除外は製品特性に基づいて個別に判断し、根拠を文書化しておく必要があります。\u003C\u002Fp>\u003Ch3 id=\"h22f3d4e740\">JIS T 2304に適合すればQMS省令の設計開発要求は満たせますか？\u003C\u002Fh3>\u003Cp>満たせません。JIS T 2304はQMS省令の代替ではなく、基本要件基準第12条第2項に基づく上乗せの要求です（薬生機審発0517第1号。同項は平成29年11月25日から適用）。QMS省令が設計開発を「どう管理するか」を定め、JIS T 2304がソフトウェアライフサイクルプロセスの中身を定めるという関係にあり、両方を満たす手順書が必要です。\u003C\u002Fp>\u003Ch3 id=\"h980eb1faeb\">品質管理業務の経験が3年ない人を国内品質業務運営責任者にできますか？\u003C\u002Fh3>\u003Cp>原則としてできません。QMS省令第72条第1項第2号の3年以上という年数要件は令和7年の改正後も維持されています。変更されたのは、管理医療機器であるプログラム医療機器の製造販売のみを行う第二種医療機器製造販売業者のうち小規模企業者に限り、プログラムの設計開発やソフトウェア開発責任者としての3年以上の経験もカウントできるようになった点です。所定の研修の修了と外部アドバイザーへの委託が条件で、通常の該当者を置くことが困難な場合に限られます。\u003C\u002Fp>\u003Ch3 id=\"h86b3bf6bdd\">SaMDのアップデートのたびに承認申請が必要ですか？\u003C\u002Fh3>\u003Cp>変更の内容によります。承認事項に該当する変更であれば手続きが必要になるため、変更が承認事項に当たるかを個別に評価する仕組みを、設計開発の変更管理手順（QMS省令第36条）に組み込んでおく必要があります。判断に迷う変更はPMDAへの相談を検討してください。設計開発の変更に伴い製品標準書（第7条の2）と設計開発に係る記録簿（第36条の2）の見直しが生じる点も、施行通知44．第36条関係（7）で示されています。\u003C\u002Fp>\u003Ch2 id=\"ha214098e44\">まとめ\u003C\u002Fh2>\u003Cp>SaMDの規制対応は、該当性の判断から業許可と三役の設置、承認・認証、QMSの構築、市販後の変更管理へと連なる一連のプロセスです。最も誤解されやすいのがQMS省令とJIS T 2304の関係で、JIS T 2304は基本要件基準第12条第2項に基づく上乗せの要求であり、QMS省令の設計開発要求を代替するものではありません。\u003C\u002Fp>\u003Cp>人の面では、令和7年4月1日から小規模SaMD製造販売業者に限り国内品質業務運営責任者の職務経験の範囲が拡張されました。ただし3年要件そのものは維持され、研修の修了と外部アドバイザーへの委託が条件で、かつ暫定的な運用とされています。仕組みの面では、文書の版管理と記録の完全性の確保に早い段階で手を打つことが、少人数の体制で適合状態を保つ近道になります。本記事の内容は2026年8月時点のものです。実務判断の際は厚生労働省・PMDAの最新の一次情報をご確認ください。\u003C\u002Fp>",{"url":50,"height":51,"width":52},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002Fd4554ce1fe5145709de19818d1cee998\u002Fsamd.webp",1024,1536,"SaMD（プログラム医療機器）の医療機器該当性の判断から承認・認証ルート、QMS省令とJIS T 2304の関係までを条番号付きで解説。令和7年4月適用の国内品質業務運営責任者の要件拡張と、QMS立ち上げチェックリストも掲載しています。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":55,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},{"url":21,"height":22,"width":23},[57,61,62,66],{"id":58,"createdAt":59,"updatedAt":59,"publishedAt":59,"revisedAt":59,"name":60},"samd","2026-08-26T03:35:38.342Z","プログラム医療機器",{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":63,"createdAt":64,"updatedAt":64,"publishedAt":64,"revisedAt":64,"name":65},"i9j-e9ygsax","2025-06-03T15:02:25.990Z","法規制",{"id":67,"createdAt":68,"updatedAt":68,"publishedAt":68,"revisedAt":68,"name":69},"t5sl3s5yi2","2025-06-10T00:30:26.259Z","医療機器",{"id":71,"createdAt":72,"updatedAt":73,"publishedAt":73,"revisedAt":73,"title":74,"content":75,"eyecatch":76,"description":78,"reviewer":79,"category":81},"csv-csa","2026-09-01T00:36:32.784Z","2026-09-08T05:18:13.583Z","CSVバリデーションとは？医療機器QMSのCSA実務","\u003Cp>CSV（コンピュータ化システムバリデーション）とは、業務に使用するコンピュータシステムが意図したとおりに機能することを検証し、その根拠を記録として残す活動です。医療機器メーカーにとっての根拠条文はQMS省令第5条の6（ソフトウェアの使用）であり、検索でよく出てくる医薬品向けのCSVガイドラインは適用されません。しかも省令と施行通知は、すでにリスクに応じた軽量化を明文で認めています。本記事では対象となるソフトウェアの切り分け、用途別の3条文マップ、実務5ステップ、GAMP 5 第2版とFDAのCSA（Computer Software Assurance）の使い方を、チェックリスト付きで整理します。\u003C\u002Fp>\u003Ch2 id=\"h4acb8e1b24\">CSV（コンピュータ化システムバリデーション）とは？医療機器QMSでの位置づけ\u003C\u002Fh2>\u003Cp>CSVはComputerized System Validationの略で、日本語では「コンピュータ化システムバリデーション」と呼ばれます。医療機器メーカーの場合、対象になるのは品質管理監督システム（QMS）の運用に使うソフトウェアで、根拠条文はQMS省令第5条の6（ソフトウェアの使用）です。表計算ファイルの拡張子であるComma-Separated Values（.csv）とは無関係の用語で、社内では正式名称で会話するほうが早く合意できます。\u003C\u002Fp>\u003Ch3 id=\"h0d6ba3a9cb\">対象は「QMSに使うソフトウェア」— 製品に組み込むソフトウェアとは別物\u003C\u002Fh3>\u003Cp>第5条の6の対象は、自社のQMSを動かすために使うソフトウェアです。医療機器そのものに該当するソフトウェアや製品に組み込むソフトウェアは対象が異なり、別の枠組みで検証します。\u003C\u002Fp>\u003Cp>施行通知（薬生監麻発0326第4号。令和7年1月31日一部改正後の版を参照しています）10．第5条の6関係（2）は、品質管理監督システムに使用するソフトウェアに含まれうるものと、対象にならないものを次のように示しています。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>区分\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェアの例\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象になりうる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製造のための指示などに関連する基幹系情報システム（ERP、MES）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象になりうる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>文書・記録の管理システム\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象になりうる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>CAD（コンピュータによる設計支援ツール）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象になりうる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>苦情、不適合、是正・予防措置管理システム\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>対象ではない\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>経理処理に使用されるソフトウェアや、事務処理に使用されるソフトウェア等の医療機器の品質、安全性又は有効性に影響しないソフトウェア\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>4種類は「含まれうるもの」として示された例示で、限定列挙ではありません。判断の軸は、そのソフトウェアが医療機器の品質、安全性又は有効性に影響するかどうかです。棚卸しの際は製品名ではなく「そのシステムでどのQMS記録を作っているか」で仕分けてください。なおERP・MESがここに挙げられているのは「製造のための指示などに関連する基幹系情報システム」としてであり、製品カテゴリとして第5条の6に固定されるわけではありません。使い方によっては第45条側になります（次の3条文マップを参照してください）。\u003C\u002Fp>\u003Cp>一方、医療機器製品に組み込むソフトウェアの検証は設計開発の枠組みで扱い、本記事の対象外です（\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation\">QMSのソフトウェアバリデーションとは？\u003C\u002Fa>、\u003Ca href=\"\u002Fblogs\u002Fiec-62304\">IEC 62304とは？\u003C\u002Fa>）。両者を混同したまま手順書を作ると、対象範囲の定義が破綻します。\u003C\u002Fp>\u003Ch3 id=\"ha4faa725bf\">法的根拠はQMS省令第5条の6（ソフトウェアの使用）\u003C\u002Fh3>\u003Cp>QMS省令第5条の6は全4項で構成され、手順の文書化・実施時期・リスクに応じた実施・記録の作成保管を求めています。施行通知10．第5条の6関係（1）は、この条がISO 13485:2016の「4.1.6」に相当すると示しています。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>第1項\u003C\u002Fstrong>: 当該ソフトウェアの適用に係るバリデーションについて手順を文書化する\u003C\u002Fli>\u003Cli>\u003Cstrong>第2項\u003C\u002Fstrong>: 初めて使用するとき、及び当該ソフトウェア又はその適用を変更するときは、あらかじめバリデーションを行う（変更前に行う必要がない正当な理由を示せる場合は変更後でも足りる）\u003C\u002Fli>\u003Cli>\u003Cstrong>第3項\u003C\u002Fstrong>: 第2項に規定するバリデーションを行うときは、使用に伴うリスク（当該ソフトウェアの使用が製品に係る医療機器等の機能、性能及び安全性に及ぼす影響を含む）に応じて行う\u003C\u002Fli>\u003Cli>\u003Cstrong>第4項\u003C\u002Fstrong>: 第2項のバリデーションから得られた記録を作成し、保管する\u003C\u002Fli>\u003C\u002Ful>\u003Cp>見落としやすい点が1つあります。第1項の括弧書きは「限定第三種医療機器製造販売業者（限定一般医療機器のみを製造販売する製造販売業者をいう。以下同じ。）を除く。\u003Cstrong>以下この条において同じ。\u003C\u002Fstrong>」としているため、この適用除外は第1項だけでなく第5条の6の全体に及びます。\u003C\u002Fp>\u003Cp>ここで最も誤りやすいのが、自社が本当にこの除外に当たるかの判定です。「一般医療機器を作っている＝限定一般医療機器を作っている」ではありません。限定一般医療機器はQMS省令第5条の5第3項が定義しており、「一般医療機器のうち製造管理又は品質管理に注意を要するものとして厚生労働大臣が指定する医療機器以外の医療機器」を指します。その大臣指定は平成26年厚生労働省告示第316号（平成26年8月6日。令和3年厚生労働省告示第104号により題名を改正）が定めており、指定対象は一般医療機器のうち「別表に掲げるもの及び製造工程において滅菌されるもの」です。つまり、別表に掲げられた一般的名称に当たる品目や、製造工程で滅菌する品目は限定一般医療機器ではなく、それらを製造販売していれば限定第三種医療機器製造販売業者にも当たりません。\u003C\u002Fp>\u003Cp>自社の該当性は2段階で判定してください。①自社品目の一般的名称を告示第316号の別表と突き合わせる、②製造工程に滅菌が含まれるかを確認する、の2つです。②は別表を見ただけでは分からないため、最も落としやすい条件です。告示の全文は厚生労働省の法令等データベースで閲覧できます。判断に迷う場合は都道府県の薬務主管課またはPMDAに確認してください。\u003C\u002Fp>\u003Cp>そして、\u003Cstrong>第5条の6の対象外であってもISO 13485:2016の4.1.6は別途要求されます。\u003C\u002Fstrong> QMS省令の適用除外は、ISO 13485の認証審査には及びません。第三者認証やISO 13485認証を維持している場合は、省令上の除外に当たっても4.1.6に基づくバリデーションの記録が必要になります。審査でソフトウェアのバリデーション記録を求められた場合は、要求の根拠となっている箇条を審査機関に確認したうえで対応してください。本記事の成果物の最小セットと導入前チェックリストは、省令上の除外に当たる場合でも4.1.6への対応にそのまま使えます。\u003C\u002Fp>\u003Cp>対象者についても補足が必要です。第5条の6は、第83条第1項により登録製造所に係る製造業者等（受託製造を行う登録製造所を含む）にも準用されます。同条第2項により、第5条の6第1項の「限定第三種医療機器製造販売業者」は「限定第三種医療機器製造業者等」と、「製造販売する製造販売業者」は「製造する登録製造所に係る製造業者等」と読み替えます。ただし第83条第1項ただし書きにより、当該製品について当該登録製造所が行う工程に照らし、その品質管理監督システムに適用することが適当でないと認められる規定は適用しないことができ、その場合は当該製品に係る品質管理監督システム基準書にその旨を記載しなければなりません。また輸出用の医療機器等に係る製品の製造業者についても、第82条第1項により準用されます。ERPや文書管理システムを使っている登録製造所が「自社は製造販売業者ではないから第5条の6は関係ない」と判断するのは誤りです。\u003C\u002Fp>\u003Ch3 id=\"ha8923ca422\">どのソフトウェアにどの条文が掛かるか（3条文マップ）\u003C\u002Fh3>\u003Cp>QMS省令はソフトウェアのバリデーションを用途別に3か所で要求しています。同じ「ソフトウェアのバリデーション」でも根拠条文が違うため、対象を取り違えると手順書と記録の置き場所を間違えます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェアの用途\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>根拠条文\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>手順\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>実施時期\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>リスク\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>記録\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ISO 13485:2016\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>品質管理監督システムに使用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第1項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第2項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第3項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第4項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4.1.6\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製造及びサービスの提供に使用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第45条第4項〜第7項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第4項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第6項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第7項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.5.6\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>監視及び測定に使用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第53条第8項〜第11項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第8項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第9項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第10項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第11項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.6\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>ISO 13485:2016の箇条との対応は施行通知10．第5条の6関係（1）、54．第45条関係（1）、61．第53条関係（1）に示されています。用語の意味も通知が説明しており、施行通知54．第45条関係（6）は第45条第4項の「ソフトウェアの適用に係るバリデーション」を、そのソフトウェアが意図した通りに適用されるかどうかを確認するものと説明しています。\u003C\u002Fp>\u003Cp>施行通知61．第53条関係（4）は、第53条第9項のバリデーションが適用される例として、製品の試験や工程の監視及び測定（パラメータが要求を満たしているか確認する等）等に使用するソフトウェアと、計測器とパソコンが接続され、計測器から計測した結果がパソコンに転送されて何らかの処理がなされる場合の2つを挙げています。試験室のパソコンに入っている解析ソフトが、最も見落とされやすい対象です。なお工程そのもののバリデーション（第45条第1項〜第3項）は本記事の対象外で、\u003Ca href=\"\u002Fblogs\u002Fprocess-validation\">QMSの製造工程バリデーションとは？\u003C\u002Fa>で解説しています（第45条第7項の記録要求は、工程側とソフトウェア側の双方に掛かる共通の項です）。\u003C\u002Fp>\u003Cp>判断の軸は、システムの製品名ではなく用途です。条文はそれぞれ「品質管理監督システムにソフトウェアを使用する場合」（第5条の6第1項）、「製造及びサービスの提供にソフトウェアを使用する場合」（第45条第4項）、「監視及び測定のためにソフトウェアを使用する場合」（第53条第8項）と書き分けています。区分はERPやMESといった製品カテゴリで決まるわけではなく、そのソフトウェアを何に使っているかで決まります。\u003C\u002Fp>\u003Cp>そして1つのシステムが複数の条文に跨がることは普通に起こります。MESであれば、工程指示や工程パラメータの制御に使う機能は第45条第4項〜第7項、そこで作った品質記録を管理監督する機能は第5条の6、試験結果の取得・処理に使う機能は第53条第8項〜第11項に分かれます。LIMSも、試験結果を取得・処理する機能は第53条側、試験記録の保管や承認ワークフローは第5条の6側です。機能単位で用途を書き出し、それぞれをどの条文に載せるかを決めてください。施行通知14．第8条関係（3）は、文書化が要求される手順書として1）品質管理監督システムに使用するソフトウェアの適用のバリデーション（第5条の6第1項）、14）製造工程等の提供に使用するソフトウェアの適用のバリデーション（第45条第4項）、21）測定等に使用するソフトウェアの適用のバリデーション（第53条第8項）を別個に列挙しており、記録の置き場所も第5条の6第4項／第45条第7項／第53条第11項に分かれます。\u003C\u002Fp>\u003Cp>省令にも施行通知にも、この切り分けの明文の基準はありません。参考になるのは、PMDAが掲載している厚生労働科学研究班のガイダンス（2020年2月作成。通知ではなく研究班の作成資料です）で、ISO 13485の箇条について「4.1.6項では7.5.6項・7.6項で求められる以外のQMSで用いられるソフトウェアが対象である」と整理しています。第45条・第53条に当たるものを先に切り出し、残りを第5条の6に置く、という順序で考えると迷いにくくなります。用途区分の判定に迷う場合も、都道府県の薬務主管課またはPMDAに確認してください。\u003C\u002Fp>\u003Ch3 id=\"h013fffad35\">医薬品のCSVガイドラインは医療機器には適用されない\u003C\u002Fh3>\u003Cp>\u003Cstrong>「CSV」で検索して最初に出てくる解説は、ほぼ医薬品向けのものです\u003C\u002Fstrong>。厚生労働省の「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」（薬食監麻発1021第11号／平成22年10月21日／平成24年4月1日適用）は、その「1．目的」で対象を「GMP省令の適用を受ける医薬品又は医薬部外品を製造販売する製造販売業者又は製造する製造業者等」と定義したうえで、「2．適用範囲」で「コンピュータ化システムを使用してGQP省令及びGMP省令が適用される業務を行う製造販売業者等に適用する」としています。名宛人がGMP省令の適用を受ける医薬品・医薬部外品の事業者に限られているため、\u003Cstrong>医療機器には適用されません。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>医療機器及び体外診断用医薬品はQMS省令（平成16年厚生労働省令第169号）が適用される別体系です。体外診断用医薬品は名称に「医薬品」を含みますが、GQP省令は品質管理業務の対象を「医薬品（体外診断用医薬品及び原薬たる医薬品を除く。）」、GMP省令も「医薬品（体外診断用医薬品を除く。）」と定義しており、いずれも体外診断用医薬品には適用されません。同ガイドラインの手法を参考にすることは可能ですが、そのまま持ち込むと省令が求めていない成果物まで作る過剰対応になります。逆に「医薬品の話だから関係ない」と読み替えて第5条の6への対応を落としているケースもあり、こちらはQMS適合性調査で指摘されます。なお電磁的記録・電子署名の取扱い（ER\u002FES指針）への対応方法は\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation-guide\">ソフトウェアバリデーション実践ガイド\u003C\u002Fa>で解説しており、本記事では扱いません。\u003C\u002Fp>\u003Cp>医薬品と医療機器の双方を扱う事業者は、この「適用されない」の射程に注意してください。\u003Cstrong>適用されないのはシステムに対してではなく、医療機器側の業務に対してです。\u003C\u002Fstrong> 同じシステムであっても、医薬品側の業務に使っている部分には引き続き医薬品側の要求が掛かります。文書管理システムやLIMSを両方の体系で共用している場合、医療機器側の手順だけに一本化すると、医薬品側で説明が立たなくなります。共用システムは、どちらの業務に使うかで適用される要求が変わるため、業務単位で対象を切り分けて手順に落としてください。医療機器側の対応を「医薬品の話だから関係ない」と落とすのも、医薬品側の対応を自社全体の結論として降ろすのも、どちらも誤りです。\u003C\u002Fp>\u003Ch2 id=\"h77526634a5\">QMS省令はすでに「リスクに応じた軽量化」を認めている\u003C\u002Fh2>\u003Cp>第5条の6第3項は、バリデーションを「使用に伴うリスクに応じて」行うことを求めています。これは労力を増やす要求ではなく、リスクが低いものには薄く、高いものには厚く配分してよいという趣旨です。\u003C\u002Fp>\u003Ch3 id=\"h61d11338e2\">第3項の趣旨は「管理の程度を定めること」\u003C\u002Fh3>\u003Cp>施行通知10．第5条の6関係（5）は、第3項について「バリデーション及び再バリデーションの実施は、当該ソフトウェアの使用によるリスクに応じて、管理の程度を定めることを意図したものである」と説明しています。つまり、すべてのシステムに同じ様式のテスト記録を作る必要はありません。\u003C\u002Fp>\u003Ch3 id=\"h707811b07e\">施行通知が示す軽量化の2つの根拠\u003C\u002Fh3>\u003Cp>同じ通知は、労力を下げられる具体的な場面を2つ示しています。\u003C\u002Fp>\u003Cp>1つ目は変更時です。施行通知10．第5条の6関係（4）は、表示上の変更や操作手順の合理化等の品質、有効性及び安全性に影響がないと判断できる変更について、①その変更内容を明確にし、変更前にバリデーションが不要であることを文書で示すか、②あらかじめバリデーションを不要とする変更範囲を文書で明示することにより、変更前のバリデーションを不要とすることができるとしています。②を先に整備しておけば、軽微なアップデートのたびに判断書を作る必要がなくなります。\u003C\u002Fp>\u003Cp>2つ目は導入時です。同（5）は「例えば、リスクが低いソフトウェア導入時においては、入力に対して出力が適切であるか等の確認をもって、当該ソフトウェアのバリデーションとすることができる」としています。低リスクなら入出力の確認をもってバリデーションとしうる、と国内の通知が例示として明記している点は、実務上かなり大きな意味を持ちます。\u003C\u002Fp>\u003Cp>ただし、\u003Cstrong>ここで挙げた2つの具体例は、通知上はいずれも第5条の6側のものです。\u003C\u002Fstrong> 「リスクに応じて管理の程度を定める」という趣旨自体は、第45条側（施行通知54．第45条関係（8））と第53条側（同61．第53条関係（5））にも書かれています。一方で「入力に対して出力が適切であるか等の確認をもってバリデーションとすることができる」（10．（5））と「変更前のバリデーションを不要とすることができる」（10．（4））は、通知の中では第5条の6関係にしか書かれていません。MESや試験室の解析ソフトのように第45条・第53条側に載る案件で、この2つをそのまま根拠にすることはできません。\u003C\u002Fp>\u003Cp>もっとも、変更前バリデーションの回避については条文に同じただし書きがあります。第45条第5項と第53条第9項は、第5条の6第2項と同一の文言で「当該ソフトウェア又はその適用の変更前にバリデーションを行う必要がない正当な理由を示すことができる場合においては、当該ソフトウェア又はその適用の変更後にバリデーションを行えば足りる」としています。通知10．（4）が示す2つの経路を第45条・第53条側でもそのまま使えるとは書けませんが、「正当な理由を示す」という条文上のルートは3条に共通です。\u003C\u002Fp>\u003Cp>第53条側には固有の例示もあります。施行通知61．第53条関係（5）は「例えば、製品や工程への影響度により、設備や器具のバリデーションの方法や頻度などを決定することが考えられる」として、頻度による軽量化を挙げています。監視及び測定に使うソフトウェアについては、この頻度の調整が実務上の効きどころです。\u003C\u002Fp>\u003Ch3 id=\"hc07d872f2a\">参照できる技術文書：ISO\u002FTR 80002-2:2017\u003C\u002Fh3>\u003Cp>施行通知10．第5条の6関係（5）は、品質管理監督システムに使用するソフトウェアの適用のバリデーションについて、ISO\u002FTR 80002-2を参照することができるとしています。第45条側（施行通知54．（8））と第53条側（同61．（5））では、「当該ソフトウェアの管理には」という形で同じ技術報告書が挙げられています。\u003C\u002Fp>\u003Cp>ISO\u002FTR 80002-2:2017の表題は「Medical device software — Part 2: Validation of software for medical device quality systems」（第1版・2017年）で、スコープはISO 13485に記述された医療機器品質システムを自動化するソフトウェアです。ソフトウェア自体が医療機器であるものや、医療機器の構成部品、部分又は附属品として使用されるソフトウェアは対象外とされており、3条文マップの3用途と範囲が一致します。参照「することができる」であって義務ではない点も含め、本記事では表題とスコープに限って紹介します。\u003C\u002Fp>\u003Ch2 id=\"hc5e3688fc4\">CSVの実務手順：計画から報告までの流れ\u003C\u002Fh2>\u003Cp>第5条の6は成果物の名前や様式を指定していません。実務では計画・要求仕様・リスク評価・検証・報告の5ステップに整理し、各段階の記録を残す形が扱いやすくなります。\u003C\u002Fp>\u003Ch3 id=\"h3ca727d085\">ステップ1 バリデーション計画\u003C\u002Fh3>\u003Cp>対象システム、範囲、体制、判定基準、作成する成果物を決めます。ここで「どこまでやれば終わりか」を先に定義しないと、検証が延々と続きます。\u003C\u002Fp>\u003Ch3 id=\"h7db3dcacba\">ステップ2 要求仕様の明確化\u003C\u002Fh3>\u003Cp>そのシステムに何ができれば「意図した用途に適合している」といえるのかを、検証可能な形で書き出します。「使いやすいこと」は検証できませんが、「承認者以外は発行できないこと」は検証できます。\u003C\u002Fp>\u003Ch3 id=\"hf92f879986\">ステップ3 リスク評価\u003C\u002Fh3>\u003Cp>第5条の6第3項が求める工程です。品質、安全性又は有効性への影響の大きさを評価し、以降の検証の厚みをここで決めます。実務上、労力配分の説明責任はこの記録が担います。\u003C\u002Fp>\u003Ch3 id=\"h4fcffabe46\">ステップ4 検証\u003C\u002Fh3>\u003Cp>要求仕様の各項目に対して、検証の方法と結果を1対1で対応づけます。この対応づけの考え方は一般に「V字モデル」と呼ばれます。ただし\u003Cstrong>GAMP 5 第2版は、V字モデルを唯一の型とはせず、アジャイル開発を含む複数のライフサイクルモデルを認めています\u003C\u002Fstrong>（Appendix D8）。重要なのは図の形ではなく、要求仕様と検証結果の追跡可能性が確保されていることです。\u003C\u002Fp>\u003Cp>なお実務で頻出するIQ（据付時適格性確認）／OQ（運転時適格性確認）／PQ（性能適格性確認）は、医薬品のCSVや製造設備のバリデーションで広く使われてきた枠組みで、QMS省令の条文には登場しない用語です。第5条の6はこの3段階を要求していないため、様式を合わせること自体が目的化しないよう注意してください。用いる場合は、各段階で何を確認するのかを自社の手順書で定義しておく必要があります。\u003C\u002Fp>\u003Ch3 id=\"h36c1d2c277\">ステップ5 報告と運用\u003C\u002Fh3>\u003Cp>意図した用途への適合を宣言する結論をまとめ、記録を作成・保管します（第4項）。運用開始後は、変更のたびに再バリデーションの要否を判断し、その判断自体を記録します。\u003C\u002Fp>\u003Ch3 id=\"hbaa6dca3d3\">CSV成果物の最小セット\u003C\u002Fh3>\u003Cp>第5条の6の全4項に対応させると、必要な成果物は次の8点に収まります。様式は自由なので、既存の手順書体系に組み込める形にしてください。リスクが低い場合でも第1項から第4項までの要求自体が消えるわけではないため、軽量化が効くのは8点の枠を減らすことではなく、各文書の分量と検証の厚みを落とすことです。\u003C\u002Fp>\u003Cul>\u003Cli>[ ] バリデーションの手順書（第1項）— 対象の特定方法・リスク評価の方法・成果物・承認者を定めている\u003C\u002Fli>\u003Cli>[ ] 対象システム一覧と、第5条の6／第45条／第53条のどれに該当するかの区分\u003C\u002Fli>\u003Cli>[ ] バリデーション計画書（範囲・体制・判定基準・成果物）\u003C\u002Fli>\u003Cli>[ ] 要求仕様（意図した用途を検証可能な形で記述したもの）\u003C\u002Fli>\u003Cli>[ ] リスク評価の結果（検証の厚みを決めた根拠）\u003C\u002Fli>\u003Cli>[ ] 検証の記録（実施者・実施日・結果・発見された不具合とその処理）\u003C\u002Fli>\u003Cli>[ ] バリデーション報告書（適合を宣言する結論と承認）\u003C\u002Fli>\u003Cli>[ ] 変更時の再バリデーション要否の判断記録（施行通知10．第5条の6関係（4）が求める文書）\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"h49428ebb04\">GAMP 5 第2版が示す考え方と労力の配分\u003C\u002Fh2>\u003Cp>ISPE GAMP 5 第2版は、コンピュータ化システムのバリデーションを\u003Cstrong>リスクベースで進めるための業界ガイド\u003C\u002Fstrong>です。規制要求ではないため「GAMP 5に従っている」ことが第5条の6への適合の証明にはなりませんが、労力配分を説明する枠組みとして実務で広く参照されています。\u003C\u002Fp>\u003Cp>正式名称は「ISPE GAMP® 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems」（Second Edition）で、2022年7月にISPEから発行された404ページの文書です。\u003C\u002Fp>\u003Ch3 id=\"h6e66560eed\">ソフトウェアカテゴリは「チェックリスト」ではない\u003C\u002Fh3>\u003Cp>ソフトウェアのカテゴリ分類はAppendix M4（Categories of Software and Hardware）が扱います。第2版のSection 12.1.1は、コンピュータ化システムは一般に異なるカテゴリの構成要素の組合せから成るため、カテゴリはシステム全体ではなく構成要素単位で捉え、連続体（continuum）とみなすべきであるとしています。\u003C\u002Fp>\u003Cp>あわせて第2版は、カテゴリ分類はバリデーションのチェックリスト的アプローチを提供する意図のものではないと明記しており、ライフサイクル活動は構成要素の性質と特定されたリスクに基づいてスケーリングされるべきものとされています。「カテゴリ番号を決めれば作る文書が自動的に決まる」という運用は、第2版の趣旨から外れます。本記事ではカテゴリ番号ごとの定義には踏み込みません。\u003C\u002Fp>\u003Ch3 id=\"h004d52636d\">第2版で強化された点\u003C\u002Fh3>\u003Cp>第2版ではAppendix D8（Agile Software Development）が新設され、Critical Thinkingは第3章3.4（Critical Thinking Through the Life Cycle）とAppendix M12に位置づけられています。テストについてはAppendix D5（Testing of Computerized Systems）と第8章Efficiency Improvements（8.5 Using Efficient Testing Practices）があり、探索的テスト等の非スクリプト技法の活用が推奨されています。表計算ソフトなどのエンドユーザーアプリケーションはAppendix S3が扱います。\u003C\u002Fp>\u003Cp>第2版はFDAのCSAの概念を取り込んでおり、次章のCSAと方向性は一致しています。ただしGAMP 5はGxP（医薬品等）向けのガイドであり、医療機器で使う場合は「QMS省令の要求を満たす手段の一つ」という位置づけを崩さないことが重要です。QMS適合性調査で説明すべきは、第5条の6の各項に対して自社が何をしたかです。\u003C\u002Fp>\u003Ch2 id=\"hc5397d1fe3\">CSA（Computer Software Assurance）— FDAが示すリスクベースのアシュアランス\u003C\u002Fh2>\u003Cp>CSA（Computer Software Assurance）は、生産及び品質マネジメントシステムに使用するソフトウェアについて、意図した用途とプロセスリスクに応じてアシュアランス活動の厚みを変えるという米国FDAの考え方です。現行版は「Computer Software Assurance for Production and Quality Management System Software」（2026年2月3日発出）です。2025年9月24日発出の最終版（当時の題名は「…and Quality System Software」）を差し替えたもので、QMSR施行に合わせて題名の「Quality System」が「Quality Management System」に改められています。旧版を参照している場合は差し替えてください。\u003C\u002Fp>\u003Cp>ガイダンスの版の位置づけや電子記録・電子署名側の要求は\u003Ca href=\"\u002Fblogs\u002Fcfr-part11\">21 CFR Part 11とは？\u003C\u002Fa>で扱います。\u003C\u002Fp>\u003Cp>米国側でバリデーションを求めているのは21 CFR Part 820（2026年2月2日に施行されたQMSRでISO 13485:2016を引用しています）であり、CSAガイダンスはその要求を満たすうえで製造業者が検討しうるリスクベースのアプローチを示す文書だと、ガイダンス自身が位置づけています。\u003C\u002Fp>\u003Cp>このガイダンス自身も、バリデーション要求の根拠としてISO 13485の4.1.6、7.5.6、7.6を挙げています。3条文マップで示した第5条の6・第45条・第53条に対応する箇条であり、日本のメーカーにとっても「同じ3つの要求に対する進め方の提案」として読めます。以下は同ガイダンスが示す枠組みのうち、アシュアランス活動の決め方に関する部分です。\u003C\u002Fp>\u003Ch3 id=\"h3798cb34e5\">ステップ1 意図した用途を特定する\u003C\u002Fh3>\u003Cp>システム単位ではなく、原則としてfeatures／functions／operations（機能・操作）の単位で意図した用途を見ます。ただし意図した用途が1つしかない単純な場合（そのソフトウェアの機能・操作がすべて同じ用途を共有している場合）は、機能ごとに個別に見ることが有用とは限らず、ソフトウェア全体の意図した用途に基づいてリスクベースの進め方を組み立ててよいとされています。用途は「直接使用」と「支援」に分けて整理されています。\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>直接使用\u003C\u002Fstrong>: 生産工程・検査・試験・生産データの収集処理の自動化／QMSプロセス・QMSデータの収集処理の自動化／適用される品質マネジメントシステム上の義務に基づき作成される品質記録の維持\u003C\u002Fli>\u003Cli>\u003Cstrong>支援\u003C\u002Fstrong>: 生産・QMSに使うソフトウェアを試験・監視する開発ツールやテスト自動化ツール（スクリプトの開発・実行に使うものや、製造設備に組み込まれたファームウェア等を含む）／品質記録に当たらない一般的な記録管理\u003C\u002Fli>\u003C\u002Ful>\u003Cp>どちらもバリデーションの対象ですが、支援用途はリスクが低いことが多く、労力を下げられます。対象外の例として、メールや会計など生産・QMSに固有でない業務アプリケーションと、ネットワークやユーザー認証、事業継続（バックアップ・復元）など生産・QMSに固有でないインフラが挙げられています。施行通知10．第5条の6関係（2）ただし書きの考え方とほぼ同じ線引きです。\u003C\u002Fp>\u003Cp>ただし「固有でない」という限定には注意が必要です。ガイダンスはIaaSのクラウドストレージを例に挙げ、インフラに分類されるものであっても、品質マネジメントシステム上の義務に基づき作成される品質記録の保管に使う場合は、生産又はQMSの一部として「直接使用」されているものとみなされるとしています。この場合は、記録の完全性に関わる機能と、保管する記録に適用される21 CFR Part 11の要求にアシュアランスの労力を集中させることが推奨されています。\u003C\u002Fp>\u003Ch3 id=\"h30bea25bf7\">ステップ2 「高プロセスリスク（high process risk）」かを判定する\u003C\u002Fh3>\u003Cp>高プロセスリスクとは、機能不全が安全性を予見可能な形で損なう品質問題を招くおそれがある場合を指します。ガイダンスは次のような例を示しています。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>判定\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>例\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>高プロセスリスクに当たる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品の物理的特性又は製造工程に影響し、機器の安全性に不可欠と特定される工程パラメータの維持／人の確認が限定的又は無い状態で製品・工程を測定・検査・分析し、又は合否を判定／人の確認なしに工程パラメータを自動補正／患者・使用者に提供される添付文書その他の表示のうち、当該医療機器の安全な操作に必要なものの生成／製造業者が機器の安全性（サイバーセキュリティ等）及び品質に不可欠と特定したデータの監視・傾向分析・追跡の自動化\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>高プロセスリスクに当たらない\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>生産・工程性能に直接影響しない監視・照査目的のデータ収集記録／CAPAのルーティング、苦情の自動記録追跡、変更管理、手順管理／データの管理（処理・保管・整理）、既存工程における計算の自動化・監視強化・例外時のアラート／上記の「支援」用途\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>多くのメーカーが最初に電子化する文書管理・CAPA・苦情処理は、下段に位置づけられています。「eQMSの導入だから重厚なバリデーションが必要」という前提は、この枠組みでは成り立ちません。\u003C\u002Fp>\u003Ch3 id=\"h2cce10f4b3\">ステップ3 アシュアランス活動を選ぶ\u003C\u002Fh3>\u003Cp>アシュアランス活動としては、スクリプトテスト（scripted testing／テストケースをあらかじめ文書化して実行する）と非スクリプトテスト（unscripted testing）が代表例として挙げられています（ガイダンスは網羅的な列挙ではないと明記しています）。後者にはシナリオテスト（アドホックテスト）と経験ベーステスト（エラー推測、探索的テスト）が含まれます。\u003C\u002Fp>\u003Cp>高プロセスリスクに該当する機能にはより厚い活動（スクリプトテスト、またはスクリプトと非スクリプトのハイブリッド）を、該当しない機能には非スクリプト中心の活動を割り当てます。ただしこの対応は排他的ではなく、リスクの低い機能にスクリプトテストを使うことも否定されていません。\u003C\u002Fp>\u003Ch3 id=\"hd7fd4f3a50\">ステップ4 記録は「必要以上に作らない」\u003C\u002Fh3>\u003Cp>記録に含めるべきものは、意図した用途、リスク評価の結果、そして実施したアシュアランス活動の文書化です。後者にはテストの内容、発見された不具合、意図した用途への適合性を宣言する結論（不具合が見つかった場合は、その解消を結論に含めることが推奨されています）、実施者と実施日、必要な場合の照査・承認が含まれます。\u003C\u002Fp>\u003Cp>スクリーンショットの束や紙への複製ではなく、システムログや監査証跡といったデジタル記録を活用することが推奨されています（least-burdensomeの考え方）。なおバリデーション記録そのものの完全性の確保は\u003Ca href=\"\u002Fblogs\u002Fdata-integrity\">データインテグリティ（ALCOA+）の実践ガイド\u003C\u002Fa>で解説しています。\u003C\u002Fp>\u003Ch3 id=\"hb0e8dc3857\">日本の第5条の6とCSAは同じ方向を向いている\u003C\u002Fh3>\u003Cp>ここまで見たCSAの進め方は、第5条の6と施行通知の要求に素直に対応づけられます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>CSAの考え方\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>日本側で対応する要求\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>意図した用途を機能単位で特定し、対象外を切り分ける\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知10．第5条の6関係（2）の対象例と「品質、安全性又は有効性に影響しないソフトウェアは対象ではない」\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>プロセスリスクに応じて活動の厚みを変える\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6第3項／施行通知10．（5）「リスクに応じて、管理の程度を定める」\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>低リスクには軽い確認で足りる\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>施行通知10．（5）「入力に対して出力が適切であるか等の確認をもって…バリデーションとすることができる」\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>記録は必要以上に作らず、用途・リスク評価・実施した活動・結論を残す\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第5条の6第1項（手順の文書化）・第4項（記録の作成・保管）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>ただしCSAは米国FDAのガイダンスであり、日本の第5条の6への適合根拠にはなりません。使えるのは実務の設計思想としてであって、説明の軸は場面によって変わります。QMS適合性調査で説明すべきは省令の各項に対して自社が何をしたかであり、ISO 13485審査で説明すべきは該当する箇条（4.1.6・7.5.6・7.6）に対して何をしたかです。\u003C\u002Fp>\u003Cp>一方で、日米双方の規制を受けるからといって記録一式を二重に作る必要はありません。CSAの進め方で実施した活動そのものは、第5条の6・第45条・第53条の各項に対応づけて説明できるのであれば、省令側の記録としても使えます。分けるべきなのは記録ではなく説明の構成です。\u003C\u002Fp>\u003Ch2 id=\"hb6d816b90d\">eQMS・表計算ソフトのバリデーション実務チェックリスト\u003C\u002Fh2>\u003Cp>自社で開発していない既製品やSaaSであっても、第5条の6のバリデーションの責任は使用する製造販売業者等にあります。実務では、供給者評価で置き換えられる部分と自社環境で確認すべき部分を切り分け、後者に労力を集中させます。この章のチェックリストは第5条の6専用ではありません。第45条・第53条に当たるシステムでも、対応づける条項を読み替えればそのまま使えます（後掲の10項目は、1つ目でその区分の確認から始めています）。\u003C\u002Fp>\u003Ch3 id=\"hce3c02d71e\">既製品・SaaSは誰が何をやるのか\u003C\u002Fh3>\u003Cp>ベンダー側が保証できるのは、製品としての開発・検証です。供給者評価（ベンダー評価）でその体制と提供可能な文書の範囲を確認し、結果を記録に残します（\u003Ca href=\"\u002Fblogs\u002Fsupplier-management-guide\">サプライヤー評価と購買管理\u003C\u002Fa>）。一方、自社の設定、アクセス権限、ワークフロー、運用手順を含めた「自社の意図した用途への適合」は自社の責任として残ります。「ベンダーがバリデーション済みだから自社は不要」という切り分けは成立しません。\u003C\u002Fp>\u003Cp>eQMSを開発する側から見ると、導入時に顧客から求められる文書はほぼ共通しています。要求仕様に対応するテスト結果、監査証跡の仕様、アクセス権限の設計、そしてバージョンアップ時の変更内容の通知方法です。この4点を選定段階の質問リストに入れておくと、自社側で作る成果物の量を先に見積もれます。\u003C\u002Fp>\u003Ch3 id=\"h6ad5e00658\">表計算ソフトの落とし穴\u003C\u002Fh3>\u003Cp>CSAガイダンスは表計算ソフトを例に挙げています。基本の入力機能だけを使って読み取り値を記録する用途であれば、供給者評価と初期のインストール・設定の確認で足りうるとされ、独自の数式を作って生産やQMSに直接使う場合は追加のバリデーションが必要になりうるとされています。\u003C\u002Fp>\u003Cp>分岐点は「表計算ソフトを使っているか」ではなく「自社がロジック（数式・マクロ・スクリプト等）を作っているか」です。作っているなら、その数式は自社が作ったロジックとして検証の対象になり、追加のリスク評価とデータインテグリティの考慮が必要になりえます。記録の完全性そのものについては\u003Ca href=\"\u002Fblogs\u002Fdata-integrity\">データインテグリティ（ALCOA+）の実践ガイド\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"hf0e9d09d95\">導入前に押さえる10項目\u003C\u002Fh3>\u003Cul>\u003Cli>[ ] 第5条の6／第45条／第53条のどれに該当するかを区分した\u003C\u002Fli>\u003Cli>[ ] 意図した用途を機能単位で書き出した（誰が・何の記録を・どう処理するか）\u003C\u002Fli>\u003Cli>[ ] 品質、安全性又は有効性への影響を評価し、リスクの高低を判断した\u003C\u002Fli>\u003Cli>[ ] リスクに応じて検証の厚み（スクリプト／非スクリプト）を決めた\u003C\u002Fli>\u003Cli>[ ] 供給者評価を実施し、結果を記録した\u003C\u002Fli>\u003Cli>[ ] ベンダーから入手できるバリデーション用文書の範囲を確認した\u003C\u002Fli>\u003Cli>[ ] 自社の設定・アクセス権限・ワークフローを検証対象に含めた\u003C\u002Fli>\u003Cli>[ ] 記録の保管期間とエクスポート手段を確認した\u003C\u002Fli>\u003Cli>[ ] バージョンアップ時の再バリデーション判断基準を手順書に定めた\u003C\u002Fli>\u003Cli>[ ] バリデーションを不要とする変更範囲をあらかじめ文書で明示するかを決めた\u003C\u002Fli>\u003C\u002Ful>\u003Cp>選定段階で分岐点になるのは、ベンダーがバリデーション用の文書を出せるか、そして監査証跡やアクセス制御が標準機能として備わっているかです。機能が足りないシステムを選ぶと、不足分を運用手順と手作業の記録で埋めることになり、軽量化どころか労力が増えます。\u003Ca href=\"\u002Fblogs\u002Feqms-introduction\">電子QMS導入のメリットと課題\u003C\u002Fa>を検討する段階であれば、\u003Ca href=\"https:\u002F\u002Fservice.qm-smart.com\u002F?utm_source=yakuji-navi&utm_medium=link&utm_campaign=csv-csa\">QMSmart\u003C\u002Fa>は監査証跡・電子署名・アクセス制御を標準機能として備えており、導入時のバリデーションを支援する「バリデーションキット」もあわせて提供しているため、バリデーション文書の整備を導入プロセスのなかで進められます。\u003C\u002Fp>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"h508eb0d41e\">CSV（コンピュータ化システムバリデーション）は医療機器メーカーにも義務ですか？\u003C\u002Fh3>\u003Cp>義務です。QMS省令第5条の6が、品質管理監督システムにソフトウェアを使用する場合の手順の文書化（第1項）、初回使用時と変更時のバリデーション（第2項）、リスクに応じた実施（第3項）、記録の作成・保管（第4項）を求めています。ただし限定第三種医療機器製造販売業者（限定一般医療機器のみを製造販売する製造販売業者）は、第1項の括弧書きが「以下この条において同じ」としているため、第5条の6の全体について対象外です。なお「一般医療機器のみを製造販売している」ことと「限定一般医療機器のみを製造販売している」ことは同じではありません。限定一般医療機器は一般医療機器のうち厚生労働大臣が指定するもの以外を指し、その指定は平成26年厚生労働省告示第316号の別表と、製造工程における滅菌の有無で決まります。該当性を確認したうえで判断してください。また省令上の適用除外は、ISO 13485:2016の4.1.6の要求には及びません。\u003C\u002Fp>\u003Ch3 id=\"h999b0772c5\">医薬品の「コンピュータ化システム適正管理ガイドライン」に従う必要がありますか？\u003C\u002Fh3>\u003Cp>適用されません。同ガイドライン（薬食監麻発1021第11号／平成22年10月21日／平成24年4月1日適用）は、その「1．目的」で対象を「GMP省令の適用を受ける医薬品又は医薬部外品を製造販売する製造販売業者又は製造する製造業者等」と定義しており、「2．適用範囲」もその製造販売業者等がコンピュータ化システムを使用してGQP省令及びGMP省令が適用される業務を行う場合に限っています。医療機器はQMS省令が適用される別体系です。手法として参考にすることは可能ですが、その様式に合わせること自体が要求ではありません。\u003C\u002Fp>\u003Ch3 id=\"h08cf95a746\">Excel（表計算ソフト）で管理している記録もバリデーションの対象ですか？\u003C\u002Fh3>\u003Cp>用途で決まります。品質管理監督システムの記録を維持する用途なら第5条の6の対象です。試験や測定の結果を取得・処理し、合否の判定に使っている場合は、第5条の6ではなく第53条第8項〜第11項が根拠条文になります（1つのファイルでも機能によって分かれます）。基本的な入力機能で読み取り値を記録するだけなら供給者評価と初期の設定確認で足りうる一方、独自の数式やマクロといったロジックを自社で作って判定や計算に直接使う場合は追加のバリデーションが必要になりえます。\u003C\u002Fp>\u003Ch3 id=\"hf3a26ea42e\">クラウド（SaaS）のeQMSは、ベンダーがバリデーション済みなら自社では不要ですか？\u003C\u002Fh3>\u003Cp>不要にはなりません。ベンダーが提供できるのは製品側の検証で、自社の設定・権限・運用手順を含めた「自社の意図した用途への適合」は自社の責任です。実務では、供給者評価とバリデーション用文書の入手によって自社側の労力を下げる、という組み立てになります。\u003C\u002Fp>\u003Ch3 id=\"h91e72b0b51\">ソフトウェアをバージョンアップしたら毎回再バリデーションが必要ですか？\u003C\u002Fh3>\u003Cp>必ずしも必要ではありません。第5条の6第2項は変更時に「あらかじめ」バリデーションを求めていますが、施行通知10．第5条の6関係（4）は、表示上の変更や操作手順の合理化など品質、有効性及び安全性に影響がないと判断できる変更について、変更内容を明確にして変更前のバリデーションが不要であることを文書で示すか、あらかじめ不要とする変更範囲を文書で明示することにより、変更前のバリデーションを不要とできるとしています。\u003C\u002Fp>\u003Ch3 id=\"h2a9b2c013a\">CSA（Computer Software Assurance）に従えばテストを省略できますか？\u003C\u002Fh3>\u003Cp>省略ではなく配分です。CSAは意図した用途とプロセスリスクに応じてアシュアランス活動の厚みを変える考え方で、高プロセスリスクに該当しない機能には非スクリプトテストを使えるとする一方、意図した用途・リスク評価の結果・実施した活動・結論・実施者と実施日といった記録は残ります。またCSAは米国FDAのガイダンスであり、日本の第5条の6への適合根拠にはなりません。ただし記録を日米で二重に作る必要はなく、CSAの進め方で実施した活動を第5条の6の各項に対応づけて説明できるのであれば、省令側の記録としても使えます。\u003C\u002Fp>\u003Ch2 id=\"ha214098e44\">まとめ\u003C\u002Fh2>\u003Cul>\u003Cli>CSV（コンピュータ化システムバリデーション）の根拠はQMS省令第5条の6。第1項＝手順の文書化、第2項＝初回使用時と変更時にあらかじめ、第3項＝リスクに応じて、第4項＝記録の作成・保管。限定第三種医療機器製造販売業者は本条全体の対象外ですが、「一般医療機器のみを製造販売している」ことと「限定一般医療機器のみを製造販売している」ことは別で、該当性の確認が前提です（省令上の除外はISO 13485:2016の4.1.6には及びません）\u003C\u002Fli>\u003Cli>用途で条文が変わります。QMSに使う＝第5条の6（ISO 13485:2016 4.1.6）／製造及びサービスの提供に使う＝第45条第4項〜第7項（7.5.6）／監視及び測定に使う＝第53条第8項〜第11項（7.6）\u003C\u002Fli>\u003Cli>医薬品のコンピュータ化システム適正管理ガイドライン（薬食監麻発1021第11号）は、名宛人をGMP省令の適用を受ける医薬品・医薬部外品の事業者に限っているため、医療機器には適用されません。参考にとどめ、様式を目的化しないこと\u003C\u002Fli>\u003Cli>省令はすでにリスクに応じた軽量化を認めています。施行通知10．第5条の6関係（4）（5）は、影響のない変更について変更前バリデーションを不要にできること、低リスクなら入出力の確認で足りることを明記しています。この2つの例示は通知上は第5条の6側のもので、第45条・第53条側は条文のただし書き（第45条第5項・第53条第9項）が共通の根拠になります\u003C\u002Fli>\u003Cli>GAMP 5 第2版とFDAのCSAは設計思想として有用ですが、いずれも日本の適合根拠にはなりません。説明すべきは、QMS適合性調査では省令の各項、ISO 13485審査では該当する箇条（4.1.6・7.5.6・7.6）に対して何をしたかです\u003C\u002Fli>\u003C\u002Ful>\u003Cp>第5条の6のバリデーションは一度きりの作業ではありません。第2項が変更時にもバリデーションを求めているため、そのソフトウェアを使い続ける限り、変更のたびに要否の判断と記録が発生します。この判断と記録を人の記憶と表計算ファイルで回していると、数年後の適合性調査で経緯を説明できなくなります。導入の段階から監査証跡と版管理が標準で残る仕組みを選んでおくほうが、長期的な負荷は小さくなります。軽量化とは記録をなくすことではなく、残すべき記録が自動的に残る状態を作ることだと考えてください。\u003C\u002Fp>",{"url":77,"height":12,"width":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F25df8720ff75404cbb4064c98605e810\u002F1.webp","CSV（コンピュータ化システムバリデーション）を医療機器メーカーの視点で解説。QMS省令第5条の6が対象とするソフトウェア、施行通知が認めるリスクに応じた軽量化、GAMP 5第2版とFDAのCSAの使い方をチェックリスト付きで整理します。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":80,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},{"url":21,"height":22,"width":23},[82,86,87,88],{"id":83,"createdAt":84,"updatedAt":84,"publishedAt":84,"revisedAt":84,"name":85},"zok07f3-fr","2024-10-16T06:41:44.552Z","バリデーション",{"id":38,"createdAt":39,"updatedAt":39,"publishedAt":39,"revisedAt":39,"name":40},{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":89,"createdAt":90,"updatedAt":90,"publishedAt":90,"revisedAt":90,"name":91},"je725wboz","2025-03-28T00:53:46.776Z","実践ガイド",{"id":93,"createdAt":94,"updatedAt":95,"publishedAt":95,"revisedAt":95,"title":96,"content":97,"eyecatch":98,"description":100,"reviewer":101,"category":103},"medical-device-cybersecurity","2026-09-01T00:36:36.587Z","2026-09-08T02:16:39.436Z","医療機器サイバーセキュリティ対応の実務とSBOM","\u003Cp>医療機器サイバーセキュリティの規制対応は、\u003Cstrong>①自社製品が基本要件基準第12条第3項の対象かを判定する、②適合をJIS T 81001-5-1と社内文書で示す、③市販後に脆弱性を管理し続ける\u003C\u002Fstrong>、という3層に整理できます。技術部門だけの話ではなく、承認申請の添付資料とQMS適合性調査で品質保証部門・薬事部門が説明を求められる領域です。2026年8月25日には「医療機器におけるSBOM導入・運用ガイドライン（第1版）」（医薬機審発0825第1号）が発出され、SBOMをQMSと市販後安全管理プロセスに統合するという論点が加わりました。\u003C\u002Fp>\u003Ch2 id=\"hfcf7a4a46e\">医療機器サイバーセキュリティ対応で最初に決める3つのこと\u003C\u002Fh2>\u003Cp>最初に決めるべきことは、対象該当性・適合の示し方・市販後運用の3点です。根拠となる通知が層ごとに分かれているため、着手前に3層を切り分けて計画すると手戻りが減ります。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>層\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>決めること\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>主な根拠\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>①該当性\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第12条第3項の対象か。対象なら申請時に適合資料の添付が必要か\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>令和5年厚生労働省告示第67号／薬生機審発0331第8号（令和5年3月31日）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>②適合の示し方\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>JIS T 81001-5-1等への適合をどの社内文書で示すか。基本要件基準CLにどう書くか\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>薬生機審発0517第1号（平成29年5月17日）／薬生機審発0523第1号（令和5年5月23日）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>③市販後の運用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>脆弱性の特定・評価・開示・修正等、不具合等報告の要否判断、対策に伴う薬事手続、SBOMの維持、既販品への情報提供とSBOM提示準備\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>医薬機審発0328第1号・医薬安発0328第3号（令和6年3月28日）／医薬安発0115第2号（令和6年1月15日）／医薬機審発0423第1号（令和6年4月23日）／医薬機審発0417第1号・医薬安発0417第1号（令和7年4月17日）／医薬機審発0825第1号（令和8年8月25日）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>最も抜けやすいのは②です。\u003Cstrong>適合は「対策を実施した」ことではなく「実施した結果を示す社内文書を特定できる」ことで示します\u003C\u002Fstrong>（薬生機審発0523第1号）。その記録は承認審査だけの資料ではなく、薬生機審発0331第8号 記3（3）はQMS適合性調査（薬機法第23条の2の5第6項又は第23条の2の23第4項の規定による調査。同通知は改正前の項番で「第23条の2の5第7項」と記載していますが、承認品目に係る調査の根拠は令和7年法律第37号による改正（令和8年5月1日施行）で同条第6項に繰り上がっています）の調査権者の求めなどに応じた提示と説明を求めています。\u003C\u002Fp>\u003Ch2 id=\"hf71f58c479\">法的根拠と適用スケジュール ― 基本要件基準第12条第3項\u003C\u002Fh2>\u003Cp>根拠は基本要件基準（医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律第41条第3項の規定により厚生労働大臣が定める医療機器の基準。平成17年厚生労働省告示第122号）第12条第3項です。令和5年厚生労働省告示第67号（令和5年3月9日）により第12条に第3項が追加され、令和5年4月1日から適用されています。\u003C\u002Fp>\u003Ch3 id=\"h49e2bad8b2\">第12条第3項は何を要求しているか\u003C\u002Fh3>\u003Cp>条文は次のとおりです。\u003C\u002Fp>\u003Cblockquote>\u003Cp>プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器又は外部からの不正アクセス及び攻撃アクセス等が想定される医療機器については、当該医療機器における動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し、当該医療機器の機能に支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理が行われていなければならない。また、当該医療機器は、当該医療機器のライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造されていなければならない。\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>要求は4つです。①動作環境及びネットワークの使用環境等を踏まえた適切な要件の特定、②サイバーセキュリティに係る危険性（機能に支障が生じる又は安全性の懸念が生じるもの）の特定及び評価、③当該危険性が低減する管理、④ライフサイクルの全てにおける、計画に基づく設計及び製造です。\u003C\u002Fp>\u003Cp>薬生機審発0331第8号 記2（3）は、①の「使用環境」を、医療機関・在宅・救急・植込み型機器等の動作環境と、接続するネットワーク種別やOS及び各種ライブラリ等のプラットフォームの両方を特定し、その使用環境に適した運用体制等を含めた医療機器の意図する使用に適切な要件を設定することだと説明しています。②③は「他のリスクと同様に」適切にリスクマネジメントを行うことであり（記2（4））、脅威モデリングは既存のリスクマネジメントプロセスの上で実施します（\u003Ca href=\"\u002Fblogs\u002Fqms-riskmanagement-guide\">医療機器QMSにおけるリスクマネジメント実践ガイド\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch3 id=\"h7699970995\">いつから適用され、既承認品はどう扱われるか\u003C\u002Fh3>\u003Cp>適用日は令和5年4月1日で、1年間の経過措置期間が設定されました。押さえるべきは経過措置の期日よりも、申請区分ごとの取扱いと、既に市場に出ている機器の取扱いです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>状況\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>取扱い（根拠の特記がないものは薬生機審発0331第8号 記4）\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>令和6年3月31日以前に承認・認証を受けた、又は届出された医療機器\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>改めて申請・届出を行う必要はない（記4（1））\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>同じ機器を\u003Cstrong>令和6年4月1日以降も継続して製造販売している\u003C\u002Fstrong>場合\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>申請・届出は不要だが、適合を確認した上で、資料を求めに応じて提示できるようにしておく（記4（1）なお書き）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>同じ機器で令和6年4月1日以降に一部変更申請が必要になった場合\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>適合を確認した上で、適合を示す資料を添付する（記4（1）ただし書き）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>令和6年4月1日以降に承認申請又は認証申請を行う医療機器\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>適合を確認した上で、適合に関する資料を添付する必要がある\u003C\u002Fstrong>（記4（3））。届出を行う医療機器も適合を確認する\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>令和6年3月31日以前に製造販売し、医療機関等に存在する\u003C\u002Fstrong>医療機器のうち、第12条第3項への適合が確認されていないもの\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>サイバーリスクに関する情報とEOL／EOSに関する情報の提供、医療機関等の求めに応じたSBOM提示準備\u003C\u002Fstrong>（医薬機審発0417第1号・医薬安発0417第1号。下記参照）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>既存品を一斉に作り直す必要はありませんが、令和6年4月1日以降の新規申請と一変申請はすべて適合資料を伴うため、\u003Cstrong>一変予定のある品目から順に整備する\u003C\u002Fstrong>のが現実的です。JIS T 81001-5-1を適用して開発していない既存品目については、令和5年7月20日の質疑応答集（事務連絡）Ａ３が、同規格の附属書F（トランジションヘルスソフトウェア）を適用してよいとしています。\u003Cstrong>ただしこれは適合性確認通知の記1（1）〜（6）の要件に対する取扱いで、記2の追加確認事項4項目を代替するものではありません。\u003C\u002Fstrong>同Ａ３は対策として「セキュリティ運用ガイドラインを更新する」「補完的コントロールを義務付ける」「ヘルスソフトウェアの一部を書き直す」なども可能とした上で、\u003Cstrong>セキュリティに関するリスクアセスメントを行い、リスク評価の結果、受容できないリスクがないことを確認するよう求めています。医療機器外部の補完的対策が必須になる場合もあり、リスクが受容できないと判断された場合は、製造販売業者が医療機関に対して当該医療機器使用の中止勧告を検討することとされています。\u003C\u002Fstrong>適用する場合はその旨を承認（認証）申請書添付資料4項に記載します。\u003C\u002Fp>\u003Cp>なおＱ３の問いは「製造販売承認・認証・届出済みで」今後も製造販売する予定の品目を対象としており、\u003Cstrong>届出品も附属書Fの適用の対象に含まれます\u003C\u002Fstrong>。申請書への記載のほうは、記載欄のある承認・認証申請を伴う品目についての取扱いです。また令和6年4月1日以降に製造販売する医療機器は、適合を確認した上で資料を求めに応じて提示できるようにしておく必要があります（同 記4（1）なお書き）。\u003C\u002Fp>\u003Cp>関連文書としてはほかに、手引書の改訂通知（令和5年3月31日 薬生機審発0331第11号・薬生安発0331第4号。別添が「医療機器のサイバーセキュリティ導入に関する手引書（第2版）」）と、令和5年7月20日・令和6年1月31日の質疑応答集（Q&A、いずれも事務連絡）があります。これらの通知・事務連絡は厚生労働省のウェブサイトで、過年度の通知はPMDAのウェブサイトでも公開されています。\u003C\u002Fp>\u003Cp>なお、薬生機審発0331第8号 記4（1）には「令和6年3月31日以前に製造販売された医療機器に関する取扱いについては追って通知するものとする」という後段があり、既に市場に出ている機器の扱いは留保されていました。この留保に対し、その一部として情報提供するべき事項をまとめたのが、令和7年4月17日の医薬機審発0417第1号・医薬安発0417第1号「医療機器のサイバーセキュリティ対策に関連する情報提供について」です。同通知は、令和6年3月31日以前に製造販売され医療機関等に存在する医療機器のうち第12条第3項への適合が確認されていないものについて、\u003C\u002Fp>\u003Cp>①当該医療機器のサイバーリスクに関する評価及び対策等を適切に実施し、意図する使用環境におけるサイバーリスクに関する情報を医療機関等に提供すること、あわせて\u003Cstrong>医療機関等の求めに応じてソフトウェア部品表（SBOM）を提示できるように準備しておくこと\u003C\u002Fstrong>（記（1））\u003C\u002Fp>\u003Cp>②医療機器のライフサイクルを特定し、EOL（製品寿命終了）及びEOS（サポート終了）に関する情報を医療機関等に提供していない場合はライフサイクルに応じて提供すること（記（2））\u003C\u002Fp>\u003Cp>③医療機器がEOSに達していない場合は、医療機関等に提供したセキュリティパッチ等の情報について医療機器に適用する計画等を医療機関等へ示し、医療機関等と連携して定期点検等の適切な時期に適用すること（記（3））\u003C\u002Fp>\u003Cp>④医療機器がEOSを越えて使用されている場合においても、有効性及び安全性に関する事項その他製品の適正な使用のために必要なサイバーセキュリティに関する情報を収集して医療機関等への情報提供を行い、サイバーセキュリティに関連して不具合が発生し健康被害が発生した若しくはそのおそれがある場合、又は脆弱性に対し外国医療機器の安全確保措置が実施された場合は、不具合等報告の要否を検討し適切な対応をとること（記（4））\u003C\u002Fp>\u003Cp>を求めています。中古医療機器を取扱う販売業者等の求めに応じても、①〜④と同様の対応をします（記（5））。ただし、EOSを過ぎたものと製造販売業者等が判断した医療機器については、納入先である医療機関等に対し、既にEOSなどに関する必要な情報提供をしている場合、SBOMの作成及び提示を要しません。申請・届出の面で既存品を作り直す必要がないことと、市販後に情報提供とSBOM提示の準備が求められることは別の話であり、既販品を抱えている企業ほどこの通知への対応が先に来ます。\u003C\u002Fp>\u003Ch3 id=\"h19bd6ab5f3\">第12条第2項（JIS T 2304）との関係\u003C\u002Fh3>\u003Cp>第12条第3項は第12条第2項（JIS T 2304等への適合。薬生機審発0517第1号 記2（1）は高度管理医療機器又は管理医療機器の承認申請・認証申請を行う製造販売業者等に「JIS T 2304等への適合性を確認すること」を求め、同項のなお書きで「一般医療機器についても同様に確認が必要であること」としています。同 記1（2）はJIS T 2304の他に国際的に用いられている適切な規格等がある場合はそれらへの適合性を確認することをもって適合を確認したものとして差し支えないとしています）に置き換わるものではなく、その上に重ねる要求です。薬生機審発0331第8号 記3（1）は、プログラムを用いた医療機器については従来のJIS T 2304に「これに加えて」JIS T 81001-5-1によってサイバーセキュリティ対策を強化する必要があるとし、注記でJIS T 81001-5-1はJIS T 2304に規定する製品ライフサイクルの要求事項に加えて実施する取組を規定していると明記しています。安全クラスの判定やSOUP管理は第12条第2項側の論点で、\u003Ca href=\"\u002Fblogs\u002Fiec-62304\">IEC 62304とは？医療機器ソフトウェア開発の実務\u003C\u002Fa>で整理しています。\u003C\u002Fp>\u003Ch2 id=\"h91050f3aa6\">自社製品は第12条第3項の対象か ― 該当性の判定\u003C\u002Fh2>\u003Cp>対象は、プログラムを用いた医療機器のうち、①他の機器及びネットワーク等と接続して使用するもの、又は②外部からの不正アクセス及び攻撃アクセス等が想定されるものです。「又は」でつながるためどちらかに当たれば対象で、実務では①の範囲が広く「ネットワークにつながっていないから対象外」という判断が誤りになりやすい点が要点です。前段の「プログラムを用いた医療機器」は、単体プログラムとして流通するプログラム医療機器（SaMD）に限りません。薬生機審発0517第1号 記1（1）はこの語を「プログラムを用いた医療機器（プログラム又はこれを記録した記録媒体を含む。以下同じ。）」と書いており、SaMDはこの語に含まれる一部です。第12条第3項側でも、薬生機審発0331第8号 記2（3）は特定すべき動作環境として「医療機関、在宅、救急、植込み型機器等」を挙げ、SBOM導入・運用ガイドラインは適用対象の構成パターンに電子血圧計・パルスオキシメーター等の組込みソフトウェアや人工呼吸器・透析装置等の機器搭載ソフトウェアを挙げています（4.1、表2。後掲）。\u003Cstrong>据置型・可搬型のハードウェアに組み込んだソフトウェアやファームウェアで動作を制御している医療機器も、この前段に含まれます。\u003C\u002Fstrong>令和6年1月31日の質疑応答集（事務連絡）Ａ１は、WiFiやBluetooth、有線（LANやUSBデバイス）で接続できる仕様は有するものの、患者への使用時等には接続されず製造販売業者等による保守や修理作業においてのみ接続され、注意事項等情報や使用者との契約で接続制限が合意された医療機器についても、「基本要件基準第12条第3項に示されているとおり」①又は②が適用されるため、リスク分析を行うことにより必要なセキュリティ対応・管理を行うこととしています。なおSaMDそのものの該当性判断や承認・認証・届出のルート選択は本記事の範囲外です（\u003Ca href=\"\u002Fblogs\u002Fsamd-qms\">SaMD（プログラム医療機器）の規制とQMS対応ガイド\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch3 id=\"h27db3ce3c6\">「他の機器及びネットワーク等と接続して使用する医療機器」の範囲\u003C\u002Fh3>\u003Cp>薬生機審発0331第8号 記2（1）は範囲を列挙しています。「他の機器」には医療機器、IoT機器、周辺機器、外部記録媒体（USB、SD、HDD、CD、DVD等）、電子カルテ、PC（外部からの持ち込みPCを含む）が含まれ、「ネットワーク」には院内システム、院外システム、グローバルが含まれます。これらに接続して電磁的情報のやり取りをする医療機器が該当するため、常時ネットワーク接続していない機器でもUSBメモリでデータを受け渡す構成なら対象で、保守で技術者が持ち込むPCと接続する機器も同様です。\u003C\u002Fp>\u003Ch3 id=\"he26d6e8102\">「外部からの不正アクセス及び攻撃アクセス等が想定される医療機器」の範囲\u003C\u002Fh3>\u003Cp>同 記2（2）は、想定する攻撃として、脆弱性を攻撃対象とする等の設計者が通常使用において想定していない手法を用いた悪意を持った不正アクセス、意図的に過剰な負荷を与える攻撃（DoS攻撃、DDoS攻撃等）、マルウェアの感染を意図する攻撃によるアクセス等を挙げ、続けて攻撃形式が多様化・高度化しており今後はこれらの手法のほかにも対応することが必要となり得ると述べています。該当性の判定は一度で終わらせず、脅威環境の変化に応じて見直す前提で記録を残してください。\u003C\u002Fp>\u003Ch3 id=\"h09322e3226\">クラス分類で変わるのは「資料の添付」だけ\u003C\u002Fh3>\u003Cp>クラス分類によって適合の必要性は変わりません。変わるのは申請・届出時に資料を添付するかどうかだけです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>区分\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>適合の確認\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>申請・届出時の資料添付\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>高度管理医療機器・管理医療機器（承認申請又は認証申請）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>必要\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>必要\u003C\u002Fstrong>（JIS T 81001-5-1等への適合性を示す資料）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>一般医療機器（届出）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>必要\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>要さない\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>（薬生機審発0331第8号 記3（4）に基づき作成）\u003C\u002Fp>\u003Cp>一般医療機器は届出時の資料添付を求められませんが「同様に適合性を確認する必要がある」と明記されており、確認の記録は保管してQMS適合性調査で提示できる状態にする必要があります（同 記3（3））。\u003C\u002Fp>\u003Ch2 id=\"hcd1ba0e349\">適合をどう示すか ― JIS T 81001-5-1と適合性確認通知の6要求\u003C\u002Fh2>\u003Cp>第12条第3項への適合は、製造販売業者等自身が確認して示します。薬生機審発0523第1号 記は、JIS T 81001-5-1等への適合性を確認する際に「当該結果を示すか又は当該結果をまとめた社内文書等を特定すること」と求めています。この「社内文書等を特定する」という一文が実務の設計を決めます。同 記 柱書のなお書きは「一般医療機器についても同様に確認が必要であること」としており、次に見る箇条4〜9の確認は届出品にも及びます。粒度については、令和5年7月20日の質疑応答集（事務連絡）Ａ２が、令和6年4月1日以降も引き続き製造販売する既存の医療機器についても、改正後の基本要件基準への適合を確認する上では「適合性確認通知の１の（１）〜（６）及び２の（１）〜（４）のそれぞれの要件に対する社内文書を特定する情報を提示できるようにしておくこと」としています（同Ａ２は、記載先を承認（認証）申請書添付資料4項の電気安全・電磁両立の欄としています）。\u003Cstrong>記1の6項目と記2の4項目のそれぞれについて文書を特定するところまでが求められる\u003C\u002Fstrong>という意味です。先に引いた記 柱書のなお書きが一般医療機器についても「同様に」としていることと合わせると、クラスや新旧で項目が減るわけではありません。\u003C\u002Fp>\u003Ch3 id=\"h20c24cb095\">JIS T 81001-5-1はJIS T 2304の上に載る\u003C\u002Fh3>\u003Cp>JIS T 81001-5-1:2023は「ヘルスソフトウェア及びヘルスITシステムの安全，有効性及びセキュリティ―第5-1部：セキュリティ―製品ライフサイクルにおけるアクティビティ」です。対応国際規格はIEC 81001-5-1:2021、一致の程度はIDT（一致）とされています（日本規格協会の規格情報による）。JIS T 2304が規定するライフサイクルプロセスの各段階にセキュリティのアクティビティを重ねる構造のため、62304対応ができている組織なら既存プロセスに成果物を追加する形になります。\u003C\u002Fp>\u003Ch3 id=\"h78f0f7e819\">箇条4〜9で確認される6項目と、追加で確認される4項目\u003C\u002Fh3>\u003Cp>薬生機審発0523第1号は、適合性を確認する際の留意事項を、記1で規格に関連する要求事項として箇条4〜9の6項目、記2で既存通知等に関連する追加確認事項として4項目に整理しています。下表は各要求と、適合を示すために特定することになる社内文書の対応例です。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>箇条\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>確認内容（記1）／\u003Cstrong>追加\u003C\u002Fstrong>確認事項（記2）\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>社内文書の例\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条4\u003C\u002Fstrong> 一般要求事項\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティ確保の活動が品質マネジメントシステムに基づくこと。規制当局及び顧客への脆弱性の適時通知の活動の確立。リスクマネジメントが脆弱性・脅威等を考慮したものであること。\u003Cstrong>追加\u003C\u002Fstrong>：セキュリティに対する対応方針と問い合わせ窓口の明確化、顧客に対する脆弱性等の開示手順\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>品質マニュアル・セキュリティ方針、窓口の公表物、脆弱性開示手順書\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条5\u003C\u002Fstrong> ソフトウェア開発プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>開発計画でのセキュリティ更新・開発環境等の考慮。製品のセキュリティ機能を含むセキュリティ要求事項の特定。意図する使用環境・信頼境界・多層防御等を考慮したアーキテクチャー設計。ベストプラクティスを考慮した設計及び実装。システム試験による脅威への対応方法の実装・有効性の確認。\u003Cstrong>追加\u003C\u002Fstrong>：意図する使用環境をシステム構成図・ネットワーク構成図等で明示\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>開発計画書、セキュリティ要求事項仕様、アーキテクチャ設計書、構成図、試験報告書\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条6\u003C\u002Fstrong> ソフトウェア保守プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>顧客に対するセキュリティ更新の通知方針を定めること。\u003Cstrong>追加\u003C\u002Fstrong>：ソフトウェア保守計画にサポート終了等の製品寿命の計画、脆弱性の監視、セキュリティ更新等の将来的な脆弱性対策の実施計画をあらかじめ定める\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェア保守計画書（EOL／EOS計画、脆弱性監視・更新計画）、顧客通知方針\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条7\u003C\u002Fstrong> セキュリティに関連するリスクマネジメントプロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>意図する使用及び使用環境を考慮した脆弱性の特定、関連する脅威の推定と評価、リスクコントロール手段による脅威のコントロールとその有効性の監視\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>リスクマネジメント計画書・報告書、脅威モデル、セキュリティリスク分析表\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条8\u003C\u002Fstrong> ソフトウェア構成管理プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>開発、保守及びサポートのための、変更管理及び変更履歴を伴う構成管理プロセスの確立。\u003Cstrong>追加\u003C\u002Fstrong>：構成管理プロセスは、当該医療機器のソフトウェア部品表（SBOM）を適切に作成することによって確認\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>構成管理手順書、変更管理記録、SBOMとその改訂履歴\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>箇条9\u003C\u002Fstrong> ソフトウェア問題解決プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>セキュリティの脆弱性に関する情報伝達及び処理の手順の策定と、セキュリティ問題に対する、情報開示を含む手順に従った実施\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>問題解決手順書、脆弱性の受付・評価・修正・開示の記録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>（「確認内容」は薬生機審発0523第1号 記1・記2の記載に基づく。箇条4の追加確認は平成30年7月24日 薬生機審発0724第1号・薬生安発0724第1号に基づくものとされています。「社内文書の例」は文書を特定する際の例示であり、同通知に列挙されているものではありません）\u003C\u002Fp>\u003Cp>追加確認事項が置かれているのは箇条4・5・6・8の4か所だけで、箇条7と箇条9にはありません。そして\u003Cstrong>箇条8の追加確認によって、SBOMは国内でも構成管理プロセスの確認手段として位置づけられています\u003C\u002Fstrong>。任意の先進的な取組ではなく、遅くとも令和5年5月の通知の時点で、適合確認の道具として明示されていました。\u003C\u002Fp>\u003Ch3 id=\"hfc2f01ed2f\">基本要件基準チェックリストに何を書くか\u003C\u002Fh3>\u003Cp>薬生機審発0523第1号の末尾には「参考：基本要件基準CLの適合」として記載例が示されています。列は「基本要件」「当該機器への適用・不適用」「適合の方法」「特定文書の確認」の4つで、記載例では第12条第3項に対し、適用・不適用は「適用」、適合の方法は「認知された基準の該当する項目に適合することを示す」、特定文書の確認は同通知とされています。CLの記載自体は簡潔で、裏付けは前掲の社内文書の一覧が担います。\u003C\u002Fp>\u003Ch3 id=\"h46348524b9\">IEC 81001-5-1などの国際規格を使う場合の条件\u003C\u002Fh3>\u003Cp>薬生機審発0331第8号 記3（2）は、IEC 81001-5-1等の国際的に用いられている適切な規格等への適合性の確認をもって第12条第3項への適合を確認したものとして差し支えないとしています。なお、承認申請（一部変更承認申請を含む）又は認証申請（一部変更認証申請を含む）に際しては、それらの規格等を用いることの妥当性を説明しなければなりません。海外本社の規格体系を流用する場合は、この妥当性説明の資料を申請パッケージに含める前提で準備してください。この国際規格ルートを使う場合でも、薬生機審発0523第1号 記の確認事項は別途満たす必要があります。同 記の柱書は「JIS T 81001-5-1等への適合性を確認する際には」、記2の柱書は「規格への適合性を確認する際」と書いており、いずれも規格名を限定していません。\u003Cstrong>前掲の表で「追加」と示した記2の4項目（箇条4のセキュリティ対応方針・問い合わせ窓口・脆弱性開示手順、箇条5の意図する使用環境の構成図での明示、箇条6のソフトウェア保守計画、箇条8のSBOM）は、規格本文の外にある国内固有の上乗せです。\u003C\u002Fstrong>令和5年7月20日の質疑応答集（事務連絡）Ａ１も、例えばセキュリティに対する窓口の明確化と顧客に対する脆弱性等の開示手順を挙げて、これらは「JIS T 81001-5-1の要求に明示的には含まれていないが、適合性確認通知による要求事項として対応する必要があり」としています。記2（2）（箇条5）・記2（3）（箇条6）は基本要件基準第12条第3項の文言そのものに紐づく要求であり、用いる規格の版や言語によって変わりません。第三者機関の試験を使う場合も同じです。令和6年1月31日の質疑応答集（事務連絡）Ａ４は、第12条第3項の適合性の確認のための第三者機関による試験は必須ではないとした上で、試験機関を活用した場合は申請時に\u003Cstrong>「適合証明書に加えて」\u003C\u002Fstrong>薬生機審発0523第1号 記2に記載されている項目に対する適合性の確認結果を示すか、確認結果をまとめた社内文書等を特定することを求めています。\u003C\u002Fp>\u003Ch2 id=\"h3548df403a\">SBOM対応 ― 2026年8月のSBOM導入・運用ガイドラインで何が変わったか\u003C\u002Fh2>\u003Cp>2026年8月25日発出の「医療機器におけるSBOM導入・運用ガイドライン（第1版）について」（医薬機審発0825第1号）は、\u003Cstrong>SBOMを既存のQMS及び市販後安全管理プロセスへ統合する道筋\u003C\u002Fstrong>を示した点が従来の通知との違いです。ただし同通知が求めているのは、本ガイドラインを参考として必要な対応を行うことであり、ガイドラインへの適合そのものを法令上の要件として課すものではありません。対象読者にはソフトウェア開発部門と並んで品質保証・QMS担当部門、薬事・規制申請部門が明記され（1.3）、すでに適切に導入・運用している場合は手順・手法等の変更を求めるものではないとされています（1.2）。SBOMの作成責任は原則として製造販売業者が負い、サードパーティから提供を受ける場合でも内容の妥当性確認、統合、管理は製造販売業者が実施します（3.2）。なお同1.1は、国内の基本要件基準第12条第3項と並べて米国FD&C法第524B条などを挙げ、国内外の当局が規制要求事項を強化していると述べています（海外規制の全体像は\u003Ca href=\"\u002Fblogs\u002Foverseas-regulations\">海外の医療機器規制入門\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch3 id=\"hf549737833\">SBOMの最小要素とフォーマット\u003C\u002Fh3>\u003Cp>第1版が採用する最小要素は、NTIA（米国商務省電気通信情報局）の「The Minimum Elements for a Software Bill of Materials (SBOM)」に基づき、「医療機器のサイバーセキュリティ導入に関する手引書（第2版）」の附属書Aに示された要素です（2.3）。サプライヤーの名前、コンポーネント名、バージョン、その他の固有識別子（purl、CPE等）、コンポーネント間の関係、SBOMの作成主体、タイムスタンプ（ISO 8601形式）を、少なくとも医療機関等に提供する最終的なSBOMに含めます。コンポーネントハッシュは手引書ではオプション要素ですが可能な限り付与するとされ、フォーマットは新規導入時の推奨として\u003Cstrong>SPDX 2.2以上又はCycloneDX 1.6以上\u003C\u002Fstrong>が示されました（2.4）。SBOMが複数のファイルで構成されている場合は、必ずSBOMの構成（フォルダを含む）を説明する文書を添えます（同2.4）。なお、この最小要素は医療機関等に提供する最終的なSBOMに係るものです。承認・認証申請との関係は令和5年7月20日の質疑応答集（事務連絡）Ａ５が答えており、\u003Cstrong>SBOMを申請時に提出する必要はないものの、承認・認証申請時にはSBOMを作成していることを明示する必要があり（例えばSBOMの文書名を記載する）、申請の際はSBOMを提示できるように準備しておくこと\u003C\u002Fstrong>とされています。申請時に添付するのはJIS T 81001-5-1等への適合性を示す資料（薬生機審発0331第8号 記3（4））で、SBOMは箇条8の適合を示す社内文書として特定される位置づけです。\u003C\u002Fp>\u003Ch3 id=\"h4029e6bf82\">自社製品はどの構成パターンか\u003C\u002Fh3>\u003Cp>ガイドラインは医療機器ソフトウェアの構成を4パターンに分類し、パターンごとに適用範囲を示しています（4.1、表2）。自社製品をこの分類に当てはめるのが最初の作業です。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>パターン\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>構成／製品例\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>適用範囲の考え方（要旨）\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>A\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社開発コード主体の組込みソフトウェア（電子血圧計、パルスオキシメーター等）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社ファームウェア本体、外部ライブラリ、更新可能な周辺ファームウェア、BSP等のサードパーティコンポーネント。ビルド専用ツール等は通常対象外\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>B\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自社開発コードと商用OS上で動作する機器搭載ソフトウェア（人工呼吸器、透析装置等）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品内部で動作する全コンポーネントを原則対象（商用OS、ミドルウェア、ランタイム、OSS、OTS、推移的依存を含む）。初期はトップレベルから段階的に拡張\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>C\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>SaMDとして提供されるソフトウェア（画像解析、AI診断補助プログラム等）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>汎用OS標準搭載の全列挙は求めず、基本性能・安全性に直接関与するものと追加インストール・同梱したものを中心に定義\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>D\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>A〜Cを組み合わせて構成されるソフトウェア（MRI／CTシステム等）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>「構成要素ごとのSBOM」と「システム全体を俯瞰するSBOM／構成情報」の二層構造\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3 id=\"h1f0d3ddde4\">段階的導入と調達・契約への織り込み\u003C\u002Fh3>\u003Cp>ガイドラインは成熟度に応じた段階的導入の道筋を示しています（1.2、3.1）。\u003Cstrong>第1段階\u003C\u002Fstrong>では最小要素を踏まえたSBOMを作成・更新できる体制を整え、対象製品のSBOMを作成し変更管理できる状態にします。\u003Cstrong>第2段階\u003C\u002Fstrong>では、その体制を脆弱性管理・ライセンス管理・EOL／EOS管理といった既存のQMS及び市販後安全管理プロセスと統合します。運用の打ち手としてコンポーネント情報を集約した「SBOMコンポーネントリポジトリ」の構築と表記揺れを吸収する「正規化」が挙げられ、\u003Cstrong>SBOMの更新完了をソフトウェアリリース承認の条件の一つと位置付ける\u003C\u002Fstrong>ことで構成情報の漏れを防止できるとされています（6.1.2）。\u003C\u002Fp>\u003Cp>第三者が実装したソフトウェアについても最終的なSBOMの正確性と網羅性に責任を負うのは製造販売業者です。ガイドライン6.3は、サプライヤーや開発委託先、OEM／ODM先との契約・調達仕様に、①NTIA最小要素に準拠した機械可読なSBOMの提供、②引渡し時までの提供と構成変更時の更新提供、③各コンポーネントのEOS及びEOLの情報提供と変更時の通知、④重大な脆弱性判明時の脆弱性情報・影響範囲・対策方針・SBOM更新の通知、を条項として検討するよう挙げています。あわせてSBOMツールの導入では、販売代理店やツールベンダーがQMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令。平成16年厚生労働省令第169号）第37条から第39条に基づく購買管理の対象となり得ること、ツール自体が同令第5条の6（ソフトウェアの使用。限定第三種医療機器製造販売業者は適用除外）に基づくバリデーション・記録の管理・変更管理の対象となり得ることが明記されています（4.3.2）。\u003C\u002Fp>\u003Ch3 id=\"hed39dfc19f\">よくある誤解\u003C\u002Fh3>\u003Cp>ガイドライン2.5は、導入判断や運用定着を妨げる誤解を整理しています。社内説明で反論材料になるのは次の2点です。「Excelが1つあれば十分」＝導入初期の可視化には有効だが、表記揺れの抑止、更新漏れの防止、識別子による自動照合、変更履歴の一貫管理に限界がある。「ツールが出力した脆弱性すべてに対応が必要」＝検出結果には悪用不可能なものや当該製品構成では影響を受けないものも含まれ、リスク評価と影響範囲を踏まえた優先順位付けが不可欠。\u003C\u002Fp>\u003Cp>同2.5は「ツールで生成すれば内容は自動的に正しい」という誤解についても、SBOMの正確性・完全性は解析対象の定義、ビルド手順、ツール設定や検出能力、運用プロセスに依存するとし、\u003Cstrong>SBOM生成ツールについてもコンピュータ化システムバリデーションの考え方を踏まえ、意図した用途に対して適切に機能していることを確認した上で、その成果物を有効な情報として扱う\u003C\u002Fstrong>としています（CSV／CSAの考え方は\u003Ca href=\"\u002Fblogs\u002Fcsv-csa\">CSV（コンピュータ化システムバリデーション）とCSA入門\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch2 id=\"h3f2503084d\">市販後に何をし続けるのか ― 脆弱性管理・報告・変更手続\u003C\u002Fh2>\u003Cp>市販後にやり続けるのは、脆弱性の特定・評価・開示・修正等と、その結果として生じる報告と薬事手続です。根拠は医薬機審発0328第1号・医薬安発0328第3号（令和6年3月28日）で、脆弱性を「システムのセキュリティポリシーを破るために悪用される可能性のある、システムの設計、導入又は運用管理における欠陥又は弱み」（JIS T 81001-1:2022 3.4.22）と定義した上で、製造販売業者等がこれらを行う必要があるとしています。\u003C\u002Fp>\u003Ch3 id=\"h693641234f\">脆弱性情報の収集と評価（IPA／JPCERT\u002FCCとの関係）\u003C\u002Fh3>\u003Cp>同通知 記1（1）は、脆弱性の特定及び検出のため、医療機関等と連携するとともにIPA（独立行政法人情報処理推進機構）又はJPCERT\u002FCCのウェブサイトから適時情報収集に努めることを求めています（GVP省令（平成16年厚生労働省令第135号）第7条の規定に沿って収集する場合は窓口への登録を要しません）。脆弱性と思われる情報を入手したときは、情報の受付、確認及び評価を行い、修正策、緩和策又は補完的対策を行う手順と、使用している医療機関へ情報提供する手順を確立します（記1（2））。脆弱性を確認した場合は\u003Cstrong>情報セキュリティ早期警戒パートナーシップ\u003C\u002Fstrong>の手順に基づき対処し、他の製造販売業者等への影響も考慮して適時かつ適切な範囲に開示します（記1（3））。同パートナーシップにおいてIPAは届出の受付機関、JPCERT\u002FCCは連絡及び公表に係る調整機関です。\u003C\u002Fp>\u003Cp>評価の手順はSBOM導入・運用ガイドラインが整理しています。JVN・NVD等の脆弱性情報データベースやベンダーのアドバイザリーを収集してSBOMと照合し、影響を受ける可能性のある製品・バージョンを特定します（6.2.1）。次に、公表されている深刻度（CVSSスコア等）、悪用の可能性、当該コンポーネントの医療機器内での役割、使用環境における露出状況、回避策の有無を踏まえ、「直ちに対応すべきもの」「次回の定期アップデートで対応するもの」「リスク受容としてモニタリングのみ行うもの」に整理します（6.2.2）。「影響なし」と判断した場合も判断理由を品質記録として残します（6.2.4）。\u003C\u002Fp>\u003Ch3 id=\"h49500297f7\">サイバーセキュリティに起因する不具合等報告の考え方\u003C\u002Fh3>\u003Cp>不具合等報告も通常と同じ枠組みで実施します。根拠は薬機法第68条の10第1項で、考え方は医薬安発0115第2号（令和6年1月15日）別添にあります。対象は薬機法（昭和35年法律第145号）第2条第4項に定義された医療機器のうち、無線又は有線により、メディア媒体を含む他の機器、ネットワーク等との接続が可能なプログラム医療機器（SaMD）を含む医療機器及びプログラムを用いた附属品等で、\u003Cstrong>医療機器のクラス分類を問いません\u003C\u002Fstrong>（別添 2.）。\u003C\u002Fp>\u003Cp>判断の骨格は同 別添 4.（3）です。脆弱性は全てが報告の対象ではありません。当該医療機器のSBOM及び設計情報等から、脆弱性が存在するソフトウェアの存在、使用の有無及び機能性能に関する影響等を評価し、使用目的、使用部位、蓋然性等を総合的に判断した結果、悪用が原因で死亡や重篤な健康被害が発生した場合、又は発生するおそれがあると判断した場合に報告します。逆に、脆弱性が存在するソフトウェアが使用されていない場合、又はセキュリティパッチ等の対策により問題が除去又は機能性能に影響がない程度にリスクを低減可能で健康被害が発生するおそれがないと判断できる場合は報告不要で、経時的にモニターし報告の必要が出てきた場合には報告します。\u003Cstrong>「自社製品に当該コンポーネントは含まれていない」と説明するには、含まれていないことを示す構成情報が必要\u003C\u002Fstrong>であり、ここでSBOMが報告要否判断の一次資料になります。なお一般の情報セキュリティを想定したCVSSスコアは臨床環境や患者安全への影響へ置き換えて再評価する必要があり、EOS後を含めた不具合情報の収集義務（薬機法第68条の2の6第1項）と行政報告義務（同法第68条の10第1項）も残ります（同 別添 4.（3）・（4））。なお、自社製品の脆弱性に対して\u003Cstrong>外国医療機器の安全確保措置が実施された場合\u003C\u002Fstrong>も、不具合等報告の要否を検討する必要があります（同 別添 4.（2））。外国で先に措置が打たれた場合に、国内での検討が漏れやすい経路です。\u003C\u002Fp>\u003Ch3 id=\"hc351d93d9e\">対策に伴う変更は一変か、軽微変更届か、いずれも不要か\u003C\u002Fh3>\u003Cp>サイバーセキュリティ対策の多くは薬事手続を伴わずに実施できます。医薬機審発0423第1号（令和6年4月23日）別添が事例を整理しており、いずれも\u003Cstrong>これらの変更等に伴う医療機器としての機能の追加・変更等がない場合に限り\u003C\u002Fstrong>という条件付きです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>手続\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>事例\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>軽微変更届の対象\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>使用方法欄における動作環境であるOSの種類やクラウド動作の追加・変更・削除（汎用PC製品へのクラウド環境での動作の追加、iOS 17製品への異なる種類のOSであるAndroid 13の追加）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>いずれの手続も不要\u003C\u002Fstrong>（次回の一変申請時に記載整備を要する）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>①ネットワークポート（物理的なインタフェースと論理的なIPポートの双方）の削除\u003C\u002Fp>\u003Cp>②ネットワーク接続の禁止又は接続要件の厳格化（SSL通信への限定等） \u003C\u002Fp>\u003Cp>③セキュリティ機能（認証、認可、暗号化、ログ、リモート更新等）又は補完的対策（ファイアウォール等）の変更・追加 \u003C\u002Fp>\u003Cp>④動作環境であるOS等のバージョンの追加・変更・削除（Windows 10製品へのWindows 11の追加、サービス終了に伴うWindows 8の削除等）、及び動作環境として用いるデータベース等のバージョンの追加・変更\u003C\u002Fp>\u003Cp>⑤操作方法や注意事項の変更（併用医療機器を特定させ、EOS製品を使用不可としてリスク軽減を図る等）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>本事例の対象外\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品の有効性及び安全性に関わる機能に影響する場合、及び本来の使用方法ができなくなる変更。ペースメーカや植込み型除細動器等で医療機関側が遠隔モニタリングを行う目的でネットワークに接続している医療機器は、接続の可否が有効性及び安全性の根幹に関わるため対象外\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>表の3行目「本事例の対象外」に当たる場合、\u003Cstrong>この事例集を根拠に手続不要と判断することはできません\u003C\u002Fstrong>。一変申請又は軽微変更届の要否を個別に検討します。\u003C\u002Fp>\u003Cp>また、表の④は使用方法欄に「動作環境」として記載しているOS・データベース・ランタイム等の更新を指すものです。使用方法欄に記載していない、\u003Cstrong>製品内部に同梱・組み込んだOSSライブラリやサードパーティコンポーネントを脆弱性対応で更新する場合に直接該当する行は、この事例集にはありません\u003C\u002Fstrong>（SBOM導入・運用ガイドラインの構成パターンBは、商用OS・ミドルウェア・ランタイム・OSS・OTS・推移的依存を「製品内部で動作する全コンポーネント」として製品側に位置づけています）。同別添は事例が限定列挙ではないことも明記し、個別の取扱いは必要に応じてPMDA又は登録認証機関に相談するよう求めています。一変と軽微変更届の一般的な区分判断、提出書類、届出期限は\u003Ca href=\"\u002Fblogs\u002Fpartial-change-application\">一部変更承認申請と軽微変更届\u003C\u002Fa>で整理しています。\u003C\u002Fp>\u003Ch3 id=\"h0a7270439a\">医療機関との責任分界（VPN装置等の付属機器を含む）\u003C\u002Fh3>\u003Cp>令和8年3月19日の事務連絡「医療機器に接続するVPN装置等のネットワーク機器におけるサイバーセキュリティ対策の徹底について（注意喚起）」（厚生労働省医薬局医療機器審査管理課・医薬安全対策課。事務連絡のため文書番号はありません）は、VPN装置を悪用した侵入によるランサムウェア被害の増加を踏まえ、①リモートメンテナンスに使用するVPN装置等のネットワーク機器など\u003Cstrong>医療機器本体以外の付属機器についても、保守契約等に基づき医療機関との間で責任分界が明らかになっていることを確認する\u003C\u002Fstrong>こと、②製造販売業者に管理の責任がある、\u003Cstrong>医療機器に接続する\u003C\u002Fstrong>VPN装置等のネットワーク機器についてファームウェア等が最新であること及びサポート終了機器が存在しないことを確認し、サポート終了時は医療機関に情報提供して機器更新等の対応を行うこと、③VPN装置について認証の強化、アクセス制御の実施その他の適切なセキュリティ対策を実施することを求めています。これは都道府県あての注意喚起の依頼で、新たな法令上の義務を課すものではなく、既存の枠組みの徹底を求めるものです。責任分界は納入時に決めるもので、医薬機審発0328第1号 記2（2）も、サイバーセキュリティに関する保守計画、インシデントを処理するためのポリシー及び役割を医療機関に説明した上で納入することを求めています。なお医療機関側の対策については、医療機関向けの手引書が別に発出されています。\u003C\u002Fp>\u003Ch2 id=\"h4cd74bcb69\">QMSへの組み込みとセルフチェックリスト\u003C\u002Fh2>\u003Cp>サイバーセキュリティ対応の成果物は、独立した文書群ではなくQMS省令の記録として管理します。専用の手順書を別立てするより、既存の設計開発・苦情処理・記録管理の各手順にセキュリティ観点を差し込むほうが運用が破綻しません。\u003C\u002Fp>\u003Ch3 id=\"ha0c3394675\">設計開発プロセスに載せる（第30条〜第36条の2）\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>サイバーセキュリティで載せるもの\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第30条第4項第5号（設計開発）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>工程入力情報から工程出力情報への追跡可能性を確保する方法。セキュリティ要求事項→アーキテクチャ設計→システム試験のトレーサビリティ\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条第2項・第5項（設計開発の変更の管理）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>変更が機能、性能、安全性及び使用性並びに\u003Cstrong>法令の規定等の適合性\u003C\u002Fstrong>に及ぼす影響の有無及び程度の検証（第2項）。照査の範囲に\u003Cstrong>既に引き渡された製品\u003C\u002Fstrong>への影響評価を含めること（第5項）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条の2（設計開発に係る記録簿）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>製品又は類似製品グループごとに作成する、適合を証明する記録・変更の記録・参照資料に係る記録簿。脅威モデル、セキュリティ試験報告書、SBOMはここに綴じる\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>第36条第2項の「法令の規定等の適合性」という文言が要点です。セキュリティ機能の変更が第12条第3項への適合に影響するかの検証は、規格の要請である以前にQMS省令の要求であり、前掲の医薬機審発0423第1号による手続の判断はこの検証の出力として記録されるべきものです。なおセキュリティリスクは、第26条第3項が求める製品実現の全工程におけるリスクマネジメントの対象に含めます。\u003C\u002Fp>\u003Ch3 id=\"hf2aa6499bf\">苦情処理と厚生労働大臣等への報告に載せる（第55条の2／第55条の3）\u003C\u002Fh3>\u003Cp>QMS省令第55条の2第1項は、苦情処理の手順に含める事項として、第3号に苦情の調査、\u003Cstrong>第4号に法第68条の10第1項及び法第68条の11の規定に基づく報告の必要性の評価\u003C\u002Fstrong>、第6号に修正又は是正措置の必要性の評価を挙げています。サイバーセキュリティに起因する不具合等報告の要否判断は、この第4号の評価そのものです。第55条の3は同じ報告に係る手順の文書化と記録の作成・保管を求めています。医療機関からの連絡が苦情として入ることもIPA／JPCERT\u002FCC経由の脆弱性情報として入ることもありますが、入口が違っても報告の必要性の評価に合流させる設計が必要です（\u003Ca href=\"\u002Fblogs\u002Fcomplaint-handling\">QMSの苦情処理とは？\u003C\u002Fa>）。\u003C\u002Fp>\u003Ch3 id=\"hb9a32e9fc4\">記録として残す（第9条第2項・第3項）\u003C\u002Fh3>\u003Cp>セキュリティ対応の記録は、QMS省令第9条第2項の管理下に置きます。同項は、記録の識別、保管、\u003Cstrong>セキュリティ確保\u003C\u002Fstrong>（漏えい、滅失又は毀損の防止その他安全管理）、\u003Cstrong>完全性の確保\u003C\u002Fstrong>（記録が正確であり、作成された時点から不適切な改変がない状態を保つこと）、検索、保管期間及び廃棄についての管理方法に関する手順の文書化を求めています（記録の完全性の考え方は\u003Ca href=\"\u002Fblogs\u002Fdata-integrity\">データインテグリティとは？\u003C\u002Fa>）。医療機器等の使用によって得られた個人情報を保有する場合は、同条第3項により適正な管理方法を定めて管理します。SBOM導入・運用ガイドライン6.1.3も、SBOMの生成・更新・利用に関する記録を既存の文書・記録管理プロセスの中で管理し、内部監査や当局査察、QMS適合性調査等において説明可能な状態を維持することを求めています。\u003C\u002Fp>\u003Cp>脅威モデル、脆弱性の評価と対応判断、SBOMの版と承認履歴は、いずれも「誰がいつ何を根拠に判断したか」を後から問われる記録です。ファイルサーバーと表計算ソフトで運用していると、第9条第2項が求める完全性の確保を証明するのに手間がかかり、調査対応の場面で説明が滞ります。医療機器QMSに特化した電子QMSであれば、版管理・承認履歴・監査証跡が記録側の標準機能として残るため、脆弱性1件ごとの判断の経緯を時系列で追える状態を維持しやすくなります。あわせて、セキュリティの証跡を外部サービスに預ける以上、提供事業者自身の情報セキュリティ体制も選定基準に入れてください。\u003C\u002Fp>\u003Ch3 id=\"hd4d7c16489\">着手チェックリスト\u003C\u002Fh3>\u003Cp>該当性の判定→社内文書の特定→CL記載→SBOM体制→市販後手順の順に埋めてください。\u003C\u002Fp>\u003Cul>\u003Cli>[ ] 「プログラムを用いた医療機器」であり、他の機器及びネットワーク等と接続して使用するか、又は外部からの不正アクセス及び攻撃アクセス等が想定されるかを判定し、判定根拠を記録した\u003C\u002Fli>\u003Cli>[ ] 動作環境と使用環境（ネットワーク種別、OS、各種ライブラリ等）を特定し、システム構成図・ネットワーク構成図として文書化した\u003C\u002Fli>\u003Cli>[ ] リスクマネジメントのプロセスに、脆弱性の特定・脅威の評価・リスクコントロール・有効性の監視を組み込んだ\u003C\u002Fli>\u003Cli>[ ] JIS T 81001-5-1の箇条4〜9それぞれについて、適合を示す社内文書を特定した一覧を作成した\u003C\u002Fli>\u003Cli>[ ] IEC 81001-5-1等の国際規格を用いる場合、申請時に妥当性を説明する資料を準備した\u003C\u002Fli>\u003Cli>[ ] 基本要件基準CLの第12条第3項の欄に、適用・不適用、適合の方法、特定文書の確認を記載した\u003C\u002Fli>\u003Cli>[ ] セキュリティに対する対応方針と問い合わせ窓口を明確化し、顧客に対する脆弱性等の開示手順を定めた\u003C\u002Fli>\u003Cli>[ ] ソフトウェア保守計画に、製品寿命、脆弱性の監視、セキュリティ更新の実施計画、顧客への通知方針を定めた\u003C\u002Fli>\u003Cli>[ ] SBOMの適用範囲を定義し、構成パターンA〜Dのどれに当たるかを整理した\u003C\u002Fli>\u003Cli>[ ] SBOMを最小要素を満たす形式（SPDX 2.2以上／CycloneDX 1.6以上）で作成し、製品型番・バージョンとの対応を追跡でき、更新完了をリリース承認の条件に加えた\u003C\u002Fli>\u003Cli>[ ] SBOMツールの選定・導入について、購買管理（第37条〜第39条）とバリデーション（第5条の6）の要否を検討した\u003C\u002Fli>\u003Cli>[ ] IPA／JPCERT\u002FCCからの情報収集経路を確保し、脆弱性の受付・評価・修正・開示の手順を確立した\u003C\u002Fli>\u003Cli>[ ] 不具合等報告の要否判断を、苦情処理手順（第55条の2第1項第4号）と報告手順（第55条の3）に組み込んだ\u003C\u002Fli>\u003Cli>[ ] VPN装置等の付属機器について、医療機関との責任分界を保守契約等で明確にした\u003C\u002Fli>\u003Cli>[ ] 令和6年3月31日以前に製造販売した機器について、サイバーリスクの評価・対策とEOL／EOS情報の提供状況を棚卸しし、医療機関等の求めに応じてSBOMを提示できる準備（又は既にEOSなどに関する必要な情報提供をしており作成・提示を要しないことの記録）を整えた（医薬機審発0417第1号・医薬安発0417第1号）\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"h5377a4e205\">自社の医療機器は基本要件基準第12条第3項の対象になりますか？\u003C\u002Fh3>\u003Cp>プログラムを用いた医療機器で、①他の機器及びネットワーク等と接続して使用する、②外部からの不正アクセス及び攻撃アクセス等が想定される、のいずれかに当たれば対象です。①の「他の機器」にはUSB・SD・HDD・CD・DVD等の外部記録媒体、電子カルテ、外部から持ち込まれたPCが含まれ（薬生機審発0331第8号 記2（1））、有線・無線を問わないため常時接続していない機器でも該当し得ます。\u003C\u002Fp>\u003Ch3 id=\"hb866bc37e8\">JIS T 81001-5-1の「認証」を取得する必要がありますか？\u003C\u002Fh3>\u003Cp>求められているのは、製造販売業者等自身による適合性の確認です。高度管理医療機器・管理医療機器の承認申請又は認証申請ではJIS T 81001-5-1等への適合性を示す資料の添付が必要で、その示し方は、確認した結果を示すか、結果をまとめた社内文書等を特定することとされています（薬生機審発0523第1号 記）。薬生機審発0523第1号・薬生機審発0331第8号のいずれも、第三者認証の取得を求めてはいません。IEC 81001-5-1等の国際規格を用いることもできますが、申請時に妥当性を説明する必要があります（薬生機審発0331第8号 記3（2））。\u003C\u002Fp>\u003Ch3 id=\"h5e6dc85b3f\">一般医療機器（クラスI・届出）も対応が必要ですか？\u003C\u002Fh3>\u003Cp>必要です。ただし届出の際に資料の添付は要さないとされています（薬生機審発0331第8号 記3（4））。適合の確認等の記録は保管し、QMS適合性調査の調査権者の求めなどに応じて提示できる状態にしておく必要があります（同 記3（3））。市販後の不具合等報告についても、対象は医療機器のクラス分類を問いません（医薬安発0115第2号 別添 2.）。\u003C\u002Fp>\u003Ch3 id=\"h062da1acaf\">OSのバージョンを追加するときは一部変更承認申請が必要ですか？\u003C\u002Fh3>\u003Cp>医療機器としての機能の追加・変更等がない場合、動作環境であるOS等のバージョンの追加・変更・削除は一変申請も軽微変更届も不要です（次回の一変申請時に記載整備を要します）。一方、異なる種類のOSの追加やクラウド動作の追加は軽微変更届の対象です（医薬機審発0423第1号 別添）。製品の有効性及び安全性に関わる機能に影響する場合は本事例の対象外で、遠隔モニタリング目的でネットワーク接続する植込み型機器等も対象外です。なお、使用方法欄に動作環境として記載していない、製品に組み込んだOSSライブラリ等を脆弱性対応で更新する場合は、この事例集に直接該当する行がないため個別に判断します。\u003C\u002Fp>\u003Ch3 id=\"h0d62a68b89\">サイバーセキュリティに起因する不具合は報告義務がありますか？\u003C\u002Fh3>\u003Cp>薬機法第68条の10第1項に基づく不具合等報告の枠組みで扱います。基本的考え方は医薬安発0115第2号（令和6年1月15日）に示されており、脆弱性は全てが報告対象ではなく、SBOM及び設計情報等から影響を評価し、悪用が原因で死亡や重篤な健康被害が発生した場合又は発生するおそれがあると判断した場合に報告します。QMS省令側では第55条の2第1項第4号が報告の必要性の評価を、第55条の3が報告手順の文書化と記録を求めています。\u003C\u002Fp>\u003Ch3 id=\"hb7c9d61cd4\">SBOMはExcelで作ってはいけないのですか？\u003C\u002Fh3>\u003Cp>導入初期にExcel等で主要コンポーネントを可視化し、関係者間で構成認識を揃えることは有効とされています。ただしExcelのみの運用では、表記揺れの抑止、更新漏れの防止、ソフトウェア識別子を用いた自動照合、変更履歴の一貫管理に限界があります。継続的な活用には、標準フォーマット（SPDX 2.2以上／CycloneDX 1.6以上）への対応、ツールによる一元管理、表記揺れを吸収する正規化を段階的に導入する必要があります（SBOM導入・運用ガイドライン 2.4・2.5）。\u003C\u002Fp>\u003Ch2 id=\"ha214098e44\">まとめ\u003C\u002Fh2>\u003Cp>医療機器サイバーセキュリティの規制対応は、基本要件基準第12条第3項の該当性判定から始まり、JIS T 81001-5-1の箇条ごとに適合を示す社内文書を特定し、市販後の脆弱性管理と報告・変更手続を回し続けるところまでが一続きです。\u003C\u002Fp>\u003Cul>\u003Cli>適合は、製造販売業者等自身が確認し、箇条4〜9それぞれについて「結果を示すか、結果をまとめた社内文書等を特定する」ことで示す（薬生機審発0523第1号）\u003C\u002Fli>\u003Cli>令和6年4月1日以降の承認申請・認証申請は適合資料の添付が必要。既存品も次の一変で対応が必要になるため、一変予定のある品目から着手する\u003C\u002Fli>\u003C\u002Ful>\u003Cp>適合を示す社内文書、脅威モデル、脆弱性ごとの評価と判断の記録、SBOMの版と承認履歴は、いずれもQMS適合性調査で提示を求められる可能性があります。医療機器QMSに特化した電子QMSであるQMSmartのように、版管理・承認履歴・監査証跡を標準機能として備えた基盤の上に記録を載せておくと、脆弱性が公表されるたびに文書を探し回る状態から抜け出せます。まずは対象製品の該当性を判定し、判定根拠を1枚の記録に残すところから始めてください。\u003C\u002Fp>",{"url":99,"height":12,"width":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F10a75b5e02e7402fb8eb738c43498d01\u002F3.webp","医療機器サイバーセキュリティの規制対応を解説。基本要件基準第12条第3項の該当性判定、JIS T 81001-5-1で適合を示す社内文書、2026年8月のSBOM導入・運用ガイドライン、市販後の脆弱性管理をQMS省令の条番号付きで整理。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":102,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},{"url":21,"height":22,"width":23},[104,105,106],{"id":58,"createdAt":59,"updatedAt":59,"publishedAt":59,"revisedAt":59,"name":60},{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":63,"createdAt":64,"updatedAt":64,"publishedAt":64,"revisedAt":64,"name":65},{"id":108,"createdAt":109,"updatedAt":110,"publishedAt":110,"revisedAt":110,"title":111,"content":112,"eyecatch":113,"description":115,"reviewer":116,"category":118},"cfr-part11","2026-08-26T03:31:08.333Z","2026-08-31T13:37:22.591Z","21 CFR Part 11とは？医療機器の対応要否と4つの場面","\u003Cp>21 CFR Part 11は、FDA（米国食品医薬品局）が規制する電子記録と電子署名の要件を定めた連邦規則です。日本の医療機器メーカーにとっては「米国向けの話」と受け止められがちですが、FDAへの申請、査察対応、米国子会社やOEM先からの要求、eQMS（電子QMS）の導入検討という4つの場面で対応の要否を判断する必要が生じます。本記事では適用範囲と条項ごとの要求事項を整理し、2026年2月2日に施行されたQMSRとの関係、日本のQMS省令との位置づけ、システム選定時の確認項目までをまとめます。\u003C\u002Fp>\u003Ch2 id=\"h2053ff89fb\">21 CFR Part 11とは？対応が必要になる4つの場面\u003C\u002Fh2>\u003Cp>21 CFR Part 11は、米国連邦規則集タイトル21のPart 11「\u003Ca href=\"https:\u002F\u002Fwww.ecfr.gov\u002Fcurrent\u002Ftitle-21\u002Fpart-11\">Electronic Records; Electronic Signatures\u003C\u002Fa>（電子記録・電子署名）」を指し、FDAが1997年3月20日に公示し、同年8月20日に施行した規則です（62 FR 13430）。電子記録と電子署名が紙の記録・手書き署名と同等に信頼できると認められるための条件を定めており、Subpart A（総則）、Subpart B（電子記録）、Subpart C（電子署名）の3部で構成されます。\u003C\u002Fp>\u003Ch3 id=\"hf056f0209a\">適用範囲は「前提規則」で決まる\u003C\u002Fh3>\u003Cp>Part 11が適用されるかどうかは、その記録が\u003Cstrong>FDAの他の規制（前提規則＝predicate rules）によって作成・保管・提出を求められているか\u003C\u002Fstrong>で決まります（§11.1）。医療機器メーカーの場合、前提規則にあたるのは主に21 CFR Part 820（QMSR）や21 CFR Part 803（不具合報告）です。\u003C\u002Fp>\u003Cp>ここから2つの帰結が導かれます。第一に、前提規則が存在しない記録は、電子化していてもPart 11の対象外です。第二に、前提規則が求める記録であっても\u003Cstrong>紙で作成・保管している限りPart 11は適用されません\u003C\u002Fstrong>（§11.1(b)は「電子的手段で伝送された紙記録には本パートを適用しない」と定めています）。Part 11は「電子で扱うなら満たすべき条件」であって、電子化そのものを義務づけるものではありません（§11.2）。\u003C\u002Fp>\u003Ch3 id=\"h1c699f675a\">対応要否の早見表\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>自社の状況\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>Part 11の対応\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>判断の根拠\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>日本国内のみで販売。FDAへの申請・登録なし\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>不要（QMS省令・ER\u002FES指針は別途適用）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>前提規則が存在しない\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>FDAへ510(k)\u002FPMAを申請予定。QMSの記録は紙で運用\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>原則不要\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子記録を使用していない\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>FDA登録済み。設計管理・CAPA・苦情処理の記録を電子で作成・保管\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>必要\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>QMSRが求める記録を電子で扱う\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>米国子会社・OEM先のFDA登録製品に関する記録を自社システムで保持\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>必要\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>前提規則の対象記録を保持している\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>FDA査察で電子記録を画面提示・出力する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>必要\u003C\u002Fstrong>（§11.10(b)の複製提供を含む）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>査察対象記録が電子形式\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3 id=\"h3451625959\">対応が問われる4つの場面\u003C\u002Fh3>\u003Cp>実務でPart 11が表面化するのは、次の4つの場面です。\u003C\u002Fp>\u003Col>\u003Cli>\u003Cstrong>FDA向け申請（510(k)\u002FPMA）\u003C\u002Fstrong> — 申請の裏づけとなる設計管理記録やバリデーション記録を電子で保持していれば、前提規則（QMSR）の対象記録としてPart 11の要求を受けます。\u003C\u002Fli>\u003Cli>\u003Cstrong>FDA査察\u003C\u002Fstrong> — 査察官は電子記録を画面上で確認し、複製の提出を求めます。エクスポート機能がないシステムは§11.10(b)の不備として指摘されます。\u003C\u002Fli>\u003Cli>\u003Cstrong>米国子会社・OEM先からの要求\u003C\u002Fstrong> — 自社が直接FDAに登録していなくても、供給先が登録企業なら供給者管理の一環として問われます。求められるのはカタログ上の「Part 11対応」表示ではなく、システム機能・運用手順・バリデーション記録の3点セットです。\u003C\u002Fli>\u003Cli>\u003Cstrong>eQMS・電子文書管理システムの導入\u003C\u002Fstrong> — 選定段階で要求を把握していないと、導入後に不足が判明して追加開発が必要になります。導入前の要件定義に落とし込むのが最も安価です。\u003C\u002Fli>\u003C\u002Fol>\u003Ch2 id=\"h8873bad7a9\">電子記録の要求事項：§11.10 クローズドシステムの管理\u003C\u002Fh2>\u003Cp>電子記録に対する中核の要求は§11.10「クローズドシステムの管理」に集約され、(a)から(k)までの11項目が定められています。クローズドシステムとは、記録の内容に責任を持つ者がシステムへのアクセスを管理しているシステムを指し、社内で運用するeQMSや文書管理システムの多くがこれに該当します（§11.3の定義）。\u003C\u002Fp>\u003Ch3 id=\"h8232604617\">§11.10 (a)〜(k) の要求事項\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>条項\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>要求事項\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>実務で問われること\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(a)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>システムのバリデーション（正確性・信頼性・一貫した意図どおりの動作、および\u003Cstrong>無効又は改変された記録を識別できること\u003C\u002Fstrong>）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>導入時のバリデーションと、変更時の再バリデーション\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(b)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>人が読める形式と電子形式で、正確かつ完全な複製をFDAの査察・レビュー・複写のために提供できること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>PDF出力・CSVエクスポート等の手段の有無\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(c)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>保管期間を通じて記録を保護し、正確かつ速やかに検索できる状態を維持すること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バックアップ、媒体・ファイル形式の陳腐化対策\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(d)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>システムアクセスを権限を与えられた者に限定すること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ロール設計、退職・異動時のアカウント停止\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(e)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>安全でコンピュータが自動生成する、タイムスタンプ付きの監査証跡\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>後述\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(f)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>操作順序のチェック（手順・イベントの許容される順序を強制）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認前に発行できない等のワークフロー制御\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(g)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>権限のチェック（システム使用・電子署名・記録の変更を許可された者だけが行えること）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>承認権限の設定と、その設定変更の記録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(h)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>機器のチェック（データ入力元や操作指示の有効性の判定）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>測定機器等からの自動取込がある場合\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(i)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>開発・保守・使用する要員の教育・訓練・経験の確認\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>教育訓練記録との紐付け\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(j)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>自らの電子署名で開始した行為に責任を負わせる文書化された方針の策定と遵守\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名に関するSOPと周知記録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(k)\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>システム文書（操作・保守手順書）の配付・アクセス・使用の管理と変更管理\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>手順書自体の版管理\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3 id=\"h1bab32017d\">§11.10(e) が求める監査証跡\u003C\u002Fh3>\u003Cp>§11.10(e)は、電子記録の作成・変更・削除について、\u003Cstrong>操作者・日時・操作内容を独立して記録する監査証跡\u003C\u002Fstrong>を求めています。要件は次の4点です。\u003C\u002Fp>\u003Cul>\u003Cli>安全であり、\u003Cstrong>コンピュータが自動生成する\u003C\u002Fstrong>こと（手入力の変更履歴台帳では要件を満たしません）\u003C\u002Fli>\u003Cli>\u003Cstrong>タイムスタンプ付き\u003C\u002Fstrong>であること\u003C\u002Fli>\u003Cli>変更前の情報を\u003Cstrong>上書きしない\u003C\u002Fstrong>こと（旧値と新値の双方が追跡できること）\u003C\u002Fli>\u003Cli>記録の保管期間\u003Cstrong>以上\u003C\u002Fstrong>保持し、FDAの閲覧・複写に供せること\u003C\u002Fli>\u003C\u002Ful>\u003Cp>なお、監査証跡そのものの考え方やALCOA+との関係は\u003Ca href=\"\u002Fblogs\u002Fdata-integrity\">データインテグリティ（ALCOA+）の実践ガイド\u003C\u002Fa>で詳しく解説しています。本記事ではPart 11が条項として何を要求しているかに絞ります。\u003C\u002Fp>\u003Ch3 id=\"hd4e79c0711\">§11.30 オープンシステムの管理\u003C\u002Fh3>\u003Cp>記録の内容に責任を持つ者がシステムアクセスを管理していないシステムはオープンシステムに分類され、§11.30が適用されます（§11.3の定義）。§11.10の要求に加えて、記録の真正性・完全性・必要に応じた機密性を担保するために、\u003Cstrong>文書の暗号化や適切なデジタル署名標準の使用\u003C\u002Fstrong>といった追加の措置が求められます。\u003C\u002Fp>\u003Cp>判断の基準は、設置場所やクラウドかどうかではなく\u003Cstrong>アクセス制御を誰が握っているか\u003C\u002Fstrong>です。SaaS型のeQMSであっても、自社がアカウントの発行・権限設定・失効を管理しているならクローズドシステムに該当します。\u003C\u002Fp>\u003Ch2 id=\"ha1306e65ed\">電子署名の要求事項：署名の表示・記録との結合・本人確認\u003C\u002Fh2>\u003Cp>電子署名の要求は、Subpart B の§11.50・§11.70と、Subpart C の§11.100〜§11.300に分かれています。前者は「署名として何を表示し、記録とどう結びつけるか」、後者は「その署名が本人のものであることをどう担保するか」を定めています。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>条項\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>要求事項の要点\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.50\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>署名した電子記録には、\u003Cstrong>署名者の印字された氏名・署名を実行した日時・署名の意味\u003C\u002Fstrong>（レビュー、承認、責任、作成\u003Cstrong>など\u003C\u002Fstrong>。原文は "such as" による例示で、この4つに限定されない）を含める。これらは電子記録と同じ管理下に置き、画面表示や印刷物など人が読める形式にも表示する\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.70\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名・手書き署名を対応する電子記録に\u003Cstrong>結合\u003C\u002Fstrong>し、署名を切り出し・複写・転記して記録を偽造できないようにする\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.100\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名は\u003Cstrong>個人に一意\u003C\u002Fstrong>であり、再利用・再割当てをしない(a)。署名を付与する前に\u003Cstrong>本人確認\u003C\u002Fstrong>を行う(b)。電子署名が手書き署名と法的に同等であることをFDAに証明する文書を、手書き署名して提出する(c)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.200\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>生体認証によらない電子署名は、IDコードとパスワードなど\u003Cstrong>2つ以上の識別要素\u003C\u002Fstrong>を用いる。連続したセッション中の最初の署名は全要素、以降は本人しか実行できない1要素でよいが、セッションをまたぐ場合は毎回全要素を用いる。他人の署名を使用するには2名以上の共謀が必要な設計とする\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.300\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>IDコードとパスワードの組み合わせの一意性(a)、定期的な確認・失効・改訂(b)、紛失・盗難時の失効と代替発行の手順(c)、不正使用の検知・報告の仕組み(d)、トークン等の初回および定期的な試験(e)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>実務で見落とされやすいのが§11.100(c)です。これは「自社の電子署名は手書き署名と法的に同等である」と証明する文書に関する要求で、システム機能では代替できません。\u003Cstrong>電子署名の使用開始前（または使用と同時）までにFDAへ実際に提出する必要があり\u003C\u002Fstrong>、社内で整備しただけでは満たされません。提出は手書き署名を付した書面で行い、電子・紙のいずれの形式でも受け付けられます。提出先はFDAの「Letters of Non-Repudiation Agreement」のページで案内されています（§11.100(c)(1)）。\u003C\u002Fp>\u003Cp>§11.200(a)(1)の「連続したセッション中の2回目以降は1要素でよい」という規定は、裏を返せば\u003Cstrong>セッションが切れたら再度すべての要素を求める\u003C\u002Fstrong>ということです。業務システムのログイン状態をそのまま署名に流用する設計は、この要求を満たさない可能性があります。\u003C\u002Fp>\u003Ch2 id=\"h6a8af680a8\">FDAの執行スタンスとQMSR施行後のPart 11\u003C\u002Fh2>\u003Cp>Part 11は1997年の制定以来、条文自体はほとんど変わっていませんが、FDAの執行方針とその周辺のガイダンスは大きく動いています。2026年時点で押さえるべきは、2003年の裁量的執行、2026年2月のCSA改訂ガイダンス、そして2026年2月2日のQMSR施行の3点です。\u003C\u002Fp>\u003Ch3 id=\"hcdb2485985\">2003年ガイダンスによる裁量的執行\u003C\u002Fh3>\u003Cp>FDAは2003年に「Part 11, Electronic Records; Electronic Signatures — Scope and Application」を発出し、\u003Cstrong>バリデーション・監査証跡・記録の保管・記録の複製\u003C\u002Fstrong>の各要求と、\u003Cstrong>Part 11の発効前から稼働していたシステム（レガシーシステム）に対するすべての要求\u003C\u002Fstrong>について、裁量的執行（enforcement discretion）の方針を示しました。\u003C\u002Fp>\u003Cp>ただしこれは「対応しなくてよい」という意味ではありません。同ガイダンスは裁量的執行の対象を上記に限ったうえで、\u003Cstrong>それ以外の規定は執行する\u003C\u002Fstrong>と明言し、例として§11.10(d)のアクセス制限、(f)の操作順序チェック、(g)の権限チェック、そして§11.30のオープンシステムの管理を名指ししています。\u003Cstrong>電子署名に関する条項（§11.50・§11.70・§11.100・§11.200・§11.300）も丸ごとこのリストに含まれており\u003C\u002Fstrong>、次章で扱う電子署名の要求は当初から裁量的執行の対象外です。\u003C\u002Fp>\u003Cp>医療機器メーカーの場合、頼れる範囲はさらに限られます。FDAは後述のCSAガイダンスで、バリデーションに関する裁量的執行は\u003Cstrong>ISO 13485の4.1.6・7.5.6・7.6に基づく製造・品質マネジメントシステム用ソフトウェアのバリデーション要求には適用されない\u003C\u002Fstrong>と明示しました。QMSRがISO 13485:2016を引用している以上、バリデーションはQMSR側の要求として独立に残ります。\u003C\u002Fp>\u003Ch3 id=\"h2dcefdc9cc\">CSAガイダンスとバリデーション要求（現行版は2026年2月3日発出）\u003C\u002Fh3>\u003Cp>§11.10(a)が求めるシステムのバリデーションについては、FDAが2025年9月24日にCSA（Computer Software Assurance）の最終ガイダンスを発出し（Federal Register 2025-18468／90 FR 45945）、\u003Cstrong>2026年2月3日に改訂版「Computer Software Assurance for Production and Quality Management System Software」を発出しました（Docket No. FDA-2022-D-0795）。\u003C\u002Fstrong>現行版はこの2026年2月3日版で、2025年9月版は置き換えられています。改訂の理由は、ガイダンス末尾のGuidance History表にFDA自身が記載しています。Level 2ガイダンス手続き（21 CFR 10.115(g)(4)）に基づく改訂であり、21 CFR Part 820の改正（QMSR）との整合が目的です。名称が「Quality System」から「Quality Management System」に変わったのもこれに伴うもので、2025年9月版の脚注2でも、規則の施行後にPart 820への参照を規則に合わせて更新すると予告されていました。\u003C\u002Fp>\u003Cp>2025年9月版は2022年9月13日のドラフト（87 FR 56059）を最終化したもので、2026年2月版はそれを改訂したものです。いずれの版も「\u003Ca href=\"https:\u002F\u002Fwww.fda.gov\u002Fregulatory-information\u002Fsearch-fda-guidance-documents\u002Fgeneral-principles-software-validation\">General Principles of Software Validation\u003C\u002Fa>」の第6章（Validation of Automated Process Equipment and Quality System Software）を置き換えます。内容は、リスクに応じて検証の厚みを変えるアプローチを認めるものです。なお本ガイダンスは、医療機器そのものに該当するソフトウェア（device software functions／SaMD等）の設計・開発における検証・バリデーション要求については扱いません。\u003C\u002Fp>\u003Ch3 id=\"h8984154802\">CSAガイダンスが示したPart 11の適用判断\u003C\u002Fh3>\u003Cp>2026年2月3日版のCSAガイダンスは、製造・品質マネジメントシステムに使うソフトウェアについて「いつPart 11が適用されるか」をFDA自身が整理した節を持ちます。判断の軸は、\u003Cstrong>その文書がPart 820（QMSR）で要求されるものかどうか\u003C\u002Fstrong>です。\u003C\u002Fp>\u003Cp>FDAは「Part 820が要求する文書を電子形式で保持しているなら、一般にPart 11が適用される」とし、\u003Cstrong>とりわけ\u003C\u002Fstrong>考慮すべき点として「\u003Cstrong>バリデーション済みの状態を裏づける証拠として必要な記録か\u003C\u002Fstrong>」を挙げています（考慮事項はこれに限られません）。たとえば、基幹管理システムが製造前の材料チェックを正しく確実に自動化していることを示す文書はこれに該当し、電子形式であればPart 11の対象になります。一方、市販ソフトウェアが起動時に自動保存する一般的な動作ログは、その証拠として必要でない限り対象外とされています。社内の電子記録を棚卸しする際は、この軸がまず仕分けの出発点になります。\u003C\u002Fp>\u003Ch3 id=\"h75b53061af\">QMSR施行後もPart 11は存続する\u003C\u002Fh3>\u003Cp>2026年2月2日、21 CFR Part 820を改正しISO 13485:2016を引用するQMSRが施行されました。ここで誤解が生じやすいのですが、\u003Cstrong>QMSRはPart 11を置き換えるものではありません\u003C\u002Fstrong>。Part 11はPart 820とは独立した規則であり、QMSR施行後も電子記録・電子署名の要求はそのまま残ります。QMSRが求める設計管理・CAPA・苦情処理・内部監査などの記録を電子的に扱う場合、引き続きPart 11が適用されます。\u003C\u002Fp>\u003Ch2 id=\"he54039d1e0\">日本のQMS省令・施行通知との関係\u003C\u002Fh2>\u003Cp>日本の医療機器メーカーには、Part 11とは別に電磁的記録に関する国内の要求が適用されます。根拠はQMS省令の第9条（記録側）と第8条（文書側）で、Part 11と条項単位で対応づけて設計すると二重対応を避けられます。\u003C\u002Fp>\u003Cp>記録側の根拠はQMS省令第9条（記録の管理）第2項です。同項は記録について「セキュリティ確保（当該記録について、漏えい、滅失又は毀損の防止その他安全管理を行うことをいう。）」と「完全性の確保（当該記録が正確であり、記録が作成された時点から不適切な改変がない状態を保つことをいう。）」の管理方法を文書化するよう求めており、§11.10の(c)(d)(e)に相当する日本法上の根拠となります。\u003C\u002Fp>\u003Cp>文書側の根拠は第8条（品質管理監督文書の管理）第2項第7号「品質管理監督文書の劣化又は紛失を防止すること」で、施行通知（薬生監麻発0326第4号）14．第8条関係（8）はこの例として「文書を電磁的に管理する場合にはそのバックアップ等必要な管理方法を定めること」を挙げています。詳細は\u003Ca href=\"\u002Fblogs\u002Fdocument-management\">QMSの文書管理システムとは？\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"hde02581614\">施行通知が参照するER\u002FES指針との位置づけ\u003C\u002Fh3>\u003Cp>施行通知14．第8条関係（9）は、電磁的管理の方法について「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」（平成17年4月1日付薬食発第0401022号厚生労働省医薬食品局長通知）＝いわゆるER\u002FES指針を参照することが望ましいとしています。ただしPart 11とER\u002FES指針は別制度であり、\u003Cstrong>一方に適合すれば他方も自動的に満たされるわけではありません\u003C\u002Fstrong>。ER\u002FES指針の三要件（真正性・見読性・保存性）への具体的な対応方法は\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation-guide\">ソフトウェアバリデーション実践ガイド\u003C\u002Fa>で解説しています。\u003C\u002Fp>\u003Ch2 id=\"h6aa697a0d6\">Part 11対応チェックリストとeQMS選定時の確認項目\u003C\u002Fh2>\u003Cp>Part 11への適合は、\u003Cstrong>システム機能・運用手順・バリデーション記録の3点が揃って初めて成立します\u003C\u002Fstrong>。「Part 11対応」と表示された製品を導入しただけでは適合しません。以下のチェックリストで自社の現状を棚卸ししてください。\u003C\u002Fp>\u003Ch3 id=\"h9d0ebf7617\">自社運用のチェックリスト\u003C\u002Fh3>\u003Cul>\u003Cli>[ ] 適用対象となる記録の範囲を特定し、文書化している（前提規則との対応づけ）\u003C\u002Fli>\u003Cli>[ ] 対象システムのバリデーションを実施し記録を保管している（§11.10(a)）\u003C\u002Fli>\u003Cli>[ ] 電子記録を人が読める形式と電子形式で出力できる（§11.10(b)）\u003C\u002Fli>\u003Cli>[ ] バックアップと復旧手順を定め、復旧テストを実施している（§11.10(c)）\u003C\u002Fli>\u003Cli>[ ] アクセス権限をロールで設計し、退職・異動時の停止手順がある（§11.10(d)）\u003C\u002Fli>\u003Cli>[ ] 監査証跡が自動生成され、旧値を上書きせず保管期間以上残る（§11.10(e)）\u003C\u002Fli>\u003Cli>[ ] 承認前の発行を防ぐなど操作順序を制御する仕組みがある（§11.10(f)(g)）\u003C\u002Fli>\u003Cli>[ ] 開発・保守・使用に関わる要員の教育訓練記録がある（§11.10(i)）\u003C\u002Fli>\u003Cli>[ ] 電子署名に関する社内方針を文書化し、周知記録がある（§11.10(j)）\u003C\u002Fli>\u003Cli>[ ] 電子署名に氏名・日時・意味が表示され、記録と結合されている（§11.50／§11.70）\u003C\u002Fli>\u003Cli>[ ] 使用開始前までに手書き署名を付した証明文書をFDAへ提出済みである（§11.100(c)）\u003C\u002Fli>\u003Cli>[ ] IDコード・パスワードの一意性・有効期限・紛失時の手順を定めている（§11.300）\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"h8107d13007\">eQMSベンダーに確認すべき7項目\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>#\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>確認項目\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>対応条項\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>1\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>監査証跡が自動生成され、管理者を含む誰も編集・削除できないこと（§11.10(e)の趣旨を満たす実務水準として）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(e)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>監査証跡が旧値と新値の双方を保持し、保管期間以上残ること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(e)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>3\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>役割ベースのアクセス制御と、権限設定変更の履歴が残ること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(d)(g)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>4\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>電子署名に氏名・日時・意味が表示され、出力物にも反映されること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.50\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>署名が記録と結合され、切り離しや転記ができない設計であること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.70\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>6\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>パスワード有効期限・失効・不正試行の検知機能があること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.300\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ベンダーがバリデーション用の文書（テストスクリプト等）を提供し、供給者監査に応じること\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>§11.10(a)\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>日本の医療機器メーカーの場合、eQMSを導入する時点でQMS省令第5条の6（ソフトウェアの使用）が適用される点にも注意が必要です。同条第1項は品質管理監督システムにソフトウェアを使用する場合のバリデーション手順の文書化を、第2項は初回使用時および変更時のバリデーション実施を求めています。つまり、Part 11対応とQMS省令対応は\u003Cstrong>同じバリデーション作業のなかで同時に満たすことができます\u003C\u002Fstrong>。\u003C\u002Fp>\u003Cp>文書管理や記録の電子化を検討する段階であれば、医療機器QMSに特化した\u003Ca href=\"\u002Fblogs\u002Feqms-introduction\">電子QMSの導入\u003C\u002Fa>を選択肢に入れる価値があります。\u003Ca href=\"https:\u002F\u002Fservice.qm-smart.com\u002F?utm_source=yakuji-navi&utm_medium=link&utm_campaign=cfr-part11\">QMSmart\u003C\u002Fa>は監査証跡・電子署名・アクセス制御を標準機能として備えており、上記7項目の確認とバリデーション文書の整備を導入プロセスのなかで進められます。\u003C\u002Fp>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"h3ac6b4d3b0\">日本国内向けだけの医療機器メーカーも21 CFR Part 11に対応する必要がありますか？\u003C\u002Fh3>\u003Cp>原則として不要です。Part 11は前提規則が作成・保管を求める記録に適用されるため、FDAへの申請・登録がなく米国市場と関わりがなければ対象外です。ただしQMS省令第8条・第9条とER\u002FES指針は適用されるため、電子記録の管理そのものは必要です。\u003C\u002Fp>\u003Ch3 id=\"hf8fe00013d\">紙で運用していれば21 CFR Part 11の対象外ですか？\u003C\u002Fh3>\u003Cp>対象外です（§11.1(b)）。Part 11は電子で扱う場合の条件を定めた規則で、電子化を義務づけるものではありません（§11.2）。ただし2003年ガイダンスは、紙に加えて電子でも記録を保持し、その電子記録を規制対象業務の遂行に依拠している場合はPart 11の対象になるとしています。紙と電子が混在する運用では、どちらが「正」かを手順書で明確にしておかないと、査察時に電子側の管理不足を指摘される可能性があります。\u003C\u002Fp>\u003Ch3 id=\"hf06d156fe7\">「Part 11対応」と書かれたクラウドサービスを使えば自動的に適合しますか？\u003C\u002Fh3>\u003Cp>適合しません。Part 11への適合はシステム機能・運用手順・バリデーション記録の3点で成立します。ベンダーが提供できるのはシステム機能だけで、アクセス権限の設計、電子署名に関する社内方針（§11.10(j)）、要員の教育訓練記録（§11.10(i)）、自社環境でのバリデーションは利用者側の責任です。\u003C\u002Fp>\u003Ch3 id=\"h4d4061fc27\">電子署名は電子契約サービスの署名と同じものですか？\u003C\u002Fh3>\u003Cp>同じではありません。Part 11の電子署名は§11.50の表示事項（氏名・日時・署名の意味）、§11.70の記録との結合、§11.100〜§11.300の本人確認と識別要素の管理を満たす必要があります。一般的な電子契約サービスは契約文書への署名を目的としており、QMSの記録に対する継続的な管理までは想定していない場合があります。\u003C\u002Fp>\u003Ch3 id=\"hcca77a5884\">監査証跡はどのくらいの期間保管する必要がありますか？\u003C\u002Fh3>\u003Cp>§11.10(e)は、監査証跡を\u003Cstrong>対象となる電子記録の保管期間以上\u003C\u002Fstrong>保持し、FDAの閲覧・複写に供することを求めています。したがって保管期間は前提規則側で決まります。日本国内の記録については、QMS省令第9条第5項により第68条が定める期間の保管が別途求められます（第67条は品質管理監督文書の保管期限で、記録側とは別の条です）。Part 11と第68条の両方の要求を満たす長い方の期間を設定するのが実務的です。\u003C\u002Fp>\u003Ch3 id=\"h2c4434bf86\">ER\u002FES指針に対応していれば21 CFR Part 11も満たせますか？\u003C\u002Fh3>\u003Cp>自動的には満たせません。両者は別制度で要求の粒度も異なります。Part 11は§11.10(a)〜(k)や§11.200の識別要素など管理項目を条項単位で定めているため、ER\u002FES指針の三要件（真正性・見読性・保存性）を満たす運用でも条項ごとの対応確認が別途必要です。ER\u002FES指針側の対応方法は\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation-guide\">ソフトウェアバリデーション実践ガイド\u003C\u002Fa>で解説しています。\u003C\u002Fp>\u003Ch3 id=\"hb46afab6fd\">QMSR（2026年2月2日施行）でPart 11の要求は変わりましたか？\u003C\u002Fh3>\u003Cp>変わっていません。QMSRは21 CFR Part 820を改正しISO 13485:2016を引用したものですが、Part 11は独立した規則のため施行後も要求はそのまま残ります。QMSRが求める設計管理・CAPA・苦情処理などの記録を電子的に扱う場合、引き続きPart 11が適用されます。\u003C\u002Fp>\u003Ch2 id=\"ha214098e44\">まとめ\u003C\u002Fh2>\u003Cul>\u003Cli>21 CFR Part 11は、FDAの前提規則が求める記録を\u003Cstrong>電子で扱う場合\u003C\u002Fstrong>に適用されます。紙運用のみ、あるいはFDAとの関わりがなければ対象外です（§11.1(b)／§11.2）\u003C\u002Fli>\u003Cli>中核は§11.10のクローズドシステムの管理(a)〜(k)。電子署名は§11.50・§11.70と§11.100〜§11.300が規定し、\u003Cstrong>§11.100(c)の証明文書は使用開始前までにFDAへ実際に提出\u003C\u002Fstrong>が必要です\u003C\u002Fli>\u003Cli>2003年ガイダンスの裁量的執行は免除を意味しません。§11.10(d)(f)(g)は当初から執行対象で、バリデーションの進め方は\u003Cstrong>2026年2月改訂のCSAガイダンス\u003C\u002Fstrong>（現行版）が示しています\u003C\u002Fli>\u003Cli>QMSR施行後もPart 11は存続します。日本のQMS省令第9条第2項・第8条第2項第7号・第5条の6と対応づけ、一度のバリデーションで両方を満たす設計が効率的です。適合はシステム機能・運用手順・バリデーション記録の3点で成立し、eQMS選定時は本記事の7項目でベンダーに確認してください\u003C\u002Fli>\u003C\u002Ful>",{"url":114,"height":51,"width":52},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F1847bbb4658b46e7b1b139f9ceed8dac\u002Fpart11.webp","21 CFR Part 11（電子記録・電子署名）を医療機器メーカーの視点で解説。対応が必要になる4つの場面、§11.10のアクセス制御や電子署名の要件、QMSR施行後の位置づけとQMS省令との関係をチェックリスト付きで整理します。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":117,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},{"url":21,"height":22,"width":23},[119,120,121],{"id":38,"createdAt":39,"updatedAt":39,"publishedAt":39,"revisedAt":39,"name":40},{"id":63,"createdAt":64,"updatedAt":64,"publishedAt":64,"revisedAt":64,"name":65},{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":123,"createdAt":124,"updatedAt":125,"publishedAt":125,"revisedAt":125,"title":126,"content":127,"eyecatch":128,"description":130,"reviewer":131,"category":133},"iec-62304","2026-08-26T03:31:09.495Z","2026-08-31T13:25:43.217Z","IEC 62304とは？医療機器ソフトウェア開発の実務","\u003Cp>医療機器にソフトウェアを搭載する、あるいはソフトウェアそのものを医療機器として承認申請する場合、IEC 62304（国内ではJIS T 2304）への適合が求められます。ただし規格の目次を読んでも、自社が何をどこまでやればよいのかは見えてきません。作業量を左右するのは安全クラスの判定であり、実務で最も詰まるのはSOUP（開発過程が不明なソフトウェア）の管理です。\u003C\u002Fp>\u003Cp>この記事では、安全クラスA・B・Cの判定と格下げの条件、クラス別に要求されるプロセスの違い、SOUP管理の要求事項、QMS省令の設計開発プロセス（第30条〜第36条の2）への載せ方を、箇条番号と条文に沿って整理します。\u003C\u002Fp>\u003Ch2 id=\"h1ff0f136dc\">IEC 62304とは？対象範囲と規格の版\u003C\u002Fh2>\u003Cp>IEC 62304は、\u003Cstrong>医療機器ソフトウェアの開発と保守について、ライフサイクル全体で実施すべきプロセス・アクティビティ・タスクを規定した国際規格\u003C\u002Fstrong>です。国内ではJIS T 2304として制定されており、現行版はJIS T 2304:2017（IEC 62304:2006およびAmendment 1:2015に一致）です。\u003C\u002Fp>\u003Cp>規定しているのは\u003Cstrong>製品の性能ではなく開発のプロセス\u003C\u002Fstrong>です。適合とは「ソフトウェア安全クラスに従って、この規格で特定した全てのプロセス、アクティビティ及びタスクを実行すること」（箇条1.4）であり、成果物の記録がなければ適合を主張できません。\u003C\u002Fp>\u003Ch3 id=\"hd1a3f4958f\">対象になるソフトウェアと、対象にならないソフトウェア\u003C\u002Fh3>\u003Cp>適用範囲は「\u003Cstrong>ソフトウェアそれ自体が医療機器である場合、又はソフトウェアが完成品である医療機器に組み込まれているか若しくは不可欠な部分となっている場合\u003C\u002Fstrong>」（箇条1.2）で、プログラム医療機器（SaMD）と組込みソフトウェアの両方が対象です。医療機器としての妥当性確認と最終的なリリースは対象外で、JIS T 0601-1やIEC 82304-1といった製品規格が担います。\u003C\u002Fp>\u003Cp>一方、\u003Cstrong>QMSの運用に使うソフトウェアはIEC 62304の対象ではありません\u003C\u002Fstrong>。文書管理システム、製造設備の制御ソフト、測定機器の解析ソフトなどは、QMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令。平成16年厚生労働省令第169号）第5条の6（ソフトウェアの使用）、第45条（製造工程等のバリデーション）、第53条（監視及び測定に係る設備及び器具の管理。第8項が監視及び測定に使用するソフトウェアの適用のバリデーション、第11項がその結果の記録を要求）が求めるバリデーションの対象で、要求の性質が異なります。「医療機器そのものを作る話」か「QMSを回すために導入した道具の話」かで、参照すべき規格も条文も変わります。\u003C\u002Fp>\u003Ch3 id=\"h76698532e1\">IEC 62304とJIS T 2304の版の対応\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>規格・版\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>内容\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>IEC 62304:2006（初版）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>医療機器ソフトウェア―ソフトウェアライフサイクルプロセス\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>IEC 62304 Amendment 1:2015\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>安全クラス判定の考え方の明確化、レガシーソフトウェア（箇条4.4）の追加など\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>JIS T 2304:2012\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>IEC 62304:2006 に対応（旧版）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>JIS T 2304:2017\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>IEC 62304:2006 + Amd.1:2015 に一致（IDT）。国内の現行版\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>古い解説はJIS T 2304:2012を前提にしている場合があります。安全クラスAの定義はAmendment 1:2015で変更されているため、参照する版を必ず確認してください。\u003C\u002Fp>\u003Ch2 id=\"h1e732751f0\">日本でJIS T 2304への適合が必要になる法的根拠\u003C\u002Fh2>\u003Cp>国内での根拠は、医療機器の基本要件基準（平成17年厚生労働省告示第122号）第12条第2項です。同項は平成29年11月25日から適用され、厚生労働省通知「医療機器の基本要件基準第12条第2項の適用について」（平成29年5月17日 薬生機審発0517第1号）により、JIS T 2304への適合をもって同項への適合を確認したものとされています。\u003C\u002Fp>\u003Cp>\u003Cstrong>確認が求められるタイミングは「製造販売」ではなく「申請」です\u003C\u002Fstrong>。経過措置期間終了日（平成29年11月24日）の翌日以降に承認申請又は認証申請を行う製造販売業者等が対象で、通知には高度管理医療機器・管理医療機器が明示されたうえで、一般医療機器についても同様に確認が必要と記載されています。\u003C\u002Fp>\u003Cp>また、\u003Cstrong>確認の対象はJIS T 2304に限られません\u003C\u002Fstrong>。通知は一貫して「JIS T 2304等」と記載し、プログラムを用いた医療機器のライフサイクルプロセスについて国際的に用いられている適切な規格等がある場合は、それらへの適合性を確認することをもって第12条第2項への適合を確認したものとするとしています。IEC 62304の原文やそのAAMI版で運用している場合、JIS版に置き換える必要はありません。\u003C\u002Fp>\u003Cp>基本要件基準は、薬機法（医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律）第41条第3項に基づき厚生労働大臣が定める医療機器の基準で、第12条は「プログラムを用いた医療機器に対する配慮」を定めています。承認・認証申請では適合性チェックリストに適合状況を記載しますが、「適合しています」と書くだけでは足りず、安全クラスの分類根拠とクラスに応じたプロセスの実施記録を提示できる状態が必要です。なお第12条第3項（サイバーセキュリティ）には別途「医療機器の基本要件基準第12条第3項の適用について」（令和5年3月31日 薬生機審発0331第8号）が発出されており、JIS T 81001-5-1が関係します。\u003C\u002Fp>\u003Ch3 id=\"h9c1c5b5a75\">すでに販売中のソフトウェアはどうするか\u003C\u002Fh3>\u003Cp>箇条3.36は、レガシーソフトウェアを「法規制に適合して市場に出荷され、現在も市販されているが、この規格の現行版に適合して開発されたという客観的な証拠が不十分な医療機器ソフトウェア」と定義しています。該当する場合は箇条4.4により、箇条5〜箇条9をすべて適用する代わりに、4.4.2（リスクマネジメントアクティビティ）、4.4.3（ギャップ分析）、4.4.4（ギャップ解消アクティビティ）、4.4.5（レガシーソフトウェアを使用する根拠）で適合性を実証できます。ギャップ分析は安全クラスに基づき、5.2、5.3、5.7および箇条7の要求事項に対して行います。過去の製品を今から全工程やり直す必要はない、という逃げ道がここにあります。\u003C\u002Fp>\u003Cp>国内でも同様の措置が用意されています。薬生機審発0517第1号は、経過措置期間終了日（平成29年11月24日）までに設計が完了している医療機器について、JIS T 2304等の要求事項と当該医療機器に関して利用可能な情報等との差分を分析し、リスクが受容可能になるようリスクマネジメントの中で対応して必要な記録を残すことを求めています。箇条4.4のギャップ分析と実質的に同じ作業です。\u003C\u002Fp>\u003Ch3 id=\"hcc0b6fba0d\">QMS省令とIEC 62304は相互に参照し合う\u003C\u002Fh3>\u003Cp>見落とされがちですが、IEC 62304の側もQMSを前提にしています。箇条4.1は製造業者が要求事項に適合する能力をもつことの実証を求め、その手段としてJIS Q 13485（ISO 13485）と並んで「医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令」、すなわちQMS省令を挙げています。独立した62304対応プロジェクトを立てるのではなく、既存の設計開発プロセスに組み込むのが本来の姿です。規制とQMS構築の全体像は\u003Ca href=\"\u002Fblogs\u002Fsamd-qms\">SaMD（プログラム医療機器）の規制とQMS対応ガイド\u003C\u002Fa>で整理しています。\u003C\u002Fp>\u003Ch2 id=\"h1c0426cda7\">ソフトウェア安全クラスA・B・Cの判定手順\u003C\u002Fh2>\u003Cp>ソフトウェア安全クラスは、ソフトウェアシステムに起因する危険状態が最悪の場合にもたらす危害のリスクに応じてA・B・Cに分類します（箇条4.3 a）。この判定で実施すべきプロセスの数が大きく変わるため、62304対応の作業量を決める最大の分岐点です。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>クラス\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>定義（箇条4.3 a）\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>A\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェアシステムが危険状態の一因とならない。または、危険状態の一因となるが、そのソフトウェアシステム以外（external to）で実施するリスクコントロール手段を考慮すれば、受容できないリスクは生じない\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>B\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>危険状態の一因となり、そのソフトウェアシステム以外で実施するリスクコントロール手段を考慮しても受容できないリスクが生じる場合で、\u003Cstrong>重傷の可能性はない\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003Cstrong>C\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>同上の場合で、\u003Cstrong>死亡又は重傷の可能性がある\u003C\u002Fstrong>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>BとCの境界は「重傷の可能性があるかどうか」です。ソフトウェアの故障の発生確率が低いことを根拠にクラスを下げることはできません。\u003C\u002Fp>\u003Ch3 id=\"hf98f7d298d\">判定で外してはいけない3つの前提\u003C\u002Fh3>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>前提\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>内容\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェアの故障の発生確率は1として扱う\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>故障確率を定量的に推定する広く認められた方法がないため、常に起きるものとして扱う。「テストで潰しているから発生確率は低い」という主張は通らない。一連の事象のうちソフトウェア以外の事象の確率を推定できない場合は、危害の重大さに焦点を合わせて評価する（附属書B.4.3）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>考慮できるのはexternal toのリスクコントロール手段だけ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェア自身に実装した安全機能を根拠にクラスは下げられない。external toの手段にはハードウェア、独立したソフトウェアシステム、医療処置その他が含まれる（箇条4.3 a 注記1）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>分類が終わるまではクラスCを適用する\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>デフォルトはCであり、下げるには根拠が要るという建て付け（箇条4.3 g）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>前提となる危険状態の特定とリスク評価は、JIS T 14971（ISO 14971）のリスクマネジメントプロセスに従います（箇条4.2）。IEC 62304は単独では完結せず、その成果物を入力として受け取る構造です。手順は\u003Ca href=\"\u002Fblogs\u002Fqms-riskmanagement-guide\">医療機器QMSにおけるリスクマネジメント実践ガイド\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"h9835d1260d\">安全クラスを下げられる2つのルート\u003C\u002Fh3>\u003Cp>安全クラスの引き下げには規格が認めるルートが2つあり、どちらも根拠の文書化が条件です。\u003C\u002Fp>\u003Col>\u003Cli>\u003Cstrong>external toのリスクコントロール手段を追加する\u003C\u002Fstrong> — 当初B又はCに分類したソフトウェアシステムについて、そのソフトウェアシステム以外で実施するリスクコントロール手段（システムアーキテクチャの改善など）を追加で実施し、新しい安全クラスに分類し直すことができます（箇条4.3 a）。\u003C\u002Fli>\u003Cli>\u003Cstrong>ソフトウェアアイテムを分離する\u003C\u002Fstrong> — ソフトウェアシステムをソフトウェアアイテムに分割した場合、各アイテムは元のクラスを\u003Cstrong>継承\u003C\u002Fstrong>します。別のクラスに分類するには正当な根拠を文書で示す必要があり、その根拠には新しいソフトウェアアイテムを\u003Cstrong>どのように分離するのか\u003C\u002Fstrong>の説明が必要です（箇条4.3 d、e）。\u003C\u002Fli>\u003C\u002Fol>\u003Cp>分離は物理的な分離に限られず、あるソフトウェアアイテムが他のアイテムに悪影響を及ぼさないためのあらゆるメカニズムを含みます。ただしクラスCでは、リスクコントロールに必要なアイテム間の分離を特定し、分離が有効であることを確実にする方法を明示することが別途要求されます（箇条5.3.5）。「モジュールを分けたのでこちらはクラスAです」と主張するには、その分離が破れないことの説明まで求められます。なお分類を確定できるのはアーキテクチャが固まった時点以降で、それ以前の分類をプロセスの省略の正当化に使わないことが望ましいとされています（附属書B.4.3）。\u003C\u002Fp>\u003Ch2 id=\"hb37c2a2ffa\">安全クラス別に要求されるプロセス\u003C\u002Fh2>\u003Cp>クラスAで要求されないのは、アーキテクチャの設計（5.3）、詳細設計（5.4）、結合及び結合試験（5.6）と、リスクマネジメントプロセス（箇条7）の大部分です。逆に開発計画・要求事項分析・システム試験・リリース・保守・構成管理・問題解決は、クラスAであっても実施しなければなりません。規格では各要求事項の末尾に適用クラスが記載されています。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>プロセス／アクティビティ\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>クラスA\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>クラスB\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>クラスC\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.1 開発計画\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.1.4、5.1.5、5.1.10〜5.1.12を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.1.4を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.2 要求事項分析\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.2.3を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.3 アーキテクチャの設計\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>−\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.3.5を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.4 詳細設計\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>−\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.4.1のみ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.5 ユニットの実装\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.5.1のみ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.5.4を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.6 結合及び結合試験\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>−\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.7 システム試験\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.8 リリース\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○（5.8.3、5.8.5、5.8.6を除く）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>6 保守プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7 リスクマネジメントプロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.4.1のみ\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>8 構成管理プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>9 問題解決プロセス\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>○\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>（JIS T 2304:2017 の各細分箇条に付記された適用クラスをもとに作成）\u003C\u002Fp>\u003Cp>クラスBとCの差は詳細設計まわりに集中しています。クラスBで要求されるのは5.4.1（ソフトウェアユニットへの分解）までで、5.4.2〜5.4.4（詳細設計の開発と検証）はクラスC限定です。ほかにクラスC固有の要求として5.1.4（開発規格・方法・ツールの計画）、5.3.5（分離の特定）、5.5.4（追加のユニット合否判定基準）があります。\u003C\u002Fp>\u003Cp>一方、\u003Cstrong>箇条7（リスクマネジメント）にクラスC限定の要求事項はありません。\u003C\u002Fstrong>クラスAで要求されるのは7.4.1（医療機器ソフトウェアの安全性に関わる変更の分析）だけで、クラスB・Cでは箇条7の全項目が要求されます。リスクコントロール手段の選択と文書化（7.2.1）もクラスBで要求されるため、クラスBだからと省略することはできません。\u003C\u002Fp>\u003Ch2 id=\"hae59e26e53\">ソフトウェアライフサイクルプロセスの実務\u003C\u002Fh2>\u003Cp>IEC 62304は、開発プロセス（箇条5）、保守プロセス（箇条6）、3つの支援プロセス（箇条7 リスクマネジメント、箇条8 構成管理、箇条9 問題解決）で構成されます。開発プロセスだけを整備して支援プロセスを落とすのが典型的な失敗パターンです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>アクティビティ\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>残す成果物\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.1 開発計画\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>プロセス・成果物・トレーサビリティ・構成管理・問題解決の扱いを定めた計画書（5.1.1）。反復的な開発も可\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.2 要求事項分析\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ソフトウェア要求事項仕様と、その検証記録。リスクコントロール手段の包含（5.2.3）はクラスB・C\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.3 アーキテクチャの設計\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>アイテムとインタフェースの設計書、SOUP要求事項（5.3.3、5.3.4）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.4 詳細設計\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ユニットへの分解（5.4.1、クラスB・C）。ユニット及びインタフェースの詳細設計とその検証（5.4.2〜5.4.4）はクラスC\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.5 ユニットの実装\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>実装と、ユニット検証の手順・結果（5.5.2、5.5.5）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.6 結合及び結合試験\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>結合計画（5.1.5）に沿った試験記録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.7 システム試験\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>要求事項ごとのインプット・予想結果・合否判定基準・手順と結果\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.8 リリース\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>検証完了確認、既知の残留異常の一覧と評価、バージョン・作成手順・作成環境の記録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>5.8.2（既知の残留異常の文書化）はクラスAでも要求されます。\u003C\u002Fstrong>「既知の不具合を残したままリリースしてよいか」ではなく、「残したものを文書化し、受容できないリスクにならないことを確認したか」（5.8.3、クラスB・C）が問われます。\u003C\u002Fp>\u003Ch3 id=\"h0a47b90b70\">保守プロセスと支援プロセスはクラスAでも省略できない\u003C\u002Fh3>\u003Cp>保守プロセス（箇条6）は保守計画の確立（6.1）、フィードバックの監視・文書化・評価（6.2.1）、変更要求の評価・承認（6.2.4）、5.8に従った再リリース（6.3.2）で構成され、すべてクラス共通の要求です。支援プロセスのうち、構成管理（箇条8）と問題解決（箇条9）も全項目がクラスAで要求されます。箇条7で例外的にクラスAに適用されるのは7.4.1（安全性に関わる変更の分析）だけです。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>支援プロセス\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>主な要求\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>クラスAへの適用\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>箇条7 リスクマネジメント\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>危険状態の一因となるアイテムと潜在的原因の特定（7.1.1、7.1.2）、リスクコントロール手段の選択・実施・検証（7.2、7.3.1）、トレーサビリティの文書化（7.3.3）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.4.1（安全性に関わる変更の分析）のみ\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>箇条8 構成管理\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>構成アイテム識別手段の確立（8.1.1）、SOUPの特定（8.1.2）、システム構成の文書化（8.1.3）、承認済み変更要求に限る変更（8.2.1）、変更のトレーサビリティ維持（8.2.4）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>全項目\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>箇条9 問題解決\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>問題報告の作成（9.1）、調査（9.2）、関係者への通知（9.3）、変更管理プロセスの使用（9.4）、記録の保持（9.5）、傾向分析（9.6）、解決の検証（9.7）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>全項目\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2 id=\"h150d632c6a\">SOUP（開発過程が不明なソフトウェア）の管理\u003C\u002Fh2>\u003Cp>SOUPは「既に開発されていて一般に利用できるが、医療機器に組み込むことを目的に開発したものではないソフトウェアアイテム、又は以前開発されたソフトウェアアイテムでその開発プロセスについての十分な記録が利用できないもの」と定義されています（箇条3.29）。OSS、商用ライブラリ、OS、既製品（OTS）が該当し、自社の過去資産でも開発記録が不十分なものはSOUPです。なお\u003Cstrong>医療機器ソフトウェアシステム全体をSOUPであると主張することはできません\u003C\u002Fstrong>（箇条3.29 注記）。\u003C\u002Fp>\u003Ch3 id=\"had490ef8b9\">SOUP管理でやることチェックリスト\u003C\u002Fh3>\u003Cul>\u003Cli>[ ] SOUPアイテムを洗い出し、名称・製造業者・SOUPを特定する識別子を文書化する（8.1.2、\u003Cstrong>クラスA・B・C\u003C\u002Fstrong>）\u003C\u002Fli>\u003Cli>[ ] 識別子にバージョン、リリース年月日、パッチ番号、アップグレードの識別子を含める（8.1.2 注記）\u003C\u002Fli>\u003Cli>[ ] 標準ライブラリもSOUP構成アイテムに含める（8.1.2）\u003C\u002Fli>\u003Cli>[ ] 各SOUPアイテムの、意図する使用に必要な機能・性能要求事項を明確にする（5.3.3、クラスB・C）\u003C\u002Fli>\u003Cli>[ ] 各SOUPアイテムの正常な動作に必要なシステムハードウェア・ソフトウェアを明確にする（5.3.4、クラスB・C）\u003C\u002Fli>\u003Cli>[ ] 医療機器アーキテクチャが全SOUPアイテムの正常な動作を支援していることを検証する（5.3.6、クラスB・C）\u003C\u002Fli>\u003Cli>[ ] SOUPを含む結合・結合試験の計画を開発計画書に示すか引用する（5.1.5、クラスB・C）\u003C\u002Fli>\u003Cli>[ ] SOUPに起因する故障・予期せぬ結果を危険状態の潜在的原因として検討する（7.1.2、クラスB・C）\u003C\u002Fli>\u003Cli>[ ] SOUPアイテムの供給者が公開している異常リストを評価する（7.1.3、クラスB・C）\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"h0ae7c5a3ed\">既知の異常リストの評価が最大の関門\u003C\u002Fh3>\u003Cp>実務で最も詰まるのが7.1.3（公開されたSOUP異常リストの評価）です。SOUPに起因する故障又は予期せぬ結果が危険状態の一因となるソフトウェアアイテムの潜在的原因になっている場合、当該医療機器に使用しているSOUPアイテムの\u003Cstrong>バージョンに関係する\u003C\u002Fstrong>、供給者が公開している異常リストを最低限度として評価し、既知の異常によって危険状態の原因となる一連の事象が生じるかを判断しなければなりません。\u003C\u002Fp>\u003Cp>つまり「このライブラリのこのバージョンについて、公開されている既知の不具合をすべて確認し、自社機器で危害につながるかを一件ずつ判断した記録」が必要です。依存パッケージが数百に及ぶ開発では、バージョンを固定して依存関係と評価結果を継続的に管理する仕組みがなければ運用が破綻します。SBOM（ソフトウェア部品表）の整備は、この要求への実務的な回答です。\u003C\u002Fp>\u003Ch2 id=\"h9fe7d6d610\">QMS省令・ISO 13485の設計開発への組み込み方\u003C\u002Fh2>\u003Cp>IEC 62304のライフサイクルは、QMS省令第5節「製品実現」の設計開発プロセス（第30条〜第36条の2）に載せるのが正しい実装です。62304用の手順書を独立して作るのではなく、既存の設計開発手順にソフトウェア固有のアクティビティを組み込みます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>QMS省令\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>ISO 13485:2016\u003C\u002Fp>\u003C\u002Fth>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>対応するIEC 62304のプロセス\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第30条（設計開発）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.1、7.3.2\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.1 ソフトウェア開発計画\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第31条（設計開発への工程入力情報）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.3\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.2 ソフトウェア要求事項分析\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第32条（設計開発からの工程出力情報）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.4\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.3 アーキテクチャの設計、5.4 詳細設計\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第33条（設計開発照査）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.5\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>各アクティビティの評価タスク\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第34条（設計開発の検証）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.6\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.5.5、5.6、5.7 の検証・試験\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第35条（設計開発バリデーション）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.7\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>（62304の対象外。製品規格側で対応）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第35条の2（設計移管業務）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.8\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>5.8 ソフトウェアリリース\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条（設計開発の変更の管理）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.9\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>箇条6 保守、箇条8 構成管理\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>第36条の2（設計開発に係る記録簿）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>7.3.10\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>全プロセスの成果物\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>（ISO 13485:2016の箇条番号は、施行通知（令和3年3月26日 薬生監麻発0326第4号。令和7年1月31日一部改正）の各条の解説に示された対応関係による）\u003C\u002Fp>\u003Ch3 id=\"he875ce453c\">リスクマネジメントと使用性は省令側でも要求されている\u003C\u002Fh3>\u003Cp>QMS省令第31条第1項第1号は工程入力情報として「意図した用途に応じた機能、性能、\u003Cstrong>使用性\u003C\u002Fstrong>及び安全性に係る製品要求事項」を、第3号は「第26条第3項に規定するリスクマネジメントに係る工程出力情報たる要求事項」を挙げています。リスクマネジメントの成果物を設計開発の入力にすることは、規格の要請である以前に日本の省令の要求です。第1号の「使用性」は、施行通知38．第31条関係（3）が「IEC 62366-1のUsabilityに相当するもの」と明記しています（\u003Ca href=\"\u002Fblogs\u002Fusability\">医療機器のユーザビリティとは？\u003C\u002Fa>）。\u003C\u002Fp>\u003Cp>トレーサビリティも同様で、第30条第4項第5号が設計開発計画において「工程入力情報から工程出力情報への追跡可能性を確保する方法」の文書化を求めています。IEC 62304側では、5.1.1 c)がシステム要求事項・ソフトウェア要求事項・ソフトウェアシステム試験・ソフトウェアに実装するリスクコントロール手段の間のトレーサビリティを開発計画に含めるよう求め、7.3.3が危険状態からソフトウェアアイテム、ソフトウェアの原因、リスクコントロール手段、その検証までのトレーサビリティの文書化を求めています。両者は同じトレーサビリティマトリクスで満たせます。設計開発プロセス全体の要求事項は\u003Ca href=\"\u002Fblogs\u002Fqms-design-development\">QMSの設計開発とは？\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"h7f44931272\">設計開発に係る記録簿に何を綴じるか\u003C\u002Fh3>\u003Cp>QMS省令第36条の2は、製品又は類似製品グループごとに、設計開発に係る要求事項への適合を証明する記録、変更の記録、参照した資料に係る記録簿の作成と保管を求めています。施行通知45．第36条の2関係（3）は、この記録簿に含まれうるものとして「ソフトウェアの検証及びバリデーション結果」を明示しています。\u003C\u002Fp>\u003Cp>IEC 62304の成果物、すなわち開発計画書、要求事項仕様、アーキテクチャ設計、トレーサビリティマトリクス、SOUP一覧、各試験の記録、既知の残留異常の一覧、問題報告と解決の記録は、そのまま記録簿の中身になります。これらがリポジトリや課題管理ツールに散在していると、適合性調査で「記録簿として提示してください」と言われた時点で行き詰まります。\u003C\u002Fp>\u003Cp>開発チームの成果物を開発ツールに置いたままにせず、QMSの文書・記録管理の版管理下に置くことが必要です。どの版が承認済みで、いつ誰が改訂し、どの製品バージョンに対応するのかを、開発部門と品質保証部門が同じ台帳で追える状態にしておくと、設計変更のたびに記録簿を作り直す手間がなくなります。\u003C\u002Fp>\u003Ch2 id=\"h08562665f0\">よくある質問\u003C\u002Fh2>\u003Ch3 id=\"had22a28e5a\">ソフトウェア安全クラスは誰がどうやって決めるのですか？\u003C\u002Fh3>\u003Cp>製造業者が、JIS T 14971に基づくリスク分析の結果をもとに分類します（箇条4.3 a）。判定はソフトウェアの故障の発生確率を1とし、そのソフトウェアシステム以外（external to）で実施するリスクコントロール手段だけを考慮して行います。分類した安全クラスはリスクマネジメントファイルへの文書化が必要で（箇条4.3 c）、分類が終わるまではクラスCの要求事項が適用されます（箇条4.3 g）。\u003C\u002Fp>\u003Ch3 id=\"hb23ccbd002\">クラスAならほとんど何もしなくてよいのですか？\u003C\u002Fh3>\u003Cp>いいえ。クラスAでも、開発計画（5.1）、要求事項分析（5.2）、ユニットの実装（5.5.1）、システム試験（5.7）、リリース（5.8）、保守（箇条6）、構成管理（箇条8）、問題解決（箇条9）は要求されます。省略できるのはアーキテクチャの設計（5.3）、詳細設計（5.4）、結合及び結合試験（5.6）と箇条7の大部分です。SOUPの特定（8.1.2）もクラスAで要求されます。\u003C\u002Fp>\u003Ch3 id=\"h15b79cc2b3\">OSSを使うと承認は通らなくなりますか？\u003C\u002Fh3>\u003Cp>なりません。OSSはSOUPとして扱い、規格が求める管理を実施すれば問題ありません。名称・製造業者・識別子の文書化（8.1.2）、意図する使用に必要な機能・性能要求事項の明確化（5.3.3）、必要なシステムハードウェア・ソフトウェアの明確化（5.3.4）、公開されている異常リストの評価（7.1.3）などです。管理されていないOSSが混入している状態が問題になります。\u003C\u002Fp>\u003Ch3 id=\"h0c2078c327\">QMSで使う業務システムのバリデーションとIEC 62304は何が違うのですか？\u003C\u002Fh3>\u003Cp>対象物が違います。IEC 62304は医療機器そのもの、または医療機器に組み込まれたソフトウェアの開発ライフサイクルを規定する規格です。一方、文書管理システムや製造設備の制御ソフトのようにQMSの運用に使用するソフトウェアには、QMS省令第5条の6（ソフトウェアの使用）、第45条（製造工程等のバリデーション）、第53条（設備及び器具の管理）が導入時・変更時のバリデーションを求めています。詳しくは\u003Ca href=\"\u002Fblogs\u002Fsoftware-validation\">QMSのソフトウェアバリデーションとは？\u003C\u002Fa>を参照してください。\u003C\u002Fp>\u003Ch3 id=\"hf795d74a64\">IEC 62304は改訂される予定がありますか？\u003C\u002Fh3>\u003Cp>2026年8月時点で発行されていません。「2026年8月発行予定」とする情報が流通していますが、実際の進捗はそれより後ろです。2025年の委員会原案（CD1）に約1,500件のコメントが寄せられ、IEC SC62A\u002FMT49は第2版ではなく第2次委員会原案（CD2）を出す段階にあります。FDISは2028年、発行は2029年になる可能性があり、IECが示す発行予測も2028年10月です。\u003C\u002Fp>\u003Cp>議論されている主な変更は、安全クラスA・B・Cを2段階のプロセス厳格度レベル（I・II）に置き換えること、適用範囲をヘルスソフトウェア全般へ拡大すること、AI\u002FMLライフサイクルの要求追加、レガシーソフトウェアの参考附属書化です。旧クラスAがレベルI、旧クラスB・CがレベルIIに相当するとされており、影響が最も大きいのは現在クラスBの製品です。\u003C\u002Fp>\u003Cp>内容は発行まで確定せず、JIS T 2304の改正時期も未定です。当面はJIS T 2304:2017への適合を前提に整備してください。ただしクラスBの製品は、将来レベルII（現行クラスC相当）へ引き上げられる前提で詳細設計とその検証の記録を残しておくと、移行時のギャップが小さくなります。\u003C\u002Fp>\u003Ch2 id=\"ha214098e44\">まとめ\u003C\u002Fh2>\u003Cp>IEC 62304対応は、安全クラスの判定に始まり、クラスに応じたプロセスを実行し、その成果物を設計開発に係る記録簿（QMS省令第36条の2）として維持するところまでが一続きです。クラスの分類根拠、SOUP一覧、トレーサビリティマトリクスの3点が揃っていない状態は、審査や適合性調査で必ず指摘されます。\u003C\u002Fp>\u003Cp>とくにSOUP一覧とトレーサビリティマトリクスは、製品のバージョンが変わるたびに版が動き、承認者と改訂履歴を伴う文書です。設計開発ファイルを電子的に管理する場合、QMS省令第8条第2項が求める文書の版管理・改訂状況の識別と、第9条第2項が求める記録の完全性の確保を同時に満たす必要があります。医療機器QMSに特化した電子QMSであるQMSmartのように、これらを標準機能として備えた基盤の上に設計開発ファイルを載せておくと、開発部門と品質保証部門が同じ版を参照したまま設計変更を回せます。\u003C\u002Fp>\u003Cp>まずは自社ソフトウェアが適用対象かを切り分け、JIS T 14971に基づくリスク分析から安全クラスを分類するところに着手してください。\u003C\u002Fp>",{"url":129,"height":12,"width":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F4c98668f45f94934a9b74391fce6dc9c\u002FIEC%2062304.webp","IEC 62304（JIS T 2304）とは何かを実務目線で解説。ソフトウェア安全クラスA・B・Cの判定と格下げの条件、SOUP管理の要求事項、QMS省令第30条〜第36条の2の設計開発への組み込み方を条番号付きで整理します。",{"id":16,"createdAt":17,"updatedAt":18,"publishedAt":17,"revisedAt":18,"name":19,"image":132,"profile":24,"subtitle":25,"profile_url":26,"profile_sameas_url":27},{"url":21,"height":22,"width":23},[134,135,136,137],{"id":58,"createdAt":59,"updatedAt":59,"publishedAt":59,"revisedAt":59,"name":60},{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":63,"createdAt":64,"updatedAt":64,"publishedAt":64,"revisedAt":64,"name":65},{"id":89,"createdAt":90,"updatedAt":90,"publishedAt":90,"revisedAt":90,"name":91},{"id":139,"createdAt":140,"updatedAt":141,"publishedAt":142,"revisedAt":141,"title":143,"content":144,"eyecatch":145,"description":147,"reviewer":148,"category":161},"eqms-introduction","2025-04-08T06:25:54.426Z","2025-04-08T06:46:32.598Z","2025-04-08T06:40:00.607Z","電子QMS導入のメリットと課題：ソフトウェアバリデーション徹底解説","\u003Ch2 id=\"h1cc5131e91\">\u003Cstrong>医療機器業界における電子QMS（eQMS）の現状と重要性\u003C\u002Fstrong>\u003C\u002Fh2>\u003Cp>医療機器業界において、QMS（品質マネジメントシステム）の電子化は単なるトレンドではなく、業務効率化とコンプライアンス強化の両立を可能にする重要な戦略となっています。特に新型コロナウイルス感染症の世界的流行以降、テレワークの普及とともに\u003Cstrong>電子QMS（eQMS）\u003C\u002Fstrong>の導入が加速しています。\u003C\u002Fp>\u003Cp>電子QMSとは、従来の紙ベースの品質管理システムを電子的なプラットフォームに移行したもので、文書管理、変更管理、逸脱管理、CAPA（是正・予防処置）、教育訓練管理などのQMSプロセスを統合的に管理するシステムです。しかし、その導入と運用には医療機器特有の規制要件への対応が求められ、特にシステムのバリデーションが重要な課題となります。\u003C\u002Fp>\u003Cp>本記事では、医療機器メーカーが電子QMSを導入する際のメリットと課題を整理し、特にQMS省令及びISO 13485で求められるソフトウェアバリデーションの実施方法について詳細に解説します。品質管理担当者や、QMS審査員、これから電子QMSの導入を検討している方々にとって実践的なガイドとなることを目指します。 \u003C\u002Fp>\u003Ch2 id=\"h75f38cea37\">\u003Cstrong>電子QMSに関する法的要件と規制背景\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h11b12c1a97\">\u003Cstrong>QMS省令における電子的記録・システムの要求事項\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>医療機器等の製造販売業者等が遵守すべきQMS省令（医療機器及び体外診断用医薬品の製造管理及び品質管理の基準に関する省令：平成16年厚生労働省令第169号）では、2021年の改正で電子的記録の取扱いがより明確化されました。特に第5条の6（ソフトウェアの使用）において、以下のように規定されています：\u003C\u002Fp>\u003Cblockquote>\u003Cp>製造販売業者等（限定第三種医療機器製造販売業者を除く。以下この条において同じ。）は、品質管理監督システムにソフトウェアを使用する場合においては、当該ソフトウェアの適用に係るバリデーションについて手順を文書化しなければならない。\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>さらに、第4項では「製造販売業者等は、第2項のバリデーションから得られた記録を作成し、これを保管しなければならない」とされ、バリデーション記録の作成・保管も要求されています。\u003C\u002Fp>\u003Ch3 id=\"h8bea553de9\">\u003Cstrong>ISO 13485:2016における要求事項\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>ISO 13485:2016の4.1.6項では、品質管理システムにソフトウェアを使用する場合の要求事項について、次のように規定しています：\u003C\u002Fp>\u003Cul>\u003Cli>ソフトウェアの適用のバリデーションに関する手順の文書化\u003C\u002Fli>\u003Cli>初回使用前及びソフトウェアや適用の変更後のバリデーション実施\u003C\u002Fli>\u003Cli>ソフトウェア使用に伴うリスクに応じたバリデーションアプローチ\u003C\u002Fli>\u003Cli>バリデーション活動の記録維持\u003C\u002Fli>\u003C\u002Ful>\u003Cp>また、7.6項では監視・測定のためのソフトウェアに対する追加要求事項も規定されています。\u003C\u002Fp>\u003Ch3 id=\"h87887aac9a\">\u003Cstrong>FDA 21 CFR Part 11との整合性\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>米国市場に展開する医療機器メーカーは、FDA（米国食品医薬品局）の21 CFR Part 11（電子記録・電子署名に関する規則）への対応も必要です。Part 11では、電子記録の信頼性、完全性、機密性を確保するための技術的・手続き的管理について詳細に規定しており、具体的には以下の要素を含みます：\u003C\u002Fp>\u003Cul>\u003Cli>システムバリデーション\u003C\u002Fli>\u003Cli>電子記録の保存と取得\u003C\u002Fli>\u003Cli>セキュリティとアクセス制御\u003C\u002Fli>\u003Cli>監査証跡（Audit Trail）\u003C\u002Fli>\u003Cli>電子署名の管理\u003C\u002Fli>\u003C\u002Ful>\u003Cp>日本のQMS省令と比較すると、FDA Part 11はより具体的かつ厳格な要求がありますが、グローバル展開を目指す企業にとっては、より厳しい要件に合わせて対応することが効率的です。 \u003C\u002Fp>\u003Ch2 id=\"ha37835d128\">\u003Cstrong>電子QMS導入のメリット\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h1d18f7f141\">\u003Cstrong>業務効率化とコスト削減\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSの導入により、以下のような業務効率化が期待できます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>文書管理の自動化\u003C\u002Fstrong>: 承認フローの電子化により承認プロセスと時間が大幅に短縮\u003C\u002Fli>\u003Cli>\u003Cstrong>検索性の向上\u003C\u002Fstrong>: 必要な文書やデータを瞬時に検索可能\u003C\u002Fli>\u003Cli>\u003Cstrong>テンプレートの活用\u003C\u002Fstrong>: 標準化されたテンプレートによる文書作成効率の向上\u003C\u002Fli>\u003Cli>\u003Cstrong>リモートアクセス\u003C\u002Fstrong>: 場所を問わず必要な文書へのアクセスが可能\u003C\u002Fli>\u003Cli>\u003Cstrong>紙資源・保管スペースの削減\u003C\u002Fstrong>: 紙文書の印刷・保管コストの削減\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ある中堅医療機器メーカーでは、電子QMS導入後、文書承認のリードタイムが平均12日から2日に短縮され、年間約500万円の紙・印刷コスト削減を実現しました。 \u003C\u002Fp>\u003Ch3 id=\"h86b5473a26\">\u003Cstrong>データインテグリティと信頼性の向上\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSでは、ALCOA+原則（Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available）に基づくデータインテグリティの確保が容易になります：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>監査証跡の自動記録\u003C\u002Fstrong>: 「誰が」「いつ」「何を」変更したかを自動的に記録\u003C\u002Fli>\u003Cli>\u003Cstrong>アクセス制御の徹底\u003C\u002Fstrong>: 権限に基づくアクセス管理による不正変更防止\u003C\u002Fli>\u003Cli>\u003Cstrong>バージョン管理の自動化\u003C\u002Fstrong>: 文書・記録の版管理が容易\u003C\u002Fli>\u003Cli>\u003Cstrong>データバックアップの自動化\u003C\u002Fstrong>: データ喪失リスクの低減\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"h3c15abf5fa\">\u003Cstrong>コンプライアンス対応の強化\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSは規制対応においても優位性があります：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>リアルタイムモニタリング\u003C\u002Fstrong>: 期限管理や進捗状況の可視化\u003C\u002Fli>\u003Cli>\u003Cstrong>自動レポート生成\u003C\u002Fstrong>: 規制当局提出用の報告書自動作成\u003C\u002Fli>\u003Cli>\u003Cstrong>統計的分析の容易さ\u003C\u002Fstrong>: 品質データの傾向分析が容易\u003C\u002Fli>\u003Cli>\u003Cstrong>グローバル規制対応\u003C\u002Fstrong>: 各国規制に対応した機能のカスタマイズ\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"ha757436962\">\u003Cstrong>リモートワーク・テレワーク環境への適応\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>COVID-19パンデミック以降、リモートワーク環境下での品質管理の継続性確保が重要課題となりました。電子QMSは、場所を問わず必要な文書へのアクセスと承認プロセスの実行を可能にし、業務継続性（BCP: Business Continuity Plan）の観点からも有効です。 \u003C\u002Fp>\u003Ch2 id=\"h7362a9f175\">\u003Cstrong>電子QMS導入における課題\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h92e3e93c87\">\u003Cstrong>初期投資と維持コスト\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSの導入には、以下のようなコスト要素があります：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>システム購入\u002Fライセンス費用\u003C\u002Fstrong>: クラウドサービスの場合は月額\u002F年額利用料\u003C\u002Fli>\u003Cli>\u003Cstrong>カスタマイズ\u002F構築費用\u003C\u002Fstrong>: 自社プロセスに合わせたシステム調整\u003C\u002Fli>\u003Cli>\u003Cstrong>バリデーション費用\u003C\u002Fstrong>: システムバリデーションの実施コスト\u003C\u002Fli>\u003Cli>\u003Cstrong>教育訓練費用\u003C\u002Fstrong>: ユーザートレーニングのコスト\u003C\u002Fli>\u003Cli>\u003Cstrong>インフラ整備費用\u003C\u002Fstrong>: ハードウェア、ネットワーク環境の整備\u003C\u002Fli>\u003Cli>\u003Cstrong>保守・運用費用\u003C\u002Fstrong>: システム管理者の人件費、定期的な更新費用\u003C\u002Fli>\u003C\u002Ful>\u003Cp>特に中小規模のメーカーにとって、これらの初期投資は大きな負担となることがあります。ROI（投資対効果）分析を行い、長期的なコスト削減効果と比較検討することが重要です。\u003C\u002Fp>\u003Ch3 id=\"h3c3ca961b4\">\u003Cstrong>変更管理とユーザー受容性\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSへの移行は、単なるシステム導入ではなく組織変革の一環として捉える必要があります：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>抵抗感の克服\u003C\u002Fstrong>: 紙ベースの従来プロセスに慣れた社員の抵抗\u003C\u002Fli>\u003Cli>\u003Cstrong>業務プロセスの再設計\u003C\u002Fstrong>: 既存プロセスの見直しと最適化\u003C\u002Fli>\u003Cli>\u003Cstrong>教育訓練の徹底\u003C\u002Fstrong>: 新システムの操作方法の習得\u003C\u002Fli>\u003Cli>\u003Cstrong>段階的な導入\u003C\u002Fstrong>: 一度にすべてを変更するのではなく段階的に移行\u003C\u002Fli>\u003C\u002Ful>\u003Cp>成功事例では、現場のキーユーザーを早期に巻き込み、導入チームに参加させることで受容性を高めています。\u003C\u002Fp>\u003Ch3 id=\"h0277e030dc\">\u003Cstrong>システム障害と事業継続性\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子システムへの依存度が高まるほど、システム障害時のリスクも増大します：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>システムダウン時の対応\u003C\u002Fstrong>: 代替手順の準備\u003C\u002Fli>\u003Cli>\u003Cstrong>データバックアップ戦略\u003C\u002Fstrong>: 定期的かつ安全なバックアップ体制\u003C\u002Fli>\u003Cli>\u003Cstrong>災害復旧計画\u003C\u002Fstrong>: 災害時のシステム復旧手順\u003C\u002Fli>\u003Cli>\u003Cstrong>セキュリティ対策\u003C\u002Fstrong>: サイバー攻撃対策、不正アクセス防止\u003C\u002Fli>\u003C\u002Ful>\u003Cp>これらのリスクに対応するため、BCP（Business Continuity Plan：事業継続計画）の一環として電子システム障害時の対応手順を文書化し、定期的な訓練を実施することが推奨されます。\u003C\u002Fp>\u003Ch2 id=\"h4d4927864e\">\u003Cstrong>ソフトウェアバリデーションの基本要件\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h4b439ec2d1\">\u003Cstrong>ソフトウェアバリデーションの目的と法的要求\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>ソフトウェアバリデーションとは、「ソフトウェアが意図した用途に適合していることを客観的証拠によって確認し、文書化するプロセス」です。QMS省令第5条の6やISO 13485:2016の4.1.6項で要求されており、その目的は：\u003C\u002Fp>\u003Cul>\u003Cli>システムが\u003Cstrong>意図した通りに機能する\u003C\u002Fstrong>ことを確認する\u003C\u002Fli>\u003Cli>システムが\u003Cstrong>品質記録の完全性と正確性\u003C\u002Fstrong>を維持することを検証する\u003C\u002Fli>\u003Cli>品質管理システムの\u003Cstrong>信頼性を確保\u003C\u002Fstrong>する\u003C\u002Fli>\u003C\u002Ful>\u003Cp>医療機器業界では、システムの複雑性やリスクに応じた\u003Cstrong>リスクアプローチ\u003C\u002Fstrong>が推奨されています。\u003C\u002Fp>\u003Ch3 id=\"hc691786c9a\">\u003Cstrong>GAMP 5アプローチとソフトウェアカテゴリ分類\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>ISPE（International Society for Pharmaceutical Engineering）が発行するGAMP 5（Good Automated Manufacturing Practice）ガイドは、コンピュータ化システムのバリデーションに関する業界標準のガイダンスを提供しています。GAMP 5では、ソフトウェアを以下のようにカテゴリ分類しています：\u003C\u002Fp>\u003Col>\u003Cli>\u003Cstrong>カテゴリ1\u003C\u002Fstrong>: インフラストラクチャソフトウェア（OS, ネットワークなど）\u003C\u002Fli>\u003Cli>\u003Cstrong>カテゴリ3\u003C\u002Fstrong>: 非構成化市販パッケージソフトウェア（設定変更が限定的）\u003C\u002Fli>\u003Cli>\u003Cstrong>カテゴリ4\u003C\u002Fstrong>: 構成化市販パッケージソフトウェア（広範囲な設定が可能、多くの電子QMSがこれに該当）\u003C\u002Fli>\u003Cli>\u003Cstrong>カテゴリ5\u003C\u002Fstrong>: カスタム開発ソフトウェア\u003C\u002Fli>\u003C\u002Fol>\u003Cp>カテゴリが上がるほどバリデーションの範囲と深さは増加します。多くの電子QMSはカテゴリ4に該当し、設定可能な範囲内でのバリデーションが必要です。\u003C\u002Fp>\u003Ch3 id=\"h069d4c15de\">\u003Cstrong>バリデーション実施体制と責任分担\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>効果的なバリデーションには、適切な体制と責任分担が不可欠です：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>バリデーションオーナー\u003C\u002Fstrong>: 全体責任者（通常は品質保証部門の管理職）\u003C\u002Fli>\u003Cli>\u003Cstrong>バリデーションチーム\u003C\u002Fstrong>: QA、IT、各部門の代表者\u003C\u002Fli>\u003Cli>\u003Cstrong>SME（Subject Matter Expert）\u003C\u002Fstrong>: 業務プロセスの専門家\u003C\u002Fli>\u003Cli>\u003Cstrong>ベンダー\u003C\u002Fstrong>: システム提供会社の技術担当者\u003C\u002Fli>\u003C\u002Ful>\u003Cp>責任範囲を明確にするためのRACI表（Responsible, Accountable, Consulted, Informed）の作成が推奨されます。\u003C\u002Fp>\u003Ch2 id=\"h24c08b27b8\">\u003Cstrong>電子QMSソフトウェアバリデーションの実施手順\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h4f45be08e7\">\u003Cstrong>バリデーション計画の策定\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>バリデーションは計画的に実施する必要があり、その第一歩はバリデーション計画書（VP: Validation Plan）の作成です。計画書には以下の内容を含めます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>バリデーションの目的と適用範囲\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>責任者と実施体制\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>スケジュールとマイルストーン\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>リスク評価の方法と結果\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>バリデーション戦略（IQ\u002FOQ\u002FPQアプローチ等）\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>合否判定基準\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>文書体系と記録要件\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>変更管理とリバリデーション方針\u003C\u002Fstrong>\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"hc64dd3d32f\">\u003Cstrong>要求仕様の作成\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>効果的なバリデーションの鍵は、明確な要求仕様の定義です：\u003C\u002Fp>\u003Ch4 id=\"h3935fcdf60\">\u003Cstrong>ユーザー要求仕様書（URS）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>ユーザー要求仕様書（URS: User Requirement Specification）には、システムに求める機能や性能を\u003Cstrong>検証可能な形\u003C\u002Fstrong>で記述します：\u003C\u002Fp>\u003Cul>\u003Cli>各要求事項は一意に識別可能であること\u003C\u002Fli>\u003Cli>明確かつ具体的であること（「使いやすい」ではなく「3クリック以内で目的の操作ができる」など）\u003C\u002Fli>\u003Cli>測定可能であること\u003C\u002Fli>\u003Cli>規制要件への対応を含むこと（例：監査証跡、アクセス制御など）\u003C\u002Fli>\u003C\u002Ful>\u003Ch4 id=\"h1324172997\">\u003Cstrong>機能仕様書（FS）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>各ユーザー要求仕様を実現するためのより具体的な機能仕様を定義します。これは通常、ベンダーと協力して作成します。\u003C\u002Fp>\u003Ch4 id=\"hec0bf48eeb\">\u003Cstrong>設計仕様書（DS）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>カスタマイズを行う場合は、システムの詳細設計を文書化します。パッケージソフトウェアの場合は、設定内容を中心に記述します。\u003C\u002Fp>\u003Ch3 id=\"h2c59fbd3d6\">\u003Cstrong>リスク評価\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>バリデーションの範囲と深さを決定するため、リスク評価を行います：\u003C\u002Fp>\u003Cul>\u003Cli>患者安全性への影響\u003C\u002Fli>\u003Cli>製品品質への影響\u003C\u002Fli>\u003Cli>データインテグリティへの影響\u003C\u002Fli>\u003Cli>規制コンプライアンスへの影響\u003C\u002Fli>\u003Cli>業務プロセスへの影響\u003C\u002Fli>\u003Cli>使用性への影響\u003C\u002Fli>\u003C\u002Ful>\u003Cp>リスク評価の結果に基づき、重要機能に対してはより徹底したテストを行います。\u003C\u002Fp>\u003Ch3 id=\"h53b4adf06b\">\u003Cstrong>IQ\u002FOQ\u002FPQアプローチ\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>バリデーションは一般的に以下の3段階で実施します：\u003C\u002Fp>\u003Ch4 id=\"hbaf441b3bd\">\u003Cstrong>インストール適格性確認（IQ）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>システムが適切にインストールされ、動作環境が整っていることを確認します：\u003C\u002Fp>\u003Cul>\u003Cli>ソフトウェア仕様と版の確認\u003C\u002Fli>\u003Cli>ハードウェア\u002Fソフトウェアが適切にインストールされているか確認\u003C\u002Fli>\u003Cli>システム環境要件の確認\u003C\u002Fli>\u003Cli>必要なドキュメントの存在確認\u003C\u002Fli>\u003Cli>セキュリティ設定の確認\u003C\u002Fli>\u003C\u002Ful>\u003Ch4 id=\"h4c4340ca61\">\u003Cstrong>運転適格性確認（OQ）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>個々の機能が仕様通りに動作することを確認します：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>機能テスト\u003C\u002Fstrong>: 各機能が仕様通りに動作するか\u003C\u002Fli>\u003Cli>\u003Cstrong>セキュリティテスト\u003C\u002Fstrong>: アクセス制御が適切に機能するか\u003C\u002Fli>\u003Cli>\u003Cstrong>エラー処理テスト\u003C\u002Fstrong>: エラー時に適切にメッセージが表示されるか\u003C\u002Fli>\u003Cli>\u003Cstrong>監査証跡テスト\u003C\u002Fstrong>: 操作履歴が適切に記録されるか\u003C\u002Fli>\u003C\u002Ful>\u003Ch4 id=\"hbdfbfc0329\">\u003Cstrong>性能適格性確認（PQ）\u003C\u002Fstrong>\u003C\u002Fh4>\u003Cp>実際の業務プロセスを模擬したテストを行い、システムが業務要件を満たすことを確認します：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>ユースケーステスト\u003C\u002Fstrong>: 実際の業務シナリオに基づくテスト\u003C\u002Fli>\u003Cli>\u003Cstrong>エンドツーエンドのビジネスプロセステスト\u003C\u002Fstrong>: 承認フローなど一連の処理の確認\u003C\u002Fli>\u003Cli>\u003Cstrong>ユーザー受入れテスト\u003C\u002Fstrong>: 実際のユーザーによる操作確認\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"ha819fb3cfc\">\u003Cstrong>バリデーション報告書の作成\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>バリデーション活動の結果をバリデーション報告書（VR: Validation Report）としてまとめます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>バリデーション活動の概要\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>テスト結果の要約\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>発見された問題と解決策\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>逸脱の記録と対応策\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>合否判定結果\u003C\u002Fstrong>\u003C\u002Fli>\u003Cli>\u003Cstrong>承認\u003C\u002Fstrong>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>バリデーション報告書は、QMS省令第5条の6第4項で要求される「バリデーションから得られた記録」の一部として保管します。\u003C\u002Fp>\u003Ch3 id=\"h098fb621be\">\u003Cstrong>変更管理とリバリデーション\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>システムの変更時には、変更の影響範囲を評価し、必要に応じてリバリデーションを実施します：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>変更管理手順\u003C\u002Fstrong>: システム変更の承認プロセス\u003C\u002Fli>\u003Cli>\u003Cstrong>変更影響評価\u003C\u002Fstrong>: 変更がバリデーション状態に与える影響\u003C\u002Fli>\u003Cli>\u003Cstrong>リバリデーション基準\u003C\u002Fstrong>: どのような変更で再バリデーションが必要か\u003C\u002Fli>\u003Cli>\u003Cstrong>リバリデーション範囲\u003C\u002Fstrong>: 全体または部分的な再バリデーション\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"h229a4d2414\">\u003Cstrong>電子QMSの実装と運用のベストプラクティス\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"ha245c65778\">\u003Cstrong>システム選定のポイント\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSの選定は重要な戦略的決定です。以下の点を考慮しましょう：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>規制対応\u003C\u002Fstrong>: ISO 13485、QMS省令、FDA Part 11対応の機能\u003C\u002Fli>\u003Cli>\u003Cstrong>スケーラビリティ\u003C\u002Fstrong>: 将来の事業拡大に対応できるか\u003C\u002Fli>\u003Cli>\u003Cstrong>カスタマイズ性\u003C\u002Fstrong>: 自社プロセスに合わせた調整が可能か\u003C\u002Fli>\u003Cli>\u003Cstrong>ユーザビリティ\u003C\u002Fstrong>: 操作が直感的で学習が容易か\u003C\u002Fli>\u003Cli>\u003Cstrong>サポート体制\u003C\u002Fstrong>: ベンダーの技術サポート体制\u003C\u002Fli>\u003Cli>\u003Cstrong>コスト構造\u003C\u002Fstrong>: 初期導入コストと運用コストのバランス\u003C\u002Fli>\u003Cli>\u003Cstrong>インターフェース\u003C\u002Fstrong>: 他のシステムとの連携可能性\u003C\u002Fli>\u003Cli>\u003Cstrong>バリデーション支援\u003C\u002Fstrong>: ベンダーのバリデーション支援体制\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"h13b4112fd4\">\u003Cstrong>段階的導入アプローチ\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSの導入は、「ビッグバン」ではなく段階的に行うことが推奨されます：\u003C\u002Fp>\u003Cp>\u003Cstrong>フェーズ1\u003C\u002Fstrong>: 文書管理など基本機能の導入\u003C\u002Fp>\u003Cp>\u003Cstrong>フェーズ2\u003C\u002Fstrong>: 変更管理、逸脱管理などのプロセス追加\u003C\u002Fp>\u003Cp>\u003Cstrong>フェーズ3\u003C\u002Fstrong>: CAPA、教育訓練管理などの導入\u003C\u002Fp>\u003Cp>\u003Cstrong>フェーズ4\u003C\u002Fstrong>: サプライヤー管理、監査管理などの拡張機能\u003C\u002Fp>\u003Cp>各フェーズの移行前にはユーザーの習熟度を評価し、必要に応じて追加トレーニングを実施します。\u003C\u002Fp>\u003Ch3 id=\"hbf0db0cd0e\">\u003Cstrong>データ移行戦略\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>既存の紙文書や旧システムからのデータ移行は慎重に計画する必要があります：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>移行対象の選定\u003C\u002Fstrong>: すべてを移行するか、アクティブな文書のみか\u003C\u002Fli>\u003Cli>\u003Cstrong>移行方法\u003C\u002Fstrong>: スキャンして添付するか、再作成するか\u003C\u002Fli>\u003Cli>\u003Cstrong>メタデータの付与\u003C\u002Fstrong>: 検索を容易にするためのインデックス作成\u003C\u002Fli>\u003Cli>\u003Cstrong>移行検証\u003C\u002Fstrong>: 移行データの完全性確認\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"hb83d8c3f09\">\u003Cstrong>ユーザートレーニング\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>システム導入の成否を左右する重要な要素です：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>役割別トレーニング\u003C\u002Fstrong>: 権限レベルに応じた内容\u003C\u002Fli>\u003Cli>\u003Cstrong>ハンズオン形式\u003C\u002Fstrong>: 実際のシステムを使った実践的トレーニング\u003C\u002Fli>\u003Cli>\u003Cstrong>トレーニング評価\u003C\u002Fstrong>: 理解度のチェック\u003C\u002Fli>\u003Cli>\u003Cstrong>トレーニング記録\u003C\u002Fstrong>: QMS要件に従った教育記録の維持\u003C\u002Fli>\u003Cli>\u003Cstrong>リファレンスガイド\u003C\u002Fstrong>: クイックリファレンスや操作マニュアルの整備\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"hd326b06754\">\u003Cstrong>査察・監査対応のポイント\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"hcf3ccd9854\">\u003Cstrong>PMDAによる調査での電子システム評価\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>PMDAによる適合性調査では、以下の点が重点的に確認されます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>ソフトウェアバリデーション記録\u003C\u002Fstrong>: QMS省令第5条の6への対応\u003C\u002Fli>\u003Cli>\u003Cstrong>電子記録の信頼性\u003C\u002Fstrong>: データの完全性、セキュリティ対策\u003C\u002Fli>\u003Cli>\u003Cstrong>電子署名の管理\u003C\u002Fstrong>: 権限設定、ID\u002Fパスワード管理\u003C\u002Fli>\u003Cli>\u003Cstrong>バックアップ・リカバリ\u003C\u002Fstrong>: データ保護措置\u003C\u002Fli>\u003Cli>\u003Cstrong>変更管理\u003C\u002Fstrong>: システム変更の管理と再バリデーション\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"hcf05357136\">\u003Cstrong>FDA査察での電子記録・電子署名関連のポイント\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>FDA査察では、21 CFR Part 11への対応が詳細に確認されます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>システムバリデーション\u003C\u002Fstrong>: リスクベースドアプローチの適用\u003C\u002Fli>\u003Cli>\u003Cstrong>監査証跡\u003C\u002Fstrong>: 変更履歴の完全性\u003C\u002Fli>\u003Cli>\u003Cstrong>システムセキュリティ\u003C\u002Fstrong>: アクセス管理、セキュリティポリシー\u003C\u002Fli>\u003Cli>\u003Cstrong>バックアップ・アーカイブ\u003C\u002Fstrong>: 記録の長期保存\u003C\u002Fli>\u003Cli>\u003Cstrong>電子署名の同等性\u003C\u002Fstrong>: 手書き署名との同等性の担保\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"hfa7da7388b\">\u003Cstrong>内部監査チェックリスト\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMSの内部監査では、以下の点をチェックします：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>バリデーション状態\u003C\u002Fstrong>: 現在のシステム構成とバリデーション記録の整合性\u003C\u002Fli>\u003Cli>\u003Cstrong>変更管理\u003C\u002Fstrong>: システム変更の適切な管理\u003C\u002Fli>\u003Cli>\u003Cstrong>ユーザー管理\u003C\u002Fstrong>: アクセス権限の定期的レビュー\u003C\u002Fli>\u003Cli>\u003Cstrong>教育訓練\u003C\u002Fstrong>: ユーザートレーニングの実施状況\u003C\u002Fli>\u003Cli>\u003Cstrong>バックアップ\u003C\u002Fstrong>: データバックアップの定期実行と復元テスト\u003C\u002Fli>\u003Cli>\u003Cstrong>セキュリティインシデント\u003C\u002Fstrong>: システムセキュリティ違反の管理\u003C\u002Fli>\u003Cli>\u003Cstrong>SOPの遵守\u003C\u002Fstrong>: 運用手順の遵守状況\u003C\u002Fli>\u003C\u002Ful>\u003Ch2 id=\"hc3efd7a869\">\u003Cstrong>電子QMS導入事例と成功要因\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"hede16ddd91\">\u003Cstrong>中小規模医療機器メーカーでの導入事例\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>従業員100名程度の医療機器メーカーA社では、クラウド型電子QMSを導入し、以下の成果を得ました：\u003C\u002Fp>\u003Cul>\u003Cli>文書承認プロセスの60%時間短縮\u003C\u002Fli>\u003Cli>監査準備工数の40%削減\u003C\u002Fli>\u003Cli>紙文書コストの80%削減\u003C\u002Fli>\u003Cli>リモートワーク環境下でのQMS業務継続性確保\u003C\u002Fli>\u003C\u002Ful>\u003Cp>成功の鍵は、\u003Cstrong>現場ユーザーの早期巻き込み\u003C\u002Fstrong>と\u003Cstrong>段階的導入アプローチ\u003C\u002Fstrong>でした。まず文書管理から開始し、ユーザーの習熟度に合わせて機能を拡張していきました。\u003C\u002Fp>\u003Ch3 id=\"h4df8301ef0\">\u003Cstrong>グローバル医療機器メーカーでの導入事例\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>多国籍医療機器メーカーB社では、グローバル統一電子QMSの導入により：\u003C\u002Fp>\u003Cul>\u003Cli>多拠点間での品質情報の共有迅速化\u003C\u002Fli>\u003Cli>各国規制対応の標準化\u003C\u002Fli>\u003Cli>グローバルCAPAプロセスの効率化\u003C\u002Fli>\u003Cli>各国当局査察対応の統一化\u003C\u002Fli>\u003C\u002Ful>\u003Cp>成功要因は、\u003Cstrong>グローバルQMSチーム\u003C\u002Fstrong>の設置と、各国の規制要件を考慮した\u003Cstrong>柔軟なシステム設計\u003C\u002Fstrong>でした。\u003C\u002Fp>\u003Ch3 id=\"h76d747ac3d\">\u003Cstrong>ROI（投資対効果）分析の実例\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>C社（中堅医療機器メーカー）の電子QMS導入のROI分析：\u003C\u002Fp>\u003Cp>\u003Cstrong>初期投資\u003C\u002Fstrong>:\u003C\u002Fp>\u003Cul>\u003Cli>システム購入・設定: 1,500万円\u003C\u002Fli>\u003Cli>バリデーション: 500万円\u003C\u002Fli>\u003Cli>トレーニング: 200万円\u003C\u002Fli>\u003Cli>初期データ移行: 300万円\u003C\u002Fli>\u003Cli>合計: 2,500万円\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>年間運用コスト\u003C\u002Fstrong>:\u003C\u002Fp>\u003Cul>\u003Cli>ライセンス料: 200万円\u003C\u002Fli>\u003Cli>システム管理者人件費: 400万円\u003C\u002Fli>\u003Cli>定期メンテナンス: 100万円\u003C\u002Fli>\u003Cli>合計: 700万円\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>年間削減効果\u003C\u002Fstrong>:\u003C\u002Fp>\u003Cul>\u003Cli>紙文書・保管コスト: 300万円\u003C\u002Fli>\u003Cli>作業効率化による工数削減: 800万円\u003C\u002Fli>\u003Cli>監査準備工数削減: 200万円\u003C\u002Fli>\u003Cli>不具合対応の迅速化による間接効果: 500万円\u003C\u002Fli>\u003Cli>合計: 1,800万円\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>ROI計算\u003C\u002Fstrong>: 3年目までに初期投資を回収、以降は年間1,100万円の効果\u003C\u002Fp>\u003Ch2 id=\"hfe0f7dc6ed\">\u003Cstrong>まとめと今後の展望\u003C\u002Fstrong>\u003C\u002Fh2>\u003Ch3 id=\"h7d33e5f82f\">\u003Cstrong>電子QMS導入の成功要因\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMS導入の成功には、以下の要素が重要です：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>経営層のコミットメント\u003C\u002Fstrong>: 導入の意義と目標の明確化\u003C\u002Fli>\u003Cli>\u003Cstrong>現場の巻き込み\u003C\u002Fstrong>: 実際のユーザーの参画\u003C\u002Fli>\u003Cli>\u003Cstrong>段階的アプローチ\u003C\u002Fstrong>: 無理のないペースでの導入\u003C\u002Fli>\u003Cli>\u003Cstrong>適切なバリデーション\u003C\u002Fstrong>: リスクに応じた効率的バリデーション\u003C\u002Fli>\u003Cli>\u003Cstrong>継続的改善\u003C\u002Fstrong>: 導入後も定期的な改善活動\u003C\u002Fli>\u003C\u002Ful>\u003Ch3 id=\"h7c37f05750\">\u003Cstrong>電子QMSの将来展望\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>医療機器業界における電子QMSは、今後以下のような発展が予想されます：\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>AI・機械学習の活用\u003C\u002Fstrong>: 品質データの予測分析、傾向検出\u003C\u002Fli>\u003Cli>\u003Cstrong>IoT連携\u003C\u002Fstrong>: 製造装置からのリアルタイムデータ収集・分析\u003C\u002Fli>\u003Cli>\u003Cstrong>ブロックチェーン技術\u003C\u002Fstrong>: 電子記録の改ざん防止\u003C\u002Fli>\u003Cli>\u003Cstrong>規制の国際調和\u003C\u002Fstrong>: 電子記録・電子署名に関する国際的要件の標準化\u003C\u002Fli>\u003Cli>\u003Cstrong>クラウドソリューションの普及\u003C\u002Fstrong>: 中小企業でも導入しやすい環境\u003C\u002Fli>\u003C\u002Ful>\u003Cp>電子QMSは単なる「紙からデジタルへの移行」ではなく、\u003Cstrong>医療機器品質管理のデジタルトランスフォーメーション（DX）\u003C\u002Fstrong>の一環として捉え、継続的に進化させていくことが重要です。\u003C\u002Fp>\u003Ch3 id=\"ha214098e44\">\u003Cstrong>まとめ\u003C\u002Fstrong>\u003C\u002Fh3>\u003Cp>電子QMS導入は、業務効率化とコンプライアンス強化の両立を可能にする重要な戦略です。しかし、その導入には適切な計画、リスク評価、そして規制要件に準拠したソフトウェアバリデーションが不可欠です。本記事で解説したアプローチを参考に、自社の状況に合わせた電子QMS導入戦略を策定し、医療機器品質管理の次のステージへと進んでいきましょう。\u003C\u002Fp>",{"url":146,"height":51,"width":51},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002F3eafcca6ee8943e599c6b1dd01e8d023\u002FChatGPT%20Image%202025%E5%B9%B44%E6%9C%888%E6%97%A5%2015_39_22-min.webp","医療機器業界の電子QMS導入（eQMS）による業務効率化とコンプライアンス強化を実現するポイントを解説。QMS省令・ISO 13485対応のソフトウェアバリデーション手順から、ROI分析、成功事例まで、品質管理のデジタル化を検討する担当者必見の実践ガイド。",{"id":149,"createdAt":150,"updatedAt":151,"publishedAt":150,"revisedAt":151,"name":152,"image":153,"profile":157,"subtitle":158,"profile_url":159,"profile_sameas_url":160},"l0496behlnj1","2024-09-09T08:43:43.850Z","2024-09-26T16:00:16.227Z","居原 範道",{"url":154,"height":155,"width":156},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002Ff66dcbcc145648f88aa317fc3a705f91\u002Ff65490240dc1402a94f557918b022042\u002Fihara2-min.webp",247,183,"\u003Cp>信州大学理学部卒業後、バクスター株式会社で製造エンジニアとしてキャリアをスタート。\u003C\u002Fp>\u003Cp>その後、アボットジャパン株式会社とボストンサイエンティフィックジャパン株式会社で品質保証責任者を務め、GQP\u002FQMS構築・改善、QMS調査、製品回収に伴う行政対応など、重要な責務を担当。40年以上の医療機器業界経験を持ち、GMP活動、プロセスバリデーション、滅菌サイクル開発にも精通。\u003C\u002Fp>\u003Cp>現在はQMサービス.IHARAの代表として、医療機器QMSに関する企業コンサルティング、セミナー講師、著作活動を展開。JRCA\u002FIRCA認定ISO9001審査員の資格を有し、実践的なQMS管理の専門知識で業界に貢献している。\u003C\u002Fp>","医療機器QMSコンサルタント","https:\u002F\u002Fsites.google.com\u002Fa\u002Fqmserve.com\u002Fqms-i\u002Fhome\u002F%E3%83%97%E3%83%AD%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB","https:\u002F\u002Fkoushiru.com\u002Flecturer\u002Fn-ihara\u002F",[162,163],{"id":30,"createdAt":31,"updatedAt":31,"publishedAt":31,"revisedAt":31,"name":32},{"id":83,"createdAt":84,"updatedAt":84,"publishedAt":84,"revisedAt":84,"name":85},1794188249871]