対象試験と出題頻度

継続的デリバリー(CD)は、応用情報技術者試験で出題されるテーマです。

DevOpsやアジャイル開発の流れの中で問われることが多く、継続的インテグレーション(CI)や継続的デプロイメントとの違いを正確に区別できるかが鍵となります。

詳細をクリックして確認
対象試験:
応用情報技術者
出題頻度:
★★☆☆☆
ランクC(応用)余裕があれば覚える

用語の定義

情報処理試験を勉強していると、「継続的デリバリーって、継続的インテグレーションや継続的デプロイメントと何が違うの?」と混乱しがちです。

継続的デリバリー(Continuous Delivery、CD)とは、一言で言うと

 「ソフトウェアをいつでも本番にリリースできる状態に、自動で保ち続ける開発手法

のことです。

イメージとしては、宅配ピザの保温棚です。

注文が入ってからピザを焼き始めるのではなく、焼きたてのピザを保温棚に常に並べておき、注文があった瞬間に届けられる状態を維持する。

これが継続的デリバリーの考え方です。コードに変更が入るたびにビルド・テスト・パッケージングまで自動で済ませ、「本番リリースのGoサインを出すだけ」の状態にしておきます。

📊 継続的デリバリー(CD)の基本情報

項目 内容
英語名 Continuous Delivery(CD)
関連分野 DevOps、アジャイル開発、CI/CDパイプライン
本番反映 手動承認(人がGoサインを出す)
代表ツール Jenkins、GitLab CI/CD、GitHub Actions、CircleCI

解説

従来の開発では、数か月分の変更をまとめて本番にリリースするのが当たり前でした。

リリース直前に大量のバグが見つかり、徹夜で修正する光景もよく見られました。

この「リリースの痛み」を取り除くために生まれた考え方が、小さな変更を頻繁に積み重ね、各段階を自動化して常にリリース可能な状態を保つ継続的デリバリーです。

CI / CD / 継続的デプロイメントの関係

試験で混同しやすいのが、CI・CD・継続的デプロイメントの3つです。

それぞれの担当範囲を一枚の流れで整理します。

CI/CDパイプラインの流れ

コミット

開発者がpush

ビルド

自動コンパイル

自動テスト

単体・結合

リリース準備

パッケージ化

本番反映

デプロイ

◀ CI(継続的インテグレーション)
①〜③:統合とテストの自動化
CD ▶
④まで自動/⑤は手動承認
継続的デプロイメント
⑤まで全自動

整理すると、3つの違いは「自動化がどこまで及ぶか」の一点に集約されます。

用語 自動化の範囲 本番反映
継続的インテグレーション(CI) コードの統合・ビルド・テストまで 対象外
継続的デリバリー(CD) CIに加えてリリース可能な成果物の作成まで 手動承認
継続的デプロイメント CDに加えて本番環境への反映まで 全自動

「Delivery(届ける準備)」と「Deployment(実際に置く)」の語感の違いを思い出すと、両者の境界が頭に残ります。

パイプライン定義の例

実際の現場では、自動化の流れを設定ファイルで定義します。

GitHub Actionsを例に、雰囲気だけ掴んでおきましょう。

# .github/workflows/cd.yml の抜粋
name: CD Pipeline
on:
  push:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci          # 依存関係のインストール
      - run: npm run build   # ビルド
      - run: npm test        # 自動テスト

  release:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/package.sh   # リリース成果物の生成

  deploy-production:
    needs: release
    environment: production         # 手動承認ゲート
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/deploy.sh    # 本番反映(承認後に実行)

ポイントは environment: production の行です。ここで承認者の手動確認を挟むことで、「リリース可能な状態は自動で維持しつつ、本番反映の判断は人間が行う」という継続的デリバリーの本質を実装しています。

承認ゲートを外せば、そのまま継続的デプロイメントになります。

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

💡 継続的デリバリー(CD)の核心を3行で

・小さな変更を頻繁に取り込み、いつでも本番反映できる状態を自動で維持する開発手法
・CIの後工程にあたり、リリース可能な成果物の作成までを自動化する
・本番環境への反映は人間の承認を経る点で、継続的デプロイメントと区別する


試験ではこう出る!

応用情報技術者試験では、DevOpsやアジャイル開発手法の選択肢の一つとしてCI/CDが取り上げられます。CD単独で問われるよりも、CIとセットで「説明文と用語の対応」を答えさせる形式が中心です。

📊 過去問での出題実績

