「意図通りの動作です」で済ませていいのか──Claude共有チャット流出事故に見るAI導入ガバナンスの盲点

「共有」ボタンを押しただけのはずが、気づけば医療記録も暗号資産のウォレット秘密鍵も、Google検索の結果に並んでいた──2026年7月、Claudeの共有チャット機能をめぐってそんな事故が起きました。

対象は臨床試験の結果、社内限定の資料、小学生の子どもの氏名と電話番号、そして「vibe coding」で作られたAIセラピーアプリや医療請求データの分析ダッシュボードにまで及びました。自社の業務でClaudeやChatGPTのようなAIチャットツールを使っている、あるいは導入を検討している方であれば、「これは他人事ではない」と感じたのではないでしょうか。

この事故に対してAnthropicは「意図通りの設計です」という趣旨の説明をしたと報じられています。しかし、この一言で片づけてしまってよいのでしょうか。本記事では、この事故の技術的な核心を正確に理解した上で、「ベンダーが悪い」「ユーザーのリテラシーが低い」という二元論を超えて、AIツールを導入する私たちが本当に持つべき前提について考えます。

何が起きたか

事の発端は2026年7月25日(土)、あるRedditユーザーが site:claude.ai/share という検索演算子でGoogle検索をかけたことでした。すると、本来は特定の相手にだけ共有されたはずのClaudeの会話や生成物(Artifacts)が、大量に検索結果に表示されることが判明したのです。翌7月27日(月)朝、テクノロジーメディアの404 Mediaがこれを報道すると、TechCrunchやFortuneをはじめとする主要メディアが次々と追随しました¹。

露出していた内容は、ニュースの見出し以上に生々しいものでした。

患者名付きの詳細な医療記録・臨床試験結果
暗号資産(仮想通貨)のウォレット秘密鍵
APIキーやログイン認証情報
小学生の氏名・電話番号を含む個人情報
社内限定の文書
AIで「vibe coding」されたセラピーアプリや医療請求データ分析ダッシュボードなどのArtifacts

出典: ¹²

Googleは「600件弱」のClaude会話をインデックスしていたとTechCrunchは報じています。ただしこの数字は、後述する2025年9月の前回インシデントでForbesが報じた数字と酷似しており、2026年7月分として独自に集計された数値かどうかは記事上では判然としません。この点は留保として押さえておく必要があります¹。

「意図通りの動作です」の中身

事故発覚後、Anthropicのスポークスパーソンであるエイミー・ロザラム(Amie Rotherham)氏はTechCrunchの取材に対し、次のように説明しました。

“We give people control over sharing their Claude conversations publicly, and in keeping with our privacy principles, we do not share chat directories or sitemaps of shared chats with search engines like Google.”¹

要約すると、「共有の可否はユーザーがコントロールしており、Anthropic自身が検索エンジンにチャットの一覧やサイトマップを渡しているわけではない」という趣旨です。この説明が海外メディアThe Next Webでは “worked as intended”(意図通りに機能した)という見出しで報じられました³。ただし正確に言うと、これはメディア側による要約表現であり、Anthropicが「意図通りの動作です」と一言一句そのまま発言したわけではない点には注意が必要です。とはいえ、「共有した時点でユーザー自身がそれを公開したことになる」という論旨そのものは、報道された発言内容と一致しています。

見過ごせないのは、これがAnthropicにとって初めての事態ではないという点です。実は2025年9月にも、ほぼ同種の事故が起きていました。当時はGoogleが約600件のClaude会話をインデックスしており、スポークスパーソンのギャビー・カーティス(Gabby Curtis)氏が、今回とほぼ同一の説明をしていたのです⁴。

“We give people control over sharing their Claude conversations publicly, and in keeping with our privacy principles, we do not share chat directories or sitemaps of shared chats with search engines like Google and actively block them from crawling our site.”⁴

