Harmonic Society
オンライン予約 お問い合わせ
プログラミング

GitHub Actions CI/CD 設定方法｜初心者でも実践できる完全ガイド

kento_morota 16分で読めます

コードの変更を本番環境に反映するたびに手作業でテストやデプロイを行い、ヒューマンエラーに悩まされていませんか？CI/CDの導入で、こうした開発プロセスの課題を自動化で解決できます。

本記事では、GitHub ActionsでCI/CDを構築する方法を、実際のコード例を交えながら基礎から実践まで具体的に解説します。

GitHub Actions CI/CDとは？開発効率を高める自動化の仕組み

「コードを本番環境に反映するたびに手作業でテストやデプロイを行っている」「人為的ミスでサービスが停止した経験がある」――こうした課題を抱える開発チームは少なくありません。

CI/CD（継続的インテグレーション/継続的デリバリー）は、開発プロセスを自動化し、品質向上と効率化を実現する仕組みです。GitHub Actionsは、GitHubに標準搭載されたCI/CDツールとして、初期投資を抑えながら導入できる点で注目されています。

本記事では、GitHub Actions CI/CD 設定方法について、基礎から実践まで具体的に解説します。実際のコード例を交えながら、段階的に導入できるアプローチをご紹介します。なお、GitHubの基本操作についてはGitHubコマンド一覧もあわせてご覧ください。

CI/CDがもたらす3つの価値

CI（継続的インテグレーション）は、コード変更のたびに自動的にビルドやテストを実行し、問題を早期発見する仕組みです。CD（継続的デリバリー）は、テスト合格後のコードを自動的に本番環境へデプロイできる状態にします。

CI/CD導入による主なメリット：

  • 品質向上：自動テストで人為的ミスを早期発見
  • 開発速度向上：手作業が減り、開発に集中できる
  • 属人化解消：デプロイ手順が自動化・標準化される

GitHub Actionsの特徴と選ばれる理由

GitHub Actionsは、他のCI/CDツールと比較して以下の優位性があります。

導入の容易さ

  • GitHubアカウントがあればすぐ利用開始
  • 別途サーバー構築が不要
  • YAML形式で直感的に記述可能

コスト効率

  • パブリックリポジトリは完全無料
  • プライベートリポジトリも月2,000分の無料枠
  • サーバー管理コストがかからない

拡張性

  • GitHub Marketplaceに豊富な既製アクション
  • あらゆる言語・フレームワークに対応
  • Linux、Windows、macOS環境で実行可能

従来のJenkinsなどと比較すると、専任の運用担当者が不要で、GitHub上ですべて完結する点が大きな特徴です。

GitHub Actionsの基本構成要素

GitHub Actions CI/CD 設定方法を理解するには、主要な構成要素を把握することが重要です。

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

ワークフローは自動化プロセス全体を定義したYAMLファイルで、.github/workflows/ディレクトリに配置します。1つのリポジトリに複数のワークフローを配置可能です。

ジョブはワークフロー内の独立した実行単位で、並行または順次実行できます。ステップはジョブを構成する個々のタスクで、順番に実行されます。

name: CI Workflow
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test

この階層構造により、処理の流れが視覚的に理解しやすく、エラー発生時も原因を特定しやすくなります。

トリガーイベントの種類

ワークフローを実行するきっかけとなる主なイベント：

  • push：コードがプッシュされたとき
  • pull_request：プルリクエストが作成・更新されたとき
  • schedule：定期実行（cron形式）
  • workflow_dispatch：手動実行

ブランチやパスでフィルタリングも可能です：

on:
  push:
    branches: [main, develop]
    paths: ['src/**']
  schedule:
    - cron: '0 0 * * 0'

ランナー環境の選択

ランナーはワークフローを実行するサーバー環境です。

GitHub-hosted runner（推奨）

  • GitHubが管理する仮想マシン
  • Ubuntu、Windows、macOSが選択可能
  • セットアップ不要で即座に利用開始

