当サイトはアフィリエイトを含むプロモーションを掲載しています
GitHub Actions 入門【2026年版】CI/CDの基礎から実践的ワークフロー設定まで
GitHub公式
2026年1月価格改定反映
初心者〜中級者向け
プッシュをトリガーに自動テスト・ビルド・デプロイが走る仕組みを、コピペで使えるYAMLサンプルつきで解説します。2026年1月の価格改定情報も反映済み。
CI/CDとGitHub Actionsの基礎
CI/CDとは何か
CI(Continuous Integration:継続的インテグレーション)は、コードをマージするたびに自動でテストを走らせ、問題を早期に発見する仕組みです。CD(Continuous Delivery/Deployment:継続的デリバリー/デプロイ)は、テストを通過したコードを自動でステージングや本番環境に展開する仕組みです。
手動でテスト→ビルド→デプロイを行っていた場合、ミスのリスクが高く・時間もかかります。CI/CDはこの反復作業を自動化します。
GitHub Actionsの位置づけ
GitHub Actionsは、GitHubが2019年に正式リリースした自動化プラットフォームです。リポジトリ内に.github/workflows/ディレクトリを作成してYAMLファイルを置くだけで動作し、別途CI/CDサーバーを立てる必要がありません。
| ツール | 特徴 | GitHubとの統合 | インフラ管理 |
|---|---|---|---|
| GitHub Actions | GitHubネイティブ・設定が最小 | ◎ 完全統合 | 不要 |
| Jenkins | 自由度が高い・老舗 | △ 別途設定が必要 | 自社サーバーが必要 |
| CircleCI | 高速・設定が豊富 | △ Webhook連携 | 不要(SaaS) |
| GitLab CI/CD | GitLabネイティブ | × GitHubでは利用不可 | GitLab環境が必要 |
基本構成要素:4つのコンセプト
GitHub Actionsは「ワークフロー → イベント → ジョブ → ステップ」の階層構造で動作します。
# ワークフロー(.github/workflows/xxx.yml)
# └─ イベント(トリガー:push / pull_request / scheduleなど)
# └─ ジョブ(runs-on でOSを指定、デフォルトで並列実行)
# └─ ステップ(コマンド実行 or 既存アクションの利用)
ワークフロー(Workflow)
自動化の最上位単位。.github/workflows/に置いたYAMLファイル1つが1つのワークフローです。リポジトリごとに複数のワークフローを持てます。
イベント(Event)
ワークフローを起動するトリガーです。push・pull_request・schedule・workflow_dispatch(手動)など多数あります。
ジョブ(Job)
独立したランナー(仮想マシン)上で実行される処理の塊です。複数のジョブはデフォルトで並列実行されます。needsキーを使うと直列実行(依存関係)を定義できます。
ステップ(Step)
ジョブ内の処理単位。runでシェルコマンドを実行するか、usesで公開アクションを利用します。同じジョブ内のステップは必ず順次実行されます。
実践:最初のワークフローを書く
Node.jsプロジェクトの自動テスト
name: Node.js CI
# トリガー設定
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
# マトリックス:複数バージョンで並列テスト
strategy:
matrix:
node-version: [18.x, 20.x, 22.x]
steps:
# コードのチェックアウト(ほぼ必須)
- name: Checkout
uses: actions/checkout@v4
# Node.jsセットアップ(依存関係をキャッシュ)
- name: Setup Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm' # npm ci が速くなる
# npm install より npm ci が CI 環境では推奨
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build (if script exists)
run: npm run build --if-present
npm install より npm ci かnpm ci は package-lock.json を厳密に参照するため再現性が高く、node_modules を毎回クリーンインストールします。CI環境での使用が推奨されています。YAMLのインデントに関する注意
# ❌ 間違い:jobs の下に直接コマンドが来ている
jobs:
build: # インデント不足
runs-on: ubuntu-latest
# ✅ 正しい:jobs → ジョブ名 → キー の階層
jobs:
build: # 2スペースインデント
runs-on: ubuntu-latest # 4スペースインデント
タブ文字を使うとパースエラーになります。VS CodeのYAML拡張(Red Hat製)を入れておくと、書いた時点でエラーを検出してくれます。
よく使うトリガーイベント
| イベント | 発火タイミング | 代表的なユースケース |
|---|---|---|
push |
ブランチへのプッシュ時 | コードの自動テスト・リントチェック |
pull_request |
PR作成・更新・同期時 | マージ前の品質ゲート |
schedule |
cron形式で指定した時刻 | 夜間の定期ビルド・依存関係チェック |
workflow_dispatch |
手動実行(GitHubのUI or API) | デプロイの手動承認、デバッグ実行 |
release |
リリース作成・公開時 | npmパッケージの公開・バイナリ配布 |
workflow_call |
他ワークフローから呼び出し時 | 再利用可能ワークフロー(DRY化) |
on:
push:
branches:
- main
- 'releases/**' # releases/ プレフィックスの全ブランチ
paths-ignore: # これらのファイル変更では発火しない
- '**.md'
- '.gitignore'
pull_request:
types: [opened, synchronize, reopened]
schedule:
- cron: '0 2 * * 1' # 毎週月曜 02:00 UTC(= 11:00 JST)
workflow_dispatch: # 手動実行も可能にする
よく使うアクション集
actions/checkout — コードのチェックアウト
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 全履歴取得(git log -1 などを使う場合に必要)
# fetch-depth: 1 がデフォルト(最新コミットのみ)
actions/setup-node — Node.js環境
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm' # 'yarn' や 'pnpm' も指定可
actions/setup-python — Python環境
- uses: actions/setup-python@v5
with:
python-version: '3.12'
cache: 'pip'
actions/upload-artifact — 成果物の保存
# ビルドしたファイルを別ジョブで使う・後からダウンロードする場合
- name: Upload build artifacts
uses: actions/upload-artifact@v4
with:
name: build-output
path: dist/
retention-days: 7 # デフォルトは90日(無料プランで容量節約)
Slack通知の組み込み
- name: Notify Slack on failure
if: failure() # 失敗時のみ実行
uses: slackapi/slack-github-action@v1.27.0
with:
channel-id: ${{ secrets.SLACK_CHANNEL_ID }}
slack-message: ":x: ビルド失敗 - ${{ github.repository }} / ${{ github.ref_name }}"
env:
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
環境変数とシークレットの管理
スコープの使い分け
env:
APP_ENV: production # ① ワークフロー全体で有効
jobs:
deploy:
env:
DEPLOY_REGION: ap-northeast-1 # ② このジョブ内で有効
steps:
- name: Deploy
env:
API_KEY: ${{ secrets.PROD_API_KEY }} # ③ このステップ内のみ
run: ./scripts/deploy.sh
シークレットの設定手順
リポジトリの設定を開く
GitHubリポジトリ → Settings → Secrets and variables → Actions
シークレットを追加
New repository secret をクリック。名前は大文字とアンダースコアで記述(例:AWS_ACCESS_KEY_ID)
ワークフローから参照
${{ secrets.シークレット名 }} で参照。ログには自動でマスクされて表示されます。
run で echo しても安全か?GitHubのログマスク機能により、シークレットの値が出力に含まれる場合は
*** に置換されます。ただし、base64エンコード等で変換した値はマスクされないため、シークレットをログに出力するロジック自体を書かないのがベストプラクティスです。よくある落とし穴と対処法
落とし穴1:アクションのバージョン固定
# ❌ ブランチ指定は危険(予告なく変更される可能性がある)
- uses: actions/checkout@main
# ⚠️ タグ指定は現実的だが、タグが移動するリスクは残る
- uses: actions/checkout@v4
# ✅ 最もセキュア:SHA固定(サプライチェーン攻撃対策)
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
SHA固定はセキュリティ重視の組織(金融・医療など)では必須です。個人・中小規模プロジェクトではタグ固定で十分なケースが多いです。
落とし穴2:権限エラー(GITHUB_TOKEN)
# コミット・PRへのコメント・リリース作成などを行う場合に権限が必要
permissions:
contents: write # コードへの書き込み
pull-requests: write # PRへのコメント・ラベル変更
issues: write # Issueへの書き込み
packages: write # GitHub Packagesへの公開
# ⚠️ permissions を明示しない場合、リポジトリ設定によってはデフォルトで read-only になる
# Settings → Actions → General → Workflow permissions で確認
落とし穴3:macOSランナーのコスト
OSによって消費される「分」の重み付けが異なります。macOSは特にコストが高いため注意が必要です。
| OS | 消費分数の計算 | 例:実時間10分 |
|---|---|---|
Linux (ubuntu-latest) |
実時間 × 1 | 10分消費 |
Windows (windows-latest) |
実時間 × 2 | 20分消費 |
macOS (macos-latest) |
実時間 × 10 | 100分消費 |
Freeプランの2,000分は、macOSで動かすと10倍換算されます。macOSが必要なビルド(iOS/macアプリ等)は消費が速いため、用途を絞るかSelf-Hosted Runnerの活用を検討してください。
落とし穴4:シークレットがフォークからのPRで使えない
セキュリティ上の理由から、フォークリポジトリからのプルリクエストでは、secrets にアクセスできません。公開リポジトリへの外部コントリビューターのPRでCIが失敗する場合の原因として多いです。
# フォークPRでシークレットが必要な場合の回避策
on:
# pull_request_target はベースリポジトリのコンテキストで実行される
# ⚠️ ただしコードインジェクション攻撃のリスクがあるため、慎重に使うこと
pull_request_target:
types: [opened, synchronize]
デバッグの方法
デバッグログの有効化
リポジトリのシークレットに以下を追加することで、詳細ログが出力されます。
ACTIONS_STEP_DEBUG=true(ステップの詳細ログ)ACTIONS_RUNNER_DEBUG=true(ランナーの診断ログ)
環境情報の出力で問題を切り分ける
- name: Debug - print context
run: |
echo "=== GitHub Context ==="
echo "Event: ${{ github.event_name }}"
echo "Branch: ${{ github.ref_name }}"
echo "SHA: ${{ github.sha }}"
echo "Actor: ${{ github.actor }}"
echo "=== Runner Context ==="
echo "OS: ${{ runner.os }}"
echo "Temp: ${{ runner.temp }}"
echo "=== Environment ==="
env # 全環境変数を出力(シークレットはマスクされる)
ワークフローの手動実行(デバッグ時に便利)
on:
workflow_dispatch:
inputs:
debug_mode:
description: 'デバッグモードを有効化しますか?'
type: boolean
default: false
environment:
description: 'デプロイ先の環境'
type: choice
options:
- staging
- production
required: true
料金プランと無料枠(2026年版)
2026年1月1日よりGitHub Hosted Runnerの価格が改定され、最大39%の値下げが実施されました。パブリックリポジトリでの無料利用とFreeプランの無料枠(月2,000分)は維持されています。Self-Hosted Runnerへの課金変更は、ユーザーからのフィードバックを受けて延期・再検討となっています。
| プラン | プライベートリポジトリ無料枠 | ストレージ | 同時実行ジョブ数 |
|---|---|---|---|
| Free | 2,000分/月 | 500MB | 20 |
| Pro | 3,000分/月 | 1GB | 40 |
| Team | 3,000分/月 | 2GB | 60 |
| Enterprise | 50,000分/月 | 50GB | 500 |
| パブリックリポジトリ | 無制限(完全無料) | — | — |
OSによる消費分数の重み付けは前述のとおりです(Linux×1・Windows×2・macOS×10)。Freeプランで個人開発をする場合、Linuxのみで1日数回デプロイする程度なら2,000分は余裕を持って使えます。
※ 最新料金は GitHub公式ドキュメント でご確認ください。
セキュリティのベストプラクティス
- アクションのバージョンはタグまたはSHAで固定する(
@mainは危険) - シークレットをログに出力するコードを書かない
- ジョブに必要最小限の
permissionsを明示する - 外部からのPRに対するワークフローでは、コードを実行前に内容を確認する
- サードパーティアクションは利用前にソースコードとメンテナンス状況を確認する
- フォークPRで
pull_request_targetを使う場合はコードインジェクションに注意 - 環境変数に機密情報をハードコードしない(必ずシークレットを使う)
まとめ:今日から始めるGitHub Actions
基本を押さえれば、今日から自動化の恩恵を受けられます。まず「pushしたらテストを実行」だけのシンプルなワークフローから始め、動作を確認しながら機能を追加していくのが最短経路です。
.github/workflows/ci.yml を作り、npm test を走らせるだけから始めるACTIONS_STEP_DEBUG=true を追加で詳細ログが出る本記事は2026年5月時点の情報をもとに作成しています。GitHub Actionsの仕様・料金は予告なく変更されることがあります。最新情報はGitHub Actions公式ドキュメントおよびGitHubブログ(日本語)でご確認ください。
