--- title: "AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/3107/" published: 2024-07-19 updated: 2026-10-01 categories: ["AWS"] publisher: "株式会社一創" --- # AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説【2026年版】 AWS CodePipelineは、ソースコードの取得からビルド・テスト・デプロイまでの一連のリリース作業を自動でつなぐ、AWSのフルマネージドなCI/CD（継続的インテグレーション/継続的デリバリー）サービスです。開発者はステージとアクションを定義するだけでよく、実行基盤の管理は要りません。この記事では、CodePipelineの仕組みとAWS Codeシリーズでの役割、2026年10月時点のV1/V2パイプラインの料金と試算例、実行モードとトリガーフィルタの設定、CodeBuild・CodeDeployやTerraformとの連携、そしてGitHub Actionsとの使い分けまでを、公式ドキュメントの記述に沿って解説します。 ## まとめ：AWS CodePipelineの料金・V1とV2の選び方・採用判断の要点 - CodePipelineは**リリース工程の自動化を担う「指揮者」**で、ビルドはCodeBuild、デプロイはCodeDeployなど各サービスに処理を委ねる。 - パイプラインには**V1とV2の2タイプ**があり、料金体系が異なる。V1は**アクティブなパイプライン1本あたり月1USD**、V2は**アクション実行1分あたり0.002USD**（2026年10月時点）。新規はGitトリガーやロールバックを使えるV2が基本。 - 2024年以降、ステージレベルの条件・ロールバック・トリガーフィルタ・QUEUED/PARALLEL実行など**V2専用機能**が拡充された。 - Terraformの`aws_codepipeline`は**pipeline\_typeを省略するとV1**で作られる。IaCで作るときは明示が必須。 - ソースにはGitHub・GitLab・Bitbucket・S3などが使え、**CodeCommitは2024年に新規受付を停止したが2025年11月24日に一般提供へ復帰**し、新規アカウントでも再び利用できる。 デプロイ先がAWSに閉じ、IAMでの権限分離やマルチアカウント展開が要件にあるならCodePipeline。GitHub中心で小さく回すチームなら、GitHub Actionsで完結させるほうが設定の手数は少なく済みます。 ## AWS CodePipelineとは｜CI/CDでリリース工程をつなぐ役割と特徴 CodePipelineは、コードの変更をトリガーに「ソース → ビルド → テスト → デプロイ」という一連の工程を自動実行するサービスです。各工程を**ステージ**として定義し、ステージ間はアーティファクト（成果物）を受け渡しながら順番に進む仕組みです。手動でのビルド・デプロイ作業をなくすことで、リリースの遅延やヒューマンエラーを減らし、変更を安全かつ短時間で本番へ届けられます。CI/CDという考え方そのものや、パイプラインを構成する段階の分け方は[CI/CDの仕組みとパイプライン構成・導入判断の基準](https://www.issoh.co.jp/column/details/13002/)で整理しているので、用語に不安があれば先に目を通すと読み進めやすくなります。 特徴は、サーバーやジョブ実行環境を自前で用意しないマネージド型である点です。JenkinsのようにCI/CDサーバーを構築・維持する必要がなく、パイプラインの定義に集中できます。実行結果はコンソールやEventBridge経由で監視でき、失敗したステージだけを再実行することも可能です。 パイプラインの定義はJSON（またはCloudFormationのYAML）で表現され、コンソールで作ったものもCLIの`get-pipeline`で取り出せます。この「定義をコードとして持てる」性質が、後述するIaC連携や環境の複製につながります。 ## 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ファイルの書き方・記述例・エラー対処](https://www.issoh.co.jp/tech/details/7564/)で詳しく解説しています。In-PlaceとBlue/Greenのどちらで配信するかといったCodeDeploy側の設計判断は[AWS CodeDeployのIn-Place・Blue/Greenデプロイと料金の解説](https://www.issoh.co.jp/tech/details/15597/)が受け皿です。コンテナ中心の構成であれば、パイプライン定義を含めて管理してくれる[AWS Copilot](https://www.issoh.co.jp/tech/details/6801/)を使う選択肢もあります。 ソース候補で注意したいのがCodeCommitの扱いです。AWSは2024年7月25日にCodeCommitとCodeStarへの新規受付を停止し、CodeStarは2024年7月31日にサポートを終了しました。一時はCodeCommitも新規利用不可でしたが、[AWS DevOpsブログの発表](https://aws.amazon.com/blogs/devops/aws-codecommit-returns-to-general-availability/)のとおり**2025年11月24日に一般提供（GA）へ復帰し、新規アカウントでも再びリポジトリを作成できます**。同じ発表ではGit LFS対応が2026年第1四半期に予定されていました。2024年時点の「CodeCommitは新規で使えない」という古い解説が今も多く残っているため、選定前に公式情報で現況を確かめてください。 リポジトリをどこに置くかは、パイプラインの起動方式にも響きます。GitHub・GitLab・BitbucketはCodeConnections経由のため、後述するV2のトリガーフィルタ（ブランチ・パス・タグ・プルリクエスト単位の起動）をそのまま使えます。 ## CodePipelineの仕組み｜ステージ・アクション・アーティファクトの関係 CodePipelineの構造は「ステージ」「アクション」「アーティファクト」の3要素と、複数の実行をどうさばくかを決める「実行モード」で理解できます。 ### ステージとアクションの6カテゴリとV2で加わったCommandsアクション **ステージ**はリリース工程の区切りで、ソースステージ・ビルドステージ・デプロイステージのように並べます。各ステージには1つ以上の**アクション**を置き、実際の処理（コード取得、ビルド、承認、デプロイなど）を担当するのがアクションです。アクションには6種類のカテゴリ（Source / Build / Test / Deploy / Approval / Invoke）があり、同一ステージ内のアクションは並列にも直列にも構成できます。 2024年以降は、シェルコマンドを直接実行する**Commandsアクション**（Computeカテゴリ）も加わりました。[Commandsアクションの公式リファレンス](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Commands.html)によると、CodeBuildプロジェクトを作らずにコマンドを書けるかわりに、実体はCodePipeline管理のCodeBuildコンピューティングで動き、**CodeBuild側の料金が別途発生**します。使えるのはV2パイプラインのみで、1回の実行のタイムアウトは55分です。lintや簡単なスクリプト実行ならCommands、ビルドキャッシュやVPC内の依存を細かく制御したいなら従来どおりCodeBuildアクション、という切り分けになります。 先頭のソースステージは、リポジトリへのプッシュなどをきっかけに起動します。以降のステージはひとつ前のステージが成功したときだけ次へ進むため、テストに失敗すれば本番デプロイは実行されません。ビルドステージではCodeBuildが呼ばれ、コードのコンパイルや単体テストといった「ビルド」処理が行われます。CodeBuild自体の仕組み・ビルド環境・コンピューティングタイプ・料金・採用判断は[AWS CodeBuildとは何かを実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15595/)で詳しく確認できます。 ### アーティファクトの受け渡しとS3アーティファクトストアの暗号化 ステージ間でやり取りされる成果物が**アーティファクト**です。ソースステージが取得したコードは入力アーティファクトとして次のビルドステージへ渡り、ビルド後の実行ファイルやパッケージは出力アーティファクトとして後続のデプロイステージへ渡ります。これらの実体はパイプライン作成時に指定するAmazon S3バケット（アーティファクトストア）へ暗号化して保存されるため、S3の利用料が別途少額発生します。 既定の暗号化はAWS管理キーですが、別アカウントへデプロイする場合はカスタマー管理のKMSキーに切り替え、デプロイ先アカウントに復号権限を渡す必要があります。成果物をnpmやMavenのパッケージとして他チームへ配る場合は、S3ではなくレジストリ側に置く選択肢もあり、[AWS CodeArtifactによる私有パッケージの配布](https://www.issoh.co.jp/tech/details/17261/)が受け皿になります。 ### 実行モード3種類｜SUPERSEDED・QUEUED・PARALLELの挙動の違い 短い間隔で複数のコミットが入ったとき、パイプラインがどの実行を先に通すかは実行モードで決まります。[パイプライン実行の仕組みを説明した公式ページ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-how-it-works.html)の定義を整理すると次のとおりです。 | 実行モード | 挙動 | 対応タイプ | | -------------- | ----------------------- | ----- | | SUPERSEDED（既定） | ステージ前で待つ古い実行を新しい実行が追い越す | V1・V2 | | QUEUED | 到着順に1件ずつ処理し追い越しなし | V2のみ | | PARALLEL | 各実行が互いを待たずに同時進行 | V2のみ | 本番環境へのデプロイで「コミットの順番どおりに全部通したい」ならQUEUEDを選びます。PARALLELは機能ブランチごとに別の検証環境へ出す開発用途向けで、公式ページにも**PARALLELではステージロールバックが使えない**と明記されています。共有の本番環境にPARALLELを向けると、古い実行が後から完了して新しい成果物を上書きする事故が起こりうるため、本番には使いません。 ## V1とV2パイプラインの料金と機能の違い｜2026年10月時点の単価 CodePipelineには**V1**と**V2**の2つのパイプラインタイプがあり、料金体系と使える機能が異なります。[パイプラインタイプの公式説明](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types.html)では、V2はV1と同じ構造に「リリースの安全性とトリガー設定のための追加パラメータ」を持つ型と位置づけられています。選定で最初に確かめる項目です。 ### V1とV2の課金単位・無料枠・トリガー・実行モード・ロールバック比較 | 比較軸 | V1 | V2 | | ------------- | ----------------- | --------------------- | | 課金単位 | アクティブパイプライン単位 | アクション実行時間単位 | | 料金 | 月1USD／アクティブパイプライン | 0.002USD／アクション実行1分 | | 無料枠 | 月1本のアクティブパイプライン | アカウントで月100分 | | Gitトリガーフィルタ | 非対応 | タグ・ブランチ・PR・ファイルパス | | 実行モード | SUPERSEDEDのみ | 3種（QUEUED・PARALLEL含む） | | パイプライン変数 | 非対応 | 対応 | | ステージ条件・ロールバック | 非対応 | 対応 | [CodePipelineの公式料金ページ](https://aws.amazon.com/codepipeline/pricing/)によると、V1の「アクティブパイプライン」とは、作成から30日を超え、その月に1回以上コード変更が通ったパイプラインを指します。作成後30日間は無料で、変更のない月も課金されません。V2は使った分だけの従量課金で、**手動承認アクションとカスタムアクションは課金対象外**です。 ### 月の実行回数から見積もるV2料金の試算例とV1との損益分岐の目安 V2の請求額は「1回の実行で各アクションが動いた合計分数 × 月の実行回数」で決まります。単価と無料枠から、典型的な規模を試算すると次のようになります（2026年10月時点の単価で計算した概算）。 - **小規模**：1回あたりのアクション合計6分×月40回＝240分。無料枠100分を引いた140分×0.002USD＝**約0.28USD**。 - **中規模**：1回あたり10分×1日10回×30日＝3,000分。2,900分×0.002USD＝**約5.8USD**。 - **V1の同条件**：本数だけで決まり、上の2例はどちらも1本なら無料枠内、2本なら月1USD。 V2で月1USDに届くのは有料分が500分を超えたあたりです。1本のパイプラインを頻繁に回すと、V1より高くなるケースも出てきます。それでもV2を勧めるのは、トリガーフィルタで不要な起動を減らせるうえ、ロールバックやQUEUEDといった安全装置の価値が数USDの差を上回るからです。ビルドアクションの実行時間がそのまま課金分数になるため、長いテストをCodeBuild側で並列化すると両方の請求を抑えられます。CodeBuildとアーティファクト用S3の料金は別に発生する点も見積もりに含めてください。 ### 2024年以降に追加されたV2専用機能4つの内容と追加された時期 - **トリガーフィルタ**：特定のGitタグやブランチ、プルリクエスト、変更ファイルのパスに絞って起動できる（2024年2月）。 - **実行モード**：後続実行で先行を上書きするSUPERSEDED（既定）に加え、順番待ちのQUEUED、同時実行のPARALLELを選べる。 - **ステージレベル条件**：ステージの入場前・成功時・失敗時に、CloudWatchアラーム・デプロイ時間帯・Lambda・CodeBuild・シェルコマンド（Commandsルール、2025年3月）でゲートを設けられる（2024年8月）。 - **ステージロールバック**：失敗時に直前の成功実行へ手動/自動で戻せる。条件失敗時の挙動はSkip・Fail・Rollbackから選択（2024年4月）。 これから新規に作るなら、Gitトリガーや安全なロールバックを備えた**V2を選ぶのが基本**です。V1は既存資産の互換維持が目的の位置づけになっており、既存のV1パイプラインもコンソールや`update-pipeline`でV2へ変更できます。 ## CodePipelineの構築手順｜コンソール作成からCLI・JSON定義での再現まで ### コンソールのウィザードで作る最小構成のパイプラインと5つの手順 最小構成のパイプライン（ソース→ビルド→デプロイ）は、マネジメントコンソールの「パイプラインを作成」ウィザードから数分で作れます。おおまかな流れは次のとおりです。 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 aws codepipeline get-pipeline --name MyAppPipeline > pipeline.json ``` 3行目の`get-pipeline`で取り出したJSONは、`metadata`ブロックを除けば`create-pipeline --cli-input-json`にそのまま渡せます。コンソールで作った構成を検証用アカウントへ複製するときの近道です。 ### トリガーフィルタをJSONで定義しブランチとパス単位で起動条件を絞る設定 モノレポで「`services/api`配下が変わったときだけ動かしたい」といった要件は、V2のトリガーフィルタで表現します。[トリガーフィルタの公式手順](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-filter.html)にあるJSON構造をもとに、mainブランチへのプッシュとリリースタグの両方で起動する例を示します。 ``` "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "branches": { "includes": ["main"] }, "filePaths": { "includes": ["services/api/**"], "excludes": ["**/README.md"] } }, { "tags": { "includes": ["v*"] } } ] } } ] ``` ブランチやパスはglob形式で書き、同じパターンをincludesとexcludesの両方に入れると除外が優先されます。注意したいのは手動実行時の挙動で、トリガーでブランチを絞っていても、コンソールや`start-pipeline-execution`で起動するとソースアクションの`BranchName`に書いたブランチが使われます。プルリクエストのトリガーが反応するのは、作成・更新・クローズ（マージ）の3イベントだけです。 ### 手動承認アクションの7日タイムアウトとSNS通知による承認フロー デプロイ先が本番の場合は、ビルドステージとデプロイステージの間に**手動承認アクション**を挟むのが定石です。[手動承認の公式ガイド](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html)によると、パイプラインが承認アクションに到達してから**7日以内**に誰も承認・却下しないと、アクションは失敗扱いになり実行は先へ進みません。 承認待ちに気づかない事態を防ぐには、承認アクションにAmazon SNSトピックを設定し、メールやチャット連携のLambdaへ通知を流します。通知には確認してほしいURLとコメントを載せられるので、検証環境のURLを添えておくと承認者が判断しやすくなります。承認できるのは`codepipeline:PutApprovalResult`を許可したIAMロールだけに絞り、開発者本人が本番リリースを自己承認できない権限設計にしておくのが安全です。 ## CodeBuild・CodeDeploy・Terraformとの連携構成とIaC化の手順 CodePipeline単体はオーケストレーションに徹するため、CodeBuildやCodeDeployなどと組み合わせて初めて実用的なCI/CDになります。代表的な連携パターンと、パイプライン自体をコードで管理する方法を整理します。 ### CodeBuild・CodeDeploy・CloudFormationとの連携パターン ビルドをCodeBuild、デプロイをCodeDeployに委ねるのが標準構成です。インフラ自体をパイプラインで作る場合は、デプロイアクションにCloudFormationを指定し、テンプレートの作成・更新をパイプラインから実行します。`cloudformation codepipeline`のように、アプリと基盤の両方を1本のパイプラインで扱う構成もよく採用されます。 CloudFormationアクションでは、いきなり更新する`CREATE_UPDATE`より、変更セットを作る`CHANGE_SET_REPLACE`と実行する`CHANGE_SET_EXECUTE`の間に手動承認を挟む構成のほうが、意図しないリソース削除を止められます。スタック更新で設定が消える典型パターンは[AWS CloudFormationのテンプレートの書き方と更新で消える設定の防ぎ方](https://www.issoh.co.jp/tech/details/2927/)にまとめています。 ### Terraformでのパイプライン定義とpipeline\_typeがV1既定の落とし穴 パイプライン自体をコードで管理したい場合は、TerraformやCloudFormationで定義します。Terraformの`aws_codepipeline`リソースで気をつけたいのが既定値です。[Terraform AWS Providerのaws\_codepipelineドキュメント](https://github.com/hashicorp/terraform-provider-aws/blob/main/website/docs/r/codepipeline.html.markdown)には「`pipeline_type`の既定値はV1」と書かれており、省略するとトリガーフィルタもQUEUEDも使えないV1で作られます。V2を前提にした設計なら次のように明示します。 ``` resource "aws_codepipeline" "app" { name = "my-app-pipeline" role_arn = aws_iam_role.codepipeline.arn pipeline_type = "V2" execution_mode = "QUEUED" artifact_store { location = aws_s3_bucket.artifacts.bucket type = "S3" } stage { name = "Source" action { name = "Source" category = "Source" owner = "AWS" provider = "CodeStarSourceConnection" version = "1" output_artifacts = ["source_output"] configuration = { ConnectionArn = aws_codestarconnections_connection.github.arn FullRepositoryId = "my-org/my-app" BranchName = "main" } } } stage { name = "Build" action { name = "Build" category = "Build" owner = "AWS" provider = "CodeBuild" version = "1" input_artifacts = ["source_output"] output_artifacts = ["build_output"] configuration = { ProjectName = aws_codebuild_project.app.name } } } } ``` パイプラインの構成をバージョン管理でき、レビューと再現が容易になります。定義をリポジトリに置く考え方そのものは[Pipeline as Codeのメリットと実践方法](https://www.issoh.co.jp/tech/details/4276/)で詳しく扱っています。Terraformの実行基盤や状態管理を含めて運用するなら、[HCP Terraform（旧Terraform Cloud）](https://www.issoh.co.jp/tech/details/3340/)の利用も運用方法を選ぶ際の検討材料です。なお、Terraformの`plan`と`apply`自体をCodeBuildアクションとしてパイプラインに組み込めば、インフラ変更のレビューから適用までを自動化できます。同じことをGitHub Actions側でOIDC認証を使って組む手順は[GitHub ActionsとTerraformでAWSのCI/CDを構築する手順](https://www.issoh.co.jp/tech/details/2715/)が参考になります。 ## 導入前の注意点とGitHub Actionsとの使い分け｜採用条件と見送る場面 ### CodePipelineを採用する条件とGitHub Actionsで完結させる場面 CodePipelineは万能ではありません。CI/CDツールの選定では、GitHub Actionsとの比較が避けて通れません。判断の目安は次のとおりです。 - **CodePipelineが向く**：デプロイ先がAWS中心で、IAMやCodeDeploy・CloudFormationとの権限・連携をAWS内で完結させたい場合。開発/本番のアカウントを分けたマルチアカウント構成でのデプロイ制御や、CloudWatchアラームを条件にした自動ロールバックも得意。 - **GitHub Actionsが向く**：ソースがGitHubにあり、ビルド〜テストをリポジトリの近くで完結させたい場合や、マルチクラウド・多言語のワークフローを1か所で回したい場合。 「AWSを使っているから」という理由だけでCodePipelineを選ぶと、単純なビルド確認までにCodePipeline・CodeBuild・IAMロール・S3バケットと複数の設定が必要になり、かえって手間が増えます。GitHub中心の小規模チームでデプロイ先も1〜2環境なら、CodePipelineは見送り、GitHub Actionsで完結させたほうが速い。これが実務での判断軸です。Actions側の分単価や無料枠との比較は[GitHub Actionsの料金と2026年改定後の無料枠](https://www.issoh.co.jp/tech/details/16698/)で確認できます。CI/CDツール全体の選び方は[GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準](https://www.issoh.co.jp/tech/details/4219/)も参考になります。 逆に、本番アカウントへの書き込み権限をGitHub側に一切持たせたくない、監査でデプロイ経路をAWS CloudTrailに一本化したい、という要件があればCodePipelineを選ぶ理由になります。CIはGitHub Actions、AWSへのデプロイはCodePipelineと分担する併用構成もよく採られます。 ### クロスアカウントデプロイで失敗するIAMロールとKMSキーの設定漏れ クロスアカウントでデプロイする場合は、対象アカウントのIAMロールへの信頼関係とKMSキーの共有設定が前提になります。アーティファクトストアが既定のAWS管理キーで暗号化されていると、別アカウントのロールは成果物を復号できず、デプロイアクションが権限エラーで止まります。 対処は3点に集約されます。カスタマー管理のKMSキーに切り替えてキーポリシーで対象アカウントを許可すること、アーティファクト用S3バケットのバケットポリシーで対象アカウントのロールに読み取りを許すこと、アクション定義の`roleArn`に対象アカウント側のロールを指定することです。設定漏れはデプロイ失敗の典型的な原因なので、最初に権限設計を固めておくのが安全です。マルチアカウント構成のパイプライン設計やAWS基盤の構築を外部に任せたい場合は、[一創のAWS・クラウドのインフラ構築サービス](https://www.issoh.co.jp/service/system/aws/)でCI/CDを含めた設計からご相談いただけます。 ## CodePipelineのよくある質問｜料金・V1とV2・承認期限・CodeCommit codepipelineを調べる方から寄せられることの多い質問をまとめました。 ### CodePipelineの料金はいくらですか？ パイプラインタイプで異なります。2026年10月時点の公式料金ページでは、V1はアクティブなパイプライン1本あたり月1USD（無料枠は月1本、作成後30日間は無料）、V2はアクション実行1分あたり0.002USD（無料枠はアカウントで月100分）です。V2では手動承認とカスタムアクションは課金対象外です。別途、CodeBuildのビルド料金やアーティファクト保存用S3の利用料がかかります。 ### V1とV2はどちらを選ぶべきですか？ 新規に作るならV2が基本です。Gitタグ・ブランチ・ファイルパスによるトリガーフィルタ、QUEUED/PARALLELの実行モード、ステージレベルの条件とロールバック、Commandsアクションといった機能はV2でのみ使えます。V1は既存パイプラインの互換維持が主な用途です。Terraformで作る場合は`pipeline_type`を省略するとV1になるため、V2と明示してください。 ### 承認期限（手動承認のタイムアウト）はどのくらいですか？ 手動承認アクションは、パイプラインが承認アクションに到達してから7日以内に承認も却下もされない場合、失敗扱いとなる仕組みです。失敗したステージは再試行できますが、その間に新しい実行が来ると追い越される場合があります。SNSトピックで承認依頼を通知し、承認者と期限内の運用ルールをあらかじめ決めておくとリリースの停滞を防げます。 ### CodeCommitは今も新規で使えますか？ 使えます。2024年7月に新規受付が停止されましたが、2025年11月24日に一般提供へ復帰し、新規アカウントでもコンソール・CLI・APIからリポジトリを作成できる状態に戻りました。ただしGitHubやGitLabなど外部リポジトリもConnections経由でソースに指定できるため、既存のリポジトリ運用に合わせて選べます。CodeCommit自体の料金や使い方は[AWS CodeCommitのGA復活後の最新情報・料金・使い方](https://www.issoh.co.jp/tech/details/3447/)で解説しています。 ### GitHub ActionsとCodePipelineはどちらがよいですか？ デプロイ先がAWS中心で権限・連携をAWS内で完結させたいならCodePipeline、ソースがGitHubにありビルド〜テストをリポジトリ近くで回したい、あるいはマルチクラウドで扱いたいならGitHub Actionsが向きます。両者を併用し、CIをActions、AWSへのデプロイをCodePipelineに任せる構成も可能です。小規模チームで環境が少ないなら、まずGitHub Actionsだけで始めるのが手数の少ない選択です。 ## 関連記事 - [appspec.ymlとは？CodeDeployのAppSpecファイルの書き方・記述例・エラー対処](https://www.issoh.co.jp/tech/details/7564/)：CodeDeployアクションで使う定義ファイルの書き方 - [AWS Copilotとは何か？その基本概念と提供される価値](https://www.issoh.co.jp/tech/details/6801/)：コンテナ向けにパイプラインごと生成する選択肢 - [HCP Terraformとは？旧Terraform Cloud（名称変更）の機能・料金とHCPでの位置づけを解説](https://www.issoh.co.jp/tech/details/3340/)：パイプラインをIaC化するときの実行基盤 - [GitHubとGitLabの違い｜料金・Free枠・CI/CD・セルフホストを比較【2026年版】](https://www.issoh.co.jp/tech/details/4219/)：ソースとCI/CDの置き場所の比較 - [【2026年版】CI/CDツール比較8選｜無料枠と料金で選ぶ判断基準](https://www.issoh.co.jp/tech/details/1834/)：CodePipeline以外のCI/CDツールとの料金比較 --- 出典: [AWS CodePipelineとは？仕組み・料金・V1/V2の違いと構築手順を解説【2026年版】]()（株式会社一創）