こんにちは！先輩エンジニアのDevOpsチームへようこそ。
「金曜日の夜に新機能を本番環境にリリースして、土日はヒヤヒヤしながら過ごす……」
もしあなたがそんな経験をしたことがあるなら、あるいはこれからチームで開発を始める中で「デプロイ事故が怖い」と感じているなら、今回のテーマはあなたの開発体験を根本から変える一冊の魔法書になります。
今回解説するのは、モダン開発の必須テクニックである「デプロイ（配置）とリリース（公開）の分離」、そしてそれを実現する「ダークローンチ（Dark Launch）」です。
GitHub Actionsとフィーチャーフラグ（LaunchDarklyなど）を組み合わせることで、「コードは本番にデプロイ済みだけど、ユーザーからは見えない。安全が確認できたらボタン一発（あるいは自動）で機能を一瞬で公開する」という夢のような世界を構築します。
一歩ずつ丁寧に、初心者でも絶対に挫折しない「Hello World」までガイドしますね。これをマスターすれば、毎日のデプロイ作業が劇的に楽になりますよ！
—
1. ダークローンチとフィーチャーフラグってなに？
まずは概念をスッキリ整理しましょう。難しい言葉に惑わされる必要はありません！
従来のリリース（デプロイ ＝ リリース）
コードを本番サーバーに配置（デプロイ）した瞬間に、新機能がユーザー全員に見えてしまいます。もしバグがあったら……即障害発生！冷や汗ものです。
ダークローンチ（デプロイ ≠ リリース）
コードを本番サーバーに配置しても、機能の「電源スイッチ」はOFFのままにしておきます。コードは影（Dark）の中でひっそりと出番を待ちます。これがダークローンチです。
そして、安全が確認できたタイミングで「電源スイッチ」をONにして公開します。このスイッチの役割を果たすのがフィーチャーフラグ（Feature Flag）です。
[従来の開発]
コード変更 ───> デプロイ ───> (即座にユーザーへ公開！失敗したら即障害)
[ダークローンチ]
コード変更 ───> デプロイ(スイッチOFF) ───> 内部テスト ───> スイッチON(公開！)
│
何かあればスイッチOFF(即時切り戻し)
そして、この「スイッチのON/OFF」をGitHub Actionsから自動制御するのが、今回構築するパイプラインです。
—
2. 事前準備：必要なものを揃えよう！
今回は、世界中で使われている代表的なフィーチャーフラグ管理ツール LaunchDarkly を例に進めます。（※無料トライアルで簡単に試せます）
準備するものは以下の3つだけです！
1. GitHubアカウントとテスト用リポジトリ
2. LaunchDarklyのアカウント（無料）
3. LaunchDarklyのAPIアクセスキー
手順：LaunchDarklyでAPIキーを取得する
1. LaunchDarklyにログインし、左メニューの Account settings ＞ Keys を開きます。
2. Access tokens タブから + Token をクリックし、`GitHub Actions Key` という名前でトークンを作成します。
3. ロール（権限）は `Writer`（フラグの切り替えができる権限）を設定し、生成されたアクセストークンをコピーしておきます。
—
3. GitHub Secretsに認証情報を安全に保管する
取得したAPIキーなどの機密情報は、絶対にコードに直接書いてはいけません（パブリックリポジトリなら世界中に大公開されてしまいます！）。
GitHubの「Secrets」機能を使いましょう。
1. ご自身のGitHubリポジトリを開きます。
2. Settings ＞ Secrets and variables ＞ Actions をクリック。
3. New repository secret をクリックし、以下を登録します。
- Name: `LAUNCHDARKLY_ACCESS_TOKEN`
- Secret: (先ほどコピーしたLaunchDarklyのアクセストークン)
これで、安全にGitHub ActionsからLaunchDarklyを操作する準備が整いました！
—
4. 実践！GitHub Actionsワークフローを作成する
それでは、実際に「GitHubからスイッチ（フィーチャーフラグ）をON/OFF制御する」ワークフローを書いてみましょう。
リポジトリ内に `.github/workflows/toggle-feature-flag.yml` というファイルを作成し、以下のコードを貼り付けてみてください。直感的に理解できるよう、コメントをたっぷり書いています！
name: Feature Flag Control Pipeline
1. 実行トリガーの設定
手動実行（workflow_dispatch）と、mainブランチへのPushの両方で動くように設定します。
on:
workflow_dispatch:
inputs:
flag_key:
description: ‘操作したいフィーチャーフラグのキー（例: new-checkout-flow）’
required: true
default: ‘new-checkout-flow’
flag_state:
description: ‘フラグの状態を選択してください’
required: true
type: choice
options:
- ‘turn-on’
- ‘turn-off’
push:
branches:
- main
jobs:
control-flag:
runs-on: ubuntu-latest
steps:
# ステップ1: リポジトリのコードをチェックアウト
- name: Checkout Repository
uses: actions/checkout@v4
# ステップ2: 手動実行（workflow_dispatch）の場合のフラグ制御ロジック
- name: Toggle Feature Flag via LaunchDarkly API
if: github.event_name == ‘workflow_dispatch’
run: |
# パラメータからON/OFF（true/false）を決定
if [ “${{ github.event.inputs.flag_state }}” == “turn-on” ]; then
NEW_STATE=”true”
else
NEW_STATE=”false”
fi
echo “🚀 フラグ ‘${{ github.event.inputs.flag_key }}’ を ‘${NEW_STATE}’ に変更します…”
# LaunchDarkly REST APIを叩いてフラグを操作（cURLを使用）
# ※
RESPONSE=$(curl -s -X PATCH “https://app.launchdarkly.com/api/v2/flags/default/${{ github.event.inputs.flag_key }}” \
-H “Authorization: ${{ secrets.LAUNCHDARKLY_ACCESS_TOKEN }}” \
-H “Content-Type: application/json; domain-model=johnson-json-patch” \
-d “[{\”op\”: \”replace\”, \”path\”: \”/environments/production/on\”, \”value\”: ${NEW_STATE}}]”)
echo “✅ 操作が完了しました！”
# ステップ3: デモ用の完了メッセージ表示
- name: Pipeline Success Notification
run: |
echo “🎉 CI/CD パイプラインが正常終了しました。デプロイとリリースの分離が実現されています！”
—
5. 精度高い「Hello World」動作確認！
ファイルを作成したら、`main` ブランチにコミット＆プッシュしましょう。
さあ、待ちに待った動作確認（Hello World）の時間です！
1. LaunchDarkly側でフラグを作成
1. LaunchDarklyの管理画面で Flags ＞ Create flag をクリック。
2. Nameに `New Checkout Flow` と入力（Keyが `new-checkout-flow` になることを確認）。
3. フラグを作成し、現在は「OFF」になっていることを確認します。
2. GitHub Actionsから手動でフラグを切り替える（ダークローンチの瞬間！）
1. GitHubリポジトリの Actions タブを開きます。
2. 左メニューから Feature Flag Control Pipeline を選択。
3. 右側にある Run workflow ボタンをクリック！
4. `flag_key` に `new-checkout-flow` を指定し、`flag_state` で turn-on を選択して Run workflow を実行します。
[GitHub Actions 実行画面]
Inputs:
flag_key: new-checkout-flow
flag_state: turn-on ▼
[ Run workflow ] 👈 ポチッと押す！
3. 結果を確認しよう！
ワークフローが緑色のチェックマーク（成功）になったら、LaunchDarklyの管理画面に戻ってページを更新してみてください。
……どうでしょう！？
コードを一切書き換えて再デプロイしていないのに、LaunchDarkly上の `new-checkout-flow` のスイッチが「ON」に切り替わっているはずです！
これが、デプロイとリリースが完全に分離された瞬間の感動です！
—
💡 先輩エンジニアからのワンポイントアドバイス
この仕組みをマスターしたあなたへ、さらに現場で役立つ次の一歩（プロの視点）を共有しますね。
1. エラー検知時の自動ロールバック（カナリアリリース）
今回は手動でフラグをON/OFFしましたが、DatadogやNew Relicなどの監視ツールとGitHub Actionsを連携させると、「デプロイ後にエラー率が1%を超えたら、GitHub Actionsが自動でAPIを叩いてフラグをOFFにする」という完全自動セーフティネットが構築できます。
2. コードのクリーンアップ（フラグの負債化を防ぐ）
新機能が100%定着したら、フィーチャーフラグの条件分岐コードは削除（クリーンアップ）するのが鉄則です。「フラグを作ったら消すまでのチケットを作る」習慣をチームで持ちましょう。
—
まとめ
今回の学びを振り返ってみましょう。
- デプロイ（配置）とリリース（公開）は別物として扱う。
- フィーチャーフラグを使えば、本番環境にコードを隠したまま置く（ダークローンチ）ことができる。
- GitHub Actionsと連携することで、リリース操作や緊急時の切り戻し（Rollback）が安全かつ一瞬で行える。
これで、あなたはもう「リリースの恐怖」に怯える必要はありません。昼間の好きな時間帯に安心してデプロイし、準備が整った最高のタイミングで機能を世に送り出すことができます。
最初は小さく、1つの機能からでOKです。ぜひチームのプロジェクトに組み込んで、快適なDevOpsライフを手に入れてくださいね！応援しています！