OpenTelemetryとは？仕組み・構成要素・導入手順をエンジニア向けに体系解説

OpenTelemetry（OTel）の基本 ― 3行で掴む全体像

OpenTelemetry（略称 OTel）は、アプリケーションからトレース・メトリクス・ログの3種類のテレメトリデータを収集・エクスポートするためのオープンソースフレームワークです。Cloud Native Computing Foundation（CNCF）が管理しており、Kubernetesに次ぐ第2位のコミット数・コントリビューター数を持つ大規模プロジェクトとして成長を続けています（出典: CNCF）。特定の監視ベンダーに依存しない「ベンダーニュートラル」な設計が最大の特徴で、計装（インストルメンテーション）を一度行えば、Datadog・Grafana・New Relicなど任意のバックエンドへデータを送信できます。

OTelは2019年、分散トレーシング標準のOpenTracingとGoogle発のテレメトリライブラリOpenCensusの2プロジェクトが統合されて誕生しました。両コミュニティの知見を引き継ぎつつ、メトリクスとログの領域まで対象を広げた統一仕様として再設計されています。

なぜ今OpenTelemetryが必要とされるのか

マイクロサービスアーキテクチャの普及に伴い、1つのリクエストが10以上のサービスを横断することは珍しくありません。従来のAPMツールでは、各ベンダー固有のエージェントをサービスごとにインストールする必要があり、計装コードがベンダーAPIに密結合してしまいます。その結果、ツールを乗り換える際にアプリケーション全体の計装を書き直すという大きなコストが発生します。

OpenTelemetryはこのベンダーロックイン問題を仕様レベルで解決します。API仕様とSDK実装が分離されているため、アプリケーションコードはOTel APIのみに依存し、データの送信先はCollectorの設定ファイルだけで切り替えられます。計装への投資がベンダー選択と独立して維持される点が、エンタープライズ採用を加速させている要因です。

テレメトリデータの3本柱 ― トレース・メトリクス・ログ

トレース ― サービス間のリクエスト経路を追う

分散トレースは、1つのリクエストが複数サービスを通過する経路を「スパン（Span）」の親子関係として可視化します。各スパンにはサービス名・操作名・開始/終了タイムスタンプ・ステータスコードが付与され、ボトルネックの特定やエラー箇所の追跡に用います。OTelではW3C Trace Context仕様に準拠したコンテキスト伝播によって、サービス境界を越えたトレースIDの受け渡しが標準化されています。

メトリクス ― システムの健全性を数値化する

メトリクスは、CPU使用率・リクエストレイテンシ・エラー率などの数値データを時系列で記録します。OTelのメトリクスAPIはCounter（累積値）、Gauge（瞬間値）、Histogram（分布）の3つの計器タイプを提供しています。Prometheusのpull型収集モデルとも互換性があり、既存のPrometheus基盤を活かしながらOTelへ段階的に移行することも可能です。

ログ ― イベントの詳細を記録する

ログはイベント単位の非構造化〜半構造化データです。OTelのログAPIはトレースIDとの関連付け（ログコリレーション）を標準でサポートしており、「あるエラーログがどのリクエスト経路で発生したか」を即座に追跡できます。既存のlog4j・slog・Python loggingなどのロガーにOTelブリッジを接続する方式が推奨されており、ロギングライブラリの全面置き換えは不要です。

4つ目のシグナル「バゲッジ」とコンテキスト伝播

競合サイトではあまり触れられていませんが、OTelにはトレース・メトリクス・ログに加えてBaggageという仕組みがあります。Baggageはリクエストのコンテキストに任意のキー・バリューペアを付与し、サービス間で伝播させる機能です。例えば、フロントエンドで付与したユーザーIDやテナント情報を下流のサービスで参照し、ログやメトリクスの属性として活用できます。ただし、Baggageはネットワーク上を平文で伝播するため、個人情報や機密データの格納には注意が必要です。

