ブラウザでPDF編集が完結する仕組みとプライバシーが重要な理由

クラウドベースのPDFツールにドキュメントをアップロードするたびに、そのドキュメントはあなたが管理できないサーバー上に存在し、確認できないソフトウェアによって処理され、独自のデータ保持方針とセキュリティ体制を持つ企業によって保管されます。ほんのわずかな間、他者のインフラがあなたの契約書、確定申告書、医療記録、または機密ビジネス文書を保持することになります。

LuraPDFは異なる仕組みで動作します。すべての処理はブラウザのタブ内で、あなたのハードウェア上で、あなたのOSのメモリ管理のもとで行われます。この記事では、これを実現する技術アーキテクチャと、そこに伴うエンジニアリング上のトレードオフを解説します。

ドキュメント処理プラットフォームとしてのブラウザ

現代のブラウザは単なるHTMLレンダラーではありません。以下を備えた完全なアプリケーション実行環境です。

• JavaScriptエンジン（ChromeのV8、FirefoxのSpiderMonkey）：ネイティブに近い速度でコードを実行
• WebAssembly（WASM）：サンドボックス環境内でコンパイル済みC/C++コードをネイティブに近い速度で実行
• Canvas API：ピクセルレベルの画像操作を実現
• File System Access API：アップロードなしでローカルファイルの読み取りを可能に
• Web Workers：UIをフリーズさせずにバックグラウンドスレッドで計算を実行
• ArrayBuffer / Blob：PDFのバイト列などの生バイナリデータをメモリ上で管理

これらの機能を組み合わせることで、5年前ならバックエンドサーバーが必要だったフル機能のドキュメント処理パイプラインをブラウザ上で実現できます。

3つのコアライブラリ

LuraPDFは3つの基盤となるオープンソースライブラリの上に構築されています。

pdf-lib

pdf-libは、あらゆるJavaScript環境でPDFドキュメントを作成・編集するためのTypeScriptライブラリです。PDF仕様（ISO 32000）の主要部分を実装しており、以下が含まれます。

• ページの作成、編集、削除
• フォントの埋め込み（標準14フォントおよびカスタムTTF/OTFフォント）
• 画像の埋め込み（JPEG、PNG）
• テキスト注釈の配置
• フォームフィールドの作成と操作
• ドキュメントメタデータ（タイトル、作成者、作成日など）
• ドキュメントのパスワード保護
• 相互参照テーブルの管理

LuraPDFがPDFを結合する際、pdf-libを使用して各ドキュメントのページツリーを読み取り、共有リソースを正規化し、新しいPDFを組み立てます。圧縮時には、画像オブジェクトをより低い品質係数で再エンコードします。パスワード保護時には、パスワードから鍵を導出し、すべてのPDFリーダーが解釈できるPDF標準セキュリティハンドラを使用して暗号化されたドキュメントを書き出します。

pdf-libはArrayBufferオブジェクト（ブラウザメモリ上の生バイナリデータ）のみで動作します。ネットワーク通信は一切発生しません。

pdfjs-dist

PDF.jsはMozillaのPDFレンダリングエンジンで、npmではpdfjs-distとして配布されています。FirefoxのビルトインPDFビューアを動かすエンジンであり、何百万もの実際のPDFでテストされています。

LuraPDFはpdfjs-distを以下の目的で使用しています。

• ページレンダリング：PDFページをCanvas ImageDataに変換して表示
• テキスト抽出：PDFページのテキストコンテンツストリームの読み取り
• ページメタデータ：ページサイズ、回転値、コンテンツタイプの取得

LuraPDFのインターフェースでPDFがレンダリングされて見える部分、つまりページのビジュアルプレビューは、pdfjs-distが各ページをHTML Canvasエレメントに描画したものです。

Tesseract.js

Tesseract.jsは、Tesseract OCRのWebAssemblyコンパイル版です。TesseractはHP Labs（1985年）が開発し、現在GoogleがメンテナンスしているオープンソースのOCRエンジンです。文字認識にはLSTM（Long Short-Term Memory）ニューラルネットワークモデルを使用します。

WebAssemblyを通じてブラウザでTesseractを動作させることで、以下が実現します。

