Meta、独自AI検索エンジン構築か　クローラー急増で『脱Google』観測情報

Meta、独自AI検索エンジン構築か　クローラー急増で『脱Google』観測情報が浮上

要点: 2026年8月上旬、インディー開発者Pieter Levels氏がMeta社員からの匿名DMとして「Metaが独自のWeb検索インデックスを構築中」との情報をXで公開し、同時期に自身のサイトへのMeta由来スクレイピングが「heavy heavy heavy」な規模だったと報告した。別の起業家Marc Lou氏も、直近3日間のMetaのAI学習目的クロール数が67,390件（OpenAIの約165倍、Anthropicの約93倍）に達したというデータを投稿し、話題が拡大した。 これらはあくまで観測・報道ベースの情報であり、Meta公式からの確認・コメントは記事執筆時点（2026年8月11日）で一切出ていない。 断定はできないが、2024年10月に報じられていた「Meta独自AI検索エンジン」構想が2年越しで具体化しつつある状況証拠として注視する価値がある。

最終更新日: 2026年8月11日

何が起きたのか

発端：Pieter Levels氏の「Meta社員からの匿名DM」投稿（8月6日）

2026年8月6日、連続インディー開発者として知られるPieter Levels氏（X: @levelsio）が、X上で気になる投稿を行った。要旨は「Meta staff DM'd me secretly（Metaの社員が密かにDMをくれた）」というもので、その社員（匿名）によれば、Metaは現在、Googleに依存しない独自のWeb検索インデックスを構築中だという。目的として説明されているのは、Meta AIがユーザーの質問に答える際にWeb検索を行う場面で、検索処理をGoogle経由にしないようにすることだ。仮にMeta AIの検索クエリがGoogleを経由してしまえば、そのクエリ内容自体がGoogle側に渡り、Googleが自社のAIモデル学習や検索改善に利用できてしまう可能性がある——競合であるMetaにとって、それを避けたいというのが匿名情報源の説明する動機である。

この投稿が単なる噂話以上の説得力を持って拡散した理由は、Levels氏自身が同じタイミングで、具体的な「実害」を報告していたからだ。同氏は自身のブログ（levels.io/meta-heavy-scraping-my-sites-url2og）で、画像スクリーンショット生成サービス「url2og」をはじめとする複数の自社サイトに対し、Meta由来とみられるスクレイピングが「heavy heavy heavy」——つまり非常に重い規模で行われ、運用しているVPS（仮想専用サーバー）でロードアベレージのアラートが発報するほどの負荷がかかったと明かしている。Levels氏はこのスクレイピングの目的について、テキストベースの検索インデックス構築だけでなく、画像・動画・いわゆる「ワールドモデル」（実世界の視覚的・物理的な構造を学習するAIモデル）の学習データ収集ではないかと推測を述べている。ただし、これはLevels氏個人の推測であり、Meta側からの説明は伴っていない点には注意が必要だ。

Marc Lou氏によるクロール量データの投稿（同時期）

Levels氏の投稿とほぼ同時期に、別の起業家Marc Lou氏（X: @marclou）が、Webトラフィック分析サービスTrustMRRのデータを引用する形で、AI学習目的とみられるクロール数の比較データを投稿した。それによれば、直近3日間のAI学習目的クロール数は次の通りだったという。

• OpenAI: 409件
• Anthropic: 721件
• Meta: 67,390件

単純計算でMetaのクロール量はOpenAIの約165倍、Anthropicの約93倍という規模になる。この数字の大きさが、Levels氏の「heavy heavy heavy」という体感的な報告を裏付ける形となり、両者の投稿が連動して拡散した。もっとも、TrustMRRのサンプル対象サイトの規模や業種、計測期間の代表性については公開情報だけでは検証できず、この数値をそのまま業界全体の一般的な比率として扱うことには慎重さが必要だ。あくまで「一部のインディー開発者が運営する複数サイトで観測された、直近数日間のスナップショット」という位置づけで理解すべきデータである。

Search Engine Roundtableによる報道（8月10日）

