GitHub Actions入門｜CI/CDパイプラインをゼロから構築する実践ガイド
※本記事はプロモーションを含みます。
GitHub Actionsはコードをプッシュするだけで、テスト・リント・デプロイが自動実行されるCI/CDプラットフォームです。インフラエンジニアの自動化スキルとして急速に注目度が上昇しており、Terraform・Ansible・CloudFormationなどの構成管理とも相性が良く、実際の運用効率化に直結します。この記事では、現役IT講師の視点から、ゼロからスタートできるように最小構成から段階的に解説していきます。読了時間の目安は15～18分です。
GitHub Action…
GitHub Actionsは、GitHub上のリポジトリに保存されたコードに対してイベント（プッシュやプルリクエスト）が発生した時点で、自動的にジョブを実行する機能とされています。従来のCI/CDツール（Jenkins、CircleCI、GitLabなど）とは異なり、GitHubのリポジトリ内に直接設定ファイルを配置するだけで、追加の外部サービス登録が不要という特徴があります。
インフラエンジニアの観点からは、以下の点が重要とされています。
- AWSやGCP、Azureとの連携が容易 — IAMロールやサービスアカウントの認証情報をGitHub Secretsに保管して、EC2への自動デプロイやS3へのアップロードが実現できます
- Terraform・Ansible・CloudFormationと相性が良い — インフラストラクチャ・アズ・コードの検証と本番反映を同一パイプラインで管理できます
- 無料枠で小～中規模運用に対応 — パブリックリポジトリは実行時間無制限、プライベートリポジトリは月2,000分無料という寛容な価格設定です
- コンテナイメージの自動ビルド・プッシュに対応 — DockerイメージをDocker Hubに自動アップロードし、ECS・AKSなどへのデプロイに繋げられます
CI/CDの全体像としては、継続的インテグレーション（CI） がコードの品質を自動検査するフェーズであり、継続的デリバリー（CD） がテスト済みのコードを本番環境へ自動配置するフェーズとされています。GitHub Actionsはこれらの両方を支えるエンジンの役割を果たします。
ワークフローと実行環境の考え方
GitHub Actionsでは、YAMLファイルで定義されたワークフローが実行環境（Runner）上で動作します。Runnerは仮想マシンであり、Ubuntu・Windows・macOS等から選択でき、カスタマイズしたRunnerを自社のオンプレミス環境に配置することも可能とされています。
| ランナー種別 | 特徴 | 推奨用途 |
|---|---|---|
| ubuntu-latest | Ubuntu LTS環境。Docker対応で最も柔軟 | Web開発・インフラ検証・コンテナビルド |
| windows-latest | Windows Server環境。PowerShell対応 | C#・.NET・Windows固有のツール検証 |
| macos-latest | macOS環境。Xcode・swiftコンパイル対応 | iOS・macアプリ開発 |
| Self-hosted | 自社サーバ上に配置したランナー | 社内ネットワーク内デプロイ・セキュリティ重視 |
ワークフロー設定の実践的な…
GitHub Actionsの心臓部はワークフローファイルです。このファイルをYAML形式で記述し、リポジトリの.github/workflows/ ディレクトリに配置すると、GitHubが自動的に読み込んで実行開始します。
最小構成の実例
まず、最も基本的なワークフローを示します。このファイル名をci-pipeline.ymlとした場合のイメージです。
name: CI Pipeline
on:
push:
branches: [main, develop]
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run tests
run: pytest tests/
- name: Run linter
run: flake8 src/
この設定ファイルでは、以下の動きが実現されます。
- トリガー定義：mainブランチまたはdevelopブランチへのプッシュ、およびすべてのプルリクエスト時に実行
- 環境準備：Ubuntu最新版上でPython 3.12をセットアップ
- 依存関係インストール：requirements.txtから必要なパッケージをインストール
- テスト実行：pytestを使ってテストスイートを実行
- 品質チェック：flake8でコードスタイルをチェック
よく使われる設定キーの解説
| 設定キー | 説明 | 使用例 |
|---|---|---|
| on | ワークフロー実行のトリガーイベント | push / pull_request / schedule |
| runs-on | ジョブを実行する仮想環境 | ubuntu-latest / windows-latest |
| uses | GitHubが提供する既成Action | actions/checkout@v4 |
| run | 実行するシェルコマンド | npm install && npm test |
| env | 環境変数（secrets.で暗号化情報も指定可） | ${{ secrets.AWS_KEY }} |
| needs | ジョブの依存関係を指定 | needs: build |
マトリックス戦略で複数バー…
インフラエンジニアがAnsibleプレイブックやTerraformコードをテストする際、複数のOSバージョンやRubyバージョンでの検証が必要な場合があります。そこで活躍するのがマトリックス（matrix）とされています。
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12"]
os: [ubuntu-20.04, ubuntu-22.04]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
- run: python -m pytest
この設定では、Python 3.9から3.12まで4つのバージョンと、Ubuntu 20.04・22.04という2つのOSの組み合わせ（計8通り）でテストが自動実行されます。これにより、複数の環境での互換性を効率的に検証できます。
インフラエンジニア向けの活…
GitHub ActionsはWebアプリケーション開発だけでなく、インフラストラクチャ管理の領域でも大きな価値を発揮するとされています。以下、実際の活用シーンを解説します。
Terraformのバリデ…
AWSやGCP上のリソースをコードで定義するTerraformを使用する場合、構文エラーやリソース定義の誤りを早期に検知することが重要です。以下のワークフローで、プルリクエスト時に自動バリデーションが実行されます。
name: Terraform Validation
on:
pull_request:
paths:
- 'terraform/**'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v2
- run: terraform fmt -check
- run: terraform init
- run: terraform validate
- run: terraform plan -json > plan.json
このワークフローの実行フローは、以下の通りとされています。
- フォーマットチェック — コードスタイルの一貫性を確保
- バリデーション — 構文エラーやリソース定義の矛盾を検知
- プランの自動生成 — 何がどう変更されるかを事前確認
Ansibleプレイブック…
Ansibleでサーバ構成管理を行う場合、プレイブック（YAMLファイル）の構文チェックと実行検証が重要とされています。
name: Ansible Lint and Syntax Check
on:
push:
paths:
- 'ansible/**'
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install ansible ansible-lint
- run: ansible-lint ansible/
- run: ansible-playbook --syntax-check ansible/site.yml
この設定により、プレイブック内の実装パターンの問題点を自動指摘し、チーム全体の構成管理品質を向上させることができます。
AWS CLIを使った自動…
mainブランチへのマージが検出された時点で、EC2インスタンスやECSタスクへの自動デプロイを実行する仕組みです。IAM認証情報はGitHub Secretsで安全に管理します。
name: Deploy to AWS
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v2
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-1
- name: Deploy to EC2
run: |
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters 'commands=["cd /var/www && git pull && ./deploy.sh"]' \
--instance-ids "i-0123456789abcdef0"
このアプローチにより、テストが通過したコードのみが本番環境に反映される仕組みが実現されます。
Docker イメージの自…
コンテナ化されたアプリケーションの場合、Git pushをトリガーにDockerイメージを自動ビルド・Docker Hubにプッシュし、ECSやAKSなどのコンテナオーケストレーション環境にデプロイすることが可能とされています。
name: Build and Push Docker Image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v2
- uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_HUB_USERNAME }}
password: ${{ secrets.DOCKER_HUB_TOKEN }}
- uses: docker/build-push-action@v4
with:
context: .
push: true
tags: |
myregistry/myapp:latest
myregistry/myapp:${{ github.sha }}
イメージにはコミットハッシュをタグとして付与することで、本番環境で問題が発生した際の原因特定が容易になるとされています。
セキュリティと料金形態
Secretsを使った認証…
AWS、GCP、Azureなどのクラウド環境へアクセスするにはAPIキーやアクセストークンが必要です。これらを平文でワークフローに記述することは絶対に避けるべきとされており、GitHub Secretsを使用して暗号化された形で保存することが重要です。
Secretsは以下の手順で登録します。
- リポジトリのSettingsタブを開く
- 左サイドバーからSecrets and variables → Actionsを選択
- New repository secretボタンをクリック
- 名前と値を入力して保存
ワークフロー内では${{ secrets.シークレット名 }} の形式で参照します。
OIDC（OpenID C…
より高度なセキュリティを求める場合、OIDCを使用してアクセストークンを動的に生成する方法が推奨されるとされています。これにより、固定的なアクセスキーをGitHubに保存する必要がなくなります。AWSやAzureなどの主要クラウドプロバイダはOIDC連携に対応しており、公式ドキュメントで詳細な設定手順が提供されています。セキュリティ設定の最新情報は各クラウドプロバイダの公式ドキュメントで確認することをお勧めします。
GitHub Action…
| 区分 | パブリック | プライベート |
|---|---|---|
| 実行時間 | 無制限 | 月2,000分無料 |
| 超過時の料金 | 課金なし | 分単価で課金 |
| ストレージ | 5GB無料 | 500MB無料 |
| Self-hosted Runner | 無料 | 無料 |
小～中規模なプロジェクトであれば、無料枠だけで十分対応できるとされています。ただし、大規模なテストスイートや頻繁なデプロイが必要な場合には、分単価が積み重なる可能性があるため、Self-hosted Runnerの導入も視野に入れる価値があります。
よくあるトラブルと解決方法
ワークフローが実行されない場合
設定ファイルを作成しても実行が始まらない場合、以下の点を確認することが推奨されるとされています。
- ファイルの配置確認 —
.github/workflows/ディレクトリに配置されているか - YAML形式の確認 — インデント（スペース）が正確か（タブは使用禁止）
- GitHub公式Actionのバージョン —
@v4など指定が可能か、非推奨バージョンでないか - トリガー条件の確認 — onで指定されたイベントが実際に発生しているか
- リポジトリのActionsタブ — エラーログで詳細な失敗原因が表示される
権限不足でデプロイが失敗する
AWS CLIやGoogle Cloudコマンドを実行する際に、Access Denied というエラーが出る場合、以下の対策が有効とされています。
- IAMロール・サービスアカウントの権限確認 — 必要なアクション（ec2:StartInstances、s3:PutObject等）の権限があるか
- OIDCの信頼ポリシー確認 — OIDC連携の場合、信頼対象がGitHubに設定されているか
- 地域（Region）の確認 — EC2やS3がクエリの地域で実際に存在しているか
- アクセスキーの有効期限確認 — Secretsに保存されたアクセスキーが失効していないか
ジョブが途中で時間切れになる
デフォルトでは各ジョブは360分（6時間）でタイムアウトされます。テストやビルドが長時間を要する場合、以下の対策が有効とされています。
- ジョブの細分化 — matrixやneedsで依存関係を作り、並列実行を活用
- タイムアウト時間の延長 —
timeout-minutes: 540で最大540分まで設定可能 - キャッシング機能の活用 —
actions/cache@v3で依存関係をキャッシュし実行時間短縮 - Self-hosted Runnerの導入 — より高性能なマシンで実行してジョブ時間を削減
Secret値が誤って出力…
GitHub Actionsは自動的にワークフロー実行ログからSecret値を隠蔽する機構を備えているとされています。ただし、以下のケースでは隠蔽が失敗する可能性があります。
- エコーコマンドでの直接出力 —
echo ${{ secrets.KEY }}は避け、必ず変数に格納 - JSON出力における値の混在 — エラーメッセージにSecret値が含まれないか確認
- ログ保持期間の設定 — Settings内でログ保持日数を短縮して安全性を強化
まとめ
GitHub Actionsはコードの品質管理と運用効率化を同時に実現する強力なツールとされています。YAMLベースのシンプルな設定で、複雑なCI/CDパイプラインを構築できる柔軟性があります。
インフラエンジニアにとっては、Terraform・Ansible・CloudFormationなどのコード検証、AWS・GCPへの自動デプロイ、Dockerイメージの自動ビルドなど、日々の業務を大幅に効率化できるツールとして活躍するとされています。
まずは最小構成から始めて、段階的に機能を追加していくことをお勧めします。無料枠の豊富さと充実したドキュメントに支えられて、初心者でも短期間で実践的な自動化を実現できる可能性があります。
なお、GitHub Actionsの料金・仕様・Action名はGitHubにより変更される場合があります。最新情報はGitHubの公式ドキュメントでご確認いただくことをお勧めします。セキュリティ設定については、IAM権限設定やシークレット管理の最新ベストプラクティスを公式ドキュメントで確認した上で運用することが重要です。
