トレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説【2026年版】

トレースサンプリングとは、分散トレーシングで発生する大量のトレースのうち、記録・送信・保存する対象を一定の規則で取捨し、観測データの量と費用を抑える仕組みです。マイクロサービス構成では1リクエストが多数のサービスを通り、その1本ごとにトレースが生成されるため、全量を保存すると保管費用とネットワーク転送が跳ね上がります。かといって無闇に間引くと、障害の原因になった遅いトレースやエラーのトレースを取りこぼしかねません。この記事では、サンプリング決定を「いつ」下すかで分かれるヘッドベースとテールベースの2方式、OpenTelemetryのサンプラー種別と伝播、CollectorやAWS X-Rayでの実装、メトリクスとの整合、そして「どの方式でサンプリング率をいくつに設定するか」の判断基準までを、実装者の視点で整理します。トレースを含む観測全体の考え方はオブザーバビリティ（可観測性）とは何かで扱っているため、本稿はそのトレース面のデータ量を制御する設計に絞って掘り下げます。

まとめ：トレースサンプリングは記録するトレースを取捨し費用と調査可能性を両立させる設計

トレースサンプリングの要点は1行で示せます。全リクエストのトレースを保存する代わりに、記録する対象を規則で選び、観測費用を抑えつつ障害調査に必要なトレースは残す、という取捨の設計です。全量保存は最も情報量が多い一方で費用が膨らみ、雑に間引くと肝心のエラートレースを失います。その中間で「何を残すか」を決めるのがサンプリングです。

方式は決定のタイミングで2つに分かれます。ヘッドベースはトレースの開始時（ルートスパン生成時）にサンプリングするかを決め、その決定をサービス間で引き継ぐ方式で、実装が単純で予測しやすい代わりに、開始時点では分からないエラーや遅延を狙って残せません。テールベースはトレースが完了して全スパンがそろってから、エラーの有無やレイテンシを見て残すかを決める方式で、価値の高いトレースを選んで残せる代わりに、全スパンを一時的にためる基盤の負荷が増えます。

判断の軸は、「開始時に決まる単純さで足りるか、完了後に選別してエラーや遅延を確実に残したいか」、そして「テールベースの選別基盤を自前で運用できるか」です。多くのチームはヘッドベースの確率サンプリングから始めるのが現実的で、エラーや特定トランザクションを取りこぼしたくない要件が明確になった段階でテールベースを足します。以下、定義・2方式・実装・導入判断の順に具体化します。

トレースサンプリングの定義と分散トレーシングにおける必要性の整理

まず、なぜトレースを全量保存しないのか、そしてサンプリングで決めているのが何なのかを整理します。ここを押さえると、方式選定の判断軸が見えてきます。

分散トレーシングが生む大量のトレースと全量保存にかかる費用の問題

分散トレーシングは、1つのリクエストが複数サービスを通る経路を1本のトレースとしてつなぎ、各サービスでの処理をスパンとして記録します。この仕組みで、どの区間が遅いか・どこでエラーが出たかを経路単位で追えるようになります。問題は量です。秒間数千リクエストを処理する基盤なら、トレースも秒間数千本生まれ、各トレースが数十のスパンを含みます。これを全量で保存・索引すると、保管費用とネットワーク転送、バックエンドの処理負荷がいずれも膨らみます。しかも、正常に速く完了したトレースの大半は、後から見返す価値がほとんどありません。そこで、全部を残す前提を崩し、記録する対象を規則で絞るのがトレースサンプリングです。トレースを含む性能監視の全体像はAPM（アプリケーション性能監視）とはで扱っており、本稿はそのトレースデータの量を制御する層に集中します。

サンプリングで決めているのは記録するトレースの取捨という二択の判断

トレースサンプリングが決めているのは、生成されたトレースを記録・エクスポート・保存するかどうかの二択です。サンプリングされたトレースは全スパンがバックエンドへ送られ、されなかったトレースは破棄されるか、そもそも計装側でエクスポートされません。ここで大切なのは、サンプリングは原則としてトレース単位で一貫して判断する点です。1本のトレースの途中のスパンだけ残り、別のスパンが欠けると経路がつながらず、トレースとして役に立ちません。そのため、あるトレースを残すと決めたら、その決定をサービス間で引き継ぎ、関わる全スパンをまとめて残す設計が前提になります。この「トレース単位で一貫させる」制約が、後述する伝播やテールベースの基盤要件を生みます。

トレースサンプリングと統計のランダムサンプリングとの明確な違い

