当サイトはアフィリエイトを含むプロモーションを掲載しています
GitHub Actions入門|初心者でも分かる自動化の始め方【2025年最新版】
開発現場で「CI/CDを導入したいけど、どこから始めれば…」と悩んでいませんか?
GitHub Actionsは、GitHubが提供する強力な自動化ツールです。プッシュやプルリクエストをトリガーに、テストやビルド、デプロイまでを自動化できる優れもの。しかも、パブリックリポジトリなら完全無料で使い放題という太っ腹ぶり。
本記事では、GitHub Actions初心者の方でも迷わず始められるよう、基本概念から実践的な使い方まで、日本語で分かりやすく解説します。編集部が実際に導入した際の体験談も交えながら、あなたのスキルアップをサポートします。
GitHub Actionsとは?CI/CDの基礎知識
そもそもCI/CDって何?
CI/CD(Continuous Integration/Continuous Delivery)は、日本語で「継続的インテグレーション/継続的デリバリー」と呼ばれる開発手法です。
簡単に言うと、**「コードを書いたら自動でテストして、問題なければ自動でリリースする仕組み」**のこと。手作業でやっていた面倒な作業を自動化することで、開発効率が劇的に向上します。
GitHub Actionsの特徴
GitHub Actionsは、GitHubリポジトリ上で直接CI/CDを実現できるサービスです。主な特徴は以下の通り:
特徴 | 説明 |
---|---|
GitHubとの完全統合 | リポジトリと密接に連携し、プッシュやPRと連動して自動実行 |
豊富な実行環境 | Linux、Windows、macOSの最新環境が利用可能 |
マーケットプレイス | 数千もの再利用可能なアクションが公開されている |
柔軟なワークフロー | YAMLファイルで複雑な処理フローも簡単に定義 |
無料枠が充実 | パブリックリポジトリは無料、プライベートも月2,000分まで無料 |
編集部の体験談
「最初はJenkinsを使っていたのですが、サーバー管理が大変で…。GitHub Actionsに移行してから、インフラ管理の手間が激減しました。特に、GitHubとの連携がスムーズなので、開発フローが格段にシンプルになりましたね」(編集部・エンジニアA)
GitHub Actionsのメリット・デメリット
メリット
- 導入が簡単
- GitHubアカウントがあればすぐ始められる
- サーバー構築不要で初期コストゼロ
- 豊富な無料枠
- パブリックリポジトリは完全無料
- プライベートリポジトリも月2,000分まで無料
- GitHub製の安心感
- GitHubとの相性抜群
- 公式サポートとドキュメントが充実
- マーケットプレイスの存在
- 他の開発者が作った便利なアクションを活用可能
- 車輪の再発明を避けられる
デメリット
- GitHub依存
- GitHubを使っていないプロジェクトでは利用不可
- GitHubの障害時には影響を受ける
- 実行時間の制限
- 1ジョブあたり最大6時間まで
- 長時間の処理には不向き
- 同時実行数の制限
- 無料プランでは同時実行ジョブ数に制限あり
基本構成要素を理解しよう
GitHub Actionsを使いこなすには、以下の4つの基本要素を理解することが重要です。
1. ワークフロー(Workflow)
ワークフローは、自動化したい一連の処理を定義したものです。.github/workflows/
ディレクトリ内にYAMLファイルとして保存します。
name: My First Workflow # ワークフローの名前
2. イベント(Event)
イベントは、ワークフローを実行するトリガーです。プッシュ、プルリクエスト、定期実行など様々なイベントが用意されています。
on: [push, pull_request] # プッシュまたはPR時に実行
3. ジョブ(Job)
ジョブは、同一のランナー上で実行される一連のステップです。複数のジョブは並列で実行されます。
jobs:
build: # ジョブ名
runs-on: ubuntu-latest # 実行環境
4. ステップ(Step)
ステップは、ジョブ内の個々の処理単位です。コマンドの実行や、既存のアクションの利用などを行います。
steps:
- name: Checkout code
uses: actions/checkout@v4 # 既存アクションの利用
- name: Run tests
run: npm test # コマンドの実行
構成要素の関係図
ワークフロー
├── イベント(トリガー)
└── ジョブ1(並列実行)
├── ステップ1(順次実行)
├── ステップ2
└── ステップ3
└── ジョブ2(並列実行)
├── ステップ1
└── ステップ2
実践!初めてのワークフロー作成
それでは、実際にワークフローを作成してみましょう。ここでは、Node.jsプロジェクトの自動テストを例に説明します。
ステップ1: ワークフローファイルの作成
リポジトリのルートディレクトリに.github/workflows/
フォルダを作成し、test.yml
ファイルを作成します。
name: Node.js CI
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16.x, 18.x, 20.x]
steps:
- name: リポジトリのチェックアウト
uses: actions/checkout@v4
- name: Node.js ${{ matrix.node-version }} のセットアップ
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: 依存関係のインストール
run: npm ci
- name: テストの実行
run: npm test
- name: ビルドの実行
run: npm run build --if-present
ステップ2: ワークフローの解説
上記のワークフローは以下の処理を行います:
- トリガー設定: mainとdevelopブランチへのプッシュ、mainブランチへのPR時に実行
- マトリックステスト: Node.js 16、18、20の3バージョンで並列テスト
- 処理の流れ:
- コードをチェックアウト
- Node.jsをセットアップ
- 依存関係をインストール
- テストを実行
- ビルドを実行
編集部の実践Tips
「最初は単純なワークフローから始めることをおすすめします。いきなり複雑な処理を組もうとすると、デバッグが大変です。まずは『pushしたらテストを実行』くらいから始めて、徐々に処理を追加していくのがコツですね」(編集部・エンジニアB)
よく使うトリガーイベント一覧
GitHub Actionsでは、様々なイベントをトリガーにワークフローを実行できます。以下、よく使われるイベントを紹介します。
イベント | 説明 | 使用例 |
---|---|---|
push | コードがプッシュされた時 | on: push |
pull_request | PRが作成・更新された時 | on: pull_request |
schedule | 定期実行(cron形式) | on: schedule: - cron: '0 9 * * 1' |
workflow_dispatch | 手動実行 | on: workflow_dispatch |
release | リリースが作成された時 | on: release: types: [created] |
issue | Issueが作成・更新された時 | on: issues: types: [opened] |
複数イベントの組み合わせ例
on:
push:
branches:
- main
- 'releases/**'
pull_request:
types: [opened, synchronize, reopened]
schedule:
- cron: '0 0 * * 0' # 毎週日曜日の0時に実行
workflow_dispatch: # 手動実行も可能に
便利なアクション活用例
GitHub Marketplaceには、数千もの便利なアクションが公開されています。ここでは、特に人気の高いアクションを紹介します。
1. actions/checkout – コードのチェックアウト
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 全履歴を取得(デフォルトは1)
2. actions/setup-node – Node.js環境のセットアップ
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm' # npm依存関係をキャッシュ
3. actions/cache – ビルドキャッシュの活用
- name: Cache node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
4. codecov/codecov-action – カバレッジレポート
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v3
with:
file: ./coverage/lcov.info
fail_ci_if_error: true
5. slackapi/slack-github-action – Slack通知
- name: Slack Notification
uses: slackapi/[email protected]
with:
channel-id: 'C1234567890'
slack-message: "ビルドが完了しました: ${{ job.status }}"
env:
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
環境変数とシークレットの管理
環境変数の設定
環境変数は、ワークフロー内で値を共有するために使用します。スコープは3つあります:
env:
GLOBAL_VAR: 'ワークフロー全体で使える' # ワークフローレベル
jobs:
build:
env:
JOB_VAR: 'このジョブ内で使える' # ジョブレベル
steps:
- name: Example step
env:
STEP_VAR: 'このステップ内で使える' # ステップレベル
run: |
echo $GLOBAL_VAR
echo $JOB_VAR
echo $STEP_VAR
シークレットの管理
APIキーやパスワードなどの機密情報は、GitHubのシークレット機能を使用して管理します。
シークレットの設定方法
- リポジトリの「Settings」→「Secrets and variables」→「Actions」
- 「New repository secret」をクリック
- 名前と値を入力して保存
シークレットの使用例
steps:
- name: Deploy to server
env:
API_KEY: ${{ secrets.API_KEY }}
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: |
# シークレットを環境変数として使用
./deploy.sh
セキュリティのベストプラクティス
項目 | 推奨事項 |
---|---|
シークレットの命名 | 大文字とアンダースコアを使用(例:API_KEY ) |
権限の最小化 | 必要最小限の権限のみ付与 |
定期的な更新 | シークレットは定期的に更新する |
ログへの出力禁止 | シークレットの値をログに出力しない |
エラー対処とデバッグのコツ
よくあるエラーと対処法
1. YAMLの構文エラー
# ❌ 間違い - インデントが不正
jobs:
build:
runs-on: ubuntu-latest
# ✅ 正しい
jobs:
build:
runs-on: ubuntu-latest
2. 権限エラー
# リポジトリへの書き込み権限が必要な場合
permissions:
contents: write
pull-requests: write
3. アクションのバージョンエラー
# ❌ 古いバージョン
- uses: actions/checkout@v2
# ✅ 最新バージョンを使用
- uses: actions/checkout@v4
デバッグテクニック
1. デバッグログの有効化
リポジトリのシークレットに以下を追加:
- 名前:
ACTIONS_STEP_DEBUG
- 値:
true
2. 環境情報の出力
- name: Debug - 環境情報の出力
run: |
echo "Event: ${{ github.event_name }}"
echo "Branch: ${{ github.ref }}"
echo "Commit: ${{ github.sha }}"
echo "Runner: ${{ runner.os }}"
3. ワークフローの手動実行
on:
workflow_dispatch:
inputs:
debug_enabled:
description: 'デバッグモードを有効化'
required: false
default: 'false'
編集部のデバッグ体験談
「最初はエラーメッセージを見ても意味が分からなくて苦労しました。でも、GitHubのActionsタブでログを詳細に確認できるので、一つずつ原因を特定していけば必ず解決できます。特に、YAMLのインデントミスは本当に多いので、VSCodeなどのエディタでYAML拡張機能を入れておくことをおすすめします」(編集部・エンジニアC)
料金プランと制限事項
無料プランの内容
項目 | パブリックリポジトリ | プライベートリポジトリ |
---|---|---|
利用時間 | 無制限 | 2,000分/月 |
ストレージ | 無制限 | 500MB |
同時実行ジョブ数 | 20 | 20 |
macOS同時実行数 | 5 | 5 |
有料プランの比較
プラン | 月額料金 | 含まれる時間 | 追加料金(分あたり) |
---|---|---|---|
Free | $0 | 2,000分 | – |
Team | $4/ユーザー | 3,000分 | $0.008 |
Enterprise | $21/ユーザー | 50,000分 | $0.008 |
実行時間の計算方法
OSによって実行時間の重み付けが異なります:
- Linux: 1分 = 1分
- Windows: 1分 = 2分として計算
- macOS: 1分 = 10分として計算
例:macOSで10分実行した場合、100分として課金されます。
まとめ:次のステップへ
GitHub Actionsは、現代の開発において欠かせないCI/CDツールです。本記事で紹介した基本を押さえれば、あなたも今日から自動化の恩恵を受けられます。
今すぐ始められる3つのステップ
- シンプルなワークフローから始める
- まずは「pushしたらテストを実行」から
- 徐々に複雑な処理を追加
- 公式ドキュメントを活用する
- GitHub Actions公式ドキュメント
- 日本語対応で分かりやすい
- コミュニティから学ぶ
- GitHub Marketplaceで人気のアクションを研究
- 他のプロジェクトのワークフローを参考に
編集部からのメッセージ
「GitHub Actionsを導入してから、リリース作業が格段に楽になりました。最初は学習コストもありますが、一度覚えてしまえば手放せなくなります。この記事が、あなたのスキルアップの第一歩になれば幸いです」(編集部一同)
開発の自動化は、エンジニアとしてのキャリアアップに直結します。GitHub Actionsをマスターして、より価値の高い仕事に集中できる環境を作りましょう!
本記事は2025年6月時点の情報を基に作成しています。GitHub Actionsの仕様は頻繁に更新されるため、最新情報は公式ドキュメントをご確認ください。