Technical

ブラウザベースのPDF編集の仕組み（そしてプライバシーが重要な理由）

LuraPDFがpdf-lib、pdfjs-dist、Tesseract.js、WebAssemblyを使用して、アップロード、クラウド、データ公開を一切行わずに、ブラウザ内でPDFを完全に処理する仕組みを技術的に解説します。

Editorial & Technical Team · May 6, 2026 · 16 min read

クラウドベースのPDFツールに文書をアップロードするたびに、その文書はあなたが管理できないサーバー上に存在し、あなたが検査できないソフトウェアによって処理され、独自のデータ保持およびセキュリティ体制を持つ企業によって保管されます。つまり、契約書、納税申告書、医療記録、機密性の高いビジネス文書などが、短期間ではありますが、他社のインフラストラクチャに保管されることになるのです。

LuraPDFは他とは異なる仕組みで動作します。すべての処理はブラウザのタブ内で、お使いのハードウェア上で、オペレーティングシステムのメモリ管理機能を利用して行われます。この記事では、これを可能にする技術アーキテクチャと、それに伴うエンジニアリング上のトレードオフについて解説します。

文書処理プラットフォームとしてのブラウザ

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

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

これらの機能を組み合わせることで、5年前であればバックエンドサーバーが必要だったような、フル機能の文書処理パイプラインを実現できる。

3つのコアライブラリ

LuraPDFは、以下の3つの基本的なオープンソースライブラリに基づいて構築されています。

pdfライブラリ

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

ページの作成、変更、削除
フォントの埋め込み（標準14フォントとカスタムTTF/OTFフォントの両方）
画像埋め込み（JPEG、PNG）
テキスト注釈の配置
フォームフィールドの作成と操作
文書のメタデータ（タイトル、作成者、作成日など）
PDF暗号化（AES-128およびAES-256）
相互参照テーブル管理

LuraPDFはPDFを結合する際、pdf-libを使用して各ドキュメントのページツリーを読み込み、共有リソースを正規化して新しいPDFを作成します。圧縮時には、画像オブジェクトを低品質係数で再エンコードします。暗号化時には、Web Crypto APIを使用してドキュメントにAES-256を適用します。

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は、WebAssemblyでコンパイルされたTesseract OCRのバージョンです。Tesseractは、元々はHP Labs（1985年）によって開発され、現在はGoogleによってメンテナンスされているオープンソースのOCRエンジンです。文字認識にはLSTM（長短期記憶）ニューラルネットワークモデルを使用しています。

ブラウザでWebAssembly経由でTesseractを実行するということは、次のことを意味します。

22 MBのWASMバイナリは一度読み込まれ、ブラウザによってキャッシュされます。 OCR処理はGPUではなく、WebAssemblyを介してCPU上で実行されます。処理速度はクラウドOCR（GPUクラスタを使用）より遅いが、出力品質は同等である。
ドキュメントの内容はデバイスから外部に出ることはありません

20ページのスキャンの場合、ブラウザのOCR処理には約30～120秒かかります。クラウドサービスなら2～5秒で済みます。プライバシーと処理速度のトレードオフとなります。

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

例えば、LuraPDFでPDFを圧縮すると、次のようなことが起こります。

ファイル選択: PDFファイルをドロップゾーンにドラッグします。ブラウザのファイルAPIがファイルをArrayBuffer（ブラウザメモリ内の生バイト）に読み込みます。アップロードは行われません。
検証: マジックバイト %PDF が ArrayBuffer の先頭に現れることを簡単に確認します。
読み込み中: pdf-lib の PDFDocument.load() は相互参照テーブルを解析し、オブジェクトツリーを読み取り、ドキュメントのメモリ内表現を構築します。
画像列挙: ライブラリはページコンテンツストリームを走査して、画像XObject（埋め込み画像）を検出します。各画像の幅、高さ、圧縮タイプ、およびバイトデータが抽出されます。
再エンコード: 各画像について、生のピクセルデータがHTML Canvas要素に描画され、その後、 canvas.toBlob('image/jpeg', quality) を使用して、より低いJPEG品質係数で再エクスポートされます。元の画像オブジェクトは、より小さいエンコードされたバージョンに置き換えられます。
ドキュメントのシリアル化: pdf-lib の save() メソッドは、変更されたドキュメントをバイト列にシリアル化します。オブジェクトストリームは DEFLATE 圧縮されます。
ダウンロード: バイト列はBlobオブジェクトにラップされ、一時的なオブジェクトURLが作成され（ URL.createObjectURL(blob) ）、によるクリックによってブラウザのダウンロードメカニズムトリガーされます。

外部サーバーに送信されたデータ総量：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(): 一時的なブロブURLはダウンロード後に無効化され、GC（ガベージコレクション）が可能になります。
ワーカーの終了: Web Worker は、タスク完了後に終了して、使用したメモリを解放します。

非常に大きなファイル（100MB以上）の場合、最新のブラウザは8GB以上のRAMを搭載したシステムであれば問題なく処理できます。しかし、古いシステムやメモリ容量の少ないシステムでは、100MBを超えるソースファイルの処理に苦労する可能性があります。

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

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

HTTPリクエストなし: ドキュメント処理中に外部API呼び出し、テレメトリ、分析呼び出しは行いません。
サンドボックス実行: Web Worker は外部オリジンへのネットワーク呼び出しを行うことができません
永続ストレージなし: 処理されたファイルはブラウザのストレージ（localStorage、IndexedDB、またはファイルシステムアクセス）に書き込まれません。
タブスコープのメモリ: タブを閉じると、それに関連付けられているすべての ArrayBuffer および Blob オブジェクトがガベージコレクションされます。

このアーキテクチャは検証可能です。ファイルを処理中にブラウザのDevToolsでネットワークタブを開いてみてください。処理中にリクエストがゼロであることが確認できます。

オープンソースライブラリ：ブラックボックスではなく、検証可能なもの

3つの主要ライブラリ（pdf-lib、pdfjs-dist、Tesseract.js）はすべてオープンソースであり、GitHubに公開リポジトリがあります。実装は誰でも検査可能です。LuraPDFで実行されるPDF処理コードは、独自のブラックボックスではなく、実際のユーザー、問題、貢献が存在する公開コードです。

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

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

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

速度: クラウドサービスはGPUクラスターと専用インフラストラクチャを備えています。ブラウザで大規模なドキュメントのOCR処理を行う場合、クラウドサービスに比べて2～10倍の時間がかかります。圧縮はCanvas APIを直接使用するため高速です。

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

処理能力: WASMはネイティブC++の40～80%の速度で動作します。クラウドサービスは最適化されたネイティブコードを実行します。ほとんどのドキュメントではこの差は感じられませんが、100ページを超えるOCR処理では顕著になります。

機能: 一部の高度なPDF機能（PDF/X準拠チェック、プロフェッショナルなカラーマネジメント、CMYKワークフローなど）には、専用のサーバーサイドツールが必要です。ブラウザベースの処理で95%のケースに対応できます。

日常的な文書処理（圧縮、結合、署名、変換、墨消しなど）においては、ブラウザベースのモデルは十分な速度を備えており、プライバシー保護も設計上確保され、アカウントやサブスクリプションも不要です。

よくある質問

LuraPDFはテレメトリデータや使用状況データを収集しますか？ LuraPDFは、ページビューの集計統計のためにGoogle Analyticsを使用しています。文書処理操作では、分析イベントは一切発生しません。ファイルの内容が送信されることもありません。

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

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

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

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

ブラウザベースの文書処理への移行は、単なる流行りではありません。これは、プライバシーと信頼性の面で明確なメリットをもたらす、真に合理的なアーキテクチャ上の選択です。ただし、負荷の高い処理においては速度が低下するというデメリットがあります。他人のサーバー上に存在させたくない文書については、この選択は適切なトレードオフと言えるでしょう。