先に要点
- リリースは「機能をユーザーが使える状態にすること」、ローンチは「世に出す/告知すること」。この2語を分けて運用すると、部署をまたいだ会話の認識ズレが激減します。
- deploy(コードを環境へ置く)→ release(使えるようにする)→ launch(外向きに打ち出す)の3段階は別物。技術反映と利用可能化と告知を1日にまとめてよいのは小規模のときだけです。
- ソフトローンチ(地域/ユーザー限定の段階公開)から全公開へ踏み切る判断は、感覚ではなく Day30 継続率、クラッシュ率、サポート初動などの数値しきい値で決めます。
- 「ローンチした=使われる」ではありません。告知は認知を作るだけで、利用開始は別途、導線設計で支える必要があります。
「ローンチしました」と「リリースしました」は、日常会話ではかなり近く使われます。ただ実務では、この2つを少し分けておくと社内の会話がかなり整理しやすくなります。
特に、開発チーム、プロダクト、マーケティング、営業、サポートが関わる場面では、「今どこまで進んでいるのか」を言い分けられないと認識ズレが起きやすいです。「もう出したのか」「まだ正式発表していないのか」「一部だけ使えるのか」が混線すると、サポートが用意できていないのに営業が告知してしまう、といった事故につながります。
この記事では、2026年6月時点で LaunchDarkly の deployment / release ドキュメント、ソフトローンチに関する各社の公開情報を確認しながら、ローンチとリリースの違い、そしてソフトローンチをいつ全公開へ切り替えるかの判断基準を、数値を交えて整理します。
まず一言でいうと
最初に短く言うと、こうです。
リリース (release)
機能や変更を「ユーザーが使える状態」にすること。フラグをオンにする、ベータ枠を開ける、本番で新画面を有効化する、といった操作が該当します。見る対象は「使えるか」です。
ローンチ (launch)
それを「外向きに世へ出す」こと。プレスリリース、LP公開、SNS告知、営業資料の切り替えまで含む打ち出し。見る対象は「外から見て世に出たか」です。
この違いを持っておくと、「実装は終わってユーザーは使えるが、まだ正式発表していない」のような中間状態がかなり説明しやすくなります。
deploy・release・launch の3語の関係を先に固定する
混乱の多くは、この3語をひとまとめに「出す」と呼んでしまうことから来ます。LaunchDarkly の deployment vs release の整理に沿って言うと、3つは別の段階です。
| 言葉 | 主に見るもの | 主担当になりやすい人 | 典型操作 |
|---|---|---|---|
| デプロイ | コードや成果物を環境へ置いたか | 開発・SRE・自動化パイプライン | git push から CI/CD が本番へ反映 |
| リリース | ユーザーが機能を使えるか | プロダクト・開発 | フラグをオン、対象ユーザーを拡大 |
| ローンチ | 外向きに世へ出したか(告知・営業・広報) | マーケ・広報・営業 | PR配信、LP公開、SNS告知 |
ポイントは、デプロイとリリースを分離できる、という点です。デプロイは「コードを置く」だけなので、機能フラグをオフのまま本番へ置いておけます。これにより「コードは本番にあるが、誰も使えない」状態を安全に作れます。リリースはそのフラグをオンにして「使える」へ切り替える瞬間で、ローンチはさらにその外側で「世に告知する」イベントです。
このうち、デプロイとリリースの境目をコマンドレベルで詳しく見たい場合は、リリースとデプロイの違いは？コードを置くこととユーザーに出すことを整理 で扱っています。本記事は「リリースから先(=外向きのローンチ)」を担当します。役割分担としては次の通りです。
本記事が扱う範囲
release(使える)と launch(世に出す/告知)の境界。ソフトローンチの段階公開と全公開の判断、部署間の認識合わせ。
ローンチとリリースを分けて運用した具体シナリオ
抽象論だと差が伝わりにくいので、よくある B2B SaaS の新機能を例に、1つのリリース・ローンチを時系列で並べます。語彙を分けるだけで会話が整う様子が分かるはずです。
この時系列で重要なのは、D-10からD-0までの間です。ここでは「機能はリリース済みだが、まだローンチしていない」状態が10日間続きます。語彙を分けていないチームだと、D-10で「出した」と言った人がいると、マーケが「もう告知していいのか」と誤解し、サポート未整備のまま外向き告知が走る事故が起きます。
実際の言い分けの定型はこうです。
使える範囲を伝える
「機能は限定リリース済み」「全体リリースは段階的」
外向き告知の有無を伝える
「正式ローンチは来週」「社外公開はしたが正式ローンチ前」
社内準備の進捗を伝える
「ローンチ前にサポート導線を整える」「PR原稿は配信待ち」
ソフトローンチとは、そしていつ全公開へ踏み切るか
ソフトローンチは「限定公開で様子を見る」戦略です。一部ユーザー、一部地域、招待制ベータで先に公開し、フィードバックと数値を見てから全公開(フルローンチ/ハードローンチ)へ進みます。リスクを抑えながら本番環境で実地検証できるのが利点です。
問題は「いつ全公開へ踏み切るか」です。ここを感覚で決めると、まだ継続率が低い段階で大々的に告知してしまい、流入したユーザーがそのまま離脱する、という最悪のパターンになります。判断は数値しきい値で行うのが定石です。公開されている目安を基準に、技術・利用・運用の3軸で見ます。
| 軸 | 指標 | 全公開へ踏み切る目安(例) |
|---|---|---|
| 技術的安定性 | クラッシュ率 / エラー率 | クラッシュフリー率 99%超、致命バグ(severity high以上)ゼロ |
| 技術的安定性 | 稼働率 / レイテンシ | サーバー稼働率や応答時間が目標値を数週間連続で維持 |
| 利用(プロダクトマーケットフィット) | 継続率(リテンション) | Day30 継続率 60%前後を目標(モバイルアプリでは Day1/Day7 も併用、90日継続25%以上を1つの目安にする例も) |
| 利用 | アクティベーション率 / NPS | 初回設定完了率が安定、NPS 40超 |
| 運用準備 | サポート初動 / 充足率 | 問い合わせの返答時間が目標内、ヘルプ・FAQの抜けがない |
これらの数値は事業領域で大きく変わるので、絶対値より「自社で設定した目標を、ブレずに数週間連続で満たしているか」という安定性の方が重要です。1日だけ達成しても踏み切らない、というのが現場の感覚に合います。具体的な踏み切り判断は次のように組みます。
なお、ソフトローンチの対極にステルスローンチ(PRを一切打たず公開し、品質と口コミで広げる手法)があります。ソフトローンチが「対象を絞って検証する」のに対し、ステルスローンチは「告知を絞る」点が違います。検証目的ならソフトローンチ、過度な期待値を作りたくないならステルス、と使い分けます。
なぜローンチとリリースは混ざりやすいのか
この2つが混ざりやすい理由は、小規模な開発では同じ日に起きやすいからです。
- 本番へデプロイする
- すぐ告知する
- 全員が使えるようになる
これが同日なら、デプロイもリリースもローンチもほぼ同じ瞬間に見えます。個人開発や社内ツールではこれで十分です。問題は、運用が複雑になると同時ではなくなることです。前述のシナリオのように、リリースが先行してローンチが10日後にくる、あるいはローンチ日は1日でもリリース(対象拡大)は段階的、という分離が起きます。このとき語彙が1つしかないと、進捗を正しく言い表せなくなります。
「外向き公開」とローンチの違い
「外向き公開」はローンチとかなり近い言い方ですが、少し広い概念です。単に社外から見える状態になったことも指します。
たとえば、LPを公開した、ドキュメントを公開した、ベータ募集ページを公開した、というだけでも「外向き公開」とは言えます。一方でローンチは、もう少し「打ち出し」「開始イベント」の色が強いことが多いです。
外向き公開
社外から見える状態にする。ベータ募集ページやドキュメント公開も含む、やや広い言い方。
ローンチ
それを正式に世へ出す打ち出し。PR・告知・営業準備を伴う開始イベントの色が強い。
「ローンチした」は終点ではない
ローンチの文脈では、どうしても告知が中心に見えます。しかし、告知したことと実際に使われることは別です。
この点は 新機能を出しても使われないのはなぜか 告知不足より導線不足を疑うべき理由 でも整理している通りで、外向きに打ち出したことと、利用開始が進むことは同じではありません。ローンチは「知ってもらう」役割、リリース後の導線設計は「実際に使ってもらう」役割で、分けて考えた方が現実的です。
この境界をもう少し実務寄りに、「誰が認知を作り、誰が利用開始を支えるのか」まで掘りたい場合は、ローンチしたのに使われないのはなぜか？告知と導線の役割分担を整理 もつながります。
よくある誤解(失敗の形で)
ローンチとリリースは完全に同じ、と扱う
現象: 開発が「出した」と言った翌日にマーケが告知、サポートが未整備で問い合わせが炎上。原因: 「出した」がリリース(使える)なのかローンチ(告知)なのか区別されていない。確認手順: 進捗報告で「使える範囲」「告知の有無」「社内準備」の3つが分けて書かれているか見る。回避: チームで語彙を揃え、「限定リリース済み・ローンチ未」のような定型句を使う。
「ローンチすれば使われる」と思い込む
現象: 大々的に告知したのにアクティベーション率が伸びない。原因: 認知は作れたが、初回導線・初回設定・対象ユーザーの見極めが弱い。確認手順: 告知後の流入数とアクティベーション率を分けて計測する。回避: ローンチ施策と導線設計を別タスクとして持つ。
「リリースはエンジニア、ローンチはマーケだけ」と切り分ける
分担としては近い面もありますが、実際にはかなり重なります。リリース判断にはサポートや営業準備が影響し、ローンチ日程には技術側の安定性が影響します。ソフトローンチの踏み切り判断(前述の3軸)が、まさに技術・利用・運用の合議である点が象徴的です。
ローンチとリリースに関するよくある質問
Q. ローンチデーとリリース日は違う？
A. はい。ローンチデーは「世に公開・告知される日」(マーケティングイベントを含む)、リリース日は「機能が技術的に使えるようになった日」です。前述のシナリオのように、リリースを先行させてローンチに備えるのが定石で、両者がずれること自体は正常です。
Q. ソフトローンチとフルローンチの違いは？
A. ソフトローンチは一部ユーザー・一部地域・招待制ベータなど対象を絞った公開で、検証が目的です。フルローンチ(ハードローンチ)は一般公開で、大規模なマーケティングを伴います。ソフトローンチで数値しきい値を満たしてからフルローンチへ進むのが安全です。
Q. いつ全公開へ踏み切ればいい？
A. 技術的安定性(クラッシュフリー率99%超・致命バグゼロ)、利用(Day30継続率60%前後やNPS40超)、運用準備(サポート初動が目標内)の3軸が、単日ではなく数週間連続でしきい値を満たしたときです。1軸でも未達なら、その軸を改善してから次段階に進めます。
Q. ソフトローンチではどの指標を見る？
A. アクティベーション率、リテンション(継続率)、エンゲージメントがプロダクトマーケットフィットの良い指標です。モバイルアプリでは CPI、LTV、Day1/Day7/Day30 継続率、オーガニックの転換率も併用します。絶対値より、自社目標を安定して満たしているかを重視します。
Q. リリースとローンチの順序は？
A. 「限定リリース → 内部テスト → ベータ顧客テスト → ローンチ」が定番です。いきなり告知付きで全公開する「ぶっつけローンチ」は、未検証のまま流入を浴びるため事故リスクが大きいです。
Q. ローンチ後の運用で気を付けることは？
A. 初日のサーバー負荷、サポート問い合わせの急増、想定外のユーザー行動、競合の反応、バグ報告対応です。ローンチ直後はハイパーケア期間として、おおむね2〜4週間は体制を強化します。ローンチは終点ではなく、利用開始を支える起点です。
Q. ローンチが想定通りいかなかった場合は？
A. 静かに撤回して再準備、ベータ版に戻して検証継続、機能を縮小して再ローンチ、サービス自体の見直し、などが現実的な選択肢です。フラグでリリースを絞れる構成にしておけば、告知を止めつつ対象を縮小する、といった部分的な後退も取りやすくなります。
まとめ
ローンチとリリースは近い言葉ですが、見る対象が違います。
- デプロイは「コードを環境へ置く」、リリースは「使える状態にする」、ローンチは「外向きに世へ出す/告知する」
- この3語を分けると、リリース先行・ローンチ後追いのような中間状態を正確に言い表せる
- ソフトローンチから全公開への踏み切りは、技術・利用・運用の3軸の数値しきい値を数週間連続で満たすかで判断する
- 告知したことと使われることは別。ローンチは認知の起点であって終点ではない
この整理があると、「もう出したのか」「まだ正式発表していないのか」「一部だけ使えるのか」を会話で区別でき、開発・プロダクト・営業・サポートが一緒に動く場面の認識ズレを大きく減らせます。
参考リンク
- LaunchDarkly Docs: Deployment and release strategies
- LaunchDarkly Blog: Why decouple deployments from releases
- LaunchDarkly Docs: Releases
- Wikipedia: Soft launch
- Userpilot: Product Launch Metrics
- Adjust: Running a successful soft launch for your app