SBOM（ソフトウェア部品表）とは？｜AI導入で見る所

ソフトウェアサプライチェーン攻撃は、2019年から2022年にかけて年平均で742%増えたというデータがある。経済産業省が2024年8月29日に公表した手引の冒頭に、この数字が置かれています。同じ資料は、医療機器の分野で行った実証で、部品の一覧をもとにした脆弱性の管理は手作業と比べて工数が70%程度減った、とも書いています。「AIの仕組みを一式で入れたのですが、中に何が使われているかは分かりません」「相手に部品表をくれと頼んだら、どの形式で何を出せばよいかと聞き返されました」——調達と情報システムの担当者に聞くと、詰まるのはこの二つの場所です。部品表は技術者向けの文書ではありません。出す側が作り、買う側が読み、読んだ結果で次の取引を決めるための書類です。この記事では受け取る側の立場に立って、最小の項目、深さの確かめ方、受け取って読むまでの工程、AIを載せた製品で追加して聞くこと、更新される一覧の扱いまでを順に整理します。

742%という数字が、部品の一覧という書類の話に変わるまで

経済産業省の手引は、部品表を勧める理由を最初に数字で置いています。2019年から2022年にかけて、ソフトウェアの供給の経路をたどる攻撃の年平均増加率が742%に達したという記述。運用管理の仕組みを経由した大規模な攻撃で影響を受けた企業は、平均して年間収益額の約11%の損害を被ったというデータもあるという記述。そして2021年12月に見つかった、広く使われていた部品の脆弱性が世界中に影響を及ぼしたという記述です。3つの数字が並んでいるだけなら、よくある脅威の説明で終わります。手引が続けて書いているのは、この種の事故で明暗を分けたのは防御の強さではなかったということです。

分かれたのは、影響の有無を答えるのに要した時間でした。手引は、部品表を作ることで「特定のコンポーネントの脆弱性が明らかになったとき、その脆弱性の影響を受けるコンポーネントが含まれているかを即座に認識することができ、脆弱性に対する迅速な対応を行うことができる」と書いています。逆に言えば、一覧がない状態では、答えるまでに数週間かかります。医療機器の分野の実証で工数が70%程度減ったという数字は、一覧があると仕事が速くなるという話ではなく、一覧がないと同じ仕事に3倍以上かかるという話として読むほうが正確です。

ここで注意したいのは、この数字がすべて作る側の目線で測られていることです。工数が減ったのは、部品表を作って管理した組織の工数です。外からAIの仕組みを買って入れる側は、作る工程を持ちません。だから買う側にとっての問いは「どう作るか」ではなく、「何を出させて、届いた一覧から何を判断するか」に変わります。この記事が引き受けるのはそちらです。

部品表とは何か。作る側が出す書類で、買う側は読む側にいる

手引の定義はこうです。「SBOMとは、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストである」。短い一文ですが、要点は3つ入っています。部品の一覧であること。部品どうしのつながり（依存関係）まで含むこと。そして機械が処理できる形であることです。つまり、表計算ソフトに人が手で打った部品名の一覧は、この定義からは外れます。同じ資料は、公開されているソフトウェアだけでなく、提供元が自社で書いた部分の情報も含めることができると書いています。

買う側が最初につかんでおくべきなのは、この書類の作り手と売り手が同じとは限らないことです。手引は「ソフトウェアコンポーネントに関するサプライヤーとSBOM作成者は一致することが理想的であるが、SBOMが完全に普及していない現状では必ずしも一致しない」と書いています。資料が挙げている例では、ある会社が2つの部品を使ってソフトを作り、うち片方の提供元は自社で一覧を作って渡したが、もう片方の提供元からは一覧が取れなかったので、買った側が自分で作った、という筋になっています。だから届いた一覧を見るときは、その一覧を誰が数えたのかを最初に確かめる。売り手が数えたのか、その先の提供元が数えたのか、誰かが推定で埋めたのかで、信頼の置き方が変わります。

