【初心者向け】GitHub Actions の使い方入門｜基礎から実践まで丁寧に解説

テストやデプロイを毎回手動で行っていませんか？GitHub Actionsを使えば、コードのテストからWebサイトの更新まで、繰り返しの作業を自動化できます。

この記事では、GitHub Actionsの基本概念からワークフローの作成方法、実践的な活用例まで、初心者でもすぐに始められるよう丁寧に解説します。

GitHub Actionsとは？基本の仕組みと導入メリット

GitHub Actionsは、GitHubに保存したコードに対してさまざまな作業を自動実行できるサービスです。プログラムのテストやWebサイトの更新、データのバックアップなど、繰り返し行う作業を自動化できます。

基本的な仕組みはシンプルです。「いつ」「何を」「どうする」を設定するだけで、人が操作しなくても自動で動く仕組みが作れます。

できること・できないこと

できること:

• コードの自動テスト（更新のたびにエラーチェック）
• Webサイトの自動公開（コード更新を本番環境へ自動反映、詳しくはGitHub Actions自動デプロイ入門を参照）
• 定期的なデータ取得（決まった時間に外部APIからデータ収集）
• 通知の自動送信（特定条件でSlackやメールに通知）
• ドキュメントの自動生成（コードから説明書を自動作成）

できないこと:

• GitHub外の複雑な業務フロー（承認プロセスが複雑な社内ワークフロー）
• リアルタイム処理（瞬時の応答が必要な処理）
• 大量のデータ処理（無料プランには実行時間の制限あり）
• GUIでの複雑な操作（マウス操作が必要な作業）

中小企業が自動化すべき理由

限られた人員で多くの業務をこなす中小企業こそ、自動化の恩恵を受けやすい環境にあります。

1. 属人化の解消
「この作業は○○さんしかできない」という状況はリスクです。作業を自動化することで、誰でも実行できる仕組みになります。

2. ヒューマンエラーの削減
手作業での更新やデプロイは、どんなに注意しても間違いが起こります。自動化により、ミスを大幅に減らせます。

3. 低コストで始められる
GitHubの無料プランでも月2,000分まで使えるため、高額なツールを導入しなくても始められます。

無料プランでどこまで使える？

GitHub Actionsは無料プランでも実用的に使えるのが大きな魅力です。

無料プラン（Free）の範囲:

• 実行時間：月2,000分（パブリックリポジトリは無制限）
• ストレージ：500MB
• 同時実行：最大20ジョブ

2,000分でできること:
- 1回5分のテストを1日13回実行（月間約2,000分）
- 小規模Webサイトのデプロイなら月100回以上
- 定期バックアップ（1日1回、5分程度）なら十分

実行時間の計算:
- Linux環境：1分 = 1分
- Windows環境：1分 = 2分
- macOS環境：1分 = 10分

コスト面から、特別な理由がなければLinux環境（ubuntu-latest）を使います。中小企業の多くは無料プランで十分です。

GitHub Actionsの基礎用語

GitHub Actionsの使い方を理解するには、いくつかの専門用語を押さえる必要があります。実際の業務に置き換えてイメージすると理解しやすくなります。

ワークフロー・ジョブ・ステップの関係

ワークフロー（Workflow）は、自動化したい一連の作業全体を指します。会社でいえば「業務フロー」のようなものです。

ジョブ（Job）は、ワークフローの中の大きなまとまりです。複数のステップで構成され、デフォルトでは並列実行されます。

ステップ（Step）は、ジョブの中の個別の作業で、上から順番に実行されます。

関係性の例:

ワークフロー「新商品の発売準備」
  └ ジョブ1「商品ページ作成」
      ├ ステップ1「写真撮影」
      ├ ステップ2「説明文作成」
      └ ステップ3「価格設定」
  └ ジョブ2「在庫登録」
      ├ ステップ1「在庫確認」
      └ ステップ2「システム登録」

イベントとトリガー

イベントは、ワークフローを起動するきっかけです。「いつ実行するか」を決める重要な要素です。

主なイベント:

