記事一覧 GitHub Actions とは？ホームページを自動で公開する仕組みと、画面の見方

コーディング 2026.11.09

GitHub Actions とは？ホームページを自動で公開する仕組みと、画面の見方

制作会社に頼んでいたお知らせの修正を、ことらが GitHub の画面で確かめ終えたのは、午後3時だった。
風虎先生からの連絡には、こうあった。
「プルリクエストを確かめて、問題が無ければ、マージのボタンを押してください。マージすると、数分でホームページに反映されます」
マージの意味は、前に教わった。
作業したブランチを、main に合わせることだ。
でも、合わせただけで、どうしてホームページが変わるのだろう。
サーバーにファイルを上げる作業は、誰がしているのだろう。
ことらは、マージのボタンを押す前に、電話をかけた。

ことら「マージすると、ホームページに反映されます」とありましたが……。
FTP でサーバーに上げる作業は、誰がやるんですか？

風虎先生手で上げる人は、いません。
マージを合図に、GitHub Actions という仕組みが、自動でサーバーに上げます。
どういう仕組みか、順番に説明しますね。

「マージすると、自動で公開されます」「Actions が失敗しました」——。
こんな連絡が届いて戸惑う方に向けて、GitHub Actions の仕組みと言葉、ホームページを自動で上げる例、画面の見方、費用、気をつけることをまとめました。
プッシュ／マージ／プルリクエストなど、Git の言葉は、前の記事Git とは？ GitHub との違いと、コミット／プッシュ／プル／マージの意味で説明しています。

GitHub Actions とは
リポジトリで起きたことをきっかけに、決めた作業を自動で行う仕組み
Git／GitHub との関係
どこで動くか
何に使えるか
動く仕組みと言葉
ワークフロー（workflow）
きっかけ（on）
ジョブとステップ（jobs／steps）
ランナー（runs-on）
アクション（uses）
例：main にマージしたら、ホームページを自動で上げる
流れの図
ワークフローのファイルを読む
パスワードや鍵の置き場所（Secrets）
テストサーバーと本番サーバーで上げ先を変える
上げないファイルを決める
画面の見方
Actions の画面：緑のチェックと赤の×
失敗した時：ログの読み方と通知のメール
もう一度動かす
「マージ＝公開」になった時に変わること
費用と上限
公開リポジトリは無料、非公開は月の無料分まで
使った分の確かめ方
気をつけること
パスワードや鍵を、ファイルやログに出さない
使うアクションの作者と版を確かめる
権限は要る分だけにする
失敗の通知を受け取る人を決める
よくある質問
まとめ

GitHub Actions とは

リポジトリで起きたことをきっかけに、決めた作業を自動で行う仕組み

GitHub Actions は、GitHub に付いている、作業を自動で行う仕組みです。
「リポジトリで○○が起きたら、△△をする」という決まりを、1つのファイルに書いておきます。
そのファイルをリポジトリに入れておくと、GitHub が○○を見張っていて、起きた時に△△を人の代わりに行います。

○○には、プッシュ／プルリクエスト／決まった時刻などが入ります。
△△には、サーバーにファイルを上げる／ファイルの中身を確かめる、などが入ります。
例えば、「main にマージしたら、ホームページのサーバーにファイルを上げる」と書いておくと、マージのたびに、GitHub がファイルを上げてくれます。

「デプロイ」とは何ですか？

サーバーにファイルを上げて、公開することです。
エンジニアは、FTP で手で上げる作業も、GitHub Actions で自動で上げることも、まとめて「デプロイ」と呼びます。
制作会社からの連絡にこの言葉が出てきたら、この記事の「上げる」に読み替えて大丈夫です。

「CI／CD」とは何ですか？

直したファイルを自動で確かめる仕組み（CI）と、確かめたものを自動で上げる仕組み（CD）を合わせた呼び方です。
CI は Continuous Integration、CD は Continuous Delivery（または Deployment）の略です。
GitHub Actions は、CI／CD を行う道具の1つです。
制作会社からの連絡にこの言葉が出てきたら、この記事の「自動の作業」に読み替えて大丈夫です。

Git／GitHub との関係

名前が似ているので、3つの役割を分けておきます。

Git: ファイルの変更の履歴を残す仕組み。
自分のパソコンの中で動く
GitHub: Git のリポジトリを置いて、人と共有するサービス。
プルリクエストやマージのボタンもここにある
GitHub Actions: GitHub の中で動く、自動の作業。
リポジトリで起きたことを合図に動く

GitHub Actions は、GitHub の一部です。
リポジトリを GitLab や Bitbucket に置いている場合は使えません。
その代わり、それぞれに同じ役目の仕組みがあります（よくある質問）。

どこで動くか

ことらは、電話を繋いだまま、自分のパソコンを見た。
FTP のソフトは入っている。
でも、GitHub Actions というソフトは、どこにも見当たらない。

ことら自動で上げる、ということは、私のパソコンで何かが動くんですか？
それとも、ホームページのサーバーに何か入れてあるんですか？

風虎先生どちらでもありません。
GitHub のサーバーの中で動きます。
ことらさんのパソコンの電源が切れていても、ホームページのサーバーに何も入れていなくても、動きますよ。

ホームページのファイルがある場所と、GitHub Actions が動く場所の関係は、次の図の通りです。

自分のパソコン

見るのは、自分だけ

作業フォルダ

ファイルを直す

プッシュ（push）で送る

プル（pull）で受け取る

GitHub

非公開なら、許可した人だけが見る

リモートリポジトリ

ファイルと修正履歴の置き場

GitHub Actions

決めた作業を自動で行う

（GitHub が用意したパソコンで動く）

Actions がアップロードする（FTP／SSH）

ホームページの
サーバー

ここに置いたものが、ブラウザに出る

テストサーバー

公開する前に、見た目を確かめる

本番サーバー

公開しているホームページ

図1：GitHub Actions が動く場所

前の記事の図では、自分のパソコンからホームページのサーバーへ、人が FTP で上げていました。
GitHub Actions を使うと、この「上げる」の矢印が、GitHub から出るようになります。
GitHub が用意したパソコン（ランナー）が、リポジトリからファイルを取り出し、ホームページのサーバーへ送ります。
ホームページのサーバーには、出来上がったファイルが届くだけで、特別なものを入れる必要はありません。

何に使えるか

「リポジトリで起きたことをきっかけに、決めた作業を行う」仕組みなので、使い道はいろいろあります。
会社のホームページでよく使うのは、次の4つです。

ホームページをサーバーに上げる: main にマージしたら本番サーバーへ、テスト用のブランチ（develop など）にマージしたらテストサーバーへ上げる。
この記事で説明する使い方
直したファイルを確かめる: プルリクエストを作った時に、リンク切れ／HTML の文法／画像の大きさなどを確かめて、問題があれば知らせる
決まった時刻の作業: 毎週月曜の朝に、サーバーのファイルの控えを取る。
毎日、掲載期限の切れたお知らせが無いか確かめる
他のサービスに知らせる: 上げ終わったら、チャットに「公開しました」と連絡を入れる

このうち、中小企業のホームページで一番よく使うのは、1つめの「サーバーに上げる」です。
この記事でも、これを例に説明します。

動く仕組みと言葉

GitHub の蔵の脇で半鐘が鳴り、壁の指図書の通りに、ぜんまい仕掛けの白い虎が蔵から巻物を取り出して風呂敷に包み、サーバーの島へ向かう船に積んでいる。仕事を終えた前のからくりは煙になって消えかけ、丸眼鏡の白虎が指図書を指して見守っている — 鐘が鳴ったら、指図書の通りに

GitHub Actions の説明や、制作会社との会話に出てくる主な言葉は、次の5つです。
1つの決まりを書いたファイルが「ワークフロー」で、その中に「きっかけ」「ジョブ」「ランナー」「アクション」を書きます。
ジョブの中の1つ1つの手順が「ステップ」です。
上の図では、鐘が「きっかけ」、蔵の壁の指図書が「ワークフロー」、ぜんまい仕掛けの虎が「ランナー」、巻物を取り出して船に積む手順が「ステップ」、道具箱が「アクション」にあたります。

ワークフロー（workflow）

ワークフローは、「○○が起きたら、△△をする」の決まりを書いた、1つのファイルです。
リポジトリの .github/workflows/ というフォルダに置きます。
ファイルの形式は YAML（ヤムル）で、名前は deploy.yml のように付けます。
ホームページを上げる決まりと、リンク切れを確かめる決まりは、別のファイルにします。

