Tracing

Tracingとは、一つのrequestや処理を構成する個々のoperationをspanとして記録し、serviceやprocessをまたぐ因果関係と時間の流れを追跡する仕組みです。

Tracingとは何か

Tracingは、一つのrequestや処理がシステム内をどのように進んだかを、時間と因果関係を保ったまま追跡する仕組みです。分散システムでは、userの一回の操作がAPI、database、cache、検索service、model serverなど多数のcomponentを通ります。Tracingを使うと、それらを「同じ一回の処理」としてつなげて見ることができます。

OpenTelemetryでは、一つのlogical operationに由来する一連の処理をdistributed traceとして扱います。Traceは複数のspanから構成され、span同士の親子関係などによって処理の流れを表します。

Spanとは何か

SpanはTraceを構成する一つのoperationです。たとえばWeb APIがrequestを受けたspan、その中でdatabaseへqueryしたspan、LLMへrequestしたspan、toolを呼び出したspan、というように処理を分解します。

OpenTelemetryのTrace APIでは、Spanはoperation名、開始・終了時刻、attribute、event、status、親spanなどを持ちます。SpanContextにはTraceIdとSpanIdが含まれ、これらを使って「どのtraceのどのoperationか」を識別します。

Trace全体を見ると、どのspanにどれだけ時間がかかり、どこでerrorが発生し、どのoperationがどのoperationから呼ばれたかが分かります。

分散システムでどうつながるのか

一つのserviceから別のserviceへHTTP requestを送ると、processもmachineも変わります。それでも同じTraceとして追うには、trace情報を次のserviceへ伝える必要があります。これがcontext propagationです。

OpenTelemetryは、context propagationによってprocessやnetwork境界を越えてsignalsを相関できると説明しています。たとえばAPI Gatewayが受けたTraceIdをmodel serverまで伝えれば、別machineで動いていても同じuser requestの一部として関連付けられます。

逆にpropagationが途切れると、同じrequestなのに別traceに見えます。分散環境で「途中からtraceが消える」問題は、instrumentationだけでなくcontext propagationを確認する必要があります。

LogsやMetricsとの違い

Logは「何時何分にこのerrorが起きた」という個別eventを詳しく記録できます。Metricは「1分あたりrequest 1000件」「p95 latency 420ms」のように数値を集約します。

Traceはその中間ではなく、別の視点です。「このrequestはAPIで20ms、retrievalで180ms、LLMで2.1秒、tool callで300msかかった」という一連の経路を示します。

Metricでlatency悪化を検出し、Traceで遅いrequestの場所を特定し、Logで該当serviceの詳細errorを見る、という使い方が典型です。

AIエージェントでTracingが重要な理由

AI agentは、一回のuser requestの中で多数のstepを実行します。LLMへ計画を依頼し、検索し、toolを呼び、結果を読み、再度LLMへ渡し、失敗すればretryすることがあります。

最終応答が遅いだけでは、どこが原因か分かりません。Tracingで、model call、retrieval、tool call、API access、retryを個別spanとして記録すれば、どのstepが遅いか、どこで失敗したか、何回繰り返したかを調べられます。

RAGでも、embedding、vector search、reranking、generationを別spanにすると、「検索が遅いのか」「LLM generationが遅いのか」を切り分けられます。Cost情報をattributeに加えれば、遅延だけでなく費用の集中点も分析できます。

TracingはChain-of-Thoughtではない

AI文脈で特に注意したいのが、「Tracing＝モデルの思考を読む」という誤解です。Operational tracingが記録するのは、system上で観測できるoperationです。Model request、tool call、retrieval query、latency、statusなどをspanとして残すことはできます。

しかし、それはモデル内部の非公開な推論過程やChain-of-Thoughtをそのまま取得することとは別です。製品が「agent traceを表示」と説明している場合も、何が記録されているかを確認する必要があります。外部に表現されたplanやtool selectionを記録しているのか、単にAPI call sequenceを記録しているのかで意味が変わります。

Tracingの画面が詳細でも、「モデルの内部 reasoning が完全に可視化された」と推論してはいけません。

SamplingとCost

すべてのrequestを詳細traceすると、データ量が非常に大きくなることがあります。そこで一定割合だけtraceするhead samplingや、結果を見てから重要traceを残すtail samplingなどが使われます。

Samplingがあると、「traceに見つからないrequest＝起きていない」とは限りません。障害調査でtraceを使うときはsampling rateと方針を確認する必要があります。

また高cardinalityなattributeを大量保存すると、Observability backendのcostが増えることがあります。必要な診断情報と運用costのバランスが必要です。

PrivacyとSecurity

AI tracingではprompt、response、retrieved document、tool argumentを記録したくなる場合があります。しかしそれらには個人情報や機密情報が含まれ得ます。

Trace backendは本番databaseと別のaccess controlになっていることもあり、「debug用だから」と詳細情報を保存すると、別経路の情報漏えいになります。Redaction、masking、retention、role-based accessを設計する必要があります。

TraceIdそのものも、外部へ無制限に露出させるのではなく、system設計に応じて扱います。Context propagationでは他serviceへ情報を渡すため、trust boundaryを越える場合のpolicyも重要です。

元の文脈で何を見るか

「Tracing対応」と書かれていたら、まず何をspanとして記録するかを確認してください。HTTPだけなのか、database、LLM、retrieval、tool callまで含むのかで価値が違います。

次に、TraceIdがserviceを跨いでpropagateするか、samplingは何%か、どのattributeを保存するか、何日保持するかを見ます。AI systemならprompt/responseを保存するか、PIIをmaskするかも重要です。

Tracingは、systemの挙動をrequest単位で追跡する強力な方法ですが、それ自体がmodel qualityを評価する仕組みではありません。一つの処理がどこを通り、何に時間を使い、どこで失敗したかを因果関係付きで追うObservability signalとして理解すると、AI運用の文脈で誤解しにくくなります。

関連AI用語

• G255 — Observability
• G191 — AIエージェント
• G202 — Tool Calling

注・出典

主要参照資料：^[1][2][3]

1. OpenTelemetry Overview — distributed traceは一つのlogical operationに起因するeventを複数componentにまたがって統合し、spanのDAGとして表現される。 ↩
2. OpenTelemetry Trace API — Spanはtrace中の単一operationを表し、TraceId、SpanId、parent、timestamps、attributes、events、status等を持つ。 ↩
3. OpenTelemetry Context Propagation — context propagationによりprocessやnetwork境界を越えてsignalsを相関し、distributed tracingの因果関係を構成できる。 ↩

AI協働制作について