いちばん近い比喩は食品の原材料表示だと思います。

ある原材料に問題が見つかったとき、原材料表示があれば「この商品には入っている」「こちらには入っていない」と即座に切り分けられます。表示がなければ、全商品を1つずつ調べ直すことになります。

ソフトウェアも同じです。現代のソフトウェアは、自社で書いたコードよりも外部から持ってきた部品のほうがはるかに多いのが普通です。その部品にも、さらに別の部品が入っています。この入れ子構造を人間が把握するのは不可能なので、機械が読める形で記録しておこう——それがSBOMです。

第1章 おわり — 次は第2章

SBOMが注目される理由は、脅威の側の変化に対応しています。

出典：OWASP Top 10 2025、IPA『情報セキュリティ10大脅威 2026』、経済産業省「サイバーセキュリティのためのソフトウェア部品表（SBOM）の最小要素に関する国際ガイダンスに共同署名しました」（2026年7月30日）。

3行目に注目してください。EUではすでに義務です。日本の製造業がEU向けに製品を出す場合、この要求が取引条件として降りてきます。「うちは国内向けだから関係ない」で済まない構造になりつつあります。

ここまでの経緯を年表で

出典：経済産業省の発表（2026年7月30日）。日本側の署名は経済産業省および内閣官房国家サイバー統括室です。

共同署名に参加したのは、日本と米国のほか、オーストラリア、カナダ、チェコ、フランス、ドイツ、インド、イタリア、韓国、オランダ、ニュージーランド、ポーランド、スロバキアの計14か国のサイバーセキュリティ当局等です。

第2章 おわり — 次は第3章

2026年7月のガイダンスは、SBOMに最低限期待されるデータフィールドとプラクティス及びプロセスを更新したものです。経済産業省の説明では、それぞれ次の意味です。

変更の中身を整理すると、次のようになります。

出典：経済産業省の発表（2026年7月30日）に記載された更新内容。項目名は同発表の日本語表記に従いました。

この表から読み取れる方向性が3つあります。

1つめ。「誰が、何のツールで、いつ作ったか」を残す方向へ動きました。新設10項目のうち7つが、SBOM文書そのものの出所と作成環境に関するものです。SBOMの中身だけでなく、そのSBOM自体が信用できるかを判断できるようにする、という発想です。作成主体の署名が入ったのは象徴的です。

2つめ。ハッシュ値とライセンスが最小要素に入りました。ハッシュ値があれば、記載されている部品が本当にその部品なのかを検証できます。ライセンスは、脆弱性とは別の「使ってよいか」という判断に必要な情報です。

3つめ。適用範囲が明示されました。経済産業省の説明によれば、このガイダンスはオープンソースソフトウェア、AIソフトウェア及びSaaSを含む、すべてのソフトウェアに適用されるとされています。AIソフトウェアが明記されたのは、この改訂の重要な点だと思います。

第3章 おわり — 次は第4章

混同されやすい言葉を整理します。

一般的な役割の整理です。製品によって範囲は重なります。

とくにVEXは、SBOMを実務で使うと必ず必要になる考え方です。SBOMに「脆弱性のある部品が入っている」と出ても、その機能を使っていなければ影響しないことがあります。それを毎回説明するのは大変なので、影響の有無を表明する仕組みが用意されています。

第4章 おわり — 次は第5章

先に正直に書きます。ソフトウェアを作っていない個人にとって、SBOMは直接関係のない話です。個人サイトの運営者やパソコンの利用者が用意するものではありません。

ただし、個人や少人数でアプリやサービスを開発している方には関係があります。そして多くの場合、思っているよりずっと簡単に作れます。

具体的なツール名は環境によって異なるため挙げていません。利用中の言語・パッケージ管理の公式ドキュメントをご確認ください。

第5章 おわり — 次は第6章

組織でSBOMに取り組む場合、最初に読むべき資料は決まっています。経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0」（2024年8月29日公表）です。第2章で触れたとおり、この手引は2026年7月の国際ガイダンスの中で各国の事例として紹介されました。日本語で、実務向けに書かれています。

そのうえで、着手の順番を整理します。

着手の順番は筆者による整理です。組織の規模・業種によって適切な進め方は異なります。

3番が最も重要です。SBOMの価値は「持っていること」ではなく「現物と一致していること」にあります。ビルドの過程で自動生成する形にできれば、この問題は構造的に解決します。

第6章 おわり — 次は第7章

広く使われているライブラリに重大な脆弱性が見つかり、緊急の注意喚起が出た。取引先から「御社の製品は影響を受けますか」と問い合わせが来た。SBOMがあるかないかで、この先の展開がまったく変わります。

対応の流れを筆者が整理したものです。実際の所要時間は組織の規模・体制によって大きく異なります。

この表の要点は、最後の行です。SBOMは脆弱性を減らしません。減るのは「分からない時間」だけです。しかし実務では、その「分からない時間」が最も高くつきます。

第7章 おわり — 次は第8章

第8章 おわり — 最後にFAQ