Girish Lade.
Webアーキテクチャ · セキュリティ公開日 2026-10-306 分で読めます

アーキテクチャによるプライバシー保護:サーバー不要のPDF・メディアローカル処理

個人文書をクラウド変換サイトに送るリスクと、LS PDFやLS Image Compressorがブラウザメモリ内で100%安全にファイルを処理する仕組みを解説します。

毎日、世界中で何百万人もの人々が、銀行の明細書、医療記録、身分証明書、機密保持契約書、家族の写真を「無料」のオンライン変換サイトにアップロードしています。目的は2つのPDFを結合したり、提出用に画像を圧縮したりといった、ほんの些細な日常の用事です。

多くの人は、ダウンロードが終わればファイルは消去されると思い込んでいます。しかし工学的な観点から見れば、外部サーバーのディスクにファイルが書き込まれた時点で、その安全性は極めて脆くなります。自動バックアップが取られ、一時フォルダの削除が遅れ、アクセスログにメタデータが記録され、クラウド基盤の設定ミスからデータが流出する恐れが常にあるからです。

LadeStack の一環として LS PDF (pdf.ladestack.in) と LS Image Compressor (img.ladestack.in) を設計した際、私は妥協のない基本方針を定めました。それは、**「ユーザーのデータを守る最良の方法は、最初から受け取らないことである」**という原則です。

クライアントサイド処理へのパラダイムシフト

昔のWebブラウザには、PDFのような複雑なバイナリ形式を解析したり、高解像度のピクセルデータを素早く処理するだけの計算能力がありませんでした。そのため、ImageMagickやGhostscriptといったサーバーサイドのツールに頼らざるを得なかったのです。

しかし今日、日常的なファイル操作においてその手法はもはや時代遅れです。TypedArrayを最適化するモダンJavaScriptエンジン、ネイティブに近い速度で動くWebAssembly、そしてハードウェアアクセラレーションが効くHTML5 Canvas APIのおかげで、ブラウザは手元の端末上ですべての処理を軽快にこなせます。

[従来のクラウド変換]
ファイル -> ネット経由で送信 -> 外部サーバー -> バックエンド処理 -> ネット経由で再取得
(通信待ち、帯域消費、データ流出の重大なリスク)

[LadeStack のローカル処理]
ファイル -> ブラウザRAM上の ArrayBuffer -> Web Worker / Canvas -> ローカル Blob URL
(送信ゼロ、即座に完了、プライバシーの完全な保護)

LS PDFの舞台裏:17の機能をメモリ上で完結

LS PDF は、ブラウザ上で動く2つの主要ライブラリを中心に構成されています。1つは画面描画やテキスト抽出を担当する PDF.js、もう1つはPDFのバイト列を変更・結合・分割・出力する pdf-lib です。

1. 通信を一切発生させない結合と分割

LS PDFで3つのPDFファイルを結合する際の手順は以下の通りです:

  1. 標準のHTML5 File APIでファイルを選択します。
  2. FileReader.readAsArrayBuffer() を通じて、ファイルがブラウザのRAM上に ArrayBuffer として直接展開されます。
  3. PDFDocument.load() がメモリ内でPDFの構造を解析します。
  4. newDoc.copyPages(sourceDoc, pageIndices) により、指定されたページだけを新しいドキュメントへコピーします。
  5. 結合後のデータが Uint8Array に変換され、URL.createObjectURL(new Blob([...])) で生成されたローカルURLを通じて、手元のストレージへ即座にダウンロードされます。

一般的なPCであれば、この一連の処理は200ミリ秒もかかりません。ネットワーク上を流れるデータ量は正真正銘の「ゼロ」です。

2. Web Workersによる画面フリーズの防止

数百ものベクターパスや高画質画像を含む重いPDFを解析すると、ブラウザのメインスレッドが占有されてしまいます。もしメインスレッドが50ミリ秒以上ブロックされると、ボタンの反応が遅れ、画面のスクロールがカクつき、「ページが応答しません」という警告が出てしまいます。

どんな時でも60fpsの滑らかな操作感を保つため、LS PDFは重い計算をすべてバックグラウンドの Web Workers に逃がしています:

// メモリの無駄なコピーを発生させずにデータを別スレッドへ転送
const worker = new Worker('/workers/pdf-worker.js');
const buffer = await file.arrayBuffer();

worker.postMessage({ action: 'EXTRACT_TEXT', buffer }, [buffer]);

buffer を「Transferable Object(移譲可能オブジェクト)」として渡すことで、余計なメモリ複製を行わずに所有権だけを別スレッドへ一瞬で渡せます。処理が終わると、整形された結果だけがメインのUIへ戻ってきます。

LS Image Compressorの舞台裏:Canvas APIの直接操作

LS Image Compressor では、外部の画像処理APIに頼る代わりに、ブラウザの HTML5 Canvas API を活用しています。

1. 寸法変更と目標ファイルサイズへの自動収束

画像をドロップすると:

  1. メインスレッド外で画像が ImageBitmap にデコードされます。
  2. 指定された最大幅・高さの制約に合わせてアスペクト比を計算します。
  3. OffscreenCanvas 上にバイキュービック補間を用いて美しく描画します。
  4. .convertToBlob({ type: 'image/webp', quality }) を呼び出して最適化画像を生成します。

「公的機関の申請フォーム用に、この4MBの写真を200KB以下に抑えたい」といった具体的なサイズ指定がある場合、本ツールは二分探索アルゴリズムを用いて圧縮率(0.1〜1.0)を3〜4回の試行で素早く算出し、目標の容量にピタリと合わせます。

2. クリップボードからの直接処理

多くのオンラインサービスでは、画像のアップロードやURLの指定が求められます。端末内処理に特化しているため、運転免許証や身分証、開発中のデザイン画面などをクリップボードから直接貼り付け(Ctrl+V)して、安全に圧縮・変換できます。

経済的かつ倫理的な優位性

クライアントサイド実行を前提にしたソフトウェア設計は、従来のSaaS企業が避けたがる理想的な好循環を生み出します:

  • 開発者側のインフラ費用がゼロ: ユーザーの手元のCPUで計算が行われるため、LadeStackは莫大なクラウドサーバー代や通信費を支払う必要がありません。これにより、ツールを永続的に完全無料で開放できます。
  • 証明可能な安全性: 「私たちは利用者のデータを覗き見しません」という何十ページもの利用規約を書く必要はありません。アーキテクチャそのものが、データを閲覧することを物理的に不可能にしているからです。
  • オフライン動作: プログラムがブラウザのキャッシュに保存されるため、一度読み込めば飛行機の中や電波の届かない場所でもツールがそのまま使えます。

プライバシー保護は、企業向けの高価なオプション機能であってはなりません。ブラウザの真の実行能力を信頼してソフトウェアを作ることで、誰にとっても速く、安く、そして根本から安全な道具を届けることができるのです。