第4回 最終回 OSS/DPGsの価値を、どう経済の言葉に翻訳するか

事例から導く実務フレーム

結論はシンプルである。OSS/DPGsの価値は、自然には見えない。だからこそ、記録し、整理し、説明し、資金循環につなげる必要がある。本稿では、そのための道具立てを、事業者・金融機関・行政のそれぞれが使える形で示す。

1. 最初に作るべきものは「資産計上ルール」ではない

OSSの価値を考えるとき、すぐに「資産計上できるか」という問いに進みたくなる。しかし、実務上はその前にやるべきことがある。何を使っているのか、どのライセンスなのか、誰が保守しているのか、どの機能が事業に効いているのか、どの支出が研究で、どの支出が開発で、どの支出が保守なのかを記録することである。

会計処理は、記録の上に成り立つ。記録がなければ、資産か費用かを判断できない（注釈1）。ライセンスが分からなければ、将来便益を説明できない。プロジェクト・機能ごとの工数が分からなければ、人件費・費用を測定できない。利用実績が分からなければ、事業価値を説明できない。日本基準が自社利用ソフトウェアの資産計上に求める「将来の収益獲得又は費用削減が確実」という要件も、突き詰めれば、利用目的と効果を示す証跡の問題である（なお、証跡があれば資産計上できるのではなく、証跡は会計判断の前提となりえる）。

1. （注釈1）
   企業会計審議会「研究開発費等に係る会計基準」（1998年）および日本公認会計士協会 会計制度委員会報告第12号「研究開発費及びソフトウェアの会計処理に関する実務指針」。

2. 実務フレームは5層で考える

OSS/DPGsの価値を経済の言葉に翻訳するには、図1のように5つの層で整理すると分かりやすい。下の層ほど技術的な事実に近く、上の層ほど社会的な意味に近い。それぞれの層に、対応するツール・証跡と、説明の「接続先」がある。

第1層と第2層には、すでに国際標準がある。SBOMの記述形式であるSPDXはISO/IEC 5962として（注釈2）、ライセンスコンプライアンスの管理体制を定めるOpenChainはISO/IEC 5230として標準化されており（注釈3）、経済産業省のSBOM導入手引（ver2.0）は、SBOMをめぐる契約上の取り決めまで整理している（注釈4）。つまり、土台となる2つの層については、ゼロから自社流を発明する必要はない。標準に乗ればよい。

第3層の原価は、第3回で見たとおり、会計・税務・資金繰りのすべての出発点である。工数管理というと開発現場には不評だが、目的は監視ではなく翻訳である。支出の性格が記録されて初めて、資産計上の検討も、研究開発税制の適用も、補助金の経費整理も、金融機関への原価説明も可能になる。第4層・第5層は、その上に積み上がる「効果」の層であり、契約一覧、KPI、導入実績、インパクト指標として整理される。この5層をつなげることで、OSS/DPGsの価値は「何となく重要」から「説明できる価値」に変わる。なお、第2回で整理した6つの翻訳パターンとの対応で言えば、ライセンス設計は第2層に、OSPO・OpenChainという統制は第1層・第2層に、売上・サブスクリプションや買収価額は第4層に、基金・助成やDPGsとしての採択は第5層に、それぞれ接続する。

1. （注釈2）
   SPDX（System Package Data Exchange）はSBOMの国際標準フォーマットの一つで、ISO/IEC 5962:2021として標準化されている。2024年4月発行のSPDX 3.0からは、AI・データセット等も対象に含む「System Package Data Exchange」へと名称の意味が拡張された。
2. （注釈3）
   OpenChainの仕様は、OSSライセンスコンプライアンス管理体制の国際規格ISO/IEC 5230:2020として標準化されている。セキュリティ保証については ISO/IEC 18974 も整備されている。
3. （注釈4）
   経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」2024年8月。SBOMに関する契約上の取り決め（要求事項、責任、コスト負担、権利等）を整理した「SBOM取引モデル」を付録に含む。

3. OSPOは、開発と経営をつなぐ翻訳装置である

OSPO（Open Source Program Office）は、OSSを管理する部署というだけではない。開発、法務、知財、セキュリティ、経理、経営が連携するためのハブであり、翻訳装置でもある（注釈5）。

開発者は、どのOSSが使いやすく、どこに技術的負債があり、どのコミュニティに貢献すべきかを知っている。法務や知財は、ライセンスや権利関係を見る。セキュリティは、脆弱性やサプライチェーンリスクを見る。経理は、原価と資産性を見る。経営は、投資対効果と事業継続性を見る。これらを別々に扱うと、OSSの価値は分断される。OSPOは、この分断を減らすための仕組みである。

必ずしも大企業のような専門部署を作る必要はない。小規模な事業者であれば、四半期に一度、OSS利用状況、ライセンス確認、脆弱性対応、工数の区分、外部への貢献を確認する定例の場を持つだけでも、説明可能性は大きく高まる。重要なのは組織の規模ではなく、「技術の事実を、会計・法務・経営の言葉に翻訳する責任者と場」が存在することである。

また、財務諸表に現れない価値が経営層に認識されなければ、OSSへの継続的な人員・予算の配分にはつながりにくい。重要なのは、会計上の資産化の可否だけではなく、OSSへの貢献が企業にどのような価値をもたらしているかを、経営が判断できる形で可視化することである。今後、国がこうした価値を経営管理指標やIT投資評価に組み込むための実務的なフレームを整理し、OSSへの貢献と企業内の投資インセンティブを接続する仕組みを提示することも期待したい。

1. （注釈5）
   TODOグループ（Linux Foundation傘下）はOSPOの実務知見を共有するコミュニティであり、OSPOの定義や成熟度モデルを公開している。

4. 金融機関・行政向けには「価値」ではなく「返済原資」と「公共効果」に翻訳する

OSS/DPGs事業者が金融機関に説明するとき、「この技術は社会的に重要です」だけでは足りない。金融機関が見たいのは、返済可能性である。行政が見たいのは、政策目的への適合と調達の合理性である。したがって、説明の言葉自体を翻訳する必要がある。表2はその対応表である。なお、こうした非財務の説明を載せる枠組みとしては、経済産業省のローカルベンチマーク（注釈6）が金融機関との共通言語として使いやすい。

なお、評価する側の制度も動いている。2024年に成立した事業性融資の推進等に関する法律は、不動産担保や経営者保証に依存せず、事業全体の価値を担保とする「企業価値担保権」を創設した。同法は2026年5月25日に施行されている。無形の技術基盤が価値の中心であるOSS/DPGs事業者がこうした新しい融資の枠組みを活かせるかどうかは、まさに本稿の5層フレームのような記録と説明の整備にかかっている。

社会的価値については、利用者数や導入機関数といった量的指標に加え、SROI（社会的投資収益率）のように成果を貨幣換算して示す手法もある（注釈7）。すべての案件で厳密な評価を行う必要はないが、「どの社会課題に、どの程度の規模で効いているのか」を一枚で示せる資料があるかどうかで、補助金や公共調達における説得力は大きく変わる。

1. （注釈6）
   経済産業省「ローカルベンチマーク（通称：ロカベン）」。財務情報（6つの指標）と非財務情報（商流・業務フロー、経営者・事業・環境関係者・内部管理体制の4つの視点）の3枚のシートで企業の経営状態を把握する、経営者と金融機関・支援機関の対話のための枠組み。
2. （注釈7）
   内閣府・社会的インパクト評価検討ワーキング・グループ（2016）「社会的インパクト評価の推進に向けて—社会的課題解決に向けた社会的インパクト評価の基本的概念と今後の対応策について—」。SROI（Social Return on Investment）は、社会的成果を貨幣価値に換算して投資対効果を示す評価手法の一つ。

5. 補足開示で何を伝えるべきか

財務諸表に出ない価値は、補足開示や説明資料で補う必要がある。上場企業であれば統合報告書や任意開示、中小・ベンチャー企業であれば金融機関向けの経営計画資料、ピッチ資料や事業性評価のための資料が、その受け皿になる。盛り込むべき項目は、たとえば次のとおりである。

• 主要OSSの利用状況と依存関係（SBOMの整備状況を含む）
• ライセンス管理体制と、SPDX・OpenChainなど標準への対応状況
• 重要なOSSプロジェクトへの貢献内容と、コミュニティにおける位置づけ
• 脆弱性対応、保守、リリース管理の体制
• OSS/DPGsを活用した売上、契約、導入実績
• 公共性あるユースケースとインパクト指標
• 研究、開発、保守、導入支援の原価区分
• 資金繰り上の入金タイミングと運転資金需要

