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)

ワークフローを起動するトリガーです。pushpull_requestscheduleworkflow_dispatch(手動)など多数あります。

ジョブ(Job)

独立したランナー(仮想マシン)上で実行される処理の塊です。複数のジョブはデフォルトで並列実行されます。needsキーを使うと直列実行(依存関係)を定義できます。

ステップ(Step)

ジョブ内の処理単位。runでシェルコマンドを実行するか、usesで公開アクションを利用します。同じジョブ内のステップは必ず順次実行されます。

実践:最初のワークフローを書く

Node.jsプロジェクトの自動テスト

.github/workflows/ci.ymlYAML
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 cipackage-lock.json を厳密に参照するため再現性が高く、node_modules を毎回クリーンインストールします。CI環境での使用が推奨されています。

YAMLのインデントに関する注意

よくある間違いYAML
# ❌ 間違い:jobs の下に直接コマンドが来ている
jobs:
build:          # インデント不足
  runs-on: ubuntu-latest

# ✅ 正しい:jobs → ジョブ名 → キー の階層
jobs:
  build:         # 2スペースインデント
    runs-on: ubuntu-latest   # 4スペースインデント
⚠️ YAMLはタブ禁止・スペースのみ
タブ文字を使うとパースエラーになります。VS CodeのYAML拡張(Red Hat製)を入れておくと、書いた時点でエラーを検出してくれます。

よく使うトリガーイベント

イベント 発火タイミング 代表的なユースケース
push ブランチへのプッシュ時 コードの自動テスト・リントチェック
pull_request PR作成・更新・同期時 マージ前の品質ゲート
schedule cron形式で指定した時刻 夜間の定期ビルド・依存関係チェック
workflow_dispatch 手動実行(GitHubのUI or API) デプロイの手動承認、デバッグ実行
release リリース作成・公開時 npmパッケージの公開・バイナリ配布
workflow_call 他ワークフローから呼び出し時 再利用可能ワークフロー(DRY化)
複数イベントとscheduleの組み合わせYAML
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 — コードのチェックアウト

YAML
- uses: actions/checkout@v4
  with:
    fetch-depth: 0    # 全履歴取得(git log -1 などを使う場合に必要)
    # fetch-depth: 1 がデフォルト(最新コミットのみ)

actions/setup-node — Node.js環境

YAML
- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'         # 'yarn' や 'pnpm' も指定可

actions/setup-python — Python環境

YAML
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'

actions/upload-artifact — 成果物の保存

YAML
# ビルドしたファイルを別ジョブで使う・後からダウンロードする場合
- name: Upload build artifacts
  uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/
    retention-days: 7    # デフォルトは90日(無料プランで容量節約)

Slack通知の組み込み

YAML
- 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 }}

環境変数とシークレットの管理

スコープの使い分け

スコープ別の設定方法YAML
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

シークレットの設定手順

1

リポジトリの設定を開く

GitHubリポジトリ → SettingsSecrets and variablesActions

2

シークレットを追加

New repository secret をクリック。名前は大文字とアンダースコアで記述(例:AWS_ACCESS_KEY_ID

3

ワークフローから参照

${{ secrets.シークレット名 }} で参照。ログには自動でマスクされて表示されます。

⚠️ シークレットを runecho しても安全か?
GitHubのログマスク機能により、シークレットの値が出力に含まれる場合は *** に置換されます。ただし、base64エンコード等で変換した値はマスクされないため、シークレットをログに出力するロジック自体を書かないのがベストプラクティスです。

よくある落とし穴と対処法

落とし穴1:アクションのバージョン固定

YAML
# ❌ ブランチ指定は危険(予告なく変更される可能性がある)
- uses: actions/checkout@main

# ⚠️  タグ指定は現実的だが、タグが移動するリスクは残る
- uses: actions/checkout@v4

# ✅ 最もセキュア:SHA固定(サプライチェーン攻撃対策)
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

SHA固定はセキュリティ重視の組織(金融・医療など)では必須です。個人・中小規模プロジェクトではタグ固定で十分なケースが多いです。

落とし穴2:権限エラー(GITHUB_TOKEN)

YAML
# コミット・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分消費
⚠️ macOSランナーはFreeプランで月200分相当が限界
Freeプランの2,000分は、macOSで動かすと10倍換算されます。macOSが必要なビルド(iOS/macアプリ等)は消費が速いため、用途を絞るかSelf-Hosted Runnerの活用を検討してください。

落とし穴4:シークレットがフォークからのPRで使えない

セキュリティ上の理由から、フォークリポジトリからのプルリクエストでは、secrets にアクセスできません。公開リポジトリへの外部コントリビューターのPRでCIが失敗する場合の原因として多いです。

YAML
# フォークPRでシークレットが必要な場合の回避策
on:
  # pull_request_target はベースリポジトリのコンテキストで実行される
  # ⚠️ ただしコードインジェクション攻撃のリスクがあるため、慎重に使うこと
  pull_request_target:
    types: [opened, synchronize]

デバッグの方法

デバッグログの有効化

リポジトリのシークレットに以下を追加することで、詳細ログが出力されます。

  • ACTIONS_STEP_DEBUG = true(ステップの詳細ログ)
  • ACTIONS_RUNNER_DEBUG = true(ランナーの診断ログ)

環境情報の出力で問題を切り分ける

YAML
- 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  # 全環境変数を出力(シークレットはマスクされる)

ワークフローの手動実行(デバッグ時に便利)

YAML
on:
  workflow_dispatch:
    inputs:
      debug_mode:
        description: 'デバッグモードを有効化しますか?'
        type: boolean
        default: false
      environment:
        description: 'デプロイ先の環境'
        type: choice
        options:
          - staging
          - production
        required: true

料金プランと無料枠(2026年版)

📢 2026年1月の価格改定
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 を走らせるだけから始める
無料枠の目安Freeプランで月2,000分。Linux中心なら個人開発で余ることが多い
2026年の変更点2026年1月よりHosted Runner最大39%値下げ。Self-Hosted課金は延期中
よくある初期ミスYAMLのインデント・アクションのバージョン未固定・シークレットの権限不足
参照先GitHub Actions 公式ドキュメント(日本語)が充実しているので積極的に参照する
デバッグ方法シークレットに ACTIONS_STEP_DEBUG=true を追加で詳細ログが出る

本記事は2026年5月時点の情報をもとに作成しています。GitHub Actionsの仕様・料金は予告なく変更されることがあります。最新情報はGitHub Actions公式ドキュメントおよびGitHubブログ(日本語)でご確認ください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次