GitHub ActionsでConoHaへ自動デプロイする方法｜FTP手動アップロードをなくした運用

Webサイトを修正するたびに、FTPソフトを開いてファイルをアップロードする。

読者

GitHubにpushしたあと、毎回FTPでアップロードする作業ってなくせないの？

YuLab

なくせます。自分はGitHub ActionsからConoHa WINGへFTPSで自動デプロイする形に変えました。

私も最初は、コードを修正したあとに手動で公開作業をする形を考えていました。

ただ、制作物が増えるほど「どのサイトを、どの場所へ、どうやってアップロードするか」という管理が増えます。

そこで現在は、mainブランチへ反映したら、そのままConoHa WINGへ自動デプロイする流れに寄せています。

なぜFTP手動アップロードをやめたのか

手動FTPそのものが悪いわけではありません。制作物が少なく、更新頻度も低いなら十分実用的です。

問題になったのは、Webアプリやポートフォリオなど複数の制作物を並行して更新するようになったことでした。

コードの修正自体はAIやCodexで速くなっているのに、公開時だけ人間がFTPソフトを開き、接続先を確認し、アップロードする。

この状態だと、制作が速くなっても、公開工程に手作業が残り続けることになります。

そこで、更新から公開までを1本の流れにすることにしました。

実際に使っている公開フロー

AIやCodexでコードを修正する

まず、制作物のコードを修正します。ここはChatGPTやCodexなどを使っても、手作業でも構いません。

大切なのは、公開作業の起点をGitHubに揃えることです。

GitHubのmainブランチへ反映する

完成した変更をリポジトリのmainブランチへ反映します。

私の運用では、このmainへの更新を「本番へ出してよい変更」の基準として扱っています。

GitHub Actionsを起動する

mainへのpushをきっかけに、GitHub ActionsのWorkflowを実行します。

Workflow側では、公開対象のファイルをConoHa WINGへFTPSで転送します。

ここで重要なのは、FTPパスワードなどをWorkflowファイルへ直接書かないことです。

ConoHa WINGの指定ディレクトリへ反映する

GitHub Actionsから、制作物ごとに決めたConoHa WING内の公開先へ転送します。

たとえば、ポートフォリオとWebアプリを同じドメイン配下で運用していても、アップロード先はそれぞれ分けます。

本番URLで反映を確認する

GitHub Actionsが成功しただけで作業完了にはしません。

実際の本番URLで変更内容が表示されているかまで確認します。

Workflow成功は「転送処理が成功した」という情報であって、最終的な画面表示や機能まで保証するものではないからです。

制作物ごとにFTPアカウントを分けた理由

私の環境では、WordPressと静的な制作物を同じConoHa WING上で運用しています。

そこで、1つのFTPアカウントに広い権限を持たせるのではなく、制作物ごとに接続できるディレクトリを限定したFTPアカウントを使う形にしました。

自動化では「操作を減らす」だけでなく、失敗したときの影響範囲を小さくすることも重要だと感じています。

「Macで1コマンド」ではなく完全自動を選んだ理由

途中では、Macから1コマンド実行すればConoHaへアップロードできる方法も候補になりました。

技術的には十分便利です。

ただ、それでも毎回「公開コマンドを実行する」という人間の操作が1つ残ります。

制作物が1つなら小さな差ですが、制作物が増えると、その1操作を毎回覚えて実行する必要があります。

そのため、今回は「自動化するために新しい手作業を増やさない」ことを優先し、mainへのpushから公開までつながる形を採用しました。

自動デプロイで確認しておきたいポイント

530 Login authentication failedが出たときに学んだこと

自動デプロイを作る途中では、FTPSの認証で530 Login authentication failedが出たこともありました。

このとき役立ったのは、設定を闇雲に変更するのではなく、すでに成功している別のWorkflowと比較することでした。

さらに、同じ認証情報でローカルから直接接続できるかを試すことで、サーバー側・Workflow側・Secrets側のどこに問題がありそうかを切り分けやすくなりました。

認証エラーでは原因候補が複数あるため、同じActionsを何度も再実行するより、「成功例との比較」と「直接接続」で情報を増やした方が原因を絞りやすいと感じています。

自動化しても、人の確認をゼロにはしていない

GitHub Actionsで公開を自動化しても、何でも無確認で本番へ出すわけではありません。

費用発生、データ削除、セキュリティ、個人情報など影響が大きい操作は、今も人間側で確認する考えです。

一方で、すでに安全性を確認した通常の公開処理まで毎回人間が操作すると、自動化の効果が小さくなります。

通常処理は自動化し、高リスク操作だけ確認する。

この境界を作ることが、AIや自動化を長く使う上では重要だと思っています。

まとめ

自動化の目的は、技術的に高度な仕組みを作ることではありません。

毎回発生する人間の操作と判断を減らし、制作そのものに使える時間を増やすことです。

公開先そのものをNetlifyやGitHub PagesからConoHaへ整理した流れは、Netlify・GitHub PagesからConoHaへ移行する手順でまとめています。

また、「どこまで自動化すべきか」の判断基準は、AI自動化はどこまでやるべき？回収期間と成果シグナルで判断する方法で紹介しています。