COSMICデスクトップ、AI生成コードを全面禁止——メンテナーの負荷過多かオープンソースのアイデンティティ危機か

2026年10月、System76傘下のCOSMICデスクトッププロジェクトは貢献規則を更新し、プルリクエストのテンプレートに強制的な宣誓リストを追加した。すべての貢献者に対し、「本PRにおいてコード・コメント・PR説明文を含む一切のLLM生成コンテンツを使用していない」ことを誓約するよう求めている。この禁止はほぼコードベース全体に及び、上流プロジェクトが自身でマニフェストを管理するcosmic-flatpakのみが適用除外となっている。

COSMICはPop!_OSオペレーティングシステムの基盤となる次世代デスクトップ環境であり、System76がRust言語でゼロから構築したもので、現在も集中的な開発段階にある。同プロジェクトの貢献者規約では、以下の各項目すべてにチェックを求めている：LLMを使用してコンテンツを生成していない；提出した変更内容を完全に理解しコードレビューに対応できる；コミットの説明が変更内容を正確に記述している；変更がテスト済みである；Developer Certificate of Origin（DCO）のすべての条項を読み遵守している。

メンテナーの負荷過多：禁止令の直接的な引き金

System76の主任エンジニアJeremy Sollerは、この決定を説明する際に現実的なジレンマを率直に指摘した。LLMツールの普及により、それまでプロジェクトに一切関与していなかった大量の貢献者が参入してきたが、彼らが提出するコンテンツは「想定外であり、ほとんど採用されない」という問題だ。問題はそれらの提出物の品質の低さではなく、品質にかかわらずすべてのPRにメンテナーが審査・テスト・返答の時間を費やさなければならない点にある。提出数が大幅に増加しながら採用率が低い状況では、メンテナーの限界的な負担が急増する。

このジレンマはCOSMIC固有の問題ではない。Linuxカーネルのメンテナーも同様にAI支援による提出に溢れていると報告しており、Ubuntuも押し寄せる問題報告の数に対処するためにアップデートのペースを上げている。違いは、LinuxとUbuntuが「条件付き受け入れ」——品質基準を満たせばAI生成コンテンツの審査通過を認める——を選択したのに対し、COSMICは入口を直接封じることを選んだ点にある。

COSMICの禁止令はAIツール自体を対象としているのではなく、「生成型」の用途を対象としている。AIを補助的に活用してバグを発見したりコードを理解したりする非生成的な場面は禁止の対象外だ。この区分は、System76が封じようとしているのが「AIに人間の代わりにコードを書かせて提出する」という特定の行為であり、AIツールを全面的に排除しようとしているわけではないことを示している。

法的側面の深刻な懸念：DCOはAI生成コードに適用できるか

メンテナーの負担は表面的な理由に過ぎず、オープンソースコミュニティがこの問題を議論する際には常に、より根本的な法的疑問が付きまとう。DCO（Developer Certificate of Origin）はAI生成コードに合法的に適用できるのか、という問題だ。

DCOは貢献者に対し、署名の上で「当該コードをプロジェクトのライセンスの下で提出する権利を有し、コードの出所が明確である」ことを証明するよう求める。問題は、主流の大規模言語モデルがいずれもGPLなどの制限的なライセンスが適用されるコードを含む大量のオープンソースコードで学習されていることだ。開発者がAIに生成させたコードを提出する際、そのコードの真の出所を追跡することは実質的に不可能であり、DCO署名が求める権利帰属の宣言を誠実に行うことができない。

Red Hatはある分析の中で、DCOはこれまで各行のコードが貢献者自身の創作表現であることを要求してこなかったと指摘している。しかし複数の法的見解では、出所を全く追跡できないAI出力に対してDCOに署名することは誠実性の観点からリスクがあるとされている。NetBSDプロジェクトはさらに早い段階で「著作権汚染」を理由にAI生成の提出を禁止した——メンテナーたちは、学習データのライセンス状態が不透明であることから、AI出力は法的に「出所不明」のコンテンツに当たると判断したのだ。