もう一つ、頼む前に知っておくと交渉が短くなる事実があります。手引は米国の資料をもとに、部品表についてよくある誤解を並べています。「SBOMは公開しなければならない」という誤解に対しては、「SBOMを公開する必要はなく、SBOM作成者やサプライヤーの判断でSBOMの共有方法を判断することができる」。「SBOMは知的財産や企業秘密を露呈する」という誤解に対しては、「SBOMは単なる材料の一覧であり、特許やアルゴリズムのようなレシピとは異なる」。相手が渋ったときに使えるのは後者です。公開しろと言っているのではなく、自社だけに、決めた宛先に、決めた形で出してほしいと頼んでいると分ければ、話は前に進みます。

どの項目が並んでいれば読めるのか。最小の7項目

項目の中身は、国際的にほぼ一つの文書に収束しています。手引の記述では、2021年5月の米国の大統領令を受けて、同年7月に米国商務省の電気通信情報を担当する機関が「最小要素」の定義を公開しました。そこには3つのまとまりがあり、1つ目が各部品について書くべき情報、2つ目が自動処理のための様式、3つ目が運用の決めごとです。買う側が届いた一覧を突き合わせに使えるかどうかは、1つ目の7項目で決まります。

項目	書かれる内容（公表資料の説明）	買う側がその欄で判断できること
供給者名	部品を開発、定義、識別する主体の名称	誰に直させるかの宛先。提供元が消えた部品を見分ける
部品名	供給者が定めた、ソフトウェアのある単位の名称	同名の別物が混ざる余地。名前だけでは足りない理由
部品の版	部品を識別するために使う版の識別子	公表された脆弱性の対象範囲に入るかどうか
その他の一意の識別子	識別に使う、または関連する台帳の検索キーになる識別子	突き合わせを機械でやれるか、人力になるか
依存関係	ある部品が、あるソフトに含まれるという関係の情報	どこを直せば影響が消えるか。孫の部品まで見えるか
一覧の作成者	その部品の一覧を作った主体の名称	売り手が数えたのか、誰かの推定が混ざっているか
時刻	一覧のデータを作成した日付と時刻	納品された版と一覧が対応しているか

この7つのうち、買う側の手間を最も左右するのは4つ目です。公表資料の説明は「コンポーネントを識別するために使用される又は関連するデータベースの検索キーとして機能するその他の識別子」。分かりにくい書き方ですが、要は脆弱性の台帳と機械で照合するための鍵です。ここが空欄だと、部品名と版から人が当たりを付けて探すことになり、同名の別物や版の書き方の違いで漏れます。7項目のうちどれが空欄かを数えるだけで、届いた一覧が使えるかどうかは判別できます。

5つ目の依存関係も、買う側の判断に直結します。手引が示す一覧の例では、ある部品の欄に「あるソフトに含まれている」という関係が書かれ、その部品の中にさらに別の部品が含まれる関係も別の行で書かれています。この関係が入っていないと、一覧は単なる名前の羅列になります。名前の羅列でも脆弱性の有無は分かりますが、どこを直せば影響が消えるかは分かりません。直させる相手を決めるための欄が、依存関係です。

項目のほかに、運用の6つの決めごとがある

最小要素の3つ目のまとまりは、部品表を使う組織が運用の方法を定めるべき項目です。公表資料は6つを挙げています。作成の頻度、一覧の深さ、既知の未知、共有の仕方、アクセスの管理、そして誤りの許容です。項目の名前だけ見ると社内規程の話に見えますが、買う側にとってはそのまま相手への質問になります。作る側が決めていないなら、その6つは取引の中で決めるしかありません。

• どのくらいの間隔で作り直すのか。版を上げたときは作り直すのか
• どの深さまで数えたのか。直接使っている部品だけか、その部品が使う部品まで含むか
• 数え切れなかった範囲を、数え切れなかったと書いてあるか
• 誰に、どの経路で渡すのか。渡した先で誰が見られるのか
• 一覧の誤りが見つかったとき、どう直して、どう知らせるのか
• 機械が読める様式で出せるのか。出せないなら何が制約なのか

3つ目の「既知の未知」は、聞き慣れない言葉ですが実務では最も効きます。公表資料の脚注は「完全なコンポーネントの依存関係が未知である場合に、未知であるという事実を明示するということ」と説明し、依存関係の存在が不明であることの明示や、部品を特定できていない範囲の明示を例に挙げています。つまり空白を空白として書くことまでが、一覧の要件に入っている。逆に、隙のない完璧な一覧が出てきたときこそ、本当に隙がないのか、数え切れなかった範囲が黙って落ちているのかを聞く必要があります。

