渡邊歩（以下、渡邊）：集めたり分析したりするところにSBOMを使えるという話で、お二方とも独自のフォーマットでやっていますというお話があったかと思います。ただ巷では、会社間でSBOMを流通させるためにフォーマットを共通化していこうという動きが生まれています。

渡邊：ということで、今回ちょっと皆様にご協力をいただきまして、アンケート、というか投票をやらせていただきたいと思います。

皆様に伺いたいこととして、設問が2点ございます。1問目が、「聞いたことがあるSBOMフォーマットを教えてください」、そして２問目が「その中でどれが今後流行ってくると思いますか（予想で）」というものです。

（セミナー視聴者に投票BOXが表示される）

ご存知ない方のために「聞いたことがあるもの」について補足したいと思います。まず上から、SPDX（Software Package Data eXchange）。こちらはつい最近ISO/IEC 5962というバージョンでISO化されたSBOMのフォーマットになります。

次のCycloneDX。こちらも同じくSBOMのフォーマットになるんですけれども、xmlとかjsonとかの形式で書けるものです。コアメンバーにOWASPの方が入っていらして、結構セキュリティ寄りなのかなというイメージがあります。

3つ目のSWID（Software Identification Tags）。海外の方が「スウィッド」っていうふうに呼ばれていると最近初めて知ったんですけれども、SWIDですね。xmlのフォーマットでちょっと古いんですけど、ISO/IEC 19770-2というものでISO化されている標準になります。

ということで、この中で聞いたことがあるもの、それからどれが今後流行ってくると思うかについて聞いてみたいと思います。

渡邊：（参加者が投票を実施）……はい、みなさんご回答いただけましたでしょうか？ちなみにこれ、米嶋さんと北村さんそれぞれいかがですか。たぶん聞いたことあると思うんですけど、どれが流行ると思いますか？個人的に何かありますか？

米嶋大志氏（以下、米嶋）：ええ、難しいですね。もちろん情報としてはすべて知っているんですけれども、流行ると思うのは、勢いを感じるのはやっぱりSPDXですかね。

渡邊：なるほど。北村さんいかがですか？どれが流行ると思います？

北村充宏氏（以下、北村）：そうですね。SPDX、CycloneDX、SWIDそれぞれ聞いたことがありますが、SPDXの方は富士通もOpenChainに参加していますのでなじみがあります。米嶋さんと同じで、やはりSPDXかなと個人的に思っています。

渡邊：はい、ありがとうございます。では投票を締め切らせていただきまして、結果の方お願いします。

はい、じゃーん！ということで、まず聞いたことのあるSBOMフォーマットについて、かなりSPDXは有名なんですね。93%の方がSPDXを知っていて、その後CycloneDX、SWIDが同じぐらいで30%という感じですかね。

設問2番「どれが流行ってくると思いますか？」 に関しては、圧倒的にやはりSPDXが多いという感じですね。日本の会社さんに聞くとSPDXが多いかなという気が私もします。あと今日、パネリストさんお2人と私とでOpenChainつながりのところもあって、OpenChainはみんなでSPDX頑張って翻訳したりしているので、個人的な思い入れがSPDXにはありますね。もしかしたらご聴講の皆様もOpenChainつながりでSPDXを推していただいているのかもしれないですけど。はい、ありがとうございます。なかなか面白い結果が出たなと思います。

渡邊：では、SBOMフォーマットに関するお話が続くんですけれども、今社内で使われているフォーマットがありつつも共通フォーマットが出てくることに関して、ネガティブな想いとポジティブな想いとがそれぞれあるかと思うんですけど、まず米嶋さん、この共通フォーマットについてどんな想いでいらっしゃいますか？

米嶋：はい、まず乗らなければいけないという想いが私、というか会社としてはあります。どれが流行るかなんてわからないので、逆に言えばどのフォーマットが流行ってもいいように社内で進めるというのがうちの方針ですね。なので、そういった方針のもと対応を進めています。

渡邊：なるほど。やはり「乗らないと」という感覚はあるんですね。お取引先から「SBOMをこの形式でくださいね」とか、逆にお取引先に対して「（同じように）くださいね」とおっしゃることもあるかと思うんですけれども、そういうときに個別フォーマットじゃなくて共通のものがあると貯めやすいし、分析しやすいというのもあるんですかね。

