Michael JohnsonAWSは2026年9月22日にCloudWatch Omniを発表し、9月23日に一般提供を開始したと案内しました。この日付は、それぞれ発表日と一般提供開始日という異なる出来事を示しています。OmniはアプリケーションとAIエージェントの可観測性を一つの環境にまとめ、単独のウェブインターフェースやIDE拡張機能に加え、CloudWatchとの統合も提供します。詳しくはAWSのCloudWatch Omni発表をご覧ください。
この統合は、本番環境における見落としに対処するものです。エージェントのリクエストは、従来型のサービスエラーを起こさずに完了しても、回答の質が低かったり、誤ったツールを選んだりすることがあります。AWSは、エージェントのトレースや評価結果をアプリケーションのテレメトリと並べて調べられる点をアピールしています。実務上の課題は、これらのシグナルを共通のワークスペースに集約することで本当に役立つのか、また、そこへ送るデータ、アクセス権限、コストをどう扱うかです。
製品の対象はエージェントのトレースだけではない
OmniはCloudWatchの拡張機能であり、CloudWatchに取って代わるものではありません。AWSによると、既存のCloudWatchアラーム、ダッシュボード、API、コンソールでの作業手順は引き続き利用できます。すでにCloudWatchに送信されているテレメトリは、再設定なしでOmniに表示できます。計測済みのその他のワークロードは、OpenTelemetry Protocol（OTLP）を使ってデータを送信できます。AWSは、サービスの検出や依存関係のマッピングに加え、設定に応じて複数のアカウントやリージョンのテレメトリをまとめられるスペースについても説明しています。詳しくはCloudWatch Omniのドキュメントをご覧ください。
利用環境はAWSマネジメントコンソールに限られません。AWSは、シングルサインオン対応の単独ウェブインターフェースと、VS Code、Cursor、Kiro向けのIDE拡張機能を提供しています。9月23日のリリースノートによると、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）で一般提供されています。Omniを本番環境の設計に組み込む前に、チームは利用予定のリージョンが対応しているか確認する必要があります。
エージェントについてAWSは、OpenAI Agents SDK、LangGraph、CrewAI、Vercel AI SDK、Strandsなどのフレームワークを対象に、トレースの調査、評価、実験を行えると説明しています。アプリケーションの調査では、自然言語で質問したり、テレメトリを直接調べたりできます。AWSによると、AI支援による調査機能はDevOps Agentを利用します。また、アプリケーション向けの発表記事では、Omniの各調査セッションでDevOps Agentがデフォルトで有効になるとも説明されています。管理者はワークフローを評価する際、この動作を把握しておく必要があります。
シグナルをまとめることに意味がある理由
従来の監視では、サービスが応答しているか、処理にどのくらい時間がかかるか、エラーを返しているかを確認できます。しかし、エージェントがリクエストを誤解したり、不適切なツールを選んだり、誤った回答をしたりしたことまでは分からない場合があります。評価結果をトレースやアプリケーションのシグナルと並べて確認できれば、エージェントの実行過程をたどり、品質上の問題の原因を探りやすくなる可能性があります。
これは期待できる運用上の利点であり、実証済みの性能向上を示すものではありません。AWSの発表資料は統合されたワークフローを説明していますが、既存のツールよりもインシデントを迅速に解決できるとは示していません。Omniの評価機能や調査機能が自社のワークロードで役立つかどうかは、各チームが検証する必要があります。
OpenTelemetryを使えば、既存の計測からテレメトリを送りやすくなる可能性がありますが、共通プロトコルを採用しても、可観測性プラットフォーム同士が置き換え可能になるわけではありません。OTLP仕様が定めるのはテレメトリの伝送方法です。チームはそれでも、自分たちのワークフローがどのシグナル、クエリ、プラットフォーム固有の機能に依存しているかを確認する必要があります。
データの一元化には設定が必要
Omniでは複数のアカウントやリージョンにまたがるデータをまとめられますが、インターフェースを有効にするだけで、すべてのアカウントのテレメトリが自動的に集約されると考えるべきではありません。AWSのセットアップドキュメントでは、ドメインとスペースを作成し、複数のアカウントのテレメトリをスペースに取り込む方法を設定する手順が説明されています。既存のCloudWatchデータは再計測せずに表示できますが、組織は意図したアクセス権限とデータフローを設定する必要があります。詳しくはOmniのセットアップ手順をご覧ください。
この違いは、導入とコストの両面で重要です。AWSの料金ページでは、テレメトリの取り込み、保存、分析にかかる料金が分けて記載されています。また、追加の一元化コピーには料金がかかりますが、掲載されている料金体系では最初の一元化コピーは無料です。クエリ料金はスキャンしたデータ量と無料枠に応じて変わり、エージェントの評価にはAmazon Bedrock AgentCore Evaluationsの料金が適用されます。そのため、適切な見積もりにはエージェント数だけでなく、データ量、保持期間、クエリのパターン、コピー数、評価の頻度も考慮する必要があります。
トレースの内容とアクセス権限を確認する
エージェントのトレースには、プロンプト、応答、取得したドキュメント、個人情報が含まれることがあります。AWSによると、Omniは個人を特定できる情報を自動的に検出したり、マスキングしたりしません。AWSの機微データに関するガイダンスでは、フィルタリングをどこで行うかを選ぶことが推奨されています。取得時にマスキングすれば、機微な内容がアプリケーションの外に出るのを防げます。
AWSはまた、顧客コンテンツを基盤モデルのトレーニングやOmni自体の改善に使用しないと説明しています。ただし、これは他の場所でコンテンツが処理されないという意味ではありません。一部の機能はデータをBedrockやAgentCoreなどのサービスに送信し、AWSはAI機能のクロスリージョン推論についても説明しています。データはスペースのリージョンに保存されますが、AIリクエストは同じ地理的エリア内の別の場所で処理される場合があります。特にトレース内容の処理場所に制限を設けるポリシーがある場合、チームはAWSのデータ利用ポリシーとクロスリージョン推論の詳細を確認する必要があります。
アクセス制御も、テレメトリのパイプラインと同じように慎重に確認する必要があります。AWSによると、スペースのメンバーはデフォルトで、そのスペースにあるすべてのテレメトリを読み取れます。データスコープを使えば、メンバーが閲覧できるログやトレースの行を絞り込めます。しかし、データスコープでは行内のフィールドは隠せないため、ユーザーに決して見せるべきではない内容のマスキングに代わるものではありません。詳しくはメンバーの閲覧範囲を制限する方法をご覧ください。
Omniを段階的に評価する
すでにCloudWatchを利用しているチームは、範囲を限定したテストを行うことで、アプリケーションとエージェントを共通の画面で確認できることが実際のワークフローに役立つかどうかを判断できます。本番環境のトレースを送る前に、必要なシグナルを特定し、フィルタリングを設定して、アカウントとリージョンのアクセスを整え、取り込み、保存、分析、評価にかかるコストを見積もりましょう。そのうえで、生成された調査結果や評価結果を現在のインシデント対応手順と比較します。
別の可観測性プラットフォームを利用している組織にとって、今回の発表はワークフローを評価するきっかけにはなりますが、それだけで移行する理由にはなりません。Omniはエージェントの品質シグナルをアプリケーション運用に近づけますが、その価値は、調査機能の有用性、制御機能との適合性、データフローの費用対効果によって決まります。
