2026.10.10 AWS

CloudWatch Omniとは：料金・東京未対応の制約とAIエージェント計装の手順

Q: CloudWatch Omniの東京リージョン対応はいつですか？

2026年10月10日時点で、AWSは東京リージョンへの提供時期を公表していません。提供状況は CloudWatchのよくある質問 とWhat's Newで更新されます。東京対応が発表されたら、スペースを東京に作り直せばリージョン間の転送料金と国外保管の問題はなくなります。

CloudWatch Omniとは：料金・東京未対応の制約とAIエージェント計装の手順

CloudWatch Omniは、2026年9月22日（米国時間）にAWSが一般提供を始めた、アプリケーションとAIエージェントを1つの画面で監視するCloudWatchの新しい作業環境です。この記事では、ドメイン・スペース・Datasetという3つの構成要素、既存のCloudWatchとの関係、Omni固有の課金が実質クエリだけという料金の読み方を公式ドキュメントで確かめます。そのうえで、シングルアカウントでの初期設定と、PythonのAIエージェントをAWS Distro for OpenTelemetry（ADOT）で計装してトレースを送る手順を、コマンドと環境変数つきで確認できる構成です。2026年10月時点で東京リージョン未提供という制約の扱いも整理します。

まとめ：CloudWatch Omniは既存データを読む監視画面で、東京未提供が導入判断の分かれ目

Omniは新しい保存先ではありません。既存のCloudWatchに入っているログ・メトリクス・トレースを読み、サービスの依存関係の自動検出、自然言語からのSQL／PromQL生成、AIエージェントの品質評価、AWS DevOps Agentによる原因調査を1か所にまとめた画面です。有効化しても既存のアラームやダッシュボードは変わらず、取り込みと保存は標準のCloudWatch料金のままです。Omniで増える課金は、取り込み量の5倍を超えてログやトレースをスキャンしたときのクエリ料金が中心になります。

制約ははっきりしています。GAはバージニア北部・オレゴン・アイルランドの3リージョンだけで、スペースは1アカウント・1リージョンに紐づきます。東京リージョンのワークロードをそのまま見る構成は2026年10月時点では組めません。米国・欧州でAIエージェントを動かしているチームはすぐ試す価値があり、国内にデータを置く必要がある業務システムは東京対応を待つ、というのが現時点の結論です。

CloudWatch Omniの構成要素と既存の監視資産との関係

最初に、ドメイン・スペース・Datasetという構成要素ごとに、Omniが何を新しく作り、何を既存のCloudWatchに任せるのかを分けて押さえます。CloudWatch Omniのユーザーガイドは、Omniを「CloudWatchの上に構築されたインターフェースとワークフロー」と定義し、置き換えではないと明記しています。

サインインURLになるドメインと、1アカウント1リージョン単位のスペース

ドメインは組織の入口です。設定時に決めた名前がhttps://<domain-name>.cloudwatch-omni.global.app.aws形式のサインインURLになり、IDプロバイダーの接続もドメイン単位で行います。利用者はAWSマネジメントコンソールにログインせず、このURLからSSOで入ります。

スペースは実際に作業する場所で、ホストしたアカウントとリージョンのテレメトリだけが見えます。境界はクエリ時のフィルタではなく、アカウントとリージョンそのものです。1つのドメインに複数のスペースを置けますが、スペースをまたぐ横断クエリはできません。複数アカウントの情報を1つのスペースで見たい場合は、CloudWatchの集約（centralization）ルールで先にデータを寄せておく必要があります。

CloudWatch Datasetへの転送と、有効化しても変わらない既存資産

スペースを作るとCloudWatch Datasetが1つでき、ロググループのログとトレースがDatasetへ転送されて、シグナルをまたいだ相関クエリができるようになります。メトリクスは転送されず、OmniがCloudWatch Metricsへ直接問い合わせます。転送は同一アカウント・同一リージョン内に限られ、Deliveryクラスのロググループは対象外です。

既存のコンソール画面、アラーム、ダッシュボード、Logs Insightsクエリ、APIは変わらず動きます。CloudWatchエージェントやOTLPパイプライン、AWS SDKによる計装もそのままで、データ収集の設定やロググループの保持期間の管理先は、引き続きCloudWatchコンソールです。初回の有効化時には、過去7日分のログとトレースがスペースへバックフィルされます。カスタマー管理のKMSキーで暗号化したデータは、このバックフィルに含まれません。

アプリ監視・AIエージェント評価・DevOps Agent調査の分担