5つ目の「誤りの許容」も、買う側の態度を決める項目です。公表資料は「ソフトウェアサプライチェーンの管理方法は日々進化しているため、導入・運用する初期フェーズにおいて完全性が欠如する可能性がある」とした上で、「偶発的な誤りに対しては明確に許容すべきである」としています。一覧に誤りが1つ見つかったら契約を切る、という運び方は想定されていません。見つけたら直してもらい、直った一覧を受け取り直す。その往復を最初から手順に入れておくほうが、取引は続きます。なお様式については、公表資料は「機械判読可能かつ相互運用可能なフォーマットを用いて作成され、共有されること」とし、国際的な議論を通じて決められた3つの様式を使うよう求めています。買う側は様式名を覚える必要はなく、自社の道具で取り込める様式かどうかだけを先に確かめれば足ります。

深さを確かめないと、一覧は読めたことにならない

同じ「部品表あり」でも、値打ちが最も大きく変わるのが深さです。手引は、国内の実証を通じて明らかになった誤解として「対象ソフトウェアが直接利用しているコンポーネントのみSBOMの管理対象とすればよい」を挙げ、事実として「そのコンポーネントが再帰的に利用するコンポーネントについても把握しないと、脆弱性対応が不十分となる可能性がある」と書いています。そして「SBOMの深さ」の観点については有識者による議論が進行中であるとも明記しています。つまり、どこまで数えるべきかの答えは、まだ確定していません。

にもかかわらず、最低線を条文で示した例はすでにあります。欧州連合の規則2024/2847（サイバーレジリエンス法）の附属書1、第2部の第1項は、デジタルの要素を持つ製品に含まれる脆弱性と部品を特定し文書化すること、そのために広く使われ機械が読める形式で、少なくとも製品の最上位の依存関係を対象とする部品表を作成することを含む、と定めています。「少なくとも最上位の依存関係」という言い方が重要です。直接使っている部品までが最低線で、その先は求めていない。だから最上位だけの一覧が届いても、この条文の枠では不足とは言えません。

ここに買う側の落とし穴があります。最低線を満たした一覧を受け取ると、点検が済んだ気持ちになります。しかし手引が図で示しているのは、利用者が認識できる部品の範囲は狭く、深い階層で使われている部品は把握できない、という構図です。2021年12月に世界中に影響した部品の脆弱性は、まさに深い階層に潜っていた例として挙げられています。だから深さについては、相手に何段まで数えたかを言わせて、足りない段を自社のリスクで引き受けると決める。全部を要求するのではなく、どこまでで止めたかを文書に残すのが現実的な線です。

AIを載せた製品では、モデルと学習の出どころが一覧の外に残る

ここまでの7項目を、生成AIを組み込んだ製品に当ててみると、抜けが見えます。7項目はすべて、ソフトウェアの部品を数えるための欄です。モデルそのものの出どころ、学習に使ったデータの範囲、追加学習や微調整をしたかどうかを書く欄は、最小要素の7項目のどこにも用意されていません。手引の項目一覧を見ても、モデルや学習に触れる項目はありません。従来の部品表は、AIが載る前の製品を前提に組まれた枠組みだからです。

手引自身も、その外側に議論があることを書いています。誤解と事実の節に、コンテナとして固めた実行環境に対する部品表、サービスとして提供されるソフトへの部品表、クラウドのサービスに対する部品表などの議論が米国を中心に行われているが、「クラウド環境特有のSBOMの課題も挙げられている」という記述があります。外から借りたモデルを使う仕組みは、この「特有の課題」の側に入ります。手元に部品が届かず、相手の環境で動いているものを一覧にする、という別種の問題になるからです。

この穴を埋める枠組みは、部品表の様式を決めているプロジェクトの側から出ています。機械学習向けの部品表という考え方で、公式の説明は「セキュリティ、プライバシー、安全、倫理の観点のための、モデルとデータセットの透明性」。扱う対象として、データセット、モデル、設定、データセットの来歴、学習の方法、AIの枠組みの設定を挙げ、偏り、データの完全性、モデルの安全に関わるリスクを見分けるためのものだと書いています。こうした拡張が加わったのは2023年ごろとされますが、公式の紹介ページには版数が示されていないため、ここでは時期を幅で書いておきます。