OpenTelemetryの構成要素を図解で整理する

仕様（Specification）とセマンティック規約

OTelの土台は言語非依存の仕様書（Specification）です。API・SDK・データモデル・プロトコルの振る舞いがすべて文書化されており、各言語のSDKはこの仕様に準拠して実装されます。加えて、セマンティック規約（Semantic Conventions）がHTTPリクエスト属性名（http.request.methodなど）やデータベース操作属性名を標準化しています。これにより、言語やフレームワークが異なっても属性名が統一され、バックエンド側でのクエリや集計が容易になります。

APIとSDK ― 分離設計の意図

OTelの計装レイヤーはAPIとSDKに明確に分かれています。ライブラリ開発者はAPI（インターフェース定義のみ）に依存してコードを書き、アプリケーション開発者がSDK（実処理を含む実装）をDI的に注入します。この分離により、ライブラリに計装コードを組み込んでも、エンドユーザーがOTel SDKを導入していない環境ではno-op（何もしない）として動作し、パフォーマンスへの影響がゼロになります。

OpenTelemetry Collector ― データパイプラインの中核

OpenTelemetry Collectorはテレメトリデータの受信・加工・転送を担う独立プロセスです。アプリケーションSDKから直接バックエンドへ送信する構成も可能ですが、Collectorを中間に挟むことでリトライ制御・バッチング・データ変換・認証情報の一元管理が実現します。

Collectorの内部パイプラインは3つのコンポーネントで構成されます。

• Receiver: OTLP・Jaeger・Prometheus・Zipkinなどの形式でデータを受信します
• Processor: バッチ処理、属性のフィルタリング、サンプリングなどを適用します
• Exporter: 加工済みデータをバックエンドへ送信します

OTel Collectorのデプロイパターンは大きく2つあります。Agentモードでは各ホスト（Pod）にサイドカーとして配置し、低レイテンシでローカルデータを収集します。Gatewayモードではクラスター単位で集約ポイントを設置し、サンプリングやルーティングの一括制御を行います。本番環境ではAgentモードで一次収集し、Gatewayモードで集約するハイブリッド構成が推奨されています。

OTLP（OpenTelemetry Protocol）― 統一通信規格

OTLP（OpenTelemetry Protocol）は、トレース・メトリクス・ログの全シグナルを単一プロトコルで転送するためのワイヤーフォーマットです。gRPCとHTTP/protobufの2つのトランスポートをサポートしており、主要な監視バックエンドの多くがOTLPネイティブ受信に対応し始めています。OTLPの普及によって、ベンダー固有のエクスポーターを使わずにデータ送信できるケースが増えています。

自動計装と手動計装の使い分け

OTelの計装には 自動計装（Auto-Instrumentation） と 手動計装（Manual Instrumentation） の2種類があります。自動計装はHTTPクライアント・データベースドライバ・gRPCなどの主要ライブラリを自動検出し、コード変更なしでトレースやメトリクスを取得します。Java Agent（-javaagentオプション）やPythonのopentelemetry-instrumentコマンドが代表例です。一方、ビジネスロジック固有の計測ポイントが必要な場合は手動計装でカスタムスパンやカスタムメトリクスを追加します。まず自動計装で広くカバーし、必要に応じて手動計装を重ねるアプローチが効率的です。

OpenTelemetry vs. 他ツールの違い早わかり表

OTelは「計装と収集」に特化したフレームワークであり、ストレージや可視化の機能は持ちません。一方、Prometheus・Jaeger・Datadogはそれぞれ異なるレイヤーをカバーしています。

OpenTelemetryとPrometheusは競合ではなく補完関係にあります。OTelで計装したメトリクスをPrometheusへエクスポートし、Grafanaで可視化する構成は広く採用されています。Jaegerも同様に、OTelのトレースデータのバックエンドとして機能します。実際、Jaegerプロジェクト自体がOpenTelemetry Collectorベースのアーキテクチャへ移行を完了しています（出典: CNCF）。

OpenTelemetryを導入する5ステップ

Step 1: 計装対象の選定

全サービスを一度に計装する必要はありません。まずリクエスト量が多いAPIゲートウェイや、障害頻度の高いサービスを1〜2つ選定します。トレースの効果はサービス間の経路が可視化されたときに最大化するため、呼び出し関係のあるサービスペアを選ぶのが有効です。

Step 2: SDKの導入（OpenTelemetry Pythonの例）

OTelは12の言語に公式SDKを提供しています（C++、.NET、Erlang/Elixir、Go、Java、JavaScript、Kotlin、PHP、Python、Ruby、Rust、Swift）。OpenTelemetry Pythonでの基本的なセットアップは以下の流れです。

pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# TracerProviderの初期化
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# カスタムスパンの作成
tracer = trace.get_tracer("my-service")
with tracer.start_as_current_span("process-order") as span:
    span.set_attribute("order.id", "12345")
    # ビジネスロジック

自動計装を使う場合は opentelemetry-instrument コマンドでアプリケーションを起動するだけで、Flask・Django・requestsなどの主要ライブラリが自動検出されます。

Step 3: Collectorのセットアップ

OTel Collectorはバイナリ配布・Dockerイメージ・Helmチャートで提供されています。最小構成のYAML設定例を示します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s

exporters:
  otlp:
    endpoint: "jaeger:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Step 4: バックエンドとの接続

Collectorのexportersセクションにバックエンド固有の設定を追加します。Jaeger・Prometheus・Zipkinなどのオープンソースバックエンドのほか、Datadog・New Relic・Grafana Cloudといった商用SaaSにもOTLP経由で直接送信できます。複数のExporterを同時に設定すれば、同じデータを異なるバックエンドへファンアウトすることも可能です。

Step 5: ダッシュボード構築

バックエンドへデータが到達したら、サービスマップ・レイテンシ分布・エラー率の可視化を設定します。Grafana + Tempoの組み合わせではトレースからメトリクスへのドリルダウンが可能です。ダッシュボードのアラート閾値は、まず1〜2週間の実データを収集してベースラインを把握してから設定すると、誤報を減らせます。

クラウド別のOpenTelemetry対応状況

主要クラウドプロバイダーはいずれもOTelを公式にサポートしています。

AWS: AWS Distro for OpenTelemetry（ADOT） として、OTel CollectorのAWS向けディストリビューションを提供しています。X-Ray・CloudWatch・Amazon Managed Service for Prometheusへのエクスポーターが組み込まれており、EKSアドオンとしてのデプロイにも対応しています（出典: AWS）。2025年にはAWS X-Ray自体がOpenTelemetryベースのアーキテクチャへ移行する方針を発表しました。

Google Cloud: Cloud TraceサービスがOTLPネイティブ受信に対応しました。telemetry.googleapis.comエンドポイントを指定するだけで、ベンダー固有エクスポーター不要でトレースデータを送信できます（出典: InfoQ）。

Azure: Azure MonitorがOpenTelemetry SDKベースのディストロを提供しています。Application Insightsとの統合により、.NET・Java・Python・JavaScript・Node.jsアプリケーションの自動計装が可能です。

本番導入で押さえるべきベストプラクティス

カーディナリティ管理: メトリクスのラベルに高カーディナリティ値（ユーザーID・セッションIDなど）を設定すると、バックエンドのストレージとクエリ性能が急激に悪化します。OTel Collectorのattributesプロセッサーで不要な属性を除外するか、値をグループ化してカーディナリティを抑制します。

サンプリング戦略: トラフィックが大きい環境では全スパンを記録するとコストが膨大になります。サンプリングには2つの方式があります。Head-based Samplingはリクエスト開始時に確率的にサンプル対象を決定する方式で、実装がシンプルです。Tail-based Samplingはリクエスト完了後にエラーや高レイテンシのトレースを優先保存する方式で、重要なトレースの取りこぼしを防げますが、Collector側にメモリバッファが必要です。

