GitHub Actionsの使い方：自動で動かす仕組みと無料枠

公開 2026年11月7日更新 2026年11月8日書いた人大林諒

GitHub Actionsは、リポジトリに変更を送ったときや決めた時刻に、GitHubのサーバーで処理を動かす機能です。制作会社から「Actionsで自動化してあります」と言われて、何が動いているのか分からないまま請求や失敗メールだけ届く、という場面でよく出てきます。

ここでは小さな料理教室のリポジトリを例に、設定ファイルの読み方、失敗したときの画面の見方、無料枠、鍵の置き方まで順に見ます。読み終わると、最小の設定を自分で置けて、外注先の説明も分かるようになります。

この記事の内容

先に答えると
GitHub Actionsとは何か
出てくる言葉は6つ
最小の例：料金表のチェック
実行結果の画面の見方
無料枠と、超えたらどうなるか
鍵はファイルに書かず、Secretsに入れる
小さな会社での使いどころ
他人のActionを使うときの注意
できないことと、その代わり
よく詰まるところ
次に読む

先に答えると

GitHub Actionsは「いつ・どこで・何を動かすか」を書いたファイルをリポジトリに置くと、GitHubがそのとおりに動かしてくれる機能です。Freeプランでも使えて、ほとんどの小さな会社は無料枠の中に収まります。ただし常時動くサーバーの代わりではなく、指定の時刻ちょうどに動く保証もありません。

設定ファイルは .github/workflows/ に置くYAMLファイル（字下げで構造を表す設定用の書式）です
無料枠はFreeで月2,000分、ストレージ500MB。公開リポジトリは標準のランナーなら無料です（2026年11月時点）
枠を使い切ると、支払い方法を登録していない場合はそこで止まり、勝手に請求は発生しません
パスワードやAPIキーはファイルに書かず、Secretsに登録して呼び出します
他人が作ったActionは便利な反面、自分のリポジトリの中身に触れます。バージョンの固定と権限の絞り込みをセットで行います

GitHub Actionsとは何か

Gitで保存した変更をGitHubへ送る操作をpush（プッシュ）と呼びます。保管場所であるリポジトリに変更が届くと、普段はそれで終わりです。Actionsを設定しておくと、この届いたタイミングなどをきっかけに、GitHubが用意したサーバーで決めておいた処理を動かします。手元のパソコンは閉じていて構いません。

きっかけになるのはpushだけではありません。決めた時刻、画面のボタン、Issue（課題を書き留める機能）の作成などでも動きます。

Actionsの説明によく出るCI/CDは、公式でもこの機能の分類として使われている言葉です。CI（継続的インテグレーション）は変更のたびに自動で確かめること、CD（継続的デリバリー）は確かめたものを自動で公開先へ届けることを指します。サンプル料理教室なら、menu.html を直すたびに料金が消えていないか確かめるのがCI、ホームページへ自動で反映するのがCDです。

出てくる言葉は6つ

言葉	意味	サンプル料理教室の例
workflow（ワークフロー）	自動処理の全体。YAMLファイル1つが1本	料金表のチェック
event（イベント）	動き出すきっかけ	`menu.html` のpush、毎朝8時30分
job（ジョブ）	同じサーバーで順に動くひとまとまり	料金表を確かめる
step（ステップ）	jobの中の1工程。コマンドかActionのどちらか	ファイルを取ってくる、中身を調べる
runner（ランナー）	処理を動かすサーバー	GitHubが用意するUbuntu
action（アクション）	再利用できる部品。他人が作ったものも使える	リポジトリの中身を取ってくる `actions/checkout`

GitHubが用意するランナーにはUbuntu Linux、Windows、macOSがあり、実行のたびに新しい仮想マシンが立ち上がります。前回の実行で作ったファイルは残っていないので、毎回リポジトリの取得から始めます。

最小の例：料金表のチェック

menu.html に「円」の文字が1つもなければ失敗にする、小さな確認を置いてみます。料金表を直すときに誤って中身を消してしまった事故を拾う程度のものです。ファイルは .github/workflows/check-menu.yml として保存します。

name: Check menu
on:
  push:
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the code
        uses: actions/checkout@v6
      - name: Check that menu.html has prices
        run: grep -q "円" menu.html

