トレース・サンプリング率¶

このダイヤルは何か¶

トレース・サンプリング率は、エージェントの実行トレース（各 LLM 呼び出し、ツール実行、意思決定のステップごとの記録）をどの割合で収集・保存するかを制御するパラメータです。100% ならすべてのリクエストのトレースを記録し、1% なら 100 リクエストに 1 件だけ記録します。

AI エージェントシステムのトレースは、従来の Web サービスのログとは質的に異なります。1 回のユーザーリクエストが複数の LLM 呼び出し、ツール実行、中間推論を含むため、1 リクエストあたりのトレースデータ量が桁違いに大きくなります。プロンプト全文、出力全文、ツール引数・戻り値、中間的な推論ステップなどを含めると、1 リクエストのトレースで数千〜数万トークン相当のデータが生成されます。

このため、全量トレースは観測基盤のストレージ・転送コストを爆発させます。しかし、サンプリング率を下げすぎると、障害発生時に該当リクエストのトレースが記録されておらず、原因究明が不可能になります。とくに LLM の出力は確率的であるため、「同じ入力を再投入すれば再現できる」という前提が成り立ちません。このジレンマを「条件付きサンプリング」で解決するのが本ダイヤルの要点です。

効かなすぎる害 ⇔ 効きすぎる害¶

サンプリング率が低すぎる場合（効かなすぎ）¶

サンプリング率を 0.1% のように極端に下げると、以下の問題が起きます。

障害の再現不能：エラーが発生したリクエストのトレースが記録されていない確率が高く、「何が起きたか」を事後に追跡できません。LLM の出力は確率的なため、同じプロンプトを再投入しても同じエラーが再現するとは限りません。トレースなしでは原因究明が推測に頼ることになります。
品質劣化の見逃し：エージェントの応答品質が徐々に低下しても、サンプルが少なすぎて統計的に有意な傾向を検出できません。モデルのバージョンアップやプロンプト変更による品質回帰を見逃すリスクがあります。
監査要件の不達成：金融、医療、法務などの規制領域では、意思決定の過程を後から再構成できることが求められます。サンプリング率が低すぎると「なぜその判断に至ったか」を説明できないリクエストが大量に発生します。
コスト異常の遅延検知：LLM 呼び出しのトークン消費やツール呼び出しの頻度を十分にモニタリングできず、コストの異常な増加に気づくのが遅れます。

サンプリング率が高すぎる場合（効きすぎ）¶

サンプリング率を 100% に設定すると、以下の害が生じます。

観測コストの爆発：プロンプト全文と出力全文を全リクエストで保存すると、観測基盤のストレージ・転送コストが本番の LLM 呼び出しコストに匹敵するか、それを上回ることがあります。エージェントの 1 リクエストが 5 回の LLM 呼び出しを含み、各呼び出しが数千トークンの入出力を持つ場合、1 リクエストのトレースデータは数十 KB〜数百 KB になります。
パフォーマンスへの影響：トレースの収集・送信が同期的に行われると、リクエストのレイテンシに影響します。非同期送信でも、大量のデータ生成がメモリ・CPU を消費します。
PII の拡散リスク：プロンプトや出力に含まれる個人情報が観測基盤に広く保存され、アクセス制御が不十分だとデータ漏洩のリスクが高まります。トレースが増えるほど PII の拡散面が広がります。
ノイズの中に信号が埋もれる：大量のトレースデータの中から問題のあるリクエストを見つけることが困難になります。適切なフィルタリングとアラート設定がないと、「データはあるが見つけられない」状態に陥ります。

決め方¶

サンプリング率は [accountability] と [cost_sensitivity] のバランスで決まりますが、最も重要なのは条件付きサンプリングの設計です。一律の確率ではなく、リクエストの属性に応じてサンプリング率を変えます。

[accountability]：説明責任が高いほど、サンプリング率を全体的に引き上げます。監査要件がある領域では、対象カテゴリのリクエストは 100% 記録が求められる場合があります。
[cost_sensitivity]：コスト感度が高い場合、成功リクエストのサンプリング率を下げ、エラー/異常リクエストのみ全量記録するという非対称な戦略をとります。
[failure_cost]：失敗コストが高い経路のリクエストは、成功時も高いサンプリング率で記録します。障害が発生したときに「直前の正常リクエスト」との比較が必要になるためです。

条件付きサンプリングの判定基準は以下のとおりです。

エラー/例外が発生したリクエスト → 100% 記録（必須）
HITL（人間介在）が発生したリクエスト → 100% 記録（承認判断の根拠として必要）
高リスク操作（副作用あり、不可逆）を含むリクエスト → 100% 記録
成功したリクエスト → 標本率で記録（1〜10%）
レイテンシが P95 を超えたリクエスト → 100% 記録（性能問題の診断用）
コストが閾値を超えたリクエスト → 100% 記録（コスト異常の診断用）

目安値（出発点）¶

リクエストの属性	サンプリング率の目安	補足
エラー/例外発生	100%	再現性のない障害のデバッグに不可欠
HITL 発生（人間承認/エスカレーション）	100%	承認判断の妥当性を事後検証するため
高リスク操作を含む（送金、データ削除等）	100%	不可逆操作の監査に必須
レイテンシ P95 超過	100%	性能劣化の根本原因分析に必要
成功かつ低リスク	1〜10%	品質の統計的モニタリングに十分。`[accountability]` が高い場合は上限寄り
開発・ステージング環境	100%	コストが問題にならない範囲で全量記録

G1 Tiered Observability のホット/コールド分離と組み合わせ、サンプリングされたトレースはコールド層に全文を、それ以外はホット層にメタデータのみを記録するのが効率的です。

実践的なアドバイス¶

「全量か無か」ではなく「何を全量にするか」で考えてください。エラー・HITL・高リスク操作を全量記録し、成功リクエストを標本記録するだけで、観測の実用性を維持しながらコストを大幅に削減できます。
サンプリング判定はリクエストの開始時ではなく終了時に行うことも検討してください。head-based sampling（リクエスト開始時に決定）は実装が簡単ですが、エラーが発生するかどうかは事前に分かりません。tail-based sampling（リクエスト完了後に決定）であれば、結果に基づいてサンプリングを決められます。ただし、中間データを一時的にバッファする必要があります。
トレースの粒度をサンプリング率とは別に制御してください。全量記録するリクエストでも、プロンプト全文はコールド層に、メタデータ（モデル名、トークン数、レイテンシ、ステータス）はホット層に分離します。これにより、ダッシュボードの応答性を維持しながら、必要時に全文を引ける構成になります。
サンプリング率は運用開始後に段階的に下げてください。最初は高いサンプリング率（50〜100%）で始め、システムの安定性を確認した後に成功リクエストの率を徐々に下げます。この過程で「この率で十分な統計的信頼性が得られるか」を検証できます。
correlation ID（trace ID）の伝播を確実にしてください。マルチステップのエージェント実行では、最初のリクエストから最後のツール呼び出しまで一貫した trace ID が紐づいていないと、部分的なトレースしか得られません。とくに非同期処理やキューを介する場合に ID が途切れやすいので注意が必要です。