DevOctane
GitHub ActionsCI/CDDevOps学習

GitHub Actions 実践ガイド|CI/CDをゼロから構築する学習ステップ

2026.05.26更新: 2026.05.2638 min read
GitHub Actions 実践ガイド|CI/CDをゼロから構築する学習ステップ

「GitHub Actionsって聞いたことはあるけど、自分でゼロから書いたことはない」——SES現場に入ったとき、筆者はまさにこの状態だった。現場ではすでに動いているワークフローがあり、YAMLファイルを初めて目にして「これを書けと言われても何が何だかわからない」という感覚だった。

この記事では、GitHub Actionsを最初から自分で構築できるようになるための学習ステップを解説する。YAML初体験の人がハマるポイント・コア概念の掴み方・実際に使えるワークフロー例まで順番に説明する。

筆者はSES現場でGitHub Actionsに初遭遇し、公式ドキュメントとUdemyで独学した。その後、テスト実行・AIコードレビュー・デプロイの自動化を構築した経験をもとに書く。


この記事でわかること

  • GitHub Actionsのコア概念(workflow/job/step/action)の掴み方
  • YAML初体験でハマるポイントと書き方のコツ
  • テスト実行・AIレビュー・デプロイまでの実践ワークフロー例
  • Jenkins・AWS CodePipelineとの使い分け
  • DevOpsエンジニアとしてのキャリア価値

GitHub Actions とは何か

GitHub Actionsは、GitHubに組み込まれたCI/CD(継続的インテグレーション・継続的デリバリー)自動化プラットフォームだ。コードをpushしたとき・PRを作ったとき・特定の時刻に、任意のスクリプトを自動実行できる。

外部サービスの契約や別サーバーの用意は不要で、GitHubリポジトリに .github/workflows/ ディレクトリを作ってYAMLファイルを置くだけで動く。無料枠(パブリックリポジトリは無制限、プライベートリポジトリは月2,000分)があり、個人開発や小規模チームはほぼ無料で使える。

CI/CDとは何か(概念の整理)

GitHub Actionsに入る前に、CI/CDの概念を整理しておこう。

CI
継続的インテグレーション(Continuous Integration)
コードをリポジトリにpushするたびに、自動でテスト・Lint・ビルドを実行する。「動く状態を常に維持する」ための仕組み。
CD
継続的デリバリー / デプロイ(Continuous Delivery / Deployment)
テストを通過したコードを、自動でステージング・本番環境へデプロイする。「リリース作業をなくす」ための仕組み。

CIとCDを合わせた「CI/CDパイプライン」を構築することで、コードをpushするだけで「テスト → ビルド → デプロイ」が全自動で走るようになる。


STEP 1: YAML の基礎を先に押さえる

GitHub ActionsのワークフローはすべてYAML形式で記述する。**YAMLを書いたことがない人は、ここが最初の壁になる。**筆者も初めてYAMLを書いたのがGitHub Actionsだった。

YAMLの基本ルール(最低限これだけ)

YAMLはインデント(字下げ)でデータの階層を表す。タブは使えない。スペース2つが基本だ。

# キーと値
name: my-workflow
 
# ネスト(階層)
jobs:
  test:
    runs-on: ubuntu-latest
 
# リスト(-)
steps:
  - name: チェックアウト
    uses: actions/checkout@v4
  - name: テスト実行
    run: npm test

よくある書き間違いパターン

ミス症状対処
タブでインデントfound character '\t' エラースペース2つに統一
インデントのズレジョブが認識されない同階層は同じ字下げ幅に揃える
: の後にスペースなしパースエラーkey: value の形式を守る
onON と書くワークフローが起動しない小文字の on を使う

YAML入力ミスを防ぐコツ
VSCodeに「YAML」拡張(Red Hat製)を入れると、インデントのズレや型エラーを書きながらリアルタイムで教えてくれる。GitHub ActionsのYAMLを書くなら必須だ。


STEP 2: コア概念を4つだけ覚える

GitHub Actionsの仕組みは、4つの概念で構成されている。この4つを掴めば「設定に何を書けばいいかわからない」という状態から脱出できる。

4つのコア概念

