オープンソース化・OSS利活用に関する有識者検討会（第3回）

最終更新日:: 2026年5月27日

概要

本検討会の概要は、オープンソース化・OSS利活用に関する有識者検討会をご覧ください。

開催情報

日時：: 令和7年（2025年）12月23日（火）11時00分から13時00分まで
場所：: オンライン（Microsoft Teams）
出席委員：: 庄司座長、今村委員、中村委員、岩原委員、関アドバイザー、外山アドバイザー、鈴木アドバイザー

議事次第

開会
座長の挨拶
議事
- 第2回有識者検討会サマリ
- オープンソース化に関する論点と仮説の共有及び議論
- OSS利活用に関する論点と仮説の共有及び議論
- 今後のスケジュール
閉会・諸連絡

資料

議事要旨

事務局から前回の検討会の振り返り、今回の検討会での論点と仮説について説明があった後、討議が行われた。各委員からの主な意見は以下のとおり。

＜デジタル庁がオープンソース化した際のOSS資産管理＞コントリビューション受け入れ

最終的にはポリシーを作るという話になると思う。Linux Foundationの開発者リーナス氏の発言で参考になる部分を以下の通り抜粋する。
- メンテナンスにAIツールを活用。（トリアージにAIを活用できるのではないか。）
- リグレッションを起こさず後方互換性を維持する運用ルール。（インターフェースで解決する。そのために多少複雑化しても安易なリファクタリングに手を出さないことが重要ではないか。）
- 安易に要求に応えない。（あらかじめ期待値を下げておく。）
一般的なオープンソースでは、コントリビューションは基本的に誰でも受け入れられる。ただし、受け入れポリシーはコミュニティで定められており、メンテナーが審査するため、ポリシーに準じた審査を実施が可能なメンテナーを設けることが重要である。ポリシーは一般的なソフトエンジニアリングと同様にバージョンアップの頻度や破壊的変更のタイミングなど、ロードマップを明確にする必要がある。デジタル庁の場合、これらの役割を理解した人材を雇用する必要がある。
コントリビューション受け入れについて、非常に難しいテーマだと考える。コントリビューションマークダウンを用意しプロセスを決めておくことや、どのようなサイクルで反映させていくか明示するということが考えられる。しかし、ポリシーとして書くとなると、どのレベルでルールを決めるかは開発チームやプロダクトの性質にもよるため難しい。反映のプロセスや貢献のルール等を明示する等抽象度の高いオーバービューのような形にならざるを得ない。今後レビューやAIを使うことが一般的になると想定され、敢えてポリシーとして書く必要はないのではないか。ポリシーではなく、プラクティスが共有され、文化をつくっていくことが重要。
考慮すべき整理事項として、オープンソースの場合、受付範囲を絞り込むのが難しい。インナーソースであればあり得るが、GitHubの仕組み上限定した人からのプルリクエストの受け取りはできないのではないか。オープンにするか、プルリクエストは受け付けないかのどちらかだと考える。
文化づくりが重要であり、リーナス氏もカルチャーをつくることを語っていた。例として、LTSのリリース時期を明言せず、コミュニティであれば理解できるだろうという文化がある。また、既にある機能は触らないという方針も有効であると感じる。
セキュリティホールなどが発生した場合、元のソフトウェアに修正がなされることで、善意であっても当初は抵触しなかった第三者の特許権を侵害する可能性がある。なんらかの修正を行う場合の特許権侵害チェック体制を設けた方が良いのではないか。国が無保証で法的責任を負わないことは問題ないが、国の信頼性の確保の点から法的な義務を超えたものが必要だと考える。
実務の観点で考えると、特許権侵害のチェック可能かどうかが課題である。

＜デジタル庁がオープンソース化した際のOSS資産管理＞脆弱性対応

メンテナーについて、一般的なコミュニティでは暗黙的な文化が存在する。大きなパッチはNG、破壊的変更はメジャーバージョンアップの場合のみ（ロードマップのポリシーはコミュニティによって違う）、テストコードを必ずつける等、このあたりを理解したメンテナー陣を確保するのが必須である。
依存ライブラリに脆弱性が発見されるパターンと、オープンソース（プロダクト）自体に脆弱性があると報告されるパターンと２つのパターンがある。前者であれば、慣れた人材が対応することができるが、プロダクト自体にCVEがついたら深刻な事態になる。
ライブラリに脆弱性が見つかった場合は、オープンソースに限らず、既存の組織での対応プロセスが存在するはずなので、OSSであってもそのプロセスに従う。OSS側からCSIRTへ連絡できる窓口を整理しておく必要があり、CSIRTがSBOMを管理することが理想である。また、OSS自体に脆弱性が見つかった場合は、イシューで報告されると脆弱性が明るみに出てしまうため、メールアドレス等の窓口に報告をしてもらうという流れが適切であると考える。脆弱性に関しては、公開時にセキュリティマークダウンを用意し、連絡窓口を明示するのが望ましい。
脆弱性対応については、コミュニティは無保証のため、基本的に自由であるが、多くの人に使ってもらうオープンソースや、道義的責任が問われる場合は、脆弱性の受付や開示についての対応プロセスを定める必要があるためオープンSSFという組織が公開しているベストプラクティスを参考にしてもらいたい。
＜https://www.bestpractices.dev/ja＞
OSSは、様々な人が自由に追加や変更を行うことができ、最初は問題がなくても、変更を続ける中で他者の特許権の侵害の構成要件を充足してしまうような法的脆弱性も存在する。自分でOSSを改変したい人が、全ての特許リスクを把握できないまま開発を進め、結果的にトラブルに巻き込まれるのは避けたいものであるが、それではOSS利活用が進まない。例えば、国がOSS化した際や利用促進の段階で、関連ソースコードの危険な部分や構成要件の充足率をリスト化し、注意喚起する仕組みが有効かもしれない。
ライセンス違反疑いがSNSで話題になり、先に拡散されてしまう現象が起こっている。報告する専用の窓口が必要であり、窓口についてはAIチャットでも問題ないと考える。
報告してもらえること自体は悪いことではなく、報告の心理的負担が上がることは良くない。報告に対しうまく対応できる方法は持っておく必要がある。
迅速に対応するのは難しいが、放置してしまうことで評判上のリスクもある。対応の体制と反応の仕方が焦点になる。
迅速に対応するのが難しいかどうかは案件による。現在進行形でベンダーに委託して開発している場合は、チケット優先度を上げて迅速に対応してもらう等、場合分けして考える必要がある。
研究開発、学術系等のすでに手の離れたものの場合等と区別して考える必要がある。
窓口が存在することが必要である。加えて、すべての案件に対応することは人的リソースの関係上不可能であるため、AIチャット等も活用可能。
修正が迅速になされるかの問題ではなく、報告自体が組織に届いているのを見える化することが重要。

＜デジタル庁がオープンソース化した際のOSS資産管理＞不具合対応

