Cloud Monitoring（Google Cloud）とは？機能・料金・設定・他ツール比較を解説

Cloud Monitoringは、Google Cloud（GCP）が提供する標準の監視サービスで、仮想マシンやコンテナ、マネージドサービスの指標・稼働状況・アラートを1か所に集約する。同名の製品はIBMなど他社にもあるが、検索で上位を占めるのはGoogle CloudのCloud Monitoringで、本記事もこれを対象にする。ここでは主要機能、無料枠を含む料金、始め方、そしてDatadogなど他ツールとの使い分けまでを一次情報で整理する。

まとめ

Cloud MonitoringはGoogle Cloud標準の指標・アラート基盤で、GCPのシステム指標は無料で自動収集される。Metrics Explorerで指標を探索し、ダッシュボード・アラート・稼働時間チェック・合成モニタリング・SLO監視までを1サービスで完結できる。VMの詳細指標はOps Agentで収集し、クエリはPromQL（Managed Service for Prometheus）に対応する。課金対象はおもにカスタム指標の取り込み量（無料枠150 MiB/月）と合成モニタリングの実行回数で、GCP標準指標そのものは無料。GCP中心の構成なら追加コストを抑えて監視を始められ、マルチクラウドや高度なAPM要件がある場合はDatadog等との併用や比較が妥当な選択になる。以下で各機能と料金の実際を掘り下げる。

Cloud Monitoringとは｜Google Cloud標準の監視サービス

Cloud Monitoringは、旧称Stackdriverの後継にあたるGoogle Cloud Observabilityの中核サービスである。Compute Engine、GKE、Cloud Run、Cloud SQLなどGCPリソースのメトリクスを自動で収集し、時系列データとして保存・可視化・アラート化する。設定なしでもGCP標準指標が取り込まれるため、プロジェクトを作った時点から基本的な監視が始まっている点が特徴になる。

監視・オブザーバビリティとの位置づけ

Cloud Monitoringはメトリクス（指標）を担い、ログはCloud Logging、分散トレースはCloud Traceが担当する。この3つを合わせてGoogle Cloud Observabilityを構成する。メトリクス・ログ・トレースを組み合わせて「なぜ問題が起きたか」まで追える状態がオブザーバビリティ（可観測性）であり、閾値超過の検知にとどまる従来型監視との違いはそこにある。計装の標準化にはOpenTelemetryを使い、Cloud Monitoringへメトリクスを送る構成も取れる。

収集できる指標｜Google Cloud標準指標とカスタム指標

指標は大きく2種類ある。1つはCPU使用率・メモリ・ディスクI/O・ネットワークなどGCPが自動で出す標準指標で、これは課金されない。もう1つはアプリケーション固有の値を送るカスタム指標で、こちらは取り込み量に応じて課金される。標準指標だけで足りるか、業務指標（注文数、キュー滞留など）まで測るかで、後述の料金が変わる。

Cloud Monitoringの主要機能

Cloud Monitoringは可視化から通知、サービス品質管理までを一連の機能として提供する。読者が個別に探すことの多い機能を順に整理する。なお、ここで挙げる指標の読み取り・カスタム指標の書き込み・ダッシュボードやアラートの管理は、いずれもCloud Monitoring API（REST／各言語のクライアントライブラリ）からプログラムで操作でき、監視設定をコードで再現可能な形に落とし込める。

Metrics Explorerによるメトリクスの可視化・探索

Metrics Explorerは、監視対象リソースと指標を選ぶだけでグラフ化できる探索ツールで、GCPコンソール内で使う。フィルタ・集計（合計、平均、パーセンタイル）・グループ化を指定して、CPU使用率やレイテンシの傾向を数クリックで確認できる。作成したグラフはそのままダッシュボードのウィジェットとして保存できるため、まず異常の当たりを付ける場所として使う。

ダッシュボードによる指標の一元監視

複数のグラフをまとめたカスタムダッシュボードを作成し、サービスやチーム単位で重要指標を並べて監視できる。GCPは主要サービスごとに定義済みダッシュボードも用意しており、ゼロから作らずに使い始められる。ウィジェットの配置はドラッグで調整し、閲覧・編集権限はIAMで制御する。

