AWS CodePipelineとは｜CodeBuild・buildspec・料金

CodePipeline は「流れの設計図」、CodeBuild は「ビルドを実際に行う作業場」、CodeDeploy は「サーバーやコンテナへ配る係」です。3つは別々のサービスで、CodePipeline がほかの2つを順番に呼び出します。

flowchart TD
    G[GitHub に push] --> S[Source ステージ<br>コードを取得]
    S -->|SourceArtifact| B[Build ステージ<br>CodeBuild が buildspec.yml を実行]
    B -->|BuildArtifact| D[Deploy ステージ<br>S3・CodeDeploy・ECS など]
    D --> OK[本番・検証環境に反映]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18・bash 5.2.21・PyYAML 6.0.3 を使い、小さな Python のアプリ（税込み合計を計算する関数と unittest のテスト2件）と buildspec.yml を作りました。buildspec.yml は PyYAML で読み込み、フェーズ名や commands の形を確かめる自作の検査スクリプトで検証し、さらに buildspec の公式リファレンスに書かれた決まり（0.2 は全コマンドを同じシェルで実行、finally は失敗しても実行、など）を再現する自作のスクリプトで、同じコマンドを手元の bash で流しました。CodeBuild や CodePipeline そのものは動かしていません。この環境の AWS の認証情報は使わず、AWS には接続していません。パイプラインの JSON は、boto3・botocore 1.44.2 に入っている CodePipeline の API 定義で入力の形を検証し、AWS のサービスを手元で模擬する moto 5.2.5 で作成と取得を試しています。料金は AWS の料金ページの単価と計算例を Python で計算し直しました。サービスの仕組み・上限・料金は AWS の公式（製品ページ・料金ページ・CodePipeline / CodeBuild / CodeDeploy のユーザーガイド）、GitHub Actions は GitHub Docs で確かめています。図は mermaid 11.16.0 で描画を確かめました（確認日 2026年11月13日）。

AWS CodePipelineとは（できること）

この節では、CodePipeline が何をするサービスなのかと、最低限覚える用語が分かります。

CodePipeline は、ソフトウェアの変更がリリースまでに通る道筋（ワークフロー）を、ステージとアクションで定義して自動で流すサービスです。公式のユーザーガイドは、パイプラインを「ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造」と説明しています。GitHub に push すると、パイプラインがそれを検出し、ビルド・テスト・デプロイを順に進めます。

最低限の用語

アーティファクトは、パイプラインごとに指定した S3 バケット（アーティファクトストア）に保存されます。料金ページには、このアーティファクトの保存と取得に S3 の料金が別にかかることがある、と書かれています。

パイプラインの段階（ソース・ビルド・デプロイ）

この節では、よく使う3段のパイプラインの中身と、ステージの決まりが分かります。

典型的な形は「Source → Build → Deploy」の3ステージです。公式の「パイプライン宣言」には、ステージについて次の決まりがあります。

• パイプラインには少なくとも2つのステージが要る
• 最初のステージにはソースアクションだけを置く（ソースアクションを置けるのは最初のステージだけ）
• 少なくとも1つのステージに、ソース以外のアクションが要る
• ステージ名はパイプラインの中で重複できない

アクションの間はアーティファクト名でつなぐ

前のアクションの outputArtifacts の名前を、次のアクションの inputArtifacts に書きます。名前が一致しないと流れがつながりません。CodeBuild のアクションの入力アーティファクトは1〜5個、出力は0〜5個です（公式のアクションリファレンス）。入力が複数のときは、どれを buildspec.yml のある主なソースにするかを PrimarySource で指定します。

実行の進み方：ステージは1つずつ

公式の「パイプライン実行の仕組み」によると、各ステージは一度に1つの実行しか処理せず、処理中はロックされます。アクションが失敗すると、その変更は次へ進みません。失敗したステージは手動で再試行でき、再試行では失敗したアクションだけが再び動きます。

CodeBuild・CodeDeployとの関係

この節では、名前の似た3つのサービスの役割の違いが分かります。

