こんにちは、かつコーチです。
Pull Requestを出すたびに、テストの実行やLintのチェックを手動でやっていませんか。
毎回同じコマンドを打つ作業は、地味に時間を奪われますし、うっかり忘れてしまうこともあります。
この記事では、そうした繰り返し作業を自動化してくれるGitHub Actionsについて、仕組みの基本から解説します。
GitHub Actionsとは？
センサーで反応する自動ドアのような仕組み
GitHub Actionsとは、リポジトリへのpushやPull Requestの作成といった「できごと」をきっかけに、あらかじめ決めた処理を自動で実行してくれるGitHub標準の機能です。
たとえるなら、GitHub Actionsは商業施設の入り口にある自動ドアだとイメージしてください。
自動ドアは、人がセンサーの前を通るという「できごと」に反応して、勝手に開くという「決められた処理」を実行します。
人がいちいちドアを手で開ける必要はありません。
GitHub Actionsも同じで、「mainブランチにpushされた」「Pull Requestが作られた」といったできごとをセンサーのように検知し、テストの実行やビルドといった処理を自動で行ってくれます。
なぜGitHub Actionsが必要なのか
手動でのチェックには、以下のような課題があります。
- 実行するコマンドを忘れる、あるいは打ち間違える
- ローカル環境によって結果が変わってしまう
- チームメンバー全員が同じ手順を毎回徹底するのは現実的に難しい
GitHub Actionsを使えば、決められた手順を毎回同じ条件で、人の手を介さずに実行できます。
自動ドアが「開け忘れる」ことがないのと同じように、CI（継続的インテグレーション）のチェックを漏れなく実行できる点が最大のメリットです。
基本の仕組み：ワークフローの構成要素
ワークフローファイルの置き場所
GitHub Actionsの設定は、リポジトリの.github/workflows/ディレクトリにYAMLファイルとして配置します。
$ mkdir -p .github/workflows
$ touch .github/workflows/ci.yml
このディレクトリに置かれたYAMLファイルが、そのまま自動ドアの「センサーと動作のルール」として認識されます。
トリガー（on）＝センサーが反応する条件
onキーで、どんな「できごと」に反応させるかを指定します。
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
この設定は、「mainへのpush」または「mainへ向けたPull Requestの作成・更新」というできごとに反応するセンサーを設置している状態です。
ジョブとステップ（jobs / steps）＝ドアが開いた後の動作
jobsの中に、実際に実行する処理をstepsとして順番に並べます。
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: リポジトリを取得
uses: actions/checkout@v4
- name: Node.jsをセットアップ
uses: actions/setup-node@v4
with:
node-version: "20"
- name: 依存パッケージをインストール
run: npm ci
- name: Lintを実行
run: npm run lint
runs-onで実行環境（ここではUbuntu）を指定し、stepsで「環境を用意する」「依存関係をインストールする」「チェックを実行する」という一連の動作を定義しています。
自動ドアでいえば、センサーが反応した後に「ドアを開く」「照明をつける」「案内音声を流す」といった複数の動作を順番にこなしているイメージです。
つまずきやすい設定・注意点
usesで指定する外部アクション（actions/checkout@v4など）は、必ずバージョンを固定してください。
バージョンを指定せずに@mainのような可変参照を使うと、外部のアクションが更新された際に、意図しない動作変更が突然ワークフローに影響することがあります。
よくあるつまずきポイント・エラー対処
インデントのズレでワークフローが認識されなかった話
私が最初にGitHub Actionsを設定したとき、YAMLのインデントを1つずらしてしまい、ワークフローが一切実行されないという事態にはまりました。
❌ Before：stepsのインデントが揃っていない
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
このファイルをpushしても、GitHubのActionsタブには何も表示されず、エラーメッセージすら出ないため、最初は原因の見当がつきませんでした。
センサーの配線がそもそも間違っていて、ドアの前を通っても何も反応していない状態です。
✅ After：steps配下のインデントを2スペースで統一する
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
YAMLはインデントの深さで階層構造を表すため、1文字でもずれると構文として成立しなくなります。
以降は、エディタのYAML拡張機能による構文チェックを必ず有効にしてから編集するようにしています。
応用・一歩先の使い方
Actionsタブで実行結果を確認する
ワークフローを設定したら、リポジトリの「Actions」タブから実行履歴とログを確認できます。
失敗した場合は、どのstepでどんなエラーが出たかがログにそのまま表示されるため、原因調査がしやすい設計になっています。
secretsで機密情報を安全に扱う
デプロイ用のトークンやAPIキーなど、コードに直接書けない情報は、リポジトリのSettings > Secretsに登録し、ワークフロー内で${{ secrets.API_KEY }}のように参照します。
これにより、機密情報をコード上に露出させずに自動化処理へ渡せます。
次の記事では、このワークフローの仕組みを使って、実際にテストを自動化する具体的な流れを解説します。
まとめ
この記事のポイント
- GitHub Actionsは、センサーで反応する自動ドアのように、pushやPull Requestといったできごとに反応して処理を自動実行する仕組み
- 設定は
.github/workflows/にYAMLファイルとして置く onでトリガー、jobsとstepsで実行内容を定義する- 外部アクションはバージョンを固定し、YAMLのインデントミスに注意する
次に読むべき記事
仕組みが分かったら、次は「簡単なワークフローを書いてテストを自動化する」で、実際に動くテスト自動化の設定を作ってみましょう。