KDOT

ビジネスサイドのための IT 用語集/開発手法・プロセス

CI/CDとは

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

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

CI/CD

CI/CDとは

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

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

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

なぜ必要か

複数の開発者が別々に作業し、数週間分の変更を最後に一括して統合すると、変更同士がぶつかります。どこで不具合が混入したかの特定にも時間がかかります。リリース前に統合とテストだけの期間を何週間も確保し、夜間や休日に手順書を参照しながら手作業で本番へ反映する進め方になりやすくなります。反映が重い作業になるほどリリースの回数は減少し、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は指標の解説で、反映の速さと安定性は二者択一ではなく、成績の良いチームは両方の指標で良好な結果を示すとしています。

判断の問い

見積もりにCI/CDの構築費が含まれている。更新の少ない小規模なシステムにも必要か？

本番への反映手順の自動化と、最低限の自動テストまでは小規模でも導入したほうがよいです。凝った仕組みは必要ありません。

更新が年に数回のシステムほど、反映の手順を記憶している人がいなくなります。そのため久しぶりの改修や担当者の交代で障害が発生しやすくなります。手順をパイプラインとして記述しておけば、それ自体が手順書を兼ねます。脆弱性が見つかって急いで反映しなければならない場面でも、手順の確認から着手する必要がありません。

開発者が1〜2人でリリースが年に数回、変更が文言や設定の修正程度なら、反映の自動化と主要な画面や処理の動作確認を数本用意すれば十分です。これが目安です。初期構築は数日から2週間程度で、クラウドのCIサービスの費用は無料枠から月数万円程度に収まることが多いです。CIを実行するサーバーを自社で構築する構成を選択すると、サーバー代と保守の手間が別にかかります。月に数回以上リリースするか、3人以上が同じコードを編集するなら、変更を取り込むたびに自動テストを実行する体制まで構築します。

本番環境を備えない用途では考慮しなくてかまいません。一度きりのデータ移行に使用するスクリプトや、数人が手元で実行するだけの集計ツールが該当します。

開発会社がCI/CDを整えているか、どう見極めればよいか？

使用しているツールの名前ではなく、本番への反映と切り戻しを実際にどう行っているかを質問します。CI/CDに対応という記載だけでは見極められません。

  • 本番への反映は誰がどの手順で行い、1回に何分かかるか
  • 変更を取り込むたびに自動で実行されるテストは何を確認していて、何分で完了するか
  • リリースで混入させた不具合を前のバージョンに切り戻す手順と所要時間
  • 直近数か月の反映回数と、そのうち修正や切り戻しが必要になった回数

反映を手作業の手順書に頼り、夜間や休日にしか実施できない体制では、継続的デリバリーは実現できていません。不具合を前のバージョンへ切り戻すのに半日以上かかる体制も同様です。目安として数十分以内に切り戻せるかを確認します。この目安はリリースで混入させた不具合に対するもので、サーバーの故障や災害からの復旧時間とは別に定めます。回数の数字は他社と比較せず、同じシステムで推移を確認します。DORAの指標の解説にもチームや組織の間で比較する使い方を避けるよう記載されています。

あわせて納品後にソースコードとパイプラインの設定を発注者のアカウントで保有できるかを確認します。開発会社のアカウントにしかないと、乗り換えや内製化のときに反映の仕組みを一から再構築することになります。

自動テストがほとんどない既存システムにCI/CDを導入すべきか？テストにどこまで投資すればよいか？

導入してかまいません。先に反映の自動化と切り戻しの手順を用意し、自動テストは停止すると影響の大きい業務から順に追加していきます。全機能のテストが完成してから着手する必要はありません。

反映の自動化はテストが少なくても効果が表れます。手作業による反映ミスと担当者への依存が解消されるためで、費用も少額で済みます。テストは変更が多い箇所と、障害が発生すると売上や業務が停止する箇所から作成します。受注・決済・請求額の計算などが典型例です。テストの網羅率を目標の数字にせず、本番で不具合が発生したらその箇所のテストを追加する運用で充実させていきます。

テストの作成と保守は継続的にかかります。重要な処理に限定すれば開発工数の1〜3割、手厚く作成すれば本体と同程度の工数が目安です。見積もりではテストの工数が別に示されているかを確認します。既存システムにテストを追加する作業は技術的負債の返済の一部でもあるため、負債返済の予算と二重に計上しません。導入の初期は手動確認の残りや旧来のコードの整理に手間がかかり、一時的にかえって遅くなることがあります。数か月単位で反映の所要時間と切り戻しの回数を確認して、投資を継続するかを決定します。

公開日
2026.10.21
更新日
2026.10.21

お問合せ

事業の課題や技術的な悩みなどどんなことでもお聞かせください

お問合せ