Skip to main content
このページでは、W&B Weave の従来の OTel ワークフローについて説明します。Weave を初めて使用する方や、エージェント型アプリケーションを構築する方には、新しいエンドポイント /agents/otel/v1/traces にトレースを送信することを強くお勧めします。新しいエンドポイントを使用すると、任意の OpenTelemetry パイプラインから OTLP トレースデータを、W&B Weave と Agent Lens (エージェントに特化したトレーシングおよび可観測性のプラットフォーム) の両方に送信できます。
Weave は、専用のエンドポイントを介した OpenTelemetry 互換トレースデータのインポートをサポートしています。このエンドポイントを使用すると、OTLP (OpenTelemetry Protocol) 形式のトレースデータを Weave プロジェクトに直接送信できます。既存の OTel ベースの可観測性パイプラインはそのままに、OpenTelemetry 標準でアプリケーションをインストルメントし、そのトレースを他の Weave データと一緒に表示したい場合は、このインテグレーションを使用してください。 このページでは、エンドポイントの詳細、認証、Python と TypeScript によるエンドツーエンドのサンプル、OpenTelemetry Collector を経由してトレースを転送する方法、トレースを Weave スレッドに整理する方法、そして Weave が受信スパンに適用する属性マッピングについて説明します。
このエンドポイントのデータは Traces ビューと Threads ビューに表示されます。マルチターンのエージェントから Agents ビューに OTel スパンを送信する場合は、代わりに agents エンドポイントを使用してください。詳しくは、OpenTelemetry スパンを Agents ビューに送信するを参照してください。

エンドポイントの詳細

  • パス: /otel/v1/traces
  • メソッド: POST
  • Content-Type: application/x-protobuf
  • ベース URL: OTel トレースエンドポイントのベース URL は、Weights & Biases のデプロイメントタイプによって異なります。
    • Multi-tenant Cloud: https://trace.wandb.ai/otel/v1/traces
    • 専用クラウドおよびセルフマネージドのインスタンス: https://<your-subdomain>.wandb.io/traces/otel/v1/traces
    <your-subdomain> は、組織固有の Weights & Biases ドメイン (例: acme.wandb.io) に置き換えてください。

認証とルーティング

Weave は、wandb-api-key ヘッダーでリクエストを認証し、TracerProvider のリソース属性に基づいてスパンを適切な entity と project にルーティングします。Forge APIキーを wandb-api-key ヘッダーで渡したうえで、TracerProvider クラスで次のキーを OpenTelemetry の Resource 属性として指定します。
  • wandb.entity: CoreWeave Forge のチーム名またはユーザー名。
  • wandb.project: トレースの送信先となるプロジェクト名。
次の例は、認証と project のルーティングを設定する方法を示しています。
以下の WEAVE_OTLP_ENDPOINT はローカル変数であり、OTel SDK の OTEL_EXPORTER_OTLP_ENDPOINT 環境変数ではありません。この変数には、トレースの完全なパス (.../otel/v1/traces) を設定しています。この値はエクスポーターの endpoint=/url: に明示的に渡されるため、SDK はその URL にそのままリクエストを送信します。一方、値を実際の OTEL_EXPORTER_OTLP_ENDPOINT として export し、引数なしでエクスポーターを構築する場合 (例: OTLPSpanExporter()) は、SDK が自動的に /v1/traces を付加します。そのため、この環境変数にはベース URL (.../otel) を設定する必要があります。そうしないと、パスが重複して (.../otel/v1/traces/v1/traces) 404 が発生し、スパンが警告なしに破棄されます。OTEL_EXPORTER_OTLP_TRACES_ENDPOINT も同様です。SDK はこの変数にも /v1/traces を付加しないため、トレースの完全なパスを設定する必要があります。

サンプル

以下のサンプルでは、Python と TypeScript を使用して OpenTelemetry のトレースを Weave に送信する方法を示します。サンプルごとに異なるアプローチを取り上げます。OpenInference インストルメンテーションライブラリを使用する方法、OpenLLMetry インストルメンテーションを使用する方法、インストルメンテーションパッケージを使わずに OpenTelemetry SDK を直接使用する方法の 3 つです。 以下のコードサンプルを実行する前に、次のフィールドを設定してください。
  • WANDB_API_KEY: User Settings から取得できます。
  • Entity: トレースをログできるのは、アクセス権のある チーム/entity 配下の project に限られます。entity 名を確認するには、Weights & Biases ダッシュボード にアクセスし、左サイドバーの Teams フィールドを確認してください。
  • プロジェクト名: 任意の名前を指定します。
  • OPENAI_API_KEY: OpenAI ダッシュボード から取得できます。

OpenInference インストルメンテーション

OpenInference は Arize AI が提供するオープンソースのインストルメンテーションライブラリで、LLM Call を OpenTelemetry のスパンとして取得します。この例では、OpenAI インストルメンテーションの使い方を紹介します。その他のインストルメンテーションは公式リポジトリで入手できます。
OpenInference のスパンは Traces ビューでのみレンダリングされ、Agents ビューには表示されません。Agents ビューは、OTel GenAI セマンティック規約に準拠したスパンをもとに、会話、ターン、ツール呼び出しを構築します。
まず、必要な依存関係をインストールします。
パフォーマンスに関する推奨事項: Weave にトレースを送信する際は、SimpleSpanProcessor ではなく必ず BatchSpanProcessor を使用してください。SimpleSpanProcessor はスパンを同期的にエクスポートするため、他のワークロードのパフォーマンスに影響を及ぼす可能性があります。これらのサンプルで使用している BatchSpanProcessor は、スパンを非同期で効率よくバッチ処理するため、本番環境での使用に適しています。
次のコードを openinference_example.py などの Python ファイルに貼り付けます。
コードを実行します:

OpenLLMetry インストルメンテーション

OpenLLMetry は Traceloop が開発しているオープンソースの可観測性ライブラリで、主要な LLM プロバイダやフレームワーク向けに OpenTelemetry インストルメンテーションを提供します。以下の例では、その OpenAI インストルメンテーションの使い方を紹介します。その他の例は OpenLLMetry リポジトリを参照してください。 まず、必要な依存関係をインストールします。
次のコードを openllmetry_example.py などの Python ファイルに貼り付けます。前の例と同じコードですが、OpenAIInstrumentor を openinference.instrumentation.openai ではなく opentelemetry.instrumentation.openai からインポートしている点のみが異なります。
コードを実行します:

インストルメンテーションを使用しない場合

インストルメンテーションパッケージを使用せずに、OTel を直接使用することもできます。この方法では、各スパンに設定する属性を完全に制御できます。Weave は、https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/ で定義されている OpenTelemetry のセマンティック規約に従ってスパン属性を解析します。 まず、必要な依存関係をインストールします。
次のコードを opentelemetry_example.py などの Python ファイルに貼り付けます。
コードを実行します:
Weave は、スパン属性の接頭辞 gen_ai と openinference を使用して、トレースの解釈時に適用する規約を判断します (どちらも適用しない場合もあります)。どちらのキーも検出されない場合は、すべてのスパン属性がトレースビューに表示されます。トレースを選択すると、サイドパネルでスパン全体を確認できます。

OpenTelemetry Collector を使用する

これまでの例では、アプリケーションから Weave へトレースを直接エクスポートしていました。本番環境では、アプリケーションと Weave の間を仲介する OpenTelemetry Collector を使用できます。コレクターはアプリケーションからトレースを受信し、1 つ以上のバックエンドに転送します。この構成では、認証、バッチ処理、ルーティングのロジックをアプリケーションコードから切り離して一元管理できます。また、単一のパイプラインから複数の可観測性バックエンドへトレースを振り分けることもできます。

コレクターを設定する

このセクションでは、Docker でローカルの OpenTelemetry Collector を実行し、アプリケーションからそのコレクターにトレースを送信するよう設定する手順を説明します。次の例では、以下の方法を示します。
  • OTLP トレースを受信してバッチ処理し、Weave に転送するローカルサーバー (コレクター) をデプロイするための Docker 設定ファイルを作成する。
  • Docker を使用してコレクターをローカルで実行する。
  • OpenAI に基本的な Call を送信し、Docker コンテナー内で実行中のコレクターにトレースを転送する。
コレクターを使用するには、まず collector-config.yaml ファイルを作成し、OTLP トレースを受信して Weave にエクスポートするようコレクターを設定します。
collector-config.yaml
この設定ファイルでは、次の処理を行います。
  • ポート 4318 (HTTP) で OTLP トレースを受信します。
  • wandb-api-key ヘッダーを使用して、Weave の OTLP エンドポイントにトレースをエクスポートします。エンドポイント URL は WANDB_OTLP_ENDPOINT から、APIキーは WANDB_API_KEY から読み取ります。
  • resource プロセッサを使用して、wandb.entity と wandb.project をリソース属性として設定します。値は DEFAULT_WANDB_ENTITY と DEFAULT_WANDB_PROJECT から読み取ります。insert action は、アプリケーションコード側でこれらの属性が設定されていない場合にのみ、属性を注入します。
  • エクスポーターに組み込まれている sending_queue をバッチ処理付きで有効にし、ネットワークのオーバーヘッドを削減します。
