ソフトウェア部品表（SBOM）とは？導入・運用と国内外10事例

製品に重大な脆弱性が見つかったとき、どの機種と版が影響を受けるのか。何時間で答えられるでしょうか。

ソフトウェアを使う製品には、社内で書いたコードだけでなく、オープンソースや取引先の部品が入っています。部品の種類は多く、製品の版ごとに組み合わせも変わります。そのため、問題が起きてから構成を調べ始めると、顧客への説明や修正が遅れます。

SBOMは、こうしたソフトウェア部品を機械で読める形にした一覧です。ただし、一覧を一度作るだけでは、製品は守れません。

SBOMの価値は、部品表そのものではなく、製品、版、供給者、脆弱性、修正判断をつなぎ、出荷後も更新できる運用にあります。

本記事では、SBOMの意味、SCAやVEXとの違い、規制の動き、国内外10事例を整理します。そのうえで、どのような新規事業が考えられるか、参入前に何を確認すべきかを考えます。

ソフトウェア部品表（SBOM）とは、部品と依存関係を示す一覧

SBOMは「Software Bill of Materials」の略です。日本語では、ソフトウェア部品表と呼ばれます。

製造業の部品表を思い浮かべると分かりやすいでしょう。完成品にどの部品が入り、誰が供給し、どの型番なのかを確認する一覧です。SBOMは、そのソフトウェア版です。

一般には、次のような情報を持ちます。

• 部品やライブラリの名前
• バージョン
• 供給者や作成者
• 部品を特定する識別子
• ほかの部品との依存関係
• ライセンス
• SBOMを作成した日時と方法

データ形式では、SPDXとCycloneDXが広く使われています。表計算の一覧も人には読めますが、製品数や更新回数が増えると追いつきません。標準形式を使う理由は、取引先やツールの間で情報を渡し、脆弱性情報と自動で照合するためです。

重要なのは、SBOMが安全証明書ではないことです。部品が分かっても、その脆弱性が製品で悪用できるとは限りません。逆に、一覧にない独自コードの欠陥や設定ミスもあります。

したがって、SBOMは「危険がないことを証明する資料」ではありません。問題が見つかったとき、影響範囲を早く絞るための基礎データです。

SCA・VEXとの違いは、情報をどう使うかにある

SBOMを調べると、SCA、VEX、CVE、PSIRTという言葉も出てきます。役割が違うため、同じものとして扱わない方がよいでしょう。

SCAは、SBOMを作る方法の一つです。開発時のソースコードや設定ファイルを調べる製品もあれば、完成したファームウェアを分解する製品もあります。

VEXは、検出結果を運用へ変える情報です。たとえば、部品に脆弱性があっても、問題の機能を製品が呼び出していなければ、すぐに悪用されない場合があります。その根拠と判断を残すのがVEXです。

ツールを選ぶ前に、自社がどの問いで困っているかを決めます。「一覧を作れない」のか。「取引先から集まらない」のか。「脆弱性が多すぎて判断できない」のか。課題が違えば、必要な製品と運用も変わります。

製品セキュリティでは、出荷後の更新が本番

Webサービスでは、問題が見つかれば運営会社がサーバーを直せます。ところが、自動車、医療機器、工場設備、通信機器では、製品が顧客の手元にあります。

販売後の期間も長くなります。十年以上使われる設備もあります。販売時には安全でも、数年後に使っている部品の脆弱性が公表されることがあります。

このとき必要なのは、三つの答えです。

1. どの製品と版に、その部品が入っているか
2. その脆弱性は、実際の製品で影響するか
3. 修正、回避策、顧客への説明を誰が進めるか

SBOMは一つ目を速くします。二つ目には製品の使い方、設定、コード経路の知識が必要です。三つ目にはPSIRT、品質保証、開発、法務、営業の連携が欠かせません。

部品表を作成した時点は、運用の開始にすぎません。製品の新版、供給者の変更、保守部品、修正版に合わせて更新します。出荷した実物とSBOMがずれれば、緊急時に誤った判断をします。

この考え方は、工場設備や制御機器を扱うOTセキュリティの記事とも共通します。社内ネットワークだけでなく、長く使う製品と供給網を含めて守る必要があります。

欧州・自動車・医療機器でSBOMの実務が変わる

SBOMが注目される理由の一つは、製品セキュリティの制度が具体化していることです。ただし、業界ごとに求められる実務は同じではありません。

