要点まとめ

  • Claude PlatformがOpenTelemetryトレースの公測を開始し、Messages API、Claude Managed Agents、Claude SDKの呼び出しを既存の可観測基盤へ送信できるようになりました。
  • 各呼び出しはスパンとして記録され、遅延、エラー、トークンの流れを標準的なトレース画面で確認できます。エージェント実行の全体像が見える点が特徴です。
  • 導入は、Claude側でトレースを有効化し、OpenTelemetryのエクスポーターを自社の可観測スタックに向けて設定する流れです。まずステージングで検証するのが安全です。
  • 専用ページはまだなく公測中のため、料金や対応範囲、データの扱いは公式サイト（anthropic.com）で最新情報を確認してください。

基本情報

ジャンル・位置づけ開発者向けの可観測性機能（公測）
対応端末サーバー側のAPI・SDK連携が中心。設定はPCのブラウザで
料金公測中の料金や上限は公式サイトで確認
対応言語SDKが提供される言語に準拠（公式サイトで確認）
注目ポイントエージェント実行まで含めてスパンで可視化
難易度中級者向け。可観測性の基礎知識があると有利
カテゴリ開発・Webツール
作者・提供元ClaudeDevs
公式サイトanthropic.com ↗
注目度🔥 注目度 97万
最終更新

Claude PlatformのOpenTelemetryトレースとは何か

2026年10月14日、AnthropicのClaude開発チームは、Claude PlatformでOpenTelemetryトレースの公測を開始したと発表しました。これはMessages API、Claude Managed Agents、各種Claude SDKからの呼び出しを、開発者がすでに運用している可観測基盤へそのまま送り出せるようにする機能です。自前の計測コードを足さなくても、本番のAIワークロードを既存のダッシュボードで追えるようになる点が評価されています。

これまでAIアプリの運用では、モデル呼び出しの遅延や失敗、トークンの消費量を把握するために独自のログ出力を組み込む必要がありました。Claude Platformのトレースは、Messages APIの1回の呼び出し、Managed Agentsのエージェント実行、SDK経由のリクエストをそれぞれスパンとして出力します。標準規格であるOpenTelemetryに沿うため、既存の可観測ツールの画面でそのまま確認できるのが大きな違いです。

提供状況は公測で、この機能専用のページはまだ用意されていません。詳細な設定方法や対応範囲は、Anthropicの公式サイト（anthropic.com）や開発者向けドキュメントで確認してください。公測中は仕様が変わる可能性があるため、本番導入の前に最新の案内を必ず確認することをおすすめします。

  • 発表元と時期

    AnthropicのClaude開発チームが2026年10月14日に公測開始を発表。専用ページはまだなく、公式サイトが一次情報です。

  • 対象となる3つの経路

    Messages API、Claude Managed Agents、Claude SDKの3経路からトレースを送信できます。

  • 標準規格ベース

    独自形式ではなくOpenTelemetryに準拠するため、既存の可観測基盤をそのまま活かせます。

  • 公測である点

    料金や利用上限の扱いは公式サイトで確認が必要です。仕様変更の可能性も想定しておきましょう。

スパンとトレースで何が見えるようになるのか

OpenTelemetryでは、1つの処理の流れをトレース、その中の各区間をスパ��と呼びます。Claude Platformの場合、Messages APIの1回の呼び出しや、Managed Agentsのエージェント実行、SDK経由のリクエストがそれぞれスパンとして記録されます。スパンには親子関係があり、どの処理がどの処理を呼び出したのかを一本の流れとして追えます。

可視化される代表的な情報は、処理にかかった時間、エラーの有無、トークンの流れです。これにより、どの呼び出しが遅いのか、どのステップで失敗したのか、ど��処理がトークンを多く消費しているのかを、推測ではなくデータで判断できます。複数ステップにわたるエージェント実行が完全に見えるようになる点が、特に注目されています。

データの送信は、OpenTelemetryのエクスポーターを通じて行います。エクスポーターは計測データを外部の可観測基盤へ渡す部品で、送信先を設定するだけで既存のダッシュボードにスパンが並びます。独自形式ではなく標準規格なので、表示や検索の方法は使い慣れたツールのままです。

  • レイテンシの内訳

    どのAPI呼び出しやエージェントのステップが時間を使っているかを区間ごとに確認できます。

  • エラーの追跡

    失敗した呼び出しをスパン単位で特定でき、原因の切り分けが速くなります。

  • トークンの流れ

    どの処理がどれだけトークンを使ったかを、処理の流れの中で把握できます。

  • エージェント実行の可視化

    複数ステップにわたるエージェントの処理が一本のトレースとして見えるのが特徴です。

ステージングから本番へ：導入手順と運用の勘所

導入の第一歩は、Claude Platform側でトレースを有効にすることです。そのうえで、OpenTelemetryのエクスポーターを自社の可観測スタックに向けて設定します。エンドポイントや認証情報は既存の基盤で使っているものを流用できるため、新しい監視ツールを契約する必要はありません。設定後は、Messages APIを数回呼び出してスパンが届くかを確認しましょう。

検証は必ずステージングのプロジェクトから始めます。本番のトラフィックをいきなり送ると、想定外のデータ量で可観測基盤側のコストや保存期間に影響が出ることがあります。少数の呼び出しでスパンの親子関係や属性が正しく出ているかを確認し、問題がなければ段階的に本番へ広げていきます。

運用に乗ったら、遅延の内訳、エラー率、トークン消費量をダッシュボードの定番指標にします。エージェント実行は処理の流れが長くなるため、どのステップで時間を使っているかをウォーターフォールで確認すると改善点が見つけやすくなります。既存のアラート条件に組み込めば、異常の検知も早くなります。

  • まずステージングで検証

    本番前に少数の呼び出しでスパンの到達と内容を確認します。いきなり全量を送らないのが安全です。

  • 送信先は既存基盤を流用

    OpenTelemetry対応のバックエンドなら、すでに使っている監視ツールをそのまま送信先にできます。

  • エージェント実行を重点的に見る

    処理が長いエージェントは、どのステップが遅いかをウォーターフォールで特定するのが有効です。

  • 公測中の変更に備える

    仕様や項目名が変わる可能性があるため、公式サイトの更新を定期的に確認しましょう。

向いているチームと、既存ツールとの比較・制約

向いているのは、Claudeを本番のプロダクトに組み込み、複数のチームで運用している開発組織です。すでにOpenTelemetry対応の可観測基盤を持っているチームほど、導入の効果は大きくなります。逆に、個人が小さな検証をするだけなら、標準のログ出力でも目的を満たせる場合があります。

既存の可観測ツールとの関係は置き換えではなく接続です。独自の計測コードを書き足す代わりに、標準規格のトレースとして既存の画面に流し込めます。ベンダー固有のSDKに依存しないため、後から監視ツールを乗り換えるときも影響を抑えられます。

制約も理解しておきましょう。専用ページはまだ存在せず、機能は公測段階です。料金、送信できるデータの種類、保持期間、対応するSDKの範囲は公式サイトの案内で確認する必要があります。トレースに含まれる情報の扱いは、自社のセキュリティ方針と照らし合わせて決めてください。

  • 本番運用チーム向け

    複数サービスをまたぐ遅延やエラーの切り分けが必要な組織ほど、恩恵が大きい機能です。

  • 標準規格なので乗り換えに強い

    OpenTelemetry準拠のため、特定ベンダーの監視ツールに縛られにくくなります。

  • 小規模な検証には過剰かも

    呼び出し回数が少ない段階では、通常のログでも目的を満たせる場合があります。

  • 公測ゆえの不確実性

    料金や対応範囲は未確定な部分があるため、公式サイトでの確認を前提に計画しましょう。

ステップ別ガイド

  1. 前提となる環境をそろえる

    Claude PlatformのアカウントとAPIキー、そしてトレースを受け取れる既存の可観測基盤を用意します。公測中の機能なので、まず公式サイトで対応範囲と制限を確認しておきましょう。

  2. Claude側でトレースを有効にする

    Claudeの連携設定でトレースを有効にします。Messages API、Managed Agents、SDKのうち、どの経路から送るかを決めておくと、後から見分けやすくなります。

  3. エクスポーターを送信先に設定する

    OpenTelemetryのエクスポーターを、自社の可観測スタックに向けて設定します。送信先のエンドポイントや認証情報は既存基盤のものを使い、まずは検証用の宛先に送るのが安全です。

  4. ステージングでスパンを確認する

    ステージングのプロジェクトからMessages APIを数回呼び出し、スパンが実際に届くかを確認します。表示される項目や親子関係をチェックし、問題がなければ本番へ展開します。

  5. 運用の監視に組み込む

    本番では遅延、エラー、トークン量をダッシュボードで監視し、エージェント実行の流れをウォーターフォールで確認します。アラート条件を既存の運用ルールに組み込むと効果的です。

よくある質問

利用に追加料金はかかりますか？

公測中の料金体系は変更される可能性があるため、公式サイトの案内で確認してください。少なくともAPI呼び出し自体の利用料は別途発生します。可観測基盤側の保存や転送にかかる費用も自社の契約に応じて変わります。

スマートフォンやアプリから使えますか？

スマートフォン向けアプリとして提供されるものではなく、サーバー側のAPIやSDKに組み込む開発者向け機能です。設定作業はPCのブラウザや開発環境から行い、トレースの閲覧は既存の可観測ツールの画面で行います。

既存の可観測ツールと併用できますか？

OpenTelemetryは特定ベンダーに依存しない標準規格なので、対応している可観測基盤であれば既存のものをそのまま使えます。監視ツールを乗り換えずに済む点が導入の大きな利点です。対応状況は利用中のツールの資料で確認してください。

具体的に何が記録されますか？

1回のMessages API呼び出し、Managed Agentsのエージェント実行、SDK経由のリクエストがそれぞれスパンとして記録され、遅延、エラー、トークンの流れを追えます。特にエージェント実行の全体像が見える点が注目されています。

セキュリティ面で注意することはありますか？

トレースにどのような情報が含まれるかは公式ドキュメントで確認してください。機密性の高いプロンプトや個人情報を送らないよう、設定やサンプリングを自社のポリシーに合わせて調整するのが安全です。