re:Invent 2024: AWSがBedrock AgentsでBlockchain分析と取引を実現
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon Bedrock Agents for blockchain analysis and interaction (BLC404)
この動画では、BlockchainデータをBedrock Agentsを活用して分析・活用する2つのユースケースが紹介されています。1つ目は、BitcoinやEthereumのデータに対して自然言語でクエリを実行できるData Analyst Agentの構築事例です。Amazon AthenaとLambda関数を組み合わせ、SQLに詳しくないユーザーでもBlockchainデータから洞察を得られる仕組みを実現しています。2つ目は、Decentralized Financeアシスタントとして機能するBedrock Agentsの活用事例です。AWS KMSで管理された暗号資産ウォレットを用いて実際にトランザクションを実行でき、Knowledge Baseを活用してセキュリティ脅威からユーザーを保護する機能も備えています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Blockchain分析におけるBedrock Agentsの活用
Anuさん、ありがとうございます。皆様、こんにちは。Blockchainは、Decentralized Financeや国境を越えたマイクロペイメントなど、新しいアプリケーションの可能性を提供しています。しかし、Blockchainの活用には、技術的な面だけでなく、暗号資産ウォレットやプライベートキーの管理、さらには異なるデータ構造によるBlockchainデータの分析など、独特の課題があります。Large Language ModelsとGenerative AIエージェントの登場により、これらの課題に取り組めるようになってきました。それが、本日のトピックです。私はNew Hampshireを拠点とするAWSのSenior Blockchain ArchitectのEmile Baizelです。
本日は2つのユースケースについてお話しします。1つ目はBedrock Agentsを使用したBlockchainデータの分析、2つ目はDecentralized FinanceアシスタントとしてのBedrock Agentsの活用と、それを用いたBlockchain上でのトランザクション実行についてです。まずは、Blockchainデータ分析に関する最初のユースケースについて、同僚のSimonから説明させていただきます。
テキストからSQLへの変換：Blockchain Data Analyst Agentの構築と実装
Emileさん、ありがとうございます。私はAtlanta, Georgiaを拠点とするBlockchain ArchitectのSimon Goldbergです。Emileが申し上げた通り、まずはBlockchain分析のためのBedrock Agentsについてお話しします。私たちはBitcoinとEthereum両方のAWS公開Blockchainデータセットに対してテキストからSQLクエリを実行できるソリューションを構築しました。2022年に、これらのデータセットはオープンデータプログラムの一環として公開され、アナリストはAmazon AthenaやAmazon Redshiftなどのサービスを使用してSQLを実行できるようになりました。これらのデータセットの主な利点の1つは、BitcoinやEthereumなど、複数の異なるBlockchainネットワーク間でデータを集約できることです。ただし、このデータの処理と分析には、データスキーマの包括的な理解と適切なSQLクエリを構築する能力が必要です。Generative AIを使用することで、自然言語によるクエリをサポートし、SQLに詳しくないユーザーでもBlockchainデータから同様のインサイトを得られるようになりました。
テキストからSQLへの変換を行うBedrock Agentの仕組みについて説明しましょう。このユースケースは実にシンプルです。エージェントを実行するには、まず「史上最大のBitcoinトランザクションは何か？」といったプロンプトをチャットボックスに入力します。このプロンプトに基づいて、エージェントはAmazon Athenaを使用してSQLクエリを生成・実行し、フォーマットされた応答をユーザーに返します。
Data Analyst Agentの構築にあたって、私たちは基本的に4つの主要なステップを踏みました。これは再利用可能なデプロイメントパターンだと考えています。最初のステップは、Bedrock Agentを作成し、適切なLarge Language Modelを選択してさまざまなパラメータを設定することです。このユースケースでは、エージェント自体にそれほど多くのコンテキストが埋め込まれていなかったため、Anthropic Claudeモデルを使用しました。エージェントを作成した後、 エージェントの動作をエージェントインストラクション（エージェントに関連付けられたプロンプト）で定義できます。ここにインストラクションの一部を示します：「あなたはAmazon AthenaのBitcoinおよびEthereumデータベース用のSQLクエリを作成する開発者です。Athenaからエラーを受け取った場合は、エラーメッセージを解決するための別のクエリを作成して再実行してください。」
実際のAgentの指示は、この短い抜粋よりもはるかに包括的なものです。このプレゼンテーションの最後に、完全な指示を確認できるオープンソースリポジトリへのQRコードを用意しています。Agentの指示には文字数制限があることがわかりましたが、Agentに確実に望む動作をさせたい場合、Bedrockは追加のコンテキストを提供する高度なプロンプトを提供しています。この高度なプロンプトでは、Agentに組み込まれているオーケストレーションプロンプトを上書きしました。高度なプロンプトにはいくつかの種類がありますが、ここに追加のコンテキストを自由に入れることができます。今回は、BitcoinとEthereumのデータベースの実際のスキーマを組み込みました。例えば、Bitcoinではブロックとトランザクションを表すスキーマがあり、Ethereumには6つの異なるテーブルがあります。Bitcoinにない例として、トークン転送やスマートコントラクトがあります。高度なオーケストレーションとプロンプトを修正した後、Action Groupを作成しました。
Action Groupは基本的に、Agentがバックエンド機能に接続する方法です。この場合、Action Groupは特定のアクションを呼び出すためのAPIを定義していました。SQLクエリを入力として受け取り、それをAction Groupに関連付けられたLambda関数に渡します。Lambdaの実行が完了すると、SQLクエリからのレスポンスがAgentに返され、人間が読みやすい形式にフォーマットされます。
ここでは機能を簡単に説明しました。単純に「このSQLクエリをAmazon Athenaを使用して実行する」と書きました。ユーザーがプロンプトを入力すると、Agentは何をすべきかを理解し、SQLクエリを構築して実行することができ、これは非常に効果的だと考えています。では、このAgentの実際のデモを見てみましょう。
ここではさまざまなプロンプトとそれに対する応答を見ることができます。例えば、過去24時間で最大のBitcoinトランザクションは何か、先週作成されたEthereumコントラクトの数、昨日のUSDC転送の数、今月最大のUSDC転送は何か、といった質問ができます。さらに、今年最も高額なEthereumトランザクションは何かといった興味深い質問もできます。これらのプロンプトそれぞれに対して、Agentはユーザーの意図を理解し、適切なSQLクエリを構築し、それがAmazon Athenaで実行されてAgentに返されます。
このソリューションをどのように構築したのか、アーキテクチャ図を簡単に見てみましょう。上部中央に見えるように、ユーザーは「史上最大のBitcoinトランザクションは何か」といったプロンプトをチャットボックスに入力します。Agentはプロンプトを受け取り、ユーザーの意図を理解します。質問の内容に基づいて、どのブロックチェーンに問い合わせるかを判断します。例えば、スマートコントラクトに関する質問をした場合、Bitcoinにはネイティブのスマートコントラクトサポートがないため、Agentは自動的にEthereumブロックチェーンを利用します。
Bedrockエージェントがユーザーの意図を理解すると、SQLクエリを生成し、それがAction groupに渡されます。このAction groupはシンプルなAWS Lambda関数に関連付けられており、生成されたクエリを入力から解析し、Amazon S3上のAWSパブリックブロックチェーンデータセットに対してAmazon Athenaで実行します。現在はBitcoinとEthereumをサポートしていますが、今週さらに5つの新しいチェーンが追加される予定で、このソリューションをそれらにも拡張できるようになります。エラーが発生した場合、エージェントがエラーメッセージを受け取り、何が問題だったかを理解するエラーハンドリング手法を実装しました。エラーメッセージに基づいて、別のクエリを構築して再試行することができます。これは失敗からの回復に非常に有効なメカニズムであることがわかりました。これを指示の最上位に追加することで、このソリューション全体の機能性が大幅に改善されました。
ここで、テキストからSQLへの変換を行うBedrock エージェントの構築から得られた重要な知見をいくつか紹介します。興味深いことに、LLMは多くの人気のあるトークンやスマートコントラクトについて本来的に認識していることがわかりました。例えば、USDCのようなポピュラーなステーブルコインの名前を入力すると、ユーザーが指定しなくても、エージェントが自動的に関連するスマートコントラクトアドレスを認識します。また、エージェントがBitcoinブロック内の16進数の値を読みやすいテキストに自動的に変換できることも、印象的でした。先ほど触れたエラーハンドリング手法について、もう一度強調しておきたいと思います。これは、ブロックチェーンデータのクエリ時のエラーや例外を処理し、失敗を防ぐための最も効果的な方法であることがわかりました。
最後の知見として、クエリを実行する際には大量のデータをスキャンする必要があり、それに関連するコストが発生します。例えば、Bitcoinの残高を取得する場合、1.15テラバイトのデータをスキャンする必要があります。昨年、私たちはAmazon Managed Blockchain Queryというサービスをローンチしました。これは、ミリ秒単位のレイテンシーでインデックス化されたデータを提供し、100万リクエストあたり7ドルという関連コストで、ユースケースによってはより費用対効果の高いソリューションとなり得ます。それでは、ブロックチェーンと対話するエージェントについて見ていくために、Emilにバトンを渡したいと思います。ありがとうございました、Simon。
DeFiアシスタント：Bedrock Agentsによるブロックチェーン取引の自動化と保護
次は、Bedrockエージェントを使ってブロックチェーンと どのように対話できるかを見ていきましょう。まずは、CoinbaseのCEOであるBrian Armstrongの言葉から始めたいと思います。「LLMはCryptoウォレットを持つべきです。AIエージェントがあなたに代わって仕事を行い、経済活動に参加できるようにしましょう」。私たちはこの言葉からインスピレーションを得て、分散型金融アシスタントとして機能するBedrockエージェントの構築に取り組みました。DeFiを選んだ理由は、ブロックチェーン内で1,000億ドル以上の規模を持ち、継続的に成長している非常に大きなエコシステムだからです。
このDeFiアシスタントで何をしたかったのか？私たちは支援を必要とする3つの領域 に絞り込みました。まず第一に、リサーチの支援です。オンチェーンの分散型金融機会を調査し、オンチェーンから貸出金利を確認し、資産を預けた場合にどれだけ得られるか、それらの資産を借りる場合にどれだけ支払う必要があるかを把握し、取引や投資戦略を提案し、オフチェーンからデータを収集します。オンチェーンとオフチェーンの市場調査を行えることで、取引の意思決定に役立てることができます。
また、私たちはDeFi Assistantに実際に代わりにトレードを行ってほしいと考えています。安全な方法でAssistantに私たちの暗号資産ウォレットを管理させたいのです。取引を実行したいと指示すると、ウォレットの秘密鍵を管理して取引を実行できるようにします。 そして最後に重要なのは、ユーザーを保護することです。分散型金融には多くの脅威が存在し、多くのプロトコルが攻撃を受けています。ユーザーが、その時点でアクティブな脅威にさらされているプロトコルと関わることがないよう確実にしたいと考えています。これから、これら3つの要素それぞれについて、どのようにAgentを構築したのか説明していきます。
まず始めに、このAgentとのやり取りがどのようなものかコンテキストを説明します。 これはStreamlitを使用したテキストベースのインターフェースです。Streamlitを使用している理由は、後ほどのスライドで説明しますが、ユーザー認証が可能だからです。まず研究から始めましょう。左側では、 オンチェーンの現在の貸出金利やUSDCステーブルコインプールの流動性がどれくらいあるかといった質問をしています。このクエリが処理される仕組みは、プロンプトが図の緑色のボックスで示されているAgentに入力され、Agentには貸出金利アクショングループなど、いくつかのアクショングループが装備されています。このアクショングループは、ブロックチェーンに接続してデータを直接クエリできるSDKを備えたLambda関数です。バックエンドでは、EthereumネットワークへのRPCアクセスにAmazon Managed Blockchainを使用しています。
プロンプトとレスポンスを見てみましょう。これらが私たちが尋ねた質問の一部です：現在の貸出金利は？ 返答ではUSDCが7.6%、DAIステーブルコインが 6.02%となっています。プールの流動性について尋ねたところ、この作成時点で15億ドルでした。 借入金利やローン・トゥ・バリュー比率について、健全なポジションを確保できているか確認するなど、取引の判断に役立つ様々な質問ができます。
以上が研究についてです。次は取引に移りましょう。素晴らしい投資機会を見つけて投資したいとします。まず、残高を確認するためにAgentにウォレット内のUSDC残高を尋ねます。回答を得た後、「よし、USDCレンディングマーケットに5ドル分のUSDCを預けたい」と言います。同じAgentですが、今度はWallet Management Groupと呼ばれる別のアクショングループを使用します。このLambda関数がEthereumトランザクションを構築し、KMSに送ってそのトランザクションに署名します。KMSを使用する理由は、そこに私たちのEthereumウォレットを保管しているからです。KMSはEthereumが使用する楕円曲線暗号をネイティブにサポートしています。
例えばKMSがネイティブにサポートしていない署名方式を使用するSolanaのような異なるブロックチェーンをサポートしたい場合や、より大規模で費用対効果の高いソリューションを構築したい場合は、異なるウォレット構造を導入することができます。例えば、AWS Nitro Enclavesを使用する方法があります。これはEC2インスタンス内に作られた機密計算環境で、オペレーターのアクセスからも保護されています。Enclaveの中で秘密鍵を生成してトランザクションに署名しますが、鍵はEnclaveの外に出ることはありません。AWS KMSで鍵を暗号化し、DynamoDBやSecrets Managerのような低コストのストレージに保存します。私たちのソリューションでは、AWS KMSを使用しています。
エージェントがどのようにしてどのユーザーのウォレットを取得するかについて疑問に思われるかもしれません。これは、Session Attributesという機能が重要な役割を果たします。Session Attributesは、エージェントへのすべての呼び出しリクエストに渡されるキーと値のペアで、これらのペアはAction Groupまで伝播します。具体的には、ユーザーがAmazon Cognitoで認証を行う際、このユーザーは特定のWallet IDやAWS KMS Key IDを持っているという情報をCognitoのカスタム属性として設定しています。ユーザーが認証すると、JWTつまりJSON Web Tokenを取得し、これをSession Attributeを通じて渡します。リクエストがAction Groupに到達する頃には、Lambda関数はユーザーが誰で、そのSession Attributesの値が何で、そして重要なことにWallet IDが何であるかを把握しており、どのKMSキーに署名を要求すべきかを知ることができます。
プロンプトの流れを見ていきましょう。「USDCの残高はいくら？」「現在10ドル分のUSDCを保有しています。」そして、 5ドル分のUSDCをUSDCレンディングマーケットに預けたいと伝えます。エージェントが具体的に何をしたいのか確認し、私たちが承認すると、トランザクションの準備に入ると伝えてきます。次に見たいのは、ユーザーの保護とその方法についてです。私たちはAmazon Bedrock Knowledge Baseを導入しました。このKnowledge Baseは、分散型金融プロトコルで報告されているすべての既知のセキュリティ脅威の最新リポジトリです。このデータを継続的にモニタリングし、ダウンロードしてKnowledge Baseに追加しています。エージェントにこのKnowledge Baseを接続し、アクティブなセキュリティ脅威があるかどうかを理解するよう指示を出し、さらにプロトコル上で取引を行う前に、アクティブな脅威がないかを確認し、ある場合は取引を行わないという指示を追加しています。
では、Knowledge Baseにデータをどのように取り込むのでしょうか？右上には、オフチェーンのデータソースがあります。これには、金融ニュースソースから、私たちが連携しているDeFiプロトコルのTelegramやDiscordグループまで、さまざまなものが含まれます。Fargateクラスターがこれらのデータソースを継続的にモニタリングし、その情報をAmazon S3バケットに格納しています。Amazon OpenSearch Serverlessデータベースを使用して、S3に格納したすべてのデータをKnowledge Baseが利用できるベクトル埋め込みに変換しています。これが、オフチェーンデータをKnowledge Baseに取り込む方法です。
ユーザー保護の具体例を見てみましょう。レンディングプロトコルに5ドルを預けようとします。2日前にセキュリティ侵害があったため、預け入れは実行されませんが、必要に応じてこれを上書きすることができます。例えば、それが実際の脅威ではない、あるいはもはやアクティブな脅威ではないことがわかっている場合、さらに詳しい情報を求めることができます。エージェントが詳細情報を提供し、「この問題は認識しているので、続行してください」と指示することができます。このように、ユーザーを保護しながらも、希望する場合は続行できるようにする方法が多数あります。
私が最も好きなAmazonのリーダーシッププリンシプルは「Think Big（大きく考える）」です。なぜなら、目の前の問題だけでなく、その先まで考えることを常に促してくれるからです。今回構築したものを拡張する方法としては、Multi-party Walletsの検討があります。KMSに1つのキーを持つのではなく、キーを3つの異なるシャードに分割し、異なる当事者が異なるシャードを保持して、それらを組み合わせるというアイデアです。また、DeFiを使用せずに、「Simonに5ドル支払って」と言えば、Simonのウォレットアドレスを知っているので送金できるようなPeer-to-peer支払いの実装や、LLM搭載のゲームアシスタントなど、他にもさまざまな可能性があります。
最後に、こちらをご紹介させていただきます。これは、Simonが発表したBlockchainデータの分析に関するブログ記事と、それに関連するGitHubリポジトリです。より詳しく知りたい方は、ぜひご覧ください。それでは、本日は皆様のお時間をいただき、ありがとうございました。モバイルアプリでセッションのアンケートにご協力いただければ幸いです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion