クローラー、検索エンジン、そして生成型 AI 企業の卑劣な行為

ここ数カ月間の生成 AI 製品のブームにより、多くの Web サイトが対策を講じるようになっています。

基本的な懸念は次のようになります。

AI 製品は、言語モデル (いわゆる大規模言語モデル、略して LLM) をトレーニングするために大量のコンテンツを消費することに依存しており、このコンテンツはどこかから取得する必要があります。 AI企業はウェブのオープン性によりトレーニングデータを取得するための大規模なクローリングが可能になると見ているが、Reddit、Stack Overflow、Twitterなど一部のウェブサイト運営者はこれに同意していない。

この興味深い質問に対するこの答えは、間違いなく世界中の裁判所で訴訟されることになるでしょう。

この記事では、ビジネス面と技術面に焦点を当てて、この質問について検討します。 ただし、本題に入る前に、いくつかのポイントがあります。

• このトピックはいくつかの法的議論に触れており、この記事にも含めていますが、私は弁護士でも、あなたの弁護士でもありません。また、あなたにいかなる種類のアドバイスも与えているわけではありません。 法的なアドバイスが必要な場合は、お気に入りの弁護士猫に相談してください。
• 私は何年も前に Google で主にウェブ検索の仕事をしていました。 以下に Google の例をいくつか引用する場合でも、私はいかなる形でも Google を代表して話すものではありません。
• これは急速に進展しているトピックです。 私がこれを書き終えてからあなたが読んでいる間に、業界で何か重大なことが起こっていることは保証されており、私が何かを見逃していたことは保証されています。

検索エンジンとウェブサイト間の「取引」

まず、Google や Bing などの最新の検索エンジンがどのように機能するかから始めます。 非常に単純化した言葉で言うと、検索エンジンは次のように機能します。

• 検索エンジンには URL のリストがあります。 各 URL には、その URL が重要であるか、検索エンジンの結果ページに表示するのに役立つ可能性があることを示すメタデータ (「シグナル」と呼ばれることもあります) があります。
• これらのシグナルに基づいて、検索エンジンにはクローラー、つまりシグナルが示す内容に基づいて「重要度」の順序でこれらの URL を取得するプログラムであるボットが搭載されています。 この目的のために、Google のクローラーは Googlebot と呼ばれ、Bing のクローラーは Bingbot と呼ばれます (そしてどちらも広告など、他の目的のために他にもたくさんあります)。 どちらのボットもユーザー エージェント ヘッダーで自身を識別しており、両方のボットを Web サイトでプログラム的に検証して、コンテンツがスプーフィングではなく本物の検索エンジン ボットに提供されていることを確認できます。
• コンテンツが取得されると、インデックスが作成されます。 検索エンジン インデックスは、ページ コンテンツと、コンテンツをユーザー クエリに照合してランク付けするために使用される膨大な量のメタデータやその他のシグナルを含む複雑なデータベースです。 インデックスは、Google または Bing でクエリを入力したときに実際に検索されるものです。

最新の検索エンジン、少なくとも優れた礼儀正しい検索エンジンでは、Web サイト運営者はクロールとインデックス作成を完全に制御できます。

ロボット排除プロトコルは、robots.txt ファイル、および Web ページ自体のメタ タグまたはヘッダーを通じてこのコントロールを実装する方法です。 これらの検索エンジンは自発的にロボット排除プロトコルに従い、Web サイトによるプロトコルの実装を単なるヒントではなく指示、絶対的なコマンドとして受け取ります。

重要なのは、プロトコルのデフォルトの位置では、すべてのクロールとインデックス作成が許可されることです。デフォルトでは許可されています。 Web サイト運営者が積極的に除外措置を講じない限り、Web サイトはクロールとインデックス作成を許可するとみなされます。

これにより、検索エンジンと Web サイト間の取引の基本的な枠組みが得られます。デフォルトでは、Web サイトは検索エンジンによってクロールされ、インデックスが作成されます。これにより、検索者は関連するクエリの検索結果で元の Web サイトを直接参照できるようになります。 。

この契約は基本的に経済交換です。コンテンツの制作、ホスティング、提供にかかるコストはウェブサイトが負担しますが、その見返りとして得られるトラフィックが利益としてそれを返済するという考え方です。

注：私はここで、この取引所で誰がより多くの力を持っているか、誰がより多くのお金を稼いでいるのか、公平性などについて、関連する多くの議論を意図的に無視しています。 これらを軽視しているわけではありません。この記事の中心的なトピックから逸​​れたくないだけです。

