Jaegerは、マイクロサービスや分散システムのリクエストを追跡するオープンソースの基盤です。開発会社を選ぶときは、Jaeger本体を動かせるかだけでなく、計装からセキュリティ、運用まで一体で提案できるかを比べることが大切です。
取り上げるのは、まず株式会社riplaを挙げ、Grafana Labs、Elastic、Amazon Web Services(AWS)、Red Hat、日本電気(NEC)の計6社です。
- OpenTelemetryによる計装
- ストレージ設計とセキュリティ
- 運用・費用・発注前の確認
▼全体ガイドの記事
・Jaegerのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Jaegerのシステム開発でパートナー選びが重要な理由

Jaegerは無償で使えるOSSですが、導入しただけで障害の原因が自動的に分かるわけではありません。
各サービスにトレースを付け、コンテキストを正しく伝播させ、保存先やサンプリングを設計して、現場が画面を見て判断できる状態まで整えて初めて、業務システムの改善につながります。
適切なパートナー選定が成否を分ける理由
注文、決済、在庫、配送などが別々のサービスで動くシステムでは、1件のリクエストが複数のAPIやデータベースを通過します。そのため、ログだけを個別に確認すると、エラーが発生したサービスと、遅延を生み出した根本原因を切り分けにくくなります。
Jaegerでは1件の処理をtrace、その中の各処理単位をspanとして表示できるため、どのサービスで時間を使ったか、どこで失敗したかを追いやすくなります。一方で、計装範囲が不十分だったり、サービス間でtrace IDの引き継ぎが切れていたりすると、画面に表示されるトレースは不完全です。
発注先には、Jaegerの起動経験だけでなく、アプリケーション改修、OpenTelemetry Collector、Kubernetes、OpenSearchなどを含む設計力が求められます。さらに、障害対応時間やp95レイテンシーを導入前後で測るKPI設計も、パートナーが担う役割の一つです。
発注前に確認すべきポイント
まず発注側で、対象サービス数、主要な業務フロー、1日のおおよそのリクエスト数、必要な保持期間、障害時に許容できる復旧時間を整理しておきます。開発環境であればall-in-oneとメモリ保存で検証できますが、再起動するとデータが失われます。そのため、本番では永続ストレージとバックアップを設計する必要があります。
span属性に顧客ID、メールアドレス、注文番号、Authorizationヘッダー、リクエスト本文を入れないルールを、開発会社と決めておきます。そのうえで、Collectorのattributes processorやfilter processorで削除・置換するだけでなく、アプリ側の計装規約をallowlist方式で決めます。
セキュリティ面では、TLS、SSO、RBAC、監査ログ、保存期間まで要件に含めます。あわせて、提案書で責任分界と納品物が明確かを確かめます。
株式会社ripla|コンサルから開発まで一気通貫で支援

riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。
営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があり、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
特徴と強み
Jaegerの導入では、ツールの設定より先に「どの業務の遅延を見つけたいか」「障害発生時に誰がどの画面を見るか」を決めることが大切です。riplaは業務要件の整理から関わり、対象となる注文・決済・在庫などの業務フローを洗い出したうえで、必要なサービスと計装範囲を定義する進め方に向いています。
Jaegerの納品後も、OpenTelemetryを使った標準化、ログやメトリクスとの相関、運用担当者への引き継ぎまで含めて相談できます。また、OSSの採用可否、既存のクラウドや監視基盤との接続、個人情報を除外する属性設計など、企業ごとに異なる非機能要件をすり合わせやすい点が特徴です。
得意領域・相談時に確認したいこと
業務システムの改善効果を重視し、Jaegerを導入すること自体ではなく、MTTR短縮や問い合わせ調査時間の削減を成果にしたい企業に適しています。既存システムがモノリスから複数サービスへ移行中の場合は、最初から全体を作り替えず、障害の多い業務APIからPoCを始める計画を立てやすくなります。
相談時は、どの言語・フレームワークを計装できるか、Collectorやストレージの運用をどこまで担当するか、IaCや設定ファイルを引き渡すかを確認します。
Jaeger専用の導入実績は、根拠を示してもらったうえで、自社の構成に近い業務システムの事例で確かめます。要件定義から運用定着までの役割分担も見ておくと安心です。
Grafana Labs|TempoやGrafana Cloudを含めた可観測性基盤