リポジトリの中

.github/
  workflows/
    deploy.yml      ← main にマージしたら、本番サーバーに上げる
    deploy-test.yml ← develop（テスト用のブランチ）にプッシュしたら、テストサーバーに上げる
index.html
css/
img/

YAML は、「項目名: 値」を、字下げで階層にして書く形式です。
字下げはスペースで（普通は2つ）、タブは使えません。
字下げが1つずれるだけで動かなくなるので、直す時は、元の形をよく見て合わせます。
このフォルダにファイルを置くと、GitHub がそれを見つけて、Actions の画面に name に書いた名前で並べます。

きっかけ（on）

ワークフローの on の項目に、「○○が起きたら」の○○を書きます。
よく使うきっかけは、次の4つです。

書き方	いつ動くか	使い道
`push`	プッシュがあった時（ブランチを絞れる）	サーバーに上げる
`pull_request`	プルリクエストを作った時と、そのブランチにプッシュした時	マージする前に、ファイルを確かめる
`workflow_dispatch`	Actions の画面で、人がボタンを押した時	もう一度上げ直す。試しに動かす
`schedule`	決まった時刻。 cron という書き方で指定する。時刻は世界標準時なので、日本時間から9時間引いて書く	控えを取る。定期の確認

main にマージした時に上げるなら、「main にプッシュがあった時」と書きます。
プルリクエストをマージすると、main に新しいコミットが入るので、GitHub はこれを main へのプッシュとして扱います。

deploy.yml（きっかけの部分）

on:
  push:
    branches: [main]
  workflow_dispatch:

この例は、「main にプッシュがあった時」と「画面でボタンを押した時」の2つを、きっかけにしています。
ボタンを足しておくと、サーバー側の都合で失敗した時に、ファイルを変えずに上げ直せます（もう一度動かす）。

ジョブとステップ（jobs／steps）

「△△をする」の中身は、ジョブとステップに分けて書きます。

ジョブ（job）: GitHub が用意する1台のパソコン（ランナー）で行う、ひとまとまりの作業。
「本番サーバーに上げる」なら、ジョブは1つ。
ジョブを2つ以上書いた時は、順番ではなく、GitHub がジョブの数だけパソコンを用意して、同時に動かす
ステップ（step）: ジョブの中の、1つ1つの手順。
「ファイルを取り出す」「サーバーに送る」のように、上から順に動く

ステップは上から順に動き、1つが失敗すると、そのジョブはそこで止まります。
後ろのステップは動きません。
Actions の画面では、どのステップで止まったかが赤い印で分かるので、失敗した時はそこを見ます（ログの読み方）。

ランナー（runs-on）

ランナーは、ジョブを動かすパソコンのことです。
ジョブ毎に runs-on で種類を指定します。
ホームページを上げる作業なら、ubuntu-latest（GitHub が用意する、Ubuntu という Linux の一番新しい版）で足ります。

ランナーは、使い捨て

GitHub は、ジョブが動くたびに、まっさらなパソコンを1台用意します。
ジョブが終わると、そのパソコンは消えます。
前回のファイルは残っていないので、毎回、リポジトリからファイルを取り出すところから始めます（次の「アクション」の checkout）。

Windows や macOS のランナーもありますが、ホームページを上げる作業には Linux で足ります（費用の違いは費用と上限）。
自社のパソコンやサーバーをランナーとして登録する方法（セルフホスト）もありますが、会社のホームページを上げるだけなら、GitHub が用意するランナーで足ります。

アクション（uses）

アクションは、他の人が作って公開している、手順の部品です。
ステップの uses に「作者/名前@版」の形で書くと、その手順を自分で書かずに使えます。
ホームページを上げるワークフローで使うのは、次の2つです。

actions/checkout: リポジトリのファイルを、ランナーに取り出す。
GitHub 自身が作っていて、ほとんどのワークフローの最初のステップに入る
SamKirkland/FTP-Deploy-Action: 取り出したファイルを、FTP でサーバーに送る。
個人の開発者が作っていて、レンタルサーバーへ上げる時によく使う

