GitHub Actionsからさくらへの自動FTPデプロイが全失敗した原因は、初期設定でオンの「国外IPアドレスフィルタ」でした。サイトは表示されるのにデプロイだけ落ちる症状の正体と、Cloudflare® Pages移行で解決した実体験を共有します。

【実録】さくら「国外IPアドレスフィルタ」で自動デプロイが半日ハマった話

結論: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アドレスフィルタが有効な状態で、海外からの通常ページの閲覧は通り、FTPやSSHによるファイル転送、WordPressのログイン画面などの特定のファイルへのアクセスは止められる様子と、GitHub Actionsからのデプロイが失敗する理由を示した図

海外の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. 同じ症状に出くわしたときのセルフチェック

「サイトは表示できるのに、自動デプロイだけが失敗する」という似た症状に出会ったら、次の順番で切り分けると早く原因にたどり着けます。

  1. 国内から同じ操作を試す:手元のパソコンなど国内のIPアドレスからFTPやSFTPで接続し、成功するかを確かめる。成功するなら、サーバーではなく「接続元の場所」に原因がある可能性が高い
  2. 管理画面でアクセス制限を探す:契約しているレンタルサーバーの管理画面で、海外からのアクセス制限の設定がないかを確認する。多くの国内レンタルサーバーが、同様の機能を標準で備えている
  3. 公式ヘルプを検索する:サーバー会社のヘルプで「海外」「国外」「GitHub」「アクセス制限」といった言葉を検索する
  4. エラーの番号の意味を調べる: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.の商標または登録商標です。

この記事を書いた人

野澤 孝理の横顔と上半身

株式会社curve

野澤 孝理

デジタルマーケティングを中心にClaude CodeやCodexを活用したサイト型LP制作、集客ツール設計、解析ツール導入や業務改善システムの構築等の集客×AIを掛け合わせた包括的支援を展開しております。

この内容を自社で相談する →