AI・SEO対策

robots.txtの日本語パスはAIクローラーに通じるか｜Googleは明記、AI各社の文書は記載なし

2026年10月22日日高駿11分で読めます

「robots.txtに日本語のパスをそのまま書いても大丈夫。Googleはちゃんと読みます」。この説明は正しい。Googleの仕様書に、そう書いてあります。ただ、robots.txtを読みに来るのは、もうGoogleだけではありません。

Googleが生の日本語を読めても、ほかのクローラーが同じように読む保証は、AIクローラー各社の文書には書かれていない。だから規則は、エンコード済みの表記で書いておく。

先に言うと、今回取得できた28件を見る限り、多くは既に安全側にいました。危ないのは、これから日本語のスラッグ（URLの末尾の名前）を作るサイトです。取込層（LLMO）の話として、日本語のURLを持つサイトのSEO/GEO担当と、日本語サイトを新しく作る韓国・米国ブランドの日本の担当者に向けて書きます。

30秒でわかる

項目	内容
ひとことで	robots.txtの日本語パスはエンコード表記で書く。Googleは生でも読むと約束しているが、ほかのクローラーには約束がない
日本での適用範囲	日本語のURL（スラッグ・カテゴリ名）を持つサイト。旧サイトのShift_JISのURLが残る場合は別の点検が必要
なぜ今	AIクローラーを名指しする規則は、Google以外のパーサーが読む。Google Search Centralも2026年10月21日の動画でこの話題を取り上げた

「日本のrobots.txtは文字コードで崩れている」は、測ると当たらなかった

取得できた28件に、Shift_JISやEUC-JPのバイトで保存されたrobots.txtは1件もありませんでした。

日本のサイトにはShift_JISの長い歴史があります。robots.txtもその名残で崩れているのではないか。そう考えて、2026年10月22日に50件を計測しました。官公庁・自治体、EC・小売、メディア・ポータル、メーカー、飲食・宿泊、大学・団体、海外ブランドの日本サイト、不動産・求人・生活から業種を混ぜて選び、日本語のパスがありそうなサイトを狙っては選んでいません。

22件は、今回の計測では取得できませんでした（HTTP 404が10件、503が4件、403が3件、タイムアウトが3件、robots.txtの代わりにHTMLが返ったものが2件）。ボット対策や一時的な障害の可能性もあるため、この22件を「robots.txtがないサイト」とは扱っていません。

見たもの	取得できた28件での結果
ファイルのバイト	ASCII文字だけ：26件／日本語を含むUTF-8：2件／Shift_JIS・EUC-JP：0件
規則の行（Allow・Disallow など）に生の日本語	1件（ja.wikipedia.org）
Shift_JISとしてしか読めないパーセント表記の規則	0件
ファイル先頭のBOM（バイト順マーク）	2件（Googleは先頭のBOMを無視すると文書に明記）
HTTPヘッダーの文字コード宣言	text/plain（charset なし）：20件／charset=utf-8：7件／charset=shift_jis：1件

日本語を含むUTF-8の2件のうち、www.donki.com は日本語がコメント行（# で始まる行）にあるだけで、規則の行はASCIIでした。規則として日本語のパスを書いていたのは ja.wikipedia.org の1件です。

そのja.wikipedia.orgのファイルが面白い。552行のうち、生の非ASCII文字（日本語のほか、ドイツ語のウムラウトやヘブライ文字など）を含むパスの規則が57行、うち漢字・かなを含むものが38行。その38行のうち35行は、同じパスのパーセントエンコード版が同じファイルに並んでいました。例えば、こうです。

Disallow: /wiki/Wikipedia:削除依頼
Disallow: /wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC
Disallow: /wiki/Wikipedia%3A%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC

生の表記、エンコード版、コロンまでエンコードした版。並べた理由はファイルからは分かりませんが、どちらの表記で比べる読み手にも一致する形です。

ヘッダーで charset=shift_jis を宣言していた1件（www.jalan.net）は、中身がASCIIだけでした。今の中身に日本語はないので、宣言とのずれが規則の読み方に響く場面は見当たりません。日本語の規則を書き足したときに、初めて問題になり得る組み合わせです。

Googleの仕様書とRFC 9309が書いていること

Googleは「生でもエンコードでも同じ」と明記し、RFC 9309は「比較の前にエンコードせよ」と定めている。どちらも、ファイル自体がUTF-8であることが前提です。

「ルール内のパスは、raw UTF-8 文字またはパーセントエンコードされた UTF-8 文字列（RFC 3986 に基づく）のいずれかにすることができます。」「これは、たとえば Disallow: /foo/bar/ツと Disallow: /foo/bar/%E3%83%84 がパーサーによって同等に扱われることを意味します。」
Google 検索セントラル「Google による robots.txt の指定の解釈」（日本語版）

同じ文書は、ファイルの形式にも条件を付けています。

「robots.txt ファイルは、UTF-8 エンコードされた書式なしテキストファイルでなければならず」「robots.txt ファイルの文字エンコードが UTF-8 でない場合、Google が UTF-8 範囲外の文字を無視した結果、robots.txt ルールが無効と解釈される可能性があります。」
同上

robots.txtの標準であるRFC 9309は、同じことをもっと硬い言葉で書いています。

"Octets in the URI and robots.txt paths outside the range of the ASCII coded character set … MUST be percent-encoded … prior to comparison."（Section 2.2.2）

"The file MUST be UTF-8 encoded"（Section 2.3）

"Implementors MAY bridge encoding mismatches if they detect that the robots.txt file is not UTF-8 encoded."（Section 2.2.2）
RFC 9309 "Robots Exclusion Protocol"

パスのASCII外のバイトは、比較の前にパーセントエンコードしなければならない（MUST）。規則を生の日本語で書いても、規格に従う読み手は内部でエンコード版に直してから比べます。Googleの「同等に扱う」も、Googleの文書自身がこの Section 2.2.2 を根拠に挙げている。ファイルはUTF-8でなければならず（MUST）、UTF-8でないと気付いたときに橋渡しするかどうかは実装者の任意（MAY）。Shift_JISで保存したrobots.txtは、規格に従うクローラーにとっても「読んでくれたら運が良い」側に置かれています。

AIクローラーの文書には、文字コードの話が出てこない

5社のクローラー文書を encod・UTF・percent・9309 で全文検索しても、パスの文字コードとRFC 9309への言及はありませんでした。

事業者	文書が扱うクローラー	パスの文字コード／RFC 9309の記載
OpenAI	GPTBot・OAI-SearchBot・ChatGPT-User	なし
Anthropic	ClaudeBot・Claude-SearchBot・Claude-User	なし
Perplexity	PerplexityBot・Perplexity-User	なし
Apple	Applebot・Applebot-Extended	なし
Common Crawl	CCBot	なし

AnthropicとAppleは、robots.txtの「標準」に従うと書いています。Anthropicは "honoring industry standard directives in robots.txt"、Appleは "Applebot respects standard robots.txt directives"。ただ、その標準がRFC 9309を指すのかは、どちらも名指ししていません。Googleの場合、クローラー一覧の文書にはこの話がなく、robots.txtの仕様書の側に書かれています。文書一つで「記載なし」とは決められません。

ここで読み違えたくないのは、「書かれていない」は「対応していない」ではないという点です。各社のクローラーも、実際には生の日本語をエンコードして比べているのかもしれません。外からは分からない。言えるのは、Googleと表の5社を合わせた6社のうち、パスの扱いを文書で約束しているのはGoogleだけだということです。

参照実装の一つで試すと、崩れたのはShift_JISが混ざったときだった

参照実装の一つ、Python標準ライブラリの urllib.robotparser では、UTF-8である限り、生の日本語でもエンコード版でも結果は同じでした。

手元で確かめられる実装として、Python 3.13.5 の urllib.robotparser を使いました。AIクローラー各社が実際に使っているパーサーではありません。規則の書き方で結果が変わるかを見るための目安です。

規則の書き方＼アクセスするURL	生の日本語	UTF-8のパーセント表記	Shift_JISのパーセント表記
生の日本語（Disallow: /商品/セール/）	ブロック	ブロック	通過
UTF-8のパーセント表記（/%E5%95%86%E5%93%81/%E3%82%BB%E3%83%BC%E3%83%AB/）	ブロック	ブロック	通過
Shift_JISのパーセント表記（/%8F%A4%95%69/%83%5A%81%5B%83%8B/）	通過	通過	ブロック

結果が割れたのは、規則とURLの文字コードが食い違ったときだけです。RFC 9309の照合はバイト（オクテット）単位で、"The match evaluates positively if and only if the end of the path from the rule is reached before a difference in octets is encountered." と書かれています。「商品」はUTF-8なら %E5%95%86%E5%93%81、Shift_JISなら %8F%A4%95%69。バイトが違えば、同じ文字でも一致しません。

Shift_JISのバイトで保存したrobots.txt（中身は User-agent: * と Disallow: /商品/セール/ の2行）も読み込ませました。この実装は規則を一行も解釈しないまま、文字コードのエラー（UnicodeDecodeError）で止まっています。

担当者の言葉で言い換えると

問うべきは「Googleが読めるか」ではありません。「一番融通の利かない読み手でも、同じ意味になるか」です。

