GitHub Actions から Xserver へ静的サイトをデプロイする方式として、最初はFTPSを使い、後からSSH+rsyncに切り替えた。その実体験に基づく比較と、それぞれの導入手順のまとめ。

結論：どちらを選ぶべきか

結論：最初からSSH+rsyncが使えるなら、そちらを選んだ方がいい。 FTPSは「手軽さ」だけが利点で、今回のように数百ファイルを扱う静的サイトでは速度・安定性の両方で見劣りした。

案1：FTPS（最初に採用・後に廃止）

仕組み

GitHub Actions上で SamKirkland/FTP-Deploy-Action というツールを使い、FTPS（FTP over TLS）でXserverに直接ファイルをアップロードする。ローカルの out/（Next.jsのビルド成果物）を丸ごと転送する。

導入手順

1. Xserverサーバーパネル → FTP → FTPアカウント設定 で、デプロイ専用のFTPアカウントを新規作成する（メインのサーバーパスワードとは分離するため）
2. 接続先ディレクトリ・パスワードを設定
3. GitHub Secretsに以下を登録：
   • FTP_SERVER（ホスト名）
   • FTP_USERNAME
   • FTP_PASSWORD
   • FTP_SERVER_DIR（アップロード先の相対パス）
4. workflow内で SamKirkland/FTP-Deploy-Action を使い、protocol: ftps を指定してアップロードする

実際にハマったこと

• 公開フォルダの場所を勘違いした：Xserverは標準で ドメイン名/public_html/ が公開フォルダになる想定だったが、このサーバーでは実際のドキュメントルートが home直下 になっており、FTPアカウントの「接続先ディレクトリ」の設定次第で見える場所がまったく変わった。テストファイルを置いて実際にどこが配信されているか確認しながら特定する必要があった。
• FTP制御コネクションのタイムアウト：Timeout (control socket) というエラーで、数回に1回の頻度でデプロイが失敗するようになった。タイムアウト時間を延長（30秒→120秒）し、失敗時に自動で1回リトライする仕組みを入れても、根本的には解消しなかった。
• 転送速度が遅い：500ファイル超（記事221件分の静的ページなど）を毎回全部アップロードする形になり、1回のデプロイに8〜13分かかっていた。記事を1件更新するだけの軽微な変更でも、同じだけ時間がかかる。

案2：SSH+rsync（現在採用）

仕組み