CodePipeline は「順番と受け渡し」だけを受け持ち、実際の処理はほかのサービスが行います。ビルドしたいなら CodeBuild、サーバーやコンテナに配りたいなら CodeDeploy（または ECS・CloudFormation などのデプロイアクション）を組み合わせます。

CodeDeploy のユーザーガイドによると、インプレースデプロイは EC2・オンプレミスだけで使え、Lambda と ECS のデプロイはすべて Blue/Green です。CodeDeploy のデプロイアクションのタイムアウトは5日間、CodeBuild のビルドアクションは36時間です（CodePipeline のクォータ）。

CI/CD という考え方そのものと、GitHub Actions で最初のパイプラインを作る手順は、関連記事「CI/CDとは｜GitHub Actionsで最初のパイプラインを作るまで」で扱っています。

buildspec.ymlの書き方（CodeBuild）

この節では、buildspec.yml の全体の形と、各項目に何を書くかが分かります。

buildspec.yml は、CodeBuild がビルドで実行するコマンドと、出力するファイルを書く YAML ファイルです。既定の名前は buildspec.yml で、ソースのルート（リポジトリの直下）に置きます。名前や場所はプロジェクトの設定で変えられますが、1つのビルドプロジェクトに使える buildspec は1つです。手元で作った例は次のとおりです。

version: 0.2

env:
  variables:
    APP_NAME: "price-app"
  exported-variables:
    - BUILD_TAG

phases:
  install:
    runtime-versions:
      python: 3.12
    commands:
      - python3 --version
  pre_build:
    commands:
      - echo "pre_build started"
      - cd src
      - export BUILD_TAG="${APP_NAME}-$(date +%Y%m%d)"
  build:
    commands:
      - echo "now in $(pwd)"
      - cd ..
      - python3 -m unittest discover -s tests -v
    finally:
      - echo "build finally (always runs)"
  post_build:
    commands:
      - echo "CODEBUILD_BUILD_SUCCEEDING=${CODEBUILD_BUILD_SUCCEEDING}"
      - mkdir -p dist && cp src/*.py dist/
      - echo "${BUILD_TAG}" > dist/VERSION

artifacts:
  files:
    - '**/*'
  base-directory: dist
  name: price-app-artifact

cache:
  paths:
    - '/root/.cache/pip/**/*'

4つのフェーズの使い分け

フェーズは install → pre_build → build → post_build の順で、名前は変えられません。公式リファレンスの例では、install はパッケージの導入、pre_build は ECR へのサインインや npm の依存関係の導入、build はテストの実行、post_build は成果物のパッケージ化やコンテナイメージの push、通知に使われています。

• runtime-versions：install の中で python: 3.12 のように言語の版を選ぶ。Ubuntu 標準イメージ 5.0 以降・Amazon Linux 2 標準イメージ 4.0 以降で使える。指定しないとイメージの既定の版になり、既定の版はサポート終了に合わせて変わることがある。
• finally：commands のどれかが失敗しても実行されるブロック。後片付けに使う。
• on-failure：フェーズが失敗したときに ABORT（中止）・CONTINUE（次のフェーズへ）・RETRY（再試行）を選ぶ。Lambda のコンピューティングとリザーブドキャパシティでは使えない。

環境変数の優先順位

同じ名前の環境変数が複数の場所にあると、ビルド開始時に渡した値 → ビルドプロジェクトの設定 → buildspec の値 の順に強くなります（左ほど優先）。CODEBUILD_ で始まる名前は CodeBuild が内部で使うので、自分では付けません。パスワードや鍵を扱う方法は、関連記事「AWS Secrets Managerの使い方 CLI・boto3取得早見表」で扱っています。

buildspec.ymlのコマンドを手元で流した結果

この節では、上の buildspec.yml のコマンドを手元で順に流すと何が起きるかと、push の前に見つけられる書き間違いが、実際の出力で分かります。

CodeBuild に送る前に、同じコマンドを手元で流しておくと、失敗の多くを先に見つけられます。ここでは、公式リファレンスに書かれた次の決まりを再現する小さな Python のスクリプトを作り、buildspec.yml を読み込んで bash で実行しました。CodeBuild のログではないので、行頭は [local] にしています（作業フォルダーの名前は短く書き換えています）。

