2026 年に現場で起きやすい三つの痛み
1) 読み書きの交錯。 転送ウィンドウ中、ユーザーは新 HTML と旧アセット、あるいはその逆の組み合わせを取得する可能性があります。
2) 部分失敗後の曖昧さ。 どのファイルが最終的に正しいかを名指しできず、復旧に時間がかかります。
3) 監査と鍵管理。 共有アカウントはログの粒度を粗くし、鍵ローテーションを難しくします。
なぜ in-place SFTP は依然として高リスクか
問題はプロトコルではなく「公開ディレクトリを継続変異させる」ことです。新しいディレクトリに完全なスナップショットを構築してからシンボリックだけを切り替えれば、利用者が見るパスは検証完了まで旧版のままです。rsync はファイル単位でも、宛先が新規フォルダであればこの性質を保てます。
意思決定表：直接上書き対ステージング＋シンボリック
| 観点 | in-place | releases + current |
|---|---|---|
| 中間状態の露出 | 長い | 切替の一瞬に限定 |
| ロールバック | 再転送が多い | 旧ディレクトリが残れば数秒 |
| CI 連携 | 順序ミスが出やすい | 同期・ゲート・切替の三段階で標準化 |
五手順のコマンド例
TS=$(date +%Y%m%d%H%M)
mkdir -p /srv/app/releases/$TS
rsync -av --delete-after --exclude '.git' ./dist/ deploy@remote-mac:/srv/app/releases/$TS/
ssh deploy@remote-mac "test -f /srv/app/releases/$TS/index.html && shasum -a 256 /srv/app/releases/$TS/index.html"
ssh deploy@remote-mac "ln -sfn /srv/app/releases/$TS /srv/app/current && readlink /srv/app/current"
Web サーバのドキュメントルートを current に向けてください。
ゲート指標と監査フィールド
最大成果物サイズの 2.5 倍 以上の空き容量を維持します。CI タイムアウトは中央値の 3 倍 を目安にします。監査ログには実行者、UTC 時刻、ホスト、$TS、切替前後の readlink を残し 90 日 保管を推奨します。デプロイユーザーは releases/* のみ書き込み、実行ユーザーは current 経由で読み取りのみに分離します。
ロールバックと SFTPMAC リモート Mac の価値
- 旧
$TSが残っていることを確認する。 ln -sfnでcurrentを旧版へ戻す。- 代表ファイルのハッシュとエラーレートを短時間監視する。
このパターンは自宅の Mac mini、クラウド Mac、マネージドのリモート Mac のいずれでも同じです。差はディスク監視、外向き帯域、常時稼働のコストです。リリース頻度が上がるほど、ディレクトリ隔離と SFTP 准入をプラットフォーム側に任せる利得が大きくなります。
SFTPMAC は開発者と CI 向けのリモート Mac と SFTP を提供し、隔離パス内で同じ rsync＋シンボリック運用を続けながら、到達性と権限ベースラインをサービス側で支えます。自管ノードの夜間障害対応を減らし、プロダクト配信に集中したいチーム向けです。
in-place SFTP の主な問題は？
転送中の混在状態と、失敗後のスナップショット不明瞭さです。
原子リリースを維持したまま運用負荷を下げるには、SFTPMAC のプランとノード仕様を確認してください。