GitHub Actions入門｜CI/CDの仕組みを「レストランの厨房」でまるごと理解する

「GitHub Actionsという言葉は聞くけれど、ワークフロー・ジョブ・ステップ・アクション…用語が多すぎて頭に入ってこない」。この記事はそんな方のために書きました。


読み終わる頃には、①GitHub Actionsが何をしてくれるのか、②登場人物どうしがどうつながっているのか、③自分のリポジトリで実際に動かすYAMLの読み方、④お金はいくらかかるのか、⑤個人の定期バッチを無料で回せるのか、までが順番につながって理解できる状態になります。


専門用語には必ずその場で補足を入れていますので、前提知識ゼロでも大丈夫です。

そもそもCI/CDとは何か

GitHub Actionsを理解する前に、CI/CDという言葉を押さえておきます。

CI（Continuous Integration／継続的インテグレーション）とは、書いたコードを頻繁に共有場所へ持ち寄り、そのたびに自動で「ちゃんと動くか」を検査する開発のやり方です。「インテグレーション」は統合、つまり複数人が書いたコードを1つにまとめることを指します。

CD（Continuous Delivery／Deployment＝継続的デリバリー／継続的デプロイ）とは、検査を通ったコードを、いつでもリリースできる状態に自動で整える（デリバリー）、あるいは本番環境まで自動で届ける（デプロイ）ことです。

イメージしにくい場合は、レストランの厨房を思い浮かべてください。料理人（開発者）が作った皿を、出す前に必ず「味見係」がチェックし、問題なければホールへ運ぶ。この味見と配膳を毎回・自動で・同じ手順でやる仕組みがCI/CDです。人間がやると「今日は忙しいから味見を飛ばそう」が起きますが、機械は絶対に飛ばしません。ここがCI/CDの最大の価値です。

CI/CDの中では、次の3つの作業が繰り返し登場します。

• ビルド（build）：人間が書いたソースコードを、実行できる形（アプリのファイル、実行ファイル、Dockerイメージなど）に組み立てる作業です。料理でいう「調理」。
• テスト（test）：組み立てたものが期待通りに動くかを自動で検査する作業です。料理でいう「味見」。
• デプロイ（deploy）：完成したものを、実際に使われる場所（サーバー、クラウド、アプリストアなど）へ配置して動かす作業です。料理でいう「配膳」。

GitHub Actionsとは何者か

GitHub Actionsは、GitHubが公式に提供しているCI/CDプラットフォームです。GitHubのドキュメントでは「ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォーム」と説明されています。

ポイントは、GitHub ActionsがCI/CD専用ツールではないことです。公式ドキュメントも明言しているとおり、「新しいIssue（課題チケット）が作られたら自動でラベルを付ける」といった、開発以外の雑務の自動化にも使えます。

「GitHubで何かが起きたら、GitHubが用意したサーバーで好きな処理を走らせられる仕組み」と捉えると応用範囲が見えてきます。

【図解】ワークフロー→イベント→ジョブ→ステップ→アクション→ランナーの関係

6つの用語は並列に並んでいるのではなく、入れ子（マトリョーシカ）の関係です。まず全体像を一文でまとめると、こうなります。


リポジトリで「イベント」が起きると「ワークフロー」が起動し、その中の「ジョブ」が「ランナー」という使い捨てのサーバー上で動き、ジョブは「ステップ」の並びでできていて、各ステップは「アクション」を呼ぶかシェルコマンドを実行します。

ジョブ間の依存関係は needs キーワードで指定します。needs を書いた場合のみ、指定したジョブの成功を待ってから実行されます。ジョブが異なればランナー（マシン）も別物になるため、ジョブAで作ったファイルはジョブBには引き継がれません。

用語をひとつずつ丁寧に

① イベント（events）

イベントとは、ワークフローを起動させるきっかけとなるリポジトリ上の出来事です。「自動販売機のボタン」だと思ってください。ボタンが押されない限り、何も出てきません。

② ワークフロー（workflows）

ワークフローは、自動化したい処理全体をまとめた手順書です。実体はYAML（ヤムル）ファイルで、リポジトリの中に一緒に保存されます。

ワークフローのYAMLファイルは、リポジトリ直下の .github/workflows というフォルダに置く決まりです。GitHubはこのフォルダだけを見に行くので、場所が1文字でも違うと何も起きません。

あなたのリポジトリ/
├── .github/
│   └── workflows/
│       ├── ci.yml          # ワークフロー1つめ
│       └── nightly.yml     # ワークフロー2つめ
├── src/
└── README.md

③ ジョブ（jobs）

ジョブは、ワークフローの中の作業の大きなかたまりで、1台のランナー（サーバー）を丸ごと1つ占有して動きます。厨房でいう「調理場ひとつ」に相当します。初心者がとくに間違えやすいのは次の2点です。

• ジョブは既定では並列（同時）に実行される：順番に動かしたい場合は needs で依存関係を書きます。
• ジョブが違えばマシンも別物：ジョブAで作ったファイルはジョブBには残っていません。渡したい場合は「アーティファクト」（後述）を使います。

④ ステップ（steps）

ステップは、ジョブの中の1つ1つの作業です。「材料を出す」「切る」「焼く」といった単位で、書いた順に上から実行され、同じランナー上で動くのでファイルや状態を引き継げます。途中のステップが失敗すると、そのジョブは原則そこで停止します。ステップの書き方は2種類だけです。

• run: … シェルコマンドをそのまま書く（例：run: npm test）
• uses: … 誰かが作ったアクションを呼び出す（例：uses: actions/checkout@v6）

⑤ アクション（actions）

アクションは、よく使う処理をパッケージ化した再利用可能な部品です。「リポジトリのコードを取得する」「Node.jsをインストールする」といった、誰もが毎回書くことになる定型処理を1行で呼び出せます。料理でいう市販の合わせ調味料で、自分で一から配合しなくてよくなります。

GitHub Marketplaceは、世界中の開発者が公開したアクションを検索・入手できる公式の部品カタログです。「Slackに通知したい」「AWSにデプロイしたい」といった用途は、たいてい既製のアクションが見つかります。もちろん自分でアクションを作って公開することもできます。

⑥ ランナー（runners）

ランナーは、ジョブを実際に実行するサーバーです。1台のランナーは同時に1つのジョブだけを担当します。GitHub公式が用意するランナー（GitHubホストランナー）には、Linux・Windows・macOSの3種類があり、ワークフローが実行されるたびに新しくプロビジョニング（用意）された仮想マシンが割り当てられます。

つまり毎回まっさらな状態から始まるため、「自分のPCでは動くのに…」という環境差のトラブルが起きにくくなります。

GitHubが用意したマシンではなく、自分の会社のサーバーや自宅PCをランナーとして登録することもできます。これをセルフホストランナーと呼びます。特殊なハードウェアが必要な場合や、社内ネットワークからしかアクセスできない環境へデプロイしたい場合に使われます。

実際のYAMLを読んでみる

Node.jsアプリをテストする最小構成のYAMLです。各行のコメントと照らし合わせながら読んでみてください。

# .github/workflows/ci.yml

name: CI                        # ワークフローの表示名

on:                             # ① イベント（起動のきっかけ）
  push:
    branches: [ main ]          #   mainブランチにpushされたとき
    pull_request:               #   プルリクエストが作られたとき
    workflow_dispatch:          #   画面から手動実行したいとき

jobs:                           # ③ ジョブの定義開始
  build-and-test:               #   ジョブのID（自由に決めてよい）
    name: ビルドとテスト
    runs-on: ubuntu-latest      # ⑥ ランナーの指定

    steps:                      # ④ ステップの並び
      - name: コードを取得する
        uses: actions/checkout@v6        # ⑤ アクションを使う

      - name: Node.js を用意する
        uses: actions/setup-node@v6      # ⑤ アクションを使う
        with:                            #   アクションへの入力パラメータ
          node-version: '22'

      - name: 依存パッケージを入れる（ビルド準備）
        run: npm ci                      # シェルコマンドを直接実行

      - name: テストを走らせる
        run: npm test

