Claude PlatformのOpenTelemetryトレースがベータ公開に

Claude Platform上で動くエージェントのトレースを、OpenTelemetry(OTel)形式で手元の観測基盤に送れるようになりました。対象はClaude Managed Agents、Messages API、Anthropic SDKの3つで、2026年10月14日にパブリックベータとして発表されています。

エージェントに権限を広げるかどうかは、モデル呼び出しとツール実行の記録を読んでから決める。この順序が前提です。

要点

• Managed Agents、Messages API、Anthropic SDKのトレースをOTelで任意のツールへ送れる
• トレースはOpenTelemetryのGenAIセマンティック規約に沿うため、他社モデルのデータと同じダッシュボードに並べられる
• Managed AgentsとMessages APIはClaude Consoleで送信先を足す(Claude PlatformとClaude Platform on AWSのみ)。SDKはアプリ側のexporterから送る
• 連携先の例はGrafana Cloud、Honeycomb、Datadog、Langfuseなど。標準のOTLPエンドポイントなら他のツールも使える
• 状態はベータ。SDKのオプションやスパンの形が変わる可能性が明記されている

設定の場所は、何を追いたいかで決まる

「Consoleで送信先を足す」と「SDKは自動でエクスポートする」の2経路は、見えるものが違います。

ドキュメントの比較表から、差が出る行だけを抜き出します。API側はClaude APIがスパンを出すためコード変更が要らず、SDK側はアプリ内のSDKが出すため権限が要りません。

両方を設定すると、1つのリクエストのSDKスパンとAPIスパンが1本のトレースにつながります。どちらを先に入れるかの判断材料は、SDK tracingとAPI tracingの比較に表でまとめています。

Consoleで送信先を足す流れ

Managed AgentsとMessages APIは、Claude Consoleの「OpenTelemetry settings」ページで送信先を登録します。追加は組織の管理者ロールだけで、開発者ロールは閲覧のみです。エンドポイントはHTTPSの443番ポートでprotobuf形式のOTLP/HTTPを受けるURLにし、末尾に/v1/tracesは付けません。APIが自動で足します。Admin APIとCLIからも登録できます。

画面の手順はConsoleで送信先を登録する手順にあります。

送る内容は2段階で、既定は控えめ

内容モードの既定はメタデータのみで、識別子、所要時間、ステータス、トークン数、エージェントやツールの名前が入ります。Full contentを選ぶと、モデルへのプロンプトと応答も観測基盤に渡ります。使い分けはメタデータのみで送る設定で扱っています。

Full contentのスパンは、既定で1つあたり最大0.75MBです。超えるとシステムプロンプトと古いメッセージから切り詰められ、anthropic.content.truncatedがtrueになります。観測基盤に渡った内容は基盤側のアクセス権と保持期間の規則で保管されるため、社内のデータ取り扱い規程と合うかは送信先ごとに見ておく必要があります。

連携先は16製品。発表本文の12製品より多い

連携先は用途で3つに分かれます。

連携先

発表が示す3つの使い道

• 既存の監視と並べて直す

  Grafana Cloud、Honeycomb、Sentry、Splunkでは、ログやメトリクスの隣にエージェントのトレースが並びます。遅い、または失敗したステップがどのサービス由来かを追えます。

• 本番データで改善する

  Arize AI、Braintrust、Datadog、Langfuse、LangSmith、New Relic、PostHogが対象です。実トレースを評価に回し、変更が効いたかを測ります。

• 組織の利用を把握する

  Databricks Unity Gatewayへ送ると、チーム別のトークン使用量や不審な動きをプラットフォーム側とセキュリティ側が見られます。

ドキュメントのパートナー一覧には、これに加えてDynatrace、Elastic、Pydantic Logfire、Snowflakeが載っています。合計で16製品です。OTLPを受けるエンドポイントなら、一覧にない製品にも送れます。

Claude CodeとCowork、Agent SDKは別の経路

発表の位置づけは「Claude CodeやCoworkのトレースをすでに観測ツールへ送っているなら、Claude Platformで作ったエージェントも同じ場所に出せる」です。ドキュメントでは、Claude Code、Agent SDK、Coworkの監視は別のページに分かれています。今回のConsole送信先とSDK tracingは、API呼び出しとManaged Agentsのセッションが対象です。

Claude Code側のトレースは、LangfuseプラグインでClaude Codeのセッションを追う手順のように、プラグイン経由でも取れます。Claude Codeと自作エージェントの両方を1つの観測基盤に集める構成が、今回の更新で現実的になりました。

Rampのトークン10〜20%削減は、OTel単体の効果ではない

4社のコメントは、使い道が2つの方向に割れています。

• 改善ループに繋ぐ: FoxgloveはPostHogで、ロボット開発向けエージェントの挙動を製品の利用データと並べて分析する。RampはLangfuseのトレースを採点して繰り返す失敗を探す社内システム「Reflect」を持ち、一部のエージェントでトークン使用量を10〜20%減らし、セッションを30%速くしたと述べる。Sterling Labsは24時間動く市場分析エージェントのトレースをLangfuseへ流している
• 説明責任に備える: 経理業務のエージェントを動かす企業のインフラ責任者は、モデル呼び出しを照合や仕訳のワークフローと同じトレースに載せ、監査で「何をなぜしたか」を1本のタイムラインで答えられるとする。Grafana Cloudを使っている

Rampの数字は、Reflectという改善の仕組み全体の成果です。OTel出力そのものの効果を示す値ではありません。トレースが「入力」で、削減はその先の分析と修正から生まれています。

導入前に押さえる制約

ドキュメントには、発表の本文に出てこない条件がいくつもあります。

• ベータである: SDKのオプション、環境変数、スパンの名前や属性は、新しいバージョンで変わる可能性がある。OpenTelemetryは全モデルでベータ。ただしConsoleの送信先(API tracing)が使えるのはClaude PlatformとClaude Platform on AWSだけで、Amazon Bedrock・Google Cloud・Microsoft Foundry経由の利用ではSDK tracingを使う。ダッシュボードやクエリを作るなら、SDKのバージョンを固定して更新時期を自分で選ぶよう書かれている
• 配信は保証されない: スパンは少なくとも1回届くが重複することがある。一方で配信前に失われることがあり、APIは再送できない。重複はtrace IDとspan IDで除く。ドキュメントは、エクスポートされたスパンをAPI利用量の完全な記録とは位置づけていない
• 自動停止がある: 送信先がリダイレクト(3xx)を返す、または24時間すべての配信が失敗すると、その送信先は無効になる。無効の間のスパンは捨てられ、再有効化しても送り直されない
• ゼロデータ保持との関係: Messages APIはFull contentのままゼロデータ保持を使える。Managed Agentsはゼロデータ保持の対象外である
• 規制対象の組織: HIPAA、FERPA、K-12のデータ取り扱い制限がある組織では、内容モードに関係なく送信先にはメタデータだけが出る。SDKのスパンは影響を受けない
• 上限: 1組織あたり送信先は無効のものを含め10個まで。リクエストヘッダーは1送信先に20個まで

トークン数の集計には注意点があります。1つのリクエストにSDKスパンとAPIスパンの両方があるとき、同じanthropic.messages.createという名前のスパンが2つ出ます。種別がCLIENTかSERVERかで見分け、どちらか片方の系統だけを足します。属性の詳しい見方はスパン属性リファレンスにあります。

「自動でエクスポート」は、設定ゼロの意味ではない

発表の「Anthropic SDKsは自動でトレースをエクスポートする」という書き方は、読み方に幅があります。SDKのドキュメントでは、SDKがアプリ内でスパンを出し、アプリが登録したtracer providerとOTLP exporterが観測基盤へ送る構成です。計測コードを自分で書かなくてよい、という意味では自動です。exporterの登録と宛先の設定は、アプリ側の作業として残ります。手順はAnthropic SDKのOpenTelemetry設定にあります。

もう1点、Console側の設定は組織単位で効きます。送信先が対象とするワークスペースで起きた全リクエストのスパンが流れます。開発用ワークスペースの試行錯誤が、本番と同じダッシュボードに混ざる点は、導入時に決めておきたい項目です。

送信先ごとにワークスペースと内容モードを選べるので、本番の送信先だけをFull contentにし、開発の送信先はメタデータのみにする分け方ができます。

まとめ

まずSDK tracingで手元から試し、Managed Agentsを本番に載せる段階で管理者にAPI側の送信先を頼む順序なら、権限の壁にぶつかりません。ターン単位のスパンが見えるのはAPI側だけで、Managed Agentsはゼロデータ保持の対象外です。スパンは利用量の完全な記録にならないため、キーごとの利用量はUsage and Cost Analytics APIで追います。

セッションの全件監査が目的なら、トレースとは別にManaged Agentsのオフラインレビューという手もあります。