インフラ担当者を悩ませる「深夜のジレンマ」と解決の糸口
深夜2時、静まり返った部屋に鳴り響くPagerDutyのアラート音。インフラエンジニアやSRE（Site Reliability Engineering）にとって、これほど心臓に悪い音はないだろう。原因は突発的なアクセス集中によるサーバーダウンか、あるいはバッチ処理の遅延か。
こうした「万が一」の事態を避けるために、インフラ運用においては深夜帯であってもリソースを過剰に確保（プロビジョニング）しがちである。日中のピーク時に合わせた台数をそのまま維持したり、あるいは「念のため」という理由で、必要以上のバッファを積むケースは多い。
クラウドインフラのリソース管理は、物流における倉庫の在庫管理や配送トラックの最適化と共通する点がある。「在庫（リソース）」を持ちすぎれば保管コストや待機コストが増加し、少なすぎれば「欠品（サービスダウン）」につながる。このトレードオフを解消するために、物流の世界では高度な需要予測と安全在庫（Safety Stock）の概念を用いる。
本記事では、この物流DXの知見をインフラ運用に応用し、AIによる需要予測と「安全係数」を組み合わせることで、可用性を一切犠牲にせず、深夜帯のコンピュートコストを定量的に削減する方法を解説する。AIに全権を委ねるのではなく、人間が設計した安全策（ガードレール）の中でAIを稼働させるアプローチについて見ていく。
なぜ「深夜の固定台数」は見直すべきなのか：コストとリスクの再評価
「深夜はアクセスが少ないから、稼働するサーバーの台数を半分にしておこう」。そう決めて静的なスケジュールを設定したものの、予想外のトラフィック増でレスポンスが悪化し、結局元の台数に戻した。このようなケースは、決して珍しくない。
物流現場でも、「夜間のトラック配車を減らしたら、想定外の夜間入荷で現場が混乱した」という事態は頻発する。安全を重視するあまり過剰なリソースを抱え込む構造は、ITインフラも物流も同じである。しかし、クラウド技術が急速に進化する現在、固定的なスケジュール管理は時代遅れになりつつある。
深夜帯の「空転リソース」が食いつぶす年間予算の試算
まず、現状維持がいかに高コストであるかを直視する必要がある。例えば、AWSの m5.large インスタンスをWebサーバーとして運用していると仮定する。日中のピークに合わせて20台稼働させており、深夜（0:00〜6:00）の実需は2台分しかないにもかかわらず、「急激なアクセス増が怖いから」という理由で10台稼働させているケースである。
この場合、8台分は完全に「荷物を積まずに走っている空のトラック」と同じ状態である。1台あたりのコストが小さくても、年間で見れば数十万円から数百万円単位の無駄を生み出す。特にリレーショナルデータベースのようなステートフルなリソースの場合、サイズを大きくしすぎているコストインパクトは甚大である。
近年、AWSの準公式情報（2026年2月時点）などでも示されている通り、クラウドインフラは「静的な確保」から「動的な最適化」へと明確に舵を切っている。例えば、Amazon OpenSearchの自動最適化機能のように、従来の手動スケジュールを不要とし、高負荷時にのみリソースを柔軟に割り当てつつコスト上限を設定できるような仕組みが標準化されつつある。このような技術トレンドの中で、深夜に固定台数を抱え続けることは、予算の観点から非常に非効率だと言える。
ルールベース（閾値）スケーリングの限界とAI予測の優位性
「オートスケーリングを入れているから大丈夫」と考えるケースもある。しかし、従来の「CPU使用率が60%を超えたら1台追加する」といったリアクティブ（反応型）なルールには、構造的な弱点が存在する。
それは「反応遅延」という問題である。
閾値を超えてから新しいインスタンスが起動し、ロードバランサーに組み込まれてリクエストを処理できるようになるまで、どうしても数分間のタイムラグが発生する。この数分間こそが、レイテンシ（遅延）の悪化や503エラーを引き起こすボトルネックとなる。物流で言えば、急な大量注文が入ってから慌ててトラックを手配し、到着を待たせている状態に他ならない。
一方、AIを用いたプロアクティブ（予測型）なスケーリングは、「未来の需要」を先読みする。「今夜の3時にはアクセスが増える」と予測できていれば、3時になる前にインスタンスを起動完了させておくことができる。最近では、Amazon BedrockやSageMakerといったAIプラットフォームの機能拡張により、高度な予測モデルをインフラ管理に組み込むハードルも下がってきた。つまり、AI予測は単なるコスト削減ツールである以上に、「ユーザー体験を守るための可用性向上ツール」として機能する。
「AIに任せるのが怖い」心理的障壁の正体
それでもAIによる自動化の導入が進まない理由の一つに、「AIが予測を外したらどうするのか？」という不安があるのは当然である。予測が下振れしてリソース不足に陥れば、即座にサービス障害につながる。
ここで重要なのが、「AIの予測値をそのまま鵜呑みにしない」というスタンスである。物流の世界でも、AIが「明日の注文は100個」と高精度な予測を出したとしても、現場にはあえて「120個」用意させることがある。この上乗せ分こそが安全係数（Safety Margin）と呼ばれるものである。
この考え方をインフラのプロビジョニングにも適用することで、心理的な障壁は大きく下がる。AIが弾き出した需要予測に対して、ビジネスの重要度に応じた一定のバッファ（安全係数）を上乗せしてスケーリングの目標値を設定する。こうすることで、予測のブレを吸収しつつ、旧来の「とりあえず半分」といったどんぶり勘定よりもはるかに無駄のないリソース管理が実現できる。
導入前の必須準備：現状分析と「予測しやすさ」の評価
いきなりツールを導入するのはリスクを伴う。まずは対象のシステムが「AIで予測しやすい動き」をしているかを診断する必要がある。
トラフィックパターンの周期性診断（Seasonality Analysis）
AIが得意なのは、データに明確なパターンが存在する場合である。
- 日次周期（Daily Seasonality）: 毎日お昼と夜22時にピークが来る。
- 週次周期（Weekly Seasonality）: 平日は多いが土日は少ない、あるいはその逆。
CloudWatchやDatadogの過去3ヶ月分のメトリクスをCSVでエクスポートし、グラフ化して確認する。きれいな波形を描いているなら、AI導入の可能性は高い。逆に、ランダムなノイズだらけであれば、AI予測の導入は見送るべきである。
AIモデルが苦手とする「スパイク」の特定と除外
テレビ放映やSNSでのバズによる突発的なスパイク（急増）は、過去のデータに基づかないため、AIでも予測不可能である。これらを学習データに含めてしまうと、モデルが「通常時でもスパイクが起きるかもしれない」と誤学習し、予測精度が歪んでしまう。
データクレンジングの段階で、明らかに異常値とわかるスパイクは除外するか、あるいは「イベントフラグ」を立ててAIに「これは特別な日だ」と認識させる処理が必要となる。
ベースラインとなるリソース使用率の策定
「CPU使用率何%を維持するのが理想か？」という目標値を定める。通常は40〜50%程度を目安にするが、AI予測導入初期は、より安全側に倒して30〜40%をターゲットにするのも一つの手法である。余裕を持たせることで、予測誤差を吸収できるからである。
Step 1：安全係数（Safety Margin）を組み込んだ予測モデルの設計
ここからが具体的な設計フェーズである。インフラのリソース管理において、「AI予測スケーリング」単体での運用は推奨されない。物流の現場において、需要予測AIの数値をそのまま信じて倉庫の在庫をギリギリまで削ることが危険であるのと同じである。突発的な需要のスパイクに対応するため、必ず従来型のルールベースと組み合わせたハイブリッド構成を設計する。
予測値に上乗せする「バッファ」の計算式
AIが算出した予測値（$\hat{y}$）をそのまま必要台数とするのではなく、物流における「安全在庫」に相当するバッファを持たせる。基本的な考え方は以下の通りである。
$ 必要台数 = \text{AI予測に基づく台数} \times (1 + \text{安全係数}) $
例えば、AIが「深夜3時の必要台数は5台」と予測した場合、安全係数を0.2（20%）と設定すれば、6台（$5 \times 1.2$）を確保する。
さらに精度の高い手法として、予測モデルが出力する信頼区間（Confidence Interval）の上限値を活用するアプローチがある。Prophetなどの時系列予測モデルは、「95%の確率でこの範囲に収まる」という幅を持った予測を算出できる。この「上限値（p95）」をターゲットに設定すれば、理論上95%の確率でリソース不足を未然に防ぐことが可能となる。
ハイブリッド方式（AI予測 + 閾値トリガー）の推奨
夜間のシステム運用において最も確実なのは、以下の二段構えの構成である。
- ベースライン（AI予測）: 過去のトレンドや周期性に基づき、事前に緩やかなスケールアウトおよびスケールインを実行する。
- ガードレール（閾値ルール）: 予測が外れてCPU使用率が急激に上昇した場合、従来の「CPU > 70% で追加」といったルールを即座に発動させ、緊急回避する。
このハイブリッド方式を採用すれば、万が一AIの予測が外れたとしても、従来型のオートスケーリングが命綱として機能する。また、Amazon CloudWatchの最新機能であるアラームミュートルールなどを組み合わせることで、計画的なリソース変動時の不要な通知を抑制し、SREの負担を軽減する工夫も重要である。
コスト削減よりも「可用性維持」を優先するパラメータ調整
AWSのAuto Scalingに備わっている「予測スケーリング（Predictive Scaling）」を活用する場合、設定モードの選択が運用成功の鍵を握る。
- Forecast only: 予測の推移を監視するのみ（実際のスケーリングは行わない）。
- Forecast and scale: 予測に基づいて実際にリソースを増減させる。
導入初期は必ず「Forecast only」で数週間稼働させ、実際のトラフィックとAI予測値の乖離（ズレ）を定量的に評価することが求められる。そして「Forecast and scale」へ移行する際も、スケールイン（台数を減らす動作）は極力緩やかに設定することが重要である。急激なリソース削減は、直後に発生するトラフィックのリバウンドに対応できず、障害の引き金になる。最近のクラウドリソース管理では、コスト上限を設定しつつ高負荷時に自動最適化を行う機能（Amazon OpenSearchの自動最適化など）がトレンドとなっているが、インフラのスケーリングにおいても「コスト削減」より「可用性維持」を最優先としたガードレールを設けることが、確実な運用につながる。
Step 2：影響範囲を限定したパイロット運用と検証
設計ができても、いきなり本番環境の全リージョンに適用するのはリスクがある。小さく始めて成果を可視化し、段階的にスケールアップするアプローチが有効である。
非本番環境での「擬似深夜トラフィック」テスト
ステージング環境などで、負荷テストツール（JMeterやk6など）を使い、過去の深夜トラフィックを再現する。そこでAI予測スケーリングがどう動くか、意図通りに事前にスケールアウトするかを確認する。
カナリアリリース的な適用範囲の拡大（1AZから開始など）
本番適用においても、特定のアベイラビリティゾーン（AZ）や、一部のサーバーグループだけにAIスケーリングを適用する「カナリアリリース」の手法が有効である。
例えば、全体の20%のトラフィックを処理するグループにのみ新設定を適用し、残りの80%は従来設定のままにする。これなら、万が一AIが誤判断をしてリソースを絞りすぎても、影響は限定的となる。
監視すべきKPI：レイテンシ悪化の予兆検知
見るべき指標は「コスト削減額」ではない。それは結果であって、運用中のKPIではない。最優先で監視すべきは「レイテンシ（応答速度）」と「エラーレート」である。
AIによるスケールイン（台数削減）が行われた直後に、レイテンシが悪化していないか。ここを重点的にモニタリングする。もし悪化が見られたら、安全係数が不足していると考えられるため、すぐに設定を見直す必要がある。
Step 3：本格展開と「人間による監視」の最小化
パイロット運用で効果が確認できたら、いよいよ適用範囲を広げる段階である。しかし、運用担当者が毎晩ダッシュボードに張り付いて監視を続けるようでは、SREとしての負担軽減という本来の目的を果たせない。深夜帯の担当者の負担を増やさず、システムが自律的に動く仕組みを整えることが重要である。
アラート通知の最適化（過剰検知を防ぐ）
AIによるスケーリング導入後は、無駄な余剰リソースが削ぎ落とされるため、リソース使用率が従来よりも高めに推移するのが正常な状態となる。そのため、過去の固定的なアラート閾値（例えば「CPU使用率が80%を超えたら警告」など）のままでは、深夜に不要な通知が頻発する原因になる。
アラートの設定値は根本的に見直す必要がある。固定値の閾値に依存するのではなく、異常検知（Anomaly Detection）を活用し、「通常の変動パターンから明らかに逸脱した場合」のみ通知する動的な設定への切り替えが有効である。さらに、最新のクラウド環境ではアラート管理機能が進化している。例えば、Amazon CloudWatchのアラームミュートルールのような機能を活用すれば、計画的なメンテナンスや特定のリソース最適化処理が走る時間帯だけ通知を抑制でき、SREの負担を効果的に軽減できる。
月次でのモデル再学習と精度評価サイクル
エンドユーザーの行動パターンは常に一定ではない。季節の変わり目や新しいキャンペーンの開始など、数ヶ月も経てば深夜のトラフィック傾向が大きく変化していることも珍しくない。
現在、多くのクラウドインフラのマネージドサービス（AWS Auto Scalingなど）は、リソースの自動最適化やモデルの再学習をバックグラウンドで継続的に実行する機能を備えている。インフラの高負荷時でも常時自律的に調整を行うような運用も一般的になってきた。しかし、完全に放置するのではなく、月に一度は予測モデルのレポートを確認し、RMSE（二乗平均平方根誤差）やMAPE（平均絶対パーセント誤差）といった予測精度の指標が悪化していないか、人間の目でチェックするサイクルを設けることが推奨される。これはインフラを支える「AIの健康診断」として不可欠なプロセスである。
異常時の緊急停止スイッチ（キルスイッチ）の整備
どれほど入念にチューニングされた予測モデルであっても、突発的なスパイクや未知の障害など、想定外の事態は必ず発生する。AIの予測が実態と大きく乖離し、インフラの挙動が不安定になった際、即座にAIによる自律制御を切り離し、安全な固定台数や従来のルールベースのスケーリングに戻せる「キルスイッチ（Kill Switch）」を必ず整備するべきである。
運用手順書（Runbook）の目立つ場所に「AI制御の緊急停止・切り戻しコマンド」を明記しておくことは、単なる障害対策にとどまらない。いざという時に確実にシステムを保護できるという事実が、深夜のオンコール対応にあたるSREの心理的負担を劇的に軽くし、安定した運用環境の実現に繋がる。
ROI測定と社内報告：削減効果を正しく伝える
プロジェクトの締めくくりは、成果の証明である。単に「安くなりました」だけでなく、ビジネスへの貢献を定量的に語ることが重要である。
削減コスト vs AI運用コストの損益分岐点
クラウドの請求額が月額10万円下がったとしても、その管理にエンジニアが時間を使っていたら効果が薄れる。AI導入によって運用が自動化され、「エンジニアがリソース調整にかける時間がどれだけ減ったか」も重要なROI（投資対効果）の一部である。
「何も起きなかったこと」の価値証明
インフラエンジニアの仕事は、何事もない日々を作ることである。しかし、それは評価されにくい。
「この3ヶ月間、深夜帯のリソースを30%削減したが、サービス稼働率は99.99%を維持し、レイテンシの悪化もゼロであった」。このように、攻め（コスト削減）と守り（品質維持）の両立を数字で示すことで、経営層や他部署からの理解を得ることができる。
次なる展開：スポットインスタンスとの併用戦略
需要予測の精度が上がれば、さらにコスト削減が可能になる。例えば、ベースロード部分はリザーブドインスタンスで固め、予測されるスパイク分には安価なスポットインスタンスを充てる、といったポートフォリオを組むことも可能である。
物流の世界で、自社トラックと傭車（スポット便）を使い分けるのと同じ戦略である。エンドツーエンドのサプライチェーンを俯瞰するようにインフラ全体を見渡すことで、ITリソースの最適化をさらに推し進めることができる。
まとめ：AIを「頼れる同僚」にするために
深夜帯のリソース最適化は、単なるコストカットではない。それは、過剰な不安から解放され、エンジニアが本来注力すべき業務に時間を割くための取り組みである。
重要なポイントを振り返る。
- AIを過信しない: 予測値には必ず「安全係数」というバッファを持たせる。
- ハイブリッドで守る: 予測スケーリングと反応型スケーリングを併用し、二重の安全網を作る。
- 小さく始める: カナリアリリースや非本番環境での検証を経て、段階的に適用する。
「落とすのが怖い」という感覚は、プロフェッショナルとして自然なものである。その恐怖心を、安全係数というロジックで管理し、AIを「魔法の杖」ではなく「頼れる同僚」として活用していくことが求められる。
コメント