GitHub Actionsとは？できること・使い方と最初のワークフロー、料金と上限【2026年10月】

GitHub Actionsは、GitHubのリポジトリで起きた出来事（プッシュ、プルリクエスト、Issueの作成、指定した時刻など）をきっかけに、テスト・ビルド・デプロイなどの処理を自動で実行する機能です。処理の内容はYAMLファイルに書き、リポジトリの .github/workflows に置くだけで動きます。

この記事では、CI/CD以外も含めてGitHub Actionsでできることをきっかけのイベント別に並べ、2026年10月時点の版で最初のワークフローを書く手順、無料枠と分単価、ジョブ6時間などの上限から見た「向かない用途」までを、GitHub公式ドキュメントに基づいて整理します。

まとめ：GitHub Actionsでできることと使い方の要点

• 何か：リポジトリのイベントを合図に、GitHubが用意する仮想マシン（ランナー）でコマンドやアクションを実行する仕組み。CI/CDが代表的な用途です。
• できること：テストとビルド（CI）、デプロイ（CD）、定期実行、Issueやプルリクエストの整理、リリースの作成、手動実行や外部システムからの起動。公式のイベント一覧には34の見出しがあります。
• 使い方：.github/workflows/ci.yml に on（いつ）・jobs（何を）・runs-on（どこで）を書いてプッシュする。実行結果はリポジトリの「Actions」タブに出ます。
• 料金：publicリポジトリで標準ランナーを使う分と、セルフホストランナーは無料。privateリポジトリはFreeプランで月2,000分（5分のジョブなら400回）まで無料で、超えた分はLinux 2コアなら1分0.006ドルです。
• 向かない用途：GitHubホストで1ジョブ6時間を超える処理（ubuntu-slim は15分超）、常時起動のサーバー、分単位の正確さが必要な定期処理。scheduleは最短5分間隔で、負荷が高いと遅れたり落ちたりします。

以下、仕組み、できること、書き方、上限、料金、ランナー、安全設定の順に説明します。

GitHub Actionsとは：リポジトリの出来事を合図に処理を走らせる仕組み

公式ドキュメントの説明は「リポジトリでイベントが起きたときに workflow が起動し、その中の1つ以上の job が順番に、または並列に実行される」というものです（Understanding GitHub Actions）。GitHubホストのジョブは原則として毎回新しい仮想マシンで動き、ubuntu-slim は新しいコンテナで動きます。セルフホストでは実行環境が再利用されることがあります。GitHubホストでは前回の実行で作ったファイルは残らないので、残したい成果物はアーティファクトかキャッシュに保存します。アーティファクトとログの保持期間は既定で90日です。

ワークフロー・ジョブ・ステップ・アクション・ランナーの関係

GitHub Actionsを構成する6つの用語を整理します。「workflow」は自動化の単位であるワークフローを指します。

ジョブは既定で依存関係を持たず並列に動き、needs を書いたときだけ前のジョブを待ちます。同じジョブの中のステップは上から順に実行され、ファイルを共有できます。ジョブをまたいだ値の受け渡しはGitHub Actionsのneeds｜ジョブ依存の設計とoutputs受け渡しの実務で扱っています。

GitHub ActionsとCI/CDの関係

CI（継続的インテグレーション）は、変更をプッシュするたびにビルドとテストを自動で回し、壊れた変更を早く見つける運用です。CD（継続的デリバリー／デプロイ）は、テストを通った成果物をそのまま本番やステージングへ届ける運用です。GitHub ActionsはこのCI/CDを実行する道具の一つです。CI/CDという考え方そのものはCI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説にまとめています。

GitHub Actionsの特徴は、イベントの種類がGitHubの操作（Issue、ラベル、レビュー、リリース等）にまで広がっている点です。そのため、CI/CDに限らず、リポジトリ運営の雑務も同じ仕組みで自動化できます。

GitHub Actionsでできること：きっかけのイベント別に7つの用途

ワークフローを起動できるイベントは、公式のEvents that trigger workflowsに見出し単位で34個並んでいます（うち pull_request_comment は「issue_comment を使う」という案内の項目です）。用途から逆引きすると次のようになります。

イベントごとの絞り込み（ブランチ名やパスで対象を限る書き方）はGitHub Actionsのトリガー（on）｜イベント選定とbranches・pathsフィルタの設計で詳しく扱っています。

プッシュ・プルリクエストを起点とするテストとビルド（CI）

代表的な用途がCIです。pull_request で動かすと、テストの結果がプルリクエストの画面にチェックとして表示され、ブランチ保護の「必須ステータスチェック」に指定すれば、テストが落ちたPRはマージできなくなります。OSや言語の版を変えて同じテストを回すにはmatrixを使います（1回の実行で最大256ジョブ）。手順の全体はGitHub Actionsでビルド・自動テストを設定する方法｜build.ymlの書き方と失敗の直し方、組み合わせの書き方はGitHub Actionsのマトリックスビルド｜組み合わせ展開とinclude・excludeの調整にあります。

本番・ステージングへのデプロイと承認（CD）

mainブランチへのマージを合図に、AWSやGoogle Cloud、Vercelなどへ反映します。クラウドへの認証は、長期のアクセスキーをsecretsに置く方式ではなく、OIDCで一時的な認証情報を受け取る方式が現在の基本です（AWSの例はconfigure-aws-credentialsの使い方：OIDC設定とv6の変更点、sub不一致エラーの直し方）。本番だけ承認者のレビューを挟みたい場合はEnvironmentsを使いますが、privateリポジトリで必須レビュアーを使えるのはEnterpriseプランです（GitHub ActionsのEnvironments｜承認ゲートと環境別シークレットの設計）。

scheduleによる定期実行と遅延・停止条件

cron式で定期実行できます。公式の仕様は「最短の間隔は5分に1回」「既定はUTC」「デフォルトブランチの最新コミットで動く」の3点です。日本時間の朝9時はUTCでは0時です。timezone に Asia/Tokyo を指定すれば、cron式を日本時間で書くこともできます。

on:
  schedule:
    - cron: '17 0 * * 1-5'   # 平日の日本時間 9:17（UTC 0:17）
  workflow_dispatch:          # 同じ処理を手動でも起動できるようにする

毎時0分ちょうどは混み合うため、公式は「負荷が高いと遅延し、十分に高ければ一部のジョブが破棄される」と書き、0分以外の時刻を勧めています。上の例で17分にしているのはこのためです。publicリポジトリでは60日間リポジトリに動きが無いと、定期実行は自動で無効になります。遅れの実態と止まる原因はGitHub Actionsのcron（schedule）｜遅延の実測・日本時間の指定・動かない原因で詳しく扱っています。

Issue・プルリクエストのラベル付けと担当者割り当て

issues イベントでIssueの作成やラベル付けを拾い、テンプレートに沿っていないIssueへのコメント、ラベルに応じた担当者の割り当て、古いIssueのクローズなどを行えます。プルリクエストへの自動ラベル付けは、フォークからのPRでも書き込み権限が要るため pull_request_target が使われますが、このイベントは扱いを誤ると危険です（後述の安全設定を参照）。GitHub APIを数行のJavaScriptで呼ぶなら actions/github-script が手軽です。

リリースの作成とパッケージの公開

v1.2.0 のようなタグのプッシュを合図に、ビルドした成果物をGitHub Releasesに添付したり、npmやコンテナレジストリへ公開したりします。リリースノートの自動生成とタグの違いはGitHub Releasesの使い方｜タグとの違い・リリースノート自動生成・Latestの決まり方、コンテナイメージのビルドとプッシュはGitHub ActionsでDockerイメージをビルドする｜push先とキャッシュ・マルチアーキの設計にあります。

ワークフローの手動実行と外部APIからの起動

workflow_dispatch を書くと、Actionsタブのボタン、gh workflow run、REST APIから起動でき、デプロイ先などを入力値で選ばせることもできます（GitHub Actionsの手動実行（workflow_dispatch）｜inputsの型定義とCLI・APIからの起動）。GitHubの外で起きた出来事を合図にしたいときは、外部システムからAPIで repository_dispatch を送ります。CMSで記事を公開したら静的サイトを作り直す、といった連携がこれで組めます。

GitHub Actionsの使い方：最初のワークフローの作成・実行・確認

リポジトリのルートに package.json と整合する package-lock.json があり、npm test でテストを実行できるNode.jsプロジェクトを前提に、mainへのプッシュとPRの作成・更新時にテストを回す例です。アクションの版は2026年10月時点の最新メジャー（actions/checkout v7.0.1、actions/setup-node v7.1.0）に合わせています。古い記事に残る @v2 や @v3 は、Node.jsの旧版向けに作られた版です。2026年9月23日にNode 20がランナーから削除され、JavaScriptアクションはNode 24で実行されるようになったため、GitHubはNode 24に対応した最新版へ上げるよう求めています（GitHub Changelog 2026-09-23）。

1. リポジトリに .github/workflows/ci.yml を作る（GitHubの画面ならActionsタブの「New workflow」から雛形を選べます）
2. 下のYAMLを書いてコミットし、プッシュする
3. Actionsタブで実行を開き、ステップごとのログを確認する。失敗したステップは赤く表示され、展開するとエラーの行が出ます

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test

YAMLの各キーの意味

timeout-minutes は省略すると360分です。テストが固まったときに6時間分の分数を使い切らないよう、普段の実行時間の2〜3倍を書いておくと安全です。値の受け渡しに使う env・vars・secrets の違いはGitHub Actionsの環境変数｜env・vars・secretsの使い分けと受け渡しを参照してください。

usesによるアクション指定とwithによる入力設定

uses: 所有者/リポジトリ@版 の形で、GitHub Marketplaceや他のリポジトリにあるアクションを呼び出し、with で入力を渡します。どの入力があるかは、各アクションのリポジトリにある action.yml の inputs に書かれています。たとえば actions/checkout は既定で最新コミット1件だけを取得するため、タグや履歴が必要なときは fetch-depth: 0 を渡します（actions/checkoutとは｜v7の既定変更・主要入力と浅いクローンの壊れ方）。

同じステップの並びを複数のワークフローで使い回すなら、自分でアクションを作るか、ワークフローごと呼び出します。前者はComposite Action（GitHub Actions）とは？action.ymlの書き方とpost処理の実装、後者はReusable Workflowsの使い方｜GitHub Actionsのworkflow_call・secrets・outputsと上限で扱っています。書いたYAMLは、プッシュする前にactionlintとは？GitHub Actionsワークフローの静的解析ツールの使い方・インストール・設定で検査すると、キーの綴り間違いや式の型の誤りを手元で拾えます。

GitHub Actionsでできないこと・向かない場面

「何でも自動化できる」わけではありません。公式のActions limitsにある上限のうち、設計に効くものは次のとおりです。上限に達すると、特に記載が無い限りワークフローやジョブはキャンセルされます。

同時実行ジョブはProで40、Teamで60、Enterpriseで500です。この上限から、次の用途にはGitHub Actionsを選ばない方がよいと判断できます。

• 常時起動のサーバーやWebhookの受け口：ジョブは最長6時間で終わり、毎回新しいマシンで動くため状態を持てません。APIサーバーやボットの常駐はクラウドの実行環境に置き、Actionsはそこへデプロイする役に徹します。
• 6時間を超えるバッチや機械学習の学習：GitHubホストのランナーでは途中で打ち切られます。セルフホストなら5日まで延びますが、GITHUB_TOKENを更新できるのは最長24時間のため、それ以降もGitHub APIなどへの認証が必要な処理には別の認証方法が要ります。
• 時刻の正確さが業務要件になる定期処理：scheduleは遅れることがあり、負荷が高ければ落ちることもあると公式が明記しています。締め処理や請求処理のように「その時刻に必ず」が求められるものは、クラウドのスケジューラーに任せます。
• privateリポジトリでの大量のmacOSビルド：macOSは1分0.062ドルでLinux 2コアの約10倍です。iOSアプリを1日に何十回もビルドするなら、費用を先に試算します。

逆に、1回数分〜数十分で終わり、リポジトリの出来事と結び付いた処理であれば、まずGitHub Actionsで組むのが手間の少ない選択です。社内のCI/CDをどこまでActionsに寄せるか、既存のJenkinsからどう移すかといった設計から相談したい場合は、DevOps・CI/CD導入支援でも承っています。

GitHub Actionsの料金：無料枠と5分ジョブの実行回数

公式の課金ドキュメントは、標準のGitHubホストランナーをpublicリポジトリで使う分と、セルフホストランナーの利用を無料としています（GitHub Actions billing）。privateリポジトリには、プランごとに月間の無料枠があります。

無料枠を超えた分の単価は、Linux 2コアが1分0.006ドル、Windows 2コアが0.010ドル、macOSが0.062ドル、1コアの ubuntu-slim が0.002ドルです（Actions runner pricing）。分数はジョブごとに1分単位へ切り上げて数えるので、20秒で終わるジョブを3つに分けると3分として数えられます。5分のLinuxジョブなら1回0.03ドルで、無料枠を使い切ったあと月にさらに1,000回回しても30ドルです。キャッシュの容量は、どのプランでも既定でリポジトリあたり10GBです（増やすことはでき、超えた分は課金されます）。

larger runnerはコア数にかかわらず、publicリポジトリでも、無料枠が残っていても常に課金されます。2026年の単価改定の経緯、費用を減らす設定、セルフホスト課金の延期はGitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準で詳しく扱っています。

ランナーの選び方：GitHubホストとセルフホスト

runs-on に書くラベルでマシンの種類が決まります。2026年10月時点で公式に載っている標準ランナーのラベルは次のとおりです（GitHub-hosted runners reference）。

• Linux：ubuntu-latest・ubuntu-26.04・ubuntu-24.04・ubuntu-22.04、arm64は ubuntu-26.04-arm などの -arm 付き
• Windows：windows-latest・windows-2025・windows-2022、arm64は windows-11-arm
• macOS：macos-latest・macos-26・macos-15・macos-14、Intelは macos-15-intel・macos-26-intel
• 軽量：ubuntu-slim（1コアのコンテナ。ジョブは15分で打ち切られ、Docker-in-Dockerなど特権が要る操作は不可）