買う側の実務に落とすと、通常の7項目に加えて聞くのは4つです。第一に、どのモデルを使っているか。自社で作ったものか、外から借りたものか。第二に、借りたものならその提供元と版、そして提供が止まったときにどうなるか。第三に、学習や微調整に自社が渡すデータを使うのか、使わない設定があるのか。第四に、モデルが差し替わったときに知らせが来るのか。4つのうち、様式の欄で答えが出るのは前の2つまでです。提供が止まったときの扱いと、自社データを学習に使うかは、様式の外にある取り決めです。だから聞き方も変わります。一覧に載っているかを見るのではなく、一覧に載らない部分を文書で別に出させる。この分担を先に決めておくのが要点です。

• 学習に渡したデータの来歴を自社で記録する話は、この記事の範囲外。ここでは相手に出させる書類だけを扱う
• モデルの提供が止まる時期の見方は、道具の提供終了の備えとして別に扱うほうが整理しやすい
• 生成AIを載せていても、載っているのが外部の窓口を呼ぶ機能だけなら、見るべきは呼び先の一覧と鍵の管理になる

受け取って読むまでの5工程

ここまでの材料を、動かせる順番に並べます。工程を分ける理由は、届いてから読み方を考えると、聞くべきことを聞き逃したまま受領が済んでしまうからです。頼む前に決めることと、届いてから見ることを分けておきます。

一覧を受け取ったら、最初に見る4つの欄

同じ「部品表を出せます」という返事の中に、品質の段が隠れています。手引の付録が示している可視化の枠組みは、部品表の対応の幅を6つの区分に分けています。誰が作ったか、どの依存関係まで含むか、どうやって作ったか、どの様式でどの項目を書くか、何に使うか、誰が使うか。このうち買う側が届いた一枚から読み取れるのは、前半の4つです。

特に読み分けたいのが、3つ目の「どうやって作ったか」です。枠組みが挙げている選択肢は4段になっています。構成管理の情報を人が拾って道具に載せて生成した段。道具で特定して生成し、誤検知の精査をしていない段。道具で特定して生成し、誤検知の精査をした段。そして委託元が、委託先の作った一覧を独立に検査した段です。この4段は、同じ一枚の紙の見た目からは区別できません。だから聞く。聞いた答えを、受け取りの記録に一行で書き残します。

2つ目の「どの依存関係まで」も、枠組みでは直接使う部品と、既製品などから再帰的に使われる部品の2択で整理されています。前章の深さの話が、ここで一覧の属性として現れます。この4つの欄を確かめる作業は、5分から10分で終わります。中身の突き合わせに何時間かける前に、その一覧が突き合わせに値するかを先に判定するほうが、順番として速いのです。

突き合わせた結果に出る、誤りの型

照合が終わると、脆弱性の一覧が出ます。ここで結果を鵜呑みにできない理由が、公表資料に書かれています。手引は、運用の段で認識しておくべき点として「SBOMツールが出力した脆弱性情報に誤りがあることが挙げられる」とし、実証で使った無償の道具で脆弱性の深刻度が誤って出力されたケースがあり、手作業で調べ直す必要が生じたと書いています。部品の検出そのものについても、誤検出と検出漏れが起きる可能性を明記しています。

漏れの型は、いくつか名前が付いています。実行時に動的に読み込まれる部品は、道具が実体を解析しないため特定できない、というのが一つ。この場合は、構成の情報と実行の環境を個別に用意して道具に認識させる必要がある、と手引は書いています。もう一つは、部品の提供終了です。手引は、道具を用いて部品の提供終了の時期を特定することは一般に難しく、手作業で特定することが必要になると書いています。提供終了の情報がない部品も存在するため、設計の段でそうした部品を使わないよう考慮することが望まれるとも書かれています。

• 一覧に無いことは、入っていないことの証明ではない。実行時に読み込まれる部品と、道具が対応していない言語の部品は落ちる
• 深刻度の点数が高い順に直させるという運びは、点数の誤りをそのまま順番にする
• 部品の提供終了は道具では出にくい。人が別に調べる欄を、受け取りの記録に用意する
• 出てきた脆弱性のすべてに対応する必要はない。手引も、悪用できないものや影響を受けないものが存在すると書いている

