2026年 リモートMac CIの二段階デリバリー：S3互換ステージングとrsync/SFTP着陸の原子性と権限

痛みの分解：成功ログでも読み取り側が壊れる理由

痛み1：その場上書きの可視化窓。テストランナーが未整合のディレクトリを走査すると、iOSのような強い依存では再現困難な署名やリソース欠落に見えます。

痛み2：同名パスへの再試行。CIは積極的に再試行します。バージョン化されたキーが無いと「どの試行のバイト列か」を説明できません。

痛み3：WANのRTTが帯域不足に見える問題。単一ストリームのSFTPやrsyncは往復遅延に弱いです。リージョナルバケットとマルチパートで並列性を前倒しし、Mac側は短距離フェッチに集中します。

痛み4：POSIX意味はキーだけでは表現しきれない。拡張属性やバンドル内シンボリックリンクはAPFS上の実ディレクトリが必要です。第二段階はその翻訳層です。

痛み5：コストと運用工数。ライフサイクルやIAMを担当者なしで増やすと、見栄えだけの複雑さになります。先にstaging+検証+シンボリック運用の規律を固定してください。

脅威モデルと境界

オブジェクト層は誰がいつ不変スナップショットを出したかを証明し、ディレクトリ層はどのスナップショットが現行かを原子に切り替えます。内部誤操作が主ならstagingで足りますが、悪意の置換が懸念ならmanifest署名を追加し、コード署名配布の文脈と揃えます。

SSH多重化併用時はデータ面と制御面のアカウントを分け、長いダウンロードが管理操作を塞がないようにします。Sequoiaの無人rsyncではPATHとssh-agentが再び効きます。Sequoiaの記事も参照してください。

測定指標の基線

PUT/GETバイト、マルチパート失敗率、manifest検証時間、current切替成功、ロールバック回数を週次で可視化します。単体成果物が約2GBを超えRTTが約180msを超えるならマルチパートが有利、約200MB未満で同一都市圏ならstaging+切替がTCOに有利になりやすいです。inodeとスナップショット空間も監視し、DerivedData同期とI/O競合しないようスケジュールをずらします。

七ステップ手順

1. 名前空間と資格情報を分離する。
2. manifestにSHA-256とパイプラインID、コミットSHAを書く。
3. マルチパートでオブジェクトへ載せる。
4. Macのinboxへ限定読取アカウントで取得する。
5. 検証に失敗したら切替を止める。
6. releases/BUILD_IDへ移しcurrentを更新する。
7. テレメトリと保持ポリシーを回す。

sha256sum -c manifest.sha256
ln -nfs "/srv/artifacts/releases/$BUILD_ID" /srv/artifacts/current

人間向けSFTPはupload/のみに限定し、chrootで半径を絞ります。

関連読みとCTA

Git内外の競合はLFS記事を先に。二段階は銀弾ではなく、隔離と証跡を買う設計です。帯域やディレクトリ契約が依然ボトルネックなら、専門運用のリモートMacレンタルで変動要因を製品化する選択も現実的です。