Claudeはrsyncのバグを増やしたのか？

• Claude支援リリースは rsync v3.4.2 と v3.4.3 の2件のみで、重大度加重バグ/10コミット基準では、過去のリリースより際立ってバグが多いという証拠はない
• sev/10c はバグの重大度スコアを 0〜1 に正規化してリリースごとに合算し、コミット数で割ったうえで 10コミット当たりの値に換算する中核指標である
• v3.4.2 は 50コミット・Claudeコミット 9件・バグ 0件・0.00 sev/10c、v3.4.3 は 34コミット・Claudeコミット 28件・バグ 17件・3.29 sev/10c で、どちらも IQR の両側に位置するが、いずれも 外れ値 ではない
• 正確置換検定 の p 値は 46%、Fisher の正確検定の p 値は 74%、オッズ比は 1.06 で、Claude リリースが無作為な 2つのリリースより悪い、または中央値超過になりやすいことを示す信号はほとんどない
• v3.4.1 は Claude 導入前のリリースであるにもかかわらず、59バグ・9コミット・39.39 sev/10c で全データ中最悪値だった。rsync 論争の核心は、歴史的分布 を見ずに単一の回帰を Claude と結び付けた点にある

---

背景と問い

• 2026年5月末の rsync 論争は、v3.4.3 の回帰とそのリリースの Claude コミットを結び付けた Mastodon 投稿から始まり、Hacker News と GitHub Issue "Please Do Not Vibe Fuck Up This Software" に広がり、その Issue には 300件を超えるコメントが付いた
• 繰り返し示された中心命題は、Claude 支援開発が安定していたツールにバグを持ち込んだというもので、データ上の問いは Claude 支援リリースが過去のリリースより異常にバグが多いかどうかである
• Lobsters ではリリースごとの回帰数を時系列チャートで見たいという要望が出ており、分析の焦点は「Claude 支援リリースは際立ってバグが多いのか」という単一の問いにある

データ範囲と再現性

• データは RsyncProject/rsync の v2.4.6 から v3.4.3 まで、バグデータがある 36件のリリースであり、Claude コミットがあるリリースは v3.4.2 と v3.4.3 の2件だけである
• 指標・方法論・データソースの選定は人手で行われ、統計学修士号を持つ配偶者の助言も反映されている
• データ収集、DuckDB への投入、ビュー作成、統計分析スクリプトは GLM 5.1 が作成したが、すべての数値・統計・カード・グラフは統計分析を実行した Python スクリプトが自動テンプレートで挿入した
• 再現用の alexispurslane/rsync-analysis リポジトリでは、パイプライン全体を最初から最後まで実行できる

指標とバグ帰属の方法

• 中核指標は重大度加重バグ/10コミットである sev/10c で、計算式は sev/10c = (Σ severity/100 ÷ total_commits) × 10 である
• コミットはデフォルトブランチの committer date 順に並べ、各リリース範囲は前のタグから当該タグまでのコミットとし、pre・rc タグは境界から除外して最終リリースに吸収する方式である
• バグの出典は GitHub Issue、rsync Bugzilla、rsync メーリングリストの3つで、GitHub Issue とメーリングリストのバグは報告時点の直前に配布されていた最新リリースに帰属させる
• Bugzilla 項目は "Version" フィールドがバグ報告対象のリリースを明示しているため、そのリリースに帰属させる
• リリース単位の分析を採用した理由は、批判自体が「Claude コミットを含むリリース全体でバグが増えた」という形を取っており、ほとんどのバグはどのコミットに由来するかが正確に明示されていないためである

重大度評価の方法

• すべてのバグ報告は Qwen 3 35B が 0〜100 点の重大度で採点し、プロンプトでは実際のユーザー影響の観点から判断するシニア信頼性エンジニアの役割を与えた
• 90〜100点は静かなデータ破損・データ損失・リモートコード実行または不正アクセスのセキュリティ脆弱性、70〜89点はクラッシュ・ハング・バックアップ失敗・ビルド失敗、50〜69点は回避可能な機能回帰と区分した
• Bugzilla とメーリングリストは本文がなくタイトル בלבדだったため、モデルはタイトルだけを見て評価し、情報が不足している場合は 40〜60 点の中間帯に寄せるよう指示した
• 出力は structured output の JSON schema で整数の重大度のみ許可し、temperature 0 に固定して同じ入力から同じ点数が出るようにした
• 機能要望、スパム、AI 関連の非技術的抗議、空の投稿のように 0 点になった Issue は基本のバグ数から除外した

