OSSに『経歴稼ぎ』の低品質AI生成PR相次ぐ、メンテナーが苦言
姉妹サイトの新着
OSSメンテナーのNeil Alexander氏が「経歴を飾るためだけに低品質なAI生成プルリクエストを送りつけるのはやめてほしい」とブログで訴えた投稿が、Hacker Newsで話題になった。
コメント欄では、貢献者としての「箔付け」を目的にした投稿への対処法や、レビューする側の負担、さらに過去のxzバックドア事件を引き合いに出した警鐘まで、さまざまな意見が交わされた。
経歴を盛るためにAI生成の低品質な投稿でプロジェクトを埋め尽くすのはやめてくれ
この話題の背景と論点
背景:GitHubのPR数やコミット数は「主要OSSへの貢献実績」として履歴書や転職活動で重宝され、2020年のHacktoberfestではTシャツ目当ての機械的PRが問題化した先例がある。今回はAIエージェントの普及で、AGENTS.mdやCLAUDE.mdといった開発者向け指示書すら読まないまま低品質な修正が自動生成・大量投稿される点が新しい。
スレでは、貢献実績の水増しが「ゼロサムでない」とする楽観論と、「本物の貢献への信頼を毀損するマイナスサムだ」とする反論が対立し、技術的フィルタリングで解決可能かという点でも意見が割れた。
押さえておきたいのは、2024年のxzバックドア事件はAI生成PRが原因だったわけではなく、レビューを素通りさせる危険性の比喩として引用されている点。またGitHubの貢献グラフは質を問わず件数のみを可視化する仕組みであり、今回の問題は制度設計そのものに起因する。
出典: neilalexander.dev / 元記事はこちら
ステータスが上がるくらい別にいいじゃないか。ゼロサムの話じゃないんだから。
『ゼロサムじゃない』というのは違う。実際はマイナスサムだ。偽物の実績が本物の実績への信頼を蝕んで、本物を見分けるのがずっと難しくなるから。
何に対するステータス向上だよ。プロンプトを打てるってことに？ ちゃんと理解して書いている人と、プロンプトを打って結果をコピペしているだけの人をどう見分けるんだ。針を探しているときに干し草の山を大きくするのは悪手だ。
それこそが本当の発見だ。まさに『構造を支えている自爆スイッチ』を見つけてしまったな。
普通に『furnish』の方が意味が通る。
何年もその火を欲しがってきたのに未だに手に入れられない『アイデアだけの人たち』は、嫉妬でいっぱいなんだよ…
『雰囲気だけの自作スロップ』と『経歴に「有名プロジェクトのコントリビューター」と書く』、どちらが得か。Openclawくらい上手くゲリラマーケできる人でもない限り、社会的な信用としてはBの方が圧勝だ。
それは無理だ。世の中に無数にある『個人プロジェクト』の大半は誰も保守できない蜃気楼みたいなものだから、だからこそ人は実際に使われ開発されているソフトウェアの評判にただ乗りしようとするんだ。
『一目でClaudeが書いたと分かる低努力・一発生成のPRを受け取ることがある(リポジトリに用意してあるAGENTS.mdすら読まないエージェントも多い)』とのことだが、Claudeはデフォルトで自動的にAGENTS.mdを読むわけではなく、CLAUDE.mdしか見ない。
その通り、でもclaude.mdの方もちゃんと用意している。要は、ベストプラクティスに沿ったエージェント開発が全然できていないのが問題だということだ。
実に賢いね(皮肉)
面白い例えだ。GitHubなどのプラットフォーム側がこの手の投稿をもっとうまくフィルタリングする余地がありそうだな。
他サイトの新着
そもそも『PR数を数える』という虚栄の指標自体に無理がある。虚栄の指標は本質的に欠陥があるものだからだ。この問題に技術的な解決策があるとは思えない。技術の問題ではないからだ。ちょっとした罠を仕掛けるならこうだ──『ああ、ヒントありがとう:)』とだけコメントして、実際の修正は自分でやってしまう。それに対する相手の反応を見てみるといい。詐欺師たちをハックしてやれ。地球をハックしてやれ。
私のやり方は『作業の証拠』を要求すること。テストすらしていないPRを開いた人の多くは、それだけで姿を消す。スクリーンショットも無しにどうやって表示上の不具合を直したと主張できるんだ？即クローズだ。
あるいはPRをローカルに取り込んで、git amend –reset-authorしてから自分でmasterにpushしてしまうという手もある。
そもそも今のオープンソースの捉え方自体、昔とは違ってしまっている。以前は『これを作った、コードはこれだ』というだけのものだったのに、今ではFacebookに近いような妙にパラソーシャルなものになってしまった。
幸い、プロジェクトを使ってInstagramのフィード用に『アヒル口』はできないけどね(笑)
ちょうど8時間前に全く同じ思考の流れをたどった。あるプロジェクトをコンパイルした際に出たセグフォルトを、そのプラットフォームの組み合わせなんてあまり想定されていないだろうと思いつつ、LLMを使って解決したところだ。
フォークを保守する方が労力が少ないなんてことがあり得るのか？ 毎週アップストリームをマージして、自分のパッチとのコンフリクトと延々戦う羽目になるのに。
その変更はコメント内の文法とスペルの修正だった。『役に立とうとした』という意図があるだけでは十分ではない。
この手のPRを受け入れることは、本当に必要なコードベースの改善作業に使うべき時間を奪ってしまう、ということだと思う。だから長い目で見れば、こういうつまらない貢献には厳しく対応して、機能追加やバグ修正のような本当に重要な変更に集中する方がいい。
低努力なPRを乱発できる環境なら、人は乱発する。裏付けのない『まあいいか』という感覚は、現実にある問題から目をそらしているだけだ。
どちらでも通じるけど、私も『furnish』の方が好みだ。経歴の主要な部分に据える、というニュアンスだから。『burnish』はどちらかというと『磨く』に近くて、根本部分というより上に重ねる追加の層を示唆する感じがする。
中身を読まずにコミットやPRをマージするから、2024年のxz事件のようなことが起きるんだ。
※本記事は5ch(Hacker News)スレッド「Please stop flooding our projects with AI slop to furnish your CV」より抜粋・要約して構成しています。
まだコメントはありません。