re:Invent 2025: CloudWatchによるアプリケーションとGenerative AIのObservability向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Elevate application and generative AI observability (COP326)
この動画では、Amazon CloudWatchを活用したアプリケーションとgenerative AIのobservability向上について解説されています。Matheus ArraisとPeter Gengが、Application Signalsを使用したAPM（アプリケーションパフォーマンス監視）の自動検出、golden signals（volume、latency、faults、errors）の監視、SLO（Service Level Objective）の設定方法を実演しています。特にgenerative AI observabilityでは、Amazon CloudWatch AI Observabilityを紹介し、Bedrock AgentCoreで動作するAIエージェントのトレーシング、評価機能、PIIデータ保護について詳しく説明されています。OpenTelemetryを使用した計装、エンドツーエンドのプロンプトトレーシング、LLM as a judgeによる品質評価など、AIワークロード特有の監視手法が具体的なデモとともに示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
COP 326セッション開始：視界が限られた運転とアプリケーション運用の類似性
COP 326、アプリケーションとgenerative AI observabilityの向上についてです。私の名前はMatheus Arraisです。テキサス州ダラスを拠点とするCloudOpsのworldwide tech leadを務めています。今回が6回目のre:Inventへの参加となります。ここに来られてとても興奮しています。Peterも一緒です。こんにちは、私はPeter Gengです。CloudWatchのproduct managerをしています。私にとっては初めてのre:Inventですが、皆さんにお会いできてとても嬉しいです。素晴らしいですね。
では、この写真から始めましょう。 想像してみてください、もしあなたが見慣れない高速道路を運転していて、視界が非常に限られているとしたら。かなり神経をすり減らしますし、危険でもありますよね。道路がどうなるのか、目の前に何が現れるのか正確にはわからず、ハンドルをさらに強く握りしめ始めます。手のひらは汗ばみ、ただ安全に家まで運転したいと思うだけです。私たちは皆、この馴染みのある状況を経験したことがあります。視界が限られた状態での運転、そしてそれを二度と繰り返したくないと思っています。
これは、AIを搭載した今日の複雑なアプリケーションを運用することに似ています。私たちはしばしばvisibilityとobservabilityを欠いており、システムがどのように前進しているのかを理解したいと思っています。それがなければ、かなり危険です。私たちのCTOであるWerner Vogelsもかつてこう言いました。 visibilityが必要だと。なぜなら、それがなければ、ただ推測しているだけだからです。システムが次に何をするのか、システムがエンドユーザーのダイナミクスにどう反応するのかを推測しているだけなのです。
このプレゼンテーションでは、それについてお手伝いします。まず、 application observability monitoringが今日どのような状況にあるのかを理解します。generative AIが導入された今、どのような課題があるのか、それがどのように関わってくるのか、そしてAIを搭載したアプリケーションへのvisibilityとobservabilityをどのように獲得するかについてです。私とPeterのお約束は、このセッションを終えて皆さんが職場や自宅に戻られる際に、single pane of glassでアプリケーションとgenerative AI observabilityの両方を向上させる方法について、実行可能なinsightsを持ち帰っていただくということです。
Johnのペルソナと複雑なアプリケーションの多層的オブザーバビリティ
Johnから始めましょう。ここにいるJohnは私たちのpersonaです。 彼はSREであり、developerであり、日常的にCloudWatchを使用している人物です。ご覧のとおり、彼のアプリケーションはかなり複雑です。多くのレイヤーがあり、backend、database、infrastructureレイヤーなどがあります。JohnはCPU metricsのようなシンプルなmonitoringを使用しています。
Johnが活用できるアプリケーションには多くのレイヤーがあります。この図でご覧いただけるように、画面に表示されている各レイヤーは、観測可能なレイヤーとなっています。ネットワーキング、インフラストラクチャ、アプリケーション、データベース、ユーザー、 などですね。下から上に向かって、AWSは多くの選択肢を提供しています。例えば、インフラストラクチャでは、EC2の観点、コンテナの観点、サーバーレス、オンプレミスなど、様々な観点から観測することができます。
アプリケーションレイヤーは非常に重要なレイヤーの一つです。なぜなら、アプリケーションログを使用してアプリケーションがどのように動作しているかを理解したり、トレースを使ってアプリケーション間の相互接続を把握したり、CPUメトリックの観点からビジネス成果に結びついたサービスレベル目標の観点へと移行することができるからです。最後になりますが、ユーザーの観点もあります。ここではCloudWatchを使用してユーザー行動の理解を構築することができます。
さて、Johnが私たちに求めているのは、ネイティブな統合です。彼は現在AWSを使用しているため、問題への対処時間を短縮し、解決時間も短縮したいと考えています。コストを最適化したい、データをあちこちに移動させたくない、と。データの複製を行うのは非常に複雑ですからね。そして、シングルペインオブグラスであるべきで、使いやすいシンプルなサービスであり、実用的なインサイトを提供し、例えば機械学習を使用して異常を理解するようなスマートなものであるべきです。
そして、これらの各レイヤーに対して、Amazon CloudWatchはJohnに観点とオプションを提供し、彼のアプリケーションを隅々まで監視することができます。下から上に見ていくと、ネットワークの観点では、例えばインターネットモニタリングがあり、インターネットのパフォーマンスを分析して、インターネットプロバイダーに問題があるのか、あるいは何らかの障害があるのかを理解することができます。
インフラストラクチャレベル、青い部分ですが、ここではCPUコンテナサービスがあり、Container InsightsやLambda Insightsを活用して、その特定のインフラストラクチャ選択のシステムレベルを理解することができます。Database Insightsもあり、データベースのパフォーマンスをリアルタイムで収集・監視できるため、どのSQLクエリが他のものより時間がかかっているかを理解することができます。緑色の部分、アプリケーションレイヤーは、先ほど申し上げたように最も重要なものです。なぜなら、アプリケーションのKPIを自動的に検出し、SLOを使用して顧客との間で約束しているサービス品質のコミットメントを維持することができるからです。
最後になりますが、トップレベル、つまりユーザーの視点では、リアルユーザーモニタリングとsyntheticを使用してcanaryを作成し、ユーザーの行動をシミュレートして、可用性の問題やパフォーマンスの低下があればアラートを出すことができます。これらすべてが単一のツール、Amazon CloudWatchで実現できます。 では、observabilityの3つの柱について説明します。皆さんご存知かもしれませんが、これが今日お話ししたい内容です。すべてのobservability戦略には、metrics、logs、tracesが伴います。これがobservabilityの3つの柱と呼ばれるものです。
オブザーバビリティの3つの柱とゴールデンシグナル、そしてSLOの重要性
Metricsでは、私のアプリケーションのレスポンスレートが35%増加したという情報を理解したいわけです。Logsでは、ユーザーが私のアプリケーションで認証したという情報を、構造化または非構造化フォーマットで持っています。そしてTracesでは、マイクロサービス全体の分散処理時間について質問したり、答えを得たりすることができます。さて、冒頭でご覧いただいたように、Johnはかなり複雑なアーキテクチャを持っており、もちろんそれに伴っていくつかの課題も生じています。
マイクロサービスのような複雑なアーキテクチャは、エンドユーザーを満足させるために、時間の経過とともに一定のパフォーマンスを必要とします。また、Johnは可用性の低下や高いレイテンシーを理解するために、テレメトリーデータをサービスと手動でつなぎ合わせる必要があります。また、ビジネスにとって何が優先事項なのかを理解するのは非常に難しいですよね。つまり、これらの異常のうち、どれがビジネスにとって最も重要で、どのように優先順位をつけるかを理解することです。最後になりますが、このばらばらな体験、つまりmetrics、logs、tracesの観点からテレメトリーデータを関連付けるには、リアルユーザーモニタリングとsyntheticモニタリングも導入する必要があります。これらすべてをまとめると、実際の問題に取り組むまでに非常に長い時間がかかる可能性があります。
さて、Johnがモニタリングを向上させるために何を使用し、何を具体的に探すべきかについて、技術的な視点を提供するために、golden signalsがあります。Golden signalsとは、volumeリクエスト、これはアプリケーションに対する需要に直接影響し、レイテンシーに直接影響します。レイテンシーは速度ですよね、特定のリクエストが解決されるまでにどれくらいの時間がかかるか、そしてレイテンシーが高いと、ユーザーエクスペリエンスにも直接影響します。下の2つは、faultsとerrorsです。これは不正なリクエストやアプリケーションの問題に関連しているので、アプリケーションモニタリングを別のレベルで理解するためには、これらを理解する必要があります。
さて、これは技術的な視点です。Johnがここでやるべきことは、これをビジネスの視点からもつなげることです。例えば、ビジネスインパクトを1分あたりの収益に直接結びつけたり、カート放棄がある場合、そのレベルはどれくらいかということです。ユーザーエクスペリエンスシグナルとは何か、例えばページロード時間、APIエラーコード、セッション期間などです。サービスヘルスインジケーターとして、レイテンシー、P90、P95などがあり、全体的な健全性を理解するためにその特定の部分を理解したいわけです。そして最後になりますが、信頼性目標との接続、各シグナルをSLO、Service Level Objectiveと結びつけて、アプリケーションの最適なレベルを維持していることを確認します。
では、これらの質問に答えるために、Johnはその特定のレイヤーに焦点を当てるべきです。なぜなら、そのレイヤーでJohnはすべての点を結びつけることができるからです。アプリケーションレベルですね。そしてAmazonはAPMソリューションを提供しています。それはAmazon CloudWatch Application Signalsと呼ばれるものです。Application Signalsを使用することで、Johnはアプリケーション監視を向上させることができます。
なぜなら、まず第一に、Application SignalsはOpenTelemetry SDKを使用して、アカウント内にどのアプリケーションがあるかを自動的に検出します。何もする必要はありません。CloudWatchによって自動的に検出されるんです。第二に、事前に構築されたダッシュボードがあり、それらのゴールデンシグナルを含む標準メトリクスが含まれています。ですので、私が数秒前に述べた技術的なメトリクスを理解することができます。第三に、数回のクリックで根本原因を簡単に理解できます。HTTPの不正なリクエストがある場合や、例外がある場合、例外がどこで発生したのか、どのコード行なのか、などを理解できます。最後になりますが、SLO、Service Level Objectiveです。これは信頼性に関する目標に関連しており、ビジネス目標に結びついています。これはあらゆるアプリケーション監視戦略にとって非常に重要です。
だからこそ、アプリケーション監視について話すとき、SLOについて話すのです。なぜなら、それはユーザーの視点からアプリケーションの健全性を包括的に理解するものだからです。そして、これがどのように機能するかです。Pet Research APIというアプリケーションまたはAPIがあり、この特定のAPIの稼働時間99.9%という特定の内部目標があります。さて、それを達成するために、私はすでに特定のSLI、つまりService Level Indicatorを選択して、その目標を測定します。この場合、それは稼働時間です。しかし、ご覧のとおり、0.1%があり、これがエラーバジェットと呼ばれるものを作り出します。つまり、この特定のSLOを30日間の期間で評価している場合、まだ43分のダウンタイムがあっても、SLOを満たすことができるということです。
なぜこれが重要なのでしょうか？なぜなら、これをすべてSLAに結びつけることができるからです。そしてSLAは、皆さんご存知のとおり、顧客と交わす合意です。ですので、これを全体的に見ると、何が得られるでしょうか？幸せな顧客が得られます。なぜなら、すべてのAPIを監視し、すべてのSLOを確立してSLIに結びつけることで、顧客はあなたがアプリケーションを大切にしていることを理解できるからです。この特定のケースでは、Johnは幸せなユーザーも達成することになります。
Amazon CloudWatch Application Signalsのデモ：障害とレイテンシー問題の追跡
では、デモに行きましょう。楽しい部分に行きましょう。このデモでは、具体的に2つのシナリオをお見せします。障害と、アプリケーションで発生しているレイテンシーの問題、そしてApplication Signalsを使用して単一のコンソールでアプリケーション全体のオブザーバビリティを監視する方法です。では、まず最初に、SLOをお見せします。ご覧のとおり、複数のSLOがあります。そして、もちろんそのうちのいくつかは健全ではありません。SLOの作成方法をお見せしたいと思います。SLOを作成するには、まずSLIを選択する必要があります。SLIは、サービスオペレーションとCloudWatchメトリクス、またはサービス依存関係のいずれかになります。そして繰り返しになりますが、そのサービスとは、OpenTelemetry SDKによって自動的に検出されるものを意味します。
このケースでは、私のフロントエンドであるPet Clinicフロントエンドと、POSTという特定のオペレーションを使用します。 そして今、興味深い部分なんですが、この特定のSLOに対する計算メトリック方法を選択できます。これはリクエストごと、または期間ごとで選択できます。 また、特定の計算方法の条件も選択できます。レイテンシーで設定することもできますし、今は100ミリ秒を選択していますが、可用性でも設定できます。 クールなことの一つは、CloudWatchがそこに小さなフレーズを表示してくれることで、これが私が何をしているのかを正確に示してくれます。
そこから、私のSLOが何であるかを選択します。このSLOによって評価される間隔または期間を定義します。 達成目標を設定すると、そこにも小さなフレーズが表示されます。もちろん、アラームと紐付けなければ、これらすべては意味がありません。アラームは SLIまたはSLO達成目標、そしてこのSLOの全体的な健全性に直接関連付けることができます。そこにあるすべてが その特定のAPIに対して意味を持ちます。
さて、それを超えて、Application Mapについてもお見せしたいと思います。これは数週間前にローンチしました。 これは、私が先ほど言及した自動検出に関連するものです。OpenTelemetryの観点から、インストルメント化されたアプリケーションだけでなく、インストルメント化されていないアプリケーションもApplication Mapによって検出されることが可能です。グループでフィルタリングできます。ここで選択できる複数のフィルターがあり、そして このアカウント内にあるすべてのアプリケーションが、右側のそれらの小さなボックスに自動的に選択されます。独自のカスタム属性を作成したい場合でも、 OpenTelemetry設定ファイルで直接設定を使用でき、それがこのコンソール上にも直接表示されます。
さて、 先ほど言及したPet Clinicについてもう少し深く見ていくと、ダブルクリックすると、トポロジーが表示されます。これが私のアプリケーションのトポロジーで、すべての フロントエンド、バックエンドとの接続、接続しているすべてのマイクロサービスを見ることができます。そして、細い線をクリックすると、 あるサービスから別のサービスへの相互接続を見ることができ、障害率や 高レイテンシーなどを伴うトップパスを理解できます。その特定のフロントエンドとバックエンドを再度クリックすると、右側に表示されるのは、 先ほど言及したゴールデンシグナルです。つまり、リクエストボリューム、リクエストレイテンシー、エラー、そして障害が、すぐにそこに表示されます。拡大して 時間経過で見ることができ、P90、P99、またはP50を選択できます。
そして、ここで CloudWatchが提供するクールなことの一つは、オペレーショナル監査だと思います。ご覧のように、いくつかの低下やスパイクがあります。CloudWatchはすでに そこに問題の兆候が何であるかを示してくれます。つまり、その期間に正確に何が起こったのか、そしてさらに評価する必要があることが正確に 何が起こるのかを示してくれます。さらに評価するために、ダッシュボードをクリックすると、この特定のアプリケーションの全体的なメトリクスを見ることができ、再び、すべてのゴールデンシグナルがここにあります。 ご覧のとおりですが、SLO作成で言及したことの一つは、サービスオペレーションです。OpenTelemetryを使用することで、これらのアプリケーションがバックグラウンドで使用しているすべてのPOST、GET、PUTを理解でき、ご覧のように、健全でないSLIがあることがわかります。
ダッシュボードをダブルクリックすると、障害のスパイクが発生しているので、そのリクエストを処理するために必要なspanの相関関係が自動的に表示されます。 そして、これらのspanの1つをクリックすると、フロントエンドからバックエンドまでのtrace mapが正確に表示され、このリクエストを 解決するための全体のtraceとspanが正確に表示されます。そして、同じ可視化を見ることもできますが、今度はタイムラインの観点から、span timelineの観点から、このホストがどこにあるかを見ることができます。 ご覧のように、visits-service-javaに障害があります。例外がスローされており、その例外はDynamoDBのスループットの問題です。 メッセージを見ることができますし、具体的には、コード内で戻って問題を修正する必要がある行も見ることができます。 そして、DynamoDBの観点からも、右側にメッセージを見ることができます。
興味深い点の1つとして、 前のダッシュボードに戻ると、これはEKSクラスターなので、この特定の障害で最も 問題を抱えているノードがどれか、そして正確にはどのpodがこの問題を抱えているかを見ることもできます。そして、 これらのノードとpodを見ることで優先順位をつけることができます。
この小さなボタンのContainer Insightsをクリックすると、 Container Insightsのパフォーマンスを全体的に見ることができるコンソールに案内されます。これは単一のペインで見ることができます。
Dependenciesは同じアプリケーションの別のタブで、このアプリケーションに関連するすべての依存関係を見ることができます。そしてもちろん、 サービスに関連する依存関係も見ることができます。これが私が話した2番目のユースケース、レイテンシーです。ご覧のように、 この特定の時間にスパイクがあり、前のユースケースと同じ方法論を使って、tracingの1つをクリックします。今はレイテンシーを探しているので、高いレイテンシーを持つ異なるAPIであるため、例えばBedrockを含む異なるサービスによって処理されていることがわかります。
同じ可視化のtrace mapがあり、すべてのspanを含むタイムラインもあります。ご覧のように、Bedrock runtimeにエラーがあります。具体的には、 viewをクリックすると、コード内でどの例外がスローされているかが正確に表示されます。この場合、問題はBedrock foundation modelが 非推奨になっているため、高いレイテンシーが発生しています。非推奨になっているため、ユーザーに 解決されるまでに時間がかかりすぎているのです。イベントをクリックすると、それをより適切に見ることができます。
さて、これはアプリケーションレベルです。トップレベルのレイヤーもお見せしたいと思います。synthetic canariesを使用して、ユーザーの行動を作成およびシミュレートすることができます。この場合、私たちのペルソナであるJohnに対して、使用する必要がある手順を正確に追うシミュレーションを作成でき、ユーザーがアプリケーションを何に使用するかをシミュレートします。そして、設定すれば小さなスクリーンショットも撮影します。また、先ほど述べたReal User Monitoring、つまりユーザーエクスペリエンスを使用して、ページの読み込みを理解することができます。エラーがある場合、右側で時間を増やすと、時間経過に伴うエラーを確認でき、ユーザーの視点からどのページが特に読み込みに問題を抱えているかを正確に把握できます。これらのいずれかをクリックすると、その特定のエラーに関する全情報が表示されます。そして、これはユーザーの視点です。セッションがいつ発生したか、これがいつ起こったか、ユーザーの行動をシミュレートするためにどのタイプのブラウザが使用されたかを確認でき、全体的なユーザーエクスペリエンスを理解することができます。
Generative AIの時代：AIアプリケーション監視における新たな課題
さて、これがアプリケーション部分です。そして今度はgenerative AIに移りたいと思います。なぜなら、今John Peterは自分のアプリケーションにgenerative AIを組み込む必要があるからです。Mathsさん、どうもありがとうございました。AIワークロードを監視するためにobservabilityがどのように変化したかについてお話しできることを、とても嬉しく思います。では、現在会社でAIアプリケーションやワークロードを構築している方は手を挙げてください。わあ、すごい、ほとんどの方ですね。では、皆さんは正しい場所にいらっしゃいます。
この2025年というクレイジーな年を振り返ると、AI搭載アプリケーションが、皆さんのビジネスとユーザーがビジネスとやり取りする方法を変革していくことは、誰もが知っています。ここにいるすべてのテクノロジーリーダーの方々は、AWSでこれらのAIワークロードを構築することがいかに簡単で強力であるかを、リアルタイムで目の当たりにしています。そこで私は、observabilityという観点から、この時代をナビゲートするお手伝いをし、3つのことをお見せします。第一に、observabilityがどのように変化したか、そして使用できる新しいツールについてです。第二に、observabilityには皆さんがすでに慣れ親しんでいるものと同じ部分がまだあること、そして使用できる既存のツールをお見せします。そして最後に、それらすべてをワークロードのデモで一緒にお見せします。
では、記憶の小道を歩いて戻ると、私たちはこのAIの話を、質問と回答のチャットボットがあった頃に始めました。しかし、それはまだ2023年のことです。その後、私たちが持つようになったのはAIアシスタント、つまり特定のビジネスプロセスを通じてユーザーをステップバイステップで導くようなAIエンティティでした。しかし今日、私たちが持っているのはAIエージェントです。これらのエンティティはより自律的で、特定のタスクを自分自身で実行し、特定の目標を達成するために独立して意思決定を行うことができます。私たちが将来的にあると考えているのは、完全にagenticなシステムです。システム全体が独立して動作し、オープンエンドなリクエストや目標を達成し、ビジネス全体が独自の意思決定を行い、その成果を推進するのを支援します。
では、これらのAIアプリケーションをどのように構築するのでしょうか？AWSでは、これらのワークロードを構築するための完全なスタックのツールを提供しており、モニタリングはスタック全体にわたって行われます。一番下から始めると、SageMakerと私たちのインフラストラクチャ上で、これらのAIモデルの構築、実行、トレーニング、デプロイを支援できます。そして中間レイヤーが、核心部分になると思います。まずAmazon Bedrockですが、これは単一のAPIを通じて多数の基盤モデルへの直接アクセスを提供する完全マネージド型サービスで、アプリケーションを非常に簡単にスケールアップできます。そして、より最近ローンチされたBedrock AgentCoreは、高度にスケーラブルで有能なAIエージェントを構築およびデプロイするための場所です。これには、エージェントがコンテキストを知ることができるようにメモリを、エージェントがどのようなサードパーティAPIを呼び出すかを制御できるようにgatewayを、そして認証と制御のためのidentityを、これらのエージェントを強化するための一連のツールが付属しています。
そしてさらに上のレイヤーでは、AWSにおいても、これらを使って完全にagenticなシステムを構築してきました。Qによるagentic IDE、Qによるagentic business intelligence、そしてAmazon Connectによるagentic contact centerなどです。私たちは何百万ものお客様に愛されてきました。ですから、どこで、どのようにAIを構築していても、私たちがカバーします。そして繰り返しになりますが、すべてのレイヤーにおいて、observabilityが皆さんと共にあります。 さて、ここで疑問が出てきます。これらのAIアプリケーションに対して、どのように適切なobservabilityを持つのか?AIが何をしているのか、どのように見て、どのように追跡するのか?そして、何が新しくて、何が違うのか?では、この急速に変化する時代を乗り切るお手伝いをさせてください。
これらのAIアプリケーションについて、お客様とお話しした結果、皆さん一様にいくつかの共通の課題を挙げられました。第一に、これらのagentは非決定的になり得るということです。彼らの行動は、過去の似たようなシナリオからでさえ、時と場合によって異なることがあり、これは非常に予期しないことです。彼らはティーンエイジャーのようなものです。時には素晴らしいことを言いますが、時には何も言わなければよかったのにと思うこともあります。そして第二に、根本原因分析は、agentが行った一連の呼び出しを追跡することに焦点を当てていますが、トレースするのが非常に難しいのです。それらの呼び出しを大規模に分析するのは非常に困難です。なぜなら、各モデルプロバイダーが少しずつ異なるフォーマットを持っており、異なるリージョンやアカウント間でそのボリュームを追跡するのは、本来あるべきよりも難しいからです。
そして最後に、システムヘルスの評価です。これはMatteoが話したのと同じ目標ですが、新しいのはこの「quality」という言葉です。今では、なぜagentがそれをしたのか、なぜそのようにルーティングしたのか、どのようなコンテキストを持っていたのかに答える必要があります。従来の監視ツールは、パフォーマンス、つまりレイテンシーやエラーのような表面的なパフォーマンスパラメータを教えてくれますが、推論については教えてくれません。AIの意思決定プロセスを説明してくれないのです。ですから、もはやAIが動いているかどうか、上がっているか下がっているかを観察するだけでなく、推論と意図を観察しようとしているのです。そして私たちは、これが皆さんの新しい運用上の現実になると信じています。Observabilityは、信頼性、安全性、品質のコントロールポイントになるでしょう。
Amazon CloudWatch AI Observabilityの紹介とBedrock AgentCoreとの統合
さて、Matteoがお見せしたのと同じスタックレイヤーに戻りますが、私たちはAIワークロードがこれらすべての上に乗ると考えています。そしてobservabilityはそこにあります。最高レベルで皆さんと共に動作し、インフラストラクチャシグナルからずっと接続し、スタック全体を通してテレメトリーをつなぎ合わせ、それらの異なるモデルやagentアクションから集約して、エンドツーエンドのインタラクション全体を皆さんのために観察します。だからこそ、私たちがこれらの課題に取り組んだ結果、Amazon CloudWatch AI Observabilityをご紹介します。すでにGAになっており、多数の機能を備えています。第一に、agentがどのモデルを使用していても、Strands、Crew AI、LangChainなどのフレームワーク上で、それらのパフォーマンスパラメータに関するout-of-the-boxダッシュボードとともに、agentの360度ビューを提供します。第二に、OpenTelemetryフォーマットを使用している限り、AIワークロードの計装は非常にシンプルです。これについては後ほど少し触れます。
そして非常に重要なのが、エンドツーエンドのプロンプトトレーシングです。これはLLM呼び出し、agentアクション、ツール、そしてメモリ呼び出しを横断してトレースし、問題を迅速に特定できるようにします。そしてデータ保護の世界では、これらのAIインタラクションにおいて、AIが受け取るものやAIが出力するものにPIIコンテンツが含まれる可能性が非常に高く、それらはログに保存されます。私たちはそのコンテンツをマスクして保護するデータ保護機能を持っています。
最後に、品質を監視するための評価機能についてです。これらはLLMをジャッジとして使用し、AIがどのように応答しているか、正しいことを言っているか、正しくルーティングされているか、そして顧客の問題を解決しているかを継続的に評価します。
これらのエージェントを構築するのは、AWS Bedrock AgentCore上では非常に簡単です。AgentCoreを使用すると、非常に高性能なAIエージェントを安全に大規模にデプロイして運用することができます。これらの動的なエージェントワークロード向けに特別に構築されたインフラストラクチャを提供しています。ご覧のように、エージェントが使用するさまざまな側面から統合されています。例えば、Bedrock上で提供されているあらゆるLLMモデル、そしてエージェントが動作するために取得して使用するコンテキストであるAgentCoreメモリを使用します。Identityはセキュリティのコントロールを管理し、またgatewayは、サードパーティAPIツールコールなどを行うための中心的な場所となります。ご覧のとおり、エージェント周辺のすべてのツールとプリミティブは、観測可能性プラットフォームであるCloudWatch generative AI observabilityにテレメトリを送信します。これにより、これらすべてを監視するための単一のペインオブグラスを持つことができます。
多くのお客様に共感いただいている点として強調したいのは、 AgentCore runtimeサービス上でエージェントをホストでき、そのテレメトリはCloudWatchを通じて送られてくるということです。私がお話しした機能すべてをすぐに利用できます。また、EC2、EKS、オンプレミス、または他のクラウドなど、別の場所でエージェントをホストしている場合でも、データがOpenTelemetryフォーマットである限り、それを受け入れることができ、CloudWatchで非常に似た機能を利用できます。つまり、お客様のニーズに合わせた柔軟性を提供しているということです。
AgentCore runtime上で実行されているエージェントについてもう少し深く掘り下げると、これらのエージェントを作成して実行する際に、作成方法についてさらなる柔軟性を提供しています。非常に人気のあるStrands Agents、Crew AI、LangChainなどのagenticフレームワークと、インストルメンテーションをサポートしています。サポートされているインストルメンテーションライブラリは非常に幅広く、すべてオープンソースです：OpenInference、Traceloopなどです。インストルメンテーションが完了したら、Amazon Distro for OpenTelemetry、ADOTと接続し、そのインストルメンテーションを収集してCloudWatch OpenTelemetryエンドポイントに送信すると、先ほどお話しした画面を動かすことができます。
より具体的には、runtime上でホストされているエージェントについて、先ほどお話ししたADOTを覚えていますか？すべてのテレメトリが入ってきたら、CloudWatchテレメトリ設定でワンクリックするだけで、AgentCoreメモリ、AgentCore gatewayなどの個々のプリミティブからのすべてのテレメトリをオンにできます。アカウント全体からワンクリックで、すべてがCloudWatchに送られ、それらのビューを動かします。他の場所でホストされているエージェントについても、やはりADOTを使用しますが、強調したいのは、OpenTelemetryフォーマットである限り、それも受け入れて、CloudWatch transaction searchをオンにして、先ほどお話ししたアクションやツールコールをつなぎ合わせることができるということです。こちらは非常に簡単なクイックスタートガイドで、今すぐお手元のラップトップで作業を始めることもできます。
Generative AIオブザーバビリティの基盤：メトリクス、ログ、トレースの活用
さて、これまでの基礎的な説明を踏まえて、Johnが実際にどのようにgenerative AIワークロードを扱っているのか、より実践的な観点から見ていきましょう。 このスライドは、先ほどご覧いただいたものと非常に似ていると思いますし、皆さんもすでにご存知ですね。メトリクス、ログ、そしてトレースです。これらがgenerative AIのオブザーバビリティを支えています。皆さんが今日使っている同じツールです。メトリクスでは、トークン消費量のようなものを扱い、それらがどのように変化しているかを追跡します。 AIが行った作業量ですね。ログは、ユーザーからの詳細な入力と、LLMモデルやエージェントからの出力を保持する場所です。最後にトレーシングですが、これは非常に重要です。トレースによって、レスポンスがシステム全体をどのように伝播していくかを理解でき、集約レベルで分析することができ、さらに個々のインタラクションごとにドリルダウンする機能も備えています。
実際にどのように機能するか、もう少し詳しく見ていきましょう。メトリクスについては、監視できる一般的なメトリクスがいくつかあります。呼び出し回数、これらの呼び出しがどれくらい速く完了しているか、スロットリング、そして入力トークン数や出力トークン数といった作業量です。ログは、モデル呼び出しのロギングと、各個別ステップの内容やツール呼び出し、エージェントのアクションを含むスパンログから取得されます。最後にトレースですが、同じセッションIDまたはトレースIDを含んでいる限り、それらは結合され、先ほどお話ししたインタラクションを表示できるようになります。
これらのメトリクスを、私たちが監視すべきだと考えているゴールデンメトリクスの同じセットに組み込みました。 最初のバケットはトークン使用量で、これはAIが行っている作業量を表し、需要予測だけでなくコストの予測にも役立ちます。次にレイテンシーがあり、これはAIがどれだけ速くニーズに応答しているかを測定します。スロットルは、制限やクォータにどれだけ近づいているかを追跡するのに役立ち、エラーはリクエストで何か問題が発生していることを示します。これらすべてを 設定不要の事前構築された自動ダッシュボードで表示できるため、ここから診断やトラブルシューティングを行うことができます。
追加のフィルターには、モデル自体でフィルタリングする機能が含まれており、使用している特定のモデルにドリルダウンして、そこで何か問題が発生していないかを確認できます。また、総消費パターンを追跡したい場合は、アラート機能など既存のCloudWatch機能と完全に統合されています。さて、ここからは オブザーバビリティの世界では非常に異なる、比較的新しい概念で、今のAIに関連するものをご紹介します。先ほど申し上げたように、皆さんにとっての新しい運用上の現実は、これらのAIレスポンスやエージェントアクションの品質を見ることになります。LLMはしばしば幻覚を起こしますし、エージェントは望ましくない独自の経路を取ることがあります。
これまで、チームがこうした質的な問題に目を配ってきた方法は、データサイエンスチームがAIワークロードの非常に小さなサンプルを取り、手動で確認して評価し、それが良好な場合にのみ、実世界にAIをデプロイすることに同意するというもので、実際に何が起こるかについてためらいや不安を抱えていました。つまり、信頼の欠如と非常に負担の大きいプロセスがあったわけです。そこでevaluationsを使えば、LLM as a judgeを活用して、エージェントがそのコンテキストにどれだけ忠実に従っているか、与えられた指示にどれだけ従っているか、顧客がタスクを達成し質問に答えるのにどれだけ役立ったかを評価できます。これはAIワークロードのトラフィック全体に対して継続的かつ自動的に行われ、フルサンプリングまたはサンプルの一部のみをサンプリングする機能があるため、お客様のチームが以前行っていた労働集約的で手動の評価プロセスを本当に取り除くことができます。
評価メトリクスは昨日ローンチされたばかりで、現在CloudWatchで利用可能になっています。これはBedrock AgentCoreの評価機能によって提供されています。メトリクスの側面についてお話ししましたが、ログに話を戻しますと、これは私のお気に入りの一つです。なぜなら、これは皆さんが使用する最も情報が密に詰まったものだからです。これから、invocationログについて、それらをどのようにクエリするか、そしてそのデータを保護する方法についてお話しします。invocationログは、LLMモデル自体とエージェントの両方から取得できます。CloudWatchとS3に送信することを選択でき、CloudWatchに入ると、既存のワークフローと統合できる、おなじみのCloudWatchロググループの概念で保存されます。
これらのログがCloudWatchに入ったら、CloudWatch Logs Insightsを使用してより深く掘り下げることができます。これは強力なクエリツールです。SQLやOpenSearch PPLのような強力な言語をサポートしており、定期的に強力なクエリコマンドをローンチしています。パターン分析を使用してログイベント内の共通のテキスト構造を検出し、より迅速なインサイトを得ることができますし、自動化されたリアルタイムの異常検知を使用して、これらのエージェントの動作やパフォーマンスの変化を特定することもできます。そして先ほど申し上げたように、これらの顧客とのインタラクションにはPII情報が含まれる可能性がありますが、ログがCloudWatchにある場合、私たちがカバーします。
CloudWatchのデータ保護機能は、クレジットカード、名前、住所などの機密性の高い顧客情報を識別してマスクし、基本的にそれらを編集することができます。また、きめ細かいIAMロールベースのコントロールも提供しているので、スーパーユーザーがコンテンツを見る必要がある場合は見ることができますが、ほとんどのユーザーは見ることができません。そして、コンプライアンスとレポーティングのための自動監査レポートを生成します。さて、最後のパートに戻りますが、メトリクスについてお話しし、ログについてお話ししました。そして今、トレースについてお話しします。これはおそらく、生成AI observabilityにおいて最も重要な部分です。
トレーシングでは、まず最初に、すべての個々のAPI呼び出しと、エージェントが行った関数呼び出しの詳細情報を、非常に整理されたリストビューで表示することができます。もはや複数のデータベースでクエリしてそれらをつなぎ合わせる必要はありません。それは自動的に行われます。そして2つ目は、これらのアクションをタイムラインで表示するので、どれが最も時間がかかっているか、どれが予想よりも長くかかっているかを知ることができ、より迅速にトラブルシューティングできます。そしてtrajectoryマップは、この特定のトレースに対するすべての異なるインタラクション、API呼び出し、ツール呼び出しを表示します。ここの各ステップはスパンであり、このトレースに集約されます。このマップは自動的に視覚化されるので、これらのツール呼び出しの階層と順序を非常に理解しやすい形で簡単に把握できます。
Pet Clinicエージェントのデモと評価機能、そしてセッションのまとめ
さて、何が違うのか、何が同じなのか、ログ、メトリクス、トレースについてお話ししました。たくさんありますね。それでは、短いデモですべてをまとめてみましょう。では、デモのパートに移りましょう。このデモでは、先ほどお見せしたPet Clinicを見ていきますが、今回はobservabilityの一般的なobservabilityのユースケースで、これは管理者、マネージャーの視点です。Bedrock AgentCore Runtimeによってホストされている完全にホストされたエージェントを使用しています。そして舞台裏では、先ほど見た複数のマイクロサービスがあります。これは同じ昔ながらのPet Clinicアプリケーションです。データベースなどがあります。
それでは、ここでこのPet Clinicに関連するいくつかのプロンプトを入力しています。そして、この特定のプロンプトでは、オーナーIDに関連する情報が表示されています。ご覧のように、Peterが以前示したように、いくつかのPII情報が含まれています。これはもちろん、管理者の視点で使用されているエージェントです。 そして、この最後のプロンプトは、このペットID番号1の請求情報に関連しています。そして、これからご覧いただくのは、エージェントがその情報をキャプチャできない、その情報を取得できないということです。いくつかの理由があります。 さて、これはもちろんフロントエンドです。それでは、実際にコンソールを見てみましょう。
まず最初に、Amazon CloudWatchの左側に、GenAI Observabilityという新しいセクションが表示されます。そして、これがPeterが以前示したモデル呼び出しです。 呼び出しレイテンシなどのGenAIゴールデンシグナルがあります。そして、ファウンデーションモデルで行われるすべての呼び出しについて、フィルタリングしたり、クエリを実行したり、内部のログを呼び出したり、JSON ファイル全体を確認したりすることができます。 モデルIDでフィルタリングすることもできます。おそらく複数の異なるファウンデーションモデルを使用している場合、それらも確認できます。
次に、Bedrock AgentCoreに移りますが、ランタイムだけでなく、CloudWatchはAgentCoreの他の部分も監視します。メモリ、ゲートウェイなどです。ここでは、特にエージェントランタイムに焦点を当てています。 3つのエージェントがあります。これらのエージェントに関する全体的な情報、セッション数、トレース数などが表示されています。私が使用してきたPet Clinicについてさらに深く見ていきます。この概要タブでいくつかの情報をお見せしたいと思います。 最初から評価に関連する情報があります。評価を使用しており、評価スコアと構成メトリックを確認できます。スパン別にエラーとレイテンシを確認でき、この表があります。 ご覧のように、DynamoDBに関連する多くのエラーがあり、その情報を確認できます。もちろん、必要に応じてダブルクリックすることもできます。
少し下にスクロールすると、まだ概要ページですが、このエージェントが持っているセッション数、トレース数、そしてトークン消費量も表示されます。これはコスト最適化やBedrockがどのように課金するかにとって非常に重要です。 これは有用な情報で、この時点でのセッション数とレイテンシが表示されています。 ご覧いただいているすべてのものは、すでにあなたのために事前構築されています。最後になりますが、CPUとメモリの使用率です。 さて、エージェントとの各インタラクションはセッションを作成し、セッションにはトレースが含まれ、トレースにはスパンが含まれます。 それでは、セッション部分をさらに深く見ていきます。私が行った最後のプロンプトをキャプチャするために、時間を5分に短縮しました。
ここに同じ情報がありますが、今はこの特定のセッションだけを見ています。これにより、この特定のプロンプトについてさらに深く掘り下げることができます。これらのトレースの1つをクリックすると、すぐに確認できるのは、スパン数、レイテンシ、そしてトークン消費量です。エラーがある場合は、すでにエラーの1つが表示されています。私がそのデータを取得できなかったことを覚えていますか。また、このプロンプト全体の軌跡も確認できます。最初から最後まで、情報を返すためにエージェントが正確に何をしなければならなかったか、そして私の代わりにエージェントが呼び出さなければならなかったすべてのツールです。
同じフォーマットでspanをタイムライン形式やツリー形式で見ることもできますし、このタイムラインでは特定の呼び出しにおけるトークン消費量、入力と出力を表示しています。これは同じ可視化ですが、今度はタイムラインの視点からです。ご覧のように、この特定のセッションがどのように動作しているかを理解するための複数の方法があります。イベント自体を見ると、ここで私が行ったプロンプトを確認できます。そうですね。支払いに関する情報を取得しようとしていて、その後内部的にツールがトリガーされます。そして何が起こるかというと、その情報はDynamoDBテーブルにあるのですが、エージェントには権限がありません。そのため例外、アクセス拒否の例外がそこで発生しています。エージェント自体がその情報を取得する権限を持っていないためです。だからエージェントでその情報を見ることができなかったんです。
ですので、これを修正するためには、もちろんエージェントのIAMロールに入って、それを行う権限を与える必要がありました。さて、評価に関連してお話ししたので、それを見せたいと思います。この特定のエージェントの前にLLM as a judgeがあります。ここで時間を12時間に変更して、このLLMによって分析されたサンプリング情報がどれだけ使用されたかをカバーします。まず第一に、全体的な評価設定を見ることができます。フィルタリングが利用可能で、ステレオタイプ化、セッションなどに関連したものを見ることができます。
各評価は同じ粒度を提供しています：セッション、トレース、そしてspanです。ご覧のように、この特定のエージェントにあるすべてのトレーシングがそこにあり、評価者によって使用されている多くのオプションでフィルタリングできます。ダッシュボードもありますよね。CloudWatchによって構築・作成されたダッシュボードです。これらの要素の一つ一つ、評価者によって使用されているこれらのメトリクスがここにあります。指示に従っているか、LLMが私が与えた指示を使用したか、有害かどうか、役に立つかどうか、ステレオタイプ化しているかどうか、すべての情報がここにあるので、エージェントの動作自体を理解できます。そしてもちろん、CloudWatch Logsを使用してログ形式でも持っています。
デモに戻りたいと思います、セッションに戻って、最後のケース、最後のユースケースを一つお見せします。同じセッションに戻りますが、今度は私が行ったプロンプトの一つ、覚えていらっしゃると思いますが、特定のオーナーの情報を取得することに関連していました。そして再び、ここでトレースに関連するすべての情報を持つことになりますが、お見せしたかったのは、CloudWatchにデータ保護ルールを設定しているためです。その特定のルールは生年月日と電話番号をマスキングしています。ご覧のように、ログでもマスキングされます、このコンソール上で直接ですね。
本日のセッションを終了しますので、いくつかの重要なポイントを持ち帰っていただきたいと思います。まず第一に、今日からオブザーバビリティスタックの強化を始めてください。最初のデモと最初のパートでご覧いただいたように、アプリケーションモニタリングについてお話ししました。APMを使用して、アプリケーション全体の理解、より多くの相互接続、アプリケーションに存在する依存関係を強化することができます。例えばApplication Mapを使用してアプリケーションのトポロジーを見ることができ、これはOpenTelemetryを使用して自動的に検出されます。
第二に、もしagentを構築しているのであれば、agentを構築してCloudWatch AI observabilityを使用して、agent全体を理解し観察すべきです。それらがBedrock AgentCoreでホストされているかどうかに関わらず、CloudWatchを使ってobservabilityを生成し、Amazon CloudWatchと完全に統合して、assessor evaluationを使用することができます。evaluatorを使ってagentをプログラム的に評価してください。これは2日前にローンチしたばかりなので、evaluationをセットアップして、agentの全体的な構造とフローを理解できるようにしてください。そしてこれらすべてを単一のpane of glassで確認できます。
最後になりますが、いくつか役立つリソースのQRコードをご紹介したいと思います。最初のものはデモ、デモコードです。GitHubでデモを公開しています。Bedrock AgentCoreだけでなく、EKS、ECS、EC2でホストされているagentのデモもあります。真ん中のQRコードには、observabilityに関連するすべてのリンクがあります。私たちはCorrelation Showという番組をYouTubeチャンネルでホストしていて、observabilityとcorrelation全般について話しています。workshop、ベストプラクティス、私が言及したすべてのものが、真ん中のその一つのQRコードに入っています。最後の三つ目は、先ほど言及したgenerative AI observabilityに関連する、この特定のローンチのブログ投稿です。
もしこのトピックに興味があれば、ぜひお誘いしたいと思います。villageとobservability villageにCloudWatchのキオスクがたくさんあります。ぜひお立ち寄りください。one-on-oneのデモがあります。世界中からSMEが来ていますので、もし質問があれば、私とPeterが外にいますので、質問にお答えすることもできますが、キオスクに行きたい場合は、ぜひそうしてください。swagもありますし、ステッカーもあります。デモもできますので、ぜひそこに行ってください。お手伝いします。
最後になりますが、感謝を申し上げたいと思います。お時間をいただきありがとうございました。このプレゼンテーションに来ていただいたことに感謝します。ぜひsurveyを完了していただきたいとお願いしたいと思います。私たちは毎年そのデータを使ってセッションを改善しています。携帯電話のAWS Eventsアプリに行っていただければ、MoreからSurveysに行くことができます。これはCOP326ですので、このセッションに関するデータポイントを提供していただき、来年改善できるようにしてください。それでは、re:Inventの残りの期間、幸運をお祈りします。ここにいてくださってありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion