AWS 完全攻略 Ep10: SESエンジニアのためのCodePipeline・CodeBuild CI/CD入門

なぜSESエンジニアにCI/CDスキルが必要なのか

AWS CodePipelineとCodeBuildは、AWSが提供するフルマネージドCI/CD（継続的インテグレーション／継続的デリバリー）サービスです。開発チームの生産性とリリース品質を同時に高めるCI/CDパイプラインは、2026年のSES案件市場においても最も求められるDevOpsスキルの一つとなっています。

従来のSES案件ではJenkinsやCircleCIなどのサードパーティツールが主流でしたが、AWSネイティブのCI/CDサービスを使いこなせるエンジニアの需要が急速に高まっています。特にIAMロールとの統合、CodeCommitやECRとのシームレスな連携、そしてCloudFormationやCDKによるパイプラインのIaC化など、AWSエコシステム全体を横断するスキルが評価される傾向にあります。

CI/CD × SES案件の需要と単価【2026年】

DevOpsエンジニアの市場動向

2026年のSES案件市場では、CI/CDパイプラインの設計・構築経験を求める案件が前年比30%増で伸びています。特に以下の領域で需要が顕著です。

• モダンWebアプリ開発: フロントエンド・バックエンドの自動ビルド＋デプロイ
• コンテナ/マイクロサービス: ECRへのイメージプッシュ → ECS/EKSへの自動デプロイ
• インフラ自動化: CloudFormation/CDKテンプレートの自動テスト＋適用

経験年数別の単価相場

経験レベル	想定月額単価	求められるスキル
1年未満	55〜65万円	CodeBuildでのビルド設定、基本的なbuildspec作成
1〜3年	70〜85万円	パイプライン設計、ブランチ戦略、自動テスト統合
3年以上	85〜110万円	マルチアカウント・クロスリージョンデプロイ、IaC化

ポイント: CI/CD単体よりも、ECS/FargateやIaC（Terraform/CDK）と組み合わせたスキルセットが高単価案件への近道です。

CodePipelineとCodeBuildの違い・役割分担

CodePipeline — パイプラインのオーケストレーター

CodePipelineは、ソースコードの変更検知からビルド、テスト、デプロイまでのワークフロー全体を管理するオーケストレーションサービスです。パイプラインは複数の「ステージ」で構成され、各ステージ内で1つ以上の「アクション」を実行します。

主な特徴:

• GitHub、CodeCommit、S3などのソースプロバイダーと統合
• ステージ間に手動承認アクションを挿入可能
• CloudWatch Eventsによる自動トリガー
• V2タイプではパイプラインレベル変数やトリガーフィルタリングが可能

CodeBuild — ビルド＆テストの実行エンジン

CodeBuildは、ソースコードのコンパイル、テスト実行、アーティファクト生成を行うフルマネージドビルドサービスです。Jenkinsのようなビルドサーバーの管理が不要で、スケーリングも自動的に行われます。

主な特徴:

• buildspec.ymlでビルド手順を定義
• Docker イメージベースの実行環境（カスタムイメージも利用可）
• ビルド結果をS3やECRに自動出力
• ビルド時間課金（使った分だけ支払い）

2つのサービスの関係

┌─ CodePipeline（オーケストレーター）─────────┐
│                                                │
│  Source → Build → Test → Approve → Deploy     │
│            ↓       ↓                    ↓      │
│       CodeBuild CodeBuild          ECS/Lambda  │
│                                                │
└────────────────────────────────────────────────┘

CodePipelineが「何を・どの順番で実行するか」を決め、CodeBuildが「実際のビルド・テスト処理」を担当します。Jenkins で例えると、CodePipelineがJenkinsfileのパイプライン定義、CodeBuildが各ステップの実行環境に相当します。

buildspec.ymlの書き方と実践パターン

基本構造

CodeBuildの実行手順はbuildspec.ymlで定義します。このファイルはリポジトリのルートに配置するのが一般的です。

version: 0.2

env:
  variables:
    NODE_ENV: "production"
  parameter-store:
    DB_PASSWORD: "/myapp/db-password"

