Cloudflare Agents 発表：デプロイ済みエージェントの「中身」をトレースで見る

要約

Cloudflare が 2026-08-04、「Cloudflare Agents」を発表しました。デプロイ済みのエージェントセッションを 1 つの画面で管理・改善するためのプラットフォームで、第一弾の機能が Agent traces です。

エージェントを本番に出したチームが最初にぶつかるのは、「動いてはいるが、なぜその結果になったのか分からない」という問題です。ログを見てもモデルへ何を渡したのか、どのツールが何回呼ばれたのか、どこで時間とトークンを使ったのかが分かれて記録されていて、1 回のセッションを通して追えません。Agent traces はここを埋めます。

技術的な位置づけがはっきりしているのが特徴です。Workers のトレーシングは以前から KV、D1、service binding といったインフラ層を計測していました。Agent traces はその上に乗るエージェント層、つまりモデル呼び出し、ツール実行、承認（human-in-the-loop の承認ステップ）、トークン使用量、各ターンを計測します。両方が揃って初めてエンドツーエンドで見える、という組み立てです。

診断の入口は 2 つ用意されています。1 つはセッション再生で、全ターンの会話履歴をそのまま再生できます。「エージェントが何を見て何を返したか」を人間の目で追う用途です。もう 1 つはトレース表示で、実行をウォーターフォール図として時間軸に並べます。どのツール呼び出しが遅かったのか、どこで失敗したのかを構造で追う用途です。

対応フレームワークは Think、Flue、AI SDK。加えて OpenTelemetry 準拠であればカスタムハーネスでも取り込めます。特定 SDK に縛られない設計になっているのは、実運用のエージェントが複数の実装を混ぜがちであることを踏まえたものと読めます。

価格は明示されています。beta 期間中は無料で、2026-10-01 から Workers Observability の料金体系に統合されます。Free プランは 1 日 20 万イベント（保持 3 日）、Paid プランは月 200 万イベント無料、超過分は 100 万イベントあたり $0.60 です。

何が変わったか

• デプロイ済みエージェントのモデル呼び出し・ツール実行・承認・トークン使用量を、エージェント層のテレメトリとして計測できるようになった
• セッション再生（会話履歴）と実行ウォーターフォール図の 2 方式で診断できる
• 対応フレームワークは Think、Flue、AI SDK。OpenTelemetry 準拠のカスタムハーネスも可
• 有効化は Wrangler の設定。AI SDK を直接呼ぶ場合は名前空間をラップする
• 既存の Workers トレーシング（KV / D1 / service binding などインフラ層）と組み合わせてエンドツーエンドで追える
• beta 中は無料。2026-10-01 から Workers Observability 料金に統合（Free: 1日20万イベント・保持3日 / Paid: 月200万イベント無料・超過100万あたり $0.60）

業務インパクト（一般企業向け）

社内でエージェントを本番投入している、あるいは投入を検討している組織にとって、これは「作れるか」ではなく「運用できるか」の側の話です。エージェントは同じ入力でも毎回同じ経路を通らないため、障害報告が来たときに再現できないことが日常的に起きます。セッション再生があると、利用者からの「変な答えが返ってきた」という報告に対して、実際のターンを開いて確認する手順が作れます。サポート窓口と開発チームの間の受け渡しが具体化する、という意味で効きます。

コスト管理の観点も無視できません。トークン使用量がツール実行単位で見えると、「どのワークフローが高いのか」を推測ではなく実測で言えるようになります。エージェントの費用は月次請求では総額しか見えず、内訳を持たないまま予算を議論している組織が多いはずです。ここに数字が入ると、機能単位で続ける・止めるの判断ができます。

承認ステップが計測対象に入っている点も、稟議まわりに関係します。human-in-the-loop を組み込んだエージェントで「どの操作が何回人間の承認を経たか」が記録されていれば、内部統制や監査の説明材料になります。逆に言えば、承認を挟む設計にしていない組織は、記録するものがありません。

料金設計は導入判断に直結します。beta 中の無料と 2026-10-01 以降の従量課金には、はっきり区切りがあります。エージェントは 1 セッションで多数のイベントを吐くため、Free の 1 日 20 万イベントは検証には十分でも本番規模では足りない可能性があります。試すなら無料期間中に、実際のトラフィックでイベント数を測っておくのが現実的です。保持期間 3 日（Free）は障害調査には短いので、Paid 前提で考える方が安全です。

情シス視点では、可観測性を別の SaaS で組んでいる場合の重複が論点になります。OpenTelemetry 互換であれば既存の収集基盤へ流す選択肢も残るため、「Cloudflare 側で完結させるか、既存基盤に寄せるか」を先に決めておくと、あとで二重コストになりません。

副業・個人活用視点

個人開発でエージェントを作って納品する場合、この機能は「納品後の説明責任」を軽くします。クライアントから「先週こういう動きをしたらしいが」と言われたときに、該当セッションを開いて事実を確認できる状態は、口頭のやり取りだけで済ませるより信頼を作れます。提案書に「稼働後のトレースを共有します」と書けるのは、単価の根拠にもなります。

エージェント開発の受託では、見積もりの精度が課題になりがちです。トークン使用量がツール単位で見えると、「この機能を足すと月あたりいくら増える」を実測ベースで示せます。従量課金のツールを扱う案件では、この数字を持っているかどうかで見積もりの説得力が変わります。

学習用途としても価値があります。ウォーターフォール図でエージェントの実行を見ると、自分が書いたプロンプトやツール定義が実際にどう使われているかが分かります。ツールを 5 個定義したのに 1 個しか呼ばれていない、同じツールを無駄に 3 回呼んでいる、といった構造的な問題は、出力だけ見ていても気づけません。

beta 期間中が無料である点は、個人にとって特に大きい要素です。2026-10-01 以降は Free でも 1 日 20 万イベント・保持 3 日という制約が付くため、練習や検証は無料のうちに回数を回しておくのが得です。