開発ツール 2026年4月14日

GitHub Actions入門2026：よくある疑問をQ&Aで完全解説するCI/CDガイド

GitHub ActionsのCI/CD入門2026。仕組みから料金・YAML設定・自動デプロイまで、初心者がつまずく疑問7つをQ&A形式で丁寧に解説します。

GitHub ActionsCI/CD入門自動化DevOps

※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。

「CI/CDって聞くけど、結局何をしてくれるの？」

独学でプログラミングを学んでいた頃の僕も、そこがずっとモヤモヤしていました。GitとGitHubの使い方はわかった。でも、求人票に「CI/CD経験あり」と書いてある意味が、長い間ぴんとこなかったんです。

結論から言うと、GitHub Actionsはコードを変更するたびに「テスト・ビルド・デプロイ」を自動でやってくれる仕組みです。 一度設定してしまえば、手動でサーバーにファイルをアップする作業が完全になくなります。

正直、当時の僕は「テストは手動でいいじゃん」と思っていました。ところがチーム開発を始めると、「誰かのプッシュで別の人の機能が壊れる」という事態が普通に起きる。CI/CDはその問題を防ぐための仕組みです。4月の頭に久しぶりに設定手順を整理したので、この記事にまとめておきます。

CI/CDパイプラインのイメージ

よくある質問まとめ

本記事で答えていく質問は以下の7つです:

CI/CDって何？普通のGitと何が違うの？
GitHub Actionsは有料？無料枠はどのくらいある？
どんな処理を自動化できるの？
YAMLが難しい。最低限何を書けばいい？
プッシュのたびにテストを自動実行するには？
本番サーバーへのデプロイも自動化できる？
ワークフローがエラーになったとき、どうデバッグする？

Q1: CI/CDって何？普通のGitと何が違うの？

A: Gitはコードの変更履歴を管理するツールです。CI/CDはその「変更をチームで取り込む作業」に自動テストや自動デプロイを組み合わせる概念です。

CI（継続的インテグレーション）: コードを共有リポジトリにプッシュするたびに、自動でテストを走らせる。バグの早期発見が目的
CD（継続的デリバリー/デプロイ）: テストが通ったら、自動で本番環境やステージング環境にデプロイする

プログラミング的に言うと、Gitが「変更の記録」、CI/CDが「変更の検証と配信の自動化」です。

“いや、Gitって結局プッシュするだけじゃないの？“って思った人、次で書きます。GitもCI/CDも「コードを共有する」という点では同じなんですが、GitはWHATを記録し、CI/CDはHOWを自動化するという役割の違いがあります。

Git・GitHub入門：バージョン管理の基本をコードで理解する（2026年版）も合わせて読むと、GitとCI/CDの関係がより鮮明に理解できます。

Q2: GitHub Actionsは有料？無料枠はどのくらいある？

A: パブリックリポジトリなら完全無料・無制限で使えます。プライベートリポジトリは月2,000分の無料枠があります。

リポジトリ種別	無料枠	実質的な回数目安
パブリック	無制限	制限なし
プライベート（Linux）	2,000分/月	月400〜1,000回程度
プライベート（macOS）	200分/月（10倍消費）	月40〜100回程度
プライベート（Windows）	1,000分/月（2倍消費）	月200〜500回程度

個人開発・学習目的であれば、プライベートリポジトリでも2,000分は十分すぎます。一般的なNode.jsのテスト実行は2〜5分程度なので、月400〜1,000回は無料で動かせる計算です。

ここがポイントなんですが、macOSランナーは消費量が10倍なので要注意。iOSアプリ開発でmacOSを使う場合は、無料枠の消費ペースが急激に速くなります。「なんか急に課金された」という話をXで見ることがありますが、だいたいmacOSランナーの使い過ぎです。

Q3: どんな処理を自動化できるの？

A: 「コードの変更」に反応してほぼ何でも自動化できます。

よく使われる自動化の例:

テスト実行: npm test / pytest などを自動で走らせる
コードの静的解析: ESLint・Prettierでコードスタイルをチェック
ビルド: TypeScriptのコンパイル、Reactのビルドなど
デプロイ: S3・Vercel・Heroku・EC2などへの自動デプロイ
通知: SlackへのPRマージ完了通知
定期実行: 毎日0時にバッチ処理を走らせる
ドキュメント生成: テスト後にカバレッジレポートを自動生成

僕がフリーランスで参加したNext.jsのプロジェクトでは、mainブランチへのプッシュで自動的にVercelのプレビューURLが生成されて、Slackに通知が飛ぶようになっています。以前は「ビルドして、確認して、デプロイして…」という手動の手順を毎回やっていたのが、今は全部自動です。デプロイに使う時間が47分から3分になりました（47分は言い過ぎじゃない。ミスで再デプロイもあったので）。

コードレビューのベストプラクティス2026も読むと、CI/CDとコードレビューをどう組み合わせてチーム開発の品質を高めるかが理解できます。

Q4: YAMLが難しい。最低限何を書けばいい？

A: ワークフローファイル（.github/workflows/ci.yml）は、以下の最小構成で動きます。

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Node.jsのセットアップ
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: 依存関係のインストール
        run: npm ci

      - name: テストの実行
        run: npm test

構造を覚える必要があるのは4つだけです:

on: いつ動くか（pushやpull_requestなど）
jobs: 何をするか（複数のジョブを定義できる）
runs-on: どの環境で動かすか（通常はubuntu-latestでOK）
steps: 具体的な手順（上から順番に実行される）

（書いてたら思い出したんですけど、初めてGitHub Actionsを設定したとき、on: を ON: と大文字で書いてエラーが出続けていました。YAMLのキーはすべて小文字です。あと、インデントは必ずスペースで。タブを使うとparse errorになります。）

正直、最初のYAMLファイルを書くのに2時間かかりました。インデントを1つずれるだけでエラーになるので。ただ、一度動くワークフローを書けてしまえば、あとはコピペで応用できます。これは断言できます。

ターミナルでコードを書くイメージ

Q5: プッシュのたびにテストを自動実行するには？

A: 上で書いたYAMLをそのまま.github/workflows/に配置すれば、mainブランチへのプッシュとPR作成のたびにテストが自動実行されます。

もう少し実用的にするなら、依存関係のキャッシュを追加しましょう:

- name: キャッシュの設定
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

- name: 依存関係のインストール
  run: npm ci

キャッシュを入れると、package-lock.jsonが変わらない限り、インストール済みのnpmパッケージを再利用してくれます。僕の環境で試したら、キャッシュなしで3分47秒かかっていたジョブが1分12秒になりました。

ここがポイントなんですが、PRでテストが通ったものだけをマージする運用にすると、バグの混入率が劇的に下がります。 GitHubの「Branch protection rules」でPR必須+ステータスチェック必須を設定すると、テストが通らないブランチはmainにマージできない状態にできます。

Q6: 本番サーバーへのデプロイも自動化できる？

A: できます。ただし、セキュリティのためにAPIキーやパスワードは「Secrets」として登録します。

Vercelへの自動デプロイであれば:

name: Deploy to Vercel

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Vercelにデプロイ
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID }}
          vercel-project-id: ${{ secrets.PROJECT_ID }}
          vercel-args: '--prod'

SecretsはリポジトリのSettings > Secrets and variablesから設定できます。ワークフローファイル内では${{ secrets.変数名 }}で参照できるため、トークンを直接コードに書く必要がありません（絶対にコードに書いてはいけません）。

S3やEC2へのデプロイも同様に、AWS_ACCESS_KEY_IDなどをSecretsに登録して使います。AWS入門完全ガイド2026も読むと、AWSへのCI/CDデプロイのイメージが具体的になります。

Q7: ワークフローがエラーになったとき、どうデバッグする？

A: GitHubのActionsタブでログを確認するのが基本です。失敗したステップが赤くなって、詳細なエラーメッセージが表示されます。

よくあるエラーのパターンと対処法:

エラー	主な原因	対処法
`YAML parse error`	インデントのズレ・大文字小文字	YAMLバリデーターで事前チェック
`npm: command not found`	Node.jsがセットアップされていない	`actions/setup-node`を追加
`Error: ENOENT: no such file or directory`	ファイルパスのミス	`ls -la`コマンドで確認ステップを追加
`Permission denied`	SecretsやSCOPEの問題	GitHubトークンのスコープを確認
ジョブが途中で止まる	タイムアウト or 無限ループ	`timeout-minutes: 10`でタイムアウトを設定

ちょっと話逸れますが、エラーのデバッグで一番役立つのは「ワークフローのログを全部読む」ことです。エラーメッセージがかなり具体的で、「○○のコマンドが失敗しました: Exit code 1」のように書いてあります。GoogleやGPTに投げる前に、まずログを最後まで読み切ることをおすすめします。

GitHub上での作業イメージ

GitHub Actionsを学ぶためのロードマップ

ゼロから始めるなら、以下の順番が効率的です:

STEP 1: Gitが使えるようになる → Git・GitHub入門でGitの基本コマンドを覚える → pushとpull_requestの概念を理解する

STEP 2: 簡単なワークフローを書いてみる → パブリックリポジトリを1つ作り、上のサンプルYAMLをコピーして動かす → 失敗してもOK。エラーを読んで直す経験をする

STEP 3: テストを書いてCIと組み合わせる → npm testが通るプロジェクトにワークフローを追加 → PRを作ってテストが走ることを確認する

