トップ > AWS WAF > AI クローラに HTTP 402 を返して課金する。AWS WAF 新機能の仕組み

AI クローラに HTTP 402 を返して課金する。AWS WAF 新機能の仕組み

AWS WAF
記事タイトルとURLをコピーする

AI クローラに HTTP 402 を返して課金する。AWS WAF 新機能の仕組み

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

2026 年 6 月、AWS から次の発表がありました。

aws.amazon.com

AWS WAF に AI traffic monetization という機能が追加された、というものです。ひとことで言うと、サイトや API にアクセスしてくる AI ボット・エージェントに対して、コンテンツの利用料を課金できる機能です。

これまで、AI クローラへの対応といえば「アクセスを許可するか、ブロックするか」の二択でした。AI traffic monetization は、そこに「課金して通す」という第三の選択肢を持ち込みます。しかも追加の決済サーバーを自前で立てる必要はなく、CloudFront のエッジで、支払いを付けた 1 リクエストの中で検証から配信までが完結します。

この記事では、次のことを整理します。

  • なぜ今この機能が登場したのか
  • どういう仕組みで課金が成立するのか
  • 相手によって値段を変える料金設計の考え方
  • 実際に使うときの前提と注意点

背景: AI クローラとコンテンツの「ただ乗り」問題

生成 AI の普及で、Web コンテンツを大量に取得していくボットが急増しました。学習データの収集、RAG（検索拡張生成）のための参照、要約や回答生成のためのリアルタイムアクセスなど、目的はさまざまです。

コンテンツを持つ側からすると、これは悩ましい状況です。アクセスは増えてサーバー負荷はかかるのに、人間の読者のように広告を見てくれるわけでも、リンクをたどって回遊してくれるわけでもありません。価値あるコンテンツが、対価なしに吸い上げられていく。いわゆる「ただ乗り」の構図です。

では、どう対応してきたか。選択肢は大きく二つでした。

  • robots.txt でクロールを遠慮してもらう
  • WAF やボット対策でアクセスをブロックする

ところが robots.txt はあくまで紳士協定で、従わないクローラを止める強制力はありません。一方でブロックしてしまうと、AI 検索経由で読者を連れてきてくれる「ありがたいボット」まで締め出してしまいます。許可とブロックの中間がなかったわけです。

AI traffic monetization が提示するのは、その中間にあたる「対価を受け取ったうえでアクセスを通す」という道です。

ここで再び脚光を浴びるのが、HTTP ステータスコードの 402 Payment Required です。402 は HTTP の仕様上ずっと前から「将来の課金のために予約」されていたものの、長らく実用例のない、いわば欠番に近いコードでした。これを machine-to-machine（機械同士）の決済に使えるよう体系化したのが x402 という、Coinbase が提唱したオープンプロトコルです。AWS WAF の AI traffic monetization は、この x402 を土台にしています。

docs.x402.org

仕組み: 1 リクエストで課金が完結する流れ

具体的なシナリオで追ってみます。あるニュースサイトが記事ページを課金対象に設定していて、そこへ AI エージェントが記事を取りに来た、という場面です。

おおまかな流れは次の 8 ステップです。

  1. リクエスト: AI エージェントが、CloudFront 上の保護されたページにアクセスする
  2. ルール評価: AWS WAF が優先度順にルールを評価する。課金対象（Monetize アクション）にマッチし、かつ有効な支払い情報が付いていなければ、HTTP 402 を返す
  3. 支払い要求（Payment Required Challenge）: 402 レスポンスに支払いの指示が機械可読な形で含まれる
  4. 支払い認可: エージェントがウォレットの秘密鍵（またはサーバーウォレットの API）で支払いに署名し、payment-signature ヘッダーを付けて同じリクエストを再送する
  5. 検証: AWS WAF がエッジで支払いを検証する。残高や認可が不十分なら 402 を返し、コンテンツは渡さない
  6. コンテンツ取得: 検証が通ると、オリジンへのリクエストが許可される
  7. 決済（Settlement）: オリジンが正常応答（2xx）を返したら、Coinbase Developer Platform の x402 facilitator を通じてブロックチェーン上で決済が行われる
  8. 応答: 決済確認の情報（payment-response ヘッダー）を添えて、コンテンツがエージェントに返される

ポイントは、支払いを付けたあとの検証から応答までが、1 リクエストのサイクルの中で同期的に進むことです。エージェント側から見れば「アクセスしたら 402 が返ってきたので、支払い情報を付けてもう一度リクエストする」だけで、コンテンツが手に入ります。

