ダークローンチとは？本番トラフィックで裏側だけ検証する実装と採用判断

検証環境では通っていた改修が、本番へ出した途端に特定の入力パターンで落ちる。原因の多くは、実データの分布と実トラフィックの形をステージングが再現しきれていないところにあります。ダークローンチは、この差分を利用者に見せないまま本番で先に踏み抜くための手法です。この記事では、定義と2つの実装方式、Istio・nginx・Envoyでの設定項目、副作用を遮断する前提条件、採用と見送りの判断基準を実装者目線で整理しました。

まとめ：ダークローンチは公開判断とデプロイを切り離す検証手法

ダークローンチで先に決めるのは2つです。何をもって「合格」とするかという判定指標と、副作用をどこで断つかという遮断点。この2つが決まっていれば、フィーチャーフラグでもトラフィックミラーリングでも構成は埋まります。

結論を先に示します。参照系のリクエストが主で、新旧の応答を突き合わせて差分を見たいならトラフィックミラーリングを選んでください。更新系を含み、機能単位で段階的に露出させたいならフィーチャーフラグ方式が向きます。両者は排他ではなく、フラグでコードを本番へ潜ませ、ミラーで負荷と応答差を測る併用が実務での定番です。

始める前に撤収手順を決めてください。ミラー設定と分岐コードは、検証が終わっても消されず、残された状態になりがちです。残骸は二重の実行コストと、読み解けない条件分岐として後から効いてきます。判定指標・遮断点・撤収期限の3点を最初に紙へ落とすところが、この手法の成否を分けます。

ダークローンチの定義とデプロイと公開を切り離して検証する考え方

まず用語の範囲を揃えます。ダークローンチという言葉は、指しているものが文脈で2通りに割れるためです。

ダークローンチの定義と利用者に結果を見せず検証する対象範囲の境界

ダークローンチは、新しいコードやサービスを本番環境で実際に動かしながら、その結果を利用者へは返さない状態で検証する手法を指します。処理は本番の実データ・実トラフィックで走り、応答は破棄されるか、画面には現れない裏側の経路にとどまります。

この「動かすが見せない」という性質が、他のリリース手法との分かれ目になります。段階的に本番へ出す点はカナリアリリースと同じですが、カナリアが一部の利用者へ新バージョンの応答を返すのに対し、ダークローンチは誰にも返しません。失敗しても利用者側の体験は変わらないため、切り戻しという概念そのものが軽くなります。

英語圏では dark launch のほか shadow deployment、traffic shadowing、traffic mirroring といった呼び方が併存する状況です。日本語ではダークリリース、シャドウトラフィックという表記も一般的です。指している技術は概ね同じなので、社内で1語に寄せておくと設計レビューの齟齬が減ります。

デプロイ・リリース・公開の3語が指す境界と用語の揺れを防ぐ定義

この手法を理解する前提として、3つの動詞を分けて扱う必要があります。デプロイはコードを本番のサーバーへ配置する行為、リリースはその機能を利用者から到達可能にする行為、公開は利用者へ告知して使わせる行為です。

従来のリリース作業は3つが同時に起きていました。配置した瞬間に機能が生き、利用者が触れる状態になる。ダークローンチはここを分解し、デプロイだけを先に済ませてリリースを後ろへずらします。分解しておくと、障害時の切り分けが「配置の問題か、機能の問題か」で分かれるため、原因の特定が速くなります。

この分離を機能単位で行う仕組みがフィーチャートグル（フィーチャーフラグ）の定義と基本概念です。ダークローンチはトグルの適用先の1つとして位置づけられます。

ダークローンチが解く課題と本番環境でしか出ない差分の正体を見分ける方法

検証環境で拾えない差分は、大きく3種類に整理できます。1つ目はデータ分布の差で、本番にしか存在しない外れ値・古い形式のレコード・想定外の文字種が該当します。2つ目はトラフィックの形の差です。同時接続数、リクエストの偏り、キャッシュのヒット率は、合成負荷では再現しきれません。

3つ目が依存先の実挙動になります。外部APIのレート制限、レプリカ遅延、隣接サービスの応答時間のばらつきは、モックでは出ません。ダークローンチはこの3種類を本番で先に踏ませ、利用者への影響が出る前に検知させる手段です。逆に言えば、この3つが問題にならない改修に対しては投資が見合いません。

フィーチャーフラグ方式とトラフィックミラーリング方式の使い分け

実装は大きく2方式に分かれます。どちらを選ぶかは、検証したいものが「機能の挙動」か「系全体の応答差と負荷」かで決まります。

フラグで裏側の処理だけ動かす方式の実装手順と適用できる範囲の条件

フィーチャーフラグ方式では、新しい処理をフラグで囲んだうえで本番へ配置し、フラグを無効のまま置きます。この時点でコードは本番に存在しますが、利用者からは到達できません。次に、応答を返さない形で新処理だけを実行させ、ログとメトリクスを集めます。

典型的な実装は、旧処理の結果を返しつつ、新処理を非同期で走らせて結果をログへ書くだけの構成です。利用者の待ち時間には影響させず、例外の発生率と処理時間だけを先に測れます。差分比較まで行う場合は、新旧の結果をハッシュ化して突き合わせ、不一致率をメトリクスとして出す形が扱いやすいでしょう。

フラグの管理は、実装が増えるほど専用の仕組みが要ります。ベンダー中立のAPI仕様としてはCNCFのOpenFeatureがあり、2022年6月にCNCFへ参画し2023年11月にIncubatingへ昇格した経緯です（2026年8月時点でIncubating）。評価APIとプロバイダを分離する設計のため、フラグ管理サービスを差し替えてもコードを書き換えずに済みます。

本番リクエストを複製して新系へ流すミラーリングの処理の流れと注意点

トラフィックミラーリング方式では、アプリケーションのコードには手を入れません。プロキシやサービスメッシュの層でリクエストを複製し、片方を従来の系へ、もう片方を検証対象の系へ送ります。検証系からの応答は破棄されるため、利用者には従来どおりの結果だけが返ります。

この方式の利点は、対象がリクエスト単位である点にあります。特定の機能ではなく、サービス全体を丸ごと新バージョンへ差し替えた状態で、実トラフィックの形のまま負荷と応答を測れます。ライブラリ更新やランタイムのバージョン上げのように、影響範囲が広く分岐を書きにくい改修と相性が良い方式です。

制約もはっきりしています。複製されたリクエストが更新系だった場合、検証系でも書き込みが走る設計です。ここを遮断しないまま始めると、本番データの二重更新や外部への二重通知が起きます。遮断策は後の章で整理します。

2つの方式を併用する構成と検証できる範囲が重なる条件と違いの判断

実務では併用が多くなります。フラグでコードを本番へ潜ませておき、ミラーリングで系全体の負荷を測り、確認が取れた順にフラグを開けていく流れです。

役割を分けると設計が澄みます。フラグは「誰に見せるか」を決める露出制御、ミラーは「何を流すか」を決めるトラフィック制御。前者はアプリケーション層、後者はネットワーク層に責務が置かれます。この2層を混ぜて実装すると、切り戻しの操作対象が分からなくなるため、層をまたぐ制御は片方へ寄せてください。

カナリアリリース・ブルーグリーンとの違いと利用者への露出で選ぶ判断基準

デプロイ戦略は名前が似ており、選定時に混同されがちです。露出の有無と切り戻しの単位という2軸で並べると区別がつきます。

利用者への露出と切り戻し単位から見た他方式との比較基準と選び方

4方式を並べると、判断の軸がはっきりします。

露出がない点がダークローンチの固有の性質です。品質指標を実利用から取りたいならカナリアへ進む必要があり、ダークローンチだけでは公開可否の最終判断まで届きません。段階的な露出制御の設計はカナリアリリースの仕組みと他方式との違い、環境ごと切り替える方式はブルーグリーンデプロイメントの仕組みと実装にそれぞれまとめています。

A/Bテストや自動昇格と目的が分かれる境界線の整理方法と判断軸

A/Bテストは同じ仕組みを使いますが、目的が別です。A/Bテストが測るのは利用者の行動であり、どちらの案が成果指標を伸ばすかを判定する手法です。ダークローンチが測るのは技術的な健全性で、落ちないか・遅くならないか・結果が変わらないかを見ます。判定する人も、開発側と事業側で分かれます。

自動分析で昇格と切り戻しまで自動化する考え方はプログレッシブデリバリーの制御ループと採用基準の領分になります。ダークローンチはその前段に置かれる検証で、自動昇格の判定に使うメトリクスを、露出ゼロの状態で先に校正しておく役目を担います。

Istio・nginx・Envoyで組むミラーリングの実装と設定項目

ミラーリングは既存のプロキシ層で実現できます。代表的な3つの設定項目を押さえます。バージョンや既定値は改版で変わるため、導入時は各公式ドキュメントで再確認してください。

IstioのVirtualServiceで指定するミラー先と比率の設定

Istioでは、VirtualServiceのルートにmirrorを書いてミラー先のホストとサブセットを指定します。比率はmirrorPercentageで指定し、このフィールドを省略すると全トラフィックが複製される挙動です。まず数パーセントから始めて、検証系の余力を見ながら引き上げる進め方が安全です。

ミラーされたリクエストは、HostまたはAuthorityヘッダに-shadowのサフィックスが付いた形で送られる仕様です。公式ドキュメントの例ではcluster-1がcluster-1-shadowになると説明されています。このサフィックスは、検証系のアプリケーション側で「これは複製されたリクエストである」と判別する手掛かりに使えます。

ミラーは fire and forget として送られ、応答は破棄されます。つまり検証系が落ちても遅くても、利用者側の応答には影響しません。公式ドキュメントの記載はページ表記で v1.30（2026年8月時点の Current 表示・Istio 1.30系）を確認した内容です。

nginxのmirrorディレクティブで複製する構成と注意点

サービスメッシュを入れていない構成でも、nginx単体でミラーリングを組めます。ngx_http_mirror_moduleのmirrorディレクティブに内部ロケーションを指定すると、そのロケーションへサブリクエストが送られる仕組みです。モジュールが追加されたのは1.13.4で、それ以降のビルドであれば標準で入っています。

公式ドキュメントには「Responses to mirror subrequests are ignored」と明記されており、Istioと同様に応答は無視されます。ボディを伴うリクエストを複製する場合はmirror_request_bodyの扱いを確認してください。ボディを読み切ってから元のリクエストを処理する挙動になるため、大きなアップロードを含む経路では遅延の要因になります。

注意点は、サブリクエストの処理がワーカープロセスを消費するところです。複製先が遅いと、その分だけ本系のワーカーが塞がります。ミラー先には短めのタイムアウトを与え、詰まったら早く諦める設定にしてください。

Envoyのリクエストミラーポリシーと比率制御を決める考え方

Envoyを直接扱う構成では、ルート設定のrequest_mirror_policiesでミラー先のクラスタと比率を指定します。IstioのミラーはこのEnvoyの機能を抽象化したもので、実際に複製を行っているのはサイドカーのEnvoyです。

比率の指定を実行時に切り替えられる点が、この層で制御する利点です。デプロイし直さずに複製を止められるため、検証系が不調になったときの撤退が速くなります。検証系にもヘルスチェックのLivenessとReadinessの分離と閾値設計を適用し、readinessが落ちたら複製先から自動で外れる構成にしておくと、手動の停止操作を待たずに済みます。

副作用の遮断と観測設計を先に決めるための前提条件の組み立て方

ここが実装の山場です。ミラーリングは、遮断を設計しないまま入れると事故になります。

書き込み・課金・通知を止める副作用遮断の実装チェック項目と手順

複製されたリクエストが引き起こす副作用は、走らせる前に洗い出してください。実務で確認すべき項目は次の5つです。

1. データベースへの書き込み（検証系は読み取り専用レプリカか別インスタンスへ向ける）
2. 決済・課金など外部への金銭が動く呼び出し（スタブへ差し替える）
3. メール・プッシュ通知・Webhookなど外部への送信（送信先をダミーへ切り替える）
4. メッセージキューへの発行（別トピックへ隔離するか発行そのものを止める）
5. 共有キャッシュへの書き込み（キー空間を分けて本系の値を壊さない）

切り分けの実装は、前述の-shadowサフィックスや専用ヘッダを見て分岐させる方法が確実です。設定ファイルの環境変数で切り替える方法もありますが、同じイメージを本系と検証系で使い回す構成では取り違えが起きます。リクエスト単位で判別できる情報を根拠にしてください。

差分比較の判定基準を決める観測メトリクスの具体的な選び方と閾値

何をもって合格とするかを、走らせる前に数値で決めます。最低限そろえるのは、検証系のエラー率・応答時間のp95とp99・新旧の応答差分の不一致率の3つです。不一致率は、応答本文を正規化してからハッシュ化し、突き合わせて算出します。

ここで落とし穴になるのが、正当な不一致です。タイムスタンプ・リクエストID・乱数を含む応答は必ず食い違うため、比較前に除外する項目を決めておかないと、不一致率が常に100パーセントになって判定に使えません。除外リストの作成は、実際に数十件を目視で突き合わせて作るのが結局は速い進め方です。

合格ラインは絶対値ではなく、本系との相対で置いてください。検証系のp99が本系の1.2倍以内、エラー率の差が0.1ポイント以内、といった形です。本系の値も同時に揺れるため、固定値で置くと季節変動やキャンペーンの負荷で判定が壊れます。

個人データの複製で広がる取り扱い範囲と保管条件の線引き判断基準

複製されるのは本番のリクエストです。個人情報・認証トークン・決済情報がそのまま検証系へ流れ込みます。検証系のログレベルを上げていると、本系では出していない情報がログへ落ちる事態も起こります。

線引きは3点で決めてください。検証系の保管期間を本系より短くする、ログの出力項目を本系と同じマスキング規則に揃える、検証系へのアクセス権限を本系と同等に絞る。検証用だからと緩めた設定が、そのまま本番データの露出面になります。

ダークローンチを採用すべき条件と見送るべき場面を分ける判断基準

最後は判断の話です。この手法は構成が増えるため、費用に見合う場面を選ぶ必要があります。

採用が投資に見合う3つの条件と回収できる検証コストの基準と判断

採用が見合う条件は3つあります。1つ目は、障害が起きたときの損失が大きいこと。決済・在庫引当・認証といった基幹の経路では、本番でしか出ない差分を先に踏む価値が構成の追加コストを上回ります。

2つ目は、検証環境で本番のデータ分布を再現できないこと。データ量が桁で違う、あるいは個人情報の制約で本番データを持ち込めない環境では、他に測る手段がありません。3つ目は、改修の影響範囲が広く、分岐を書き切れないことです。ランタイムやフレームワークの世代更新が典型で、機能単位のフラグでは覆えません。

逆に、この3つのどれにも当てはまらない改修では、ステージングでの負荷試験とカナリアリリースによる段階的な露出で足ります。全ての改修へ一律に適用すると、遮断設定の保守だけで工数が溶けていきます。

見送るべきシステム側の条件と代替手段へ切り替える判断基準と代案

見送りを勧める条件も明確です。更新系が主体で副作用の遮断点を作れない場合、この手法は選ばないでください。書き込みを止められないなら、複製したリクエストは本番データを壊す経路そのものになります。

検証系を本番と同等の規模で用意できない場合も見送り側です。半分の規模の検証系へ全量を複製すれば、そこで出る遅延は改修由来ではなく規模由来の値になり、判定材料になりません。複製比率を絞れば測れますが、負荷起因の問題は比率を絞るほど見えなくなります。

代替としては、本番データの匿名化コピーを使った負荷試験、あるいは記録した本番リクエストを後から再生する方式が候補になります。リアルタイム性を捨てる代わりに、副作用の心配なく繰り返し試せる点が利点です。

撤収手順を決めずに始めた場合に残る二重コストの実態と対策と期限

始め方より難しいのが終わり方です。検証が終わったあとも、ミラー設定と分岐コードは動き続けます。複製されたリクエストは検証系の計算資源を消費し続け、クラウド費用としては素直に二重で計上されます。

コード側の残骸はさらに厄介です。-shadowヘッダを見る分岐が半年後も残っていると、その条件が何のためにあるのか読み解けなくなり、次の改修の障害物になります。開始時に撤収期限を決め、期限が来たら設定と分岐をまとめて消すところまでを1つの作業として扱ってください。

遮断設定と観測の作り込み、そして撤収までの一連の管理は、リリースのたびに手が要る領域になります。社内の運用体制で回し切れない場合は、保守運用・内製化支援のように、構成の設計から監視との接続、内製へ戻すまでの伴走を含めて外部に預ける選択肢もあります。

よくある質問

ダークローンチの設計時に相談を受けることの多い質問を、実務での判断とあわせて整理します。

ダークローンチとカナリアリリースはどちらを先に導入すべきですか？

カナリアリリースを先に整えてください。カナリアは露出を絞って実利用の指標を見る仕組みで、切り戻しの経路さえ作れば単独で成立します。ダークローンチは検証系の用意と副作用の遮断が前提になるため、構成の負担が重くなります。順序としては、カナリアで段階的な露出制御を確立し、それでも本番でしか出ない差分に困った時点でダークローンチを足す流れが現実的です。基幹の経路を丸ごと差し替えるような改修が控えているなら、その案件に限って先行して組む判断もあります。

ミラーリングした検証系のデータベースはどう用意すればよいですか？

参照系だけを検証したいなら、本番の読み取り専用レプリカへ向ける構成が手軽です。書き込みは遮断され、データの鮮度も保てます。更新系まで含めて動かしたい場合は、本番のスナップショットから復元した専用インスタンスを用意してください。この場合、時間の経過とともに本番との差が開くため、判定に使える期間は数日が上限と考えたほうが安全です。いずれの構成でも、検証系から本番のデータベースへ書き込む経路が残っていないか、接続文字列の単位で確認してください。

ミラーリングは本番の応答時間に影響しませんか？

方式によって変わります。Istioのミラーは fire and forget で応答を破棄する仕組みのため、検証系が遅くても本系の応答は待たされません。一方でnginxのサブリクエストはワーカープロセスを消費し、ボディを伴う複製ではボディを読み切る処理が入ります。複製先が詰まるとワーカーが塞がるため、ミラー先には短いタイムアウトを設定してください。導入直後は複製比率を数パーセントに絞り、本系のp99を監視しながら引き上げる進め方を勧めます。

フィーチャーフラグ方式のフラグはいつ削除すべきですか？

検証が終わり、機能を全面公開して安定を確認した時点で削除します。目安としては公開から2週間、切り戻しの必要がなければ分岐ごと消す運用が扱いやすいでしょう。削除の判断を属人的にしないため、フラグの作成時に期限と削除の担当を記録してください。期限切れのフラグを検出して通知する仕組みを持つ管理サービスもあります。放置されたフラグは条件分岐の組み合わせを指数的に増やし、テストで到達できない経路を生みます。

小規模なチームでもダークローンチは実現できますか？

フィーチャーフラグ方式であれば、専用の基盤がなくても始められます。設定値でフラグを切り替え、新処理を非同期で走らせてログへ結果を書くだけの構成なら、追加のインフラは不要です。難しいのはトラフィックミラーリング方式で、検証系の環境費用と遮断設定の保守が継続的に発生します。サービスメッシュを導入していない小規模チームでは、まずフラグ方式で機能単位の検証を回し、ミラーリングは影響の大きい改修に限って一時的に組む使い分けを勧めます。

関連記事

• ローリングアップデートとは：検証を終えた変更を無停止で行き渡らせる更新方式の設定値を整理しています。
• ゼロダウンタイムデプロイとは：公開に踏み切る段階で無停止を壊す発生源と設定順序を確認できます。
• イミュータブルインフラとは：検証系を本番と同じ手順で作り直す前提を整える考え方です。