Jaegerのシステム開発を依頼するなら、Jaeger本体を動かせるだけでなく、OpenTelemetryによる計装、ストレージ設計、セキュリティ、運用まで一体で提案できる会社を選ぶことが重要です。
Jaegerはマイクロサービスや分散システムのリクエストを追跡するオープンソースの基盤です。この記事では、株式会社riplaを最初に、Grafana Labs、Elastic、Amazon Web Services（AWS）、Red Hat、日本電気（NEC）の計6社を紹介し、向いている企業や発注前の確認事項、費用の考え方まで解説します。
▼全体ガイドの記事
・Jaegerのシステム開発の完全ガイド
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のシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。