Gitの`--author`フラグでGitHubリポジトリのAIボットスパムを防いだ方法
(archestra.ai)- Archestraリポジトリでは、AIベースのコントリビューションが増えるにつれて無意味なコメントやPRが殺到し、実際の議論が埋もれ、メンテナンス負荷が増大した
- 900ドルのバウンティ付きissueは本来、実際の貢献者が議論する場だったが、AIボットのコメントで253件のコメントにまで膨れ上がり、攻撃的な態度まで見られた
- x.ai provider対応issueには、クローズされマージされなかった27件のPRが投稿され、その大半は貢献者がテストすらしていなかった
- GitHubのprior contributor制限は、新規の実在する開発者とAIボットを区別できないため、Gitの
--authorで承認済みユーザーをmainコミットのauthorに追加した - オンボーディングでは、倫理的なAIルールとCAPTCHAの後、GitHub Actionでホワイトリスト用コミットを作成し、水増しされた活動指標よりも品質を優先した
AIボットスパムがオープンソースリポジトリをむしばんだ方法
- Archestraリポジトリでは、GitHubのAIベースのコントリビューション指標が伸びているのとは対照的に、現場では貢献の品質低下とメンテナンス負荷の増大が起きていた
- 900ドルのバウンティを付けたissueは、実際の貢献者が計画を提案し、質問し、作業を試みる場だったが、AIボットが押し寄せて合計253件のコメントに膨れ上がった
- AIアカウントは無意味な実装計画を残し、メンテナーに対して攻撃的な態度まで見せ、議論を汚染した
- リポジトリを見守っていたチームメンバーは、AIコメントのたびに通知を受け取り、@ethanwater、@developerfred、@Geetk172 のような実在する貢献者同士の会話が埋もれてしまった
- x.ai provider対応issueには、クローズされマージされなかった 27件のpull request が寄せられ、その大半は貢献者がテストすらしていなかった
- チームメンバー1人が毎週半日を費やして、未テストのPRや幻覚ベースのissueを整理しなければならず、放置すればリポジトリは実際の貢献者にとって急速に不親切な場へと変わっていった
GitHubの制限を回避したホワイトリスト方式
-
初期対応の限界
- Archestraはまず、貢献者の評判を計算するために London-Cat という小さなボットを作った
- London-Catは、マージされたPRといくつかのシグナルをもとに貢献者の評判を計算し、例 のように貢献者の識別には役立った
- しかしこの方法は、スパム遮断そのものには失敗した
- 次の段階で作られたAI sheriffは、例 のように実際のPRまで一部クローズしてしまった
-
オンボーディングなしの活動を遮断
- 無意味なAIコメントや提案が続いたことで、実際の貢献者が去り始め、バウンティで貢献を促す方法や、採用候補者にテスト課題を与える方法まで見直すことになった
- Archestraは、実際の貢献者、責任あるAI利用者、初心者、熟練エンジニアの全員にとって快適で安全なリポジトリを作るため、対策を強化した
- オンボーディングを経ていないユーザーは、今後issue作成、PR作成、コメント投稿ができないように制限された
- VC出資を受けたスタートアップにとってGitHub活動指標は敏感なものだが、ArchestraはAI slopで水増しされた指標よりも品質を重視した
-
GitHub設定の限界
- GitHubには、オープンソースリポジトリでコメント投稿者やPR作成者を直接ホワイトリスト管理する簡単な方法がない
- 「Limit to prior contributors」設定は、
mainに以前コミットしたことのないユーザーによるissue・PRコメント投稿を防ぐ - この設定では、AIボットと、バウンティ作業のために新たに来た実在の開発者を区別できず、どちらも既存貢献者ではないユーザーとして扱われる
-
--authorフラグを使ったホワイトリスト- GitHubは、
mainブランチのコミットのauthorに紐づいたGitHubアカウントを prior contributor と判定する - Gitコミットには author と committer という2つの身元フィールドがあり、この2つの値は異なる場合がある
- Gitの
--authorフラグを使えば、他人に帰属するコミットを作成でき、メールアドレスがそのGitHubアカウントと一致していれば、GitHubはそのコミットをそのプロフィールに紐づけ、貢献者ステータスを付与する - すべてのGitHubアカウントには、
<id>+<username>@users.noreply.github.com形式のnoreplyメールアドレスがある - ユーザーIDをAPIで取得し、そのメール形式でコミットauthorを指定する
gh api users/their-username --jq '.id' git commit \ --author="their-username <ID+their-username@users.noreply.github.com>" \ -m "chore: add their-username to external contributors"- このコミットを
mainにプッシュすると、外部ユーザーはauthor、Archestraアカウントはcommitterとして表示され、GitHubはそのユーザーを prior contributor と見なして即座にコメント権限を付与する
- GitHubは、
-
実際のオンボーディングの流れ
- https://archestra.ai/contributor-onboard - Webサイト上で、倫理的なAIルールとCAPTCHAを含むオンボーディングを実施する
- GitHub Action - 送信時にユーザーのGitHub IDを取得し、
EXTERNAL_CONTRIBUTORS.mdファイルにハンドルを追加したうえで、そのユーザーアカウントをauthorとするコミットをmainにプッシュする - ユーザー - ホワイトリストに登録され、リポジトリへのアクセス権を得る
- GitHubがAI生成活動を含む大規模な指標成長を報告する一方で、オープンソースプロジェクトのチームは、リポジトリ内のAI slopを自ら片づけ、実際の参加者の水準を保つための回避策まで作らなければならなかった
- AI slopは、良い貢献をしようとする人をノイズの中に押しやって意欲を削ぐだけでなく、LiteLLM repo のように攻撃者がAIボットで会話を誘導しようとするセキュリティリスクももたらす
1件のコメント
Hacker Newsのコメント
リポジトリのコントリビューターは fork PR 実行の承認要求を回避できるなど、より高い権限を持つようになるため、この方式には見落とされている セキュリティ上の影響 がある
GitHub のドキュメントでも「初回コントリビューターのみに承認を要求する」設定では、リポジトリにコミットまたは PR が一度でもマージされたユーザーは承認が不要になり、悪意あるユーザーが単純なタイプミス修正のような無害な変更を受け入れてもらうことでこの条件を満たせてしまうと警告している
誰かの完全に無害な PR が 1 つリポジトリにマージされたというだけで不安定になるなら、そのリポジトリはすでに不安定な状態だと言うべきだ
GitHub がこんなことを可能なままにしているのが問題だ。コメント投稿や PR 作成にごく基本的な要件を設けていれば、ここまでにはならなかったはずだ
それに、Issue を削除できるように PR も削除 できるようにしてほしい
目標は、メンテナーがリポジトリへのコントリビューションをどう管理するかをよりよく制御できるようにすることだ。アーカイブされた PR は管理者にのみ表示され、監査や組織・コンプライアンス要件のためにコントリビューター記録にはメンテナーが引き続きアクセスできるようにしたい。このような機能が役立つか気になっている
PR スパム は懸賞金を運営しているリポジトリでは大きな問題だ。PR の 95% 以上が却下されるアカウントは、GitHub が一時的に PR 作成を止めるべきかもしれない
誰かが意味のある議論に参加し、Issue や機能を解決するよいアイデアを示したら、最初は PR トークンを 1 つ与える。PR の品質が良ければさらにいくつか与え、最終的には自由に PR を作れるコントリビューターに昇格させる、という形だ。Issue にも似た仕組みがあるとよいが、Issue が PR コントリビューションの出発点である場合にどうあるべきかはよくわからない。ただ、GitHub/MS は Copilot のサブスクとトークンを売りたいだろうし、LLM 生成 PR もそのビジネスモデルの一部なので、実際に実現する可能性は低そうだ
こうした問題を減らすのに Elo ベースのスコアシステム が有効か気になる
特定プロジェクトに PR を成功裏にマージした人、実際の Issue を認められた人、他ユーザーの反応で応答品質が測定された人などを評価し、その活動があったプロジェクトの重要度まで掛け合わせる、というものだ。人間対 AI ではなく、実際に役に立つ効果的なコントリビューションと、低労力・スパム的なコントリビューションを分ける基準になりうる。Issue と PR は Elo スコアで並べ替えたりフィルタしたりできる。ここでの Elo は文脈依存スコアの比喩であって、実際の Elo システムを 1:1 で持ち込もうという意味ではない
マイナス点はスパム的コンテンツや認められなかった Issue に対する他ユーザーの報告から生じ、善意は明らかだがマージされた PR には至らなかった場合や、正しいリポジトリではなかった Issue、事前実装が必要だった良い PR のようなケースには、中立または弱いプラス点を与える中間地帯が必要そうだ
たとえば実際に刑務所内にかなり強いチェスプレイヤーがいて、彼は自分に負けて高い Elo を得たプレイヤーの集団を作り、その人たちを使って自分のスコアをさらに押し上げた。これを繰り返せばよい
操作可能な制度であれば、AI は必ず操作方法を見つける。元記事の方式でも、ある AI がコントリビューター資格を得れば、ほかの AI をコントリビューターに引き上げられるし、そこでまた同じ問題が始まる。そこに目的すら必要ない。荒らしは荒らしをするし、AI ボットを持つ荒らしは無限のエネルギーを注げる。止めようとすればするほど、彼らにはもっと面白くなる。この問題に答えがあればいいのだが、わからない
https://en.wikipedia.org/wiki/Elo_rating_system
Frontier users: 527,865
Light indexed: 527,865
Ready to queue: 9,083
Fast scores ready: 0
Activity events 24h: 30,266
Fast scores completed 24h: 19,123
Deep jobs completed 24h: 3,043
Fast-score ETA: n/a
Deep-hydrate ETA: 69h
Stale running jobs: 0
GitHub backpressure jobs: 19,113
High automation signals: 4,608
Medium automation signals: 1,327
Completed jobs: 74,714
最大の難関は GitHub のレート制限 だ。このペースだと 98% のカバレッジに達するまでさらに 2 か月かかるが、その後の保守はかなり単純になりそうだ
AI がどれだけコードを書くのがうまいかを皆に吹聴した結果がこれだ
AI を売る人たちが始め、奇妙なことにインディー開発者たち、その中には業界でかなり尊敬されている人たちまで大挙してそれに乗った。Facebook が今や人を解雇しながら、AI があまりに優秀だからだと言っているのも火に油を注いでいる。その結果、AI 友達がすごいコードを量産すると確信している人たちがいて、完全に手に負えなくなったプロジェクトにそのコードを送り込んでいる
尊敬されているかどうかとは別に、1 人開発者が常にカウボーイにならないだけの必須能力を備えているとは限らない。経験不足でも、生まれつきの適性不足でもそうなりうる。ただ、この物語を完全には信じていない。「初期」から強いトップダウンの後押しがあったからだ
.ai ドメイン なのが皮肉だ
結局、すべての解決策はもっと多くの catgirl なのか？ [1] プルーフ・オブ・ワークはもともとメールスパムへの対策として考案されたもので、PR スパム はその長い伝統の最新例にすぎない
1- https://anubis.techaro.lol
有効なプルーフ・オブ・ワークを作る負担は、どんな実装でも常に正規ユーザーに不利に働く。スパムを送る動機のある人は、いつでもより速く効率的にできるからだ
ノートPCが遅すぎて PR を出せないなら？ 誰かからハッシュパワーを借りればよく、そうなると GitHub リポジトリに typo 修正を送るためにボットネット所有者へ金を払う仕組みを作ったことになる。HashCash が現実で使われなかったのには理由がある。かわいく聞こえるが、皆が不正をしない真空状態を前提にしないと成立しないほど、インセンティブ設計がおかしい
オンボーディング文書の文体には、よくある AI っぽさ がある。引用でも em dash や「A ではなく B だ」式の文が見える
火を火で消そうとしているのか、あるいはすでに言われているように時間がなかったのかもしれないのは理解できる。それでも全体としては、不十分な中途半端な対応に感じられる
人が考えを整理して入れたのはわかるが、LLM に「これをブログ記事にしてくれ」と頼むのは、HN にはふさわしくない低労力コンテンツだと思っていた。ただ、基本方針の「コントリビューターに限定する」がセキュリティ面で悪いアイデアかもしれない、という議論を生んだ点はある
「メールアドレスが GitHub アカウントと一致すれば GitHub がそのコミットをプロフィールに紐づけ、コントリビューター状態を付与する」という部分を見て、コントリビューターのメールアドレスが変わったら壊れないかと心配になった
何年ものあいだ、もう存在しないメールアドレスで複数のプロジェクトにコントリビュートしたことがあるからだ
しかし実際には、作者の元の git コミットに記録されたメールアドレスを使うのではなく、GitHub ユーザー ID とユーザー名が固有部分に入った GitHub 生成アドレス を使っているようだ。なら作者がメールアドレスを変えても維持できる。もっとも、コントリビューターがアカウントへのアクセスを失い、新しいアカウントを作らなければならない場合には壊れるかもしれないが、それはたぶんよりまれだろう
「応募者に面白いテスト課題を出すのをやめるべきか？」への答えは イエス だ
そして開発者たち: 実際の問題を解かせるな