Jaegerとは？v2でOpenTelemetryを取り込んだ分散トレーシングの仕組みとX-Rayとの選び分けを解説【2026年版】

Jaegerは、マイクロサービスをまたいで流れる1リクエストの経路を、サービス単位のスパンとして記録・可視化するOSSの分散トレーシング基盤です。Uberが開発してCNCF（Cloud Native Computing Foundation）へ寄贈し、卒業（graduated）まで到達した数少ないプロジェクトで、2024年11月に公開されたv2ではコアにOpenTelemetry Collectorを取り込み、内部構造が大きく変わりました。この記事では、トレースとスパンの基本モデル、v2のパイプライン型アーキテクチャ、OTLPでの収集経路とストレージの選び方、サンプリングの考え方、そして「OpenTelemetryとどう役割分担するか」「AWS X-Rayとどちらを選ぶか」「どこからは自前運用が過剰か」の判断基準までを、実装者の視点で整理します。トレーシングを含む観測全体の考え方はオブザーバビリティとは何かで扱っているため、本稿はその一要素であるトレース基盤のJaegerに絞って掘り下げます。

まとめ：Jaegerはv2でOpenTelemetryを核に据えたトレース保存・可視化基盤

Jaegerの立ち位置は1行で示せます。各サービスが送るトレースを受け取り、保存し、経路とレイテンシを可視化する「トレースのバックエンド」です。計装（アプリからトレースを出す部分）そのものはOpenTelemetryが標準を握り、Jaegerはその受け皿として保存とUIを担う、という役割分担で理解すると迷いません。

v2でこの分担がはっきりしました。旧v1はagent・collector・query・ingesterといった独自コンポーネント群で組まれていましたが、v2はOpenTelemetry Collectorを土台にし、receiver・processor・exporterのパイプラインに、トレース検索とUIを担うjaeger_query拡張を足した構成へ置き換わっています。受信の主経路はOTLPになり、Jaeger独自プロトコルへの依存が薄れました。v1は2025年12月31日にEOLを迎えて更新が止まっているため、新規に選ぶならv2が前提です。

判断の軸は、要件が「自前で保存基盤まで持ってトレースを掌握したいか」「マネージドに預けて運用から降りたいか」です。Kubernetes上のマイクロサービスで、ベンダーに縛られずトレースを蓄積・分析したいならJaegerが有力候補になります。一方でAWSに寄せた構成で運用の手離れを優先するなら、マネージドのAWS X-Rayに分があります。加えてv2ではCassandraやElasticsearchといったストレージの選定と運用が実質の作業量になる点は、導入前に見積もっておくべき判断材料です。以下、定義・仕組み・選び分け・採用判断の順に具体化します。

Jaegerの定義とv2でOTel Collectorをコアに据えた構造

まず「何であって、何でないか」を切り分けます。Jaegerはアプリのコードへ計測を書き込むためのライブラリではなく、送られてきたトレースを受け取って保存し、検索・可視化する基盤ソフトウェアです。動作の前提はコンテナ基盤であることが多く、Kubernetesとは（コンテナオーケストレーション）で解説した基盤の上へ載せて運用します。

Jaegerの定義：Uber由来でCNCFを卒業したOSSの分散トレーシング

Jaegerは、分散システム内を流れる1つのリクエストが、どのサービスを何ミリ秒かけて通過したかを追跡するためのOSSです。Uberが2015年前後に開発し、CNCFへ寄贈したのち卒業したプロジェクトで、系譜としてはGoogleの論文「Dapper」とオープンソースのZipkinを踏まえています。追跡の単位は、リクエスト全体を表すトレースと、その中の個々の処理を表すスパンです。各サービスはスパンにトレースIDを付けて送り、Jaegerがそれらを1本のトレースへ組み立て直します。この「経路と所要時間を後から追える」ことが、単一の障害点を持たないマイクロサービスでボトルネックを見つける手掛かりになります。

トレース・スパン・コンテキスト伝播というトレーシングの基本モデル

Jaegerを理解する鍵は3つの語です。トレースは1リクエストの全経路、スパンはその中の1区間（例：APIゲートウェイの受付、認証サービスの照合、DBクエリ）、コンテキスト伝播はサービス境界を越えてトレースIDを引き継ぐ仕組みを指します。あるサービスが次のサービスを呼ぶ際、HTTPヘッダなどにトレースIDと親スパンIDを載せて渡すことで、受け側は自分のスパンを同じトレースへ紐づけられます。この伝播が途切れると経路が分断されて見えるため、計装の設計ではヘッダの受け渡しを全サービスで揃えることが要点です。

