前回は、SBOMが「何であるか」「なぜ必要か」を整理しました。今回はおそらく最も多くの方が気になっている疑問——「SBOMは法律で義務づけられているのか」を、米国と日本それぞれの現状に分けて見ていきます。
米国では、SBOMは医療機器の承認申請における法律上の要件です。根拠となるのは、連邦食品・医薬品・化粧品法(FD&C法)に追加された524条Bという規定で、2022年末に成立した法律に基づき、2023年3月末から施行されています。
524条Bは、ソフトウェアを搭載し、かつネットワーク接続の技術的な能力を持つ「サイバーデバイス」に該当する医療機器を対象に、510(k)・De Novo・PMA・HDEといった各種の申請区分において、次のような資料の提出を義務づけています。
- 市販後の脆弱性を監視・特定・対処する計画(協調的な脆弱性開示の仕組みを含む)
- ソフトウェアを最新の状態に保つための設計・妥当性確認のプロセス
- SBOM(当局の求めに応じて開示できる、使用中のすべての市販・オープンソースソフトウェア部品の一覧)
この規定に不備がある申請は、実質審査に入る前の段階でFDAから受理拒否(Refuse to Accept)される可能性があります。単なる推奨ではなく、書類の完備性を左右する要件として運用されている点が、日本の状況と大きく異なります。
さらに2025年から2026年にかけて、FDAはこの義務を実務レベルまで具体化するガイダンスの整備を進めており、SBOMの提出形式としてSPDXやCycloneDXといった機械可読フォーマットが明確に位置づけられるようになっています。
これに対して日本では、SBOMの提出は法律上の義務にはなっていません。関連する規定を整理すると、次のようになります。
| 階層 | 内容 |
|---|---|
| 基本要件基準 第12条第3項 | 医療機器の製造販売承認申請時に、国際規格 JIS T 81001-5-1 への適合性を示す資料の添付を求める規定。SBOMそのものの提出は、この通知の本文には明記されていません。 |
| JIS T 81001-5-1 | ソフトウェアのライフサイクル管理に関する要求事項の規格。SBOMへの明示的な要求は本文になく、附属書の注記でごく簡単に触れられる程度です。 |
| 医療機器のサイバーセキュリティ確保に関する手引書(第2版) | 附属書AでSBOMの最小要素7項目を示していますが、位置づけは推奨です。 |
| SBOM導入・運用ガイドライン(第1版) | 2026年に発行された、最新かつ最も詳細な文書。ただし通知本文は「同ガイダンスを参考として、必要な対応を行うよう」という表現にとどまり、参考ガイダンスという位置づけです。 |
つまり日本では、「SBOMを作らなければ承認が下りない」という状態にはなっていません。ただし、これは需要がないことを意味しません。次に見るように、規制当局とは独立に、SBOMを求める・準備しておくべき理由が存在します。
米国については、事実上必須と考えてよい状況です。FDAのガイダンスがCycloneDXやSPDXといった機械可読フォーマットでの提出を明示しており、PDFやExcelでの提出は想定されていません。
日本については、法的に機械可読形式が義務づけられているわけではありません。ただしガイドライン第1版は、SBOMデータを「機械可読かつ相互運用可能なフォーマットを用いて作成・共有されることが求められる」とし、SPDX 2.2以上・CycloneDX 1.6以上という具体的なバージョン下限まで示しています。法的拘束力はないものの、実務上の期待水準としてはかなり明確に機械可読を前提にしていると読めます。
規制当局が一律にSBOMの提出を求めることは、現時点の日本では想定されていません(提出義務がないため)。
一方で、医療機関側からSBOMの提供を求められる可能性はあります。ガイドラインは、医療機関へのSBOM提供のベースラインや、契約条項にSBOM提供を盛り込むことについて言及しており、調達・保守契約の一環として求められるケースが今後増えていくと考えられます。これは規制当局の要求とは別の、取引先からの要求という性質のものです。
現行の通知を見る限り、承認・認証申請の際にSBOM本体の提出を一律に求める規定は明記されていません。基本要件基準が求めているのは、あくまでJIS T 81001-5-1への適合性を示す資料であり、SBOMそのものではないためです。
ただし、「提出を求められていない=準備しなくてよい」ではない点に注意が必要です。ガイドラインは、規制当局への申請等にSBOMを用いる場合の記載方法(把握できているすべてのコンポーネント情報を記載することを原則とする、など)を定めており、いつでも提出できる状態を準備しておくことを前提とした書きぶりになっています。求められたときに慌てて作り始めるのではなく、日頃から整備しておくことが実務上の要点です。
ここまで、SBOMの規制上の位置づけを日米で比較しました。次回・最終回では、より実務に踏み込み、「SBOMの機密は守られるのか」「Excel提出はなぜ勧められないのか」「OSやOTS製品のSBOMはどう作るのか」「ビルドのたびに自動生成できるのか」といった、実際に手を動かす段階で必ず出てくる疑問を整理します。