継続的インテグレーション（CI）とは？仕組みとメリットをわかりやすく解説【IPA試験対策】

対象試験と出題頻度

継続的インテグレーション（CI）は、基本情報技術者・応用情報技術者で出題されるテーマです。

アジャイル開発やDevOpsの文脈で頻出となっており、「CD（継続的デリバリー／デプロイメント）」「リファクタリング」「テスト駆動開発（TDD）」との違いを正確に区別できるかが問われます。

詳細をクリックして確認

対象試験：
基本情報技術者
応用情報技術者

出題頻度：
★★★☆☆
ランクB（標準）覚えておくと有利

用語の定義

情報処理試験を勉強していると、「継続的インテグレーションって、結局なにを”継続”してるの？」と混乱しがちです。

継続的インテグレーション（Continuous Integration / CI）とは、一言で言うと

　「開発者がコード変更を頻繁に共有リポジトリへ統合し、ビルドとテストを自動実行する開発プラクティス」

のことです。

イメージとしては、「毎日少しずつ片付ける部屋」です。

掃除を半年に一度まとめてやろうとすると、ホコリが積もりすぎて手がつけられません。

一方、毎日5分ずつ片付ければ、汚れは小さなうちに発見でき、対処も簡単です。

CIも同じで、コードの変更を「ためずに」「こまめに」統合してチェックすることで、不具合を早期に発見し、後からまとめて直す苦しみを避ける手法です。

解説

従来のウォーターフォール開発では、各メンバーが数週間〜数か月かけて自分の担当機能を作り込み、最後に一気に統合していました。

この方式では、統合段階で大量のコンフリクト（競合）やバグが噴出し、修正に膨大な工数を要する「統合地獄（Integration Hell）」が頻発していたのです。

この課題を解決するために、エクストリームプログラミング（XP）の中核的プラクティスとして提唱されたのがCIです。

CIパイプラインの流れ

CIは「コードをコミットしてから自動チェックが完了するまで」を一連のパイプラインとして構成します。

設定ファイルのイメージ（GitHub Actions）

実際のCIは、リポジトリに置いた設定ファイルを読み取って自動実行されます。雰囲気をつかむための例を示します。

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build   # ← ②ビルド
      - run: npm test        # ← ③自動テスト

「pushされたら、Node環境を用意して、依存をインストールし、ビルドとテストを実行する」という流れが、わずかなYAMLで自動化されているわけです。

CIで得られる4つのメリット

CI／CD／継続的デプロイメントの違い

CIと混同されやすいのが「CD」です。両者は一連の自動化パイプラインを構成しますが、対象範囲が異なります。

CIはあくまで「統合とテストの自動化」に焦点を絞った概念であり、その下流にある「リリース工程の自動化」はCDの担当領域です。

では、この用語が試験でどのように出題されるか見ていきましょう。

---

試験ではこう出る！

CIは、FE・APの午前問題で「アジャイル開発のプラクティス」「DevOps関連用語」のテーマとして繰り返し出題されています。

---

【確認テスト】理解度チェック

ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。

---

---

よくある質問（FAQ）