GitHub Actionsとは使い方入門から料金・CI/CDまで解説

ソフトウェア開発の現場では、ソースコードを書く以外にも、ビルド、テスト、デプロイといった多くの付随的な作業が発生します。これらの作業を手動で行うと、時間がかかるだけでなく、ヒューマンエラーの原因にもなりかねません。このような開発ワークフローにおける定型的な作業を自動化し、開発者の生産性を劇的に向上させるツールが「GitHub Actions」です。

GitHub Actionsは、世界最大のソースコードホスティングサービスであるGitHubにネイティブに統合された、強力な自動化プラットフォームです。登場以来、多くの開発現場でCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインの構築ツールとして採用され、今やモダンな開発に欠かせない存在となりつつあります。

この記事では、GitHub Actionsとは何かという基本的な概念から、その中核をなすCI/CDの考え方、具体的な使い方、料金体系、そして利用する上での注意点まで、網羅的に解説します。これからGitHub Actionsを学びたいと考えている初心者の方から、さらに活用を深めたい中級者の方まで、幅広く役立つ情報を提供します。

1 GitHub Actionsとは
2 CI/CDとは
3 GitHub Actionsでできること
4 GitHub Actionsを導入するメリット
5 GitHub Actionsを構成する6つの主要要素
6 GitHub Actionsの料金体系
7 GitHub Actionsの基本的な使い方3ステップ
8 知っておくと便利なワークフローの基本構文
9 GitHub Actionsを利用する際の注意点

GitHub Actionsとは

GitHub Actionsとは、GitHubに組み込まれた、ソフトウェア開発のワークフローを自動化するためのプラットフォームです。リポジトリ内でのさまざまなイベント（例：コードのプッシュ、Pull Requestの作成、Issueの登録など）をトリガーとして、あらかじめ定義しておいた一連の処理を自動的に実行させることができます。

従来、このような自動化処理を実現するには、JenkinsやCircleCIといった外部のCI/CDツールを導入し、GitHubと連携させる設定が必要でした。しかし、GitHub ActionsはGitHubの機能として提供されているため、外部サービスを契約したり、複雑な連携設定を行ったりすることなく、GitHub上ですべての作業を完結させられるのが最大の特徴です。

GitHub Actionsで自動化できるタスクは多岐にわたります。

コードのビルドとテスト: 新しいコードがプッシュされるたびに、自動でビルドが通るか、テストがすべて成功するかをチェックします。これにより、バグの早期発見と品質の維持が可能になります。
アプリケーションのデプロイ: テストを通過したコードを、ステージング環境や本番環境のサーバーへ自動的にデプロイします。手動でのデプロイ作業をなくし、迅速かつ安全なリリースを実現します。
パッケージの公開: 作成したライブラリやツールを、npmやPyPIといったパッケージ管理リポジトリへ自動で公開します。
リポジトリの管理: 新しいIssueが作成された際に自動でラベルを付けたり、貢献者に対して感謝のメッセージを送ったりするなど、コミュニティ管理の手間を軽減します。
定期的なタスク実行: 毎日深夜に依存関係の脆弱性をスキャンしたり、週次でレポートを生成してSlackに通知したりといった、cronジョブのような定期実行も可能です。

これらの自動化処理は、「ワークフロー（Workflow）」と呼ばれるYAML形式のファイルで定義します。このファイルはソースコードと同様にリポジトリ内で管理されるため、誰がどのような変更を加えたのかを追跡しやすく、バージョン管理の恩恵を受けることができます（Infrastructure as Code）。

さらに、GitHub Actionsの強力な点として「Marketplace」の存在が挙げられます。Marketplaceでは、世界中の開発者や企業が作成した再利用可能な処理の部品（「アクション」と呼びます）が数多く公開されています。例えば、「AWSにデプロイする」「Slackに通知を送る」といった一般的なタスクは、これらの公開されているアクションを組み合わせるだけで、比較的簡単に実現できます。

まとめると、GitHub Actionsは単なるCI/CDツールにとどまらず、GitHubを中心とした開発活動全般を自動化し、効率化するための統合プラットフォームと言えるでしょう。手作業によるミスを減らし、開発者がより創造的なコーディング作業に集中できる環境を提供することで、ソフトウェア開発の生産性と品質を大きく向上させる力を持っています。

CI/CDとは

GitHub Actionsを理解する上で欠かせないのが、「CI/CD」という概念です。これは「継続的インテグレーション（Continuous Integration）」と「継続的デリバリー（Continuous Delivery）」または「継続的デプロイメント（Continuous Deployment）」を組み合わせた言葉で、現代の俊敏なソフトウェア開発（アジャイル開発など）を支える重要なプラクティスです。

CI（継続的インテグレーション）
CIは、開発者が書いたコードを、頻繁に（理想的には1日に何度も）メインの共有リポジトリにマージする開発手法です。そして、コードがマージされるたびに、ビルドとテストを自動的に実行するのが重要なポイントです。

昔ながらの開発では、複数の開発者がそれぞれのローカル環境で長期間開発を続け、リリースの直前になってから全員のコードを結合（インテグレーション）することがよくありました。この方法では、いざ結合しようとした際に大量のコード競合（コンフリクト）や、予期せぬバグが発生し、その解決に膨大な時間と労力がかかるという問題がありました。「インテグレーション地獄」とも呼ばれるこの問題を解決するのがCIです。

CIを導入することで、以下のようなメリットが生まれます。

バグの早期発見: 変更範囲が小さいうちにテストが実行されるため、問題が発生しても原因の特定が容易です。
開発効率の向上: 手動でのビルドやテストの手間が省け、開発者はコーディングに集中できます。
品質の維持: 常にテストが通った状態が保たれるため、ソフトウェアの品質が安定します。
チームコラボレーションの促進: 開発者全員が常に最新のコードベースで作業するため、認識の齟齬が減り、円滑な共同作業が可能になります。

