GitHub Actions 入門：YAMLワークフロー基礎とトリガー設定

正直、初めて.github/workflowsフォルダのYAMLファイルを見た時、少し困惑しました。インデント、コロン、意味不明なキーワード——on、jobs、runs-on。これ何？食べられるの？

後でプロジェクトが増えて、コード推送後に毎回手動でテスト実行、手動デプロイを繰り返すのが面倒になりました。その時気づきました：GitHub Actions、本当に便利。

この記事ではGitHub Actionsの基礎——YAMLワークフローの書き方、トリガー設定方法——を紹介します。複雑な機能は扱いません、実用的な部分だけ。まず動かせることが大事。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

GitHub Actionsで何ができるか

簡単に言えば：自動化。

以前、コード推送後は手動で多くの作業が必要でした：テスト実行、コードフォーマット確認、プロジェクトビルド、サーバデプロイ。今はこれらをYAMLファイルに書くだけで、GitHubが自動実行。

例えば：mainブランチにコード推送毎に、GitHub Actionsが自動でテスト実行。テスト通過後のみPRマージ許可。これでコード品質保証、安心。

もう一つのメリット：無料。公開リポは完全無料。プライベートリポは月2000分無料枠あり（個人プロジェクトで十分）。

YAMLワークフローの基本構造

最も簡単な例を見てみましょう：

name: テストワークフロー

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name:挨拶を表示
        run: echo "Hello, GitHub Actions!"

各行の解説：

name：ワークフロー名。自由に命名、GitHub Actionsページで識別用。

on：トリガー条件。pushを書くと、コード推送毎にこのワークフロー実行。

jobs：ジョブブロック。1つのワークフローは複数ジョブを含め可能、並列または順次実行。

build：このジョブのID。自由命名、但し意味ある名前推奨（build、test、deploy等）。

runs-on：実行環境。ubuntu-latestは最新Ubuntuサーバで実行。windows-latest、macos-latestも選択可能。

steps：ステップリスト。1つのジョブは複数ステップ構成、順次実行。

run：実行コマンド。ここはメッセージ表示のみ。

これが最も基本の構造。複雑なワークフローは、この基礎に更多ジョブ、更多ステップ、更多判断ロジックを追加。慌てず、基礎を理解すれば複雑も自然と分かります。

トリガー：ワークフロー実行タイミング

トリガーはワークフロ全体の「スイッチ」。正しく設定すれば、適切なタイミングで実行。

4つの主要トリガー：push、pull_request、schedule、workflow_dispatch。順に解説。

1. push：コード推送時トリガー

最も使用頻度高いトリガー。

on: push

この設定で、任意ブランチへのコード推送毎にトリガー。

但し通常、特定ブランチのみトリガーしたい：

on:
  push:
    branches:
      - main
      - dev

この設定意味：mainまたはdevブランチへの推送のみトリガー。他ブランチ？無視。

更に詳細——特定パス変更のみ監視：

on:
  push:
    branches:
      - main
    paths:
      - 'src/**'
      - 'package.json'

src/ディレクトリ下のファイルまたはpackage.json変更のみトリガー。ドキュメントや設定ファイル変更でCI無駄実行回避。

2. pull_request：PR関連操作トリガー

PR（Pull Request）はチーム協力の核心場面。

on: pull_request

この設定で、PR全操作トリガー：PR作成、PR更新、PR再開。

但し同様にブランチ限定可能：

on:
  pull_request:
    branches:
      - main

ターゲットブランチがmainのPRのみトリガー。

PR操作タイプ指定も可能：

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened

• opened：PR作成時
• synchronize：PRに新コミット追加（新変更推送時）
• reopened：閉じたPR再開

この設定は一般的——PR作成時テスト実行、変更問題ない確認。

3. schedule：定時トリガー

定時タスク同様、計画通りワークフロー実行。

on:
  schedule:
    - cron: '0 0 * * *'

これはcron式、形式：分 時 日 月 曜日。

上記意味：毎日UTC時間0時（北京時間朝8時）1回実行。

常用場面：毎日自動テスト、定時キャッシュクリア、定期レポート生成。

正直、cron式は書き間違いやすい。確認用オンラインツールあり、crontab.guru等。

4. workflow_dispatch：手動トリガー

時には手動トリガー必要——例1クリックデプロイ、特定タスク手動実行。

on: workflow_dispatch

設定後、GitHub Actionsページに「Run workflow」ボタン表示。クリックで手動トリガー。

入力パラメータ設定も可能：

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ環境'
        required: true
        default: 'production'
        type: choice
        options:
          - production
          - staging

手動トリガー時、デプロイ環境選択可能。テストまたは本番環境へ1クリックデプロイ。便利ですね。

トリガー組み合わせ

実際のプロジェクトでは複数トリガー必要な場合多い：

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  schedule:
    - cron: '0 6 * * 1'  # 毎週月曜6時UTC
  workflow_dispatch:

この設定意味：

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

• mainブランチ推送時トリガー
• ターゲットブランチmainのPRトリガー
• 毎週月曜朝1回実行
• 手動トリガー対応

1ワークフロー、複数トリガー方法。一般的な設定パターン。

実践：Node.jsプロジェクトに自動テスト設定

実用的な例を作成——Node.jsプロジェクト自動テスト。

プロジェクト構造想定：

