Cloudflare Walletsが使う決済プロトコル x402 を理解する 目次 はじめに x402が対象とする課題 プロトコルフロー ② 402 Payment Required と PaymentRequirements scheme が取る値 — exact と upto ③ authorization への署名 ④ PaymentPayload の送信 ⑤ verify / settle と facilitator 決済の確定と不可逆性 HTTPを利用する構成のメリット 支払ってよいかの判断は仕様の範囲外 まとめ 参考 はじめに こんにちは、開発本部開発1部の 赤川 です。食事管理アプリ ヘルシカ の開発をしています。 ダイエット・食事管理・体重管理・カロリー計算 - ヘルシカ every, Inc. ヘルスケア／フィットネス 無料 2026年8月4日、Cloudflareが Cloudflare Wallets を発表しました。これは、Web上でサービスの購入や入金を行うためのウォレットで、Cloudflareのアカウントに紐づきます。現時点ではウォレットの識別子の予約のみが提供されており、僕もとりあえず予約してみました。 Cloudflare Wallet Tagを予約した Cloudflare Walletsでは、アカウントが持つWalletから、エージェントが使うVirtual Walletに支出権限を委任できます。エージェントはVirtual Walletを使って、API、MCPツール、コンテンツなどを購入できます。 この購入のやり取りには、 x402 という決済プロトコルが使われています。x402は、HTTPのリクエストとレスポンスの中だけで完結し、支払いが必要であることを示すのに、HTTPステータスコードの 402 Payment Required 1 を使っています。 本記事ではこの x402 について、ドキュメントをあたりながらまとめてみました。 x402が対象とする課題 例えば有料APIを利用しようと思ったら、我々は一般に次の手順を踏みます。 サービスにサインアップする クレジットカードなどの決済手段を登録する APIキーを発行する そのキーをリクエストに付けて呼ぶ 月末にまとめて請求される 認証と課金がフローとして完全に分離しており、いずれも事前のサインアップを前提としています。 人間が利用する分には何の問題もないですが、クライアントがAIエージェントである場合、この前提が制約になります。手順1〜3のうち、サインアップページは人間向けのUIとして作られており、決済手段の登録も人間の承認が必要です。エージェントは事前登録された識別子も支払い手段も持たないため、この3手順の実行には人間の介在が必要になります。 x402は、事前の登録手続きなしに支払いを成立させる方式を定義しています。 プロトコルフロー プロトコルのフローは次のとおりです。この章の図や記述は、 x402 Specification v2 と Cloudflare の x402 ドキュメント に基づいており、執筆時点で最新のv2について書いています。 x402のプロトコルフロー このフローには、アカウントやセッション、事前に共有したAPIキーなどは含まれません。ClientとServerはこのリクエストで初めて通信し、支払いが成立します。 ※ 実際の支払いは、ブロックチェーン上でトークンを送ることで成立します。USDCなどのステーブルコイン（米ドルなどの法定通貨に価値を連動させたトークン）が使われます。 ② 402 Payment Required と PaymentRequirements ①のリクエストに対して、Serverは②で 402 Payment Required を返します。支払いの条件は PAYMENT-REQUIRED ヘッダに、Base64エンコードされたJSONとして載ります。 このJSONの accepts フィールドに、支払いの条件が配列で入ります。要素1つが「この条件で払ってくれれば、このリソースを渡すよ」という1件分の提示にあたり、これを PaymentRequirements と呼びます。配列なのでServerは条件の異なる複数の選択肢を並べられ、Clientはその中から1つを選びます。 PaymentRequirements は次のフィールドから構成されます。 フィールド 内容 scheme 支払いスキーム（ exact / upto ） network 対象ブロックチェーン（Base、Ethereum、Solana など） amount 金額 asset トークン種別（USDC など） payTo 支払いの宛先アドレス maxTimeoutSeconds タイムアウト scheme が取る値 — exact と upto scheme フィールドは支払い方式を指定します。 Cloudflare のドキュメント に記載されているのは次の2つです。 exact : 固定額の送金です。EVM（Ethereum Virtual Machine） 2 上では USDC を payTo のアドレスに送金します。②の時点で金額が確定しているケースに対応します。 upto : 上限額を先に承認し、実際の課金額を決済時に確定します。LLMの推論APIのように、実行するまでトークン数が確定せず、金額が事後に決まるケースに対応します。 ③ authorization への署名 Clientは、 accepts の中から採用する PaymentRequirements を1つ選び、その内容を authorization オブジェクトに反映して署名します。authorization の形は、 scheme とチェーンの種類の組み合わせで決まり、EVM上で exact を使う場合は次のフィールドを持ちます。 フィールド 内容 from 送金元アドレス to 宛先アドレス value 金額 validAfter / validBefore 有効期間 nonce 一度きりの値 署名は自身の秘密鍵で行います。署名が保証するのは、その鍵の保有者にしか生成できないこと、署名対象が1バイトでも変われば検証に失敗すること、の2点です。 nonce は一度きりの値であり、 validBefore で有効期間が区切られるため、同じ署名を他の支払いに再利用することはできません。 ④ PaymentPayload の送信 署名と authorization は PaymentPayload にまとめられ、 PAYMENT-SIGNATURE ヘッダに載って、同じURLに再送されます。 PaymentPayload は次の構造です。 { " x402Version ": 2 , " resource ": { ... } , " accepted ": { /* ②の accepts から選んだ PaymentRequirements */ } , " payload ": { " signature ": " ... ", " authorization ": { " from ": " ... ", " to ": " ... ", " value ": " ... ", " nonce ": " ... " } } } ⑤ verify / settle と facilitator ⑤でServerが行う検証と決済は、facilitator に委譲できます。facilitator は、支払いの検証とブロックチェーンへの送信を担うサービスで、次の2つのエンドポイントを提供します。 POST /verify : 支払いペイロードが有効かを、ブロックチェーン上で送金を実行せずに検証する POST /settle : 検証済みの支払いをブロックチェーンに送信し、送金を確定させる facilitator の利用は必須ではありませんが、ブロックチェーンとのやり取りを抽象化できるため、Cloudflareのドキュメントでは推奨されています。 Clientは facilitator と直接通信せず、ServerとHTTPで通信します。⑤の内側を展開すると、次のようになります。 facilitator を含む⑤の内側 決済が確定すると、Serverは⑥でリソースを返します。決済の確認は PAYMENT-RESPONSE ヘッダに載ります。 決済の確定と不可逆性 x402の決済は、1回の送金で確定します。カード決済のように、支払いを承認する段階と実際に資金が動く段階が分かれることはありません。これにより、リソース1件ごとのような少額の支払いでも短時間で決済できますが、同時に次の制約が生じます。 決済を取り消せない プロトコルとして返金手段を定義していない 誤送金や詐取による送金があった場合、プロトコルの範囲では資金は戻りません。返金や救済を実装する場合は、アプリケーション層で別途定義することになります。 HTTPを利用する構成のメリット x402は決済専用のプロトコルを新設せず、支払いのやり取りをHTTPのリクエスト/レスポンスサイクルの中で表現します。そのためクライアントを選びません。エージェント、curl、サーバ間通信のいずれも対象になり、SDKも必須ではありません。 402応答は特定のURLに対する支払い要求なので、値付けの単位もURLになります。エンドポイントごと、MCPツールごとに価格を返せます。 支払ってよいかの判断は仕様の範囲外 x402の仕様が定義しているのは、3つのHTTPヘッダ、 PaymentRequirements と PaymentPayload の構造、facilitator の verify / settle の手順、および scheme です。「どのような条件で支払いを承認するか」は定義されていません。仕様上、正しく署名されたペイロードは正当な支払いとして処理されます。 Cloudflare Walletsは、この判断をウォレット側で縛る仕組みを持っています。エージェントに渡すVirtual Walletには、使ってよい金額の枠（allowance）、支払い先の許可リスト（allow list）、1回あたりの上限額（maximum transaction size）を設定できます。 これらはウォレット側の設定なので、エージェントが何をしようとしても、枠を超える送金や、許可リストにない相手への送金は成立しません。x402が定義していない「支払ってよいか」の判断を、エージェント任せにせず、ウォレットの設定として持たせている構成です。 まとめ x402の仕様を整理すると、次のようになります。 決済専用のプロトコルを新設せず、HTTPのリクエスト/レスポンスサイクルで支払いを表現する 事前のアカウントもAPIキーも使わず、402応答とその再送だけで支払いが成立する scheme として exact （固定額）と upto （上限額の事前承認）を定義する 検証と決済は facilitator に委譲できる。利用は必須ではない 決済はブロックチェーン上で確定し、プロトコルとして取り消し手段を持たない 支払ってよいかの判断は仕様の範囲外で、クライアント側に委ねられる 最後までお読みいただきありがとうございました。 参考 Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet - The Cloudflare Blog （2026年8月4日） x402 - Cloudflare Agents docs x402 Specification v2 - coinbase/x402 RFC 9110: HTTP Semantics - 15.5.3. 402 Payment Required 現行のHTTP仕様である RFC 9110 では "The 402 (Payment Required) status code is reserved for future use." と記述されています。402が標準として用途を定義されてこなかったことを、僕は今回の記事を書くまで知りませんでした。 ↩ Ethereum が採用しているブロックチェーンの実行環境です。これを採用するチェーンは多く、Cloudflareのドキュメントも EVM に対応するチェーンとして Base、Ethereum、Polygon などを挙げています。 ↩