CD（継続的デリバリー / 継続的デプロイメント）
CDは、CIのプラクティスをさらに推し進め、リリースプロセスを自動化する手法です。CDには「継続的デリバリー」と「継続的デプロイメント」という、似て非なる2つの概念があります。

継続的デリバリー（Continuous Delivery）:
CIによってビルドとテストが完了したコードを、いつでも本番環境にリリースできる状態に保っておくことを指します。ステージング環境など、本番に近い環境へのデプロイまでは自動化されますが、最終的な本番環境へのリリースは、ビジネス判断に基づき、ボタン一つで実行できるような手動のステップが介在します。これにより、リリースのタイミングを柔軟にコントロールできます。
継続的デプロイメント（Continuous Deployment）:
継続的デリバリーをさらに一歩進め、CIのすべてのテストを通過したコードを、人手を介さずに自動的に本番環境へリリース（デプロイ）する手法です。変更がメインブランチにマージされた瞬間から、数分後にはユーザーがその機能を使えるようになります。これにより、ユーザーへの価値提供を最速で行うことができますが、高度なテスト自動化と監視体制が不可欠です。

どちらの手法を採用するにせよ、CDの目的は、リリースプロセスから手作業を排除し、迅速かつ信頼性の高いリリースを可能にすることです。

GitHub ActionsとCI/CDの関係

では、GitHub ActionsとCI/CDはどのような関係にあるのでしょうか。結論から言うと、GitHub Actionsは、このCI/CDという概念を実現するための、具体的かつ強力なツールの一つです。

開発者がGitHubのリポジトリにコードをプッシュしたり、Pull Requestを作成したりすると、それをトリガー（Event）としてGitHub Actionsのワークフローが起動します。

CIの実現: ワークフロー内で、ソースコードのチェックアウト、依存関係のインストール、コードのビルド、ユニットテストや結合テストの実行といった一連の処理を自動化できます。テスト結果が失敗すれば、Pull Request上で即座に開発者にフィードバックされ、マージを防ぐことも可能です。これが継続的インテグレーションの実践です。
CDの実現: CIのジョブがすべて成功したら、それに続くジョブとして、ビルドされたアプリケーションをパッケージ化し、AWS、Google Cloud、Microsoft Azureといったクラウドサービスのステージング環境や本番環境へ自動でデプロイする処理を実行できます。これが継続的デリバリー/デプロイメントの実践です。

つまり、CI/CDは「何をすべきか」という開発のベストプラクティスや思想であり、GitHub Actionsは「それをどうやって実現するか」という具体的な手段・プラットフォームに相当します。GitHubという開発の中心地で、ソースコード管理とCI/CDパイプラインの構築・実行がシームレスに連携することで、開発チームはより迅速で品質の高いソフトウェア開発サイクルを実現できるようになるのです。

GitHub Actionsでできること

CI/CD（継続的インテグレーション/継続的デリバリー）の自動化、ソフトウェアのパッケージ作成と公開、IssueやPull Requestへの自動応答、定期的なタスクの実行

GitHub Actionsは非常に柔軟なツールであり、その用途はCI/CDの実現だけにとどまりません。ここでは、GitHub Actionsで実現できる代表的な4つの活用例を、具体的なシナリオとともに詳しく解説します。

CI/CD（継続的インテグレーション/継続的デリバリー）の自動化

これはGitHub Actionsの最も代表的で強力なユースケースです。開発ワークフローの中核となるビルド、テスト、デプロイのプロセスを完全に自動化できます。

具体的なシナリオ:
あるWebアプリケーション開発チームを想定してみましょう。

コードのプッシュとPull Requestの作成: 開発者Aが、新機能を追加するためのコードを書き、「feature/new-login-function」のようなブランチにプッシュし、mainブランチへのマージをリクエストするPull Requestを作成します。
CIワークフローの自動実行: Pull Requestが作成されたことをトリガーに、GitHub ActionsのCIワークフローが自動的に起動します。
ビルドとテスト: ワークフローは、以下のステップを順番に実行します。
- リポジトリのソースコードをチェックアウトする。
- Node.jsなどの実行環境をセットアップする。
- npm install を実行し、必要なライブラリ（依存関係）をインストールする。
- npm run build を実行し、アプリケーションが正常にビルドできるかを確認する。
- npm test を実行し、あらかじめ用意されたユニットテストや結合テストをすべて実行する。
結果のフィードバック: テストがすべて成功すれば、Pull Requestのステータスチェックが緑色のチェックマークになります。これにより、レビュー担当者はこのコードが最低限の品質基準を満たしていることを一目で確認できます。もしテストが失敗すれば、赤色のバツ印が表示され、マージがブロックされます。開発者Aは、ログを確認して問題を修正し、再度プッシュします。
CDワークフローの実行: レビューを経てPull Requestがmainブランチにマージされると、今度はCD（デプロイ）用のワークフローがトリガーされます。
自動デプロイ: ワークフローは、テスト済みのアプリケーションをDockerイメージとしてビルドし、ステージング環境のサーバーへ自動的にデプロイします。ステージング環境で最終的な動作確認が行われた後、手動の承認を経て、本番環境へも同様にデプロイされます。

このように、CI/CDパイプラインを構築することで、コードの品質を常に高いレベルで維持しつつ、リリースにかかる時間と手間を大幅に削減できます。

ソフトウェアのパッケージ作成と公開

自身で開発したライブラリやツールを、他の開発者も使えるように公開する際、そのパッケージ作成と公開プロセスもGitHub Actionsで自動化できます。

具体的なシナリオ:
あるPython製の便利なライブラリを開発し、PyPI（Python Package Index）で公開する場合を考えます。

