2026年7月、ユーザーがGoogleのサイト検索構文を使用してClaudeユーザーの共有会話履歴を一括で抽出できることに気づいた。その理由は、Claudeの共有機能が秘密リンクではなく公開ウェブページを生成していたためであり、ページにはrobots.txtによる保護はあったが、重要なnoindexメタタグが欠けており、検索エンジンがページのURLとコンテンツを両方収録していた。検索結果には、ユーザーの暗号通貨ウォレットの秘密鍵や社会保険番号などの機密情報が含まれていた。現在、Anthropicは緊急に対応し、noindexタグを追加してさらなる収録を阻止した。この問題は孤立したものではなく、OpenAIのChatGPTおよびxAIのGrokも以前、まったく同じプライバシー脆弱性を経験している。

記事執筆者、出典：雷峰網

暗号通貨の秘密鍵から身元情報まで、Redditで他人の情報を覗き見る風潮が広がっている。

具身知能が煙のたぎる厨房に進出

百万のトラフィックにおけるボットのバイト記

前Covariant AI副社長、舟譜データCTOの慕巍博士が「枢途科技」のCTOに就任。

創設チームが剛剛亮相，這家物理AI初創公司的融資與股東陣容也隨之浮出水面。

Beta Infinityは、兆ドル規模の消費者向けロボット市場に焦点を当てます。

26年はエムボディードAIにとって、23年は大規模言語モデルにとってである。

2026年7月26日、Redditのユーザーがコミュニティに投稿し、Googleのサイト検索構文site:claude.ai/shareを使用すると、何千ものClaudeユーザーの共有会話履歴を一括で抽出できることを明らかにした。

ユーザーがClaudeで「共有」ボタンをクリックすると、システムは指定された対象のみがアクセス可能な秘密のリンクではなく、ログインや本人確認を必要としない公開ウェブページを生成します。

このタイプのページは、インターネット上の一般的なサイトページと本質的に違いはなく、検索エンジンのクローラーによって収集・インデックスされる条件を備えています。しかし、共有機能をこれまで使用したユーザーのほとんどは、関連するリスク警告を受けたことがありません。

投稿後、海外のソーシャルメディアで急速に拡散され、「共有＝公開」のメカニズム設計に関する議論がさらに高まっている。また、一般の予想をはるかに超える多数のプライバシー漏洩事例が次々と明らかになっている。

より多くの人々が検索に参加するにつれ、いくつかの劇的なケースが掘り起こされた。一時的に、他のネットユーザーのチャット履歴を検索することがコミュニティ内の大きな楽しみとなった。人々は他のユーザーのプライバシーを検索し、たびたび議論し、感嘆し、楽しんでいた。

検索された内容の中で、二つの情報タイプのリスクが最も顕著です。

その一つは暗号資産の情報です。誰かがユーザーのウォレットとパスワードを検索しました。ネットユーザーはチャット履歴をたどって対応するウォレットを見つけましたが、残高は2.73ドルだけでした。さらに笑えないのは、親切なネットユーザーが鍵の漏洩を警告しようとしたものの、対話全体を調べても連絡先が見つからず、そのユーザーは今も自分のウォレット鍵がこのように全世界に晒されていることに気づいていない可能性があります。

二つ目は核心的な身元情報です。ユーザーが確認したところ、検索結果に社会保険番号（SSN）を含む完全な会話が含まれていたことが判明しました。このような情報がブラックマーケットに流出した場合、身元盗用や金融詐欺などの具体的な被害を引き起こす可能性があります。

さらに、検索されたコンテンツには、実名で活動する従業者のプロジェクトドキュメント、法律相談の対話、個人の求職用履歴書、アダルトコンテンツなど、さまざまな種類のプライバシー情報が含まれています。本来限られた範囲でのみやり取りされるべき個人情報が、まるで防壁もないかのように公共の検索エンジンのインデックスに取り込まれました。

なぜrobots.txtでは収録をブロックできないのですか？