402 レスポンスには、次のような情報が機械可読な形で入っています。

  • リクエストあたりのコンテンツ価格（USDC 建て）
  • 受け付ける決済ネットワーク（Base、Solana）
  • 支払い先のウォレットアドレス（payTo）
  • 最大タイムアウト
  • 支払いスキーム

エージェント側は、この内容を読み取って「いくら払えばいいか」「どこへ払えばいいか」を理解し、自動で支払いを組み立てられる、というわけです。

取りこぼしを防ぐ設計

課金が絡むと「払ったのにコンテンツが来なかった」「同じ内容に二重課金された」といった事故が心配になりますが、ここはいくつかの仕組みで守られています。

  • オリジンが失敗したら課金しない: オリジンが 4xx や 5xx を返した場合、決済はスキップされ、クライアントに課金は発生しません
  • 冪等性（べきとうせい）: x402 の payment-identifier という拡張を使うと、最大 15 分間は二重課金なしでリクエストをリトライできます（クライアントがこの拡張に対応している場合）
  • リプレイ保護: 支払い認可は 1 回限りで使い捨てです。payment-identifier なしで同じ支払いヘッダーを再利用しようとすると、改めて 402 が返ります

課金できるリソースは CloudFront 経由で配信するものなら幅広く、Web ページや記事、API エンドポイント、データフィード、メディアアセット、構造化データセットなどが対象になります。

料金設計: 相手によって値段を変えられる

この機能の面白いところは、一律料金ではなく「相手や用途によって値段を変えられる」点です。

価格は二段構えで決まります。

  • 基本価格（base price）: web ACL の設定（MonetizationConfig）に書く、リクエストあたりの基準額。最小は 1 リクエストあたり $0.001 USDC で、小数点以下 3 桁まで指定できます
  • 価格倍率（PriceMultiplier）: 個々の課金ルールに付ける 1〜100 の整数。実際の価格は「基本価格 × 倍率」になります

たとえば基本価格を $0.001 に設定し、あるルールに倍率 3 を付ければ、そのルールにマッチしたリクエストの価格は $0.003 になります。

これを「相手の意図（intent）」と組み合わせると、次のような価格戦略が描けます。

  • 参照トラフィックを連れてきてくれる検証済みの AI 検索クローラ → 無料（Allow）または低価格
  • RAG や要約を行う既知のエージェント → 標準価格
  • 素性のわからない未検証のエージェント → 高めの価格
  • 学習目的のクローラ → ブロック、あるいはプレミアム価格

「歓迎したい相手は安く、警戒したい相手は高く」という、コンテンツ提供者にとって自然な料金設計が組めるわけです。

人間のアクセスには 402 を返さない

ここで一つ大事な注意点があります。Monetize アクションはあくまで自動化された AI エージェント向けで、人間のブラウザに 402 を返してはいけません。人間のブラウザは x402 形式の支払い指示を解釈できず、支払いも完了できないため、402 が返ると実質的にアクセス不能になってしまうからです。

これを避けるため、AWS は Bot Control のラベルと組み合わせる設計を推奨しています。まずトラフィックがボットかどうかを Bot Control で判定し、ボットと分類されたものだけに Monetize アクションを適用する、という流れです。

設定イメージは次のようになります。awswaf:managed:aws:bot-control:bot というラベルが付いたリクエスト（＝ボットと判定されたもの）だけを課金対象にしています。

{
  "Name": "MonetizeBotTrafficOnly",
  "Priority": 5,
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "LABEL",
      "Key": "awswaf:managed:aws:bot-control:bot"
    }
  },
  "Action": {
    "Monetize": {}
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "MonetizeBotTrafficOnly",
    "SampledRequestsEnabled": true
  }
}

このルールでは、ラベルを持たない人間のアクセスはマッチせず素通りして次のルールへ進み、ボットと判定されたものだけが 402 を受け取ります。検証済みクローラは無料で通し、未検証ボットには高い倍率で課金する、といった形でルールを分けて精緻化していくこともできます。

セットアップ: 始めるための前提と手順

実際に始める際の前提と手順を、公式ドキュメントの流れに沿って整理します。

docs.aws.amazon.com