v2の構造：OTel Collectorのパイプラインとjaeger_query拡張

v2で内部が入れ替わりました。土台がOpenTelemetry Collectorになり、テレメトリを受けるreceiver、間引き・整形するprocessor、ストレージへ書き出すexporterという3段のパイプラインで構成されます。Collectorはデータ取り込みが本分で、トレースの検索やUI表示はその範囲外のため、Jaegerはこれをjaeger_queryという拡張（extension）として実装しています。v1が担っていた収集・保存・照会を、標準のCollectorに拡張を足す形へ整理し直したのがv2の骨子です。これにより、Collectorのエコシステム（KafkaやRedis経由の入力、多様なexporter）をそのまま流用しやすくなりました。

v1のEOLとv2構成への移行という版アップグレードの現在地

版の状況には注意が要ります。旧v1は2025年12月31日にEOL（サポート終了）を迎え、以降のセキュリティ更新やバグ修正が止まっています。新規導入はv2が前提で、2026年7月時点ではv2系として2.20系が公開帯にあります（版番号は時点付きの参考値です）。v1で稼働中の環境は、独自コンポーネント構成からCollectorベースのv2構成へ設定を書き換える移行作業が発生します。受信プロトコルやストレージ設定の指定方法が変わるため、移行はバージョンアップというより構成の作り替えに近い規模で見積もるのが安全でしょう。

Jaegerが担うトレース収集・保存・可視化とサンプリングの仕組み

Jaegerの仕事は大きく3工程です。トレースを受け取り、どこかへ保存し、UIで見せる。この各段でどんな選択肢があるかを押さえると、運用の作業量が具体的に見えてきます。

OTLP受信を主経路とした各サービスからのトレース収集フロー

v2の受信はOTLP（OpenTelemetry Protocol）のgRPC/HTTPが主経路です。アプリ側はOpenTelemetryのSDKやCollectorでトレースを生成し、それをJaegerのreceiverへ送ります。互換のため、旧来のJaeger独自フォーマットやZipkinフォーマットの受信も設定で残せますが、新規設計ではOTLPへ寄せるのが素直でしょう。受信後はprocessorでバッチ化やサンプリング後の整形を行い、exporterがストレージへ書き出します。この経路をアプリのコードへ埋め込む計装ライブラリと切り離せる点が、多言語混在の基盤で効いてきます。Jaeger自身の旧クライアントSDKは2022年前後に非推奨化され、計装はOpenTelemetry SDKへ移譲済みです。

productionを見据えたストレージ選定とデータ保持設計の勘所

Jaegerは自前でトレースを溜め込むデータベースを持たず、外部のストレージへ書き出します。選択肢は、検証やデモ向けのメモリ・ローカルのBadger、production向けのCassandra、全文検索とダッシュボード連携に向くElasticsearch、そしてgRPC APIで独自バックエンドをつなぐリモートストレージです。ここが運用設計の中心になります。トレースは量が多く、保持期間を延ばすほどストレージ費用と検索負荷が膨らむため、保持日数とサンプリング率をセットで決める必要があります。

表の通り、検証はメモリで足りますが、productionではCassandraかElasticsearchのクラスタ運用が実質の作業量になります。ここを自前で背負えるかが、後述の外部委託ラインの分かれ目です。

サンプリング戦略：ストレージ費用を抑えるヘッドベースの間引き

全リクエストのトレースを保存すると、ストレージも検索も破綻します。Jaegerはヘッドベースのサンプリング（トレース開始時点で残すか捨てるかを決める方式）を基本とし、固定割合の確率的サンプリング、単位時間あたりの上限を切るレート制限、サービスごとに割合を配るリモート適応サンプリングを選べます。実務ではまず低い確率（例：数%）で始め、トラフィックとストレージ費用を見ながら調整するのが定石でしょう。エラー時だけ全量残したいといった要件は、テールベース（結果を見てから残す方式）をCollector側のprocessorで補う設計になります。間引き方針は「後から増やすより減らす方が痛い」ため、保持コストとのバランスで先に決めておきます。

UIでのトレースのタイムライン可視化とサービス依存グラフの読み方

Jaegerのフロントエンドは、1トレースを時系列のスパンとして横棒で並べるタイムライン表示が中心です。どのスパンが長いか、どこで待ちが発生したかを目視で追え、ボトルネックの当たりを付けられます。加えて、収集したトレースからサービス間の呼び出し関係を集計する依存グラフ（サービスマップ）を描け、システム全体の通信構造を俯瞰できます。成功率やレイテンシといった数値をダッシュボードで継続監視したい場合は、メトリクスを扱うGrafana v12の最新リリースと主要機能のようなツールと組み合わせ、トレースは経路の深掘り、メトリクスは全体傾向の監視、と役割を分けるのが定石です。

