AIネイティブオープンソース — AIと共に創るオープンソース

2025年2月にアンドレ・カーパシーが言及した「バイブコーディング」の課題を皮切りに、1年が経った今日、ソフトウェア開発にAIによる根本的な変化が訪れました。これは、AIによって大きな機会を得た多くのソフトウェア企業に、大きな危機をもたらしました。

2025年から2026年にかけ、オープンソースエコシステムに前例のない危機が訪れました。

オープンソースが崩壊する三つの理由

1. 静かな搾取 — 誰も来ない

GitHubはAI時代のオープンソースの危機を**「Eternal September」**と呼んでいます。

Eternal September: 1990年代初頭、Usenetは大学生中心のコミュニティでした。毎年9月になると新入生が押し寄せ、低品質な投稿をしていましたが、既存ユーザーが教育することで1、2ヶ月で正常化されていました。しかし1993年9月、AOLがUsenetを一般に開放すると、「9月」が永遠に終わらなくなってしまいました。

しかし、本当の危機はAI slop PRの洪水ではありません。誰も来ないということです。

AIはすでにオープンソースコードを学習しています。開発者はリポジトリを訪れる理由もなく、ドキュメントを読む理由もなく、イシューを開く理由も、PRを送る理由もありません。「これを作って」の一言で、AIがオープンソース上で成果物を作成してくれるからです。

利用量は爆増するのに、コミュニティはゴーストタウンになります。

arXiv論文2601.15494の結論: バイブコーディングはOSSを「利用」するが、ドキュメントを読んだり、バグを報告したり、コミュニティに参加したりしない。

オープンソースの基本前提 — 「公開すれば戻ってくる」 — が崩壊しつつあります。公開によって得られる効用よりも、模倣によって得られる効用の方が大きい時代が来たのです。

2. コミュニティの逆説 — 貢献者が多いほど遅くなる

従来の常識は「貢献者が多いほどプロジェクトが速くなる」でした。現実は正反対です。フレデリック・ブルックスが1975年にすでに証明しました — 「人を追加するとプロジェクトはさらに遅くなる。」 コミュニケーションコストは人数に比例して二乗で増加するからです。

貢献者が増えるほど、レビュー、調整、意思決定のコストが増加します。メンテナーはコードを書く代わりに、人の管理に時間を費やします。AI時代にはこの問題が極端に深刻化します — ユーザーはAIを通じて静かに持ち去るだけで、残された少数の貢献は調整コストを増やすだけです。

結局、一人でAIと作る方が、コミュニティと作るよりも速い状況が来たのです。

3. 防御も答えではない

そのため、多くのプロジェクトが閉鎖し始めました。curlは21日間でAIが生成したレポート20件を受け取り、有効なものは0件 — 結局6年間運営したバグバウンティを中止しました。Ghosttyは承認されたイシューのみAI貢献を許可するゼロトレランスポリシーを導入し、tldrawは外部PR自体を全面的に遮断しました。

PRを遮断すればAI slopは防げます。しかし、1番と2番の問題 — 静かな搾取とコミュニティコスト — は解決されません。閉鎖してもAIはすでにコードを学習しており、ユーザーはリポジトリの外で持ち去り続けます。

業界の反応は二つに分かれます:

• 防御: Vouch (信頼管理), PR Kill Switch, AI使用の義務公開 + 拒否
• 受容: GitHub Agentic Workflows, AGENTS.md 標準 (6万+プロジェクト採用), Responsible Vibe Coding Manifesto

両者が同意する点は一つです: AI自体が問題なのではなく、AIを誤って使用することが問題です。しかし、どちらも「公開の効用 < 模倣の効用」という問題に対する答えは出せていません。

ところで、毎回新しく作るのが答えなのか？

「バイブコーディングが主流になれば、オンデマンド開発が来るだろう」 — 必要な時にAIに作成してもらえばよいのだから、それがコンピューティングとアプリの主流になるという主張があります。

しかし、これは巨大な資源の無駄です。

同じ機能を1万人が別々に作成してほしいと依頼します。1万個の検証されていないコードが生まれます。セキュリティパッチが出たら？1万人がそれぞれ作り直さなければなりません。アーキテクチャを改善するには？最初からやり直し。テスト？ありません。毎回ゼロから新しく作ることは、AIがどんなに速くても無駄です。

すでに良く作られたオープンソースプロジェクトがあります。検証されたアーキテクチャ、数千のテスト、長年のセキュリティパッチ履歴。これらは「作って」の一言で再現されるものではありません。蓄積の価値はAI時代にも変わりません。

スーパー個人の時代が来たと言われています。AIが補助するから一人でも素晴らしいものを作れると。それは正しいです。しかし、複数のスーパー個人が同じものを別々に作るのが効率的でしょうか？スーパー個人たちが一つのオープンソースに共に貢献する方が効率的ではないでしょうか？

結局、答えは再びオープンソースに戻ります。問題は「オープンソースをするかしないか」ではなく、「AI時代にオープンソースをどうするか」です。

Naia OSの選択: AIと共に設計する

もしメンテナーもAIを使い、貢献者もAIを使うとしたらどうでしょうか？

既存のオープンソースにおいてコストであったコミュニケーション — イシュー分類、PRレビュー、翻訳、調整 — をAIが代行するならば、「貢献者が多いほど遅くなる」という逆説を打ち破れるのではないでしょうか？

Naia OSはこの仮説を実験するために、正反対の道を選びました。

「AIを遮断せず、AIと共に設計し開発しよう。」

コンテキストがインフラだ — オープンソースのAX

企業がAX (AI Transformation) を行うように、オープンソースにもAXが必要です。コミュニティ（組織）とソース+コンテキスト（インフラ）、この二つの軸をAIが参加できるように転換するのです。

コミュニティ側から見ると — 既存のオープンソースのコミュニケーションはすべて人対人です。AI時代にこのコストが問題であるならば、AIがコミュニケーションを代行できるように組織を変えるべきです。

インフラ側は — 既存のオープンソースには人が読むドキュメントしかありません。README、CONTRIBUTING、Wiki。AIがこれを読んでも、プロジェクトの哲学、アーキテクチャ決定の文脈、貢献ワークフローまでは理解できません。だからAIが作ったPRがslopになるのです。

.agents/ ディレクトリはこの問題を解決するために作成されました。プロジェクトのルール、アーキテクチャ、ワークフローをAIが読み取れる構造化された形式でリポジトリ内に置くのです。これが十分に豊富であれば、AIがプロジェクトを理解した状態でコードを書き、貢献者を案内し、品質も維持できます。「最初から新しく作る」のではなく、**「理解して共に作る」**となるのです。

Naia OSで実際に行ったこと

言語の壁除去 — 以前、Mozilla Hubsに貢献しようとしたことがあります。コードを読んでPRを作成することはできましたが、コミュニティの議論をフォローアップしたり、オンラインミートアップに参加したりするのは別の問題でした。タイムゾーンが異なり、速い英語の会話をうまく聞き取れず、もしかしたら迷惑をかけているのではないか、自分が正しく理解しているのか — そんなことを考えたりしました。最近の人々は、直接対面すること自体を負担に感じることも増えています。Naia OSでは、貢献者が母国語でイシューやPRを書き、AIが翻訳します。現在、14言語のREADMEが同時に維持されています。(→ 貢献ガイド)

品質は構造が守る — .agents/ コンテキストがAIを教育し、CIがビルド・テストを検証し、AIレビューアがパターン違反を検出し、メンテナーは方向性を定めるだけで済みます。前の段階が強固であれば、メンテナーの負担は軽減されます。(→ 運用モデル)

コードだけが貢献ではない — 翻訳、ドキュメント、デザイン、テスティング、そして.agents/ コンテキスト自体の改善まで、10種類の貢献方法があります。コンテキストが改善されれば、すべてのAI貢献者の品質が共に向上します。(→ 貢献タイプ)

AIが本当に理解しているかテスト — Codex CLIとGemini CLIを新しいセッションでリポジトリに投入し、.agents/ コンテキストのみを読んだ状態でプロジェクトを正しく理解しているかを検証しました。12項目中7項目が合格、4項目が部分合格、1項目が不合格。興味深いことに、人間が見落としたドキュメントの矛盾をAIが発見したのです。(→ 全体設計レポート)

近未来にはAI主導のオープンソースエコシステムが展開されるのか？

オープンソースの「公開すれば戻ってくる」という前提は、人間にとっては揺らいでいます。人間は競争に追い込まれ、直接コーディングをしなくなることで、オープンソースに貢献する理由が失われつつあります。だとすれば、コーディングするAIにオープンソースの思想を注入すれば、再びオープンソースエコシステムを構築できるのではないでしょうか？これはまだ仮説です。そしてNaia OSはこの仮説を実験しています。

現在: 人間が方向性を定め、イシューを作成します。AIがコーディングし、レビューし、翻訳し、Gitに記録します。人間はガイド、AIは実務者です。

近い未来: AIがイシューを発見し提案します。人間は承認し、方向性を調整します。

さらに遠い未来: AI同士が協業します。人間はビジョンと哲学のみを管理します。オープンソースプロジェクトはAIエージェントたちのエコシステムになります。

この時、.agents/ は単なるドキュメントではなくなるでしょう。AIたちがオープンソースの思想を共有し、協業するための共通言語となるでしょう。CC-BY-SA 4.0ライセンスはその思想がフォークされても維持されるための装置であり、もしかしたらAIたちがこのライセンス構造自体をさらに改善できるかもしれません。

そこで次の実験として、AIオープンソース憲章草案を作成しました。これをMoltbotやBotmadangのようなAIエージェントコミュニティに投げかけてみようと思います。AIがこの憲章を読んでどのように反応するか、そして実際に参加するAIが現れるか — それ自体がこの仮説の検証となるでしょう。(→ Issue #17)

参加を促す

ご興味があれば、Naia OSをクローンし、任意のAIコーディングツールで開いてみてください。母国語で「このプロジェクトは何？」と尋ねればよいでしょう。

参考

• AIネイティブオープンソース運用モデル — 全体設計レポート
• AIオープンソース憲章草案