このトラフィックに対するインデックス付けのアプローチは、検索エンジンがペイウォールの背後にあるコンテンツのインデックス付けを許可されている場合など、他の場所でも登場します。 これも同じ考えです。Web サイトは、検索結果に表示される代わりにコンテンツを共有し、検索者を Web サイトに直接誘導します。

そして、この取引のプロセスの各段階で、パブリッシャーが何らかの方法ですべてまたは一部のクロールまたはインデックス作成をブロックしたい場合、パブリッシャーはロボットと除外プロトコルを使用するいくつかのツールを備えています。 それでもクロールとインデックス登録が許可されているのは、Web サイトが検索結果に表示されることで直接的な利益を得ているためです。

この主張は、何らかの形で実際に法廷で「robots.txt 弁護」として知られるようになり、基本的には支持されてきました。 この短い裁判例のリストを参照してください。その多くは Google に関係しています。また、この件について完全に満足しているわけではない 2007 年の記事もご覧ください。

LLM は検索エンジンではありません

LLM が検索エンジンとは異なるものであることは明らかです。

言語モデルの応答は、モデルのトレーニングにコンテンツが使用された Web サイトを直接示すわけではありません。 検索エンジンで見られるような経済的な交流はなく、これが多くの出版社 (および著者) が動揺している理由です。

直接的なソース引用の欠如は、検索エンジンと LLM の根本的な違いであり、「なぜ Google と Bing にはコンテンツのスクレイピングが許可され、OpenAI には許可されないのか?」という非常に一般的な質問に対する答えになります。 (この質問では、より丁寧な表現を使用しています。)

Google と Bing は、AI の生成応答にソース リンクを表示しようとしていますが、これらのソースは、たとえ表示されたとしても完全なセットではありません。

これにより、関連する疑問が生じます。何も見返りが得られないのに、なぜ Web サイトのコンテンツを言語モデルのトレーニングに使用できるようにする必要があるのでしょうか。

それはとても良い質問であり、おそらく社会として私たちが答えるべき最も重要な質問です。

現世代の LLM には大きな欠点 (いくつか例を挙げると、幻覚、人間のオペレーターに対する嘘、偏見など) があるにもかかわらず、LLM には利点があり、欠点が解決されるまで、これらの利点は時間の経過とともに増大するだけです。

しかし、この議論において重要な点は、現在のオープン Web の機能の基本的な柱が LLM に適していないことを認識することです。

下品さ

自社の経済的利益のみを目的として大規模なモデルをトレーニングすることに関心がある AI 企業にとって、これは問題ではないようです。

OpenAI はトレーニング データ入力としていくつかのデータセットを使用しました (GPT3 の詳細はこちら)。OpenAI は意図的に GPT4 のトレーニング データセットを開示していません。

OpenAI は、GPT4 のトレーニング データ (ここで説明) に関する情報を開示しないことを正当化するために多くの議論を使用しますが、私たちにとって重要な点は変わりません。それは、どのコンテンツがトレーニングに使用されたのかが分からず、OpenAI は ChatGPT 応答でそれを示しません。

OpenAI のデータ収集はロボット排除プロトコルに従っていますか? 教科書や他の書籍など、著作権で保護されたテキストは含まれていますか? ウェブサイトや出版社から許可を得たのでしょうか? 彼らは言いません。

Brave Software の非常にいかがわしいアプローチ

OpenAI のアプローチに問題があるとすれば、Brave Software (Brave ブラウザーと Brave 検索エンジンのメーカー) は、検索と AI トレーニング データに関してはさらに問題のあるアプローチとスタンスをとっています。

Brave 検索エンジンは、いわゆる Web Discovery プロジェクトに大きく依存しています。 このアプローチは非常に精緻であり、ここで文書化されていますが、重要な事実を 1 つ強調しておきます。Brave は、彼らが運用する集中型のクローラーを持っていないようで、どのクロールも自分自身を Brave のクローラーとして認識していません。そして、(このために座って) Brave Brave が購入者に AI トレーニングのために与える権利を付けて、スクレイピングされたコンテンツを販売します。

この文には多くの内容が含まれているので、分解してみましょう。

Brave 検索は、Brave ブラウザを分散クローラーとして使用します。 このヘルプ記事に記載されているように、次の FAQ の質問と回答があります。

Web Discovery プロジェクトはクローラーですか?

