GitHub Actions 基本とCI/CDパイプライン構築ガイド

2026年6月20日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 1. GitHub Actions の基本概念と構成要素
- 1.1 1‑1. workflow・job・step の役割と関係（H3）
  - 1.1.1 参考情報
2 2. リポジトリシークレットと環境変数の安全な設定方法
- 2.1 2‑1. GitHub Secrets の登録手順（H3）
- 2.2 2‑2. 環境変数との使い分け（H3）
  - 2.2.1 参考情報
3 3. YAML で構築するビルド・テスト・デプロイパイプライン
- 3.1 3‑1. キャッシュ戦略とビルド時間短縮テクニック（H3）
- 3.2 3‑2. 公式ドキュメントへのリンク
4 4. 主要クラウドサービスへの自動デプロイ例
- 4.1 4‑1. マルチクラウド同時デプロイ（H3）
  - 4.1.1 参考情報
5 5. 再利用可能なワークフローと Composite Action の作り方
- 5.1 5‑1. 再利用可能ワークフローのテンプレート例（H3）
- 5.2 5‑2. Composite Action の作成と公開手順（H3）
  - 5.2.1 参考情報
6 6. デプロイ失敗時のトラブルシューティングと承認プロセス
- 6.1 6‑1. 環境保護ルールと手動承認ステップ（H3）
- 6.2 6‑2. ログ分析と典型的エラー例（H3）
7 7. 参考資料・リンク集

スポンサードリンク

1. GitHub Actions の基本概念と構成要素

GitHub Actions はリポジトリ内で CI/CD パイプラインを直接定義できるサービスです。このセクションでは workflow、job、step がどのように階層化され、全体像を形成するかを把握します。

1‑1. workflow・job・step の役割と関係（H3）

各レベルは「何を」「いつ」「どう実行するか」を明確に分離し、保守性と可視化を高めます。

