第7章 GitHub Actions（CI/CD）

GitHub Actions は、GitHub に組み込まれた CI/CD プラットフォームです。
コードの変更をトリガーに、テスト・ビルド・デプロイを 自動化 できます。

管理者として、チームの開発フローを支える ワークフローの設計と運用 を学びましょう ⚡

7.1 ワークフローの基本構造

全体像

flowchart TD
    WF["📄 Workflow
(.github/workflows/ci.yml)"]
    WF --> J1["Job: test"]
    WF --> J2["Job: build"]
    WF --> J3["Job: deploy"]
    J1 --> S1["Step 1: Checkout"]
    J1 --> S2["Step 2: Setup Node"]
    J1 --> S3["Step 3: Install deps"]
    J1 --> S4["Step 4: Run tests"]

    J1 -- "成功したら" --> J2
    J2 -- "成功したら" --> J3

    style WF fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style J1 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style J2 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style J3 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1

概念	説明
Workflow	`.github/workflows/` 配下の YAML ファイル。 1ファイル = 1ワークフロー
Event	ワークフローを起動するトリガー（push, PR, schedule など）
Job	ワークフロー内の実行単位。デフォルトで並列実行
Step	Job 内の各ステップ。 Action を使うか、シェルコマンドを実行
Action	再利用可能な処理ユニット（公式 or コミュニティ製）
Runner	ジョブを実行するサーバー（GitHub-hosted or Self-hosted）

最小構成のワークフロー

name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - run: npm ci
      - run: npm test

7.2 トリガー（on）の種類と設計

よく使うトリガー

トリガー	発火タイミング	主な用途
`push`	ブランチへの push 時	CI テスト、デプロイ
`pull_request`	PR の作成・更新時	コードレビュー前のチェック
`schedule`	cron 式でスケジュール実行	定期的なバッチ処理
`workflow_dispatch`	手動実行（ボタン）	デプロイ、メンテナンス
`release`	リリースの作成時	パッケージ公開
`workflow_call`	他のワークフローから呼び出し	再利用ワークフロー

トリガーの設定例

on:
  # ブランチとパスでフィルタリング
  push:
    branches: [main]
    paths:
      - "src/**"
      - "package.json"
    paths-ignore:
      - "**.md"
      - "docs/**"

  # PR イベントの種類を指定
  pull_request:
    types: [opened, synchronize, reopened]
    branches: [main, develop]

  # 毎日午前3時（UTC）に実行
  schedule:
    - cron: "0 3 * * *"

  # 手動実行（入力パラメータ付き）
  workflow_dispatch:
    inputs:
      environment:
        description: "デプロイ先の環境"
        required: true
        type: choice
        options:
          - staging
          - production

flowchart LR
    P["push to main"] --> CI["CI ワークフロー"]
    PR["PR 作成/更新"] --> CI
    S["毎日3時 (UTC)"] --> BATCH["バッチワークフロー"]
    M["手動ボタン"] --> DEPLOY["デプロイワークフロー"]
    R["リリース作成"] --> PUB["パッケージ公開"]

    style CI fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style BATCH fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style DEPLOY fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style PUB fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

7.3 Secrets / Variables / Environments

Secrets（機密情報）

API キー、トークンなど 絶対に公開してはいけない値 を安全に保存します。

flowchart TD
    subgraph "Secrets の設定場所"
        RS["Repository Secrets
1リポジトリで使用"]
        ES["Environment Secrets
特定環境でのみ使用"]
        OS["Organization Secrets
複数リポジトリで共有"]
    end

    style RS fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style ES fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style OS fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

# ワークフロー内での使用
steps:
  - name: Deploy
    env:
      API_KEY: ${{ secrets.API_KEY }}
    run: ./deploy.sh

Variables（変数）

機密ではない設定値を保存します。
ログにそのまま出力されます。

env:
  APP_NAME: ${{ vars.APP_NAME }}
  NODE_ENV: ${{ vars.NODE_ENV }}

Environments（環境）

承認フロー や 環境固有の Secrets を管理するための仕組みです。

jobs:
  deploy-staging:
    environment: staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to staging"

  deploy-production:
    environment: production # 承認が必要な環境
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production"

7.4 GITHUB_TOKEN の権限制御

GITHUB_TOKEN とは？

各ワークフロー実行時に 自動発行される一時的なトークン です。
明示的に作成する必要はなく、リポジトリに対する操作に使えます。

最小権限の原則

# ワークフロー全体のデフォルト権限を最小に
permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  release:
    runs-on: ubuntu-latest
    # このジョブだけ書き込み権限を付与
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - run: gh release create v1.0.0

主な権限

権限	説明
`contents`	リポジトリの読み書き
`pull-requests`	PR の作成・コメント
`issues`	Issue の操作
`packages`	パッケージの読み書き
`deployments`	デプロイメントの管理
`id-token`	OIDC トークンの取得
`actions`	ワークフロー実行の管理

7.5 Reusable Workflows と Composite Actions

Reusable Workflows

複数のリポジトリで同じワークフローを 呼び出し で再利用できます。

name: Reusable Test

on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
        default: "20"
    secrets:
      NPM_TOKEN:
        required: false

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci
      - run: npm test

name: CI

on:
  pull_request:

jobs:
  test:
    uses: your-org/shared-workflows/.github/workflows/reusable-test.yml@main
    with:
      node-version: "20"
    secrets:
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Composite Actions

複数のステップを 1つの Action にまとめて再利用できます。

name: Setup Project
description: プロジェクトのセットアップ

inputs:
  node-version:
    description: Node.js のバージョン
    default: "20"

runs:
  using: "composite"
  steps:
    - uses: actions/checkout@v4
      shell: bash

    - uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}
        cache: "npm"

    - run: npm ci
      shell: bash

steps:
  - uses: ./.github/actions/setup-project
    with:
      node-version: "20"
  - run: npm test

どちらを使う？

項目	Reusable Workflows	Composite Actions
粒度	ワークフロー全体	複数ステップ
呼び出し方	`jobs.*.uses`	`steps.*.uses`
ジョブ定義	含められる	含められない
共有範囲	クロスリポジトリ	同リポジトリ or 公開

7.6 Self-hosted Runner

いつ必要？

場面	理由
社内ネットワークへのアクセスが必要	GitHub-hosted は外部ネットワーク
特殊なハードウェア（GPU など）	GitHub-hosted では提供されない
実行時間の制限を超える	GitHub-hosted は6時間まで
コストを最適化したい	大量実行時に自前のほうが安い場合

設定の流れ

flowchart LR
    A["① Settings → Actions
→ Runners"] --> B["② New self-hosted
runner"]
    B --> C["③ OS を選択
スクリプトを実行"]
    C --> D["④ ラベルを設定"]
    D --> E["⑤ ワークフローで
runs-on 指定"]

    style A fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style E fill:#E8F5E9,stroke:#43A047,color:#1B5E20

jobs:
  build:
    runs-on: [self-hosted, linux, gpu] # ラベルで指定
    steps:
      - uses: actions/checkout@v4
      - run: ./train-model.sh

7.7 Actions のセキュリティ

Action のピン留め

# ❌ タグ指定（作者が上書き可能）
- uses: actions/checkout@v4

# ✅ コミットSHA指定（改ざん不可）
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

許可リストの設定

Organization 設定で、使用可能な Actions を制限できます。

設定	説明
Allow all actions	すべて許可
Allow local actions only	同一リポジトリの Actions のみ
Allow select actions	指定した Actions のみ（推奨）

7.8 実践的な使用例

CI（テスト + リント）

name: CI

on:
  pull_request:
    branches: [main, develop]

permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm test -- --coverage

CD（タグ push → リリース）

name: Release

on:
  push:
    tags: ["v*"]

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }

      - run: npm ci
      - run: npm run build

      - name: Create GitHub Release
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gh release create ${{ github.ref_name }} --generate-notes

まとめ

機能	管理者として押さえるポイント
ワークフロー構造	`.github/workflows/` に YAML で定義
トリガー	イベントに応じた適切な発火条件を設計
Secrets / Environments	機密情報は Secrets、環境ごとに分離
Permissions	最小権限の原則を徹底
Reusable / Composite	共通処理を再利用して保守性向上
Self-hosted Runner	必要な場合のみ、セキュリティに注意
セキュリティ	SHA ピン留め、許可リスト