STEP 4: デプロイを自動化する → VercelかS3にデプロイする設定を追加 → mainへのマージで本番更新される環境を作る

STEP 5: 高度な設定を学ぶ → matrix（複数バージョンでテスト）、environment（本番/ステージングの分離）などを学ぶ

この順番で経験を積むと、バックエンドvsフロントエンドエンジニア：どちらを目指すべきかの記事に書いてある「インフラ知識の重要性」がずっとリアルに感じられると思います。

独学ロードマップ：未経験からエンジニア転職するための学習計画の中に「CI/CDを学ぶタイミング」も書いてあるので、全体の学習計画と組み合わせて参照してみてください。

ここまで読んでくれた人に正直に言うと

GitHub Actionsは「難しそう」と思われがちですが、実際に触ってみると思っていた以上にシンプルです。

ただ、一つだけ正直に言うと——テストがゼロの状態でCI/CDを導入しても、ほとんど意味がありません。 ワークフローは走るけど、「テストが通った」という保証がないからです。まずは小さいテストを1本書くところから始めてください。

あとこれは個人的な感覚なんですが、GitHub Actionsを使えるようになってから、コードを書くのが少し楽しくなりました。プッシュしたら自動でテストが走って、グリーンになったら「よし」という感覚がクセになるんです。

GitHub Actionsを使わない方がいいケース

“おすすめしない人”も正直に書いておきます。

1人でしか開発しない個人プロジェクト: 設定コストの割にメリットが薄い場合がある
プロトタイプ段階のコード: 構造がまだ固まっていない状態で自動化しても、設定を何度も直す羽目になる
テストが0本のコードベース: テストを書かないままCIを入れても、何も検証できない
毎回手動デプロイで10秒以内に終わる規模: オーバーエンジニアリングになる可能性

ぶっちゃけ、シンプルな静的サイトをGitHubにプッシュするだけのプロジェクトだったら、VercelのGitHub連携で十分です。CI/CDが本当に威力を発揮するのは、テストがあって、複数人が開発していて、デプロイが頻繁に起きる状況です。

よくある質問

Q: GitHub ActionsとJenkinsはどう違うの？

A: JenkinsはGitHubが登場する前から使われてきたCI/CDツールで、自前サーバーへのインストールが必要です。GitHub Actionsは完全マネージドで、GitHubのリポジトリにYAMLを置くだけで動きます。2026年現在、個人開発〜中規模チームはGitHub Actionsが主流です。既存のJenkins環境がある大企業ではJenkinsが残っているケースもありますが、新規導入ならActionsを選ぶのが自然です。

Q: GitHub Actionsのワークフローのテンプレートはある？

A: あります。リポジトリのActionsタブを開くと、言語・フレームワークごとのテンプレートが選べます。Node.js・Python・Go・Java・Dockerなど主要な構成のテンプレートが用意されているので、まずはそれをコピーして使うのが一番早いです。「テンプレートを選んでコミットするだけ」で動く状態になります。

Q: GitHub Actions以外でCI/CDを無料で使うなら？

A: GitLab CI（GitLab利用者向け、400分/月無料）、CircleCI（月2,500分の無料枠）などがあります。GitHubを使っているなら、GitHub Actionsが一番シームレスに使えます。特別な理由（既存のCircleCIの設定を引き継ぐなど）がない限り、Actionsから始めるのが無難です。

Q: ワークフローの実行時間を短くする一番効果的な方法は？

A: 依存関係のキャッシュを使うことです。actions/cacheアクションでnode_modulesをキャッシュするだけで、実行時間が半分以下になることも多いです。僕の環境では3分47秒→1分12秒になりました。他には、並列実行（needsを使わずに複数ジョブを同時実行）やDockerイメージのキャッシュも効果的です。

Q: プライベートリポジトリで無料枠を使い切った場合はどうなる？

A: ワークフローが実行されなくなります（エラーで止まる）。課金設定をしていなければ自動的に課金されることはないので、「急に請求が来た」という事態は起きません。ただし、チームの開発が止まるので、無料枠の残量は定期的に確認することをおすすめします。

追記（2026/04/12）

GitHubがActionsのmacOSランナーの料金体系を改定しました。macOS M1/M2ランナーはLinuxの10倍ではなく、用途によって異なる倍率が設定されるようになっています。iOSアプリ開発でActionsを使っている方は、公式のBillingページで消費量を定期的に確認することをおすすめします。

また、Actionsのキャッシュの最大容量が10GBから引き上げられた（リポジトリごと）というアップデートがありました。大規模なプロジェクトでキャッシュの上限に悩んでいた方には朗報です。

この記事を書いた人: 中村ソウマ / フリーランスフロントエンドエンジニア。文系・営業職→独学8ヶ月でエンジニア転職。React/Next.js専門。