Claude リリースの統計結果

• v3.4.2 は 50コミット中 Claude コミット 9件、実バグ 0件、0.00 sev/10c、0パーセンタイルのリリースである
• v3.4.3 は 34コミット中 Claude コミット 28件、バグ 17件、3.29 sev/10c、77パーセンタイルのリリースである
• 歴史的 IQR は 0.29〜2.59 sev/10c で、v3.4.2 は IQR のすぐ下、v3.4.3 は IQR のすぐ上にあり、2つのリリースが中間分布を反対側から挟む形になっている
• 正確置換検定 では、可能な 2リリース組み合わせ 595通りのうち 272通りが Claude グループ平均 1.65 sev/10c 以上となり、p 値 46% という結果になった
• Fisher の正確検定 では、中央値 0.74 sev/10c を基準に Claude リリースが中央値超過になりやすいかを見たが、結果は p 値 74%、オッズ比 1.06 だった

コミット数と変更規模

• Claude リリースは平均 42コミット、Claude を含まないリリースは平均 185コミットであり、任意の 2リリースがそれ以上のコミット数を持つ確率は 88% だった
• GitHub compare API ベースの変更行数は、Claude リリース平均が 3,756行、Claude を含まないリリース平均が 696行であり、任意の 2リリースがそれ以上の変更行数を持つ確率は 5% だった
• 重大度加重バグ数は、Claude リリース平均が 5.6件、Claude を含まないリリース平均が 14.9件であり、任意の 2リリースがそれ以上の重大度加重バグ数を持つ確率は 77% だった
• 結論として、Claude リリースは変更行数こそはるかに多かったが、コミット数や重大度加重バグ数が多いわけではなかった

バージョン体系と事前の外れ値

• v2.x リリースの平均は 1.11 sev/10c、v3.x リリースの平均は 4.23 sev/10c で、v3.x のほうが高いバグ率を示した
• v3.x のみで比較しても Claude リリースは中位圏かそれより良い位置にあり、Claude を外れ値のように見せるには、より静かだった過去の時代と比較し、Claude 以前にすでに起きていた変化を Claude のせいにする形になる
• Wald–Wolfowitz runs test は、Claude なしの 35リリースで観測 run 数 13、無作為期待値 18.5、z=-1.88、p=0.060 となり、0.05 基準では無作為性を棄却できるほど強くない
• v3.4.1 は Claude 導入前のリリースであるにもかかわらず、59バグ・9コミット・39.39 sev/10c で全データ中もっとも高いバグ率を記録したリリースである
• v3.4.1 は v3.4.0 の翌日に出た hotfix リリースで、他のすべてのリリースを一桁以上の差で上回る最高バグ率を示したが、当時は AI を責める対象がなかった

解釈と限界

• データと整合する解釈は、「現時点の 2つの Claude リリースは過去のリリースと統計的に区別できない」というものである
• v3.4.3 は 3.29 sev/10c で 77パーセンタイルと高めではあるが極端値ではなく、これより高いスコアを示した過去のリリースが 8件ある
• 「Claude が明らかに悪化させた」という命題は、リリース分布、置換検定、Fisher 検定のいずれからも裏付けられない
• 逆に、「Claude コミットは今後も一般的に悪化させない」という結論もこのデータからは導けず、現状では 2つのリリースが平凡な範囲に収まっていると言えるにとどまる
• この指標には、コミットの複雑さやセキュリティ作業の強度を統制できない粗いツールだという限界がある

議論された交絡要因

• Hacker News のあるユーザーは、CVE 対応のセキュリティ修正によって 2007年からコード中にあったコーディングミスが露呈したように見えると述べた
• Lobsters のあるユーザーは、「LLM → 既知のセキュリティ問題の増加 → 平常時より多い変更が必要 → 平常時より多い回帰」という因果連鎖を提示した
• Andrew Tridgell は、AI 生成の CVE レポートの洪水によって rsync の攻撃面に対する迅速かつ広範な変更が必要になったと説明した
• こうした交絡要因まで含めると、問題は Claude 自体というより、より多くのセキュリティ作業とそれに伴う変更量の増加に近い

[GN⁺]

Lobste.rsの意見

• 今後バイブコーディングで進められるFOSSプロジェクトを引き続き使うかどうかは、各自で判断できると思う。ただ、管理者がバイブコーディングツールへ切り替えた後にコミュニティが見せた怒りはかなり驚きだったし、記事に出てくる実証データは少なくとも、その慣行の変化による影響をよりよく文脈化してくれている
  管理者がこのコーディング方式を採用したことで信頼が保たれるのか、さらに崩れるのかは、時間が経たないと分からない

  • この移行に腹を立てた人たちのうち、実際にrsyncに意味のある貢献をしたり、お金を払ったりした人がどれくらいいるのか気になる

• この分析は私が望んでいたまさにその内容で、それ以上だった。特に「すべての指標、方法論、データソースは、Penn State Universityで統計学の修士号を持つ妻と相談して私が直接選んだ」という部分がよかったし、実際の統計専門家を関与させた点と、読みやすい文章にした点がすばらしい
  「コミット10件あたりのバグ数」という単一指標を使ったとのことだが、SI接頭語を使ってコミットあたりデシバグ(decibugs)と呼ぶ機会を逃したようだ

  • 同意する。私の文章ではないが、誰かが過熱した賛否を越えてコード品質に与えた影響をデータで示した点がよかった

• オープンソースプロジェクトの成功は認識に大きく左右されすぎるので、人々はGitHubスターを金で買ったりもする。残念ながら今回の認識の問題は制御を外れて一つの論点になってしまっており、どんなデータでもそれを変えるのは難しい
  今後「rsyncの管理者がLLMを使ったら壊れた」という話は、「データセンターは1日に50万ガロンのきれいな水を浪費する」「METRの研究はLLMが生産性を下げると言った」といった論点と並んで、AI懐疑論者が持ち出すものになるだろう
  私がAI懐疑論者かどうかを言いたいのではなく、このテーマの論争はたいていこういう流れになると言いたいだけだ

  • それがなぜ「論点」なんだ、ただの事実じゃないのか？
  • 筆者がデータで誰かを説得しようとしているのかは分からない。この記事は、rsyncのツール採用をめぐる辛辣な論争にデータの文脈を付け加えたものだと見ている
    ただ、記事から他の非定量的要素が完全に抜け落ちているという指摘はその通りで、伝道者と懐疑論者の双方のノイズがすでに十分あるので、あえてそうしたのだと思う

• rsync史上最悪のリリースはClaude導入前で、コミット10件あたりのバグが39.39件だった、という点は非常に重要で予想どおりの結論だ
  ユーザーと開発者の間にあるテストや品質保証のようなプロセスがソフトウェアの正確性を保証できなければ、LLMの有無にかかわらずバグは出荷される。LLMはこの過程に害を与えることもあれば、役立つこともある

  • 同意する。cURLの最近の記事は、その反対側の事例を示しているように見える
    すでに何年もかけて定着した強いソフトウェア工学の慣行のおかげで、似たようなAIツールでバグを見つける価値は全体として低くなっている
  • rsyncの将来についてはいくつか懸念がある。最大の問題は、rsyncが事実上ここ数年完成済みのプロジェクトだったのに、AIを使いながら既存のテストコードを取り外してPythonのテストスイートに置き換え、かなりの期間にわたって既存テストを並行運用して正確性を検証しなかったことだ
    私の基準では無責任だ。とりわけrsyncの主な目的は大切なデータを移動することであり、そのデータの完全性は絶対的に重要だ

• 「AI反対派のユーザーによくあるように、結局は暴力のファンタジーへとエスカレートした」といったレトリックは避けてほしい。筆者が同意しない一部の人々を一般化しているだけでなく、もともと同意しない読者の反感も買い、結果として本来いちばん読むべき人たちが記事を読まなくなる
  それとは別に、以前のバージョンよりバグが多いか少ないかは、私はあまり気にしない。私にとって重要なのは、自分が考えるソフトウェア開発のやり方と合わない方法で開発されているという点だ。効率性以外にも問題があるという基本的な理解がなければ、この立場が合理的だと説得できる見込みはない
  幸い、望まなければこのバージョンのrsyncを使わずに済むし、LLM使用以前から分岐した代替を選ぶつもりだ

  • この記事は怒りが強く出すぎていて、長く読めず途中でやめてしまった。公正であろうとしていた、あるいは少なくともそう見えたなら、もっとよかったと思う
    しかも、最初のバグレポートは人が殺到したイシューだったという、ずっと前に反駁されたミームを繰り返していたのもよくなかった。実際の最初のバグレポートは別にあった

• 正直、今の文章のほうが良いと思う。ただし「この指標はコミットの複雑さ、セキュリティ上の機微、バグの重大度を統制できていない。1行のタイプミス修正とCVEパッチを区別できない鈍い道具だ」という部分は、LLMは良くない側にいる自分の立場からすると、核心的な批判を外している。
  私や他の人たちが提起している批判は、AIがより大きく、理解しにくく、複雑さを増すコミットを大量に生み出させるということだ。LLM支持者も似たようなことを言いながら、何十年も検証されてきた「PRを読む」という慣行から、「LLMがすべてをテストできるようにすべきだ」へとゴールポストを動かしがちだ。しかし、コードの複雑さが技術的負債だという問題は消えない。
  今回のケースではバグの重大度は非常に高い。バックアップのワークフローが実際に壊れたからだ。rsyncはバックアップに広く使われており、人々はパッチ更新でバックアップスクリプトが壊れる可能性など想像すらしないほど、「実戦で鍛えられた」ツールとして信頼してきた。
  LLMがバグのあるソフトウェアを作ったのは偶然だったとか、メンテナがLLMの作業フローを変えてテストカバレッジを上げるべきだと言うことはできる。実際、メンテナもそう言っていた。しかし怒りの核心は、このツールがその信頼を壊したことにある。
  実際、最近では「コードをまったく読まない」と言う新しい類のLLMプログラマーたちがいる。読むのに時間がかかりすぎるし、普通のプログラマーのコードより把握するのが複雑だという理由だ。コードを読むというのは他人のメンタルモデルを学ぶことだが、LLMツールは一貫した1つのメンタルモデルを提供できない。
  別件だが、サイトのアクセシビリティも確認すべきだ。視力はかなり良くて20代後半なのに、クリーム色／黄色の背景の上にある明るい灰色の文字は本当に読むのがつらい。

  • 引用部分が紛らわしい。記事で使われている指標は、コミット10件あたりのバグ数に重大度の重み付けをしたもののように見えるが、筆者は自分で自分に矛盾しているのか？ それとも自分の読み違いか？
  • ワークフローが壊れたと言っている人たちにとっては、オープンソースソフトウェアとGPLライセンスが何であり、どんな保証を与えるのかを学ぶ良い機会だと思う。
    実際にそのバグを自分で見つけた人は多くないだろう。rsyncユーザーの90%以上は、そのバグのない以前のバージョンを使っているのではないかと推測する。私もその1人だ。

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    注目を集めた理由について言えば、今かなりの部分のコミュニティが混乱していることは、Steven Pinkerでなくても理解できる。LLMが人間よりプログラミングが上手いという事実は、受け入れやすいものではない。
    自分のアイデンティティや自尊心をプログラミング能力や職業に置いていた人たちは、将来の生計／市場価値の不確実性と、アイデンティティの危機という二重の危機に直面している。
    恐怖、不確実性、疑念は扱いにくく、LLM企業は株価を上げるためにその効果を増幅することに全力を尽くしている。10月以降に市場が急激に調整すれば、こうした増幅装置も弱まるかもしれないと思う。
    世界中のプログラマーのうちごく小さな割合、つまりコードを芸術形式として見る人たちは、おそらくLLMを訓練やスキル向上に使うだろう。

• この記事はリグレッションに言及したコメントを多く引用しているが、分析自体はリグレッションではなく、バグレポートだけを測定している。バグが導入されたリリースではなく、報告されたリリースにバグを結びつけていて、リリースの重大度はコミット数で測りつつ、リリース期間やディストリビューションでの採用状況のような明確な要因は除外している。
  これでどうして筋が通るのか分からない。

• 個人的には、LLMを使うプロジェクトは避けている。実質的な理由があるというより、ただひどく気持ち悪いからで、誰かが「kek」や「fren」みたいな言葉を使うと、特に理由がなくてもそれ以上関わりたくないというサインとして受け取るのに近い。
  今LLM利用を嫌う理由として挙げられている説明は、後付けの合理化のように感じる。倫理や品質といった現在の懸念はもっともだが、そうした問題が解決したからといって、私のようなAI反対寄りの人たちが急に平気になるとは思えない。
  だから「AGENTS.md」やClaude共同執筆コミットなどがあるプロジェクトは、具体的な理由がなくても避ける。ただ不快で、好みに合わず、バグがあるかどうかは関係ない。他の人たちも似たように感じていることはあると思う。

• 筆者に言うなら、第一にファンタジーは言葉だ。実際には言葉で止まったと主張しているのであって、少なくとも非言語的な拡大があったと主張しているわけではない。
  第二に、こういう主張をするなら、近くの統計専門家にどう裏付ければよいか聞くべきだ。何人かがそういう投稿をしたというだけでは、それが「典型的」だという主張を有意に裏付けることにはならない。
  統計で裏付けていない私の逸話的観察では、「AI反対」のユーザーは、LLMが役に立たない場面に割り込んでくることを、たいてい暴力的に感じるというより悲しく感じる側に近い。

  • ときどき、非常に冗長で詳細な文章で、LLM反対派の一部、たいていはLLMに感情的・社会的に反応している一部を反駁するものを見る。そういう文章は、なぜかはっきり説明しにくいが、とても不誠実に感じられ、弱い者いじめのように思える。
    詳細すぎて感情的な観点から反論しにくく、結局は「LLMが問題なのではなく、正しく使えば増幅装置になる。AI反対派は分かっていないだけで、取り残されるのが怖いだけだ」で終わるように見える。
    rsyncメンテナたちの作業を論争として矮小化したくもないので、自分がどうやって説得力のある反論を組み立てればいいのか分からない。
    ここでの統計は、オープンソース保守の観点からは興味深いかもしれないが、結論が妙に一方へ傾いていて、GitHub流のオープンソースは自分が貢献したい形ではない、という感覚が残る。
    それでも、rsyncのリポジトリに対してメンテナへ集団で押しかけたのはまったく良くないと思う。
  • 公然たる暴力的ファンタジーをよくないものだと呼ぶのは正しい。そういうものは文明として目指すべきことではない。ただ、筆者がそれを「典型的」と呼んだ部分は一般化なので引っかかる。
    逸話的観察については、この漫画はその通りだと思う。私は具体的で測定可能な主張を見るのが好きで、それは数字が好きだからでもあるし、オンラインでの議論が最後のコマの理想世界に少しでも近づくようにしたいからでもある。

• 分析には感謝するが、方法論にはあまり確信が持てない。コミットごとに中核コード、つまりテストやドキュメントではないコードの変更行数を掛けた差分単位のバグ数のような指標や、リリース後に特定のバグ数へ到達するまでにかかる時間の分析が気になる。
  ただし、今回のリリースは他のリリースよりはるかに多くの注目を集めたため、バグがより多く報告された可能性が高く、非常に説得力のある指標を作るのは難しそうに見える。『リリース後何週間という基準で典型的か？』のような問いも、あまり有用ではないかもしれない