AIスロップとの戦い：ArchestraがいかにしてGitの --author フラグを使用してオープンソースを保護するか

AI支援コーディングの台頭は、オープンソースコミュニティに逆説的な課題をもたらしています。GitHubが貢献メトリクス（指標）の急増を祝う一方で、メンテナーは「AIスロップ（AIによる低品質なゴミ）」に溺れつつあります。これは、正当な人間の貢献を埋もれさせてしまう、低品質でテストされておらず、しばしばハルシネーション（幻覚）を含むプルリクエストやIssueです。

Archestraのチームにとって、この問題は、MCP Appsサポートへの900ドルのバウンティ（報奨金）が、才能ある開発者だけでなく、AIボットの洪水をも引き寄せてしまった時に限界点に達しました。単一のIssueが253件のコメントに膨れ上がり、無意味な実装計画や攻撃的なボット生成のノイズで埋め尽くされました。その結果、実際の貢献者を疎外する「ノイズの壁」が生じ、チームメンバーは毎週何時間もリポジトリを手動でクリーニングすることに費やされることになりました。

ボットの潮流に対する苦闘

Archestraは最初、より伝統的なソフトウェアベースのアプローチを使用してスパムを軽減しようと試みました。彼らは、マージされたPRに基づいて貢献者のステータスを計算するレピュテーションボット「London-Cat」と、疑わしい貢献を自動的にクローズする「AI sheriff」を構築しました。しかし、これらのツールは不十分でした。sheriffは時折、正当なPRをクローズしてしまい、AI生成コンテンツの量も増え続けました。

この傾向は、より広範なシステム上の問題を浮き彫りにしています。AIツールによってコードや提案の生成が容易になったことで、PRを提出するコストはほぼゼロにまで下がりましたが、一方でそのPRをレビューするコストは依然として人間の負担として残っています。この非対称性が、ボット運営者が、特にバウンティのような金銭的インセンティブを提供するリポジトリを標的にして悪用する脆弱性を生み出しています。

ホワイトリスト化のための「核の選択肢」

リポジトリを取り戻すために、Archestraは厳格なオンボーディングプロセスを導入しました。彼らは、検証プロセスを経ていないユーザーに対して、Issueの作成、PRのオープン、コメントの投稿をブロックすることに決めました。

GitHubにはオープンソースリポジトリ向けの粒度の細かいネイティブなホワイトリスト機能がないため、チームは「Limit to prior contributors」設定を利用した巧妙な回避策を用いました。このルールに基づくと、以前に main ブランチにコミットしたことがあるユーザーのみがリポジトリと対話できることになります。

正当なユーザーに、実際にコードを提出する前にこのステータスを付与するために、ArchestraはGitにおける author と committer の違いを活用しています。

オンボーディング: ユーザーは専用サイトを訪れ、倫理的なAIルールに同意し、CAPTCHAを通過します。
Identification: GitHub ActionがAPIを介してユーザー固有のGitHub IDを取得します。
The Hack: システムは --author フラグを使用して main ブランチにコミットを作成し、そのコミットをユーザーの GitHub noreply メールアドレス (<id>+<username>@users.noreply.github.com) に帰属させます。
Activation: ユーザーは main ブランチ上のコミットの author になるため、GitHubは彼らを「以前の貢献者」として認識し、即座にコメントやPRのオープンが可能になります。

コミュニティによる批判とセキュリティ上の影響

この解決策は、低労力なボットを阻止するのには効果的ですが、開発者コミュニティの間で大きな議論を巻き起こしています。

セキュリティリスク

コミュニティから提起された一つの重要な懸念は、「以前の貢献者」ステータスを付与することによるセキュリティ上の影響です。ユーザー @captn3m0 が指摘したように、GitHubのセキュリティ設定は、以前の貢献者を異なる方法で扱うことがよくあります。

When requiring approvals only for first-time contributors... a user that has had any commit or pull request merged into the repository will not require approval.

プログラム的にこのステータスを付与することで、Archestraは、初回貢献者をより厳重に精査するためのセキュリティガードレールを意図せず的にバイパスしてしまう可能性があります。

「いたちごっこ」のゲーム

他の批判者は、これが一時的な解決策に過ぎないと主張しています。ボット運営者が単にCAPTCHAとオンボーディングプロセスを自動化し、スパムをPRの段階からオンボーディングの段階へと移動させるだけだと示唆する人もいます。また、この方法がgitの履歴に「ノイズ」を導入することを指摘するsいます。最近のコミットの大部分が、純粋に管理的なホワイトリスト登録用のエントリとなるためです。

代替案の提案

Hacker Newsのコミュニティは、AIスロップとの戦いに対抗するためのいくつかの代替戦略を提案しました:

ELO-based systems: マージされた作業の量ではなく、品質と影響力に基づいて貢献者をランク付けするシステム。
Financial barriers: 「Pfand」またはデポジット（預かり金）システムを、貢献者がPRを提出する際に少額の費用を支払う仕組み。誠実な取り組みであれば、返金されます。
Identity Verification: 匿名性を排除し、貢献者が評判を維持すべき実在の人間であることを確実にする方法。

結論

Archestraのアプローチは、GitHubが追跡するメトリクス（総貢献数やアクティビティ）が、実際のプロジェクトの健全性からますます乖離しているということを、痛烈に思い出させてくれます。「成長」がAI生成の「スロップ」によって駆動されるとき、その結果は、より生産的なエコシステムではなく、より負担の重いものになります。彼らの --author ハックは、風変わりな回避策ではありますが、それは、貢献のコストが人工的に激減した時代において、メンテナーが量よりも質を優先させる必要性が高まっていることを反映しています。