Claudeエージェントの動作をOpenTelemetryのトレースで監視可能に

Claudeエージェントの動きをトレースで追えるように

Anthropicは10月14日、Claude PlatformでOpenTelemetry（OTel）のトレースを外部の監視ツールへ送信する機能を公開ベータにしました。 エージェントがどの順に何をしたかを、1ステップずつ監視ツールで追えます。

Anthropicは、エージェントに広い権限を任せる前にこの機能でエージェントの動きを把握するよう勧めています。モデル呼び出しやツールの使用、MCPサーバーの呼び出しをトレースで見て、信頼できるとわかってから権限を広げるという順番です。

対象はManaged Agents・API・SDKの3つ

トレースを出せるのは、Claude Managed Agents・Messages API・Claude SDKの3つです。OpenTelemetryは、多くの監視ツールが対応している共通の規格です。トレースは1つのリクエストがシステムを通った記録の全体で、その中のモデル呼び出しやツールの使用といった1ステップをスパンと呼びます。

Managed AgentsとMessages APIは、管理者がClaude Consoleで送信先を追加すると、アプリのコードを変えずに監視ツールへトレースが届きます。 Claude SDKは、Python・TypeScript・C#・Go・Java・PHP・Rubyの7言語に対応しています。アプリ側でトレーサープロバイダーを登録すると、SDKがトレースを書き出す仕組みです。

SDKとAPIでは、トレースに記録される範囲が次のように異なります。設定するのもSDKは開発者、APIは管理者です。

SDKのトレースとAPIのトレースに記録される範囲

記録の対象	SDKのトレース	APIのトレース
Messages API・Sessions APIのリクエストとトークン使用量	記録される	記録される
リクエスト内の各モデル実行	記録されない	記録される
Managed Agentsのターン	記録されない	記録される
APIが実行するサーバー側のツール	記録されない	記録される
tool runnerや独自のサンドボックスで動作するツール	記録される	記録されない
設定する人	開発者（コードで設定）	管理者（Consoleで設定）

両方を設定すると、1つのリクエストについてSDK側とAPI側のスパンが1本のトレースにまとまります。Claude CodeやCoworkのトレースをすでに送信している監視ツールなら、Claude Platformのエージェントも同じ画面で見ることができるとのこと。なお、Claude Code・Agent SDK・Coworkの監視は別の仕組みで、設定の方法も別のドキュメントで説明されています。

エージェントのどんな動作がトレースに含まれるか

管理者が送信先を追加すると、エージェントのターン・モデル呼び出し・ツールの使用が、標準形式のOpenTelemetryトレースとして監視ツールに届きます。 それぞれのスパンには、レイテンシとトークン数とIDが含まれます。

レイテンシとは処理にかかった時間のこと。遅いステップを見分けるときの目印になる値です。

トレースの属性は、OpenTelemetryが生成AI向けに定めた共通の規約（GenAIセマンティック規約）に沿っています。したがって、Claudeのデータと他社モデルのデータを同じ監視ツールやダッシュボードで使うことができます。

Claudeのトレースはどの監視ツールへ送信できるか

公式記事が名前を出している送信先は、DatadogやLangfuseなど12社の監視ツールです。 12社のほかにも、OpenTelemetryのデータを受け取る標準の受け口を持つツールなら送信できます。

エンドポイントとはデータを受け付けるURLのこと。OpenTelemetryのデータを受け取るものは、OTLPエンドポイントと呼ばれます。

公式記事は、送信先を用途別に3つに分けて紹介しました。Langfuseは、2つ目の評価に使うツールとして紹介されています。分け方は次のとおりです。

公式記事が紹介する送信先と用途

用途	送信先
ログ・メトリクスと同じ画面で、遅いステップや失敗したステップの出どころを探す	Grafana Cloud・Honeycomb・Sentry・Splunk
実際のトレースから評価を作り、品質の問題と変更の効果を測る	Arize AI・Braintrust・Datadog・Langfuse・LangSmith・New Relic・PostHog
チームごとのトークン使用量を見て、普段と異なる動きを目立たせる	Databricks（Unity Gateway）

3つ目のDatabricks Unity Gatewayは、プラットフォームやセキュリティの担当者向けとして紹介されています。トークンの使用量をチームごとに確認でき、普段と異なる使われ方があれば警告として表示できます。

導入企業はトレースをどのように活用しているか

公式記事には、トレースを品質改善や監査への説明に使う企業の声が掲載されています。会計の業務にエージェントを使う企業のAnkush Sharma氏（インフラ責任者）は、モデル呼び出しを仕訳などの業務フローと同じトレースに記録しています。したがって監査人に「エージェントが何をなぜしたか」と聞かれても、1本の時系列で答えられるとのこと。

ロボット開発チーム向けのエージェントを作るFoxgloveは、エージェントのやり取りをPostHogで製品の利用データと合わせて分析しています。Rampが社内で運用する「Reflect」はLangfuseのトレースを採点して繰り返し発生する失敗を見つけ、修正案を出す仕組みです。

ただし、Rampが公表した「一部のエージェントでトークン使用量を10〜20%減らし、セッションを30%速くした」という数値は、今回の機能が出る前にReflectで得た成果です。RampのDavid Traina氏はこの数値に続けて、OpenTelemetryの送出によって、改善の仕組みへ追加の手順なしでデータを直接送信できるようになると述べています。

使い方は管理者がConsoleで送信先を追加するだけ

APIのトレースを受け取るには、Claude Consoleで組織の管理者が送信先を1つ追加します。 送信先の追加や変更は管理者（admin）のロールに限られ、開発者（developer）のロールは閲覧だけです。事前に用意するものは次の3つです。

• Claude Consoleでの管理者ロール
• 監視ツール側の受け口（OTLP/HTTPのエンドポイント）
• 受け口の認証情報（APIキーなど）

受け口は、ポート443を使うHTTPSのURLでprotobuf形式のデータを受け付ける必要があります。自前でOpenTelemetry Collectorを運用している場合、Collectorの受け口はデフォルトでポート4318です。443で受ける設定に変更するか、前段のロードバランサーやリバースプロキシを経由させる構成にしてください。

送信先に入れる情報は次のとおりです。監視ツールを一覧から選ぶと、受け口URLの代わりにAPIキーなどを入力する画面に変わります。

• 監視ツールの種類（一覧に無ければCustom）と、受け口のURL
• 認証キーを入れるリクエストヘッダー
• 送信する中身の範囲（Content mode）
• 対象のワークスペース（すべて／選んだものだけ／選んだもの以外）

保存したらテスト用のスパンを送信し、Consoleの表示がHealthyに変わるのを待ちます。表示が変わるまでの目安は約1分です。届いたトレースは、監視ツール側でservice.name = claude-platformの条件で検索すると見つかります。

送信先は、Consoleの代わりにAdmin APIやCLIで追加することもできます。自社アプリのトレース配下にAPIのスパンを加えたい場合は、自社のスパン内からClaude SDKを呼び出してください。SDKがW3Cのtraceparentヘッダーにトレースの情報を書き込み、APIはこのヘッダーを読んで同じトレースにスパンを追加します。

デフォルトではプロンプトを送信せずメタデータだけ

送信する中身はデフォルトで「Metadata only」となり、プロンプトと応答は含まれません。 送信対象はID・時刻・ステータス・トークン数と、エージェントやツールの名前・説明、MCPサーバーの名前など、ユーザーが指定した文字列だけです。

送信先を「Full content」にすると、プロンプトと応答も送信されます。失敗や遅さの理由を調べるときや、会話の全体を読むときに使う設定です。実際のトレースから評価を作る場合にも、Full contentを選びます。

Full contentで送信した中身は、Anthropicの外にある監視ツールで、そのツールのアクセス権と保存期間の設定に従って保管されます。データの保管には次の条件があります。

• AnthropicとのあいだにHIPAA・FERPA・K-12のデータ取り扱い制限がある組織では、設定にかかわらずメタデータだけが送信される（SDKのスパンは対象外）。
• Anthropic側にデータを残さない契約（ゼロデータ保持）でも、Messages APIならFull contentを使うことができる。Managed Agentsにはゼロデータ保持が適用されず、OpenTelemetryを使っても保持期間はこれまでと同じ。
• Full contentの中身は、1スパンあたりデフォルトで0.75MBまで。英文なら20万トークンのコンテキストが収まる大きさで、超えた分はシステムプロンプトと古いメッセージから先に削られる。100万トークンのコンテキストを丸ごと送信するには約4MBが必要。

トレースは届く保証がなく、トークンの二重計上もある

2026年10月時点でOpenTelemetryの送出はベータ版で、送信したスパンがすべて届く保証はありません。 スパンは途中で失われることがあり、失われたものは再送されません。

逆に、同じスパンが2回以上届くこともあります。重複は、trace IDとspan IDの組み合わせで取り除けます。

SDKのスパンとAPIのスパンを両方受け取ると、トークン数を合計したときに同じリクエストが2回カウントされます。合計するときは、リクエストごとにどちらか一方だけを使います。

SDKのスパンもAPIのスパンも名前はanthropic.messages.createで、種類はSDK側がCLIENT、API側がSERVERです。一方だけを使うときはこの種類で見分けることができます。

このほか、24時間にわたって送信がすべて失敗した送信先は自動で無効になります。送信先は1組織あたり10件までです。OpenTelemetry送出そのものの料金について、Anthropicは公式記事でもドキュメントでも明らかにしていません。

同じ時期に出たManaged Agentsなどの更新

リリースノートを見ると、10月の前半にはManaged Agentsなどの更新がほかにも出ています。 いずれもOpenTelemetryの送信とは別の更新です。

10月前半のClaude Platformの主な更新

日付	更新の中身
10月14日	Managed Agentsのスケジュールデプロイが、Claude Platform on AWSで利用可能に
10月9日	Managed AgentsでDynamic Workflows（動的ワークフロー）がベータに
10月7日	Claude Sonnet 5.5のプロンプトキャッシュ読み取りの料金を、それまでの半額に値下げ
10月7日	Claude MaxとTeamのプランに、毎月のAPIクレジットが付与されるように
10月7日	Managed Agentsのweb_fetchが、セッションにすでに出てきたURLだけを取得するように

10月9日のDynamic Workflowsは、多数のエージェントを並列に動作させる仕組みです。Managed Agentsのエージェントがプログラムを書き、そのプログラムが複数のエージェントを段階ごとに動作させて、結果を1つに統合する流れです。

動きは監視ツールで追い、使用量の集計はUsage APIで

トレースはエージェントの動きを追うための記録であって、使用量を漏れなくカウントする記録にはなりません。 欠けることもあれば重なることもあり、SDKとAPIを両方受けると数え方を選ぶ必要まで出てくるからです。

一方で、プロンプトを送信しないデフォルトの設定でも、所要時間とステータスとトークン数は届きます。遅いステップや失敗したステップを探す目的なら、プロンプトと応答を外部に送信しないままトレースを使うことができます。APIキーごとの使用量を追う場合や、流出したキーを見つける場合のように1件も落とせない集計は、公式ドキュメントの推奨どおりUsage APIでカウントするのが確実です。