ARC 0.14.0で学ぶGitHub Actions誤デプロイ防止運用

GitHub Actionsの運用が増えるほど、「テストだけ回したかったのにデプロイまで進んだ」「self-hosted runnerが詰まって待ち時間が長い」という悩みは起きやすいですよね。この記事は、GitHub Actions self-hosted runnerの設計で迷っている人に向けて、2026年3月19日にGAになったARC 0.14.0の複数ラベルと、同日に追加されたdeployment: falseを組み合わせる実践手順をまとめました。読むと、誤デプロイを抑えながら運用コストも下げる設計が見えるようになります。僕は福祉事業のIT全般を担当しつつ、AI×SaaS開発でもActionsを日常的に運用しているので、現場でそのまま使える粒度でお話しします。

なぜ今ARC 0.14.0なのか｜1ラベル設計の限界と複数ラベルの価値

2026年3月19日に公開されたARC 0.14.0のGAリリースで、runner scale setが複数ラベルを正式に扱えるようになりました。ここが今回の分岐点です。以前の運用では、runner名や1つのラベルに意味を詰め込みすぎて、runs-onの意図が読みにくくなりがちでした。つまり「どのマシンで何を回すか」がworkflow上で曖昧になり、運用者依存になっていたんです。

• 可読性の低下 — runs-on: team-aのように用途が見えにくくなる
• 再利用性の低下 — 別リポジトリで同じラベル体系を使い回しにくい
• 事故率の上昇 — 意図しないrunnerにジョブが飛びやすくなる

イメージとしては、配送センターの仕分けタグを1枚から複数枚に増やす感じです。linux、x64、gpu、buildのように意味を分解できるので、運用の読みやすさと拡張性を同時に上げやすいです。

deployment: falseの正しい理解｜環境を使うがデプロイ記録は作らない

同じく2026年3月19日のGitHub Actions更新で、environment.deployment: falseが追加されました。これで環境のsecretsやvariablesは使いつつ、不要なdeployment object作成を抑止できます。検証系ジョブで「環境値は使いたいけど、デプロイ履歴は汚したくない」という現場にかなり相性がいいです。

environment:
  name: staging
  deployment: ${{ github.ref_name == 'main' }}

ここで大事なのは、保護ルールの挙動です。公式ドキュメントでは、deployment: falseでもWait timerとRequired reviewersは適用されます。一方で、GitHub AppのCustom deployment protection ruleと併用するとジョブ失敗になります。この仕様差を知らないままだと、原因不明の失敗に見えてハマりやすいです。設定は短いですが、挙動は必ず検証環境で先に確認するのがおすすめです。

実装手順① ARC側設定｜runner scale set名・複数ラベル・スケーリング

まずはARCのvalues.yamlを整えます。最初に迷いやすいのがラベルキー名です。資料によってrunnerScaleSetLabelsとscaleSetLabelsの表記差があり、チャート世代で見え方が変わることがあります。なので、利用中チャートのvalues.yamlを先に確認してから適用してください。

githubConfigUrl: "https://github.com/your-org/your-repo"
runnerScaleSetName: "prod-shared-runners"

# 利用チャートに合わせてキー名を選択
runnerScaleSetLabels:
  - self-hosted
  - linux
  - x64
  - build
# scaleSetLabels: []  # こちらを使うチャートもある

minRunners: 20
maxRunners: 30

listenerTemplate:
  spec:
    nodeSelector:
      kubernetes.io/os: linux

1. ラベルを4層で設計 — OS / CPU / 用途 / 特殊性能に分ける
2. 最小・最大を決める — まずminRunners: 20、maxRunners: 30を叩き台にする
3. 既存runner setの整理 — 古いsetを残すなら縮退計画を先に決める

僕の現場では、ここを曖昧にすると後でジョブ詰まりが再発しました。逆に最初に命名ルールを固定すると、workflowの可読性が一気に上がります。最初の30分でラベル辞書を作るだけでも、運用負債はかなり減らせます。

実装手順② Workflow側設定｜runs-on複数ラベルとdeployment false設定

