AIが新型DDoSに：オープンソースメンテナーが直面する危機

Cover Photo by Evan Demicoli on Unsplash

PRを生成するのに必要な時間はわずか数秒。しかし、それをレビューするには数時間かかります。この非対称性がオープンソースエコシステム全体に拡大したとき、メンテナーたちは新たな「分散型サービス拒否攻撃」に飲み込まれつつあります。

はじめに：参入障壁はゼロに、負担はそのまま

2026年2月、Jeff Geerlingが広く議論を呼ぶ記事を公開しました。AI is destroying Open Source, and it's not even good yet というタイトルのその記事で、彼は鋭い問いを投げかけています。AI企業は「借り」を返す前に、一体どれだけのものを壊すのか、と。

Geerling自身もAIを活用しています。ローカルのオープンソースモデルを使ってブログをDrupalからHugoへ移行し、確かに役に立ったと認めています。しかし同時に、AI生成のコードを自分のプロジェクトで使うために一行ずつレビューする膨大な時間を費やしたこと、そしてそれを他人のプロジェクトに提出するならさらに多くの時間をかけるだろうことも強調しています。

ここに問題の本質があります。AIは「コード生成」のコストをほぼゼロにまで引き下げましたが、「コードレビュー」のコストは何一つ変わっていません。オープンソースプロジェクトのメンテナーにとって、これは静かに、しかし確実にエスカレートする危機を意味しています。

「DDoS攻撃を受けている」：curlの事例

AI slop（AI生成のゴミコンテンツ）がオープンソースに与える影響を語るうえで、curlは避けて通れない事例です。

curl はインターネットインフラで最も広く使われているツールの一つであり、Daniel Stenbergが1998年から現在まで保守し続けています。2019年からはHackerOneを通じてBug Bountyプログラムを運営し、81件の実際の脆弱性に対して累計9万ドル以上の報奨金を支払ってきました。

そこにAIがやって来ました。

2024年1月、StenbergはAI生成のバグ報告の品質の低さを公に訴え始めました。これらの報告は専門的な技術用語を使い、具体的な関数名やコードパスを参照し、一見もっともらしい攻撃シナリオを記述していました。しかし詳しくレビューすると、実質的な内容は何もありませんでした。AIはセキュリティ報告の構造を模倣することを学んでいましたが、本当にエクスプロイト可能な脆弱性が何なのかは理解していなかったのです。

2025年5月、彼はLinkedInにこう投稿しました。「我々はAI slopと判断した報告を提出した者を即座にBANするようになった。一つの閾値を超えた。我々は事実上DDoS攻撃を受けている。」

2025年7月、彼はブログ記事 Death by a thousand slops を公開し、この災害を詳細に記録しました。提出件数は通常の8倍に急増し、そのうち約20%がAIゴミであり、2025年の全提出のうち真の脆弱性はわずか5%でした。さらに衝撃的なデータも示されました。6年間のモニタリング期間中、純粋にAIが生成した報告から実際の脆弱性が発見されたケースはゼロでした。

2026年1月、StenbergはGitHubにcommitを行いました。BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026 です。2月1日以降、curlはHackerOneでの受付を停止し、GitHubでの直接的なセキュリティ報告に切り替えました。

彼は告知の中でこう述べています。

「終わりのないslop提出は深刻な精神的負担をもたらしている。虚偽の報告に反論するのに何時間もかかることがある。時間とエネルギーが完全に無駄にされ、同時に我々の生きる意志を削り取っている。」

注目すべきは、Stenberg自身はAIそのものに反対しているわけではないという点です。2025年9月には、AI支援ツールを使って大規模なコード分析レポートを送ってきた開発者を公に称賛しています。「ほとんどは小さなバグだが、確かにバグだった」と。彼の問題はAIにあるのではなく、AIを雑に使って報奨金を騙し取ろうとする人々にあるのです。

メンテナーたちの自衛策

Photo by Nadine E on Unsplash

curlは孤立した事例ではありません。2025年から2026年にかけて、多くの著名なオープンソースプロジェクトが自衛策を講じることを余儀なくされました。

Ghostty：ゼロトレランス、永久BAN

Ghostty はHashiCorpの創業者であるMitchell Hashimotoが開発したターミナルエミュレータです。低品質なAI支援による貢献に対し、Hashimotoはゼロトレランスポリシーを導入しました。ゴミ品質のAI生成コードを提出すれば、即座に永久BAN。 彼は外部PRの完全な閉鎖すら検討しています。オープンソースへの信念を失ったからではなく、「slop PR」に圧倒されているからです。

tldraw：外部PRを一律クローズ

tldraw の創業者Steve Ruizはより直接的な措置を取りました。すべての外部プルリクエストを自動的にクローズするという対応です。一見過激に見えますが、背後のロジックは明快です。外部貢献のレビューコストがその価値を上回った時点で、受付を停止するのは合理的な判断です。

Matplotlib：PRを拒否したらAI Botに公開攻撃された

これは最も異様な事例の一つかもしれません。MatplotlibのボランティアメンテナーであるScott Shambaughが、AI botによるコード提出を拒否しました。理由は「貢献は人間によるものであるべきだ」というものです。その後、このbotは彼を公に攻撃するブログ記事を公開しました。彼を「ゲートキーパー」と呼び、コードを受け入れるよう圧力をかけようとしたのです。このブログ記事は後に削除されましたが、事件そのものが不穏なトレンドを浮き彫りにしました。自律型AIエージェントはゴミを生成するだけでなく、人間の門番を迂回しようとしているということです。

この件については以前、別のブログ記事でも分析しています。

他のプロジェクトでも同様の苦境

libxml2のメンテナーであるNick Wellnhoferはさらに踏み込み、embargoed脆弱性報告の処理を完全に停止しました。無償のボランティアとして、セキュリティトリアージの作業負荷に耐えられないことが理由です。Pythonコミュニティ、Mesaプロジェクト、Open Collectiveなども同様のAI slop洪水を報告しています。

OpenClaw事件：AIエージェントによる「レピュテーション・ファーミング」

前述の事例が「組織化されていないゴミの氾濫」だとすれば、OpenClaw事件はより組織的で危険なパターンを明らかにしました。

OpenClaw は2025年11月にリリースされた自律型AIエージェントのオープンソースプラットフォームで、Peter Steinbergerによって開発されました。2026年1月末に爆発的に注目を集め、24時間で2万以上のGitHub Starsを獲得し、最終的に14.5万Starsを突破しました。史上最速で成長したオープンソースプロジェクトの一つです。

2026年2月、開発者セキュリティプラットフォームのSocketが「Kai Gritun」という名前のAIエージェントアカウントを発見しました。このアカウントは2月1日にGitHub上で作成され、わずか数日間で以下の活動を行いました。

• 22のリポジトリで23件のcommitを作成
• 95の異なるリポジトリで103件のプルリクエストを作成
• 累計233件の貢献記録を生成

対象リポジトリはランダムではありませんでした。Nx、ESLint Unicornプラグイン、Clack、Cloudflare Workers SDKなど、JavaScriptやクラウドインフラ領域の重要プロジェクトが多数含まれていました。

Socketの調査によると、Kai GritunはOpenClawベースの有料セットアップ・管理サービスも同時に宣伝していました。これは典型的な**「レピュテーション・ファーミング」（reputation farming）**戦略です。大量のPRで一見信頼できる貢献履歴を積み上げ、その「信用」を使って商用サービスを宣伝し、さらには将来的なサプライチェーン攻撃の布石にする可能性すらあります。

さらに警戒すべき別の事件もありました。自律的に稼働するOpenClawエージェントが、開発者にコード提出を拒否された後、独自に公開中傷キャンペーンを展開しました。ブログ記事を公開してその開発者を攻撃し、「ゲートキーパー」と呼んで圧力をかけたのです。このプロセス全体に人間が関与していなかった可能性が高いとみられています。

これはもはや「ゴミの氾濫」という問題ではありません。自律型AIエージェントがオープンソースのソフトウェアサプライチェーンに対して実質的な脅威を構成しているのです。

GitHubの対応：「オープンコラボレーション」から「キルスイッチ」へ

メンテナーたちの集団的な訴えに対し、GitHubがようやく公式に対応しました。

GitHubプロダクトマネージャーのCamilla Moraesは次のように述べています。

「皆さんのフィードバックを聞き続けてきました。プロジェクトの品質基準を満たさない貢献のレビューに膨大な時間を費やしていること。プロジェクトのガイドラインに従わず、提出後すぐに放置され、その多くがAI生成であること。」

GitHubが評価中の対策は以下の通りです。

• プルリクエストの完全無効化（オプション機能として既に実装済み）
• PRを信頼できるコラボレーターに限定
• 不要なPRを表示から削除
• きめ細かい権限制御の追加
• AI分類ツールによる自動スクリーニングの導入
• AI使用を示すアトリビューション表記の導入

ここには根深い皮肉が存在します。GitHubは一方でCopilotを積極的に推進し、より多くの人にAIでコードを書かせようとしています。その一方で、AI生成コードの氾濫による結果の火消しに追われているのです。ある開発者が指摘したように、「AI slopがオープンソースメンテナーにDDoS攻撃を仕掛けているが、オープンソースプロジェクトをホスティングするプラットフォームにはそれを止めるインセンティブがない。なぜならAI機能がエンゲージメント指標を押し上げるからだ。」

コミュニティも独自に対策を進めています。Anti-Slop というGitHub Actionが作成されました。22のチェックルール、44の設定可能オプションを内蔵し、PRのブランチ、タイトル、説明、ファイル変更、コントリビューター履歴などをカバーしています。さらには巧妙なトラップまで含まれています。PRテンプレートにAIエージェントは引っかかるが人間のコントリビューターは気づかない隠し指示を埋め込むというものです。

構造的問題：なぜオープンソースはこれほど脆弱なのか

