GitHub Actions deployment:false誤デプロイ防止術

GitHub Actionsでstagingのシークレットを使って検証したいだけなのに、deployment履歴が増えて「これ本番を触ったのかな？」と毎回確認していませんか。2026年3月に追加されたdeployment: falseを使うと、環境シークレットを使いながら“検証だけ”のCIを分離できます。この記事では、誤デプロイを防ぎつつ開発スピードを落とさない設計を、福祉事業のIT全般を担当する僕の実運用ベースで具体化します。

2026年3月更新の要点｜GitHub Actions deployment falseで何が変わったか

2026年3月19日のGitHub公式アップデートで、environment指定ジョブにdeployment: falseを設定できるようになりました。一次情報は GitHub Changelog と Control deployments です。この変更の本質は、環境シークレットは使えるのにdeployment履歴は作られない点です。

• 維持されるもの — environment secrets / vars へのアクセス
• 止まるもの — deploymentレコードの作成・更新
• そのまま有効 — required reviewers と wait timer
• 追加注意 — custom deployment protection rule とは非互換

つまり「検証のために鍵は使うけど、本番デプロイの記録は残さない」運用が可能になります。イメージとしては、ホテルのマスターキーを受け取って客室の点検はするけど、チェックイン記録は発行しない感じです。検証と配備の意味を分離できるので、GitHub Actions 誤デプロイ 防止の設計がぐっと明快になります。監査でdeployment履歴を使うチームでも、mainだけtrueに統一すれば、履歴の意味を保ったまま検証速度を落とさず回せます。

誤デプロイを防ぐ設計原則｜environment secretsと記録を分離する

運用でいちばん大事なのは、「秘密情報を使うジョブ」と「本番へ出した証跡」を別物として設計することです。これまではenvironmentを使うだけでdeploymentが自動作成されるため、検証ジョブでも本番に近い見え方になり、レビュー画面で混線しやすかったです。非ITメンバーが参加する定例だと、この曖昧さが意思決定を遅くします。

僕の現場では「staging検証はfalse」「main本番はtrue」の2層で固定しています。これだけで、誰が見ても「これは検証」「これは配備」が判別しやすくなります。CI設計の壁打ちをしたい方は、フリーランスエンジニア相談でも受けています。技術と運用言語の橋渡しを一緒に整理すると、導入の摩擦がかなり減ります。

実装テンプレート｜GitHub Actions environment secretsで「検証だけ」回す

ここはコピペして始められる最小構成です。ポイントは3つです。1つ目はdeployment: falseで検証モード化、2つ目はmainだけ記録を残す分岐、3つ目はSecrets判定をenv経由にすることです。Secretsを直接if:で読むと失敗しやすいので、公式どおりの書き方に寄せるのが安全です。

GitHub Actions deployment false 最小YAML

jobs:
  verify:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false
    env:
      API_KEY: ${{ secrets.API_KEY }}
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  deploy:
    if: ${{ github.ref_name == 'main' }}
    runs-on: ubuntu-latest
    environment:
      name: production
      deployment: ${{ github.ref_name == 'main' }}

Secrets存在チェックも合わせて入れておくと、設定漏れの検知が早くなります。

GitHub Actions environment secrets 条件分岐

env:
  SUPER_SECRET: ${{ secrets.SUPER_SECRET }}
steps:
  - if: ${{ env.SUPER_SECRET != '' }}
    run: echo "secret configured"

運用CLIはgh secret set --env staging API_KEYとgh secret list --env stagingを覚えておけば十分です。最初は1本のworkflowだけ差し替えて、1週間ログを見てから横展開する流れがおすすめです。

失敗しやすいポイント｜custom rule非互換・自動環境作成・secrets制約

導入でつまずく場所は、コードより前提条件です。とくにdeployment: falseは便利なぶん、環境設定のクセを知らないと「なぜ落ちたのか」が見えにくいです。ここだけは先に押さえると事故率が下がります。

environment名は255文字以内でリポジトリ内一意です。長い命名はtypo時の発見が遅れるので、stg-app / prd-appのように短く固定するのがおすすめです。さらに、レビュー待ちジョブは30日以内に承認されないと失敗します。待ちっぱなしの運用になりやすいチームは、期限通知を先に作ると詰まりません。

本番移行時の安全装置｜required reviewers・wait timer・branch policy・OIDC

検証運用が安定したら、本番側の安全装置を固めます。僕が実務で回しやすいと感じる順番は、承認設定→待機時間→ブランチ制限→OIDCです。required reviewersは最大6人/チームまで設定でき、実行には1名承認で進めます。厳しすぎる承認にすると詰まりやすいので、まずは「回る設計」に寄せるのが現実的です。

• required reviewers — 本番environmentだけ有効化
• wait timer — 10〜30分で急な誤操作を吸収
• branch policy — mainのみ本番許可、featureは検証専用
• OIDC — 長期鍵を減らし、都度発行トークンへ移行

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

GitHub Actionsを放置した先に待つ現実

この分離設計を入れないまま運用すると、検証ジョブと本番ジョブの境界が曖昧な状態が続きます。するとdeployment履歴の読み解きコストが毎週じわじわ増えて、レビューが形式化しやすくなります。さらにenvironment名のtypo自動作成を放置すると、保護ルールのない環境が増える可能性があります。事故は「一度の大ミス」より「曖昧さの放置」で起きやすいので、早めの線引きが結果的にいちばん楽です。小さな整備を先送りしないことが、長期運用ではいちばん効率的です。

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

僕は2026年3月28日にMac miniでのSelf-hosted Runner構築、3月29日にARC 0.14.0とdeployment:false運用の記事を公開しました。その検証で共通して見えたのが、「本番を守りながら検証速度を落とさない設計」が現場のボトルネックを外すという事実です。さらに、2025年に開発した結婚式Web招待状サービスでも、リリース後の改善を回し続けて90日以上のログイン継続率を作れました。僕自身がこの進め方で助かったからこそ、再現できる形で残したいと思って書いています。

次のアクション