「テストは書いたけど、毎回手動で実行するのが面倒」「デプロイのたびにコマンドをコピペしてるけど、いつか事故りそう」——個人開発をしていると、こういうモヤモヤって地味にストレスですよね。

僕自身、以前Chrome拡張を開発していたとき、テストを通さずにリリースしてしまい、ユーザーから「動かないんですけど」と報告を受けた苦い経験があります。あのときGitHub ActionsでCI/CDを組んでいれば、防げた事故でした。

この記事では、個人開発者がGitHub Actionsを使ってテスト自動化と自動デプロイを実現する方法を、実際のワークフローファイルを交えながら解説します。

そもそもCI/CDとは何か、30秒で理解する

CI（Continuous Integration）は「コードを変更するたびに自動でテスト・ビルドを実行する仕組み」、CD（Continuous Deployment/Delivery）は「テストを通過したコードを自動で本番環境にデプロイする仕組み」です。

大規模チームの話に聞こえるかもしれませんが、個人開発こそCI/CDの恩恵が大きいです。レビューしてくれる同僚がいない分、自動テストが唯一の防波堤になるからです。

GitHub Actionsの無料枠が個人開発に最適な理由

2026年2月時点で、GitHub Actionsの無料枠はこうなっています：

  • パブリックリポジトリ — 完全無料、制限なし
  • プライベートリポジトリ — 月2,000分（Linux環境）
  • ストレージ — 500MB（アーティファクト・キャッシュ用）

月2,000分というのは、1回のワークフローが平均2分として月1,000回実行できる計算です。個人開発で1日30回以上pushする人はそういないでしょうから、まず足りなくなることはありません。

CircleCIやTravis CIも選択肢ですが、GitHubにリポジトリがあるなら追加のアカウント登録も連携設定も不要なActions一択だと思います。

最初のワークフローを作る：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が自動検知してくれることもありますが、過信は禁物です。

広告スペース

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

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からリリースノートを自動作成できます。
  • 依存パッケージの自動更新 — 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するだけ。テストもデプロイも勝手にやってくれます。

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

🚀 開発の生産性をさらに上げるなら

CI/CDと合わせて、AIコーディングツールを活用すれば開発速度がさらに向上します。テストコードの自動生成やコードレビューの自動化など、2026年ならではの開発体験を試してみてください。

広告スペース