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

概要

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

開催情報

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

議事次第

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

資料

議事要旨

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

オープンソース化推進に関するロードマップ（案）

  • 準備に2年かかるという記載に違和感がある。マインドを醸成し、運用をしっかり準備して、実際に開始する、という3つのフェーズが分かれているのは違和感ないが、それぞれに1年ずつかけるというのではなく進められる部分から段階的に進めるべき。すでにオープンソースで公開しているソフトウェアについては最低限必要なことから始めるべきである。OSPOに関しては、予算を立てて準備をしてから進めるのではなく、横断的な組織で有志による活動から始めることも可能ではないか。できる範囲から文化を醸成していく示し方をしたい。
  • オープンソース公開で一番コストがかかるところはコミュニティの部分だと言われている。政府向けのコミュニティの活性化と一般国民向けのコミュニティの活性化では、やり方が大きく異なる。パイロット的に公開する場合も、省庁向けパイロットと一般・国民向けパイロットと2つ生じると考えられ、それぞれの目的に応じてやることは異なるため、特にコミュニティの部分は注意が必要である。Linux Foundationの事例を見ても、コミュニティに多くのコストをかけている印象である。また、人材の部分では、「オープンソース活動の業務認定と評価反映プロセス設計に向けた整理」となっているが、認定というよりも当たり前のこととして、ジョブディスクリプションや評価制度を整備するべきである。
  • ロードマップの記載内容が全体的に重い印象であるが、他委員の言うとおり、やれることから進めていくと印象が変わってくると考える。また、資料のマトリックスという表現でのまとめ方が適切か疑問である。ルールやコミュニティなど、軸の捉え方も考え直す必要があるのではないか。
  • ルールについては、まず有志でOSPOのようなチームができて、準備段階で現状を洗い出し、ライセンス・権利、運用等をリポジトリにどのように書いていくかを、実際に公開している方と議論をしてルールを定めていく。このフェーズが完了したら100%になるという見え方ではなく、試行錯誤しながらやってみて良かったことは広がっていく、というイメージを持っている。
  • ロードマップにインナーソースの考え方を入れるのはどうか。諸外国のベストプラクティスを見ると、まずはインナーソースから始めて、良さそうであればオープンにするという流れや、政府内や公共機関内だけでインナーソースに留まっているケースも多く見受けられる。そうした段階的な進め方も選択肢として考えられるのではないか。
  • 確かに、他委員のコメントの通り、諸外国でも内部から始めるというケースはよく見られる。ロードマップに記載のフェーズもそのような意図で記載されているという前提だとすると、まずはインナーソースで始めるフェーズがあり、そこからインナーソースを広げるフェーズという流れの方が適切である。現状のロードマップのフェーズは準備期間が長い印象を受ける。庁内の運用ベースのフェーズになっているため、戦略ベースの形になると良いと感じた。
  • 一点、申し上げると、行政と民間のルールは大きく異なるため、行政の中だけでオープンにすると考えても、民間にどう落とし込んでいくか検討が必要。

デジタル庁でのオープンソース化におけるOSPOの機能・役割・フェーズ別運用

  • 難易度は高いが、オープンソース利活用を踏まえてOSPOの設計をしなければならない。資料に記載の機能については一般論として異論はないが、デジタル庁が持つべき機能についてはデジタル庁とベンダーとの関係や、どこまでを内製化するかによって大きく異なると考える。また、資料に記載されていない機能として重要と感じている機能があり、まず一つ目は「窓口機能」である。デジタル庁内や各省庁にワンストップの相談窓口を置く必要がある。二つ目は「アンテナ機能」である。戦略・ガバナンスの前提に、トレンドを収集するアンテナ機能は非常に重要である。オープンソースのコミュニティや諸外国のOSPOとの交流を通して情報を集める機能が必要であるため、明記しておくべきと考える。
  • 他委員のコメントの通り、窓口機能は重要である。「OSSのことはOSPOがすべて担当する」とならないようにしなければならない。OSPOは困ったときの相談や、ガイド役として伴走支援する役割である。全てをOSPOに任せる整理になることを懸念している。
  • OSPOの役割は、特に初期段階ではあまり重くし過ぎず、ガイドライン作成等を中心にすべき。また、モニタリングやコミュニティとの連携、情報交換など、支援的な役割にとどめたい。
  • 所属組織で社内向けのポータルを作る際のテンプレート集を作成しているが、そのような教育的資料の類はOSPOの役割になると考える。
  • 啓発活動やポータルの整備は民間企業のOSPOが有している非常に重要な役割である。また、社内向けの共有や組織内からの課題吸い上げの仕掛けも重要であり、課題の共有も実施すべきである。例えば、各OSSを利用している部門を集めて定例会を実施して課題を収集することや、Teamsのようなツールで課題を共有している事例がある。
  • 法務・コンプライアンスについては、現場に詳しい職員が少ないことが想定されるため、OSPOで内製するのか、外部に支援を求めるのか決める必要がある。OSS化の場合、権利侵害についてどこまでカバーするかが問題となり、主に著作権と特許権の問題になる。実際のソフトウェア紛争や特許紛争は非常に専門性が高く、企業でも途中で対応が困難になる。政府としてOSS化を進める以上、これを避けて通ることはできず、特に特許権の場合、公開したOSSを改変して使う過程で新たな特許権侵害が発生する可能性がある。民間であれば「非保証」で済ませることが多いですが、政府として果たしてそれでよいのかという点は慎重に考える必要がある。
  • デジタル庁はユニット制であるため、ユニットに法務担当者を配置することや、別のユニットの法務担当と協力するやり方があると感じた。専門性は非常に高く、適した人材や時間を確保することは困難だと考える。

OSS利活用推進に関するロードマップ（案）

  • OSS利活用推奨リストは民間では、社内ポータルサイトにて社内で実績のあるOSS一覧やサポートのあるOSS一覧が公開されており、各部門が参考に使用している。内部向けで使用し、例えば採点で使うとなると、利活用する民間OSS選定基準の明確化は実施するべきだが、推奨リストは用途が明確でないと意味のないリストになる可能性があり、管理が煩雑であると考える。
  • ベンダーロックインの排除を目的とすると、様々な考慮すべきパラメータが発生すると考えられる。最近では世界情勢やクラウドサービスの値上げ、突然のSaaSサービス停止など、予測が難しい事態が発生している。
  • OSS利活用の前に理解することが大事である。所属組織では、ベンダーロックインが起因の不測の事態に迅速に対応するために、OSSを正しく扱えるようにすることを推奨している。
  • OSSの利活用のロードマップは、既存のOSS推進のロードマップと重複している内容も多く、個別でロードマップとして作成する意義を再確認する必要があると感じた。
  • リファレンスアーキテクチャの作成とあるが、作成すると、OSSは決め打ちになってしまうのではないか。OSS非依存にするとリファレンスアーキテクチャが抽象的になり過ぎてしまう懸念がある。民間の場合、発注者側がOSSの選定をして業務委託するが、OSSを選定する側の選定方法によって持つべき機能が異なる。
  • ロードマップの体制やコミュニティ活性化、人材の項目について、内部でハンドリングできる人材が必要である。

「デジタル庁でのOSS利活用におけるOSPOの機能・役割・フェーズ別運用」

  • 本論点もやはり調達ルールを軸に考える必要がある。戦略的にロードマップのマトリクスを調達改革をどう進めるかを検討するフェーズとして考えるのはどうか。
  • 今は、OSS利活用をどのように広げていくか、OSPOをどのように整理するかという観点でまとめているが、調達改革として何をしていくのかという観点で整理ができると感じた。
  • 議論を分けて考えることは必要だが、最終アウトプットの形として、矢羽根（アクションポイント）をたくさん設ける必要はない。フェーズは分けない方が見やすいのではないか。
  • フルタイムのアサインを前提にしなくても良いのではないか。デジタル庁では兼務者も多く、難しいと考える。フルタイムがアサインされているからと言って、ロードマップ上のフェーズが進んだということではないので、フルタイムを強調する必要はない。
  • 雇用形態にはこだわる必要はないが、体制は兼任が多い方が良い場合もある。予算の兼ね合いもあり、規模感を示すことは参考になるかもしれない。デジタル庁の中に詳しい人材も多数在籍しているため、OSSの経験が豊富な人材を採用することも一つの案である。
  • オープンソースを安全に利用することだけのフェーズであれば、OSPOが保有すべき機能は「法務」と「コンプライアンス」で十分である。ベンダーロックインの排除やコスト削減といった目的とするのであれば、OSS利活用をリードする熱意のある相当な見識者を雇って、オープンソースのナレッジを蓄積していくイメージだと考える。また、調達時にも注意が必要で、サポート付きのものを必ず調達するというルールにしてしまうと、特定ベンダーに依存してしまう可能性もあるため見識ある人材の登用が不可欠となる。
  • リスク管理（知財や法務等）の研修カリキュラム作成・運営は重要である。OSPOを設置して法務担当者に多くの相談や質問が来てリソースが足りなくなると想定されるため、ライセンスや知的財産に関する研修を行い、原課の最低限の知識の底上げは必要である。
  • 資料2（P.31.）の法務・コンプライアンスの内容は、政府側の権利侵害についての記載のみになっているが、特許条項の内容によっては政府が特許権行使を事実上できなくなる可能性があることも精査の内容として留意するべきである。

以上