分散トレーシング & OpenTelemetry 2026 — OTel / Jaeger / Tempo / Zipkin / Honeycomb / Lightstep / SigNoz / SkyWalking / Datadog APM 徹底比較

プロローグ — 「なぜ決済が遅いのか？」という問いから

2026年の金曜夜。決済チームの Slack にアラートが鳴る。

「p99 決済レイテンシ 4.2 秒。普段は 600ms。何が遅くなったのか？」

この問いに 5 分で答えるために、人類は過去 10 年間 分散トレーシング(distributed tracing) を作り続けてきた。1 つのリクエストがゲートウェイを抜け、認証を経て、決済コアに入り、外部 PG を呼び出して、領収書キューに積まれる — その全ホップを 1 本のトレースで見る。

2020 年当時、この領域は OpenTracing、OpenCensus、Jaeger クライアント、Zipkin ライブラリ、各 APM ベンダーのエージェントが乱立していた。同じ会社の中でも Java は Datadog、Go は Jaeger、Node は New Relic というのが普通だった。2026 年の答えはシンプルだ — OpenTelemetry。

本稿は 2026 年の分散トレーシングの地図を描く。OTel 仕様と Collector、伝搬標準、OSS バックエンド(Jaeger / Tempo / Zipkin)、observability 2.0(Honeycomb / SigNoz)、買収された巨人(Lightstep)、APM スーパーリーグ(Datadog / New Relic / Dynatrace / Splunk)、eBPF 自動計装(Pixie / Beyla)、そしてサンプリングと費用まで。韓国・日本企業が実際にどう移行したかも触れる。

1. 2026 年の分散トレーシング地図 — 4 区分

エコシステムは大きく 4 つのまとまり に分かれる。

区分	代表	性格
標準・計装	OpenTelemetry	共通仕様・SDK・Collector。ほぼ全員がここを通る
OSS セルフホスト	Jaeger、Tempo、Zipkin、SigNoz、SkyWalking	自分で運用。ライセンス費なし
APM SaaS	Datadog、New Relic、Dynatrace、Splunk、AppDynamics、Sentry、Elastic	マネージド。統一 UI + アラート + AIOps
observability 2.0	Honeycomb、Lightstep(ServiceNow)	ワイドイベント・高カーディナリティ分析
eBPF 自動計装	Pixie、Beyla、Coroot	コード変更なし・カーネル/ネットワーク層

3 軸を 1 枚で見る。

              OSS                              SaaS
        +--------------+              +-----------------+
計装    | OTel SDK     |  -- 互換 --- | OTel SDK         |
        | (ベンダー中立)|              | (ベンダーアダプタ) |
        +------+-------+              +--------+--------+
               |                                |
        +------v-----------------------------------v-----+
        |          OpenTelemetry Collector              |
        |  receivers --> processors --> exporters       |
        +------+-----------------------------------+----+
               |                                  |
       +-------v--------+                +--------v--------+
       | Jaeger / Tempo |                |  Datadog APM    |
       | Zipkin / SigNoz|                |  New Relic APM  |
       | SkyWalking     |                |  Honeycomb 等   |
       +----------------+                +-----------------+

要点: 計装は OTel に統一し、バックエンドは差し替え可能にする。 これが 2026 年の標準姿勢だ。

2. OpenTelemetry — CNCF Graduated (2024)

OpenTelemetry(OTel)は OpenTracing(2016)と OpenCensus(2018)の合併として 2019 年に発足した。2021 年に CNCF Incubating、2024 年 11 月に CNCF Graduated へ昇格。事実上の業界標準になった。Kubernetes に次ぐ規模の CNCF プロジェクトだ。

OTel が提供するもの:

仕様(Specification): トレースとは、スパンとは、どんな属性を持つか。
API: 言語別の計装 API(Java、Go、Python、.NET、Node.js、Ruby、PHP、Rust、C++、Swift など)。
SDK: API の参照実装 — サンプリング、バッチ、エクスポータ込み。
Collector: 別プロセスで動くテレメトリーパイプライン。
Semantic Conventions: HTTP、DB、メッセージングなどの標準属性名。
OTLP(OpenTelemetry Protocol): gRPC / HTTP のワイヤーフォーマット。

データモデルの中核: トレースはスパンのツリー。各スパンは trace_id、span_id、parent_span_id、開始・終了、属性、イベント、リンクを持つ。

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
)

tracer = trace.get_tracer("checkout")
with tracer.start_as_current_span("charge_card") as span:
    span.set_attribute("user.id", user_id)
    span.set_attribute("amount", amount)
    result = pg.charge(...)
    span.set_attribute("pg.response_code", result.code)

OTel の真価は、メトリクス・ログ・トレースを同じ SDK で扱うところにある。トレースは Graduated 安定、メトリクスも安定、ログは 2024〜2025 年に多くの言語で安定段階に達した。OTel はもはや単なるトレース標準ではなく、統合テレメトリー標準 だ。

3. OTel Collector — Receivers・Processors・Exporters

OTel SDK がアプリの中に入るなら、Collector はアプリの外で動く別プロセス。分離する理由は:

アプリにベンダーバックエンドの SDK を入れずに済む — 依存衛生がよくなる。
サンプリング・フィルタ・ルーティングを 集中で 適用できる。
バックエンドを変えてもアプリを再起動しなくていい。
トラフィック急増時のキューイング・再試行。

Collector の 3 軸:

コンポーネント	役割	例
Receivers	受信	otlp、jaeger、zipkin、prometheus、kafka、filelog
Processors	加工・変換・フィルタ・サンプリング	batch、memory_limiter、tail_sampling、attributes
Exporters	送信	otlp、jaeger、prometheus、datadog、honeycomb、logging

この 3 軸をパイプラインでつなぐ。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 1500
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: sample_10
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls: { insecure: true }
  datadog:
    api: { site: datadoghq.com, key: ENV_DD_API_KEY }

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, tail_sampling, batch]
      exporters: [otlp/tempo, datadog]

同じトレースを OSS バックエンド(Tempo)と SaaS(Datadog)に同時 に送れる。これが Collector を移行ツールとして使う理由 — 行を 1 本足して並列で比較し、検証してから元を切る。

Collector の 2 モード:

Agent: 各ホスト/ノード/Pod サイドカーに 1 つ。少量・近距離の収集。
Gateway: クラスタ/リージョンに数台。バッファリング・テールサンプリング・中央ポリシー向け。

大規模では Agent → Gateway → バックエンド の 2 段構成が多い。

4. 伝搬標準 — W3C Trace Context・B3・Baggage

分散トレーシングが「分散」であるのは、同じ trace_id が サービス境界を越えて伝搬 するからだ。伝搬は通常 HTTP ヘッダで行う。

W3C Trace Context (2020 勧告)

2020 年に W3C が標準化した 2 つのヘッダが 2026 年のデファクトだ。

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             |   |                                |                |
             |   trace-id (16 byte hex)            parent-span-id   trace-flags
             version

tracestate: vendor1=value1,vendor2=value2

traceparent: すべての OTel SDK が標準で送受信する。
tracestate: ベンダー固有の付加情報(例: サンプリング決定)。

OTel SDK は HTTP・gRPC・メッセージング(Kafka・RabbitMQ ヘッダ)・一部の SQL コメントにまでこのヘッダを自動注入する。

B3 Propagation (Zipkin 系)

Zipkin が作ったマルチヘッダ形式。

X-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736
X-B3-SpanId: 00f067aa0ba902b7
X-B3-ParentSpanId: 05e3ac9a4f6e3b90
X-B3-Sampled: 1

OTel は W3C と B3 を両方サポート。レガシーシステムと混じる場面では両方を受けられるようにする。

Baggage — 「次のサービスへ一緒に運ぶコンテキスト」

Baggage は trace_id とは別のキー・バリューをトレース伝搬とともに運ぶ。例: user.tier=gold、tenant=acme、experiment=ab_42。

baggage: user.tier=gold,tenant=acme

使いどころ:

すべての下流スパンに同じラベルを自動で付けたいとき。
baggage の値で動的にサンプリングを変えたいとき(例: 「tenant=enterprise は 100% サンプル」)。
下流で権限・ロギング・ルーティングに参照する。

注意: baggage は秘密ではない。 次のホップが外部システムだとヘッダが見える。PII は絶対に baggage に入れない。

5. Jaeger — CNCF Graduated、Uber 出身のクラシック