つまり、約10.5ヶ月の間隔を置いて、ほぼ同じ釈明が2度使われたことになります。ここでいったん「なるほど、結局はユーザー側の共有操作の問題なのか」と納得しかけた方もいるかもしれません。しかし、この理解は技術的には正確ではありません。次の章で、なぜそう言えるのかを見ていきます。

技術的核心──なぜnoindexは機能しなかったのか

「noindexの設定を忘れていた」という理解は、実はこの事故の本質を捉えきれていません。実際に起きていたのは、もう一段精緻な技術的自己矛盾でした。

検索エンジンのクロール・インデックス制御には、大きく分けて2つの仕組みがあります。ひとつは robots.txt による「クロールの許可・禁止(Disallow)」、もうひとつはページ内のmetaタグや X-Robots-Tag ヘッダーによる「インデックスの許可・禁止(noindex)」です。この2つは似ているようで、実は役割が異なります。

Google Search Central(Google公式ドキュメント)は、この違いをはっきりと明記しています。

“Google can’t index the content of pages which are disallowed for crawling, but it may still index the URL and show it in search results without a snippet.”⁵

つまり、robots.txtでクロールを禁止(Disallow)しても、そのページの「内容」がインデックスされないだけで、他のサイトからリンクされていれば「URLそのもの」は検索結果に表示されうるのです。

さらに重要なのが、noindexタグが機能するための前提条件です。

“Keep in mind that these settings can be read and followed only if crawlers are allowed to access the pages that include these settings.” “If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving rules will not be found and will therefore be ignored.”⁶

平たく言えば、noindexタグは「クローラーがそのページの中身を読みに行って、初めて機能する指示」だということです。

