AWS X-Ray で見る場所は 3 つ: サービスマップ・サブセグメント・ログのトレース ID
遅延調査で X-Ray を使うときは、サービスマップで遅い呼び出しを辿り、DB や外部 API をサブセグメントで個別に測り、トレース ID をログに出して突き合わせる。遅くなってから入れても比較対象がないので、平常時から入れておく。
3 つの見方
- サービスマップで「どこが伸びたか」を辿る。 サービス間の呼び出しがノードとして並び、平均レイテンシやエラー率が見える。全体が遅いとき、まずどの呼び出しが伸びたかを特定する。
- サブセグメントで中身を分けて測る。 1 つの Lambda や API の処理時間だけでは、DB 待ちなのか外部 API 待ちなのか分からない。DB クエリや外部 HTTP 呼び出しをサブセグメントとして計測しておくと、内訳が分かる（X-Ray SDK や OpenTelemetry の計装で AWS SDK・HTTP クライアントの呼び出しを自動で囲める）。
- トレース ID をログに出す。 アプリのログ（CloudWatch Logs など）に各リクエストのトレース ID を書いておくと、遅かったトレースから該当ログへ、エラーログから該当トレースへと行き来できる。
なぜ平常時から入れるか
問題が起きてから計装しても、「いつもは何ミリ秒だったか」という基準がない。普段の値があって初めて、どこが伸びたかを比べられる。
注意点
- サブセグメントを細かくしすぎるとトレースが読みにくくなる。まずは DB と外部 API など「待ち」が発生する境界から。
- サンプリングされているので、全リクエストのトレースが残るわけではない。ログのトレース ID から辿れないこともある前提で使う。
- Cloudflare Workers 側の同じ考え方（スパンの付け方）は Workers のトレースで trace ID をレスポンスに返し、ルート名でスパンを付け直す（spanContext() / setStatus() / updateName()） を参照。
出典
- @dkfj · 2026-11-07 （AWS 認定デベロッパー本の紹介を兼ねた投稿）