アラートと通知チャネル

アラートポリシーで「指標が閾値を超えたら通知」という条件を定義する。通知はメール、SMS、Slack、PagerDuty、Pub/Sub、Webhookなどの通知チャネルへ送れる。閾値ベースだけでなく、後述のPromQLを条件式に使ったアラートも設定でき、複数条件の組み合わせや欠損データの扱いも指定できる。

稼働時間チェックと合成モニタリング

稼働時間チェック（Uptime check）は、指定したURLやエンドポイントへ複数リージョンから定期リクエストを送り、応答コードと応答時間を監視する外形監視である。合成モニタリング（Synthetic monitoring、2023年11月にGA）はさらに一歩進み、Cloud Run functions（旧Cloud Functions）上でブラウザ操作やAPI呼び出しのシナリオを実行し、ログイン〜購入のような一連の操作が成立するかを検証する。単なる死活監視では拾えない「動くが正しく機能しない」状態を検知できる。

SLO監視によるサービス品質管理

SLO（Service Level Objective）機能では、可用性やレイテンシの目標値を定義し、エラーバジェットの消化状況を追跡できる。「直近30日で99.9%の成功率」といった目標をサービスに紐づけ、バジェットが尽きそうになったらアラートを出す運用が組める。障害対応の優先順位付けやリリース判断の基準として使える。

PromQL・MQLとManaged Service for Prometheus

Cloud Monitoringの指標は、クエリ言語で柔軟に取り出せる。現在はPromQL（Prometheus Query Language）が中心で、Google Cloud Managed Service for Prometheus経由でGCP標準指標・Kubernetes指標・ログベース指標・カスタム指標のすべてをPromQLで照会できる。PromQLベースのアラートポリシーやGrafanaダッシュボードの取り込みもGAで提供される。Google独自のMQL（Monitoring Query Language）も引き続き使えるが、Prometheusエコシステムの資産（既存のPromQLアラートやGrafana）を活かせるPromQLが実務では扱いやすい。

Managed Service for Prometheusは、自前でPrometheusを運用せずにスケールさせられるマネージド基盤で、Prometheus/カスタム指標を最長24か月保持する。Prometheus・Grafana・Lokiを自前で組む構成と比較検討する場合は、Grafana LokiとPrometheus連携の記事も判断材料になる。

Ops AgentによるVMの詳細監視

Compute EngineのVMからOSレベルやアプリケーションの詳細指標・ログを集めるには、Ops Agentをインストールする。Ops Agentはログとメトリクスを1つに統合したエージェントで、YAMLファイルで収集対象を設定する。かつての監視エージェントとロギングエージェントを別々に入れる方式は、レガシー扱い（Monitoring agent 5.xは非推奨・廃止済み）となり、新規VMや移行先はOps Agentが推奨される。インストール後は標準でCPU・メモリ・ディスクなどのホスト指標を送り始め、設定を追記すればNginxやMySQLなど個別アプリの指標も取得できる。

Cloud Monitoringの料金体系

Cloud Monitoringは従量課金で、多くのGCP利用者が無料枠の範囲で使い始められる。おもな課金対象と無料枠は次のとおり（2026年7月時点。単価は改定されうるため、最新は公式の料金ページで確認する）。

実務でコストが増える主因はカスタム指標の取り込み量である。ラベルの組み合わせが多い（カーディナリティが高い）指標を大量に送ると取り込み量が膨らむため、不要なラベルを削り、送信頻度を見直すのがコスト抑制の要点になる。GCP標準指標は無料なので、まず標準指標中心で構成し、必要な業務指標だけカスタムで足す設計が無駄を防ぐ。

アラートについては、2026年9月1日以降（no sooner than）にアラートポリシーへの課金開始が告知されている（アラートポリシー内のメトリクス参照ごとに月額$0.35、条件クエリが返す100万ポイントごとに$0.50の見込み）。従来無料だったアラートが有料化されるため、監視設計を組む前に施行時期と単価を公式の料金ページで必ず確認しておきたい。

Cloud Monitoringの始め方（3ステップ）

GCPプロジェクトがあれば、大きく3ステップで監視を開始できる。

1. GCPコンソールでMonitoringを開き、対象プロジェクトのワークスペースを確認する（標準指標は自動収集済み）。
2. VMの詳細指標が必要ならOps Agentを対象インスタンスにインストールし、収集対象をYAMLで設定する。
3. Metrics Explorerで見たい指標を選んでダッシュボード化し、重要指標にアラートポリシーと通知チャネルを設定する。

外形監視まで含めるなら、稼働時間チェックや合成モニタリングを追加し、SLOを定義して品質目標を運用に組み込む。最初から全機能を入れず、標準指標とアラートから始めて段階的に広げるのが実務的である。

他の監視ツールとの比較と使い分け

Cloud MonitoringはGCPネイティブである点が最大の強みで、GCP標準指標が無料かつ設定不要で取れる。一方で、複数クラウドやオンプレを横断する統合監視、高度なAPM・分散トレースの相関分析、豊富なインテグレーションを求める場合は、専用の監視SaaSに分がある。

判断を明確にするなら、GCPだけで完結し予算を抑えたい構成にDatadogを持ち込むのは過剰で、Cloud Monitoringで十分なことが多い。逆に、AWS・Azure・GCPを一枚のダッシュボードで見たい、あるいは深いトランザクション追跡が要る場面ではCloud Monitoring単独では力不足になりやすい。DatadogをコードでIaC管理したい場合はTerraformでDatadogを管理する方法、オンプレ資産を自前で監視する選択肢はZabbixの仕組みと監視できることが具体的な比較材料になる。

よくある質問

Cloud Monitoringとは何ですか？

Google Cloud（GCP）が提供する標準の監視サービスで、GCPリソースの指標を自動収集し、可視化・アラート・稼働時間チェック・SLO監視などを一元的に行えます。旧称Stackdriverの後継で、Cloud Logging・Cloud Traceと合わせてGoogle Cloud Observabilityを構成します。IBMなど他社にも同名製品がありますが、日本語検索で主に対象になるのはこのGoogle Cloudの製品です。

Cloud Monitoringの料金はいくらですか？

従量課金ですが、Google Cloudの標準指標は無料で取り込めます。課金されるのはおもにカスタム/外部指標の取り込み量（無料枠150 MiB/月を超えた分、$0.2580/MiB〜）と、合成モニタリングの実行回数（無料100実行/月、超過は$1.20/1,000実行）です。稼働時間チェックは月100万実行まで無料です。単価は改定されうるため、最新は公式の料金ページで確認してください。

Ops Agentとレガシー監視エージェントの違いは？

Ops Agentはログとメトリクスを1つに統合したエージェントで、YAMLで設定します。従来はMonitoring agentとLogging agentを別々に導入していましたが、レガシー版（Monitoring agent 5.x）は非推奨・廃止済みで、新規のVMや移行先ではOps Agentが推奨されます。VMの詳細指標やアプリ個別の指標を取りたい場合にインストールします。

PromQLとMQLはどちらを使うべきですか？

現在はPromQLが中心です。Managed Service for Prometheusを通じて、GCP標準指標からカスタム指標までPromQLで照会でき、既存のPromQLアラートやGrafanaダッシュボードをそのまま活かせます。Google独自のMQLも使えますが、Prometheusエコシステムの資産を再利用できるPromQLのほうが実務では扱いやすいでしょう。

Cloud MonitoringだけでAWSも監視できますか？

基本はGCP向けの監視サービスで、AWSやAzureを含むマルチクラウドの統合監視は得意領域ではありません。複数クラウドを一元的に見たい場合は、DatadogやNew Relicのようなマルチクラウド対応ツールとの併用・比較が現実的です。GCP中心の構成であればCloud Monitoringで完結できます。

関連記事

• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説
• OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説
• Grafana Lokiとは？Prometheus連携・LogQL・導入方法をわかりやすく解説
• TerraformでDatadogを管理する方法｜Provider設定・モニター・AWSインテグレーション実践ガイド
• Zabbixとは？仕組み・監視できること・他ツールとの違いをわかりやすく解説