レンタルサーバーへのSFTP自動デプロイの組み方｜鍵認証・ステージング・同期の落とし穴

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

この記事のポイント

• SFTP自動デプロイは「鍵認証」「ステージング分離」「同期のマージ問題」の3点を先に設計しておかないと、後から必ず事故る
• 同期は基本的に「マージ」であって「置き換え」ではない。ローカルで消したファイルが本番に残り続けることを前提に運用を組む必要がある
• 1契約で複数サイトを同居させる場合、デプロイ先パスの取り違えは「起きるもの」として検査を仕込んでおく
• 料金は契約期間で倍近く変わる。エックスサーバー スタンダードは12ヶ月契約なら990円/月〜、6ヶ月契約なら1,210円/月〜（税込）
• まずは10日間の無料お試しで管理画面とSFTP接続を実際に触ってから、6ヶ月以上（できれば12ヶ月）で契約するのが現実的

「制作会社に任せきりで、サーバーの中身が分からない」から始まる話

Web制作を発注している側の経営者・マーケ担当の方から、こんな相談をよく受けます。「サイトはあるけど、サーバーの契約が誰名義かも分からない」「担当者が退職したら誰もFTPのパスワードを知らない」。これ、実はかなり多いパターンです。

制作会社に丸投げすること自体は悪くありません。ただ、サーバーの契約だけは自社名義で持っておくべきだと私は考えています。理由は単純で、サーバーはサイトという資産そのものを置いている場所だからです。ドメインとサーバーが自社名義であれば、制作会社を変えても、担当者が辞めても、サイトという資産は自分の手元に残ります。逆にここが制作会社名義だと、関係が切れた瞬間にサイトが人質になりかねません。

この記事では、そこからもう一歩踏み込んで、「サーバーを自社で持った後、実際にどうやって更新を回すか」という運用設計の話をします。手作業でFTPソフトを開いてファイルをドラッグ&ドロップする運用は、担当者が変わるたびに手順書を作り直す羽目になり、ミスも起きやすい。ある程度の更新頻度があるサイトなら、SFTPでの自動デプロイに寄せた方が長期的に楽になります。

私自身、真策堂の自社サイト（shinsakudo.com）をエックスサーバーで運用していて、2026年4月にWordPressから静的サイト（Astro）へ移行しました。この移行の過程でSFTPデプロイの仕組みを組み、実際に何度か事故も踏みました。この記事はその実務ベースの話です。

SFTP自動デプロイとは何か、なぜFTPソフトの手作業ではダメなのか

SFTP（SSH File Transfer Protocol）は、暗号化された通信でサーバーにファイルを送受信する仕組みです。従来のFTPと違い、通信内容が暗号化されるため、パスワードや転送データが平文で流れません。「自動デプロイ」というのは、このSFTP接続をスクリプトやCIツールから呼び出して、手動操作なしにビルド済みのファイル一式（dist/フォルダなど）をサーバーに送り込む仕組みのことです。

手作業のFTPソフトとの違いは、再現性です。人がドラッグ&ドロップで更新すると、「今回はどのフォルダを上げ忘れた」「前回と手順が微妙に違う」といったブレが必ず出ます。スクリプト化しておけば、誰が実行しても同じ結果になります。特に(C)の制作・運用を仕事にしている方にとっては、複数の顧客サイトを抱えるほど、この再現性の価値が効いてきます。

エックスサーバーはSFTP接続に標準対応しており、公開されているアカウント情報（サーバーID・FTPアカウント）でスクリプトから接続できます。私は Node.js の ssh2-sftp-client というライブラリを使って、dist/ フォルダをまるごと同期するデプロイスクリプトを書いて運用しています。

鍵認証で組む理由と、実際にハマったポート番号

SFTPの認証には大きく分けてパスワード認証と鍵認証があります。パスワード認証は手軽ですが、スクリプトやCIの設定ファイルにパスワードを平文で書く必要があり、その設定ファイルが漏れた瞬間にサーバーへの入り口が開いてしまいます。

鍵認証は、公開鍵をサーバー側に登録しておき、手元の秘密鍵だけで接続する方式です。秘密鍵はローカルの環境変数やCIのシークレット管理に置いておけるので、コードやリポジトリに直接パスワードを書かずに済みます。私が組んでいるデプロイスクリプトも、パスワードではなく秘密鍵認証で接続しています。

実務上、地味に引っかかりやすいのがポート番号です。エックスサーバーのSFTPはポート10022を使います。標準の22番だと思い込んでスクリプトを書くと、接続できずに「サーバーが落ちているのか？」と勘違いしてしまうことがあります。ここは最初にマニュアルで確認しておくべきポイントです。

鍵認証を組む手順（概要）

ステップ	やること
1	ローカルでSSH鍵ペアを生成する
2	エックスサーバーの管理画面（サーバーパネル）から公開鍵を登録する
3	デプロイスクリプト側は秘密鍵のパスを参照するよう設定する
4	ポート10022・ホスト名・SFTPアカウントを環境変数に切り出す
5	まずは手元のPCから一度手動で接続テストする

いきなりCIに組み込まず、手元から接続テストを一度通してから自動化する、という順番が事故を減らします。

ステージング環境を分ける意味

本番に直接デプロイするのは、慣れないうちは怖いものです。私は本番サイトとは別に、ステージング環境（サブドメイン）を用意していて、本番切替前の確認に使っています。WordPressから静的サイトへ移行する際も、まずステージングで一通りページが正しく表示されるか、リンク切れがないかを確認してから本番切替をしました。

ステージング環境を用意する意味は、単に「テストできる」だけではありません。デプロイスクリプト自体のバグ（送り先パスの間違いなど）を、本番を汚す前に発見できることが一番大きいと感じます。SFTPデプロイのスクリプトは、最初のうちは「動くには動くけど本当に正しいパスに送っているか」が曖昧なまま運用されがちです。ステージングで何度か流してから本番用の設定に切り替える、というワンクッションを置くだけで、事故の確率はかなり下がります。

(A)のこれから自社サイトを作る事業者の方であれば、制作会社に「ステージング環境はありますか」と聞いてみることをお勧めします。無ければ、それだけで運用の透明性に不安が残ります。

一番の落とし穴：同期は「マージ」であって「置き換え」ではない

ここが、この記事で一番伝えたいことです。

SFTPでdist/フォルダをサーバーに同期するとき、多くのツール・スクリプトは「ローカルにあるファイルをサーバーに上書きする」動作はしますが、「ローカルに無くなったファイルをサーバーから削除する」動作は自動ではしません。つまり同期は基本的にマージであって、完全な置き換えではないのです。

これは私自身、実際に踏んだ落とし穴です。WordPressから静的サイトへ移行した後、記事のURL構造を変えたことがありました。ローカルでは古いディレクトリの記事ファイルを削除していたのですが、デプロイスクリプトは「新しいファイルを送る」だけで「古いファイルを消す」処理をしていなかったため、本番サーバーには古いURLのページが生き残ったままになりました。結果、Search Consoleで古いURLがインデックスされ続けるという状態になり、後から気づいて対応する羽目になりました。

この落とし穴が意味すること

「デプロイが成功した＝サイトが最新の状態になった」ではない、ということです。ファイルを消す運用をする場合は、同期スクリプトとは別に、明示的な削除処理を組んでおく必要があります。あるいは、思い切って本番のディレクトリを一度空にしてから全量を上げ直す、という運用に振り切る手もあります（ただしこれはこれで、他のファイルを巻き込むリスクがあるので慎重に）。

URL構造を変える予定がある方、記事を頻繁に削除・統合する運用をしている方は、このマージ動作を必ず頭に入れておいてください。

もう一つの落とし穴：1契約に複数サイトを同居させるときの取り違え

エックスサーバーは1つの契約で複数のドメイン・複数のサイトを運用できます（マルチドメイン無制限）。コストを抑えたい制作・運用担当者にとってはありがたい仕様ですが、ここにも落とし穴があります。

私自身、同一アカウント内に複数サイトを同居させて運用しているのですが、デプロイ先のパスを取り違えて、片方のサイト用のファイルがもう片方のドキュメントルートに撒かれてしまったことがあります。しかも前述の「マージ動作」のせいで、間違って撒いたファイルは自動で消えず残り続けます。気づいたきっかけは、Search Consoleに身に覚えのないクエリが出てきたことでした。

この経験から、デプロイスクリプト側で「送り先のパスが想定しているドメイン宛てになっているか」を機械的に検査するようにしています。人間の目視確認だけに頼ると、忙しいときに必ず見落とします。スクリプトの実行前に「デプロイ先: xxx.com で合っていますか？」という確認ステップを挟むだけでも、事故はかなり防げます。

(C)の制作・運用を仕事にしている方で、複数の顧客サイトを1つのサーバー契約、あるいは似た構成のスクリプトで回している場合、この取り違えリスクは他人事ではありません。デプロイ対象のドメイン名をスクリプトの引数として明示的に渡し、ハードコードしない、といった基本的な設計が効いてきます。

独自SSLと、Cloudflareを噛ませる場合の注意

エックスサーバーは全プランで無料独自SSLに対応しており、私自身もこの無料独自SSLを使っています。ここは特に難しい設定なく有効化できる部分です。

一点、別件で得た知見として共有しておきたいのが、レンタルサーバーの無料SSLをCloudflareのProxied（オレンジクラウド）配下で使うと、更新に失敗することがあるという点です。サーバーによって挙動が違い、90日ごとの自動更新のタイミングで静かに失敗し、気づかないうちに証明書が切れているというケースがあります。Cloudflareを噛ませる構成を考えている方は、事前に更新が正常に通るか検証しておくことをお勧めします。エックスサーバー固有の話ではなく、レンタルサーバー全般に言える注意点です。

WordPressから静的サイトへの移行を検討している方は、こちらの記事も参考にしてください。WordPressサイトを静的サイトに移行してサーバーはそのままにした話｜判断基準と移行手順で、サーバーを変えずに構成だけ変える判断基準を書いています。

他の選択肢との比較：SFTP手動運用・Git連携ホスティング・自前サーバー

SFTP自動デプロイが唯一の正解というわけではありません。他の選択肢と比較して整理しておきます。

方式	初期の手間	運用の再現性	向いているケース
FTPソフトで手動アップロード	低い	低い（属人化しやすい）	更新頻度が低い小規模サイト
SFTP自動デプロイ（本記事）	中程度（スクリプト構築が要る）	高い	静的サイト・頻繁に更新する運用サイト
Git連携型ホスティング（Vercel等）	低い（設定は簡単）	高い	完全に静的サイトに振り切れる場合
自前VPS・クラウドサーバー	高い（サーバー構築から必要）	高い（自由度も高い）	特殊な要件・大規模トラフィック

エックスサーバーでのSFTP自動デプロイは、「レンタルサーバーの手軽さ」と「デプロイの自動化」を両立させたい場合の中間的な選択肢です。完全にGit連携型のホスティングに寄せてしまう手もありますが、WordPressのような動的なCMSを一部残したい場合や、メールサーバー・データベースも同じ契約でまとめて管理したい場合は、レンタルサーバー側でSFTPデプロイを組む方が現実的なことが多いと感じます。

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

SFTP自動デプロイが向いているのは、更新頻度がある程度あり、かつ複数人（または複数サイト）で運用していて手作業のブレをなくしたい方です。逆に、月1回程度の更新で、担当者が固定されている小規模サイトであれば、無理に自動化せず手動運用のままでも実害は少ないと思います。自動化のためのスクリプト構築・鍵の管理といった初期コストがかかるので、更新頻度と運用体制を見て判断するのが現実的です。

「意味ない？」への実態ベースの回答

SFTP自動デプロイについて「結局、手作業と大差ないのでは」という声を聞くことがあります。私の実感では、差が出るのは「事故が起きたとき」です。手作業だと、どのファイルをいつ上げたか、誰が最後に触ったかが曖昧になりがちですが、スクリプト化しておけば、デプロイのログが残り、実行者や実行時刻が追えます。特に(C)の複数サイトを扱う立場だと、この「何が起きたか後から追える」ことの価値は大きいです。ただし前述の通り、同期のマージ動作や送り先パスの検査を組み込んでいないと、自動化したがゆえに気づかない事故も起きます。「自動化＝安全」ではなく、「自動化した分だけ、検査も自動で組む」がセットだと考えておくのが実態に近いと思います。

契約プランと期間の選び方（法人利用の視点も含めて）

ここまでの運用を組む前提として、まずサーバー契約そのものの話をしておきます。エックスサーバーの料金は契約期間によって大きく変わります（税込・2026年8月時点、公式サイト参照：エックスサーバー公式 料金ページ）。

プラン	6ヶ月契約	12ヶ月契約	24ヶ月契約	ディスク容量
スタンダード	1,210円/月	990円/月	836円/月	500GB
プレミアム	2,420円/月	1,980円/月	1,672円/月	600GB
ビジネス	4,840円/月	3,960円/月	3,344円/月	700GB

「990円から」という表示だけを見て申し込むと、実際は12ヶ月契約時の単価であることに気づかず、短い契約期間で申し込んで割高になるケースがあります。3ヶ月契約は月額が最も高く設定されているので、コスト面でも実務面でも積極的に選ぶ理由は薄いと感じます。短期でお試ししたい場合は、まず10日間の無料お試し期間を使い、契約自体は6ヶ月以上、できれば12ヶ月で見積もるのが現実的な線だと思います。