オープンソースの一般論として、不具合の管理や報告はGitHubのイシューで対応していることが多い。イシューを報告する際にもルールが定められており、バグの場合は、再現方法まで記載することが求められている。不具合の重大度の判定は雇われているメンテナーが実施するのか、承認はだれが実施するのか、ベンダーメンテナーとOSPOメンテナーとで分かれるのか、その辺りのガバナンスも事前に考える必要がある。その際、OSPO側にも技術面に明るい人材を雇うことが前提となる。
軽微な不具合であれば、ユーザーが改修する場合やバグ報告とパッチが一緒に届くことがある。通常のコミュニティでは、優先度の基準はある程度あるものの、あくまでボランティアの集合体であるため、メンテナーの気が向いた順に対応していくことが多い。
OSPOが資料に記載の事項をすべて請け負うためには、専門的な知識と多くのリソースを割かねばならないと感じた。しかし、行政としてOSPOに多くのリソースを割くことは困難であり、横串の横断チームのようなイメージで、人材を少しずつ集めて兼務で進めていくことが想定される。公開している全てのOSSに対するオーダーのイシュー等の判定をしていくことは現実的には難しいと考える。現場で対応したものを上手くいっているのかOSPOがチェックをする程度でないと対応しきれないのではないか。
修正方針決定の重大度の判定はAIを活用できるのではないか。また、報告はフォーマット化し再現方法を記載することでAIが一定程度対応できるのではないか。
OSPOはどのレベルが重大なのかを決めるくらいが無難である。
一般的にOSPOは開発には関与せず、方針を示す程度にとどめている。実際のコミュニティ運営は、運営チームが担うべき。ベンダーにコミュニティの運営を委ねる場合、開発量の予測が困難なため、どのように発注するのかについても課題となる。
コミュニティを委託することの困難さについての論文があるため、Webサイトのリンクを共有する。
＜https://www.jstage.jst.go.jp/article/aaostrans/12/2/12_2023-005/_pdf/-char/ja＞
発注の事例として、Linux Foundationのあるプロジェクトでは、メンバーから集めたお金でメンテナーを雇っているという事例がある。メンテナーを雇うことは様々な団体が行っており、契約形態は準委任契約である。
いくつかのパターンがあると考える。アジャイル契約ができるようになることで柔軟に対応できるようになる可能性がある。重要なのは、組織内部に判断可能な専門家を配置し、ベンダーへ適切な指示を出せる体制を構築することである。プロジェクトの成熟度に応じて進め方を柔軟に変化させる必要があるが、期待値コントロールはしっかりやるべきである。
優先度や判断基準が不明確だと、対応漏れやリスクの増大につながりやすいため、誰が対応するかをはっきりさせることが推奨される。ただし、それも実際には事例を積み重ね、状況ごとに分けて考える必要がありそうである。
修正パッチの管理をする必要性について議論を深めたい。インシデント管理システムをそのために開発することは負担が大きく避けたい。クリティカルなものは、他のチームに共有するためにも意義があるとは考える。
GitHubの使い方次第で、システムを新たに開発する必要はないと考える。クリティカルなものを修正した場合は迅速にリリースするが、細かいバグを修正した場合は一定程度まとめてリリースするなどのポリシー決めが必要である。
Howを書きすぎない方がいいと考える。なぜこれをやるか、ということが分かるように明記することが大事なので、GitHubでラベル付けの条件をOSPOが決めて各チームがそれを順守することなどをベストプラクティスとして掲載するようにしてはどうか。
修正したものは過去を辿れるようにしていれば、問題ないのではないか。

＜デジタル庁がOSSを利活用する際の調達要件＞調達時のOSSライセンス指針

透明性について、何かを検証するためのシステムの場合、検証可能性がないと本当に検証できているか分からないという問題がある。例えば昨今偽情報、誤情報の問題が顕著であるが、偽情報だと判断しているアルゴリズムが本当に判断できているのかというのは透明性が求められる。アルゴリズム自体を検証可能にしておくことが望ましい。
システム自体がどんな部品で成り立っているのかというのは公開するべきである。
公開性・透明性を重視するシステムは、オープンソースを使う以前に、初めからデジタル庁OSSになっているのではないか。また、個人情報を扱うシステムについては、設計を確認し、便利なオープンソースの機能やライセンスも検討する必要がある。たとえGPLライセンスであっても、便利且つ伝播範囲が限定されるなら、柔軟に対応することが重要である。
「個人情報を取り扱うシステムでは、コピーレフト型の場合リスクが高まる可能性」というのは、元のシステムは公開されている中で、ソースコード内に個人情報が含まれる形で改変することは考えにくいため、必要のない事項だと考える。
システムが1つで完結している場合ではなく、寄せ集めでできている場合、デジタル庁が開発してリリースしたシステムの中に、外部の開発者の技術が入っていて、それが他者の権利を侵害した技術であったとする。その場合、デジタル庁が開発した技術自体は、他者の権利を侵害したままになってしまうのではないかという懸念がある。
OSSであるか否かに関係なく、通常の調達の時でもライセンス違反はしてはならないため、OSSであることで特別なリスクは生じることはない。
他社の権利侵害という観点からはこれまでのシステム調達の契約において定められている。どのようなライセンスを選ぶべきかについては、OSSかどうかに関係なく公開予定ではないソフトウェアにGPLは使ってはならない。それ以外に避けるべきものはないのではないか。
ソフトウェア開発の範疇あるいは責務については、本検討会では議論するべきではないと考えるがどうか。オープンソースに関する観点は非常に多様にあるため、議論が発散してしまう。
再配布は考慮せず、利用関係のみに絞ると、資料上のパーミッシブ型にはMITもApacheも混在している。他者の権利＝特許権のことだと思慮するが、OSSの中でも特許権に関して規定のあるものとないものがあり、規定のされ方も様々で曖昧なものもある。国がどの程度、他国の企業に対して特許権を行使する可能性があるのかを踏まえ、特許権行使について制限がないものを採用するかどうか等検討する必要がある。
デジタル庁内で内製開発においてOSSを活用した時どのようにチェックしていけばいいのかという懸念がある。
ライセンスについての意識を持ってもらう等の教育もOSPOの役割になるのだと考える。
デジタル庁の内製開発でOSSを活用した場合に、修正を加えた時に他者の特許権を侵害することに留意する必要がある。

＜デジタル庁がOSSを利活用する際の調達要件＞調達仕様書にて評価項目とすべき要件

OSSを使って調達する際、公平性の観点から特定のOSSを指定して仕様書に明記することは望ましくないため、あらかじめOSSを決めることは難しい。そのためコミュニティへの貢献実績等も具体的に書きづらい問題がある。OSSに関連した認定証等の提出を要件とすることは可能である。実務面では、ベンダーがプルリクエストに対応した場合にその部分は瑕疵担保要件から外れるという事例があり、調達だけでなく契約周りの話にも関わってくる。
オープンソースの決め打ちは難しいため、加点評価できるとすれば、入札要件にオープンソース利用が入っている場合や、応札者がオープンソース利用を提案する際にアピールポイントになることが想定されるが、加点評価するかは評価者の知見が問われることになる。また管理体制に関しては、ISO規格のOpenchain等を利用し、チェックリストによる自己認証を取得することで最低限の体制は確保できる。さらに、保守・運用能力については、実際の技術力と予算的制約の間で大きな乖離が生じる可能性があり、十分な予算が確保されれば対応可能なケースもあり、予算次第ではオープンソースのメンテナーの即時対応は難しく、案件ごとの優先順位に影響する。そのため、記載方法や評価手法には注意が必要である。
＜https://openchainproject.org/checklist-iso-5230-2020＞
法的リスクのチェック能力の有無や程度を要件とする必要があるのではないか。契約書で担保責任について定めても、実際にその能力がないベンダーであれば意味がない。法的なチェック体制を備えているベンダーは少数であり、これまでの実績や、法的チェック体制について確認・評価する、あるいは価格に反映させることが必要である。もしその能力がなければ、国側でも法的チェック体制を整備する必要となるが、しっかりしていれば国側の負担を軽減できるという目安になる。
行政の現状として、法的チェックを事業者に任せている部分も多く実際にチェックできているかを確認するための知見も不足している。国としてプロダクトを立ち上げる場合には、法的チェック体制に係る基準を作ることも必要だと考える。
法的な面で判断できる人材の確保は重要だが、特許権の範囲判断は弁護士でも理解している方が少なく、発注に頼るとコスト増になるため、例えば特許庁から知見のある方に出向してもらうことも一案ではないか。また、現場の知識の向上を目的とし、研修等を実施し、問題意識を共有できる体制づくりも必要であると考える。

＜デジタル庁がOSSを利活用する際の調達要件＞SBOMの整理

ダウンロードしたオープンソースを管理するシステムが必要であるため、それがあることを前提として考えるべきである。CVE情報は後から増えることもあるため、そのような変わる情報はSBOMに含めないことが望ましい。パッケージURLをSBOMに含め、デジタル庁でCVEを引いてくるという手法を取ればよい。
運用を踏まえて無理のない要件設定をしないとSBOMをDVDで提出されても実務上意味がないので、GitHubにリポジトリがあってSBOMが更新される仕組みがあり、脆弱性が発見された際にすぐに調査できることが理想である。仮説の方向性は合っているが、OSPOやCSIRTの運用を整理してから要件を検討するべきである。
ファイル形式は機械可読性であることは必須であり、自動更新に対応できることが重要である。
ロードマップという観点では、SBOMをどのように運用していくのかが重要になる。

以上