経営層はCPU使用率を見ない——情シスが翻訳すべきGrafana監視画面の作り方
「サーバーの状況をグラフで持ってきました」
そう言って経営会議室のスクリーンに映したのは、縦軸がパーセンテージ、横軸が時刻のCPU使用率グラフだった。
沈黙の後、CFOが口を開いた。「で、問題あるの?」
答えられなかった。グラフは正常範囲を示していた。でも「正常」という言葉が経営層に何を意味するのか、その場で翻訳できなかった。あの瞬間の感覚は、Prometheus+Grafanaをどれだけ丁寧に設定しても消えない。画面の問題でなく、言語の問題だからだ。
エンジニア向け画面と経営層向け画面は、目的が違う
「きれいに整えれば経営層にも見せられる」という考え方がある。配色を整え、パネルを並べ、ラベルを日本語化する。それで伝わると思っていた時期がある。
伝わらない。なぜなら画面の問題ではないからだ。
エンジニアが監視画面で見ているもの
Grafana公式ドキュメントが定義する監視メソッドには、USE法（Utilization・Saturation・Errors）、RED法（Rate・Errors・Duration）、Four Golden Signals（Latency・Traffic・Errors・Saturation）がある。
これらはすべて「障害の原因を特定する」ための言語だ。エンジニアはグラフの形状から異常を読み、原因箇所を絞り込み、対処する。CPU使用率の急騰はその文脈では意味のある情報になる。
経営層がダッシュボードで知りたいこと
Grafana公式ブログは明確に述べている。「An engineer has a very different goal when using a Grafana dashboard compared to a product manager.」
経営層が知りたいのは、障害の場所ではない。事業への影響だ。「システムは動いているか」「動いていない時間はどれくらいか」「それは前月より良くなっているか悪化しているか」——この三問に答えられない画面は、経営層にとって存在しないのと同じだ。
hawatel.comが指摘する通り、組織で最も多い課題のひとつは「統一されたKPIビューの欠如」にある。部門ごとに異なるレポート形式が存在し、経営判断を難しくしている。
技術指標を経営言語に変換する3つの方法
変換作業は抽象論ではない。具体的な3つの変換パターンがある。
①稼働率（%）への変換——Four Golden SignalsをSLO達成率に見せる
Four Golden Signalsをそのまま見せても経営層には読めない。これをSLO（Service Level Objective）達成率として表示することで、意味を持たせられる。
設計の方向性はシンプルだ。Grafana上でエラーレートと可用性のデータからSLO達成率を計算し、単一の数値パネルとして表示する。「今月の稼働率: 99.8%」という形式なら、技術的な文脈がなくても意味が通じる。
Grafana公式ドキュメントはSLOベースのダッシュボード設計を推奨している。Four Golden SignalsはSLO達成率の計算素材として使うのが、経営層向け画面での正しい使い方だ。
②ダウンタイムの「ビジネス影響」への変換
KDDIアイレットの事例が参考になる。Amazon Managed Grafana（AMG）を使った社内サービス可視化で、1枚のダッシュボードに各サービスの「SLO」「効果」「導入率」を並べた構成を実現している。技術的な稼働状況と、ビジネス上の成果を同一画面に置いた設計だ。
この考え方を自社に応用するなら、月間ダウンタイム分数を起点に「事業への影響」を試算する欄を設けることが有効だ。たとえば月間ダウンタイムが30分だったとして、その間にどれだけのトランザクションが止まるかを推定値で示す。数値の精度より「ビジネス影響を考えた形跡」が重要で、それが経営層との共通言語になる。
③トレンド比較——Time seriesを「傾向確認」として使う
Time seriesパネルはエンジニアが詳細なスパイクを読むための道具だが、経営層向けには「傾向の確認」として使う設計にする。
具体的には、表示期間を直近1時間ではなく「今月vs前月」に変える。軸の粒度を落として大きな傾向だけが見えるようにする。「改善しているか悪化しているか」を一目で判断できる形にすることが目的だ。詳細は別の画面に分離する。
経営層向けダッシュボードの設計原則
何を置くかより、何を消すかの方が難しい。
Master-Detailed構造で分離する
業界で広く参照される設計手法として、Master-Detailed構造がある。経営層向けの概要画面（Master）と、エンジニアが掘り下げる詳細画面（Detail）を別々に設計し、ドリルダウンリンクで接続する方法だ。
実装上のポイントは「Masterを見ただけで意思決定できること」だ。詳細が欲しい場合はリンクを辿る。経営層がDetailを開く必要は原則ない。
情報の優先度を視覚で伝える
Grafanaのパネルには閾値（Threshold）設定がある。正常・警告・危険を色で区別できる。経営層向け画面ではこの色分けが特に重要で、「赤いパネルがあれば問題がある」という読み方だけ共有しておけば、細かい説明が不要になる。
パネル数は一般的に5〜7個を目安とする声が多い（出典となる公式規定はなく、実務上の目安として広まっている数値だ）。それ以上になると視線が散り、重要なシグナルが埋もれる。
閲覧専用の権限設定
経営層に配布するダッシュボードは、編集権限を与えない。GrafanaのOrganization設定でViewerロールを割り当てることで、閲覧のみの権限に制限できる。
Amazon Managed Grafana（AMG）を利用している場合は注意が必要だ。watchittrend.comによると、AMGは閲覧ユーザーにも課金が発生する構造になっている。経営層や管理職への配布を想定する場合、ユーザー数に応じたコストが積み上がる点を事前に確認しておく必要がある。
アラート設計——経営層には「結論だけ」届ける
監視基盤が完成しても、アラートの設計が間違っていると意味がない。
エンジニア向けアラートと経営層向けアラートを分ける
LogicMonitorの調査が示す通り、アラートには偽陽性と偽陰性のトレードオフがある。「偽陰性を減らそうとすると偽陽性が増える」という構造上の問題だ。エンジニア向けには早期検知を優先して多少の偽陽性を許容するが、経営層向けには「本当に問題が起きたとき」だけ通知する設計にする。
具体的には、SLOが実際に違反した場合——つまり稼働率が規定値を下回った場合のみ経営層に通知するアラートルールを別系統で設ける。エンジニアへの詳細アラートとは独立して設計する。
Keep firing forで繰り返し通知を防ぐ
Grafana Alertには「Pending period」と呼ばれる設定がある。zenn.devでの解説によると、Pending periodを5分に設定すると「5分間連続でアラート条件に合致した場合のみ発報する」動作になる。瞬間的なスパイクで通知が飛ぶ偽陽性を減らせる。
経営層向けアラートではこの設定を長めにとる——たとえば10〜15分——ことで、一時的な高負荷による誤通知を抑制できる。通知を受け取る側が技術的な文脈を持たないほど、誤通知のコストは大きくなる。
セルフホスト運用の現実——設計より維持の方が重い
ここまで設計の話をしてきたが、維持の話を先送りにすべきではない。
watchittrend.comはこう述べている。「本来の価値創出である『何を監視すべきか』の設計やアラートルールのチューニングに使うべきリソースが、インフラ維持に消費されてしまいます」
PrometheusとGrafanaのセルフホスト構成は、設計が完成した後も継続的なメンテナンスが必要だ。Grafanaのバージョンアップ、Prometheusのscrape設定の見直し、ストレージの管理——これらは専任担当者が継続して対応する必要がある（watchittrend.com）。
Grafana Cloudのデータ保持期間について補足しておく。 2026年6月時点、Grafana公式の価格ページではFreeプランのデータ保持期間を14日と記載しているが、サードパーティの調査記事（app-tatsujin.com）では2024年9月に7日へ短縮されたとの報告がある。差異が解消されているかどうかを執筆時点では確認できていないため、実際に利用する前に公式で最新情報を確認することを勧める。
また、scrape_intervalを短く設定してデータ粒度を上げると、ストレージ消費とコストが急激に増える。「詳しく見たいから頻度を上げる」という判断が、運用コスト上の問題につながるケースがある。
設計だけ外注して運用は内製する選択肢
監視基盤の構築・改善を外部に依頼する場合、「全部任せる」以外の選択肢がある。
設計フェーズだけを外注し、運用は内製するという分割発注だ。初期設計の品質が高ければ、その後の運用負荷は大きく変わる。逆に言えば、設計を誤ったまま自力で積み上げると、後から直すコストが設計から外注するコストを超える。
フリーランス業務委託の市場を参考値として示すと、freelance-hub.jpの案件一覧（2026年6月時点）では以下の単価が掲載されている。
- 電力会社向け OpenShift + Prometheus + Grafana 監視基盤: 月60万円
- IoTデータ可視化 + Grafana: 月100万円
- AWS運用監視 + CDK + Grafana: 月120万円
注意が必要なのは、これらがフリーランスの業務委託月額単価であって、企業が外注するプロジェクト費用ではない点だ。 実際のプロジェクト外注費は、スコープ・期間・契約形態によって大きく異なる。「相場観を掴む参考値」として読んでほしい。
設計フェーズの期間は一般的に2〜4週間程度（要件の複雑さによる）。その後の運用は内製チームが引き継ぐという形であれば、継続的な外注コストなしに品質の高い監視基盤を維持できる。
Prometheus+Grafanaの監視基盤を経営層に説明できる形にする作業は、技術的なGrafana設定作業よりも「翻訳作業」に近い。どの指標をどの言語に置き換えるかの設計が核心で、それが定まれば実装は比較的単純に進む。
設計フェーズだけの相談にも対応しています。構築・設計の相談はこちら