Search Engine Journalの分析によれば、Claudeの共有ページはrobots.txtで /share/* というパスをDisallow(クロール禁止)にしつつ、同時にページ自体は x-robots-tag: none(noindex相当)というヘッダーを返す構成になっていたとされています⁷。しかし、ここに矛盾がありました。robots.txtでDisallowされているため、クローラーはそもそもそのページの中身を読みに行きません。読みに行かないということは、ページに書かれた「noindexにしてください」という指示自体を発見できない、ということです。

たとえるなら、こういうことです。「この部屋には入るな」という貼り紙をドアに貼った上で、部屋の中には「中の物は写真に撮らないでください」という貼り紙も貼っていた。しかし最初の貼り紙のせいで誰も部屋に入らないため、2枚目の貼り紙の存在自体が誰にも伝わらなかった──これが、今回の事故の技術的な核心です。

単純な「設定忘れ」ではなく、2つの制御の役割を混同したことによる、構造的な自己矛盾だったのです。そしてこれは、「誰が悪いか」という話ではなく、「公開URLの設計思想そのものの問題」として捉え直す必要があります。

「ベンダーが悪い」でも「ユーザーが悪い」でもない

ここまで見てきた技術的経緯を踏まえると、「Anthropicの設定ミスが悪い」という単純な結論に落ち着きたくなります。しかし、それだけでは足りません。そもそも、noindexやrobots.txtという仕組み自体に、私たちが期待するような「安全装置」としての強度があるのかを問い直す必要があります。

robots.txtは「お願い」であって「鍵」ではない

OWASP(Open Web Application Security Project)のWebセキュリティテストガイドは、robots.txtの限界について次のように明言しています。

“Web spiders/robots/crawlers can intentionally ignore the Disallow directives specified in a robots.txt file. Hence, robots.txt should not be considered as a mechanism to enforce restrictions on how web content is accessed, stored, or republished by third parties.”⁸

つまり、robots.txtはクローラーへの「お願い」に過ぎず、遵守するかどうかは相手のポリシー次第だということです。Googleは比較的これを遵守する側の検索エンジンですが、だからといって「Googleが守っているから安全」と考えるのは早計です。同ガイドはさらに、robots.txtに記載したパス自体が、外部の攻撃者に対して「ここに何かがある」という手がかりを与えてしまう逆説的なリスクにも触れています。隠したい情報のありかを、隠すための仕組みそのものが教えてしまう可能性がある、ということです。

推測不可能なURLは、推測不可能なだけ

もうひとつ検討すべきなのが、「共有リンクは第三者から推測できないから安全」という考え方です。共有機能の多くは、ランダムな文字列を含む「推測不可能なURL(un-guessable URL)」を発行することで、アクセス制御の代わりとしています。

しかし、この発想の限界は、実は10年以上前から指摘されています。W3C(World Wide Web Consortium)のTAG(Technical Architecture Group)は、2014年に公開した文書「Good Practices for Capability URLs」の中で、次のように警告していました。

“URLs appear within URL bars, from which they can be copied easily. They appear within application logs, such as within web servers and in browser history.” “If a link to another site is followed on a page accessed through a capability URL, that site may be notified of the capability URL through the Referer HTTP header.” “In short, the risk of exposure of capability URLs is very high, particularly when they are accessed through a browser.”⁹

ブラウザの履歴、アプリケーションのログ、他サイトへ遷移した際の Referer ヘッダー──検索エンジンによるインデックス以外にも、URLが漏洩する経路は無数に存在します。「推測できないURL」は、あくまで「推測できない」というだけであり、「漏洩しない」ことを保証するものではないのです。

ここまで来ると、「ベンダーが悪い」「ユーザーのリテラシーが低い」という二元論そのものが、問いの立て方として不十分だったことが見えてきます。本当に持つべき前提は、「一度公開URLを発行した情報は、noindexやrobots.txtの設定に関わらず、本質的に統制不能である」というものです。公開した時点で、それはいつ誰に見られてもおかしくない──この前提に立たない限り、同種の事故はどれだけ設定を見直しても再発し得ます。

「Googleで消えた」は「安全になった」ではない

事故発覚後、Googleの検索結果からは該当ページが比較的すみやかに削除されたと報じられています。しかし、これをもって「安全になった」と考えるのも、また別の楽観です。

Googleが提供する「削除ツール(Removals tool)」のヘルプページには、次のように明記されています。

“A successful request lasts only about six months.”¹⁰

つまり、この削除は約6ヶ月(180日)の一時的な措置に過ぎません。恒久的な削除ではないのです。もうひとつの「Refresh Outdated Content tool」についても、同様の記述があります。

“A request expires when either 180 days has passed since the request was approved, or the URL no longer exists.” “This tool only updates Google’s search result, it does not remove a page from the web.”¹¹

このツールは「Googleの検索結果の表示」を更新するだけであり、「ウェブ上からページそのものを消す」わけではありません。ページが実際にサーバー上に存在し続けている限り、期限が過ぎれば再びクロールされ、表示される可能性が残ります。

さらに、セキュリティ系メディアのthecybersecguru.comは、「Googleは同日中に多くのインデックスページを削除したが、他の検索エンジンではより長期間結果が表示され続けたという報告がある」と報じています¹²。件数や具体的な期間までは明らかになっていませんが、Googleの対応だけで「検索できなくなった」と考えるのは早計だということが伺えます。

Webアーカイブについても留意が必要です。Internet Archive(Wayback Machineの運営元)は2017年、公式ブログで「検索エンジン向けに書かれたrobots.txtは、アーカイブ目的には必ずしも適さない」として、一部のサイト(米国政府・軍事関連サイト)についてrobots.txtを無視する方針へ転換し、「より広範囲に適用していく意向」を表明しています¹³。2026年時点でこの方針がどこまで広がっているかは明らかではありませんが、検索エンジン向けの設定が、Webアーカイブによる保存までは止められない可能性がある、という点は押さえておくべきでしょう。

「検索結果から消えた」ことと、「情報がこの世界から消えた」ことの間には、まだ大きな距離があります。

これは初めてではない──繰り返される同型の事故

実は、「AIチャットの共有機能が検索エンジンに露出する」という事故は、Claudeだけの問題ではありません。過去3年ほどの間に、少なくとも4社が同型の事故を繰り返しています。

サービス	発覚時期	規模	対応
Google Bard	2023年9月	300件超	Google Search Liaisonが「意図しないこと」と回答し修正¹⁴
OpenAI ChatGPT	2025年8月	サイト内検索で約4,500件、別調査では約10万件との報道	CISO ダン・スタッキー(Dane Stuckey)氏が機能自体を廃止(唯一「共有可能にする」がオプトインのチェックボックスだった)¹⁵
xAI Grok	2025年8月	37万件超	xAIはコメントせず¹⁶
Anthropic Claude(1回目)	2025年9月	600件弱	ギャビー・カーティス氏が同種の説明⁴
Anthropic Claude(2回目)	2026年7月	600件弱(前回との数字の一致は要留保)	エイミー・ロザラム氏がほぼ同一の説明を再度使用¹

特筆すべきは、Claudeが 同一の技術的欠陥によって、約10.5ヶ月の間隔で2回同じ事故を起こしている という事実です。これは「意図通りの動作です」という釈明と、「実際には再発防止が十分に機能していなかった」という現実との間に、看過できない緊張関係があることを示しています。

もちろん、これはAnthropicだけの問題ではなく、「AIチャットの共有機能」と「検索エンジンのインデックス」という組み合わせそのものに潜む構造的なリスクだと捉えるべきです。だからこそ、私たちは個社の対応を待つのではなく、自社側の備えを持つ必要があります。

自社のAI導入で何をすべきか

ここまでの話を、自社の実務にどう落とし込めばよいのでしょうか。

まず前提として押さえておきたいのが、「シャドーAI」の存在です。従業員が組織の承認を得ずにAIツールを利用する状態は、多くの企業で管理しきれていないと報じられています。あるセキュリティレポートでは、シャドーAIが要因となった情報漏洩は全体の約2割を占め、通常の漏洩よりも被害額が大きい傾向にあると報告されています(一次資料への直接確認は取れていないため、参考値としての紹介にとどめます)。「共有機能もGoogle DocsやSlackと同じレベルのガバナンス対象として扱う」という発想の転換が、まず必要になってきます。

具体的な実務の拠り所としては、以下のような公的なガイドラインが参考になります。

経済産業省「AIの利用・開発に関する契約チェックリスト」(2025年2月公表)¹⁷
総務省・経済産業省「AI事業者ガイドライン」(2026年3月時点で第1.2版が最新)
AIセーフティ・インスティテュート(AISI)「CAIO設置・AIガバナンス実務マニュアル」(2026年2月公表、執筆時点では「案」段階)¹⁸

これらはAI活用における契約上の注意点や、ガバナンス体制の構築指針をまとめたものであり、ベンダー選定・契約時のチェックリストとして活用できます。

そして何より大切なのは、AIベンダーから「意図通りの動作です」「ユーザーの操作によるものです」といった説明を受けたとき、それを最終回答として受け入れないことです。ベンダーの説明が技術的に正確かどうかを自社で検証し、自社の情報取り扱い基準に照らして評価する視点を持つ必要があります。これは、AIモデル選定における「性能だけでなく主権・ガバナンスの軸で見るべき」という視点¹⁹とも通じる話です。

まとめ

Claudeの共有チャット流出事故を振り返ると、見えてくるのは「ベンダーが悪い」でも「ユーザーが悪い」でもない、もっと根本的な事実です。noindexやrobots.txtといった仕組みは、あくまで検索エンジンへの「お願い」に過ぎず、法的にも技術的にも強制力を持ちません。そして、一度発行された公開URLは、設定の巧拙にかかわらず、本質的に統制不能なものだと考えるべきなのです。

自社がAIツールを導入・展開する際には、ベンダーの「意図通りの動作です」という説明を鵜呑みにせず、自社のガバナンス基準に照らして評価する視点が欠かせません。自社のAI導入ガバナンス基準や、ベンダー評価プロセスの棚卸しについて相談したい場合は、コンタクトフォームよりお気軽にお問い合わせください。