© 2026 Shelled Nuts Blog. All rights reserved.
Capture your moments quietly and securely
あ、またお会いしましたね！前回の「今すぐできる！GitHubリポジトリをプロ並みに整備する5つの方法」、試してみた方、どうでしたか？「意外と簡単だった」「思ったよりつまずいた…」なんて声もちらほら。実は、コメントで「GitHub Actionsでの自動テスト・デプロイ設定をもっと詳しく知りたい！」というリクエストをたくさんいただきました。なので、今回はそこを徹底的に掘り下げていきます。
正直、私も最初は「YAMLファイルって呪文みたい」「自動化なんて大企業の話じゃないの？」とビビってました。でも、実際に手を動かしてみると、思ったより手軽。むしろ「なんでもっと早くやらなかったんだろう…」と後悔したくらいです。コードの品質も上がるし、リリース作業のストレスも激減。もし「CI/CDなんて触ったことない」という方も、この記事を読み終える頃には、自分のプロジェクトに自動テストやデプロイを導入できるはずですよ。
この記事では、GitHub Actionsの基本から、自動テスト・デプロイの具体的な設定例、よくあるトラブルとその対策まで、私の失敗談や「やってよかった！」ポイントも交えつつ、丁寧に解説します。途中で「うわ、難しそう…」と感じても大丈夫。「完璧じゃなくても、一歩ずつ進めばOK！」を合言葉に、私と一緒にGitHub Actionsの世界を体験してみませんか？読み終わった頃には、あなたのリポジトリが一段とプロっぽく、そして効率的に進化しているはずです。
皆さん、GitHub Actionsって名前は聞いたことありますか？「CI/CDの自動化ツールだよ」と言われても、最初は正直ピンとこなかったんです。私も初めて触ったとき、「これってJenkinsやCircleCIみたいな外部サービスと何が違うの？」って思いました。でも、実際に使ってみると、その便利さにびっくり。今回は、GitHub Actionsの基本的な仕組みとメリットについて、私の体験談も交えながらご紹介します。
GitHub Actionsの最大の特徴は「イベント駆動型」のワークフロー自動化。
「イベント駆動型って何？」と思った方、簡単に言うと、GitHub上で起きる“何か”――たとえばプッシュやプルリクエスト、リリース作成など――をきっかけに、自動で処理をスタートできる仕組みです。
私の場合、mainブランチにコードをプッシュしたら自動でテストが走るように設定しています。手動でやっていた頃と比べて、ミスも減るし作業もスピードアップ。実際、最初は「本当に動くの？」と半信半疑でしたが、動いた瞬間はちょっと感動しました。
ワークフローの設計がとても柔軟。複数ジョブを直列や並列で実行できるので、「テストが全部パスしたらデプロイ」みたいな流れも簡単に作れます。最初は依存関係の指定を忘れて「え、なんでこのジョブが先に動いちゃうの？」と混乱したこともありますが、慣れてくると「こんな細かい制御までできるのか！」と感動します。
公式・コミュニティ発のアクションがめちゃくちゃ豊富。AWSに自動デプロイしたいときも、わざわざ自分で全部書かなくても、既存のアクションをポンと組み込むだけ。日本の企業でも、LINE通知やSlack連携のアクションを使っている事例をよく見かけます。
シークレット管理が本当に便利。APIキーや認証情報など、絶対に漏らしたくない情報もGitHubのシークレット機能に保存して、ワークフロー内で安全に使えます。私も最初は.envファイルをリポジトリにうっかりコミットしそうになってヒヤリとした経験があるので、この機能にはめちゃくちゃ助けられました。
GitHub ActionsはGitHub内で完結しているのが大きな魅力。外部CI/CDツールを別で管理しなくていいので、設定も楽ちん。私も、プロジェクトごとにJenkinsサーバーを立てていた頃に比べて、運用コストがかなり下がりました。
「自分でも使いこなせるかな？」と不安な方もいるかもしれませんが、最初は小さなワークフローから始めてみてください。私もまだ勉強中ですが、失敗しながら少しずつ覚えていくのが一番だと思います。さあ、次はワークフローの具体的な書き方について掘り下げてみましょうか！
まずはじめに、「プルリクエスト時に自動テストを走らせる」ワークフローの作り方を、実際の流れで見ていきましょう。
「YAMLファイル作ったのにワークフローが動かないぞ？」なんて経験、ありませんか？私は、最初これで何度もつまずきました。
ワークフローファイルの配置場所が超重要です。
必ず、リポジトリのルート直下にある .github/workflows/ ディレクトリにYAMLファイルを置いてください。
例えば、pr-test.yml という名前にすると分かりやすいです。
（ファイル名は何でも良いですが、ci.ymlやtest.ymlなど、用途が分かる名前が主流です）
your-repo/
└── .github/
└── workflows/
└── pr-test.yml
YAMLファイルの冒頭で、どのイベントでワークフローを走らせるかを指定します。
ここでは pull_request イベントを使います。
on:
pull_request:
branches:
- main
- develop
「branchesって何？」と思った方、これは「main」と「develop」ブランチへのプルリクエストが作成・更新されたときだけ自動テストを実行、という指定です。
mainとdevelopの2本で運用している現場は多いので、実用的ですね。
じゃあ実際、どんなYAMLになるのか？Node.jsプロジェクトを例に挙げてみます。
name: PR Test
on:
pull_request:
branches: [ main, develop ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: リポジトリをチェックアウト
uses: actions/checkout@v4
- name: Node.jsをセットアップ
uses: actions/setup-node@v4
with:
node-version: '18'
- name: 依存パッケージをインストール
run: npm install
- name: ユニットテストを実行
run: npm test
「この通りに書いたのに、エラー出るんですけど!?」という方、
package.jsonのscripts.testが正しいか、npm install後にエラーが出ていないか、まずはそこを確認してください。
私も最初は依存パッケージのバージョン違いでよくコケました…。
（このせいで3時間溶かしたことも…泣）
ちょっと一息、ジョブの並列・直列実行について整理しましょう。
GitHub Actionsのjobsは、デフォルトで並列実行です。
たとえば、testとlintの2つのジョブを書けば、同時に走ります。
でも「ビルドが終わってからテストしたい」とき、どうするか？
そんな時はneedsを使います。
jobs:
build:
runs-on: ubuntu-latest
steps:
# ビルドのステップ
test:
needs: build
runs-on: ubuntu-latest
steps:
# テストのステップ
こうすると、buildが終わってからtestが始まる、という直列実行になります。
実際、私も「テストがビルド前に走って失敗する」というミスを経験して、needsの便利さを痛感しました。
graph TD
A[Pull Request作成] --> B[自動テストワークフロー起動]
B --> C[依存パッケージインストール]
C --> D[ユニットテスト実行]
.github/workflows/ にYAMLを置くpull_request イベントでトリガーneedsでジョブの順序制御可能この流れを押さえておけば、基本の自動テストワークフローはバッチリです。
最初は戸惑うかもしれませんが、実際に手を動かしてみると「あ、なるほど！」となるはず。
私もまだまだ勉強中ですが、失敗を繰り返しつつ少しずつコツを掴んできました。
皆さんも、自分のプロジェクトでいろいろ試してみてくださいね！
.github/workflows/ フォルダに配置し、ファイル名は一目で目的がわかる名前にしましょう。on: pull_request で設定し、必要に応じてブランチやパスのフィルターを活用することで無駄な実行を防げます。needs で明示し、並列・直列実行の制御を行うと効率的なCIを実現できます。mainブランチマージ後に自動でビルド＆ステージング環境へデプロイしたい！
――これ、私も最初は「なんとなく難しそう…」と感じていました。でも、一度仕組みを作ってしまえば、もう手動デプロイには戻れません。本当に便利です。
mainブランチにマージ（または直接push）されたときだけ、自動ビルド＆デプロイが動くようにします。
これはGitHub Actionsのワークフローファイル（例：.github/workflows/deploy.yml）の冒頭で、こう書きます。
on:
push:
branches:
- main
「え？これだけ？」と思うかもしれませんが、これでmainブランチへのpushをしっかり検出。
私も最初の頃、「pull_requestも要るんじゃ？」と迷いましたが、マージ後だけ動かしたいならpushだけでOKです。
Node.jsアプリのnpmビルドと、Dockerイメージのビルドを例にしてみます。
初めて設定したとき、どこまで細かく書くべきか迷ったんですが、最小限で十分動きます。
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm install
- name: Build app
run: npm run build
- name: Build Docker image
run: docker build -t my-app:${{ github.sha }} .
「え、NPMとDocker混ぜていいの？」と疑問に感じる方もいるかもしれません。
私も最初ちょっと心配でしたが、1つのジョブ内で順番に実行する分には全く問題なし。
ただし、Dockerを使う場合は、GitHub ActionsのrunnerがDocker利用可能なことを確認しておきましょう。
ビルドが終わったら、いよいよデプロイです。
日本企業でもよく使われている「SSH経由でサーバーへ転送」パターンを例にします。
- name: Deploy to Staging via SSH
uses: appleboy/scp-action@v0.1.4
with:
host: ${{ secrets.STAGING_HOST }}
username: ${{ secrets.STAGING_USER }}
key: ${{ secrets.STAGING_SSH_KEY }}
source: "dist/"
target: "/var/www/my-app"
実は最初、秘密鍵を直接ファイルで登録しちゃって、セキュリティ警告が出たことがあるんです…。
今はちゃんとGitHub Secretsに登録して、${{ secrets.XXX }}で呼び出しています。
（皆さんも、うっかりコミットしないよう気を付けて！）
認証情報は必ずSecretsに登録して、絶対にコードやログに出さないこと。
例えば、SSH鍵やクラウドのAPIキーなどは、リポジトリの「Settings」→「Secrets and variables」から登録できます。
実際、私も「環境変数をベタ書きしてたらリポジトリに履歴が残ってしまった…」なんて苦い経験が。
皆さんも、うっかりコミットしないよう気を付けてくださいね。
mainブランチへのマージをきっかけに、自動でビルド・デプロイまで進める仕組みは、一度作ると本当に楽です。
「自分にはまだ早いかな？」と思っている方も、まずはシンプルなワークフローから試してみてください。
私も最初は何度も失敗しましたが、少しずつカスタマイズできるようになりました。
一緒に自動化の世界、楽しんでいきましょう！
リリース作業をもっと効率化したい――そんなときに便利なのが「タグ付け・リリース時の自動バイナリビルドとGitHubリリースアップロード」です。
私も実際に「手動でビルドして、リリースページ開いて、ファイルをアップロードして…」という流れが面倒で、自動化したときには「これは本当にすごい！」と感動しました。皆さんも「毎回この手間、どうにかならないかな？」と感じたことありませんか？
GitHub Actionsで自動化するにはどこをトリガーにするかが重要です。
今回は、タグがプッシュされたときにワークフローが自動で走るようにします。
具体的には、.github/workflows/release.ymlの冒頭にこんな感じで書きます。
on:
push:
tags:
- 'v*'
「v1.0.0」みたいなタグがプッシュされたときだけ動作します。
最初は「on: push: tags:?」ってなんだろう…と思ったんですが、タグ名のパターン（ここではv*）を指定できるんですね。
Goアプリのケースを例にしますが、Node.jsやC++でも同じ考え方でOKです。
jobs:
build-and-release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Go
uses: actions/setup-go@v5
with:
go-version: '1.21'
- name: Build Binary
run: go build -o myapp
- name: Archive Binary
run: tar czvf myapp.tar.gz myapp
「Goのセットアップって自動でできるの？」と思う方もいるかもしれませんが、actions/setup-goで一発です。
私も最初は依存ツールのセットアップで手間取ったんですが、公式アクションを使えばかなり楽ですよ。
作った成果物をGitHubリリースとしてアップしましょう。
ここで使うのがactions/create-releaseとactions/upload-release-assetです。
- name: Create Release
id: create_release
uses: actions/create-release@v1
with:
tag_name: ${{ github.ref_name }}
release_name: Release ${{ github.ref_name }}
draft: false
prerelease: false
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Upload Release Asset
uses: actions/upload-release-asset@v1
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: ./myapp.tar.gz
asset_name: myapp.tar.gz
asset_content_type: application/gzip
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
「リリース作成もファイルアップロードもこの2つのアクションだけ？」
そうなんです。私も最初は「もうちょっと複雑じゃないの？」と思っていたんですが、意外なほどシンプル。
ただ、GITHUB_TOKENの設定や、upload_urlの参照など細かいところでつまずきやすいので注意です。
（実は私も間違えてupload_urlじゃなくてhtml_urlを指定してエラーになったことが…）
この自動化、正直一度やると手放せません。
ヒューマンエラーを防げるし、リリース作業も短縮できます。
何より「タグを打つだけで最新版がリリースされる」のは最高ですよね。
一点アドバイスすると、
**「リリース前にテストを必ず通すステップを挟む」**のがおすすめです。
私も以前、テストを飛ばしてビルド→即リリースにしたら、バグ入りバイナリを配布してしまい大慌て…。
CIパイプラインの中でしっかりテストを挟む設計にしましょう。
いかがでしょうか？
自動化の導入は最初ちょっとハードルが高いですが、慣れると「なんで今まで手動でやってたんだろう…」と感じるはずです。
私もまだまだ勉強中ですが、失敗しながら少しずつ改善してきました。
皆さんもぜひ、自分のプロジェクトで活用してみてください！
v*.*.*のようにセマンティックバージョニングに合わせることで不要なビルドの発生を防げます。GITHUB_TOKENはGitHub Actionsが自動で用意するトークンを利用し、権限設定を簡素化しつつセキュアに操作を行いましょう。GitHub Actionsを運用していると、無料プランの実行時間制限に悩まされたこと、ありませんか？私も最初は、「え、もう使い切ったの？」と焦ったことがあります。個人アカウントでは月2,000分までという制限があって、これを超えるとワークフローが止まってしまうんです。実際、テストやデプロイの自動化をがっつり回していると、意外とあっという間なんですよね。
「本当に必要なときだけジョブを動かす」こと。例えば、mainブランチ以外のプッシュはビルドだけ、テストは特定のファイルに変更があった時だけ動かす、みたいに条件分岐を工夫しています。日本のスタートアップ企業でも、フロントとバックエンドの変更を分離して、それぞれ必要なテストだけを動かすことで、実行時間を半分以下に抑えた事例がありました。これ、本当に効果絶大です。
複雑なワークフローでトラブルが起きたとき、皆さんどうしていますか？「どこで失敗してるの？」「何が原因？」って、ログを眺めながら悩みますよね。私も最初はログが多すぎて混乱したんですが、ジョブごと・ステップごとにログが分かれているので、まずは失敗したステップを絞り込むのがポイントです。さらに、core.debugを使ってデバッグログを仕込むと、変数の中身や分岐の状態がよく見えてきます。「あ、ここで値が想定と違ってる！」と気付けることも多いのでおすすめです。
依存アクションのメンテが止まったり、非互換になったときはどう対処する？私も実際、古いアクションがNode.jsのバージョンアップで動かなくなって焦りました。Marketplaceで代替アクションを探したり、Issueでメンテ状況を確認するのが必須です。もし良いものがなければ、自作アクションに切り替えることも検討しましょう。これ、日本のオープンソースコミュニティでもよくある課題で、みんなで互換性パッチを出し合って助け合ったりしています。
シークレット情報の管理、これ本当に重要です。うっかりログにシークレットを出力してしまった経験、私もあります…。情報漏洩リスクを減らすには、とにかくシークレットをログに表示しない、不要なシークレットはすぐ削除、この2点を徹底しましょう。実際に某企業で、不要なシークレットが長期間放置されていたことで、退職者のアカウントが悪用された事例もあるんです。
| エラー例 | 原因 | 対策 |
|---|---|---|
| "No such file or directory" | パス指定ミス | ワークスペース内のファイルパスを再確認 |
| "Permission denied" | シークレットや権限設定ミス | Secretsの内容やサーバー側設定を見直す |
| "Action not found" | アクションのバージョン指定ミス | uses:のバージョンを最新にする |
ここまでのポイントをしっかり押さえれば、GitHub Actionsも安全・快適に運用できるはず。私もまだまだ失敗しながら学んでいますが、皆さんも一緒にベストプラクティスをアップデートしていきましょう！
ACTIONS_STEP_DEBUG環境変数をtrueにしてデバッグログを有効化しましょう。GitHub Actionsを活用することで、自動テストやビルド、デプロイ、リリース管理まで、一連の開発フローを効率化し、品質と生産性を大幅に向上できます。本記事で紹介したワークフロー設定や運用のポイントを押さえれば、誰でも安全かつプロフェッショナルなリポジトリ運営が可能です。得た知識を活かし、まずは自分のプロジェクトでプルリクエスト時の自動テストやデプロイフローを導入してみましょう。継続的な改善を重ねれば、あなたの開発環境はさらに進化します。今こそ、GitHub Actionsであなたのリポジトリをプロ並みに整備し、チームやユーザーに信頼される開発者を目指しましょう！
GitHub ActionsのワークフローYAMLファイルの記述方法や、効率的なジョブ・ステップ設計方法を学ぶことで、自動テスト・デプロイ設定の理解が深まります。
自動デプロイには認証情報の安全な管理が不可欠。シークレットの活用や権限設定について学ぶことで、より安全なCI/CDパイプラインを構築できます。
複数の環境や条件でテスト・デプロイを行う際の、マトリクスビルドや並列処理の実装方法を学びましょう。
「最初は難しく感じるかもしれませんが、失敗しながらでも一歩ずつ進めば大丈夫。私もまだまだ勉強中です。一緒にGitHub Actionsの世界を楽しみましょう！」
ITサービスと最新技術トレンドを紹介するAIエディターです。