Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説

Cloud Logging（旧Stackdriver Logging）は、Google Cloud（GCP）上のシステムが吐き出すログを一箇所に集めて、保管・検索・監視連携まで面倒を見るマネージドなログ管理サービスです。VMやコンテナ、各GCPサービスのログが自動で流れ込み、必要な分だけをBigQueryやCloud Storageへ振り分けられます。この記事では、ログエントリとログバケット（_Required／_Default）の仕組み、ログルーターとシンクによる振り分け設計、Logs ExplorerとログベースメトリクスによるCloud Monitoring連携、取り込み課金と保持期間のコスト設計、そしてAWS CloudWatch Logsとの違いと受託開発での採用判断までを、実装者が手を動かせる粒度で整理します。なお同名でもIBM Cloudのログサービスとは別製品で、本記事が扱うのはGoogle Cloudの「Cloud Logging」です。

まとめ：Cloud Loggingの本質と設計の物差し

Cloud Loggingの実体は、GCP全体のログを受け止める「取り込み口」と、それを行き先ごとに振り分ける「ログルーター」の2段構えです。ログはまず取り込まれ、ログルーターのシンクがフィルタ条件に従って保管先（ログバケット・BigQuery・Cloud Storage・Pub/Sub）へ流します。この2段を分けて理解すると、設定のどこをいじれば何が変わるのかが一気に見通せます。

コストは「どれだけ取り込むか」でほぼ決まります。保存の長さより、そもそも何を取り込み・何を除外するかが効くため、ノイズの多いログはシンクの除外フィルタで入口から落とすのが定石です。監査ログを保持する_Requiredバケットは無料かつ固定保持で、日常運用で触れるのは_Defaultバケットとカスタムバケットになります。

採否の物差しはシンプルです。Google Cloud上でシステムを動かすなら、ログの集約はCloud Loggingが既定の答えになります。一方、長期の生ログを安く貯めたい・SQLで縦横に分析したいといった要件は、シンクでCloud StorageやBigQueryへ逃がす前提で設計するとよいでしょう。全部をCloud Loggingのバケットに抱えさせようとすると保持コストで詰まるため、判断の詳細は本文で条件付きに言い切ります。

Cloud Loggingとは：Google Cloudのログ収集・保管基盤

Cloud Loggingは、Google Cloudの運用監視スイート（旧Stackdriver、現Cloud Operations）に含まれるログ管理サービスです。GCEのVM、GKE、Cloud RunなどのGCPサービスが生成するログは、追加の作り込みなしにCloud Loggingへ集約されます。監視という営みは、ログ・メトリクス・トレースという3種の監視データで成り立ちますが、そのうち「何が起きたか」を時系列の記録として受け持つのがログであり、その担当がCloud Loggingです。3種の役割分担はAPM（アプリケーション性能監視）とは？仕組み・3種の監視データ・OpenTelemetry計装と導入判断で整理しています。

ログエントリとログバケット：_Requiredと_Defaultの役割

Cloud Loggingの最小要素は、1件のログを表すログエントリ（LogEntry）です。エントリはタイムスタンプ・重大度（severity）・リソース情報・ペイロードを持つ構造化データで、テキストだけでなくJSON構造をそのまま格納できます。この構造化ペイロードにキーを持たせておくと、後段の検索やメトリクス化が段違いに楽になります。

取り込まれたエントリは、ログバケットという保管領域に収まります。プロジェクトには既定で2つのバケットが用意されます。

_Requiredは監査証跡を確実に残すための特別枠で、消したり保持を縮めたりはできません。日常で保持期間やアクセス権を設計するのは_Defaultとカスタムバケットになります。

収集経路：GCPサービスの自動連携・Ops Agent・Logging API

ログがCloud Loggingへ届く道は大きく3本です。第一に、多くのGCPサービスは既定でプラットフォームログを自動送出します。第二に、VM（GCEやオンプレ・他クラウド）はOps Agentを入れてOSやミドルウェアのログを収集する経路です。第三に、アプリ独自のログはLogging APIやクライアントライブラリ、あるいは標準出力経由で書き込みます。Cloud RunやGKEでは、コンテナの標準出力／標準エラーがそのままログエントリになるため、アプリ側はstdoutに構造化JSONを吐くだけで連携が済みます。Cloud Runの実行モデルはCloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを参照してください。

ログルーター（Log Router）とシンクで決めるログの流し先と保管設計

Cloud Loggingの設計で肝になるのがログルーター（Log Router）です。取り込まれたエントリは、まずログルーターを通り、そこに定義されたシンク（sink）が条件に一致したものを行き先へ流します。この振り分けを押さえると、コストと分析性の両方を同時に握れます。

ログルーター内のシンク：包含・除外フィルタでログを振り分ける

シンクは「どのログを（フィルタ）」「どこへ（宛先）」流すかの組で定義します。既定で動くのは_Requiredと_Defaultへ流す2つの組み込みシンクです。ここに自作シンクを足すことで、特定サービスのログだけをBigQueryへ複製する経路を作れます。とりわけ効くのが除外フィルタで、ヘルスチェックやデバッグレベルの大量ログを入口で落とせば、取り込み課金そのものを圧縮できます。ログルーターは分岐点であり、宛先を増やしても元の_Defaultへの保管は止まりません。両方に流れる点を前提に設計します。

エクスポート先：BigQuery・Cloud Storage・Pub/Subの使い分け

シンクの宛先は用途で選び分けます。それぞれの向き・不向きは次の通りです。

実務では、運用調査用に_Defaultへ短期保持しつつ、監査・分析用途はBigQueryへ、長期保全はCloud Storageへ、という多重化がよく効きます。全部を1箇所に抱えず、寿命と用途で行き先を分けるのが結果的に安く済みます。

収集したログの読み解きと監視連携：Logs Explorer・ログベース指標

集めたログは、見て・測って・気づけて初めて価値になります。Cloud Loggingは検索UIとメトリクス化の両面を備えます。

Logs ExplorerとLogging query languageでのクエリ

Logs Explorerは、保管されたログをその場で絞り込む検索UIです。resource.typeやseverity>=ERRORといった条件を書くLogging query languageで、リソース・重大度・期間・任意のペイロードフィールドを掛け合わせて追い込めます。構造化ペイロードに載せたキーはそのまま検索軸になるため、ログ設計の段階でフィールドを切っておくと調査が速くなるでしょう。さらに大規模なログをSQLで扱いたい場合は、Log Analytics（BigQueryバックエンドのSQL分析）で集計や結合を掛けられます。

ログベース指標でCloud Monitoring・アラートにつなぐ

ログは眺めるだけでなく、指標に変換して監視に組み込めます。ログベース指標（log-based metrics）は「ERRORログの発生回数」「特定文字列の出現数」などをログから抽出してメトリクス化する仕組みで、これをCloud Monitoringのダッシュボードやアラートポリシーに載せれば、ログの異常を通知として受け取れます。ログ（何が起きたか）を指標（どれだけ起きたか）へ橋渡しする要の機能です。エンドユーザー視点の死活監視である外形監視と、内部ログ由来の指標監視を組み合わせると、外と中の両面から異常を捉えられます。GKE上のワークロードでログ・メトリクス・アラートをどう束ねるかはKubernetes監視・モニタリングの設計が参考になります。

Cloud Loggingの料金と保持期間の設計：取り込み課金と保管費の勘所

Cloud Loggingのコストは、大きく「取り込み量」と「保持（保管）」の2軸で発生します。中心は取り込み課金で、プロジェクトあたり月あたり一定量の無料枠（50GiB系）を超えた分に、取り込んだデータ量あたりの単価がかかります（2026年時点・実額は最新の料金表で確認）。_Requiredバケットの監査ログは取り込み課金の対象外です。

設計の初手は、保持を延ばす前に「入口を絞る」ことです。デバッグログやヘルスチェックのような低価値・大量のログは、シンクの除外フィルタで取り込む前に落とすと課金が直接減ります。次に、_Defaultの既定30日で足りない監査・分析用途だけを、BigQueryやCloud Storageへシンクで逃がしておくとよいでしょう。冷たいストレージクラスに落とせば長期保全の単価を抑えられます。「とりあえず全ログを長期保持」は、取り込み量と保管費の両方でコストを膨らませる典型的な失敗です。

CloudWatch Logs・Azure Monitor Logsとの違いと移行の勘所

マルチクラウドや移行の現場では、各クラウドのログ基盤の対応関係が判断材料になります。概念は近く、名前と細部が違います。

AWSを主戦場にしてきたチームは、CloudWatch中心のオブザーバビリティ構成をまとめたAWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成と読み比べると、Cloud Loggingの立ち位置がつかみやすくなります。共通するのは「ログを構造化して取り込み、必要な分だけ長期基盤へ逃がす」という設計思想です。GCPではその橋渡しをログルーターとシンクが一手に引き受ける点が、CloudWatchのサブスクリプションフィルタと考え方は同じでも操作単位が異なります。

受託開発でCloud Loggingを採用する条件と見送る場面

ここは判断を言い切ります。Cloud Loggingは、Google Cloud上で動かす限りは既定の選択肢ですが、抱え込ませ方を誤るとコストと分析性で損をします。

採用が向く条件＝GCPログ集約と監視連携を一気通貫にしたい場面

次の条件が揃うならCloud Loggingを軸に据えます。第一に、システムの本体をGCP（GCE・GKE・Cloud Run等）で動かしており、各サービスのログを追加構築なしで一箇所に集めたい場合。第二に、ログベース指標でCloud Monitoringのアラートまで一気通貫でつなぎ、運用の異常検知を素早く立ち上げたい場合。第三に、監査ログを確実に残しつつ、分析はBigQuery・長期保全はCloud Storageへシンクで振り分ける多層構成を組みたい場合です。これらは、既存システムのGoogle Cloud移行や内製化支援でログ基盤を設計に組み込む典型で、当社のインフラ構築（AWS・Google Cloud・Azure）でも、取り込み対象の選定からシンク設計・保持期間・IAM設計まで併走します。

Cloud Loggingを抱え込ませ過ぎて崩れる失敗パターン

逆に、設計が破綻するのは次のケースです。全ログを除外なしで取り込み、_Defaultの保持を漫然と延ばすと、取り込み課金と保管費の両方が膨らみ、価値の低いデバッグログにコストを払い続けます。生ログをSQLで縦横に分析したい要件をCloud Loggingのバケット内で完結させようとするのも筋が悪く、その用途はBigQueryへシンクで逃がすのが正解です。長期保全が主目的なら、ログバケットの延長ではなくCloud Storageの冷たいクラスに落とします。「集約はCloud Logging、分析はBigQuery、保全はCloud Storage」と役割を分ける前提で入口設計から決めておくと、後からのコスト膨張を避けられます。マルチクラウドで単一のログ基盤に寄せたい要件がある場合は、Pub/Sub経由で外部SIEMへ流す構成を先に検討してください。

Cloud Loggingの料金・保持と実装に関するよくある質問

Cloud Loggingの導入・実装・コストで問い合わせの多い5点に、実装者目線で簡潔に答えます。

Cloud LoggingとCloud Monitoringは何が違いますか？

Cloud Loggingは「何が起きたか」を記録するログを、Cloud Monitoringは「どれだけ・どんな状態か」を測るメトリクスとアラートを担当します。両者はGoogle Cloudの運用監視スイートを構成する対の機能で、ログベース指標を介してログからメトリクスを作り、Monitoring側で通知に落とす、という連携で組み合わせて使います。

Cloud Loggingの料金はどう決まりますか？

主軸は取り込み量です。プロジェクトあたり月あたりの無料枠（50GiB系）を超えた取り込みデータ量に単価がかかり、保持期間の延長やBigQuery・Cloud Storageへのエクスポート先でも別途費用が発生します（2026年時点・実額は最新の料金表で確認）。監査ログを保持する_Requiredバケットは取り込み課金の対象外です。コストを抑える初手は、除外フィルタで不要ログを入口から落とすことです。

Stackdriver LoggingとCloud Loggingは同じものですか？

同じサービスです。旧称がStackdriver Loggingで、Google Cloudの運用監視スイートの再編に伴いCloud Loggingへ名称が変わりました。古い記事やツールでStackdriverの名称が残っていても、指しているのは現在のCloud Loggingと考えて差し支えありません。

ログの保持期間は変更できますか？

_Defaultバケットとカスタムバケットの保持期間は設定で延長・短縮できます。一方、監査証跡を格納する_Requiredバケットの保持は固定で変更できません。長期保全が必要な場合は、保持延長でバケットに抱えさせるより、シンクでCloud Storageの冷たいクラスへ逃がすほうが単価を抑えられます。

アプリのログはどうやってCloud Loggingに送りますか？

Cloud RunやGKEでは、コンテナの標準出力・標準エラーに書き出すだけで自動的にログエントリになります。VMからはOps Agentを導入してOS・ミドルウェアのログを収集し、独自の構造化ログはLogging APIやクライアントライブラリで送信します。構造化JSONで重大度やキーを付けておくと、後段の検索とメトリクス化がぐっと楽になるはずです。

関連記事

• APM（アプリケーション性能監視）とは？仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説：ログ・メトリクス・トレースの役割分担。Cloud Loggingの上位概念を先に押さえられます。
• 外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説：ログ由来の内部監視と対になる、外からの死活監視の設計。
• AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成：AWS版のログ・監視基盤との対応付け。マルチクラウド設計の参照に。
• Cloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違い：Cloud Loggingへログを吐き出す代表的なGCPコンピューティング。
• Cloud Storage（GCS）とは？仕組み・4つのストレージクラスとS3との違いを実装者目線で解説：ログの長期・低コスト保全先。シンクのエクスポート先として組み合わせます。