PDFの黒塗りと墨消しの違い｜消したつもりで残るものが、4か所ある

梟〜GLEANINGS〜

2026年9月12日 13:30

社外に出す見積書から、原価の欄だけを隠したい。
PDFを開いて、その部分に黒い四角を置いて、上書き保存しました。

画面では、たしかに見えません。
受け取った相手がその部分をなぞってコピーし、メモ帳に貼り付けるまでは。

この記事では、消したつもりで消えていない操作を4つ扱います。
PDFの黒塗り、robots.txt、メールの送信取り消し、そしてクラウドの削除です。

共通しているのは、操作した本人の画面では成功して見える、という点です。
だから、作った人も、確認した上司も、気づけません。

先に、調べていていちばん意外だったことを2つ書いておきます。

1つ目。
Microsoftの「ドキュメント検査」は、隠れたデータを見つけて消すための機能ですが、覆われたものは見つけられない、と自分で書いています。
掃除の道具のほうが、先に降参しています。

2つ目。
robots.txtに「見ないでください」と書いたページは、検索結果に出ることがあります。
Googleが自分のドキュメントに、出る条件まで書いています。

この記事は、Adobe Acrobat ヘルプの墨消しの2ページ、Microsoft のドキュメント検査・Outlook・SharePoint の各ドキュメント、IETF の RFC 9309、Google 検索セントラル、Gmail ヘルプ、AWS の Amazon EC2 ユーザーガイドをもとに、2026年9月12日時点の内容にしています。

黒い四角は、文字の上に置いただけである

Adobeは「覆われたテキスト」を、データの種類として数えている

まず、公式の資料がどう説明しているかを見ます。

Adobeのヘルプに、PDFの中で墨消しの対象になり得るデータを並べた表があります。
そこに「非表示テキスト」という項目があり、説明はこうです。

透明であるか、他のコンテンツで覆われているか、または背景色と同じ色のテキスト

他のコンテンツで覆われているテキスト。
これが、黒い四角を重ねた状態です。

覆われたテキストは、消えたのではありません。
見えない状態のデータとして、PDFの中に分類されています。

同じ表に、14の種類が並んでいる

この表には、ほかにも見落としやすいものが並んでいます。

「削除またはトリミングされたコンテンツ」の説明は、こうです。

トリミングされたページや削除された画像など、削除されて表示されなくなったコンテンツ

ページを切り詰めても、画像を消しても、表示されなくなっただけの場合がある、ということです。

そしてもう1つ、黒い四角の話に直接あたる項目があります。

重なり合うオブジェクト（画像、ベクターグラフィック、グラデーション、パターンを含む）

重なり合っていること自体が、点検の対象として1行を与えられています。

表の残りも挙げておきます。
可視テキスト、画像、フォームフィールド、メタデータ、添付ファイル、しおり、コメントとマークアップ、フォームフィールドデータ、非表示のレイヤー、埋め込まれた検索用インデックス、リンク、アクションおよび JavaScript。
全部で14種類です。

埋め込まれた検索用インデックスは、とくに忘れられます。
説明は「PDF ファイル内の検索を高速化するインデックス」です。
検索を速くするために作られた索引が残っていれば、そこから言葉を拾える可能性があります。

紙に塗るのと、PDFに四角を置くのは、別のことである

なぜこうなるのか。

PDFは紙のように見えますが、紙ではありません。
文字は文字のデータとして、画像は画像のデータとして入っています。

紙であれば、黒いペンで塗りつぶした時点で、下の文字は物理的になくなります。
PDFでは、黒い四角は新しいデータとして追加されるだけです。
下の文字は、そのまま残ります。

紙の感覚でPDFを扱うと、この差に気づけません。
そして、ほとんどの人が紙の感覚で扱っています。

墨消しは、覆うのではなく置き換える

では、正しい方法は何か。
墨消しという機能です。

Adobeの説明は、こうです。

墨消しは、PDF 文書から機密情報を完全に非表示にします。Acrobat Pro では、テキストや画像などのコンテンツを墨消しすると色付きの長方形で置き換えられ、機密情報を復元したり表示したりすることはできなくなります。

注目したいのは「置き換えられ」という言葉です。

