黒塗りしたはずのPDFから、文字はそのまま取り出せる — 中小企業 × AI 経営(2026年8月)
自社のPDFツールに墨消し機能を作った際、黒い四角を重ねるだけの一般的な方式では下の文字がそのまま抽出できることを実測で証明しました。画像化方式のみを採用し、送信ゼロで完結させた実録です。
はじめに:この記事の前提
Koinobori 代表取締役の杉﨑です。 社員数名の会社を経営しながら、このコーポレートサイトも自分の手で作り、AI を相棒に毎日更新しています。
私たちは自社サイトとは別に、誰でも無料で使えるブラウザ完結型のツール集を運営しています。今回はそこに、書類の黒塗り(墨消し)を含む PDF ツールを6本追加しました。作業の中心は機能追加そのものよりも、「黒塗りは、本当に文字を消せているのか」を自分たちで実測して確かめることでした。結果、世の中に出回っている墨消しのやり方の多くが、実は文字をそのまま残してしまうことが分かりました。行政や企業の黒塗り文書が、実は下の文字を読めてしまったという事故が繰り返し報じられていますが、同じ構造の落とし穴が、自分たちの実装にもあっさり再現できたという話です。
契約書・見積書・議事録など、中小企業でも「一部だけ隠して共有したい」場面は意外と多いと思います。もし今この記事を読んで「うちも似たようなやり方で黒塗りしている」と思い当たる方がいたら、後半の実測結果はぜひ確認していただきたい内容です。
1. 課題:「どこまで機能を足せるか」の前に、「足してはいけない機能」を切り分ける
1-1. 背景:ブラウザ完結を看板にしたツール集
このツール集の一番の特徴は、ファイルを一切サーバーへ送信せず、利用者の手元のブラウザの中だけで処理を完結させることです。書類を扱うツールほど、「アップロードしない」という約束は価値を持ちます。逆に言えば、この約束を破る機能は、たとえ技術的に作れても採用しないという制約を、自分たちに課しています。
今回は「海外の大手 PDF ツールサービスに近づけるにはどこまで機能を追加できるか、まず可否一覧から整理したい」という発想から始まりました。ただ真似るのではなく、“作れるもの”と”作ってはいけないもの”をまず分けることを優先しました。
1-2. 33機能を4つに仕分ける
参考にした大手サービスの機能を1つずつ洗い出し、「ブラウザの中だけで完結できるか」という一つの物差しだけで分類しました。
| 分類 | 内容 | 該当機能の例 |
|---|---|---|
| そのまま作れる | 追加の仕組み無しで実装可能 | 結合・分割・ページ削除・回転・トリミング・ページ番号・透かし・フォーム入力・画像からPDF化 |
| 部品を足せば作れる(今回実装) | 描画用の追加部品を組み込めば可能 | 画像化・文字起こし・ページ整理・見比べ・墨消し |
| 一部だけ作れる | 制約付きで実現可能 | 圧縮(画像の再圧縮は不可)・日本語入り透かし(書体データの同梱が必要) |
| 作らない | ブラウザ内で完結しない、または方針と矛盾する | 文書形式の変換・保存規格変換・破損修復・暗号化(内部で使う部品が非対応と実測済み)・電子署名・AI要約や自動翻訳 |
一番下の「作らない」に AI 要約・自動翻訳を入れたのは意図的です。便利さで言えば欲しい機能ですが、実現するには文書の中身を外部のサーバーへ送る必要があります。 それは「送信ゼロ」という私たちの一番の約束と真っ向から矛盾します。「技術的にできない」のではなく、**「できるけれど、やらないと決めた」**という整理です。この線引きができたことが、企画段階でのいちばんの収穫でした。大手サービスにできて自分たちにできないことが、そのまま信頼の証明になるとも言えます。
2. 取り組み:核心は「墨消し」——実測がすべてを決めた
2-1. 一般的な墨消しの正体
「部品を足せば作れる」に分類した5機能のうち、最も重要なのが墨消しでした。世の中の多くのツールでの墨消しは、文書の見た目の上に黒い四角形を重ねて描くだけという作り方です。画面で見る限り、隠したい部分は真っ黒に塗りつぶされていて、何の問題もないように見えます。
けれど、「見た目が黒い」ことと「文字データが消えている」ことは、まったく別の話です。PDF の内部には、見た目とは別に「文字そのもののデータ」が保持されています。黒い四角は、その文字データの”上”に置かれた飾りに過ぎません。
2-2. 実測でわかったこと
代表からの「墨消しはどこまでできるか、実際に検証してほしい」という指示を受け、テスト用の文書を使って両方式を比較しました。
| 方式 | 見た目 | 黒塗り後に文字を抽出すると |
|---|---|---|
| 黒い四角を重ねるだけ(多くのツールの方式) | 真っ黒で隠れているように見える | 隠したはずの文字列が、そのままコピー・検索できる |
| ページを画像に変換してから塗る(採用した方式) | 同じく真っ黒 | 文字データそのものが存在せず、何も抽出できない |
見た目はどちらもまったく同じです。違いは、文字のデータが「隠れているだけ」なのか「そもそも無くなっている」のかという、利用者からは見えない部分にありました。見た目だけを確認しても、この違いには絶対に気づけません。 実際に文字を抽出する操作をして初めて、隠れているつもりの情報が丸見えだと分かる構造です。
2-3. 代償も測る:ファイルサイズと検索性
画像化する方式には代償もあります。実測したところ、該当ページのファイルサイズが約6倍に膨らみ、そのページに限っては文字の選択や文書内検索ができなくなることが分かりました。文字として扱えるデータそのものを消してしまうので、当然の結果です。
この代償をそのまま受け入れるのではなく、設計を工夫しました。墨消しを指定したページだけを画像化し、それ以外のページは元の文字データをそのまま残す。 こうすることで、安全性が必要な箇所だけ確実に守りつつ、文書全体の使い勝手はできるだけ損なわない形にできました。この動きは実際にテスト文書で検証し、想定どおりに機能することを確認しています。
2-4. 「見た目だけの墨消し」は、理由があっても作らない
この検証結果を受けて、**「黒い四角を重ねるだけの、見た目だけの墨消しは、いかなる理由があっても実装しない」**という方針を、コードの説明文にもはっきり書き残しました。将来、誰かが「処理を軽くしたいから」「開発を急いでいるから」といった理由でこの方式に戻さないようにするための、明文化した歯止めです。
情報漏洩事故の多くは、“それらしく見える対策”が実際には機能していなかったという構造で起きます。今回の検証は、その典型的な失敗を自分たちの手で再現し、事前に潰せたという意味で価値がありました。
2-5. 技術判断は推測せず、実測で決めた
墨消し以外にも、開発の途中でいくつかの判断がありました。いずれも「たぶんこうだろう」で決めず、実際に動かして確かめることを徹底しました。
- 正しく動いているかを、人の目視だけに頼らない仕組みにした — ブラウザの中でしか動かない処理を、機械的に自動検証できる形に設計し直し、45件のテストがすべて正しく通ることを確認しました。目視確認だけでは見落としが出ます。
- 「必要だろう」と思っていた追加データを、検証の上で見送った — 日本語の PDF を正しく扱うには、2.4MB ほどの追加データが必要だと当初は考えていました。しかし実際の日本語文書で試したところ、追加データの有無で結果に差が出ないと確認できたため、同梱を見送りました。余計な重さを乗せずに済みました。
- ページを開くだけで、使わない機能の部品まで読み込んでいたことが発覚 — 詳しく計測すると、訪問者がまだ何もしていない段階で、330KB 分の処理部品を毎回読み込んでいたことが判明しました。使う機能の部品だけをその都度読み込む形に設計し直し、最初の読み込み量を330KBから2〜3KBまで削減(99%減)しました。
2-6. AI 3体を並行させた副作用と、最後にやったこと
今回の開発は、AI 3体に作業を分担させて並行で進めました。速く仕上がる一方で、必ずと言っていいほど3種類のズレが出ることも分かりました。
| 起きたこと | 内容 | どう解消したか |
|---|---|---|
| 報告の食い違い | 「後から読み込む設計」「先に全部読み込む設計」と、正反対の報告が上がった | 自分で実測し、どちらが正しいかを直接確認した結果、330KBの読み込み問題を発見できた |
| 確認の積み残し | 「墨消しの実行結果までは確認できていない、実機での確認を推奨」という報告があった | 自分で実際に生成したファイルを作り直し、文字が本当に抽出できないことを再確認した |
| 状況の見誤り | 3体とも「描画が止まる、環境のせいかもしれない」と報告した | 調べると、画面を見ていない間はブラウザが描画を止めるという、ごく普通の仕様が原因で、不具合ではなかった |
教訓は、並行作業は速さと引き換えに、必ず最後の実測確認を一人でやり直す工程が要るということです。速さだけを取って確認を省くと、今回のような食い違いや見落としがそのまま製品に残ります。ツールの登録作業(どのツールをどこに表示するかという最終的な組み込み)だけは、あえて一人で最後にまとめて行い、複数のAIが同時に同じ場所を編集してぶつかる事故を防ぎました。
3. 結果:6本のツールを、送信ゼロのまま届ける
墨消しを含む5つの機能を実装し、PDF ツール6本を独立したカテゴリとして公開しました。結合・分割はもともと部品無しで作れていたので、これで結合分割・墨消し・画像化・文字起こし・ページ整理・見比べの6本がそろい、ツール集全体は173種に達しています。
公開前には、「ファイルが一切外部へ送信されないか」を機械的に検査する仕組みを通し、問題がないことを確認しました。ページを開いた瞬間に読み込む量は2〜3KB まで削減済みで、自動検証45件はすべて通過しています。本番へ反映する際も、削除されたファイルがすべて開発用の中間生成物だけであること(本文のページなどが誤って消えていないこと)を事前に確認してから公開しました。
派手な機能というより、「約束を守れているか」を地味に測り続けた結果の6本です。
4. 学び:セキュリティ機能は「それらしい見た目」が一番危ない
今回の一番の学びは、これに尽きます。
セキュリティ機能は、見た目が”それらしい”ことが、いちばん危ない。
黒い四角を重ねる墨消しは、画面を見る限り完璧に見えます。しかし実態は、隠したはずの情報がそのまま読み取れる状態でした。「見た目が対策済みに見える」ことと「実際に対策できている」ことの間には、常に距離があります。 そしてこの距離は、自分で壊してみない限り気づけません。
もう一つの学びは、作る側が、自分たちの作ったものを自分で破ってみる姿勢です。今回、墨消し機能をただ実装して終わりにしていたら、この事実には気づけませんでした。「利用者を守るための機能ほど、作った本人が最初の攻撃者になって検証する」というのは、地味ですが欠かせない工程だと再確認しました。
そして、「アップロードしない」という制約を先に決めたこと自体が、遠回りに安全性を高めたとも感じています。AI 要約のような便利な機能を安易に追加していたら、そもそも文書を外部に送る前提の設計になり、今回のような「送信ゼロを機械的に検査する」という発想自体が生まれなかったかもしれません。機能を絞ることは、弱さではなく設計の強さになることがあります。
おわりに
墨消し機能一つのために、これだけの検証と作り直しをするのは、遠回りに見えるかもしれません。ただ、機密文書を扱うツールで「実は文字が読めました」という事故が起きれば、信頼はその一度で消えます。 遠回りに見える実測の積み重ねこそが、いちばんの近道でした。
改めて、今回の教訓を3つにまとめます。
- 見た目の対策は、実測で確かめるまで信じない — 黒い四角を重ねるだけの墨消しは、文字データをそのまま残す
- 「できるけれど、やらない」を先に決める — アップロードが必要な機能は、技術ではなく方針として不採用にした
- 並行作業は速いが、最後は一人で実測し直す — 複数の担当(今回はAI)が同時に進めるほど、報告のズレ・積み残し・見誤りが出る前提で動く
セキュリティやプライバシーに関わる機能を作る、あるいは選ぶ立場にある方は、一度「見た目ではなく、実際に何が起きているか」を自分の手で確かめてみることをお勧めします。
読者への問い: 御社で使っている「対策済み」の仕組みは、見た目の安心感だけで運用されていませんか? 一度、自分たちの手で”破ってみる”検証をしたことはあるでしょうか。
この記事を読んだ方へ
自社ツールの開発だけでなく、業務で使うツール選定・セキュリティ設計の相談にも対応しています。
👉 AI 導入サポートサービス — 中小企業向け、設計から構築・運用まで 👉 お問い合わせフォーム — 個別のご相談・お見積もり
関連記事: 顧問の顔写真が消えた——「使われていない」の誤判定
執筆:Koinobori 株式会社 代表取締役 杉﨑
RELATED — 関連コラム
こちらもどうぞ
- HANDS-ON
作ったページの448枚が、どこからもリンクされていなかった — 中小企業 × AI 経営(2026年8月)
1本のページを調べたつもりが、同じ問題が11か所で見つかりました。作ったのに誰も辿り着けないページ448枚と、サイトマップが毎日ついていた「嘘」の話です。
- HANDS-ON
同じコードから、2台のパソコンで違うサイトが出来上がった — 中小企業 × AI 経営(2026年8月)
2台目の作業マシンを立てたら、同じコミットからビルドしたはずのサイトが49ページ食い違いました。原因は「並び順を指定していなかった」こと。再現性という言葉の実務的な意味について書きます。
- HANDS-ON
「部署宛」をやめて「あなた宛」にしたら、タスクが動き出した — 中小企業 × AI 経営(2026年8月)
毎朝タスクを部署ごとに1本流していましたが、誰も自分の仕事だと思っていませんでした。宛先を個人に変え、さらに同じ日のうちに一度作り直した話です。