行ごとに読む

行	意味
`name: Check menu`	画面に出るワークフローの名前
`on:` と `push:`	pushされたら動く
`permissions:` と `contents: read`	このワークフローはリポジトリの中身を読むだけ
`jobs:` と `check:`	ジョブの一覧と、`check` という名前のジョブ
`runs-on: ubuntu-latest`	Ubuntuのランナーで動かす
`steps:`	ここから工程を順に書く
`uses: actions/checkout@v6`	公式のActionでリポジトリの中身を取ってくる
`run: grep -q "円" menu.html`	`menu.html` の中に「円」があるか調べる

最後の grep -q は、文字が見つかれば終了コード0、なければ1を返します。終了コードは処理の結果を表す数字で、Actionsは0を成功、それ以外を失敗と扱います。手元で試すと次のようになります。

$ grep -q "円" menu.html
$ echo $?
0

menu.html から「円」を消して同じことをすると、結果は変わります。

$ grep -q "円" menu.html
$ echo $?
1

置き方

画面だけで置けます。

GitHubでリポジトリ website を開きます。
「Add file」を押し、「Create new file」を選びます。
ファイル名の欄に .github/workflows/check-menu.yml と入れます。
上のYAMLを貼り付けます。
「Commit changes」を押します。
開いた「Propose changes」の画面で「Commit changes」を押します。

このコミット（変更の保存）自体がpushと同じきっかけになるので、置いた直後に1回動きます。Gitのコマンドで置いた場合は、送る前に次のように2つのファイルが入っていることを見ておきます。

$ git log --oneline --stat
a738f0e 料金表のチェックを追加
 .github/workflows/check-menu.yml | 13 +++++++++++++
 menu.html                        |  2 ++
 2 files changed, 15 insertions(+)

menu.html が変わったときだけ動かしたいときは、push: の下に paths: を足して対象のファイルを書きます。

on:
  push:
    paths:
      - 'menu.html'

実行結果の画面の見方

結果はリポジトリの「Actions」タブに集まります。

リポジトリ名の下の「Actions」を押します。
左の一覧でワークフロー（ここでは Check menu）を押します。
実行の一覧から、見たい実行を押します。
左の「Jobs」の下で、ジョブ（ここでは check）を押します。
ステップを開くとログ（処理の記録）が読めます。

失敗したときは、失敗したステップが最初から開いた状態で表示されます。読む場所は、赤い印のステップの一番下の数行です。右上の「Search logs」で検索もできますが、対象は開いているステップだけです。

直してもう一度試すなら、新しくpushするか、実行の画面の右上にある「Re-run jobs」から「Re-run failed jobs」を選び、「Re-run jobs」を押します。やり直せるのは最初の実行から30日までです。

実際に運用していると、失敗の多くは処理そのものではなく、YAMLの字下げのずれ、ファイル名の違い、Secretsの登録漏れのどれかです。ログの最後の数行を読めば、たいていどれか分かります。読めないときは、そのままログを外注先に渡せば話が早く進みます。

無料枠と、超えたらどうなるか

数字はすべて2026年11月時点です。

プラン	実行時間（月）	料金（1ユーザー月）
Free	2,000分	$0
Team	3,000分	$4
Enterprise	50,000分	$21

ストレージはFreeで500MBです。公開リポジトリは標準のランナーなら無料です。自分のサーバーをランナーにする場合（セルフホスト）も無料で、枠も減りません。

料金ページは分で書いていますが、課金の説明のページでは同じ枠が金額で書かれています。Freeは$12分で、標準のLinux（2コア）は1分$0.006です。割ると2,000分になります。Windowsは1分$0.010、macOS（3または4コア）は1分$0.062なので、同じ$12でもmacOSでは減りが早くなります。ランナーをUbuntuにしておけば、この差は考えなくて済みます。

目安として、1回2分の処理を毎日3回動かしても月に約180分です。料金表のチェックや毎朝のメール送信くらいなら、枠を気にする場面はまずありません。

超えたときの扱いは、支払い方法の登録の有無で変わります。登録がなければ、枠を使い切った時点で使えなくなります。登録がある場合は、予算と、90%・100%に達したときのメール通知を使えます。

消費を見る場所は次のとおりです。

見たいもの	場所
個人アカウント全体	github.com/settings/billing の「Usage」または「Metered usage」
Organization全体	Organizationの設定の「Access」の下の「Billing & Licensing」→「Usage」または「Metered usage」
1回の実行の分数	実行の画面の左「Run details」の下の「Usage」

1回の実行の課金対象の分数が出るのは、非公開リポジトリでGitHubのランナーを使ったジョブだけです。

鍵はファイルに書かず、Secretsに入れる

reservation-mail のスクリプトでメールを送るには、メールサーバーのパスワードが要ります。これをファイルに書いて .env ごとコミットすると、履歴に残り続けます。Actionsには、値を暗号化して預けるSecretsという置き場があります。

リポジトリの「Settings」を開きます。
左の「Security」の欄で「Secrets and variables」を押し、「Actions」を押します。
「Secrets」タブで「New repository secret」を押します。
「Name」に SMTP_PASSWORD と入れます。
「Secret」に値を入れます。
「Add secret」を押します。

名前に使えるのは英数字と _ だけで、GITHUB_ で始まるものと数字で始まるものは使えません。登録した値は画面で読み返せないので、控えは1Passwordのようなパスワード管理ツールに置いておきます。

ワークフローからは ${{ secrets.名前 }} で呼び出し、環境変数（プログラムに渡す名前付きの値）として渡します。毎朝8時30分にリマインドメールを送る例です。

name: Send reminder mail
on:
  schedule:
    - cron: '30 8 * * *'
      timezone: "Asia/Tokyo"
  workflow_dispatch:
permissions:
  contents: read
jobs:
  send:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the code
        uses: actions/checkout@v6
      - name: Send mail
        run: python3 send_mail.py
        env:
          SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}

cron は時刻を「分時日月曜日」の順に書く書式で、* は「毎」の意味です。timezone を書かないとUTC（日本より9時間遅い世界標準時）になります。workflow_dispatch を入れておくと、画面の「Run workflow」ボタンから手動で試せるようになります。

Secretsで押さえるのは次の3つです。

ログに値が出ると自動で伏せられますが、値を加工して出力すると伏せられないことがあり、公式も保証はしていません。値をログに出す処理を書かないのが基本です
リポジトリに書き込み権限を持つ人は、登録済みのSecretsを使ったワークフローを動かせるので、実質的に値を読めます。外注エンジニアBに書き込み権限を渡すなら、鍵も見られる前提で考えます。契約が終わったら権限を外し、鍵も作り直します
フォーク（他人が作ったコピー）からの実行には、Secretsは渡されません

小さな会社での使いどころ

Actionsが合うのは、コードと一緒に管理したい処理です。

場面	例	向き
変更のたびの確認	`menu.html` のチェック、リンク切れの確認	向いている
サイトの自動公開	`main` に入ったらホームページへ反映	向いている
定時の処理	毎朝 `send_mail.py` を動かす	数分の遅れが許せるなら向いている
別のサービス同士のつなぎ	フォームの回答を表計算へ送る	n8nなどの自動化ツールのほうが楽
画面で流れを組みたい処理	担当者が自分で直す通知の仕組み	n8nなどの自動化ツールのほうが楽

リポジトリが無い処理のためにわざわざActionsを使う必要はありません。すでにn8nなどで動いている自動処理を移す理由もあまりなく、Gitで管理しているコードに関わるものから使うのが自然です。

会社の処理を公開リポジトリで動かして枠を節約する発想も勧めません。無料になっても、スクリプトの中身が誰でも読める状態になります。

他人のActionを使うときの注意

uses: の行で呼び出すActionは、他人が書いたプログラムです。ワークフローの中で動くので、リポジトリの中身や渡したSecretsに触れられます。公式の注意点を、小さな会社で実行しやすい順に並べます。

やること	理由
使うActionを減らす	数行のコマンドで済むなら部品は要らない
提供元を確かめる	`actions/` はGitHub公式。Marketplaceの「Verified creator」は提供元の確認済みを示すが、中身の保証ではない
中身を読む、読める人に見てもらう	リポジトリの中身やSecretsを想定どおり扱っているか確かめる
バージョンをコミットのハッシュで固定する	`@v6` のようなタグは後から動かせる
`permissions:` で権限を絞る	乗っ取られたときの被害を小さくする

