AWS X-Rayは、1本のリクエストが API Gateway、Lambda、ECS、DynamoDB といった複数のサービスをどう通過したかを記録し、どこで時間を使い、どこで失敗したかを追跡する分散トレーシングのサービスです。ただし2026年7月時点で「X-Ray SDKを入れてX-Rayデーモンを動かす」という定番の手順は、これから書くコードに対しては選ぶべきではありません。AWSは2026年2月25日にX-Ray SDKとデーモンをメンテナンスモードへ移し、計装の標準をOpenTelemetryへ移行しました。検索で出てくる解説の大半はこの変更の前に書かれています。この記事では、X-RayとCloudWatchの役割分担、いま採るべき計装経路、サンプリング設計の落とし穴、東京リージョンの実額を、公式ドキュメントの記述に沿って整理します。
まとめ：2026年のAWS X-Rayで押さえる5点
- X-Rayが担うのはトレース：CloudWatchがメトリクスとログを担い、X-Rayがサービス間をまたぐリクエストの経路（セグメント／サブセグメント）を担う。この役割分担自体は変わっていない。
- ただし入口はCloudWatchに寄った：X-Rayのサービスマップと旧ServiceLensのマップは統合され、CloudWatchコンソールの「X-Ray traces」配下のTrace Mapになった。サンプリングルールもCloudWatchコンソールから設定できる。
- SDKとデーモンは2026年2月25日にメンテナンスモード、2027年2月25日にサポート終了：この1年はセキュリティ修正のみで新機能は追加されない。公式の推奨は OpenTelemetry SDK／ADOT による計装と、CloudWatchエージェントまたはOpenTelemetry Collectorによる収集。
- Transaction Searchはサンプリングを100%にしてくれる機能ではない：スパンを全量ログとして保持したいなら、ヘッドサンプリング率を自分で100%に設定する必要がある。
- 異常時だけ記録率を上げるアダプティブサンプリングはADOT限定：
SamplingRateBoostで平常時5%・異常時25%といった設定ができるが、ルートサービスがADOT SDK（Java／Python）で動いていないと発動しない。 - 料金（東京）：トレース記録が100万件あたり5.00 USD、取得・スキャンが100万件あたり0.50 USD。月10万トレースまでは記録が無料。
料金と機能は改定されます。設計に入る前にAWS公式の料金ページとX-Rayデベロッパーガイドで最新値を確認してください。
X-RayとCloudWatchの違い
「AWS X-Ray CloudWatch 違い」は、この記事に実際に流入している検索クエリのなかで唯一クリックを獲得しているものです。それだけ両者の線引きが分かりにくいということでもあります。
担うテレメトリの種類が違う
CloudWatchはメトリクス（数値の時系列とアラーム）とログ（CloudWatch Logs）を扱う監視基盤です。「Lambdaのエラー率が5%を超えた」「レスポンスタイムのp99が悪化した」といった、集計された数値の異常はCloudWatchが検知します。一方でX-Rayが持つのはトレース、つまり個々のリクエストがどのサービスを何ミリ秒で通ったかという1本ごとの経路です。エラー率の上昇に気づくのがCloudWatch、その5%が「DynamoDBへの特定クエリで詰まっている」と特定するのがX-Ray、という関係になります。
X-Rayのデータモデルでは、1サービスの処理区間をセグメント、その内側のSDK呼び出しやHTTPリクエストをサブセグメントと呼びます。OpenTelemetryの用語ではセグメントがサーバースパン、サブセグメントがそれ以外のスパンに対応します。
コンソールと課金の入口はCloudWatch側へ統合された
「別サービスとして使い分ける」という説明は、いまの実態からずれています。AWSはCloudWatchのドキュメントで、X-Rayのサービスマップと ServiceLens のマップはCloudWatchコンソール内のX-Ray trace mapに統合されたと明記しています。サンプリングルールの設定も同じくCloudWatchコンソールから行えます。X-Rayコンソール自体が廃止されたわけではなく、AWSは既存のX-Rayコンソール体験を引き続きサポートすると表明していますが、新しい導線はCloudWatch側に置かれていると理解しておくのが実務的です。
その上に載るのがCloudWatch Application Signalsです。EC2・ECS・EKS・Lambdaから可用性・レイテンシ・エラー・呼び出し量といった標準メトリクスを自動収集し、SLOの設定とアプリケーショントポロジーの自動検出を提供するAPM層で、対応言語はJava・Python・Node.js・.NET。異常を見つけたらそこから相関するX-Rayトレースへ降りていく、という使い方になります。詳しくはApplication Signalsとは何か？概要と基本機能をやさしく解説で解説しています。
| 担当 | CloudWatch | AWS X-Ray |
|---|---|---|
| データ | メトリクス・ログ | トレース（セグメント／サブセグメント） |
| 得意 | 異常の検知・通知 | 異常箇所の特定・原因究明 |
| 粒度 | 集計値 | リクエスト1本 |
| UI | CloudWatchコンソール | CloudWatchコンソール内 Trace Map |
| 計装 | エージェント・SDK | OpenTelemetry（推奨） |
X-Ray SDKとデーモンのメンテナンスモード移行
ここが、既存の日本語記事との最大の差分です。
2つの期日：メンテナンスモードとサポート終了
AWSはX-Rayデベロッパーガイドに「X-Ray SDK and Daemon Support timeline」というページを設け、一般提供の終了日を2026年2月25日、同日からメンテナンスモード開始と明示しています。メンテナンスモード中の扱いは「セキュリティ問題への対応のみリリースし、新機能の追加は行わない」。そしてサポート終了（EOS）は2027年2月25日です。この日以降、SDKとデーモンの更新もリリースも行われません。移行の実質的な締切はこの日と考えてください。
同じページでAWSは「アプリケーションの計装とX-Rayへのトレース送信は、OpenTelemetryソリューションへ移行することを推奨します」と述べています。移行ガイドでも、新規・既存いずれのアプリケーションについても、計装はOpenTelemetry SDKまたはADOT（AWS Distro for OpenTelemetry）、収集はOpenTelemetry CollectorまたはCloudWatchエージェント、という推奨が示されています。
いま動いているX-Ray SDKをどうするか
明日止まるわけではありません。AWSは「メンテナンスモードに入っても、X-Rayは既存のX-Ray SDKとデーモンからのトレースを引き続き受け付け、処理する」と明言しており、X-Ray APIもコンソールも従来どおり動きます。移行後もCloudWatchコンソールのTracesとTrace Mapの見え方は変わりません。ただし2027年2月25日以降はセキュリティ修正すら来なくなるため、それまでに移行を終える計画は立てておく必要があります。
次のいずれかに当てはまるなら、前倒しすべきです。第一に、これから新しくサービスを計装する場合。X-Ray SDKで書いた計装は将来ADOTへ移し替える二度手間になります。第二に、Application SignalsのSLOやサービスマップ、後述のアダプティブサンプリングを使いたい場合。これらはOpenTelemetryベースの計装を前提としており、X-Ray SDKのままでは使えません。第三に、AWS以外のバックエンド（Datadog、Grafana Tempoなど）へも同じトレースを送る可能性がある場合。OpenTelemetryなら計装コードを変えずにエクスポーターの差し替えだけで済みます。OpenTelemetry自体の構成要素はOpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説で整理しています。
OpenTelemetryでX-Rayへトレースを送る手順
「x-ray 使い方」で来た読者が2026年に見るべき手順はこちらです。送信経路は3つあり、どれを選ぶかで構成が変わります。
送信経路は3択
| 経路 | 要件 | 向く場面 |
|---|---|---|
| CloudWatchエージェント | 1.300025.0以降 | EC2・ECS／エージェント削減 |
| OTel Collector | awsxray exporter | 他バックエンドへも送る |
| OTLPエンドポイント直送 | SigV4署名 | Collectorを立てない小規模構成 |
3つ目のOTLP直送は、AWSがCloudWatch側にOTLPエンドポイントを用意したことで可能になりました。トレースの宛先は https://xray.<Region>.amazonaws.com/v1/traces で、HTTPのみ対応（gRPCは非対応）、SigV4署名が必須です。Collectorから使う場合は sigv4authextension が要ります。1リクエストあたり非圧縮5MB・最大10,000スパン、単一スパン200KBという上限があるため、大量のスパンを吐くバッチ処理ではCollectorを挟んでバッチ制御したほうが安全です。
ECS（Fargate）でのサイドカー構成
従来のX-Rayデーモンのサイドカーを、CloudWatchエージェントまたはOTel Collectorのコンテナに置き換えます。デーモンと同居させるとポート2000が競合するため、既存デーモンは停止してから切り替えます。アプリ側は環境変数でCollectorを指すだけです。
ENV OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4318/v1/traces
ENV OTEL_SERVICE_NAME=checkout-api
ENV OTEL_TRACES_SAMPLER=xrayCollector側の最小構成は次のとおりです。OTLPレシーバ（4317／4318）、X-Rayのサンプリングルールを取得するための awsproxy エクステンション（127.0.0.1:2000）、awsxray エクスポーターの3点で足ります。
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
extensions:
awsproxy:
endpoint: 127.0.0.1:2000
exporters:
awsxray:
region: ap-northeast-1
service:
extensions: [awsproxy]
pipelines:
traces:
receivers: [otlp]
exporters: [awsxray]タスクロールには xray:PutTraceSegments と xray:PutTelemetryRecords が必要です。Javaアプリの計装例はSpring Boot Starterを使用したOpenTelemetryの導入プロセスが参考になります。
アノテーションとメタデータの扱いが変わる
X-Ray SDKでは、検索対象にしたい値をアノテーション、検索対象にしない補足情報をメタデータとして明示的に書き分けていました。OpenTelemetryにはこの区別がなく、すべてスパン属性（attributes）です。そのためOTelの属性は既定でX-Ray側のメタデータへ変換され、そのままではフィルタ式で検索できません。アノテーションとして扱わせたい属性は、aws.xray.annotations という属性にキー名を列挙して指定します。移行時にトレース検索が効かなくなる原因はほぼこれです。
Lambdaのトレース有効化
Lambdaは従来どおりアクティブトレーシング（Active／PassThroughの2モード、既定はPassThrough）で、CLIなら --tracing-config Mode=Active です。コンソールの導線は「CloudWatch Application Signals and AWS X-Ray」に変わりました。実行ロールには AWSXRayDaemonWriteAccess を付与します。
重要な制約として、Lambdaのサンプリング率は毎秒1リクエスト＋追加分の5%に固定されており、変更できません。公式ドキュメントが「関数のX-Rayサンプリングレートは設定できない」と明記しています。全量トレースが要る場合はLambda自身の設定ではなく、OpenTelemetryレイヤー側のサンプラーで制御することになります。なおMSK、セルフマネージドKafka、Amazon MQ、DocumentDBのイベントソースマッピングはX-Rayトレースに対応していません。Lambda周辺の監視設計はAWS Lambda関数のモニタリングに必要な基礎知識と概要で補足しています。
サンプリング設計の落とし穴とアダプティブサンプリング
つまずきやすい2つの仕様
X-Rayの既定は「毎秒最初の1リクエストを記録し、それを超えた分は5%を記録する」です。前者をリザーバ、後者をレートと呼び、ルールにはPriority（1〜9999、小さいほど先に評価）、Service name、URL path などの条件を設定できます。ここで事故が起きやすいのが次の2点です。
ひとつはサンプリング判断がトレースの最初のサービスで一度だけ行われること（ヘッドベース）。下流サービスに「このAPIだけ100%記録する」というルールを書いても、上流が記録しないと決めたリクエストは下流でも記録されません。AWS自身がこれを”よくある落とし穴”として挙げています。ルールは必ずリクエストの入口となるサービスに対して書きます。
もうひとつはローカルのJSONファイルでルールを定義した場合、各インスタンスが独立にサンプリングすること。リザーバ1req/秒のつもりでも、10インスタンスあれば実質10req/秒になります。コンソール（X-Rayサービス側）でルールを定義すれば、サービスがリザーバのクォータを各インスタンスへ配分するため、意図した量に収まります。
異常時だけ自動で記録率を上げる（ADOT限定）
「低いサンプリング率だと障害時のトレースを取り逃す、かといって常時100%は高い」というジレンマに対して、X-Rayにはアダプティブサンプリングが用意されています。サンプリングルールに SamplingRateBoost を足しておくと、X-RayがHTTP 5xxやレイテンシ異常を検知したときだけ、設定した上限まで自動で記録率を引き上げます。
{
"RuleName": "MyAdaptiveRule",
"Priority": 1,
"ReservoirSize": 1,
"FixedRate": 0.05,
"SamplingRateBoost": {
"MaxRate": 0.25,
"CooldownWindowMinutes": 10
}
}この例では平常時5%、異常検知時は最大25%まで自動で上がります。ブーストは異常検知から最短10秒で始まり、最長1分続いたあと基準レートへ戻り、クールダウン期間中は再発動しません。効果を確認したければ、CloudWatchメトリクスの AWS/X-Ray 名前空間に SamplingRate（ディメンションは RuleName）が出るのでそれを見ます。
重要な制約が2つあります。この機能はADOT SDKでしか動きません（対応言語はJavaのv2.11.5以降とPythonのv0.15.0以降）。X-Ray SDKのままでは使えず、既定のサンプリングルールにも適用できません。もう1つ、ブースト判断はルートサービスが行うため、入口のサービスがADOT SDKで動いていないとブーストは一切起きません。異常時の可視性を求めてOTelへ移る理由としては、これが一番具体的です。
Transaction Searchの採否判断
2024年11月21日にGAとなったCloudWatch Transaction Searchは、トレーススパンを構造化ログとしてCloudWatch Logsの aws/spans ロググループに保存する機能です。スパンがログ基盤に載るため、メトリクスフィルタ、サブスクリプションフィルタ、データマスキング、Logs Insightsといった既存のログ機能をそのままトレースに使えます。有効化はアカウント単位で aws xray update-trace-segment-destination --destination CloudWatchLogs、反映に最大10分かかります。
「100%取り込み」の誤解
公式の説明文が「Ingest 100 percent of spans」と書いているため、有効化すれば全量が取れると読まれがちですが、これは正確ではありません。AWSのドキュメントは完全な可視性を得るにはヘッドサンプリング率を自分で100%に設定する必要があると明記しています。X-Ray／ADOTのSDKならコンソールのサンプリングルールで固定レートを100%に、OpenTelemetry SDKならAlwaysOn相当のサンプラーに変更します。ここを設定しないまま「Transaction Searchを入れたのにトレースが欠ける」となるのが典型的な躓きです。
取り込んだスパンのうち、X-Ray側でトレースサマリとしてインデックスされるのは既定で1%（この分は無料）。インデックス率は aws xray update-indexing-rule で変更できます。トレース検索・分析・Trace Insightsが使えるのはインデックスされた分です。
採用の判断基準
Transaction Searchが効くのは、エラーの再現性が低く、サンプリングから漏れた1件を後追いしたいケースです。「特定のテナントIDのリクエストだけが失敗する」「1日に数回だけタイムアウトする」といった調査で、5%サンプリングは無力になります。全スパンがログにあるなら、属性で絞り込んで該当リクエストを掘り出せます。
逆に導入を見送ってよいのは、トラフィックが大きくエラー率が安定している定常的なWebサービスです。有効化するとスパン取り込みがCloudWatch課金（東京で最初の10TBまで1GBあたり0.35 USD）に切り替わるため、毎秒数千リクエストを100%記録すると請求は跳ねます。全量が要るのは調査局面であって常時ではない、という判断が現実的です。まずは既定のサンプリングにアダプティブサンプリングを組み合わせ、異常時だけ記録率が上がる状態を作るほうが、費用対効果は素直に収まります。同じくCloudWatch Logsへ流れるアプリケーションログ側の取り込みコスト設計は、Fluent Bitとは？仕組み・Fluentd比較・AWSログ運用を実務解説【2026年v5対応】で扱っています。
料金（東京リージョン）
AWSの公式Price Listに基づく、ap-northeast-1の単価です。
| 項目 | 単価（USD） | 無料枠（月） |
|---|---|---|
| トレース記録 | 5.00 ／ 100万トレース | 10万トレース |
| トレース取得・スキャン | 0.50 ／ 100万トレース | 100万トレース（合算） |
| X-Ray Insights | 1.00 ／ 100万トレース | なし |
| スパン取り込み（Transaction Search） | 0.35 ／ GB（最初の10TB） | 100GB（初回3か月） |
| インデックス済みスパン | 0.75 ／ 100万スパン | 取り込み量の1% |
感覚をつかむために概算すると、毎秒100リクエストのAPIを既定サンプリング（毎秒1件＋超過分の5%）で運用した場合、記録されるトレースは1秒あたり約6件、月間で約1,540万件になり、記録料は月77 USD前後です。同じ構成を100%サンプリングに切り替えると記録対象は月約2.6億件、記録料は月1,300 USD規模まで跳ね上がります。サンプリング率は品質の設定ではなく、請求額の設定だと考えたほうが誤りません。常時100%ではなく、前述のアダプティブサンプリングで異常時だけ引き上げるほうが、この17倍の差を払わずに済みます。ヘッドベースとテールベースの選び分けやサンプリング率の決め方の全体像はトレースサンプリングとはで整理しています。
よくある質問
AWS X-RayとCloudWatchはどちらか一方でよいですか
置き換え関係ではないため、両方使うことになります。CloudWatchのメトリクスとアラームで異常を検知し、X-Rayのトレースで原因箇所を特定する、という分担です。現在はX-RayのトレースもCloudWatchコンソールから参照するため、実運用ではCloudWatchという1つの画面のなかでトレースまで見る形になります。
X-Ray SDKはいつまで使えますか
2026年2月25日にメンテナンスモード（セキュリティ修正のみ）へ入り、2027年2月25日にサポート終了です。それ以降は更新もリリースも行われません。X-Rayサービス自体は継続し、既存SDKとデーモンからのトレースも引き続き受け付けられますが、新機能は来ないため、新規の計装はOpenTelemetryを選び、既存分も2027年2月までに移行する計画を立ててください。
アノテーションとメタデータの違いは何ですか
アノテーションはインデックスされ、トレースのフィルタ式で検索できるキーと値です。メタデータは記録されるだけで検索対象になりません。OpenTelemetryで計装する場合はすべてスパン属性となり、既定ではメタデータ扱いになります。検索キーにしたい属性は aws.xray.annotations にキー名を列挙してアノテーション化してください。
X-Rayデーモンは動かさなくてよくなりましたか
既存環境で動いているものはそのまま使えますが、公式の移行先はCloudWatchエージェント（1.300025.0以降）またはOpenTelemetry Collectorです。CloudWatchエージェントに寄せると管理するエージェントが1つ減ります。切り替える際は、ポート2000が競合するため既存のデーモンを停止してから入れ替えます。
Lambdaのサンプリング率を上げられますか
Lambdaのアクティブトレーシングでは変更できません。公式ドキュメントが「関数のX-Rayサンプリングレートは設定できない」と明記しており、毎秒1リクエスト＋追加分の5%で固定です。より高い割合が必要なら、OpenTelemetryのレイヤーを使ってサンプラーを自前で設定する構成に変えます。
障害時だけトレースを増やすことはできますか
サンプリングルールに SamplingRateBoost（MaxRateとCooldownWindowMinutes）を設定すると、X-Rayが5xxやレイテンシ異常を検知したときだけ上限まで記録率を自動で引き上げます。ただしADOT SDK（Java v2.11.5以降／Python v0.15.0以降）が必要で、リクエストの入口となるルートサービスがADOTで計装されていないとブーストは発動しません。既定のサンプリングルールには適用できない点にも注意してください。
