re:Invent 2025: EventBridgeとBedrock AgentCoreで構築するイベント駆動型AIワークフロー
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Building Intelligent Workflows with Event Driven AI (MAM327)
この動画では、Unicorn Gaming Shopを舞台に、EventBridgeを活用したイベント駆動型アーキテクチャにAIエージェントを組み込む実践的な方法が紹介されています。プロダクトオーナーのMarinと開発者のJeffが、50倍のユーザー成長に対応するため、Amazon Bedrock AgentCoreを使用した2つのパターンを実装します。1つ目はEventBridgeがエージェントをトリガーしてゲーム推薦を行うパターン、2つ目はCloudWatchアラームからエージェントが自律的に問題の深刻度を判断し、自動修復またはエンジニアへのエスカレーションを行うパターンです。デモでは、センチメント分析、メモリ機能、SQLクエリの自動生成、observabilityの実装など、具体的なコードとともに詳細に解説されています。strangler figアーキテクチャパターンを用いたレガシーシステムのモダナイゼーション手法も示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Unicorn Gaming Shopにおける課題設定：50倍の成長への挑戦
本日はお集まりいただきありがとうございます。イベントベースアーキテクチャを使用して全く新しいアプリケーションを構築したり、レガシーアプリケーションをモダナイズすることは、イベントと非同期動作を使用してスケーラビリティを実現し、アプリケーションをモダナイズする効果的な方法です。しかし、ビジネスイベントや特性がそれだけでは不十分であると示している場合、どうなるでしょうか?こちらがMarinで、私はJeffです。次の1時間で、ビジネスのニーズを満たすために、イベントベースアーキテクチャにAIとエージェントをどこに、どのように組み込むかをご紹介します。
まず、私たちの会社であるUnicorn Gaming Shopでのシナリオを設定します。 ここでいくつかの役割を演じます。漫画が私たちに正確には似ていないことをお詫びします。これがライセンスで提供されたものです。ありがとう、Jeff。では私の名前はMarinです。ようこそ、そして私の名前もです。私はアプリケーションプロダクトオーナーです。この会社には新しく入りました。これらのことを行う20年以上の経験があります。基本的にこの会社では、顧客満足度を高めるための新機能を定義することを任されています。主なことは、拡大したいということと、一方では顧客とのやり取りをできるだけ自動化したいということですが、アプリケーションに問題が発生したときにバックエンドのエンジニアを支援したいとも考えています。
問題を解決する必要があるときに、彼らを支援し、プロセスをスピードアップするために、あらゆる種類の問題に対応したいのです。また、解決プロセスの一部を自動化して、最も重要で最も難しい問題だけがバックエンドのエンジニアに届くようにしたいと考えています。そうすれば彼らが介入して問題を解決できます。トラブルシューティングプロセスの応答時間を短縮したいのです。
そして私はJeffです。経験豊富なソフトウェア開発者で、Unicorn Gaming Shopでかなり長い間働いています。長年にわたってイベント駆動アーキテクチャとEventBridgeを使用してそのアプリケーションをモダナイズしてきました。そして、Marinが考案しているGaming Shopアプリケーションの新機能を維持し、構築することを任されています。もちろん、私には新機能がたくさんあります。私はここに新しく来ました。自分を証明する必要があります。そして、この会社のために間違いなく大きなアイデアを持っています。拡大する必要があります。顧客基盤を増やすために拡大する必要があります。
本当に素晴らしいアイデアですね、Marin。これらのいくつかを聞きたいです。本当に大きなアイデアなので、気に入らないものもあるかもしれません。基本的に、 私は会社のために10件の新規契約を獲得しました。それによって実際に今の50倍のユーザー成長をもたらすことになります。Jeffには大変な仕事が待っていると思います。
10倍って言いましたっけ？そして50倍の成長、まさにその通りです。ありがとうございます。彼が私に課したのはかなり大変なタスクですね。このような状況に対処しなければならない時、私がすぐに考えることは、それが引き起こすスケールの問題です。 私が抱えているチームへの過負荷という観点でですね。この動的にスケーリングして成長していくシステム全体で起こっているすべてのことについて、運用上の可視性を確保するのはどうでしょうか？AIを使いたいのですが、私自身もチームも経験が限られていますし、チームも限られている、時間も限られている、予算も限られているんです。
EventBridgeとstrangler figパターンによる既存アーキテクチャ
さて、以前お話ししたように、私はここにあるこのアプリケーションをイベント駆動アーキテクチャとEventBridgeを使ってモダナイズしてきました。EventBridgeは現在システムに持っているアーキテクチャの中核となっています。そしてEventBridgeは本当に3つのことを提供してくれています。1つ目は、ここにあるプロデューサーのいずれかから来るイベントを受け取ります。この場合は私のアプリケーションです。そして、バスがあり、3種類の異なるバスを持つことができます。AWSサービスのAPIと統合するデフォルトバス、システム内の特定のイベントを処理するために使用しているカスタムイベントバス、またはSaaSイベントバスです。そして3つ目がルールで、ルールは入ってきたイベントに何が起こるか、そしてどこに行くかを決定します。
そして、それを strangler figアーキテクチャパターンを使用することと組み合わせてきました。strangler figアーキテクチャパターンとは、ここにレガシーシステムがあり、そのシステムの横に新しい機能を構築しているというものです。ここでEventBridgeを使用してそれを構築しており、以前Marinが考え出したビジネス機能である特定のトランザクションを処理しています。それは、Unicorn Gaming Shopを通じてゲームを購入する顧客と非同期で質問に答えることができるカスタマーアシスタントに、イベントベースのチャット機能を導入するというものです。
そして、それはうまく機能しているのですが、 Marinが言っている50倍のユーザー増加に基づいて、ここで起こる成長の量でそれがどのようにスケールするのか心配しています。
それは私たちのカスタマーサービスアシスタントにとって圧倒的な負荷になるでしょう。そして、これらの新しいことすべてによって生成されるすべてのログで、起こっているすべてのことについて運用上の可観測性をどのように維持すればいいのでしょうか？ 現状のままシステムを使うこともできます。技術的には機能します。サーバーレスで、イベントベースで、そこを流れるすべてのメッセージは非同期です。しかし、それはカスタマーアシスタントまでしかスケールしません。カスタマーアシスタントは、顧客から来る質問に答えるためにリサーチをしなければならず、それは遅いのです。カスタマーアシスタントがここで多くの作業をしているため遅く、彼らは圧倒されてしまうでしょう。
Amazon BedrockとAgentCoreの導入：エージェントによる自律的な意思決定
私は多くのリサーチを行ってきまして、ここでAIを導入して助けてもらえることを学びました。そしてAWSの世界では、AIは本当にAmazon Bedrockと呼ばれるものに集約されます。BedrockはAWSのファーストパーティモデルと、主要プロバイダーのサードパーティモデルの両方へのAPIアクセスを提供するサービスです。私がこれについて気に入っているのは、このAPIレイヤーによって、特定のモデルに縛られることなく自分のシステムに統合できることです。そして、自分のシステムが最終的な顧客に対してどのように答えを提供しているかを学び、時間の経過とともにモデルを変更することができます。また、モデルをファインチューニングして、得られる結果の品質をさらに向上させることもできます。ですので、私が持っている顧客に対して望む結果を本当に引き出し始めるために、これを自分のシステムにどのように組み込むかに非常に興味があります。
そこで私は小さなチャットを構築しました。カスタマーアシスタント向けのリサーチアシスタントチャットです。私のアーキテクチャは依然としてサーバーレスで、依然としてイベントベースで、依然として非同期です。今ではカスタマーサービス、カスタマーアシスタンスの担当者向けに、Bedrockの統合を通じてリサーチ拡張機能がここにあります。そして以前よりも高速になりました。しかし、まだ十分に速くはなく、カスタマーアシスタントまでしかスケールしません。
さらにリサーチを進める中で、エージェントというこのアイデアについてさらに多くの情報を得ました。そしてエージェントについて私が本当に興味をそそられるのは、それらがリクエストを理解し、意思決定を行い、タスクを実行するために自律的に行動できる自律システムであるということです。これは、カスタマーアシスタントを拡張し、私が持っているビジネスにスケールさせる素晴らしい方法のように思えます。そしてエージェントについて考えるとき、それらはいくつかの異なるスタイルで提供されます。まず、部門レベルのタスクを実行するエージェントを考えることができます。これは非常に近いデータを必要とするもので、通常それほど複雑ではなく、おそらくその領域ではセキュリティがそれほど強くないものです。組織エージェントは、私のシステムの境界を越えて、おそらく社内の事業部門の境界を越えて機能します。通常、データへのアクセスが増え、誰が何にアクセスできるかという点でセキュリティが少し重要になり始めます。そして外部エージェントは、私のアプリケーションの境界外、私の会社の境界外で機能し、サードパーティのAPIやサードパーティのデータとやり取りします。そこで何が起こっているかについて、私は絶対に多くのコントロールが必要です。
そしてこれについて考えるとき、この世界でこれらすべてをどのように管理し、どのように実行するかを考えます。そこでAmazon Bedrock AgentCoreの出番となり、それは私に3つのことを提供してくれます。まず、エージェントが必要とするツールとメモリを提供します。メモリは本当に重要です。なぜなら、エージェントでプロトタイピングを行う場合、多くの場合それらは非常に短期的なメモリだからです。つまり、タスクを与えると、それを実行し、完了すると忘れてしまい、後続の質問をすると、最初に行ったすべてをやり直さなければなりません。これを使えば、AgentCoreを通じてそのエージェントにメモリが組み込まれているので、後続の質問をしても、以前にあったことを覚えていて、すべてを連鎖させることができます。次に、エージェントのランタイム環境とアイデンティティ管理を提供するので、誰がそのエージェントにアクセスでき、そのエージェントが何を許可されているかを制御できます。これは私にとって重要です。なぜなら、私が持っているそのエージェントは推奨事項を生成し、大規模なデータセットとやり取りし、外部に応答を返すからです。
そして3つ目は、オブザーバビリティです。システムがスケールするにつれて多くのことが起こり、多くの意思決定が生成されます。ここで発生しているトランザクションから生成されるログへのオブザーバビリティだけでなく、監査と観察ができる必要があります
そのエージェントがどのような意思決定を行ったのかを理解することで、モデルをさらにトレーニングして、今後私が望む方向により沿った意思決定ができるようにすることができます。さて、これらすべてを私のアプリケーションにまとめることを考えると、既存のアプリケーションと、意思決定のためにエージェントをどのように統合・組み込むかについて、ここで私が注目している2つの実際のパターンがあります。ここでEventBridgeとエージェントがすべて一緒になります。
2つの統合パターン：EventBridgeとエージェントの連携によるゲーム推奨機能
まず、最初のパターンはEventBridgeがエージェントをトリガーするものです。このケースでは、イベントが様々なソースから入ってきます。S3かもしれませんし、スケジュールかもしれませんし、Lambdaかもしれません。私の場合は、チャット機能が組み込まれたWebアプリケーションになります。メッセージがイベントとしてEventBridgeに送られ、EventBridgeがBedrockを呼び出して何かを実行させます。私のケースでは、顧客が求めているものに基づいてリサーチを行い、その特定の顧客のニーズに応えられるものについての推奨を提供することになります。
2つ目は、エージェントがトリガーするEventBridgeイベントです。これは最初のものとは逆のようなものです。これはエージェントが何かを実行し、リサーチを行い、意思決定を行い、何かを見て、そしてEventBridge上にイベントを生成するところから始まります。そのイベントはファンアウトパターンのように動作し、このイベントに基づいて何かをしたい人は誰でも、このイベントに基づいて何かを実行できるようになります。これら2つのパターンを組み合わせることで、顧客アシスタントから提供したいゲーム推奨機能を作成するという私の懸念事項、これは本当に最初のパターンになりますが、それをどのように処理するか、そして私のシステムで起こるすべてのことについて、運用上の可観測性とサイトの信頼性をどのように維持するかという点で、大いに役立つことになります。
それでは最初に、エージェントを活用したゲーム推奨についてです。以前のシステムがあり、ここで私が行っているのは、構築したエージェントを導入することです。このエージェントは、イベントから受け取った情報、つまり顧客が「新しいタイプのゲームに興味があります、こういうものが好きです、何を推奨してくれますか?」というチャットをしている情報に基づいて行動します。エージェントはそれを受け取り、リサーチを行う前にまずいくつかのことを行います。エージェントにこの人の感情を判断させることができます。もし彼らがポジティブであったり、あるいは中立的であったりする場合は、おそらく多くの対応は必要ありません。エージェントがオフラインで自分で処理することができます。
しかし、もしかしたらその人が「あなたのゲームはひどい、返金してほしい、ここで起こっていることが気に入らない」と言って電話をかけてくるかもしれません。ここでエージェントに意思決定をさせて、「感情を理解しました、この人はおそらく別の人と話す必要があります、カスタマーサービスエージェントにルーティングします」と言わせることができます。しかし、私たちは良いゲームを作っていますし、そのようなケースは少数のトランザクションになると考えています。ですから、イベントが入ってきたとき、エージェントはまず感情が何か、誰にルーティングすべきかを判断できます。自分で処理すべきだと判断したら、リサーチを行い、情報を収集し、推奨を顧客に提供することができます。
さて、覚えておいてください。これもAgentCoreを使って構築されているため、最初に申し上げた機能であるメモリが備わっています。つまり、ここで一連の会話が行ったり来たりすることができるんです。そしてエージェントは、以前の内容を一貫して記憶し続け、それが知っていることに基づいてすべてのレスポンスを構築していきます。最初に行った作業をやり直す必要がないわけです。一つ目のメリットは、時間の節約になります。二つ目は、コストの節約です。なぜなら、エージェントがすでに分析した内容を再生成するために、より多くのサイクルを消費することがないからです。つまり、これが私が最初のパターン、EventBridgeがエージェントをトリガーするパターンを導入して、顧客向けのゲーム推薦を構築しスケールさせるという問題を解決する方法になるわけです。これで私の問題の一つが解決しました。
SREエージェントによる運用の自動化：CloudWatchアラームからの自律的な問題解決
二つ目の問題はサイト信頼性エンジニアリングです。私のシステムはすべてCloudWatchで計装されていて、スケールが50倍に成長している今、大量のログが生成されています。そして私のエンジニア、覚えていますか、私には限られたチーム、限られた予算しかありません。彼は、その中で何が起こっているかを理解し、調査が必要なものを探し、何か悪い傾向になっているもの、修正が必要なもの、対処が必要なものを見つけなければならず、圧倒されてしまうでしょう。
つまり、CloudWatchログが指数関数的に増加しているんです。このシステムをどれだけ良く構築しても、推測できると思いますが、エラーは発生します。そして時には軽微なものもあれば、重大なものもあります。いずれにせよ、それらは調査される必要があります。
ここでCloudWatchを使用して、システムで誤って発生する可能性のある特定の事象に基づいてCloudWatchアラームを設定できます。これらのCloudWatchアラームに基づいて、何かがアラーム状態になったときに、エージェントを呼び出すことができます。SREエージェントを呼び出せるんです。そのエージェントはいくつかのことができます。まず、その特定のアラームで何が起こっているかを理解できますし、システムのアーキテクチャとその実装も理解しているので、それが何の根本原因である可能性があるかを判断できます。
そして、その深刻度を判断できます。願わくば、私の問題のほとんどは低い深刻度のもので、簡単に修正できる類のものであってほしいですが、中には高い深刻度のものもあるかもしれません。そして最初のパターンと同様に、高い深刻度のものはSNSメッセージとして送信して、エンジニアが受け取るようにするという判断ができます。願わくば、そういったものは少量であってほしいですね。しかし、低い深刻度や中程度の深刻度のものについては、エージェント自身に修正させたいんです。そして、そのための小さな仕組みを構築できるかもしれません。その場合、エージェントは、例えば、どこか別の場所にコードを再デプロイしたり、障害が発生しているサーバーをシャットダウンしたりできるかもしれません。
私のシステムで、以前はエンジニアがやらなければならなかったことを実行できますが、今では完全に自律的に実行できるようになりました。このシステムは、エンジニアに負担をかけることなく、私が望む50倍のボリュームまで非常に大規模にスケールアウトでき、疲れることなく、繰り返し実行してくれます。そこで、この問題を解決するために、エージェントトリガーのEventBridgeパターンを導入する方法をご紹介します。AgentCore上で動作するシステム内のエージェント、そのメモリとランタイムの組み合わせにより、ビジネスニーズを満たすためのスケールと、必要な運用サポートのスケールの両方を実現でき、素晴らしい結果をもたらしています。
デモ第1部：センチメント分析を活用したカスタマーアシスタントエージェント
さて、こういった話を聞くのも素晴らしいですが、これがどのように構築されるのかをデモで見るのはさらに良いですよね。それでは、デモについてはMartinに引き継ぎたいと思います。OK、最初から理解しました。
Jeffが説明したように、そしてご覧いただけるように、これは録画です。これが録画である理由があります。ステージ上ですべてがうまく動作するというデモの神様を信用しなかったので、実際に動作して見せたいものをすべて表示できるように、安全で確実にするために、デモセッションを録画しました。それでは進めていきます。約22分ありますので、これを見ていく間、どうかお付き合いください。
2つのケースをお見せします。Jeffが説明したように、最初のケースは、カスタマーエージェントがお客様をサポートして、プレイしたいと思っている類似のゲームを探したり、すでにプレイしたゲームに似たゲームを提案したり、お客様がエージェントとやり取りできるようにするものです。この場合、AIエージェントがいくつかの提案を行いますが、その上に追加のレイヤーとして、お客様が感情や気持ちを提供できるようになります。何かが好きか嫌いかを伝えることで、エージェントはそれに基づいて提案を言い換え、プレイするゲームの異なるリストを提供できるようになります。
2つ目、2つ目のデモは、より多くのコンポーネントがあるため少し長くなりますが、バックエンドのエンジニアを含むもので、主にコンソールとコードの内容を見ていきます。これはエンジニアがケースをより迅速に解決するのをサポートするものです。ロジックは、繰り返しになりますが説明したとおり、偽のLambdaトリガーによってアラートがトリガーされ、それがEventBridgeに送られます。そしてそのアラートはAgentCoreを経由して進み、問題に関する追加情報を探し、その問題が低、中、高のどの深刻度かを判断します。そして再び問題の感情に基づいて、自動修復に送るか、これはサービスの再起動、何かの開始、何かの停止、コードの実行などですが、あるいは高レベルの問題や課題だと判断した場合は、エンジニアにメールを送信してケースをさらにエスカレーションします。
それでは、一緒に見ていきましょう。さあ、どうでしょうか。これを非表示にできますか?はい、これがプロジェクトのフォルダです。
プロジェクトのフォルダ構造をお見せします。ご覧のように、複数の異なるファイルがあり、これらを使用していきます。インストラクションファイルや他の設定ファイルも含まれています。これらのファイルについては後ほど、何が含まれているかを見ていきます。ここではPython環境をアクティベートしています。なぜならエージェントとの通信にPythonを使用しているからです。また、requirementsをインストールする必要があります。ご覧のように、これらのrequirementsのほとんどは既に満たされています。なぜなら、この環境を以前に実行したことがあるからです。
それでは、アプリケーション自体を実行します。ここで少し止めて説明させてください。このアプリケーションはAWS Amplifyのフロントエンドを実行しており、顧客が対話するためのユーザーインターフェースとして使用されます。ここで申し上げておきたいのは、Amazon Bedrock AgentCoreとAmplifyはローカルで実行されているということです。ローカルで実行されていますが、もちろんどこでも実行できます。この場合は、ローカルで実行されています。ご覧のように、システムはインストラクションファイルを読み込んでいます。インストラクションファイルには、エージェントがどのように振る舞うべきかを理解するためのプロンプトエンジニアリングが含まれています。興味深いことに、後ほど見ていきますが、センチメントに関する追加データも含まれています。具体的には、顧客がシステム内でどのようなタイプのセンチメントを生成しているかを判断する方法です。
それでは、フロントエンドをデプロイしましょう。Amplifyがフロントエンドを起動するはずです。フロントエンドはReactをベースにしていますが、お好きなフレームワークを使用できます。これが私たちのフロントエンドです。特に洗練されているようには見えませんが、デモンストレーションの目的には十分です。私たちのアシスタントはGusと呼ばれています。Gusに話しかけてみましょう。「Hi Gus, how are you?」と尋ねます。彼は私たちのために何ができるかについての情報を返してくれます。今、私は顧客としてエージェントと対話し、自分が好きなものや以前プレイしていたもの、具体的にはどのようなタイプのゲームをプレイしていたかについての情報を与えています。ゆっくりとタイピングしていますし、また意図的にスペルミスも入れて、自然に見えるようにしています。しかし、Gusは非常に賢いので、私が実際に必要としているものや尋ねていることを簡単に認識してくれます。
このクエリはバックエンドのデータベースに送られ、そこでGusが私が実際に尋ねていることを理解するのを助けるために、コード内で使用されているさまざまなツールを見ることができます。お気づきかと思いますが、この反復処理の最初の実行では、Gusは最初は何も見つけられませんでした。最初は理解できなかったのですが、その後、キーワード、データベーステーブルの構造、そして私が質問で言っていることに基づいて再処理を行いました。彼は戻って、コードを再実行し、データベースからその情報を取得するために必要なSQLクエリを再作成し、そして私に推奨事項を提供してくれました。ご覧のように、彼は複数の異なるオプションを提示してくれました。
それでは、彼にセンチメントフィードバックを与えてみます。私はResident Evilが好きではありません。なぜなら私は怖がりやすいので、それは私が楽しめるものではないからです。Resident Evilに似たものを提案しないように彼に伝えたいと思います。ここにもスペルミスがありますが、繰り返しになりますが、Gusは非常に賢いので、そのエラーを簡単に理解してくれるでしょう。ここで、エージェントとの私のインタラクションで何が起こっているかを見ることができます。私が何を尋ねているか、彼がどのようにメモリを準備しているか、そして最後にセンチメント分析が有効になっていることがわかります。興味深いことに、私の最初の質問にはセンチメントがありません。私はただ自分が興味を持っているもの、アドベンチャーゲームやこのタイプのゲームが好きだということを言っているだけです。それに関連するセンチメントはありません。センチメントが出てくるのは、ホラーゲームや怖がりやすいゲームが好きではないと言ったときです。センチメントニュートラルと表示されているのがわかります。ここにはセンチメントがありません。なぜならこれは私の最初の質問だからです。
エージェントはクエリの実行を開始します。興味深いことに、ツールを使用することで、エージェントは私が欲しいものをバックエンドデータベースに問い合わせるために必要なSQLクエリを生成しています。コードの中にSQLクエリは表示されていません。Gusにこれをするように指示するハードコードされたSQLクエリはありません。Gusに何をしてほしいかについての指示があるだけです。クエリに埋め込まれたコードはありません。レコードが見つかりました、ゼロです。クエリが作成されたのがわかります。テーブルからコンソールとジャンルを選択する、などです。レコードが見つかりました、ゼロです。最初は何も見つかりませんでした。
さて、エージェントは反復して、コードを再実行します。アクションやアドベンチャーのような追加のジャンルを追加して、今度は150件のレコードを見つけるためにクエリを再実行します。エージェントは再度実行します。これでは表示するのに十分ではないかもしれないと考えて、最後に追加のクレジットを見つけます。そこではありませんが、次のものにあります。追加のレコードが返されたのがわかります。合計5件です。エージェントは単にレコードを追加するだけでなく、基本的に再度実行してリストを短縮します。ここでセンチメントが作用してきます。Resident Evilのゲームが怖いと言ったとき、このセンチメントがエージェントに提供され、このセンチメントがネガティブまたは悪いものであることを伝えています、私はそう表現します。そのため、エージェントは次回、似たようなゲームを含む結果を私に与えることを避ける必要があります。
コード自体を見ると、これが私が言及した指示であることがわかります。これらの指示の中には、エージェントがどのように振る舞う必要があるか、エージェントが何をする必要があるか、私とどのようにコミュニケーションを取るか、そしてエージェントから必要な情報をどのように返してもらうかについてのガイドラインがあります。下部には、センチメントモニタリングも表示されています。ご覧のように、エージェントは継続的に会話を監視し、それがどのタイプのセンチメントであるかを判断します。良いセンチメントなのか、悪いセンチメントなのか。例えば、私はResident Evilが好きです、もっとそれをください、と言うこともできましたし、私がしたように好きではない、もっとそれをくださらないで、と言うこともできました。
アプリケーションファイル自体は、Pythonコードですが、多くのツールが定義されています。データベースに行って情報を抽出するツール、エージェントが結果を返すSQLクエリを生成するのを助けるツールがあります。また、センチメント生成を助ける他のツールもあります。残念ながら、コード全体を見ていくことはできません。また、ここでは非常に非常に小さく表示されています。先ほど見たように、再び異なる指示があります。いくつかの定義を見てみましょう。これらは基本的にエージェントが私にどのように応答するかを定義しています。繰り返しになりますが、このコードすべての中に、クエリは表示されません。何をする必要があるかを示すSQLクエリはありません。なぜなら、そうするとエージェントベースではなくなるからです。それは単なるSQLクエリになってしまいます。エージェントのエントリーポイントで私が提供したいくつかのキーワードに基づいた。
基本的には、これは呼び出しベースで、完全に非同期です。先ほど申し上げた通り、それがアイデアなんです。何かが起こるのを待つ必要はありません。即座に、双方向で起こる必要があるんです。はい、セッションID、ユーザーIDなどなど。もちろん、これが動作するためには、LLMはAWSで動いている必要があります。ですから、現在このagent coreとAmplifyを実行しているように、LLMをローカルで実行することはできません。ですから、認証情報が必要です。データベースがあるバックエンドと、実際に問い合わせを行うエージェントロジックやLLMへのアクセスが必要になります。
感情分析ですが、ご覧の通り感情を分析できます。何かを入力してエージェント自体とやり取りすると、常に感情を分析します。感情を分析する方法の定義を見ることができます。感情を分析する方法と、EventBridgeに出力する方法です。これをEventBridgeに入れたら、基本的に何でもできます。ただ、このケースでは、作成方法についてのフィードバックをお客様に提供しているだけです。本当にすみません、これはサイレントセッションみたいな感じで、これをやるのは初めてなんです。いつもは質問してくる人たちとのやり取りがあったので、あの赤いやつをつけたエイリアンみたいな皆さんがいるのは変な感じです。
ええ、いいですね。コードは基本的にパターンを示していて、このやり取りを助けるコードで、バックエンドでこれらすべてがどのように機能するかを定義しています。繰り返しになりますが、最も重要なのは、これがEventBridgeの部分で、基本的にすべての情報、感情、信頼度、要約をユーザーに送り返して、その部分を理解してもらうということです。はい、ここで少し止めます。
デモ第2部：アラート駆動型の自律的トラブルシューティングシステム
説明した通り、第2部は第1部の上に構築されています。これで何ができるでしょうか？事前に構築されたエージェントがたくさんありますし、それらを再利用することもできます。これは興味深いです。なぜなら、デプロイがとても簡単だからです。実行して、ローカルでテストして、それからAWSにプッシュして、そこで実行することもできます。ですから、これは基本的に、お客様とバックエンドのエージェント間の非同期通信と、追加データを提供するために既存のLLMを再利用するという概念を証明するコンセプトです。これは非常に簡単なコードで、非常に短く、長くありません。そして、非常に簡単にテストできます。これは、私が質問をプロンプトして、これをください、あれをくださいなどと尋ねるときのユーザーインタラクションです。もちろん、これはすべて、お持ちのすべてのゲームのデータベースのバックエンドに持っている既存の知識に基づいています。
第2部にはもう少し多くのコンポーネントが含まれていて、第2部は、インタラクティブではないと言えます。なぜなら、アイデアは、永続的なウォッチャーまたはアラートベースのシステムを持つことだからです。今回はCloudWatchを通じて、基本的にアラートを生成して、そのアラートをEventBridge経由でAmazon Bedrock AgentCoreに送信し、AgentCoreがそのアラートの感情を判断して、何らかのアクションを実行します。これは完全に自律的なもので、何かを入力して、やり取りして、インタラクションする必要がある第1部とは対照的です。ここではアラート自体があります。ご覧の通り、このケースではアラートが設定されています。本番環境向けではないかもしれませんが、1つのデータポイントを持つ1つのイベントでアラートが発生し、それからEventBridgeにルールがあります。基本的にそれらのアラート、状態の変化を監視していて、そのアラートで何かをするためのAmazon Bedrock AgentCoreのターゲットがあります。では、そのAgentCoreが実際に何をするのか、後で見ていきます。
重要なのは、単にそれを送信しているだけではないということです。アラートがあります。送信していますが、アラートがあるんです。CloudWatch Logsに戻る必要があります。そのアラートに関する追加情報を取得する必要があり、後ほどコードの中で、それを行う追加のツールがあることをご覧いただけます。そしてそれを使って何かを実行します。これがAmazon Bedrock AgentCoreです。ここで少し止めますが、Jeffもこれらのいくつかについて言及していました。このケースではAgent Runtimeを使用していますが、Built-in ToolsやGatewaysなど、他にも利用可能なオプションがあります。最近、このツールのGatewaysについていくつかのアップグレードを行いました。Memoryについても言及されましたし、Identityは非常に重要です。そして後ほどObservabilityも非常に重要であることがわかります。なぜなら、これを野放しにして、実際に何が起こっているのか、何回の呼び出しがあるのか、何かが起こったときにLambdaが何回起動したのかを知らないままにしたくないからです。リソース使用量、コスト使用量、またはコードの最適化のために、それを微調整したいわけです。ですので、この特定のAgentCoreには、現在Agent Runtimeを使用しています。
それでは、アラートについてです。後ほどご覧いただける偽のLambdaがあり、これがいくつかのアラートをトリガーします。繰り返しますが、本番環境で使用するものではなく、デモ目的のためだけのものです。それがEventBridgeに送られます。EventBridgeがそれをAgentCoreに送信します。AgentCoreには指示があります。後ほど指示ファイルをご覧いただけますが、少し異なるもので、これはシンプルな名前ではなく、もっと不吉な名前が付けられています。そしてそれは、ああ、アラートがあるな、と見て、CloudWatchに戻ります。追加情報を収集します。センチメントを判断します。そしてその情報をどうするかを決定します。つまり、これが実際に行っているのは、エンジニアがすべてのイベントに対してそこにいる必要がないようにすることで、基本的に最上位の最優先イベントだけを受け取り、それに対して行動できるようにしているのです。
さて、これが詳細です。ここで一つ注目していただきたいのは、これがVersion 7だということです。これを何度も実行しているので、最後まで来てもう一度実行すると、すべてのファイルを見ていくと、Agent Version 9になると思います。何度も実行しているからです。ですので、もちろんエージェント内にはバージョニングがあります。呼び出しコード自体を見ることができます。このケースでは、Pythonが機密情報を含むいくつかのものをぼかしています。非常に、非常にシンプルなコードです。複数のバージョンがあり、現在は7です。実際にもう一度実行すると9になります。追加情報はエンドポイント自体についてです。もちろん、必要に応じてタグを追加できます。作成日時、ステータスがreadyなど、その他もろもろです。
この部分は非常に重要です：observabilityです。これは絶対に持っておきたいものです。プロセスと内部で実際に何が起こっているかについての洞察を得られるようにしたいのです。もちろん、何かが起こっているときの範囲を変更できます。ここでは4週間に変更していますが、以前に4週間実行したからです。エンドポイントの数、セッション数、トレース、エラー率などを確認できます。この情報を見るには、セッション呼び出し、呼び出しなどを見るには、Bedrockでこれを有効にする必要があります。
基本的にはチェックボックス、スイッチがあり、それをオンにすると呼び出しが有効になります。そして内部に入ると、今その部分に入りますが、Bedrockの中で、基本的にどのタイプの呼び出しをログに記録したいか、そしてその情報をどこに保存したいかを確認できます。Amazon Bedrockに行くと、私の場合は、すでにオンにしているのでオンになっています。settingsに行って、そしてここで少し止めます。止めましたか？いいえ、止めていませんでした。ここで、止めました。
では、これをオンにする必要があります。model invocation loggingです。これをオンにしていないと、そこにデータが表示されません。これは良くないですね。そのデータが必要なんです。どのタイプをログに含めたいですか?私はすべてのtext、image、embedding、そしてvideoを含めました。それをどこに保存したいですか?S3、CloudWatch Logsのみです。今回のイテレーションではCloudWatch Logsに保存します。
CloudWatchに行きましょう。CloudFrontに行って、何がデプロイされたか見てみます。何がデプロイされたかを見るために、これに対してCloudFormationを通じて複数のリソースがデプロイされました。ちょっと止めますね。ロードされたら、これを隠します。隠れないのが嫌なんですよね。さあ。もういいです。
Lambda、EventBridge、そしてAgentCoreがあります。EventBridgeに関してはこれですね。EventBridgeがLambdaを呼び出し、それがAgentCoreと通信して、調査すべきイベントがあることを伝えます。Lambda error generatorは、エラーの偽のジェネレーターで、いくつかエラーを生成するために何回かクリックします。Error alarm自体、agent SNS topicは、エラーのseverityやsentimentが高い場合にエンジニアにメールを送信するために使用されます。それからrole自体と、下部にいくつかのメタデータがあります。
これらすべてには、これらすべてのサービスにアクセスするための適切な権限があります。ですから、これらそれぞれの権限を、アクセスする必要があるものだけにアクセスできるように、本当にスコープを絞ることができます。では、プロジェクトファイルに行きましょう。これはすでに見たものと似ています。すでに見たプロジェクトと似ていますね。requirementsが見えます、instructionsが見えます。instructionsはもちろん異なります。同じものではありません。
このケースでは、アラートを受信したとき、アラートを受信したときに、CloudWatchに戻ってそのアラートに関する追加データを収集し、それに基づいてどのレベルのsentimentかを決定するように、エージェントに指示しています。また、いくつか使用しています。ツールに関する追加情報とアラートに関する追加情報を取得するために、いくつかの異なるツールを使用しているのが見えるでしょう。そしてそれらのツールはコード自体で定義されています。log group name queryを取得したいんです。CloudWatch Insights queryを作成したい、いつ開始したか、いつ終了したか、などなどです。
そして最後に、エージェントに対してリトライするように、少なくとも2回はリトライできる場合はリトライするように指示しているのがわかると思います。つまり、get more information tool、notify high severity problem tool、これらはすべて、エージェントが追加情報を取得し、問題自体のセンチメントを判断した後に使用するツールです。すべてはinstructionsファイルの中にあります。ですから、これをしっかりやればやるほど、より良い結果が得られます。繰り返しになりますが、エラーハンドリングについてです。常にエラーハンドリングを用意しておくべきです。これは最高のものでも最もスマートなものでもありませんが、少なくともツールが、エージェントが何をする必要があるかを知るためにそこにあります。
繰り返しになりますが、これはPythonアプリケーションです。このアプリケーションは基本的に、エージェントが起動されたときにどのように開始するか、どのツールが利用可能か、どのような指示があるか、などを定義しており、すべてをサービスにプリロードします。私はこれにAmazon Bedrock AgentCore Runtimeを使用してきました。これは基本的にバックエンドでコンテナをビルドし、DockerコンテナをECRにデプロイし、その中にエージェントをデプロイして、そのインフラストラクチャを通じて実行します。
ツール自体は、もちろん、ツールがデプロイされたときやエージェントがデプロイされたときにすぐに呼び出されるわけではありません。何かが起こった後に呼び出されます。ですから、これには2つのパートがあると言えるでしょう。最初のパートは、エージェントをどのように開始するか、指示は何か、どのツールが利用可能かということです。2番目のパートは、イベント駆動型で何かが起こったときに、今日一日中話してきたように、それをどう処理するか、そしてどのツールを使用するか適切なクエリを構築するためにということです。これには、ログからデータを収集し、その後基本的に問題の重要度レベルが実際にどのくらいなのかを判断することが含まれます。
これらすべては、エンジニアがまだ見る前に起こります。これはサービスのバックグラウンドで動作しており、それらのアラートをリスニングして、必要なときにトリガーします。これらが私が言及したツールです。センチメント分析のためのツール、問い合わせを生成するためのツール、またはログファイルに関する追加データを取得するためのツールです。なぜなら、単にアラートがあるというだけではセンチメントを判断できないからです。エージェントはセンチメントを判断できません。アラート情報を取得しに戻り、その後基本的にセンチメントと次に何が起こるかを決定する必要があります。ですから、これらのツールにはlog group name、query、start time、end timeといった引数があります。
もちろん、それが起こると、Lambda関数がトリガーされ、エージェントに行って次の可能なステップを決定します。これにはECSサービス、Lambda、RDSなどが含まれる可能性があります。ですから、繰り返しになりますが、メッセージを送信することもできますし、サービスを再起動することもできますし、コードを実行することもできますし、必要なことは何でもできます。もちろん、ここでの質問は、どれだけの自動化を与えたいかということです。途中に誰か、つまり人間を置いて、これを確認し、何か問題があるかを検証する必要があるのか?再起動、リブート、変更、修正、または何かを実行させるためのコマンドを送信している間に、この種のサービスにどれだけの権限を与えたいのか?ということです。
それでは、ターミナルからagent coreをデプロイしているところです。これによりDockerコンテナが生成され、実行されます。アプリケーションのPythonコード内のすべての命令を使用し、基本的にエージェントを実行するために必要なすべてのツールを収集します。先ほど申し上げたように、Lambda関数は2つあります。1つはエラーを生成するためのダミーのLambdaで、上部にあるLambda Error Generatorです。そして2つ目のLambdaは、基本的にEventBridgeとagent core自体の間の仲介役として機能し、それらすべてのツールとその情報へのアクセス方法を定義します。
これは単純なエラージェネレーターで、コンソールに戻ってそれがどのようにトリガーされるか、そして結果を確認する際にいくつかのエラーをトリガーするだけです。申し訳ないのですが、それほど派手なものではありませんが、実際に何が起こるかをお見せします。それでは、Agent Runtimeに戻りましょう。何が起こったか見てみましょう。ご覧のように、Version 9です。つまり、その間にテスト目的で実行された1つのバージョンがあり、それは見ていませんでした。これが現在のVersion 9です。
Lambda functionsに行くと、基本的に話しているこれら2つのLambda関数が表示されます。これはagent coreと通信するためのものです。いや、これはイベントを生成するためのものですね。そうです、テスト用です。これは、私が複数回クリックすると、いくつかの偽のイベントを送信するだけです。
デモの神々に対してエラーが発生することを期待していたので、1つ記録しました。CloudWatchに送信され、CloudWatchでいくつかのイベントが表示されます。その部分を見てみましょう。ご覧のように、いくつかのイベントがLambdaから生成されました。もちろん実際には、これは本番環境で実際に発生したものになります。繰り返しになりますが、トリガーされたアラームが状態を変更しました。状態が変更されると、EventBridgeイベントが作成され、そこから私たちはこれをAgentCoreに送信することを選択しています。これは、AgentCoreがすべての命令とともに重大度などを決定するオプションの1つです。しかし、ここまで来れば、基本的に何でもできます。これが以前のオプションと比較したEventBridgeの美しさです。
ここで再び、2つのイベントが発生しているのが見えます。Lambdaに戻って、もう1つの方、実際にAgentCoreと通信するLambdaです。これには、CloudWatchに戻って問題に関する詳細情報を探すための命令があります。繰り返しになりますが、ここでトリガーされたことがわかります。小さなトリガーですが、そこにあります。これがトリガーされたことがわかります。ログ自体を見てみましょう。これが起こっていることです。ここで少し止めさせてください。ここで実際に何が起こっているかの完全なログを見ることができます。Lambdaエラーで、この中でCloudWatchに戻っていることも確認でき、基本的にこのエラーに関する追加情報を収集し、このエラーの重大度を定義する必要があると指示していることがわかります。
繰り返しになりますが、どこにもクエリはありません。秘密のクエリもありません。クエリ、そしてすべてのクエリは、ログから提供される情報に基づいて、その場で生成されます。最終的には、JSONペイロードになります。ご覧のように、深刻度は高いと判定されました。つまり、この場合、深刻度は高いと判定されました。低、中、高のいずれかになります。繰り返しになりますが、何が低、中、高なのかは私たちが決めます。つまり、低、中、高の場合にどのようなアクションが起こるかを私たちが決めるということです。この場合は高なので、高い深刻度の通知が送信されました。
ここで一旦止めましょう。先ほど申し上げたように、それほど派手な結果ではありませんが、これが私たちのSite Reliability Engineerに送ったものです。これが彼が受け取ったメールです。もっときれいにすることもできます。メールである必要はありません。高い優先度で誰かに割り当てられたチケットシステムに送ることもできますし、その他いろいろな方法があります。しかし、これが基本的なアイデアです。Jeffが説明したように、一般的なアイデアは、イベント駆動型アーキテクチャのほとんどのアプリケーションにすでに存在していた技術を使って、これの一部を非常に簡単な方法で実際に自動化することです。私たちはその上に、既存のLLMを再利用できるような形でいくつかのスマート機能を追加していますが、その上に収集しているログから得られる私たち自身の知識を与え、それを活用してエンジニアの作業を軽減します。もちろん、これらの問題を解決する必要があるエンジニアの作業を軽減し、最終的には顧客とアプリケーションの利益のためになります。
まとめ：イベントベースアーキテクチャとエージェントの統合による拡張性の実現
既存のサービスアプリケーションを強化する可能性と方法について、皆さんに少しでも理解を深めていただけたなら幸いです。すべてをゼロから構築する必要はありません。JeffとI私はこれで締めくくります。ありがとうございました。素晴らしいデモでしたね。うまくいけば、EventBridgeを使用してイベントベースの方法でアーキテクチャを構築することから始め、そのプロセスにagenticエージェントを組み込むことで、以前はビジネス能力を超えていると思われていた特性に対処するためにスケールできることを実証できたと思います。これで、MartinとI私は、私たちが構築したものに満足しています。お客様も満足していますし、エンジニアも満足していますし、カスタマーアシスタントも満足しています。
それでは、本日はお時間をいただきありがとうございました。re:Inventにお越しいただきありがとうございます。もしご質問があれば、もう少しこの辺りにいますので、お気軽にお声がけください。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion