何が起きたか
Search Engine Roundtableの記事は、Facebook、Instagram、WhatsApp、Messenger、Threadsを運営するMetaが、ウェブをクロールしており、独自の検索エンジンを構築している過程にあるとされる、という書き出しで始まります。「とされる(allegedly)」という留保が最初から付いている点が、この記事の性格を決めています。
出どころは、開発者のPieter Levels氏がXに投稿した内容です。同氏は次のように書いています。「Metaはとされる話として、自社版のGoogle検索エンジンを構築している。自社のAIがウェブ検索をしたときにGoogleへ行き着かないようにするためだ。Googleに行き着けば、Googleがそれを自社の学習に使えてしまう。だから彼らは自前のウェブインデックスを持ちたがっており、それを自社のAIのためのMeta検索エンジンとして使うことになる」。
Levels氏は投稿に「Metaのスタッフが内密にDMをくれた」「許可を得て投稿している」という趣旨の説明を添えたうえで、自身が運営するサービスがクロールされている様子を示すスクリーンショットを掲載しました。原文はこの投稿とスクリーンショットを引用する形で構成されており、Metaの発表資料や公式声明を出典としているわけではありません。議論の場としても、原文はXの当該投稿を挙げています。
時系列を整理すると、Levels氏の投稿が2026年8月6日、Search Engine Roundtableの記事が2026年8月10日午前7時51分です。
出典が示している範囲と、示していない範囲
この件を扱ううえで、最初に切り分けておきたいことがあります。原文の本文には、クローラーの名前も、リクエストの件数も、集計期間も、サーバー負荷の値も、一切書かれていません。本文に置かれているのは「彼は自身のプロパティがクロールされている様子を示すスクリーンショットを投稿した」という一文と、それに続くLevels氏のX投稿の埋め込みだけです。
スクリーンショット自体は記事に画像として掲載されています。ただし本記事では、その画像に写っている数値を引用しません。画像の中身は原文の本文テキストとして記述されておらず、読者が原典に当たって同じものを確かめられる形になっていないためです。「どのユーザーエージェントが何件来ていたのか」「どれくらいの期間の集計なのか」を、この報道から確定的に述べることはできません。
したがって、原文から読み取れるのは次の範囲にとどまります。少なくとも1人の開発者が、自身が運営するサービスのサーバーでMetaによるクロールと見られる挙動を観測し、それを公開した。Levels氏はそこに、Metaのスタッフから内密に聞いたという説明を重ねている。Search Engine Roundtableはそれを「とされる(allegedly)」という留保つきで報じた。確認できるのはここまでです。
一方で、Metaがどのようなクローラーを運用していると自ら説明しているかは、推測ではなく公式ドキュメントで確認できます。Meta for Developersの「Web Crawlers」ページには、次のユーザーエージェントが記載されています。
facebookexternalhit: Facebook、Instagram、MessengerといったMetaのアプリ群で共有されたアプリやウェブサイトのコンテンツをクロールするmeta-webindexer: 利用者にとってのMeta AIの検索結果の品質を高めるためにウェブを巡回するmeta-externalads: 広告およびその他のビジネス関連の製品・サービスの改善といった用途でウェブをクロールするmeta-externalagent: 基盤AIモデルの学習や、コンテンツを直接インデックスすることによる製品改善といった用途でウェブをクロールするmeta-externalfetcher: 利用者の要求に応じて個別のリンクを取得し、エージェント的なAI機能の評価と改善といった製品機能を支える
ここで注意したいのは、「こうしたクローラーが存在する」ことと「自社サイトにどれだけ来ているか」がまったく別の話だという点です。前者はMetaの公式資料で誰でも確認できます。後者は、自社のアクセスログを見る以外に知る方法がありません。他人の観測値を自社の状況として受け取る必要はありませんし、そもそも受け取れる根拠がありません。
Metaは何と言っているか、言っていないか
まず押さえておきたいのは、Metaがこの件について何かを発表したという事実は原文に出てこない、という点です。原文が引用しているのはLevels氏のX投稿であり、そこに書かれているのは「Metaのスタッフから内密にDMがあった」という本人の説明です。実名の関係者コメントも、Metaの広報の見解も、原文には登場しません。「検索エンジンを構築している」という部分は、あくまでLevels氏が伝え聞いた内容として提示されています。
一方で、前章に挙げたとおり、検索結果の品質向上を目的としたクローラーの存在自体は、Metaが自ら文書化しています。meta-webindexerについて「Meta AIの検索結果の品質を高めるためにウェブを巡回する」と書いているのはMeta自身です。ここは推測ではありません。
ここで区別が必要です。Metaが「検索品質向上のためのクローラーを動かしている」ことは公式ドキュメントで確認できますが、「Google対抗の独自検索エンジンを製品として構築している」ことをMetaが認めた、という事実は原文にはありません。後者はLevels氏の投稿に基づく伝聞であり、確定ではありません。原文のタイトルが「構築しているかもしれない(May Be Building)」という形になっているのも、そのためだと読めます。
背景:AI学習用のクロールと検索インデックス用のクロールは何が違うのか
今回の話が注目されるのは、同じ「クロールされている」でも、目的によって意味合いが変わるからです。
AI学習用のクロールは、集めたテキストをモデルの学習データとして使うものです。学習に取り込まれた内容が、そのまま出典として提示されるとは限りません。これに対して検索インデックス用のクロールは、ページを検索可能な索引に登録するためのもので、回答のなかで出典としてページを引用したりリンクしたりする土台になります。前者は取られる一方になりやすく、後者は流入につながる可能性を持つ、という違いがあります。
Metaの公式ドキュメントに、学習や製品改善の用途であるmeta-externalagentと、検索結果の品質向上の用途であるmeta-webindexerが別々のユーザーエージェントとして登録されていること自体は、この文脈で意味を持ちます。用途が違えば、サイト運営者にとっての損得も変わるからです。ただし、それぞれが実際にどの程度の量で動いているのかは、Metaも公表しておらず、原文にも記載がありません。
もう1つの背景として、原文はFacebookと検索の歴史に触れています。Facebookは10年以上前から独自の検索サービスを持ちたがってきた、という指摘です。実際、Facebookはウェブ検索機能をBingと提携して提供していましたが、数年後にその提携を解消しています。原文はこの経緯を挙げたうえで、いまはAIの時代になった、と書いています。
Barry Schwartz氏自身の見立ても添えられています。Facebookも、Googleも、Microsoftも、Xも、大手はどこも自社のAIを構築したがっている。そのためには、ウェブインデックスを提携先に依存していられないかもしれない。だからこれはFacebook/Metaにとって次の一手として筋が通る、という趣旨です。これは記者の見解であり、Metaの計画を確認したものではありません。
サイト運営者への影響とrobots.txtの選択肢
日本のサイト運営者にとって、この件は2つの側面を持ちます。1つはサーバー負荷の問題、もう1つは自社コンテンツの露出の問題です。
負荷の面では、まず自社の実測が出発点になります。クロールの規模を示す数値は原文の本文には書かれていないため、他社の観測を借りてきて自社の見込みにすることはできません。一般論として、サイト全体を面で巡回するタイプのクロールは、リンクが共有されたときにプレビューを取りに来るだけの従来型のアクセスとは、量の次元が変わり得ます。小規模なサーバーであれば体感できる負荷になる可能性もあります。ただし、それが自社に起きているかどうかは、自社のログとサーバーの負荷指標を突き合わせて初めて分かります。
露出の面では、判断が単純ではありません。meta-webindexerを止めれば、Meta AIの検索結果に自社ページが取り込まれる経路を自分で閉じることになります。逆に通せば、学習用クローラーとは別の枠で、引用され得る対象になります。どちらが得かは、Meta AI経由の流入が自社にとってどれだけ意味を持つかによって変わります。現時点でその流入規模を示すデータは原文にはありませんし、Metaも公表していません。
制御手段については、Metaの公式ドキュメントに「これらのクローラーをブロックするには、robots.txtに該当するクローラーへのdisallowを追加してください」という記載があります。ユーザーエージェントごとに個別に指定できるため、たとえば学習用は止めて検索インデックス用は通す、といった書き分けも可能です。なお同じ資料は、robots.txtの変更が反映されるまでに最大24時間かかるとしています。クローラーがrobots.txtを最大24時間キャッシュするためで、書き換えた直後にログの件数が変わらなくても、効いていないと判断するのは早すぎます。
ただし、同じドキュメントには注意すべき記述もあります。meta-externalfetcherについては、利用者の要求に応じた取得を行うためrobots.txtを迂回することがあるとされ、facebookexternalhitについても、マルウェアや悪質なコンテンツの確認といったセキュリティ・健全性のチェックを行う際にrobots.txtを迂回することがあるとされています。robots.txtを書けばMeta由来のアクセスがすべて止まる、という理解は正確ではありません。確実に遮断したい場合は、サーバー側やCDN側でユーザーエージェントを見て403を返すなど、別の層での対応が必要になります。
なお、robots.txtはユーザーエージェントごとのグループとして解釈される仕組みです。Meta系のクローラーに対してdisallowを書いても、Googlebotに対する指定には影響しません。ここを混同してUser-agent: *で広く書いてしまうと、意図せず検索エンジンのクロールまで止めてしまうため、対象を必ず限定してください。
今日からできる確認手順
まずは「自社が実際にどれだけクロールされているか」を数字で押さえるところからです。他社の観測をそのまま自社に当てはめる必要はありませんし、今回の報道はそもそも規模を示す数値を本文に載せていません。自社の数字は自社でしか取れません。
- サーバーのアクセスログを取得し、ユーザーエージェント欄に
meta-を含む行を抽出する。meta-externalagent、meta-webindexer、meta-externalads、meta-externalfetcher、facebookexternalhitのそれぞれについて件数を数える。レンタルサーバーの場合は管理画面から生ログをダウンロードできることが多いです。 - 件数は必ず「期間あたり」で見る。単位を決めずに総数だけを見ても比較になりません。日次で並べて、増えているのか一定なのかを確認します。
- あわせてサーバーの負荷指標(ロードアベレージ、CPU使用率、レスポンスタイム)を同じ期間で並べる。クロールが増えていても負荷に出ていないなら、急いで対処する話ではありません。
- どのURLが集中的に取得されているかを見る。サイト全体を面で巡回されているのか、特定のディレクトリに偏っているのかで、対応の方針が変わります。
- CDNやWAF(Cloudflareなどのボット管理機能)を使っている場合は、そちらのダッシュボードでもボット別のリクエスト数を確認する。オリジンのログに届く前に処理されている分があるためです。
- そのうえで方針を決める。負荷が問題なら、まずrobots.txtで対象クローラーを限定してdisallowを追加する。それでも収まらない場合、あるいは確実に止めたい場合は、サーバーやCDN側でユーザーエージェント単位の遮断を検討します。
- 止める場合は、Meta AIの検索結果からの露出を手放す判断になり得ることを、社内で合意しておく。特に
meta-webindexerはMeta自身が検索品質向上の用途と説明しているクローラーです。
※以下は運営者による一般的な実務上の補足です。robots.txtを変更したときは、変更日と対象ユーザーエージェントを記録に残しておくと、後日ログの件数が変わった理由を追えます。反映に最大24時間かかる点と合わせると、記録がないまま数日後に見返しても、変化の原因を切り分けられなくなりがちです。
所感
ここからは記事本文にはない、運営者の見解です。この件で最初に押さえるべきは、話が2つの層に分かれているということだと考えます。「Metaが検索品質向上のためのクローラーを運用している」という層と、「MetaがGoogle対抗の検索エンジンを製品として作っている」という層です。前者はMetaの公式ドキュメントで裏が取れますし、自社に来ているかどうかは自社のログで確かめられます。後者はLevels氏が伝え聞いた話であり、原文にもMetaの確認は載っていません。ここを一続きに語ると、観測が結論にすり替わってしまいます。
そのうえで、実務的に意味があるのは前者のほうだと考えます。meta-webindexerというユーザーエージェントが実在し、Metaがそれを「Meta AIの検索結果の品質を高めるため」と説明している以上、Meta AIに自社コンテンツが取り込まれる経路は、少なくとも設計としては用意されているということです。検索エンジンが製品として発表されるかどうかを待つ必要はなく、いま自社のログに何件来ているかは今日確認できます。ニュースの真偽を議論するより、自社の数字を取るほうが早いという状況です。
判断の難しさは、止める側にあります。AI学習用のクロールは「取られるだけ」に見えやすく、ブロックしたくなる気持ちは分かります。ただmeta-webindexerは、Metaの説明を素直に読む限り、引用と流入につながり得る側のクローラーです。両方をまとめて遮断すると、負荷は下がる代わりに露出の芽も同時に摘むことになります。ユーザーエージェント単位で書き分けられるのですから、まずは分けて考えるのが妥当でしょう。
最後に、robots.txtへの過信は避けたいところです。Metaの資料自身が、一部のクローラーについてrobots.txtを迂回することがあると書いています。robots.txtは「お願い」の層であり、強制力のある遮断ではありません。負荷の問題として本気で止めるなら、サーバーやCDNの層まで降りる必要がある、という前提で設計するのが安全です。
まとめ
・Search Engine Roundtableが2026年8月10日、Metaがウェブをクロールしており独自の検索エンジンを構築している過程にあるとされる、と報じた。執筆はBarry Schwartz氏。根拠は開発者Pieter Levels氏が2026年8月6日にXへ投稿した内容で、同氏自身が「ALLEGEDLY(とされる)」と大文字で留保しており、確定した事実ではない
・原文の本文には、クローラー名も、リクエスト件数も、集計期間も書かれていない。本文にあるのは、Levels氏が自身のプロパティのクロール状況を示すスクリーンショットを投稿した、という記述と、その投稿の埋め込みだけである。クロールの規模を示す数値をこの報道から引くことはできない
・Metaの公式コメントは原文に掲載されていない。ただしMetaの開発者向けドキュメントには、meta-webindexerが「Meta AIの検索結果の品質を高めるためにウェブを巡回する」、meta-externalagentが「基盤AIモデルの学習や、コンテンツを直接インデックスすることによる製品改善のためにクロールする」と記載されている。クローラーの存在は公式に確認できるが、検索エンジンの製品化をMetaが認めた事実はない
・原文はFacebookが10年以上前から独自の検索サービスを求めてきた経緯にも触れ、Bingとの提携とその解消を挙げている。Schwartz氏は、大手が自社AIを構築するにあたりウェブインデックスを提携先に依存できない以上、Metaにとって筋の通る次の一手だと述べているが、これは記者の見解である
・対応策として、Metaの資料は「これらのクローラーをブロックするにはrobots.txtに該当クローラーへのdisallowを追加する」としており、反映には最大24時間かかるとしている。ただしmeta-externalfetcherとfacebookexternalhitについてはrobots.txtを迂回することがあると同資料に明記されており、確実に止めるにはサーバーやCDN側での遮断が必要になる
よくある質問
Q1: Metaが独自の検索エンジンを構築しているというのは、確定した事実ですか?
確定した事実ではありません。原文は「構築しているかもしれない」という形で伝えており、根拠は開発者のPieter Levels氏が2026年8月6日にXへ投稿した内容です。Levels氏自身が投稿のなかで「ALLEGEDLY(とされる)」という語を大文字で強調しており、断定を避けています。同氏はMetaのスタッフから内密にDMを受け取ったと説明していますが、実名の関係者コメントやMetaの公式声明は原文に掲載されていません。確認できるのは、Levels氏が自身のサービスでクロールを観測し、その様子を示すスクリーンショットを公開したという事実までです。クロールの規模を示す数値は、原文の本文には記載されていません。
Q2: meta-externalagentとmeta-webindexerは、それぞれ何をするクローラーですか?
Metaの開発者向けドキュメントによれば、meta-externalagentは基盤AIモデルの学習や、コンテンツを直接インデックスすることによる製品改善といった用途でウェブをクロールするクローラーです。meta-webindexerは、利用者にとってのMeta AIの検索結果の品質を高めるためにウェブを巡回するクローラーと説明されています。同じページには、Metaのアプリ群で共有されたコンテンツを取得するfacebookexternalhit、広告やビジネス関連の製品・サービスの改善に用いるmeta-externalads、利用者の要求に応じて個別のリンクを取得するmeta-externalfetcherも記載されています。なお、これらの説明はMetaの公式資料に基づくもので、Search Engine Roundtableの記事本文には各クローラーの違いについての記述はありません。
Q3: Metaのクローラーを止めたい場合、robots.txtでどう書けばよいですか?
Metaの公式ドキュメントには「これらのクローラーをブロックするには、robots.txtに該当するクローラーへのdisallowを追加してください」と記載があります。robots.txtはユーザーエージェントごとのグループとして解釈されるため、対象をMeta系のクローラーに限定して書けば、Googlebotなど他のクローラーには影響しません。反映までには最大24時間かかるとされており、クローラーがrobots.txtを最大24時間キャッシュするためだと同資料は説明しています。ただし同じ資料では、meta-externalfetcherは利用者の要求に応じた取得を行うためrobots.txtを迂回することがあるとされ、facebookexternalhitもマルウェアや悪質なコンテンツの確認といったセキュリティ・健全性のチェック時に迂回することがあるとされています。確実に遮断したい場合は、サーバーやCDN側でユーザーエージェントを判定して403を返すなど、別の層での対応が必要です。
出典:Meta/Facebook Crawling Web & May Be Building Search Engine(Search Engine Roundtable、Barry Schwartz氏、2026年8月10日)https://www.seroundtable.com/meta-facebook-search-engine-41840.html
出典:Meta Web Crawlers(Meta for Developers)https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/