段階的導入: 既存の監視基盤を一括で置き換えるのではなく、新規サービスからOTel計装を始め、既存サービスは並行稼働期間を設けて移行します。CollectorのファンアウトExporter機能を使えば、旧バックエンドと新バックエンドへ同時にデータを送信しながら比較検証できます。

セキュリティ: Collectorのattributesプロセッサーやredactionプロセッサーを使い、トレースやログに含まれるパスワード・トークン・個人情報をマスキングします。Collector間の通信にはmTLSを有効化し、認証されていないデータの混入を防ぎます。

AIオブザーバビリティとOpenTelemetryの接点

LLM（大規模言語モデル）を組み込んだアプリケーションの急増に伴い、プロンプト・レスポンス・トークン消費量・レイテンシを可視化する「AIオブザーバビリティ」の需要が高まっています。Traceloop社が開発するOpenLLMetryはOTelの拡張としてLLM呼び出しを自動計装するOSSで、GitHub上で6,600以上のスターを獲得しています（出典: GitHub）。

OpenTelemetry本体でも、GenAI向けのセマンティック規約（gen_ai.*属性名）の策定が進んでおり、LLMプロバイダー名・モデルID・トークン数などの標準属性が定義されつつあります。Datadogなど主要バックエンドもこのセマンティック規約への対応を表明しており、AIワークロードの監視がOTelエコシステムの中で標準化される方向です。

OpenTelemetryの歴史と現在のステータス

2025年時点で、OTelのGitHub Organization配下には約95のリポジトリが存在し、47のSpecial Interest Group（SIG）が活動しています（出典: OpenTelemetry Blog）。CNCFの成熟度としては「Incubating」ステータスですが、Kubernetes・Prometheusに次ぐプロジェクト規模を持ち、Graduated申請も視野に入っています。

よくある疑問（FAQ）

Q: PrometheusとOpenTelemetryはどう使い分けますか？

Prometheusはメトリクスの収集・保存・アラートに特化した完結型システムで、OTelは計装・収集に特化したフレームワークです。両者は競合ではなく、OTelで計装 → Prometheusへエクスポートという組み合わせが標準的なパターンです。既にPrometheusを運用中であれば、OpenTelemetry Collectorのprometheusエクスポーターを追加するだけで統合できます。

Q: AWSでOpenTelemetryを使うにはどうすればよいですか？

AWS Distro for OpenTelemetry（ADOT）を利用します。ADOTはAWSが公式にサポート・テストしたOTel Collectorディストリビューションで、X-RayやCloudWatchへのエクスポーターがプリセットされています。EKS環境ではアドオンとして数クリックで導入可能です。

Q: 学習コストは高いですか？

OTelの概念（トレース・メトリクス・ログ・Collector）自体はシンプルですが、設定パラメータとエコシステムの広さから「どこから手を付けるか」で迷いやすい傾向があります。OpenTelemetry入門として推奨されるのは、公式サイトの「Getting Started」ページから使い慣れた言語のSDKチュートリアルを1つ完走し、ローカルでJaegerにトレースを送信してみることです（出典: OpenTelemetry）。OpenTelemetry GitHubリポジトリのDemoアプリ（Astronomy Shop）を動かすと、複数サービス間のトレース伝播を体感できます。

Q: バックエンドは何を選ぶべきですか？

チームの運用能力と予算次第です。OSSで構築するなら、トレースにJaeger（またはGrafana Tempo）、メトリクスにPrometheus、ログにLokiを組み合わせ、Grafanaで統合可視化する構成が定番です。運用負荷を下げたい場合はGrafana Cloud・Datadog・New Relicなどのマネージドサービスが選択肢になります。OTelを採用していれば、バックエンドの変更はCollectorの設定変更のみで完結するため、後からの切り替えも容易です。