re:Invent 2025: CloudWatchによるGenerative AIワークロードの品質と精度監視
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Monitor the quality and accuracy of your generative AI workloads (COP418)
この動画では、AWSのGanesh SambandanとRaviteja SunkavaliがGenerative AIワークロードの品質と精度の監視について解説しています。AIエージェントの進化と、Strands SDKを使用したエージェント構築の実践的な方法を紹介し、Amazon CloudWatch generative AI observabilityによる監視の重要性を強調しています。ライブデモでは、Pet Adoptionsアプリケーションに統合されたWaggle AIエージェントを使い、Bedrock AgentCoreへのデプロイ、AWS Distro for OpenTelemetryによるゼロコードインストルメンテーション、そしてSession、Trace、Span、Sub-spanといった階層構造でのテレメトリ追跡を実演しています。trajectoryマップによるエージェントの意思決定プロセスの可視化や、火曜日のCEO基調講演で発表された評価メトリクス機能についても詳しく説明されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション開始：Generative AIワークロードの品質と精度の監視
皆さん、ようこそ。この1時間、私たちと一緒に過ごすことを選んでいただき、ありがとうございます。このセッションを皆さんと共有できることは、本当に嬉しく光栄なことです。re:Inventも4日目、ランチの後で、セッション会場とホテルの間をたくさん歩かれていることと思います。ところで、今週1日1万歩を達成された方はいらっしゃいますか？わあ。私は昨日1万5千歩を達成しました。正直、私も疲れを感じています。
さて、良いニュースです。これは座って聞くだけのセッションではありません。ライブデモを交えてインタラクティブに進めていきますので、ご質問があればお気軽に遮っていただいて構いません。私たちのセッション、COP418、Generative AIワークロードの品質と精度の監視へようこそ。私はGanesh Sambandanと申します。AWSのSenior Technical Account Managerです。AWSの戦略的顧客セグメントをサポートしています。この会社には約4年在籍しており、Cloud Operations Technical Field Communityのメンバーでもあります。
私はRaviteja Sunkavaliです。AWSのSenior Solutions Architectで、Cloud Operationsを専門としています。私の専門分野はobservabilityとinstance managementです。素晴らしいですね。本日は一緒にいくつかの興味深いトピックを探求していきます：もちろんAI、Strands SDKを使用したAIエージェント、そしてCloudWatch generative AI observability、そしてこれらすべてのツールを活用して本番環境でAIシステムを大規模に運用する方法についてです。
本日の簡単なアジェンダです。エージェントの紹介。AIエージェント、AIエージェントの進化、そして現在の状況についてお話しします。次に、observabilityについて、そしてなぜAIエージェントにとってobservabilityを持つことが絶対に重要なのかを議論します。そして楽しい部分です。AIエージェントのライブデモと、Strands SDKを使ってAIエージェントを構築する方法をお見せします。その後、CloudWatch generative AI observabilityを探求し、AIエージェントからCloudWatchにメトリクスを取り込んで監視する方法をご紹介します。それから、AIエージェントで直面する一般的なトラブルシューティング手順をいくつかお見せします。最後に、セッション後に探求できるリソースをいくつか共有します。これには、自信を持ってAIエージェントを構築するのに役立つライブコードサンプルも含まれています。
AIエージェントの進化とCloudWatch Generative AI Observabilityの必要性
さて、generative AIは長い道のりを歩んできましたよね？2023年には、チャットボット、プロンプトエンジニアリングの仕組み、RAGシステムの仕組みについて議論していました。つまり、探求と概念実証の年だったわけです。そして2024年が来ました。私たちはいくつかのAIエージェントと、アプリケーション内のいくつかのAI機能を採用し始めました。しかし、議論はこれらのAIエージェントを安全に使用する方法から、AIに対して責任を持つことへとシフトしましたよね？そして今、私たちは2025年にいます。AIはあらゆるところにありますよね？すべてのアプリケーションがAIを有効にしたいと考えています。すべてのエンタープライズ企業がAIから真の自動化とビジネス価値を見出したいと考えています。
ここが興味深いところです。AIエージェントを構築すること自体は比較的簡単、あるいは少なくとも複雑ではないのですが、それらを観測することは本当に困難なんですね。そして、ここでより多くの選択肢を提供するために、AWSではStrands SDKを提供しています。そして、LangChainやCrew AIのような有名なフレームワークがいくつかあり、これらを使ってAIエージェントを構築することができます。これらのフレームワークはそれぞれ異なる利点と機能を持っていますよね。繰り返しになりますが、人気のあるフレームワークなどを使えば、エージェントを構築することは簡単なことです。しかし、このAIエージェントを数万ものAIエージェントを持つ本番環境にデプロイすると、それらのAIエージェントを観測し監視することは極めて困難になります。そして、お客様からは、AIエージェントの最初から最後までの完全なビューを持つこと、リクエストを監視することが極めて困難で挑戦的だと言われています。
この課題を解決するために、私たちはAmazon CloudWatch generative AI observabilityを提供しています。では、Amazon CloudWatch generative AI observabilityとは何でしょうか?これは、すぐに使えるキュレーションされたインサイトとメトリクスです。つまり、invocations、threads、latency、token usageといったすべての重要なメトリクスが同じ場所にあります。エージェントワークフローの360度のビューが得られます。そして、ゼロコードインストルメンテーション。AWS Distro for OpenTelemetryを使用してAIエージェントをインストルメント化し、CloudWatchにテレメトリを送信して監視できるようにします。そして、エンドツーエンドのプロンプトトレーシング。基本的に、AIエージェントの全体的な反復をトレースできます。
AIエージェントがどのようにLLMを起動し、RAGシステムを使用するか。最初から最後までのすべてのリクエストを追跡できます。そして、データ保護ポリシー。組み込みのCloudWatchデータ保護ポリシーがあり、これを使用してデータをマスクし、データインジェクションのコンプライアンスを確保できます。そして最後に、火曜日のCEO基調講演で発表した新しい機能、評価メトリクスです。評価メトリクスとは何でしょうか?基本的には、AIエージェントが適切なタイミングで適切な方法で正しいことを行っているかを確認するために監視するものです。AIエージェントを評価するために使用できるスコアとプロンプトがあります。ライブデモでさらに詳しくお見せします。
CloudWatch generative AI observabilityについて理解していただいたところで、CloudWatch generative AI observabilityの最大の利点の一つは、その柔軟性です。AIエージェントがどこで実行されていても、Bedrock AgentCoreでも、EKSでも、ECSでも、Lambdaでも、CloudWatch generative AI observabilityを統合してアプリケーションを監視できます。この柔軟性により、インフラストラクチャ全体でAIエージェントを監視する能力が得られます。
CloudWatchについて、何を監視するかについて説明しましたので、どのように構造化されているか、何を追跡するか、どのようにすべてのメトリクスを監視するかについて、さらに深く掘り下げていきましょう。一番上にセッションがあります。セッションは、ユーザーとAIエージェント間の完全な会話と考えてください。例えば、チャットボットで質問をする場合、最初から最後までがセッションです。セッションの下には、トレースがあります。トレースは、一つのリクエストと一つのレスポンスからなる一つの会話と考えてください。その間に起こるすべてのことを、トレースで追跡します。
Traceの下には、Spanがあります。Spanは、その対話の中で発生している個々のタスクをすべて追跡するものです。基本的には、ユーザーリクエストを渡したり、LLMを起動したりするようなものです。それに関連するすべてのメトリクスを追跡します。Spanの下にはSub-spanがあります。Sub-spanは、単一のAPI呼び出しやユーザーへの返答、LLMの起動といった、より細かい詳細です。これらすべての重要な概念、Session、Trace、Span、Sub-spanを使うことで、エージェントがどのように動作するか、評価でどのように追跡するか、360度の視点を得ることができます。本番環境でエージェントがどのように実行されるかについて、完全なコントロールと自信を得ることができます。
Strands SDKを使ったAIエージェント構築とBedrock AgentCoreへのデプロイ実演
さて、CloudWatchとAIエージェントの背後にある概念についてすべて説明しましたので、理論から実践に移りましょう。それでは、RaviがAIエージェントとCloudWatchのGenerative AI Observabilityのライブデモをお見せします。Raviがプレゼンテーションをしている間、私は質問にお答えするためにここにいます。質問があれば遠慮なく中断してください、Ravi。
素晴らしい。ありがとう、Ganesh。始める前に、このデモを3つのパートに分けて構成します。最初のパートでは、シンプルなエージェントを構築してローカルで実行し、次にエージェントがマイクロサービスを呼び出すためのツールを追加する方法を見て、それからランタイムにデプロイします。それが最初のパートです。Observabilityを有効にして、CloudWatchの新しいGenerative AIコンソールで全体のテレメトリを観察します。それが2番目のパートで、エージェントのパフォーマンスを監視するためのトラブルシューティングシナリオをいくつか見ていきます。そして3番目のパートでは、新しいEvaluations機能を使ってエージェントの精度を監視します。よろしいですか。
始める前に、ここで質問させてください。これまでにAWS One Observability Workshopを探索したことがある方はいらっしゃいますか？はい、何人か手が挙がっていますね。探索したことがある方には、このアプリケーションは見覚えがあるかもしれません。私たちは、Pet Adoptionsというこのアプリケーションを使って、お客様にAWSとネイティブなCloudWatch、そしてAmazon Managed PrometheusやAmazon Managed Grafanaのようなオープンソースツールでハンズオンをしていただいています。フロントエンドがあり、4つの異なるマイクロサービスがあります。PetSearchが1つのマイクロサービス、PetFood、PetListAdoptions、そしてPayForAdoptionです。このアプリケーションからのすべてのテレメトリはCloudWatchに取り込まれます。今日やろうとしているのは、エージェントを構築することです。Strandsを使ってWaggle AIと呼ばれるものです。
それをBedrock AgentCoreにデプロイし、AWS Distro for OpenTelemetry SDKを使ってテレメトリを収集し、CloudWatchに取り込んで、CloudWatch内でテレメトリを探索します。これが私たちが探索するコードです。スナップショットを撮っていただければ、デモを始めることができます。よろしいですか。デモに移ってもいいですか？素晴らしい。
まず、Strandsの基本を理解して、Strands SDKを使ってエージェントを構築することがいかに簡単かを理解しましょう。皆さんの中で、すでにStrands SDKに精通していて、Strandsを使ってエージェントを構築している方はどのくらいいらっしゃいますか?なるほど、かなりの方がいらっしゃいますね。では、Strandsを知らない方や、まだ探求していない方のために、簡単に説明させていただきます。私のIDEは見えていますか?ズームインしました。素晴らしい。
まず、エージェントを構築するために使用するagentモジュールをインポートします。そして、StrandsからBedrockモデルをインポートしています。繰り返しになりますが、Strandsは他のサードパーティプロバイダーのモデルもサポートしていますが、このデモではBedrockモデルを使用しています。次に、システムプロンプトを定義しています。システムプロンプトは一般的なものです。ここでは、エージェントに、外部のツールやAPIを利用せずに、トレーニング済みのLLMモデルからの データをすべて使用してもらいたいと思っています。一般的なシステムプロンプトで、例えば、「あなたはWaggleです。ペットに優しいペットフード推奨エージェントで、ペットの親が完璧なフードを見つけるのを手伝います」といった感じです。フードを見つけるための アプローチ方法について他の指示を与え、正確にどのように振る舞うべきかについてのガイドラインを与えました。このシステムプロンプトを、エージェントへの職務記述書だと考えてください。つまり、正確に従う必要があることのすべての指示が含まれています。
そして、エージェントインスタンス自体を定義しています。これは非常にシンプルです。agentクラスを開いて、 モデルを定義します。私はBedrock Claude Sonnet 4を使用しています。そして、US East Oneのモデルを使用しています。そして、上で定義した システムプロンプトをこのエージェントに渡しています。それだけです。定義したら、これを使ってエージェントを呼び出すことができます。ここに入力を持つことができます。 このように、Pythonを使ってエージェントを構築するのは簡単です。このデモでは、CLIでエージェントと対話できるように、インタラクティブループを用意しました。 保存します。ここでエージェントを実行してみます。 サンプルの質問をしてみます。おそらくこの中から一つ。はい、直接いくつかの応答を返してくれています。 LLMを呼び出して、事前トレーニング済みのモデルを使用して、応答を返してくれていますよね?しかし、裏で正確に何をしているのかはわかりません。そこで可視性が必要になるわけです。
では、本番環境に移行する前に、もう少し概念を追加しましょう。一つは、 エージェントに事前トレーニング済みのデータを使用させる代わりに、エージェントにリアルタイムでマイクロサービスを呼び出してデータを取得し、それからフードを推奨してもらいたいのです。そのために、HTTP requestというツールをインポートしています。このツールを使えば、エージェントは私のAPIエンドポイントにHTTP呼び出しを行うことができます。そして、Bedrock AgentCore appをインポートしています。これは、エージェント関数をデコレートして、AgentCoreランタイムにデプロイするために使用できます。AgentCoreランタイムに初めて触れる方のために説明すると、これはエージェントをホストし、動的にスケールできる新しいホストです。
そして、プロンプトも同様ですが、ここでは一般的なプロンプトの代わりに、特定の指示を指定しています。まず、すべてのペットが利用可能なこのエンドポイントからペットの詳細を取得してください。そして、すべてのフード、フードデータベースがあるこのエンドポイントからフードの詳細を取得してください。そして、ペットの特性を マッチングし、栄養ニーズを考慮して、各推奨事項について明確な理由を提供してください。そして、応答を返す方法についてのさらなる指示もあります。 それが完了したら、Bedrock AgentCore appを初期化できます。そして、エントリーポイントを追加できます。 以前、ローカルコードを見ていただくと、私たちが行ったのは同期呼び出しだけでした。つまり、エージェントは応答全体を公開するまで待機します。 しかし、リアルタイムで、チャットボットを使用している場合は、データをストリーミングする必要があります。そのため、ここでは非同期関数を使用してデータをストリーミングし、フロントエンドのチャットボットがそれをキャッチしてライブでストリーミングできるようにしています。 さて、コードを修正したので、本番環境にプッシュできます。
では、ここにどうやってオブザーバビリティを追加するのでしょうか？ コードを変更する必要があるのでしょうか？すべてのエージェントに対してコードを変更するのは現実的でしょうか？オブザーバビリティパッケージをメンテナンスするのは面倒ですよね？そこで登場するのが、AWS Distro for OpenTelemetry SDKです。デプロイする前に、このパッケージをrequirementsファイルに追加するだけでいいんです。 つまり、例えばLangChainなどのフレームワークや他のサードパーティがあって、ホストフレームワークがありますよね。今、私はBedrock AgentCoreをホストに使っています。そして、AWS OpenTelemetry Distroを追加するだけです。これが何をするかというと、エージェントがLLMツールやRAGやナレッジベースに呼び出しを行うたびに、モンキーパッチングを行い、呼び出しをインターセプトして、プロンプトやメトリクスなどのテレメトリを抽出し、それをCloudWatchに送り返すんです。
それが完了したら、AgentCoreにさまざまな方法でエージェントを公開できます。最も簡単な方法は、 このAgentCoreスターターキットを提供していますので、スターターキットをインストールして、エージェントを設定し、エントリーポイント、つまりエージェントコードを指定して、公開先の権限を与え、イメージを作成できるリポジトリを指定して、エージェントに名前を付けます。それだけです。つまり、エージェントを設定すると、 Dockerファイルが作成され、CodeBuildパイプラインが開いてCodeBuildパイプラインが実行され、イメージがECRリポジトリにプッシュされ、そしてエージェントがAgentCoreランタイムにデプロイされます。これはカスタマイズすることもできます。スターターキットを使いたくない場合は、独自のDockerファイルを作成し、イメージを作成してECRにプッシュし、API呼び出しでECRリポジトリ名を指定してランタイムにプッシュすればいいんです。
それが完了すると、オブザーバビリティはデフォルトで有効になります。さて、ここまではAgentCoreについてでした。では、EC2やEKS、または他のホストにデプロイしたい場合はどうでしょうか？CloudWatchで観察したい場合はどうでしょうか？ いくつか追加のステップを行う必要があります。AgentCore内では、これらのパラメータがデフォルトで事前設定されていますが、EKSやEC2などの他のホストでは、ADOTに対して、ここがCloudWatchに送信する必要がある場所だと知らせるために、これらの環境変数をエクスポートする必要があります。例えば、CloudWatchにログを送信する必要があるログループを指定し、リージョン、プロトコル、そして使用しているOpenTelemetry Distroを指定します。ここではAWSのものを使用しているので、それを指定してエージェントのオブザーバビリティを有効にする必要があります。これらの追加の環境変数を追加するだけで、それだけです。AgentCoreで行ったのと同じように動作します。ここまでで、AgentCoreのデプロイについて何か質問はありますか？
大丈夫そうですね。では、コンソールに移りましょう。 このデモでは、すでにエージェントをデプロイしてあります。これがペットフードエージェントで、AgentCoreにあります。そして、これが私が話しているアプリケーションです。 PetAdoptionsというもので、すべてのペットを見ることができ、ペットを引き取ることができます。ペットの代金を支払うことができ、 そして引き取ることができ、ペット用のフードを購入することもできます。ここにチャットボットを統合したいと思っていました。お客様がここに来て、エージェントとチャットしてフードのおすすめを得られるようにするためです。ここでチャットを開きます。これが私の新しいWaggle AIです。これと会話してみます。 はい、完璧なフードを見つけるのを手伝うのをとても楽しみにしているようです。ここで質問してみましょう。 私にはMaxという名前の、生後2ヶ月の黒い子犬がいます。何か良いフードを提案してもらえますか？
バックエンドで興味深い判断をいくつか行って、レスポンスを返してくれます。そこでオブザーバビリティが必要になるんです。なぜなら、バックエンドでエージェントがどのような判断を下しているのかを正確に監視する必要があるからです。ここでレスポンスをくれました。 小さなMaxのためのフードを見つけるお手伝いをしますと。まず、在庫の中でMaxを検索していて、それから素晴らしいフードを見つけてくれます。次の行では、データベースで複数の黒い子犬を見つけたと言っています。
エージェントが食べ物を検索して、ビーフとターキーキブル、そしてローチキンバイツといったいくつかのレコメンデーションを提供しています。これら2つの食べ物が私たちのデータベースにあるか見てみましょう。新しいタブで開きますね。はい、ありました。ビーフとターキーキブル、ローチキンバイツ、それからパピートレーニングトリーツがあります。つまり3つの食べ物があって、上位2つをレコメンドしたわけです。子猫用には他の食べ物があり、ウサギ用にも別の食べ物があることがわかります。つまり正常に動作しているということですが、バックエンドでどのように興味深い判断を行って、お客様に適した食べ物を見つけているのか見てみましょう。
CloudWatchダッシュボードでのエージェント動作の可視化とトラブルシューティング
新しいCloudWatchダッシュボードに移動します。これが新しいCloudWatchで、生成AIの可観測性を提供しています。左側には2つのダッシュボードがあります。1つはモデル呼び出し、もう1つはBedrock AgentCoreです。モデル呼び出しについては、Bedrockモデル呼び出しログを有効にする必要があります。これが何をするかというと、Bedrockモデルを使用している場合、すべての生成AIゴールデンシグナルと呼べるもの、つまり呼び出し回数、レイテンシー、トークン数などが得られます。また、各Bedrockモデルの各リクエストの入力と出力も確認できます。
では、ここで特定のリクエストをクリックしてみます。ここに入力が表示されています。これは私のシステムプロンプトです。ユーザー入力も確認できます。食べ物を買いたいと尋ねているのがわかります。モデル呼び出しが正確に何をしているかも確認できます。つまり、すべてのモデル、各リクエストの入力と出力を見ることができます。Bedrock AgentCoreに進むと、ここで複数のプラットフォームでホストされているすべてのエージェントを単一のペインで表示できます。現時点では、過去12時間に呼び出された2つのエージェントがあります。エージェントのリストとそれらがホストされている環境、そして実行されたセッション数、それからトレースが確認できます。エラーやスロットルがあれば、すべてこの単一のペインで確認できます。
また、ランタイムメトリクスも確認できます。これはAgentCoreでホストされているもののみです。ランタイムセッション、呼び出し、消費されたvCPU、そしてメモリも確認できます。ここでエージェントの1つをクリックできます。ペットフードエージェントが私たちがやり取りしたものです。ここをクリックします。これにより特定のエージェントの詳細ビューが表示されます。ここには複数の事前設定されたウィジェットがあります。スパン別のエラーとレイテンシー、その特定のエージェントのセッション数とトレース数です。そして基盤モデルのトークン使用量です。現在、私はClaude Sonnet 4を使用しています。入力と出力のようなトークン使用量の時系列グラフが確認できます。エラーやスロットルがあれば、このペインで確認できます。
さて、セッションに深く掘り下げたい場合は、セッションに移動できます。セッションIDを取得します。私と友人のセッションIDがここにあります。セッションIDでフィルタリングします。12時間分のデータをフィルタリングしているので、少し時間がかかります。はい、できました。特定のセッションIDをクリックすると、すべてのトレースが表示されます。各トレースは1つのインタラクションです。エージェント自体への質問と考えてください。ここでは、2つの質問をしています。1つは「hey Waggle」です。もう1つは「もう1つ質問があります。Maxがいます」です。これが1つのトレースで、これがもう1つのトレースになります。
それでは戻って、ここにあるトレースの1つをクリックしてみましょう。サイドパネルが開いて、トレースメトリクスを確認できます。その特定のトレースにいくつのスパンがあるか、レイテンシーはどのくらいか、平均レイテンシー、そしてトークン数です。エラーがあれば、ここにエラーが表示されます。最も重要なのは、新しいtrajectoryマップです。ここでは、generative AIエージェントによって行われたすべての選択を視覚化して確認できます。例えば、私がWaggle APIを呼び出すと、Bedrock AgentCoreが1回呼び出されました。次にStrands Agentsを呼び出します。3つのループがありました。最初のループでは、ペットを検索しました。これは、覚えていらっしゃると思いますが、システムプロンプトで指示した内容です。私のプロンプトはどこでしたっけ?ほら、ご覧いただけます。最初のプロセスは、このAPIから詳細を取得することです。それがペットを検索するために行ったことです。
次に2番目のループでは、フードの推奨を取得します。3番目のループでは、すべての入力をLLMに送信し、LLMがデータに基づいて推奨を提供します。さて、チャットスパンの1つをクリックすると、会話全体を確認できます。ほら、ご覧ください。まず、システムプロンプトが表示され、私のユーザープロンプトが表示されます。エージェントが何を返したかを確認でき、ターンごとの会話が見られます。次に、Maxについて別の質問をしました。ここにMaxが表示されています。アシスタントメッセージとツールメッセージが確認できます。ツールは私のマイクロサービスを呼び出して、ペット検索結果を取得しました。年齢やURLを含む、私のペットのデータベース全体をJSON形式で提供しました。
次に行うことは、これをユーザーメッセージとしてLLMに入力し、LLMが処理できるようにすることです。これがユーザーメッセージになり、アシスタントはデータベース内のすべての愛らしい黒い子犬を見ることができると言います。さて、子犬を見つけました。今度はフードを見ています。再びツールを呼び出し、マイクロサービスからレスポンスを取得し、再びそれをユーザーメッセージとしてLLMに入力しています。そして、ここで推奨を行っています。このように、CloudWatch observabilityダッシュボードで会話全体を確認できます。お客様が何を見ているかを確認することは非常に重要です。
ここにクイックフィルターがあります。例えば、エラーになっているスパンをフィルタリングしたいとします。現時点では、エラーや高レイテンシーはありませんが、どのホップでユーザーへのレスポンスを返すのに時間がかかっているかを正確に特定できます。最初のホップで時間がかかっているのか、それともツールを呼び出しているときなのか。すべての詳細をここで確認できます。また、各LLM呼び出しについて、ここに入力トークンと出力トークンが表示され、LLMがどれだけのトークンを使用しているかがわかります。そして、予期していない特定の制限を超えた場合にアラームを設定し、アラームをトリガーしてここから調査を行うことができます。
最初のリソースは、他のプラットフォームへのエージェントのデプロイに関するコードサンプルを提供しています。今日はAmazon Bedrock AgentCoreを見ましたが、Amazon EC2、Amazon ECS、Amazon EKSにデプロイしたい場合は、これが最初のリソースです。2番目は、Strands、LangChain、SDKに関する質問に対応しています。これは、さまざまなagenticフレームワークでのobservabilityを探索するための素晴らしいリソースです。3番目と4番目は、generative AI observabilityを始めたい場合のドキュメントとローンチブログです。どうもありがとうございました。アプリケーションでアンケートフィードバックをぜひお寄せください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion