re:Invent 2025: Web3とAIの融合 - ステーブルコインとAIエージェントによる自律決済システム
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Web3 + AI: Agents that mean business (DAT318)
この動画では、AWSのSenior Solutions ArchitectであるArvindとJoshua Smith、CoinbaseのHead of Engineering Coinbase Development PlatformであるEric Rappelが、Web3とデジタル資産決済、特にエージェンティックペイメントについて解説しています。Web3の基礎概念から始まり、AWSがブロックチェーンノード運用のためのAWS Blockchain Node RunnersやAWS Public Blockchain Dataプログラムを提供していることが紹介されます。Ericはステーブルコインを活用したオープンソースペイメントプロトコルx402を説明し、HTTP 402ステータスコードを使用してインターネットネイティブな決済を実現する仕組みを詳述します。x402は現在7000万件のトランザクションを処理し、平均取引額は約80セントという小額決済を可能にしています。JoshuaはAmazon BedrockのAgent Core RuntimeとAgent Core Gatewayを活用し、Nitro EnclavesとCoinbaseのAgentKitを組み合わせて、AIエージェントが自律的に決済を行うアーキテクチャを実装する方法を示します。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
re:Invent 5日目の開幕：Web3とエージェンティックペイメントへの招待
おはようございます。re:Inventの5日目へようこそ。まず、金曜日の朝を私たちと過ごすことを選んでいただいたことに感謝したいと思います。皆さんは非常に情熱的な方々だと思います。金曜日の朝にWeb3、ペイメントプロトコル、デジタルアセット、ペイメント、そしてエージェンティックペイメントについて聞くというのは、それ以外に説明がつきません。私だったらここに来られたかどうか分かりませんが、その好奇心には拍手を送りたいと思います。
感謝の気持ちに加えて、今日は非常にワクワクしています。なぜなら、私たちのお客様であるCoinbaseにもご参加いただき、AWSでのエージェンティックペイメントに関する彼らの取り組みを共有していただけるからです。始める前に、ここにいらっしゃる皆さんの構成について少し理解したいと思います。歩き回って何人かの方とお話ししたのですが、Web3についてバックグラウンドをお持ちの方もいれば、そうでない方もいらっしゃるようでした。会場の構成を理解することで、どれくらいの時間をそれに費やせるかが分かります。
挙手をお願いできますか？実際にWeb3で積極的に開発をされている方はどれくらいいらっしゃいますか？なるほど、非常に少ないですね。それでは、Web3とデジタルアセットについて概要を説明する時間を少し取りたいと思います。そうすれば、これから続くトピックについてより深く理解していただけるでしょう。さて、私の名前はArvindです。このセッションは、AWSのSenior Solutions ArchitectであるJoshua Smith、そしてCoinbaseのHead of Engineering Coinbase Development PlatformであるEric Rappelと共同で発表させていただきます。
では、今日は何についてお話しするのでしょうか？約束通り、まずWeb3の概要をお伝えします。当初の予定よりも少し時間をかけて、Web3とは何か、AWSはそれをどう見ているか、Web3に対する私たちの視点は何か、どのようなワークロードがあるか、これらのワークロードの要件にどう対応しているか、そして今後の計画について、皆さんに基礎を築けるようにしたいと思います。
そこから、デジタルアセットがペイメントに対して何ができるのか、そしてなぜそれが重要なのかという話題に移ります。その後、Ericがステージに上がり、オープンソースのペイメントプロトコルであるx402についてお話しします。そして、Joshが、Ericが先ほどお話ししたx402とAWSの基盤機能を活用して、AWS上でエージェンティックペイメントを実装する方法についてお話しします。よろしいでしょうか？さて、これがこのセッションで期待できる内容です。これはレベル300のセッションです。ですので、好奇心旺盛な方々のために私がこれからお伝えする概要に加えて、コードや実装についても少し深く掘り下げていきます。
AWSにおけるWeb3の視点：暗号通貨を超えた分散化の世界
さて、Web3についてですが、AWSにおけるWeb3とはどのようなものでしょうか？私たちの視点は何でしょうか？私がWeb3と言ったとき、何人の方がすぐに暗号通貨を思い浮かべますか？今度はもっと多くの手が上がりましたね？それには十分な理由があります。暗号通貨は、おそらく過去10年間でWeb3の最も人気のあるユースケースでした。ですから、ブロックチェーンと言ったとき、Web3と言ったとき、人々はすぐに暗号通貨を思い浮かべるのです。
私がここでお伝えしたいのは、私たちのWeb3に対する見方は暗号通貨をはるかに超えているということです。Web3を支える同じ基本原則を活用するユースケースは他にもたくさんあります。暗号通貨はその一つに過ぎません。今日触れる様々な技術を活用した分散型アプリケーションは数多く存在します。
Web3は、現在のインターネットインフラの認識されている欠点に対応して生まれたもので、その中核となる理念は分散化です。Web3ワークロードを運用するためには、様々な分散型技術を組み合わせる必要があります。ブロックチェーンネットワーク、分散型ストレージネットワーク、スマートコントラクト実行のための仮想マシンなどです。実際のユースケースやワークロードについて考えてみると、例えばデジタル資産を実現する場合、単一のワークロードを運用するために、これらの分散型技術の多くを組み合わせることがよくあります。
それが実際にすべてがまとまる仕組みであり、そうする際には多くの選択をする必要があります。そして私たちAWSは、これらのワークロードを構築し、大規模に展開するために必要な規範的なガイダンスを提供するためにここにいます。 Web3製品の構築について考えるとき、分散型技術を使用することは目標ではありません。それは単なる手段に過ぎません。結局のところ、あなたが求めているのは製品を構築することです。
ですから、多くの点で、これらの技術を活用して必要な製品を構築できるように、適切な構成要素を提供することが私たちの責務となります。私たちは、これらのプリミティブ、つまり構成要素を提供するビジネスをしており、それによってあなたがWeb3製品を構築できるようにしています。私たちがあなたのためにWeb3製品を構築するわけではありません。それをしているのはあなたです。私たちがしているのは、これらすべての基盤技術とプリミティブを提供し、あなたがこれらのワークロードを運用できるようにすることです。
しかし、これらすべての分散型テクノロジーを活用してWeb3製品を構築していく際、画面に表示されているような曲がりくねった曲線のようになることが非常によくあります。それは、多くの選択をしなければならず、単一のソリューションをまとめるために活用すべき多くのコンポーネントがあるからです。最も基本的な選択は、まず製品を構築するための適切な基盤を選ぶことです。パブリックチェーンを使うのか、それともパーミッション型チェーンを使うのか？両方を組み合わせて使うのか？どのパブリックプロトコルを選ぶのか？複数の異なるプロトコルを選ぶのか？そしてそうする場合、相互運用性を構築する必要があるのか？
さて、アセットについて話すなら、カストディアルソリューションを提供するのか、それともノンカストディアルソリューションを提供するのか？スマートコントラクトの実行をどのように処理するのか？そこでどのような標準を使用するのか？これらはすべて、皆さんが精通しているかもしれないし、そうでないかもしれないトピックであり、非常に多くの異なる選択をしなければなりません。これらの基礎となるコアコンポーネントを超えたら、次に他の選択をしなければなりません。
ブロックチェーンデータをどのように処理するのか？分析をどのように行うのか？オンチェーンデータもあれば、オフチェーンデータもあります。製品を構築する際に必要な選択をするために、それらすべてをどのようにまとめるのか？ウォレットをどのように構築するのか？自分で構築するのか、それとも購入するのか？そしてもちろん、デジタルアセットビジネスに関わっている場合、発行者になるのか？それを自分で処理するのか、それとも他の誰かを活用してそれを行い、必要な製品の構築に専念して、重労働を取り除くのか？これらは非常に大きな選択です。なぜなら、それらがビジネスがそこからどのように進んでいくかを決定するからです。
AWSのWeb3ソリューション：マネージドサービス、DIYツール、パートナーエコシステム
そして、ここで私たちの出番です。Web3に対して私たちが取ってきたアプローチにより、先ほど見ていただいた曲がりくねった曲線を、画面に表示されている直線にするために最善を尽くしています。そして、私たちは3つの基本的な柱でそれを実現しています：マネージドサービス、DIY Web3ソリューション、そしてWeb3を中心に構築した非常に堅牢なパートナーエコシステムです。まずマネージドサービスから始めましょう。
AWSで独自の製品を構築したい場合、現在私たちが持っているすべてのプリミティブ、すべてのビルディングブロックを活用して、ソリューションを運用可能にすることができます。選択すれば、すべてを自分で行うこともできます。多くの作業が必要ですが、実行可能です。私たちが持っているコアとなるインフラストラクチャ製品のいくつかを活用するだけで、私たちがその構築をお手伝いします。
それでは、インフラストラクチャの観点から、EC2に少し焦点を当てましょう。あちらにはLambdaや他のロゴもありますが、ここではEC2について少しお話しします。先ほどお話しした核となる原則の一つは、分散化です。分散化というのは、クラウド上で実行しないという意味ではありません。権限や意思決定を分散化するという意味です。さて、ブロックチェーンノードをクラウド上で実行することを考えるとき、AWSはデフォルトで特定の保証を提供しています。それは、AWS上で実行されているNitroベースのインスタンス上の顧客コンテンツに対して、オペレーターがアクセスすることはないということです。
ですから、一歩下がって、おそらく分散化について考えるきっかけとなった大きな要因の一つを考えてみてください。それはデータへのアクセス、所有権についてです。そしてAWSでは、EC2インスタンスを立ち上げて実行する場合、デフォルトでAWSのオペレーターがお客様のコンテンツにアクセスする仕組みは一切ありません。つまり、お客様のコンテンツは保護されたままです。これは、ブロックチェーンノードをAWS上で実行すべき最も良い理由の一つと言えるでしょう。
ストレージやセキュリティに関する他のコンポーネントもあります。今、セキュリティについて少し触れておきます。カストディソリューションを構築している場合は、これらのWeb3カストディソリューションに対応するために特別に構築した専門的な機能について検討することを強くお勧めします。AWS Nitro Enclavesは、これらのウォレットソリューションにおけるコンフィデンシャルコンピューティングの基盤となるコンポーネントです。
ウォレットソリューションを構築する際、enclavesを使用している場合、おそらくキーストアを使用して鍵を持ち込み、enclave内で復号化し、トランザクションに署名するために鍵を管理していることでしょう。それを可能にする製品として、AWS KMSやAWS CloudHSMがあります。セッション後にこれについてご質問をお受けすることもできますし、AWS上でそれがどのようなものかを深く掘り下げることもできます。これらの特定のソリューションについて考え始める際に検討すべきコンポーネントと製品をいくつかご紹介しているところです。
マネージドサービスに加えて、DIY型のソリューションも提供しています。これらは本番環境向けではありませんが、すぐに始めるのに役立ちます。AWS Blockchain Node Runnersと呼ばれるものを構築しており、これはオープンソースプロジェクトです。Node Runnersには、いくつかの人気のあるプロトコル向けのブループリントがあり、AWS上で独自のブロックチェーンノードを立ち上げるのに役立ちます。ですから、ノードを自己管理したい場合で、プロバイダーを使用していない場合は、Amazon EC2を直接使用してAWS上でブロックチェーンノードを立ち上げることができ、Node Runnersがそれを支援します。ブループリントを提供しており、Node Runnersには人気のあるプロトコルを追加し続けています。もし皆さんが関心のあるプロトコルがあって、それが私たちのリポジトリに見当たらない場合は、私に話しかけてください、メモを送ってください、そうすれば追加します。
もう一つのソリューションはブロックチェーンウォレットに関するものです。私たちはブロックチェーンウォレットに4年から5年取り組んできましたので、多くの知識と専門性を構築してきました。そしてそのすべてを共有しています。ブロックチェーンウォレットに関するワークショップやブログがありますし、AWSでウォレットを構築する方法についての規範的なガイダンスやアーキテクチャガイダンスも提供しています。
Web3向けに実施しているもう一つの大きなプログラムは、AWS Public Blockchain Dataです。ブロックチェーンのデータセットを無料で提供しています。お客様が求めている、または関心を持っているトップのブロックチェーンプロトコルを選択しています。どのプロトコルを追加し続ける必要があるかを確認するためにアクティビティを監視し、データセットを無料で追加しています。これまで長年にわたってパートナーを通じてこれを実現してきました。2026年に向けて、アプローチに若干の変更を加えます。財団と直接協力して、財団からデータセットを提供していきます。つまり、パートナー製品に依存する必要がなくなります。無料で提供し、AWS Public Blockchain Dataプログラムを通じて利用できるようになります。
それでは、これらのNode Runnersを簡単に見てみましょう。これらのブループリントをご覧になりたい方のために、ここにQRコードがあります。約14から15のプロトコルのサポートを追加しており、来年も追加を続けていきます。また、どれだけ多くのLayer 2が登場しているかも監視していきます。アクティビティと需要がある場所に応じて、ここに追加を続けていきます。これはオープンソースプロジェクトですので、皆さんもぜひ貢献していただければと思います。
現在、画面に表示されているこれらすべてのチェーンに対して、Public Blockchain Dataでサポートを提供しています。一部はよりネイティブに利用でき、一部はパートナーを通じて提供されています。パートナーソリューションもぜひご覧いただくことをお勧めします。なぜなら、独自のデータ分析ソリューションを構築していない場合、パートナーはデータセットを無料で提供していますが、このデータを活用し、彼らの製品ですぐにデータのマイニングを開始できる素晴らしい製品を持っているからです。ですので、オンチェーンデータの扱い方やその作業方法に慣れていない方、会場の中にもそういった方がいらっしゃると思いますが、彼らはすでにその問題を解決しています。パートナーソリューションのいくつかをぜひご覧いただくことを強くお勧めします。最近追加した最新のデータセットはCronosからのものです。より多くのチェーンに対する需要が増えていることを確認していますので、来年中にさらに多くのデータセットを追加することを期待していただければと思います。そして、こちらがそのQRコードです。
ということで、パートナーソリューションについてお話しします。お探しのものが何であれ、ブロックチェーンインフラストラクチャソリューション、ウォレットやカストディソリューション、データや分析ソリューションなど、これらはすべて基盤となる要素です。もっとたくさんあります。ブループリントを開いて見ていくこともできます。もっとたくさんありますが、これらは非常に基盤的なものです。これらのそれぞれについて、AWSで精査し認定した複数のパートナーがソリューションを提供しており、分散型アプリケーションを非常に迅速に立ち上げることができます。なぜなら、すべての基盤となるベースレイヤーを処理してくれるからです。皆さんがやるべきことは、分散型テクノロジー向けに構築したいアプリケーションに集中するだけです。
デジタル資産決済の重要性：従来型ペイメントの課題を解決する新たな可能性
それでは、Web3における主要なユースケースを簡単に見ていきましょう。ここにいくつか挙げていますが、これらに限定されるわけではありません。ただ、現在最も活発な動きが見られる分野としてここに挙げています。トークン化、トレーディング、ペイメント、そしてウォレットです。本日は実際にトークン化とペイメントについて組み合わせてお話しすることになりますので、ここではあまり時間をかけません。しかし、Web3について皆さんに考えていただきたいこととして残しておきたいのは、現在出現し始めている最大のトレンドの一つが、デジタル資産、証券のトークン化、さらには通貨のトークン化、そしてステーブルコインを中心としたものだということです。
しかし、これらすべては、提供されているものを実際に活用するための下流のユースケースがなければ意味がありません。そして、それこそがペイメントが本当に重要になってくるところなのです。つまり、一方をイネーブラーとして、もう一方を、今後より主流になっていく実際のユーティリティとして考えていただければと思います。
こちらはトークン化ソリューションがどのようなものかを詳しく見たものです。慌てないでください、このソリューションを一つ一つ説明するつもりはありません。ここで注目していただきたいのは、エンドツーエンドのトークン化ソリューションを見て、それを構成要素に分解していくと、AWSではこれらの構成要素それぞれに対応する製品と機能をすべて持っていることがすぐにわかるということです。そして、この構成要素を簡単にマッピングして、パートナーがここでどのように関わるか、誰がトークン化エンジンを提供するか、誰がウォレットを提供できるか、誰がカストディソリューションを提供できるかをお見せすることもできます。ですので、ここから持ち帰っていただきたい高レベルのアイデアは、もしご希望であれば独自に立ち上げるお手伝いができるだけでなく、パートナーと一緒に始めるお手伝いも同様にできるということです。つまり、構築するか購入するかのご意向に応じて、AWSにマッピングすることもパートナーにマッピングすることもできるブループリントとして考えていただければと思います。
それでは、私たちのエコシステムを形作っているWeb3のトレンドを見ていきましょう。ここにいくつか異なる項目を挙げていますが、本当に注目していただきたいのは二つです。それが本日フォーカスする内容です。多くの機関や政府による採用が始まっており、それが規制の明確化につながっています。ですので、GENIUS Actに詳しい方、Clarity自体に詳しい方であれば、ステーブルコインが複数の異なるユースケースに活用できるデジタル資産として、より受け入れられ始めていることをご存知でしょうし、政府からもこれについてより情報に基づいた言葉が出てきています。ですので、お客様から多くの声を聞いていますが、先ほど申し上げたように、ステーブルコインを発行することは一つのことですが、実際にそれを使用することが重要なのです。それこそが本当にすべての人にもたらすものであり、そこでペイメントが登場するのです。ステーブルコインとペイメント、私たちはこれを一つのトレンドとして一緒に見ており、本日はEricとJoshから、デジタル資産で何ができるのか、どのようにペイメントソリューションを構築できるのかについてお話しいただきます。そして次の疑問が出てきます。なぜこれが重要なのか？すでに通貨はあります。すでにペイメントソリューションもあります。なぜこれらすべてが重要なのでしょうか？
重要なのは、既存の従来のペイメントソリューション、現在のペイメントソリューションには課題があるからです。処理手数料が非常に高いのです。決済の遅延が長くあります。対処しなければならない通貨の変動があります。ある国から別の国へお金を移動しようとする場合に発生する複雑なクロスボーダー取引があります。そして最後に、多くの仲介者が存在します。一歩下がって反対側から見てみましょう。処理手数料が本当に高い場合、小額の取引を行うことは非常に困難です。デジタル資産ペイメントは、必要なインフラが少なく、不正管理コストが低く、コンプライアンスが自動化されているため、実際にコストを削減します。これらすべてが実際にコストを削減し、大きなメリットをもたらします。それがマイクロペイメントです。より少額の支払いができるようになります。より多くの取引を行うことができるのです。
再び、決済の遅延についてです。例えば月曜日に取引しようとする場合、前の週の木曜日に送金を確実に行って、使えるようにお金を準備しておく必要があります。もしあなたが中小企業で、3つか4つの取引の遅延に対処しなければならない場合、それは本当にキャッシュフローに影響を与えます。デジタル資産は数分で決済され、キャッシュフローを改善し、応答時間を改善します。為替変動についても同様です。これについて詳しく説明する必要はないと思います。為替変動に対処しながらお金の決済を待っている場合、為替が変動していれば1パーセントポイントか2パーセントポイント損失する可能性があります。
そして仲介業者です。仲介業者を排除する、あるいは仲介業者を減らすことができれば、より速くなるだけでなく、より安くなりますが、さらに重要なのは、カウンターパーティリスクを削減できることです。ですから、デジタル資産決済がより主流になっていく理由を後押しする多くの利点があるのです。最後に一つ申し上げたいのは、これによって銀行口座を持たない人々に銀行サービスを提供できるということです。今日、世界には実際の銀行システムにアクセスできない12億人以上の人々がいます。これは彼らに銀行サービスをもたらします。これはピアツーピア取引をもたらします。これは彼らができることをもっと多くもたらします。
Coinbase Developer Platformとステーブルコインの可能性
それでは、Ericを招いて、x402ペイメントプロトコルとそれがどのようにデジタル資産決済を可能にするかについてお話ししていただきます。ご清聴ありがとうございました。ありがとう、Ivan。ここに来られて本当に興奮しています。サイレントディスコのトークは初めてなので、もし会場にいて私の声がよく聞こえない場合は、ヘッドフォンを試してみてください。
私はEricです。Coinbase Developer Platformのエンジニアリングを率いています。CDPは、いわばAWSがAmazonにとってのような存在です。CDPはCoinbaseにとってそういう存在です。Amazonはクラウドインフラストラクチャの構築における専門知識をすべて活用し、それを何百万ものビジネスが活用して使用できるようにしました。CDPはCoinbaseのインフラストラクチャ、つまり資産の保管、決済インフラストラクチャ、ブロックチェーンインフラストラクチャ、ウォレット、オーケストレーション、トレーディングなどについて同じことを行ってきました。
スライドには私たちが行っている多くのことがありますが、ここにないものもたくさんあります。もし決済やステーブルコインやサービスとしてのトレーディングについて話したい場合は、この後私に話しかけてください。しかし、私たちは素晴らしいウォレットも持っています。データプロダクトへの素晴らしいアクセスも持っています。ノードやステーキング、そして暗号エコシステムへのオンランピングとオフランピングもあります。しかし、今日ここでCDPについて話すために来たわけではありません。私はエージェント決済と、私たちが取り組んできたx402と呼ばれるプロジェクトについて話すためにここに来ました。
Coinbaseでは広く、ステーブルコインはAIにとって極めて魅力的な技術的ソリューションであると考えています。挙手をお願いしたいのですが、会場の皆さんの中でステーブルコインが何かご存知の方はいらっしゃいますか?おそらく70%くらいの方でしょうか。では認識を合わせるために説明しますと、ステーブルコインとはブロックチェーン上に存在するトークンで、何らかの法定資産に1対1でペッグされているものです。この会場にいる皆さんが最も耳にしたことがあるであろうものはUSDCです。USDCはCircleとCoinbaseがパートナーシップで立ち上げたステーブルコインです。米国債と銀行口座のドルの組み合わせによって1対1で裏付けられており、完全に監査されています。
CircleとCoinbaseは現在どちらも上場企業です。文字通り、USDCを裏付けているすべての国債のシリアル番号を確認することができ、1対1で裏付けられていることを確実に知ることができます。つまり、1USDCを保有していれば、銀行口座に1ドルを引き出すことができるのです。なぜステーブルコインはエージェントにとって本当に優れているのでしょうか?まあ、取引コスト、決済のスピードなど、これから説明するいくつかの要因があります。しかし、決済に取り組む際に直面する、より根本的な問題があります。それは、決済のためのオープンスタンダードが存在しないということです。では、定義をお話ししましょう。
インターネットネイティブな決済の必要性：x402プロトコル誕生の背景
インターネットはおよそ35年近く存在していますが、決済のための標準がないのです。もし私がこの点について本当に、本当に深く掘り下げてほしいということであれば、水曜日にFSIトラックで、基本的に標準とそれが重要である理由を分解した講演を行いましたので、ぜひその録画をチェックしていただくことをお勧めします。しかし、私がインターネットネイティブな決済についてどう考えているか、定義させてください。私はインターネットネイティブな決済を、コンピューターがプログラム的に決済を交換する方法であり、標準的かつ中立的な方法で、インターネットが構築されている既存のクライアント・サーバーパラダイムの中で、そして人間がループに入ることを必要とせずに行われるものと定義します。
では、標準的かつ中立的とはどういう意味でしょうか?それは、クライアントとサーバー間のすべてのインタラクションが同じであるべきだということです。私たちは訪問するウェブサイトごとに異なるブラウザをダウンロードしたりしません。インターネットが機能するのは、Googleが公開しているブラウザがAmazonが公開しているウェブサイトにアクセスでき、そのデータを送信するための合意された標準的な方法があるからです。その標準とは、HTML、CSS、インタラクションのためのJavaScriptなどです。
中立的というのは、特定の決済プロセッサーやブロックチェーン、決済メカニズムに偏らないということです。インターネットネイティブな標準の中で表現されたいと考えるあらゆるメカニズムは、ゲートキーピングなしに、その標準の中で自分たちの決済フローを表現できる必要があります。そして既存のクライアント・サーバーパラダイムの中でということですが、以前に決済APIを統合したことがある方なら、おそらくお気づきだと思いますが、ある時点でクライアントは通常、他の誰かに呼び出しを行うか、webhookがあるか、クライアントがサーバーに直接行っているリクエストの外側に存在する何らかのコンポーネントがあります。
そして、人間をループに入れる必要なく実現できます。これまでインターネット上で発生したほぼすべての支払いは、人間がウェブサイトにクレジットカードを入力することの下流で行われてきました。ですから、もし私たちがエージェントの時代に入っていくと信じるなら、そのパラダイムから抜け出す必要があります。そして、インターネットネイティブな支払いメカニズムが必要だというこのアイデアの名残を、80年代や90年代まで遡って見ることができます。
1997年に公開されたと思いますが、HTTP 1.1標準では、HTTPステータスコード、ステータスコード402が、このリソースにアクセスするには支払いが必要であることを表すために、将来の使用のために予約されていました。
実際、Netscapeの共同創設者であるMarc Andreessenは、インターネット上で支払いを機能させるために多くの時間を費やしましたが、技術がまだそこまで到達していませんでした。私たちが今、技術が整っていると考える理由の一つは、ステーブルコインの台頭です。5年前、2020年には、ステーブルコインを送るのに約10ドルかかっていました。しかし、世界がAIやその他多くのことに注目している間に、ブロックチェーンは非常に優れたものになりました。今では、ステーブルコインを送るのに通常0.1セント未満のコストで済みます。それが1ドルであろうと100万ドルであろうと関係ありません。しかし、そのお金を送るためのオンチェーンでの実際のコストは0.1セントであり、パーセンテージベースの手数料はありません。あなたが支払っているのは、純粋にあなたのトランザクションが利用しているブロックチェーン上のリソースに対してだけです。
これは期待を裏切るものです。直感に反しています。ほとんどの人は30セントの手数料と3%の手数料があることに慣れていますが、ブロックチェーンでは、実際に利用しているブロックチェーンの処理能力に対して支払っているのです。ですから、ブロックチェーンがスケールし、より多くのスループットを実現し、より速く決済できるようになると、それらの直接的な利益を支払いに還元できるのです。AIは、インターネットネイティブな支払いを本当に再評価することを私たちに迫っています。AIは今や毎日何億人もの人々に使われていますが、彼らが実行している経済取引の数は信じられないほど少ないのです。その理由の一つは、AIエージェントは基本的にコンピュータ上で実行されるプログラムだからです。
皆さんの中でAIエージェントを書いたことがある方はどれくらいいらっしゃいますか。AIエージェントを書いたことがある方は挙手をお願いします。おそらく3分の1くらいの方ですね。AIを構築し始めたいと思ったときに、すぐに気づくことは、AIはLLMを呼び出す長時間実行されるwhileループとそれほど変わらないということです。これらのエージェントには、一貫して取引を行う方法がありません。結局、このような庭が存在するとしても、ある種の壁に囲まれた庭のようなものになってしまうのです。
では、挙手でお聞きしますが、AIエージェントがインターネット上で何かの支払いをしてくれたことがある方はいらっしゃいますか？おそらくACPか他の標準を使ってですね。ええ、こうした問題に対処するための標準が出現し始めているのがわかりますね。ACPはチェックアウトやヒューマン・イン・ザ・ループの会話型コマースにとって素晴らしい標準です。しかし、真の自律性を実現したいのであれば、支払いの標準がインターネットに直接組み込まれる必要があると思います。なぜなら、AIエージェントはインターネットの基本的な経済モデルを根本的に破壊してしまうからです。
インターネットの多くがどのように機能してきたか、これまでどう機能してきたかを考えてみると、ある販売者がウェブサイトにお金を払います。そのウェブサイトはあなたにコンテンツと販売者の広告を表示します。あなたはユーザーとしてそのコンテンツと広告を消費し、そしてある時点でコンバージョンして販売者から商品を購入します。これが、消費者向けインターネットの多くの仕組みだと言えます。ウェブサイトは広告を配信できるのでコンテンツを公開するインセンティブがあります。その広告がコンバージョンします。販売者が支払います。3つのアクター間で素晴らしいクローズドループができています。私たちが目にしているのは、AIが広告を取り除き、それによって支払いも取り除いてしまうということです。
より多くの人々がチャットインターフェースを使ってインターネットを消費し始めると、LLMからの応答に情報を提供したウェブサイトからの広告を見たことはおそらくないでしょう。これらのLLMをトレーニングするためのスクレイピングも、コンテンツパブリッシャーが価値を逃すという結果になります。そうして、この循環が壊れてしまうのです。私たちには新しい循環が必要です。私たちにはこうしたインタラクションのための新しい経済モデルが必要なのです。これを実現する方法の一つは、コンテンツに直接支払うことです。このループをスキップして、ウェブサイトに直接支払うのです。ここで登場するのがx402です。これはCoinbaseが取り組んでいるインターネットネイティブな支払いのためのオープンスタンダードです。
x402プロトコルの仕組み：HTTPステータスコード402を活用した決済標準
実際、x402とはインターネットとブロックチェーンベースの支払いの間の橋渡しです。人々が拍手している時に話すのはとても気が散りますね。インターネットとブロックチェーンベースの支払いの間の橋渡しであり、ブロックチェーンの利点とこれらのサブセントトランザクションの利点を得ることができます。インターネット上で、コンテンツに直接支払うことが実現可能でない理由の一部は、手数料が30%から3%である既存のレールで30セントや50セント、あるいは1ドルを動かすことが本当に難しいからです。ビジネスとして、50セントを請求している場合、今度は14セントの価値しか得られず、これは多くのマージンを食いつぶすことになります。一方、0.1セントの手数料を請求されている場合は、40セントから50セント、あるいは49.9セントを稼ぐことができますよね？
では、x402とは何でしょうか？x402はインターネットネイティブな支払いのためのオープンスタンダードです。これは、私が講演の冒頭で述べた哲学のポイントを満たしています。これはCoinbaseで始まりました。
実は私が作成したもので、現在はLinux Foundation JDFとして構造化された独立した財団に移管されているところです。 では、どのように進んでいるのでしょうか？11月には、x402は7000万件のトランザクションを処理しました。正直に言って、この成長は驚くべきものです。週次で30%の成長という素晴らしいチャートがあったのですが、11月に大きな変曲点を迎え、本当に急成長しました。この7000万件のトランザクションのうち、実際に動いた金額、つまりドルの量は約4000万ドルでした。お気づきかと思いますが、4000万ドルは7000万ドルより少ないですね。x402での平均トランザクションサイズは約80セントの取引を表しています。これらはカードレールでは実際にはできなかった取引であり、x402を使えば1セントから100万ドルまで、本当に必要であればですが、どこでも支払いをスケールアップできます。しかし、このマイクロペイメントのニッチ市場が、これまでのところx402のプロダクトマーケットフィットとなっており、以前は不可能だった新しいことを可能にしています。
では、x402は実際にどのように機能するのでしょうか？ クライアントとサーバーの既存のフローに標準的に、クライアント、ブラウザ、携帯電話、LLM、ボットがサーバーにHTTPリクエストを送ります。そのサーバーは402ステータスコードと、payment requiredというヘッダーで応答します。このヘッダーには支払い方法を伝えるデータが含まれています。そのデータがどのようなものかは、すぐに説明します。 クライアントはそのヘッダーを見て、その支払いを表すペイロードを構築します。その支払いペイロードがどのように構築されるかは、すぐに触れます。心配しないでください、説明しますから。そして、同じリクエストを、今度はpayment signatureのヘッダーと構築したペイロードを含めて再度送信します。
サーバーには選択肢があります。このスライドで行っているすべての作業を自分で行うこともできますし、 Web3での作業にあまり慣れていないチームの場合は、x402でのブロックチェーンとのやり取りを、私たちがfacilitatorと呼ぶものに委任することができます。facilitatorには、かなり標準化されたフローがあります。サーバーはHTTP経由でfacilitatorのverifyと呼ばれるエンドポイントを呼び出し、クライアントに送った支払い要件とクライアントから送られた支払い署名の両方を伝播します。facilitatorに「この支払いは有効になりますか？実際にこの支払いを処理すべきですか？」という質問をします。ハッピーパスでは、facilitatorは200レスポンスで「はい、これは良いペイロードです。これによってあなたは支払いを受け取ることになります。クライアントに応答するために必要な作業を行うべきです」と言います。
ここでサーバーは、データベースクエリ、キャッシュルックアップ、PDFの生成など、Webサーバーとして行っている作業を実行します。そして作業が完了した後、facilitatorのsettleに、その支払い署名とクライアントに渡した支払い要件データを再度ポストします。facilitatorは ブロックチェーンへのトランザクション送信を処理します。ブロックチェーントランザクションが送信されると、facilitatorはサーバーに応答して「この支払いは成功しました」と伝えます。これは実際にはブロッキング操作です。最新のL2や最新のブロックチェーンでは、トランザクションを確認する処理時間は約2秒であり、クライアントに返す前に、お金を受け取ったこと、そしてそれが取り消し不可能なトランザクションであることを実際に知ることができます。
ステーブルコインは返金をサポートしていますが、チャージバックはサポートしていません。そのため、サーバーとしては常に「ああ、間違えました、クライアントに返金します」と言うことができます。しかし、クライアントには、すでにあなたに渡した資金を奪う能力はありません。そして今、資金を手に入れたので、クライアントに「はい、こちらがそのニュース記事です、こちらがあなたが求めているAPIアクセスです」と返すことができます。これは標準的なHTTP動詞を通じて行い、ヘッダーを活用するだけでHTTP仕様全体を通じて機能します。post、get、put、何でも好きなものに返すことができます。
それでは、このpayment requirements データ構造について見ていきましょう。これがpayment requirementsのトップレベルの構造です。x402プロトコルのトップレベルバージョンがあります。私たちは間もなくspecのV2をリリースする予定です。そして、acceptsと呼ばれるpayment requirementsのリストがあります。このacceptsキーワードによって、サーバーは複数の支払い方法を指定することができます。サーバーとして、BaseのUSDCでの支払いをサポートしていると言うことができます。また、SolanaのUSDTでの支払いもサポートしていると言えます。そして将来的には、x402はfiatメソッドもサポートする予定です。MastercardやVisaでのUSDをサポートしていると言うこともできるでしょう。そして、error でクライアントにエラー情報を伝えます。
acceptsキー内のそれぞれのpayment requirementsは、ここで展開されており、scheme、network、asset、pay-toフィールド、そして転送される金額であるmax amount requiredで構成されています。他にもメタデータのフィールドがありますが、これらが最も重要なものです。これがどのように見えるかというと、右側にあるような ものをクライアントに返すことができます。ここではx402バージョン1で動作しており、USDCの識別子であるassetのBase上のExactというschemeを受け付けています。そして、暗号アドレスに支払ってほしいということです。この暗号アドレスは、どんなウォレットでも構いません。Coinbaseのような取引所でも構いません。暗号資産を受け取ることができる任意のアドレスで構いません。そして、もし支払わなかった場合は、payment not includedとなります。
payment payloadについてお話ししましょう。schemeとnetworkに気づくと思いますが、その考え方としては、schemeはお金が移動する論理的な方法です。Exactでは、私があなたに1ドルを手渡すのと同等です。それがやり取りの複雑さのすべてです。私は財布から1ドルを取り出して、あなたに手渡しました。お金を移動させる他の論理的な方法もあり得ます。例えば、LLMトークン生成では、LLMは決定論的に終了しないため、トークンの生成が完了するまでいくら請求すべきかが必ずしもわかりません。そこで、up-toと呼ばれるschemeを想像できます。これは、最大1ドルまで請求する可能性があるが、正確にいくら請求されるかはまだわからない、ということです。つまり、1ドルを事前承認してもらい、トークンの生成が完了した後、実際に実行した作業に基づいて請求します。
このpayloadをどのように構築するかが、mechanismと呼ばれるもので、mechanismはschemeとnetworkの上に構築されます。これが意味するのは、支払いを実行する方法が、networkと支払いが実行される論理的な方法から切り離されているということです。BaseやEthereum上のExactは、例えばSolana上のExactとは異なる動作をします。そして、資金が実際に決済されるブロックチェーンネットワークやfiatネットワークに対して、支払いフローを最適化することができます。
x402の設計思想：安全性、ネイティブ性、導入の容易さ、拡張性の実現
x402の目標のいくつかは、安全性、ネイティブ性、採用の容易さ、そして中立性と拡張性でした。 安全性については、クライアントが支払いを構築するロジックを保持します。サーバーやファシリテーターは、クライアントが資金の移動を承認しない限り、資金を移動させる能力を持ちません。サーバーは、受け入れることを選択する支払いメカニズムを選択するので、誰かが「このマイナーなチェーンで支払ったから、あなたのサービスを提供する義務がある」と言うことはできません。サーバーは受け入れることを選択するメカニズムを指定し、クライアントはどれを使用したいかを選択します。同様に、販売時点では、Visa、Mastercard、Amex、現金を受け付けるかもしれません。あなたは財布を取り出して、「ああ、Visaカードを持っているから、Visaで支払おう」と言います。
facilitatorは、いかなる時点においても資金を保管することはなく、資金を指示したり、どこかにルーティングしたりすることもできません。これは単にブロックチェーン上の抽象化レイヤーであり、サーバーがホットウォレットを実行したり、RPCノードを実行したりする必要がないようにするためのものです。サーバーは、ガスの管理とブロックチェーンとの大規模なトランザクション処理という責任をfacilitatorに委譲することができます。EVM Exactの安全性については、EIP-3009メッセージを使用しています。これはEVMエコシステムにおける署名ベースの転送の標準です。その結果、資金が移動できる唯一の方法は、クライアントが資金の移動を許可するintentに署名した場合のみとなります。
Nativenessについてです。私たちは、クライアントとサーバー間で発生する既存の通信に支払いを含めたいと考えています。つまり、これらのタイプは、トランスポートにネイティブな方法で表現される必要があるということです。また、x402では、トランスポートと資金の移動方法を分離しています。HTTPでは、支払い要件とペイロードをヘッダーに含めます。MCPで発生する既存のリクエストでは、すべてのMCPインタラクションとツール呼び出しに存在するmetaフィールドにそれらを含めます。Agent-to-Agentでは、メタデータのx402 paymentフィールドに含めます。私たちは、発生する各トランスポートの規約に従うようにしており、これはすべてリポジトリで標準化され、文書化されています。
誰でも、私たちのリファレンスSDKとは独立してクライアントやサーバーを書くことができ、他のクライアントやサーバーとやり取りできるようになります。なぜなら、トランスポートの動作方法は標準の一部だからです。MCPコンテキスト内でx402がどのように機能するかについてのドキュメントを読んで、独自のクライアントを書くことも、この数ヶ月間で書かれた多くのクライアントを使用することもできます。
導入の容易さは非常に重要です。 可能な限り、クライアント側でRPCやガスを必要としないようにしています。クライアントのスタックに新しい技術を導入する必要はないはずです。ブラウザや既存のWebエコシステムとの後方互換性をできるだけ確保したいと考えています。また、SDKのすべての署名、標準、signerが業界標準のインターフェースに準拠するようにしています。これは非常に細かい話ですが、アクションを表現するための既存のパターンがある場合は、それを使用してください。新しいものを発明しないでください。
私たちは、一般的なすべてのHTTPフレームワーク向けにミドルウェアを提供しようとしています。つまり、Express、Hono、Flask、Gin、そして他にもここで挙げきれないものがありますが、これらを使っている場合、既存のサービスにx402をミドルウェアとして1行のコードで統合できます。そして、先ほど述べたように、ファシリテーターがあります。これは暗号化を抽象化し、導入のハードルを非常に低くします。ホットウォレットの操作方法を学ぶ必要はありません。ノードも必要ありません。ファシリテーターがあれば、RPCリクエストを送信するためのURLだけが必要で、すべてが実行されます。私たちのミドルウェアはそれを抽象化します。使用したいファシリテーターのURLをミドルウェアの設定に追加するだけです。
次に、拡張性と中立性についてです。これが、データ構造と実装を分離する理由です。これにより、EVM x402とSVM x402が異なることができ、クライアントとファシリテーターがそのシナリオで何をすべきかについて共通の理解を持つことができます。これは、imageタグがPNGを使用している場合、サーバーがそのPNGをエンコードする方法を知っていて、ブラウザがそのPNGをレンダリングする方法を知っているのと似ています。哲学的に、私たちはフルスタックですべての問題を解決しようとするのではなく、意見を持たずモジュラーであることを好みます。私たちは1つの問題を非常にうまく解決しようとしています。アイデンティティやエージェントシステムの他の側面に関しては、私たちはそれらと互換性を持ちたいのであって、全員を私たちのフルスタックソリューションに強制しようとはしていません。
では、これで何が得られるのでしょうか？ ここにあるこのデモビデオは、私がチャットインターフェースLLMを使用してx402と、最近起こっているx402に関するトレンドを調査しているところです。このチャットインターフェースのユニークな点は、 ステーブルコインを持つウォレット、x402リソースの支払い能力、そしてx402リソースの発見能力へのアクセスを提供するMCPツールを持っていることです。 ご覧いただけるように、まずウェブを検索してx402を調査し、次に私たちがBazaarと呼んでいる、x402サービスのマーケットプレイスをチェックします。 そして、それらのサービスの1つからデータに対して支払いを行い、x402について書くレポートを充実させます。これらの資金、そしてこれがエージェントが持っているウォレットですが、これらの資金は エージェントに隔離されています。ウォレットには56セントが入っています。その56セントしか使えません。そして私は、 リクエストごと、またはセッション内でどれだけ使えるかについて権限を設定する能力を持っています。
誰でもこの体験を構築できます。これは完全に、x402やステーブルコインを取り巻くウォレットエコシステムとインフラストラクチャのようなオープンスタンダードの上に構築されています。この体験は、x402を受け入れるあらゆるものに対して機能します。つまり、あなたのAPIがx402による支払いを受け入れるなら、このMCPは今やあなたのコンテンツに対して支払いができるのです。これは非常に強力です。これまで不可能だったレベルのエージェント利用を可能にすると思います。現在は、各MCPツールを手動で統合する必要があります。今では、1つのMCPツールを統合すれば、エコシステム内のあらゆるものに対して支払いができるのです。
得られるのは動的なエージェントです。エージェントが持つ能力のセットは、あなたが人間として1つずつ統合してきた垂直統合やウォールドガーデンのセットに制限されません。ブラウザがインターネット上のあらゆるウェブサイトを訪問できるのと同じように、エージェントは今や、あなたのために仕事をより良くするために、あらゆるツールやサービスに対して支払いができるのです。それでは、Joshに引き継ぎます。Joshは、x402とステーブルコインを使用してAWS上で決済インフラストラクチャを構築する方法についてのソリューションをお見せします。
AWS上でのAI決済システム構築：BedrockとAgent Coreの活用
はい、ありがとうございます、Eric。それでは、まず概念的なハイレベルから始めましょう。私たちはここAWSで、スケーラブルなAI決済システムを構築するためのスタックについて考えています。このスタックは、プラットフォームまたは基盤から始まります。AWSは、Arvinが先ほど話していたように、コンピュート用のEC2やAI用のAmazon Bedrock、またはNitro EnclavesのようなセキュリティプリミティブやCloudFrontのようなエッジサービスといったプリミティブを提供しています。今日は、 このスタックを支えるこれらの基盤のいくつかと、実際にソリューションを構築する方法についてお話しします。
その上に、Ericが話したようなオープンプロトコルを活用します。これらのいくつかは古くから存在しています：HTTP、DNS、HTML、言語、フレームワーク、プロトコルです。そして今、x402が決済のためのオープンスタンダードとして登場し、これを統合して使い始めることができます。ここから、プラットフォームとプロトコルを組み合わせて、より高度なサービスを構築し強化することができます。これがミドルウェアで、これらの一部はサービスとしての製品、B2B製品であり、AmazonはBedrockのようなサービスを提供しています。私たちはBedrock用のAgentCoreを提供しており、これについてはすぐにお話しします。そして、エージェント型AIのための完全なスイートを持っています。CoinbaseはAgentKitと呼ばれるものを提供しており、AgentKitはウォレットをAIエージェントに接続するツールで、今日はこれも活用します。そして最後に、これらすべてが、Web2アプリケーション、Web3アプリケーション、ハイブリッドアプリケーション、そして決済を含むエージェント間通信に接続する複雑なソリューションを構築することを可能にします。
それでは、ズームアウトして見ると、このスライドにはあまり時間をかけませんが、AWSはスタック全体にわたってエージェント型AIソリューションを提供しています。最下層にはインフラストラクチャがあり、ビルダー向けの開発とサービスがあり、そしてアプリケーションがあります。私たちは、皆さんが望む方法でジャーニーを始めるのを支援できる、モデル、ツール、アプリケーション、専門知識のスイートを提供しています。また、カスタムシリコン、データアクセス、その他の基盤サービスを含む堅牢なインフラストラクチャも提供しています。
そして今日は、この中間層とBedrockにズームインします。なぜなら、私たちはビルダーについて話しており、これらの新しいプロトコルの採用について話しているからです。それでは、Amazon Bedrockですが、 これに入る前の前提として、これはエージェントを含むGen AIアプリケーションの構築、デプロイ、運用を支援するサーバーレスで完全マネージド型のサービスです。BedrockはMistral、Anthropic、Cohere、Amazon、その他からの主要な基盤モデルへのアクセスを提供し、ガードレールを適用したり、コストを最適化したり、レイテンシーを最適化したり、データを非常に簡単に活用したりできます。これらの機能は、暗号ネイティブなエージェント型AI決済システムの構築と運用を含む、あらゆるタイプのユースケースに使用できます。
BedrockにはAgentCoreも含まれています。そして、上部にこれらのサービスがあります。これらは、エージェントを安全に大規模にデプロイし運用するためのサービスです。この上層は、エージェントを運用し実行するものと考えることができます。Runtimeがあり、これは長時間実行されるエージェント用のサーバーレスランタイムで、インフラストラクチャを管理する必要がありません。次にAgentCore Gatewayがあり、これによってMCPサーバー、APIをエージェントと簡単に統合でき、大量のツールでエージェントを強化する簡単な方法を提供します。そして今日はこれら両方のサービスを使用します。そして最後に、AgentCore BrowserとCode Interpreterは、エージェントがブラウザ内で自律的に動作し、皆さん自身の条件でコードを実行できるようにします。下層については、これらのエージェントを可能にする支援ツールのようなものだと考えています。
エンタープライズ対応のエージェントを構築するには、標準ベースの認証を備えたアイデンティティが必要です。エージェントでOAuthのようなものを使用します。AgentCore Memoryは、エージェントが短期および長期のメモリを保存および取得できるようにします。これらのエージェントはステートレスで、Runtime内で実行されているためです。そして、これも今日使用する予定です。そして最後に、observabilityはGen AIエージェントのためのobservabilityスタックを一元化するのに役立ちます。特に決済システムにおいては、LLMの精度と決定論の欠如により、observabilityは追加のレイヤーを持つ必須要素となります。では、これらのツールを使用すると、ここでズームアウトすると、何を達成できるでしょうか？AIの成熟度において私たちが目にする重要な領域の1つは、ツールを発見して使用する能力です。エージェントは最終的に数万のツールにアクセスできる可能性があります。そこでAgentCore Gatewayがこのエコシステムに接続し、ツールの発見を可能にし、Authと組み合わせてどのエージェントがどのツールを使用できるかを決定し、そして有料のAPIキーを使用できるツールを活用し始めることができます。既存の関係、つまりAPIキーを持つ月額サブスクリプションがあるかもしれませんし、Lambda関数やEC2サーバー上で実行されている内部サービスを呼び出したいかもしれません。しかし、今日お話しするのはこの中間チャネルです。エージェントがツールを発見して使用する能力を持たせたい場合があります。Ericがビデオで示したように、インターネット上で利用可能なものを見に行き、x402を使って目標を達成するために何ができるかを見に行く、という方法です。そこで、CloudFrontを使用し、Lambda Edgeを使って関数を実行できるようにし、S3やEC2によってバックアップされたコンテンツを持つアーキテクチャを作成し、このフレームワークを構築できます。
トラベルエージェントAIの実装例：Nitro EnclavesとAgentKitによるエンドツーエンドアーキテクチャ
そこで今日は、トラベルエージェントAIとそれと連携するデータプロバイダーの例についてお話しします。これは企業によって構築される可能性があります。自動化されたバケーションパッケージを構築している顧客にサービスを提供しようとしている仮想の企業があるとしましょう。エージェントはユーザーにフロントエンドを提示します。これがトラベルエージェントAIインターフェース、つまりチャットです。
そしてAIは、Agent Core Gatewayを使用して、x402 MCPサーバーから利用可能なツールを発見することができます。ここでの例として、このエージェントは多くの異なるタイプのデータを活用する必要があります。ホテルの在庫、フライト、フライト価格、空席状況などを持つグローバル流通システムを活用する必要があるかもしれません。これはさまざまな方法で課金される可能性があります。クエリごと、予約手数料、またはその他の料金です。また、観光スポットのデータベース、地元のアトラクションも必要かもしれません。これらはクエリごとに課金される可能性がありますよね？このレストランのレビューを1ペニーで送ってください、という具合です。遅延リスクや予報を特定するため、または晴れた場所に行きたいかどうかをチェックするための気象データも必要かもしれません。
まずはズームアウトして見てみましょう。これがエンドツーエンドのアーキテクチャです。左側にはトラベルエージェントAIがあり、これはCoinbaseのNitro EnclavesとCoinbaseのAgentKitを使用したサーバーウォレットによって駆動され、Bedrock AIエージェントと対話します。中央には、データプロバイダーまたはマーチャントがいます。彼らは気象データ、マップサービスのAPIを提供し、そしてrailsがあります。これはEricが話していたファシリテーションレイヤーです。
暗号データ決済を行う予定なので、まず基盤を見てみましょう。Nitro Enclavesを使用したセキュアウォレットです。ここで長い時間は費やしませんが、AWSサイトにCoinbaseと共同で書いたブログがあります。それを送ったり共有したりできます。最後にQRコードがあるかもしれません。しかし、これはCoinbaseがAWS上でサーバーウォレットを駆動するために使用しているアーキテクチャです。開発者がウォレットを作成したりトランザクションに署名したりしたい場合、APIゲートウェイを通じてこのワークフローに従います。リクエストはこのenclave内のセキュアサイナーに渡され、CoinbaseもAWSオペレーターもこれらのキーにアクセスすることはできません。このウォレットは、暗号決済を構築して有効にするための安全な基盤を提供します。あとはそれに接続するだけです。
それでは、AgentKitはBedrock AIエージェントと連携して動作します。これが今日お話しするアーキテクチャです。このアーキテクチャがそのAIエージェントを支えているんですね。 そして、このセキュアなウォレットにアクセスするためにAgentKitを使用しています。右側のゲートウェイのところにAgentKitが見えますが、まず上の方から見ていくと、スーパーバイザーエージェントがあります。これは任意のマルチエージェントワークフローで構いません。これは単なる例です。Agent Coreランタイムで動作するスーパーバイザーエージェントがあり、これが旅行のメモリとプランニングを管理する旅程エージェントと対話します。そして、仮定を立てていきます。この場所が良いと確認できたので、この場所にホテルを見つける必要がある、と言うわけです。そこに行きたいので、空室があることを確認したい。そこで、これらの仮定をツールエージェントに確認させます。
ツールエージェントはAgent Core Gatewayを使用して、利用可能なツールを検索します。これらのツールの中には、 Agent Core Gatewayに直接登録されているものもあるかもしれませんが、アカウントの外部にある外部のMCPサーバーもあるかもしれません。これはx402 MCPサーバーかもしれませんし、 あるいは既存の旅行会社や旅行代理店が運営する何らかのユニバーサル旅行MCPサーバーかもしれません。エンドツーエンドのパスを見てみると、ツールエージェントは Agent Core Gatewayを呼び出します。Agent Core Gatewayを通じてx402 MCPサーバーを呼び出し、必要なデータにアクセスして、x402経由で支払いを行います。AgentKitを通じて持っているウォレットを活用できるようになります。これもゲートウェイに登録されています。
これがAIエージェント側ですが、 実はAWS上の反対側も見ることができます。もしあなたがデータプロバイダーだとしましょう。つまり、気象データを提供しているサービス、地図データを提供しているサービスだとします。覚えておいてください、これらはフライトスケジューリングや配信を提供しているエンティティです。AWS上のこれらのお客様にとって、x402というブリッジを使用して、既存のバンドルやサブスクリプション方式の支払いに依存せず、新しいワークフローのために新しい方法でデータを収益化し始める機会があるのです。
では、マップ上での私たちの位置を示すために、これは別の視点から見たアーキテクチャです。Agent Core Gatewayと重複する部分があります。先ほど見たのと同じx402 MCPサーバーが見えます。これは位置を示すためのものです。AgentKitとx402 MCPサーバーがツールとして登録されています。このレイヤーを通過すると、CDN、つまりCloudFrontを経由して、ここにあるLambda関数、Lambda Edgeにビューワーリクエストとして送られます。このビューワーリクエストには最初、支払い情報がないかもしれません。そこで、このLambda関数は、このコンテンツは実際に支払いが必要だというリクエストを返します。支払いが必要であることを示すヘッダーが必要だと。アセット、ネットワーク、そしてEricが話していたようなパラメータを指定し、クライアントはリクエストを再試行できます。
支払いヘッダーが存在する場合、ファシリテーターに検証を依頼します。この支払いは機能するのか、この支払いは通るのか、このアドレスは有効なのか、と尋ねるわけです。それが有効であれば、x402関数はサーバーに応答を返してリクエストを行い、最終的にエージェントは正しい支払いを発行できます。 ワークフローの最後に、リクエストをオリジンに転送できます。この場合、衛星気象画像やJSON気象データ、または旅行エージェントが必要とするあらゆるデータをホストしているEC2ウェブサーバーです。この時点で、エージェントは気象データをリクエストしました。AgentKit経由で接続されたウォレットによって支払いが行われ、マーチャントは受け入れられた支払いについてx402経由でプロンプトされました。ファシリテーターがブロックチェーン上での決済を処理し、資金はマーチャントの暗号ウォレットに到着します。
また、追加のリソースやブログなどもご用意しています。Agent Coreのドキュメントでは、先ほどお話しした observability、identity、runtime、gateway について詳しく説明されており、これらのプリミティブについて理解を深めることができます。また、Coinbaseと共同で執筆したブログもあり、私たちが使用したNitro Enclavesベースのウォレットについて深く掘り下げています。そして、こちらにCDPのドキュメントへのリンクもあります。これはx402、AgentKitをはじめ、彼らが提供する他のサービスについてカバーしています。それでは、お時間をいただきありがとうございました。このトークを楽しんでいただけたことを願っています。それでは、良い週末をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion