AIエージェントで障害が起きたとき、「モデルが遅い」「Workerが失敗した」という個別ログだけでは、利用者への説明になりません。利用者の依頼が、どの処理を経由し、どこで待ち、どの副作用を起こさずに止まったかを、一つの追跡線として説明できる必要があります。
結論は、入口の要求にアプリケーション固有のrequest IDを付け、非同期処理のjob IDと分け、分散処理には標準のtrace IDを渡すことです。ただし追跡可能性を上げようとして、プロンプトや応答本文を無制限に残してはいけません。trace、運用ログ、監査イベント、AI Gatewayログの役割を分けることで、障害調査とデータ最小化を両立できます。
モデルのログだけでは利用者の障害を説明できない
AI Gatewayは、要求ごとのprovider、token使用量、cost、duration、prompt、model responseなどを記録できます。モデル呼出しの状態を見るには有用です。一方で、利用者が「回答が返らなかった」と問い合わせたとき、原因が入力検証、認可、Queue待ち、Workerの外部API呼出し、モデル応答、保存処理のどこにあるかは、Gateway単体では分かりません。
追うべき対象は「LLM APIの一回の呼出し」ではなく、利用者の目的を完了するまでの処理です。たとえば経費精算の下書きを作るエージェントなら、画面からの依頼、ファイル取得、社内API検索、モデル呼出し、下書き保存、承認待ちを一続きで調べられるようにします。そこで必要になるのが、用途の異なるIDを混ぜずに結ぶ設計です。
IDを用途ごとに分けて、相互に結ぶ
request IDは利用者の一回の依頼を表す
入口で推測不能なrequest IDを発行し、画面表示、APIレスポンス、アプリケーションログに残します。問い合わせ番号にも使えるため、顧客名、メールアドレス、プロンプト本文をIDへ埋め込んではいけません。IDは照合のための値であり、業務データを運ぶ箱ではありません。
job IDは再実行可能な非同期処理を表す
QueueやWorkflowへ渡す処理にはjob IDを持たせます。同じrequest IDから複数jobが派生することも、同じjobが再試行されることもあります。request IDとjob IDを同一視すると、冪等性（何度実行しても結果が同じ性質）や再実行の調査が難しくなります。両者の対応だけを状態データとして残せば、利用者要求と処理単位を行き来できます。
trace IDは処理時間と依存先をつなぐ
W3C Trace Contextのtraceparentは、異なるサービスや観測基盤の間でtraceを伝播する標準です。Cloudflare Workersのtracingは、fetch、KV、R2、Durable Objectsなどを自動計測できます。外部HTTP呼出しや後続Workerへtrace contextを渡し、request ID・job IDをspan属性または構造化ログで参照できるようにすると、「待っていた場所」と「業務上の依頼」を結べます。
IDを一つに統合する必要はありません。用途の違うIDを無理に兼用するより、最小限の対応表を残す方が、再試行と障害調査の両方に強くなります。
trace、運用ログ、監査イベントを混ぜない
traceは、要求がどのサービスを何秒使ったかを調べる時系列の経路です。通常成功の性能改善、外部依存の遅延、失敗箇所の特定に向きます。運用ログは、job_started、tool_call_failed、model_timeoutのように処理状態を調べる記録です。OpenTelemetryも、状態変化や例外など意味のある時点をeventとして表す考え方を示しています。
監査イベントは、「誰の権限で、何を変更・送信・削除しようとしたか」を後から説明する記録です。traceのサンプリング対象に任せず、外部送信や更新など高リスク操作について、別の保持・閲覧権限・削除基準を決めます。
AI Gatewayログはモデル運用のための観測経路です。既定で記録するか、要求ごとに記録を切り替えるかを選べます。promptやresponseを保存する場合も、障害調査に必要な範囲を超える本文を常時保持しないようにします。OpenTelemetryのGenAI semantic conventionsも、会話ID、入力メッセージ、出力メッセージには機微情報が入り得ると注意しています。
サンプリングと保持期間は別に決める
Cloudflare Workersのtracingはhead samplingを設定できます。通常成功のtraceを全件保存しないことは、運用コストと調査ノイズを抑える手段です。ただし、サンプリングされなかった要求について「障害は起きていない」とは言えません。
成功の性能分析はtraceの標本で行い、エラー、外部副作用、承認待ち、失敗したjobの状態は、必要最小限の構造化イベントとして別に残します。本文を保存しない場合でも、request ID、job ID、操作種別、結果、失敗分類、時刻があれば、多くの一次調査は可能です。
2026年9月7日時点で、Cloudflare WorkersのOpenTelemetry exportはbetaです。traceとlogを対象とする一方、metrics exportは未対応とされています。料金、保存期間、対応先、betaの制約は更新され得るため、実装時に公式仕様を再確認してください。
実装前チェックリスト
- 入口で推測不能なrequest IDを発行し、個人情報をIDへ含めていないか
- 非同期処理のjob IDとrequest IDを分け、対応関係を記録しているか
- Worker、外部HTTP、AI Gatewayをtrace contextでつなげるか
- prompt・response本文を既定で保存する必要性を、データ分類ごとに説明できるか
- timeout、cancel、retry、approval expiredを固定した失敗分類で記録するか
- 外部送信・更新・削除は、性能traceとは別の監査イベントにしているか
- 保存期間、削除手順、ログ閲覧権限をデータ管理者と合意しているか
限界：可観測性は品質・認可・個人情報保護の代替ではない
traceがつながっても、モデルが正しい回答を出したか、ツール実行を許可してよかったか、prompt injectionを受けていないかは分かりません。可観測性は「何が起きたかを調べる能力」であり、認可、承認ゲート、入力検査、データ削除の代わりにはなりません。
また、ログを増やせば調査しやすくなる一方で、保存データと閲覧可能者も増えます。本文を保存する設計は例外扱いにし、目的・保持期間・アクセス権を先に決めるべきです。
AI基盤設計・セキュリティ相談
AIエージェントの障害追跡、ログ最小化、Cloudflare WorkersとAI Gatewayをまたぐ運用設計を整理したい方は、AI基盤設計・セキュリティ相談をご利用ください。
一次情報と確認範囲
確認日：2026年9月7日。Cloudflareの製品仕様は変更され得るため、導入時は最新版を確認してください。
| 機関・仕様 | 確認した範囲 | URL |
|---|---|---|
| Cloudflare Workers | OpenTelemetry exportの対象、beta上の制約、metrics未対応 | Exporting OpenTelemetry Data |
| Cloudflare Workers | 自動計測とhead sampling | Traces |
| Cloudflare Workers | ログの収集・外部送信の選択肢 | Workers Logs |
| Cloudflare AI Gateway | ログ項目と要求単位の記録制御 | Logging |
| W3C | traceparentとtracestateによるtrace伝播 | Trace Context |
| OpenTelemetry | GenAI属性の機微情報リスク | GenAI semantic conventions |
| OpenTelemetry | 状態変化・例外をeventとして表す考え方 | Semantic conventions for events |
一次情報と確認範囲
確認日：2026年9月7日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。