バージョニングとタグ付け: ライブラリのバージョンを1.0.0に更新し、そのコミットに対してv1.0.0というGitタグを付けます。
リリーストリガー: vから始まるタグがプッシュされたことをトリガーに、リリース用のワークフローが起動するように設定しておきます。
パッケージ作成と公開: ワークフローは以下の処理を自動で行います。
- ソースコードをチェックアウトする。
- Pythonの環境をセットアップする。
- ビルドに必要なツール（build, twineなど）をインストールする。
- ソース配布物（sdist）とホイール（wheel）形式のパッケージを作成する。
- あらかじめGitHubのSecretsに保存しておいたPyPIのAPIトークンを使い、作成したパッケージをPyPIにアップロード（公開）する。

この自動化により、手作業によるバージョンの付け間違いや、アップロード漏れといったヒューマンエラーを防ぎ、誰がリリース作業を行っても常に同じ手順で確実に行われることが保証されます。npm（JavaScript）、RubyGems（Ruby）、Docker Hub（Dockerイメージ）など、他の多くのパッケージリポジトリに対しても同様の自動化が可能です。

IssueやPull Requestへの自動応答

GitHub Actionsは、コーディングだけでなく、リポジトリの管理やコミュニケーションといった、プロジェクト運営に関わるタスクも自動化できます。

具体的なシナリオ:
大規模なオープンソースプロジェクトを運営している場面を想像してください。

ラベリングの自動化: ユーザーから「バグ報告」のテンプレートを使って新しいIssueが作成された場合、GitHub Actionsがそれを検知し、自動的に「bug」というラベルを付けます。機能追加の要望であれば「enhancement」ラベルを付けます。これにより、メンテナーはIssueの種類を一目で把握し、対応の優先順位付けが容易になります。
貢献者へのウェルカムメッセージ: プロジェクトに初めてPull Requestを送ってくれた貢献者に対して、自動で「ご貢献ありがとうございます！コントリビューションガイドラインをご確認ください」といった感謝のメッセージと関連リンクをコメントします。これにより、コミュニティへの参加を促し、貢献者体験を向上させることができます。
古いIssueの整理: 90日間以上更新のないIssueに対して、「このIssueは長期間更新がありません。まだ問題が解決していない場合は、コメントでお知らせください」というコメントを自動で投稿し、さらに14日経っても反応がなければ自動でクローズします。これにより、対応が不要になったIssueを整理し、プロジェクトを健全な状態に保てます。

これらの自動化は、actions/first-interactionやactions/staleといった既存のアクションを利用することで簡単に実現でき、プロジェクト管理者の負担を大幅に軽減します。

定期的なタスクの実行

特定のイベント発生時だけでなく、cronのように決まったスケジュールでタスクを実行することも可能です。

具体的なシナリオ:

依存関係の脆弱性スキャン: 毎日深夜0時にワークフローをスケジュール実行し、npm auditやpip-auditのようなコマンドを使って、プロジェクトが利用しているライブラリに新たな脆弱性が発見されていないかをチェックします。脆弱性が見つかった場合は、Issueを自動で作成したり、セキュリティ担当者にSlackで通知したりします。
Webサイトの死活監視・リンクチェック: 自社で運営するWebサイトのトップページが正常に表示されるかを5分おきにチェックしたり、サイト内の全ページのリンク切れを毎晩チェックしたりするワークフローを作成します。問題があれば、即座に担当者へアラートを飛ばします。
データの定期バックアップ: データベースの内容を定期的にダンプし、クラウドストレージにバックアップとして保存する、といったインフラ運用タスクも自動化できます。

このように、手動では忘れがちな、しかし重要な定型業務をGitHub Actionsに任せることで、システムの安定性やセキュリティを継続的に維持することができます。

GitHub Actionsを導入するメリット

GitHub上ですべての作業が完結する、Marketplaceの豊富なアクションを再利用できる、柔軟なカスタマイズが可能、複数のOS（Windows, macOS, Linux）で実行できる、無料で始められる利用枠がある

GitHub Actionsが多くの開発者に支持されるのには、明確な理由があります。ここでは、GitHub Actionsを導入することで得られる5つの大きなメリットについて、それぞれ詳しく解説します。

GitHub上ですべての作業が完結する

最大のメリットは、開発に関連するほぼすべての作業がGitHubという単一のプラットフォーム上で完結する点です。

従来の開発フローでは、以下のように複数のツールを使い分けるのが一般的でした。

ソースコード管理: GitHub
CI/CD: Jenkins, CircleCI, Travis CIなど
プロジェクト管理: Jira, Redmineなど
コミュニケーション: Slack, Microsoft Teamsなど

これらのツールはそれぞれ高機能ですが、連携させるためには個別の設定やアカウント管理が必要となり、ツール間を行き来する「コンテキストスイッチ」が発生します。このコンテキストスイッチは、開発者の集中力を削ぎ、生産性を低下させる要因となり得ます。

GitHub Actionsを導入すると、ソースコード管理（Git）、コードレビュー（Pull Request）、プロジェクト管理（Issues, Projects）、そしてCI/CD（Actions）が、すべて使い慣れたGitHubのインターフェース内でシームレスに連携します。Pull Requestの画面を見れば、関連するIssue、コードの差分、そしてCI/CDの実行結果までが一目瞭然です。これにより、開発者は複数のツールを渡り歩く必要がなくなり、本来のタスクに集中できます。また、管理面でも、ツールの契約やアカウント管理を一元化できるため、運用コストの削減にも繋がります。

Marketplaceの豊富なアクションを再利用できる

GitHub Actionsでは、ワークフローをゼロからすべて自分で記述する必要はありません。「GitHub Marketplace」というエコシステムが存在し、ここには世界中の開発者やAWS、Google、Microsoftといった企業が作成・公開した数万もの「アクション」（ワークフローの再利用可能な部品）が登録されています。

例えば、以下のような一般的なタスクは、Marketplaceで公開されているアクションを見つけてきて、数行のYAMLを記述するだけで簡単に実現できます。