phases:
  install:
    runtime-versions:
      nodejs: 20
    commands:
      - npm ci
  pre_build:
    commands:
      - echo "Running lint..."
      - npm run lint
  build:
    commands:
      - echo "Building application..."
      - npm run build
  post_build:
    commands:
      - echo "Running integration tests..."
      - npm run test:integration

artifacts:
  files:
    - '**/*'
  base-directory: dist

cache:
  paths:
    - 'node_modules/**/*'

実践パターン：Dockerイメージのビルド＆ECRプッシュ

ECS/Fargate案件で頻出するパターンです。

version: 0.2

phases:
  pre_build:
    commands:
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION |
        docker login --username AWS --password-stdin $ECR_REPO_URI
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c1-7)
  build:
    commands:
      - docker build -t $ECR_REPO_URI:$IMAGE_TAG .
      - docker tag $ECR_REPO_URI:$IMAGE_TAG $ECR_REPO_URI:latest
  post_build:
    commands:
      - docker push $ECR_REPO_URI:$IMAGE_TAG
      - docker push $ECR_REPO_URI:latest
      - printf '[{"name":"app","imageUri":"%s"}]' $ECR_REPO_URI:$IMAGE_TAG
        > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

imagedefinitions.jsonはCodePipelineのECSデプロイアクションが参照するファイルです。このパターンを覚えておけば、コンテナ系CI/CD案件の8割はカバーできます。

ブランチ戦略と承認ゲートの設計

SES案件で多いブランチ戦略

現場で最も多く見られるのは、以下の2パターンです。

パターン①: GitHub Flow（シンプル）

• main ブランチへのマージをトリガーにデプロイ
• 小〜中規模のチームに最適
• CodePipeline V2のトリガーフィルタリングでブランチ指定

パターン②: GitFlow（エンタープライズ）

• develop → staging、main → production の2段階
• 大規模案件やリリースサイクルが固定されたプロジェクト向け
• ステージごとにパイプラインを分離

承認ゲートの実装

本番デプロイ前に手動承認を挟むのは、SES案件ではほぼ必須の要件です。

CodePipelineでは「Manual Approval」アクションを挿入するだけで実現できます。承認リクエストはSNSトピック経由でSlackやメールに通知でき、SQS・SNSの知識がここでも活きてきます。

Source → Build → Test → [手動承認] → Deploy(Production)

承認待ちの間、パイプラインは一時停止状態になります。承認者がAWSコンソールまたはCLIから承認/却下を行い、承認された場合のみデプロイが続行されます。

ECS/Lambdaへの自動デプロイ構成

ECS Blue/Greenデプロイ

ECS/Fargateへの本番デプロイでは、Blue/Greenデプロイが推奨されます。CodeDeployと連携することで、トラフィックの段階的な切り替えとロールバックを自動化できます。

デプロイフロー:

1. CodeBuildでDockerイメージをビルド → ECRにプッシュ
2. CodeDeployが新しいタスクセット（Green）を起動
3. ALBのターゲットグループを段階的に切り替え（Canary/Linear）
4. ヘルスチェック通過後、旧タスクセット（Blue）を終了
5. 異常検知時は自動ロールバック

Lambda関数の自動デプロイ

Lambdaのデプロイには**AWS SAM（Serverless Application Model）**との組み合わせが効果的です。

# buildspec.yml for SAM
phases:
  build:
    commands:
      - sam build
      - sam package --s3-bucket $ARTIFACT_BUCKET
        --output-template-file packaged.yaml
artifacts:
  files:
    - packaged.yaml

CodePipelineのデプロイステージでCloudFormationアクションを使い、packaged.yamlをデプロイします。CloudFormationの知識がここで活きてきます。

セキュリティとIAM設計のベストプラクティス

CI/CDパイプラインは本番環境への入口です。セキュリティ設計を疎かにすると、パイプラインが攻撃経路になりかねません。

最小権限の原則を徹底する

CodeBuildのサービスロールには、ビルドに必要最小限の権限のみを付与しましょう。IAM設計の基本を復習しておくことをおすすめします。

