GitHub Actionsとは？自動化で開発を加速させる強力なツールを徹底解説

プログラミングをしていて、「コードを書く以外の作業が面倒だな」と思ったことはありませんか？

コードをプッシュするたびに手動でテストを実行
デプロイするために毎回コマンドを打つ
コードレビュー後に手動でマージ
リリースノートを手作業で作成

こうした繰り返し作業を自動化してくれるのが、GitHub Actionsという仕組みです。

GitHub Actionsを使えば、「コードをプッシュしたら自動でテスト」「マージしたら自動でデプロイ」といった処理を、設定ファイルを書くだけで実現できます。しかも、GitHubに標準搭載されているので、追加のツールは不要なんです。

この記事では、GitHub Actionsの基本から実践的な使い方まで、初心者の方にも分かりやすく解説していきます。

GitHub Actionsって何？基本をサクッと理解しよう
1. CI/CDって何？
2. GitHub Actionsでできること
GitHub Actionsの基本概念
最初のワークフロー：Hello World
実践例：テストの自動実行
1. Node.jsプロジェクトのテスト
2. 新しい要素の説明
トリガーの種類
アクションの使い方
1. よく使われるアクション
2. GitHub Marketplace
Secretsの管理
1. Secretsの登録
2. Secretsの使用
環境変数の活用
複数ジョブの連携
1. ジョブの順序制御
2. アーティファクトによるデータ共有
条件分岐
1. if条件の使用
2. よく使われる条件
セルフホストランナー
キャッシュの活用
1. Node.jsの例
2. 手動でのキャッシュ管理
マトリックス戦略
1. 基本的な使い方
2. 特定の組み合わせを除外
料金体系
ベストプラクティス
まとめ：自動化で開発を加速

GitHub Actionsって何？基本をサクッと理解しよう

GitHub Actionsは、GitHubが提供するCI/CD（継続的インテグレーション/継続的デリバリー）プラットフォームです。

CI/CDって何？

まず、CI/CDについて簡単に説明しましょう。

CI（Continuous Integration：継続的インテグレーション）
コードの変更を頻繁にメインブランチに統合し、自動テストで問題を早期発見する手法です。

CD（Continuous Delivery/Deployment：継続的デリバリー/デプロイメント）
テストを通過したコードを、自動的に本番環境にリリースする手法です。

GitHub Actionsでできること

GitHub Actionsを使えば、こんなことが自動化できます。

テストの自動実行
プルリクエストを作成すると、自動的にテストが走ります。バグを早期発見できるんです。

自動デプロイ
メインブランチにマージされたら、自動的にサーバーにデプロイ。手動作業が不要になります。

コードの品質チェック
リンター（コードの書き方をチェックするツール）を自動実行して、コーディング規約を守れます。

定期実行タスク
毎日決まった時間にスクリプトを実行する、といったスケジュール実行も可能です。

Issue管理の自動化
特定のラベルが付いたら自動で担当者をアサインする、など管理作業も自動化できます。

GitHub Actionsの基本概念

GitHub Actionsには、いくつかの重要な用語があります。

ワークフロー（Workflow）

ワークフローは、自動化したい一連の処理をまとめたものです。

YAMLファイルで定義し、リポジトリの.github/workflows/ディレクトリに配置します。

例：test.yml、deploy.ymlなど

イベント（Event）

イベントは、ワークフローを起動するきっかけのことです。

よく使われるイベント：

push：コードがプッシュされた時
pull_request：プルリクエストが作成された時
schedule：定期実行（cronのような）
workflow_dispatch：手動実行

ジョブ（Job）

ジョブは、ワークフロー内の大きな処理の単位です。

1つのワークフローに複数のジョブを含められます。デフォルトでは並列実行されますが、依存関係を設定して順番に実行することもできます。

ステップ（Step）

ステップは、ジョブを構成する個別のタスクです。

コマンドを実行したり、既存のアクションを呼び出したりします。

アクション（Action）

アクションは、再利用可能な処理の部品です。

自分で作ることもできますし、GitHub Marketplaceで公開されている数千のアクションを使うこともできます。

ランナー（Runner）

ランナーは、ワークフローを実際に実行する環境（仮想マシン）のことです。

GitHubが提供するホスト型ランナーと、自分で用意するセルフホストランナーがあります。

最初のワークフロー：Hello World

実際にシンプルなワークフローを作ってみましょう。

ファイルの作成

リポジトリに.github/workflows/hello.ymlというファイルを作成します。

name: Hello World

on: [push]

jobs:
  greeting:
    runs-on: ubuntu-latest

    steps:
      - name: Say Hello
        run: echo "Hello, GitHub Actions!"

各部分の説明

name: Hello World
ワークフローの名前。GitHubのUIに表示されます。

on: [push]
トリガーの設定。この例では、プッシュされた時に実行されます。

jobs:
ジョブの定義開始。

greeting:
ジョブの名前（任意）。

runs-on: ubuntu-latest
どのOSで実行するか指定。ubuntu-latest、windows-latest、macos-latestなどが選べます。

steps:
ステップの定義開始。

– name: Say Hello
ステップの名前。

run: echo “Hello, GitHub Actions!”
実際に実行するコマンド。

実行結果の確認

このファイルをコミット＆プッシュすると、GitHubの「Actions」タブで実行結果を確認できます。

実践例：テストの自動実行

実際のプロジェクトでよく使われる、テスト自動実行の例を見てみましょう。

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: [16.x, 18.x, 20.x]

    steps:
      - name: チェックアウト
        uses: actions/checkout@v4

      - name: Node.jsのセットアップ
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}

      - name: 依存関係のインストール
        run: npm ci

      - name: テストの実行
        run: npm test

新しい要素の説明

branches: [ main, develop ]
特定のブランチへのプッシュだけを対象にします。

strategy: matrix:
複数の条件（この場合はNode.jsのバージョン）でテストを実行します。

uses: actions/checkout@v4
既存のアクションを使用。この場合、リポジトリのコードをチェックアウトします。

with:
アクションにパラメータを渡します。

${{ matrix.node-version }}
変数の参照。マトリックスで定義したバージョンが入ります。

トリガーの種類

ワークフローを起動する様々な方法があります。

pushイベント

コードがプッシュされた時に実行します。

on:
  push:
    branches:
      - main
      - 'release/**'
    paths:
      - 'src/**'

特定のブランチや、特定のパスのファイルが変更された時だけ実行することもできます。

pull_requestイベント

プルリクエストが作成された時に実行します。

on:
  pull_request:
    types: [opened, synchronize, reopened]

プルリクエストのアクション（開かれた、更新された、再開された）を指定できます。

scheduleイベント

定期実行を設定できます。cron形式で指定します。

on:
  schedule:
    # 毎日午前9時（UTC）に実行
    - cron: '0 9 * * *'

注意： 時刻はUTC（協定世界時）で指定します。日本時間より9時間遅れです。

workflow_dispatchイベント

手動実行を可能にします。

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先の環境'
        required: true
        type: choice
        options:
          - staging
          - production

入力パラメータも設定できるので、柔軟な実行が可能です。

repository_dispatchイベント

外部からAPIで起動します。他のサービスとの連携に便利です。

on:
  repository_dispatch:
    types: [deploy-command]

アクションの使い方

既存のアクションを活用することで、車輪の再発明を避けられます。

よく使われるアクション

actions/checkout
リポジトリのコードをチェックアウトします。ほぼ全てのワークフローで最初に使います。

- uses: actions/checkout@v4

actions/setup-node
Node.js環境をセットアップします。

- uses: actions/setup-node@v4
  with:
    node-version: '20'

actions/setup-python
Python環境をセットアップします。

- uses: actions/setup-python@v5
  with:
    python-version: '3.11'