ARC側を整えたら、workflowでラベルをAND条件として使います。self-hosted runnerは全ラベル一致でマッチするので、runs-on: [self-hosted, linux, x64, build]のように属性を組み合わせるのが基本です。つまり「たまたま空いていたrunner」ではなく「意図したrunner」を選べるようになります。

name: ci-cd

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: [self-hosted, linux, x64, build]
    environment:
      name: staging
      deployment: false
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  deploy:
    if: github.ref_name == 'main'
    runs-on: [self-hosted, linux, x64, deploy]
    environment:
      name: production
      deployment: true
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

• buildラベル — テスト・ビルド専用
• deployラベル — デプロイ専用
• gpuラベル — 学習や推論など重い処理専用
• arm64ラベル — ターゲット環境互換の検証専用

イメージとしては、空港の搭乗ゲートを目的別に分ける感じです。ゲートを分けることで、乗るべき便に確実に乗れますよね。runs-onを役割ラベルまで明示するだけで、誤実行は目に見えて減ります。

誤デプロイを防ぐ運用設計｜レビュー承認・待機時間・concurrency

設定ができても、運用ルールが弱いと事故は起きます。ここでは「技術ガード」と「人の確認」を分けて設計します。僕が実際に回しているのは、次の4層です。

1. 環境レビュー — Required reviewersで承認者を固定（最大6人/チームまで設定可能）
2. Wait timer — 焦りによる誤実行を防ぐため、短い待機時間を入れる
3. concurrency — 同一環境への同時デプロイを抑止する
4. ジョブ役割分離 — testはdeployment: false、deployはtrueで明確化する

concurrency:
  group: deploy-production
  cancel-in-progress: false

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

移行チェックリスト｜既存self-hosted runnerからARC 0.14.0へ安全に移す

最後に、既存運用からの移行でハマりやすい点をチェックリスト化します。ここを飛ばすと「動くけど危ない」状態になりがちです。特に、古いrunner setのautoscaling停止はexit code 7に依存し、完全有効化は関連runner変更の「2リリース後」とされています。段階移行が前提です。

• ラベル辞書の確定 — self-hosted/linux/x64/buildのように意味を固定
• チャートキー確認 — runnerScaleSetLabels or scaleSetLabelsを実ファイルで確認
• canary導入 — 1つのworkflowだけARCへ切り替えて計測
• 待ち時間計測 — 切替前後でキュー時間を比較（週次で確認）
• 環境分離 — stagingはdeployment: false、productionはtrue
• 承認者設定 — Required reviewersとWait timerを先に有効化
• ロールバック手順 — 旧runnerへ戻す条件を文書化

移行は「一気に置換」より「可視化しながら段階移行」が安全です。この順番なら、速度を落としすぎずに誤デプロイリスクを下げられます。

deployment falseを知らないまま1年運用すると

この情報を知らないままだと、検証ジョブでも不要なデプロイ記録が積み上がり、履歴のノイズが増える可能性があります。ノイズが増えると、インシデント時に「本当に見たいデプロイ」が埋もれやすいです。さらに1ラベル設計のままだと、ジョブの意図と実行先がずれ、レビュー負荷がじわじわ上がります。危機感を煽りたいわけではなく、小さな設計差が1年後の運用コストに直結するという気づきを持ってほしいです。

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

僕自身、Mac mini M4 Pro（24GB）を24時間稼働させたモノレポ運用で、runner設計の甘さがそのまま待ち時間に跳ねる場面を何度も見てきました。福祉事業のIT全般を担当する立場では、技術者だけが分かる設計だと現場が回りません。だから、環境シークレット管理とデプロイ統制を分けられるdeployment: falseは、現場言語に翻訳しやすい仕組みだと感じています。さらに業務効率化で月80時間削減を出した経験からも、運用を「再現できる形」に落とすことが成果につながると実感しているので、このテーマを共有したかったです。

次のアクション

まずはstagingジョブ1本だけでdeployment: falseを試し、同時にruns-onを複数ラベル化してみてください。1週間の待ち時間と失敗率を比較すれば、改善ポイントがはっきり見えてきます。