CI/CDってなに？ — 手作業の自動化と「なぜ嬉しい」
📖 このページのゴール：「CI」と「CD」が何の略で、何をしてくれるのかを、たとえ話で腹落ちさせます。手作業でありがちな失敗（テスト忘れ／「自分の環境では動くのに」／手デプロイ事故）が、自動化でどう消えるのかまで分かれば合格です。 ← 目次・はじめにへもどる
🟢 まず結論：CI/CD は「いつもの面倒」を機械にやらせること
コードを書いたあと、毎回こんなこと、していませんか？
- テストを手で走らせて、通るか確かめる
- ビルドして、エラーが出ないか確かめる
- 問題なければ、サーバーやサイトにアップする
どれも地味だけど大事で、しかも忘れる・間違えるのが人間です。この「いつもの面倒」を、コンピュータに毎回・自動で・同じようにやらせる——これが CI/CD（シーアイ・シーディー） です。
このガイドの背骨は、これ一行だけ。
手でやっていた繰り返し作業（テスト・ビルド・チェック・デプロイ）を、コンピュータに“毎回・自動で・同じように”やらせる。
🏭 たとえ：CI/CD は「工場のベルトコンベア」
いちばん近いイメージは、工場のベルトコンベアです。あなたが部品（コード）を乗せると、あとは流れていくだけで、検査も箱詰めも出荷も勝手に進みます。
あなた：コードを commit / push（ベルトに乗せる）
│
▼ （ここから先は、ぜんぶ自動で流れる）
[ テスト ] → [ ビルド ] → [ 検査(lint/型/セキュリティ) ] → [ 出荷(デプロイ/リリース) ]
│
▼
壊れていれば、その場でブザー（即お知らせ）
問題なければ、そのまま本番へ
うれしいのは、人は「中身を作ること」に集中できること。退屈で間違えやすい検査や出荷は、コンベアがいつも同じ品質で引き受けてくれます。
🔧 ちなみに：このコンベアを GitHub の中だけで動かせるのが、次のページで学ぶ GitHub Actions です。このページではまず「コンベアって何が嬉しいの？」を押さえます。
🟢 CI と CD を、ことばからほどく
「CI/CD」とまとめて呼びますが、じつは前半（CI）と後半（CD）で役割がちがいます。コンベアでいうと、前半が「検査」、後半が「出荷」です。
| 略語 | 何の略？ | やさしく言うと | コンベアでいうと |
|---|---|---|---|
| CI | 継続的インテグレーション （Continuous Integration） |
コードを上げるたびに、自動でテスト／ビルドして「壊れてないか」を確認する | 部品が流れるたびに検査する |
| CD | 継続的デリバリー／デプロイ （Continuous Delivery / Deployment） |
CI が通ったら、自動で届ける（デプロイ・リリース） | 検査をパスした品を出荷する |
- CI ＝「毎回こわれてないか確認」。コミットやプルリクエスト（PR）のたびに、機械が自動でチェックします。壊れていれば、その場で気づけるのがポイント。
- CD ＝「自動で届ける」。CI のチェックを全部パスしたものだけを、サーバーやサイトへ自動でアップします。「最後の手作業」をなくす役です。
🔧 「デリバリー」と「デプロイ」の細かい違い：デリバリー＝本番へ出す一歩手前まで自動（最後の「えいっ」ボタンだけ人間）、デプロイ＝本番まで丸ごと自動。最初は「CD＝自動で届ける」とざっくり覚えればOKです。
😊 なぜ嬉しい？（4つ）
手作業をコンベアに任せると、いいことが大きく4つあります。
| うれしいこと | なぜ？ | |
|---|---|---|
| ① | ミスが減る | 人は忘れる・サボる。機械は毎回・同じようにやる。テストやチェックを「うっかり飛ばす」が起きない |
| ② | 速い・ラク | チェックを待たずに並行で回せて、手作業から解放される。空いた時間で本来の開発ができる |
| ③ | 安心してマージ／リリースできる | 壊れていればすぐ気づけるので、壊れたコードをそのまま入れてしまわない |
| ④ | チームの品質が揃う | だれが上げても同じ環境で同じチェック。「自分のパソコンでは動いたのに」を防げる |
ひとことで言えば、「人の気合い」ではなく「しくみ」で品質を守れるようになります。気合いは続きませんが、しくみは続きます。
💥 手作業だと、こんな事故が起きる → 自動化で防ぐ
「自動化って大げさでは？」と思うかもしれません。でも、手作業のままだとあるある事故が必ず起きます。代表的な3つを、自動化でどう消えるかとセットで見てみましょう。
| 手作業だと… | 何が起きる？ | CI/CD だと？ |
|---|---|---|
| 😱 テスト忘れ | 急いでいて npm test を流し忘れ、壊れたコードをそのままマージ。後で他の人が踏んで大騒ぎ |
push / PR のたびに自動でテスト。壊れていればマージをブロックできる（CI） |
| 😱 「自分の環境では動くのに」 | 自分のパソコンだけにある設定やバージョン違いのせいで、他の人やサーバーでは動かない | いつもまっさらな同じ環境でテスト・ビルドするので、環境差が原因のバグに早く気づく（CI） |
| 😱 手デプロイで事故 | 本番へアップする手順を1ステップ間違える／古いものを上げてしまう。深夜の作業でうっかり | 毎回まったく同じ手順で自動デプロイ。人の手順ミスが入り込まない（CD） |
ポイントは、どれも「人が頑張れば防げる」けれど、人はいつかミスするということ。CI/CD は、その「いつか」をしくみで先回りして潰します。
🟢 だから最初の一歩は、いちばん事故が多い「テスト忘れ」を自動化するのがおすすめ。「push したら自動でテスト」だけでも、安心感がぐっと変わります（やり方は第3章で）。
🟢 ひとことで言うと
CI/CD ＝ テスト・ビルド・チェック・デプロイという「いつもの面倒」を、機械に毎回・自動でやらせるしくみ。 前半の CI が「毎回こわれてないか確認」、後半の CD が「自動で届ける」。ミスが減り、速く、安心してリリースでき、チームの品質も揃う——「気合い」ではなく「しくみ」で品質を守れるようになります。
➡️ 次へ
このコンベアを GitHub の中で動かす正体が「GitHub Actions」です。次のページで、その「○○したら△△する」のしくみ（トリガー → ジョブ → ステップ）をのぞいてみましょう。
次のページ：GitHub Actions のしくみ — トリガー → ジョブ → ステップ → ← 目次・はじめにへもどる