10月26日、Help Net Securityが「AI slop is piling up highest on the biggest open-source projects」と題した記事を公開した。Linux Foundationの調査をもとに、大規模オープンソースプロジェクトにおけるAI生成の低品質コード（AI slop）の急増と、それによるメンテナのバーンアウト問題について詳しく紹介されている。

大規模プロジェクトほど負荷が集中する

Linux Foundationが234名のオープンソースコントリビューターとメンテナを対象に実施した調査によると、50人以上のコントリビューターを抱える大規模プロジェクトでは、レビューキューに届くプルリクエストの約3分の1が低品質またはAI生成と推定されている。全プロジェクトを通じると、その割合は約4分の1に相当する。なお、ここで言う「AI slop」とは、AIが生成した低品質・粗雑なコンテンツを指すスラングであり、近年オープンソースコミュニティで急速に広まっている言葉だ。

「大規模プロジェクトならレビュワーも多いから分散できる」という期待は、現実には裏切られている。調査では、大規模プロジェクトほどAI slopの量が多く、プルリクエストの増加速度も速く、レビューの遅延への不満も大きいという結果が出た。

生成AIが普及して以降、多くのメンテナが「コントリビューションが増えた」と回答している。小規模プロジェクトでは依然としてコード品質そのものへの懸念が上位を占めるが、大規模プロジェクトではバーンアウトへの懸念がトップに浮上している。プルリクエストは1件ずつ人間が読まなければマージも却下もできない。そのコストが、プロジェクトを支えるべきメンテナの時間を削り続けている。

ポリシーの整備はまだ途上

正式なAI利用ポリシーを持つプロジェクトは約3分の1にとどまり、禁止しているのは1割。残りは未整備か策定中だ。ポリシーが存在する場合も、その内容はAI使用の開示と、コードの事前レビューを投稿者自身に求めるというものが中心である。

ポリシーがない場合、メンテナは昔ながらの方法で対処している。知っているコントリビューターを信頼するか、自分でコードを読む。約4分の1はチェック自体を行っていない。一方、4分の3のメンテナはAIツールを使ってレビューを補助しており、変更内容の要約やロジックバグの検出に活用している。

参考になる実例として、Linuxカーネルはすでにコミットメッセージに Assisted-by: という行を設けており、使用したAIツールとモデルを明記する運用を採用している。なお、本調査の詳細な集計・方法論についてはLinux Foundation Researchで公開されているレポートを参照されたい。

コントリビューター側の自己認識と現実のギャップ

コントリビューター側の回答は、メンテナ側の懸念より楽観的だ。6割がAI生成コードを行単位で確認し、十分なテストを経てから提出していると答えている。未確認のまま送るという回答は少数にとどまる。

ただし、AI関与の開示については一貫性を欠く。約5人に1人はAIを使ったことを一切知らせない。メンテナ側にすれば、相手がどこまで自分でコードを理解しているか判断しにくい状況でもある。

時間短縮効果は「簡単な仕事」に限定される

AIを使うことで、コード作成時間は約半分に、レビュー時間は40%超削減できると回答した開発者は多い。ただし、この効果は難易度が上がるにつれて薄れる。最も複雑なタスクでは、約5人に1人がAIによって作業が遅くなると答えている。

コミュニティへの影響も見逃せない。AIによって新規参加のハードルが下がったという意見は多数を占める一方、半数以上のメンテナは「コミュニティ内の信頼には何も貢献していない」と答えた。新しいコントリビューターへのメンタリングが以前より必要だという声は、不要になったという声を上回っており、そのメンタリングも結局は既存のメンテナが担っている。

curlプロジェクトの事例：状況は改善できる

curlプロジェクトはひとつの好例を示している。プロジェクトリードのDaniel Stenbergは2025年、脆弱性報告がAI slopで溢れかえっていると述べていたが、2026年4月には「AI slopのセキュリティレポートは届かなくなった。AIを活用した質の高いレポートが増え続けている」と状況の改善を報告している。問題は固定的ではなく、コミュニティの対応次第で変えられる余地がある。

詳細はAI slop is piling up highest on the biggest open-source projectsを参照していただきたい。