はじめに
「とりあえず動いている」でリリースしたコードにはログも計装もない。障害が発生して初めて「どこで何が起きているか分からない」と気づく——。
本記事はClaude Code自体の利用コストやROIを測る話ではない。Claude Codeを使って、自分たちのアプリケーションにOpenTelemetry（OTel）を実装するという逆向きの活用だ。計装コードの自動生成から、HoneycombやDatadogのMCPで本番データを参照しながら改善するフィードバックループまでを体系化する。
Claude Codeが「計装コードを書く」とはどういうことか
Honeycombのブログ「Can Claude Code Observe Its Own Code?」では、Claude Codeが自分自身のコードにOTel計装を追加する能力が検証されている。
典型的な依頼プロンプトはこうなる。
このAPIエンドポイント（handlers/user.go）にOpenTelemetryの計装を追加してください。
- リクエスト処理全体のspan
- データベースクエリのspan（クエリの種類・テーブル名を属性として含める）
- エラー発生時のspan statusの設定
- span nameはOpenTelemetry Semantic Conventionsに従う
Claude Codeはコードベース全体を読み込み、既存のパターン・命名規則・フレームワークに合わせた計装コードを生成する。「OTelのコードを書く」という作業が自動化され、エンジニアは「どこを計装すべきか」という設計判断に集中できる。
可観測性3本柱の実装支援
分散トレーシング（Spans）
マイクロサービス間の呼び出し追跡では、W3C TraceContextの伝播まで含めた計装が必要だ。
UserServiceからOrderServiceへのgRPC呼び出しとOrderServiceからInventoryServiceへのHTTP呼び出しに
OpenTelemetryのspanを追加してください。W3C TraceContextを伝播させること。
Claude Codeが自動生成するのは、各サービスのspan生成・終了処理、TraceContextの伝播コード（HTTPヘッダー/gRPCメタデータ）、エラー時のrecordException処理、Semantic Conventions準拠のspan属性（`http.method`、`db.system`等）だ。
メトリクス設計とカーディナリティ管理
OTelメトリクス設計で最も難しいのがカーディナリティ爆発の回避だ。`user_id`のような高カーディナリティ属性をラベルにすると時系列DBが爆発する。
このメトリクス設計をレビューして、カーディナリティの問題があれば指摘してください。
また以下のビジネス指標を計測するための適切なメトリクスを提案してください：
- 注文処理成功率
- チェックアウトのレイテンシP50/P95/P99
- 在庫切れによるエラー率
Claude Codeはカーディナリティリスクのあるラベル設計を指摘し、適切な粒度のメトリクス構造を提案する。
構造化ログ設計
このログ出力をOpenTelemetryのlog semantic conventionsに準拠した構造化ログに変換してください。
現在: console.log("Order created for user " + userId)
期待: 検索可能なフィールドを持つJSON形式のログ
HoneycombとDatadog MCP：本番データを見ながら計装を改善する
Honeycombは公式にMCP統合を提供しており、Claude CodeからHoneycombのデータを直接参照できる。「過去1時間のP95レイテンシが高いトレースを取得して、ボトルネックを分析して」「エラーが発生したトレースを全件取得して、共通パターンを分類して」という操作が自然言語で実行できる。
「計装を追加 → 本番で確認 → Claude Codeで分析 → 計装を改善」というフィードバックループが成立する。計装を入れたら終わり、ではなかった。本番データを見てから「ここはもっと詳しく取るべき」「このラベルは不要だった」という気づきが出てくる。このループがあると可観測性がじわじわ良くなっていく。
DatadogのMCPサーバーをClaude Codeに接続した事例（Steven C.氏のLinkedIn投稿）では、「特定サービスの昨日のエラーログを分析して」とClaudeに指示するだけでDatadogのログ検索・集計が自動実行される。アラートルールの生成も「CPU使用率が5分間80%超えたら通知するアラートを作って」という自然言語で行える。
Honeycomb・DatadogのMCPにはread accessのみを付与し、write操作は許可しないことが安全設計の原則だ。
Claude Codeエージェント自体の可観測性
Claude Agent SDKで作ったエージェントをLangfuseで可視化する統合が提供されている。エージェントの各ステップ（ツール呼び出し・LLMリクエスト）のレイテンシ、トークン使用量とコスト、プロンプトのバージョン管理などを追跡できる。複数エージェントが連携するシステムで「どのエージェントがボトルネックか」「どのプロンプトが高コストか」を可視化する用途に使える。
`claudia`（GitHub: TechNickAI/claude_telemetry）は`claude`コマンドをそのまま置き換えることで計装を追加できるラッパーだ。Logfire・Sentry・Honeycomb・Datadogにトレースを自動送信する。テレメトリはasync処理でオーバーヘッドが低いという報告がある。
`ccdashboard`（GitHub: NikiforovAll/ccdashboard）はClaude CodeのOTelテレメトリをGrafanaで可視化するCLIツールだ。エージェントの各ツール呼び出しをspanとして可視化し、「Claude Codeがどの順序で何をしていたか」をウォーターフォール図で確認できる。
設計上の注意点
span設計で「どのビジネスイベントを計装すべきか」はドメイン知識が必要で、Claude Codeは計装コードを書けるが設計判断は人間が行う。Claude Codeが提案するラベル設計に高カーディナリティ属性が含まれていないかのレビューも必須だ。
Claude CodeのOTelテレメトリはデフォルト無効・オプトイン方式で、ファイルの生コンテンツはメトリクスに含まれない。
まとめ
着手の順番に迷ったらこれで始めてみてほしい。
ステップ1（1時間）：Claude Codeに「このリポジトリでObservabilityのGapを分析してください。spanがないエンドポイント・エラーログが出ない箇所・計測できていないコードパスを一覧にして優先順位をつけて」と依頼する。現状の可視化から始める。
ステップ2（2〜3時間）：使用技術スタックとバックエンド（Honeycomb/Datadog/Grafana）を伝え、プロジェクト固有のOTel初期化コードと計装ガイドラインをClaude Codeに生成させる。
ステップ3（設定30分）：毎週「先週のトレースでP95が遅い上位5エンドポイントを特定して、改善提案をまとめて」というスケジュールをSchedulerに設定する。
OTelの知識がなくても計装コードは書いてもらえる。ただ「何を計測すべきか」と「カーディナリティは大丈夫か」は人間がちゃんと考えないといけない——この感覚が掴めると、Claude Codeとの分担が自然になってくる。
コメント