これらSNS上の一連の動きを受けて、2026年8月10日、検索業界の老舗メディアであるSearch Engine Roundtable（Barry Schwartz氏）が「Meta/Facebook Building Search Engine, Crawling Web」と題する記事を公開し、報道として取り上げた。

Search Engine Roundtableの記事で強調されているのは、Meta公式からの確認・コメントは一切出ていないという点だ。記事内でも "no official confirmation from Meta" と明記されており、あくまでLevels氏・Lou氏の投稿とそれに伴う業界内の憶測を整理・紹介する内容にとどまっている。Search Engine Roundtableは検索エンジンの仕様変更やアルゴリズムアップデートを長年扱ってきたメディアであり、こうした未確認情報を扱う際にも「観測情報である」というトーンを崩さない書き方をしている点は、読者としても参考にすべき姿勢だろう。

本記事でも同じ立場を取る。「Metaが検索エンジンを作った」という断定はできない。あくまで「作っている可能性を示す観測情報が複数浮上し、それを業界メディアが報道した」という段階に過ぎない、という前提で以下を読み進めてほしい。

背景：2024年10月にも同種の構想が報じられていた

実は、Metaが独自のAI検索エンジンを模索しているという話自体は、今回が初出ではない。2024年10月28日（今回とは2年近く前の報道である点に注意）、調査報道メディアThe Informationが「Meta Develops AI Search Engine to Lessen Reliance on Google, Microsoft」と題する記事で、Metaが独自のAI駆動検索エンジンを開発中であり、GoogleおよびBing（Microsoft）への依存を減らす狙いがあると報じていた（TheWrap経由でも報じられている）。

2024年時点の報道内容を整理すると、以下のような構想だったとされる。

• この検索エンジンはWebをクロールし、Meta AIチャットボット（Facebook・Instagram・WhatsApp・Messengerに統合。当時の月間利用者数は約32.7億人規模とされていた）のユーザーに対し、時事的な話題についての会話型の回答を提供する設計だったとされる
• 同時期にMetaはニュース通信社Reutersと契約を締結し、Meta AIの回答内でReutersのコンテンツを引用・リンクし、その対価を支払う仕組みを発表していたことも報じられている

つまり2024年10月の時点で、「Metaが検索の自前化を模索している」という方向性そのものはすでに報道されていた。今回2026年8月に浮上した一連の観測情報（社員からの匿名DM、急増するクロール量、業界メディアの報道）は、この2年越しの構想が、実際のクロール活動という形で具体化しつつある可能性を示す新しい状況証拠、という位置づけで理解するのが妥当だろう。ただし、2024年の報道と2026年の観測情報が同一プロジェクトの進捗を指しているのか、それとも別の取り組みなのかについても、公式な言及がない以上は確定的なことは言えない。

AIクローラー活動全体の業界データ（Meta固有の話とは切り分けて理解する）

今回のMeta関連の観測情報とは別に、2026年8月5日に公開された業界分析「Crawl-to-Refer Ratio 2026」（nobori.ai、データソースはCloudflare RadarおよびDataDome AI Traffic Report Q2 2026）でも、AIクローラー全般の活動量に関する興味深いデータが示されている。

2026年6月時点の「クロール対リファラル比率」（サイトへのクロール回数と、そこから実際にサイトへ送客された回数の比率）は、以下のように報告されている。

この比率が意味するのは、たとえばAnthropicのクローラーはサイトを4,580回クロールする一方で、実際にそのサイトへユーザーを送客するのは1回程度、という極端な非対称性だ。Googleの5:1と比べると、AI企業各社のクロールが「サイトから情報を持っていくだけで、送客にはほとんど貢献しない」構造になっていることが浮き彫りになっている。

同じ分析の中で、Metaは2026年第2四半期（Q2）に主要AI企業の中で最大のクローラーになったと報告されている。ただし、この記事にはMeta固有のクロール対リファラル比率の具体的な数値は明記されていない。したがって本記事でも「比率は公表されていないが、クロール量として最大規模のクローラーになった」という表現に留める。

また、DataDome側の観測データでは、AI関連クロール総数が2026年第1四半期の12.2億件から第2四半期には17.7億件へと、四半期成長率45%で増加したと報告されている。この45%という成長率は、AI業界全体のクロール総量の伸びを示す一般的な業界トレンドのデータであり、Meta単体のクロール量が45%増えたという意味ではない点は明確に区別して理解する必要がある。Levels氏・Lou氏が報告した「直近数日間のMetaクロールの急増」という個別の観測情報と、このQ2業界全体トレンドは、時期も対象も異なる別々のデータソースであり、混同すべきではない。

aiseo-llmo.com ユーザーへの影響

今回の一連の動きが、日本のマーケター・SEO/LLMO担当者にとってなぜ注視に値するのか。実務的な影響は大きく2つの軸に整理できる。

1. 短期的な影響：Meta系AIクローラーによるサーバー負荷とアクセスログの変化

Levels氏の報告が示す通り、Metaのクロール活動がすでに「一部サイトでVPSのロードアベレージアラートが出るほどの負荷」を発生させている以上、これは検索順位やAI引用云々以前に、まずインフラ・サーバー運用上の実務課題として現れる可能性がある。特に以下のようなサイトは影響を受けやすい。

• 画像・動画コンテンツを多く保持するメディアサイト、ポートフォリオサイト、ECサイトの商品画像ページ
• 動的にレンダリングされるページが多く、1リクエストあたりのサーバー処理コストが高いサイト
• CDNやキャッシュ設定が不十分で、クローラーのリクエストがオリジンサーバーに直接届いてしまう構成のサイト

これまでGPTBot（OpenAI）やClaudeBot（Anthropic）、PerplexityBotといったAIクローラーへの対応を検討してきた事業者は多いはずだが、Metaのクロール規模がMarc Lou氏の観測データ通りであれば、Meta系クローラーへの対応が後回しになっていたサイトほど、急激な負荷増に不意打ちを食らうリスクがある。

2. 中長期的な影響：Meta AIが新たなLLMO対象サーフェスになる可能性

より本質的な論点は、仮にMetaが本当に独自のAI検索・Web索引を構築しているとすれば、Facebook・Instagram・WhatsApp・Messengerという合計数十億人規模のユーザーベースを持つMeta AIが、GoogleやChatGPT Search、Perplexityと並ぶ「AI検索・引用サーフェス」になり得るという点だ。

現時点でLLMO（大規模言語モデル最適化、/glossary/llmo参照）やGEO（生成エンジン最適化、/glossary/geo参照）の実務では、ChatGPT・Perplexity・Google AI Overviewsでの引用最適化が主な対象になっているケースが多い。しかしMeta AIが独自のWeb索引を持ち、検索的な機能を強化していけば、Meta AIでの引用・言及も新たなAIO（/glossary/aio参照）対策の対象として加わってくる可能性がある。特にMeta AIはFacebook・Instagram上の会話UIに直接統合されているため、他のAI検索サービスとは異なる導線・利用文脈を持つ点も踏まえておきたい。

ただし繰り返しになるが、これはあくまで「観測情報が正しければ」という仮定の上に立つ将来シナリオである。現時点でMeta AIが独自インデックスに基づく検索結果や引用機能を一般公開しているという確認情報はない。過剰な先回り投資は避けつつ、「準備だけはしておく」という距離感が適切だろう。

業種別の実務インパクトの違い

• メディア・ニュースパブリッシャー: 2024年の報道で言及されたReutersとの契約のように、MetaがAI回答内での引用に対して対価を支払う仕組みを構築する可能性がある。ニュース系パブリッシャーは今後、Metaとの個別契約や引用ポリシーの動向を注視する価値がある業種だ。
• 画像・動画コンテンツを持つサイト: Levels氏が推測する「画像・動画・ワールドモデル学習」目的のクロールが事実であれば、写真素材サイト、動画共有サービス、ビジュアル重視のポートフォリオサイトなどは特に負荷・データ利用の両面で影響を受けやすい。
• ECサイト: 商品画像・商品説明文が大量にクロールされることで、サーバー負荷の増加に加え、無断学習への懸念という論点も生じる。robots.txtでの許可・ブロック方針を業種特有の視点で検討する必要がある。
• BtoB・SaaS: 現時点でMeta AIの利用者はBtoC寄りのコミュニケーション文脈が中心と見られるため、直接的な引用機会の急拡大は他業種と比べて緩やかかもしれない。ただし将来的にMeta AIがビジネス用途の検索機能を強化する可能性もあり、静観しつつ動向を追う姿勢が妥当だ。

