ソフトウェア開発を効率化するCI/CDツールの選択肢は年々増えており、どれを選ぶべきか判断に迷う場面も多いでしょう。
GitHub Actionsは、GitHubが提供するワークフロー自動化サービスです。GitHubリポジトリ内でCI/CDを直接定義・実行できる点が支持され、導入が広がっています。
しかし、「用語が多くて全体像がつかめない」「YAMLファイルの書き方がわからない」「他のCI/CDツールと比べて何が違うのか知りたい」と感じている方もいるのではないでしょうか。
本記事では、GitHub Actionsの仕組みから基本用語、YAMLファイルの書き方、料金体系、他のCI/CDツールとの比較までを紹介します。CI/CDツールの導入を検討している方は、ぜひお役立てください。
「どのCI/CDツールが自社に合うのかわからない」「GitHub Actionsを導入したいが、体制づくりに不安がある」という方もいるのではないでしょうか。
アイスリーデザインでは、ツール選定から導入・運用までを一貫して支援しています。構想段階でも構いませんので、お気軽にご相談ください。
GitHub Actionsとは？CI/CDを実現する自動化ツール
GitHub Actionsは、GitHubが提供するワークフロー自動化サービスです。DevOpsやアジャイル開発で必要なCI/CDのプロセスを、GitHubリポジトリ上で直接定義・実行できます。
ここでは、GitHub Actionsの全体像と前提となるCI/CDの概念を説明します。
DevOpsやアジャイル開発を詳しく知りたい方は、以下の記事もご覧ください。
GitHub Actionsの概要と特徴
GitHub Actionsは、2019年11月に一般提供が開始されたGitHub公式のワークフロー自動化サービスです。2018年のGitHub Universeで初めて発表され、限定的なベータ版を経て2019年に正式リリースされました。GitHubのリポジトリ内でCI/CDパイプラインを定義・管理でき、別のCIサービスを用意する手間が省ける点が支持されています。
GitHub Actionsの主な特徴は以下のとおりです。
| 特徴 | 内容 |
|---|---|
| GitHubイベントとの連携 | プッシュ、プルリクエスト、イシュー作成など、GitHub上の操作をトリガーにワークフローを自動実行できる。CI/CD以外にも、Slack通知やドキュメント生成といったプロジェクト管理の自動化にも対応 |
| 実行環境の提供 | Linux・Windows・macOSの仮想環境をGitHubが管理しており、セットアップや保守の手間なく一貫した環境でテスト・ビルドを実行できる |
| GitHub Marketplaceの活用 | 事前に定義されたワークフロー部品（アクション）をMarketplaceから取得でき、一般的なタスクの実装を短縮できる |
| セキュリティの統合 | GitHubのアクセス権限管理やシークレット管理機能と統合されており、APIキーやパスワードを安全に扱える |
GitHubを普段から利用しているチームにとって、追加のツール導入や学習コストを抑えつつCI/CDを始められる点が導入のしやすさにつながっています。
GitHubについて詳しく知りたい方は、以下の記事もご覧ください。
そもそもCI/CDとは？
CI/CDは、ソフトウェア開発のビルド・テスト・デプロイといった作業を自動化し、効率化する手法です。継続的インテグレーション（Continuous Integration）と継続的デリバリー/デプロイメント（Continuous Delivery / Continuous Deployment）の頭文字を組み合わせた言葉です。
| 用語 | 内容 |
|---|---|
| 継続的インテグレーション（CI） | 開発者が頻繁にコードを共有リポジトリにマージし、自動でビルドとテストを実行する。バグを早期に発見し、コードの品質を保てる |
| 継続的デリバリー/デプロイメント（CD） | 検証済みのコードを自動でリリース環境に反映し、本番環境へのデプロイまでを自動化する。新機能や改善を素早くユーザーに届けられる |
CI/CDの自動化により、人的エラーを防ぎながら開発・運用チーム全体の生産性を高められます。GitHub Actionsは、このCI/CDのプロセスをGitHub内で完結させるためのツールです。
CI/CDについて詳しく知りたい方はこちらの記事をご覧ください。
GitHub Actionsの構成要素と基本用語
GitHub Actionsでワークフローを作成するには、構成要素とその関係性を把握しておくとスムーズです。
ここでは、GitHub Actionsを構成する主要な要素と基本用語を説明します。
Workflow・Job・Step・Actionの関係性
GitHub Actionsのワークフローは、Workflow・Job・Stepの3階層で構成され、Step内でAction（再利用可能な部品）を呼び出して処理を実行します。全体の関係性は以下の図のとおりです。
各要素の役割は以下のとおりです。
| 要素 | 役割 |
|---|---|
| Workflow（ワークフロー） | 一連の作業をまとめた処理の定義ファイル。YAML形式で.github/workflows/配下に保存する |
| Job（ジョブ） | ワークフロー内の個別の作業単位。複数のジョブを並列に実行できる |
| Step（ステップ） | ジョブの中で実行される具体的なタスク。コマンド実行やアクションの呼び出しなどを順番に進める |
| Action（アクション） | 再利用可能な処理の部品。MarketplaceやGitHubリポジトリから取得して、ステップ内で使える |
図中の「Run action」が、Marketplaceなどから取得できる再利用可能な部品（Action）にあたります。Actionを組み合わせることで、ゼロからスクリプトを書かずにワークフローを組み立てられます。
イベントとトリガーの種類
ワークフローは、特定のイベントをトリガーに自動実行されます。実務でよく使われるトリガーは以下のとおりです。
| トリガー | 内容 |
|---|---|
| push | コードがプッシュされたときに実行 |
| pull_request | プルリクエストの作成・更新時に実行 |
| schedule | cron構文で指定した時刻に定期実行 |
| workflow_dispatch | GitHubのUIやAPIから手動で実行 |
| issues | イシューのopened・closed・labeledなどの特定アクティビティ時に実行 |
| release | リリース作成時に実行 |
複数のトリガーを組み合わせて、1つのワークフローを複数のタイミングで動かすこともできます。たとえば「プッシュ時とプルリクエスト時の両方でテストを実行する」といった設定も可能です。
ランナーの種類と選び方
ランナーは、ワークフローを実行するための作業環境です。大きく分けてGitHub-hostedとSelf-hostedの2種類があります。
| 種類 | 内容 |
|---|---|
| GitHub-hosted | GitHubが提供する仮想マシン。Linux・Windows・macOSから選択でき、環境のセットアップや保守が不要 |
| Self-hosted | 自社のサーバーやクラウド上に構築するランナー。特殊なハードウェア要件やセキュリティ要件がある場合に利用する |
通常のCI/CD用途ではGitHub-hostedで十分ですが、社内ネットワーク内のリソースにアクセスする必要がある場合や、特定のOSバージョン・ハードウェアが必要な場合はSelf-hostedを検討します。
これらの構成要素を実際に定義するのが、次のセクションで扱うYAMLファイルです。
GitHub Actionsを動かすYAMLファイルの書き方
GitHub Actionsのワークフローは、YAMLファイルで定義します。.github/workflows/配下にファイルを配置し、YAMLファイル内でon:を使って実行トリガーを指定することで、GitHubが自動的に実行します。
ここでは、YAMLの基本的な書き方と主要キーの役割を紹介します。
最小構成のワークフロー例
mainブランチへのプッシュをトリガーに、Node.jsのテストを実行する最小構成は以下のとおりです。
name: CI
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
このファイルを.github/workflows/ci.ymlとして保存しリポジトリにプッシュすれば、以降mainブランチへのプッシュのたびにテストが自動実行されます。
覚えておきたいYAMLの主要キーと役割
上記の例で使われているキーの意味は以下のとおりです。
| キー | 役割 |
|---|---|
| name | ワークフローの名前。GitHub上の表示名として使われる |
| on | ワークフローを起動するトリガーを指定する |
| jobs | 実行するジョブの一覧を定義する |
| runs-on | ジョブを実行するランナー（OS）を指定する |
| steps | ジョブ内で順番に実行する手順を並べる |
| uses | 既存のアクションを呼び出す。MarketplaceやGitHubリポジトリ上のアクションを指定できる |
| with | アクションに渡すパラメータを指定する |
| run | シェルコマンドを直接実行する |
これらのキーを組み合わせることで、テスト・ビルド・デプロイといった処理を自在に定義できます。
シークレットと環境変数の設定方法
APIキーやトークンといった機密情報は、リポジトリのSettings > Secrets and variables > Actionsから登録します。登録した値はsecrets.<名前>で参照でき、ログにも表示されません。
steps:
- name: Deploy
env:
API_KEY: ${{ secrets.API_KEY }}
run: ./deploy.sh
通常の環境変数はenvキーで定義します。ワークフロー全体・ジョブ単位・ステップ単位のいずれでも指定できるため、スコープを意識して使い分けるとよいでしょう。
${{ secrets.GITHUB_TOKEN }}はGitHubが自動発行する一時的なトークンで、リポジトリ操作の権限管理に使います。
CI/CDの自動化設計や運用体制の構築は、開発プロジェクトの規模・言語・リリース頻度によって適した形が異なります。
アイスリーデザインでは、構想からPoC、実装、運用まで一貫した支援が可能です。お気軽にご相談ください。
GitHub Actionsの料金体系
GitHub Actions は、パブリックリポジトリでは標準の GitHub-hosted runner を無料で利用できます。（ただし larger runner はパブリックリポジトリでも無料ではありません。）プライベートリポジトリでは、プランごとの無料分を超えた利用に課金が発生します。
ここでは、無料枠の範囲と、超過した場合の料金について説明します。
※本記事の料金情報は2026年4月時点のものです。最新情報はGitHub公式ドキュメントをご確認ください。
無料でどこまで使える？無料枠の範囲と確認方法
パブリックリポジトリでは、標準のGitHub-hostedランナーを使ったワークフローの実行時間が無料です。一方、プライベートリポジトリでは、アカウントのプランごとに月間の無料枠が付与されます。
無料枠の残量は、GitHubのSettings > Billing and plans > Plans and usageから確認できます。組織アカウントの場合は、組織のSettingsから同じ画面にアクセスできます。
有料プランに切り替えるべき？料金の目安と計算方法
GitHub-hosted runner の料金は、OS と runner の性能によって異なります。ストレージは artifact と cache で別の計測体系があり、時間ベースで蓄積されます。
| ランナー | 単価（1分あたり） |
|---|---|
| Linux 1コア | $0.002 |
| Linux 2コア | $0.006 |
| Linux ARM 2コア | $0.005 |
| Windows 2コア | $0.010 |
| macOS | $0.062 |
OSによって単価に差があり、macOSが高めでLinuxが安価です。コストを抑えたい場合は、特別な理由がない限りLinuxランナーを選ぶのが現実的です。
ストレージは無料枠を超えた分について使用量に応じて課金されます。実際の費用を把握したい場合は、GitHub提供の料金計算機で見積もりできます。
無料枠内に収まる場合は追加コストは発生しません。無料プランで始め、使用量を見ながら必要に応じてプランを切り替えるとよいでしょう。
GitHub Actionsと他のCI/CDツールの比較
CI/CDツールを選ぶ際には、代表的な他のツールとの違いを押さえておくと判断がしやすくなります。
ここでは、GitHub Actionsの導入を検討する上で比較対象になりやすい3つのツールを紹介します。
CircleCIとの違い
CircleCIは、GitHub・GitLab・Bitbucketに対応した独立系のCI/CDサービスです。両者の違いは以下のとおりです。
| 観点 | GitHub Actions | CircleCI |
|---|---|---|
| 運用モデル | マネージド（Self-hostedも選択可） | マネージド（Self-hostedも選択可） |
| 設定ファイル | .github/workflows/配下にワークフローごと複数のYAML | 単一の.circleci/config.yml |
| 再利用の仕組み | Actions（Marketplaceから取得可） | Orbs |
| 向いている用途 | GitHub完結でCI/CDを始めたい場合 | 複数のGitホスティングを横断して使いたい場合や並列実行を重視する場合 |
GitHubで完結させたい場合はGitHub Actionsが、複数のGitホスティングを横断して使いたい場合はCircleCIが候補になります。
CircleCIについて詳しく知りたい方はこちらの記事をご覧ください。
Jenkinsとの違い
Jenkinsは、長い歴史を持つオープンソースのCI/CDツールです。両者の違いは以下のとおりです。
| 観点 | GitHub Actions | Jenkins |
|---|---|---|
| 運用モデル | マネージド（Self-hostedも選択可） | セルフホスト（自社で構築・運用） |
| 設定ファイル | YAML（.github/workflows/配下） | Jenkinsfile（Groovy） |
| 再利用の仕組み | Actions（Marketplaceから取得可） | プラグイン（1,800以上） |
| 向いている用途 | クラウド前提でCI/CDを素早く始めたい場合 | オンプレミスやコンプライアンス要件の厳しい環境 |
サーバー構築や保守の手間をかけずにCI/CDを始めたい場合はGitHub Actionsが、オンプレミスやエアギャップ（外部ネットワークから隔離された環境）での運用が必要な場合はJenkinsが適しています。
GitLab CI/CDとの違い
GitLab CI/CDは、GitLabに組み込まれたCI/CDツールです。両者の違いは以下のとおりです。
| 観点 | GitHub Actions | GitLab CI/CD |
|---|---|---|
| 運用モデル | マネージド（Self-hostedも選択可） | マネージド（Self-hostedも選択可） |
| 設定ファイル | .github/workflows/配下にワークフローごと複数のYAML | 単一の.gitlab-ci.yml |
| 再利用の仕組み | Actions（Marketplaceから取得可） | include / コンポーネント |
| 向いている用途 | GitHubのエコシステムとMarketplaceを活用したい場合 | GitLabのDevOpsプラットフォーム全体と統合したい場合 |
Marketplaceの既製アクションを活用してCI/CDを組みたい場合はGitHub Actionsが、GitLab標準のDevOps機能（セキュリティスキャンやAuto DevOpsによる自動デプロイなど）をまとめて使いたい場合はGitLab CI/CDが向いています。
CI/CDツールの選定や乗り換えに迷っている方もいるでしょう。
アイスリーデザインでは、デザイナーとエンジニアが同一チームで開発を進めるワンストップ体制で、開発環境の構築・改善を支援しています。まずはお気軽にご相談ください。
まとめ
GitHub Actionsは、GitHubリポジトリ上で直接CI/CDを定義・実行できるワークフロー自動化サービスです。本記事で紹介した内容を振り返ります。
- GitHub ActionsはCI/CDを含むワークフローの自動化を担い、GitHubのイベントをトリガーに動作する
- Workflow・Job・Step・Actionの関係を押さえれば、全体像がつかめる
- YAMLファイルを
.github/workflows/配下に置き、on:で実行トリガーを指定するとワークフローが自動実行される - パブリックリポジトリでは無料、プライベートでもプランに応じた無料枠がある
- GitHub完結で運用したい場合は、CircleCIやJenkins、GitLab CI/CDと比べて導入しやすい
本記事の最小構成YAMLをコピーして、自分のリポジトリで動かしてみるところから始めるのがおすすめです。実際にワークフローが動く体験を経ると、用語や仕組みの理解が一気に進みます。
アイスリーデザインでは、GitHub Actionsをはじめとした開発ツールの導入支援を提供しています。導入計画の立案から運用体制の構築まで、お気軽にご相談ください。
本記事は、2024年8月30日に公開された記事を再編集し、2026年4月27日にin-Pocket編集部により情報を追記しております。