Grafana Labsは、Grafanaを中心にメトリクス、ログ、トレースを可視化する製品群を提供する企業です。
分散トレーシングでは、TempoやGrafana Cloud Application Observabilityが候補になります。Jaegerから別のバックエンドへ移行する場合も、OpenTelemetryを共通の計装層として設計しやすい企業です。
特徴と強み
JaegerのUIだけでなく、ダッシュボードやアラートまで同じ運用画面に集約したい企業に向いています。たとえば、Tempoはトレースの保存・検索を担い、Grafanaでサービスマップやレイテンシーをメトリクスと関連付ける構成を検討できます。
セルフホストとマネージドサービスを比較しながら、運用負荷とデータ所在のバランスを取りやすい点も強みです。なお、Grafana Cloud Application Observabilityでは、2026年2月13日以降の新規顧客向けに、ホスト時間とテレメトリ量を組み合わせた料金体系が案内されています。
ホスト時間は1時間あたり0.025米ドル、トレース・ログ・プロファイルは1GBあたり0.50米ドルなど、保持量とホスト数で費用が変わります(出典:Grafana公式Application Observability料金、2026年)。この料金はJaegerのセルフホスト費用とは異なりますが、サンプリング設計の重要性を見積もる比較材料になります。
得意領域・発注前の確認事項
複数クラウドやKubernetesを使い、ログ・メトリクス・トレースを横断して見る必要がある企業に適しています。導入時は、TempoやGrafana Cloudを採用するのか、既存のJaegerを残すのか、データの保持期間とリージョンをどうするのかを確かめます。
運用を外部に任せる場合は、ダッシュボード作成、アラートチューニング、障害時の一次対応まで契約範囲に含むかを明確にします。
Elastic|ログ・メトリクス・APMを統合した分析基盤

Elasticは、ElasticsearchやKibanaを中核に検索・分析機能を提供する企業です。
Elastic APMではOpenTelemetryのデータを受け入れ、ログ・メトリクス・トレースを一つの分析基盤で扱う方向性を示しています。既存のJaeger環境から、より広いAPMやログ分析へ段階的に移りたい場合の比較候補です。
特徴と強み
障害発生時に、トレースから関連するログを探し、エラーの傾向やサービスの性能をまとめて分析したい企業に向いています。検索基盤に慣れたチームであれば、既存の運用知識を活用しやすくなります。
Elasticsearchをストレージとして利用する場合は、検索性能、インデックスのライフサイクル、シャード設計、保持期間を業務量に合わせて決めることが重要です。また、OpenTelemetryはベンダー中立の計装とデータ形式を目指すため、アプリ側の計装を標準に寄せておけば、将来Jaeger、Elastic、Tempoなどのバックエンドを比較できます。
移行時は、trace IDの形式、属性名、サンプリング、保存期間、既存ダッシュボードの作り直しが必要かを確かめます。単なる製品置き換えとして扱わないことが大切です。
得意領域・発注前の確認事項
ログ基盤がすでにElasticで、トレースも同じ場所で相関分析したい企業に適しています。
見積もりでは、APMのライセンスやクラウド利用料だけでなく、データ取り込み量、ストレージ、バックアップを分けて確認します。検索用の計算資源や運用監視も、別々に確認します。
個人情報を含むログとspanが同じ権限で見えないよう、ロールやマスキングの設計も発注条件に含めます。
Amazon Web Services(AWS)|AWS上のコンテナ・OpenSearchと組み合わせる構成

Amazon Web Services(AWS)は、コンピューティングやコンテナ、データベースのクラウドサービスを提供しています。監視やセキュリティ関連のサービスも含みます。
AWS Distro for OpenTelemetryやAmazon OpenSearch Serviceを組み合わせると、EKSなどのコンテナ環境で収集したトレースを扱えます。これにより、AWSの権限管理やネットワーク設計の中に組み込みやすくなります。
特徴と強み
AWSを標準クラウドとして採用している企業では、IAM、VPC、EKS、CloudWatch、OpenSearchなどを含めて、既存のセキュリティ・運用ルールに沿った設計を進めやすい点が強みです。Jaegerの収集基盤を別管理にせず、アプリケーション、コンテナ、ストレージ、監査の責任分界を一つの構成図で確認できます。
Jaeger公式は、本番の永続ストレージとしてCassandra、Elasticsearch、OpenSearchなどを挙げ、大規模構成ではOpenSearchを推奨しています(出典:Jaeger公式Storage Backends、2026年)。また、ピーク時のデータ損失を抑える場合は、Collectorとストレージの間にKafkaを置く構成も候補になります。
AWSでは、これらのマネージドサービスと自社運用の境界を決めることが、費用と品質を左右します。
得意領域・発注前の確認事項
EKSや複数アカウントを使い、クラウド上の業務システムを統合監視したい企業に適しています。提案依頼では、トレースをどのアカウント・リージョンに保存するのか、IAMロールをどう分けるのか、障害時にAWSと開発会社のどちらが対応するのかを確かめます。
毎月のAWS利用料は、ホスト数、スパン量、保存期間、OpenSearchのノード構成、バックアップで変わるため、前提値を見積書に記載してもらいます。
Red Hat|OpenShift上の分散トレーシングと企業サポート

