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と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 の形式を守る |
on を ON と書く | ワークフローが起動しない | 小文字の on を使う |
YAML入力ミスを防ぐコツ
VSCodeに「YAML」拡張(Red Hat製)を入れると、インデントのズレや型エラーを書きながらリアルタイムで教えてくれる。GitHub ActionsのYAMLを書くなら必須だ。
STEP 2: コア概念を4つだけ覚える
GitHub Actionsの仕組みは、4つの概念で構成されている。この4つを掴めば「設定に何を書けばいいかわからない」という状態から脱出できる。
4つのコア概念
.github/workflows/ 以下のYAMLファイル1つが1つのワークフローに対応する。複数作れる。push・pull_request・schedule・workflow_dispatch(手動実行)など。on: キーで指定する。jobs: 以下に定義する。各ジョブは独立した仮想マシン(Runner)で実行され、並列実行が可能。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 testGo / Python など他の言語も同じ構造
言語が変わっても構造は同じ。setup-node の部分を setup-go・setup-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: falsesecrets の使い方(セキュリティの要)
APIキーやパスワードをYAMLに直書きしてはいけない。GitHubのSecrets機能を使う。
- リポジトリの
Settings → Secrets and variables → Actions New repository secretでキー名と値を登録- ワークフローから
${{ 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: trueAWS 認証は Access Key より OIDC が推奨
上記では aws-actions/configure-aws-credentials を OIDC(OpenID Connect)で使っている。Access Key + Secret をSecretsに置く旧来の方法より安全で、AWSが公式推奨している方式だ。
| 認証方法 | メリット | デメリット |
|---|---|---|
| Access Key(旧来) | 設定が簡単 | キーのローテーションが必要・漏洩リスク |
| OIDC(推奨) | 一時的な認証情報のみ発行・キー管理不要 | IAMロールの設定が初回必要 |
デプロイワークフローが正常に完了すると、GitHub ActionsのUIに以下のような緑チェック画面が表示される。これが「CIが通った」状態だ。

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 pushJenkins・AWS CodePipeline との比較
SES現場ではJenkinsが多く、AWSプロジェクトではCodePipelineを使うことも多い。それぞれの使い分けを整理しておこう。
| GitHub Actions | Jenkins | AWS 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/checkout・actions/setup-node など)が多数ある。「やりたいこと + GitHub Actions」で検索すると既存のアクションが見つかることが多い。
Udemy で体系的に学ぶ
公式ドキュメントは情報量が多い反面、「どこから読むか」が初学者には分かりにくい。UdemyのGitHub Actions講座は実際に手を動かしながら概念を積み上げる構成になっているため、公式ドキュメントの前に一度通しで見ると理解が速い。筆者も最初に公式ドキュメントで概念を把握し、Udemyで実装パターンを補完する流れで覚えた。
Udemy でGitHub Actions講座を探す →
※本リンクはアフィリエイトリンクですまとめ
GitHub Actionsをゼロから使えるようになるための学習ステップをまとめる。
GitHub Actionsは「一度動くワークフローを作る」経験が最大の学習になる。公式ドキュメントを手元に置きながら、自分のリポジトリで実際に動かすことを最優先にしてほしい。
SESでの評価を上げる・転職を有利にする・副業案件を取るという目的があるなら、GitHub ActionsはDockerやAWSと並んで最もリターンが大きいスキルの一つだ。SES脱出ガイドもあわせて読んでほしい。