• push: コードがリポジトリに追加されたとき
• pull_request: プルリクエストが作成・更新されたとき
• schedule: 決まった時間（cron形式で指定）
• workflow_dispatch: 手動で実行ボタンを押したとき

設定例:

on:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 9 * * 1'  # 毎週月曜9時

アクション

アクションは、再利用可能な作業の部品です。世界中の開発者が作った便利なアクションを使うことができます。

よく使うアクション:

# コードを取得
- uses: actions/checkout@v3

# Node.jsをセットアップ
- uses: actions/setup-node@v3
  with:
    node-version: '18'

信頼できる提供元のアクションを選び、バージョンを指定して使うことがポイントです。

はじめてのワークフロー作成

実際に手を動かしながらワークフローを作成します。最もシンプルな例から始めるので、安心して進めてください。

リポジトリの準備

手順:

1. GitHubにログインし、右上の「+」→「New repository」をクリック
2. Repository nameに「github-actions-test」と入力
3. 「Public」を選択（無料プランで無制限に使うため）
4. 「Add a README file」にチェック
5. 「Create repository」をクリック

練習用のリポジトリで試すことで、本番環境への影響を避けられます。

ワークフローファイルの配置ルール

GitHub Actionsのワークフローは、決まった場所に決まった形式で保存する必要があります。

配置場所:

リポジトリのルート
└ .github/
    └ workflows/
        └ hello.yml

重要なルール:

• フォルダ名は.github/workflows/固定
• ファイル形式は.ymlまたは.yaml
• ファイル名は任意だが、内容がわかる名前にする

シンプルなワークフローの作成

ファイル名: .github/workflows/hello.yml

name: Hello World Workflow

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  greeting:
    runs-on: ubuntu-latest

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

      - name: Show Date
        run: date

コードの解説:

• name: ワークフローの名前（Actionsタブで表示）
• on: トリガー設定（mainブランチへのpushまたは手動実行）
• runs-on: 実行環境（ubuntu-latest = 最新のUbuntu）
• steps: 実行する処理

作成手順:

1. リポジトリで「Add file」→「Create new file」
2. ファイル名に.github/workflows/hello.ymlを入力
3. 上記のコードをコピー&ペースト
4. 「Commit new file」をクリック

動作確認

手動実行の方法:

1. リポジトリの「Actions」タブをクリック
2. 左サイドバーから「Hello World Workflow」を選択
3. 「Run workflow」ボタンをクリック
4. ブランチを選択して「Run workflow」をクリック

実行結果の確認:

• ✅ 緑色のチェックマークが表示されたら成功
• 各ステップの実行結果が確認できます
• ❌ 赤いバツマークが表示されたら、YAMLのインデント（字下げ）が正しいか確認

YAMLファイルの書き方

ワークフローはYAML形式で記述します。基本ルールを押さえれば誰でも書けるようになります。

YAMLの基本ルール

1. インデント（字下げ）が重要: スペース2つで統一、タブ文字は使えません
2. コロン（:）で項目と値を区切る: name: ワークフロー名
3. ハイフン（-）でリストを表現: 複数の項目を列挙
4. コメントはシャープ（#）: # これはコメント

よくある間違い:

# ❌ インデントがバラバラ
jobs:
 test:
   runs-on: ubuntu-latest
    steps:

# ✅ インデントを揃える
jobs:
  test:
    runs-on: ubuntu-latest
    steps:

必須項目

すべてのワークフローに必要な基本項目：

name: ワークフロー名

on: [push]  # トリガー（必須）

jobs:
  job-name:
    runs-on: ubuntu-latest  # 実行環境（必須）
    steps:
      - name: ステップ名
        run: echo "Hello"

トリガーイベントの設定

コードpush時:

on:
  push:
    branches: [ main, develop ]
    paths:
      - 'src/**'  # srcフォルダ内の変更のみ

定期実行（cron）:

on:
  schedule:
    - cron: '0 9 * * 1'  # 毎週月曜9:00 (UTC)

cron形式の読み方:

分 時 日 月 曜日
0  9  *  *  1

複数トリガーの組み合わせ:

on:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

環境変数とシークレット

