オープンソースプロジェクトはAI生成コードをどのように受け入れるべきか? — QEMUの禁止ポリシーからの教訓

QEMUプロジェクトは、AIツールによって生成されたコードによる貢献を拒否する方針を正式に取り決めた。その核心的な理由は、貢献者が提出するパッチの正当性を証明するために用いているDeveloper’s Certificate of Origin (DCO) の要件を、AI生成コードが満たせないという懸念である。この問題に対して我々は何をすべきなのだろうか?

English article: https://shujisado.org/2025/07/02/how-can-open-source-projects-accept-ai-generated-code-lessons-from-qemus-ban-policy/

なぜDCOはAI生成コードを拒むのか?

AI生成によるコードがDCOをクリアしにくい理由は二つある。一つは人間による作者性の問題である。DCOの条項は貢献が「自身によって作成された」ことを求めているが、現状で多くの法域ではAI生成コードに著作物性を認めていない。従って、人間の作者の存在を示すことが法的に難しい。二つ目は生成コードが本当にクリーンであるかが不明瞭だからである。AIが様々な世界中の様々なライセンスが適用されたソフトウェアのコードでトレーニングされているのは自明であり、貢献対象のソフトウェアのライセンスと矛盾するライセンスのコード断片が偶然出力される可能性もある。

現在ではある程度の大きさの断片のコードが既存の公開されたソースコードとの類似をチェックする仕組みを利用することが一般的になりつつあるので、二つ目の懸念は割と小さなリスクと整理できるかもしれない。しかし、どの程度リスクが抑制されているのかはまだ不明瞭であるとは言える。それよりも一つ目の作者性の問題は本質的に解決が難しい。

AI生成コードは多くの法域で著作権が認められない。これは一種のパブリックドメインのコードに近いと言える。パブリックドメインのコードをオープンソースのソフトウェアに組み込むこと自体は、ライセンスの互換性を気にする必要がなく、全く問題がない。また、一般的にソースコードの全てが著作権で保護されるわけでなく、「アイデア」や「ありふれた表現」などの人間による創作性が低い部分は著作権保護の対象外である。この二つの事実を合わせると、AI生成コードをプロジェクトへ組み込むことは、プロジェクト全体に占める著作権保護対象となるコードの割合が減るだけという見方が理論上は成り立つ。

だが、実際にAIによって生成されたコードに「著作権がない」ことを人間が保証することは非常に困難である。AI生成コードに著作権がないという多くの法域での見解は存在するが、グローバルで法的に統一された見解からは程遠い。また、そのコードをどのように扱えば人間の著作権が認められるのかという点も曖昧であり、法的な不確実性が大きいと言える。また、AI生成コードに対して誰かが著作権のクレームを付けた場合、AIの利用者が「これはAIが生成したものであり、著作権がなく、あなたの著作物とも無関係だ」と立証することは難しい。つまり、現状では、AI生成コードが、第三者コードと一切類似せず、かつ、著作権が発生しないことが法的に保証することは難しい。よって、QEMUプロジェクトのようなAI生成コードを拒絶するという決断をするプロジェクトは今後も出てくるだろう。

それでもAI生成コードを受け入れる道は?

AI生成コードをオープンソースプロジェクトが何ら障害もなく受け入れるためには、まず既存コードとの類似性をチェックする仕組みの更なる改善が必要である。商用の優れた製品があることは理解しているが、オープンソースで提供されるツールの進化を促す必要があるだろう。また、AI出力コードの透明性を高めるために、SPDXがAI生成関連コードを識別する仕様をなるべく早く追加し、様々なシステムで自動的にタグが付与されるように促すことも重要だろう。

さらに、QEMUプロジェクトがAI生成コードを拒絶するポリシーを規定したのは、DCOの解釈上は人間の作者を要求しているからである。よって、AIの時代の到来に合わせてDCO自体のアップデートが必要なのかもしれない。歴史的に考えれば、DCOはSCO GroupからのLinux陣営への訴訟攻撃があった時代にLinuxカーネルへの貢献コードの出所をめぐる問題や訴訟の排除を目指して導入されたものである。AI生成コードの出所が課題なのであるから、このDCOをアップデートしてDCOv2を作成することは理想的であるように一見は考えられる。

しかし、DCOはすでに様々なプロジェクトやコードホスティングプラットフォームで使われており、DCOを安易にアップデートすることは大きな副作用が生じる可能性が高い。DCOの最大の利点はその簡潔さと普遍性にあり、その利点を損なうアップデートも難しいだろう。事実上、DCOでAI生成コードへの対応を行うのは相当に難易度が高いと言える。そのため、DCOにおける「私が作成した」という根幹の宣誓は維持し、その宣誓を誠実に行うために貢献者が何をすべきかを、周辺のドキュメントで補うというアプローチが現実的であるが、この作業を完全に各プロジェクトに任せるとDCOの解釈がプロジェクトによって揺らぐ状況となり、貢献者にとってもプロジェクト管理者にとっても混乱を招き、エコシステムの健全性を損なうだろう。

非常に難しい作業になると思うが、DCOの策定者であるLinux FoundationはAI時代におけるDCOの解釈がどのようにあるべきかという点に対してある程度のガイダンスを示す必要があるように思う。

https://www.linuxfoundation.org/legal/generative-ai でLinux FoundationとしてのAIポリシーを示していることは理解しているが、これだけではDCOを採用していく幾万のプロジェクトにとって参考とはなりにくいだろう。特にDCOにおける「人間の作者性」を要求する部分に対する指針を示すべきである。Linuxカーネルのような法的安定性が最優先されるプロジェクトとWebフレームワークのような開発速度が優先されるプロジェクトでは許容されるリスクに大きな差異が生じることは理解するが、それでもDCOにおけるAI生成コードの受け入れに関する最低限の考え方を整理する必要がある。