はじめに(この記事で分かること)#
2020年2月18日、東京地裁で、アイドルとして活動する20代の女性のマンションに侵入してわいせつな行為をし、けがをさせたとして起訴された男の裁判員裁判が始まった。この初公判を報じた文春オンラインの記事によれば、男は、女性がSNSに投稿した顔写真の瞳に映る景色を手がかりにマンションを特定したとされる。瞳に映っていたのは駅の屋根の形、線路の本数、背後の看板だった。男はGoogleのストリートビューで候補の路線の駅周辺を探して最寄り駅を見つけ、女性が自宅から配信していた動画の背景から部屋のある階を割り出した。
この写真のEXIFに位置情報が入っていたかどうかは、記事からは分からない。分かるのは、仮に位置情報がきれいに消えていても、この特定は止まらなかったということだ。手がかりは画像の中身そのものだった。
「写真の位置情報を消しましょう」という助言は正しいが、それで守れるのは問題の半分にすぎない。この記事では、EXIFに何が記録されるかを規格の原文で確かめたうえで、EXIFを消した後に画像の中に残る手がかり、人力とAIによる位置推定の実力と誤り、SNSやメッセンジャーがアップロード時に何をしているか(公式に説明されている範囲)、そして「何を写さないか」という形の対策と、その限界を扱う。他人の写真から居場所を割り出す方法は扱わない。主語は一貫して、自分が公開する写真から何が読み取られうるか、である。
前提: 脅威モデルの整理#
脅威モデル入門で整理した5種類の相手のうち、この記事がもっとも重く見るのは標的型攻撃者、つまりストーカーや元交際相手、特定の人に執着する人物だ。
理由は二つある。一つは、写真の位置推定に令状も専門設備も要らないことだ。冒頭の事件で使われたのは、SNSに公開された写真と、誰でも使える地図サービスだった。もう一つは、この相手が事前の知識を持っていることだ。住んでいる市、勤め先の最寄り駅、よく行く店を知っている人にとって、写真の背景は「世界のどこか」を当てる問題ではなく、「知っている範囲のどこか」を絞り込む問題になる。後で見るAIの推定精度は世界全体を対象にした数字で、事前の知識がある相手には、粗い推定でも十分な絞り込みになりうる(これは数字からの推測で、測定値ではない)。同居や交際の関係から生じる脅威の全体像は親密な関係の脅威モデルで扱っている。
プラットフォームは別の意味で関係する。後述するとおり、Xは投稿された写真のEXIFを一時的に保持して処理に使うと説明しており、Metaのプライバシーポリシーは利用する情報に「Metadata about content and messages」を挙げている。閲覧者からEXIFが見えなくなることと、事業者の手元に届かないことは別の話だ。
法執行機関も、画像からの位置推定を道具として持ち始めている。404 Mediaは2026年2月、入手した警察内部のメールをもとに、マイアミ・デイド郡保安官事務所とロサンゼルス市警が商用の位置推定サービスGeoSpyへのアクセスを購入していたと報じた。ただ、捜査機関に狙われる立場の人にとって写真は多数ある経路の一つにすぎず、この記事の対策だけで足りることはない。
広告網やISPに対しては、この記事の内容はほとんど効かないし、必要もない。彼らが位置を知る経路は写真よりも、端末の位置情報の権限やIPアドレスのほうにある。その経路はスマホの位置情報の記事とIPアドレスからの特定の領域だ。
EXIFを消した後に残るもの#
EXIFに記録される位置情報#
まず、消す対象のほうを規格の原文で確かめておく。デジタルカメラの画像ファイル形式であるExifは、カメラ映像機器工業会(CIPA)が規格番号DC-008として、電子情報技術産業協会(JEITA)と共同で定めている。CIPAの改訂履歴によれば、2023年5月にExif 3.0、2026年1月にExif 3.1が公開されている。ここでは、CIPAのサイトから直接ダウンロードできるExif 2.3(DC-008-2012)の英訳版で該当箇所を確認した。
Exif 2.3では、位置情報は「GPS IFD」というタグの集まりに入る。表15に並ぶGPSのタグは32個あり、緯度(GPSLatitude)と経度(GPSLongitude)は度・分・秒の三つの有理数で記録される。高度(GPSAltitude)、GPSの時刻(GPSTimeStamp)と日付(GPSDateStamp)もこの中にある。見落とされやすいのは、撮影した方向を記録するタグ(GPSImgDirection)があることだ。位置だけでなく、カメラがどちらを向いていたかまで残りうる。
GPS以外にも、撮影日時(DateTimeOriginal)、カメラの所有者名(CameraOwnerName)、カメラ本体のシリアル番号(BodySerialNumber)といったタグが規格にある。所有者名やシリアル番号は、場所ではなく「同じカメラで撮った別の写真」との連結に使われうる。規格はさらに、本体の画像とは別に小さなサムネイル画像を同じファイルに持てる構造を定めている。また、CIPAはExifの情報をXMPという別の形式で書く規格(DC-010)も公開しており、同じ情報がEXIF以外の場所に入っていることもある。「EXIFを消した」と「位置情報がファイルに残っていない」は、厳密には同じ意味ではない。
画像の中身に残るもの#
ファイルの付属情報をすべて消しても、画像そのものは残る。以下は、自分の写真を公開前に見直すときに、どこに目を向けるかという観点で整理したものだ。
文字。看板、店名、標識、バス停の名前、ナンバープレート、掲示物。文字は言語と地域をいきなり狭める。日本の写真で見落とされやすいのが電柱だ。東電タウンプランニングの電柱広告の案内は、電柱に巻き付ける巻広告について「地域の皆さまの役立つ情報として、巻広告の下部に町名番地を表示しています」と書いている。電柱に巻かれた看板の一番下には、その場所の住所が書いてあることがある。
構造物。冒頭の事件では、駅の屋根の形と線路の本数が手がかりになった。線路、高架、送電線の鉄塔、特徴的な建物、山の稜線、川や海岸線の形は、それ自体に文字がなくても地図や航空写真と照合できる形を持っている。
植生と季節。植物の種類、紅葉や桜の状態、雪の有無は、地域と時期の両方を示す。Bellingcatが紹介する過去の調査では、植物の同定や土の色が出発点になった例がある。
影。影の向きと長さは、太陽の位置と結びついている。Bellingcatが2024年に公開した「Shadow Finder」は、撮影の日時が分かっていて、物体の高さと影の長さを測れれば、撮影地の候補を地図上の環状の帯として示す道具だ。同じ記事は、良い結果を得る条件として、日時が既知であること、物体と影がカメラに対しておおむね直角であること、影が水平な面に落ちていること、レンズの歪みが大きくないことを挙げている。条件は厳しいが、投稿時刻がほぼ撮影時刻である写真は、最初の条件を自分から満たしてしまう。
反射。瞳、眼鏡、サングラス、窓ガラス、鏡、車のボディ、テレビやスマートフォンの黒い画面。冒頭の事件の手がかりは瞳の反射だった。撮っている本人の目には被写体しか見えていないが、拡大すれば撮影者の背後にあるものが写っていることがある。
窓の外。自宅で撮った写真や配信で、窓の外の景色は外の世界との接点になる。向かいの建物、見える高さ、日の差し方は、建物と階を絞る材料になる。冒頭の事件では、配信動画の背景から部屋のある階が割り出された。
一つひとつの手がかりで場所が決まることは少ない。効くのは組み合わせだ。人力の調査も、次に見るAIも、小さな手がかりの重なりから候補を狭めていく。
人力の位置特定で見られるもの#
画像の位置特定は、報道の検証のために公開の手法として磨かれてきた分野でもある。オランダの調査報道グループBellingcatは、その手法を記事として公開している。ここではその公開範囲を、手順ではなく「何が照合の対象になるか」として読む。
2014年、Bellingcatの創設者Eliot Higginsが書いた入門記事は、動画の撮影場所を特定する方法として、まず範囲を狭めるランドマークを探し、次に「道路の配置」を衛星写真と照らし合わせるという考え方を示している。道路の曲がり方や交差点の位置は、看板がなくても形として残るからだ。2023年にBellingcatが公開したOpenStreetMapの検索ツールは、地図上の複数の要素(記事の例では噴水、路面電車の線路、角のコンビニエンスストア)が指定した距離の範囲に揃う場所を探す。冒頭で触れた「組み合わせ」が、そのまま検索の単位になっている。
防御の側から読むと、ここから言えることは単純だ。照合されるのは、地図や航空写真、ストリートビューに載っている形と文字である。道路の形、駅の構造、交差点の配置、店の並び、地名の書かれた看板。こうしたものが写り込むほど、照合の材料が増える。逆に、壁や室内、空、特徴のない植え込みだけの写真は、照合できるものが少ない。
人力の調査には時間がかかる。ただし、それは特定の一人に強い関心を持つ相手にとっては障害にならない。冒頭の事件の男は、候補の路線の駅を一つずつ探していった。標的型攻撃者は、時間だけは持っていることが多い。
AIによる位置推定#
研究: PIGEONとPIGEOTTO#
画像から撮影地の座標を推定する研究は以前からあるが、精度を大きく引き上げた例としてよく引かれるのが、スタンフォード大学のHaasらによるPIGEON(CVPR 2024)だ。論文は二つのモデルを報告している。数字を読むときに一番大事なのは、どちらのモデルが、どんな画像で、どんな条件で測られたかだ。
一つ目のPIGEONは、位置当てゲームGeoGuessrから無作為に集めた10万地点のストリートビュー画像で学習している。1地点につき、90度ずつ向きを変えた4枚、つまり周囲一周分のパノラマを入力にする。ストリートビュー5,000地点の評価用データでは、国の正解率が91.96%、誤差の中央値が44.35km、25km以内に収まった推定が40.36%、1km以内は5.36%だった。同じ論文の検証では、入力をパノラマ4枚から1枚に減らすと、25km以内は24.18%、誤差の中央値は131.1kmに悪化する。ゲームでは人間の上位0.01%にあたる層を上回り、プロのプレイヤーとの6試合にすべて勝ったと報告されている。
二つ目のPIGEOTTOは、ストリートビューではなく、FlickrとWikipediaに由来する一般の写真(Flickrが約417万枚、ランドマーク画像が約34万枚)で学習した汎用のモデルで、1枚の画像を入力にする。SNSに投稿される写真に近いのはこちらだ。Flickr画像の評価セットYFCC4kでの結果は、誤差の中央値が383.0km、25km以内が23.7%、1km以内が10.4%、国レベル(750km以内)が62.2%だった。ランドマーク中心の小さな評価セットIM2GPS(237枚)では、25km以内が40.9%になる。
この数字は両方向に読める。25km以内に収まるのが4割ということは、6割は25kmより外れているということだ。1km、つまり通りの単位で当たるのは、条件の良いデータでも1割前後にとどまる。論文自身も倫理に関する節で、自分たちを含む現在の技術の大きな限界は通りの単位の推定を確実にできないことだと書き、悪用の危険を理由にモデルの重みを公開せず、学術的な検証のためのコードだけを公開したと述べている。
一方で、冒頭で述べたように、事前の知識を持つ相手にとって「25km以内」はすでに有用な絞り込みでありうる。AIが候補の地域を出し、人がそこから先を詰める、という組み合わせは十分に考えられる(これは推測で、PIGEONの論文がそうした使われ方を報告しているわけではない)。
汎用のAIチャットでの検証#
研究用のモデルではなく、誰でも使えるAIチャットではどうか。Bellingcatは2025年6月、未公開の自分たちの旅行写真25枚(メタデータなし、全大陸から)を、20のモデル(Google Lensを比較の基準として含む)に「この写真はどこで撮られたか」とだけ聞く形で、合計500回の試験を行った。
結果として、Google Lensを上回ったのはOpenAIのo3、o4-mini、o4-mini-highの三つだけで、その差も大きくはなかった。誤りの型が具体的に記録されている。スイスの野原の写真を、撮影者のオランダ風の名前に引きずられたらしくオランダと答えたモデル。店先の文字に注目してシンガポールの路地をバンコクと答えたモデル。季節限定の観覧車がある海岸を、もっと有名な別の海岸と取り違えたモデル群。さらに、ChatGPTのo4-miniが利用者との過去の会話を参照し、Grokは利用者のX(旧Twitter)のプロフィールを手がかりにしたように見えた、とも書かれている。写真そのもの以外の情報が推定に混ざることがある、という点は防御の側にとっても示唆的だ。Bellingcatの結論は、LLMは人が見落とす細部を拾う助けにはなるが、まだ幻覚を起こし、「silver bullet(万能の解決策)ではない」というものだった。
商用サービス: GeoSpy#
研究の外では、画像からの位置推定を商品として売る事業者が現れている。公式サイトの表記でGraylark Technologies Inc.が提供するGeoSpyだ。公式サイトは2026年11月8日時点で、メタデータなしで写真から情報を得るとうたい、市や国ごとの位置推定モデルで「up to meter level accuracy(最大でメートル単位の精度)」を提供し、1万件以上の事件の解決に役立ったと主張している。対象は「qualified government and enterprise organizations」とされている。これらはすべて事業者自身の主張で、精度の数字について第三者の検証は確認できなかった。
404 Mediaは2025年1月20日の記事で、GeoSpyが植生、建築、建物の間の距離といった画像内の特徴から数秒で撮影地を推定でき、一般の利用者にも使われていたこと、その中には特定の女性へのストーキングに協力を求める者もいたこと、創業者はそうした依頼を強く拒んでいたことを報じた。同誌が取材を申し込んだ後、GeoSpyは一般向けの公開を閉じた。2026年2月12日の続報が、前述の保安官事務所とロサンゼルス市警による購入である。
ここで押さえておきたいのは二つだ。一般向けの公開が閉じられても、同じ種類の技術は研究として公開され、汎用のAIチャットにも一定の能力がある。そして、この種の推定は誤ることがある。誤った推定は、写真を投稿した本人ではなく、推定された場所にいる無関係な人を巻き込むおそれがある(誤り率から考えられる危険であり、そうした実例を今回確認したわけではない)。
なお、写真管理のサービス自身も画像から位置を推定している。Googleフォトのヘルプは、位置情報のない写真について、写真に写ったランドマークや、位置情報付きの他の写真との類似から位置を推定する機能があると説明し、共有した写真から位置の情報を外しても、写真に写ったランドマークから場所を推測される可能性があると自ら注意している。
SNSの再圧縮とメタデータ#
SNSやメッセンジャーの多くは、アップロードされた画像を縮小・再圧縮して配信する。その過程でEXIFが落ちることは広く知られているが、各社がそれを公式に説明しているかどうかはまちまちだ。以下は、2026年11月8日に各社の公式ヘルプ・公式ブログ・公式アカウント・公式リポジトリで確認できた範囲である。
| サービス | 公式の説明 | 確認した内容 |
|---|---|---|
| X | ヘルプセンター | 位置情報サービスが有効なとき、投稿画面で写真のExifを参照して場所の候補を表示する。Exifは端末のカメラで撮った写真かどうかの分析にも使う。Exifは処理のために一時的に保持し、写真を見る人は利用できない |
| Signal | 公式アカウントの投稿(2020-06-09)とAndroid版のコミット(2018-03-19) | 「Yes, EXIF data is automatically removed.」。Android版のコミットは、すべてのJPEGを再エンコードしてEXIFのタグを取り除くと説明している |
| Discord | 公式ブログ(2025-03-12) | 「historically relied on the piexif Python library to strip EXIF data from media files」と記述 |
| Bluesky | AT Protocolの公式ブログ(2023-08-11) | アップロード前に画像のメタデータを取り除くことを「strongly recommended」とし、現時点では除去はクライアント(アプリ)の責任だと説明 |
| Googleフォト | ヘルプ | 位置情報は既定で非公開で、共有時に含めるかを選べる。推定された位置は共有されない。パートナー共有などの例外がある |
| Facebook・Instagram(Meta) | 公式の説明は見つからなかった | プライバシーポリシー(2026-07-23施行)は、利用する情報として「Metadata about content and messages」を挙げている |
| LINE | 公式の説明は見つからなかった | — |
| 公式の説明は見つからなかった | ヘルプは送信時に画像が圧縮されることには触れているが、メタデータには触れていない | |
| Telegram | 公式の説明は見つからなかった | — |
この表から読み取れることは三つある。
一つ目に、「閲覧者に見えない」と「事業者に届かない」は違う。Xの説明は、Exifを一時的に保持し、場所の候補の表示や分析に使うとはっきり書いている。Metaのポリシーもメタデータを利用する情報に含めている。プラットフォームを相手とする脅威モデルでは、アップロードする前に自分で消すしかない。
二つ目に、除去が保証されているのは公式が説明している経路だけだ。Blueskyの例のように、仕様上は除去が受け取る側の責務になっていない場合もある。メッセンジャーの「ファイルとして送る」「元の画質で送る」といった経路でEXIFが残るかどうかについて、今回、公式の説明は見つからなかった。第三者の検証記事では残るとする報告が多いが、アプリの版によって挙動が変わったという報告もあり、ここでは断定しない。確かめたいときは、自分あての送信で受け取ったファイルを後述の方法で読むのが確実だ。
三つ目に、スマートフォンの共有機能は、既定でメタデータを渡しうる。AppleのiPhoneユーザガイドは、写真を共有すると日時、位置、デバイス、キャプションといった関連するメタデータも共有されると注記している。SNSに投稿するつもりでも、メールやクラウド共有、AirDropで直接渡せば、受け取った人は元のファイルを手にする。
スクリーンショットについても触れておく。スクリーンショットは画面から新しく作られる画像なので、元の写真のEXIFは引き継がれないと考えられる(これは仕組みからの推測で、各OSの公式の説明は確認していない。確かめるなら、撮ったスクリーンショットを後述のexiftoolで読む)。ただ、画面に写っているものはすべて残る。元の写真の背景はもちろん、ステータスバーの時刻や通信事業者名、通知の文面、地図アプリの表示、天気ウィジェットの地名もそうだ。スクリーンショットはEXIFの対策にはなっても、画像の中身の対策にはならない。
対策と限界#
対策は二層に分かれる。ファイルの付属情報を消す層と、写すものを選ぶ層だ。前者は手順で確実にでき、後者は判断の問題になる。
付属情報: 撮るとき、共有するとき、公開する前#
いちばん確実なのは、撮影の時点で位置を記録させないことだ。Appleのパーソナルセーフティのガイドは、iPhoneで「設定」>「プライバシーとセキュリティ」>「位置情報サービス」>「カメラ」を「しない」(英語版はNever)にする手順を示し、写真やビデオの位置情報は、カメラアプリが位置情報サービスにアクセスできる場合にのみ記録されると説明している。共有するときは、写真を選んで共有ボタンから「オプション」を開き、「位置情報」をオフにする。オプションの上に「Location Not Included」に当たる表示が出る。すでに撮った写真は、情報の調整から位置を「No Location」にできる(日本語の画面表示はガイドの英語版から訳したもので、実際の表示と異なる場合がある)。
Androidでは、Googleフォトのヘルプによれば、Google製の端末はカメラの設定で「Save location」をオフにする。メーカーによって名前が違い、ヘルプはSamsungの「Location tags」、ソニーやモトローラの「Save location」などの一覧を載せている。注意が要るのは、同じGoogleフォトのヘルプが、Googleフォトで変更・削除できるのは推定された位置と手動で加えた位置だけで、カメラが自動で付けた位置はGoogleフォト上では消せないと書いている点だ。撮影時の設定のほうが後から消すより確実なのは、このためでもある。
パソコンで公開前に処理するなら、Ubuntu 26.04ではExifTool(libimage-exiftool-perl 13.50)とmat2(0.14.0)が使える。読み取りと除去の最小限の形は次のとおりだ。
exiftool -a -u -g1 photo.jpg
exiftool -all= photo.jpg
exiftool -a -u -g1 photo.jpg
exiftool(1p)のmanページによれば、-a -u -g1は重複や未知のタグも含めてグループ別に表示する(ただし性能上の理由ですべてのメタデータを取り出すとは限らないとも書いている)。-all=は画像からすべてのメタ情報を消す例として載っており、既定では元のファイルがphoto.jpg_originalとして残る。manページは、消せないグループがあることや、RAW形式(DNGを除く)にはこの操作をすべきでないことも注意している。mat2(1)は、--showで何も表示されなくてもメタデータがないとは限らないと明記している。道具の使い方と注意点の詳細は自己点検の記事とソフトウェアの基本構成にまとめた。どちらの道具を使っても、処理した後のファイルをもう一度読み直すところまでが手順だ。
写すもの: 何を写さないか#
画像の中身は道具では消えない。ここからは脅威モデル次第の判断になる。
自宅とその周辺を撮らない、または公開しない。自宅の窓から見える景色、玄関先、最寄り駅、毎日通る道は、冒頭の事件で実際に手がかりになった種類のものだ。自宅の中で撮るなら、窓とカーテンの開いた部分を画面に入れない。配信をするなら、背景に窓が入らない向きを選ぶ。
反射を確認する。顔のアップ、眼鏡、鏡越しの写真、窓ガラス、黒い画面は、拡大して見てから出す。自分の目には被写体しか見えていないことが多い。
文字と組み合わせを減らす。看板、標識、電柱の巻広告、バス停、ナンバープレートは、写っているなら切り取るか、塗りつぶす。一つ消せば終わりではない。前の節で見たとおり、照合は特徴の組み合わせで行われる。特徴の数そのものを減らすことが効く。
撮影の場所と時刻を投稿から切り離す。その場で投稿すると、「今そこにいる」ことと影や天気が示す時刻が投稿時刻と一致する。帰宅してから、あるいは数日後に投稿すれば、少なくとも「今どこにいるか」は伝わらなくなる。ただし、遅らせても撮影した場所そのものは隠れない。いつも行く場所の写真は、遅らせて投稿しても、いつも行く場所であることを示す。
同じ場所の写真を積み重ねない。一枚では特定できない場所も、同じ窓、同じ通り、同じ店を角度を変えて何枚も公開すれば、手がかりが積み上がる。過去の投稿は消さない限り残る。新しい写真に気をつけるのと同じだけ、過去の投稿の見直しにも意味がある。
自分の目で、相手の立場で見る。投稿する前に、知らない人の写真だと思って眺め、「どこで撮ったか」を当ててみる。駅の名前や町名が読めてしまうなら、相手にも読める。なお、自分の写真を逆画像検索やAIチャットにかけて確かめる方法もあるが、その時点で写真をその事業者に渡すことになる。公開前の写真でそれをするかどうかは、脅威モデルで決める。
脅威モデルごとの優先度を表にしておく。
| 相手 | 効く対策 | 効かない、または足りないもの |
|---|---|---|
| ストーカー・元交際相手 | 自宅と周辺を写さない、反射の確認、投稿の遅延、過去の投稿の見直し | EXIFの除去だけ。相手の事前の知識は消せない |
| プラットフォーム | アップロード前の自分での除去、撮影時の位置記録の停止 | 閲覧者側での除去(事業者は元の情報を受け取りうる) |
| 法執行機関 | 写真は経路の一つにすぎない。全体の設計が先 | この記事の対策だけで足りることはない |
| 取材源を守る記者 | 提供された写真の付属情報の除去、背景と反射の確認、公開する写真の選別 | 写真の中身が取材源の居場所を示す場合、加工では消しきれないことがある |
記者の立場では、守る対象が自分ではなく取材源になる。取材源から受け取った写真をそのまま記事に使えば、付属情報だけでなく背景も一緒に公開することになる。写真を使わず文章で伝えるという選択肢も、脅威モデルによっては合理的だ。
限界と残るリスク#
ここまでの対策をすべて実行しても、写真からの推定を完全に防ぐことはできない。その理由を具体的に書いておく。
第一に、写真に何かが写っている限り、推定の材料はゼロにならない。空と壁だけの写真でも、光の色や建材の種類から地域を推定しようとすることはできる。対策でできるのは、材料を減らし、推定の幅を広げることまでだ。
第二に、相手の事前の知識は消せない。PIGEONの数字が示すように、AIの推定は世界全体で見ればまだ粗い。しかし、住んでいる市を知っている相手にとって、その粗さは問題にならないことがある。ストーカー型の脅威モデルでもっとも危ういのは、このAIの推定と相手の知識が重なる場面だ。
第三に、自分が撮った写真だけが経路ではない。友人が撮ってタグ付けした写真、家族のSNS、配信の背景、オンラインで売りに出した物の写真も、同じ手がかりを運ぶ。ここは自分の設定では管理できず、周囲の人に頼むしかない部分が残る。
第四に、技術は改善を続けている。PIGEONの著者たちは、現在の技術は通りの単位の推定を確実にはできないとしつつ、精度が上がるにつれて悪用の危険を考える必要があると書いている。今日の誤り率は、来年の誤り率を約束しない。今日公開した写真は、来年のモデルにかけられうる。
第五に、事業者の手元に残る元の情報は、利用者の側から消せない。Xは一時的に保持すると説明しているが、保持の期間は公式の説明に書かれていない。
そして逆向きのリスクもある。推定は誤る。Bellingcatの検証では、AIは自信ありげに別の国を答えた。推定を信じた誰かが、まったく無関係の人の家を訪ねることもありうる。自分の写真を守ることは、こうした誤りの材料を世に出さないことでもある。
まとめ#
SNSで日常の写真を公開しているだけの人なら、今日はスマートフォンのカメラの位置情報の設定を開いて、撮影時に位置を記録しない設定になっているかを確かめるところから始めるとよい。そのうえで、直近に公開した写真を見返し、自宅の窓の外や最寄り駅が写っていないかを確認する。
顔を出して活動している人、配信をしている人は、過去の投稿を「知らない人が自宅を探すつもりで見たら」という目で一度見直す価値がある。見るべきは、窓の外、瞳や眼鏡の反射、配信の背景、同じ場所を写した写真の積み重ねだ。
元交際相手や特定の人物に居場所を知られることを恐れている人は、写真の対策だけでなく、端末や共有設定の点検も必要になる。親密な関係の脅威モデルで点検の順番を扱っている。身の危険を感じているなら、写真の削除や設定の変更より先に、警察相談専用電話(#9110)などの窓口に相談するほうが安全なことがある。
取材源を守る立場の人は、受け取った写真を公開する前に、付属情報を消し、その後で背景と反射を確認する。写真を使わずに伝えられないかも検討する。
どの立場でも、付属情報の除去は道具でできる確実な作業で、画像の中身は判断で減らすしかない部分だ。この二つを分けて考えるところから始めるとよい。公開情報の突き合わせ全般はOSINTの記事、文章や活動時間から身元がつながる経路は文章からの特定で扱っている。
出典#
- CIPA DC-008-Translation-2012 — Exchangeable image file format for digital still cameras: Exif Version 2.3(表15 GPS属性情報、GPSLatitude・GPSImgDirection・CameraOwnerName・BodySerialNumberの定義。参照日2026-11-08)
- CIPA — Update History(Exif 3.0の公開2023-05-29、Exif 3.1の公開2026-01-30、DC-010 Exif metadata for XMP。参照日2026-11-08)
- Haas, Skreta, Alberti, Finn — PIGEON: Predicting Image Geolocations(arXiv 2307.05845v6)(表1・表2・表3、第5節「Ethical considerations」。参照日2026-11-08)
- Haas et al. — PIGEON: Predicting Image Geolocations(CVPR 2024、CVF Open Access)(参照日2026-11-08)
- Bellingcat — Have LLMs Finally Mastered Geolocation?(2025-06-06)(参照日2026-11-08)
- Bellingcat — A Beginner's Guide to Geolocating Videos(2014-07-09)(参照日2026-11-08)
- Bellingcat — Finding Geolocation Leads with Bellingcat's OpenStreetMap Search Tool(2023-05-08)(参照日2026-11-08)
- Bellingcat — Chasing Shadows: Geolocate Images with Bellingcat's Shadow Finder Tool(2024-08-22)(参照日2026-11-08)
- Bellingcat — Resources: How-tos(参照日2026-11-08)
- GeoSpy(Graylark Technologies)公式サイト(性能・実績はすべて事業者の主張。参照日2026-11-08)
- 404 Media — The Powerful AI Tool That Cops (or Stalkers) Can Use to Geolocate Photos in Seconds(2025-01-20)(参照日2026-11-08)
- 404 Media — Cops Are Buying 'GeoSpy', an AI That Geolocates Photos in Seconds(2026-02-12)(参照日2026-11-08)
- 文春オンライン — 瞳に映る景色で住所特定……地下アイドルストーカー「住居侵入・強制わいせつ致傷」の異常手口(2020-02-21)(2020-02-18の東京地裁初公判の傍聴記事。参照日2026-11-08)
- X Help Center — How to post photos or GIFs on X(「What happens to the Exif data for my photo?」。参照日2026-11-08)
- Signal(@signalapp)の投稿(2020-06-09)(参照日2026-11-08)
- signalapp/Signal-Android — Strip EXIF metadata from all JPEG images(2018-03-19)(参照日2026-11-08)
- Discord — Modern Image Formats at Discord: Supporting WebP and AVIF(2025-03-12)(参照日2026-11-08)
- AT Protocol — Posting via the Bluesky API(2023-08-11)(参照日2026-11-08)
- Meta — Privacy Policy(2026-07-23施行)(参照日2026-11-08)
- Apple — Manage location metadata in Photos(パーソナルセーフティユーザガイド)(参照日2026-11-08)
- Apple — Share photos and videos on iPhone(iPhoneユーザガイド)(参照日2026-11-08)
- Google Photos Help — Change your camera location settings(参照日2026-11-08)
- Google Photos Help — Understand, find & edit your photos' locations(Android)(参照日2026-11-08)
- Google Photos Help — How Google Photos protects your location data(参照日2026-11-08)
- Ubuntu Manpage — exiftool(1p)(Ubuntu 26.04 resolute)(参照日2026-11-08)
- Ubuntu Manpage — mat2(1)(Ubuntu 26.04 resolute)(参照日2026-11-08)
- 東電タウンプランニング — 電柱広告デザインプラン(町名番地表示。参照日2026-11-08)