actions/upload-artifact
ビルド成果物をアップロードして、他のジョブで使えるようにします。

- uses: actions/upload-artifact@v4
  with:
    name: build-files
    path: dist/

actions/download-artifact
アップロードされた成果物をダウンロードします。

- uses: actions/download-artifact@v4
  with:
    name: build-files

GitHub Marketplace

GitHub Marketplaceには、コミュニティが作成した数千のアクションが公開されています。

人気のアクション例：

Docker関連のアクション
AWS、Azure、GCPへのデプロイ
Slackへの通知
コードカバレッジのレポート
セキュリティスキャン

Secretsの管理

APIキーやパスワードなどの秘密情報を安全に扱う方法です。

Secretsの登録

リポジトリの「Settings」タブを開く
左メニューから「Secrets and variables」→「Actions」を選択
「New repository secret」をクリック
名前と値を入力して保存

Secretsの使用

steps:
  - name: デプロイ
    env:
      API_KEY: ${{ secrets.API_KEY }}
      DATABASE_PASSWORD: ${{ secrets.DB_PASSWORD }}
    run: |
      echo "APIキーを使ってデプロイ"
      ./deploy.sh

重要な注意点：

Secretsの値はログに表示されません（自動的にマスクされます）
forkされたリポジトリではsecretsは使えません（セキュリティのため）
プルリクエストからのワークフロー実行でも、制限があります

環境変数の活用

ワークフロー内で変数を使う方法です。

ワークフローレベルの環境変数

env:
  NODE_VERSION: '20'
  DEPLOY_ENV: 'production'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Node version: $NODE_VERSION"

ジョブレベルの環境変数

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      BUILD_DIR: './dist'
    steps:
      - run: echo "Build directory: $BUILD_DIR"

ステップレベルの環境変数

steps:
  - name: ビルド
    env:
      API_ENDPOINT: 'https://api.example.com'
    run: npm run build

複数ジョブの連携

ジョブ間で依存関係を設定したり、データを受け渡したりできます。

ジョブの順序制御

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: ビルド
        run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: テスト
        run: npm test

  deploy:
    needs: [build, test]
    runs-on: ubuntu-latest
    steps:
      - name: デプロイ
        run: ./deploy.sh

needs:を使うことで、「buildが成功したらtestを実行」「build とtestが両方成功したらdeployを実行」という順序を制御できます。

アーティファクトによるデータ共有

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: ビルド
        run: npm run build
      - name: 成果物をアップロード
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist/

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: 成果物をダウンロード
        uses: actions/download-artifact@v4
        with:
          name: dist-files
      - name: デプロイ
        run: ./deploy.sh

条件分岐

特定の条件下でのみステップやジョブを実行できます。

if条件の使用

steps:
  - name: 本番環境へのデプロイ
    if: github.ref == 'refs/heads/main'
    run: ./deploy-production.sh

  - name: ステージング環境へのデプロイ
    if: github.ref == 'refs/heads/develop'
    run: ./deploy-staging.sh

よく使われる条件

ブランチによる分岐：

if: github.ref == 'refs/heads/main'

イベントタイプによる分岐：

if: github.event_name == 'pull_request'

前のステップの成功/失敗による分岐：

if: success()  # 前のステップが成功
if: failure()  # 前のステップが失敗
if: always()   # 常に実行

セルフホストランナー

GitHub提供のランナーではなく、自分のサーバーで実行することもできます。

メリット

コスト削減
大量にワークフローを実行する場合、自前のサーバーの方が安くなることがあります。

カスタム環境
特殊なソフトウェアやハードウェアが必要な場合に対応できます。

ファイアウォール内部へのアクセス
社内ネットワークのリソースに直接アクセスできます。

セットアップ

リポジトリの「Settings」→「Actions」→「Runners」
「New self-hosted runner」をクリック
表示される手順に従ってランナーをインストール

ワークフローでの指定

jobs:
  build:
    runs-on: self-hosted
    steps:
      - run: echo "自分のサーバーで実行中"

