※本記事にはプロモーション（広告）を含みます。

目次

  • GitHub Actionsの基本構成
  • 最小構成で作る初めてのCI
  • テストとビルドの自動化
  • デプロイまで繋ぐCD設計
  • 運用でつまずく注意点
  • よくある質問
  • まとめ

GitHub ActionsでCI/CDを構築するなら、まずリポジトリ直下に.github/workflowsディレクトリを作り、YAMLファイル1本でテスト自動化から始めるのが最短ルートです。ビルドやデプロイまで一気に組もうとすると設定ミスの切り分けが難しくなるため、最初はプッシュ時のテスト実行だけに絞り、動作確認を取ってから段階的にジョブを追加する進め方が失敗を減らします。本記事では基本構成の理解から実際のワークフロー作成、テスト・ビルドの自動化、デプロイ連携、運用時の注意点までを順を追って解説します。

GitHub Actionsの基本構成

GitHub Actionsは、GitHubが提供するCI/CDプラットフォームで、リポジトリ内のイベントをトリガーに任意の処理を自動実行できる仕組みです。追加のCIサーバーを自前で用意する必要がなく、GitHubのリポジトリと同じ画面から設定・実行結果の確認まで完結する点が特徴です。

ワークフローファイルの役割

ワークフローの定義は.github/workflows/配下に置いたYAMLファイル1つ1つが担います。ファイル名は自由ですが、ci.ymlやdeploy.ymlのように処理内容が分かる名前を付けておくと、ワークフローが増えたときに管理しやすくなります。1つのリポジトリに複数のワークフローファイルを置くことも可能で、テスト用とデプロイ用を分離して管理するケースが多く見られます。

イベントとジョブの関係

ワークフローは「イベント」をトリガーに起動し、内部で1つ以上の「ジョブ」を実行します。ジョブはさらに複数の「ステップ」で構成され、各ステップでコマンド実行や既存アクションの呼び出しを行います。この階層構造を理解しておくと、後からジョブを並列化したり、特定のステップだけ条件分岐させたりする設計がしやすくなります。

要素役割設定例
onワークフローの起動条件push, pull_request, schedule
jobs並列または直列で実行する処理単位test, build, deploy
stepsジョブ内で順に実行する処理checkout, setup-node, run npm test
runs-on実行環境（ランナー）の指定ubuntu-latest, windows-latest

最小構成で作る初めてのCI

基本構造を押さえたら、実際に最小構成のワークフローを作成します。ここではプッシュ時にテストを自動実行するシンプルな例を組み立てます。

リポジトリへの配置手順

まずリポジトリのルートに.github/workflows/ci.ymlを作成します。以下は依存関係のインストールとテスト実行だけを行う最小構成の例です。

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

このファイルをコミットしてリポジトリにプッシュすると、GitHub上の「Actions」タブに実行履歴が自動的に表示されます。初回実行でエラーが出た場合は、ログを上から順に確認し、どのステップで失敗したかを特定してから修正するのが基本の進め方です。

トリガー設定のコツ

onキーの設定次第で、ワークフローの実行タイミングは細かく制御できます。全てのブランチへのプッシュで実行すると無駄な実行回数が増えるため、対象ブランチを絞り込んでおくと実行時間とコストの両方を抑えられます。

  • mainブランチへのプッシュのみ実行したい場合はbranches: [main]を指定する
  • プルリクエスト作成時だけ検証したい場合はpull_requestイベントを使う
  • 特定のパス配下の変更のみ検知したい場合はpathsキーで対象を絞る
  • 定期実行が必要な場合はscheduleとcron形式で時刻を指定する

特にモノレポ構成のプロジェクトでは、変更が発生していないディレクトリのCIまで毎回走らせると実行時間が無駄に伸びます。pathsやpaths-ignoreを組み合わせて、影響範囲に応じたトリガー設計をしておくと後の運用が楽になります。

テストとビルドの自動化

テストが動くようになったら、次はビルドとテストを分離し、言語・フレームワークに応じた最適化を加えていきます。

