【#も読】OSSメンテナの憂鬱 ―― “AI Slop”がもたらす疲弊（@yusuktan）

「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？

みなさんこんにちは。

「あの人も読んでる」、第15回目の投稿です。maguro (X @yusuktan)がお届けします。

今回のタイトル「OSSメンテナの憂鬱」は、Honoの作者であるyusukebeさんの講演「OSS開発者の憂鬱」へのオマージュです。

AIエージェントの普及と性能向上により、コードを書くハードルは劇的に下がりました。GitHub Copilot、Claude、ChatGPTなどを使えば、プログラミング初心者、あるいは対象のコードベースに対して知識があまりない状態であっても、それなりに動くコードを生成できます。しかし、この「民主化」がオープンソースの世界に思わぬ副作用をもたらしている、ということが最近表面化してきたように思います。

今回は、OSSメンテナたちが直面しているAI Slop^[1] 問題について、いくつかのOSSプロジェクトを取り上げながら見ていこうと思います。

ケース1 curl：バグバウンティ終了

2026年1月、多くの人がお世話になっているであろうコマンドラインツールの1つであるcurlのメンテナ、Daniel Stenberg氏がバグバウンティプログラムの終了を発表しました。

AI生成による質の低いバグレポートが増えたことによる負担増が原因とされています。Stenberg氏によると、直近の1週間だけで7件の報告があり、そのいずれも実際の脆弱性を示すものではありませんでした。それぞれの報告を精査するのに「相当な時間」がかかったといいます。

Stenberg氏は次のように述べています。

you should NEVER report a bug or a vulnerability unless you actually understand it – and can reproduce it.
（バグや脆弱性を報告するなら、それを実際に理解し、再現できなければならない）

バウンティを終了することで、「十分に調査されていないレポートを送るインセンティブを取り除きたい」というのが彼の狙いです。金銭的報酬がなくなれば、本当に問題を理解している人だけが報告してくるだろう、ということが期待されています。

ケース2 GNOME Shell Extensions：レビュー負荷の増大

GNOME Shell Extensionsのレビューチームも同様の問題に直面しています。開発者のJavad Rahmatzadeh氏は、2025年12月のブログ記事でAI生成コードによる問題を詳しく報告しています。

典型的な例として、以下のようなコードパターンが挙げられています。

destroy() {
  try {
    if (typeof super.destroy === 'function') {
      super.destroy();
    }
  } catch (e) {
    console.warn(`${e.message}`);
  }
}

本来であれば super.destroy() の1行で済むところを、AIが「念のため」と言わんばかりに不必要なエラーハンドリングを追加しています。このようなパターンが提出される拡張機能全体に蔓延し、レビュー時間が大幅に増加したとのことです。

Rahmatzadeh氏は次のように指摘しています。

Some devs are using AI without understanding the code. This has led to receiving packages with many unnecessary lines and bad practices.
（一部の開発者はコードを理解せずにAIを使っている。その結果、不必要な行やバッドプラクティスを含むパッケージを受け取ることになった）

結果として、GNOME Shell Extensionsのレビューガイドラインには、「Extensions Must Not Be AI Generated」というルールが追加されました。具体的には、大量の不必要なコード、一貫性のないコードスタイル、存在しないAPIの使用、LLMプロンプトとして機能するコメントなど、AI生成の兆候を示す拡張機能は明示的にリジェクトされます。

ただし、Rahmatzadeh氏はAIそのものを否定しているわけではありません。

This doesn't mean you cannot use AI for learning or fixing some issues. AI is a fantastic tool for learning and helping find and fix issues.
（これは学習や問題修正にAIを使ってはいけないという意味ではない。AIは学習や問題の発見・修正を助ける素晴らしいツールだ）

あくまで真の問題は、AIを「コードのことを理解せずにただただ生成するツール」として使うことにある、というスタンスです。

ケース3 Ghostty：低品質なAI生成は一発BAN

最近、Claude Codeとの相性の良さにより注目されているターミナルエミュレーターGhosttyが、2026年1月23日、AIを用いたコントリビューションについてのポリシーを更新しました。

作者のMitchell Hashimoto氏は、更新の背景をこう説明しています。

The rise of agentic programming has eliminated the natural effort-based backpressure that previously limited low-effort contributions. It is now too easy to create large amounts of bad content with minimal effort.
（エージェント型プログラミングの台頭によって、低品質な貢献を自然に抑制していた「労力という障壁」が消え去った。最小限の労力で大量の低品質コンテンツを作ることが、あまりにも簡単になってしまった）

更新後のポリシーの要点は以下の通りです。

• AI生成のコントリビューションは、承認済みIssueとメンテナに限り許可される。事前のIssueなしに投げられるdrive-by PR (通りすがりのPR)は即座にクローズされる
• 低品質なAI生成コンテンツを提出したユーザーは即座にBANされる。一発アウトであり、AIを使うならその品質に責任を持たなければならない
• 学習目的のジュニア開発者は歓迎する。AIを脇に置いて自分で考え、努力する姿勢があれば喜んでサポートする

This is not an anti-AI stance. This is an anti-idiot stance.
（これはアンチAIの立場ではない。アンチ愚か者の立場だ）

Ghosttyの開発チーム自身はAIを日常的に活用しており、ポリシーの目的は「AIを禁止する」ことではなく「低品質なPRからプロジェクトを守る」ことにあると強調されています。

さらに、ポリシーの更新からほどなくして、2026年2月3日、Mitchell Hashimoto氏はさらに踏み込んだ方針を検討していることをX上で表明しました。

I've been doing open source since I was a teenager (over 20yrs). And for the first time ever, I'm considering closing external PRs to my OSS projects completely. This will throw the baby out with the bathwater and I hate that, but we close auto-opened slop PRs every single day.
（10代の頃から20年以上オープンソースに携わってきましたが、今、初めて自分のOSSプロジェクトへの外部からのPRを完全にクローズすることを検討しています。これは、貴重なものまで切り捨てることになり、本当に不本意です。しかし、実際には自動で作成された品質の低いPRを毎日クローズする作業に追われているのが現状です。）

AI Slopによる負担増が許容できる範囲を超え、外部からのPRを「すべて」クローズするという強硬策を検討せざるを得ないレベルに達していることが読み取れます。極めて危機的な状況です。

ケース4 Zig：最も厳格な「No AI」ポリシー

プログラミング言語ZigのCode of Conductでは、厳格な「No AI」ポリシーが掲げられています。

No LLMs for issues.
No LLMs for pull requests.
No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.
（issueにLLMを使うな。PRにLLMを使うな。バグトラッカーへのコメントにもLLMを使うな、翻訳であっても。英語が推奨されるが必須ではない。母語で投稿してよい。他の人が自分の好きな翻訳ツールであなたの言葉を解釈するだろう）

IssueやPRのみならず、バグトラッカーにコメントをするときの翻訳のためにすらLLMを使うな、という姿勢は、他のどのOSSプロジェクトよりも厳格で、際立っています。

この「No AI」ポリシーと、最近のGitHubが推進しているCopilotとの統合が相容れないということが理由の1つになり、2025年11月にはGitHubからCodebergへの移行が行われました。

Denoでも聞こえ始めた声

さて、さまざまなOSSプロジェクトがどのようにAIと向き合っているかを見てきましたが、実は僕が働いているDeno Land Inc.でも、同様の声が聞こえ始めています。

僕自身はDenoのOSSチームに直接所属しているわけではないのですが、OSSチームのメンバーから「AIにより生成されたと思われるコントリビューションのうち、半分くらいはレビューするだけ時間の無駄だと感じる」という話を聞きました。近いうちに、Denoでも何らかのAIポリシーが採用されるかもしれません。

おわりに

AIコーディングツールは、正しく使えば開発者の生産性を大きく向上させる素晴らしいツールです。僕自身も日常的に活用しています。しかし、「AIが生成したコードをそのまま提出する」という使い方は、OSSエコシステムに大変な負担をかけはじめています。

コントリビューターとして心がけたいのは、AIを使うにしても、最終的に自分が理解し、説明でき、責任を持てるコードだけを提出するということ。ほとんどのOSSプロジェクトでは、Ghosttyのポリシーでも明文化されている通り、「AIをいったん脇にやって、努力し学習する意欲のあるジュニア開発者の貢献は歓迎される」はずです。

また次回、おすすめコンテンツを紹介していきます。お楽しみに！

maguroさんの「も読」過去記事

• なぜApache IggyはTokioを捨てたのか、なぜMicrosoftはRustに賭けるのか(1月12日公開)
• JSConf、YAPC、HonoConf――カンファレンスの秋を振り返る(12月9日公開)
• 初心者と熟練者、同じ5行のコードを見た時の視界の違い(9月19日公開)