Claudeの共有会話がGoogle検索に露出した理由｜robots.txtとnoindexの違い・自環境の確認手順

2026年7月25日、Claudeで共有した会話やArtifactがGoogle検索の結果に表示される、という報告が広がった。多くの記事は「noindexタグが無かったのが原因」と説明している。ただ、実際に claude.ai/robots.txt を見ると、共有ページのパスは11か月前から Disallow で塞がれていた。塞いでいたのに、なぜ検索結果に出たのか。ここが今回いちばん面白く、そしてすべてのWebサービス開発者に効く教訓を含んでいる部分だ。本記事は編集部が実際のHTTPヘッダとWayback Machineの保存版を検証し、その仕組みを解いたものである。

セキュリティ全般の防御フレームワークは サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

1. 何が起きたのか——2026年7月25日からのタイムライン

まず事実関係を時系列で整理する。日付は各報道および編集部の実測に基づく。推測が混じる箇所は明示した。

報道されているAnthropicの説明は「利用者にはClaudeの会話を公開共有する制御が与えられており、プライバシー原則に沿ってGoogleのような検索エンジンにチャットのディレクトリやサイトマップを提供してはいない。共有リンクは推測可能でも発見可能でもなく、利用者自身が共有を選ばない限り公開されない」という趣旨のものだ。この説明自体は、後述する技術的な事実関係と矛盾しない。サイトマップを出していなくても、共有リンクが外部に貼られていれば検索エンジンはそこからURLを知りうる、という点が今回の核心である。

2. robots.txtで塞いでいたのに、なぜ検索結果に出たのか

ここが本題である。多くの解説は「noindexが無かったから」で止まっているが、Disallow は最初からあった。両者は別の仕事をしている。

2-1. Disallow は「読むな」、noindex は「載せるな」

・robots.txt の Disallow は、クローラに対して「このパスの中身を取得しないでほしい」と伝える指示である。あくまでクロール（本文の取得）の制御であって、検索結果への掲載可否とは別レイヤーの話になる
・noindex（<meta name="robots" content="noindex"> または HTTPレスポンスヘッダの X-Robots-Tag）は、「このページを検索結果に載せないでほしい」と伝える指示である。掲載可否そのものを制御する

この2つは目的が違うので、片方だけでは目的を達成できない場面が出てくる。今回はまさにその典型だった。

2-2. 「読ませない」と「noindexが届かない」というジレンマ

Googleの公式ドキュメント（Search Central）は、この点について明確な注意書きを置いている。原文の要旨はこうだ。

つまり、Disallow と noindex を同時に指定すると、後者が前者によって無効化される。クローラはページを取得しないので、そこに書かれた「載せないで」という指示を読む機会が永久に来ない。

では Disallow されているページはどうやって検索結果に載るのか。Googleはクロールしていなくても、他のサイトからのリンクを通じてURLの存在自体は把握できる。共有リンクがXの投稿やブログ、公開Slack、フォーラムなどに貼られていれば、そこからURLが知られる。この場合、本文を取得していないので通常はスニペット（説明文）のない、URLとリンク先のアンカーテキストだけの控えめな検索結果になる。

2-3. それでも「中身」が見えたのはなぜか

ここで疑問が残る。Disallow でクロールしていないのなら、検索結果に出るのはURLだけのはずで、会話の中身までは索引化されないのではないか。この疑問が、実は今回の一番重要な発見につながっている。答えは次章にある。

3. 実測でわかった2つの事実——ヘッダ差分とrobots.txtの履歴

3-1. 会話とArtifactではレスポンスヘッダが違う

編集部は2026年7月28日、Googlebotを名乗るUser-Agentで claude.ai の各パスにリクエストを送り、レスポンスヘッダを比較した。結果は明確に分かれた。

# 共有会話のパス
$ curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    "https://claude.ai/share/00000000-0000-0000-0000-000000000000" | grep -i "x-robots-tag"
x-robots-tag: none

# 公開Artifactのパス
$ curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    "https://claude.ai/public/artifacts/00000000-0000-0000-0000-000000000000" | grep -ci "x-robots-tag"
0

# robots.txt に /public を対象とする行はあるか
$ curl -s https://claude.ai/robots.txt | grep -c "public"
0

「存在しないUUIDだから何も返っていないだけではないか」という疑いは、対照実験で潰せる。存在しないパスを投げると挙動がはっきり分かれた。

デタラメなパスは 403 を返す。つまり /public/artifacts/ が 200 を返すのはサーバがそのルートを実在するものとして扱っているからであり、SPAが何でも200で返す「キャッチオール」ではない。読み取れることを整理する。

・/share/* には x-robots-tag: none が返っている。robotsディレクティブの語彙において none は noindex, nofollow と同等である（Google公式の仕様ページに「Equivalent to noindex, nofollow」と明記）。つまり共有会話のパスには現在、明確な「載せるな」指示が付いている
・Claude Codeが発行するArtifact（/code/artifact/*）にも同じヘッダが付いている
・上記6パスのうち、200を返しながら x-robots-tag を持たないのは /public/artifacts/* だけだった
・claude.ai/robots.txt には /public を対象とする行が1行も無い。Disallow されているのは /new?* /chat/* /share/* /join/* /magic-link* /api/* /onboarding* /upgrade* /lti/* /settings* /task* である

会話（/share/*）は Disallow されていたためクロールされず、検索結果に出たとしてもURL中心の控えめな形になりやすい。一方でArtifact（/public/*）は Disallow の対象外なので、クローラはページを普通に取得できる。取得できて、かつ noindex も無ければ、中身まで含めて索引化される。Artifactは性質上、ダッシュボードや文書、ミニWebアプリといった「読める成果物」であるため、索引化されたときの情報量が大きい。

3-2. /share/* を塞いだのは11か月前だった——Wayback Machineでの検証

「noindexが無かった」という説明は結果としては正しい。しかし、Anthropicがインデックス制御に無関心だったわけではない、という事実がWayback Machineの保存版から読み取れる。

編集部は claude.ai/robots.txt の保存版を時系列に取得し、/share/* の行がいつ現れたかを特定した。

# 2025-08-01 10:51 UTC の保存版
$ curl -s --compressed "https://web.archive.org/web/20250801105159id_/https://claude.ai/robots.txt"
User-Agent: *
Disallow: /new?*
Disallow: /chat/*
Disallow: /settings/*
Disallow: /magic-link*
# → /share/* の行は無い

# 2025-08-02 00:46 UTC の保存版（約14時間後）
$ curl -s --compressed "https://web.archive.org/web/20250802004634id_/https://claude.ai/robots.txt"
User-Agent: *
Disallow: /new?*
Disallow: /chat/*
Disallow: /share/*      # ← 追加されている
Disallow: /settings/*
Disallow: /magic-link*

Disallow: /share/* は 2025年8月1日から2日にかけての約14時間の間に追加されている。この時期は、ChatGPTの共有会話が検索結果に現れて大きく報じられ、OpenAIが該当機能を撤去した時期と重なる。因果関係を断定する材料は無いが、同種のリスクが業界的に意識されたタイミングで、共有パスへの制限が入ったという時系列は事実として確認できる。

そして皮肉なことに、Disallow を先に入れたこと自体が、後から noindex を効かせにくくする要因にもなる。すでに検索結果に登録されてしまったURLを消すには、クローラにページを取得させて noindex を読ませる必要があるが、Disallow が残っているとその取得が行われない。2026年7月28日時点でも Disallow: /share/* と x-robots-tag: none は同居している。この状態が実運用でどう振る舞うかは、Google側の処理（サイト所有者向けの削除ツールの利用有無など）にも依存するため、外部からは断定できない。ここでは「Googleの公式ドキュメントが注意を促している組み合わせが、現在も併存している」という事実の指摘にとどめる。

4. インデックス制御の4つの層——noindexはどこで効くのか

今回の件を一般化すると、「URLを知っていれば誰でも見られるページ」を持つすべてのサービスに共通する設計問題になる。露出を止める手段は4層あり、効く場面が違う。

重要なのは、L1からL3までは「検索エンジンに対する制御」でしかないという点だ。リンクを受け取った人がそれを転載したり、アーカイブサービスに保存したり、スクリーンショットを撮ったりすることは止められない。共有リンクの本質は「知っていれば開ける」ことであり、検索結果から消えることと、そのURLが無効になることはまったく別の話である。

L4だけが、リンクを配った後にコントロールを取り戻せる層になる。有効期限、いつでも取り消せる失効操作、閲覧にログインを要求するアクセス制御といった手段がここに入る。共有機能を設計する側は、L1〜L3で満足せず、L4を用意しているかを自問する価値がある。

L4が後回しにされやすい理由もはっきりしている。共有機能の価値は「摩擦の少なさ」にあるからだ。ログインを要求すれば共有相手が減り、有効期限を短くすれば「開けなくなった」という問い合わせが増える。プロダクトとしての使いやすさと、事故が起きたときの取り返しやすさが正面から衝突する。この衝突をどう解くかは各サービスの判断だが、少なくとも「既定値をどちらに置くか」は設計の意思表示になる。無期限・認証なしを既定にしているなら、それは「共有されたものは基本的に取り戻せない」という前提を利用者に引き受けさせている、ということでもある。

もう一点、L2とL3には共通の限界がある。どちらもクローラ側の自主的な遵守が前提という点だ。robots.txt も noindex も、それに従う意思のあるクローラにしか効かない。従わない収集ボットやアーカイブサービスに対しては、L4の認証・失効しか実効性を持たない。「検索エンジンに出ない」ことと「機械的に収集されない」ことは別物であり、前者を達成しても後者は保証されない。

5. 対策——noindexの実装と、自分の共有リンクの点検

ここからは読者が実際に手を動かす部分である。対象は「自分のアカウント」と「自分が運用するサービス」の2つに分かれる。

5-1. 利用者としての対策：共有リンクの棚卸し

Claudeの設定画面から共有済みリンクの一覧を開き、不要になったものを削除する。判断基準は「このURLが第三者の手に渡っても構わないか」であって、「検索結果に出ているか」ではない。検索結果から消えていても、リンクを知っている人は引き続き開ける。

あわせて、これまでに共有した会話の中身を思い出しておきたい。実務でよく混入するのは次のような情報である。

・APIキー・アクセストークン・接続文字列などの認証情報
・社内システムのホスト名・内部URL・ディレクトリ構成
・顧客名・取引先名・未公表の製品名や日程
・個人情報（氏名・連絡先・health/財務に関する記述）
・エラーログやスタックトレースに含まれる環境の詳細

該当するものがあれば、リンクの削除だけでなく、鍵のローテーションなど情報そのものへの対処が要る。この観点は 【公式検証】Claudeに送ったデータは学習に使われる？セキュリティ・プライバシー・ガバナンス完全ガイド で、送信データの範囲とプラン別の扱いを含めて整理している。そもそも機密を入力段階で止める方向の対策としては PasteGuard｜LLMに貼る前に機密情報を止めるプライバシープロキシ のようなアプローチもある。

5-2. 運用者としての対策：自社サービスの点検コマンド

共有機能・プレビュー機能・レポート出力など、「URLを知っていれば見られる」ページを持つサービスは、以下のコマンドで自分の設定を実測できる。推測ではなく実際のレスポンスを見ることが重要だ。

# ① 対象ページが noindex 相当を返しているか（ヘッダ）
curl -sI "https://example.com/share/xxxx" | grep -i "x-robots-tag"

# ② HTML内の meta robots も確認する（SSRしている場合）
curl -s "https://example.com/share/xxxx" | grep -io '<meta[^>]*name="robots"[^>]*>'

# ③ 同じパスを robots.txt で Disallow していないか
curl -s "https://example.com/robots.txt"

# ④ 検索エンジン向けの応答が変わる設計になっていないか
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     "https://example.com/share/xxxx" | grep -iE "x-robots-tag|^vary"

判定は単純である。

・②または①で noindex（もしくは none）が返り、③で当該パスが Disallow されていない → 正しく効く構成
・①②で noindex が返るのに、③で同じパスが Disallow されている → noindexがクローラに届かない。Disallow を外す判断が要る
・①②のどちらにも noindex が無い → クロール可能なら中身ごと索引化されうる
・④で vary: User-Agent が返る場合、UAによって応答が変わる設計になっている。検証は必ず検索エンジンのUAでも行う

すでに検索結果に登録されてしまったページを消したい場合の順序も間違えやすい。先に Disallow を外し、noindex を読ませ、検索結果から消えたことを確認してから、必要なら Disallow に戻す。逆順にすると、登録済みのページが消えないまま残る。急ぐ場合はSearch Consoleの削除ツールを併用する。

5-3. 設計としての対策

コマンドで塞ぐのは対症療法に近い。共有機能を持つサービスなら、設計段階で次を検討したい。

・共有リンクにデフォルトの有効期限を設ける（無期限を既定にしない）
・共有一覧とワンクリックの失効を利用者に提供する
・共有ページのレスポンスに X-Robots-Tag: noindex をサーバ側で無条件に付与する（アプリ側のmetaタグだけに頼らない）
・共有時のUIで「リンクを知っている全員が閲覧できる」ことを明示する
・機密が混入しやすい経路（ログ貼り付け・設定ファイル共有）を想定した警告を出す

5-4. 影響範囲——誰が、何を、どこまで影響を受けるか

影響の大小は「何を共有したか」でほぼ決まる。共有していない会話は対象外である。

回避できない条件は「過去に共有リンクを発行し、そのURLが外部に出ている」ケースである。検索結果から消えても、リンクを保存した第三者、キャッシュ、アーカイブサービスに残った分までは遡及できない。したがって、機密が含まれていた場合の実質的な対処は、リンクの削除ではなく情報そのものの無効化（鍵のローテーション、関係者への通知など）になる。

なお、共有リンクは推測で当てられる形式ではない。ランダムなUUIDが割り当てられており、総当たりで他人の会話に到達することは現実的でない。今回問題になったのは「外部に出たリンクが検索エンジンに拾われた」経路であって、URLの推測可能性ではない。

5-5. 機密が含まれていた場合の事後対応

共有した会話に機密が含まれていたと判明した場合、リンクの削除は出発点であって到達点ではない。検索結果からの消滅、リンクの失効、情報そのものの無効化は、それぞれ別の作業である。優先順位は「取り消せないもの」から着手するのが原則になる。

・認証情報が含まれていた場合：APIキー・トークン・パスワードは即座にローテーションする。リンクを消しても、既に閲覧・保存された可能性は否定できない。鍵の無効化だけが確実な対処になる
・内部構成が含まれていた場合：ホスト名・内部URL・ディレクトリ構成は、それ自体を「変更」するのが難しい。攻撃面の縮小（該当エンドポイントの認証強化、外部公開の見直し）で補う
・個人情報が含まれていた場合：組織として扱っている個人情報であれば、社内の情報セキュリティ規程に沿った報告経路に乗せる。露出範囲の特定が難しくても、判断は担当部門に委ねるのが安全である
・取引先・顧客の情報が含まれていた場合：自社だけの判断で完結しない。契約上の通知義務の有無を確認する

あわせて、露出期間の見積もりも行いたい。共有リンクをいつ発行し、いつどこに貼ったかがわかれば、露出しうる期間の上限が絞れる。検索結果に載っていたかどうかは、自分が発行したURLについてSearch Consoleや検索での直接確認である程度は追える。ただし「載っていなかった」ことの証明は原理的に難しいため、機密が含まれていた場合は露出したものとして扱うのが安全側の判断になる。

6. ChatGPTの件と何が違うのか

2025年8月にも、ChatGPTの共有会話がGoogle検索に現れて大きく報じられた。現象は似ているが、失敗した層が違う。

ChatGPTのケースでは、「このチャットを検索で見つけられるようにする」というopt-inのチェックボックスが実際に存在した。ユーザーが自分でそれを有効にした結果として検索対象になったため、問題の本質は「その選択の意味が利用者に正しく伝わるUIだったか」という同意設計にあった。OpenAIは短命な実験だったと説明し、意図しない共有の機会を生みすぎるとして機能自体を撤去している。それでも、削除前に10万件規模がアーカイブに保存されていたと研究者が指摘しており、いったん公開されたものを取り戻す難しさが残った。

今回のClaudeのケースには、そもそも検索公開のopt-inが存在しない。利用者は「リンクを知っている人と共有する」つもりで操作しており、その理解自体は仕様と一致している。ずれていたのは配信側のインデックス制御であり、同意設計ではなく設定の層で起きた問題だった。

この違いは対処にも効いてくる。同意設計の失敗はUIの作り直しか機能撤去でしか直せないが、設定の失敗はヘッダ1行で直せる。一方で、設定の失敗は外から見えにくく、気づくのが遅れるという別の難しさを持つ。今回、Disallow が入っていたことで「対策済み」に見えていたことがまさにそれで、robots.txtを開いた人は問題が無いと判断しかねなかった。

同種の構図は他社サービスでも起こりうる。実際、AIアシスタントの共有機能は各社が似た形で提供しており、「リンクを知っていれば見られる」設計は広く採用されている。利用者側でできるのは、共有した内容を把握しておくことと、機密を入力しないことに尽きる。データ漏洩が起きた後の対応手順については Campfire情報漏洩から学ぶセキュリティ対策ガイド2026 も参考になる。

7. まとめ——共有機能を持つすべてのサービスへの教訓

今回の件から取り出せる実務的な教訓を整理する。

今回の件で最も示唆的なのは、対策が「打たれていなかった」のではなく「打たれていたが、別の問題を解く対策だった」という点である。Disallow: /share/* は2025年8月から存在し、robots.txtを開いた人には対策済みに見えた。しかし解いていたのはクロールの問題で、インデックスの問題ではなかった。

セキュリティ設定のレビューでは「設定が入っているか」を確認しがちだが、確認すべきなのは「その設定が、いま防ぎたい事象に効いているか」である。両者はよく似ていて、しかも前者だけを見ると安心してしまう。今回のように、実際にヘッダを1回投げて確かめれば分かることが、設定ファイルの見た目からは分からないという例は珍しくない。

この種の取り違えは、レビューの体制で防ぐより、実測を手順に組み込む方が確実だ。共有機能をリリースする際のチェックリストに「検索エンジンのUAでヘッダを1回取得し、noindex 相当が返ることと、同じパスが robots.txt で塞がれていないことを両方確認する」と書いておけば、設定ファイルの見た目に頼らずに済む。設定の意図と実際の挙動がずれていないかは、外から1リクエスト投げれば分かる。

自社サービスに共有・プレビュー・公開レポートの機能があるなら、この記事の5-2にあるコマンドを一度流してみてほしい。所要時間は1分に満たない。今回のような事故は、技術的に難しい見落としというより、2つのよく似た仕組みの役割を取り違えたことで起きている。取り違えたまま運用されている共有機能は、おそらく他にもある。

参照ソース

• [Block Search indexing with noindex

  Google Search Central](https://developers.google.com/search/docs/crawling-indexing/block-indexing) — noindex の指定方法（metaタグ / X-Robots-Tag）と、robots.txtでブロックされたページでは noindex が機能しないことの公式な記述

• [Introduction to robots.txt

  Google Search Central](https://developers.google.com/search/docs/crawling-indexing/robots/intro) — robots.txtの役割と、ブロックされたURLが他サイトからのリンク経由で検索結果に表示されうることの公式な説明

• claude.ai/robots.txt（2025-08-02 保存版・Wayback Machine） — Disallow: /share/* が追加された直後の保存版
• claude.ai/robots.txt（2025-08-01 保存版・Wayback Machine） — 追加される前の保存版。約14時間差で比較できる

• [Robots meta tag, data-nosnippet, and X-Robots-Tag specifications

  Google Search Central](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag) — none が noindex, nofollow と同等である旨を含む、robotsディレクティブの語彙仕様