CI/CDとは何か — GitHub Actionsで開発を自動化する理由 - GitHub ActionsでCI/CDをはじめる

GitHub Actionsは、GitHubに組み込まれた自動化プラットフォームです。コードをpushしたら自動でテストが走る、Pull Requestを出したらlintが自動でチェックされる、mainにマージされたら自動でデプロイされる——そうした「開発の定型作業」を、リポジトリに置いたYAMLファイル1つで実現できます。

この章では、いきなりYAMLを書き始める前に、「そもそもCI/CDとは何か」「なぜ自動化が必要なのか」という土台から整理していきます。

学習者

CI/CDって言葉はよく聞くんだけど、正直「デプロイを自動でやるやつ」くらいのイメージしかなくて…。テストの自動化とは別物なの？

その疑問はもっともです。CIとCDは別の概念ですが、セットで語られることが多いので混ざりやすいんです。順番にほどいていきましょう。

自動化がない世界を想像する

まず、CI/CDが何を解決しているのかを知るために、「すべて手作業」の開発フローを考えてみます。

あなたはチームで開発しており、機能を1つ実装し終えました。ここからやるべきことを並べてみると——

ローカルでテストを実行する（忘れることがある）
lintを実行する（忘れることがある）
型チェックを実行する（忘れることがある）
Pull Requestを出す
レビュワーが「テスト通ってますか？」と確認する
マージ後、誰かがビルドしてサーバーにアップロードする
アップロード後、動作確認をして問題があれば手で戻す

この運用には、構造的な問題があります。

人間は忘れる — テストを実行し忘れたまま壊れたコードがマージされる
人によって手順が違う — 「私のPCでは通ったのに」が頻発する
デプロイが怖くなる — 手順が属人化し、特定の人しかリリースできなくなる
壊れたことに気づくのが遅い — マージから数日後に「実は動いていなかった」と発覚する

問題が発覚するタイミングが遅いほど、原因の特定は難しくなります。1日分のコミットがまとめて壊れていたら、どのコミットが原因かを探すだけで一苦労です。

CI — 継続的インテグレーション

CI（Continuous Integration / 継続的インテグレーション） は、この「気づくのが遅い」問題への答えです。

考え方はシンプルで、コードに変更が加わるたびに、テスト・lint・ビルドを自動で実行して、壊れていないかを毎回確認するというものです。

コードをpush
   ↓ （自動）
lint・型チェック・テスト・ビルドが実行される
   ↓
✅ 全部通った → 安心してレビュー・マージへ
❌ 何かが落ちた → その場で通知が来る。壊したコミットは明確

壊れた瞬間に検知できるので、原因は「たった今pushしたコミット」に絞られます。修正コストが最小のうちに問題を潰せる——これがCIの本質的な価値です。

学習者

なるほど、「継続的に統合する」って、変更をこまめに合流させて、そのたびに自動チェックするってことなんだ。

そのとおりです。「インテグレーション（統合）」は、各自の変更をメインのブランチに合流させることを指します。統合を小さく・頻繁に・自動チェック付きで行うので「継続的インテグレーション」と呼ばれます。

CD — 継続的デリバリー/デプロイメント

CDはCIの続きにある考え方で、テストを通過したコードを、自動でリリース可能な状態まで運ぶことを指します。

実はCDには2つの意味があります。

用語	意味	デプロイの最終判断
継続的デリバリー (Continuous Delivery)	いつでもデプロイできる状態を自動で維持する	人間がボタンを押す
継続的デプロイメント (Continuous Deployment)	テストを通過したら本番まで自動でデプロイする	完全自動

どちらも「Delivery/Deployment」の頭文字でCDです。最後の一歩を人間が承認するか、そこまで自動にするかの違いだと押さえておけば十分です。

いきなり本番への完全自動デプロイを目指す必要はありません。まずCIでチェックを自動化し、慣れてきたらデプロイも自動化する——という段階的な進め方が現実的です。本書もその順番で進みます。

