「リスクマネジメントの本質 ― “安全性”と“セキュリティ”を分けて考える」医療機器ソフトウェア開発 スタートアップのための“後悔しない”実践ガイド第6回

はじめに

「サイバーセキュリティ対応＝IEC 81001-5-1 完全準拠」ではない

医療機器ソフトウェア開発の現場で、サイバーセキュリティの話題になると、次のような声をよく耳にします。

• IEC 81001-5-1 を全部やらないといけないのか

• スタートアップには重すぎるのではないか

• そもそも、どこまでが“規制要求”なのか分からない

この混乱の多くは、
「規制として求められていること」と
「それを実現するための規格」を混同していること
から生じています。

今回は、リスクマネジメントの本質に立ち返りながら、特に誤解されやすい次の2点を整理します。

1. なぜ「安全性」と「セキュリティ」は分けて考えるべきなのか

2. 日本の医療機器規制が、実際に何を求めているのか

1. 日本の医療機器規制における「セキュリティ要求」の正体

最初に、はっきりさせておくべきことがあります。
日本の医療機器規制において、サイバーセキュリティ対応の法的根拠は
IEC 81001-5-1（JIS T 81001-5-1）がすべてではありません。

規制要求の根拠は、医療機器の基本要件基準 第12条第3項 です。

この条文は、

• 他の機器やネットワークと接続して使用される医療機器

• 外部からの不正アクセスや攻撃が想定される医療機器

を対象として、次のことを求めています。

👉 これが、日本の規制としての「Must（必須要求）」です。

2. IEC 81001-5-1 は「どうやって満たすか」を示す規格

では、IEC 81001-5-1 は何者なのでしょうか。

IEC 81001-5-1（JIS T 81001-5-1）は、基本要件基準 第12条第3項の要求を満たすための“推奨される実装手段の一つ”として位置づけられています。

厚生労働省・PMDA は、この規格を活用して適合を説明することを推奨していますが、
IEC 81001-5-1 のすべての要求事項を網羅的に満たすこと自体が、日本の法規制として義務付けられているわけではありません。

ここを取り違えると、

• 実態に合わない重たい体制

• 規格対応のためだけの文書作成

• 開発スピードの低下

といった“後悔ポイント”に直結します。

3. それでも「安全性」と「セキュリティ」は分けて考えるべき理由

では、なぜ安全性（Safety）とセキュリティ（Security）を分けて考える必要があるのでしょうか。理由はシンプルです。

前提となる「世界観」がまったく異なるから

同じ「患者危害」という結果に至る場合でも、原因の捉え方、対策の立て方、そして規制当局への説明の仕方はまったく異なります。

4. 規制が本当に見ているのは「安全性への影響」

基本要件基準 第12条第3項が問題にしているのは、サイバー攻撃そのものではありません。
規制が問うているのは、サイバーセキュリティに係る危険性が、医療機器の機能や安全性にどのような影響を与えるのかという点です。

つまり、

セキュリティ事象
↓
機能の停止・誤動作・制御不能
↓
患者・使用者への危害

この因果関係を説明できることが、日本の医療機器規制で求められています。

5. Lean-QMS的な現実解 ― 統合しない、関連付ける

スタートアップにとって現実的なのは、次のような整理です。

① 安全性リスク（ISO 14971）

• リスク分析

• 危害・危険状態の特定

• リスクコントロール

 ② セキュリティリスク（第12条第3項対応）

• 動作環境・接続構成の明確化

• 不正アクセス等による危険性の特定・評価

• セキュリティ対策

• 市販後を含むサイバーセキュリティ計画

③ 両者は「リンク」でつなぐ

セキュリティリスクがどの安全性リスクに影響するかを参照関係として示す

👉 一つの表に無理やり統合しないことが、Lean-QMS を破綻させないコツです。

6. 規制当局が見ているのは「規格名」ではない

PMDA が見ているのは、
・IEC 81001-5-1 の何条まで対応したか
ではありません。

見ているのは、

• 自機器の構成と使用環境を理解しているか

• 想定しているリスクが現実的か

• ライフサイクル全体を見ているか

• 説明に一貫性があるか

つまり、「このチームは、サイバーセキュリティを規制対応として“理解して扱っているか」です。

おわりに ― 規制は敵ではない。設計思想を問う“鏡”である

日本の医療機器規制は、「すべての規格を完璧に守れ」とは言っていません。

1. 何が規制要求なのか

2. 何が推奨される手段なのか

3. それを自社製品としてどう説明するのか

これを整理することが、Lean-QMS を成立させ、後悔しない開発につながります。

次回は、この流れを受けて、市販後フェーズの実務であるSBOM・脆弱性対応・PSIRT体制に踏み込みます。

次回予告

第7回　「SBOMと脆弱性対応 ― SaMD時代の保守運用」SBOM作成・更新／PSIRT体制／脆弱性情報のモニタリングと報告

補足動画のご案内（理解を深めたい方へ）

本記事で解説した「安全性（Safety）とセキュリティ（Security）の違い」「日本の医療機器規制におけるサイバーセキュリティ要求の位置づけ」については、YouTube 動画でも詳しく解説しています。

👉 サイバーセキュリティと医療機器規制の考え方（解説動画）

この動画では、

• IEC 81001-5-1 が日本の規制要求そのものではない理由

• 医療機器の基本要件基準 第12条第3項が実際に求めているポイント

• 安全性リスクとセキュリティリスクをどう分けて、どう関連付けて説明すべきか

を、図解と具体例を用いて説明しています。

文章だけではイメージしづらい方は、まず動画で全体像を把握したうえで本記事を読み返していただくと、実務での説明や資料作成がよりスムーズになるはずです。

執筆・監修：酒井 由夫（Medical Software Consulting / xCAREエキスパート）

医療機器ソフトウェア開発コンサルタント／xCAREエキスパート

医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。
クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。
現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。

🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら

「医療機器ソフトウェア開発でお困りの方へ」

「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。

👉 xCAREへのご相談はこちら（無料個別相談あり）