AI crawlerをサイトに入れるべきか？この表で3分で決める

まず分ける：AI crawlerは1種類ではない

crawlerは、まず「Webサイトの内容を自動で読み取るプログラム」と理解すればよい。以前なら主な相手は検索エンジンのbotだった。ページを取得し、インデックスを作り、あとで読者をあなたのサイトへ戻してくれる。

AI crawlerが厄介なのは、用途が分岐し始めたことだ。

• 検索型crawler：あなたのコンテンツをAI検索や要約結果に出すことを目的にする。
• agent型crawler：agentは「いくつかの作業を自分で連続実行するAI助手」と考えればよい。ユーザーの代わりにページを読み、価格を比較し、仕様を調べ、答えを整理することがある。
• 学習型crawler：コンテンツをモデル学習やデータセットに取り込むことを目的にする。必ずしも判別できる読者流入を返すとは限らない。

この3種類の流量は、サイトにとっての価値もリスクも違う。すべてを同じルールに入れると、2つの悪い結果が起きる。入ってきてよい検索露出を止めてしまう一方で、本来はライセンスや制限を話すべき学習用途のアクセスを黙って許してしまう。

BMCでは以前、agentic webには機械が読める入口と検収条件が必要だと扱った。サイトが入口ルールを明確に書かなければ、AIツールは推測するしかない。この話は、〈agentをサイトに入れる前に、機械が読めるドアを用意する〉とあわせて読むとよい。前者は「誰を入口に入れるか」を扱い、この記事は「入った後、それを何の用途と数えるか」を扱う。

文字版の判断ツリーで一度走らせる

まだcrawlerポリシーがないチームなら、最初から完全な規約を書く必要はない。次の順番で進めればよい。

1. このcrawlerは用途を明確に説明しているか。

   • している：次の問いへ進む。
   • していない：用途、連絡先、退出方法を提供できるまで、観察またはブロックリストに入れる。

2. 用途は検索、agentのリアルタイム読み取り、学習のどれか。

   • 検索：本当に判別できる流入を返しているか確認する。
   • agent：公開データだけを読み、ログイン、フォーム、取引を触っていないか確認する。
   • 学習：コンテンツライセンスと商業的交換が成立しているか確認する。

3. 測定できるコストを生んでいるか。

   • 例：1日のリクエスト量が通常bot平均の2倍を超える、エラー率が上がる、キャッシュヒット率が下がる、検索ページが大量に走査される。
   • コストがある：レート制限、課金、API、または人による審査へ切り替える。
   • コストがない：いったん観察を続ける。ただし30日後の見直しを設定する。

4. 高価値コンテンツに触れているか。

   • 例：有料記事、会員データ、独自調査、商品データベース、講座内容、価格ページ、在庫ページ。
   • 触れている：学習と大量読み取りは、原則として無料開放しない。
   • 触れていない：比較的ゆるいポリシーでもよい。ただしlogは残す。

5. このルールにownerはいるか。

   • ownerとは、最後の判断と後始末に責任を持つ人だ。ownerのないポリシーは、すぐに誰も維持しないブロックリストになる。
   • 少なくともコンテンツownerを1人、技術ownerを1人指定し、いつ再評価するかを書いておく。

このツリーの使い方は単純だ。急いで「全面許可」か「全面ブロック」を選ばない。まずcrawlerを正しい場面に置き、それから許可、観察、課金、ブロックを決める。

よくある失敗：すべてのAI流量を1つのスイッチに押し込む

最も事故が起きやすいのは、管理画面で「AI crawler」を見つけて、総合スイッチを1つ作ることだ。これでは3つの違う問題が混ざる。

• 露出の問題：AI検索に見つけてもらいたいか。
• 操作の問題：agentにページを読ませ、データを調べさせ、ユーザーの手順を進めさせてよいか。
• ライセンスの問題：自分のコンテンツを学習やデータセット構築に使わせてよいか。

この3問の答えは、完全に違っていてよい。検索型crawlerには公開記事を読ませたいかもしれない。読者を連れてくる可能性があるからだ。agentにはFAQを読ませてもよいが、会員エリアへのログインやフォーム送信はさせたくないかもしれない。同時に、学習型crawlerには先にライセンス交渉を求めるかもしれない。

すでにAIコンテンツのノイズ処理に取り組んでいるサイトなら、〈情報の入口と出典ルールでAIコンテンツのノイズを処理する〉も参考になる。入口ルールとcrawlerポリシーは一組だ。前者は何を受け取るかを決め、後者は自分のコンテンツが機械にどう使われるかを決める。

今日できる最初の一歩

今日1つだけやるなら、完全なツール一覧を追いかけない。まず文書を1つ開き、「AI crawler access policy v0.1」と名づけ、次の4段落を書く。

1. 検索インデックス型crawlerを許可する条件。
2. agentリアルタイム読み取りを許可する境界。
3. 学習型crawlerに対するデフォルトのライセンス立場。
4. どのパスを高価値コンテンツとし、追加審査が必要か。

そしてownerと30日後の見直し日を指定する。この文書は短くてよい。しかし後続の技術設定に根拠を与える。robots.txt、Bot管理、WAF、API key、有料壁、契約条項はすべて、このポリシーを別の層で実行する方法にすぎない。

本当に厄介なのは、Cloudflareや特定のサービスがどうルールを変えるかではない。コンテンツサイトがこれまで「読めること」と「機械が利用できること」を混ぜて扱ってきたことだ。いま補うべきなのは、長期的に維持できるアクセス方針である。

AI整理カード

下の文をAIに渡すと、crawlerポリシーの初版作成を手伝わせることができる。使う前に、括弧内を自分のサイト情報に置き換える。

あなたはコンテンツサイトの技術・コンテンツポリシー顧問である。以下の情報にもとづいて、「AI crawler access policy v0.1」の草案を作ってほしい。

サイト種別：［例：小規模メディア、ナレッジベース、講座サイト、製品ドキュメント、データベース］
高価値コンテンツのパス：［URL pathを列挙。例：/members/、/courses/、/research/］
現在把握しているAI crawler：［名称、User-Agent、流量概況。不明なら不明と書く］
私たちが得たい見返り：［検索露出、referral、ライセンス料、API利用、提携データ］
最も心配しているリスク：［サーバーコスト、コンテンツの置き換え、学習利用、会員コンテンツ流出、フォーム悪用］

出力してほしいもの：
1. 検索インデックス型crawlerの許可条件。
2. agentリアルタイム読み取り型crawlerの許可行為と禁止行為。
3. 学習またはデータセット型crawlerに対するライセンス立場。
4. 先にブロックまたは人による審査に回すべきシグナル。
5. 30日後に見直す5つの指標。

制約：
- 抽象原則だけを書かない。各項目に実行可能な条件を入れる。
- 公開閲覧と自動化された大量取得を区別する。
- 情報が足りない場合は、サイトownerに追加で聞くべき質問を列挙する。

この整理カードの目的は、法律判断を代行することではない。コンテンツ、エンジニアリング、ビジネスの間に散らばった問いを、まず同じリストに並べることだ。リストが形になってから、どれをツールで止めるべきか、どれをライセンスで話すべきか、どれは安心して開けてよいかが見えてくる。