GitHub Actionsの立ち位置

CI/CDを実現するツールは昔からたくさんあります。Jenkins、CircleCI、GitLab CI/CDなどが代表的です。その中でGitHub Actionsには明確な強みがあります。

GitHubに最初から組み込まれている — 別サービスの契約・連携設定が不要
リポジトリのイベントと直結している — push、Pull Request、Issue作成など、GitHub上の出来事すべてをきっかけに動かせる
パブリックリポジトリは無料、プライベートも毎月の無料枠が大きい
公開されたアクションを組み合わせられる — 「Node.jsのセットアップ」のような定型処理は、公式・コミュニティ製の部品を呼ぶだけで済む

メンター

すでにGitHubでコードを管理しているなら、追加の契約もインストールも不要で今日から使えます。「CI/CDの学習を始める場所」として、現状もっとも手軽な選択肢ですよ。

GitHub Actionsの登場人物

次章から実際にワークフローを書いていきますが、先に用語の地図を持っておきましょう。GitHub Actionsは、次の階層構造でできています。

ワークフロー（workflow）      … 自動化の一連の流れ。YAMLファイル1つ = 1ワークフロー
 └── ジョブ（job）           … ワークフロー内の実行単位。仮想マシン1台の上で動く
      └── ステップ（step）    … ジョブ内の個々の作業。コマンド実行 or アクション呼び出し
           └── アクション（action） … 再利用可能な処理部品（例: リポジトリのチェックアウト）

そして、これらを実際に動かす実行環境が**ランナー（runner）**です。GitHubが用意した仮想マシン（Ubuntu、Windows、macOS）が、ワークフローが起動するたびに割り当てられます。

用語	一言でいうと	例
ワークフロー	自動化のレシピ全体	「CIワークフロー」「デプロイワークフロー」
イベント	ワークフローを起動するきっかけ	push、pull_request
ジョブ	レシピ内の大きな工程	「テスト」「ビルド」
ステップ	工程内の1つ1つの手順	`npm ci` を実行する
アクション	使い回せる手順の部品	`actions/checkout`
ランナー	手順を実行するマシン	`ubuntu-latest`

この6つの用語が読めれば、公式ドキュメントも他人のワークフローもぐっと読みやすくなります。いま完全に覚える必要はありません。次章で実物を動かしながら、何度も出てくるので自然に馴染みます。

用語の公式な定義は GitHub Actions を理解する（公式ドキュメント）にまとまっています。

この本の前提と進め方

本書は、Gitの基本操作（add / commit / push、ブランチ、Pull Request）を理解していることを前提にしています。このあたりに不安がある場合は、先に『Gitをちゃんと使う』第3章 add・commit・pushの基本フローと第10章 GitHubでのチーム開発を読んでおくと、本書の内容がスムーズに入ってきます。

本書は次の流れで進みます。

第1〜2章: CI/CDの考え方と、はじめてのワークフロー実行
第3〜5章: ワークフロー構文の仕組み（トリガー・変数・ランナー）
第6〜8章: Node.js/Next.jsプロジェクトのCI構築（テスト・キャッシュ・再利用）
第9〜10章: デプロイの自動化とセキュリティ
第11〜12章: 一気通貫ハンズオンとレシピ集

まとめ

**CI（継続的インテグレーション）**は、変更のたびにテスト・lint・ビルドを自動実行して、壊れた瞬間に検知する仕組み
**CD（継続的デリバリー/デプロイメント)**は、テストを通過したコードを自動でリリースまで運ぶ仕組み
自動化の価値は「人間の忘れ・属人化・発覚の遅れ」という構造的な問題を消すことにある
GitHub ActionsはGitHubに組み込まれたCI/CDプラットフォームで、追加契約なしで始められる
ワークフロー > ジョブ > ステップ > アクションの階層と、それを動かすランナー・きっかけとなるイベントが基本の登場人物

次章では、実際に .github/workflows/ にYAMLファイルを置いて、はじめてのワークフローを動かします。