Amazon Web Services ブログ

今月の AWS オブザーバビリティ – 2026年6月

はじめに

「This Month in AWS Observability」最新号へようこそ。今回は、この6月に Amazon CloudWatch と AI 駆動型オペレーション全般で発表された新機能をご紹介します。CloudWatch でネイティブな OpenTelemetry メトリクスと PromQL クエリが一般提供（GA）となり、より深い統計・構造化分析のための 23 個の新しい Logs Insights コマンドがローンチされ、CloudWatch RUM に Session Replay が登場し、 AWS DevOps Agent では MCP および Agent-to-Agent プロトコルをサポートするカスタム SRE エージェントがリリースされました。EKS クラスター全体で GPU コストを配賦する場合も、実際のセッション再生でフロントエンドの問題をデバッグする場合も、チームのランブックを自律型 SRE エージェントに組み込む場合も、役立つ情報が見つかるはずです。これらの新機能のデモをご覧になりたい方は、8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」にご登録ください。

OpenTelemetry と Prometheus

Amazon CloudWatch は、ネイティブ OpenTelemetry メトリクスと PromQL クエリの一般提供という大きなマイルストーンに到達しました。また、Amazon Managed Service for Prometheus には、高カーディナリティなワークロードのコストと複雑さを削減する機能が追加されました。

ネイティブ OpenTelemetry メトリクスと PromQL クエリ（GA） 

Amazon CloudWatch が OpenTelemetry メトリクスをネイティブにサポートし、一般提供が開始されました。チームは OpenTelemetry Protocol（OTLP）経由でメトリクスを直接送信し、Prometheus Query Language（PromQL）でクエリできます。料金は GB あたりの取り込み課金で、15 か月分のストレージが含まれます。これにより、CloudWatch と並行して別途 Prometheus 互換バックエンドを用意する必要がなくなります。数十のラベル（namespace、pod、container、node、deployment）を持つ高カーディナリティメトリクスが CloudWatch に直接流れ込み、チームがすでに慣れ親しんだ PromQL 構文で即座にクエリ可能になります。

CloudWatch Pipelines が OpenTelemetry メトリクスの処理とエンリッチメントをサポート 

CloudWatch Pipelines により、カスタムインフラストラクチャやアプリケーション計装の変更なしに、取り込み時に OpenTelemetry メトリクスの処理とエンリッチメントが可能になりました。例えば、ビジネスコンテキストの追加、高カーディナリティラベルの除去、命名規則の強制などが行えます。

Amazon Managed Service for Prometheus のネイティブヒストグラムサポート 

ネイティブヒストグラムは、バケット境界ごとに 1 つの時系列を出力する従来の Prometheus ヒストグラムを置き換えるものです。20 個以上のバケット境界を事前定義してメトリクスごとに 20 以上の時系列分のコストを支払う代わりに、ネイティブヒストグラムは分布全体を動的な解像度を持つ単一の時系列に格納します。これにより、レイテンシー、リクエスト時間、値の分布の追跡において正確なパーセンタイル計算を維持しながら、ストレージコストとカーディナリティを削減できます。

OTel と Managed Prometheus による GPU コスト配賦 

Amazon Elastic Kubernetes Service 上で AI/ML ワークロードをスケールさせるチーム向けに、OpenTelemetry コレクター、Amazon Managed Service for Prometheus、Amazon Managed Grafana を使用した GPU コスト配賦の新しいリファレンスアーキテクチャが公開されました。namespace、チーム、ワークロードタイプごとに GPU コストを配賦でき、「共有クラスターで最も高価なコンピューティングリソースを消費しているのは誰か」という問いに答えられます。

CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 

Claude Code のような AI コーディングエージェントがエンジニアリング組織全体に広がる中、トークン消費量、チームごとのコスト、開発者の生産性の追跡が重要になっています。このパターンでは、CloudWatch OTLP エンドポイントを使用して Claude Code セッションからカスタム OpenTelemetry メトリクスを取り込み、既存ツールでは答えられない問い（どのチームが最も多くのトークンを消費しているか、開発者あたりのコストはいくらか、AI 支援開発が最も価値を発揮しているのはどこか）に答えるダッシュボードを実現します。

ログ分析の進化

Amazon CloudWatch Logs の新しいクエリ・取り込み機能により、ログデータの大規模な分析・検索・ルーティングが容易になります。

23 個の新しい CloudWatch Logs Insights クエリコマンド 

