社会・産業のデジタル変革

  1. トップページ
  2. 社会・産業のデジタル変革
  3. システム／ソフトウェア開発の革新
  4. Japan Open Source Hub
  5. OSSを知る・関わる | Japan Open Source Hub
  6. 連載：OSS/DPGsの価値を経済の言葉に翻訳する（全4回）
  7. 第1回 OSSの価値はどこで見えなくなるのか

第1回 OSSの価値はどこで見えなくなるのか

公開日：2026年10月29日
執筆：木村 悦久（株式会社misto・木村悦久公認会計士事務所）

会計・資産・ライセンスから考える現在地

オープンソースソフトウェア（OSS）は、いまや社会と経済を支える「見えないインフラ」である。ところが、その価値は財務諸表にも、開示書類にも、融資審査の資料にもほとんど表れない。本シリーズでは4回にわたり、OSSあるいはデジタル公共財（DPGs）の価値が会計・金融・公共調達の言葉に乗りにくい理由を解きほぐし、価値を「経済の言葉」に翻訳するための実務的な道筋を探る。第1回は、その問題提起である。

本連載の出発点には、実務のなかで繰り返し突き当たってきた三つの問題意識がある。

第一に、OSSを主力プロダクトとするベンダー（その多くはスタートアップや中小のソフトウェア企業）は、自らの成果物が産業や行政の基盤として広く使われているにもかかわらず、その価値を説明して資金を集めることが難しい。なぜなら、成果物の多くは無償で公開されるため、既存の会計基準に当てはめると資産計上されづらい支出に該当し、財務諸表に資産計上されない以上、投資家や金融機関に対して「何を作り、どれだけの価値を生んでいるのか（または将来生む可能性が高いか）」を示す手立てが限られるからである。たとえば金融機関も、融資検討時など会社を評価する際に、財務諸表に資産計上されていないシステムに、価値があるとは判断し難い。事業としての実力と、外部から見える数字との間に、構造的な隔たりがある。

第二に、ソフトウェア開発に関する会計の枠組みが、OSSという開発形態を前提に作られていない。現行の基準は、自社利用ソフトウェアや市場販売目的のソフトウェアを念頭に整理されており、外部コミュニティと共同で開発し、成果を公開したうえで、その周辺でサービスを収益化するというベンダーの実態は必ずしも想定されていない。結果として、同じ開発活動が費用なのか資産なのかの判断が企業ごとに揺れ、開発投資の説明可能性そのものが下がってしまう。これは特定の一社の悩みではなく、OSSを取り込むあらゆる企業に共通する論点である。

第三に、「OSSの開発力は、通常のソフトウェア開発力とどこが違うのか」という問いが残る。OSSでは、自社の要求だけでコードの行き先を決められない。上流コミュニティの合意を形成し、他社の利用も前提に設計し、公開後の互換性と脆弱性に長期の責任を負う。この調整と保守の能力は、受託開発や自社プロダクト開発とは異なる種類の蓄積であり、企業の競争力の一部を確かに成している。しかし、それを測る指標も、会計や金融の言葉での表現も、いまのところ用意されていない。

以下では、この三つの問題意識に立ち返りながら、OSSの価値がどこで見えなくなるのかを順に辿っていく。

オープンソースソフトウェアと聞くと、多くの人は「無料で使えるソフトウェア」を思い浮かべるかもしれない。たしかに、OSSはインターネット上で公開され、ライセンス条件を守れば誰でも利用できる。だが、無料で手に入ることと、価値がないことは、まったく別の話である。

では、OSSの「価値」とは具体的に何を指すのか。多くは次のような形で現れる。ゼロから作るより速く確かなソフトウェアを用意できること。特定のベンダーに縛られず、不具合があれば自分たちで中身を調べて直せること。世界中の開発者が改良し続ける基盤に、自社も改良の手を加えることで、その方向性に関与し、依存先を自分たちで安定させられること。そして、その基盤が一社の所有物ではなく、産業や行政全体のデジタル化を底支えしていること。いずれも確かに存在する便益でありながら、経済活動の実務においては、請求書や固定資産台帳のような「目に見える形」を取りにくい。本シリーズが問うのは、まさにこの見えにくさである。

私たちが日々使っているスマートフォンアプリ、クラウドサービス、企業の業務システム、行政サービスの多くは、OSSを土台にして動いている。OSSは、もはや一部のエンジニアだけが扱う特殊な道具ではない。道路や水道のように、社会の中に深く入り込み、目立たないところで経済活動を支える基盤になっている。

しかし、ここに大きなねじれがある。OSSは社会や企業に大きな価値をもたらしているにもかかわらず、その価値は企業の財務諸表や開示書類の中には表れにくい。投資家や金融機関から見ても、「この企業はOSSをどのように使い、どのように育て、どのくらいの経済効果を得ているのか」は分かりにくい。OSSの価値は確かにある。だが、その価値をお金の言葉、会計の言葉、金融の言葉に翻訳する仕組みが、まだ十分に整っていないのである。OSSには利用価値、事業価値、社会価値などが存在する。しかし現代の会計や金融の仕組みは、その一部しか金銭的価値として表現できていないのではないか。

1. OSSはすでに市場の前提になっている

まず、OSSがどれほど浸透しているかをデータで確認したい。アプリケーションセキュリティ企業のBlack Duckが947の商用コードベースを監査した2026年版OSSRAレポートによれば、監査対象のコードベースの98％にOSSが含まれ、1つのアプリケーションに組み込まれるOSSコンポーネントは平均1,180個と、前年から3割増えている（注釈1）。つまり、企業が「自社開発」と呼ぶソフトウェアも、その内実は世界中の開発者が公開したOSSの組み合わせの上に成り立っている。

経済価値の推計もある。ハーバード・ビジネス・スクールの研究チームは、広く使われているOSSを一度作り直すための供給側コストを約41.5億ドルと見積もる一方、利用企業がOSSなしで同等の機能を内製した場合の需要側価値を約8.8兆ドルと推計した。OSSが存在しなければ、企業はソフトウェアに現在の約3.5倍の支出を強いられるという（注釈2）。供給コストと利用価値の間に2,000倍以上の開きが生じるのは、一度作られたOSSを無数の企業が共有して使っており、OSSがなければ各社が同等の機能を自前で開発・調達しなければならないからである。つまりこの分析は、OSSの価値が「作る側の原価」ではなく「使う側の便益」に宿ることを端的に示している。

企業が新しいサービスを作るとき、ゼロからすべてのソフトウェアを作ることはほとんどない。既存のOSSを組み合わせ、必要な部分を改良し、自社サービスに組み込む。これにより、開発期間は短くなり、コストも下がり、品質の高い仕組みを早く作ることができる。

これは料理に似ている。すべての材料を畑から育てる料理人はほとんどいない。よい素材、調味料、道具を使い、それをどう組み合わせるかで料理の価値が決まる。ソフトウェア開発でも同じである。OSSという素材があるからこそ、企業は本当に差別化すべき部分に力を使える。

ただし、料理と違って、OSSの価値は値札として見えにくい。商用ソフトウェアを購入すれば請求書が残る。設備を買えば固定資産台帳に載る。だが、OSSを利用して開発が速くなったこと、障害対応がしやすくなったこと、特定ベンダーに依存しなくなったことは、財務諸表の数字として表れにくい。価値が見えなければ、実際には企業のソフトウェアを支えているOSSプロジェクトの運用やアップストリーム（自社が利用しているOSSの開発元となる本家プロジェクト）への還元への予算もつきにくい。もとより、価値の見える化は資金供給の十分条件ではなく、企業内での会計処理（資産か費用か）と、アップストリームの保守者への資金循環は、本来は別の層の問題である。それでも、説明できない支出は、組織内で予算要求の土俵に乗りにくい。予算がつかなければ、いずれは基盤であるOSSそのものが脆くなりかねない。その根にあるのは、価値が生まれていても、それが財務や投資判断という「見える世界」に現れないことである。なお、この見えにくさの影響は一様ではない。商用サービスとして収益化されたOSSは市場で価値評価を受けやすい一方、無償の保守に支えられるコミュニティOSSや、公共財的な性格を持つソフトウェアほど、資金の細りに直結しやすい。誰もが無償で利用できる一方で保守費用を負担する主体が契約上定まらず、便益だけを受け取るフリーライド（ただ乗り）が構造的に生じやすいからである。本シリーズが主に念頭に置くのは後者である。図1は、この構造を示したものである。

  1. （注釈1）
    Black Duck Software, Inc.「2026 Open Source Security and Risk Analysis (OSSRA) Report」2026年2月公表。17業種・947の監査対象のコードベース（2024年11月〜2025年10月の監査）の分析に基づく。なお前年の2025年版では、OSSを含むコードベースの割合は97％だった。
  2. （注釈2）
    Hoffmann, M., Nagle, F. and Zhou, Y. (2024) "The Value of Open Source Software", Harvard Business School Strategy Unit Working Paper No. 24-038.

2. 企業はどこで困るのか

OSSをめぐる企業の悩みは、ライセンス違反に対する懸念やセキュリティリスクだけではない。会計、法務、開発、経営の間で、同じものを違う観点で見ていることが多い。表1は、典型的な論点を整理したものである。

表1 OSSをめぐって企業内で見方が分かれる4つの論点
観点
現場で起きる問い
なぜ難しいか
会計
OSSに関する開発費は費用なのか、資産なのか
将来の収益獲得や費用削減に結びつくか、またその確実性を説明しにくい
法務
このコードは本当に使ってよいのか
ライセンスごとに条件が異なり遵守できるか、またAI生成コードによって混入するリスクがある
開発・保守
アップストリームへのバグ修正や脆弱性対応は価値を生んでいるのか
新機能の追加とは異なり、サービス停止を防ぎ、既存価値を維持する活動は価値の創出を説明しにくい
経営 OSSへの貢献や保守に予算をつける理由は何か OSSへの貢献や保守の効果は直接数値で示すことが難しく、間接的な成果として現れるため、投資対効果を説明しにくい

 

会計の観点を少し掘り下げよう。日本基準におけるソフトウェア制作費の会計処理は、そのソフトウェアがOSSであるか、企業が独自に開発したものであるかという取得形態やライセンスの違いによって決まるものではない。ソフトウェアをどのような目的で制作し、利用するのかという制作目的によって区分される。「研究開発費等に係る会計基準」では、研究開発費に該当しないソフトウェア制作費を、受注制作のソフトウェア、市場販売目的のソフトウェア、自社利用のソフトウェアに区分している。外部から購入したソフトウェアや、第三者に委託して制作したソフトウェアについても、最終的な制作目的に応じて会計処理を判断する。

OSSを利用する場合も、この基本的な考え方は変わらない。例えば、OSSを改変したソフトウェアそのものを不特定多数の顧客に販売する場合には、市場販売目的のソフトウェアとして検討する。一方、OSSを自社の業務システムに組み込む場合や、SaaS、クラウドサービス、情報処理サービス等を提供するための基盤として自社が使用する場合には、自社利用のソフトウェアとして検討することになる。特定の顧客から依頼を受け、その顧客に納入するためにOSSを利用して開発する場合には、受注制作のソフトウェアに該当し得る。

表 2 は、ソフトウェア制作費に関する会計基準上の基本的な類型と、OSS を利用する場合の具体例を整理したものである。

