CodePipelineを活用してCI/CDパイプラインの実行時間を抑えながら自動テストを強化しました
株式会社アップガレージグループ / takumi.shiki
メンバー / SRE / 従業員規模: 301名〜500名 / エンジニア組織: 11名〜50名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2025年8月 | B to C |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2025年8月 |
| 事業形態 | B to C |
アーキテクチャ

アーキテクチャの意図・工夫
Playwrightのテストを複数ブラウザで並列実行
Playwright(E2Eテストフレームワーク)はブラウザの種類を指定してテストを実行できます。自動テストで最低限動作を担保するべきパターンとして Mobile Safari と Chromium のテストを実行する CodeBuild プロジェクトをそれぞれ用意し、並列でビルドを実行することで、全体の実行時間を抑えつつ自動テストを拡充しました。
プルリクエスト用パイプライン
上の図はデプロイ用パイプラインですが、それとは別にプルリクエスト用のパイプラインも用意しました。
コストの問題
Playwright を実行する CodeBuild プロジェクトは、プロセスがメモリ不足で異常終了してしまう問題を解消するためスペックを引き上げました。ただし、これをプルリクエストのソースブランチが更新されるたびに実行することはコスト面の懸念がありました。
そこで、デプロイ用とは別にプルリクエスト用の自動テストのみ実行するパイプラインを用意し、そこでは、リントとユニットテストを合格しない限り Playwright を実行しないようにしました。
GitHubコミットステータスとCodePipelineビルドステータスの同期について
CodePipelineはビルドステータスがGitHubなどのサードパーティー製ソースプロバイダーに通知されないため、通知する仕組みを自前で用意する必要があります。
AWSの公式ブログで、GitHubのREST APIを実行してビルドステータスをGitHubに通知するAWS Lambda関数を作成するためのCloudFormationテンプレートが紹介されています。作業量はやや多いですが、記事の内容に従うだけでビルドステータスの同期を実現できます。
また、記事には書かれていませんが、ステータスの同期だけでなく、プルリクエストの作成者のメンション付きメッセージをプルリクエストに投稿するといったことも可能で、運用面の様々なニーズに対して応用が利くと思います。
ソースプロバイダーとのビルドステータスの同期や、ビルド完了をトリガーとしたオートメーションは、開発体験のよいCI/CDパイプライン運用には必須かと思いますので、CodePipelineを導入する場合は合わせて設定することをおすすめします。
導入の背景・解決したかった問題
導入背景
2025年当時、弊社では多くのプロダクトでAWS CodeBuildをCI/CDパイプラインそのものとして利用していました。
AWS CodeBuildはその名のとおりCI/CDパイプラインの中でもビルド処理を担うサービスですが、パイプラインがシンプルなビルド処理で間に合うのであれば、CodeBuildのみでパイプラインを構築することは実用上多いと思います。
今回CodePipelineを導入した、弊社の主要事業であるアップガレージのサービスサイト(https://www.upgarage.com/)のフロントエンドアプリケーションでも、パイプラインは当初単一のCodeBuildプロジェクトで構築していました。
2024年にEC機能をリニューアルした際に Playwright を商品検索ページに導入し、しばらくはCI上でも実行していました。ところが、その後テストを他ページにも拡充したところCIの実行時間が大幅に長くなってしまい、開発やリリース作業に支障を来すため一時的に停止せざるをえなくなりました。
商品検索ページはリニューアル後も継続的に機能改善を行っており、開発による既存機能への影響を考えると Playwright を利用しない状態は非常に危険でしたので、 Playwright の復旧をマネージャーチームに強く上申し、承認を頂きました。
最初は別の方が Playwright の実行プロセスの改善による時間短縮を試みましたが上手くいかなかったため、ワークフローを並列化して時間短縮する方針を変更し、CodePipelineの導入に至りました。
比較検討したサービス
2025年当時は原則としてCI/CDパイプラインをAWSに構築する方針だったため、サービスの比較は行っていません。
ただし、オーケストレーション機能が近年充実してきているGitHub Actionsを現在一部のアプリケーションで試験的に導入しており、今ならGitHub Actionsも検討対象になったと思います。(GitHub Actionsを司令塔として、リントなど軽微なプロセスをGitHub Actionsで賄い、各種自動テストなど重めのプロセスやAWSと連携するCD部分をCodePipelineに任せる、といったハイブリッド方式が最近のトレンドかと思います。)
導入の成果
改善したかった課題はどれくらい解決されたか
元々は単一の CodeBuild プロジェクトでリント、ユニットテスト、E2Eテストをすべて直列で実行する構成になっており、60分以上かかっておりました。(毎回CIの実行に60分以上かかるのが運用に耐えないことは明らかなので正確な時間は計っておりません。)
CodePipeline に移行したことで、デプロイ用パイプラインでは15分、プルリクエスト用パイプラインでは20分に時間を短縮できました。
なお、今回のケースでは、推計で月間150ドル程度のコスト増加となりました。(他にもコスト変動の要因が多数あるため正確な計測はできていません。)
どのような成果が得られたか
CIへの Playwright 導入と実行時間の短縮を両立したことで、商品検索ページの不具合を開発中に迅速に検知できるようになりました。
導入時の苦労・悩み
CodeBuildからCodePipelineへのパイプライン移行で最も大変だったのは、CodeBuildプロジェクト単体のパイプラインで使用していた環境変数のほとんどが使用できなくなり、GitHubリポジトリからのデータの取得を設定しなおす必要があったことです。
元々、アクションの実行制御や、CIの結果をSlackに通知するために、GitHubのリポジトリ名、プルリクエストのID、リリースタグなどビルドトリガーの情報を環境変数から取得していました。変更前はビルドのトリガーがGitHubだったので、CodeBuild側で用意されている環境変数を参照すれば必要な情報をすべて取得できました。
今回ビルドトリガーがGitHubではなくCodePipelineになったことで、GitHubに関する情報はCodePipelineから渡さなければなりませんでした。しかし、AWSの公式ドキュメントにCodePipelineから渡せる環境変数に関する完全な情報が記載されておらず、実際に渡されている環境変数をすべて確認するにはCodePipelineコンソールを参照する必要がありました。(AWSは非常に便利なサービスですが、ドキュメントの品質がよくないことがあるのが玉に瑕ですね。。。)

導入に向けた社内への説明
上長・チームへの説明
多少のコスト増加は Playwright を稼働させて不具合を事前に検知するための必要経費として許容することになっていたのと、この開発を行う前に大きなコスト削減を実現できていたため、導入時に詳細な費用対効果の検証は行っていません。
ただ、 Playwright を実行する CodeBuild プロジェクトのスペック引き上げについては大きなコスト増加が予想されるため、ワークフロー設計についてマネージャーチームと議論して決定しました。
活用方法
よく使う機能
CodePipelineの機能をマニュアルで使用することは基本的にありません。
ツールの良い点
- 複雑なワークフローをコンソール上で簡単に構築できること
- パイプラインの状態をコンソール上で簡単に確認できること
- パイプラインのスペックを柔軟に調整できること
- AWSの他機能と連携した高度なオートメーションを実現できること
ツールの課題点
CodePipelineよりもCodeBuildの問題ですが、コンテナの起動に時間がかかります。「比較したサービス」でも言及しましたが、パイプラインが軽量の場合はGitHub Actionsのほうがコストパフォーマンスがよい可能性があります。
株式会社アップガレージグループ / takumi.shiki
メンバー / SRE / 従業員規模: 301名〜500名 / エンジニア組織: 11名〜50名
2018年4月〜現職 入社以来、 upgarage.com や tokyo-tire.com などエンドユーザー向けウェブサイト全般の開発・保守・一部運用を担当してきました。(現在もしばしばヘルプに駆り出されています。) 一時はBtoBのECサイトであるネクスリンクも担当しました。 現在は、SRE(という名の何でも屋さん)、自社システムの情報セキュリティ対策、全社の情報セキュリティマネジメントを担当しています。
株式会社アップガレージグループ / takumi.shiki
メンバー / SRE / 従業員規模: 301名〜500名 / エンジニア組織: 11名〜50名
2018年4月〜現職 入社以来、 up...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


