AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説

AWS CodePipelineは、ソースコードの取得からビルド・テスト・デプロイまでの一連のリリース作業を自動でつなぐ、AWSのフルマネージドなCI/CD（継続的インテグレーション/継続的デリバリー）サービスです。開発者はステージとアクションを定義するだけでよく、実行基盤の管理は不要です。この記事では、CodePipelineの仕組みとAWS Codeシリーズでの役割、V1/V2パイプラインの料金と機能の違い、構築手順、CodeBuild・CodeDeployやTerraformとの連携、そしてGitHub Actionsとの使い分けまでを、最新のアップデートを踏まえて解説します。

まとめ：この記事の要点

• CodePipelineはリリース工程の自動化を担う「指揮者」で、ビルドはCodeBuild、デプロイはCodeDeployなど各サービスに処理を委ねる。
• パイプラインにはV1とV2の2タイプがあり、料金体系が異なる。V1はアクティブなパイプライン1本あたり月1USD、V2はアクション実行1分あたり0.002USD。新規はGitトリガーやロールバックを使えるV2が基本。
• 2024年以降、ステージレベルの条件・ロールバック・トリガーフィルタ・並列実行などV2専用機能が拡充された。
• ソースにはGitHub・GitLab・Bitbucket・S3などが使え、CodeCommitは2024年に新規受付を停止したが2025年11月24日に完全GA復帰し、新規アカウントでも再び利用できる。

以降で、定義・仕組みから料金と構築手順までを順に見ていきます。

AWS CodePipelineとは（CI/CDにおける役割）

CodePipelineは、コードの変更をトリガーに「ソース → ビルド → テスト → デプロイ」という一連の工程を自動実行するサービスです。各工程をステージとして定義し、ステージ間はアーティファクト（成果物）を受け渡しながら順番に進みます。手動でのビルド・デプロイ作業をなくすことで、リリースの遅延やヒューマンエラーを減らし、変更を安全かつ短時間で本番へ届けられます。

特徴は、サーバーやジョブ実行環境を自前で用意しないマネージド型である点です。JenkinsのようにCI/CDサーバーを構築・維持する必要がなく、パイプラインの定義に集中できます。実行結果はコンソールやEventBridge経由で監視でき、失敗したステージだけを再実行することも可能です。

AWS Codeシリーズでの役割とCodeCommitの現況

CodePipeline単体はビルドやデプロイの処理そのものを行いません。役割は各サービスを呼び出して工程を連結するオーケストレーション（指揮）です。そのため、実際のCI/CDは以下のAWS Codeシリーズや外部サービスと組み合わせて構成します。

• ソース：GitHub、GitLab、Bitbucket（いずれもCodeConnections経由）、Amazon S3、Amazon ECR、AWS CodeCommit
• ビルド/テスト：AWS CodeBuild（コンパイル・単体テスト・Dockerイメージ作成などを実行）
• デプロイ：AWS CodeDeploy、AWS CloudFormation、Amazon ECS、AWS Lambda など

デプロイ工程で使うCodeDeployは、EC2やECSへの配信ルールをappspec.ymlで定義します。書き方はappspec.ymlとは？CodeDeployのAppSpecファイルの書き方・記述例・エラー対処で詳しく解説しています。コンテナ中心の構成であれば、パイプライン定義を含めて管理してくれるAWS Copilotを使う選択肢もあります。

ソース候補で注意したいのがCodeCommitの扱いです。AWSは2024年7月25日にCodeCommitとCodeStarへの新規受付を停止し、CodeStarは2024年7月31日にサポートを終了しました。一時はCodeCommitも新規利用不可でしたが、2025年11月24日に完全な一般提供（GA）へ復帰し、新規アカウントでも再び利用できる状態に戻っています。2024年時点の「CodeCommitは新規で使えない」という古い解説が今も多く残っているため、最新の状況を公式ドキュメントで確認したうえで選定してください。

CodePipelineの仕組み（ステージ・アクション・アーティファクト）

CodePipelineの構造は「ステージ」「アクション」「アーティファクト」の3要素で理解できます。

ステージとアクション

ステージはリリース工程の区切りで、ソースステージ・ビルドステージ・デプロイステージのように並べます。各ステージには1つ以上のアクションを置き、アクションが実際の処理（コード取得、ビルド、承認、デプロイなど）を担当します。アクションには6種類のカテゴリ（Source / Build / Test / Deploy / Approval / Invoke）があり、同一ステージ内のアクションは並列にも直列にも構成できます。2024年以降はシェルコマンドを直接実行するCommandsアクション（Computeカテゴリ）も加わりました。

先頭のソースステージは、リポジトリへのプッシュなどをきっかけに起動します。以降のステージはひとつ前のステージが成功したときだけ次へ進むため、テストに失敗すれば本番デプロイは実行されません。ビルドステージではCodeBuildが呼ばれ、コードのコンパイルや単体テストといった「ビルド」処理が行われます。CodeBuild自体の仕組み・ビルド環境・コンピューティングタイプ・料金・採用判断はAWS CodeBuildとは何かを実装者目線で解説した記事で詳しく確認できます。

アーティファクトの受け渡し

ステージ間でやり取りされる成果物がアーティファクトです。ソースステージが取得したコードは入力アーティファクトとして次のビルドステージへ渡り、ビルド後の実行ファイルやパッケージは出力アーティファクトとして後続のデプロイステージへ渡ります。これらの実体はパイプライン作成時に指定するAmazon S3バケット（アーティファクトストア）へ暗号化して保存されるため、S3の利用料が別途少額発生します。

V1とV2パイプラインの料金と機能の違い

CodePipelineにはV1とV2の2つのパイプラインタイプがあり、料金体系と使える機能が異なります。ここが選定で最初に押さえるべきポイントです。

V1の「アクティブパイプライン」とは、作成から30日を超え、その月に1回以上コード変更が発生したパイプラインを指します。作っただけで変更のない月は課金されません。V2は使った分だけの従量課金で、手動承認アクションとカスタムアクションは実行時間に含めても課金されません。無料枠はV1が月1本、V2がアカウント全体で月100分です。実際の料金は構成と実行頻度で変わるため、最新の単価は公式の料金ページで確認してください。

V2でしか使えない主な機能は次のとおりで、いずれも2024年以降に追加されたものです。

• トリガーフィルタ：特定のGitタグやブランチ、プルリクエスト、変更ファイルのパスに絞って起動できる（2024年2月）。
• 実行モード：後続実行で先行を上書きするSUPERSEDED（既定）に加え、順番待ちのQUEUED、同時実行のPARALLELを選べる。
• ステージレベル条件：ステージの入場前・成功時・失敗時に、CloudWatchアラーム・デプロイ時間帯・Lambda・CodeBuild・シェルコマンド（Commandsルール、2025年3月）でゲートを設けられる（2024年8月）。
• ステージロールバック：失敗時に直前の成功実行へ手動/自動で戻せる。条件失敗時の挙動はSkip・Fail・Rollbackから選択（2024年4月）。

これから新規に作るなら、Gitトリガーや安全なロールバックを備えたV2を選ぶのが基本です。V1は既存資産の互換維持が目的の位置づけになっています。

CodePipelineの構築手順

最小構成のパイプライン（ソース→ビルド→デプロイ）は、マネジメントコンソールの「パイプラインを作成」ウィザードから数分で作れます。おおまかな流れは次のとおりです。

1. パイプライン名とパイプラインタイプ（V2）を指定し、アーティファクト用のS3バケットとサービスロールを設定する。
2. ソースプロバイダ（GitHub等）を選び、Connections経由でリポジトリとブランチ、必要なら起動条件（トリガーフィルタ）を指定する。
3. ビルドステージでCodeBuildプロジェクトを指定する（buildspec.ymlでビルド手順を記述）。
4. デプロイステージでCodeDeploy・CloudFormation・ECSなどの配信先を指定する。
5. 作成後、ソースへプッシュするか、以下のCLIで手動実行して動作を確認する。

aws codepipeline start-pipeline-execution --name MyAppPipeline
aws codepipeline get-pipeline-state --name MyAppPipeline

デプロイ先が本番の場合は、ビルドステージとデプロイステージの間に手動承認アクションを挟むのが定石です。承認アクションには応答期限があり、既定では7日間承認されないとタイムアウトして失敗扱いになります。承認者や期限内の運用ルールを決めておくと、リリースの停滞を防げます。

他サービス・IaCとの連携

CodePipeline単体はオーケストレーションに徹するため、CodeBuildやCodeDeployなどと組み合わせて初めて実用的なCI/CDになります。代表的な連携パターンを整理します。

CodeBuild・CodeDeploy・CloudFormationとの連携

