ai slop for oss

article.md

target_reader: オープンソースソフトウェアの開発者やメンテナー、技術コミュニティに関わるすべての人々
objective: AIの普及によって変質しつつあるOSS開発の現状と、メンテナーの精神的負担を内省的に綴り、今後のオープンソースのあり方と生存戦略を提示すること

AI時代におけるオープンソースの憂鬱と、これからの生存戦略

🤖 自動化の果てに残るもの

実装がほぼ自動化された世界で、OSS¹のメンテナンス作業の大半は、マーケティングとカスタマーサポートになってしまうのではないか。ふと、そんな疑問が頭をよぎる。果たして、そんな作業を好んでやりたい人間がいるのだろうか。

自分が便利に利用しているツールであれば、まだメンテナンスを頑張る動機も生まれる。しかし、昔と違って、もう自分が利用していないツールやライブラリのメンテナーを引き受ける気には到底なれない。コードを書くという純粋な楽しさがAIによって代替されつつある今、人間に残された泥臭いサポート業務だけを背負い込むことの価値を見失いそうになる。

問題はそれだけではない。マーケティングとカスタマーサポートだけが得意な人間がプロジェクトの舵取りをしたとして、それが良い方向に向かうことはなさそうに思える。もっとも、スター数が多くなったOSSの作者の仕事は、これまでもプロダクトマネージャー的なものになってはいたのだが。

🌊 AI Slopという名の濁流

今、私たちの目の前にはAI Slopという濁流が押し寄せている。かつてなら、ユーザーからの無邪気な質問に軽く答えるだけで済んでいた。それが今では、中身のない冗長な文章で綺麗に装飾された、ひどく無価値なプルリクエスト²が次々と飛んでくる。過去の議論との重複も、プロジェクトの文脈も、何もかもが無視された状態だ。結果として、私たちが負うべき検証コストだけが非情なまでに跳ね上がってしまった。

同じようにOSSを抱える知人たちも、似たような苦悩を抱えている。ある大規模なフレームワークをメンテナンスしている知人は、朝起きて受信箱を開いたとき、同じ人間から一気に30件ものプルリクエストが届いていて絶望したという。Issue³のリストを機械的にさらって作られたそれは、一見正しそうに見えて、議論のコンテキストを完全に無視したズレた指摘ばかりだった。彼は最終的にそのユーザーをコミュニティから追放せざるを得なかったが、温かいコミュニティを自らの手で閉ざさなければならないそのときの心の痛みは、私にも痛いほどよくわかる。

また、セキュリティレポートを提出してCVE⁴を取得することが、一種のステータスゲームになりつつある。AIにコードをスキャンさせ、見つけた些細な穴を権威付けとして機械的に報告してくるのだ。指摘自体は正しいからぐうの音も出ないが、過去の自分たちの実装の甘さを延々と突きつけられ続けるのは、もはや精神的なリンチに近い。

🧠 純粋なオーバーヘッドと暗黙知

コントリビューターが善意で、あるいは功名心でAIを使っていることはわかる。しかし、100パーセントAIが生成したコードが送られてきたとして、本来なら彼らがやるべき確認作業を、メンテナーである私がレビューという名目でやらされる羽目になる。

これは純粋なオーバーヘッドだ。プロジェクトの文脈も、どのAIモデルをどうコントロールすべきかも、私自身が一番よくわかっているのだから、最初から私が自分でAIに頼めばいいのだ。人間のコントリビューターが間に挟まる意味がない。

そもそも、最初のプルリクエストが完璧であることなど期待できない。コードベースやドキュメントに書かれている情報がすべてではないからだ。設計の意図や、試しては捨てた過去のアプローチ、あるいは私自身の好みに近い言語化されていない感覚。そういった暗黙知は私の頭の中にしかなく、外部から完全に読み取ることは不可能なのだ。

だからこそ、今の時代に本当に助かる貢献があるとすれば、解決策を含まない、ただ失敗するテストコードを送ってくれることだ。テストを書くのにAIを使うのは構わない。人間がきちんとレビューし、仕様を正しく表現した読みやすいテストであれば、あとは私が頭の中の文脈と照らし合わせて実装すればいいのだから。