EUサイバーレジリエンス法は、デジタル要素を持つ製品に、設計から保守までのセキュリティを求めます。脆弱性や重大事故の報告義務は2026年9月11日から、法の本格適用は2027年12月11日からです。

自動車では、UN R155が管理の仕組みを重視します。完成車メーカーだけでなく、部品やソフトウェアの供給者から情報を集める力が問われます。

医療機器では、米国食品医薬品局のサイバーセキュリティFAQが、対象製品の申請時にSBOMを含む情報を求めています。2026年2月には、市販前申請の最終ガイダンスも更新されました。

日本では、経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」を公開しています。2024年の第2.0版では、脆弱性管理の実施事項や契約のひな形が追加されました。日本の手引は、すべての企業に一律の提出を義務付ける法律ではありません。目的と業界条件に合わせて使う実務資料です。

SBOM市場は、生成ツールから運用基盤へ広がる

SBOM市場の数字を見るときは注意が必要です。調査によって、SCAだけを数える場合、製品セキュリティ基盤まで含める場合、コンサルティングを含める場合があります。そのため、異なる調査の市場額を横に並べても、成長の大きさを正しく比べられません。

元のDeep Researchレポートを分解すると、市場は四つの層に広がっています。

1. ソースコード、バイナリ、ファームウェアから部品を見つける
2. 開発工程の中でSCAを動かし、問題のある部品を止める
3. 複数のSBOMを集め、版、VEX、規制資料を管理する
4. 自動車、医療、産業機器などの製品セキュリティ運用を支える

一つ目と二つ目には、既に多くの有力製品があります。新規参入の余地が大きいのは、三つ目と四つ目です。理由は、製品メーカーごとに供給網、保守期間、承認手続きが違うためです。

顧客が買いたいのは、きれいな部品一覧ではありません。問い合わせへ答える時間を短くすること。直すべき製品を絞ること。規制や顧客に示せる証拠を残すことです。

生成機能だけで競うと、既存SCA製品や無料ツールと比較されます。運用まで持つ事業は、導入後に顧客固有のデータと手順が蓄積します。継続収益を作りやすい一方、判断責任と支援工数も重くなります。

導入は「作る・集める・判断する・直す」の4工程

SBOM導入は、ツールの設定から始めない方が失敗を減らせます。先に、対象製品と判断の流れを決めます。

1．作る

自社開発部分は、ビルド工程でSBOMを生成します。組込み製品では、完成したファームウェアやバイナリから部品を調べる方法も必要です。

2．集める

取引先から部品情報を受け取ります。形式、必須項目、版、提出時期、機密の扱いを契約や調達条件に落とします。ファイルをメールで集めるだけでは、更新漏れや重複が起きます。

3．判断する

SBOMと脆弱性情報を照合します。ただし、深刻度が高い順にすべて直すと、開発が止まります。製品で使う機能、外部からの到達性、回避策、顧客影響を確認し、VEXや社内記録に残します。

4．直す

修正版の開発、試験、配布、顧客説明を進めます。供給者しか直せない部品では、代替部品や一時的な軽減策も考えます。新しい版へ更新したら、SBOMも更新します。

この四工程を、製品の発売後まで回します。担当部署、回答期限、承認者、顧客への通知経路を決めて初めて、SBOMが日常業務になります。

企業10社のSBOM事例から、運用の差が見える

SBOMに関わる企業は、同じ機能を提供しているわけではありません。国内外10件を、誰のどの作業を支えているかで整理しました。

事例から見える共通点は、SBOM単体を売っていないことです。導入ルール、取引先からの収集、優先順位、規制証拠、修正工程のいずれかへ接続しています。

国内事例は、ガイドラインと体制づくりから始まる

三菱総合研究所と日立ソリューションズ

三菱総合研究所は、経済産業省のSBOM実証を進めました。日立ソリューションズは、参加企業へのツール導入と手引のレビューを支援しています。

ここで重要なのは、同じツールでも業界や開発環境で使い方が変わる点です。初めてSBOMを扱う企業も参加していました。そのため、必要項目を定め、実務で使える手順へ落とす支援が必要でした。

この事例は、SBOMの初期市場ではソフトだけでなく、目的設定と運用設計が商品になることを示します。

日立建機と日立ソリューションズ