前提として、次の三つが必要です。

  • CloudFront ディストリビューションに紐づいた AWS WAF の web ACL（新しいコンソールでは protection pack と表示されます）
  • 支払いを受け取るための USDC ウォレットアドレス（Base、Solana、またはその両方）
  • （推奨）Bot Control の有効化（AI ボットを識別・分類するため）

セットアップは、おおまかに次の流れです。

  1. Bot Control を有効化する（まだなら web ACL にマネージドルールグループを追加）
  2. CloudFront（Global）リージョンで web ACL を作成し、CloudFront ディストリビューションに関連付ける
  3. MonetizationConfig を設定する

MonetizationConfig は、受け付ける決済ネットワークと基本価格を定義する設定です。構造はこのようになっています。

{
  "MonetizationConfig": {
    "CryptoConfig": {
      "PaymentNetworks": [
        {
          "Chain": "BASE",
          "WalletAddress": "0x1234567890abcdef1234567890abcdef12345678",
          "Prices": [ { "Amount": "0.001", "Currency": "USDC" } ]
        },
        {
          "Chain": "SOLANA",
          "WalletAddress": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
          "Prices": [ { "Amount": "0.001", "Currency": "USDC" } ]
        }
      ]
    }
  }
}

対応する決済ネットワークは次のとおりです。本番用とテスト用がそれぞれ用意されています。

Chain ネットワーク 通貨 用途
BASE Base mainnet（EVM L2） USDC 本番
SOLANA Solana mainnet USDC 本番
BASE_SEPOLIA Base Sepolia testnet USDC テストモード
SOLANA_DEVNET Solana Devnet USDC テストモード

いきなり本番のお金を動かすのは怖い、という場合のために、テストモード（CurrencyMode: TEST）が用意されています。テストモードでは Base Sepolia や Solana Devnet といったテストネットを使い、実際の USDC ではなくテスト用の資金（Circle の Testnet Faucet などで入手）を使って、本番と同じ支払いフローを丸ごと検証できます。価格設定が意図どおりか、ウォレットに正しく着金するか、ログや分析に正しく記録されるかを確認したうえで、CurrencyMode を REAL に切り替えて本番運用へ移ります。

知っておきたい注意点

一通り紹介してきましたが、導入を検討するなら押さえておきたいポイントがいくつかあります。

レイテンシ

支払い処理が走るリクエストには、認可の検証とオンチェーン決済のぶん、数秒の追加レイテンシが乗ります。実際の遅延はブロックチェーンの混雑状況に左右されます。ただし、これは課金が発生するリクエストだけの話で、課金ルールにマッチしないリクエストや支払い署名なしのリクエストには影響しません。

決済通貨

支払いは USDC（ステーブルコイン）で行われ、Coinbase Developer Platform の x402 facilitator が決済を担います。資金はクライアントのウォレットから設定済みのウォレットへ直接精算され、AWS は資金フローの当事者にはなりません。利用にあたっては Coinbase の利用規約への同意が必要です。なお公式発表では、Stripe と Machine Payments Protocol（MPP）への対応も近日予定とされています。

判定は確率的

どのリクエストが AI ボットかの分類は、行動シグナルやリスクベースの手法による確率的な判定で、すべてを完璧に見分けられるわけではありません。だからこそ、本番でいきなり課金を有効にする前に、テストモードで意図どおりの結果になるか検証することが推奨されています。

追加料金

AI traffic monetization 自体には、AWS WAF の標準料金を超える追加料金はかかりません。ただし、前提として推奨される Bot Control のマネージドルールグループには別途利用料が発生する点には注意が必要です。

提供範囲

CloudFront のエッジロケーションで利用でき、web ACL が CloudFront に関連付けられている環境であればグローバルに使えます。

まとめ

AI traffic monetization は、「AI ボットのアクセスを許可するかブロックするか」という二択に、「課金して通す」という第三の選択肢を加える機能です。鍵になっているのは、長く眠っていた HTTP 402 と、それを機械同士の決済として実用化した x402 プロトコルでした。

メディアや API 提供者、データを持つ事業者にとっては、AI トラフィックを「コストやリスク」としてだけでなく「収益源」として捉え直すきっかけになりそうです。最小 $0.001 という細かい単位で、相手によって値段を変えられる柔軟さも、Web の新しい経済圏の入り口を感じさせます。

詳細は AWS WAF Developer Guide を参照してください。

docs.aws.amazon.com

針生 泰有(執筆記事の一覧)

2026 Japan AWS Top Engineer（AI/ML Data Engineer）
サーバーワークスでAI活用推進を担当