画面に出る結果は、どちらも黒い長方形です。
けれども、片方は元のテキストの上に図形を置いただけ。
もう片方は、元のテキストそのものを長方形に置き換えています。

見た目が同じなので、開いた側にはこの違いが見分けられません。

元に戻せないから、消えている

墨消しについては、こうも書かれています。

永続性：墨消しは永続的であり、一度適用して保存したら、元に戻すことはできません。

元に戻せない。
不便に聞こえますが、戻せないからこそ消えている、ということでもあります。

図形を重ねただけなら、その図形を動かせば下が出てきます。
戻せるということは、残っているということです。

作業のときに「元に戻せます」と案内が出たら、それは消えていません。

墨消しをしても、まだ残るものがある

もう1つ、知っておくべき制限があります。
同じページに、墨消しの範囲がこう書かれています。

範囲：墨消しで削除できるのは、表示されているテキストとグラフィックのみです。メタデータや埋め込まれたコンテンツなどの非表示のデータは、別々に削除する必要があります。

別々に削除する必要がある。
本文の墨消しだけでは足りない、ということです。

そのための機能が、非表示情報の削除です。

非表示情報の削除は、PDF から非表示のデータを削除することに重点を置いています。これには、メタデータ、埋め込みコンテンツ、スクリプト、その他の非表示の要素が含まれ、機密情報を含んでいたりセキュリティリスクをもたらす可能性があります。

つまり、社外に出すPDFに対しては操作が2つあります。
見えている機密を墨消しする。
見えていないデータを別に削除する。

片方だけで終えている会社が多いはずです。
作成者名や、社内のファイルサーバーのパスが、そのまま出ていきます。

WordとExcelにも、同じ穴がある

PDFの話だと思って読むと、元のファイルのほうを見落とします。
WordとExcelにも、同じ構造の問題があります。

ドキュメント検査という機能がある

Microsoftは、共有前の点検機能を用意しています。

Microsoft 365 ドキュメントファイルのコピーをクライアントや同僚と共有する場合は、ドキュメントに非表示のデータや個人情報がないか確認して削除することをお勧めします。

Wordであれば、コメント、変更履歴マーク、文書のバージョン情報、インク注釈。
ドキュメントのプロパティ、ユーザー名、テンプレート名、電子メールヘッダー。
ヘッダー、フッター、透かし。
これらを見つけて削除できます。

Excelであれば、非表示の行、データが入った非表示の列、非表示のワークシート。
プリンターパスの情報、アクティブでない外部データ接続、定義された名前とテーブル名に関するコメント。

注意書きも付いています。

ドキュメント検査で削除されたデータは必ずしも復元できるとは限らないため、元の文書のコピーでドキュメント検査を使用することを強くお勧めします。

検査が「見つけられない」と、自分で書いている

ここからが、この章でいちばん言いたいことです。

同じ表の中に、検査の限界が2か所、メモとして書かれています。

1つ目は、隠し文字のところです。

メモ: このインスペクターでは、他の方法では非表示にされたテキスト (たとえば、白地に白いテキスト) を検出できません。

白い紙に白い文字。
古典的な隠し方ですが、点検機能はこれを拾いません。

2つ目は、非表示の内容のところです。

メモ: このインスペクターは、他のオブジェクトに覆われているオブジェクトを検出できません。

覆われているオブジェクトを、検出しません。
PDFの黒い四角と、まったく同じ状態です。

隠れたデータを消すための機能が、覆われたものは対象外だと明記しています。
つまり、図形を上に置いて隠した部分は、ドキュメント検査を通しても残ります。

Excelの側にも、似た但し書きがあります。

ドキュメント検査では、非表示の列に含まれている図形、グラフ、コントロール、Microsoft ActiveX オブジェクトおよびコントロール、画像、または SmartArt グラフィックは検出されません。

消す前に、開いて見る

Excelの非表示については、Microsoft自身が手順を1つ足しています。

非表示のワークシートに含まれている情報がわからない場合は、ドキュメント検査を閉じ、非表示のワークシートを再表示して、その内容を確認します。

ドキュメント検査を閉じて、再表示して、見る。
自動で消すのではなく、目で見ろ、という指示です。

