ClaudeのOpenTelemetryでプロンプトと応答を送るか — Full contentの選び方

Claude APIのOpenTelemetry出力は、既定ではプロンプトも応答も送りません。送るかどうかを決めるのがcontent modeで、選択肢はMetadata only(SDKでは metadata_only)とFull content(同じく content)の2つです。迷ったらMetadata onlyのまま始め、障害調査や評価データの作成で本文が要る段階になってからFull contentに上げる、という順序で足ります。

この設定は、Consoleで追加する送信先(destination)と、SDKのクライアントのそれぞれに別々に持ちます。同じ組織でも、API側はMetadata only、SDK側はFull contentという組み合わせが作れます。OpenTelemetry出力自体はベータ機能です。

Metadata onlyとFull contentでspanに入るもの

Metadata onlyのspanには、識別子・所要時間・ステータス・トークン数が入ります。加えて、エージェントやツールの名前と説明、MCPサーバー名のように、利用者が自分で決めた文字列も含まれます。プロンプトと応答の本文は入りません。

Full contentは、上の内容にプロンプトと応答を足します。spanリファレンスでContentのバッジが付く属性が、Full contentのときだけ現れるものです。

このほか gen_ai.request.stop_sequences と、Managed Agentsの成果評価spanにある anthropic.session.outcome_evaluation.explanation もContent扱いです。

Full contentで得られるのは、失敗や遅延の理由をspanから読めること、会話をそのまま読めること、実トラフィックから評価データを作れることです。裏返せば、Metadata onlyでも「どのリクエストが遅い、いくらかかった」までは追えます。本文が要らない用途なら、Full contentに上げる理由はありません。

本文を送る前に確認する3つの前提

送信先の保管と閲覧権限はこちらの管理下に移る

spanが送信先に届いた後、データは選んだ観測基盤が自身の保持期間とアクセス制御で保管します。Anthropic側の設定とは別の管理になります。Full contentにすると、プロンプトに含まれる個人情報や社内文書が、観測基盤のダッシュボードを見られる全員に見える状態になります。送信先の閲覧権限と保持期間が組織の要件に合うかを、切り替えの前に確かめる作業になります。

SDKの会話IDはどちらのモードでも送られる

SDKの conversation_id に渡した値は gen_ai.conversation.id に書かれ、Metadata onlyでも出力されます。個人情報や秘密は入れないことが前提です。content modeを絞っても、ここから漏れる設計だと意味がありません。

Anthropicの安全機構が止めた内容はspanにも出ない

応答の一部がAnthropicの安全対策(safeguards)で止められた場合、API側のspanにもその部分は含まれません。spanは「モデルが生成したものすべて」の記録ではありません。

HIPAA・FERPA・K-12の組織ではFull contentにしても本文は出ない

組織がAnthropicとの間でHIPAA・FERPA・K-12のいずれかのデータ取り扱い制限を持っている場合、送信先はcontent modeの設定にかかわらずメタデータだけを送ります。Consoleの設定をFull contentにしても、本文を持たないspanが届きます。

API側ドキュメントのトラブルシューティング表にも「送信先はFull contentなのに本文がない」という症状があり、確認先として組織のHIPAA・FERPA・K-12制限が挙がっています。

もうひとつ見落としやすい点があります。この制限が止めるのはAPI側の送信先だけで、SDKのspanは影響を受けません。SDKは自分の環境から自分のエクスポーターへ直接送るためです。HIPAA対象の組織でSDKのクライアントを content にすると、本文が観測基盤へ届きます。送信先で本文を止めたつもりでも、SDK側の設定が別に残っていれば抜け道になります。SDKのcontent modeは、環境変数 ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE かコードの設定で確認できます。

ZDRとは両立する(Managed Agentsを除く)

ゼロデータ保持(ZDR)の契約があっても、Full contentは使えます。Messages APIのリクエストでは、APIはspanに載せる内容を、送信先に届けるまでメモリ上にだけ置きます。データ保持の一覧表でも、OpenTelemetry出力はZDR対象の機能として載っています。条件は2つです。