AIに任せてよい工程と、人が決める工程

部品表の仕事は、突き合わせと差分の作業が大半を占めます。だから任せられる範囲は広い。一覧と一覧を突き合わせる、前の版との差分を出す、提供終了に近い部品を抜き出す、長い一覧の傾向を要約する、届いた知らせを自社の一覧に当たるものと当たらないものに仕分ける。ここまでは、AIに下書きを作らせて人が確かめる形が向いています。作業の量が減るぶん、見落としの原因が「手が回らなかった」から「判断を委ねすぎた」に移ります。

委ねてはいけない側は、公表資料の書き方から線が引けます。優先付けに使う情報の表で、一般に公表される深刻度の点数について、手引は「一般的なケースにおける影響度及び深刻度の評価であり、ユーザー環境に基づく評価ではないため、精度は高くない」と書いています。影響の有無を機械が読める形で伝える知らせが取れない場合の独自評価についても、部品の開発主体が作るものと違って「精度が低い可能性が存在する」としています。そして節の末尾に、優先付けは評価者によって違いが生じる可能性があるため、導出の過程や前提条件、評価基準の妥当性、根拠となる証跡から検証することも推奨されると明記しています。

この記述を素直に読めば、AIの置き場所は決まります。検証される側の材料はAIに作らせてよい。検証する側の判断は人が持つ。そして材料には、必ずどの資料のどの記述から出した数字かを書かせる。根拠を書かせないと、点数の出どころが確かめられないまま順番だけが残ります。人が確認する範囲は、AIに渡す前に決めておきます。後から決めると、確認できなかった部分が確認済みの山に混ざります。

• 脆弱性の一覧をAIに渡して、対応の優先順位まで出させる。自社の業務の重みが入らないため、止まると困る機器が下に来る
• 取引を続けるかどうかの判断材料を、AIの要約だけで役員に上げる
• 一覧に載っていない部品について「他にありませんか」とAIに聞く。渡した材料の外は見えないので、ないという答えが返るだけ
• 相手から届いた説明文をAIに要約させ、原文を保管しない。後から条件を争えなくなる

危ないと見なす順番は、点数ではなく判断の枝で決まる

では順番は何で決めるのか。手引は米国の当局が示した枠組みを採り、条件分岐で構成した判断の枝を通して4区分に振り分ける方法を示しています。枝になるのは、悪用の可能性、悪用の効率、技術的な影響度、そして利用者への影響度の4つです。点数を1本の軸に並べるのではなく、枝をたどった結果として区分が決まる形になっているのが要点です。

振り分けられる先は4つです。即対応は「全てのリソースを集中し、必要に応じて組織の通常業務を停止して可能な限り迅速に対応を行う」区分。優先保守は、通常より迅速に動き、計画外の次の機会に緩和策か修復策を実施する区分。通常保守は「定期メンテナンス時に対応する」区分。対応保留は「現時点では対応しない。状況を注視する」区分です。4つのうち2つは、今すぐは動かないという判断です。全件に対応しないことを、あらかじめ区分として持っている点が実務的です。

買う側にとって効くのは、判断の基準が立場ごとに分けて示されていることです。手引は、判断の枝の基準を、役割（開発する組織か、使う組織か）と技術力（高いか、そうでないか）の組合せで4通りに分けて例示しています。使う組織の側の判断の例として挙げられているのは、該当の脆弱性が社外の通信網と社内の通信網の接点になる機器に存在すること、止まると8割以上の社員の業務が止まること、その機器の不具合が人の精神的・身体的な健康や環境に致命的な影響を及ぼす可能性があること。並べてみると分かるのは、この枝はどれも自社の事情を知らないと答えられないということです。だから枝の答えはAIに出させない。枝の答えを一度決めて表にしておけば、次からは当てはめだけになります。

入れたあと、動いている間に更新される一覧をどう扱うか

契約の段で部品表を出させても、そこで終わらない理由が公表資料に書かれています。手引は共有の節で「多くのSBOMは、コンポーネントのバージョンアップ等により作成後も動的に内容が変わることに留意する必要がある」としています。つまり納品時の一枚は、その日のスナップショットにすぎません。選定のときに見た一覧と、半年後に動いている中身は違います。だから決めるのは、次の一覧がどういうときに届くのかです。

