運用コスト可視化の方法

「どのコストを誰の意思決定で下げるか」を最初に決める

可視化で迷子になる理由の多くは、対象範囲が曖昧なことです。サーバ監視運用では、コストの箱を4つに分け、持ち主をはっきりさせると動きが速くなります。固定費（監視ツール、ログ保管、ライセンス）、変動費（クラウドのCPU/ストレージ/転送料、ログ発生量）、人件費（当番、チケット対応、定例・レビュー）、品質コスト（インシデント、SLO逸脱、誤検知対応）です。各箱に紐づく“決められる人”を先に置き、見たい単価を定義します。

意思決定に直結する指標セット

• アラート単価 = 当番時給 × 対応時間（h） × 対応人数
• インシデント単価 = アラート単価合計 + 影響額（カート離脱・SLAペナルティ等の推定）
• サービス月額 = 監視SaaS費用按分 + クラウド請求（タグ集計） + 人件費按分
• ノイズ率 = 終了チケットのうち「手動作業なし/再発防止不要」で閉じた割合
• MTTD/MTTR、変更失敗率、SLO消費率（Error Budget Burn）

しきい値を最初に置きます。例：ノイズ率20%以下、アラート単価800円未満、SLO消費率が週あたり25%を超えたらタスクを停止して安定化へ。これがない可視化は“きれいな壁紙”で終わります。

計測の設計：タグ・スキーマ・自動化で抜け漏れを塞ぐ

ダッシュボードは後回しで構いません。まずデータを拾う導線を作ります。コストは発生源でタグをつけ、作業は開始/終了を自動で刻み、アラートは意味づけラベルを持たせます。集計粒度は「サービス/環境/チーム/重要度」の4軸が基本です。

最小で回る必須データ

• クラウド請求のタグキー：service, env, team, criticality（未タグは“others”に強制集約）
• アラートのラベル：runbook_id、source（メトリクス/ログ/トレース）、owner、severity
• 当番スケジュールと実働時間：ページャーの通知から自動採取、Slackの開始/終了スタンプ
• チケット種別：障害/予兆/誤検知/変更、所要時間（30分刻みで自動丸め）
• 共通費の按分ルール：ログ保管やNAT転送料はイベント数やリクエスト数で割る等

整形やスクリプト化は、Copilotでシェル/SQLのたたき台を作り、ChatGPTやClaudeで正規表現やログのパースを補助させると初期立ち上がりが速いです。大量のアラート注記から「実作業の有無」を抽出するのにGeminiを使い、誤検知候補をフラグする、といった使い方もあります。機微情報は匿名化し、AIへの投入は要ポリシー整備です。

落とし穴はダブルカウントと“共通費の無限按分”です。クラスタ共通のログ保管を各サービスに100%ずつ乗せてしまうなど。按分キーは1つに統一し、未割当は“プラットフォーム費”で別建てにします。

ダッシュボード設計：1枚で判断できる切り口

ページ構成の定番

• 経営サマリ：今月総額、先月比、1リクエスト単価、SLO消費率。しきい値超過は色で強調。
• サービス別P&L風：収益/トラフィックに対する運用比率、アラート単価、ノイズ率、担当チーム。
• SRE向け深掘り：ノイズ上位アラート、メトリクスのカーディナリティ上位、静音化候補、無視率。
• 工数ヒートマップ：曜日×時間帯の当番実働、深夜帯の占有率、連続覚醒の危険ライン。

“見えたら終わり”にしないために、カードごとにアクションを紐づけます。例：ノイズ率>20%かつアラート単価>800円 → 閾値再設計/集約/自動修復の三択から選ぶ。SLO消費率が週25%超 → 新機能リリースを一時停止し、Error Budgetを回復させる。カードにRunbookやチケット雛形のリンクを直結すると、意思決定がその場で終わります。

現場で効く目標レンジ

• アラート単価：500〜800円（24/7当番、月あたり1000件規模を想定）
• ノイズ率：20%以下（誤検知＋情報通知で作業なし）
• 深夜帯実働：総実働の15%以下（健康指標）
• MTTR：重要度P1で30分未満、P2で2時間未満

数値は万能ではありませんが、レンジがあると議論が進みます。達成できない場合は、検知の粒度、オンコール体制、キャパシティ計画のどこを動かすかを特定できます。

身近な企業活用例：中堅ECの失敗と改善

自社ECと在庫APIを運営。監視は増やしたが、月の運用費が不透明で、当番2名が燃え尽きかけていました。症状は「夜間の誤検知多発」「ログ保管費の肥大」「インシデント後の振り返りが形骸化」。意思決定者はCFOと開発部長でしたが、指標が噛み合わず議論が空中戦に。

取り組みは3点。1) すべてのクラウド資源とアラートにservice/env/team/criticalityタグを強制。未タグはCIで失敗させる。2) アラートにrunbook_idを付与、Slackの対応開始/終了スタンプをBotで必須化。3) ダッシュボードに“アラート単価”“ノイズ率”“SLO消費”を追加し、しきい値超過時は自動で改善チケットを生成。スクリプトの雛形はCopilotで作り、誤検知パターン抽出はChatGPTとClaudeにアラート本文を要約させ、Geminiで深夜帯の発火傾向を可視化しました。

結果、3カ月でアラート件数は-60%、ノイズ率は35%→12%、アラート単価は1,150円→620円。ログ保管は保持期間の層別化で-22%。当番の深夜実働は-38%となり、P1のMTTRは45分→18分に短縮。CFOは「サービス別P&L」でEC本体の1注文あたり運用単価を38円→24円と把握でき、開発部長は“ノイズ上位5ルール”の削除/閾値調整/自動修復化（キャッシュ再起動の自動化など）に投資判断できるようになりました。失敗は、最初に共通費をすべて等分してしまい、APIのコストが過小評価されたこと。按分キーをリクエスト数に変えて解消しました。

可視化のコツは、数字を“誰が何をやめる/始めるか”に直結させることです。タグで原価を正しく集め、アラートに意味を持たせ、しきい値にアクションを紐づける。サーバ監視運用事業の現場では、監視設計の段階でこの仕組みを組み込み、SLO・当番・コストの三角形を同じダッシュボードに載せると、運用は静かに、そして強くなります。