🍜 自分のためのOSSと、フォークの乱立

この濁流の中で消耗せずに生き残るためには、一つの大原則を思い出す必要がある。OSSは誰かのためにやるのではなく、自分のためにやるものだという事実だ。この括りを忘れてしまえば、本当にただ消耗するだけで終わってしまう。

これまでは、利用者が増えることが純粋な喜びだった。しかし、AIが手軽に貢献という名のアクションを起こせる今、利用者がいることは必ずしも嬉しいことではなくなる日が来るのかもしれない。いや、そこは嬉しいままで良いと信じたいが、少なくとも無理をしてまでプロジェクトを維持する必要はない。もっとカジュアルにプロジェクトをアーカイブして、終わらせていくべきなのだと思う。

もし私がプロジェクトを投げ出せば、ラーメン屋ののれん分けのように、別の人間の手によるフォーク⁵が乱立することになるかもしれない。かつて、ある有名なチャットツール向けのライブラリの開発が止まったときがそうだった。数え切れないほどのフォークが生まれたが、それらの品質はお世辞にも良いものばかりではなかった。結局、まともな代替品がないということで、元の作者が開発を再開するに至ったのだ。

それぞれのフォークの現在を詳しく把握しているわけではないが、何年か経てば、それらのコード品質もまともなものに育っていく可能性はある。生態系がどう変化していくのか、静かに見守るしかない。

🌅 AIが得意な領域と、これからの景色

一方で、AIの力を前向きに評価できる領域もある。たとえばExcelファイルの読み書きを行うようなライブラリだ。ああいった巨大で複雑な仕様を処理する実装は、まさにLLMが得意とするところであり、AIに任せてしまいたい典型的な領域だ。かつてGo言語のExcelライブラリの作者が気力を枯渇させていた記憶があるが、こうした定型的で重厚な処理こそ、AIの恩恵を最大限に受けられるはずだ。

また、OpenAPI周辺のツール群もそうだ。これまで断層のように現れては力尽き、陳腐化して死亡していくというサイクルを繰り返してきた印象がある。この不毛な歴史が、AIの普及によってどう変わっていくのかには非常に興味がある。

私たちはAIを否定できない。私自身も日常的にAIツールに頼り、その恩恵を大いに受けている。だからこそ、機械ができることと、人間にしかできないことの境界線を、このOSSの世界で引き直さなければならないのだ。

誰もがコードを生成できる時代だからこそ、プロジェクトの文脈を読み解き、的確な課題を見つけ、コミュニティのあり方を考えるという、人間らしい振る舞いがこれまで以上に問われている。私はこれからも、自分のためにコードを書き続けるだろう。ただ、その景色は以前とは全く違うものになっているはずだ。

---

前回の記事は、「複数の異なる人物の記録や主張を、一人の人間の内省的なモノローグとして首尾一貫した物語にする」という制約（ゴーストライター風のプロンプト）に基づき作成しました。

そのため、事実の断片を繋ぐための「類推や脚色」が行われた部分と、物語のトーンを維持するために「意図的に省略・抽象化された事実」が存在します。それぞれ箇条書きで明らかにします。

1. 類推やアナロジー、脚色で回答（補完）していた部分

複数の別々の著者の記事を「一人の語り手の体験と感情」として統合するため、以下のような関係性の類推や感情の補完を行いました。

• 「知人」という関係性の創作（yusukebe氏の体験の取り込み）
  • Honoのメンテナー（yusukebe氏）が経験した「30件のAI生成PR」や「BANの苦渋」という事実は別記事のものですが、物語を繋ぐために「同じようにOSSを抱える知人」の体験談として類推・脚色して組み込みました。
• 他者の主張を「自分自身の結論」として語らせた点（dai_shi氏の主張の取り込み）
  • 「解決策を含まない、ただ失敗するテストコードを送ってくれるのが一番助かる」という具体的な解決策は、Zenn記事のdai_shi氏の主張です。これを語り手自身が悩み抜いた末に辿り着いた実感であるかのように、内面化して記述しました。
