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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主要CI/CDツールの比較

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

GitHub Actionsの料金体系

重要なポイントとして、パブリックリポジトリでは完全無料・無制限で使えます。 個人開発でオープンソースとして公開する場合は、料金を一切気にする必要がありません。 プライベートリポジトリでも、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にはマーケットプレイスがあり、 コミュニティが作った再利用可能なアクションを使えます。 個人開発でよく使うアクションを紹介します。

個人開発の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、セキュリティスキャンまで含めた本格的な構成です。 サービスが成長してきた段階で導入を検討しましょう。

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

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

実践：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()
})

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

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

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

テストカバレッジの目安

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

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

npx vitest run --coverage

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エラーのパターンと解決策をまとめます。

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を自分のプロジェクトに導入してみたいけど、一人では不安」という方は、 ぜひ無料相談会にご参加ください。