これらは、すべてを一度に完璧に整える必要はない。第1層・第2層（構成と権利）から始め、工数記録（第3層）を整え、年に一度、事業価値と社会的価値（第4層・第5層）を棚卸しする。重要なのは、OSS/DPGsの価値を「説明できないもの」として放置しないことである。

6. 最初の問いへの答え

本シリーズの最初の問いは、「OSSあるいはDPGsは価値を生んでいるのに、その価値はどこで見えなくなるのか」であった。これは、OSS/DPGsがソフトウェア開発における社会全体のコスト低減や、付加価値の向上に貢献しているにも関わらず、そのプロジェクトの開発・運用においては、十分な資金が供給されず、維持が困難になるケースが多いことに問題意識の端を発する。会計・金融の面での評価が可能となれば、OSS/DPGsをファイナンスの面で持続可能にすることができるのではないかという仮説に立って、その可能性を本論では考察してきた。

答えは、OSS/DPGsの価値が存在しないからではない。価値の発生場所と、会計・金融が見る場所がずれているからである。OSS/DPGsの価値は、コード、コミュニティ、保守、利用実績、公共性、再利用性、外部資金といった多様な要素に分散して存在している。一方で、会計や金融では、権利、支配、将来便益、原価測定、返済原資、リスク管理の観点から評価を行う。したがって必要なのは、価値をそのまま主張することではなく、会計・金融の観点で理解可能な形で価値を翻訳することである。

結論を一文でまとめれば、こうなる。OSS/DPGsの価値は自然には見えないが、構成、権利、原価、事業価値、社会的価値の5層を記録し、SBOM、SPDX、OpenChain、OSPO、工数管理、契約一覧、インパクト指標へ接続すれば、財務諸表に直接表れない価値であっても、投資・融資・補助金・公共調達・開示の判断材料に変換できる。これは第2回で立て、第3回で例証した仮説の、実務的な言い換えでもある。

おわりに

OSSは無料の素材ではない。DPGsは理念だけで維持される公共財でもない。どちらも、開発し、保守し、説明し、資金を回す人と組織があって初めて続く。

これから重要になるのは、「OSSを使っているか」ではなく、「OSSの価値とリスクを説明できるか」である。AIによるコード生成が広がるほど、出所と権利を説明できることの価値はむしろ高まる。公共性あるソフトウェアを社会に根づかせるには、技術の言葉と、会計・金融・政策の言葉をつなぐ必要がある。その翻訳の仕組みこそが、OSS/DPGsの持続可能性を支える基盤になる。本シリーズが、その仕組みづくりに踏み出す一助となれば幸いである。

参考文献・出典

番号は本文の注釈番号に対応する。［8］は本文第4節で言及。

• [1] 企業会計審議会（1998）「研究開発費等に係る会計基準」/日本公認会計士協会 会計制度委員会報告第12号「研究開発費及びソフトウェアの会計処理に関する実務指針」
• [2] SPDX Project（ISO/IEC 5962:2021）公式サイト https://spdx.dev/（2026年6月10日アクセス）
• [3] OpenChain Project（ISO/IEC 5230:2020、ISO/IEC 18974）公式サイト https://openchainproject.org/（2026年6月10日アクセス）
• [4] 経済産業省（2024）「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」（2024年8月29日公表・本文PDF） https://www.meti.go.jp/files/900016245.pdf（2026年6月10日アクセス）
• [5] TODO Group（Linux Foundation）公式サイト（OSPOの定義・ガイド） https://todogroup.org/（2026年6月10日アクセス）
• [6] 経済産業省「ローカルベンチマーク（通称：ロカベン）」 https://www.meti.go.jp/policy/economy/keiei_innovation/sangyokinyu/locaben/（2026年6月10日アクセス）
• [7] 内閣府「社会的インパクト評価検討ワーキング・グループ報告書（社会的インパクト評価の推進に向けて）」（NPOホームページ掲載） https://www.npo-homepage.go.jp/uploads/social-impact-hyouka-houkoku.pdf（2026年6月10日アクセス）
• [8] 金融庁「事業性融資の推進等に関する法律」関連公表資料（企業価値担保権） https://www.fsa.go.jp/news/r7/sonota/20250702/20250702.html（2026年6月10日アクセス）