届け方の選択肢も書かれています。製品の中から確認できるように組み込む方法、利用者が見られる置き場で公開する方法、ウェブの画面で公開する方法、共通の道具でデータを共有する方法です。ここで注意が要るのは道具の相性で、手引は「ほかのツールで生成したSBOMを取り込んで脆弱性管理等に活用することができるツールは限られている」と書いています。相手と自社が別の道具を使っていると、届いても読み込めないことがある。だから届け方は、様式と一緒に事前に協議することが望まれるとされています。改ざんへの備えとして、電子署名の技術などの活用を検討することも挙げられています。

保管については、期間の考え方まで書かれています。「社外からの問合せがあった場合等に参照できるよう、変更履歴も含めて一定期間保管する」。期間は、製品が市場に流通している間やサービスが提供されている期間を最低限としつつ、販売終了後も、保証期間、サポートの提供期間、交換部品の提供期間に応じて参照する可能性があるため備えておく必要があるとしています。部品の使用条件で製品の提供終了後3年といった個別の指定がある場合は、その期間も考慮するとも書かれています。買う側の保管も、この考え方をそのまま借りれば決まります。使い終わってからも、問い合わせが来る期間は残す。

更新を受け取る条件は、日付ではなく出来事で置くと運用が続きます。版が上がったとき、部品が入れ替わったとき、そして自社が影響を問い合わせて相手が調べ終わったとき。この3つで新しい一覧が来るように決めておけば、四半期ごとに催促する仕事が消えます。更新の宛先も、担当者名ではなく窓口の名前で決めておく。担当が変わった時点で連絡が止まるのが、この種の取り決めのいちばん多い切れ方です。

どの取引で求められ始めているのか

義務かどうかを先に知りたくなりますが、手引の書き方は慎重です。「現状のところ、SBOMの提供が義務付けられているソフトウェアは限定的である」。そのうえで、求められ始めている場面を具体的に挙げています。米国では、政府の調達の対象となるソフトウェアの提供者に対して提供を推奨している。欧州では、市場に出すデジタル製品に対する要求事項に含まれている。義務の有無は、製品と売る市場と取引の相手で変わります。だから聞き方は「必須ですか」ではなく「この取引では出せますか、いつから出せますか」になります。

欧州の枠組みは日付が決まっているので、時期の目安として使えます。規則2024/2847は2024年12月10日に発効し、欧州委員会の政策ページの記述では、主要な義務は2027年12月11日から適用され、報告の義務は2026年9月11日から適用されます。部品表の作成は、前に引いた附属書1第2部第1項の中に「少なくとも最上位の依存関係を対象とする」形で入っています。欧州に製品を出す取引先を持つ相手なら、2027年に向けて出せる体制を作る側にいるということになります。

分野で先に動いている例もあります。手引は医療機器の分野について、国際的な規制当局の集まりが出した機器のセキュリティの手引を薬機法による規制に取り入れ、本格運用する方針が示されているところ、今後、規制の中で部品表が要求される可能性もある、と書いています。断定ではなく可能性として書かれている点は、そのまま受け取っておくのが正確です。また参考資料の一覧には、ドイツの担当機関が2023年8月に初版を出し2024年1月に改定した技術指針が、部品表の様式と技術の要件を示すものとして挙げられています。

• 義務の範囲は、製品の種類と売る市場で違う。相手が国内向けだけなら、条文の話は当たらない
• 国内で一律に部品表の提供を義務づける規定は、手引の記述の時点では確認されていない
• 自社が売る側に回る取引では、同じ問いを逆から受ける。出せる範囲を先に決めておく
• 条文の適用時期は先でも、相手が体制を作る時期は今。だから今の交渉で聞ける

出す側に無理をさせない範囲の決め方

全部を最高の精度で出せと言えば、話は止まります。手引はそこを正面から書いていて、調達する側の要求は「調達者が一定の負担をするなど供給者に過剰な負担とならない仕組みが期待される」としています。さらに、重要な社会基盤の分野などで高いレベルの一覧を求める場合、供給する側はその作成にかかる費用の支払いを受けなければ事業が続かなくなる、とも書いています。つまり部品表の水準は、値段と分けて決められない。ここを分けて考えると、出せますと言った相手が続かなくなります。