コレクターの設定が完了したら、次の Docker コマンドの API と entity の値を書き換えてから実行します。
コレクターが起動したら、OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定し、アプリケーションからコレクターへトレースをエクスポートするように構成します。OTel SDK はこの変数を自動的に読み取るため、エンドポイントをエクスポーターに渡す必要はありません。 アプリケーションの TracerProvider で wandb.entity または wandb.project をリソース属性として設定した場合、コレクターの設定で定義されたデフォルトよりもそちらが優先されます。
OpenAIInstrumentor は OpenAI の Call をラップしてトレースを作成し、コレクターにエクスポートします。認証と Weave へのルーティングはコレクターが担当します。 スクリプトの実行後、Weights & Biases の UI でトレースを表示できます。 他のバックエンドにもトレースを送信するには、エクスポーターを追加して service.pipelines.traces.exporters リストに含めます。たとえば、1 つの コレクター インスタンスから Weave と Jaeger の両方にエクスポートすることもできます。

OTel トレースをスレッドに整理する

Weave スレッドを使用すると、関連するトレースをグループ化し、マルチターンの会話やユーザーセッションを 1 つの単位として分析できます。特定のスパン属性を追加して OpenTelemetry トレースをスレッドに整理すると、Weave の Thread UI で、マルチターンの会話やユーザーセッションなどの関連する操作を分析できます。 スレッドによるグループ化を有効にするには、OTel スパンに次の属性を追加します。
  • wandb.thread_id: スパンを特定のスレッドにグループ化します。
  • wandb.is_turn: スパンを会話のターンとしてマークします (スレッドビューに行として表示されます) 。
次のサンプルでは、OTel トレースを Weave スレッドに整理する方法を示します。wandb.thread_id で関連する操作をグループ化し、wandb.is_turn でスレッドビューに行として表示される上位の操作をマークします。
これらのサンプルを実行するには、次の設定を使用します。
これらのトレースを送信すると、Weights & Biases UI の Threads タブで確認できます。トレースは thread_id ごとにグループ化され、各ターンはそれぞれ別の行に表示されます。

属性マッピング

Weave は、さまざまなインストルメンテーションフレームワークから送られる OpenTelemetry のスパン属性を、内部データモデルにマッピングします。このマッピングにより、既存のインストルメンテーションの属性をリネームしたり変換したりしなくても、Weave で充実したビューを利用できます。複数の属性名が同じフィールドにマッピングされる場合、Weave は優先順位に従ってそれらを適用します。そのため、同じトレース内で複数のフレームワークを共存させることができます。

サポートされるフレームワーク

Weave は、以下の可観測性フレームワークおよび SDK の属性規約をサポートしています。
  • OpenTelemetry GenAI: 生成 AI 向けの標準セマンティック規約 (gen_ai.*)。
  • OpenInference: Arize AI のインストルメンテーションライブラリ (input.value、output.value、llm.*、openinference.*)。
  • Vercel AI SDK: Vercel AI SDK の属性 (ai.prompt、ai.response、ai.model.*、ai.usage.*)。
  • MLflow: MLflow のトラッキング属性 (mlflow.spanInputs、mlflow.spanOutputs)。
  • Traceloop: OpenLLMetry のインストルメンテーション (traceloop.entity.*、traceloop.span.kind)。
  • Google Vertex AI: Vertex AI のエージェント属性 (gcp.vertex.agent.*)。
  • OpenLit: OpenLit の可観測性属性 (gen_ai.content.completion)。
  • Logfire / Pydantic AI: Logfire による Pydantic AI のインストルメンテーション (gen_ai.input.messages、gen_ai.output.messages、pydantic_ai.all_messages、final_result)。
  • Langfuse: Langfuse のトレース属性 (langfuse.startTime、langfuse.endTime)。

属性リファレンス

制限事項

Weights & Biases の UI では、OTel トレースのツール呼び出しを Chat ビューでレンダリングすることはサポートされていません。ツール呼び出しは、代わりに生の JSON として表示されます。
最終更新日 2026年10月20日