AWS WAFにAI traffic monetizationという機能が追加されました。サイトやAPIにアクセスしてくるAIボットに対して、コンテンツの利用料を課金できる機能です。AIクローラへの対応はこれまで「許可するか、ブロックするか」の二択でしたが、そこに「対価を受け取って通す」という第三の道が加わりました。
機能そのものの仕組み、つまりコンテンツを持つ側がどう収益化を設定するかは、本記事では深追いしません。それらの内容はこちらが参考になります。
本記事で触れたいのは、その裏側です。コンテンツを守る側の話は、同時にコンテンツを読みにいく側、つまり自律エージェントを動かす側の話でもあります。長らく予約されたまま使われてこなかったHTTPステータスコード402が実用化されたことは、エージェントがWebを読むときのコスト構造が変わりはじめたという意味を持つでしょう。決済プロトコルそのものは、x402の仕様から読み解いていきます。
公式の発表はこちらです。
AIによって成り立たなくなった「読ませて回収する」ビジネスモデル
前提として、AIボットのトラフィックは無視できない規模になっています。公式ブログによれば、多くのコンテンツ提供者にとってAIボットがWebトラフィックの過半を占め、AI専用クローラは前年比で3倍以上に増えているとされています。
従来の検索エンジンのクローラは、インデックスを作って検索結果から読者を送り返してくれました。一方でAIボットは、同じコンテンツを要約や回答の生成に使い、元のサイトへ読者をほとんど返しません。提供者はトラフィックを捌くインフラ費用を負担しながら、ページビューも広告表示も得られません。この非対称が課金という発想の出発点です。
ここまでが、コンテンツを守る側から見た景色です。
402を返すMonetizeの中身と二つの制約
まず、課金の仕組みを要点だけ押さえます。
課金はAWS WAFのBot Control機能の一部として動きます。ボットと判定されたリクエストに対して、6種類のアクション（Monetize / Allow / Block / Count / CAPTCHA / Challenge）のうちMonetizeを割り当てると、支払いのないリクエストにはHTTP 402 Payment Requiredが返ります。402とともに、リクエストあたりの価格（USDC建て）、受け付ける決済ネットワーク（BaseとSolana）、支払い先アドレスなどを、プログラムが解釈できる形で記したマニフェストが返ります。この形式がx402で、プログラム同士の決済のためにCoinbaseが提唱したオープンプロトコルです。
押さえておきたい制約は二つあります。一つは、このMonetizeアクションがAmazon CloudFrontに紐づくWeb ACLでのみ使えることです。もう一つは、決済の検証とオンチェーンでの確定をリクエストパスの中で同期的に行うことです。公式ドキュメントはこの処理をsynchronouslyと明記していて、確定を待ってからコンテンツを返します。その分のレイテンシは支払いを伴うリクエストにだけ生じ、支払いのないリクエストには影響しません。
ソースから読み解くx402の決済の中身
x402はCoinbaseが提唱したもので、現在はx402 Foundationにリポジトリが移管され、オープン標準として開発が続いています。仕様も実装もGitHubで公開されているので、AWS公式の説明だけでは見えない部分を直接読めます。公式ドキュメントが伝えるのは流れの全体像までで、その先は仕様にしかありません。だからこそソースを読んで、402に何が入り、どう署名し、どこへ送るのかを順に確かめていきます。
402の中身は支払い条件のマニフェスト
402 Payment Requiredが返るとき、x402 v2では支払い条件がPAYMENT-REQUIREDヘッダにBase64で載ります。これをデコードすると、仕様がPaymentRequiredと呼ぶオブジェクトが得られます。提供者が受け入れる支払い方法の配列（accepts）を持ち、配列の一つひとつが、どのスキームで、どのネットワークの、どの通貨を、いくら、どの宛先に送れば通すか、を宣言しています。
その中身は、たとえばこういうものです。これは、v2仕様の例からaccepts配列の一要素を抜き出したものです。
{
"scheme": "exact",
"network": "eip155:84532",
"amount": "10000",
"asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
"payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"maxTimeoutSeconds": 60,
"extra": { "name": "USDC", "version": "2" }
}
各フィールドの意味は次のとおりです。
- scheme（支払い方式、たとえばexact）
- network（eip155:84532のようなチェーンID）
- amount（金額。最小単位の整数で表す。例の10000はUSDCで0.01ドル）
- asset（通貨のコントラクトアドレス）
- payTo（受け取りアドレス）
- maxTimeoutSeconds（支払いの有効期限）
払う側はこの配列から自分が払える条件を一つ選んで支払いを組み立てます。複数のネットワークや通貨が並ぶこともあり、どれを選ぶかは払う側に委ねられています。
支払いは署名された認可であって送金そのものではない
払う側が作るのはPaymentPayloadというオブジェクトで、中身は署名（signature）と認可（authorization）です。認可には、誰から（from）、誰へ（to）、いくら（value）、いつからいつまで有効か（validAfter / validBefore）、再利用を防ぐ使い捨ての値（nonce）が入ります。
{
"signature": "0x2d6a7588...148b571c",
"authorization": {
"from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
"to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"value": "10000",
"validAfter": "1740672089",
"validBefore": "1740672154",
"nonce": "0xf3746613...62f13480"
}
}
値はいずれもv2仕様にある例です。先行するaccepts（支払い要求）に対して、払う側はこう署名して返します。これは送金の実行ではなく、この条件でこの額を引き落としてよいという署名付きの許可です。EIP-3009のtransferWithAuthorizationを使う仕組みで、額と有効期限と使い捨てnonceが署名で縛られている点が、後の予算設計に効いてきます。
ヘッダ名はv1とv2で変わっている
x402にはv1とv2があり、支払いをやり取りするヘッダの扱いはv2で変わっています。実装に触れるなら知っておきたい違いです。
| 用途 | v1 | v2 |
|---|---|---|
| 402の支払い要求 | レスポンスボディ | PAYMENT-REQUIRED |
| クライアントの支払い | X-PAYMENT | PAYMENT-SIGNATURE |
| 決済結果 | X-PAYMENT-RESPONSE | PAYMENT-RESPONSE |
v1では支払い要求だけがレスポンスボディで返り、支払いと結果はヘッダでした。v2は三つともヘッダに整理され、仕様もx402のプロトコル情報はすべてヘッダで運び、レスポンスボディはサーバ実装の裁量とすると明記しています。AWSのドキュメントがpayment-signatureヘッダと書いているのは、v2に準拠しているからです。
facilitatorは検証と決済を肩代わりするが資金は持たない
提供者がオンチェーンの検証や送金を自前で実装しなくて済むように、facilitatorという仲介サービスが用意されています。役割は二つあり、verify（署名された支払いが条件を満たすか検証する）とsettle（ブロックチェーンに送って確定を待つ）です。仕様が明記しているのは、facilitatorは資金を保持しない、つまりカストディアンではないという点です。署名された認可を受け取り、検証と実行を代行するだけで、Solana・Polygon・Baseなど複数のネットワークでfacilitatorがすでに本番稼働しています。
一連の流れを払う側の視点で短く追うと、以下のとおりです。
- リクエストを送る
- 402とPAYMENT-REQUIREDが返る
- acceptsから条件を一つ選ぶ
- 署名した認可をPAYMENT-SIGNATUREに載せて再送する
- 提供者がfacilitatorのverifyで検証し、コンテンツを取得し、settleで決済を確定し、PAYMENT-RESPONSEを付けて返す
AWS WAFが受け持っているのは、この流れの提供者側です。
そのsettleでAWS WAFが使うのは、Coinbase Developer Platformが提供するx402 facilitatorです。なお、オリジンが4xxや5xxを返したリクエストには決済が走らず、払う側に課金は発生しません。
エージェントのランタイムが決済主体になる
402が返るのは、それを受け取って支払い、もう一度取りに行くエージェントがいることを前提にした仕組みです。
先ほど追ったフローを、払う側のエージェントランタイムはほぼ自律的に回せます。402を受け取り、署名した認可をPAYMENT-SIGNATUREに載せて再送するところまでをランタイムが代行し、提供者側の検証から決済の確定までが、同期的にリクエストの処理経路の中で完結します。
これは、エージェントを動かす側にとって新しい設計上の論点です。これまで、自律エージェントがWebをfetchするコストは、ほぼ自分側のトークン消費と通信費だけでした。これからは、fetchした先が有料化されていれば、コンテンツそのものに対価が発生する可能性があります。エージェントのランタイムが、HTTPクライアントであると同時に決済主体になる、という構造変化です。
自前でエージェントを回している場合、この変化は新しい設計判断を二つ持ち込みます。fetch先が402を返したときに失敗として扱うのか支払って通すのか、そして払うならどのウォレットで、いくらまでを自動で許すのかという点です。認証経路の選択が設計判断になったのと同じ構図が、決済経路でも発生します。
「自分は大量にクロールしているわけではないので関係ない話だ」と感じるかもしれませんが、これは規模ではなく前提の問題だと言えます。一度でも402を返す先が出てくれば、エージェントの設計に「402をどう扱うか」という分岐が生まれます。有料化する提供者が増えれば、fetchの失敗理由に402が混ざることは避けられません。諦めるのか、支払うのか、迂回するのかを後から慌てて決めるより、想定だけ持っておくほうが落ち着いて設計できます。
払う側のハーネスに必要な三つの観点
仕様が分かると、払う側の設計観点が具体的になります。観点は大きく三つです。
一つ目は、402を受けた後の分岐をどこに置くかです。エージェントのHTTPクライアントが402を受け取ったとき、それを失敗として上に返すのか、その場で支払い経路に入るのかという点です。fetchのすぐ内側で自動的に払ってしまえば、エージェントは402を意識せずに済みますが、どこでいくら払ったかが見えにくくなります。逆に、エージェントが次の行動を決める計画層まで持ってくるとしたら、支払いの判断をタスクの文脈で下せますが、呼び出し経路のあちこちに分岐が散らばります。認証トークンの付与をどの層でやるかと同じ判断が、決済でも立ち上がります。
二つ目は、予算の上限をどう縛るかです。ここでx402の署名の作りが効いてきます。認可にはvalue（金額）とvalidBefore（有効期限）とnonce（使い捨て）が含まれ、署名で固定されます。つまり一回の支払いごとに、上限額と期限を署名の時点で決められます。ハーネス側に「一つのリクエストあたりいくらまで」「一つのタスクあたり累計いくらまで」「この時刻を過ぎたら無効」というルールを持たせ、それを認可の生成に落とし込めば、暴走したエージェントが青天井で払い続ける事態を仕組みで防げます。上限をコードのどこかにハードコードするのではなく、署名する認可そのものに埋め込めるのが、この設計の強みです。
三つ目は、本番に出す前の検証です。決済が絡む処理は、いきなり実通貨を流すわけにはいきません。x402にはテスト用のネットワーク（前述の例でも登場したeip155:84532はBase Sepoliaというテストネット）があります。これは、402が返り、認可が作られ、検証される一連の流れを、実資産を動かさずに通せます。決済機能を実装に乗せる前段として、ここを一度通しておくかどうかで、初回の本番投入の安心感が変わります。
設計段階では、この三つの観点を考えます。402をどの層で受けるか、上限を誰のウォレットでいくらに切るか、テストネットで通すか。実装はまだ要りません。前提が変わったことを認識し、判断の置き場所だけ決めておけば、払う先が増えても慌てずに済みます。
robots.txtでは塞げなかった隙間
もう一つ、払う側から見ておきたいのがrobots.txtとの関係です。robots.txtはあくまで紳士協定で、従わないクローラを止める強制力はありませんでした。許可とブロックの中間がなく、ブロックすればAI検索経由で読者を連れてくる「ありがたいボット」まで締め出してしまいます。この隙間を、402という強制力のある仕組みが埋めにきています。
払う側の視点で言い換えると、これまで「読みにいけば読めた」Webの一部が、「読みにいくと対価を求められる」Webに変わりうるということです。公式ブログによれば、AWS WAFは650種類以上のAIボットやエージェントを分類し、暗号署名や公開されたIPレンジで確認できる検証済みと、そうでない未検証に分けます。検証済みの検索クローラは無料で通し、未検証のクローラには高い単価を設定する、といった出し分けが提供者側でできます。つまり、自身のエージェントが「未検証」に分類されると、相対的に高い対価を求められる側に回る可能性があります。
ステーブルコイン決済の現在地
次に気になるのは決済手段です。現時点の支払いがUSDCなどのステーブルコインを軸にしているのは事実です。受け取り側もBase / Solanaといったネットワークのウォレットアドレスを指定する形で、AWSは決済を仲介せず手数料も取りません。受け取ったステーブルコインを法定通貨に換えて銀行口座へ動かす部分は、公式には自分で管理するか、ウォレットプロバイダ側に任せる形とされています。AWS WAFが受け持つのは支払いを受け取るところまでで、その先の換金や記帳は自前です。既存の経理フローにそのまま組み込める段階ではありません。
ただ、当面の実務で効いてくるのは別の点です。本番に出す前に、実通貨を流さずテストモードで支払いフローを試せることです。決済が絡む機能を実装に乗せる前段として、ここはありがたい設計だと言えます。
有料化へ向かう業界の動き
似た仕組みは、CloudflareのPay Per Crawlが先行していました。AWSが続いたことで、課金の仕組みがクラウドごとに分かれ、各社が自社への囲い込みに使うのでは、という見方も出ます。
ただ、二社がそろって同じ方向、つまり402を使ったプログラム同士の決済に動いたことは、各社ごとの一手というより、Webの読み取りが有料化しうる方向に業界が傾きはじめた兆候と見るのが自然だと思います。x402というプロトコル自体は特定クラウドに閉じていません。だとすれば論点は「どのクラウドを使うか」ではなく、「どのエージェントランタイムが先にこの決済フローに標準対応するか」に移っていくのではないでしょうか。AWS WAFの新機能として見れば一社の話ですが、エージェントにWebを読ませて払う側に立つと、もっと広い業界の変化の一部に見えてきます。
さらにソースを読むと、x402が見据えている範囲はWebの読み取りより広いことが分かります。x402のトランスポートはHTTPだけでなく、MCP（Model Context Protocol）とA2A（Agent-to-Agent Protocol）にも定義されています。MCPトランスポートでは、エージェントが有料のツールを呼び出すと結果がいったんエラーとして返り、支払いを載せて呼び直すと実行されます。A2Aトランスポートでは、あるエージェントが別のエージェントのサービスに支払います。仕様の言葉を借りれば、エージェントが自分のサービスをオンチェーン決済で収益化する、という想定です。
つまりAWS WAFのAI課金は、HTTPでコンテンツを読むという一つの面にx402を実装したものにすぎません。その下には、エージェントがツールを呼ぶときも、エージェント同士が取引するときも、同じ402と同じ署名で払うという決済レイヤーの構想が広がっています。402が呼び戻されたのは、Webの有料化のためというより、エージェントが経済主体としてふるまうための共通の支払い口を用意するためだと読むほうが、理にかなっているでしょう。
どこから手をつけるか
コンテンツを持つ側であれば、最初の一歩は課金設定ではなく、AIトラフィック分析のダッシュボードで自サイトに来ているAIボットの比率を見ることでしょう。CloudFront配信のサイトを持っているなら、まず現状を可視化し、ブロック・課金・許可のどれが見合うかを判断する材料を集めます。いきなりMonetizeを有効化する必要はありません。
エージェントを動かす側であれば、いま自身のエージェントがfetchしている先のうち、402を返しはじめそうなコンテンツがあるかを見ておきたいところです。そのうえで、支払いを自動で出すのか出さないのか、出すなら上限をどこに置くのかという方針を、ハーネスの設計メモに一行だけでも残しておきます。実装はまだ要りません。前提が変わったことを認識しておくだけで、後の判断が変わります。
402という、長く眠っていたステータスコードが、エージェント経済の決済レイヤーとして起き上がってきました。コンテンツを守る話として読むこともできますが、同じ出来事は、エージェントにWebを読ませる側にとって、コストの前提が一つ増えたという話でもあります。どちらの側に立つかで景色は変わりますが、Webの読み取りがタダではなくなりうる、という入り口にいることは、どちらの側からも同じに見えます。
Discussion