分散型金融 (DeFi) の取引判断には、ブロックチェーンの価格と流動性データが必要です。 しかし、ブロックチェーンノードへの直接クエリは非効率的でリソースを大量に消費するため、タイムリーな意思決定のボトルネックとなります。 ブロックチェーンは効率的なデータクエリに最適化されておらず、データは順次 (ブロックごとに) 保存されています。 特定の情報を取得するには、多くの場合、ブロックチェーン全体をスキャンする必要があります。 インデクサーは、この問題に対するソリューションを提供します。 インデクサーは新しいブロックとトランザクションを監視し、最適化されたセカンダリデータベース (リレーショナルデータベースなど) にデータを保存するように設計できます。 これらのデータベースには、アプリケーションが直接クエリできる直接アクセス用のインデックスが含まれています。 インデクサーは、ブロックチェーンへの直接クエリと比較して高速な応答時間を提供し、過去および現在のブロックチェーンデータへの効率的なアクセスにより、DeFi アプリケーションのユーザー体験を向上させます。 ブロックチェーンインデクサーは広く利用可能ですが、既存のソリューションがブロックチェーンや必要なデータをサポートしていない場合、AWS 上にカスタムインデクサーを構築する必要があります。 本記事では、ブロックチェーンのシーケンシャルなデータ構造を DeFi アプリケーション向けに効率的にクエリできる形式に変換する、ブロックチェーンインデクサーの重要な役割とアーキテクチャについて説明します。 また、AWS 上でブロックチェーンインデクサーを構築するためのアーキテクチャガイダンスを提供します。 インデックス作成モード ブロックチェーンインデクサーには 2 つの異なるモードがあり、それぞれ異なる要件が適用されます。 バックフィル – 初回起動時、インデクサーはジェネシスから現在のヘッドまでのすべての履歴ブロックを並列プロセスで処理し、取り込み速度を最大化しています。ブロックチェーンデータは不変であるため、バックフィル中にチェーンのブロック再編成を考慮する必要はありません。 フォワードフィル – このモードでは、インデクサーは新しいブロックを発見次第すぐに取り込みます。ただし、ブロック再編成によるブロックチェーン先端の変更により、以前のブロックが無効になる可能性があるため、セカンダリデータストアが実際のブロックチェーンデータと一貫性を保つためのメカニズムが必要です。 ソリューション概要 インデクサーがブロックチェーンノードから直接抽出し、変換ロジックが変更された場合、ブロックチェーン全体を再インデックス化する必要があります (これは時間がかかります)。 代わりに、1 回抽出し、必要に応じて複数回変換とロードを行う方法を提案します。 ブロックチェーンデータを保存する中間ストレージレイヤーを作成することで、変換処理はノードに繰り返しクエリを実行するのではなく、ローカルコピーに対して処理を実行できるようになります。 次の図は、インデクサーの主要なコンポーネントを示しています。 ブロックチェーンノードは Ethereum ブロックチェーンに接続されています。 バックフィル(過去データ取得)とフォワードフィル(新規データ取得)のコンポーネントは、ブロックチェーンノードからデータを取得します。 抽出後、データは中間ストレージとしての Amazon Managed Streaming for Apache Kafka (Amazon MSK) にロードされます。 データは Amazon Managed Service for Apache Flink で変換され、 Amazon Relational Database Service (Amazon RDS) のようなデータベースにロードされます。 以下のセクションでは、抽出、変換、読み込み (ETL) プロセスについて詳しく説明します。 抽出 ブロックチェーンノードは、ブロックチェーン自体へのゲートウェイです。 すべてのブロックのローカルコピーを保持し、ブロックチェーンネットワークを通じて伝播される新しいブロックを受信します。 ブロックチェーンノードは、標準化された JSON-RPC 呼び出しを使用してクエリを実行できます。 ブロックチェーンのインデックス作成には、フルノードまたはアーカイブノードのいずれかが必要です。 フルノードはすべてのトランザクションを保持しますが、過去の状態データはプルーニングされます。一方、アーカイブノードは完全な状態履歴を保持します。 提案するアーキテクチャではアーカイブノードを前提としています。これは、フルノードを使用する場合、必要なデータがすべて含まれていることを検証する必要があるためです。 バックフィル データ取り込みの最初のステップは、ブロックチェーンの開始時点 (ジェネシスブロック) からチェーンの最新ブロックまでの過去データの取り込みです。 この過去データの取り込みコンポーネントは、過去のブロックを処理し、関連データを抽出して、Apache Kafka トピックにプッシュします。 Amazon MSK は中間ストレージとして機能します。 これにより、データを保持しつつ、複数の独立したコンシューマーがデータを処理できます。 この例では、blocks、transactions、logs という 3 つの異なるトピックを使用し、それぞれのデータを保持します。 理論的には、バックフィリングコンポーネントは、インデクサーがゼロから開始する際に一度だけ実行する必要があります。 すべての履歴データを取り込んだ後は、フォワードフィリングコンポーネントのみが、Kafka トピックをブロックチェーンの最新状態と同期させるために必要となります。 しかし、バックフィリングコンポーネントを再実行する必要がある理由はさまざまです。最初の実行時に一部のデータが取りこぼされた可能性がある場合、転送先のデータスキーマの変更、または修正された ETL ロジックのバグなどが考えられます。 バックフィリングコンポーネントを再実行する可能性があるため、高速化に重点を置いています。 バックフィリングコンポーネントの一般的なアーキテクチャは、次の図のようになります。 データ抽出には、 Paradigm が開発したオープンソースの抽出エンジン cryo を使用します。 これは、並列的な RPC 呼び出しを使用してブロックチェーンノードからデータを抽出し、ローカルファイルとして保存します。その後、これらのファイルを Kafka トピックにプッシュできます。 バックフィル中、インデクサーはブロックチェーンノードにクエリを送信します。 スロットリングを回避し、クエリへの応答を確実にするために、専用ノードを使用することをお勧めします。 ネットワークレイテンシーを削減するために、このノードをインデクサーの近くに配置することをお勧めします。 サンプルアーキテクチャでは、単一の Amazon Elastic Cloud Compute (Amazon EC2) インスタンスを使用して、ノードのホストとインデックス処理ロジックの実行の両方を行っています。 フォワードフィル バックフィル後、インデクサーはフォワードフィルモードに切り替わります。 フォワードフィルは継続的かつ順次実行され、ノードを監視して新しいブロックを検出します。 このコンポーネントは 2 つの機能を実行します。1/ ブロックチェーンノードを監視し、到着した新しいブロックを取り込む、2/ ブロック再編成 (reorg) を認識し続けます。 多くのブロックビルダーが同時に新しいブロックを作成しているため、生成されたブロックが無効になる可能性があります (より長いチェーンのフォークが存在する場合)。 インデクサーは reorg を認識する必要があります。ブロック reorg が発生した場合、フォークの起点まで遡る必要があります。 ブロック reorg は次のことを検証することで検出されます。1/ 各新しいブロックに前のブロックのハッシュが含まれていること、2/ ブロック番号が順次増加していること。 いずれかの条件が満たされない場合、reorg が発生しており、インデクサーはフォーク前の最後のブロックまで巻き戻す必要があります。 ワークフローには 3 つのステップがあります (上の図に示されています)。 現在の正規チェーンの先頭 (緑) に従わない新しいブロック (紫) が出現します。 インデクサーは新しいブロックから共通の祖先 (緑) まで遡ります。 インデクサーは共通の祖先までの、以前に保存されたブロックを削除します。インデクサーは新しい正規ブランチから新しいブロックを取り込みます。 次の図は、フォワードフィリングコンポーネントのアーキテクチャを示しています。 これは、ブロックチェーンノードがチェーンの再編成を正しく処理する機能に依存しています。 これを実現するために、Reth クライアントの Execution Extensions (ExEx) 機能を使用します。 クライアントは各新しいブロック (およびreorg) を ExEx に通知し、ExEx はデータをカスタムの送信先に送信できます。 reorgを処理するために、ExEx は巻き戻しと新しくコミットされたブロックの両方を Kafka にプッシュします。 Kafka トピックはこれらのブロックを順次保存し、その後変換ロジックが実行されて最終的なデータシンクのデータを更新または削除します。 変換 Apache Flink を使用すると、Kafka トピックに対してコンシューマーを実行し、データのフィルタリングと変換を行うことができます。 Flink アプリケーションは Java で記述されており、データのフィルタリングや変換に適しています。 アドレスまたはイベントデータのデコードによって、特定のスマートコントラクトに対するフィルタリングを実行できます。 変換されたデータは、再び Kafka トピック、Amazon RDS などのデータベース、または Amazon Simple Storage Service (Amazon S3) 上のファイルとして保存できます。 コンシューマーは元のデータを変更しないことに注意することが重要です。 変換ロジックに変更が発生した場合、最初の Kafka メッセージからインデックスを再構築するためにコンシューマーを再起動するだけで済み、データソース（ノード）自体に戻る必要はありません。 データの構造によっては、複数のコンシューマーを並列で実行できる可能性があります。 ロード コンシューマーは、データをカスタムシンクにロードできます。 Uniswap の例では、データをカスタム PostgreSQL テーブルに保存します。 フロントエンドはテーブルをクエリして、適切なデータを取得できます。 ソリューション全体の最終的なアーキテクチャは、次の図に示されています。 まとめ AWS ベースのブロックチェーンインデクサーは、単方向データフローと抽出プロセスと変換プロセスの分離により、最適化されたデータアクセスを実現します。 このアーキテクチャは、バックフィルによる効率的な履歴データ処理を可能にしながら、再編成検知機能を備えたフォワードフィルによってリアルタイムデータの整合性を維持します。 このソリューションは、MSK、Managed Flink、RDS を含む AWS サービスを活用して、ブロックチェーンの順次的な構造を効率的にクエリ可能な形式に変換する、スケーラブルで信頼性の高い基盤を構築します。 このソリューションをデプロイすることで、開発者は直接ノードにクエリを実行する際のパフォーマンス制限を回避しながら、貴重なブロックチェーンインサイト（洞察）を得ることができます。 詳細情報 このソリューションをご自身でデプロイするには、 GitHub の詳細なデプロイメントガイド に従ってください。 インデクサーのデモでは、デフォルトでアーカイブノードを持つ reth 実行クライアントを使用し、カスタムシンクにデータをストリーミングする方法を提供します。このストリーミング機能はフォワードフィリングプロセスで使用されます。 このソリューションは、バックフィリングのために cryo を使用して履歴データを効率的に抽出し、カスタム reth ExEx を通じてリアルタイムデータを取得し、Flink を使用してこのデータを処理および変換し、分析のために構造化データをリレーショナルデータベースに保存します。 このソリューションは、オンチェーンデータの規模と複雑さに対応できるブロックチェーンのインデックス作成と分析のための信頼性の高い基盤を提供し、ブロックチェーンデータから価値ある洞察を得るのに役立ちます。 これを拡張するには、以下を検討してください。 異なるプロトコルやトークンのための Flink アプリケーションの追加 データ可視化ダッシュボードの実装 特定のオンチェーンイベントに対するアラートの設定 予測分析のための機械学習モデルとの統合 本記事は、2025 年 11 月 25 日に公開された Building a blockchain indexer on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 著者について Christoph Niemann Christoph は Dune Analytics の Web3 ソリューションエンジニアであり、AWS の元シニアブロックチェーンアーキテクトです。ブロックチェーンを扱い、ブロックチェーンデータのソリューションを開発する深い経験を持っています。 Arvind Raghu Arvind は AWS の Web3 および Confidential Compute のグローバル責任者です。顧客やパートナーと緊密に連携して Web3 および Confidential Computing ソリューションを開発するアーキテクトと GTM ストラテジストのチームを率いています。 Forrest Colyer Forrest は AWS で Web3 と分散型テクノロジーを専門とするシニアスペシャリストソリューションアーキテクトです。ブロックチェーンなどのテクノロジーに依存するワークロードを構築する際に、業界を超えた顧客に対して深い技術的ガイダンスを提供し、また Web3 分野の ISV とのパートナーシップの構築にも取り組んでいます。

