SRE NEXT 2026 July 11th, 2026 at 1135am Track A Staff Developer Advocate, Grafana Labs 山口能迪 サンプリングは統計学である 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する 

山口 能迪（やまぐちよしふみ） Staff Developer Advocate Grafana Labs 専門領域 ● オブザーバビリティ ● SRE @ymotongpoo 

No content

今日話すこと ● なぜサンプリングは難しい意思決定なのか ● サンプリングを統計学として捉える ● サンプリングされたデータをどう読むべきか ● いつ避け、いつ許容できるか ● まとめ 

本セッションの対象範囲 前提: 分散トレースのサンプリング ● 本セッションの内容はログにも共通する話 ● ただコストとしては分散トレースの話が多いのでそこに絞る ● 実装・仕様に関してはオープンソースやオープン標準を中心に話す ○ OSS: OpenTelemetry ○ 標準: W3C Trace Context 

なぜサンプリングは難しい意 思決定なのか 

「データを捨てて大丈夫か」という不安 これらの疑問に答えられるか ● P99レイテンシーは信用できるのか ● エラー率の監視精度は落ちないか ● インシデント時の根本原因が辿れなくならないか ● 不安のための全量保持を正当化できるか 

Subheading goes here 「とりあえず 1% で」 Lorem ipsum dolor sit amet, consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 

サンプリングはやむを得ない手段 全量保持ができればあらゆる解析が可能 仕方なくサンプリング 制約 なんとなくでボタンを押さないためには 数理的根拠が必要 

何を、どの精度で知りたいのか 

サンプリングを 統計学として捉える 

標本誤差を直感的に理解する 味見＝サンプリング 鍋全体の味を知りたい ● 最も正確に知るには全部食べる ● それは本末転倒なので味見 どの精度で知りたいのか 

標本サイズが精度を決める 95%信頼区間 　　　: 標本比率（例: エラー率） 　　　: 標本サイズ 1.96　: 95%信頼水準の係数 100回標本を作成して標本比率を 計算したら95%の確率で母比率 ±1.96σの間に入る 

計算例 1,000 req/s でエラー率 1% のとき ● 1秒窓だと不安定 ● 5分窓にすると標本は300倍 サンプリング率 標本/秒 95% CI 100% 1,000 ±0.62pp 50% 500 ±0.87pp 10% 100 ±1.95pp 1% 10 ±6.17pp 10%サンプリングでも 5分窓なら30,000標本得られる 

必要な精度から逆算する サンプリング率の決定＝結果 サンプリング率決定の手順 1. 許容できる誤差を決める 2. 必要な標本数が決まる 3. 必要なサンプリング率が決まる 　　　: 標本比率（例: エラー率） 　　　: 許容誤差 1.96　: 95%信頼水準の係数 → 次のスライドで計算例 

計算例 エラー率 1%、許容誤差 0.5pp の場合 つまり必要なサンプル数は 1522 1,000req/sで5分窓なら、必要なサンプリング率は 0.5% 

じゃあ許容誤差は どうやって決めるのか？ 

SLO から逆算する エラーバジェットが許容誤差を決める 概ねエラーバジェットの1/2 〜 1/4 が目安 例: 成功率のSLO 99.9%の場合 1%サンプリングだと SLO違反検知に不足 ①エラーバジェット 0.1% ②許容誤差 0.05pp ③必要サンプル数 ④1000req/sで5分窓 必要なサンプリング率 

平均、エラー率、 P99の推定の難しさ 指標の性質 集約窓を広げれば精度改善 ● 平均値: 中心極限定理で安定 ● エラー率（比率）: 信頼区間を計算可能 10件の標本でP99を語ること自体が無意味 ● P50/P99: テイルの標本数に依存 ● 低頻度イベント: 確率的に補足不可 扱いやすい 難しい 

サンプリングされたデータを どう読むべきか 

データの読み方を変える サンプリング後は「推定値」 サンプリングしたら観測値ではない ● 10%サンプリング後の標本10,000は実態10,000リクエストではない ● count() や rate() をそのまま計算すると実態の1/10 ● 均一サンプリングであれば比率（エラー率など）は不変 ● しかし動的サンプリング では前提が崩れる 

Adjusted Count（重みによる調整） 各スパンは母集団の何件を代表するか サンプリング率　で残ったスパンの重みは　　となる ● 10%サンプリング→重み 10 ● 2%サンプリング→重み 50 動的サンプリングではスパンごとに重みが異なるので、集計時にこの重みを掛 けて母集団を復元する → 統計学で Horvitz-Thompson推定量 と呼ばれる 

不均一サンプリングでの考慮事項 エラー100% + 正常系 5% のエラー率を考える よくある設計: エラーは全量保持、正常系は5% ● 単純集計するとエラー率が実態より大幅に大きく見える ● 正常系1件 = 母集団20件、エラー1件 = 母集団1件 重み付けなしの count() は誤ったSLIを返す → Horvitz-Thompson推定量で重み付けすることで母集団に近い復元 

サンプリング後の値を正しく読むための設計 「推定値として読める状態」を設計する 補正には各スパンの最終的な保持確率が必要だが、多段サンプリングで確率 情報が失われがち 必要な設計は2つ 1. 保持確率をパイプライン全体で伝搬・保持する → 個々のトレースから量的な影響を推測する場合 2. SLIはそもそもサンプリング前に作る → 事前にわかっているメトリクス App SDK ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo × 50% × 20% = 10% 

probabilistic sampler プロセッサー Consistent Probability Sampling W3C Trace Context の tracestate ヘッダーで rv と th を伝搬・保持 ● rv (random value): トレースIDから導出されるトレース全体で不変な値 ● th (threshold): 保持確率を表現、前段までの閾値を表す絶対値 これにより格段が互いの設定を知らない多段サンプリングでも整合性が保たれる バックエンドは th から adjusted_count を算出 App SDK ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo ot=rv:0.37;th=2 th=2 → 50%保持 ot=rv:0.37;th=4 th=4 → 25%保持 adjusted_count = 4（保持率25%） 注: 便宜上otヘッダの中身を読みやすくしている。 実際は56ビットで表現されている。 

probabilistic sampler プロセッサー Consistent Probability Sampling の注意点 最初から最後まで全コンポーネントが対応する必要あり App SDK ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo otヘッダーなし 50%保持 何パーセントに調整 していいか不明 

spanmetricsコネクター メトリクスとトレースの責務分離 サンプリングする前に全量スパンからRED指標を⽣成 メトリクスは全量からの計算で正確なので重み考慮しなくてよい App SDK 全量スパン送信 OTel Collector spanmetrics tail_sampling Mimir Tempo サンプリング済 全量メトリクス 

許容可否の判断 

サンプリング可否のチェックリスト サンプリンクの判断のフレームワーク ● 低頻度かつ重大 （不正利用、決済失敗） ● 母数が少なく標本数を確保できない ● 完全な因果関係が調査に必須 ● 規制や監査で完全性が必要 ● ⼗分なトラフィック（数百 req/s 以上） ● ⽬的が全体傾向の把握 ● spanmetricsで集約値は全量保証 ● 必要精度が事前に⾒積もれる 避けるべきケース 許容できるケース 

まとめ サンプリング率は結果 「なんとなく 1%」から「説明できる 1%」へ 1. そもそも、このデータは捨てて良いのか 2. この指標を、どの時間窓で、どの精度で 知りたいのか 3. そのために必要な標本数はいくつか 4. その標本数を確保するには、どのサンプリング率 が必要か 

参考文献 https://amzn.to/4ftOIRw https://amzn.to/3SMdzaB