• 22MBのWASMバイナリは一度ロードされるとブラウザにキャッシュされる
• OCR処理はGPUではなく、WebAssembly経由でCPUで実行される
• 処理速度はクラウドOCR（GPUクラスターを使用）より遅いが、出力品質は同等
• ドキュメントの内容はデバイスの外に出ない

20ページのスキャン文書の場合：ブラウザOCRは約30〜120秒かかります。クラウドサービスなら2〜5秒程度です。このトレードオフはプライバシーと速度の問題です。

アーキテクチャ：ファイルから出力まで

LuraPDFでPDFを圧縮する場合、何が起きているかを順を追って説明します。

1. ファイル選択：ドロップゾーンにPDFをドラッグします。ブラウザのFile APIがファイルをArrayBuffer（ブラウザメモリ上の生バイト列）として読み取ります。アップロードは発生しません。

2. バリデーション：ArrayBufferの先頭にマジックバイト%PDFが存在するかをすばやく確認します。

3. ロード：pdf-libのPDFDocument.load()が相互参照テーブルを解析し、オブジェクトツリーを読み取り、ドキュメントのインメモリ表現を構築します。

4. 画像の列挙：ライブラリがページコンテンツストリームを走査して画像XObject（埋め込み画像）を検出します。各画像の幅、高さ、圧縮タイプ、バイトデータが抽出されます。

5. 再エンコード：各画像について、生ピクセルデータをHTML Canvasエレメントに描画し、canvas.toBlob('image/jpeg', quality)でより低いJPEG品質係数で再出力します。元の画像オブジェクトはより小さいエンコード済みバージョンに置き換えられます。

6. ドキュメントのシリアライズ：pdf-libのsave()メソッドが編集済みドキュメントをバイト列に戻します。オブジェクトストリームはDEFLATE圧縮されます。

7. ダウンロード：バイト列がBlobオブジェクトにラップされ、一時的なオブジェクトURL（URL.createObjectURL(blob)）が生成され、プログラム的な<a>クリックによってブラウザのダウンロード機構が起動します。

外部サーバーへの送信データ量：0バイト。

Web Workers：UIのレスポンシビリティを維持する

PDF処理はCPUを集中的に使用します。メインのJavaScriptスレッドで実行すると、ファイル処理中にブラウザタブがフリーズし、スクロールもクリックも進捗確認もできなくなります。

LuraPDFはすべての重い計算（OCR、大きなPDFの解析、画像の再エンコード）をWeb Workers（バックグラウンドで動作する独立したJavaScriptスレッド）で実行します。メインスレッドはUIを担当し、プログレスバーを表示し、メッセージパッシング（postMessage / onmessage）でワーカーと通信します。

OCRの実行中は、各ページの処理が完了するたびに進捗イベントが発火します。ワーカーは{ page: 5, total: 20, confidence: 94 }をメインスレッドに送信し、プログレスバーが更新されます。処理中もUIは常に操作可能です。

メモリ管理

ブラウザのメモリは有限です。200MBのPDFをメモリにロードし、処理し、保存する場合、400〜600MBのRAM（元のバイト列＋中間のCanvasデータ＋出力バイト列）が必要になる可能性があります。RAMが限られたシステムでは、メモリプレッシャーが生じることがあります。

使用している対策：

• ストリーミングページ処理：複数ページの操作では、ページを処理した後に中間のCanvasエレメントを順次破棄
• URL.revokeObjectURL()：一時的なBlobのURLはダウンロード後に失効させてGCを促進
• Workerの終了：Web Workersはタスク完了後に終了させ、使用していたメモリを解放

非常に大きなファイル（100MB超）は、8GB以上のRAMを持つシステムの現代的なブラウザでは問題なく処理できます。古いシステムやメモリが制限されたシステムでは、100MB超のソースファイルで問題が生じる場合があります。

プライバシーアーキテクチャ

セキュリティモデルはブラウザの同一オリジンポリシーと分離アーキテクチャによって強制されます。

