GitHub Actionsの概要

この講座では、GitHubの自動化ツールであるGitHub Actionsについて学びます。

GitHub Actionsの特徴とメリット
ワークフロー・ジョブ・ステップの概念
トリガー（イベント）の種類
ランナー（Runner）とアクション（Action）
外部サービスとの連携

1. GitHub Actionsとは

GitHub Actionsは、GitHub上でワークフローの実行や結果の確認ができる自動化ツールです。開発から運用までをシームレスに管理でき、GitHubだけで開発の流れを完結できるのが特徴です。

1.1 GitHubとの統合

GitHub ActionsはGitHubと密接に連携しており、プッシュやプルリクエストの作成などのイベントをトリガーに、自動で処理を実行できます。同じプラットフォーム上でコードやリポジトリに直接アクセスできるため、設定やスクリプトの記述もシンプルになります。

1.2 外部サービスとの連携

また、GitHub Actionsでは、AWSをはじめとするさまざまな外部サービスと簡単に連携できます。AWSの場合は、OIDC（OpenID Connect）を使って安全に認証・連携を行えます。また、アクセスキーなどの機密情報はSecrets機能で安全に管理できます。公式アクションやCLIを使えば、柔軟な連携処理も実現できます。

1.3 GitHub上で完結

合わせて、GitHub Actionsは、ワークフローの実行から結果の確認まですべてGitHub上で完結できます。他のツールを併用する場合のように、別の管理画面を開く必要がなく、GitHubだけで一元的に管理できる点が大きな利点です。

2. GitHub Actionsの構成要素

このセクションでは、GitHub Actionsにおけるいくつかの構成要素を説明します。

2.1 ワークフロー（Workflow）

GitHub Actionsの処理はワークフローという単位で定義され、その中がジョブとステップに細分化されます。

ワークフローとは、GitHub Actionsで自動的に実行される一連の処理の流れを定義したものです。たとえば、コードがGitHubにプッシュされたときに「ビルド → デプロイ」といった処理を自動で実行するよう設定します。この全体のフローを「ワークフロー」と呼びます。

ワークフローには、どのイベントで処理を開始するか（例：push、pull_request）、どの環境で実行するか（例：ubuntu-latest）、どんな処理を行うか（例：テストやデプロイ）といった情報を記述します。これらの記載については後ほど詳しく説明します。

ワークフローのコード例

ワークフローのコード例を見てみましょう。細かい部分は後ほど説明しますが、ここではnameの部分に注目してください。

name: Test Workflow

nameにはワークフローの名前を指定します。ここでは「Test Workflow」という名前を付けています。この下に、トリガーや実行する処理を順に記載していきます。

ワークフローの画面表示

こちらが実際のGitHubにて、ワークフローを表示させた画面です。今回は「Test Workflow」という名前のワークフローを作成しており、左側の一覧にそれが表示されています。複数のワークフローを作成すれば、ここに追加されていきます。

中央の部分にはワークフローの実行履歴が表示されます。ここから、実行のステータスや結果を参照することができます。

実際のワークフローの作成方法や実行方法は、この後説明します。

2.2 ジョブ（Job）

ジョブとは

ワークフローはジョブとステップによって構成されます。ジョブは、ワークフロー内で実行される処理のまとまりを表します。

たとえば「ビルド」「デプロイ」という2つの処理を行う場合、それぞれを1つのジョブとして定義します。

ジョブごとに実行結果を確認したり、失敗したジョブのみを再実行したりできるため、柔軟な運用が可能です。

ジョブのコード例

ジョブのコード例を見てみましょう。

jobs:
  hello:

jobs:の下に、ジョブの名前を指定して定義します。ここではhelloという名前のジョブを定義しています。ジョブは複数指定することもできます。

ジョブの画面表示

これがGitHub Actionsの実行結果の画面ですが、ジョブごとに実行結果が表示される様になっています。

2.3 ステップ（Step）

ステップとは

ステップは、ジョブの中で順に実行される具体的な処理（コマンドやアクション）を記述する部分です。実際に何を行うかを定義する箇所であり、スクリプトの実行や外部アクションの呼び出しなどを指定します。