my-project/
├── src/
├── tests/
├── package.json
└── .github/
    └── workflows/
        └── test.yml

.github/workflows/test.ymlファイル作成：

name: 自動テスト

on:
  push:
    branches:
      - main
      - dev
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      # 1. コードチェックアウト
      - name: コードチェックアウト
        uses: actions/checkout@v4

      # 2. Node.js設定
      - name: Node.js設定
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      # 3. 依存関係インストール
      - name: 依存関係インストール
        run: npm ci

      # 4. テスト実行
      - name: テスト実行
        run: npm test

      # 5. コードフォーマット確認（任意）
      - name: コードフォーマット確認
        run: npm run lint

各ステップ解説：

コードチェックアウト：actions/checkout@v4は公式提供Action、リポジトリを実行環境にダウンロード。

Node.js設定：actions/setup-node@v4も公式Action、指定Node.jsバージョンインストール。node-version: '20'はNode.js 20使用意味。

依存関係インストール：npm ciはCI環境でnpm installより適切——package-lock.json厳密従い、高速で信頼性高。

テスト実行：テストコマンド直接実行。前提はpackage.jsonでtestスクリプト設定済み。

コードフォーマット確認：ESLintまたはPrettier設定済みなら、このステップで自動フォーマット確認。

このワークフローはmainまたはdevブランチ推送時トリガー、ターゲットブランチmainのPR時もトリガー。各変更はテスト監視。

よくある落とし穴

正直、YAML書き始めた時多くの失敗経験あり。一般的なもの紹介：

1. インデントエラー

YAMLはインデント極めて敏感。スペース必須、タブ不可。インデントレベル一致必須。

# ❌ エラー：インデント不一致
jobs:
build:
  runs-on: ubuntu-latest

# ✅ 正解：統一インデント
jobs:
  build:
    runs-on: ubuntu-latest

エディタのYAMLプラグイン使用推奨、インデントエラー自動ハイライト。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

2. トリガー動作しない

時には設定済みトリガーが動作しない。一般的原因：

• ブランチ設定エラー：developブランチ推送、但し設定はmainのみ監視
• フォークリポ：フォークリポからの推送はpushイベントトリガーしない
• PR from fork：フォークからのPRは一部トリガー動作しない

3. コードチェックアウト忘れ

初心者最も犯しやすいエラー：actions/checkout@v4忘れ。

このステップ無いと、ワークフロー環境は空——コード存在しない。

steps:
  # ❌ エラー：コードチェックアウト前にコマンド実行
  - run: npm test

  # ✅ 正解：先にコードチェックアウト
  - uses: actions/checkout@v4
  - run: npm test

4. 古いActionバージョン

一部チュートリアルはactions/checkout@v2またはv3使用。但し最新版v4推奨——機能完全、性能良好。

使用Actionの新バージョン定期確認。GitHubはバージョン古い通知。

実用的なアドバイス

トリガー選択原則

問い自分：

• 自動または手動？ → 自動：push/pull_request、手動：workflow_dispatch
• 頻度高い？ → 頻度高いならブランチまたはパス限定、リソース浪費回避
• チーム協力？ → PR場面pull_request必須設定

性能最適化Tips

• トリガー範囲限定：重要ブランチとパスのみ監視
• 並列実行：複数独立ジョブ並列実行可能
• キャッシュ活用：actions/setup-nodeはNode.jsと依存関係自動キャッシュ、毎回再インストール不要

明確命名

# ❌ 曖昧命名
jobs:
  job1:
    steps:
      - name: step1

# ✅ 明確命名
jobs:
  test:
    steps:
      - name: 依存関係インストール

明確な名前は問題調査便利——GitHub Actionsページは各ステップ名表示。

推奨学習パス

この記事は基礎のみ。深く学ぶなら、継続学習：

1. マトリックスビルド：複数環境（Node.js 16、18、20）同時テスト
2. キャッシュ最適化：手動キャッシュ設定、ビルド高速化
3. Secret管理：API Key、パスワード等機密情報安全保管
4. カスタムAction：独自Action封装、ロジック再利用
5. デプロイ自動化：サーバまたはクラウドプラットフォーム自動デプロイ

公式ドキュメント最良リソース：GitHub Actions Docs。内容完全、少し長い。

もう一つ提案：他人設定参照。GitHub上多くオープンソースプロジェクトは.github/workflowsフォルダに完全設定あり——コピーも可。

最後に

多く話しました、核心は3点：

1. YAML構造：name、on、jobs、steps——4キーワードで基本構造
2. トリガー設定：push、pull_request、schedule、workflow_dispatch——4種最も常用
3. 実践例：Node.js自動テスト最も典型的な入門場面

最初ワークフロー完成後の感覚記憶——コード推送、GitHub自動テスト実行、メール「テスト通過」通知。「全て制御中」安心感、本当に爽快。

後で高度機能学ぶ（マトリックスビルド、キャッシュ最適化、デプロイ自動化）、基礎あれば難しくない。GitHub Actions入門難易度低、但し上手く使えば時間大幅節約。少なくとも毎回コード推送後に手動テスト不要、そうですね？

参考資料

• GitHub Actions公式ドキュメント
• Workflow Syntax for GitHub Actions
• Events that trigger workflows

5 min read · 公開日: 2026年4月5日 · 更新日: 2026年4月5日

Easton

技術開発