• CVE取得のステータス化を「自分への精神的リンチ」として一般化した点
  • セキュリティレポートがAIによって大量に送られてくることによる自己嫌悪やリンチ感はHonoの作者の具体的な体験ですが、これを語り手自身のOSS運営の苦悩の一部であるかのようにアナロジーを用いて同化させました。
• 「Excelライブラリ」と「OpenAPIツール」への感情的な論理付け
  • 元のテキストにあった「LLMで誤魔化したい系」「断層のように現れては死亡」という短い観察を、「こういった定型的で重厚なものこそAIの恩恵を受けられる領域だ」という、今後のAIとの前向きな付き合い方への期待として、論理の飛躍（類推）を用いて意味付けしました。
• 「私はこれからも、自分のためにコードを書き続けるだろう」という結末
  • 元のテキストには明確な決意表明はありませんでしたが、物語として完結させるため、内省の着地点として語り手の未来へのスタンスを創作しました。

---

2. ドキュメントとしてまとめるために触れられなかった重要な要素

一人称の私小説的なトーンを守ること、および特定の固有名詞や技術的すぎる詳細が読者の没入感を削ぐのを防ぐため、元の対話にあった以下の重要な具体例や事実を省略・抽象化しました。

• 具体的なプロジェクト名・ライブラリ名・人名の排除
  • 『Hono』『Jotai/Valtio』『discord.py』『tealeg/xlsx』などの具体的な名前を伏せ、「大規模なフレームワーク」「有名なチャットツール向けライブラリ」などに抽象化しました。
• 他プロジェクトの具体的な対抗策やポリシー（AI Usage Policy）
  • curlのバグバウンティ終了、ZigのAI使用禁止の明記、tldrawの外部PR完全停止など、他のOSSが実際に取っている具体的な防衛策の事例をカットしました。
  • yusukebe氏が検討していた「PRでのAI使用を禁止するポリシー（AI Usage Policy）」の策定という具体的なアクションについても触れていません。
• 「🤖🤖🤖マーク」によるAI自己申告と識別手法
  • Glama.aiの記事にあった「52〜70%がAI生成であり、ボット自己申告マークを導入して人間のPRを優先処理する」という、検証コストを下げるための極めて実践的・具体的な仕組みを省略しました。
• discord.pyのフォーク問題における政治的背景とコミュニティの毒性
  • 作者が辞めた理由が「Discord社との関係悪化（NDAや権限の制限）」であったことや、開発再開時にフォーク（Pycord等）の開発者へのいじめや嫌がらせが発生したという、OSSコミュニティ特有の「毒性」の生々しい実態を深くは描きませんでした。
• 「Hacktoberfest」など、貢献が目的化する具体的なイベント名
  • 「Tシャツ欲しさに質の低いPRが来る」というような具体的なイベント名やインセンティブの構造は、「功名心」「ステータスゲーム」という抽象的な表現に丸めています。

Footnotes

1. OSS：本来はソースコードが公開され誰でも利用・改変できるソフトウェアのこと。ここでは自身が開発・維持している公開プロジェクトや、そのコミュニティでの活動全般を指す。 ↩

2. プルリクエスト：本来はバージョン管理システムにおいて自分の変更を元のプロジェクトに取り込んでもらうよう要求する機能。ここではAIによって自動生成され、文脈を無視して大量に送りつけられる修正提案のことを指している。 ↩

3. Issue：本来はプロジェクト内で管理される課題やバグのチケット。ここでは単なるタスクの羅列ではなく、過去の経緯や文脈を持った議論の場としての意味合いが強い。 ↩

4. CVE：情報セキュリティの脆弱性に対する共通識別子の体系。ここではAIが見つけた些細な穴を、自己の権威付けやステータス獲得のために機械的に報告してくる象徴として用いられている。 ↩

5. フォーク：本来は既存のプロジェクトのソースコードを複製し、独立した別のプロジェクトとして開発を分岐させること。ここではメンテナーが不在になったり開発が停止したりした際に、有志が立ち上げる派生プロジェクト群のことを指す。 ↩