先に要点
- GitHub Actions は、GitHub 上でテスト、ビルド、デプロイなどを自動化できる仕組みです。
- 最初に覚えたいのは、workflow ファイルを `.github/workflows/` に置くこと、処理は runner 上で動くことです。
- 初心者はまず `push` や `pull_request` をきっかけにテストを回すところから始めると入りやすいです。
- 便利ですが、GITHUB_TOKEN の権限や Secrets の扱いを雑にしないこともかなり大事です。
GitHub を使って開発していると、GitHub Actions という言葉をかなり早い段階で見かけます。
ただ、最初は CI/CD の何からしい くらいの理解で止まりやすく、実際に何ができるのか どう始めればいいのか が分かりにくいことも多いです。
この記事では、2026年4月4日時点で GitHub 公式ドキュメントの GitHub Actions の理解、quickstart、workflow syntax、GitHub-hosted runners、automatic token authentication を確認しながら、GitHub Actions の基本、できること、最初の使い方、初心者が最初にハマりやすい点を整理します。
AI にコードを書かせたあとに自動テストをどう回すかまでつなげて考えたいなら、AIにコードを書かせるときの注意点は？そのまま使わないための確認ポイントを解説 もあわせて読むとつながりやすいです。
GitHub Actionsとは何か
GitHub Actions は、GitHub 上でソフトウェア開発の作業を自動化する仕組みです。
公式では、ワークフローの自動化、カスタマイズ、実行に使える CI/CD プラットフォームとして説明されています。
初心者向けに言い換えると、コードを push したら自動でテストを回す タグを切ったら自動でビルドする main へマージされたらデプロイする といった作業を、GitHub 上で自動化するための仕組みです。
このとき混ざりやすい デプロイ と リリース の違いは、リリースとデプロイの違いは？ で整理しています。コードを置くことと、ユーザーに出すことは同じとは限りません。
何ができるのか
GitHub Actions でよくやることは、だいたい次のあたりです。
つまり、コードを書いたあとに人が毎回手でやっていること を自動化しやすいです。
特に最初は、CI/CD のうち CI 寄り、つまりテストや検証の自動化から入ると分かりやすいです。
まず押さえたい基本用語
初心者が最初につまずきやすいので、ここだけ先に整理します。
| 用語 | 役割 | ざっくり言うと |
|---|---|---|
| workflow | 自動化の手順を書いた設定ファイル | .github/workflows/ に YAML で置く |
| job / step | 処理のまとまりと個別の作業 | job が大きな単位、step が1つずつの作業 |
| runner | workflow を実行するマシン | GitHub提供かself-hostedかを選べる |
| event | workflow を動かすきっかけ | push、pull_request、手動実行など |
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@v5
- run: echo "GitHub Actions is working"
この設定だと、main への push と pull request をきっかけに workflow が動きます。
runs-on: ubuntu-latest は、GitHub が用意する Ubuntu の runner 上で動かす指定です。
次にやるなら何を自動化するとよいか
最初の echo が動いたら、次は実務でも意味のあるものに寄せるとよいです。
テストを回す
いちばん自然なのは、テストの自動化です。
たとえば Node.js や Python や PHP のプロジェクトなら、依存を入れてテストコマンドを実行します。
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: npm ci
- run: npm test
こうしておくと、push のたびに テストが通るか を GitHub 上で確認できます。
lint や型チェックを回す
テストだけでなく、lint や型チェックも相性がよいです。
人がレビューする前に、最低限の崩れを自動で落とす という意味でかなり効きます。
手動実行も使う
workflow_dispatch を入れると、GitHub 画面から手動実行もできます。
毎回自動で動かしたくない処理は、ここから始めるのもありです。
何が便利なのか
GitHub Actions が便利なのは、単に自動化できるからだけではありません。
GitHub の流れにそのまま乗せやすい
push、pull request、release、issue など、GitHub 上のイベントにそのまま反応できます。
そのため、別ツールへ飛ばなくても開発の流れに自動処理を組み込みやすいです。
チームで同じチェックを回しやすい
手元の環境だけでテストしていると、自分のマシンでは通る 問題が起きやすいです。
GitHub Actions で共通の workflow を持つと、同じ手順を共通で回しやすくなります。
小さく始めて広げやすい
最初はテストだけ、次に lint、次にビルド、最後にデプロイ、というように段階で育てやすいです。
この 小さく始められる のはかなり大きいです。
初心者が最初にハマりやすいところ
runner は自分のPCではない
ここはかなり大事です。
手元で動くのに、Actions では動かない ことは普通にあります。
理由は、GitHub-hosted runner は 毎回まっさらな実行環境 に近いからです。
そのため、依存インストール、環境変数、必要ファイルの取得を workflow 側でちゃんと書く必要があります。
Secrets をそのままログへ出さない
API キーやパスワードのような値は、Secrets として GitHub 側に持たせるのが基本です。
workflow ファイルへ直書きしない方が安全です。
ただし、Secrets に入れたから絶対安全というわけではなく、echo でそのまま出したり、外部 Action へ雑に渡したりすると危ないです。
GITHUB_TOKEN の権限を広げすぎない
GitHub Actions では、リポジトリに対して GITHUB_TOKEN が自動で使えることがあります。
便利ですが、必要以上の権限を前提にしない方が安全です。
最初は 何をさせる workflow なのか を絞って、必要な権限だけで動くかを見る方が事故が少ないです。
実務でどう使い分けるか
実務では、最初から全部を自動化するより、順番をつける方が失敗しにくいです。3段階で考えると、便利だけど危ない 部分を後ろに回しやすくなります。
1. まず入れたい（低リスク）
push / pull request でのテスト・lint・型チェック。失敗してもコードベースは壊れないので最初に入れる。チームの認識合わせにも有効。
2. 次に入れる（中リスク）
ビルド・成果物アップロード・staging へのデプロイ。本番には影響しないが運用整備が必要。Artifacts のサイズ管理、staging 環境のリセット手順を決めてから。
3. 慎重に入れる（高リスク）
production デプロイ・自動マージ・強い権限の書き込み処理。事故が本番に直接届くので、approve フロー、ロールバック手順、監査ログを整備してから。
よくある誤解
GitHub Actions を入れたら、自動で CI/CD が完成するわけではありません。実際には、何をきっかけに、どの runner で、どの権限で、どこまで自動化するかを自分たちで決める必要があります。
もう一つ多いのは、最初から本番デプロイまでやるべき と思ってしまうことです。
初心者や小規模チームでは、まずテストと lint から始めた方がかなり安全です。
GitHub Actions に関するよくある質問
無料枠はどれくらい使える？
パブリックリポジトリは無制限、プライベートリポジトリは月 2,000 分（Free プラン）から。Pro / Team / Enterprise でさらに増えます。最新の正確な無料枠は GitHub 公式の Billing ページで確認してください。CI 実行時間が増えてきたら、self-hosted runner も選択肢に入ります。
GitHub-hosted runner と self-hosted runner、どう違う？
GitHub-hosted は 毎回まっさらな環境 で実行され、メンテ不要だが時間課金。self-hosted は 自前のマシン で実行し、メンテは必要だが速度・キャッシュ・ネットワーク内部アクセスで有利。大規模 CI、長時間ビルド、社内ネットワークへの接続が必要なら self-hosted も検討します。
Secrets と Variables の使い分けは？
Secrets はログにマスクされる機密値（API キー、トークン、パスワード）、Variables は通常の設定値（環境名、URL、ブランチ名など）。Secrets の値は echo で出してもログ上ではマスクされますが、外部 Action へ雑に渡すと漏れる可能性があるので注意。
GITHUB_TOKEN は何ができる？
リポジトリ単位の自動生成トークンで、リポジトリへの read/write、PR コメント、issue 操作などができます。デフォルト権限は組織設定で制御でき、workflow 単位で permissions: を絞るのが安全。permissions: read-all で読み取りだけに絞るなど、最小権限を意識します。
依存キャッシュで CI を速くするには？
actions/cache@v4 や、Python なら actions/setup-python の cache: pip、Node.js なら actions/setup-node の cache: npm を使うと、依存インストールがかなり速くなります。キーの設計（lock file の hash など）が大事で、雑だとキャッシュが当たらず効果が出ません。
マトリックスビルド（複数バージョン同時テスト）はいつ使う？
ライブラリ開発で複数 Python / Node.js バージョンに対応したい場合、複数 OS（Ubuntu / macOS / Windows）でテストしたい場合に使います。アプリ開発で本番が単一 OS / 単一バージョンなら、マトリックスを使うと CI 時間が伸びるだけなので不要です。
ローカルで workflow をテストできる？
act というツールで GitHub Actions の workflow をローカル実行できます（Docker ベース）。本番と完全に同じ挙動にはなりませんが、構文チェックや簡単な動作確認には便利。本格的なデバッグは GitHub 上で実際に push して確認するのが確実です。
まとめ
GitHub Actions は、GitHub 上でテスト、ビルド、デプロイなどを自動化できる仕組みです。
最初は .github/workflows/ に YAML で workflow を置き、runner 上で push や pull request をきっかけにテストを回すところから始めると分かりやすいです。
便利さはかなり大きいですが、GITHUB_TOKEN や Secrets の扱い、権限の広げすぎ、本番デプロイの自動化は慎重に見た方が安全です。
迷ったら、まずは push でテストを回す ところから始めるのがいちばん入りやすいです。
参考情報
- GitHub Docs: GitHub Actions の理解
- GitHub Docs: GitHub Actions のクイックスタート
- GitHub Docs: GitHub Actions の workflow 構文
- GitHub Docs: GitHub-hosted runners について
- GitHub Docs: 自動トークン認証
- GitHub Docs: GitHub Actions でシークレットを使う