用語の混同を避けるため、ここを切り分けておきます。統計調査でいうランダムサンプリングやエリアサンプリングは、母集団から標本を抽出して全体の傾向を推定する手法です。一方のトレースサンプリングは、観測データの量と費用を抑えるために、記録するトレースを取捨するシステム運用上の仕組みで、目的が異なります。共通するのは「全部ではなく一部を選ぶ」という点だけで、選ぶ理由（推定の精度か、観測費用の削減か）も、選び方（無作為抽出か、確率やエラー条件による取捨か）も別物です。本稿で扱うのは後者、分散トレーシングにおけるトレースの取捨に限ります。

ヘッドベースとテールベースというトレースサンプリング2方式の違い

トレースサンプリングは、サンプリング決定を「いつ」下すかで大きく2方式に分かれます。この差が、実装の単純さと残せるトレースの質のトレードオフを決めます。

ヘッドベースサンプリングは開始時に確率で決めて伝播させる仕組み

ヘッドベースサンプリングは、トレースの開始時、つまり最初のスパン（ルートスパン）を作る時点でサンプリングするかを決める方式です。決定は多くの場合、トレースIDから計算する確率で下されます。例えばサンプリング率10%なら、トレースIDのハッシュに基づいて約10本に1本を残すと決め、残す・残さないをそのトレースの全スパンで一貫させます。この方式の利点は単純さと予測可能性です。決定が開始時に1回で済み、特別な中継基盤も要らず、計装ライブラリだけで完結します。データ量もサンプリング率にほぼ比例して見積もれます。欠点は、開始時点ではそのトレースがエラーになるか、遅くなるかが分からない点です。したがって「エラーのトレースだけ確実に残す」といった、結果に基づく選別はヘッドベースだけではできません。まず全体を確率で薄く残す用途に向きます。

テールベースサンプリングは完了後にエラーや遅延で選別する方式

テールベースサンプリングは、トレースが完了して全スパンがそろってから、その中身を見て残すかを決める方式です。完了後に判断するため、「エラーを含むトレースは必ず残す」「レイテンシが閾値を超えた遅いトレースは残す」「正常で速いトレースは1%だけ残す」といった、結果に基づく選別ができます。これがテールベースの最大の利点で、価値の高いトレース（エラー・異常な遅延・特定の重要トランザクション）を狙って保存しつつ、大量の正常トレースは薄く間引けます。代償は基盤の負荷です。あるトレースの全スパンがそろうまで、それらをメモリ上にため込んで待つ必要があり、しかも同じトレースのスパンを1つの判定ノードへ集めなければ完了判定ができません。分散したCollectorへスパンが散らばると判定できないため、trace_id単位で同じノードへ振り分ける構成が前提になります。この待ち受けとルーティングのぶん、メモリ消費と運用対象が増えます。

ヘッドベースとテールベースの費用と実装負荷と残せるトレースの比較

両方式は排他ではなく、ヘッドベースで全体を薄く残しつつ、テールベースでエラーや遅延を上乗せして拾う併用も採られます。判断材料として要点を並べます。

表の通り、単純さと予測可能性を取るならヘッドベース、エラーや遅延を確実に残す選別を取るならテールベース、という重み付けになります。多くの基盤は前者から始め、取りこぼしが問題になった範囲だけ後者を足す段階設計が費用対効果に見合います。

OpenTelemetryとAWS X-Rayでのトレースサンプリング実装

方式が分かったら、実際の計装・基盤でどう設定するかです。標準計装のOpenTelemetryと、代表的なマネージドであるAWS X-Rayを例に、実装の勘所を押さえます。

OpenTelemetryのサンプラー種別とサンプリング決定の伝播

OpenTelemetryは、SDKレベルで数種類の組み込みサンプラーを備えています。用意されているのは、常に残すAlwaysOn、常に捨てるAlwaysOff、トレースIDから確率で決めるTraceIdRatioBased、そして親スパンの決定を継承するParentBasedの4種です。SDKレベルの決定論的なヘッドベースサンプリングは、TraceIdRatioBasedをParentBasedで包む組み合わせで構成するのが定番になります。ここで鍵になるのが決定の伝播です。サービスをまたいでも同じトレースで決定を一貫させるため、W3C Trace Contextのtraceparentヘッダに含まれるsampledフラグで、上流が下した「残す／残さない」を下流へ引き継ぎます。ParentBasedは、親の決定があればそれに従い、なければ設定した確率で判断するサンプラーで、これによりトレース全体でサンプリングが一貫するわけです。標準の全体像とOTLP・Collectorの役割はOpenTelemetry（OTel）とはで解説しているため、本稿はサンプラーとしての側面に集中します。

OpenTelemetry Collectorのtail_samplingプロセッサ

