GitHub Actionsって何だろう？

「コードをpushしたら、あとは全部自動で動く」——そんな開発スタイルに憧れていませんか？それを実現してくれるのがGitHub Actionsです。

GitHub Actionsは、GitHubが提供するCI/CD（継続的インテグレーション／継続的デリバリー）の仕組みです。リポジトリに特定のイベント（pushやPRの作成など）が起きたときに、あらかじめ定義した処理を自動実行してくれます。

CI/CDという言葉を分解すると：

• CI（Continuous Integration）： コードを統合するたびに自動でテストを走らせる
• CD（Continuous Delivery/Deployment）： テストが通ったら自動でデプロイまで行う

要するに「push → テスト → デプロイ」という一連の流れを人間が手動でやらなくて済むようにする仕組みです。組み込み系のエンジニアをやっていると、ビルドやフラッシュ作業を手動で何度も繰り返す場面が多いので、この自動化の恩恵は非常に大きいと感じました😊

ワークフローファイルの基本構造

GitHub Actionsの設定は、リポジトリの .github/workflows/ ディレクトリに置いた YAMLファイルで書きます。このファイルを「ワークフロー」と呼びます。

まず最もシンプルな例から見てみましょう。mainブランチにpushされたとき、Pythonのテストを自動実行するワークフローです。

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: リポジトリをチェックアウト
        uses: actions/checkout@v4

      - name: Pythonをセットアップ
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: 依存パッケージをインストール
        run: pip install -r requirements.txt

      - name: テストを実行
        run: python -m pytest tests/

ポイントをまとめると：

• on: → どのイベントで動かすか（pushやpull_requestなど）
• jobs: → 実行する処理のまとまり
• runs-on: → 実行環境（ubuntu-latest、windows-latest、macos-latestから選べる）
• steps: → 実際に実行するコマンドや処理の手順

YAMLのインデントに少し慣れが必要でしたが、構造自体はわかりやすかったです。

よく使うトリガーとActionの一覧

ワークフローを組んでいると、「どんなイベントで起動できるの？」という疑問が出てきます。主要なトリガーをまとめました。

uses: actions/〇〇 で呼び出す公式Actionも豊富で、チェックアウト・言語のセットアップ・Dockerビルドなど、よくある処理はほぼActionとして提供されています。Marketplaceで検索するとサードパーティ製も大量に出てきます。

テストからデプロイまでつなげてみる

テストが通ったら自動でデプロイまで行うフローも作ってみました。ここでは、Pythonスクリプトをビルドしてサーバーにrsyncで転送する例です。

# .github/workflows/deploy.yml
name: Deploy Pipeline

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install -r requirements.txt
      - run: python -m pytest tests/

  deploy:
    runs-on: ubuntu-latest
    needs: test  # testジョブが成功した場合のみ実行
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: デプロイスクリプトを実行
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}  # シークレットから読み込む
        run: |
          echo "$DEPLOY_KEY" > deploy_key
          chmod 600 deploy_key
          rsync -avz -e "ssh -i deploy_key" ./src/ user@example.com:/app/

重要なポイントは needs: test の部分です。これを書くことで「testジョブが成功しないとdeployジョブは動かない」という直列の依存関係を作れます。テストが失敗したまま本番にデプロイされる事故を防げますね。

また、パスワードやAPIキーは secrets.〇〇 で参照します。GitHubのリポジトリ設定から Settings → Secrets and variables → Actions で登録しておくと、ワークフロー内で安全に使えます。ソースコードに直接書かなくていいのが安心です。

開発体験はどう変わるか

実際にGitHub Actionsを導入してみて感じた変化は大きかったです。

これまでは「コードを書く → ローカルでテスト → 手動でサーバーに転送 → 動作確認」という流れを毎回手動でやっていました。特にデプロイ作業は手順をミスると戻すのが面倒で、精神的なコストがじわじわ積み重なっていたんですよね😊

GitHub Actionsを導入してからは「pushすれば終わり」です。あとは数分待てばGitHubのActionsタブで結果が緑（成功）か赤（失敗）かを確認するだけ。失敗した場合はログをそのまま見れるので、原因の特定も速くなりました。

組み込みエンジニアの観点からすると、マイコンのファームウェアビルドもCIで自動化できます。ARM GCC toolchainをインストールするステップを書いておけば、pushのたびにバイナリが自動生成されてArtifactsとして保存されます。チームで開発するときのビルド環境の統一にも使えるので、「自分のマシンではビルドできるのに」問題が減ります。

ブログ自動投稿システムとの関係

実はこのブログ自体、毎日の記事生成・投稿を自動化するシステムを自分で作って運用しています。macOSのlaunchdを使って毎朝9時にPythonスクリプトを走らせ、Claude APIで記事を生成してCloudflare Pagesにデプロイ、さらにInstagramとXにも自動投稿する仕組みです。

今回GitHub Actionsを触ってみて「これ、ブログの自動投稿にも使えるな」と思いました。現状はmacローカルで動いているため、Macの電源が落ちていたり眠っていたりするとスキップされてしまう問題があります。GitHub Actionsの schedule トリガーを使えば、クラウド上で確実に定時実行できます。

ローカルのlaunchdからGitHub ActionsのCI/CDへの移行は、今後やってみたいことの一つです。自動化の仕組みを学ぶほど「もっと自動化できるじゃないか」と欲が出てくるのが面白いですね。CI/CDは最初の設定に少し手間がかかりますが、一度動き出すと毎回の手作業から解放されるメリットはとても大きいです。ぜひ試してみてください😊

それでは、今回はここまで。ありがとうございました😊