Claude Code SIEM連携でOTELイベントを監査基盤に送る
Claude CodeのOTELログイベントをSIEMへ送る設定を、プロトコル選択・mTLS認証・管理設定でのロック方法まで具体的にまとめます。
はじめに
Claude Codeが吐き出すOTel(OpenTelemetry)のログイベントは、そのままSecurity Information and Event Management(SIEM)基盤に取り込める形式で設計されています。OTLPのlogsエクスポーターをSIEM側のOTLP受信エンドポイントか、SIEMへ転送するOpenTelemetry Collectorに向けるだけで、Bashコマンド・ファイル編集・MCP呼び出し・権限判断がイベントとして流れ込みます。
前提はシンプルです。
| 項目 | 必要な状態 |
|---|---|
| Claude Code | 必要な状態制約なし。ただしエンドポイント・プロトコル・認証情報の削除挙動はv2.1.217以降が対象 |
| SIEM側 | 必要な状態OTLPを受信できるレシーバー、またはOTel Collectorを経由した転送経路 |
| 設定権限 | 必要な状態シェル変数、または管理設定(managed settings)ファイルへの書き込み権限 |
この記事はSIEM向けのイベント配送そのものに絞ります。メトリクスによるコスト・利用量の可視化を先に知りたい場合はClaude CodeのOpenTelemetryで利用量とコストを可視化が入り口として適しています。どのイベントがどんな監査質問に答えるかはClaude Codeセキュリティ監査とOTELイベントの対応表にまとめました。OTel以外の監査経路も含めた組織のセキュリティ設計全体はClaude Codeセキュリティ・権限ガイドを参照してください。
ステップ1: OTLPプロトコルとエンドポイントを決める
OTLPにはgrpc・http/protobuf・http/jsonの3プロトコルがあり、Claude Codeには既定プロトコルがありません。有効化する信号(metrics / logs / traces)ごとにOTEL_EXPORTER_OTLP_PROTOCOLか信号別の変数を必ず指定します。
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://siem.example.com:4318/v1/logs
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-siem-token"信号別の変数(OTEL_EXPORTER_OTLP_LOGS_ENDPOINTなど)を設定すると、汎用のOTEL_EXPORTER_OTLP_ENDPOINTより優先されます。メトリクスは既定でホームサーバー等の一般的なOTel Collectorに送り、イベントだけを別のSIEM受信エンドポイントへ向ける構成も、このエンドポイント分離で成立します。
mTLSを要求するSIEMやCollectorに接続するときは、プロトコルによって証明書関連の変数名が異なります。取り違えると証明書を設定したのに認証エラーが取れないという事態になるため、先に対応を確認しておきます。
| プロトコル | クライアント証明書変数 | CollectorのCAを信頼させる変数 |
|---|---|---|
http/protobuf / http/json | クライアント証明書変数CLAUDE_CODE_CLIENT_CERT / CLAUDE_CODE_CLIENT_KEY(必要ならCLAUDE_CODE_CLIENT_KEY_PASSPHRASE) | CollectorのCAを信頼させる変数NODE_EXTRA_CA_CERTS |
grpc | クライアント証明書変数OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE / OTEL_EXPORTER_OTLP_CLIENT_KEY(信号別に上書きするならOTEL_EXPORTER_OTLP_METRICS_CLIENT_KEYのように信号名を挟んだ形) | CollectorのCAを信頼させる変数OTEL_EXPORTER_OTLP_CERTIFICATE |
ステップ2: 管理設定でエンドポイントをロックする
管理設定(managed settings)ファイルでOTEL_EXPORTER_OTLP_*系の変数を設定すると、Claude Codeは起動時に開発者側が設定した競合変数を削除します。組織が意図したSIEM以外へテレメトリが流れる経路を、設定の優先順位ではなく削除という形で塞ぐ仕組みです。
何を消すかは設定した変数の種類で変わります。汎用のOTEL_EXPORTER_OTLP_ENDPOINTを管理設定側で指定すると、開発者が設定した信号別エンドポイントはすべて削除されます。OTEL_EXPORTER_OTLP_PROTOCOLを設定すると、開発者が設定した信号別プロトコルがすべて削除されます。OTEL_EXPORTER_OTLP_HEADERS・OTEL_EXPORTER_OTLP_CLIENT_KEY・OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATEのいずれかを管理設定側で設定すると、それらの信号別バージョンに加えて、開発者が設定したエンドポイント変数(汎用・信号別を問わず)まで削除されます。認証情報だけを固定しても、開発者がエンドポイントを変えて別の受信先に漏らせてしまうからです。
一方、OTEL_METRICS_EXPORTER・OTEL_LOGS_EXPORTER・ベータのOTEL_TRACES_EXPORTERは通常のキー優先順位に従います。開発者側の設定でイベント送信自体を無効化したりconsoleエクスポーターに切り替えたりできてしまうため、SIEM連携を固定したい組織はこれらのセレクター自体も管理設定側で明示する必要があります。この削除挙動はClaude Code v2.1.217以降が対象です。それより前のバージョンでは、すべての変数が独立してキー優先順位に従っていたため、ユーザー設定やシェルで信号別エンドポイントを指定すると、管理設定のCollectorから信号ごと逸れる余地がありました。なお、管理ソースが複数あるときOTEL_LOGS_EXPORTERだけがテレメトリ単位でまとまり、他の2つはキー単位でマージされるという別の挙動はv2.1.223以降が対象です。
ステップ3: イベントだけをSIEM向けに送る
メトリクスとログ(イベント)は別々のエクスポーターを持てるため、コスト可視化用のCollectorとSIEMを分離できます。SIEM連携だけが目的なら、OTEL_METRICS_EXPORTERはnoneのままにしてOTEL_LOGS_EXPORTERだけを設定すれば送信量を抑えられます。
MCP呼び出しやBashコマンドの詳細までSIEM側で検知ルールに使いたい場合は、OTEL_LOG_TOOL_DETAILS=1を追加します。この設定なしでは、ユーザー設定のMCPサーバーに対するtool_result / tool_decisionイベントのツール名が"mcp_tool"という文字列に丸められ、引数も含まれません。
SIEM側のベアラートークンは失効・ローテーションするため、OTEL_EXPORTER_OTLP_HEADERSに静的な値を直書きし続けると更新のたびに設定変更が要ります。http/protobuf・http/jsonではotelHeadersHelperにヘッダー生成スクリプトを指定でき、Claude Codeがそのスクリプトを定期的に呼び出してヘッダーを再生成します(既定の呼び出し間隔はCLAUDE_CODE_OTEL_HEADERS_HELPER_DEBOUNCE_MSで、既定値は29分)。grpcはこのヘルパーに対応しておらず、静的な変数のみを使います。管理設定の例は次の形です。
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_LOGS_EXPORTER": "otlp",
"OTEL_LOG_TOOL_DETAILS": "1",
"OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
"OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem.example.com:4318/v1/logs",
"OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-siem-token"
}
}設定が届いているかは、この構成が反映されたセッションでプロンプトを1つ送り、SIEM側でclaude_code.user_promptイベントを探すことで確認できます。何も届かない場合はclaude --debugを実行し、デバッグログの[3P telemetry](third-partyの意)で始まる行を探します。[Anthropic telemetry]はAnthropic側の別系統の運用テレメトリを指すため、SIEM連携の不具合とは無関係です。
信号ごとにどのバックエンド特性が要るか
SIEM連携ではイベント(ログ)だけを意識しがちですが、メトリクス・トレースを同じ組織内の別基盤に振り分ける設計も珍しくありません。信号ごとに向いているバックエンド特性が異なります。
| 信号 | 向くバックエンド特性 | できる分析 |
|---|---|---|
| メトリクス | 向くバックエンド特性時系列データベース / 列指向ストア | できる分析レート計算、ユニークユーザー分析 |
| イベント(ログ) | 向くバックエンド特性ログ集約基盤 / SIEM | できる分析全文検索、監査イベントの構造化分析 |
| トレース(ベータ) | 向くバックエンド特性分散トレーシング対応基盤 | できる分析スパン可視化、リクエストのウォーターフォール表示 |
DAU/WAU/MAUのようなアクティブユーザー数を継続的に見たい組織は、ユニーク値クエリを効率的に処理できるバックエンドを選ぶ必要があります。イベントをSIEMに、メトリクスを別の可観測性基盤に振り分ける構成であれば、OTEL_EXPORTER_OTLP_METRICS_ENDPOINTとOTEL_EXPORTER_OTLP_LOGS_ENDPOINTをそれぞれ独立して指定するだけで実現できます。
SIEM側でホストとバージョンを絞り込む属性
すべてのメトリクス・イベントには、送信元を特定するためのリソース属性が共通で付きます。service.nameはターミナルセッションならclaude-code、Claude DesktopアプリのCodeタブから起動したセッションならclaude-code-desktopになります。既存のCollectorパイプラインやダッシュボードがservice.name = claude-codeだけでフィルタしている場合、Desktopアプリ経由のテレメトリを取りこぼすため、claude-code-desktopもフィルタに加える必要があります。
他にもservice.version(Claude CodeまたはDesktopアプリのバージョン)、os.type / os.version、host.arch、WSL環境でのみ付くwsl.versionが付きます。SIEM側で「未パッチのバージョンからの操作だけを抽出する」「特定OSからの異常な操作を洗い出す」といった絞り込みルールを組むときの軸になります。Meter Nameはcom.anthropic.claude_code固定です。
mTLS証明書をローテーションしてもSIEMに届かなくなる罠
Claude Code本体のAPI接続用証明書(CLAUDE_CODE_CLIENT_CERT / CLAUDE_CODE_CLIENT_KEY)は、接続エラーを検知すると実行中のセッションのまま再読み込みしてローテーションを反映します(v2.1.232以降)。しかしOTLPのテレメトリエクスポーターはこの再読み込みの対象外です。エクスポーターは最初に使ったときに読み込んだ証明書を保持し続けるため、SIEM側の証明書をローテーションしても、Claude Codeを再起動しない限り新しい証明書はテレメトリ側の接続に反映されません。API接続は生きているのにSIEMへのイベント送信だけが古い証明書のまま失敗し続ける、という切り分けにくい状態になりがちです。証明書をローテーションしたら、SIEM連携用のセッションは必ず再起動する運用にしておくと安全です。
よくあるつまずき
- 証明書変数を設定したのに認証エラーが取れない:
grpc用のOTEL_EXPORTER_OTLP_CLIENT_KEYとhttp/protobuf用のCLAUDE_CODE_CLIENT_KEYは別の変数です。プロトコルに対応する変数名を取り違えていないか確認します。 411 Length Requiredまたは400エラーが返る: v2.1.212より前のバージョンは、v2.1.191以降でチャンク転送エンコーディングを使っており、宣言された長さを要求するAzure Monitorなどの受信先が拒否していました。Content-Lengthヘッダーを送るv2.1.212以降にアップグレードすると解消します。- 管理設定で固定したのに開発者側の値が優先されているように見える: 固定したのがエンドポイントか、エクスポーター選択(
OTEL_LOGS_EXPORTERなど)かを区別します。前者は削除の対象、後者は通常のキー優先順位のままです。 - Bashツールから起動した別のOTel対応アプリにテレメトリ設定が引き継がれない: Claude Codeは
OTEL_*環境変数をBashツール・フック・MCPサーバー・言語サーバーといったサブプロセスに渡しません。サブプロセス自身のテレメトリが必要なら、コマンド内で改めて変数を指定します。
まとめ
SIEM連携の骨格は、OTEL_LOGS_EXPORTER=otlpとSIEM向けのOTLPエンドポイントを指定するだけで成立します。監査に必要な詳細度まで踏み込むならOTEL_LOG_TOOL_DETAILS=1を、組織として送信先を固定するなら管理設定側でのエンドポイント・認証情報の指定を組み合わせます。mTLSを使う場合はプロトコルごとに変数名が違う点、v2.1.217より前は管理設定のロック挙動自体が異なる点の2つを押さえておけば、設定でつまずく箇所は大きく減ります。
よくある質問
メトリクスも同じ設定でSIEMに送れますか
送れますが、SIEMはログ・イベントの分析に向いた基盤なので、コスト・利用量のメトリクスは別の時系列データベースや可観測性基盤に振り分ける構成のほうが一般的です。エンドポイントは信号ごとに独立して指定できます。
OTel Collectorを経由してSIEMに転送する構成は使えますか
使えます。OTEL_EXPORTER_OTLP_LOGS_ENDPOINTをCollectorのOTLP受信ポートに向け、CollectorのエクスポーターでSIEMのネイティブ取り込みAPIへ転送する構成が案内されています。SIEM側にOTLPレシーバーがない場合の標準的な回避策です。
管理設定のロック挙動はどのバージョンから有効ですか
エンドポイント・プロトコル・認証情報の削除挙動はClaude Code v2.1.217以降が対象です。それより前のバージョンでは、すべての変数が独立してキー優先順位に従うため、開発者側の設定がCollectorの向き先を変えられる余地が残ります。なお、管理ソースが複数あるときOTEL_LOGS_EXPORTERだけがテレメトリ単位でまとまる挙動はv2.1.223以降が対象です。
メトリクスだけを止めてイベントだけを送ることはできますか
できます。OTEL_METRICS_EXPORTER=noneにすればメトリクスの送信を止め、OTEL_LOGS_EXPORTER=otlpだけを有効にできます。送信量を絞りたいときや、SIEM連携だけを先に始めたいときに使う組み合わせです。
エクスポーターが設定を無視しているかどうかはどう切り分けますか
claude --debugでデバッグログを確認し、[3P telemetry]から始まる行を探します。third-partyエクスポーターのエラーはここに出力され、[Anthropic telemetry]から始まる行はAnthropic側の別系統の運用テレメトリなので無関係です。