FTPの手動更新をやめる｜会社サイトの一部だけGitHubで自動公開した手順

今回、何を自動化したの？

合同会社SaGaSの公式HP内には、「中小企業IT改善室」という独立したコンテンツがあります。今回の対象は、この改善室に当たる/lab/配下だけです。公式HP本体のファイルはGitHubへ登録せず、本番サーバーでも改善室以外へ接続できない構成にしました。

初回登録は192ファイル、約3MBです。GitHubの非公開リポジトリへ登録し、更新がmainブランチへ入った時だけGitHub Actionsが動き、暗号化されたFTPS接続で/lab/を公開します。

手動FTPの何が危ないの？

FTPソフトが悪いわけではありません。問題は、毎回の判断と操作を人の記憶だけに任せることです。接続先を間違える、必要なファイルを選び忘れる、古いファイルを混ぜる、どの版を公開したか分からなくなる、といった事故が起こります。

特に会社サイトでは、トップページ、問い合わせフォーム、メール設定に関係するファイルまで同じアカウントで操作できると、一つの誤操作が広い範囲へ及びます。「注意して操作する」だけでなく、そもそも対象外へ触れない権限にする方が安全です。

• 更新対象と本体サイトが同じ画面に並ぶ
• 公開前後のファイル差分を記録していない
• FTPパスワードを複数人が共有している
• 失敗時に戻す版が分からない
• アップロード完了を担当者しか確認できない

GitHubから公開される仕組みは？

GitHubは「サイトの原本と変更履歴を保管する場所」、GitHub Actionsは「決めた条件で公開作業を実行する係」です。FTPSは、FTP通信をTLSで暗号化する接続方式です。担当者は毎回サーバーへ接続せず、GitHubへ変更を送るところまで行います。

1. STEP 1パソコン対象フォルダのファイルを更新
2. STEP 2GitHub原本と変更履歴を保存
3. STEP 3Actions安全確認後にFTPS接続
4. STEP 4公開サーバー対象フォルダだけ更新

この構成なら「誰が、いつ、何を変えたか」がコミット履歴に残り、公開処理の成否もActionsの実行履歴で確認できます。公開後に問題が見つかった時は、正常だった版へ戻して再度公開できます。

事故を防ぐために、どんな設計にした？

第一に、FTPアカウントの接続先を/lab/へ限定しました。 ワークフローの設定を誤っても、そのアカウントでは公式HPの上位フォルダへ移動できません。権限を先に狭くする「最小権限」の考え方です。

第二に、ユーザー名・サーバー名・パスワードをGitHub Secretsへ登録しました。 YAMLファイルへ直接書くと、非公開リポジトリでも履歴に残ります。後から行を消しても、過去のコミットから見える可能性があります。

第三に、転送しない確認を先に実行しました。 対象ファイル、秘密情報らしい文字列、シンボリックリンク、接続方式を確認し、問題がないことを確かめてから本番転送を有効にしました。

第四に、外部ActionをコミットSHAで固定しました。 @v4のような可変タグではなく、確認した版の完全なコミットIDを指定すると、同じ設定名の参照先が変わるリスクを抑えられます。

初心者は、どの順番で設定すればいい？

一度に本番公開まで進めず、次の八段階に分けます。各段階の完了条件を確認してから次へ進むことが重要です。

1. 公開対象を分離する：GitHubへ入れるフォルダと、入れない公式HP本体を分ける
2. 秘密情報を検査する：パスワード、APIキー、個人情報、設定ファイルを検索する
3. 非公開リポジトリへ初回登録する：既存READMEを残し、対象フォルダだけ追加する
4. GitHub Desktopでクローンする：パソコン側に正しいリポジトリのコピーを作る
5. 限定FTPアカウントを作る：接続先ディレクトリを公開対象へ固定する
6. Repository secretsを登録する：接続情報をYAMLへ直接書かない
7. 手動テストを実行する：対象と接続条件を確認し、転送前チェックを通す
8. 本番公開して照合する：Actionsの成功、公開URL、ファイル件数、主要ページを確認する

ワークフローの中心部分は次のようになります。完全なテンプレートではなく、対象範囲と秘密情報の扱いを理解するための例です。接続先ディレクトリをFTPアカウント側で/lab/に固定しているため、Action側のserver-dirは./です。

name: Deploy lab only

on:
  push:
    branches: [main]
    paths:
      - "lab/**"

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1

      - name: Deploy lab through encrypted FTPS
        uses: SamKirkland/FTP-Deploy-Action@3a9c65ae0fc12ac924ccef8afc26941cc43aad0b
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps
          local-dir: ./lab/
          server-dir: ./

次回からの更新作業はどう変わる？

初期設定後は、担当者がFTPソフトを開く必要はありません。パソコン側のlab/内でファイルを追加・修正し、GitHub Desktopで変更内容を確認して、分かる名前でコミットし、Push originを押します。

mainへ反映されると自動公開が始まります。GitHubのActions画面で緑のチェックになったことを確認し、公開URLを開いて、変更したページと共通部分を確認します。成功表示だけで終わらせず、実際のサイトを見るところまでが更新作業です。

戻す時は、GitHub上の正常だったコミットを基準に復元し、再度mainへ反映します。サーバー上のファイルだけを直接直すと、次回の自動公開で元へ戻る可能性があるため、原本は必ずGitHub側で管理します。

この方法が向くサイト・向かないサイトは？

HTML、CSS、JavaScript、画像などで構成された静的サイトや、他から独立したサブディレクトリには向いています。更新履歴を残したい、複数人で確認したい、FTP操作を減らしたい会社にも有効です。

一方、WordPressはデータベース、管理画面から追加した画像、プラグインやテーマの更新が関係します。ファイルだけをGitHubから送っても、サイト全体の状態は再現できません。予約・決済・会員機能などがある場合も、開発環境、データ移行、動作確認、切り戻しを含む別の設計が必要です。

実際に迷った点と、確認する順番

GitHub Desktopの認証画面で広い権限が見える：公式のGitHub Desktopアプリで、接続するアカウントが正しいかを確認します。認証後は対象リポジトリをクローンし、別のリポジトリへ誤って追加しないよう左上のリポジトリ名を確認します。

Actionsが「Queued」のまま：これは失敗ではなく実行待ちです。まず数分待って画面を更新します。長時間変わらない時だけ、GitHub Status、同時実行中の処理、Actionsの利用制限を確認します。

緑のチェックが付いたのに表示が古い：公開URLの対象ページを直接開き、強制再読み込みを試します。その後、転送元のファイル、公開先、キャッシュの順に切り分けます。むやみに再実行すると原因が分からなくなります。

秘密情報を間違ってコミットした：ファイルから消すだけでは不十分です。まず資格情報を失効・変更し、GitHub公式手順に沿って履歴からの削除が必要か判断します。パスワードをチャット、Issue、YAML、スクリーンショットへ載せない運用が最も重要です。