遅いCI/CDを改善して開発速度を戻す進め方
「プルリクエストを出してからマージできるまで、CIの完了待ちだけで小一時間かかる」「レビュー自体は5分で終わったのに、CI待ちで結局その日のうちにリリースできない」——開発チームからよくいただく相談です。最初はテストを書けば書くほど品質が上がるはずだと考えて増やし続けた結果、いつの間にかCIが「開発を守るための仕組み」から「開発を止める仕組み」に変わってしまっている、というケースは少なくありません。
厄介なのは、CIが遅いこと自体はエラーでもバグでもないため、誰も緊急対応が必要な問題として扱わないことです。日々の業務では「今日中に直したいバグ」の方が優先され、CIの遅さは「まあ我慢すればいい」と後回しにされ続けます。しかしCIの完了待ちは、1回あたり数十分でもエンジニアの人数×1日あたりの実行回数を掛け合わせると、月あたり数十時間〜百時間規模の待ち時間になっていることが珍しくありません。この記事では、遅くなったCI/CDパイプラインの原因を切り分け、開発速度を取り戻すための改善の進め方を整理します。
なぜCI/CDは徐々に遅くなっていくのか
CIは最初から遅かったわけではなく、たいていはプロダクトの成長とともにじわじわ遅くなっていきます。原因はいくつかのパターンに分類できます。
- テストを全件毎回実行している: 変更したファイルに関係のないテストまで含めて、コミットのたびにテストスイート全体を毎回フルで実行している。テスト数がプロダクトの成長とともに増え続け、実行時間も比例して伸びていく
- 並列化されていない: テストが1つのジョブの中で直列に実行されており、複数のマシン・ワーカーに分散させれば数分で終わる処理を1台で回し続けている
- 依存関係のインストールを毎回ゼロから行っている:
bundle installやnpm installのたびに全パッケージをネットワーク経由でダウンロード・ビルドしており、キャッシュが効いていない - ビルドが重い: アセットのコンパイルやDockerイメージのビルドなど、コードの変更内容に関わらず毎回フルビルドが走っている
- 不要なステップが残り続けている: 過去のある時点で必要だった検証ステップが、要らなくなった後も惰性で残っている。誰も「これ本当に必要か」を見直していない
- CIサービスのプラン・インスタンススペックが実態に合っていない: 小さいインスタンスのまま実行数だけが増え、キューで待たされる時間がボトルネックになっている
これらは単独ではなく複合していることがほとんどです。「テストが多いから遅い」と決めつけて安易にテストを削ると、今度は本番不具合が増えるという別の問題を招きます。まずは実際の実行ログから、どのステップに時間がかかっているかを計測するところから始めるべきです。
遅さの原因を計測して切り分ける
改善に着手する前に、感覚ではなく数字で「何が時間を食っているか」を可視化します。
- ステップごとの実行時間を洗い出す: GitHub Actionsなら各ジョブ・各ステップの実行時間はログから確認できる。依存関係のインストール、テスト実行、ビルド、デプロイのそれぞれに何分かかっているかを一覧化する
- 直列実行されている箇所を探す: 本来並列にできるのに1つのジョブにまとめられている処理がないかを確認する
- キャッシュのヒット率を確認する: 依存関係のキャッシュが正しく効いているか、毎回キャッシュミスして再インストールが走っていないかをチェックする
- 待ち時間と実行時間を区別する: CIのキューで順番待ちしている時間と、実際に処理が走っている時間は別物。前者が長いならインスタンス数やプランの見直しが必要になる
この計測を怠って「とりあえずテストを並列化してみよう」と場当たり的に手を入れると、本当のボトルネックを直さないまま工数だけ消費することになります。私たちが改善に入る際も、必ず最初の1〜2日はこの計測フェーズに充て、どこに手を入れれば最も効果が大きいかを特定してから着手します。
具体的な改善アプローチ
原因が切り分けられたら、それぞれに対応した改善策を適用していきます。
- テストの並列化・分割: テストスイートを複数のグループに分割し、複数のワーカーで同時実行する。GitHub Actionsのmatrix機能やテストランナーの並列実行オプションを使えば、実行時間を台数分の1近くまで縮められることが多い
- 依存関係のキャッシュ活用:
bundle install・npm installなどの結果をロックファイルのハッシュ値をキーにしてキャッシュし、変更が無ければ再利用する。これだけで数分単位の短縮になることが多い - 変更範囲に応じたテストの絞り込み: 変更されたファイルに関連するテストだけを実行する仕組みを取り入れ、フルテストはmainブランチへのマージ時やスケジュール実行に限定する
- 不要なステップの削減: 現状のCI設定を棚卸しし、今も必要なステップかどうかをチームで確認する。使われなくなった通知・検証ステップは削除する
- ビルドの差分ビルド化: Dockerイメージのレイヤーキャッシュを活用する、変更の無いアセットは再ビルドしないなど、フルビルドを避ける工夫を入れる
- デプロイフローの見直し: リリース関連の改善はリリースの実績反映を直す取り組みとあわせて整理すると、CIからデプロイまで一連の流れとして速度を底上げしやすい
これらは一度に全部やる必要はありません。計測結果から最も時間を食っている箇所を1〜2個選び、効果を確認しながら順に手を入れていくのが現実的です。
開発体験への影響は数字よりも大きい
CIの遅さがもたらす影響は、単純な「待ち時間×回数」の計算以上に大きいというのが私たちの実感です。
- 集中力が途切れる: CIの完了を待つ間に別の作業に移り、戻ってきたときに文脈を思い出すコストが発生する。「ながら待ち」は生産的なように見えて、実際には切り替えコストがかさむ
- レビューのテンポが落ちる: CIが通らないとレビューを依頼しづらい文化のチームでは、CIが遅いほどレビュー依頼自体が滞留する
- リリース頻度が下がる: 1回のリリースにかかる時間が長いほど、こまめなリリースを避けて変更をまとめてリリースする方向に流れやすくなる。変更が大きくなるほど不具合発生時の切り分けも難しくなる
- 新しいメンバーの立ち上がりが遅れる: 入社したばかりのエンジニアが最初に触れる開発体験がCIの遅さだと、その後の生産性イメージにも影響する
CI改善は地味に見えますが、開発チーム全体の生産性とモラールに直結する投資対効果の高い改善です。
外部に依頼するときの進め方
CI/CDの改善を外部チームに依頼する場合、いきなり設定ファイルをいじり始めるのではなく、次の順で進めると安全です。
- 現状のCI実行ログを共有する: 直近数週間〜1ヶ月分の実行時間の推移とステップごとの内訳を渡す
- 計測・原因切り分けから始めてもらう: いきなり改善提案を求めるのではなく、まず何がボトルネックかを特定するフェーズを設ける
- 小さく試して効果を確認する: 一部のジョブから並列化・キャッシュ導入を試し、効果が確認できたら他のジョブにも展開する
- CI設定自体をコードレビューの対象にする:
.github/workflowsなどの設定ファイルも通常のコードと同様にレビューし、変更履歴を残す
弊社では保守・改善支援の一環としてCI/CDパイプラインの改善にも対応しています。AWS上のCI環境やインフラ構成(インフラ構築・運用)とあわせて見直すことで、CIだけでなくデプロイ全体のリードタイム短縮まで一気通貫で改善できます。また、CI改善は既存プロダクト改善の一部分でしかないため、まず全体像を把握したい場合は既存プロダクト改善の最初のチェック項目もあわせてご覧ください。
まとめ
- CIの遅さはエラーではないため後回しにされがちだが、待ち時間を人数×回数で積み上げると月あたり数十〜百時間規模の損失になっている
- 改善はまず計測による原因の切り分けから。並列化・テスト分割・依存キャッシュ・不要ステップ削減を、効果の大きいところから順に適用する
- CI改善はエンジニアの集中力・レビューのテンポ・リリース頻度に直結し、投資対効果の高い改善である
CI/CDが遅くて開発速度が落ちていると感じたら、まずは現状の実行ログを見せていただくところから始められます。診断、または継続的な改善支援で対応していますので、お問い合わせからお気軽にご相談ください。