AI基盤投資のROI懸念から学ぶ、SREが備えるべきコスト設計3点

GPU（画像処理用に設計され、現在は機械学習の並列計算に広く使われる半導体）を大量に抱えるデータセンターの採算性に、疑問の目が向けられ始めています。これはAI企業だけの話ではありません。社内でLLM（大規模言語モデル、大量のテキストから学習し文章生成や推論を行うAI）を使った機能を運用しているSREやインフラ担当者にとっても、無関係ではない構造の変化です。

ビットコインが8万5000ドルの高値から後退し、TeslaやMetaといった大手テック企業の決算に市場が冷ややかな反応を示した背景には、投資家心理の転換があります。AIを導入しているかどうかではなく、投じた資本に対する実際のリターン（投資対効果、ROIと略されます）が問われる段階に移っているという指摘です。この変化は、AI基盤を運用する側の設計思想にも影響を及ぼします。

なぜ「導入したこと」だけでは評価されなくなったか

背景にあるのは、LLMのスケーリング則（モデルの性能はデータ量と計算量を増やすほど向上するという経験則）が抱える構造的な問題です。性能を線形に伸ばそうとすると、計算コストは指数関数的に膨らみます。

たとえば、応答精度を少し改善するために、GPUクラスタの規模を倍増させても、得られる性能向上はそれに見合わないことがあります。ソフトウェアの進化速度と、それを支えるハードウェアコストの増加速度にギャップが生まれているという整理です。

この結果、投資家の関心は「AIがどれだけ高度か」から「その基盤コストは生産性向上で回収できるのか」へと移っています。企業の決算発表でCapEx（設備投資、サーバーやデータセンターへの資本的支出）の規模が注目されるのも、この延長線上にある動きです。

SREの現場に置き換えると何が起きるか

この視点は、社内のAI基盤運用にもそのまま当てはまります。GPUインスタンスやマネージドLLM APIの利用料は、トラフィックの伸びに比例しない形で膨らみがちです。

具体的には、推論リクエスト数が2倍になっても、レイテンシ要件を満たすために必要なインスタンス数やキャッシュ層の規模が、それ以上の比率で増えるケースがあります。これはAWSのSageMakerやGCPのVertex AIのようなマネージドサービスでも、自前でGPUクラスタをKubernetes上に構築する場合でも共通して起こりうる現象です。

この構造を前提にすると、SREがAI関連ワークロードに対して行うべき点検は、従来のSLO（サービスレベル目標、可用性やレイテンシの許容範囲を定めた指標）設計に加えて、コスト効率そのものをオブザーバビリティ（システムの内部状態を外部から観測できる仕組み）の対象に含めることです。

今日から確認できる3つの点検ポイント

抽象的な話で終わらせないために、実際に確認できる項目を整理します。

1. コストをSLOの一部として扱えているか

SLOは可用性やレイテンシだけで設計されがちですが、AI関連ワークロードでは「1リクエストあたりのコスト」もエラーバジェット（許容される障害・劣化の予算）と同様に監視対象にする価値があります。

# Prometheusでの簡易的なコスト効率メトリクス例
# GPU利用時間とリクエスト数から単価を算出するクエリ
sum(rate(gpu_seconds_used_total[1h])) / sum(rate(inference_requests_total[1h]))

このようなクエリをGrafanaのダッシュボードに組み込んでおくと、トラフィック増加とコスト増加の比率が線形かどうかを可視化できます。

2. IaCでGPUリソースの上限が固定化されていないか

TerraformやPulumiでインフラをコード化している場合、GPUインスタンス数やオートスケーリングの上限値を見直す価値があります。

# Terraformでのオートスケーリング上限の例
resource "aws_autoscaling_group" "gpu_pool" {
  max_size = 20
  min_size = 2
  desired_capacity = 4
  # コスト急増を防ぐスケールイン閾値を別途CloudWatchアラームで設定
}

max_size が過去の見積もりのまま放置されていないか、半年に一度は棚卸しする価値があります。スケーリング則のコスト非線形性を踏まえると、上限値の設計はSLO達成だけでなく予算防衛の役割も持ちます。

3. 障害対応フローにコスト異常検知が組み込まれているか

従来のインシデント対応は「可用性低下」をトリガーにしますが、AI基盤では「コスト急増」もインシデントとして扱う設計が有効です。GPUの予約インスタンスが切れてオンデマンド単価に切り替わった、特定のプロンプトが異常に長いトークンを消費している、といったケースは数時間で数十万円単位の差が出ることがあります。

観点	従来のSLO運用	AI基盤を含むSLO運用
監視対象	可用性・レイテンシ・エラー率	上記に加えてコスト効率・トークン消費量
IaCの見直し頻度	年次程度	四半期ごとの単価変動を踏まえた見直し
インシデントの定義	SLO違反のみ	コスト異常も含める

まとめ

AI基盤への投資がROIで厳しく評価される流れは、インフラを運用する側の設計にも波及します。

SLOにコスト効率の指標を組み込み、エラーバジェットと同様に監視する
TerraformやPulumiで管理するGPUリソースの上限値を定期的に棚卸しする
障害対応フローに「コスト急増」をインシデントとして扱う基準を追加する

まずは自分のチームのダッシュボードに、リクエスト数とGPU利用コストの比率を示すグラフが存在するかどうかを確認してみてください。存在しない場合、それが最初の改善点になります。