英語版で読む
技術 約10分で読めます

AWS WAFのAIボット課金は個人ブログの収益になるのか

AWS AWS WAF CloudFront AI x402 ブログ運営
いけさん目次

AWSが2026年6月15日に、AWS WAFのAIトラフィック収益化を発表した。CloudFrontの前段にあるAWS WAFでAIボットやAIエージェントを判定し、対象パスへ来たリクエストに 402 Payment Required を返す。対応しているエージェントはx402でUSDC支払いを送り、支払いが検証されるとコンテンツを取得できる。

個人ブログに金が入るかで見ると、答えは「入る仕組みにはなっているが、今すぐ個人ブログの収益源として期待するには条件がきつい」。AWSの説明では支払いは設定したウォレットへ直接入る。AWSはコンテンツ売上から手数料を取らない。ただし標準のAWS WAF料金とBot Control料金は請求されるし、支払うのはx402対応のエージェントだけだ。払わないボット、対応していないボット、身元を偽るスクレイパーは従来通りブロックやレート制限へ回す。

このサイトはVercel配信なので、AWS WAFのこの機能をそのまま使える状態ではない。使うならCloudFrontを前段に置くか、配信をAWS側へ寄せる。そこまでして回収できるかは、AIボットの実リクエスト数と、実際に支払ってくれるエージェントの割合に左右される。

何が発表されたか

AWS WAFのAIトラフィック収益化は、Bot Controlの分類結果を使ってAIボットへのアクセスを分ける機能だ。AWS News Blogでは、GPTBot、Claude-Web、Perplexity-Botなど650以上のAIボット/エージェントを分類し、確認済みと未確認の区分へ分けると説明している。

ルール側では、エージェント区分ごとに以下のアクションを選ぶ。

アクション挙動
Monetizex402の支払い指示を含む402を返す
Allow無料で通す
Block拒否する
Count通してログだけ取る
CAPTCHA人間確認を出す
Challengeブラウザ確認を走らせる

Monetize は人間向けのペイウォールではない。AWSのDeveloper Guideにも、通常のブラウザや人間ユーザーはこの支払いフローを処理できないと書かれている。間違って人間のページビューに当てると、ただのアクセス不能になる。

リクエストの流れはこうなる。

sequenceDiagram
    participant Bot as AIボット/エージェント
    participant WAF as AWS WAF
    participant Pay as x402決済代行
    participant Origin as オリジン
    participant Wallet as 公開者ウォレット

    Bot->>WAF: GET /articles/example
    WAF->>WAF: Bot Controlラベルで判定
    WAF-->>Bot: 402 Payment Required + x402価格マニフェスト
    Bot->>WAF: payment-signature付きで再リクエスト
    WAF->>Pay: 支払い検証
    Pay-->>WAF: 検証OK
    WAF->>Origin: コンテンツ取得
    Origin-->>WAF: 2xx response
    Pay->>Wallet: USDC決済
    WAF-->>Bot: コンテンツ + payment-response

AWSの資料では、本番の支払いネットワークとしてBaseとSolanaが挙がっている。テストモードではBase SepoliaやSolana Devnetを使える。最低価格は1リクエストあたり0.001 USDC。価格はルールごとの倍率で変えられる。

個人にも入金されるのか

入金先は設定したウォレットだ。AWSのDeveloper Guideでは、支払いは直接ウォレットへ決済され、AWSは資金の流れの当事者ではないと説明している。AWS News Blogでも、AWSはコンテンツ収益に手数料を取らないと書いている。

なので、技術的には個人でも受け取れる。Coinbaseのアカウントやセルフカストディのウォレットを使い、AWS WAFの課金設定にウォレットアドレスと価格を入れる形になる。

ただし、個人ブログで「入金される」と「収益になる」は別だ。

条件個人ブログでの詰まり
CloudFront + AWS WAFが前段にあるVercelやCloudflare Pages運用だと構成変更が入る
Bot ControlでAIボットを分類できる未分類ボットや偽装ボットは取りこぼす
ボット側がx402に対応している非対応ボットは支払えない
ボット運営者が支払いを許可している価格を見て撤退することがある
USDCを受け取れるウォレット管理、換金、税務記録を処理する
WAF/Bot Control費用を超える小規模サイトではここが一番きつい

個人の技術ブログだと、PVの多くは検索、人間のSNS流入、RSS、たまにAIクローラという構成になりやすい。広告のように人間PVへ広く乗る収益ではなく、支払い可能なエージェントに当たった時だけ発生する従量課金だ。

料金の最低ライン

AWS WAF料金ページの例では、CloudFrontに紐づくWeb ACLは月5ドル、ルールや管理ルールグループは月1ドル単位、リクエストは100万件あたり0.60ドルで計算されている。Bot ControlはWeb ACLごとに月10ドルの基本料金があり、Common Bot Controlは月1000万リクエストまで追加のリクエスト課金なし、超過分は100万件あたり1ドルの例が載っている。

ざっくり、AIボット課金だけのために最小構成を置くなら、固定費として少なくとも次のような数字を見る。

項目月額の目安
Web ACL5ドル
Bot Control基本料金10ドル
マネージドルールグループや自前ルール1ドル以上
WAFリクエスト課金100万リクエストあたり0.60ドル
CloudFrontやログ別途

最低価格の0.001 USDCで計算すると、15ドルを回収するだけで月15,000件の支払い済みリクエストを通すことになる。35ドルなら35,000件。これは「AIボットリクエスト数」ではなく「x402に対応し、価格に同意し、支払いまで完了したリクエスト数」だ。

単価を0.01 USDCにすれば、15ドルの回収は1,500件の支払い済みリクエストで済む。ただ、単価を上げるほどボット側の支払い拒否も増える。技術記事のHTMLを1ページ読むために1セントを払うエージェントがどれだけいるかは、まだ実績を見ないと分からない。

この時点で、個人ブログの収益化というより、出版社や有料データ提供者の「ボット向けライセンス販売」に近い。

払わないボットには効かない

x402は支払いプロトコルなので、相手が従うことが前提になる。悪意のあるスクレイパーや未対応ボットに「課金」を強制して売上に変えるものではない。AWS WAFが処理するのは、分類、402の提示、支払い検証、通す/止める判断までだ。

そのため、実運用では次の3層になる。

相手現実的な扱い
確認済み検索クローラ検索流入を残したいならAllowか低価格
x402対応AIエージェントMonetizeの対象
不明・未対応・偽装ボットBlock、レート制限、Challenge、ログ監視

AWSの価格設定ページにも、ボット分類は複数の検出技術に基づくが確率的で、すべてのボットアクセスを正しく分類できるとは限らないと書かれている。この注記は課金設計に入れる。課金できるボットだけを見ていると、課金できない大量アクセスのコストを見落とす。

CloudFront前提で構成変更が増える

今回のMonetizeアクションは、CloudFrontディストリビューションに関連付けたAWS WAF Web ACL専用だ。リージョナルWeb ACLでは使えない。

S3 + CloudFrontで静的サイトを置いているなら導入しやすい。既にCloudFrontを前段にしていて、WAF Bot Controlも使っているメディアなら、コンソール上の設定追加で試しやすい。

VercelやNetlifyで動かしている個人ブログでは追加作業が増える。CloudFrontをさらに前段に置くと、キャッシュ、リダイレクト、ヘッダー、画像最適化、プレビュー環境、ログ、証明書、障害時の切り分けを扱うことになる。Astroの静的出力だけなら移せるが、既存のVercel連携、デプロイプレビュー、vercel.json のredirectsをそのまま持っていけるわけではない。

このサイトの場合も、AIボットから月数ドルを拾えるかもしれないという理由だけでCloudFrontへ寄せると、固定費と運用変更のほうが大きくなりやすい。先にやるなら、AIボットのアクセス量を測るところからだ。

先に測るならAI Traffic Analysis

AWSは2026年5月5日にAI Traffic Analysisダッシュボードも出している。AWS WAF Bot ControlでAIボット/エージェントの活動を見て、上位パス、ボット名、組織、検証状態、CloudWatchメトリクスを出す機能だ。

個人ブログで判断するなら、いきなりMonetizeではなく、まずCountとダッシュボードで見るほうが現実的だ。