Xでの反応（分かる範囲で）

Levels氏・Lou氏の投稿は、開発者コミュニティを中心に活発な反応を呼んでいる。共通する論調としては、「AI企業各社が自社サイトのコンテンツを一方的に大量クロールしている一方、送客（リファラル）はほとんど発生していない」という不満・懸念が背景にあり、その中でもMetaのクロール規模の大きさが際立って注目された、という構図だ。これは前述のnobori.aiのクロール対リファラル比率のデータが示す「AI企業のクロールは持っていくだけで返さない」という業界全体の構造的な不満とも重なるテーマであり、Meta固有の話題というより、AIクローラー全般への警戒感が高まる中でMetaの件が象徴的な事例として取り上げられた面もありそうだ。なお、これらはX上の反応の傾向として観測されるものであり、統計的な集計データに基づくものではない点は付記しておく。

今すぐできる対応策

Meta公式の確認がない以上、大規模な戦略転換を急ぐ必要はない。しかし「クロール量の急増」自体はLevels氏やMarc Lou氏の報告により実際に観測されている現象であるため、サーバー負荷とアクセスログの両面で、今すぐ着手できる実務対応を整理する。

ステップ1: 現在確認されているMeta系User-Agentを把握する

Metaは公式に複数のクローラー・フェッチャーのUser-Agentを公開している。robots.txtでの制御を検討する前に、まず現状把握から始めたい。代表的なものは以下の通りだ（2026年8月時点で公開が確認できているもの）。

• meta-externalagent: MetaのAI（Meta AIなど）の学習・検索改善などに利用されるクローラーとされる
• Meta-ExternalFetcher: ユーザーがMeta製品（Facebook、WhatsAppなど）でリンクを共有した際に、そのリンク先ページを取得するために動作するフェッチャー。ユーザー操作に紐づくオンデマンド型のアクセスで、学習目的ではないとされる
• FacebookBot: Facebook製品向けにコンテンツを理解・改善する目的で使われるとされるクローラー
• facebookexternalhit: OGP（Open Graph Protocol）情報取得など、リンクプレビュー生成のために古くから稼働しているクローラー

重要な注意点: 今回話題になっている「独自Web検索インデックス構築」が事実であった場合、上記のいずれかの既存User-Agentがそのまま流用されるのか、それとも新しい専用のUser-Agent（たとえば検索インデックス専用の名称）が登場するのかは、記事執筆時点では確認されていない。したがって「特定の1つのUser-Agentだけをブロックすれば十分」と考えるのではなく、アクセスログ全体で「Meta」「facebook」を含むUser-Agent文字列を継続的に監視する体制を整えることが重要になる。

ステップ2: robots.txtでのUser-Agent別ポリシーを整理する

自社の方針（AI学習には使わせたくないが検索的な引用は許容したい、あるいは全面ブロックしたい、など）に応じて、User-Agentごとに個別のディレクティブを設定する。以下は設定例のイメージだ（実際の適用前に自社の方針・法務判断を確認すること）。

# 例1: AI学習目的とみられるクローラーのみブロックし、
# リンクプレビュー用のフェッチャーは許可する方針の場合

User-agent: meta-externalagent
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Meta-ExternalFetcher
Allow: /

User-agent: facebookexternalhit
Allow: /

# 例2: Meta系クローラーを一括で厳格にブロックする方針の場合
# （Meta AIでの将来的な引用機会も含めて遮断するトレードオフを理解した上で採用する）

User-agent: meta-externalagent
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Meta-ExternalFetcher
Disallow: /

# 例3: 現時点では静観し、すべて許可した上でログ監視を強化する方針の場合
# （新しいUser-Agent名が登場していないか継続確認する前提）

User-agent: meta-externalagent
Allow: /

User-agent: FacebookBot
Allow: /

User-agent: Meta-ExternalFetcher
Allow: /

どの方針を採るべきかは一律には決められない。将来Meta AIが検索・引用サーフェスとして重要になった場合に備えて露出を確保したいのか、それともサーバー負荷や無断学習への懸念を優先してブロックするのか、自社のコンテンツ戦略と照らして判断する必要がある。robots.txtの基本的な考え方や他のAIクローラーとの整理方法については、AIクローラーとrobots.txtの索引戦略や学習用ボットと検索用ボットを分離するrobots.txt戦略で詳しく解説している。CloudflareでAIクローラーを管理している場合は、Cloudflare Content Signals Policyのrobots.txt設定ガイドも参照してほしい。

ステップ3: アクセスログでMeta系クローラーの挙動を監視する

robots.txtの設定だけでは「実際に守られているか」「どの程度の頻度でアクセスが来ているか」は把握できない。サーバーのアクセスログ（Nginx、Apache、あるいはCDN側のログ）から、Meta系User-Agentのアクセス頻度を定期的に集計する仕組みを用意したい。

# 例: Nginxアクセスログから直近1日のMeta系クローラーアクセスを集計する（擬似コマンド）
grep -iE "meta-externalagent|facebookbot|meta-externalfetcher|facebookexternalhit" \
  /var/log/nginx/access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 例: 時間帯別のアクセス数推移を確認し、急増タイミングを特定する（擬似コマンド）
grep -iE "meta-externalagent|facebookbot" /var/log/nginx/access.log | \
  awk '{print $4}' | cut -d: -f1-2 | sort | uniq -c

このようなログ監視を週次・日次で回し、「特定日にMeta系クローラーのアクセスが平時の何倍になったか」を追跡できるようにしておくと、Levels氏が報告したような突発的な負荷増にも早期対応しやすくなる。GPTBot・ClaudeBot・PerplexityBotなど他のAIクローラーとあわせたログ分析の実装例は、AIクローラーのログ分析（GPTBot・ClaudeBot・GEO視点）で具体的な手順を紹介している。

ステップ4: サーバー・CDN側での負荷対策を検討する

robots.txtはあくまで「お願いベース」の制御であり、すべてのクローラーが厳密に遵守する保証はない。実際の負荷対策としては、以下のような技術的な緩和策も並行して検討したい。

• CDN（Cloudflareなど）でのレート制限（Rate Limiting）ルールを、特定User-Agentからの過剰なリクエストに対して設定する
• キャッシュ設定を見直し、クローラーのリクエストがオリジンサーバーまで到達する頻度を減らす
• 画像・動画などリソースの重いコンテンツについては、専用のCDN配信・帯域制限を検討する

ステップ5: Meta AIでの言及・引用状況を継続的にモニタリングする

将来的にMeta AIが検索・引用機能を強化した場合に備え、今のうちからMeta AI（Facebook・Instagram・WhatsApp内のAIチャット機能）で自社ブランド・サービス名がどのように言及されるかを定期的にチェックしておくことも有効だ。ChatGPTやPerplexityでのブランド言及最適化と同様の考え方をMeta AIにも適用する視点は、Meta AIアシスタントでのブランド引用最適化で詳しく扱っている。

よくある質問

Q1. Metaは本当に独自の検索エンジンを作っているのですか?

記事執筆時点（2026年8月11日）で、Meta公式からの確認・発表は一切ありません。あくまで観測情報・報道ベースの話です。

Pieter Levels氏がXで「Meta社員からの匿名DM」として投稿した情報と、実際に観測されたクロール量の急増データ、それを取り上げたSearch Engine Roundtableの報道を組み合わせると「可能性が高い」と推測できる状況ではありますが、Meta自身がこれを公式に認めたり否定したりしたという事実は確認されていません。断定的な表現は避け、「観測情報が浮上している」という段階として理解する必要があります。

Q2. なぜMetaが独自検索エンジンを作る動機があると考えられているのですか?

匿名情報源によれば、Meta AIがWeb検索を行う際にGoogle経由にすると、検索クエリの内容がGoogle側に渡ってしまい、競合であるGoogleに利用されるリスクがあるためだとされています。

Meta AIがユーザーの質問に答える過程でWeb検索が必要になった場合、その検索処理を外部の検索エンジン（Google等）に依存すると、検索クエリという貴重なユーザーインタラクションデータが競合他社に渡ってしまう可能性があります。この依存を断ち切り、検索処理を自社で完結させることが、独自インデックス構築の動機として説明されています。ただしこれもあくまで匿名情報源の説明であり、Meta公式の説明ではありません。

Q3. Metaのクロール量が他社の90倍以上というのは本当ですか?

Marc Lou氏がTrustMRRのデータとして投稿した「直近3日間: Meta 67,390件 / OpenAI 409件 / Anthropic 721件」という数字に基づく比較です。この特定のデータセットでは事実ですが、業界全体を代表する数値かどうかは別途検証が必要です。

TrustMRRの計測対象サイトの規模・業種・期間の代表性については公開情報だけでは十分に検証できません。あくまで「一部のインディー開発者が運営する複数サイトで、直近数日間に観測されたスナップショット」というデータの性質を理解した上で参照するべきです。傾向として「Metaのクロール量が際立って多い」ことを示す一つの根拠にはなりますが、これをそのまま「Metaは常に他社の90倍クロールする」という一般法則として扱うのは慎重であるべきです。

Q4. 2024年の「Meta AI検索エンジン」報道と、今回の話はどう違うのですか?

2024年10月28日のThe Information報道は「Metaが独自AI検索エンジンを開発中」という構想段階の報道でした。今回2026年8月の一連の観測情報は、その構想が実際のクロール活動として具体化している可能性を示す、より新しい状況証拠という位置づけです。

2024年時点の報道では、開発中の検索エンジンがWebをクロールしてMeta AIチャットボット利用者に時事的な会話回答を提供する設計だとされ、同時にReutersとのコンテンツ引用契約も発表されていました。2026年8月の観測情報（社員の匿名DM、急増するクロール量）が、この2024年の構想の延長線上にあるプロジェクトを指しているのか、まったく別の取り組みなのかは、公式な言及がない以上確定できません。ただし時系列として「2年前に構想が報じられ、今回クロール活動の急増が観測された」という流れ自体は、無関係とみなすより関連性を疑う方が自然な解釈でしょう。

Q5. 自社サイトへのMeta系クローラーのアクセスが急に増えた場合、どう対応すればよいですか?

まずアクセスログでUser-Agentを確認し、サーバー負荷が問題になっているならCDNのレート制限やキャッシュ設定の見直しで緩和し、それでも懸念が強い場合はrobots.txtで該当User-Agentをブロックする、という順序で対応するのが実務的です。

Meta系クローラーには学習目的のmeta-externalagentやFacebookBot、ユーザー操作に紐づくオンデマンド型のMeta-ExternalFetcher、リンクプレビュー用のfacebookexternalhitなど複数の種類があります。一律にすべてをブロックするのではなく、自社の方針（学習には使わせたくないがリンクプレビューは許可したい、など）に応じてUser-Agentごとに個別設定することを推奨します。具体的なrobots.txt設定例は本記事の「今すぐできる対応策」セクションを参照してください。

Q6. robots.txtでMetaのクローラーをブロックすれば、完全に守られますか?

いいえ。robots.txtはクローラー側の自主的な遵守に依存する「宣言」であり、法的強制力や技術的な遮断効果はありません。確実な負荷対策にはCDN側でのレート制限など、ネットワークレベルの制御も併用する必要があります。

robots.txtに書かれたDisallowディレクティブは、あくまでクローラー運営者が自主的に守るというルールに基づいています。悪意あるスクレイパーや、robots.txtを遵守しない実装のクローラーには効果がありません。確実にアクセスを制限したい場合は、CloudflareなどのCDN・WAFレベルでのUser-Agentベースのブロックやレート制限ルールを併用することが望ましいです。