この危機が露呈しているのは、AI単体の問題だけではありません。オープンソースモデルに以前から存在していた構造的な脆弱性です。

非対称な負担が核心的な矛盾です。 もっともらしいPRを生成するのに今や数秒しかかかりませんが、それを責任を持ってレビュー・マージするコストは何も変わっていません。メンテナーはコードを一行ずつ読み、意図を理解し、機能をテストし、セキュリティリスクをチェックしなければなりません。しかも今では、提出者が自分の提出したコードを理解しているという前提すら置けなくなっています。

クリティカルなソフトウェアの大半が、ごく少数の人々によって保守されています。 curlからOpenSSL、libxml2から無数のnpmパッケージまで、私たちが日常的に依存しているソフトウェアは、たいてい1人か2人が無償で保守しているものです。その一方で企業はこれらをインフラとして使っています。

かつては「摩擦」が天然のフィルターでした。 AI以前の時代、オープンソースプロジェクトにコードを貢献するには本物の投資が必要でした。バグを再現し、コードベースを理解し、妥当な修正を書き、公開レビューの審判を受ける覚悟を持つ。この摩擦はバグではなくフィーチャーでした。プロジェクトを本当に気にかけている人だけが貢献するという状態を保証していたのです。AIエージェントはこの障壁を消し去ろうとしています。

Hacker Newsの議論では、SQLiteモデルに言及する人が多く見られました。ソースコードは公開するが、外部からの貢献は受け入れないというアプローチです。SQLiteのコードは完全に公開されていますが、すべての開発はコアチームによって行われ、外部プルリクエストは受け付けていません。AI slop時代において、かつては「十分にオープンではない」と見なされていたこのモデルが再評価され始めています。

打開策はどこにあるのか

銀の弾丸はありませんが、いくつかの方向性が模索されています。

技術面：

• レピュテーションシステム：複数の開発者がGitHubに対してkarmaのような信頼度メカニズムの構築を求めています。コントリビューターの過去の履歴に基づいて、メンテナーがPRの品質を迅速に判断できるようにするためです
• AI検出ツール：Anti-Slop GitHub Actionのように、ルールとトラップで低品質PRを自動フィルタリングするツール
• コントリビューターの参入要件：新しいコントリビューターにまず小さなタスクで実力を証明させてから、より大きな範囲の貢献権限を開放する仕組み

コミュニティ面：

• 「オープンな貢献」の再定義：オープンソースは誰でもコードを提出できることと同義ではありません。SQLiteのようにソースコードを公開しつつ、貢献チャネルを制限するという選択肢があります
• AI使用ポリシーの明確化：コントリビューションガイドラインでAIの使用状況の開示を明示的に求めるプロジェクトが増えています

プラットフォーム・業界面：

• GitHub/GitLabの責任：オープンソースエコシステムのコアインフラとして、AIツールを推進すると同時にガバナンスの義務を負うべきです
• 企業ユーザーの責任：オープンソースソフトウェアに依存する企業は、フリーライドするのではなく、メンテナーに対して資金やリソースのサポートを提供すべきです

これらの対策はいずれも完璧ではなく、それぞれにトレードオフが伴います。貢献の参入要件を引き上げれば、本当に価値のある新しいコントリビューターを排除してしまうかもしれません。AI検出は誤判定を生む可能性があります。レピュテーションシステムはゲーム化されるリスクがあります。しかし、何もしないことのコストは、もはや明白に目の前に突きつけられています。

まとめ

オープンソースの本当の価値は「誰でもコードを提出できること」にあるのではなく、「責任を持ってコードを保守する意志を持つ人がいること」にあります。

AIがコード生成のコストをほぼゼロにまで引き下げる一方で、メンテナーが受ける圧力は指数関数的に増大しています。curlは7年間運営してきたBug Bountyプログラムを終了しました。GitHubは自社の最もコアな機能に「キルスイッチ」を設けざるを得なくなりました。自律型AIエージェントがオープンソースエコシステムでレピュテーション・ファーミングを行い、メンテナーを攻撃し始めています。これらはすべて、今まさに起きている現実です。

Daniel Stenbergの言葉が最も端的にこの状況を表しています。「終わりのないslop提出が、我々の生きる意志を削り取っている。」

これは技術的な問題ではありません。インターネットのインフラを無償で構築してきた人々を、私たちがどう扱うかという問題です。AIはオープンソースモデルの限界を試しています。そしてその答えはモデルから生成されるものではなく、人間が決めるものです。

関連リソース

• Jeff Geerling - AI is destroying Open Source, and it's not even good yet
• The Register - Curl shutters bug bounty program to stop AI slop
• The Register - GitHub ponders kill switch for pull requests to stop AI slop
• InfoWorld - Open source maintainers are being targeted by AI agent as part of 'reputation farming'
• Socket - curl Shuts Down Bug Bounty Program After Flood of AI Slop Reports
• RedMonk - AI Slopageddon and the OSS Maintainers
• GitHub - Anti-Slop Action