【2026年版】GitHub Actionsで始めるCI/CD入門｜個人開発者のためのテスト自動化・自動デプロイ実践ガイド

広告

マネーフォワード

最大2,000円還元

詳しく見る →

最初のワークフローを作る：Node.jsプロジェクトのテスト自動化

まずは一番シンプルな例から。リポジトリに.github/workflows/ci.ymlを作成します。

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm test

たった18行です。これをリポジトリにpushするだけで、mainブランチへのpushやPRのたびにテストが自動実行されます。

ポイントはcache: 'npm'の部分。これがないとnpmパッケージを毎回フルインストールすることになり、ワークフローの実行時間が倍近くになります。僕のプロジェクトでは、キャッシュありで48秒、なしで1分32秒でした。

マトリクスビルドで複数環境をテストする

ライブラリを公開している場合や、複数のNode.jsバージョンに対応したい場合はマトリクスビルドが便利です。

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test

2つのNode.jsバージョンで並列にテストが走ります。実行時間はほぼ変わらず（並列実行なので）、対応バージョンの安心感が得られます。

自動デプロイを組む：Cloudflare Pages編

テストが通ったら自動でデプロイする——これがCDの本体です。ここではCloudflareのPages環境へのデプロイを例に解説します。

name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          command: pages deploy dist --project-name=my-project

needs: testが肝です。これにより、テストジョブが成功した場合にのみデプロイが実行されます。テストが落ちたらデプロイされない——当たり前のことですが、手動運用だとつい「テスト後で直すからとりあえずデプロイ…」とやりがちなんですよね。

CLOUDFLARE_API_TOKENのようなAPIキーは、リポジトリのSettings → Secrets and variables → Actionsから登録します。ワークフローファイルにトークンを直書きするのは絶対にやめましょう。GitHubが自動検知してくれることもありますが、過信は禁物です。

広告

DMM FX

最大40,000円還元

詳しく見る →

実践で役立つワークフローのテクニック

Lint + テスト + ビルドを並列で回す

テスト・Lint・ビルドの3つを並列に実行し、すべて通ったらデプロイする構成です。直列にするよりトータル時間が短くなります。

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

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: 'npm' }
      - run: npm ci
      - run: npm test

  deploy:
    needs: [lint, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... デプロイ処理

PRにテスト結果をコメントする

テストのカバレッジレポートをPRにコメントとして投稿すると、コードレビュー（セルフレビューでも）の質が上がります。個人開発でも、1週間前の自分のPRを見返すとき地味に助かります。

スケジュール実行でリグレッションを検知

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

依存パッケージのアップデートで壊れていないか、週次でチェックするのに使えます。自分のPagePulse（Web監視ツール）でもこのパターンを使っていて、依存更新によるビルド失敗を2回ほど事前にキャッチできました。

個人開発でありがちなCI/CDのアンチパターン

1. ワークフローを複雑にしすぎる

最初から「Docker buildしてECRにpushしてECSにデプロイして…」みたいな大掛かりなパイプラインを組む人がいますが、個人開発ならテスト→デプロイの2ステップで十分です。複雑さは必要になってから足せばいい。

2. テストがないのにCIだけ組む

ビルドが通ることだけ確認するCIは、あるだけマシですが本質的な安全網にはなりません。最低限、主要な関数のユニットテストを5〜10個書いてからCI化しましょう。

3. シークレットをenvファイルでコミットする

笑い話みたいですが、GitHubで.envを検索すると山ほど出てきます。.gitignoreに.envを入れるのを忘れずに。GitHub Secretsを使いましょう。

GitHub Actions × 個人開発ツールの連携例

CI/CDは単なるテスト・デプロイだけでなく、開発フロー全体を自動化できます。

• リリースノート自動生成 — release-drafterアクションを使えば、マージされたPRからリリースノートを自動作成できます。
• < strong>依存パッケージの自動更新 — Dependabotと組み合わせて、セキュリティアップデートのPRを自動作成→テスト→マージまで自動化。
• ステータスページの更新 — デプロイ後にStatusCraftのようなステータスページへ通知を送り、ユーザーにリリース情報を自動で共有する運用も可能です。
• Chrome拡張のビルド・パッケージング — Chrome拡張のzipファイル生成やChrome Web Store APIへのアップロードもActions上で自動化できます。

Wrangler + GitHub Actionsの落とし穴と対策

Cloudflare WorkersやPagesへのデプロイでwrangler-actionを使う際、ハマりがちなポイントがあります。

• APIトークンの権限不足 — PagesデプロイにはAccount権限の「Cloudflare Pages: Edit」が必要。Zone権限だけだとエラーになります。
• wranglerバージョンの固定 — wranglerVersion: '3.x'を指定しないと、メジャーバージョンアップで突然壊れることがあります。実際、2025年末のv3→v4移行期に遭遇しました。
• ビルド成果物のパス — フレームワークによって出力ディレクトリが異なります（Viteならdist、Next.jsなら.nextなど）。間違えるとデプロイはされるが空ページになります。

まとめ：個人開発のCI/CDは「小さく始める」が鉄則

GitHub Actionsを使ったCI/CDは、個人開発者にとってコストゼロで始められる最強の安全網です。

まずやることは3つだけ：

1. .github/workflows/ci.ymlを作る（テスト自動実行）
2. デプロイ先のAPIトークンをSecretに登録する
3. テスト成功後に自動デプロイするジョブを追加する

15分もあれば基本形は完成します。一度組んでしまえば、あとはコードを書いてpushするだけ。テストもデプロイも勝手にやってくれます。

「そのうち設定しよう」と後回しにすればするほど、手動オペレーションの癖がついて移行が面倒になります。次のプロジェクトではなく、今のプロジェクトで今日始めましょう。