表2 ソフトウェア制作費に関する会計上の基本的な類型
制作目的・活動 会計上の類型 OSSを利用する場合の例 基本的な会計処理
特定の顧客から注文を受けて制作する 受注制作のソフトウェア 顧客の情報システムをOSSを利用して開発し、顧客に納入する 受注契約に係る会計処理に従い、契約資産、仕掛品、売上原価等として処理する
不特定多数の顧客に販売する製品を制作する 市場販売目的のソフトウェア OSSを改変したパッケージソフトウェアや製品マスターを市場で販売する 研究開発費に該当する部分は発生時に費用処理し、研究開発終了後の製品マスター制作費は原則として資産計上する。機能維持のための費用は費用処理する
自社の業務で使用する 自社利用のソフトウェア OSSを改変し、会計、人事、顧客管理等の社内システムとして使用する 将来の収益獲得又は費用削減が確実である場合は資産計上し、確実でない場合又は不明な場合は費用処理する
自社が外部へサービスを提供するために使用する 自社利用のソフトウェア OSSを改変し、SaaS、クラウドサービス、検索、決済等のサービス提供基盤として使用する サービス提供による将来の収益獲得が確実である場合は資産計上する
機械や装置に組み込み、機器と一体で使用・販売する 機器組込みソフトウェア OSSを家電、産業機械、車載機器等に組み込む 機器と有機的一体として機能する場合は、原則として機械装置等の取得原価に含める
新しい知識の発見や技術的可能性の確認を目的とする 研究開発活動 新たなOSSの調査、技術検証、実験的な改変、PoC 研究開発費として発生時に費用処理する
稼働後の機能を維持する 保守・維持管理 通常のバグ修正、脆弱性対応、ライブラリ更新 原則として発生時に費用処理する。ただし、新たな機能追加や大幅な改良に当たる場合は、その実態に応じて別途判断する

市場販売目的のソフトウェアでは、最初に製品化された製品マスターが完成するまでの費用や、製品マスターの著しい改良に要した費用は、研究開発費として費用処理される。その後の機能の改良・強化に係る制作費は原則として資産計上される一方、既存機能を維持するための支出は費用処理される。

これに対し、自社利用のソフトウェアについては、その利用によって将来の収益獲得又は費用削減が確実であるかどうかが、資産計上の主要な判断基準となる。たとえば、自社の業務処理にソフトウェアを使用し、人件費の削減、処理時間の短縮、業務処理量の増加等が確実に見込まれる場合には、費用削減又は収益獲得が確実であるとして、その制作費を無形固定資産に計上する。また、企業がソフトウェアを自ら利用して第三者へサービスを提供し、その利用者から対価を得る場合も、将来の収益獲得に結び付く自社利用ソフトウェアに該当し得る。JICPAのQ&AQ15も、通信ソフトウェアの機能を利用者に提供し、利用者から収入を得る場合を、収益獲得が実現している例として挙げている。

本稿では、OSSを改変したソフトウェアそのものを製品として販売する場合ではなく、主として、企業がOSSを自社の業務システムやクラウドサービス等の提供基盤として利用する場合を念頭に置く。このため、以下では自社利用ソフトウェアに関する会計処理を中心に取り上げる。

日本基準では、自社利用ソフトウェアの制作費は「その利用により将来の収益獲得又は費用削減が確実であると認められる場合」に無形固定資産として資産計上し、確実であると認められない場合や不明な場合は費用処理するとされている（注釈3）。ここで重要なのは、OSSを利用していること自体が、資産計上を妨げるわけではないという点である。会計上問われるのは、OSSを「所有しているか」ではなく、企業が行った支出の性格と、その支出によって制作されたソフトウェアの利用から将来の収益獲得又は費用削減が確実と認められるかどうかである。

したがって、インターネット上で無償公開されているOSSを入手し、自社の業務システムやクラウドサービスで利用するために改変した場合、その改変費用は自動的に費用処理されるわけではない。改変後のソフトウェアが自社利用ソフトウェアに該当し、その利用による将来の収益獲得又は費用削減が確実であり、改変作業が当該ソフトウェアを制作するために直接必要な活動である場合には、その人件費や外注費等は制作費として資産計上の対象となり得る。

実務指針においても、外部から購入したソフトウェアを自社仕様に合わせるための付随的な修正費用は取得価額に含め、既存のソフトウェアやパッケージソフトウェアを大幅に変更して新たな自社仕様のソフトウェアを制作する場合には、将来の収益獲得又は費用削減が確実であれば、その変更費用を資産計上するものとされている。OSSは購入価額が無償である場合が多いものの、自社の従業員や外部委託先が行う改変作業には人件費や外注費が生じるため、その支出の性格を判断する必要がある。

