第3回 公共性あるOSS/DPGsは、なぜ資金繰りでつまずきやすいのか

モデル事例で仮説を例証する

取り上げるのは、都市データ、3D可視化、行政DXに関わるOSS/DPGs的な技術基盤を開発する、ある事業者である（注釈1）。固有名詞や個別の金額は扱わない。ここで見たいのは、特定企業の実績ではなく、公共性あるソフトウェアを継続して開発する事業者に共通する構造だからである。

1. （注釈1）
   本稿で扱うモデル事例は、都市データ・3D可視化・行政DX領域でOSS/DPGs的な技術基盤を開発する複数の事業者への支援経験等をもとに、固有名詞・個別金額を伏せて一般化して構成したものである。特定の企業の実績を示すものではない。

1. 公共性があることと、資金が回ることは別である

この事業者が扱う技術は、都市計画、防災、インフラ管理、行政データの活用、地域課題の可視化などに使われる。社会的な意味は大きい。自治体や官公庁、民間企業、国際機関にとっても有用である。

しかし、公共性が高いことは、資金繰りが安定することを意味しない。むしろ、公共性ある案件ほど、事業者側には複雑な資金負担が生まれやすい。一口にOSS/DPGsの開発・運用といっても、その担い手と資金の型は一様ではない。大きく分ければ、（1）開発者コミュニティが有志で担う型、（2）単一企業が主導し商用サービスで収益化する型（第2回のMongoDBやElasticなど）、（3）中立的な財団がプロジェクトをホストし、会費や寄付で支える型（Linux Foundation傘下のプロジェクトなど）、（4）国際機関や財団のドナー資金で支える型（第2回のDHIS2やMojaloopなど）、（5）行政機関等が事業者に委託して開発・運用する型である。なお、（3）の財団型であっても、個々のプロジェクトの保守が少人数に依存する状況は生じ得る。第1回で触れたLog4jは、Apacheソフトウェア財団傘下の事例である。また、（3）や（4）では会費・寄付・助成が開発に先行して入る資金構造を取り得るため、以下で述べる立替の問題は同じ形では現れない。本稿が取り上げるのは（5）の委託型である。公共性の高い案件の国内の実務では、この委託型が最も一般的であり、資金繰りの問題も最も顕著に発生するからである。

この委託型では、企画、提案、契約、開発、検収、請求、入金の間に長い時間差がある。政府や地方公共団体の契約は、成果物としてのソフトウェア納入の完了を確認した後に代金を支払う「後払い」が原則とされており（注釈2）、公共工事では普及している前金払の慣行が乏しいため、単年度・年度末検収の案件では、開発期間中のコストをほぼ全額、事業者が立て替えることになる。開発者の人件費、外注費、クラウド費、管理費は毎月発生する。一方で、入金は検収・請求を経た後である。つまり、価値は先に作られるが、現金は後から入ってくる。図1は、この構造を概念図にしたものである。

ここで例えば受託した事業者の資金繰りが詰まると、どれほど社会的に重要な技術でも、開発や保守を続けることが難しくなる。行政がOSS/DPGsを事業者に委託して開発・運用するという本稿が対象とする類型においては、持続可能性を担保するため、資金循環の設計が必要であろう。事業者の側の視点で見れば、複数の行政システムの構築・運用に関する案件が同じ年度サイクルで動くと、立替負担は単純に積み上がる。行政からより多くの開発・運用を受託している事業者ほど運転資金需要が膨らむという、いわゆる「成長の痛み」が、現状では制度的に増幅されやすい。

1. （注釈2）
   地方公共団体の支出は、給付の完了の確認（検収）後に支払う確定払いが原則であり、資金前渡・概算払・前金払等の例外は、地方自治法第232条の5第2項および地方自治法施行令第161条〜第163条等に定める場合に限られる。

2. OSS/DPGsの価値は、売上だけでは説明しきれない

もっとも、開発費が入金に先行する構造自体は、受託開発一般に共通する。OSS/DPGs事業者に固有なのは、その立替が支える価値の多くが、個別契約の対価に収まりきらない点である。モデル事例で重要なのは、技術が複数の価値を同時に生んでいる点である。

第一に、直接の売上がある。行政や民間からの開発委託、導入支援、保守、カスタマイズである。

第二に、再利用可能な技術基盤としての価値がある。一つの案件で開発した機能が、別の自治体や別の用途に応用できる場合がある。OSSとして公開された基盤であれば、横展開のたびに開発をやり直す必要がなく、限界費用が下がっていく。

第三に、社会的インパクトがある。防災、空き家対策、都市計画、行政データの公開、住民サービスの改善などである。

第四に、人材・信用・ネットワークの価値がある。OSS/DPGsに関わることで、開発者コミュニティ、行政、研究機関、国際機関との接点が生まれ、採用や次の案件につながる。

しかし、これらの価値は、行政機関から受託してOSS/DPGsを開発・運用する事業者側の財務諸表の上では分かりにくい。売上は計上される。補助金や委託費も一定の形で表れる。そもそも成果物であるソフトウェアの権利は、契約上、発注者である行政機関に帰属することが多い（契約によっては、成果物の著作権等が発注者に帰属し、又は発注者に広範な利用権が設定される場合がある）。このケースにおいて事業者側に残るのは、主に再利用を支える設計・保守の能力、技術的知見、コミュニティとの関係といった無形の組織能力である。ただし、本節で挙げた「再利用可能な技術基盤としての価値」が実際に働くのは、成果物がOSSライセンスの下で公開されるか、少なくとも事業者に再利用・再頒布の権利が契約上留保される設計になっている場合に限られる。権利がすべて発注者に専属し、公開もされなければ、横展開のたびに開発をやり直さずに済むという限界費用の逓減は生じない。つまり、契約における権利帰属の設計そのものが、事業者に残る無形の能力を将来の価値に変えられるかどうかを左右する前提条件である。こうした自己創設の無形の能力は、現行の会計基準では資産計上の対象にならないため、財務諸表には表れない。本稿が問題にするのは、この計上できないが確かに存在する能力を、融資や取引の判断材料としてどう可視化するかである。決算書だけを見れば、いわゆる労働集約的な受託開発の会社と区別がつかないのである。

3. 会計上の難しさは「資産か費用か」だけではない

OSS/DPGsの会計論点は、単に「資産計上できるか」という問いに閉じない。日本基準では、研究開発費は発生時に費用処理され、自社利用ソフトウェアは将来の収益獲得又は費用削減が確実と認められる場合に資産計上される（注釈3）。だが実務でまず立ちはだかるのは、その手前にある「支出の性格の切り分け」である。表1のように、性質の異なる支出が一つの開発チームの中で混ざりやすい。

この区分が曖昧なままだと、会計、税務、監査、金融機関向け説明のすべてが難しくなる。資産計上の根拠も、研究開発税制などの税務上の取扱いも、補助金の対象経費の整理も、すべて支出の性格の記録が出発点になるからである。逆に言えば、OSS/DPGsの価値を説明する第一歩は、高度な評価モデルを作ることではなく、工数とプロジェクトの台帳を整え、支出を目的ごとに記録することなのである。

1. （注釈3）
   企業会計審議会「研究開発費等に係る会計基準」（1998年）。研究開発費は発生時に費用処理し、自社利用ソフトウェアは将来の収益獲得又は費用削減が確実と認められる場合に資産計上するとされる。区分の前提として、支出の性格ごとの記録が必要になる。

4. 金融機関に伝わりにくい理由

金融機関は、返済可能性を見る。売上、利益、キャッシュフロー、契約、入金予定、資産、担保、過去実績を見る。ところが、OSS/DPGsの価値は、これらの項目に直接は表れにくい。「このOSSは社会的に重要です」と言うだけでは、融資判断にはつながりにくい。「この技術は公共事業に使われています」と言うだけでも不十分である。必要なのは、契約済み案件、検収予定、入金予定、継続保守、再利用可能な機能、開発原価、資金需要、返済原資をつなげて説明することである。近年、金融庁が促してきた事業性評価融資（注釈4）や、経済産業省のローカルベンチマーク（注釈5）のように、財務情報だけに依存せず事業の中身を見る枠組みは整いつつある。だが、その枠組みに載せる「材料」を整えるのは、事業者側の仕事である。表2は、金融機関が見たい情報と、OSS/DPGs事業者が補うべき説明の対応関係を整理したものである。

リスク管理の項目に挙げたSBOMやライセンス管理は、第1回で見たとおり、経済産業省の手引（注釈6）などで実務の標準になりつつある。これらは本来セキュリティのための道具だが、金融機関や取引先に対して「この会社は自社の技術基盤を把握し、統制できている」ことを示す証跡としても機能する。ここまで整理できれば、OSS/DPGsの価値は、少なくとも融資や補助金の判断材料に変換できる。財務諸表に直接表れない価値でも、説明資料、資金繰り表、契約一覧、インパクト指標として見える化できるからである。