Red Hatは、Linux、OpenShift、コンテナ基盤などを企業向けに提供するソフトウェア企業です。Red Hatの公式ドキュメントでは、OpenShift Distributed TracingのプラットフォームがJaegerを基盤とし、データ収集がOpenTelemetryを基盤とする構成が説明されています。
OpenShiftを採用している企業にとっては、Jaegerを個別のサーバーとして扱わず、クラスター運用の一部として設計できる候補になります。
特徴と強み
OpenShiftのOperator、テナント、証明書、権限、監視を含めて、コンテナ基盤の標準に合わせた導入を検討しやすい点が強みです。また、OpenTelemetry CollectorからREDメトリクスを作り、リクエスト数・エラー率・処理時間を可視化する構成も選択肢になります。
アプリ開発チームとプラットフォームチームの責任分界を整理したい企業に向いています。ただし、OpenShiftのバージョンや提供コンポーネントによって、JaegerやOpenTelemetryの対応範囲が変わる可能性があります。
契約前には、現在の製品バージョンで本番サポートされる機能か、どのストレージを使えるか、アップグレード時にトレースを止めない方法があるかを確認する必要があります。
得意領域・発注前の確認事項
OpenShift上で複数の業務サービスを運用し、コンテナ基盤のサポートと運用標準化を重視する企業に適しています。
見積もりでは、Operatorの導入やCollector設定、アプリ計装を分けてもらいます。ストレージや証明書、SSO、運用手順、教育も、それぞれ別の項目として示してもらいます。
障害発生時のエスカレーション先と、Red Hatのサポート範囲、開発会社の対応時間を別々に整理することが大切です。
日本電気(NEC)|WebOTXとJava業務システムの連携

日本電気(NEC)は、企業向けのIT基盤や業務システムを提供する国内企業です。NECのWebOTX公式ドキュメントには、MicroProfile OpenTracingのトレーサー実装としてJaegerを利用する構成が掲載されています。あわせて、Jaegerのclient、agent、collector、query、ストレージの役割も説明されています。
Javaを中心とした既存業務システムで、アプリケーションサーバーとの関係を含めて検討したい場合の候補です。
特徴と強み
WebOTXでは、ソースコードに大きく手を入れずにJAX-RSやMicroProfile Rest Clientのリクエストを追跡する方法が案内されています。既存のJava資産が多く、基幹業務の可視化を段階的に進めたい企業では、現在のアプリケーションサーバー、JDK、ネットワーク、運用手順を踏まえた提案を受けやすくなります。
一方で、公開ドキュメントにはOpenTracingや古いJaeger clientを前提とする内容も含まれます。そのため、新規開発や長期運用を見据える場合は、OpenTelemetry API・SDK・OTLPへどのように移行するのか、既存の計装をどの期間維持するのかを確かめます。
公式情報に記載された連携方式が、自社の現行バージョンに適用できるかも、提案段階で確かめる必要があります。
得意領域・発注前の確認事項
Java、WebOTX、オンプレミスやハイブリッド環境の業務システムを運用している企業に向いています。相談時は、WebOTXのバージョンとアプリの言語・フレームワークを共有します。既存のログ基盤や、利用可能なネットワーク経路も伝えます。
開発会社には、Jaeger v2とOpenTelemetryへの移行計画、障害時のサポート体制、既存業務への影響を含む工程表を提示してもらいます。
Jaegerのシステム開発パートナーを選ぶポイント

