トレーサビリティ（トレーサビリティ）
ソフトウェアの実行経路や処理時間を追跡する技術。分散システムでは複数サービス間のリクエスト全体を一意 ID で追跡し、ボトルネック特定・障害分析に使う。
概要
トレーサビリティ（Traceability / Distributed Tracing）は、ソフトウェアの実行経路や各処理の所要時間を追跡する技術を指す。特に分散システム（マイクロサービス / サーバレス / FaaS）では、1 つのユーザーリクエストが複数のサービスを横断して処理されるため、各サービスでの処理時間・依存関係を一意のトレース ID で繋いで可視化する。2026 年現在、OpenTelemetry（OTel）が業界標準として確立、Datadog APM / Honeycomb / Jaeger / Grafana Tempo 等のバックエンドで可視化される。SRE（Site Reliability Engineering）/ 障害分析 / パフォーマンスチューニングの中核技術である。
主要なトレーシング基盤（2026 年）
バックエンド製品
| 製品 | 形態 | 価格 | 特徴 |
|---|---|---|---|
| Datadog APM | SaaS | $31/host/月 | 業界トップシェア、APM 統合 |
| New Relic One | SaaS | $0.30/GB データ取込 | 老舗、Java 系強い |
| Honeycomb | SaaS | $130/月〜 | 高カーディナリティ対応、SRE 寄り |
| Grafana Tempo | OSS / Cloud | 無償 / Cloud 従量 | OSS Best、Loki/Mimir 統合 |
| Jaeger | OSS | 無償 | CNCF Graduated、Uber 由来 |
| AWS X-Ray | クラウド | $5/100 万トレース | AWS 統合、Lambda 連携 |
| Google Cloud Trace | クラウド | 無償（一部上限あり） | GCP 統合 |
| Sentry Performance | SaaS | $26/月〜 | エラー追跡 + APM 統合 |
計装ライブラリ（OpenTelemetry SDK）
| 言語 | パッケージ |
|---|---|
| Node.js / Bun | @opentelemetry/sdk-node |
| Python | opentelemetry-distro |
| Go | go.opentelemetry.io/otel |
| Java | opentelemetry-java |
| Rust | opentelemetry-rust |
| .NET | OpenTelemetry.* NuGet |
| Ruby | opentelemetry-sdk |
主な構成要素
- Trace: 1 リクエストの全工程、複数 Span のツリー
- Span: 個別の処理単位（API 呼出 / DB クエリ / 関数実行）
- Trace ID: 16 バイトの一意識別子（W3C Trace Context）
- Span ID: 8 バイトの個別 Span 識別子
- Parent Span ID: Span 間の親子関係
- Attributes: メタデータ（HTTP メソッド / DB SQL / ユーザ ID）
- Baggage: サービス間で共有するコンテキスト
OpenTelemetry の標準化
| 領域 | 状況 |
|---|---|
| Tracing | GA（v1 安定版）、業界標準確立 |
| Metrics | GA（v1）、Prometheus 互換 |
| Logs | Beta、安定化進行中 |
| Profiling | Experimental、CPU/メモリプロファイリング |
| Semantic Conventions | 命名規則、HTTP / DB / Cloud 等 |
用途別の選び方
| 用途 | 推奨 |
|---|---|
| 個人 / OSS | Jaeger（OSS）or Honeycomb 無償枠 |
| スタートアップ | Sentry Performance（エラー込み） |
| 中規模 SaaS | Datadog APM（一括管理） |
| 大規模エンタープライズ | New Relic / Datadog Enterprise |
| Kubernetes ネイティブ | Grafana Tempo + Loki + Prometheus |
| AWS 中心 | AWS X-Ray + CloudWatch |
PC 自作 / 個人開発との接点
- 個人 SaaS 運用: Sentry Performance 月 $26 でエラー + パフォーマンス追跡
- 学習用途: Jaeger を Docker で立てて OpenTelemetry 計装を実践
- ホームサーバ監視: Grafana Tempo + Loki + Prometheus で全部 OSS
- AI / LLM API ラッパー: 各 API 呼び出しのレイテンシを Trace で計測
関連用語との違い
| 用語 | 違い |
|---|---|
| ロギング | イベント単位の記録、Trace は処理経路全体 |
| メトリクス | 数値指標の集計、Trace は個別実行の詳細 |
| プロファイリング | コード内部の CPU / メモリ詳細、Trace は API 呼出単位 |
| Observability（可観測性） | Logs + Metrics + Traces の統合概念 |
よくある質問
Q1: OpenTelemetry vs ベンダー独自 SDK、どちらを選ぶ？ A: 2026 年は OTel 一択。ベンダーロックイン回避 + 業界標準。Datadog / New Relic / Honeycomb 等、主要ベンダーは全て OTel 受信に対応済み。
Q2: 個人開発で Trace は必要？ A: 月数千リクエスト超なら有用。エラー追跡だけなら Sentry / Logtail で十分、レスポンス時間の遅さや特定エンドポイントのボトルネック調査なら Trace が威力を発揮。
Q3: Trace のサンプリング率は？ A: 高負荷サービスは 10% サンプリング、エラー時は 100% 採取が王道。Datadog Intelligent Sampling は重要トレースを自動保持して無駄を削減。
まとめ
- 分散システムで リクエストの実行経路を追跡 する技術
- 2026 年は OpenTelemetry が業界標準、ベンダー独立
- 個人は Jaeger / Honeycomb 無償枠 / Sentry が現実的入口