CI/CDとは何か？クラウドエンジニアが知るべきデプロイ自動化の基礎とAWS・Azure主要サービス比較

手動でファイルをサーバーに転送してアプリを再起動、チェック項目を一つひとつ確認しながらリリース——そんなデプロイ作業を繰り返しているエンジニアは今も少なくありません。クラウド移行を進めると「CI/CDを整備するのが当然」という話になりますが、何をどう自動化するのか、AWSやAzureで何を使えばいいのかが体系的に理解できていないと、ツール選定でつまずきます。

この記事では、CI/CDの概念から始まり、AWS・Azureそれぞれのサービス構成と比較、現場でよくあるトラブルと対処法まで、オンプレ経験のあるインフラエンジニアが現場ですぐ使える知識として整理します。

なぜCI/CDが必要なのか？手動デプロイの限界とクラウド時代の変化

オンプレ時代は、リリース作業を担当者が手順書を見ながら手動で行うことが珍しくありませんでした。SSH接続でソースコードを更新し、アプリを再起動して動作確認してから「本番反映OK」と連絡する——月に1度か2度のリリースであれば、それでもなんとか回っていました。

ところがクラウド移行を機に開発サイクルが大きく変化します。マイクロサービスやコンテナの普及で、アプリの更新頻度が週1回・1日1回、場合によっては1日に何十回にも増えます。手動作業では物理的に追いつかなくなるだけでなく、「ヒューマンエラー」が常につきまといます。手順書の読み間違い、環境変数の設定漏れ、確認のし忘れ——本番障害の原因を辿ると手動デプロイに行き着くケースは後を絶ちません。

CI/CDは「コードを変更したら自動でテストしてデプロイするしくみ」です。手順を自動化することでヒューマンエラーを排除し、リリース速度を上げ、品質を担保する——これが現代のインフラ運用においてCI/CDが不可欠になった理由です。

オンプレからクラウドへ移行するタイミングで、デプロイ方式を「手動から自動」に切り替えることは、単なる効率化ではなく、インフラ運用全体の信頼性向上に直結します。

CI/CDの基本概念を理解する

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

CI（Continuous Integration、継続的インテグレーション）は、コードが変更されるたびに自動でビルドとテストを実行するプラクティスです。

・開発者がGitにコードをpushする
・自動でビルド（コンパイル・パッケージング）が走る
・ユニットテスト・結合テストが自動実行される
・テスト結果がSlackやメールで開発者に通知される

オンプレ時代は「週次のビルド」や「月次のテスト実施」が当たり前でした。CIを導入すると、バグを「コードが書かれた直後」に検出できます。後工程になるほど修正コストは指数関数的に増えるため、早期検出の効果は絶大です。

2. CD（継続的デリバリー）と継続的デプロイメントの違い

CDには2つの意味があり、現場では混同されがちです。

現場での選択基準としては、金融・医療・官公庁などリリース承認フローが求められる環境では継続的デリバリーを選び、SaaS・ECサイト・スタートアップなどスピード重視の環境では継続的デプロイメントを選ぶのが一般的です。

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

「パイプライン」とは、コードのpushから本番デプロイまでの一連の処理フローです。典型的な構成は以下のようになります。

# 典型的なCI/CDパイプラインのステージ
# Step 1: Source
#   Gitへのpushまたはプルリクエストをトリガーに起動
#
# Step 2: Build
#   ソースコードのビルド・依存関係の解決・コンテナイメージのビルド
#
# Step 3: Test
#   ユニットテスト・結合テスト・セキュリティスキャン
#
# Step 4: Deploy to Staging
#   ステージング環境への自動デプロイと動作確認
#
# Step 5: Approve（オプション）
#   担当者による手動承認（継続的デリバリーの場合）
#
# Step 6: Deploy to Production
#   本番環境へのデプロイ（Blue/Green または ローリング）

各ステップを自動化することで、人間は「コードを書く」と「承認する」だけに集中できます。

AWSのCI/CDサービス一覧

AWSには、CI/CDパイプラインを構成するためのマネージドサービスが複数あります。それぞれの役割を把握してから組み合わせるのが正しい理解の仕方です。

1. AWS CodePipeline

AWS CodePipelineはパイプライン全体の「司令塔」となるサービスです。ソースコードのpushを検知して、ビルド・テスト・デプロイの各ステージを順番に実行します。Jenkinsの「ジョブ連携」をマネージドサービスに置き換えたイメージで捉えると理解しやすいです。

・ソース接続: GitHub、AWS CodeCommit、Amazon S3などを接続可能
・ステージ構成: AWS CodeBuild・CodeDeployを各ステージに組み合わせる
・手動承認: パイプラインに承認ステップを挿入してゲートウェイを設定できる
・料金: アクティブなパイプライン1本あたり1.00USD/月（2026年3月時点）

2. AWS CodeBuild

AWS CodeBuildは、ビルドとテストを実行するマネージドサービスです。オンプレでJenkinsサーバーを自分で管理していたエンジニアにとっては、そのビルドエージェント部分をクラウドに移した存在として理解するとわかりやすいです。

・ビルド定義: buildspec.ymlというYAMLファイルでビルド手順を記述
・対応ランタイム: Node.js・Python・Java・Go・.NETなど主要言語に対応
・コンテナ対応: DockerイメージのビルドとAmazon ECRへのpushも可能
・料金: ビルド時間に応じた従量課金。無料枠は月100分（2026年3月時点）

buildspec.ymlの基本例：

# buildspec.yml（AWS CodeBuild用）
version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.11
  pre_build:
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      - python -m pytest tests/ --junitxml=report.xml
  post_build:
    commands:
      - echo "Build completed on `date`"

reports:
  pytest_reports:
    files:
      - report.xml

artifacts:
  files:
    - '**/*'

3. AWS CodeDeploy

AWS CodeDeployは、EC2・Lambda・ECSへのアプリケーションデプロイを自動化するサービスです。単純なファイルコピー以上の「デプロイ戦略」をマネージドに実装できる点が特徴です。

・デプロイ戦略: In-place（インプレース）とBlue/Green（ブルーグリーン）に対応
・ECS Blue/Green: 新タスクが起動してからトラフィックを切り替えるため、ダウンタイムがゼロ
・自動ロールバック: デプロイ失敗時に旧バージョンへ自動で戻る
・定義ファイル: appspec.ymlでデプロイフックを細かく制御できる

4. GitHub Actionsとの連携

AWSのネイティブサービス以外に、多くの現場でGitHub ActionsによるCI/CDが採用されています。GitHubで開発しているチームなら、リポジトリと同じ場所でパイプラインを管理できる点が大きなメリットです。

認証にはaws-actions/configure-aws-credentialsアクションとIAMのOIDCプロバイダーを組み合わせる方式が推奨されています。アクセスキーをGitHubのSecretsに保存する方式より安全で、キーの定期ローテーションが不要になります。

姉妹サイトセキュリティマスターズ.TOKYOでは、CI/CDパイプラインへのシークレット安全注入とOIDC認証の仕組みをセキュリティ観点で詳しく解説しています。

AzureのCI/CDサービス

1. Azure DevOps Pipelines

Azure DevOps PipelinesはMicrosoftが提供するCI/CDの統合プラットフォームです。AWSのCodePipeline + CodeBuild + CodeDeployを組み合わせた構成に相当する機能を、一つのサービスで完結させられる点が特徴です。

・パイプライン定義: YAMLファイル（azure-pipelines.yml）でビルドからデプロイまで記述
・エージェント: Microsoftホスト型（Windowsを含む3OS）とセルフホスト型を選択可能
・Azure統合: Azure Kubernetes Service（AKS）・Azure App Service・Azure Functionsへのデプロイを標準サポート
・エコシステム: Azure Boards（チケット管理）・Azure Repos（Gitリポジトリ）と一体化
・料金: Microsoft-hostedエージェントは月1,800分まで無料（2026年3月時点）

