---
title: "個人開発のCI/CD入門【GitHub Actions完全ガイド】"
description: "GitHub Actionsを使った個人開発のCI/CD入門。無料で始める自動テスト・リント・デプロイの構築方法を、Next.js×Vercelの実践例付きで徹底解説します。"
url: "https://shiftb.dev/articles/indie-dev-cicd-guide"
publishedAt: "2026-04-07"
updatedAt: "2026-04-07"
author: "立川修平（ぶべ）"
category: "tools"
tags: ["CI/CD", "GitHub Actions", "個人開発", "自動化", "DevOps"]
---

# 個人開発のCI/CD入門【GitHub Actions完全ガイド】

「手動でデプロイするたびにミスが怖い」「テストを忘れて本番でバグが出た」——ShiftBの無料相談会で、個人開発経験者の**約65%**がデプロイやテストの手動作業に不安を抱えています。実際、ShiftB受講生のデータでは、手動デプロイに起因する本番障害が**全障害の約40%**を占めていました。

CI/CD（継続的インテグレーション/継続的デリバリー）を導入すれば、こうした手動作業のミスを**ほぼゼロ**にできます。GitHub Actionsなら**月2,000分の無料枠**があり、個人開発では実質無料で使えます。「大規模チーム向けの仕組みでしょ？」と思うかもしれませんが、実は**個人開発こそCI/CDの恩恵が大きい**のです。

僕自身、ShiftBのサイトや複数の個人開発サービスでGitHub Actionsを活用しており、CI/CD導入後はデプロイにかかる時間が**1回あたり15分→2分**に短縮されました。年間で換算すると**約50時間**の節約です。

この記事では、ShiftB校長として**150名以上の受講生**をサポートしてきた経験から、個人開発者が**今日から始められるCI/CD入門**を、GitHub Actionsの基礎からNext.js × Vercelの実践的なパイプライン構築まで徹底解説します。

## なぜ個人開発にCI/CDが必要なのか

「一人で開発しているのにCI/CDなんて大げさじゃない？」——そう思う方は多いでしょう。しかし、**一人だからこそCI/CDが必要**なのです。チーム開発ならレビューやQAの工程で誰かがミスに気づいてくれますが、個人開発では**すべてのミスを自分一人で防がなければなりません**。

### 手動デプロイの3つのリスク

個人開発で手動デプロイを続けていると、以下のリスクが常につきまといます。

| リスク | 具体例 | 発生頻度（ShiftB受講生データ） |
| --- | --- | --- |
| ヒューマンエラー | 環境変数の設定忘れ、ビルドコマンドの打ち間違い | 月1〜2回 |
| テスト漏れ | ローカルでテストせずにデプロイ、型エラーの見落とし | 月2〜3回 |
| 時間の浪費 | 毎回同じ手順を手動で実行、デプロイ待ちの非生産時間 | 毎デプロイ（15〜20分） |

### CI/CD導入のビフォーアフター

実際にCI/CDを導入した受講生のデータを見てみましょう。ShiftBの受講生**32名**にCI/CD導入前後の変化をヒアリングした結果です。

| 指標 | CI/CD導入前 | CI/CD導入後 | 改善率 |
| --- | --- | --- | --- |
| デプロイ1回あたりの時間 | 15〜20分 | 2〜3分（自動） | **85%短縮** |
| 本番障害（月平均） | 2.1件 | 0.3件 | **86%削減** |
| デプロイ頻度（週平均） | 2.3回 | 8.7回 | **3.8倍** |
| コードレビューの安心感 | 不安 | 自信あり | — |

### 個人開発者にとっての最大のメリット

CI/CDの最大のメリットは**「心理的安全性」**です。「pushしたら自動でテストが走り、問題なければ勝手にデプロイされる」——この安心感は、個人開発のモチベーション維持に直結します。

特に副業や週末だけ開発する方にとって、久しぶりにコードを触ったときに「デプロイってどうやるんだっけ？」と思い出す時間がゼロになるのは大きなメリットです。**開発に集中できる環境を自動化で作る**——これがCI/CDの本質です。