注意したいのは -latest の中身が入れ替わることです。ubuntu-latest は2026年10月19日から11月19日にかけて、Ubuntu 24.04から26.04へ段階的に移ります（GitHub Changelog 2026-09-17）。macos-latest はすでにmacOS 26を指しており、macos-14 は2026年11月2日に廃止される予定です（GitHub Changelog 2026-10-01）。Ubuntuの移行期間中は同じワークフローでも実行ごとにOSが変わりうるので、入っているツールの版が変わって落ちたら、まず ubuntu-24.04 に固定して切り分けます。ラベルの記法と更新への備えはGitHub Actionsのruns-on｜ラベル指定の記法と-latest更新・arm64への備え、slimの制約はGitHub Actionsのubuntu-slimとは｜1コア5GB・15分上限とDockerが動かない条件にあります。

社内ネットワークの中にあるデータベースへ接続したい、GPUや特定のOSが要る、という場合はセルフホストランナーを自分のマシンに登録します。利用料は無料ですが、ランナーの版を新版の公開から30日以内に更新する義務と、マシンの保守は自分の負担になります（GitHubセルフホストランナーとは？導入手順とhosted版の違い【2026年版】）。

使い始める前に決める安全設定

ワークフローはリポジトリへの書き込みやクラウドへのデプロイ権限を持つため、乗っ取られると被害が大きくなります。最初の1本を書く段階で、次の4点を決めておきます。

• GITHUB_TOKENの権限を絞る：ワークフローの先頭に permissions: { contents: read } を書き、書き込みが必要なジョブにだけ追加します。トークンはジョブの開始時に発行され、ジョブが終わると失効します（GitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計）。
• サードパーティのアクションはコミットSHAで固定する：@v1 のようなタグは作者が付け替えられるので、乗っ取られたタグを通じて悪意あるコードが入る経路になります。組織の設定でSHA固定を必須にもできます（SHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法【Enforce設定・pinact・ロックファイル】）。
• pull_request_target でPRのコードを実行しない：公式は、このイベントで信頼できないコードを動かすと、キャッシュの汚染や、意図しない書き込み権限・secretsへのアクセスにつながると警告しています。フォークのPRのテストは pull_request で回します。
• フォークからのPRでsecretsが渡らない前提で組む：フォークからのPRを pull_request イベントで処理する場合、既定ではActions secretsは渡されず、GITHUB_TOKENは読み取り専用です。ただし、pull_request_target ではベースリポジトリの権限やsecretsを利用できるため、この制限を前提にしてはいけません。DependabotのPRを pull_request イベントで処理する場合もGITHUB_TOKENは既定で読み取り専用ですが、Actions secretsの代わりにDependabot secretsを利用できます。

よくある質問

GitHubとGitHub Actionsの違いは何ですか？

GitHubはGitリポジトリを置いてプルリクエストやIssueで共同開発するサービスで、GitHub Actionsはその中の自動化機能です。追加の契約は不要で、リポジトリに .github/workflows のYAMLを置けば使えます。

GitHub Actionsは無料で使えますか？

publicリポジトリで標準ランナーを使う分と、セルフホストランナーの利用は無料です。privateリポジトリはFreeプランで月2,000分まで無料で、超えた分はLinux 2コアなら1分0.006ドルです。larger runnerはコア数にかかわらず常に有料です。

ワークフローとアクションの違いは何ですか？

ワークフローは「いつ・何を・どこで」を書いた自動化の単位で、.github/workflows に置くYAMLファイル1つが1ワークフローです。アクションはワークフローの中の1ステップとして uses で呼ぶ部品で、checkoutや言語のセットアップのように使い回せる処理をまとめたものです。

JenkinsやGitLab CIとは何が違いますか？

Jenkinsはサーバーを自分で立てて保守するのが前提ですが、GitHub ActionsはGitHubがランナーを用意するので、サーバーの保守が要りません。GitLab CIとは仕組みが近く、差はリポジトリをどちらに置くかと料金体系です。キーの対応表はGitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較、製品横断の比較はCI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】にあります。

GitHub Actionsは何と読みますか？

「ギットハブ アクションズ」と読みます。公式の表記は「GitHub Actions」で、略して「GHA」や、単に「Actions」と呼ばれることもあります。

関連記事

• GitHub Actionsでビルド・自動テストを設定する方法｜build.ymlの書き方と失敗の直し方
• GitHub Actionsのトリガー（on）｜イベント選定とbranches・pathsフィルタの設計
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準
• GitHubセルフホストランナーとは？導入手順とhosted版の違い【2026年版】
• CI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説