見積書の非表示シートに原価表が入っている、というのはよくある形です。
非表示の行や列は、印刷しても出ませんし、画面でも見えません。
ファイルを渡すときにだけ、一緒に渡ります。

robots.txtは、アクセスを禁じる仕組みではない

2つ目の操作に移ります。

自社サイトに、検索には出したくないページがあるとします。
関係者だけに見せる資料、テスト中のページ、社内向けの案内。
制作会社に相談すると、robots.txtに書いておきます、という答えが返ってくることがあります。

これで隠せた、と思ってはいけません。

標準が「アクセス認可の形式ではない」と書いている

robots.txtは、サイトの入口に置くテキストファイルです。
検索エンジンなどの巡回プログラムに、どこを見てよいかを伝えます。

この仕組みは、2022年9月にRFC 9309として標準化されました。
名前は「Robots Exclusion Protocol」です。

そのRFCの本文に、こうあります。

These rules are not a form of access authorization.

これらのルールは、アクセス認可の一形態ではない。

巡回を除外するための取り決めであって、アクセスを禁止する仕組みではない、ということです。

書いた行が、そのまま案内板になる

RFC 9309には、セキュリティに関する節があります。
そこに書かれているのが、今回いちばん大事な一文です。

The Robots Exclusion Protocol is not a substitute for valid content security measures. Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable.

この取り決めは、まっとうなコンテンツのセキュリティ対策の代わりにはならない。
robots.txtにパスを列挙することは、それらを公に露出させ、その結果、発見可能にする。

露出させ、発見可能にする。
隠すために書いた行が、そのまま案内板になります。

理由は単純で、robots.txtは誰でも開けるからです。
サイトのアドレスのうしろに robots.txt と付ければ、ブラウザで読めます。
検索エンジンに読ませるためのファイルなので、当然そうなっています。

そこに「このフォルダは見ないでください」と書けば、そのフォルダの名前を教えたことになります。

続けて、どうすべきかも書かれています。

To control access to the URI paths in a robots.txt file, users of the protocol should employ a valid security measure relevant to the application layer on which the robots.txt file is served -- for example, in the case of HTTP, HTTP Authentication as defined in [RFC9110].

アクセスを制御したいのなら、その層に応じたまっとうなセキュリティ対策を使うこと。
HTTPであれば、認証を使うこと。

見せたくないものには鍵をかけろ、という話です。

止めたはずのURLが、検索結果に出ることがある

検索エンジンの側も、同じ説明をしています。

Googleの検索セントラルにある、robots.txtの解説ページの冒頭です。

robots.txt ファイルとは、検索エンジンのクローラーに対して、サイトのどの URL にアクセスしてよいかを伝えるものです。これは主に、サイトでのリクエストのオーバーロードを避けるために使用するもので、Google にウェブページが表示されないようにするためのメカニズムではありません。Google にウェブページが表示されないようにするには、noindex を使用してインデックス登録をブロックするか、パスワードでページを保護します。

主な用途は、サイトに負荷をかけすぎないようにすること。
本来の目的が、そもそも隠すことではありません。

他のサイトからリンクされていれば、出る

同じページに、もっと具体的な注意が書かれています。

Google では、robots.txt ファイルでブロックされているコンテンツをクロールしたりインデックスに登録したりすることはありませんが、ブロック対象の URL がウェブ上の他の場所からリンクされている場合、その URL を検出してインデックスに登録する可能性はあります。そのため、該当の URL アドレスや、場合によってはその他の公開情報（該当ページへのリンクのアンカーテキストなど）が、Google 検索結果に表示されることもあります。

robots.txtで止めたページでも、どこかからリンクされていれば、URLが検索結果に出ることがあります。
リンクのアンカーテキストまで一緒に出る場合がある、とも書かれています。

「robots.txtに書いたから検索に出ない」は、Google自身が否定しています。

従うかどうかは、クローラー次第である

もう1つ、前提があります。

サイトに対するクローラーの動作に対して、robots.txt ファイルの指示を強制適用することはできません。指示に従うかどうかはクローラー次第です。

強制ではありません。
Googlebotのような信頼できる巡回プログラムは従いますが、すべてがそうとは限りません。

