9月11日、Mark Silvesterが「Session Traces and Cost Controls Help Diagnose AI Agent Failures」と題した記事を公開した。本記事はStackGenのプリンシパルエンジニアであるSabith K Soopy氏が2026年8月4日にCNCF(Cloud Native Computing Foundation)のメンバーブログとして公開した投稿を元ネタとしており、AIエージェントが本番環境で誤動作した際の原因究明に有効なセッショントレースとコスト制御の実践手法を紹介している。
「アラートが鳴らない障害」がAIエージェントの本質的な難しさ
AIエージェントが誤った処理を繰り返しても、従来の死活監視には引っかからない。これがAIエージェント運用の核心的な問題だ。
サービスの可用性は正常でも、エージェントが同じツールを何度も呼び出したり、存在しないエンドポイントを叩き続けたり、実際には実行していないタスクを「完了」と報告したりする。標準的なアプリケーション監視はこうした挙動を検知できない。
Soopy氏は「最も難しいのはエージェントを構築することではなく、何かが壊れたときに何をしているのかを理解することだ」と述べており、本番運用での数ヶ月の経験をもとに具体的な手法をまとめている。
セッショントレース:マルチエージェントの委譲チェーンを丸ごと記録する
StackGenはLangfuseを使ってネストされたセッショントレースを取得している。LLM呼び出し、ツール実行、サブエージェントへの委譲のそれぞれが、実行レイテンシとトークンコストを付与した個別のスパンとして記録される。
重要なのは、子スパンを親トレースの下にネストすることで、複雑なマルチエージェントワークフロー全体にわたる委譲チェーンを保持できる点だ。LLMがどのサブエージェントに何を委ねたのか、その連鎖を後から追うことができる。
実装上の注意点として、テレメトリバックエンドが一時的にダウンした際にエージェントの実行をブロックしないよう、非同期バッチエクスポーターの利用が推奨されている。スパンをメモリにキューイングして定期的にフラッシュする構成にすることで、バックエンド障害時にはトレースデータが欠落するだけで、エージェント本体への影響を避けられる。
コスト制御:暴走実行への第一の防衛線
コスト制御は、エージェントが際限なく実行し続ける「暴走」を防ぐための主要な運用上の安全弁として位置付けられている。具体的には以下が推奨されている:
- 実行前にイテレーション上限とツール呼び出し回数の上限をハードコードする
- 連続した同一ツールリクエストを事前チェックでブロックする
単純な繰り返しは連続呼び出しブロックで対処できるが、より複雑なケースには統計的監視を組み合わせる。各エージェントのローリング平均コストとセッションコストを比較することで、モデルルーティングエラー、ツールのハルシネーション(存在しないツールを呼び出したり、実行していない操作を「実行した」と返したりするAI固有の誤り)、マルチターン対話でのコンテキスト無制限膨張といった遅発性の異常を検出できる。
高速で並列実行されるエージェントに対しては、リアクティブなアラートだけでは手遅れになると同氏は指摘している。
事後分析のための追記専用ログとCLI診断ツール
インシデントの事後レビューには、ツール呼び出し・ガバナンス判断・メモリ操作を追記専用で検索可能なログに書き出すことが推奨されている。保存前に認証情報と個人識別情報(PII)はリダクション処理を行う。
StackGenはこれに加え、CLIの診断ツールを内製している。モデルAPIへのアクセス可否、ベクターデータベースの疎通確認、承認待ちタスクの有無、メモリカウント、トレースバックエンドの接続状態、各種インテグレーションの健全性を1回の実行でまとめて検証できる。
メトリクスとトレースの役割分担:高カーディナリティ問題に注意
完成したトレースは自動アナライザーを通じて実行時間・ツール失敗・リトライ回数・トークン効率の問題をフラグ立てして人間のレビューに回す。ツールエラー率や承認レイテンシのヒストグラムといった指標はPrometheusへエクスポートする構成が推奨されている。
ここで重要な警告がある。動的なセッションIDをメトリクスのラベルに入れると高カーディナリティ(ラベルの組み合わせが爆発的に増加し、メトリクスサーバーのリソースを圧迫する状態)の時系列が生成され、メトリクスサーバーをクラッシュさせる可能性があるという点だ。セッションレベルの細粒な文脈はトレースか構造化ログに置くべきであり、同記事はこれを端的に「トレースはデバッグのため、メトリクスはアラートのため」と表現している。
周辺ツールのエコシステム
標準化の観点では、OpenTelemetryのジェネレーティブAIセマンティック規約がモデル操作・トークン消費・ツール呼び出しの標準属性を定義しており、テレメトリバックエンド間で一貫したスキーマを提供する。
評価ツールとしては、LangSmithが本番の異常トレースを回帰ベンチマーク用のテストデータセットに変換する機能を持つ。オープンソースのArize PhoenixはOpenTelemetryネイティブなトレーシングとセルフホスト型のLLM-as-a-judge評価、プロンプト実験を組み合わせて提供している。
詳細はSession Traces and Cost Controls Help Diagnose AI Agent Failuresを参照していただきたい。