非公開ユーザー
株式会社コアコンセプト・テクノロジー｜ソフトウェア・SI｜ITアーキテクト｜300-1000人未満｜ユーザー（利用者）｜契約タイプ 分からない
CI/CDツールで利用
良いポイント
CodeBuild、CodeDeploy、ECS、Lambda、CloudFormation、S3 などとの連携が標準アクションで用意されており、認証情報の受け渡しを自前で実装する必要がない。GitHub Actions などで AWS にデプロイすると OIDC や IAM ロールの設計が必要になるが、CodePipeline は IAM ロール 1 つで完結する。
改善してほしいポイント
GitHub Actions や GitLab CI のように、リポジトリ内に .codepipeline.yml を置いて宣言的に管理する方式が公式に欲しい。現状は CloudFormation や CDK 経由で書くしかなく、パイプライン定義のためだけに IaC を学ぶコストが高い。リポジトリ内の YAML が標準化されれば、開発者が自分の手元でパイプラインを直感的に編集でき、レビューもしやすくなる。
GitHub Actions のように「feature ブランチが作られたら自動でプレビュー環境をデプロイ、PR がマージされたら削除」というフローが組みづらい。ブランチ単位の動的パイプラインがネイティブで組めれば、プレビュー環境の運用がぐっと楽になる。
どのような課題解決に貢献しましたか？どのようなメリットが得られましたか？
導入前は、本番デプロイを特定のインフラ担当者がSSH経由で手動実施しており、手順書の解釈のズレや作業漏れによるリリース事故が月1〜2件発生し、深夜・休日対応も担当者に集中していた。
CodePipelineで「ソース取得 → ビルド → ステージング検証 → 手動承認 → 本番デプロイ」を完全自動化した結果：
リリース事故が月1〜2件 → 四半期0〜1件に減少
1回あたりのデプロイ作業時間が平均90分 → 10分（承認操作のみ）に短縮
特定担当者への依存が解消され、アプリ開発者自身がリリース可能になった
検討者へお勧めするポイント
ワークロードの大半が AWS 上にあるなら、他社 CI/CD より圧倒的に楽。IAM ロールで認証が完結し、OIDC 連携やシークレット管理の設計が不要。「AWS にデプロイするためだけに外部 CI の認証情報を管理する」というよくある悩みがそもそも発生しない。ECS、Lambda、CloudFormation、S3 などへのデプロイは標準アクションで数クリック。
