2026年 macOS Sequoia で openrsync が採用された理由とリモートビルド同期への影響
Apple は macOS Sequoia で長年使われてきた rsync を openrsync に置き換えた。主な理由は GPLv3 ライセンス方針との関係で、システム付属の rsync 2.6.9 は古く、新版 rsync 3.x は GPLv3 のため、Apple は BSD ライセンスの openrsync を採用して配布上の制約を避けた。開発者にとって openrsync は軽量でパフォーマンスも改善しているが、リモートデーモンモード（rsync daemon）や ACL、一部の権限同期の挙動は rsync 3.x と異なる。パイプラインがこれらの機能に依存している場合は、Homebrew の rsync 3.x を継続するか、openrsync の機能範囲に合わせてスクリプトを調整するかを事前に検討する必要がある。
リモートビルド同期では、主に三つの点が影響する。増分チェックと delta 転送の互換性、転送先の権限・タイムスタンプの保持度、既存 CI（GitHub Actions や Jenkins など）の rsync コマンドとの互換性だ。「ローカルからリモートディレクトリへの同期だけ」であれば openrsync で十分な場合が多い。デーモンモードや複雑な ACL、複数ノード間の同期が必要なら、従来どおりフル版 rsync の利用を推奨する。
rsync と openrsync の機能比較表：権限・ACL・リモートデーモンの違い
リモートビルド同期でよく使う機能について、システムの openrsync と Homebrew rsync 3.x を比較した。
| 機能 | システム openrsync (Sequoia) | Homebrew rsync 3.x | ビルド同期への影響 |
|---|---|---|---|
| 増分 / delta 転送 | 対応 | 対応 | どちらでも増分同期は可能で差は小さい |
| リモート daemon モード | 制限ありまたは挙動差異 | 完全対応 | CI で rsync:// から成果物を取得する場合は Homebrew rsync 推奨 |
| ACL / 拡張属性 | 一部対応 | 完全対応 | 権限を厳密に保持したい場合は rsync 3.x を選択 |
| --fake-super | ロードマップ上で検討中 | 対応 | root 以外で full permissions を保持する場合に必要 |
| 保守・アップデート | OS 更新に追随 | brew upgrade rsync | 長期的な制御は Homebrew の方が柔軟 |
結論として、「ローカルまたは CI からリモート Mac のディレクトリへの増分プッシュ」だけで、デーモンや複雑な ACL に依存しないなら、まずはシステムの openrsync を試してよい。そうでない場合は、ビルドノードで brew install rsync を統一し、/opt/homebrew/opt/rsync/bin/rsync を明示するか PATH で優先し、システムの openrsync と混在しないようにする。
リモート Mac でのビルド成果物同期の推奨構成（Homebrew rsync / Docker rsync / SFTP）
よくある三つのやり方と、それぞれの適用場面・注意点をまとめる。
- Homebrew rsync： リモート Mac で
brew install rsyncを実行し、CI やローカルから SSH でその rsync を呼び出す。SSH アクセスを標準化しており、rsync の全機能を維持したいチームに向く。PATH で Homebrew 版を優先し、システムの openrsync と混在しないようにする。 - Docker rsync： リモート Mac 上でコンテナとして rsync 3.x を動かし、バージョンと挙動を固定する。複数ノード・複数 OS が混在する環境に向くが、イメージとネットワークの管理が必要で複雑になりやすい。
- SFTP ゲートウェイ + ディレクトリ分離： rsync デーモンに頼らず、SFTP でビルド成果物のアップロード・ダウンロードを行い、ディレクトリ権限と監査を厳格にする。権限境界・監査・複数ロールでの配布を重視するチームに向く。増分同期も必要なら、SFTP でアクセスを制御したうえで「許可したディレクトリ」内で rsync over SSH を使う構成が現実的だ。
実際には「SFTP でアクセスと権限を担い、rsync で大量の増分同期を行う」ハイブリッド構成を採用するチームが多い。SFTP で認可されたアカウントだけが指定ディレクトリにアクセスし、その中で rsync が効率的な増分転送を担当する形で、セキュリティと効率を両立できる。
ENOSPC・ECONNREFUSED などよくある同期失敗の確認と対処
5 ステップの確認フローと対応の考え方を示す。
# 1. 使用している rsync のパスを確認（openrsync との混在を防ぐ）
which rsync
/opt/homebrew/bin/rsync --version
# 2. SSH と転送先のディスク容量を確認（ENOSPC を防ぐ）
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inode 枯渇の有無
# 3. 転送先がリッスンしているか確認（ECONNREFUSED を防ぐ）
# rsync デーモン利用時: netstat -an | grep 873
# rsync over SSH 利用時: sshd が動いているか・ファイアウォールで 22 を許可しているか
# 4. ドライランで転送対象を確認
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. 本番実行とログ保存
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC： 転送先ディスクまたは inode が満杯。転送先の整理・古い成果物のアーカイブ・容量増強を行う。必要なら CI に「同期前にディスク容量をチェックする」ステップを追加する。
ECONNREFUSED： 相手がリッスンしていないかファイアウォールで遮断されている。SSH の場合は sshd と 22 番ポートを確認。rsync デーモンの場合は 873 番と rsyncd.conf を確認する。
Permission denied / 権限まわり： 転送先ディレクトリの所有者が SSH ユーザーと一致しているか、ACL や --fake-super に依存していないかを確認する。権限を完全に保持したい場合は Homebrew rsync を優先し、そのドキュメントを参照する。
選定チェックリスト：チーム規模・OS バージョンに応じて rsync/openrsync か SFTP ホスティングか
- 単一マシンまたは単一ノードで、Sequoia 標準の openrsync で足りる場合： システムの rsync をそのまま使い、スクリプトではデーモンや複雑な ACL に依存しないようにする。
- 複数ノードの CI でデーモンや厳密な権限が必要な場合： 各ノードで Homebrew rsync を入れ、そのパスを固定して使う。
- 権限境界・監査・複数ロールでの配布を重視する場合： SFTP ゲートウェイとディレクトリ分離を導入し、必要に応じて許可ディレクトリ内で rsync over SSH を併用する。
- 単一マシンや rsync バージョンへの依存を減らしたい場合： ビルド成果物のホスティングを SFTP を提供するリモート Mac ホスティングに任せ、可用性と権限ポリシーをサービス側で担保し、ローカルや CI はアップロード・ダウンロード・検証に専念する構成を検討する。
rsync と openrsync は「ディレクトリ単位の増分同期」であれば多くのケースで問題なく動く。体験を左右するのは、バージョンの統一・パスの一貫性・障害時の迅速な切り分けだ。チームが大きくなり、コンプライアンスや監査の要件が高くなると、rsync だけでは不足し、SFTP のような明確なアクセス層と安定したリモート環境が必要になる。
macOS Sequoia でなぜシステム標準の rsync が openrsync に変わったのか？
GPLv3 ライセンスと Apple のポリシーが合わないため、Apple は macOS Sequoia で従来の rsync を BSD ライセンスの openrsync に置き換えました。openrsync は軽量でパフォーマンスも改善していますが、リモートデーモンモード・ACL・一部の権限同期で rsync 3.x と挙動が異なるため、リモートビルド同期では互換性に注意が必要です。
リモート Mac のビルド成果物同期には rsync と SFTP のどちらが向いている？
チームで rsync を統一しており増分・チェックサムが必要なら、Homebrew の rsync 3.x を継続利用できます。権限境界・監査・多役割での配布を重視するなら、SFTP ゲートウェイとディレクトリ分離の方が運用しやすいことが多いです。両方の併用も可能で、SFTP でアクセス制御と権限を担い、rsync で大量の増分同期を行う構成がよく使われます。
同期で ENOSPC や ECONNREFUSED が出たときの確認手順は？
ENOSPC は転送先ディスクまたは inode が満杯であることを示します。転送先の整理・アーカイブ・容量増強を行ってください。ECONNREFUSED は相手側サービスがリッスンしていないかファイアウォールで遮断されている状態です。sshd・rsync デーモン・SFTP のポートが開いているか、ローカルとリモート Mac のネットワーク・ファイアウォール設定を確認してください。
自前の Mac や CI ノードで rsync/openrsync のバージョン管理やネットワーク・ディスクのトラブル対応に時間を割くより、ビジネス成果の出し方に集中したいなら、ビルド成果物の同期と権限制御をリモート Mac ホスティングに任せる選択肢がある。SFTPMAC は安定した SFTP とディレクトリ分離を提供し、rsync over SSH による増分同期にも対応している。ノードの可用性と権限ポリシーは当方で担保するので、あなたはビルドとリリースに集中できる。