CI/CD入門ガイド2026──GitHub Actionsで始める自動化パイプライン

CI/CDとは──概念を整理する

CI/CDは3つの概念の総称だ。混同されがちだが、それぞれの境界を理解しておくことが重要になる。

概念	正式名	何を自動化するか	ゴール
CI	Continuous Integration	ビルド・テスト	コードが常に統合可能な状態を保つ
CD（デリバリー）	Continuous Delivery	リリース準備	いつでもリリース可能な状態を保つ
CD（デプロイメント）	Continuous Deployment	本番デプロイ	テスト通過後に自動で本番反映

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

CIの核心は「開発者がコードをmainブランチに頻繁にマージし、そのたびに自動テストが走る」仕組みだ。

CIで行うこと	目的
コードのビルド	コンパイルエラーの早期検出
単体テスト	ロジックの正しさを検証
統合テスト	コンポーネント間の連携を検証
リント / フォーマットチェック	コード品質の維持
セキュリティスキャン	脆弱性の早期発見

CIのないチームでは「自分のPCでは動くけど、他の人の環境では動かない」「マージ後に初めてバグが発覚する」といった問題が頻発する。CIはこれらを防ぐ。

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

CDはCIの次のステップで、テスト済みのコードをステージングや本番環境に自動的にデリバリーする。

段階	Continuous Delivery	Continuous Deployment
ステージングへのデプロイ	自動	自動
本番へのデプロイ	手動承認後にデプロイ	テスト通過で自動デプロイ
適するチーム	リリース承認プロセスがあるチーム	高い自動テストカバレッジがあるチーム
リスク	低（人間が最終判断）	低〜中（自動テストへの信頼が必要）

多くの組織はContinuous Deliveryから始め、テスト基盤の成熟に合わせてContinuous Deploymentに移行する。

CI/CDツール比較

2026年のCI/CDツール市場は多様だが、GitHub Actionsの成長が著しい。

ツール	特徴	無料枠	適するケース
GitHub Actions	GitHubネイティブ。YAMLベース	パブリックリポジトリ無制限 / プライベート2,000分/月	GitHub利用チーム（最も人気）
GitLab CI/CD	GitLabネイティブ。Auto DevOps	400分/月	GitLab利用チーム
CircleCI	高速。Docker Layer Caching	6,000分/月（Freeプラン）	複雑なビルドパイプライン
Jenkins	オープンソース。プラグイン豊富	無料（セルフホスト）	オンプレミス・高カスタマイズ
AWS CodePipeline	AWSネイティブ	1パイプライン無料	AWSエコシステム
Azure DevOps	Azureネイティブ。Boards連携	1,800分/月	Microsoft環境
Dagger	コンテナベース。言語非依存	オープンソース	ポータブルなCI

GitHub Actionsの普及により、CI/CDの設定方法は事実上の標準化が進んでいる。GitHubをソースコード管理に使っているなら、GitHub Actionsを第一候補にするのが合理的だ。

GitHub Actionsで始めるCI/CD

基本概念

用語	説明
Workflow	.github/workflows/以下のYAMLファイルで定義する自動化プロセス
Event	ワークフローを起動するトリガー（push, pull_request, schedule等）
Job	ワークフロー内の実行単位。ランナー上で動作
Step	Job内の個々のコマンドまたはAction
Action	再利用可能なステップ（Marketplace公開のものも）
Runner	ジョブを実行するマシン（GitHub提供 or セルフホスト）

CIパイプラインの例（Node.js）

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 run lint
      - run: npm run test
      - run: npm run build

このワークフローは、mainブランチへのpushやPull Requestがトリガーとなり、依存関係のインストール、リント、テスト、ビルドを順番に実行する。いずれかのステップが失敗するとワークフロー全体が失敗し、PRにマージできなくなる。

CDパイプラインの例（Vercelへのデプロイ）

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test     # CIジョブが成功した後に実行
    steps:
      - uses: actions/checkout@v4
      - uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID }}
          vercel-project-id: ${{ secrets.PROJECT_ID }}
          vercel-args: '--prod'

needs: testにより、テストジョブが成功した場合のみデプロイが実行される。secretsにはGitHubリポジトリの設定画面からシークレットを登録する。

Docker Build + Push

jobs:
  build-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

