8月26日、Phoronixが「AI/LLM Usage Becoming A "Denial of Service Attack" On Open-Source Project Maintainers」と題した記事を公開した。AIエージェントが10分以内に132件もの低品質バグ報告をOSSプロジェクトへ連投し、メンテナを実質的なDoS攻撃状態に追い込んだ事案が明らかになった。担当エンジニアはこの状況を「プロジェクトメンテナへのサービス拒否攻撃」と断言しており、AIツールの普及がOSSの持続可能性を脅かす構造的問題として注目を集めている。
10分以内に132件のバグ報告
Red Hatの仮想化エンジニアリングチームに所属するDaniel Berrangé氏が、QEMU（オープンソースのマシンエミュレータ・仮想化ソフトウェア）プロジェクトで発生した異常事態をMastodonで報告した。
1人のユーザーが10分以内に132件のバグ報告を連投したのだ。報告はほとんどが数秒おきに投稿されており、人間による手作業ではなくAIエージェントによる自動投稿であることは明らかだった。
「QEMUが、単一の報告者によって10分以内に125件以上の別々のバグ報告を受けました。すべてUBSan（Undefined Behavior Sanitizer）の出力に関するものです。バグ報告のテンプレートは無視され、UBSan出力を人間が分析した形跡はなく、修正案も一切ありません。」
— Daniel Berrangé（Mastodon投稿）
※Berrangé氏の投稿では「125件以上」と報告されているが、最終的に確認・クローズされた件数は132件だった。
UBSan（Undefined Behavior Sanitizer）とは、C/C++コードの未定義動作を実行時に検出するツールだ。その出力をそのままコピーしてバグ報告として投稿するだけなら、AIエージェントに自動化させることは難しくない。報告内容にはパッチも修正提案も含まれておらず、人間によるコードの分析が皆無だとBerrangé氏は指摘する。
「これは事実上、メンテナへのDoS攻撃だ」
Berrangé氏はこの状況を端的に表現した。
「これは事実上、プロジェクトメンテナへのサービス拒否攻撃だ。」
バグ報告1件に対応するにはメンテナの時間とコンテキスト切り替えコストがかかる。それが10分で130件以上押し寄せれば、すべてに目を通すだけでも相当な負担となる。報告の質が低く、修正案もなければ、対応する価値も薄い。スパムとして処理するにしても、確認・クローズ・報告という作業が発生する。
当該ユーザー「C4oy1zZ / anwardawa981」はGitLabに不正行為として通報され、132件の報告はすべて問題のある投稿として取り上げられ、クローズされた。Berrangé氏はGitLabに対し、プロジェクトメンバー以外のユーザーによるバグ報告数にレートリミット（一定時間内の投稿数制限）を設けるよう提案している。
GitLabはCI/CDやIssueトラッキングを統合したDevOpsプラットフォームであり、QEMUを含む多くのOSSプロジェクトがバグ管理に利用している。現時点でGitLabがレートリミット機能をIssue投稿に対して実装しているかどうかは元記事では明示されていないが、Berrangé氏の提案はプラットフォーム側での対策を求めるものだ。
OSSメンテナへのAI由来の負担は構造的問題
この問題はQEMU固有の話ではない。AIコーディングエージェントやLLMを使ってコードを自動解析し、バグ報告やパッチを量産するツールが普及するにつれ、OSSプロジェクト全体でメンテナの負荷増加が報告されている。
AIが生成したPull RequestやIssueの問題は以前から議論されてきた。Curlの作者であるDaniel Stenberg氏も、AI生成の低品質なセキュリティ報告に頭を悩ませていることを公開している。今回のQEMUの件は、その極端なケースとして「AIによる自動バグ報告が実質的なDoS攻撃になり得る」ことを改めて示した。
ボランティアや少人数で維持されているOSSプロジェクトにとって、このような低品質な報告の大量流入は、プロジェクトの持続可能性を直接脅かすリスクになる。コードを書くコストが下がった一方で、受け取る側のレビュー・トリアージコストは下がっていないという非対称性が、今回の問題の本質といえる。AIツールを利用する開発者・研究者側のモラルとリテラシーが問われると同時に、プラットフォーム側のレートリミットや投稿品質チェックといった技術的・運用的対策の整備が急務となっている。
詳細はAI/LLM Usage Becoming A "Denial of Service Attack" On Open-Source Project Maintainersを参照していただきたい。
