開発の現場で「デプロイしました」という報告を聞いたとき、「もう使えるの？」と思ったことはないでしょうか。
実は、デプロイとリリースは別のことを指しています。
この2つを混同したままでいると、「デプロイ完了と聞いたのにサイトが変わっていない」「リリースしたと思ったらまだ誰も見られない状態だった」という認識のズレが起きます。
まず結論から
デプロイ ＝ コードをサーバーに配置する「技術的な作業」 リリース ＝ ユーザーへ機能を届ける「ビジネス上の判断と行為」
同じタイミングで行われることも多いですが、意図的に分けることができるという点が重要です。
デプロイは「商品を倉庫から店頭に運ぶ作業」
デプロイをたとえるなら、新商品を倉庫から店頭の棚へ運んで並べる作業です。
- 工場（開発環境）で作った商品を
- 検品して（ステージングで確認して）
- 店頭の棚（本番サーバー）に並べる
この時点では、棚に商品は並んでいます。でも**「本日より販売開始」の告知はまだ出ていない**かもしれません。
デプロイとはあくまで「コードを本番環境に配置して、動く状態にすること」です。 ユーザーにとって見える変化があるかどうかは、また別の話です。
リリースは「販売開始の告知」
リリースをたとえるなら、「本日より新商品の販売を開始します」という告知を出すことです。
- 棚に商品が並んだ（デプロイ済み）
- 「本日発売開始」の看板を出し、宣伝を打つ
- 初めてお客さんが手に取れるようになる
リリースは「いつ・誰に・どのように届けるか」というビジネス上の判断を含みます。 発表のタイミング、対象ユーザーの範囲、告知の方法などを決めて実行するのがリリースです。
2つは意図的に「ずらせる」
ここが最も重要なポイントです。
デプロイとリリースは、同じ日に行う必要はありません。
よくある使い方：デプロイ先行
月曜：デプロイ（コードは本番に入っている。でも新機能は非表示）
↓
金曜：リリース（キャンペーン開始と同時にスイッチを入れて公開）「機能フラグ」と呼ばれる仕組みを使って、コードは本番に存在するが特定のユーザーや特定の日時にならないと表示されない、という状態を作れます。
よくある使い方：段階的リリース
デプロイ完了
→ 社内ユーザーだけリリース（確認）
→ 5%のユーザーにリリース（様子見）
→ 問題なければ全ユーザーにリリース一度のデプロイを起点に、リリースを少しずつ広げることで、不具合が起きた場合の影響範囲を小さくできます。
2つを並べて比べると
| 観点 | デプロイ | リリース |
|---|---|---|
| 意味 | コードを本番サーバーに配置する | ユーザーへ機能を正式に公開する |
| 担当する人 | 開発者・インフラ担当 | 開発者・PdM・ビジネス側 |
| タイミングの柔軟性 | 技術的に準備ができたらいつでも | ビジネス判断で決める |
| ユーザーへの影響 | 必ずしも見える変化はない | ユーザーが気づく変化が生じる |
| 失敗時の対応 | ロールバックで前の状態に戻す | リリース取り消し・告知の修正 |
「デプロイ＝リリース」になるケースも多い
小規模なサービスや機能変更では、デプロイと同時にそのままリリースする形が大半です。 「デプロイしたら即公開」という運用で問題なく回っているチームも多くあります。
ただ、規模が大きくなったり複数チームが関わったりすると、この2つを分けて考えないと混乱が起きやすくなります。
「デプロイ完了」の報告はあくまで技術的な作業の完了を意味し、「リリース完了」はユーザーへの公開が完了したことを意味します。 この使い分けを意識するだけで、チーム内の認識のズレを大きく減らせます。
まとめ
- デプロイ：コードを本番サーバーに配置する技術的な作業。商品を棚に並べること。
- リリース：ユーザーへ機能を届けるビジネス上の判断と行為。「本日発売」の告知を出すこと。
- 同じタイミングで行われることも多いが、意図的に分けることができる。
- 「機能フラグ」「段階的リリース」などを使うと、デプロイとリリースをずらしてリスクを管理しやすくなる。
開発チームから「デプロイしました」と聞いたとき、「ユーザーからも見えている状態ですか？」と一言確認するだけで、認識のズレを防ぐことができます。