米嶋：はい、そうですね。まず、我々は知っていて当たり前なんですけれども、営業や調達部門が「SBOMって何？」とならないように、OSS推進部門としてはそういった部門の社員に対しても、認知させる取り組みを進めていかなければいけないと思っています。

渡邊：なるほど、（技術者だけでなく）直接相手方さんとやり取りする方もこういうことを知っておかなきゃいけないというところなんですね。ありがとうございます。富士通さんいかがでしょう？この共通フォーマットに対して、やっぱり「乗らないと」という感覚を同じくお持ちですか？

北村：そうですね。その感覚はあります。SBOMがちゃんと流通することによって安心して外からもらったものを利用できるとか、流通してきたSBOMを活用してその後の調査を省けるとか、効率的になるという点では結構メリットになるんじゃないかと思っています。

ただ、なかなか一つに統一されることは難しく複数乱立することになり、情報の共通化という点では困難な道のりなのかなと個人的には思います。

渡邊：ありがとうございます。「効率的に」というのが、やっぱり共通フォーマットで一番大事にしてほしいところかなという気がしますよね。誰かからもらったものに対して、また自分がアドオンして、さらに別の方に配布していくっていう一連のサプライチェーンがある中で、もらったものと自分が入れ込むものとでまた出していくものがうまく簡単にマージできたりするようなところだったり。あとチェックを二重にやらなくてもよくなるとか、そういうサプライチェーン全体で共通化することによるメリットというのを考えていきたいところですかね。どうもありがとうございます。

パネリストの皆様から興味深いお話をたくさん伺っているところではありますが、このあたりでそろそろ後半ということで、ご聴講の皆様からのご質問にお答えいただく時間になってきました。皆様、ご質問の投稿はお済みでしょうか？まだの方、まだ間に合いますので、ぜひQ&Aの機能からご質問のご投稿をお願いいたします。

渡邊：皆様からご質問をたくさんいただいております。どうもありがとうございます。非常にたくさんいただきましたので、ちょっと時間内に答え切れるか自信がないんですけれども、なるべく多くのご質問に答えていきたいと思います。

まず一問目ですね。「利用者の要望にすべて応じていると、BOMに不足する要素が増えすぎて、後でかえってわかりづらいものになりがちだと思います。どのようにユーザビリティを保ちながら、利用者要望に応えているのですか？」というご質問です。米嶋さん、まずお願いできますでしょうか？ユーザビリティを保ちながらというところ。

米嶋：はい。保てているかどうか、うちも不安なんですけど（笑）。要望として複数回挙がったものに対しては取り込んでいます。定期的に内部でも見直しをしているので、その中で出た「削っていいんじゃないか」とか「同じようなことを実は聞いているんじゃないか」とか、そういった点をチェックして、我々としては保っているつもりです。

どのようにユーザビリティを保ちながら要望に答えるかというところでは、先ほどのSPDXだとか、CycloneDXだとか、ああいったところが「もう一般的に普及しているフォーマットだ」というふうに言い張って、それを盾に我々は「この要素を変えない」みたいな考え方で社内に対してBOMの設定をするというのも、ある意味ひとつの手なのかなというふうに思います。

渡邊：なるほど、「標準です」と言い張る作戦ですね。ありがとうございます。では北村さん、同じご質問いかがでしょう？ユーザビリティの観点。

北村：はい、そうですね。必要なものを最低限というのは、昔から変わらないところだと思います。ただ、会社だったり部門だったりが、その時の旬なテーマにしたがって追加削除していくことが大事かなと思います。

渡邊：ありがとうございます。加えるけど減らすものもあるというところや、トレンドとか、今大事だと思うところ。なるほど、ありがとうございます。

渡邊：では、次の質問にいきたいと思います。「過去に開発した製品にどのようなOSSが含まれているかを調査する場合、何階層まで調べるべきかなど、社内で基準を定めていますでしょうか？」というご質問です。米嶋さんいかがでしょうか？調べるときは何階層までか、基準はありますか？

米嶋：社内で集めたSBOM相当の情報というのはRedmineを使って文字列検索できるようになっていますので、改めて過去どういうOSSがどのプロジェクトで使われていたとかというのは調べられるようになっています。

渡邊：多分これ、ライブラリの入れ子構造に関するお話なのかなと思いました。あるOSSが内包しているライブラリがまた別のOSSだったり、さらにそれが別のOSSを使ってたりとか、そういう入れ子構造になっているようなケースに何階層まで調べるとか、そういうルールはありますか？

米嶋：その点ですと、基準を設けて「こういう粒度で書いてください」というようなことはしていません。ただ、依存ライブラリまで含めてしまうとキリがないですし、大体セキュリティの脆弱性が出ている粒度というのは、パッケージの所までは及ばないので、その前段の包含をしているOSSの単位で書いてもらうというようなことは、プロジェクトには言っています。中にはいるんですよね、パッケージリスト全部出してきて、全部書くみたいな。どうしようもないので、そんなことをされても。なので、OSSとしてどれを使っているかというのは、そのような粒度で社内には展開しています。

渡邊：ありがとうございます。北村さんも同じご質問いかがでしょう。

北村：そうですね、富士通としても特に何階層かの指定はありません。配下の階層は部門の中で管理ができる単位で調べてもらっています。

渡邊：時間的にあと1～2問な気がしますので、今日のテーマに即したところのご質問にいきたいと思います。「SBOMは共通フォーマットで改変を繰り返してきたとのことですが、ツールを使って管理されているのでしょうか？それともExcelのようなドキュメントとして管理されているのでしょうか？分析するために工夫していることがあれば、教えていただけないでしょうか。」というご質問です。米嶋さん、いかがでしょう？

米嶋：弊社はExcelを使ってます。万能ツールだと思います。工夫しているところは、ファイルの中に入っている文字列なので、それをあとで検索できるように検索用途としてテキストを外部に出して、そのチケットに紐づけるという工夫はしています。

渡邊：なるほど、ありがとうございます。これ富士通さんの中ではいかがでしょう？

北村：そうですね。出荷の時のチェックは我々もExcelを使っています。他に、ツール上にBOM情報を蓄積しているところもあります。

渡邊：なるほど、ありがとうございます。Excel万能説出てきましたね（笑）。ありがとうございます。

この他にも非常にたくさんのご質問をいただいているんですけれども、残念ながら時間の関係ですべてお答えすることができませんでした。申し訳ございません。ご質問いただきました皆様、どうもありがとうございました。

渡邊：それでは、そろそろクロージングの時間になってきましたので、最後の質問としてパネリストの方に、SBOMの活用が将来的にどうなっていくのかについて、お考えなどを一言ずついただければと思います。まず米嶋さんお願いします。

米嶋：はい。先ほども同じようなことを言いましたけれども、社内でも非常に関心の高いテーマで、国内・海外でも重要なキーワードになるというのは間違いないことだと思います。我々としても、引き続きこういったところでの情報収集ですとか、戦略への取り組みというところは続けていきたいと思っています。

米嶋：私も今、こうやって喋っていますけど、聴く側としても情報収集を続けていかなければなというふうに思っています。すごい、鮮度が大事な情報だと思いますので。

渡邊：そうですね。この後情報をウォッチしたいなと思っている方に対して「こういうところを見ておくといいよ」というアドバイスはございますか？

米嶋：OpenChainでしょうね。もしくは国内の行政機関が出しているレポートですとか、そういったところをウォッチするべきだと思います。

渡邊：はい、ありがとうございます。では同じ質問を北村さん、お願いします。

北村：はい。SBOMは今後切っては切れないものになると考えています。将来的にはSBOMが普通に流通される世の中になっていくと感じています。

渡邊：なるほど。今後絶対に必要な要素というところで、もう切っても切り離せないようになっていくんですかね。ソフトウェアの流通と一緒にこのSBOMがくっついて流通して、情報のtransparency（透明性）が保たれる、そんなソフトウェアサプライチェーンになっていくといいなというところですね。

それでは、時間が残り少なくなってきましたので、この質問を最後にこのパネルディスカッションを終わりにしたいと思います。本日はNECの米嶋さん、富士通の北村さんにパネリストとしてご登壇いただき、お話をいただきました。お二方、どうもありがとうございました。

米嶋：ありがとうございました。

北村：ありがとうございました。

渡邊：はい、最後に、ご聴講の皆様、3日間お付き合いいただきまして、本当にありがとうございました。非常にいろいろなお話をお届けできる機会を作れたというところも、こちらとしてはすごくやりがいがあったセミナーでした。またこういった機会を作って、皆様に情報をお届けできればなと思っておりますので、またぜひご参加いただければ幸いです。

それでは以上を持ちまして、3日間のセミナーを終了とさせていただきます。ご聴講いただきまして、どうもありがとうございました。