ステップのコード例

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - name: メッセージを表示
        run: echo "Hello, GitHub Actions!"

このコードにあるsteps:と記載のある部分が、実際のステップを記載する箇所です。このコードでは、ステップに「メッセージを表示」という名前をつけています。

runは、ステップの中でシェルコマンドを実行するための命令です。run:の後ろに記載したコマンドが実行されます。実行できるコマンドは、この後説明する「ランナー」と呼ばれる実行環境によって異なります。今回使用しているランナーはubuntu（Linux）で動作するため、Linux系のコマンドが実行できます。

ここではecho "Hello, GitHub Actions!"という命令で、"Hello, GitHub Actions!"という文字列をコンソール上に出力しています。echoはLinuxにおいて、指定した文字列をコンソールやログに出力するコマンドです。

実行結果の例

この画面は、ワークフローの実行結果を表示した画面です。ステップのnameで指定した「メッセージを表示」が、実行結果として表示されています。

「メッセージを表示」を展開すると、echoコマンドで表示した「Hello, GitHub Actions!」のメッセージが表示されます。

3. GitHub Actionsの実行方法

このセクションでは、GitHub Actionsを実行する方法となる「トリガー」や、実行環境である「ランナー」について説明します。

3.1 トリガー（Trigger）

トリガーは、GitHub Actionsにおいてワークフローの実行を開始するきっかけとなるイベントのことです。GitHub ActionsではGitHubの各種操作に応じてさまざまなトリガーが用意されています。

トリガーの種類

代表的なトリガーには次のようなものがあります。

トリガー	説明	主な利用シーン
`push`	ブランチにコードがプッシュされたときに実行	ビルドやデプロイなど、反映処理の自動化
`pull_request`	プルリクエストが作成または更新されたときに実行	レビュー前の静的解析や自動テスト
`schedule`	`cron`形式で指定した時刻に定期実行	毎週日曜日の午前1時に自動実行するなど
`workflow_dispatch`	手動でワークフローを実行	特定のタイミングで自動テストだけを実行したい場合など

このほかにも、GitHub Issueの更新やリリースの公開など、さまざまなイベントをトリガーとして設定することができます。

トリガーのコード例

これらをYAMLファイルのon:セクションで指定します。例えば、次のように記述します。

on:
  workflow_dispatch:

この例では、workflow_dispatchを指定しているため、手動での実行を行います。

このように、トリガーを設定することで、開発の各段階（コード更新・レビュー・リリースなど）に応じて、自動的にビルドやテスト、デプロイを実行する仕組みを作ることができます。

3.2 ランナー（Runner）

ランナーとは

ランナーとは、ジョブを実際に実行するための環境のことを指します。ワークフローで定義した処理は、このランナーで指定した環境上で動作します。

例えば、Linux（Ubuntu）、Windows、macOSなどのOS環境をGitHub Actionsの実行環境として指定し、ワークフローを実行できます。ここでのlatestとは「最新版」を意味します。

Ubuntuをランナーとして指定した場合、GitHubがUbuntu環境を自動的に用意し、その中でワークフローを実行します。

なお、ステップのrunで実行するコマンドは、ランナーの環境（OS）に依存します。そのため、Ubuntu環境で利用できるコマンドやディレクトリ構成を使ったり、アプリケーションをインストールすることも可能です。

ランナーのコード例

ランナーは、runs-onと記載したあと、ランナーの種類を指定することで記載できます。

runs-on: ubuntu-latest

ここではubuntu-latestを指定しているため、このジョブで定義された処理はUbuntu環境上で実行されます。

ランナーの種類

GitHub Actionsのランナーには、ホステッドランナーとセルフホステッドランナーの2種類があります。

ホステッドランナーはGitHubが公式に提供している実行環境で、ユーザが自分でサーバを用意する必要はありません。代表的なものに、Ubuntu環境のubuntu-latest、Windows環境のwindows-latest、macOS環境のmacos-latestがあります。特別な設定をしなくても、これらの環境を指定するだけでジョブを実行できます。