01
Workflow(ワークフロー)
自動化の全体定義。.github/workflows/ 以下のYAMLファイル1つが1つのワークフローに対応する。複数作れる。
02
Event(イベント)
ワークフローを起動するトリガー。pushpull_requestscheduleworkflow_dispatch(手動実行)など。on: キーで指定する。
03
Job(ジョブ)
ワークフロー内の処理単位。jobs: 以下に定義する。各ジョブは独立した仮想マシン(Runner)で実行され、並列実行が可能。
04
Step(ステップ)
ジョブ内の処理を順番に並べたもの。各ステップは run:(シェルコマンド)か uses:(外部アクション呼び出し)で定義する。

構造を図で確認する

Workflow(ファイル1つ)
└─ on: push          ← Event
└─ jobs:
   ├─ test:          ← Job 1
   │  └─ steps:
   │     ├─ checkout ← Step 1
   │     └─ run test ← Step 2
   └─ build:         ← Job 2(testと並列実行可)
      └─ steps:
         └─ docker build

ワークフローファイルの骨格はこのパターンで覚えておくといい。


STEP 3: 実践ワークフロー① — テスト自動実行

最初に構築すべきワークフローは**「PRを作ったらテストが自動で走る」**だ。SES現場でも最も多く見るパターンで、筆者が初めて触れたのもこのタイプだった。

Node.js プロジェクトのテスト実行

# .github/workflows/test.yml
name: テスト自動実行
 
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
 
    steps:
      - name: コードをチェックアウト
        uses: actions/checkout@v4
 
      - name: Node.js をセットアップ
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
 
      - name: 依存パッケージをインストール
        run: npm ci
 
      - name: テストを実行
        run: npm test

Go / Python など他の言語も同じ構造

言語が変わっても構造は同じ。setup-node の部分を setup-gosetup-python に変えるだけだ。

# Go の場合
- name: Go をセットアップ
  uses: actions/setup-go@v5
  with:
    go-version: '1.22'
 
- name: テストを実行
  run: go test ./...

Lint チェックをセットで追加する

テストと合わせて Lint チェックも実行するのが現場のスタンダードだ。

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Lint チェック
        run: npm run lint
      - name: テスト実行
        run: npm test

テストが失敗したらPRをマージ不可にする
GitHubのリポジトリ設定(Settings → Branches → Branch protection rules)でテストジョブを「Required status checks」に追加すると、テスト失敗時にPRのマージボタンがグレーアウトされる。チームで品質を守る基本設定だ。


STEP 4: 実践ワークフロー② — AIコードレビュー

筆者が構築した中で、チームへのインパクトが大きかったのがAIによる自動コードレビューだ。PRを作成すると、AIがコードの問題点・改善提案・セキュリティリスクをコメントしてくれる。

GitHub Actions + AI レビューの仕組み

# .github/workflows/ai-review.yml
name: AI コードレビュー
 
on:
  pull_request:
    types: [opened, synchronize]
 
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
 
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
 
      - name: AI レビューを実行
        uses: coderabbitai/ai-pr-reviewer@latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          debug: false
          review_simple_changes: false
          review_comment_lgtm: false

secrets の使い方(セキュリティの要)

APIキーやパスワードをYAMLに直書きしてはいけない。GitHubのSecrets機能を使う。

  1. リポジトリの Settings → Secrets and variables → Actions
  2. New repository secret でキー名と値を登録
  3. ワークフローから ${{ secrets.キー名 }} で参照する
# ❌ 絶対にやってはいけない(公開リポジトリで即アウト)
env:
  API_KEY: sk-xxxxxxxxxxxx
 
# ✅ Secretsから参照する
env:
  API_KEY: ${{ secrets.OPENAI_API_KEY }}

GITHUB_TOKEN と自前のトークンは別物
secrets.GITHUB_TOKEN はGitHubが自動発行するトークンで登録不要。PRへのコメント・ラベル操作などに使える。外部API(OpenAI・AWSなど)には自分で Secrets に登録したトークンを使う。


STEP 5: 実践ワークフロー③ — Dockerビルド & デプロイ自動化

インフラ・バックエンドエンジニアが最も価値を発揮できるのが、Dockerイメージのビルドとデプロイ自動化だ。

Docker ビルド → ECR プッシュ → ECS デプロイ

# .github/workflows/deploy.yml
name: 本番デプロイ
 
on:
  push:
    branches: [main]
 