• version 0.2 では、全コマンドを同じシェルのインスタンスで実行する（cd や export が次のコマンドに引き継がれる）
• コマンドは書いた順に1つずつ実行し、失敗したら同じフェーズの残りは飛ばす。finally は実行する
• BUILD が失敗しても、成果物のアップロード（UPLOAD_ARTIFACTS）は試みる

[local] version=0.2 CODEBUILD_SRC_DIR=/tmp/src6_l2g9yh/src
[local] runtime-versions {'python': 3.12} は手元では切り替えない
[local] run: python3 --version
Python 3.13.18
[local] Phase complete: INSTALL State: SUCCEEDED
[local] run: echo "pre_build started"
pre_build started
[local] run: cd src
[local] run: export BUILD_TAG="${APP_NAME}-$(date +%Y%m%d)"
[local] Phase complete: PRE_BUILD State: SUCCEEDED
[local] run: echo "now in $(pwd)"
now in /tmp/src6_l2g9yh/src/src
[local] run: cd ..
[local] run: python3 -m unittest discover -s tests -v
test_basic (test_price.TestTotal.test_basic) ... ok
test_empty (test_price.TestTotal.test_empty) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK
[local] run: echo "build finally (always runs)"  (finally)
build finally (always runs)
[local] Phase complete: BUILD State: SUCCEEDED
[local] run: echo "CODEBUILD_BUILD_SUCCEEDING=${CODEBUILD_BUILD_SUCCEEDING}"
CODEBUILD_BUILD_SUCCEEDING=1
[local] run: mkdir -p dist && cp src/*.py dist/
[local] run: echo "${BUILD_TAG}" > dist/VERSION
[local] Phase complete: POST_BUILD State: SUCCEEDED
[local] exported BUILD_TAG='price-app-20261113'
[local] UPLOAD_ARTIFACTS ./out/price-app-artifact.zip
    VERSION  19 bytes
    price.py  173 bytes
[local] BUILD SUCCEEDED

テストが失敗したとき

税率を 0.10 から 0.08 に書き換えてテストを失敗させると、build の残りのコマンドは飛ばされ、finally は動きました。post_build では CODEBUILD_BUILD_SUCCEEDING が 0 になります（公式の環境変数の説明：失敗なら0、成功なら1）。

[local] run: python3 -m unittest discover -s tests -v
test_basic (test_price.TestTotal.test_basic) ... FAIL
test_empty (test_price.TestTotal.test_empty) ... ok

======================================================================
FAIL: test_basic (test_price.TestTotal.test_basic)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/src3zd91t4d/src/tests/test_price.py", line 7, in test_basic
    self.assertEqual(total([(100, 2), (250, 1)]), 495)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 486 != 495

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)
[local] FAILED: python3 -m unittest discover -s tests -v (exit status 1)
[local] run: echo "build finally (always runs)"  (finally)
build finally (always runs)
[local] Phase complete: BUILD State: FAILED
[local] run: echo "CODEBUILD_BUILD_SUCCEEDING=${CODEBUILD_BUILD_SUCCEEDING}"
CODEBUILD_BUILD_SUCCEEDING=0

失敗したビルドの成果物をデプロイしないよう、post_build で成否によって処理を分けたいときは CODEBUILD_BUILD_SUCCEEDING を見ます。フェーズの間の移り方は公式の「ビルドフェーズの移行」の図に示されていて、本文には「UPLOAD_ARTIFACTS フェーズは、BUILD フェーズが失敗した場合でも必ず試行されます」と書かれています。

version 0.1 にすると何が変わるか

同じファイルの version だけを 0.1 にして流しました。0.1 はコマンドごとに別のシェルで実行するので、cd も export も次のコマンドに残りません。

[local] run: cd src
[local] run: export BUILD_TAG="${APP_NAME}-$(date +%Y%m%d)"
[local] Phase complete: PRE_BUILD State: SUCCEEDED
[local] run: echo "now in $(pwd)"
now in /tmp/src6pddkzz9/src
...
[local] exported BUILD_TAG=''
[local] UPLOAD_ARTIFACTS ./out/price-app-artifact.zip
    VERSION  1 bytes
    price.py  173 bytes

テストは通りましたが、VERSION ファイルの中身は改行1文字だけになりました。エラーにならずに中身だけが欠けるので、気づきにくい違いです。公式も 0.2 を勧めています。

push の前に YAML として検証する

公式リファレンスにも「buildspec 宣言は有効な YAML である必要がある」とあり、空白（インデント）が意味を持ちます。PyYAML で読み込み、フェーズ名・commands の型・artifacts.files の有無を確かめる20行ほどの検査スクリプトを作り、よくある書き間違いを5つ流しました。

--- tab
tab.yml: YAML として読めない
while scanning for the next token
found character '\t' that cannot start any token
  in "tab.yml", line 5, column 1
--- colon
colon.yml: build.commands[0] が文字列でない: {'echo Build': 'done'}（': ' を含むなら引用符で囲む）
--- name
name.yml: フェーズ名が違う: prebuild（install/pre_build/build/post_build のどれか）
--- alias
alias.yml: YAML として読めない
while scanning an alias
  in "alias.yml", line 8, column 7
expected alphabetic or numeric character, but found '*'
  in "alias.yml", line 8, column 8
--- nofiles
nofiles.yml: artifacts.files がない（必須）

公式リファレンスも「YAML でサポートされない文字を含むコマンドは引用符で囲む」ように書いています。: （コロンと空白）・先頭の *・{・# を含むコマンドは、最初から引用符で囲むのが確実です。YAML の構文と落とし穴は、関連記事「YAMLの書き方｜構文一覧とパース結果、落とし穴10例を実測」で扱っています。

パイプラインのJSONを手元で確かめる

この節では、パイプラインの定義（JSON）の形と、AWS に送る前に形と決まりを確かめた結果が分かります。

パイプラインは JSON（AWS CLI の create-pipeline や CloudFormation）でも定義できます。上の3ステージを JSON で書くと次のとおりです（ARN やバケット名は例です）。

{
  "pipeline": {
    "name": "price-app-pipeline",
    "roleArn": "arn:aws:iam::123456789012:role/service-role/AWSCodePipelineServiceRole-price-app",
    "artifactStore": { "type": "S3", "location": "codepipeline-ap-northeast-1-example" },
    "pipelineType": "V2",
    "executionMode": "QUEUED",
    "stages": [
      { "name": "Source", "actions": [ {
          "name": "Source",
          "actionTypeId": { "category": "Source", "owner": "AWS", "provider": "CodeStarSourceConnection", "version": "1" },
          "configuration": {
            "ConnectionArn": "arn:aws:codeconnections:ap-northeast-1:123456789012:connection/example-id",
            "FullRepositoryId": "example-org/price-app",
            "BranchName": "main",
            "OutputArtifactFormat": "CODE_ZIP"
          },
          "outputArtifacts": [ { "name": "SourceArtifact" } ],
          "runOrder": 1 } ] },
      { "name": "Build", "actions": [ {
          "name": "BuildAndTest",
          "actionTypeId": { "category": "Build", "owner": "AWS", "provider": "CodeBuild", "version": "1" },
          "configuration": { "ProjectName": "price-app-build" },
          "inputArtifacts": [ { "name": "SourceArtifact" } ],
          "outputArtifacts": [ { "name": "BuildArtifact" } ],
          "runOrder": 1 } ] },
      { "name": "Deploy", "actions": [ {
          "name": "DeployToS3",
          "actionTypeId": { "category": "Deploy", "owner": "AWS", "provider": "S3", "version": "1" },
          "configuration": { "BucketName": "price-app-example-bucket", "Extract": "true" },
          "inputArtifacts": [ { "name": "BuildArtifact" } ],
          "runOrder": 1 } ] }
    ]
  }
}

この JSON を、(1) botocore に入っている CodePipeline の API 定義で CreatePipeline の入力として検証し、(2) ユーザーガイドの「パイプライン宣言」の決まり（ステージ2つ以上・ソースは最初のステージだけ・アーティファクト名のつながり・QUEUED は V2 が必要）を自作のスクリプトで確かめました。わざと壊した JSON（roleArn を消す・runOrder を文字列にする・Build ステージにソースを足す・入力名を間違える・V1 にする）も流しています。

== pipeline.json
[botocore] OK
[rules] OK
== broken.json
[botocore]
Missing required parameter in pipeline: "roleArn"
Invalid type for parameter pipeline.stages[1].actions[0].runOrder, value: 1, type: <class 'str'>, valid types: <class 'int'>
[rules]
  ソースアクションは最初のステージだけ（Build）
  DeployToS3: 入力 BuildOutput を前のアクションが出していない
  QUEUED モードは V2 タイプが必要

さらに、AWS のサービスを手元で模擬する moto の中で、ダミーの認証情報を使って同じ JSON から作成と取得を試しました。同じ名前で2回作ると、エラーになりました。

created: price-app-pipeline version 1 V2
stages: Source -> Build -> Deploy
list: ['price-app-pipeline']
InvalidStructureException An error occurred (InvalidStructureException) when calling the CreatePipeline operation: A pipeline with the name 'price-app-pipeline' already exists in account '123456789012'

moto は AWS の応答をまねる道具で、本物の CodePipeline がこのメッセージを返すかは確かめていません。API の形の検証（botocore）と、手元の決まりの検査までが、AWS に送る前に確かめられる範囲です。roleArn に指定するサービスロールの考え方は、関連記事「IAMロールとは｜ユーザー・ポリシーとの違いとAssumeRole、信頼ポリシー」で扱っています。

CodePipelineのV1とV2の違い

この節では、パイプラインのタイプ V1 と V2 で使える機能の違いが分かります。

V2 は V1 と同じ JSON の構造に、リリースの安全性とトリガーの設定のための項目を足したタイプです。公式の「適切なパイプラインのタイプの選択」の比較表から抜き出しました。

3つの実行モード

1. 1SUPERSEDED（既定）待っている実行は、より新しい実行に置き換えられる。最新の変更だけを届けたいとき
2. 2QUEUED（V2 のみ）到着した順に1つずつ処理し、置き換えない。どの変更も必ず通したいとき
3. 3PARALLEL（V2 のみ）実行どうしが独立して同時に進む。ブランチごとの開発環境など。ステージのロールバックは使えない

V2 のトリガーでは、push とプルリクエストごとに絞り込みを書けます。クォータによると、絞り込みは push・プルリクエストごとに最大3つ、含める・除外するパターンはそれぞれ最大8つ、各パターンは255文字までです。

CodePipelineの料金（V1・V2）

この節では、CodePipeline の料金の決まりと、回数ごとに計算した月額が分かります。

V1 は「アクティブなパイプライン1本あたり月1.00 USD」、V2 は「アクション実行1分あたり0.002 USD」です（料金ページ、2026年11月13日時点）。

まず、料金ページの計算例を Python で計算し直し、同じ答えになることを確かめました。

公式例2: 9.12            （V1 10本＋V2 で 20回×4アクション×2分）
公式例3: 0.2  公式例4: 99.0

次に、この記事の3ステージ（Source 40秒・Build 230秒・Deploy 50秒と仮定）で計算しました。アクションごとに分へ切り上げるので、1回あたり 1＋4＋1＝6分になります。

import math
V2_PER_MIN, V2_FREE = 0.002, 100
acts = [40, 230, 50]                       # 各アクションの秒数（仮定）
per = sum(math.ceil(s / 60) for s in acts)  # アクションごとに分へ切り上げ → 6
for runs in (20, 50, 100, 200, 500):
    m = per * runs
    print(runs, m, round(max(0, m - V2_FREE) * V2_PER_MIN, 2))

この形のパイプライン1本なら、月101回を超えると V2 の料金が V1 の1本分を上回ります（計算で求めた値）。ただし V2 の無料枠100分はアカウントの V2 パイプライン全体で共有なので、本数が増えると早く使い切ります。また、59秒のアクションは1分、61秒は2分と数えるので、短いアクションを細かく分けるほど課金分が増えます。料金ページには、AWS 料金見積りツールが対応しているのは V1 だけ、とも書かれています。なお、この金額に CodeBuild のビルド料金と S3 の料金は含まれません。

CodeBuildの料金とビルド環境

この節では、CodeBuild の課金の考え方、無料枠、選べるビルド環境の大きさが分かります。

CodeBuild は、選んだビルド環境（コンピューティングタイプ）でビルドした時間に応じて課金されます。料金ページの無料枠は次のとおりです（2026年11月13日時点）。

• オンデマンドの EC2 で general1.small か arm1.small を使うと、月合計100分のビルド時間
• オンデマンドの Lambda で lambda.arm.1GB か lambda.x86-64.1GB を使うと、月合計6,000秒
• この無料枠は12か月の無料利用枠の期間が終わっても自動では切れず、新規・既存のどちらの利用者も対象

料金ページの計算例では build.general1.small を1分あたり0.005 USD として「5分のビルドを100回＝500分、無料の100分を引いた400分×0.005 USD＝2 USD」と計算しています。リージョンごとの単価（東京リージョンを含む）は料金ページの表で選んで確かめます。計算例の単価で、上の3ステージのビルド（230秒＝4分と数えた場合）を試算すると次のとおりです。

ビルド環境の大きさ（オンデマンド EC2・Linux）

ディスク容量は CODEBUILD_SRC_DIR のフォルダーでだけ使える、と注記されています。ビルドのタイムアウトは5〜2,160分（36時間）、同時に動かせるビルドの数は既定でコンピューティングタイプごとに決まっていて、Service Quotas から引き上げを頼めます（CodeBuild のクォータ）。

buildspec で使える主な環境変数

CodePipelineとGitHub Actionsの違い

この節では、同じ CI/CD を CodePipeline＋CodeBuild と GitHub Actions で組むときの、仕組みの違いが分かります。

どちらも「変更をきっかけにビルド・テスト・デプロイを自動で流す」点は同じで、設定の置き場所・実行環境・AWS への権限の渡し方が違います。どちらかが優れているという話ではなく、チームのコードの置き場所とデプロイ先に合わせて選びます。

同じテストを GitHub Actions で書くと、次のような YAML になります。手元で PyYAML（YAML 1.1 の決まりで読む）に読ませると、キーの on が真偽値の True として読まれました。自作のスクリプトで workflow ファイルを読むときは、この点に気をつけます。

name: test
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python3 -m unittest discover -s tests -v

['name', True, 'jobs']

GitHub Actions から AWS にデプロイするときの権限の設定は、関連記事「GitHub ActionsからOIDCでAWSへ｜IAMロールの信頼ポリシー」で扱っています。

はじめ方（パイプラインを作るまでの流れ）

この節では、GitHub のリポジトリから CodePipeline を作るまでの順番と、設計のときに当たりやすい上限が分かります。

先に CodeBuild のプロジェクトと buildspec.yml を用意し、最後にパイプラインでつなぐ順番が分かりやすい流れです。コンソールの細かい画面は変わることがあるので、ここでは公式のユーザーガイドに沿った順番だけを示します。

• 1buildspec.yml をリポジトリの直下に置くpush の前に手元で YAML として読めるか、同じコマンドが通るかを確かめる
• 2CodeBuild のビルドプロジェクトを作るビルド環境のイメージ・コンピューティングタイプ・サービスロールを決める。プロジェクト名は2〜150文字
• 3GitHub への接続を作るAWS Connector for GitHub のアプリを入れる。CLI や CloudFormation で作った接続は PENDING のままなので、コンソールで AVAILABLE にする
• 4パイプラインを作り、Source・Build・Deploy をつなぐタイプ（V1/V2）と実行モードを選び、アーティファクト名をそろえる
• 5小さな変更を push して最後まで流す失敗したアクションのログを見て直し、ステージを再試行する

GitHub への接続を作るには、GitHub の組織の所有者（組織でなければリポジトリの所有者）である必要があります。接続の「リポジトリアクセス」で選ばなかったリポジトリは、CodePipeline から見えません。ソースの形式を Full clone（CODEBUILD_CLONE_REF）にすると、CodeBuild で git コマンドを直接使えますが、使えるのは後ろが CodeBuild のアクションのときだけで、CodeBuild のサービスロールに権限を足す必要があります。

設計のときに当たりやすい上限（クォータ）

多くの値は固定で、一部だけリージョンごとに引き上げを頼めます（CodePipeline のクォータ、2026年11月13日時点）。

よくあるエラー・つまずき

この節では、CodePipeline と CodeBuild で起きやすい失敗の原因と直し方が分かります。

まず「どのステージの、どのアクションで止まったか」を見て、CodeBuild ならそのビルドのログを開きます。表の原文は、この記事の手元の検査で実際に出したものです。

CodeBuild の公式リファレンスには、イメージが runtime-versions に対応していないとき Skipping install of runtimes. Runtime version selection is not supported by this build image という警告が出ること、互いにぶつかる版（例：android: 29 と java: openjdk11）を指定するとビルドが失敗することも書かれています。

CodePipelineを選ぶかどうかの判断表

この節では、状況ごとにどの組み合わせが合うかが分かります。

決め手は「コードとデプロイ先がどこにあるか」と「権限をどこで管理したいか」です。

よくある質問

Q. AWS CodePipeline とは何ですか？ A. ソースの取得・ビルド・テスト・デプロイをステージとアクションとして定義し、コードの変更のたびに自動で流す AWS の CI/CD サービスです。実際のビルドやデプロイは CodeBuild・CodeDeploy などのサービスが行います。

Q. CodePipeline と CodeBuild の違いは何ですか？ A. CodePipeline は流れ（順番・受け渡し・承認）の管理、CodeBuild はコンテナの中でビルドやテストのコマンドを実行するサービスです。CodeBuild は単体でも使えます。

Q. buildspec.yml はどこに置きますか？ A. 既定ではソースのルート（リポジトリの直下）に buildspec.yml という名前で置きます。プロジェクトの設定で別の名前・別の場所・同じリージョンの S3 バケットも指定できます。

Q. buildspec の version は 0.1 と 0.2 のどちらですか？ A. 公式は 0.2 を勧めています。0.2 は全コマンドを同じシェルで実行するので、cd や export が次のコマンドに引き継がれます。手元で 0.1 にすると、変数が空のまま成果物ができました。

Q. post_build はビルドが失敗しても動きますか？ A. フェーズの間の移り方は公式の「ビルドフェーズの移行」の図に示されています。成否で処理を分けたいときは、post_build の中で CODEBUILD_BUILD_SUCCEEDING（成功1・失敗0）を見るのが確実です。成果物のアップロードは BUILD が失敗しても試みられる、と公式に書かれています。

Q. V1 と V2 のどちらを選べばよいですか？ A. タグやプルリクエストでの絞り込み、QUEUED・PARALLEL の実行モード、パイプラインレベルの変数、ステージ条件を使うなら V2 です。料金の決まりが違うので、実行回数とアクションの時間で試算して比べます。

Q. CodePipeline の料金はいくらですか？ A. 料金ページでは、V1 はアクティブなパイプライン1本あたり月1.00 USD（月1本は無料）、V2 はアクション実行1分あたり0.002 USD（月100分は無料）です（2026年11月13日時点）。CodeBuild のビルド時間と S3 の料金は別にかかります。

Q. CodeBuild に無料枠はありますか？ A. general1.small か arm1.small のオンデマンド EC2 で月100分、1GB の Lambda で月6,000秒の無料枠があり、12か月の無料利用枠の期間が終わっても自動では切れない、と料金ページに書かれています。

Q. CodeDeploy は必ず要りますか？ A. 要りません。S3 への配置や CloudFormation、ECS など、CodePipeline のほかのデプロイアクションでも配れます。EC2・オンプレミスへの配布や、Blue/Green・Canary の切り替えを使いたいときに CodeDeploy を組み合わせます。

Q. GitHub のリポジトリをソースにできますか？ A. できます。GitHub への接続（CodeConnections）を作り、ソースアクションに CodeStarSourceConnection を選びます。接続を作るには GitHub の組織の所有者、またはリポジトリの所有者である必要があります。

Q. GitHub Actions とどちらがよいですか？ A. 優劣ではなく条件で選びます。デプロイ先が AWS で権限を IAM ロールで管理したいなら CodePipeline＋CodeBuild、ワークフローをリポジトリの中で管理して AWS 以外にも配るなら GitHub Actions が候補です。

Q. buildspec.yml を AWS に送る前に確かめる方法はありますか？ A. YAML として読み込めるか、フェーズ名と commands の形が正しいかを手元のスクリプトで確かめ、commands を同じ順番で bash で流すと、書き間違いの多くを先に見つけられます。この記事の例では、タブ・引用符のない **/*・: を含むコマンドをすべて手元で見つけました。