ある意味、そうですね。 Web Discovery プロジェクトは、Brave の Web クローラーからのフェッチ ジョブを処理します。 数秒または数分ごとに、ブラウザーは Web ページを取得して HTML を Brave に送信するように指示される場合があります。 ただし、この取得は閲覧履歴や Cookie には影響しません。プライベート フェッチ API 呼び出しとして実行されます。 安全性をさらに高めるため、フェッチ ジョブ ドメインは、無害で信頼できる少数のドメインのセットから事前に選択されます。

Web ディスカバリー プロジェクトとは何ですか? – ブレイブサーチ

Fetch API は、Brave が使用するものを含む、最新のブラウザ エンジンに組み込まれた Web 標準機能です。 一般的な用途は、ブラウザでユーザーに表示するコンテンツを取得することです。 私たちの目的では、それが Brave の検索エンジンに代わって Web サイトのコンテンツをリクエストしているユーザーのブラウザであることがすぐにわかります。

興味深いことに、2021年6月のRedditスレッドではさらに詳細と混乱が追加されています。 Brave の代表者からの 1 つの返信は非常に興味深いものです (私のものを強調しています)。

私たちは独自のクローラーを持っていますが、潜在的な差別を避けるために、ユーザー エージェント文字列が含まれていません(ブラウザーの Brave にも一意のユーザー エージェント文字列が含まれていないのと同じです)。 そうは言っても、私たちは、クローラーがいつ、どこに自分のプロパティに到達するかを知りたい管理者に対して、クローラーを特定できる可能性があることについて話しました。 また、robots.txt も尊重しているため、Brave Search がサイトをクロールしたくない場合は、クロールされません。

これは事実の宝庫です:

1. 彼らは独自のクローラーを持っており、集中型クローラーまたは分散型ブラウザーベースの Web Discovery プロジェクトを参照している可能性があります。
2. このクローラーは、自分自身をクローラーとして識別しませんが、何らかの形でロボット排除プロトコル (robots.txt ファイルの形式) に従います。 ブラウザーが自身を識別しない場合、Web サイト運営者はどのようにしてロボット排除ディレクティブを作成できるでしょうか? Brave のクローラーに固有のディレクティブを指定するために、robots.txt ファイルでどのユーザー エージェント トークン (と呼ばれる) が使用されますか? Brave からのドキュメントは見つかりませんでした。
3. 彼らが差別と呼んでいるのは、実際にはパブリッシャーがクロールをどのように制御するかということだ。 Robots Exclusion Protocol は、サイト運営者がユーザーとクローラーにアクセスを許可するものと、異なるクローラーを区別するためのメカニズムです (たとえば、Bingbot のクロールは許可しますが、Googlebot のクロールは許可しません)。 Brave は差別を避けたいと主張することで、実際には、何をクロールしてインデックスするかを決定できるのは発行者ではなく、自分たちであると言っているのです。

Fetch API に戻ります。デフォルトでは、Fetch API はブラウザのユーザー エージェント文字列を使用します。 Brave ブラウザは、固有のユーザー エージェント ヘッダーで自身を識別せず、代わりに、基礎となるブラウザ エンジンによって生成される汎用のユーザー エージェント文字列を使用することはすでにわかっています。

ユーザー エージェント文字列は、ブラウザー全般と Fetch API に対してカスタマイズできますが、Brave がそれを行うという兆候はまだ見つかりません (実際、上で引用した Reddit の返信では、一意の識別子が存在しないと明示的に述べられています)。

さらに、Brave は、スクレイピングしたデータを、単なる検索結果 (たとえば、サイト検索機能を強化するため) としてだけでなく、AI トレーニング専用に販売し続けています。

Brave Search API ホームページにアクセスすると、「Data for AI」と呼ばれるものを含むいくつかの価格帯が表示されます。 これらのデータ プランには、加入者が「AI モデルをトレーニングするためのデータのキャッシュ/保存」を可能にする「ストレージ権限付きデータ」のオプションが含まれており、そのデータには「AI 用の追加の代替スニペット」と「AI 推論にデータを使用する権利」が含まれます。 」

要約すると、Brave の公式声明と文書の欠如に基づいて、Brave は、Web を制御またはブロックする明確な方法がない状態で、こっそりと Web をクロールし、クロールしたコンテンツを AI トレーニング用に再販し続けています。

あるいは、これをより率直に言い換えると、 Brave は、Web サイト発行者からのライセンスや許可を得ることなく、著作権で保護されたコンテンツの営利目的の配布者として自らを指定しました。

これは許容されますか? 私はこれをサービスとしての低俗なスクレーパーだと考えています。

Google のパブリッシャーコントロールイニシアチブ

生成 AI に特化した、新しいタイプの Web クローラーが間もなく登場する可能性があります。

