Meta-ExternalFetcher

Meta-ExternalFetcher とは何か

Meta-ExternalFetcher は、ユーザーの操作（プロンプトやリンク指定）を起点に、Meta のAI製品機能が「今このタスクに必要な特定のリンク」をその場で取りに行くときに使うフェッチャーです。用途は、エージェントAI機能の評価・改善など製品機能のサポートで、AIがユーザーの代わりにWebを探してタスクを完了する動きを支えます。同じ Meta ファミリーの Meta-ExternalAgent（メタエクスターナルエージェント）が「訓練・インデックス用にWeb全体を広く巡回する学習・収集系」であるのに対し、Meta-ExternalFetcher は「ユーザーの指示を受けて個々のURLを単発で取りに行く取得系」で、性質がはっきり異なります。

サイト側から見ると、Meta-ExternalFetcher はUA文字列に「meta-externalfetcher」を含めて来訪します。Meta 公式が例示するUA文字列は「meta-externalfetcher/1.1 (+/documentation/sharing/webmasters/web-crawlers)」あるいは末尾の説明部分を省いた「meta-externalfetcher/1.1」です。したがってログ上では meta-externalagent（学習・収集系）と一文字違いで並ぶことがあり、混同しやすいので集計時は文字列を正確に区別する必要があります。

なぜ重要か（AI検索での位置づけ）

AI検索の可視化を測る観点では、Meta-ExternalFetcher の来訪は「ユーザー個別の閲覧に近い取得」であって、Web全体に対する学習でも、回答候補の一括索引化でもありません。ユーザーが Meta のAIに「このURLをまとめて」と頼んだ結果としての取得なので、来訪1件は「誰かが自社ページをAI経由で読もうとした」痕跡に近く、学習・収集系の来訪とは意味合いが違います。ここを混ぜて数えると、「学習された量」「回答候補に索引化された量」「ユーザー起点で読まれた量」がごちゃ混ぜになり、AI検索での実態を読み違えます。フェッチャーの来訪はユーザー行動の反映、学習系の来訪は将来の訓練候補——と分けて解釈するのが正解です。

仕組み（UA と robots.txt の例外）

Meta の robots.txt ドキュメントは、一般のクローラー（Meta-ExternalAgent 等）は robots.txt を尊重する一方で、「Meta-ExternalFetcher クローラーは、ユーザーのリクエストでフェッチを実行するため、robots.txt をバイパスする可能性がある」と特記しています。これは「robots.txt は自動クローラー向けの取り決めであって、ユーザー本人の閲覧までは止めない」という業界共通の前提に立つものです。したがって、Meta-ExternalFetcher の来訪を確実に止めたい場合は、robots.txt だけに頼らず、UAベースやIPベースのアクセス制御（＝サーバー側でのブロック）まで踏み込む必要があります。

この「フェッチャーは robots.txt を必ずしも尊重しない」という考え方は、Meta 固有のものではなく、主要各社に共通する設計思想です。たとえば Google は自社のクローラーを「一般クローラー」「特殊ケースのクローラー」「ユーザー起点のフェッチャー（user-triggered fetchers）」の3類型に分け、ユーザー起点のフェッチャーはエンドユーザーの操作を起点とする取得だと位置づけています。OpenAI（オープンエーアイ＝ChatGPT の開発企業）も、ユーザーが指定したURLをその場で取りに行く ChatGPT-User について、ユーザーが起点であるため robots.txt のルールが適用されない場合があると公式に説明しています。ただし全社共通ではありません。Anthropic（アンソロピック＝対話型AI「Claude」の開発企業）は、ユーザー起点の Claude-User を含む自社の全ボットが robots.txt の指示を尊重すると公式に説明しており、拒否指定が効きます。Meta-ExternalFetcher もこの系譜に連なる「ユーザー起点の取得系」であり、robots.txt が効かない前提で扱うのが、各社横断で見ても妥当な理解になります。

なお、なりすまし（UA詐称）の排除がここでも重要です。UA文字列に「meta-externalfetcher」を含むアクセスがあっても、それが本物の Meta かどうかはUA名だけでは確定できません。とりわけ Meta-ExternalFetcher はユーザー起点の単発取得のため、悪意あるスクレイパーが「ユーザー操作を装った取得」に見せかけて robots.txt をすり抜けようとする余地があります。したがって、遮断・許可・監視のいずれの判断でも、Meta が公開するIPレンジとの照合や逆引き（IPアドレスからホスト名を引き、Meta のドメインに属するかを確かめる二重照合）で裏を取ることが欠かせません。UA名の一致は出発点にすぎず、確度を上げるにはIP側の証拠を組み合わせる——これが未然に事故を防ぐ実務の勘所です。

• UA検知の手がかり：アクセスログのUA文字列に「meta-externalfetcher」を含むかで判別します（meta-externalagent と一文字違いなので厳密に区別します）。
• robots.txt の限界：拒否ルールを書いても、ユーザー起点の取得のため無視される可能性があります。確実に止めるにはサーバー側のUA／IPブロックを併用します。
• なりすまし対策：UA名は詐称可能なので、Meta の公開IPレンジや逆引きで本物かを確かめてから遮断・許可を判断します。
• 解釈の分離：フェッチャーの来訪はユーザー行動の痕跡、学習系の来訪は訓練候補——と意味を分けて集計します。

具体例・データ

たとえば、あるユーザーが Meta のAIに「このニュース記事を要約して」と自社URLを渡したとします。このとき Meta-ExternalFetcher が単発でその記事を取りに来ますが、これは「Web全体を学習のために巡回した」わけでも「回答候補として索引化した」わけでもありません。あくまでそのユーザーのタスク完了を助けるための個別取得です。したがって、この1件を学習・収集系（Meta-ExternalAgent）の来訪と同じ枠で数えると、「学習された量」を過大評価してしまいます。下の対比表のとおり、目的・robots.txt の効き方・AI検索での意味がそれぞれ違うことを踏まえて集計を分けてください。

AI検索最適化（AIO／GEO）の観点で見ると、Meta-ExternalFetcher の来訪は「ユーザーが自社ページをAI経由で読もうとした需要」を映す、貴重なシグナルにもなり得ます。学習・収集系の来訪が「将来の訓練候補」という長期の話であるのに対し、フェッチャーの来訪は「今この瞬間、誰かが Meta のAIに自社URLを渡した」という現在進行形の行動です。したがって、フェッチャーの来訪が特定ページに集中しているなら、そのページがAIユーザーの関心を集めている証拠として読み解けます。一律にブロックしてしまうと、こうした需要シグナルの観測機会も、AIユーザーへの情報提供の機会も同時に失う点に注意が必要です。止めるか通すかは、負荷やコンテンツ保護の必要性と、AI経由の可視化のメリットを天秤にかけて、ページ単位・目的単位で判断するのが賢明です。

よくある誤解・注意点

実務での扱い方

1. ログでUAを正確に分離する：meta-externalfetcher と meta-externalagent を一文字違いとして厳密に区別し、別カウントにします。
2. 止めたいなら多層で：robots.txt が効かない前提で、サーバー側のUA／IPブロックまで設計します。
3. IPで裏を取る：遮断・許可の判断は、UA名だけでなく Meta の公開IPレンジ・逆引きとの照合で行います。
4. 解釈を分ける：フェッチャーの来訪は「ユーザーがAI経由で読もうとした痕跡」として、学習系・回答系とは別の意味で扱います。
5. 過剰遮断に注意：ユーザー起点の取得を一律ブロックすると、自社ページをAIで読もうとしたユーザー体験を損なう可能性があるため、目的に応じてページ単位・目的単位で判断します。

よくある質問（FAQ）