見る数字はこのあたり。

見るもの判断
月間AIボットリクエスト課金母数の規模
上位パス有料にしてもよいページか
確認済み/未確認の比率AllowとMonetizeを分けられるか
帯域とオリジン負荷そもそもコスト対策が必要か
参照流入のあるボットか検索流入を捨てていないか

月に数百〜数千リクエストしかないなら、課金よりブロックとrobots.txtの整備で十分だ。月に数十万以上のAIボットアクセスがあり、特定のAPI、データ、アーカイブ、画像素材に集中しているなら、課金の検証候補になる。

このサイトでは、週3〜4回ほどトラフィック警告が来るが、ほぼGoogle関連ボットで、他のボットが同じ強さで叩いてくることは少ない。こういうサイトだと、AWS WAFの課金機能はさらに使いどころが狭い。Google関連ボットを雑に止めると検索インデックスや検索流入にも影響するし、課金対象にしてもGoogle側がx402で支払うとは限らない。一番払ってほしい相手がGoogleでも、個人サイト側では「ログを取る」「許可する範囲を分ける」「明らかに不要なアクセスだけ絞る」くらいの運用になりやすい。

RSLは支払い条件ではなく利用条件

AWSのDeveloper Guideは、x402で伝わるのは「いくら払うか」で、コンテンツの利用条件そのものはRSLで伝えると説明している。RSLはReally Simple Licensingの略で、AIエージェント向けに機械可読なライセンス条件を示す仕様だ。

発見方法としては、robots.txt、HTTP Linkヘッダー、HTMLの<link rel="license">、RSS/Atomモジュールが挙がっている。CloudFrontならレスポンスヘッダーポリシーでLinkヘッダーを付けられる。

x402とRSLは役割が違う。

役割使うもの
支払い要求x402
価格AWS WAF課金設定
支払い検証AWS WAF + x402決済代行
利用条件RSL
ボットの入口制御AWS WAF Bot Control

個人ブログでやるなら、支払いより先にRSLやrobots.txtで利用条件を明示するほうが導入コストは低い。強制力は限定的だが、サイトの意思表示としてはコストが低い。

CloudflareのPay Per Crawlとの違い

同じ文脈ではCloudflareのPay Per Crawlもある。CloudflareはAIクローラに対してAllow、Charge、Blockを選ぶ形で、2025年7月に非公開ベータとして発表している。Cloudflare寄りのサイトなら、こちらのほうが運用基盤を変えずに済むことがある。

ただし、どちらも「払うボットがいる」ことが前提だ。Cloudflareの説明でも、請求関係を持たないクローラをChargeにすると実質403になると書かれている。AWSのx402も、非対応クライアントには402を返すだけになる。

AWS版の特徴は、CloudFront + WAF + Bot Controlのルール評価にそのまま組み込まれることだ。Cloudflare版の特徴は、Cloudflare利用者には入口が近いこと。どちらも大規模な媒体運営者やデータ提供者なら導入対象になるが、個人ブログではまずトラフィック量の確認が先になる。

個人ブログでの判断

自分なら、個人ブログではすぐ導入しない。

自分のサイトでやるなら、この順番になる。

  1. robots.txt とAIクローラ向けポリシーを整える
  2. CDNやアクセスログでAIボットのリクエスト数を測る
  3. 人間流入を作るボットと、コストだけ使うボットを分ける
  4. コストだけ使うボットはブロックかレート制限
  5. 支払い済みリクエストが月数万件を超えそうならx402課金を検討する

AWS WAFの新機能は、AI企業と個別契約できない媒体運営者に「HTTP上で価格を提示する手段」を渡すものだ。個人のウォレットも入金先にできる。ただ、個人ブログで黒字にするには、CloudFront前提の構成変更、AWS WAF/Bot Controlの固定費、ウォレット運用、税務記録、支払い対応エージェントの少なさを全部処理することになる。

小さなブログでまず得られるものは収益より可視化だ。どのAIボットが、どの記事を、どれくらい読んでいるかを出せるなら、Allow、Block、Chargeの判断材料がそろう。

参考