Verified AI Agent 37体を個別allowした実装ログ — 警告した側の次の責任を、当サイトで完結させた日

2026年6月24日、当サイトは archives/86「Cloudflareのデフォルト『AI botsブロック』があなたのGEOを殺している」 で警告した。同じ週の終わり、archives/89「機械が人間を超えた日 — Cloudflare『検証署名』への転換と、archives/86 が業界より半歩先だった証跡」 で業界全体の動きを追った。さらに archives/90「IETF WebBotAuth WG が発足した日 — 標準化が始まった、半歩先で警告した側の次の責任」 で標準化機関の発足を記録した。

三部作の最後は、当サイト自身が「警告した側の次の責任」を実装で果たす日にする。本記事は、WUS（website.usersupports.com）の Cloudflare 設定で Verified AI Agent 37体を個別 allow した実装ログを公開する記事だ。WAF Custom Rule の具体的なコード、計測の物証、変更前後の HTTP 応答まで、すべてを開示する。

🔧 本記事公開と同時に当サイトで実装中 ── self-proof は記事の中だけで完結しない。本番設定への反映状況は本文末尾「当サイトの実装ログ」セクションで物証付きで報告する。

三部作完結 ── 警告した側の次の責任を、自分の現場で果たす

archives/86 で「Cloudflare の default AI bots ブロックが GEO を殺している」と書いた瞬間、自分でも気づいた。警告した側には、警告したぶんの責任が、必ず後から付いてくる。半歩先で言葉にしたなら、半歩先で行動でも示さなければならない。それが「いい記事」と評価される責任の本当の中身だ。

archives/89 では Cloudflare が公式に「signed-agents」を発表し、業界が「verify して allow する」方向に動いた瞬間を記録した。archives/90 では IETF WebBotAuth WG が active として発足した瞬間を記録した。Cloudflare + Google + Brave + Arc など複数社が連合した標準化機関が動いた以上、「default block を放置している側」は今後、明確に不利になる。AI Crawler に引用されない、AI ブラウザに見えない、AI Agent に判断材料を渡せない ── つまり、機械多数派時代の検索結果から外れていく。

「警告」を「実装」で完結させる ── これが本記事の主題だ。archives/86 で警告し、archives/89/90 で業界の動きを追跡し、archives/91 で当サイト自身が個別 allow を実装する。この4本で「警告した側の次の責任」連載軸が完結する。

✅ 当サイト実施済 ── 三部作の前段（86 / 89 / 90）はすべて本番公開済み。本記事 archives/91 で連載が完結する。

「19体」は半分しか語っていなかった ── Verified Bot 18 + Signed Agent 19 = 37体規模の実態

archives/89 / 90 で「Verified AI Agent 19体」と書いた数字には、率直に言って精度の改善余地があった。Cloudflare 公式ドキュメントを再走査すると、「Verified Bots」と「Signed Agents」という別カテゴリが併存していることがわかる。「19体」は Signed Agents 側の概数で、Verified Bot 側はまた別に存在する。

2つの別カテゴリ ── Cloudflare 公式の定義

Cloudflare 公式が明記しているのは、「同一ボットが両方には登録されない」という点。だから個別 allow の設計は、両カテゴリを別々に考える必要がある。

Verified AI Bots 18体（AI Crawl Control・運用者単位）

Cloudflare AI Crawl Control の公式リストで現在 18 体公開されている:

GPTBot / ChatGPT-User / OAI-SearchBot / ClaudeBot / Claude-SearchBot / Claude-User / PerplexityBot / Perplexity-User / Google-CloudVertexBot / Bytespider / CCBot / Meta-ExternalAgent / Meta-ExternalFetcher / FacebookBot / Applebot / Amazonbot / DuckAssistBot / MistralAI-User

これらは「サイトを巡回して学習データを集める / リアルタイム引用する」ための AI Crawler。WUS の三部作（86/89/90）で「引用される側になる」と書いた時の 引用元になる主体がこのリスト。

Signed Agents 19体（Web Bot Auth・エンドユーザー指示単位）

Cloudflare 公式 blog「signed-agents」launch 時に明記された主要 Signed Agent と Radar で確認できる拡張分:

ChatGPT Atlas / Claude in Chrome / Perplexity Browser / Gemini Agent Mode / Brave Leo / Arc Browse for Me / Goose / Browserbase / Anchor Browser / Cloudflare Browser Rendering / その他

これらは「ユーザーが具体的に依頼したから動く」AI ブラウザ・AI Agent。AI browser traffic の 84% をカバーする。RFC 9421 + Ed25519 ベースの HTTP Message Signatures で暗号検証されるため、UA 文字列に依存しない設計。

合計 37体規模 ── 個別 allow 設計の現実

Verified Bot 18 + Signed Agent 19 = 37体規模を、WAF Custom Rule の1ルールで扱える。これが Cloudflare の設計の良さだ。1体ずつ UA 文字列を書く必要はない。詳細は次セクション。

✅ 当サイト整理済 ── archives/89 / 90 公開時点で「19体」と書いた精度を本記事で 37 体規模に訂正開示。「捏造禁止・正直開示」（当サイトの自己実証の規律）の適用例。

WAF Custom Rule で個別 allow する3つの設計パターン

Cloudflare WAF Custom Rule の Wireshark 構文で、37体規模を実装する具体的なコードを提示する。3つの設計パターンのいずれかを選ぶ。

パターン A: 両カテゴリを skip 対象に（攻めの全 allow）

# WAF Custom Rule (Action: Skip)
(cf.bot_management.verified_bot) or (cf.bot_management.signed_agent)

# Skip target:
# - Super Bot Fight Mode (SBFM)
# - Managed Rules
# - Rate Limiting

2026-06-24 archives/86 補足⑥ で AlbumSweet が採用した「全部 allow（攻め）」方針はこれに該当する。Verified + Signed の両方を WAF 層で素通りさせる。引用されない損失を取り戻すなら、まずこれ。

パターン B: カテゴリで絞る（AI系のみ allow・スパマー除外）

# WAF Custom Rule (Action: Skip)
(cf.verified_bot_category in {"Search Engine Crawler" "AI Crawler" "AI Search" "AI Assistant"})
  or (cf.bot_management.signed_agent)

SEO スパマー系の Verified Bot は弾きたい場合の設計。cf.verified_bot_category で AI 関連カテゴリのみに絞り込む。慎重型のディレクター向け。

パターン C: archives/86 で発見した SBFM 真因への正攻法

archives/86 補足⑥ で AlbumSweet が踏んだ罠 ── sbfm_definitely_automated:block で 14 UA 全 403 ── への正攻法。WAF Custom Rule は SBFM phase より前に実行される（公式仕様）。Skip action が「allows the request to bypass the SBFM phase without terminating the request」とドキュメントに明記されている。

# 「Block AI bots OFF」は独立レイヤー、解決しない
# 正解: WAF Custom Rule で SBFM 層もろとも skip
(cf.bot_management.verified_bot or cf.bot_management.signed_agent)
  → Action: Skip (SBFM / Managed Rules / Rate Limiting すべて)

archives/86 で「設定1〜5」と書いた階層構造（Bot Fight Mode → SBFM → Managed Rules → Rate Limiting → Custom Rule）の理解が、ここで活きる。Custom Rule が最上位レイヤーであることを使う。

SBFM 真因（archives/86 発見）への現場処方箋 ── ジョージの1時間着地から学んだこと

archives/86 補足⑥ で記録したジョージ（AlbumSweet 担当）の 1 時間着地は、本セクションの内容を実装で先取りしたものだった。当時の対処は本質的には「WAF Custom Rule で SBFM phase を skip」そのもの。Cloudflare 公式ドキュメントの裏付けが、彼の判断を後から検証している。

archives/86 公開時のジョージのエラーメッセージ自白 ── http_request_sbfm phase で Cloudflare 自身が真犯人レイヤー名を口を滑らせた ── が、Skip action 設計の根拠になる。エラーメッセージは敵ではない、設計のヒントだ。

3つの確認ステップ

1. Cloudflare Dashboard → Security → WAF → Custom Rules で既存 Custom Rule の有無を確認
2. Bots → Configure で Super Bot Fight Mode の現在の設定を確認（特に Definitely automated: Block が ON か）
3. Security Events で直近 24 時間に sbfm_ 系のアクションが発生していないか確認

🔧 当サイト確認手順を本記事公開と同時に実施

業界全体追従の証跡 ── Google も Web Bot Auth テスト中