CloudWatch Logs Insights に、複数カテゴリにわたる 23 個の新しいクエリコマンドが追加されました。
パースコマンド: 多様なログ形式からの構造化抽出のための parse_json、parse_kv、parse_csv、parse_xml
分析関数: より深い統計分析のための median、percentile_cont、mode、variance、stddev
ハッシュ・IP 関数: セキュリティおよびネットワーク調査ワークフローのための md5、sha256、ip_to_int、cidr_match
条件ロジック: より表現力豊かなクエリ構築のための case、coalesce、nullif、if
これらの追加により、複雑な調査のためにログを外部分析プラットフォームへエクスポートする必要性が減少します。

Log Analytics 統合コンソール 

新しい Log Analytics コンソールは、ロググループ横断のクエリ、自然言語によるログデータの探索、再利用可能なクエリパターンの保存を単一のインターフェースで提供します。従来は複数のコンソールページを行き来する必要があった作業が、単一のワークフローに統合されました。

タグベースのロググループクエリ

個々のロググループ名を指定する代わりに、タグでロググループをクエリできるようになりました。数百〜数千のロググループを持つ組織にとって、クエリのスコープ指定が簡素化されます。チーム、環境、サービス階層でロググループにタグ付けすることで、明示的なリストを維持することなく「決済チームの本番ログすべて」をクエリできます。

マネージド Syslog 取り込み 

CloudWatch Logs が、VPC エンドポイント経由で TCP、TLS、UDP を使用したマネージド syslog 取り込みをサポートしました。RFC 5424、RFC 3164、および Cisco FTD や ASA を含むベンダー固有の形式に対応します。syslog メッセージは自動的に構造化フィールドにパースされ、手動での変換なしに Logs Insights で即座にクエリ可能になります。

Elastic Beanstalk ログ統合 

AWS Elastic Beanstalk 環境が、ネイティブ統合によりアプリケーションログとプラットフォームログを CloudWatch Logs に直接ストリーミングできるようになりました。カスタムの .ebextensions 設定や、Beanstalk 管理インスタンス上のログストリーミングエージェントは不要です。

大規模なメトリクスとモニタリング

新しいクエリおよびメトリクス機能が拡張され、より大規模で複雑なマルチアカウントアーキテクチャを、より長い保持期間とより深いサービス固有の可視性でサポートします。

クロスアカウントメトリクスの一元化 

CloudWatch が、簡素化された設定によるクロスアカウントメトリクスの一元的な収集をサポートしました。組織はモニタリングアカウントを指定し、メンバーアカウントからメトリクスを自動的に集約できます。アカウントごとの手動セットアップなしに、フリート全体のダッシュボードとアラームが実現します。

Metrics Insights の保持期間延長

CloudWatch Metrics Insights クエリが延長された保持期間をサポートし、より長い過去のウィンドウにわたる分析クエリを実行できるようになりました。これにより、外部分析システムへのデータエクスポートを必要とせず、CloudWatch 内で直接トレンド分析、キャパシティプランニング、前年比較が可能になります。

Amazon ElastiCache: 13 個の新しい CloudWatch メトリクス 

Amazon ElastiCache が、メモリ断片化、接続チャーン、キー削除（Eviction）パターン、レプリケーションラグの詳細、コマンドレベルのレイテンシー分布をカバーする 13 個の新しい CloudWatch メトリクスを公開しました。これらのメトリクスは、従来は Redis や Memcached インスタンスに直接接続しないと観測できなかった、キャッシュ劣化の早期警告指標を見える化します。

エンドユーザーモニタリングと合成モニタリング

強化されたリアルユーザーの可視性と、より柔軟な合成テストトポロジーにより、モニタリングがエンドユーザーにさらに近づきます。

CloudWatch RUM Session Replay

CloudWatch Real User Monitoring（RUM）に Session Replay が追加され、実際のユーザーセッションを発生した通りに記録・再生できるようになりました。顧客から報告された問題を調査する際、エンジニアはユーザーが体験したインタラクション、ページロード、エラー、レイテンシーの正確なシーケンスを見ることができ、フロントエンドデバッグから当て推量を排除します。

Synthetics マルチロケーション Canary 

CloudWatch Synthetics に、単一の管理設定のもとで同じ合成テストを複数の AWS リージョンから同時に実行するマルチロケーション Canary が導入されました。各ロケーションは独立して動作します。あるロケーションが失敗を報告し、他が成功している場合、CloudWatch はシグナルを相関させて局所的な問題とグローバルな障害を区別し、誤検知によるアラームノイズを削減します。

AWS DevOps Agent によるインテリジェントオペレーション

AWS DevOps Agent は、クラウド環境向けの AI 搭載オペレーションアシスタントとして進化を続けており、自動調査のインテリジェンスとリーチの両方を向上させる新機能が追加されました。

カスタム SRE エージェント 

チーム固有の運用ランブックやインフラストラクチャパターンに合わせたカスタム SRE エージェントを構築できるようになりました。カスタムエージェントは、サービスアーキテクチャ、よくある障害モード、推奨される修復手順に関する組織の知見をエンコードし、繰り返し発生する問題の解決時間短縮を可能にします。

MCP および A2A プロトコルサポート 

AWS DevOps Agent が Model Context Protocol（MCP）と Agent-to-Agent（A2A）通信をサポートしました。これにより、DevOps Agent はマルチエージェントアーキテクチャの中で他の AI エージェントとオーケストレーションし、外部ツールの呼び出し、ナレッジベースへのクエリ、組織の境界を越えた修復ワークフローの調整が可能になります。

Webhook トリガーと曖昧性解消カード 

新しい Webhook ベースのトリガーにより、外部システム（PagerDuty、Datadog、カスタムアラートパイプライン）が DevOps Agent の調査を自動的に開始できるようになりました。調査中に曖昧さに遭遇した場合、曖昧性解消カード（disambiguation cards）が実行を停止させる代わりに構造化された選択肢をオペレーターに提示し、人間のガイダンスを得ながら調査ループを前進させ続けます。

5 つの新リージョンへの展開 

AWS DevOps Agent がさらに 5 つの AWS リージョンで利用可能になり、広範なグローバルカバレッジを実現しました。ヨーロッパ、アジアパシフィック、および追加の北米リージョンで運用するチームは、調査をローカルで実行できるようになり、データレジデンシーの懸念を軽減し、リアルタイム運用ワークフローのレイテンシーを改善します。

開発者体験の改善

AWS DevOps Agent には、日常の運用ワークフローの摩擦を減らす、的を絞った QOL（quality-of-life）改善が加えられました。

リリース管理機能（プレビュー）

DevOps Agent がリリース管理機能をプレビューとして提供開始しました。コード変更の本番投入準備状況をレビューし、標準からの逸脱、依存関係への影響、Well-Architected への準拠をチェックするとともに、テスト計画を自律的に生成・実行してデプロイ前にリグレッションを検出します。これにより、チームは AWS、マルチクラウド、オンプレミス環境全体で、より速いリリースと MTTR の削減を実現できます。

静的 IP サポート

エージェントスペースにアウトバウンドトラフィック用の静的 IP アドレスを設定できるようになりました。IP ベースの許可リストを必要とする外部システム（オンプレミスの ITSM プラットフォーム、パートナー API、レガシーファイアウォール）との統合が可能になります。

自動拡張チャットと完全なコンテキスト保持 

DevOps Agent の調査インターフェースに、自動的に広がるチャット入力欄と、調査セッションをまたいだ完全なコンテキスト保持が追加されました。より長く詳細なプロンプトが切り捨てられることなくサポートされ、以前の調査に戻ると会話履歴と調査結果が完全な状態で保持されています。

AWS Cloud Operations Blog の関連記事（2026年6月）

2026年5月〜6月に AWS Cloud Operations Blog で公開された記事は以下の通りです。

2026年6月

まとめ

過去 2 か月間のオブザーバビリティ関連のローンチは、明確な方向性を示しています。AI 支援オペレーションはプロダクショングレードへの移行を続け、ログ分析は CloudWatch コンソールを離れることなくより強力になり、メトリクスはマルチアカウントのエンタープライズアーキテクチャに対応する規模へスケールし、モニタリングは合成テストとリアルユーザー体験の両レイヤーへさらに深く到達しています。

これらの機能を使い始めるには

最近のローンチの完全なリストは、Amazon CloudWatch でフィルタリングした AWS What’s New ページ をご覧ください。

さらに詳しく知りたい方へ

8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」に参加して、これらの新機能の実際の動作を確認し、トラブルシューティングの高速化に活用してください。

著者

Dot Ho

Dot Ho

Dot は AWS Observability 担当の Senior Technical Product Marketing Manager です。WCA 3×3 マルチブラインド（目隠し複数ルービックキューブ）ソルブの記録向上に向けて練習中です。

Joe Alioto

Joe Alioto

Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。

本ブログは 2026 年 7 月 15 日に公開された This Month in AWS Observability: June 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。