GitHub Actionsとは？できること・最初の使い方を初心者向けにわかりやすく解説

GitHub Actions は、リポジトリに YAML ファイルを1つ置くだけで、push や Pull Request のたびにテスト・ビルド・デプロイを GitHub のマシンで自動実行できる機能です。パブリックリポジトリなら標準のマシンは無料で、プライベートでも Free プランで月 2,000 分まで追加料金なしで使えます。

この記事では定義の先として、そのまま使える最小の設定と実務向けのテスト設定、失敗したときのログの読み方、無料枠の数字、そして初心者が見落としやすい権限と Secrets の扱いを整理します。時点で変わる数字やバージョンは、2026年10月時点の GitHub 公式ドキュメント（課金・ランナー・制限値・セキュリティガイド）と各アクションのリリースページで確認しました。
AI にコードを書かせたあとに自動テストをどう回すかまでつなげて考えたいなら、AIにコードを書かせるときの注意点は？そのまま使わないための確認ポイントを解説 もあわせて読むとつながりやすいです。

GitHub Actionsとは何か

GitHub Actions は、GitHub 上でソフトウェア開発の作業を自動化する仕組みです。
公式では、ワークフローの自動化、カスタマイズ、実行に使える CI/CD プラットフォームとして説明されています。

初心者向けに言い換えると、コードを push したら自動でテストを回す タグを切ったら自動でビルドする main へマージされたらデプロイする といった作業を、GitHub 上で自動化するための仕組みです。 このとき混ざりやすい デプロイ と リリース の違いは、リリースとデプロイの違いは？ で整理しています。コードを置くことと、ユーザーに出すことは同じとは限りません。

何ができるのか

GitHub Actions でよくやることは、だいたい次のあたりです。

つまり、コードを書いたあとに人が毎回手でやっていること を自動化しやすいです。
特に最初は、CI/CD のうち CI 寄り、つまりテストや検証の自動化から入ると分かりやすいです。

まず押さえたい基本用語

初心者が最初につまずきやすいので、ここだけ先に整理します。

workflow

workflow は、自動化の手順を書いた設定ファイルです。 .github/workflows/ 配下に YAML 形式で置きます。

job / step

1つの workflow の中には job があり、その中に step を並べます。 雑に言うと、job がまとまり、step が1個ずつの作業です。

runner

runner は、workflow を実際に実行するマシンです。 GitHub が用意する GitHub-hosted runner を使うこともできますし、自分で用意した self-hosted runner を使うこともできます。

event

workflow は何かのイベントをきっかけに動きます。 よくあるのは push、pull_request、workflow_dispatch です。

最初の使い方はどうするのか

初心者が最初にやるなら、push したら簡単な処理が動く ところから始めるのがいちばん分かりやすいです。3ステップで動かせます。

最小の workflow はこれくらいで十分です。

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo "GitHub Actions is working"

この設定だと、main への push と pull request をきっかけに workflow が動きます。 runs-on: ubuntu-latest は、GitHub が用意する Ubuntu の runner 上で動かす指定です。2026年10月時点の ubuntu-latest は Ubuntu 24.04 で、latest の指す先は新しい OS が安定すると切り替わります。切り替わりで壊れたくないなら ubuntu-24.04 のように版を固定します。

actions/checkout@v7 の @v7 は、使うアクションのバージョンです。古い記事のコピーで @v2 や @v3 が残っていると、実行時の Node.js が古いという警告が出たり動かなくなったりします。最新の番号は各アクションのリリースページで確認してください。

次にやるなら何を自動化するとよいか

最初の echo が動いたら、次は実務でも意味のあるものに寄せるとよいです。

テストを回す

いちばん自然なのは、テストの自動化です。
たとえば Node.js や Python や PHP のプロジェクトなら、依存を入れてテストコマンドを実行します。

実務で使うなら、最小例に次の4点を足した形が扱いやすいです。

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read            # このworkflowはリポジトリを読むだけ

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true  # 同じブランチの古い実行は止める

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15     # 既定は360分。固まったときに課金時間を食わせない
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test

こうしておくと、push のたびに テストが通るか を GitHub 上で確認できます。PHP や Python でも形は同じで、setup-php 相当や actions/setup-python に置き換えて、依存インストールとテストのコマンドを書き換えるだけです。

失敗したらログのどこを見るか

リポジトリの Actions タブで失敗した実行を開き、ジョブを選ぶと、失敗した step が自動で展開されます。見るのは赤くなった step の最後の数行です。

Run npm test
> sample-app@1.0.0 test
> vitest run

 FAIL  src/price.test.ts > calcTotal > 税込み金額を返す
