新機能が急にバズり、ダッシュボード上のトラフィックが数日で桁違いになった経験はないでしょうか。Meta が2026年9月に投入した「パーソナルAIエージェント」Muse は、公開直後にApptopia調査で米国内600万人超の日次アクティブユーザー（DAU、1日あたりの利用者数を示す指標）を記録し、iOS App Storeのランキング上位に入りました。こうした急成長期に運用側で起きがちな落とし穴を、SRE（サイト信頼性エンジニアリング、システムの信頼性を工学的に担保する役割）の視点で整理します。
対象となるのは、新機能や新プロダクトが短期間でユーザー数を伸ばし、運用チームが後追いで容量計画やSLO（サービスレベル目標、可用性やレイテンシの目標値）の見直しを迫られている方です。「炎上上等でとにかく出す」判断がビジネス側で下された後、インフラ側に何が残るかを具体的に見ていきます。
何が起きるか：優先順位の入れ替わりが可観測性の穴を生む
急成長プロダクトの裏側では、しばしば「次の優先事項への乗り換え」が起きます。Zuckerberg自身、内部のやり取りで児童安全対策よりもメタバースへの注力を優先すると明言していたことが、訴訟で開示された資料からわかっています。
組織のトップの関心が次の目玉プロジェクトに移ると、既存機能の監視体制は更新されないまま放置されがちです。具体的には、次のような事象が起きます。
- 新機能用のダッシュボードは作られるが、既存システムとの依存関係を示すトレーシング（リクエストの経路を追跡する仕組み）が後回しになる
- SLOがローンチ時の想定トラフィックのまま固定され、実際の利用者数増加に追随していない
- オンコール体制の人員やエスカレーション先が、旧優先度のまま更新されていない
Museのように短期間でDAUが桁違いに増えるケースでは、この「可観測性の穴」が障害発生時の初動を遅らせる直接原因になります。
なぜ起きるか：意思決定のスピードと運用の整備速度がずれる
原因を段階的に分解すると、まず経営判断のスピードが先行します。新規プロダクトの投入判断は数週間単位で決まる一方、SLI（サービスレベル指標、実際の稼働状況を測る値）の再定義やアラート閾値の調整には、依存サービスの棚卸しなど数週間から数か月かかる作業が伴います。
次に、組織内のインセンティブのずれがあります。ローンチの成功指標は「DAU」「App Store順位」のような外向きの数字で評価されがちです。一方、可用性やエラーバジェット（許容できる障害時間の予算）の消費状況は、外部への説明責任が弱く後回しにされやすい構造があります。
さらに、IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）の運用が追いついていないケースもあります。TerraformやPulumiでインフラを管理していても、急増したトラフィック用のオートスケール設定やリソース上限が、コードレビューを経ずに手動変更（いわゆる「setting drift」）されると、次回のterraform planやpulumi previewで意図しない差分が検出され、変更履歴の追跡が難しくなります。
自分のプロジェクトが該当するか確認する方法
以下の観点で、自分のチームが同じ落とし穴にはまっていないか確認できます。
- SLOの見直し日付を確認する：SLO定義ファイルやWikiの最終更新日が、直近のトラフィック急増より古い場合は要注意です
- IaCの差分を確認する：
terraform planやpulumi previewを実行し、意図しない手動変更（drift）が出力されないか確認します - アラート閾値の妥当性を確認する：現在のトラフィック量に対して、過去のインシデント発生時のメトリクス値をダッシュボードで比較します
- オンコールローテーションの担当範囲を確認する：新機能のサービス群がオンコール表に明記されているか確認します
# IaCのドリフト検出例（Terraform）
terraform plan -detailed-exitcode
# 終了コード2は差分あり、0は差分なしを意味する
echo $?このコマンドで差分が出続ける場合、手動運用とコード管理が乖離しているサインです。
対策の手順
落とし穴にはまらないための対策は、次の順序で進めるのが現実的です。
1. エラーバジェットの再計算：直近30日のトラフィックとインシデント件数から、現行SLOが現実的か再計算します。GoogleのSRE本で紹介されているエラーバジェット方式（許容ダウンタイムを事前に予算化する考え方）を使うと、経営判断とのすり合わせがしやすくなります。
2. IaCのコードレビュー必須化：緊急スケール対応であっても、変更は必ずプルリクエスト経由でTerraform/Pulumiのコードに反映し、手動コンソール操作を禁止するポリシーをCIに組み込みます。
3. オブザーバビリティの棚卸し：新機能リリース前に、依存サービスのトレース・ログ・メトリクスが揃っているかチェックリストで確認します。OpenTelemetry（分散システムの計測を標準化するフレームワーク）の導入状況を合わせて確認すると抜け漏れが見つかりやすくなります。
4. オンコール表の更新をリリースチェックリストに追加：新プロダクトのローンチ承認フローに、オンコール担当・エスカレーション先の明記を必須項目として組み込みます。
まとめ
急成長プロダクトの裏側では、優先順位の入れ替わりが可観測性の穴を生みやすいことを確認しました。
具体的な確認の第一歩として、terraform plan や pulumi preview でドリフトの有無を今すぐチェックしてみてください。
SLOの最終更新日とエラーバジェットの消費状況も、次のスプリントで見直す価値があります。
ビジネス側の「次の優先事項」への切り替えは避けられない場合もありますが、インフラ側の棚卸しを定例化しておくことで、急成長時の初動対応の質を落とさずに済みます。