OSSを組み込んだ開発では、実務上の判断が煩雑になりやすい。一つの開発チームの活動の中に、研究・検証、自社サービスの機能開発、既存OSSの改変、アップストリームへの貢献、バグ修正、脆弱性対応、日常的な保守といった、性格の異なる活動が混在することがあるからである。会計処理を判断するためには、それぞれ活動が研究開発、自社利用ソフトウェアの制作、機能の改良・強化、又は通常の保守・維持管理のいずれに当たるのか区分し、資産計上の対象となる制作活動について、それぞれの工数、人件費、外注費等を合理的に集計する必要がある。

たとえば、ある会社の開発者が、自社のクラウドサービスに必要な機能をOSSに追加し、OSS開発元にコントリビューションしたとする。その機能は自社サービスにも利用されるが、公開されたOSSである以上、他社も使用できる。この場合、変更内容を外部に公開したことだけを理由に、その開発費が直ちに費用処理されるわけではない。自社サービスの提供に必要なソフトウェアを制作する目的で行われ、その利用による将来の収益獲得が確実であり、当該作業がその制作活動に直接対応するのであれば、自社利用ソフトウェアの制作費として資産計上の対象となり得る。一方、特定の自社サービスの制作とは直接対応せず、一般的な技術調査、実験、開発者コミュニティとの関係構築、又は広範な利用者のための機能開発を主たる目的としている場合には、研究開発費その他の費用として処理すべき場合がある。公開されたコードを他者も利用できるという事実だけでは会計処理は決まらず、企業がその活動を行った目的、自社のソフトウェア制作との対応関係、将来便益の確実性等を踏まえて判断する必要がある。別の例もある。OSSに重大な脆弱性が見つかり、企業が多くの時間をかけて修正したとする。新しい機能を作ったわけではない。しかし、その修正をしなければサービスの停止や情報漏えいが生じ、顧客に重大な影響を与える可能性がある。このような脆弱性対応は、企業にとって重要な経済的価値を持つ。

しかし、企業に経済的価値をもたらす活動であることと、会計上、資産として計上されることは同じではない。稼働中のソフトウェアについて、現在の機能や安全性を維持するために行う通常のバグ修正、脆弱性対応、ライブラリ更新等は、原則として保守・維持管理に係る支出として、発生した期の費用となる。これは、財務諸表の読み手としては”将来”価値を生まない、”過去”の消費支出である。

これに対し、単なる機能維持を超えて、新たな機能の追加や大幅な性能向上を行い、その結果として将来の収益獲得又は費用削減が確実であると認められる場合には、新たなソフトウェアの制作又は既存ソフトウェアの改良として、資産計上の対象となる可能性がある。市場販売目的のソフトウェアについても、機能維持のための費用は資産計上しない一方、機能の改良・強化に係る制作費は、著しい改良に該当する場合を除き、原則として資産計上する整理となっている。

このように、OSSをめぐる会計上の難しさは、OSSを所有しているかどうかという一点にあるのではない。OSSを使って何を制作し、企業がどのように利用するのか、その活動が研究、制作、改良、保守又はコミュニティ活動のいずれに当たるのかを区分する必要があることにある。

また、OSSの価値のすべてが、会計上の資産として認識されるわけではない。ソースコードを検証・修正できること、特定のベンダーへの依存を避けられること、外部の開発者コミュニティから知見を得られること、アップストリームとの関係を通じて技術基盤の安定性を高められることは、企業にとって重要な価値となり得る。しかし、それらの価値が存在することと、個々の支出について資産計上要件を満たすことは別の問題である。

だからこそ、OSSを利用した開発では、開発目的、利用方法、将来の収益又は費用削減との関係、作業内容、工数及び外注費等を記録し、性格の異なる活動を区分して説明できる状態を作ることが重要になるのである。

  1. （注釈3）
    企業会計審議会「研究開発費等に係る会計基準」（1998年）および日本公認会計士協会 会計制度委員会報告第12号「研究開発費及びソフトウェアの会計処理に関する実務指針」。自社利用ソフトウェアは「将来の収益獲得又は費用削減が確実であると認められる場合」に資産計上するとされる。

3. ライセンスと「説明できるコード」：「使ってよい」だけでは語れない

会計が問うのが「いくらの価値か」だとすれば、法務が問うのは「その価値を使う権利を、自社は説明できるか」である。OSSについてもう一つ誤解されやすいのがライセンスである。OSSライセンスは、著作権を放棄するものでも、譲渡するものでもない。Open Source Initiativeが定めるオープンソースの定義に沿って、一定の条件のもとで複製、改変、再配布を認める利用許諾である（注釈4）。

要は「使ってよい。ただし条件は守ってほしい」という約束であり、著作権表示の保持やソースコードの提供など、求められる条件はライセンスごとに異なる。許諾の緩やかなMIT Licenseから、改変版にも同じ自由な利用許諾を求めるGPL（GNU General Public License）まで幅があり、OSSは「誰のものでもない」のではなく、多くの人の権利と意思の上に成り立っている。

さらに近年は、AIによるコード生成がこの問題を難しくしている。AIが出力したコードが、OSSの複製、二次的著作物に該当する程度に依拠しているか、どのライセンスの影響を受けるのか、人間がすぐに判別できない場合があると指摘されている（注釈5）。AIは開発を速くするが、出所の説明を自動的に保証するわけではない。だからこそ、企業は「動くコードかどうか」だけでなく、「説明できるコードかどうか」を見なければならない。説明できないコードは、法務リスクであると同時に、価値評価の対象にもなりにくい。

  1. （注釈4）
    Open Source Initiative「The Open Source Definition」。OSSの定義として国際的に広く参照されている。
  2. （注釈5）
    AI生成コードがGPL等の制限的ライセンスのコードを再現し、知的財産・ライセンス上のリスクを生じ得ることは、Black Duckの2026年版OSSRAレポート（参考文献［1］）でも指摘されている。なお、ソフトウェア構成分析（SCA）およびスニペットスキャナーといった自動検出ツールは存在する。

4. 見える化は、会計処理の前に必要である

この問題を解く第一歩は、いきなり新しい会計ルールを作ることではない。まず、自社がどのOSSに依存しているのか、どのOSSに貢献しているのかを見える化することである。

その必要性を世界が痛感した出来事がある。2021年12月に発覚した、Apache Log4jというOSSの脆弱性問題（通称Log4Shell）である。Log4jは、システムの動作記録（ログ）を出力するための定番ライブラリで、目立たない裏方の部品として、企業システムからクラウドサービスまで無数のソフトウェアに組み込まれていた。この一つの部品に深刻な欠陥が見つかったことで、IPAやJPCERT/CCを含む各国の当局が一斉に緊急の注意喚起を出し、世界中の企業や政府機関が対応に追われた（注釈6） 。このとき多くの組織が直面したのは、攻撃そのものより手前の問題だった。「自社のシステムのどこでLog4jを使っているのか」を、即答できなかったのである。自社ソフトウェアの「原材料表示」が存在しなかった、と言い換えてもよい。

この経験を背景に、ソフトウェアの「部品表」であるSBOM（Software Bill of Materials）の整備が国際的な政策課題になった。米国では2021年の大統領令14028が連邦政府調達におけるSBOMの活用を打ち出し（注釈7）、EUでは2024年12月に発効したサイバーレジリエンス法が、経過期間を経て2027年からデジタル製品に脆弱性管理等を義務づける（注釈8）。日本でも経済産業省が2024年8月に「SBOMの導入に関する手引 ver2.0」を公表し、脆弱性管理プロセスやSBOMに関する契約上の取り決め（要求事項、責任、コスト負担、権利等）について触れている（注釈9）。

