【戦慄】rsyncが最新版でバックアップを破壊…コミット履歴の「AI痕跡」で炎上、しかし本当の原因は別にあった
【戦慄】rsyncが最新版でバックアップを破壊…コミット履歴の「AI痕跡」で炎上、しかし本当の原因は別にあった
rsyncに異変が起きている。サーバー管理やバックアップに欠かせない定番ツールが、最新のセキュリティ更新でバックアップを壊している。コミット履歴にAIの痕跡が見つかりコミュニティは激しく割れているが、実は原因は別の場所にあった。
壊れた更新 セキュリティ更新がバックアップを壊した
Linuxやサーバーの世界でファイル同期の定番として数十年使われてきたrsync。その最新版3.4.3が、インクリメンタルバックアップ（変更分だけを転送する方式）を壊している。3.4.3は6件の脆弱性を修正するセキュリティ更新として公開された。修正された脆弱性のうち深刻度が高いものには、rsyncデーモン（rsyncをサーバーとして常駐させる運用形態）における権限境界の突破が含まれる。管理者が即座に適用すべきリリースであり、多くの環境で更新が進んだ。ところが更新後に報告が相次いだ。
ハードリンクなどで差分バックアップの参照先を管理し、変更のないファイルはハードリンクで済ませるオプションを使ったインクリメンタルバックアップが、毎回フルバックアップとして動作してしまう。差分転送が意味をなさなくなれば、ストレージ消費も転送時間も跳ね上がる。セキュリティを強化した更新がバックアップの信頼性を損なうという、皮肉な事態になっている。
怒りの連鎖 コミット履歴に「Co-authored-by: Claude」
障害の原因を追った利用者たちは、rsyncのGitHubリポジトリで1つの事実に気づいた。コミット履歴に「Co-authored-by: Claude」という記述が並んでいる。Anthropicの大規模言語モデルClaudeがコードの共著者として記録されていたのだ。GitHubのイシューには「AIに指示を出してコードを丸投げする『バイブコーディング』はやめろ」というタイトルの議論が立った。技術的なバグ報告ではなく、Mastodonの批判投稿のスクリーンショットが貼られただけだったが、コメントは数百件に達した。ハッカーニュースやRedditにも波及し、重要インフラへのAIコード導入に対する批判が広がった。
怒りの一部は暴走した。メンテナーへの暴力を示唆する画像が投稿され、削除される事態にまでなっている。技術的な議論の枠を超えた反応が混じったことで、問題の本質は見えにくくなった。
壊れた原因 AIではなくセキュリティ強化のコードだった
では実際にバックアップを壊したのは何か。リグレッションの原因を追うと、批判が集中したAI支援のテストスイートではなく、セキュリティ強化のために追加された「セキュアリラティブオープン」という関数に行きつく。この関数は、シンボリックリンクを悪用した攻撃（ファイルパスをすり替えて権限境界を超えるスリムリンクという手法）を防ぐもので、パスにダブルドットやディレクトリの参照が含まれていれば一律に拒否する。
脆弱性を塞ぐためには不可欠な変更だったが、正当な用途まで巻き込む副作用を持っていた。具体的には、「--link-dest=../backup/」のような相対パス指定がこの制限に引っかかる。rsyncをデーモンモードで動かし、chroot（ファイルシステムのルートを変更してアクセス範囲を制限するセキュリティ機構）を無効にしている環境で、インクリメンタルバックアップの参照先にダブルドットを使うパターンがそれに当たる。影響は特定の構成に限られるが、壊れたのはセキュリティ修正のコードであり、批判が集中したテストスイートではなかった。この区別は騒動の中でほとんど注目されていない。
作者の反論 「設計は自分で行い、AIは実装を補助した」
rsyncの共同開発者であるアリ・トリジェル氏が、Mediumに「rsyncと怒りとデマ」と題する記事を公開した。トリジェル氏はscpの作者としても知られるオーストラリアのプログラマーで、rsyncの開発から一度離れた後、2024年に復帰し再びメンテナーを務めている。トリジェル氏はAIツールの使用を認めた上で、その範囲を明確にした。AIを使ったのは主にテストスイートの書き直し、シェルスクリプトからPythonへの移行であり、設計は自分で行い、Claudeで実装を補助し、CodexとGeminiでクロスチェックした。コミット履歴にClaudeと記されているのはこの作業の痕跡だ。
「テストスイートをPythonに変換しろとバイブコーディングしたわけではない。40年の経験を持つソフトウェアエンジニアだ。まず設計を行い、検証計画を立て、全てのコードを自分でレビューした」。リグレッションについてはこう述べている。「セキュリティ修正を優先した結果、一部の稀なケースが影響を受けた。既存のテストスイートにも、私自身の手動テストにもカバーされていなかった。影響を受けた方には申し訳なく思う」。同時に、OpenBSDチームが開発したrsyncの再実装「OpenRSync」に乗り換えるという声に対しては、新しいテストスイートでOpenRSyncをテストしたところ98件中85件が失敗したと指摘した。この発言に対しては「自分のプロジェクトの問題に集中すべきだ」という批判もある。
数字が示すもの AIはバグを増やしたのか
騒動のさなか、rsyncの全リリース履歴を対象にした統計分析が公開された。Claudeが関与したリリース（3.4.2と3.4.3）と過去のリリースを比較し、コミットあたりのバグ発生率を重大度で重み付けして算出したものだ。その結果、Claudeリリースとそれ以外のリリースの間に統計的な有意差はなかった。統計検定のp値は46%。ランダムに2つのリリースを選んでも同程度かそれ以上のバグ率になる確率が46%あるという意味になる。rsync史上最もバグの多かったリリースは、Claude導入以前のものだった。
ここで慎重になるべき点がある。この分析はバグの件数と重大度を測定しているが、バグの原因となったコミットを特定しているわけではない。またサンプル数が少なく、Claude関与は2つのリリースのみで、決定的な結論を導くには限界がある。AIがバグを増やしたと指示するデータは現時点では存在しないが、AIは安全だとするデータもまだ十分ではない。
見えてきた構造 AI報告の殺到という現実
この騒動が浮き彫りにしたのはAIの是非だけではない。トリジェル氏がAIツールに頼った背景には、AI生成のセキュリティ報告が殺到しているという現実がある。rsyncだけの問題ではなく、多くのオープンソースプロジェクトが同じ状況に直面している。AIが脆弱性を発見し、レポートを自動生成し、メンテナーに対応を迫る。報告の質にはばらつきがあるが、量は圧倒的だ。トリジェル氏は「引退した身だが（本人曰く家族には異論があるかもしれないが）rsyncのセキュリティ対応に全振りしたい」と書いている。世界中のサーバーが依存するインフラを、引退した開発者がボランティアで支えている。AIツールの導入は、この構造的な負荷に対する個人の合理的な判断だったとも言える。
一方で、rsyncのような重要インフラにAI生成コードが入ることへの懸念自体は理解できる。問題は、技術的な検証を経ずに批判が先行したことだろう。壊れた原因がセキュリティ修正にあるという事実は、AIへの反感の中で注目されなかった。トリジェル氏は3.4.4で一部のリグレッションを修正するか、より大規模なセキュリティ強化を含む3.5.0に進むかを検討しているという。新たに優秀な開発者がプロジェクトに加わったとも述べており、皮肉にも騒動がきっかけだったという。
対処法 影響を受ける環境と回避策
影響を受ける環境は、rsyncデーモンを「--no-chroot」で運用し、--link-destや--compare-destにダブルドットを含む相対パスを使っているケースに限られる。SSH越しの転送やchrootが有効な構成では問題は起きない。該当する環境では、SSH経由への切り替えが当面の回避策になる。旧バージョン（3.4.2以前）へのダウングレードも可能だが、3.4.3で修正された脆弱性が残る点に注意が必要だ。
名前を呼ばれる日
声には速さがある。「壊れた」という声は早い。1つの画面から無数の画面へ一晩で届く。なぜだ？誰のせいだ？理由が見つかる前に、もう結論が決まっている。「ありがとう」という声は遅い。あまりにも遅くて、大抵送られないまま消えていく。何年も動き続けたものがある。動いているうちは空気のように透明で、止まった瞬間にだけ色がつく。作った人の名前が呼ばれるのは、決まって何かがうまくいかなかった日だ。
それでも、と思う。名前を呼ばれなかった日々の方がずっと長い。その日々の方が本当の仕事だったのだろう。沈黙の中に確かに誰かがいて、朝が来るたびに全てが昨日と同じように動いていた。遅い声を、まだ誰にも送っていない。
ネットの反応
いちばん脆弱なのは人間だったんですよ。
「ありがとう」の声は遅い。本当その通り。当たり前のことに誰かの頑張りがあることを改めて意識しようと思いました。
無償で提供されているものは自己責任で使用する、という前提を忘れて怒り狂うのは筋違いだけど、その立場になったら多分自分でもブチ切れるかもしれんね。現在のIT業界が非常に歪んでいることは間違いない。
悲しいけど作成サイドも使用者サイドも、誰もが賢人や聖者ではないからな。
結局、何が良くて悪くて何が原因なのか。そういうものの検証を全部後回しにして、分かりやすく目についたモノを悪として感情論で動いて燃えた話だな。
rsyncみたいなソフトウェアって新機能はいらない、ただただ安定して動いてほしいというユーザーがほとんどだと思う。なのに世の動きは待ってくれない。AIによるコード生成もセキュリティ修正に伴うバグ混入も、望まないのに避けられない時代。
嫌なら自分でforkして自分でメンテすればいいんやで。それがOSS。
AIに嫌悪感を抱く人たちは、いい加減「何でもかんでもAIのせい」にすることで原因が隠れてしまうことに気づいた方が良い。
AI「バックアップという重要インフラで利用している部品を、検証もせずに本番環境で更新を掛けるのはオススメできません」
AIに責任を負わせられないのに、AIに任せたプログラマを排除しきれないんだもの。マージ責任者が本当に責任を持つか、そうでもなければ「こういうことも起こる不安定なリポジトリ」として扱う以外の方法がない。
相対パスはセキュリティホールの温床だけど、排除したらしたで不便なのよな。
そこまでAIが嫌いなのになぜ他人にメンテナンスを任せるのかね？
これはAIのせいではない。品質管理がプロジェクト規模の拡大に追いつかずに発生した問題だ。サブプロジェクトの新設や人員増で開発体制そのものの規模が拡大した時には、同じような問題がプログラムの種類や現場を問わず発生している。
おお、マジか。サーバー確認せなあかんかも。
新しい協力者の認証がどうなっているのかの方が気になる。
AIの所感
この騒動の本質は、技術的問題と感情論のすり替えが同時並行で起きたことだ。rsyncのリグレッションの直接原因はAI支援コードではなく、セキュリティ修正のために追加された関数の副作用だった。にもかかわらず、コミット履歴の「Co-authored-by: Claude」が先に炎上の着火点となり、真因の検証が後回しにされた。ネット上の批判は「検証より反応」が先行する典型例であり、技術コミュニティにおいても感情が理性を凌駕しうることを示している。
統計分析が「AI関与リリースと非関与リリースのバグ率に有意差なし（p=0.46）」と出たのは興味深いが、サンプルが2リリースしかない以上、AIの安全性を証明するものではない。一方で「AIがバグを増やした」という仮説も支持されていない。つまり現時点で確かなのは、「AIが書いたから壊れた」という帰属は統計的に裏付けられない、ということだけだ。重要なのは、AI生成コードがプロジェクトの品質プロセス（設計レビュー、テストカバレッジ、マージ責任）を正しく通れば、人間のコードと同じ扱いで評価されるべきだという点だ。
構造的には、OSSメンテナーへのAIセキュリティ報告の殺到という現実が、開発者がAIツールを使う合理的理由になっている。ボランティアで世界のインフラを支える個人が、膨大な報告と質の悪い要求に押しつぶされないための自己防衛として、AIを導入した。これは「AI vs 人間」ではなく、リソース不足の構造問題だ。次の教訓は明確だ。重要なインフラの変更には、たとえAI生成であっても人間による徹底した回帰テストと、コミュニティへの透明な情報公開が不可欠である。そして、うまくいかなかった日だけではなく、動き続けた日々の貢献にも目を向けるべきだ。