### 「一人だから不要」は誤解

よくある誤解として「CI/CDはチーム開発で効果を発揮するもの」というものがあります。確かにチーム開発ではコードの統合テストが重要ですが、個人開発でも以下の場面でCI/CDは効果を発揮します。

- **リファクタリング時**：テストが自動で走るので、既存機能の破壊に即座に気づける
- **依存パッケージの更新時**：ビルドが通るかを自動確認できる
- **複数環境の管理**：開発環境・ステージング・本番を自動で切り替え
- **長期メンテナンス**：半年後に戻ってきても同じ手順で確実にデプロイ

## CI/CDの基本概念 — 初心者でもわかる仕組み解説

CI/CDは**「Continuous Integration / Continuous Delivery（Deployment）」**の略称です。日本語にすると「継続的インテグレーション / 継続的デリバリー（デプロイメント）」。横文字が多くて難しそうに見えますが、やっていることはシンプルです。

### CI（継続的インテグレーション）とは

CIは**「コードを変更したら、自動でテストやチェックを実行する仕組み」**です。具体的には以下の処理を自動で行います。

- **ビルドチェック**：コードが正しくコンパイル/ビルドできるか
- **テスト実行**：ユニットテスト、統合テストの自動実行
- **リントチェック**：コーディング規約に違反していないか
- **型チェック**：TypeScriptの型エラーがないか

料理に例えるなら、CIは**「レシピ通りに作れているかを毎回自動で味見してくれるロボット」**です。材料（コード）を入れるたびに、味（品質）が崩れていないか確認してくれます。

### CD（継続的デリバリー/デプロイメント）とは

CDには2つの意味があります。

| 用語 | 意味 | 個人開発での使い方 |
| --- | --- | --- |
| **Continuous Delivery** | テスト通過後、デプロイ可能な状態まで自動で準備 | 手動で最終確認してからデプロイ |
| **Continuous Deployment** | テスト通過後、本番環境まで自動でデプロイ | mainブランチにマージ→即デプロイ |

個人開発では**Continuous Deployment（完全自動デプロイ）**を採用するケースが多いです。一人で開発しているので、CIのチェックさえ通れば手動の最終承認は不要という判断です。Vercelを使っている場合、mainブランチにpushするだけで自動デプロイされるので、すでにCDを実践していることになります。

### CI/CDパイプラインの全体像

CI/CDパイプラインとは、コードの変更から本番デプロイまでの**一連の自動化された工程**のことです。個人開発の典型的なパイプラインは以下の通りです。

```
コードをpush
  → リントチェック（ESLint）
    → 型チェック（TypeScript）
      → テスト実行（Jest/Vitest）
        → ビルド確認
          → デプロイ（Vercel/Netlify）
```

この一連の流れが**毎回自動で実行される**のがCI/CDの威力です。一度設定すれば、あとはコードを書いてpushするだけ。残りはすべて自動化されます。

![CI/CDパイプラインの全体像 — コードのpushからデプロイまでの自動化フロー図](https://shiftb.dev/images/articles/indie-dev-cicd-guide-pipeline.png)

### CI/CDと関連する用語の整理

CI/CDを学ぶ際に出てくる用語を整理しておきましょう。

| 用語 | 意味 | 具体例 |
| --- | --- | --- |
| **ワークフロー** | CI/CDの自動化手順をまとめた設定ファイル | `.github/workflows/ci.yml` |
| **ジョブ** | ワークフロー内の実行単位 | lint、test、buildなど |
| **ステップ** | ジョブ内の個々のコマンド | `npm run lint` |
| **トリガー** | ワークフローを開始する条件 | push、pull_request |
| **ランナー** | ワークフローを実行するサーバー | ubuntu-latest |
| **アーティファクト** | ワークフローで生成された成果物 | ビルド済みファイル、テストレポート |

## GitHub Actionsの基礎知識と料金プラン

CI/CDツールはいくつかありますが、個人開発には**GitHub Actions一択**と言っても過言ではありません。GitHubでコードを管理しているなら、追加のサービス登録やインフラ構築は不要で、リポジトリ内にYAMLファイルを置くだけで始められます。

### 主要CI/CDツールの比較

| ツール | 無料枠 | GitHubとの連携 | 学習コスト | 個人開発との相性 |
| --- | --- | --- | --- | --- |
| **GitHub Actions** | 2,000分/月 | ネイティブ | 低 | ★★★ |
| CircleCI | 6,000分/月 | API連携 | 中 | ★★☆ |
| GitLab CI | 400分/月 | GitLab専用 | 中 | ★★☆ |
| Jenkins | 無料（自前サーバー） | プラグイン | 高 | ★☆☆ |
| AWS CodePipeline | 1パイプライン無料 | API連携 | 高 | ★☆☆ |

GitHub Actionsの無料枠は**月2,000分**（パブリックリポジトリは無制限）。個人開発のCI/CDパイプラインは1回あたり**2〜5分**で完了するので、月400〜1,000回実行できる計算です。**個人開発で使い切ることはまずありません**。

### GitHub Actionsの料金体系

| プラン | 無料枠（分/月） | ストレージ | 月額 |
| --- | --- | --- | --- |
| **Free** | 2,000分 | 500MB | $0 |
| Team | 3,000分 | 2GB | $4/ユーザー |
| Enterprise | 50,000分 | 50GB | $21/ユーザー |

重要なポイントとして、**パブリックリポジトリでは完全無料・無制限**で使えます。個人開発でオープンソースとして公開する場合は、料金を一切気にする必要がありません。プライベートリポジトリでも、Freeプランの2,000分で十分すぎるほどです。

### ワークフローファイルの基本構造

GitHub Actionsのワークフローは、リポジトリの`.github/workflows/`ディレクトリにYAMLファイルを置くだけで設定できます。基本構造を見てみましょう。

```
# .github/workflows/ci.yml
name: CI

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

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm run test
      - run: npm run build
```

たった**20行程度**で、リント・型チェック・テスト・ビルドの自動化が完了します。これをリポジトリにpushすれば、次回のpushやPRから自動的にCI/CDが動き始めます。

### よく使うアクション（actions）

GitHub Actionsには**マーケットプレイス**があり、コミュニティが作った再利用可能なアクションを使えます。個人開発でよく使うアクションを紹介します。

| アクション | 用途 | 使用例 |
| --- | --- | --- |
| `actions/checkout@v4` | リポジトリのコードを取得 | ほぼすべてのワークフローで必須 |
| `actions/setup-node@v4` | Node.js環境のセットアップ | Next.js/Reactプロジェクト |
| `actions/cache@v4` | 依存パッケージのキャッシュ | CI実行時間の短縮 |
| `vercel/action` | Vercelへのデプロイ | Next.jsアプリのデプロイ |
| `actions/upload-artifact@v4` | ビルド成果物の保存 | テストレポートの保存 |

## 個人開発のCI/CDパイプライン設計パターン

CI/CDの仕組みを理解したところで、個人開発に最適なパイプラインの設計パターンを紹介します。チーム開発とは異なり、個人開発では**シンプルさと速度のバランス**が重要です。

### パターン1：ミニマル構成（初心者向け）

CI/CD初心者が最初に構築すべき、**最小限の構成**です。設定時間は**約10分**。

```
# .github/workflows/ci.yml
name: CI

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

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

これだけで「pushしたらビルドが通るか自動チェック」が実現します。ビルドエラーがあればGitHub上で赤い×マークが表示されるので、**壊れたコードがmainブランチに入ることを防げます**。

### パターン2：標準構成（おすすめ）

リント・型チェック・テスト・ビルドを**並列実行**する構成です。個人開発のほとんどのプロジェクトに適しています。設定時間は**約20分**。

```
# .github/workflows/ci.yml
name: CI

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

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

  type-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx tsc --noEmit

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

  build:
    needs: [lint, type-check, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
```

ポイントは`needs`キーワードです。lint・型チェック・テストの3つが**並列で実行**され、すべて成功した場合のみビルドが実行されます。並列化により、全体の実行時間は**直列の約60%**に短縮できます。

### パターン3：フル構成（本格運用向け）

E2Eテスト、Lighthouse CI、セキュリティスキャンまで含めた**本格的な構成**です。サービスが成長してきた段階で導入を検討しましょう。

| 構成要素 | ツール | 目的 | 実行タイミング |
| --- | --- | --- | --- |
| リント | ESLint + Prettier | コード品質の統一 | push/PR |
| 型チェック | TypeScript | 型安全の保証 | push/PR |
| ユニットテスト | Vitest | 個別機能の検証 | push/PR |
| E2Eテスト | Playwright | ユーザー操作の検証 | PR/main push |
| パフォーマンス | Lighthouse CI | Core Web Vitals監視 | main push |
| セキュリティ | npm audit | 脆弱性検出 | 週次スケジュール |
| デプロイ | Vercel | 本番環境反映 | main push |

### どのパターンから始めるべきか

僕のおすすめは、まず**パターン1（ミニマル構成）**から始めて、1〜2週間使ってみてから**パターン2（標準構成）**に拡張するアプローチです。ShiftBの受講生にもこの段階的な導入をおすすめしており、**約85%の受講生がパターン2で十分**と回答しています。

![CI/CDパイプライン設計パターンの比較 — ミニマル・標準・フルの3段階](https://shiftb.dev/images/articles/indie-dev-cicd-guide-patterns.png)

## 実践：Next.js × Vercelの自動デプロイを構築する

ここからは実際に手を動かしてCI/CDパイプラインを構築していきます。ShiftBの技術スタックでもある**Next.js × Vercel**の構成で解説します。所要時間は**約30分**です。

### ステップ1：Vercelのデプロイ設定を確認する（所要時間：5分）

Next.jsプロジェクトをVercelに接続している場合、**mainブランチへのpushで自動デプロイ**がデフォルトで有効になっています。これだけでCDは実現していますが、CIが不足しています。つまり、テストやリントチェックなしにデプロイされてしまう状態です。

まず、Vercelのプロジェクト設定で以下を確認しましょう。

- **Framework Preset**：Next.jsが選択されていること
- **Build Command**：`next build`（デフォルト）
- **Output Directory**：`.next`（デフォルト）
- **Node.js Version**：20.x（LTSを推奨）

### ステップ2：CIワークフローを作成する（所要時間：10分）

リポジトリのルートに`.github/workflows/ci.yml`を作成します。

```
# .github/workflows/ci.yml
name: CI

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  ci:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Test
        run: npm run test -- --passWithNoTests

      - name: Build
        run: npm run build
```

注目ポイントは`concurrency`の設定です。同じブランチで連続pushした場合、**前の実行をキャンセルして最新のみ実行**します。これにより、無駄な実行時間（＝無料枠の消費）を抑えられます。

### ステップ3：PRでのプレビューデプロイを活用する（所要時間：5分）

Vercelでは、PRを作成すると自動で**プレビューURL**が発行されます。これはGitHub Actionsとは別にVercelが自動で行うので、追加の設定は不要です。

開発フローは以下のようになります。

```
1. featureブランチで開発
2. PRを作成
   → GitHub Actions: リント・テスト・型チェック・ビルド（CI）
   → Vercel: プレビューURLを自動生成（CD）
3. CIが全部グリーンなのを確認
4. PRをマージ
   → Vercel: 本番環境に自動デプロイ（CD）
```

この流れなら、**壊れたコードが本番に出ることはありません**。個人開発でもこのブランチ戦略を採用することを強くおすすめします。

### ステップ4：環境変数を安全に管理する（所要時間：10分）

CI/CDで環境変数を扱う際は、**GitHub Secrets**を使います。リポジトリの Settings → Secrets and variables → Actions から設定できます。

```
# ワークフロー内での環境変数の使い方
jobs:
  ci:
    runs-on: ubuntu-latest
    env:
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
      NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}
    steps:
      # ...
```

**絶対にやってはいけないこと**は、環境変数をYAMLファイルに直接書くことです。YAMLファイルはリポジトリにコミットされるため、APIキーやデータベースURLが漏洩します。必ずGitHub Secretsを使いましょう。

## 実践：自動テスト・リント・型チェックを導入する

デプロイの自動化ができたら、次はCIの要である**品質チェックの自動化**です。「テストを書くのは面倒」と感じるかもしれませんが、個人開発こそ**最小限のテストで最大限の安心感**を得るべきです。

### ESLintの設定（所要時間：5分）

Next.jsプロジェクトを`create-next-app`で作成した場合、ESLintの設定はすでに含まれています。`package.json`に以下のスクリプトがあるか確認しましょう。

```
{
  "scripts": {
    "lint": "next lint"
  }
}
```

`next lint`はNext.js専用のESLint設定で、**React Hooks のルール違反**や**アクセシビリティの問題**も検出してくれます。個人開発レベルではこれで十分です。追加のESLintプラグインは必要に応じて導入しましょう。

### TypeScriptの型チェック（所要時間：3分）

TypeScriptを使っている場合、`package.json`に型チェック用のスクリプトを追加します。

```
{
  "scripts": {
    "type-check": "tsc --noEmit"
  }
}
```

`--noEmit`オプションは「型チェックだけ行い、ファイル出力はしない」という意味です。CIでは型エラーの検出だけできればOKなので、このオプションをつけます。型チェックは**ビルド前に行う最も効果的な品質チェック**です。ShiftBの受講生データでは、型チェックの自動化だけで本番バグが**約30%減少**しました。

### Vitestでユニットテストを導入する（所要時間：15分）

2026年現在、Next.jsプロジェクトのテストフレームワークには**Vitest**がおすすめです。JestよりもESM対応が優れており、実行速度も**2〜3倍高速**です。

```
# インストール
npm install -D vitest @vitejs/plugin-react jsdom @testing-library/react @testing-library/jest-dom
```

```
// vitest.config.ts
import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom',
    setupFiles: './vitest.setup.ts',
    include: ['**/*.test.{ts,tsx}'],
  },
})
```

```
// vitest.setup.ts
import '@testing-library/jest-dom'
```

テストの書き方の良い例・悪い例を見てみましょう。

```
// ❌ 悪い例：実装の詳細をテストしている
test('state が更新される', () => {
  const { result } = renderHook(() => useState(0))
  act(() => result.current[1](1))
  expect(result.current[0]).toBe(1)
})

// ✅ 良い例：ユーザーの振る舞いをテストしている
test('カウンターのボタンをクリックすると数値が増える', () => {
  render(<Counter />)
  const button = screen.getByRole('button', { name: '増やす' })
  fireEvent.click(button)
  expect(screen.getByText('1')).toBeInTheDocument()
})
```

テストは**ユーザーの振る舞い**を中心に書くのがポイントです。内部実装の詳細をテストすると、リファクタリングのたびにテストが壊れて保守コストが膨らみます。

### 個人開発で「テストすべき場所」の優先順位

個人開発では時間が限られるので、**テストの費用対効果**を意識しましょう。すべてをテストする必要はありません。

| 優先度 | テスト対象 | 理由 | テスト例 |
| --- | --- | --- | --- |
| **★★★** | ビジネスロジック | 収益に直結する計算処理 | 料金計算、ポイント付与 |
| **★★★** | ユーティリティ関数 | 多くの場所から呼ばれる共通処理 | 日付フォーマット、バリデーション |
| **★★☆** | APIレスポンスの加工 | 外部APIの変更に気づける | レスポンスの型変換 |
| **★☆☆** | UIコンポーネント | 見た目は目視確認でも十分 | ボタンの表示切り替え |
| **☆☆☆** | CSSスタイル | テストのコスパが悪い | — |

### テストカバレッジの目安

個人開発での理想的なテストカバレッジは**40〜60%**です。100%を目指す必要はありません。重要なのは**壊れたら困る部分**が確実にテストされていることです。

カバレッジの確認は以下のコマンドで行えます。

```
npx vitest run --coverage
```

![個人開発のテスト優先度マトリクス — コストと効果のバランスを視覚化](https://shiftb.dev/images/articles/indie-dev-cicd-guide-testing.png)

## AI駆動開発でCI/CDを加速する方法

ここまでCI/CDの基本を解説してきましたが、2026年の個人開発では**AIを活用してCI/CDの構築・運用を効率化**できます。Claude Codeを使えば、ワークフローファイルの作成からテストコードの生成まで、大幅に時間を短縮できます。

### Claude Codeでワークフローを自動生成する

Claude Codeは、プロジェクトの構成を理解した上で最適なCI/CDワークフローを提案してくれます。以下のようなプロンプトで依頼できます。

```
# Claude Codeへの依頼例
「このNext.jsプロジェクトにGitHub ActionsのCIワークフローを作成して。
lint、型チェック、テスト、ビルドを並列で実行して、
キャッシュも効かせてほしい」
```

Claude Codeは`package.json`やプロジェクト構成を自動で読み取り、そのプロジェクトに最適化されたワークフローファイルを生成してくれます。手動で書くと**20〜30分かかる作業が5分で完了**します。

### テストコードをAIで生成する

「テストを書くのは面倒」という個人開発者の最大の障壁も、AIで解消できます。Claude Codeに既存のコードを読ませて、テストコードを生成させましょう。

```
# Claude Codeへの依頼例
「src/utils/price.ts のユニットテストを書いて。
正常系、異常系、境界値をカバーしてほしい」
```

AIが生成したテストコードをそのまま使うのではなく、**必ず自分の目で確認してから採用**しましょう。特に境界値やエッジケースのテストは、ビジネスロジックを理解している開発者自身がレビューすべきです。

### CIエラーのデバッグにAIを活用する

CIが失敗したとき、エラーログを読み解くのは初心者にとって大変です。GitHub Actionsのログをそのままコピーしてクロードに貼り付けるだけで、**原因と解決策を教えてくれます**。

```
# Claude Codeへの依頼例
「GitHub ActionsのCIが以下のエラーで失敗しています。原因と修正方法を教えて。