Self-hosted runner

  • 自社サーバーで実行
  • 特殊な環境や高スペックが必要な場合に選択

まずはGitHub-hosted runnerから始めることで、運用負荷を最小限に抑えられます。

GitHub Actions CI/CD 設定方法｜実践ステップ

ここからは、実際の設定手順を具体的に解説します。

ワークフローファイルの作成

ワークフローファイルは必ず.github/workflows/ディレクトリに配置します。

your-repository/
└── .github/
    └── workflows/
        └── ci.yml

作成方法

  1. GitHubのリポジトリで「Actions」タブをクリック
  2. 「set up a workflow yourself」を選択
  3. ブラウザ上のエディタでYAMLファイルを編集
  4. コミットして保存

またはローカルで作成してpushも可能です：

mkdir -p .github/workflows
touch .github/workflows/ci.yml
git add .github/workflows/ci.yml
git commit -m "Add CI workflow"
git push

最小構成のワークフロー例

まずはシンプルなワークフローから始めましょう。

name: Hello World

on:
  push:
    branches: [main]

jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
      - name: 実行確認
        run: echo "Hello, GitHub Actions!"
      
      - name: 環境情報
        run: |
          echo "OS: $RUNNER_OS"
          node --version

このファイルを保存してmainブランチにpushすると、ワークフローが自動実行されます。

実行状況の確認方法

確認手順

  1. リポジトリの「Actions」タブをクリック
  2. 実行履歴から対象のワークフローを選択
  3. 各ステップのログを確認

ステータス表示

  • 緑のチェックマーク：成功
  • 赤のバツマーク：失敗
  • 黄色の丸：実行中

失敗時は該当ステップのログで詳細なエラーメッセージを確認できます。

よくあるエラーと対処法

YAMLの構文エラー

Error: Invalid workflow file

対処法：インデント（スペース2つ）を正しく設定。タブ文字は使用しない。

コマンド実行エラー

Error: Process completed with exit code 1

対処法：該当ステップのログを確認し、ローカル環境で同じコマンドを実行してテスト。

権限エラー

permissions:
  contents: read
  pull-requests: write

必要な権限をワークフローに明示的に追加します。

実践例①：Node.jsアプリのテスト自動化

実際のプロジェクトで活用できる具体的なワークフローを紹介します。

基本的なテスト自動化

name: Node.js CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build

ポイント

  • npm ciはnpm installより高速で安定
  • cache: 'npm'で依存パッケージをキャッシュし実行時間を短縮

複数バージョンでのテスト

複数のNode.jsバージョンで動作確認する場合：

name: Node.js Matrix

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: [16, 18, 20]
    
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

6つの組み合わせで並行実行され、幅広い環境での動作を保証できます。

実践例②：Dockerイメージのビルドとデプロイ

コンテナ化されたアプリケーションのCI/CD設定例です。

Docker Hubへのプッシュ

name: Docker Build and Push

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v2
      
      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      
      - name: Build and push
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: your-username/myapp:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

AWS ECRへのデプロイ

name: Deploy to AWS ECR

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ap-northeast-1
      
      - name: Login to ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1
      
      - name: Build and push
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/myapp:$IMAGE_TAG .
          docker push $ECR_REGISTRY/myapp:$IMAGE_TAG

GitHub Secretsでの認証情報管理

機密情報は必ずGitHub Secretsで管理します。

設定手順

  1. リポジトリの「Settings」→「Secrets and variables」→「Actions」
  2. 「New repository secret」をクリック
  3. 名前と値を入力して保存

ワークフロー内では${{ secrets.SECRET_NAME }}で参照します。

実践例③：本番環境への自動デプロイ

安全な自動デプロイの設計方法を解説します。

環境別の設定

開発環境と本番環境で異なる設定を使用する例：

name: Deploy

