【2026年版】GitHub Actionsの始め方 — CI/CDを自動化する完全ガイド

ワークフローの基本構造

# .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: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

よく使うアクション早見表

シークレットの使い方:

- name: Deploy
  env:
    API_KEY: ${{ secrets.API_KEY }}   # リポジトリのSecretsから参照
  run: ./deploy.sh

よくある詰まりポイント

Q: ワークフローが動かない → まず .github/workflows/ ディレクトリに正しくYAMLが配置されているか確認。YAMLのインデントミスが多いため、VSCodeのYAML拡張機能を使うと構文エラーを事前に検出できます。

Q: シークレットをログに出力してしまいそうで怖い → GitHub ActionsはSecretsの値をログで自動的にマスクします。ただし base64 エンコードなどで変形した値はマスクされないので注意が必要です。

Q: 実行時間が長すぎる → actions/cache で node_modules や .pip をキャッシュすると大幅に短縮できます。ジョブを並列実行（needs を外す）するのも有効です。

ひよこ

GitHub Actionsってよく聞くけど、何ができるの？

ペンギン先生

簡単に言うと、GitHubにコードをpushしたりプルリクエストを出したときに、テストやデプロイを自動で実行してくれる仕組みだよ。これがいわゆるCI/CD、つまり「継続的インテグレーション・継続的デリバリー」ってやつだね。

ひよこ

CI/CDって難しそうだけど、具体的にはどういうことなの？

ペンギン先生

CIは「コードを変更するたびに自動でテストを走らせて、壊れてないか確認する」こと。CDは「テストが通ったら自動で本番環境にデプロイする」こと。手作業でやると忘れたりミスしたりするけど、GitHub Actionsに任せればpushするだけで全部やってくれるんだよ。

ひよこ

便利だね！でもどうやって設定するの？

ペンギン先生

リポジトリの中に「.github/workflows」というフォルダを作って、そこにYAMLファイルを置くだけだよ。このYAMLファイルが「ワークフロー」と呼ばれていて、いつ・何を・どの順番で実行するかを定義するんだ。ファイル名は自由だけど、ci.ymlとかdeploy.ymlみたいに分かりやすい名前を付けるのがおすすめだね。

ペンギン先生

ここで実際に試してみてね。GitHubリポジトリに「.github/workflows/hello.yml」を作って、「on: push」「jobs: say-hello: runs-on: ubuntu-latest steps: - run: echo 'Hello Actions!'」という最小構成を書いてpushしてみよう。ActionsタブでワークフローがGreen（✓）になれば成功だよ！

ひよこ

ワークフローの中身ってどんな構造になっているの？

ペンギン先生

大きく3つの要素があるよ。まず「トリガー」で、いつワークフローを動かすかを決める。pushしたとき、プルリクエストが作られたとき、スケジュールで定期実行、なんかが選べるね。次に「ジョブ」で、実行する作業のまとまり。そしてジョブの中に「ステップ」があって、具体的なコマンドを1つずつ書いていくんだよ。

ひよこ

トリガーにスケジュールもあるんだね！毎日決まった時間にテストを走らせたりもできるの？

ペンギン先生

そうそう、cron形式で指定できるよ。たとえば毎日朝9時に依存パッケージの脆弱性チェックを自動で走らせる、みたいな使い方ができるね。他にも特定のブランチやタグへのpushだけをトリガーにしたり、手動実行のworkflow_dispatchっていうトリガーもあるよ。

ひよこ

ジョブとステップの関係がまだちょっと分からないかな？

ペンギン先生

たとえばテストジョブとデプロイジョブを分けるとするよね。テストジョブの中には「コードをチェックアウトする」「依存パッケージをインストールする」「テストを実行する」という3つのステップがある。デプロイジョブには「ビルドする」「サーバーにアップロードする」というステップがある。ジョブ同士は並列で動かしたり、テストが通ってからデプロイする、みたいに順序を指定したりもできるんだよ。

ひよこ

全部自分で書かなきゃいけないの？大変そう…

ペンギン先生

そこで便利なのがMarketplaceだよ！よく使う処理は「アクション」としてコミュニティが公開していて、たとえばNode.jsのセットアップ、AWSへのデプロイ、Slackへの通知なんかは公式やサードパーティのアクションを1行書くだけで使えるんだ。ワークフローのステップでusesキーワードを使って指定するだけだよ。

ひよこ

APIキーとかパスワードはどうやって管理するの？ワークフローに直接書いたら危ないよね？

ペンギン先生

いい質問だね！GitHubにはSecretsという機能があって、リポジトリの設定画面から暗号化された状態で登録できるよ。ワークフローの中ではsecretsという特別な変数でアクセスするんだ。ログにも表示されないし、フォークしたリポジトリからも見えないように設計されているから安心だよ。本番のデプロイキーやAPI トークンは必ずSecretsに入れようね。

ひよこ

Node.js 18と20の両方でテストしたいときとかはどうするの？

ペンギン先生

それは「マトリクスビルド」の出番だね。strategyのmatrixで、Node.jsのバージョンとかOSの種類を配列で指定すると、全組み合わせで自動的にジョブが並列実行されるんだよ。たとえばNode.js 18と20、Ubuntu とWindowsの組み合わせなら4つのジョブが同時に走る。クロスプラットフォームのライブラリ開発では必須のテクニックだね。

ひよこ

毎回パッケージインストールすると時間がかかりそうだけど、何か対策はあるの？

ペンギン先生

キャッシュを活用すると劇的に速くなるよ。actions/cacheというアクションを使えば、node_modulesや各種パッケージマネージャのキャッシュを保存して次回以降のワークフローで再利用できるんだ。npm ciで毎回3分かかっていたのがキャッシュヒットで10秒になる、なんてことも珍しくないよ。2026年現在ではactions/setup-nodeなどのセットアップ系アクションにキャッシュ機能が組み込まれているから、さらに簡単になっているね。

ひよこ

実際に始めるとしたら、最初に作るワークフローはどんなものがおすすめなの？

ペンギン先生

まずはpushとプルリクエストをトリガーにしたテスト自動実行ワークフローがおすすめだよ。コードのチェックアウト、Node.jsのセットアップ、依存パッケージのインストール、テスト実行、という4ステップだけで十分実用的なCIが組めるんだ。慣れてきたらリンターやフォーマッターのチェック、mainブランチへのマージ時に自動デプロイ、といった具合にステップを追加していけばいいよ。小さく始めて育てていくのがコツだね。