1つのレンタルサーバーで複数サイトを運用するときの事故と防ぎ方｜デプロイ先の取り違えとファイルの残骸

ℹ️ 本記事はアフィリエイトプログラム（エックスサーバー株式会社／A8.net）による収益を含みます。料金・仕様は変わることがあるため、申し込み前に必ず公式サイトの最新情報をご確認ください（本記事は2026年8月時点）。

この記事のポイント

• 1契約で複数サイトを運用していると、デプロイ先のパスを取り違えて別サイトにファイルを撒いてしまう事故が起きうる
• 原因は「同期がマージ動作である」こと。消したつもりのファイルは本番に残り続ける
• Search Consoleに身に覚えのないクエリが出たら、それはこの事故のサインかもしれない
• 防ぐには、デプロイ先パスの検査・ステージング環境・削除の明示的な運用の3点がカギ
• エックスサーバーは新規なら12ヶ月契約990円/月〜、10日間の無料お試しで管理画面を先に触れる

「なんでこのURL、Search Consoleに出てるんだろう」から始まった話

見慣れないクエリに首をかしげる瞬間

複数のサイトを1つのレンタルサーバー契約で運用している方、けっこう多いんじゃないかと思います。コストを抑えたいのは当然ですし、独自ドメインを複数持てるプランなら、わざわざサイトごとに契約を分ける必要もありません。

ただ、この「1契約で複数サイト」という構成、便利な反面、地味に厄介な事故の種を抱えています。それが今回のテーマである「デプロイ先の取り違え」です。

私は自社サイト（shinsakudo.com）をエックスサーバーで運用していて、同じアカウント内に複数のサイトが同居しています。ある時、Search Consoleを見ていて「あれ、このクエリ、うちのサイトに関係ないな」というものが混ざっているのに気づきました。調べてみると、別サイト用にデプロイしたはずのファイルが、間違ったドキュメントルートに撒かれていたんです。しかも同期の仕組み上、そのファイルは消えずに残り続けていました。

この記事では、この種の事故がなぜ起きるのか、どう防ぐのか、そしてそもそも1契約で複数サイトを回す構成が自分に向いているのかを、実務目線で整理します。

デプロイ先取り違え事故の正体

まず起きたことを整理すると、シンプルです。

1. 複数サイトを1つのサーバーアカウントで管理している
2. デプロイスクリプト（SFTP等）で、指定するパスを間違える、あるいは環境変数の切り替えを誤る
3. 本来Aサイト用のファイルがBサイトのドキュメントルートに転送される
4. 転送後、気づかなければそのまま放置される

問題は3と4の間です。「間違えて転送しちゃった」だけなら、気づいた時点で削除すれば済みます。ですが実際には、多くのSFTP同期ツールはマージ動作です。つまり「新しいファイルを追加・上書きする」ことはしても、「転送元に存在しないファイルを転送先から削除する」ことは自動ではやってくれません。

これが意味するのは、一度取り違えて撒いてしまったファイルは、明示的に消さない限り本番サーバーに残り続けるということです。しかもクロールされてインデックスされてしまえば、Search Consoleに「身に覚えのないクエリ」として現れます。私が最初にこの事故に気づいたのも、まさにこのタイミングでした。表示速度が落ちたわけでも、エラーが出たわけでもなく、静かに残骸だけが積み上がっていたんです。

なぜ「消せばいい」で終わらないのか

「気づいたら消せばいいじゃない」と思うかもしれません。ただ実務ではそう単純ではない理由が2つあります。

1つ目は、気づくタイミングが遅れがちなこと。デプロイ直後にエラーが出るわけではないので、見た目には何も起きていません。気づくのは大体、Search Consoleのクエリ一覧やアクセス解析の数値に違和感を覚えたときで、そのころには数週間〜数ヶ月経っていることも珍しくありません。

2つ目は、消す作業自体が明示的な操作を必要とすること。同期スクリプトが「転送元にないファイルは転送先からも削除する」設定（いわゆるミラー同期）になっていれば自動で片付きますが、これは逆に「意図せず消してはいけないファイルまで消してしまう」リスクと表裏一体です。私は自分の運用では、削除は同期とは別のスクリプトで明示的に行うようにしています。安全側に倒すなら、自動で消えない代わりに、消すときは自分の意思で消す、という設計の方が事故が小さく済むと感じています。

このあたりの同期設計の考え方は、以前レンタルサーバーへのSFTP自動デプロイの組み方｜鍵認証・ステージング・同期の落とし穴でも詳しく書いているので、これからデプロイを自動化する方はあわせて読んでもらえると設計の抜け漏れが減ると思います。

複数サイト同居という構成そのものの向き不向き

1つの箱に詰め込むか、分けて持つか悩む人

ここで一度、そもそも論を挟みます。「1契約で複数サイトを運用する」構成自体は、多くのレンタルサーバーで可能ですが、向き不向きがあります。

比較：1契約で複数サイト vs サイトごとに契約を分ける

観点	1契約で複数サイト	サイトごとに契約を分ける
コスト	抑えられる（プラン1つ分）	サイト数分かかる
デプロイ先取り違えリスク	ある（パス管理が必要）	ない（そもそもサーバーが別）
障害時の影響範囲	サーバー障害時は複数サイトが同時停止	影響が該当サイトのみに限定される
管理の手間	1つの管理画面で完結	管理画面・請求がサイト数分に増える
向いている規模	個人・小規模事業者、社内の複数ブランドサイト	顧客の本番環境を預かる制作会社、規模の大きい法人サイト

コストと管理の手間を優先するなら1契約複数サイトは合理的です。ただしその場合、デプロイ先パスの管理を「人の注意力」に頼らない仕組みにしておくことが前提になります。逆に、顧客の本番サイトを預かる立場や、障害時の影響範囲を絶対に切り分けたい法人サイトであれば、多少コストがかかってもサイトごとに契約を分ける判断の方が安全です。

真策堂の読者には制作・運用を仕事にしている方も多いと思いますが、顧客案件のサーバーと自社サイトのサーバーを同じ契約にまとめるのは避けた方がいいというのが私の考えです。自社の実験的な変更が、顧客サイトの安定運用に影響を及ぼすリスクを負う必要はないからです。

事故を防ぐ具体的な手順

図1: 事故を防ぐ4ステップのフロー図

抽象論だけで終わらせず、実際にやっている・やった方がいいと考えている手順を挙げます。

1. デプロイ先パスをスクリプト側で検査する

私は、デプロイスクリプトの中で「これから転送しようとしているパスが、想定しているドメイン宛てかどうか」をチェックするようにしました。具体的には、デプロイ先のディレクトリ名やドメイン文字列をスクリプト内の定数と突き合わせて、一致しなければ処理を止める、というシンプルな仕組みです。人間の注意力に頼らず、機械的に弾く仕組みを1つ挟むだけでも事故率はかなり下がります。

2. 本番前にステージング環境で確認する

本番切替の前に、別のディレクトリ（サブドメイン等）で一度デプロイして目視確認する工程を挟みます。私も自社サイトをWordPressから静的サイトへ移行したとき、本番切替前にステージング環境（xs640578.xsrv.jpのような形のURL）で確認してから本番に反映しました。パスの取り違えは、この段階で気づけることも多いです。

3. 削除は同期と切り離して明示的に行う

前述の通り、マージ動作の同期に削除まで任せると危険です。消すべきファイルは別工程で、明示的に削除コマンドを実行する運用にしておくと、意図しない削除・意図しない残骸のどちらも防ぎやすくなります。

4. 定期的にSearch Consoleのクエリと表示URLを見る

これは事後の検知策ですが、月に一度でもいいので「身に覚えのないURLがインデックスされていないか」を確認する習慣は効きます。私の場合、これがなければ取り違え事故に気づくのがもっと遅れていたと思います。

サーバー移行を検討している人へ：借り換えなくていいケースもある

ここまで読んで「じゃあサーバー自体を分けよう」「乗り換えよう」と考えた方もいるかもしれません。ただ、実は運用方法を見直すだけで解決するケースもあります。

私自身、WordPressの運用の手間（更新・プラグイン管理・セキュリティ対応）を減らしたくて、自社サイトをWordPressから静的サイトへ移行しました。このとき、サーバー自体は同じエックスサーバーのままで、SFTPでファイルを置くだけで移行できました。サーバーを借り換える必要がなかったんです。

「WordPressの運用がしんどい」「表示が重い」という悩みは、サーバーのスペック不足が原因のこともあれば、WordPress側の構成（プラグインの数・テーマ・データベースの肥大化）が原因のこともあります。原因を切り分けずにサーバーだけ乗り換えても、根本原因が解決しないこともあるので注意が必要です。原因の切り分け方はWordPressサイトが重い原因の切り分け手順｜画像・プラグイン・サーバー・テーマのどれかを数値で特定するにまとめているので、乗り換え前に一度確認してみることをおすすめします。

静的サイトへの移行そのものの判断基準や手順は、WordPressサイトを静的サイトに移行してサーバーはそのままにした話｜判断基準と移行手順で詳しく書いています（記事タイトルの通り、サーバーはそのままでOKでした）。

エックスサーバーの料金と契約期間の注意点

さて、ここからは「新規に借りる」「他社から乗り換える」場合を想定して、エックスサーバーの料金を具体的に見ていきます（既存契約の更新については触れません）。

契約期間別の月額（税込・2026年時点）

契約期間	スタンダード	プレミアム	ビジネス
3ヶ月	1,320円/月	2,640円/月	5,280円/月
6ヶ月	1,210円/月	2,420円/月	4,840円/月
12ヶ月	990円/月	1,980円/月	3,960円/月
24ヶ月	836円/月	1,672円/月	3,344円/月
36ヶ月	693円/月	1,386円/月	2,772円/月

「990円から」という表記をよく見かけますが、これは12ヶ月契約時の価格です。3ヶ月契約だと1,320円/月とほぼ1.3倍になるので、比較検討するときはどの契約期間の数字を見ているか必ず確認してください。個人的には、よほど短期の検証目的でない限り、価格面でも12ヶ月契約を基準に考えるのが現実的だと思います。

スタンダードプランでもディスク容量500GB（NVMe）、独自ドメイン2つ永久無料、無料独自SSL、自動バックアップ14日分がついてきます。複数サイトを運用する前提なら、マルチドメイン・サブドメインが無制限という点も効いてきます（出典：エックスサーバー公式 料金ページ、機能一覧ページ）。

法人でサイトの規模が大きい、あるいは管理者ユーザーを分けて権限管理したいという場合は、ビジネスプランで管理者ユーザー設定が使える点もチェックしておくといいと思います。制作会社に丸投げせず自社名義でサーバーを持っておきたい経営者・マーケ担当の方は、この管理者ユーザーの機能で、制作会社に渡す権限と自社が持つ権限を分けられるのが実務上ありがたいポイントです。

無料独自SSLについての注意点

エックスサーバーの無料独自SSLは、申し込むだけで無料・無制限に使えます。私も自社サイトでこの無料独自SSLを使っています。

ただ一点、レンタルサーバー全般に言える注意点として、CloudflareをProxied（オレンジクラウド）にした状態で運用していると、無料SSLの自動更新に失敗することがあります。サーバー側の挙動によって差があり、90日後に静かに切れてしまうケースもあるので、Cloudflareを噛ませる構成にするなら事前に検証しておくことをおすすめします。

向いている人・向いていない人

図2: 向いている人／向いていない人の二分図

向いている人

• これから自社サイトを新規に作る、または作り直す事業者で、サーバーを自社名義で管理したい人
• WordPressの運用負荷を減らしたい、あるいは静的サイトへの移行を検討している人
• 個人・小規模事業者で、複数の自社サイトを1契約でコンパクトに運用したい人

向いていない人・注意が必要な人

• 顧客の本番サイトを複数預かっていて、障害時の影響範囲を厳密に切り分けたい制作会社（サイトごとの契約分離を検討すべき）
• デプロイ・同期の仕組みを整備する余力がなく、パス管理を人力の注意力だけに頼らざるを得ない体制の人（事故リスクが残ります）

よくある質問

Q. 1つの契約で複数サイトを運用するのは、そもそもリスクが高すぎますか？ リスクゼロではありませんが、デプロイ先パスの機械的な検査やステージング環境の活用など、仕組みで防げる部分が大きいです。コストと管理の手間を優先するなら、仕組みを整えた上で1契約複数サイトの運用は十分成立すると考えています。

---

Q. デプロイ先の取り違えに気づく一番早いサインは何ですか？ 私の経験では、Search Consoleに身に覚えのないクエリやURLが出てくることでした。エラーが出るわけではないので、定期的にクエリ一覧を確認する習慣をつけておくと早期発見につながります。

---

Q. 同期を「ミラー」にして自動で削除も反映させた方が安全ですか？ 一長一短です。ミラー同期にすれば残骸は残りませんが、逆に消してはいけないファイルまで意図せず消してしまうリスクが出ます。私は削除だけは別工程で明示的に行う運用にしていて、その方が事故が小さく済むと感じています。

---

Q. サーバーを乗り換えれば、この手の事故はなくなりますか？ サーバーを分ければ物理的な取り違えは起きなくなりますが、コストと管理の手間は増えます。まずは同じサーバー内でパス検査・ステージング環境・削除の明示化といった仕組みを整えることを検討して、それでも不安が残る規模や体制であれば分離を検討する、という順番がおすすめです。

---

Q. 10日間の無料お試しでは何が確認できますか？ 実際の管理画面の使い勝手やマルチドメインの設定画面、SFTP接続の可否などを、契約前に確認できます。デプロイの仕組みを組む前提なら、この期間に一度SFTP接続まで試しておくと、契約後の設計がスムーズになると思います。

まとめ

複数サイトを1つのサーバーで運用するのは、コストと管理の手間を考えれば合理的な選択です。ただし「同期はマージ動作で、消したファイルは自動では消えない」という前提を理解していないと、デプロイ先の取り違えという静かな事故につながります。防ぐ手段は難しいものではなく、デプロイ先パスの機械的な検査、ステージング環境での事前確認、削除の明示化という3点に集約されます。

これから自社サイトを新規に作る、あるいは他社から乗り換えを検討している方は、まず10日間の無料お試しで管理画面やSFTP接続を実際に触ってみて、契約期間は価格面でも成果条件面でも実質的な基準になる12ヶ月契約で見積もってみるのがおすすめです。

エックスサーバー公式サイトで、まずは料金シミュレーションと無料お試しの申し込み画面を見てみてください。