試験回 出題内容 問われたポイント
AP R5秋
午前 問47
継続的インテグレーションの説明として正しいものを選ぶ問題。 ・「ビルドとテストを自動化し短サイクルで実施」が正解
・ノーコード開発・MDA・形式手法がひっかけ
AP H30秋
午後 問8
フリマサービス開発を題材とした継続的インテグレーションの実装に関する長文問題。 ・自動ビルド・自動テストの目的
・ブランチ戦略とマージのタイミング
IP R4
問42
DevOpsの説明として最も適切なものを選ぶ問題。 ・「開発と運用が協力しリリース工程を自動化」が正解
・CI/CDはDevOpsの実践手段として位置づけられる

📝 IPA試験での出題パターン

パターン1:「CI/CDの説明文を選べ」
選択肢にCI、CD、DevOps、ノーコード開発、MDAなどが並び、説明文との対応を問う形式。「ビルドとテストの自動化」=CI、「リリース可能な状態を自動で維持」=CD、と覚えてください。

 

パターン2:「CDと継続的デプロイメントの違い」
本番反映が手動か自動かを問うパターン。「本番への反映に人の承認を挟むのがCD、全自動で本番に出るのが継続的デプロイメント」が分岐点です。

 

試験ではここまででOKです。Blue/Greenデプロイやカナリアリリースまで深追いする必要はありません。


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

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


Q. ソフトウェア開発における継続的デリバリー(CD)の説明として、最も適切なものはどれでしょうか?

  • A. 開発者がコミットしたコードを自動でビルドし、単体テストや結合テストを短サイクルで実行することで、統合時の不具合を早期に発見する手法。
  • B. テストに合格したコードを人の介入なしに本番環境まで自動で反映し、機能追加や修正を即座にエンドユーザーへ届ける手法。
  • C. ビルドとテストを経たソフトウェアをリリース可能な成果物として常に準備しておき、本番反映は承認に基づいて行うことで、いつでも安全にリリースできる状態を維持する手法。

正解と解説を見る

正解:C

解説:
継続的デリバリー(CD)は、CIで検証済みのコードをリリース可能な状態にまで仕上げて待機させ、本番への反映タイミングは人間が判断する仕組みです。「いつでもリリースできる」を自動で保つ点が本質です。

選択肢Aは継続的インテグレーション(CI)の説明です。CIはコード統合とテスト自動化の段階を指し、リリース成果物の準備までは含みません。選択肢Bは継続的デプロイメントの説明です。本番反映まで全自動で行う点でCDと区別されます。


よくある質問(FAQ)

Q. CDが「Continuous Delivery」と「Continuous Deployment」のどちらを指すかは、文脈でどう判断しますか?

本番反映に人の承認が入るかどうかが手がかりになります。「リリース可能な状態を維持する」「いつでも出せる」と書かれていればDelivery、「自動で本番に反映される」「承認なしでリリース」と書かれていればDeploymentです。応用情報試験ではDeliveryの意味で使われるケースが多く、迷ったらDeliveryと解釈して問題ありません。

Q. CDを導入するメリットはリリース速度以外にもありますか?

あります。第一に品質の安定です。小さな変更を頻繁に検証するため、不具合の発生箇所を特定しやすくなります。第二にリスク低減です。1回のリリース規模が小さいため、問題が起きても切り戻しが容易です。第三に開発チームの負荷軽減です。リリース作業が定型化・自動化され、深夜作業や属人的な手順書から解放されます。

Q. すべてのシステムで継続的デプロイメント(全自動本番反映)を採用すべきですか?

ケースバイケースです。Webサービスのような頻繁な改善が価値になる領域では継続的デプロイメントが有効ですが、金融系の基幹システムや医療機器など、本番反映に法令・契約上の承認手続きが必要な領域ではCD(手動承認あり)が現実的です。「自動化のレベルを業務リスクに合わせる」という発想が重要で、闇雲に全自動化を目指すものではありません。

Q. DevOpsとCI/CDは同じものですか?

違います。DevOpsは「開発(Dev)と運用(Ops)が協力して継続的に価値を届ける文化・組織論」であり、CI/CDはそれを技術的に実現する手段の一つです。DevOpsという考え方を実装するためのツール群がCI/CDパイプライン、と整理すると関係がスッキリします。IPA試験ではDevOpsを問う問題(IP R4 問42など)と、CI/CDを問う問題が別々に出題されます。

Q. CDを支える代表的なツールは何ですか?

老舗のJenkins、リポジトリと統合されたGitHub ActionsやGitLab CI/CD、クラウドネイティブなCircleCI、AWS環境向けのAWS CodePipelineなどがあります。試験ではツール名そのものよりも「自動化パイプラインを構築するための仕組み」という概念理解で十分です。実務に進む際は、まず自分のチームが使っているリポジトリサービスに統合された選択肢から触ってみると学習効率が上がります。