オープンソースメンテナーはAIによる労働のためのスパムフィルターを必要としている

AIツールの普及はオープンソースコミュニティの協業方法を変えつつあるが、その変化は必ずしも良いものばかりではない。AIが生成したバグ報告、プルリクエスト（PR）、セキュリティ脆弱性の開示が低コストで大量に流入する一方、メンテナーはその真偽を判断するために多大な時間と労力を費やしている。

curlプロジェクトの創設者Daniel Stenbergはこの現象を詳細に説明している。AI生成コンテンツ（AIスロップ）が大量出現する以前、curlのバグ報奨金プログラムは約5年半で477件の提出を受け、その約15.4%が確認された脆弱性だった。しかし2025年半ばには状況が一変し、提出の約20%がAIによるものと推定され、プロジェクトは週に約2件のセキュリティ報告を受け取るようになったが、そのうち実際の脆弱性はわずか5%だった。Stenbergによると、各報告の却下には3～4人のセキュリティチームメンバーが30分から3時間（合計1.5～12メンテナー時間）を費やしており、この負担が原因でcurlは2026年初頭に報奨金プログラムを終了した。

同様の問題はプルリクエストにも及んでいる。2026年初頭、tldrawプロジェクトは外部コントリビューターからのPRを自動的にクローズし始めた。AIが生成したPRが急増したためである。これらのPRは一見妥当に見えるが、コントリビューションテンプレートを無視し、コントリビューターライセンス契約の手順を踏まず、プロジェクト設計を理解しておらず、レビューでの質問に対して停滞することが多かった。tldrawのSteve Ruizは、AIがコード生成を容易にする一方で、コードの読み取りとレビューは依然として困難であり、変更を弁護できない提出者にメンテナーの時間を割くべきではないと指摘している。

これらの事例は、AIが提出コストを下げる一方でレビューコストが変わらないという根本的な矛盾を浮き彫りにしている。メンテナーは自分たちの時間を守るためにより厳格な受け入れルールを必要としている。記事が提案する対策には、AI補助の使用を開示すること、アカウント作成からの期間やレート制限の設定、AI生成コンテンツへのラベル付け、そして提出者に再現手順やテスト、設計判断の説明を求めることが含まれる。実際に作業を理解し、質問に答えられる提出者のみを受け入れるべきである。

ただし、AIがすべて悪いわけではない。Stenbergは後に、AISLE、ZeroPath、Codex SecurityなどのAI駆動型分析ツールが多くのバグを発見し、複数のCVEを確認したと述べている。AIによるPRレビューボットはcurlのコード品質向上にも貢献した。問題は、不適切なインセンティブと検証の欠如にある。

オープンソースライセンスとパブリックホスティングは、メンテナーに無制限のトリアージや無料のセキュリティ分析、常時の可用性を要求するものではない。記事は最後に、生成と提出がほぼ無料になった時代には、オープン性を維持するためにフィルターが必要だと強調する。AIは強力だが、証拠、文脈、説明責任があってこそ建設的に活用できる。フィルターなしのAI労働は、最も重要な貢献を低品質な努力の海に埋もれさせてしまう。