タグでの固定は、作者を信頼できるときに限ります。公式も、提供元のリポジトリが乗っ取られるとタグを動かされるおそれがあると書いています。ハッシュ（コミットごとの40桁の識別子）で固定するときは次の形にし、後ろに元のバージョンを書き添えます。ハッシュは提供元のリポジトリのタグの画面で確かめ、フォーク先のものを使わないようにします。

- uses: actions/checkout@（40桁のコミットハッシュ）  # v6

固定すると更新が止まるので、Dependabot（依存の更新を提案する機能）と組み合わせることになります。公式はさらに強い手段としてワークフローのlockfile（依存先を記録するファイル）も挙げています。外注先がいるなら、まずは「Actionはハッシュで固定していますか」「権限は絞っていますか」と聞けば足ります。

権限は、ワークフローの上のほうに permissions: を書いて読み取りだけにし、必要なジョブだけ増やします。書いた項目以外は none になるので、足りない権限があれば失敗して気づけます。

できないことと、その代わり

できないこと	理由	代わり
指定の時刻ちょうどに必ず動かす	混雑時は遅れ、混み具合によっては実行が落ちることもある	時間厳守の処理はサーバーのcronや専用のサービス
動かし続ける	GitHubのランナーでは1ジョブ6時間まで	サーバーを別に借りる
5分より短い間隔で定期実行	最短は5分ごと	同上
画面で流れを組む	設定はYAMLで書く	n8nなどの自動化ツール
前回の実行のファイルを残す	毎回新しいマシンで動く	外部の保存先、または成果物の保管機能

定時の処理で予約確認のような大事なメールを送るなら、遅れと取りこぼしを前提に作ります。送信済みの記録を残して次の実行で拾い直す、失敗したら通知が届くようにするといった備えです。GitHubが混みやすい毎時0分は避け、8時30分のように少しずらして設定します。

よく詰まるところ

症状	原因	直し方
「Actions」タブが出ない	リポジトリでActionsが無効になっている	「Settings」→「Actions」→「General」の「Actions permissions」を確かめる。Organizationの方針で止まっていれば管理者に頼む
ファイルを置いたのに動かない	置き場所か拡張子の間違い、`on:` の条件に合っていない	`.github/workflows/` の直下か確かめる。`paths:` を付けていれば対象のファイルか見る
定時の処理が動かない	既定のブランチ（枝）に入っていない	`schedule` は既定のブランチでだけ動く。`add-summer-class` のような枝のままなら `main` に合流させる
定時の処理が遅れる	GitHubの混雑	毎時0分を避ける。時間厳守の処理はActionsから外す
しばらくして定時の処理が止まった	公開リポジトリで60日間動きがなく自動で無効になった	「Actions」の画面から有効に戻す
Secretsを使う処理が失敗する	名前の違いや未登録。未登録の値は空になる	「Secrets and variables」で名前を見比べる
急に実行されなくなった	無料枠を使い切った	「Metered usage」で確かめ、回数を減らすか支払い方法を登録する
`@v6` が見つからないと出る	Actionの名前かバージョンの書き間違い	Actionのリポジトリでタグを確かめる
`git push` が `refusing to allow an OAuth App to create or update workflow` で断られる	`gh auth login` のトークンは既定で `repo`、`read:org`、`gist` の権限だけで、`.github/workflows/` の中を変えるのに要る `workflow` の権限が無い	`gh auth refresh -s workflow` を打ってブラウザで承認する。権限を増やしたくないなら、GitHubの画面からファイルを置く

コマンドで見たいときは、GitHub CLI（gh）に gh run list や gh run view、手動実行の gh workflow run があります。画面だけで足りるなら入れなくて構いません。

次に読む

ホームページを公開する先については、GitHub Pagesの使い方：無料でサイトを公開する手順と注意点に続きます。プランごとの違いは GitHubの料金：Free・Team・Enterpriseと無料でできる範囲に、コマンドで実行結果を見るなら GitHub CLIの使い方：ghでできることと、gitとの違いにまとめています。鍵をファイルに書いて送ってしまったときは APIキーやパスワードをGitHubにpushしてしまったときの対応を見てください。

あわせて読む

画面に出てくる言葉の意味はGit用語集で引けます。