大規模オープンソースプロジェクトのメンテナーが、AIスロップ(AIが生成した低品質な成果物)の被害を最も大きく受けています。Linux Foundationが、オープンソースのコントリビューターとメンテナー234人を対象に実施した調査で、コントリビューターが50人を超えるプロジェクトの運営者は、レビュー待ちのコード変更のうち、3分の1近くが低品質、またはAI生成のものだと推定しています。こうしたメンテナーは今、コードそのものより、自分自身の燃え尽きを心配しています。
全プロジェクトを平均すると、推定値は約4件に1件です。プルリクエストと呼ばれるこうした投稿は、マージするか却下するかを決める前に、必ず人間が目を通さなければなりません。その担い手がメンテナーであり、キューに紛れ込んだ不要な投稿は1件ごとに、プロジェクトの運営を支える本来の作業の時間を奪っていきます。
規模が大きいほど、山も大きく
大規模なプロジェクトなら、増えた負荷を多くのレビュー担当者で分担できると思うかもしれません。しかし、現実はそうなっていません。スロップの量が最も多く、投稿の増え方が最も速く、レビューの長期化に対する不満が最も多かったのは、いずれも大規模プロジェクトでした。
多くのメンテナーが、生成AIが普及して以降、寄せられるコントリビューションが増えたと答えています。小規模なプロジェクトでは、AI支援による作業の最大の懸念として、依然としてコード品質を挙げています。一方、大規模なプロジェクトでは、燃え尽きが懸念事項の筆頭になりました。
ルールを整備したプロジェクトはまだ少数
AI支援によるコントリビューションを認める正式な方針を設けているプロジェクトは約3分の1で、禁止しているのは10件に1件です。残りは、方針を文書化していないか、まだ策定中です。方針がある場合も、AIの利用を開示することと、自分の成果物のレビューに責任を持つことを、コントリビューターに求める内容が大半です。
ルールがない場合、メンテナーは昔ながらの方法でAI支援コードを確認しています。知っているコントリビューターを信頼するか、自分でコードを読むかのどちらかで、約4分の1は何の確認手段も設けていません。AIにはAIで対抗しているメンテナーも多く、4人中3人は、受け取った内容の検証にAIツールを活用しています。主な用途は、変更内容の要約や、ロジックのバグ探しです。
コントリビューターは「慎重に確認している」と回答
開発者側から見た状況は、想像よりも良好です。10人中6人が、AI生成コードを1行ずつ確認し、十分にテストしてから提出すると答えています。未確認のまま送信していると認めた人は、ごくわずかでした。
ただ、AIを使ったことを周囲に伝えるかどうかになると、対応はばらばらです。約5人に1人は、まったく伝えていません。プロジェクトを運営していて、参考になる基準を示したいなら、Linuxカーネルがすでに一つの例を示しています。コミットメッセージに、使用したAIツールとモデルを明記する「Assisted-by:」行を求めているのです。
時間の節約効果は本物だが、限界もある
AIを使っている人は、コードを書く時間が約半分に、レビューの時間が40%以上減ったと答えています。ただし、作業が難しくなるほど、この効果は薄れます。最も複雑な作業では、約5人に1人の開発者が、AIのせいで作業が遅くなると回答しました。
コミュニティ側にも代償があります。AIによって新規参入者が関わりやすくなる点には、多くのメンテナーが同意しています。一方、コミュニティ内の信頼には何の効果もないと答えた人も、半数を超えています。新しいコントリビューターには追加の指導が必要だと答えた人は、必要ないと答えた人より多く、その指導は、ただでさえ増えたキューをさばいているメンテナーの肩にのしかかります。
curlプロジェクトの例は、この問題が和らぐ可能性を示しています。プロジェクトリーダーのDaniel Stenberg氏は2025年、curlは脆弱性報告に混じるAIスロップに圧倒されていると述べていました。ところが2026年4月には、プロジェクトは「AIスロップのセキュリティ報告を受け取らなくなった」うえ、「ほぼすべてAIの助けを借りた、質の高いセキュリティ報告が増え続けている」と語っています。
翻訳元: https://www.helpnetsecurity.com/2026/10/26/linux-foundation-open-source-ai-slop/