6社は、同じ条件で単純にランキングするものではありません。
自社の環境(クラウド、コンテナ、言語、既存監視、データ保持方針)に合うかを確かめます。そのうえで、Jaegerの構築だけでなく、導入後に現場が使い続けられるかで比較します。
実績と経験の確認方法
「Jaegerに対応できます」という説明を聞いたら、traceをどの業務フローに付けたか、サービス数やピーク時のスパン量はどの程度か、障害対応でどのKPIを改善したかを確認します。顧客名を開示できない場合でも、構成図を匿名化したサンプル、PoCの成果物、障害シナリオのテスト計画を見せてもらうと、実装経験を比較しやすくなります。
また、提案書には、要件定義や計装、Collector構築の担当者を記載してもらいます。ストレージ、テスト、移行、運用についても、担当者をそれぞれ明記してもらいます。「開発一式」という表記だけでは、どこまで含まれるか分かりません。
特に、アプリ改修の対象サービス数や属性のマスキングは、別項目に分けることが大切です。性能試験、バックアップ復元試験、運用教育も、それぞれ別項目にします。
技術力と専門性の評価
新規アプリでは、Jaeger固有のclientを追加する前に、OpenTelemetry API・SDK・自動計装を使い、OTLPで送る方式を基本に比較します。Jaeger公式のv2は、OpenTelemetry Collectorを基盤に、collector、query、ingester、all-in-oneなどの役割を構成できます。
さらに、OpenTelemetry Collectorを前段に置いて、属性処理やサンプリングを行うこともできます(出典:Jaeger公式Architecture、2026年)。この構成を自社のトラフィック量と運用体制に合わせて説明できる会社を選びます。
確認したい質問の例は、「all-in-oneを本番で使わない理由を説明できますか」「OpenSearchとElasticsearchをどう比較しますか」「Kafkaを置く判断基準は何ですか」です。加えて、「どの属性を削除・マスキングしますか」「サンプリング率をどう変更しますか」も聞いておきます。答えが製品名だけで終わらず、可用性、データ損失、検索遅延、コスト、個人情報の観点で説明されるかを見ます。
プロジェクト管理体制と費用の確認
Jaeger本体のライセンス費用は原則無料でも、計装工数やCollector、ストレージの費用が発生します。さらに、クラウド、監視、バックアップ、24時間対応にも費用がかかります。
本記事の目安では、1〜2サービスのPoCは50万〜150万円、5〜20サービスの小規模本番は300万〜800万円、Kubernetesや高可用性を含む中規模構成は800万〜2,000万円程度です。これらはスパン量、保持期間、環境数、既存アプリの改修量で変わる推定値であり、確定価格ではありません。
期間の目安は、PoCで1〜2か月、小規模本番で2〜4か月、中規模で3〜6か月です。要件定義、設計、計装のあとには、本番に出すまでの作業が続くため、期間の見積もりに含めておく必要があります。
- 性能・障害テスト
- リリース
- 教育
各工程には完了条件を決めておきます。保守費用は初期費用の年15〜25%程度を目安にする考え方もありますが、監視時間、SLA、改修回数、クラウド費用を分けて見積もる必要があります。
よくある質問(FAQ)

Jaegerのシステム開発を検討すると、OSSの費用、本番構成、既存のJaeger client、個人情報の扱いについて疑問が出やすくなります。発注前に特に確認されやすい質問に、順に答えます。
Jaegerは無料なので、開発会社への費用も安くなりますか?
Jaeger本体はOSSのためライセンス費用を抑えやすいですが、計装や設計、ストレージの費用がかかります。クラウドや監視、保守の費用も別に発生します。
特に全件保存や長期保持はデータ量を増やすため、対象業務を絞ったPoCとサンプリングで費用対効果を確認することが現実的です。
既存のJaeger clientはすぐにOpenTelemetryへ移行すべきですか?
すぐに全サービスを置き換える必要はありませんが、新規開発ではOpenTelemetryを標準にすることが基本です。既存サービスはOpenTelemetryのshimやCollectorを使い、trace IDの連携、属性、サンプリングを確認しながら、業務影響の小さいサービスから段階的に移行する方法が適しています。
Jaegerに個人情報が保存されるリスクはありますか?
計装の設計によっては、URLのクエリ、メールアドレス、顧客ID、認証情報などがspan属性に入るリスクがあります。記録してよい属性はallowlistで決め、Collectorで削除・置換します。
次に、TLS、SSO、RBAC、暗号化の設計を進めます。保存期間、委託先管理、監査ログも含めて、セキュリティ部門のレビューを受けます。
まとめ

Jaegerのシステム開発会社を選ぶ際は、Jaegerを起動できるかだけでなく、OpenTelemetryによる計装、Collector、OpenSearchなどの永続ストレージ、サンプリングまで任せられるかを比べます。個人情報保護や障害時の運用も、あわせて見ます。
株式会社riplaは業務要件の整理から開発・定着までを一気通貫で相談したい企業に向いています。比べる観点は、Grafana Labsなら可観測性の統合、Elasticならログ・APMの分析、AWSならクラウド標準化、Red HatならOpenShift、NECならJavaやWebOTXとの連携です。
6社を比較するときの要点
候補会社には、対象サービス数や主要業務、ピーク時のリクエスト量を伝えます。保持期間や必要な可用性、既存のクラウドと監視基盤も、あわせて伝えます。
そのうえで、PoC、本番設計、計装、テスト、移行、保守を分けた見積もりを依頼し、成果物と責任分界を比較します。Jaeger専用の実績は根拠なく断定せず、自社構成に近い技術領域を公開情報や提案内容で確認することが重要です。
最初の1業務でのPoC
全社のサービスをいきなり対象にするのではなく、障害の多い注文APIや決済フローを1つ選びます。そのうえで、導入前後の原因特定時間、MTTR、p95レイテンシー、スパン量を測ります。
PoCで得たデータをもとに、サンプリング率、保持期間、ストレージ容量、運用担当を決めれば、本番の見積もりと社内説明が具体的になります。自社に合うパートナーと段階的に進めることで、Jaegerを業務改善に結び付けやすくなります。
▼全体ガイドの記事
・Jaegerのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
