注目度の高い文書流出がバズるたびに、同じPDF論争がタイムラインに流れてきます。
今回も “Epstein files” のPDFで、黒塗り部分を拡大しながら「これは本当にレダクションされているのか、それとも上に黒い矩形を重ねただけか」が話題になっていました。
個別の事件をここで蒸し返すつもりはありません。ですが、この議論には価値があります。多くのチームが認めたがらない、よくあるミスをはっきり示してくれるからです。
黒いバーは“見た目を隠す”だけのことが多い。レダクションは“データを消す”こと。
この2つは別物です。
「黒く見える」だけでは危ない理由
PDFは必ずしも「ページ画像」ではありません。むしろコンテナです。1ファイルの中に、次のような要素を持てます。
- 見えているページ
- 選択可能なテキスト
- 非表示のOCRテキスト（見えないが検索できる）
- 注釈（ハイライト、図形、コメント）
- メタデータ（author/title/subject など）
つまり、画面上では隠せていても、下層テキストやOCR、残留オブジェクトをそのまま送ってしまうことがあります。これが 無効なレダクション です。高度な攻撃ではなく、「覆う」と「削除する」を取り違えたワークフローの問題です。
もし手順が「Word/PowerPointで黒い矩形を描いてPDFに書き出す」なら、かなり危険です。問題ないこともありますが、問題が出ることもあります。送る直前の 最終ファイルそのもの を確認しない限り、判断できません。
私が送信前にやる“60〜90秒チェック”
これは厳密なコンプラ運用ではありません。単純ミスを拾うための、短い実務チェックです。
確認対象は 最終書き出しファイル のみ（実際に送信・共有するもの）です。
- 機微語句を 検索（氏名、ID、メール断片、住所）
- 黒塗り周辺を選択して コピー/貼り付け し、プレーンテキストで確認
- 2種類の閲覧環境 で開く（デスクトップアプリ + ブラウザで十分なことが多い）
- 残った 注釈/コメント を確認（ハイライト、ノート、図形）
- 外部送付なら メタデータ（作成者/タイトル/件名）も確認
文書がスキャン起点だったりOCRを通している場合は、特に注意します。非表示なのに検索できるテキストは、見落としやすい隠れレイヤーだからです。
以上です。シンプルで再現可能、しかも効果があります。
事故を減らすためのワークフロー
機微情報を含む文書では、リリース手順をできるだけ単純に保ちます。
- 本物のレダクションを行う（重ねるのではなくコンテンツを削除）
- 余計なレイヤーを掃除する（注釈、添付ファイル、隠しレイヤー、メタデータ）
- 最終書き出しを検証する（上のチェックリスト）
- 送付用バージョンを作る（多くはスキャン風で、見た目を最終化）
最後の工程は思っている以上に重要です。見せかけの安全対策のためではなく、端末差による崩れや偶発的なノイズを減らすためです。
私の中でのLook Scannedの役割
Look Scannedはレダクションツールとして使っていません。役割が違います。
私にとっては 最終仕上げの出力ツール です。
文書を正しくレダクションし、最終ファイルを検証したあとに、Look Scannedでクリーンな スキャン風PDF を作ります。提出書類やフォーマルなやり取りで期待される、あの仕上がりです。
実務上のメリットは次の通りです。
- 「私の環境だとレイアウトが崩れる」という往復が減る
- 「最終成果物らしさ」が出る（特にスキャン見た目が求められる場合）
- 余計なマークアップ層の混入リスクを下げやすい（書き出し手順次第）
順序が重要です。削除 → 検証 → 仕上げ。
短い結論
“Epstein files”のPDF論争がまた教えてくれたのは、これです。
黒塗りは証拠にならない。
レダクションはデータ操作として行い、公開する“そのファイル”を検証し、その後でスキャン風の最終見た目を整えるべきです。
Look Scannedを試す: https://lookscanned.io