AssertionError: expected 1099 to be 1100
Error: Process completed with exit code 1.

最後の Process completed with exit code 1. は「コマンドが失敗した」という結果だけなので、原因はその上の行にあります。ログが長いときは右上の Search logs で Error や FAIL を検索します。GitHub CLI を入れているなら、ターミナルから失敗した step のログだけを出せます。

gh run list --limit 5          # 直近の実行と結果を一覧
gh run view RUN_ID --log-failed     # RUN_IDは一覧の数字。失敗した step のログだけ表示

手元では通るのに Actions だけ落ちるときは、後述の「runner は自分のPCではない」を疑います。

lint や型チェックを回す

テストだけでなく、lint や型チェックも相性がよいです。
人がレビューする前に、最低限の崩れを自動で落とす という意味でかなり効きます。

手動実行も使う

workflow_dispatch を入れると、GitHub 画面から手動実行もできます。
毎回自動で動かしたくない処理は、ここから始めるのもありです。

何が便利なのか

GitHub Actions が便利なのは、単に自動化できるからだけではありません。

初心者が最初にハマりやすいところ

runner は自分のPCではない

ここはかなり大事です。
手元で動くのに、Actions では動かない ことは普通にあります。

Secrets をそのままログへ出さない

API キーやパスワードのような値は、Secrets として GitHub 側に持たせるのが基本です。
workflow ファイルへ直書きしない方が安全です。

もう一つ、初心者が驚きやすいのがフォークからの Pull Request では Secrets が渡されないことです。公式ドキュメントのとおり、フォーク元からの Pull Request で動く workflow には GITHUB_TOKEN 以外の Secrets が渡りません。「外部の人の PR だけ API キーが空で落ちる」のはこれが原因です。これを避けようとして pull_request_target に変え、PR のコードを checkout して実行するのは危険です。この設定は Secrets と書き込み権限を持ったまま、外部の人が書いたコードを動かすことになるからです。

GITHUB_TOKEN の権限を広げすぎない

GitHub Actions では、ジョブごとに GITHUB_TOKEN が自動で発行されます。2023年2月以降に作ったリポジトリや組織では、このトークンの既定の権限は「読み取りのみ」です。それより前からあるリポジトリは「読み書き」のままのことがあるので、Settings の Actions → General にある Workflow permissions を一度確認しておくと安心です。

workflow の中で権限を書いておけば、リポジトリの設定に関係なくその範囲に絞れます。PR にコメントを書く処理だけ書き込みを足す、という形にします。

permissions:
  contents: read
  pull-requests: write   # PRへのコメントが必要なジョブだけ

外部の Action はバージョン番号よりコミットで固定する

uses: 作者/アクション名@v7 の v7 はタグで、作者側で付け替えられます。2025年3月には、広く使われていた tj-actions/changed-files の既存のタグが攻撃者に書き換えられ、そのタグを指定していた workflow で Secrets がログから読める状態になりました（CVE-2025-30066）。GitHub 公式のセキュリティガイドは、外部の Action をコミットの SHA（40桁の英数字）で固定することを勧めています。

- uses: some-org/some-action@1234567890abcdef1234567890abcdef12345678  # v2.1.0

最初から全部を SHA で固定しなくても、少なくとも「GitHub 公式（actions/）以外で、Secrets を渡す Action」から固定すると効果が大きいです。固定したあとの更新は Dependabot に任せられます。サプライチェーン攻撃の全体像は Mini Shai-Hulud Worm とは？ でも扱っています。

無料枠と料金の目安

GitHub Actions の課金は「GitHub が用意したマシンを何分使ったか」で決まります。2026年10月時点の公式の課金ページでは次のとおりです。

目安として、1回3分のテストを1日20回 push すると月に約1,200分です（3分×20回×20営業日）。Free の 2,000 分に収まりますが、OS を3種類にしたり macOS を混ぜたりすると、すぐに超えます。料金は改定されることがあるので、使う前に課金ページで最新の数字を確認してください。

実務でどう使い分けるか

実務では、最初から全部を自動化するより、順番をつける方が失敗しにくいです。3段階で考えると、便利だけど危ない 部分を後ろに回しやすくなります。

本番デプロイまで進めるときは、切り戻しやすい出し方（ブルーグリーンデプロイ など）を先に決めておくと、自動化の失敗が大きな障害になりにくくなります。デプロイの所要時間が問題になった構成の例は GitHub Actionsのデプロイが遅い？Next.jsをVPS直ビルドにした構成を整理 にまとめています。

よくある誤解

もう一つ多いのは、最初から本番デプロイまでやるべき と思ってしまうことです。 初心者や小規模チームでは、まずテストと lint から始めた方がかなり安全です。