1. （注釈4）
   金融庁は監督指針等において、担保・保証に過度に依存せず、事業の内容や成長可能性を評価して融資判断を行うこと（事業性評価）を金融機関に促してきた。さらに2024年には、事業全体を担保とする「企業価値担保権」を創設する事業性融資の推進等に関する法律（令和6年法律第52号）が成立している。
2. （注釈5）
   経済産業省「ローカルベンチマーク」。企業の経営状態を、財務情報（6指標）と非財務情報（4つの視点：経営者、事業、企業を取り巻く環境・関係者、内部管理体制）から把握する枠組みで、金融機関との対話ツールとして利用されている。
3. （注釈6）
   経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」2024年8月。

5. 第2回の仮説はどこまで確かめられたか

事例に照らす限り、第2回の仮説は概ね妥当と考えられる。ただし、本稿の事例は支援経験をもとに一般化した構成事例であり、仮説と独立に観察された事実による厳密な検証ではない。その限界を踏まえた例証として読まれたい。OSS/DPGsの価値は、コード単体では会計・金融の言葉に乗りにくい。しかし、契約、入金予定、保守体制、ライセンス管理、再利用可能性、社会的インパクトを整理すれば、金融や公共調達の判断材料に変換できる。

一方で、限界も見えた。価値を説明できることと、すぐに資金が出ることは同じではない。金融機関や行政の側にも、OSS/DPGsの価値を理解する枠組みが必要である。事業者側だけが努力しても、評価する側の言葉が整っていなければ、公共性あるソフトウェアは過小評価される。この点、日本でも評価する側の制度は動き始めている。2024年には、不動産担保や経営者保証ではなく事業全体の価値を担保にできる「企業価値担保権」を創設する事業性融資の推進等に関する法律（令和6年法律第52号）が成立した。同法は2026年5月25日に施行され、制度としてすでに動き出している。無形の技術基盤こそが価値の中心であるOSS/DPGs事業者にとって、この新しい枠組みを使えるかどうかは、結局のところ、自社の事業価値を記録と証跡で説明できるかどうかにかかっている。第2回で見たドイツのSovereign Tech Agencyのような公的資金の仕組みとあわせて、評価する側と説明する側の双方の整備、また双方の言葉を翻訳できる人材の育成が問われている。

おわりに

公共性あるOSS/DPGsは、社会全体のソフトウェアの開発・運用コストを低減し、新しい付加価値を生み出すため重要である。しかし、それが重要であるとしても、それをもって開発・運用を行う事業者の資金繰りの問題が解決するわけではない。行政機関からの受託によるOSS/DPGsの開発においては、開発費は先に出て、入金は後から来る。保守や脆弱性対応は不可欠だが、財務諸表では価値として見えにくい。社会的インパクトは大きくても、融資判断には翻訳が必要である。

次回は最終回として、ここまでの例証を実務フレームに落とし込む。OSS/DPGsの価値を、どのような記録、管理、開示、資金説明によって経済の言葉に変換できるのか。第1回の問題提起に立ち返り、実務上の着地点を示す。

参考文献・出典

番号は本文の脚注番号に対応する。注釈1は事例の性格に関する注記のため対応する文献はない。［7］は本文第5節で言及。

• [2] 地方自治法（昭和22年法律第67号）第232条の5ほか（e-Gov法令検索） https://laws.e-gov.go.jp/law/322AC0000000067（2026年6月10日アクセス）
• [3] 企業会計審議会（1998）「研究開発費等に係る会計基準」／日本公認会計士協会 会計制度委員会報告第12号「研究開発費及びソフトウェアの会計処理に関する実務指針」
• [4] 金融庁「中小・地域金融機関向けの総合的な監督指針」（担保・保証に過度に依存しない融資等） https://www.fsa.go.jp/common/law/guide/chusho/02d.html（2026年6月10日アクセス）
• [4b] 金融庁「事業性融資の推進等に関する法律」関連公表資料（企業価値担保権） https://www.fsa.go.jp/news/r7/sonota/20250702/20250702.html（2026年6月10日アクセス）
• [5] 経済産業省「ローカルベンチマーク（通称：ロカベン）」 https://www.meti.go.jp/policy/economy/keiei_innovation/sangyokinyu/locaben/（2026年6月10日アクセス）
• [6] 経済産業省（2024）「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」（2024年8月29日公表・本文PDF） https://www.meti.go.jp/files/900016245.pdf（2026年6月10日アクセス）
• [7] Sovereign Tech Agency 公式サイト https://www.sovereign.tech/（2026年6月10日アクセス）