Claude Code

Claude Codeを個人の開発ツールとして使う分には設定はほぼ不要だが、チームや組織で本格導入する段階になると、「誰が」「どれくらい」「どのように」使っているかを把握できる仕組みが必要となってくる。コスト管理、利用状況の監査、セキュリティレビューなど、企業導入担当者が気にするポイントの多くは「可観測性（observability）」の問題に集約される。

Claude Codeには、この可観測性を支える2つの機能が用意されています。ひとつはメトリクス・ログを外部の監視基盤に送信するOpenTelemetry（OTel）連携、もうひとつはセッションの会話ログをローカルに記録するtranscript機能。

1. OpenTelemetry（OTel）連携

概要

Claude CodeはOpenTelemetry標準に対応しており、有効化するとセッション数・APIコスト・トークン消費量・コード変更行数・Gitコミット数・プルリクエスト作成数といった利用状況の指標を、既存の監視基盤（Datadog、Grafana、Prometheusなど、OTLPを受け付ける任意のバックエンド）に送信できる。ユーザーのプロンプト送信、APIリクエスト、エラー、ツール実行結果、MCPサーバー接続といったイベントもトラッキング対象。

デフォルトでは無効になっており、明示的な有効化が必要なオプトイン方式。また、プロンプトの本文自体はデフォルトで送信対象から除外されており、必要に応じて詳細ログを追加で有効化する設計。

有効化方法

主に環境変数で制御します。

export CLAUDE_CODE_ENABLE_TELEMETRY=1

export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp

export OTEL_EXPORTER_OTLP_ENDPOINT=https://otel-collector.example.com:4317

組織で統一運用したい場合は、個々の開発者の環境変数任せにするのではなく、管理者向けのマネージド設定（managed settings）を使ってこれらの値を一括配布することもできる。

何がわかるようになるか

  • コスト管理: チーム・プロジェクト単位でのAPI利用コストの推移把握
  • 利用状況の可視化: アクティブなセッション数、利用が多い時間帯・曜日
  • 生産性の傾向把握: コード変更行数やコミット数、PR作成数の推移
  • 異常検知: エラー率の急増やツール実行失敗の監視

2. Transcript機能

概要

Claude Codeは、セッション内のやり取り（ユーザーの発言、Claudeの応答、ツールの実行結果、メタデータなど）をJSONL形式で自動的にローカル保存する、これが「transcript（トランスクリプト）」。1行が1つのメッセージ・ツール実行・メタデータ単位に対応しており、機械的にパースしやすい構造。

保存先はデフォルトで以下のパス。

~/.claude/projects/<プロジェクト名>/<セッションID>.jsonl

保持期間はデフォルトで30日、設定のcleanupPeriodDaysで変更可能です。監査要件が厳しい組織では長めに、逆にセンシティブな情報を扱う開発現場では短めに調整するといった運用が考えられる。

主な関連機能

  • /exportコマンド: セッションの内容を人間が読みやすい形式でエクスポートできる。過去のやり取りを議事録やナレッジ共有として残したい場合に便利。
  • CLAUDE_CONFIG_DIR環境変数: トランスクリプトを含む設定ファイル全体の保存場所を変更できる。共有ストレージや監査用ディレクトリに保存先を統一したい場合に利用。
  • CLAUDE_CODE_SKIP_PROMPT_HISTORY環境変数: トランスクリプトの書き込み自体を抑制したい場合に使用。機密性の高いプロジェクトで、ログをそもそも残したくないケースに有効。

プライバシー・セキュリティ上の注意点

Transcriptはローカルにプレーンテキストで保存される。ソースコードの内容や社内固有の情報がやり取りに含まれる場合、その内容がそのままファイルに残ることになるため、以下の点は事前に検討する必要がある。

  • 開発端末のディスク暗号化やアクセス権限の設定状況
  • 保持期間（cleanupPeriodDays）を社内のデータ保持ポリシーに合わせて調整するか
  • 機密プロジェクトではCLAUDE_CODE_SKIP_PROMPT_HISTORYによる記録抑制を検討するか
  • CLAUDE_CONFIG_DIRで保存先を統制し、バックアップ・監査のフローに組み込むか

3. 2つの機能を組み合わせた企業導入の考え方

OTelとtranscriptは役割が異なる。OTelは「集約された利用状況・パフォーマンスの可視化」、transcriptは「個々のセッションの詳細な記録」。企業導入の際は、次のような住み分けが現実的。

  • 経営層・マネージャー向けのダッシュボードにはOTel経由のメトリクスを使い、コストや利用率の傾向を追う
  • セキュリティ監査やインシデント調査が必要な場面ではtranscriptを参照し、実際に何がやり取りされたかを確認する
  • 両者とも管理者側で一括設定できるため、開発者個々の設定任せにせず、マネージド設定として組織ポリシーに組み込むのが望ましい

導入初期は「まずOTelでメトリクスを可視化し、運用が安定してきたらtranscriptの保持ポリシーを整備する」といった段階的な進め方がおすすめです。

もう少し踏み込んだ使い分け

OTelとtranscriptの違いは、「計測」と「ログ監視」という言葉よりも、もう一段掘り下げると次のように整理できる。

OTel Transcript
性質 定量的・集計データ（数値の集まり） 定性的・個別の生データ（会話そのもの）
見るもの 「何回」「いくら」「何%」 「実際に何を言った/何をしたか」
保存先 外部の監視基盤（Datadog等） ローカルのJSONLファイル
使うタイミング 常時・継続的に流し込む 事後に特定のセッションを掘り下げる時
例えるなら 心拍数・体温計（バイタルモニター） 診察記録・カルテ（個別の詳細記録）

正確に言うと、OTelは文字通り「計測・モニタリング」であり、ダッシュボード上で「今月コストが急増した」「特定チームのエラー率が上がった」といった異常の検知に向いている。一方でtranscriptは「監視」というより事後調査・証跡としての役割が強く、「その時間帯のセッションで具体的に何が起きていたのか」を掘り下げて確認するために使う。

実務的な流れにすると、次のようになる。

  1. OTelのダッシュボードで異常や傾向に気づく（例: 特定チームでエラー率が急上昇）
  2. 原因を特定するために、該当時間帯のtranscriptを掘り下げて確認する

まとめ

Claude Codeは個人利用の手軽さを保ちながら、企業導入を見据えた可観測性の機能もしっかり備えている。

  • OpenTelemetry連携: メトリクス・ログを外部監視基盤に送信し、コストや利用状況を可視化。オプトイン方式でプロンプト本文はデフォルト除外。
  • Transcript機能: セッションの詳細をJSONLでローカル保存。/exportでの取り出しや、保持期間・保存先の調整が可能。

c.sakyou

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA