Meta「Muse」日本で開始、クローラー文書にMuseの名はない｜日本語28サイトのrobots.txt実測

「MetaのAIエージェント『Muse』、日本で提供開始」。このニュースは、スマホアプリの話として読まれています。ただ、サイトを管理する側には別の問いが残ります。Museがブラウザを開いてあなたのサイトに来たとき、サーバーのログには何と記録されるのか。Metaのクローラー文書を端から端まで読んでも、その答えは見つかりません。

結論を先に書きます。Metaのクローラー文書（日本語版・英語版）には、「Muse」という名前も、Museが使うユーザーエージェント（UA）も載っていません。文書にあるのは役割の違う5種類のクローラーで、そのうちユーザーのリクエストで動くMeta-ExternalFetcherについては「robots.txtのルールを無視する可能性があります」と明記されています。2026年10月22日に私たちが日本語サイト28件のrobots.txtを確かめたところ、Meta系のUAを指定した規則があったのは4件でした。手を付けるべきは「Museを止めるかどうか」ではない。Metaのボットを役割ごとに書き分けているかどうかです。

---

何が発表されたか

日本は、北米の次にMuseが届いた地域です。

Metaの日本語版ニュースルームによると、Museは10月23日（日本時間）から日本で提供が始まりました。iOS、Android、muse.aiで使えます。発表文は日本を「今年9月に先行して提供を開始した北米以外で、初めての提供地域」と位置付けています。

地域の書き方には一点だけ注意が要ります。2026年9月8日付の英語版発表は「Muse is rolling out in the US」と書いており、挙がっている地域名は米国だけです。「北米」は日本語版の表現で、英語原文から読み取れるのは米国までです。本社やクライアントへの報告では、どちらの原文を引いたかを添えておくと話がずれません。

サイト側にとって効いてくるのは機能のほうです。Museは「ブラウザを開き、フォームに入力するなど、利用者に代わって」操作を進めると説明されています。質問に答えるだけのチャットではなく、利用者の代わりに他社のサイトを開きに行くエージェントです。連携先としてはStripe、Shopify、Trip.com、Agoda、Klookなどのグローバルサービスが挙がりました。日本のメルカリ、マネーフォワード ME、チケットぴあについては「連携を進めて参ります」という書き方で、提供開始の時点ではまだ連携を進めている段階として発表されています。

Metaのクローラー文書に「Muse」は出てこない

文書が説明しているのは、5種類のクローラーの役割です。Museとの対応を探すと、手掛かりになる説明文は一つに絞られます。

Meta for Developersの「Meta Web Crawlers」（10月26日確認）に載っているのは次の5つです。

クローラー（UA）	文書が説明する用途	robots.txtについての記述
FacebookExternalHit	Facebook・Instagram・Messengerなどで共有されたリンクのタイトル、説明、サムネイル画像の取得	セキュリティや整合性のチェック時はrobots.txtを「バイパスする可能性があります」
Meta-WebIndexer	「Meta AI検索結果の品質向上」	許可すると「Meta AIの回答でのコンテンツの引用やリンクが可能」になる
Meta-ExternalAds	広告やビジネス関連の商品・サービスの改善	robots.txtの記載例に登場
Meta-ExternalAgent	「基盤AIモデルのトレーニング」や商品の改善	robots.txtの記載例に登場
Meta-ExternalFetcher	ユーザーのリクエストに応じた個々のリンクの取得	「robots.txtのルールを無視する可能性があります」

このクローラー文書の日本語版・英語版と、英語版のリンク共有FAQを全文検索しました。「Muse」は0件です。9月と10月のMuse発表記事、Metaの研究ブログ2本にも、クローラー、robots.txt、ユーザーエージェントへの言及はありませんでした。

Museの機能を思わせる記述なら、Meta-ExternalFetcherの説明の中に一つある。

「Meta-ExternalFetcherクローラーは、ユーザーのリクエストに応じて個々のリンクを取得し、エージェントAI機能の評価や改善など、製品機能をサポートします。これには、AIがウェブサイトを探してユーザーのタスクを完了するのを支援することが含まれます。そのため、このクローラーはrobots.txtのルールを無視する可能性があります。」

Meta for Developers「Meta Web Crawlers」（日本語版）

「AIがウェブサイトを探してユーザーのタスクを完了する」。Museの説明と重なる言い回しではあります。それでもこの一文はMuseを名指ししていない。MuseがこのUAで来るのか、別の名乗り方をするのか、文書からは判断できません。「MuseはMeta-ExternalFetcherで来る」と言い切る解説を見かけたら、原文に戻って確かめてください。

Museの通信の仕組み自体は、Metaの研究ブログがかなり細かく書いています。外部とのやり取りは利用者のMuseとは別に動く「Sentinel」というエージェントが管理し、通信の評価対象として「ホスト名、名前解決後の最終的な宛先IPアドレス、ポート、プロトコル、HTTPメソッド、パス」などを挙げる。安全対策の説明としては具体的です。ところが、受け取る側のサイトから見てその通信がどう名乗るのかには、触れていません。

robots.txtで指定できる範囲は、文書の上でも限られている

文書のrobots.txtの節は、クローラーの役割ごとに効き方が違う前提で書かれています。

文書のrobots.txtの節は、ブロックしたいクローラーにDisallowを書くよう案内しています。ただ、記載例に出てくるのはmeta-externalagentとmeta-externaladsの2つです。続く段落では、Meta-ExternalFetcherについて「ユーザーのリクエストでフェッチを実行するため、robots.txtをバイパスする可能性があります」と書かれています。FacebookExternalHitも、セキュリティや整合性のチェック時には同じ扱いです。

反映にも時間差があります。文書によれば、クローラーはrobots.txtの内容を「最大で24時間キャッシュする可能性がある」。書き換えた直後の数時間は、古い規則で読まれ得る前提で動くことになります。

文書はMeta系のUAを用途で分けています。学習に使うのはMeta-ExternalAgent、Meta AIの回答での引用やリンクに関わるのはMeta-WebIndexer、ユーザーのリクエストで個々のページを取りに行くのはMeta-ExternalFetcher。「学習には使われたくないが、Meta AIの回答では引用されたい」という方針は、ExternalAgentとWebIndexerを別々に書かないと表現できません。「Metaのボットを全部止める」も「全部通す」も、この区別を潰してしまいます。

日本語28サイトのrobots.txtに書かれていたMeta系UA

28件のうちMeta系UAを指定した規則を持っていたのは、ニュースサイト3件とレシピサイト1件でした。

MuseがどのUAで来るのかは、今の文書からは分かりません。名乗りの分からない通信は、名前では止められない。サイト側に残る手段は、文書に載っている役割ごとの指定です。その指定が日本語サイトでどこまで書かれているかを、実測で確かめました。

MenuMenuは2026年10月22日（09:02 JST）、日本語ユーザー向けのサイト50件を業種混合で選び、robots.txtを取得しました。HTTP 200で本文が返り、HTMLページではなかったものだけを数え、取得できたのは28件です。この28件のUser-agent行のうち、MetaとFacebookのUAを名指ししたものを、大文字・小文字を区別せずに数えました。

UA	指定したサイト（28件中）	書かれていた規則
Meta-ExternalAgent	4件（nikkei.com・asahi.com・nhk.or.jp・cookpad.com）	4件とも Disallow: /（asahi.comは Allow: /ads/ を併記）
Meta-ExternalFetcher	2件（nikkei.com・asahi.com）	Disallow: /（asahi.comは Allow: /ads/ を併記）
FacebookBot	3件（nikkei.com・asahi.com・cookpad.com）	Disallow: /（asahi.comは Allow: /ads/ を併記）
Meta-WebIndexer	0件	なし
Meta-ExternalAds	0件	なし
FacebookExternalHit	0件	なし

この4件を除く24件のrobots.txtには、Meta系UAの名前が出てきません。標本に入れた海外ブランドのサイト4件（innisfree.jp・amorepacific.com・samsung.com・apple.com）も、指定は0件でした。

書かれていた規則は、どれも「止める」側です。Meta AIでの引用を受けたい側の指定（Meta-WebIndexer）は、この標本では一行も見当たりませんでした。

FacebookBotには別の問題があります。3件が指定していたこのUAは、10月26日時点のMetaのクローラー文書には項目がありません。今の文書に載っていないUAへの規則と、載っているUAへの規則が同じファイルに並んでいる。robots.txtが文書の更新に追い付いているかどうかは、サイトごとに確かめるしかありません。

この数字には限界があります。28件は業種を混ぜて任意に選んだ標本で、日本語サイト全体の比率を示すものではありません。数えたのは「UAを指定した規則がある」サイトの数で、Metaのボットが実際に止まっているかどうかではない。指定がないことも、Metaのボットを許可しているという意味にはなりません。同じ標本で日本語パスの文字コードを調べた結果はrobots.txtの日本語パスはAIクローラーに通じるかにまとめています。

名前の分からない相手には、役割で備える

Museの名乗り方が文書に載る日は、いずれ来るかもしれません。そのとき一行足せば済む状態にしておくのが、今できる備えです。

Museの日本開始で、Metaのシステムが日本語サイトを開きに来る理由が一つ増えました。文書に名前のないUAでも、役割が分かれば置き場所は決まります。学習を断る行、引用を受ける行、ユーザーのリクエストをどう扱うかの方針。この三つが先に書いてあれば、新しい名前が文書に載った日に、どの役割の行に足すかを決めれば終わる。「Metaのボットを全部止める」一行しか書いていないサイトは、その日に方針から決め直すことになります。

日本の担当者が今やるべきこと

• Meta系UAの方針を、役割ごとに書き出す：学習のMeta-ExternalAgent、Meta AIでの引用のMeta-WebIndexer、ユーザーのリクエストで動くMeta-ExternalFetcher。この3つについて「許可するか」を表にし、今のrobots.txtの記述と突き合わせます。引用されたいのに全てのMetaボットを止めていないか、今の文書にないFacebookBotの行だけで済ませていないかも、ここで分かります。
• 本国サイトの方針と、日本語ドメインのrobots.txtを並べる：英語版の発表によれば、Museは9月に米国で提供が始まりました。本国サイトでMeta系UAをどう指定したかを確かめ、日本語サイトのrobots.txtと一行ずつ比べます。日本向けサイトが別ドメインなら、robots.txtも別ファイルです。設定が効く単位は本国の「AI除外」設定は日本向けドメインに届くかで整理しました。
• アクセスログでmeta-externalfetcherを探す：文書が示すUA文字列は「meta-externalfetcher/1.1」です。10月23日以降のログで、これと「meta-externalagent/1.1」「meta-webindexer/1.1」の出現を日付ごとに見ておく。Museの通信がどれに当たるかを文書が明かしていない以上、自社のログが手掛かりになります。
• robots.txtの一行で「止めた」と報告しない：ExternalFetcherには、robots.txtの規則を書いても届かない場合があります（文書上、無視し得る）。書き換えた後も、キャッシュの最大24時間を待ってからログで確かめる。本社への報告には「規則を書いた」と「アクセスが止まった」を分けて書きます。

参考資料

• Meta（日本語版ニュースルーム）「Muse」日本での提供開始の発表（2026年10月）
• Meta Newsroom "Introducing Muse"（2026年9月8日）
• Meta for Developers「Meta Web Crawlers」（2026年10月26日確認）
• Meta AI Research「Museに安全性を組み込むための取り組み」
• MenuMenu実測：日本語サイト50件（取得28件）のrobots.txt、2026年10月22日09:02 JST取得