
ここ数週間、Claude Code のテレメトリをじっと見てきましたが、いつも同じことに気づきます。ほとんどのチームはそれを環境に導入して「素晴らしい」と言うだけで、システムレベルで実際に何をしているのかを全く理解していないのです。
個人向けの開発ツールとしてはそれで問題ありません。50 人のエンジニアに展開してしまったら、それでは済みません。
Claude Code が実際に出力しているもの
Claude Code にはネイティブの OpenTelemetry サポートが組み込まれています。環境変数を 2 つ設定するだけで、次の内容がエクスポートされます。
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://collectors.sumologic.com/receiver/v1/otlp/<unique-id>
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=x-sumo-token your-token"
エンドポイント URL は、Sumo Logic の「Manage Data」→「Collection」→「Hosted Collectors」で OTLP/HTTP ソースを作成することで取得できます。ソースが作成されると、一意の取り込み用 URL が発行されます。環境変数をその URL を指すように設定すれば完了です。コレクターは不要です。SDKも不要です。ラッパーも不要です。何が流れ始めるか:メトリクスは60秒ごと、イベントは5秒ごと。
メトリクスは退屈な部分ですが(それでも必要です)
ユーザー別、モデル別、タイプ別(入力/出力/キャッシュ)のトークン使用状況。1セッションあたりの料金(USD)。開始されたセッション数。追加および削除されたコード行数。作成されたコミット数。作成されたPR数。Claudeと能動的にやり取りしている時間と、Claudeが処理している時間。
これはROIダッシュボードです。これは、3か月後にエンジニアリング担当VPが投げかける次の質問への答えです。「これにお金を払っているが、本当に誰か使っているのか?」
user.account_uuidとorganization.idでセグメント化します。Sumo Logicダッシュボードを構築する。先に進みます。
イベントこそが興味深い部分です
これは注目すべき点です。
Claudeがツールを実行するたびに、claude_code.tool_resultイベントが発生します。そのイベントには、ツール名、実行時間、成功または失敗、そしてBashの場合は実行された完全なbash_commandが含まれます。
アクセスされたすべてのファイルパス。すべてのgitコマンド。呼び出されたすべてのスクリプト。ログ化され、構造化され、検索可能。
ユーザーがプロンプトを送信するたびに、claude_code.user_promptイベントが発生します。デフォルトではプロンプトの長さが記録され、OTEL_LOG_USER_PROMPTS=1をオンにすると内容全体が記録されます。すべてのAPI呼び出しには、モデル、コスト、レイテンシ、トークン数を含む独自のclaude_code.api_requestイベントが付与されます。
これらすべてを結びつけるもの:prompt.id。各イベントには、そのイベントを引き起こした元のプロンプトにリンクするUUIDが付与されます。Sumo Logic Log Searchでフィルターを1つ設定するだけで、ユーザーが何を要求したか、どのようなAPI呼び出しを行ったか、どのようなツールを実行したかなど、実行チェーン全体を順番に再構築できます。
これは単なるログではなく、監査証跡です。
誰も注目していないフィールド
decision_source.
すべてのツール実行は、権限決定がどのように行われたかを記録します: config、hook、user_permanent、user_temporary、user_abort、user_reject。
user_permanentは、ユーザーが「常に許可する」をクリックしたことを意味します。一度。そのツールのために。今後ずっと。
Sumo Logicでそのフィールドを抽出して、分布を確認してください。ツールに関する決定のほとんどがuser_permanentである場合、エンジニアは事実上、Claudeが触れるツールで何でも好きなようにできることを事前に承認していることになります。彼らはそれを数か月前に一度行い、そのまま忘れてしまっています。それはセキュリティ危機ではありません。しかし、これは把握しておくべきことであり、現時点ではおそらく把握できていません。
Sumo Logicで実際に構築するもの
Sumo Logicで設定する価値のあるダッシュボードを3つ紹介します。
- 使用状況とコスト:ユーザーおよびモデル別のトークン消費量の推移。セッションごとのコスト。アクティブ時間とアイドル時間。これは最終的に経理部門が求めるものです。
- ツール実行: どのツールが実行されているか、実行頻度、成功率、平均実行時間。Bashツールに絞り込んで、コマンドパターンを確認してください。エンジニアが実際にどのようにツールを使用しているか、そしてあなたが想定していた使い方との違いが見えてきます。
- セッション再構築:
prompt.idでフィルタリングされた保存済み検索。フィールドはevent.name、event.timestamp、tool_name、bash_command、cost_usdです。何らかの問題が発生して誤ったファイルが削除された場合や、予期しないAPI呼び出しや不可解なコミットが発生した場合でも、ここから何が起こったのかを突き止めることができます。
広範囲に展開する前に、まず確認しておくべきこと
tool_parametersフィールドには秘密情報が含まれる可能性があります。エンジニアがトークン、パスワード、またはAPIキーをインラインで含むbashコマンドを実行すると、それらの値がログに記録されます。
環境によって懸念がある場合は、取り込み前にtool_parametersをマスクまたは削除するようにSumo Logicのフィールド抽出ルールを設定します。50人にリリースしてからでは遅い。
最後に
Claude Code は役に立つ。それはもうはっきりしている。しかし、役に立つことと可観測であることは別物だ。そしてエンジニアリング組織では、可観測性のないツールは、最悪のタイミングで思わぬ問題を引き起こしがちだ。
つなぎ込もう。知っていて損はないはずだ。