オープンソースエコシステムの路線対立

COSMICの選択により、オープンソースコミュニティ内部の意見の相違がより明確になった。これまでの報告を見ると、現在のLinuxエコシステムはAIポリシーにおいて二つの明確な陣営に分かれている。

一方は明確に禁止するプロジェクト群だ。aerynOSは「ChatGPT、Claude、Copilotなどの確率的ツールが生成したコンテンツ」を明示的に禁止している。Chimera Linuxは「LLMの使用が発覚した貢献者はプロジェクトへの参加を永久に禁止する」と規定している。Elementary OSは「LLMおよびチャットボットによって生成された貢献」を認めていない。Gentooは「自然言語処理AIツールを用いて作成されたあらゆるコンテンツ」を禁止している。Nuraは「生成AIによって一部または全部が作成された貢献」を禁止している。secureblueは「いかなる形式であれAI生成のコードまたはコンテンツはすべて禁止」と規定している。

もう一方はLinuxカーネルに代表されるプラグマティックな路線だ。Linuxカーネルは2026年にAI支援コードに関する正式なポリシーを策定し、その核心的な仕組みとして新たな「Assisted-by」タグを導入した。AI支援によるコードには法的拘束力を持つ「Signed-off-by」タグを使用できず、代わりに「Assisted-by」を付記し、そのコードを提出した人間の開発者にすべての責任を明確に帰属させる。このポリシーの策定には数ヶ月にわたる激しい議論を経た。IntelのDave HansenとOracleのLorenzo Stoakesが公に対立し、Linus Torvaldsが彼らしい率直なスタイルで議論に終止符を打った。TorvaldsはAIへの全面禁止を「無意味なポーズ」と切り捨て、AIを「また別のツール」と位置づけた。悪意ある者がゴミを提出する場合はどのみちルールを読まないのだから、重要なのは人間の開発者が自分の提出物に責任を持てるようにすることだ、という論旨だ。

この二つの路線の背後にある論理の違いは精査に値する。Linuxカーネルのアプローチは問題を「説明責任」の問題として再定義する——AIを使うか否かは重要ではなく、人間がコードの品質に責任を持つことが重要だ、という考え方だ。COSMICのアプローチは問題を「運営コスト」の問題として定義する——AI生成コードの品質にかかわらず、選別コスト自体が受け入れがたい負担であり、審査よりも源流での遮断の方がコスト効率が高い、という考え方だ。どちらの答えも内的な整合性を持っているが、前提が異なる——Linuxカーネルには数十年にわたって積み上げられた高い審査文化と大規模なメンテナー陣がある一方、COSMICはまだ急速な構築段階にある比較的小規模なプロジェクトだ。

各利害関係者にとっての意味

COSMICへの貢献を希望する個人開発者にとって、このルールは提出前にすべてのコードの出所を明確に把握していなければならないことを意味する。AIを使って「素早くキャッチアップ」することに慣れた開発者は、より高い参入障壁に直面することになる。これにより、プロジェクト自体への理解が浅くAI生成の提出に主に依存している貢献者が篩い落とされる。そしてそれはまさにSystem76が意図している効果だ。

企業ユーザーや組織としての貢献者にとっては、状況がより複雑になる。ますます多くの企業がAI支援プログラミングツールを開発フローに深く統合しており、特定のオープンソースプロジェクトへの貢献時にそれらのツールを「手動でオフにする」よう従業員に求めることは、運用上の曖昧さを伴う。貢献者のコードが完全にAI生成によらないものであることを証明する信頼できる技術的手段は現時点で存在しない——この禁止令は本質的に技術的な強制ではなく、コミュニティの誠実さに基づく自律に依存している。

オープンソースエコシステム全体の競争環境においては、この分裂はプロジェクトを選ぶ際に開発者が新たな次元を考慮しなければならないことを意味する——そのプロジェクトのAIポリシーは何か？という問いだ。禁止派と開放派のプロジェクトはそれぞれ異なるコミュニティ風土を形成していき、ひいては各々の開発速度やコードスタイルに影響を与えていくかもしれない。