GitHub Actions に関するよくある質問

無料枠を超えそうなときはどうする？

まず、使用分数の多い workflow を Settings の Billing で確認します。効きやすいのは、concurrency で古い実行を止める、paths で関係ないファイルの変更では動かさない、依存のキャッシュを効かせる、macOS や Windows のジョブを本当に必要なものに絞る、の4つです。それでも足りなければ、プランの変更か self-hosted runner を検討します。数字は本文の「無料枠と料金の目安」を参照してください。

GitHub-hosted runner と self-hosted runner、どう違う？

GitHub-hosted は 毎回まっさらな環境 で実行され、メンテ不要だが時間課金。self-hosted は 自前のマシン で実行し、メンテは必要だが速度・キャッシュ・ネットワーク内部アクセスで有利。大規模 CI、長時間ビルド、社内ネットワークへの接続が必要なら self-hosted も検討します。

Secrets と Variables の使い分けは？

Secrets はログで伏せ字になる機密値（API キー、トークン、パスワード）、Variables は伏せる必要のない設定値（環境名、URL、ブランチ名など）です。Secrets は登録した値そのものしか伏せられないので、加工した値をログに出さないようにします。

GITHUB_TOKEN は何ができる？

ジョブごとに自動で発行され、ジョブが終わると失効するトークンです。権限の範囲で、リポジトリの読み書き、PR へのコメント、issue の操作などができます。新しいリポジトリでは既定が読み取りのみなので、書き込みが必要な処理だけ permissions: で足します。

依存キャッシュで CI を速くするには？

Node.js なら actions/setup-node の cache: npm、Python なら actions/setup-python の cache: pip を使うのが手軽です。ビルド成果物など任意のフォルダを保存したいときは actions/cache（2026年10月時点の最新は v6）を使います。キャッシュはリポジトリごとに 10 GB までで、キーを lock ファイルのハッシュにしないと、依存が変わったのに古いキャッシュを使い続けることがあります。

マトリックスビルド（複数バージョン同時テスト）はいつ使う？

ライブラリ開発で複数 Python / Node.js バージョンに対応したい場合、複数 OS（Ubuntu / macOS / Windows）でテストしたい場合に使います。アプリ開発で本番が単一 OS / 単一バージョンなら、マトリックスを使うと CI 時間が伸びるだけなので不要です。

ローカルで workflow をテストできる？

act というツールで GitHub Actions の workflow をローカル実行できます（Docker ベース）。本番と完全に同じ挙動にはなりませんが、構文チェックや簡単な動作確認には便利。本格的なデバッグは GitHub 上で実際に push して確認するのが確実です。

外部のアクションを、タグ（@v4 など）で指定したままで安全ですか？

タグやブランチは付け替えられるため、アクションの作者が侵害されると、確かめていないコードが自分のワークフローで動くことがあります（2025年3月の tj-actions/changed-files の事例）。2026年10月28日にロックファイル（actions.lock）が一般提供になり、タグ表記のまま、確かめたコミットだけを実行できるようになりました。従来のコミット SHA での固定との違いと導入手順は GitHub Actions のロックファイルで解説しています。

まとめ

GitHub Actions は、GitHub 上でテスト、ビルド、デプロイなどを自動化できる仕組みです。
最初は .github/workflows/ に YAML で workflow を置き、runner 上で push や pull request をきっかけにテストを回すところから始めると分かりやすいです。

便利さはかなり大きいですが、GITHUB_TOKEN や Secrets の扱い、権限の広げすぎ、本番デプロイの自動化は慎重に見た方が安全です。
迷ったら、まずは push でテストを回す ところから始めるのがいちばん入りやすいです。

公開リポジトリでフォークからの Pull Request に反応する pull_request_target は、2026年12月2日から既定でブロックされます。使っている場合の確認はpull_request_target が12月2日に既定ブロックを見てください。

参考情報

• GitHub Docs: GitHub Actions の理解
• GitHub Docs: GitHub Actions のクイックスタート
• GitHub Docs: GitHub Actions の workflow 構文
• GitHub Docs: GitHub-hosted runners について
• GitHub Docs: 自動トークン認証
• GitHub Docs: GitHub Actions でシークレットを使う
• GitHub Docs: GitHub Actions billing
• GitHub Docs: Actions limits
• GitHub Docs: Secure use reference
• NVD: CVE-2025-30066（tj-actions/changed-files）
• GitHub Changelog: Updating the default GITHUB_TOKEN permissions to read-only（2023年2月）
• GitHub Docs: Using workflow run logs
• GitHub: actions/runner-images（ランナーのイメージとラベル）
• GitHub: actions/checkout のリリース / actions/setup-node のリリース