継続的インテグレーション(Continuous Integration)

分類
テクノロジ系 ソフトウェア開発管理技術
出る試験
基本情報応用情報
重要度
★★★★☆

書いた変更を頻繁に統合し、そのつど自動でビルドとテストを行う進め方。問題を小さいうちに見つける。

もう少し詳しい説明

継続的インテグレーション(CI:Continuous Integration)は、各自が書いた変更を頻繁に統合し、そのつど自動でビルドとテストを行う進め方です。

まず、「統合」とは何か

チームでソフトウェアを作るとき、各自は自分の手元でソースを書き換えます。Aさんは画面を、Bさんは集計を、Cさんは帳票を、というように分かれて進みます。

書き換えたものは、そのままでは別々のままです。これを1つに合わせて、全体として動く状態にすることを統合(インテグレーション)と呼びます。

統合という作業そのものは、CIがあってもなくても必要です。 変わるのは、どれくらいの間隔で合わせるかだけです。CIの「継続的」は、ここを指しています。

まとめて合わせると何が起きるか

3人が別々の機能を1か月かけて作り、最後にまとめて合わせるとします。

起きること
同じファイルを3人が直していて、合わせ方が分からない
合わせたら動かなくなったが、どの変更のせいか分からない
直すのに何日もかかる(統合地獄と呼ばれます)

1か月ぶんの変更が一度にぶつかるので、原因の候補が多すぎます。 3人が1か月で書いた変更のどれが原因でもおかしくない、という状態です。

少しずつ合わせる

CIは、この間隔を1日に何度もに変えます。

まとめて合わせる1か月ぶんが一度にぶつかる(疑う変更が多すぎる)少しずつ合わせる合わせて検証合わせて検証合わせて検証合わせて検証
帯の長さはどちらも1か月ぶんの変更で、同じ量です。違うのは区切りの数=合わせた回数です。上は最後に1回だけ合わせるので、壊れたときに疑う変更が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