キャッシュの活用

依存関係のインストール時間を短縮できます。

Node.jsの例

steps:
  - uses: actions/checkout@v4

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

  - run: npm ci
  - run: npm test

cache: ‘npm’を指定するだけで、node_modulesが自動的にキャッシュされます。

手動でのキャッシュ管理

steps:
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-node-

より細かい制御が必要な場合は、cacheアクションを直接使います。

マトリックス戦略

複数の環境でテストを実行できます。

基本的な使い方

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [16, 18, 20]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm test

この例では、3つのOS × 3つのNode.jsバージョン = 9通りの組み合わせでテストが実行されます。

特定の組み合わせを除外

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16, 18, 20]
    exclude:
      - os: windows-latest
        node-version: 16

Windowsでのバージョン16のテストだけをスキップできます。

料金体系

GitHub Actionsの利用には、一部制限があります。

無料枠

パブリックリポジトリ：
完全無料で無制限に使えます。

プライベートリポジトリ（Free プラン）：

月2,000分まで無料
ストレージ500MBまで無料

プライベートリポジトリ（有料プラン）：

Proプラン：月3,000分
Teamプラン：月3,000分
Enterpriseプラン：月50,000分

実行時間の計算

OSによって消費時間が異なります。

Linux：1分 = 1分
Windows：1分 = 2分
macOS：1分 = 10分

例えば、macOSで10分実行すると、100分として計算されます。

コスト最適化のコツ

必要な時だけ実行
全てのプッシュではなく、プルリクエスト時だけ実行するなど、トリガーを絞ります。

キャッシュを活用
依存関係のインストール時間を短縮します。

並列実行を減らす
マトリックス戦略は便利ですが、実行時間を倍々で消費します。必要最小限に。

Linuxを優先
可能な限りLinuxランナーを使用します。

ベストプラクティス

効果的にGitHub Actionsを使うためのコツです。

ワークフローのベストプラクティス

ワークフローファイルを分ける
テスト用、デプロイ用など、目的ごとにファイルを分けると管理しやすくなります。

ステップに明確な名前を付ける
何をしているか分かりやすい名前にします。

fail-fastを検討
マトリックステストで1つが失敗したら、他を中止するオプションです。

strategy:
  fail-fast: true

セキュリティのベストプラクティス

Secretsを適切に管理
環境変数に直接書かず、必ずSecretsを使います。

最小権限の原則
必要最小限の権限だけを付与します。

permissions:
  contents: read
  pull-requests: write

アクションのバージョン固定
@v4ではなく、具体的なSHAで固定するとさらに安全です。

uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab

パフォーマンスのベストプラクティス

不要なチェックアウトを避ける
コードが不要なジョブでは、checkoutを省略します。

ジョブの並列実行
依存関係のないジョブは並列実行させます。

早く失敗させる
時間のかかるステップの前に、簡単なチェックを入れます。

まとめ：自動化で開発を加速

GitHub Actionsは、開発ワークフローを自動化する強力なツールです。

この記事のポイント：

GitHub ActionsはGitHub標準のCI/CDプラットフォーム
ワークフロー、ジョブ、ステップ、アクションの階層構造
YAMLファイルで処理を定義する
push、pull_request、scheduleなど様々なトリガーがある
GitHub Marketplaceで既存のアクションを活用できる
Secretsで秘密情報を安全に管理
マトリックス戦略で複数環境のテストが可能
パブリックリポジトリは無料、プライベートには制限あり
キャッシュや並列実行で効率化できる
セキュリティとパフォーマンスのベストプラクティスを守る

始め方：

簡単なワークフローから始める
既存のアクションを活用する
徐々に複雑な自動化に挑戦
コミュニティの事例を参考にする

GitHub Actionsを活用すれば、繰り返し作業から解放され、コードを書く時間を増やせます。最初は小さく始めて、徐々に自動化の範囲を広げていきましょう！