Mac miniでGitHub Actionsセルフホスト構築法

「GitHub ActionsのmacOS料金が重い」「環境シークレットは使いたいけど、テストでデプロイ履歴を汚したくない」と感じている人に向けた記事です。2026年3月のアップデートで追加された deployment: false を軸に、Mac miniでGitHub Actions self-hosted runnerを運用する手順をまとめます。読了後に、誤デプロイ防止とCIコスト見直しを同時に進められる状態を目指します。

2026年3月更新で何が変わったか｜deployment: falseの実務インパクト

2026年3月19日のGitHub Actions更新で、環境を参照しつつデプロイ履歴だけ作らない設定が公式で使えるようになりました。ジョブに environment.name とあわせて deployment: false を書く形で、仕様はGitHub Docsにも明記されています。

つまり「環境シークレットは使う、でもテスト実行でデプロイ履歴は増やさない」が標準機能で実現できるようになったということです。 イメージとしては、鍵付きの会議室（Environment）には入れるけど、正式な会議ログ（Deployment record）は残さない運用です。

• 使えるもの — Environment secrets / variables
• 残る制御 — Wait timer、Required reviewers
• 残らないもの — Deployment history

jobs:
  test:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false
    steps:
      - name: Run tests with staging secrets
        env:
          API_KEY: ${{ secrets.API_KEY }}
        run: npm test

注意点は、GitHub AppsベースのCustom deployment protection ruleを有効化している環境では失敗することです。 ここはハマりやすいので、環境保護ルールを使っているチームは先に1本だけPoCワークフローを作って確認しておくと安全です。

Mac miniでself-hosted runnerを立てる手順｜登録・サービス化・ラベル設計

ここからは、Mac miniをGitHub Actions self-hosted runnerとして常駐させる手順です。公式要件ではmacOS 11以上が対象で、ARM64も利用できます。僕の環境はMac mini M4 Proで、Node.js + TypeScript + npm workspacesモノレポを常時回しています。ラベル設計まで先に決めると運用が安定します。

1. Runnerを登録 — リポジトリまたはOrganizationのRunner設定画面でトークンを発行し、Mac miniでconfigを実行します。
2. サービス化 — ログイン中だけ動く状態ではなく、再起動後も起動する形にします。
3. ラベルを統一 — self-hosted macOS ARM64 を軸にし、必要なら m4pro など機種ラベルを追加します。
4. 実行ログ監視 — 最初の1週間は失敗ジョブだけでも毎日見ます。

runs-on: [self-hosted, macOS, ARM64]

ジョブルーティング仕様も重要です。一致ラベルのrunnerがオンラインかつアイドルなら実行、60秒で拾えなければ再キュー、24時間キューに残ると失敗です。つまり、夜間にrunnerが止まると朝に失敗が並ぶことがあります。

誤デプロイを防ぐCI設計｜deployment: falseの正しい使い方

誤デプロイを防ぐなら、CIとCDを同じジョブにしないのが前提です。テスト・Lint・型チェックはEnvironmentを使って回し、実デプロイだけ別ジョブに分けます。僕は福祉事業の現場で非ITメンバーが触る管理画面を扱うことが多いので、壊れにくい導線を作って“人の注意力に依存しない”設計に寄せています。

jobs:
  ci:
    runs-on: [self-hosted, macOS, ARM64]
    environment:
      name: staging
      deployment: false
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint && npm run test && npm run typecheck

  deploy:
    needs: ci
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - run: echo "deploy"

• CI側 — シークレットは使う、履歴は作らない
• CD側 — Required reviewersを有効化し、承認後のみ進める
• 事故防止 — main直pushではなくPR経由を標準にする

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

Next.js 16.2 / TypeScript 6対応の落とし穴｜canary差分から逆算する

2026年3月はフロントエンド側の更新も大きく、Next.js 16.2（3月18日公開）とTypeScript 6.0（3月23日公開）の組み合わせを意識しないとCIが不安定になりやすい時期です。Next.js canary 16.2.1-canary.7では、TS6移行で話題になりやすい moduleResolution や baseUrl 周辺のdeprecation対応が出ています。安定版だけ見ていると差分に気づきにくいです。

僕が先に確認しているのは次の3点です。

• tsconfigの警告 — CIで tsc --noEmit を必ず実行してログ保存
• ビルドキャッシュ — .next/cache とnpmキャッシュをセットで保存
• Nodeバージョン固定 — ローカルとrunnerでズレないように揃える

- uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      ${{ github.workspace }}/.next/cache
    key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nextjs-

Mac mini CI コスト削減の試算テンプレート｜損益分岐を数字で見る

コスト判断は、まず単価を固定するとブレません。GitHub-hostedの標準料金はLinuxが$0.006/分、Windowsが$0.010/分、macOSが$0.062/分です。分単位切り上げなので、短いジョブが多いほど実質単価は上がりやすいです。self-hosted runnerの利用自体は分課金対象外です。

Mac mini M4 Pro（$1,399）をmacOS runner課金だけで回収すると、損益分岐は約22,565分です。さらに最大155Wで24時間×30日フル稼働すると111.6kWh/月なので、電気代を30円/kWhで見ると約3,348円/月です。「月にどれだけmacOSジョブを回すか」を先に数字化すれば、投資判断がかなりクリアになります。

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

運用で詰まりやすい論点｜Docker制約・保護ルール衝突・更新期限

最後に、実際の運用で止まりやすいポイントを3つに絞って共有します。ここを先回りしておくと導入後のトラブルを減らせます。

• Docker container actions / service containersの制約 — これはLinux runner前提です。Mac mini runnerだけで完結しないジョブが混ざるなら、Linux runnerとのハイブリッド構成にします。
• Environment保護ルールの衝突 — Custom deployment protection ruleがある環境にdeployment: falseをそのまま当てると失敗するケースがあります。
• Runner更新期限 — 自動更新を止める運用にした場合、新バージョン公開後30日以内に更新しないとジョブを受け取れなくなります。

スケジュール実行の時刻ズレも地味に事故要因なので、timezone指定は最初から入れておくのがおすすめです。

on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "Asia/Tokyo"

この設計を知らないまま1年過ごすと起こること

この情報を知らないままだと、テスト目的のジョブでデプロイ履歴が積み上がり、監査や障害対応の時系列が読みにくくなる可能性があります。さらに、macOSジョブをGitHub-hostedに寄せたまま運用すると、月次コストが気づかないうちに膨らみやすいです。「後から困る原因は、最初の設計でほぼ決まる」と知っておいてほしいんです。今日1本だけでもワークフローを分離して検証してみてください。

この記事を書いている理由

僕自身、Mac mini M4 Proを24時間稼働させてモノレポを回し、tmuxで長時間ジョブを監視する運用を続けています。その中で、設定が曖昧なまま走らせると、障害時に「誰が悪いか」探しになってしまう場面を何度も見てきました。結婚式Web招待状サービスで90日以上ログイン継続率を作った時も、派手な機能追加より運用導線の設計が結果を左右しました。だからこそ、誤デプロイを減らしながらコストも整えるこのテーマを今共有したいです。

次のアクション

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。