リリースとデプロイの違いは？コードを置くことと公開することを整理

先に要点

デプロイは「コードを実行環境へ置く」、リリースは「ユーザーが実際に使える状態にする」。この2つは別物で、デプロイ済み・未リリースという状態は普通に存在します。
feature flag・段階公開・ステージング・承認フローがあると2つははっきり分かれ、デプロイは自動・リリースは人の判断、という構成になります。
事故は「デプロイ済み=もう公開済み」という認識ずれから起きます。Slack やチケットでの表記を統一するだけで、確認漏れと誤操作が大きく減ります。
ローンチ(外向きの告知・世に出す)との違いとは別軸の話です。本記事はあくまで「環境への配置」と「ユーザーへの有効化」という運用上の段階を扱います。

「リリースした」と「デプロイした」は、現場では似た意味で使われることがあります。小さなチームや単純なサイトなら、たしかに同じ日に同じ作業として起きることも多いです。

でも、本来は同じ言葉ではありません。この違いが曖昧なままだと、会話の中で「もう本番に入ったのか」「まだユーザーには見えていないのか」「確認待ちなのか」が分からなくなります。そしてこの曖昧さは、後半で紹介する「片方は本番公開済みだと思い、もう片方はまだフラグ OFF だと思っていた」という種類の事故に直結します。

この記事では、デプロイとリリースの違いを、実際の Slack 表記・ChatOps コマンド・認識ずれ事故の例まで含めて、実務で使える形に整理します。LaunchDarkly の deployment / release ドキュメント、GitLab の feature flag ChatOps 運用ドキュメントを確認しながら書いています。

まず一言でいうと

最初に一番短く言うと、こうです。

デプロイ (deploy)

コードを動く場所へ「置く」こと。サーバーへ配置する、コンテナイメージを入れ替える、関数の新バージョンを登録する、といった技術作業。ユーザーに見えるかどうかはまだ本質ではありません。

リリース (release)

そのコードを「ユーザーが実際に使える」状態にすること。フラグを ON にする、10% へ段階公開する、ベータ参加者へ開放する。顧客体験が変わる瞬間です。

たとえば、新機能のコードを本番サーバーに配置したけれど、feature flag でまだ無効のままなら、それは「デプロイ済み・未リリース」です。逆に、すでに本番に置いてあった機能を feature flag で一部ユーザーへ有効化したなら、その瞬間がリリースです。

LaunchDarkly のドキュメントでも、deploy は「ある環境に新しいソフトウェアバージョンを導入すること」、release は「その環境でソフトウェアをユーザーが利用できるようにすること」と、明確に分けて説明されています。feature flag の本質的な価値は、この2つを切り離せること(decouple deploy from release)にあります。

デプロイとは何か

デプロイは、技術的には次のような作業に近いです。

サーバーへ新しいアプリを配置する
コンテナイメージを入れ替える
ビルド済みファイルを本番環境へ反映する
関数やジョブの新バージョンを登録する

ここでは「ユーザーに見えるか」はまだ本質ではありません。まずは「コードがその環境に存在するか」がポイントです。

具体的なイメージとして、GitHub Actions でのデプロイ完了ログはこう見えます。

Run actions/deploy@v4
✓ Build succeeded (commit a1b2c3d)
✓ Uploaded 142 files to production bucket
✓ Invalidated CDN cache (distribution E2XXXX)
Deployment complete: https://app.example.com (live in 38s)

このログが緑になった瞬間に「公開された」と思い込みがちですが、新機能が feature flag の裏に隠れていれば、ユーザーにはまだ何も起きていません。デプロイが完了しても、それはコードが本番に「置かれた」だけです。

リリースとは何か

一方リリースは、ユーザー視点の出来事です。たとえば、

feature flag をオンにする
10% のユーザーへ段階公開する
ベータ参加者だけ使えるようにする
承認後に本番で表示を切り替える

のような瞬間がリリースです。

リリースは技術作業だけでなく、プロダクト判断や運用判断も含みやすい言葉です。「いつ出すか」「誰に出すか」「問題が出たら止めるか」は、デプロイのようにビルドが通れば終わり、という話ではありません。

GitLab のように規模の大きい開発では、本番のフラグ操作そのものが Slack の ChatOps コマンドで行われます。たとえば全ユーザーへ有効化するなら次のように打ちます。

/chatops gitlab run feature set some_feature true

25% のアクター(ユーザーやプロジェクト)だけに段階公開するなら、こうです。

/chatops gitlab run feature set some_feature 25 --actors

この「コマンドを打った瞬間」がリリースであって、コードのデプロイとは別のイベントとして扱われています。GitLab の運用では、この本番フラグ操作は専用の #production チャンネルで実行し、誰が・いつ・どのフラグを操作したかが自動で監査ログ(専用 issue と features_json.log)に残るようになっています。リリースが「記録すべき独立したイベント」として扱われていることが分かります。

「デプロイ済み・未リリース」をチームでどう表記するか

ここが実務で一番効く部分です。状態を口頭の「あれ、もう出てる?」で済ませると、ほぼ確実に認識がずれます。Slack やチケットでは、「どこに置かれたか(配置)」と「誰が使えるか(公開)」を必ず分けて書くのが基本です。

おすすめは、状態を1行で表せる短いタグ表記をチームで決めておくことです。

状態	Slack / チケット表記の例	意味
本番へ配置だけ済んだ	[deployed / flag:OFF]	コードは本番にあるが、ユーザーには未公開
社内・一部だけ公開	[released 10% / internal]	一部ユーザーのみ有効。観察フェーズ
全体公開済み	[released 100%]	全ユーザーに有効化済み
公開だけ取り消した	[flag:OFF / code still deployed]	フラグは戻したが、コードは本番に残っている

ポイントは、deployed と released を別の単語として固定し、flag:OFF/ON と 10% / 100% を必ず添えることです。「リリースしました」だけだと、全体なのか一部なのか、コードの話なのか公開の話なのかが伝わりません。リリース対象の状態(配置先・公開範囲・フラグ状態)をワンセットで書くと、後から流れを追う人も含めて誤解が激減します。

Slack の運用テンプレートとしては、新機能の本番投入時にスレッドの先頭へこう貼っておくと安全です。

機能: 新チェックアウト画面
状態: [deployed / flag:OFF]   ← 本番にコードはあるが未公開
公開予定: 6/16 10:00 に internal → 翌日 10% → 全体
フラグ名: new_checkout_ui
止め方: /chatops ... feature set new_checkout_ui false(即時 OFF）

認識ずれで起きる事故の例(現象→原因→確認手順→回避)

実際に起きやすいのが、「デプロイ=公開済み」という思い込みからの事故です。1つ典型例を、現象から回避策まで分解します。

現象

エンジニア A が新決済画面を本番へデプロイし、Slack に「新決済、本番にリリースしました」と投稿。サポートとマーケはこれを「公開済み」と解釈し、ユーザー向けの告知メールを送信。ところが実際にはフラグ OFF のままで、メールのリンク先には旧画面しか出ず、問い合わせが殺到した。

原因

A の言う「リリース」は「本番へデプロイ完了」の意味だったが、受け手は「ユーザーが使える状態」と解釈した。deployed と released を同じ言葉で運用していたため、フラグの状態(OFF)が会話のどこにも書かれていなかった。

確認手順(同じ事故を見つける・防ぐ初動)は次の通りです。

読み込み中...

回避策はシンプルで、前章のタグ表記を徹底することです。A が最初から「新決済、[deployed / flag:OFF]、公開は明日10時から段階的に」と書いていれば、サポートもマーケも告知を前倒しせず、事故は起きませんでした。released という単語を「フラグ ON でユーザーが使える状態」だけに限定して使うルールが、最も安いコストの再発防止策です。

なぜ同じに見えやすいのか

この2つが混ざりやすい理由は、単純な構成では同じタイミングで起きるからです。小さな Web サイトで「サーバーへ反映する → その瞬間に新画面が見える」なら、デプロイした瞬間がそのままリリースです。この場合、言葉を厳密に分けなくても会話が回ります。

でも、少し運用が大きくなると事情が変わります。違いがはっきり出るのは、次の3つの場面です。

1. feature flag を使うとき

これが一番分かりやすいです。コードをデプロイしても、フラグをオンにするまでは機能を有効化しません。

水曜日に本番へデプロイ(deployed / flag:OFF)
金曜日に一部ユーザーへ公開(released 10%)

このとき、水曜日はデプロイ、金曜日がリリースです。コードは1度きりの配置でも、公開イベントは別の日に独立して起きています。

2. ステージング環境を挟むとき

ステージング環境では、コードを先に配置して確認します。でも、その段階ではまだ一般ユーザーは使えません。

ステージングへデプロイ → 確認 → 本番へデプロイ → 承認後に公開

という流れの中で、デプロイは複数回あっても、リリースは最後の公開タイミングだけ、ということがあります。ステージングの役割を広く見たい場合はステージング環境とは？本番環境との違い・必要性を初心者向けに解説もつながります。

3. 段階公開やカナリア公開をするとき

最初は社内だけ、次に 10%、最後に全体公開、という流れでは、コード自体はすでに本番へ入っていても、リリースは段階的に進みます。この場合は「デプロイは1回でも、リリースは複数段階」という見方になります。前述の 25 --actors のようなコマンドは、まさにこの段階リリースを刻むための操作です。

よくある誤解

デプロイしたら必ずリリース済み

これは必ずしも正しくありません。feature flag や設定切り替えがあるなら、デプロイ済みでも未公開の状態は普通です。前章の事故は、まさにこの誤解が原因でした。

リリースはエンジニアだけの仕事

小さな開発ではそう見えやすいですが、実際にはプロダクト・QA・サポート・マーケティングが関わることもあります。ユーザーへいつ出すか、誰へ出すか、問題があれば止めるか、という判断は技術だけでは決まりません。

リリースとローンチは同じ

近い意味で使われることはありますが、ローンチはより外向きで、告知や営業、広報を含めた「世に出す」感覚で使われやすい言葉です。本記事で扱っているデプロイ/リリースは、あくまで環境への配置と、ユーザーへの機能有効化という運用上の段階の話です。

つまり軸が違います。デプロイ/リリースは「コードがどこにあり、誰が使えるか」という内部の状態遷移、ローンチ/リリースは「内部の公開」と「外向きの告知」の違いです。同じ「リリース」という単語が両方の比較で出てくるため混乱しますが、この記事ではプロダクトの告知戦略やプレスリリースの話は扱いません。外向き公開や告知との違いまで整理したい場合は、ローンチとリリースはどう違うのか？外向き公開との違いを整理を参照してください。前章の事故で「告知メールを止める」が回避策に出てきたのは、まさにリリース(機能有効化)とローンチ(告知)を別々に管理すべきだからです。

実務でどう使い分けると分かりやすいか

会話では、次のように分けるとかなり誤解が減ります。

「ステージングへデプロイ済み」
「本番へデプロイ済み(フラグ OFF)」
「社内ユーザーへ先行リリース」
「10% へ段階リリース中」
「全体リリース完了」

こうすると、「どこに置かれているか」と「誰が使えるか」を同時に伝えられます。GitHub Actions などで自動化していると、デプロイは自動でも、リリースは人の承認や feature flag 操作という構成が普通にあります。CI/CD 全体の流れと合わせて見たい場合は GitHub Actionsとは？できること・最初の使い方を初心者向けに解説もつながります。

迷ったときの見分け方

見たいこと	デプロイ寄り	リリース寄り
コードはどこに置かれたか	デプロイ	-
ユーザーは使えるか	-	リリース
本番へ反映されたか	デプロイ	場合による
顧客体験が変わったか	-	リリース
戻すのに何が必要か	再デプロイ / ロールバック手順	フラグ OFF(即時)

リリースとデプロイに関するよくある質問

Q. CD(継続的デリバリー)では一緒？

A. CD でも「デプロイとリリースは別」という概念は分離して扱います。本番にデプロイされても feature flag で OFF、一部ユーザーのみ ON、のような段階公開を可能にするのが狙いです。デプロイは自動化し、リリース(公開判断)は人が握る、という形が一般的です。

Q. デプロイ済み → リリース済みの流れは？

A. 1) コードを本番にデプロイ(フラグ OFF)、2) 内部テストで動作確認、3) 一部ユーザーに ON(カナリア)、4) 段階的に拡大、5) 全ユーザーに ON(完全リリース)、です。Slack 表記なら [deployed / flag:OFF] から [released 10%]、最後に [released 100%] と遷移していきます。

Q. 戻すときも違いますか？

A. はい。ロールバックには2種類あります。リリース取消(フラグ OFF)は即時に効きますが、デプロイ取消(コードのロールバック)は再デプロイ手順が必要で時間がかかります。事故時は「まずフラグ OFF で公開を止め、余裕を持ってコードをロールバック」という段階対応が安全です。

Q. 小規模サービスでも分ける必要は？

A. シンプルな構成では不要なケースも多いです。大きな機能追加・本番影響が大きい変更・実験的機能のときだけ分ける、という運用が現実的です。ただし、Slack で deployed と released の単語を分けるだけなら追加コストはほぼゼロなので、表記の習慣だけは小規模でも持っておくと安全です。

Q. リリースノートはどちらの単位で書く？

A. リリース単位です。デプロイ毎のリリースノートは細かすぎます。「ユーザーに見える変更のまとまり」でリリースノートを書きます。フラグ OFF のままデプロイした分は、まだリリースノートには載せません。

Q. 用語の使い分けでチームの混乱を避けるには？

A. プロジェクト開始時に定義書で言葉を揃えます。デプロイ=環境への配置、リリース=機能の有効化、ローンチ=外向きの告知・公開、と明確に区別して書面化します。さらに Slack 表記([deployed / flag:OFF] など)をテンプレ化しておくと、口頭の解釈ずれを構造的に防げます。

Q. 本番でフラグを操作するとき、ログは残すべき？

A. 残すべきです。GitLab では本番フラグ操作を専用チャンネルで実行し、誰が・いつ・どのフラグを操作したかが自動で監査ログに残ります。小さなチームでも、操作を1つのチャンネルに集約し、操作内容をスレッドへ書くだけで、事故時の追跡が一気に楽になります。

Q. ロールフォワードとロールバックの関係は？

A. デプロイ後の問題対応で重要です。小さな修正ならロールフォワード(前進修正)、大きな問題ならロールバック(戻す)。そして「リリースだけ取消(フラグ OFF)」が第3の選択肢として最速で効きます。コードを触らずに被害を止められるのが、デプロイとリリースを分けておく最大の実益です。

まとめ

リリースとデプロイの違いは、「技術的に置くこと」と「ユーザーに出すこと」の違いです。

デプロイはコードを環境へ置く
リリースはユーザーが使える状態にする
小さな構成では同時に起こる
feature flag や段階公開があると分かれる

この整理があると、「もう本番に入っているのか」「まだ見えていないだけなのか」がかなり伝わりやすくなります。特にチームで運用するなら、deployed と released を分けて言い、フラグ状態と公開範囲を添えるだけで、本記事で挙げたような告知の前倒し事故を構造的に防げます。

参考リンク

LaunchDarkly Docs: Releases
LaunchDarkly Blog: Why you should decouple deployments from releases
LaunchDarkly Docs: Deployment and release strategies
GitLab Docs: Use ChatOps to enable and disable feature flags

リリースとデプロイの違いは？コードを置くこととユーザーに出すことを整理