レンタルサーバー時代のIaC的運用

本稿で目指すのはIaCそのものではなく、IaCの3つの価値をレンタルサーバー環境で再現することです。再現性:同じ手順を実行すれば同じ状態になる。可視性:何がいつ変わったかが履歴に残る。可逆性:問題が起きたら前の状態に戻せる。この3つが揃えば、root権限がなくてもIaC的と呼ぶに値する運用になります。

WordPressの構成要素を「コード」「状態」「コンテンツ」に分類することが出発点です。Git管理するのは、自作テーマ、自作プラグイン、設定ファイル類。Git管理しないのは、WordPress本体、サードパーティプラグイン、メディア、データベースです。

本体とプラグインはバージョン管理ではなくバージョン指定すべきものであり、メディアとDBはそもそもコードではありません。この分類で、リポジトリは「自分たちが書いたものだけ」というクリーンな状態になり、AIエージェントに変更を任せる際のコンテキストも明確になります。

リポジトリにplugins.txt（プラグイン名とバージョンの一覧）を置き、デプロイ時に適用するスクリプトを回します。これにより、本番のプラグイン構成がリポジトリの記述と一致し、「いつの間にか誰かが管理画面からプラグインを入れていた」という構成ドリフトを検出できます。

Terraformのような完全な収束はできませんが、「宣言と実態の差分を検出して警告する」だけでも運用の質は大きく変わります。差分検出はcronで日次実行し、ドリフトがあれば通知します。

第一に、必ずドライランを先に実行し、転送される差分を確認してから本番実行する二段階を踏みます。AIエージェントにデプロイを任せる場合も、ドライランの結果を人間が確認するゲートを挟みます。

第二に、--deleteオプションの扱いです。誤った除外設定と組み合わさると本番のuploadsを消し飛ばす威力があります。除外リストをスクリプトに固定し、手打ちでのrsync実行を禁止します。

第三に、デプロイ直前のスナップショットです。rsync実行前にテーマディレクトリをサーバー上でtarに固め、日付付きで保存します。「デプロイ直前」という復元ポイントを自前で持つことで、切り戻しが数分で完了します。

プルリクエスト時はPHP構文チェックとコーディング規約。mainマージ時はステージング環境（サブドメインに構築）へ自動デプロイし、Playwrightによるスモークテストを実行。本番デプロイは自動化せず、手動トリガーに人間の承認を挟みます。実行内容はステージングと同一のスクリプトです。

重要な原則は、CIが実行するスクリプトと人間がローカルから実行するスクリプトを同一にすることです。deploy.shという単一のスクリプトに集約し、CIはそれを呼ぶだけの薄いラッパーにします。「CIでは動くが手元では動かない」は、緊急時の対応力を奪います。

DBのマイグレーションは自動化の対象外です。ステージングと本番のDB内容は乖離します。サーバー設定は管理画面操作であり、コード化できません。

それでも、属人化の解消、AIエージェントとの協働基盤、事故の予防という明確な価値があります。ドライラン、スナップショット、ステージング検証という三重のゲートが、「本番を直接いじって壊す」という最頻の事故を構造的に防ぎます。

レンタルサーバーだからモダンな運用は無理、というのは思い込みです。制約の中でIaCの思想を翻訳する理解は、いずれクラウドに移行する日にも必ず生きます。