2026.07.27 インフラ

Cloud Traceとは？Google Cloudの分散トレーシングの仕組み・OpenTelemetry連携・料金と導入判断を実装者目線で解説

Cloud Traceは、Google Cloudが提供するマネージドの分散トレーシングです。マイクロサービスをまたぐ1件のリクエストが、どのサービスでどれだけ時間を使ったかを経路として記録し、遅延のボトルネックを絞り込みます。この記事で扱うのは、トレース・スパンといった基礎、OTLP（OpenTelemetry Protocol）でのデータ取り込み、Trace Explorerでの分析、料金体系、そしてCloud Traceを選ぶべきか、セルフホスト型のバックエンドやAWS X-Rayを選ぶべきかまで。実際にGoogle Cloud上でシステムを組む技術者の目線で整理します。仕様・料金は2026年7月時点の実測値です。

まとめ：Cloud TraceはGCPの運用負担を抑えた分散トレーシング基盤

Cloud Traceは、Google Cloudの可観測性スイート（Cloud Observability）に含まれる、フルマネージドの分散トレーシングサービスです。要点は3つあります。第一に、トレースの保存先やインデックスを自前で用意せず、GCPが運用するバックエンドへスパンを送るだけで検索・分析ができる点です。第二に、OTLPをネイティブに取り込めるため、OpenTelemetryで計装したアプリをそのまま接続できます。第三に、Cloud RunやGKEなど一部の実行環境では計装なしでも基本的なトレースが自動で集まる点です。

役割分担で見ると、メトリクスはCloud Monitoring、ログはCloud Logging、そしてトレースはCloud Traceが担い、この3つでGoogle Cloud Observabilityの3本柱を構成します。計装の入口となるOpenTelemetry（OTel）の考え方を先に押さえると、Cloud Traceが「どこからデータを受け取るか」を掴みやすくなります。導入判断の軸は、システムがGoogle Cloud中心か、マルチクラウドで中立性を優先したいかの2点。GCPに寄せた構成なら運用の手離れが良いCloud Trace、複数クラウドをまたぐなら計装をOTelで標準化してバックエンドを選べる構成が向きます。

Cloud Traceの定義と可観測性スイートの中での位置づけ

まず「トレースとは何か」と「Cloud Traceが何を代行するか」を実装単位で確認します。ここが曖昧だと、送っているデータとTrace Explorerで見える内容がずれて理解されがちです。

トレース・スパン・trace_idが支えるトレースの基本データ構造

1件のリクエストがサービスAからB、Cへと渡る一連の処理が「トレース」です。トレースは複数の「スパン」で構成され、各スパンは処理区間の開始・終了時刻、サービス名、HTTPステータスなどの属性を持ちます。スパン同士は親子関係でつながり、どの処理がどれを呼び出したかをたどれる構造です。この関係を運ぶのがtrace_idとspan_idで、次のサービスへヘッダーとして伝搬させることで1本のトレースにまとまります。Cloud Traceはこのスパン群をtrace_id単位で受け取って保存し、後からIDや条件で引き出す部分を代行するサービスです。

Cloud Monitoring・Cloud Loggingと並ぶ可観測性の3本柱

可観測性は、メトリクス・ログ・トレースの3種類のテレメトリーで対象を観測します。Google Cloudでは、メトリクスをCloud Monitoring、ログをCloud Logging、トレースをCloud Traceが担う分担です。メトリクスは異常の発生を数値で知らせ、ログは個々の事象を詳細に残し、トレースは「どのサービス間で遅延やエラーが起きたか」を経路として示します。役割の違いはオブザーバビリティ（可観測性）と監視の違いを整理した記事に詳しく、ログ側の設計はCloud Loggingのログルーター/シンクの解説が対応する形です。3つを同じGoogle Cloudコンソール上でひも付けると、メトリクスの異常からトレース、該当スパンのログへと一続きにたどれる構成になります。

フルマネージドである意味とセルフホスト型バックエンドとの分かれ目