セルフホステッドランナーは、自分で管理しているサーバやクラウド環境上にランナーを用意し、その上でGitHub Actionsの処理を実行する方法です。この方法では、より細かい環境制御が可能で、専用ネットワークや独自構成など、特殊な要件にも対応できます。特に、大規模なプロジェクトやセキュリティ要件が厳しいシステムでは、外部のホステッド環境を利用できない場合があります。そうしたケースで、セルフホステッドランナーが有効です。

3.3 アクション（Action）

アクションとは

アクションとは、GitHub Actionsのステップで実行される、再利用可能な処理の定義です。ワークフローの中で行いたい処理を、あらかじめまとめて提供してくれているパーツのようなイメージです。自分で一から処理を書かなくても、必要な機能を簡単に利用できるという点が大きなメリットです。

アクションには、非常に多くの種類があります。例えば、以下のようなものが代表例としてよく利用されます。

actions/checkout - リポジトリ内のコードをチェックアウトするアクションです。
actions/setup-python - Pythonの実行環境をセットアップします。
docker/build-push-action - Dockerイメージをビルドし、レジストリにプッシュします。
aws-actions/configure-aws-credentials - GitHub ActionsからAWSにログインできるようにするためのアクションです。
slackapi/slack-github-action - Slackへ通知を送るためのアクションです。

このように、よく使う処理はすでにアクションとして提供されています。

アクションのコード例

ワークフロー内では、アクションをuses:という記述を使って呼び出します。uses:の右側に、利用したいアクション名を指定します。

- uses: docker/build-push-action@v6
  with:
    push: true
    tags: user/app:latest

@v6は、利用するアクションのバージョンを指定している部分です。バージョンを明示しておくことで、予期せぬアップデートによる動作変更を避け、ワークフローの再現性を保つことができます。

続いてwith:ブロックでは、アクションに渡すパラメータを設定します。この例ではpush: trueとすることで、Dockerイメージのプッシュを行うことを指定しており、tags: user/app:latestで付与するタグを指定しています。

アクションの種類

アクションの種類について説明します。

GitHub Actionsで利用できるアクションには、大きく分けて3つの種類があります。それぞれの特徴を理解しておくと、ワークフローを設計する際に、どのアクションを使うべきか判断しやすくなります。

まず1つ目は公式アクションです。これは、GitHubが公式に提供しているアクションになります。リポジトリのチェックアウト（actions/checkout）やプログラミング言語環境のセットアップ（actions/setup-pythonなど）といった、GitHub上でよく利用される基本的な処理が定義されています。信頼性が高く、メンテナンスも継続的に行われているため、特に初心者の方はまず公式アクションを利用することをおすすめします。

2つ目はコミュニティアクションです。こちらはGitHubのユーザや組織が公開しているアクションで、公式アクションでは提供されていない機能を補う際に役立ちます。例えば、AWSの認証処理（aws-actions/configure-aws-credentials）やDockerイメージのビルド（docker/build-push-action）など、各サービスの提供元が公開しているアクションもこのカテゴリに含まれます。 GitHub Marketplaceから検索して利用することができます。多くのニーズに応えられる反面、品質や更新状態は提供者によって異なるため、利用する際はスター数や最終更新日などを確認することが大切です。

そして3つ目はカスタムアクションです。自分で独自に作成するアクションのことです。プロジェクトや組織独自の処理を共通化したい場合に非常に有効で、Shell ScriptやDocker、JavaScriptなどを利用して作成できます。共通機能としてアクション化しておけば、複数のワークフローで再利用しやすくなり、メンテナンス性も向上します。

4. まとめ

この講座では、GitHub Actionsの概要について学びました。

GitHub ActionsはGitHub上でワークフローを実行・確認できる自動化ツール
ワークフローは自動実行される一連の処理で、ジョブとステップで構成される
トリガー（push、pull_request、schedule、workflow_dispatch）でワークフローの実行タイミングを指定
ランナーはジョブを実行する環境で、ホステッドランナーとセルフホステッドランナーがある
アクションは再利用可能な処理で、公式・コミュニティ・カスタムの3種類がある