アクションは、GitHub Marketplace というページで探せます。
名前が actions/ で始まるものは GitHub 自身が作ったもので、それ以外は個人や会社が作ったものです。
他の人が作ったものを自分のリポジトリで動かすので、作者と版の確かめ方は、気をつけることで説明します。

アクションを使わず、run にコマンドを直接書くステップもあります。
SSH で繋げるサーバーなら、rsync というコマンドで送る形もあります。

例：main にマージしたら、ホームページを自動で上げる

ここからは、会社のホームページのファイルを GitHub で管理していて、レンタルサーバーに FTP で上げている場合を例に、ワークフローの中身を見ていきます。

流れの図

お知らせを1つ直して、公開するまでの流れです。
人がするのは、1. と 2. だけです。

1. 直して、プッシュする

人がする

作業用のブランチ

お知らせを直して、コミットし、GitHub にプッシュする

プルリクエストを作る

2. 確かめて、マージする

人がする

プルリクエストの画面

変わった所を見て、問題が無ければ main にマージする

main へのプッシュを合図に動く

3. GitHub Actions が上げる

自動

ランナー

main のファイルを取り出し、FTP で本番サーバーに送る

（1〜2分）

送り終わる

4. ホームページが変わる

自動

本番サーバー

新しいお知らせが、ブラウザに出る

図2：マージしてから、ホームページが変わるまで

前の記事の「作業の流れの例」と、2. までは同じです。
違うのは、マージした後に、人が FTP で上げる作業が無くなることです。
マージのボタンを押した人が、そのまま公開した人になります。

ワークフローのファイルを読む

図2 の 3. を行うワークフローは、次のような短いファイルです。
全部で 20 行ほどで、制作会社が作って、リポジトリに入れます。

.github/workflows/deploy.yml