分散トレーシングを自前で運用する場合、JaegerやGrafana Tempoのようなバックエンドを立て、保存先のストレージやスケール設計、バージョン更新まで自分たちで抱えます。Cloud Traceはこの運用一式をGoogle Cloud側に寄せる選択肢です。サーバーやストレージの容量設計、可用性の担保を意識せずにスパンを送れる代わりに、保存期間やクエリの自由度はサービスの仕様に沿います。全部を自前で握りたいならセルフホスト、運用の手離れを取るならマネージド、という判断の分かれ目がここにあります。

Cloud Traceへのデータ取り込みの仕組みとOpenTelemetry連携

Cloud Traceの理解は、スパンがどこで生まれ、どの経路で届くかを追うと早いです。取り込みの入口はOpenTelemetryが標準になっています。

OTLPネイティブ取り込みとTelemetry APIの位置づけ

Cloud TraceはOTLP（OpenTelemetry Protocol）でのデータ受信に対応しており、Googleはベンダー中立のOpenTelemetryライブラリでの計装を推奨しています。アプリケーションに計装コードを入れてスパンを生成し、OTLPでTelemetry APIへ送る流れです。以前はGoogle独自のクライアントライブラリで送る形が中心でしたが、現在はOpenTelemetryを入口に据える構成が推奨経路になりました。OTelで計装しておくと、送信先をCloud Traceから別のバックエンドへ切り替える際も、アプリ側のコードを大きく書き換えずに済みます。計装の考え方はOpenTelemetryの3つのシグナルとOTLPの解説で先に押さえておくと迷いません。

Collectorを挟むパイプラインとサービス間のコンテキスト伝搬

アプリからCloud Traceへ直送もできますが、間にOpenTelemetry Collectorを挟むのが実務では扱いやすい構成です。Collectorがスパンを受けてバッファ・整形し、Cloud Traceへ転送します。この中間層があると、サンプリング方針の変更や送信先の追加を、アプリのコードに触れずに設定側で調整できます。もう一つの要点はコンテキスト伝搬です。サービスAがBを呼ぶ際にtrace_idとspan_idをリクエストヘッダーへ載せ、Bがそれを引き継いで自分のスパンを親にひも付けます。この伝搬が途切れると、本来1本であるべきトレースが分断され、経路が追えなくなる原因です。計装ライブラリの伝搬設定（コンテキストプロパゲーション）をサービス間でそろえておく作業が、正確なトレースの前提になります。

Cloud Run・GKE・App Engineでの自動連携とサンプリング

Cloud Traceは、Cloud RunやGKE、App Engine、Compute Engineといった実行環境と自動的に連携し、環境によっては計装を細かく入れなくても基本的なリクエストトレースが集まります。全リクエストを漏れなく残すと、トラフィックの多いサービスではスパン量とコストが膨らむため、実務ではサンプリングでどれを残すかを制御する設計です。サンプリングの方式や割合の決め方はトレースサンプリングの解説にまとめた通りで、ヘッドベースとテールベースの違いを踏まえて、遅延やエラーのトレースを取りこぼさない設定を選びます。自動連携で楽に始められる一方、意味のあるスパンを残す設計は自分たちで詰める前提です。

Trace Explorerでできる分析と他サービスへの相関

Cloud Traceの価値は保存だけでなく、貯めたトレースをどう読み解くかにあります。Trace Explorerが検索と可視化の中心になります。

Trace Explorerのヒートマップと集約分析によるレイテンシー傾向の把握

Trace Explorerは、トレースの集約情報をヒートマップとして表示し、レイテンシーの分布や外れ値の塊を視覚的に掴めます。全体の傾向から「この時間帯・このエンドポイントで遅延が偏っている」といった当たりを付け、そこから個別トレースへ降りていく流れです。1件ずつのトレースを眺めるより、まず分布を見て異常な帯を見つけ、対象を絞ってから詳細へ進むと、原因への到達が速くなります。属性でのフィルタも効くため、サービス名やステータスコードで対象を切り出せます。

スパンのウォーターフォール表示による処理時間と根本原因の絞り込み

個別トレースを開くと、スパンが時間軸に沿ってウォーターフォール（滝）状に並び、どのスパンがどれだけの時間を占めたかが一目で分かります。親スパンの下に子スパンがぶら下がる構造なので、遅いのは自サービスの処理なのか、下流サービスやデータベース呼び出しの待ち時間なのかを切り分けられる点です。エラーが起きたスパンには印が付き、そこにひも付いた属性から失敗の文脈を読めます。「メトリクスで異常を検知し、Trace Explorerで遅いスパンを特定し、該当ログで原因を確認する」という調査の一筆書きが、根本原因の絞り込みを短くする流れです。