3つの選択肢には、順番がある

出てきた選択肢を整理します。

1つ目、パスワードで保護する。
いちばん確実です。
URLを知られても、認証を通らなければ中身は見えません。
RFCが挙げているのも、この方法です。

2つ目、noindexでインデックス登録を止める。
検索結果には出なくなりますが、URLを直接入力すれば誰でも見られます。
人に見せたくないものには足りません。

3つ目、ページを完全に削除する。
Googleが「確実に防ぐには」として挙げている3つのうちの1つです。

この3つには順番があります。
本当に見せたくないものは1つ目です。
2つ目は、見られてもよいが検索には出したくない、という場合のものです。

いますぐできることを1つ書いておきます。
自社サイトのアドレスのうしろに、スラッシュと robots.txt を付けて開いてみてください。
管理画面のパス、テスト環境の名前、取引先ごとのフォルダ名が並んでいないでしょうか。

書いた本人は、隠すつもりで書いています。

送信取り消しは、社外には効かない

3つ目の操作です。

宛先を間違えて送ってしまった。
添付ファイルが違った。
気づいた瞬間に、送信取り消しを押す。

このボタンで、本当に戻るのでしょうか。

条件は3つある

Microsoftのサポート記事は、使える場面をこう書いています。

新しい、従来の Outlook for Windows または Outlook on the web から、自分と受信者が同じ組織内に Microsoft 365 の職場または学校のメールアカウントを持っており、受信者がまだメッセージを開いていない場合のみ、organization からメールを取り消すことができます。

条件が3つ並んでいます。

1つ目、自分と相手が同じ組織内であること。
2つ目、どちらも職場または学校のアカウントであること。
3つ目、相手がまだ開いていないこと。

使えない場合も明記されています。

個人用メールアカウント (Gmail、Hotmail、Outlook.com) では、メッセージの取り消しを使用できません。

ここから分かることは、はっきりしています。
社外に送ったメールは、取り消せません。
取引先の担当者は、同じ組織内にいないからです。

仕組みを考えると、当然の話です。
取り消しは、相手のメールボックスにある未読のメッセージを、こちら側から取り下げる操作です。
同じ組織のサーバーの中にあるから、手が届きます。

社外に送ったメールは、その時点で相手の会社のサーバーに渡っています。
そこに手を入れる権限は、こちらにありません。

郵便でいえば、社内便で回した封筒を途中で抜くのと、投函した封筒を回収するのとの違いです。

「取り消しました」ではなく、レポートを見る

社内であっても、3つ目の条件が残ります。
相手がすでに開いていたら、戻りません。

そして、成否は押した時点では分かりません。
同じサポート記事に、こうあります。

その後すぐに、受信トレイにメッセージ取り消しレポートが届きます。そのメッセージ内のリンクを選択して、取り消しが成功したか、保留中であるか、失敗したかを確認します。

成功したか、保留中か、失敗したか。
3つの結果があります。

この連載で扱ってきた他の操作と、同じ構造です。
押した本人の画面には、取り消しの操作をした、という結果が出ます。
相手のメールボックスから実際に消えたかどうかは、レポートを開くまで分かりません。

Gmailの取り消しは、最長30秒である

もう一方の仕組みも見ておきます。

Gmailのヘルプには、設定の手順としてこう書かれています。

[送信取り消し] の横で、送信を取り消せる時間（送信からの経過時間）を 5、10、20、30 秒から選択します。

選べるのは4つで、いちばん長くて30秒です。
既定のままだと、もっと短い設定になっていることがあります。
まず、この設定を30秒にしておくことをお勧めします。
設定画面で選ぶだけです。

ただし、30秒です。
送信を押して、画面を見て、間違いに気づいて、取り消しを押す。
ここまでを30秒で終える必要があります。

添付ファイルの中身が違っていた、という種類の間違いは、たいてい30秒では気づけません。
相手からの指摘で気づきます。

取り消せない前提で、押す前に何を置くか

ここまでを踏まえると、取り消し機能は最後の砦にはなりません。
そこで、押す前の側に仕掛けを作ることになります。