Jaeger は Uber が 2015 年に作った分散トレーシング。2017 年 CNCF Incubating、2019 年 CNCF Graduated。OTel 以前のデファクト標準だった。

特徴:

Go 製、バックエンドはモジュール式。
ストレージ: Cassandra、Elasticsearch / OpenSearch、ClickHouse、Badger(組込)。
UI: トレースビュー、依存関係グラフ、比較ビュー。
取り込み: 自前 SDK(非推奨)・Zipkin プロトコル・OTLP。

2024 年以降、Jaeger プロジェクトは明示的に 「OTel ファースト」 に舵を切った。Jaeger 独自 SDK は非推奨で、新規ユーザーには OTel SDK を勧め、Jaeger は「バックエンド + UI」として使うのが推奨経路だ。v2 バックエンドは内部的に OTel Collector をベースにビルドされている。

デプロイ形:

AllInOne: agent + collector + query + UI + memory storage を 1 コンテナに。デモ/開発用。
Production: collector + storage + query/UI を分離、agent はホスト別。
Kubernetes Operator: jaegertracing/jaeger-operator で CR 一行。

長所: 軽量、OSS、導入が容易、UI が直感的。

弱点: メトリクス/ログはやらない(トレース専用)。高カーディナリティ分析は弱め。UI は trace_id 検索と時間範囲フィルタが主体。

6. Grafana Tempo — Parquet ベース、「オブジェクトストレージがホットパス」

Grafana Tempo は 2020 年に Grafana Labs が作ったトレースバックエンド。コンセプトが明確だ — 「インデックスのないトレースストア」。

従来の Jaeger / Zipkin は全スパンにインデックス(サービス、オペレーション、タグ)を作る。インデックスがスパン本体より大きく、コストも高い。Tempo はインデックスを作らず、trace_id でのみ検索 する — ただし、メトリクス(Prometheus)・ログ(Loki)から trace_id を取り出して繋ぐ前提だ。「exemplar をクリックすればトレースが出る」UX。

ストレージは S3 / GCS / Azure Blob のようなオブジェクトストレージに直接。インデックスがないので保存が安い。2023 年以降はディスクフォーマットが Parquet に統一された。カラムナで圧縮が効き、外部ツール(Athena、DuckDB)からも読める。

クエリ言語 TraceQL もある — トレース本体の中でパターンを探す。

{ resource.service.name = "checkout"
  && span.http.status_code = 500
  && duration > 1s
}

長所:

保存コストが最安 — オブジェクトストレージ直書き。
Loki・Mimir・Grafana と自然に連携。
Parquet なので外部分析ツールに持っていける。

弱点:

「メトリクス/ログとトレースを exemplar で繋ぐ」運用がないと価値が落ちる。
一般検索(サービス名・タグ)は Jaeger より弱い(代わりに TraceQL)。

大規模・長期保存が最優先なら Tempo が答え。

7. Zipkin — Twitter 原典、生きているクラシック

Zipkin は Twitter が 2012 年にオープンソース化した分散トレーシング。Google Dapper 論文の最も影響力のある OSS 実装で、後続のすべてのトレーシングシステムの出発点となった。

特徴:

Java ベース(Brave 計装)。
ストレージ: メモリ(開発用)、Cassandra、Elasticsearch、MySQL。
シンプル — 単一 jar で動く。
B3 伝搬の起源。

2026 年で新規採用は多くないが、以下では今も現役だ。

既存の B3 / Brave Java コードベースのバックエンド。
「Jaeger でも重い」と感じる小規模システム。
OTel Collector の zipkin receiver / exporter による変換ハブ。

Jaeger と比べると、UI は地味だがセットアップはより簡単。

8. Honeycomb — Charity Majors の「observability 2.0」

Honeycomb は 2016 年に Charity Majors と Christine Yen が創業した SaaS オブザーバビリティ会社。彼女らが定着させた 「observability 2.0」 という表現が業界の語彙を変えた。

主張: 従来のモニタリング(メトリクス・ログ・トレース分離)は事前に決めた次元しか見えない。実際のデバッグに必要なのは 高カーディナリティ次元(user_id、request_id、k8s_pod 等)を自由にスライス/ダイス できる ワイドイベント(wide event) だ。

Honeycomb のデータモデル: すべてのスパンが実質「イベント」。自由に属性を付け、クエリは BubbleUp(異常自動分解)・ヒートマップ・トレースビュー を行き来する。

BubbleUp の結果例:
  遅いリクエスト(p95)の 73% が user.tier=enterprise かつ
  db.host=replica-3 かつ
  client_country=JP である。
  ← この組み合わせを人が事前に指定しなくても自動で見つける。

差別化要素:

すべての次元にインデックスを作らない — 自前のカラムナストア(Retriever)。
サンプリング SDK(Refinery) — テールサンプリングのデファクト。
OTel 100% 互換取り込み。
料金: イベント数(スパン数)・保存期間。

長所: デバッグ速度が違う。「なぜ遅いか」をインデックスなしで 1〜2 分で絞れる。

弱点: SaaS のみ(セルフホスト不可)。単純な監視で高カーディナリティが要らないならオーバースペック。

9. Lightstep → ServiceNow Cloud Observability

Lightstep は Google Dapper 共著者の Ben Sigelman が 2014 年に創業した会社。「統計的分析」「メトリクスとトレースの融合」を早くから掲げていた。

2021 年に ServiceNow が買収。現在は ServiceNow Cloud Observability にリブランド。単独製品としては影が薄くなったが、ServiceNow の ITSM/AIOps とセットでエンタープライズ市場(特に ITIL・CMDB と絡む場所)で生き残っている。

技術的遺産:

OTel 初期の標準化に中心的役割(Sigelman は OTel ガバナンス委員)。
トレースに対する統計的ノイズ低減を早くから推した。

2026 年の評価: ServiceNow エコシステムの中にいる会社なら検討。そうでなければ Honeycomb・Datadog・OSS 陣営の方が活発だ。

10. SigNoz — OSS フルスタック・オブザーバビリティ

SigNoz は 2020 年にインド発のオープンソース APM。ClickHouse の上にトレース・メトリクス・ログを全部のせる。「Datadog の OSS 代替」 をうたう。

特徴:

100% OTel ネイティブ — OTel Collector をほぼ SDK のように扱う。
単一 UI でトレース/メトリクス/ログ/例外。
ClickHouse ベース — クエリが速く、保存も圧縮効率が高い。
2024 年シリーズ B 資金調達 — LogStream・Anomaly Detection・メトリクス v2 をリリース。

docker-compose up 一発でフルスタックが立ち上がり、OTel 互換なので移行が比較的スムーズ。

2024〜2025 のアップデート:

LogStream: ログも同じ UI で検索・フィルタ。
Anomaly Detection: ML ベースの異常検知(ベースライン自動)。
Trace Funnels: 決済のような多段フローのステップ別成功率。

長所: OSS なのに UI が洗練されていてフルスタック。クラウド SaaS もあり、セルフホストが負担なら一方に逃げられる。

弱点: ClickHouse 依存が強く、大規模運用にはノウハウが要る。エンタープライズ機能(SSO、SOC2 レポート等)はクラウドプランに偏る。

11. Apache SkyWalking — APM + トレース、中国主導

Apache SkyWalking は 2017 年 Apache Incubating、2019 年に Graduated した OSS APM。中国系のコントリビュータ(華為・アリババ・テンセント)が厚く、東アジア圏でユーザーが多い。

特徴:

自前エージェント(Java、.NET、Node) + OTel 互換。
トレースだけでなく サービストポロジ・メトリクス・ログ・イベント をすべて。
バックエンド: 自前 OAP サーバ + Elasticsearch / BanyanDB(自前時系列 DB)。
UI: トポロジ可視化が強い。
サービスメッシュ(Istio)可視化、イベント駆動の自己修復(SkyWalking-Rover、eBPF)などの拡張。

2026 年の立ち位置: 中国・インド・東南アジアの OSS 陣営のメイン選択肢。韓国・日本では相対的に少ないが、中国法人を運営する企業なら自然に出会う。

12. Datadog APM / New Relic APM / Elastic APM / Sentry Performance

商用 APM スーパーリーグのトレース陣容。

Datadog APM

市場シェア最大。UI の完成度が圧倒的。
OTel ネイティブ入出力 — dd-trace もあるが OTel SDK 直も対応。
トレース + APM メトリクス(throughput・error・latency) + プロファイリング連結。
料金: ホスト単価 + 取り込みスパン課金で分離。大規模トラフィックでは請求書が怖くなる。
Watchdog(AIOps)、Continuous Profiler、Database Monitoring へ連結。

