オープンソース
今日のPRスパムは2000年代初頭のEメールスパムに似ている
PR spam today looks like email spam in the early 2000s (greptile.com)
要約
本記事は、GitHubのリポジトリ「OpenClaw」におけるプルリクエスト(PR)の急増を分析し、AIエージェントが生成する低品質なPRが2000年代初頭のEメールスパムと類似していると指摘しています。PRの品質低下はオープンソースプロジェクトの多様性を損ない、今後は送信者のレピュテーションシステムや、コードベースの深い理解を要する貢献がより重要になると論じています。
全文翻訳
私はRahulで、GreptileでプルリクエストをレビューするAIエージェントを構築しています。GreptileはOpenClawのPRをレビューしており、OpenClawはGitHub史上最速で成長したリポジトリになりました。これにより、私たちは奇妙な現象を目の当たりにしました。昨年12月、OpenClawは週に2件のプルリクエストを受け取っていましたが、2月にはその数が週に3,400件に急増しました。スパイク前はPRの約48%がマージされていましたが、その後は9.3%未満に減少しました。これらのPRの多くは、人々のAIコーディングエージェントによって生成された、質の低い雑多なものでした。例えば、あるコントリビューターは1日に106件のPRを提出し、提出間の平均時間は3秒でした。多くの点で、openclaw/openclawは、オープンソースへの貢献の未来がどのようになるかのプレビューを提供しています。ここに3つの観察結果があります:
PRには送信者のレピュテーションが必要になる
今日のPRスパムは、2000年代初頭のEメールスパムに似ています。OpenClawのデータを見て最初に気づいたのは、そのパターンがEメールを連想させることでした。2000年、ILOVEYOUワームは24時間で4500万台のコンピューターに感染しました。これはEメール送信のコストがほぼゼロになり、人々がプラットフォームを信頼していたためです。その結果、人々ははるかに大量のEメールを受け取るようになり、その中には悪意のあるものも含まれていました。今日のPRにも同じパラメーターが当てはまります。最初の対策も似ています:ボリュームを管理するためのブロックリスト、悪意のあるアクターを捕捉するための信頼ベースのフィルターとレピュテーションインフラストラクチャ。今日、あなたのEメールが受信者の受信トレイに届くかどうかは、2つのことに帰着します:あなたが誰であるか、そしてあなたの送信履歴です。OpenClawのコントリビューターはすでにそのレピュテーションによってフィルターされています:初回参加者は8.2%のマージ率、2〜5件のPRを持つコントリビューターは10.3%、5件以上のコントリビューターは18.6%です。
Mitchell Hashimotoは、最も人気のあるオープンソースのターミナルエミュレーターの1つであるGhosttyを作成し、維持しています。プロジェクトが勢いを増すにつれて、AIが生成した質の低いPRが大量に提出されたため、彼はAIが生成した貢献を制限する必要がありました。1週間後、彼は解決策を発表しました:Vouch、オープンソースコントリビューターのための信頼管理システムです。Vouchされていないユーザーは貢献できず、悪意のあるアクターは明示的にフラグ付けされます。Vouchは今のところプロジェクト固有ですが、Mitchellのビジョンは、信頼の決定が最終的に同じ価値観を共有するプロジェクト全体に波及することです。Vouchは、送信者レピュテーションスコアのオープンソース版です。(注目すべき点:VouchはGhosttyでうまく機能していましたが、MitchellはGhosttyをGitHubから外すことを決定しました。)
多くのコントリビューターが同じ考え方をするなら、彼らが増えても助けにはならない
Linus Torvaldsには有名な言葉があります:「十分な数の目があれば、すべてのバグは浅い(見つけやすい)」。同じ問題に多くの目を向けることは、多様な視点をもたらします。異なる人々は異なる方法でソフトウェアを使用し、異なるバグに遭遇し、新しい方法で修正に取り組みます。しかし、誰もがClaude / Codex / Cursor / Devinなどに収束する場合、そのルールは当てはまらないかもしれません。OpenClawでは:
4人のコントリビューターが「feat(web-search): add SearXNG as a search provider」という全く同じタイトルでPRを提出しました。彼らは、同じ機能を独立して追加しようとした10人以上のうちの4人でした。
6人が独立して同じBrave Searchのロケールバグを修正しました。2人が94分間隔で同じタイトルのPRを提出しました。
5人が独立してエージェントランナーで同じタイムアウトデッドロックを発見しました。
OpenClawにはこれまで以上に多くの目が向けられていますが、彼らの視点もAIコーディングエージェントによってフィルタリングされています。ほとんどのコントリビューターが同じAIコーディングエージェントを同じプロンプトで使用する場合、彼らの貢献も互いに似たものになるでしょう。オープンソースの約束と利点は、思考の多様性でした。Linusの法則は、基礎となる思考が多様であり続ける場合にのみ成り立ちます。コードベースを真剣に研究するコントリビューターは、そうでないコントリビューターとは異なるプロンプトを作成するでしょう。
実際にマージされているもの
OpenClawのPRデータでは、機能(features)のマージ率は9%ですが、リファクタリング(refactors)は35%でマージされています。既存のコードベースの深い理解を必要とする貢献は、新しい機能の貢献をほぼ4倍も上回っています。これは最近よく言われることですが、タイピングよりも思考がはるかに重要です。データがそれを裏付けています。例えば、claude-memがClaude Codeのフックでキャプチャされたツールストリームを自身の再開可能なAgent SDKオブザーバーセッションにマッピングする方法は、両方のシステムに対する深い理解を必要とする、自明ではないアーキテクチャ上の選択です。この決定を理解したソフトウェア開発者は、それをチェックリストにまとめ、それがエージェントの出力を大幅に向上させるプロンプトとなるでしょう。「メモリシステムを構築する」と促されたエージェントは、それ自体ではそれを達成できません。
200年前までは、建物を設計する人々が同時にそれらを建設していました。彼らはマスタービルダーとして知られていました。建設が進むにつれて、その役割は建築と建設という2つの職種に分かれました。ソフトウェアとの類推は単純ではありません。建築家は依然として建物がどのように建つかを知る必要があります。しかし、それは何か現実のものを指し示しています:レビューを生き残る貢献は、エージェントだけではできないもの、つまり新しい構築ではなく、既存のシステムに対する深い理解を必要とする呼び出しがますます多くなっています。
では、次は何でしょうか?
OpenClawは、わずか数ヶ月で何もない状態から現実世界のJarvisへと成長しました。一人の人間が、強力なコミュニティと共に、1年前には不可能だったペースで構築することができました。それは非常に特別なことです。オープンソースコミュニティはかつてないほど速く構築できます。この速度によって導入される問題には、アイデンティティ、レピュテーション、そして貢献の検証方法におけるより良いプリミティブが必要となり、それらはすべて構築されるでしょう。オープンソースは以前にもより困難な問題を解決してきました。