ハクソク

世界を動かす技術を、日本語で。

Gitの–authorフラグを使って、GitHubリポジトリでAIボットのスパムを防ぎました

7日前原文(archestra.ai)

概要

  • AIによる貢献の質低下 がオープンソース界隈で深刻化
  • AIスパム がリポジトリ運営や正規コントリビューターの活動を妨害
  • 独自のホワイトリスト方式 でAIアカウント対策を実施
  • GitHubの制限の中で工夫 したオンボーディングプロセス導入
  • AIによるリスクと今後の議論の必要性 を強調

オープンソースの終焉？AIスパム問題とその対策

  • GitHub でのAIによる貢献数増加、しかし 貢献の質低下 が顕著
  • バウンティ付きIssue （$900報酬）にAIアカウントが殺到、 ノイズ化問題 発生
  • AIボット による不要なコメントや攻撃的発言、 正規コントリビューターの埋没
  • Pull Request（PR）やIssue が未検証・無意味なものだらけになり メンテナンス負荷増大
  • リポジトリがAIスパムに埋もれ、新規・正規の貢献者が活動しにくい環境へ

対策とその課題

  • London-Cat という独自Botで コントリビューターのレピュテーション管理 を試行
    • 効果限定的、スパム根絶には至らず
  • AI sheriff 導入でAIスパム自動排除
    • 誤検知による正規PRの排除 も発生
  • オンボーディング必須化 という「核オプション」採用
    • Issue作成・PR・コメント は 事前承認（ホワイトリスト）通過者のみ許可
    • 品質重視 の方針転換、AIによる「数値水増し」否定

GitHub上でのホワイトリスト運用方法

  • 「prior contributors限定」設定 で 過去にmainへコミットしたユーザーのみ権限付与
    • AIも新規コントリビューターも一律制限 される副作用
  • Gitの--authorフラグ や GitHub noreplyメール を活用したコミットで 外部ユーザーを事前承認
    • 外部ユーザーがauthor、チームがcommitterとなるコミット をmainへpush
  • オンボーディングフロー ：
    • 自社サイトでAI倫理ルール同意＋CAPTCHA認証
    • GitHub Actions がユーザーID取得、EXTERNAL_CONTRIBUTORS.md更新、mainへコミット
    • 承認後、即リポジトリアクセス可能

AIスパムによるリスクと今後の課題

  • AI生成ノイズ は モチベーション低下・貢献意欲の阻害要因
  • LiteLLMリポジトリ事例 ：AIボットによる セキュリティリスク、攻撃者が議論誘導
  • GitHubのメトリクス増加 の裏に AI生成コンテンツの氾濫
  • オープンソースコミュニティ全体でAIの影響を再考 する必要性

まとめとコミュニティへの呼びかけ

  • AI活用の功罪 を直視し、 本質的な貢献の質 を守るための仕組み作りが必須
  • 正規コントリビューター・責任あるAIユーザー・初心者・熟練者 が安心して参加できる場の維持
  • コミュニティ全体でAI時代のオープンソースのあり方 を議論すべき時期

Hackerたちの意見

PRスパムは、報酬を出しているリポジトリにとって大きな問題だよね。GitHubは、95%以上のPRが拒否されるアカウントを一時的にブロックすべきなんじゃないかな。

└

問題は、ボットが無限にGitHubアカウントを作ってスパムを続けられることだよね。でも、これを防ぐためのシンプルな対策としてはいいスタートかも。

└

GitHubにはAIをブロックするインセンティブがないんだよね。広告会社に自社のブラウザに広告ブロッカーを作れって言ってるようなもんだ。

└

GitHubとMicrosoftはこの問題に積極的に関与しているから、彼らが非を認めるわけがないよね。

└

GitHubには、例えば1つのPRに有効なトークンを配布できるシステムがあってもいいと思う。誰かが意味のある議論をして、問題や機能に対する良いアイデアを示したら、最初に1つのPRトークンを渡す。もしそのPRが良質なら、さらにいくつか渡して、最終的には好きなようにPRを作成できる貢献者になれる。問題に対しても似たようなシステムがあればいいけど、問題がPRの貢献のきっかけになるとしたら、どうなるのかは分からないな。実現する可能性は低いと思うけど（他の人も言ってたし）、GitHub/MSはCoPilotのサブスクリプションやトークンを売りたいから、LLM生成のPRもそのビジネスモデルの一部なんだ。

