OTel によるエージェント実行メトリクス収集

[clonable-eden]

概要

Claude Code の OpenTelemetry サポートを活用し、Worker/Reviewer/Orchestrator の実行メトリクスを構造化データとして収集する。

動機

現在は /postmortem で transcript を JSONL パースして問題検出しているが、定量的な傾向分析（retry 回数、フェーズ別所要時間、エラー率など）には向いていない。OTel で構造化メトリクスを収集すれば、再現性のあるパターンの自動検出が可能になる。

設計方針

• opt-in: CEKERNEL_ENV のプロファイルで有効化（例: envs/observability.env）
• デフォルトは無効（Rule of Economy）
• 利用者が増えたときの選択肢として

現状

1人開発で /postmortem が回っている現状では不要。将来の選択肢として記録。

[clonable-eden]

関連: --output-format stream-json + --include-hook-events (2026-06-07)

OTel まで踏み込まなくても、Claude Code 自体の event stream で「retry 回数」「フェーズ別経過時間」を取れることが分かったため、軽量な中間策として記録しておきます。

概要

• claude -p --output-format stream-json で newline-delimited JSON event を stdout に流せる。
• 主なイベント：system/init、system/api_retry、message/start、message/delta、tool_use/*、（--include-hook-events で）hook ライフサイクル。
• total_cost_usd のような cost 情報も final JSON に含まれる。

cekernel への接続点

• 現状の FIFO / state file による「フェーズ遷移」検出を、Worker stdout の stream-json を tail するだけでメタデータ付きで取得できる。
• OTel exporter を組まなくても、Orchestrator がイベントを logs/{issue}.events.jsonl として保存しておけば、/postmortem の入力としても活用可能。
• Retry 回数や API エラーの集計は jq で十分。

棲み分け案

• stream-json log: 単一ユーザ・自己 hosting 向けの軽量観測（本 issue の "1 人開発で不要" な領域にちょうどフィット）
• OTel exporter: 複数ユーザ・チーム配布時の選択肢として opt-in（本 issue の元方針）

アクション

別 issue として「stream-json を Worker spawn 時の補助観測層として記録する」案を切り出すか検討中。本 issue は OTel 本格対応のトラッキングとして引き続き open のままにします。