env:
  AWS_REGION: ap-northeast-1
  ECR_REPOSITORY: my-app
  ECS_SERVICE: my-service
  ECS_CLUSTER: my-cluster
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
 
    steps:
      - uses: actions/checkout@v4
 
      - name: AWS 認証(OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
 
      - name: ECR にログイン
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
 
      - name: Docker イメージをビルド & プッシュ
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
 
      - name: ECS にデプロイ
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: task-definition.json
          service: ${{ env.ECS_SERVICE }}
          cluster: ${{ env.ECS_CLUSTER }}
          wait-for-service-stability: true

AWS 認証は Access Key より OIDC が推奨

上記では aws-actions/configure-aws-credentials を OIDC(OpenID Connect)で使っている。Access Key + Secret をSecretsに置く旧来の方法より安全で、AWSが公式推奨している方式だ。

認証方法メリットデメリット
Access Key(旧来)設定が簡単キーのローテーションが必要・漏洩リスク
OIDC(推奨)一時的な認証情報のみ発行・キー管理不要IAMロールの設定が初回必要

デプロイワークフローが正常に完了すると、GitHub ActionsのUIに以下のような緑チェック画面が表示される。これが「CIが通った」状態だ。

GitHub Actionsのワークフロー実行画面:deployジョブが成功(緑チェック)している状態
筆者が構築したVercelデプロイワークフローの実行結果。deployジョブが1分17秒で完了し、Successと表示されている

STEP 6: よく使うパターンの早見表

実務でよく登場するパターンをまとめた。「ゼロから書く」より「パターンを組み合わせる」が GitHub Actions の上達の近道だ。

トリガーのパターン

on:
  push:
    branches: [main]           # mainブランチへのpush時
  pull_request:
    branches: [main, develop]  # PRを作成・更新時
  schedule:
    - cron: '0 9 * * 1'        # 毎週月曜9時(UTC)
  workflow_dispatch:           # 手動実行ボタン

環境変数・条件分岐

jobs:
  deploy:
    runs-on: ubuntu-latest
    # mainブランチのpushのみデプロイ
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
 
    env:
      NODE_ENV: production
      APP_PORT: 3000
 
    steps:
      - run: echo "環境: $NODE_ENV"

ジョブ間の依存関係(順序制御)

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test
 
  deploy:
    needs: test          # test ジョブ完了後に実行
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

キャッシュで高速化

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

STEP 7: デバッグのコツ

ワークフローが失敗したとき、GitHub ActionsのUIのログを読むのが基本だ。ただしログが長いと読みにくい。

デバッグを効率化する3つの方法

① ステップ名を分かりやすく書く

run: npm test のステップ名が Run npm test だと、複数ステップが並んだときにどこで失敗したか一目でわかりにくい。name: を必ず書く習慣をつける。

# ❌ 名前がない
- run: npm ci
- run: npm test
 
# ✅ 名前あり
- name: 依存パッケージをインストール
  run: npm ci
- name: 単体テストを実行
  run: npm test

echo でデバッグ出力を入れる

- name: デバッグ確認
  run: |
    echo "ブランチ: ${{ github.ref }}"
    echo "コミット: ${{ github.sha }}"
    echo "イベント: ${{ github.event_name }}"

act でローカル実行する

act はGitHub Actionsをローカルで実行できるOSSツールだ。pushするたびに確認するのは非効率なので、複雑なワークフローの開発時に使うと便利。

# インストール(macOS)
brew install act
 
# ローカルで実行
act push

Jenkins・AWS CodePipeline との比較

SES現場ではJenkinsが多く、AWSプロジェクトではCodePipelineを使うことも多い。それぞれの使い分けを整理しておこう。

GitHub ActionsJenkinsAWS CodePipeline
導入コスト低(設定ファイルのみ)高(サーバー構築が必要)中(AWSリソース設定が必要)
管理コスト低(GitHubが管理)高(自前サーバー管理)中(AWSが管理)
柔軟性高(Marketplace活用)非常に高(プラグイン豊富)中(AWSサービス連携に特化)
コスト無料枠ありインフラ費用AWS従量課金
向いている用途GitHubをメインで使うチームオンプレ・既存資産がある環境AWSにフルコミットの環境

筆者はSES離脱後にJenkinsとAWS CodePipelineも経験したが、新規プロジェクトの立ち上げならGitHub Actionsが圧倒的にコストパフォーマンスが高い。 Jenkinsは既存資産がある環境で引き続き使われるが、新規で選ぶ理由はほぼない。


GitHub Actions がなぜ「必須スキル」なのか

「一般的なスキルとして必須では」——ヒアリングで筆者がそう感じた通り、GitHub Actionsはもはやエンジニアの共通インフラになっている。

求人・転職での位置づけ

バックエンド・インフラ・DevOpsエンジニアの求人で「CI/CDの構築・運用経験」は標準的な要件として登場する。「GitHubを使っている」だけでなく「ワークフローを自分で書ける」ことが差別化になる。

スキルレベル市場評価
GitHub Actionsを読める・設定変更できるSES現場の基礎スキルとして期待される水準
テスト・Lint の自動化を構築できるバックエンド中堅以上として評価
DockerビルドからECSデプロイまで一貫して構築できるインフラ・DevOps分野でリード候補として評価
セキュリティ(OIDC・Secrets管理)を適切に設計できるシニア・アーキテクト水準

SES 脱出とキャリアの関係

SES現場では既存のワークフローを「使う立場」にとどまることが多い。自分でゼロから構築・設計した経験が持てれば、転職・フリーランス転向時の武器になる。クラウドエンジニアへの転向を目指している人は、GitHub Actions + Docker + AWS のセットで覚えると市場価値が大きく上がる。

クラウドエンジニアとしての全体的な学習ロードマップはクラウドエンジニアへの最短学習ロードマップも参照してほしい。


効率よく学ぶためのリソース

無料で使えるリソース

公式ドキュメント(最優先)

GitHub Actions の公式ドキュメントは非常によくできており、日本語訳も整っている。コンセプトの説明から実際のワークフロー例まで揃っている。筆者もここをメインに使った。

GitHub Marketplace

Actions Marketplace には、すでに公開されているアクション(actions/checkoutactions/setup-node など)が多数ある。「やりたいこと + GitHub Actions」で検索すると既存のアクションが見つかることが多い。

Udemy で体系的に学ぶ

公式ドキュメントは情報量が多い反面、「どこから読むか」が初学者には分かりにくい。UdemyのGitHub Actions講座は実際に手を動かしながら概念を積み上げる構成になっているため、公式ドキュメントの前に一度通しで見ると理解が速い。筆者も最初に公式ドキュメントで概念を把握し、Udemyで実装パターンを補完する流れで覚えた。

Udemy — セール時に2,000円前後で購入可能。GitHub Actions・Docker・CI/CD講座が豊富

Udemy でGitHub Actions講座を探す →

※本リンクはアフィリエイトリンクです

まとめ

GitHub Actionsをゼロから使えるようになるための学習ステップをまとめる。

01
YAML の基本ルールを覚える
インデントはスペース2つ。タブ禁止。VSCode拡張でリアルタイムチェック。
02
4つのコア概念を掴む
Workflow / Event / Job / Step の構造を頭に入れる。「設定に何を書くか」が見えてくる。
03
テスト自動実行から始める
push/PRで自動テストが走るワークフローを自分のリポジトリに実装する。
04
Secrets・条件分岐・キャッシュを覚える
実務で必要なパターンを1つずつ追加して、ワークフローを育てる。
05
Docker + AWS デプロイまで構築する
インフラエンジニアはここまで到達すると、DevOps分野のキャリア評価が一段上がる。

GitHub Actionsは「一度動くワークフローを作る」経験が最大の学習になる。公式ドキュメントを手元に置きながら、自分のリポジトリで実際に動かすことを最優先にしてほしい。

SESでの評価を上げる・転職を有利にする・副業案件を取るという目的があるなら、GitHub ActionsはDockerやAWSと並んで最もリターンが大きいスキルの一つだ。SES脱出ガイドもあわせて読んでほしい。

Udemy — GitHub Actions / Docker / AWS の実践講座をまとめて学べる

Udemy でCI/CD講座を探す →

※本リンクはアフィリエイトリンクです
DO
この記事を書いた人
DevOctane

バックエンド/インフラエンジニア歴8年。SES客先常駐から大手自社開発企業へ転職後、フリーランスとして独立。AWS・コンテナ・FinOps・バックエンド領域を中心に現場で培った知識を発信しています。