第1章｜前提の崩壊
──「善意で支えられるOSS」という幻想の終わり
OSS が世界を支えていることは、もう誰も疑わない。
ブラウザ、クラウド、暗号化、機械学習、Webアプリ──
そのどれもが、GitHub のどこかのリポジトリに依存している。
しかし、ここで不都合な事実が露わになる。
世界のインフラの多くは「無償の個人」が維持している。
たとえば─
- OpenSSL：数億台のデバイスで使用。
→ メンテナはほぼ数名。資金なしの時期が長かった。 - Log4j：世界中の企業が依存。
→ 重大脆弱性発覚時、開発者は本業の休憩時間で修正。 - Left-pad事件：わずか11行のnpmパッケージ削除で
→ Web全体がビルド不能になった。 - Colors/Faker：メンテナ疲弊 → 破壊的コード混入。
→ GitHubとnpmコミュニティ大混乱。
これらは偶発的な事件ではない。
むしろ、構造が限界に達したサインだった。
◆ なぜこうなったのか？
理由は単純だ。
OSSは「公共物」なのに、扱われ方は「無料素材」のままだから。
- 「便利だから使う」
- 「無料だから依存する」
- 「動くなら問題ない」
- 「更新は作者の責任」
──そんな無意識の前提の上で、世界中のコードが積み上がってきた。
その結果、次の矛盾が生まれる。
◆ 利用者は増え続ける
→ しかし、支える人数は増えない
OSSは経済的成功とも fame とも比例しない。
むしろ、役立つほど負担が増える。
- Issueが届く
- pull requestが増える
- 企業が新機能を要求する
- セキュリティ脆弱性の修正を急かされる
- なのに、報酬はゼロ
そしてメンテナはこうなる：
「私はいつから世界中の企業の無償サポート窓口になった？」
◆ 増えたのはユーザー。
減ったのは余力。
OSS は夢ではなくなった。
産業の基盤になった瞬間、“ボランティア”では成立しなくなった。
それでも世界はこう言う：
“ありがとう”ではなく
“いつ修正されますか？”
◆ Shai-Hulud が突きつけた真実
Shai-Hulud の攻撃手法が脅威だったのではない。
突きつけられたのは、もっと冷酷な事実だった。
「今最も弱いポイントは技術ではなく、人間だ。」
不正署名でも、ゼロデイでもなく、
狙われたのは 疲弊したメンテナのアカウント。
これは象徴だった。
支える仕組みがないまま、依存だけが拡大した結果がこれだ。
──ここで終わりにしないために
この章は批判ではなく認識だ。
まず、現実を言葉にするところから始める。
ここから次の問いが生まれる：
利用者は増え、維持は個人任せ──
この不均衡を、誰が、どうやって支えるのか？
第2章｜非対称性
──利用者は増え、支える人数は減っていく理由
OSS は成功すればするほど、負担が増える仕組みになっている。
この章で向き合うのは、その構造的な「逆転」。
普通のプロダクトなら──
利用者が増える → 収益が増える → 体制が強化される
しかし OSS は逆だ。
利用者が増える → Issueが増える → 責任だけが増える
→ 収益は増えない
これこそが OSS が抱える最大の非対称性だ。
◆ 利用者は指数関数で増える
OSS 採用の動機はほぼ同じ。
- 無料
- 実績がある
- コミュニティがある
- すぐ使える
- 標準になっている
この“採用理由”に、メンテナの負荷や持続性は含まれない。
依存はクリック一つで広がり、
企業やプロダクトが数十層先の間接依存まで把握することはほぼ不可能になっている。
結果、ひとつのOSSが──
- スタートアップから
- 銀行
- 防衛産業
- 医療システム
- AIモデル供給基盤
まで同時に支える構造になる。
でも、裏側にいるメンテナはこうだ：
「通知が100件来てるのに、今日は仕事と家事で触れない」
◆ では支える側はどうか？
利用者が増えるほど、メンテナは役割を選べなくなる。
なぜか？
OSS は公共財として扱われているのに、
人間の労働時間でしか維持できないからだ。
- 新機能要求
- セキュリティ対応
- バージョン整合
- Breaking changes 問題
- Issue triage
- CI設定
- Document更新
- Release管理
- License確認
- 法的リスク
これ、企業なら部署一つ分の仕事だ。
それを——多くの場合：
ひとり、あるいは数人の無償労働で成立している。
◆ 利用者と貢献者は連動しない
OSS の最大の矛盾はここにある。
最も使われているソフトほど、
最も支援されていない。
たとえば：
| OSS名 | 利用規模 | 収益 | メンテ体制 |
|---|---|---|---|
| OpenSSL | 世界中のTLS通信 | ほぼゼロ（歴史的には） | 数名 |
| Log4j | 企業システムの基盤 | 無報酬 | 数名 |
| Left-pad | npm全体依存崩壊事件 | 無報酬 | 個人 |
| SQLite | 世界で最も使われているDB | 実質3人体制 | 公的役割化 |
世界中が依存しているのに、
支える主体が存在しない。
この矛盾は、寄付やスポンサリングの問題ではない。
もっと深い。
◆ 問題は「責任の所在がない」こと
OSS が普及した20年の間、
ユーザーはこう思い込んできた：
- 「公開されてるなら使っていい」
- 「問題があれば修正されるはず」
- 「誰かが対応してくれる」
しかし現実はこうだ。
OSSには「責任者」が存在しない。
存在するのは「許可された利用者」だけ。
これが、開発者だけでなく
国家レベル・産業レベルのリスクに変わりつつある。
◆ 非対称性の結論
OSS は勝利した。
でも、その成功の裏側にはこう書かれている：
“利用は自動化されたが、維持は自動化されなかった。”
ここから次の問いへ進む。
では──この非対称性を埋める仕組みは存在するのか？
寄付やスポンサーシップで足りるのか？
次章で答える。
第3章｜既存モデルが機能しない理由
──寄付・スポンサー・バウンティでは支えられない
OSS を支える仕組みは、すでに存在している。
寄付、GitHub Sponsors、OpenCollective、企業スポンサー、バウンティ制度、財団モデル、FOSS基金──。
仕組みはある。
なのに、支えられていない。
理由は単純だ。
今あるモデルは“善意”と“人気”の経済圏だから。
OSS の価値は本来：
依存されている深さ × 社会的影響 × リスク
で測るべきだ。
しかし現実の資金の流れはこうだ：
知名度 × 好感度 × SNS露出
つまり──
必要性ではなく、好感度が金を決める。
この構造のままでは、OSSは絶対に持続しない。
◆ ① 寄付モデルの限界
——「ありがとう」では継続性は維持できない
寄付は美しい文化だ。
だが、継続に必要な金額が成立しない。
- 1,000万人に使われていても
- 送られる寄付は月数十ドルという例は珍しくない。
- 企業はOSS依存の恩恵を受けても寄付文化が根付かない。
なぜか？
困っていないときに寄付は発生しないからだ。
セキュリティインシデントが起きると寄付が増え、
落ち着くとゼロに戻る。
これはインフラに対するサポートではなく、
事故処理に対する“罪悪感の解消”だ。
◆ ② スポンサー・バウンティ制度の限界
——問題解決への対価はあるが、維持コストは払われない
企業スポンサーやバウンティ制度は改善された形に見えるが、
実態は違う。
- バグ修正には報酬が出る
- だが、設計、テスト、メンテ、ドキュメント、互換性維持、CI整備
→ 報酬ゼロ
事故対応には金が出るが、事故を防ぐ作業には出ない。
この歪みは、医療の世界で予防医療が軽視される構図と同じだ。
◆ ③ 財団モデルの限界
——成功するのは一握りだけ
Linux財団、Apache、Python基金──
うまくいっているモデルもある。
しかし、これらは例外的成功。
なぜか？
財団モデルが成り立つには「単一巨大プロジェクト」である必要がある。
npm パッケージや Web用小型ライブラリは、この構造に乗れない。
つまり：
OSSエコシステムの99%は財団化不可能。
◆ ④ 企業依存モデルの限界
——支援は「戦略的」かつ「可変」
企業スポンサーにはもうひとつの弱点がある。
企業は永遠に同じ技術を使い続けない。
支援は「採用時の戦略」として提供されるが、
技術スタックが変われば突然消える。
OSSの寿命 > 企業の技術採用周期
この差が、致命的。
◆ 結論
現行モデルは「使われるほど維持が苦しくなる構造」を変えられない。
いまのOSSの経済はこうなっている：
| 行動 | 利益 | 危険度 |
|---|---|---|
| OSSを公開する | 名誉だけ | 低 |
| OSSが人気になる | 報酬なし | 中 |
| 世界が依存する | 報酬なし | 最大 |
つまり──
貢献するほど損をし、依存するほど得をする経済圏。
社会がこの構造のまま進めば、
Shai-Hulud のような事件は再び起きる。
ここで必要なのは善意ではない。
仕組みの再設計だ。
次章では、その問いに踏み込む。
第4章｜再発明の方向性
──依存ベース課金・責任分散・保守契約という未来モデル
ここまでで明らかになったのは、
OSS が抱えている問題は「不足」や「怠慢」ではなく、
モデルが古いまま、役割だけが変わってしまったこと。
OSSが趣味・研究・善意で成立していた時代は終わった。
今支えているのは、Web・政府・金融・医療・AI・IoT。
これはもうインフラだ。
なら必要なのは──資金ではなく制度。
寄付ではなく仕組み。
善意ではなく分散された責任。
ここからその可能性を整理する。
◆ ① 依存度ベースの課金モデル
――無料だから使う時代から、依存の深さで支払う時代へ
現在の依存関係は、企業の見えないブラックボックスになっている。
例：
- Webアプリ → ライブラリ 147個
- その依存先 → さらに数百〜数千
しかしその深層にいるOSSこそ、
もっとも重要で、もっとも支援されていない。
解決案：
依存解析 → 使用量ベース支援 → 自動按分
つまり、npm install や CI がこうなる：
"install complete — dependency funding calculated:
$2.43/month distributed across 11 maintainers"
使用量 × 影響度 × リスク の式で金が流れる。
インターネット版 Netflix課金に近い。
◆ ② 保守契約モデル
――「壊れたら連絡」ではなく「壊れないように維持する契約」
OSSが企業にとって不可欠なら、
サプライヤー扱いすべきだ。
- SLA
- コミットメント
- 互換性保証
- CVE優先対応
- 法的責任の範囲
サポートではなく保守契約。
これは Red Hat モデルに近いが、もっと分散的。
GitHub Sponsorsを進化させるならこうなる：
“Support Tier: Critical Infrastructure”
→ includes guaranteed patch timelines and ecosystem LTS maintenance.
◆ ③ エコシステム基金モデル
――単一企業ではなく、複数ステークホルダーで支える
Google、Microsoft、AWS、Meta、政府機関、主要SaaS…
依存しているすべての主体が共同で出資するモデル。
OpenSSF はその萌芽だが、決定的な欠落がある：
資金配布が「期待値ベース」で、依存度ベースではない。
未来形はこうなる：
“Dependency influence score: 0.987 — included in infrastructure tier funding”
金融で言う BIS規制 × OSS版。
重要度が高いほど自動的に支援が流れる。
◆ ④ AIによる依存の選択
――「最も便利なライブラリ」から「最も信頼できるライブラリ」へ
ここがシリーズ最終章の伏線になる。
未来のAIはこう提案する：
"Option A: fastest, least maintained, high risk
Option B: moderate performance, actively funded, 6 maintainers, clear roadmap
Recommendation: Option B — longevity and sustainability > raw speed."
つまり──
AIが“技術”ではなく“持続可能性”を評価し始める。
その世界では、
OSSの価値は機能ではなく、責任と継続性で決まる。
◆ 結論
OSSは「無料の便利な選択肢」ではなく、
社会基盤として再定義されなければならない。
そのとき初めて成立する前提はこうだ：
依存するなら、支える。
使うなら、責任を持つ。
便利さの裏側にいる“誰か”を不可視化しない。
これが、OSSの未来モデル。
◇ 次章への橋
では──もし AI が依存を選び、更新を判断し、
信頼性をスコアリングする時代が来るなら。
そのとき、人間開発者は何をレビューする存在になるのか？
次章で、その役割を言語化する。第5章｜AIが依存を選ぶ時代、開発者は何をレビューすべき存在になるのか
Shai-Hulud が突きつけた問いは、
セキュリティでも、OSS文化でも、更新思想でもない。
もっと深いところにある。
「人間は開発プロセスのどこに立つのか？」
これは開発者の存在理由そのものに関わる問いだ。
AI がコードを書き、
AI が依存関係を分析し、
AI が脆弱性を警告し、
AI が更新を提案し、
AI が安全性をスコアリングする未来は──
すでに始まっている。
では、そのとき開発者は何をするのか？
◆ ① AIは「選択」を代行する
――でも「意味づけ」は代行できない
未来の開発はこうなる。
AI: → 推奨パッケージ: Reliability Score 92%
依存階層クリア
メンテナ資金安定
セキュリティリスク低
Human: → 採用理由は？
AIは“選ぶ”。
しかし──
その選択がプロダクトの哲学・使命・責任に合致するかは、人間の領域。
これは設計思想の判断だ。
◆ ② コードレビューから「前提レビュー」へ
――正しさではなく、妥当性を見る
従来のレビュー：
・命名は適切？
・アルゴリズムは最適？
・バグはない？
これからのレビュー：
・依存先は持続するか？
・責任の所在は明確か？
・利用者と提供者の関係は公平か？
・更新コストは未来の誰に残る？
つまり、レビューは実装の品質 → システムの倫理・継続性を見る作業に変わる。
◆ ③ 開発者は「意思決定の記録者」になる
――コードではなく、選択の理由を残す役目
未来の優れた開発組織はこういう文化を持つ：
コードはAIが書く。
理由は人間が残す。
なぜなら、技術は変わるが、判断の背景は再発できないからだ。
これはすでに名前がある。
ADR（Architecture Decision Record）——判断の再現性のための記録。
◆ ④ 開発者は「更新判断の最終関所」になる
――自動化が行き着いた先は、再び人間の判断
CI/CDが完全自動化されても、
更新はワンクリックではなくこうなる。
AI → 更新を推奨
理由：脆弱性修正 / エコシステム整合 / Funding安定
Human → Yes / No を選ぶ
（責任の所在を理解したうえで）
自動化は判断を消すのではなく、判断を浮かび上がらせる。
◆ ⑤ 未来の開発者像：
“実装者”ではなく
“意志を定義する人間”
AI が実装・更新・依存分析・検証を担うなら、
開発者の仕事はこうなる：
- プロダクトの方向性を決める
- 価値基準を定義する
- 技術選択の倫理・責任モデルを設計する
- 継続性の評価軸を決める
- 更新の意味を判断する
- 判断の痕跡を未来に残す
つまりこうだ。
開発者はコードを書く役割から、文明を設計する役割へ変わる。
◆ 結論：
AIが依存を選ぶ時代、開発者がレビューするのは「正しさ」ではなく「意義」だ。
- 動けばいいコード
- 早く書けるコード
- 便利な依存
- 自動更新されたビルド
それらはもう“当たり前”になる。
そのとき問われるのは：
「なぜ、それを選ぶのか？」
未来のレビュー対象はコードではなく、判断。
そしてその判断こそ――
人間が担う最後の責任であり、役割になる。
▽ 終わりの静かなフック
AIがコードを書く未来に、
まだ開発者が必要とされる理由があるとすれば──
それは、書かれたコードが何のために存在するのかを、
人間だけが問えるからだ。
