GitHub Actionsの使い方を調べると、ワークフロー、ジョブ、ステップ、runner、Secretsなど、最初に覚える言葉が多くて迷いやすいと思います。結論から言うと、GitHub ActionsはGitHub上のイベントをきっかけに、テスト、ビルド、デプロイ、通知などを自動実行するための仕組みです。
この記事では、GitHub Actionsの使い方をCI/CDの基本から整理し、実際に `.github/workflows/ci.yml` に置けるワークフロー例まで紹介します。開発者が手を動かす場面だけでなく、発注者やPMが「テストは自動化されているか」「デプロイ権限は分けられているか」「外注先の運用が属人化していないか」を確認できるように、運用設計の観点も含めて解説します。
この記事のポイント
- GitHub ActionsはGitHubのイベントを起点にテスト、ビルド、デプロイを自動化する仕組み
- 最初は `.github/workflows/ci.yml` に小さなCIを作り、pull_requestでテストを走らせる
- Secrets、permissions、concurrency、timeoutを設計しないと運用事故や無駄な実行が起きやすい
- 外注時はワークフローの有無だけでなく、誰が失敗を確認し、どの条件でリリースするかまで決める
目次
GitHub Actionsの使い方と基本構造
GitHub Actionsとは何を自動化する仕組みか
GitHub Actionsは、GitHubリポジトリ内で発生したイベントに応じて処理を自動実行する機能です。たとえば、プルリクエストが作られたらテストを実行する、mainブランチにマージされたらビルドする、リリースタグを付けたら本番デプロイする、といった作業をワークフローとして定義できます。
CI/CDの文脈では、CIは継続的インテグレーション、CDは継続的デリバリーまたは継続的デプロイを指します。GitHub Actionsを使うと、コード変更のたびにテストや静的解析を走らせ、問題がある変更を早い段階で見つけられます。デプロイまで自動化すれば、手順の抜け漏れや担当者ごとの差を減らせます。
ただし、GitHub Actionsを入れる目的は「自動化すること」ではありません。リリース前の品質確認を安定させること、レビューの待ち時間を減らすこと、障害時に誰でも同じ手順で戻せる状態を作ることが目的です。開発会社へ依頼する場合も、単に「CI/CDを入れてください」と伝えるより、どの品質条件を自動で確認したいかを伝える方が実務に合います。
ワークフロー、ジョブ、ステップの関係
GitHub Actionsの基本単位はワークフローです。ワークフローはリポジトリ内の `.github/workflows/` 配下にYAMLファイルとして置きます。1つのワークフローには複数のジョブを定義でき、各ジョブには複数のステップを並べられます。
| 要素 | 役割 | 例 |
|---|---|---|
| イベント | ワークフローを起動するきっかけ | pull_request、push、workflow_dispatch |
| ワークフロー | 自動化したい処理全体 | CI、デプロイ、定期実行 |
| ジョブ | 実行環境ごとの処理単位 | test、build、deploy |
| ステップ | ジョブ内で順番に実行する命令 | checkout、依存関係インストール、テスト |
| アクション | 再利用できる処理部品 | actions/checkout、actions/setup-node |
この構造を押さえておくと、ワークフローが長くなったときも整理しやすくなります。テスト、ビルド、デプロイをすべて1つのジョブに詰め込むと、どこで失敗したのかが分かりにくくなります。最初は小さく作り、必要に応じてジョブを分ける方が保守しやすいです。
最初に作るCIワークフロー例
まずは、プルリクエストとmainブランチへのpushでテストとビルドを実行するCIから始めるのが実務的です。Node.jsプロジェクトであれば、`.github/workflows/ci.yml` に次のようなファイルを置きます。例では2026年6月時点の現行メジャーバージョンを使っていますが、実運用では公式のリリース情報を確認して更新してください。
name: ci
on:
pull_request:
push:
branches:
- main
permissions:
contents: read
concurrency:
group: ci-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- name: Check out repository
uses: actions/checkout@v6
- name: Set up Node.js
uses: actions/setup-node@v6
with:
node-version: 22
cache: npm
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run buildこの例では、pull_requestでレビュー前の確認を行い、pushでmainに入った変更も確認します。`permissions: contents: read` は、必要以上の権限をワークフローに渡さないための設定です。`concurrency` は同じブランチで古い実行が残り続けるのを防ぎ、`timeout-minutes` は止まったジョブが無制限に走るのを防ぎます。
YAMLの構文は少しのインデントミスで壊れるため、構文の細部はGitHub Actionsの公式ワークフロー構文も確認しておくと安全です。開発会社へ依頼する場合も、ワークフローの完成物だけでなく、失敗したときのログ確認方法まで共有してもらいましょう。
pushとpull_requestをどう使い分けるか
GitHub Actionsの使い方で迷いやすいのが、どのイベントで何を実行するかです。すべてのpushで重いテストを走らせると待ち時間や利用時間が増えます。一方で、mainに入ってから初めて不具合が分かる設計では、リリース前の手戻りが大きくなります。
基本は、pull_requestではレビュー前に必要なテスト、lint、型チェック、ビルドを実行します。mainへのpushでは、マージ後の最終確認やステージング環境へのデプロイを実行します。本番デプロイは、自動実行にする場合でも環境保護ルールや承認フローを組み合わせ、誰がいつリリースを許可したかが分かる状態にしておくと安心です。
発注側の確認では、「ワークフローがありますか」だけでは足りません。pull_requestで何を止められるのか、mainに入った後に何が自動で進むのか、失敗時に誰へ通知されるのかを確認します。コードレビューの観点を整理したい場合は、コードレビューのやり方と品質基準も合わせて見ると、CIに任せる範囲と人が見る範囲を分けやすくなります。
GitHub Actionsの使い方で失敗しない運用設計
Secretsと権限を最小にする
デプロイや外部サービス連携をGitHub Actionsで行う場合、トークンやAPIキーを使う場面があります。これらをワークフローファイルへ直接書くのは避け、GitHubのSecretsや環境ごとのVariablesを使います。Secretsは便利ですが、入れれば安全というものではありません。誰が登録できるか、どの環境で使えるか、ローテーション手順があるかまで決めておく必要があります。
ワークフロー側では、`permissions` を明示して必要な権限だけを渡します。読み取りだけで済むCIに書き込み権限を渡すと、依存関係やアクションの不備があったときの影響が大きくなります。デプロイ用のジョブだけに必要な権限を与え、通常のテストジョブは読み取り中心にしておくのが基本です。
Secretsを使う処理は、pull_requestで安易に動かさないことも重要です。外部からの変更が混ざる可能性がある運用では、どのイベントでSecretsを渡すかを慎重に決めます。開発会社へ運用を任せる場合は、納品後にSecretsの所有者を自社側へ移せるか、退職者や委託先変更時に権限を棚卸しできるかも確認しましょう。
キャッシュと並列化で待ち時間を減らす
GitHub Actionsは便利ですが、実行時間が長すぎると開発の流れを止めます。Node.jsなら `actions/setup-node` の `cache: npm` を使うだけでも、依存関係の取得時間を短縮できることがあります。テストが大きいプロジェクトでは、単体テスト、型チェック、lint、ビルドをジョブに分けて並列実行する設計も検討できます。
ただし、最初から複雑な並列化を入れる必要はありません。小規模なプロジェクトでは、1つのジョブでテストとビルドを確実に通す方が分かりやすいこともあります。待ち時間が問題になってから、ボトルネックになっている処理を分ける方が運用負荷は小さくなります。
また、キャッシュは壊れた状態を抱えることがあります。依存関係更新後に不自然な失敗が続く場合は、キャッシュのキー設計や削除手順も確認します。CI/CDは自動化の仕組みであると同時に、開発チームの日常的な作業基盤です。速さだけでなく、失敗時に原因を追いやすい構成にしましょう。
デプロイ自動化は環境ごとに分ける
GitHub Actionsでデプロイまで自動化する場合、開発環境、検証環境、本番環境を同じ扱いにしないことが大切です。検証環境はmainに入ったら自動デプロイ、本番環境はタグ作成や手動承認をきっかけにする、というようにリスクに応じて分けます。
たとえば、CIが成功した後だけデプロイ用ワークフローを動かす場合は、次のような考え方になります。実際のデプロイコマンドは利用しているホスティングやクラウドによって変わるため、ここではSecretsの使い方と成功条件の見方に絞っています。
name: deploy
on:
workflow_run:
workflows:
- ci
types:
- completed
permissions:
contents: read
deployments: write
jobs:
deploy:
if: github.event.workflow_run.conclusion == 'success'
runs-on: ubuntu-latest
environment: production
timeout-minutes: 15
steps:
- name: Check out repository
uses: actions/checkout@v6
- name: Deploy application
run: npm run deploy
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}この例では、`ci` ワークフローが成功したときだけデプロイジョブへ進みます。`environment: production` を使うことで、本番環境の承認やSecretsを分ける設計にもつなげやすくなります。実際には、失敗時の通知、ロールバック手順、デプロイ対象のブランチ制限も合わせて決める必要があります。
外注開発では、デプロイ自動化の有無だけでなく、リリース判断を誰が持つかが重要です。開発会社がすべてのSecretsとリリース権限を持ったままになっていると、保守移管やベンダー変更のときに困ります。外注管理の観点は、システム開発の外注管理方法ともつながります。
ベストプラクティスは品質基準として見る
GitHub Actionsのベストプラクティスは、技術者だけの細かな作法ではありません。発注者やPMにとっては、開発会社がどの程度安全に運用できるかを確認する品質基準になります。最低限、ワークフロー名とステップ名が分かりやすいか、失敗時にログから原因を追えるか、権限が過剰でないか、実行時間が長すぎないかは見ておきたいところです。
| 確認項目 | 見るポイント | 発注側の質問例 |
|---|---|---|
| テスト範囲 | pull_requestで何を確認するか | レビュー前に止められる不具合は何ですか |
| 権限 | permissionsとSecretsの範囲 | 本番Secretsを使うジョブはどれですか |
| 実行時間 | キャッシュ、並列化、timeout | CIが遅いときの見直し方はありますか |
| 通知 | 失敗時の担当者と確認場所 | 失敗したら誰が何分以内に確認しますか |
| 移管性 | 自社で再実行・修正できるか | 納品後にワークフローを保守できますか |
この表の内容は、要件定義や契約前の確認にも入れられます。たとえば「テストは自動化します」だけではなく、「どのブランチで、どのテストを、どの条件で必須にするか」まで書いておくと、あとから認識違いが起きにくくなります。開発前の整理には、要件定義書の作り方と成果物サンプルも参考になります。
GitHub Actionsの使い方に関するよくある質問
- Q. GitHub Actionsとは何ですか？
- A. GitHub Actionsは、GitHubリポジトリ内で発生するイベント（pull_requestやpushなど）を起点に、テスト、ビルド、デプロイ、通知などを自動実行する仕組みです。CI/CDの構築に広く使われます。
- Q. GitHub ActionsでCI/CDを始めるには何から作ればよいですか？
- A. まずは `.github/workflows/ci.yml` に、pull_requestとmainブランチへのpushでテストとビルドを実行する小さなCIワークフローを作るのが実務的です。最初からpermissionsやtimeout-minutes、concurrencyも設定しておくと、運用事故や無駄な実行を防げます。
- Q. pushとpull_requestはどう使い分けますか？
- A. pull_requestではレビュー前に必要なテスト、lint、型チェック、ビルドを実行し、mainへのpushではマージ後の最終確認やステージング環境へのデプロイを実行します。本番デプロイは環境保護ルールや承認フローと組み合わせ、誰がいつリリースを許可したかが分かる状態にします。
- Q. Secretsと権限はどう管理すべきですか？
- A. APIキーやデプロイ用トークンはSecretsに登録し、ログに出さず必要なジョブだけで使います。permissionsは最小限にし、読み取りだけで足りるなら contents: read のように絞ります。外注開発では、本番Secretsの管理権を誰が持つか、運用フェーズでの引き継ぎも決めておきます。
- Q. 外注・発注時にGitHub Actionsで確認すべきことは何ですか？
- A. ワークフローの有無だけでなく、pull_requestで何を止められるか、失敗時に誰へ通知されるか、リリース条件、保守移管のしやすさ、権限が過剰でないかを確認します。これらはテスト範囲やリリース条件として要件定義や契約前の確認に含められます。