name: 本番サーバーに上げる

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

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

      - uses: SamKirkland/FTP-Deploy-Action@v4.4.0
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USER }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps
          server-dir: /public_html/
          exclude: |
            **/.git*
            **/.git*/**
            **/.vscode/**
            docs/**

上から順に読むと、次の意味になります。

行	意味
`name`	このワークフローの名前。 Actions の画面にこの名前で並ぶ。日本語でも良い
`on`	きっかけ。 main にプッシュがあった時と、画面でボタンを押した時
`permissions`	ワークフローに自動で付く権限。リポジトリを読むだけにする（権限は要る分だけにする）
`jobs` / `deploy`	ジョブの一覧。ここでは deploy という名前のジョブが1つ
`runs-on`	ランナーの種類。 Ubuntu（Linux）の一番新しい版
`steps`	手順の一覧。上から順に動く
`uses: actions/checkout`	1つめの手順。リポジトリの main のファイルを、ランナーに取り出す
`uses: SamKirkland/FTP-Deploy-Action`	2つめの手順。取り出したファイルを FTP で送る。 `with` の下が、そのアクションへの指示
`server` / `username` / `password`	FTP の接続先／ID／パスワード。値はここに書かず、Secrets から読む（次の節）
`protocol: ftps`	通信を暗号化する FTPS で繋ぐ。サーバーが対応していれば、こちらにする
`server-dir`	サーバー側の、ホームページのファイルを置くフォルダ
`exclude`	上げないファイル（上げないファイルを決める）

読んでみると、「main が変わったら、ファイルを取り出して、FTP で送る」と書いてあるだけです。
人が FTP ソフトでしていた操作を、文字にしたものと思ってください。

パスワードや鍵の置き場所（Secrets）

FTP のパスワードを、ワークフローのファイルに直接書くと、リポジトリを見られる人全員に見えてしまいます。
後からファイルから消しても、履歴には残ったままです。
そこで、パスワードのような値は、リポジトリの Secrets（シークレット）という場所に入れておき、ワークフローからは名前で読みます。

リポジトリの Settings を開く

左の一覧から「Secrets and variables」→「Actions」を選びます。
「New repository secret」で値を登録する

名前（例：FTP_PASSWORD）と値を入れて保存します。
名前は英字と数字と _ で付けます（大文字で書くのが普通です）。
ワークフローから名前で読む

${{ secrets.FTP_PASSWORD }} と書くと、動く時に値に置き換わります。

登録した値は、登録した本人にも、二度と画面に出ません（上書きだけ出来ます）。
動いた記録のログにも、登録した値は伏せ字で出ます。
FTP のパスワードを変えた時は、Secrets の値も変えます。
変え忘れると、次の上げる作業が失敗します。

テストサーバーと本番サーバーで上げ先を変える

公開する前に、テストサーバーで見た目を確かめたいことがあります。
その場合は、ワークフローを2つにして、きっかけのブランチと、上げ先を分けます。
テスト用に develop というブランチを作り、作業したブランチをいったんそこに集めて、テストサーバーで確かめてから main に入れる形です。

ファイル	きっかけ	上げ先	Secrets の名前
deploy-test.yml	develop にプッシュ	テストサーバー	FTP_SERVER_TEST など
deploy.yml	main にプッシュ	本番サーバー	FTP_SERVER など

作業したブランチを develop にマージすると、テストサーバーに上がります。
テストサーバーで確かめて、develop を main にマージすると、本番サーバーに上がります。
ブランチの名前が、そのまま「どこに上がるか」になるので、マージする前に、どのブランチへのマージかを確かめます。

上げないファイルを決める

リポジトリには、ホームページに要らないファイルも入っています。
exclude に書いたものは、サーバーに上がりません。

Git の管理用のファイル（.git、.github）
VS Code などの設定（.vscode）
原稿や設計書のフォルダ、作業用のプログラム

注意

上げるアクションの設定によっては、リポジトリに無いファイルを、サーバーからも消します。
サーバーにだけあるもの（フォームの送信記録／お客様が上げた画像など）も exclude に書いておくと、消す対象から外れます。
最初の1回は、テストサーバーで、消えて困るものが残っているかを確かめてから、本番サーバーに使います。

上げるファイルは、初回は全部、2回目からは変わったファイルだけです。
FTP-Deploy-Action は、サーバーに小さな記録ファイルを置いて、前回からの違いを見分けます。
そのため、お知らせを1つ直した時は、数ファイルを送るだけで終わり、1〜2分で済みます。

画面の見方

自動で動く仕組みなので、Web担当者がすることは、「動いたか」「失敗していないか」を画面で見ることです。
リポジトリの上の方にある「Actions」を開きます。

Actions の画面：緑のチェックと赤の×

Actions の画面には、動いた記録が、新しい順に並びます。
1行が1回の実行で、左の印が結果です。

緑のチェック: 最後まで動いた。
ホームページを上げるワークフローなら、サーバーに届いている
赤の×: 途中で失敗した。
ホームページは、前の状態のまま（途中まで送っていることもある）
黄色の丸: 今、動いている。
1〜2分待つ

行を押すと、その実行の中身が開きます。
左にジョブ、右にステップが並び、ステップを押すと、その時に出た文字（ログ）が読めます。
マージした後にホームページを見て、変わっていない時は、まずここを開いて、緑か赤かを見ます。
緑なのに変わっていない時は、ブラウザが前の表示を覚えていることが多いので、再読み込み（Windows は Ctrl+F5）をしてから、もう一度見ます。

失敗した時：ログの読み方と通知のメール

赤の×の実行を開くと、失敗したステップにも赤の印が付いています。
そのステップを押して、ログの一番下の数行を読みます。
失敗の理由は、たいてい最後の数行に書いてあります。
ホームページを上げるワークフローで多いのは、次の4つです。

ログに出る言葉の例	起きていること	直す所
530 Login incorrect	FTP の ID かパスワードが違う。サーバーでパスワードを変えた後に多い	Secrets の値
ENOTFOUND／Timeout	接続先の名前が違うか、サーバーが接続を受け付けていない。レンタルサーバーによっては、国外からの FTP 接続を初期設定で止めていて、海外にある GitHub のランナーからの接続を通さない	Secrets の接続先。サーバーの管理画面の接続制限
Invalid workflow file	ワークフローのファイルの書き方が間違っている（字下げのずれなど）。動く前に止まる	deploy.yml
No such file or directory	上げ先のフォルダ名が違う。大文字と小文字の違いも含む	server-dir の値

失敗すると、GitHub からメールも届きます。
届くのは、そのワークフローを動かすきっかけを作った人です。
main にマージして動いたなら、マージのボタンを押した人に届きます。
GitHub の通知の設定で、「失敗した時だけ」か「毎回」かを選べます。
毎回届くと読まなくなるので、失敗した時だけにしておく形が多いです。

もう一度動かす

サーバーの一時的な不調など、ファイルを変えずに上げ直したい時は、2つの方法があります。

Re-run all jobs: 失敗した実行を開いて、右上のボタンを押す。
同じコミットで、もう一度動く。
動いてから 30 日以内
Run workflow: きっかけに workflow_dispatch を入れてあるワークフローは、左の一覧で選ぶと、このボタンが出る。
今の main で動く

Secrets の値を直した後は、Re-run で同じコミットを上げ直せます。
ワークフローのファイルを直した場合は、直したものを、同じようにプルリクエストで main に入れると、それがきっかけになって、また動きます。

「マージ＝公開」になった時に変わること

説明を聞き終えて、ことらは、マージのボタンを前にして、もう一度手を止めた。

ことらということは、このボタンを押した瞬間に、公開されるんですね。
前は、制作会社さんが上げてくれるまでに、もう一度見直す時間があったんですが……。

風虎先生はい。
だから、見直す場所が、マージの前に移ります。
プルリクエストの画面で変わった所を見て、テストサーバーで表示を確かめてから、押してください。
押した人と時刻は、履歴に残りますよ。

GitHub Actions でホームページを上げるようにすると、main へのマージが、公開の合図になります。
便利になる代わりに、次のことが変わります。

見直す場所が、「上げる前」から「マージする前」に移る。
プルリクエストの画面と、テストサーバーで確かめてからマージする
main に直接プッシュしない。
作業はブランチで行い、プルリクエストを通す（直接プッシュすると、確かめる間もなく公開してしまう）
急いで直す時も、同じ道を通る。
手で FTP で上げると、リポジトリとサーバーの中身が食い違い、後で自動の作業が上書きした時に、手で直した分が消える
誰が、いつ公開したかが、GitHub の履歴に残る。
「誰が上げたか分からない」が無くなる

プルリクエストで確かめてからマージする流れは、前の記事のプルリクエストで確かめてから合わせるで説明しています。

費用と上限

公開リポジトリは無料、非公開は月の無料分まで

GitHub Actions の費用は、ランナーが動いた時間で決まります。
会社のホームページのリポジトリは非公開にすることが多いので、非公開の場合で説明します。
無料分の大きさや、1分あたりの単価は変わるので、この記事には書かず、GitHub の料金ページで確かめてください。

公開リポジトリ: GitHub が用意する標準のランナーなら、時間に関係なく無料
非公開リポジトリ: 無料のプラン（Free）でも、月に決まった金額分だけ、ランナーを使える枠が付いてくる。
使った時間を単価で金額に直して、この枠から引く。
有料のプランでは、枠が増える

ホームページを上げるジョブは、1回 1〜2分です。
毎日1回上げても、月に1時間ほどで、無料のプランの枠で足ります。
時間はジョブ毎に数え、1分に満たない分は切り上げます。
Windows や macOS のランナーは Linux より単価が高いので、ホームページを上げる作業には Linux を使います。

補足

支払い方法を登録していなければ、無料分を使い切った時点で、その月はワークフローが動かなくなります。
そのため、知らないうちに請求が来る形にはなりません。
支払い方法を登録している場合は、「予算（budget）」で、超えた分を止めるか、支払って続けるかを決めます。

時間の他に、1つのジョブの長さ／同時に動かせるジョブの数／ワークフローが保存するファイル（控えなど）の置き場の容量にも上限があります。
ホームページを上げる使い方なら、どれも気にならない大きさです。
今の値は、GitHub Docs の上限のページに載っています。

使った分の確かめ方

使った分は、GitHub の Settings の「Billing and licensing」にある「Usage」で見られます。
個人のアカウントなら自分の Settings、会社の Organization（組織）で管理しているなら、その Organization の Settings です。
月の途中で「残りがどのくらいか」を見たい時と、翌月に「先月どのくらい使ったか」を見たい時に開きます。
ホームページを上げるだけの使い方なら、毎月見る必要はなく、ワークフローを増やした時に一度見ておけば足ります。

気をつけること

GitHub の蔵の前で、丸眼鏡の白虎が「極秘」の判を押したサーバーの文書を、錠前の付いた鉄の扉の棚にしまっている。隣の開いた棚には巻物が並ぶ。もう一方では同じ白虎が虫眼鏡で行商人のかごの道具の焼き印と札を確かめ、ぜんまい仕掛けの小さな虎が道具に手を伸ばし、岩の陰には偽の札を持った狐が隠れている。奥の島にはサーバーの看板の城 — 極秘の文書は鉄の棚に、道具は印を見て

GitHub Actions は、リポジトリの中身と、サーバーのパスワードを扱います。
設定するのは制作会社でも、次の4つを Web担当者が知っておくと、連絡の意味が分かります。
上の図で、左の白虎が鉄の扉の棚にしまっているのは、サーバーに入るためのパスワードを書いた極秘の文書で、この棚が Secrets です（隣の開いた棚の巻物が、普通のファイル）。
右の道具の焼き印と札が作者と版、岩の陰の狐がすり替えにあたります。

パスワードや鍵を、ファイルやログに出さない

FTP のパスワードや SSH の鍵は、Secrets にだけ入れます（Secrets）。
ワークフローのファイルや、リポジトリの他のファイルにも書きません。
加えて、動いている途中で画面に出す（ログに出す）書き方も避けます。
GitHub は、Secrets に登録した値がログに出ると伏せ字にしますが、値の一部だけや、形を変えたものまでは伏せられません。

リポジトリに入れてしまった時は、消すだけでは履歴に残るので、そのパスワードを変えます。

使うアクションの作者と版を確かめる

アクションは、他の人が作った手順を、自分のリポジトリとパスワードを渡して動かすものです。
作者が信用できるかと、版を固定しているかを確かめます。

実際にあったこと

2025年3月、2万以上のリポジトリで使われていたアクション「tj-actions/changed-files」を、何者かが書き換えました。
その人物は、作者が自動化に使っていたアカウントの鍵を盗み、アクションの中身を不正なものに替えました。
さらに、v45 のような版の名前が指す先も、その不正な中身に向け直しました。
そのため、版を名前で指定していたワークフローは、次に動いた時に不正な中身を実行し、Secrets の値をログに書き出してしまいました。
公開リポジトリでは、そのログを誰でも見られる状態でした。

この出来事の後、GitHub は次の3つを勧めています。

GitHub 自身が作るもの（actions/ で始まる）や、使っている人が多く、更新が続いているものを選ぶ
版は、@v4 のような名前ではなく、コミットの ID（40 桁の英数字）で固定する。
ID は後から向け直せない
Dependabot（GitHub の機能）に、アクションの新しい版を知らせてもらい、人が確かめてから更新する

この記事の例では読みやすさのために @v7 のように書いていますが、実際のリポジトリでは、制作会社が ID で固定しているかを聞いてみてください。

権限は要る分だけにする

ワークフローには、動く時に、そのリポジトリを扱う権限（GITHUB_TOKEN）が自動で付きます。
2023年2月より前に作ったリポジトリでは、この権限の既定が「読み書き」のままになっていることがあります（それより後に作ったリポジトリは、「読む」だけが既定です）。
ホームページを上げるだけなら、「読む」だけで足ります。
ワークフローに permissions で読むだけと書くか（3-2 の例にも入れてあります）、リポジトリの Settings で、自動で付く権限を読むだけにしておきます。
読むだけにしておく理由は、6-2 のように、アクションの中身をすり替えられた場合への備えです。
アクションは、ワークフローと同じ権限で動きます。
権限が「読み書き」のままだと、すり替えられたアクションが、自分のリポジトリのファイルまで書き換えられてしまいます。
「読む」だけにしておけば、リポジトリは書き換えられません。

deploy.yml（権限の部分／3-2 の例の on と jobs の間）

permissions:
  contents: read

失敗の通知を受け取る人を決める

失敗のメールは、決まった人ではなく、そのワークフローを動かした人に届きます。
main にマージして動いたなら、マージのボタンを押した人です（通知のメール）。
マージする人が日によって違うと、メールの届く先もばらばらになり、誰も気付かないことがあります。
決まった時刻に動くワークフローは、時刻の設定を最後に書いた人に届くので、その人が退職すると、誰にも届きません。

「失敗のメールが来たら、誰が見て、誰に伝えるか」を、制作会社と決めておきます。
ホームページが変わっていない時に Web担当者が Actions の画面を見るようにするだけでも、気付くまでの時間が短くなります。

よくある質問

手で FTP で上げるのと、何が違いますか？

上がるファイルは同じです。
違うのは、「誰が、いつ、何を上げたか」が GitHub の履歴に残ることと、上げ忘れや、古いファイルで上書きする間違いが無くなることです。
手で上げる時は、作業した人のパソコンのファイルが上がるので、他の人の直した分が入っていないことがあります。
GitHub Actions では main のファイルを上げるので、全員の直した分が揃った状態になります。

レンタルサーバーの Git 連携の機能とは、何が違いますか？

レンタルサーバーの中には、管理画面でリポジトリを登録すると、プッシュした時にサーバー側がファイルを取り込む機能を持つものがあります。
ファイルを上げるだけなら、そちらの方が設定は簡単です。
GitHub Actions は、上げる前にファイルを確かめたり、上げ先を切り替えたり、上げた後に連絡を入れたりと、作業を組み合わせられる点が違います。
サーバーにその機能が無い場合も、FTP か SSH で繋げれば使えます。

GitLab や Bitbucket、Backlog でも、同じことは出来ますか？

GitLab には GitLab CI/CD、Bitbucket には Bitbucket Pipelines という、同じ役目の仕組みがあります。
書き方は違いますが、「○○が起きたら、△△をする」の考え方は同じです。
Backlog の Git には、この仕組みはありません。
Backlog のリポジトリから自動で上げたい場合は、別のサービスと組み合わせます。

自分の会社で設定できますか？

ワークフローのファイルは 20 行ほどで、この記事の例を基に書けます。
ただ、最初の1回は、上げないファイルの選び方、サーバーの接続制限、消えて困るファイルの確かめ方で、つまずきやすい所があります。
ホームページを制作会社に頼んでいる場合は、「GitHub Actions で上げる形に出来ますか」と相談して、設定を見てもらう方が確実です。
設定した後の「動いたか」「失敗していないか」の確認は、自社で出来ます。

Actions が失敗した時、ホームページは消えますか？

消えません。
失敗したステップより前に送ったファイルは、サーバーに届いています。
届かなかったファイルは、前の状態のままです。
そのため、途中で止まると、新しいファイルと古いファイルが混ざることはあります。
直して上げ直すか、Re-run で同じコミットを上げ直すと、揃います（もう一度動かす）。

間違えてマージして、公開してしまった時は？

マージしたプルリクエストの画面にある「Revert」のボタンで、その変更を打ち消すプルリクエストを作れます。
それをマージすると、GitHub Actions がまた動き、前の状態のファイルが自動で上がります。
手で FTP で戻すと、リポジトリとサーバーの中身が食い違うので、この形で戻す方が確実です。

まとめ

ことらは、プルリクエストの画面を、もう一度開いた。
変わっているのは、お知らせの1行だけだった。
テストサーバーで、その1行が出ているのも確かめた。
マージのボタンを押す。
Actions の画面に、黄色の丸が出て、1分ほどで緑のチェックに変わった。

ことらホームページ、変わりました。
マージしたら、GitHub がファイルを取り出して、FTP で送ってくれたんですね。
私のパソコンでも、サーバーでもなく、GitHub の中で。

風虎先生その通りです。
これからは、マージのボタンが公開のボタンです。
押す前にプルリクエストとテストサーバーで確かめる、押した後は Actions の画面で緑を確かめる。
この2つを覚えておけば、大丈夫ですよ。

GitHub Actions は、リポジトリで起きたことをきっかけに、決めた作業を GitHub の中で自動で行う仕組みです。
この記事に出てきた言葉は、次の通りです。

言葉	意味
ワークフロー（workflow）	「○○が起きたら、△△をする」を書いたファイル。 .github/workflows/ に置く
きっかけ（on）	○○の部分。プッシュ／プルリクエスト／画面のボタン／決まった時刻
ジョブ（job）	1台のランナーで行う、ひとまとまりの作業
ステップ（step）	ジョブの中の1つ1つの手順。上から順に動き、失敗するとそこで止まる
ランナー（runner）	ジョブを動かす、使い捨てのパソコン。 GitHub が用意する
アクション（action）	他の人が作った手順の部品。作者と版を確かめて使う
Secrets	パスワードや鍵の置き場所。ワークフローからは名前で読む