DevOps の CI/CD 入門 — 継続的インテグレーション/デリバリーで「速く・安全に」届ける

DevOps 基本編の第3回では、CI/CD を扱います。CI/CD は「ツールを入れて自動化する話」に見えがちですが、本質は 手動・属人的なビルド、テスト、デプロイを減らし、小さな変更を安全に届け続ける仕組み です。

第2回で見た Four Keys のうち、特に デプロイ頻度 と 変更リードタイム に直結します。一方で、速度だけを追うと「失敗も速く届く」状態になりかねません。品質確認、承認、証跡、セキュリティをパイプラインに組み込むことが重要です。

なぜ CI/CD なのか

手動デプロイが中心の組織では、次のような問題が起きやすくなります。

• リリース手順が担当者の記憶や手元メモに依存する
• リリース直前に大きな統合作業が発生する
• テスト実行や確認観点が人によって揺れる
• 失敗時に「何を、いつ、誰が、どこへ反映したか」を追いにくい

CI/CD は、これらを 再現可能な流れ に変えます。変更が入ったらビルドし、テストし、成果物を作り、必要なゲートを通して環境へ届ける。この一連の流れをパイプラインとして定義します。

現場への影響は大きく、リリース作業そのものよりも「リリース前の調整会議」「統合待ち」「手順確認」といった待ち時間を減らせます。筆者の評価として、CI/CD の価値は単なる高速化ではなく、同じ品質確認を繰り返せること、証跡が残ること、属人性を下げられること にあります。

背景として、近年はソフトウェアサプライチェーン攻撃への警戒が高まり、CI/CD 自体も守るべき資産として扱われています。OWASP の CI/CD Security Risks や NIST SSDF のような考え方が広がり、今後は署名、依存関係チェック、来歴管理、権限最小化がパイプラインの標準的な要素になっていくでしょう。

CI：頻繁に統合し、すぐに壊れを見つける

CI、つまり継続的インテグレーションは、変更を頻繁にメインラインへ統合し、自動ビルドと自動テストで状態を確認する実践です。

ポイントは次の3つです。

1. 変更を小さく保つ
2. 頻繁にマージする
3. ビルドとテストを自動で実行する

長期間のフィーチャーブランチに変更を溜めると、統合時に衝突や仕様の食い違いがまとめて表面化します。これがいわゆる「統合地獄」です。CI は、問題を後工程に送らず、早い段階で発見するための仕組みです。

現場では、CI が整うとレビュー担当者やテスターの負担も変わります。人が見るべきなのは、コンパイルできるか、基本的なテストが通るかではなく、設計意図や仕様の妥当性です。筆者としては、CI は DevOps の中でも投資対効果が出やすい領域だと考えています。ただし、テストが遅すぎる、失敗が不安定、壊れても放置される、という状態では信頼されません。CI はツールよりも運用規律が成果を左右します。

CD：デリバリーとデプロイの違い

CD には、似た言葉として Continuous Delivery と Continuous Deployment があります。

推進担当が最初から自動本番反映を目指す必要はありません。まずは「いつでも出せる」状態、つまり継続的デリバリーを作るほうが現実的です。そのうえで、リスク許容度や事業特性に合わせて自動化範囲を広げます。

ここで重要なのが、デプロイ と リリース の分離です。デプロイは環境へ配置すること、リリースはユーザーに機能を公開することです。フィーチャーフラグを使うと、コードは本番に置きつつ、機能公開は段階的に制御できます。

パイプラインの基本構成

CI/CD パイプラインの最小構成を示します。

この図で押さえたいのは、ソース変更からデプロイまでを一続きの流れとして扱う点です。承認ゲートを置けば継続的デリバリー、自動通過させれば継続的デプロイに近づきます。

各ステージの役割は次の通りです。

• ソース：Pull Request やマージをきっかけにパイプラインを起動する
• ビルド：依存関係の取得、コンパイル、パッケージ化を行う
• テスト：ユニット、統合、E2E などで品質を確認する
• 成果物保存：どのコミットから作られた成果物か追跡できるようにする
• デプロイ：ステージングや本番環境へ反映する

近年はここに、依存関係スキャン、シークレット検出、SBOM 生成、署名、ポリシーチェックなどを組み込む流れが強まっています。筆者の意見として、これらは後付けの監査作業にするより、開発者が普段通るパイプラインに入れたほうが定着しやすいです。一方で、チェックを増やしすぎると開発速度を落とすため、共通テンプレートと例外フローの設計が欠かせません。

トランクベース開発、小さな PR、フィーチャーフラグ

CI/CD と相性がよい開発スタイルが、トランクベース開発です。これは、長期間ブランチを分け続けるのではなく、短いサイクルでメインラインへ統合する考え方です。

その実践を支えるのが、小さな PR とフィーチャーフラグです。

• 小さな PR はレビューしやすく、衝突も起きにくい
• 短い変更はテスト失敗時の原因を追いやすい
• フィーチャーフラグにより、開発中の機能を隠したまま統合できる
• デプロイとリリースを分けられるため、公開タイミングを制御しやすい

従来の長期フィーチャーブランチと比べると、トランクベース開発は統合リスクを前倒しで処理できます。これは Four Keys の改善に直結します。

ただし、筆者はフィーチャーフラグを万能策とは見ていません。フラグが増えすぎると、組み合わせが複雑になり、テストや運用の負債になります。導入時点で「いつ消すか」「誰が管理するか」を決めておくことが重要です。

自動テストはパイプラインの信頼性を決める

自動テストは、CI/CD の安全性を支える中心です。代表的な段階は次の通りです。

現場への影響として、テストが速く安定しているほど開発者は小さく頻繁に変更できます。逆に、E2E が多すぎて毎回長時間待つ状態になると、PR が大きくなり、CI/CD の効果が薄れます。

筆者の評価では、導入初期はユニットテストと主要な統合テストに注力するのがよいです。キャッシュや並列化はリードタイム短縮に有効ですが、設定が複雑化すると「通るはずのものが落ちる」「落ちるはずのものが通る」という不信感につながります。今後は、速さだけでなく パイプラインの信頼性 も運用指標として見る組織が増えるでしょう。

ツール選定で見るべきこと

代表的な CI/CD ツールには、GitHub Actions、GitLab CI/CD、Jenkins、CircleCI などがあります。クラウドサービスと統合しやすいもの、セルフホストしやすいもの、組織ポリシーを適用しやすいものなど、特徴はさまざまです。

推進担当としては「どのツールが一番か」よりも、次の観点で見るべきです。

• 標準テンプレートを配布しやすいか
• 権限、シークレット、依存関係を統制しやすいか
• 実行履歴や承認履歴を追跡しやすいか
• チームごとの自由度と組織ガードレールを両立できるか

GitHub Actions も GitLab CI/CD も、近年はセキュリティやポリシー管理を強化しています。背景には、CI/CD がソフトウェア供給網の中核になったことがあります。今後のツール選定では、実行速度や料金だけでなく、監査性と統制のしやすさがより重視されるはずです。

Four Keys への効き方

CI/CD は、Four Keys のうち特に次の2つに効きます。

• デプロイ頻度：小さな変更を流しやすくなり、リリース単位を小さくできる
• 変更リードタイム：ビルド、テスト、デプロイの待ち時間を短縮できる

ただし、デプロイ頻度とリードタイムだけを見ると、品質低下に気づきにくくなります。変更失敗率や復旧時間も合わせて見ることで、「速く届ける」と「安全に届ける」のバランスを保てます。

ここで大切なのは、指標を個人評価の道具にしないことです。CI/CD と Four Keys は、チームの流れを改善するための共通言語として使うべきです。詰まりがどこにあるのか、手作業がどこに残っているのかを可視化し、改善の優先順位を決める材料にします。

推進担当が最初に整える一歩

CI/CD 導入の第一歩は、自動デプロイではなく ビルドとテストの自動化 です。おすすめの進め方は次の通りです。

1. 既存のリリース手順を棚卸しする
2. PR またはマージ時にビルドを実行する
3. ユニットテストをパイプラインに組み込む
4. 成果物をコミット ID と紐づけて保存する
5. パイプライン時間、失敗率、変更リードタイムを測る
6. 小さな PR とトランクベース開発へ段階的に寄せる

最初から全サービスに展開するより、影響範囲を決めたプロダクトで成功例を作るほうが進めやすいです。現場にとってのメリット、たとえば「リリース手順確認が減った」「レビュー前に基本的な不具合が落ちる」「本番反映の証跡が残る」を見せることが、組織展開の後押しになります。

CI/CD は、単に速くリリースするための仕組みではありません。変更を小さくし、品質確認を自動化し、必要な統制をパイプラインに組み込み、チームが安心して改善を届け続けるための基盤です。次回は、その基盤を支える IaC とコンテナの考え方へ進みます。