GitHub Actionsからさくらへの自動FTPデプロイが全失敗した原因は、初期設定でオンの「国外IPアドレスフィルタ」でした。サイトは表示されるのにデプロイだけ落ちる症状の正体と、Cloudflare® Pages移行で解決した実体験を共有します。
結論:GitHub Actionsからさくらのレンタルサーバーへの自動FTPデプロイがすべて失敗した原因は、さくらの「国外IPアドレスフィルタ」でした。海外のIPアドレスからのFTPやSSHなどのアクセスを制限する機能で、初期設定で有効になっています。GitHub Actionsは海外のサーバー(Microsoft Azureのデータセンター)で動くため、ファイルの転送が止められていたのです。
このフィルタは、普通のページの閲覧は止めません。そのため、「サイトは普通に表示されるのに、デプロイだけが必ず失敗する」という、原因にたどり着きにくい状況が生まれていました。
この記事は、株式会社curveが運営するAI情報メディア「AIテックベース」を、WordPressから静的サイトの構成へ移行した実体験シリーズの1本です。作業したのは非エンジニアのWeb担当者で、AIコーディング支援「Claude Code」と一緒に進めました。移行中に半日ハマった「自動デプロイ全失敗」の顛末を、症状・原因の特定・解決の順で共有します。
1. 何が起きたのか:ログインは通るのに、転送だけ失敗する
症状は、「FTPのログイン(認証)は成功するのに、その後のファイル一覧の取得や転送の段階で必ず失敗する」というものでした。使うツールごとに、次のようなエラーが出ました。
- lftpを使った場合:max-retries exceeded(再試行の回数の上限に達して停止)
- curlを使った場合:exit code 56(データの受信に失敗)
厄介だったのは、ログインは通っているという点です。パスワードの誤りなら「ログインに失敗しました」と出るので、すぐに設定を見直せます。「ユーザー名とパスワードは合っている。でもファイルが送れない」という中途半端な状態が、原因の特定をいっそう難しくしました。
背景として、さくらのレンタルサーバー(スタンダードプラン)自体はSFTPやSSHにも対応していますが、私たちの運用は昔からのFTPのままでした。旧WordPressのファイル削除に47分かけて失敗するなど、もともとFTPでの運用は不安定で、「FTPでの自動デプロイは筋が悪いかもしれない」という違和感が、少しずつ積み上がっていました。
2. なぜ原因の特定に時間がかかったのか
理由は、エラーメッセージが「真の原因」を直接指していなかったからです。max-retries exceededやexit code 56は、「海外からのアクセスが制限されている」とは書いてくれません。
ここで非エンジニアが陥りがちなのが、「原因らしきものを片っ端から試す」という対処です。実際、最初は推測でFTPのホスト名を変えて試し、失敗しました。タイムアウトの値を変える、パッシブモードを切り替える、再試行の回数を増やす。こうした当てずっぽうの修正は、半日を溶かす典型的なパターンです。
転機は、修正を試す前に「環境の仕様」を1つずつ確定したことでした。
- 転送方式:プラン自体はSFTPやSSHにも対応しているが、当時の運用はFTPのままだったと確定
- ホスト名:推測ではなく、契約情報から正しい値を確認
- 切り分け:手元のパソコン(国内のIPアドレス)からはFTP転送が成功するのに、GitHub Actions(海外のIPアドレス)からだけ失敗する、という差に注目
「国内からは通り、海外からだけ通らない」という事実がそろった瞬間、原因の候補は一気に絞られました。さくらの設定を確認したところ、「国外IPアドレスフィルタ」が初期設定のまま有効になっていたのです。
3. 真犯人:さくらの「国外IPアドレスフィルタ」
国外IPアドレスフィルタは、海外からの不正なアクセスを防ぐためのセキュリティ機能で、初期設定で有効になっています。重要なのは、「何を止めて、何を止めないか」です。
海外のIPアドレスからのアクセス | フィルタ有効時の扱い |
|---|---|
普通のページの閲覧(HTTP/HTTPS) | 止められない(普通に表示できる) |
FTP(ファイル転送) | ログインはできるが、その後のファイル一覧の取得や転送ができない |
SSH・SFTP | パスワードでの接続は拒否される(公開鍵認証は制限の対象外) |
メール送信(SMTP認証)、WebDAV | 止められる |
「個別制限設定」で対象にした特定のファイルやフォルダ(WordPressのログイン画面や管理画面、XML-RPC、コメント投稿、phpMyAdminなど) | 止められる |
つまり、サイトを見る人には影響しない一方で、GitHub Actionsのような海外のサーバーからの自動デプロイだけが狙い撃ちで止まります。「サイトは見えるのにデプロイだけ落ちる」という不可解な症状の正体が、これでした。
「ログインは通るのに転送だけ失敗する」という症状も、この仕様で説明がつきます。公式の説明でも、FTPは「認証に成功すればログインできるが、その後の操作ができない」とされています。curlのexit code 56(データの受信に失敗)や、lftpの再試行の上限到達は、ログイン後の操作で止められた結果だったのです。
さくらのサポート情報には、GitHub.comなどの海外サービスからFTPやSSHで接続できない場合の案内ページもあります。フィルタの存在自体は公式に明記されていたのですが、デプロイの失敗という別の症状から逆算して、その情報にたどり着くまでに時間がかかりました。
4. 解決の選択肢:3つの方法を比べる
解決策は、大きく3つあります。
方法 | 内容 | 注意点 |
|---|---|---|
フィルタを無効にする | さくらの管理画面で国外IPアドレスフィルタをオフにする | いちばん簡単だが、サーバー全体のセキュリティが下がる |
公開鍵認証のSFTPで配置する | FTPをやめ、鍵を使ったSFTPなどでファイルを送る | 公開鍵認証の接続はフィルタの対象外。鍵の管理と、GitHub側への安全な登録が必要 |
海外からさくらへ接続しない構成にする | 国内で動く仕組みから配置するか、ホスティングそのものを別のサービスに移す | 構成を見直す手間はかかるが、フィルタを有効のまま自動化できる |
「GitHub ActionsのIPアドレスを許可リストに入れればよいのでは」と考えるかもしれませんが、さくらの許可リストが効くのは、WordPressの管理画面などウェブの特定ファイルへのアクセスだけです。FTPやSSHの制限は、許可リストでは外せません。そもそもGitHub Actionsの接続元のIPアドレスは膨大で、毎週のように更新されるため、許可リストでの管理には向いていません。
5. 採用した方法:ホスティングをCloudflare Pagesへ
最終的に採用したのは、3つ目の方法です。当時は運用がFTPのままで、鍵を使った接続に切り替える準備もなかったため、サイトの公開の仕組みそのものを見直すことにしました。サイトの公開先(ホスティング)を、Cloudflare Pagesに切り替えました。
Cloudflare PagesはGitHubと連携して、変更を送るたびに自動でサイトを組み立てて公開します。さくらへ海外からFTPで接続する必要そのものがなくなったため、さくらの国外IPアドレスフィルタは有効のまま(安全性を保ったまま)、自動デプロイが回るようになりました。記事の更新は、変更を送ってから1分ほどでサイトに反映されます(2026年9月時点)。
さくらのサーバーは完全に手放したわけではなく、問い合わせフォームのPHP(メールを送るだけで、個人情報は保存しない。自サイトからの送信だけを受け付ける設定)として今も使っています。役割を「ホスティング」から「フォームの処理」に絞った形です。このフォームのファイルはフィルタの制限対象の一覧に入っていないため、海外から閲覧している読者も送信できます。
6. 同じ症状に出くわしたときのセルフチェック
「サイトは表示できるのに、自動デプロイだけが失敗する」という似た症状に出会ったら、次の順番で切り分けると早く原因にたどり着けます。
- 国内から同じ操作を試す:手元のパソコンなど国内のIPアドレスからFTPやSFTPで接続し、成功するかを確かめる。成功するなら、サーバーではなく「接続元の場所」に原因がある可能性が高い
- 管理画面でアクセス制限を探す:契約しているレンタルサーバーの管理画面で、海外からのアクセス制限の設定がないかを確認する。多くの国内レンタルサーバーが、同様の機能を標準で備えている
- 公式ヘルプを検索する:サーバー会社のヘルプで「海外」「国外」「GitHub」「アクセス制限」といった言葉を検索する
- エラーの番号の意味を調べる:exit code 56のような番号は、検索すれば意味が分かる。AIにエラーの全文を見せて、次に確認すべきことを一緒に考えるのも有効
なお、同じ仕組みはWordPressの運用にも影響します。海外出張中にWordPressの管理画面へログインできない、海外のサービスから記事を自動投稿できない、といった場合も、このフィルタが原因のことがあります。
7. この経験から得た学び
最大の学びは、「推測で試す前に、環境の仕様を確定する」という一点です。
- 先に環境を確定する:転送方式、正しいホスト名、セキュリティの設定を、推測ではなく事実として確認する
- エラーの意味を調べる:番号の意味から原因を1つに絞る
- 差分に注目する:「国内は通る・海外は通らない」のように、成功と失敗の違いそのものが原因のヒントになる
- セキュリティは下げずに解決する:フィルタを切れば早く解決するが、接続方式や構成を見直せば、安全性を保ったまま自動化できる
外部の制作会社やサーバー会社のサポートに問い合わせれば、もっと早く解決できたかもしれません。それでも自分たちで原因を特定したことで、「先に仕様を確定し、差分から原因を絞る」という考え方を社内に残せました。AIと一緒に作業する場合、エラーや切り分けの結果をそのまま共有すれば、非エンジニアでも「次に何を確認すべきか」の仮説を一緒に立てられます。専門用語を知らないことは、原因究明のハンデにはならない、というのが今回の実感です。
8. まとめ
- GitHub Actionsからさくらへの自動FTPデプロイが全失敗した原因は、さくらの「国外IPアドレスフィルタ」(初期設定で有効)だった
- フィルタは普通のページの閲覧は止めない。FTPはログインできても転送ができず、パスワードでのSSH・SFTP、メール送信、WordPressのログイン画面などの特定のファイルも海外から制限される
- エラーは原因を直接示さないため、「国内は通る・海外は通らない」という差から原因を絞った
- 解決策は「無効にする」「公開鍵認証のSFTPにする」「海外から接続しない構成にする」の3つ。許可リストはFTPやSSHには効かない
- 採用したのはCloudflare Pagesへの移行。フィルタを有効のまま自動デプロイを実現し、さくらは問い合わせフォームの処理として継続利用している
CloudflareおよびCloudflare Pagesなどのサービス名は、Cloudflare, Inc.の商標または登録商標です。
