# OpenTelemetry vs Jaeger: 標準 vs トレーシングバックエンド

> OpenTelemetry vs Jaeger: ベンダー中立な計装標準 vs トレーシングバックエンドと UI。分散トレーシングでどう組み合わさるか。

Source: https://latchkey.dev/ja/learn/tool-comparisons/opentelemetry-vs-jaeger  
Updated: 2026-06-26

OpenTelemetry はテレメトリーを生成しエクスポートするためのベンダー中立な標準で、Jaeger はトレースを保存し可視化するバックエンドと UI です。

OpenTelemetry(OTel)は CNCF の標準で - SDK、API、そして collector を含み - アプリを計装し、トレース、メトリクス、ログを任意のバックエンドへエクスポートします。Jaeger はストレージとクエリ UI を備えた分散トレーシングバックエンドです。両者は補完的で、OTel がデータを生成し、Jaeger(をはじめとするもの)がそれを保存し表示します。

## Comparison

|  | OpenTelemetry | Jaeger |
| --- | --- | --- |
| 役割 | 計装 + エクスポート標準 | トレーシングバックエンド + UI |
| 対象範囲 | トレース、メトリクス、ログ | トレース |
| ベンダー中立性 | あり(どこへでもエクスポート) | 一つのバックエンド |
| ストレージ | なし(エクスポート) | あり |
| 最適な用途 | 標準化された計装 | トレースの閲覧とクエリ |

## 実際のところ

これらは本当にどちらか一方という関係ではありません。アプリを OpenTelemetry で計装し、そのトレースをバックエンドへ送ります - それは Jaeger でも構いません。OTel はベンダーロックインに対して将来を守り、Jaeger はトレースを保存し探索するための成熟したオープンソースの場を提供します。Jaeger は現在 OTel の取り込みを直接サポートしているため、モダンなパターンは OTel の SDK が Jaeger(または他の)バックエンドに供給する形です。

## 補足

CI や build のステップも OTel でトレースできます。build は CI runner 上で実行され、より高速なマネージド runner はそれを短縮します。

## Benchmark on your repository before choosing

Build-tool benchmarks published by vendors use repositories chosen to show a difference. Yours is the only one that matters, and both a cold and a warm measurement are needed because CI mostly runs cold.

```Terminal
# cold: no cache, the CI condition
rm -rf node_modules/.cache dist && time <tool> build

# warm: the local development condition
time <tool> build

# and the one people forget: incremental after a one-line change
echo "// touch" >> src/index.ts && time <tool> build
```

> Cold and warm can rank the two tools in opposite orders. Decide which one you are optimising for first: CI time is cold, developer feedback is warm and incremental.

## 結論

両者は連携します。計装とエクスポートには OpenTelemetry を使い、トレースの保存と可視化には Jaeger(または別のバックエンド)を使いましょう。OTel で標準化し、堅実なオープンソースのトレーシングバックエンドの一つとして Jaeger を選びます。

## FAQ

### OpenTelemetry vs Jaeger: Standard vs Tracing Backend?

OpenTelemetry (OTel) is the CNCF standard - SDKs, APIs, and a collector - for instrumenting apps and exporting traces, metrics, and logs to any backend. Jaeger is a distributed tracing backend with storage and a query UI. They are complementary: OTel produces the data, Jaeger (among others) stores and displays it.

### In practice?

These are not really either/or: instrument your apps with OpenTelemetry, then send traces to a backend - which can be Jaeger. OTel future-proofs you against vendor lock-in; Jaeger gives you a mature open-source place to store and explore traces.

### Note?

You can trace CI and build steps with OTel too. The builds run on CI runners; faster managed runners shorten them.

### Which should I choose?

They work together: use OpenTelemetry to instrument and export, and Jaeger (or another backend) to store and visualize traces. Standardize on OTel; pick Jaeger as one solid open-source tracing backend.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt