並行セッションが走っていても、本番サイトを壊さずにデプロイする

01何が起きかけたか

WorkPilot の LP は、複数の AI セッションがそれぞれのスレッドから触っています。その結果、本番サーバーのほうがリポジトリより新しい状態が、実際に2回ありました。

8月末：「作った人」セクションの新しい版が本番にだけあり、リポジトリの site/ は3日前の版のまま。新しい版は git に一度もコミットされていなかった
9月9日：プレス資料ページのスクリーンショット5枚（計 2.7MB）が、本番サーバーにしか無かった。著者写真も同じ状態だった

どちらも、site/ をフォルダごと同期していたら黙って消えていました。エラーは出ません。コマンドは「成功した」ように見えるのが厄介なところです。

もう1つ、本番の .htaccess はサーバー上で直接編集して HTTPS 強制を有効にしています。ローカルに古い設定が残っていれば、同期した瞬間に HTTPS 強制が外れます。

転送するのは、今回変えたファイルだけ。名指しで送ります。

✗ フォルダごと＋削除同期bash

$ rsync -av --delete site-deploy/ server:public_html/

deploy.shbash

# 変えたファイルだけを名指しで送る
$ rsync -v --stats index.html press.html server:public_html/

⚠ GOTCHA

--delete は「ローカルに無いものは不要」とみなします。サーバー側にだけある認証用ファイルや、サーバー上で直した設定は、ローカルに無いという理由だけで消えます。

ローカルにバックアップがあっても、壊れるのはサーバー側です。戻す材料もサーバーに置きます。

backupbash

$ ssh server 'cd ~/site && tar czf backup_2026-09-11_before_blog.tar.gz -C public_html .'

ファイル名に日付と「何の前か」を入れておくと、半年後の自分も、次のスレッドの AI も迷いません。

並行して動くセッションが、本番だけを先に直していることがあります。上げる前に本番を落として、差分を見ます。

check-prodbash

$ curl -s "https://example.com/?cb=$(date +%s)" -o /tmp/prod.html
$ diff /tmp/prod.html site/index.html && echo "same"

NOTE

?cb= はキャッシュ回避です。フロントのキャッシュが HTML を10分持つ環境だと、上げた直後の確認で古いレスポンスを見て「反映されていない」と誤判定します。

この3つのルールは、WorkPilot の接続メモ（ナレッジごとの _access_playbook.md）に書いてあります。メモは、そのナレッジをつないだスレッドで毎回 AI への指示に添えられます。だから次にデプロイを頼んだ AI も、同じ地雷を避けて動きます。

「前回うまくいったやり方」を、人間が覚えておかなくていい。これが、自分の開発で WorkPilot を使い続けている一番の理由です。