開発・エージェント

CI/CDとは

この記事の結論

CI/CDとは、変更を頻繁に取り込んで自動でビルドとテストを回すCI（継続的インテグレーション）と、リリースの準備や本番への反映を自動化するCD（継続的デリバリー／継続的デプロイ）を組み合わせた開発の進め方です。
CDには2つの意味があります。本番に出す直前まで自動で進めて最後は人が承認するのが継続的デリバリー、承認なしで本番まで自動で進むのが継続的デプロイです。
AIが書いたコードも、人が読む前に自動テストで一度ふるいにかけられます。どのテストを通すかを決めるのは人の側の仕事です。

しーあいしーでぃー／Continuous Integration / Continuous Delivery

変更のたびに自動でビルドとテストを回し、リリースの準備や本番への反映まで自動化する開発の進め方です。

最終更新: 2026-09-26

CI/CDとは何か（意味と読み方）

CI/CDとは、コードの変更を小刻みに取り込み、そのたびにビルドやテストを自動で走らせ、リリースまでの流れもできるだけ自動にする開発の進め方です。読み方は「しーあいしーでぃー」で、CIは Continuous Integration（継続的インテグレーション）、CDは Continuous Delivery（継続的デリバリー）または Continuous Deployment（継続的デプロイ）の略です。

AWSの解説What is Continuous Integration?では、CIを「開発者が変更を定期的に中央のリポジトリへマージし、そのあとに自動のビルドとテストが実行される」手法と定義しています。狙いとして、不具合を早く見つけて直すこと、品質を上げること、更新の検証とリリースにかかる時間を縮めることが挙げられています。

CI/CDの仕組み：CI・継続的デリバリー・継続的デプロイ

CI/CDの流れは「パイプライン」と呼ばれ、次の段階を順に進みます。

取り込み：プッシュやプルリクエストをきっかけに動き出す
ビルドとテスト（ここまでがCI）：コードを組み立て、自動テストや静的解析を実行する。1つでも落ちたらそこで止まる
検証用の環境への反映：本番に近いステージング環境へ自動で出す
本番への反映：利用者が使う環境へデプロイする

最後の段階をどう扱うかで、CDの意味が分かれます。AWSの継続的デリバリーの解説によると、継続的デリバリーでは変更ごとにビルドとテストを行い、本番以外の検証環境まで送ります。継続的デプロイとの違いは、本番の更新に人の手による承認があるかどうかです。継続的デプロイでは、明示的な承認なしに本番まで自動で反映されます。

AI開発でのCI/CDの具体例

GitHubでは、GitHub Actionsという機能でCIを組めます。継続的インテグレーション（GitHub Docs）によると、ワークフローはコードのプッシュのようなイベント、決めたスケジュール、外部からのWebhookをきっかけに動かせます。設定ファイルは、ワークフロー構文（GitHub Docs）にあるとおりリポジトリの .github/workflows に YAML 形式で置きます。

たとえば次のような短い設定で、プルリクエストが作られるたびにテストが走るようになります。

on: pull_request：プルリクエストをきっかけに動かす
runs-on: ubuntu-latest：実行する仮想マシンの種類
run: npm ci と run: npm test：依存関係を入れてテストを実行する

AIコーディングエージェントと組み合わせると、AIが作った変更をプルリクエストにした時点で自動テストが走り、結果が画面の Checks 欄に出ます。人は、テストが通った変更だけを読めば済みます。

LLMを組み込んだアプリでは、プロンプトを変えたときに評価（Evals）の質問集を自動で流し、点数が下がったら止める、という使い方もあります。最小構成の作り方はEvals（LLM評価）の始め方｜評価セット20件から始める最小構成で扱っています。

CI/CDについてのよくある誤解

誤解：CI/CDは特定のツールの名前 → 実際：進め方の名前です。GitHub Actions、GitLab CI/CD、Jenkins などは、それを実現するための道具です。
誤解：CDと付けば本番まで自動で出る → 実際：継続的デリバリーは本番の手前で人の承認を挟みます。承認なしで出るのは継続的デプロイのほうです。
誤解：CIを入れれば品質が上がる → 実際：CIが確かめるのは、書かれているテストの範囲だけです。テストが薄ければ、緑の表示でも不具合は通ります。
誤解：個人開発には大げさ → 実際：テストを1本走らせるだけの小さな設定からでも始められます。手で確認し忘れる作業を減らせます。

CI/CDを入れるときの注意点

鍵は設定ファイルに書かない：デプロイ用の鍵などは、サービス側の秘密情報の保管機能に入れて参照します。ワークフローのファイルはリポジトリに残るからです。
落ちたテストを消して通さない：AIに「CIを通して」と頼むと、テストを削ったり緩めたりする修正が返ってくることがあります。テストファイルの差分は省かずに読みます。
遅いパイプラインは使われなくなる：数十分かかる検査は、プルリクエストでは速いものだけを回し、重いものは取り込み後に回すなど分けて考えます。
本番への自動反映は戻し方とセットで：継続的デプロイにするなら、問題が出たときのロールバックの手順を先に用意しておきます。

出典・参考資料

よくある質問

Q1. CI/CDとは何ですか？
変更を小刻みに取り込んでそのたびに自動でビルドとテストを回すCIと、リリースの準備や本番への反映を自動化するCDを組み合わせた開発の進め方です。不具合を早く見つけ、リリースまでの手作業を減らすことを狙います。

Q2. 継続的デリバリーと継続的デプロイの違いは何ですか？
どちらも変更ごとにビルドとテストを行い、検証用の環境まで自動で進めます。違いは本番への反映で、継続的デリバリーは人の承認を経てから出し、継続的デプロイは承認なしで自動的に出します。

Q3. GitHubでCIを始めるには何が必要ですか？
リポジトリの .github/workflows フォルダにYAML形式の設定ファイルを置きます。いつ動かすか、どの環境で動かすか、どのコマンドを実行するかを書けば、プッシュやプルリクエストのたびにテストが自動で走ります。

Q4. CIが通ればコードは正しいと言えますか？
言えません。CIが確かめるのは、用意したテストや検査の範囲だけです。テストが足りなければ、表示が緑でも不具合は残ります。差分を人が読むレビューと組み合わせて使います。

Q5. AIにCIのエラーを直させるときの注意点はありますか？
テストを削除したり期待値を緩めたりして通そうとする修正が返ってくることがあります。直ったように見えても、テストファイルの差分を読み、実装の側が直っているかを確かめてから取り込みます。