AIクローラを一律に止める前に：検索・エージェント・学習を分けて決める

A&Aの考え方

AIクローラを許可するか拒否するかは、一つのスイッチで決める問題ではありません。決める単位は二つあります。一つはボットの振る舞い、つまり検索のために取得しているのか、利用者の代理でその場の用事を片づけているのか、モデルの学習に取り込むために取得しているのか。もう一つは自社サイトの区画、つまりその URL が見つけてもらうための面なのか、顧客に引き渡すための面なのか。この二つを掛け合わせてから設定を触ります。これは A&A の判断です。

A&Aの考え方

検索の提供者自身が、クロールを止められる場所として自社の CDN を名指ししている。ここが起点です。この事実と、次の事実を並べると、一律ブロックが非対称に効くことが見えます。robots.txt は要請であって強制ではありません。だからこそ、遵守状況を追跡する機能が商品として成立します。追跡する必要があるのは従わない場合があるからだ、という読みは当方のものであり、Cloudflare がそう書いているわけではありません。一方で配信元でのブロックは強制です。結果として、名札で一律に止める操作は、止めたかったもの、つまり学習への取り込み全体は確実には止められず、止めたくなかったもの、つまり検索や AI の回答から見つけてもらう経路だけは確実に閉じます。安全側に倒したつもりが、倒れている側が逆になっている。これが問題の形です。

A&Aの考え方

ここから言えるのは、あるクローラ名を許可するか拒否するかという判断が、そのクローラが同時に行っている別の用途もまとめて決めてしまう、ということです。だからボット名の許可リストは、作った日から古くなりはじめます。提供者は新しい用途のために新しいクローラを足しますし、既存のクローラの用途が増えることもあります。維持できるのは名前の一覧ではなく、振る舞いに対する方針です。検索のための取得は通す、代理で用事を片づける取得は通す、学習のための取得はこう扱う。そう決めておけば、知らない名前が出てきたときに当てはめ先があります。名前の一覧を維持しようとすると、月次の宿題が一つ増えるだけで、しかもその宿題は必ず遅れます。ここは A&A の判断です。

A&Aの考え方

振る舞いで分ける方針だけでは、まだ設定に落ちません。同じ「検索のための取得を許可する」という方針でも、公開しているサービス説明と、顧客ごとの見積を置いた共有 URL とでは答えが逆になるからです。先に必要なのは、自社ドメインの URL を、見つけてもらう必要がある面と、引き渡すための面に分ける棚卸しです。

A&Aの考え方

一人・少人数の受託やサービス事業では、この二つが同じドメインに同居しがちです。公開記事とサービス説明は前者で、ここが問い合わせの実質的な入口になっています。一方で、提案書の共有リンク、納品ファイルの置き場、進行中案件のダッシュボードは後者で、そもそも誰にも見つけてほしくありません。後者については振る舞いで分ける議論は不要で、全部拒否が正しい答えです。さらに言えば、この区画はボットの分類より手前、認証と非公開設定で守るべき場所です。AI クローラの設定を、認証の代わりに使ってはいけません。

A&Aの考え方

棚卸しの結果は、区画・見つけてもらう必要があるか・既定の扱い、という三列で一枚に書けます。下の表は前の節の仮の例を表の形にしたもので、A&A が作った整理です。振る舞いの名称は Cloudflare の分類に合わせていますが、区画の切り方と既定の選び方は出典にはありません。

A&Aの考え方

逆に学習の列は、発見とは切り離して事業判断で決めてよい列です。ここを拒否しても、検索と代理実行の取得を許可している限り、上の入口は閉じません。逆にここを許可しても、それが引用や送客を増やすという根拠は、当方の手元にも今回読んだ出典にもありません。学習の可否は、自社が書いたものをモデルへ恒久的に取り込まれることをどう考えるかという、取引条件の判断として決めるのが筋です。発見の話と混ぜると、どちらの判断も濁ります。

A&Aの考え方

ここから二つ言えます。一つ目、クローラの設定を触ることは、引用されるための施策ではありません。発見の前提条件を自分で外さないための衛生管理です。この区別を曖昧にすると、設定を直した月に問い合わせが増えなかったことを失敗として数えてしまいます。二つ目、機械可読ファイルを置いたことをもって AI 対応が済んだと数えないことです。少なくとも Google の検索については、提供者自身が不要と書いています。他のエンジンが別の扱いをする可能性は残りますが、それは当方では未検証であり、この記事では根拠として使いません。

A&Aの考え方

観測できるようになると、取得回数を成果として数えたくなります。分けてください。取得回数は、ボットが何回取りに来たかという数字です。検索の表示回数とクリックは別の数字で、問い合わせはさらに別の数字です。取得が増えても問い合わせが増えない期間は普通にあり、その逆もあります。配信原価の話と発見機会の話も、別の帳簿に書くものです。一人でやっている事業ほど、見える数字が増えたときに、増えた数字を成果の代わりに置いてしまいがちです。収益化の仕組みが一般提供になっていない現時点では、取得回数は原価側の指標として見るのが妥当だと考えます。これは A&A の判断であり、出典の主張ではありません。

A&Aの考え方

向かない場面が三つあります。一つ、配信元が Cloudflare でない場合、同じ管理面はありません。振る舞いで分けるという考え方は移せますが、設定項目は移せません。二つ、サイトに発見面がない場合、つまり公開しているのが会社概要だけで、仕事が紹介と既存顧客から来ている場合は、この記事の判断はほとんど意味を持ちません。一律に閉じてよい場面です。三つ、規制や契約で内容の再利用が制限されている場合は、発見機会との比較ではなく、その制約が先に来ます。

A&Aの考え方

次の一歩は、設定画面ではなく棚卸しです。自社ドメインの URL を発見面と引き渡し面に分け、引き渡し面に認証がかかっているかを先に確認してください。そのうえで、発見面についてだけ、検索と代理実行を許可し、学習を事業判断で決めます。顧客獲得から継続までの全体の中でこの判断がどこに位置するかは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にまとめています。区画の線引きが自社の商売の形と噛み合っているか判断がつかない場合は、個別の相談に向く論点です。