ビルドをCodeBuild、デプロイをCodeDeployに委ねるのが標準構成です。インフラ自体をパイプラインで作る場合は、デプロイアクションにCloudFormationを指定し、テンプレートの作成・更新をパイプラインから実行します。cloudformation codepipelineのように、アプリと基盤の両方を1本のパイプラインで扱う構成もよく採用されます。

Terraformでのパイプライン定義（IaC）

パイプライン自体をコードで管理したい場合は、TerraformやCloudFormationでaws_codepipelineリソースを定義します。パイプラインの構成をバージョン管理でき、レビューと再現が容易になります。Terraformの実行基盤や状態管理を含めて運用するなら、HCP Terraform（旧Terraform Cloud）の利用も検討材料になります。なお、Terraformのplanとapply自体をCodeBuildアクションとしてパイプラインに組み込めば、インフラ変更のレビューから適用までを自動化できます。

導入前に押さえる注意点とGitHub Actionsとの使い分け

CodePipelineは万能ではありません。特にCI/CDツールの選定では、GitHub Actionsとの比較が避けて通れません。判断の目安は次のとおりです。

• CodePipelineが向く：デプロイ先がAWS中心で、IAMやCodeDeploy・CloudFormationとの権限・連携をAWS内で完結させたい場合。マルチアカウント構成（開発/本番のアカウント分離）でのデプロイ制御も得意。
• GitHub Actionsが向く：ソースがGitHubにあり、ビルド〜テストをリポジトリの近くで完結させたい場合や、マルチクラウド・多言語のワークフローを1か所で回したい場合。

「AWSを使っているから」という理由だけでCodePipelineを選ぶと、単純なビルド確認までに複数サービスの設定が必要になり、かえって手間が増えることがあります。GitHub中心の小規模チームで、デプロイ先も限定的なら、単純なビルド確認までに複数サービスの設定を要するCodePipelineより、GitHub Actionsで完結させたほうが速いケースが多いのが実務での判断軸です。CI/CDツール全体の選び方はGitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準も参考になります。

また、クロスアカウントでデプロイする場合は、対象アカウントのIAMロールへの信頼関係とKMSキーの共有設定が前提になります。設定漏れはデプロイ失敗の典型的な原因なので、最初に権限設計を固めておくのが安全です。

よくある質問

CodePipelineの料金はいくらですか？

パイプラインタイプで異なります。V1はアクティブなパイプライン1本あたり月1USD（無料枠は月1本）、V2はアクション実行1分あたり0.002USD（無料枠はアカウントで月100分）です。V2では手動承認とカスタムアクションは課金対象外です。別途、アーティファクト保存用S3などの利用料がかかります。

V1とV2はどちらを選ぶべきですか？

新規に作るならV2が基本です。Gitタグ・ブランチ・ファイルパスによるトリガーフィルタ、並列実行、ステージレベルの条件とロールバックといった機能はV2でのみ使えます。V1は既存パイプラインの互換維持が主な用途です。

承認期限（手動承認のタイムアウト）はどのくらいですか？

手動承認アクションは、既定で7日間承認されないとタイムアウトして失敗扱いになります。承認者や、期限内に承認するための通知・運用ルールをあらかじめ決めておくとリリースの停滞を防げます。

CodeCommitは今も新規で使えますか？

使えます。2024年7月に新規受付が停止されましたが、2025年11月24日に完全な一般提供へ復帰し、新規アカウントでも利用できる状態に戻りました。ただしGitHubやGitLabなど外部リポジトリもConnections経由でソースに指定できるため、既存のリポジトリ運用に合わせて選べます。

GitHub ActionsとCodePipelineはどちらがよいですか？

デプロイ先がAWS中心で権限・連携をAWS内で完結させたいならCodePipeline、ソースがGitHubにありビルド〜テストをリポジトリ近くで回したい、あるいはマルチクラウドで扱いたいならGitHub Actionsが向きます。両者を併用し、CIをActions、AWSへのデプロイをCodePipelineに任せる構成も可能です。あわせて、AWS CodeCommitについても解説しています。

関連記事

• appspec.ymlとは？CodeDeployのAppSpecファイルの書き方・記述例・エラー対処
• AWS Copilotとは何か？その基本概念と提供される価値
• HCP Terraformとは？旧Terraform Cloud（名称変更）の機能・料金とHCPでの位置づけを解説
• GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準