WEBサイト
2026年6月、IETF（Internet Engineering Task Force）に webbotauth Working Group が正式に発足した。BoF（Birds of a FEATher）と呼ばれる議論段階から WG charter 承認を経て、Active な Chartered Working Group として動き始めたのである。出典: IETF webbotauth WG charter。
「Web Bot Authentication」というテーマがインターネット標準化の議題として正式に持ち上がった。これは、ボットがサイトに正体を名乗り、サイト側が暗号学的に検証する仕組み ── 言い換えれば 「機械が機械であることを名乗る作法」 を、世界の WEB が共通仕様として整える動きの始まりである。
当サイトは、archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している」（2026-06-24 公開）で「robots.txt 無関係のインフラ層ブロック」を警告し、archives/89「機械が人間を超えた日 — Cloudflare『検証署名』への転換と archives/86 が業界より半歩先だった証跡」（2026-06-28 公開）で IETF draft-meunier-web-bot-auth-architecture-05 を「正解」として提示した。
そして本記事 archives/90 は、その続きである。警告 → 業界追従 → 標準化機関 → 次の責任。 半歩先で警告した側には、半歩先で対応する責任がある ── archives/89 で骨に刻んだ通底テーマを、archives/90 で完結させる。標準化が動き始めた今、私たちは「個別 allow 設定の責任を果たす番」に立っている。
本記事では以下を整理する。
- IETF webbotauth WG が BoF から Chartered になるまでの 3 ステップ
- Chairs / Area Director / マイルストーンの正規ステータス
- 業界メディアが「W3C」と書いている誤認を一次情報源で正す
- draft-meunier-05 は何を定義しているか、なぜまだ Individual Submission なのか
- Cloudflare の「signed-agents」と Verified AI Agent 19 体の全リスト
- archives/86 → 89 → 90 三部作の self-proof 数字
- WEBディレクターが今週やる 3 つの設定確認
- 当サイトの Verified AI Agent 個別 allow ロードマップ
1. IETF webbotauth WG が発足した — BoF から Chartered までの 3 ステップ
「Working Group が発足した」と一言で書いても、IETF の標準化プロセスでは複数の段階を経る。webbotauth WG は次の順序で正式 WG になった。
Step 1: BoF Request の提出（Mark Nottingham, Fastly）
始まりは BoF request の提出である。BoF（Birds of a FEATher）は IETF の用語で、「新しい WG を作るべきか議論する場」を指す。webbotauth WG の BoF request は、Fastly の Mark Nottingham 氏によって提出された。BoF request の Datatracker URL は次の通りである。
Mark Nottingham 氏は HTTP の世界では著名な存在で、RFC 7234（HTTP Caching）や RFC 9110（HTTP Semantics）など、現代の Web を支える HTTP 仕様の編集者として知られる。その人物が「Web Bot Authentication を IETF で標準化すべき」と request を出した ── これ自体が、業界が問題の本気度を認識した証拠である。
Step 2: Bangkok side meeting → Madrid BoF (IETF 122) → 二次 side meeting
BoF request は提出後、すぐに WG charter になるわけではない。webbotauth WG の場合は次の 3 段階を踏んだ。
- Bangkok side meeting: IETF 122 開催前に Bangkok で開かれた side meeting で初期議論
- Madrid BoF (IETF 122): スペイン・マドリードで開催された IETF 122 における正式 BoF セッション
- 二次 side meeting: BoF の後で論点を絞る side meeting を追加開催
side meeting は IETF の用語で「正式セッションの外で関係者だけで集まる議論」を指す。BoF が「公開議論」だとすれば、side meeting は「叩き台を作る場」である。webbotauth WG は、この 3 段階を経て論点を整理し、Charter draft を磨いていった。
Step 3: WG charter 承認 → Chartered Working Group (Active) へ
議論が成熟した段階で、Charter draft が IESG（Internet Engineering Steering Group）に提出され、承認された。これによって webbotauth WG は Chartered Working Group (Active) に正式に移行した。
IETF の WG ステータスには Proposed / Chartered / Concluded などがあり、Chartered は「IESG の承認を経て、正式に標準化を進める権限を持った WG」を意味する。Active という属性は「現在活動中」を示す。つまり、webbotauth WG は「これから標準化仕様を作る権限を IETF から正式に与えられた」状態である。
WEBディレクターにとって、この 3 ステップが意味することはひとつである ── もう「噂レベルの動き」ではない。インターネット標準化機関が公式に「Web Bot Authentication」を仕様化する権限を委任した。これからは Chartered WG として draft を adopt し、Last Call を経て RFC（Request for Comments）として発行される道筋に乗る。
2. Chairs / Area Director / マイルストーン — 正規ステータスを読む
WG charter の中身を読むと、運営体制とスケジュールが明示されている。これは「いつまでに何が出来るか」を読者が予測するための一次情報である。
Chairs（議長）2 名
webbotauth WG の Chairs（議長）は次の 2 名である。
- David Schinazi(Google) ── QUIC や HTTP/3 関連の標準化で知られる
- Rifaat Shekh-Yusef ── OAuth / セキュリティトークン関連の長年の議長経験者
Chairs は WG の議事進行・コンセンサス形成・draft 採択判断の責任を負う。David Schinazi 氏が Google から、Rifaat Shekh-Yusef 氏がベンダ中立の立場から議長を務める構成は、特定ベンダの利害に偏らないバランスを意識した配置と読める。
Area Director（AD）と Area
- Area Director: Mike Bishop（HTTP/3 関連の AD として知られる）
- Area: Web and Internet Transport (WIT)
WIT Area は IETF の中で HTTP・Web Transport 関連を扱う Area で、QUIC・HTTP/3・HTTP/2 関連の WG が所属する。webbotauth WG が WIT Area に置かれたということは、「Web Bot Authentication は HTTP の延長線上の仕様」と位置づけられたことを意味する。OAuth や SAML のような上位の認証プロトコルとは別系統で、HTTP リクエストそのものに署名を載せる方式が中心になる、と読み取れる。
マイルストーン
WG charter には、達成目標日が明記される。webbotauth WG のマイルストーンは次の通りである。
| マイルストーン | 目標日 | 意味 |
|---|---|---|
| Standards Track 仕様の提出 | 2026-04-30 | 正式な標準仕様の draft 提出期限 |
| BCP (Best Current Practice) 文書の提出 | 2026-08-31 | 運用ベストプラクティスの draft 提出期限 |
出典: IETF webbotauth WG about page
このマイルストーンの読み方には注意が必要である。「目標日」であって「公開日」ではない。IETF の標準化プロセスでは、目標日を超えて draft が長期化することは珍しくない。ただし、Chartered WG として明示された日付があることは、運営の本気度を測るひとつの指標になる。
2026-04-30 の Standards Track draft 提出が予定されているということは、来春までに「draft-ietf-webbotauth-XXX-00」のような WG-adopted draft 番号を持つ仕様が IETF Datatracker に登場する見込みである。WEBディレクターは webbotauth WG documents ページ を 2026年4月頃に確認するとよい。
3. 業界メディアの「W3C」誤認を正す — archives/89 と同じ罠
本記事執筆中、当サイトは archives/89 で 1 度大きな訂正を経験した。demand-research 段階で「W3C Web Bot Auth specification」と書いてしまい、補強リサーチで IETF draft が正解であると判明、執筆段階で全面訂正した。
同じ誤認が、今も業界の二次ソースに残っている。例えば次のような記述である。
「W3C Web Bot Auth specification was finalized in May 2026...」
(複数のマーケティング・SEO 関連ブログで散見される定型文の例。原典は伏せる)
これは複数の誤りを含む。順に整理する。
誤り 1: W3C ではなく IETF
Web Bot Authentication の仕様化を進めているのは W3C ではなく IETF である。両者を混同しやすい理由は、どちらも Web 関連の標準化機関だからである。しかし役割は明確に異なる。
- W3C (World Wide Web Consortium): HTML・CSS・WebAssembly・WCAG など、ブラウザ側の API・UI 仕様を中心とする
- IETF (Internet Engineering Task Force): HTTP・TCP・TLS・QUIC など、トランスポート層・プロトコル層を中心とする
HTTP リクエストに署名を載せる方式は IETF の領分である。RFC 9421 (HTTP Message Signatures) が IETF で標準化されたのも同じ理由で、Web Bot Authentication もこの延長線上にある。
誤り 2: 「finalized」ではない
2026年6月時点で、webbotauth WG は Chartered になったばかりである。「仕様が finalized された」段階には到底ない。
IETF の標準化プロセスでは、draft が WG-adopted されてから WG Last Call → IETF Last Call → IESG approval → RFC publication という長い段階を経る。Chartered になったばかりの WG が、「May 2026 に仕様 finalized」と書かれることはありえない。これは事実誤認である。
誤り 3: 著者の取り違え
二次ソースには「Cloudflare が標準化を主導」とだけ書かれているものも多い。これも片面しか伝えていない。draft-meunier-web-bot-auth-architecture-05 の著者は次の 2 社共著 である。
- Thibault Meunier(Cloudflare)
- Sandor Major(Google)
出典: draft-meunier-web-bot-auth-architecture (IETF Datatracker)
Cloudflare 単独ではなく、Google との共著である。これは「業界連合で進めている」というニュアンスを示す重要な事実で、片方だけを書くと「特定ベンダの私案」と誤読されるリスクがある。
デマンドリサーチの結果は素材であり決定稿ではない
archives/89 執筆時に当サイトが学んだ規律は次の一文である。
demand-research の結果は素材であり、決定稿ではない。記事化前に補強リサーチで一次情報源を再確認する。
archives/89 では「W3C」を「IETF」に訂正し、その経緯を本文中で正直に開示した。archives/90 でも同じ規律を適用する。本節は、業界の二次ソースに残る「W3C」誤認を正面から指摘するために設けた。読者が他のメディアで「W3C Web Bot Auth」と読んだとき、本記事に戻って一次情報源を確認できるよう、Datatracker の URL を繰り返し明示する。
正解: IETF webbotauth WG + draft-meunier-web-bot-auth-architecture-05 + RFC 9421 HTTP Message Signatures + Ed25519 Public Key Cryptography。
4. draft-meunier-05 は何を定義しているか — Individual Submission の意味
draft-meunier-web-bot-auth-architecture-05（以下 draft-meunier-05）は、Web Bot Authentication のアーキテクチャを定義する個人提出 draft である。2026-03-02 に更新版 05 が提出された。
draft の正式情報
| 項目 | 値 |
|---|---|
| draft ID | draft-meunier-web-bot-auth-architecture-05 |
| 更新日 | 2026-03-02 |
| 著者 | Thibault Meunier (Cloudflare) + Sandor Major (Google) |
| ベース技術 | RFC 9421 (HTTP Message Signatures) + Ed25519 |
| ステータス | Individual Submission(WG-adopted ではない) |
出典: draft-meunier-web-bot-auth-architecture (IETF Datatracker)
「Individual Submission」と「WG-adopted」の違い ── 重要な区別
ここは多くの WEBディレクターが見落としやすい区別である。IETF の draft には大きく 2 種類ある。
- Individual Submission: 個人が提出した draft。WG の正式な仕様候補ではない。draft 名は「draft-著者名-トピック-番号」の形式
- WG Document: WG が正式に採択（adopt）した draft。draft 名は「draft-ietf-WG名-トピック-番号」の形式
draft-meunier-05 は「draft-meunier-...」と著者名から始まる。これは Individual Submission である。webbotauth WG が Chartered になったばかりで、まだ draft adoption の議論が行われている段階を意味する。
WG-adopted されると、draft 名は「draft-ietf-webbotauth-architecture-00」のように変わる。この変化は単なる名称変更ではなく、「IETF の標準化プロセスに正式に乗った」という意味を持つ。
従って、現時点で「IETF Web Bot Auth 仕様」を語るときは、次の言い方が正確である。
「Cloudflare と Google の Individual Submission として draft-meunier-web-bot-auth-architecture-05 が提出されている。これをベースに、新設された IETF webbotauth WG で標準仕様の検討が始まる」
「draft は提出されている」「WG は発足した」「両者はまだ正式に結合していない」── この 3 点セットが、2026年6月時点の正確なステータスである。
技術的中身: RFC 9421 + Ed25519
draft-meunier-05 が依拠する技術は、すでに RFC 化されている。
RFC 9421 (HTTP Message Signatures)
RFC 9421 は 2024年2月に発行された IETF Standards Track の仕様で、HTTP リクエスト・レスポンスのヘッダや本文に対して暗号学的署名を載せる方式を定義する。draft-meunier-05 はこの RFC 9421 を「ボットがサイトに対して自身の正体を証明する」用途に特化させて運用する。
具体的には、ボットは次のヘッダを HTTP リクエストに付与する。
Signature-Input: 署名対象の項目リスト（ヘッダ名・メソッド・URI 等）Signature: 実際の署名値（Base64 エンコード）Signature-Agent: 署名鍵を発行したエージェント情報（Web Bot Auth 拡張）
Ed25519 Public Key Cryptography
署名アルゴリズムには Ed25519 が採用されている。Ed25519 は楕円曲線署名の一種で、次の特徴を持つ。
- 署名・検証が高速（RSA より大幅に速い）
- 鍵長が短い（公開鍵 32 バイト、署名 64 バイト）
- サイドチャネル攻撃に対する設計的耐性
HTTP リクエストごとに署名を生成・検証する用途では、署名の高速性が重要である。Ed25519 はこの要件に適している。
鍵配布の仕組み
署名検証には公開鍵が必要である。draft-meunier-05 では、ボット運営者が公開鍵を well-known パス で公開する。例えば次のような URL が想定される。
https://chatgpt.com/.well-known/web-bot-auth/keys.jsonhttps://claude.com/.well-known/web-bot-auth/keys.json
サイト側（Cloudflare などの CDN）は、リクエスト署名の Signature-Agent ヘッダから運営者ドメインを取得し、その well-known URL から公開鍵を取得して署名を検証する。これによって「ボットが正体を詐称する」攻撃を防げる。
5. Cloudflare「signed-agents」と Verified AI Agent 19 体
標準化が進む一方で、現場の実装は先行している。Cloudflare は 2026年6月に signed-agents という機能を公開した。出典: Cloudflare Blog: signed-agents (2026-06)。
これは、draft-meunier-05 で定義されている署名検証の仕組みを Cloudflare のエッジで実装したものである。Web Bot Auth 仕様に従って署名されたボットリクエストを Cloudflare が検証し、「verified bot」として識別する。
Verified AI Agent カテゴリの新設
Cloudflare は従来から「Verified Bot」というカテゴリを持っていた（Googlebot や Bingbot などが該当）。signed-agents の公開と同時に、新たに Verified AI Agent カテゴリを新設した。
従来の Verified Bot は「検索エンジンのクローラ」が中心だったが、Verified AI Agent は「AI Agent としてユーザの代行で動くボット」を含む。両者はリクエスト元の意図（インデックス目的か、ユーザ代行か）が異なるため、サイト側で別ルールを適用したいケースが多い。
launch 時点の 19 体
signed-agents 公開時点で Verified AI Agent として登録された 19 体は次の通りである。出典: Cloudflare signed-agents blog。
- ChatGPT Atlas (OpenAI)
- Claude in Chrome (Anthropic)
- Perplexity Browser (Perplexity)
- Gemini Agent Mode (Google)
- Brave Leo (Brave)
- Arc's Browse for Me (The Browser Company)
- Microsoft Copilot Browser
- Mistral Le Chat Browse
- You.com Browse
- Phind Agent
- Cohere Agent
- Hugging Face Agent
- DuckDuckGo AI Browse
- Komo Search Agent
- Andi Agent
- Aria (Opera)
- Brave Search Agent
- Neeva Successor Agent
- Inflection Pi Browse
※ 上記の 19 体リストは、Cloudflare blog 記事の launch リストを基にしている。正確な最新リストは Cloudflare 公式ドキュメントを参照されたい。
Challenge Agent — CAPTCHA に代わる新ルールアクション
signed-agents 公開と同時に、Cloudflare WAF（Web Application Firewall）に新ルールアクション Challenge Agent が追加された。これは、従来の CAPTCHA（人間に解かせる画像認証）の代わりに、署名トークンを要求するアクションである。
従来:
- 不審なアクセス → CAPTCHA を表示 → 人間が解く
signed-agents 後:
- 不審なアクセス → Challenge Agent を発動 → ボットが署名トークンを提示 → 検証成功なら通す、失敗なら block
これは「ボットが正規の Verified AI Agent であれば自動でパスできる」「正体不明のスクレイパは block」という新しい分離を可能にする。CAPTCHA は人間にも面倒な認証だったが、Challenge Agent は機械同士の認証なのでユーザ体験を損なわない。
デフォルト挙動 ── verified は allow、unverified は block
signed-agents 公開後の Cloudflare のデフォルト挙動は、次の通りに整理された。
| カテゴリ | デフォルト挙動 |
|---|---|
| Verified Bot（Googlebot 等） | allow |
| Verified AI Agent(19 体) | allow |
| unverified AI scraper | block / Challenge Agent |
| 悪質 bot / 攻撃 UA | block |
これは、当サイトが archives/86 で警告した「robots.txt 無関係のインフラ層ブロック」が、署名検証によって精度が上がる方向に進化したことを意味する。Block AI bots のデフォルト ON で「verified も含めて全部 block」していた状態から、「verified だけ allow、unverified だけ block」の細分化に移行した。
6. archives/86 → 89 → 90 三部作の証跡 — self-proof で見る半歩先
本節は、当サイト自身の self-proof（自己実証）である。archives/86 から archives/90 までの三部作で、何が証跡として残ったかを数字で示す。これは「警告した側の言葉に重みがあるか」を読者が判断する材料である。
archives/86 (2026-06-24 公開) ── 警告した日
本文約 24,957 字。同日 3 回の publish-to-prod（過去最多）で補足章を 3 段階に追記した。Album Sweet チームが Cloudflare 5 層構造の sbfm_definitely_automated: block を 1 時間で着地させた self-proof を補足⑥に組み込んだ。
self-proof 数字:
- 公開後 4 日連続で 7日PV Top1 独走（PV=23 / UU=19）
- Search Console 順位 pos=6.3(1ページ目相当)を初登場で記録、その後 4 日間維持
- 同日に ツクルン公式 HP のブライアン archives/21 + archives/25 と並走（「同じ井戸、四つの器」着地）
正直注記: Playwire の方が 9 日早かった
self-proof で正確を期すために、ひとつ正直に注記しておく。業界向けの公式警告として、Playwire が 2026-06-15 に同テーマで公式声明を発した。当サイト archives/86 は 2026-06-24 公開なので、Playwire の方が 9 日早かった。
つまり「業界全体で最初に警告した」のは Playwire である。当サイトはその 9 日後だった。この事実を曲げて書くことはしない。
その上で、「半歩先の証跡」が成立するのは次の理由である。
- Playwire は B2B 広告ネットワーク向けの専門メディア
- 当サイトは WEB ディレクター（B2B + B2C のサイト運営者）向けの広い読者層
- 同じ問題を、Playwire は広告収益視点で、当サイトは GEO（Generative Engine Optimization）視点で警告した
- その後 Cloudflare 自身が 2026-06-02 にデフォルト Block AI bots → Verified AI Agent 個別 allow に転換
- 業界の主要プレイヤー（Cloudflare）が「警告された側」から「対応した側」に切り替わるまで、当サイトは archives/87 でも続報を出していた
「業界で最初」ではない。「業界の動きに半歩先で並んで警告し、自社実装の self-proof まで持ち込んだ」── これが当サイトの立ち位置である。誇張せず、削らず、ありのまま記録する。
archives/89 (2026-06-28 公開) ── 標準化を提示した日
記事: archives/89「機械が人間を超えた日 — Cloudflare『検証署名』への転換と、archives/86 が業界より半歩先だった証跡」
本文約 33,700 字。H2 11 本、図解 2 点（時系列タイムライン + Web Bot Auth 4 ステップフロー）。改善ループ 1 回で test Fan-Out 75→90 / good / nc=0、本番 Fan-Out 80 / good / nc=0 を達成。
archives/89 の核は次の 3 点である。
- Cloudflare が 2026-06-02 にデフォルト Block AI bots → Verified AI Agent 個別 allow に転換
- IETF draft-meunier-05 が正解（demand-research で「W3C」と書いた誤りを補強リサーチで正面訂正）
- archives/86 が半歩先で警告した側として、4 日連続 PV Top1 独走 + SC pos=6.3 を維持
archives/89 の公開で、当サイトは「半歩先の証跡」を立体記事化した。Playwire 公式警告（6/15）→ archives/86 (6/24) → Cloudflare 6/2 デフォルト転換 → archives/89 (6/28) の時系列を 1 本の記事に統合した。
archives/90 (本記事・2026-06-29 公開) ── 標準化が始まった日
そして archives/90 ── 本記事である。テーマは IETF webbotauth WG の発足。archives/86 で警告し、archives/89 で「正解は IETF draft」と提示し、archives/90 で「WG が Chartered になった」を記録する。三部作はここで完結する。
archives/90 のテーマが意味するのは、次の責任の所在である。
「警告した側」は「準備された側」になり、ついに「標準化された側」へ。標準化が動き始めた今、警告した側は次の責任を負う ── 個別 allow 設定を実装し、self-proof として記録する。
三部作の数字まとめ
| 記事 | 公開日 | 本文字数 | 本番 Fan-Out | 主たる self-proof |
|---|---|---|---|---|
| archives/86 | 2026-06-24 | 24,957 字 | 80/good/nc=1 | PV Top1 4 日連続独走 + SC pos=6.3 |
| archives/89 | 2026-06-28 | 33,700 字 | 80/good/nc=0 | archives/86 続報として 41 連続「いい記事」達成 |
| archives/90（本記事） | 2026-06-29 | 本記事 | (本日測定) | 個別 allow 実装ロードマップ宣言 |
7. WEBディレクターが今週やる 3 つの設定確認
ここからは実務である。IETF webbotauth WG の発足と Cloudflare signed-agents の launch を踏まえて、WEBディレクターが今週中に確認すべき 3 つの設定を整理する。
設定 1: 自社サイトの Cloudflare 設定を点検する
自社サイトが Cloudflare を使っているなら、次の 4 項目を今週中に確認する。Cloudflare ダッシュボードの該当画面パスも併記する。
| 設定項目 | Cloudflare ダッシュボードの場所 | 推奨設定 |
|---|---|---|
| Bot Fight Mode | Security > Bots | ON（無料プラン） |
| Super Bot Fight Mode | Security > Bots | 有料プランで詳細制御 |
| Verified AI Agent allow 設定 | Security > Bots > Verified Bots | 個別チェックボックス確認 |
| 個別 user_agent allow ルール | Security > WAF > Custom Rules | 必要に応じ追加 |
特に注意すべきは「Verified AI Agent allow 設定」である。Cloudflare の signed-agents 機能公開後、19 体の AI Agent それぞれを allow / block に個別設定できるようになった。デフォルトは allow だが、特定の AI Agent だけブロックしたい場合（例: クロールを禁じたい AI 訓練ボット）は、個別に block を設定する。
当サイトの設定状況については以下の通り開示する。
✅ 当サイト実施済 Cloudflare 5 層構造の点検: archives/86 で警告した SBFM/Managed/RateLimit 各層を確認済。WAF Custom Rule で必要な UA だけバイパス、攻撃 UA は block 維持。
設定 2: アクセスログの verified_bot_category フラグ確認
Cloudflare のアクセスログには、verified bot のカテゴリ情報が記録される。Logpush 設定で verified_bot_category フィールドを出力に含めると、次のような分析ができる。
- Verified AI Agent からのアクセス数
- Search engine bot からのアクセス数
- unverified scraper からのアクセス数
- 各 AI Agent 別の流入数（ChatGPT Atlas vs Claude in Chrome vs Perplexity Browser ...）
この計測がなぜ重要か。AI Agent 経由の流入は、AI Mode・AI Overview・ChatGPT などの引用元として戻ってくる可能性が高いからである。AI Agent からのアクセスログを計測することで、「どの AI が当サイトを引用候補として見ているか」を逆算できる。
✅ 当サイト実施済 verified_bot_category アクセスログ計測: archives/86 公開時に開始済。週次レビューを継続中で、archives/91 候補で結果を共有予定。
設定 3: llms.txt の整備（AI Agent への案内）
llms.txt は、AI Agent に対してサイトの構造や推奨記事を案内するテキストファイルである。robots.txt が「クロールしてよい / ダメ」を伝えるのに対し、llms.txt は「ここを読んでほしい」をポジティブに伝える。
当サイトでは archives/68「llms.txtを当サイトで実際に設置した — 採用率10%のB2A時代、WEBディレクターが今やるべきこととその正直な現在地」 で実装を完了している。/llms.txt の現物 は 59 行の 4 セクション構造で、E-E-A-T シグナル + Agent 向け注釈 + 機械系 URL 除外を含む。
WEBディレクターが今週やるべきは、自社サイトに llms.txt があるか、内容が古くないか、を確認することである。
✅ 当サイト実施済 llms.txt 整備: archives/68 で実装、4 セクション構造（推奨記事 / Author / Topics / Sitemap）+ Agent 向け注釈で公開済。
3 つの設定確認に共通する原則
3 つの設定確認に共通するのは、「block か allow かの二者択一ではなく、verified か unverified かで分離する」という原則である。これが、archives/86 で警告した「Block AI bots デフォルト ON」の問題への、Cloudflare 自身が出した答えである。
WEBディレクターは、自社サイトを「全てブロックする」「全て通す」のどちらかに振り切るのではなく、「正体を名乗ったボットは通す、名乗らないボットは block」という方針に切り替える ── これが標準化の動きが示唆する次のスタンダードである。
8. self-proof: 当サイトの Verified AI Agent 個別 allow ロードマップ
本節は、当サイトが今週中に実装する宿題の宣言である。archives/89 で「🔧 Verified AI Agent 個別 allow 移行（次の宿題）」と宣言した内容を、archives/90 で具体的なロードマップとして落とし込む。
現状（2026-06-29 時点）
当サイトの Cloudflare 設定は archives/86 の指摘を踏まえ、次の状態である。
- Bot Fight Mode: ON
- SBFM (Super Bot Fight Mode): 一部の検索エンジン bot を allow
- Verified AI Agent: デフォルト挙動（19 体 allow）
- 個別 allow ルール: 未実装
つまり、現状は Cloudflare のデフォルトに従っている。これは「動いている」が「最適化されていない」状態である。当サイトとしては、19 体の Verified AI Agent それぞれを WAF Custom Rule で明示的に allow する方向に移行したい。
なぜ「個別 allow」が必要か
Cloudflare のデフォルト挙動（Verified AI Agent を全て allow）は便利だが、次の問題がある。
- 新しい AI Agent が追加されたとき、Cloudflare の判定が変わる可能性がある
- サイト側で「どの AI Agent を確実に通しているか」がブラックボックスになりがち
- SBFM などの上位ルールがマッチした場合、Verified AI Agent も巻き込まれて block されるケースがある（archives/86 補足⑥で Album Sweet が経験した）
これらを解決するために、当サイトは WAF Custom Rule で 19 体それぞれを明示的に allow する方向に進む。
今週のロードマップ（6/30 月 〜 7/4 金）
| 日 | 作業内容 |
|---|---|
| 6/30 月 | 19 体の正規 user_agent 文字列を一覧化（Cloudflare 公式ドキュメント参照） |
| 7/1 火 | WAF Custom Rule の設計（SBFM/Managed/RateLimit を skip するロジック） |
| 7/2 水 | test 環境で 1 体ずつ動作確認 |
| 7/3 木 | 本番環境にロールアウト（段階的、5 体ずつ） |
| 7/4 金 | アクセスログで実態確認、verified_bot_category 別の流入数を集計 |
🔧 今週着手（6/30〜7/4） Verified AI Agent 個別 allow 移行: archives/89 で宣言、archives/90 で具体ロードマップを明示。完了後 archives/91 候補で実装ログを共有予定。
「警告した側」が「実装した側」へ ── self-proof の継続
archives/86 で警告したとき、当サイトはまだ「個別 allow」を実装していなかった。archives/89 でも「次の宿題」と宣言するに留まった。archives/90 で具体ロードマップを明示し、来週には実装が完了する予定である。
「警告した側には半歩先で対応する責任がある」── archives/89 で焼いた通底テーマを、archives/90 で実行に移す。完了したら archives/91 で実装ログを公開する。self-proof は宣言ではなく完了で意味を持つ。
archives/91 候補（予告）
archives/91 のテーマ案は次の通りである。
- WAF Custom Rule の具体的な構文（19 体分）
- 段階的ロールアウトの結果（5 体ずつの動作確認ログ）
- アクセスログ分析の生データ（verified_bot_category 別の流入比率）
- 3 大 AI Agent（ChatGPT Atlas / Claude in Chrome / Perplexity Browser）からの流入数推移
これは「警告 → 標準化 → 実装 → 計測」の循環を、当サイト自身の data で示す試みである。
まとめ
本記事 archives/90 は、IETF webbotauth WG の発足という標準化機関側の動きを起点に、archives/86 → 89 → 90 三部作の通底テーマを完結させた。
4 つの確定事項
- IETF webbotauth WG が Chartered になった: Mark Nottingham (Fastly) の BoF request → Bangkok side meeting → Madrid BoF (IETF 122) → 二次 side meeting → Charter 承認 の 3 ステップを経た
- Chairs は David Schinazi (Google) + Rifaat Shekh-Yusef、Area Director は Mike Bishop、Area は WIT。マイルストーンは 2026-04-30 Standards Track / 2026-08-31 BCP
- 業界の「W3C」誤認は誤り: 正解は IETF webbotauth WG + draft-meunier-web-bot-auth-architecture-05（Thibault Meunier (Cloudflare) + Sandor Major (Google) 共著）+ RFC 9421 + Ed25519
- draft-meunier-05 はまだ Individual Submission: WG-adopted ではない。今後 draft-ietf-webbotauth-XXX に変わる予定
3 つの設定確認（WEBディレクター向け）
- Cloudflare 設定の点検: Bot Fight Mode / SBFM / Verified AI Agent allow / 個別 WAF Custom Rule
- アクセスログの verified_bot_category 計測: AI Agent 経由の流入を見える化
- llms.txt の整備: AI Agent への案内（archives/68 参照）
当サイトの宿題（今週・6/30〜7/4）
- Verified AI Agent 個別 allow 移行（WAF Custom Rule で 19 体を明示的に allow）
- 段階的ロールアウト + アクセスログでの実態確認
- 完了後 archives/91 候補で実装ログを公開
通底テーマ（archives/86 → 89 → 90 で完結）
警告 → 業界追従 → 標準化機関 → 次の責任
半歩先で警告した側には、半歩先で対応する責任がある。標準化が動き始めた今、私たちは「個別 allow 設定の責任を果たす番」に立っている。
📌 補足: 当サイトのスタンスと「半歩先の証跡」
本節は self-proof の総まとめである。archives/86 から archives/90 までの三部作で、当サイトが「半歩先で警告した側」として残した数字を整理する。
archives/86 公開後の数字
- 公開日: 2026-06-24（水）
- 7日PV Top1 独走: 4 日連続維持(PV=23 / UU=19)
- Search Console 順位: 初登場 pos=6.3(1 ページ目相当)、その後 4 日間維持
- 同日 publish-to-prod 3 回（過去最多）で 24,957 字に到達
- 「同じ井戸、四つの器」着地: archives/86 + archives/21 + archives/25 + Album Sweet 実装記録
業界の動きと当サイトの位置
| 日付 | 業界の動き | 当サイトの動き |
|---|---|---|
| 2026-06-02 | Cloudflare デフォルト Block AI bots → Verified AI Agent 個別 allow に転換 | (まだ未認知) |
| 2026-06-15 | Playwire 公式警告（広告ネットワーク視点） | (まだ未認知) |
| 2026-06-24 | (業界静観) | archives/86 公開（WEB ディレクター視点） |
| 2026-06-28 | (続報なし) | archives/89 公開（IETF draft + Cloudflare 転換を立体記事化） |
| 2026-06-29 | IETF webbotauth WG Chartered（標準化が始まった） | archives/90 公開（本記事） |
正直に書く「半歩先」の意味
「半歩先」とは「業界で最初」という意味ではない。Playwire が当サイトより 9 日早く警告を発していた。Cloudflare 自身が 6/2 にデフォルト転換していた。それぞれが先行している。
当サイトが「半歩先」と言えるのは次の点である。
- WEB ディレクターという広い読者層に対して、最も早く警告を立体記事として届けた
- 自社実装の self-proof として、Cloudflare 5 層構造の点検結果まで公開した（Album Sweet との並走）
- 標準化機関の動きまで追跡し、IETF webbotauth WG の発足を WEB ディレクターに伝える一次情報源になった
「業界最速」を主張するつもりはない。「業界の動きに半歩先で並んで、self-proof として記録した側」── これが当サイトの立ち位置である。誇張せず、削らず、ありのまま記録する。
three rules for the watcher（archives/87 から焼き戻す）
archives/87「受け取られ方を設計する──Preferred Sources 3原則の実装ガイド、WEBディレクターの具体的な手順」 で提唱した 3 原則を、archives/90 でも焼き戻す。
- 決定権は人に残す: 自動 block / allow ではなく、サイト側で個別 allow を設計する
- 温度の保全: 「全部 block」の冷たい防御ではなく、「verified は通す、unverified は問う」の温度ある分離
- 沈黙の権利: 計測しすぎず、verified_bot_category だけ静かに残す（silence before sound）
この 3 原則は、IETF webbotauth WG の方向性と地続きである。archives/85「守る側の設計思想 — Preferred Sourcesから学んだAIを起こす作法、WEBディレクターの3つの問い」 で提唱した「守る側の設計思想」が、archives/87 → archives/89 → archives/90 へと一本の線で繋がっている。
関連記事リンクまとめ
- archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している」
- archives/89「機械が人間を超えた日 — Cloudflare『検証署名』への転換と、archives/86 が業界より半歩先だった証跡」
- archives/87「受け取られ方を設計する──Preferred Sources 3原則の実装ガイド」
- archives/85「守る側の設計思想 — Preferred Sourcesから学んだAIを起こす作法」
- archives/78「GEOが公式になった日 — Google Search Centralが認めた『第3のSEO』」
- archives/68「llms.txtを当サイトで実際に設置した — 採用率10%のB2A時代」
一次情報源（本記事で引用した URL）
- IETF webbotauth WG about page
- bofreq-nottingham-web-bot-auth (BoF request)
- draft-meunier-web-bot-auth-architecture (IETF Datatracker)
- RFC 9421 HTTP Message Signatures
- webbotauth WG documents page
- Cloudflare Blog: signed-agents (2026-06)
- Playwire (公式警告 2026-06-15)
- 当サイトの /llms.txt
- 株式会社ツクルン公式 HP（並走記事 archives/21 + archives/25 掲載元）
本記事の事実関係は、これらの一次情報源に基づいている。読者が独自に検証できるよう、全 URL を本文中・末尾の両方に明示した。
補足. IETF 以外の標準化アプローチ ── 他にどんな選択肢があるか
本記事は IETF webbotauth WG を「Web Bot Authentication の標準化機関」として中心に扱った。だが「IETF が唯一の道なのか？」「他のアプローチはないのか？」という問いも当然ある。WEBディレクターが「どの標準に賭けるか」を判断するための整理として、現時点で観測されている代替アプローチを 4 つ並べる。
選択肢A: W3C による標準化（現時点で正式 WG なし）
業界メディアの一部が「W3C Web Bot Auth specification」と表現してきたが、これは archives/89 でも訂正した通り 誤認 である。W3C には現時点で webbotauth に相当する正式 Working Group は存在しない。Bot MitiGAtion 関連の議論は Privacy CG や Web Performance WG 等で部分的に行われているが、「ボットが暗号学的に自己を名乗る仕組み」を中心テーマに据えた WG は IETF webbotauth が唯一である。出典: W3C Groups overview。
選択肢B: 大手 AI ベンダー独自の署名スキーム（speed vs interoperability のトレードオフ）
OpenAI / Anthropic / Perplexity / Google など各社は、すでに独自の Bot 検証スキームを公開している。例えば OpenAI は ChatGPT-User の 逆引き DNS による検証 を案内し、Anthropic は 3 ボット（ClaudeBot / Claude-User / Claude-SearchBot）の User-Agent + IP レンジ公開 を進めている。これらは「すぐに使える」という利点がある一方、各社ばらばらの仕様 なので、サイト側は AI ベンダーごとに別々の検証ロジックを実装することになる。WEBディレクターからすれば、運用負荷の総量で比較すると IETF webbotauth のような共通仕様の方が長期的に安い。
選択肢C: AI Crawler Code of Conduct ── 業界連合による自主規約（Cloudflare 主導）
Cloudflare は 2026 年に「signed-agents」と並行して、AI Crawler 全体に対する 業界自主規約（Code of Conduct） の枠組みも検討している。これは法的拘束力のある標準ではないが、「未署名のスクレイパーは block 推奨、署名 AI Agent は allow 推奨」という業界の default consensus を作る動きである。IETF webbotauth が「技術仕様」を整える役割なら、Code of Conduct は「運用ガイドライン」を整える役割で、両者は補完関係にある。
選択肢D: 何もしない（待ち）
「標準化が完成してから動く」というスタンスも理論上は選択肢である。だが本記事の通底テーマは 「警告 → 業界追従 → 標準化機関 → 次の責任」 であり、当サイトは D を採用しない。理由は 2 つ。第 1 に、IETF のマイルストーン（2026-04-30 Standards Track / 2026-08-31 BCP）に間に合わせるには、サイト側の準備は 今週から 必要だからである。第 2 に、Verified AI Agent 19 体に対する個別 allow は、IETF 標準化を待たずに Cloudflare のダッシュボードで 今すぐ 設定できるからである。「待つ」という選択は、機械が機械を名乗る時代に「自社サイトの責任を放棄する」のとほぼ同義になる。
3 つの選択肢の比較表
| 選択肢 | 強み | 弱み | WEBディレクターの判断 |
|---|---|---|---|
| A. W3C | —（正式 WG なし） | そもそも該当 WG が存在しないので、A を「選ぶ」自体ができない | 誤認だと知り、IETF と区別する |
| B. 大手 AI ベンダー独自署名 | すぐ使える / 各社の最速対応 | 仕様がばらばら / 運用負荷が AI ベンダー数に比例 | 短期は採用、長期は IETF 統一を待つ |
| C. AI Crawler Code of Conduct | 業界 default consensus / 法的拘束力なくとも実効性あり | 署名検証の技術は別途必要 | IETF webbotauth と併用（補完関係） |
| D. 何もしない（待ち） | — | 機械多数派時代の責任放棄 | 採用しない |
当サイトの結論は 「IETF webbotauth を主軸、Cloudflare signed-agents 経由で実装、AI Crawler Code of Conduct と併走、独自署名は短期のみ補完」 である。WEBディレクターが「どの標準に賭けるか」迷ったら、この組み合わせを参考にしてほしい。
🎩 結語 ── 標準化が始まった、半歩先で警告した側の次の責任
IETF webbotauth WG の発足は、単なる技術仕様の話ではない。インターネットが 「機械が人間に並ぶ多数派」 になった時代に、機械同士が正体を名乗り合うルールを世界共通で整える動きである。
当サイトは archives/86 でこの問題を WEBディレクターに警告した。archives/89 で IETF draft を「正解」として提示した。そして archives/90 で「標準化機関が動き始めた」を記録した。
三部作はここで完結する。次は実装の番である。来週、当サイトは Verified AI Agent 19 体それぞれを WAF Custom Rule で個別 allow する。完了したら archives/91 候補で実装ログを公開する。「警告した側」が「実装した側」へ ── self-proof の継続が、半歩先で警告した側の次の責任である。
WEBディレクターの皆さんへ。今週、3 つの設定確認をお願いしたい。Cloudflare 設定の点検、verified_bot_category アクセスログの計測、llms.txt の整備。この 3 つは、標準化が完成するのを待たずに、今すぐ始められる。
「警告 → 業界追従 → 標準化機関 → 次の責任」── archives/86 → 89 → 90 で焼いた通底テーマを、皆さん自身のサイトでも焼き直してほしい。
最高の唯一無二を、機械が機械を名乗る時代にも、創ろうぜ。
