開発手法・プロセス

CI/CDとは

しーあいしーでぃー / CICD / CI / CD / 継続的インテグレーション/継続的デリバリー / Continuous Integration / Continuous Delivery

ソースコードの変更をこまめに取り込み、自動でテストして、いつでも本番に反映できる状態を維持する開発の進め方とその仕組みです。リリースが速くなるほか不具合を混入させたときに前のバージョンへ切り戻しやすくなります。

公開
2026.10.21
更新
2026.10.22
CI/CD

CI/CDとは

CI/CDはCI(Continuous Integration)とCD(Continuous Delivery)の総称です。日本語ではそれぞれ継続的インテグレーション、継続的デリバリーと訳します。CIは各開発者の変更を小さな単位でこまめに共通のソースコードへ取り込む進め方です。取り込むたびにテストを自動で実行し、変更同士の矛盾を早期に発見します。CDはテストに合格した変更を、いつでも本番環境へリリースできる状態に維持することを指します。リリースの手順は自動化しておき、リリースの時期だけを人が決定します。

工場でいえば月末にまとめて行っていた出荷前の試験を、製品が1つできるたびに試験装置へ通す方式に変更するのに近いです。試験に合格した製品はいつでも出荷でき、出荷の時期は別に決定できます。

GitHub ActionsのようなCIサービスは、この進め方を自動で実行するためのサービスにあたります。変更の取り込みからテスト、本番への反映までを自動でつないだ処理はパイプラインと呼びます。

変更の取り込み・自動テスト・反映可能な状態を経た後に人の判断で本番へ反映する流れ

なぜ必要か

複数の開発者が別々に作業し、数週間分の変更を最後に一括して統合すると、変更同士がぶつかります。どこで不具合が混入したかの特定にも時間がかかります。リリース前に統合とテストだけの期間を何週間も確保し、夜間や休日に手順書を参照しながら手作業で本番へ反映する進め方になりやすくなります。反映が重い作業になるほどリリースの回数は減少し、1回に含まれる変更が増加して、失敗したときの影響も拡大します。

変更を集約して反映する場合と、小規模な変更を頻繁に反映する場合の1回あたりの変更規模の違い。集約するほど失敗時の切り戻し範囲も拡大する

CDの考え方を整理したcontinuousdelivery.comは、統合とテストのための期間やコードの凍結期間をなくすことを目的に挙げています。

開発と運用の分断を組織と文化の面から解消しようとする考え方がDevOpsで、CI/CDはそれを支える技術的な実践の1つに位置づけられます。

効果

  • 小さな変更をすぐに本番へ反映でき、要望や不具合への対応が迅速になる
  • 不具合が混入した変更を特定しやすく、前のバージョンへ切り戻す判断と作業も速くなる
  • 反映の手順が仕組みとして保持され、特定の担当者の記憶や手作業に依存しなくなる
  • 休日や深夜の反映作業と、そのための待機が減少する
  • いつ誰のどの変更が本番に反映されたかの記録が保存され、障害調査や監査で追跡できる

コストとリスク

費用

  • 自動テストの作成と保守が最も大きな費用になる。テストが不十分なまま仕組みだけ導入しても、不具合はそのまま本番で発生する
  • パイプライン自体の保守が続く。ツールや外部から取り込んで利用するプログラムの更新、失敗したときの原因調査に人手がかかる
  • CIサービスの利用料はテストなどの実行時間に応じて増加する
  • テストとパイプラインを設計・保守できる人材が必要になる。導入の最大の壁はテストを記述する技術の不足であることが多い

リスク

  • 結果が日によって変化する不安定なテストを放置すると、失敗の通知が常態化して誰も確認しなくなる
  • パイプラインには本番環境へ反映する権限と、本番環境にアクセスするための認証情報を配置する。設定に不備があれば不正な反映や情報漏えいが発生する。パイプラインに組み込む外部のプログラムが改ざんされた場合も、その権限や認証情報を悪用される。2025年3月には広く利用されていたGitHub Actions用の公開プログラムが改ざんされ、2万を超えるリポジトリで認証情報の漏えいのおそれが生じた
  • プログラムのバージョンを切り戻しても、データベースの構造を変更した反映や、外部のシステムへ送信済みのデータは元の状態に復元されない。こうした変更は切り戻しの方法を別に設計しておく
  • ツールを導入しても進め方が変化しなければ効果は表れない。各自の手元で変更を長期間保留したままCIサービスでビルドしていても、継続的インテグレーションとはいえない。手順や設計を変更せずに反映の回数だけ増やすと、失敗が増加してチームが疲弊する。開発と運用の実践を調査しているDORA(DevOps Research and Assessment)の解説も、よくある失敗としてこの形とツール導入だけで終了する形を挙げている

よくある誤解

CI/CDを導入すると変更が自動で本番に反映されてしまう

テストを通った変更を人の判断を挟まずに自動で本番へ反映する運用は継続的デプロイと呼び、継続的デリバリーとは別の運用です。継続的デリバリーはいつでも反映できる状態を保つことまでを指し、反映するかどうかとその時期は事業側が決定してかまいません。DORAも両者は混同されやすいが別の実践だとしています。スマートフォンアプリや機器に組み込むソフトウェア、規制のある業種は継続的デプロイに向きませんが、継続的デリバリーは実践できます。承認の手順を維持したまま導入してかまいません。

テストに合格した変更について、反映時期を人が決定する継続的デリバリーと、自動で反映する継続的デプロイの分岐

リリースの回数を増やすほど障害が増加する

1回あたりの変更が小規模になるため、失敗の原因を特定しやすく、切り戻す作業も軽くなります。DORAは指標の解説で、反映の速さと安定性は二者択一ではなく、成績の良いチームは両方の指標で良好な結果を示すとしています。