GitHub Actionsとは?活用事例・使い方をエンジニアが実際の画面で解説

  • 2026.10.30
       
【GitHub Actions】テスト・ビルドを自動化

ソフトウェア開発では、コード修正の度にテストを実施する必要がありますが、毎回手作業で実行すると確認に時間がかかるだけでなく、実行し忘れや確認漏れが発生する可能性があります。
このような作業を自動化できる仕組みが、GitHub Actionsです。

本記事では、GitHub Actionsの基本的な仕組みや活用事例を紹介した上で、実際に自動テストを実行する方法を解説します。

GitHub Actionsとは

GitHub Actionsとは何か

GitHub Actionsとは、GitHubが提供するワークフロー自動化機能です。
リポジトリ内のソースコードに変更があった場合や、プルリクエストが作成された場合など、指定した条件に応じてさまざまな処理を自動で実行できます。

GitHub Actionsでは、自動化する処理のまとまりを「ワークフロー」と呼びます。
ワークフローは、リポジトリ内に配置したYAML形式のファイルで定義します。

ワークフローには、主に次の要素があります。

  • イベント(Event):ワークフローを実行するきっかけ。コードのプッシュやプルリクエストの作成などを指定する。
  • ジョブ(Job):ワークフロー内で実行する処理のまとまり。テストやビルドなど、目的ごとに分けて設定できる。
  • ステップ(Step):ジョブ内で実行する個々の処理。コマンドの実行や、あらかじめ用意されたアクションの利用などを指定する。

ワークフローが実行されると、GitHubが提供する実行環境(ランナー) などで設定に従って処理が進みます。
ランナーには、UbuntuなどのLinux環境やWindows、macOSの環境を指定できます。

▼こちらもチェック▼
GitHubとは?初心者向けにメリットや知識、機能を解説 GitHubとは?初心者向けにメリットや知識、機能を解説 ▶

GitHub Actionsの主な活用事例

GitHub Actionsは、様々な用途で利用することができます。代表的な活用事例を紹介します。

  • 自動テスト
    コードを変更したタイミングでテストを実行し、プログラムが想定どおりに動作するかを確認します。
    プルリクエストの作成時にテストを実行するように設定すれば、変更内容を取り込む前に問題を検出しやすくなります。
  • ビルドの自動化
    アプリケーションのソースコードを実行可能な形式に変換したり、配布用のファイルを生成したりする処理を自動化できます。
    対応する言語やフレームワークに合わせてコマンドを設定することで、ビルド作業を効率化できます。
  • デプロイの自動化
    コードの変更が特定のブランチに反映されたことなどをきっかけに、Webアプリケーションや各種サービスへのデプロイを実行できます。
    手作業による公開手順を減らし、リリース作業の標準化につなげられます。
  • 定期的な処理の実行
    スケジュールを設定して、定期的に処理を実行することも可能です。
    依存ライブラリの状態確認やデータの集計など、一定の間隔で繰り返す作業に活用できます。
▼こちらもチェック▼
【CI/CD】開発環境を効率化する CI/CDとは?テスト・公開を自動化する手順を実践解説 ▶

GitHub Actionsの使い方|自動テストを動かしてみる

ここからは、GitHub Actionsを使ってPythonの自動テストを実行してみましょう。
今回は、簡単な計算処理を行うPythonファイルと、その動作を確認するテストコードを用意します。

練習用のリポジトリを作成する

まずは、練習用のリポジトリを作成します。
GitHubにログインし、画面右上の「+」メニューから「New repository」を選択して、リポジトリ作成画面に移動します。

画面が表示されたら、リポジトリ名や公開範囲などの設定を行い、「Create repository」をクリックすることでリポジトリを作成できます。

GitHubのCreate a new repository画面でリポジトリ名にgithub-actions-python-testを入力し、公開範囲をPublicに設定した状態
リポジトリ作成画面
▼こちらもチェック▼
【画像付き】GitHubの使い方|設定・基本操作 【画像付き】GitHubの使い方|設定・基本操作 ▶

テストしたいPythonファイルを用意する

次に、テスト対象となるPythonファイルとテストコードを作成します。

まず、リポジトリの画面で「Add file」から「Create new file」を選択し、新しくファイルを作成します。
作成したファイルには、2つの数値を受け取り、その合計を返す関数を定義します。

GitHubのファイル作成画面でcalculator.pyにadd関数を記述した状態
calculator.pyの作成画面
calculator.py
def add(a, b):
    return a + b

コードを記述し終えたら、「Commit changes」で変更内容をコミットし、リポジトリに保存しましょう。
続いて、同様の手順でファイルを作成し、テストコードを記述します。

GitHubのファイル作成画面でtest_calculator.pyにunittestを使ったテストコードを記述した状態
test_calculator.pyの作成画面
test_calculator.py
import unittest
from calculator import add


class TestCalculator(unittest.TestCase):
    def test_add(self):
        self.assertEqual(add(2, 3), 5)


if __name__ == "__main__":
    unittest.main()

2つのファイルをそれぞれ作成し、コミットし終えたら、リポジトリ内にcalculator.pyとtest_calculator.pyが存在することを確認してください。

ワークフローファイルを作成する

続いて、テストを自動実行するためのワークフローファイルを作成します。
「Add file」から「Create new file」を選択し、ファイル名の入力欄に「.github/workflows/ファイル名.yml」と入力してください。

.github/workflows/は、GitHub Actionsのワークフローファイルを配置するためのディレクトリです。
ファイル作成時にディレクトリが存在しない状態でも、ファイル名にパスを含めて入力することで同時に作成できます。

.github/workflows/python-test.ymlにPythonのテストを実行するワークフローを記述している画面
ワークフローファイルの作成画面
.github/workflows/python-test.yml
name: Python Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v6

      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: "3.12"

      - name: Run tests
        run: python -m unittest discover -v

画面ではactions/setup-python@v5を指定していますが、GitHubはNode.js 20で動作するアクションの廃止を進めています。
これから作成する場合は、上記のようにNode.js 24に対応したv6以降を指定するのがおすすめです。

ワークフローファイルでは、以下の内容を設定しています。

  • name:ワークフロー名
  • on:ワークフローの実行タイミングの指定
  • jobs:実行する処理のまとまりを定義
  • runs-on:ジョブを実行する環境の指定
  • steps:ジョブ内で実行する処理順の定義

actions/checkoutはリポジトリのファイルを実行環境に取得するためのアクション、actions/setup-pythonは指定したバージョンのPythonを利用できるようにするためのアクションです。
最後に、python -m unittest discover -v というコマンドでテストを実行します。

Actionsタブで実行結果を確認する

ワークフローファイルをリポジトリにコミットすると、設定したイベントに応じてワークフローが実行されます。
今回の設定ではpushを指定しているため、ファイルをコミットしてリポジトリに変更を反映すると、自動テストが開始されます。

リポジトリ上部の「Actions」タブをクリックすると、ワークフローの実行履歴が表示されます。

ActionsタブのAll workflowsに、Create python-test.ymlの実行履歴が成功として表示された画面
Actionsタブの実行履歴

履歴をクリックすると、実行結果や各ステップのログなどの詳細内容を確認することができます。

ワークフローの実行詳細画面で、StatusがSuccessになりtestジョブが成功している状態
ワークフローの実行結果

わざとテストを失敗させて自動チェックを体験する

テストが失敗した場合の挙動も合わせて確認してみましょう。
今回は、テストコードの期待値を変更し、実際の計算結果と期待値が一致しない状態を作ります。

test_calculator.pyの期待値を5から6に変更している編集画面
テストコードの期待値を変更する

変更をコミットして保存したら、Actionsタブを開いて新しい実行履歴を確認します。
ワークフローの実行時にエラーが発生した場合、ログからエラーが発生した箇所と詳細内容を見ることができます。

Run testsステップのログに、AssertionError: 5 != 6とError: Process completed with exit code 1.が表示された画面
テスト失敗時のログ

このように、GitHub Actionsではテストが成功したかどうかを自動で判定できます。
開発者が毎回手動でテストを実行しなくても、コードの変更に伴う問題を早い段階で発見できる点が大きなメリットです。

作成したワークフローを読み解く

ここまでの実践で、ワークフローファイルを作成するだけで自動テストを実行できることが分かりました。
次に、設定ファイルの各項目がどのような役割を持っているのかを確認しましょう。

ワークフロー・ジョブ・ステップの関係

GitHub Actionsでは、ワークフロー、ジョブ、ステップという3つの単位で処理を管理します。

ワークフローは、自動化する処理全体を表します。
リポジトリ内の.github/workflows/にYAMLファイルを配置し、実行するタイミングや処理内容を定義します。

ジョブは、ワークフロー内で実行する処理のまとまりです。
例えば、テストを実行するジョブと、アプリケーションをビルドするジョブといったように、役割ごとに行う処理を分けて一つのまとまりとして定義することができます。
ジョブは、依存関係を設定しない限り、基本的に並列実行されます。

ステップは、ジョブ内で実行する個々の処理です。
コマンドを実行したり、既存のアクションを呼び出したりできます。
同じジョブ内のステップは、基本的に記述した順番に実行されます。

この構造を理解しておくと、処理を追加するときに、どの階層に設定を書くべきか判断しやすくなります。

いつ・どこで動かすかを決める設定

