SBOM（Software Bill of Materials／ソフトウェア部品表）とは、一つのソフトウェア製品が、どのような部品（コンポーネント）から成り立っているかを一覧にしたデータです。

身近な例で言えば、食品パッケージの「原材料表示」に近いものだと考えると分かりやすいでしょう。加工食品には、使われている原材料・添加物が成分表示として記載されています。私たちはそれを見て、アレルギー物質が含まれていないか、体に合わない成分がないかを確認できます。

ソフトウェアも同じです。現代のソフトウェア製品は、開発者が一から書いたコードだけでなく、世の中に公開されているオープンソースソフトウェア（OSS）の部品や、他社が作った既製品（OTS：Off-The-Shelf ソフトウェア）を組み合わせて作られているのが普通です。ある調査では、ソフトウェア製品に含まれるコードの大部分がこうした外部の部品で占められているとも言われています。

SBOMは、この「中身の部品構成」を一覧化したものです。具体的には、各部品の名称・バージョン・提供元（開発元）といった情報が、コンポーネントごとに記載されます。

SBOMの必要性が世界的に強く意識されるようになった大きなきっかけの一つが、2021年末に発覚した、非常に広く使われているログ出力用OSS部品の深刻な脆弱性でした。この部品は世界中の無数のソフトウェア製品に組み込まれていましたが、多くの企業が「自社製品にこの部品が含まれているかどうか」を即座には把握できず、確認だけで長い時間を要する事態が相次ぎました。

このとき、あらかじめSBOMを整備していた組織は、対象の部品を使っているかを検索一つで確認でき、対応の初動が大きく早まりました。逆に、SBOMがなかった組織は、開発者への聞き取りやソースコードの手作業での確認から始めることになり、対応に数週間を要したケースも報告されています。

この経験を通じて、次のような認識が世界的に広がりました。

• 脆弱性は「発見されてから」対応するものであり、日頃から自社製品の構成を棚卸ししておく必要がある
• ソフトウェアのサプライチェーン（部品の調達網）は、想像以上に長く、不透明になりやすい
• 製品を使う側（調達側）にも、中身を把握する権利・必要性がある

SBOMの用途は、脆弱性対応だけにとどまりません。主な使われ方を整理すると、次のようになります。

• 脆弱性対応の迅速化——新しい脆弱性情報が公表されたとき、自社製品への影響有無を素早く判定できる
• サプライチェーンの透明性確保——自社が使っている部品の提供元・ライセンス条件を可視化し、管理する
• 調達・受入時の確認——他社から製品やソフトウェアを調達する際、中身の妥当性を確認する材料にする
• 保守・サポート体制の設計——使用中の部品のサポート終了時期（EOL/EOS）を把握し、計画的に更新する
• 規制対応・監査対応——第三者（規制当局・監査機関・取引先）への説明責任を果たす

特に医療機器ソフトウェアの分野では、一度市場に出た製品を長期間使い続けることが多く、また人の健康・安全に直結するという特性から、「今、自社の製品に何が入っているか」を継続的に把握し続けることの重要性が、他分野以上に強く求められています。

ここまで、SBOMが「何であるか」「なぜ必要か」を見てきました。次回・第2回では、「SBOMは法律上の義務なのか」という、多くの方が最も気になる疑問——日本と米国それぞれの規制上の位置づけ、薬機法の承認・認証との関係——を整理します。