画像ホスティングの共有リンク、Googleに検索されてない？無料7サービスのnoindex実測

Discordのサーバーに何気なく貼ったスクリーンショット、あれ実は今この瞬間もGoogleのインデックスに載っていて、誰かが site: 検索を打つだけで掘り出せる状態かもしれません。ハッキングは一切必要なく、robots設定の食い違いだけで起きます。

2026年7月末、セキュリティ業界で実際にこれが起きました。Googleで site:claude.ai/share と検索するだけで、他人のAIチャット履歴が大量に出てくることが判明したのです。中にはAPIキー、暗号資産の秘密鍵、法律相談の内容、履歴書まで含まれていました。原因はハッキングではなく設定の矛盾です。それらの共有ページは robots.txt で「クロール禁止」に設定されていたと同時に、X-Robots-Tag: none も設定されていました。問題は、Googlebotが robots.txt の時点でブロックされると、そもそもページに到達できず、本来効くはずだった noindex タグを読み取ることすらできない点です。結果、外部リンク経由でページが発見・インデックスされてしまい、それを止める仕組みが何一つ機能しませんでした。これは1年間で4件目の同種インシデントで、それ以前にもChatGPT（推定7万〜10万件の会話）とGrok（数十万件）で同じ構造の問題が起きています。

これは画像ホスティングと直接関係ないように見えるかもしれません——あれはAIチャットの共有リンクで、画像ではないからです。ですが仕組みはそのまま流用できます。「リンクを知っている人だけが見られる」設計なのに、クローラーを正しく遮断していない共有機能は、すべて同じロジックの餌食になります。 画像ホスティングの閲覧ページも「URLさえ知っていれば見られる」形式である以上、robots.txt、meta robots、X-Robots-Tag という同じ三層構造で守るしかなく、どこか一層でも設定を誤れば、画像も同じように検索結果へ流出します。企業のセキュリティ監査を何件も担当してきましたが、正直なところ画像流出はチャット流出よりも気づきにくいケースが多いです。何気なく送ったスクリーンショットが検索されているとは、誰も思わないからです。

そこで実際にテストしてみました。

画像が検索されるかどうかを決める3つの層

表を見る前に判断基準を整理しておきます。あるURLがGoogleにインデックスされるかどうかは、次の3つの独立した層で決まります。

robots.txt はクローラーがそのパスに入れるかどうかを決めます。ページHTML内の <meta name="robots"> は、クローラーが入った後にインデックスするかどうかを決めます。HTTPレスポンスヘッダーの X-Robots-Tag は、meta タグと同じ効果を持つ独立したインデックス指示で、HTMLを書き換えなくても設定できる点だけが違います。この3層は本来それぞれ独立しているのに、しばしば「同じ一つの設定」として扱われてしまいます——これがまさにClaudeの事故の根本原因でした。robots.txt でブロックされていたため、X-Robots-Tag は正しく設定されていたのに、誰もそれを読み取れなかったのです。

一つ強調しておきたい原則があります。noindex を効かせるには、クローラーがまず「中に入れる」ことが前提条件です。 robots.txt であるパスをdisallowしつつ、同じパス配下の noindex タグにも効果を期待するのは矛盾した設計で、結果的にどちらも機能しないことがほとんどです。

検証方法：やったこと、やらなかったこと

正直なところ、この手のテストで一番怖いのは「記憶だけで書いてしまう」ことです。だから方法を先に明かします。2026年9月、ブラウザのUser-Agentで各サービスの閲覧ページに curl -I を実行してHTTPヘッダー（X-Robots-Tag の有無）を取得し、完全なHTMLを取得して <meta name="robots"> を確認、さらに各サービスの robots.txt を直接取得しました。JavaScriptでコンテンツを描画するサービス（Imgurのトップページのおすすめ枠がまさにこれで、curl では実際のリンクを取得できません）については、ブラウザ自動化ツールで実際にページを読み込んでからリンクを取得しています。

実際に検索でヒットするかどうかは、別途Google検索での確認も行いました——ただしここで一つ正直に限界を書いておきます。使用した検索ツール自体がimgur.comというドメインへのアクセスをブロックされていました（Googleにブロックされたのではなく、検索ツールのクローラーがimgur側の防御に弾かれた形です）。そのためImgurの「すでに検索されているか」の欄だけは同じ方法では検証できず、技術設定の観点から「理論上インデックス可能」と判断するにとどめ、その旨を表に正直に注記しています。隠したいわけではなく、単なるツールの限界です。テストしたふりをするより、限界を明示するほうが誠実だと考えました。

実測結果

以下の表は今回実際に取得したURLとレスポンスで、ドキュメントから推測して作った表ではありません。

サービス	閲覧ページ例	robots.txt の制限	meta robots / X-Robots-Tag	インデックス状況（2026年9月実測）
Imgur	imgur.com/gallery/xxx	/gallery/ パスは未ブロック	どちらも未設定（デフォルトでインデックス可能）	技術的にはインデックス可能。検索ツールがimgur.comにブロックされているため直接検証できず
ImgBB	ibb.co/xxx	robots.txt が完全に空	どちらも未設定	すでにインデックス済み——一般的なキーワード検索で実在する画像ページが複数ヒット
Postimages	postimg.cc/xxx	robots.txt が完全に空	どちらも未設定	すでにインデックス済み——同様にファイル名入りの画像ページが複数ヒット
Flickr	flickr.com/photos/user/id	具名クローラー（Googlebot含む）が /photos/ へのアクセスを許可されている	noarchive のみで noindex はなし	すでにインデックス済み——特定ユーザーの特定写真ページを実際に検出
Catbox	files.catbox.moe/xxx	一部の管理系パスのみクロール禁止、かつ ClaudeBot / GPTBot を明示的にブロック	ファイル自体が純粋なバイナリ直リンクで、meta タグを置けるHTMLページが存在しない	構造上「インデックス可能な閲覧ページ」自体が存在しない——ページがないのでmeta robotsの概念自体が成立しない
Google フォトの共有リンク	photos.app.goo.gl/xxx	/share/ パスがrobots.txtで明確に除外されていない	ページがJSレンダリングのため curl では内容を判断できず	すでにインデックス済み——他人の共有リンクが検索でヒットし、一部は今も開ける状態
lpic.cc	lpic.cc/短縮コード	Allow: /（トップレベルで開放）	閲覧ページのソースに index: false, follow: true と明記	明確なnoindex——設計段階から閲覧ページをインデックスさせない方針

正直、Google フォトの行を見たときは少し驚きました。

サービス別の読み解き：問題はどの層にあるのか

ImgBBとPostimagesは今回のテストで最もわかりやすい2つの反例です。robots.txt は空の内容をそのまま返し、パス制限が一切ないことを意味します。ページにも meta robots タグは一切ありません。制限なし＋タグなしはすなわち「完全開放」——これはデフォルトの状態であり、アップロード時にユーザーがオフにできるオプションではありません。検索するとほぼ一瞬でヒットし、検索結果のページタイトルにはスマホのカメラが生成した元のファイル名（IMG_ に日時が続く形式）がそのまま出てくるものも少なくありませんでした。スマホから直接アップロードされた写真だと一目でわかります。

Flickrの状況はより繊細で、誤読しやすいポイントでもあります。robots.txt にはGooglebotを含む約40の具名クローラーがリストされていますが、このリストが除外するのは一部の特定アカウントと機能ページのみで、一般ユーザーの /photos/ユーザー名/写真ID というパスは除外対象に含まれていません。ページ自体は noarchive（キャッシュ非表示）のみで、noindex は一切設定されていません。実際に検索で見つけたケースは少々皮肉なもので、Flickrの公式アカウントが「Flickrの写真をどう共有するか」を解説している教則投稿でした——共有方法を教える記事そのものが検索されてしまっていたわけです。