まとめ

• CodePipeline は流れの管理役。Source → Build → Deploy をアーティファクト名でつなぎ、実際の処理は CodeBuild・CodeDeploy などが行う。
• buildspec.yml は version 0.2 と4つのフェーズ。0.2 は同じシェルなので cd と export が残る。手元で 0.1 にすると変数が空になった。
• push の前に手元で確かめる。タブ・**/*・: を含むコマンドは YAML の読み込みで見つかる。パイプラインの JSON は botocore の API 定義で形を検証できる。
• V2 は QUEUED・PARALLEL・トリガーの絞り込みが使える。料金はアクション実行分で、この記事の3ステージでは月101回から V1 の1本分を上回った。
• GitHub Actions とは置き場所・実行環境・権限の渡し方が違う。デプロイ先と権限の管理の仕方で選ぶ。

参考・出典

確認日はいずれも 2026年11月13日です。

• AWS「AWS CodePipeline 料金」：https://aws.amazon.com/codepipeline/pricing/
• AWS「AWS CodeBuild 料金」：https://aws.amazon.com/jp/codebuild/pricing/
• AWS CodePipeline ユーザーガイド「とは AWS CodePipeline」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/welcome.html
• AWS CodePipeline ユーザーガイド「CodePipeline の概念」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/concepts.html
• AWS CodePipeline ユーザーガイド「パイプライン実行の仕組み」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/concepts-how-it-works.html
• AWS CodePipeline ユーザーガイド「パイプライン宣言」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/pipeline-requirements.html
• AWS CodePipeline ユーザーガイド「適切なパイプラインのタイプの選択」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/pipeline-types-planning.html
• AWS CodePipeline ユーザーガイド「AWS CodeBuild ビルドおよびテストアクションリファレンス」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/action-reference-CodeBuild.html
• AWS CodePipeline ユーザーガイド「CodeStarSourceConnection アクションリファレンス」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/action-reference-CodestarConnectionSource.html
• AWS CodePipeline ユーザーガイド「GitHub への接続」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/connections-github.html
• AWS CodePipeline ユーザーガイド「AWS CodePipeline のクォータ」：https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/limits.html
• AWS CodeBuild ユーザーガイド「buildspec の構文リファレンス」：https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html
• AWS CodeBuild ユーザーガイド「ビルドフェーズの移行」：https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/view-build-details-phases.html
• AWS CodeBuild ユーザーガイド「ビルド環境の環境変数」：https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-env-vars.html
• AWS CodeBuild ユーザーガイド「コンピューティングタイプ（ビルド環境）」：https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-compute-types.html
• AWS CodeBuild ユーザーガイド「AWS CodeBuild のクォータ」：https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/limits.html
• AWS CodeDeploy ユーザーガイド「CodeDeploy とは」：https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/welcome.html
• GitHub Docs「GitHub Actions を理解する」：https://docs.github.com/ja/actions/get-started/understand-github-actions
• GitHub Docs「GitHub Actions の課金」：https://docs.github.com/ja/billing/concepts/product-billing/github-actions

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。