第１ 画像本体だけを管理しても十分ではない
法律事務所や税理士事務所では，エラー画面，裁判資料，給与台帳又は本人確認書類の一部を，スクリーンショットとして担当者へ伝えることがある。
送信が簡単である反面，画像の内容だけでなく，画像から読み取られた文字，題名，元のページのURL等が別に保存・共有される場合がある。
本記事は，令和８年９月に公表された画像共有サービス「Gyazo」の情報漏えいを手掛かりに，何を確認してからアップロードし，何を削除・再共有の対象とするかを整理する。
公表資料の確認日は同年１０月１３日である。
個々のサービス，契約又はプランについて一律の安全性を認定するものではない。
実務上の結論は，①画像本体と付随情報を別に把握する，②保全用データと共有用コピーを分ける，③入力・共有前に不要な情報を除く，④削除の範囲と残存期間を確認する，⑤停止した画像の配信再開では内容と閲覧者を再点検する，という五点である。
以下の確認票や担当の決め方は，本記事の運用提案であり，一律の法定様式ではない。
第２ Gyazoの公表資料が示す三つの区別
１ 画像，OCR及びメタデータ
Helpfeelの第一報は，流出した画像関連のメタデータとして，画像URLの構成に用いられる画像ID，アップロード元のIPアドレス，User-Agent，画像に含まれる場合のEXIF位置情報，OCRで抽出した文字，画像の題名及び元のURL等を挙げている。
これは同社の公表内容であり，外部から独立したフォレンジック検証を行った結果ではない。
OCRとは，画像に写った文字を文字データとして読み取る処理である。
画像本体を閲覧できなくても，OCRの文字が残れば，氏名，事件番号，口座番号又は取引内容が読める場合がある。
逆に，すべてのスクリーンショットに位置情報やOCRが存在するわけでもない。
利用するサービスが実際に生成・保持する項目を確認する必要がある。
２ 削除済み画像と，その画像に関する情報
同社の第二報は，過去に削除された画像に関するメタデータ約１．７４億件の流出を追加で公表した。
主に令和５年２月以前に画像又はアカウントが削除されたものが対象であり，この追加確認に削除済み画像ファイルそのものは含まれていないとしている。
したがって，「削除した画像約１．７４億枚が流出した」と言い換えることはできない。
また，この公表を，現在のすべての削除処理に同じ残存があることの証明として扱うこともできない。
学びは，利用者から見た削除，画像本体の消去及び関連データの消去が同じとは限らず，それぞれを確認する必要があるという点にある。
３ サービス再開と，画像の配信再開
サービス再開案内は，利用者が画像の配信を再開すると，事故前の閲覧範囲が適用されると説明する。
９月２９日の追記では，Gyazo Teamsの事故前にアップロードされた画像について，配信停止中でも同じチームのメンバーが閲覧できる仕様を示している。
「自分のみ」設定は除かれ，パスワード保護のある画像は引き続き入力を要するとされる。
このため，「サービスを再開しても全画像が本人だけに見える」と一括して説明することは適切でない。
サービスの復旧，個々の画像の配信再開及びチーム内の閲覧権限を分ける必要がある。
現在の設定を確認せず，過去の案内だけで共有先を決めてはならない。
第３ アップロード前に確認する
１ その画面を外部へ送る必要があるか
最初に，問い合わせ又は共同作業の目的と，必要な情報を決める。
エラーコードの説明で足りるなら，別の依頼者の氏名，開いているブラウザのタブ，通知欄又は給与台帳全体まで添える必要はない。
公開資料だけで再現できる問題であれば，秘密情報を含まない再現画面を作る方法もある。
画像共有サービスへアップロードする行為と，画像URLを相手へ送る行為は別の段階である。
リンクをまだ送っていなくても，アップロード先に画像が届いていることを前提に，送信先，利用目的，保存条件及び取扱権限を判断する。
法律事務所では事件記録や第三者の秘密・プライバシー，税理士事務所では顧客の帳簿や従業員情報の取扱いを確認する。
氏名を消しても，法人の資金繰り，取引条件又は調査方針が残ることがある。
既存の事件記録の返還・保管・廃棄及び税理士事務所のAI入力資料の記事で扱う管理を，画像共有にも適用して検討する。
２ 保全用と共有用を分ける
証拠として必要な元データを上書きして，公開・共有用の加工をするべきではない。
取得元，日時，担当者及び取得方法を記録し，保全用データへのアクセスを限定した上で，共有目的に必要な部分だけを別のコピーへ切り出す。
共有用では，画面上の氏名や番号に加え，ファイル名，画像の題名，元のURL，画像に付随する位置情報等を点検する。
既に作成されたOCRの文字，PDFの文字層，又は別の保存済みコピーがある場合は，画像へ黒い図形を重ねただけでそれらまで消えたと扱わない。
加工後の出力を開き，必要に応じて文字の検索・コピー結果も確認する。
この点検のために，未承認の外部OCRへ元の機密資料を送り直してはならない。
承認された環境と処理方法を用いる。
詳しくは画像・動画ファイルの形式と位置情報も参照されたい。
AdobeのAcrobat Proに関する公式説明も，表示されるテキスト・画像の墨消しと，メタデータや埋込みコンテンツ等の非表示情報の削除を別に説明している。
これは同製品の機能についての説明であり，任意の黒塗り操作や別製品でも同じ効果になるとの保証ではない。
処理後のファイルを確認するとともに，サービス側に既に送信・生成された別データは，ファイルの加工とは別に扱う。
３ 閲覧者と有効期間を決める
送信前に，所有者，指定した個人，同一チーム，リンクを知っている者又は一般公開という閲覧範囲を確認する。
推測しにくいURLであることだけで，個人ごとのアクセス制御があると判断してはならない。
必要な受信者への限定，期限の設定及び作業終了時の権限整理が可能かを確認する。
チーム内共有でも，別事件の担当者，外部の協力者又は退所・退職した者が含まれていないかを点検する。
共有設定の画面だけでなく，送信したリンクが予定した範囲で閲覧できることを，機密情報を不用意に公開しない方法で確認する。
第４ 削除対象と保存が必要な資料を分ける
１ 保存期間を画像の種類ごとに決める
原資料を保存する必要があることは，同じ内容の作業用画像，OCR結果又は共有サービス上の複製をすべて同期間残す理由にはならない。
他方，法令，規程，契約又は紛争対応上必要な資料を，漏えい予防だけを理由に一括削除してよいわけでもない。
責任者は，原資料，保全用複製，共有用画像，OCR，検索用データ及びログを分け，保存目的，根拠，起算点，満了日並びに廃棄を保留する条件を定める。
税務上の保存期間は資料・税目・主体によって異なるため，「税務資料だから画像も一律７年」としてはいけない。
２ 削除を確認する対象
削除の点検では，次の対象を区別するとよい。
① 画像本体，動画，サムネイル等の派生ファイル
② OCRの文字，画像の題名，元のURL及びその他のメタデータ
③ 検索用の索引，履歴，ごみ箱及び同期端末の複製
④ 再委託先の処理データ，バックアップ及び監査・障害調査用のログ
これらがすべてのサービスに存在するという意味ではない。
契約・仕様・事業者の回答と，利用者が実際に確認できた結果を対応させる。
管理画面から見えなくなっただけで，事業者側の全データが消えたとの結論は出ない。
３ 削除記録に何を残すか
運用上は，対象を識別できる情報，担当者，実施日，処理方法，確認結果，残存する範囲・理由，残存期間の満了予定及び再確認日を残すことが考えられる。
削除証明書を受領しても，そこに書かれた対象が画像本体だけなのか，OCRや再委託先まで含むのかを確認する。
削除の記録自体へ元の秘密情報を丸ごと貼り付けると，新たな複製になる。
識別子や対象範囲で足りる場合は，記録に残す情報も必要な範囲へ限定する。
残存がある場合は，「全件削除済み」と表示せず，その範囲のアクセス制限及び次の点検を管理する。
第５ 共有を再開するときの順序
１ 誰が再開を判断するか
サービス復旧時に，担当者が便利だからという理由だけですべての画像を一括再開するべきではない。
事件又は顧客の担当者が内容と利用目的を確認し，事務所の管理責任者が現在の閲覧者及び取扱条件を点検する。
再開の判断を誰が行うかは，停止中に決めておくことが望ましい。
画像ごとに，①現在も共有が必要か，②秘密情報を含むか，③以前の閲覧範囲へ戻すと誰が見られるか，④退所者等のアクセスが残っていないか，⑤差替えた共有用コピーで目的を達成できないかを確認する。
保存が必要であっても，外部から閲覧可能にする必要があるとは限らない。
２ 既存のリンクと埋込みも点検する
画像URLが過去のメール，チャット，顧客向け資料又はウェブページに貼られている場合，配信再開によって以前の受信者が再び閲覧できることがある。
URL，利用場所，送信先及び現在の権限を対応させて点検する。
再開後には，承認した画像と閲覧範囲が実際の表示に反映されたことを確認する。
予定外の閲覧が判明したら，追加の共有を止め，内容，時刻，設定及びアクセス記録を保全して管理責任者へ報告する。
共有リンクの失効や停止の効果はサービスごとに異なるため，ボタンを押したことだけで第三者の全複製を回収できたと扱わない。
第６ 漏えい通知を受けた事務所の確認票
利用サービスから事故の通知を受けたら，画像をアップロードしたアカウントと業務を対応させ，次の事項を確認する。
① どの時期の画像・関連データが対象か。登録日と削除日を取り違えていないか。
② 画像ファイル，OCR，題名，元のURL，位置情報又は認証関連情報のどれが対象か。
③ 影響する事件・顧客と，資料に含まれる第三者は誰か。
④ 漏えいが確認された範囲と，可能性が残る範囲はどこか。
⑤ 現在の共有設定，リンク・チームの閲覧者，連携先及び削除の状態はどうか。
⑥ 顧客への説明，契約上の通知，個人情報保護法上の報告・本人通知を誰が判断し，実施結果をどこへ記録するか。
サービス事業者が当局へ報告したことだけで，利用事務所自身の対応がすべて終わるとは限らない。
委託関係，情報の種類，実際の取扱い及び事故状況に即して判断する。
初動については法律事務所のサイバー事故初動チェックリストを参照されたい。
事故通知の数量を人数へ置き換えず，メタデータ件数を画像ファイルの流出枚数へ置き換えない。
事業者が「二次被害は確認していない」と説明しても，将来の悪用可能性をすべて否定したものとして顧客へ伝えるべきではない。
第７ 根拠と確認範囲
本記事が扱うGyazoの事故情報は，Helpfeelの第一報，第二報及びサービス再開案内に記載された内容である。
個々の利用者の漏えい項目，実際の閲覧者，損害，内部の削除処理又は最新の契約条件を，本記事だけで確定することはできない。
本記事は，Gyazoの事故について事業者の違法性や賠償責任を認定するものではなく，公表資料から事務所の運用上の確認事項を整理したものである。
この事故名・事業者名による判例秘書の独立検索及び判決本文の取得・照合は行っておらず，運用提案に裁判例の裏付けがあるとは表示しない。
主な出典は次のとおりである。
① Helpfeel第一報（令和８年９月１６日）。確認ページは英語版の本文である。
② Helpfeel第二報（同月２５日）。
削除済み画像に関するメタデータ及び数量の単位を確認した。
③ Helpfeelサービス再開案内。
同月２９日の追記を含めて確認した。
④ Adobe「Acrobat ProでのPDFの墨消しと非表示情報の削除について」（令和７年１１月５日最終更新）。
契約条件や共有・削除の機能は変更され得る。
実際の導入，処理，削除及び再開の時点では，利用しているサービス・プラン・機能の最新条件と現設定を確認する必要がある。