Engineering · 統制

エージェントが壊れた場所を特定する — OpenTelemetryトレーシングとエージェント可観測性の設計

2026年10月14日、AnthropicはClaudeプラットフォームへのOpenTelemetryトレーシング（公開ベータ）を発表。エージェントの多段階実行を「セッション→ターン→モデル実行/ツール呼び出し」の階層スパンで可視化し、Datadog・Grafana等の既存監視スタックで追えるようになりました（@ClaudeDevs、2026-10-14）。

要点

✓Anthropicが2026年10月14日にClaudeプラットフォームのOpenTelemetryトレーシングを公開ベータとして発表（Messages API・Managed Agents・Claude SDK対応）。@ClaudeDevs
✓Managed Agentsのスパン階層：Session Request→Turn→{Model Run・Tool Call・Outcome Eval}。どのターンのどの操作で問題が起きたかを構造的に追える
✓デフォルトは「メタデータのみ」（duration・status・トークン数・モデル・ツール名）。full contentモードに切り替えるとプロンプト・レスポンス・ツールI/Oも記録——センシティブデータが含まれる可能性があるため保存先の管理が重要
✓OpenTelemetry gen_ai セマンティック規約を採用。Datadog・Honeycomb・Grafana・Langfuse・Braintrust・Arize・Sentry・カスタムOTLPエンドポイントに接続可能
✓Managed AgentsはZero Data Retentionの対象外——OpenTelemetryを導入してもこの制限は変わらない
✓コンプライアンス目的の監査記録（Compliance API）とエンジニアリング目的のデバッグトレーシング（OpenTelemetry）は用途が違う。設計段階から管理先を分けることを推奨

なぜエージェントは「デバッグが難しい」のか

通常のWebサービスのデバッグは比較的明快です。HTTPリクエストが来て、ビジネスロジックが実行されて、レスポンスが返る——どこで何が起きたかをアクセスログやエラーログで追えます。

AIエージェントは違います。エージェントは一度の実行で、複数のモデル呼び出し・複数のツール実行・サブエージェントへの委譲を繰り返します。しかも出力が非決定的で、同じ入力でも動きが変わります。「どのステップで何が起きたか」を後から追う仕組みがなければ、失敗した理由を特定するのは困難です。

Anthropicは自社のManaged Agentsの初期設計を振り返り、WebSocketのイベントストリームは「どこで失敗が起きたか教えてくれなかった」と述べています（anthropic.com/engineering/managed-agents）。可観測性の欠如は、エージェント基盤を設計する上で実際にぶつかる問題です。

スパン階層が「エージェントの行動ログ」になる

Managed Agentsのスパン構造（Anthropic、2026-10-14）。Session Requestスパンをルートに、ターンごとのTurnスパン、その中にModel Run・Tool Call・Outcome Evalがネストされる。親子関係で「どのターンのどの操作で何ミリ秒かかったか」を構造的に追える。

Anthropicの実装 — OpenTelemetryトレーシング公開ベータ（2026-10-14）

2026年10月14日、AnthropicはClaudeプラットフォームのOpenTelemetryトレーシングを公開ベータとして発表しました（@ClaudeDevs、2026-10-14。二次報道：tokenpost.com・superpowerdaily.com・techcityauthority.com）。対象はMessages API・Claude Managed Agents・Claude SDKの3つです。

設定方法：管理者がClaude Consoleにエクスポート先を追加するだけで、アプリケーションのコード変更は不要です（Messages API・Managed Agentsのサーバーサイドトレーシング。SDK経由のトレーシングは別途SDKトレーサーの設定が必要）。

対応する接続先：Datadog・Honeycomb・Grafana・Langfuse・Braintrust・Arize・Sentry、またはカスタムのOTLPエンドポイント。既存の監視スタックにそのままつなげます。

スパンはOpenTelemetryのgen_ai セマンティック規約（OpenTelemetry Semantic Conventions、GenAI Working Group。CNCF）に準拠しています。これにより、AI向けの標準属性名でデータが記録され、異なるプロバイダのトレースを一つの監視スタックで横断的に扱いやすくなります。

何を記録するか：デフォルトとfull contentのトレードオフ

デフォルト（メタデータのみ）はduration・status・トークン数・モデル・ツール名のみ。full contentモードに切り替えるとプロンプト・レスポンス・ツールI/Oも含まれる。後者はトレース先のアクセス管理と保存ポリシーが重要になる（Anthropic、2026-10-14）。

(B) 設計上の落とし穴：センシティブデータの意図しない記録

Full contentモードは、「どの入力でモデルが予期せぬ出力をしたか」のデバッグに強力です。しかし、エージェントが個人情報・機密文書・認証トークンなどを扱うタスクを実行している場合、プロンプトやツール入出力にその情報が含まれる可能性があります。

Anthropicは「full contentトレースにはセンシティブデータが含まれる可能性があるため、保存先のアクセス管理と保存期間が重要になる」と注意しています（Anthropic、2026-10。二次報道による）。エージェントでfull contentモードを使う場合の設計考慮点：

トレース保存先へのアクセス権限の分離（開発者・SREに絞る）
保存期間のポリシー（監査要件に合わせてGrafanaやDatadogの保存期間を設定）
PII除去：ツール出力の一部をログに出さない処理を挟む設計
デフォルトはメタデータのみで運用し、デバッグが必要な場面だけfull contentに切り替える

