【要約】AI PRの渋滞が見えないのでOpenTelemetryで管制ログを設計した [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
AIエージェントが並列でPRを量産する環境において、開発者がPRの停滞理由を把握できない問題に直面した。GitHub AppがPRの着地を制御する際、判断の根拠がログやDBに分散し、調査コストが増大していた。
- ・PRが「Wait」状態になる理由が不明。
- ・どの判断ステップで遅延したかが追えない。
- ・ログ、DB、GitHub画面の確認を繰り返す必要がある。
// Approach
GitHub Appの判断ロジックを可視化するため、OpenTelemetryを用いたトレーシングとメトリクスの設計を行った。処理の文脈を保持しつつ、集計効率とセキュリティを両立させる手法を採用している。
- ・1つのWebhook受信を1つのTraceとして定義。
- ・判断プロセスをSpanとして構造化し、節目をSpan Eventとして記録。
- ・業務上の判断（Wait等）はErrorではなくAttributeとして記録。
- ・Metricには高カーディナリティな値を避け、集計に適した属性のみを付与。
- ・機密情報をTelemetryに含めない分離設計を徹底。
// Result
判断のプロセスを時系列で追跡可能にした。これにより、運用者は「なぜその表示になったか」を即座に特定できる。
- ・Traceにより、PRごとの判断根拠を詳細に調査可能。
- ・Metricにより、システム全体の判断傾向をダッシュボードで把握可能。
- ・機密情報を保護しつつ、運用に必要なメタデータのみを抽出可能。
Senior Engineer Insight
> 従来の「エラー監視」から「意思決定の可観測性」へのシフトが重要である。AIエージェントが介在する系では、ロジックの正当性を追う必要がある。Metricの高カーディナリティ回避や、機密情報の分離といった設計思想は、大規模運用における鉄則である。単なるログ増量ではなく、情報の粒度をTraceとMetricで使い分ける設計が、運用コストを左右する。