New Relic APM

1 世代目 APM(2008)の元祖。2020 年代に 「Telemetry Data Platform」 へ再ポジショニング。
2020 年に料金体系大改革 — ユーザー単価 + 取り込み GB 単価へ単純化。
OTel 互換、OTel オンリー運用も可能。
New Relic AI、ログ・トレース自動結合。

Elastic APM

Elasticsearch の上に乗せた APM。ELK スタックを既に使っている現場なら自然。
セルフホスト・Elastic Cloud の両方。
OTel + OSS バックエンドより高くなりにくく、検索・ダッシュボード・ML が統合される。

Sentry Performance

Sentry は元々エラーモニタリング会社。2020 年頃に Performance(分散トレーシング) を追加。
強み: フロントエンドとの結合。React / Vue 等のクライアント SDK のトレースがそのままバックエンドへ繋がる。
バックエンド専用 APM としては弱いが、フルスタック(特に SPA フロント)は強い。

13. Dynatrace / AppDynamics (Splunk) / Splunk Observability Cloud

エンタープライズ重量級。

Dynatrace

1993 年創業のオーストリア企業。エンタープライズ APM の巨人。
自前エージェント OneAgent がインストールした瞬間に自動でトポロジ・メトリクス・トレースを作る — 人手はほぼ不要。
AI エンジン Davis が原因候補を自動提示。
OTel 入力にも対応。
料金: エンタープライズ。ROI が大きい環境(グローバル大型運用)向き。

AppDynamics (Splunk 傘下)

2017 年に Cisco が買収、2024 年に Cisco が Splunk を買収したため、AppDynamics は 再び Splunk 傘下 に。
Java・.NET に強い。ビジネストランザクション中心ビュー。
2025〜2026 のロードマップでは Splunk Observability Cloud へ段階的に統合される方向。

Splunk Observability Cloud

2019 年の SignalFx 買収で生まれたライン。メトリクス・トレース・ログ + RUM(real-user monitoring)。
Cisco の Splunk 買収(2024)以降、SignalFx と AppDynamics の遺産を 1 つの SKU に統合する作業が進行中。
Cisco + Splunk を既に使っている現場には強い候補。

14. eBPF トレーシング — Pixie と Beyla、コード変更なしの自動計装

eBPF は Linux カーネル内で安全にコードを実行する技術。ネットワークパケット・システムコール・HTTP リクエストをカーネル層で捕捉できる — アプリのコードを 1 行も変えずに。

Pixie

2019 年に開始、2021 年に New Relic が買収。その後 OSS として CNCF Sandbox(2021)、2023 年に Incubating。
Kubernetes に DaemonSet として入れると、HTTP / HTTPS / gRPC / DNS / MySQL / Postgres / Redis 等のリクエストを自動キャプチャ。
データはノード内インメモリに留まり(デフォルト 24h)、必要なときだけ外に出す — プライバシー・コスト面で有利。
クエリ言語は PxL(Python ライク)。

Beyla — Grafana の eBPF 自動計装

Grafana Labs が 2023 年に発表。2024 年 GA。
単一バイナリ・サイドカーで入り、eBPF で HTTP / gRPC を捕捉して OTel スパン として出す。
セルフホスト OTel + Tempo スタックに最もスムーズに刺さる。

eBPF トレーシングの位置

コード変更なしの高速可視化 が要る場面 — ポリグロット環境、レガシーコード、「今この瞬間どこが遅いか」の即時把握。
弱点: ビジネスコンテキスト(user_id など) は取れない。eBPF が見るのはネットワークペイロード — アプリがその中に ID を入れなければ見えない。

結論: eBPF + OTel SDK の両方を併用するのが定石。eBPF でインフラ・ネットワーク層の自動可視化、OTel SDK でビジネススパン・高カーディナリティ属性。

15. サンプリング — head vs tail vs ratio

トレース費用 = 生成スパン数 × 単価。費用カーブの 8 割以上は サンプリング戦略 で決まる。

3 つの戦略:

Head-based サンプリング

トレースの 開始時 に決定。決定結果を traceparent の trace-flags で伝搬。
決定材料が少ない(まだ何が起きるか分からない)。
長所: シンプル、コスト予測が容易、SDK だけで可能。
通常 1〜10% の固定比率で流す。

