「本番サーバーへのデプロイで手順を間違えた」「リリースのたびに同じ確認作業を手作業で繰り返している」——ソフトウェア開発の現場で、こうした負担を感じていませんか。手作業のデプロイでは、コマンドの打ち間違い、設定ファイルの更新漏れ、テストの実行忘れといったミスが起こりえます。こうしたミスを減らす方法の一つが「CI/CDパイプライン」です。
本記事では、CI/CDの基本、GitHub Actionsを使った自動テスト（CI）の設定例、テスト結果をマージの条件にする方法、本番デプロイ（CD）に進む前に整えるべき認証・承認・復旧の仕組みまでを、これから導入する中小企業の開発チーム向けに解説します。
CI/CDとは？CI・継続的デリバリー・継続的デプロイの違い
CI/CDは「継続的インテグレーション（Continuous Integration）」と「継続的デリバリー／継続的デプロイ（Continuous Delivery / Continuous Deployment）」をまとめた呼び方です。
CI（継続的インテグレーション）は、開発者がコードをリポジトリ（コードの保管場所）に送るたびに、ビルドとテストを自動で実行する仕組みです。複数人の変更をこまめに統合して確かめることで、問題を早い段階で見つけやすくなり、「最後にまとめて統合したら大量の衝突が起きた」という事態を避けやすくなります。
CDは、CIを通過した変更を、ステージング環境（本番前の検証環境）や本番環境へ届けるまでの工程を自動化する考え方です。CDは「継続的デリバリー」と「継続的デプロイ」のどちらを指す場合もあり、CIとあわせて整理すると次のとおりです。
| 用語 | 内容 | 本番への反映 |
|---|---|---|
| CI（継続的インテグレーション） | 変更のたびにビルドとテストを自動で実行する | 対象外 |
| 継続的デリバリー | いつでも本番にリリースできる状態を保ち、検証環境への反映などを自動化する | 人がリリースを判断して実行する |
| 継続的デプロイ | テストなどの条件を満たした変更を、人の承認を挟まずに本番まで反映する | 自動 |
中小規模の開発チームでは、まずCIだけを導入し、次に検証環境への反映、最後に承認の手順を残した本番リリースの自動化、と段階的に進めるのが現実的です。
CI/CDでできることと導入効果
CI/CDを導入すると、次のような変化が期待できます。ただし、どこまで効果が出るかは、テストの整備状況や既存の運用によって変わります。
- 変更のたびに同じ手順でテストが実行される：自動テストで検知できる種類の不具合は、コードを送った直後に見つけやすくなります。テストで確かめていない部分の不具合は見つけられないため、テストの中身が重要です
- 手順の抜け漏れや属人化を減らせる：ビルドやデプロイの手順をワークフローとしてコードに残すため、担当者による手順の違いが起きにくくなります
- 小さな変更を出しやすくなる：リリース作業の負担が下がると、変更を小さく分けてリリースしやすくなります。リリース頻度が上がるかどうかは、承認の流れや業務上のリリース判断にも左右されます
一方で、CI/CDを導入しても、リリースの判断、変更の承認、デプロイ後の確認と監視、障害時の対応といった人の作業は残ります。
CI/CDにより、自動テストとデプロイ作業の一部を標準化し、手作業の負担やミスを減らせる可能性があります。ただし、効果は既存の運用やテストの整備状況に左右されます。導入前後でリリース頻度、変更リードタイム、不具合や復旧の状況、手作業時間を測って評価してください（測り方は後述の「CI/CD導入の効果をどう測る？」で紹介します）。
主要なCI/CDツールの比較
CI/CDを実現するツールは多数あります。ここでは代表的な4つを、特徴と運用の手間の観点で紹介します。料金や無料枠は変わることがあるため、導入前に各公式サイトで確認してください。
GitHub Actions：GitHubに組み込まれたCI/CD機能で、リポジトリにYAML形式の設定ファイル（ワークフロー）を置いて使います。GitHubでコードを管理しているチームは追加の環境を用意せずに始めやすく、公開されているAction（再利用できる処理の部品）も豊富です。無料枠はプランによって異なります（次の表を参照）。
GitLab CI/CD：GitLabに内蔵されたCI/CD機能で、.gitlab-ci.ymlという設定ファイルで管理します。GitLab自体を自社サーバーに設置する形態（セルフマネージド）も選べるため、ソースコードを外部のサービスに置けない案件でも検討しやすいツールです。料金はGitLabの料金ページで確認できます。
CircleCI：設定の柔軟性が高く、テストの並列実行やキャッシュの機能が充実しているため、テストの量が多いプロジェクトで使われています。料金と無料枠はCircleCIの料金ページで確認してください。
Jenkins：オープンソースの老舗CI/CDツールで、プラグインが豊富です。ライセンス費用はかかりませんが、自社でサーバーを用意し、本体やプラグインの更新、互換性の維持を自分たちで行う必要があります。すでにJenkinsを運用しているチームには有力な選択肢です。詳細はJenkins公式サイトを参照してください。
GitHub Actionsの無料枠（プラン別）
パブリックリポジトリ（公開リポジトリ）で標準のGitHubホストランナー（GitHubが用意する実行環境）を使う場合、GitHub Actionsは原則として無料です。プライベートリポジトリでは、プランごとに毎月の無料枠があり、それを超えた分が課金対象になります。
| プラン | 月間の無料枠（標準ランナー） |
|---|---|
| GitHub Free（個人・組織） | 2,000分 |
| GitHub Pro | 3,000分 |
| GitHub Team | 3,000分 |
| GitHub Enterprise Cloud | 50,000分 |
- 大型ランナー（Larger runners）は、パブリックリポジトリで使う場合や、無料枠が残っている場合でも課金されます
- 成果物（アーティファクト）の保存容量やキャッシュの容量にも、プランごとの上限があります
- 使いすぎを防ぐには、予算（Budget）の設定も検討してください
- 上の表は2026年10月26日時点のGitHub公式ドキュメント「GitHub Actions billing」に基づきます。利用前に最新の料金と規約を確認してください
GitHub ActionsでCIを始める：PRの自動テスト設定例
まずは、プルリクエスト（PR：変更をmainブランチに取り込む前のレビュー依頼）を作成したときと、mainブランチに変更が入ったときに、自動でテストを実行するCIを設定します。この段階ではサーバーへのデプロイは行いません。
前提を確認
package.jsonとlockfile
ci.ymlを作成
.github/workflows/
トリガーと権限
PR・push／最小権限
PRで結果を確認
失敗したら修正
必須チェックに設定
ブランチ保護・Rulesets
STEP1：前提を確認する
この例はNode.jsのプロジェクトを想定しています。package.jsonにtestスクリプトがあり、依存パッケージのバージョンを固定するpackage-lock.json（lockfile）がリポジトリに含まれていることが前提です。どちらかがないプロジェクトでは、下のYAMLはそのままでは動きません。
STEP2：ワークフローファイルを作成する
リポジトリに.github/workflows/ci.ymlを作成し、次の内容を保存します。
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- name: Checkout source
uses: actions/checkout@v7
- name: Set up Node.js
uses: actions/setup-node@v7
with:
node-version: '24'
package-manager-cache: false
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm testSTEP3：トリガーと権限を確認するonで、ワークフローを動かすきっかけ（トリガー）を指定します。この例では、mainブランチ向けのPRと、mainブランチへのpushで実行します。permissions: contents: readは、ワークフローに自動で渡されるトークン（GITHUB_TOKEN）の権限を、コードの読み取りだけに絞る設定です。
STEP4：PRで実行結果を確認する
PRを作成すると、PRの画面にテストの成否が表示されます。失敗した場合は、ログで原因を確認して修正します。
STEP5：テストの成功をマージの必須条件にする
次の章で説明する、ブランチ保護またはRulesetsを設定します。
設定例を使う前の注意点
- Node.js 24は説明用の例です。実際のプロジェクトがサポートするバージョンに合わせて選んでください
npm ciはlockfileの内容どおりに依存パッケージを入れるコマンドで、lockfileがないと失敗します。npm testで何が実行されるかは、プロジェクトのテストスクリプト次第ですpull_requestとpushのどちらで実行するかは、用途に合わせて調整してください。フォーク（リポジトリの複製）から送られたPRで動くワークフローには、原則としてシークレットが渡されず、GITHUB_TOKENの権限も制限されますpermissionsは必要最小限にし、ジョブに不要な書き込み権限を与えないでくださいpackage-manager-cache: falseは依存パッケージの自動キャッシュを無効にする設定です。setup-nodeの公式READMEでは、高い権限や機密情報を扱うワークフローでは、必要がなければ自動キャッシュを無効にすることが推奨されています- この例で使っているactions/checkoutとactions/setup-nodeは、GitHub公式のActionです。2026年10月26日時点の公式READMEで、v7が案内されていることを確認しています。採用時には最新のREADMEでバージョンを確認してください
- 第三者が公開しているActionは、提供元、必要な権限、更新状況を確認してから使ってください。重要な用途では、バージョン番号ではなくコミットSHA（特定の版を示す識別子）で固定することも検討します
pull_request_targetイベントは、取り込み先のリポジトリの権限やシークレットを使える状態で動きます。PRのコード（信頼できない可能性があるコード）を取り出して実行すると危険なため、安易に使わないでください
ワークフローの書き方の詳細は、GitHub公式ドキュメント「Workflow syntax for GitHub Actions」を参照してください。
CIの成功をマージの必須条件にする（ブランチ保護・Rulesets）
PRでCIを実行すると、変更に対するテスト結果を確認できます。さらに、ブランチ保護やRulesetsでテスト成功を必須条件に設定すると、失敗したチェックがあるPRのマージを制限できます。設定や利用条件はリポジトリの公開範囲・契約プランによって異なります。
CIを設定しただけでは、テストが失敗していてもマージ自体はできてしまいます。マージを止めたい場合は、mainブランチに次の設定を加えます。
- 必須のステータスチェック（Required status checks）：上の例なら、
testジョブの成功をマージの条件に指定します - レビューの必須化：PRの承認者の人数などを指定します
- 強制pushやブランチ削除の禁止：保護したブランチの履歴が書き換えられるのを防ぎます
GitHub公式ドキュメントでは、ブランチ保護とRulesetsは、GitHub Freeではパブリックリポジトリで、GitHub Pro・Team・Enterprise Cloudではプライベートリポジトリでも利用できると案内されています。また、必須のステータスチェックを使う場合は、複数のワークフローでジョブ名が重複しないようにすることが推奨されています。詳しくは「About protected branches」と「About rulesets」を参照してください。
ステージング・本番へのCDは段階的に進める
CIが安定して動くようになったら、検証環境や本番環境へのデプロイ（CD）を検討します。デプロイは、サーバーやクラウドの構成、認証の方式、障害時の戻し方によって必要な実装が大きく変わるため、どの環境でもそのまま使える完成形はありません。
CI（自動テスト）
PRでテストし必須チェックに
ステージングへのCD
検証環境で動作を確認
本番へのCD
承認・監視・復旧手順を整えてから
- Phase 1：CI：前章までの設定です。PRで自動テストを実行し、テストの成功をマージの必須条件にします
- Phase 2：ステージングへのCD：mainブランチへの取り込み後に、検証環境へ反映する仕組みを加えます。本番に近い環境で動作を確認できるようになります
- Phase 3：本番へのCD：承認の手順、デプロイ後の確認と監視、障害時に戻す手順を整えてから進めます。リリースタグなど、本番に反映する条件も決めておきます
ジョブの依存関係と、デプロイに必要な設計
GitHub Actionsでは、needs: testと書くと、testジョブが成功した後にだけ次のジョブを実行する依存関係を作れます。ただし、これだけでは安全な認証、変更の承認、デプロイ先の権限管理、障害時のロールバック（元の版に戻すこと）は確保できません。
次のコードは、ジョブの構成を説明するための概念例です。実際のデプロイ処理は含まれておらず、実行しても本番環境には何も反映されません。
# 構造説明用：デプロイ処理は未実装
name: CD structure example
on:
workflow_dispatch:
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: '24'
package-manager-cache: false
- run: npm ci
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
environment: production
concurrency:
group: production-deployment
cancel-in-progress: false
steps:
- name: Deployment placeholder
run: echo "デプロイ処理は対象環境に応じて別途実装する"このテンプレートは構造の説明用で、本番へのデプロイは実装していません（deployジョブはメッセージを表示するだけです）。workflow_dispatchは、GitHubの画面などから手動で実行するためのトリガーです。
実際に使える形にするには、少なくとも次の設計が必要です。
- デプロイを実行できるブランチやタグの制限
- デプロイ先の設定と、Environment（環境ごとの設定）の保護ルール
- 本番反映前の承認の手順
- デプロイ先への認証の方式（後述のOIDCなど）
- デプロイする成果物（ビルド済みのファイルなど）の作成と保管
- デプロイ後のヘルスチェック（正常に動いているかの確認）
- データベースの変更（マイグレーション）の手順とバックアップ
- 障害時のロールバック、または修正版を出し直す（ロールフォワード）手順
concurrencyは、同じグループのデプロイが同時に実行されないように制御する設定です。同時実行は防げますが、アプリケーションやデータの整合性までは保証しません。
Environmentと承認（Required reviewers）の利用条件
GitHubのEnvironmentを使うと、本番用の設定やシークレットを分け、承認者（Required reviewers）や待機時間などの保護ルールを設定できます。ただし、GitHub公式ドキュメント「Managing environments for deployment」では、利用できる範囲が次のように案内されています（2026年10月26日時点）。
- パブリックリポジトリでは、現行のすべてのプランでEnvironmentと保護ルールを利用できる
- プライベートリポジトリでEnvironmentを使うには、GitHub Pro・Team・Enterpriseのいずれかが必要（GitHub Freeでは利用できない）
- GitHub Free・Pro・Teamでは、承認者（Required reviewers）や待機時間などの保護ルールはパブリックリポジトリでのみ利用できる
つまり、プライベートリポジトリで承認者の設定を使えるかどうかは契約プランによります。使えない場合は、リリース用のブランチやタグを作る操作を限られた人に絞る、外部の承認の仕組みと組み合わせる、などの代わりの方法を検討してください。最新の条件は公式ドキュメントとプラン表で確認してください。
シークレットの管理とOIDC
APIトークンなどの機密情報は、リポジトリの「Settings」→「Secrets and variables」→「Actions」から登録します。シークレットには主に次の2種類があります。
- Repository secrets：そのリポジトリのワークフローから利用できる
- Environment secrets：その環境を指定したジョブだけが、保護ルールを通過した後に利用できる。本番用の認証情報を分けたい場合に使う
シークレットに登録しても、それだけで最小権限や秘匿性が確保されるわけではありません。登録する認証情報自体の権限を必要最小限にし、利用できるジョブを絞り、定期的に見直してください。機密情報をコードやログに直接書かないことも基本です。
AWS、Google Cloud、Azureなど、OIDC（OpenID Connect）に対応したクラウドへデプロイする場合は、長期間有効なアクセスキーをシークレットに保存する代わりに、実行のたびに短期間だけ有効なトークンを受け取る方式を選べます。そのためには、クラウド側でGitHubを信頼する設定が必要です。また、トークンの発行に必要なid-token: write権限は、実際にクラウドへ認証するジョブだけに付与し、ワークフロー全体に付与しないでください。詳しくはGitHub公式ドキュメント「OpenID Connect」を参照してください。
テスト自動化の基礎：テストの種類とカバレッジ
CI/CDパイプラインの品質を左右する重要な要素の一つが、組み込むテストの内容です。代表的なテストには次の3種類があります。
ユニットテスト（単体テスト）：関数やメソッドの単位で、期待どおりに動くかを確かめるテストです。一般に実行時間が短いため、PRのたびに実行しやすいテストです。JavaScriptならJest、PythonならPytestなどのテストフレームワークを使います。
結合テスト（インテグレーションテスト）：複数のモジュールを組み合わせた動作や、データベース・外部APIとの連携部分を確かめるテストです。
E2Eテスト（エンドツーエンドテスト）：ブラウザを操作して、ログインから購入完了までのような一連の操作を再現するテストです。PlaywrightやCypressなどのツールを使います。
どのテストをどのタイミングで実行するかは、実行時間、実行にかかる費用、確かめたい内容の重要度で決めます。結合テストやE2EテストをPRのたびに実行する構成もあれば、一部を夜間やリリース前にまとめて実行する構成もあります。
テストの対象は、正常に動くケースだけでは不十分です。次のような観点も確認できるようにしておくと安心です。
- 異常なデータや想定外の操作を受け取ったときの振る舞い（異常系）
- 上限・下限ちょうどの値など、境界になる値（境界値）
- 権限のない利用者が操作できないこと（認可）
- パスワードやAPIキーなどの秘密情報がコードに含まれていないこと
- データベースの変更（マイグレーション）が正しく適用・復元できること
テストカバレッジの正しい見方
カバレッジは、テスト時にどの範囲のコードが実行されたかを示す指標です。行単位で見る行カバレッジや、条件分岐ごとに見る分岐カバレッジなど、いくつかの種類があります。カバレッジが高くても、テストの期待値が不適切なら不具合を見逃します。数値の高さそのものよりも、重要な業務ロジックや障害時の振る舞いを検証できているかを優先して判断します。
CI/CDを安全に運用するためのチェックリスト
CI/CDのワークフローは、リポジトリやデプロイ先への強い権限を持つことがあります。導入時と定期的な見直しのときに、次の項目を確認してください。
| 確認項目 | 確認すること |
|---|---|
| 1. マージの条件 | ブランチ保護またはRulesetsで、必須のステータスチェックと必要なレビューを設定しているか |
| 2. ワークフローの権限 | permissionsを最小限にしているか。GITHUB_TOKENに不要な書き込み権限が付いていないか |
| 3. シークレットの管理 | 環境ごとに利用範囲を分けているか。OIDCが使える場面では、長期間有効なキーよりもOIDCを優先しているか |
| 4. Actionと依存パッケージ | 提供元と更新状況を確認しているか。バージョンの固定など、ソフトウェアの供給網（サプライチェーン）を狙った攻撃への対策をしているか |
| 5. デプロイの条件 | デプロイできるブランチ・タグとEnvironmentの保護ルールを決めているか。利用プランと公開範囲による制約を確認したか |
| 6. データの保全と復旧 | 本番データベースの変更手順、バックアップ、復元の手順があるか。必要に応じてロールバックやロールフォワードの手順を決めているか |
| 7. デプロイ後の監視 | ヘルスチェック、エラー率・応答時間の監視を行っているか。アラートを誰が受け取るか決めているか |
| 8. 対応の責任者 | ワークフローが失敗したときや、想定外の権限で動いたときに、誰が対応するか決めているか |
サーバーのパスワードやSSHキーなどの実際の値は、ワークフローのファイルやログ、ドキュメントに書かないでください。GitHub Actionsのセキュリティについては、GitHub公式ドキュメント「Secure use reference」にまとめられています。
AIツールの活用：レビュー・テスト作成・監視の補助として
CI/CDにAIツールを組み合わせると、コードレビューやテスト作成の一部を補助できます。ただし、AIの出力には誤りや見落としがあるため、人の確認を置き換えるものではありません。
AIコードレビューの組み込み：CodeRabbitなどのAIレビューサービスをPRと連携すると、変更点に対するコメントを自動で受け取れます。人のレビューの前に気づきを得る手段として役立ちますが、不具合や脆弱性をすべて見つけられるわけではなく、誤った指摘が含まれることもあります。なお、reviewdogは、リンター（コードの書き方を検査するツール）などの結果をPRのレビューコメントとして投稿するためのツールです。reviewdog単独で生成AIによるレビューを行うものではなく、AIと組み合わせる場合は、別のレビュー処理や外部サービスの出力をreviewdogに渡す構成になります。
AIによるテストの作成補助：GitHub Copilotなどのコーディング支援AIや、テスト作成を支援するAIツール（例：Qodo（旧CodiumAI））を使うと、実装コードからテストケースの案を作れます。ただし、AIが作ったテストが正しいとは限りません。前提条件、期待値、境界値、認可の確認が適切かを人が確かめ、実際に実行して妥当性を評価してください。各サービスの現在の製品構成は公式サイトで確認してください。
デプロイ後の監視と通知：DatadogやNew Relicなどの監視サービスを使うと、デプロイ後のエラー率・応答時間・リソース使用量の異常を検知し、Slackなどに自動で通知できます。通知によって異常に気づきやすくなりますが、通知を受けた後の判断、関係者への連絡、ロールバックなどの障害対応は人が行う必要があります。
外部サービスに送る情報の確認：AIレビューや監視のサービスには、ソースコードやログを送ることになります。契約条件、データの保存期間、学習への利用の有無を確認し、送ってよい情報の範囲を決めてから使ってください。
CI/CD導入の効果をどう測る？
CI/CDの効果は、導入前後の数値を比べて評価します。指標としては、ソフトウェアの開発・運用の実態を研究しているDORA（DevOps Research and Assessment）の指標が参考になります。DORAの指標は見直しが重ねられており、以前は4つの指標（Four Keys）として知られていましたが、2024年に「デプロイ手戻り率」が加わり、現在は次の5つの指標で説明されています。
| 指標 | 分類 | 内容 |
|---|---|---|
| デプロイ頻度（Deployment frequency） | スループット | アプリケーションの変更を本番にデプロイする頻度 |
| 変更リードタイム（Change lead time） | スループット | コードのコミットから、本番へのデプロイが成功するまでの時間 |
| デプロイ失敗からの復旧時間（Failed deployment recovery time） | スループット | 失敗したデプロイから復旧するまでの時間 |
| 変更失敗率（Change fail rate） | 不安定性 | 本番で障害を起こしたデプロイの割合 |
| デプロイ手戻り率（Deployment rework rate） | 不安定性 | 不具合の修正のために行った、計画外のデプロイの割合 |
出典：DORA「A history of DORA’s software delivery metrics」
中小規模のチームでは、最初からすべてを測る必要はありません。たとえば「デプロイ頻度」と「変更リードタイム」のように、記録しやすい指標を少数選んで導入前の値を記録し、導入後と比べるところから始めてください。手作業にかかっていた時間や、リリース時の不具合の件数をあわせて記録しておくと、効果を説明しやすくなります。
まとめ
CI/CDは、テストやデプロイの手順を自動化・標準化して、手作業のミスや負担を減らすための仕組みです。最初の一歩としては、PRで自動テストを実行するCIを設定し、テストの成功をマージの必須条件にするところから始めるのが取り組みやすい方法です。
本番へのデプロイを自動化する場合は、認証、承認、監視、障害時の復旧の手順を先に整え、利用しているGitHubのプランで使える機能を確認してから段階的に進めてください。AIツールはレビューやテスト作成の補助として役立ちますが、最終的な確認と判断は人が行います。導入の効果は、DORAの指標などを使って導入前後の数値で確かめましょう。
株式会社アイ・エス・プライムでは、業務システムの開発・改修や開発後の保守・運用、DX推進のご相談を承っています。「今の開発や運用の進め方を見直したい」という段階からご相談ください。