環境変数の設定:

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production
    steps:
      - run: echo "環境: $NODE_ENV"

シークレット（機密情報）の設定:

1. リポジトリの「Settings」→「Secrets and variables」→「Actions」
2. 「New repository secret」をクリック
3. Name: API_KEY、Secret: 実際のAPIキーを入力

ワークフローでの使用:

steps:
  - name: APIを呼び出す
    env:
      API_KEY: ${{ secrets.API_KEY }}
    run: curl -H "Authorization: Bearer $API_KEY" https://api.example.com

セキュリティのポイント:
- APIキーやパスワードは必ずシークレットで管理
- コードに直接書かない
- シークレットはログに自動的にマスクされます

すぐ使える実践例

実際の業務で使える具体的なワークフロー例を紹介します。

コードの自動テスト

ワークフロー例（Node.jsプロジェクト）:

name: コード品質チェック

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'

      - run: npm ci
      - run: npm run lint
      - run: npm test

ポイント:
- npm ciはnpm installより高速で安定
- キャッシュ機能で実行時間を短縮
- プルリクエストごとに自動実行され、品質が保たれる

Webサイトの自動デプロイ

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Deploy to Server
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
        run: |
          echo "$SSH_PRIVATE_KEY" > key.pem
          chmod 600 key.pem
          rsync -avz -e "ssh -i key.pem" ./dist/ user@server:/var/www/

定期的なバックアップ

name: Daily Backup

on:
  schedule:
    - cron: '0 2 * * *'  # 毎日2:00 (UTC)

jobs:
  backup:
    runs-on: ubuntu-latest

    steps:
      - name: Backup Database
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: |
          mysqldump -u user -p$DB_PASSWORD database > backup.sql
          aws s3 cp backup.sql s3://my-bucket/backups/$(date +%Y%m%d).sql

よくあるエラーと対処法

ワークフローが実行されない

確認ポイント:

1. ファイルの配置場所が.github/workflows/になっているか
2. YAMLの構文エラーがないか（インデントを確認）
3. トリガー設定が正しいか（ブランチ名など）
4. リポジトリの「Actions」タブが有効になっているか

よく見るエラーメッセージ

「Invalid workflow file」
- YAMLの構文エラー
- オンラインYAMLチェッカーで確認

「Resource not accessible by integration」
- 権限不足
- リポジトリの「Settings」→「Actions」→「General」で権限を確認

「Process completed with exit code 1」
- コマンドの実行エラー
- ログを確認してエラー箇所を特定

デバッグ方法

ログの確認:
1. 「Actions」タブで失敗した実行をクリック
2. ジョブ名をクリック
3. 各ステップを展開してエラーメッセージを確認

デバッグ情報を追加:

steps:
  - name: Debug Info
    run: |
      echo "Current directory: $(pwd)"
      echo "Files: $(ls -la)"
      echo "Environment: $NODE_ENV"

業務の属人化を解消する導入ステップ

小さく始めて徐々に広げる

ステップ1: 簡単な自動化から
- 手動テストの自動化
- 定期レポートの自動生成

ステップ2: デプロイの自動化
- ステージング環境への自動デプロイ
- 本番環境への自動デプロイ

ステップ3: 複雑なワークフロー
- 複数環境への展開
- 承認フローの追加

社内に定着させるポイント

1. ドキュメント化: ワークフローの目的と使い方を記録
2. 段階的な導入: 一度にすべてを変えない
3. 成功体験の共有: 自動化で削減できた時間を可視化
4. 定期的な見直し: 改善点を継続的に検討

次のステップ

さらに学びたい方へ:

• GitHub公式ドキュメント: 最新機能と詳細な仕様
• GitHub Marketplace: 便利なアクションの検索
• コミュニティ: Zenn、Qiitaの記事

GitHub Actionsの使い方をマスターすることで、繰り返し作業から解放され、本来注力すべき業務に時間を使えるようになります。テストの自動化と組み合わせるとさらに効果的です。テストフレームワークの選び方についてはVitestとJestの比較記事も参考にしてください。まずは小さな一歩から、業務の自動化を始めましょう。