rsync の全リリース版におけるバグ分析：Claude アシストリリースは異常なほど不具合が多いのか？

0 · 免責事項：AI アシスタンスの活用方法について

本レポートの信頼性を確保するため、以下のように AI（Claude）のアシスタンス内容を明確にしています。

• データの独立性
  • 全ての指標、手法、データソースは、ペンシルバニア大学統計学修士号を取得した私の妻と協議し、私が独占的に選択いたしました。
  • 手法は妻のアドバイスに基づいています。「10 ラインあたりのバグ数」や「線形回帰モデル」はサンプル数が少なくノイズに影響されやすく不適切だと指摘されたためです。
• 分析アプローチ
  • 「Claude を活用したリリースが歴史的な分布の中でどの位置にあるか」、そして「そのほど（あるいはそれ以上に）悪い release が出現する確率は何か」という問いが核心です。
• 手作業と自動化のバランス
  • 数日間の集中作業を経て、レポート全体を書き直す大規模な改訂を行いました。
  • データ取得やスクリプト記述は AI に支援されましたが、すべての数値・グラフ・統計量は Python スクリプトによって自動的にテンプレート化されており、幻覚や不整合を排除しています。
• 公開後の対応
  • 投稿後に実質的な反応が少なかったため、当初 AI に作成させたプロース（文章）を全て自筆で書き直しました。

---

1 · 背景：rsync の怒り

2026 年 5 月下旬、rsync コミュニティにおいて「AI 使用による機能低下」との主張が爆発的な反響を呼びました。

• きっかけ
  • Mastodon 上で、「バージョンアップ時の回帰（機能低下）」と「Claude のコミット」の間には虚偽の相関があると主張する投稿が行われました。
  • これは無数の称賛を受け、AI への畏怖や怒りが広まりました。
• Hacker News の炎上
  • GitHub アイス「Please Do Not Vibe Fuck Up This Software」が作成され、350 以上のコメントが集まりました。
  • コメントには暴力的な内容が含まれ、開発者に攻撃的な発言が行われました。
• 核心的な主張
  • 「非常に安定していたツールを、『vibe coding』によって品質が著しく低下させた」という意見が主流となりました。
  • 実際のリターンは Linux Mint の Timeshift ツールにおける回帰など、Claude アダプター後の機能低下と結びつけられました。

本分析は、この「怒り」の正当性を客観的なデータに基づいて検証することを目的としています。

---

2 · 要約

バグデータを伴う 36 のリリース（v2.4.6 〜 v3.4.3）を解析した結果、以下の結論に至りました。

• Claude コミットを含むリリースは極めて少数
  • 対象期間内において、Claude を使用したリリースは всего 2 つのみです：

    • v3.4.2

      （バグ数：0）

    • v3.4.3

      （バグ数：28）
• 統計的に異常な結果ではありません
  • 正確な置換検定における p 値は 46% です。これは、ランダムに 2 つのリリースを選んでも、観測されたほど悪い結果が出る確率はほぼ半分であることを意味します。
  • フィッシャーの正確検定（p 値=74%）では、Claude リリースが歴史的中央値より高いという確率は統計的に有意ではありません（オッズ比：1.06）。
• 歴史的な外れ値が存在する
  • 平均バグ数は Claude を使用していないリリースの方が約 1.8 倍高い傾向にあります。
  • 特に、Claude アシスト導入前の

    v3.4.1

    は、データセット全体で最もバグ率が高かった（39.39 sev/10c）という驚くべき事実が確認されました。

---

3 · メトリック：分析方法の詳細

分析では「コミットあたりの数」といった単純な指標を避け、「10 コミットあたりの重症度加重バグ数（sev/10c）」を主要指標としました。

計算式

$$ \text{sev/10c} = \left( \frac{\sum (\text{severity}/100)}{\text{total_commits}} \right) \times 10 $$

バグの重症度評価（Rubric）

各バグを 0–100 スケールでスコアリングし、LLM が割り当てた重症度を基準としています。

スコア	カテゴリ	具体例・説明
90–100	データ損失/破損	サイレントなデータ破損、ファイル喪失、セキュリティ脆弱性（RCE など）。
70–89	クラッシュ/フリーズ	クラッシュ、ハング、ビルド失敗、機密データ漏洩。生産環境で動作不能。
50–69	機能回帰（重大）	以前動作していた機能が壊れ、回避策が必要。パフォーマンスの劇的低下。
30–49	軽微な回帰	エラーメッセージの混乱など、動作自体は成功するが不便なこと。
10–29	コス metic/低影響	ドキュメント誤り、UX の不快感、テスト専用問題。
0	機能リクエスト	新しい機能要望やデフォルト動作の変更（バグではないため除外）。

分析のロジック：なぜ「リリース単位」なのか？

批評家の主張は「Claude のコミットがあるだけでリリース全体が悪化する」という点にあります。したがって、以下のようなアプローチをとりました。

1. リリース単位の比較: Claude コミット自体の複雑さだけでなく、最終的にユーザーが使う「リリース全体」の品質を比較します。
2. 帰属の問題: 「どのコミットがバグの原因か」は調査コストが高く不明確な場合が多いです。リリース全体の品質変化を見るのが現実的です。
3. 分布での位置付け: Claude リリースが、過去 36 リリースという歴史的分布の中で「外れ値（異常値）」なのか、「中央付近の普通なもの」なのかを判定します。

---

4 · 結果：データに基づく客観的事実

Claude リリースの実態

• v3.4.2:

  0.00 sev/10c

  （バグ数 0）。第 0 パーセンタイル（最良の一つ）。
• v3.4.3:

  3.29 sev/10c

  （バグ数 17）。第 77 パーセンタイル。

これらは、赤い旗となるほど悪いわけではありません。

統計的検定結果

• 正確な置換検定 (Exact Permutation Test)

  • p 値：46%
  • 解釈：ランダムに 2 つのリリースを選んでも、Claude グループと同じくらい（またはそれ以上に）高いバグ率を持つグループは約半数存在します。つまり、「異常」として識別できません。

• フィッシャーの正確検定 (Fisher's Exact Test)

  • p 値：74%
  • オッズ比：1.06（ほぼ 1:1）
  • 解釈：Claude リリースの方が、歴史的中央値よりも高い方に落ちる確率は有意に高くありません。

分布とコミット数の比較

• コミット数: Claude リリースの方がコミット数は少ないですが（p=88%）、これは異常ではありません。
• 変更行数: クロードリリースの方がコード変更量は多いですが（p=5%）、バグ数はむしろ少ない傾向にあります。
• バグ数: 平均バグ数は

  sev/10c

  が約 5.6 ですが、非-Claude リリース（約 14.9）に比べて劣っています。

レジームチェック（時期による影響）

早期の rsync リリースは一般的に不安定であり、近年は安定しています。したがって、Claude リリースと最新の安定したリリース群のみを比較する必要があります。

• v3.x 内での比較: v3.x の歴史的年平均（4.23 sev/10c）に対し、Claude リリース（平均約 1.65）は極めて良好な品質を示しています。
• Wald-Wolfowitz ランズテスト: p=0.06 で、歴史的数据のノイズを含めても、外れ値として扱えるほどの特異性は認められません。

驚きの発見：Claude 以前のアウトライア

データを探した結果、rsync の歴史で最もバグ率が高かったリリースは、Claude が導入されるずっと以前のものでした。

• v3.4.1 (Claude 未使用)
  • バグ/10c: 39.39（データセット最高値）
  • このリリースにおいて 59 のバグが 9 つのコミットに含まれていました。
  • 当時、この異常な高バグ率に対し「怒るべき AI」はおらず、開発者は通常通り修正を行いました。

---

5 · データが一致し、不一致していること

✓ 「Claude リリースは歴史的リリースとの間で統計的に区別不能」

• 1 つのリリース（v3.4.2）は IQR を下回り、もう 1 つ（v3.4.3）はわずかに上回っています。
• どちらも外れ値ではなく、歴史的な分布の中に完全に収まっています。

✓ 「怒りは単一事象に基づいて選択され、物語化された」

• Mastodon ユーザーは v3.4.3 の回帰に気づき、「Claude が原因だ」と結論付けました。
• しかし、v3.4.3 は統計的に異常な値ではなく、8 件の他の歴史的リリースも同等以上のスコアを持っています。相関はノイズです。

✗ 「一般的に Claude コミットは物事を悪化させず、今後も悪くしない」

• 将来的な外挿を主張するわけではありませんが、現状のデータ（2 つのリリース）を見る限り、AI は「世界を崩壊させる」というほど有害であるという証拠はありません。むしろ現在のリリースは極めて普通です。

✗ 「回帰は自分自身を語っている」

• v3.4.1 という、Claude を導入する前のリリースこそが、データ上最も深刻な問題を抱えていました。歴史を無視した批判は正しくありません。

---

討論と Tridge の応答

「なぜ人々は AI が rsync を壊したと信じるのか？」という問いに対し、以下の要因が挙げられます。

• 単純な盲目的怒り: LLM への先験的な不信感。
• 交絡因子（Confounding Factors）の誤認識:
  • HN や Lobste.rs のユーザーは、「セキュリティ修繕」や「既知の脆弱性の修正」をきっかけに大規模なコード変更を行ったことが、回帰を増加させたことを指摘しました。これは「AI のせい」ではなく「より多くのセキュリティ作業」という事実です。

最終的に、開発者である Andrew Tridgeell（Tridge）は、以下の通り AI への過度な恐怖と時代遅れの哲学を戒めました。

「私は LL M がどのように機能するかを知っています（おそらく！）。しかし、それはそれらが役に立たないことを意味しません。それは注意が必要ですという意味であり、私は注意を払っています。」 — Andrew Tridgeell

結論 「Claude をアシストしたリリースは異常にバuggy である」という主張は、統計的事実（p=46%）および歴史的数据（v3.4.1 など）と矛盾します。現在の怒りはデータに基づいておらず、AI アシストの成果を正しく理解していない状態にあります。