読み方のコツは次のとおりです。

• on: を見れば「いつ動くか」がわかる
• jobs: の直下の名前が「何個の作業単位があるか」
• runs-on: が「どのOSで動くか」
• steps: の「-」の数が「何手順あるか」

ジョブを2つに分け、テストが通ったときだけデプロイする形にすると、こうなります。

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: npm ci && npm test

  deploy:
    needs: test                 # testジョブが成功するまで待つ
    if: github.ref == 'refs/heads/main'   # mainのときだけ実行
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: ./deploy.sh
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}   # シークレットを渡す

環境変数とシークレット

環境変数（environment variables）とは、プログラムの外側から渡す設定値の入れ物です。「本番用かテスト用か」「どのURLに接続するか」といった、コードに直接書きたくない値を保持します。GitHub Actionsでは env: で定義し、${{ env.名前 }} や $名前 で参照します。

env:
  NODE_ENV: production          # ワークフロー全体で有効

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      APP_NAME: my-app          # このジョブだけで有効
    steps:
      - run: echo "$APP_NAME を $NODE_ENV モードでビルドします"

シークレット（secrets）とは、他人に見られてはいけない機密値（APIキー、パスワード、クラウドの認証情報など）を安全に保管する仕組みです。GitHubの画面上で登録すると暗号化して保存され、登録後は本人でも中身を読み出せません。ワークフローからは ${{ secrets.名前 }} で参照します。実行ログに出力しようとしても、GitHubが自動で *** にマスクします。

登録方法：リポジトリの Settings → Secrets and variables → Actions → New repository secret

料金プランと無料枠

大原則は次の1行です。パブリックリポジトリ（誰でも見られる公開リポジトリ）で標準のGitHubホストランナーを使う限り、GitHub Actionsは無料です。料金が発生するのは、原則としてプライベートリポジトリ（非公開）で使った場合です。


プライベートリポジトリの場合、プランごとに毎月の無料枠が付与され、それを超えた分が課金されます（2026年7月時点、公式ドキュメント記載の値）。

無料枠は毎月の請求サイクルの開始時にリセットされます。また、消費した分は「実行した人」ではなくリポジトリの所有者に課金される点も覚えておいてください。

OSによって消費が変わる（超過後の単価）

無料枠を超えた分の単価は、OSと構成によって大きく違います（2026年1月1日改定後の標準ランナー）。

個人の定期バッチを無料で自動化することは可能か？

結論：可能です。ただし、いくつか押さえるべき条件と落とし穴があります。

無料で回すための条件

1. パブリックリポジトリを使う：これが最重要です。公開リポジトリでの標準GitHubホストランナー利用は無料なので、実行時間を気にせず回せます。処理内容を公開したくない場合はプライベートリポジトリになり、無料枠（Freeなら月2,000分）の中でのやりくりになります。
2. Linuxランナーを使う：runs-on: ubuntu-latestが最も安価です。プライベートで運用する場合、Windowsは約1.7倍、macOSは約10倍の消費として計算されます。
3. scheduleイベントで定期実行する：cron形式で日時を指定します。

実際のコード例：毎日9時（日本時間）に処理を回す

# .github/workflows/daily-batch.yml
name: 毎日のバッチ処理

on:
  schedule:
    - cron: '0 0 * * *'     # UTCの毎日0:00 = 日本時間の毎朝9:00
  workflow_dispatch:         # 手動実行もできるようにしておくと便利

jobs:
  batch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v6
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - name: バッチ本体を実行
        run: python main.py
        env:
          API_KEY: ${{ secrets.API_KEY }}

知っておくべき落とし穴

向いている用途・向かない用途

まとめると、「1日1回〜数回、数分で終わる、多少時刻がずれても困らない処理」であれば、GitHub Actionsは個人の定期バッチ基盤として極めて優秀です。サーバー代ゼロ、監視ゼロ、コードとスケジュールを同じ場所で管理できるという利点は、レンタルサーバーのcronにはない大きな魅力です。

