re:Invent 2025: Amazon Bedrock AgentCoreで構築するWeb3自律エージェントの実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Autonomous Web3 agents on AWS (DAT457)
この動画では、Amazon Bedrock AgentCoreを使用したWeb3エージェントの構築方法を、ライブコーディングを通じて解説しています。エージェントには、ブロックチェーンデータとマーケットデータへのアクセス、AgentCore memoryによる長期記憶機能、そして特定タスクに特化した他エージェントの呼び出し機能が実装されています。Strands Agents SDKとDockerベースのデプロイメントを採用し、AgentCore Runtimeのセッション分離機能により、ユーザー間のデータ隔離を実現しています。ブラウザツールを活用してCoinMarketCapから非構造化データを取得し、さらにKMS（Key Management Service）を使用してEthereumトランザクションへの署名とブロードキャストを可能にするエージェント間通信も実装されています。実際のコード例とともに、IAMポリシーの設定、メモリストラテジーの構成、そしてKMS公開鍵からEthereumアドレスへのマッピング方法まで、本番環境に近い実装の詳細が示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Web3エージェント構築のためのコードトーク：セッション概要と要件定義
素晴らしい、水曜日の午後遅くにお越しいただき、本当にありがとうございます。このイベントに5回参加していますが、水曜日になると、参加者の皆さんにとっても、ここで働いている人やプレゼンテーションをする人にとっても、本当に疲れますよね。ですので、お越しいただきありがとうございます。そして、Web3エージェントに関するコードトークへようこそ。今日これから行うのは、技術的なセッションの進行です。ライブコードをお見せして、コードを見ていき、それが何をするのか、なぜ私たちが使用するサービスやプリミティブについてそのような決定を下したのかをお話しします。また、各パーツがどのように組み合わさり、どのように機能するのか、そしてこの方法で物事を行うことの価値は何なのかをデモンストレーションしてお見せします。
最初にいくつか申し上げておきたいことがあります。AgentCoreについて多くお聞きすることになりますが、今週ずっと耳にされてきたことと思います。ですので、私たちがWeb3のフレーバーでそれをどのように使用しているかを共有できることに興奮しています。今日の要点は、AgentCoreのプリミティブの一部を使用して、Web3アシスタントになることができるエージェントを構築する方法です。そして、もちろん、それを独自のユースケースに拡張する方法もあり、それらの機会についてもお話しします。
もう一つ、そのエージェントが何をできるようになるのか、そして進行の流れがどのようなものになるのかについてお話ししたいと思います。これが今日の全体的なアジェンダの一つです。 コードトークですので、先ほど申し上げたように、ライブコードを一緒に見ていき、それについて話し、コードの中で紹介する際に、さまざまなAmazon Bedrock AgentCoreのプリミティブの紹介を行います。しかし、このWeb3エージェントの要件は何でしょうか?私たちは、Web3のお客様、Web3スペースにいるユーザー、Web3愛好家にとって、エージェントを価値あるものにするために必要な基本的なニーズについて考えました。
まず第一に、ブロックチェーンからのコンテキスト、つまりブロックチェーンデータが必要ですが、マーケットデータも必要ですよね?ニュース、センチメント、価格などに興味がある場合です。ですので、ユーザーからのプロンプトに基づいて行動するために必要なデータを取得できるエージェントが欲しいのです。第二に、メモリが必要です。つまり、ユーザーの好みを記憶し、以前の会話や以前の会話からの状態を検索して思い出すことができる必要があります。人についての事実、使用しているチェーン、持っているアドレス、さらには残高などを記憶することです。ですので、私たちのエージェントにはメモリを持たせたい、ステートフルにしたいのです。
そして最後に、特定のタスクに特化した他のエージェントをトリガーまたは呼び出すことができるエージェントも欲しいと考えています。今日は、トランザクションに署名してブロードキャストしたり、チェーン上の特定のアドレスやウォレットの残高を取得したりできるエージェントの参考例をお見せします。それはEthereum上ですよね?ええ、Ethereum上です。そして最後に申し上げたいのは、このエージェントはロボアドバイザーのようなものや、トレードを実行したり、トレードインテントを実行したりすることを意図していないということです。ですので、それを最初に申し上げておきたいと思います。アシスタントとして考えてください。あなたのためにトレードを行うものではありません。
それでは最後に、今からQRコードを画面に表示しますので、実際に一緒に進めていただけます。リポジトリにアクセスできます。今日使用する全てのコードがここにあります。それからJupyter notebookではないんですが、今日進めていく全てのステップが記載されたmarkdownファイルもあります。ですので、もしご自身で実行してみたい、もう少し深く掘り下げてみたいという方は、60分しかありませんので、全てについて詳細にお話しすることはできませんが、ぜひそちらをご利用ください。それでは、David、始めましょう、画面を切り替えてください。
AgentCore Runtimeとセッション分離：セキュリティとアーキテクチャの基礎
はい。ここに表示されているのは、今日使用している公開GitHubリポジトリです。workshopフォルダに切り替えました。ここには基本的にセッション全体の概要、つまり今日予定していることが全て含まれています。実際に見ていただくこともできますし、ここに列挙されている各ステップごとに技術的な説明もあります。Forrest、お願いします。ええ、その通りです。最初の、つまり冒頭で行う準備段階として、Davidが説明する最初のコードは、ウェブ検索が可能で、メモリを採用できる、つまりAgentCore memoryを使用して長期記憶を作成できるベースラインエージェントになります。そのエージェントをAgentCore Runtimeを使ってデプロイします。
AgentCore Runtimeについて最も重要なことの一つとして強調したいのは、明らかにエージェントをデプロイして運用できる環境であることは非常に明確ですが、AgentCore Runtimeについて特に重要だと思うことの一つは、Web3に関連するこのようなユースケースにとって特に重要だと思うのですが、セッション分離です。エージェントセッションを実行する際、セッションIDでエージェントを呼び出すと、分離されたコンピュート、メモリ、ストレージ用のファイルシステムを持つ独自のマイクロVMが作成されます。例えば、
ユーザーがトランザクション履歴を処理して暗号通貨の税金に関する意見を生成するのを支援するエージェントを考えてみてください。トランザクション履歴、XPub公開鍵、アドレスなどの本当に機密性の高い情報をプッシュしている異なるユーザー間でセッションが混在することは望ましくありません。これらすべてのことについて、他のユーザーから分離され、分けられていることを確認したいわけです。ですので、それがBedrock AgentCore runtimeについて強調したいことの一つであり、デプロイメントについて話し始める際に頭の片隅に置いておいていただきたいことです。
アーキテクチャに移りましょうか、David？これが、ここで皆さんと一緒に構築する部分の最終的な状態です。他にもいくつか相互作用するコンポーネントがあります。後ほどお見せできる別のアーキテクチャ図があると思いますが、一般的に言えば、これが今日のセッションの最後に到達する地点です。明らかに、先ほど述べたBedrock AgentCore runtimeを使用していますし、Strands Agents SDKを使用していますが、お好みの他のエージェントフレームワークでも同じようなセットアップを実行できます。Strandsを選びましたが、例えばLangChainのような別のものを選ぶこともできます。また、ロギングのためにobservabilityも活用します。さらに、ブラウザツール、Bedrock Browser Toolを使用して、ブロックエクスプローラーのようなものから必要なデータにアクセスします。それでは、David、最初の作業から始めましょうか。
さて、このセッションは本当にインタラクティブなものにしたいと思っています。ですので、質問がある場合や、特定のことについて深掘りしたい場合は、遠慮なく聞いてください。ここには特定のことについて多くのコンテンツがあります。Forrestが言ったように、Bedrockを使用しますし、メモリ部分も使用します。おそらく他のワークショップでそういったものをすでに見たことがあるでしょう。私たちはそれを使用していますが、実際にはWeb3特有の部分まで到達したいと思っています。ですので、Bedrock AgentCoreの部分にはあまり時間をかけません。メモリがどのように機能するか、フックについても、あまり時間をかけません。最も重要なことは指摘しますが、もし特定のことについてもう少し説明してほしいと感じたら、ぜひ聞いてください。なぜなら、ここではあまり時間がないからです。残り時間は約50分です。そして、その後も質問があれば、私たちは外にいますので、遠慮なく声をかけてください。話しかけてください、つながってください、またはリポジトリを見てください。
Dockerベースのデプロイメント環境構築とStrandsエージェントの初期化
さて、それを踏まえて、 この特定のフォルダ、または私が見せているこの特定のワークショップには、すべてのコードサンプルがここにあります。これらの特定のコードサンプルは、今日私が使用するcodeフォルダにもあります。つまり、基本的にここに見えているフォルダです。 そして、私たちが行うことは、Dockerベースのアプローチを使用することです。つまり、実際に本番環境に非常に近いものです。ですので、構築したいエージェントがあると仮定しています。Dockerビルドプロセスを使用しています。ECRに、基本的にはコンテナリポジトリにプッシュして、そこから実際に取得しています。これが見えるでしょうし、これは実際に、ラッピングツールやブートストラップツールを使用するのではなく、本番環境に非常に近いからです。
さて、また、自分のマシンで進めている場合、IAMポリシーなど、CLIでこれらをデプロイするために必要な特定のポリシーセットがあります。確実に指摘しておきますが、いくつかのBedrockとBedrock AgentCoreの要件が必要ですが、これらのことは実際にreadmeやワークショップファイルにもリストアップされています。さて、最初のモジュールは実際に今 メモリサポート付きのベースStrandsエージェントを作成します。そのために、UV initを使用します。UVは次世代のPythonパッケージマネージャーです。readmeやこの特定のワークショップファイルは、すべてをどのようにセットアップするか、どのように作成するかを説明しています。UV initを実行し、UV addを実行して、Boto3、Python依存関係、Bedrock AgentCore、そしてBoto coreを追加します。画面に表示されているとおりです。UV lockがあり、このファイルがあります。基本的に、codeフォルダはUVプロジェクトとして初期化されています。ですので、今はUVを実行したり、UV runを使用してコマンドを実行できます。つまり、基本的にすべての要件、フォルダ内のすべてのPython依存関係があるということです。
また、仮想環境も作成しました。ですので、UV venvからvenvフォルダがここにあります。実際にそこからソースすることもできます。私たちが行ったことは、UVフォルダ、またはこのフォルダに、後でスクリプトを実行するための基本要件があります。例えば、デプロイメントやエージェント作成などです。ですので、Boto3とPython依存関係がこのフォルダにあり、ここに専用のrequirements.txtがあります。 この特定のrequirements.txtは、基本的にすべての要件、Strandsエージェントのすべての Python要件を指摘しています。 これらのことについてあまり深く入りたくはありません。Strands Agent Core、コア依存関係があります。Playwrightは、これらのブラウザ関連ツールの1つで、Lambdaに必要なもので、ブラウザを使用するときのStrandsエージェントのビルドアウトステップの1つで必要になります。そして、後で別のエージェントを呼び出すためにBoto3を使用しますので、基本的に、エージェント間通信のようなものを行おうとしています。
また、指摘したいのは 別のスタックです。ここで見ている大きな包括的なリポジトリがあります。それはCrypto AI Agentsと呼ばれています。 別の暗号化cryptoエージェントが配置されており、私はすでに事前にデプロイしています。これらの要件、ソース、そしてこれらすべてのものはすべてリポジトリにあります。ですので、すべてがこのリポジトリにありますが、この特定のアカウントで私が行ったことは、Crypto AI Agentをすでに事前にデプロイしたことです。なぜなら、これはもう少し手間がかかるからです。そして、実際に後でそのCrypto AI AgentをStrandsエージェントと統合または呼び出すつもりです。しかし、実際には 最後のビルドアウトステップに到達したときに、それについてより詳しく話します。
長期記憶機能の実装：AgentCoreメモリとメモリストラテジーの活用
それでは、最初に作成するエージェントについてですが、基本的には先ほど申し上げた通り、いくつかのコアとなる依存関係があります。Strands Agentがあり、それからMemory Clientを使用しています。ちょっと待ってください。コアメモリを作成するためなんですが、StrandsやBedrock AgentCoreはメモリをサポートしていて、Web3関連のエージェントを構築する場合、メモリはコア機能となります。なぜなら、いくつかのことを説明する必要があるからです。例えば、何に興味があるのか？特定のコインがあるのか？自分が持っている特定の役割があるのか？といったことを伝える必要があります。そのため、ある種の長期記憶が必要で、この特定の長期記憶は事前にセットアップしています。create_web3_agent_memory.pyというスクリプトがあります。これを実行できますし、ここにはいくつかの異なるメモリストラテジーが定義されていて、後で使用されます。
メモリストラテジーについてもう少し詳しくお話しできます。これを設計して取り組んでいたとき、エージェントメモリをゼロから構築する方法について調査を始めました。つまり、AgentCoreを使わずに自分でセットアップする場合、どのように進めるかということです。オープンソースのツールを使ってメモリを作成し、どこかに生データを置いて、エージェントにそれへのアクセスを与えるのは比較的簡単です。実際にこれを実用的な意味でどのように活用するかについて、もう少し調査を始めたとき、AgentCoreメモリを使ってテストを始めました。これがどのように機能するかについて、いくつかお話しします。AgentCoreメモリには短期記憶があり、これは生データです。基本的に、エージェントによってイベントが作成されると、それらは短期記憶用の短期データストアに生データとして保存されます。
長期記憶を有効にして、要約、以前の状態からのセマンティック検索、ユーザー設定などのメモリストラテジーを持っている場合、非同期の自動プロセスがその生ストレージの短期記憶からイベントを取得し、ベクトル埋め込みを作成して、長期記憶用のベクトルストアに保存します。そのデータの存続期間、つまりデータがどのくらい持続するかを設定できます。確か、最大で1年まで延長できるタイムスケールだったと思います。デフォルトは7日間で、ここではそれを使用しています。本当の価値は、画面に表示されているこの部分、つまり長期記憶用の事前構築されたメモリストラテジーにあると思います。なぜなら、ベクトルストアベースのアプローチを構築するのにかかる複雑さと時間を大幅に削減できるからです。特に、セマンティック検索や過去の会話の要約のようなものに関してはそうです。このエージェントのデモを始めると、以前の会話の一部を覚えているのがわかると思います。まあ、Davidが行った会話ですね。さて、メモリについては以上です。
次のステップですが、これも繰り返しになりますが、ワークショップガイドではこのWeb3エージェントメモリを作成するように求められていて、それがわかると思います。私はすでにファイルをここに持っているので、実際にこれらをコピーしてあります。次に必ず行う必要があるのは、インフラストラクチャ全体に対して、どこにデプロイしたいのか、AWSアカウントIDを伝えることです。デプロイ先のアカウントはすでにセットアップしてあります。
さて、できました。これを自分で実行する場合、基本的にuv run web agent memory.pyを実行する必要があります。これは実際にメモリIDを返します。このメモリIDは非常に重要です。これを覚えておいて、後で使用します。私はすでにこの特定のものを作成しました。このメモリIDは後でまた実際に見ることになりますが、今は私のターミナルの環境変数に入れてあります。
また、メモリ統合の実装を少し速く進めるために、次はmemory.pyファイルを用意します。これは自動的にDockerfileにも追加されます。Memory.pyは基本的に、Strands Agentで使用するヘルパーモジュールです。 Memory.pyには、このクラスの中に、エージェント用に定義したLongTermMemoryHooksプロバイダーがあります。これがコンストラクタです。後でメモリIDを渡すことで、どの特定のメモリストアと通信するかを把握できるようにしています。retrieve user contextという関数があります。 save conversationもあり、基本的にはフックを登録する必要があります。これにより、ユーザー、つまりWeb3アナリストやWeb3の担当者が、 エージェントとやり取りするたびに、エージェントが基本的にトリガーされ、これらのフックがトリガーされて、実際にこの情報を長期メモリに保存しています。
さて、これが基本的にmemory.pyの内容です。ここでも私は メモリファイルにすべてを用意しています。次に、ベースとなるWeb3エージェントを構築するために、Strands Agent streaming memoryというものがあります。ファイルがあり、 この特定のStrands Agentがあります。Strands Agentはすでにご覧になったことがあるかもしれませんし、re:Inventの別のセッションに参加されていれば、おそらくすでに見たことがあるでしょう。もしそうでなければ、簡単に説明します。ノンブロッキングなインタラクションのためにasync IOを使用しています。Strandsからこれらをインポートしています、AgentとToolです。Toolは後でcrypto AIエージェントスタックのツール統合に使用します。そして実際に、Bedrock AgentCore MemoryからMemoryClientをインポートしており、ここに表示されているこの特定のインポートは、基本的に、以前作成したメモリファイルからLongTermMemoryHooksをインポートしている部分です。それ以外は、基本的にすべて標準的なエージェントです。 デモ用に現在ハードコードされたユーザーIDがあります。そして小さなツールを用意しました。これは基本的にget versionで、デプロイメントで何か問題が発生した場合に、どの特定のエージェントと やり取りしているかを把握できるようにするためです。
そして、システムプロンプトがあります。これは基本的に今 Web3ユーザーの要件を指定しています。これについていくつか言及したいことはありますか？ええ、私たちはいくつかの異なるタイプのエージェントを作成してきました。より専門化されたものもあれば、より一般的な性質のものもあります。明らかにこれはより一般的なものですが、システムプロンプトは特定のタスクに対してエージェントを専門化するのに最適な場所の1つだと思います。1時間半ほど前に行ったブロックチェーンデータに関するセッションから、何人か見覚えのある顔があると思います。そこではブロックチェーンデータアナリストエージェントがあり、そのシステムプロンプトでは、ブロックチェーンデータがどのように保存され、クエリされるかについての多くのヒント、ベストプラクティス、パターンを提供しました。そして再びアシスタントについては、このエージェントを段階的にテストする際に、どのプロンプトに基づいてどのツールを使用するか、どのデータを使用するかについて、ここに追加のステアリングを追加する場所です。また、メモリについても、何をメモリに保存すべきで何を保存すべきでないかを決定する際に、エージェントに自律性を与えることもできます。ここにあるのは比較的シンプルです。セッション全体を通じて追加していきます。
繰り返しになりますが、ここはエージェントを大幅にカスタマイズできる場所です。ここの下の方では、フックプロバイダー内にメモリフックが統合されており、現在はget_versionを渡しているだけのツールがあります。
最後になりますが、モデルについては、これを環境変数として提供しています。実際には 次のステップでDockerについて説明しますが、これにはClaude Sonnetを使用しているので、どの推論、どのモデル、どのLLMを 使用しているかを実際に把握できるようにしています。最後になりますが、Strandsにはこのアプリのエントリーポイント、基本的にエージェントの呼び出しがあり、stream agent、stream syncを使用しています。つまり、基本的にはLLMや完全なレスポンスが作成されるのを待たないということです。すべてをストリーミングで返しており、これは今からクライアントで確認できます。インタラクティブなストリーミングクライアントでは、このようなセッションにとってより対話的だと考えました。
また、ここで見ていただけるのは、基本的にこれらはほんの少し、いくつかのデバッグステートメントです。ツールの使用について、モデルの推論について、もっと情報を得たい場合は、実際にこれをアンコメントすることができます。そうすると、モデルが特定のツールについてどのように推論し、これらのものをストリームで返すかを実際に見ることができます。しかし、今日はこれをやりません。なぜなら、それは実際に非常にノイジーになってしまうからです。デバッグには本当に良いのですが、私たちの目的にはあまり適していません。さて、今お見せしたこの特定のエージェントは、strands_agents_streaming_memory.pyに存在しています。まさにここにあります。もうほぼ完了です。
エージェントのビルドとデプロイ：DockerfileからAgentCore Runtimeへ
Strandsエージェントが定義されており、メモリがセットアップされています。先ほど述べたように、メモリについては、これを以前に実行しました。メモリデータベースの作成には数分かかるので、すでにメモリが用意されており、このメモリIDを持っています。後ほどご覧いただけます。さて、すべてをビルドするには、これにはDockerが必要で、実際にDocker PS、Dockerバージョンを見ることができます。Dockerがインストールされていることがわかります。特別な要件はありません。ただ、Dockerベースのビルドを使用しているだけなので、マシンにDockerが必要か、どこかにリモートDockerまたはリモートビルドエンジンが必要です。
では、エージェントをどのように統合し、どのようにデプロイできるか、簡単に見てみましょう。繰り返しになりますが、Dockerを使用しているので、Dockerには何が必要でしょうか？Dockerfileが必要です。ここにDockerfileがリストされています。この場合は非常にシンプルです。Pythonベースイメージを使用しています。requirementsをコピーしてインストールしています。これらは最初に定義したrequirementsなので、基本的にはブラウザ統合を含むStrands agentのrequirementsと、Boto3があるものです。それから、この特定のDockerイメージまたはDockerコンテナにOpenTelemetry distroもインストールしています。これは本当に、運用部分をアプリケーションから分離できるようにするためのものです。ここでやっているのはまさにそれです。
それから、デプロイしたいAWSリージョンを設定しています。inference profileを設定しています。これは、ここでClaude Sonnetに使用しているクロスリージョンinference profileです。これをどうやって確認できるでしょうか？これは実際に米国向けのクロスリージョンです。ご覧いただけますが、エージェントをEUにデプロイしているので、フランクフルトで実行されています。変更は間もなくご覧いただけます。そして最後に、Dockerコンテナに渡しているメモリIDがあります。今日のこれらの多くは、本当にデモ用に最適化されています。基本的にこれが、このようにパラメータを渡しているものです。
さて、ここで私のDockerfileの何が違うのか、簡単に見てみると、US East Oneの代わりに、EU Centralがあることがわかります。USのクロスリージョナルプロファイルの代わりに、EUを使用しています。そして基本的にメモリがすでにそこにあり、後のエージェント用に他のエージェントへのいくつかの参照がありますが、これについては次のステップでお話しします。
さて、このようなDockerやこのようなエージェントを構築するための基本要件は何でしょうか？基本要件は、リポジトリを持っていることです。私はリポジトリを作成しましたが、このコードを実行すると、実際にはECRリポジトリが返されます。そして、基本的にはこれにログインするだけです。
もしこれが速すぎる場合や、実際にどのようにインフラストラクチャを構築しているのか説明が必要な場合は、遠慮なく質問してください。誰かがDockerのアーキテクチャは何かと質問しました。必要なアーキテクチャはARM64です。例えば、AMDを使用している環境でこれを行う場合は、Docker Buildxを使用してクロスプラットフォームビルドを行うことができますが、期待されるのはARM64です。ご覧のとおり、これはまさに私たちがここで行っていることです。ARM64が基本的にターゲットなので、Buildxを使用しています。
Macマシンでは大したことではありませんが、x86システムでこれを行う場合は、何らかのクロスコンパイラが必要です。実際、CloudShellでこれをビルドする場合、アーキテクチャが異なるため、この問題に遭遇します。さて、それでは今から、ここに最新の認証情報があることを確認してから、基本的にBuildxをトリガーして、リポジトリにプッシュアップします。これは基本的にこのコマンドに統合されているすべてです。Docker Buildx buildで、プラットフォームを指定し、そしてご覧のとおり、ここにターゲットリポジトリがあり、それをプッシュしています。さて、認証情報を使って、Dockerが処理しています。できました。
完璧です。これで、Strandsエージェントができ、ECRリポジトリにプッシュしました。さて、もう一つあります。ご存知のとおり、適切なIAMポリシーなしではAWSで何もできません。そのため、デプロイに必要なもう一つのステップがあります。create agent runtime roleがあります。これは、Bedrock AgentCoreに必要なランタイムまたはIAMポリシーです。ここでは、invoke modelが定義されており、ECRパーミッションやこれらすべてのものがあり、これを実行すると、この特定のagent core execution roleが得られます。この特定のワークショップまたはファイルでは、実際に反復的にさらにパーミッションを追加していくので、より多くの機能とともに常に追加のIAMパーミッションを追加し、最小権限ポリシーにも従うようにしています。リポジトリのフォルダに最小権限のIAMロールがあります。
さて、それからdeploy agentもあります。deploy agentは、私がこのために作成した小さなPythonスクリプト、Pythonヘルパーです。これは基本的にBoto3 Bedrock AgentCore controlを使用して、client create agent runtimeと言っているだけです。この特定のclient create agent runtimeは、その後使用する新しいBedrock AgentCoreランタイムを作成します。私たちが行っているのは、その特定のランタイムをECRリポジトリに向けることです。これが私たちのリポジトリなので、そのランタイムは、わかりました、常にこの特定のリポジトリからコンテナをプルしていると認識し、IAMポリシーをそれに渡しています。これがここで見ているもので、role ARNです。基本的には、web searching core execution roleです。デプロイを実行すると、わかりました、AgentCoreランタイムが正常に作成されました、runtime ARNと表示されます。私がそれを作成したので、実際に後でこれに戻りますが、私が代わりに行うのは、createを実行せず、別のスクリプトを実行します。それは実際には、おっと、update agentです。なぜなら、これらのものを事前にデプロイしていたからです。
Bedrock AgentCore環境がない場合は、createを実行するだけです。それ以外の場合はupdateを実行します。さて、今agent runtimeのARNを取得しています。そして、この特定のruntimeのARNをagent runtime環境変数に入れています。これは基本的に、私たちが使用しているAgentCoreのruntimeのARNです。今、invoke agent asyncファイルを使用しています。これも、ここに小さなターミナルがあり、この特定のagentと対話できるストリーミングクライアントです。
このファイルはinvoke agentasyncと呼ばれており、これが実際に私たちのagentと対話するために使用できるものです。そして、この特定のストリーミングターミナルは、基本的に私たちのagentとの対話のためのもので、このagent runtimeをソースとしています。つまり、これによってどの特定のStrandsのagentと通信するかを知っているわけです。それから、この特定のものもあなたのファイルにコピーして、初めてagentと対話してみます。
メモリ機能のデモンストレーション：ユーザー設定の記憶と会話の継続性
これは再びUV run invoke agent asyncです。これは毎回作成しているランダムなセッションIDです。調子はどうですか？agentが応答するか見てみましょう。よし。さて、ご覧のように、プロセスをスピードアップするために少し設定しました。私が名前はDavidだと伝えたことを覚えているようです。やあDavid、以前の会話に基づいて、と言っています。私が暗号関連のことに興味があると伝えました。それを覚えていて、今実際に以前の会話を思い出しています。では、Web3の分野で私について何を知っているでしょうか？見てみましょう。BitcoinとEthereumについて何か知っているようです。
そして今、実際に将来の会話のために、こう伝えることもできます。他に好みはありますか？Solanaです。これが実際に私たちが好みを構築している方法です。さあ、できました。そして今見たように、すでにポートフォリオのフォーカスが更新されています。今後、対話するたびに、Solanaからのすべても返されるようになります。はい、わかりました。使用しているのはそうではなく、それは？いいえ、あなたが言及しているのは基本的に、あなたが言及している別のスタックです。Polygon RPCのデフォルトパラメータがありますが、RPCエンドポイントは更新できます。しかし、RPCエンドポイントは、ブロックチェーン自体と直接対話する場合にのみ必要になります。
例えば、特定のアカウント、アカウントの残高や特定のことを尋ねる場合などです。私たちは今、よりハイレベルなところにいます。まだこれと対話していません。なぜなら、RPCエンドポイントは本当に別のスタック、それが必要とする別のagentだからです。では、ポートフォリオのフォーカスについて、メモリを置く単一の場所がありますか、それとも、これはポートフォリオのフォーカスに関するメモリ、これは出力に含めるべきもの、そしてこちらのこの場所にユーザー情報がある、というように、メモリを複数の種類のフォーカスに分割しているのか、それともすべてを一緒にしてモデルに判断させているのか、どちらですか？
はい、そこにはオプションがあります。組み込みのストラテジーとメモリフックは、基本的には通常、推論を使用して、ユーザーIDとセッションIDの観点から、何を保存する必要があるか、どこに保存する必要があるかを決定します。メモリは名前空間化され暗号化されているので、別々に保持されます。そうでなければ、セッション分離とランタイムレイヤーの目的が損なわれてしまいますからね。しかし、これらのデフォルトストラテジーのデフォルト動作を拡張するカスタムストラテジーを使用するオプションもあります。そこでは、どのタイプのインサイトをどこに、一緒に保存する必要があるかを事前に定義することができます。そして明らかに、これはベクトル埋め込みの観点から長期メモリにおいてさらに役立ちます。
つまり、よりすぐに使える方法か、よりカスタムな方法のどちらかがあるということですね。そしてカスタムメソッドは、基本的に自然言語で、何でも?はい、自然言語で行う方法もありますが、メモリプロバイダーとメモリフックを設定する際に論理的に行う方法もあります。ええ、もちろんです。これらのことはドキュメント化されていますので、後でお会いしてドキュメントをお見せできます。今、区切りの良いところですが、他に何か質問はありますか?ええ、異なる顧客をどのように区別できるのでしょうか?
それは素晴らしい質問ですね。異なる顧客は異なる好みを持っているかもしれません。ある人は一つのことを望み、別の人は別のことを望むかもしれません。まさにその通りです。Davidが簡単にDockerfileを見せたとき、確かそうだったと思いますが、そこでユーザーIDを定義していました。多くのユーザーがいる本番環境のエージェントでは、明らかに動的なユーザーIDを持つことになります。アイデンティティプラットフォームと連携しているかもしれません。例えばOAuthがあり、そこでユーザーIDを持っています。そして開かれる各セッションは、まずユーザーIDをチェックし、それがメモリの名前空間化を行うものになります。つまり、すべてのユーザーのメモリが分離され、その問題が解決されます。各ユーザーは自分自身の好み、自分自身の会話履歴、以前のセッションのリストなどを持ちます。素晴らしい質問です。このデモのために、私たちは簡素化したかったのですが、実際には、本番環境では、全員が異なるユーザーIDを持ち、それがその解決方法になります。
はい、そしてメモリについて、すみません、メモリについての質問をもう一度言っていただけますか?それは良い質問ですね。その答えは分かりません。間違ったことをお伝えしたくないので、メモリが個別にクエリ可能かどうかについては、答えを調べてお伝えします。複数のエージェントからアクセスできることは知っていますが、他のクライアントから直接できるかどうかは分かりません。このエージェントの次のバージョンに進む前に、他に質問はありますか?その上にいくつかの段階的な機能を構築しています。素晴らしい。
ブラウザツールの統合：非構造化データからのマーケット情報取得
さて、David、始める前に一つ。ビルドプロセスとその反復的な性質についても触れておきたいと思います。ビルドプロセスは一般的に同じままです。エージェントのコードを変更し、Dockerイメージをビルドし、ECRにプッシュし、そして新しいエージェントを作成するか、既存のエージェントを更新します。これはCI/CDプロセスなどと本当に互換性があります。Agent Core Runtimeはバージョニングをサポートしているため、このパターンと非常にうまく機能します。名前で既存のエージェントの新しいバージョンを作成すると、そのエージェントのエンドポイントが最新バージョンを指すようになりますが、これについてもコントロールできます。エージェントの複数のバージョンを異なるエンドポイントで分離し始めることができるので、環境を分離できます。開発、ステージング、本番環境をそれぞれ異なるバージョンのエージェントコードで行うことができます。または、それらのエージェントの動作を分岐させ始めて、エンドポイントでも分離することができます。つまり、これについて多くのコントロールができます。デフォルトの動作は明らかにあなたのために処理されます。これは単にエージェント呼び出しエンドポイントを最新バージョンに向けるだけですが、APIまたはコンソールからそれをコントロールできます。
はい、そうですね。では次のイテレーションについてお話ししましょう。今から実際に行うのは、エージェントにブラウザアクセスを使用することです。もし現在の情報をクエリすることになっているエージェントを持ちたい場合、常に方法はあります。例えば、事前定義されたREST APIに行くことができます。市場情報を提供するREST APIはたくさんあります。しかし、多くの情報、センチメント分析、そしてこれらすべてのものを基本的に無料で直接提供する他のウェブページもあります。データは非構造化されています。通常、他のAPIは非常に構造化されています。適切なJSONを提供しますが、それには統合するために多くの作業が必要になります。そこで私たちは、Web3については、ブラウザ関連のものも使ってみようと考えました。
また、プロセスに従うために、先ほど述べたように、常にIAMパーミッションを増やす必要があります。私たちが行うこと、または私が行ったことは、実際にポリシーに対して、Bedrock AgentCore Browserフィーチャーを使用できるようにするスクリプトがあります。これにはブラウザアクセスに必要なすべてのパーミッションが含まれています。この特定のファイルをファイルシステムにコピーして、それを実行します。実行するたびに、AgentCore実行ポリシーが更新されます。ここで少し時間を節約できるように、私は事前にこれを行いました。
今、Strandsエージェントを見ています。ブラウザ使用は基本的にここに追加されています。Playwrightがあり、Bedrock AgentCore Tools Browserクライアントがあります。これは後で見ることになります。コンソールにログインすると、ブラウザセッションが立ち上がっているのも見えるでしょう。それに加えて、Bedrockエージェント、Strandsエージェント用に定義されたツールがあります。このツールはget coin dataと呼ばれています。Playwrightがあり、get coin data with browserというツールがあります。これはこのメソッドを呼び出しています。
このメソッドは、ブラウザセッションを定義する場所です。リージョンとこれらすべての情報をそこに渡しています。リージョンは環境変数から取得されています。基本的に行うことは、このケースではCoinMarketCapを使用したいということです。CoinMarketCapに行って、コイン固有の情報を取得し、それを基本的に処理したいのです。そして基本的にこのデータをLLMで消費し、分析して、それが私たちに良い情報を提供してくれることを期待します。
それが基本的に今ここにあるものです。この特定のファイルを終了します。そして、Strands Agents Memory Browserドットpyファイルがここにあるのが見えるでしょう。今できることは、Dockerのようにファイルで、Dockerfileで今これを行うことができます。なぜならDockerfileはディレクトリ全体、つまりすべてのファイルを含んでいて、私は基本的にDocker内のプロセスに、どの特定のツールまたはどの特定のStrands Agentバージョンを呼び出すかを指示しているだけだからです。だから私はただbrowserとタイプするだけで、それが自動的にスキャンされるのです。
では今からDocker buildxを実行します。基本的に次のバージョンをビルドしているところです。この特定のDockerfileはブラウザ対応のStrands Agentを使用していて、UV run update agentを実行しています。基本的には、Strands Agentの最新のDockerバージョンをプルしているんです。待っている間に、ここで使用しているブラウザツールは、AgentCoreで利用可能なものです。AgentCoreを通じて利用できる組み込みツールなんです。これはヘッドレスブラウザで、さまざまなブラウザタスクを自動化することができます。
ここでは構造化されたAPIセットを使う代わりに、コインデータを取得するために使っています。なぜなら、より広範なデータセットをより簡単に取得できるからです。また、ニュース配信サイトなどから情報を取得して、一般的なセンチメント分析を行うためにも簡単に使えるもので、これを構築する際に実際にテストしました。さて、これが理由で、このような小さなバージョン表示にしていたんです。どのバージョンなのか確認したかったので。この場合、今はメモリとブラウザを持つエージェントになっています。
では、提供してみましょう。そして、私の暗号通貨のマーケットデータを提供してください、と。これで理解してくれるでしょう。ええ、理解してくれます。今、実際にブラウザを使って、これらを理解し、Solana、Ethereum、Bitcoinを使って、データを作成し、そして分析を提供するはずです。素晴らしい。わあ、今日Ethereumで何か起きているようですね。これで、ブラウザや非構造化データと実際にやり取りできるWeb3エージェントができました。
さて、これは基本的にデータ収集側の話です。ブロックチェーン自体と実際にやり取りできるブラウザやエージェントを持つには、もう少し複雑さを追加する必要があります。ああ、すみません、聞き逃しました。実行している呼び出しやすべてのブラウザインタラクションを確認する簡単な方法はありますか?ええ、実際にこれのデバッグフラグを有効にすることができます。これらは私が指摘したものです。有効にはしていませんが、これは、例えば、ここで、これらは実際にどのツールを使うか、いつ何を呼び出すかについての推論を教えてくれます。システムプロンプトで本当に具体的にして、ルーティングを行い、正確に何を呼び出すかを伝える必要がある場合、エージェントにとってこれは本当に重要です。そうしないと、混乱して、この情報を持っているなどと言ってハルシネーションを始める可能性があるからです。これらのデバッグ機能を持つことは、エージェントの意思決定プロセスを理解するために不可欠です。
ですから、ここにこれらのフックを持ち、この情報を呼び出すことは、そのために本当に役立ちます。
さて、残り時間は約15分ですね。ここまでで実装したのは、エージェントがコイン関連のマーケットデータとやり取りできるようになったということです。つまり、暗号資産関連のあらゆるWebページとやり取りできるようになりました。これの素晴らしいところは、これらすべてのデータポイントが取得できるようになったことです。マーケット情報、取引量、センチメント、そしてこれら全てのデータが取得できます。実際に、30個もの異なるRESTエンドポイントに接続したり、Twitterフィードを処理したりといったことをしなくても、これらのページから直接すべてを抽出できるんです。
エージェント間通信の実装：ブロックチェーンとの直接やり取りを可能にする
さて、ここでの最後のステップですが、これは冒頭でやったことですね。このエージェントが特定のタスクに特化した他のエージェントを呼び出せるようにすることです。ここでお見せしたいタスクは、実際にブロックチェーンと直接やり取りできるエージェントに接続することです。つまり、KMSのKey Management Serviceを活用してトランザクションに署名してブロードキャストしたり、あるいは単純にチェーンへのRPCリクエストのような読み取りリクエストを行ったりできるエージェントです。ここに表示されているこの図は、私たちの同僚が構築したアーキテクチャから取ったもので、このワークショップのために、複数のエージェントが連携して何かを実行する様子をお見せできるよう、その上に追加で実装したものです。この中には、ニュースソースのナレッジベース、データアナリストエージェント、そしてツール呼び出しを通じた暗号資産価格APIへのアクセス、そして最後にチェーンに直接アクセスするためのツール呼び出しがありました。では、Davidが後者のチェーンとのやり取りについてお見せします。
はい、それでは、この特定のスタックをご覧ください。これは実際にこのcrypto agents with Bedrockに含まれているCDKです。つまり、CDKでデプロイできますし、RPCエンドポイントのようなブロックチェーン関連のものもいくつかあり、これらは今このスタックに必要なものです。これから実際にこの特定のスタックと統合して、それで何ができるか見ていきます。繰り返しになりますが、重要なのは、事前にデプロイしておいたということです。なぜなら、特にナレッジベースなどがあるため、時間がかかりすぎるからです。また、実際に行ったのはIAMポリシーの更新です。追加の権限が必要だからです。このためにBedrock invoke agentの権限が必要になります。
そして、さて、再びStrandsエージェントを見ています。エージェント間通信のために実際にどのように更新するのか、あるいは他のcryptoスタックとどのように統合できるのか。これはかなり簡単です。ここではBoto3を使用しており、再び独自のツール定義があります。これは本当に単純に呼び出しているだけで、Bedrock agent runtimeクライアントのinvoke agentを実行しています。そしてagent ID、agent alias IDがあり、これは基本的にStrandsエージェントに対して、そのツールを呼び出して使用するよう指示します。そのツールが実際にBedrockエージェントとやり取りすることになります。
繰り返しになりますが、ここにツール定義があり、ここで本当に重要なのはシステムプロンプトも更新して、基本的に適切なルーティングを行うことです。つまり、Bedrockエージェントがあることを伝える必要があり、これは何なのか。例えば、ウォレット操作、送信、残高確認などに関するものはすべて、それに問い合わせてくださいと。この特定の他のスタックにはデータフィードの収集機能もあるので、この特定のエージェントを暗号資産の価格取得などにも使用できます。ここにはいくつかの例があります。例えば、アカウント残高を確認したい場合、これは私が作成したアカウント、Ethereum Sepoliaテストネット上のアカウントについて話していますが、実際にこのツールを呼び出すことになります。
それ以外には、あまり変わっていませんが、ブラウザは削除しました。なぜなら、ここではツールからツールへと移動しているだけだからです。さて、この特定のファイルはagent-to-agentの中、Agent-to-Agent communicationに配置されています。
つまり、ブラウザを使う代わりに、今はAgent-to-Agent communicationを使っているわけです。そして今から、このビルドとアップデートのパイプライン全体を再度トリガーします。以前お話ししたように、そしてDockerfileでご覧いただいたように、Agent IDとAgent Alias IDはすでにDockerfileに入っているので、これは事前設定済みです。
さて、アップデート中です。では、何をしているか見てみましょう。Bedrock Agent Runtimeを呼び出しています。最初のレスポンスまで少し時間がかかります。具体的なバージョンが何だったかも覚えていません。まあ大丈夫です。
この別のスタックには今、KMSキーが関連付けられています。KMSはAmazon Key Management Serviceのことで、KMSを使うとプライベートキーを管理できます。主にキー管理、つまりプライベートキーのためのものです。ここでのKMSの素晴らしい点は、実際にKMSを直接統合できること、あるいはKMSを使ってEVMトランザクションに署名できることです。具体的にはSECP256K1です。つまり、この楕円曲線を使うものすべてに対して、KMSを使用できます。
ああ、Service Unavailable exceptionが出ないとライブデモじゃないですよね。オーケー、もう一度実行して、再度チャットすれば動くと思います。本当にスロットルされているか何かですね。でもまあ、ライブですから。つまり、こういうことは起こり得るわけです。ええ、言ったように、ああ、見てみましょう。オーケー、いや、ほら動きました。
KMSを活用したウォレット管理：Ethereumトランザクションの署名とセキュリティ
では、KMSを使うと、実際にブロックチェーントランザクションに署名することができます。皆さん、例えばEthereumでウォレットがどのように機能するか、あるいはパブリックキーについてご存知でしょうか?Ethereumのようなブロックチェーンでは、アカウントやウォレットは基本的にパブリックアドレスに関連付けられた残高によって識別されるということが重要です。パブリックアドレスは基本的に、特定のプライベートキーとパブリックキーのペアのパブリックキーそのものです。KMSを使用する場合、実際にパブリックキーを抽出することができ、そして少し計算が必要になります。しかし基本的には、例えばEthereumのために、KMSベースのプライベート・パブリックキーペアからパブリックキーを実際に使用することができます。
これが正しい尋ね方なのかどうかさえわかりません。まあ、大丈夫です。では、ここでレスポンスを待っている間に、そうでなければ別の方法を...はい、これがウォレットアドレスです。そして、実際に今から状態で何が起こったかについて詳しく説明しますが、まず最初にアカウントにどれだけの残高があるか確認します。
はい、今他のエージェントとやり取りをしていて、基本的にRPCエンドポイントに接続しています。はい、正しそうですね。しかし、どうやってそれを検証するのでしょうか?この特定のアドレスを取って、ここに行きます。これは、今まで見たことがない方のために説明すると、Sepolia Block Explorerです。そして、このアドレスを入力しています。
そして、どうやら誰かがこの特定のアドレスにいくらかのSepolia testnet ETHを送金したようです。素晴らしいですね。では、これらは実際にどのように機能するのでしょうか?もしこれに興味があれば、基本的にcrypto AI agent supervisorスタックの中に、Lambda関数があります。すべてがindex.pyの中にあり、ここにはいくつかの異なる関数とメソッドがあります。もし興味があれば、私はEthereumでKMSを使用する方法について、特にEIP-155やEIP-4337のような異なる署名標準を使った異なるトランザクションタイプについて、いくつかのブログ記事を書きました。しかし、通常どのようにするか、あるいはまずKMSキーまたはKMSパブリックキーをどのようにマッピングできるかというと、プライベートキーにはアクセスできないからです。KMSは本当に、プライベートキーを作成すると、それはHSMの内部に残り、エクスポートすることはできません。キーをインポートすることはできます。例えば、MetaMaskのキーをKMSにインポートすることはできますが、エクスポートすることはできません。それが基本的な考え方です。完全に管理されたキー管理サービスであり、完全に管理されているということは、バックアップなどすべて、AWSがそれを処理してくれるということです。そしてセキュリティとパーミッションについては、基本的にIAMで行うことです。
さて、先ほど述べたように、KMS上のパブリックキーを例えばEthereum上のパブリックアドレスにマッピングするために、少し計算を行う必要があります。ここにcalc_eth_addressと呼ばれるメソッドがあり、パブリックキーを渡しています。これはバイト、パブリックキーのバイト表現です。そして、HSM内でキーがどのように処理されているかを見ると、通常ASN.1表記のようなものがあるので、基本的にこれらのいくつかをデコードする必要があります。そして、ここにあるのは、実際に、私たちが探している情報は基本的にsubject public keyであり、これがここで起こっていることです。subject ASNキー定義があり、これらはすべてIEEE標準で定義されています。そして実際にパブリックキーを抽出し、少し計算を行っています。バイトを取り、実際には16進数アドレスの最後の40文字だけを取り、そして実際に、計算したこの特定のパブリックキーをチェックサムアドレスに変換することができます。
そしてEthereumのチェックサムアドレスは、基本的に、これをご存知ない方のために説明すると、公開鍵の大文字と小文字、これがチェックサムなんです。これは実際に、Ethereumの公開鍵が、何かを送信したい場合に、これが有効なアドレスかどうか、または何か欠けているものがないかを検証できる方法なんです。そして、はい、これは基本的に今を統合して、私たちのためにすべての機能を提供しているわけです。そしてこれは実際に、このget_wallet_addressを実行する際に重要になります。crypto agentは実際にはKMSでBoto3クライアントをインスタンス化しているだけで、基本的に公開鍵をダウンロードし、その公開鍵は基本的に再計算され、これが私たちの公開鍵アドレスに変換されるわけです。
そして、KMSの公開鍵をEthereumウォレット、またはEthereumアカウント、EOA、externally owned accountにマッピングしているのと同じ方法で、署名についても少し魔法のようなことができるようになります。つまり、KMSを使用してブロックチェーントランザクションの署名を作成できるんです。基本的にやることは、事前に計算して、Ethereum、EVMトランザクションを設定し、ハッシュ値を取得し、このハッシュを基本的にKMSで署名し、それを異なるコンポーネントにデコードします。EVMの場合、通常はR、S、Vになるので、検証される3つの異なるパラメータがあるわけです。そして実際にこれらすべてがカプセル化されている、またはすべてがこのindex.pyに書き込まれています。
さて、そして今これが基本的に私たちにできることは、エージェントから実際にアカウント残高を照会できるということです。また、必要に応じて他のアカウントのアカウント残高を確認することもできますし、ブロックチェーンウォレットから特定の資金を送信するように依頼することもできます。例えば、ETH資金を送信したい相手や他の誰かに送ることができます。それでは、時間になったと思います。私たちがカバーしたかった多くの内容をカバーしましたし、最終的に到達したいと思っていたcrypto agentの機能にたどり着くことができました。お時間をいただき本当にありがとうございます。セッション中に質問できなかったことについて質問がある場合は、ドアのすぐ外にいますので、お気軽に私たちに自己紹介して、質問があればどんなことでもお聞きください。そして改めて、カンファレンスの残りの時間をお楽しみください。そして素晴らしい夜をお過ごしください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion