OSSにおけるAI Slop問題の何が問題なのか？
Honoは2021年の12月に開発が始まって4年と少し経つ。たぶん、あなたが想像する以上に大きくなっている。GitHubのスターは現時点で29.2K。これは日本人発OSSで観測する限り第3位の数字だ。最近ではMCP公式SDKの依存に入り、ダウンロード数はうなぎのぼり。月間1億ダウンロードが近い。Cloudflareは多くのプロダクトでHonoを使っている。
これだけ大きな規模のOSSに、クリエーター、もしくはメンテナとして関わることは非常に貴重な経験である。そこにはみなさんが見ていない景色が広がっている。
Honoの開発において「憂鬱な」こともたくさんある。ただ、それを上回る楽しいことがある。そうやって相殺してきた。ところが最近、4年間で一番憂鬱なタイミングきている。俗に言うAI Slop問題である。
今回は、OSSにおけるAI Slop問題について、実体験を元に何が問題なのかを語ってみたい。
1. OSS開発者の憂鬱
「OSS開発者の憂鬱」については去年11月のYAPC::Fukuoka 2025で話した。
つまり憂鬱とはこうだ。
- 色んな人がいる
- 登山すれ違い問題
- バグが再現できない
- バグと言いつつバグじゃないことが多い！
- Whyを聞かれるのが辛い
- Noを言うには体力がいる
- 嫉妬される
- 政治に巻き込まれる
- 悲しい発言
内容が内容なのでトークの準備をしているときは辛かったことを思いだす。だけども的を射ている。例えばレビューが多いのは、OSSに限らずどこでもききそうな悩みだが、Honoにおいては国籍、人種、年齢、目的⋯バラバラな人から突然IssueやPRがやってくる。これがOSSならではの問題だ。
憂鬱はAI以前から存在していた。根本はまさしくここにある。憂鬱は「もうすでに」あったのだ。それがAIによって加速した。
2. AI Slopとは？
Slopとはそもそも「汚水」「残飯」を意味し、これが「AI Slop」として使われると、AIによって生成された大量の低品質なもの、みたいな意味だ。それがOSSのコンテキストで使われるとどうなるか？はmaguroさんの以下の記事によくまとまっている。
AI Slopという言葉をたくさん使ったのは先日のデブサミだ。「AI時代にフレームワークは必要なのか？」という題材でwatanyさんとsyumaiさんとパネルディスカッションをした。
当初はもう少しマイルドな内容になると思いきや、HonoにおけるAI Slop問題のことばかり話した。結果的に「隣の会場ではAIバンザイみたいな話をしてると思いますが、こちらの会場では現実的な（辛い）話になりましたね」と終わった。その様子はモーリさんのレポートに掲載されてる。
3. 何が起きているか？
AI Slop問題で何が起きているのか？簡単に言うと、AIで作った低品質なIssueとPRが増えている。それによりメンテナが疲弊しているというものだ。この現象は大きなOSSライブラリで顕著だ。もしくは、大規模でなくては出現しない事柄かもしれない。
いくつかのライブラリではいち早くその問題に気づき、対応をしている。maguroさんの記事から引用するにたとえばこうだ。
- curl - 低品質なバグレポートの増加をうけバグバウンティ終了
- GNOME Shell Extensions - レビュー負荷の増大をうけ、AI生成の兆候を示すものはリジェクト
- Ghostty - ポリシーを改定し低品質なAI生成は一発BAN
- Zig - ポリシーにIssue、PRにLLMを使うな、と強く記載
こうした問題は遠くの場所で起こっているもので、我々には関係のない。そう思っていたのだが⋯。衝撃的だったのが1ヶ月前。朝起きてGitHubのInboxを眺めたら驚いた。同じ人からAIが作ったと見られるPRが30個来ていた。
以前から、AIが生成した「重厚なdescription」のPRが増えてきたなーと思っていたのだが、これが決定的だった。我々はAI Slop問題に直面した。
4. 何が問題か
では、何が問題なのか？そりゃあ「問題」といってるんだから問題だろうが、ここにはHonoのメンテナだからこそ知れることがある。
レビューコスト
まずは分かりやすいところから。レビューに割かなくてはいけない時間が絶対的に増えた。PRの量が増えるだけじゃなく、内容も「重厚」になった。descriptionが綺麗に章立てされ、時には箇条書きや表まで付けてくる。絵文字も入る。一見丁寧だが明らかにAIが書いたもので嫌気が指す。
AIが書いたPRだからといって、レビューをしないわけにはいけない。「レビューもAIにやらせればいいじゃん」。そう簡単には収まらない。
一見コードが正しそうでもIssueのコンテキストを無視する場合が多々ある。先程の30件のPRは（おそらく）プロジェクトにあるIssueを一気にさらって、AIがそれをFixするために大量生成されたもので、こうした場合に多い。対象のIssueの流れを全く無視してズレてる指摘をしている。
以下はそのようなPRに対してコメントをしている。
バンしなくてはいけない
30件の例はさすがにブチ切れた。ありゃスパムだ。AIに30件のPRを作らせて、それだけでもイライラするのに、一見正しそうで指摘はズレてる。
このあとバンした。
OSSには人間がいる
今まで「貢献」してくれる人に感謝して、楽しくやっていた。憂鬱なことがあっても、なるべく努力して受け入れようとしていた。あえて「コミュニティ」なんて言葉を自ら使わなくても、それは温かいコミュニティになった。去年の10月にはHono Conferenceをやって200人弱が集まった。
それがだ。そんな温かいものに触れていたのが、PR作者をバンした。そりゃその人はいけないことをしているし、Code of Conductにも違反している。バンされるべきかもしれないが、心が痛む。本当に痛む。
OSSのモデルはただ正しいソフトウェアをつくる場ではない（正しいソフトウェアをもくもくと正しく作るだけなら、超外向的な自分はそのオーナーとして向いてないと思う）。OSSは、少なくともHonoの場合は、コントリビュータ、そしてユーザーという「人」がいてこそ成り立つものだと思っていた。
貢献が目的になってはいけない
AI SlopなPRを作るモチベーションはどこからくるのか？この問題はAI以前から存在していた。「貢献」だけが目的になったらいけない。
分かりやすい例がHacktoberfestだ。これはGitHubにコントリビューションしたらT-shirtsを貰える権利をくれるというもの。うまく作用することもあるが、モチベーションが「T-shirtsが欲しい」だけだとPRの品質は確実に下がる。重箱の隅をつつくようなFixもあれば、リファクタリングだけのものもある。無駄なテストを追加するだけのもの。先程話した通りIssueの流れを無視したただのFix。
そもそも、それらのPRの作者は本当にHonoを使っているのか？や、使っていたとしても本当に困っていたのだろうか？
これまでPRを作れなかった人がAIでコードを書けるようになると、こうした貢献だけを目的としたPRが目出すようになる。
ちなみに、よくある「OSSにコントリビューションしましょう」というキラキラした感じ。あれも同じような理由で好きではない。ドキュメントのタイポはノールックでマージできるけど、無理に貢献しなくていい。
また、GitHubの右側にはコミット数に応じてコントリビュータが表示される。大きなOSSになるほどこれはステータスなのだが、こうしたコミットでここに登場しちゃうのはなんか違う気がする。
ぐうの音がでない
Hacktoberfestはカジュアルな例だったが、「CVEのレポーター」になることが権威になってしまっているのが恐怖だ。セキュリティレポートが格段に増えた。Honoのリリースノートを見てもらうと分かるが、最近は脆弱性のFixが多い。レポートには明らかにAIが作ったものもある。推測するに、コードなりをスキャンをして、穴を見つけてるんだろうね。「CVEを取る」ことはそれなりに自慢できることだから、そりゃやるよね。
Honoから脆弱性が消えるのはいいことだ。とはいえやっぱり疲弊する。特にセキュリティに関わることである。指摘が正しければぐうの音も出ない。過去の自分たちの実装に穴があったことを認めなくてはいけない。「あの時のレビューが甘かったな」とか振り返る。CVSSのスコアを下げたくもなる。これは精神的にかなりくる。さらに見え方の問題もあるから、リリースのタイミングやレポートの記述を工夫しなくてはいけない。そんなレポートがAIからたくさんやってきて、人間は疲弊する。時たまリンチにあってる気分になる。
AIを否定できない
だからといってAIを否定できない。これが問題たらしめている。
そもそも自分もAIを使っている。Claude Codeと一緒にレビューしている。もうなくてはならない。AIは素晴らしい！
世の中は（少なくとも僕のタイムライン上では）「AIを使いこなす」話題ばかり。一方で僕はAIにリンチされている。これはFOMOどころではない。
AIでもっと楽しいことをしたい。
孤独
この問題を実体験として共有できる人はものすごく少ない。大規模OSSのメンテナである必要がある。Honoを一緒にやってるusualomaさんとはこの話題を共有してるんだけど、なかなかいない。
「OSS開発者の憂鬱」に何が価値があるかと言うと、これほど大きなOSSのプロダクトオーナーになれる人は非常に少ないわけということ。だから逆に言えば、孤独なわけだ。
5.どうするか
じゃあどうするか。目を瞑っていたけど、そろそろ対策を打たないといけない時がきた。
例えば「AI Usage Policy」を作ろうと思っている。ポリシーは一度言ったら変えにくいものなので、慎重にいきたい。いくつか方針の候補を考えているところだ。その一つは、PRはAI禁止にするというもの。
わざわざ見知らぬ人がAIでコードをPRで書かなくてもいい。AIでコードを書くのはメンテサイドでもできる。
他のプロジェクトの例だと、tldrawは外部からPRを受付なくした。
また、Cloudflare Agentsのプロジェクトでは外部からのPRを受け付けていない。そのくらい極端なことを考えてもいいと思えてきた。
6. まとめ
以上、OSSにおけるAI Slop問題をHonoの実体験を元に紹介してきた。
OSSが、特にGitHub登場以降、PRをベースとした「貢献」でOSSが育ってきたのならば、OSSのあり方が変わると思う。
どう変わるのかわからない。あんまり考えたくないってのが正直なところで、これは「サンクコストを捨てきれていないAI時代に適応できてない虚しい人間の性」かもしれない。なんて思うけど、それだけじゃない気がする。前を向いていかないといけない。OSSのメンテナンスは続く。
Discussion
AIを使ってコントリビュートする場合は利用したモデルとプロンプトのみを記述して貰うのが良いのでは？
そもそも自動生成物をレビューするプロセスを維持するよりプロンプトと利用したモデルだけ教えて貰えば再現性もあるし、今後の機能追加の場合も同じプロンプトでの処理が必要か判断できるますし…
プロンプトでフィックスできるならCI入れられますし…
AI slop問題に対して『ユーザを啓蒙する』は、一切の解決策になりません。
なぜなら、AI slopを産み出す側は注意書きなど読まないからです。
ユーザーを啓蒙するなんて一言も書いていません。
GitHubにアカウントBAN機能は(まだ)ないと思うのですが、これは何処のことを表しているでしょうか。
(Organizationに対しての) Blockのことです
おお、プロジェクトではなくユーザにそんな設定があったんですね。
ありがとうございます。
メンテナが作ったカスタムプロンプトでレビューさせたらどうでしょうか？
提案のレビュー これはAIがやる
レビューのレビューを見る これを人がやる
実現できるのかはわかりませんが、同時に出せるPRを1人1つにして、ホワイトリストに登録した人は無制限に出せるってのが落としどころかなあと思います。
コントリビューターとして経験が全くない自分が初挑戦をするという状況で、AIに頼り切りにならずに自力でPRを作るとしたら時間がかかるので、一つまでという制限は初心者の貢献するモチベーションを下げることには繋がらないと思います。
PR や Issue の description の文字数を制限したり、1コミットあたりのコードの変更行数を制限するのはどうでしょうか?
AI の出力したテキスト (コードを含む) のレビュー負担が重い原因として、出力の文量が大きすぎることが一因としてあるような気がしています。
実装としては、コントリビューターが Issue や PR を作成・変更したタイミングで GitHub Actions を回して、文量や1コミットあたりのコード変更量が多い場合は、ラベルの付与と「文量減らしてね」「読みやすくコミット分けてね」「修正されるまでレビューしないよ」というコメントを付ける形を想定しています。
別の方のコメントを見て気が付きましたが、許可リストで特定のコントリビューターだけ制限を外せるようにしておいた方が良さそうですね。
ただ、この方法の懸念点として、GitHub Actions の課金額が増えないか、という点がありますが…
私は殆ど PR の来ない小さな OSS しかやったことがないので、的外れだったらすみません。