次に覚えると強い追加知識

基本を押さえたら、次はこのあたりを知っておくと一気に実用度が上がります。

アーティファクト（artifact）：ワークフローが生み出した成果物ファイル（ビルド済みアプリ、テストレポート、ログなど）を保存し、後からダウンロードしたり別のジョブへ受け渡したりする仕組みです。ジョブ間でファイルを共有する標準的な方法です。

キャッシュ（cache）：npmやpipでインストールするライブラリなど、毎回同じものを再取得するのは時間の無駄です。キャッシュを使うと2回目以降の実行が劇的に速くなります（実行時間＝コストなので節約にもなります）。

マトリックス（matrix）：「Node.js 20と22の両方」「WindowsとLinuxの両方」のように、条件を変えて同じジョブを複数回まとめて実行する機能です。1つの定義で組み合わせ全パターンを検証できます。

再利用可能ワークフロー（reusable workflows）：共通のワークフローを1か所に定義し、複数のリポジトリやワークフローから呼び出す仕組みです。同じ内容のコピペが増えてきたら導入を検討します。

環境（environments）：「ステージング」「本番」といったデプロイ先を定義し、承認者のレビューを必須にしたり、環境ごとに専用のシークレットを持たせたりできます。本番デプロイの事故防止に有効です。

実行の制限：ジョブは最大6時間、ワークフロー全体は最大35日といった上限があります。長時間処理を組む前に公式の制限一覧を確認しておくと安心です。

まとめ

• CI/CDは、ビルド・テスト・デプロイという繰り返し作業を自動化する考え方です。
• GitHub ActionsはGitHub公式のCI/CDプラットフォームで、CI/CD以外の雑務自動化にも使えます。
• 用語の関係は「イベント → ワークフロー → ジョブ → ステップ → アクション」で、ジョブを実行する場所がランナーという入れ子構造です。
• ワークフローは.github/workflowsにYAMLで置きます。この場所は固定です。
• ランナーは毎回まっさらな仮想マシン。ジョブが違えばマシンも別です。
• 機密値は必ずシークレットに。コードへの直書きは厳禁です。
• パブリックリポジトリなら標準ランナーは無料。プライベートはプランごとの無料枠（Freeで月2,000分）内。
• 個人の定期バッチの無料自動化は十分可能。ただし「UTC基準」「実行時刻の遅延」「パブリックリポジトリの60日無操作で自動停止」の3点には要注意です。

まずは自分のリポジトリに.github/workflows/hello.ymlを作り、run: echo "Hello Actions"だけのワークフローを動かしてみてください。GitHubのActionsタブに緑のチェックが付く体験をすると、ここまでの用語が一気に立体的につながります。

参考リソース

• GitHub Actionsについて｜GitHub Docs … ワークフロー・イベント・ジョブ・アクション・ランナーの公式定義。最初に読むべきページです。
• GitHub Actionsのクイックスタート｜GitHub Docs … 最小のワークフローを実際に動かすチュートリアルです。
• ワークフロー構文｜GitHub Docs … YAMLで書けるすべての項目のリファレンスです。
• ワークフローをトリガーするイベント｜GitHub Docs … scheduleのcron記法や遅延の注意事項もここに記載されています。
• GitHub Actionsの課金｜GitHub Docs … プランごとの無料枠と超過時の単価の一次情報です。
• Actionsランナーの価格｜GitHub Docs … ランナー種別ごとの最新単価一覧です。
• GitHub Actionsの価格改定について｜GitHubブログ … 2026年1月からの値下げと、セルフホストランナー課金の延期に関する公式発表です。
• GitHub Actionsの制限｜GitHub Docs … ジョブ6時間などの上限値の一覧です。
• GitHub Marketplace（Actions） … 公開されているアクションを検索できる公式カタログです。
• crontab guru … cron記法が「いつ実行されるか」を日本語感覚で確認できる定番ツールです。

※本記事の料金・バージョン情報は2026年7月時点のものです。GitHubの仕様や価格は変更されることがあるため、最新情報は必ず公式ドキュメントをご確認ください。