アプリ側では、テレメトリからサービスと依存関係を自動検出し、リクエスト率・エラー・所要時間のRED指標を出します。自然言語の質問への回答は、OmniエージェントがSQLかPromQLに変換して返す仕組みです。アラートはSlackかAmazon SNS経由で届き、発火したアラートからAWS DevOps Agentの調査を始められます。DevOps Agent単体の構築手順はAWS DevOps Agentの使い方：CLIでの構築とCloudWatchアラームから調査を自動起動する手順で扱っています。

エージェント側の柱は品質評価です。生成AI向けのAWS News Blogによると、組み込み評価器は17種類あり、回答の一貫性や忠実性、ツール選択の正しさを採点します。評価の実行基盤はAmazon Bedrock AgentCore Evaluationsで、DeepEvalなどの外部評価器も同じカタログから選べます。エラー率に出ない「形式は正しいが中身が誤った応答」を拾える点が、従来のAPMとの違いです。

CloudWatch Omniの料金と提供リージョン：Omni固有の課金と東京未提供の扱い

料金とリージョンは導入可否をほぼ決めます。数字は2026年10月時点の公式ページから取っています。

取り込みと保存は標準料金のまま、増えるのはクエリのスキャン料金

CloudWatch Omniの料金ページは「取り込みと保存は標準のCloudWatch料金のまま」と書き、Omniが足す課金は無料枠を超えたスキャンだけだとしています。バージニア北部の単価は次のとおりです。表のOTelはOpenTelemetryの略称で、取り込みの行はアプリ・カスタムログとOpenTelemetryメトリクスを対象にしています。

区分	項目	単価（USD）
取り込み	アプリ・カスタムログ／OTelメトリクス	0.50／GB
取り込み	スパン（最初の10TB）	0.35／GB
保存	Standard（30日以内にアクセス）	0.030／GB-月
分析	ログ・トレースのクエリ	0.005／スキャンGB
分析	PromQLクエリ（Omni画面からは無料）	0.01／100万サンプル
分析	ダッシュボード・アラート	無料（クォータ内）

エージェント評価はAgentCore Evaluationsの料金が別にかかります。料金ページの試算例では、スパン1TB・ログ0.6TB・評価4,000件の本番エージェントで月657ドル＋評価料金です。この657ドルはほぼ取り込み料金なので、既にCloudWatchへ同量を送っている環境なら、Omniを足しても請求はほとんど増えません。

1,000ドル分30日のクレジットと、取り込み量の5倍まで無料のスキャン枠

新規の有効化には1,000ドル分のクレジットが付き、最大30日間、OpenTelemetryのログとメトリクス、Application Signalsのスパンに充てられます。1つのAWS Organizationにつき最大10アカウントまでで、全アカウントが対象ではないため、コンソールで適格性を確かめてください。

クレジットとは別に、毎月のログとスパンの取り込み量の5倍までは、スキャンが無料になります。月2TBを取り込む環境なら10TBまでのスキャンは課金されません。注意点はダッシュボードの自動更新で、更新のたびにスキャンが走ります。料金ページは更新間隔を5分以上にするよう勧めています。

GAはバージニア北部・オレゴン・アイルランドの3リージョンで東京は対象外

2026年9月23日掲載のWhat’s Newは、提供リージョンをUS East（N. Virginia）、US West（Oregon）、Europe（Ireland）の3つと明記しています。スペースは1アカウント・1リージョンに紐づくため、東京リージョン（ap-northeast-1）のロググループやトレースは、そのままでは見られません。

回避策として、集約ルールで東京のテレメトリを対応リージョンへコピーする方法はあります。料金ページでは集約の最初のコピーは無料（追加コピーは0.05ドル／GB）ですが、リージョン間のデータ転送料金は別にかかり、データが国外リージョンに置かれます。顧客データの国内保管を契約で約束している業務システムでは採れない手です。

CloudWatch Omniの初期設定：シングルアカウントでドメインとスペースを作る手順

ここからは、ドメインとスペースを実際に作成するための設定手順です。複数アカウントで使う組織向けの手順は管理アカウントでの作業が要るため、まずは検証用の単一アカウントで試す流れを示します。手順はシングルアカウント設定のページに沿っています。

ドメイン名の命名規則とIAM Identity Centerを同じリージョンに置く条件

ドメイン名は3〜63文字の英小文字・数字・ハイフンで、先頭と末尾は英数字、ハイフンの連続は不可です。aws-、amazon-、cloudwatch-、omni-で始まる名前は予約されています。全CloudWatchドメインで一意なので、社名そのままの名前は取られている可能性があります。

SSOでサインインさせる場合、IAM Identity Centerのインスタンスはドメインと同じリージョンに置く必要があります。東京でIdentity Centerを運用している組織は、マルチリージョンレプリケーションでOmniのリージョンを含める作業が先に発生します。Identity Centerの設計はAWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説を参照してください。IDプロバイダーを繋がない場合は、IAMユーザーかIAMロールでサインインできます。

スペース作成時のTransaction Search有効化と3つのIAMロール

Transaction Searchの有効化と3つのIAMロールの自動作成を伴うコンソールでの作業は、大きく分けて次の4段階です。

CloudWatchコンソールのOmni設定画面を開き、Get startedを選ぶ
Account domainを選び、ドメイン名を入力する
権限のステップを完了し、必要なIAMロールを作成させる
続けて表示されるスペース設定で、スペース名とアカウント・リージョンを確認して完了する

スペース作成と同時に、CloudWatch Dataset連携、OTelメトリクスのエンリッチメント、Transaction Searchによるスパン取り込みが有効になります。後者2つの課金には、新たな料金体系ではなく既存の料金体系が適用される仕組みです。IAMロールはCloudWatchOmniOperatorRole、CloudWatchOmniDatasetIntegrationExecutionRole、オンライン評価用のAgentCoreEvaluationRoleの3つで、最後の1つは不要なら外せます。

AWS CLIでDataset連携を張るときの信頼ポリシーとコマンド

IaCで管理したい場合は、Dataset連携をテレメトリ送信のページの手順でCLIから作れます。まずCloudWatch Logsが引き受ける実行ロールを、次の信頼ポリシーで作ります。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "logs.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "<account-id>" },
      "ArnLike": { "aws:SourceArn": "arn:aws:observabilityadmin:<region>:<account-id>:dataset-integration/default" }
    }
  }]
}

ロールにlogs:IntegrateWithDatasetとcloudwatch:PutRecordsを許可したら、連携を作成します。

aws observabilityadmin create-dataset-integration \
    --role-arn arn:aws:iam::<account-id>:role/CloudWatchOmniDatasetIntegrationRole \
    --region us-east-1

落とし穴はaws:SourceAccountです。別のアカウントIDを書いても作成コマンドは成功しますが、ログは1件も転送されません。転送対象を絞りたい場合は、権限ポリシーのリソースをlog-group:*から個別のロググループ名に変えます。

CloudWatch Omniへのトレース送信：Pythonエージェントの計装手順

アプリ側のテレメトリは既存のCloudWatchエージェントやApplication Signalsの設定がそのまま使えます。新たに作業が要るのはAIエージェントです。ここではAIエージェントのテレメトリ送信ページの手動手順で、EC2やECSで動くPythonエージェントをADOTで計装します。

ADOT単体での計装とOpenInferenceを追加する場合の判断基準

推奨はADOTのディストリビューションであるaws-opentelemetry-distro単体での導入です。コード変更なしでモデル呼び出しとツール呼び出しを計装し、gen_ai.*属性のスパンとして記録します。属性の体系はOpenTelemetryのGenAIセマンティック規約｜gen_ai属性とメトリクスの体系・移行の判断で解説しています。

pip install "aws-opentelemetry-distro>=0.20.0"

# LangGraph や LangChain で AGENT／LLM／TOOL のスパン種別が欲しい場合だけ追加
pip install "aws-opentelemetry-distro>=0.20.0" openinference-instrumentation-langchain

OpenInferenceは任意です。フレームワーク由来のスパン種別と構造化された入出力が欲しい場合に足します。どちらを選んでも、トレーサープロバイダーを自前でもう1つ作ってはいけません。OpenTelemetryは最初に登録されたプロバイダーしか使わないため、後から作った側は何も送りません。版の更新はaws-otel-python-instrumentationのリリース一覧で確認できます。

環境変数を指定する起動コマンドとプロンプト・応答本文の記録設定

起動時には、本文の記録を制御するAWS_GENAI_CONTENT_EXTRACTION_OPT_OUTなどの環境変数を渡し、opentelemetry-instrument経由でエージェントを動かします。実行ロールにはAWS管理ポリシーAWSXrayWriteOnlyAccessを付けておきます。

AGENT_OBSERVABILITY_ENABLED=true \
AWS_GENAI_CONTENT_EXTRACTION_OPT_OUT=true \
OTEL_PYTHON_DISTRO=aws_distro \
OTEL_PYTHON_CONFIGURATOR=aws_configurator \
OTEL_RESOURCE_ATTRIBUTES="service.name=support-agent,deployment.environment.name=staging" \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_TRACES_EXPORTER=otlp \
OTEL_LOGS_EXPORTER=none \
OTEL_METRICS_EXPORTER=none \
opentelemetry-instrument python agent.py

名前に反して、AWS_GENAI_CONTENT_EXTRACTION_OPT_OUT=trueはプロンプトと応答の本文をスパンに残す設定です。未設定かfalseだと本文はスパンから外れてログイベント側に出され、評価器が読む入出力が空になります。個人情報を含むプロンプトを扱う場合は、残す前にマスキングの方針を決めてください。サンプリングは既定の全件のままが推奨で、間引くとトークン使用量などスパンから計算する指標が不正確になります。

トレース未着時の確認順：Transaction Search・権限・1%索引

公式ページのトラブルシューティング表から、つまずきやすい順に並べ直すと次のようになります。HTTP 200が返っていても、トレースが届いた証拠にはなりません。

Transaction Searchがそのリージョンで有効か。有効化前に送ったスパンは検索できず、宛先の変更は反映に約10分かかる
実行ロールにAWSXrayWriteOnlyAccessが付いているか。EKSではPod IdentityかIRSAが無いとノードロールに落ちる
エクスポーターが404を返す場合、エンドポイントに/v1/tracesを二重に付けていないか
一覧に出ない呼び出しがある場合、Transaction Searchは既定で1%のスパンしか一覧用に索引しない点を疑う

4つ目は不具合と取り違えがちです。スパン自体は全件保存されているので、ロググループaws/spansを直接見れば到着を確かめられます。X-Rayとの関係を含むトレースの保存先の整理はAWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方が詳しいです。

CloudWatch Omniを採用すべきチームと見送るべき業務システムの判断基準

ここまでの事実を踏まえ、2026年10月時点での判断を条件つきで言い切ります。

採用：米国か欧州リージョンでAIエージェントを本番運用しているチーム

バージニア北部・オレゴン・アイルランドのいずれかでBedrock AgentCoreやLangGraphのエージェントを動かしているなら、今すぐ有効化して構いません。既存のCloudWatchを変えず、取り込み済みのデータに対する画面が増えるだけなので、撤退コストも小さく済みます。評価器による品質スコアは、他の監視製品へ移らずに手に入る機能としては最も大きな差です。AgentCoreへのデプロイ手順はAmazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイにまとめています。

計装・アラート設計・評価基準の決め方まで含めて運用体制を組み直したい場合は、一創の保守運用・内製化支援で、監視設計から社内チームへの引き継ぎまでを相談いただけます。

見送り：東京リージョンにデータを置く必要がある国内向け業務システム

東京リージョンだけで動く業務システムには、現時点で導入しません。スペースが東京に作れない以上、見るには国外へテレメトリをコピーするしかなく、ログに含まれる顧客情報の保管場所が変わります。アプリ監視が目的なら、東京で使えるAmazon CloudWatch Application SignalsでSLOとサービスマップを先に整え、東京提供の発表を待つのが堅実です。

Application Signalsや他社APMと並べるときの役割分担

Omniは既存データを読むだけなので、Application SignalsやDatadogなどのAPMと競合せずに並べられます。現実的な分担は、アプリのSLOとアラームは既存の仕組みに残し、AIエージェントの品質評価と横断の調査だけをOmniに寄せる形です。ADOTとCloudWatchエージェントで計装を揃えておけば、どちらへ送る場合も同じデータが使えます。計装の全体構成はAWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成で解説しています。

CloudWatch Omniの導入前によくある質問と既存環境への影響

導入を検討する段階で出やすい質問に、公式情報の範囲で答えます。

CloudWatch Omniを有効化すると既存のアラームやダッシュボードは移行されますか？

移行も変更もされません。既存のアラーム、ダッシュボード、Logs Insightsクエリはそのまま動き、別に課金も続きます。Omniのアラートとダッシュボードは新しく作る別物で、既存のアラームを自動で取り込む機能は2026年10月時点の公式ドキュメントに見当たらないため、必要なものだけOmni側で作り直します。

AWSアカウントが無くてもCloudWatch Omniを試せますか？

試せます。サインインページのTry playgroundから、サンプルデータ入りの共有環境をアカウントなしで操作できます。VS Code、Kiro、Cursor向けのIDE拡張も無料で、ローカルのエージェントの計装とトレース確認ならAWSアカウントは要りません。Bedrockのモデルを呼ぶ場合はAWS認証情報、他社モデルならそのAPIキーが必要です。

CloudWatch OmniとApplication Signalsは何が違いますか？

Application Signalsはアプリの計装とSLO管理の機能で、Omniはそのデータも含めて読む作業画面です。Application Signalsのスパンは無料クレジットの対象にも入っており、Omniの画面にそのまま表示されます。

Omniの料金はCloudWatchの請求にどう上乗せされますか？

取り込みと保存は既存のCloudWatch料金のままなので、上乗せはクエリのスキャン料金が中心です。毎月の取り込み量の5倍までは無料で、超えた分が0.005ドル／GBかかります。AIエージェントのオンライン評価を使う場合はAgentCore Evaluationsの料金、東京から集約する場合はリージョン間の転送料金が別に加わります。