Claude は rsync のバグを増やしたのか — 36 リリースの統計を運用者目線で読む

結論: 「Claude がバグを増やした」という直感は、統計では裏付けられなかった

rsync の最近のリリースで Claude（Anthropic の AI コーディング支援）が大量のコードを書き、それでバグが増えたのではないか。そんな疑いを、実際のリリース履歴で検証した分析を読みました。結論を先に言うと、バグ増加を支持する統計的証拠は出ていません。順列検定（ランダムに並べ替えて偶然どれだけ起きるかを測る検定）の p 値は 46%、Fisher 正確検定では 74%。どちらも「Claude 関連リリースが過去より悪い」という仮説を後押ししませんでした。

元ネタは Alexis Purslane 氏による rsync のバグ分析レポート（Did Claude increase bugs in rsync?）です。話題になったきっかけは、rsync v3.4.3 にバグが目立ったこと。AI が書いたコードが原因だと結びつける声が出たわけですが、レポートはそれを 36 リリース分の履歴という「分布」に置き直して検証しています。私はこの「単発の事例を分布の中へ戻す」姿勢が、運用者として一番の学びになりました。

何をどう測ったのか — sev/10c という物差し

この分析の肝は、バグ数をそのまま数えず「重要度で重み付けしたバグ / 10 コミット（sev/10c）」という指標に揃えたことです。リリースごとにコミット数が違うので、生のバグ数だけ比べても公平になりません。

具体的な数字を並べます。問題視された v3.4.3 は 3.29 sev/10c（バグ 17 件 / コミット 34 / うち Claude 関連 28）。一方その前の v3.4.2 は 0.00 sev/10c（バグ 0 件 / コミット 50 / Claude 9）でした。歴史的な平均は 2.95 sev/10c、Claude 関連リリースの平均は 1.65 sev/10c。つまり Claude が関わったリリースは、平均より「むしろ低い」側にいます。v3.4.3 は確かに悪い数字ですが、過去の四分位範囲（データの真ん中半分が収まる幅）を挟んだ位置にあり、外れ値とは言えませんでした。

ついでに言うと、歴史的に最悪だったのは Claude 以前の v3.4.1 で、9 コミットで 59 バグ。桁が違います。けれど当時これが炎上した記憶はありません。新しい容疑者が現れると、古い前科はあっさり忘れられるものらしい、と少し可笑しくなりました。

「コードは増えたがバグは増えていない」をどう読むか

注目すべきは、規模と品質が分離していた点です。Claude 関連リリースは平均 3,756 行を変更し、非 Claude 関連の平均 696 行のおよそ 5 倍。にもかかわらずバグ数はむしろ少ない。「より多くのコード、同じか少ないバグ」という結果でした。

コミット行数で見ると Claude 関連は p=5% で「明確に大きく変えている」と出ます。ところが深刻度加重バグ数では p=77%、つまり差が無い。変更量は飛び抜けて多いのに、欠陥の密度は上がっていない、という構図です。

この数字をそのまま「AI は安全だ」と読むのは早計だと私は思います。レポート自身が触れているとおり、v3.4.3 の変更は AI が生成した CVE（脆弱性報告）への対応で急いだことが背景にある可能性があります。原因はモデルそのものではなく、「急いだプロセス」かもしれない。私が auto-publish（AI が下書きを書き、私が確認して公開する仕組み）の品質チェックを回していても、事故が起きるのは決まって締め切りに追われて検証を飛ばした時で、道具より段取りの問題であることが多いという実感があります。これは以前書いた自動化は測ってから決める話とも地続きでした。

運用者がコードレビューで疑うべきは「分布の文脈」

実務に持ち帰る教訓は 1 つ、単発の回帰事例で因果を断定しないことです。「このバグは AI が書いた」という観測は事実でも、「だから AI はバグを増やす」は別の主張で、後者には分布が要ります。

• 比べる基準を持つ: 1 リリースの不調は、過去 N リリースの分布に置いて初めて意味を持ちます。基準が無いと、印象がそのまま結論になります。
• 指標を正規化する: 生のバグ数ではなく、コミット数や変更行で割った密度で見る。規模が違うものを並べて比べない。
• 「これからもっと出る」に警戒する: 漠然とした未来予測ではなく、観測できるデータの監視を優先する。

AI に判定そのものを委ねる怖さは別にあって、フロンティアモデルでも事実判定が割れる話は5 つの LLM が 67% で食い違う件で書きました。逆に Claude にバグを「探させる」側の運用は、Anthropic の脆弱性発見ハーネスが参考になります。書かせる・探させる・判定させる、どれも「人間が分布で検算する」工程を残すのが、いまの落としどころだと思っています。

まとめ: 犯人探しの前に、分布を見る

持ち帰る点を並べます。

• rsync v3.4.3 のバグは事実だが、36 リリースの分布では外れ値ではなく、Claude が原因という統計的証拠は出ていない（順列検定 p=46% / Fisher p=74%）。
• Claude 関連リリースは変更量が約 5 倍（3,756 行 vs 696 行）でも、深刻度加重バグ数では差が無い（p=77%）。
• 真因はモデルより「急いだプロセス」の可能性があり、コードレビューでは規模を正規化した指標と過去分布で疑うのが筋。

AI がコードを書く量が増えるほど、「AI のせいだ」と言いたくなる場面も増えます。けれど数字を分布に戻すと、たいてい話はもっと地味になる。地味な結論を地味なまま受け取れるかどうかが、運用者の腕の見せどころだと感じています。