robots.txtは一つのファイルを、作りの違う何種類ものパーサーが読みます。Googleのパーサーは生の日本語を自分でエンコードし直してくれる。規格もそうしろと言っている。それでも、規格にどこまで従うかを文書で約束していない読み手がいる以上、変換を読み手に任せない形のほうが確実です。

Google Search Relations の Cherry Prommawin 氏は、10月21日公開の動画でこう話しています（発言は Search Engine Roundtable の書き起こしによる）。

"…other or older crawlers on the web might get confused. To be safe across the entire global internet infrastructure, you should use the encoded version in your robots.txt rules."
Cherry Prommawin, Google Search Central「Non-Canonical Cabinet」第2話（2026-10-21）

同じ場面で同氏は、処理できない読み手は Disallow の行ごと無視して、守りたい場所までクロールしてしまうかもしれない、とも続けています。

robots.txtの規則は「ここには入らないでほしい」という意思表示です。読み手によってそれが消えるなら、書いていないのと変わらない。守るべきは書き手の意図で、文字コードはそのための手段にすぎません。

危ないのは、これから日本語のスラッグを作るサイト

今回取得できた28件を見る限り、今あるrobots.txtの多くは安全側にあります。リスクが生まれるのは、日本語のURLを新しく作り、その規則を誰かが生の日本語で書き足す瞬間です。

海外ブランドが日本語サイトを立ち上げるとき

本国のサイトは英語のスラッグ。日本向けには /ja/セール/ や /ja/店舗一覧/ のように、カテゴリ名を日本語で作ることがあります。キャンペーンが終わったページを隠そうとして、本国のSEO担当が Disallow: /ja/セール/ と書き足す。Googleでは効きます。そのほかのクローラーで効くかどうかは、文書からは確かめられません。本国の運用チームは日本語の文字コードを意識したことがない、という前提で、手順書の側で手当てしておく。

AIクローラーを名指しして規則を書くとき

User-agent: GPTBot や User-agent: ClaudeBot の下に日本語のパスを書く。その行を解釈するのは、Googleのパーサーではありません。AIクローラーごとに許可と拒否を分ける設計にしているサイトほど、ここで差が出ます。規則がどの単位で効くかは本国の「AI除外」設定は日本向けドメインに届くかでも整理しました。

旧サイトのShift_JISのURLが残っているとき

Shift_JISが関わるのは、ファイルよりもURLのほうです。古いCMSで作ったページのURLが、もし %8F%A4%95%69 のようにShift_JISのバイトでエンコードされたまま残っているなら、規則をUTF-8で書いても、上の試験の通りURLと一致しません。Gary Illyes 氏は動画で "mirror what your server expects and actually write its percent-encoded form." と話しています。サーバーが実際に受け取るURLの形を確かめ、その形をエンコード済みで書く。旧サイトを移行・統合するときの点検項目に入れておけば足ります。

始めるなら、ここから

日本語サイトを持つ海外ブランドの日本の担当者が、まずやることは一つです。本国チームの手順書に「robots.txtの日本語のパスはパーセントエンコードで書く」と書き足すこと。本国への報告にも「Googleで効いているから、ほかのクローラーでも効くとは言えない」と添えておくと、話が早くなります。

サイトの点検は、ターミナルでコマンドを数本打てば終わる。

規則の行に生の日本語がないか見る：curl -s https://example.jp/robots.txt | perl -ne 'print "$.: $_" if /[^\x00-\x7F]/' で、ASCII以外を含む行が行番号付きで出ます。# で始まるコメント行は、クローラーが読み飛ばすので気にしなくて構いません。
見つかったら、UTF-8のパーセント表記に直す：python3 -c "from urllib.parse import quote; print(quote('/商品/セール/'))" は /%E5%95%86%E5%93%81/%E3%82%BB%E3%83%BC%E3%83%AB/ を返します。移行の間は ja.wikipedia.org のように生の行を残して併記しても、Googleの解釈では同じ規則が二重になるだけです。
ファイルとヘッダーの文字コードを見る：curl -s https://example.jp/robots.txt | file - の答えが ASCII か UTF-8 なら、ファイルは規格の範囲。curl -sI https://example.jp/robots.txt の Content-Type に charset=shift_jis とあれば、宣言と中身のどちらに合わせるかを決めましょう。
日本語のURLがShift_JISで残っていないか見る：サイトマップのURLを python3 -c "from urllib.parse import unquote; print(unquote('%8F%A4%95%69', errors='strict'))" の形で戻してみる。UTF-8として解釈できれば日本語が出て、できなければエラーで止まる。Shift_JISのバイト列は多くの場合ここで弾かれ、この例の %8F%A4%95%69 もエラーになりました。