求人候補者に楽しいテスト課題を出すのをやめるべき？ うん、そうだね。

└

それ、誰にとって楽しいの？

└

この特定の会社は、そのタスクを完了することで報酬を支払っているみたいだから、そんなに悪くないかもね。

└

開発者たち：ホワイトボードインタビューはやめて、実際の仕事に関連するものを測れないから。で、開発者たち：現実の問題を解決するのはやめて。

.aiドメインの皮肉だよね。

└

指摘してくれてありがとう！気づかなかったし、すごく面白いね。

└

それと、ウェブサイトのスクロールコードを直してくれない？めっちゃイライラする。記事が読めないよ。

└

それについてはアイロニーはないと思うよ。AIが悪いって言ってるわけじゃなくて、ただ悪用される可能性があるってことだから。

ELOベースのシステムがこれらの問題を軽減するのに役立つかもしれないな。実際の問題が認められたプロジェクトにPRを成功させた人たち、その反応を他のユーザーのリアクションで測るとか、活動が行われたプロジェクトの重要度で掛け算するとか。人間対AIじゃなくて、実際に役立つ貢献と低努力のスパム的な貢献を区別する感じ。問題やPRはELOスコアでソートやフィルタリングできるかも。ELOってのは「文脈に応じたスコア」って意味で使ってるだけで、ELOシステムの1:1翻訳じゃないからね。ネガティブスコアはスパム的な内容や認められない問題で他のユーザーからの報告、ニュートラルスコア（±0）や、明確な善意があるけど適切なマージPRに至らなかった問題とかに少しポジティブなスコアがつく感じかな（例えば、問題はあったけど正しいリポジトリじゃなかった、PRは良かったけど他の実装が必要だったとか、長い目で見ればね）。

└

問題は、他のコミュニティプロジェクトでの活動に基づいたELOスコアを求めていることだね。ここでは善意を前提にするのは無理だよ。

└

こんな感じのものを作ったことがあって、データを集めてるところだよ。フロンティアユーザー数: 527,865 ライトインデックス: 527,865 キュー待ち: 9,083 ファストスコア準備完了: 0 過去24時間のアクティビティイベント: 30,266 過去24時間のファストスコア完了: 19,123 過去24時間のディープジョブ完了: 3,043 ファストスコアのETA: 不明 ディープハイドレートのETA: 69時間 ステール状態の実行中ジョブ: 0 GitHubのバックプレッシャージョブ: 19,113 高い自動化シグナル: 4,608 中程度の自動化シグナル: 1,327 完了したジョブ: 74,714 一番の課題はGitHubのレート制限だね。このペースだと98%のカバレッジを達成するのにあと2ヶ月かかる。でもその後はメンテナンスがかなり簡単になるはず。

└

ELOは驚くほど操作しやすいんだよね。例えば、そこに普通のチェスプレイヤーがいる刑務所があったんだ。彼は自分に勝つことで高いELOを得たプレイヤーのプールを作って、さらに自分のレーティングを上げるために使ったんだ。洗って、すすいで、また繰り返す。操作可能な仕組みがあれば、AIはそれを操作する方法を見つけるよ。OPにとって、もし単一のAIが貢献者にたどり着いたらどうなる？ そしたら他のAIも貢献者に昇格して、また始まる。目的がなくてもいいんだ。トロールはトロールするし、AIボットを持ったトロールは無限のエネルギーを注げるからね。彼らを排除しようとすればするほど、逆に楽しくなっちゃう。これに対する答えがあればいいんだけど、残念ながらないんだ。

└

Eloって何か気になる人へ。これは人の名字で、略語じゃないよ（全て大文字じゃない）。詳しくはこちら: https://en.wikipedia.org/wiki/Elo_rating_system

└

エロじゃなくて、Eloだよ。Eloは略語じゃないからね。https://en.wikipedia.org/wiki/Elo_rating_system

└

ELOじゃなくて、信頼のサークルが必要だと思う。

└

ミッチェル・ハシモトのVouchにちょっと似てるね。https://github.com/mitchellh/vouch

これには見落とされがちなセキュリティの問題があるんだ。リポジトリの貢献者は、フォークPRの承認要件を回避できるなど、より高い権限を持っている。GitHubのドキュメントにも警告があるよね：> 初めての貢献者にのみ承認を要求する場合（最初の2つの設定）、リポジトリにコミットやプルリクエストがマージされたユーザーは承認を必要としない。悪意のあるユーザーは、メンテイナーに簡単なタイプミスや他の無害な変更を受け入れてもらうことで、この要件を満たすことができるんだ。

└

確かにその通り！「外部の貢献者には全て承認が必要」ってのはデフォルト設定にすべきだと思う。組織のメンバーじゃない人を信用するのは難しいからね。

└

いや、それにはセキュリティの問題はないよ。誰かの無害なPRが君のリポジトリにマージされたからって不安になるなら、それは君が不安定なだけだよ。

すべての解決策は、ただもっと猫耳少女が必要ってこと？[1] プルーフ・オブ・ワークは、結局メールスパムに対抗するためのものだったし、PRスパムはその長い伝統の最新のものだよ。1- https://anubis.techaro.lol

└

プルーフ・オブ・ワークはここでは機能しないし、メールでも機能しない。正当なユーザーは、常に有効なPoWを作るための努力で不利になる。スパムを送るインセンティブがある人は、常に君よりも早く、効率的にできるから。もし君のノートパソコンが遅くてPRを提出できないなら、誰かからハッシュレートを借りて、今度はGitHubのリポジトリでタイプミスを修正するためにボットネットの所有者にお金を払うシステムを作ったことになる。HashCashは現実世界では使われなかった理由があって、可愛い響きだけど、インセンティブが異常すぎて、みんなが不正をしていないと仮定する真空状態でしか機能しないんだよね。

これはオープンソースにおけるお金の有毒な影響の良い例だね。人々には尊敬と認識で報いるべきだよ。誰も知らないような匿名アカウントは去るだろうし、身元を隠している誰か（または何か）は認識から得られるものがないからね。正直、GitHubには実名ポリシーが必要だと思う。GitHubで匿名でいる理由は、(1) 雇用主の承認を回避するため、(2) スパムや嫌がらせ、毒性のある行動をするため、または (3) 人間じゃないからのどれかだと思う。これらの理由は、GitHubでのやり取りの際に最も避けたいことだよ。ロボットは好きだけど、自分でロボットと話すことはできるから、君のロボットとは話したくないな。それに、雇用主の同意なしに知的財産を渡されるのも嫌だし、嫌がらせやヘイトも楽しめないよ。GitHubは、ヘイトの露骨な表現を問題にすることで、最後の部分を助けようとしているけど、結局は人々がもっと巧妙に匿名アカウントを使うようになってしまうんだ。もしGitHubがすべてのユーザーが実名で善意の行動をしていることを保証できるなら、お金の話を始められるかもしれないね。

ブログ記事が「無意味な『実装計画』で会話を毒している」と文句を言っているのはちょっと変だね。実際には、$900 USDの報酬を非常に具体性のない問題に付けた後で、それを求めているわけだし、最初の「挑戦者」に「実装計画は考えてる？」って返事してるし。彼らが求めていたものをまさに手に入れたように聞こえるし、LLMが登場する前でも似たようなことをしたら、影響は同じだったと思うよ。

└

開発者がプランを提供するのは全然いいけど、拒否されてもね。問題は、すべてのスクリプトキディがAIのおかげで自分が開発者になったと勘違いすること。医者の意見を聞きたいと思ったら、何人かの意見を聞きたいよね。でも、無数のAIアマチュアが自分を医者として登録してる。どうやって本物と偽物を見分けるの？

みんなにAIがコードを書くのがすごいって言った結果がこれだよね。最初はAIを売ってる人たちから始まって、なんでか知らないけど、結構評価されてる独立系の開発者たちも乗っかってきた。Facebookが人を解雇して、その理由が「AIがすごすぎるから」って言ってるのも、火に油を注いでる感じ。今じゃ、自分のAIの友達がすごいコードを出してくれるって自信満々な人たちがたくさんいて、プロジェクトが完全に圧倒されてる。

└

なんでか知らないけど、たくさんの独立系開発者たちがカウボーイコーダーになって、バーチャルなカウガールコーダーを作ってみんなに売った、うーん、もしかして…（評価されてるかどうかに関わらず、ソロ開発者は経験不足やスキル不足でカウボーイになっちゃうこともあるからね）でも、このストーリーには完全には賛同できないかな。「始まり」から強いトップダウンの推進があったし。

ブログを読んで最初に思ったのは、「このブログをClaudeにシェアして、ボットがどうやってこれを回避できるか聞いてみよう」ってこと。個人的には、AIボットがOSSにかなり影響を与えてると思うし、成功を定義するためにもっと良い質的な指標が必要だね。