JaegerとOpenTelemetry・AWS X-Ray・他トレーシングの選び分け

採用を検討する段階では、計装標準のOpenTelemetryとの関係、そしてマネージドのAWS X-Rayとの比較が論点になります。

JaegerとOpenTelemetryの関係：計装標準とトレース保存先の役割分担

両者は競合ではなく分担関係です。OpenTelemetryは、トレース・メトリクス・ログを生成し送り出すための計装標準（SDK・API・Collector）にあたり、どのベンダーにも依存しない共通言語として機能します。Jaegerはその送り先の一つ、つまりトレースを保存し可視化するバックエンドです。v2でJaeger自身がOpenTelemetry Collectorをコアに取り込んだことで、この分担はより明確になりました。標準側の全体像はOpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collectorで扱っているため、本稿と読み合わせると「どこまでがOpenTelemetryで、どこからがJaegerか」の線引きがつかめます。計装はOpenTelemetryで統一し、保存先としてJaegerを選ぶ、というのが現在の標準的な組み合わせです。

JaegerとAWS X-Rayの選び分け：OSS自前運用とマネージドの分岐

同じ分散トレーシングでも、Jaeger（自前運用のOSS）とAWS X-Ray（マネージド）は運用モデルが逆です。Jaegerはストレージまで自分で持ち、ベンダーに縛られずマルチクラウドでも動かせる代わりに、保存基盤の構築と運用を背負います。X-RayはAWSが保存・スケールを引き受ける代わりに、AWS前提の構成になり保持や料金の制御はサービスの枠内に収まります。判断の勘所は、マルチクラウドか単一クラウドか、運用工数を自前で持てるか手離れを優先するかです。X-Ray側の詳細はAWS X-Rayとは何か？基本概念と分散トレーシングで解説しているため、両者を読み比べると選定の判断がつきやすくなります。

表の通り、ベンダー中立と掌握を優先するならJaeger、運用の手離れとAWS統合を優先するならX-Ray、という重み付けで選びます。

Zipkinなど他のトレーシングと比べたJaegerの位置づけ

OSSの同系にはZipkinがあります。ZipkinはJaegerより古くから使われてきた軽量なトレース基盤で、Jaegerは互換のためZipkinフォーマットの受信も残しています。両者の機能は近く、現在はどちらを選んでもOpenTelemetryで計装してバックエンドを差し替える構図です。トレースの発生源としては、アプリの明示的な計装に加え、サービスメッシュとは？サイドカー方式の仕組みと導入判断で解説したメッシュがプロキシ層で自動的にスパンを生む経路もあります。メッシュを併用する基盤では、アプリ計装とメッシュ由来のスパンをどう突き合わせるかが設計論点になります。

Jaegerを自前運用で採用すべき場面と過剰投資として見送るべき場面

ここは他社解説が手薄な論点です。Jaegerは無償のOSSですが、保存基盤の運用という固定費が別途かかり、規模と要件が閾値を超えて初めて投資が回収されます。条件を切って言い切ります。

Jaeger採用が見合う条件：マルチクラウドで掌握したい中規模以上の基盤

次の条件が重なるなら自前のJaegerが見合います。マイクロサービスが十数個以上あり、サービス境界をまたぐ遅延やエラーの調査が日常的に発生していること。特定クラウドに縛られたくない、あるいはトレースを自社の管理下で長期に蓄積したいこと。そしてCassandraやElasticsearchのクラスタ運用を担える体制があること。この3点が揃う基盤では、マネージドの制約を避けつつ、OpenTelemetryで計装を統一しながらベンダー中立にトレースを掌握できます。導入前に、保持日数・サンプリング率・ストレージ容量の初期見積もりを必ず作っておきます。

Jaegerが過剰投資になり自前運用を見送るべき小規模構成の場面

逆に、サービスが数個でモノリスに近い構成、通信要件が単純なREST呼び出しのみ、という基盤では自前Jaegerは過剰です。トレースのボリュームが小さく、経路調査の頻度も低いなら、保存基盤のクラスタ運用という固定費が便益を上回ります。この規模なら、まずアプリのログとメトリクスで足り、トレースが要るならマネージドのX-Rayやクラウド標準の監視サービスで賄うほうが費用対効果に見合う場面です。「観測性を高めたいからJaegerを入れる」は失敗の典型で、調査対象の分散度が低いまま保存基盤だけ抱えると、運用対象が増えるだけに終わります。反対に、規制でデータを自社管理下に置く要件がある大規模基盤では、マネージドが選べずJaegerの自前運用が現実解になります。

