OpenTelemetry Collectorとは？
OpenTelemetry Collector は、アプリケーションとテレメトリーの送り先のあいだに置くサービスです。アプリケーションはトレース、メトリクス、ログを、たいていは OpenTelemetry 独自のプロトコルである OTLP で送ります。Collector はそれをまとめ、指定したものを捨てたり書き換えたりして、1 つ以上のバックエンドにコピーを転送します。設定はすべて YAML のパイプラインで、receiver（入力）、processor（絞り込み、サンプリング、マスキング）、exporter（出力）、connector（パイプライン同士をつなぐもの）を並べます。
エージェントのチームにとって、ここはプランナー、3 つのツールワーカー、2 つのモデル提供元をまたぐトレースが再び 1 つにまとまる場所であり、エンドツーエンドの遅延がどこで生じたかがわかる場所です。LLM のスパンは OpenTelemetry の GenAI セマンティック規約に従います。gen_ai.request.model や gen_ai.usage.input_tokens のような共通の名前の集まりで、これにより Collector は同じスパンを LLM のデバッグ用に Langfuse や Arize Phoenix へ、スタックの残りのために Grafana や Datadog へ送れます。
コアのリポジトリにはフレームワークと少数のコンポーネントがあり、receiver、processor、exporter の大半は opentelemetry-collector-contrib にあります。どちらも Apache 2.0 の CNCF プロジェクトです。公式ディストリビューションは 5 つあり、コア版、contrib 版、Kubernetes 版などが含まれます。Collector Builder（ocb）を使えば、必要なコンポーネントだけを含む独自版をビルドできます。
OpenTelemetry Collectorは使う価値があるか？
Collector は、エージェントシステムのトレーシングを持ち運べる状態に保つものです。OpenTelemetry で一度計装し、すべてのサービスの送り先を Collector にすれば、トレースを Langfuse、Phoenix、Datadog のどれに、あるいは 3 つすべてに送るかは、コードではなく YAML の変更で決まります。オブザーバビリティの分野でこれほど広く使われているものはほかにありません。コアのリポジトリには GitHub のスターが約 7,700、contrib には約 5,000 あり、リリースは数週間ごとに出て、バージョン 0.165.0 が 2026年11月6日に公開されました。
LLM のバックエンドにはできない仕事もします。redaction や transform の processor を使えば、プロンプトの属性から顧客データを社外に出る前に取り除けます。GenAI 規約は入出力のメッセージ全体をスパン属性に入れ、個人データを含みうると警告しているので、これは重要です。サンプリングは費用を 抑えます。おしゃべりなエージェントのトレースをすべて残すと高くつきますが、tail sampling なら遅いものや失敗したものだけを残せます。Langfuse 自身のドキュメントも、Collector が OTLP を gRPC で受け取り HTTP で転送する例を示しています。Langfuse がまだ gRPC を受け付けないためです。
GenAI の層はまだ動いています。GenAI 規約はどれも Stable に達しておらず、2026年に専用のリポジトリへ移り、属性の名前もすでに変わっています（gen_ai.system は gen_ai.provider.name になりました）。バックエンドは仕様に遅れており、Langfuse はいまも非推奨の gen_ai.prompt と gen_ai.completion を対応づけています。計装のバージョンを固定し、バックエンドが何を読むかを確かめるのも仕事のうちです。絞り込みにも注意が要ります。Langfuse はトレースのルートスパンを必要とし、それを捨てるとトレースが不完全になります。
残りについてはバージョン番号が正直に語っています。バイナリはまだ 0.x で、安定度はコンポーネントごとに異なり、互換性のない変更がリリースノートに載ります。0.165.0 では非推奨の HTTP 設定が 4 つ削除されました。セキュリティ上のリスクの大半は contrib にあり、2026年のアドバイザリには Azure 認証拡張の認証回避や、設定した認証を無視する GitHub receiver が含まれます。エージェントのサービスが 1 つでバックエンドも 1 つのチームが得るものは少なく、ドキュメントも小さな構成なら直接送って構わないとしています。意味が出てくるのは 2 つ目のサービスか 2 つ目の送り先からです。
真価を発揮する場面
6 つのサービスにまたがるサポートエージェントを運用するフィンテックのプラットフォームチーム
遅い回答を端から端まで追い、口座番号をトレースの保存先に残さない
各サービスが OTLP を Collector のゲートウェイに送り、redaction の processor が gen_ai.input.messages 内の口座番号のパターンをマスクしてから、セルフホストの Langfuse にエクスポートします。Collector 自体の費用は、動かしている Pod の分だけです。
取り込んだスパン単位で Datadog に支払う小売企業の SRE
エージェントの全ステップに課金されずに LLM デバッグ用の詳細を残す
AI チーム向けにはすべてのスパンを Phoenix か Langfuse に送り、Datadog には tail sampling で選んだ遅いトレースや失敗したトレースだけを送ります。tail sampling では 1 つのトレースの全スパンが同じ Collector に届く必要があるため、先にロードバランシングの層を置きます。
LLM オブザーバビリティのベンダーを選ぶ 15 人のスタートアップの CTO
最初のトレーシングツールに縛られないようにする
最初から OpenTelemetry で計装し、Collector を経由させます。2 つ目のバックエンドを試すには exporter を 1 つ足し、1 か月ほど両方を並行して動かすだけで、SDK の入れ替えは要りません。
導入前に確認すること
- 導入
- otelcol-contrib の Docker イメージかバイナリを、receiver、processor、exporter を並べた YAML 設定で起動します。Langfuse は転送用のサンプル設定をそのまま使える形で公開しています。Kubernetes 向けには専用のディストリビューションがあり、ocb で小さなバイナリを作れます。
- 連携
- 入力は gRPC と HTTP の OTLP で、contrib を通じてほとんどのオブザーバビリティのバックエンド向け exporter があります。Langfuse が受け付けるのは /api/public/otel への HTTP の OTLP だけです。Phoenix と OpenLLMetry は OpenTelemetry のスパンを出力し、読み込みます。
- データとプライバシー
- セルフホストです。設定しない限りメモリ上のバッファ以外には何も保存せず、指定した exporter にだけデータを送ります。GenAI のスパンにはプロンプトと出力の全文が入りうるため、マスキングはここで行うのが適切です。Apache 2.0 です。セキュリティアドバイザリはコアのリポジトリに 2 件、contrib には 2026年に複数件あります。
- 大規 模利用時のコスト
- ライセンス料も有料版もありません。費用はエージェントやゲートウェイとして動かす Collector の計算資源と、バックエンドの取り込み料金です。LLM のワークロード向けのサイジングの数字は公開されていません。
- 制限
- 0.x のリリースで互換性のない変更があります。GenAI 規約は Development の段階です。tail sampling にはロードバランシングの層が必要です。ルートスパンを捨てると Langfuse のトレースが壊れます。未解決の issue とプルリクエストはコアで約 690 件、contrib で 1,060 件です。
良い点
- ベンダー中立で、アプリのコードに触れずにバックエンドを切り替えたり追加したりできる
- データが社外に出る前にマスキング、絞り込み、tail sampling ができる
- プロトコルを橋渡しでき、たとえば gRPC で受けて HTTP で Langfuse に送れる
- ocb による独自ビルドでバイナリを小さく保てる
気になる点
- まだ 0.x で、リリースノートに互換性のない変更が載る
- GenAI 規約はまだ Stable ではなく、名前の変更が続いている
- contrib のコンポーネントは成熟度がまちまちで、アドバイザリの大半を占める
- 運用、サイジング、監視が必要なサービスがもう 1 つ増える
おすすめの人
複数のサービスや複数のテレメトリーバックエンドを持ち、コードを変えずに LLM のトレースをマスキング、サンプリング、再ルーティングしたいエージェントのチーム。
OpenTelemetry Collectorの代替
OpenTelemetry Collector：よくある質問
- OpenTelemetry Collectorは使う価値があるか？
- 複数のサービスやバックエンドが関わるようになったら、エージェントのトレースを集め、整え、振り分ける標準の場所です。それまでは可動部品が 1 つ増えるだけです。 評価は5点満点中4.4点です。
- OpenTelemetry Collectorの料金は？
- Apache 2.0 の無料のオープンソースで、プロジェクトによる有料版はありません。費用は動かすマシンと送り先のバックエンドの分で、商用ディストリビューションはオブザーバビリティベンダーが提供しています。
- OpenTelemetry Collectorの欠点は？
- まだ 0.x で、リリースノートに互換性のない変更が載る; GenAI 規約はまだ Stable ではなく、名前の変更が続いている; contrib のコンポーネントは成熟度がまちまちで、アドバイザリの大半を占める; 運用、サイジング、監視が必要なサービスがもう 1 つ増える.
- OpenTelemetry Collectorは誰に向いているか？
- 複数のサービスや複数のテレメトリーバックエンドを持ち、コードを変えずに LLM のトレースをマスキング、サンプリング、再ルーティングしたいエージェントのチーム。
- チームや本番環境でOpenTelemetry Collectorを使うと費用はいくらか？
- ライセンス料も有料版もありません。費用はエージェントやゲートウェイとして動かす Collector の計算資源と、バックエンドの取り込み料金です。LLM のワークロード向けのサイジングの数字は公開されていません。
- OpenTelemetry Collectorは企業データを扱っても安全か？
- セルフホストです。設定しない限りメモリ上のバッファ以外には何も保存せず、指定した exporter にだけデータを送ります。GenAI のスパンにはプロンプトと出力の全文が入りうるため、マスキングはここで行うのが適切です。Apache 2.0 です。セキュリティアドバイザリはコアのリポジトリに 2 件、contrib には 2026年に複数件あります。
- OpenTelemetry Collectorの代わりになるものは？
- 当サイトでレビューした中で最も近い代替はOpenLLMetryです。
回答確認日：2026年11月9日
OpenTelemetry Collectorの開発元の方へ：この評価をサイトに掲載できます
