WEBサイトCloudflareの「Agents aren’t humans」は、代理で動くAIの課題14個を挙げ、顧客が今日使える3つの手順と、これから出る提案を分けて書いた ── 提案と出荷済みを分けて読み、担当サイトで変えることを決める13項目（2026年11月時点）
Cloudflareの「Agents aren’t humans」は、代理で動くAIの課題14個を挙げ、顧客が今日使える3つの手順と、これから出る提案を分けて書いた ── 提案と出荷済みを分けて読み、担当サイトで変えることを決める13項目（2026年11月時点）
目次
- 01 何が書かれたか — 11月5日、Cloudflareは「代理で動くAI」の課題を14個挙げ、今日使える手順と、これから出る提案を、同じ記事の中で分けて書いた
- 02 なぜ・背景 — サイトが見えるのは、仲介者だけになった
- 03 用語 — 出てくる言葉を、先にそろえる
- 04 型別 — 適用範囲、この記事が測っていないこと、確かめる手順
- 05 明日、担当サイトで確認できること
- 06 代替・他の選択肢 — 提案の状態を知る方法を、並べて比べる
- 07 当サイトで確かめたこと — 当サイトはCloudflareを使っていないので、変えたことはない
- 08 このテーマは、ここまで — 「見分ける」から「誰が責任を負うか」へ、どう積み上げてきたか
- 09 この記事のまとめ
01 何が書かれたか — 11月5日、Cloudflareは「代理で動くAI」の課題を14個挙げ、今日使える手順と、これから出る提案を、同じ記事の中で分けて書いた
引用について
この記事は、Cloudflareの公式ブログ「Agents aren’t humans (but they kinda are)」（2026年11月5日付）と、同社のWeb Bot Authの文書、IETFのAIPREF作業部会の案内ページを、2026年11月6日に開いて確かめた内容を書いている。英文を引くときは原文のまま引き、日本語訳を添える。それ以外は、記事の筆者が日本語に直した要旨で書く。原文に書かれていない筆者の読みは「筆者の読み」と書いて分ける。05章のチェックリストは、筆者が整理したものである。
AIエージェントが人に代わってサイトを使うようになると、サイトの側には、見えるのはエージェントだけで、その背後の人が見えないという問題が出る。Cloudflareは11月5日に出したこの長いブログで、問題を整理し、必要なものを「Identity（識別）」「Reputation（評判）」「Accountability（説明責任）」の3つにまとめ、解決のための提案を並べた。同じ記事の最後には、Cloudflareの顧客が今日からできる3つの手順も載っている。
WEBディレクターが読むときに迷いやすいのは、この記事に書かれていることが、すでに使えるものなのか、これから作るものなのかが、文の中で混ざって見えることだ。この記事では、原文を「課題」「提案」「今日使える手順」に分けて整理し、担当サイトで何を変えて、何を変えないかを決める手順を13項目にした。画面の見え方や、エージェントを数える手順は、別の記事Cloudflareは、利用者の代わりに来る個人用AIエージェントを、分析の専用の区分と、エージェントごとの許可・ブロックで扱えるようにした ── 自社のログで代理の取得を分けて数え、通すかを決める13項目（2026年11月時点）に書いた。この記事は、その背景にある考え方を扱う。
原文が置いた原則: 仲介があっても、関係と責任は保つ
原文は、記事全体の土台になる原則を1つ置いている。「仲介の原則（The Intermediation Principle）」である。
"The business relationship between Users and Sites, and each participant’s security responsibilities, must be upheld regardless of intermediation."
（日本語訳: 利用者とサイトの間の取引上の関係と、それぞれの参加者の安全上の責任は、仲介があっても保たれなければならない。）
原文はこの原則から、サイトには、エージェントを通した利用者を、直接来た利用者と同じように識別し、サービスを提供し、責任を問える道具が要る、と続ける。同時に、エージェントとその運営者も、識別でき、責任を問える存在でなければならない、と書いている。
原文が挙げた14の課題
原文は、エージェントを通すことで難しくなる、サイト運営者の目標を14個の表にしている。次の表は、その要旨を日本語に直したものである。名前の訳は筆者のもので、1行目の英語は原文の見出しである。
| 原文の見出し | 日本語での名前（筆者訳） | 原文の説明の要旨 |
|---|---|---|
| Account sharing | アカウントの共有 | 1つの有料契約が多数の利用者に使われるのを防ぎたいが、エージェント経由ではサイトに1つのアカウントと1つのクライアントしか見えない |
| Compliance and illegal activity | 法令順守と違法行為 | 年齢や地域の制限など、利用者の情報を確かめる法的な要件がある。エージェントは、その基準を満たす保証を出さない |
| Friendly fraud | 友好的な不正 | 利用者がエージェントの購入を承認したあと、無断だと争う。エージェントの購入はエージェントの基盤から来るので、本人の過去の購入と同じ端末・IP・住所という状況証拠がない |
| Human verification is irrelevant | 人間の確認が意味を持たない | CAPTCHAは操作しているのが人かを見る。エージェントは人であることを期待されないので、人の確認を利用者に渡しても新しい情報が増えない |
| Identity spoofing | なりすまし | エージェントは家庭用IPや本物のブラウザで動き、人の通信に混ざる。攻撃者が有名なエージェントの名乗りを写して、同じ許可を得ようとする |
| Identity verification breaks | 本人確認が成り立たない | 年齢確認や身分証の確認は、目の前の人が本人だという前提で作られている。エージェントはその人ではない |
| Misalignment | 意図とのずれ | 新しいエージェントは、違う商品、違う日付、重複した注文などの間違いをする。返金や問い合わせの費用をサイトが負うことがある |
| Policy circumvention | 方針の回避 | 名乗りに基づく方針（ブロック、提携先だけ許可、頻度の制限）を課したいが、エージェントは名乗らないことがあり、利用者の情報も持たない |
| Resource exhaustion | 資源の枯渇 | 無料のサービスは利用者の行動に上限があると想定している。エージェントは絶えず状態を確かめ、重い機能を使い、無料の枠を使い切る |
| Risk-based authentication breaks | リスクに応じた認証が成り立たない | 端末・場所・動作が利用者と合う前提で作られている。エージェントはクラウドで動き、毎回見慣れない形に見える |
| Traffic commingling | 通信の混在 | 1人が共有のエージェントを悪用すると、サイトは悪用を見つけられるが、止められるのはエージェントだけで、正当な利用者も一緒に止まる |
| Unauthorized card users | 承認されていないカード利用者 | 承認された利用者の購入ならカード保持者が責任を負う。エージェントにはその立場がなく、利用者が争うと、実際にはサイトが支払うことになる |
| Uncompensated consumption | 対価のない消費 | エージェントが記事・商品データ・レビューを読み取って別の場所で答える。サイトは配信の費用を払い、訪問も広告の表示も購入も得られない |
| User attribution | 利用者の紐づけ | 個人化、おすすめ、ポイント制度は、利用者のセッションと端末に結びつけた分析を使う。エージェントの通信は、多数の利用者を1つにまとめるか、利用者のセッションなしで来る |
原文は、この表のあとに、ほぼすべての課題で、サイトが主なコストを負うと書く。"In nearly every challenge above, the Site bears the primary cost."（日本語訳: 上の課題のほぼすべてで、サイトが主なコストを負う。）
3つの提案と、3つの手順
原文は、必要なものを「Identity」「Reputation」「Accountability」の3つにまとめ、提案を「Protocols（通信の約束事）」「Identities（識別）」「Claims（事実の申告）」「Site Agent access policy（サイトのエージェント方針）」の4つの見出しで並べる。記事の最後の「What you can do today（今日できること）」には、Cloudflareの顧客向けに3つの手順が載る。1つ目はエージェントを見ること、2つ目はエージェントごとに方針を決めること、3つ目はエージェントを、その背後の利用者に結びつけて対応することである。この3つの中身は、前の記事の01章に書いた。
原文に書かれていないこと
- 具体的なHTTPヘッダーの名前や書き方
- エージェントの通信量の割合や、伸び率の数字
- MOLEの仕様の中身や、いつ使えるようになるか
- Web Bot AuthがIETFの標準になったという記述（原文は「Cloudflareが好む方法（preferred method）」と書くだけである）
02 なぜ・背景 — サイトが見えるのは、仲介者だけになった
仲介者は前から居た。変わったのは、数の見込み
原文は、エージェントを「仲介者（intermediary）」の最新の形と位置づける。利用者とサイトの間に立ち、サイトからは利用者の代わりに仲介者が見えるものを、仲介者と呼ぶ。原文は、クラウドのブラウザ（ソフトが利用者に代わって操作する、遠隔のブラウザ）や、VPNを含む通信の中継のサービスも、仲介者だと書いている。変わったのは、エージェントの通信が急速に増えていて、近い将来、人の通常のブラウジングを上回るかもしれない、と原文が書いている点である。
そこで原文は、これまでの対応が使えなくなる、と続ける。以前は、仲介者の通信をブロックして、利用者に仲介サービスを切ってもらえばよかった。通信の多数がエージェントになれば、それは通用しなくなる。ブロックが選べなくなると、サイトは、仲介者から利用者の直接の情報が消えた状態で、仲介者を信頼するか決める問題に向き合う。エージェントの通信がどれだけ増えるかの数字は、原文には書かれていない。
例え話: 買い物を頼まれるアシスタント
原文は、仲介の問題を、街のアシスタントのエズラという人物で説明している。エズラはアミー、ボブ、チャーリー、デブラの4人の用事を引き受ける。八百屋は、前はアミーの好みを知っていたが、今は4人分の注文を持ったエズラしか来ず、誰の好みか分からない。ボブがエズラにスマートフォンを買わせ、1週間後に店へ連絡して「承認していない」と言い、スマートフォンは手元に残す。店が勝つには、ボブが頼んだと証明する必要があるが、店が見たのはエズラだけだった。チャーリーが「パスワードのどれかだ」とエズラに渡した一覧を、エズラが銀行で試す。銀行は攻撃を見つけられるが、締め出せるのはエズラだけで、アミー、ボブ、デブラも一緒に締め出される。
どの店も、エズラ自身には問題がない。問題は、エズラだけが見えて、エズラが代わりに動いている人が見えないことだ。原文は、エズラをAIエージェントに、店をウェブサイトに置き換えると、今のウェブになる、と書く。
人の確認や、狭い権限では足りない理由
原文は、これまでに試された案が、なぜ足りないかも書いている。1つは、エージェントがCAPTCHAを利用者に渡して解いてもらう案である。これは、その瞬間にどこかの人が居ることは示すが、それ以上のことは示さない。「どの利用者か」を区別できず、エージェントは摩擦をなくすために作られているので、運営者は摩擦を減らす方向に動く、と書く。もう1つは、権限の範囲を狭くする案である。エージェントは、利用者ができることは何でもするように作られていて、実際には「すべて」の権限を求めて、得る。範囲が「すべて」では、サイトは何も分からない。範囲が狭くても、間違ったときに誰が責任を負うかは分からない、と原文は書く。
03 用語 — 出てくる言葉を、先にそろえる
用語: 仲介者（Intermediary）
利用者とサイトの間に立ち、サイトから見ると利用者の代わりに見えるもの全般。原文は、AIエージェント、クラウドのブラウザ、VPNを含む通信の中継を、仲介者の例に挙げる。
Web Bot Auth（ウェブボットの認証）
Cloudflareの文書によると、Web Bot Authは、HTTPの通信に暗号の署名を付けて、その要求が自動のボットから来たと確かめる方法である。確認済みボットとエージェントの確かめ方の1つとして使われる。文書は、これがIETFの2つの草案に基づくと書く。公開鍵をクローラーが共有するための草案と、鍵を使って要求にクローラーの名乗りを結びつける方法の草案である。原文のブログは、この方法で、エージェントが自分と、運営者を安全に名乗れると書く。ただし、複数の仲介者が連なる場合を支える仕組みは、まだ決める必要があると、原文は書いている。
MOLE
原文は、MOLEを「これから出てくる方法の1つ」と書き、利用者固有の識別子を使わずに、通信の頻度を制限するものだと説明する。サイトが、暗黙の識別から、明示の約束事へ移る助けになる、という。原文は、以前の試みとして「Private Access Tokens」を挙げ、MOLEはその後継を意図している、と書く。原文のMOLEの語は、インターネットドラフト（draft-jms-mole-architecture）へのリンクになっている。仕様の中身は、原文にはない。
Trusted Agent Delegation（TAD）の連合
原文の最後で、Cloudflareは「Trusted Agent Delegation（TAD）」の連合の発表を書く。目的は、エコシステム全体の代表者が集まって、今回の課題全体を議論し、既存の約束事を調べ、範囲を絞った問題をIETFに持ち込むことである。会議の予定として、IETFの場での脇の会合と、今後のワークショップが挙がっている。
識別の4つの段階
原文は、識別を「利用者についての情報の量を変える、連続した段階」と考え、情報を最小限にする原則を守りたいと書く。そのうえで、段階を4つに分ける。なし（Nothing）、セッション（Session）、アカウント（Account）、ユニーク（Unique）である。セッションは、同じセッションの中の要求を1つのエージェントに結びつける。アカウントは、セッションをまたいで同じ利用者に結びつける。ユニークは、運営者・アカウント・エージェント・セッションをまたいで続く、利用者ごとの識別子で、政府発行の身分証や第三者の本人確認がその例に挙がる。
04 型別 — 適用範囲、この記事が測っていないこと、確かめる手順
適用範囲: ログインや購入などの「人を前提にした仕組み」がある場所
14の課題は、どれも、サイトに人を前提にした仕組みがある場合に効いてくる。ログイン、会員登録、購入、年齢や地域の制限、無料の試用や回数制限、個人化などである。そうした仕組みが何もなく、記事だけを公開しているサイトでは、関係する課題は少ない。代わりに「対価のない消費」と「資源の枯渇」が前に出る。
この記事が測っていないこと
原文は主張の記事で、エージェントの通信がどれだけあるか、14の課題がどれだけ起きているかの数字は示していない。この記事も、そうした数字を持たない。MOLEやWeb Bot Authなどの仕様を、1つずつ試して確かめてもいない。仕様の文書を開いたのは、Web Bot Authの文書だけである。MOLEのインターネットドラフトの本文は、開けていない。
確かめる手順1: 提案と出荷済みを、表で分ける
原文は、使えるものと、これから作るものを、同じ文章の中で書く。読む側で分けないと、「もう使える」と思い込んだり、「まだ何もない」と思い込んだりする。次の表は、原文と、Cloudflareの文書に書かれた言葉に沿って、状態を分けたものである。状態は「今日使える」「文書がある」「提案・これから」の3つにそろえ、x402だけは原文から読み取れないので「状態不明」とした。
| 項目 | 状態 | 根拠となる言葉 |
|---|---|---|
| 個人用エージェントの分析の区分と一覧 | 今日使える | 原文の「What you can do today」の1つ目。Cloudflareの顧客が対象 |
| エージェントごとのアクセス方針 | 今日使える | 「What you can do today」の2つ目。Cloudflareの顧客が対象 |
| エージェントと利用者の紐づけ（Account Abuse Protection） | 今日使える（先行利用） | 「What you can do today」の3つ目。原文は「early access」と書く。Cloudflareの文書は、企業向け契約の顧客が対象と書く |
| Web Bot Auth | 文書がある | Cloudflareの文書に手順がある。文書は、確認済みボットとエージェントの確かめ方として説明する。署名の仕様はIETFの草案に基づく |
| x402（支払い） | 状態不明 | 原文は「支払いをプライバシーを守って可能にすることを目指す」と書く |
| MOLE（利用者固有の識別子なしの頻度制限） | 提案・これから | 原文は「upcoming（これから出る）」と書く |
| 複数の仲介者が連なる場合の識別 | 提案・これから | 未定。原文は「まだ決めなければならない」と書く。Cloudflareの文書は、運営者の識別にForwardedヘッダーを使う試みを「試験的」と書く |
| Claims（年齢など、事実の申告） | 提案・これから | 仕組みが要る段階。原文は「仕組みが必要だ」と書く |
| サイト側の、機械が読めるエージェント方針 | 提案・これから | 議論の場が未定。原文は、この大きな必要に焦点を当てた作業部会は、まだ無いと書く |
| TADの連合 | 提案・これから | 連合そのものは発表された。原文は、これから議論を始めると書く |
確かめる手順2: 14の課題から、担当サイトに当てはまる3つを選ぶ
14の課題を全部確かめる必要はない。担当サイトにある「人を前提にした仕組み」から、関係する課題を3つ選ぶ。たとえば、会員登録とログインがあるなら、「通信の混在」「リスクに応じた認証が成り立たない」「アカウントの共有」が入口になる。記事を公開しているだけなら、「対価のない消費」と「資源の枯渇」である。選んだ3つの隣に、担当サイトのどの画面の話かを書く。
実務のヒント
課題の名前は、そのまま社内の会議に出さなくてよい。「ログインの画面に、人ではない通信が混ざったとき、どちらを止めるか決まっているか」のように、担当サイトの言葉に直して書く。
確かめる手順3: ログインと会員登録の保護が、「人だけ」を前提にしていないか
原文の「人間の確認が意味を持たない」が指すのは、CAPTCHAが人の確認だけを見ている場合、エージェントには意味がないことだ。担当サイトのログインや会員登録に、人の確認だけで守っている画面があるなら、代理で来る通信に対して何が起きるかを、前提として書き出す。止めたいのは「エージェント」ではなく、「悪用している1つのアカウント」かもしれない。原文の通信の混在の例が、そのことを示している。
確かめる手順4: robots.txtで、できることとできないことを書き分ける
原文は、robots.txtを次のように評価している。
"Robots.txt says where a crawler may go, but isn’t fully suited to express what Agents may do."
（日本語訳: robots.txtは、クローラーがどこへ行ってよいかを示すが、エージェントが何をしてよいかを表すには十分に向いていない。）
robots.txtでできるのは、場所についての希望を伝えることである。購入してよいか、ログインしてよいか、といった動作についての希望は、書く場所が決まっていない。原文によれば、IETFのAIPREF作業部会は、利用の希望（学習、推論、検索など）の表現を扱っていて、動作についての大きな必要を扱う場は、まだ無い。
"However, the focus of the group is on expressing preferences for use (such as training, inference, and search), and there is still not a group focused on the larger need for preference expression mechanisms discussed here."
（日本語訳: ただし、この作業部会の焦点は、利用についての希望（学習、推論、検索など）を表現することにあり、ここで論じた、より大きな希望の表現の仕組みの必要性に焦点を当てた作業部会は、まだ無い。）
確かめる手順5: 識別の4段階のうち、どこまで要るかを決める
原文は、サイトが、要求の背後の存在が「いま、この操作をしてよいか」を答えるのに必要な情報を決める、と書く。担当サイトの操作を、記事を読む、問い合わせる、会員登録する、購入する、のように並べて、操作ごとに4段階のどこまで要るかを書き込む。記事を読むだけなら「なし」で足りる。購入には、少なくとも「アカウント」が要るかもしれない。ただし、これは筆者の整理で、原文は操作ごとの対応を書いていない。
05 明日、担当サイトで確認できること
以下は、担当サイトで、提案と出荷済みを分けて読み、今日変えることを決めるための13項目である。1〜3番目は読み方、4〜7番目は担当サイトの「人を前提にした仕組み」の洗い出し、8〜10番目は保護とrobots.txt、11〜13番目は決めたことの残し方である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- Cloudflareのブログ「Agents aren’t humans (but they kinda are)」を開き、「What you can do today」の3つの手順を書き写す
- 04章の表の「今日使える」「文書がある」「提案・これから」の3つの区分を、自分のノートに書き写す
- x402のように、原文から状態が読み取れないものを、「状態不明」として別の行に書く
- 担当サイトにログイン、会員登録、購入、問い合わせの画面があるか、1つずつ確認する
- 無料の試用や、回数の制限、会員限定の内容があるか、確認する
- 14の課題の表から、担当サイトに当てはまるものを3つ選び、担当サイトのどの画面の話かを隣に書く
- 選んだ3つの課題について、「いま決まっていること」と「決まっていないこと」を1行ずつ書く
- ログインの画面が、人の確認（CAPTCHAなど）だけで守られていないか確認する
- 1つのアカウントだけを止める手段があるか、サービスの管理者に聞いて、答えを書く
- robots.txtを開き、「場所」についての行と、「動作」についての行が書き分けられているかを確認する
- 担当サイトの操作を4つ選び、操作ごとに、識別の4段階のどこまで要るかを書き込む
- Cloudflareを使っているなら、管理画面でエージェントの区分と方針を開き、現在の値を書き写す
- 次に原文とCloudflareの文書を読み直す日を決め、確認した日付と一緒に、方針の記録に書く
チェックが終わったら、選んだ3つの課題と、識別の段階の書き込みを1枚にまとめて、担当サイトの記録に残す。提案はこれから変わる。書き写した日付が、あとで変化に気づく手がかりになる。
06 代替・他の選択肢 — 提案の状態を知る方法を、並べて比べる
提案の状態を知る方法は、Cloudflareのブログを読む以外にもある。それぞれの向き不向きを、次の表に整理した。比べ方は、筆者の整理である。
| 方法 | 向いている場面 | 注意 |
|---|---|---|
| Cloudflareのブログ | Cloudflareが何を課題と見て、何を出したかを知る | 書いた会社の見方である。提案と出荷済みが同じ文章に混ざる |
| Cloudflareの文書 | 今日使える機能の、手順と条件を確かめる | 更新の日付が表示される。ブログと内容が食い違うことがある |
| IETFのdatatracker | 提案が草案としてどの段階にいるかを、名前と種別で確かめる | 草案は標準そのものではない。読み方はAI学習の信号をめぐる草案は、作業部会の草案が第08版、個人の草案が第00版で、どちらもまだ標準ではない。草案の状態は名前・種別・有効期限・置き換えの4か所で読める ── 話題になった草案をdatatrackerで確かめる13項目（2026年11月時点）に書いた |
| 各社の公式の説明ページ | 代理で来る名乗りが、robots.txtをどう扱うかを確かめる | 会社ごとに説明が違う。名乗りの一覧は、公式のページから写す |
| 担当サイトのログ | 自社に実際に何が来ているかを知る | 名乗りは自己申告で、見分けられない通信も残る |
当サイトの過去の記事で扱った、近い話題
エージェントが操作できるように、ページが道具を差し出す仕組みは、WebMCPは、ページがAIエージェントに操作の「道具」を差し出す実験段階の仕組み ── 自社のページに自分で選んでいない道具や差し込みが入っていないか確かめる13項目（2026年10月時点）で扱った。エージェント向けの案内の置き場所は、Lighthouse 13.5にAIエージェント向けカタログの検査が入った。探す名前は、仕様が「前身」と呼ぶai-catalogの側だった ── 置くか置かないかを決めて確かめる14項目（2026年10月時点）に書いた。名乗りだけで決めない考え方は、Googlebotの名乗りは誰でも書ける。通す・止めるを名乗りだけで決めず、接続元で確かめる ── 自分のサイトの判定を点検する13項目（2026年10月時点）にある。
ログインの画面や会員向けの画面を持つサイトの保護を確かめる手段として、当サイトには🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 外から見える設定を確かめるというツールがある（利用には無料の会員登録が必要です）。
07 当サイトで確かめたこと — 当サイトはCloudflareを使っていないので、変えたことはない
この記事のために、当サイトの設定は変えていない
当サイトはCloudflareを使っていないため、今回の記事で書かれた画面や設定は、当サイトには存在しない。この記事は、担当サイトで確かめる手順として書いた。当サイトは、検索・学習・エージェントの3つを通す方針で、robots.txtも今回の記事を読んで変えていない。方針を決めた経緯は、Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つの末尾に書いてある。
当サイトにも、人を前提にした画面はある
当サイトには、会員登録とログインの画面があり、会員向けの無料ツールがある。14の課題のうち、「通信の混在」「リスクに応じた認証が成り立たない」は、この画面に関係する。ただし、この記事のために、当サイトのログインや会員登録への通信を数え直してはいない。ログを名乗りで分けて数えた記録は、Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直すにある。次に数えるときは、ログインの画面だけを取り出して、代理の名乗りがあるかを確かめ、結果をこの記事に日付つきで追記する。
08 このテーマは、ここまで — 「見分ける」から「誰が責任を負うか」へ、どう積み上げてきたか
これまでの記事
- Cloudflareは、利用者の代わりに来る個人用AIエージェントを、分析の専用の区分と、エージェントごとの許可・ブロックで扱えるようにした ── 自社のログで代理の取得を分けて数え、通すかを決める13項目（2026年11月時点） — 今回のブログの「出荷済み」の側の詳しい読み方
- AI学習の信号をめぐる草案は、作業部会の草案が第08版、個人の草案が第00版で、どちらもまだ標準ではない。草案の状態は名前・種別・有効期限・置き換えの4か所で読める ── 話題になった草案をdatatrackerで確かめる13項目（2026年11月時点） — 提案の状態の読み方
- WebMCPは、ページがAIエージェントに操作の「道具」を差し出す実験段階の仕組み ── 自社のページに自分で選んでいない道具や差し込みが入っていないか確かめる13項目（2026年10月時点） — ページの側から差し出す道具
- 「守る」から「見分ける」へ ── Cloudflare Precursor GAが変えるbot対策と、WEBディレクターが今週確認すべき3点 — 守るから見分けるへの流れ
- Cloudflareが確認済みのボットを「行儀」で評価し始めた週、当サイトの9つの名乗りの取得（4,317行）の18.1%は、公式のIPアドレスの一覧と合わなかった ── 14日分のログで数え直した — 名乗りを公式の一覧で確かめた記録
注意
この記事は、2026年11月6日に確かめた内容に基づく。原文の提案は、これから変わる。実装や標準化の状態を知りたいときは、Cloudflareの文書とIETFのdatatrackerを、その日に開き直すこと。
現在の貴方のIPアドレス
このサイトで書いている人