決める区分	選択肢の例（公表資料の整理）	買う側が決めること
誰が作るか	提供元が自社で作る／委託先が作る／取引契約のない提供元の分は誰かが作る	契約のない範囲を、誰が埋めるか
どこまで含むか	直接使う部品まで／再帰的に使われる部品まで	自社のリスクで、何段で止めるか
どう作るか	人が拾って生成／道具で生成（精査なし）／道具で生成（精査あり）／委託元が独立に検査	精査を求めるか、費用を持つか
何を書くか	共通の様式に沿う／最小の項目を満たす／それに届かない	自社の道具で読める線を最低条件にするか
何に使うか	脆弱性の特定／深刻度の評価／悪用の可能性の評価と対処／使用条件の確認	どこまで自社でやり、どこから相手に頼むか
誰が使うか	製品の利用者／最終製品の提供元／各部品の開発者	自社が読むのか、間に立つ提供元に読ませるのか

使い方は取引の形で変わります。手引は、既製品を売買する場合は、製品に一覧と対応の範囲を添えて出すことで買う側の選別を受ける形になるとし、委託して開発する場合は、対応の範囲を委託先と協議して要求事項として合意することが考えられるとしています。既製品を買うときに交渉できるのは範囲の要求ではなく、出てきた範囲を見て入れるか入れないかの判断だということです。委託開発は逆で、範囲そのものを合意事項として書けます。同じ部品表という言葉でも、この2つは別の仕事になります。

誰が読むのか。社内の受け皿を先に決める

最後に残るのが、届いた一覧を誰が読むかです。手引は作る側の体制について、製品の安全対応を担う部門が主導するのが望ましいとし、その部門がない場合は品質管理部門で管理することが望まれるとしています。どちらもない場合は、まず特定の開発チームで道具を入れて、作成から運用までのやり方を蓄えてから横に広げる、という順番を示しています。担当を決めずに道具から入れる形は、想定されていません。

買う側の組織に置き換えると、必要な役は3つに分かれます。一覧を読んで突き合わせる役。相手に聞いて答えを引き出す役。そして影響が出たときに業務を止める判断をする役です。情報システム部門が1つ目、調達や購買が2つ目、業務を持っている部門が3つ目を担うのが自然な形になります。3つを1人に寄せると、聞く相手に遠慮が生まれて、読みが甘くなる。読む役と聞く役を分けておくほうが、質問は具体的になります。

受け皿が決まっていないときに起きる型は、はっきりしています。一覧が添付ファイルで届き、誰も開かずに保存される型。開いたが自社の道具に取り込めず、後で見ることにして忘れる型。そして脆弱性の知らせが来たときに、どの製品の一覧を見ればよいかが分からず、提供元に電話をかけ直す型です。3つとも、書類の不備ではなく受け皿の不備で起きます。だから頼む前に、届いたファイルの置き場所と、見る人の名前を決めておく。それだけで、この3つの型はほとんど消えます。

まとめ

部品表は、作る側が出す書類です。定義は「ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リスト」で、買う側はそれを受け取って読む側にいます。読めるかどうかは最小の7項目で決まり、特に識別子と依存関係が空欄だと、突き合わせは人力に落ちます。項目のほかに運用の6つの決めごとがあり、そのうち「既知の未知」——数え切れなかった範囲を明示すること——が、隙のない一覧を疑うための手がかりになります。深さについては、欧州の規則が「少なくとも最上位の依存関係」を最低線として置いていますが、どこまで数えるべきかの答えは議論が進行中と手引自身が書いています。

AIを載せた製品では、モデルと学習の出どころが7項目の外に残ります。機械学習向けの部品表という別の枠組みが動き始めていますが、現時点では、一覧に載らない4点（どのモデルか、提供元と版、自社データの学習利用、差し替えの知らせ）を別の文書で出させるほうが確実です。受け取りは5工程。頼む形を先に決め、届いた一覧の作られ方を見て、突き合わせ、読めない所を質問に変え、変更履歴つきで保管する。AIに任せるのは突き合わせと差分と抽出まで。どれを危ないと見なすかは、自社の業務がどれだけ止まるかを知っている人が決める。この分担にしておけば、部品表は提出物ではなく、次の取引を決める材料になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。