traceloop/openllmetry とは何ですか？

OpenLLMetry は LLM 呼び出しとベクター DB を OpenTelemetry のスパンとして計装するパッケージ群である。既存の可観測基盤に LLM のトレースを流し込める点が最大の利点だが、計装対象の網羅性とデータ量の扱いは自分で確かめる必要がある。

traceloop/openllmetry は商用利用できますか？

できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

traceloop/openllmetry は今もメンテナンスされていますか？

されています。最後のコミットは 37 日前です。

traceloop/openllmetry はどのプログラミング言語で書かれていますか？

主に Python です（GitHub の言語統計による）。

OpenLLMetry レビュー: OpenTelemetry ベース LLM 計装の構成と採用判断

ひと目でわかる

これは何？: OpenLLMetry は LLM 呼び出しとベクター DB を OpenTelemetry のスパンとして計装するパッケージ群である。既存の可観測基盤に LLM のトレースを流し込める点が最大の利点だが、計装対象の網羅性とデータ量の扱いは自分で確かめる必要がある。
誰に向いている？: OpenTelemetry をすでに運用していて、LLM 呼び出しを同じトレース基盤に載せたいチームには向いている。逆に、独自の LLM 専用ダッシュボードや評価ワークフローを求めている場合、OpenLLMetry はあくまで計装層なので別途ツールが要る。
商用利用できる？: できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 37 日前です。
何の言語で書かれている？: 主に Python です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · traceloop/openllmetry

OpenLLMetry が埋めるのは「LLM 呼び出しがトレースに出ない」という穴

通常の Web アプリケーションは OpenTelemetry で HTTP ハンドラや DB クエリをスパンとして記録できる。しかし LLM アプリケーションでは、肝心の推論呼び出しやベクター検索がただの外部 HTTP リクエストとして扱われ、プロンプトやトークン数、モデル名といった情報がトレースに残らない。OpenLLMetry はこの部分に標準の OpenTelemetry スパンを生成する計装を提供する。対象は OpenAI や Anthropic などのプロバイダ SDK、Chroma、Pinecone、Qdrant、Weaviate といったベクター DB である。README は「OpenTelemetry already instruments」の範囲に加えて独自拡張を載せると説明しており、既存の計装を置き換えるのではなく積み増す設計だと読み取れる。想定読者は、すでに Datadog や Honeycomb など何らかの OTLP 受け口を持ち、LLM 機能をその監視の延長で見たいエンジニアである。

traceloop-sdk と個別計装パッケージの二層構造

リポジトリは大きく二種類の成果物を含む。ひとつは LLM プロバイダやベクター DB 向けの標準 OpenTelemetry 計装パッケージ群、もうひとつは導入を簡単にする Traceloop SDK である。README によれば、SDK は「standard OpenTelemetry data」を出力するため、Traceloop のバックエンドに縛られない。すでに OpenTelemetry で計装済みの環境なら、SDK を挟まず必要な計装パッケージだけを追加できる。この二層構造は、既存の Collector パイプラインを持つチームにとっては無駄が少ない。一方で、SDK 側の設定項目と個別計装側の設定項目が別々に存在することを意味するので、初期化の順序やリソース属性の扱いを把握しておかないと、スパンが二重に出たり属性が欠けたりする余地がある。README の範囲ではこの境界の詳細までは示されていない。

導入手順: init 一行と disable_batch の使い分け

README が示す最短手順は次のとおり。pip install traceloop-sdk で SDK を入れ、コードに from traceloop.sdk import Traceloop と Traceloop.init() を追加する。これだけで計装が有効になる。ローカルで動作確認する場合は Traceloop.init(disable_batch=True) を使うと、バッチ送信を無効化してトレースを即座に確認できると README は説明している。本番ではバッチ送信のままにしておくのが自然で、disable_batch は開発時のデバッグ用と位置づけられる。送信先は環境変数や Collector の設定で切り替える形になり、README は Traceloop、Datadog、Honeycomb、Grafana、SigNoz、OpenTelemetry Collector など多数の接続先を列挙し、それぞれの手順はドキュメント側に委ねている。この記事の範囲では、各接続先の具体的な環境変数名までは確認できない。

計装対象の広さと、ベクター DB 側の見えにくさ

README の対応リストはプロバイダとベクター DB を混在して並べている。Aleph Alpha、Anthropic、Bedrock などが挙がり、ベクター DB では Chroma、Pinecone、Qdrant、Weaviate が対象である。ただしプロバイダ計装とベクター DB 計装では得られる情報の性質が違う。プロバイダ計装はモデル名やトークン数など比較的そろった属性を期待できるが、ベクター DB 側はクエリの埋め込みや返却件数といった情報が中心になり、検索品質そのものを評価する情報にはならない。RAG の不具合を追うとき、どのドキュメントがヒットしなかったのかをスパンだけで判断するのは難しい。この点は OpenLLMetry の欠点というより、トレースという形式が持つ限界である。計装対象が広いことと、欲しい情報が取れることは別問題だと考えておいたほうがよい。

向かないケース: 計装層であって評価基盤ではない

OpenLLMetry はあくまで計装とエクスポートの層である。プロンプトのバージョン管理、A/B 比較、出力の自動採点といった機能は README には記載がない。LLM の品質を継続的に評価したいチームが OpenLLMetry だけを入れても、トレースは流れるが判断材料は自分で作ることになる。また、スパンにはプロンプトやレスポンスが属性として載る可能性があり、個人情報や機密を含む入力を扱う場合はサンプリングや属性の削除を Collector 側で設計する必要がある。README はこの点に触れていない。データ量についても、バッチ送信を切った状態で高トラフィックを流せば送信がボトルネックになりうる。disable_batch はあくまでローカル確認用と考えるべきで、本番の設定として残すのは避けたい。

代替との違い: Langfuse や Phoenix は評価まで含む

LLM 向けの可観測ツールとしてよく比較されるものに Langfuse や Arize Phoenix がある。これらはトレース表示に加えて、プロンプト管理や評価スコアの記録といった機能を前面に出す。OpenLLMetry の発想は逆で、LLM 固有の情報を OpenTelemetry の意味論に沿ったスパンに変換し、あとは既存の可観測基盤に任せる。したがって Datadog や Grafana をすでに全社で使っている組織では、新しいダッシュボードを増やさずに LLM のレイテンシやエラーを既存のアラート体系に載せられる。逆に、LLM 専用の評価画面が欲しいだけなら、OpenLLMetry を入れたうえで別のツールを重ねることになり、構成要素が増える。どちらが優れているという話ではなく、監視をどこに集約したいかで決まる。

ライセンスと更新頻度から見た運用コスト

ライセンスは Apache-2.0 で、Traceloop が維持している。Apache-2.0 は商用利用や改変を許容するが、特許条項や再配布時の表示義務など条件があるため、法務確認は各自で行う必要がある。ここで法的助言はできない。更新は活発で、0.62.1 が 2026-06-28、0.62.2 が 2026-08-09、0.62.3 が 2026-08-10 と短期間に続いている。LLM プロバイダの API は頻繁に変わるため、計装パッケージが追随し続けることは利点である。同時に、マイナーバージョンが細かく上がるということは、依存を固定せずに追従すると検証負荷が継続的に発生するということでもある。プロバイダ SDK 側の更新と OpenLLMetry 側の更新がずれると、属性が取れなくなる期間が生じうる。バージョンを固定して定期的に見直す運用のほうが現実的だろう。

採用前に確かめる三つのこと

第一に、自分の使うプロバイダとベクター DB が README の対応リストに入っているか。リストは長いが網羅ではない。第二に、既存の Collector に送ったスパンがどう見えるか。OpenLLMetry は標準の OpenTelemetry データを出すと README は述べているが、LLM 固有の属性がダッシュボードでどう表示されるかは受け口次第である。第三に、プロンプトやレスポンスを属性として送るかどうか。機密を含むなら Collector のプロセッサで除去する設計を先に決めておきたい。これらを確認せずに Traceloop.init() を本番に入れると、あとから属性設計をやり直すことになる。

編集部の結論

OpenTelemetry をすでに運用していて、LLM 呼び出しを同じトレース基盤に載せたいチームには向いている。逆に、独自の LLM 専用ダッシュボードや評価ワークフローを求めている場合、OpenLLMetry はあくまで計装層なので別途ツールが要る。最初に確認すべきは、自分の使うプロバイダとベクター DB が README の対応リストに入っているか、そして既存の Collector に送ったときにスパン属性がどう見えるかである。

公式情報源

コミュニティノート