GitHub Actions（以下、Actions）は、GitHubが提供する継続的インテグレーション（CI）および継続的デリバリー/デプロイ（CD）の機能を統合したサービスです。近年はソフトウェアの開発サイクルが高速化しており、テストやデプロイを自動化するCI/CDの導入が当たり前になりつつあります。特に、GitHubをメインのリポジトリとして運用しているチームや個人開発者にとって、GitHub Actionsはもっとも導入しやすいCI/CDツールの一つと言えるでしょう。
本記事では、GitHub Actionsとは何か、どのようにセットアップして、どんな機能があるのかといった基本的な部分から、代表的なユースケースやワークフロー（workflow）の書き方まで、初心者向けに分かりやすく解説していきます。まだ導入していない方や、名前は知っているけれど活用できていない方にとって、参考になる内容を目指しています。ぜひ最後までご覧いただき、開発プロセスの自動化・効率化を実現してみてください。
GitHub Actionsとは
GitHub Actionsは、GitHubが提供している公式のCI/CDプラットフォームです。これまでは、JenkinsやCircleCI、Travis CIなどの外部サービスを使って自動テスト・デプロイを行うケースが多く見られました。しかし、GitHub Actionsならリポジトリと同じプラットフォーム上で簡単にワークフローを作成でき、他のサービスを経由せずに自動化のフローを実装できます。
また、GitHub Actionsには「マネージドな実行環境」が用意されており、リポジトリと同じGitHub上で設定を完結できます。YAML形式の設定ファイル（.github/workflows 配下に配置）を記述するだけで、ビルドやテスト、デプロイなどを柔軟に自動化できる点が特長です。
GitHub Actionsのメリット
1. GitHubとの高い親和性
GitHub Actionsは、プッシュやプルリクエストなど、GitHub上で起きるイベントをトリガーにしてCI/CDを実行します。コードの変更やIssueの作成など、GitHub特有のイベントと連携しやすい点が非常に便利です。外部サービスでトリガーを設定するよりもシンプルかつ強力にワークフローを構築できます。
2. 豊富な公式・コミュニティ製アクション
GitHub Actionsには、Actionsのプラグインに相当する「アクション」が公式・コミュニティから多数公開されています。DockerイメージのビルドやAWS、GCP、Azureへのデプロイ、自動ラベル付け、Slack通知など、さまざまな処理を簡単に導入できます。自分で毎回スクラッチから書く必要がないので、設定の時間を大幅に削減可能です。
3. 無料枠の活用
GitHub Actionsはパブリックリポジトリなら無料で、プライベートリポジトリでも一定時間までは無料で利用できます（ただし利用プランによって上限の分数が異なります）。個人開発では無料枠を活用すれば、簡単にCI/CD環境を構築できるのが大きなメリットです。
4. GitHubネイティブのUI・ログ
GUIやログの閲覧もGitHub上で完結します。他のCIサービスを使っていると、リポジトリがGitHubにありながら、ログ閲覧や管理画面だけ別のサービスに飛ぶ必要があります。しかし、Actionsでは、すべて同一のUIで完結するため、開発者にとってとても扱いやすい仕様です。
GitHub Actionsの基本用語
GitHub Actionsの設定やドキュメントを読んでいると、特定の用語が出てくるので、まずはこれらを押さえておきましょう。
1. Workflow（ワークフロー）
ワークフローとは、アクションをどのような条件（イベント）で実行し、どんなステップを実行するのかを定義した、YAML形式の設定ファイルのことです。ワークフローはひとつのリポジトリに複数定義できます。基本的には、.github/workflows フォルダ内にYAMLファイルを配置し、そこに処理を書き込んでいきます。
2. Job（ジョブ）
ワークフローの中で実行する単位を「ジョブ」と呼びます。ジョブは複数定義することが可能で、並列あるいは順序を指定して実行できます。例えば「テストジョブ」「ビルドジョブ」「デプロイジョブ」といったように役割を分割しておくと、より構造化したワークフローを作ることができます。
3. Step（ステップ）
ジョブの中でさらに細かい処理を定義していく単位がステップです。ステップごとにコマンドを実行したり、アクションを呼び出したりすることが可能です。ステップはジョブ内で順番に実行されます。
4. Action（アクション）
公式・コミュニティ・個人が作成した、「特定の処理をパッケージ化したもの」がアクションです。ワークフロー定義ファイルの中で使うことで、例えばDockerビルドやAWSへのデプロイなどを一行で呼び出せます。自作することも可能です。
GitHub Actionsを始める手順
GitHub Actionsの基本的な流れは以下の通りです。初心者の方はまず、シンプルなワークフローを作りながら慣れていくと良いでしょう。
- GitHubリポジトリを作成する（または既存リポジトリを使う）
.github/workflowsフォルダを作成- ワークフロー定義ファイル（例：
ci.yml）を作成し、YAMLで記述 - リポジトリにプッシュする
- プッシュやプルリクエストなどのイベントでワークフローが自動的に実行される
次のコード例では、非常に簡単なワークフローの例を紹介します。プッシュやプルリクエストが行われたときに、Ubuntu環境を使って「Hello, GitHub Actions!」を表示するだけのジョブを作成しています。
name: Simple CI
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v3
- name: Say Hello
run: echo "Hello, GitHub Actions!"
これをリポジトリ直下の.github/workflows/ci.yml のように配置し、コミット&プッシュすると、以降はプッシュやプルリクエストが発生するたびに自動的にワークフローが走り、「Hello, GitHub Actions!」というログが表示されます。もちろん、このままではあまり実用的ではありませんが、最初の動作確認や学習用としては十分です。
ジョブの並列・依存関係の設定
ジョブを複数定義することで、テスト、ビルド、デプロイといったステージを分割できます。デフォルトではジョブは並列に実行されますが、特定のジョブに依存関係を持たせたい場合はneeds オプションを使います。下記の例では、build ジョブが成功したらdeploy ジョブを実行する流れを定義しています。
name: Multi Job CI
on:
push:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v3
- name: Build
run: echo "Building..."
deploy:
runs-on: ubuntu-latest
needs: [build]
steps:
- name: Check out repository
uses: actions/checkout@v3
- name: Deploy
run: echo "Deploying..."
このようにneedsを使うと、deployジョブはbuildジョブが成功（スキップや失敗でない）したときにのみ実行されます。ジョブをパイプラインのように直列化したい場合に便利です。
ワークフローのトリガーイベント
先ほどの例ではpushとpull_requestをトリガーに使いましたが、GitHub Actionsでは他にも多くのイベントをトリガーに設定できます。たとえば、以下のようなものがあります。
release: リリースが作成・公開・削除されたときに実行workflow_dispatch: 手動でワークフローを起動schedule: CRON式で定期実行（例：cron: '0 0 * * *'）issues: Issueがオープン/クローズされたときに実行label: ラベルが付与されたときに実行
これらのイベントを使い分けることで、プッシュやPRに限らず、さまざまなタイミングや条件で自動処理を走らせられます。例えば、毎日深夜に定期的なバッチ処理を走らせたり、リリース時に自動的にバージョン番号を更新したりといった応用が可能です。
アクションの使い方
ワークフロー内で特定の処理を行うとき、「run」にシェルコマンドを書いても良いのですが、より便利なのが「uses」で既存のアクションを呼び出す方法です。たとえば、GitHub公式が提供しているactions/checkoutやactions/setup-nodeなどが有名で、コミュニティ製も含めると数多くのアクションが公開されています。
actions/checkout
リポジトリのソースコードを取得するためのアクションです。CI環境でソースコードを扱う場合はほぼ必須と言えるほど多用されます。下記のように記述すると、現在のリポジトリが$GITHUB_WORKSPACEにクローンされます。
- name: Check out repository
uses: actions/checkout@v3
actions/setup-node
Node.jsのバージョンを指定してセットアップしてくれるアクションです。JavaScript/TypeScriptのプロジェクトをテスト・ビルドするときに便利です。以下のようにnode-versionを指定できます。
- name: Set up Node
uses: actions/setup-node@v3
with:
node-version: 16
aws-actions/amazon-ecr-login、aws-actions/amazon-ecs-deploy等
AWS CLIを利用して、ECRやECSに対してログイン・デプロイを行うためのアクションです。AWSを使った本番環境へのデプロイを自動化したい場合に役立ちます。
このように、まずはやりたい処理に合ったアクションを探してみましょう。公式ドキュメントの「GitHub Marketplace（Actions）」から検索できます。多くの場合はすでにコミュニティが便利なアクションを公開しています。
ワークフロー内でのシークレット管理
CI/CDの過程でAPIキーやパスワードなどの認証情報を使う場合は、GitHubリポジトリの設定でシークレットを登録し、ワークフロー内で参照する仕組みを使うと安全です。リポジトリの「Settings」→「Secrets and variables」→「Actions」から、環境変数を設定できます。シークレットに登録した値は、Actionsのログなどでマスクされるため、漏洩リスクを最小限に抑えられます。
- name: Deploy to Server
run: |
sshpass -p ${{ secrets.SERVER_PASSWORD }} ssh -o StrictHostKeyChecking=no user@server "deploy command"
上記のように${{ secrets.XXXX }} という形式で参照できます。なお、組織単位や環境単位でもシークレットを設定できるため、用途に応じてうまく使い分けましょう。
環境ごとのデプロイと環境変数
ステージング環境や本番環境など、複数の環境を使い分けてデプロイする場合は、environment 機能を活用すると便利です。GitHubリポジトリの「Settings」→「Environments」から、stagingやproductionなど環境を定義できます。そこに秘密情報（シークレット）を含めた設定を行い、ワークフロー内で環境ごとに切り替えることが可能です。
環境が増えてきた場合、ワークフロー設定が複雑になるかもしれません。そのときはジョブ内で条件分岐を入れたり、strategyを使って複数環境に対して同じ手順を繰り返す設定にしたりといった方法で管理を簡単にすることができます。
自動テストの実行例（Node.jsの場合）
実際のプロジェクトでは、プッシュやプルリクエストが行われるたびに自動テストを走らせるのがCIの基本です。ここではNode.js（npm）プロジェクトを例に、テストを実行するシンプルな例を紹介します。
name: Node.js Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Use Node.js 16
uses: actions/setup-node@v3
with:
node-version: 16
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
これだけでも十分ですが、npm ci を使ったり、キャッシュ機能で依存関係をキャッシュしたりすると、ビルド・テストが高速化できます。また、カバレッジレポートやLintチェックなど、追加したい処理はすべてステップで定義可能です。TypescriptやReactなど、フロントエンド・バックエンドを問わずNode.jsプロジェクトであれば、ワークフローの基本は似たような構造になります。
Dockerイメージのビルドとプッシュ
Dockerを使った開発では、CI環境でDockerイメージをビルドし、レジストリ（Docker HubやAWS ECRなど）にプッシュするパターンが一般的です。以下にDocker Hubを例としたイメージのビルド&プッシュのワークフロー例を示します。
name: Docker Build and Push
on:
push:
branches: [ "main" ]
jobs:
build-push:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Log in to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_PASSWORD }}
- name: Build and push Docker image
uses: docker/build-push-action@v3
with:
context: .
file: ./Dockerfile
push: true
tags: ${{ secrets.DOCKERHUB_USERNAME }}/my-app:latest
このワークフローでは、docker/login-actionでDocker Hubにログインし、docker/build-push-actionでビルドおよびプッシュを行います。ユーザー名とパスワードはシークレット管理しておきます。AWS ECRにプッシュしたい場合は、AWS CLIのログインアクションを使い、タグをECRのリポジトリURIに変更すればOKです。わざわざ他のCIサービスを使わず、同じGitHub Actionsで完結できるのは非常に便利です。
ワークフローのスケジューリング（cron）
Actionsにはscheduleトリガーが用意されており、CRON式を使って定期的にジョブを実行できます。深夜にバッチを回したり、週に一回レポートを生成したりするのに有用です。
name: Scheduled Job
on:
schedule:
- cron: '0 2 * * *' # 毎日午前2時に実行
jobs:
batch:
runs-on: ubuntu-latest
steps:
- name: Run batch process
run: echo "Running daily batch at 2 AM..."
CRONの書き方は一般的な形式と同じで、* * * * * の順に「分 時 日 月 曜日」を指定します。なお、Actionsのスケジュールは厳密に指定の分秒に実行されるわけではなく、若干のズレが生じることがある点に注意が必要です。
ワークフローのデバッグと実行ログ
ワークフローがうまく動かない、失敗してしまうという場合は、実行ログをチェックしましょう。GitHubのリポジトリ画面から「Actions」タブを開くと、実行されたワークフローの一覧が表示されます。失敗しているワークフローをクリックすると、ジョブごとに展開してステップ単位のログを確認できます。
また、ローカルで実験的にワークフローを動かしたい場合は、act などのツールを使うと便利です。ローカル環境でDockerコンテナを立ち上げて、ワークフローをシミュレートしてくれます。ただし完全に同じ環境ではないため、あくまで補助的に使うのが良いでしょう。
よくあるエラーと対処法
初心者の方がGitHub Actionsを使い始めると、YAMLのフォーマットエラーやアクションのバージョン指定ミス、シークレットの設定漏れなど、さまざまなトラブルが起こりがちです。ここでは、よくあるケースをいくつか紹介します。
1. YAMLのインデントや構文エラー
Actionsのワークフロー定義はYAMLファイルです。インデントのミスやコロンの付け忘れなどがあるとエラーになります。VSCodeなどのエディタを使い、YAMLのLintチェックを有効にしておくと対策しやすいです。
2. actions/checkout@v3 を忘れてソースが見つからない
ソースコードを操作するステップがあるにもかかわらず、actions/checkout@v3を呼び出していないためにソースコードが存在しないケースが多いです。初歩的な見落としなので、常に最初にチェックアウトステップを入れることを意識しておきましょう。
3. シークレットを設定し忘れている
デプロイ先の認証情報などが必要なのにシークレットを未登録で、その結果ワークフローが失敗するというケースも少なくありません。特に、他人のリポジトリをフォークして自分の環境で動かす際には、改めてシークレットを設定する必要があります。
4. イベントの指定を間違えている
onの指定で、pushをpushesなどと書き間違えて、全くワークフローが走らないこともあります。もしワークフローが一度も起動しない場合は、イベント指定が合っているかを確認しましょう。
プルリクエストの自動テストとステータスチェック
チーム開発の現場では、プルリクエストが立ち上がるたびに自動テストが走り、テストが通らない限りマージできないようにする仕組みを整えると安心です。GitHub ActionsとGitHubのBranch protection rulesを組み合わせると、プルリクエストのCIが失敗した場合にマージがブロックされるよう設定できます。
具体的には、以下のような流れです。
- ワークフローで
on: pull_requestを設定し、自動テストを実行 - GitHubリポジトリ設定の「Branches」→「Branch protection rules」で、ターゲットブランチ（例：
main）を選択 - 「Require status checks to pass before merging」を有効にして、先ほどのワークフロー名を指定
こうすることで、テストが通らない限りメインブランチにマージできなくなり、コード品質を保つことができます。チーム内でのレビューサイクルが活発になると同時に、テストの自動化により不具合を早期に発見しやすくなります。
マトリックスビルド（matrix）
GitHub Actionsではstrategy.matrixを使うことで、複数のOS、言語バージョンなどの組み合わせを一気にテストできます。例えば、Node.jsアプリをWindows、Linux、macOSで同時にテストしたり、Node.js 14/16/18の各バージョンでテストするなど、多様な環境での互換性チェックを自動化できます。
name: Node.js Matrix Test
on: [push, pull_request]
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
node: [14, 16, 18]
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node }}
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
これにより、3種類のOS × 3つのNodeバージョンの合計9パターンでテストを自動的に実行し、結果を個別に確認できます。プロダクション向けには特定のバージョンだけをサポートする場合もありますが、オープンソース開発などで幅広い環境への互換性を担保したい際には非常に有効です。
キャッシュの活用
同じ依存ライブラリを毎回インストールしていると、そのたびに時間がかかってしまいます。GitHub Actionsにはキャッシュ機能があり、依存関係（npmのnode_modulesやPythonのvenv、Rubyのbundleなど）を保存して、次回のワークフロー実行時に再利用できます。下記はNode.jsの例です。
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
上記のように、actions/cacheアクションでpathやkeyを設定すると、依存関係をキャッシュできます。hashFilesでpackage-lock.jsonを指定することで、ロックファイルが更新されたタイミングでキャッシュが無効化され、新しいライブラリをインストールし直します。大規模プロジェクトや依存が多いプロジェクトでは、これによってビルド・テスト時間を大幅に短縮できます。
ワークフローの再利用（リユーザブルワークフロー）
大規模プロジェクトでは、共通化したいステップやジョブが多数出てくることがあります。そんなときに役立つのが「リユーザブルワークフロー（Reusable workflows）」です。あるリポジトリ内で定義したワークフローを、別のリポジトリでも呼び出せます。これによって、複数のリポジトリが同じCI/CDパイプラインのロジックを共有・再利用できるようになります。
やり方は簡単で、まずは共有したいワークフローを定義し、workflow_callトリガーを設定します。呼び出す側のワークフローでは、uses: <owner>/<repo>/.github/workflows/<workflow-file>@<ref> といった形で記述することで、共通ワークフローを利用できます。チーム内で同じテンプレートを何度も書かずに使い回す際に便利です。
セキュリティ上の注意点
GitHub Actionsを使う上で、セキュリティには十分注意を払う必要があります。特に、以下のポイントを押さえておきましょう。
- Pull Requestでのシークレット暴露リスク：
ForkからのPull Requestによってワークフローが走る場合、外部からのコード実行を許してしまう可能性があります。Actionsの設定で「Pull Request時にシークレットへのアクセスを禁止する」などのオプションを適宜利用しましょう。 - サードパーティのアクションの信頼性：
コミュニティ製アクションの中には、悪意が潜んでいる可能性もゼロではありません。人気があり評判の良いアクションを選んだり、自分でコードを確認したりする習慣を持ちましょう。 - リポジトリの権限設定：
シークレットの権限やブランチ保護ルールを適切に設定しないと、悪意あるコミットでシークレット情報を盗まれるリスクがあります。特に本番環境用のキーやパスワードを扱う場合は慎重に運用してください。
他のCI/CDツールとの比較
GitHub Actions以外にも、多くのCI/CDプラットフォームがあります。Jenkins、CircleCI、Travis CI、GitLab CI、Azure Pipelinesなどが有名です。以下のようにそれぞれ特徴があります。
- Jenkins: オープンソースで拡張性が高いが、自前サーバーの構築・運用が必要。プラグインも多数。
- CircleCI: クラウド環境で手軽に使える。ビルド速度が速く、設定も比較的シンプル。
- GitLab CI: GitLabと連携がスムーズ。オンプレやクラウド両方で使える。
- Azure Pipelines: Microsoft Azureとの親和性が高く、Windows環境でも強みを発揮する。
GitHub ActionsはGitHubと深く統合されている点が最大の利点です。既にGitHubを使っているならば、追加コストや導入の手間を最小限に抑えてCI/CDの仕組みを導入できるというメリットが大きいです。一方で、大量のビルドを同時並行で走らせるようなユースケースではランナーの制限に注意したり、有償プランを検討する必要もあります。
まとめ：まずは小さな自動化から始めよう
GitHub Actionsは、GitHubユーザーにとって非常に導入しやすいCI/CDプラットフォームです。初心者の方はまずシンプルなワークフローを作り、プッシュやPRで自動テストを走らせるところから始めると良いでしょう。慣れてきたら、デプロイの自動化やバッチ処理の定期実行、さらにはマルチプラットフォーム対応のテストなど、少しずつ機能を拡張していくのがおすすめです。
特に個人開発や小規模チームでは、無料枠やコミュニティ製アクションを活用することで、最小の手間でパイプラインの自動化を行えます。結果として、手動で行っていたテストやデプロイの負荷が減り、開発スピードが向上します。ぜひ本記事を参考に、あなたのプロジェクトにもGitHub Actionsを取り入れてみてください。
GitHub Actionsは公式ドキュメントも分かりやすく、コミュニティから多くのTipsが共有されています。分からないことがあれば「Actions エラー内容」「Actions ジョブが動かない」などで検索したり、公式リファレンス（https://docs.github.com/actions）を確認するとよいでしょう。時間をかけて複雑な自動化を実装する価値は十分にあります。小さく始めて、大きく育てていきましょう！
コメント