「インフラ」から「比喩」へ—10年の乖離

米国で2026年6月、UN Open Source Weekが開催されました（出典）。その場に集まった各国政府の関係者たちは、次々とオープンソースを「重大なインフラ」と呼びました。

この表現は、2016年にNadia Eghbalが米Ford Foundationのために執筆した報告書『Roads and Bridges』に遡ります。当時、テクノロジー企業と慈善財団を対象に書かれたこの報告書は、オープンソースを「道路と橋」に例えました。

オープンソースは社会を支える基本的なインフラなのに、その維持費用や管理体制は「無料で走る」道路のような扱いを受けている。

しかし重要なのは、この比喩はあくまで聴衆を説得するための手段だったということです。当時の対象者（テック企業や財団）は実際には橋を所有したり維持したりしていません。

彼らは「税金で支払われた橋を通り抜ける」側の人間でした。だからこそ、報告書は真の「インフラ管理」までは言及せず、比喩で止まったのです。

過去10年は「寄付」と「スポンサーシップ」の時代

その後の10年間で、オープンソース資金調達の仕組みは大きく広がりました。

  • GitHub Sponsors
  • Open Collective
  • 企業のOSPO（Open Source Program Office）予算
  • 財団グラント

これらは基本的に「利用者からの自発的な貢献」という形態です。土木インフラに例えるなら、「Adopt-a-Highway」（ハイウェイ里親制度）に該当します。

地元の企業が道路の清掃活動に資金を提供し、看板にその企業名が掲載される—実在する制度で、確かに役立っていますが、どの国も橋梁崩壊を防ぐためにこの制度に頼っていません。

任意の寄付と継続的なインフラ維持費用は、本来は別物なのです。

米国の橋梁管理基準から学ぶべき仕組み

この問題の本質を理解するため、米国の実際の橋梁管理制度を見ていきましょう。

1967年、Silver Bridge が崩落して46人が亡くなりました。この事故を受け、1971年から連邦政府は「National Bridge Inspection Standards（NBIS）」を導入しました。現在、この基準は23 CFR 650 Subpart Cに文書化されています。

米国の橋梁管理の仕組みは、以下の要素で構成されています：

要素 内容 オープンソースの現状
強制検査 全橋梁が認定検査官により定期検査（デフォルト24ヶ月サイクル） 検査義務なし。発見ベースの報告
定量的評価 甲板・上部構造・下部構造を0～9で評価。「Poor condition」は定義済み セキュリティ評価の統一基準なし
荷重制限 劣化した橋は法律で「減格」。最大重量を制限する看板が設置される 脆弱性に対する強制的な「容量制限」がない
公開台帳 National Bridge Inventory で全橋梁を記録。所有者・検査記録が公開 CVE データベースは存在するが、不完全で分散化
継続的資金 Highway Trust Fundから自動配分。四半期の気まぐれではない 四半期ごと、寄付者の気分次第
事故調査 NTSB による正式な事故報告書。原因分析と改善提言 インシデント対応は個別プロジェクト依存

この表を見ると、課題が明らかになります。オープンソースがインフラとして認識されるようになったのに、その管理体制は「任意の支援」の枠組みのままなのです。

政府規制は「消費者責任」に重心を置く

さらに問題なのは、ここ数年の政府規制の方向性です。

EU Cyber Resilience Act（CRA）や米Executive Order 14028、各国のSBOM（Software Bill of Materials）義務化は、いずれも「オープンソースの消費者」に責任を負わせる設計になっています（参考）。

橋梁に例えるなら、「輸送企業にどの橋を通ったかを報告させよ」と命じるのに、橋梁検査官を雇っていないようなものです。

Eclipse Foundation が2026年7月に「ORC Learning Hub」を立ち上げたのは、こうした規制への対応支援ですが、根本的な解決にはなっていません。開発者側が適応を迫られる一方で、インフラそのものの維持体制は強化されていないのです。

今、何が必要か

もし本当にオープンソースを「インフラ」として扱うなら、以下のような体制設計が必要になります：

  • 強制的な定期監査：任意ではなく、一定規模以上のプロジェクトは定期的なセキュリティ監査を受ける
  • 定量的な評価基準：「セキュリティが良い・悪い」ではなく、明確な指標と段階評価
  • 機能制限の権限：深刻な脆弱性を持つプロジェクトに対し、「容量制限」（機能削減・インストール提限）を強制できる権限
  • 公開台帳：全重要オープンソースプロジェクトの中央登録簿
  • 継続的な公的資金：四半期の気まぐれではなく、予測可能な予算配分
  • 事故調査体制：大規模インシデント後の正式な調査と改善勧告

これらは「業界の自助努力」では実現できません。公的な制度設計が必要です。

私自身も、AIコーディングツールやローカルLLMの構築で、定期的にオープンソースコンポーネントに依存しています。その信頼性は「スポンサーシップ待ち」ではなく、社会的に保証されるべきものではないか—と感じます。

オーナーシップの問題

もう一つ、報告書では触れられていない課題があります。それが「オーナーシップ」です。

橋梁管理では、所有者が明確です。州政府か市町村か民間企業か—必ず誰かが責任を持ちます。

しかしオープンソースプロジェクトでは、オーナーが曖昧なまま重要インフラ化することがあります。個人開発者が維持するプロジェクトが、数千の企業システムで使われている—こういった状況が放置されています。

2016年の「Roads and Bridges」は、比喩として機能しました。だからこそ10年後、各国政府がその言葉を文字通り受け取り始めたのです。しかし今、私たちは比喩から現実への転換を迫られています。