AIにスクショを貼る人へ|1枚で61か所読まれる。30秒の3手
1440×900のスクショ1枚を機械に読ませたら61ブロック・1,940字が読めた。うち48%は用件の外。さらに「小さくすれば消える」を実測すると、macOS標準の縮小ではGPS7項目が丸ごと残った。貼る前30秒の3手を実測つきで。
「ここだけ見てほしい」と思ってスクショを撮り、AIに貼る。私も1日に何度もやります。
ところが昨日、自分がいつも貼っている画像を機械に読ませてみて、手が止まりました。1440×900のスクリーンショット1枚から、61か所・合計1,940文字が読み取れたのです。私が見せたかったのは、そのうちの1段落だけでした。
もっと意外だったのは、対策のほうです。「小さくすれば消える」と思って使っていたmacOS標準のリサイズは、画素を4分の1にしても、位置情報を1項目も落としませんでした。
この記事は、その日の実測をそのまま書いたものです。数字はすべて自分の手元で測っています。
「1か所だけ見せたつもり」が、実際には61か所だった
まず、誰でも再現できる形で測りました。使ったのは公開されているPython公式ドキュメントのページ(jsonモジュールの解説)です。これを1440×900のウィンドウで、ごく普通に1画面ぶんスクリーンショットしました。
この画像を、macOSに標準で入っている文字認識(Visionフレームワーク)にかけます。AIが画像を読むときにやっていることと、原理は同じです。結果はこうでした。
- 読み取れたテキストのかたまり:61ブロック
- 読み取れた文字数:合計1,940字
私がこの画面で聞きたかったのは「この引数の意味」ひとつだけでした。つまり、必要だったのは1ブロック。実際に渡したのは61ブロックです。
なぜこうなるのか。人間は画面の真ん中を見ます。端のほうは視界に入っていても「読んでいない」。ところが機械は、真ん中も端も等しく読みます。文字の大きさも、目立つかどうかも関係ありません。「小さいから」「隅っこだから」大丈夫という私たちの感覚が、そのまま通じない相手に画像を渡している——これが今回いちばん腑に落ちた点でした。
今日できること:直前に貼った1枚を思い出して、その画像の四隅に何が写っていたかを言えるか、自分に聞いてみてください。
周辺の29ブロックは、用件と1文字も関係がなかった
61ブロックがどこにあったのかを、座標で3つに分けて数え直しました。
スクショ1枚(1440×900)から機械が読んだもの
上部ナビ・パンくず → 6ブロック / 199字 … 用件と無関係
左サイドバー → 23ブロック / 480字 … 用件と無関係
本文エリア → 32ブロック / 1,261字 … ここだけが用件
─────────────────────────
合計 → 61ブロック / 1,940字
うち無関係 → 29ブロック=48% / 679字=35%
ブロック数でいえば、読まれたものの約半分が「用件の外側」でした。文字数でも3分の1です。
今回は公開ドキュメントなので、周辺に写っていたのは「Table of Contents」「Quick search」といった無害な文字列でした。問題は、あなたの画面の同じ場所に何が写っているかです。上部にはブラウザのタブ名が並び、右上には通知が出ているかもしれません。メニューバーにはアカウント名と時刻、左にはブックマークバー。私の実測では、その帯が画像の情報量の3分の1を占めていました。その3分の1が「無害な目次」なのか「取引先の名前が並んだタブ」なのかは、撮った瞬間の画面しだいです。
そして、この帯は自分ではまず見返しません。見たい場所を見て、撮って、貼る。周辺は最初から視界の外にあるからです。
今日できること:ブラウザのタブを1本だけ、別ウィンドウに逃がしてください。それだけで、次の1枚から消えます。
もう一つの経路:写真には、見えない7項目が入っている
スクショの危険が「写っているもの」だとすれば、写真の危険は「写っていないのに入っているもの」です。経路がまったく別なので、分けて考える必要があります。
検証には、他人の写真ではなく、スマホで撮った写真と同じ構成のテスト画像を自分で作って使いました。入れたのはEXIFという規格の情報で、次の9項目です。
- メーカー名/機種名/OSのバージョン
- 撮影日時/作成日時
- 作者名/著作権表記
- 画像の向き
- GPS情報(この中にさらに7項目)
GPSの中身は、緯度・経度・高度・高度の基準・測位日など7項目でした。画像を開いても目には何も見えません。それでもファイルの中には、ずっとそのまま残っています。
なぜこれが「AIに貼る」話と関係するのか。エージェント型のAIが、チャットの外に出て個人のデータに触り始めているからです。報道ベースの話として、9月4日にGoogleが常駐エージェント「Gemini Spark」にGoogleフォトの操作権限を追加したと伝えられました(米国の有料プラン向けで、日本での提供時期は未定)。1枚貼るかどうかの話が、ライブラリごと預ける話に近づいています。だからこそ、1枚のときに何が付いてくるのかを知っておく価値があると思いました。
今日できること:自分のスマホで撮った写真を1枚選び、次の節のコードで中身を見てください。
「小さくすれば消える」を実測したら、1項目も消えていなかった
ここがいちばん驚いた結果です。よく言われる4つの「対策」を、同じ1枚の写真に順番にかけて、EXIFが何項目残るかを数えました。
同じ写真に4つの処理をかけた結果
A 縮小して保存し直す(Python) 1200×900→600×450 EXIF 0項目 / GPS 0項目 → 消えた
B PNGに変換する 1200×900のまま EXIF 0項目 / GPS 0項目 → 消えた
C macOS標準のsipsで縮小 1200×900→600×450 EXIF 9項目 / GPS 7項目 → 残った
D ピクセルだけ入れ直す 1200×900のまま EXIF 0項目 / GPS 0項目 → 消えた
Cだけが、1項目も落ちませんでした。
画素数は4分の1になり、ファイルサイズも18,125バイトから5,687バイトへ、約3分の1に減っています。それでも緯度・経度・機種名・撮影日時・作者名は、9項目すべてがそのまま残っていました。中身を実際に取り出して確認したところ、緯度経度は元と同じ場所を指したままでした。
つまり「軽くしたから中身も減ったはずだ」という直感は、ここで裏切られます。減ったのは画素だけで、情報の棚は新しいファイルにそっくり引き継がれていました。
大事なのは、AとCが人間の目にはまったく同じ操作に見えることです。どちらも「写真を小さくした」。違うのは使った道具だけで、結果は正反対でした。だから「縮小した」という行為そのものは、何の保証にもなりません。
今日できること:ふだん写真を小さくするのに使っている道具の名前を1つ書き出してください。それが安全側かどうかは、次の節のコードで確かめられます。
貼る前の30秒でやる3手
実測をもとに、順番まで決めた形にしました。上から順にやれば30秒です。
手1:全画面ではなく、範囲で撮る Mac は cmd + shift + 4、Windows は Win + Shift + S で範囲指定になります。 実測:同じ画面を、見せたい範囲だけに切り出してからもう一度読ませたところ、 61ブロック → 10ブロック(84%減)、1,940字 → 703字(64%減)になりました。 これがいちばん効きます。しかも撮り方を変えるだけで、後処理がいりません。
手2:写真は、一度PNGを通してから貼る プレビューなどでPNGとして書き出し直す。実測で EXIF 9項目/GPS 7項目 → 0項目/0項目 になりました。 ただし重要な注意があります。PNGにしても「写っている文字」は1文字も減りません。 手1と手2はまったく別の問題への対策なので、両方いります。
手3:iPhoneから送るなら、共有シートの「オプション」を開く Apple公式の手順はこうです。共有ボタンをタップ → 画面上部の「オプション」 → 「位置情報」をオフ → 「完了」。 写真そのものから消すなら、写真を開く →「その他」→「位置情報を調整」→「位置情報なし」。 Macの写真アプリなら、写真を選んで「画像」→「位置情報」→「位置情報を非表示」です。 参考:Apple「写真で位置情報メタデータの収集を停止して削除する」 https://support.apple.com/ja-jp/guide/personal-safety/ips0d7a5df82/web
そして、自分の画像に何が入っているかを確かめるコードです。そのままコピーして check.py という名前で保存してください。
# 事前に一度だけ: pip3 install pillow
# 使い方: python3 check.py 画像1 画像2 ...
import sys
from PIL import Image, ExifTags
tag = lambda e: ", ".join(sorted(ExifTags.TAGS.get(k, str(k)) for k in e.keys())) or "(なし)"
for p in sys.argv[1:]: im = Image.open(p); ex = im.getexif(); gps = ex.get_ifd(0x8825); print(p, im.format, im.size, "→ EXIF", len(ex), "項目 / GPS", len(gps), "項目", "★位置情報あり" if gps else ""); print(" 中身:", tag(ex))
なお、このコードをわざと字下げなしで書いているのには理由があります。noteは本文に貼ったコードの行頭の半角スペースを消してしまうため、ふつうにforループを書くと、読者がコピーした時点で動かなくなるからです。全角スペースで字下げすればnote上では残りますが、Pythonは全角スペースを字下げとして受け付けません(手元で試したところ SyntaxError になりました)。そこでforの中身を1行に畳んで、字下げそのものを無くしています。
インストールなしで済ませたい場合、macOSなら sips -g all 画像ファイル で機種名・撮影日時・作者名までは表示されます。ただしGPSは出ませんでした(私の環境で確認)。位置情報まで見たいなら、上のコードが必要です。
今日できること:check.py を保存して、直近にAIへ貼った画像を1枚だけ通してください。所要30秒です。
つまずくのは、だいたいこの4か所
①「PNGにしたから安全」 違います。PNGはEXIFを落としますが、写っている文字は1文字も減りません。今回のスクショはPNGでEXIF 0項目でしたが、それでも1,940字が読めました。埋め込み情報とフレームは、別々に潰す必要があります。
②「モザイクをかけたから大丈夫」 塗りつぶしをレイヤーとして保存できる形式のまま渡すと、下の層が残ることがあります。塗ったあとに一度PNGかJPEGへ書き出し直して、書き出した側を貼るのが確実です。書き出しは「画像を平らに潰す」操作なので、ここで層が消えます。
③「小さくしたから大丈夫」 上のCのとおりです。同じ「縮小」でも道具によって結果が正反対でした。行為の名前ではなく、実際に測った結果で判断してください。
④「あとで消せる」 貼った時点で、画像は相手のサーバに渡っています。学習に使われるかどうかは設定しだいですが、渡した事実そのものは取り消せません。消せるのは自分の手元の履歴だけ、と考えたほうが安全です。だから対策は、すべて「貼る前」に寄せてあります。
今日・今週・30日でやること
今日(1分) ブラウザのタブを整理し、範囲指定のショートカット(cmd + shift + 4 / Win + Shift + S)を1回押して体に入れる。それだけで次の1枚が84%軽くなります。
今週(15分) check.py を保存して、自分がよく貼る画像を3枚通す。スマホの写真・スクショ・加工した画像の3種類を選ぶと、どこに何が入るかの地図ができます。あわせてiPhoneの共有シートで「位置情報」をオフにする場所を、実際に一度開いておく。
30日(習慣) 「貼る前に範囲で撮り直す」を既定の動作にする。私は撮ったあとにプレビューで開き直す手間が惜しくて全画面を貼っていましたが、最初から範囲で撮れば手間はゼロで、渡す情報だけが6分の1になります。習慣として置き換えるほうが、毎回気をつけるより確実です。
まとめ
-
要点 スクショの危険は「写っているもの」、写真の危険は「写っていないのに入っているもの」で、経路が別です。1440×900の1枚から61ブロック・1,940字が読まれ、その48%は用件の外でした。そして「小さくすれば消える」は、道具によっては成立しません。
-
今日の小さな一歩 今から、次にAIへ画像を貼るときだけ、全画面ではなく範囲指定で撮ってみてください。押すキーが1つ増えるだけで、渡す文字数が3分の1になります。
-
筆者の視点 私はAIに毎日大量の画像を渡しています。だからこそ、危ないと言われている話を鵜呑みにせず、自分の環境で測ることにしています。今回いちばんの収穫は「危険の発見」ではなく、良かれと思ってやっていた対策の1つが効いていなかったと分かったことでした。効かない対策を続けているあいだ、私たちは安全だと思い込んでいます。測らないかぎり、そこは見えません。
同じ場面、ありませんか。役に立ったら♡やブックマークをどうぞ。毎日こういう検証を続けています。
参考にした一次情報
- Apple「写真で位置情報メタデータの収集を停止して削除する」 https://support.apple.com/ja-jp/guide/personal-safety/ips0d7a5df82/web
- 検証に使った公開ページ:Python公式ドキュメント json — JSON encoder and decoder https://docs.python.org/3/library/json.html
#AI活用 #ChatGPT #生成AI #業務効率化 #仕事術 #プロンプト #個人情報保護 #セキュリティ #スクリーンショット
この記事は note にも掲載しています(初出: note版 2026-09-08)。