2. GitHub ActionsとAzure連携

GitHub Actionsを使ってAzureにデプロイする場合、azure/loginアクションとService PrincipalまたはFederated Credentials（OIDC）で認証します。Azure Web Apps・AKS・Azure Functionsへのデプロイを自動化できます。

社内でMicrosoft 365を使っているチームやAzure Active DirectoryとIDを統合したい場合は、Azure DevOps Pipelinesとの統合が一段とスムーズになります。一方、オープンソースプロジェクトやGitHubを中心に開発しているチームでは、GitHub Actionsの採用が標準になりつつあります。

AWS vs Azure CI/CDサービス比較

Linuxサーバー上でCI/CDエージェントを自前で動かす場合の基礎知識については、姉妹サイトLinuxMaster.JPでも解説しています。

現場でよくあるCI/CDのトラブルと対処法

トラブル1: 「ローカルやステージングは通るのに本番だけ失敗する」

CI環境では成功するのに本番だけ失敗するケースで最も多い原因は、環境変数・シークレット・IAMロールの設定差です。

・対処: CodePipelineのステージに注入する環境変数を、AWS Systems Manager Parameter Store（SSM）またはAWS Secrets Managerで一元管理する。Azureなら Azure Key Vaultを利用する。ステージング・本番の差異は設定ファイルではなくシークレット管理サービス側で吸収するのが原則です。

トラブル2: ビルド時間が長すぎて開発者のフローを中断させる

テストが増えるほどビルド時間は伸び、CI/CDの待ち時間が開発者の集中を妨げます。10分を超えるビルドは「待つのをやめてしまう」という文化的な問題を引き起こします。

・対処: テストを並列実行する設定を入れる（CodeBuildなら並列ビルド設定が可能）。DockerビルドではBuildKitのレイヤーキャッシュを活用して変更のないレイヤーの再ビルドを省略する。また、ユニットテスト・結合テスト・E2Eテストをステージに分け、早いテストを先に実行して失敗を早期検出する「フェイルファスト」設計も有効です。

トラブル3: デプロイが途中で失敗して本番が中途半端な状態になる

ローリングアップデートの途中でエラーが起きると、古いバージョンと新しいバージョンが同時に動く「混在状態」が生まれ、ユーザーに影響が出ます。

・対処: AWS CodeDeployのBlue/Greenデプロイを使うと、新環境をすべて起動してからトラフィックを切り替えるため、中途半端な状態になりません。失敗時は自動で旧環境にロールバックされます。AzureではAzure App ServiceのデプロイスロットやAKSのローリングアップデートポリシーで同様の制御が可能です。

トラブル4: シークレット（APIキー・パスワード）がリポジトリに混入する

GitHubの公開リポジトリにシークレットが混入する事故は今も頻繁に発生しています。「.envファイルをうっかりpushした」というケースが典型です。

・対処: CI/CDパイプラインの最初のステップにgit-secretsまたはTrivyのシークレットスキャンを組み込む。AWSではGitHub Advanced SecurityのSecret Scanningとの連携も有効です。また、IAM認証をOIDCベースに切り替えることで、静的なアクセスキー自体をなくすアプローチが根本的な解決策になります。

本記事のまとめ

・CI（継続的インテグレーション）: コードをpushするたびに自動ビルド・テストを走らせるしくみ。バグを早期に検出して手戻りコストを削減する
・CD（継続的デリバリー / デプロイメント）: テスト済みコードを常にデプロイ可能な状態に保つ（デリバリー）か、全自動で本番まで届ける（デプロイメント）かを要件に応じて選択する
・AWSの基本構成: AWS CodePipeline（司令塔）+ AWS CodeBuild（ビルド）+ AWS CodeDeploy（デプロイ）
・Azureの基本構成: Azure DevOps PipelinesがCI/CDを1ツールで統合。GitHub Actionsも両クラウドで有力な選択肢
・現場の優先設計事項: シークレットのマネージドサービス管理・Blue/Greenデプロイ・テスト並列化は最初から設計に組み込む