なぜIEC 81001-5-1:2021が必要か
本記事の解説動画
IEC 81001-5-1:2021 は、ヘルスソフトウェアの製品ライフサイクルにおけるセキュリティ関連アクティビティを規定した規格である。2026年8月現在、日本では JIS T 81001-5-1:2023 として国内規格化され、基本要件基準第12条第3項への適合を示す手段として通知に明記されている。本稿は「規格が何を要求しているか」を箇条の構成に沿って整理する。自社の開発プロセスへどう組み込み、申請でどう示すかという導入実務は、姉妹記事「なぜIEC 81001-5-1が必要か」で扱う。
1．規格の素性
| 項目 | 内容 |
|---|---|
| 国際規格 | IEC 81001-5-1:2021（第1版） |
| 正式名称 | Health software and health IT systems safety, effectiveness and security ― Part 5-1: Security ― Activities in the product life cycle |
| 国内規格 | JIS T 81001-5-1:2023（IEC 81001-5-1:2021 と IDT）。和文名称「ヘルスソフトウェア及びヘルスITシステムの安全，有効性及びセキュリティ―第5-1部：セキュリティ―製品ライフサイクルにおけるアクティビティ」 |
| 適用対象 | ヘルスソフトウェア（医療機器ソフトウェアを含む）の開発および保守 |
| 日本の規制上の位置づけ | 基本要件基準（平成17年厚生労働省告示第122号）第12条第3項への適合を示す規格（薬生機審発0331第8号、同0523第1号） |
| 関連規格 | IEC 62443-4-1（産業用オートメーション・制御システムのセキュア開発ライフサイクル）への適合を支援する要求を規定 |
2．IEC 62304に「足す」規格であって、置き換える規格ではない
この規格の設計思想でもっとも重要なのは、セキュリティライフサイクルを一から定義していない、という点である。医療機器製造業者にはすでにソフトウェアライフサイクルプロセス（IEC 62304 / JIS T 2304）とリスクマネジメントプロセス（ISO 14971 / JIS T 14971）が実装されていることを前提に、既存プロセスの枠組みに対してサイバーセキュリティに関連するアクティビティを追加する形式を採っている。
厚生労働省の通知も、この関係を次のように整理している。
JIS T 81001-5-1（ヘルスソフトウェア及びヘルスITシステムの安全、有効性及びセキュリティ－第5－1部：セキュリティ－製品ライフサイクルにおけるアクティビティ）は、医療機器の製造販売業者がJIS T 2304（医療機器ソフトウェアライフサイクルプロセス）に規定する製品ライフサイクルの要求事項に加えて実施するサイバーセキュリティに関する取組を規定している。
出典：厚生労働省「医療機器の基本要件基準第12条第3項の適用について」（令和5年3月31日 薬生機審発0331第8号）
実務上の含意
既存のJIS T 2304対応SOPを捨てて新規に作り直す必要はない。既存の開発計画書・アーキテクチャ設計書・構成管理手順・問題解決手順に、セキュリティの観点を追記していくのが正しい進め方である。逆に、JIS T 2304対応が不十分なまま81001-5-1に取り組んでも、土台がないため要求を満たせない。
3．箇条ごとの要求の趣旨
IEC 81001-5-1 は有償規格であり本文を逐語引用することはできないが、厚生労働省の通知（令和5年5月23日 薬生機審発0523第1号）が、承認・認証申請時に確認すべき事項を箇条ごとに公表している。規格の要求構造は、この通知から正確に把握できる。
| 箇条 | プロセス | 通知が求める確認事項 |
|---|---|---|
| 箇条4 | 一般要求事項 | サイバーセキュリティの確保に係る活動が品質マネジメントシステムに基づいて行われていること／規制当局および顧客に対して脆弱性を適時に通知する活動を確立すること／医療機器のリスクマネジメントがセキュリティの脆弱性・脅威等を考慮したものであること |
| 箇条5 | ソフトウェア開発プロセス | 開発計画においてセキュリティ更新や開発環境等のセキュリティを考慮すること／製品のセキュリティ機能を含むセキュリティ要求事項を特定すること／意図する使用環境、信頼境界、多層防御等を考慮してアーキテクチャー設計を行うこと／セキュリティ設計のベストプラクティスを考慮した設計および実装を行うこと／ソフトウェアシステム試験によりセキュリティ要求事項が満たされ、リスクマネジメントプロセスで特定した脅威への対応方法が設計に実装され有効であることを確認すること |
| 箇条6 | ソフトウェア保守プロセス | 顧客に対するセキュリティ更新の通知方針について定めておくこと |
| 箇条7 | セキュリティに関連するリスクマネジメントプロセス | 医療機器の意図する使用および使用環境を考慮して、関連する脆弱性を特定し、関連する脅威を推定して評価し、リスクコントロール手段によって脅威をコントロールし、その有効性を監視すること |
| 箇条8 | ソフトウェア構成管理プロセス | 医療機器の開発、保守およびサポートのための、変更管理および変更履歴を伴う構成管理プロセスを確立すること |
| 箇条9 | ソフトウェア問題解決プロセス | セキュリティの脆弱性に関する情報伝達および処理の手順を定め、セキュリティ問題に対して情報開示を含めて手順に従って実施すること |
箇条の並びがJIS T 2304の箇条4〜9とそのまま対応していることに注目したい。これは偶然ではなく、既存のソフトウェアライフサイクルプロセスの各段階に対して、セキュリティの観点を一対一で重ねられるように設計されているためである。
4．ISO 14971との関係 ― 用語の対応づけ
サイバーセキュリティのリスクマネジメントを、まったく別の体系として立ち上げる必要はない。ISO 14971 / JIS T 14971 のプロセスの流れを、セキュリティの語彙で読み替えて運用するのが基本である。
| ISO 14971 / JIS T 14971 の概念 | セキュリティ文脈での対応物 | 実務での読み替え |
|---|---|---|
| ハザード（危害の潜在的な源） | 脆弱性（セキュリティホール） | 攻撃の起点となり得る設計上・実装上の弱点を洗い出す |
| 危険状態（人がハザードにさらされる状況） | 脅威 | 脆弱性が攻撃者に悪用され、悪影響が生じ得る状態を推定する |
| 危害 | 危害（患者・使用者への健康被害）そのもの | 診断・治療の遅延、不適切な治療の実施、機器の停止による健康影響など |
| リスクコントロール | セキュリティ対策（多層防御、アクセス制御、暗号化、監査ログ等） | 対策の実装だけでなく、有効性の検証と市販後の監視まで含める |
よくある誤り：危害を「サイバーテロ」と対応づける
「ハザード⇒脆弱性、危険状態⇒脅威、危害⇒サイバーテロ」といった対応表を見かけることがあるが、最後の行は誤りである。ISO 14971における危害（harm）は人の健康への傷害・悪影響を指す概念であり、攻撃の類型名ではない。サイバーテロやランサムウェア攻撃は「脅威」の側に置かれるべきものである。危害はあくまで、その脅威が顕在化した結果として患者・使用者に生じる健康被害として評価する。この対応を取り違えると、リスク分析の受容可能性判断そのものが成立しなくなる。
厚生労働省の通知も、基本要件基準第12条第3項に求めるリスクマネジメントについて「JIS T 81001-5-1に示されている通り、サイバーセキュリティの脆弱性を特定し、その悪用によって生じる脅威や悪影響に伴うリスクを評価し、適切にリスクをコントロールすること」と説明しており、上記の整理と一致している。
5．想定される脅威と脅威モデリング
基本要件基準第12条第3項の適用通知は、「外部からの不正アクセス及び攻撃アクセス等」として次を想定していると明示している。
- 脆弱性を攻撃対象とするなど、設計者が通常使用において想定していない手法を用いた悪意ある不正アクセス
- 意図的に過剰な負荷を与える攻撃（DoS攻撃、DDoS攻撃等）
- マルウェア（悪意のあるソフトウェア）の感染を意図する攻撃によるアクセス
通知はさらに、「昨今のサイバー攻撃についてはその攻撃形式が多様化・高度化しており、今後はこれらの攻撃手法の他にも対応することも必要となり得る」としている。すなわち、列挙された3類型への対応で足りるという読み方はできない。
そこで用いられるのが脅威モデリングである。想定される攻撃者、攻撃手法、影響を受け得る資産、実現可能な対策を体系的に洗い出し、対策の優先順位を決める。箇条5がアーキテクチャ設計において「意図する使用環境、信頼境界、多層防御等を考慮」することを求めているのは、脅威モデリングの成果を設計に反映させることを意図している。
6．接続環境の特定が出発点
基本要件基準第12条第3項の適用通知は、対象となる「他の機器及びネットワーク等と接続して使用する医療機器」の範囲を具体的に示している。
| 区分 | 具体例 |
|---|---|
| 他の機器 | 医療機器、IoT機器、周辺機器、外部記録媒体（USB、SD、HDD、CD、DVD等）、電子カルテ、PC（外部からの持ち込みPCを含む） |
| ネットワーク | 院内システム、院外システム、グローバル |
| 動作環境 | 医療機関、在宅、救急、植込み型機器等 |
| 使用環境 | 接続するネットワーク種別、オペレーティングシステム、各種ライブラリ等のプラットフォーム |
「インターネットに接続しないから対象外」という判断は成り立ちにくい。USBメモリでのデータ受け渡しや保守用PCの接続も、通知が想定する接続に含まれるためである。
7．継続的なプロセスであること
脆弱性は日々発見され、攻撃手法も進化する。したがって81001-5-1に基づくセキュリティリスクマネジメントは、承認取得時点で完結する一時的な作業ではない。箇条6（保守）と箇条9（問題解決）が明示的にプロセスとして要求されているのは、市販後のライフサイクル全体を対象とするためである。基本要件基準第12条第3項も「ライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造」されていることを求めており、通知はこの計画に、医療機関との連携や市販後のアップデートを含む脆弱性対策の計画も含まれると解説している。
8．2026年時点で取るべき対応
規格要求の理解として押さえるべき点
- 版と国内規格番号を正しく書く。国際規格はIEC 81001-5-1:2021（第1版）、国内規格はJIS T 81001-5-1:2023（IDT）。
- 「62304に追加する」構造を前提に設計する。箇条4〜9はJIS T 2304の箇条4〜9に対応する。新規のセキュリティ専用プロセスを別建てで作ると、二重管理になり整合が取れなくなる。
- 用語対応を正しく持つ。ハザード↔脆弱性、危険状態↔脅威。危害は「サイバーテロ」ではなく、患者・使用者への健康被害である。
- 脅威モデリングの成果をアーキテクチャ設計に落とす。信頼境界と多層防御の考え方を設計文書に明示する。
- 接続環境を網羅的に特定する。USB・保守PC・電子カルテ連携も接続に含まれる。システム構成図・ネットワーク構成図で意図する使用環境を明示する。
- 市販後の運用まで含めて計画する。セキュリティ更新の通知方針、脆弱性情報の受付と開示手順、サポート終了時期まで含めた保守計画を用意する。
以上が規格の要求そのものである。これを自社の手順書・設計文書・申請資料にどう落とし込むかについては、「なぜIEC 81001-5-1が必要か」で、基本要件基準第12条第3項の適合性確認の手順に沿って解説している。
出典
- 厚生労働省「医療機器の基本要件基準第12条第3項の適用について」（令和5年3月31日 薬生機審発0331第8号）
https://www.pmda.go.jp/files/000252064.pdf - 厚生労働省「医療機器の基本要件基準第12条第3項の適合性の確認について」（令和5年5月23日 薬生機審発0523第1号）
https://www.pmda.go.jp/files/000252724.pdf - 厚生労働省「医療機器におけるサイバーセキュリティについて」（関連通知一覧）
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000179749_00009.html - 日本規格協会「JIS T 81001-5-1:2023」
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+T+81001-5-1:2023 - PMDA「医療機器のサイバーセキュリティについて」
https://www.pmda.go.jp/review-services/drug-reviews/about-reviews/devices/0051.html
この記事へのコメントはありません。