OpenTelemetry CollectorでAIエージェントのテレメトリコストを削減

DynatraceのBindplaneに所属するAdnan Rahic氏は、2026年10月22日に、AIエージェント向けOpenTelemetryパイプラインの最適化に関する実践的なガイドを公開しました。この記事では、Claude Codeなどのツールによって生成される過剰なテレメトリデータが、高いストレージコストと管理不能なカーディナリティを引き起こすという、本番環境での一般的な課題に対処しています。

何が起きたのか

AIコーディングエージェントのテレメトリを有効にすると、保存コストが高く解釈が困難な大量のデータが発生することがよくあります。あるテストケースでは、Claude Codeが2つの失敗したテストを修正し、境界値テストを追加しましたが、単一の実行で181件のテレメトリレコードと289 KBのJSONデータが生成されました。このデータには完全なプロンプト、ファイル本体、差分が含まれており、継続的な運用監視には不要なものがほとんどです。

根本的な問題は、デフォルトの計装（インストゥルメンテーション）が個々の開発者セッションのデバッグ用に設計されており、エージェントのフリート管理には適していない点にあります。1日あたり200セッションといった規模になると、このアプローチは持続不可能になります。メトリクスにはセッションIDやユーザーメールアドレスなど高カーディナリティの属性が含まれ、期限切れにならない数百ものユニークな時系列を作成します。さらに、ツールのコンテンツがトレースとログの両方に重複して格納され、ストレージ要件をさらに膨張させます。

Rahic氏は、任意にデータを減らすのではなく、特定の運用上の質問に答えるために必要なデータのみを保持することが目標であると示しています。バックエンドに到達する前にOpenTelemetry Collector内でデータを整形することで、チームは重要なパフォーマンスおよびコスト指標に対する可視性を失うことなく、コストを大幅に削減できます。

仕組み

このソリューションでは、OpenTelemetry Collectorを設定し、すべてのシグナルを「生データ用パイプライン」と「最適化済みパイプライン」の2つの別々なパイプラインへファンアウト（分散送信）します。両方のパイプラインは単一のOTLPレシーバーからバイト単位で同一の入力を受け取るため、公正な比較が可能になります。生データ用パイプラインは対照群として機能し、サービス名とバッチプロセッサのみを含みます。一方、最適化済みパイプラインには具体的なフィルタと変換処理が適用されます。

最適化済みパイプラインでは、プロセッサが高カーディナリティの次元と冗長なコンテンツを削除します。例えば、ツール出力からの完全なファイル内容はスパンとログから除去され、必須のメタデータのみが残ります。メトリクスは事前集約されたり、カーディナリティ爆発を引き起こすセッションごとの識別子を削除するために調整されたりします。これにより、バックエンドに送信されるデータは軽量になり、実行可能なインサイトに焦点を当てたものとなります。

設定にはGrafana LGTMを使用し、両方のパイプラインの差異を可視化します。ダッシュボードでは、カーディナリティ、毎分のバイト数、レコード数を並べて比較します。本番環境では、生データ用パイプラインは偶発的な詳細デバッグのためにオブジェクトストレージへ向けるか、完全に破棄し、最適化済みパイプラインが主要な監視バックエンドへ供給するように構成するのが一般的です。

主な詳細

• Claude Codeの単一の実行において、すべてのコンテンツフラグを有効にした場合、181件のテレメトリレコードと289 KBのJSONが生成されました。
• デフォルトのメトリクスにはsession.idやuser.emailといった高カーディナリティの属性が含まれており、25セッションにおける8つのメトリクスだけで300の時系列が作成されます。
• ツールコンテンツはトレースとログの両方で重複しており、ファイル内容はスパンイベントおよびログ属性として保存されています。
• 最適化済みパイプラインでは、セッションごとの次元を削除することで、メトリクスの時系列数を300から12に削減します。
• 最適化を推進する6つの主要な質問は以下の通りです：モデルあたりのコスト、トークン使用量、ツール失敗率、編集拒否、レイテンシ、エラー。
• otelcol_exporter_enqueue_size_bytes メトリクスは、送信キューが有効な詳細レベルでのみ存在します。

なぜ重要なのか

AIエージェントを用いて構築を行うエンジニアリングチームにとって、テレメトリコストは適切に管理されなければ急速に制御不能になる可能性があります。メトリクスにおける高カーディナリティは、観測性プラットフォームでのストレージおよびクエリコストを増加させ、大きなトレースおよびログペイロードは帯域幅とインデックスリソースを消費します。コレクターレベルでこのデータをフィルタリングすることで、組織はすべてのプロンプトやファイル差分を保存するための prohibitive（法外な）費用をかけることなく、包括的な可視性を維持できます。

さらに、特定の運用上の質問に焦点を当てることで、開発者やSREのための信号対雑音比（SN比）が向上します。テキストの壁を掘り返す代わりに、チームはタイプ別トークン使用量、ツール成功率、レイテンシなど、エージェントのパフォーマンスを示す明確な指標を監視できます。生のデータ収集からターゲットを絞った観測性へのこの転換により、トラブルシューティングの高速化とより効果的なコスト管理が可能になります。

実施できること

• AIエージェントのパフォーマンスについてチームが必要とする回答を持つ6つの主要な質問（例：モデルあたりのコスト、ツール失敗率）を特定します。
• OpenTelemetry Collectorを設定し、AIエージェントのテレメトリ用に生データ用と最適化済みの別々のパイプラインを作成します。
• セッションIDやユーザーメールなどの高カーディナリティ属性をメトリクスから削除し、時系列の爆発を防ぎます。
• トレーススパンとログから完全なファイル内容とプロンプトを除去し、必須のメタデータとエラー情報のみを保持します。
• バックエンドに送信されるデータポイント数を削減するため、可能な限り事前集約されたメトリクスを使用します。
• 生データストリームと最適化済みストリームの差異を可視化し、ストレージ節約を検証するとともに、重要なデータが失われていないことを確認します。