• HTTPリクエストなし：ドキュメント処理中に外部APIへの呼び出し、テレメトリ、アナリティクスの送信は発生しない
• サンドボックス実行：Web Workersは外部オリジンへのネットワーク呼び出しが不可能
• 永続ストレージなし：処理済みファイルはブラウザのストレージ（localStorage、IndexedDB、File System Access）に書き込まれない
• タブスコープのメモリ：タブを閉じると、関連するすべてのArrayBufferとBlobオブジェクトがガベージコレクションされる

このアーキテクチャは検証可能です。ファイルの処理中にDevToolsのNetworkタブを開いてください。処理操作中にリクエストが0件であることが確認できます。

オープンソースライブラリ：検査可能、ブラックボックスではない

3つのコアライブラリ（pdf-lib、pdfjs-dist、Tesseract.js）はすべて、GitHubに公開リポジトリを持つオープンソースです。実装は誰でも確認できます。LuraPDFで動作するPDF処理コードは独自仕様のブラックボックスではなく、実際のユーザー、Issue、コントリビューションを持つ公開コードです。

これは信頼の観点から重要です。クラウドサービスが「ファイルを処理して削除します」と言うとき、あなたはその言葉を信じるしかありません。LuraPDFがブラウザのサンドボックス内でネットワーク呼び出しなしにオープンソースライブラリを使用する場合、Networkタブを確認することでその主張を自分で検証できます。

クラウド処理とのトレードオフ

ブラウザベースのモデルには正直に認めるべきトレードオフがあります。

速度：クラウドサービスはGPUクラスターと専用インフラを持っています。大きなドキュメントに対するブラウザOCRは、クラウドの同等処理に比べて2〜10倍の時間がかかります。圧縮はCanvas APIを直接使用するため高速です。

ファイルサイズの制限：制約となるのはブラウザのメモリです。非常に大きなファイル（300MB超）は一部のシステムでメモリ制限に達する場合があります。クラウドサービスにはそのような制約はありません。

処理能力：WASMはネイティブC++速度の40〜80%で動作します。クラウドサービスは最適化されたネイティブコードを実行します。ほとんどのドキュメントではこの差は体感できませんが、100ページ超のOCR処理では目立ちます。

機能：一部の高度なPDF機能（PDF/Xコンプライアンスチェック、プロフェッショナルカラーマネジメント、CMYKワークフロー）は専門的なサーバーサイドツールを必要とします。ブラウザベースの処理は95%のケースに対応します。

日常的なドキュメント処理（圧縮、結合、署名、変換、削除）については、ブラウザベースのモデルは十分な速度があり、設計上プライベートであり、アカウントやサブスクリプションも不要です。

よくある質問

LuraPDFはテレメトリや使用データを収集しますか？ LuraPDFはページビューの集計統計にGoogle Analyticsを使用しています。ドキュメントの処理操作はアナリティクスイベントを生成しません。ファイルの内容は一切送信されません。

アップロードが発生しないことを確認できますか？ はい。デベロッパーツール（F12）を開き、Networkタブをクリックし、「XHR」または「Fetch」でフィルタリングします。ファイルを処理してください。処理中にドキュメント関連のネットワークリクエストが0件であることを確認できます。

他のサービスと比べてOCRに時間がかかるのはなぜですか？ ブラウザベースのTesseract.jsはWebAssembly経由でCPUで動作します。クラウドのOCRサービスは文字認識を桁違いの速度で処理するGPUクラスターで動作します。そのトレードオフとして、ドキュメントがブラウザの外に出ることはありません。

処理中にタブを閉じるとどうなりますか？ 処理は即座に停止します。ブラウザタブのメモリはガベージコレクションされます。ディスク上の元のファイルは変更されません。

コードはオープンソースですか？ コア処理ライブラリ（pdf-lib、pdfjs-dist、Tesseract.js）はオープンソースです。LuraPDFのインターフェースコードは現在オープンソースではありませんが、処理パイプラインはオープンソースのコンポーネントのみを使用しています。

ブラウザベースのドキュメント処理への移行は単なるギミックではありません。これは計測可能なプライバシーと信頼の優位性を持つ、真のアーキテクチャ上の選択です。集中的な処理における速度という代償を払う価値があります。他者のサーバーに存在させたくないドキュメントにとって、これは正しいトレードオフです。