Analyzegear
「開発現場で Claude Code を使い倒す」シリーズ5回目。今回は本番デプロイまで任せる話です。手作業のデプロイは、手順漏れと環境差で事故ります。だからこそ手順を決めて、検証までを一続きにして任せるのが効きます。WordPressの複数インストールとLaravelの、実際にやっている流れを書きます。
WordPress ― 転送 → 各所へ配置 → 反映 → 検証
私たちのサイトは、同じテーマファイルが本番の複数インストール（本体・実績・お知らせ・ブログ）と検証環境に存在します。デプロイはおおむねこの順です。
- ローカルで直したファイルをサーバの作業ディレクトリへ転送する（
scp）。 - そこから各インストールのテーマパスへ配置する（1ソースから全環境へ）。
- 固定ページや投稿の内容は
wp post update／wp post createで反映する。 - キャッシュを飛ばす（
wp cache flush）。 - 最後に必ず
curlで検証：HTTP 200 か、意図した文字列（数値や見出し）が入っているか、参照画像が 200 を返すか、余計な空要素が生まれていないか。
この「検証まで」を手順に含めるのが肝です。反映＝完了ではありません。反映したあと、本番URLを実際に叩いて「意図どおりになったか」を確認して、はじめて完了です。
Laravel ― 同期 → マイグレーション → キャッシュ
Laravel 側は、コードを同期（rsync）したあと、サーバ上で artisan migrate・各種 cache 生成を走らせます。公開ディレクトリに置くビルド済みファイルの扱いや、シンボリックリンクの張り直しも手順に含めておくと、毎回同じ状態になります。ここでも最後に公開URLの応答を確認します。
サーバ固有の地雷を手順に埋め込む
エックスサーバーで何度か踏んだ落とし穴は、CLAUDE.md と共通リファレンス（シリーズ第2回参照）に書いて、デプロイ手順にも直接埋め込んでいます。代表的なものを挙げます。
- PHP はフルパスの
php8.3で叩く。素のphpは古いバージョンのことがあり、そのままだと “platform check” で落ちます。 - WP-CLI も
php8.3経由で。サーバ既定のPHPや古いWP-CLIバイナリで動かすと、警告が大量に出て出力が埋もれたり、挙動が変わったりします。 composer.lockは本番のPHP版で生成する。手元の新しいPHPでcomposer updateすると、本番のcomposer installが壊れます。- 外部HTTPは古い libcurl の地雷に注意（環境によっては新しい接続方式で失敗する）。
こういう「その環境だけの前提」は、覚えていないと毎回踏みます。手順とドキュメントに書いておけば、AIはそれを踏まえて叩いてくれるので、事故が目に見えて減りました。
dev → 承認 → 本番、を崩さない
デプロイは、検証環境で確認して承認を得てから本番へ。第3回「危険な操作を安全に任せる」と同じ原則です。反映のスピードより、順番と検証を守ることが、任せて安心できる状態を作ります。
まとめ
- 転送 → 各所へ配置 → 反映 → curl で検証、までを一続きの手順にする。反映＝完了にしない。
- 1ソースから全環境へ。どこか1つだけ古い状態を作らない。
- サーバ固有の地雷（PHPのフルパス、composer.lock のPHP版固定など）を手順に埋め込む。
- dev → 承認 → 本番の順を守る。
次回はシリーズ最終回「『盛らせない』検算をコードで持つ」――AIに数字を作らせず、機械で検算する運用を書きます。