テールベースを実装する標準的な手段が、OpenTelemetry Collectorのtail_samplingプロセッサです。このプロセッサは、受け取ったスパンをトレース単位で一定時間ためて完了を待ち、設定したポリシーで残すかを判断します。ポリシーには、エラー（status_code）で残す、レイテンシが閾値超で残す、特定の属性値（string_attribute）で残す、件数を制限する（rate_limiting）、確率で残す（probabilistic）などがあり、これらを組み合わせて「エラーは全部・遅いものは全部・残りは数%」といった規則を作ります。実装で外せないのが、同じトレースの全スパンを同一のCollectorインスタンスへ集める点です。複数のCollectorへスパンが分散すると各ノードがトレースの全体を見られず完了判定ができないため、前段にloadbalancing exporterを置き、trace_idをキーに同じトレースを同じCollectorへ振り分ける2段構成を組みます。ためる時間とメモリの見積もりが、この基盤の設計上の勘所です。

AWS X-Rayのサンプリングルール：リザーバと固定レート

マネージドなトレース基盤の例として、AWS X-Rayはサンプリングルールという仕組みでヘッドベースのサンプリングを制御します。ルールはリザーバと固定レートという2つの要素で構成される仕組みです。リザーバは「毎秒この件数までは必ず残す」という最低保証で、これによりトラフィックが少ない時間帯でも一定数のトレースを確保します。固定レートは、リザーバを超えた分から一定割合を残す設定です。例えばリザーバ1件/秒・固定レート5%なら、毎秒1本は確保しつつ、それを超えるリクエストは5%を残す動きになります。ルールはサービス名やパスの条件ごとに分けて定義でき、X-RayのAPIを介して中央で管理し全ホストへ配布されるため、アプリを再デプロイせずにサンプリング率を変えられます（2026年時点の仕組みで、詳細仕様は時点付きの参照とします）。X-Rayの位置づけと計装はAWS X-Rayとはで、AWS全体での観測基盤の組み方はAWSオブザーバビリティの実装で扱っています。

サンプリングとメトリクスの整合：集計は原則サンプリング前から

見落としやすい論点が、サンプリングとメトリクスの関係です。エラー率やレイテンシのパーセンタイルといった集計値を、サンプリング後の残ったトレースだけから計算すると、母数が偏って実態とずれます。10%サンプリングしたトレースからエラー率を出しても、それは全体のエラー率ではありません。この歪みを避けるため、リクエスト数・エラー数・レイテンシ分布のメトリクスは、サンプリングで間引く前の全量スパンから算出する設計が採られます。OpenTelemetry Collectorのspanmetrics系コネクタは、サンプリングの手前でスパンから指標を生成し、メトリクスは全量ベース・トレースは間引いた標本、という役割分担を実現します。「トレースは薄く、メトリクスは全量」を分けて考えるのが、サンプリング下で数値を信頼する条件です。

トレースサンプリングの方式とサンプリング率をどう決めるかの導入判断

ここは他社解説が手薄な論点です。方式もサンプリング率も、費用と調査可能性のトレードオフをどこで切るかの判断であり、規模と要件で答えが変わります。条件を切って言い切ります。

ヘッドベースの確率サンプリングから始めて足りる規模と要件の場面

次の条件なら、ヘッドベースの確率サンプリングから始めるのが妥当です。サービス数がまだ多くなく、障害調査ではメトリクスとログで当たりをつけ、トレースは傾向把握に使う段階であること。トレース費用を抑えたいが、テールベース基盤を運用する人員までは割けないこと。この場合、まず全体を数%〜十数%のヘッドベースで薄く残し、エラー時はログと相関IDで補完する運用が現実解です。サンプリング率は、1日あたりのトレース保存量とバックエンドの費用試算から逆算し、費用が収まる範囲で決めます。開発・ステージング環境はサンプリング率を高め（あるいは全量）にして調査しやすくし、本番は費用に合わせて下げる、という環境別の設定も有効です。

テールベースが要る場面と自前運用の負荷から見る外部委託の判断ライン

逆に、次の要件が明確ならテールベースの導入が見合います。エラーや異常な遅延のトレースを1本も取りこぼしたくないこと。決済や在庫引当のような、失敗が事業影響に直結する特定トランザクションを確実に保存したいこと。この場合、Collectorのtail_samplingで「エラーは全保存・遅延超過は全保存・正常は薄く」という規則を組みます。ただしテールベース基盤で生じるのが、スパンを一時保持するメモリ、trace_id単位のルーティング、Collectorの台数管理と障害対応まで含めた継続運用の負荷です。ここに割ける人員が確保できない場合は、トレースサンプリングを含む観測基盤の設計・構築と定常運用を外部に委ねる選択が現実的になります。一創のシステムの保守運用・内製化支援では、トレース・監視基盤の方式選定やサンプリング設計から日々の運用代行、そして最終的に自社で回せるようにする内製化の伴走まで対応しています。自社で担う範囲と委託する範囲を、運用に割ける人数と時間から線引きするのが判断の勘所です。

サンプリング率の決め方と費用と調査可能性のトレードオフの考え方

サンプリング率に唯一の正解はなく、費用と調査可能性のどちらをどれだけ取るかで決めます。基本の考え方は、まずエラーと遅延という価値の高いトレースはテールベースで取りこぼさず残す前提を置き、その上で正常トレースの残す割合を費用の許す範囲で下げる、という順序です。正常トレースを1%まで下げても、傾向把握とメトリクス（全量ベース）は保てるため、費用削減の効果が大きいのは正常系の間引きです。逆に、トラフィックが少ないサービスでサンプリング率まで下げると、そもそも残るトレースが数本しかなく調査に使えないため、リザーバのような最低保証で下限を確保します。決めた率は固定ではなく、費用実績と「調査時に必要なトレースが残っていたか」の振り返りで定期的に見直すのが、サンプリング設計を実務に合わせ続けるやり方です。

トレースサンプリングの方式選定・設定・運用で挙がるよくある質問と回答

トレースサンプリングを検討する際に挙がりやすい5つの疑問に、実装者の観点で簡潔に答えます。

トレースサンプリングとログのサンプリングは同じですか？

目的は似ていますが、単位が異なります。トレースサンプリングは、経路をつなぐ1本のトレース全体を単位に残すか捨てるかを一貫して決めます。トレースの途中のスパンだけ残ると経路がつながらず役に立たないためです。ログのサンプリングは行やイベント単位で間引くのが一般的で、トレースほど強い一貫性の制約はありません。ただし、トレースとログを相関IDで突き合わせる運用では、残したトレースに対応するログも残るよう設計をそろえる配慮が要ります。

ヘッドベースとテールベースはどちらを選ぶべきですか？

単純さを取るならヘッドベース、エラーや遅延の確実な保存を取るならテールベースです。多くのチームは、特別な基盤が要らず予測しやすいヘッドベースの確率サンプリングから始めます。運用していくうちに「エラーのトレースを取りこぼして原因が追えなかった」という課題が出た段階で、テールベースを足してエラーと遅延を確実に拾う、という順序が現実的です。両方式は併用でき、ヘッドベースで薄く全体を、テールベースでエラーと遅延を上乗せする構成も採られます。

サンプリング率はいくつに設定すればよいですか？

費用と調査可能性のトレードオフで決めるため一律の正解はありませんが、考え方は共通です。エラーと遅延のトレースはテールベースで取りこぼさず残す前提を置き、正常トレースは費用が収まる割合まで下げます。正常系は1%程度まで下げても、傾向把握とメトリクス（全量ベース）の信頼性は保てるのが理由です。トラフィックの少ないサービスは、率だけで絞ると残るトレースが少なすぎるため、毎秒一定件数を必ず残す最低保証を併用します。決めた率は費用実績と調査での過不足で定期的に見直します。

サンプリングするとエラー率などの数値は不正確になりますか？

集計をサンプリング後のトレースから出すと不正確になります。間引かれた標本から率を計算すると母数が偏るためです。これを避けるには、エラー率やレイテンシ分布などのメトリクスを、サンプリングの手前で全量スパンから算出します。OpenTelemetry Collectorのspanmetrics系コネクタなどで、メトリクスは全量ベース・トレースは間引いた標本、と役割を分ける形です。この分離ができていれば、トレースを薄くしても数値の信頼性は保てます。

OpenTelemetryでサンプリングはどう設定しますか？

ヘッドベースはSDKのサンプラーで設定します。TraceIdRatioBasedで確率を指定し、それをParentBasedで包めば、親の決定を継承しつつルートでは確率で判断する、トレース全体で一貫したヘッドベースサンプリングの構成です。サービス間の決定の引き継ぎは、traceparentヘッダのsampledフラグが担う仕組みです。テールベースはSDKではなくOpenTelemetry Collector側で行い、tail_samplingプロセッサにエラー・遅延・属性などのポリシーを設定します。この場合、同じトレースのスパンを1つのCollectorへ集めるため、前段でtrace_id単位に振り分ける構成を合わせて組みます。

関連記事

• OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説：トレースサンプリングのサンプラーとCollectorが載る計装標準で、本稿の実装の土台です。
• AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】：サンプリングルール（リザーバと固定レート）でトレースを制御するマネージドの実装例です。
• APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断：トレースを含む性能監視の上位実務で、サンプリングはそのトレース面のデータ量制御にあたります。
• AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】：AWS上でトレースを含む観測基盤を組む具体構成で、サンプリング設定を組み込む前提の実装です。
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説：トレースを含む観測性全体の考え方で、トレースサンプリングはそのトレース面の設計を担います。