Google フォトの共有リンクが今回のテストで最も気になった項目です。共有リンクは一見「渡した相手だけが見られる」プライベートな仕組みに見えますが、特殊な検索コマンドを一切使わず一般的なキーワードだけで、他人の photos.app.goo.gl 共有短縮URLを検索結果から見つけることができました（プライバシーに配慮し、実際のリンクはここに記載しません）。クリックするとログインを求められるものは、共有権限が後から変更または失効したことを意味し、依然として開けるものは、「特定の人にだけ渡したはずのリンク」がかつて、あるいは今なお公開検索で見つかる状態にあることを意味します。これはClaudeの流出事故と同じ形のリスクです。リンク自体には公開の意図がなくても、クロールルールの細部次第で検索エンジンに拾われてしまいます。

Catboxはむしろ特殊なケースです。他のサービスのように独立した「閲覧ページ」を持たず、アップロード後にそのままファイル直リンクのURLが渡され、開けば画像そのものが表示され、meta robots を置けるHTML外殻が存在しません。つまり従来の「meta robotsチェック」という手法自体がそもそも成立しません。ただしこれは安全という意味ではなく、リスクが別の場所に移っているだけです。Google画像検索は直リンクの画像ファイルURL自体をインデックスする可能性が依然としてあり、その判断基準はHTMLページとは異なります。この部分については安定した検証方法が見つからず、正直に言えば検証できていません。数字をでっち上げるつもりはありません。

lpic.cc——自分の製品ですが、他社と同じ基準でテストしないわけにはいきません。ソースコードを確認すると、閲覧ページのmetadataに robots: { index: false, follow: true } が明示的にハードコードされています。つまり短縮コードが誰かに共有されてクローラーに発見されたとしても、ページ自体が「インデックスしないでほしい」とGoogleに伝える設計になっています。これは今回のテストのために後付けしたものではなく、設計時点から決まっていた挙動です。ただし正直に言うと、noindex が防げるのは検索結果への掲載だけで、「URLさえ知っていれば開ける」という問題そのものは防げません。だからこそパスワード保護機能が別途存在するわけで、両方を組み合わせて初めて対策として完結します。

これが実際にどんなリスクにつながるか

技術的な話を平たく言い換えると、個人情報、領収書、チャットのスクリーンショット、身分証明書が写った画像をImgBBやPostimagesのようなデフォルトで全開放されているホスティングにアップロードした場合、理論上は誰でもキーワードや画像内に写っている文字の断片から検索して見つけられます。共有された相手からリンクをもらう必要すらなく、検索エンジンがすでにクロール済みであれば、そこに存在し続けます。これは自分のウェブサイトにファイルを「公開」設定でアップロードするのと本質的に変わりません。

さらに見落とされがちなのは、掲示板やSNSに画像ホスティングのリンクを貼るとき、多くの人は「この画像が検索されるかどうか」をわざわざ考えないという点です。しかし画像に氏名、住所、部分的なマイナンバーや保険証番号など（確定申告や返品手続き、各種申請書類のスクリーンショットに多い）が写っていれば、検索エンジンにインデックスされた瞬間、その情報は自分で気づいて削除依頼を出すまでネット上に晒され続けます。そもそもどこに削除依頼を出せばいいのかを知らない人がほとんどです。

自分の共有リンクを守る方法

すべての画像にここまでの警戒が必要なわけではありません。大事なのは「気軽に共有するミーム」と「個人情報が写ったスクリーンショット」を区別して、それぞれ違うレベルの対策を取ることです。具体的には3つ。

• アップロード前後に自分で検索する。ファイル名や画像内の特徴的な文字列でGoogle検索をかけ、インデックスされていないか確認する。
• 機微な内容は、デフォルトで全開放されているホスティングを避け、noindex を明示しているか、パスワード保護に対応したサービスを使う。
• 共有リンクには有効期限を能動的に設定する。「どうせURLを知られていないから大丈夫」という前提には頼らない——Claudeの事故がすでに証明した通り、クローラーは事前にURLを知る必要すらなく、外部からのリンクが一本あれば十分です。

「共有リンクをデフォルトで非インデックス化する」と「パスワード保護」の両方を最初から備えた画像ホスティングを探しているなら、lpic.cc の閲覧ページはもともと noindex 設計で、さらにパスワード保護機能も付いているため、この2層の防御を一度に満たせます。ただし制約も正直に書いておきます。無料プランでアップロードしたメディアはデフォルトで30日後に期限切れになります（アップロードフォームは「閲覧時に自動延長」がデフォルトでオンになっています）。期限が切れると削除され、サービス自体は広告収益で運営されています——これらはアップロード後ではなく事前に知っておくべき点です。

よくある質問 FAQ

Q1：noindexさえ設定すれば、画像は絶対に検索されませんか？ 絶対ではありません。noindex はクローラーへの「お願い」であり、多くの場合Googleは尊重しますが、それはクローラーが実際にこのタグを読み取れることが前提です。もし robots.txt で同じパスがブロックされていれば、クローラーはそもそも中に入れず noindex を見ることすらできません。これがまさにClaudeの事故の原因です。

Q2：Catboxのような直リンク型のホスティングでも、画像は検索されますか？ HTMLページが存在しないため、meta robotsでの判断はできません。理論上はGoogle画像検索が直リンクの画像ファイルURL自体をインデックスする可能性がありますが、検証方法は通常のWebページとは異なり、今回のテストでは信頼できる検証方法が見つかりませんでした。検証されていない断定はしません。

Q3：ImgBBにアップロードした画像が検索されているのに気づきました。インデックスを削除できますか？ まず元の画像を削除してURLを無効化し、そのうえでGoogle Search Consoleの「URLの削除」ツールから削除リクエストを送るのが、自然なクロールの再取得を待つより確実に速いです。

Q4：この記事は2026年9月時点の結果ですが、その後プラットフォームが設定を変えたらどうなりますか？ robots.txt やmetaタグはいつでも変更され得るもので、この種の設定に永続的な保証はもとよりありません。この表を丸暗記するのではなく、自分で curl -I やブラウザの開発者ツールを使って確認する習慣をつけるほうが、結論そのものより長く使えます。

Q5：なぜFlickrはGooglebotだけ許可して、他の大半のクローラーはブロックするのですか？ これは意図的な使い分けです。主要な検索エンジンにはインデックスを許可してトラフィックと露出を維持しつつ、匿名の第三者クローラーはブロックしてコンテンツの盗用・悪用リスクを下げる——両者は異なる判断軸に基づくもので、同じ基準を二重に適用しているわけではありません。

Q6：日本の個人情報保護法の観点では、こうした画像流出はどう扱われますか？ 氏名や住所、身分証番号などの個人情報が写った画像が検索エンジンにインデックスされた場合、個人情報保護法上の「個人情報」に該当し得ます。プラットフォーム側（個人情報取扱事業者に該当する場合）に削除請求ができるほか、個人情報保護委員会への相談窓口も利用できます。ただしこれは事後の法的手段であり、そもそも robots.txt や noindex の設定を正しくしておくことの代わりにはなりません。

参考資料

• Claudeの共有リンクがGoogleにインデックスされた事故の報道（2026-07-29）
• Imgur、ImgBB (ibb.co)、Postimages (postimg.cc)、Flickr、Google フォト (photos.google.com)、Catbox (catbox.moe) 各サービスの robots.txt、2026年9月に直接取得
• 上記各サービス閲覧ページのHTTPヘッダーとHTMLソース、2026年9月に curl およびブラウザ自動化ツールで実測
• lpic.cc 閲覧ページの metadata ソースコード（app/(public)/[locale]/[code]/page.tsx）