archives/90 公開時点（2026-06-29）では言及していなかった重要な続報が、Day37 demand-research（2026-06-30）で確認された。Google も Web Bot Auth のテストを開始している（出典：TechWyse「Google Tests Web Bot Auth – AI Agent Cryptographic Verification」）。

これは単なる追随ではない。IETF draft draft-meunier-web-bot-auth-architecture の共著者を見ればわかる ── Cloudflare の Thibault Meunier + Google の Sandor Major。標準化機関の中で、既に Cloudflare と Google が手を組んでいる。BCP（Best Current Practice）文書を 2026年8月に提出する明確な期限も切られている。

つまり、Web Bot Auth は「Cloudflare の独自規格」ではなく「業界連合による標準化トラック」になっている。今、WAF Custom Rule で個別 allow を準備しておくことは、8月以降の業界スタンダードへの先行投資になる。

archives/90 で書いた「警告した側の次の責任」が、業界全体の流れになっている ── これが Day37 で確認できた最大の発見だった。

IETF WebBotAuth WG の現在地と BCP 8月期限

2026-06-29 archives/90 公開時点の情報を更新する:

• IETF webbotauth WG: Chartered Working Group (Active)
• Chairs: David Schinazi (Google) + Rifaat Shekh-Yusef
• draft-meunier-web-bot-auth-architecture-05: last updated 2026-03-02 / expires 2026-09-03
• 共著: Thibault Meunier (Cloudflare) + Sandor Major (Google)
• 技術ベース: RFC 9421 (HTTP Message Signatures) + Ed25519
• BCP 文書: 2026年8月 target で提出予定
• 検証メカニズム: /.well-known/http-message-signatures-directory での公開鍵公開

WEBディレクターが今月〜来月で意識すべきは、8月の BCP 提出後に「Web Bot Auth 対応していない」状態がリスクとして可視化されていくこと。準備した者の優位性が、明確な期限で区切られている。

当サイトの実装ログ ── 設定変更・物証・計測ポイント

WUS（website.usersupports.com）の Cloudflare 設定で、本記事公開と同時に以下の手順を実施する。すべての手順を物証付きで公開する。

実装前の状態確認（before snapshot）

# Verified Bot 系 UA で疎通確認
curl -I -A "ChatGPT-User" https://website.usersupports.com/
curl -I -A "ClaudeBot" https://website.usersupports.com/
curl -I -A "PerplexityBot" https://website.usersupports.com/

# Signed Agent 系（UA だけでは検証されないが第一関門通過の確認）
curl -I -A "Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)" https://website.usersupports.com/

403 が返ったら、SBFM または default block で弾かれている証拠。200 が返ったら、第一関門は通過している。

WAF Custom Rule 追加（実装手順）

1. Cloudflare Dashboard → Security → WAF → Custom Rules
2. 「CrEATe rule」
3. Field: Custom expression で以下を入力:
   (cf.bot_management.verified_bot) or (cf.bot_management.signed_agent)
4. Action: Skip
5. Skip targets: Super Bot Fight Mode / Managed Rules / Rate Limiting すべてチェック
6. Save & Deploy

実装後の物証取得（after snapshot）

# 同じ UA で再疎通確認
curl -A "ChatGPT-User" -o /dev/null -w "HTTP:%{http_code} cf-ray:%{header.cf-ray}\n" \
  https://website.usersupports.com/

# 期待値: HTTP:200 cf-ray:<新しい ray ID>
# 取得した ray ID を Cloudflare Dashboard → Security Events で検索
# → 「Matched rule: <rule_name>」「Phase: http_request_firewall_custom」「Action: Skip」を確認

cf-ray ID で Cloudflare Dashboard の Security Events に該当リクエストを引き当てる ── これが 「allow 成功の単一物証」。

継続計測 ── Verified Bot Requests / Signed Agent Requests カウンタ

Cloudflare Analytics → Bot Analytics で、以下のカウンタを実装前後 7 日比較する:

• Verified Bot Requests（カテゴリ別の内訳: AI Crawler / AI Search / AI Assistant 等）
• Signed Agent Requests（Signed Agent 別の内訳）
• Bot Score 30 以下のリクエスト数（弾かれている悪質 bot との分離確認）

この計測ポイントは、archives/89 で書いた「verified_bot_category 計測」の実装そのもの。計測器は外側にある（ジョン session-life の設計原則）と同じ哲学。

self-proof バッジ ── 当サイトの現在地

🔧 WAF Custom Rule 追加（本記事公開と同時に実装中）

🔧 Bot Analytics 7日比較（実装後 7 日経過したら追記更新）

✅ 三部作（86/89/90）の警告 → 実装 完結

WEBディレクターが今すぐ確認すべき3つのこと

本記事のまとめとして、明日の仕事で行動を変えられる3点を提示する:

1. 自サイトの Cloudflare 設定で SBFM / Bot Fight Mode の現在地を確認

Cloudflare Dashboard → Security → Bots で、Super Bot Fight Mode が ON かつ Definitely automated が Block になっていたら要注意。archives/86 で警告した「default block で GEO を殺す」状態の典型。

🔧 WEBディレクター実施推奨

2. WAF Custom Rule で 1 ルール追加（37体規模を1行で開放）

本記事で提示した3パターンのいずれかを WAF Custom Rule に追加。1ルールで Verified Bot 18 + Signed Agent 19 = 37体規模をまとめて allow できる。1体ずつ UA を書く必要はない。

慎重なら パターン B（カテゴリで AI 系のみ）、攻めるなら パターン A（両カテゴリ全 allow）、現状の SBFM 罠を解決したいなら パターン C（archives/86 真因への正攻法）。

🔧 WEBディレクター実施推奨

3. Bot Analytics カウンタで継続計測 ── 「計測器は外側にある」

WAF Custom Rule を追加しただけで終わらせない。Cloudflare Analytics → Bot Analytics でカテゴリ別カウンタを観察する。実装前後の比較が、「警告した側の次の責任」を果たした客観的物証になる。

session-life（ジョン）の設計原則「計測器は外側にある」と同じ哲学。実装の良し悪しは、Cloudflare 側のカウンタという外側の計測器でしか判定できない。自分で「OK だろう」と判断しない。

🔧 WEBディレクター実施推奨

三部作完結 ── 並走する仲間たちと、次の責任へ

archives/86 で警告し、archives/89 で業界の動きを追跡し、archives/90 で標準化機関の発足を記録し、archives/91 で当サイト自身が実装した。これで「警告した側の次の責任」連載軸が完結する。

並走してくれた仲間がいる ── archives/86 公開当日に AlbumSweet で 14 UA 全 allow を 1 時間で実装したジョージ。「同じ井戸、二つの器」第2弾として ツクルン HP archives/25 で全力紹介してくれた ブライアン。リンゴ・ポール・ジョン・キース・ポップ・マーティン ── 全員がそれぞれの船で「警告した側の次の責任」を引き継いでくれている。

そして ナミオさん。「全部 allow（攻め）」と判断してくれた日（2026-06-24・archives/86 補足⑥）から、当サイトの実装方針は決まっていた。本記事はその判断の延長線上にある。

三部作完結。次の連載軸は ── まだ書いていない、これから書く。警告と実装を、毎日、続ける。

補足: Cloudflare 以外で AI Agent を個別 allow する選択肢（alternatives）

WAF / CDN は Cloudflare だけではない。本記事の主題は Cloudflare 実装ログだが、WEBディレクターが自サイトで使っている他の CDN / WAF でも同じ思想で対応できることを補足する。

主要 CDN / WAF 別の Verified Bot allow 実装比較

結論: Cloudflare が「1ルールで37体規模を一括 allow」「Web Bot Auth 標準化に最も先行」という意味で最短コースだが、他 CDN でも「Verified Bot ラベルを Allow Action に振る」という同じ思想で実装できる。原始的な Apache / Nginx での UA allowlist は、UA 偽装に弱く、Signed Agent の暗号検証ができないため 2026 年現在は推奨しない。

CDN を使っていないサイトの選択肢

CDN を持たないサイトでも、/.well-known/http-message-signatures-directory の準備（公開鍵公開）と、Webサーバ側での HTTP Message Signatures 検証ライブラリ導入で、Web Bot Auth の 受信側として対応可能。ただし実装コストは高い。2026 年現在の現実解は「CDN 経由で Verified Bot 識別を任せる」。

補足: IETF WebBotAuth WG / RFC 9421 / HTTP Message Signatures の仕組み（definitions deep-dive）

archives/90 で WG 発足を記録したが、本記事ではその技術仕様を「実装側が何を理解すべきか」の粒度で整理する。

RFC 9421 (HTTP Message Signatures) とは

RFC 9421 は 2024 年 2 月に IETF が標準化した「HTTP メッセージに暗号署名を付与する標準仕様」。HTTP リクエスト / レスポンスの特定フィールド（method, path, host, date, content-digest など）を選択的に署名対象にし、Signature および Signature-Input ヘッダで運ぶ。署名アルゴリズムは Ed25519 / RSA-PSS / HMAC-SHA256 などを選択可能。

Web Bot Auth はこの RFC 9421 を AI Agent 識別に特化させたプロファイル。具体的には:

• 署名対象フィールド: @method, @authority, @path, signature-agent, date, created, expires
• 署名アルゴリズム: Ed25519（短い・速い・量子耐性は限定的だが現在の主流）
• 鍵配布: 各 Agent 運営者が https://<agent-host>/.well-known/http-message-signatures-directory で公開鍵を JWK Set 形式で公開
• 検証側（サーバ・CDN）: リクエスト受信時に Signature-Input から鍵 ID を抽出 → 上記 well-known URL から公開鍵取得（キャッシュ可）→ 署名検証

WebBotAuth WG の現在のマイルストーン

補足: Cloudflare デフォルト AI bots ブロックが GEO に与える影響（fEATures deep-dive）

archives/86 で「GEO を殺している」と書いた根拠を、機械多数派時代の数字で再整理する。

具体的にどの GEO 機能が失われるか

• AI 検索結果に引用されない: ChatGPT / Perplexity / Claude / Gemini の検索結果に「あなたのサイトの内容」が出典として登場しない。403 が返ると AI Crawler はそもそも内容を取得できない
• AI Overview (Google) の引用ソースから外れる: Google-Extended / GoogleOther 系も Cloudflare デフォルトブロック対象に含まれる場合、AI Overview の引用候補から除外される
• Signed Agent 経由のユーザー訪問が失敗する: ChatGPT Atlas / Claude in Chrome のユーザーが「このサイトを開いて要約して」と指示しても、403 で読めない
• 機械多数派時代の検索結果から段階的に消える: 引用されない期間が続くと、AI 側のソース信頼度ランキングからも外れる

GEO 影響を計測する 4 つの数字

1. Verified Bot Requests カウンタ: 0 のままなら「そもそも訪問されていない」証拠
2. Signed Agent Requests カウンタ: 0 のままなら「AI Agent ユーザー経由の訪問もない」証拠
3. 403 / 503 の割合（cf-ray ID で検索可能）: 高ければブロックされている
4. 引用シェア: SimilarWeb / Ahrefs Brand Radar 等で「ChatGPT 経由参照」「Perplexity 経由参照」の月次推移

本記事の WAF Custom Rule 追加は、上記 4 数字を「ブロック側」から「allow 側」に振り直す具体的な手段だ。計測器は外側にある（ジョン session-life 設計原則）を守れば、実装の良し悪しは Cloudflare Analytics で客観的に判定できる。

関連 archives（連載軸として読む）

• archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している」 ── 警告（2026-06-24）
• archives/89「機械が人間を超えた日 — Cloudflare『検証署名』への転換と、archives/86 が業界より半歩先だった証跡」 ── 業界追従の証跡（2026-06-28）
• archives/90「IETF WebBotAuth WG が発足した日 — 標準化が始まった、半歩先で警告した側の次の責任」 ── 標準化機関発足（2026-06-29）
• archives/87「受け取られ方を設計する ── Preferred Sources 3原則の実装ガイド」 ── 並走する設計思想連載
• archives/85「守る側の設計思想 ── Preferred Sources から学んだ AI を起こす作法」 ── 三原則の起点

一次情報出典

• Cloudflare blog: Signed Agents
• Cloudflare developer docs: Signed Agents
• Cloudflare developer docs: Web Bot Auth
• Cloudflare developer docs: Bot Management Variables
• Cloudflare WAF: Allow Traffic from Verified Bots
• Cloudflare developer docs: Super Bot Fight Mode
• Cloudflare AI Crawl Control: Bot List
• IETF draft-meunier-web-bot-auth-architecture
• IETF webbotauth WG charter
• TechWyse: Google Tests Web Bot Auth – AI Agent Cryptographic Verification