• spanのZDR適格性は、そのspanを生んだ機能と同じになります。ZDRの対象外の機能が生んだspanには、ZDRの保証は及びません
• Claude Managed AgentsはZDRの対象外で、OpenTelemetryを使ってもデータ保持の扱いは変わりません

注意したいのは、ZDRが守るのはAnthropic側の保持だけだという点です。届いた後のspanは送信先の保持ルールに従うので、「ZDR契約だから本文を送っても残らない」とは言えません。残るかどうかは観測基盤の設定で決まります。

1 span 0.75 MBの上限と、1 MB制限の観測基盤

Full contentのspanが運ぶ本文は、既定で1 spanあたり0.75 MBまでです。英語のテキストなら200kトークンのコンテキストウィンドウ1つ分が収まり、多くの観測基盤やプロキシが持つ1 MBのリクエスト上限を下回る値として選ばれています。Consoleで観測基盤をProviderに選んだ場合は、その基盤が受け付ける上限が自動で入ります。

上限を超えた本文は、SDKかAPIが縮めたうえで anthropic.content.truncated を true にします。縮め方はspanの種類で違います。

• リクエストspan: システムプロンプトと、古いメッセージから順に落とす
• ツールspan: 実行結果のブロックを末尾から落とす
• 画像とドキュメント: 中身は出ず、種類だけが残る

つまり長い会話では、一番知りたい冒頭の指示が先に消えます。調査で「システムプロンプトがspanにない」と気づいたら、まず anthropic.content.truncated を見てください。

上限を変える場面は2つです。

設定の場所は次のとおりです。SDKでは traces.max_content_bytes(TypeScript・Java・PHPは traces.maxContentBytes、環境変数は ANTHROPIC_OPEN_TELEMETRY_TRACES_MAX_CONTENT_BYTES)。Consoleでは、content modeをFull contentにしたうえで、Advanced settingsのMaximum content size in MBです。空欄にすると、APIが送れる範囲で上限なしになります。

送信先をAdmin APIで作るときの書き方

Consoleの代わりにAdmin APIでも送信先を作れます。管理者ロールのサインインかAdmin APIキーが要ります。Metadata onlyで作る例は次のとおりです。

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/organizations/telemetry_destinations" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: telemetry-destinations-2026-08-11" \
  -H "content-type: application/json" \
  -d '{
    "endpoint_url": "https://gateway.example.com/otlp",
    "headers": {"authorization": "Bearer YOUR_KEY"},
    "traces": {"content_mode": "metadata_only"},
    "workspaces": {"type": "all"}
  }'

Full contentにするなら content_mode を content に変え、上限は traces.max_content_bytes にバイト数で指定します。作成後はConsoleのTestで anthropic.test spanが届くか確かめられます。

どちらを選ぶか

本番はMetadata only、検証用のワークスペースだけFull contentという分け方が現実的です。送信先はワークスペース単位で対象を選べる(All・Selected・All except)ので、1つの組織の中で、本番ワークスペースはMetadata onlyの送信先、検証ワークスペースはFull contentの送信先、と分けられます。

使用量の集計はspanでなくUsage APIで行う

spanの配信はベストエフォートで、届く前に失われることがあります。同じspanが重複して届くこともあり、重複の除去にはトレースIDとスパンIDを使います。呼び出し側がリクエストの traceparent ヘッダーでsampledフラグを落とせば、そのリクエストのspanは出ません。APIキーごとの使用量を正確に追いたい場合は、spanではなくUsage APIを使います。

Claude Code・Agent SDK・Coworkの監視は別の仕組みです。それぞれの手順はAgent SDKをOpenTelemetryで可観測化する実装ガイド、CoworkのOpenTelemetry監視設定、Claude CodeのOTEL_LOG_TOOL_DETAILSとTOOL_CONTENTで見える範囲にあります。OpenTelemetryとCompliance APIの役割の違いはClaude Compliance APIとはで比較しています。

まとめ

本文を送るかどうかは、観測基盤の保管と閲覧権限を許せるかで決まります。ZDRやHIPAAの契約は、API側の送信先の振る舞いを変えるだけで、観測基盤に届いた後の本文は守りません。まずMetadata onlyで配線を通し、本文が要る環境だけをFull contentと専用の送信先に分けるのが、後から戻しやすい順序です。