Cloud Logging・Cloud MonitoringやBigQueryとの連携

Cloud TraceはCloud Loggingと統合でき、トレースの1スパンから、その処理が出した該当ログへ相関してたどれます。ログにtrace_idを載せておくと、トレースとログの結び付きが確実になり、往復の調査が減る利点です。メトリクス側はCloud Monitoringと組み合わせ、レイテンシーやエラー率のアラートを起点にトレースへ入る導線を作れます。さらにトレースデータをBigQueryへエクスポートすれば、SQLで長期の傾向分析や独自の集計を回せる仕組みです。標準の画面で足りる範囲はTrace Explorer、腰を据えた分析はBigQuery、という使い分けができる構成です。

Cloud Traceの料金体系とサンプリングによるコスト設計

Cloud Traceはマネージドサービスのため、送るスパン量に応じた課金が発生します。無料枠と従量の境目、そしてサンプリングでの制御を押さえておきます。

Cloud Traceの無料枠と取り込みスパン数に応じた従量課金

Cloud Traceの課金は、取り込む（インジェストする）スパンの数を単位にします。2026年7月時点の公開料金では、毎月一定量のスパンまでが無料枠で、その枠を超えた分に対して取り込んだスパン量に応じた従量課金がかかる体系です。Cloud Runや一部のマネージド環境が自動生成するトレースは、この従量枠の対象外として扱われる区分もあります。具体的な無料枠の数値や単価は改定される可能性があるため、実際の設計時はGoogle Cloudの可観測性の料金ページを一次情報として最新値を確認してください。ここで押さえるべきは「送ったスパンの量がそのままコストに効く」という課金の性格です。

サンプリング率と属性設計によるトレース取り込みコストの制御方針

コストがスパン量に連動するため、全リクエストを常時100%で取り込むと、トラフィックの増加がそのまま費用に跳ね返ります。実務ではサンプリング率を絞り、正常系は間引きつつ、エラーや高レイテンシーのトレースは残す方針が実務的です。テールベースサンプリングを使えば、トレースが出そろってから残すか捨てるかを判断できるため、貴重な異常系の取りこぼしを抑えられます。あわせて、スパンに載せる属性を必要な範囲に絞ると、1スパンあたりのデータ量とノイズを減らせる効果です。料金を抑える設計は、後から効かせるより計装の初期に方針を決めておくほうが手戻りが小さく済みます。

Cloud Trace導入の判断とセルフホスト型・X-Rayとの選び分け

ここからは、実際にCloud Traceを採るかどうかの判断です。マネージドの手離れと、バックエンドを選べる中立性は両立しにくい面があります。構成と体制を見て、採用条件と見送り場面を言い切ります。

Cloud Traceを採用すべき要件と導入を見送るべき場面

採用が向くのは、システムをGoogle Cloud中心で組んでおり、トレース基盤の運用に人手を割きたくないケースです。Cloud Run・GKE・App Engineでの自動連携が効き、Cloud Logging・Cloud Monitoringとの相関もそろっているため、GCPに寄せた構成では初期の立ち上げが軽く済みます。逆に見送りを検討すべきなのは、複数クラウドやオンプレをまたいでトレースを一元管理したい場合、保存期間やクエリの自由度を自分たちで握りたい場合、既にGrafanaやElasticといった可視化資産を持っていてそこへ集約したい場合です。単一の小さなアプリで外部依存が浅く、ログとメトリクスで原因が十分たどれる段階なら、トレース基盤の導入自体を後回しにしてよい場面もあります。分散トレーシングの効果はサービス間の呼び出しが多いほど大きく、呼び出しが浅い構成では計装とコストが先に立ちます。

OpenTelemetryで計装してロックインを避ける進め方

Cloud Traceを使う場合でも、計装をGoogle独自のライブラリではなくOpenTelemetryで組んでおくと、後からバックエンドを差し替える自由が残ります。OTelで生成したスパンは、送信先をCloud Traceにも、セルフホストのJaegerやGrafana Tempoにも、別のSaaSにも向けられます。まずはCloud Traceで手軽に運用を始め、要件が変わってマルチクラウド中立や独自の長期保管が必要になったら、計装はそのままに送信先だけを移す、という段階的な進め方が現実的です。計装の入口をベンダー中立にしておく判断が、将来の乗り換えコストを下げます。基盤の設計や既存構成への組み込みで手が足りない場合は、クラウドインフラの構築支援（AWS・Google Cloud・Azure）で設計から運用移管まで伴走できます。

AWS X-Rayやセルフホスト型バックエンドとの選定比較軸

他クラウドのマネージドと比べると、AWS上ならAWS X-Rayが同じ立ち位置で、CloudWatchやOpenTelemetryとの連携を軸に選びます。クラウドを固定せず中立に運用したいなら、JaegerやGrafana Tempoをセルフホストし、保存先や保持期間を自前で設計する道があります。比較の軸は、運用をどこまで自分たちで抱えるか、どのクラウドに寄せるか、トレースをログ・メトリクスと同じ基盤で束ねたいか、の3点です。Google Cloud中心で手離れ重視ならCloud Trace、マルチクラウドや独自運用重視ならOTel＋セルフホスト、と割り切ると選定が進みます。いずれの場合も、計装をOpenTelemetryでそろえておけば、選び直しの余地を残せます。

Cloud Traceの導入・運用に関するよくある質問と回答

導入検討でよく挙がる論点を、実装・運用の観点で簡潔にまとめます。

Cloud TraceとAWS X-Rayは何が違いますか？

どちらもクラウド事業者が提供するマネージドの分散トレーシングで、役割はほぼ同じです。違いは対象クラウドと周辺サービスとの連携で、Cloud TraceはCloud Logging・Cloud Monitoringと、X-RayはCloudWatchと組み合わせる前提です。どちらもOpenTelemetryでの計装に対応するため、計装をOTelでそろえておけば、送信先をCloud TraceとX-Rayで切り替える形も取れます。使っているクラウドに合わせて選ぶのが基本の考え方です。

OpenTelemetryは必須ですか？

必須ではありませんが、実務ではOpenTelemetryでの計装が推奨経路です。Cloud TraceはOTLPをネイティブに取り込めるため、OTelで計装したアプリをそのまま接続できます。新規に計装するなら、ベンダー中立で送信先を切り替えやすいOpenTelemetryを選ぶと、将来Cloud Traceから別バックエンドへ移す際もアプリ側の書き換えを避けられます。既存のGoogle独自ライブラリからの移行も、OTelを入口に据える方向で進めるのが定石です。

Cloud Traceの費用はどれくらいかかりますか？

Cloud Traceは取り込んだスパンの数に応じた従量課金で、毎月一定量までは無料枠があります。無料枠を超えた分に料金がかかるため、トラフィックが多いほど費用が積み上がる仕組みです。サンプリングで残すトレースを絞ればコストを抑えられます。無料枠の具体量や単価は改定され得るので、設計時はGoogle Cloudの料金ページで最新値を確認してください。

Cloud Runで動かすと自動でトレースが取れますか？

Cloud RunやGKE、App Engineといった環境では、基本的なリクエストトレースが自動で集まる仕組みがあります。ただし、サービス内部の処理やデータベース呼び出しといった細かいスパンまで取るには、OpenTelemetryでの計装を足す必要があります。自動連携で全体像の入口を作り、深掘りしたい区間を計装で補う、という組み合わせが実務的な進め方です。

既存のログ・メトリクス基盤と一緒に使うべきですか？

可観測性はメトリクス・ログ・トレースの3つがそろって初めて障害の初動が速くなります。Google Cloudで運用しているなら、Cloud MonitoringのメトリクスとCloud Loggingのログに、Cloud Traceのトレースを足すと「サービス間の経路」が埋まる形です。3つをtrace_idで結び付けておくと、メトリクス異常からトレース、該当ログへの往復が減ります。ゼロから3つ同時に入れる場合は、まずメトリクスとログを整え、サービス境界が増えた段階でトレースを追加する順序が無理のない進め方です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る