個人情報を検出するツールの多くは、テキストを入力として受け取ります。紙をスキャンしたPDFなら、先にページを文字に変える作業が必要ですが、それが誰の担当なのかをはっきり説明しているツールは多くありません。こうしたツールは開発者のために作られていて、書類を手にしている人は、もともと想定された利用者ではないからです。
最初の関数を呼ぶ前の作業
よく知られた検出ツールの最初の関数は、文字列を受け取って、「40文字目から51文字目が氏名」という位置を返します。その用途には適切な設計です。
ただし、誰かがすでにページを文字に変えていることが前提です。データが最初からテキストなら、この作業はありません。スキャンしたPDFなら、この作業が問題のほとんどを占め、それが利用者に任されています。
インストール手順を見ると、想定された利用者がわかる
Presidioは、オープンソースの定番の選択肢です。Microsoftで作られ、現在はコミュニティが運営していて、画像用の黒塗りモジュールもよく動きます。使うには、Pythonのパッケージ（pip install presidio-image-redactor）を入れ、文字認識エンジンのTesseractを別にインストールします。ドキュメントには、Tesseract 5.2.0で動作を確認したと書かれています。
PyPIの公開統計（pypistats.org）を見ると、この画像用モジュールは2026年10月下旬の1週間に約1万回ダウンロードされていました。ただ、Pythonの開発環境に入れて使うものなので、ダウンロードしているのは開発者です。スキャンした書類を毎日扱う事務所の担当者が、自分で入れるものではありません。
医療画像向けの機能には、画素を黒塗りしても、ファイルのメタデータに個人情報が残る場合があるという注意書きがあります。開発者にとっては役に立つ情報です。ただ、スキャンした雇用契約書を40件抱えた人事の担当者から見ると、このツールが誰のために書かれたかがよくわかります。
クラウドのサービスにも、同じ組み立てのものがあります。文字の読み取りと個人情報の検出が別々のサービスになっていて、その二つをつなぐ部分は利用者に任されています。間違いが起きやすいのは、まさにそのつなぎ目です。
Acrobatでも、難しい部分は利用者の仕事
実際に試す人の多くは、Adobe Acrobatを使います。スキャンしたPDFに文字認識をかけてから、検索して墨消しをします。コントラストの低いFAXの文字は、読み取られないことがあります。文字がつながって読み取られた氏名は、検索で見つかりません。こうした読み取りの誤りはエラーとして表示されないことが多いため、確認するのは利用者自身です。
日本語のスキャンで起きること
日本語では、ページを文字に変える作業がさらに難しくなります。文字認識エンジンのTesseractは、日本語の行を空白で区切った「単語」に分けて返すことが多く、「神奈川県横浜市」が「神奈 川 県 横浜 市」のように読み取られます。住所や氏名を探すパターンは、この空白があると一致しません。
日本の職場では、押印して再スキャンした契約書、FAXで届いた申込書、本人確認のために受け取った運転免許証のコピーなど、スキャンした書類が日常的に行き来しています。文字が空白で分かれて読み取られても、どこにも警告は出ません。
promptShieldは、同じ行で隣り合う日本語の文字の間に入った空白を、文字の間隔を確かめたうえでつなぎ直し、それから検出を行います。
当社も同じ前提を置いていた
外から指摘するだけの立場で書ければよかったのですが、当社も同じ前提を3か所で置いていました。気づいたのは、結果を測ったからです。
1つ目は、ページを画像として読むのを、画像が大きい場合に限っていたことです。レターヘッドの帯に入った会社名はページの0.5%ほどの面積しかなく、読み飛ばされていました。大事なのは画像の大きさではなく、画像の上に文字のデータが重なっているかどうかです。文字のデータがなければ、大きさに関係なく、抽出処理には画像の中身が見えません。
2つ目は、埋め込み画像を調べる処理が、当社のPDFライブラリにないメソッドを呼んでいたことです。エラーはデバッグ用のログに埋もれていました。そのバージョンを使っていた間は、面積の65%が画像のページも含め、すべてのページで「画像なし」と判定していました。
3つ目は、スキャンしたレターヘッドの上に、利用者が手で枠を描いたときの問題です。編集画面は文字のデータだけを読んだため、枠の中に文字が見つからず、何も取り込みませんでした。3つとも、この分野のほかの製品と同じ前提から来ています。テキストだけを使い、画像はほかの誰かの問題として扱っていました。
気づかれない見落としの負担は誰にかかるか
処理がエラーで止まるなら、失うのは作業時間だけです。氏名が並ぶページに「個人情報は見つかりませんでした」と表示された場合は、一見すると何の問題もありません。そのリスクを負うのは、結果を確かめる手段を持たない人です。
スキャンした書類を手元に置いているのは、銀行のシステム部門ではないことがほとんどです。少人数の法律事務所や税理士事務所、問診票をスキャンする診療所です。スキャンには機微な内容が多いのに、それを持つ人ほど、連携の仕組みを自分で組むことができません。処理の組み方を誤った開発者は不具合として報告できます。しかし、本人確認書類のコピーを黒塗りされないまま送られた本人には、取り返す手段がありません。
書類を持つ人のために作ると、何が変わるか
まず入力が変わります。ツールは、画像を含めたページをそのまま受け取ります。文字認識は処理の中に入り、ページを300dpiで描画して、文書の言語と英語でTesseractにかけます。手で描いた枠に文字が見つからない場合は、そのページを文字認識で読み直します。
検出した氏名は、その部分の画素を長方形で塗りつぶします。コードに置き換えた部分には、あとで元に戻せるよう、コードを見えない文字として書き込みます。詳しくはスキャンしたPDFと画像の黒塗りで説明しています。文字認識にはPresidioと同じTesseractを使っていますが、ターミナルを開くことのない人でも使えるように組み立てています。Presidioとの比較は検出エンジンを自社開発した理由にまとめました。
処理はすべて、文書がすでにあるデバイスの中で行い、文書をどこにも送りません。運転免許証のコピーのような書類では、この点が特に重要です。どの検出も完全ではないため、ダウンロードの前に結果を確認する手順を設けています。お使いのツールで「個人情報なし」と表示されたスキャンがあれば、それで試してみてください。
よくある質問
黒塗りツールが画像の中の文字を見落とすのはなぜですか？
多くのツールは画像を見ていないからです。入口がテキストを受け取る形なので、スキャンしたページは検索できる文字がないまま渡され、何も見つからないまま、警告もなく返ってきます。
Presidioの画像用モジュールを使えば解決しますか？
画像用モジュールはそのための機能で、よく動きます。ただ、文字認識エンジンを自分でインストールする前提のPythonパッケージなので、スキャンを手にしている人の多くには扱えません。
スキャンの処理をデバイスの中で行うことが、特に大切なのはなぜですか？
スキャンには、本人確認書類、問診票、署名済みの契約書が多いからです。個人情報を取り除くために外部のサービスへ送れば、取り除く前の内容をまず送ることになります。