JIS T 81001-5-1入門

JIS T 81001-5-1対応で最初に確認すべきこと

2026年6月18日監修・作成：AIGIS編集部難度：中級

対象読者：開発責任者品質保証部門薬事部門

JIS T 81001-5-1は、ヘルスソフトウェア・医療機器ソフトウェアのセキュリティを対象とした国際規格（IEC 81001-5-1）の国内版です。設計から廃棄に至るライフサイクル全体を通じて、セキュリティ活動をどのように開発・保守プロセスに組み込むかを規定しています。

「対応しなければならないらしい」という認識はあっても、どこから手をつければいいか分からないという声は多く聞きます。最初に確認すべきポイントを整理しました。

1. 現在の開発・保守プロセスとのギャップ

規格が求める活動の多くは、既存の開発プロセスの中に組み込む形で実施します。まず確認すべきは「今のプロセスに、どのセキュリティ活動が含まれていて、どこが抜けているか」です。

たとえば、設計段階の脅威分析（TARA）、コードレビューでのセキュリティチェック、第三者によるセキュリティ試験、脆弱性情報収集の仕組みなど、規格が要求する活動のうち、どれが現状のフローに存在するかを棚卸しします。完全にゼロから始める組織は少なく、既存の活動をベースに補完・強化する形が現実的です。

規格の中核は「リスクに基づくセキュリティ対策の実施」です。製品が持つ通信機能、外部接続、格納データを整理し、攻撃者がどのような経路でどのような被害を起こせるかを分析する「脅威分析（TARA）」が求められます。

既にリスク管理の仕組みがある場合（ISO 14971ベースのリスクマネジメント等）、そこにサイバーセキュリティ固有の脅威分析を統合する形が多いです。完全に別のプロセスとして立ち上げる必要はありません。

製品に含まれるOSS・サードパーティコンポーネントを把握し、新たな脆弱性が公表されたときに影響範囲を特定できる体制が必要です。これはSBOMの整備と、脆弱性情報を定期的に確認するプロセスの両方を指します。

規格では市販後の継続的な脆弱性管理も要求しており、「出荷したら終わり」ではなく、販売継続中は監視と対応を続ける必要があります。

どれだけ良いセキュリティ活動をしていても、審査・監査で説明できる文書がなければ評価されません。規格では、セキュリティ計画書、脅威分析結果、テスト記録、脆弱性対応記録などの文書整備が求められます。

文書の形式や粒度について厳密な規定があるわけではないため、「審査担当者が確認できる」レベルで整備することが現実的な目標になります。

いきなり全ての要求事項を満たそうとすると、工数が見えず動きにくくなります。まずは現状とのギャップを整理し、製品の開発段階・上市スケジュール・リスクの大きさに応じて優先順位をつけたロードマップを作ることが出発点です。

AIGISでは、製品の構成・開発状況をヒアリングした上で、対応の優先順位と具体的な進め方をご提案しています。まずは相談からでも、お気軽にご連絡ください。