デジタル資産決済により、迅速かつ低コストのピアツーピア取引が可能になります。 ブロックチェーンベースの決済システムは、従来の決済方法で企業が直面する主要な課題に対処します。 これには、高い処理手数料、キャッシュフローに影響を与える決済遅延、業務に影響を及ぼす複雑な国際取引などが含まれます。 この投稿では、ブロックチェーンベースのデジタル資産決済システムがどのようにコストと遅延を削減できるかを説明します。 USDC 、 PYUSD 、 USDG などのステーブルコインを例として、AWS 上でサーバーレス決済システムを構築する方法を紹介します。 このソリューションは、従来の決済方法に代わる低コストでスケーラブル、かつ分散型の選択肢を提供します。 実装は GitHub リポジトリ で公開されています。 この投稿は、デジタル資産決済ソリューションの技術的な概要を示すものであり、法的助言や規制上のガイダンスを意図したものではありません。 法的コンプライアンス、検証、確認の要件は管轄区域によって異なる場合があり、読者ご自身の責任です。 この投稿で説明されている決済ソリューションを実装または使用する前に、ご自身でデューデリジェンスを実施してください。 ブロックチェーンベースの決済のメリット デジタル資産決済を導入する企業には、魅力的なメリットがあります。 コスト管理 決済処理のオーバーヘッドの削減 決済効率 ブロックチェーンの確認後に資金にアクセスできます。正確なタイミングはネットワークによって異なります (数秒から数分) グローバル展開 複数の仲介業者を介さずに国境を越えた取引を実行し、為替手数料を排除します トランザクションの可視性 オンチェーン検証による完全なトランザクションの透明性により、監査の効率化 デジタル資産決済は、さまざまなステークホルダーにメリットをもたらします。 加盟店 – 高速で低手数料の決済により、EC （イーコマース）を効率化します。 金融機関 – 決済時間を短縮し、国際送金や資金管理を促進します。 共通のメリット – 通貨交換と決済処理の手数料を最小化します。 最終的に、デジタル資産決済は、マーチャントや金融機関が技術革新を進め、コストを最小化し、新たな機会を引き出すのに役立ちます。 ソリューション概要 このソリューションにより、企業は Ethereum を含む Ethereum Virtual Machine (EVM) 互換ネットワーク全体で、デジタル資産による消費者からの支払いを、完全な自動化と安全な資金処理で受け入れることができます。 テストネットとメインネット環境の両方に対応しています。 リポジトリ では、デジタル資産支払いソリューションをデプロイして使用する手順を順を追って説明しています。 このソリューションの主な機能は以下の通りです。 デジタル資産決済ソリューションの 3 つのコアコンポーネントについて、さらに詳しく見ていきましょう。 請求書ジェネレーター このコンポーネントを使用すると、請求書を生成し、顧客から直接支払いを受け付けることができます。 請求書ジェネレーターは以下の機能を提供します: 確定的な請求書生成 – 請求書ジェネレーターは、請求書とブロックチェーンアドレスの 1 対 1 のマッピングを容易にします。これにより、各支払いが対応する請求書に正しく紐付けられることが保証されます。このシステムは、 アトミックカウンター を Amazon DynamoDB に保存してウォレットインデックスを維持し、高い同時実行シナリオでもスレッドセーフなアドレス生成を維持します。 効率的な鍵管理 – BIP32 / BIP44 は、階層的決定性鍵導出関数を使用して、 AWS Secrets Manager に保存された単一のプライマリシードから多数の鍵パスを生成し、複数のアカウントとアドレスの構造化された管理を可能にします。 UI ですぐに使える出力 – 請求書ジェネレーターは、請求書の入金アドレスと Data URL 形式の Base64 エンコードされた QR コードの両方を返します。これは HTML の タグに直接埋め込むことができます。 セキュリティとプライバシーの強化 – 各顧客は一意の 1 回限りの支払いアドレスを受け取ります。これにより、アドレスの再利用を防ぎ、パブリックブロックチェーン上でユーザーのプライバシーを保護することができます。 簡素化された会計処理 – 合理化された追跡により、会計と監査が容易になります。 定期支払いのシナリオでは、安定した顧客識別子から支払いアドレスを導出するようにソリューションを拡張できます。 これにより、各顧客に対して一貫したウォレットアドレスが作成され、定期支払いが合理化され、顧客の許可リスト登録プロセスが簡素化されます。 支払いの自動検出 「The Watcher」は、自動的な更新情報とイベント駆動型通知による支払い状況の監視を可能にします。 自動支払い検出コンポーネントは、以下の機能を提供します。 最適化されたデータベースクエリ – DynamoDB グローバルセカンダリインデックス ( status-index ) を使用して、 pending 状態の請求書のみをクエリします。これにより、請求書の総量が増加してもクエリのパフォーマンスが維持され、DynamoDB の読み取り消費量が大幅に削減されます。 リアルタイム残高検証 – ETH および ERC-20 トークンの残高を請求書の金額と照合して検証します。 自動ステータス更新 – 十分な支払いが検出されると、請求書を自動的に paid としてマークします。(デフォルトでは、このソリューションはファイナリティやリオーグを考慮しません。より強力な保証が必要な場合は、Watcher の eth_getBalance に finalized ブロックタグを渡すことができます。) 即時通知 – 支払い確認時に Amazon SNS を通じて加盟店への通知をトリガーします。 資金照合 請求書の支払いを受け取った後、資金は安全な管理のために指定された財務ウォレット (できれば高度にセキュアなコールドウォレット) に自動的に移動されます。 これにより、数分以内にオフラインで支払いが安全に処理され、加盟店が選択したウォレットへの資金集約のための監査可能なメカニズムがサポートされます。 ファンド照合プロセスは、以下の機能を提供します。 DynamoDB Streams によるトリガー – フィルタリングされたストリームトリガーを通じて確認済みの支払いを検出します (ステータスが paid )。ネットワークの混雑や一時的なブロックチェーンの問題に対処するための組み込みメカニズムを備えています。 ガスの最適化 – コスト効率の高いトランザクションのために、ネットワークのガス価格を動的に計算します。 ガス補充メカニズム – 専用のホットウォレット「ガスタンク」が、ネットワークのネイティブトークン (例: ETH) の準備金を保持します。これは、ERC-20 インボイスを補充するためだけに使用され、最小限のガス料金で コールドストレージの金庫に集約できるようにします。 安全な転送 – 秘密鍵はメモリ内で決定論的に導出され、保存されません。これらは個々のインボイスからの転送を実行するために使用されます。これは Lambda 内で行われ、AWS は オペレーターによるアクセスはありません 。 ステータスの更新 – 正常に完了すると、インボイスのステータスを swept に更新します。 次の図は、ソリューションのアーキテクチャを示しています。 このアーキテクチャは、サーバーレスなデジタル資産決済処理の PoC （ Proof of Concept ）を目的としており、本番環境で使用できる状態ではありません。 セキュリティ、信頼性、コンプライアンス、監査可能性に関する本番環境の基準を満たすには、追加の機能強化が必要です。 以下のフローの各ステップの番号は、Ethereum ネットワーク上でのステーブルコイン決済を示しており、上記のアーキテクチャ図の番号に対応しています。 加盟店は、 Amazon API Gateway が提供する /create-invoice REST API へのリクエストを通じて、ステーブルコインのインボイスを作成します。これは API キーを使用して保護されています。 AWS Lambda 関数である Invoice Generator がトリガーされ、 AWS Secrets Manager からニーモニック シードフレーズ を取得します。シードフレーズは、インボイスに対応するキーペアを作成 (および復元) するために必要です。 Invoice Generator は Amazon DynamoDB のアトミックカウンターをインクリメントします。アトミックカウンターの値はインデックスを表します。これはシードフレーズと共に使用され、特定の支払いに対する 階層的決定性 (HD) ウォレットアドレスを決定論的に導出します。 Invoice Generator Lambda 関数は新しいインボイスを作成し、 status: pending として DynamoDB に保存します。データは AWS Key Management Service (AWS KMS) を使用して保管時に自動的に暗号化されます。 前のステップで生成された QR コードには、送金先アドレス、通貨、金額がエンコードされており、加盟店に返されます。加盟店は QR コードを顧客と共有します。顧客は、入金アドレスに適切な金額の資金を送信することで、ステーブルコインの支払いを行います。 Amazon EventBridge スケジュールを通じて、Watcher という Lambda 関数が毎分トリガーされます。Watcher は DynamoDB から保留中のインボイスを取得し、提供された RPC エンドポイントを通じて行われた支払いを確認します。支払いが到着した場合、インボイスを paid に更新します。 Watcher Lambda 関数は、 Amazon Simple Notification Service (Amazon SNS) を使用して、加盟店に支払い確認を送信します。 CryptoInvoices データベースで支払いが検出されると (ステータスが paid に遷移すると)、 Amazon DynamoDB Streams を使用してイベントが発行されます。これにより Lambda Sweeper 関数がトリガーされます。 Sweeper 関数は資金の集約トランザクションに必要なガスを計算し、これが ERC20 インボイスであるため Eth をリクエストします。 十分な Eth が利用可能になると、Sweeper 関数はインボイスに関連付けられたトークンをオフラインの保管用ウォレットに送信します。Sweeper 関数は、HD ウォレットのシードフレーズをリクエストし、トランザクションに署名するための秘密鍵を導出することでこれを行います。その後、インボイスは CryptoInvoices データベースで swept としてマークされます。資金の集約プロセス中にエラーが発生した場合、失敗がログに記録され、最大 3 回の再試行が行われます。 加盟店は、API Gateway を使用して公開された REST エンドポイントを通じてインボイスを管理できます (インボイスの現在のステータスを表示したり、保留中のインボイスをキャンセルしたりできます)。 支払い、支払い監視、資金の回収フローの詳細な図解については、 GitHub リポジトリ を参照してください。 まとめ このサーバーレスソリューションは、AWS 上でデジタル資産決済を処理するための安全で効率的、かつコスト効率の高いシステムを提供します。 AWS のサービスとブロックチェーン技術を活用することで、組織は決済処理コストを削減し、資金へのより迅速なアクセスを実現し、キャッシュフローを向上させ、グローバルに事業を展開できます。 本記事は、2025 年 10 月 2 日に公開された Processing digital asset payments on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 GitHub で完全なコードを確認し、AWS 上で安全なサーバーレスデジタル資産決済ソリューションの構築を始めましょう。 著者について Simon Goldberg Simon は、AWS のブロックチェーン/Web3 スペシャリストソリューションアーキテクトです。仕事以外では、音楽制作、読書、クライミング、テニス、ハイキング、コンサート鑑賞、Web3 テクノロジーの研究を楽しんでいます。 David Dornseifer David は、AWS のブロックチェーンおよびコンフィデンシャルコンピュートアーキテクトです。彼は、お客様がエンドツーエンドのブロックチェーンおよびコンフィデンシャルコンピュートソリューションの設計、開発、スケーリングを支援することに注力しています。主な専門分野は、デジタル資産の保管と鍵管理ソリューションです。