(A) agens の設計との関係 / (C) 今後の方向性

(A) agens はRBAC・SSO/SAML/OIDC・監査ログ・操作の巻き戻しを実装済みです。これらはエージェントの操作を誰が許可し、何が行われ、問題発生時に戻せることを担保します。OpenTelemetryトレーシングはこれと補完的な位置づけです——「誰が何をしたか（監査）」に加え、「どのスパンで何ミリ秒かかったか・どこでエラーが出たか（デバッグ・性能把握）」の可視性を既存の監視スタックにもたらします。(C) トレースデータをエージェントの自動評価（evals）と組み合わせ、失敗パターンの自動検出・改善サイクルを回す設計は今後の方向性の一つです。

(B) コンプライアンス記録とデバッグトレーシングは別物

可観測性の設計でよく混同されるのが、「コンプライアンス目的の監査記録」と「エンジニアリング目的のデバッグトレーシング」です。両者は目的も保存先も設計上の要件が違います。

コンプライアンス記録は「誰が・いつ・何の操作を承認したか・結果はどうだったか」を改ざん困難な形で残すことが目的で、保存期間は法令・業界規制に合わせ数年単位になります。Anthropicが提供するCompliance API（セッション転写）はこちらの用途向けです。

OpenTelemetryトレーシングはエンジニアリングチームが「今のシステムがどう動いているか」を把握するためのものです。レイテンシの異常検知、失敗ターンの特定、ツールやモデルごとの性能比較——このような運用・改善サイクルを支えます。保存期間は数週間〜数ヶ月程度が典型です。両者を混同しないよう、設計段階から用途別に管理先を分けることが推奨されます。

(B) なぜOpenTelemetryが標準になりつつあるか

OpenTelemetryはCloud Native Computing Foundation（CNCF）のプロジェクトで、ベンダー中立の観測可能性標準を定義します。分散トレーシング・メトリクス・ログの三本柱を統一したAPIとSDKで扱えることが強みで、AI/LLMワークロードを含む多くのプラットフォームに採用が広がっています。

AIシステム向けにはgen_ai セマンティック規約が整備されています。gen_ai.system（AIプロバイダ）・gen_ai.request.model・gen_ai.usage.input_tokensといった標準属性名を使うことで、Anthropic・OpenAI・Googleなど異なるプロバイダのトレースを一つの監視スタックで横断的に扱えます。これはマルチプロバイダ構成や、モデルを切り替えたときの比較分析に効いてきます。

AnthropicがOpenTelemetryを採用した設計思想は「エージェント基盤の可観測性を『AIの特殊対応』ではなく、既存のエンジニアリング組織の標準ツール・プロセスの中に収める」というものです。Datadog等の汎用APMも、Langfuse・Braintrust等のLLM特化観測ツールも、同じ接続先として使えます。

🛡 一次資料と注記

本記事の事実はすべて一次・二次資料に基づきます：@ClaudeDevs（Anthropic公式開発者アカウント）ポスト（2026-10-14）・tokenpost.com・techcityauthority.com・superpowerdaily.com等の二次報道（2026-10-14）・anthropic.com/engineering/managed-agents（Anthropic Engineering）。スパン階層・対応バックエンド・full contentの注意事項は上記資料からの引用です。agens の実績値は含みません。Managed AgentsのZero Data Retention対象外はOpenTelemetry対応前から変わりません。公開ベータのため、仕様・GA時期は変更の可能性があります。

よくある質問

OpenTelemetryとは何ですか？

Cloud Native Computing Foundation（CNCF）が管理する、ベンダー中立の観測可能性標準です。分散トレーシング・メトリクス・ログを統一したAPIとSDKで扱えます。Datadog・Grafana・Honeycombなど主要な監視ツールが対応しており、AI/LLM向けには gen_ai セマンティック規約が整備されています。

デフォルトのメタデータモードとfull contentモードの違いは？

メタデータモード（デフォルト）はduration・status・トークン数・モデル・ツール名のみ記録します。full contentモードはさらにプロンプト・レスポンス・ツールI/Oも含みます。センシティブデータが含まれる場合があるため、full contentを使う際はトレース保存先のアクセス管理と保存期間の設定が重要になります（Anthropic、2026-10）。

agens の監査ログとどう使い分けますか？

agens の監査ログは「誰が・何を・いつ承認したか」のコンプライアンス記録（操作の巻き戻し可）です。OpenTelemetryは「どのスパンで何ミリ秒かかったか・どこでエラーが出たか」のエンジニアリング可観測性です。用途が違うため、両方を組み合わせるのが設計上の基本です。

設定にコード変更は必要ですか？

Messages API・Managed Agentsのサーバーサイドトレーシングは、管理者がClaude Consoleにエクスポート先を追加するだけで有効化できます（アプリケーションコードの変更不要）。SDK経由のトレーシングを使う場合は別途SDKトレーサーの設定が必要です（@ClaudeDevs二次報道、2026-10-14）。

Managed AgentsをOpenTelemetryで監視するとZero Data Retentionに影響しますか？

影響しません。ただし、Managed AgentsはOpenTelemetry対応以前からZero Data Retentionの対象外です（Anthropic）。OpenTelemetryを使っても使わなくても、この制限は変わりません。

最終更新: 2026-10-19

agens を実際に動かしてみませんか?

デモ・お問い合わせ agens を詳しく見る他の技術解説を見る