法人でサイトを持つ場合、ディスク容量やメールアドレス数（全プラン無制限）よりも、管理者ユーザー設定（ビジネスプランのみ対応）の有無が効いてくることがあります。担当者が複数いる組織で、権限を分けて管理したい場合はビジネスプランも検討候補に入れておくとよいと思います。各プランの詳細な機能一覧はエックスサーバー公式 機能一覧ページで確認できます。

デメリット・注意点を正直に

ここまで書いてきた通り、SFTP自動デプロイは組めば楽になりますが、「組むまでの手間」と「事故のリスク」は正直に伝えておきたいところです。鍵認証の設定、ステージング環境の用意、同期のマージ動作への対策、複数サイト同居時のパス検査――どれも最初から完璧に組めるものではなく、私自身、実際に事故を踏んでから対策を追加してきました。裏を返せば、これらの落とし穴を先に知っておけば、同じ事故を踏まずに済むということでもあります。この記事がその先回りになれば、という気持ちで書いています。

よくある質問

Q. SFTPとFTPの違いは何ですか？ FTPは通信が暗号化されないのに対し、SFTPはSSHの暗号化された通信路の上でファイル転送を行います。パスワードや転送データが盗聴されるリスクを下げられるため、現在は業務利用であればSFTP（またはFTPS）を使うのが基本です。エックスサーバーもSFTP接続に対応しています。

---

Q. 鍵認証の設定は難しいですか？ SSH鍵ペアの生成自体はコマンド一つで完了します。難しいのはむしろ「秘密鍵をどこに安全に保管するか」の設計です。CIツールを使う場合はシークレット管理機能を使い、ローカルで完結させる場合は環境変数やパスワード管理ツールに保管するなど、鍵の置き場所を最初に決めておくと迷いません。

---

Q. 同期でファイルが消えないなら、どうやって不要なファイルを消せばいいですか？ デプロイスクリプトの同期処理とは別に、削除対象のパスを明示的に指定して消す処理を組むのが確実です。あるいは本番のデプロイ先ディレクトリを一度クリアしてから全量をアップロードし直す運用に切り替える手もありますが、他のファイル（アップロード画像やメールデータの配置など）を巻き込まないよう、デプロイ対象のディレクトリを厳密に分けておく必要があります。

---

Q. 1つの契約で複数サイトを運用しても大丈夫ですか？ エックスサーバーはマルチドメインが無制限なので、契約上は問題なく複数サイトを同居させられます。ただし自動デプロイを組む場合は、送り先パスの取り違えが起きうることを前提に、デプロイスクリプト側でドメイン名の検査を入れておくことをお勧めします。私自身、この取り違えを一度経験しています。

---

Q. 3ヶ月契約と12ヶ月契約、結局どちらがいいですか？ 月額単価だけで見ると、3ヶ月契約が最も割高で、契約期間が長くなるほど単価は下がります（スタンダードで3ヶ月1,320円/月に対し、12ヶ月990円/月、24ヶ月836円/月）。まず10日間の無料お試しで管理画面やSFTP接続の使い勝手を確認し、続けられそうであれば6ヶ月以上、コスト面でも12ヶ月契約を軸に検討するのが現実的だと思います。

---

Q. WordPressのまま自動デプロイは組めますか？ WordPressはデータベースと連動する動的なCMSのため、静的サイトのようにファイル一式をSFTPで同期するだけでは完結しません（データベースの移行・同期が別途必要です）。WordPressのまま更新頻度を保ちたいのか、静的サイト化して自動デプロイに寄せたいのかは、運用の手間と更新頻度のバランスで判断するとよいと思います。

まとめ

SFTP自動デプロイは、鍵認証・ステージング環境・同期のマージ動作という3つのポイントを先に押さえておけば、手作業の更新よりも再現性の高い運用に変えられます。ただし「自動化した＝安全」ではなく、削除処理やパスの検査といった、事故を防ぐための仕組みをセットで組む必要がある、というのがこの記事で一番伝えたかったことです。

これから自社サイトを持つ方、他社サーバーから乗り換えを検討している方は、まずエックスサーバー公式サイトから10日間の無料お試しで、管理画面とSFTP接続まわりを実際に触ってみることをお勧めします。契約する場合は、3ヶ月契約は月額が割高になるので避け、6ヶ月以上、コスト面では12ヶ月契約を軸に見積もるのが現実的です。詳しい料金・プランはエックスサーバー公式サイトの料金ページで最新の内容をご確認ください。