よくある過剰権限の例:

• CodeBuildロールにAdministratorAccessを付与 → ❌
• ECRのプッシュ権限が全リポジトリに開放 → ❌
• Secrets Managerの全シークレットへのアクセス → ❌

シークレット管理

環境変数にパスワードやAPIキーをハードコードしてはいけません。以下のサービスと連携しましょう。

• AWS Systems Manager Parameter Store: buildspecのparameter-storeセクションで参照
• AWS Secrets Manager: より高度なローテーション機能が必要な場合
• 環境変数の暗号化: CodeBuildプロジェクト設定でKMSキーを指定

VPC内でのビルド実行

プライベートサブネットのリソース（RDS、ElastiCacheなど）にアクセスする必要がある場合は、CodeBuildをVPC内で実行します。VPC設計の知識が必要になるため、合わせて確認しておきましょう。

コスト最適化のポイント

CodeBuildの料金体系

CodeBuildはビルド時間（分単位）の従量課金です。コンピュートタイプによって単価が異なります。

コンピュートタイプ	vCPU	メモリ	Linux料金（東京）
BUILD_GENERAL1_SMALL	2	3GB	$0.005/分
BUILD_GENERAL1_MEDIUM	4	7GB	$0.010/分
BUILD_GENERAL1_LARGE	8	15GB	$0.020/分

コスト削減テクニック

1. キャッシュの活用: S3キャッシュまたはローカルキャッシュでnode_modules等を再利用
2. 適切なコンピュートタイプ: 小規模ビルドにLARGEインスタンスを使わない
3. 並列ビルドの制御: 不要なブランチへのトリガーを無効化
4. CodePipeline V2の料金: パイプライン数ではなくアクション実行回数で課金（低頻度なら安価）

無料利用枠

CodeBuildには毎月100分のビルド時間（build.general1.small） が無料枠として含まれています。学習目的であれば十分な量です。

実務で差がつくTips

1. パイプラインのIaC化

パイプライン自体をCloudFormationやCDKで管理することで、環境の再現性が格段に上がります。IaC入門の知識を活かしましょう。

// AWS CDK でパイプラインを定義する例
const pipeline = new codepipeline.Pipeline(this, 'MyPipeline', {
  pipelineType: codepipeline.PipelineType.V2,
  stages: [
    { stageName: 'Source', actions: [sourceAction] },
    { stageName: 'Build', actions: [buildAction] },
    { stageName: 'Deploy', actions: [deployAction] },
  ],
});

2. CloudWatchによるパイプライン監視

ビルド失敗率やデプロイ頻度をCloudWatchメトリクスで可視化しましょう。DORA指標（デプロイ頻度・リードタイム・変更失敗率・復旧時間） をダッシュボードで追跡できると、チームの改善活動にも貢献できます。

3. テスト戦略の段階化

Unit Test（CodeBuild①）
    ↓
Integration Test（CodeBuild②）
    ↓
E2E Test（CodeBuild③、ステージング環境）
    ↓
Manual Approval
    ↓
Production Deploy

テストを段階的に実行することで、早期のフィードバックと本番品質の担保を両立できます。

まとめ：CI/CDスキルでSES案件の幅を広げよう

AWS CodePipelineとCodeBuildを使いこなせれば、開発プロセス全体を設計・自動化できるエンジニアとして評価されます。CI/CDはインフラエンジニアだけでなく、アプリケーションエンジニアにも求められるスキルであり、SES案件における単価アップの強力な武器になります。

本シリーズで学んだVPC、IAM、ECS/Fargate、CloudFormationなどの知識と組み合わせることで、AWSインフラの設計からデプロイまでを一気通貫でカバーできるスキルセットが完成します。

まずはCodeBuildでシンプルなビルド設定を作り、CodePipelineで自動化するところから始めてみましょう。実践あるのみです！

参考リンク

• AWS CodePipeline公式ドキュメント
• AWS CodeBuild公式ドキュメント
• AWS DevOps Blog
• CI/CDパイプラインのベストプラクティス — AWS Well-Architected Framework