ワークフローの実行タイミングや実行環境は、主にonとruns-onで指定します。

  • on:実行のきっかけを指定する
    どのイベントが発生した際にワークフローを実行するかを指定する項目です。(今回のサンプルでは pushと pull_request時)
    必要に応じてブランチ名やイベントの種類を追加指定することも可能です。
  • runs-on:実行環境を指定する
    ジョブを実行するランナーの環境を指定する項目です。
    Pythonなどの開発環境を準備したり、テストを実行したりする処理は、このランナー上で行われます。
    実行するアプリケーションの要件に応じて、WindowsやmacOSなどの環境も選択可能です。

用意された部品を使う処理とコマンドを実行する処理

ワークフローのステップでは、主にusesとrunという2つの指定方法を利用します。

  • uses:既存のアクションを利用する
    usesは、あらかじめ用意されたアクションを利用するための項目です。
    アクションとは、特定の処理を再利用できるようにまとめたもののことを言います。
    主に、リポジトリ内のファイルの取得や実行環境のセットアップなどのために利用されます。
    公開されているアクションは、GitHub Marketplaceで検索できます。
  • run:コマンドを実行する
    runは、ランナー上で実行するシェルコマンドを指定するための項目です。
    各ステップの実行順の関係上、基本的に usesの後に記述します。

うまく動かないときの確認ポイント

Actionsタブにワークフローが表示されない

「Actions」タブを開いてもワークフローが見つからない場合は、まずファイルの配置場所や保存状態を確認してみてください。

ワークフローファイルは、リポジトリの.github/workflows/ディレクトリ内に配置する必要があります。
また、ファイルの拡張子は.ymlまたは.yamlである必要があります。

そのため、ファイル名の入力ミスや、別のディレクトリに作成していないかなどを確認しましょう。
作成したファイルがまだコミットされていない場合は、リポジトリに変更を保存する必要があります。

また、配置場所などに問題はない状態でも、ワークフローを実行するイベントが発生していない場合は、実行履歴に表示されないことがあります。
その場合は、イベントの指定に問題がないかなども合わせて確認するといいでしょう。

ワークフローファイルのエラーが表示される

YAMLの書式やワークフローの設定に問題があると、処理を実行する前にエラーが発生する場合があります。

AnnotationsにInvalid workflow fileのエラーと、Unexpected valueが発生した行番号が表示された画面
Invalid workflow fileのエラー表示

YAMLでは、インデントによって設定の階層を表現します。
そのため、スペースの数や位置が不適切だと、意図した構造として認識されないことがあります。
また、キー名の入力ミスや、文字列を囲む引用符の不整合なども、エラーの原因になります。

エラーメッセージが表示された場合は、該当するファイルや行番号、エラーの内容を確認し、設定を修正してから再度コミットしましょう。

ジョブが失敗したときの確認手順

ジョブが失敗した場合は、まずActionsタブから該当する実行履歴を開き、失敗したジョブとステップを特定しましょう。
各ステップのログには、実行したコマンドやエラーメッセージが記録されているため、最初に失敗したステップを確認すると、原因を切り分けやすくなります。

例えば、リポジトリの取得に失敗している場合はアクションの設定やアクセス権限を確認し、セットアップに失敗している場合は指定したバージョンや実行環境を確認します。
テストの実行で失敗している場合は、テストコードや実行コマンド、依存関係などを確認しましょう。

エラーメッセージを確認し、失敗した処理を特定してから修正することが、トラブルシューティングの基本です。

GitHub Actionsの料金と無料枠

GitHub Actionsを利用する際は、実行環境や利用するプランによって料金が異なる点に注意が必要です。

GitHub Actionsは、パブリックリポジトリで標準のGitHubホストランナーを利用する場合、基本的に無料で使用できます。
一方、プライベートリポジトリでは、契約プランに応じて無料利用枠が設定されており、上限を超えると追加料金が発生する場合があります。

GitHub Actions の無料使用
GitHub プランには、標準ランナー、アーティファクト ストレージ、キャッシュ ストレージの以下の時間が含まれています。
アカウントによって使われた分数は、毎月初めにゼロにリセットされます。

Planアーティファクト ストレージ分 (月あたり)キャッシュ ストレージ (リポジトリごと)カスタム イメージ ストレージ
GitHub Free500MB2,00010 GB適用なし
GitHub Pro1 GB3,00010 GB適用なし
GitHub Free 組織向け500MB2,00010 GB適用なし
GitHub Team2 GB3,00010 GB75 GB
GitHub Enterprise Cloud50 GB50,00010 GB150 GB
出典:GitHub Docs「GitHub Actions の課金」(2026年10月30日確認)

