エージェント運用の可観測性——ログ・トレース・イベント

「エージェントが期待通りに動いていない気がする。でも、どこで何が起きたかわからない」——LLMを組み込んだシステムを本番運用しはじめると、必ず出てくる問題だ。可観測性（observability）の話である。

この記事では、LLMエージェント運用でどこまでを、どう記録すべきかを、編集部が観測してきた実運用の慣行から整理する。

トレースを単位にする

従来のWebアプリのログは、「1リクエスト = 1行のログ」で足りることが多い。しかしエージェント構成では、1つのユーザー要求から、複数のモデル呼び出し・ツール呼び出しが連鎖する。これをバラバラに記録すると、後から追えなくなる。

編集部が推奨するのは、トレース単位で記録する設計だ。トレースIDを1つ発行し、その要求に紐づくすべてのモデル・ツール呼び出しに同じIDを付ける。各呼び出しはスパンとして時系列で並び、開始時刻・終了時刻・親スパンIDを持つ。OpenTelemetryのTrace/Spanモデルをそのまま流用できる。

何を記録するか

各スパンに、少なくとも以下を含める。入力（プロンプト全文、ツール引数）。出力（モデル応答、ツール戻り値）。モデル名とバージョン。使用トークン数（input / output別）。所要時間。成功 / 失敗、失敗ならエラー種別。ユーザーID（サービスによっては匿名ID）。

これらは後から分析するときの最小単位になる。「モデルAをBに変えたら平均品質はどう変わったか」「エラーが集中しているのはどの入力パターンか」「トークンコストを跳ね上げているのは誰か」といった問いに、後付けで答えるには、これらが揃っている必要がある。

個人情報の扱いを、最初に決める

プロンプトとレスポンスをそのまま保存すると、個人情報や機密データがログに大量に残る。「後で消せばいい」と考えるのは危険だ。編集部が観測した事故のいくつかは、この方針の欠如から起きていた。

推奨は、収集段階でマスキングする設計にすることだ。メールアドレス・電話番号・氏名などの特定パターンは、収集前に検知して置換する。マスキング後の情報だけを長期保管する。マスキング前の生データが必要な場合は、短期保管（例：7日）で自動削除する。セキュリティに関する記事でも触れたが、可観測性とセキュリティは同じ設計判断の別側面だ。

コストとレイテンシは、P99を見る

「平均レイテンシは2秒、平均コストは1回3円です」——この報告だけで運用が成り立つケースは少ない。エージェント構成では、応答時間もコストも、外れ値の分布が問題になる。

P50（中央値）、P90、P99を並べて追う。P99レイテンシが平均の10倍を超えていれば、ユーザーの一部は「よく詰まるシステム」と感じている。P99コストが平均の100倍なら、暴走しているエージェントが混じっている可能性がある。ダッシュボードに平均だけを載せると、これらは可視化されない。

アラートは、静的閾値ではなく前週比で

「エラー率が5%を超えたらアラート」のような静的閾値は、扱いやすいが、緩やかな悪化を見逃す。運用が始まってしばらくすると、「季節性」「時間帯」「特定ユーザー」のパターンが見えてくる。

編集部が観測した運用チームは、以下のように移行していた。エラー率・平均品質スコアが、前週の同じ時間帯より±30%ずれたときにアラート。特定モデル・特定ツールのエラー率が、他モデル・他ツールに比べて有意に高いときにアラート。トークン消費が、日別・週別の予算を超えそうなときにアラート。

ただし、ログは万能ではない

詳細なログは、事故の分析には役立つが、事前予防にはならない。ゴールデンセットでのオフライン評価、カナリアリリース、段階的ロールアウトなど、他の仕組みと組み合わせて初めて安全な運用になる。評価に関する記事もあわせて参照してほしい。

参考にした一次資料

• OpenTelemetry Project. “GenAI Semantic Conventions.” opentelemetry.io.
• Zaharia, M. et al. “The Shift from Models to Compound AI Systems.” Berkeley AI Research Blog, 2024.