言語別セットアップの違い

GitHub Actionsには言語ごとの公式セットアップアクションが用意されており、これを使うと環境構築の記述量を大きく減らせます。

言語/環境セットアップアクション用途
Node.jsactions/setup-nodenpm/yarn/pnpmプロジェクトのビルド
Pythonactions/setup-pythonpip/poetryによる依存解決とテスト
Javaactions/setup-javaMaven/Gradleビルド
Goactions/setup-gogo buildおよびgo test

各アクションのバージョンやオプションは頻繁に更新されるため、最新の入力パラメータは公式ドキュメントで確認してから利用してください。バージョン固定を怠ると、ある日突然ビルドが失敗する事態にもつながります。

キャッシュで実行時間短縮

依存関係のインストールはCI実行時間の中でも大きな割合を占めます。actions/cacheを使ってnode_modulesや~/.m2などのディレクトリをキャッシュすると、2回目以降の実行を短縮できます。多くのセットアップアクションにはcacheオプションが標準搭載されており、以下のように指定するだけでキャッシュ管理が完結します。

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'

マトリクスビルドを使えば、複数のNode.jsバージョンやOS環境でテストを並列実行することも可能です。対応環境を広げたいライブラリ開発では特に有効な機能です。

strategy:
  matrix:
    node-version: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]

デプロイまで繋ぐCD設計

テストとビルドが安定したら、いよいよデプロイ工程を組み込みます。CDの設計では、認証情報の扱いと環境の分離が最も重要な検討事項です。

シークレット管理の基本

APIキーやデプロイ用トークンをワークフローファイルに直接書き込むのは避けてください。GitHubリポジトリの「Settings」→「Secrets and variables」→「Actions」から登録した値は、ワークフロー内で${{ secrets.SECRET_NAME }}という形式で参照できます。ログにシークレットの値がそのまま出力されないよう自動でマスクされる仕組みがありますが、標準出力に直接echoするような記述は避け、公式ドキュメントで案内されている参照方法に従って設定してください。

環境ごとの承認フロー

本番環境へのデプロイでは、意図しない自動実行を防ぐ仕組みが欠かせません。GitHub Actionsの「Environments」機能を使うと、環境ごとにシークレットを分離し、デプロイ前に承認者の確認を必須にする設定が行えます。

  • developブランチへのプッシュ → ステージング環境へ自動デプロイ
  • mainブランチへのマージ → 承認者のレビュー後に本番環境へデプロイ
  • タグ作成イベント → リリースビルドの生成とアーティファクト保存

このように環境ごとにトリガーと承認プロセスを分けておくと、テスト用の変更が誤って本番に反映されるリスクを構造的に抑えられます。デプロイ先がAWSやAzureなどのクラウドサービスの場合、各社が公式に提供しているアクション（例：aws-actions/configure-aws-credentials）を使うと、認証情報の受け渡しを安全な形で実装できます。設定項目は各クラウドのドキュメントを必ず参照してください。

運用でつまずく注意点

ワークフローが一通り動くようになった後も、運用フェーズで見落としやすいポイントがいくつかあります。

権限設定と実行コスト

ワークフローに付与するGITHUB_TOKENの権限は、デフォルトで広めに設定されている場合があります。必要最小限の権限だけを付与するpermissionsキーを明示的に記述しておくと、万が一ワークフロー内のコードに問題があった場合でも被害範囲を限定できます。

permissions:
  contents: read
  pull-requests: write

また、プライベートリポジトリでのActions実行には利用時間に応じた課金が発生します。無料枠の分数やランナーごとの料金は変更される可能性があるため、正確な数値はGitHub公式の料金ページで最新情報を確認してください。実行時間を抑えるには、前述のキャッシュ活用に加え、不要なジョブの並列削減や、変更のないパスへのトリガー除外が効果的です。

他CIツールとの比較

