今月の AWS オブザーバビリティ: 2026 年 7 月

はじめに

7 月は AWS オブザーバビリティにとってアップデートの多い月となりました。すでに収集しているテレメトリをより実用的なものにし、その収集にかかる運用作業を AWS 側で引き受ける機能をリリースしました。ログ分析は、ログクエリから直接実行できるアラームと、取り込み時に行われるエンリッチメントによって、アクションに繋げやすくなりました。アプリケーションレベルのオブザーバビリティは、エラーとデプロイイベントを自動的に捕捉するようになりました。AI コーディングエージェントの可視化が、新しいオブザーバビリティのカテゴリとして登場しました。Prometheus メトリクスのスクレイピングのために自前で運用していたエージェントは、マネージドコレクションによって不要になりました。そしてこれらすべてを支える基盤として、OpenTelemetry と Prometheus が引き続き中核的な役割を果たしています。

Amazon CloudWatch、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS DevOps Agent の最新情報をご紹介します。

これらのリリースのライブデモをご覧になりたい方は、9 月 16 日開催の「I didn’t know Amazon CloudWatch could do that!」ウェビナーにご登録ください。過去のまとめを見逃した方は、「今月の AWS オブザーバビリティ」の 2026 年 1 月〜5 月 および 2026 年 6 月 のブログをご覧ください。

ログ分析: クエリからアクションへ

7月のテーマとして最も分かりやすいのは、ログクエリと、そこから起こすアクションに繋げやすくすることでした。

CloudWatch Logs のクエリから直接アラームを作成できるようになりました。クエリを記述してしきい値を設定すれば、エラーが急増したときに周辺のログコンテキストとともにアラートを受け取れます。これら一連の操作が 1 つのワークフローで完結します。メトリクスフィルターやカスタムメトリクスを事前に作成する中間ステップは不要になりました。ログアラームは、Amazon Simple Notification Service や Amazon EventBridge を含む、すでに利用している標準的なアラームアクションをサポートしているため、他の CloudWatch アラームと同じ通知・自動化の経路にルーティングできます。

新しいログエンリッチメント用の lookup プロセッサは、アップロード済みの CSV のルックアップテーブルとログイベントのフィールドを照合することで取り込み時にコンテキストを追加します。カスタムのエンリッチメントロジックを書かなくても、IP アドレスから担当チームへ、エラーコードから人が分かりいやすい説明文へ、ユーザー ID からアカウントのメタデータへ、といったマッピングができます。エンリッチメントはデータの到着時に行われるため、クエリ、ダッシュボード、アラームのすべてが追加されたフィールドの恩恵を直ちに受けられます。

CloudWatch Logs が、Application Load Balancer のログを Vended Logs (AWS のサービスが発行するログ) としてサポートするようになりました。Application Load Balancer のアクセスログ、接続ログ、ヘルスチェックログが CloudWatch Logs に直接ストリーミングされ、Logs Insights でのクエリ、メトリクスフィルターの作成、Live Tail によるリアルタイム監視が可能になります。テレメトリ有効化ルールにより、組織内の既存および新規のロードバランサーに対してロギングが自動構成されるため、1 つずつ手作業で設定する必要はありません。

CloudWatch Logs Insights には、7 月に25 個の新しいクエリコマンドと関数が追加されました。統計関数、セッション化 (sessionization)、外れ値検出、NULL 処理などが含まれます。これらにより、結果を別の場所で後処理するのではなく、クエリ言語の中でより多くの分析を直接実行できます。

コスト効率の良いログストレージ

ログを 1 か所に集めるほど、ストレージコストが課題になります。7 月はこの点にも対応しました。CloudWatch Logs Intelligent Tiering は、直近のアクセス状況に基づいて、ログデータを Standard、Infrequent Access、Archive Instant Access の 3 つの階層に分類します。30 日間アクセスされていないデータは Infrequent Access に移動し、90 日間アクセスされていないデータは Archive Instant Access に移動します。古いデータをクエリすると、自動的に Standard に戻ります。クエリの操作感は 3 つの階層すべてで同じであるため、チームの運用を変えることなくストレージコストを削減できます。有効化はアカウントレベルで行います。

アプリケーションのオブザーバビリティ

Application Signals が、計装済みのサービスからエラー、パフォーマンス異常、デプロイイベントを自動的に捕捉するようになりました。追加のコード変更は不要です。例外とレイテンシーのイベントスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを記録します。そのため、何か変化が起きたときには Errors ビューを直接開き、最近のデプロイが新しい例外を引き起こしたかどうかを確認できます。この機能は、AWS Distro for OpenTelemetry SDK、または Amazon Elastic Kubernetes Service (Amazon EKS) 用の CloudWatch Observability アドオンで計装された Java、Python、JavaScript のサービスでサポートされます。イベントはログとして、関数メトリクスは OpenTelemetry メトリクスとして配信されるため、既存のオブザーバビリティデータとまとめて扱えます。

AI コーディングエージェントのオブザーバビリティ

Coding Agent Insights は、AI コーディングツールが組織全体でどのように価値を生み出しているかを、エンジニアリングリーダーが把握できるようにします。Claude Code、Codex、GitHub Copilot と統合され、追加の計装なしで OpenTelemetry メトリクスを収集します。データは既存の CloudWatch の運用ビュー上に表示されます。支出のトレンドを追跡し、トークン課金のアラートを設定し、エージェントの導入状況をコミットのスループットやプルリクエストの速度と突き合わせ、どのモデルが最も優れたコスト対アウトプット比を実現しているかを特定できます。コーディングエージェントを大規模に導入していくチームにとって、リターンを推測ではなく計測する手段となります。

OpenTelemetry とマネージドコレクション

Managed Prometheus collectors は、エージェントのデプロイや保守なしに、Prometheus メトリクスをフルマネージドで収集します。スクレイプ設定を用意すれば、プロビジョニング、スケーリング、収集は CloudWatch が処理します。エージェントを一切デプロイ・管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service のワークロードの監視を有効化できます。メトリクスは OpenTelemetry 形式で配信され、AWS Vended メトリクス (AWS のサービスが発行するメトリクス) とともに PromQL でクエリできます。

AWS Cloud Operations Blog の関連記事 (2026 年 7 月)

2026 年 7 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。

Getting per-resource alarm notifications with Amazon CloudWatch  – Himanshu Dewan, Ashish Kumar, Radheshyam Baliga Bantwal

Autonomous Root Cause Analysis for AWS Systems Manager Patch Failures Using AWS DevOps Agent  – Rizwan Mohammed, Samir Behara, Shanmukha Jaya Harsha Alluri, Vinod Kisanagaram

Build bespoke operational workflows with AWS DevOps Agent custom SRE agents  – Harish Mandhadi, Brent Everman, Joe Alioto, Janardhan Molumuri

Automate CI/CD troubleshooting with AWS DevOps Agent and GitHub  – Purushotham G K, Abhishek Taparia

Extend Amazon CloudWatch Beyond Native Connectors with Cribl Stream  – Gabriel Costa, Kishore Vinjam

How Amazon Achieved Full Stack Observability Across 400 Offices with Amazon OpenSearch Serverless  – Shivansh Singh, Arijit Chakravorty, Bishr Tabbaa, Leonardo Quintero

Deploy OpenTelemetry Gateway on AWS: Monitoring Your Observability Pipeline  – Ankita Saxena, Jyothi Madanlal

Amazon CloudWatch アラームをアクション可能なシグナルに変える  – Helen Ashton, Gagandeep Singh

Using Amazon S3 Server Access Logs with Amazon CloudWatch Logs  – Isaiah Salinas, Erik Weber

まとめ

7 月のリリースによって、ログ分析はクエリとアクションのギャップを埋め、ストレージの階層化はデータ保持コストを抑えやすくしました。さらに、アプリケーションのオブザーバビリティは追加のコードなしで重要なイベントを捕捉し、AI コーディングエージェントは計測可能になり、マネージドコレクションはエージェント運用の負担を取り除きました。これらはすべて OpenTelemetry と Prometheus の基盤の上に構築されています。

これらの機能を使い始めるには、以下を実施してください。

• CloudWatch コンソールで、ログクエリから直接アラームを作成する。
• CloudWatch Pipelines で取り込み時にログをエンリッチするルックアップテーブルをアップロードする。
• エラーとデプロイの自動捕捉のために、Application Signals のサービスイベントを有効にする。
• Coding Agent Insights にデータを取り込むために、Claude apps gateway のテレメトリを設定する。
• 自己管理型のコレクターをマネージド Prometheus コレクターに置き換える。
• テレメトリ有効化ルールを使って、Application Load Balancer のログを CloudWatch Logs にストリーミングする。
• ストレージコストを自動的に削減するために、ログアカウントで CloudWatch Logs Intelligent Tiering を有効にする。

最近のリリースの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページをご覧ください。

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

9 月 16 日開催の「I Didn’t Know Amazon CloudWatch Could Do That」ウェビナーにご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングの迅速化にお役立てください。

著者について

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