Claudeはrsyncのバグを増やしたか？ 統計的分析

2026年5月下旬、rsyncプロジェクトは最近のリリースでのリグレッションがClaudeの使用に起因すると報告されたことから、AI支援コーディングに関する議論の焦点となった。しかし、36のrsyncリリース（v2.4.6からv3.4.3まで）に対する包括的な分布分析により、Claude支援リリースはバグ密度の点で過去のリリースと統計的に区別できないことが示された。

統計的結果：Claude vs. 過去のベースライン

Claude支援リリースは、過去のrsyncリリースの分布と比較して異常なバグ率を示さない。分析では、重大な脆弱性に対してコスメティックな問題よりも重みを付けるために、10コミットあたりの重大度加重バグ数（sev/10c）という指標を使用した。

  • 統計的異常なし: 正確な置換テストの結果、p値は46%であった。これは、過去の記録からランダムに2つのリリースを選んだ場合、Claudeリリースと同等かそれ以上にバグが多い確率が46%であることを意味する。
  • 中央値のパフォーマンス: Fisherの正確検定（p値 74%）により、Claudeリリースが過去の中央値バグ率を上回る可能性は他のリリースと同等であることが確認された。
  • 分布のブランケート: 2つのClaude支援リリース（v3.4.2 と v3.4.3）は四分位範囲（IQR）を逆方向に挟んでいる：v3.4.2 は実際のバグがゼロで、v3.4.3 はIQRのすぐ上に位置する。どちらも負の外れ値ではない。
  • コード量と欠陥率: Claude支援リリースは変更されたコード行数が大幅に多く（平均 3,756 行 vs. 非Claudeリリースの 696 行、p=5%）したが、重大度加重バグの絶対数は増加しなかった（p=77%）。

方法論と重大度スコアリング

単純なバグ数の落とし穴を回避するため、分析ではデータ収集と重大度加重のための構造化されたアプローチを採用した。

データソースと帰属

バグレポートはGitHubのissue、rsyncのBugzillaインスタンス、そしてrsyncメーリングリストから収集された。バグはレポート前に出荷された最新リリース、またはBugzillaで言及された特定バージョンに帰属された。

重大度加重

すべてのバグレポートは、シニア信頼性エンジニアとして機能するQwen 3 35Bにより0〜100のスケールで評価された。評価基準は「データ損失/破損」（90–100）から「コスメティック/低影響」（10–29）まで分類し、機能要望とスパムは0点としバグ数から除外した。

分析単位

分析単位は個々のコミットではなくリリースとした。このアプローチは批評家が主張する「リリース がよりバグだらけになった」という主張を反映しており、多くのバグが複数のコミットの相互作用から生じるか、リリースが最終化される前に後続のコミットで修正されるという事実を考慮している。

「怒り」の文脈付け

データは、rsyncの品質低下と認識されたものが実証的証拠というよりもソーシャルメディアによって駆動された物語であることを示唆している。

Claude以前の外れ値

特筆すべきは、データセット全体で最もバグが多いリリースはv3.4.1であり、Claude導入以前のリリースである。これは 39.39 sev/10c（9コミットで59バグ）を記録した。このリリースは同様の公的な非難を受けておらず、"AIの敵" の存在が実際のバグ率よりも v3.4.3 への反応に影響したことを示唆している。

リグレッションの因果連鎖

技術的議論では、リグレッションの増加は「vibecoding」ではなく、AI生成のセキュリティレポートの急増が原因とされている。メンテナーのAndrew Tridgellが指摘したように、AI対応のCVEレポートの洪水がrsyncの攻撃面に対する迅速かつ大規模な変更を余儀なくし、結果としてリグレッションの可能性が自然に高まった。

コミュニティの反論と批判

統計分析が害の証拠を見つけなかった一方で、コミュニティの一部メンバーは方法論とAIコードの性質について懸念を示した：

  • サンプルサイズ: 一部の批評家は、2つのデータポイント（Claudeリリース）だけでは決定的な結論を導くには不十分だと主張した。
  • 帰属バイアス: マイナーバージョンで導入されたバグがしばしば最も長く存続するパッチリリースに帰属されることがあり、v3.4.1 のデータが歪められる可能性があるという懸念が提起された。
  • 定性的低下: 一部の開発者は、定量的指標ではAIコードの「雑さ」を捉えきれないと主張し、意味不明な関数名変更や不適切なNULLポインタ処理など、直ちにバグを引き起こさなくても長期的な保守性を低下させる例を挙げた。
  • 「錆びた」メンテナー: エージェント的コーディングツールが人間のメンテナーを基礎的なスキルで「錆びさせ」、時間とともにエッジケースのエラーが増えるという理論が提案された。

"変更量の増加（したがってリグレッション数の増加）の引き金は、（主に）LLM対応のセキュリティ問題の流入であった。すなわち因果連鎖は次の通り：LLMs $\rightarrow$ 既知のセキュリティ問題が増加 $\rightarrow$ 通常以上の変更が必要 $\rightarrow$ 通常以上のリグレッションが増加。" — jbert on Lobsters

Sources