継続的インテグレーション(Continuous Integration)
書いた変更を頻繁に統合し、そのつど自動でビルドとテストを行う進め方。問題を小さいうちに見つける。
もう少し詳しい説明
継続的インテグレーション(CI:Continuous Integration)は、各自が書いた変更を頻繁に統合し、そのつど自動でビルドとテストを行う進め方です。
まず、「統合」とは何か
チームでソフトウェアを作るとき、各自は自分の手元でソースを書き換えます。Aさんは画面を、Bさんは集計を、Cさんは帳票を、というように分かれて進みます。
書き換えたものは、そのままでは別々のままです。これを1つに合わせて、全体として動く状態にすることを統合(インテグレーション)と呼びます。
統合という作業そのものは、CIがあってもなくても必要です。 変わるのは、どれくらいの間隔で合わせるかだけです。CIの「継続的」は、ここを指しています。
まとめて合わせると何が起きるか
3人が別々の機能を1か月かけて作り、最後にまとめて合わせるとします。
| 起きること |
|---|
| 同じファイルを3人が直していて、合わせ方が分からない |
| 合わせたら動かなくなったが、どの変更のせいか分からない |
| 直すのに何日もかかる(統合地獄と呼ばれます) |
1か月ぶんの変更が一度にぶつかるので、原因の候補が多すぎます。 3人が1か月で書いた変更のどれが原因でもおかしくない、という状態です。
少しずつ合わせる
CIは、この間隔を1日に何度もに変えます。
壊れたとき、原因は「さっき入れた変更」にほぼ絞られます。 10分前に通っていたのなら、疑うのはその10分ぶんだけです。
変更の総量は、どちらも同じという点が大事なところです。作業が減るわけではなく、ぶつかる単位を小さくしているだけです。
何が自動で動くのか
誰かが変更を登録すると、CIサーバ(この自動の流れを受け持つ機械。サーバは、要求を受け取って応えを返す側の機械のこと)が自動で動き始めます。
| 順 | やること |
|---|---|
| 1 | 最新のソースを取ってくる |
| 2 | ビルドする(実行できる形に変換する) |
| 3 | 自動テストを流す |
| 4 | 書き方の検査をする(静的解析) |
| 5 | 結果を知らせる |
人は何もしません。 登録したら、しばらくして「通った」「壊れた」が届きます。
要るもの、守ること
CIサーバを置けば自動でうまくいく、という仕組みではありません。 先にそろえておく道具が2つ、チームで守る約束が2つあります。
そろえる道具
1つめは、バージョン管理(いつ誰が何を変えたかを記録し、前の状態に戻せるようにする仕組み)です。
Git(バージョン管理の道具で、いま広く使われているもの)などを使って、全員の変更が1か所に集まる状態を作ります。これが無いと、そもそも何と何を合わせるのかが決まりません。CIサーバが「最新のソース」を取ってこられるのは、置き場が1つに決まっているからです。
2つめは、自動テストです。ここがCIの本体にあたります。
自動テストが無いままCIを動かすと、確かめているのは「ビルドが通る」ことだけになります。ビルドが通るのは、文法の誤りが無いという意味でしかありません。計算結果が合っているかどうかは、誰も見ていない状態です。
守る約束
1つめは、ビルドとテストを短く保つことです。
結果が返るまでに何十分もかかると、人は待たずに次の作業へ進みます。壊れたと分かるころには、その上にさらに変更が積まれていて、せっかく小さくした「疑う範囲」がまた広がります。
2つめは、壊れたら直すことを最優先にすることです。
赤い表示を放置すると、次の人も赤いまま自分の変更を登録します。もう誰も「自分が壊したのか」を確かめられません。やがて赤が日常になり、誰も結果を見なくなります。こうなったCIは、動いてはいても何も守っていません。
道具の2つは買えますが、約束の2つは買えません。 CIがうまくいかない理由は、たいてい後ろ側にあります。
CD:その先の段階
CIと組で語られる言葉があります。
| 何をするか | どこまで自動か | |
|---|---|---|
| CI(継続的インテグレーション) | 統合して、ビルドとテスト | 検証まで |
| 継続的デリバリ(CD) | いつでも出せる状態まで用意する | リリース判断の直前まで |
| 継続的デプロイメント | 本番へ反映する | 本番まで |
継続的デリバリと継続的デプロイメントの違いは、本番へ出すかどうかです。
| 本番への反映 | |
|---|---|
| 継続的デリバリ | 人がボタンを押す |
| 継続的デプロイメント | 自動で出る |
どちらも「CD」と略されるため、どちらの話か文脈で読むことになります。試験では、本番まで自動かどうかで切り分けてください。
DevOpsは、この一連の流れを含む、より広い取り組みです。
試験ではこう出る
科目A(旧・午前)では、CIの目的がそのまま問われます。「頻繁に統合し、そのつど検証して問題を早期に発見する」が答えです。
CIとCDの違いも出ます。検証までがCI、出せる状態までがCD、本番まで自動なら継続的デプロイメントです。
成り立つ条件として、自動テストが前提であることも問われます。
応用情報では、統合の間隔を短くすることの効果が、手戻りの大きさと結び付けて問われます。
関連する用語
- DevOps
- 開発と運用をつなぐ取り組み。CIはその土台になる仕組み
- アジャイル開発
- 短い間隔で動くものを出す。CIがないと間隔を短くできない
- ホワイトボックステスト
- 自動で流すテストの中身。どの行を通ったかを測る
- リーンソフトウェア開発とバリューストリームマップ
- 待ち時間を減らす。CIは統合待ちをなくす手にあたる
ミニクイズ
継続的インテグレーション(CI)の目的として、最も適切なものはどれか。
正解は 4番:変更を頻繁に統合してそのつど検証し、問題を早期に発見する
CIは、各自が書いた変更を1日に何度も統合し、統合のたびに自動でビルドとテストを流して、壊れていないかを確かめる進め方です。問題を小さいうちに見つけることが目的になります。本番環境へ自動で反映するのは継続的デプロイメントで、CIのさらに先の段階です。変更履歴を記録して以前の状態に戻せるようにするのはバージョン管理で、CIが動くための前提ではありますが、CIそのものではありません。要求を優先順位を付けて一覧にするのはプロダクトバックログです。
この分野をまとめて解く → システム開発とユーザーインタフェースのミニテスト(全40問)
最終更新:2026-10-20