ただし、パブリックリポジトリでも、使用するランナーの種類によっては料金が発生する場合があるため、利用前に最新の料金条件を確認することが重要です。
また、料金や無料枠は変更される可能性があるため、実際に運用する際は公式ドキュメントの料金ページを参照してください。

活用の幅を広げるための設定と注意点

活用事例に合わせて実行のきっかけを変える

GitHub Actionsでは、onに指定するイベントを変更することで、ワークフローを実行するタイミングを調整できます。

例えば、mainブランチに変更が反映された場合だけテストを実行したいときは、次のように設定できます。

mainブランチへのpush時だけ実行する
on:
  push:
    branches:
      - main

毎日決まった時間に処理を実行したい場合は、scheduleイベントを利用できます。

毎日決まった時間に実行する
on:
  schedule:
    - cron: "0 0 * * *"

なお、cronの時刻は標準でUTC(協定世界時)として扱われるため、上記の設定は日本時間の毎日午前9時に実行されます。
日本時間で指定したい場合は、次のようにtimezoneでタイムゾーンを指定することもできます。

日本時間の毎日午前9時に実行する
on:
  schedule:
    - cron: "0 9 * * *"
      timezone: "Asia/Tokyo"

scheduleイベントのワークフローは、デフォルトブランチにあるワークフローファイルをもとに実行されます。
また、GitHub Actionsの負荷が高い時間帯は、実行が遅れる場合もあります。

また、workflow_dispatchを利用することにより、GitHubの画面などからワークフローを手動で実行することも可能です。

手動で実行できるようにする
on:
  workflow_dispatch:

ワークフローファイルがデフォルトブランチにあれば、Actionsタブのワークフロー画面に「Run workflow」ボタンが表示され、クリックするだけで実行できます。
定期実行や手動実行などを使い分けることで、用途に合った自動化を実現できます。

使うときの注意点

GitHub Actionsを安全かつ効率的に利用するために、以下のポイントに注意するようにしましょう。

  • 機密情報をコードに直接記述しない:APIキーやアクセストークンを利用する場合に、ワークフローファイルに値を直接書き込むのを避ける
  • 外部のアクションを利用するときは信頼性を確認する:公開元やソースコード、更新状況、必要とする権限などを確認する
  • 必要以上に広い権限を与えない:処理に必要な範囲に限定して設定する
  • 実行ログを確認して問題を早期に発見する:自動化した処理が正常に完了しているか、定期的に実行結果を確認する

APIキーなどの機密情報は、リポジトリの「Settings」→「Secrets and variables」→「Actions」からシークレットとして登録し、ワークフローではsecretsコンテキストで参照します。

シークレットを環境変数として渡す例
steps:
  - name: Run command with secret
    env:
      API_TOKEN: ${{ secrets.API_TOKEN }}
    run: |
      example-command "$API_TOKEN"

シークレットの値はログに出力されても自動でマスクされるため、ワークフローファイルに値を直接書くよりも安全に扱えます。
詳しい設定方法は、GitHub Docsのシークレットの使用に関するページを参照してください。

よくある質問

Q. GitHub Actionsを使うためにローカル環境へのインストールは必要ですか?

A. GitHubが提供するホストランナーを利用することで、ローカル環境に実行環境を用意しなくてもワークフローを実行できるため、必須ではありません。
ただし、利用するケースによっては、別途環境構築が必要になる場合があります。

Q. プライベートリポジトリでもGitHub Actionsは無料で使えますか?

A. プランごとに設定された無料利用枠の範囲内であれば、無料で利用できます。
例えばGitHub Freeでは、標準ランナーを月2,000分まで利用でき、使用した分数は毎月初めにリセットされます。
上限を超えて使う場合は追加料金が発生することがあるため、利用状況を定期的に確認しましょう。

Q. GitHub ActionsではPython以外の言語も利用できますか?

A. Pythonだけでなく、JavaScriptやTypeScript、Java、Goなど、さまざまな言語を利用できます。

Q. テストが失敗した場合、コードは自動で修正されますか?

A. 通常は自動で修正されないため、テストが失敗した場合はログを確認して原因を特定し、開発者がコードや設定を修正する必要があります。
ただし、別途AIツールなどと連携して、修正案を生成する仕組みを構築することは可能です。

Q. GitHub Actionsは個人開発でも利用できますか?

A. 個人開発でも利用可能です。
個人で管理しているアプリケーションの自動テストや、Webサイトのビルド、デプロイなどに活用できます。

まとめ

GitHub Actionsを利用すると、テスト・ビルド・デプロイなどの処理や、繰り返し発生する開発作業を自動化できます。
無料で利用できる枠も用意されているため、まずは簡単な自動テストから始め、必要に応じて定期実行やビルド、デプロイなどへ活用範囲を広げていきましょう。

     

Programmingカテゴリの最新記事