Cloudflare Agent Tracing、モデルやツール実行を可視化

概要

AgentがHTTP 200を返しても、処理が正しかったとは限らない。誤ったツールを選んだり、古いコンテキストをSubagentに渡したり、リトライを繰り返してTokenを消費したりする可能性がある。従来のアプリケーション監視はFetch、KV、D1などの処理を示せても、どのAgentの判断が問題を生んだのかまでは説明しにくい。CloudflareのAgent Tracingは、その空白を埋めるための機能だ。

Agentの判断を追跡

Agent TracingはWorkers Tracingを基盤に、各インタラクションへAgentレベルのSpanを追加する。Agentの呼び出し、モデル呼び出し、ツール実行、ツール承認を階層化し、モデル情報やToken使用量をメタデータとして表示する。親AgentがSubagentへ作業を委任し、Subagentがモデルやツールを呼び出し、D1を読み、KVへ書き込む場合も、両者の処理を一つのウォーターフォールで確認できる。

Dashboardでは、Agent nameが論理的な実装、Agent IDが個別インスタンス、Conversation IDが会話を識別する。リクエストやユーザー識別子からAgent nameを動的に生成すると、Dashboard上に大量のAgentが作られるため、Cloudflareは避けるよう説明している。

Session Replayでは、複数ターンにまたがる記録済みのメッセージ、推論、ツールの引数と結果、Subagentの活動を再構成できる。ただし、これは保存データの再生であり、Agentを再実行するものではない。またApproval Spanは一つのWorker invocation内部のライフサイクルを表すだけで、複数のinvocationをまたいでユーザーが返答を待つ時間は含まない。人間による承認の全遅延を測る指標ではない点に注意が必要だ。

Payloadの既定値に差

フレームワークごとにPayloadの扱いが異なる。

• Thinkは、Agent classでstoreMessagesとstoreToolsを有効にしない限り、メッセージとツールPayloadを保存しない。
• wrapAISDK()も同じ既定動作である。
• Flueはメッセージ、システム指示、ツール定義、引数、結果を標準で保存し、停止するにはcontent: falseを設定する。

Payloadには個人情報、Secret、内部指示が含まれる可能性がある。導入時には保存範囲だけでなく、マスキング、権限、保持期間も確認しなければならない。

切り詰めと料金

CloudflareはTraceを完全で無損失な会話記録とは位置付けていない。Spanサイズの制限により、長いメッセージ、推論、ツール引数や結果は切り詰められる可能性があり、Session Replayは画像も表示しない。したがって、主用途はデバッグであり、完全な監査記録として扱うには制約がある。

ThinkとFlue v2以降は各ターンを自動計測する。AI SDKを直接利用する場合はwrapAISDK()で包み、Agentインスタンスがないため各呼び出しに識別情報を渡す必要がある。独自HarnessではWorkers Custom Spans APIを使い、OpenTelemetryのGenAIセマンティック規約を参照する。Traceは任意のOTLP Endpointへ出力できるが、Workersは現在OpenTelemetry APIを直接サポートしておらず、対応は開発中だという。

Beta期間は無料だが、2026年10月1日からWorkers Observabilityの課金対象になる。Workers Freeは1日20万Event、保持期間3日、Workers Paidは月2,000万Event、保持期間7日で、超過分は100万Eventあたり0.60ドル。Agents画面に表示されないSDK内部やWorker層のSpanも課金単位に含まれる。

意味すること

この発表は、Agentにはインフラ監視とは別のテレメトリが必要だという流れを示している。モデル選択、ツール引数、承認、Token消費を一つの流れで見られる一方、Payloadのプライバシー、切り詰め、承認待ち時間の欠落、保持期間、料金を同時に設計しなければならない。

出典：InfoQ 中文