CI/CDツールはGitHub Actions以外にも複数存在し、既存の開発環境やインフラ構成によって選択肢が変わります。GitLab CI/CDはGitLabのリポジトリ管理と一体化しており、GitLab上でソース管理をしている場合に親和性が高いツールです。CircleCIは独立したCI専業サービスとして長く運用されており、複雑なワークフロー制御に強みを持ちます。Jenkinsはオープンソースのため自前サーバーでの運用が前提となり、プラグインによる拡張性の高さが特徴です。

ツール特徴向いているケース
GitHub ActionsGitHubリポジトリと統合済み、設定はYAMLGitHubでソース管理している開発チーム
GitLab CI/CDGitLabに標準搭載、.gitlab-ci.ymlで定義GitLabを利用している開発チーム
CircleCICI専業サービス、実行環境の柔軟性が高い複数SCMを横断して使いたいチーム
JenkinsOSSでセルフホスト、プラグインが豊富オンプレミス環境や独自要件が多いプロジェクト

すでにGitHubでソースコードを管理しているプロジェクトであれば、追加の外部サービス連携なしに始められるGitHub Actionsが導入コストの面で選びやすい選択肢です。一方で、既存のCI資産がJenkinsやCircleCIに蓄積されている場合は、無理に移行せず段階的な併用を検討する方が現実的な判断になることもあります。

よくある質問

Q1. GitHub Actionsは無料で使えますか

パブリックリポジトリでは無料で利用できます。プライベートリポジトリでは月あたりの無料実行時間枠が設けられており、超過分は従量課金となります。正確な無料枠の分数やランナーごとの料金は変更される可能性があるため、GitHub公式の料金ページで最新情報を確認してください。

Q2. ワークフローが失敗した原因はどう調べますか

リポジトリの「Actions」タブから該当の実行履歴を開き、失敗したジョブとステップのログを確認します。多くの場合、依存関係のインストールエラーか、環境変数・シークレットの参照ミスが原因です。ログ中のエラーメッセージをそのまま検索すると、原因の特定が早くなります。

Q3. セルフホストランナーは必要ですか

GitHubが提供するホステッドランナーで多くのケースは十分対応できます。社内ネットワーク内のリソースへのアクセスが必要な場合や、特殊なハードウェア要件がある場合に限り、セルフホストランナーの導入を検討してください。セルフホストランナーはネットワーク設定やセキュリティ管理を自組織で担う必要があるため、運用負荷を踏まえた上で判断することが求められます。

Q4. 複数の環境（開発・検証・本番）はどう分けますか

ブランチ戦略とGitHub Actionsの「Environments」機能を組み合わせて分離します。developブランチへのプッシュで検証環境へ、mainブランチへのマージで本番環境へといったように、ブランチとデプロイ先を1対1で対応させる設計が管理しやすい方法です。

Q5. YAMLファイルの構文エラーはどう防ぎますか

インデントのずれが原因となるケースが多いため、エディタでYAML用の構文チェック拡張を有効にしておくと入力段階でエラーを検知できます。またGitHubのWeb UI上でワークフローファイルを編集する場合も、保存前に構文エラーが表示されるため、その時点で修正してからコミットする流れが安全です。

Q6. Dockerを使ったビルドにも対応できますか

対応できます。docker/build-push-actionなどの公式・準公式アクションを使うと、Dockerイメージのビルドとレジストリへのプッシュをワークフロー内に組み込めます。レジストリの認証情報はシークレットとして登録し、直接記述しない運用を徹底してください。

関連記事

まとめ

GitHub ActionsによるCI/CD構築は、まず最小構成のテスト自動化から始め、キャッシュやマトリクスビルドで実行効率を高め、最後に環境分離を伴うデプロイ工程を組み込むという段階的な進め方が確実です。シークレット管理と権限設定はセキュリティ上の要になる部分のため、公式ドキュメントの最新情報を確認しながら自己責任で設定を行ってください。すでにGitHubでソースコードを管理しているチームであれば、追加インフラなしに始められる点がGitHub Actionsの実務上の利点であり、既存のJenkinsやCircleCIとの併用を含め、開発チームの規模や既存資産に応じた構成を選んでいく進め方が現実的です。

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営