1つ目、送信を数分遅らせる設定にしておく。
多くのメールソフトに、送信を一定時間保留する設定があります。
30秒より、こちらのほうが現実的な猶予になります。

2つ目、社外宛てのときだけ確認画面を出す。
宛先に社外のアドレスが含まれているときに、もう一度たずねる仕組みです。

3つ目、添付をやめて、権限を切れる形で渡す。
リンクで渡せば、送ったあとでも権限を切れます。
ただし渡し方には条件があります。
「リンクを知っている全員」で渡していれば、切るまでは誰でも開けますし、そのリンクは転送できます。
共有リンクの種類ごとの違いは、記事末にリンクを置いた別の記事にまとめてあります。

4つ目、誤送信が起きたときの手順を決めておく。
戻せないのですから、次にやることは相手への連絡です。
誰が、いつまでに、何を伝えるのか。
個人データが含まれていれば、報告の義務がかかる可能性もあります。

慌てている本人に判断させないために、紙1枚にしておくものです。

念のため書いておくと、取り消し機能が無意味だという話ではありません。
社内で、宛先を1文字間違えた。
すぐ気づいた。
この場合には効きます。

条件が揃ったときにだけ効く補助であって、これがあるから安心、という位置づけのものではありません。

削除しても、ごみ箱は2段ある

最後は、消したのに残っている話です。
ここまでの3つと違い、残っていることが助かる場合もあります。

Microsoftのドキュメントに、SharePointでファイルを削除したあとの流れが書かれています。

ブラウザー内で SharePoint アプリケーションを使用すると、ユーザーがアイテムを削除した場合、そのアイテムを元の場所から削除したときから 93 日間、サイトのごみ箱にアイテムが保持されます。

93日です。
そして、その先があります。

サイトのごみ箱はサイトコレクションのごみ箱 (第 2 段階のごみ箱とも呼ばれます) に移動し、残りの保持期間はサイトコレクションのごみ箱にとどまります。サイトコレクションのごみ箱から削除されたアイテムは、すぐに削除されます。

93日は、2段の合計である

ここは読み違えやすいところです。

ごみ箱を空にしても終わりではなく、もう1段あります。
ただし、そこで日数が足されるわけではありません。

原文は「残りの保持期間はサイトコレクションのごみ箱にとどまります」です。
1段目と2段目を合わせて93日、という構造です。
93日のうち10日目に空にすれば、2段目にいられるのは残りの83日です。

この2段目は、多くの場合、一般の利用者からは見えません。
管理者の画面から開くものです。

だから、利用者が「ごみ箱も空にしたので消えました」と報告してきても、まだ残っていることがあります。
逆にいえば、戻せる可能性がまだあります。

サイトごと消した場合も同じです。

削除されたサイトコレクションは 93 日間保持されます。 93 日を過ぎると、リスト、ライブラリ、ページ、サブサイトなど、サイトおよびサイトのすべてのコンテンツと設定が完全に削除されます。

そのあとに、14日ある

その先にも、もう1段あります。

SharePoint では、お客様がサイトコレクション全体を復元しやすくするために、実際の削除から 14 日間、すべてのコンテンツのバックアップが保持されます。

そして、その終わりもはっきり書かれています。

この 14 日間が経過すると、Microsoft はデータを保持しなくなり、回復できなくなります。

誤って消したファイルが戻せるのは、この仕組みがあるからです。
そして同時に、期限も決まっています。

あとで戻せばいい、と思っているうちに期限が来ます。
クラウドの標準機能で戻せる日数は、サービスごとに違います。
そこは、バックアップの記事にまとめてあります。

プログラムから消すと、ごみ箱に入らない

同じドキュメントに、見落とされやすい記述があります。

アイテムをリサイクルすると、この記事で前述したブラウザーアプリケーションの動作と同様に、ごみ箱に追加されます。ただし、削除すると、アイテムは直ちに消去され、サイトまたはサイトコレクションのごみ箱からは回復できません。

画面から消したときと、プログラムから消したときで、結果が違います。

正確にいうと、プログラム側には2つの操作があります。
リサイクルすればごみ箱に入り、削除すれば直ちに消えます。
どちらを呼んでいるかは、使っているツールの作り次第です。

一括整理のためにツールやスクリプトを入れる場面は、これから増えます。
古いファイルをまとめて片づける自動化を入れるとき、それがどちらを呼んでいるかを確かめておく必要があります。

93日の猶予があるつもりで動かして、実際には即時に消えている。
これは、気づいたときには終わっている種類の事故です。

サーバーを消しても、ディスクは残る

もう1つ、別の種類の「残る」を挙げておきます。

クラウド上の仮想サーバーを削除したのに、請求が続く。
この現象について、AWSのドキュメントにはこう書かれています。

インスタンスの終了時に削除されなかったボリュームは、引き続き料金が発生します。

仮想サーバーと、そこに接続していたディスクは、別のものです。
サーバーを終了したときにディスクも消えるかどうかは、設定によって変わります。

同じページに、既定の動作が整理されています。

ルートのディスクは、起動時に付けたものなら終了時に削除され、起動後に付けたものなら保持されます。
データ用のディスクは、画面から起動時に付けたなら保持、コマンドから起動時に付けたなら削除、起動後に付けたならどちらでも保持です。
インスタンスストアと呼ばれる種類だけは、終了すると必ず全部消えます。

覚えようとすると間違えます。
実務上の答えは1つです。
サーバーを消したあとに、ディスクの一覧を開いて、どこにも付いていないものが残っていないかを見る。

そこには、消したつもりのデータも入っています。
費用の問題であると同時に、情報の問題です。

2026年9月時点の最新状況

この記事で引いた資料は、更新の時点がばらばらです。
一次資料にあたるときは、ページごとの日付を見る必要があります。

引用元の更新時点

Adobeの墨消しの2ページは、どちらも最終更新日が2025年11月5日です。

Microsoftの「Microsoft 365 での SharePoint データの削除」は、ページのメタデータ上の日付が2026年8月28日です。
この記事の引用のうち、93日と14日、それにプログラムからの削除の記述は、すべてこのページのものです。

Googleの「robots.txt の概要」は、最終更新日が2025年12月18日（UTC）と表示されています。

RFC 9309は2022年9月の発行で、その後の更新はありません。
これがいちばん古い資料ですが、標準化された文書なので、日付の古さは内容の古さを意味しません。

robots.txtの仕様書は、置き場所が変わっている

1つ、確認しておいたほうがよい変化があります。

Googleの「robots.txt の指定の解釈」は、検索セントラルの配下（/search/docs/crawling-indexing/robots/robots_txt）にありましたが、現在はクロール関連のドキュメント（/crawling/docs/robots-txt/robots-txt-spec）へ移っています。
古いURLからは転送されますが、社内の手順書に旧URLを書いている場合は、書き換えておくほうが安全です。

概要ページのほうは、検索セントラルの元の場所のままです。

標準になったのは2022年だが、仕組みは1994年のものである

RFC 9309の冒頭に、こう書かれています。

This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994

1994年に定義された方法を、2022年に文書化したものだ、ということです。
28年のあいだ、事実上の取り決めとして使われてきました。

「隠す道具ではない」という性質は、最初からそうだったのであって、後から変わったわけではありません。

誤送信の側は、制度が動いている

メールの誤送信で個人データが外に出た場合、報告の義務がかかることがあります。
この部分は2026年に法改正があり、本人への通知の要件が変わる予定です。
報告そのものの枠組みは変わっていません。

制度の側の詳細は、記事末にリンクを置いた記事にまとめてあります。

消す操作を上手にするより、置かないほうが早い

4つを並べると、同じ形が見えます。

黒い四角を重ねても、文字は残る。
robots.txtに書いても、隠れない。むしろ公開される。
送信取り消しは、社外には効かない。
削除しても、ごみ箱の2段目とバックアップに残る。

どれも、操作した本人の画面ではうまくいったように見えます。
だから、確認のしようがありません。
確認するには、その仕組みがどう作られているかを知っている必要があります。

そして、ここから導かれる結論は、たぶん1つです。
消す操作を上手にするより、そもそも置かないほうが早い。

社外に出す資料は、隠す部分を含んだまま作って後から塗るのではなく、最初から含まない版を作る。
見せたくないページは、検索に出さない設定をするのではなく、認証の内側に置く。
メールに添付するのではなく、権限を切れる形で渡す。