v1移行とストレージ運用の負荷を踏まえた外部委託ラインの見極め

Jaegerの本当のコストは導入ではなく継続運用にあります。v1で動いている環境は2025年末のEOLを受けてv2構成への作り替えが要り、加えてCassandraやElasticsearchのクラスタは容量管理・バックアップ・スケールという定常運用を伴う作業です。トレースの保持設計、サンプリング率の調整、ストレージの費用の圧縮とスケール、障害時の切り分けまで含めると、Kubernetes運用に相応の余力が要ります。ここが埋まらない場合は、Jaegerを含む可観測性基盤をAWS/Google Cloud/Azure上に構築し、収集経路からストレージ運用まで設計を外部に委ねる選択が現実的です。一創のインフラ構築（AWS・Google Cloud・Azure）では、マイクロサービス基盤とトレーシングを含む観測基盤の構築・移行を支援しています。自社で担う範囲と委託する範囲を、担当者の人数とストレージ運用の余力から線引きするのが判断の勘所です。

Jaegerの導入判断と日常運用で挙がるよくある質問への回答集

Jaegerの検討時に挙がりやすい5つの疑問に、実装者の観点で簡潔に答えます。

JaegerとOpenTelemetryはどちらを使えばよいですか？

どちらか一方ではなく、組み合わせて使います。OpenTelemetryはトレースを生成・送信する計装標準で、Jaegerはそれを保存・可視化するバックエンドです。役割が異なるため競合しません。計装はOpenTelemetryのSDKで統一し、その送り先としてJaegerを選ぶ、というのが現在の標準的な構成になります。v2ではJaeger自身がOpenTelemetry Collectorをコアに取り込んでおり、この分担はより明確になりました。

Jaeger v1とv2は何が違いますか？

内部構造が入れ替わりました。v1はagent・collector・query・ingesterという独自コンポーネント群で組まれていましたが、v2はOpenTelemetry Collectorを土台にし、receiver・processor・exporterのパイプラインに検索・UI用のjaeger_query拡張を足した構成です。受信もOTLPが主経路になりました。v1は2025年12月31日にEOLを迎えているため、新規導入と既存環境の更新はいずれもv2が前提になります。

Jaegerはどのデータベースにトレースを保存しますか？

Jaeger自身はDBを内蔵せず、外部ストレージへ書き出します。検証向けのメモリやローカルのBadger、production向けのCassandra、検索・可視化連携に向くElasticsearch、gRPC APIで独自バックエンドをつなぐリモートストレージから選ぶ構成です。productionではCassandraかElasticsearchのクラスタ運用が実質の作業量になるため、保持日数とサンプリング率をセットで設計します。

JaegerとAWS X-Rayはどちらを選ぶべきですか？

運用モデルで選びます。マルチクラウドで動かしたい、トレースを自社管理下に置きたい、保存基盤を自前で運用できるならJaegerです。AWSに寄せた構成で運用の手離れを優先し、保持やスケールをサービスに任せたいならX-Rayが向きます。計装はどちらもOpenTelemetryで共通化できるため、バックエンドの差し替えは比較的容易です。運用工数を自前で持てるかどうかが最初の分岐になります。

すべてのリクエストをトレースすると問題になりますか？

全量保存はストレージ費用と検索負荷を圧迫するため、通常はサンプリングで間引きます。Jaegerはヘッドベース（開始時に残すか決める方式）の確率的・レート制限・リモート適応サンプリングを備え、実務では数%程度から始めて調整するのが定石です。エラー時だけ全量残したい場合は、結果を見てから残すテールベースをCollector側で補う設計にします。間引き方針は保持コストとセットで、導入前に決めておくのが安全です。

関連記事

• OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector：Jaegerが受け皿となる計装標準で、v2ではそのCollectorをコアに取り込んでいます。
• AWS X-Rayとは何か？基本概念と分散トレーシング：同じ分散トレーシングのマネージド版で、自前運用のJaegerと選び分ける対象になります。
• オブザーバビリティとは何か：トレースを含む観測性全体の考え方で、Jaegerはその一要素を担います。
• サービスメッシュとは？サイドカー方式の仕組みと導入判断：プロキシ層でスパンを自動生成する経路として、Jaegerのトレース発生源になります。
• Kubernetesとは（コンテナオーケストレーション）：Jaegerを載せて運用する土台となるコンテナ基盤の全体像です。