事件が拡大した後、細心のネットユーザーがClaudeのrobots.txtファイルを確認し、そこに明確にDisallow: /share/*と記載されていることを発見した。つまり、ルール上、クローラーの/shareパスへのアクセスが禁止されている。

明確なルールがあるのに、なぜ対話が検索エンジンに収録されたのでしょうか？これは今回のイベントにおける最も核心的な技術的詳細です。

この問題を明確にするには、まず「クローリング」と「インデックス登録」の2つの概念を区別する必要があります。

• robots.txtの役割は、クローラーと約束することです：このパス以下のページコンテンツを積極的に収集しないでください。これは、ウェブサイト内のリンクに従ってクローラーが積極的にクロールする行為を防ぐだけであり、強制的な制約力はなく、検索エンジンがURL自体を検索結果に含むことを防ぐことはできません。
• 検索エンジンは1つのリンクを発見し、もう1つのパスも存在します：外部の公開ウェブページの外部リンクから発見されます。ユーザーがClaudeの共有リンクをReddit、X、公開フォーラム、GitHubドキュメントなど、クローラーがアクセス可能などの公開ページにも投稿した場合、Googleがそのページをクロールする際に、その/shareリンクを発見します。

たとえ robots.txt がクローラーによるページ本文の読み取りを禁止しても、Google はその URL を検索結果に含めます。ただし、ページのサマリーは表示されません。ページを検索結果から完全に除外するには、ページの HTML に含まれる noindex メタタグが必要です。このタグは検索エンジンに直接、このページをインデックスに含めないよう指示します。

事发时，Claude 的所有共享页面恰恰缺失了这一关键的 noindex 配置。平台仅靠 robots.txt 做了半程防护，缺少真正生效的反收录机制。据社区网友追溯，2025 年 9 月 Claude 就曾出现过小范围同类收录事件，当时谷歌估算约有不到 600 条对话被索引后移除，但并未推动平台彻底补全防护配置。

このイベントのもう一つの問題は、ランダムなUUIDで構成される共有リンクが、Googleがどのようにして発見したのかということです。

あるネットユーザーは、数十億の文字組み合わせを暴力的に列挙することはほぼ不可能であり、核心的な経路は外部リンクであると明確に指摘しました。主流の推測では、一部のユーザーが公開フォーラム、ソーシャルプラットフォーム、オープンソースプロジェクトのドキュメントなど、クローラーがアクセス可能な公開ページにリンクを投稿し、Googleがこれらのページをクロールする際に、対応する/shareリンクを同時に発見したと考えられています。

また、一部のユーザーは、GmailやGoogle ChatなどのGoogle傘下の通信製品がリンクの来源の一つである可能性を指摘していますが、この主張はコミュニティの推測に過ぎず、現在のところ実証的な裏付けはありません。

この出来事に対し、Anthropic も緊急対応を実施したようだ。ユーザーの実験により、site:claude.ai/shareというコマンドを実行すると、Google は「一致するドキュメントが見つかりません」と表示されるようになった。外部では、プラットフォームがすべての共有セッションページにnoindexタグを追加し、新たなインデックス登録が発生しないようにしたと広く判断されている。

しかし、修正には自然な遅延が伴います。BingやBraveなどの他の検索エンジンのキャッシュ更新は独立したサイクルを持っており、既にクロールされた過去のページのキャッシュはすぐに消えません。

OpenAIとGrokのプライバシー上の不備

実際、このようなインデックス設定の問題はAnthropicに限りません。

数年前、ChatGPTの共有会話機能では、まったく同じプライバシー設計の問題が発生した。事後、OpenAIはページのnoindex設定を緊急で補完し、共有ポップアップにリスク警告を追加したが、共有メカニズムそのものの基本的な設計は変更されていない。

現在、Anthropicでも同様の問題が発生しており、本質的には両大手メーカーが同じセキュリティ設計の考え方を採用しているためである。

同じ分野のGrokも、2025年に数十万件の共有会話がGoogleに一括収集され、同規模のプライバシー問題を引き起こした。

事故後、xAIはアーキテクチャレベルで複数の前段防御を構築しました。たとえば、すべての共有ページにnoindexタグを強制的に付与し、サイト全体のrobots.txtのクローリングルールを同時に厳格化しました。この二重の防御により、クローラーによる取得と結果のインデックス登録の両方の段階で明確な制限が設けられました。

このソリューションの核心的な利点は、セキュリティをユーザーの使用習慣に依存させるのではなく、事前に防護を施すことにあります。しかし、業界全体を見渡すと、このような問題の根本的な設計ロジックはまだ広く修正されていません。

インデックス設定と共有設計の課題をどのように補完するか

OpenAIやAnthropicで繰り返し発生した同種の脆弱性は、業界で一般的な製品設計の考え方を見直すきっかけとなっています。

会話共有機能はコンテンツの拡散を促進し、製品成長を後押しするため、メーカーは大抵、使用体験の最適化を優先する。一方で、逆インデックスや階層的権限管理といったプライバシー保護手段は、セキュリティ事故が発生し、世論が盛り上がった後になって、ようやく一時的なパッチとして急いで導入されることが多い。

多くのネットユーザーが議論の中で、プラットフォームが基盤からより完全な防護体制を構築する必要があると呼びかけています。一般ユーザーの多くは、noindexやウェブクローラーのキャッシュといったネットワーク技術を理解しておらず、リンクを共有することに潜むリスクに気づきにくいです。

製品技術の観点から見ると、現在実行可能な最適化のアイデアは比較的成熟しており、実装コストもコントロール可能です。その最も基本的な層は、共有ページのデフォルト設定として noindex を設定し、検索エンジンのインデックス収集パスを根本的に遮断することです。

さらに、権限設計を通じてリスクをさらに制限できます。たとえば、ログイン認証を追加し、ユーザーがリンクにアクセスパスワードを設定したり、有効期間をカスタマイズしたりすることで、共有の範囲と有効期限をよりコントロールしやすくなります。

共有ボタンの横に、専門用語を使わず、リンクが検索エンジンに収録される可能性があることを明確に警告し、ユーザーがクリックする前にその公開性を理解できるようにしてください。

これらの調整は製品アーキテクチャを大幅に変更する必要なく、ユーザーのプライバシーに対する期待と製品の実際のメカニズムとのギャップを効果的に埋めます。