日立建機は、OSSを安全かつ効率よく使うためのガイドラインを約3カ月で策定しました。対象部署への聞き取り、現状整理、規程と手続きの設計を先に進めています。

SBOMツールを入れても、申請、承認、例外対応のルールがなければ、現場は動きません。日立建機の事例は、技術導入よりガバナンスが先に来ることを分かりやすく示しています。

積水メディカルとベリサーブ

積水メディカルは、医療機器の品質管理にSBOMを組み込みました。製造委託先からSBOMを集め、ベリサーブの「SBOM.JP」で脆弱性を照合しています。

同社は、年4回の情報連携に加え、緊急性の高い脆弱性は都度確認する運用を採用しています。新しい脆弱性があれば、品質保証部門が製品への影響を調べ、必要な対応を決めます。

ツールだけでなく、日々の監視作業を外部へ委託している点も特徴です。専門人材が足りない企業には、管理ソフトより運用サービスの方が導入しやすい場合があります。

岡山トヨタシステムサービスとサイバートラスト

岡山トヨタシステムサービスは、SBOMを生成できる脆弱性管理ツールを3カ月試した後に採用しました。選定理由には、サーバーが不要で、画面が分かりやすい点が挙げられています。

一度構成を登録すると、新しい脆弱性を画面とメールで確認できます。この事例が示すのは、高度な機能の多さより、少人数でも続けられることの重要性です。

自動車では、供給者の情報を集める力が問われる

Hyundai Motorは、Cybellumの製品セキュリティ基盤を採用しています。公開された事例では、約5カ月の試行を経て、完全なSBOM管理、OSSライセンス、バイナリ解析、脆弱性管理を評価したと説明されています。

自動車には、完成車メーカーが直接書いていないソフトウェアが大量に入ります。一次取引先の部品にも、その先のソフトウェアやOSSが含まれます。

したがって、自社の開発工程だけをスキャンしても全体は分かりません。取引先のSBOMを集め、形式と品質を確認し、車種、型式、部品番号へ結び付ける必要があります。

ここには、新規事業の余地があります。供給者が情報を出しやすい仕組み。完成車側が不足項目を返す仕組み。知的財産を見せすぎずに必要情報だけ共有する仕組みです。

ただし、プラットフォームを作れば情報が集まるわけではありません。調達条件、契約、提出期限、問い合わせ窓口まで変える必要があります。

組込み製品は、ソースコードがない部品も調べる

ONEKEYは、完成したファームウェアを解析し、部品と版を検出します。外部から受け取ったSBOMを取り込み、自動検出した結果と照らすこともできます。CycloneDXやSPDXで出力し、脆弱性判断を含むVEXにも対応しています。

この機能が向くのは、ルーター、産業機器、家電、医療機器などです。取引先からソースコードを受け取れない場合でも、出荷物に近いバイナリを確認できます。

Finite Stateも、ファームウェア、バイナリ、ソースコード、供給者SBOMを一つの製品記録にまとめます。製品の版ごとに、何が出荷されたか、どの脆弱性が関係するか、どの証拠を規制や顧客へ出せるかをつなぎます。

両社の違いを細かい機能で比べる前に、自社の証拠がどこにあるかを確認します。開発リポジトリにあるのか。完成したファームウェアしかないのか。供給者の資料として届くのか。この入口で、適した製品が変わります。

到達可能性とVEXで修正の順番を決める

部品とCVEを照合すると、多くの警告が出ます。すべてを同じ優先度で扱えば、開発者は対応しきれません。

Endor Labsは、アプリケーションから脆弱な関数までの呼び出し経路を調べます。実際に呼び出せるもの、可能性があるもの、到達しないものを分けます。これは、直す順番を決める材料になります。

Interlynkは、SBOMの生成だけでなく、取引先からの収集、品質確認、脆弱性監視、VEX、共有までを一つの流れにします。製品、環境、版、部品、脆弱性という階層で管理し、更新で情報が古くなる問題を減らします。

Anchoreは、コンテナや開発工程に近い領域が中心です。SBOMを生成・取り込みし、開発パイプラインやレジストリの脆弱性を確認します。問題のある成果物をリリース前に止める使い方ができます。

三社に共通するのは、部品を見つけるだけで終わらないことです。警告を減らし、開発者へ返し、監査や顧客説明へ使える状態までつなぎます。

SBOMの事業機会は、作成ツールの外側にある

汎用的なSBOM生成は、競争が激しい領域です。オープンソースの生成ツールもあり、大手SCA製品も機能を持っています。新規参入企業が同じ機能だけを作ると、精度、対応言語、脆弱性データ、販売力で厳しい競争になります。

一方で、企業の現場には次の空白があります。

• 取引先へ何を依頼すればよいか分からない
• 届いたSBOMの品質を確認できない
• 自社製品と部品表の版が一致しない
• 警告が多すぎて修正の順番を決められない
• 脆弱性の報告期限に合わせて社内承認を進められない
• 長期保守の製品で、修正版を出せない
• 顧客へ説明できる記録が残っていない

この空白は、単なるIT導入ではありません。調達、品質保証、開発、法務、顧客対応をまたぐ業務です。ここを標準化し、顧客ごとの違いを吸収できる事業には余地があります。

また、ソブリンクラウドの記事で扱ったデータ所在地や運用主体の論点も関係します。SBOMには、製品構成や供給者という機密情報が含まれます。保存場所、閲覧権限、外部事業者による二次利用を確認する必要があります。

自社はSBOM関連事業のどこへ入れるか

顧客接点、供給網、解析技術、運用人材から近い入口を確認します。

01　製造業の顧客と運用人材を持つ

対象製品を絞り、導入と継続運用を支援します。

• 製品版を追跡できる
• 更新と監視を続けられる
• 顧客回答の手順を作れる

02　調達・供給者との接点を持つ

取引先からSBOMを集め、品質と版を確認します。

• 必須項目を定義できる
• 機密と権限を守れる
• 不足情報を供給者へ返せる

03　脆弱性判断と規制対応に強い

VEX、承認、報告、証跡の流れを整えます。

• 到達可能性を説明できる
• 期限と責任者を決められる
• 規制専門家と連携できる

04　組込み・長期保守に強い

ファームウェアと出荷後の製品を継続管理します。

• ソースなしでも確認できる
• バックポートを追える
• 長期保守の費用を設計できる

新規事業で考えられる4つの参入方法

参入方法は、汎用ツールを一から作ることだけではありません。自社の顧客接点と専門知識に近い入口を選びます。

第一の入口は、導入と運用の代行です。製品数が少ない企業には、大規模な基盤より、対象を絞った運用サービスが合います。積水メディカルの事例に近い考え方です。

第二は、供給者との情報交換です。自動車や産業機器の取引関係を持つ企業に向きます。SBOMを集めるだけでなく、足りない項目を返し、版の不一致を知らせます。

第三は、判断と報告の流れです。EU法や顧客契約に合わせ、期限、承認、VEX、報告内容を管理します。開発、法務、顧客対応を一つの案件で動かします。

第四は、組込み製品への特化です。ファームウェア解析だけでなく、RTOS、Yocto、バックポート、保守部品の知識が差になります。業界ごとの長い製品寿命まで理解する必要があります。

製品セキュリティ事業で先に決めたい7つの懸念

1．一覧の精度を保証しすぎる

どの解析方法にも、見落としと誤検出があります。生成したSBOMが完全だと約束すると、事故時の責任が重くなります。対象、検出方法、確認できない範囲を契約と画面に示します。

2．製品版とSBOMがずれる

開発版のSBOMと、実際に出荷した製品が違う場合があります。生成の時点、ビルド番号、署名、配布記録を結び付けます。

3．警告が多すぎて運用が止まる

深刻度だけで並べると、重要でない警告に時間を使います。到達可能性、利用機能、外部公開、悪用状況、製品の重要度を加えて絞ります。

4．取引先が情報を出さない

SBOMは知的財産や供給関係を見せる可能性があります。誰に何を開示するか、必要項目だけを渡せるか、契約終了後に削除するかを決めます。

5．判断責任が曖昧になる

ツール会社は脆弱性を示せても、製品を出荷してよいかは決められません。開発、品質保証、PSIRT、経営、顧客の役割を分けます。

6．長期保守に費用が積み上がる

製品が増えるほど、版と脆弱性の監視対象も増えます。販売時の一括料金だけでは、出荷後の運用費を回収できません。保守契約、製品数、版数、対応期限を料金へ反映します。

7．規制対応を保証してしまう

SBOMがあっても、法令や認証の全要件を満たすとは限りません。法的判断、技術評価、証拠作成の責任範囲を分け、必要に応じて専門家と組みます。

セキュリティ事業は、売る前の説明が重要です。できることだけでなく、できないこと、顧客が担う判断、事故時の連絡手順まで示します。

参入・提携・待機・見送りは、運用資産で決める

自社が参入できるかは、四つの質問で判断できます。

1. 顧客の製品と版を継続して特定できるか
2. 取引先や開発部門から必要情報を集められるか
3. 脆弱性の優先順位を説明できる専門家がいるか
4. 出荷後の監視と顧客対応を続けられるか

四つがそろうなら、運用サービスや業界特化型基盤として参入を検討できます。

顧客関係はあるが解析技術がない場合は、ONEKEY、Finite State、国内SCA事業者などとの提携が現実的です。反対に、解析技術はあっても業界の販売経路と責任体制がなければ、完成品メーカーや試験会社と組みます。

顧客が「規制が気になる」と話すだけで、対象製品、担当者、予算、保守期間が決まっていない場合は待機です。まず一製品の有償診断や運用設計で、支払意思と社内体制を確認します。

見送るべきなのは、SBOMを安全証明として売る場合です。製品の実物を確認できない。判断責任者がいない。事故時の連絡もできない。この状態で事業化すると、顧客の安心ではなく誤解を増やします。

SBOMについてよくある質問

Q. SBOMとは何ですか？

A. SBOMは、製品やサービスに含まれるソフトウェア部品、版、供給者、依存関係などを機械で読める形にした一覧です。日本語ではソフトウェア部品表と呼ばれます。

Q. SBOMがあれば製品は安全ですか？

A. 安全とは限りません。SBOMは影響範囲を調べる基礎データです。独自コードの欠陥、設定ミス、悪用可能性、修正方法は別に確認する必要があります。

Q. SBOMとSCAの違いは何ですか？

A. SBOMは部品の一覧です。SCAはソースコードやバイナリを調べ、部品、脆弱性、ライセンスを分析する方法やツールを指します。SCAの結果からSBOMを作ることがあります。

Q. SPDXとCycloneDXはどちらを選べばよいですか？

A. 取引先、規制、利用ツールが受け取れる形式を優先します。どちらかの名前だけで決めず、必要な項目、版、依存関係、VEXの扱いまで小さく試してください。

Q. 中小企業にもSBOMは必要ですか？

A. 業種と取引条件によります。自社製品が欧州、自動車、医療、重要インフラの供給網に入る場合は、顧客から構成情報を求められる可能性があります。まず対象製品を一つに絞る方法が現実的です。

Q. SBOM事業へ参入するなら、どこから始めるべきですか？

A. 自社が持つ製造業の顧客、取引先網、組込み解析、規制対応、運用人材のどれが強いかを確認します。汎用生成ツールより、収集、品質確認、VEX、規制報告、長期保守の一工程へ絞る方が差を作りやすいでしょう。

まとめ｜SBOMは更新と判断の仕組みまで設計する

SBOMは、製品に含まれるソフトウェア部品を示す一覧です。しかし、一覧を一度作るだけでは、脆弱性への対応は速くなりません。

必要なのは、作る、集める、判断する、直すという四つの工程です。製品の版とSBOMを合わせ、供給者から情報を集め、VEXなどで影響を判断し、修正と顧客説明を進めます。

国内外10事例からは、事業機会が生成ツールの外側に広がっていることが分かります。特に、供給者からの収集、組込み製品の解析、修正の優先順位、規制証拠、長期運用に余地があります。

参入する企業は、機能の多さより、誰のどの判断を速くするかを決めるべきです。製品、供給網、責任者へ近い企業ほど、実務に根付くサービスを作れます。

参考文献

• 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引」
• CISA「2025 Minimum Elements for a Software Bill of Materials」
• EU Cyber Resilience Act, Regulation (EU) 2024/2847
• UNECE UN Regulation No. 155
• FDA Cybersecurity in Medical Devices FAQs
• 日立ソリューションズ「SBOM事例」
• ベリサーブ「積水メディカル株式会社様 導入事例」
• サイバートラスト「岡山トヨタシステムサービス 導入事例」
• Cybellum「Hyundai Motor Company Case Study」
• ONEKEY「SBOM management」
• Finite State「Product Security Platform」
• Endor Labs「Reachability analysis」
• Interlynk「Automated SBOM Management」
• Anchore「Security Analysis and Reporting」