Claudeにコードを書かせたらrsyncでバグが増えた？真相を調査

最近、Claudeを使ってrsync周りの処理を記述したところ、以前よりもバグや予期せぬ動作が増えたように感じています。皆さんの環境でも同様の現象は起きていますか？AIが生成したスクリプトをそのまま使う際の注意点や、皆さんが普段行っている検証方法があればぜひ教えてください。

コミットの複雑さやセキュリティ上の重要度、バグの深刻度などは考慮されていません。1行のタイプミス修正とCVEパッチを区別することもなく、大雑把な指標に過ぎません。しかし、批判側の「Claudeが状況を悪化させている」という主張もまた大雑把なものです。その意味で、この大雑把なアプローチは公平な対応と言えるかもしれません。

もし「公平」という言葉が、この分析と対応で十分であるという意味なら、残念ながら同意できません。ユーザーの視点から見てバグの性質が実際に悪化しているのかを理解する必要があります。バグの発生率が変わらなかったとしても、結果としてソフトウェアの品質が低下したと認識されるなら、個人的にはそれを「悪化」とみなします。特にプロジェクトのメンテナーであればなおさらです。

完全に否定したいわけではありませんが、一般的に言って、定量的分析だけでこの種の問題に十分な答えが出せるとは思えません。

残念ながら、この件で怒っている人たちがrsyncのメンテナーに圧力をかけたところで、結局は他の開発者が責任を持ってAI利用を開示することをためらわせるという結果にしかならないでしょう。AI利用を公言することで揉め事を起こすくらいなら、コミットからClaudeの表記を消すようになるだけですよ。

私はこの件に利害関係はありませんが、いくつか怪しい点がありますね。

• バグの報告数が最も多いリリースは、Claudeが共同執筆したコミットが初めて含まれる直前の、1月にリリースされた版です。もしかして、AIが書いたと明記されていないコードがそこに含まれていた可能性はありませんか？

• リリース時の帰属（attribution）を判断する手法にも難があります。マイナーバージョンのアップデートで混入したバグが、そのマイナーバージョンの中で最も期間が長いパッチリリースに紐付けられてしまう傾向があるからです。3.4.1でバグが大量に混入したとは思えませんが、3.4.0の翌日にリリースされたため、結局そのリリースで発生したバグがすべて3.4.1のせいにされてしまいます。

• 関連して、最近のリリースほどバグを報告される時間が短いため、新しいリリースほどバグが少ないというバイアスがかかっている可能性があります。

この調査を批判するつもりはありません。膨大な時間と忍耐が必要だったはずです。素晴らしい仕事ですよ！

本格的な調査は、学術機関のようなグループが複数のリポジトリを対象に行うべきでしょうね。

LLMがソフトウェア開発をどう変えたかについては学ぶべきことが山ほどあるはずです。おそらく最も明確な分類方法は、「LLM不使用」を宣言しているリポジトリと、そうでないリポジトリ、あるいは中立なリポジトリで分けることでしょうね。

バグだけが関心の対象ではありませんし。私たちが議論している間にも、誰かがすでにそれに取り組んでいるような気がします。

コミット履歴を見ていたら、あるコミットとそのrevert（取り消し）を見つけました。

元のコミット: https://github.com/RsyncProject/rsync/commit/d046525de39315d625ffaef4fdd6e7cf12148016

- if (!ptr)
-  ptr = malloc(num * size);
- else if (ptr == do_calloc)
+ if (!ptr || ptr == do_calloc)

ptr = calloc(num, size);

これはClaudeが書いたものです。LLMの注意力が及ばない典型例ですね。すべてのメモリ確保を強制的にcallocへ置き換えてしまっていますが、これが正しいアップグレードとは限りません。巨大な配列や再帰的な確保を行う場合、これは大きなコストになります。

revertされたコミット: https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721f14a43219d73127b23b86fe00

このrevertのコミット説明文を注意深く読んでみれば、それすらもLLMが書いたものだと簡単に分かります。

元のスレッドを投稿した人の気持ちも分かりますよ。

私は20年以上プログラミングをしていますが、ずっと大好きですし、これからもそうでしょう。

数ヶ月前まではAI懐疑派でしたが、ClaudeとCodexのおかげで、自分の開発スタイルやスピードが想像もしなかったほど変わりました。結果としてコードの生産量は増え、バグを見つけることも増えました。

なので、Hacker Newsの記事に対するコメントで、AI生成物に対する極端な憎悪が向けられているのを見ると驚かされます。AIが手伝った、あるいは完全に生成したというだけで、プロジェクトが突然「適当なコード（vibe coded）」呼ばわりされるなんて……LLMユーザーに対する侮辱のつもりでしょうか。

90年代半ばにオフショア開発が広まったとき、「インド人開発者」に対して向けられた差別的な言葉を思い出します。2020年代半ばになって、今度はその対象がAIになっただけですね。

本当に理解できません。確かなのは、否定派がいようがいまいが、AI生成コードは今後も増え続けるということです。

コメントする皆さんへ。rsyncの作者がリンクしている以下の投稿を一読することをお勧めします。

https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0

（補足：ここ数年話してはいませんが、Tridgeは長年私の同僚でありメンターでした。十字軍のように叩く前に、彼の視点に目を向ける価値はあると思いますよ）

この投稿は、答えよりも疑問を多く投げかけてくるので、判断を下せません。

• なぜv3.4.1が最もバグが多く、しかもClaudeのコミットが入る直前だったのか？ なぜ誰も気づかなかったのか？ 単に「まあ人間がやったミスだろう」で済ませるには奇妙すぎます。
• なぜv3.4.2はバグが0、あるいはバグスコアが0なのか？ そして、なぜこのような外れ値（他のコミットには見られない）を統計に含めて、「Claudeはバグが多いのか？」というスコアを引き下げることを許したのか。正直、なぜこれが作者の分析で「赤信号」にならなかったのか理解できません。

高度な統計手法を使っているせいで、複雑に作り込まれた完成品のように見えますが、分析としては半分しか語られていないような印象を受けます。

すごく興味深い投稿ですが、一つ考慮すべき指標があると思います。ある領域でエージェント型のコーディングツールを使うと、別の領域でのコーディング能力に影響が出ないか？という点です。最近、周りでも「基礎力が鈍ってきた」という話をよく聞きます。私自身は、エージェントを並行で走らせつつ、必要な部分は手動でコードを書くというスタイルなので、そこまで感じてはいませんが……もし普段の仕事でプロンプトを入力するだけの人が、帰宅後にrsyncのようなプロジェクトで作業をして「鈍っている」としたら、それがバグにつながることもあるかもしれませんよね。

これを測定するのはさらに難しそうですが。

投稿者はある意味で釣り針を飲み込んでしまったわけですが、議論を終わらせるためには誰かがやらなければならなかったことでしょう。

実際のところ、たった一つの投稿を見てrsyncを「ゴミ」と呼ぶような人たちは、どんなデータを見ても納得しないでしょうね。返信欄を見ても、みんな細かな粗探しをして論点をずらしています。「もう一つClaude由来のコミットが見つかったら、もう安定したプロジェクトではなく『適当なゴミコード』だ」と言わんばかりに。

ソフトウェアというものは常に曖昧なものです。品質を扱うための客観的な手法なんてこれまで一度も確立できていません。LLMへの極端な憎悪は、人間が犯した重大なバグやミスに対して、責任をうやむやにしてしまうだけです。

一度立ち止まって、この分野の人たちともっと共感し、思いやりを持つべきです。まだ新しい技術でみんな実験中なんです。スレッドやX、Mastodonなどで怒りに任せて個人攻撃をしたり、プロジェクトをDDoS攻撃したりしても、良いことなんて一つもありません。

バグを見極めて品質を上げるにはどうすればいいか？ それはずっと昔から議論されてきたことなのに、今でもみんなベストな方法をめぐって喧嘩をしています。シンプルな設計、テスト駆動開発、ユーザーアンケートなど、全てが品質管理の代用として使われてきましたが、どれも万能ではありませんでした。昔はそうした曖昧さを互いに許し合ってきましたが、今はその曖昧さを武器に、他のクリエイターを引きずり下ろそうとしています。まあいいですが、もしオープンソースソフトウェアが本当に死にかけているとしたら、その原因はLLMと同じくらい、こうした有毒な空気のせいですよ。