Ratio サンプリング

Head サンプリングの下位分類。例: sample_ratio=0.1(10%)。
OTel SDK デフォルト(TraceIdRatioBased)。
一貫性保証: trace_id ハッシュで決定 → 同じトレースは全サービスで同じ決定。

Tail-based サンプリング

トレースが 終わったあと(または一定時間待った後)に決定。
全スパンをまず Collector に集めて見る — 決定材料(エラー有無、合計レイテンシ、特定属性)が豊富。
長所: エラーと遅いトレースを 100% 保存、正常は 1% だけ。費用対価値が最高。
弱点: 決定までキューイングが要る(通常 30 秒〜数分)、メモリ・CPU を消費、同じトレースの全スパンが同じ Collector インスタンスへ届かねばならない(load balancing exporter で trace_id ハッシュルーティング)。

OTel Collector tail_sampling プロセッサの例:

processors:
  tail_sampling:
    decision_wait: 30s
    num_traces: 100000
    policies:
      - name: keep_errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: keep_slow
        type: latency
        latency: { threshold_ms: 1500 }
      - name: keep_enterprise
        type: string_attribute
        string_attribute: { key: tenant.tier, values: [enterprise] }
      - name: random_2pct
        type: probabilistic
        probabilistic: { sampling_percentage: 2 }

このポリシーは: エラー 100% + 1.5 秒超 100% + enterprise テナント 100% + 残りの 2% のみ保持。

どれを選ぶか

状況	推奨
小規模(数百 rps)	Head 100% または ratio 50%
一般的 SaaS(数千 rps)	Head 10% + エラー 100%(SDK で分岐)
大規模(数万〜数十万 rps)	Tail-based + エラー/遅い/特定テナント 100%
費用が爆発中	Tail-based を即導入 — 通常 5〜10 倍削減

16. 費用 — テールサンプリングプロキシと請求書

分散トレーシングの請求書が怖くなる 2 つのパターン。

トラフィック増加に比例した請求書 — 100% サンプル + 大規模トラフィック。
高カーディナリティ属性の爆発 — 全スパンに user_id、request_id、k8s_pod、container_id を貼る。

対処:

テールサンプリングを Gateway Collector に置く。 SaaS に入る前にカットする。同じトレースの全スパンを同じ Collector に届けるため、前段に loadbalancing exporter を置く。
保存は OSS、「ホット」トレースだけ SaaS。 すべてのトレースを Tempo へ送り、エラー・遅いだけ Honeycomb / Datadog に追加送信。
属性ホワイトリスト。attributes プロセッサで使わない属性を削除する。
ログ・トレース連結でトレース本体を細くする。長くて大きい属性はログに置き、スパンには log_id 参照のみ。

実戦経験値(著者の保守的見積もり):

無理な 100% → 1% head サンプル = 請求書 90% 減、デバッグ品質 30% 減。
1% head → テールサンプル(エラー 100% + 正常 1%)= 請求書同じ、デバッグ品質 200% 増。
Gateway Collector + ホワイトリスト追加 = 請求書をさらに 30% 減。

17. 韓国 / 日本 — 実例

韓国

トス(Toss) — 自前のトレースインフラ(Kafka Consumer + Spring Sleuth)から 2023〜2024 年にかけて OTel + Tempo + Grafana スタックへ段階移行。決済・送金トラフィックのテールサンプリングで費用を抑えた。Toss SLASH カンファレンスで関連発表がある。
カカオ(Kakao) — 社内 APM から OTel 標準化へ移行。KakaoTalk のバックエンドは Java スタックなので、OTel Java agent の自動計装 + 一部コアサービスのみ手動計装の組み合わせ。if(kakao) カンファレンスにトレーシング事例が時々登場。
NAVER — 社内モニタリング基盤 nLog、Pinpoint といった自前ツールに OTel 互換インターフェースを追加する方向。Pinpoint は NAVER 製の OSS APM(Java バイトコード計装が強み)で、自ら OTel exporter を追加して標準に合流。

日本

メルカリ — Datadog から OTel + 自前バックエンドの組み合わせへ移行した事例を Mercari Engineering ブログが公開。トラフィック費用が主要動機で、OTel Collector + テールサンプリングで請求書を抑えた。
NTT コミュニケーションズ — 社内マルチクラウド監視プラットフォームに OTel を採用。Datadog / New Relic / SkyWalking 混在環境を OTel で一元化 — 韓国でいえば SK テレコム・KT のような通信キャリアのモニタリング部門の重厚事例。
CyberAgent / DeNA / LINE — ゲーム・メディア・メッセンジャートラフィック特性上、テールサンプリング・高カーディナリティ分析の要件が高く、Honeycomb / Datadog + OSS セルフホスト(Tempo・Jaeger)のハイブリッド。

共通パターン: ベンダーロックインを避けるため、SDK は OTel、バックエンドは差し替え可能に。SaaS の単価交渉も OTel 互換が武器になる。

18. 誰が何を選ぶべきか

小さなチーム / サイドプロジェクト

OTel SDK + Jaeger(AllInOne)あるいは SigNoz(セルフホスト)、または Honeycomb Free / Sentry Performance。
立ち上げ 30 分、費用は 0〜数万円。

中規模(数十名、数万〜数十万 rps)

OTel SDK + Collector + Tempo + Grafana(OSS フルスタック)。費用はインフラのみ。
あるいは Datadog / New Relic APM(SaaS、適用が速くアラートが統合済み)。
安全な移行パターンは、両方を OTel Collector で並走させて片方に絞ること。

エンタープライズ

Dynatrace / Splunk Observability Cloud / Datadog — 自動トポロジ・AIOps・全社アラート・監査ログ。
OTel 互換は必須条件。OTel オンリーで受けるようベンダーと交渉する。

デバッグ優先(高カーディナリティ・オンデマンド分析)

Honeycomb — observability 2.0 の姿勢。費用はイベント数・保存期間ベース。
SigNoz が OSS で近い方向を追いかける。

セルフホスト強制(規制・セキュリティ)

OTel + Tempo / Jaeger / SigNoz / SkyWalking。SigNoz はフルスタック(トレース + メトリクス + ログ + イベント)、Tempo + Loki + Mimir は Grafana 陣営の分離型。

Kubernetes ポリグロット + コード変更が難しい

Pixie または Beyla — eBPF で自動可視化。ビジネススパンは OTel SDK で追加。

19. アンチパターン 10 選

OTel を使わずベンダー SDK を直結 — ベンダー切替時にコードを総書換。
計装はしたがサンプリングが 100% のまま — 請求書が爆発。
テールサンプリングなしで「エラーは全部見たい」 — head 1% サンプルでは 99% のエラーが消える。
すべてのスパンに user_id・request_id を無差別に貼る — 高カーディナリティ請求に直結。
W3C と B3 の併用を忘れる — レガシーサービス境界でトレースが切れる。
Baggage に PII を入れる — 次のホップでヘッダから漏洩。
メトリクス・ログ・トレースのバックエンドが分断され trace_id 連結なし — exemplar 運用が崩壊。
Collector を置かず SDK から直接 SaaS へ — バックエンド切替でアプリ総デプロイ。
テールサンプリングの trace_id ルーティングを無視 — 同じトレースが複数 Collector に分散し決定が誤る。
トレースだけ見てメトリクス・ログを見ない — トレースは「特定リクエストの物語」、メトリクスは「全体の傾向」。両方必要。

エピローグ — OTel の上に自由を建てる

2026 年の教訓は一文だ。

計装は OTel に統一し、バックエンドは差し替え可能にする。

OTel は単なるトレース標準ではなく、ベンダーロックインを断つインターフェース だ。その上に — Jaeger / Tempo の OSS の自由でも、Honeycomb のデバッグの深さでも、Datadog の統合 UX でも、Dynatrace の AIOps でも — 自分に合うバックエンドを乗せる。差し替えコストがコード書換ではなく Collector の設定一行になった瞬間、交渉力もコスト管理もデバッグ品質も全部手に入る。

次回候補: OpenTelemetry メトリクス徹底解説 — exemplar と trace-metric 連結、ログをトレースに繋ぐ — Loki・OpenSearch・OpenTelemetry Logs、テールサンプリング実戦 — load-balancing exporter トポロジと費用カーブ。

— 分散トレーシング & OpenTelemetry 2026 徹底比較、了。