on:
  push:
    branches: [develop, main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      
      - name: Set environment
        run: |
          if [ "${{ github.ref }}" = "refs/heads/main" ]; then
            echo "ENV=production" >> $GITHUB_ENV
            echo "URL=${{ secrets.PROD_URL }}" >> $GITHUB_ENV
          else
            echo "ENV=development" >> $GITHUB_ENV
            echo "URL=${{ secrets.DEV_URL }}" >> $GITHUB_ENV
          fi
      
      - name: Deploy to ${{ env.ENV }}
        run: ./deploy.sh ${{ env.URL }}

承認フローの組み込み

本番デプロイ前に手動承認を必要とする設定：

name: Production Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        run: ./deploy.sh

リポジトリの「Settings」→「Environments」で承認者を設定します。

ロールバックの仕組み

デプロイ失敗時の自動ロールバック：

- name: Deploy
  id: deploy
  run: ./deploy.sh
  
- name: Health check
  run: curl -f https://example.com/health
  
- name: Rollback on failure
  if: failure()
  run: ./rollback.sh

運用時のポイントと最適化

効率的な運用のための実践的なアドバイスです。

無料枠と料金体系

無料枠

  • パブリックリポジトリ：無制限
  • プライベートリポジトリ：月2,000分

実行時間の目安

  • 単純なテスト：2〜5分
  • ビルド含む：5〜10分
  • フルCI/CD：10〜20分

複数ジョブの並行実行で時間を短縮できますが、無料枠の消費も増えます。

ワークフロー実行時間の最適化

キャッシュの活用

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

不要な実行の回避

on:
  push:
    paths-ignore:
      - '**.md'
      - 'docs/**'

ドキュメント変更時はワークフローをスキップします。

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

  1. 最小権限の原則：必要最小限の権限のみ付与
  2. Secretsの適切な管理：機密情報は必ずSecrets化
  3. 依存関係の定期更新：セキュリティパッチを適用
  4. サードパーティアクションの検証：信頼できるアクションのみ使用

GitHub Marketplaceの活用

既製アクションを活用して効率的に開発できます。

よく使われるアクション

基本的なアクション

  • actions/checkout：リポジトリのコードを取得
  • actions/setup-node：Node.js環境のセットアップ
  • actions/cache：依存関係のキャッシュ

デプロイ関連

  • aws-actions/configure-aws-credentials：AWS認証
  • docker/build-push-action：Dockerビルド・プッシュ

通知・レポート

  • codecov/codecov-action：カバレッジレポート
  • 8398a7/action-slack：Slack通知

アクションの探し方

  1. GitHub Marketplaceで検索
  2. スター数とメンテナンス状況を確認
  3. ドキュメントの充実度をチェック
  4. 公式アクションを優先的に選択

まとめ：段階的な導入で確実に

GitHub Actions CI/CD 設定方法について、基礎から実践まで解説しました。

導入のステップ

  1. 最小構成から開始：まずは自動テストだけを導入
  2. 段階的に拡張：慣れてからビルド、デプロイへ展開
  3. チームで運用：ルールを決めて継続的に改善

成功のポイント

  • 必要最小限の機能から始める
  • GitHub Marketplaceの既製アクションを活用
  • 無料枠内で十分な自動化が可能
  • セキュリティを意識した設定

GitHub Actionsは、GitHubを使っているなら追加コストなしで始められる「ちょうどいい」CI/CDツールです。小さく始めて、自社に合った形に育てていくアプローチをお勧めします。

導入や運用でお困りの際は、専門家のサポートを活用することも選択肢の一つです。

#GitHub Actions#CI/CD#DevOps
共有:

関連記事

【初心者向け】AWS Lambdaの使い方を基礎から解説｜実…

【初心者向け】AWS Lambdaの使い方を基礎から解説｜実践で使える設定手順
【Docker入門】初心者でも安心！基礎から実践まで丁寧に解…

【Docker入門】初心者でも安心！基礎から実践まで丁寧に解説
【初心者向け】Docker Compose の使い方｜基本か…

【初心者向け】Docker Compose の使い方｜基本から実践まで丁寧に解説

ちょっとした業務の悩みも、気軽にご相談ください。

まずは話だけ聞いてもらう