actions/checkout: リポジトリのコードをランナーにダウンロードする（ほぼ必須のアクション）。
actions/setup-node: 特定のバージョンのNode.js環境をセットアップする。
aws-actions/configure-aws-credentials: AWSの認証情報を設定する。
google-github-actions/auth: Google Cloudの認証を行う。
docker/build-push-action: Dockerイメージをビルドしてレジストリにプッシュする。
slackapi/slack-github-action: Slackに通知を送る。

これにより、開発者は「車輪の再発明」を避け、複雑な処理を自前で実装する手間を省くことができます。実績のあるアクションを組み合わせることで、迅速かつ堅牢なワークフローを構築できるのは、GitHub Actionsの非常に強力なメリットです。もちろん、特定のプロジェクトに特化した独自のアクションを作成し、プライベートに利用したり、Marketplaceに公開してコミュニティに貢献したりすることも可能です。

柔軟なカスタマイズが可能

既存のアクションを組み合わせる手軽さに加え、GitHub Actionsは非常に高いカスタマイズ性も備えています。ワークフローはYAML形式のテキストファイルで定義するため、ソースコードと同様にGitでバージョン管理ができます。これにより、「いつ、誰が、なぜワークフローを変更したのか」という履歴が明確に残り、チームでの共同編集やレビューも容易になります。

また、既存のアクションでは対応できない独自の処理が必要な場合でも、runキーワードを使えば、LinuxのシェルスクリプトやWindowsのPowerShellコマンドを直接実行できます。これにより、特定のビルドツールを呼び出したり、独自のデプロイスクリプトを実行したりと、事実上ほぼすべてのタスクを自動化できます。

さらに、ifによる条件分岐、matrixストラテジーによる複数環境での並列実行、needsによるジョブの依存関係定義など、高度な制御構文も用意されています。これらの機能を組み合わせることで、シンプルなCIから、何段階もの承認プロセスを含む複雑なエンタープライズ級のリリースパイプラインまで、あらゆる要件に柔軟に対応できます。

複数のOS（Windows, macOS, Linux）で実行できる

現代のアプリケーションは、Web、デスクトップ、モバイルなど、様々なプラットフォームで動作することが求められます。GitHub Actionsは、このようなクロスプラットフォーム開発を強力にサポートします。

GitHubが提供する実行環境（GitHub-hosted runner）には、Ubuntu（Linux）、Windows Server、macOSの最新バージョンが標準で用意されています。ワークフローの定義ファイルで runs-on: macos-latest のように一行書き加えるだけで、macOS環境でジョブを実行できます。

これは、以下のような場合に特に威力を発揮します。

iOSアプリの開発: ビルドやテストにmacOS環境が必須となるiOSアプリのCI/CDパイプラインを構築できます。
Windowsネイティブアプリ開発: Visual Studioを使ったビルドなどを自動化できます。
クロスプラットフォームライブラリのテスト: matrixストラテジーと組み合わせることで、Linux, Windows, macOSの3つのOS上で、かつ複数の言語バージョン（例: Python 3.9, 3.10, 3.11）でテストを同時に実行する、といった複雑なテストシナリオを、ごくわずかな記述で実現できます。これにより、ライブラリが様々な環境で正しく動作することを効率的に保証できます。

無料で始められる利用枠がある

高機能なCI/CDツールは高価なイメージがあるかもしれませんが、GitHub Actionsは非常に導入しやすい料金体系になっています。特に、パブリックリポジトリ（オープンソースプロジェクト）であれば、GitHub-hosted runnerの利用は完全に無料です。

プライベートリポジトリであっても、アカウントの種類ごとに十分な無料利用枠が提供されています。例えば、個人向けの無料アカウント（GitHub Free）でも、月に2,000分の実行時間と500MBのストレージが利用できます。

この無料枠は、個人の学習や小規模なアプリケーション開発であれば十分に収まる範囲です。つまり、追加費用を一切かけることなく、本格的なCI/CDをすぐにでも始められるのです。この導入ハードルの低さは、特に個人開発者、スタートアップ、学習者にとって大きな魅力と言えるでしょう。もし無料枠を超える利用が必要になった場合でも、使った分だけ支払う従量課金制でスケールさせることが可能です。

GitHub Actionsを構成する6つの主要要素

Workflow（ワークフロー）、Event（イベント）、Job（ジョブ）、Step（ステップ）、Action（アクション）、Runner（ランナー）

GitHub Actionsのワークフローを理解し、自由にカスタマイズするためには、その中核をなす6つの構成要素を知ることが不可欠です。これらの要素がどのように連携して自動化プロセスを実現するのか、その関係性を把握しましょう。

① Workflow（ワークフロー）

Workflow（ワークフロー）は、GitHub Actionsにおける自動化プロセス全体を定義する、最も大きな概念です。リポジトリの.github/workflows/という特定のディレクトリに配置されたYAMLファイル一つひとつが、一つのワークフローに対応します。

このYAMLファイルには、「いつ（When）」「どの環境で（Where）」「何を（What）」実行するかという、自動化の全体設計図が記述されています。例えば、「mainブランチにコードがプッシュされたら（いつ）、Ubuntuの最新環境で（どの環境で）、ビルドとテストを実行する（何を）」といった内容を定義します。一つのリポジトリには、CI用、リリース用、定期実行用など、複数のワークフローファイルを持つことができます。

② Event（イベント）

Event（イベント）は、定義したワークフローを起動する「きっかけ」や「トリガー」となる、リポジトリ上での特定のアクティビティを指します。ワークフローファイルのonキーで指定します。

代表的なイベントには以下のようなものがあります。

push: 特定のブランチやタグにコードがプッシュされたとき。
pull_request: Pull Requestが作成、更新、クローズされたとき。
schedule: cron構文を使って定義した定期的なスケジュール（例: 毎日深夜3時）。
workflow_dispatch: GitHubのUIから手動でワークフローを実行するとき。
issues: Issueが作成、編集、ラベル付けされたとき。

これらのイベントに対して、さらに「mainブランチへのプッシュのみ」や「.jsファイルが変更されたときのみ」といった詳細なフィルターを設定することも可能です。イベントは、自動化プロセスの「開始スイッチ」として機能する重要な要素です。

③ Job（ジョブ）

Job（ジョブ）は、ワークフロー内で実行される一連のステップをまとめた単位です。一つのワークフローは、一つまたは複数のジョブで構成されます。

各ジョブは、デフォルトでは互いに独立しており、並列で実行されます。これにより、例えば「フロントエンドのテスト」と「バックエンドのテスト」を同時に実行して、全体の実行時間を短縮することができます。

一方で、needsキーを使ってジョブ間の依存関係を定義することも可能です。例えば、「deployジョブは、buildジョブとtestジョブの両方が成功した場合にのみ実行する」といった順序制御ができます。各ジョブは、後述するランナー（仮想マシン）の新しいインスタンス上で実行されるため、ジョブ間でのファイル共有はデフォルトでは行われません（共有するにはArtifacts機能を使います）。

④ Step（ステップ）

Step（ステップ）は、ジョブを構成する個々のタスクであり、処理の最小実行単位です。ジョブ内では、ステップは上から下に順番に実行されます。

ステップでは、主に以下の2種類のタスクを実行できます。

コマンドの実行 (run): runキーを使って、シェルコマンドやスクリプトを直接実行します。例えば run: npm install のように記述し、依存関係をインストールしたり、テストスクリプトを実行したりします。
アクションの利用 (uses): usesキーを使って、後述する再利用可能な「アクション」を呼び出します。例えば uses: actions/checkout@v4 のように記述し、リポジトリのコードをチェックアウトします。

ジョブが「タスクの目標（例: アプリケーションをテストする）」だとすれば、ステップはその目標を達成するための「具体的な手順（例: 1. コードをチェックアウト、2. 依存関係をインストール、3. テストを実行）」に相当します。

⑤ Action（アクション）

Action（アクション）は、ワークフローを構築するための再利用可能な部品（ビルディングブロック）です。複雑なタスクや定型的な処理をカプセル化したもので、ワークフローのYAMLファイルを簡潔で読みやすく保つ役割を果たします。

GitHub Marketplaceで公開されているサードパーティ製のアクションを利用することも、自分でカスタムアクションを作成することもできます。アクションは、JavaScriptで作成したり、Dockerコンテナとしてパッケージ化したり、あるいは単純なシェルスクリプトの集まりとして定義することも可能です。

アクションは、ワークフローを組み立てるための「レゴブロック」に例えることができます。actions/setup-node（Node.js環境のセットアップ）やdocker/login-action（Docker Hubへのログイン）といった便利なブロックを組み合わせることで、効率的に目的のパイプラインを構築できます。

⑥ Runner（ランナー）

Runner（ランナー）は、ワークフローのジョブを実際に実行するサーバー（仮想マシン）です。ジョブがトリガーされると、GitHub Actionsはランナーをプロビジョニングし、その上でジョブ内のステップを実行します。

ランナーには大きく分けて2種類あります。

GitHub-hosted runner:
GitHubが管理・提供するランナーです。Linux (Ubuntu), Windows, macOSの各OSが利用可能で、開発に必要な一般的なツールがあらかじめインストールされています。ユーザーはサーバーの管理を気にする必要がなく、手軽に利用を開始できます。ただし、スペックは固定で、カスタマイズはできません。
Self-hosted runner:
ユーザー自身が管理する物理サーバー、仮想マシン、またはクラウドインスタンス（AWS EC2など）をGitHub Actionsのランナーとして登録するものです。特定のハードウェアやソフトウェアが必要な場合、VPC内のリソースにアクセスしたい場合、またはGitHub-hosted runnerよりも高いスペックが必要な場合などに利用します。実行時間に対する課金が発生しないため、利用頻度が高い場合はコスト削減に繋がることもあります。

これら6つの要素の関係をまとめると、「Event」をきっかけに「Workflow」が起動し、その中の「Job(s)」が指定された「Runner」上で実行されます。各ジョブは一連の「Step(s)」で構成され、ステップではコマンドを実行したり、再利用可能な「Action」を呼び出したりする、という流れになります。

GitHub Actionsの料金体系

GitHub Actionsは無料で始められる強力なツールですが、プライベートリポジトリでの利用には上限があり、それを超えると料金が発生します。意図しない課金を避けるためにも、料金体系を正しく理解しておくことが重要です。

料金は主に、「実行時間（分単位）」と、ワークフローの成果物（Artifacts）やキャッシュを保存するための「ストレージ（GB単位）」という2つの要素で決まります。料金プラン（Free, Pro, Team, Enterprise Cloud）によって、無料枠の量や超過分の単価が異なります。

項目	GitHub Free	GitHub Pro	GitHub Team	GitHub Enterprise
実行時間 (プライベートリポジトリ)	2,000分/月	3,000分/月	3,000分/月	50,000分/月
ストレージ (プライベートリポジトリ)	500MB	1GB	2GB	50GB
パブリックリポジトリ	無料	無料	無料	無料

参照：GitHub Docs “About billing for GitHub Actions”

パブリックリポジトリの場合

まず最も重要な点として、パブリックリポジトリ（オープンソースプロジェクト）でのGitHub Actionsの利用は、GitHub-hosted runnerの実行時間もストレージも、基本的にすべて無料です。これは、GitHubがオープンソースコミュニティを強力に支援していることの表れであり、多くのOSSプロジェクトがGitHub ActionsをCI/CD基盤として採用している大きな理由です。

ただし、暗号通貨のマイニングなど、利用規約で禁止されている用途での使用は認められていません。常識の範囲内での利用が前提となります。

プライベートリポジトリの場合

プライベートリポジトリでの利用は、契約しているGitHubのプランに応じて毎月一定の無料枠が付与されます。この無料枠を超過した分については、従量課金制で料金が発生します。

実行時間（Minutes）の超過料金:
無料枠を超えた実行時間は、使用したランナーのOSによって異なる単価で課金されます。これは、各OSを動作させるための基盤となるインフラのコストが異なるためです。料金計算には「乗数（Multiplier）」という考え方が用いられます。Linuxの実行時間を基準（1x）として、Windowsは2倍（2x）、macOSは10倍（10x）の速さで無料枠の分を消費し、超過料金の単価も高くなります。

OS (GitHub-hosted runner)	1分あたりの料金 (USD)	乗数
Linux	$0.008	1x
Windows	$0.016	2x
macOS	$0.080	10x
macOS (Large runner, M1)	$0.080	10x
Linux (Larger runner – 4 vCPU)	$0.016	2x
Windows (Larger runner – 4 vCPU)	$0.032	4x

参照：GitHub Docs “About billing for GitHub Actions”
※上記料金は本記事執筆時点のものであり、最新の情報は公式サイトでご確認ください。

例えば、無料枠を使い切った後にWindowsランナーで100分ジョブを実行した場合、100分 * 2（乗数） * $0.008 = $1.6 が課金される計算になります。macOSでのビルドは高コストになりがちなので、特に注意が必要です。

ストレージ（Storage）の超過料金:
ワークフローの成果物（Artifacts）やキャッシュの保存に使用するストレージも、プランごとの無料枠を超えると課金対象となります。超過分は、1GBあたり月額$0.0025程度で課金されます。

課金管理:
意図しない課金を防ぐために、GitHubには「Spending limit（利用上限）」機能があります。アカウントの支払い設定ページで、この上限を$0に設定しておくことを強くお勧めします。これにより、無料枠を使い切った時点でワークフローの実行が自動的に停止し、追加料金が発生するのを確実に防ぐことができます。

無料利用枠でできること

「月に2,000分」と言われても、どの程度の作業量なのかイメージしにくいかもしれません。仮に、あなたのプロジェクトのCIワークフローが1回の実行に平均2分かかるとします。この場合、2,000分 ÷ 2分/回 = 1,000回、つまり月に1,000回までワークフローを無料で実行できる計算になります。

これは、1日に約33回に相当し、個人開発や数人規模の小規模なチームであれば、無料枠の範囲内で十分にGitHub Actionsの恩恵を受けることが可能です。コードをプッシュするたびにテストを回す、といった基本的なCI/CDは問題なく運用できるでしょう。

ただし、ビルドに時間がかかる大規模なプロジェクトや、macOSランナーを多用するiOSアプリ開発、あるいは非常に頻繁にコードが更新されるプロジェクトの場合は、無料枠をすぐに使い切ってしまう可能性があります。その際は、有料プランへのアップグレードや、コスト効率の良いSelf-hosted runnerの導入を検討することになります。

GitHub Actionsの基本的な使い方3ステップ

ワークフローを新規作成する、ワークフローファイルを編集して保存する、実行結果を確認する

ここからは、実際にGitHub Actionsを使い始めるための基本的な手順を3つのステップに分けて解説します。専門知識がなくても、テンプレートを使えば驚くほど簡単に最初の自動化を体験できます。

① ワークフローを新規作成する

まず、GitHub Actionsを設定したいリポジトリのページを開き、上部にあるタブから「Actions」をクリックします。

初めてActionsタブを開くと、GitHubがリポジトリ内のコードを分析し、プロジェクトの言語やフレームワークに合わせたワークフローのテンプレート（Starter workflows）を提案してくれます。例えば、Node.jsプロジェクトであればNode.js用のCIテンプレートが、PythonプロジェクトであればPython用のテンプレートが推奨されます。

ここでは、最もシンプルなテンプレートから始めてみましょう。「Simple workflow」の下にある「Configure」ボタンをクリックします。もし適切なテンプレートが見つからない場合は、「set up a workflow yourself」のリンクをクリックしても構いません。

ボタンをクリックすると、ワークフローファイルを編集するためのWebエディタ画面に遷移します。リポジトリ内に.github/workflows/というディレクトリが自動的に作成され、その中にmain.yml（またはblank.yml）という名前のファイルが新規作成されます。

② ワークフローファイルを編集して保存する

エディタ画面には、以下のようなシンプルなワークフローの雛形がすでに記述されています。

# ワークフローの名前
name: CI

# ワークフローが実行されるトリガーを指定
on:
  # mainブランチへのpushイベント
  push:
    branches: [ "main" ]
  # mainブランチへのpull_requestイベント
  pull_request:
    branches: [ "main" ]

  # 手動でこのワークフローを実行できるようにする
  workflow_dispatch:

# 実行するジョブを定義
jobs:
  # "build"というIDのジョブ
  build:
    # ジョブを実行する環境（ランナー）を指定
    runs-on: ubuntu-latest

    # ジョブ内で実行される一連のステップ
    steps:
      # usesキーワードで、公開されているアクションを利用する
      # actions/checkout@v3は、リポジトリのコードをランナーにチェックアウトするアクション
      - uses: actions/checkout@v4

      # runキーワードで、シェルコマンドを直接実行する
      - name: Run a one-line script
        run: echo Hello, world!

      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

このYAMLファイルが何をしているかを簡単に解説します。

name: CI: このワークフローの名前を「CI」と定義しています。
on: ...: このワークフローは、「mainブランチへのpush」または「mainブランチへのpull_request」、そして「手動実行（workflow_dispatch）」のいずれかが発生したときにトリガーされます。
jobs: build: ...: 「build」という名前のジョブを一つ定義しています。
runs-on: ubuntu-latest: このジョブは、最新のUbuntu環境で実行されます。
steps: ...: 実行する具体的な手順です。
1. actions/checkout@v4 を使って、リポジトリのコードを仮想環境上にコピーします。
2. echo Hello, world! というコマンドを実行します。
3. 複数行のechoコマンドを実行します。

この時点では、特にファイルを編集する必要はありません。内容を確認したら、画面右上の「Commit changes…」ボタンをクリックします。コミットメッセージ（例: “Create main.yml”）を入力し、「Commit directly to the main branch」を選択した状態で「Commit changes」をクリックして、ファイルをリポジトリに保存します。

③ 実行結果を確認する

ワークフローファイルをリポジトリのmainブランチにコミット（プッシュ）したことで、on: push: branches: [ "main" ] というトリガー条件が満たされました。これにより、定義したワークフローが自動的に実行されます。

実行結果を確認するには、再度リポジトリの「Actions」タブをクリックします。左側のサイドバーに、先ほど作成したワークフロー（”CI”）が表示されているはずです。それをクリックすると、中央の画面にワークフローの実行履歴が一覧で表示されます。

最新の実行履歴（コミットメッセージ “Create main.yml” に対応するもの）をクリックすると、実行の詳細画面に遷移します。左側にジョブの一覧（この場合は “build” のみ）、右側にステップごとの実行ログが表示されます。

“build” ジョブをクリックすると、各ステップが展開されます。

「Run a one-line script」のステップをクリックすると、その中で実行された echo Hello, world! の結果として、Hello, world! と出力されているのが確認できます。
同様に、「Run a multi-line script」の結果も確認できます。

各ステップの横には、処理にかかった時間も表示されます。ワークフローが成功すると、実行履歴の横に緑色のチェックマークが付きます。もし何らかのエラーで失敗した場合は、赤色のバツ印が表示され、ログを確認することでエラーの原因を特定できます。このログは、ワークフローが期待通りに動かない場合のデバッグに非常に重要です。

以上が、GitHub Actionsを体験する最も基本的な流れです。この3ステップだけで、あなたはもう立派な自動化の第一歩を踏み出しました。

知っておくと便利なワークフローの基本構文

on：ワークフローを開始するタイミングを指定する、jobs.<job_id>.runs-on：実行環境を指定する、jobs.<job_id>.steps：実行する一連のタスクを定義する

基本的な使い方がわかったら、次はワークフローを自分の目的に合わせてカスタマイズしていきましょう。ここでは、実践的なワークフローを作成する上で特によく使われる、便利なYAML構文をいくつか紹介します。

on：ワークフローを開始するタイミングを指定する

onキーは、ワークフローをいつ実行するかを定義する、最も重要な部分です。単純なpushやpull_requestだけでなく、様々な条件を指定できます。

特定ブランチへのプッシュで実行

開発ブランチ（develop）と本番ブランチ（main）で実行する処理を分けたい、といったケースは頻繁にあります。branchesやbranches-ignoreを使って、対象となるブランチを絞り込むことができます。

例：mainブランチまたはrelease/で始まるブランチ（例: release/v1.2）へのプッシュ時のみ実行

on:
  push:
    branches:
      - 'main'
      - 'release/**'

逆に、特定のブランチを除外することも可能です。
例：docs/で始まるブランチ以外へのプッシュ時に実行

on:
  push:
    branches-ignore:
      - 'docs/**'

定期的なスケジュールで実行

scheduleイベントを使うと、cronジョブのように指定した日時にワークフローを定期実行できます。構文は標準的なcron形式です。

例：毎日午前9時30分（JST）に実行
cronの時刻はUTC（協定世界時）で指定する必要があります。日本標準時（JST）はUTCより9時間進んでいるため、JSTで午前9時30分は、UTCでは午前0時30分になります。

on:
  schedule:
    # 形式: 分 時 日 月 曜日
    - cron: '30 0 * * *'

この機能は、夜間のバッチ処理、定期的な脆弱性スキャン、レポート作成などに非常に便利です。

手動で実行

workflow_dispatchイベントを設定すると、Actionsタブに「Run workflow」というボタンが表示され、任意のタイミングでワークフローを手動実行できるようになります。

例：手動実行を許可し、実行時にパラメータを受け取る
inputsを定義することで、ワークフロー実行時にユーザーからの入力を受け取ることができます。これは、デプロイ対象の環境を選択させたり、デバッグレベルを指定させたりする場合に役立ちます。

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先の環境'
        required: true
        default: 'staging'
        type: choice
        options:
        - staging
        - production
      logLevel:
        description: 'ログレベル'
        required: false
        default: 'info'
        type: string

jobs..runs-on：実行環境を指定する

runs-onキーで、ジョブを実行する仮想マシンの環境（ランナー）を指定します。GitHub-hosted runnerの場合、OSの種類やバージョンを選ぶことができます。

Linux (Ubuntu): runs-on: ubuntu-latest (推奨), runs-on: ubuntu-22.04
Windows: runs-on: windows-latest (推奨), runs-on: windows-2022
macOS: runs-on: macos-latest (Intel), runs-on: macos-14 (Apple Silicon)

クロスプラットフォームテストなどで、複数の環境で同じジョブを実行したい場合は、matrixストラテジーと組み合わせると非常に強力です。

例：Node.js 18と20、OSはUbuntuとWindowsの組み合わせでテストを実行

jobs:
  test:
    strategy:
      matrix:
        node-version: [18, 20]
        os: [ubuntu-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

この定義だけで、(Node.js 18, Ubuntu), (Node.js 20, Ubuntu), (Node.js 18, Windows), (Node.js 20, Windows) の4つのジョブが並列で実行されます。

jobs..steps：実行する一連のタスクを定義する

stepsセクションには、ジョブが実行する具体的な手順を記述します。runとusesがその中心となります。

run：コマンドを実行する

runキーを使うと、ランナーのシェルで任意のコマンドを実行できます。LinuxとmacOSではbash、WindowsではPowerShellがデフォルトのシェルです。

例：複数行のコマンドを実行
|（パイプ）文字を使うと、複数行のスクリプトを記述できます。


- name: Build and Test
  run: |
    npm install
    npm run build
    npm test

working-directoryを指定すれば、特定のディレクトリに移動してからコマンドを実行することも可能です。


- name: Run tests in server directory
  working-directory: ./server
  run: npm test

uses：既存のアクションを利用する

usesキーは、Marketplaceなどで公開されているアクションを呼び出すために使用します。これにより、複雑な処理を自分で書くことなく、ワークフローを構築できます。

例：アクションにパラメータを渡す
多くのアクションは、withキーを使って動作をカスタマイズするための入力パラメータを受け取ります。


- name: Setup Node.js environment
  uses: actions/setup-node@v4
  with:
    # 使用するNode.jsのバージョンを指定
    node-version: '20'
    # npmのキャッシュを有効にする
    cache: 'npm'

アクションを利用する際は、actions/checkout@v4のように、@に続けてバージョン（タグやブランチ名、コミットハッシュ）を指定することが強く推奨されます。バージョンを固定することで、アクションの作者が破壊的な変更を加えても、自分のワークフローが突然壊れるのを防ぐことができます。

GitHub Actionsを利用する際の注意点

無料利用枠の上限を超えると有料になる、複雑な処理には専門知識が必要になる場合がある、パスワードなど機密情報の管理に注意する

GitHub Actionsは非常に便利で強力なツールですが、利用にあたってはいくつか注意すべき点があります。これらを理解しておくことで、トラブルを未然に防ぎ、より安全かつ効率的に活用することができます。

無料利用枠の上限を超えると有料になる

プライベートリポジトリでGitHub Actionsを利用する場合、契約プランに応じた無料利用枠（実行時間とストレージ）を超過すると、従量課金が発生します。特に、個人アカウントや小規模なチームで利用している場合、意図せず料金が発生してしまう可能性があるため、十分な注意が必要です。

対策として、以下の実践をお勧めします。

利用状況を定期的に監視する: GitHubの「Settings」→「Billing and plans」→「Plans and usage」ページで、現在の使用量を確認する習慣をつけましょう。
Spending limit（利用上限）を設定する: これが最も確実な対策です。支払い設定ページでSpending limitを$0に設定しておけば、無料枠を使い切った時点でワークフローが自動的に停止するため、想定外の課金を100%防ぐことができます。
ワークフローを最適化する:
- キャッシュの活用: actions/cacheアクションなどを使い、npm installでダウンロードしたライブラリなど、時間のかかる処理の結果をキャッシュしましょう。2回目以降の実行時間が大幅に短縮され、実行時間の節約に繋がります。
- 不要なジョブやステップの削減: 本当に必要な処理だけを実行するように、ワークフローを定期的に見直しましょう。
- 適切なランナーの選択: macOSランナーはLinuxランナーに比べて10倍のコストがかかります。本当にmacOS環境が必要なジョブ以外では、コストの安いLinuxランナー（ubuntu-latest）を積極的に利用しましょう。

複雑な処理には専門知識が必要になる場合がある

テンプレートを使えば基本的なCI/CDは簡単に始められますが、複数のクラウドサービスと連携する高度なデプロイパイプラインや、企業のセキュリティ要件を満たす複雑なワークフローを構築しようとすると、相応の専門知識が必要になります。

YAML: ワークフローの構文を正しく理解し、複雑な条件分岐や依存関係を記述する能力。
シェルスクリプト: runステップで独自の処理を書くためのスクリプティング能力。
Docker: アプリケーションをコンテナ化したり、カスタムアクションを作成したりするための知識。
クラウドサービス: AWS, GCP, Azureなど、連携先のサービスのAPIやCLIに関する知識。

また、ワークフローが失敗した際のデバッグは、ローカル環境で簡単には再現できないため、GitHub Actionsのログを丹念に読み解き、試行錯誤を繰り返す場面も出てきます。

まずはシンプルなワークフローから始めて、少しずつ機能を拡張していくアプローチが現実的です。いきなり複雑なものを作ろうとせず、一つひとつの要素を学びながらステップアップしていくことが成功の鍵です。

パスワードなど機密情報の管理に注意する

これはGitHub Actionsを利用する上で最も重要なセキュリティ上の注意点です。

ワークフローを定義するYAMLファイルは、ソースコードと同じリポジトリにコミットされます。そのため、YAMLファイル内にAPIキー、データベースのパスワード、クラウドサービスの認証情報といった機密情報を直接書き込むことは、絶対にやってはいけません。もしパブリックリポジトリでこれを行ってしまうと、全世界に機密情報が公開され、深刻なセキュリティインシデントに直結します。

これらの機密情報を安全に扱うために、GitHub Actionsには「Secrets」という機能が用意されています。

Secretsの正しい使い方:

リポジトリの「Settings」タブに移動し、左側のメニューから「Secrets and variables」→「Actions」を選択します。
「New repository secret」ボタンを押し、名前（例: AWS_ACCESS_KEY_ID）と値（実際のキー）を入力して保存します。
保存されたSecretは暗号化され、リポジトリの関係者であってもその値を見ることはできなくなります。
ワークフローファイルの中からは、${{ secrets.SECRET_NAME }}という構文で参照します。

例：


- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-1

このようにSecretsを使うと、機密情報がコードベースから完全に分離されます。さらに、GitHub Actionsは実行ログの中にSecretの値が出力されそうになった場合、自動的にその部分を***でマスクしてくれるため、誤ってログに機密情報が漏洩するリスクも低減されます。機密情報の取り扱いには細心の注意を払い、必ずSecrets機能を利用することを徹底してください。

GitHub Actionsとは 使い方入門から料金・CI/CDまで解説