Q7. Meta AIが将来、検索・引用のサーフェスとして重要になった場合、何を準備しておくべきですか?

ChatGPTやPerplexity向けに行っているのと同様の、AI検索エンジンに引用されやすいコンテンツ構造（明確な見出し、FAQ形式、一次情報の提示など）を整えておくことが基本的な準備になります。

現時点でMeta AIが独自インデックスに基づく検索・引用機能を一般公開しているという確認情報はありませんが、仮に将来そうした機能が実装された場合に備え、他のAI検索エンジン向けのLLMO・GEO対策（構造化された情報提示、FAQスキーマの活用、独自データ・一次情報の充実など）をあらかじめ整えておくことは、Meta AI特有の対策ではなく汎用的なAIO対策として今から着手する価値があります。あわせてMeta AI上での自社ブランドの言及・引用状況を定期的にモニタリングしておくとよいでしょう。

Q8. なぜSearch Engine RoundtableはMetaの検索エンジン開発を断定的に報道しなかったのですか?

Meta公式からの確認・コメントが一切得られていないためです。同メディアは記事内で明確に「no official confirmation from Meta」と記載し、あくまで観測情報の整理・紹介という立場を取っています。

Search Engine Roundtableは検索エンジンのアルゴリズム変更や業界動向を長年扱ってきた専門メディアであり、未確認情報を扱う際には出典と確度を明確に区別する姿勢を持っています。今回の記事でも、Pieter Levels氏やMarc Lou氏の投稿内容をそのまま事実として断定するのではなく、「そうした観測情報が浮上している」というトーンで報じています。本記事もこの姿勢を踏襲し、断定を避けた書き方を採用しています。

Q9. クロール対リファラル比率（Crawl-to-Refer Ratio）とは何ですか? Metaにも当てはまりますか?

クロール対リファラル比率とは、AIクローラーがサイトを訪問した回数と、そのAIサービス経由で実際にサイトへユーザーを送客した回数の比率を示す指標です。nobori.aiの分析では、Anthropicが約4,580:1、OpenAIが約848:1などと報告されていますが、Meta固有の比率数値はこの分析では公表されていません。

同分析では「Metaは2026年第2四半期に主要AI企業の中で最大のクローラーになった」とだけ報告されており、具体的な比率は明記されていません。したがって「Metaのクロール対リファラル比率は◯:1である」といった断定はできない状態です。この点は本記事でも意図的に「比率は公表されていないが、クロール量として最大規模になった」という表現に留めています。

Q10. AIクロール全体がQ2に45%増えたというデータと、今回のMetaの話は同じ現象を指していますか?

いいえ、別々のデータです。DataDomeが報告するAIクロール総数の45%成長（Q1: 12.2億件→Q2: 17.7億件）は、AI業界全体の一般的なトレンドを示すデータであり、Meta単体のクロール量の増加率を示すものではありません。

Levels氏・Lou氏が報告した「直近数日間のMetaクロールの急増」は、それとは別の、個別サイトでの観測情報です。時期・対象・データソースがそれぞれ異なるため、これらを混同して「Metaのクロールが45%増えた」のように記述するのは不正確です。本記事でも両者を明確に切り分けて解説しています。

関連記事

• AI検索最適化ガイド——LLMOとSEOの統合戦略
• LLMO完全ガイド
• AIクローラーとrobots.txtの索引戦略
• 学習用ボットと検索用ボットを分離するrobots.txt戦略
• Cloudflare Content Signals Policyのrobots.txt設定ガイド
• AIクローラーのログ分析（GPTBot・ClaudeBot・GEO視点）
• Meta AIアシスタントでのブランド引用最適化
• Cloudflareの「AIボットブロック」設定でGooglebotも巻き添えに
• JavaScriptナビゲーションはAI検索から見えない——41日間の実験が実証

用語の詳細は、LLMO、GEO（生成エンジン最適化）、robots.txt、AIO の各用語解説もあわせて参照してください。