SBOMは食品でいえば原材料表示に近い。どの部品が入っているか、どのバージョンか、どのライセンスかを把握するための道具である。ただし、SBOMだけで十分とは言えず、開発費、工数、利用目的、事業への貢献、ライセンス確認、脆弱性対応、AI利用の有無を、経理、法務、開発、経営が共有できる形にする必要がある。これは面倒な管理作業に見えるかもしれない。しかし、見えないものには予算がつかない。説明できないものには投資がつかない。OSSを持続的に使うには、まず「説明できる状態」を作る必要がある。

  1. （注釈6）
    Apache Log4jの脆弱性CVE-2021-44228（通称Log4Shell）。2021年12月の公表を受け、日本ではIPAおよびJPCERT/CCが緊急の注意喚起を発出した。経済産業省のSBOM導入手引（脚注9）も、こうしたOSSの脆弱性対応を背景として策定されている。
  2. （注釈7）
    米国大統領令14028「Improving the Nation's Cybersecurity」（2021年5月12日署名）。連邦政府へのソフトウェア納入におけるSBOM活用等を打ち出した。
  3. （注釈8）
    EUサイバーレジリエンス法（Cyber Resilience Act、Regulation (EU) 2024/2847）。2024年12月に発効し、経過期間を経て「デジタル要素を持つ製品」に脆弱性管理等の義務を課す。
  4. （注釈9）
    経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」2024年8月29日公表。

5. OSSからDPGsへ：公共財の持続可能性という問い

OSSは今や社会全体の基盤であり、デジタル公共財（Digital Public Goods、以下DPGs）として考えることができる。国際的には、国連事務総長が2020年に示した「デジタル協力のためのロードマップ」でDPGsの推進が掲げられ、その担い手であるDigital Public Goods Allianceが、オープンライセンスであること、プライバシーや法令への適合性、害を及ぼさない設計などの認定基準（DPG標準）を運用している（注釈10）。

DPGsは、公共性があるからこそ重要である。一方で、公共性があるからといって、自然に維持されるわけではない。誰かが開発し、保守し、脆弱性に対応し、利用者を支え続けなければならない。そのためには人も資金も必要である。

ここで、OSSあるいはDPGsの議論はファイナンスの問題につながる。公共性のあるソフトウェアを育てる企業があっても、開発費の支払いと公共案件の入金には時間差がある。社会的価値は高くても、現金が回らなければ開発は続かない。つまり、OSSあるいはDPGsを支えるには、技術だけでなく、資金循環の設計が必要なのである。本連載の根底には、次の仮説がある。OSSやDPGsの価値を会計・金融の言葉で評価できるようになれば、企業は貢献や保守の予算を根拠をもって確保でき、金融機関はOSSを支える事業者に融資しやすくなり、行政は調達や補助で公共財を支えやすくなる。つまり価値の見える化は、OSSプロジェクトへの資金循環の経路を太くし、個人の善意に依存しない持続可能な開発・運用体制に近づくための入口になる、という仮説である。もちろん、見える化が資金供給を自動的に保証するわけではない。だが、判断の土俵に乗らない価値には、そもそも資金が向かいようがない。

  1. （注釈10）
    Digital Public Goods Alliance「Digital Public Goods Standard」。国連事務総長の「デジタル協力のためのロードマップ」（2020年）でDPGの推進が掲げられたことを受け、認定基準を運用している。

おわりに

OSSの課題は、「無料だから会計に乗らない」という単純な話ではない。むしろ、無料に見えるからこそ、価値の説明が難しくなるのである。OSSは開発を速くし、サービスを安定させ、社会のデジタル基盤を支えている。だが、その価値のうち資産計上されていないもの（費用処理されている過去の支出）については、財務諸表や投資判断の中で見えにくい。そして、見えない価値には資金が流れにくく、資金が流れなければ基盤の持続可能性が損なわれる。逆に言えば、価値を評価できる形にすることが、この循環を逆回転させる入口になる。

次回は、この問題を国内外の具体事例から考える。Red HatやGitLabのようなOSS企業、国内企業のOSPO（オープンソースプログラムオフィス）、公共財としてのDPGsは、それぞれどのように価値を見える化しているのか。その整理から、OSS/DPGsの価値を会計や金融の言葉に翻訳するための仮説を立てる。

参考文献・出典

番号は本文の注釈番号に対応する。注釈5は補足注記のため対応する独立の文献はない。

連載トップ 第2回 OSSの価値は、海外と国内でどう見える化されているか

お問い合わせ先

IPAデジタル＆AIシステムズ・デザインセンター

  • E-mail

    dadc-infoアットマークipa.go.jp

更新履歴

  • 2026年10月29日

    公開