OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説

OpenTelemetry（オープンテレメトリ、略称OTel）とは、トレース・メトリクス・ログといった「テレメトリデータ」を、特定の監視ツールに縛られず統一的に収集・送信するためのオープンソースの標準です。CNCF（Cloud Native Computing Foundation）が支える、ベンダー非依存の可観測性（Observability）基盤として、クラウドネイティブ開発で事実上の標準になっています。この記事では、OpenTelemetryの全体像、3つのシグナル、OTLP、SDK・自動計装、Collectorの役割と設定例、Kubernetesでの導入、Prometheusとの違い、導入メリットと運用の注意点までを2026年時点の最新情報で整理します。

まとめ：OpenTelemetryの要点

• OpenTelemetry（OTel）とは：トレース・メトリクス・ログを統一的に扱う、CNCF傘下のベンダー非依存な可観測性の標準・OSS。読みは「オープンテレメトリ」。
• 3つのシグナル：分散トレース／メトリクス／ログが仕様上は安定版（ログは言語により実装の成熟度に差あり）。プロファイル（continuous profiling）は開発中。これらが「テレメトリデータ」。
• OTLP：OpenTelemetry Protocol。テレメトリを運ぶ標準プロトコルで、gRPC/HTTPに対応。これによりツール間でデータ形式が統一される。
• 計装とCollector：アプリ側はSDK＋自動計装（auto-instrumentation）でデータを生成。OpenTelemetry Collectorが受信(receiver)→処理(processor)→送信(exporter)を担い、送信先（Prometheus/Jaeger/各種SaaS）を自由に差し替えられる。
• Prometheusとの違い：Prometheusは主にメトリクスのプル型監視、OTelは3シグナルを横断する計装・転送の標準。競合ではなく組み合わせて使うのが一般的。

OpenTelemetryとは何か（全体像となぜ必要か）

OpenTelemetryは、2019年にOpenTracingとOpenCensusが統合して生まれた、可観測性のためのオープンソースプロジェクトです。目的は、アプリケーションが生成するテレメトリデータ（トレース・メトリクス・ログ）を統一された方法で計装・収集・送信し、特定ベンダーへのロックインを避けることにあります。従来は監視SaaSごとに独自エージェントや独自フォーマットが必要でしたが、OTelに揃えれば、計装は一度きりで、送信先だけを後から差し替えられます。

CNCFが支えるベンダー非依存の標準であり、API・SDK・プロトコル（OTLP）が公開仕様として整備されています。マイクロサービスやKubernetesのような分散システムでは、どのサービスで何が起きているかを横断的に把握する必要があり、OTelはその共通言語として広く採用されています。

テレメトリデータの3つのシグナル（トレース・メトリクス・ログ）

「テレメトリデータとは」、システムの状態や挙動を外部から観測するために出力されるデータの総称です。OpenTelemetryは次の3シグナルを扱い、仕様上はいずれも安定版です（トレース・メトリクスは広く安定、ログは言語により実装の成熟度に差があります。プロファイルは開発中で2026年時点はアルファ段階）。

OTelの強みは、これら3つを相関（correlation）させられる点です。たとえばトレースから関連ログへ、メトリクスの異常から該当トレースへとたどることで、分散システムの障害調査が大幅に速くなります。

OTLPとは（OpenTelemetry Protocol）

OTLP（OpenTelemetry Protocol）は、テレメトリデータを送受信するためのOpenTelemetry標準プロトコルです。トレース・メトリクス・ログを共通のスキーマで運べるため、計装側・収集側・バックエンド側がベンダーをまたいで相互運用できます。通信方式はgRPC（既定ポート4317）とHTTP（既定ポート4318）の2種類があり、リアルタイム性や既存インフラとの相性で選びます。gzip等の圧縮にも対応し、大量データの転送効率を高められます。

計装（Instrumentation）とSDK・自動計装

テレメトリを生み出す工程を「計装（instrumentation）」と呼びます。OpenTelemetryはJava・Go・Python・JavaScript/Node.js・.NET・Rubyなど主要言語向けにAPIとSDKを提供しており、トレースとメトリクスのAPIは安定版です。計装には2通りあります。

• 自動計装（auto-instrumentation）：エージェントやライブラリを追加するだけで、HTTP・DB・gRPCなど主要ライブラリのトレース／メトリクスを自動取得。コード変更を最小化できる。
• 手動計装：SDKを使ってビジネスロジック固有のスパンや属性を追加し、欲しい粒度で計測する。

既存のログライブラリと併用すれば、ログにトレースコンテキスト（trace_id等）を自動付与でき、ログとトレースの相関も取れます。

OpenTelemetry Collectorとは（受信・処理・送信）

OpenTelemetry Collectorは、テレメトリデータを受信（receiver）→処理（processor）→送信（exporter）する中継コンポーネントです。アプリから直接バックエンドへ送ることもできますが、Collectorを挟むと、送信先の変更・フィルタリング・バッチ化・再試行などを一元管理でき、アプリ側の設定を最小化できます。エージェント（各ノード）としてもゲートウェイ（集約）としても配置でき、200以上のコンポーネントが提供されています。主要要素は次の4つです。

• レシーバー（receiver）：OTLPやPrometheusなどでデータを受け取る入口。
• プロセッサ（processor）：バッチ化・フィルタ・属性付与・サンプリングなどの加工。
• エクスポーター（exporter）：Prometheus・Jaeger・各種SaaSなど送信先へ出力。
• エクステンション（extension）：ヘルスチェックや認証など補助機能。

設定はYAMLで記述します。OTLPで受け、バッチ処理して別のバックエンドへ送る最小構成は次のとおりです。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:
exporters:
  otlphttp:
    endpoint: https://your-backend.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

送信先を変えたいときは exporters と service.pipelines を書き換えるだけで済み、アプリ側の計装はそのまま使えます。これがベンダーロックイン回避の実装上の核心です。

KubernetesでのOpenTelemetry Collector導入

Kubernetes環境では、HelmチャートやOpenTelemetry OperatorでCollectorを導入するのが一般的です。Helmなら helm repo add でリポジトリを追加し、helm install でデプロイします。配置形態は、各ノードでデータを集めるDaemonSet（エージェント）と、集約してバックエンドへ送るDeployment（ゲートウェイ）を組み合わせるのが定番です。CollectorにはCPU/メモリのrequests/limitsを設定し、データ量の増減にはオートスケールで対応します。Operatorを使うと、アプリPodへの自動計装（サイドカー注入）も宣言的に管理できます。

OpenTelemetryとPrometheus・各ツールの違いと連携

「OpenTelemetryとPrometheusの比較」はよくある疑問ですが、両者は守備範囲が異なります。Prometheusはメトリクスのプル型収集とPromQLによる分析に特化した監視システムで、OpenTelemetryはトレース・メトリクス・ログを横断して計装・転送を標準化する枠組みです。実務では「OTelで計装し、メトリクスはPrometheusへ、トレースはJaegerやSaaSへ、ログはGrafana Lokiへ」のように、OTelを共通の入口にして各専用ツールへ振り分ける構成が一般的です。可視化はGrafanaで3シグナルをまとめて扱えます。

OpenTelemetry導入のメリットと運用の注意点（活用のポイント）

導入メリットは、第一にベンダーロックインの回避です。計装をOTelに統一すれば、監視SaaSの乗り換えや併用が設定変更だけで済みます。第二に、3シグナルの相関による障害調査の高速化。第三に、クラウド／オンプレ／マルチクラウドをまたいだ統一監視です。

一方、運用では次の点に注意します。テレメトリは放置するとデータ量とコストが急増するため、サンプリング（トレースの間引き）やプロセッサでのフィルタ・バッチ化でボリュームを制御します。属性に機微情報を載せないなどのセキュリティ配慮、OTLP通信のTLS化や認証も重要です。まずは1サービスで自動計装から小さく始め、Collector経由で送信先を一本化し、対象を広げていくのが失敗の少ない進め方です。ログ収集を軽量に始めたい場合はFluent Bitなどと役割分担する構成も有効です。

よくある質問（FAQ）

OpenTelemetry（OTel）とは何ですか？読み方は？

トレース・メトリクス・ログを統一的に計装・収集・送信するためのCNCF傘下のオープンソース標準です。「オープンテレメトリ」と読み、OTel（オーテル）と略されます。

テレメトリ（テレメトリデータ）とは？

システムの状態や挙動を観測するために出力されるデータの総称で、OpenTelemetryではトレース・メトリクス・ログの3シグナルを指します。

OTLPとは何ですか？

OpenTelemetry Protocolの略で、テレメトリを運ぶ標準プロトコルです。gRPC（4317）とHTTP（4318）に対応し、ツール間のデータ形式を統一します。

OpenTelemetryとPrometheusはどちらを使う？

競合ではありません。OTelで計装し、メトリクスはPrometheusへエクスポートするなど、組み合わせて使うのが一般的です。

Collectorは必ず必要ですか？対応言語は？

アプリから直接バックエンドへ送ることも可能ですが、送信先の一元管理・フィルタ・バッチ化のためCollectorを挟むのが推奨です。SDKはJava・Go・Python・JavaScript・.NET・Rubyなど主要言語に対応しています。

関連記事

• Prometheusの誕生とCloud Native Computing Foundationとの関係
• Grafana Lokiとは何か：Prometheus由来の設計でコスト効率に優れたログ基盤を徹底解説
• Grafana v12の最新リリース情報と注目すべき主要機能まとめ
• Fluent Bitとは？仕組み・Fluentd比較・AWSログ運用を実務解説【2026年v5対応】