workflow：.github/workflows/*.yml に配置し、トリガー (on:) と全体の流れを定義します。
job：workflow 内で jobs: 配列に並び、実行環境（OS・ランナー）や依存関係 (needs:) を設定します。
step：ジョブ内の steps: に記述し、具体的なコマンドまたは公式アクションを呼び出します。

構成要素	設置場所	主な役割
workflow	`.github/workflows/*.yml`	パイプライン全体とトリガー設定
job	`jobs:` 配列	ランナー種別・依存関係の管理
step	`steps:` 配列	個々の処理（checkout、ビルド、テスト）

ポイント：workflow → job → step の階層で設計すると、複雑なデプロイフローでも見通しが良くなります。

参考情報

GitHub Docs – Workflows syntax for GitHub Actions

2. リポジトリシークレットと環境変数の安全な設定方法

機密情報を漏らさずに自動デプロイを実装するには、GitHub Secrets と 環境変数 の使い分けが必須です。

2‑1. GitHub Secrets の登録手順（H3）

シークレットは暗号化されて保存され、ワークフロー内では ${{ secrets.NAME }} で参照します。

Settings → Secrets and variables → Actions を開く。
「New repository secret」から AWS_ACCESS_KEY_ID 等を入力し保存する。
ワークフロー例：

- name: Configure AWS credentials
  run: aws configure set aws_access_key_id ${{ secrets.AWS_ACCESS_KEY_ID }}

- name: Configure AWS credentials

run: aws configure set aws_access_key_id ${{ secrets.AWS_ACCESS_KEY_ID }}

ポイント：シークレットはコードに埋め込まず、常に ${{ secrets... }} 経由で使用してください。

2‑2. 環境変数との使い分け（H3）

環境変数は非機密情報の共有に適し、env: キーでジョブ・ステップ単位に設定できます。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production            # 非機密
      API_URL: ${{ secrets.API_URL }} # 機密は Secrets 経由

jobs:

build:

runs-on: ubuntu-latest

env:

NODE_ENV: production # 非機密

API_URL: ${{ secrets.API_URL }} # 機密は Secrets 経由

ポイント：機密情報は必ず Secrets に、設定値は環境変数に分けることで安全性と可読性が向上します。

参考情報

GitHub Docs – Encrypted secrets

3. YAML で構築するビルド・テスト・デプロイパイプライン

最新の公式アクションを組み合わせることで、キャッシュ活用やコンテナビルドがシンプルに実装できます。

3‑1. キャッシュ戦略とビルド時間短縮テクニック（H3）

actions/cache@v3 と setup-node@v4 の組み合わせは、依存パッケージ取得を 約 60 % 短縮できることが公式ドキュメントで報告されています（キャッシュのベストプラクティス）。

name: CI

on:
  push:
    branches: [ main ]

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # npm キャッシュ
      - name: Cache node_modules
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      # Node.js 環境設定（内部で同様の npm キャッシュが有効化されます）
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      # Docker ビルド（キャッシュをレジストリに保存）
      - name: Build Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          tags: myapp:${{ github.sha }}
          push: false
          cache-from: type=registry,ref=myrepo/myapp:cache
          cache-to: type=inline

on:

push:

branches: [ main ]

jobs:

build-test:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v4

# npm キャッシュ

- name: Cache node_modules

uses: actions/cache@v3

with:

path: ~/.npm

key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}

restore-keys: |

${{ runner.os }}-node-

# Node.js 環境設定（内部で同様の npm キャッシュが有効化されます）

- name: Set up Node.js

uses: actions/setup-node@v4

with:

node-version: '20'

cache: 'npm'

- name: Install dependencies

run: npm ci

- name: Run tests

run: npm test

# Docker ビルド（キャッシュをレジストリに保存）

- name: Build Docker image

uses: docker/build-push-action@v5

with:

context: .

tags: myapp:${{ github.sha }}

push: false

cache-from: type=registry,ref=myrepo/myapp:cache

cache-to: type=inline

ポイント：hashFiles('package-lock.json') によるキー生成で、依存が変わったときだけキャッシュが再作成されます。

3‑2. 公式ドキュメントへのリンク

actions/cache@v3 – GitHub Marketplace
setup-node@v4 – GitHub Marketplace
docker/build-push-action@v5 – GitHub Marketplace

4. 主要クラウドサービスへの自動デプロイ例

本節では AWS Elastic Beanstalk、Azure App Service、Google Cloud Run、Vercel、Netlify の代表的なデプロイ手順を示します。すべてシークレットから認証情報を取得し、環境変数でステージを切り替える設計です。

4‑1. マルチクラウド同時デプロイ（H3）

以下のワークフローはタグプッシュ (v*.*.*) をトリガーに、Docker イメージをビルドした後、AWS と Azure に同時デプロイします。

name: Deploy to Cloud

on:
  push:
    tags:
      - 'v*.*.*'   # バージョンタグで自動デプロイ

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      # Docker ビルド
      - name: Build Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          tags: myapp:${{ github.sha }}
          push: false

      # ---------- AWS ----------
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v3
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Deploy to Elastic Beanstalk
        run: |
          zip -r /tmp/app.zip .
          eb init my-app --region us-east-1
          eb deploy production-env --label ${{ github.sha }}

      # ---------- Azure ----------
      - name: Login to Azure
        uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v2
        with:
          app-name: my-azure-app
          slot-name: production
          images: myapp:${{ github.sha }}

on:

push:

tags:

- 'v*.*.*' # バージョンタグで自動デプロイ

jobs:

deploy:

runs-on: ubuntu-latest

environment: production

steps:

- uses: actions/checkout@v4

# Docker ビルド

- name: Build Docker image

uses: docker/build-push-action@v5

with:

context: .

tags: myapp:${{ github.sha }}

push: false

# ---------- AWS ----------

- name: Configure AWS credentials

uses: aws-actions/configure-aws-credentials@v3

with:

aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}

aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

aws-region: us-east-1

- name: Deploy to Elastic Beanstalk

run: |

zip -r /tmp/app.zip .

eb init my-app --region us-east-1

eb deploy production-env --label ${{ github.sha }}

# ---------- Azure ----------

- name: Login to Azure

uses: azure/login@v2

with:

creds: ${{ secrets.AZURE_CREDENTIALS }}

- name: Deploy to Azure Web App

uses: azure/webapps-deploy@v2

with:

app-name: my-azure-app

slot-name: production

images: myapp:${{ github.sha }}

クラウド	公式アクション (2026)	必要シークレット
AWS Elastic Beanstalk	`aws-actions/configure-aws-credentials@v3`	`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`
Azure App Service	`azure/webapps-deploy@v2`	`AZURE_CREDENTIALS` (JSON)
Google Cloud Run	`google-github-actions/setup-gcloud@v2`	`GCP_SA_KEY` (service‑account JSON)
Vercel	`vercel/action@v3`	`VERCEL_TOKEN`, `VERCEL_ORG_ID`, `VERCEL_PROJECT_ID`
Netlify	`nwtgck/actions-netlify-cli@v2`	`NETLIFY_AUTH_TOKEN`, `NETLIFY_SITE_ID`

ポイント：上記テンプレートを .github/workflows/deploy.yml に配置すれば、タグプッシュだけでマルチクラウドへ自動デプロイが完了します。

参考情報

AWS Docs – Deploying with Elastic Beanstalk
Azure Docs – GitHub Actions for Azure Web Apps

5. 再利用可能なワークフローと Composite Action の作り方

大規模組織や複数リポジトリで同一パイプラインを使い回す場合は、呼び出し可能ワークフロー と Composite Action が有効です。

5‑1. 再利用可能ワークフローのテンプレート例（H3）

workflow_call を用いると、入力・シークレットを外部から渡せる汎用ビルドテンプレートが作れます。

# .github/workflows/build-template.yml
name: Reusable Build

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
    secrets:
      NPM_TOKEN:
        required: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: 'npm'
      - name: Install dependencies
        run: npm ci
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Run tests
        run: npm test

# .github/workflows/build-template.yml

on:

workflow_call:

inputs:

node-version:

required: true

type: string

secrets:

NPM_TOKEN:

required: true

jobs:

build:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Setup Node.js

uses: actions/setup-node@v4

with:

node-version: ${{ inputs.node-version }}

cache: 'npm'

- name: Install dependencies

run: npm ci

env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

- name: Run tests

run: npm test

呼び出し側：

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [ main ]

jobs:
  app-build:
    uses: ./.github/workflows/build-template.yml
    with:
      node-version: '20'
    secrets:
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

# .github/workflows/ci.yml

on:

push:

branches: [ main ]

jobs:

app-build:

uses: ./.github/workflows/build-template.yml

with:

node-version: '20'

secrets:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

ポイント：テンプレートを一箇所だけ更新すれば、全リポジトリのビルドロジックが即座に反映されます。

5‑2. Composite Action の作成と公開手順（H3）

複数ステップをひとつにまとめた Composite Action は action.yml に定義し、社内リポジトリまたは Marketplace に公開できます。

# .github/actions/docker-login/action.yml
name: Docker Login
description: Log in to a Docker registry using provided credentials.
inputs:
  registry:
    description: 'Registry URL (e.g., ghcr.io)'
    required: true
  username:
    description: 'Docker username'
    required: true
  password:
    description: 'Docker password or token'
    required: true

runs:
  using: &quot;composite&quot;
  steps:
    - name: Login to registry
      run: echo &quot;${{ inputs.password }}&quot; | docker login ${{ inputs.registry }} -u ${{ inputs.username }} --password-stdin

# .github/actions/docker-login/action.yml

description: Log in to a Docker registry using provided credentials.

inputs:

registry:

description: 'Registry URL (e.g., ghcr.io)'

required: true

username:

description: 'Docker username'

required: true

password:

description: 'Docker password or token'

required: true

runs:

using: "composite"

steps:

- name: Login to registry

run: echo "${{ inputs.password }}" | docker login ${{ inputs.registry }} -u ${{ inputs.username }} --password-stdin

利用例：

- uses: ./.github/actions/docker-login
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}

- uses: ./.github/actions/docker-login

with:

registry: ghcr.io

username: ${{ github.actor }}

password: ${{ secrets.GITHUB_TOKEN }}

ポイント：内部ロジックを隠蔽でき、呼び出し側は一行で完結するため可読性が向上します。

参考情報

GitHub Docs – Creating a composite run steps action

6. デプロイ失敗時のトラブルシューティングと承認プロセス

自動デプロイは便利ですが、失敗した際に迅速に原因を特定し、安全にロールバックできる仕組みが必要です。

6‑1. 環境保護ルールと手動承認ステップ（H3）

environment: と GitHub Settings の Environments で「Require approval」や「Wait timer」を設定すると、本番デプロイ前にレビュー担当者の承認が必須になります。

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.example.com   # 環境 URL（オプション）
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Cloud Run
        run: |
          gcloud run deploy my-service \
            --image=gcr.io/${{ secrets.GCP_PROJECT }}/myapp:${{ github.sha }} \
            --region=asia-northeast1 \
            --platform=managed

jobs:

deploy-prod:

runs-on: ubuntu-latest

environment:

url: https://myapp.example.com # 環境 URL（オプション）

steps:

- uses: actions/checkout@v4

- name: Deploy to Cloud Run

run: |

gcloud run deploy my-service \

--image=gcr.io/${{ secrets.GCP_PROJECT }}/myapp:${{ github.sha }} \

--region=asia-northeast1 \

--platform=managed

ポイント：承認が完了するまでジョブは保留状態になるため、誤って本番環境へデプロイされるリスクを低減できます。

6‑2. ログ分析と典型的エラー例（H3）

失敗時は GitHub の Run タブでステップごとのログを確認し、クラウド側のデプロイ履歴とも照らし合わせます。以下はよくあるエラーと対処法です。

エラーコード	発生原因	推奨対策
`AuthenticationFailed` (AWS)	シークレットが古い、または IAM ロール権限不足	Secrets を最新にし、ポリシーに `elasticbeanstalk:*` を付与
`Docker timeout`	キャッシュ不整合でレイヤ取得失敗	キーを見直すか `--no-cache` で再ビルド
`ResourceExhausted` (GCP)	クォータ超過またはメモリ不足	プロジェクトクォータを拡張、もしくは `resource_class` を上げる

GitHub のフィルタ機能（例：error、setup-node）でログを絞り込むと原因特定が速くなります。

ポイント：環境保護と詳細ログの組み合わせにより、失敗からの復旧とロールバックが迅速に行えます。

7. 参考資料・リンク集

項目	URL
GitHub Actions ワークフロー構文	https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
キャッシュベストプラクティス（公式）	https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
`actions/cache@v3` Marketplace	https://github.com/actions/cache
`setup-node@v4` Marketplace	https://github.com/actions/setup-node
Docker Build‑Push Action (`v5`)	https://github.com/docker/build-push-action
AWS Elastic Beanstalk デプロイガイド	https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deployment.html
Azure Web Apps GitHub Actions 連携	https://learn.microsoft.com/en-us/azure/app-service/deploy-github-actions
Google Cloud Run GitHub Actions 設定	https://cloud.google.com/run/docs/tutorials/github-actions
Vercel Action (`v3`)	https://github.com/vercel/action
Netlify CLI Action (`v2`)	https://github.com/nwtgck/actions-netlify-cli
Composite Action 作成ガイド	https://docs.github.com/en/actions/creating-actions/creating-a-composite-run-steps-action

以上が Acme 社の開発者向けに最適化した、実務で即活用できる GitHub Actions の全体像です。ご質問や実装上の課題があれば、Acme Tech Support（support@acme.co.jp）までお気軽にお問い合わせください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-GitHubActions

comment コメントをキャンセル

: GitHubActions

GitHub Actions と AWS Amplify で OIDC を活用した自動デプロイパイプライン構築

本記事では、GitHub Actions と AWS Amplify を連携させ、OIDC 認証と最小権限 IAM ロールで安全に自動デプロイを実現する CI/CD パイプラインの構築手順をハンズオン形式で紹介します。ブランチ戦略やプレビュー環境の自動作成・削除、ベストプラクティスまで網羅しています。

: GitHubActions

GitHub 2025-2026セキュリティ機能とワークフローのベストプラクティス

GitHubのSecret ProtectionとCode Securityによりサプライチェーン攻撃リスクが38%削減。SHA-256ハッシュ固定やAWS IAM最小権限設定を含むワークフロー構築方法。

: GitHubActions

GitHub Actions vs CircleCI 比較：パフォーマンス・コスト・信頼性2026年

GitHub Actions と CircleCI を最新ベンチマーク・信頼性データで比較し、速度差40%、料金プラン、ロックインリスクをまとめた完全ガイド。

: GitHubActions

GitHub Actions 環境変数設定基本とセキュリティ

GitHub Actionsでの環境変数設定基本からSecrets管理まで。ワークフロー全体/ジョブ単位の共有方法やセキュリティリスク回避策を解説しています。

: GitHubActions

GitHub Actions: 自動化の基礎とYAMLワークフローの始め方

GitHub Actionsはコードのビルド・テスト・デプロイを自動化するCI/CDプラットフォームです。YAMLファイルによるワークフロー構築やイベントトリガー設定、デバッグ方法などを初心者向けに解説しています。

Okta Identity Cloud導入の意義と中小企業向けメリット

Vercel AI Agent Deployment Guide 2026 | MCP Protocol Compliance