Google は、Googlebot が Web 検索のために取得したコンテンツの使用が AI モデルのトレーニングには適さない可能性があるという、上記の非互換性を認識しているようです。

Google は、AI Web Publisher Controls を作成するためのコミュニティ ディスカッションを開始したいと発表しました (おい、Google、登録しました。参加させてください!)。 私はこの会話を心から支持します。そして、この会話への扉を開いた Google はよくやったと思います。

まだ初期段階にあるため、そのようなコントロールのデフォルトと機能が成功または失敗に重要であることを示すことが重要です。 多くの出版社や著者は、これらの AI 制御がどのように機能するべきかについて私たちが聞く必要があるという強い意見を持っているのではないかと思います。

オープンソース LLM についてはどうですか?

上記の議論の重要な側面は経済交流です。 しかし、言語モデルの背後にある組織が、自分たちに利益をもたらさずにモデルを自由にリリースしたらどうなるでしょうか?

このようなオープンソース モデルは数多くあり、それらは商用の独自モデルのトレーニングに使用されるデータセットと実質的に重複するデータセットでトレーニングされます。 多くのオープンソース モデルは、現時点では一部のユースケースには十分であり、さらに改良され続けています。

それでも: オープンソース LLM をトレーニングするために Web サイトのコンテンツが許可なく使用されるのは正しいでしょうか?

それはおそらくより難しい質問であり、現時点での答えはロボット排除プロトコルで何が許可されているかに基づいていると思います。 Google の AI Web Publisher Controls やその他の同様の取り組みから、適切に設計されたアプローチの形で、より良い答えが現れる可能性があります。

このスペースをご覧ください。

では、パブリッシャーは今何ができるのでしょうか?

この現状は、多くの出版社が望んでいない、受け入れていない状況です。 彼らに何ができるでしょうか？

ここでは、昔ながらのクローラー/ボットのブロックに戻る必要があります。 クローラーには通常、次の 2 種類があります。

1. 自分自身を識別するクローラー。 ロボット排除プロトコルに従う場合も従わない場合もありますが、少なくともサーバーには、リクエストをブロックするかどうかを決定するために確認する識別子があります。 例としては、Googlebot や Bingbot が挙げられます。
2. ステルス クローラー。丁寧な検索エンジンには使用されません。 彼らは自分自身を識別しないか、ロボット排除プロトコルに従いません。 例としては、Script Kiddie のスパム スクレーパーや Brave Search のクローラーなどが挙げられます。

補完的に実行できることが 2 つあります。

1. クローラーがロボット排除プロトコルに従っている場合、クローラーがクロールするコンテンツが AI トレーニング データにフィードされると思われる場合は、クローラーをブロックできます。 ここには 2 つのアプローチがあります。
   • すべてのクローラーをブロックし、ニーズに応じて許可したいクローラーのみを許可します (Googlebot や Bingbot など)。 これは、オーガニック検索における Web サイトのパフォーマンスにとって危険です。 細心の注意が必要ですが、このようなクローラーには効果的です。
   • すべてのクロールを許可し、ブロックしたいものをブロックします。 このより寛容なアプローチは危険性が低いですが、もちろん、コンテンツが AI やその他の望ましくないクローラーによってスクレイピングされる可能性があります。
2. サーバー側のステルス ボット検出機能を使用して、そのようなクローラーをブロックします。 多くの製品でこれが可能です。 多くのパブリッシャーと同様にコンテンツ配信ネットワーク (CDN) を使用している場合は、おそらくこの種の機能がそこを通じて利用できるでしょう (Akamai、Cloudflare、Fastly など)。

私が運営する Web サイトに対して採用し始めており、クライアントと話し合っているアプローチは、オプション (1a) と (2) を組み合わせたものです。つまり、制限付きの robots.txt ファイルと CDN コントロールを使用することです。

これは各出版社にとって最善のアプローチではないかもしれませんが、真剣に検討する価値があると思います。

これは何を意味するのでしょうか？

私たちは歴史上最も影響力のある時代の一つとして残るであろう時代を生きています。 人々は文字通り、AIによる人類の滅亡を予測しています。 私たちは皆、未来を形作る上で役割を担っています。

オリジナル コンテンツのクリエイターとしての私たちは、業界のこの急速に変化する部分にどのように対応し、追いついて適応するかを考える必要があります。 私たちが作成するコンテンツがどのように作成、配布、消費されるかを決定することは、現在、戦略、テクノロジー、財務、倫理などが複雑に絡み合っています。

どのような反応をするにしても、あなたは歴史的な瞬間に態度をとっているのです。 あなたの負担を感じています。