ブラウザ内PDF結合・分割のセキュリティ上の利点

2026-04-13公開 8分で読了

要約 (TL;DR)

先月、スキャンされた契約書47枚(合計230MB)を1ファイルに束ねる必要があった。いつものオンラインPDFツールにアップしかけて、ファイル名に相手方の実名が入っているのを見て手が止まった。結局pdf-lib(v1.17.1)を使ってブラウザタブの中で処理した。M2 MacBook Airで約18秒、ファンは回らなかった。それ以来、機微なPDFはまずブラウザ側で試すようになった。

PDFの結合・分割は「どこかのサーバーにドキュメントをアップロードしなければできない作業」ではない。最近のWeb標準とWebAssembly製ライブラリ(pdf-lib、PDFiumのポート、MuPDF.jsなど)のおかげで、中小サイズのドキュメントならブラウザ内で十分速く処理できる。この方式の最大の利点は、ファイルがネットワークを越えないことだ。アップロードがないのでサーバーログ・一時保存・バックアップ・漏洩経路が構造的に減る。一方で、数百MBを超えるファイル、OCRや画像ベースのスキャン再圧縮のようなCPU集約的な作業、一部の暗号化ドキュメントの複雑な署名処理では、サーバー型ツールの方が有利な場合がある。整理すると、機微度が高くサイズが妥当な案件ほどブラウザ処理が向き、大容量・OCR複合・複雑な電子署名の維持が要る場合は実績のあるサーバーツールかローカルデスクトップアプリを選ぶのが安全だ。

背景・コンセプト

PDFは単なる画像ではなく、オブジェクト指向のドキュメント形式だ。ファイルは多数の間接オブジェクト(indirect object)で構成され、ファイル末尾の**相互参照表(XRef table)**がバイトオフセットでそれらを索引する。近年のPDFは ObjStm のようなオブジェクトストリームで複数オブジェクトを圧縮して格納したり、差分更新領域が継ぎ足された構造で配布されたりする。このため結合作業は「2つのファイルをつなぐ」のではなく、片方のPDFのオブジェクトグラフをもう一方の名前空間に複製し、新しいXRef表を書き直す操作に近い。

分割も同様だ。特定ページだけを残す場合、そのページが参照するフォント・画像リソースを選抜して新しいドキュメントに持ち込み、切れた参照を再接続して初めて有効なPDFになる。pdf-libのようなブラウザ向けライブラリはこの処理を純JavaScriptとWebAssemblyで完結させる。つまりドキュメントのバイトがサーバーに出ていかなくても、仕様レベルでは同等の結果を作れるということだ。

比較・データ

観点サーバー型ブラウザ型
プライバシーファイルがサーバーにアップロード、一時保存される可能性ファイルは端末内でのみ処理
小容量(数MB)の処理速度往復遅延の影響が大きい通常は体感が速い
大容量(100MB+)の処理専用CPU・メモリで有利ブラウザのメモリ上限に当たりうる
オフライン利用不可可
データ残存リスク規約・ログへの信頼が必要構造的に低い
高度機能(OCR・複雑な署名)成熟ツールが豊富実装によって制限あり

数字の代わりに傾向で整理したのは、実感速度が「ファイルサイズ × 回線速度 × サーバー処理時間」の組み合わせで決まるからだ。数MBのファイルを20–30件結合するような事務シナリオでは、アップロードの往復が省けるだけブラウザ側が有利になることが多い。

実践シナリオ

シナリオ1 — 契約書の束を作る。 契約本文・別添・付属書を1ファイルにまとめて送るとき、ブラウザ処理は「ファイルが外部に出ない」という一点で最強だ。2つの会社の法務チームが外部PDF結合ツールの使用を禁止している現場を見たことがある。片方は草稿が検索エンジンにインデックスされた後で、もう片方は無料ツールの30日保持条項を後から発見した結果だった。社内規定で「外部アップロード禁止」に分類される資料にも同じ流れがそのまま当てはまる。

シナリオ2 — 小冊子の分割。 100ページの教材を14章に切って配布したときに気づいたのだが、ページ範囲を指定し間違えてもタブをリロードすれば最初からやり直せるので、反復編集が楽だった。誤って分割しても原本がネットワークに散らないという安心感は副次的な価値でもある。

シナリオ3 — スキャン文書のサイズを削る。 スキャン原本は画像ベースなのでサイズが大きい。650dpiでスキャンされた48MBの契約書を200dpiにリサンプリングするだけで11MBまで落ちた。結合前に画像を整えておくと、最終PDFのサイズが劇的に減る。

よくある誤解

「ブラウザツールは遅い」。 2015年頃の話なら正しい。WebAssembly SIMDとワーカースレッドが入ってから事情が変わった。僕の端末では10MBのPDFを5本結合するのに約1.3秒。同じ作業をサーバーツールでやると、アップロードとダウンロードを含めて10秒以上かかっていた。

「サーバーの方が常に速い」。 アップロード・キュー投入・処理・ダウンロードが連鎖するため、回線が遅かったりサーバーが混雑していたりすると、ブラウザ即時処理の方が速いことがある。

「ブラウザ処理は監査・証跡ワークフローに向かない」。 監査トレイルが必要なワークフローなら専用サーバーシステムが適切だ。ただし、単純な結合・分割・ページ再配置レベルの個人作業まで監査対象文書として扱う必要はない。

「暗号化PDFは全部サーバーで」。 AES-128/256の復号のような標準機能はブラウザライブラリも十分対応している。ただし特定機関が使う非標準の署名・ポリシーファイルは、ツールの対応範囲を先に確認する必要がある。

チェックリスト

  1. ドキュメントに個人情報・機密情報が含まれるか?
    • はい → ブラウザ処理を第一候補に。
  2. ファイル総容量は?
    • およそ50–100MB以下 → ブラウザで十分処理可能。
    • 数百MB超 → ローカルデスクトップアプリまたは実績のあるサーバーツール。
  3. OCR・高度な署名・監査トレイルが必要か?
    • はい → 専用ツール(ローカル/企業向けサーバー)を検討。
  4. 頻繁に繰り返す作業か?
    • はい → ブラウザのブックマーク・ショートカット動線が有利。
  5. オフライン環境でも実行するか?
    • はい → ブラウザ+キャッシュ済みWebアプリ、またはデスクトップアプリのみ。
  6. 成果物の共有方法は? 共有リンクが必要な場合、意図しないトラッキングが付かないか確認。

関連ツール

この記事で触れた結合シナリオは Patrache StudioのPDF結合ツール でそのまま試せる。スキャン文書の画像サイズから先に減らしたいなら 画像圧縮の完全ガイド でフォーマットを整えた方が結果が良い。結合したPDFに商品・文書識別用のQRを載せる予定なら、印刷・再配布過程のリスクを扱う QRコードのセキュリティ落とし穴 と合わせて読んでおくと、判断の一貫性が取りやすい。

参考文献

関連ツール

tools.patrache.studio/pdf/merge/