どれも、消す作業そのものが要らなくなる方向の対策です。

社内で1つだけ決めるなら、社外に出すファイルは新しいファイルに作り直す、という決めごとだと思います。
元のファイルに手を入れて出す限り、隠したものは付いてきます。

誤送信が起きたときに誰がいつまでに何を伝えるかを紙1枚にするなら、書式があります。
初動72時間フローシートと報告書式を含む6種です。

まとめ

PDFに黒い四角を重ねても、下のテキストは残る。Adobeはこれを「非表示テキスト」と呼び、墨消しの対象になり得るデータ14種類の1つに数えている
墨消しは覆うのではなく置き換える操作で、適用して保存すると元に戻せない。戻せる状態なら、それは消えていない
墨消しで消えるのは表示されているテキストとグラフィックだけ。メタデータや添付は「別々に削除する必要があります」と書かれている
WordとExcelのドキュメント検査は、白地に白い文字と、他のオブジェクトに覆われているオブジェクトを検出しない。Microsoftが注記として自分で書いている
Excelの非表示のワークシートは、中身が分からないなら再表示して目で見る、というのがMicrosoftの手順
robots.txtはアクセス認可の一形態ではない。RFC 9309は、パスを列挙することが「公に露出させ、発見可能にする」と明記している
robots.txtでブロックしたURLでも、他のサイトからリンクされていれば検索結果に出ることがある。確実に防ぐならパスワード保護、noindex、または削除
Outlookの取り消しは、同じ組織内・職場または学校のアカウント・相手が未読、の3つが揃ったときだけ。個人用アカウントでは使えない。成否は取り消しレポートで確認する
Gmailの取り消しは最長30秒。設定で選べるのは5・10・20・30秒の4つ
SharePointの93日は、サイトのごみ箱とサイトコレクションのごみ箱の合計。そのあとに14日のバックアップがあり、そこを過ぎると回復できない
プログラムから削除した場合は、ごみ箱に入らず直ちに消えることがある
仮想サーバーを終了しても、削除されなかったディスクには料金が発生し続ける。データも残っている

4つに共通していたのは、操作した本人の画面では成功して見える、という点でした。
見た目で確かめられないものは、仕様を読むしかありません。

皆さんの会社で、消したつもりになっているものは、どこにあるでしょうか。

参考・引用元

Adobe

Adobe「墨消し可能なデータの種類」（最終更新日2025年11月5日） https://helpx.adobe.com/jp/acrobat/desktop/protect-documents/redact-pdfs/redactable-data.html
Adobe「Acrobat Pro で PDF の墨消しと非表示情報の削除を行う」（最終更新日2025年11月5日） https://helpx.adobe.com/jp/acrobat/desktop/protect-documents/redact-pdfs/redacting-sanitizing.html

Microsoft

Microsoft「ドキュメントを検査して非表示のデータや個人情報を削除する」 https://support.microsoft.com/ja-jp/office/collab-files/remove-hidden-data-and-personal-information-by-inspecting-documents-presentations-or-workbooks
Microsoft「Outlook でメールを取り消す方法: 要件、制限事項、＆手順」 https://support.microsoft.com/ja-jp/outlook/mail/how-to-recall-an-email-in-outlook-requirements-limitations-steps
Microsoft「Microsoft 365 での SharePoint データの削除」（2026年8月28日） https://learn.microsoft.com/ja-jp/sharepoint/sharepoint-data-deletion

IETF・Google

IETF「RFC 9309 Robots Exclusion Protocol」（2022年9月） https://www.rfc-editor.org/rfc/rfc9309.txt
Google「robots.txt の概要」（最終更新日2025年12月18日 UTC） https://developers.google.com/search/docs/crawling-indexing/robots/intro?hl=ja
Google「Google による robots.txt の指定の解釈」 https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=ja
Google「メールの送信または送信取り消し」（Gmail ヘルプ） https://support.google.com/mail/answer/2819488?hl=ja

Amazon Web Services

AWS「インスタンスの終了方法」（Amazon EC2 ユーザーガイド） https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/how-ec2-instance-termination-works.html

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40