「本番切り替えはカナリアリリースで進めます」とベンダーから提案を受けたとき、多くの発注担当者は「安全そうだが、本当に自社に合っているのか」という不安を抱えます。技術的には合理的な選択に見えても、追加インフラの費用、監視期間の延長、障害発生時の切り戻しコスト、SLA や利用規約への影響など、発注者側で確認しなければならない論点は数多くあります。
カナリアリリースは、新しいバージョンを最初は一部のユーザーだけに限定公開し、問題がないことを確認してから段階的に全ユーザーへ拡大していく方式です。「炭鉱のカナリア」の比喩で語られるように、少数のユーザーで先行して危険を察知する仕組みですが、実務においては監視体制・切り戻し設計・コスト構造まで踏み込んで理解しないと、承認判断の精度は上がりません。
しかし、多くの解説記事は技術者向けに書かれており、「どのように実装するか」「どんな監視ツールを使うか」という観点が中心です。発注者として本当に知りたいのは「自社のサービス特性でカナリアリリースが最適か」「承認前にベンダーに何を確認すればよいか」「代替案を求めるべきケースはどんな場合か」といった意思決定のための判断軸ではないでしょうか。
本記事では、カナリアリリースの仕組みを非エンジニア向けにやさしく解説したうえで、ブルーグリーンデプロイメントやローリングアップデートとの違いを発注者視点で比較します。さらに、承認判断の前にベンダーへ確認すべき7つのリスク管理チェックポイントと、カナリアリリースが向くケース・避けた方がよいケースの判断基準を整理します。読了後には、次回のベンダー打合せで主体的に質問し、承認を出すべきか代替案を求めるべきかを自分の言葉で判断できるようになるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
カナリアリリースとは？発注者が押さえるべき基本の意味
カナリアリリースは、新しいバージョンのシステムをいきなり全ユーザーへ公開するのではなく、まずごく一部のユーザーだけに提供し、問題がないことを確認しながら段階的に対象を広げていくリリース手法です。技術者向けには「トラフィックの段階的なシフトによる本番検証手法」と説明されることが多いですが、発注者にとっての本質は「本番環境で少人数から様子を見て、大きな障害が起きても影響範囲を最小化できる仕組み」だと押さえておけば十分です。
名前の由来と一言定義
「カナリア（canary）」という名称は、かつて炭鉱労働者が有害ガスの検知のためにカナリアを籠に入れて坑内に持ち込んだ故事に由来します。カナリアはガスに対して人間より敏感なため、異変を察知するとカナリアが先に反応し、労働者は退避することができました。
同じ発想で、システムの新バージョンを最初に体験する少数のユーザーを「カナリア」と見立て、そこでエラーや不具合が観測されなければ順次対象範囲を拡大し、逆に異常が観測されれば全ユーザーへ広げる前に切り戻すのが、カナリアリリースの基本的な考え方です。
一言で言えば、「新バージョンをまず一部のユーザーだけに公開し、安全性を確認してから全ユーザーへ広げる段階的リリース手法」となります。
発注者が押さえる仕組みの流れ
実務でカナリアリリースを進める際は、以下のようなステップでトラフィックの割合を段階的に増やしていきます。あくまで例ですが、発注者としてはこのような「段階的な拡大の流れ」があるとイメージしておけば十分です。
- 全ユーザーの5%に新バージョンを提供
- 一定時間の監視でエラー率・レスポンス速度・ビジネス指標に異常がないことを確認
- 25%へ拡大し、再度監視
- 50%へ拡大し、再度監視
- 100%へ拡大し、全展開完了
各ステップの間には「監視期間」と「拡大判定」があり、監視期間中に定めた閾値を超えるエラーが発生すれば、拡大を止めて旧バージョンへ切り戻します。この「段階的な拡大」と「途中で止められる」という2点が、カナリアリリースが「安全な方式」と呼ばれる根拠です。
「デプロイ」「リリース」との位置関係
カナリアリリースを理解する前提として、「デプロイ」と「リリース」の違いを押さえておくと、ベンダーの説明が格段に読み解きやすくなります。
デプロイは新しいバージョンを本番環境のサーバーに配置する作業、リリースは配置されたバージョンを実際にユーザーへ提供する状態にする行為、という区別です。カナリアリリースは、この「リリース」の段階でトラフィックの割合を制御することによって、ユーザーへの露出を管理する手法だと位置づけられます。
発注者としてより体系的に理解したい場合は、デプロイとは？発注者が知るべきリリース・インフラ展開の違いと確認事項7つ を先に読んでおくと、本記事の内容がよりスムーズに頭に入ります。
リリース手法の違い｜ブルーグリーン・ローリングとの比較
ベンダーから「カナリアリリースで行きます」と提案されたとき、発注者としてまず整理しておきたいのは「なぜ他の方式ではないのか」という視点です。ここでは代表的な3つのリリース手法（カナリア・ブルーグリーン・ローリング）を、発注者視点の比較軸で整理します。
ブルーグリーンデプロイメントとは
ブルーグリーンデプロイメントは、本番環境（Blue）と全く同じ構成の別環境（Green）を用意しておき、新バージョンを Green 側にデプロイして動作確認したうえで、ロードバランサーの切り替えなどによって全ユーザーのトラフィックを一斉に Green へ流す方式です。切り替え後、Blue はしばらく待機環境として残しておき、問題が起きたら瞬時に Blue へ切り戻せるようにしておきます。
発注者視点では「全ユーザーが同時に新バージョンを使い始める」「切り戻しが最も速い」「一方で本番環境をまるごと2セット用意する分の追加インフラ費が発生する」という特徴を押さえておけば十分です。
ローリングアップデートとは
ローリングアップデートは、複数台あるサーバーを1台ずつ順番に新バージョンへ入れ替えていく方式です。たとえば10台のサーバーで運用しているサービスであれば、まず1台目を新バージョンにアップデートし、動作確認後に2台目、3台目と順番に置き換えていきます。
発注者視点では「サービスを止めずに更新できる」「追加インフラは基本的に不要」という長所がある一方、「新旧バージョンが一時的に混在するため、ユーザーによって挙動が変わる可能性がある」「切り戻しには再度全台を旧バージョンへ戻す必要があり時間がかかる」といった特徴があります。Kubernetes や AWS の各種サービスでも標準的にサポートされている、最も一般的な段階的更新方式のひとつです。
3手法を発注者視点で比較する
3手法の違いを、発注者が意思決定で用いる観点で整理すると以下のようになります。
観点 | カナリアリリース | ブルーグリーンデプロイメント | ローリングアップデート |
|---|---|---|---|
ユーザーへの見え方 | 一部ユーザーのみ新バージョン。順次拡大 | 全ユーザーが一斉に切り替わる | サーバー切替中のユーザーで新旧が混在 |
切り戻しやすさ | 拡大前なら容易。データ変更を伴う場合は要注意 | 最も高速（ロードバランサー切替） | 全台を旧バージョンへ戻す時間が必要 |
追加インフラの目安 | 中（新旧が同時稼働する時間帯あり） | 大（本番相当の環境をもう1セット） | 小（既存台数のまま入れ替え） |
監視期間・監視負荷 | 長い（段階拡大の各ステップで監視） | 短い（切替直後を集中的に監視） | 中（切替中の各台の監視が必要） |
向いているケース | 大規模ユーザーベース／リスクの読めない新機能 | 高速切替と即時ロールバックが最優先 | インフラ費を抑えつつ徐々に更新したい |
「切り戻しの速さ」「追加インフラ費」「監視期間の長さ」の3点で見ると、それぞれの手法の性格が明確に見えてきます。「安全性の高さ」だけを軸にすると差が分かりにくいですが、「何にどれくらいコストを払うか」で見比べると、自社にとっての適正解が浮かび上がってきます。
A/B テスト・フィーチャーフラグとの違い
「一部ユーザーだけに新機能を出す」という点で、カナリアリリースは A/B テストやフィーチャーフラグと混同されがちですが、目的が異なります。
- カナリアリリース: 目的は「安全性の検証」。エラー率・レスポンス速度など技術的な健全性を段階的に確認する
- A/B テスト: 目的は「ビジネス仮説の検証」。UI やコピーの違いがコンバージョン率などに与える影響を統計的に評価する
- フィーチャーフラグ: 目的は「機能の出し分け制御」。特定の顧客・特定の条件下でのみ機能を有効化する仕組み
発注者としては、この3つを混同しないことが重要です。「カナリアで A/B テストもやります」といった提案が来た場合、それぞれで見たい指標・監視期間・判定基準が異なるため、目的を明確にしたうえで承認判断を行う必要があります。
カナリアリリースを採用する発注者側のメリットとリスク
カナリアリリースを「安全そう」という第一印象で承認する前に、発注者として得られるメリットと引き受けるリスク・追加負担を整理しておきましょう。技術者向けの記事とは異なり、事業判断の観点から見た損得を明らかにするのが本セクションの目的です。
発注者にとっての3つのメリット
1つ目は、大規模障害の影響を最小化できることです。仮に新バージョンに致命的なバグがあった場合でも、影響を受けるのは最初は5〜10%のユーザーに限られます。全ユーザーが一斉に不具合を踏むブルーグリーンデプロイメントと比べれば、カスタマーサポートへの問い合わせ集中・SLA 違反・信頼失墜のリスクが大きく下がります。
2つ目は、本番トラフィックでの検証精度が上がることです。ステージング環境ではどうしても再現できない負荷やデータパターンがあるため、実際の少数ユーザーで動かして初めて発見できる問題が存在します。カナリアリリースは、この「本番でしか分からない問題」を早期に発見できる仕組みだと言えます。
3つ目は、リリース失敗時のダメージを限定できることです。仮に拡大を中止して切り戻すことになっても、影響を受けたユーザーが限定的であれば、対応する顧客への謝罪・補償の範囲も限定されます。事業リスクの「上限」をあらかじめ制御できる、という点も発注者にとっては大きな価値です。
発注者が背負う3つのリスク・追加負担
一方で、カナリアリリースにはコスト面・運用面での追加負担が発生します。
まず、インフラ費用の増加です。新旧バージョンを同時に稼働させる期間が生じるため、その分の計算リソース・ネットワーク帯域・ロードバランサー機能などが必要になります。クラウド利用の場合、監視期間が長引けばそれだけ従量課金額も膨らみます。
次に、監視期間の延長による工数増です。ブルーグリーンなら切り替え直後の数時間で判定できるところ、カナリアでは段階拡大のたびに監視期間を設けるため、数日〜1週間に及ぶこともあります。この間、監視体制を維持するためのエンジニア工数や、深夜・休日の対応体制が必要になる可能性があります。
3つ目は、一部ユーザーだけ新バージョンになる状態のカスタマーサポート負荷です。「同じ画面のはずなのに、なぜか同僚は使えるのに自分は使えない」といった問い合わせが増えることがあります。BtoC サービスであれば、SNS 上での混乱にも配慮が必要です。
BtoB SaaS 特有の論点
BtoB SaaS を運営している場合、カナリアリリースには独自の注意点があります。
法人顧客との利用契約や SLA には、しばしば「機能の追加・変更については事前に通知する」といった条項が含まれています。カナリアリリース中は、一部の顧客だけが新バージョンを利用している状態になるため、この事前通知の考え方と齟齬が生じないか確認が必要です。
また、契約単位で「同一バージョンを全ユーザーに提供する」ことが明示・黙示的に前提となっているケースもあります。この場合、カナリア対象を「社内ユーザーのみ」「特定のオプトイン顧客のみ」に限定するなど、契約遵守と安全性検証の両立を図る設計が必要になります。承認判断の前に、法務・カスタマーサクセスと連携して既存契約の該当条項を確認しておきましょう。
発注者が承認前に確認すべきリスク管理チェックポイント7つ
ここからは本記事の中核となる、承認判断のためのチェックリストです。ベンダーから「カナリアリリースで行きます」と提案された発注者が、承認会議までに確認すべき7つの観点を、それぞれ「なぜ確認するか」「望ましい回答例」「回答が不十分だった場合のリスク」の3点で解説します。
1. 段階設計と最終判定基準
なぜ確認するか: カナリアリリースの中身は「段階設計次第」で大きく変わります。5%→100%を1時間で駆け抜けるのと、5%→25%→50%→100%を1週間かけて行うのとでは、安全性もコストも別物です。
望ましい回答例: 「初回5%を24時間監視し、閾値内であれば25%へ拡大、さらに24時間監視して50%、最後に100%へ。全展開の判定基準はエラー率0.5%未満・レスポンス時間の悪化20%以内・重大アラート0件です」
回答が不十分だった場合のリスク: 段階拡大の間隔や判定基準が曖昧だと、ベンダー側の主観で拡大が進み、発注者が気づいた時には全展開済み、といった事態になりかねません。定量的な基準を書面で残すことが重要です。
2. 監視対象とアラート閾値
なぜ確認するか: 「監視します」と言われても、何をどこまで監視するのかで検知力は大きく変わります。技術指標だけでなく、ビジネス指標も監視対象にすべきケースがあります。
望ましい回答例: 「エラー率・レスポンス時間・スループットの技術3指標に加え、決済成功率・重要フォームの送信完了率など事業クリティカルな指標も監視します。閾値超過時は Slack と電話で自動アラートします」
回答が不十分だった場合のリスク: 技術指標だけを監視していると、「エラーは出ていないが、なぜかコンバージョンだけが半減している」といった事業影響を見逃すことがあります。ビジネス指標を必ず監視対象に含めましょう。
3. 切り戻し（ロールバック）の手順と時間
なぜ確認するか: カナリアリリースの安全性は「異常を検知したら即座に切り戻せる」ことが前提です。切り戻しに何時間もかかる設計だと、その安全性は絵に描いた餅になります。
望ましい回答例: 「トラフィックのシフトによる切り戻しは5分以内に完了します。データベーススキーマ変更を伴う場合は、旧バージョンとの互換性を保った設計にしており、切り戻し後もデータ整合性は維持されます」
回答が不十分だった場合のリスク: 特にデータベースの変更を伴うリリースは要注意です。「切り戻したら過去数時間のデータが失われる」といった設計になっていないか、必ず確認しましょう。
4. 追加インフラ費用と工数の内訳
なぜ確認するか: カナリアリリースには追加インフラ費と監視工数が必ず発生します。「安全のためです」で予算超過を許容するのではなく、金額根拠を確認しましょう。
望ましい回答例: 「新旧同時稼働期間の追加インフラ費は月額10万円、監視工数は3日間×2名で60万円を見込んでいます。既存契約の運用保守枠内で吸収可能な範囲か、追加見積もりが必要か、承認前に整理してご提示します」
回答が不十分だった場合のリスク: 「後から追加請求が来た」というトラブルは典型的な発注者リスクです。承認時点で費用の内訳と上限を明確にしておくことが、後々の紛争予防につながります。
5. カナリア対象ユーザーの選定方針
なぜ確認するか: 「まず5%のユーザーに提供」と一言で言っても、その5%がランダムなのか、特定属性なのかで意味合いが変わります。BtoB SaaS の場合、契約単位での配慮が必要なケースもあります。
望ましい回答例: 「初回は社内ユーザーおよびオプトインしていただいたベータ顧客に限定します。第2段階から本番の一般ユーザーに5%ランダムで拡大し、企業アカウント単位ではなくユーザー単位で振り分けます」
回答が不十分だった場合のリスク: 「大口顧客のアカウントが初期カナリア対象に入っていて、そこで不具合が発生した」といった事態は避けなければなりません。対象選定の方針は事前に必ず握っておきましょう。
6. 障害発生時の連絡・エスカレーションフロー
なぜ確認するか: カナリアリリース中に問題が発生した場合、「誰が」「いつ」「どのチャネルで」発注者に連絡するかが不明確だと、発注者が事後に問題を知る羽目になります。
望ましい回答例: 「重大アラートは検知後15分以内に、担当エンジニアから発注者様の Slack チャンネルに一次報告します。電話連絡が必要な深刻度の場合は、あらかじめ共有した緊急連絡先へ即時電話します」
回答が不十分だった場合のリスク: 事後に「実は3日前から一部ユーザーで障害が発生していました」と報告されるようでは、発注者としての説明責任を果たせません。連絡フローは書面で合意しましょう。
7. SLA・契約への影響と顧客説明の要否
なぜ確認するか: BtoB SaaS を運営している場合、カナリアリリース中の状態が既存契約や SLA に抵触しないか、法務観点での確認が必要です。
望ましい回答例: 「カナリア対象は社内ユーザーとオプトイン顧客に限定するため、既存の SLA・利用規約には抵触しません。念のため、リリース予定は事前にステータスページで公表し、影響を受ける可能性のある顧客には事前通知を送付します」
回答が不十分だった場合のリスク: リリース後に「契約違反ではないか」というクレームを受けるリスクは、法務チーム・カスタマーサクセスとも早めに連携して潰しておく必要があります。承認前の確認事項として位置づけましょう。
障害発生時のより広範なトリアージや報告手順については、リリース後バグ多発の対応フロー｜PM・発注者が知るべきトリアージと報告手順 も併せて参照すると、リリース後のリスク管理の全体像が把握しやすくなります。
カナリアリリースが向くケース・向かないケース
ここまでの整理を踏まえ、「自社のシステムにカナリアリリースが本当に最適か」を判断するための基準を提示します。ベンダー提案を鵜呑みにするのではなく、代替方式を求めるべきかを見極めるための材料としてご活用ください。
カナリアリリースが向くケース
以下のような特徴を持つシステムでは、カナリアリリースが有効に機能しやすいと言えます。
- ユーザー数が多い: 数万ユーザー以上いれば、5%の対象だけでも数千人規模の検証データが得られます。統計的に意味のある監視が可能になります
- リスクの読めない新機能を含む: 使われ方が予測しにくい機能・アルゴリズム変更を含むリリースでは、本番トラフィックでの検証が有効です
- データ書き込みが軽い、または互換性がある: 新旧バージョンが同時に動いてもデータ整合性が保たれる設計であること
- 段階的な展開が業務に支障しない: 「一部ユーザーだけ新画面」の状態が数日続いても、業務・契約上の問題が発生しないこと
- 監視・オンコール体制が整っている: 監視期間中にアラートに対応できるエンジニア体制があること
カナリアリリースを避けた方がよいケース
一方、以下のようなケースではカナリアリリースは選ばない方が無難です。
- ユーザー数が少ない: 数百人規模のサービスでは、5%＝数十人しか対象がおらず、統計的な検証が成立しません。ブルーグリーンやローリングで十分です
- 契約上「同一バージョンを全ユーザーへ提供」が必須: 一部ユーザーだけ新バージョンになる状態が契約違反または利用規約違反になり得る場合
- 大規模なデータ移行を伴う: データベーススキーマの大規模変更や、マイグレーションが必要な変更では、新旧バージョンの同時稼働自体が困難です
- サービスの停止時間が許容できる: メンテナンス時間を確保できるなら、シンプルな一括切り替えの方が運用負荷が低くなります
- 監視・オンコール体制が不十分: 段階拡大中に異常を検知しても対応できない体制では、カナリアリリースの安全性は活かせません
代替手法を検討すべきタイミング
ベンダーから「カナリアで行きます」と提案されたとき、上記の「向かないケース」に該当していないかをチェックし、当てはまるものがあれば代替案の提案を求めましょう。以下の質問をベンダーへ投げるとよいでしょう。
- 「ブルーグリーンデプロイメントで即時切り替え＋高速ロールバックの方が、当社の要件に合いませんか？」
- 「ローリングアップデートで追加インフラ費を抑えつつ更新するのは検討されましたか？」
- 「そもそも今回のリリースで、段階的な展開が本当に必要でしょうか？」
こうした問いかけは、発注者としての知識を示すと同時に、ベンダーが「なんとなくカナリア」を選んでいないかを確認する機会になります。ベンダーが技術的合理性を持って答えられれば、その選択に安心して承認を出せますし、答えに詰まるようであれば設計の再検討を求める根拠になります。
まとめ｜承認前チェックリストとリスク管理の全体像
本記事では、カナリアリリースを「新バージョンを一部ユーザーに限定公開して安全性を検証する段階的リリース手法」と定義したうえで、発注者としての意思決定に必要な情報を整理してきました。最後に要点を1画面で振り返れる形で振り返り、発注者として身につけたいリスク管理の連続的な視点を示します。
カナリアリリース承認前チェックリスト
承認会議・ベンダー打合せの前に、以下の7点を確認しましょう。1つでも「回答が曖昧」「書面での合意がない」項目があれば、承認を保留にして再度説明を求めることをおすすめします。
- 段階設計と最終判定基準（何%ずつ、何時間ごと、判定閾値は何か）
- 監視対象とアラート閾値（技術指標＋事業指標、通知チャネル）
- 切り戻し手順と時間（何分で戻せるか、データ整合性はどう保つか）
- 追加インフラ費用と工数の内訳（金額根拠と上限）
- カナリア対象ユーザーの選定方針（ランダムか、特定属性か、社内限定か）
- 障害発生時の連絡・エスカレーションフロー（誰が、いつ、どのチャネルで）
- SLA・契約への影響と顧客説明の要否（既存契約との整合性）
発注者として身につけたいリスク管理の連続的な視点
カナリアリリースの理解は、発注者に必要な技術リテラシーの一部です。より上流の「用語の理解」、下流の「障害時対応」、横断的な「アジャイル開発全体のリスク管理」まで含めて連続的に押さえておくと、日々のベンダーとのコミュニケーションが格段にスムーズになります。
- 用語・全体像の理解: デプロイとは？発注者が知るべきリリース・インフラ展開の違いと確認事項7つ
- リリース後の障害対応フロー: リリース後バグ多発の対応フロー｜PM・発注者が知るべきトリアージと報告手順
- アジャイル外注全般のリスク管理: アジャイル開発の外注リスクをどう管理するか
リリース手法の選定は、技術チームに任せきりにするのではなく、事業影響・コスト・契約リスクを一番よく理解している発注者が主体的に関わるべき領域です。本記事のチェックリストを、次回のベンダー打合せでぜひ活用いただき、「なんとなく安全そう」ではなく「この設計だから安全と判断した」と自信を持って承認できる状態を目指してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- カナリアリリースとブルーグリーンデプロイメント、結局どちらを承認すべきか迷ったらどう判断すればよいですか？
ユーザー数が多く段階的な影響最小化を優先するならカナリアリリース、切り戻し速度と検証のシンプルさを優先し追加インフラ費を許容できるならブルーグリーンが適します。自社のユーザー規模と切り戻し要件を軸に選定してください。
- カナリア対象に大口顧客のアカウントが含まれていないか、契約前にどう確認すればよいですか？
対象選定方針（ランダムか特定属性か）を契約前にベンダーへ提示させ、選定ロジックが企業単位ではなく個々のユーザー単位になっているかを確認しましょう。大口顧客のみを除外リストとして明示させ、契約書面で選定基準を合意しておくと後々のトラブル予防に有効です。
- カナリアリリースの追加インフラ費用は発注者とベンダーのどちらが負担するのが一般的ですか？
既存の運用保守契約の範囲か追加見積もりが必要かは案件ごとに異なるため一律の相場はありません。新旧環境の並行稼働にかかる計算リソース代・監視要員の工数を項目別に見積もらせ、上限金額を書面で合意しておくと後日の追加請求トラブルを防げます。
- ベンダーが監視体制や判定基準を明確に説明できない場合、承認を保留すべきですか？
保留すべきです。段階設計・監視対象・切り戻し手順のいずれかが曖昧なまま承認すると、拡大判断がベンダーの主観に委ねられ、発注者が気づかないうちに全展開が進むリスクがあります。質問への回答が具体的な数値で返ってこない場合は、再説明を求めてから再度承認を検討してください。
- ユーザー数が少ない自社サービスでもカナリアリリースを検討する価値はありますか？
数百人規模のサービスでは5%が数十人程度にとどまり、母数不足で異常検知の統計的信頼性を確保しにくいため、基本的には向きません。同程度の安全性を求めるなら、フィーチャーフラグで社内限定公開してから全展開する運用も代替案として検討できます。