GitHub Container Registry（ghcr.io）へのDockerイメージのビルド＆プッシュは、Kubernetes環境へのデプロイの前段として一般的だ。

CI/CDのベストプラクティス

カテゴリ	プラクティス	効果
速度	テストの並列実行	パイプライン実行時間を50%以上短縮
速度	キャッシュの活用（依存関係、Docker Layer）	ビルド時間の大幅短縮
速度	差分テスト（変更ファイルに関連するテストのみ実行）	不要なテストを排除
信頼性	テストの安定性（Flaky Testの排除）	偽の失敗による開発者の信頼低下を防ぐ
信頼性	Immutableなアーティファクト（Dockerイメージにタグ付け）	環境差異によるバグを防止
セキュリティ	シークレットのCI/CD変数管理	ハードコーディングの防止
セキュリティ	依存関係の脆弱性スキャン	サプライチェーン攻撃の防止
運用	パイプラインのモニタリング	実行時間の劣化を検知
運用	ブランチ保護ルール	CI成功をマージの必須条件に

テストピラミッド

CI/CDにおけるテスト戦略は「テストピラミッド」の考え方が基本だ。

テスト種類	実行速度	カバレッジ	数
単体テスト（Unit）	最速	関数・メソッド単位	最多
統合テスト（Integration）	中速	コンポーネント間連携	中程度
E2Eテスト（End-to-End）	遅い	ユーザーシナリオ全体	少数

単体テストを厚くし、E2Eテストは重要なユーザーフローに限定する。E2Eテストを増やしすぎるとパイプラインの実行時間が長くなり、開発者のフィードバックループが遅くなる。

GitOps──CI/CDの先にある運用モデル

GitOpsはCI/CDの発展形で、Gitリポジトリを「信頼できる唯一の情報源」としてインフラとアプリケーションの状態を管理する手法だ。

比較軸	従来のCI/CD	GitOps
デプロイ方式	CIパイプラインがpush	GitOpsオペレータがpull
状態管理	パイプラインスクリプト内	Gitリポジトリのマニフェスト
ドリフト検知	なし（手動確認）	自動（差分を常時監視）
ロールバック	パイプライン再実行	Gitのrevert
監査証跡	CIログ	Gitコミット履歴

GitOpsの代表的なツールはArgoCDとFluxだ。Kubernetesとの組み合わせで真価を発揮する。Kubernetesの運用について詳しくは「Kubernetes入門ガイド」も参照してほしい。

年収とキャリア

市場	年収レンジ	備考
日本（DevOpsエンジニア）	550万〜1,200万円	CI/CD構築経験者は需要高
日本（SRE）	700万〜1,500万円	CI/CD + 可観測性 + インフラ
日本（フリーランス）	月額65万〜110万円	パイプライン設計・構築
米国	$100K〜$175K	DevOps/Platform Engineer

CI/CDのスキルは「開発者の生産性を上げる」能力であり、組織への貢献度が可視化しやすい。Platform Engineeringの文脈で、社内開発者プラットフォーム（IDP）の構築に関わるキャリアパスも広がっている。

学習ロードマップ

Phase 1：基礎（1-2週間）

学習項目	リソース
Git基本操作	ブランチ、マージ、PRの作成
GitHub Actions入門	GitHub公式ドキュメント
YAMLの書き方	基本構文の理解

Phase 2：実践（3-5週間）

学習項目	プロジェクト例
CIパイプライン構築	テスト自動化 + ビルド
CDパイプライン構築	Vercel / Netlify / AWS へのデプロイ
Docker + CI	イメージビルド + レジストリPush
セキュリティスキャン	Trivy / Snyk統合

Phase 3：応用（6-8週間）

学習項目	目標
GitOps	ArgoCD + Kubernetes
カスタムAction作成	再利用可能なCI/CDコンポーネント
パフォーマンス最適化	キャッシュ戦略、並列実行
マルチ環境デプロイ	dev / staging / production

CI/CDは「一度構築して終わり」ではない。プロジェクトの成長に合わせてパイプラインも進化させる必要がある。テストカバレッジの向上、ビルド時間の短縮、セキュリティチェックの追加──パイプラインの改善は、開発チーム全体の生産性に直結する投資だ。自分のプロジェクトのCI/CDを「育てる」感覚で向き合うことが、DevOpsの本質ではないだろうか。