Error: Cannot find module '@/components/Button'
...（エラーログ）」
```

よくあるCIエラーのパターンと解決策をまとめます。

| エラーパターン | 原因 | 解決策 |
| --- | --- | --- |
| `Cannot find module` | パスエイリアスがCI環境で解決できない | `tsconfig.json`のpaths設定を確認 |
| `ENOMEM` | メモリ不足 | `NODE_OPTIONS=--max-old-space-size=4096`を設定 |
| `npm ci`失敗 | `package-lock.json`と`package.json`の不整合 | ローカルで`npm install`してlockファイルを更新 |
| テスト失敗（ローカルでは通る） | 環境変数の未設定、タイムゾーンの差異 | GitHub Secretsに環境変数を追加 |
| `Rate limit exceeded` | 外部APIの呼び出しが多すぎる | テストをモック化する |

### CLAUDE.mdにCI/CDの設定を記載する

Claude Codeを日常的に使っている場合、プロジェクトの`CLAUDE.md`にCI/CDの設定方針を記載しておくと、AIが自動的にCI/CDを意識したコードを生成してくれます。

```
# CLAUDE.md に追記する例
## CI/CD
- GitHub Actionsでlint、型チェック、テスト、ビルドを自動実行
- mainブランチへのpushでVercelに自動デプロイ
- テストフレームワーク: Vitest
- 新しい関数を作成したら、対応するテストも作成すること
```

## よくある質問（FAQ）

### Q1. GitHub Actionsの無料枠を使い切ることはありますか？

個人開発では**ほぼありません**。Freeプランの月2,000分は、1回3分のCIを**月666回**実行できる計算です。毎日20回pushしても月600回で、まだ余裕があります。ただし、E2Eテスト（Playwright）を含めると1回10分以上かかることがあるので、その場合はmain pushのみに制限するなど工夫しましょう。なお、パブリックリポジトリなら**完全無制限**です。

### Q2. テストを書いたことがないのですが、CI/CDは導入できますか？

**もちろんできます**。テストなしでも、リント・型チェック・ビルドの自動化だけで十分な価値があります。まずはビルドチェックだけのミニマル構成から始めて、慣れてきたら少しずつテストを追加していくアプローチがおすすめです。`--passWithNoTests`オプションを使えば、テストファイルがなくてもCIは通ります。

### Q3. Vercelを使っているなら、GitHub Actionsは不要では？

Vercelの自動デプロイ（CD）だけだと、**CIが不足**しています。Vercelはビルドが通れば自動デプロイしますが、リントエラーや型エラーがあってもビルドさえ通ればデプロイされてしまいます。GitHub ActionsでCIを設定しておけば、**品質チェックを通過したコードだけ**がデプロイされるようになります。

### Q4. GitHub Actionsが遅い場合、どうすれば速くなりますか？

以下の**3つの最適化**が効果的です。

- **npm ciのキャッシュ**：`actions/setup-node@v4`の`cache: 'npm'`を設定する（これだけで**30〜50%高速化**）
- **ジョブの並列化**：lint・型チェック・テストを別ジョブで並列実行
- **concurrencyの設定**：同じブランチの古い実行をキャンセルして無駄を排除

### Q5. CI/CDの設定ファイルを他のプロジェクトでも使い回せますか？

**使い回せます**。GitHub Actionsのワークフローファイルをテンプレートとして保存しておけば、新しいプロジェクトにコピーするだけでCI/CDが動きます。Node.jsのバージョンやスクリプト名が異なる場合は調整が必要ですが、基本構造は同じです。また、GitHub Actionsには**Reusable Workflows**という機能があり、共通のワークフローを別リポジトリから呼び出すことも可能です。

### Q6. プライベートリポジトリでもGitHub Actionsは使えますか？

**使えます**。Freeプランでも月2,000分まで無料で使えます。個人開発サービスのソースコードは通常プライベートリポジトリで管理するので、この無料枠をそのまま活用できます。2,000分を超えた場合は**$0.008/分**の従量課金になりますが、個人開発で超えることはまずないでしょう。

### Q7. CI/CDを学ぶのにおすすめのリソースはありますか？

**GitHub公式ドキュメント**が最も信頼できるリソースです。日本語にも対応しており、ステップバイステップのチュートリアルも充実しています。また、GitHub Actionsのマーケットプレイスでは、人気のアクションのREADMEにワークフローのサンプルが載っているので、それをコピーして改変するのが最速の学習法です。ShiftBの受講生には、まず本記事のパターン2（標準構成）を実装してから、公式ドキュメントで応用知識を学ぶルートをおすすめしています。

## まとめ

CI/CDは「大規模チーム向けの仕組み」ではなく、**個人開発者こそ最大の恩恵を受ける自動化技術**です。本記事の内容をおさらいしましょう。

- **CI/CDで手動作業のミスをゼロにできる**——デプロイ障害の約40%は手動ミスが原因
- **GitHub Actionsは個人開発に最適**——月2,000分の無料枠で実質無料
- **まずはミニマル構成から始める**——ビルドチェックだけでも十分な価値がある
- **テストは費用対効果を意識する**——ビジネスロジックを優先的にテスト
- **AIを活用してCI/CDの構築を加速**——Claude Codeでワークフローもテストも自動生成

CI/CDの導入は、個人開発の**「開発体験（Developer Experience）」を劇的に向上**させます。一度設定すれば、あとは**コードを書いてpushするだけ**。テスト、リント、型チェック、デプロイ——すべてが自動で実行されます。

ShiftBでは、AI駆動開発の基礎からCI/CDの実践まで、個人開発に必要な技術を**体系的に学べるカリキュラム**を提供しています。「CI/CDを自分のプロジェクトに導入してみたいけど、一人では不安」という方は、ぜひ無料相談会にご参加ください。